Hi Bob,
Bob Willan wrote:
I've been thinking about getting into Lisp and Cells for a while, and your
how-to prompted me to give it a try now. Not to mention all the work
you've been doing, making cells-gtk look like more of a going concern
now. Thanks for that.
Thanks for the positive feed back. Though I see that I might have
opened a can of worms here ;)
I followed all your instructions, and when I had a compile problem, I
removed everything, downloaded again/updated from cvs, and tried again
from scratch, with the same results. I'm new at lisp and must say the
compile errors and debugger aren't exactly intuitive to me, though I'd
guess it involves the cffi function call :(
Ok, I since you included all the relevant logs, I will try to shed some
light on it.
My compile stops in tree-view.lisp, as the lines below show. I am using
straight Debian Etch (32bit 2.6.18-5-k7 kernel), gcc that came with it
v4.1.2 20061115 (prerelease)(Debian 4.1.1-21), SBCL 0.9.16, cffi 0.9.2,
and the cells/cells-gtk from cvs using the commands on your site.
As Friedrich pointed out, try using a newer sbcl. You can download
binary realeases at sbcl.org. I have not tested anything with a pre
1.0.x version of SBCL.
;; I've listed my links (without the permissions/owner/etc to better
;; read the lines, but permissions were wide open)
[EMAIL PROTECTED]:~/.sbcl/site$ ls -la
total 20
drwxr-xr-x 5 bob bob 4096 2008-01-30 09:32 .
drwxr-xr-x 4 bob bob 4096 2008-01-28 23:53 ..
drwxr-xr-x 6 bob bob 4096 2008-01-30 23:07 cells
drwxr-xr-x 8 bob bob 4096 2008-01-30 23:07 cells-gtk
drwxr-xr-x 8 bob bob 4096 2008-01-30 09:33 cffi_0.9.2
ok, that looks nice and clean.
[EMAIL PROTECTED]:~/.sbcl/site$ ls -la ../systems/
total 8
cells.asd -> ../site/cells/cells.asd
cells-gtk.asd -> ../site/cells-gtk/cells-gtk/cells-gtk.asd
cffi.asd -> ../site/cffi_0.9.2/cffi.asd
cffi-uffi-compat.asd -> ../site/cffi_0.9.2/cffi-uffi-compat.asd
gtk-ffi.asd -> ../site/cells-gtk/gtk-ffi/gtk-ffi.asd
ph-maths.asd -> ../site/cells-gtk/ph-maths/ph-maths.asd
pod-utils.asd -> ../site/cells-gtk/pod-utils/pod-utils.asd
test-gtk.asd -> ../site/cells-gtk/cells-gtk/test-gtk/test-gtk.asd
utils-kt.asd -> ../site/cells/utils-kt/utils-kt.asd
That's perfect, too. BTW, without the correct permissions, you could
not have gotten that far. See below.
;;----------------------------------------------------------------------------
;; I wasn't sure if these warnings when compiling gtk-ffi are
;; okay/expected or not?
[EMAIL PROTECTED]:~/.sbcl/site/cells-gtk/gtk-ffi$ make
gcc -fPIC -c gtk-adds.c `pkg-config --cflags --libs gtk+-2.0`
gtk-adds.c: In function 'gtk_adds_color_new':
gtk-adds.c:77: warning: incompatible implicit declaration of built-in
function 'malloc'
gcc: -lgtk-x11-2.0: linker input file unused because linking not done
gcc: -lgdk-x11-2.0: linker input file unused because linking not done
gcc: -latk-1.0: linker input file unused because linking not done
gcc: -lgdk_pixbuf-2.0: linker input file unused because linking not done
gcc: -lm: linker input file unused because linking not done
gcc: -lpangocairo-1.0: linker input file unused because linking not done
gcc: -lfontconfig: linker input file unused because linking not done
gcc: -lXext: linker input file unused because linking not done
gcc: -lXrender: linker input file unused because linking not done
gcc: -lXinerama: linker input file unused because linking not done
gcc: -lXi: linker input file unused because linking not done
gcc: -lXrandr: linker input file unused because linking not done
gcc: -lXcursor: linker input file unused because linking not done
gcc: -lXfixes: linker input file unused because linking not done
gcc: -lpango-1.0: linker input file unused because linking not done
gcc: -lcairo: linker input file unused because linking not done
gcc: -lX11: linker input file unused because linking not done
gcc: -lgobject-2.0: linker input file unused because linking not done
gcc: -lgmodule-2.0: linker input file unused because linking not done
gcc: -ldl: linker input file unused because linking not done
gcc: -lglib-2.0: linker input file unused because linking not done
gcc -shared -o libcellsgtk.so gtk-adds.o `pkg-config --cflags --libs
gtk+-2.0`
Yep, perfectly fine. Same thing for me.
;;----------------------------------------------------
;; Compile log starting at tree-view.lisp
... which means you have successfully compiled cells, cffi, and gtk-ffi
(which are the major systems r3equired by the actual cells-gtk system).
So the issue should be pretty local to that file.
If you check cells-gtk/cells-gtk.asd you will notice that tree-view is
one of the last files mentioned, so the major part of cells-gtk got
compiled, too.
; compiling file "/home/bob/.sbcl/site/cells-gtk/cells-gtk/tree-view.lisp"
(written 27 JAN 2008 03:01:05 PM):
; compiling (IN-PACKAGE :CGTK)
; compiling (DEF-OBJECT LIST-STORE ...)
; compiling (DEF-OBJECT TREE-STORE ...)
; compiling (DEFUN FAIL ...)
; compiling (DEF-WIDGET TREE-VIEW ...)
; compiling (DEF-CLEAN-UP (SELF TREE-VIEW) ...)
; compiling (DEF-C-OUTPUT TREE-MODEL ...)
; compiling (DEF-C-OUTPUT EXPAND-ALL ...)
; compiling (CFFI:DEFCALLBACK TREE-VIEW-ITEMS-SELECTOR ...)
; compiling (DEFMETHOD GET-SELECTION ...)
; compiling (DEF-C-OUTPUT SELECTION-MODE ...)
; compiling (CFFI:DEFCALLBACK TREE-VIEW-SELECT-HANDLER ...)
; compiling (DEF-C-OUTPUT ON-SELECT ...)
; compiling (DEFMODEL LISTBOX ...)
; compiling (DEFMETHOD ITEMS ...)
; compiling (DEFMETHOD (SETF ITEMS) ...)
; compiling (DEFUN MK-LISTBOX ...)
; compiling (DEF-C-OUTPUT SELECT-IF ...)
; compiling (DEF-C-OUTPUT ROOTS ...)
; compiling (DEFMODEL TREEBOX ...)
; compiling (DEFUN MK-TREEBOX ...)
; compiling (DEF-C-OUTPUT SELECT-IF ...)
; compiling (DEF-C-OUTPUT ROOTS ...)
; compiling (DEFUN GTK-TREE-STORE-SET-KIDS ...)
; compiling (CFFI:DEFCALLBACK TREE-VIEW-RENDER-CELL-CALLBACK ...)
; compiling (DEFUN ITEM-FROM-PATH ...)
; compiling (DECLAIM (OPTIMIZE #))
; compiling (DEFUN GTK-TREE-VIEW-RENDER-CELL ...)
; compiling (DEFSTRUCT RENDERER ...)
; compiling (LET (#) ...)
Ok, if you wish to look into this in more detail, open tree-view.lisp
and scroll to line 302. The offending instruction is:
(let ((renderers (make-hash-table)))
(defun register-renderer-data (renderer data)
(setf (gethash (cffi-sys:pointer-address renderer) renderers) data))
(defun recover-renderer-data (renderer)
(gethash (cffi-sys:pointer-address renderer) renderers)))
Nothing spectacular here. The pointer-address function can't be too
complex.
debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread"
{A7BD4C1}>:
The value NIL is not of type SB-C::PHYSENV.
The error is in a SB-xxx package. THat is often a sign that there is
nothing wrong with your code, but the problem is at a deeper level.
Common solutions are (as Friedrich already pointed out):
. update SBCL to something more current. If in doubt, remove the debian
package first to make sure the current sbcl is called
. remove stale fasl files. These are something like C's object files:
compiled code used instead of the source file. Just do rm *.fasl
**/*.fasl to remove all compiled files in the current directory and all
subdirs. Then restart sbcl. Everything will be compiled freshly from
scratch
. you have some leftovers in your current working image. Restart sbcl
to start clean
1: (SB-C::LET-CONVERT
It works on the let with some internal function
...
10: (SB-C::COMPILE-TOPLEVEL
(#<SB-C::CLAMBDA
:%SOURCE-NAME SB-C::.ANONYMOUS.
:%DEBUG-NAME (SB-C::TOP-LEVEL-FORM
(LET #
#
#))
:KIND :TOPLEVEL
:TYPE #<SB-KERNEL:BUILT-IN-CLASSOID FUNCTION (read-only)>
:WHERE-FROM :DEFINED
:VARS NIL {B6E2001}>)
NIL)
This is the part where the compiler (SBcl-Compiler) compiles the let form.
So in other words, the SBCL compiler chokes at this rather simple let
clause. And you say this error persists, even if you recompile
everything from scratch.
Therefore my guess really is that the problem is with SBCL. Try the
newest SBCL. If the problem persists, we should try to isolate it and
post on the SBCL list.
Peter
_______________________________________________
cells-gtk-devel site list
cells-gtk-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-gtk-devel
