Cells compared to Flow-Based Programming

Peter Hildebrandt wrote:
>
> Thanks for that story. You made my day :-)

Thanks. I am hoping it will discourage people from askingme for
documentation again.

> I created my own little event handling for the cairo-drawing-area widget
> in cells-gtk, which deals with clicks, selection (single elements and
> multiple elements by drawing a transparent box), and dragging. And I
> can tell you, the code is ugly.

Right, this all started when I mentioned that declarative is fun but not
event-friendly. Ephemerals help a lot, but still some transparency is
lost: we are no longer Just Writing A Formula.

>
> If only I had thought of ephemeral cells. Well, time to think about
> cells-gtk4.
>
> Btw, my current project contains a physics simulator using cells-ode as
> a backend, the gl-drawing-area widget of cells-gtk3 for visualization,
> and a small DSL to specify scenes in terms of s-expressions. I will
> factor out the relevant stuff and merge it will cells-gtk next week.

Damn, sounds like you got pretty far with Cells-ODE. I thought I was
going to be extending Cells left and right to support that. Glad to hear
it went well, I gotta add that to Cello. I mentioned to the organizers
of ECLM how thrilling it was that my 3D GUI buttons really were 3D. One
of them responded, "So what?". My fault, I forgot that the best part was
actually that the highlighting change needed to indicate that a button
was being held down (moused down but not yet released) that I achieved
this by actually moving the button further, well, down into the
keyboard. I am sure that would have him jumping up and down. And now
with Cells-ODE I can actually put little springs under the GUI buttons
and when we get the mouse-up event...



kt

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Ken Tilton wrote:
>> Btw, my current project contains a physics simulator using cells-ode
>> as a backend, the gl-drawing-area widget of cells-gtk3 for
>> visualization, and a small DSL to specify scenes in terms of
>> s-expressions. I will factor out the relevant stuff and merge it will
>> cells-gtk next week.
>
> Damn, sounds like you got pretty far with Cells-ODE. I thought I was
> going to be extending Cells left and right to support that.

I need to do some performance checking, tho. We might still need to
create a with-one-propagation macro for atomic changes. The stuff is
really slow at this point, about 1 fps. But hold on, this might be due
to my using OpenGL's selection processing about 10MB of vertex data at
every iteration.

> Glad to hear
> it went well, I gotta add that to Cello. I mentioned to the organizers
> of ECLM how thrilling it was that my 3D GUI buttons really were 3D. One
> of them responded, "So what?". My fault, I forgot that the best part was
> actually that the highlighting change needed to indicate that a button
> was being held down (moused down but not yet released) that I achieved
> this by actually moving the button further, well, down into the
> keyboard. I am sure that would have him jumping up and down. And now
> with Cells-ODE I can actually put little springs under the GUI buttons
> and when we get the mouse-up event...

Can't wait to play with it. As a matter of fact, I don't know whether
there are native springs in ODE. IIRC, you need to do some black magic
for that.

But wait -- we have CELLS-ode! A spring is defined by F = Dx --> So
what about something like

(make-instance 'slider-joint
:body1 *environment*
:body2 my-button
:max-force (c? (vector 0 0 (* D (z button)))))


A cells driven physics simulator will be an awesome toy ... but I still
have a thesis to write ;-)

TTL,
Peter

Frank Buss wrote:


> This looks interesting. But looks like is is a bit different from Cells
> and FBP. Is it right that in your system only one process (called "part"
> in your system) is active at the same time?

No - EXACTLY the opposite.

The idea is that every part is asynchronous and stand-alone.

Ideally every part would get its own cpu.

When we have only one cpu to work with (or fewer cpus than there are parts),
we have to "fake it".

When we fake it with a kernel in an embedded system, we use hardware
interrupts to supply the "threads" of execution - we can have at least as
many "threads" active as there are hardware interrupt levels. We *could*
fake it using an RTOS and a process for each part instance, I suppose, but
our real-life requirements didn't allow for such (space and time) luxuries.

Nor was it necessary to use an RTOS and processes - VF gives the benefits
without incurring the cost of fully-preemptive processes.

