new user Lars suggested the Cells library have all its documentation in
error messages. Perfect for those of us who hate reading doc -- if the
user won't go to the FM, the FM will go to the user.
Here is the first bit:
"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"
Boy that mediate has a ring to it. Not sure on the cellular, but it
beats the hell out of cellish. Normlly I just say Cell slot. Yawn.
Comments? Questions?
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
On Wed, 07 Jun 2006 18:35:40 -0400, <·········@gmail.com> wrote:
> new user Lars suggested the Cells library have all its documentation in
> error messages. Perfect for those of us who hate reading doc -- if the
> user won't go to the FM, the FM will go to the user.
>
> "Break: cellular slot STATUS of #<MOTOR> cannot be SETFed because it is
> ...
> Comments?
It doesn't sound good to me. I think in all the thousands of error
messages I've read maybe 20% have been actually useful, most are
shorthand for the developer (including my own). At least 20% have
been misleading or wrong (such as a cacading error fubar).
Most of what I learned of cells came from sweat equity -- reading
code, puttering with it, running it, fixing it, etc. There have been
several short paragraphs recently posted that capture the essence of
Cells, if someone wants more, it's 'sweat time'.
There must be about a dozen different samples of running Cells code by
now, that's about 10 more than the average perl doc off of CPAN.
Aren't lispers smarter than perl geeks?
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> There must be about a dozen different samples of running Cells code by
> now, that's about 10 more than the average perl doc off of CPAN.
> Aren't lispers smarter than perl geeks?
Probably, but Cells is (are?) conceptually different *and* difficult
enough to thwart even lispers, it seems. I've got a project in the
pipeline where I could maybe profit from it, so I'll have a look at it
in the near future - maybe I can get my head around it (and any bugs)
this time.
On 7 Jun 2006 21:44:58 -0700, <········@chello.at> wrote:
> GP lisper wrote:
>> There must be about a dozen different samples of running Cells code by
>> now, that's about 10 more than the average perl doc off of CPAN.
>> Aren't lispers smarter than perl geeks?
>
> Probably, but Cells is (are?) conceptually different *and* difficult
A = B + C
change B and C as fast and as often as you like, A will remain correct
without any additional programmer work.
--
Posted via a free Usenet account from http://www.teranews.com
Christopher Koppler wrote:
> GP lisper wrote:
>
>>There must be about a dozen different samples of running Cells code by
>>now, that's about 10 more than the average perl doc off of CPAN.
>>Aren't lispers smarter than perl geeks?
>
>
> Probably, but Cells is (are?)...
Neither works, right? Last time I name a package in the plural.
>... conceptually different ...
Yep. But familiar, if one has ever seen VisiCalc or anything like it.
Still, it is a /big/ paradigm shift. Pull vs. push, as Mr. Eby put it.
>... *and* difficult
> enough ...
I seriously believe the only difficulty is in accepting that one can
program this way. This may be one of those deals where new programmers
have less trouble than dinosaurs.
>...to thwart even lispers, it seems.
I have never heard of anyone who could not "get it", but they might not
have communicated with me. I know a lot of people gave up because of
hassles installing, no doc, etc. I do the same.
> I've got a project in the
> pipeline where I could maybe profit from it, so I'll have a look at it
> in the near future - maybe I can get my head around it (and any bugs)
> this time.
>
The only bug I recall was a funny one that arose if the :cell slot
option was specified last in a slot spec. (I guess I should have known
REMF was destructive. <g>) Anyway, bug reports always welcome. The test
suite pounds on Cells pretty well and last I heard it passes that.
As for getting up to speed on Cells, a number of people have sent me
their first failed attempts and I was happy to sort those out to get
them rolling.
Finally, this summer's traffic on the PyCells SoC project should have
great educational value for Cell (Cells?) fans everywhere. :)
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Beaming husband to scowling life, New Yorker cartoon
GP lisper wrote:
> Most of what I learned of cells came from sweat equity -- reading
> code, puttering with it, running it, fixing it, etc. There have been
> several short paragraphs recently posted that capture the essence of
> Cells, if someone wants more, it's 'sweat time'.
Hey, good to hear from you. Are you still active with Cells? This could
swell my user count by 10%. :)
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Beaming husband to scowling life, New Yorker cartoon
On Wed, 07 Jun 2006 22:40:51 -0400, <·········@gmail.com> wrote:
>
>
> GP lisper wrote:
>> Most of what I learned of cells came from sweat equity -- reading
>> code, puttering with it, running it, fixing it, etc. There have been
>> several short paragraphs recently posted that capture the essence of
>> Cells, if someone wants more, it's 'sweat time'.
>
> Hey, good to hear from you. Are you still active with Cells? This could
> swell my user count by 10%. :)
The original work was expanded somewhat, but seed money ran out and it
went on the back burner -- where I'm mostly looking at the genetic
programming end (since the cells frontend worked fine).
However, I always keep it in mind, and have discussed Cells somewhat
during Bay Area Lispers dinners. Many people get interested, but the
"it's like a spreadsheet" doesn't seem to light the bulb. I recently
tried a longer explaination at a local meeting. I think a lot of
people get tripped up on "why do I want that?", and without a good
answer for themselves, don't get further.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> I think a lot of
> people get tripped up on "why do I want that?", and without a good
> answer for themselves, don't get further.
>
Have them count the SETFs in their code and compare it with Kenny's.
Everyone managing memory manually knows full well they are doing so and
welcome a change to automatic memory management. Folks managing state
have no idea how much energy they are expending on, or how many of their
bugs boil down to failures in, that effort.
An interesting indicator might be the raves over at Adobe for their
state management tool, Adam. I have belatedly realized that, in order to
utilize Adam, a C++ developer embeds in their apps source from a new
language called Adam. ie, They cannot simply write C++ and have data
integrity Just Happen. Of course Adam is similar to C/C++ so it is not
the absolute end of th... yeah, it is. It is a horrible prospect. Yet
Adobe thinks Adam is a godsend.
I understand what is going on at Adobe. The same will happen with
Python. Without macros, PyCells will show a lot more wiring than Cells,
but that is a linear degradation that will not detract from the
nonlinear win from decomposition of application complexity into so many
simple rules.
In fact, my bet is that for a sufficiently interesting application, a
Pythonista with PyCells will leave a Yobbo without Cells in the dust.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Beaming husband to scowling life, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Folks managing state have no idea how much energy they are expending
> on, or how many of their bugs boil down to failures in, that effort.
The last company I worked with made a product that was a control unit
for some mechanical devices, presenting both sensor readings coming in
from those devices and an interface to program the devices. Consider
it like a very sophisticated microwave oven, perhaps with a
temperature probe.
The UI code was a frighteningly complex rat's nest. Input data
arriving from the sensors changed certain state values, which caused
the display to update, but the system state also changed, and rules
had to be evaluated, the outcome of which might be tuning to the
running job or warning messages presented to the user, and in the
meantime the user may be adjusting the running job. I'm sure there are
even more interactions I'm leaving out.
There was no "large idea" in this code to organize these dependencies
or orchestrate the data flow. The individual facilities were
well-formed enough: "message" input and output, GUI widgets and forms,
real-world entities modeled as entities in the code. However, the
connections between these things were ad-hoc and not formalized. Every
change to the system would provoke defects, and the failure usually
involved not propagating some event, propagating it at the wrong time,
or propagating it to the wrong recipients.
Before I left the company, we were starting to discuss "next
generation" UI design. I described Cells in the abstract, but the
entire code base was written in C++ -- and in a conservative
mostly-still-C style. Having studied the implementation techniques and
source-level convenience in Cells, I did not think I could create such
a system afresh that could be integrated into the existing code
base. That Adobe created something similar in C++ was intriguing, but
I never got the chance to look into whether we could make use of it.
--
Steven E. Harris
Steven E. Harris wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Folks managing state have no idea how much energy they are expending
>>on, or how many of their bugs boil down to failures in, that effort.
>
>
> The last company I worked with made a product that was a control unit
> for some mechanical devices, presenting both sensor readings coming in
> from those devices and an interface to program the devices. Consider
> it like a very sophisticated microwave oven, perhaps with a
> temperature probe.
>
> The UI code was a frighteningly complex rat's nest. Input data
> arriving from the sensors changed certain state values, which caused
> the display to update, but the system state also changed, and rules
> had to be evaluated, the outcome of which might be tuning to the
> running job or warning messages presented to the user, and in the
> meantime the user may be adjusting the running job. I'm sure there are
> even more interactions I'm leaving out.
>
> There was no "large idea" in this code to organize these dependencies
> or orchestrate the data flow. The individual facilities were
> well-formed enough: "message" input and output, GUI widgets and forms,
> real-world entities modeled as entities in the code. However, the
> connections between these things were ad-hoc and not formalized.
Greenspunning a forma constraints mechanism. Indeed, one good reason for
not bothering with Cells is that Lisp does make it easy to solve these
problems on the fly without noticing that maybe one should have a formal
mechanism.
> Every
> change to the system would provoke defects, and the failure usually
> involved not propagating some event, propagating it at the wrong time,
> or propagating it to the wrong recipients.
Can I add the above to the "motivation" section of my doc?
>
> Before I left the company, we were starting to discuss "next
> generation" UI design. I described Cells in the abstract, but the
> entire code base was written in C++ -- and in a conservative
> mostly-still-C style. Having studied the implementation techniques and
> source-level convenience in Cells, I did not think I could create such
> a system afresh that could be integrated into the existing code
> base. That Adobe created something similar in C++ was intriguing, but
> I never got the chance to look into whether we could make use of it.
>
You know, once upon a time I started on ports of Cells to C++ as well as
Java. Lord knows where that code is now, and I was just doing rough
proof-of-concept stuff, spending only a day or two on each. Anyway, I
wonder why Adobe created an embedded language? I think I saw that it was
dynamic. Maybe that was it. Perhaps Adam greenspuns things like
anonymous functions and closures. I recall using anonymous classes in Java.
Maybe this is the ultimate language comparison test. Forget how long it
takes to write, since one cannot control for programmer skill. Take an
intense library like Cells and port it to language X. See how much can
be replicated, and what can be added that CL cannout handle. See what
the resulting code looks like. Then apply to a sufficiently interesting
application, executed in each language. See what the application code
looks like.
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Beaming husband to scowling life, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Indeed, one good reason for not bothering with Cells is that Lisp
> does make it easy to solve these problems on the fly without
> noticing that maybe one should have a formal mechanism.
I have been studying some CAPI examples lately in anticipation of
using it for our next project. First, the wonder of passing closures
as callbacks seems amazing, boosting confidence to keep building, but
it doesn't take long to recognize that after a few menus and controls
the connections start to get brittle.
> Can I add the above to the "motivation" section of my doc?
Yes. I was careful not to get too specific about the device's purpose,
as there aren't many companies in that market.
> I wonder why Adobe created an embedded language?
Before I comment on why, let me say that I was fascinated with their
solution until I discovered that they had used this embedded
language. It seemed like they cheated. Now, there may be no way to
solve the problem without "cheating" like this, but it did make me
loose interest, seeing both the length of the reach and how far still
it was from what Cells could accomplish in CL.
As for needing to create an embedded language, it's not too hard to
see what one must deal with using only the bare language. The whole
act of simply reading an observed (member) variable needs to be
formalized. The observing reader has to deliberately make itself
manifest itself in the call stack, faking up something like the
*calculators* stack (sorry if I'm misremembering the name or if the
mechanism has changed) in Cells, whether by "registering" itself
before the call or passing itself as an argument to the call. The
reader has to know that the variable to be read participates in some
kind of protocol. Hence, we're out of the realm of normal variables in
the language, and into building up some kind of "property access"
system, with its own syntax -- or at least its own set of functions --
to access values within it.
It's hard to write the observing code without knowing exactly which
variables are observable. That is, without designing for some kind of
default property accessor that can fetch values from non-Cell
variables, the observer's code would have to change if its rule
depended on some variables that changed from being Cells to non-Cells,
or vice versa.
> I think I saw that it was dynamic. Maybe that was it.
Adding one point to my previous story, one aspect of Cells that we
didn't really need was the /dynamic/ discovery and maintenance of
dependencies. The relationships were never supposed to change during
the life of our program. It would have been fine to "discover" them
once and freeze them, even if that meant having some kind of
declarative means to express them at compile time. Thinking through
that, we're back in the land of having an embedded language, or at
least one that would have to drive a code generator.
> Take an intense library like Cells and port it to language X. See
> how much can be replicated, and what can be added that CL cannot
> handle.
Predicting this experience is mostly what stopped me. I could see that
I would need a lot of macros (which are commonly frowned upon in C++),
strange and verbose function calls, and perhaps code generation. Yet
Cells in CL requires very little distinct syntax. It's the macro
system at work, coupled with extensibility of CLOS's slot access
mechanism. As I said above, we'd have to build our own "slot
access"/"property" system in C++, and only then figure out how to use
it without a prohibitive amount of syntactic pain.
> See what the application code looks like.
This would be the true test. Producing the observable behavior with
ugly and bulky code isn't enough. Cells shows that one can get a lot
of magic with only a few strange mutterings. Once the burden of the
incantation becomes noticeable, the desire for the outcome withers.
--
Steven E. Harris
On Wed, 07 Jun 2006 18:35:40 -0400, Ken Tilton <·········@gmail.com> wrote:
> new user Lars suggested the Cells library have all its
> documentation in error messages. Perfect for those of us who
> hate reading doc -- if the user won't go to the FM, the FM will
> go to the user.
>
> Here is the first bit:
>
> "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"
>
> Boy that mediate has a ring to it. Not sure on the cellular,
> but it beats the hell out of cellish. Normlly I just say Cell
> slot. Yawn.
>
> Comments? Questions?
Having verbose and descriptive error messages, especially if they
contain useful suggestions to fix the error (like the one shown
above), is a *VERY* good thing. Some times these verbose
messages tend to become a huge deal of 'noise' though. Would it
be nice to make their appearance tunable? For example, the
errors could be written in a style that facilitates both 'short'
and 'long' versions, i.e.:
"Non-SETFable cellular slot STATUS of #<MOTOR>. Use C-IN or C-INPUT.
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"
Then, one could switch between printing just the first line of
the error message vs. all of it at will:
(defparameter *cells-verbose-errors* t)
Does this sound reasonable?
Regards,
Giorgos
Giorgos Keramidas wrote:
> On Wed, 07 Jun 2006 18:35:40 -0400, Ken Tilton <·········@gmail.com> wrote:
>
>>new user Lars suggested the Cells library have all its
>>documentation in error messages. Perfect for those of us who
>>hate reading doc -- if the user won't go to the FM, the FM will
>>go to the user.
>>
>>Here is the first bit:
>>
>>"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"
>>
>>Boy that mediate has a ring to it. Not sure on the cellular,
>>but it beats the hell out of cellish. Normlly I just say Cell
>>slot. Yawn.
>>
>>Comments? Questions?
>
>
> Having verbose and descriptive error messages, especially if they
> contain useful suggestions to fix the error (like the one shown
> above), is a *VERY* good thing. Some times these verbose
> messages tend to become a huge deal of 'noise' though.
I do not see how this could be too much noise. When this error happens
it happens only once and then we have to restart; there is no way to
continue from it reliably (assuming the error was not in initializing
the slot with an input Cell). So it is not like you would see dozens (or
even two) at once.
cheers, kenzo
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
On Wed, 07 Jun 2006 19:57:33 -0400, Ken Tilton <·········@gmail.com> wrote:
> Giorgos Keramidas wrote:
>> Having verbose and descriptive error messages, especially if they
>> contain useful suggestions to fix the error (like the one shown
>> above), is a *VERY* good thing. Some times these verbose
>> messages tend to become a huge deal of 'noise' though.
>
> I do not see how this could be too much noise. When this error happens
> it happens only once and then we have to restart; there is no way to
> continue from it reliably (assuming the error was not in initializing
> the slot with an input Cell). So it is not like you would see dozens
> (or even two) at once.
I see. Thanks for the clarification. I'm all for verbosity and helpful
hints in the error messages then :)