On May 27, 4:54 pm, Ken Tilton <kennytil> wrote:
[..]
>
> Events are hard for Cells, change is easy/
>> Yeah!!!! Argument from analogy!
>> Which is the exact same thing as traditional programming... well, know,
> it is worse. Try Prolog ot constraints or any non-deterministic (name
> well chosen) paradigm.

I already did that. Reminds me of the Russian joke:

I'm very ill.
Try drugs.
Tried. Ain't work.
Try herbas.
Tried. Ain't work.
Try surgery.
Tried. Ain't work.

Then pray to god
Tried. Ain't work.

:)

Slobodan Blazeski wrote:
> On May 27, 4:54 pm, Ken Tilton <kennytil> wrote:
>> Ok you got me. Any idea for cool problem with cells? Pure cells only
> no gui crap please.

Let's turn that around, that question still has the tool in front: what
applications (or libraries -- AC is having fun with a Web programming
library built on Cells) do you consider cool?

kt

Slobodan Blazeski wrote:
> On May 27, 4:20 pm, Ken Tilton <kennytil> wrote:
>> You are right but how does cells solve this?

Imagine you have been asked to write a report program that will take in
all the financial data for a company for last year and print out monthly
totals for revenue, costs, taxes, etc etc with subtotals etc, totalling
each for the year, computing a bottomline by month and then for the
whole year.

You have a great idea. Work out how to import the raw data into
VisiCalc. How would VisiCalc solve that?

Hint: it will /not/ involve you looking at the VisiCalc columns and rows
thinking "OK, the data starts here in A1 then flows over to B12 then
jumps out to C7 and D9". That is push, Visicalc is pull and really just
declarative: B12 = A1 + 42. I do not think about "pulling" from A1, I
just think about computing B12. The flow is an emergent property, not
part of my thinking.

The neat thing is that you can now add columns for new months and watch
results pile up if you can get a real-time feed out of the CFO, and as
they make corrections to last year's data....

With Cells you stop to think how to solve your problem as if your
application were a spreadseet model. In RoboCup, a first order set of
Cells took raw feeds from the server (which is simulated sensory data,
so we have some work to do just to build a "mental model" of where we
are on the field and where everything is) and, well, computed just that,
a model of the field, players, goals, and ball. Now I know where I am
and in what direction lies the ball etc etc.

The next layer of Cells decided on a strategy (the goalie might decide
to position themself ideally between the ball and goal until a shot is
taken (a higher order result), at which point the strategy rule should
recompute a new strategy: catch the ball. (Hmmm, I should have had it
consider tipping the ball over the goal or just clearing it.)

The strategy instance computes a series of "tactics" -- steps to take to
achieve the strategy. Each tactic had a rule to decide when it had been
achieved, or when it should be abandoned.

The cool thing is that I am in a game with twenty-one other players so I
can be in the middle of dribbling the ball downfield when my next sight
input arrives and the worldview cells rerun and suddenly the rule to
decide whether or not it is time to tap the ball suddenly gets back NIL
for position of ball -- it has gone out of sight -- and with luck I have
allowed for that and my design either drops back to tactic "find ball"
or as the designer I have had the foresight to code up the "abandon"
rule on the dribble strategy to go to true if I can no longer even see
the ball -- I mean, what's the point, right? (OK, OK, I know, this is
just an example, a real footballer does not need to see the ball
continuously, no quibbling plz <g>.) But in any case it is all
declarative. I cannot think about /particular/ events because the rules
I write must work for all circumstances as long as the instance I am
serving is alive. I decide what happens in /any/ event, or better, for
any state of the surrounding world, specifically the state that matters
to this slot being calculated by this rule.

Look, it is a new paradigm, OK? Old if you count VisiCalc, but then it
may as well be from Mars because we programmers have been hand-animating
our models for fifty years and cannot imagine an application built in
the mindset of CFO playing with VisiCalc. It took me a solid year to let
go of the hand-animation habit even after falling in love with Cells,
just to let you know how deep is the habit.

kzo

