I started a toy version of the Distel process code (erl.el) in Common
Lisp, and I thought it might be interesting to replace the event loop with
an architecture based on cells. I've read Bill Clementson's post on the
subject, but I'm still a little fuzzy on a good mapping of the states in
an event loop to a collection of models. Could anyone give a simple
example of a system modeled as a state machine, and then modeled in cells.
Thank You,
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> I started a toy version of the Distel process code (erl.el) in Common
> Lisp, and I thought it might be interesting to replace the event loop with
> an architecture based on cells. I've read Bill Clementson's post on the
> subject, but I'm still a little fuzzy on a good mapping of the states in
> an event loop to a collection of models. Could anyone give a simple
> example of a system modeled as a state machine, and then modeled in cells.
>
> Thank You,
>
> Matt
>
Send me the event loop code and I will try to help. If you do not mind
an audience, subscribe to cells-devel and mail it there. I treat that as
cells-user, too. :) I like to keep these chats public so others benefit.
You'll be able to get to the list subscription here:
http://common-lisp.net/project/cells/
I am currently overhauling Cells /and/ moving to a new apartment, so
there might be a small delay in responding, but if the "event loop" is
anything like GUI event loops the answer is pretty easy: we still
register event-specific callbacks with a dispatcher, then within each we
just:
(defun mouse-event-handler (mouse-event)
(setf (mouse-event *window*) mouse-event))
[Aside: *window* might be passed to the handler or extracted from the
event or the application's problem to figure out depending on the GUI.]
Anyway, other rules are then "watching" the mouse-event and get kicked
off, starting a cascade of processing all specified declaratively, which
is nice.
btw, if like Mac OS9 all events come in thru some waitNextEvent call,
one still has a case statement for each event type and stuffs
mouse-events into a mouse-event cell, a key-event into a key-event cell,
etc.
So the application is built as a tree of model instances with various
interdependencies (detected and tracked transparently) and we drive the
thing by feeding it OS events. The application takes effect via
so-called "output" callbacks. The latter is what I am overhauling to
give users control over outputs where needed.
kt
Warning: I know nothing about Erlang, so if that matters it may take us
a while to understand each other.
On Wed, 22 Feb 2006 20:41:13 +0000, Kenny Tilton wrote:
> Send me the event loop code and I will try to help. If you do not mind
> an audience, subscribe to cells-devel and mail it there. I treat that as
> cells-user, too. :) I like to keep these chats public so others benefit.
Well, I'm still trying to grok it, but there's no explicit event loop: its
a scheduler that is driven by two external events. The scheduling loop is
driven on one end by the explicit spawning of processes and on the other
end by the receipt of messages (both local and remote-- the remote
messaging is still a bit of a mystery, but the socket, I think, is handled
by emacs and distel must hook into it somewhere).
The processes (at least the code) themselves are usually explicit
infinite loops that pull from a message queue using erl-recieve.
Erl-recieve yeilds by returning a thunk to the scheduler if the process
has to block-- No preemption just cooperation.
Anyway, I'll explore more of this on the cell list as soon as I have a
better idea what's going on in the emacs code. I just brought it up at
this early stage (in my understanding of distel), to see if there was a
standard, or at least natural way of mapping a state machine to a network
of cells.
Anyway, thanks for the invite, and I hope to have better (and more
concrete) things to say about distel soon.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> Anyway, I'll explore more of this on the cell list as soon as I have a
> better idea what's going on in the emacs code. I just brought it up at
> this early stage (in my understanding of distel), to see if there was a
> standard, or at least natural way of mapping a state machine to a network
> of cells.
>
OK. No, no standard way, but I think we can invent an automatic
conversion of a state machine to a Cells-based implementation. If we are
talking about what I think we are talking about (a finite state machine
with rows representing states and columns the inputs, each col-row
specifying a transition to a new state) we can do it programatically.
otoh, FSMs and Cells are a tad redundant. Both decompose the complexity
of an unpredictable input stream into manageable chunks. I am thinking
that, once I have the state table, shucks, the code to implement it is
straightforward. Cells may not offer any value.
otoh2, if you skip the state machine analysis and just start coding
naturally using Cells, it may turn out you do not need the FSM
decomposition.
kt
On Wed, 22 Feb 2006 20:41:13 +0000, Kenny Tilton wrote:
> if the "event loop" is anything like GUI event loops the answer is
> pretty easy: we still register event-specific callbacks with a
> dispatcher
Distel has a state machine, but in theory the only the only "real" event
I'm tied to is the sending and receiving of messages over a socket.
The whole interaction with remote nodes and among local node(s)
could have a cells interface. However, I don't know whether that would
look like erlang anymore*.
Matt
*It certainly wouldn't have erlang's semantics, but strictly speaking
neither does distel since all distel processes are non-preemptable.
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> On Wed, 22 Feb 2006 20:41:13 +0000, Kenny Tilton wrote:
>
>
>>if the "event loop" is anything like GUI event loops the answer is
>>pretty easy: we still register event-specific callbacks with a
>>dispatcher
>
>
> Distel has a state machine, but in theory the only the only "real" event
> I'm tied to is the sending and receiving of messages over a socket.
I had a ball with Cells and RoboCup, in which client players talk to a
server that combines inputs from the other teams players to compute a
virtual game. The message types were simple: see, sense, move, kick,
IIRC. But then I created a whole framework of strategy, tactic, goals
(as in objectives) all of which shifted during play. Turns out to have
been a much greater stressor than anything else I had done with Cells
and led to a major rewrite.
>
> The whole interaction with remote nodes and among local node(s)
> could have a cells interface. However, I don't know whether that would
> look like erlang anymore*.
Can't help you with that, as promised. :) I do see a boast about
"declarative" in there, and Cells is all over that.
kt