Hi Rick, Thanks a lot for making me aware of that implementation by José I. Romero! I have to give it a try (when I find some time)
And thanks to Alex for explaining the matter re. PicoLisp and Ctrl-D. /Jon > Jon, > > Have you tried this: > > https://bitbucket.org/cyborgar/web.l/src/249fe9f5c7d8/web/sockets.l > > -rl > > > > On Tue, Dec 31, 2013 at 10:02 AM, Alexander Burger > <a...@software-lab.de>wrote: > >> Hi Jon, >> >> > server, and I have discovered that PicoLisp (at least the 32-bit), >> > behaves a little different from other "applications" (incl. bash and >> > ersatz/pil). >> > ... >> > 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 >> behavior. >> >> 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 "-> ") >> > (println >> > (setq Res >> > (let @ Res >> > (eval Exe) ) ) ) >> > (flush) ) ) ) >> >> should always call (bye) in the end (i.e. after 'until' or the enclosing >> 'in' terminated). >> >> >> >> > 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 ...) >> >> ?? Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