We have faked it under Windows (C) and Lispworks. A real project (an IDE
running under Windows) used something like O(10,000) part instances, iirc.
A simulation achieved O(1M) instances.

Example: currently, I am working on a GUI for a PDF page-layout system. I
needed a way to update properties on an object property sheet every time
time I made a change on the page (and v.v.). In Smalltalk, I would have
used the listener pattern, in CL, I would use a hoary complex of callbacks,
in kt-land, I would have used cells, but I was in too much of a hurry to
hit a trade show to learn a new (to me) technology. I built a part class
and a schematic class and used these to shepherd events around my system (I
made the deadline :-).

> How would you implement the
> telegram problem with your system?
> http://en.wikipedia.org/wiki/Flow-ba...ram_Problem.22

Similarly to FBP solution, I guess.

ReadSeq would read lines from the file and send each line out as an event.

DeCompose would chop up the line into words and send each word out as an
event. If DeCompose was "slower" than ReadSeq, line-events would pile up
at the input (in order) of DeCompose. If Decomose was "faster" than
ReadSeq, it would finish chopping and sending words, then go idle waiting
for another line event to wake it up.

And so on.

In fact, having used this stuff in embedded systems for so long, my
knee-jerk reaction would be to replace ReadSeq with ReadChar - and have it
send single characters as events. Decompose would be replaced by Tokenize,
which would buffer characters until it sees white space, then it would send
a word event. And so on.

The choice of records vs. characters is an architectural decision, not
something imposed by the system.

> In a multithreading FBP system, the ReadSeq process can run all the time,

VF uses cooperative multitasking (as does Stackless Python, as far as I
understand). VF parts are fully asynchronous and stand-alone, but the
(severe) overheads of full preemption is avoided with a trade-off.

At first, it may seem that the trade-off (no preemption) is too severe, but,
if you switch your mind-set to the "reactive" paradigm - everything is
INPUT driven - the trade-off melts away and seems completely natural and
fun (powerful) to use.

The weird-est (fun-est) part of VF is that you feel utterly compelled to
draw (semantically complete) diagrams of the software.

And, this leads to the revelation that all diagramming tools suck as code
editors.

The current implementation (written in lispworks) is a grand experiment at
inventing an emacs-like diagram editor (esp. employing "point" and "mark"
cursors) and "factbases" (using PAIP) to infer graphical objects from
graphical primitive objects (lines, dots, text) parse them and infer
semantic meaning.

pt

Peter Hildebrandt wrote:
> Ken Tilton wrote:
>
>>> Btw, my current project contains a physics simulator using cells-ode
>>> as a backend, the gl-drawing-area widget of cells-gtk3 for
>>> visualization, and a small DSL to specify scenes in terms of
>>> s-expressions. I will factor out the relevant stuff and merge it
>>> will cells-gtk next week.
>>
>>
>> Damn, sounds like you got pretty far with Cells-ODE. I thought I was
>> going to be extending Cells left and right to support that.
>
>
> I need to do some performance checking, tho.

Oh, right. Sounds like you were able to defer that.

> We might still need to
> create a with-one-propagation macro for atomic changes.

I thought I did that -- maybe I forgot to document it. ISTR doing the
geenral case of with-client-propagation so users could play all sorts of
games.

> The stuff is
> really slow at this point, about 1 fps. But hold on, this might be due
> to my using OpenGL's selection processing about 10MB of vertex data at
> every iteration.

Oy. Can you check every tenth iteration?

>
>> Glad to hear it went well, I gotta add that to Cello. I mentioned to
>> the organizers of ECLM how thrilling it was that my 3D GUI buttons
>> really were 3D. One of them responded, "So what?". My fault, I forgot
>> that the best part was actually that the highlighting change needed to
>> indicate that a button was being held down (moused down but not yet
>> released) that I achieved this by actually moving the button further,
>> well, down into the keyboard. I am sure that would have him jumping up
>> and down. And now with Cells-ODE I can actually put little springs
>> under the GUI buttons and when we get the mouse-up event...
>
>
> Can't wait to play with it. As a matter of fact, I don't know whether
> there are native springs in ODE.

