From marco.gidde at tiscali.de Sat May 20 13:25:53 2006 From: marco.gidde at tiscali.de (Marco Gidde) Date: Sat, 20 May 2006 15:25:53 +0200 Subject: [cells-gtk-devel] SBCL patches Message-ID: <85sln43k0u.fsf@tristan.br-automation.com> Hi, recently I started playing with SBCL 0.9.12 and cells-gtk (from CVS) and found a few bugs. Some of these prevented a successful compilation, others where runtime bugs. The first one is a missing argument in pod-utils/utils.lisp: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 811 bytes Desc: pod-utils URL: -------------- next part -------------- gtk-ffi/gtk-utilities.lisp contains two runtime bugs. The first one is in BUTTON-PRESS-EVENT-HANDLER and prevents the pop up of the context menu in the gtk-demo (can be found at the bottom of the "Menus" page tab). The other one is a type mismatch in GTK-FILE-CHOOSER-GET-FILENAMES-STRS which also results in a compiler error. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 1576 bytes Desc: gtk-utilities URL: -------------- next part -------------- The last file with errors is gtk-ffi.lisp and this one is a little bit obscure (at least to me). The defpackage form at the beginning of the file makes SBCL complain about several other symbols also being exported when this form is evaluated for the second time. For some reasons SBCL considers this an *error*, so I changed it to (eval-when (:compile-toplevel :load-toplevel :execute) (unless (find-package :gtk-ffi) (defpackage :gtk-ffi (:use :common-lisp :pod)))) The other problem is that FFI-TO-UFFI-TYPE is not defined at load time, but used in the function CAST. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 1261 bytes Desc: gtk-ffi URL: -------------- next part -------------- With these patches it is possible to load cells-gtk without errors in SBCL and the resulting fasl files also work when a new instance of SBCL is started later (without the patches I had to "touch" a few *.lisp files every time to enforce a recompilation). Regards, Marco From lkman at webmail.co.za Sun May 28 08:33:09 2006 From: lkman at webmail.co.za (Lelanthran Manickum) Date: Sun, 28 May 2006 10:33:09 +0200 Subject: [cells-gtk-devel] only works the first time Message-ID: Hello all I've only ever been able to run the "load.lisp" file once (both on cmucl and clisp). When I run the second time, they both complain, so exactly what is it that I need to run after I've already run load.lisp? All I want to do now is view the demo again without having to rebuild everything (it works if I delete all the compiled files). The other thing is that neither cmucl nor clisp will rerun the core file that was saved after running load.lisp. What must I do to save my core-fire/memory-images if I don't want to keep recompiling or if I want to ship a core-file? Thanks in advance Lee ___________________________________________________________________ For super low premiums, click here http://www.webmail.co.za/dd.pwm http://www.webmail.co.za the South African FREE email service From lkman at webmail.co.za Sun May 28 11:34:16 2006 From: lkman at webmail.co.za (Lelanthran Manickum) Date: Sun, 28 May 2006 13:34:16 +0200 Subject: [cells-gtk-devel] only works the first time In-Reply-To: References: Message-ID: Hello all (I feel like an idiot for replying to my own mail, but anyway ...) After much experimenting, I find that gtk-ffi.lisp has to be *recompiled* on every run (along with all its dependencies. I'm now trying to save a core/image file, but it cannot be done (clisp complains about a foreign pointer from a previous session that is invalid) and I assume that foreign-pointers are not valid between sessions (I, for one, cannot imagine a way for a C pointer to be consistent between successive runs). I'll experiment some more to find a way (sure it exists) to save a corefile minus gtk-ffi and only reload gtk-ffi on restarts (although it takes fairly long to recompile - almost 20 seconds for only gtk-ffi; a full compile takes a couple of minutes). Lee On Sun, 28 May 2006 10:33:09 +0200 "Lelanthran Manickum" wrote: >Hello all > >I've only ever been able to run the "load.lisp" file >once (both on cmucl and clisp). When I run the second >time, they both complain, so exactly what is it that >I need to run after I've already run load.lisp? All I want >to do now is view the demo again without having to rebuild >everything (it works if I delete all the compiled files). > >The other thing is that neither cmucl nor clisp will >rerun the core file that was saved after running >load.lisp. What must I do to save my >core-fire/memory-images >if I don't want to keep recompiling or if I want to >ship a core-file? > >Thanks in advance >Lee ___________________________________________________________________ For super low premiums, click here http://www.webmail.co.za/dd.pwm http://www.webmail.co.za the South African FREE email service From peter.denno at nist.gov Sun May 28 12:50:49 2006 From: peter.denno at nist.gov (Peter Denno) Date: Sun, 28 May 2006 08:50:49 -0400 Subject: [cells-gtk-devel] only works the first time In-Reply-To: References: Message-ID: <200605280850.49557.peter.denno@nist.gov> On Sunday 28 May 2006 07:34, Lelanthran Manickum wrote: > Hello all > > (I feel like an idiot for replying to my own mail, > but anyway ...) > > After much experimenting, I find that gtk-ffi.lisp > has to be *recompiled* on every run (along with all > its dependencies. > > I'm now trying to save a core/image file, but it cannot > be done (clisp complains about a foreign pointer from > a previous session that is invalid) and I assume that > foreign-pointers are not valid between sessions > (I, for one, cannot imagine a way for a C pointer > to be consistent between successive runs). > > I'll experiment some more to find a way (sure it exists) > to save a corefile minus gtk-ffi and only reload > gtk-ffi on restarts (although it takes fairly long > to recompile - almost 20 seconds for only gtk-ffi; a > full compile takes a couple of minutes). Hi, I think our email is crossing paths. It is probably not the recompilation that is doing anything here, but that gtk-ffi:load-gtk-libs is wrapped in a eval-when :compile-toplevel. I think if you should call load-gtk-libs on restart. > > Lee > > On Sun, 28 May 2006 10:33:09 +0200 > > "Lelanthran Manickum" wrote: > >Hello all > > > >I've only ever been able to run the "load.lisp" file > >once (both on cmucl and clisp). When I run the second > >time, they both complain, so exactly what is it that > >I need to run after I've already run load.lisp? All I want > >to do now is view the demo again without having to rebuild > >everything (it works if I delete all the compiled files). > > > >The other thing is that neither cmucl nor clisp will > >rerun the core file that was saved after running > >load.lisp. What must I do to save my > >core-fire/memory-images > >if I don't want to keep recompiling or if I want to > >ship a core-file? > > > >Thanks in advance > >Lee > > ___________________________________________________________________ > For super low premiums, click here http://www.webmail.co.za/dd.pwm > > http://www.webmail.co.za the South African FREE email service > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel -- - Best regards, Peter From peter.denno at nist.gov Sun May 28 12:40:29 2006 From: peter.denno at nist.gov (Peter Denno) Date: Sun, 28 May 2006 08:40:29 -0400 Subject: [cells-gtk-devel] only works the first time In-Reply-To: References: Message-ID: <200605280840.29908.peter.denno@nist.gov> On Sunday 28 May 2006 04:33, Lelanthran Manickum wrote: > Hello all > > I've only ever been able to run the "load.lisp" file > once (both on cmucl and clisp). When I run the second > time, they both complain, so exactly what is it that > I need to run after I've already run load.lisp? All I want > to do now is view the demo again without having to rebuild > everything (it works if I delete all the compiled files). What is the complaint that it makes on the second attempt? > > The other thing is that neither cmucl nor clisp will > rerun the core file that was saved after running > load.lisp. What must I do to save my > core-fire/memory-images > if I don't want to keep recompiling or if I want to > ship a core-file? I haven't tried this myself except for on lispworks. (Perhaps there is something in the cmucl manual about saving core files with loaded libraries???) It probably is related to reloading the libraries, so maybe you could look at doing that again. (see gtk-ffi/gtk-ffi.lisp : load-gtk-libs). > > Thanks in advance > Lee > ___________________________________________________________________ > For super low premiums, click here http://www.webmail.co.za/dd.pwm > > http://www.webmail.co.za the South African FREE email service > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel -- - Best regards, Peter From lkman at webmail.co.za Sun May 28 13:48:50 2006 From: lkman at webmail.co.za (Lelanthran Manickum) Date: Sun, 28 May 2006 15:48:50 +0200 Subject: [cells-gtk-devel] only works the first time In-Reply-To: <200605280850.49557.peter.denno@nist.gov> References: <200605280850.49557.peter.denno@nist.gov> Message-ID: Hello On Sun, 28 May 2006 08:50:49 -0400 Peter Denno wrote: >On Sunday 28 May 2006 07:34, Lelanthran Manickum wrote: >> I'm now trying to save a core/image file, but it cannot >> be done (clisp complains about a foreign pointer from >> a previous session that is invalid) and I assume that >> foreign-pointers are not valid between sessions >> (I, for one, cannot imagine a way for a C pointer >> to be consistent between successive runs). >> I'll address this at the end. >the recompilation that >is doing anything here, but that gtk-ffi:load-gtk-libs is >wrapped in a >eval-when :compile-toplevel. I think if you should call >load-gtk-libs on >restart. > Ok; I cannot actually get gtk-ffi loaded without first removing the compiled gtk-ffi compiled file, so I cannot call load-gtk-libs at all. I've modified the load.lisp file that cells-gtk came with to make the changes to my global asdf:*central-repository*, and I've got anther file which just calls (asdf:operate 'asdf:load-op 'cells) and all the other asdf modules. However, (asdf:operate 'asdf:load-op 'gtk-ffi) won't work unless the compiled gtk-ffi file is removed, and then it compiles it. On another note: I just now attempted loading a corefile which was saved after loading+compiling everything that was needed (and the test application worked as well), however both clisp and cmucl die before I get to a repl. The error message (clisp) is: $ clisp -M gtk-cells.mem *** - FFI::WRITE-MEMORY-AS: # comes from a previous Lisp session and is invalid The following restarts are available: SKIP :R1 skip (SAVEINITMEM gtk-cells.mem) STOP :R2 stop loading file /home/lee/test/cells-gtk-2006-02-16/run-demo.lisp ABORT :R3 ABORT Break 1 [2]> Any ideas how I can get corefiles to automagically reinit ffi pointers? thanks in advance Lee ___________________________________________________________________ For super low premiums, click here http://www.webmail.co.za/dd.pwm http://www.webmail.co.za the South African FREE email service From asimon at math.bme.hu Tue May 30 13:27:13 2006 From: asimon at math.bme.hu (Andras Simon) Date: Tue, 30 May 2006 15:27:13 +0200 (CEST) Subject: [cells-gtk-devel] SBCL patches In-Reply-To: <85sln43k0u.fsf@tristan.br-automation.com> References: <85sln43k0u.fsf@tristan.br-automation.com> Message-ID: Hi Peter, Are you considering applying Marco's patches (http://common-lisp.net/pipermail/cells-gtk-devel/2006-May/000171.html)? I tested them (except for the one in gtk-ffi.lisp which wraps defpackage in an eval-when, because I think that the defpackage should go instead in a separate file), and they not only make SBCL, but also ACL 6.2 happy; and I see no regression in LWL either. (The context menu in the Menu tab still doesn't work in LWL, but it didn't before either.) Also, something like --- gtk-ffi/gtk-ffi.lisp 19 Feb 2006 20:17:41 -0000 1.19 +++ gtk-ffi/gtk-ffi.lisp 30 May 2006 13:13:43 -0000 @@ -133,12 +133,13 @@ #+win32 "libgtk-win32-2.0-0.dll" #+macosx "libgtk-win32-2.0-0.dylib") #+libcellsgtk - (cffi:load-foreign-library #+cffi-features:unix "libcellsgtk.so" + (cffi:load-foreign-library #+cffi-features:unix + (merge-pathnames "libcellsgtk.so" #.*compile-file-pathname*) #+win32 "libcellsgtk.dll" #+macosx "libcellsgtk.dylib"))) ) ; eval might be a good idea. Or is there a better way to ensuring that libcellsgtk.so is found? Andras From peter.denno at nist.gov Tue May 30 17:35:26 2006 From: peter.denno at nist.gov (Peter Denno) Date: Tue, 30 May 2006 13:35:26 -0400 Subject: [cells-gtk-devel] SBCL patches In-Reply-To: References: <85sln43k0u.fsf@tristan.br-automation.com> Message-ID: <200605301335.26883.peter.denno@nist.gov> Hi Andras, Yes, I'll add this to CVS (today, I hope) and perhaps create a new tarball. I overlooked the original message somehow. Thanks. On Tuesday 30 May 2006 09:27, Andras Simon wrote: > Hi Peter, > > Are you considering applying Marco's patches > (http://common-lisp.net/pipermail/cells-gtk-devel/2006-May/000171.html)? > I tested them (except for the one in gtk-ffi.lisp which wraps > defpackage in an eval-when, because I think that the defpackage should > go instead in a separate file), and they not only make SBCL, but also > ACL 6.2 happy; and I see no regression in LWL either. (The context > menu in the Menu tab still doesn't work in LWL, but it didn't before > either.) > > Also, something like > > --- gtk-ffi/gtk-ffi.lisp 19 Feb 2006 20:17:41 -0000 1.19 > +++ gtk-ffi/gtk-ffi.lisp 30 May 2006 13:13:43 -0000 > @@ -133,12 +133,13 @@ > #+win32 "libgtk-win32-2.0-0.dll" > #+macosx "libgtk-win32-2.0-0.dylib") > #+libcellsgtk > - (cffi:load-foreign-library #+cffi-features:unix "libcellsgtk.so" > + (cffi:load-foreign-library #+cffi-features:unix > + (merge-pathnames "libcellsgtk.so" > #.*compile-file-pathname*) #+win32 "libcellsgtk.dll" > #+macosx "libcellsgtk.dylib"))) > ) ; eval > > might be a good idea. Or is there a better way to ensuring that > libcellsgtk.so is found? > > Andras > _______________________________________________ > cells-gtk-devel site list > cells-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-gtk-devel -- - Best regards, Peter