cells-devel

cells-devel@common-lisp.net

567 discussions

[cells-devel] Re: question about cells
by Ken Tilton 07 Jun '06

07 Jun '06

> > Hmm, maybe the error does not need to announce where it is in the source? > OK, I just committed code to produce this (we can continue refining if necessary, but I like this so wanted to get it in): Break: cellular slot STATUS of #<MOTOR> cannot be SETFed because it is not mediated by a Cell with :inputp t. To achieve this, the initial value :ON -- whether supplied as an :initform, :default-initarg, or at make-instance time via an :initarg -- should be wrapped in either macro C-IN or C-INPUT. In brief, initialize STATUS to (c-in :ON) instead of plain :ON Code: (unless c (c-break "cellular slot ~a of ~a cannot be SETFed because it is not mediated by a Cell with :inputp t. To achieve this, the initial value ~s -- whether supplied as an :initform, :default-initarg, or at make-instance time via an :initarg -- should be wrapped in either macro C-IN or C-INPUT. In brief, initialize ~0@*~a to (c-in ~2@*~s) instead of plain ~:*~s" slot-name self (slot-value self slot-name))) ken

1 0

[cells-devel] Re: question about cells
by Ken Tilton 07 Jun '06

07 Jun '06

On 6/7/06, Lars Rune Nøstdal <larsnostdal(a)gmail.com> wrote: > > i keep getting this: > > (setf md-slot-value)> cellular slot value of #<InputText {B079EC9}> > cannot be setf unless initialized as inputp > > if i've understood this message correctly; it means that i'm trying to > setf a slot with `:initform (c? ...)' .. No, that should give you a different error saying you cannot SETF a /ruled/ slot, but I just checked to get the text of that error (and tested for it) and am rather astounded to see that that discipline is no longer enforced. I will have to investigate. :) The error you are getting means the slot has been initialized to some plain Lisp value such as NIL or "Hello world", without any Cell wrapper as one would get with c-in or c-input or any of the macros to generate ruled Cells. Which means.... but the slot i'm having > trouble with resides in a superclass of `InputText' and is defined > like this: > > .. > (value :accessor value-of :initarg :value > :initform (c-in "")) This initform (which is fine) has been overridden at make-instance time with something like: :value "Test" hth, kenny

1 0

[cells-devel] Tiny patch
by Lars Rune Nøstdal 02 Jun '06

02 Jun '06

Hello, Just a tiny "patch"; the NIL (in uppercase) caused some troubles in `cells.lisp' for me when *readtable* is set to :invert. -(defparameter *client-queue-handler* NIL) +(defparameter *client-queue-handler* nil) -- Mvh, Lars Rune Nøstdal http://lars.nostdal.org/

1 0

[cells-devel] Fwd: Just can't hear enough about Cells?
by Ken Tilton 01 Jun '06

01 Jun '06

---------- Forwarded message ---------- From: Anon <bsd1628(a)comcast.net> Date: Jun 1, 2006 4:03 PM Subject: Re: Just can't hear enough about Cells? To: Ken Tilton <kentilton(a)gmail.com> I'm getting a ton of garbage when trying to ASDF-INSTALL :cells What's going on? here follows: * (asdf-install:install :cells) Install where? 1) System-wide install: System in /usr/lib/sbcl/site-systems/ Files in /usr/lib/sbcl/site/ 2) Personal installation: System in /home/oper/.sbcl/systems/ Files in /home/oper/.sbcl/site/ --> 2 Downloading 74072 bytes from http://common-lisp.net/project/cells/asdf- install/cells_2.0.tar.gz ... debugger invoked on a ASDF-INSTALL::KEY-NOT-TRUSTED in thread #<THREAD "initial thread" {A687621}>: GPG warns that the key id 0xNIL () is not fully trusted Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE ] Install the package anyway 1: [SKIP-GPG-CHECK] Don't check GPG signature for this package 2: [ABORT ] Exit debugger, returning to top level. (ASDF-INSTALL::VERIFY-GPG-SIGNATURE/STRING "-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MÒwBcells_2.0.tarä\\[sÛF²Î«õ+¦èÚ];9Ê¦BKtÄ]YrIr×fë\"\"`0dû_~ ñ¯^~öêßû)UæØ²XÌi¡ÿìOdù¿ªùb7Õú_¾ÇþÁþþW/÷»pðå×¯^jþ¿üú+L ¹Oóþåtüü?çÿáá¡ ¸ZÆJàIÀHÓ¬XÊ\\\\Þ«B(r)Ä±\\Äi\\ÄY*Þ óYÝ QÄÅý(r)»_ÿ÷Öâ Å¬¼¹\\gy¡\"LçbÑRt.E$âN&Q¶#±Nd¨¤X q\"Á|EIÁâ;ú¥vÕb7Å·Øïuà%Å\"ÎU!eH¿¤Â4Kã(LÊÊ<Â,ç³ÐÖ¹T2-{=ýè4LÅÑ¥,¿aq:ZÅz´· ÝbsX×°Ø(r)ã`§{·±¼£çø¾ÇóÍÙûÖcº÷Y)²YÆ(c)ccàeë{±È³ÈúJ!%5hºü¸y,ÓH2\"ÏÊY \"E(c)âôZÄÅPàPàÄh âÒUx/îÂÈ¨MdQÈ\\ gÙ¡XeØ7(\"ne(r)èy0Çó,*W <SNIP> ã¤Â¥é ¡Ìãÿx6¿LöË=ªìSöD -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFD1qcfl2RwVlDQtPYRApX/AKCFgsrLXsv8FllEQ1YQtC2nYRZiHACcDkJY whE3bSaRgquYThmepNzfYVc= =Pacw -----END PGP SIGNATURE----- " #P"/home/oper/projects/db-project/order-entry/CELLS.asdf-install-tmp") 0] PuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuT TYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYP uTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTYPuTTY

