From jamesjb at jamesjb.com Fri Apr 22 20:52:21 2005 From: jamesjb at jamesjb.com (James Bielman) Date: Fri, 22 Apr 2005 13:52:21 -0700 Subject: [cells-devel] New Cells User Feedback (includes patch!) Message-ID: Hi, Here's a patch containing the changes I made to get Cells to compile on a current OpenMCL (just Cells, none of the GUI stuff). Also, the files in the UTILS-KT defsystem had no dependencies, so I added :serial t to compile them in the order they appear. I added a paragraph to the documentation about calling CELL-RESET after errors occur and accessors just print ".". This drove me crazy for awhile---I was restarting my Lisp image once I got in this state because I couldn't figure out what to do! What about doing something like this in MD-SLOT-VALUE (untested, and assuming I haven't completely misunderstood what's going on): (defun md-slot-value (...) (tagbody retry (when *stop* (restart-case (error "Cells is stopped due to a prior error.") (continue () :report "Return a slot value of nil." (return-from md-slot-value nil)) (reset-cells () :report "Reset cells and retry getting the slot value." (cell-reset) (go retry)))) ; rest of MD-SLOT-VALUE here ...)) Also, let me second the need for an ASDF-INSTALL'able recent version of Cells without checking out all the GUI stuff---I couldn't get the version that's up there now to work. With respect to documentation, I was thinking of adding documentation strings for exported symbols as I learn what they do---watch this space for future patches! James Index: cells/doc/01-Cell-basics.lisp =================================================================== RCS file: /project/cells/cvsroot/cell-cultures/cells/doc/01-Cell-basics.lisp,v retrieving revision 1.1 diff -u -r1.1 01-Cell-basics.lisp --- cells/doc/01-Cell-basics.lisp 26 Jun 2004 18:38:38 -0000 1.1 +++ cells/doc/01-Cell-basics.lisp 22 Apr 2005 19:34:13 -0000 @@ -319,6 +319,10 @@ c-setting-debug > ruled distance in stone may not be setf'ed 0> error is # +when errors like this occur, cells may enter a "stopped" state, +in which propagation does not occur and accessing model slot values +will print ".". to restart cells use the CELL-RESET function. + ;----------------------------------------------------------- aside from c?, cv, and def-c-output, another thing you will see in cello code is how complex views are constructed using Index: utils-kt/defpackage.lisp =================================================================== RCS file: /project/cells/cvsroot/cell-cultures/utils-kt/defpackage.lisp,v retrieving revision 1.7 diff -u -r1.7 defpackage.lisp --- utils-kt/defpackage.lisp 17 Nov 2004 12:32:01 -0000 1.7 +++ utils-kt/defpackage.lisp 22 Apr 2005 19:34:14 -0000 @@ -25,7 +25,7 @@ (defpackage :utils-kt (:nicknames #:ukt) (:use #:common-lisp - #-(or cormanlisp cmu sbcl) #:clos + #-(or cormanlisp cmu sbcl mcl) #:clos #+sbcl #:sb-mop #+mcl #:ccl) (:export #:utils-kt-reset Index: utils-kt/detritus.lisp =================================================================== RCS file: /project/cells/cvsroot/cell-cultures/utils-kt/detritus.lisp,v retrieving revision 1.3 diff -u -r1.3 detritus.lisp --- utils-kt/detritus.lisp 17 Nov 2004 12:32:01 -0000 1.3 +++ utils-kt/detritus.lisp 22 Apr 2005 19:34:14 -0000 @@ -36,15 +36,11 @@ ;;;(defmethod class-slot-named (class slotname) ;;; (find slotname (class-slots class) :key #'slot-definition-name)) -#+mcl -(defun class-slots (c) - (nconc (copy-list (class-class-slots c)) - (copy-list (class-instance-slots c)))) - - #-(or lispworks mcl) (defun true (it) (declare (ignore it)) t) +#-(or lispworks mcl) (defun false (it) (declare (ignore it))) + (defun xor (c1 c2) (if c1 (not c2) c2)) Index: utils-kt/utils-kt.asd =================================================================== RCS file: /project/cells/cvsroot/cell-cultures/utils-kt/utils-kt.asd,v retrieving revision 1.2 diff -u -r1.2 utils-kt.asd --- utils-kt/utils-kt.asd 5 Dec 2004 04:51:02 -0000 1.2 +++ utils-kt/utils-kt.asd 22 Apr 2005 19:34:14 -0000 @@ -16,6 +16,7 @@ :licence "MIT Style" :description "Kenny's Utilities" :long-description "Low-level utilities used by all of Kenny's projects" + :serial t :components ((:file "defpackage") (:file "debug") (:file "detritus") From ktilton at nyc.rr.com Fri Apr 22 23:09:35 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 22 Apr 2005 19:09:35 -0400 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: References: Message-ID: <4269842F.9010304@nyc.rr.com> James, This is great feedback, and I agree with all of it. The only problem is that there is little active interest in Cells, other than my own use of it, so I am not worrying much these days about making the Cells project approachable to others. What I did with Cells-gtk was get a heavy user or two authorized as project admins so they could do things like fixing asdf-install. I suggest you poke around and see if you want to use Cells for anything, and if so we can sort out the mess in CVS. I want to look at moving Cello out of the Cells project and back to the Cello project on c-l.net, and get cells out from under cells-culture back to being a top-level module of the Cells project. Of course Cells-gtk would then have to be told the new home of Cells (and utils-kt and hello-c), so it could be a messy week. Which is why I will hold off until folks such as yourself pester me for, oh, two weeks straight. :) Thanks again for the input. kenny From peter.denno at nist.gov Sat Apr 23 00:33:49 2005 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 22 Apr 2005 20:33:49 -0400 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <4269842F.9010304@nyc.rr.com> References: <4269842F.9010304@nyc.rr.com> Message-ID: <200504222033.49709.peter.denno@nist.gov> On Friday 22 April 2005 19:09, Kenny Tilton wrote: > James, > > This is great feedback, and I agree with all of it. The only problem is > that there is little active interest in Cells, other than my own use of > it, so I am not worrying much these days about making the Cells project > approachable to others. > > What I did with Cells-gtk was get a heavy user or two authorized as > project admins so they could do things like fixing asdf-install. I'd be one of those. I'd be happy to apply this to cells-gtk. Is this what you were referring to when you were referring to the "gui stuff" ? I think I know the sort of problem you are trying to address here. You might not see this in the distribution for a few weeks. Some time in May I'm going to look into getting cells-gtk running on sbcl, among other things. > I suggest you poke around and see if you want to use Cells for anything, > and if so we can sort out the mess in CVS. I want to look at moving > Cello out of the Cells project and back to the Cello project on c-l.net, > and get cells out from under cells-culture back to being a top-level > module of the Cells project. > > Of course Cells-gtk would then have to be told the new home of Cells > (and utils-kt and hello-c), so it could be a messy week. We have a tarball distribution to weather messy weeks. > Which is why I > will hold off until folks such as yourself pester me for, oh, two weeks > straight. :) > > Thanks again for the input. > > kenny Hey kenny is this really you? It looks like the shift key is starting to work on your keyboard ;^) > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel -- - Best regards, Peter From ktilton at nyc.rr.com Sat Apr 23 03:03:55 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 22 Apr 2005 23:03:55 -0400 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <200504222033.49709.peter.denno@nist.gov> References: <4269842F.9010304@nyc.rr.com> <200504222033.49709.peter.denno@nist.gov> Message-ID: <4269BB1B.2050109@nyc.rr.com> Peter Denno wrote: >On Friday 22 April 2005 19:09, Kenny Tilton wrote: > > >>James, >> >>This is great feedback, and I agree with all of it. The only problem is >>that there is little active interest in Cells, other than my own use of >>it, so I am not worrying much these days about making the Cells project >>approachable to others. >> >>What I did with Cells-gtk was get a heavy user or two authorized as >>project admins so they could do things like fixing asdf-install. >> >> > >I'd be one of those. > >I'd be happy to apply this to cells-gtk. Is this what you were referring to >when you were referring to the "gui stuff" ? > I think James was talking about Cells (active directory) being buried under cell-cultures along with the Cello "gui stuff". > >I think I know the sort of problem you are trying to address here. > >You might not see this in the distribution for a few weeks. Some time in May >I'm going to look into getting cells-gtk running on sbcl, among other things. > > > >>I suggest you poke around and see if you want to use Cells for anything, >>and if so we can sort out the mess in CVS. I want to look at moving >>Cello out of the Cells project and back to the Cello project on c-l.net, >>and get cells out from under cells-culture back to being a top-level >>module of the Cells project. >> >>Of course Cells-gtk would then have to be told the new home of Cells >>(and utils-kt and hello-c), so it could be a messy week. >> >> > >We have a tarball distribution to weather messy weeks. > Don't encourage me. > > > >>Which is why I >>will hold off until folks such as yourself pester me for, oh, two weeks >>straight. :) >> >>Thanks again for the input. >> >>kenny >> >> > >Hey kenny is this really you? It looks like the shift key is starting to work >on your keyboard ;^) > moment of weakness. :) well, keep the pestering up (13 more days to go) and we can do something. Is hello-c (or whatever we want to call "UFFI extended to support callbacks into Lisp from C as well as CLisp") going to get enough attention to warrant its own c-l.net project? Should utils-kt quietly be redundantly added to Cells and hello-c? Or is it fine as a module under Cells? I doubt it is worth making into its own project, as at least one other did. etc etc. kt From peter.denno at nist.gov Sat Apr 23 20:38:32 2005 From: peter.denno at nist.gov (Peter Denno) Date: Sat, 23 Apr 2005 16:38:32 -0400 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <4269BB1B.2050109@nyc.rr.com> References: <200504222033.49709.peter.denno@nist.gov> <4269BB1B.2050109@nyc.rr.com> Message-ID: <200504231638.32981.peter.denno@nist.gov> On Friday 22 April 2005 23:03, Kenny Tilton wrote: > well, keep the pestering up (13 more days to go) and we can do something. > > Is hello-c (or whatever we want to call "UFFI extended to support > callbacks into Lisp from C as well as CLisp") Hello-c is fine with me. > going to get enough > attention to warrant its own c-l.net project? Got me. I haven't had time to think about it yet. Do you suppose there are other projects that would use it? > Should utils-kt quietly be redundantly added to Cells and hello-c? Or is > it fine as a module under Cells? I doubt it is worth making into its own > project, as at least one other did. Maybe added to cells makes most sense. I'm not too crazy of the idea of a separate module for utilities. We each have our own such collection and I'd like to add a few of mine wherever they are useful. In my thinking, a module ought to support a bounded, well-defined purpose -- either as a component of a system or as a set of operations on a single kind of object. Utilities aren't like that. -- - Best regards, Peter From ktilton at nyc.rr.com Sun Apr 24 01:08:23 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 23 Apr 2005 21:08:23 -0400 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <200504231638.32981.peter.denno@nist.gov> References: <200504222033.49709.peter.denno@nist.gov> <4269BB1B.2050109@nyc.rr.com> <200504231638.32981.peter.denno@nist.gov> Message-ID: <426AF187.8010901@nyc.rr.com> Peter Denno wrote: >On Friday 22 April 2005 23:03, Kenny Tilton wrote: > > >>well, keep the pestering up (13 more days to go) and we can do something. >> >>Is hello-c (or whatever we want to call "UFFI extended to support >>callbacks into Lisp from C as well as CLisp") >> >> > >Hello-c is fine with me. > > > >>going to get enough >>attention to warrant its own c-l.net project? >> >> > >Got me. I haven't had time to think about it yet. Do you suppose there are >other projects that would use it? > Well, we would soon have both Cello and Cells-Gtk reaching into Cells to get hello-c, but they also go after Cells, so that is not too silly. And it is hard to imagine anyone doing a project without using Cells. But... When kevin rosenberg encouraged me to take my uffi extensions to a new project, he mentioned that he himself thought it was time for a new uffi. CLisp now has a great FFI, but UFFI does not support CLisp. Callbacks into Lisp from C are now universal enough to meet KR's requirements for UFFI inclusion, but I do not see him going that way. Unless KR has a chnage of heart, Lisp needs a new semi-universal C FFI. > > > >>Should utils-kt quietly be redundantly added to Cells and hello-c? Or is >>it fine as a module under Cells? I doubt it is worth making into its own >>project, as at least one other did. >> >> > >Maybe added to cells makes most sense. I'm not too crazy of the idea of a >separate module for utilities. We each have our own such collection and I'd >like to add a few of mine wherever they are useful. > >In my thinking, a module ought to support a bounded, well-defined purpose -- >either as a component of a system or as a set of operations on a single kind >of object. Utilities aren't like that. > And the good news is that they do not undergo evolutionary development over time, so they can just be replicated into a serious module and forgotten. hmmmm. well, if we are going to upset the applecart we may as well do it all at once: cells out from under cell-cultures to be a toplevel module in the cells project (and eventually the only one). hello-c into its own c-l.net project (if c-l.net approves) utils-kt replicated redundantly into... uh-oh. who exports it?! OK, let's have cells export those functions. cello back over to the cello project cell-cultures sleeps with the fish all those in favor? opposed? kt -- Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From tfb at OCF.Berkeley.EDU Tue Apr 26 09:35:06 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 26 Apr 2005 02:35:06 -0700 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <426AF187.8010901@nyc.rr.com> References: <200504222033.49709.peter.denno@nist.gov> <4269BB1B.2050109@nyc.rr.com> <200504231638.32981.peter.denno@nist.gov> <426AF187.8010901@nyc.rr.com> Message-ID: <17006.2890.573897.719340@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > And the good news is that they do not undergo evolutionary development > over time, so they can just be replicated into a serious module and > forgotten. Well, yes. But if everything's already using Cells, it can't hurt to put it there. Unless you plan on releasing a major Cells-free package, in which case I guess it would want its own copy. > hmmmm. well, if we are going to upset the applecart we may as well do it > all at once: > > cells out from under cell-cultures to be a toplevel module in the cells > project (and eventually the only one). > hello-c into its own c-l.net project (if c-l.net approves) > utils-kt replicated redundantly into... uh-oh. who exports it?! > OK, let's have cells export those functions. > cello back over to the cello project > cell-cultures sleeps with the fish > > all those in favor? opposed? I'd like to see utils-kt go in a cells/utils-kt subdirectory, but keep its own package. That way there's only one point in cvs to keep up-to-date, and Cello and cells-gtk can use it, but Cells users don't have to. Weekend before last, I was going to put the new asdf-installable Cells release up on c-l.net, but I've managed to forget my gpg password, so I can't sign it. If it doesn't come to me over the next little while, I'll give up and make a new key. From ktilton at nyc.rr.com Tue Apr 26 14:01:42 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 26 Apr 2005 10:01:42 -0400 Subject: [cello-devel] Re: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <17006.2890.573897.719340@conquest.OCF.Berkeley.EDU> References: <200504222033.49709.peter.denno@nist.gov> <4269BB1B.2050109@nyc.rr.com> <200504231638.32981.peter.denno@nist.gov> <426AF187.8010901@nyc.rr.com> <17006.2890.573897.719340@conquest.OCF.Berkeley.EDU> Message-ID: <426E49C6.3080509@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > And the good news is that they do not undergo evolutionary development > > over time, so they can just be replicated into a serious module and > > forgotten. > >Well, yes. But if everything's already using Cells, it can't hurt to >put it there. Unless you plan on releasing a major Cells-free >package, in which case I guess it would want its own copy. > Yeah, I am thinking cl-opengl, cl-openal, cl-ftgl, cl-magick and cl-anythingelseiamforgetting are all worthy standalone projects. > > > hmmmm. well, if we are going to upset the applecart we may as well do it > > all at once: > > > > cells out from under cell-cultures to be a toplevel module in the cells > > project (and eventually the only one). > > hello-c into its own c-l.net project (if c-l.net approves) > > utils-kt replicated redundantly into... uh-oh. who exports it?! > > OK, let's have cells export those functions. > > cello back over to the cello project > > cell-cultures sleeps with the fish > > > > all those in favor? opposed? > >I'd like to see utils-kt go in a cells/utils-kt subdirectory, but keep >its own package. > Agreed. > That way there's only one point in cvs to keep >up-to-date, and Cello and cells-gtk can use it, but Cells users don't >have to. > >Weekend before last, I was going to put the new asdf-installable Cells >release up on c-l.net, but I've managed to forget my gpg password, so >I can't sign it. If it doesn't come to me over the next little while, >I'll give up and make a new key. > This is the only feedback I have gotten. This is insufficient pestering. The Open Source Fairy is dead. I am working now on my proprietary stuff and want to concentrate on it long enough to build that kind of momentum that has me waking up at 6am and stumbling to the keyboard to pick up where I left off. The next window of opportunity is on or about May 10th. Pester now or forever hold your peace. :) kenny -- Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From tfb at OCF.Berkeley.EDU Tue Apr 26 14:36:00 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 26 Apr 2005 07:36:00 -0700 Subject: [cello-devel] Re: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <426E49C6.3080509@nyc.rr.com> References: <200504222033.49709.peter.denno@nist.gov> <4269BB1B.2050109@nyc.rr.com> <200504231638.32981.peter.denno@nist.gov> <426AF187.8010901@nyc.rr.com> <17006.2890.573897.719340@conquest.OCF.Berkeley.EDU> <426E49C6.3080509@nyc.rr.com> Message-ID: <17006.20944.85678.193705@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > This is the only feedback I have gotten. This is insufficient pestering. > The Open Source Fairy is dead. I am working now on my proprietary > stuff and want to concentrate on it long enough to build that kind of > momentum that has me waking up at 6am and stumbling to the keyboard to > pick up where I left off. > > The next window of opportunity is on or about May 10th. Pester now or > forever hold your peace. > > :) Hmm, pestering is one thing, but how about threats? If the Open Source Fairy has passed on, I can reorganize cvs and release a new asdf-installable Cells, but I'd just orphan the other stuff in cell-cultures that I don't use From ktilton at nyc.rr.com Tue Apr 26 14:58:51 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 26 Apr 2005 10:58:51 -0400 Subject: [cello-devel] Re: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <17006.20944.85678.193705@conquest.OCF.Berkeley.EDU> References: <200504222033.49709.peter.denno@nist.gov> <4269BB1B.2050109@nyc.rr.com> <200504231638.32981.peter.denno@nist.gov> <426AF187.8010901@nyc.rr.com> <17006.2890.573897.719340@conquest.OCF.Berkeley.EDU> <426E49C6.3080509@nyc.rr.com> <17006.20944.85678.193705@conquest.OCF.Berkeley.EDU> Message-ID: <426E572B.4020704@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > This is the only feedback I have gotten. This is insufficient pestering. > > The Open Source Fairy is dead. I am working now on my proprietary > > stuff and want to concentrate on it long enough to build that kind of > > momentum that has me waking up at 6am and stumbling to the keyboard to > > pick up where I left off. > > > > The next window of opportunity is on or about May 10th. Pester now or > > forever hold your peace. > > > > :) > >Hmm, pestering is one thing, but how about threats? > Threats are good. > If the Open >Source Fairy has passed on, I can reorganize cvs and release a new >asdf-installable Cells, but I'd just orphan the other stuff in >cell-cultures that I don't use > OK, so: -- a utils-kt module (aka toplevel directory) gets created in the Cells project and populated with the stuff under cell-cultures -- the current Cells directory (module?) at the top level of the Cells project will be re-populated with the Cells directory under cell-cultures. cells.asd targets the new utils-kt module. -- all lists (cells, cello, cells-gtk) are notified that the cell-cultures subdirectories for utils-kt and cells are no longer maintained and will be deleted in a week Hmm. Perhaps while I am at it I should apply for projects for hello-c, cl-magick, cl-ftgl, cl-openal, and cl-opengl (if that is not already taken)? kt -- Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From tfb at OCF.Berkeley.EDU Tue Apr 26 15:19:13 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 26 Apr 2005 08:19:13 -0700 Subject: [cello-devel] Re: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <426E572B.4020704@nyc.rr.com> References: <200504222033.49709.peter.denno@nist.gov> <4269BB1B.2050109@nyc.rr.com> <200504231638.32981.peter.denno@nist.gov> <426AF187.8010901@nyc.rr.com> <17006.2890.573897.719340@conquest.OCF.Berkeley.EDU> <426E49C6.3080509@nyc.rr.com> <17006.20944.85678.193705@conquest.OCF.Berkeley.EDU> <426E572B.4020704@nyc.rr.com> Message-ID: <17006.23537.243251.653746@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > -- a utils-kt module (aka toplevel directory) gets created in the Cells > project and populated with the stuff under cell-cultures > > -- the current Cells directory (module?) at the top level of the > Cells project will be re-populated with the Cells directory > under cell-cultures. cells.asd targets the new utils-kt module. Do you want to release utils-kt as an asdf-installable package? If not, it'd be easeir (for me) if utils-kt were a subdirectory of cells. I can always solve this by adding more cheesy hacks on top of asdf though (like the lpr support). From tfb at OCF.Berkeley.EDU Wed Apr 27 11:40:28 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 27 Apr 2005 04:40:28 -0700 Subject: [cells-devel] Cells 2.0 release candidate Message-ID: <17007.31276.295374.747613@conquest.OCF.Berkeley.EDU> I've put a release candidate for Cells up here: http://www.ocf.berkeley.edu/~tfb/cells_2.0.tar.gz Before I put it up on c-l.net, change the Cliki link, and make noise about it, I'd appreciate it if other Cells users would confirm that it works for them. Particularly users of Cello and Cells-Gtk, which I don't use. The differences from what's in CVS are mostly organizational: I moved utils-kt into the cells directory, rearranged the locations of a couple files, and removed the unused profile code. I replaced defconstant-once (in utils-kt) with a better define-constant that DoesWIM, and I think what Kenny means, too, based on the evidence of his code. I also changed the one use of defconstant to use define-constant, and now everything builds cleanly again on SBCL. I think this should all be uncontroversial. If this works for everybody, I'll paste together a README file from the various candidates in cell-cultures, and release this weekend. Kenny: this tarball looks to me like a good way of organizing cells in CVS, so if you agree, you can just check this in to have a freed-from-cell-cultures cells. Otherwise, you can figure it out, this works for a release anyhow. From peter.denno at nist.gov Wed Apr 27 21:33:06 2005 From: peter.denno at nist.gov (Peter Denno) Date: Wed, 27 Apr 2005 17:33:06 -0400 Subject: [cells-devel] Cells 2.0 release candidate In-Reply-To: <17007.31276.295374.747613@conquest.OCF.Berkeley.EDU> References: <17007.31276.295374.747613@conquest.OCF.Berkeley.EDU> Message-ID: <200504271733.06914.peter.denno@nist.gov> On Wednesday 27 April 2005 07:40, Thomas F. Burdick wrote: > Before I put it up on c-l.net, change the Cliki link, and make noise > about it, I'd appreciate it if other Cells users would confirm that it > works for them. ?Particularly users of Cello and Cells-Gtk, which I > don't use. I'll try to give it a look WRT cells-gtk tomorrow. -- - Best regards, Peter From jamesjb at jamesjb.com Wed Apr 27 21:48:46 2005 From: jamesjb at jamesjb.com (James Bielman) Date: Wed, 27 Apr 2005 14:48:46 -0700 Subject: [cells-devel] Cells 2.0 release candidate In-Reply-To: <17007.31276.295374.747613@conquest.OCF.Berkeley.EDU> (Thomas F. Burdick's message of "Wed, 27 Apr 2005 04:40:28 -0700") References: <17007.31276.295374.747613@conquest.OCF.Berkeley.EDU> Message-ID: On 27 Apr 2005, Thomas F. Burdick wrote: > I've put a release candidate for Cells up here: > > http://www.ocf.berkeley.edu/~tfb/cells_2.0.tar.gz > > Before I put it up on c-l.net, change the Cliki link, and make noise > about it, I'd appreciate it if other Cells users would confirm that > it works for them. Particularly users of Cello and Cells-Gtk, which > I don't use. It needs some reader conditional fixes to build in OpenMCL---my patch from last week fixes these. James From jamesjb at jamesjb.com Wed Apr 27 22:05:30 2005 From: jamesjb at jamesjb.com (James Bielman) Date: Wed, 27 Apr 2005 15:05:30 -0700 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: <4269842F.9010304@nyc.rr.com> (Kenny Tilton's message of "Fri, 22 Apr 2005 19:09:35 -0400") References: <4269842F.9010304@nyc.rr.com> Message-ID: On 22 Apr 2005, Kenny Tilton wrote: > This is great feedback, and I agree with all of it. The only problem > is that there is little active interest in Cells, other than my own > use of it, so I am not worrying much these days about making the > Cells project approachable to others. Fair enough. > I suggest you poke around and see if you want to use Cells for > anything, and if so we can sort out the mess in CVS. Well, for kicks I wrote a little 6502 LAP-style macro assembler using Cells as my internal representation of instructions and labels, which worked out really well until I ran into a cycle I couldn't get around. Briefly, the problem is that defining a forward-referenced label may cause prior instructions to change size, which causes the label to be redefined at a new location, which causes prior instructions to be rewritten again to reflect the final label location. So, there is a cycle, but I have domain-specific knowledge (that an instruction can only change size once) that ensures the cycle will terminate. If I #-(and) out the cycle check in MD-SLOT-VALUE-ASSUME (I think), everything works okay, so I either need a way to refactor my model to eliminate the cycle or some way to tell Cells that a particular cycle is OK. Anyway, I'd never written an assembler before but I had a blast writing this---Cells is pretty cool. The code is up at: http://jamesjb.com/~jamesjb/darcs/cl-6502/ if anyone is interested. (Assembling examples/hello.l65 will error with a cycle unless you hack Cells to ignore cycles...) James From ktilton at nyc.rr.com Wed Apr 27 22:50:00 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 27 Apr 2005 18:50:00 -0400 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: References: <4269842F.9010304@nyc.rr.com> Message-ID: <42701718.3000405@nyc.rr.com> James Bielman wrote: >On 22 Apr 2005, Kenny Tilton wrote: > > > >>This is great feedback, and I agree with all of it. The only problem >>is that there is little active interest in Cells, other than my own >>use of it, so I am not worrying much these days about making the >>Cells project approachable to others. >> >> > >Fair enough. > > > >>I suggest you poke around and see if you want to use Cells for >>anything, and if so we can sort out the mess in CVS. >> >> > >Well, for kicks I wrote a little 6502 LAP-style macro assembler using >Cells as my internal representation of instructions and labels, which >worked out really well until I ran into a cycle I couldn't get around. > Fascinating. I happen to have done quite a bit of 6502 programming back in my Apple II days. I can't wait to look at your code and see how Cells was able to contribute to that. I will also stare at the cycle and think about how Cells could be enhanced to handle that gracefully, even if just by giving programmers an orderly way to apply domain knowledge. kt -- Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From tfb at OCF.Berkeley.EDU Thu Apr 28 07:58:37 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Thu, 28 Apr 2005 00:58:37 -0700 Subject: [cells-devel] Cells 2.0 release candidate In-Reply-To: References: <17007.31276.295374.747613@conquest.OCF.Berkeley.EDU> Message-ID: <17008.38829.714613.270769@conquest.OCF.Berkeley.EDU> James Bielman writes: > On 27 Apr 2005, Thomas F. Burdick wrote: > > > I've put a release candidate for Cells up here: > > > > http://www.ocf.berkeley.edu/~tfb/cells_2.0.tar.gz > > > > Before I put it up on c-l.net, change the Cliki link, and make noise > > about it, I'd appreciate it if other Cells users would confirm that > > it works for them. Particularly users of Cello and Cells-Gtk, which > > I don't use. > > It needs some reader conditional fixes to build in OpenMCL---my patch > from last week fixes these. Shame on me, I even have OpenMCL on my Mac (I just don't use it). I'll get those fixes from the mailing list and update the candidate tonight (German time). From ktilton at nyc.rr.com Fri Apr 29 02:26:46 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 28 Apr 2005 22:26:46 -0400 Subject: [cells-devel] RFE: Set My Cycles Free? In-Reply-To: References: <4269842F.9010304@nyc.rr.com> <42701718.3000405@nyc.rr.com> Message-ID: <42719B66.2020305@nyc.rr.com> James Bielman wrote: >On 27 Apr 2005, Kenny Tilton wrote: > > > >>Fascinating. I happen to have done quite a bit of 6502 programming >>back in my Apple II days. I can't wait to look at your code and see >>how Cells was able to contribute to that. I will also stare at the >>cycle and think about how Cells could be enhanced to handle that >>gracefully, even if just by giving programmers an orderly way to >>apply domain knowledge. >> >> > >Cool. I never really did much so I'm learning as I go. :) I put up a >more detailed description of what happens during an assembly and where >the cycle occurs at: > > http://www.jamesjb.com/assembler-cycle.txt > > Thanks for the detailed breakdown of the problem. You may have noticed that the system does allow a cell to be specified as "cyclic", but then the propagation simply halts if a cycle is detected. This to support cases like a scroll thumb, which both drives and is driven by the text currently displayed in a window. In that case, the cyclic propagation would be to set the cell to the value it already has, so it can simply be skipped. (I could let it continue and then propagation would stop anyway since the skipped set would result in no change, when propagation stops anyway, but I decided, hey, save a few CPU cycles. anyway...) Likewise, in your case the cycle is benign and terminates naturally. And as long as we are considering some way to let the programmer apply domain-specific knowledge.... What if we just eliminate entirely the cyclic thing and let programmers shoot themselves in the foot if they like? That is the Grand Lisp Philosophy, after all. Ironically, I might then consider treating the scroll case as /non/-cyclic. ie, It becomes a special declaration /not/ to cycle, saving a few CPU cycles. Hmmm, but now I am wondering about the CPU cost of cycle detection: (when (find c *causation*) (case (c-cyclicp c) (:run-on (trc "cyclicity running on" c)) ((t) (progn (trc "cyclicity handled gracefully" c) (c-pulse-update c :cyclicity-1) (return-from md-slot-value new-value))) (otherwise (c-break "(setf md-slot-value) setf looping ~a ~a" c *causation*)))) Omigod. What the hell is :run-on doing there? :) I am going to go try that now on your assembler code. Anyway, look at that "(find c *causation*)". That runs allllllllllll the time. The only benefit is automatically notifying the developer when they screw up. I could just toss the whole thing (even the cyclic attribute altogether, I think) or we could have a special such as *cell-trap-cyclic-bugs-please* and then try to figure out when something is cyclinc (not that easy, I believe Turing demonstrated). Of historical interest is that it occurred to me long ago that applications could simply work this way. I mean, it is how the world works. One cause leading to another. And it so happens that one consequence of Cells II is that this endless causal chain no longer means endless recursion, so the timing is good. Thoughts? kenny From ktilton at nyc.rr.com Fri Apr 29 02:56:31 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 28 Apr 2005 22:56:31 -0400 Subject: [cells-devel] RFE: Set My Cycles Free? In-Reply-To: <42719B66.2020305@nyc.rr.com> References: <4269842F.9010304@nyc.rr.com> <42701718.3000405@nyc.rr.com> <42719B66.2020305@nyc.rr.com> Message-ID: <4271A25F.6070900@nyc.rr.com> Kenny Tilton wrote: > Omigod. What the hell is :run-on doing there? :) I am going to go try > that now on your assembler code. Ah, sorry, that was in (setf md-slot-value), not md-slot-value-assume. I made this change: (defmodel label () ((name :initarg :name :reader name :documentation "Name of this label, a symbol.") (location :initform (c-input (:cyclicp :run-on) 0) ...etc... And modified md-slot-value-assume to know about :run-on, and the assembly ran to completion (correctly, I am assuming). I am assuming because I am not so interested in this fix so much as in the grander fix of simply not checking for cycles and letting programmers fend for themselves. btw. note that there would still be a different kind of cycle which would still be an error, one on the read side: if the rule for A eventually leads back to a read of A, that is a fatal error. kenny -- Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/ Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film "Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd From ktilton at nyc.rr.com Fri Apr 29 03:08:15 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 28 Apr 2005 23:08:15 -0400 Subject: [cells-devel] New Cells User Feedback (includes patch!) In-Reply-To: References: Message-ID: <4271A51F.9060005@nyc.rr.com> James Bielman wrote: >Hi, > >Here's a patch containing the changes I made to get Cells to compile >on a current OpenMCL (just Cells, none of the GUI stuff). Also, the >files in the UTILS-KT defsystem had no dependencies, so I added >:serial t to compile them in the order they appear. > >I added a paragraph to the documentation about calling CELL-RESET >after errors occur and accessors just print ".". This drove me crazy >for awhile---I was restarting my Lisp image once I got in this state >because I couldn't figure out what to do! > >What about doing something like this in MD-SLOT-VALUE (untested, and >assuming I haven't completely misunderstood what's going on): > >(defun md-slot-value (...) > (tagbody > retry > (when *stop* > (restart-case > (error "Cells is stopped due to a prior error.") > When I went to do something like that it came back to me in a flash: two different Lisp implementations killed me for hours until I figured out what was going on, in exactly the same way. It is OK to put up one backtrace, but the Lisp environments both then allow OS events through to my application windows, events such as "deactivate window". My application code then might fail again and put up another backtrace, and the only way out was to kill the Lisp environments. So once I see the *stop* sign, I literally try to do zero processing and simply return. Now the situation here is unusual because I do more GUI development than the average bear, so maybe something could be worked out. I could have a second special which tells the Cells engine that I have an application window up, and set that in some with-application-window macro right at my top-level testing function. then, if that flag is clear, I could have a patch such as yours to alert developers of the *stop* thing. Thoughts? kt