[Kde-bindings] Readable GCC dump parser

[Richard Dale]

On Sunday 03 August 2003 20:50, Ashley Winters wrote:
> --- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> > On Saturday 02 August 2003 21:07, Ashley Winters wrote:
> > > --- Alexander Kellett <lypanov at kde.org> wrote:
> > > > On Sat, Aug 02, 2003 at 03:21:36PM +0200, Alexander Kellett
> >
> > wrote:
> > > > > okay. just to check if i've got this right.
> > > > > kalyptus would be partially replaced by this
> > > > > then smoke would be modified to use the xml api.
> > > > > and in principle perlqt/kde and *ruby would not
> > > > > really require all that much work other than a
> > > > > few namespace changes and a ton of data type
> > > > > (de)marshallers?
> > >
> > > I want to split Smoke into 2 pieces, effectively into Smoke and a
> > > Mirror.
> >
> > Good name! Light bouncing off a mirror is like a message being
> > redirected by a
> > proxy instance. Don't know what it stands for though - so many R's..
> > 'Message
> > Invocation Redirection..' um er..
>
> That is alot of R's. I need a dictionary for that one.
'Resource', 'Resolution' so far

> Okay, here's how it'll work. This is tentative, of course, but I'm
> probably going to go whole-hog w3 style with it.
>
> The Mirror libraries will take every function in Qt and KDE and make
> them accessible through C function pointers with predictable symbol
> names in the Mirror library. Instead of trying to do name mangling, I'm
> moving in the other direction: name elaboration. Every function gets an
> absurdly long and exacting name which can be preserved across versions.
>
> So, how will this work? *steals from the w3*
>
> Okay, every thing will have a URL which uniquely identifies it. For
> example, QWidget::resize(int, int) will be:
>
> http://trolltech.com/api/qt/method/QWidget/resize?int%2cint
>
> Yes, I'm serious! The point of that URL is to be able to get a function
> pointer from the Mirror library that will let us call that method
> exactly. Lets say we use md5 as the symbol name format for doing that.
> When we want to call QWidget::resize(int, int), the Smoke library will
> conjure up that URL; it has more than enough information to generate it
> at runtime if we want it to. It will stick that URL through an md5sum
> generator and arrive at 128e48bb22c40e48d8acd3b1e5570671 as the symbol.
>
> So, here's where the voodoo comes in. Imagine we're Smoke or some other
> Mirror client:
>
> typedef void (*fptr)(void*, int, int);
> fptr f = (fptr)dlsym(mirror_qt, "128e48bb22c40e48d8acd3b1e5570671");
> f((void*)self, width, height);
>
> With that voodoo, we've gone from an automatically generated URL, to a
> symbol name, to a C function pointer, to a call to resize(). The symbol
> names are knowable at /compile/ time, so usage of the mirror library is
> not restricted to dynamic languages like Perl/Ruby/etc. If JavaQt
> wanted to call QWidget::resize, it could use the exact same method at
> compile time to deterministically derive the C symbol it needed to
> call.
>
> For virtual methods, there would be a different URL set for setting
> method overrides.
>
> http://kde.org/api/kdeui/virtual/KListBox/leaveEvent?QEvent%2a
>
> That returns a function pointer which allows you to CHANGE the function
> called for leaveEvent. Of course, first you'd have to allocate a new
> vtbl for KListBox, like so...
>
> http://kde.org/api/kdeui/virtual/KListBox?sizeof
> http://kde.org/api/kdeui/virtual/KListBox?init
>
> So whenever you derived a subclass from KListBox, you'd allocate and
> initialize a new vtbl for your class with those two functions, and use
> the previously listed URL to change the delegate pointer called by that
> vtbl for it. PerlQt probably wouldn't try to change those functions
> individually, but rather would change them all and decide for itself
> when to delegate them to Perl.
>
> > > The "flaw" in Smoke's design is that it never forces Qt to work
> >
> > down at
> >
> > > the lowest-common-denominator, C. It works at a higher level, which
> >
> > is
> >
> > > all I needed for dynamic language like Perl (and, it seems, without
> > > modification for Ruby).
> >
> > I think that was only a flaw for C# which had 'magic marshalling' for
> > a C api
> > or something. For other languages you could use the simple existing
> > SMOKE
> > interface with C wrappers.
>
> Parrot has magic marshalling as well. As does Ruby, if I recall.
> Python, too.
>
> The fact that Perl doesn't is to Perl's disadvantage in the grand
> scheme of things. Regardless, I'm embracing the C
> lowest-common-denominator.
I think magic marshalling might make a small scale project easier, but I'm not 
convinced it would be worth the extra code bloat. Adapting the PerlQt 
marshalling for QtRuby only took about a day.