2 1

[cells-devel] Re: Just can't hear enough about Cells?
by Ken Tilton 01 Jun '06

01 Jun '06

On 6/1/06, Anon <bsd1628(a)comcast.net> wrote: > > > I'm getting a ton of garbage when trying > to ASDF-INSTALL :cells > What's going on? Sorry, I do not know anything about asdf-install. I forwarded your note separately to the cell-devel list. If you know of any asdf support list, I suggest you try that. Here is where you can just get the tarball: http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/?root=cells kt

1 0

[cells-devel] Celtk: Text widget API woes
by Frank Goenninger 31 May '06

31 May '06

Hi all: Just a heads up on the behaviour of the text widget: Currently setting the contents of the text widget is done by setting the model value of the widget's model. This causes two steps to be triggered as Tcl commands: 1. Erase text widget to empty display 2. Set new text and display this text Now, if one is reading file contents to be display to the widget by using consequtive calls to read-line and setting each line as the new text widget content only the last line will be displayed, of course. And if this happens to be an empty line then just nothing will appear on the text widget. In case you want to dig in deeper on that subject, well, we're here... Frank

2 5

[cells-devel] New "tutorial/RT code in Cells source tree
by Ken Tilton 30 May '06

30 May '06

I have just uploaded a first rough set of example code which is intended to exercise Cells with a progression of challenges, in the order I might follow when developing a port of Cells to another language, or when validating cells after an enormous upheaval. I call it the tutorial directory, but it could also be a porting guide and a more concise regression test than the random mish-mosh in cells-test. I do plan to put future energy into this code as a regrression test suite, so... watch for a name change? :) kt

1 0

[cells-devel] to propagate or not to propagate...
by Ken Tilton 30 May '06

30 May '06

Turns out the one filter I looked at was already answering either :propagate or :no-propagate, so on the fly I pronounced that a new standard, tweaked the code to respect either in re propagation and otherwise do the usual test of before/after value change. So is this an API change or bug fix? :) ken

1 0

[cells-devel] Filters, anyone?
by Ken Tilton 29 May '06

29 May '06

Wow, just tripped over my own code in support of filters, aka synapses. I think I have to make a change. I manage to eliminate Synapses as distinct objects by /always/ interpreting the second of possibly multiple returned values as a "propagate?" indicator. I thought this would be OK since a slot can hold only one value. But! (c? (floor (^length) 2)) ...ends up feeding the "propagate?" interpretation, so it turned we all have been getting unnecessary propagation where we innocently returned multiple values and the second was non-nil. My proposed solution is to make the kludge even worse. :) A cell acting in the role of a synapse/filter will have to return 'cells::propagate-yes, 'cell::propagate-no, or (I think there was a third value). Only those will be meaningful. Anything else gets thrown away. Thoughts? Alternatives? kt

1 0

[cells-devel] Re: [PyCells] Possibly-useful prior art
by Ken Tilton 27 May '06

27 May '06