Yeah, as I wrote I recalled being surprised at how little a physics
engine does for us. I have to wonder if a Lisp physics engine might be
in order. But maybe there is more there than I realize.


> IIRC, you need to do some black magic
> for that.
>
> But wait -- we have CELLS-ode! A spring is defined by F = Dx --> So
> what about something like
>
> (make-instance 'slider-joint
> :body1 *environment*
> :body2 my-button
> :max-force (c? (vector 0 0 (* D (z button)))))
>
>
> A cells driven physics simulator will be an awesome toy ... but I still
> have a thesis to write ;-)

Must be nioe having the finish line in sight. Good luck with that.

kt

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Ken Tilton wrote:
> Peter Hildebrandt wrote:
>> We might still need to create a with-one-propagation macro for atomic
>> changes.
>
> I thought I did that -- maybe I forgot to document it. ISTR doing the
> geenral case of with-client-propagation so users could play all sorts of
> games.

Stupid me. Now I remember us talking about it on cells-devel. I will
dig it up at integrate it with cells-ode next week.

>> The stuff is really slow at this point, about 1 fps. But hold on,
>> this might be due to my using OpenGL's selection processing about 10MB
>> of vertex data at every iteration.
>
> Oy. Can you check every tenth iteration?

As a matter of fact, that is what I do. The GUI provides me with a few
spin-buttons to select how often to run ODE, how often to redraw OpenGL,
and how often to process the output. But this is all for academics
anyway, so who is ever going to care?

>> Can't wait to play with it. As a matter of fact, I don't know whether
>> there are native springs in ODE.
>
> Yeah, as I wrote I recalled being surprised at how little a physics
> engine does for us. I have to wonder if a Lisp physics engine might be
> in order. But maybe there is more there than I realize.

Yep. Before starting to work with ODE I seriously considered writing my
own physics engine and realized quickly that it was not as easy as it
looks. It is quite simple to get the toy examples right, but once you
face Real Problems it gets ugly. You find yourself dealing with numeric
stability, numeric performance issues, optimization here and there,
borderline cases ...

Decided I could imagine nicer things to do on a sunny afternoon.


> Must be nioe having the finish line in sight. Good luck with that.

Thanks. And as a matter of fact, it was the best decision of the past
year or so to set an ultimate deadlide for delivery. I suggest you do
something similar for you Algebra software. It has a wonderful way of
focussing the mind :-)

Cheers,
Peter

Peter Hildebrandt wrote:
> Ken Tilton wrote:
>
>> Peter Hildebrandt wrote:
>>
>>> We might still need to create a with-one-propagation macro for atomic
>>> changes.
>>
>>
>> I thought I did that -- maybe I forgot to document it. ISTR doing
>> the geenral case of with-client-propagation so users could play all
>> sorts of games.
>
>
> Stupid me. Now I remember us talking about it on cells-devel. I will
> dig it up at integrate it with cells-ode next week.
>
>>> The stuff is really slow at this point, about 1 fps. But hold on,
>>> this might be due to my using OpenGL's selection processing about
>>> 10MB of vertex data at every iteration.
>>
>>
>> Oy. Can you check every tenth iteration?
>
>
> As a matter of fact, that is what I do. The GUI provides me with a few
> spin-buttons to select how often to run ODE, how often to redraw OpenGL,
> and how often to process the output.

Nice. I was wondering if there would be some way to leverage synapses to
automatically and selectively tune how often the ODE side got polled.
There would be a base rate (perhaps no more frequent than the highest
frequency required by any Cell) and then individual Cells or groups of
cells or something could decide which subset of the base rate samples to
process: Ah, not much is going on, let's wait 10ms before recomputing.
The cool thing would be that the synapse could adjust this over time, so
if things did get crazy up goes the sampling rate.

> But this is all for academics
> anyway, so who is ever going to care?

Academics!? Omigod!! If I had known that...
>
>>> Can't wait to play with it. As a matter of fact, I don't know
>>> whether there are native springs in ODE.
>>
>>
>> Yeah, as I wrote I recalled being surprised at how little a physics
>> engine does for us. I have to wonder if a Lisp physics engine might be
>> in order. But maybe there is more there than I realize.
>
>
> Yep. Before starting to work with ODE I seriously considered writing my
> own physics engine and realized quickly that it was not as easy as it
> looks. It is quite simple to get the toy examples right, but once you
> face Real Problems it gets ugly. You find yourself dealing with numeric
> stability, numeric performance issues, optimization here and there,
> borderline cases ...
>
> Decided I could imagine nicer things to do on a sunny afternoon.

Exactly. As long as ODE offers value it is more useful and fun to add
value elsewhere.

>
>
>> Must be nioe having the finish line in sight. Good luck with that.
>
>
> Thanks. And as a matter of fact, it was the best decision of the past
> year or so to set an ultimate deadlide for delivery. I suggest you do
> something similar for you Algebra software. It has a wonderful way of
> focussing the mind :-)

Yep. I went into final approach about six weeks ago, committed to doing
the absolute minimum to have something in folks' hands by, oh, July 1.
It's a lot more fun programming when I can get to something tricky and
just say f**k it, they'll live.

kt


--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Ken Tilton wrote:

> Yep. I went into final approach about six weeks ago, committed to doing
> the absolute minimum to have something in folks' hands by, oh, July 1.
> It's a lot more fun programming when I can get to something tricky and
> just say f**k it, they'll live.

If you want to put your mouth where your foot is:

http://kalzumeus.com/2008/05/27/incr...30-day-sprint/

That is my official invitation to you.

Really. Would love to see you reach the finish line.

Sohail Somani wrote:
> Ken Tilton wrote:
>
>> Yep. I went into final approach about six weeks ago, committed to
>> doing the absolute minimum to have something in folks' hands by, oh,
>> July 1. It's a lot more fun programming when I can get to something
>> tricky and just say f**k it, they'll live.
>
>
> If you want to put your mouth where your foot is:
>
> http://kalzumeus.com/2008/05/27/incr...30-day-sprint/
>
> That is my official invitation to you.

Why thank you. I'll think about it. But my experience has been that I
need to minimize distraction ruthlessly, so I might have to pass. Sounds
like fun, tho.

>
> Really. Would love to see you reach the finish line.

Not to worry, I have a friendly letter here from the IRS asking when
they might expect to see last year's taxes, those tend to focus the mind
wonderfully as well.

kt

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?do...93764413&hl=en
ECLM talk:
http://video.google.com/videoplay?do...42928&q=&hl=en

Ken Tilton wrote:

>> Really. Would love to see you reach the finish line.
>
> Not to worry, I have a friendly letter here from the IRS asking when
> they might expect to see last year's taxes, those tend to focus the mind
> wonderfully as well.

Well, best of luck focusing. Though I hear lots of (((())))) make you
cross-eyed.

Ken Tilton wrote:
> Nice. I was wondering if there would be some way to leverage synapses to
> automatically and selectively tune how often the ODE side got polled.
> There would be a base rate (perhaps no more frequent than the highest
> frequency required by any Cell) and then individual Cells or groups of
> cells or something could decide which subset of the base rate samples to
> process: Ah, not much is going on, let's wait 10ms before recomputing.
> The cool thing would be that the synapse could adjust this over time, so
> if things did get crazy up goes the sampling rate.

That'd be really nice. Then of course we'd have to intertwine the
stepping function with cells, so that cells knows when it was called the
last time (and with which step size and with how many iterations).
Then a synapse would know when (at which data pulse) it was updated the
last time and how much simulated time had passed since. I believe the
fire decision should be a function of those two.

> Yep. I went into final approach about six weeks ago, committed to doing
> the absolute minimum to have something in folks' hands by, oh, July 1.
> It's a lot more fun programming when I can get to something tricky and
> just say f**k it, they'll live.

Great. I'm looking forward to seeing it released

Peter