> > I think there are at least five sorts of languages (I'm personally
> > really only
> > really interested in the first two categories):
> >
> > 1 - Fully dynamic - perl, python, ruby, Smalltalk
> >
> > 2 - Semi dynamic - java, C#, Objective-C
> >
> > 3 - Semi dead - C++ with moc
> >
> > 4 - 'Dead' :) - Eiffel, Ada, Object Pascal, FORTRAN
> >
> > 5 - 'Weird' - Haskell, prolog
> >
> > For, type 1 languages we're already there, just need a kde version
> >
> > For type 2 languages, I'm not sure if all of smoke could be used or
> > just the
> > mirror part. For java, to use that message forwarding part of smoke,
> > it would
> > mean creating the complete class hierarchy as dynamic Proxy
> > interfaces. Don't
> > know if that's technically possible, but it would be fun finding out.
>
> I would expect that Smoke would be optional for the type 2 languages.
> Java/C# would likely want to do everything at compile-time for the
> speed advantage, as well as the fact that they have method overloading
> which their compilers can resolve at compile-time. I would expect them
> to use Mirror alone, by default.
I think that was what I was intending to do, until I implemented the smoke 
adaptor for ruby. A big advantage to me now is that I can see it will be easy 
to make it possible for PerlQt and QtRuby so share and subclass each others 
Qt instances via 'bridge extensions'. So if java could be implemented 
dynamically, it would make it easier to to share the runtime with perl and 
ruby.

> > Objective-C is really just as dynamic as Smalltalk, but the
> > distinction for
> > bindings writing is that you need to generate a header files for the
> > Objective-C proxy classes, if you want to avoid a load of compile
> > errors.
> > Those two languages also need the argument names to construct the
> > equivalent
> > of a method name, which the current SMOKE runtime doesn't have.
>
> ObjC uses argument names as part of the method signature? Wow.
Here's an example of what the current Objective-C wrappers look like:

- invokeMailer: (NSString *)to cc: (NSString *)cc bcc: (NSString *)bcc 
subject: (NSString *)subject body: (NSString *)body messageFile: (NSString 
*)messageFile attachURLs: (NSArray *)attachURLs
{
static qt_QStringList * _qlist_attachURLs = 0L;
static qt_QString * _qstring_messageFile = 0L;
static qt_QString * _qstring_body = 0L;
static qt_QString * _qstring_subject = 0L;
static qt_QString * _qstring_bcc = 0L;
static qt_QString * _qstring_cc = 0L;
static qt_QString * _qstring_to = 0L;

	kde_KApplication_invokeMailer2((kde_KApplication *)[self qt],
 (qt_QString *) [to toQString: &_qstring_to],
 (qt_QString *) [cc toQString: &_qstring_cc], 
(qt_QString *) [bcc toQString: &_qstring_bcc], 
(qt_QString *) [subject toQString: &_qstring_subject], 
(qt_QString *) [body toQString: &_qstring_body], 
(qt_QString *) [messageFile toQString: &_qstring_messageFile], 
(qt_QStringList*) [attachURLs toQStringList: (void *)&_qlist_attachURLs]);
	return self;
}

So the name of this method is actually 
'-invokeMailer:cc:bcc:subject:body:messageFile:attachURLs:'
Phew!

We Objective-C programmers just can't get enough typing done :)

So it looks like I would need to replace kde_KApplication_invokeMailer2() call 
with a mirror URI type thing.

> > > So, the new Smoke will take an XML API for Qt/KDE/Whatever and
> >
> > flatten
> >
> > > it out into a C library, and then provide a separate library to
> >
> > make it
> >
> > > accessible through marshallers and such to dynamic languages like
> > > Perl/Ruby/Python.
> >
> > Well, as long as it doesn't end up too huge.
> >
> :)
>
> I've definitely gone off the deep-end, now. No doubt about it.
Swimming well so far!

-- Richard