PLT Scheme sandbox + multiple repl support for Emacs.

SNOT is not slime.. it's a special purpose PLT Scheme <-> Emacs
binding, intended to support http://zwizwa.be/brood , a suite of
languages based on lisp and forth.

For more info, see:
http://zwizwa.be/darcs/snot/README

Entry: cough 1 2 3
Date: Wed May  2 22:26:28 CEST 2007


the idea is:

* to have a single pipe (stdio) between scheme and emacs.
* send s-expresions over this pipe
* possible asynchronous operation (not yet)
* there is only one connection, one scheme process

Oh and.. this is late night hacking, except for the times when I get
fed up during the day..


Entry: multiple repls
Date: Wed May  2 23:07:22 CEST 2007

the idea is that the emacs side determines which mode is running: the
scheme side is modeless. it has only state, and several suspended
modes acting on this state.


Entry: turning things around
Date: Wed May  2 23:51:35 CEST 2007

it's probably better to let the other end perform more of the
logic. emacs is cool, but i miss the power of scheme.. the thing i
need to look at is to make the communication protocol better.

one of the things to arrange is to let scheme call emacs and act on
values. so the interface should really be fully 2 way.


request:  (<receiver> expr ...)
reply:    (<receiver> (out x) ... (val x) ... (err x) ...)


Entry: async
Date: Wed Jun  6 20:11:44 CEST 2007

using it for a bit, it's clear that async IO is necessary. for the
rest it works pretty well. so i need these operation schemes:

* synchronous evaluation: obtain value from scheme -> emacs,
  independent of the currently running task.

* commands: set some process in motion, and let it print to the buffer
  output, possibly executing emacs code.


what about this: all messages are asynchronous on the emacs
side. synchronous is built on top of asynchronous, by waiting on a
reply, and updating all buffer filters during waiting. this is how it
works now.

the change would be: scheme side can return multiple output replies,
but the value needs to go to a proper receiver. i think this solves
it: scheme just needs to treat output and values differently, sending
output always to the buffer, and reply to the receiver requested by
emacs.

so, basicly, it's just as ordinary inferior processes, only the stuff
that comes back is tagged (embedded in s-expressions), giving several
logical channels. two of them are ordinary output, and emacs code
invokation. (ordinary output is a special case of emacs code
invokation, in short: everything that returns is evaluated).


now, the difference between a synchronous and an asynchronous reply is
that the former has some code waiting. i could probably unify both of
them, by having the async reply always store the values and errors in
some dummy global variable: normally, there should be no value, since
for async commands, either output is generated, or some other elisp
code is run.


Entry: changes
Date: Wed Aug  1 12:00:27 CEST 2007


- output is always asynchronous, go directly to the console and thus
  cannot be waited on

- only values and errors can be waited on

- snot needs a restart mechanism (implemented by a relaunch script)

- save all (most) state and functionality on the scheme side
  (i.e. 'current language' and prompt etc..)


what about this:

emacs -> scheme	: a single read dispatch loop
scheme -> emacs : a single write merge loop

then tasks are just tasks: they do something, write output, maybe read
input. the important part is to get the synchronization right.

then, the next problem is pipes. the output from ordinary scheme
functions needs to be wrapped in an s-expression by a separate task.

things i need to read:
- ports and I/O, or how to implement a port
- synchronization mechanism: the concurrent ML stuff



Entry: scheme concurrency
Date: Wed Aug  1 12:35:10 CEST 2007

bringing the raw character I/O to a synchronized channel is really
trivial. now for the other way: i'd like to have a raw character
output generated within the expr->reply evaluator to show up on the
console, wrapped in an 'out' event.

this works, but my synchronization is off.

instead of 'simply using' pipes, it might be better to just implement
a new port, which immediately sends stuff through to the channel.


Entry: elisp sync
Date: Wed Aug  1 16:43:22 CEST 2007

now that tasks are working, and output is working too, there is no
longer a need to distinguish between synchronous and asynchronous
invokation from emacs: only synchronous is supported.

async stuff is handled from scheme: scheme can call arbitrary
functions from the process filter.

ok, that's not true. control needs to be passed back to elisp when a
command is sent: can't busy wait on it, polling output.. this is only
for synchronous stuff.

but, i got it almost right now:
* output is always asynchronous: goes straight to the buffer
* only one callback for values: snot-reply-sync

what i need is a proper way to handle replys. actually there are only
2 mechanisms that need replies, of which there is only one at a time:

* generic eval (emacs is single-threaded)
* prompt ready (only one snot process)

but i do want to combine them. so both need their own callback and an
exclusion mechanism. 

got them working now, but still need exclusion mechanism, and tasks.


Entry: updated new brood core
Date: Sun Aug  5 00:16:32 CEST 2007

to run with snot. still only have cat running. the whole brood system
will follow in the next couple of days maybe..

one more question for today:

why do emacs -> scheme and scheme -> emacs protocols need to be
different?


Entry: more in scheme
Date: Mon Aug  6 10:39:33 CEST 2007

to make snot more useful, more logic needs to be implemented in
scheme. emacs should be just 'view' and contain no state.

first thing to take out is the prompt. whenever a prompt changes, the
scheme process notifies emacs so comint highlighting can be changed.


Entry: protocol simplification
Date: Mon Aug  6 13:41:32 CEST 2007

Making a simpler 2-way message protocol. Return values are ignored, so
if a reply is required, the evaluator needs to be passed a
continuation.


Entry: sandbox working
Date: Tue Aug  7 20:29:17 CEST 2007

whoohoo!

now i just need to add some code for sending the whole buffer at once
to the snot process, and i got myself a transparent repl.


Entry: eval-string is not used
Date: Tue Aug  7 21:16:37 CEST 2007

i don't use it anywhere, so better to take it out? maybe best to
replace it with an s-expression version, for those languages where it
makes sense to do so.

in addition to that, what about the 'values' construct? it is handy
for stack langauges..


Entry: things to fix
Date: Thu Aug  9 18:43:14 CEST 2007

* transferring code to sandbox -> asynchronous (done)
* set directory path properly (done)
* breaks don't play nice with sandbox.ss



Entry: cleanup string stuff
Date: Sat Oct  6 19:57:17 CEST 2007

some strings mess up the scheme -> emacs communication. quickly
patched it, but there's a problem with eval/not eval at some
points. i.e. in scratch buffer :

	(snot-eval '(list->bytes '( 0 0 0 ))) =>
	(string 0 0 0)

and not the string itself.

it's importantto be able to transfer binary data.

problem: snot-eval-reply should process the expression 


Entry: time for factoring
Date: Sun Oct  7 23:50:03 CEST 2007

been using it for a while. maybe it's time to factor it out a
bit. there are already some clear components:

- emacs <-> scheme channel + data type translation
- multiple language repl
- mzscheme sandboxes



Entry: moving to plt v4
Date: Thu Feb 21 18:45:32 CET 2008

a lot of things changed in plt 4 that obsolete some of the things used
in snot. it looks like the 'enter!' macro will completely obsolete the
'box' approach. or not.. the thing with enter! is that it gets rid of
the toplevel namespace that snot uses to interact with modules.

(enter! <x>) -> (do-enter! '<x>)
it's defined in scheme/enter.ss

to go to a single scheme repl instead of 2, it might be interesting to
have 'box' use escape commands.

two things not to confuse:
  enter! merely uses namespaces, while sandbox uses custodians and
  more separation.

apparently, enter! can easily be used inside a sandbox. just (require
scheme/enter) after creating the evaluator.


for reference, eli barzilay's debug tricks:
http://tmp.barzilay.org/interactive.ss


Entry: prompt and errortrace
Date: Thu Feb 28 15:40:47 CET 2008

trying to get some decent stack trace reporting working for sandboxed
evaluators. first thing: extended the evaluator with a preprocessor
that takes 'unquoted' commands. see make-eval in snot/box.ss

now: where do exceptions go that are generated in the box? it seems
they are propagated across the box barrier. do i want that? yes, in
case of normal eval, but no in case of repl.

maybe look at the sandbox plt code to see if it uses prompts..

  NOTE: exceptions travel across prompts. this is because they are
  re-raised. see the internal function 'user-eval' in
  'make-evaluator*' in scheme/sandbox.ss : the value that comes from
  the channel is raised if it's an exception.

in order to capture stack traces, it needs to be done inside the
sandbox, since the outside doesn't have access to this (it's a
separate thread).

something else i noticed there: void can be used to capture anything:

(with-handlers ((void (lambda (ex) 123))) (raise 'boo))
=> 123

  10.2.2 handling exceptions:
  "The new exception handler processes an exception only if one of the
  pred-expr procedures returns a true value..."

it doesn't say anything about void values. maybe some unspecified
legacy thing? ok.. maybe time to stop. a 'true value' is not a '#t'
value. void is true.

anyways.. looks like the solution is (see brood ramblings) to capture
the exception inside the box, and have it print an error trace
there. it should be possible to use the default error printer for
this. if i'm correct, the exception contains the complete information
to print a stack trace.

  10.2.3

  "The default error display handler displays its first argument to
   the current error port (determined by the current-error-port
   parameter) and extracts a stack trace (see
   continuation-mark-set->context) to display from the second argument
   if it is an exn value but not an exn:fail:user value."

fixed that: solution is:
  * errors are captured inside the box by the plt sandbox.ss machinery
  * they are printed with-error-print using (error-display-handler)
    (used in language.ss)


Entry: parsing in scheme?
Date: Thu Feb 28 15:50:50 CET 2008

since i'm running into quite some trouble with different syntax in
emacs vs scheme, it might be interesting to move more of snot.el to
scheme, and do the basic parsing in scheme, using emacs more as a
terminal. this would also enable more of the functionality to be
available in a readline console.

probably some of the functionality of drscheme can be snarfed in this
way. also, it makes sense to do this for forth too. more
context-sensitive editing.


Entry: the 'help' command
Date: Sun Mar  9 15:29:44 CET 2008

(require net/sendurl)
(external-browser '("emacsclient -e '(w3m \"" . "\")'"))

which is a bit dirty: help opens on the host where the scheme is
running.. maybe that's just what's necessary? probably better to open
it in emacs session: find a way to channel this through the snot pipe.


Entry: bored
Date: Mon Mar 10 18:09:40 CET 2008

before digging into the module/unit system fully, let's try to play a
bit trying to add some functionality to snot. in my .snotrc, i took
out the image language: with unquoting commands and forms, this isn't
necessary.

problem: read: #lang expressions not currently enabled

note: main difference between a toplevel namespace and a module is
that the former allows free variables, the latter does not.



Entry: fixing macro transformation in module context (after enter!)
Date: Thu Mar 13 10:25:02 EDT 2008

done + fixed (read-accept-reader #t)



TODO:
  figure out prompts + snot + errortrace
  figure out #lang syntax
  more parsing in scheme?
  make repl behave more like readline? (look at slime again)
  save commands in file like readline




Entry: port to v3.99.0.23
Date: Tue Apr 22 20:10:26 EDT 2008

language changed from mzscheme -> scheme/base


Entry: continuation marks
Date: Thu May  1 13:29:05 EDT 2008

wrap sandbox evaluation in a continuation mark + exceptions for
toplevel forms (require).


Entry: kindergarten
Date: Tue May 13 01:12:46 CEST 2008

time to stop pretending and start to use slime+cl to get some
inspiration..

i'm getting a bit ennoyed with snot, and the way the repl works
so-so. i'd like to write it in scheme, so it also works on the command
line, and just provide an api for emacs.


Entry: parsing
Date: Fri May 16 15:13:25 CEST 2008

The problem is really parsing. What you want is PLT do do the parsing:
faking it in elisp is never going to work, especially not with the
pluggable syntax in PLT Scheme.

So.. snot should just use the readline repl, and use a separate
mechanism for sending messages to the process. Something that can be
attached later.



Entry: partial parsing
Date: Sat May 17 01:32:11 CEST 2008

the thing to figure out is how to trick scheme in doing 'partial
read'. i.e. 

image> (with-handlers ((void (lambda(e)e))) (read(open-input-string"(1 2")))
#(struct:exn:fail:read:eof
  "UNKNOWN::0: read: expected a `)'"
  #<continuation-mark-set>
  (#(struct:srcloc #f #f #f 1 1)))

hmm.. 

what's the problem really? snot needs a proper repl and a separate
command channel. all of it needs to be programmed in scheme, and the
interface between emacs and scheme needs to be standardized, so there
are no surprises with datatypes. current hacks are crap.



Entry: design changes
Date: Thu May 22 15:19:22 CEST 2008

instead of convincing emacs to read snot i/o, it might be wiser to
restructure snot such that the scheme side does all the magic, and
uses elisp just passes messages to emacs through a channel.


Entry: better emacs channel
Date: Thu May 22 15:28:00 CEST 2008

This is a redesign of the emacs<->mzscheme communication in snot,
using a simpler architecture where mzscheme does most of the logic.

Previous design had the following problems:

 * repl not intelligent enough to understand the different languages used.
 * differences in elisp <-> scheme syntax
 * problematic multiplexing of data over a single channel

The core idea now is: keep the emacs side dumb. All significant
processing should be done in the scheme side, possibly also providing
the emacs side with code initializations.

Where to start?

   ** create a bidirectional asynchronous message channel **
  
What about using emacsclient for scheme->emacs? One of the things i
got annoyed about is that there's no way to perform a read from a
stream to produce a single message without hassle. emacsclient does
provide delimited messages.

Sending messages the other way could be done using a similar
'mzclient' application. Using socat is probably the easiest way.

I'm thinking about just using unix sockets on the scheme side, but
this is not portable. INET sockets are portable, but not
authenticated.. Let's stick to unix, and make the mechanism pluggable
later.



using  (planet "socket.ss" ("vyzo" "socket.plt" 1 2))
but i can't get it to work with PF_UNIX

maybe i concentrate on just stdin.

i ignored a problem: some code in emacs will need a blocking rpc
semantics. how to do that?



Entry: emacsclient
Date: Thu May 22 18:43:58 CEST 2008

snot -> emacs (print)    == scheme STDOUT
emacs -> snot commands   == scheme STDIN
snot -> emacs (commands) == emacsclient

emacsclient works while emacs is busy as long as (snot-poll) is called.

so what does this solve? it removes input parsing on the emacs side.


Entry: binary interface
Date: Thu May 22 18:53:04 CEST 2008

stretching further, what about
  * one buffer per repl
  * raw pipe io for transferring binary files, or temp files
  * one modeless bidirectional comm channel

one buffer per repl: this makes it easier to do sane syntax
highlighting, by reusing other interaction code.

so, i need to find a way to open multiple consoles on a running scheme
system. unix sockets make this relatively easy.


Entry: no RPC
Date: Sat May 24 01:33:39 CEST 2008


http://www.erlang.org/pipermail/erlang-questions/2008-May/035207.html

doing something different, design without rpc? is it possible or
desireable in emacs? i'm thinking about command completion..


Entry: channels
Date: Sat May 31 17:05:18 CEST 2008

so.. let's stick with asynchronous messages, and proper channels.

the unix socket approach might be nice, but is not portable. maybe i
should follow the PLT approach and forget about that, and concentrate
on TCP + some other form of authentication.

this brings us to SSL/TLS. is there native support for PLT here?
yes: (require openssl)


it would really be more interesting to use ssh instead, since that is
usually already in place. that's why unix sockets are interesting: use
ssh + socat to connect to a user managed pipe.

anyways, let's try to get ssl running.

with the example it works.. that gives encryption, but no
authentication.

ok.. what about just ignoring this crap and going for a very simple
ipc mechanism that starts a listener given an input port.


Entry: abort and expanding top forms
Date: Wed Jun  4 11:01:43 CEST 2008

currently, i'm expanding top forms manually to be able to evaluate
'define' expressions. however, this seems to be bug prone.. is there a
better way? sandbox should be able to do this, right?

let's see how sandbox catches errors.

ok, it was a sandbox bug, fixed couple weeks ago.
other problems seem to be solved too.



Entry: box commands
Date: Sat Jun  7 17:29:04 CEST 2008

removed explicit box commands: symbols now come from toplevel and are
interpreted as thunks, or are expanded to a filename and loaded in
some path.

this means there is no access to variable values through box commands:
use parameters instead.

something i'd like to improve on is how to reload snot.



Entry: repl in scheme
Date: Sun Jun  8 10:10:21 CEST 2008

i was wondering what is necessary to design a proper repl for snot. it
would be nice to have it working in scheme, and let it use emacs just
as a display interface. what should that interface have?

my best guess is some model-view-controller architecture, since it's a
ui.

there are two parts to editing:
  * treating the code at hand as plain text
  * treating it as a (partially) parsed object

the problem is that using emacs's partial parsing method doesn't
really work because of minor differences in syntax.. what i'd like to
do is to use exact parsing.

this is not so trivial as it sounds.. really would be helpful if
internals of read were exposed.



Entry: displaying images
Date: Fri Jul  4 12:56:19 CEST 2008

There are two problems I'd like to solve: displaying bitmap images and
Gnuplot output. The easiest way seems to be to add some kind of
data structure like:

(snot-image <w> <h> <c> <bytes>) to move images between snot and emacs.


In emacs, the simplest way to create and display an image is:

(insert-image (create-image "P5\n3 3\n255\nzzzzzzzzz" 'pbm t))

The problem is: all output is printed verbatim, so what is needed is
some kind of escape sequence there.

Maybe I should forget displaying images inline for now: there's an
interaction with the output filter I don't understand. Inserting
images @ current position is no problem. Let's extend snot with a
'video' port, something that accepts image data.

One problem though: how to get the image out of the sandbox, into the
upper atmosphere?

Ok, this doesn't seem so difficult: just add a box command that will
fetch a variable name, or evaluate an expression that displays an
image.

The real problem atm is getting the damn binary data into emacs.


Looks like it works now: quoting is fixed, looks like i can send image
data. It's just terribly unefficient. Maybe just use "tail -f" in
image mode?

Entry: schem->emacs
Date: Fri Jul  4 16:09:58 CEST 2008

The simplest thing to do is to make sure emacs side only needs to do
'eval' on all s-expressions that come in. Currently however, there is
a difference between the way emacs->scheme RPC and scheme->emacs ASYNC
messages are handled. First one does proper unquoting, second one
doesnt.

( This code is a complete mess, and I need to have a proper protocol,
probably best Scheme forms with quote/unquote. )
 
This is the emacs code that needs to be evaluated:

(snot-display (snot-unserialize (quote (unquote (string 1 2 3)))))

I think i start to see the problem: one would like to keep emacs's
quoting facility, but at the same time, in paralle, be able to add
data converters in the s-expressions. This requires a SEPARATE quoting
mechanism, because otherwise it would interfere with nested
quasiquotes/backquotes.


So, the scheme->emacs channel has

    * a scheme side driver which inserts 'snot-construct' atoms
    * a emacs side receiver which unpacks these before eval is called


Entry: transferring large data chunks
Date: Fri Jul  4 19:42:45 CEST 2008

maybe.. it's quadratic?
i think i use string-append somewhere.. probably a temporary buffer is
a better idea?

i tried emacsclient approach: works, but seems to have a problem with
large messages and isn't really fast either.



Entry: module language
Date: Thu Mar 26 10:46:40 CET 2009

I'm starting to appreciate DrScheme's "run" button.  Let's wakeup that
behaviour in snot.


UNKNOWN::0: read: #lang expressions not currently enabled

 === context ===
/home/tom/snot/box.ss:135:2: box-read

(read-accept-reader #t)


Ok, so I added this in box-read, but then it fails:

extract-required: bad language spec: 
  (module page scheme/base
        (require net/url)
        (define
          (url str)
          (define url
            (string->url str))
          (set-url-scheme! url "http")
          url))

The module name needs to come from the filename..  This can be done by
setting the filename of the stream passed to read.  Can we fix this
with read-syntax?

Fixed with make-module-evaluator.



Entry: typed scheme
Date: Tue Mar 31 12:48:49 CEST 2009

program::: define-struct:: bad syntax in: (define-struct: si (asm dasm))

 === context ===
/usr/local/plt/collects/scheme/sandbox.ss:667:2: user-process

typecheck: unbound identifier compile-enforce-module-constants

 === context ===
core
/usr/local/plt/collects/typed-scheme/private/type-utils.ss:216:0: tc-error/expr
/usr/local/plt/collects/typed-scheme/env/type-env.ss:42:0: lookup-type
try-next
/usr/local/plt/collects/typed-scheme/typecheck/tc-expr-unit.ss:214:0: tc-expr
try-next
/usr/local/plt/collects/typed-scheme/typecheck/tc-expr-unit.ss:214:0: tc-expr
/usr/local/plt/collects/typed-scheme/typecheck/tc-toplevel.ss:251:0: tc-toplevel-form
try-next
/usr/local/plt/collects/scheme/sandbox.ss:375:0: call-with-custodian-shutdown
/usr/local/plt/collects/scheme/sandbox.ss:681:6: loop

Fixed after uncommenting line 211 in box.ss:
      ;; (eval '(compile-enforce-module-constants #f))



Entry: command completion
Date: Mon Apr 27 10:52:01 CEST 2009

Snot's current command completion is too slow.  Since I'm mostly
working with transparent repl now, it might be better to simply cache
all the symbols once, instead of requesting them every time..

Let's see.. maybe it can be optimized a bit.  There is also an error:
currently trying to complete "scat/" in the staapl/test-control.cc
module gives 

error in process filter: Lisp nesting exceeds `max-lisp-eval-depth'


Entry: unix socket
Date: Mon Apr 27 11:05:04 CEST 2009

I'm going to rewrite snot so it takes commands over a unix socket.
There's too much hassle in trying to prevent the standard output from
being polluted with protocol errors..


Entry: the socket
Date: Fri May  1 18:40:39 CEST 2009

let's see.

starting snot from the command line gives:

tom@zzz:~/snot$ mzscheme snot-load.ss
(snot-display "Loading ")
(snot-display "/home/tom/.snotrc")
(snot-display "\n")
(snot-display "toplevel ")
(snot-display "/home/tom/")
(snot-display "\n")

Now, (see snot-emacs-channel.el) to interact with it you send a
command like:

(eval (display 123))

Which returns:

(snot-display "123")

The main evaluator for snot is:



Let's start with setting up a listener on the unix socket /tmp/snot

Now.. How does the emacs side work?  I tried this before using
emacsclient to send atomic messages.  Why didn't this work?

Apparently it had trouble with large messages.

What about using temp files as reply mechanism?  This could use
'load-file' for evaluation.


Entry: blocking read
Date: 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.

so:
        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:

(read <buffer>)

on a restricted region

ha!

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."
  (goto-char (point-min))
  (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
incomplete buffer.


Entry: last correct
Date: Sat May  2 01:58:38 CEST 2009

snot-send-module sets the current environment in that can produce
command completions.  however, if it doesn't compile, it might be
interesting to fall back onto some part that does compile.


Entry: lexical variables
Date: Sat May  2 02:02:13 CEST 2009

to get at the lexical variables of an expression it might be
interesting to try to parser plt's toplevel forms.


Entry: polling frequency
Date: Sat May  2 02:17:40 CEST 2009

when data doesn't arrive immediately, we wait for a while to try
again.  this used to be a second, but that's too long.  currently set
to 100ms.

(defun snot-poll ()
  "Poll all processes. Used in `snot-wait-reply'."
  (accept-process-output 
   nil ;; (snot-process) 
   0 100))


Entry: doing stuff at emacs idle time
Date: Sat May  2 02:40:52 CEST 2009


(defun snot-start-idle ()
  (interactive)
  (run-with-idle-timer .1 t 'snot-display-info))
                       

Entry: thing-at-point
Date: Sat May  2 21:56:17 CEST 2009

http://www.emacswiki.org/emacs/ThingAtPoint

Means I can take my bric-a-brac out.

Hmm.. not really.  I need to wrap them with no-properties stuff
anyway, so might just as well stick to my own.  I did take out the
file with things that are not used. (substring*)


Entry: output throttling
Date: Tue May  5 14:06:43 CEST 2009

It seems that producing large amounts of output makes emacs behave
badly.  Let's bundle up and send periodically.

Ok, it sort of works.. (programming by trial and error..)

The problem is: the throttling needs to happen at the port side, not
the emacs-display side.



Entry: parsers
Date: Wed May  6 13:06:20 CEST 2009

(semi-)structured editing is about being able to parse (incomplete)
source code.  Is there a way to export a parser from PLT schemeso it
can be run in emacs?


Entry: separating out the channel again
Date: Mon May 11 18:47:02 CEST 2009

Maybe it's best to write a decent emacs channel application (using
slime-stile prefix protocol) based on socat running in a buffer.  This
is useful for other message-based things too.

Maybe I can just take it from slime?


Entry: slime
Date: Tue May 12 08:17:54 CEST 2009

* translate from/to lisp filename
* output presentations


Entry: emacs receiver
Date: Tue May 12 13:14:58 CEST 2009

The idea is to split off the message receiver from snot, so it can be
used in other applications as a remote repl.  Emacsclient sucks.

The thing I always forget is that a receiver that is able to handle
multiple clients needs to serialize the messages.  In the case of
elisp expressions this means multiple fd/buffer for multiple clients.
This is not what we'd want.  Ideally, the emacs side should just read
consecutive messages from a buffer process.



Entry: server.el
Date: Fri May 15 00:32:11 CEST 2009

Why didn't i think of this earlier?

Look at the server.el source code.  There you'll find all kinds of
goodies for listening to sockets.

Looks like connections are represented by processes with possibly a
buffer associated.  That's what we need.


Entry: emacsclient
Date: Sun May 17 20:25:58 CEST 2009

# emacsclient -e '(+ 1 2)'

Gives the following over the socket:

-eval (+&_1&_2) 

Apparently spaces get filled up so emacs can read the expression
without problems..

Let's try to build an alternative for message reception, using the
swank protocol.  First modify slime.el to log messages.



Entry: removing "run" and "restart".
Date: Sun Jul 12 11:04:50 CEST 2009

Because it's not used.


Entry: evaluator-break during instantiation
Date: Sun Jul 12 11:42:34 CEST 2009

Apparently evaluator-break doesn't work when instantiating a module.

Of course you can't!  I'm confusing two things here.  The evaluator
isn't yet defined so you can't send it anything..

What i want is to be able to break instantiation.

To: plt-scheme@list.cs.brown.edu

Hello,

Say you have a module which takes a while to instantiate using         
"make-module-evaluator" from scheme/sandbox.  How would you
make it possible to interrupt the instantiation?  Obviously
"kill-evaluator" or "break-evaluator" won't work yet since there is no
value to apply them to, and other attempts to kill it seem to fail:

(define e #f)
(define t 
  (thread 
   (lambda ()
     (set! e
           (make-module-evaluator
            '(module foo scheme/base (let x () (x))))))))

# (kill-thread t)
kill-thread: the current custodian does not solely manage the specified thread: #<thread>

This seems to leave the instantiation still running in the
background (judging from "top").

# (break-thread t) 


However, hitting ctrl-c when evaluating the following does seem to
stop the instantiation.

# (make-module-evaluator '(module foo scheme/base (let x () (x))))

This is in v4.2.0.5 [3m] from svn 15326 2009-06-29 09:50:11
Any ideas?

Cheers,
Tom



Entry: Emacs 23 : cursor problem
Date: Sat Apr  3 16:22:09 CEST 2010

For some reason, in emacs23 the cursor position doesn't update after
sending a command on the console.  I though I'd fix it by adding a
(goto-char (point-max)) in a particular place, but this doesn't seem
to carry from centeos to debian.

Another problem: output written to the stdout doesn't appear any more.
This might be because I'm using the wrong parameters though.


This thing is broken..  Many things happen that I can't explain.  It's
time for a clean solution.

FIXED: changing the following from `save-excursion' ->
`save-current-buffer' seems to do the trick.

(defun snot-display (thing)
  "Sends a string to the buffer, through the comint filter."
  (save-current-buffer
    (set-buffer snot-buffer)
    (comint-output-filter (snot-process) thing)))


Entry: Makefile broken in Racket 5.1
Date: Thu Jan 17 16:33:20 CET 2013

This worked:

tom@tx:~/snot$ planet link zwizwa snot.plt $(cat planet-version.txt) $(readlink -f snot)