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.
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?
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!)
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