Ken Tilton wrote:
[..]
> can be in the middle of dribbling the ball downfield when my next sight
> input arrives and the worldview cells rerun and suddenly the rule to
> decide whether or not it is time to tap the ball suddenly gets back NIL
> for position of ball -- it has gone out of sight -- and with luck I have
> allowed for that and my design either drops back to tactic "find ball"
> or as the designer I have had the foresight to code up the "abandon"
> rule on the dribble strategy to go to true if I can no longer even see
> the ball -- I mean, what's the point, right? (OK, OK, I know, this is
> just an example, a real footballer does not need to see the ball
> continuously, no quibbling plz <g>.)

Actually, it would not be a quibble. Thanks to Cells I am now in a
position to insert a true mental model above the perception layer
compued from the raw layer (really just two-three kinds of input). The
mental model would persist over time in ways plausible given the laws of
physics and even certain assumptions ("if no one else has kicked the
ball it should be here based on the last observed location, speed , and
direction").

Great fun, programming this way. :)

kt
[..]

Slobodan Blazeski wrote:
> You are right but how does cells solve this?

CL-USER> (require :cells)
CL-USER> (defpackage :flow (:use :cells :utils-kt :cl))
CL-USER> (in-package :flow)
FLOW> (defmd node ()
in
out)
FLOW> (defmd double-node (node)
:out (c? (* 2 (^in))))
FLOW> (defmd print-node (node)
:out (c? (print (^in))))
FLOW> (defun path (&rest nodes)
(when (car nodes)
(multiple-value-bind (start node)
(apply #'path (butlast nodes))
(let ((self (make-instance (car (last nodes))
:in (if node
(c? (out node))
(c-in 0)))))
(values (or start self) self)))))
FLOW> (path 'double-node 'print-node 'double-node 'print-node)
DOUBLE-NODE26
FLOW> (setf (in *) 4)
8
16

What else do we have? Inverse and mod?
FLOW> (defmd mod3-node (node)
:out (c? (mod (^in) 3)))
FLOW> (defmd inverse-node (node)
:out (c? (if (eql (^in) 0) 0 (/ (^in)))))
FLOW> (path 'double-node 'inverse-node 'mod3-node 'print-node)
FLOW> (setf (in *) 4)
1/8
FLOW> (setf (in **) 1/8)
1

Satisfied?

Peter
[..]

Ken Tilton wrote:
>> Slobodan Blazeski wrote:
>>
> Let's turn that around, that question still has the tool in front: what
> applications (or libraries -- AC is having fun with a Web programming
> library built on Cells) do you consider cool?

btw, any simulation of course would be a blast. I think we are always
building models when we program computers, but when you are /really/
modelling something else (like a football match) Cells /really/ pays off.

That said, there is a second class of problem well-handled by Cells but
not so much cool as useful: driving another system from Lisp, whether it
be a C GUI, a sophisticated graphics engine like OpenGL, a Web browser,
or a C physics engine such as ODE. Over here the Lisp model Does Its
Thing, while Cell observers drive the other system over there, feedback
from that system coming in the form of C callbacks or http requests as
the case may be.

I always marvelled at the dual role played by Cells in something like
Cells-Gtk or Celtk -- animating the application model I have in mind
/and/ gluing that model to Gtk or Tcl/Tk, then I finally got it: Cells
is simply about change and simply gives application state causal power
over other application state. Causation and change are as fundamental as
it gets so dual/multiple roles are to be expected.

kt

Ken Tilton wrote:
> Events are hard for Cells, change is easy/

Huh?

I would have thought (without close examination :-) that Cells was based
on "events".

Obviously, our nomenclature does not match.

From my perspective, a "change" is an "event". A change causes a chain of
reactions - a chain of events sent to the dependents interested in the
event.

I think of an "event" as a pulse of data (scalar or non-scalar). The pulse
is propagated throughout the system. It might cause other components to
produce further "events" (data pulses).

The pulses of data are uni-directional (no call-return protocol implied).

A reactive system.

I perceive "events" (uni-directional data pulses) to be the most basic unit
of communication between software components.

Reading your past few postings, I surmise that you have some other
interpretation of the concept of "event".

Would you please explain to me what you think of as an "event" vs. "change"?

Thanx

pt

Paul Tarvydas wrote:

> Here are two short papers about it:
>
> [..]
> [..]

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

In a multithreading FBP system, the ReadSeq process can run all the time,
feeding lines of strings to the next process, which runs in parallel. But
if I understand your system correctly, it would need to fill up the queue
to the next process with all lines of the whole file, then goes to idle and
then the next process reads and evaluates the queue.

Paul Tarvydas wrote:
> Ken Tilton wrote:
>
>>Events are hard for Cells, change is easy/
>> Huh?
>
> I would have thought (without close examination :-) that Cells was based
> on "events".
>
> Obviously, our nomenclature does not match.

The nomenclature is fine, rather our subjects do not match.

I am talking about the programming experience. If I write a rule that
says the area is the length times the width then I am not thinking about
events. I /am/ taking huge delight in knowing that when in the course of
(yes) human events something transpires to occasion a change in the
width that the area will miraculously change at effectively (to other
code playing by the Cells rules) the exact same time. I believe this is
how Mr. Sulzberger resolved all these action at a distance matters, but
we not should digress in the absence of beer.

So the rule A = l x w is code written in an eventless mindset with its
inavriance enforced by one dataflow hack or another. Dandy.

But now we have a different rule that worries about a mouse-down event.
A button with a slot called "clicked?". But a mousedown /happens/, it
does not exist. Well, it exists ephemerally -- its existence is also its
demise. An example will make this clearer.

If I say:

(when (mouse-down *system*)
(when (pt-within (mouse-pos *system*) (bounding-box self))
...I have been clicked! Do amazing things...))

And suppose we get a mouse-down event in this GUI button which happens
to launch all ICBMs on Canada. That is OK, the button was disabled, the
launch commander was just showing off for the cute new recruit, got a
giggle out of her... I digress.

Now things get serious. No, not that. Canada freezes maple syrup
production to drive up prices. Bush hopes a third war will distract the
world from the first two he started and throws Congress a biscuit who
runs in a circle, rolls over, and declares the hockey puck a weapon of
mass destruction. All the silos go to defcon 42 and the launch interface
software enables all the gui buttons which now need to be redrawn with a
thicker frame so now they are bigger. The bounding box has changed. The
above rule runs.

The launch commander is necking with the recruit having left the mouse
positioned over the button, so if the mouse-down slot is populated...
bye bye moose people. That's OK, he is necking, not holding down the
mouse button. But what is the value of the mouse-down slot of the system
instance? Is it the same as when he clicked the disabled button to show
off? Bye bye moose people. And that would be an event.

So this is the tricky bit -- I can no longer think the way a spreadsheet
modeller thinks. They build models as if there was no such thing as
change by writing a rule that will be true regardless of events, for all
values of all independent variables: area is length times width. boom, I
am done. change is someone elses's problem -- ah, there ya go. In the
only paradigm most yobbos understand, they are in charge of propagating
change. They are not like me, they are all smart, they /like/ being in
charge. That is why they live in a forum where they can kick people who
joke about their typos. I digress. I am not smart like them, I love
automatic change management even more than I like automatic memory
management. I could programm faster in C with Cells/C than a yobbo could
program in Lisp without it. Hell, the not-to-be method would handle the
fricken GC...hmmm, should I go back? Run 20% faster? See, this is the
thing: Cells is just about change (or change and cause and effect but I
keep thinking they must be the same because of something Buddha said) so
automatic memory -- what is that about? Anyone? Good, Tommy. Change.

>
> From my perspective, a "change" is an "event". A change causes a chain of
> reactions - a chain of events sent to the dependents interested in the
> event.
>
> I think of an "event" as a pulse of data (scalar or non-scalar). The pulse
> is propagated throughout the system. It might cause other components to
> produce further "events" (data pulses).
>
> The pulses of data are uni-directional (no call-return protocol implied).
>
> A reactive system.
>
> I perceive "events" (uni-directional data pulses) to be the most basic unit
> of communication between software components.

Then stop thinking about communication between components. When you see
area = length x width, do you see length and width components
communicating wuth an area component? If so, fine, but does that not
also feel a tad contrived? Smalltalkers say 2+3 is a message to 2
telling it to add 3 to itself. chya. And worse than contrived, doh!, now
you are the one thinking about architecting the dataflow from here to
there to there to here to -- what? -- achieve the application
functionality. Cue Brooks, that does not scale. I need a declarative
paradigm that lets me write one rule at a time in isolation and have my
application emerge from the sum of the rules.


Think about the mindset of a spreadsheet modeller, the CFO using the
software to model the finances of his employer. Great, the huge model
gets filled with literal data such as the current prime rate or current
tax tables in some cells and formulas in others. [This happens to be
exactly how cell-driven slots work in CLOS.] OK, now the CFO starts
experimenting with different values for exchange rate and cost of fuel.
Both are volatile so he experiments a lot. The people who wrote VisiCalc
sweated bullets over getting the numbers displayed to recalculate
properly in the face of these change events, but the CFO just wrote
rules in a state of mind oblivious to change relying the underlying
tool to handle all that.

>
> Reading your past few postings, I surmise that you have some other
> interpretation of the concept of "event".

No, I just do not want to /think/ about events or change /while
programming/. That is a slippery slope that ends up with Brooks being
right: manual management of change by the programmer is ineluctably hard
once a too-low threshold of application complexity is reached.

I want to be precisely exactly completely totally is anybody listening
like a spreadsheet modeller, writing one rule for all time that will
compute the right value for this cell and have Cells handle the rest.

When after ten years of C I made automatic memory management a "must
have" on my shopping list for a new language, I was not saying I had no
intention ever again to allocate and later no longer need blocks of
memory -- I just did not want to think about it any more.

>
> Would you please explain to me what you think of as an "event" vs. "change"?
>

The trick then -- and hey, maybe I missed an easier way! -- is that
unlike anything a spreadsheet modeller deals with it seems to me there
is some data such as "the mouse just went to a down state" that forces
me to step away from a steady state state of mind and think about events
/at the application level/ -- not just something happening in the
background that Cells has to deal with. Ah, even better than the above
scenario: suppose the launch commander is doing a drag and drop and
happens to pass over the launch button just as it gets enabled. By GUI
standards that is /not/ a mouse click, tho the mouse would be down over
the enabled button.

As for there being an easier way, perhaps there is a way to duck the
special handing of events by using time as state (with Lisp time
granularity then being sufficiently imprecise as to take out Canada on
an unlucky day) but Tilton's Laws of Programming frowns on making things
more complicated in order to make things simpler: if a mousedown is not
like a mouse position they should be different in the same way.

peace, out, kzo

Ken Tilton wrote:
> If I say:
>
> (when (mouse-down *system*)
> (when (pt-within (mouse-pos *system*) (bounding-box self))
> ...I have been clicked! Do amazing things...))

The more I think about it, I believe this is how we should do events in
Cells-Gtk4. Well, deadline is on Friday. Some time after that.

[..]
> software enables all the gui buttons which now need to be redrawn with a
> thicker frame so now they are bigger. The bounding box has changed. The
> above rule runs.
>
> The launch commander is necking with the recruit having left the mouse
> positioned over the button, so if the mouse-down slot is populated...
> bye bye moose people. That's OK, he is necking, not holding down the
> mouse button. But what is the value of the mouse-down slot of the system
> instance? Is it the same as when he clicked the disabled button to show
> off? Bye bye moose people. And that would be an event.

Thanks for that story. You made my day :-)

>
> The trick then -- and hey, maybe I missed an easier way! -- is that
> unlike anything a spreadsheet modeller deals with it seems to me there
> is some data such as "the mouse just went to a down state" that forces
> me to step away from a steady state state of mind and think about events
> /at the application level/ -- not just something happening in the
> background that Cells has to deal with. Ah, even better than the above
> scenario: suppose the launch commander is doing a drag and drop and
> happens to pass over the launch button just as it gets enabled. By GUI
> standards that is /not/ a mouse click, tho the mouse would be down over
> the enabled button.

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.

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.

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

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?
> [..]

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

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