<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>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 configure.ac 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 configure.ac 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>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>./autogen.sh --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 <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>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 :-) <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 <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>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 <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. <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 ***karswell` is now known as karswell