May 2005 - cells-devel - mailman3.common-lisp.net

[cells-devel] Release update
by Thomas F. Burdick 03 May '05

03 May '05

I'm pretty much just waiting on an answer from the OpenMCL developers telling me where we're supposed to be getting MOP functions from. For kicks, I checked Classic MCL this weekend, and it partially works. One of the unbound-cells tests failed, and I didn't feel very inspired to debug it. That does mean it got pretty far through the test suite, though. When I get the answer back from the OpenMCL developers, I'll update the candidate, and ask the couple of you who had problems with it to see if it works. Then, release :-) Here's the implementations I think Cells supports: Allegro, SBCL, LispWorks, CMUCL, OpenMCL. MCL was formerly supported and should not be very difficult to get working again. What about CLISP? Is it in the same category as MCL, or does anyone use it?

2 4

[cells-devel] Re: How cells wasted my time
by Kenny Tilton 02 May '05

02 May '05

What wasted your time was not asking on cells-devel when you had a problem. What wasted my time was taking the trouble to do open-source. Madhu wrote: >Helu, Heres some feedback on problems I encountered when learning to >use cells. > >Changing a defmodel form and evaluating it often caused the system to >stop functioning as expected. > >An example of a change is changing an :initform FORM slot to (c-in >FORM). > >An example of how the system stops functioning as expected is: rules >just dont fire. (echo output just does not happen). Accessors return >NIL instead of computed values > >lisp needs to be killed and restarted to recover. This is a >showstopper. Is there a quick way to reset the cells system and >recover? > (cell-reset) > >Another issue is after reading the doc my expectation was set at >identical behaviour from using SLOT-VALUE or an accessor. This does >not happen: For example calling the accessor produces `echo output' , >slot-value doesnt. > > slot-value is now a back door. ie, you are right, the doc is old, slot-value no longer triggers cell-ish behavior. You might do better with McCLIM. kt

1 0

[cells-devel] Re: Cells: Differences between Cells 2.0 release candidate and Cells in Cello ?
by Kenny Tilton 02 May '05

02 May '05

Frank GOENNINGER wrote: >Kenny, Thomas, > >hmm - I wonder if there are any differences between Cells versions - or >are these all the same versions? > I just checked on the Mac to confirm (it has been a while!) that we (Frank and I) were using Cells II on the Cello port to OS X. And on OS X we were just wrestling with differences between OSes and FreeGlut/MacGlut, not Cells. That said, I never finished merging the two code branches, so .... tell you what, I will do a diff and see what I can see, report back shortly.... OK, no difference. > >Thx for sorting this out. I am about to use Cells for a more advanced >system > Cool. Did you see my post a few days ago threatening to take out automatic detection of SETF cycles? These would arise normally in the classic Scoll Bar Scenario, where the cell for thumb position echos its output by SETFing the vertical offset of the text, the cell for which likewise SETFs the position of the thumb. I handled that with the "cyclicp" option, but a recent project (a 6502 assembler) required the cycling to run on a little to achieve a two-pass assemble, and in investigating i concluded, what the hell, programmers have created and fixed infinite loops for a while now and we are still here. Meanwhile, cycle detection was an ever-present drag on the system. Bad Kenny! I have disabled it in my Cells code and all seems well. Once Thomas's work is firmly in place I will CVS that down and hack out cycle detection unless someone yells. To explore your self, just locate all the *causation* references and disable the code in the two places where looping errors are thrown. I myself am firing up Cello while CliniSys works its way thru the Dilbert opus, so look for fresh paint over there as well. kt

1 0