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

John Morrison <[email protected]> writes:
> On Tuesday 04 November 2003 12:25 pm, Mario Mommer wrote:
> > 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
> 
> Ouch.  That can't be good.  I have to assume it's an Official Bug --
> something that would render the program suspect if not useless...

In any case, this should be checked independently. Not that I distrust
this friend of mine, but maybe there where other bugs ailing him, or
the gccxml team has fixed this, etc.

BTW, there are ways around it. Once you have the names of the slots,
you can get the offsets by compiling a C program that does something
like

        struct_name instance;
        printf("%d\n",((int)&instance.slot)-((int)&instance));

You can sort according to this, or generate accessors that use pointer
arithmetic (I'm tinkering on the last approach to generate slot
accessors for speciffic slots only without having to declare all the
others)

> > declarations (this makes sense when parsing a header - variable names
> > in prototypes are essentially redundant - but is disapointing if you
> > want to write bindings).
> 
> That's too bad.  They can be important clues...

I rememebered now what gave the last stroke to gccxml: constants. A
parser only gets what the preprocessor leaves behind, and thus it
never sees #defined constants. This means that you have to get them in
a different way, which is just another rather large disapointment.

> > 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.
> 
> Funny how I'm headed the other direction.  The grass is always greener
> on the other side of the fence, I suppose...

It seems this is a fairly rugged terrain with a lonely fence :-)

> Do you know if he ran into the same killer problems I hit?

He got distracted by other things and never tried it out.

> > How about the type of the arguments?
> 
> Those are obtained by:
> (1) getting the C++ "mangled" name from "nm"
> (2) passing the "mangled" name into "c++filt"

This is interesting indeed.

A strange Idea I had yesterday while going home: how about parsing the
documentation? It might be in a more friendlier format. I think
parsing the gtk/gdk/etc docs is in fact easier than parsing the
headers. One could use all available methods (probing, gccxml, parsing
the docs, c++filth, swig) to get a fairly high accuracy and to
identify the harder problem cases.

Is this just crazy?

Regards,
        Mario.