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 #<simple-error @ #x2123e392>
+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")
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
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@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel
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. <g>
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
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.
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. <g> 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?! <sigh> 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
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?! <sigh> 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.
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?! <sigh> 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. <g> 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
Kenny Tilton writes:
This is the only feedback I have gotten. This is insufficient pestering. <g> 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 <g>
Thomas F. Burdick wrote:
Kenny Tilton writes:
This is the only feedback I have gotten. This is insufficient pestering. <g> 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 <g>
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
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).
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
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
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
-
James Bielman -
Kenny Tilton -
Peter Denno -
Thomas F. Burdick