[Kde-bindings] Splitting up the SMOKE library

Dongxu Ma dongxu.ma at gmail.com
Wed Jul 18 14:47:03 UTC 2007


Hello Richard, CC: gents,

Beside object bus, how do you deal with allocation of Qt/Kde object ?
First I'd like to share you my progress on my QT4 Perl binding. Due to
personal issues, I recently didn't pay much time on coding...
The typemap system is almost finished. You can check here (
http://dongxu.googlecode.com/svn/trunk/PerlQT/script/create_typemap.pl)
The typemap, as you know in perl, is the repos for type marshalling between
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.
What I did in tha script is a knowledge study and relationship analyse
system. For above example, in case it knows QString is a QObject (obviously
from qstring.h), it automatically knows how to marshall QString *, QString
&, const QString, const QString * and QString const *. Furtherly
QList<QString *> is possible. It goes thru different aspects to find type
relationship ( class declaration, inheritance tree, namespace path,
pre-defined typemaps ).
It is powerful enough to bridge native Qt type with KDE type, custom type.

While the bad situation I am facing is GC system. Perl uses simple
reference, while ruby makes use of mark and sleep way. On the another hand,
generally, various cases may mess GC:
1) GC in Qt itself: Qt maintains its internal object reference status;
2) non-new method which exports an internal address,which will have the same
lifecycle of exporter;
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.
I'd like to hear your words on this question.

PS: boost python binding page also discussed similar issues. Go and take a
look.

cheers,
-dongxu


> Message: 2
> Date: Tue, 17 Jul 2007 13:19:02 +0100
> From: Richard Dale <rdale at foton.es>
> Subject: Re: [Kde-bindings] Splitting up the SMOKE library
> To: KDE bindings for other programming languages
>         <kde-bindings at kde.org>
> Message-ID: <200707171319.02329.rdale at foton.es>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Tuesday 17 July 2007, Ashley Winters wrote:
> > --- Thomas Moenicke <tm at php-qt.org> wrote:
> > > The kalyptus generator should generate the qt_Smoke instance in
> > > smokedata.cpp only for the Qt smoke, for KDE smoke it should have
> > > a kde_Smoke instance which has a pointer to qt_Smoke. In case the
> > > inline methods of kde_Smoke don't find the index they can ask the
> > > qt_Smoke before it returns 0.
> > > Thus we can create a hierarchy of dependencies and don't need to
> > > touch too much in the implementations:
> > >
> > > + qt_Smoke
> > > +--+ qwt_Smoke
> > > +--+ kde_Smoke
> > >     +--+ whatever_in_kde_Smoke
> > > +--+ qscintilla_Smoke
> > >
> > > I think this way would follow the design currently implemented in the
> > >
> > > bindings, but i would like to hear the opinion of Ashley though.
> >
> > Yeah, a single-inheritance hierarchy should work. You first search your
> > "local" copy of smoke, and if something's missing you forward the
> > search to your parent.
> >
> > I went through my old code to try and refresh my memory of the issues
> > with combining Smoke libraries. PerlQt had a class already written for
> > merging Smoke instances, but it was never made to work.
> >
> > and the SmokePerl class declaration (with comments) here:
> > http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.h
> >
> > And the implementation via the SmokePerlQt class here:
> > http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.cpp
> >
> > It seems I even implemented a Smoke API for loading multiple libraries
> > from within Perl:
> >
> >
> http://perlqt.cvs.sourceforge.net/*checkout*/perlqt/PerlQt-3/PerlQt/smokepe
> >rl.cpp?revision=1.1.2.16&pathrev=dev-3_0_0
> >
> > Apparently I went homeless before finishing that. It's too bad, cause
> > that was some good stuff. I can hardly remember how it works, now. :)
> >
> > From browsing through the code, it looks like smoke-qt and smoke-kde
> > didn't directly reference or inherit each other. They each filled in
> > the AUTOLOAD (method_missing for Perl) for the classes which they
> > respectively defined, and let the language method dispatcher handle
> > finding which class the method was defined in. Each class knew which
> > Smoke* object it came from, and each object knew which Smoke* it
> > belonged to.
> OK, I've had a read, and in fact some of that code is still in qtruby, and
> then ported to qyoto. But I didn't understand the 'hasFire()' method quite
> -
> why would only certain classes know which Smoke instance they belonged to?
>
> class SmokeClass {
> ...
>     bool hasFire() const { return !(flags() & Smoke::cf_undefined); }
>
> I think we just need a hash table called GlobalSmokeClasses
> of 'full_class_name => smoke instance' and load into it each time a new
> smoke
> module is loaded.
>
> When we look up a method for an instance we always provide the classname
> of
> the instance, and each instance already has which Smoke instance its class
> belongs to inside the 'smoke_perlobject' struct. So as long as we have the
> strings which give the names of superclasses that are not in the current
> Smoke instance, we can look them up the smoke instances of the parent
> classes
> when finding a method via the GlobalSmokeClasses hash. Then the classFn
> for a
> particular method won't always be in the same Smoke instance that the
> ruby/perl/csharp/php instance belongs to as now. But the code to call a
> method would be much the same.
>
> I don't think a particular Smoke module has to know which parent modules
> it
> has, only the individual classes need to know what their parent class
> names
> are as strings.
>
> Virtual method callbacks will need to have methods that are not in the
> current
> smoke module, but as far as I can see that should work ok at runtime, and
> it
> just makes the code generation harder.
>
> -- Richard
>



-- 
http://search.cpan.org/~dongxu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20070718/0b36792b/attachment.html>


More information about the Kde-bindings mailing list