Re: GTK modula-3 bindings



Michael Beach wrote:
>In other words, proxy objects. Sounds ok, but naturally you have to
>manage the interaction between Modula-3's GC and the gtk+ reference
>counting scheme. BTW is the Modula-3 GC conservative, or does it use
>tagged types, or none of the above?
That's the part I fear most.
I'm quite used to having the collector running by my side, cleaning up
my mess. I love it. I guess that's why the GTK team took the work to
implement this sort of garbage collection scheme for their C lib. They
love it too.
But when you get a real GC, it's more of a problem. It would be very
nice if it could be turned off somehow. Then I'd use traced references
and stop worrying.
Don't know much about the internals of garbage collectors (just let the
GC do its job), but according to the docs the SRC Modula-3 collector is
incremental, generational, VM-synchronized, and can run in a background
thread. I don't see the word 'conservative' anywhere. I'd like to know
why you ask this, and what does it imply.
Anyway, there's a whole set of procedures for tuning the collector
performance (enabling/disabling, turning on/off motion, starting the
background thread...).
>>really safe if I do so from m3? Will I be able to declare a base class
>>with just one data atribute (the ADDRESS that points to GTK struct) and
>>the corresponding suite of methods, and subclass that?
>Can't see why not.
That's how I'm doing. Proxy objects. The base class (GtkObjectImpl.T)
has an atribute called 'data' that is the GtkWidget untraced reference.
The 'public' base class (GtkObject.T) hides this from clients.
Everything else is methods and inheritance. I'm even trying to keep both
the procedural and the OO syntax, ie, "GtkWindow.Show(myWindow)" versus
"myWindow.show()". Don't have to code things twice, it's due to the way
m3 works.
Now I have even more questions :P
(this one mainly to the guys doing bindings to other languages) Someone
working with multithreaded languages? Modula-3 supports multithreading.
I just made GtkObjectImpl.T inherit from MUTEX (that's what the native
m3 window toolkit does), but would love to hear from someone who really
knows about concurrent programming.
In the 0.99.10 docs (still did not upgrade) there's an example in which
a button is added to a window in this way:
gtk_container_add (GTK_CONTAINER (window), button);
What happens with GTK's reference counting if I do this:
GtkContainer.From(window).add(button);
No casting in Modula-3. Hand made 'conversions'. GtkContainer.From()
will return a GtkContainer.T pointing to the *same* GtkWidget that
window points to. No new memory is created by GTK, so there's no
reference number increment, right? And no decrement when this temporary
object is collected?
Is there a way I can find out how many references point to a given
widget? I'll have to check all this very very carefully.
I see it's possible that I'm the only one in this list that codes in
Modula-3 (Ada may well follow, you know), so I'm grateful to you all for
giving me some of your time. Really.
-Daniel
ps: If you want to convert to m3, well... http://www.m3.org/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]