On Mon, Aug 23, 2004 at 12:14:51PM +0200, Leopold Toetsch wrote:
> Leopold Toetsch wrote:
> >Stephane Peiry wrote:
> >
> >>>>>> g_return_val_if_fail (G_IS_OBJECT (gobject), 0); <<<< Fails here
>
> >gtk shouldn't make assumption on the user_data argument IMHO.
[...]
> call is NULL, because of the same check, G_IS_OBJECT(gobject).
mh.. ok, this whole thing made me try the following, and that is actually
sticking to what I do really understand about nci and function signatures
for parrot. Currently the signature is 'lptpPi'
dlfunc P2, P1, 'g_signal_connect_object', 'lptpPi'
and Ive placed P in there for the user data mainly because of the example
taken from the t/pmc/nct.t tests and I thaught that well.. that would do
the "right thing" :) Now I would have otherwise written the function sig
as 'lptppi'
dlfunc P2, P1, 'g_signal_connect_object', 'lptppi'
as thats what gtk really wants, a pointer to the user data, and for sure
"p" will give it exactly that.
Doing so, gtk doesnt complain anymore, it goes onto creating the window,
the button, installing the callback (by calling this g_signal..) without
problems and shows the window and button.
So now gtk is "happy" but parrot isnt: if I hit the button, it goes onto
calling callback in parrot, and he breaks with:
Parrot VM: PANIC: callback_info doesn't look like a pointer!
C file src/inter_cb.c, line 132
(as I understand it, by having "p" on the signature for the user data,
gtk gets what it wants, a pointer to the user data, but parrot doesnt
like it because once it gets it, it doesnt get it wrapped into a PMC?
otoh, if P is used then its gtk not happy because it wants a pointer
rather than a - pmc - struct?.. how wrong is this view?)
> *If* that is solved then the next problem is of course that by calling
> gtk_main() the GTK event loop is running. That means, while
> Parrot_callback_C() would get called, the callback fuction itself
> wouldn't get run because Parrot isn't executing any code at that point.
> Parrot is stuck in the NCI call to gtk_main().
mh.. thats was not the way I understood callbacks were implemented.
I mean understood from this thread (*):
[1] pdd16 states:
Hand over control to the external library. IT IS
IMPORTANT THAT THE INTERPRETER YOU ARE CALLING BACK
INTO IS NOT ACTIVE WHEN THE CALLBACK IS MADE!
As we don't know, when the callback is invoked, my scheme uses an event
so that its safe to run the PASM code.
that callbacks were indeed installed through an event (that is on its own
thread) so that it wouldnt block nomatter what parrot would be doing at a
given point (say it invoked some long running function in a lib :) unless
there would be a lock on the user data itself.
Otherwise, already thaught of actually unrolling the gtk_main function
and have it handled/implemented within parrot directly (mainly gtk_main
simply loops and waits on the gtk event queue). Or maybe run it in its
own thread if the event threads are not enought?
Thanks,
Stephane
(*) Subject: [CVS ci] approaching pdd16 callbacks
http://groups.google.com/groups?q=callback+group:perl.perl6.internals&hl=en&lr=&ie=UTF-8&group=perl.perl6.internals&selm=4024E112.5030809%40toetsch.at&rnum=3
PS.: attached the same test files, just using the new signature.
# -- Gtk Button Example.
.sub _gtkcallback
print "Hello\n"
.end
.sub _main @MAIN
.include "glib.pasm"
.include "gtk.pasm"
.local pmc window
.local pmc button
.local pmc callback
.local pmc userdata
.local NCI init
init = global "Gtk::gtk_init"
init(0)
# -- create the window
.local NCI w_new
w_new = global "Gtk::gtk_window_new"
window = w_new(0)
# -- create the button
.local NCI b_new
b_new = global "Gtk::gtk_button_new_with_label"
button = b_new("Parrot")
# -- install callback?
.local pmc cb_sub
cb_sub = global "_gtkcallback"
userdata = new Integer
userdata = 42
callback = new_callback cb_sub, userdata, "pU"
# -- function sig is "'lptppi', then we have:
# P5 is the button
# P6 the callback
# P7 data we may to pass through.
# S5 "clicked"
# I5 is 0
# -- Uncomment this section to actually install the callback
# -- (this segfaulst on my system)
.local NCI sig_conn
sig_conn = global "Glib::g_signal_connect_object"
sig_conn(button, "clicked", callback, userdata, 0)
# -- Set the container.
.local NCI cont_add
cont_add = global "Gtk::gtk_container_add"
cont_add(window, button)
# -- show button
.local NCI w_show
w_show = global "Gtk::gtk_widget_show"
w_show(button)
# -- show window
w_show(window)
.local NCI g_main
g_main = global "Gtk::gtk_main"
g_main()
end
.end
saveall
loadlib P1, 'libgtk-x11-2.0'
dlfunc P2, P1, 'gtk_init', 'vii'
store_global 'Gtk::gtk_init', P2
dlfunc P2, P1, 'gtk_main', 'vv'
store_global 'Gtk::gtk_main', P2
dlfunc P2, P1, 'gtk_widget_show', 'vp'
store_global 'Gtk::gtk_widget_show', P2
dlfunc P2, P1, 'gtk_container_add', 'vpp'
store_global 'Gtk::gtk_container_add', P2
dlfunc P2, P1, 'gtk_button_new_with_label', 'pt'
store_global 'Gtk::gtk_button_new_with_label', P2
dlfunc P2, P1, 'gtk_window_new', 'pi'
store_global 'Gtk::gtk_window_new', P2
restoreall
saveall
loadlib P1, 'libgobject-2.0'
dlfunc P2, P1, 'g_signal_connect_object', 'lptppi'
store_global 'Glib::g_signal_connect_object', P2
restoreall
$ ../../parrot gtk.toplevel.button.imc
Parrot VM: PANIC: callback_info doesn't look like a pointer!
C file src/inter_cb.c, line 132
Parrot file (not available), line (not available)
We highly suggest you notify the Parrot team if you have not been working on
Parrot. Use bugs6.perl.org or send an e-mail to [EMAIL PROTECTED]
Include the entire text of this error message and the text of the script that
generated the error. If you've made any modifications to Parrot, please
describe them as well.
Version : 0.1.0-devel
Configured : Wed Aug 18 22:08:26 2004
Architecture: i386-linux
JIT Capable : Yes
Interp Flags: (no interpreter)
Exceptions : (missing from core)
Dumping Core...
Quit
