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
>

Reply via email to