Common Lisp bindings to GTK+

Dear Espen

I am having some problem on compilation of OpenMusic on this machine.  
Clg seems to work with hello-world.
My config is :

kernel :2.6.22-3-686
libgtk2.0-0 version : 2.12.1-1
sbcl 1.0.5


the error is :

WARNING: GLib-GObject: invalid (NULL) pointer instance

debugger invoked on a GLIB:CRITICAL-LOG-LEVEL in thread #<THREAD  
"initial thread" {A6984D9}>:
   GLib-GObject: g_signal_connect_data: assertion  
`G_TYPE_CHECK_INSTANCE (instance)' failed

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [ABORT] Exit debugger, returning to top level.

(NIL -303628736 -303628740 #<FUNCTION GLIB::LOG-HANDLER>)
0]


Is it related to the libgtk2 version ? because on other machines it  
works and libgtk is 2.10?
Or is it always the trouble with dynamic 3rd part libraries ?

Thanx
Karim

Hi

The code I used below is a little bit different to the testcairo
examples. In testcairo, cairo context is created within the callback
of expose-event, while in  my code, I want to initialize the context
and set it to a global variable, so that I don't need to pass it
around.

But running the program, there were errors told me that The slot
GTK:WINDOW is unbound in the drawing-area object.

After an hour of debugging, I finally found that if I place
gdk:cairo-create after gtk:widget-show-all, then it works.

So I'm wondering if it's caused by the initialization sequences in clg.

And do you have any suggestions for using cairo efficiently in clg
(like being a graphics editor within a scrolled-window)



Best,
Jianshi

Hi,

I want to add some buttons with mnemonic labels, but I couldn't find
anyway to do that. Could anyone give me an example?


Best,
Janshi

Hi,

I'm using SBCL 1.0.5 with CLG after reading the mailing list. It works
perfect. Just being curious, is there a plan to support more recent
SBCL (or what did the SBCL developers responded to the periodical
polling api)?


Cheers,
Jianshi

Hi,

I met a new bug when using the latest CVS version.

I made a customized image of SBCL containing several packages I often
use including clg. During startup, SBCL gave errors that C libraries
like gffi-alien.so, etc, cannot be located (could not find the file
error).

So I'm wondering if there's someone else here who has the same problem.


Cheers,
Jianshi

I upgraded clg to the latest CVS version but testgtk reported some weird errors.

I'm using SBCL 1.0.5 on x86-64 Linux, both multi-threaded mode
(started with clg-init-with-threading) and single-threaded mode gave
similar errors.

Here's the debug backtrace.

The value NIL is not of type NUMBER.
   [Condition of type TYPE-ERROR]

Restarts:
 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "gtk event
loop" {1000C5FCF1}>)

Backtrace:
  0: (SB-C::%COMPILE-TIME-TYPE-ERROR (NIL) NUMBER #<unavailable argument>)
      Locals:
        SB-DEBUG::ARG-0 = (NIL)
        SB-DEBUG::ARG-1 = NUMBER
        SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
  1: (SB-C::%COMPILE-TIME-TYPE-ERROR (NIL) NUMBER #<unavailable argument>)
      Locals:
        SB-DEBUG::ARG-0 = 3
        SB-DEBUG::ARG-1 = (NIL)
        SB-DEBUG::ARG-2 = NUMBER
        SB-DEBUG::ARG-3 = :<NOT-AVAILABLE>
  2: (GLIB:GVALUE-TYPE #.(SB-SYS:INT-SAP #X2B12E1749BA0))
      Locals:
        SB-DEBUG::ARG-0 = #.(SB-SYS:INT-SAP #X2B12E1749BA0)
  3: (GLIB::GVALUE-PEEK #.(SB-SYS:INT-SAP #X2B12E1749BA0))
      Locals:
        SB-DEBUG::ARG-0 = #.(SB-SYS:INT-SAP #X2B12E1749BA0)
  4: (GLIB::CALLBACK-TRAMPOLINE #<FUNCTION
GLIB::INVOKE-SIGNAL-HANDLER> 2 1 #.(SB-SYS:INT-SAP #X2B12E1749BA0)
#.(SB-SYS:INT-SAP #X00000000))
      Locals:
        GLIB::CALLBACK-ID = 2
        GLIB::N-PARAMS = 1
        GLIB::PARAM-VALUES = #.(SB-SYS:INT-SAP #X2B12E1749BA0)
        GLIB::RESTART-WRAPPER = #<FUNCTION GLIB::INVOKE-SIGNAL-HANDLER>
        GLIB::RETURN-VALUE = #.(SB-SYS:INT-SAP #X00000000)
  5: (NIL 5920011490077 5920011490076 #<FUNCTION GLIB::SIGNAL-HANDLER-MARSHAL>)
  6: ("foreign function: #x41F332")
  7: ("foreign function: #x40BAC2")
  8: ("foreign function: #x426BA5D4")

Hi,

The following code was distilled from a real system to illustrate
a problem that's been bothering me.  I'm using the 2007-12 snapshot
of CMUCL on a Gentoo x86 computer and the CLG is the latest from
the CVS source.

Step 0. Enter the following into Lisp:

  (defun popup-palette ()
    (let ((dialog (make-instance 'gtk:dialog
                                 :modal nil
                                 :button (list "gtk-ok"
                                               #'gtk:widget-destroy
                                               :object t))))
      (gtk:box-pack-start (gtk:dialog-vbox dialog)
                          (make-instance 'gtk:color-selection)
                          ;;(make-instance 'gtk:label
                          ;;               :label "this should be ok")
                          t t 0)
      (gtk:widget-show-all dialog)
      dialog))

  (let ((w (make-instance 'gtk:window)))
    (gtk:widget-add-events w '(:button-press))
    (glib:signal-connect w
                         :button-press-event
                         #'(lambda (event)
                             (declare (ignore event))
                             (popup-palette)))
    (gtk:widget-show w))

Step 1. Click the left mouse button over the blank window to pop up a
   color selection dialog.

Step 2. Click the OK button of the the color selection dialog.

Setp 3. Repeat 1 again.

Step 4. Repeat 2 again and you'll get the following error:

Invalid function name: #<Unknown Pointer Object, type=#x8B
                         {58D30A97}>
   [Condition of type SIMPLE-TYPE-ERROR]

Restarts:
 0: [CONTINUE] Return from callback function
 1: [RE-INVOKE] Re-invoke callback function
 2: [DISCONNECT] Disconnect and exit signal handler
 3: [ABORT] Return to Top-Level.

Backtrace:
  0: (LISP::FDEFINITION-OBJECT #<Unknown Pointer Object, type=#x8B {58D30A97}> NIL)
  1: (KERNEL:%COERCE-TO-FUNCTION #<Unknown Pointer Object, type=#x8B {58D30A97}>)
  2: ("DEFMETHOD COMPUTE-SLOT-READER-FUNCTION (EFFECTIVE-VIRTUAL-ALIEN-SLOT-DEFINITION)" #<GTK:DIALOG at 0x8115E38>)
  3: ("DEFMETHOD COMPUTE-SLOT-BOUNDP-FUNCTION (EFFECTIVE-VIRTUAL-SLOT-DEFINITION)" #<GTK:DIALOG at 0x8115E38>)
  4: ("DEFMETHOD COMPUTE-SIGNAL-FUNCTION (WIDGET T T T T)" #<GTK:DIALOG at 0x8115E38>)
  5: ("DEFMETHOD SIGNAL-CONNECT (GOBJECT T T)" #<GTK:DIALOG at 0x8115E38> 0)
  6: (GLIB:INVOKE-CALLBACK 22 NIL #<GTK:DIALOG at 0x8115E38> 0)
  7: (GLIB::INVOKE-SIGNAL-HANDLER 22 #<unused-arg> #<GTK:DIALOG at 0x8115E38> 0)
  8: (GLIB::CALLBACK-TRAMPOLINE #<Function GLIB::INVOKE-SIGNAL-HANDLER {59327581}> 22 2 #.(SYSTEM:INT-SAP #x3FFFB960) ...)
  9: (GLIB::SIGNAL-HANDLER-MARSHAL 268430813 268430809)
 10: ("call_into_lisp+#x8C [#x8052BE8] /usr/local/cmucl/bin/lisp")
 11: ("funcall3+#x26 [#x8052A56] /usr/local/cmucl/bin/lisp")
 12: ("Foreign function call land")

If you replace the color selection widget with a label widget,
repeating steps 1 & 2 as many times as you want won't send CMUCL
into the debugger.

Could someone please shed any light on what's going on?

Best wishes,

-cph

This is rather trivial, but it was bothering me sometime ago.

Is there a reason why the C compiler is hardwired to be the GNU one?

I suppose it's fine for Linux, CYGWIN and a couple of other systems,
but I suspect other non-GNU compilers can handle CLG's code just as
well.

I believe that modifying forms like:

     (run-shell-command "gcc ~A -o ~S ~{~S~^ ~} ~{~A~^ ~}"
      #-(or darwin win32)"-shared"
      #+darwin "-bundle"
      [...]

into

     (run-shell-command "~A -o ~S ~{~S~^ ~} ~{~A~^ ~}"
      #-(or darwin win32 freebsd linux)"cc -shared"  ; cross your fingers and hope it's GNU
      #+darwin "cc -bundle"
      #+freebsd "cc -shared"
      #+linux "cc -shared"
      #+win32 "gcc -whatever"
      [...]

would be more portable.

-- 
walter pelissero
http://www.pelissero.de

On SBCL, if I remember well, MAKE-PROXY-INSTANCE caused a run-time
error due to a method signature mismatch between the around method and
its next method.  On a closer look it seems to me the Lisp was right:

Index: gdkevents.lisp
===================================================================
RCS file: /cvsroot/clg/clg/gdk/gdkevents.lisp,v
retrieving revision 1.12
diff -c -r1.12 gdkevents.lisp
*** gdkevents.lisp	26 Apr 2006 09:20:20 -0000	1.12
--- gdkevents.lisp	4 Jan 2008 13:46:02 -0000
***************
*** 82,88 ****
  
! (defmethod make-proxy-instance :around ((class (eql (find-class 'event))) location &rest initargs)
    (let ((class (%event-class location)))
!     (apply #'call-next-method class location initargs)))
  
  
  (defclass timed-event (event)
--- 82,88 ----
  
! (defmethod make-proxy-instance ((class (eql (find-class 'event))) location &rest initargs)
    (let ((class (%event-class location)))
!     (apply #'make-proxy-instance class location initargs)))
  
  
  (defclass timed-event (event)


-- 
walter pelissero
http://www.pelissero.de

"Walter C. Pelissero" <walter@...> writes:

> I've given a cursory look at the code and I've noticed that you meant
> to try first the non-absolute pathname and then the absolute.  I
> initially understood you intended to do the other way around.  This,
> of course, reduces substantially the security risk as I saw it.

No, I actually meant to (and does) first try the absolute path. But on a
second thought I agree that this is not a very good solution. 

So I ended up removing the directory from the pathname after a shared
object has been loaded, similar to what you did before saving an
image. It is now possible to specify absolute pathnames during
development, save an image and move the shared objects around without
doing anything else when loading the image than setting LD_LIBRARY_PATH.

The default behavior of removing absolute directories can be overridden
by specifying ":absolute t" to libraries and shared objects in the
defsystem form.

-- 
Espen

Luca Capello <luca@...> writes:

> To remove the need to specify a `logical-pathname-translations', I
> develop the attached patch which uses ASDF functions instead, since clg
> already depends on ASDF.
> 
> While I was at it, I modified that clg/gdk/export.lisp to use
> `export-from-files' similar to clg/gtk/export.lisp.
> 
> Comments are welcome!

This was indeed a very good idea. I haven't applied your patch as such,
but instead created a new macro called export-from-system. This macro
will export symbols from all components that the file in which it is
used (typically the export.lisp files) depends on. That way new files
from which symbols should be exported automatically can be added by just
modifying the system definition.


Luigi Panzeri <matley@...> writes:

> I think that the same results can be achieved with a less invasive
> patch. You just need to setup pathname translation in clg-tools.asd
> before doing anything, like in the patch attached.

For backward compatibility (and to be able to run the examples) I've
also done this, although I included it directly at the top-level and
not wrapped in method definitions.

-- 
Espen

"Matthew D. Swank" <akopa.gmane.poster@...> writes:

> The accessor sb-thread:mutex-value can only refer to nil or to the owning
> thread, so the use of a cons as the mutex value in calls to get-mutex fail
> under recent versions of sbcl.  The attached patch fixes that (and is
> backward compatible with older sbcl's?)

Thanks, I have applied the patch with some minor changes.

-- 
Espen