Fri May 1 20:09:42 CEST 2009
problem is this:
due to absence of threads and blocking read in emacs, transferring
atomic messages is cumbersome.
moreover, emacsclient won't work with large messages.
the simplest way to work around this is to use files to transfer
messages: 'load is a built-in function in emacs so should be
relatively fast, as is storing files on tmpfs.
emacs -> snot : same as it was, stdin.
scheme can use blocking i/o just fine
snot -> emacs :
- create /tmp/snot-message.el
- emacsclient -e '(load #f "/tmp/snot-message.el")'
- remove /tmp/snot-message.el
maybe it's time to look at slime..
slime uses in 'slime-net-read:
on a restricted region
slime sends the lenght!!
read uses the length to determine what part of the buffer to evaluate,
and a condition is computed to see if a message is complete.
(defun slime-net-have-input-p ()
"Return true if a complete message is available."
(and (>= (buffer-size) 6)
(>= (- (buffer-size) 6) (slime-net-decode-length))))
that's a nice trick. let's see if we can do something similar.
ok. i made 2 more buffers:
*snot-log* for message passing
*snot-msg* for debugging: log all messages
next: switch from string interpretation to buffer interpretation.
ok seems to work fine.
need to profile how inefficent it is to successively retry to parse an