Re: Guile bugs

[Linas Vepstas]

Hi Ludo,

Perhaps I was too brief in my remarks. By a networked REPL, I meant this:

https://www.gnu.org/software/guile/manual/html_node/REPL-Servers.html

For accidental, historical reasons, (i.e. I did not know the above existed)
I wrote my own variant, which accepts network connections, handles guile in
full, including the printing of exception frames, handles async printing to
stdio (i.e. to the network connection) so that long-running functions can
print, and the user can see that output, unbuffered.   Its full
multi-threaded, uses a pool of threads pre-initialized in guile, hot and
ready to go, to avoid the overhead of initializing and entering guile.  Its
fast, robust, it works.

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().

As mentioned, this customized blob of code is easily 3x or 5x faster
than (use-modules (system repl server)), and also more  robust ...
sometimes (system repl server) seems to lock up or hang or something, I
have not delved into it.

One of my complaints is that the C strings sent to scm_eval_string() go
through some pointless layers that convert utf8 to utf32, and then back
again. I do not recall the details. There are some obvious optimizations
that can be performed. Its more than an afternoon or two but less than a
week or two.  I am not motivated to submit patches, as I fear these will
just provoke arguments and be rejected.

The custom guile network repl server can be viewed at the URL's below. To
preserve your sanity, you probably don't want to study it.  But in the
spirit of open source, here it is:

https://github.com/opencog/atomspace/blob/master/opencog/guile/SchemeEval.cc

The network REPL shell is here:
https://github.com/opencog/opencog/blob/master/opencog/cogserver/shell/GenericShell.cc

we've layered both guile and python on it.  Python is annoying because
executing python from repl behaves differently than executing python from a
file. Not my fault; its built into the python language definition. Idiots.

--linas





On Sun, Sep 10, 2017 at 8:11 AM, Ludovic Courtès <address@hidden> wrote:

> Hi,
>
> Linas Vepstas <address@hidden> skribis:
>
> > 1) There is a need to pass messages between subsystems running on
> different
> > machines.
> >
> > 2) Solutions include ROS, ZeroMQ,  google protocol buffers... whatever.
> All
> > require lots of work, a learning curve, complexity, etc.
> >
> > 3) Wait!  I know! I will just send around ascii (utf8) strings that are
> > guile programs!  Just use the guile repl server, connect to it, and send
> > some guile string!  No muss, no fuss, no coding, no learning curve,
> simple
> > easy ...  You can use netcat to drive things!  echo (display "hello
> > world\n") | nc 1.2.3.4 37146
>
> Then you’re sending sexps, not strings, and you’re reading them with
> ‘read’ from a port, as opposed to loading whole strings in memory.
>
> Also, the REPL server is not necessarily the right thing here.  You
> conceptually want a REPL, but not Guile’s full-blown REPL, which can be
> hard to deal with (you need to parse the prompts, determine if you’re in
> a recursive REPL, whether an exception occurred, etc.)
>
> In the Shepherd, I implemented a very simple REPL that is just enough to
> communicate evaluation results to the client, and to distinguish return
> values from exceptions.  This does not use Guile’s REPL server, only
> ‘read’, ‘eval’, ‘write’.
>
> HTH,
> Ludo’.
>



-- 
*"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." *