Re: Guile bugs

[Linas Vepstas <linasvepstas@gmail.com>]

On Mon, Sep 11, 2017 at 2:26 AM, Ludovic Courtès <ludo@gnu.org> wrote:

> Hello,
>
> Linas Vepstas <linasvepstas@gmail.com> skribis:
>
> > The stuff coming over the network sockets are bytes, not s-exps. Since
> none
> > of the bytes are ever zero, they are effectively C/C++ strings, and are
> > handled as such. These C strings are sent to  scm_eval_string() wrapped
> > by scm_c_catch().
>
> I don’t know to what extent that is applicable to your software, but my
> recommendation would be to treat that network socket as a Scheme port,
> pass it to ‘read’, and pass the result to ‘eval’ (as opposed to reading
> the whole string from C++ and passing it to ‘scm_eval_string’.)
>

Why?  What advantage does this offer?

Its not clear that guile eval is smart enough to manage a network socket --
if the user starts a long-running process with intermittent prints, will it
send that to the socket?  What if the user hits cntrl-C in the middle of it
all? What if the code that came over the socket happened to throw an
exception?

I've had to deal with all of these issues in the past, and have a stable
code base; but if I had to start all over again, its not clear that these
issues have gone away.  I mean, eval was designed to eval -- it was not
designed to support multi-threaded, concurrent network operations, right?

To support my point: the default guile network REPL server is painfully
slow, and frequently crashes/hangs. It works well enough to do some demos
but is not stable enough for production use ... if its just read+eval, that
might explain why its unstable.

--linas

-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *