Re: [Help-smalltalk] gst-remote architecture

[Paolo Bonzini]

Stefan Schmiedl wrote:
> On Fri, 19 Jun 2009 14:11:23 +0200
> Joachim Jaeckel <address@hidden> wrote:
>
> > > A bug in gst-remote? ;-)
> > Oh... *sad* I was sooooo happy, that gst-remote was running on my 
> > computer after your described patch for amd64.
>
> I can make a ruby script remote-able by including the
> drb-library and starting the server. Is it possible for
> gst to take the same approach, i.e. _just_ file in some 
> Smalltalk code?
>
> Why do we need a dedicated gst-remote binary?

No, we don't.  The body of gst-remote is installed in 
/usr/share/smalltalk/scripts/Remote.st and it is, in some sense, the 
moral equivalent of the drb server and library.  It would be possible 
and easy to move the gst-remote client to a package so that other 
scripts could act as gst-remote clients.

Note however that drb is not a REPL.  It is more than a REPL in that it 
provides distributed objects.  But if I understand correctly it is also 
less than a REPL in that you would need anyway to write the logic to 
read evals on the client (from the command line) and a server object to 
capture stdout and send it back to the client.

I had written a long blurb on gst-remote before writing the above 
answer.  It didn't really answer your question but I think it is 
interesting anyway, so here it is.

The gst-* binaries (gst-load, gst-sunit, gst-remote, gst-doc, gst-blox, 
etc.) are actually all compiled from the same source, gst-tool.c, and 
actually they are all hard links to the same executable; they call a 
Smalltalk script in /usr/share/smalltalk/scripts depending on argv[0]. 
I'll call the binaries gst-tool in the rest of this message.

gst and gst-tool are the two clients of libgst.so in the standard 
distribution of GNU Smalltalk.  They only differ in the handling of 
command-line options; their source code is in main.c for gst and in 
gst-tool.c for gst-tool.

There are two reasons for gst-tool's existence.

The first is that most of the gst-* tools care a lot about what image 
they are loaded in.  For example, gst-remote does not care much about it 
when loaded as a client, but it obviously does when loaded as a server. 
 For gst-blox, gst-load and gst-sunit, it would not make sense at all 
to not have a -I option.  The -I option however must be processed before 
the Smalltalk script is started, so you cannot just use a "#! 
/usr/bin/gst -f" line.  Before the gst-tool binary was born, the parsing 
of the command-line to separate -I arguments was done with a shell script.

Nowadays, the gst-tool binary does a few more things: it implements 
--daemon, and it passes a few of configure's results to the scripts so 
that the Smalltalk code can be used with no modification on different 
platforms.

The second is that this makes it much easier to deploy Smalltalk scripts 
on native Windows, which does not support #! lines.  On native Windows, 
a Smalltalk script would anyway need a small stub executable that 
started it.  This is especially important for gst-blox, which is a 
"real" application that someone may want to link on the desktop or start 
menu, rather than invoke from a Cygwin or MSYS shell.

There is a third reason too, though it is more of an historical 
background.  Until GNU Smalltalk 3.0 the interface of libgst.so was a 
bit fake; main.c was little more than this:

  int
  main(int argc, const char **argv)
  {
    int result;
    gst_smalltalk_args(argc, argv);
    result = gst_init_smalltalk();
    if (result == 0)
      gst_top_level_loop();

    exit(result <= 0 ? 0 : result);
  }

and the parsing of command-line options was entirely in libgst/lib.c.  I 
wanted to get rid of this and have a real library interface, and I 
needed a use case to test the library interface.  Of course, some 
coverage came from moving command-line option parsing was moved from 
libgst/lib.c (now libgst/files.c) to main.c, but it would have been nice 
to see if the interface was okay for a simpler client that only needed a 
handful of settings.  Given how messy the gst-* shell scripts were, 
gst-tool was born as an alternative client to clean up the mess and to 
see if the new library interface could do the task.

Ciao,

Paolo