Stefan Schmiedl wrote:
On Fri, 19 Jun 2009 14:11:23 +0200
Joachim Jaeckel <[email protected]> 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
_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
