<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>On Thursday 19 July 2007, Dongxu Ma wrote:<br>> >On Wednesday 18 July 2007, Dongxu Ma wrote:

<br>> >> Hello Richard, CC: gents,<br>> >><br>> >> Beside object bus, how do you deal with allocation of Qt/Kde object ?<br>> >> First I'd like to share you my progress on my QT4 Perl binding. Due to

<br>> >> personal issues, I recently didn't pay much time on coding...<br>> >> The typemap system is almost finished. You can check here (<br>> >> <a href="http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl">

http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl</a>)<br>> >> The typemap, as you know in perl, is the repos for type marshalling<br>><br>> between<br>><br>> >> perl and c++ plants. While the old typemap mechanism introduced by

> >> ExtUtil.pm is somewhat out of date, it has no knowledge about > > relationship > > >> between relevant types. Say, for instance, QString and QString *. > >> Typemap simply treats them as un-relevant ones.

<br>> >> What I did in tha script is a knowledge study and relationship analyse<br>> >> system. For above example, in case it knows QString is a QObject<br>><br>> (obviously<br>><br>> >> from 

qstring.h), it automatically knows how to marshall QString *,<br>><br>> QString<br>><br>> >> &, const QString, const QString * and QString const *. Furtherly<br>> >> QList<QString *> is possible. It goes thru different aspects to find

<br>> >> type relationship ( class declaration, inheritance tree, namespace path,<br>> >> pre-defined typemaps ).<br>> >> It is powerful enough to bridge native Qt type with KDE type, custom<br>

><br>> type.<br>><br>> >Well I think we already have this sort of thing in the Smoke libs, and we<br>><br>> have<br>><br>> >a parser written in perl with powerful abstract syntax tree utilities for

<br>> >walking round the parse tree.<br>><br>> Nice. I used to have a look at Smoke, the output is quite programmatic look<br>> (in C),<br>> that is one of the primary reasons I'd like to write QTEDI, which presents

<br>> in more<br>> human-readable style. While that doesn't mean Smoke is ugly, really depends<br>> on<br>> how people make use of.<br>Well I don't think that being able to read the autogenerated code is all that

<br>important. Nobody is going to read 1000s of lines of yaml either. You can<br>introspect the smoke lib to ask what classes and methods it has though, which<br>is certainly useful, and something you can't do in any other language binding

library as far as I know.</blockquote><div> Point here is not only readability, but also the chance to patch at certain point. I can also develop nice tool to query, I'd also like to have enough place to apply patch. The opportunity is open for new maintainer too.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> >> While the bad situation I am facing is GC system. Perl uses simple

<br>> >> reference, while ruby makes use of mark and sleep way. On the another<br>><br>> hand,<br>><br>> >> generally, various cases may mess GC:<br>> >> 1) GC in Qt itself: Qt maintains its internal object reference status;

<br>> >> 2) non-new method which exports an internal address,which will have the<br>> >> same lifecycle of exporter;<br>> >> 3) non-new method which returns a new heap address, which transfers the

> >> ownership of that pointer to caller; > >> 4) non-new method which accepts a pointer and takes the ownership of > >> that pointer; > >> > >> Either case will leak the vm unless treating it carefully.

<br>> >> I'd like to hear your words on this question.<br>> ><br>> >The Smoke bindings have a struct like this:<br>> ><br>> >struct smokeqyoto_object {<br>> >   bool allocated;<br>

> >    Smoke *smoke;<br>> >   int classId;<br>> >   void *ptr;<br>> >};<br>> ><br>> >Where 'allocated' is true if the instance was created in the bindings<br>> >language, and so the bindings runtime is responsible for deleting the C++

<br>> >instance on garbage collection.<br>> ><br>> >The bindings runtime needs to know about the various rules of object<br>><br>> ownership<br>><br>> >in the Qt libraries such as the QObject object tree where a parent 'owns'

<br>><br>> its<br>><br>> >children and is responsible for deleting them.<br>> ><br>> >The QtJambi bindings have a third state, which is 'not owned by either c++<br>><br>> or<br>><br>

