Subject: Re: wrapping primitives in cecil
From: Craig Chambers (chambers@cs.washington.edu)
Date: Tue Apr 23 2002 - 15:28:31 PDT
No, there is no finalization method called, although it's been on the
nice-to-have-someday list for a while. (The underlying GC should already
support it.)
As for call-backs, the motif.cecil file, ugly though it is, contains some
examples of saving Cecil objects into global variables that C code can then
access. There is some extra work if you're using accurage (copying) GC, but
that only applies for the Sparc asm back-end. Normally, all you need is to have
a C global variable that points to your call-back Cecil object, so that the
conservative GC still sees the object as live. Maybe you're storing the only
references to the Cecil object into a part of the C heap that's not exposed to
the conservative GC system?
Good luck!
-- Craig
Thorsten Seitz wrote:
>
> Thank you very much for your help! It worked very nicely.
>
> Might I bother you with another (short) question and another (long)
> problem?
>
> The question: is there a finalize method which gets called before an
> object is garbage collected?
>
> The problem:
> When I try to register a callback (on the C-side), the registered
> Cecil-object seems to be invalid (moved by the gc?) when I later try to
> call a method on it (from the C-side).
>
> The following excerpt from the code illustrates the problem:
>
> 01 representation Object subtypes Object;
> 02 field obj (@:Object): OOP; -- the wrapped C-Object
> 03
> 04 prim c_++ {
> 05 PairType __dummy_return; -- ?? hack
> 06 void signal_callback (GtkObject *o, void* action) {
> 07 EnvOOP currentEnv; -- ?? hack
> 08 OOP a, ignored_result;
> 09 ReturnCode rc;
> 10 SEND_NO_PROP (ignored_result,
> 11 rc, a, eval, 0, 1, ((OOP)action),
> 12 "1#signal_callback(o,data)");
> 13 }
> 14 };
> 15
> 16 method on_signal_do (
> 17 sender@:Object, t@:Object, s:string, a:&():void): void
> 18 {
> 19 gtk_on_signal_do (t.obj, s, a)
> 20 }
> 21 private method gtk_on_signal_do (
> 22 o:OOP, signal:string, action:&():void): void
> 23 (** formals_escape(t, f, t) **)
> 24 {
> 25 prim c_++ {
> 26 gtk_signal_connect (
> 27 GTK_OBJECT (asObj (o)),
> 28 AS_C_STRING (signal),
> 29 GTK_SIGNAL_FUNC (signal_callback), -- call this when
> button gets pressed
> 30 (void*)(action)); -- give this pointer to the
> callback
> 31 }
> 32 }
>
> The following method creates a new button and registers a closure as
> callback.
>
> method new_button (l@:string, a:&():void): Button {
> let button: Button := object isa Button {
> label := l,
> action := a,
> obj := gtk_new_button (l)
> };
> button.on_signal_do (button, "clicked", a); -- register callback
> button
> }
>
> When the button gets pressed the C-function signal_callback (defined in
> line 06) gets called. The evaluation of the closure fails:
>
> ** Error: message "execute" with 2 args not understood.
> Called as:
> Uøj, <anon/i_vector/: 0x8641fc9>)
>
> Current stack frame:
> Uøj), bc-eval.cecil:314
>
> The pointer to the closure is given correctly to the callback (I've
> verified this with printf), but the contents of the memory at that
> location is changed. I would have guessed that the pragma (**
> formals_escape(t, f, t) **) would ensure that the pointer remains
> stable.
>
> Calling the callback just after registering (i.e. immediately after line
> 30 from within the primitive) does work as expected: the closure is
> executed.
>
> Do you have an idea what I'm doing wrong? The two hacks (marked with --
> ?? hack) might be responsible. I don't know how to fix those correctly.
>
> Best regards
> Thorsten
>
> Craig Chambers wrote:
> > You can't use Cecil-like expressions within primitive blocks; the code there is
> > raw C++. You also can't treat a primitive block like an expression; it's just a
> > sequence of statements.
> >
> > There are macros that can be used in the C++ body of a prim statement that let
> > you do things like send messages and return. But for the show method, the
> > easiest thing to do is to have show first send the w.gtk message in regular
> > Cecil code, then call a helper method passing the result of the message as an
> > argument, e.g.
> >
> > show (w@widget) { w.show_helper(w.gtk); }
> > show_helper (w@widget, gtk) { prim c_++: "gtk_widget_show (gtk);"; }
> >
> > The RETURN (or some variation, I don't recall exactly what is allowed) macro can
> > be used to return the result of the gtk_window_new function call. Look at the
> > existing prim methods to get ideas for what's possible.
> >
> > -- Craig
> >
> >
> > Thorsten Seitz wrote:
> > >
> > > Hi,
> > >
> > > I'm trying to write a small GUI library in Cecil. The library shall use
> > > GTK+ (a GUI library written in C) internally.
> > >
> > > Now comes the big question: how can I wrap a GTK+ primitive object in a
> > > Cecil object?
> > > I'd like to do something like:
> > >
> > > object Widget;
> > > field gtk (w@widget);
> > > show (w@widget) { prim c_++: "gtk_widget_show (w.gtk);"; }
> > >
> > > object Window;
> > > new_window (w@int, h@int): Window {
> > > object isa Window { gtk := prim c_++: "gtk_window_new (w, h);"; }
> > > }
> > >
> > > This was probably too naive, for it won't work :-)
> > > The problem in "show" seems to be that w.gtk is not known on the
> > > primitive level and in "new_window" that the return value is not
> > > correct.
> > >
> > > What would be the correct way to do something like this? I tried to find
> > > out by looking at the source of motif.cecil, file.cecil etc. but didn't
> > > come very far.
> > >
> > > Thanks for any help!
> > >
> > > Best regards
> > > Thorsten
> > >
> > > _______________________________________________
> > > Cecil mailing list
> > > Cecil@cs.washington.edu
> > > http://majordomo.cs.washington.edu/mailman/listinfo/cecil
> >
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Tue Apr 23 2002 - 16:28:59 PDT