From bwillan at matrix-systems-inc.com Fri Feb 1 00:57:54 2008 From: bwillan at matrix-systems-inc.com (Bob Willan) Date: Thu, 31 Jan 2008 19:57:54 -0500 Subject: [cells-gtk-devel] "First steps" how to compile problem In-Reply-To: <479DA300.1030202@gmail.com> References: <479C80E5.7050409@gmail.com> <87zluq4jet.fsf@q-software-solutions.de> <479DA300.1030202@gmail.com> Message-ID: <200801311957.55181.bwillan@matrix-systems-inc.com> Hi, Peter, 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. 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 :( 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. Any suggestions would be greatly appreciated. Thanks, Bob Willan ;; I've listed my links (without the permissions/owner/etc to better ;; read the lines, but permissions were wide open) bob at work1:~/.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 bob at work1:~/.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 ;;---------------------------------------------------------------------------- ;; I wasn't sure if these warnings when compiling gtk-ffi are ;; okay/expected or not? bob at work1:~/.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` ;;---------------------------------------------------- ;; Compile log starting at tree-view.lisp ; 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 (#) ...) debugger invoked on a TYPE-ERROR in thread #: The value NIL is not of type SB-C::PHYSENV. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing # on #. 1: [ACCEPT] Continue, treating # on # as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (SB-C::MERGE-LETS # :WHERE-FROM :DEFINED :VARS (VALUES) {B6F94E9}> # :ARGS (#) {B7332C1}>) 0] backtrace 0: (SB-C::MERGE-LETS # :WHERE-FROM :DEFINED :VARS (VALUES) {B6F94E9}> # :ARGS (#) {B7332C1}>) 1: (SB-C::LET-CONVERT # :WHERE-FROM :DEFINED :VARS (VALUES) {B6F94E9}> # :ARGS (#) {B7332C1}>) 2: (SB-C::MAYBE-LET-CONVERT # :WHERE-FROM :DEFINED :VARS (VALUES) {B6F94E9}>) 3: (SB-C::DELETE-REF # :WHERE-FROM :DEFINED :VARS (VALUES) {B6F94E9}> {B6FBC99}>) 4: (SB-C::DELETE-BLOCK # NIL) 5: (SB-C::CLEAN-COMPONENT # #) 6: (SB-C::IR1-OPTIMIZE # NIL) 7: (SB-C::IR1-OPTIMIZE-UNTIL-DONE #) 8: (SB-C::IR1-PHASES #) 9: (SB-C::COMPILE-COMPONENT #) 10: (SB-C::COMPILE-TOPLEVEL (# :WHERE-FROM :DEFINED :VARS NIL {B6E2001}>) NIL) 11: (SB-C::CONVERT-AND-MAYBE-COMPILE (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))) (SB-C::ORIGINAL-SOURCE-START 0 29)) 12: ((FLET SB-C::DEFAULT-PROCESSOR) (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)))) 13: (SB-C::PROCESS-TOPLEVEL-FORM (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))) (SB-C::ORIGINAL-SOURCE-START 0 29) NIL) 14: (SB-C::SUB-SUB-COMPILE-FILE #) 15: ((LAMBDA ())) 16: (SB-C::%WITH-COMPILATION-UNIT #) 17: (SB-C::SUB-COMPILE-FILE #) 18: (COMPILE-FILE #P"/home/bob/.sbcl/site/cells-gtk/cells-gtk/tree-view.lisp") 19: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) # # # #) 20: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) # # # #) 21: ((LAMBDA ())) 22: (SB-C::%WITH-COMPILATION-UNIT #) 23: (ASDF:OPERATE ASDF:LOAD-OP COMMON-LISP-USER::TEST-GTK) 24: (ASDF::MODULE-PROVIDE-ASDF COMMON-LISP-USER::TEST-GTK) 25: ((LAMBDA (#:G21)) ASDF::MODULE-PROVIDE-ASDF) 26: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 # (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB)) 27: (SB-KERNEL:%MAP NIL # (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB)) 28: (REQUIRE COMMON-LISP-USER::TEST-GTK NIL) 29: (SB-INT:EVAL-IN-LEXENV (REQUIRE 'COMMON-LISP-USER::TEST-GTK) #) 30: (SB-EXT:INTERACTIVE-EVAL (REQUIRE 'COMMON-LISP-USER::TEST-GTK)) 31: (SB-IMPL::REPL-FUN NIL) 32: ((LAMBDA ())) 33: ((LAMBDA ())) 34: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #) 35: (SB-IMPL::TOPLEVEL-REPL NIL) 36: (SB-IMPL::TOPLEVEL-INIT) 37: ((LABELS SB-IMPL::RESTART-LISP)) 0] list SB-DEBUG::ARG-0 = 2 SB-DEBUG::ARG-1 = # :WHERE-FROM :DEFINED :VARS (VALUES) {B6F94E9}> SB-DEBUG::ARG-2 = # {B733289}> :ARGS (#) {B7332C1}> From frido at q-software-solutions.de Fri Feb 1 06:58:52 2008 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Fri, 01 Feb 2008 07:58:52 +0100 Subject: [cells-gtk-devel] "First steps" how to compile problem In-Reply-To: <200801311957.55181.bwillan@matrix-systems-inc.com> (Bob Willan's message of "Thu, 31 Jan 2008 19:57:54 -0500") References: <479C80E5.7050409@gmail.com> <87zluq4jet.fsf@q-software-solutions.de> <479DA300.1030202@gmail.com> <200801311957.55181.bwillan@matrix-systems-inc.com> Message-ID: <87ve59b1sj.fsf@q-software-solutions.de> Bob Willan writes: > Hi, Peter, > > 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. > > 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 :( > > 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. The SBCL is quite old, I'd try with a newer version. > ;; I wasn't sure if these warnings when compiling gtk-ffi are > ;; okay/expected or not? > > bob at work1:~/.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` I'm have puzzeled a bit about it, but I think you can ignore it > > ;;---------------------------------------------------- > > > ;; Compile log starting at tree-view.lisp > > ; 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 (#) ...) > debugger invoked on a TYPE-ERROR in thread # {A7BD4C1}>: > The value NIL is not of type SB-C::PHYSENV. As written above I'd try with a newer SBCL version. This systme is relativly fast moving, so one has to expect troubles.... And do not forget to remove the generated .fasl files (that are the compiled .lisp files) Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus From peter.hildebrandt at gmail.com Fri Feb 1 11:45:18 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Fri, 01 Feb 2008 12:45:18 +0100 Subject: [cells-gtk-devel] "First steps" how to compile problem In-Reply-To: <200801311957.55181.bwillan@matrix-systems-inc.com> References: <479C80E5.7050409@gmail.com> <87zluq4jet.fsf@q-software-solutions.de> <479DA300.1030202@gmail.com> <200801311957.55181.bwillan@matrix-systems-inc.com> Message-ID: <47A3064E.108@gmail.com> 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) > > bob at work1:~/.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. > bob at work1:~/.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? > > bob at work1:~/.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 # {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 > (# :%SOURCE-NAME SB-C::.ANONYMOUS. > :%DEBUG-NAME (SB-C::TOP-LEVEL-FORM > (LET # > # > #)) > :KIND :TOPLEVEL > :TYPE # > :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 From bwillan at matrix-systems-inc.com Fri Feb 1 21:53:13 2008 From: bwillan at matrix-systems-inc.com (Bob Willan) Date: Fri, 1 Feb 2008 16:53:13 -0500 Subject: [cells-gtk-devel] "First steps" how to compile problem - fixed In-Reply-To: <47A3064E.108@gmail.com> References: <479C80E5.7050409@gmail.com> <200801311957.55181.bwillan@matrix-systems-inc.com> <47A3064E.108@gmail.com> Message-ID: <200802011653.13779.bwillan@matrix-systems-inc.com> 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) > > > > bob at work1:~/.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. > > > bob at work1:~/.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? > > > > bob at work1:~/.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 # > {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 > > (# > :%SOURCE-NAME SB-C::.ANONYMOUS. > > :%DEBUG-NAME (SB-C::TOP-LEVEL-FORM > > (LET # > > # > > #)) > > :KIND :TOPLEVEL > > :TYPE # > > :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 > > From peter.hildebrandt at gmail.com Sat Feb 2 12:23:17 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Sat, 02 Feb 2008 13:23:17 +0100 Subject: [cells-gtk-devel] "First steps" how to compile problem - fixed In-Reply-To: <200802011653.13779.bwillan@matrix-systems-inc.com> References: <479C80E5.7050409@gmail.com> <200801311957.55181.bwillan@matrix-systems-inc.com> <47A3064E.108@gmail.com> <200802011653.13779.bwillan@matrix-systems-inc.com> Message-ID: <47A460B5.7000505@gmail.com> 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) >>> >>> bob at work1:~/.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. >> >>> bob at work1:~/.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? >>> >>> bob at work1:~/.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 #>> {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 >>> (#>> :%SOURCE-NAME SB-C::.ANONYMOUS. >>> :%DEBUG-NAME (SB-C::TOP-LEVEL-FORM >>> (LET # >>> # >>> #)) >>> :KIND :TOPLEVEL >>> :TYPE # >>> :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 >> >> > > From peter.hildebrandt at gmail.com Sat Feb 2 12:51:15 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Sat, 02 Feb 2008 13:51:15 +0100 Subject: [cells-gtk-devel] Problems with demo In-Reply-To: <47A11E93.1030006@tutopia.com> References: <479FBA86.8020208@tutopia.com> <479FC360.4040502@gmail.com> <47A11E93.1030006@tutopia.com> Message-ID: <47A46743.5080801@gmail.com> Leandro, sorry for the late reply. I've been busy over here. Leandro R?os wrote: > Sorry for getting back late. I've been doing some debugging, and this is > what I found so far: > > The error is raised in SBCL's %make-alien function, file > target-alienval.lisp. More precisely: > > (defun %make-alien (bits) > (declare (type index bits)) > (alien-funcall (extern-alien "malloc" > (function system-area-pointer unsigned)) > (ash (the index (+ bits 7)) -3))) <<<<<<< Alright, so the error actually occurs in one of SBCLs source files. > This is the backtrace of the last debugging step before the error occurs: > > Evaluating call: > (ASH (THE SB-INT:INDEX (+ SB-SYS:BITS 7)) -3) > With unknown arguments > Backtrace: > 0: (CFFI:FOREIGN-ALLOC :INT) > 1: (GTK-FFI:GTK-LIST-STORE-NEW (:STRING :STRING)) > 2: ((LAMBDA > (CELLS::SLOT-C > &AUX (CELLS:SELF (CELLS::C-MODEL CELLS::SLOT-C)) > (CELLS:.CACHE (CELLS::C-VALUE CELLS::SLOT-C)))) > [?#:=[0]ID/LIST-STORE]) Here is what list-store-new does: (defun gtk-list-store-new (col-types) (let ((c-types (cffi:foreign-alloc :int :count (length col-types)))) (loop for type in col-types for n upfrom 0 do (setf (cffi:mem-aref c-types :int n) (coerce (as-gtk-type type) 'integer))) (prog1 (gtk-list-store-newv (length col-types) c-types) (cffi:foreign-free c-types)))) So the call to foreign-alloc :int :count x is the first thing here. That leads to this one (size is (* count (size-of :int))): (defun %foreign-alloc (size) "Allocate SIZE bytes on the heap and return a pointer." (alien-sap (make-alien (unsigned 8) size))) Which then goes to the step you had above. > Next step, it hangs. So AFAICT the problem really seems to be with sbcl's foreign function interface. You are using the latest SBCL, right? Maybe we should take this to their list. > It seems that the problem originates in the call to > (cells:md-slot-value list-store cells-gtk:new-args) only, calling the > function with other parameters succeeds. > I don't know enough about cffi or sbcl internals to determine if it is a > malformed call from cffi or a bug in sbcl itself. Me neither, so maybe you should go ahead and ask them. > If you need me to perform any test you can think of, I'll be pleased to > do so. Thanks for your help, Peter. Great, thanks for your help. I do think your best bet is to ask in the sbcl newsgroup or on their mailing list, though. You might find someone on c.l.l, too, since the sbcl coders seem to be regulars there. Cheers, Peter > > Leandro > From ibormuth at efil.de Sat Feb 2 15:03:33 2008 From: ibormuth at efil.de (Ingo Bormuth) Date: Sat, 2 Feb 2008 16:03:33 +0100 Subject: [cells-gtk-devel] "First steps" how to compile problem - fixed In-Reply-To: <47A460B5.7000505@gmail.com> References: <479C80E5.7050409@gmail.com> <200801311957.55181.bwillan@matrix-systems-inc.com> <47A3064E.108@gmail.com> <200802011653.13779.bwillan@matrix-systems-inc.com> <47A460B5.7000505@gmail.com> Message-ID: <20080202150333.GA8872@efil.de> On 2008-02-02 13:23, Peter Hildebrandt wrote: > 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. Check out qemulator (http://qemulator.createweb.de/). Together with qemu this is as simple to use as vmware, without the need to constantly compile an external kernel module, which actually makes it even more convenient ;) -- Ingo Bormuth, voicebox & fax: +49-(0)-12125-10226517 public key 86326EC9, http://ibormuth.efil.de/contact From roerdhh at googlemail.com Wed Feb 6 22:25:00 2008 From: roerdhh at googlemail.com (=?ISO-8859-1?Q?R=F6rd_Hinrichsen?=) Date: Wed, 6 Feb 2008 23:25:00 +0100 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" Message-ID: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> Hello, "load.lisp" doesn't yet include the path to the ph-maths library. I suggest these changes: $ cvs diff -u load.lisp Index: load.lisp =================================================================== RCS file: /project/cells-gtk/cvsroot/load.lisp,v retrieving revision 1.3 diff -u -r1.3 load.lisp --- load.lisp 30 Jun 2006 15:24:21 -0000 1.3 +++ load.lisp 6 Feb 2008 22:00:02 -0000 @@ -29,12 +29,14 @@ #P"cells-gtk:cffi;" #P"cells-gtk:root;pod-utils;" #P"cells-gtk:root;gtk-ffi;" + #P"cells-gtk:root;ph-maths;" #P"cells-gtk:root;cells-gtk;" #P"cells-gtk:root;cells-gtk;test-gtk;"))) (asdf:oos 'asdf:load-op :cells) (asdf:oos 'asdf:load-op :cffi) (asdf:oos 'asdf:load-op :cffi-uffi-compat) (asdf:oos 'asdf:load-op :gtk-ffi) + (asdf:oos 'asdf:load-op :ph-maths) (asdf:oos 'asdf:load-op :cells-gtk) (asdf:oos 'asdf:load-op :test-gtk)) R?rd -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.hildebrandt at gmail.com Thu Feb 7 10:16:03 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 07 Feb 2008 11:16:03 +0100 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" In-Reply-To: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> References: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> Message-ID: <47AADA63.7020007@gmail.com> Roerd, thanks for spotting this. However, I don't see a load.lisp in CVS. Did you install cells-gtk from CVS, from one of the tarballs, or from asdf-install? We have recently changed cells-gtk quite a bit, but the changes are only available in CVS, so I'd recommend you go with that. The preferred method to load cells-gtk is via asdf. I explain this in more detail in my guide over here: http://www.washbear-network.de/peterblog/getting-started-with-cells-gtk/ (I know, I should get my own (less silly) domain at some point) If you have further questions, let us know. Peter R?rd Hinrichsen wrote: > Hello, > > "load.lisp" doesn't yet include the path to the ph-maths library. I > suggest these changes: > > $ cvs diff -u load.lisp > Index: load.lisp > =================================================================== > RCS file: /project/cells-gtk/cvsroot/load.lisp,v > retrieving revision 1.3 > diff -u -r1.3 load.lisp > --- load.lisp 30 Jun 2006 15:24:21 -0000 1.3 > +++ load.lisp 6 Feb 2008 22:00:02 -0000 > @@ -29,12 +29,14 @@ > #P"cells-gtk:cffi;" > #P"cells-gtk:root;pod-utils;" > #P"cells-gtk:root;gtk-ffi;" > + #P"cells-gtk:root;ph-maths;" > #P"cells-gtk:root;cells-gtk;" > #P"cells-gtk:root;cells-gtk;test-gtk;"))) > (asdf:oos 'asdf:load-op :cells) > (asdf:oos 'asdf:load-op :cffi) > (asdf:oos 'asdf:load-op :cffi-uffi-compat) > (asdf:oos 'asdf:load-op :gtk-ffi) > + (asdf:oos 'asdf:load-op :ph-maths) > (asdf:oos 'asdf:load-op :cells-gtk) > (asdf:oos 'asdf:load-op :test-gtk)) > > R?rd > > > ------------------------------------------------------------------------ > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From peter.hildebrandt at gmail.com Thu Feb 7 13:43:45 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 07 Feb 2008 14:43:45 +0100 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" In-Reply-To: <47AADA63.7020007@gmail.com> References: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> <47AADA63.7020007@gmail.com> Message-ID: <47AB0B11.3010809@gmail.com> Peter Hildebrandt wrote: > thanks for spotting this. However, I don't see a load.lisp in CVS. Did > you install cells-gtk from CVS, from one of the tarballs, or from > asdf-install? Sorry, my bad here. I just learned that load.lisp is supposed to be in CVS, too. I will get it from the tarballs, merge in your patch (so it is useful, after all!), and commit it to CVS later tonight. > > We have recently changed cells-gtk quite a bit, but the changes are only > available in CVS, so I'd recommend you go with that. The preferred > method to load cells-gtk is via asdf. I was wrong here. The (load "load") method should work, too. Peter I explain this in more detail in > my guide over here: > > http://www.washbear-network.de/peterblog/getting-started-with-cells-gtk/ > > (I know, I should get my own (less silly) domain at some point) > > If you have further questions, let us know. > > Peter > > > R?rd Hinrichsen wrote: >> Hello, >> >> "load.lisp" doesn't yet include the path to the ph-maths library. I >> suggest these changes: >> >> $ cvs diff -u load.lisp >> Index: load.lisp >> =================================================================== >> RCS file: /project/cells-gtk/cvsroot/load.lisp,v >> retrieving revision 1.3 >> diff -u -r1.3 load.lisp >> --- load.lisp 30 Jun 2006 15:24:21 -0000 1.3 >> +++ load.lisp 6 Feb 2008 22:00:02 -0000 >> @@ -29,12 +29,14 @@ >> #P"cells-gtk:cffi;" >> #P"cells-gtk:root;pod-utils;" >> #P"cells-gtk:root;gtk-ffi;" >> + #P"cells-gtk:root;ph-maths;" >> #P"cells-gtk:root;cells-gtk;" >> #P"cells-gtk:root;cells-gtk;test-gtk;"))) >> (asdf:oos 'asdf:load-op :cells) >> (asdf:oos 'asdf:load-op :cffi) >> (asdf:oos 'asdf:load-op :cffi-uffi-compat) >> (asdf:oos 'asdf:load-op :gtk-ffi) >> + (asdf:oos 'asdf:load-op :ph-maths) >> (asdf:oos 'asdf:load-op :cells-gtk) >> (asdf:oos 'asdf:load-op :test-gtk)) >> >> R?rd >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> cells-gtk-devel site list >> cells-gtk-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/cells-gtk-devel From peter.denno at nist.gov Thu Feb 7 14:08:57 2008 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 7 Feb 2008 09:08:57 -0500 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" In-Reply-To: <47AB0B11.3010809@gmail.com> References: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> <47AADA63.7020007@gmail.com> <47AB0B11.3010809@gmail.com> Message-ID: <200802070908.58351.peter.denno@nist.gov> On Thursday 07 February 2008 08:43, Peter Hildebrandt wrote: > Peter Hildebrandt wrote: > > thanks for spotting this. However, I don't see a load.lisp in > > CVS. Did you install cells-gtk from CVS, from one of the > > tarballs, or from asdf-install? > > Sorry, my bad here. I just learned that load.lisp is supposed to > be in CVS, too. I will get it from the tarballs, merge in your > patch (so it is useful, after all!), and commit it to CVS later > tonight. The tarballs also have a INSTALL.txt. I haven't checked CVS for this, but it contains just the follow: To compile and run: STEP 0: WINDOWS USERS: Do the stuff marked "Windows Users" below. STEP .5: CLISP Users edit the path in ./load.lisp (you'll see it). STEP 1: EVERYONE: Start lisp, change to this directory and do (load "load") STEP 2: EVERYONE: (test-gtk::gtk-demo) STEP 3: ANYONE (optional) make libcellsgtk, (or get it from the cells-gtk site). To make: 3a) In ./root/gtk-ffi 'make' 3b) Move the library created to where it will be found (Linux see /etc/ld.so.conf). 3c) Uncomment the line (pushnew :libcellsgtk *features*) in ./root/gtk-ffi/gtk-ffi.asd 3d) Recompile the distribution (remove fasls and type (load "load") again. TESTED ON: Windows XP: (with gtk 2.4.10) AllegroCL 6.2 Enterprise, Lispworks 4.3 Personal Windows 2000: CLISP 2.38 Linux: Lispworks 4.4 Pro, CMUCL 19c, CLISP 2.36 SBCL 0.9.9.1 NOT TESTED SINCE SWITCHING TO CFFI: (as of 2006-01-03): AllegroCL MACOSX ;;; -------- Windows Users --------------- Get GTK and Install http://gimp-win.sourceforge.net/stable.html (I used version 2.8.9) Executing the setup.exe should add "C:\Program Files\Common Files\GTK\2.0\bin" to your path. You can verify that it has: Start>Settings>Control Panel>System>Advanced>Environment Variables> (I had to reboot after this, but then I don't know anything about Win32). Note: On windows under emacs with slime, the gtk window does not popup. You must start the application from a dos prompt. (Solutions to this problem welcome!, probably involves putting something like a call to gtk-iteration-do into some slime loop through a hook.) Known bugs: On Windows: Clisp crashes if [My Computer]-> [Properties]-> [Advanced]-> [Perfomance Settings]-> [Show windows contents while dragging] is set and resize the window while viewing a listbox or treebox. > > > We have recently changed cells-gtk quite a bit, but the changes > > are only available in CVS, so I'd recommend you go with that. > > The preferred method to load cells-gtk is via asdf. > > I was wrong here. The (load "load") method should work, too. > > Peter > > I explain this in more detail in > > > my guide over here: > > > > http://www.washbear-network.de/peterblog/getting-started-with-cel > >ls-gtk/ > > > > (I know, I should get my own (less silly) domain at some point) > > > > If you have further questions, let us know. > > > > Peter > > > > R?rd Hinrichsen wrote: > >> Hello, > >> > >> "load.lisp" doesn't yet include the path to the ph-maths > >> library. I suggest these changes: > >> > >> $ cvs diff -u load.lisp > >> Index: load.lisp > >> ================================================================ > >>=== RCS file: /project/cells-gtk/cvsroot/load.lisp,v > >> retrieving revision 1.3 > >> diff -u -r1.3 load.lisp > >> --- load.lisp 30 Jun 2006 15:24:21 -0000 1.3 > >> +++ load.lisp 6 Feb 2008 22:00:02 -0000 > >> @@ -29,12 +29,14 @@ > >> #P"cells-gtk:cffi;" > >> #P"cells-gtk:root;pod-utils;" > >> #P"cells-gtk:root;gtk-ffi;" > >> + #P"cells-gtk:root;ph-maths;" > >> #P"cells-gtk:root;cells-gtk;" > >> #P"cells-gtk:root;cells-gtk;test-gtk;"))) > >> (asdf:oos 'asdf:load-op :cells) > >> (asdf:oos 'asdf:load-op :cffi) > >> (asdf:oos 'asdf:load-op :cffi-uffi-compat) > >> (asdf:oos 'asdf:load-op :gtk-ffi) > >> + (asdf:oos 'asdf:load-op :ph-maths) > >> (asdf:oos 'asdf:load-op :cells-gtk) > >> (asdf:oos 'asdf:load-op :test-gtk)) > >> > >> R?rd > >> > >> > >> ---------------------------------------------------------------- > >>-------- > >> > >> _______________________________________________ > >> cells-gtk-devel site list > >> cells-gtk-devel at common-lisp.net > >> http://common-lisp.net/mailman/listinfo/cells-gtk-devel > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel -- Best regards, - Peter -------------- next part -------------- To compile and run: STEP 0: WINDOWS USERS: Do the stuff marked "Windows Users" below. STEP .5: CLISP Users edit the path in ./load.lisp (you'll see it). STEP 1: EVERYONE: Start lisp, change to this directory and do (load "load") STEP 2: EVERYONE: (test-gtk::gtk-demo) STEP 3: ANYONE (optional) make libcellsgtk, (or get it from the cells-gtk site). To make: 3a) In ./root/gtk-ffi 'make' 3b) Move the library created to where it will be found (Linux see /etc/ld.so.conf). 3c) Uncomment the line (pushnew :libcellsgtk *features*) in ./root/gtk-ffi/gtk-ffi.asd 3d) Recompile the distribution (remove fasls and type (load "load") again. TESTED ON: Windows XP: (with gtk 2.4.10) AllegroCL 6.2 Enterprise, Lispworks 4.3 Personal Windows 2000: CLISP 2.38 Linux: Lispworks 4.4 Pro, CMUCL 19c, CLISP 2.36 SBCL 0.9.9.1 NOT TESTED SINCE SWITCHING TO CFFI: (as of 2006-01-03): AllegroCL MACOSX ;;; -------- Windows Users --------------- Get GTK and Install http://gimp-win.sourceforge.net/stable.html (I used version 2.8.9) Executing the setup.exe should add "C:\Program Files\Common Files\GTK\2.0\bin" to your path. You can verify that it has: Start>Settings>Control Panel>System>Advanced>Environment Variables> (I had to reboot after this, but then I don't know anything about Win32). Note: On windows under emacs with slime, the gtk window does not popup. You must start the application from a dos prompt. (Solutions to this problem welcome!, probably involves putting something like a call to gtk-iteration-do into some slime loop through a hook.) Known bugs: On Windows: Clisp crashes if [My Computer]-> [Properties]-> [Advanced]-> [Perfomance Settings]-> [Show windows contents while dragging] is set and resize the window while viewing a listbox or treebox. From roerdhh at googlemail.com Thu Feb 7 14:22:02 2008 From: roerdhh at googlemail.com (=?ISO-8859-1?Q?R=F6rd_Hinrichsen?=) Date: Thu, 7 Feb 2008 15:22:02 +0100 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" In-Reply-To: <47AADA63.7020007@gmail.com> References: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> <47AADA63.7020007@gmail.com> Message-ID: <1517b2890802070622v14dcb7e0x1a6e4d2fdf6a1c5f@mail.gmail.com> Hello, 2008/2/7, Peter Hildebrandt : > > thanks for spotting this. However, I don't see a load.lisp in CVS. Did > you install cells-gtk from CVS, from one of the tarballs, or from > asdf-install? I got it from CVS. It isn't in the directory called "root", but in the real root of the CVS tree. R?rd -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.denno at nist.gov Thu Feb 7 15:39:38 2008 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 7 Feb 2008 10:39:38 -0500 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" In-Reply-To: <1517b2890802070622v14dcb7e0x1a6e4d2fdf6a1c5f@mail.gmail.com> References: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> <47AADA63.7020007@gmail.com> <1517b2890802070622v14dcb7e0x1a6e4d2fdf6a1c5f@mail.gmail.com> Message-ID: <200802071039.38350.peter.denno@nist.gov> On Thursday 07 February 2008 09:22, R?rd Hinrichsen wrote: > Hello, > > 2008/2/7, Peter Hildebrandt : > > thanks for spotting this. However, I don't see a load.lisp in > > CVS. Did you install cells-gtk from CVS, from one of the > > tarballs, or from asdf-install? > > I got it from CVS. It isn't in the directory called "root", but in > the real root of the CVS tree. Makes sense, since it loads all the components, whereas the directory called "root" only concerns cells-gtk. > > R?rd -- Best regards, - Peter From peter.hildebrandt at gmail.com Thu Feb 7 16:21:39 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 07 Feb 2008 17:21:39 +0100 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" In-Reply-To: <200802071039.38350.peter.denno@nist.gov> References: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> <47AADA63.7020007@gmail.com> <1517b2890802070622v14dcb7e0x1a6e4d2fdf6a1c5f@mail.gmail.com> <200802071039.38350.peter.denno@nist.gov> Message-ID: <47AB3013.3090502@gmail.com> Peter Denno wrote: > On Thursday 07 February 2008 09:22, R?rd Hinrichsen wrote: >> Hello, >> >> 2008/2/7, Peter Hildebrandt : >>> thanks for spotting this. However, I don't see a load.lisp in >>> CVS. Did you install cells-gtk from CVS, from one of the >>> tarballs, or from asdf-install? >> I got it from CVS. It isn't in the directory called "root", but in >> the real root of the CVS tree. > > Makes sense, since it loads all the components, whereas the directory > called "root" only concerns cells-gtk. Alright, I see where I was mistaken. I used "root" as the module I checked out from cvs, thus never saw the directory above that. Plus, when you use the CVS link on the homepage, it gets you right into the root dir: http://common-lisp.net/cgi-bin/viewcvs.cgi/root/?cvsroot=cells-gtk and not here: http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells-gtk#dirlist So both files (INSTALL.TXT and load.lisp) live there. Sorry about all the confusion. R?rd, I applied your patch right now. Peter. >> R?rd > From peter.hildebrandt at gmail.com Thu Feb 7 16:22:28 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 07 Feb 2008 17:22:28 +0100 Subject: [cells-gtk-devel] Patch suggestion for "load.lisp" In-Reply-To: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> References: <1517b2890802061425s5bebfda0ic16ff73ff81b4989@mail.gmail.com> Message-ID: <47AB3044.2050908@gmail.com> Sorry about all the confusion. I applied your patch to CVS a few minutes ago. Again, thanks, for your help. Peter R?rd Hinrichsen wrote: > Hello, > > "load.lisp" doesn't yet include the path to the ph-maths library. I > suggest these changes: > > $ cvs diff -u load.lisp > Index: load.lisp > =================================================================== > RCS file: /project/cells-gtk/cvsroot/load.lisp,v > retrieving revision 1.3 > diff -u -r1.3 load.lisp > --- load.lisp 30 Jun 2006 15:24:21 -0000 1.3 > +++ load.lisp 6 Feb 2008 22:00:02 -0000 > @@ -29,12 +29,14 @@ > #P"cells-gtk:cffi;" > #P"cells-gtk:root;pod-utils;" > #P"cells-gtk:root;gtk-ffi;" > + #P"cells-gtk:root;ph-maths;" > #P"cells-gtk:root;cells-gtk;" > #P"cells-gtk:root;cells-gtk;test-gtk;"))) > (asdf:oos 'asdf:load-op :cells) > (asdf:oos 'asdf:load-op :cffi) > (asdf:oos 'asdf:load-op :cffi-uffi-compat) > (asdf:oos 'asdf:load-op :gtk-ffi) > + (asdf:oos 'asdf:load-op :ph-maths) > (asdf:oos 'asdf:load-op :cells-gtk) > (asdf:oos 'asdf:load-op :test-gtk)) > > R?rd > > > ------------------------------------------------------------------------ > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From peter.denno at nist.gov Thu Feb 14 22:43:19 2008 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 14 Feb 2008 17:43:19 -0500 Subject: [cells-gtk-devel] terminate-gtk Message-ID: <200802141743.19530.peter.denno@nist.gov> Hi, gtk-app.lisp in CVS HEAD contains this: (defun stop-gtk-main () "Final clean up stuff -- need to RESTART lisp to access gtk again." (terminate-gtk) (threads:destroy-thread gtk-main-thread)) I don't see terminate-gtk anywhere. -- Best regards, - Peter From peter.hildebrandt at gmail.com Fri Feb 15 09:56:30 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Fri, 15 Feb 2008 10:56:30 +0100 Subject: [cells-gtk-devel] terminate-gtk In-Reply-To: <200802141743.19530.peter.denno@nist.gov> References: <200802141743.19530.peter.denno@nist.gov> Message-ID: <47B561CE.60508@gmail.com> Peter, thanks for spotting this. This is a "note to self" sort of thing. The whole idea of terminating the GTK thread is ill conceived. Neither stop-gtk-main nor terminate-gtk are neither used anywhere nor exported. I will remove them ASAP. (I have been busy with cells3-gtk in the last week) Peter Peter Denno wrote: > Hi, > > gtk-app.lisp in CVS HEAD contains this: > > (defun stop-gtk-main () > "Final clean up stuff -- need to RESTART lisp to access gtk > again." > (terminate-gtk) > (threads:destroy-thread gtk-main-thread)) > > I don't see terminate-gtk anywhere. > > From peter.denno at nist.gov Fri Feb 15 13:18:00 2008 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 15 Feb 2008 08:18:00 -0500 Subject: [cells-gtk-devel] terminate-gtk In-Reply-To: <47B561CE.60508@gmail.com> References: <200802141743.19530.peter.denno@nist.gov> <47B561CE.60508@gmail.com> Message-ID: <200802150818.00951.peter.denno@nist.gov> On Friday 15 February 2008 04:56, Peter Hildebrandt wrote: > Peter, > > thanks for spotting this. This is a "note to self" sort of thing. > The whole idea of terminating the GTK thread is ill conceived. > Neither stop-gtk-main nor terminate-gtk are neither used anywhere > nor exported. I will remove them ASAP. (I have been busy with > cells3-gtk in the last week) Hi Peter, So is there a way now to stop Cells-gtk? I have a Lispworks application for which I make a .exe, and on quitting, the linux process does not end. I have to use the linux kill command. Thanks. > > Peter > > Peter Denno wrote: > > Hi, > > > > gtk-app.lisp in CVS HEAD contains this: > > > > (defun stop-gtk-main () > > "Final clean up stuff -- need to RESTART lisp to access > > gtk again." > > (terminate-gtk) > > (threads:destroy-thread gtk-main-thread)) > > > > I don't see terminate-gtk anywhere. -- Best regards, - Peter From peter.hildebrandt at gmail.com Sat Feb 16 09:27:30 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Sat, 16 Feb 2008 10:27:30 +0100 Subject: [cells-gtk-devel] terminate-gtk In-Reply-To: <200802150818.00951.peter.denno@nist.gov> References: <200802141743.19530.peter.denno@nist.gov> <47B561CE.60508@gmail.com> <200802150818.00951.peter.denno@nist.gov> Message-ID: <47B6AC82.4000706@gmail.com> Hi Peter, > So is there a way now to stop Cells-gtk? I have a Lispworks > application for which I make a .exe, and on quitting, the linux > process does not end. I have to use the linux kill command. Wow, I must have been blin, sorry for missing this -- yes, there is no other way. That's what I get for not having a "real world" test case here. So, the call to (terminate-gtk) should be (close-all-windows), then :stop-gtk-main should be exported, and is the right way to stop gtk. I won't get round to committing this until Tuesday, so it'd be great if you could change it in CVS. Peter Peter Denno wrote: > On Friday 15 February 2008 04:56, Peter Hildebrandt wrote: >> Peter, >> >> thanks for spotting this. This is a "note to self" sort of thing. >> The whole idea of terminating the GTK thread is ill conceived. >> Neither stop-gtk-main nor terminate-gtk are neither used anywhere >> nor exported. I will remove them ASAP. (I have been busy with >> cells3-gtk in the last week) > > Hi Peter, > > So is there a way now to stop Cells-gtk? I have a Lispworks > application for which I make a .exe, and on quitting, the linux > process does not end. I have to use the linux kill command. > > > Thanks. > >> Peter >> >> Peter Denno wrote: >>> Hi, >>> >>> gtk-app.lisp in CVS HEAD contains this: >>> >>> (defun stop-gtk-main () >>> "Final clean up stuff -- need to RESTART lisp to access >>> gtk again." >>> (terminate-gtk) >>> (threads:destroy-thread gtk-main-thread)) >>> >>> I don't see terminate-gtk anywhere. > From peter.hildebrandt at gmail.com Thu Feb 21 11:29:06 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 21 Feb 2008 12:29:06 +0100 Subject: [cells-gtk-devel] terminate-gtk In-Reply-To: <200802150818.00951.peter.denno@nist.gov> References: <200802141743.19530.peter.denno@nist.gov> <47B561CE.60508@gmail.com> <200802150818.00951.peter.denno@nist.gov> Message-ID: <47BD6082.1060408@gmail.com> Peter Denno wrote: > Hi Peter, > > So is there a way now to stop Cells-gtk? I have a Lispworks > application for which I make a .exe, and on quitting, the linux > process does not end. I have to use the linux kill command. > Sorry for the late response. I have been tied up in other issues, and only got back to my project yesterday. The issue here is that GTK only wants to accept calls to gtk-main from one thread per process, and there appears to be no way around that. That means that the GTK thread has to run as long as the lisp process itself. This puts us in an unfortunate situation: - If we kill the GTK thread when the main window is closed, we'd have to restart out lisp process for every test run (which, of course, is not ideal). - If we leave the GTK thread running, the lisp process never quits because of the active thread. I am not sure what would be the right way to deal with this. So far, I have only used threading while developing my application and disabled it before creating an executable (That is, I used start-win during the debugging process and changed it to start-app before creating the actual application). Thus I circumvented the issue. There a two problems with an explicit call to terminate-gtk: (1) We do not want to call it during the debugging -- Thus we'd always have to comment/uncomment the call, use a parameter, use a feature, etc. This is not too hard, but messy. (2) It is non-trivial to put this call in the right place (which is why I vaguely said it was "ill-conceived"). If the gtk-main thread is terminated prematurely, the user is left with non-reactive "zombie windows". If I remember correctly, it is in particular not a good idea to call terminate-gtk in any gtk callback (like for instance on-destroy, on-clicked for the Quit menu option etc.) The right way to deal with it would be to have the gtk main-loop in gtk-app.lisp deal with the situation. This is currently an infinite loop, calling gtk-main, wait until it returns whenever a window is closed, and call it again right away. What we'd want to do is check whether there are open windows left when gtk-main returns, and if not, manually process all pending events and then return from the thread. We'd have to options to deal with the debugging mode (1) Just open a window when you start your debugging session: (start-win 'window) And keep it around until you are done (2) Have a flag (a special variable) which controls the exit behavior of the main loop Probably I won't get around to this until next week. Peter On a different note, cells-gtk3 is coming along, and I hope I can commit a first usable version for testing to the cells cvs soon. Currently the cells-tree-view is still broken and I have not started porting the drawing-area from cells2 to cells3. If anyone wants to play, let me know and I will zip up what I have here. > Thanks. > >> Peter >> >> Peter Denno wrote: >>> Hi, >>> >>> gtk-app.lisp in CVS HEAD contains this: >>> >>> (defun stop-gtk-main () >>> "Final clean up stuff -- need to RESTART lisp to access >>> gtk again." >>> (terminate-gtk) >>> (threads:destroy-thread gtk-main-thread)) >>> >>> I don't see terminate-gtk anywhere. > From roby.giana at tiscali.it Thu Feb 28 08:46:09 2008 From: roby.giana at tiscali.it (roberto) Date: Thu, 28 Feb 2008 09:46:09 +0100 Subject: [cells-gtk-devel] Patches Message-ID: <200802280946.09326.roby.giana@tiscali.it> Hi Peter, my name is Roberto, and I'm from Italy. First of all, thank you for what u have done. Second ( but maybe first ), excuse me for my really BAD english...! Third, the problem: I have cells-gtk-2006-06-30. When I try to fire-up the gtk-demo, everything' s okay, and so for other little gtk apps. But when I patch the files with yours cgtk-full-08-01-19.patch, here where arises the problem ! I had patched every files by hand, so I believe that the problem is elsewhere. In the repl ( I use emacs with slime ) I have this message, after: (require 'test-gtk) (in-package :test-gtk) (start-win 'test-gtk) Attempt to call an undefined alien function. [Condition of type SB-KERNEL: : UNDEFINED-ALIEN-FUNCTION-ERROR] ........ ........ ("foreign function: call_into_lisp") ("foreign function: funcall0") ("foreign function: undefined_alien_function") ....... Any idea? My links seems to work with the "old" version... Sorry again, but I'm not a programmer... If u want, ask me if u need any other informations . I run it all under Linux Mepis 2.6.22-1. Thank you very much again, Roberto From peter.hildebrandt at gmail.com Thu Feb 28 09:14:34 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 28 Feb 2008 10:14:34 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <200802280946.09326.roby.giana@tiscali.it> References: <200802280946.09326.roby.giana@tiscali.it> Message-ID: <47C67B7A.3040409@gmail.com> Hi Roberto, welcome aboard! And don't worry, your English is just fine. (I'm not a native speaker either, though ;-) Anyway, as to the problem that you run into: My first guess is that you need to rebuild the libcellsgtk thing: cd cells-gtk/gtk-ffi make You might need to move it to something like /usr/lib: sudo cp libcellsgtk.so /usr/lib/ You might need to check whether you have an older version of libcellsgtk.so somewhere in you system: find / -name libcellsgtk.so For further debugging, please try (let ((*gtk-debug* t)) (start-win 'test-gtk)) And send us the part of the output right before the error occurs. Let us know how things are going, Peter roberto wrote: > Hi Peter, > my name is Roberto, and I'm from Italy. First of all, thank you for what u > have done. Second ( but maybe first ), excuse me for my really BAD > english...! Third, the problem: > I have cells-gtk-2006-06-30. When I try to fire-up the gtk-demo, everything' s > okay, and so for other little gtk apps. But when I patch the files with yours > cgtk-full-08-01-19.patch, here where arises the problem ! I had patched every > files by hand, so I believe that the problem is elsewhere. In the repl ( I > use emacs with slime ) I have this message, after: > (require 'test-gtk) > (in-package :test-gtk) > (start-win 'test-gtk) > > Attempt to call an undefined alien function. > [Condition of type SB-KERNEL: : UNDEFINED-ALIEN-FUNCTION-ERROR] > ........ > ........ > ("foreign function: call_into_lisp") > ("foreign function: funcall0") > ("foreign function: undefined_alien_function") > ....... > > Any idea? My links seems to work with the "old" version... Sorry again, but > I'm not a programmer... If u want, ask me if u need any other informations . > I run it all under Linux Mepis 2.6.22-1. Thank you very much again, > Roberto > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From roby.giana at tiscali.it Thu Feb 28 16:33:46 2008 From: roby.giana at tiscali.it (roberto) Date: Thu, 28 Feb 2008 17:33:46 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <47C67B7A.3040409@gmail.com> References: <200802280946.09326.roby.giana@tiscali.it> <47C67B7A.3040409@gmail.com> Message-ID: <200802281733.46569.roby.giana@tiscali.it> On Thursday 28 February 2008 10:14:34 am Peter Hildebrandt wrote: > Hi Roberto, > > welcome aboard! And don't worry, your English is just fine. (I'm not a > native speaker either, though ;-) > > Anyway, as to the problem that you run into: My first guess is that you > need to rebuild the libcellsgtk thing: > > cd cells-gtk/gtk-ffi > make > > You might need to move it to something like /usr/lib: > > sudo cp libcellsgtk.so /usr/lib/ > > You might need to check whether you have an older version of > libcellsgtk.so somewhere in you system: > > find / -name libcellsgtk.so > > For further debugging, please try > > (let ((*gtk-debug* t)) > (start-win 'test-gtk)) > > And send us the part of the output right before the error occurs. > > Let us know how things are going, > > Peter > > roberto wrote: > > Hi Peter, > > my name is Roberto, and I'm from Italy. First of all, thank you for what > > u have done. Second ( but maybe first ), excuse me for my really BAD > > english...! Third, the problem: > > I have cells-gtk-2006-06-30. When I try to fire-up the gtk-demo, > > everything' s okay, and so for other little gtk apps. But when I patch > > the files with yours cgtk-full-08-01-19.patch, here where arises the > > problem ! I had patched every files by hand, so I believe that the > > problem is elsewhere. In the repl ( I use emacs with slime ) I have this > > message, after: > > (require 'test-gtk) > > (in-package :test-gtk) > > (start-win 'test-gtk) > > > > Attempt to call an undefined alien function. > > [Condition of type SB-KERNEL: : UNDEFINED-ALIEN-FUNCTION-ERROR] > > ........ > > ........ > > ("foreign function: call_into_lisp") > > ("foreign function: funcall0") > > ("foreign function: undefined_alien_function") > > ....... > > > > Any idea? My links seems to work with the "old" version... Sorry again, > > but I'm not a programmer... If u want, ask me if u need any other > > informations . I run it all under Linux Mepis 2.6.22-1. Thank you very > > much again, Roberto > > _______________________________________________ > > cells-gtk-devel site list > > cells-gtk-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/cells-gtk-devel Hi again, Peter. Now I have this message, after I try: (require 'bordeaux-threads) (require 'test-gtk) (in-package :test-gtk) (start-win 'test-gtk) The function CELLS-GTK: :GTK-TREE-STORE-SET-CELL is undefined. [Condition of type UNDEFINED-FUNCTION] .................... I take a look at the file gtk-utilities.lisp, and it's there...... This is really a can of worms, as you said! ;) From roby.giana at tiscali.it Thu Feb 28 10:32:25 2008 From: roby.giana at tiscali.it (roberto) Date: Thu, 28 Feb 2008 11:32:25 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <47C67B7A.3040409@gmail.com> References: <200802280946.09326.roby.giana@tiscali.it> <47C67B7A.3040409@gmail.com> Message-ID: <200802281132.25578.roby.giana@tiscali.it> Hi Peter, thank you very much for your answer! I did what you told me, and now I have a different problem .... ;) When I try : (let ((*gtk-debug* t)) ? ?(start-win 'test-gtk)) everything's stopped after few line: Calling (gtk-adds-g-thread-supported) (.........) returns 0 <---- It's here the problem? Calling (g-thread-init #. (SB-SYS: INT-SAP #X00000000)) (........) retuns NIL Calling (gdk-threads-init) (........) returns NIL Calling (gtk-init-check #. (SB-SYS: INT-SAP #X00000000) #. (SB-SYS: INT-SAP #X00000000)) (.......) returns T Calling (gtk-init #. (SB-SYS: INT-SAP #X00000000) #. (SB-SYS: INT-SAP #X00000000)) (.......) returns NIL eval (SETF APP (APPLY #'MAKE-INSTANCE APP-NAME VISIBLE (C-IN NIL) INITARGS)) Calling (gtk-statusbar-new) .......................................................... ......and everything stopped. Thank you, Roberto From peter.hildebrandt at gmail.com Thu Feb 28 17:12:25 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 28 Feb 2008 18:12:25 +0100 Subject: [cells-gtk-devel] Blocked IP for mailing-list? Message-ID: <47C6EB79.9080806@gmail.com> I was getting an SMTP failure posting to the list through gmail: Delivery to the following recipient failed permanently: cells-gtk-devel at common-lisp.net Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 13): 554 Service unavailable; Client host [72.14.220.153] blocked using web.dnsbl.sorbs.net; Exploitable Server See: http://www.sorbs.net/lookup.shtml?72.14.220.153 Which is one of gmails mail handlers: nslookup 72.14.220.153 153.220.14.72.in-addr.arpa name = fg-out-1718.google.com. Any ideas? Peter From roby.giana at tiscali.it Thu Feb 28 17:56:51 2008 From: roby.giana at tiscali.it (roberto) Date: Thu, 28 Feb 2008 18:56:51 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <47C6E995.4070807@gmail.com> References: <200802280946.09326.roby.giana@tiscali.it> <200802281132.25578.roby.giana@tiscali.it> <47C6E995.4070807@gmail.com> Message-ID: <200802281856.52987.roby.giana@tiscali.it> Hi Peter, > First of all: I have no good explanation what is going wrong here. I > haven't seen this problem before. Since cells-gtk itself appears to > work for a number of people (myself included), it must be something that > is (slightly) different about your setup. I think that it doesn't work only because I'm not very good in programming, and I do not want makes you to lose time too much... Anyway, let's try, if you want...;) > - I assume you uncommented the (pushnew :cells-gtk-threads *features*) > in cells-gtk/cells-gtk.asd? And after that, you removed all fasls, > restarted sbcl, and did (require 'test-gtk) after that? (Otherwise you > might have stale fasls hanging around. This is an issue with SBCL). I uncommented the line ( or it is uncommented by your patch, I don't remember), next I got a fresh directory of cells-gtk-2006-06-30 (without fasl files, with: cd .../gtk-ffi and: make, cp libscellgtk.so in /usr/lib, where I had the old working version ), restarted emacs, did alt-x slime (and everything's recompiled), and then require bordeaux-threads, and test-gtk. > - Does (start-app 'test-gtk) work? Or is it broken, too? (start-app is > the non-threading part, start-win is the threading part) Note that you > have to restart sbcl before you switch from one to the other. (This is a > GTK issue, GTK is not prepared for something dynamic like lisp. When > you do C, you restart your app for every little test anyway. In Lisp, > you have your app running as long as your lisp session lasts. This is > quite tricky) (start-app 'test-gtk) give me the same error message (also after I recompile all): The function CELLS-GTK: :GTK-TREE-STORE-SET-CELL is undefined. ? ? ? [Condition of type UNDEFINED-FUNCTION] > - Can you (start-win 'window) ? What happens? It appears a little window, but when I try to close it, well, it doesn't close.... > - Remove all fasls, restart lisp, do (pushnew :msg *features*), and > require test-gtk. You will get a debug build with further debugging output. I did : (pushnew :msg *features*) and appears: (:MSG :CELLS_GTK_THREADS :LIBCELLSGTK CFFI-FEATURES:X(& CFFI-FEATURES:UNIX :CFFI :CELLS :BORDEAUX-THREADS :THREAD-SUPPORT :SB-BSD-SOCKETS-ADDRINFO :ASDF :SB-THREADS :ANSI-CL :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE_LOCKS :SB-UNICODE :SB-EVAL :SB-SOURCE_LOCATIONS :IEEEE-FLOATING-POINT :X86 :UNIX :ELF :LINUX :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK :COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP :STACK-ALLOCATABLE-CLOSURES :ALIEN-CALLBACKS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T) But when I launch: (require 'test-gtk), (in-package :test-gtk) and (start-app 'test-gtk) , it give me the same error message: The function CELLS-GTK: :GTK-TREE-STORE-SET-CELL is undefined. [Condition of type UNDEFINED-FUNCTION] Thanks again, for your answers and for all, Roberto _____________________________________________ > > cells-gtk-devel site list > > cells-gtk-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From roerdhh at googlemail.com Thu Feb 28 20:47:15 2008 From: roerdhh at googlemail.com (Roerd Hinrichsen) Date: Thu, 28 Feb 2008 21:47:15 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <200802281856.52987.roby.giana@tiscali.it> References: <200802280946.09326.roby.giana@tiscali.it> <200802281132.25578.roby.giana@tiscali.it> <47C6E995.4070807@gmail.com> <200802281856.52987.roby.giana@tiscali.it> Message-ID: <47C71DD3.6060409@googlemail.com> Hello Roberto, roberto schrieb: >> - I assume you uncommented the (pushnew :cells-gtk-threads *features*) >> in cells-gtk/cells-gtk.asd? And after that, you removed all fasls, >> restarted sbcl, and did (require 'test-gtk) after that? (Otherwise you >> might have stale fasls hanging around. This is an issue with SBCL). > > I uncommented the line ( or it is uncommented by your patch, I don't > remember), next I got a fresh directory of cells-gtk-2006-06-30 (without fasl > files, with: cd .../gtk-ffi and: make, cp libscellgtk.so in /usr/lib, where I > had the old working version ), restarted emacs, did alt-x slime (and > everything's recompiled), and then require bordeaux-threads, and test-gtk. Do you use an operating system that has common-lisp-controller (Debian, Ubuntu, Gentoo)? In that case, there might be old FASLs hanging around somewhere below /var/cache/common-lisp-controller. HTH R?rd From roby.giana at tiscali.it Fri Feb 29 09:49:30 2008 From: roby.giana at tiscali.it (roberto) Date: Fri, 29 Feb 2008 10:49:30 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <47C70985.9070706@gmail.com> References: <200802280946.09326.roby.giana@tiscali.it> <200802281856.52987.roby.giana@tiscali.it> <47C70985.9070706@gmail.com> Message-ID: <200802291049.30465.roby.giana@tiscali.it> On Thursday 28 February 2008 8:20:37 pm Peter Hildebrandt wrote: > Hi Roberto, > I am pretty confident we can make this work. ?Plus, you'll learn quite a > bit on the way, I hope :-) Hi again, Peter! Maybe, I've done a little bit confusion in my attempt to drive a Ferrari when I always drive a bicycle.... ;) > >> - Does (start-app 'test-gtk) work? ?Or is it broken, too? (start-app is > >> the non-threading part, start-win is the threading part) ?Note that you > >> have to restart sbcl before you switch from one to the other. (This is a > >> GTK issue, GTK is not prepared for something dynamic like lisp. ?When > >> you do C, you restart your app for every little test anyway. ?In Lisp, > >> you have your app running as long as your lisp session lasts. ?This is > >> quite tricky) > > > > (start-app 'test-gtk) give me the same error message (also after I > > recompile all): > > The function CELLS-GTK: :GTK-TREE-STORE-SET-CELL is undefined. > > ? ? ? [Condition of type UNDEFINED-FUNCTION] > > Did you check whether gtk-tree-store-set-cell appears in > gtk-ffi/package.lisp? The problem was here! As I said, I patched everything by hand, but.....yes, I admit: I'M GUILTY!!!! I missed this line..... ?:) ?#:gtk-tree-store-set-cell Now everythings works fine! Thank you, Peter, and also thank's to ? Roerd , for his answer. Now I try something by myself, and maybe (not, sure.. ?;) ), I come back here to ask you other silly questions.... Cheers, Roberto _______________________________________________ > > cells-gtk-devel site list > > cells-gtk-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/cells-gtk-devel From roby.giana at tiscali.it Fri Feb 29 10:06:36 2008 From: roby.giana at tiscali.it (roberto) Date: Fri, 29 Feb 2008 11:06:36 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <47C7D664.10104@optonline.net> References: <200802280946.09326.roby.giana@tiscali.it> <200802291049.30465.roby.giana@tiscali.it> <47C7D664.10104@optonline.net> Message-ID: <200802291106.37058.roby.giana@tiscali.it> On Friday 29 February 2008 10:54:44 am Ken Tilton wrote: > roberto wrote: > > On Thursday 28 February 2008 8:20:37 pm Peter Hildebrandt wrote: > >>Hi Roberto, > >>I am pretty confident we can make this work. Plus, you'll learn quite a > >>bit on the way, I hope :-) > > > > The problem was here! As I said, I patched everything by hand, > > but.....yes, I admit: I'M GUILTY!!!! I missed this line..... :) > > Haha, I almost said something, but when you said "I did this by hand so > I /know/ it is right." I decided I better let you find it on your own. :) > > kenny Hi Kenny, yes.. yes... I know, I was too much pretty confident in my ....hand...... :) By the way, if you are the creator of cells, well, I accept your laughs... ;), and, congratulation for your work! Roberto From roby.giana at tiscali.it Fri Feb 29 10:07:12 2008 From: roby.giana at tiscali.it (roberto) Date: Fri, 29 Feb 2008 11:07:12 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <47C7D664.10104@optonline.net> References: <200802280946.09326.roby.giana@tiscali.it> <200802291049.30465.roby.giana@tiscali.it> <47C7D664.10104@optonline.net> Message-ID: <200802291107.12134.roby.giana@tiscali.it> On Friday 29 February 2008 10:54:44 am Ken Tilton wrote: > roberto wrote: > > On Thursday 28 February 2008 8:20:37 pm Peter Hildebrandt wrote: > >>Hi Roberto, > >>I am pretty confident we can make this work. ?Plus, you'll learn quite a > >>bit on the way, I hope :-) > > > > The problem was here! As I said, I patched everything by hand, > > but.....yes, I admit: I'M GUILTY!!!! I missed this line..... ?:) > > Haha, I almost said something, but when you said "I did this by hand so > I /know/ it is right." I decided I better let you find it on your own. :) > > kenny Hi Kenny, yes.. yes... I know, I was too much pretty confident in my ....hand...... :) By the way, if you are the creator of cells, well, I accept your laughs... ;), and, congratulation for your work! Roberto From peter.hildebrandt at gmail.com Fri Feb 29 11:00:43 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Fri, 29 Feb 2008 12:00:43 +0100 Subject: [cells-gtk-devel] Patches In-Reply-To: <200802291049.30465.roby.giana@tiscali.it> References: <200802280946.09326.roby.giana@tiscali.it> <200802281856.52987.roby.giana@tiscali.it> <47C70985.9070706@gmail.com> <200802291049.30465.roby.giana@tiscali.it> Message-ID: <47C7E5DB.7020507@gmail.com> Hi Roberto, roberto wrote: > On Thursday 28 February 2008 8:20:37 pm Peter Hildebrandt wrote: >> Hi Roberto, >> I am pretty confident we can make this work. Plus, you'll learn quite a >> bit on the way, I hope :-) > > Hi again, Peter! > Maybe, I've done a little bit confusion in my attempt to drive a Ferrari when > I always drive a bicycle.... ;) Given the preconceptions about lisp people usually have, maybe we should say you're used to driving a Japanese made compact and now you find yourself on an 1890s steam train ... :-) >>> The function CELLS-GTK: :GTK-TREE-STORE-SET-CELL is undefined. >>> [Condition of type UNDEFINED-FUNCTION] >> Did you check whether gtk-tree-store-set-cell appears in >> gtk-ffi/package.lisp? > > The problem was here! As I said, I patched everything by hand, but.....yes, I > admit: I'M GUILTY!!!! I missed this line..... :) > #:gtk-tree-store-set-cell > Now everythings works fine! Alright, glad to hear things are working for you now :-) Have fun, and feel free to come back if you have further questions. Peter > Thank you, Peter, and also thank's to > Roerd , for his answer. Now I try something by myself, and maybe (not, > sure.. ;) ), I come back here to ask you other silly questions.... > Cheers, > Roberto > _______________________________________________ >>> cells-gtk-devel site list >>> cells-gtk-devel at common-lisp.net >>> http://common-lisp.net/mailman/listinfo/cells-gtk-devel > > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel