Hi! [BTW: There seem to be two guile-gtk mailing lists ATM - I guess people should migrate to the one at GNU...] I'm ATM working at implementing "glueless" wrapping for g-wrap, i.e. instead of using a dedicated C wrapper for each wrapped function creating an applicable smob that invokes a general marshaller which in turn calls the C function via libffi. This of course means a good amount of modifying/hacking g-wrap (Hi, Rob!), mostly to spit out all the necessary argument type information, so it can be used for marshalling. My main idea is to have each type have a flag that indicates it is "dynamic" (suggestions for better name welcome), which means that the type can be marshalled at runtime. Whenever all argument types on a wrapped function are dynamic, g-wrap will be able to spit out a bunch of conversion functions (c->scm, scm->c, c-destructor, ...) for each argument type along with a desciption of the argument types (basically function pointers to the conversion functions). This information then will be used by the marshaller. For a start, I plan to make all types that are generated by (gw:wrap-simple-type) dynamic. Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Python is executable pseudocode, Perl is executable line-noise.
Andreas Rottmann <a.rottmann@gmx.at> writes:
> [BTW: There seem to be two guile-gtk mailing lists ATM - I guess
> people should migrate to the one at GNU...]
>
> I'm ATM working at implementing "glueless" wrapping for g-wrap,
> i.e. instead of using a dedicated C wrapper for each wrapped function
> creating an applicable smob that invokes a general marshaller which in
> turn calls the C function via libffi.
Interesting. A couple of questions come to mind. First, how portable
is libffi? Will it cover all the existing architectures? Also, do we
know what the overhead's likely to be? I suppose the performance
argument could go either way when comparing to the existing approach
since the existing one-function-per-wrapper approach may well have
poorer interactions with the memory hierarchy. In any case, I do want
to preserve the ability for people who want to, to be able to have
close to minimal ffcall overhead using g-wrap. When calling from
interpreted languages, you may have a lot more leeway before you
noticably affect performance, but in the long run, I'm hoping guile
will also provide some form of compilation.
On a related front, I've decided to just use CVS at savannah, so I
should be setting that up over the next week (plus or minus -- I have
family coming to visit). It also probably makes sense to have a place
where those interested can discuss "what should happen next" with
g-wrap. I'm happy to have that discussion on an existing list if that
would be appropriate, or to create a new one. I've had some ideas I'd
like to discuss, and to compare and contrast (to the extent that they
overlap) with the above.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <rlb@defaultvalue.org> writes: > Andreas Rottmann <a.rottmann@gmx.at> writes: > >> [BTW: There seem to be two guile-gtk mailing lists ATM - I guess >> people should migrate to the one at GNU...] >> >> I'm ATM working at implementing "glueless" wrapping for g-wrap, >> i.e. instead of using a dedicated C wrapper for each wrapped function >> creating an applicable smob that invokes a general marshaller which in >> turn calls the C function via libffi. > > Interesting. A couple of questions come to mind. First, how portable > is libffi? Will it cover all the existing architectures? > At auric.debian.org: rotty@auric:~% madison libffi2 libffi2 | 1:3.0.4-7 | stable | alpha, arm, i386, ia64, m68k, powerpc, s390, sparc libffi2 | 1:3.3.2-0pre4 | testing | alpha, arm, i386, ia64, m68k, powerpc, s390, sparc libffi2 | 1:3.3.2-0pre4 | unstable | arm, m68k, powerpc, s390, sparc libffi2 | 1:3.3.2-0pre5 | unstable | alpha, i386, ia64 So libffi seems pretty portable. > Also, do we know what the overhead's likely to be? I suppose the > performance argument could go either way when comparing to the > existing approach since the existing one-function-per-wrapper > approach may well have poorer interactions with the memory > hierarchy. In any case, I do want to preserve the ability for > people who want to, to be able to have close to minimal ffcall > overhead using g-wrap. > I plan to make "glueless" wrapping an optional feature that you can turn on and off at your delight (at wrapper creation time, that is, of course). > When calling from interpreted languages, you may have a lot more > leeway before you noticably affect performance, but in the long run, > I'm hoping guile will also provide some form of compilation. > Yes, I'd like to see that, too. > On a related front, I've decided to just use CVS at savannah, so I > should be setting that up over the next week (plus or minus -- I > have family coming to visit). > Cool. I think that you can integrate GNU arch somehow with CVS, so if we are going to do multi-branch development (which CVS is poor at), we could have just the mainline in CVS and use arch for the harrier stuff I think. I've not yet very much looked into arch, but perhaps someone else here has real experience. > It also probably makes sense to have a place where those interested > can discuss "what should happen next" with g-wrap. I'm happy to > have that discussion on an existing list if that would be > appropriate, or to create a new one. I've had some ideas I'd like > to discuss, and to compare and contrast (to the extent that they > overlap) with the above. > Maybe guile-gtk is appropriate (the GNU one, /methinks), but I'm not the one to decide this and I'll be happy either way. Regards, Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62