IRC channel logs


back to list of logs

<daviid>hello guilers
<daviid>davexunit: guile-2d configure claims i don't have guile-2
<daviid>./configure: line 2384: GUILE_PROGS: command not found
<daviid>configure: error: Guile 2.0 required.
<daviid>i have a manually build guile and my ACLOCAL_FLAGS is properly set
<daviid>davexunit: fyi, guile-g-wrap[cairo,gnome] autogen/configure do not protest
<daviid>it still does not find it even after autoreconf -vfi
<davexunit>daviid: hmmm, strange. I also compiled my own guile.
<daviid>there id a bug in configure
<daviid>it has a line [line 2386 in my case] with the sole expression:
<daviid>which leads to GUILE_PROGS: command not found
<daviid>line 9 in is missing a comment imo
<daviid>ok, now it leaves us only with: configure: error: Guile 2.0 required
<davexunit>I'm curious as to why this has always worked for me
<daviid>davexunit: i sugget you take a look at as done in guile-gnome, i think you should change the way you check for guile's presence on a user computer
<civodul>daviid: re GUILE_PROGS not found, guile.m4 needs to be in aclocal's search path when autoreconf is run
<daviid>ah let me check
<daviid>civodul, it is
<daviid>echo $ACLOCAL_FLAGS
<daviid>-I /opt/share/aclocal
<daviid>david@capac:/usr/local/src/guile-2d/git-clone 28 $ ll /opt/share/aclocal/guile.m4
<daviid>16 -rw-r--r-- 1 david alto 13059 Apr 12 18:05 /opt/share/aclocal/guile.m4
<civodul>daviid: yes GUILE_PROGS is not picked from there?
<daviid>i don't understand sorry
<daviid>./ --prefix=/opt; ./configure --prefix=/opt; ... ./configure: line 2384: GUILE_PROGS: command not found
<daviid>configure: error: Guile 2.0 required.
<daviid>civodul: i worked on g-wrap manual this we :) it all started because i wanted modern procedure and type index as by texinfo5.2, then discovered a bunch of bugs [while compiling with texinfo 5.2], then could'nt stop to try to improve the structure and get it as close as possible of the guile ref manual. all done, i'll send a patch soon
<civodul>sounds good! :-)
<daviid>it really looks much better, i'm pleased i did that. now i'll read it :) :)
<civodul>daviid: can you try "aclocal -I/opt/share/aclocal && grep GUILE_PROGS aclocal.m4"?
<daviid>sure: ... GUILE_PROGS aclocal.m4
<daviid>hereis: ... AC_DEFUN([GUILE_PROGS],
<daviid>civodul: if you add me to the g-wrap project i can do the house keeping for the html mages of the online manual...
<daviid>after review of course
<civodul>daviid: i'm not a member:
<civodul>you should ask wingo or rotty
<daviid>ah ok
<civodul>rotty is G-Wrap 2.0's father :-)
<daviid>i'll send a request through savannah
<daviid>it's a fantastic tool really, i just have to understand whu basic pointers are not handled. but it's ineration with goops is a must. the manual needs some technical updates as well, did do that [freeing pointers seems to refer to the previous gc still]
<daviid>what is the future of g-wrap? last time you said 'oh'... i think it should be improved, but i have a feeling that it is abandonned, somehow,wdyt?
<civodul>daviid: to be honest, in hindsight, i'd prefer to see it vanish quietly :-)
<civodul>i prefer to use the FFI, or otherwise something much less baroque when the FFI is not an option
<civodul>(i did use g-wrap in the old days, and was enthusiastic as well back then ;-))
<daviid>is the FFI as fast [I mean the code that is wrapped through]
<civodul>in theory C bindings can be slightly faster than the FFI
<civodul>in practice, it probably rarely matters
<civodul>and g-wrap adds run-time overhead compared to C bindings you'd do by hand anyway
<daviid>speed is very important i think [binfing clutter...] but the question is to do things automatically, imo, and integrate with goops when the original lib is oo
<daviid>so you'd prefe to write g-wrap using the ffi then [sort of]?
<daviid>you would use ffi, like reading gir files -> all automatic?
<civodul>it's true that the FFI doesn't really help wrt. GOOPS integration, but that's probably easily added
<civodul>i'm not sufficiently familiar with gir files
<daviid>anyway i need help to wrap a guint8* [as an argument], could you help me pleaaase? :) [WARNING (opaque type for proc clutter-image-set-data guint8*)]
<civodul>you wouldn't want to read them at run time, rather at expansion time
<daviid>i am not either. i understand .h -> h2defs and the wrap chain..
<civodul>i'm afraid i wouldn't even be able to help in a timely fashion :-)
<civodul>all this has escaped my mind ;-)
<daviid>ok, too bad
<daviid>no read at runtime of course
<daviid>why doi you say that, ffi reads at runtime?
<daviid>but do you think g-wrap could be improved rahter then abandonned? like make it use the ffi instead?
<daviid>civodul: i know but i did not read about it yet: i need [want to] update guile-clutter first
<civodul>i think it uses GOOPS in very nasty ways
<civodul>and it's very oriented towards C code generation
<daviid>it's all learning curve for me, which is good of course, but make me ask stupid quizz from time to time :)
<daviid>GOOPS in very nasty ways'; any example?
<civodul>daviid: all that said ;-), it's really great that you're working on updating all these libraries
<civodul>these are useful pieces of software
<daviid>i am learning a lot, and really want to use clutter
<civodul>an issue with GOOPS is that define-method creates a new generic if it can't find one under that name, or adds a method to an existing generic otherwise
<civodul>that's very error-prone
<civodul>and i remember hitting this sort of problems in g-wrap
<daviid>but that is the essence of goops
<civodul>this particular problem could have been avoided without changing the essence :-)
<daviid>thay can't be any error coming from adding a method to a generic function, imo
<daviid>i am curious: what you suggest then?
<civodul>force users to define-generic prior to define-method
<daviid>by the way, in practice, andy also wanted generated generics to land in 1 module (gnome gw generics) and wrote some magic for that to happen
<civodul>ok, haven't looked at guile-gnome
*civodul has to go
<daviid>ok bye civodul
<davexunit>ah, that GOOPS method problem bit me back when I tried to use it. it was super frustrating.
<daviid>davexunit: i can help if you wish. the problem is the default 'behaviour' of the module system, and lack of a parameter so that #:export [getter|setter|accessor|method] behaving like re-export. if not by default, the module system should offer that as a config option, the same way you'd configure (default-duplicate-binding-handler '(merge-generics replace warn-override-core warn last)) [my options]
<davexunit>daviid: yeah I think that I did something like that to work around the issue.
<davexunit>when I used GOOPS, which I no longer do.
<daviid>too bad, goops is great
<daviid>i wish i knew guile's internals better, i'd write immediately a series of options to the already existing 'mege-generics, so that goops [and the module system] behave exactly as i want: all classes and generics in 1 module, #:export getter|setter|accessor|method always automatically creating a generic if not exists/adding a method to 'its' generic function. generics automatically created [as said] and redefining a generic would trigger
<daviid>an error [when 'all generics in 1 module, merge-generics would be disabled of course]. redefining a class would trigger a WARNING by default
<ijp>there is no point having a module system if you want to lump them all in one
<daviid>ijp: you need the module system for non oop programming
<ijp>and not for oop?
***karswell` is now known as karswell
<daviid>please keep cool and nice