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
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
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.
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
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.
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
"KT" == Kenny Tilton ktilton@nyc.rr.com 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
rpgoldman@real-time.com wrote:
"KT" == Kenny Tilton ktilton@nyc.rr.com 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
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 :-)
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
-
Kenny Tilton -
Peter Denno -
rpgoldman＠real-time.com -
Thomas F. Burdick