From tfb at OCF.Berkeley.EDU Mon May 2 12:28:23 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 2 May 2005 05:28:23 -0700 Subject: [cells-devel] Release update Message-ID: <17014.7399.871754.518133@conquest.OCF.Berkeley.EDU> 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? From ktilton at nyc.rr.com Mon May 2 12:46:25 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 02 May 2005 08:46:25 -0400 Subject: [cells-devel] Release update In-Reply-To: <17014.7399.871754.518133@conquest.OCF.Berkeley.EDU> References: <17014.7399.871754.518133@conquest.OCF.Berkeley.EDU> Message-ID: <42762121.2040303@nyc.rr.com> Thomas F. Burdick wrote: >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. > My bad. I hate testing. I did not even run the tests under AllegroCL. I just fired up Cello and The Fabulous Spinning Shape Demo. To be honest, I would not be surprised if some tests need revision. And if I go ahead and remove autodetection of cycles, this will break any test designed to confirm that cycles are autodetected -- just do not remember if I have one. > 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? > Cells has always been tested under CLisp, and Cells-Gtk Classic was developed on CLisp. It should work there as well, if anyone cares to test. CLisp now has better (great, they say) MOP support, so things should only be getting easier. One issue with CLisp was some crazy defstruct/include/conc-name behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the Cell defstructs have different conc-names. btw, Cells has been observed running satisfactorily on CormanCL. kt From ktilton at nyc.rr.com Mon May 2 13:01:29 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 02 May 2005 09:01:29 -0400 Subject: [cells-devel] Re: Cells: Differences between Cells 2.0 release candidate and Cells in Cello ? In-Reply-To: <1115035692.24257.3.camel@stargate.de.goenninger.net> References: <1115035692.24257.3.camel@stargate.de.goenninger.net> Message-ID: <427624A9.9070108@nyc.rr.com> 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 From ktilton at nyc.rr.com Mon May 2 13:05:56 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 02 May 2005 09:05:56 -0400 Subject: [cells-devel] Re: How cells wasted my time In-Reply-To: <20050502074730.10726.qmail@robolove.meer.net> References: <20050502074730.10726.qmail@robolove.meer.net> Message-ID: <427625B4.5070400@nyc.rr.com> 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 From tfb at OCF.Berkeley.EDU Mon May 2 14:49:07 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 2 May 2005 07:49:07 -0700 Subject: [cells-devel] Release update In-Reply-To: <42762121.2040303@nyc.rr.com> References: <17014.7399.871754.518133@conquest.OCF.Berkeley.EDU> <42762121.2040303@nyc.rr.com> Message-ID: <17014.15843.332257.751159@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > > Thomas F. Burdick wrote: > > >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. > > My bad. I hate testing. I did not even run the tests under AllegroCL. I > just fired up Cello and The Fabulous Spinning Shape Demo. To be honest, > I would not be surprised if some tests need revision. And if I go ahead > and remove autodetection of cycles, this will break any test designed to > confirm that cycles are autodetected -- just do not remember if I have one. Actually, I think it means that there is something broken on MCL, because the tests run to completion on SBCL. > Cells has always been tested under CLisp, and Cells-Gtk Classic was > developed on CLisp. It should work there as well, if anyone cares to > test. CLisp now has better (great, they say) MOP support, so things > should only be getting easier. Oh yeah. So the list is: Allegro, SBCL, LispWorks, CMUCL, CLISP, OpenMCL. Probably works: Corman Partially works: MCL > One issue with CLisp was some crazy defstruct/include/conc-name > behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the > Cell defstructs have different conc-names. I had wondered about that. It did make the SBCL port more "exciting" because there were a couple cases of using a subclass' accessor on a parent class, which SBCL is picky about. I had meant to malign the conc-name decision, but I guess I forgot :-) From ktilton at nyc.rr.com Mon May 2 16:47:34 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 02 May 2005 12:47:34 -0400 Subject: [cells-devel] Release update In-Reply-To: <17014.15843.332257.751159@conquest.OCF.Berkeley.EDU> References: <17014.7399.871754.518133@conquest.OCF.Berkeley.EDU> <42762121.2040303@nyc.rr.com> <17014.15843.332257.751159@conquest.OCF.Berkeley.EDU> Message-ID: <427659A6.4000304@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > One issue with CLisp was some crazy defstruct/include/conc-name > > behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the > > Cell defstructs have different conc-names. > >I had wondered about that. It did make the SBCL port more "exciting" >because there were a couple cases of using a subclass' accessor on a >parent class, which SBCL is picky about. > Hmm. I seem to recall this. You could have gone (and can go) ahead and fix any of those. Good for SBCL! > I had meant to malign the >conc-name decision, but I guess I forgot :-) > > When I saw you cross swords with Sam or Bruno on c.l.l. over gratuitous differences i thought this issue might be part of it. One of them actually responded to me on this issue and heartily defended their approach. Oh, well. Glad to see their other progress on MOP and FFI. I wonder if they still mess up this concname thing. 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 May 3 08:34:00 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 3 May 2005 01:34:00 -0700 Subject: [cells-devel] Release update In-Reply-To: <427659A6.4000304@nyc.rr.com> References: <17014.7399.871754.518133@conquest.OCF.Berkeley.EDU> <42762121.2040303@nyc.rr.com> <17014.15843.332257.751159@conquest.OCF.Berkeley.EDU> <427659A6.4000304@nyc.rr.com> Message-ID: <17015.14200.388994.893262@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > > Thomas F. Burdick wrote: > > >Kenny Tilton writes: > > > One issue with CLisp was some crazy defstruct/include/conc-name > > > behavior. Gratuitous noncompliance crap. Hsssss! :) That is why all the > > > Cell defstructs have different conc-names. > > > >I had wondered about that. It did make the SBCL port more "exciting" > >because there were a couple cases of using a subclass' accessor on a > >parent class, which SBCL is picky about. > > Hmm. I seem to recall this. You could have gone (and can go) ahead and > fix any of those. Good for SBCL! Oh, I certainly fixed them -- if I hadn't, Cells would not be running on SBCL, and the software I delivered for my final two contracts as a consultant wouldn't run. > > I had meant to malign the > >conc-name decision, but I guess I forgot :-) > > When I saw you cross swords with Sam or Bruno on c.l.l. over gratuitous > differences i thought this issue might be part of it. One of them > actually responded to me on this issue and heartily defended their > approach. Oh, well. Glad to see their other progress on MOP and FFI. I > wonder if they still mess up this concname thing. Heh, I meant I had intended to malign your non-idiomatic use of conc-names in Cells, not realizing that it was to support CLISP. That's definately on the list of gratuitous incompatabilities I hate in CLISP -- I'm definately interested in seeing how much of this gets fixed. They seem to have grown an interest in being able to bootstrap SBCL, so that should help push them in a compliant direction. From tfb at OCF.Berkeley.EDU Tue May 3 11:41:07 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 3 May 2005 04:41:07 -0700 Subject: [cells-devel] Cells 2.0pre2 Message-ID: <17015.25427.11456.975131@conquest.OCF.Berkeley.EDU> A new candidate: http://www.ocf.berkeley.edu/~tfb/cells_2.0pre2.tar.gz This works for me in SBCL, LispWorks, CLISP, and and older OpenMCL. James, could you check this on your OpenMCL? The only notable failure is CMUCL: it looks like Cells can trigger a bug in CMUCL's constructor optimizations. I'll try to file a bug before they release 19b, but for now it looks like CMUCL is in the partially supported category. If there are no objections, I'll put this up on c-l.net tomorrow, and announce in whatever fora strike my fancy. I've appended the README file below: ***** About Cells ***** (Installation instructions follow) Cells is a mature, stable extension to CLOS that allows you to create classes, the instances of which have slots whose values are determined by a formula. Think of the slots as cells in a spreadsheet (get it?), and you've got the right idea. You can use any arbitrary Common Lisp expression to specify the value of a cell. The Cells system takes care of tracking dependencies among cells, and propagating values. It is distributed under an MIT-style license. Documentation is unfortunately quite lacking; the cells-devel list is still your best source of information. Some documentation can be found in the doc/ directory of the distribution. See the website at http://www.common-lisp.net/project/cells/ for more info. Cells is written in almost-portable ANSI Common Lisp. It makes very light use of the introspective portions of the MOP, and contains a few workarounds for shortcomings in common implementations. It contains gratuitous use of silly reader conditionals (eg, #-chya, #-not, etc), so users wishing to push things like :TEST and :NOT on *FEATURES*, and users of the New Implementation of Lisp (NIL) should beware. If the last sentance didn't mean anything to you, you can ignore it. Cells is known to currently work on the following Lisp implementations: * Allegro * SBCL * CLISP * LispWorks * OpenMCL Partially supported are: * CMUCL * Corman Lisp * MCL One of the Cells tests fails with CMUCL. This appears to be caused by a bug in its CLOS implementation, but has not been investigated in great depth. Cells is belived to work with Corman CL, but has not been recently tested. In the past, MCL was supported, but a it does not currently pass the test suite. Ressurecting full support for any of these implementations should be easy. Porting Cells to an unsupported but ANSI-conforming Lisp implementation should be trivial: mostly a matter of determining the package where the MOP lives. In reality, however, you might have to find workarounds for bugs in ANSI compliance. ***** Installation ***** [ Cells follows the usual convention for asdf and asdf-installable packages. If you know what that means, that's all you need to know. ] Installation is trivial for asdf-install users: (asdf-install:install :cells) Users without asdf-install will need to download the distribution from common-lisp.net. If your implementation does not come with ASDF, please complain to the implementor, then load the asdf.lisp file included in the Cells distribution. Unpack the distribution where you will. Unix users: If you do not already have an asdf central registry, create a directory calld asdf-registry under your home directory and push this onto asdf:*central-registry*. Create symlinks there to the cells.asd and cells-test.asd files in the distribution. Alternately, follow the instructions for Windows users. Windows and Classic Mac users: Push the directory where you unpacked the Cells distribution onto asdf:*central-registry*. You can now load Cells in the usual manner for asdf. SLIME: ,load-system cells SBCL: (require :cells) Other systems: (asdf:oos 'asdf:load-op :cells) You may wish to run the test suite. To do so, use asdf to load the :cells-test system. From jamesjb at jamesjb.com Tue May 3 18:56:45 2005 From: jamesjb at jamesjb.com (James Bielman) Date: Tue, 03 May 2005 11:56:45 -0700 Subject: [cells-devel] Re: Cells 2.0pre2 In-Reply-To: <17015.25427.11456.975131@conquest.OCF.Berkeley.EDU> (Thomas F. Burdick's message of "Tue, 3 May 2005 04:41:07 -0700") References: <17015.25427.11456.975131@conquest.OCF.Berkeley.EDU> Message-ID: On 3 May 2005, Thomas F. Burdick wrote: > This works for me in SBCL, LispWorks, CLISP, and and older OpenMCL. > James, could you check this on your OpenMCL? Yep, this works just fine in OpenMCL 0.14.3! About the CLOS package confusion in OpenMCL, the conditional logic in defpackage was backwards---in my patch I added OpenMCL to the list of implementations that /don't/ have a CLOS package: (:use #:common-lisp - #-(or cormanlisp cmu sbcl) #:clos + #-(or cormanlisp cmu sbcl mcl) #:clos Thanks! James From tfb at OCF.Berkeley.EDU Tue May 3 19:17:28 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 3 May 2005 12:17:28 -0700 Subject: [cells-devel] Re: Cells 2.0pre2 In-Reply-To: References: <17015.25427.11456.975131@conquest.OCF.Berkeley.EDU> Message-ID: <17015.52808.263150.168103@conquest.OCF.Berkeley.EDU> James Bielman writes: > On 3 May 2005, Thomas F. Burdick wrote: > > > This works for me in SBCL, LispWorks, CLISP, and and older OpenMCL. > > James, could you check this on your OpenMCL? > > Yep, this works just fine in OpenMCL 0.14.3! Great! I'm releasing it before I change my mind and track down the CMUCL problem. > About the CLOS package confusion in OpenMCL, the conditional logic in > defpackage was backwards---in my patch I added OpenMCL to the list of > implementations that /don't/ have a CLOS package: > > (:use #:common-lisp > - #-(or cormanlisp cmu sbcl) #:clos > + #-(or cormanlisp cmu sbcl mcl) #:clos D'oh. Oh well, the net effect was good -- we get symbols from the right place now, and that gross reader conditional is now positive. From ktilton at nyc.rr.com Thu May 5 13:07:22 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 05 May 2005 09:07:22 -0400 Subject: [cells-devel] [Fwd: Re: Cells 2.0 released] Message-ID: <427A1A8A.6090002@nyc.rr.com> -------- Original Message -------- Subject: Re: Cells 2.0 released Date: 04 May 2005 13:21:49 -0700 From: Fred Gilham Newsgroups: comp.lang.lisp References: > Partial support exists for CMUCL, Corman Lisp, and MCL. The docs say that one of the tests fails with CMU Lisp. However, I don't see any sign of that when I run with a recent snapshot (March 2005). What does this failure look like? I ran the same process in sbcl as common lisp, then compared the output. That is, I ran (asdf:oos 'asdf:load-op :cells-test) in both. Then I compared the outputs. Except for formatting and a few other minor issues, they were the same. Does this imply that CMUCL is runing cells 2.0 correctly? -- Fred Gilham gilham at csl.sri.com Comprehensive Computer Language Preference Survey Do you like Lisp? (Check one) [ ] Yes [ ] Sure [ ] You bet [ ] Yep [ ] Da -- 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 May 5 15:17:16 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: 05 May 2005 08:17:16 -0700 Subject: [cells-devel] Re: Cells 2.0 released In-Reply-To: Fred Gilham's message of "04 May 2005 13:21:49 -0700" References: Message-ID: The following message is a courtesy copy of an article that has been posted to comp.lang.lisp as well. Fred Gilham writes: > > Partial support exists for CMUCL, Corman Lisp, and MCL. > > The docs say that one of the tests fails with CMU Lisp. However, I > don't see any sign of that when I run with a recent snapshot (March > 2005). What does this failure look like? > > I ran the same process in sbcl as common lisp, then compared the > output. That is, I ran (asdf:oos 'asdf:load-op :cells-test) in both. > Then I compared the outputs. Except for formatting and a few other > minor issues, they were the same. > > Does this imply that CMUCL is runing cells 2.0 correctly? That's good to hear, that does imply it's working correctly. One of the tests tickles what appears to be a bug in Gerd's constructor optimizations, at least in 19a. Unfortunately that means there won't be a supported release of CMUCL until 19b, but I'll change the docs to indicate that recent snapshots are fully supported. That also saves me the pain of installing the most recent snapshot, and trying to come up with a reasonably concise test case to report the bug :-) From fph at clouddancer.com Fri May 6 05:53:11 2005 From: fph at clouddancer.com (GP lisper) Date: Thu, 5 May 2005 22:53:11 -0700 (PDT) Subject: [cells-devel] Re: Dow-Cells In-Reply-To: <427B00FF.1070501@nyc.rr.com> (message from Kenny Tilton on Fri, 06 May 2005 01:30:39 -0400) References: <20050506004824.114832CD9B@phoenix.clouddancer.com> <427B00FF.1070501@nyc.rr.com> Message-ID: <20050506055311.0361A2CD9B@phoenix.clouddancer.com> Date: Fri, 06 May 2005 01:30:39 -0400 From: Kenny Tilton >(defmodel ticker (model) > ((ticker-sym :cell nil :initarg :ticker-sym :reader ticker-sym) > > ;; not a cell because I forgot that issues can change their ticker symbols <--Kenny > ;; Not during a trading day. Because of 23.75 hour trading days, symbol changes > ;; only occur on Friday afternoons. The index basket setup on Sunday is valid > ;; thru the week. So should it be a cell then? > Your call. Simple issue: will a stock change symbol during the run of the application? No. Especially no in this tutorial code. If I understand correctly, then there is no need to make this a cell. Ron From ktilton at nyc.rr.com Fri May 6 05:30:39 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 06 May 2005 01:30:39 -0400 Subject: [cells-devel] Re: Dow-Cells In-Reply-To: <20050506004824.114832CD9B@phoenix.clouddancer.com> References: <20050506004824.114832CD9B@phoenix.clouddancer.com> Message-ID: <427B00FF.1070501@nyc.rr.com> GP lisper wrote: >I've been scratching my head and discovering how little I know about >this lisp OO stuff. Got some books coming on interlibrary loan, but >on-the-job training has worked in the past. > >But I do know what idea I had in mind when I started this email >exchange. So I would like to establish some common terminology, which >makes it easier for me to read the code. > ok, will adjust to your terms. >------------------------------------------------------------------ > >Comments on your old code: > >... >(defmodel ticker (model) > ((ticker-sym :cell nil :initarg :ticker-sym :reader ticker-sym) > > ;; not a cell because I forgot that issues can change their ticker symbols <--Kenny > ;; Not during a trading day. Because of 23.75 hour trading days, symbol changes > ;; only occur on Friday afternoons. The index basket setup on Sunday is valid > ;; thru the week. So should it be a cell then? > Your call. Simple issue: will a stock change symbol during the run of the application? I would add, "and will anyone care?". but assuming the thing is displayed, yeah, the text widget displaying the symbol will care. ie, some list will know only that it is displaying the stock object (or ticker object as you have now defined), the object being a Lisp instance with a slot which is the symbol. The list contents will not change, just the symbol associated with the listed ticker. So nothing tells the text label displaying the symbol to change, unless it is a cell and we can arrange for dataflow (aka "hey! you need to change the string in this text label and redraw it!". > > (trades :reader trades > :initform (c? (bwhen (xtrade (car (trades .parent))) > (if (eql (ticker-sym self) (trade-ticker-sym xtrade)) > (cons xtrade .cache) > .cache)))) > ;; the above could be done more efficiently, albeit less declaratively, by <--Kenny > ;; making this an input cell (c-in nil) and having an output method on the > ;; trades cell of the exchange push a new trade onto the trades cell of the > ;; matching issue > ;; > ;; speed counts, there is (or will be) a LOT going on... > Yep, but my didactic instincts tell me to defer performance tweaks until you grok basic Cells. > >... > >; (defstruct trade ticker tickmin last) kennys previous > >;; a trade never changes (well, we'll see) so for now it can just be a struct >;; changes are unimportant, the moving herd has stampeeded on > agreed. almost every time I am convinced something can be just a struct it ends up needing to be a DEFMODEL. But the change is trivial, so where I think I see a defstruct I use one. > >------------------------------------------------------------------ > >I'm catching on a bit to this idea of spreading the code out amongst >objects and methods, accessors and readers(? whatever stuffs values >in). I smell wood burning! > You are almost ready to leave the temple, grasshopper. Cells are all about a declarative model which nicely chops up huge wodges of code into so many declarative cell rules. As I say in some of my doc, this is exactly what happens in spreadsheet programming: an emergent, complex financial model out of so many simple, discrete rules. Cells draw a developer into a natural, easy decomposition of complex state interactions into a declarative model of more or less simple rules. The only hard part is accepting that this is indeed possible. Surely this declarative thing must break down at some point. Nope. Back in the day someone proved that any GOTO program could be automatically be rewritten as a structured, GOTO-free program. I think we go thru the same epiphany when coming up to speed on Cells. After I first developed them, I certainly expected them to break down and not handle some requirement for many months. Only after throwing a variety of challenges at Cells did I conclude that there must be something deeply sensible about the critters. 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 fph at clouddancer.com Fri May 6 06:22:42 2005 From: fph at clouddancer.com (GP lisper) Date: Thu, 5 May 2005 23:22:42 -0700 (PDT) Subject: [cells-devel] Cells testing...maybe Message-ID: <20050506062242.6D4EE2CD9B@phoenix.clouddancer.com> I'm trying to learn Cells by poking at the examples to see if I can predict the result. I'm using the April 05 snapshot of CMUCL with Ray's patches to Require for ASDF. Cells-test passes without any obvious glaring errors, but most of it is greek to me. In boiler-example.lisp, I can run (boiler-1) without a problem. I was trying to understand what cv-assert did, so I added a line to induce an error: (defmodel boiler1 () ((id :cell nil :initarg :id :accessor id :initform (random 1000000)) (status :initarg :status :accessor status :initform nil) ;; vanilla cell (temp :initarg :temp :accessor temp :initform nil) (vent :initarg :vent :accessor vent :initform nil) )) (defun boiler-1 () ;; resets debugging/testing specials (cell-reset) (let ((b (make-instance 'boiler1 :status (c? (if (< (temp self) 100) :on :off)) :temp (c-in 20) :vent (c? (ecase (^status) ;; expands to (status self) and also makes coding synapses convenient (:on :open) (:off :closed)))))) (cv-assert (eql 10 (temp b))) ; ADDED TO TRIGGER the Hyperspecs "correctable error" (cv-assert (eql 20 (temp b))) (cv-assert (eql :on (status b))) (cv-assert (eql :open (vent b))) (setf (temp b) 100) ;; triggers the recalculation of status and then of vent (cv-assert (eql 100 (temp b))) (cv-assert (eql :off (status b))) (cv-assert (eql :closed (vent b))) )) It was my reading of the Hyperspec's entry for assert, which lives inside cv-assert that I would get a correctable error and be able to alter the 10 to 20, and have the test pass. But I get: CELLS> (boiler-1) Error in function LISP::ASSERT-ERROR: (EQL 10 (TEMP B)) ...failed [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Retry assertion. 1: [ABORT ] Return to Top-Level. Debug (type H for help) (LISP::ASSERT-ERROR (EQL 10 (TEMP B)) NIL "~&~a~&...failed" (EQL 10 (TEMP B))) Source: ; File: target:code/macros.lisp (RESTART-CASE (ERROR COND) (CONTINUE () :REPORT (LAMBDA # #) NIL)) 0] H The prompt is right square brackets, the number indicating how many recursive command loops you are in. Debug commands do not affect * and friends, but evaluation in the debug loop do affect these variables. Any command may be uniquely abbreviated. Getting in and out of DEBUG: Q throws to top level. GO calls CONTINUE which tries to proceed with the restart 'continue. RESTART invokes restart numbered as shown (prompt if not given). ERROR prints the error condition and restart cases. FLUSH toggles *flush-debug-errors*, which is initially t. The name of any restart, or its number, is a valid command, and is the same as using RESTART to invoke that restart. Changing frames: U up frame D down frame T top frame B bottom frame [RETURN FOR MORE, Q TO QUIT HELP TEXT]: q 0] GO Error in function LISP::ASSERT-ERROR: (EQL 10 (TEMP B)) ...failed [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Retry assertion. 1: [ABORT ] Return to Top-Level. Debug (type H for help) (LISP::ASSERT-ERROR (EQL 10 (TEMP B)) NIL "~&~a~&...failed" (EQL 10 (TEMP B))) Source: (RESTART-CASE (ERROR COND) (CONTINUE () :REPORT (LAMBDA # #) NIL)) 0] ------------------------------------------------------------------ So, do I have the right idea that a user opportunity to correct an error exists? Might this be related to a CMUCL bug afterall? Is the example boiler-1 too simple to support this testing? TIA Ron From rpgoldman at real-time.com Fri May 6 17:38:47 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 6 May 2005 12:38:47 -0500 Subject: [cells-devel] cells-gtk status Message-ID: <17019.43943.917207.729648@gargle.gargle.HOWL> Would it be possible for someone on the list to clue us in on the status of Cells-gtk now that there is a new version of Cells? A while ago there was a lot of email traffic that seemed to be concerned with this issue, but as a newcomer, I really didn't follow it. It SEEMED like there was some version skew, but I didn't understand. Thanks, R From ktilton at nyc.rr.com Fri May 6 18:05:06 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 06 May 2005 14:05:06 -0400 Subject: [cells-devel] cells-gtk status In-Reply-To: <17019.43943.917207.729648@gargle.gargle.HOWL> References: <17019.43943.917207.729648@gargle.gargle.HOWL> Message-ID: <427BB1D2.7030804@nyc.rr.com> rpgoldman at real-time.com wrote: >Would it be possible for someone on the list to clue us in on the >status of Cells-gtk now that there is a new version of Cells? > >A while ago there was a lot of email traffic that seemed to be >concerned with this issue, but as a newcomer, I really didn't follow >it. It SEEMED like there was some version skew, but I didn't >understand. > As I understand it, the folks in cells-gtk maintain a tarball known to have everything you need, including cells and utils-kt, isoloating the crew from any tossing and turning in the Cells world. My understanding was that cells-gtk worked OK with cells after a tweak or two, but I might be mistaken, and at any rate they will not pull Cells-2 into the tarball without making sure it all works. Note, btw, that cells-gtk already uses a version including the new technology of cells-2, just not the actual source release that Mr. Brudick made. ie, Just grab the tarball and you probably do not need to worry about any cells-2 release issues. kenny From peter.denno at nist.gov Fri May 6 18:14:05 2005 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 6 May 2005 14:14:05 -0400 Subject: [cells-devel] cells-gtk status In-Reply-To: <17019.43943.917207.729648@gargle.gargle.HOWL> References: <17019.43943.917207.729648@gargle.gargle.HOWL> Message-ID: <200505061414.05944.peter.denno@nist.gov> On Friday 06 May 2005 13:38, rpgoldman at real-time.com wrote: > Would it be possible for someone on the list to clue us in on the > status of Cells-gtk now that there is a new version of Cells? In my work I switched to a new version of cells April 28 -- whatever was available then. I haven't noticed any difference. As I have read on this list, cells 2.0 is mostly just reorganization (bringing utils-kt under the cells directory). I hope to do some work on cells-gtk in the next few weeks (adding some abilities to combo-box -- it can be made to use the tree model to allow hierarchical organization, look into use with sbcl ... among other things). At that time, I'll make a tarball using the current version of 2.0...but I don' think it should matter much. Or has there been some substantial changes that are affecting the use of cells-gtk ??? > A while ago there was a lot of email traffic that seemed to be > concerned with this issue, but as a newcomer, I really didn't follow > it. It SEEMED like there was some version skew, but I didn't > understand. Maybe you are referring to a discussion between myself and Kenny Tilton on the cells-gtk list about the /possibility/ of that occurring over time ??? -- - Best regards, Peter From ktilton at nyc.rr.com Fri May 6 18:35:13 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 06 May 2005 14:35:13 -0400 Subject: [cells-devel] Cells 2 Synapses... In-Reply-To: <200505061414.05944.peter.denno@nist.gov> References: <17019.43943.917207.729648@gargle.gargle.HOWL> <200505061414.05944.peter.denno@nist.gov> Message-ID: <427BB8E1.9070702@nyc.rr.com> ... look broken, in the case where the only dependency would be on the synapse. Well, I am sure they have been broken for longer than that. Anyway, once I fix them I will also get onto cleaning up the CVS tree under the Cells project, and then post the Cells 2 code there. The CVS tree then becomes the official version. kenny From ktilton at nyc.rr.com Sat May 7 18:56:46 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 07 May 2005 14:56:46 -0400 Subject: [cells-devel] CVS Clean-up Message-ID: <427D0F6E.1040800@nyc.rr.com> OK, the Cells CVS repository has been cleaned up and I am on the verge of making my first changes to Cells, so (a) beware and (b) anyone with a standalone tarball will soon be diverging from the official code. My first change will be an oddity: ephemeral cells, when reset, do not get the corresponding slot value reset. I have not made this change yet, so maybe it was that way for a reason? Hard to imagine. Second will be repairing the damage done to Synapses. Well, overall the change was good, it just broke Synapses. I am starting to see how the same change done properly will simplify Cells a little: Synapses always had two rules: should I fire, and what value should I pass along? Normal Cells only had the "what value?" rule, with a hard-coded (kinda) test "has it changed?" to decide whether or not to fire. The default changed test EQL could be overridden, but that was it. In the change that broke Synapses, I simply eliminated Synapses as a separate data structure and implemented them with Cell structures, the fire test and value rules being combined in one lambda for the Cell value rule. Goofy mistake since the standard Cell was still being controlled by the "unchanged" rule. So the Deep Fix will be to meet half-way, and now enhance standard Cells to work like Synapses, by moving the "unchanged" test into a "fire?" mechanism. This is not the unification of Gravity with Electromagnetism, but it should simplify the code some. It should also take quite a few days, especially since I realize I better get to work on the regression test suite. kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 Sat May 7 21:30:55 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 07 May 2005 17:30:55 -0400 Subject: [cells-devel] Next Steps In-Reply-To: <427D0F6E.1040800@nyc.rr.com> References: <427D0F6E.1040800@nyc.rr.com> Message-ID: <427D338F.8090307@nyc.rr.com> Kenny Tilton wrote: > OK, the Cells CVS repository has been cleaned up and I am on the verge > of making my first changes to Cells, so (a) beware and (b) anyone with > a standalone tarball will soon be diverging from the official code. > > My first change will be an oddity: ephemeral cells, when reset, do not > get the corresponding slot value reset. I have not made this change > yet, so maybe it was that way for a reason? Hard to imagine. > > Second will be repairing the damage done to Synapses. No, come to think of it second will be some easier work: (a) a check that Cells is not *stop*ped, which will be avoidable with a new special I will set when working under typical window manager environments (a long story, wherein the app cannot be successfully killed because the IDE keeps allowing OS events thru to application windows). (b) eliminate the check for looping in which one setf of a cell leads back to setf of the same cell (the scroll bar scenario). I will leave the code behind in case I decide to simply enhance cycle detection as opposed to wiping it out entirely. Then I will properly Unify Synapses with Cells, and beef up the test suite a little. Comments welcome. kt From peter.denno at nist.gov Sat May 7 22:49:31 2005 From: peter.denno at nist.gov (Peter Denno) Date: Sat, 7 May 2005 18:49:31 -0400 Subject: [cells-devel] Next Steps In-Reply-To: <427D338F.8090307@nyc.rr.com> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> Message-ID: <200505071849.31966.peter.denno@nist.gov> On Saturday 07 May 2005 17:30, Kenny Tilton wrote: > No, come to think of it second will be some easier work: > > (a) a check that Cells is not *stop*ped, which will be avoidable with a > new special I will set when working under typical window manager > environments (a long story, wherein the app cannot be successfully > killed because the IDE keeps allowing OS events thru to application > windows). This sounds good. I think we in cells-gtk-land are suffering from something like this. -- - Best regards, Peter From ktilton at nyc.rr.com Sun May 8 16:55:42 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 08 May 2005 12:55:42 -0400 Subject: [cells-devel] Two Next Steps for Cells, One New CL-6502 Module For Example In-Reply-To: <427D338F.8090307@nyc.rr.com> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> Message-ID: <427E448E.9060201@nyc.rr.com> >> OK, the Cells CVS repository has been cleaned up and I am on the >> verge of making my first changes to Cells, so (a) beware and (b) >> anyone with a standalone tarball will soon be diverging from the >> official code. >> >> My first change will be an oddity: ephemeral cells, when reset, do >> not get the corresponding slot value reset. I have not made this >> change yet, so maybe it was that way for a reason? Hard to imagine. >> >> Second will be repairing the damage done to Synapses. > > > No, come to think of it second will be some easier work: > > (a) a check that Cells is not *stop*ped, which will be avoidable with > a new special I will set when working under typical window manager > environments (a long story, wherein the app cannot be successfully > killed because the IDE keeps allowing OS events thru to application > windows). > > (b) eliminate the check for looping in which one setf of a cell leads > back to setf of the same cell (the scroll bar scenario). I will leave > the code behind in case I decide to simply enhance cycle detection as > opposed to wiping it out entirely. Done. And with (b) I have created a new example cells-inside module from James Bielman's nifty cl-6502 assembler code, named cl-6502. It cycles a little on setf to effect a two-pass assemble. Next will be.... > > Then I will properly Unify Synapses with Cells, and beef up the test > suite a little. kt From tfb at OCF.Berkeley.EDU Mon May 9 13:20:43 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 9 May 2005 06:20:43 -0700 Subject: [cells-devel] CVS Clean-up In-Reply-To: <427D0F6E.1040800@nyc.rr.com> References: <427D0F6E.1040800@nyc.rr.com> Message-ID: <17023.25515.482414.716804@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > OK, the Cells CVS repository has been cleaned up and I am on the verge > of making my first changes to Cells, so (a) beware and (b) anyone with a > standalone tarball will soon be diverging from the official code. Well, the released code, anyway. I think the moral of the story is: version 2.1 is coming in the not-too-distant future. > My first change will be an oddity: ephemeral cells, when reset, do not > get the corresponding slot value reset. I have not made this change yet, > so maybe it was that way for a reason? Hard to imagine. I have a vague memory of talking about this, but I don't remember why. Either way, it only affects the non-cells view of the object, right? > Second will be repairing the damage done to Synapses. Well, overall the > change was good, it just broke Synapses. I am starting to see how the > same change done properly will simplify Cells a little: > > Synapses always had two rules: should I fire, and what value should I > pass along? Normal Cells only had the "what value?" rule, with a > hard-coded (kinda) test "has it changed?" to decide whether or not to > fire. The default changed test EQL could be overridden, but that was it. I really should remember to use this feature sometime. I think the name "synapse" is too clever for me: I never remember what it means, and end out not using them where they're appropriate. > In the change that broke Synapses, I simply eliminated Synapses as a > separate data structure and implemented them with Cell structures, the > fire test and value rules being combined in one lambda for the Cell > value rule. Goofy mistake since the standard Cell was still being > controlled by the "unchanged" rule. > > So the Deep Fix will be to meet half-way, and now enhance standard Cells > to work like Synapses, by moving the "unchanged" test into a "fire?" > mechanism. This is not the unification of Gravity with Electromagnetism, > but it should simplify the code some. Sounds good. Hey, if it's available as a keyword option to c-formula, I might actually see it and use it :-) From tfb at OCF.Berkeley.EDU Mon May 9 13:26:08 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 9 May 2005 06:26:08 -0700 Subject: [cells-devel] Next Steps In-Reply-To: <427D338F.8090307@nyc.rr.com> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> Message-ID: <17023.25840.841533.147600@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > (b) eliminate the check for looping in which one setf of a cell leads > back to setf of the same cell (the scroll bar scenario). I will leave > the code behind in case I decide to simply enhance cycle detection as > opposed to wiping it out entirely. I think The Right Thing is to allow looping by default, assuming that the programmer knows what they're doing, and to be able to optionally declare a certain cell to be non-cyclic. From ktilton at nyc.rr.com Mon May 9 14:22:58 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 09 May 2005 10:22:58 -0400 Subject: [cells-devel] Next Steps In-Reply-To: <17023.25840.841533.147600@conquest.OCF.Berkeley.EDU> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> <17023.25840.841533.147600@conquest.OCF.Berkeley.EDU> Message-ID: <427F7242.3070509@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > (b) eliminate the check for looping in which one setf of a cell leads > > back to setf of the same cell (the scroll bar scenario). I will leave > > the code behind in case I decide to simply enhance cycle detection as > > opposed to wiping it out entirely. > >I think The Right Thing is to allow looping by default, assuming that >the programmer knows what they're doing, > done. > and to be able to optionally >declare a certain cell to be non-cyclic > for debugging? ie, How are non-cyclic cells to be handled? Scrollbars want zero revisits, the 6502 assembler wanted one. But this is irrelevant since they do not need to be non-cyclic. Both work unrestricted because they coast to a stop naturally, converging on one stable value. So what case can you think of for non-cyclic? And then should there be a cyclep test, to fully generalize the mechanism? It could be TRUE, FALSE, or a custom function. kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 Mon May 9 14:25:49 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 09 May 2005 10:25:49 -0400 Subject: [cells-devel] CVS Clean-up In-Reply-To: <17023.25515.482414.716804@conquest.OCF.Berkeley.EDU> References: <427D0F6E.1040800@nyc.rr.com> <17023.25515.482414.716804@conquest.OCF.Berkeley.EDU> Message-ID: <427F72ED.1040208@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > OK, the Cells CVS repository has been cleaned up and I am on the verge > > of making my first changes to Cells, so (a) beware and (b) anyone with a > > standalone tarball will soon be diverging from the official code. > >Well, the released code, anyway. I think the moral of the story is: >version 2.1 is coming in the not-too-distant future. > Yeah, the Semi-Grand Unification of Synapses and Cells will rate a full tenth. > > > My first change will be an oddity: ephemeral cells, when reset, do not > > get the corresponding slot value reset. I have not made this change yet, > > so maybe it was that way for a reason? Hard to imagine. > >I have a vague memory of talking about this, but I don't remember why. >Either way, it only affects the non-cells view of the object, right? > Yep, but after marrying Cells to AllegroStore I became quite sensitive to the need for a value to occupy its slot, because a lot of AStore's magic relies on that. > > > Second will be repairing the damage done to Synapses. Well, overall the > > change was good, it just broke Synapses. I am starting to see how the > > same change done properly will simplify Cells a little: > > > > Synapses always had two rules: should I fire, and what value should I > > pass along? Normal Cells only had the "what value?" rule, with a > > hard-coded (kinda) test "has it changed?" to decide whether or not to > > fire. The default changed test EQL could be overridden, but that was it. > >I really should remember to use this feature sometime. I think the >name "synapse" is too clever for me: I never remember what it means, >and end out not using them where they're appropriate. > heh-heh. I name all canned synapses f-something, for "filter". > > > In the change that broke Synapses, I simply eliminated Synapses as a > > separate data structure and implemented them with Cell structures, the > > fire test and value rules being combined in one lambda for the Cell > > value rule. Goofy mistake since the standard Cell was still being > > controlled by the "unchanged" rule. > > > > So the Deep Fix will be to meet half-way, and now enhance standard Cells > > to work like Synapses, by moving the "unchanged" test into a "fire?" > > mechanism. This is not the unification of Gravity with Electromagnetism, > > but it should simplify the code some. > >Sounds good. Hey, if it's available as a keyword option to c-formula, >I might actually see it and use it :-) > The first thing called will be the "firep" function, which decides if a Cell should propagate to others once someone else has propagated to it. If so, the fire-value function is called to determine the value to respond with when sampled. Current Cells behavior is to decide its new value and then decide whether to propagate by calling c-unchanged-p or some such. This can be expressed in the new scheme as: -- firep decides a new value and caches it as the new value to return when sampled. -- It then uses c-unchanged-p (?) to get its return value (indicating firep). kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 rpgoldman at real-time.com Mon May 9 14:41:02 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Mon, 9 May 2005 09:41:02 -0500 Subject: [cells-devel] Next Steps In-Reply-To: <427F7242.3070509@nyc.rr.com> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> <17023.25840.841533.147600@conquest.OCF.Berkeley.EDU> <427F7242.3070509@nyc.rr.com> Message-ID: <17023.30334.674889.935425@gargle.gargle.HOWL> >>>>> "KT" == Kenny Tilton writes: KT> Thomas F. Burdick wrote: >> Kenny Tilton writes: >> >> > (b) eliminate the check for looping in which one setf of a cell leads >> > back to setf of the same cell (the scroll bar scenario). I will leave >> > the code behind in case I decide to simply enhance cycle detection as >> > opposed to wiping it out entirely. >> >> I think The Right Thing is to allow looping by default, assuming that >> the programmer knows what they're doing, >> KT> done. >> and to be able to optionally >> declare a certain cell to be non-cyclic >> KT> for debugging? ie, How are non-cyclic cells to be handled? Perhaps I'm missing something, but I would have thought that cyclic cells would have been the unusual case, and the one you want to trap by default. I.e., it would make more sense to default to acyclic, and then allow users to explicitly declare cycles. I suppose there are two colliding philosophies here: 1. the cyclic case is the one likely to cause inefficiencies and/or bugs. So make it exceptional, and require your user to declare it explicitly. Also this lets your users find cycles using Cells as a tool. 2. Things should mostly work w/o declarations, so the cyclic case should be the default. You should be able to declare acyclicity specifically, as a way of providing more efficiency (but do we know how to do this?). Cheers, R From ktilton at nyc.rr.com Mon May 9 17:02:33 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 09 May 2005 13:02:33 -0400 Subject: [cells-devel] Next Steps In-Reply-To: <17023.30334.674889.935425@gargle.gargle.HOWL> References: <427D0F6E.1040800@nyc.rr.com> <427D338F.8090307@nyc.rr.com> <17023.25840.841533.147600@conquest.OCF.Berkeley.EDU> <427F7242.3070509@nyc.rr.com> <17023.30334.674889.935425@gargle.gargle.HOWL> Message-ID: <427F97A9.7080209@nyc.rr.com> rpgoldman at real-time.com wrote: >>>>>>"KT" == Kenny Tilton writes: >>>>>> >>>>>> > > KT> Thomas F. Burdick wrote: > > >> Kenny Tilton writes: > >> > >> > (b) eliminate the check for looping in which one setf of a cell leads > >> > back to setf of the same cell (the scroll bar scenario). I will leave > >> > the code behind in case I decide to simply enhance cycle detection as > >> > opposed to wiping it out entirely. > >> > >> I think The Right Thing is to allow looping by default, assuming that > >> the programmer knows what they're doing, > >> > KT> done. > > >> and to be able to optionally > >> declare a certain cell to be non-cyclic > >> > KT> for debugging? ie, How are non-cyclic cells to be handled? > >Perhaps I'm missing something, but I would have thought that cyclic >cells would have been the unusual case, and the one you want to trap >by default. I.e., it would make more sense to default to acyclic, and >then allow users to explicitly declare cycles. > Actually, that is the way it has been for ages, and the change just made was to flip the direction of that choice. Cells now effortlessly run on propagating if the user chooses to set things up that way. And I think that is actually a natural way to program in what we might call a causation paradigm of programming. For now you are right, it is the exception, but I have also been looking at solving certain problems with more of this. But that is not the main issue here. The fact is, detecting cycles takes extra (Cells internal) code and extra runtime effort, including maintaining a list of "causers" in a given data pulse so as to detect cycles. (Propagation no longer takes place in a call stack, so there is no clear place to set/clear a flag indicating causation is underway.) The interesting question is not the default value for the cyclicp parameter, should it return to Cells; anyone can override the group choice with their own macros. The question now is simply whether and how to allow the user special syntax by which to control cycling. kt From ktilton at nyc.rr.com Fri May 13 23:25:55 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 13 May 2005 19:25:55 -0400 Subject: [cells-devel] Re: [cells-gtk-devel] making a text-buffer inputp In-Reply-To: <200505131753.32363.peter.denno@nist.gov> References: <42851EF3.9060606@drugphish.ch> <200505131753.32363.peter.denno@nist.gov> Message-ID: <42853783.40507@nyc.rr.com> Peter Denno wrote: >On Friday 13 May 2005 17:41, Jonathan Heusser wrote: > > >I think you want :text (c-in "bla") here. > Agreed. Hope it works. Even so, I am curious how Cells internals ended up calling ADOPT-CT on the string. If possible, I would like to shield users from that kind of error by detecting the error further upstream. This is a general policy of mine, so any time anyone gets a nasty error from Cell internals I would be happy to look into adding some programmer friendliness if a detailed report (preferably the failing source) is forwarded. The good news is that I myself no longer find myself poking around Cells internals to resolve application programming problems, but that might just mean I am in part figuring things out in my head based on long experience. kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 Wed May 18 18:35:17 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 18 May 2005 14:35:17 -0400 Subject: [cells-devel] New Cells Use Case, comments welcome Message-ID: <428B8AE5.5000401@nyc.rr.com> Sorry for spaming all the groups, but the occasion (Cells doc) is rare enough I thought everyone should be included. From here on is a standalone example (with Cells loaded) that reads data from itself. It models tracking of an index of stocks. I plan a few more notes, but thought I would invite comments/requests for clarification now. Here goes: (in-package :cells) #| The deal is this: explanations of chunks of code appear /below/ them. Now here are Ron's functional requirements: process a stream of messages from an imagined source of financial data. Actually, Ron has an intermediate process reading a real source and producing a somewhat-digested stream in Lisp-friendly format. Sample: (:date 5123 :weekday 3) (:index ((AA 29.30 7.3894672) (AIG 53.30 7.3894672)(AXP 53.00 7.3894672) (BA 59.87 7.3894672) (C 46.80 7.3894672) (CAT 87.58 7.3894672) (DD 47.74 7.3894672) (DIS 26.25 7.3894672) (GE 36.10 7.3894672) (GM 27.77 7.3894672) (HD 36.75 7.3894672) (HON 35.30 7.3894672) (HPQ 21.00 7.3894672) (IBM 76.47 7.3894672) (INTC 23.75 7.3894672) (JNJ 68.73 7.3894672) (JPM 35.50 7.3894672) (KO 43.76 7.3894672) (MCD 29.80 7.3894672) (MMM 76.76 7.3894672) (MO 65.99 7.3894672) (MRK 34.42 7.3894672) (MSFT 25.36 7.3894672) (PFE 27.5 7.3894672) (PG 54.90 7.3894672) (SBC 23.8 7.3894672) (UTX 100.96 7.3894672) (VZ 36.75 7.3894672) (WMT 48.40 7.3894672) (XOM 56.50 7.3894672))) (:trade INTC 0.001932 :last 23.75) (:trade MSFT 0.001932 :last 25.36) (:trade INTC 0.011931 :last 23.75) (:trade MSFT 0.011931 :last 25.36) (:trade MSFT 0.041965 :last 25.32) (:trade UTX 0.067027 :last 101.39) ...etc... Date messages encode date as (+ (* (- year 2000) 1000) julian-days). Weekday is dicey, so the tutorial deduces the Lisp weekday and stores that. Index messages define which tickers are in the index and their weights. Entries are: (ticker-symbol initial-price index-weight) Trade messages are (ticker-symbol ticker-minute :LAST price) Ticker-minute is time since open, in minutes. Negative indicates pre-open trading. To get the ball rolling, we just want to print out each trade as received, with the addition of an indicator as to which way the price moved: -1, 0, or 1 for down, unchanged, or up. For the index, we want to track the minute of the last trade affecting the index, the weighted index value, and the last move of each index entry. |# (defparameter *trc-trades* t) #+test (run-trading-day) (defun run-trading-day () (cell-reset) (let ((*trc-trades* nil) (t-day (make-be 'trading-day))) ;; - always call CELLS-RESET when starting a test run ;; - (make-be ...) -> (to-be (make-instance ...)) ;; - TO-BE jumpstarts a Cells instance into the flow. (FN to-be) #+not (with-open-file (t-data (make-pathname :directory '(:absolute "0dev" "cells" "Use Cases" "dow-jones") :name "stock-exchange" :type "lisp")) (with-metrics (nil t "run-trading-day") (loop for message = (read t-data nil :eof) until (eq message :eof) do (setf (message t-day) message))) ) (with-open-file (t-data (make-pathname :directory '(:absolute "0dev" "cells" "Use Cases" "dow-jones") :name "stock-exchange" :type "lisp")) (with-metrics (t t "run-trading-day") (loop with in-data = nil do (if (not in-data) (setf in-data (msg-start (read-line t-data nil :eof))) (let ((message (read t-data nil :eof))) (count-it :dow-message) (if (eql (car message) :close) (loop-finish) (setf (message t-day) message))))))) (trc "index value = " (value (car (indexes t-day)))))) ;; --- trading day --------------------------------- ;; (defmodel trading-day () ((message :initarg :message :accessor message :initform (c-in nil) ;; c-in -> c-input, how data enters a model (see FN c-input) :cell :ephemeral) ;; handling transient phenomena in a steady-state paradigm (FN ephemeral) (date :initarg :date :accessor date :initform (c? (or .cache ;; advanced trick using prior value (see FN date/.cache) (when (eql :date (car (^message))) (destructuring-bind (&key date weekday) (^message) (declare (ignore weekday)) ;; derive from date (encode-julian-date (+ 2000 (floor date 1000)) (mod date 1000))))))) (weekday :initarg :weekday :accessor weekday :initform (c? (when (^date) (multiple-value-bind (second minute hour date month year day daylight-p zone) (decode-universal-time (^date)) (declare (ignorable second minute hour date month year daylight-p zone)) day)))) ;; not much new here, but astute readers will wonder if this cell gets optimized away ;; when (^date) on its second evaluation uses its .cache and gets optimized away. ;; ;; yes. Just checked to be sure. (trade :cell :ephemeral :initarg :trade :accessor trade :initform (c? (when (eql :trade (car (^message))) (message-to-trade (^message))))) ;; ;; nothing new here, but note that again we use the :ephemeral option ;; (indexes :initarg :indexes :accessor indexes :initform (c? (with-c-cache ('cons) (when (eql :index (car (^message))) (make-be 'index :trading-day self :index-def (second (^message))))))) (tickers :cell nil :reader tickers :initform (make-hash-table :rehash-size 50)) )) (def-c-output trade ((self trading-day) trade) ;; FN def-c-output (when trade ;; FN trade setf optimization (push trade (trades (ensure-ticker self (trade-ticker-sym trade)))))) (defun trading-day-ticker (day sym) (gethash sym (tickers day))) (defun (setf trading-day-ticker) (ticker day sym) (setf (gethash sym (tickers day)) ticker)) (defun ensure-ticker (trading-day ticker-sym &optional price minute) (or (trading-day-ticker trading-day ticker-sym) (setf (trading-day-ticker trading-day ticker-sym) (make-be 'ticker :ticker-sym ticker-sym :trades (c-in (when price (list (make-trade :ticker-sym ticker-sym :minute minute :price price)))))))) (defmodel ticker (model) ((ticker-sym :cell nil :initarg :ticker-sym :reader ticker-sym) (trades :initarg :trades :accessor trades :initform (c-in nil)) (last-move :reader last-move :initform (c? (bwhen (penult-trade (second (^trades))) (let ((last (trade-price (first (^trades)))) (penult (trade-price penult-trade))) (cond ((< last penult) -1) ((= last penult) 0) (t 1))))) :documentation "Price up, down, or unchanged as 1, -1, or zero"))) ;; ;; Small point: there is no problem with accessing a dependency twice, as above. ;; (defun ticker-price (ticker) (bwhen (trade (car (trades ticker))) (trade-price trade))) (defun ticker-trade-minute (ticker) (bwhen (trade (car (trades ticker))) (trade-minute trade))) (def-c-output trades ((self ticker)) ;; FN trades def-c-output (when *trc-trades* (loop for trade in (set-difference new-value old-value) do (format t "~&at ~a min, ~a at ~a, change ~a" (trade-minute trade) (ticker-sym self) (trade-price trade) (or (^last-move) ""))))) ;; --- index --------------------------------------------------- (defmodel index () ((index-def :cell nil :initarg :index-def :initform nil :accessor index-def) (trading-day :cell nil :initarg :trading-day :initform nil :accessor trading-day) (ticker-weights :initarg :ticker-weights :accessor ticker-weights :initform (c? (loop for (ticker-sym price weight) in (index-def self) collecting (cons (ensure-ticker (trading-day self) ticker-sym price -60) ;; whoa, a mid-rule to-be! (FN ticker-weights rule) weight)))) (state :reader state :initform (let ((moves (make-hash-table :size 50))) (c-formula (:lazy t) ;; do not re-compute on every trade (see FN lazy) (count-it :index-state-calc) (clrhash moves) ;; Re-use OK since fresh cons triggers dataflow (FN state rule) (let ((minutes (loop for (ticker . nil) in (ticker-weights self) maximizing (ticker-trade-minute ticker)))) (without-c-dependency ;; dependency on trade minute suffices (see FN without-c-dependency) (loop for (ticker . weight) in (ticker-weights self) summing (* weight (ticker-price ticker)) into value do (setf (gethash (ticker-sym ticker) moves) (last-move ticker)) finally (return (list minutes value moves)))))))) (value :reader value :initform (c? (second (^state)))) ;; ;; allows dependency on just value, which will not change on unchanged trades (FN value cell) )) (defun index-minutes (index) (first (state index))) (defun index-moves (index) (third (state index))) (defun index-ticker-sym-move (index ticker-sym) (gethash ticker-sym (index-moves index))) (defun index-ticker-move (index ticker) (index-ticker-sym-move index (ticker-sym ticker))) (def-c-output value ((self index)) (when *trc-trades* (trc "index time:" (index-minutes self) :value new-value :was old-value))) ;;; --- trade --------------------------------------------------------------------- (defstruct trade minute ticker-sym price) (defun message-to-trade (message) (destructuring-bind (ticker-sym ticker-min &key last) (rest message) (make-trade :ticker-sym ticker-sym :minute ticker-min :price last))) ;;; --- utilities --------------------------------------------------------- (defun encode-julian-date (year julian) (+ (encode-universal-time 0 0 0 1 1 year ) (* (1- julian) 86400))) ;; seconds in a day ;; I am sorry, that is all there is to tell. So we have a mindless main loop and a few declarations ;; and somehow we get all the functionality desired. [OK, granted, this is a pretty simple ;; batch process which would not be too complicated in non-Cells form. In that regard, it ;; is a good tutorial use case but does not show off Cells very much.] Anyway... ;; ;; It occurs to me that the above notes do not convey how the damn thing works. So let us walk ;; thru a hand-execution of the above sample data. ;; ;; (make-be 'trading-day) -> (to-be (make-instance 'trading-day)) ;; ;; Each ruled Cell gets evaluated. Each Cell slot -- constant, input, or ruled -- is output. ;; So with trading-day: ;; ;; message is input, and has no associated output function ;; ;; date is evaluated: ;;; (or .cache ;;; (when (eql :date (car (^message))) ;;; (destructuring-bind (&key date weekday) ;;; (^message) ;;; (declare (ignore weekday)) ;; derive from date ;;; (encode-julian-date (+ 2000 (floor date 1000)) (mod date 1000))))) ;; ;; .cache is nil, but so is (message self). NIL is returned, there is no output. ;; date now has a dependency on message. ;; ;; weekday is evaluated ;;; (c? (when (^date) ;;; (multiple-value-bind (second minute hour date month year day daylight-p zone) ;;; (decode-universal-time (^date)) ;;; (declare (ignorable second minute hour date month year daylight-p zone)) ;;; day)))) ;; date is nil, so weekday is NIL but has a dependency on date. No output is defined. ;; ;; trade is evaluated ;;; (c? (when (eql :trade (car (^message))) ;;; (message-to-trade (^message))))) ;; message is NIL, so NIL is returned. trade now has a dependency on message. The output ;; method on trade is invoked, but has no interest in NIL new values. ;; ;; indexes is evaluated: ;;; (with-c-cache ('cons) ;;; (when (eql :index (car (^message))) ;;; (make-be 'index ;;; :trading-day self ;;; :index-def (second (^message))))))) ;; message is NIL, so NIL is returned, a dependency on message created. No output defined. ;; ;; (setf (message t-day) ) ;; ;; Many rules are dispatched: date, trade, and indexes. Only date processes :date messages. ;; it returns a converted date, and still has a dependency on message. Weekday has a dependency ;; on date, so that rule gets dispatched. It returns a weekday calculated off the date, and ;; keeps the dependency on that. Other rules return ;; NIL, which is the same value they had before. Nothing else is done (and in this case, that ;; would only have been to call the output method on trade. ;; ;; (setf (message t-day) ) ;; ;; The date rule runs and returns its .cache without accessing any cell. The Cell internals ;; optimize away the fact that date ever had a rule or any kind of cell. It sees weekday ;; was a dependent on date and nothing else, so it optimizes that away, too. Slots end up ;; with the last values calculated, and now look to other rules as if they were constant ;; all along. ;; ;; The trade rule runs and comes up empty again. The indexes rule runs and adds a new ;; index list to its current contents, which happens to be NIL. ;; ;;;; make-be is called on the index instance. Each slot gets processed in turn in a ;;;; fashion similar to that for trading-day. When the ticker-weights rule runs, ticker ;;;; instances for each ticker in the index are created and passed to TO-BE, in the ;;;; function ensure-ticker. No dependencies are created since index-def is not a Cell, ;;;; so the ticker-weights cell gets optimized away. ;;;; ;;;; as each ticker is created and processed by TO-BE: ;;;;;;; ;;;; the state rule is evaluated and computes an initial index state off the data ;;;; provided in the index-def. state ends up with dependencies on each ticker in the ;;;; index. ;; [rest under construction] ;; ;;; ============================================================================= ;;; Footnotes ;;; ============================================================================= ; ;; --- FN to-be -------------------------------------- ;; TO-BE jumpstarts a Cells instance into the flow. Literally, as in ;; the dataflow. It evaluates ruled slots to establish dependencies (those ;; get established during evaluation) and in turn arrange for state change ;; within the model to propagate to the instance's ruled Cells. It also ;; DEF-C-OUTPUTs all cell slots so the outside world is consistent ;; with the model state. More on def-c-output below. ; ;; --- FN c-input ------------------------------------ ;; ;; c-in is short for c-input, which simply means imperative application code ;; can SETF this slot. (Note that this is just the initform for this slot, ;; which can be overridden by subclasses or at make-instance time, and if ;; the override is not another C-IN or C-INPUT, then all bets are off. ie, The ;; SETF ability depends on the type of Cell (if any) associated at run-time ;; with the slot of an instance. It ;; is not an attribute of the slot as with the :cell slot option discussed just below. ;; ;; Anyway, C-IN lets us make a lot of points about Cells. ;; ;; First, no model is ;; an island; the dataflow has to start somewhere. Just as a VisiCalc spreadsheet ;; has cells where you can type, say, different interest rates to see how that ;; effects the rest of a financial model, a Cell-based application model needs ;; some way to interface with the outside world, if only the mouse and keyboard ;; of a GUI application. ;; ;; The way we do that is by having conventional application code feed (SETF) data into ;; the dataflow model at what we call cell inputs. In a typical GUI app, this means ;; having callbacks registered with the window manager. The callbacks then take their ;; arguments (window events such as mouse-downs and key-presses) and setf that ;; info to slots of a window or system instance modelling the window or operating ;; system, slots mediated by c-input Cells. ;; ;; In this simple use case we have just one stream of external inputs (messages ;; from some financial data service) being SETFed into one slot, the message ;; slot of an instance of the trading-day class. ;; ;; Second, the Cells design enforces discipline. So in case you are ;; wondering, no, if you do not bind a C-INPUT to a slot of an instance, you cannot ;; SETF that slot from imperative code. (Aside: (SETF SLOT-VALUE) /is/ a back door ;; allowing you to wreak havoc on your dataflow model if you so choose (but it will ;; wreak havoc).) ;; ;; Third, you might wonder why slots meant as inputs cannot just have no Cell at all ;; associated with them at run-time, and then have the Cell internals accept that ;; as a SETF-able state. Well, it is a long story, but it turns out that a lot of ;; Cells overhead can be avoided if we distinguish a slot whose value will never ;; change from an input slot which will be SETF'ed. A simple example of a constant ;; slot would be the bounding rectangle of a push button. Those values have to be ;; Cells because in other graphical elements sharing the same superclass, the bounding ;; rectangle changes. A good example is the win32-style scroll bar thumb, which changes ;; size to reflect how much of the total file is visible. Anyway, it turns out that ;; a significant performance boost comes from having Cells which happen to access ;; a constant value not record a dependency on that value and, where a rule evaluation ;; turns out not to access any non-constant other Cell slot, likewise convert the ruled ;; slot into a constant slot. Sorry you asked? ;; ;; --- FN ephemeral ----------------------------------------------------------- ;; ;; Whoa, here is an advanced topic. Ephemeral means "fleeting". Before getting into ;; that, the other options for the :cell option are T and NIL. T is the default. ;; NIL means you get a normal slot having nothing to do with Cells. Now about ;; that :ephemeral option: Messages are ;; like events: they happen, then they are no more. This is a problem for ;; Cells, which like a VisiCalc spreadsheet model (say, your household budget) ;; is all about steady-state occasionally perturbed by inputs. That is vague. ;; Here is a concrete example: suppose you have some game where the user has ;; to press a key when two randomly moving shapes overlap. You will have a hit rule ;; that says (abbreviated somewhat): ;; ;; (and (eql (event *sys*) :keypress) (shapes-overlap-p *sys*)) ;; ;; OK, the key is pressed but the shapes do not overlap. No cigar. Now a few ;; seconds later the shapes do overlap. The key is not being pressed, but the ;; EVENT slot of the *sys* instance (modelling the computer system) still ;; says :keypress. bad news. Obviously we need to process an event and then ;; clear the value before processing any other model input. Now perhaps we could ;; simply have imperative code which says: ;; ;; (setf (event *sys*) :keypress) ;; (setf (event *sys*) nil) ;; ;; But that is different. That suggests an application semantic in which the ;; EVENT slot changes from :keypress to NIL. It will trigger all the usual ;; dataflow, to see if the model should react. But in fact what we /really/ ;; need is /not/ to clear the EVENT slot. What we really need is ;; ephemeral SETF behavior from a mechanism designed for steady-state. ;; We need the EVENT slot to take on a value just long enough to perturb our ;; model and then cease to be without fanfare. ;; ;; So we extend the Cells model with the :ephemeral option on a slot, and have ;; Cell internals watch out for that and silently clear the slot once a value ;; has been propagated to other Cells and output (again, outputs ;; are discussed below.) ;; ;; A final newbie note: watch the bouncing options. Ephemerality is a slot option, ;; not something one tailors to the instance. Think about it. Think about the ;; slot names. "message", "event". We want to get ephemeral behavior for these ;; slots no matter what cell (input or ruled) we choose to associate with them. ;; So it is more convenient and reliable to endow the slot itself with ephemerality. ;; in other cases we see different instances enjoying different Cell-ish qualities ;; for the same slot, sometimes constant, sometimes computed, sometimes being ;; SETFed by imperative code outside the dataflow model. These variations are ;; then found in the type of runtime Cell associated with the Cell slot. ;; ;; --- FN date/.cache -------------------------------------------------- ;; ;; ;; There is a lot going on here, too, including some premature optimization. ;; ;; First of all, .cache is just a local variable, bound by the expansion ;; of the C? macro to the latest value calculated for this rule. It starts out as NIL, so ;; the rule next reads the message slot of the same trading-day instance. How so? ;; ;; ^message is a macro written by the defmodel macro. It expands simply to: ;; ;; (message self) ;; ;; It used to expand to more, including vital Cell plumbing. Now I keep it around just ;; because I love that self-documenting quality. And yes, I have adopted the ;; Smalltalk "self" convention over the C++ "this" convention. There is no need ;; to use these (^macros), just code ( self) and you will establish a ;; dependency on the message slot. What does dependency mean? ;; ;; Simply that the next time the message slot changes (the default test between old and ;; new values is EQL, but can be overridden), the Cells engine will immediately kick ;; the DATE rule to see if it wants to compute a different value. ;; ;; A very important point is that dependencies are established automatically simply ;; by invoking the reader or accessor associated with a slot, and that this happens ;; dynamically at run-time, not by inspection of code. A second point is that the ;; dependency is established even if the read takes place in a called function. ;; ;; There is a backdoor. No dependencies are established in code wrapped by ;; the macro WITHOUT-C-DEPENDENCY. ;; ;; Another important point is that dependencies are re-decided completely each time ;; a rule is invoked. So this particular rule is an oddball: it will produce only one value, when a :date ;; message is received ;; and teh first non-NIL value is returned. On the next message (of any kind) .cache will be ;; non-NIL and the rule will simply return that value. ;; During this last evaluation the cell will not access, hence no longer ;; depend on, the message slot or any other slot and it will get optimized away. This ;; improves performance, since the message slot no longer bothers propagating to ;; the date slot and Cell internals no longer have to invoke the rule. Otherwise, every ;; new message for the entire day (none of which would be :date messages) would kick ;; off this rule. ;; ;; --- FN with-c-cache ------------------------------------ ;; ;; I am actually doing something new here. The idea is that again we deviate ;; slightly from the spreadsheet paradigm and want to accumulate data ;; from a stream of ephemeral values. Normally we calculate a slot value in ;; its entirety from data at hand, even if only ephemerally. Here we want ;; to add a newly computed result to a list of prior such results. ;; ;; with-c-cache will accept any two-argument function, and when the enclosed ;; form returns a non-nil value, pass that and the .cache to the specified ;; function. ;; ;; --- FN def-c-output -------------------------------------------- ;; ;; Above is another optimization, and the long-awaited discussion of Cell ;; output. ;; ;; Output reinforces the "no model is an island" theme. We create ;; models to obtain interesting outputs from inputs, where the model ;; provides the interest. For a RoboCup player simulation, the inputs are ;; sensory information about the game, provided in a stream from a server ;; application managing multiple client players and coaches. The outputs are ;; messages to the server indicating player choices about turning, running, ;; and kicking. In between, the game play model is supposed to compute ;; actions producing more or less capable soccer play. ;; ;; --- FN trade setf optimization --------------------------------------- ; ;; But this is strange "output". It actually changes internal model state. ;; It is no output at all, just feeding dataflow back into a different ;; model input. Whassup? ;; ;; Like I said, it is an optimization. A ticker instance could have a ;; rule which watched the message stream looking for trades on that ticker, ;; but then every ticker would be watching the message stream. ;; ;; Instead, we simply leverage an "output" method to procedurally decide which ;; ticker has been traded and directly add the trade to that ticker's list ;; of trades. ;; ;; --- FN trades def-c-output -------------------------------------- ;; ;; Now the above is a proper output. Merely a print trace to standard output, but ;; that happens to be all the output we want just now. In a real trading application, ;; there probably would not be an output on this slot. Some gui widget might "output" ;; by telling the OS to redraw it, or some trader instance might decide to output ;; a buy order to an exchange, but that is about it. ;; ;; --- FN ticker-weights rule -------------------------------------- ;; ;; A curiosity here is that ensure-ticker will often be making and to-be-ing new model ;; instances while this rule is running. No problem, though it would be possible to ;; get into trouble if such destructive (well, constructive) operations triggered ;; dataflow back to this same rule. Here we are safe; it does not. In fact... ;; ;; This rule runs once and then gets optimized away, because in this simple case ;; index-def is a constant, not even a cell. Should we someday want to handle ;; changes to an index during a trading-day, this would have to change. ;; ;; --- FN lazy ------------------------------------------------------ ;; ;; Lazy ruled cells do not get calculated until someone asks their value, ;; and once they are evaluated and dependencies have been established, ;; they merely will be flagged "obsolete" should any of those dependencies ;; change in value. ;; ;; --- FN state rule ------------------------------------------------ ;; ;; c? ends up wrapping its body in a lambda form which becomes the rule for this ;; slot, and here that lambda form will close over the MOVES hash-table. Neat, eh? ;; What is going on is that we do not anticipate in the application design that ;; any cell will depend in isolation on the move of one ticker in the index. So ;; we can allocate just one hashtable at make-instance time and reuse that each ;; time the rule gets evaluated. Cells depending on the state Cell will know ;; when that aggregate value gets recomputed because the finally clause conses ;; up a new list each time. ;; ;; --- FN without-c-dependency ------------------------------------- ;; ;; [to be written] ;; ;; --- FN value Cell -------------------------------------------------- ;; ;; Weird, right? Well, we noticed that many trades came thru at the same price ;; sequentially. The rule above for STATE gets kicked off on each trade, and the ;; index gets recomputed. Because it is an aggregate, we get a new list for state ;; even if the trade was at an unchanged priced and the index value does not change. ;; ;; Now suppose there was some BUY! rule which cared only about the index value, and not ;; the latest minute traded of that value, which /would/ change if a new trade at ;; an unchanged price were received. Because a new list gets consed up (never mind the ;; new trade minute), The BUY! rule would get kicked off because of the new list in the ;; the STATE slot. Not even overriding the default EQL test with EQUAL would work, ;; because the trade minute would have changed. ;; ;; What to do? The above. Let VALUE get recalculated unnecessarily and return unchanged, ;; then code the BUY! rule to use VALUE. VALUE will get kicked off, but not BUY!, which ;; would likely be computationally intense. ;; #| TRADEDATA (:date 5123 :weekday 3) (:index ((AA 29.30 7.3894672) (AIG 53.30 7.3894672)(AXP 53.00 7.3894672) (BA 59.87 7.3894672) (C 46.80 7.3894672) (CAT 87.58 7.3894672) (DD 47.74 7.3894672) (DIS 26.25 7.3894672) (GE 36.10 7.3894672) (GM 27.77 7.3894672) (HD 36.75 7.3894672) (HON 35.30 7.3894672) (HPQ 21.00 7.3894672) (IBM 76.47 7.3894672) (INTC 23.75 7.3894672) (JNJ 68.73 7.3894672) (JPM 35.50 7.3894672) (KO 43.76 7.3894672) (MCD 29.80 7.3894672) (MMM 76.76 7.3894672) (MO 65.99 7.3894672) (MRK 34.42 7.3894672) (MSFT 25.36 7.3894672) (PFE 27.5 7.3894672) (PG 54.90 7.3894672) (SBC 23.8 7.3894672) (UTX 100.96 7.3894672) (VZ 36.75 7.3894672) (WMT 48.40 7.3894672) (XOM 56.50 7.3894672))) (:trade INTC 0.001932 :last 23.75) (:trade MSFT 0.001932 :last 25.36) (:trade INTC 0.011931 :last 23.75) (:trade MSFT 0.011931 :last 25.36) (:trade MSFT 0.041965 :last 25.32) (:trade UTX 0.067027 :last 101.39) (:trade INTC 0.067062 :last 23.82) (:trade MSFT 0.070397 :last 25.37) (:trade INTC 0.070397 :last 23.82) (:trade MSFT 0.074167 :last 25.32) (:trade INTC 0.081800 :last 23.83) (:trade MSFT 0.097178 :last 25.33) (:trade MSFT 0.106488 :last 25.32) (:trade INTC 0.110410 :last 23.82) (:trade INTC 0.124263 :last 23.83) (:trade MSFT 0.130411 :last 25.33) (:trade INTC 0.143792 :last 23.81) (:trade MSFT 0.143792 :last 25.33) (:trade DIS 0.150441 :last 26.25) (:trade INTC 0.160480 :last 23.82) (:trade MSFT 0.160480 :last 25.33) (:trade HPQ 0.166767 :last 21.00) (:trade INTC 0.178832 :last 23.82) (:trade MSFT 0.183710 :last 25.33) (:trade DIS 0.187167 :last 26.25) (:trade AIG 0.193117 :last 53.60) (:trade INTC 0.196399 :last 23.81) (:trade PFE 0.200523 :last 27.51) (:trade MSFT 0.200523 :last 25.33) (:trade GE 0.202185 :last 36.11) (:trade MSFT 0.207199 :last 25.37) (:trade BA 0.209810 :last 59.75) (:trade INTC 0.210524 :last 23.83) (:trade MSFT 0.230556 :last 25.37) (:trade INTC 0.230556 :last 23.83) (:trade BA 0.234812 :last 59.76) (:trade MSFT 0.240580 :last 25.37) (:trade INTC 0.247233 :last 23.83) (:trade MSFT 0.256892 :last 25.37) (:trade UTX 0.257729 :last 101.33) (:trade GE 0.261942 :last 36.11) (:trade AIG 0.267072 :last 53.60) (:trade MSFT 0.272956 :last 25.36) (:trade INTC 0.275617 :last 23.83) (:trade WMT 0.280660 :last 48.40) (:trade SBC 0.284975 :last 23.78) (:trade GE 0.289229 :last 36.10) (:trade MSFT 0.292285 :last 25.35) (:trade DIS 0.295646 :last 26.30) (:trade HPQ 0.303630 :last 21.04) (:trade IBM 0.305629 :last 76.60) (:trade INTC 0.307321 :last 23.81) (:trade INTC 0.310671 :last 23.81) (:trade SBC 0.316331 :last 23.76) (:trade AIG 0.322292 :last 53.60) (:trade MSFT 0.324057 :last 25.36) (:trade MCD 0.324057 :last 29.79) (:trade UTX 0.325694 :last 101.15) (:trade INTC 0.327348 :last 23.81) (:trade IBM 0.336878 :last 76.60) (:trade MSFT 0.342414 :last 25.37) (:trade MSFT 0.345710 :last 25.37) (:trade HD 0.346983 :last 36.82) (:trade BA 0.347295 :last 59.80) (:trade MCD 0.360765 :last 29.80) (:trade HPQ 0.364067 :last 21.03) (:trade MSFT 0.364067 :last 25.37) (:trade SBC 0.367409 :last 23.79) (:trade MSFT 0.392928 :last 25.36) (:trade AIG 0.407453 :last 53.55) (:trade HPQ 0.407533 :last 21.03) (:trade SBC 0.407533 :last 23.79) (:trade MSFT 0.407533 :last 25.36) (:trade INTC 0.407533 :last 23.82) (:trade HPQ 0.407533 :last 21.03) (:trade HD 0.407545 :last 36.84) (:trade BA 0.413185 :last 59.80) (:trade INTC 0.414117 :last 23.81) (:trade PFE 0.420796 :last 27.51) (:trade DIS 0.424120 :last 26.30) (:trade AIG 0.424654 :last 53.58) (:trade INTC 0.427471 :last 23.81) (:trade XOM 0.429865 :last 56.85) (:trade IBM 0.431927 :last 76.65) (:trade HPQ 0.432407 :last 21.04) (:trade HD 0.432507 :last 36.84) (:trade MCD 0.439207 :last 29.80) (:trade MSFT 0.442518 :last 25.36) (:trade DIS 0.442518 :last 26.30) (:trade MSFT 0.453747 :last 25.36) (:trade PFE 0.458821 :last 27.52) (:trade IBM 0.459026 :last 76.66) (:trade HON 0.467342 :last 35.36) (:trade XOM 0.469083 :last 56.88) (:trade INTC 0.470871 :last 23.80) (:trade SBC 0.476712 :last 23.79) (:trade BA 0.476730 :last 59.80) (:trade MCD 0.479248 :last 29.80) (:trade HPQ 0.479248 :last 21.03) (:trade AIG 0.480883 :last 53.57) (:trade MSFT 0.482567 :last 25.36) (:trade INTC 0.482567 :last 23.80) (:trade IBM 0.484223 :last 76.73) (:trade MSFT 0.494243 :last 25.36) (:trade AIG 0.497551 :last 53.57) (:trade PFE 0.497569 :last 27.53) (:trade INTC 0.504245 :last 23.80) (:trade HD 0.504660 :last 36.84) (:trade IBM 0.504849 :last 76.73) (:trade GM 0.507621 :last 30.53) (:trade SBC 0.511484 :last 23.79) (:trade HPQ 0.514265 :last 21.04) (:trade HD 0.514798 :last 36.85) (:trade MSFT 0.517601 :last 25.32) (:trade WMT 0.524286 :last 48.46) (:trade IBM 0.524286 :last 76.74) (:trade INTC 0.529220 :last 23.80) (:trade HPQ 0.536813 :last 21.04) (:trade PG 0.537627 :last 54.91) (:trade PFE 0.540979 :last 27.54) (:trade INTC 0.544290 :last 23.80) (:trade PG 0.547549 :last 54.91) (:trade XOM 0.547624 :last 56.85) (:trade HON 0.547687 :last 35.40) (:trade UTX 0.550986 :last 101.33) (:trade HD 0.555694 :last 36.85) (:trade MSFT 0.560792 :last 25.35) (:trade INTC 0.564337 :last 23.80) (:trade XOM 0.566779 :last 56.85) (:trade BA 0.567359 :last 59.81) (:trade HON 0.581023 :last 35.41) (:trade INTC 0.589796 :last 23.80) (:trade BA 0.596050 :last 59.80) (:trade CAT 0.612134 :last 87.83) (:trade WMT 0.618386 :last 48.44) (:trade INTC 0.620474 :last 23.80) (:trade MCD 0.624417 :last 29.80) (:trade MSFT 0.627748 :last 25.35) (:trade BA 0.630881 :last 59.83) (:trade AIG 0.634410 :last 53.56) (:trade MCD 0.637785 :last 29.79) (:trade HON 0.637785 :last 35.40) (:trade INTC 0.649577 :last 23.79) (:trade BA 0.655889 :last 59.85) (:trade HD 0.662287 :last 36.83) (:trade AIG 0.669431 :last 53.53) (:trade HON 0.671133 :last 35.44) (:trade MCD 0.674457 :last 29.79) (:trade MO 0.683443 :last 66.20) (:trade INTC 0.687668 :last 23.79) (:trade MSFT 0.691181 :last 25.35) (:trade PFE 0.694477 :last 27.54) (:trade MSFT 0.720936 :last 25.35) (:trade GM 0.726237 :last 30.50) (:trade WMT 0.730056 :last 48.40) (:trade IBM 0.740544 :last 76.74) (:trade PG 0.744569 :last 54.91) (:trade HON 0.752103 :last 35.46) (:trade CAT 0.753014 :last 87.85) (:trade MO 0.763918 :last 66.20) (:trade MSFT 0.764592 :last 25.35) (:trade HON 0.771289 :last 35.46) (:trade BA 0.772935 :last 59.75) (:trade JPM 0.773229 :last 35.51) (:trade MSFT 0.774612 :last 25.35) (:trade PG 0.776267 :last 54.91) (:trade AIG 0.781168 :last 53.54) (:trade HD 0.782946 :last 36.87) (:trade CAT 0.784614 :last 87.85) (:trade XOM 0.786285 :last 56.88) (:trade MSFT 0.792950 :last 25.36) (:trade UTX 0.794689 :last 101.40) (:trade INTC 0.797969 :last 23.78) (:trade IBM 0.801301 :last 76.74) (:trade HD 0.809652 :last 36.87) (:trade JPM 0.809652 :last 35.51) (:trade MSFT 0.811489 :last 25.37) (:trade MO 0.812994 :last 66.20) (:trade IBM 0.816563 :last 76.75) (:trade MCD 0.828046 :last 29.77) (:trade UTX 0.829055 :last 101.37) (:trade MSFT 0.833420 :last 25.36) (:trade GM 0.837650 :last 30.50) (:trade IBM 0.838004 :last 76.75) (:trade HON 0.838531 :last 35.47) (:trade XOM 0.841372 :last 56.88) (:trade MCD 0.841894 :last 29.78) (:trade KO 0.853202 :last 43.98) (:trade UTX 0.858235 :last 101.38) (:trade INTC 0.864331 :last 23.82) (:trade PFE 0.869104 :last 27.55) (:trade HON 0.873063 :last 35.48) (:trade IBM 0.873095 :last 76.77) (:trade HD 0.873132 :last 36.87) (:trade XOM 0.884796 :last 56.86) (:trade UTX 0.884820 :last 101.38) (:trade HON 0.888886 :last 35.48) (:trade INTC 0.891420 :last 23.81) (:trade CAT 0.895715 :last 87.86) (:trade MO 0.898111 :last 66.19) (:trade XOM 0.898111 :last 56.87) (:trade IBM 0.899775 :last 76.78) (:trade BA 0.899775 :last 59.83) (:trade MSFT 0.901469 :last 25.38) (:trade HD 0.906673 :last 36.86) (:trade HPQ 0.908113 :last 21.03) (:trade CAT 0.916467 :last 87.85) (:trade BA 0.916467 :last 59.83) (:trade MSFT 0.918773 :last 25.38) (:trade PFE 0.926271 :last 27.57) (:trade MO 0.926288 :last 66.18) (:trade WMT 0.929791 :last 48.40) (:trade KO 0.932333 :last 43.98) (:trade JNJ 0.933224 :last 68.15) (:trade PG 0.936516 :last 54.91) (:trade INTC 0.938989 :last 23.81) (:trade IBM 0.942596 :last 76.78) (:trade XOM 0.944052 :last 56.89) (:trade INTC 0.944885 :last 23.81) (:trade BA 0.946486 :last 59.85) (:trade IBM 0.958178 :last 76.78) (:trade INTC 0.959853 :last 23.81) (:trade JPM 0.959897 :last 35.50) (:trade WMT 0.961498 :last 48.40) (:trade MCD 0.963195 :last 29.77) (:trade HPQ 0.966525 :last 21.03) (:trade AIG 0.968663 :last 53.54) (:trade XOM 0.978210 :last 56.89) (:trade AIG 0.979896 :last 53.55) (:trade CAT 0.979896 :last 87.85) (:trade MCD 0.984732 :last 29.77) (:trade PG 0.985307 :last 54.90) (:trade WMT 0.995716 :last 48.41) (:trade MSFT 1.005256 :last 25.38) (:trade PFE 1.005256 :last 27.55) (:trade JPM 1.008448 :last 35.48) (:trade CAT 1.011343 :last 87.86) (:trade XOM 1.011825 :last 56.88) (:trade INTC 1.012667 :last 23.79) (:trade JNJ 1.018655 :last 68.15) (:trade KO 1.021589 :last 43.99) (:trade INTC 1.026597 :last 23.78) (:trade HD 1.029577 :last 36.85) (:trade MSFT 1.029936 :last 25.39) (:trade JPM 1.033267 :last 35.49) (:trade C 1.064996 :last 46.80) (:trade CAT 1.065946 :last 87.85) (:trade MCD 1.066687 :last 29.75) (:trade MRK 1.066687 :last 34.33) (:trade PFE 1.066687 :last 27.55) (:trade INTC 1.066687 :last 23.79) (:trade INTC 1.066687 :last 23.79) (:trade XOM 1.068360 :last 56.88) (:trade JPM 1.068360 :last 35.49) (:trade XOM 1.068360 :last 56.89) (:trade KO 1.068360 :last 43.99) (:trade MRK 1.070274 :last 34.34) (:trade HON 1.073312 :last 35.49) (:trade PFE 1.080025 :last 27.55) (:trade MCD 1.080025 :last 29.75) (:trade INTC 1.080025 :last 23.79) (:trade AIG 1.083337 :last 53.55) (:trade GM 1.083420 :last 30.55) (:trade XOM 1.086739 :last 56.89) (:trade HON 1.093425 :last 35.49) (:trade HPQ 1.093425 :last 21.03) (:trade INTC 1.093425 :last 23.79) (:trade MSFT 1.093425 :last 25.37) (:trade JPM 1.098339 :last 35.49) (:trade IBM 1.099113 :last 76.86) (:trade XOM 1.104257 :last 56.89) (:trade MCD 1.104268 :last 29.74) (:trade GE 1.108379 :last 36.14) (:trade MSFT 1.108408 :last 25.40) (:trade XOM 1.115052 :last 56.89) (:trade JPM 1.118397 :last 35.50) (:trade GM 1.118397 :last 30.55) (:trade C 1.125426 :last 46.78) (:trade MCD 1.132390 :last 29.74) (:trade WMT 1.133494 :last 48.40) (:trade MRK 1.135099 :last 34.33) (:trade MSFT 1.135099 :last 25.39) (:trade INTC 1.135099 :last 23.78) (:trade INTC 1.146096 :last 23.79) (:trade KO 1.146108 :last 43.99) (:trade WMT 1.155346 :last 48.41) (:trade PG 1.158447 :last 54.90) (:trade WMT 1.162645 :last 48.41) (:trade HON 1.162660 :last 35.52) (:trade KO 1.162672 :last 43.98) (:trade JNJ 1.166783 :last 68.20) (:trade DIS 1.166815 :last 26.34) (:trade HD 1.166856 :last 36.90) (:trade MCD 1.171129 :last 29.74) (:trade INTC 1.175130 :last 23.79) (:trade JPM 1.178485 :last 35.50) (:trade KO 1.178485 :last 43.98) (:trade MSFT 1.184447 :last 25.39) (:trade AIG 1.191811 :last 53.56) (:trade WMT 1.195138 :last 48.41) (:trade MSFT 1.199050 :last 25.39) (:trade MO 1.201440 :last 66.18) (:trade INTC 1.201841 :last 23.80) (:trade DIS 1.201841 :last 26.34) (:trade JNJ 1.202292 :last 68.20) (:trade C 1.205172 :last 46.79) (:trade KO 1.205172 :last 43.98) (:trade WMT 1.209557 :last 48.40) (:trade INTC 1.209927 :last 23.79) (:trade VZ 1.209962 :last 34.75) (:trade MSFT 1.213558 :last 25.37) (:trade C 1.220169 :last 46.79) (:trade DIS 1.220225 :last 26.34) (:trade PFE 1.220225 :last 27.55) (:trade JNJ 1.220921 :last 68.20) (:trade MMM 1.223614 :last 76.70) (:trade INTC 1.226875 :last 23.79) (:trade DIS 1.230230 :last 26.34) (:trade HPQ 1.230230 :last 21.03) (:trade HON 1.230230 :last 35.52) (:trade PFE 1.230230 :last 27.56) (:trade SBC 1.230230 :last 23.78) (:trade C 1.236915 :last 46.79) (:trade MSFT 1.240577 :last 25.40) (:trade DIS 1.243960 :last 26.34) (:trade SBC 1.250258 :last 23.78) (:trade MCD 1.250258 :last 29.74) (:trade MSFT 1.250258 :last 25.40) (:trade INTC 1.253588 :last 23.79) (:trade HON 1.253588 :last 35.53) (:trade MCD 1.257704 :last 29.74) (:trade MSFT 1.262803 :last 25.37) (:trade KO 1.271926 :last 43.99) (:trade JPM 1.271926 :last 35.51) (:trade VZ 1.276339 :last 34.75) (:trade MSFT 1.280283 :last 25.40) (:trade HPQ 1.280283 :last 21.03) (:trade DIS 1.288624 :last 26.34) (:trade GE 1.288664 :last 36.14) (:trade JPM 1.288664 :last 35.51) (:trade AIG 1.290300 :last 53.59) (:trade CAT 1.290300 :last 87.86) (:trade IBM 1.290300 :last 76.85) (:trade SBC 1.291940 :last 23.77) (:trade XOM 1.301948 :last 56.88) (:trade DIS 1.303625 :last 26.34) (:trade AIG 1.304047 :last 53.60) (:trade KO 1.305316 :last 43.99) (:trade JPM 1.305316 :last 35.51) (:trade C 1.305316 :last 46.79) (:trade KO 1.314761 :last 43.99) (:trade DIS 1.316972 :last 26.35) (:trade HON 1.316972 :last 35.54) (:trade CAT 1.317022 :last 87.86) (:trade IBM 1.317022 :last 76.85) (:trade GE 1.318640 :last 36.15) (:trade WMT 1.320354 :last 48.41) (:trade HPQ 1.322354 :last 21.04) (:trade AIG 1.331152 :last 53.59) (:close) |# (defun msg-start (m) (search "TRADEDATA" m)) From ktilton at nyc.rr.com Thu May 19 21:17:45 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 19 May 2005 17:17:45 -0400 Subject: [cells-devel] Synapses and Cells Unified Message-ID: <428D0279.30700@nyc.rr.com> Whoa, that was easy. Synapses are now just like any other rule-based cell. This was achieved by giving all such cells some new expressiveness: the rule for a cell is now understood to return two values. the second can be :propagate, :no-propagate, or nil, with these semantics: - nil Use EQL or slot unchanged test if specified to test if new and old values are different. (Old behavior.) - :propagate Tell all users to recalculate regardless of the new value. - :no-propagate Do not propagate, regardless of the new value. Not exactly sure how normal ruled cells will benefit from the new capability, but I suspect they will. (I also expect the nature of this new capability to get a lot of refinement as it gets put to use, so forward requests/complaints freely.) kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 May 20 22:14:21 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 20 May 2005 18:14:21 -0400 Subject: [cells-devel] Ooops: with-c-cache Message-ID: <428E613D.9030800@nyc.rr.com> Ooops. I yanked this new macro out of the use case just before posting everything to CVS, forgetting some of you old Cells hands would likely not update from CVS before trying the use case. Here is with-c-cache, not found in cells/constructirs.lisp (defmacro with-c-cache ((fn) &body body) (let ((new (gensym))) `(or (bwhen (,new (progn , at body)) (funcall ,fn ,new .cache)) .cache))) kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 Mon May 23 23:16:00 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 May 2005 19:16:00 -0400 Subject: [cells-devel] Synapse note Message-ID: <42926430.1070402@nyc.rr.com> I forgot to mention something about the new Synapse technology: you can now have a synapse on an arbitrary sub-form within a rule. Silly example: :circumference (c? (* 2 (f-sensitivity :l+w (:delta 10) (+ (^length) (^width)))) Not sure if it matters, but I get a big kick out of that for some reason. kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 frank_goenninger at t-online.de Mon May 23 23:47:10 2005 From: frank_goenninger at t-online.de (Frank Goenninger DG1SBG) Date: Tue, 24 May 2005 01:47:10 +0200 Subject: [cells-devel] Meta-level oof relations ... How? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To all: This is the beginning of a discussion about what I called meta-level usage of the Cells approach and mechanism actually using Kenny's Cells package. You better start at the bottom to get this straight then go up again and read downwards Here we go: Am 24.05.2005 um 00:30 schrieb Kenny Tilton: > Frank Goenninger - PRION Consulting wrote: > >> Kenny, >> >> while designing my app here I am stuck with the following problem: >> >> Using Cells I want to build an object management kernel (to be >> used within my Product Information Management Application). This >> kernel has to implement a basic set of operations to manage >> objects (instances of any kind of class) such as Create, Read, >> Update (using Check-in / Check-Out into / from Vaults) and such. >> >> While Cells is perfect for modeling dependencies between instances >> of objects (using synapses) I am now about to implement relations >> and dependencies between classes. > > uh-oh, maybe Thomas is right and "synapses" is as confusing as it > is clever. And synapses are now just Cells, to make things even > worse. :) But I still talk about synapses as a class. Cells model > dataflow from one slot of an instance to another slot of the same > or different instance. That is, a c-ruled (or is it c-dependent?) > can access any combination of other c-ruled or c-input cells. A > synapse arises where one wants either to (a) mediate that > dependency, say with an f-sensitivity synapse; (b) translate the > dataflow, as with a delta synapse; or (c) do either with an > arbitrary subform within a cell rule (something I might have > pointed out with the new Synapse mechanism, and will shortly in a > standalone post). I think it is worth here to distinguish between two separate domains where the terms CLASS, INSTANCE, RELATION, DEPENDENCY each have different meanings and side effects. In the Application domain (my app being based on Cells) has Classes that get defined while adapting the app to a user's needs. A typical class would be "BOM" (said bill of material). The other one to be use in the use case outlined below is class "PART". So we have: + Application Class BOM + Application Class PART + Class Relation IS-USED-IN: PART -> BOM (read: a PART can be related to a BOM with the relation IS-USED-IN). This is a relation defined on CLASS (!) level. + Instance "As Built BOM, Baseline 001" of application class BOM + Instance "High Pressure Turbine, Serial Nr 0001" of class PART In order to make the use case more verbose we define some attributes on the classes: + Attribute PRICE on class BOM + Attribute NR-PARTS on class BOM + Attribute PRICE on class PART The relation is a "general" one: if any attribute of an instance of class PART changes then recalculate all attributes of the corresponding instance of class BOM. Several things have to be noted here: Adding a part to a Bom is done by the following steps (not using Cells but the - say - traditional approach): 0. BOM instance is already there 1. Create an instance of class PART 2. Create an instance of relation IS-USED-IN 3. Set the LHS (left hand side) of the relation to the object id of the new part 4. Set the RHS of the relation to the object id of the BOM instance Now, the update mechanism in this traditional approach always crawls all relation instances using the id of the changed object to find all other objects being related to that instance id and sends an update event to all these instances. This should be avoided by limiting the nr of events being fired. Not every related object has to be updated when a part is added. The same is true when the Price attribute of a part is changed: the BOM need not recalculate the nr of parts in it. The intended use case is: Define a relation class that says: update attribute PRICE on instances of class BOM if the attribute PRICE of instances of class PART changes - respecting the fact that a particular instance of class PART is always related to particular instances of class BOM (so update only those affected). A part can be related to more than one BOM. A BOM can have more than one part (well, a simple n:m relation). So, I want to define a class-level dependency between classes BOM and PART by defining the slots PRICE in BOM and NR-PARTS, PRICE in PART as cells. Using whatever mechanism out of the Cells package I defined the relation between these Cell slots. As there will be millions of instances of PART and (a few less) instances of BOMs I want to have to define the dependency just once while still being able to overwrite the firing rules and the dependency rules between any two instances of classes BOM and PART. The reminder of the email exchange is now discussion the various aspects of this and also what Cells really are ;-) >> The use case for this will be: I create a dependency between >> class BOM (bill of material) and Part (individual components). >> Once having create that class synapse-connection every instance >> created of the classes BOM and Part "knows" of the dependency ... > > A couple of things here. > > (1) I myself have lately stepped up my understanding of Cells, viz, > that a lot of the power comes from being instance-oriented, as in > different instances of the same class can have different rules for > the same slot. Note that def-c-output compromises this by being > class-oriented, so now I have a solid reason for my long-held vague > discomfort with def-c-outputs which are not really outputs but > instead feed back into the model by setf-ing c-input cells. So this > talk of relations between classes has me thinking "you better have > a good reason". > > (2) I forget the second thing. > >> and after being related to specific instance (say, a Part "High >> Pressure Turbine, Serial Nr 0001" is related to an instance "As >> Built BOM , Baseline 001" of class BOM) then, when the Part "High >> Pressure Turbine, Serial Nr 0001" gets changed.. > > You lost me. Do you mean it gets changed in the sense that some > other part is now being used, or in the sense that some attribute > of the part (say, the price of the turbine) changes? Both: If a new part is added or a part is deleted from the BOM or the price attribute is changed. >> the synapse between the two classes triggers the /right/ instance >> of class BOM, here the instance "As Built BOM , Baseline 001". > > "Triggers"? Do you mean, the total on the BOM would have to be > changed to reflect the changed turbine price? Yes. > Anyway, it does not sound as if the two classes require dataflow, > it sounds as if each instance of each class will require that > dataflow with some other instance. Agreed. > As much as I talk about instance-oriented programming, hey, if you > author a cell in a rule supplied in an initform or default-initarg, > guess what? You get class-oriented behavior. :) Just do not > override those rules at make-instance time. :) Aha! #### It all started with my email: Kenny, while designing my app here I am stuck with the following problem: Using Cells I want to build an object management kernel (to be used within my Product Information Management Application). This kernel has to implement a basic set of operations to manage objects (instances of any kind of class) such as Create, Read, Update (using Check-in / Check-Out into / from Vaults) and such. While Cells is perfect for modeling dependencies between instances of objects (using synapses) I am now about to implement relations and dependencies between classes. The use case for this will be: I create a dependency between class BOM (bill of material) and Part (individual components). Once having create that class synapse-connection every instance created of the classes BOM and Part "knows" of the dependency and after being related to specific instance (say, a Part "High Pressure Turbine, Serial Nr 0001" is related to an instance "As Built BOM , Baseline 001" of class BOM) then, when the Part "High Pressure Turbine, Serial Nr 0001" gets changed the synapse between the two classes triggers the /right/ instance of class BOM, here the instance "As Built BOM , Baseline 001". Hmmm - you, as the expert here, would you: 1) Create a new class of synapses 2) Create a new class of cells 3) Implement a new dependency mechanism 4) Do something else (and for every case I dare to ask: Why ?) ;-) - --- EOM (End Of Mail) --- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iEYEARECAAYFAkKSa34ACgkQfYXhf9DGKdZlQQCfSOuHaMxVtJbtOGv/Jk7efALw XXkAnimcQTvB4hq32b3XvXCOcyscVV94 =eoZc -----END PGP SIGNATURE----- From ktilton at nyc.rr.com Tue May 24 05:03:39 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 May 2005 01:03:39 -0400 Subject: [cells-devel] Meta-level oof relations ... How? In-Reply-To: References: Message-ID: <4292B5AB.5090901@nyc.rr.com> > I think it is worth here to distinguish between two separate domains > where the terms CLASS, INSTANCE, RELATION, DEPENDENCY each have > different meanings and side effects. > > In the Application domain (my app being based on Cells) has Classes > that get defined while adapting the app to a user's needs. A typical > class would be "BOM" (said bill of material). The other one to be use > in the use case outlined below is class "PART". > > So we have: > > + Application Class BOM > + Application Class PART > + Class Relation IS-USED-IN: PART -> BOM (read: a PART can be related > to a BOM with the relation IS-USED-IN). This is a relation defined on > CLASS (!) level. > > + Instance "As Built BOM, Baseline 001" of application class BOM > + Instance "High Pressure Turbine, Serial Nr 0001" of class PART > > In order to make the use case more verbose we define some attributes > on the classes: > > + Attribute PRICE on class BOM > + Attribute NR-PARTS on class BOM > > + Attribute PRICE on class PART > > The relation is a "general" one: if any attribute of an instance of > class PART changes then recalculate all attributes of the > corresponding instance of class BOM. > > Several things have to be noted here: > > Adding a part to a Bom is done by the following steps (not using > Cells but the - say - traditional approach): > > 0. BOM instance is already there > 1. Create an instance of class PART > 2. Create an instance of relation IS-USED-IN > 3. Set the LHS (left hand side) of the relation to the object id of > the new part > 4. Set the RHS of the relation to the object id of the BOM instance > > Now, the update mechanism in this traditional approach always crawls > all relation instances using the id of the changed object to find all > other objects being related to that instance id and sends an update > event to all these instances. > > This should be avoided by limiting the nr of events being fired. Not > every related object has to be updated when a part is added. The same > is true when the Price attribute of a part is changed: the BOM need > not recalculate the nr of parts in it. > > The intended use case is: > > Define a relation class that says: update attribute PRICE on > instances of class BOM if the attribute PRICE of instances of class > PART changes - respecting the fact that a particular instance of > class PART is always related to particular instances of class BOM (so > update only those affected). > > A part can be related to more than one BOM. A BOM can have more than > one part (well, a simple n:m relation). > > So, I want to define a class-level dependency between classes BOM and > PART by defining the slots PRICE in BOM and NR-PARTS, PRICE in PART > as cells. As I said, just use an :initform or :default-initarg: (defclass BOM (priceable) () (:default-initargs :price (c? (apply '+ (mapcar 'price (^parts)))))) BTW, if this gets into a long-enough list (a) at 64 you will hit a silly Cells limitation which i will look at eliminating shortly but (b) i think we are into new territory which I first noticed on the Dow-Jones Index use case, viz, one slot quite reasonably depending on a kazillion other slots. DJI got solved by ducking the problem -- it turned out each ticker was being depended on twice (for two different values) and a carefully placed without-c-dependency got the dependency count under 64 without sacrificing true dependency (the others were semantically redundant) -- but obviously this bad boy of an issue has to be dealt with. How long are the parts lists? Even after I relax the 64-link limitation I observed a performance hit from cells internals searching down that long list (gets hit a lot, relatively speaking). I am thinking a clever divide-conquer scheme will be necessary, in which cells internals generate trees of synapses with a maximum of 16 or whatever dependencies at each node. We will see. > > > Using whatever mechanism out of the Cells package I defined the > relation between these Cell slots. As there will be millions of > instances of PART and (a few less) instances of BOMs I want to have > to define the dependency just once while still being able to > overwrite the firing rules and the dependency rules between any two > instances of classes BOM and PART. A Cell data structure has, inter alia, slots for used cells and cells which use it. These must be instance specific, since in the end we really do have a normal case of instances depending on other instances. The slots for the rule will all contain the same rule instance (unless it closes over a lexical variable). So you could save one slot in each Cell -- if defstruct supported class-allocated slots, but I do not think they do. (You would think I would know for sure, but Lisp still surprises me from time to time.) Are all these parts loaded into RAM at once? With that kind of demand on memory i do not think Cells will stand out as a burden, though i could be wrong. Have you tried the normal approach and found a problem? I am not completely against early optimization and do it often, but this would be a case where I would let the normal approach fail before working on optimization. Conceivably we can carve out a lighter-weight Cell, but I am not sure we can save more than a few slots. I think structures are implemented as arrays, so we are just making smaller arrays. I am concerned that that will not help much if a bottleneck is discovered. I would then lean towards your idea of a single Cell capable of managing the dependencies of all class instances. That would save almost all the slots at the cost of adding a hashtable lookup on an instance before getting to its list of used or user cells, and of course save all those make-cell calls themselves. Hey, if you can set up some dummy classes and bog it down, I will see what I can do about creating class-allocated cells which can still be overridden if necessary. >> >> You lost me. Do you mean it gets changed in the sense that some >> other part is now being used, or in the sense that some attribute of >> the part (say, the price of the turbine) changes? > > > Both: > > If a new part is added or a part is deleted from the BOM or the price > attribute is changed. You just need slots Part-BOMs and BOM-Parts. Any rule such as: (defclass BOM () () (:default-initargs :price (c? (apply '+ (mapcar 'price (^parts)))))) Will establish dependencies on (a) the parts slot and (b) the price of each part. Note by the way that this means you cannot use destructive operations to change a parts list, unless you get sneaky and create a destructive function which guarantees the first cons cell is different, perhaps by re-consing the first element back on (assuming it is not being deleted). > > >>> the synapse between the two classes triggers the /right/ instance >>> of class BOM, here the instance "As Built BOM , Baseline 001". >> >> >> "Triggers"? Do you mean, the total on the BOM would have to be >> changed to reflect the changed turbine price? > > > Yes. > >> Anyway, it does not sound as if the two classes require dataflow, it >> sounds as if each instance of each class will require that dataflow >> with some other instance. > > > Agreed. > >> As much as I talk about instance-oriented programming, hey, if you >> author a cell in a rule supplied in an initform or default-initarg, >> guess what? You get class-oriented behavior. :) Just do not override >> those rules at make-instance time. :) > > > Aha! Well, let's see if you hit a problem with that approach and then look at optimizations. Might be a fun task. In a sense, the class-allocated Cell is precisely analogous (he said after several seconds of careful analysis) to the RDBMS scheme of setting up an intermediate many-many relation, with the extra feature of automating dataflow from parts to BOM. kt From ktilton at nyc.rr.com Tue May 24 14:56:58 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 May 2005 10:56:58 -0400 Subject: [cells-devel] Meta-level oof relations ... How? In-Reply-To: <4292B5AB.5090901@nyc.rr.com> References: <4292B5AB.5090901@nyc.rr.com> Message-ID: <429340BA.5010300@nyc.rr.com> Kenny Tilton wrote: >> If a new part is added or a part is deleted from the BOM or the >> price attribute is changed. > > > You just need slots Part-BOMs and BOM-Parts. Any rule such as: > > (defclass BOM () > () > (:default-initargs :price (c? (apply '+ (mapcar 'price (^parts)))))) > > Will establish dependencies on (a) the parts slot and (b) the price of > each part. Nah, that will not work. We could have a parts slot on the BOM class mediated by c-input, but then how does each part get its BOMs slot updated? In the past I would kludge up an output method (via def-c-output) on the parts slot of BOM to maintain the BOMs slot of Part, but with Cells II we have a Prime Directive which says -- well, it gets complicated, but logically those two updates are one, and output methods do not run until propagation is complete, so the model is inconsistent during propagation of any change to the parts list of a BOM -- any rule that fires will see a BOMs value on any new part which does not show the BOM to which the part has been added. We can go the RDBMS route and create or destroy instances of Relations, or we can do what AllegroStore does with its persistent CLOS database: define a so-called inverse function on a slot, via a new defmodel slot option. It would work like this: (defclass BOM () ((parts :cell t :inverse-cell part-BOMs :initform (c-in nil) :initarg :parts :accessor parts))) (defclass part ()()) After which: (let ((p (make-be 'part)) (BOM (make-be 'bom :parts (c-in (list p))))) (part-BOMs p)) => A list containing the BOM instance ...and part-BOMS is a cell like any other cell, accept that there is no BOMs slot on part. Now Cells II's new propagation scheme naturally takes care of consistency, since it arranges for just-in-time consistency during propagation. AllegroStore went one more step and supported a "unique" option for the case where a one-to-many relationship is to be modeled. We could then apply this to the Family class, where kids have only one fm-parent. What do we achieve by this? For one, the inverse Cell fm-parent will now return just one parent instance instead of a list of one. For another, an error can be generated if a kid gets pushed onto the kids slot of more than one instance at the same time. This is interesting. Although I have gotten by nicely with the one Family class for a long time, I have started to notice occasions where the special handling given the kids slot might be useful more generally. I have even considered a new cell slot option which would let any slot work like the kids slot. We are talking about a different issue now, but it is interesting that they point back to the same kind of relational slot. Thoughts? kt From tfb at OCF.Berkeley.EDU Tue May 24 15:46:13 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 24 May 2005 08:46:13 -0700 Subject: [cells-devel] Logic Programming in Cells Message-ID: <17043.19525.48820.752685@conquest.OCF.Berkeley.EDU> I was looking to build a Prolog-ish logic-programming layer on top of Cells, and looking at how to do this, it looks like basic support could be added to Cells itself pretty easily. Here's what I'm thinking. We add a new type of Cell, let's call it a Generator. Data propogation proceeds as usual, but when we get to a Generator, we mark this on a stack. If evaluation of some formula calls FAIL, we go back to the last Generator, evaluate it again, and resume data propogation from there. Any pending inputs from code that was backtracked over would of course be thrown out. Any thoughts? It's a holiday here on thursday, so I'm thinking about hacking on this then. From frank_goenninger at t-online.de Tue May 24 17:12:15 2005 From: frank_goenninger at t-online.de (Frank Goenninger DG1SBG) Date: Tue, 24 May 2005 19:12:15 +0200 Subject: [cells-devel] Logic Programming in Cells In-Reply-To: <17043.19525.48820.752685@conquest.OCF.Berkeley.EDU> References: <17043.19525.48820.752685@conquest.OCF.Berkeley.EDU> Message-ID: <15BC1EF9-8F19-4AA6-B375-6E4403B87EF2@t-online.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas, Am 24.05.2005 um 17:46 schrieb Thomas F. Burdick: > I was looking to build a Prolog-ish logic-programming layer on top of > Cells, and looking at how to do this, it looks like basic support > could be added to Cells itself pretty easily. Here's what I'm > thinking. We add a new type of Cell, let's call it a Generator. Data > propogation proceeds as usual, but when we get to a Generator, we mark > this on a stack. If evaluation of some formula calls FAIL, we go back > to the last Generator, evaluate it again, and resume data propogation > from there. Any pending inputs from code that was backtracked over > would of course be thrown out. Fits nicely with what I want to do also. I need to implement a Neural Net and this would be a real good start I think. Need to do analyzing CAD data and do automatic classification of the contents. ... Go ahead! ;-) > > Any thoughts? It's a holiday here on thursday, so I'm thinking about > hacking on this then. Some of the nicer aspects of living in Germany - a load of public holidays. With best wishes from Stuttgart Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iEYEARECAAYFAkKTYHAACgkQfYXhf9DGKdazpwCgrt2LPpY8sSDqsj52ZL1wggDg 6t8AnAq0F8ZNyogXIc+0Rgn8i+eb6lVR =2Nb8 -----END PGP SIGNATURE----- From ktilton at nyc.rr.com Tue May 24 17:22:09 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 May 2005 13:22:09 -0400 Subject: [Fwd: Re: [cells-devel] Logic Programming in Cells] Message-ID: <429362C1.5040609@nyc.rr.com> -------- Original Message -------- Subject: Re: [cells-devel] Logic Programming in Cells Date: Tue, 24 May 2005 12:37:50 -0400 From: Kenny Tilton To: Thomas F. Burdick References: <17043.19525.48820.752685 at conquest.OCF.Berkeley.EDU> Thomas F. Burdick wrote: >I was looking to build a Prolog-ish logic-programming layer on top of >Cells, and looking at how to do this, it looks like basic support >could be added to Cells itself pretty easily. Here's what I'm >thinking. We add a new type of Cell, let's call it a Generator. Data >propogation proceeds as usual, but when we get to a Generator, we mark >this on a stack. If evaluation of some formula calls FAIL, we go back >to the last Generator, evaluate it again, and resume data propogation >from there. Any pending inputs from code that was backtracked over >would of course be thrown out. > >Any thoughts? > So the generator sits there trying different values, with nested generators each working thru their values? The generator needs to be able to keep track of where it is between evaluations, including knowing when it is starting a fresh search (if you will). Are you up to speed on the new propagation scheme, as featured most prominently in "unfinished-business"? I guess teh good news is that propagation to dependent cells completes before any output is done, so you do not have to back out outputs (and rules are not supposed to have side effects, tho I did just that in the Dwo Jones use case .). But what about the dependency propagation itself? A retry by the Generator may not propagate to the same population, so some positive mechanism must un-calculate dependencies reached during any failed propagation. Too bad I am not using the stack any more....Just had an idea. I need to look at the logic again, but what if we let dependency propagation take place on the stack. One nice thing here is that I was just about to /fake/ a stack just for debugging purposes, so I could figure out where problematic data pulses were originating. So either we do not need to do that, or that supports the backtracking you will need. Again, have you been thinking about these issues? Either way, am I in the right ballpark approach-wise? kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 May 24 17:48:42 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 24 May 2005 10:48:42 -0700 Subject: [Fwd: Re: [cells-devel] Logic Programming in Cells] In-Reply-To: <429362C1.5040609@nyc.rr.com> References: <429362C1.5040609@nyc.rr.com> Message-ID: <17043.26874.729702.799046@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > So the generator sits there trying different values, with nested > generators each working thru their values? The generator needs to be > able to keep track of where it is between evaluations, including knowing > when it is starting a fresh search (if you will). Yep. I'm envisioning a generator doing things like producing permutations or counting or working its way through a database cursor. Knuth will be useful here. I'm thinking a generator has an internal state which is initialized by a rule, but can be set by the generator's formula. In the case where the generator is reevaluated because something under it FAILed, the state is not reinitialized. > Are you up to speed on the new propagation scheme, as featured most > prominently in "unfinished-business"? I guess teh good news is that > propagation to dependent cells completes before any output is done, so > you do not have to back out outputs (and rules are not supposed to have > side effects, tho I did just that in the Dwo Jones use case .). Yeah, the new propagation scheme is really the reason I thought of doing this in Cells itself; it should make it easier to handle at the Cells level. > But what about the dependency propagation itself? A retry by the > Generator may not propagate to the same population, so some positive > mechanism must un-calculate dependencies reached during any failed > propagation. Yeah, I'm hoping this isn't too hard. > Too bad I am not using the stack any more....Just had an > idea. I need to look at the logic again, but what if we let dependency > propagation take place on the stack. One nice thing here is that I was > just about to /fake/ a stack just for debugging purposes, so I could > figure out where problematic data pulses were originating. So either we > do not need to do that, or that supports the backtracking you will need. > > Again, have you been thinking about these issues? Either way, am I in > the right ballpark approach-wise? You're pretty much right-on. I was going to look hard at the propagation code to figure out whether to use the control stack, or hand-manage a stack of my own. If it uses tail-calls in the case where there are no backtracking points and *debug* is nil, it should be possible to avoid excessive stack use in the normal case, at least for high-quality CLs. From ktilton at nyc.rr.com Tue May 24 18:08:24 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 May 2005 14:08:24 -0400 Subject: [Fwd: Re: [cells-devel] Logic Programming in Cells] In-Reply-To: <17043.26874.729702.799046@conquest.OCF.Berkeley.EDU> References: <429362C1.5040609@nyc.rr.com> <17043.26874.729702.799046@conquest.OCF.Berkeley.EDU> Message-ID: <42936D98.6060809@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > So the generator sits there trying different values, with nested > > generators each working thru their values? The generator needs to be > > able to keep track of where it is between evaluations, including knowing > > when it is starting a fresh search (if you will). > >Yep. I'm envisioning a generator doing things like producing >permutations or counting or working its way through a database cursor. >Knuth will be useful here. I'm thinking a generator has an internal >state which is initialized by a rule, but can be set by the >generator's formula. In the case where the generator is reevaluated >because something under it FAILed, the state is not reinitialized. > > > Are you up to speed on the new propagation scheme, as featured most > > prominently in "unfinished-business"? I guess teh good news is that > > propagation to dependent cells completes before any output is done, so > > you do not have to back out outputs (and rules are not supposed to have > > side effects, tho I did just that in the Dwo Jones use case .). > >Yeah, the new propagation scheme is really the reason I thought of >doing this in Cells itself; it should make it easier to handle at the >Cells level. > BTW, have you considered simply leaving Cells out of the logical computation? Just have a classic proplog-in-lisp work things out and produce an aggregation of values from which Cells simply look up the value decided for them? OTOH, I can see how, if you are using Cells, you would just as soon go on using them and then add a little logic, rather than end up with some of the system specified in Cells and some of it specified in some alternative scheme -- especially since the rules in the alternative scheme would tend to have dependencies on Cells. I am talking myself into your approach, but I just wanted to make sure there is not a better way than Cells. kt ps. I have to head out for some R&R, but will look at propagating on the stack instead of via the ufb-queue when I get back. k From frank_goenninger at t-online.de Tue May 24 18:23:45 2005 From: frank_goenninger at t-online.de (Frank Goenninger DG1SBG) Date: Tue, 24 May 2005 20:23:45 +0200 Subject: [cells-devel] Hooks on Cells accesses? Message-ID: <93941B5A-5902-4F52-9E63-1FE61CB18A38@t-online.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Cells Users: Maybe you have come across this also ... While working on the other challenges I have been telling on this list I am also trying to set-up an authorization model for Cells. I need to check permissions to Create, Update, Read, and Delete a cell slot. I thought about having hooks on each of these operations such that on every such operation within Cells an "outside function" can be called. These just return t or nil depending on permission check success or failure. As the model outside can be quite different from case to case (app to app) I did not think about implementing this within Cells. So (cells:add-hook 'cells:slot-read slot-reference 'my-permission-check- function) would install that hook. Or should I keep this on class level instead of on slot level because of possible impacts on propagation speed and other inner Cells aspects? I'd prefer to get the fine-grained control here and no, I'm not trying to get into the premature optimization game but want to get some basic thoughts straight. Again: Any feedback very welcome! Cheers, Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iEYEARECAAYFAkKTcTEACgkQfYXhf9DGKdbaowCfXXtDJ61h9xQUMjkzarsh84f+ hl4AoLNk1dS2C56Slb6VRuYZdL0mvYuV =iwCb -----END PGP SIGNATURE----- From tfb at OCF.Berkeley.EDU Tue May 24 22:13:46 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 24 May 2005 15:13:46 -0700 Subject: [Fwd: Re: [cells-devel] Logic Programming in Cells] In-Reply-To: <42936D98.6060809@nyc.rr.com> References: <429362C1.5040609@nyc.rr.com> <17043.26874.729702.799046@conquest.OCF.Berkeley.EDU> <42936D98.6060809@nyc.rr.com> Message-ID: <17043.42778.939067.522565@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > BTW, have you considered simply leaving Cells out of the logical > computation? Just have a classic proplog-in-lisp work things out and > produce an aggregation of values from which Cells simply look up the > value decided for them? Well, I started with the idea of using Cells and Allegro Prolog. I tried a couple fake-ups but it felt awkward. Part of it is that you really need to interleave the two systems, because you don't want to generate lists of possibilities when you only need One That Works. So I was going to write a higher-level constraints system that would internally use Cells for data propagation, and Allegro Prolog for the LP part of constraints-solving. But ... > OTOH, I can see how, if you are using Cells, you > would just as soon go on using them and then add a little logic, rather > than end up with some of the system specified in Cells and some of it > specified in some alternative scheme -- especially since the rules in > the alternative scheme would tend to have dependencies on Cells. ... exactly, what I want to be able to have is a variable that magically takes on the right, constrained value. Having cells that depend on Prolog, whose predicates depend on cells ... this was looking ugly. My bet is that by adding Generators and backtracking, a lot of the Prolog work can be done in Lisp, and it will make interfacing between Lisp and Prolog nicer for those times when Prolog is a better solution. > I am talking myself into your approach, but I just wanted to make > sure there is not a better way than Cells. Actually, this could be seen as trying to build up what I need for a CL+Cells<->Prolog FFI :-) From ktilton at nyc.rr.com Wed May 25 03:36:58 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 May 2005 23:36:58 -0400 Subject: [cells-devel] Cello migration underway Message-ID: <4293F2DA.60303@nyc.rr.com> Anyone interested in Cello should know that I am slowly moving code from subdirectories under the cell-cultures module of Cells to their own modules under the Cello project. The module status is earned by being something which, if successful, could rightly be its own c-l.net project. I do not want to take that ambitious step since I am leaning towards hosting all future development on my own site (does not exist yet). So far I have moved hello-c and cl-opengl to the Cello project. kt From ktilton at nyc.rr.com Wed May 25 17:06:57 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 May 2005 13:06:57 -0400 Subject: [cells-devel] Hooks on Cells accesses? In-Reply-To: <93941B5A-5902-4F52-9E63-1FE61CB18A38@t-online.de> References: <93941B5A-5902-4F52-9E63-1FE61CB18A38@t-online.de> Message-ID: <4294B0B1.8080700@nyc.rr.com> Frank Goenninger DG1SBG wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear Cells Users: > > Maybe you have come across this also ... > > While working on the other challenges I have been telling on this > list I am also trying to set-up an authorization model for Cells. > > I need to check permissions to Create, Update, Read, and Delete a > cell slot. I thought about having hooks on each of these operations > such that on every such operation within Cells an "outside function" > can be called. These just return t or nil depending on permission > check success or failure. As the model outside can be quite different > from case to case (app to app) I did not think about implementing > this within Cells. > > So > > (cells:add-hook 'cells:slot-read slot-reference 'my-permission-check- > function) > > would install that hook. I went ahead and made md-slot-value and its setter into generic functions. Not the end of the world performance-wise from brief analysis with ACLs profiler. More study necessary, but my guess is you really want more than this (such as making the hook specific to a slot, as per your add-hook semantics) and it would impact everyone, so I will await further input before exploring this further. Possibly you want a new defmodel slot option? kt From tfb at OCF.Berkeley.EDU Wed May 25 17:15:01 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 25 May 2005 10:15:01 -0700 Subject: [cells-devel] Hooks on Cells accesses? In-Reply-To: <4294B0B1.8080700@nyc.rr.com> References: <93941B5A-5902-4F52-9E63-1FE61CB18A38@t-online.de> <4294B0B1.8080700@nyc.rr.com> Message-ID: <17044.45717.158820.898241@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > I went ahead and made md-slot-value and its setter into generic > functions. Not the end of the world performance-wise from brief analysis > with ACLs profiler. (Yikes!) If I'm not mistaken, speed of generic-function dispatch is something where Allegro is head-and-shoulders above the competition. I guess I'll try profiling SBCL before I freak out, but I'd guess this could have nasty performance penalties there. From tfb at OCF.Berkeley.EDU Wed May 25 17:21:10 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 25 May 2005 10:21:10 -0700 Subject: [cells-devel] Hooks on Cells accesses? In-Reply-To: <93941B5A-5902-4F52-9E63-1FE61CB18A38@t-online.de> References: <93941B5A-5902-4F52-9E63-1FE61CB18A38@t-online.de> Message-ID: <17044.46086.452691.461171@conquest.OCF.Berkeley.EDU> Frank Goenninger DG1SBG writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear Cells Users: > > Maybe you have come across this also ... > > While working on the other challenges I have been telling on this > list I am also trying to set-up an authorization model for Cells. > > I need to check permissions to Create, Update, Read, and Delete a > cell slot. I thought about having hooks on each of these operations > such that on every such operation within Cells an "outside function" > can be called. These just return t or nil depending on permission > check success or failure. As the model outside can be quite different > from case to case (app to app) I did not think about implementing > this within Cells. I'm really not seeing what you're wanting to do here. Why does the authorization take place at the cell-access level? In the past, I've had slots that held authentication and authorization policy objects. For formulas that need authorization, you just stick an (assert (^authorized)) in the appropriate places. From ktilton at nyc.rr.com Wed May 25 17:22:30 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 May 2005 13:22:30 -0400 Subject: [Fwd: Re: [cells-devel] Logic Programming in Cells] In-Reply-To: <17043.26874.729702.799046@conquest.OCF.Berkeley.EDU> References: <429362C1.5040609@nyc.rr.com> <17043.26874.729702.799046@conquest.OCF.Berkeley.EDU> Message-ID: <4294B456.2050905@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > So the generator sits there trying different values, with nested > > generators each working thru their values? The generator needs to be > > able to keep track of where it is between evaluations, including knowing > > when it is starting a fresh search (if you will). > >Yep. I'm envisioning a generator doing things like producing >permutations or counting or working its way through a database cursor. >Knuth will be useful here. I'm thinking a generator has an internal >state which is initialized by a rule, but can be set by the >generator's formula. In the case where the generator is reevaluated >because something under it FAILed, the state is not reinitialized. > > > Are you up to speed on the new propagation scheme, as featured most > > prominently in "unfinished-business"? I guess teh good news is that > > propagation to dependent cells completes before any output is done, so > > you do not have to back out outputs (and rules are not supposed to have > > side effects, tho I did just that in the Dwo Jones use case .). > >Yeah, the new propagation scheme is really the reason I thought of >doing this in Cells itself; it should make it easier to handle at the >Cells level. > > > But what about the dependency propagation itself? A retry by the > > Generator may not propagate to the same population, so some positive > > mechanism must un-calculate dependencies reached during any failed > > propagation. > >Yeah, I'm hoping this isn't too hard. > > > Too bad I am not using the stack any more....Just had an > > idea. I need to look at the logic again, but what if we let dependency > > propagation take place on the stack. One nice thing here is that I was > > just about to /fake/ a stack just for debugging purposes, so I could > > figure out where problematic data pulses were originating. So either we > > do not need to do that, or that supports the backtracking you will need. > > > > Again, have you been thinking about these issues? Either way, am I in > > the right ballpark approach-wise? > >You're pretty much right-on. I was going to look hard at the >propagation code to figure out whether to use the control stack, or >hand-manage a stack of my own. If it uses tail-calls in the case >where there are no backtracking points and *debug* is nil, it should >be possible to avoid excessive stack use in the normal case, at least >for high-quality CLs. > > > > I went ahead and implemented recursive propagation to users. No faster, btw, so I guess the queueing scheme... well, hang on, it was not a real-world test. The bigger problem is that half-way thru I remembered that I kind of like the idea of setting a model in motion and then just having it run without further input because one change always leads to another. We'd have to have a hook somewhere to stop and check the event queue so the poor user can get in on the fun. I cannot say for sure I will ever do that, but it Sounds Right. So I will look instead at maintaining a simulated propagation stack just to help debugging (a known need) with an eye towards someday possibly implementing "rule calculation backout". Am I right that the condition system would be too slow for logic programming? You mentioned the rule would "call FAIL". What would FAIL do? Is this another role for the second value rules might return: :propagate, :no-propagate, nil, or :fail? kt -- Cells? Cello?: http://www.common-lisp.net/project/cells/ Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/ 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 Thu May 26 01:27:54 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 May 2005 21:27:54 -0400 Subject: [cells-devel] *causation* Message-ID: <4295261A.8070802@nyc.rr.com> It's back. *causation* is now bound to a "stack" of propagating cells, where the last element of the list is the original cause. Of course, to achieve proper backout this really needs to become more history than stack, because propagation sweeps a tree of dependencies, and the FAIL even can arise in a second branch of propagation, at which point a stack will have lost track of the first branch of propagation. Over to you, Prolog fans. kenny From ktilton at nyc.rr.com Thu May 26 04:20:02 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 26 May 2005 00:20:02 -0400 Subject: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog Message-ID: <42954E72.7040300@nyc.rr.com> If your Prolog-in-CL uses slot readers/accessors, dependencies will arise. So the position (or whatever GUI layout attribute you have in mind) can be calculated by a cl-prolog operating over CLOS instances via CLOS slot accessor GFs, and the necessary dataflow will arise naturally. The invocation of the cl-prolog computation will have to require dynamic insertion of initializing/configuring facts. The cell rule calculating the result will specify these facts from other cell values, and supply the calculating form. This then neatly embeds Prolog within Cells, with the Prolog both driving and driven by Cells. Yet one gets (I presume) the greater performance from a dedicated prolog working on a fixed set of facts (for the duration of a single calculation). Not very sure of the above, btw. kenny -- Cells? : http://www.common-lisp.net/project/cells/ Cello? : http://www.common-lisp.net/project/cello/ Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/ 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 marcoxa at cs.nyu.edu Thu May 26 15:16:15 2005 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Thu, 26 May 2005 11:16:15 -0400 Subject: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog In-Reply-To: <42954E72.7040300@nyc.rr.com> References: <42954E72.7040300@nyc.rr.com> Message-ID: <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> As an aside, any Prolog implementation needs a good unification routine. Now, you also want a good unification routine that does CL objects properly. So you cannot help but using the CL-UNIFICATION package from http://common-lisp.net/project/cl-unification I know it is a shameless plug, but you simply cannot avoid it :) Cheers -- Marco On May 26, 2005, at 12:20 AM, Kenny Tilton wrote: > If your Prolog-in-CL uses slot readers/accessors, dependencies will > arise. So the position (or whatever GUI layout attribute you have in > mind) can be calculated by a cl-prolog operating over CLOS instances > via CLOS slot accessor GFs, and the necessary dataflow will arise > naturally. > > The invocation of the cl-prolog computation will have to require > dynamic insertion of initializing/configuring facts. The cell rule > calculating the result will specify these facts from other cell > values, and supply the calculating form. This then neatly embeds > Prolog within Cells, with the Prolog both driving and driven by Cells. > Yet one gets (I presume) the greater performance from a dedicated > prolog working on a fixed set of facts (for the duration of a single > calculation). > > Not very sure of the above, btw. > > kenny > > -- > Cells? : http://www.common-lisp.net/project/cells/ > Cello? : http://www.common-lisp.net/project/cello/ > Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/ > 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 > > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel > -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. From tfb at OCF.Berkeley.EDU Thu May 26 18:43:47 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Thu, 26 May 2005 11:43:47 -0700 Subject: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog In-Reply-To: <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> References: <42954E72.7040300@nyc.rr.com> <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> Message-ID: <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> Marco Antoniotti writes: > As an aside, any Prolog implementation needs a good unification routine. > > Now, you also want a good unification routine that does CL objects > properly. > > So you cannot help but using the CL-UNIFICATION package from > http://common-lisp.net/project/cl-unification > > I know it is a shameless plug, but you simply cannot avoid it :) Shameless but well timed, I hadn't realized that your cl-unification goes through slot accessors. Very nice. Just to dispell any illusions, I'm not trying to turn Cells into a Prolog interpreter. I kind of want a Real Constraints system, but know the problems associated with that, so I'm just playing with trying to mix a little LP into Cells to see if I can get something where my code is a little clearer than what I could get otherwise. The other motivation is that, in the past, I've had situations where I got data out of a database, and fed it line-by-line into a c-input until I got a consistent model, like: (do-results (x y z) (db (generate-query a b c)) (setf (values (x obj) (y obj) (z obj)) (values x y z)) (when (model-is-good obj) (return obj))) I'd prefer to be able to integrate this into the model, so I could have something more like: (defmodel my-model () ((a :initform (c-input () ...) :accessor a) (b :initform (c-input () ...) :accessor b) (c :initform (c-input () ...) :accessor c) (xyz :initform (c-generator ((it (db-query-iterator *db* (generate-query (^a) (^b) (^c))))) (if (more-tuples-p it) (next it) (fail))) :accessor xyz) ... x y and z here depend on xyz, and if something is inconsistent in the model, their formulas call fail instead of causing (^model-is-good) to be nil ... )) > On May 26, 2005, at 12:20 AM, Kenny Tilton wrote: > > > If your Prolog-in-CL uses slot readers/accessors, dependencies will > > arise. So the position (or whatever GUI layout attribute you have in > > mind) can be calculated by a cl-prolog operating over CLOS instances > > via CLOS slot accessor GFs, and the necessary dataflow will arise > > naturally. Yeah, it could be that some Allegro Prolog enhancements would handle all of this as well. But in the cases where I just want a *little* Logic, making Cells handle it might not be a bad idea. Certainly what I have is entertaining. Now to look at your recent changes, and to actually restore the old dependencies on backtracking. From tfb at OCF.Berkeley.EDU Thu May 26 18:52:21 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Thu, 26 May 2005 11:52:21 -0700 Subject: [Fwd: Re: [cells-devel] Logic Programming in Cells] In-Reply-To: <4294B456.2050905@nyc.rr.com> References: <429362C1.5040609@nyc.rr.com> <17043.26874.729702.799046@conquest.OCF.Berkeley.EDU> <4294B456.2050905@nyc.rr.com> Message-ID: <17046.6885.637596.949103@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > The bigger problem is that half-way thru I remembered that I kind of > like the idea of setting a model in motion and then just having it run > without further input because one change always leads to another. We'd > have to have a hook somewhere to stop and check the event queue so the > poor user can get in on the fun. > > I cannot say for sure I will ever do that, but it Sounds Right. So I > will look instead at maintaining a simulated propagation stack just to > help debugging (a known need) with an eye towards someday possibly > implementing "rule calculation backout". Am I right that the condition > system would be too slow for logic programming? You mentioned the rule > would "call FAIL". What would FAIL do? FAIL would do some sort of nonlocal exit :-) Uhm, I'm not sure. Currently, the FAIL I have signals a NO-VALID-STATE condition, the code that runs the generators establishes a BACKTRACK restart, and wrapped around the very outside is a handler for NO-VALID-STATE that invokes the BACKTRACK restart if it can find it. I did this with the idea that Cells is probably not up to being a full-featured LP engine, so it's probably better to err on the side of letting the user hook in. In the no-stack situation, FAIL could cause a RETURN-FROM back into the propagation machinery, which would certainly be faster. Whether that would make enough of a difference to enable a backtracking Cells to be used for more general LP stuff, I don't know. Only one way to find out, I guess. From marcoxa at cs.nyu.edu Thu May 26 18:53:53 2005 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Thu, 26 May 2005 14:53:53 -0400 Subject: CL-UNIFICATION Re: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog In-Reply-To: <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> References: <42954E72.7040300@nyc.rr.com> <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> Message-ID: <5f750409359f0e43a6951d7b49f5472a@cs.nyu.edu> On May 26, 2005, at 2:43 PM, Thomas F. Burdick wrote: > Marco Antoniotti writes: >> As an aside, any Prolog implementation needs a good unification >> routine. >> >> Now, you also want a good unification routine that does CL objects >> properly. >> >> So you cannot help but using the CL-UNIFICATION package from >> http://common-lisp.net/project/cl-unification >> >> I know it is a shameless plug, but you simply cannot avoid it :) > > Shameless but well timed, I hadn't realized that your cl-unification > goes through slot accessors. Very nice. Yep. That was the whole point of the exercise. In the next version you will be able to do something like (unify #T(protocol t count-elements ?c get-minimum ?m) #S(tree )) or (unify #T(protocol enum:enumerations current ?x next 42) #) where TREE can be manipulated by the functions COUNT-ELEMENTS and GET-MINUMUM and ENUMERATION, NEXT and CURRENT are part of the (shameless plug) CL-ENUMERATION library for common-lisp.net. Cheers -- Marco Antoniotti http://bioinformatics.nyu.edu NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. From ktilton at nyc.rr.com Thu May 26 19:49:27 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 26 May 2005 15:49:27 -0400 Subject: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog In-Reply-To: <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> References: <42954E72.7040300@nyc.rr.com> <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> Message-ID: <42962847.7070200@nyc.rr.com> Thomas F. Burdick wrote: >Now to look at your recent changes, and to actually restore the old >dependencies on backtracking. > Ouch, hadn't thought of that one. And the pulse-stamp, and.... have fun. :) kt From tfb at OCF.Berkeley.EDU Mon May 30 20:47:21 2005 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 30 May 2005 13:47:21 -0700 Subject: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog In-Reply-To: <42962847.7070200@nyc.rr.com> References: <42954E72.7040300@nyc.rr.com> <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> <42962847.7070200@nyc.rr.com> Message-ID: <17051.31705.135323.94149@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > > > Thomas F. Burdick wrote: > > >Now to look at your recent changes, and to actually restore the old > >dependencies on backtracking. > > > Ouch, hadn't thought of that one. And the pulse-stamp, and.... have fun. :) And the pulse-stamp. Ay. So, for the moment, I've made a new system: KNOB (KNowledgeable OBjects). In the world of KR, Cells, Cosi, etc, it's a one-trick pony that does targeted backtracking. If it turns out to be a good idea, I'll try to incorporate KNOB-style backtracking (whatever that turns out to be) into Cells. In the meantime, it's a lot easier to make changes to a 300-line, non-industrial-quality object system :-) Actually, I think I've found an interesting design space. At least it's interesting to me, and lets me express some problems nicely yet efficiently that I couldn't with either Cells nor KR nor Prolog. But I'm still working it out, so integrating it into Cells will be left for a time when I have more confidence in my approach. -- /|_ .-----------------------. ,' .\ / | Free Mumia Abu-Jamal! | ,--' _,' | Abolish the racist | / / | death penalty! | ( -. | `-----------------------' | ) | (`-. '--.) `. )----' From ktilton at nyc.rr.com Tue May 31 00:58:58 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 30 May 2005 20:58:58 -0400 Subject: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog In-Reply-To: <17051.31705.135323.94149@conquest.OCF.Berkeley.EDU> References: <42954E72.7040300@nyc.rr.com> <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> <42962847.7070200@nyc.rr.com> <17051.31705.135323.94149@conquest.OCF.Berkeley.EDU> Message-ID: <429BB6D2.3020708@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > > > > Thomas F. Burdick wrote: > > > > >Now to look at your recent changes, and to actually restore the old > > >dependencies on backtracking. > > > > > Ouch, hadn't thought of that one. And the pulse-stamp, and.... have fun. :) > >And the pulse-stamp. Ay. > >So, for the moment, I've made a new system: KNOB (KNowledgeable >OBjects). > Great name, justification enough for the project. :) > In the world of KR, Cells, Cosi, etc, it's a one-trick pony >that does targeted backtracking. If it turns out to be a good idea, >I'll try to incorporate KNOB-style backtracking (whatever that turns >out to be) into Cells. In the meantime, it's a lot easier to make >changes to a 300-line, non-industrial-quality object system :-) > Boy, I can imagine. But tell me you are at least using CLOS! > >Actually, I think I've found an interesting design space. At least >it's interesting to me, and lets me express some problems nicely yet >efficiently that I couldn't with either Cells nor KR nor Prolog. But >I'm still working it out, so integrating it into Cells will be left >for a time when I have more confidence in my approach. > > > Sounds neat. kenny -- Cells? : http://www.common-lisp.net/project/cells/ Cello? : http://www.common-lisp.net/project/cello/ Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/ 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 Tue May 31 01:42:04 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 30 May 2005 21:42:04 -0400 Subject: [cells-devel] Re: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <200505301328.14784.peter.denno@nist.gov> References: <200505301016.19467.peter.denno@nist.gov> <429B414D.8010302@nyc.rr.com> <200505301328.14784.peter.denno@nist.gov> Message-ID: <429BC0EC.1070309@nyc.rr.com> Peter Denno wrote: >>I was over on 6.2 because Cells-Gtk had worked there, >>and under ACL7 I was getting an obscure error loading the GTK dlls. I >>have not touched those since playing with cgtk, so I thought maybe the >>ACL loader was doing something different. Nope, same error on ACL 6.2. >>So as usual with Windows, nothing makes sense and I am slowly installing >>the latest GTK+ 2.6.7 family of libs to see if I can get Gtk working >>itself. >> >>If that succeeds, I will then finish a little libgtkcells VC++ project >>to build a win32 dll for that and see if I can get the new stuff working. >> >> > >I'd be real interested in knowing how that goes. > The error persists.Loading libgobject, libintl_bind_textdomain_codeset not found in intl.dll. libintl.h shows that as a valid exported label. That is under ACL7. I am trying also from Lispworks Trial, but that seems to be unhappy with the logical-pathname usage in load.lisp: ASDF reports it cannot find Cells. Anyone have a clue on the INTL issue? I did a fresh install of GIMP, which brings down all the gtk stuff. And the GIMP app itself runs fine. kenny From rpgoldman at real-time.com Tue May 31 01:41:50 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Mon, 30 May 2005 20:41:50 -0500 Subject: [cells-devel] Thought For Someone Who Would Use Cells to Do Prolog In-Reply-To: <429BB6D2.3020708@nyc.rr.com> References: <42954E72.7040300@nyc.rr.com> <5688677e52cb323fcf3532fe3c38dbc1@cs.nyu.edu> <17046.6371.403171.338753@conquest.OCF.Berkeley.EDU> <42962847.7070200@nyc.rr.com> <17051.31705.135323.94149@conquest.OCF.Berkeley.EDU> <429BB6D2.3020708@nyc.rr.com> Message-ID: <17051.49374.832230.324199@gargle.gargle.HOWL> For what it's worth, you might want to look at Jeffrey Siskind's SCREAMER, which provides nondeterministic programming (with backtracking) for Common Lisp. Of course, this does not include objects, but it would probably be worth a cross-reference. best, r From ktilton at nyc.rr.com Tue May 31 01:59:38 2005 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 30 May 2005 21:59:38 -0400 Subject: [cells-devel] Re: [cells-gtk-devel] New cells-gtk capabilities and new tarball In-Reply-To: <429BC0EC.1070309@nyc.rr.com> References: <200505301016.19467.peter.denno@nist.gov> <429B414D.8010302@nyc.rr.com> <200505301328.14784.peter.denno@nist.gov> <429BC0EC.1070309@nyc.rr.com> Message-ID: <429BC50A.3040300@nyc.rr.com> Kenny Tilton wrote: > > > Peter Denno wrote: > >>> I was over on 6.2 because Cells-Gtk had worked there, and under ACL7 >>> I was getting an obscure error loading the GTK dlls. I >>> have not touched those since playing with cgtk, so I thought maybe the >>> ACL loader was doing something different. Nope, same error on ACL 6.2. >>> So as usual with Windows, nothing makes sense and I am slowly >>> installing >>> the latest GTK+ 2.6.7 family of libs to see if I can get Gtk working >>> itself. >>> >>> If that succeeds, I will then finish a little libgtkcells VC++ project >>> to build a win32 dll for that and see if I can get the new stuff >>> working. >>> >> >> >> I'd be real interested in knowing how that goes. > > The error persists.Loading libgobject, libintl_bind_textdomain_codeset > not found in intl.dll. libintl.h shows that as a valid exported label. > > That is under ACL7. I am trying also from Lispworks Trial, but that > seems to be unhappy with the logical-pathname usage in load.lisp: ASDF > reports it cannot find Cells. Sorry. I inadvertently tried to load the "load.lisp" in \cells-gtk\root. (Is that still needed?) Anyway, good/bad news: same error from Lispworks.