[Kde-bindings] Readable GCC dump parser

[Ashley Winters]

--- 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.

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 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.

> 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.

> > 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.

Ashley Winters

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com