Phillip, Nice write-up. Random notes: What I discovered is quite cool. The Cells system *automatically discovers* dynamic dependencies, without having to explicitly specify that X depends on Y, as long as X and Y are both implemented using cell objects. <g> And that is part of why Cells is pretty much all-or-nothing for a developer: I have not tried to figure out the threshhold, but above what I think is a very low one, all application semantics must be expressed declaratively as Cell rules. Otherwise imperative code gets left out of the action as the automatic dataflow engine does its thing. The corollary being your "as long as" qualifier: my declarative rules are crippled if some important datapoint is not a Cell. For the first seven years of Cells development, when in doubt I started out a new slot/attribute as a non-Cell, bending over backwards if you will not to force the mechanism where it should not go. The default :cell meta-attribute was nil until just recently. But in each case, soon enough it turned out I would need them to be Cells. Just recently "true" became the default for :cell. Specifically, the cells system understands how to make event-based updates orderly and deterministic, in a way that peak.events cannot. It may be of interest that this orderliness is relatively new to Cells. For the longest time and in the most intense applications I got away with murder. Strangely, it was development of a RoboCup client that forced Cells to "grow up". One especially interesting bit is that the Cells system can "optimize away" dependencies or subscriptions when their subjects are known to be constant values. I was quite surprised at how much faster this made Cells run. I'm also wondering if a Cells-like system couldn't also be used to implement STM (Software Transactional Memory) to allow for atomic operations even in the presence of threads. All reads and writes are controlled by the cells system, so it can in principle abort and retry a "transaction", by waiting until *something changes* that would affect the transaction's ability to succeed. We have a Google SoC project over on the Lisp side to implement STM, and yes, I am excited about that making Cells viable in a multi-threaded situation. Mind you, I had never heard of STM before this proposal landed on our doorstep, nor do even have much idea of what is available to applications when it comes to dealing with threads, but looking at how Cells manages data integrity I know it will need help to survive threads. STM looks like a great fix. However, seeing how the Cells paradigm works, it seems to me that it should be pretty easy to establish the convention that side-effects should be confined to non-rule "observer" code. Right, it is just a convention, but I think one that gets easier to follow because the engine provides a simple way to say "do this when the time is right". experience w/e.g. peak.binding attributes shows that it's rare to want to put side-effects into pull-oriented rules. "We could do it, but it would be wrong." Really, the principal downside to Cells is wrapping your head around the idea that *everything* should be treated as pull-oriented rules. Yes, it really is a paradigm shift, one it takes a long time to internalize. What I noticed was that, if I decided to add a significant new mechanism to the system, after about two hours of coding I would be having increasing difficulties and start to get a vague "bad feeling". Then I would realize that I had, from long habit, fallen back into an imperative style. Hence the "bad feeling". Because the code was all new, it did not grow naturally from the Cell-based model. if it had, It would of course been done originally in the declarative style. I have encouraged Ryan, the PyCells author, not to allow backdoors to the Cells engine, precisely because of this. The big win comes from the declarative paradigm, and developers will not climb that learning curve if they can avoid it. SImple human nature. Cells makes one think harder up front in return for all sorts of good things later, and that is a tradeoff I have always liked to make as a developer. There are some operations (such as receiving a command and responding to it) that seem to be more naturally expressed as pushing operations, where you make some decisions and then directly update things or send other commands out. Exactly! A spreadsheet is a steady-state thing (here are the values, here is the computed other state) and using Cells to express static reality is a snap. Otoh, imperative code is all about change, so it is great for handling events. We use ephemeral Cells to model events (they take on a value, propagate, then revert to null silently, without propagating), but one still can end up thinking pretty hard when it comes to events. I think the most frightening "rule" I have written was for a Timer class implemented by the Tcl "after" command. Actually, you can still do that, it's just that those updates or commands force another "virtual moment" of time into being, where if you had made them pull-driven they could've happened in the *same* "virtual moment". So, it's more that pull-based rules are slightly more efficient than push-based ones, which is nice because that means most developers will consider it worth learning how to do it the pull way. ;) That and the straitjacket I hope PyCells keeps from Cells. Anyway, there is a *lot* of interesting food for thought, here. For example, you could create object validation rules using cells, and the results would be automatically recomputed when something they depended on changed. Not only that, but it would be possible to do atomic updates, such that the validation wouldn't occur until *after* all the changes were made -- i.e., no false positives. Of course, you'd get the resulting validation errors in the *next* "time quantum", so you'd need to make the response to them event-driven as well. It's definitely a slippery slope. :) For example, this deterministic model of computation seems to resemble "object prevalence" (e.g. Prevayler) in that everything (even the clock) is deterministic, changes are atomic, and I/O occurs between logical moments of time. I haven't thought this particular link through very much yet, it's just an intriguing similarity. Nice call. I have heard the Cells data integrity model maps nicely onto the transaction model of AllegroCache, a persistent Lisp object database. The head-exploding part is figuring out how to get errors to propagate backwards in time, so that validation rules (which run in the "next moment") could appear to cause an error at the point where the values were set. Sounds like you want at least one Undo. What about a "fail now or forever hold your peace" policy? cheers, kenny

1 0

← Newer
1
...
33
34
35
36
37
38
39
...
57
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel