[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] gst-remote architecture

From: Paolo Bonzini
Subject: Re: [Help-smalltalk] gst-remote architecture
Date: Fri, 19 Jun 2009 15:04:20 +0200
User-agent: Thunderbird (X11/20081009)

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/ 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 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 was a bit fake; main.c was little more than this:

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

    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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]