I have a little tool which allows me to have a CL server which hangs
around and which I can call from the Unix command line, passing it
basically an array of strings, the first of which identifies a handler,
and the rest of which are given to the handler as arguments. It also
gets told things like the host the call came from and the directory on
that host. It gets to pass back optional stdout string, stderr string
and exit code. The server side provides an API for registering
handlers, and the whole thing is multithreaded on the server (obviously
depending on the Lisp implementation for this).
It's trivial but very useful, to me anyway - it lets me, for instance,
call our Lisp document processing system from Makefiles.
Unfortunately it uses CORBA for the communications, so relies on CL
CORBA bindings & hence enterprise Lisp implementations which is a
market I'm no longer in, and the client side (which is trivial, using
the Unix command line as args) relies on the Lisp implementation being
able to generate executables with very small start-up time (LW in
fact).
I need to reimplement this for some free CL (my current probable choice
being SBCL, because it seems reasonable and runs all the places I want
it to).
Is there a good framework for this - I really don't want to have to
cook one up myself - doing all the on-the-wire encoding would be a
pain. Preferably it should be simple (so I think not SOAP, and
definitely not CORBA unless the bindings are 100% compatible with the
standard ones) and ideally not Lisp-specific. Simple is most important
- if it takes me a long time to make work it just won't happen.
My two current thoughts are:
XML-RPC. I've used this before, and it looks OK. Client could be in
Perl, Python, whatever.
Something involving sexps. This would be even simpler, but would
realistically require a CL client, and so would only work if the
implementation I choose has a startup time of less than .1 s and is
amenable to being used from the Unix command line.
But I'm open to other suggestions.
Thanks
--tim
Tim Bradshaw wrote:
> XML-RPC. I've used this before, and it looks OK. Client could be in
> Perl, Python, whatever.
>
> Something involving sexps. This would be even simpler, but would
> realistically require a CL client, and so would only work if the
> implementation I choose has a startup time of less than .1 s and is
> amenable to being used from the Unix command line.
Not quite sure what you're asking for. If you're asking for something
that can do serialization, then cl-store works very well and I've used
it on both ends of a remote eval server (using plain sockets). This
would require that both sides be CL, of course.
http://common-lisp.net/project/cl-store/
Another alternative would be implementing a remote repl and sending
sexpr strings. Here's one for OpenMCL that when I looked at it last,
shouldn't be too hard to port for SBCL:
http://homepage.mac.com/svc/openmcl/readme.html
The CL implementation of XML-RPC is here:
http://common-lisp.net/project/s-xml-rpc/
As far as startup time for sbcl, dump a core with everything in it and
specify it on the sbcl command line. Start up time is super fast. You
can also dump it as a standalone executable as well. Details:
http://www.sbcl.org/manual/Saving-a-Core-Image.html
Hope one of these is what you're looking for.
Glenn
·············@specastro.com wrote:
>
> Not quite sure what you're asking for. If you're asking for something
> that can do serialization, then cl-store works very well and I've used
> it on both ends of a remote eval server (using plain sockets). This
> would require that both sides be CL, of course.
Well, you need some kind of serialisation, yes, because you don't know
what's in the strings you want to pass, so you need to encode them
somehow. Given that I *only* want to pass strings, it's probably easy
enough to write something which will encode them so that READ can deal
with them if I avoid thiking too much about Unicode (look for " chars
in the strings etc..).
> Another alternative would be implementing a remote repl and sending
> sexpr strings. Here's one for OpenMCL that when I looked at it last,
> shouldn't be too hard to port for SBCL:
That's sort of what I meant by `passing sexps' though you want the far
end not to be a REPL, as that's too dangerous. The client then just
has to make sure that the strings are OK as above.
>
> As far as startup time for sbcl, dump a core with everything in it and
> specify it on the sbcl command line. Start up time is super fast. You
> can also dump it as a standalone executable as well. Details:
>
> http://www.sbcl.org/manual/Saving-a-Core-Image.html
I tried this on a 1.5GHz PPC Mac, with something like:
(sb-ext:save-lisp-and-die "ts" :executable t :toplevel #'(lambda (&rest
args) (declare (ignore args))))
(in fact I defined & compiled the toplevel fn just in case). End to
end time was just over 3 secs, which is 30 to 100 times too slow -
Imagine this being called 100 times from a Makefile, say. (For
comparison the Java equivalent is about 0.8 sec on the same machine,
Perl is 0.05 sec). May be there is some cleverness I'm missing, but I
suspect the client side needs to be not Lisp.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> ·············@specastro.com wrote:
>
> > Another alternative would be implementing a remote repl and sending
> > sexpr strings. Here's one for OpenMCL that when I looked at it last,
> > shouldn't be too hard to port for SBCL:
>
> That's sort of what I meant by `passing sexps' though you want the far
> end not to be a REPL, as that's too dangerous. The client then just
> has to make sure that the strings are OK as above.
I have a home-rolled format for simple serialization that's easy to
implement in just about any language. If all you want to send is
strings, it'd be dead-simple. For strings, something like:
number of strings in this message<RET>
string-length<RET>
the contents of the string (ie, STRING-LENGTH characters)<RET>
...
All the returns in there are helpful with language implementations for
which you don't necessarily trust their buffer flushing to be correct.
> > As far as startup time for sbcl, dump a core with everything in it and
> > specify it on the sbcl command line. Start up time is super fast. You
> > can also dump it as a standalone executable as well. Details:
> >
> > http://www.sbcl.org/manual/Saving-a-Core-Image.html
>
> I tried this on a 1.5GHz PPC Mac, with something like:
>
> (sb-ext:save-lisp-and-die "ts" :executable t :toplevel #'(lambda (&rest
> args) (declare (ignore args))))
>
> (in fact I defined & compiled the toplevel fn just in case). End to
> end time was just over 3 secs, which is 30 to 100 times too slow -
> Imagine this being called 100 times from a Makefile, say. (For
> comparison the Java equivalent is about 0.8 sec on the same machine,
> Perl is 0.05 sec). May be there is some cleverness I'm missing, but I
> suspect the client side needs to be not Lisp.
Did you try a second time? On a 750 MHz UltraSPARC, I get startup
times of 0.09s once the core has been pulled over from the NFS filer.
On a 3 GHz Pentium, it's 0.01s. A local disk won't be as extreme as
an NFS-mounted share, but it will still make a difference. Also, make
sure you aren't reading the system- and user-init files. I think
there's a way to save command-line options in the single-file
executable now. The options you want are:
--noinform --sysinit /dev/null --userinit /dev/null
and maybe --disable-debugger as well.
Thomas F. Burdick wrote:
> I have a home-rolled format for simple serialization that's easy to
> implement in just about any language. If all you want to send is
> strings, it'd be dead-simple. For strings, something like:
>
> number of strings in this message<RET>
> string-length<RET>
> the contents of the string (ie, STRING-LENGTH characters)<RET>
Yes, I'd thought of something like that (which is why I specified `not
thinking too hard about unicode :-), but I kind of wanted to not roll
my own if I could avoid it.
> Did you try a second time? On a 750 MHz UltraSPARC, I get startup
> times of 0.09s once the core has been pulled over from the NFS filer.
> On a 3 GHz Pentium, it's 0.01s.
Yes, averaged over the last 10 of 20 runs, on local disk. maybe it is
reading startup files, as the times you have sound fine to me.
--tim