Hello list,
just stumbled over a small buglet in 'examples.lisp' - the function 'textentry' fails to call gtk::init which results in some nasty openmcl kernel mess when called (this bug only shows up iff '(textentry)' is called before any other demo invocations, once any othjer demo got started gtk (or - more precicely, it's type system - will be properly initialized).
BTW, i've started to work on gtk2 support for OpenMCL/Linux - so far i've been able to generate gtk2.ffi and the interface database. I modified openmcl-gtk-support to get a (not-so-good) working openmcl-gtk2-support. I've even managed to frankensteinize Rick Taube's lambda-gtk-openmcl.lisp into a lambda-gtk-openmcl-linux.lisp that _does_ produce a gtkffi-openmcl.lisp. Now, i can load and start the examples but unfortunately the first callback seems to tickle openmcl's kernel in unwanted places. I guess i should first test my gtk2 bindings without the lambdagtk suggar ... :-/
Oh, and as a suggestion: i'd be rather cool to have libglade support in lambda-gtk. Saves a _lot_ of typing ...
Cheers Ralf Mattes
thanks ralf ! ill fix that today in cvs btw if you want cvs access to add the linux/ppc support let me know.
On Dec 4, 2004, at 9:16 AM, rm@fabula.de wrote:
Hello list,
just stumbled over a small buglet in 'examples.lisp' - the function 'textentry' fails to call gtk::init which results in some nasty openmcl kernel mess when called (this bug only shows up iff '(textentry)' is called before any other demo invocations, once any othjer demo got started gtk (or - more precicely, it's type system - will be properly initialized).
BTW, i've started to work on gtk2 support for OpenMCL/Linux - so far i've been able to generate gtk2.ffi and the interface database. I modified openmcl-gtk-support to get a (not-so-good) working openmcl-gtk2-support. I've even managed to frankensteinize Rick Taube's lambda-gtk-openmcl.lisp into a lambda-gtk-openmcl-linux.lisp that _does_ produce a gtkffi-openmcl.lisp. Now, i can load and start the examples but unfortunately the first callback seems to tickle openmcl's kernel in unwanted places. I guess i should first test my gtk2 bindings without the lambdagtk suggar ... :-/
Oh, and as a suggestion: i'd be rather cool to have libglade support in lambda-gtk. Saves a _lot_ of typing ...
Cheers Ralf Mattes
lambda-gtk-devel site list lambda-gtk-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/lambda-gtk-devel
On Dec 4, 2004, at 9:16 AM, rm@fabula.de wrote:
Hello list,
just stumbled over a small buglet in 'examples.lisp' - the function 'textentry' fails to call gtk::init which results in some nasty openmcl kernel mess when called (this bug only shows up iff '(textentry)' is called before any other demo invocations, once any othjer demo got started gtk (or - more precicely, it's type system - will be properly initialized).
BTW, i've started to work on gtk2 support for OpenMCL/Linux - so far i've been able to generate gtk2.ffi and the interface database. I modified openmcl-gtk-support to get a (not-so-good) working openmcl-gtk2-support. I've even managed to frankensteinize Rick Taube's lambda-gtk-openmcl.lisp into a lambda-gtk-openmcl-linux.lisp that _does_ produce a gtkffi-openmcl.lisp. Now, i can load and start the examples but unfortunately the first callback seems to tickle openmcl's kernel in unwanted places. I guess i should first test my gtk2 bindings without the lambdagtk suggar ... :-/
Oh, and as a suggestion: i'd be rather cool to have libglade support in lambda-gtk. Saves a _lot_ of typing ...
Cheers Ralf Mattes
lambda-gtk-devel site list lambda-gtk-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/lambda-gtk-devel
Now, i can load and start the examples but unfortunately the first callback seems to tickle openmcl's kernel in unwanted places. I guess i should first test my gtk2 bindings without the lambdagtk suggar ... :-/
sorry i dont know anything about the callback support on linux-ppc, ive only used the darwin version and that works quite well
Oh, and as a suggestion: i'd be rather cool to have libglade support in lambda-gtk. Saves a _lot_ of typing ...
there was a post about this on Planet Lisp last month, I think this is the one:
On Sat, Dec 04, 2004 at 12:11:48PM -0600, Rick Taube wrote:
Now, i can load and start the examples but unfortunately the first callback seems to tickle openmcl's kernel in unwanted places. I guess i should first test my gtk2 bindings without the lambdagtk suggar ... :-/
sorry i dont know anything about the callback support on linux-ppc, ive only used the darwin version and that works quite well
Hello Rick,
here's what i've done so far (i'll send a cc tothe openmcl-devel list, i fear i need some help from there).
- created a (hopefully correct) populate.sh that uses 'pkg-config' to find all neccessary CPP flags.
- generated the interface database as outlined on the website
- rewrote 'ccl:library/openmcl-gtk-support.lisp' into 'ccl:library/openmcl-gtk2-support.lisp' (BTW, is the installation of the gtk-task with def-load-pointers really neccessary? Is there no better way to run the gtk-main loop in a dedicated thread?).
- wrote a quick test case as follows:
;;; ---- File ffi-test-gtk2.lisp ---------------------------------------------------------
(eval-when (:compile-toplevel :execute) (require "openmcl-gtk2-support"))
(defcallback button-clicked (:address button :address cmd :void) (declare (ignore button cmd)) (format t "Hello stranger ~%"))
(defcallback action-quit (:address widget :address data :void) (declare (ignore widget)) (format t "Oi veh ...~%") (#_gtk_main_quit))
(defun gtk2-test ()
(let ((window (#_gtk_window_new #$GTK_WINDOW_TOPLEVEL)) (button (#_gtk_button_new)))
(with-cstrs ((destroy-name "destroy") (clicked-name "clicked") (window-title "Mompidomp ...") (button-label "Click me, stranger ...")) (#_gtk_window_set_title window window-title) (#_gtk_button_set_label button button-label) (#_g_signal_connect_data button clicked-name button-clicked button (%null-ptr) 0) (#_g_signal_connect_data window destroy-name action-quit window (%null-ptr) 0))
(#_gtk_container_add window button) (#_gtk_widget_show button) (#_gtk_widget_show window)
(ccl::%install-periodic-task 'gtk2-task #'(lambda () (do* () ((eql (#_gtk_events_pending) 0)) (#_gtk_main_iteration))) 10)))
;;;; -------------- File ends here --------------------------------------------------
NOTE: i installed the periodic task here since i haven't put it into my gtk2-support and i wnated to test whether gtk-main was causing the troubles (same effect with gtk-man and the periodic task, i'm affraid).
Now, as with the lambda-gtk code, everything works fine until the first callback arrives ... here's a kernel backtrace:
Welcome to OpenMCL Version (Beta: Linux) 0.14.2! ? (load "ffi-test-gtk2.lisp")
"Loading libraries ..." " ... Done" ;Compiler warnings : ; Unused lexical variable DATA, in ACTION-QUIT. #P"/usr/local/src/LISP/lambda-gtk-0.1/ffi-linux.lisp" ? (gtk2-test) #<PERIODIC-TASK GTK2-TASK 10 #x353B58A6> ? Unhandled exception 11 at 0x00012c78, context->regs at #x7fffdd50 Read operation to unmapped address 0x7f454c44 In foreign code at address 0x00012c78 ? for help [8158] OpenMCL kernel debugger: b
(#x7fffe210) #x00013688 : (null) + 79496 (#x7fffe240) #x0001381C : (null) + 79900 (#x7fffe480) #x300E4BD4 : (null) + 806243284 (#x7FFFE4B0) #x7FFFE808 : foreign code (unknown) (#x7fffeb00) #x0F8E3AC4 : (null) + 260979396 (#x7fffebc0) #x0F8E29EC : g_signal_emit_valist + 1864 (#x7fffee10) #x0F8E2D38 : g_signal_emit + 108 (#x7fffeea0) #x0F015628 : gtk_button_clicked + 132 (#x7fffeec0) #x0F016804 : (null) + 251750404 (#x7fffeee0) #x0F8E405C : g_cclosure_marshal_VOID__VOID + 176 (#x7fffef00) #x0F8CE930 : (null) + 260892976 (#x7fffef30) #x0F8CE5A4 : g_closure_invoke + 224 (#x7fffef70) #x0F8E3374 : (null) + 260977524 (#x7ffff030) #x0F8E29EC : g_signal_emit_valist + 1864 (#x7ffff280) #x0F8E2D38 : g_signal_emit + 108 (#x7ffff310) #x0F015568 : gtk_button_released + 132 (#x7ffff330) #x0F016618 : (null) + 251749912 (#x7ffff350) #x0F0D62F0 : _gtk_marshal_BOOLEAN__BOXED + 212 (#x7ffff380) #x0F8CE930 : (null) + 260892976 (#x7ffff3b0) #x0F8CE5A4 : g_closure_invoke + 224 (#x7ffff3f0) #x0F8E3470 : (null) + 260977776 (#x7ffff4b0) #x0F8E27B0 : g_signal_emit_valist + 1292 (#x7ffff700) #x0F8E2D38 : g_signal_emit + 108 (#x7ffff790) #x0F1DBEE8 : (null) + 253607656 (#x7ffff7b0) #x0F0D4670 : gtk_propagate_event + 268 (#x7ffff7d0) #x0F0D3118 : gtk_main_do_event + 652 (#x7ffff800) #x0F96965C : (null) + 261527132 (#x7ffff820) #x0F9DAC98 : (null) + 261991576 (#x7ffff870) #x0F9DC1DC : g_main_context_dispatch + 232 (#x7ffff890) #x0F9DC5AC : (null) + 261997996 (#x7ffff8d0) #x0F9DC8B0 : g_main_context_iteration + 132 (#x7ffff8f0) #x0F0D2AE0 : gtk_main_iteration + 60 (#x7ffff910) #x00007BE0 : (null) + 31712 (#x7FFFF918) #x353BF980 : #<Anonymous Function #x353bf9be> + 52 (#x7FFFF928) #x311143D0 : #<Function HOUSEKEEPING #x3512b42e> + 452 (#x7FFFF938) #x31114358 : #<Function HOUSEKEEPING #x3512b42e> + 332 (#x7FFFF948) #x311142C8 : #<Function HOUSEKEEPING #x3512b42e> + 188 (#x7FFFF958) #x310F7F6C : #<Anonymous Function #x350f7afe> + 312 (#x7FFFF968) #x310F7F84 : #<Anonymous Function #x350f7afe> + 336 (#x7FFFF978) #x310F7F8C : #<Anonymous Function #x350f7afe> + 344 (#x7FFFF988) #x310F7FC0 : #<Anonymous Function #x350f7afe> + 396 (#x7FFFF998) #x00008820 : (subprimitive (null))
... more follows but didn't look to relevant.
Hmm, i don't really know where to go now. Maybe one of the OpenMCL gurus has some idea/pointer?
Oh, and as a suggestion: i'd be rather cool to have libglade support in lambda-gtk. Saves a _lot_ of typing ...
there was a post about this on Planet Lisp last month, I think this is the one:
Ah, missed that. That does look very promissing :-)
TIA Ralf Mattes
- rewrote 'ccl:library/openmcl-gtk-support.lisp' into
'ccl:library/openmcl-gtk2-support.lisp' (BTW, is the installation of the gtk-task with def-load-pointers really neccessary? Is there no better way to run the gtk-main loop in a dedicated thread?).
hi ralf - i wouldnt bother with ccl/library/openmcl-gtk-support.lisp -- it is not used or needed by lambda-gtk in any way. (at one point I did try to use that timer function BUT it was the source of endless problems with gtk and i gave up.) my own gtk interface just calls gtk-main and it works very well. But at some point it would be nice to have a 'portable' solution to gtk-main's blocking the repl since this is very unlispy. i think running gtk-main it in its own thread is probably the first way to try. but i wouldn't worry about that yet, just get a version of lambda-gtk to compile and load on ppclinux.
Hmm, i don't really know where to go now. Maybe one of the OpenMCL gurus has some idea/pointer?
dont go anywhere -- just forget about that file. look in the lambda-gtk tarball for the file gtkffi-openmcl.lisp -- all it does is load the gtk libs and then does a (ccl:use-interface-directory :gtk) and thats it. the big problem om ppclinux may be the callbacks -- i dont know if work in openmcl there or not.
-rick
lambda-gtk-devel@common-lisp.net