Hi all
I'm playing with CMUCL and was wondering how to communicate with a running
lisp session from the command line prompt (linux)
The steps would be something like:
->Fire up lisp, get all the functions I'd like running.
->From the command line, on the same machine, pass lisp code to the lisp
session, and get results.
I'd like to separate the action of getting the lisp session up and running
from the actual calls to functions etc, since starting the session and
loading all my functions could, eventually be very expensive, compared to
the time lisp would take actually processing any requests I'd have.
something like
linux_prompt> lispmiddleman <them_options> (hello-world "ryan")
and I get the result back
hello ryan
Nil
... would be really helpful. <them_options> would be whatever's neccessary
to point the middleman to the process.
It'd allow me to use the system call functions in php scripts to get
non-trivial stuff done quickly, and start getting large chunks of our code
dependent on lisp, so I can, at some stage, migrate the entire system over
to lisp, and run all of our operations from one lambda function, the last
line of which reads.. )))))))) or something..
Thanks
Ryan
Ryan White wrote:
> Hi all
>
> I'm playing with CMUCL and was wondering how to communicate with a running
> lisp session from the command line prompt (linux)
>
> The steps would be something like:
>
> ->Fire up lisp, get all the functions I'd like running.
> ->From the command line, on the same machine, pass lisp code to the lisp
> session, and get results.
>
> I'd like to separate the action of getting the lisp session up and running
> from the actual calls to functions etc, since starting the session and
> loading all my functions could, eventually be very expensive, compared to
> the time lisp would take actually processing any requests I'd have.
>
> something like
>
> linux_prompt> lispmiddleman <them_options> (hello-world "ryan")
>
> and I get the result back
>
> hello ryan
> Nil
>
> ... would be really helpful. <them_options> would be whatever's neccessary
> to point the middleman to the process.
>
> It'd allow me to use the system call functions in php scripts to get
> non-trivial stuff done quickly, and start getting large chunks of our code
> dependent on lisp, so I can, at some stage, migrate the entire system over
> to lisp, and run all of our operations from one lambda function, the last
> line of which reads.. )))))))) or something..
>
> Thanks
> Ryan
For CMUCL you can try using this trick, which makes it act as a Lisp
server: [http://www.cons.org/cmucl/doc/lispserver.html].
For a more portable solution, you can check out the Swank part of
SLIME.
Regards,
Ivan
Ryan White <····@trigger.co.za> wrote:
+---------------
| I'm playing with CMUCL and was wondering how to communicate with a
| running lisp session from the command line prompt (linux)
...
| I'd like to separate the action of getting the lisp session up and
| running from the actual calls to functions etc, since starting the
| session and loading all my functions could, eventually be very expensive...
+---------------
It sounds like what you want to do is fire up a copy of CMUCL at login
time [or even at system boot time] as a persistent server, and then
have a small client program that talks to the "CMUCL server", passing it
requests and getting responses back. This is easily done with CMUCL
[and most other Common Lisps too, by the way], which contains support
or listening to sockets. To simplify things and avoid most security
issues[1], you'll probably want to use local-domain (a.k.a Unix-domain)
sockets, and hide the socket inside a directory[2] to which only you
(that is, processes running under your user ID) have access. In the
CMUCL case, the following functions will be useful:
EXTENSIONS:CREATE-UNIX-LISTENER
MP:PROCESS-WAIT-UNTIL-FD-USABLE [iff making your server multithreaded]
EXTENSIONS:ACCEPT-UNIX-CONNECTION
SYS:MAKE-FD-STREAM
Little-known fact: Recent versions of the standard "telnet" program
can connect to such sockets by specifying an absolute local pathname
instead of a hostname or IP address. So you should be able to test
your server this way:
$ echo '(expt 2 100)' | telnet $HOME/tmp/demo.sock
Trying /u/rpw3/tmp/demo.sock...
Escape character is '^]'.
1267650600228229401496703205376
Connection closed by foreign host.
$
-Rob
[1] You can certainly use TCP sockets, but then any system anywhere
might acess your Lisp process, so you'll need some kind of
authentication. Doing authentication securely can be very tricky.
Cleartext passwords can be snooped on the wire [and are clumsy
for you to use in your client program], but for an example of how
one might do it anyway, see the source for the CMUCL function
MULTIPROCESSING::START-LISP-CONNECTION-LISTENER.
[2] On some Unix-like operating system the permissions on a local-domain
socket special file are honored, but on others they are not -- any
process that can stat the socket can open it. For this reason, it's
safest to always place such socket special files under a directory
which permits access only to the desired user-ID or group-ID.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Bourguignon <····@mouse-potato.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > [1] You can certainly use TCP sockets, but then any system anywhere
| > might acess your Lisp process, so you'll need some kind of
| > authentication. ...
|
| You can listen only on 127.0.0.1, and therefore ignore any connection
| comming from other computers.
+---------------
True, but you still need to be careful if "your" computer is really
a shared server with other users on it [such as a web host].
And you also have to watch out for programs such as "ssh" which
support "tunneling" remote TCP connections to local 127.0.0.1 targets.
[Though on a truly single-user system this can also sometimes be a
*good* thing, as with X Windows forwarding, for example.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607