cells-devel August 2009

cells-devel@common-lisp.net

3 participants
5 discussions

[cells-devel] A few patches for making cells (3.0 from cvs) run on debian unstable using sbcl.
by Peder Chr. Nørgaard 14 Dec '09

14 Dec '09

Hello cells-devel list. I am investigating cells and cells-gtk3 for a project that I am planning. For a starter, I needed to get the software running on my Debian unstable system. It needed a few patches that you may wish to take into your development. The version of cells that I use is taken with cvs -z3 -d :pserver:anonymous:anonymous@common-lisp.net:/project/cells/cvsroot co cells That is the most actual one, yes? Well, the sbcl on Debian unstable (1.0.18) does not have nor need the EXCL package. So it must be configured out: diff -u -r cells/defpackage.lisp cl/cells/defpackage.lisp --- cells/defpackage.lisp 2008-10-12 03:21:07.000000000 +0200 +++ MDM/cl/cells/defpackage.lisp 2008-11-28 20:08:38.000000000 +0100 @@ -23,7 +23,7 @@ (in-package :common-lisp-user) (defpackage :cells - (:use #:common-lisp #:excl #:utils-kt) + (:use #:common-lisp #-sbcl #:excl #:utils-kt) (:import-from ;; MOP #+allegro #:excl diff -u -r cells/utils-kt/defpackage.lisp cl/cells/utils-kt/defpackage.lisp --- cells/utils-kt/defpackage.lisp 2008-10-12 03:21:10.000000000 +0200 +++ MDM/cl/cells/utils-kt/defpackage.lisp 2008-11-28 20:04:08.000000000 +0100 @@ -35,7 +35,8 @@ (defpackage :utils-kt (:nicknames #:ukt) - (:use #:common-lisp #:excl + (:use #:common-lisp + #-sbcl #:excl #+(or allegro lispworks clisp) #:clos #+cmu #:mop #+sbcl #:sb-mop The sbcl does not have the MOP package - it is called SB-MOP. Much of the code knows that already, but I had to patch one file: diff -u -r cells/utils-kt/detritus.lisp cl/cells/utils-kt/detritus.lisp --- cells/utils-kt/detritus.lisp 2008-10-12 03:21:10.000000000 +0200 +++ MDM/cl/cells/utils-kt/detritus.lisp 2008-11-28 20:07:57.000000000 +0100 @@ -33,7 +33,7 @@ (let ((cc (find-class c))) (when cc (finalize-inheritance cc)) - (mop::class-prototype cc))) + (#+sbcl sb-mop:class-prototype #-sbcl mop::class-prototype cc))) (defun brk (&rest args) After that, I tried to run the test suite. Worked fine, except that it is a little bit too Window'ish. I did this: diff -u -r cells/cells-test/test.lisp cl/cells/cells-test/test.lisp --- cells/cells-test/test.lisp 2008-10-12 03:21:09.000000000 +0200 +++ MDM/cl/cells/cells-test/test.lisp 2008-12-01 22:25:26.000000000 +0100 @@ -69,7 +69,7 @@ (defun test-cells () - (dribble "c:/0algebra/cells-test.txt") + (dribble "/tmp/cells-test.txt") (progn ;prof:with-profiling (:type :time) (time (progn but that is not what you want to go in the main sources. Maybe something based on the features - (dribble #+unix "/tmp/cells-test.txt" #-unix "c:/0algebra/cells-test.txt") - or perhaps just a file name parameter to TEST-CELLS with the above as the default value? Hope this is of a little help to you. I am sure to come back for assistance for my project later. best regards -- Peder Chr. Nørgaard e-mail: pcn(a)pogt.dk Gefionsvej 19 DK-8230 Åbyhøj tel: +45 87 44 11 99 Denmark mob: +45 30 91 84 31

6 5

Re: [cells-devel] bug in celtk
by Andy Chambers 15 Aug '09

15 Aug '09

On Fri, Aug 14, 2009 at 5:21 PM, Frank Goenninger - Consequor Consulting AG<frank.goenninger(a)consequor.de> wrote: > Am 14.08.2009 um 17:56 schrieb Andy Chambers: > >> OK Thanks for checking that out Frank. I must have something else >> wrong over here. I think the problem was actually with my Lisp. I changed the test to have the button click reflected in the gui and it happened immediately. My new theory is that because I'm using a single threaded lisp, it doesn't get round to executing the print statement until the next set of events are being processed. If I just just setf the new value into a cell, it all seems to work as expected. -- Andy

1 0

[cells-devel] bug in celtk
by Andy Chambers 14 Aug '09

14 Aug '09

Hey All, There seems to be a strange bug in celtk. I'm looking into it but wondered if any of you guys had any clues. Celtk seems to be delaying the evaluation of an "on-command" procedure until the next "on-command" event is generated. You can see this in the example ltktest-ci. If you start that, and click the "Hallo" button, then the "Wald" button, then the "Hallo" button, you'll see what I'm talking about. I've made a few changes to my local copy so it might just be me but it would be interesting to find out if anyone else can confirm this behaviour. Cheers, Andy

3 5

Re: [cells-devel] bug in celtk
by Andy Chambers 14 Aug '09

14 Aug '09

On Fri, Aug 14, 2009 at 4:20 PM, Kenneth Tilton<kentilton(a)gmail.com> wrote: > That would just leave the problem extant, by finding some other way to > dispatch commands. I may DL and try myself later. Did you grab from CVS > recently? Or, better: zip up your copy and send me that so we are looking at > the same code for sure. Yeah but I think that may be the cause of the problem. Consider this bit from the Tcl docs > Tcl_CreateCommand defines a new command in interp and associates it with procedure proc such that whenever cmdName is invoked as a Tcl command __(via a call to Tcl_Eval)__ the Tcl interpreter will call proc to process the command. vs > Tcl_CreateObjCommand defines a new command in interp and associates it with procedure proc such that whenever name is invoked as a Tcl command (e.g., via a call to Tcl_EvalObjEx) the Tcl interpreter will call proc to process the command. How is Tcl going to know to invoke do-on-command using Tcl_Eval rather than Tcl_EvalObjEx? You can grab a zip of my current working directory at the link below. http://github.com/cddr/celtk/zipball/master Cheers, Andy

1 0

Re: [cells-devel] bug in celtk
by Andy Chambers 14 Aug '09

14 Aug '09

On Fri, Aug 14, 2009 at 3:54 PM, Kenneth Tilton<kentilton(a)gmail.com> wrote: > If you now click some place at random do you see "hitting button C"? You > might have to create a checkbox or something else that is enabled and > handles mouse events. No but it does eventually catch up when you close the app down. I added a tcl trace to the "do-on-command" procedure and tcl does indeed seem to be calling that procedure at the correct time. I have a theory that altering defcommand to make it use a command created by TclCreateObjCommand (as opposed to TclCreateCommand) might make it work. I'll send a patch if it does. Cheers, Andy -- ---- Andy Chambers Formedix Ltd

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel August 2009