[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: [Kde-bindings] Splitting up the SMOKE library
From: "Dongxu Ma" <dongxu.ma () gmail ! com>
Date: 2007-07-18 14:47:03
Message-ID: 9bc0d5d20707180747m39b761f4re9c2a89afe424b36 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@foton.es>
> Subject: Re: [Kde-bindings] Splitting up the SMOKE library
> To: KDE bindings for other programming languages
> <kde-bindings@kde.org>
> Message-ID: <200707171319.02329.rdale@foton.es>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tuesday 17 July 2007, Ashley Winters wrote:
> > --- Thomas Moenicke <tm@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
[Attachment #5 (text/html)]
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 personal issues, I recently didn't pay much time on coding... \
<br>The typemap system is almost finished. You can check here (<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 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. \
<br>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 ). <br>It is powerful enough to bridge \
native Qt type with KDE type, custom type.<br><br>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: <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 same lifecycle of exporter;<br>3) non-new method \
which returns a new heap address, which transfers the ownership of that pointer to \
caller; <br>4) non-new method which accepts a pointer and takes the ownership of that \
pointer;<br><br>Either case will leak the vm unless treating it carefully.<br>I'd \
like to hear your words on this question. <br><br>PS: boost python binding page also \
discussed similar issues. Go and take a look. \
<br><br>cheers,<br>-dongxu<br><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>Message: 2<br>Date: Tue, 17 Jul 2007 13:19:02 +0100 <br>From: \
Richard Dale <<a href="mailto:rdale@foton.es">rdale@foton.es</a>><br>Subject: \
Re: [Kde-bindings] Splitting up the SMOKE library<br>To: KDE bindings for other \
programming languages<br> <<a \
href="mailto:kde-bindings@kde.org"> kde-bindings@kde.org</a>><br>Message-ID: \
<<a href="mailto:200707171319.02329.rdale@foton.es">200707171319.02329.rdale@foton.es</a>><br>Content-Type: \
text/plain; charset="iso-8859-1"<br><br>On Tuesday 17 July 2007, \
Ashley Winters wrote: <br>> --- Thomas Moenicke <<a \
href="mailto:tm@php-qt.org">tm@php-qt.org</a>> wrote:<br>> > The kalyptus \
generator should generate the qt_Smoke instance in<br>> > smokedata.cpp only \
for the Qt smoke, for KDE smoke it should have <br>> > a kde_Smoke instance \
which has a pointer to qt_Smoke. In case the<br>> > inline methods of kde_Smoke \
don't find the index they can ask the<br>> > qt_Smoke before it returns \
0.<br>> > Thus we can create a hierarchy of dependencies and don't need to \
<br>> > touch too much in the implementations:<br>> ><br>> > + \
qt_Smoke<br>> > +--+ qwt_Smoke<br>> > +--+ kde_Smoke<br>> \
> +--+ whatever_in_kde_Smoke<br>> > +--+ \
qscintilla_Smoke <br>> ><br>> > I think this way would follow the design \
currently implemented in the<br>> ><br>> > bindings, but i would like to \
hear the opinion of Ashley though.<br>><br>> Yeah, a single-inheritance \
hierarchy should work. You first search your <br>> "local" copy of \
smoke, and if something's missing you forward the<br>> search to your \
parent.<br>><br>> I went through my old code to try and refresh my memory of \
the issues<br>> with combining Smoke libraries. PerlQt had a class already written \
for <br>> merging Smoke instances, but it was never made to work.<br>><br>> \
and the SmokePerl class declaration (with comments) here:<br>> <a \
href="http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.h"> \
http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.h</a><br>><br>> \
And the implementation via the SmokePerlQt class here:<br>> <a \
href="http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.cpp"> \
http://search.cpan.org/src/GGARAND/PerlQt-3.008/PerlQt/smokeperl.cpp</a><br>><br>> \
It seems I even implemented a Smoke API for loading multiple libraries<br>> from \
within Perl:<br>><br>> <a \
href="http://perlqt.cvs.sourceforge.net/*checkout*/perlqt/PerlQt-3/PerlQt/smokepe"> \
http://perlqt.cvs.sourceforge.net/*checkout*/perlqt/PerlQt-3/PerlQt/smokepe</a><br>>rl.cpp?revision=1.1.2.16&pathrev=dev-3_0_0<br>><br>> \
Apparently I went homeless before finishing that. It's too bad, cause <br>> \
that was some good stuff. I can hardly remember how it works, now. :)<br>><br>> \
From browsing through the code, it looks like smoke-qt and smoke-kde<br>> \
didn't directly reference or inherit each other. They each filled in <br>> the \
AUTOLOAD (method_missing for Perl) for the classes which they<br>> respectively \
defined, and let the language method dispatcher handle<br>> finding which class \
the method was defined in. Each class knew which <br>> Smoke* object it came from, \
and each object knew which Smoke* it<br>> belonged to.<br>OK, I've had a read, \
and in fact some of that code is still in qtruby, and<br>then ported to qyoto. But I \
didn't understand the 'hasFire()' method quite - <br>why would only \
certain classes know which Smoke instance they belonged to?<br><br>class SmokeClass \
{<br>...<br> bool hasFire() const { return !(flags() & \
Smoke::cf_undefined); }<br><br>I think we just need a hash table called \
GlobalSmokeClasses <br>of 'full_class_name => smoke instance' and load \
into it each time a new smoke<br>module is loaded.<br><br>When we look up a method \
for an instance we always provide the classname of<br>the instance, and each instance \
already has which Smoke instance its class <br>belongs to inside the \
'smoke_perlobject' struct. So as long as we have the<br>strings which give \
the names of superclasses that are not in the current<br>Smoke instance, we can look \
them up the smoke instances of the parent classes <br>when finding a method via the \
GlobalSmokeClasses hash. Then the classFn for a<br>particular method won't always \
be in the same Smoke instance that the<br>ruby/perl/csharp/php instance belongs to as \
now. But the code to call a <br>method would be much the same.<br><br>I don't \
think a particular Smoke module has to know which parent modules it<br>has, only the \
individual classes need to know what their parent class names<br>are as strings.<br> \
<br>Virtual method callbacks will need to have methods that are not in the \
current<br>smoke module, but as far as I can see that should work ok at runtime, and \
it<br>just makes the code generation harder.<br><br>-- Richard \
<br></blockquote></div><br><br clear="all"><br>-- <br><a \
href="http://search.cpan.org/~dongxu">http://search.cpan.org/~dongxu</a>
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic