> server, and I have discovered that PicoLisp (at least the 32-bit),
> behaves a little different from other "applications" (incl. bash and
> websocketd --port=8080 -devconsole pil
> (You get cleaner results back from PicoLisp if you don't add the "+"
> after "pil".)
> ersatz/pil and other "applications", is that if you click the
> disconnect button, then pil32 is not terminated. On my Mac it
> instead starts using close to 100% CPU, and I have to kill it
> manually. If I, instead of clicking disconnect, type "(bye)", then
> PicoLisp terminates and I get a 'disconnect'.
I haven't tried exactly this example, but I think I can explain the
The runtime behavior of PicoLisp differs from other applications in that
it evaluates all command-line arguments, and then goes into an infinite
loop (REPL). This means specifically that (bye) must be called
eventually. In debug mode, the REPL line editor takes care of that, by
calling (bye) when Ctrl-D is hit.
Perhaps it is a bug that EOF on STDIN is not handled more gracefully,
and I'm not sure at the moment what it would involve.
"Barebone" stdio-programs like bash, ersatzLisp, but also e.g.
miniPicoLisp terminate despite of that, because they don't set up a
special handler for the console.
In any case, scripts like yours
> #!/usr/bin/picolisp /usr/lib/picolisp/lib.l
> (load "@lib/misc.l")
> (in NIL
> (use (Exe Res)
> (until (eof)
> (setq Exe (read))
> (prin "-> ")
> (setq Res
> (let @ Res
> (eval Exe) ) ) )
> (flush) ) ) )
should always call (bye) in the end (i.e. after 'until' or the enclosing
> Something else is that output that goes to STDERR, does not show up
> in the browser (it ends up in the websocketd log), and I guess that
> is why I don't see any response if I type something like "(foo)",
> where 'foo' is undefined. Can output to STDERR in an easy way be
> redirected to STDOUT in a REPL script?
Yes, this should be doable with (err NIL ...)