Re: lgtk-0.0.3 - experimental gtk bindings for Common Lisp

John Morrison <[email protected]> writes:
> > As an alternative, I like the probing approach from sb-grovel better:
> > produce c/c++ probes that print out the info you want, do what you
> > can't achieve this way either by hand or by ad-hoc glue generation.
> 
> The C++ software I am trying to "bind" to or call is very, very, very
> large (in terms of SLOC).  Certainly well over 1MSLOC.  Thus, I was
> trying very, very hard to automate the process.

This clearly is another situation than that of lgtk, which can take
time to grow. I hope other people do contribute bindings too, so the
current non-automatic nature of the process does not hit too hard.

> Aside from the
> obvious difficulties, "ld" (or linking time) for building an
> application can be measured in minutes rather than seconds.
> 
> I confess to being unfamiliar with sb-grovel.  Do you think
> sb-grovel's "try it" approach would scale to this kind of problem?

The only thing I know about sb-grovel is the approach, and I have seen
it in use. It seems to work fairly well. sb-sockets uses it; osicat
too.

If for every single thing you want to find out you bild a program, I
don't think it will scale. But if only one program gathers al the
probes, then I don't see why it wouldn't.

> > I've heard from people trying to use gccxml that it disregarded so
> > much vital information (I don't remember the details) so that it was
> > essentially useless for this. But things might have changed, so don't
> > hesitate to find out and tell us ;-)
> 
> Eeek.  Is it possible to obtain a URL to the discussion?  I would like
> to spare myself a Don Quixote style bout with a windmill, if indeed
> gccxml is a futile approach.

It was a personal communication. I dug up an old mail of that
exchange, and the problems were that it sometimes reordered the slots
of a struct, and that it lost the names of variables in function
declarations (this makes sense when parsing a header - variable names
in prototypes are essentially redundant - but is disapointing if you
want to write bindings).

I asked him again, and he replied that the main reason was that he
found swig. So maybe my memories weren't too accurate. The email
exchange is from may '03.

> > int some_function (char *fname);
> > int another_function (char *str);
> >
> > You want a different wrapper for the first one (that is able to cope
> > with cl pathnames) than for the second. You will need some fairly
> > advanced AI if you want this to happen automagically (and correctly!).
> 
> Well, I would rather try to write that kind of smart code in Lisp
> (say, after interning a rather large amount of XML in Lisp data
> structures) rather than C++ (say, in a SWIG back-end, or in a C++ XML
> program).

I really wonder how you would go about it. I don't think it is
possible to do this in a reliable way. :-|

> I just wish that there were return value information stored in the
> object files.  If there were, a ridiculously simple script using the
> output of "nm" would suffice.  So near, and yet so far...

How about the type of the arguments? 

Btw, the R developers seem to have modified lcc to be able to get at C
data structs, etc:

http://www.omegahat.org/Slcc/man/Slcc/html/lcc.html

Regards,
        Mario.