[<<][packetforth][>>][..]
Fri Nov 3 10:11:52 EST 2006

shut up and code

i just finished a pre-emptable version of the parser. didn't find any
way to easily do the C stack switching, so i just made a single
function with a return stack as pf list. looks even simpler than it
was before.

FIXME: raw packet reading still uses blocking (iterated poll + sleep)
I/0. this might be incorporated into the pre-emptive parser later.

allright. so now it's really possible to get rid of all thread
code. guilty parties are:

- console : readline/emacs can be unified now
- osc     : i guess udp 'streams' are easily added

let's try console first.

maybe i should re-define a console? so it can easily be attached
later? maybe i should write the console in lisp/python whatever?

the thing which is important here is flow control: the console needs
to know when the prevous input was successful. maybe i should
distinguish two modes of operation:

- bidirectional: console sends message + waits for reply
- unidirectional: console sends raw text
- in-band-hack: unidirectional + escape code like 'emacs: '

the second one is trivial, and already present. the first one needs
flow control, so it's best to avoid ad-hoc protocols and just use the
pf text protocol: means, the other end is pf, and the communication is
one atom at a time.

actually, the first one is pretty trivial also: open a pipe, start
sending/receiving atoms.

so what am i whining about? both readline and emacs do not fit this:
they provide raw text, and require in-band data.

maybe i should try the emacs thing first and model readline after
that, using a special purpose hack: make pf talk back in their own
language.

ok.. emacs.pf works without reader.c now. sweet. probably best to go
after osc next: an opportunity to factor it into udp 'streams' and a
plain osc parser which operates on streams/strings.

still to fix:
- hex digit parsing -> can't save binary buffers quoted as strings now (done)
- osc-receiver -> no blocking receive atm

so the command console is the only thing that uses threads atm. all
the rest is thread free..

it would be nice to take advantage of the occasion to make the
readline console behave a bit better. alright..



[Reply][About]
[<<][packetforth][>>][..]