> >the bindings language'.<br>><br>> The hard point here is the handover of object relationship is really case<br>> by case.<br>> The metaobject system in Qt is mainly based on class inheritance hierarchy.

<br>> That doesn't really work for the case: the instance exports an inner part<br>> (note<br>> that such part is in-a-class, not is-a-class); while other method may<br>> export a<br>> component of itself, which is certainly a standard QObject, and release the

<br>> ownership of that component to caller; From my point of view, it is very<br>> hard to<br>> tell such two different cases automatically.<br>> Another example to address one of my previous points: say, one creates a

<br>> new<br>><br>> QObject in binding code, then QObject is owned by binding code till a<br>> special<br>> method is invoked, which takes that QObject as parameter and finally 'eats'<br>> it.<br>

> That dedicated QObject is taken over by Qt metaobject after the call,<br>> regarding<br>> its lifecycle.<br>> You can find such method somewhere inside Qt (sorry, I don't remember the<br>> class<br>> name but I am pretty sure it has).

> The issue here is Qt metaobject system doesn't offer any callbacks on the > events > of importing/exporting a child. A message bus between Qt and bindings. > There is QObjectCleanupHandler, not very helpful in this paticular case.

<br>> Things go more complex if we start talking about non-meta classes (which is<br>> declared without Q_OBJECT macro). This side is completely out of control<br>> from<br>> Qt metaobject system.<br>Yes,  there is an internal method for monitoring changes in QObject parents

<br>via events. From qyoto.cpp:<br><br>QInternal::registerCallback(QInternal::EventNotifyCallback,<br>qyoto_event_notify);<br><br>Then qyoto_event_notify() is sent events:<br><br>static bool<br>qyoto_event_notify(void **data)

<br>{<br>    QEvent *event = (QEvent *) data[1];<br><br>        // If a child has been given a parent then make a global ref to it, to<br>prevent<br>        // garbage collection. If a parent has been removed, then remove to global

ref         // to the child also.         if (event->type() == QEvent::ChildAdded || event->type() == QEvent::ChildRemoved) { ...</blockquote><div> Great, I really didn't notice that! But as I said this mechanism only works for meta-lized QObject.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> >> PS: boost python binding page also discussed similar issues. Go and take

<br>><br>> a<br>><br>> >> look.<br>> ><br>> >What will it tell us that we don't already know, and what do you think is<br>> >wrong with out existing approaches?<br>><br>> Trust me, I am really not arguing current kde-bindings' implementation ;-)

<br>> Please don't treat me like an enermy ;D<br>> I pay my enough respect to you guys behind this maillist, indeed.<br>> Noticed that recently there was a post saying different words on<br>> <a href="http://kdeveloper.org">

kdeveloper.org</a>. > I think the author was quite friendly and really wanted to bring new ideas > in. > Things are always improved by questions and innovations. > We can keep walking on each own way but we can share our thoughts, right ?

<br>Sorry if I sounded rude. It's more that I'm not sure if you've studied the<br>code for the existing Qt bindings enough. Unless you can understand what they<br>do, and how they do it, then it will be very difficult to design something

better. You'll probably just end up re-inventing what we already have. So maybe boost python have done something none of the bindings authors (ie the QtJambi, PyQt, QtRuby, PerlQt, Qyoto and PHPQt authors) have thought of.

</blockquote><div><br>Yes, that's probaly true. Sorry I haven't read much code of Smoke and Qt. To be honest I dislike the look of Smoke output, which is totally C++ code. Very hard to analyse for a new comer.. <br>

To my project, I am not sure how far it can go, try my best to make it better. <br></div>Keep your speed too :-)<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> >Note that the subject of this thread is 'splitting up the smoke libraries'<br>><br>> -<br>><br>> >please can you start a new thread to discuss anything which isn't about<br>><br>> that

> > >topic? > > Sorry, that topic triggered me yesterday. OK, no problem - it just easier for people to follow the history of the discussion in the if we can keep the threads a bit self contained.

<br><br>-- Richard<br></blockquote></div><br>-- <br>cheers,<br>-dongxu<br>__END__<br><a href="http://search.cpan.org/~dongxu">http://search.cpan.org/~dongxu</a>