Bob Willan wrote:
Peter and Friedrich,
Thanks to both of you for your help. It was the older version of SBCL
that was the problem. I've got a working demo now, too cool.
Glad to hear it worked for you now. I added a paragraph to the guide
about installing a recent sbcl.
Peter, you might mention on your Getting Started page that (require :asdf)
might be needed before anything else. The Debian pkg was setup so I
didn't need to do that, but the sbcl 1.0.12 compiled tar I downloaded
did - I received a "Don't know how to REQUIRE CELLS." error without it
when I typed (require 'cells). I suppose maybe I should add that to a
sbclrc initialization file so its always there?
Yep, exactly. Thanks for pointing that out. I added to the guide how
to include (require 'asdf) (require 'asdf-install) in your .sbclrc.
I also created a section warning potential users that it might be
difficult ;-)
Maybe I'll think about moving up to Debian Unstable (except the kernel,
because my VMWare Workstation won't work correctly with the latest
kernels - my only commercial license and its the only software I have
problems with that I can't get around or fix!)
A great testimony to open source :) Maybe you should check out qemu.
It is a little harder to set up than VMWare, but does a pretty good job
these days. Rumour has it you can even run OSX 10.5 Tiger in there.
Cheers,
Peter
Thanks, again,
Bob
===================================
On Friday 01 February 2008, Peter Hildebrandt wrote:
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
