Hello!
Maybe this is kind of a stupid question to ask, but I was
wondering if it is possible to run Lisp in the background and
have it run scripts. What I'm thinking of is something like
(server-start) in Emacs, which lets me run emacsclient. It
would be nice if I could do something like this:
#!/path/to/lispclient
(do-something)
dhl
On May 12, 5:58 pm, Daniel Leidisch <····@leidisch.net> wrote:
> Maybe this is kind of a stupid question to ask, but I was
> wondering if it is possible to run Lisp in the background and
> have it run scripts. What I'm thinking of is something like
> (server-start) in Emacs, which lets me run emacsclient. It
> would be nice if I could do something like this:
I had once written a small utility[1] for that purpose. It brings an
init.d script that fires up a swank instance in a GNU screen session.
(You can easily configure the lisp commands that you want it to run at
start-up by editing the script file.) GNU screen gives you a full
control over the deamonized lisp instance, and you can connect to the
session at any time.
BTW, you may want to check detachtty[2] or how do ucw[3] guys solve
this problem.
Regards.
[1] http://www.students.itu.edu.tr/~yazicivo/files/swank-daemon.tar.gz
[2] http://www.cliki.net/detachtty
[3] http://www.cliki.net/UCW
Thus spoke vy <·············@gmail.com>:
> I had once written a small utility[1] for that purpose. It brings an
> init.d script that fires up a swank instance in a GNU screen session.
> (You can easily configure the lisp commands that you want it to run at
> start-up by editing the script file.) GNU screen gives you a full
> control over the deamonized lisp instance, and you can connect to the
> session at any time.
>
> BTW, you may want to check detachtty[2] or how do ucw[3] guys solve
> this problem.
I've downloaded swank-demon and tried it. I think I'll have to read
up on SWANK in order to use it. Unfortunately my Distribution uses
BSD-style initscripts, so I can't use it out of the box.
Anyway, I tried to run swank.sh by hand, which (after some fiddling)
gave me a listening swank server at port 5004, but I don't know
how to use it for my scripts, which makes me feel really stupid. ;)
Thanx
dhl
> Regards.
>
> [1] http://www.students.itu.edu.tr/~yazicivo/files/swank-daemon.tar.gz
> [2] http://www.cliki.net/detachtty
> [3] http://www.cliki.net/UCW
>
On May 12, 10:49 pm, Daniel Leidisch <····@leidisch.net> wrote:
> I've downloaded swank-demon and tried it. I think I'll have to read
> up on SWANK in order to use it. Unfortunately my Distribution uses
> BSD-style initscripts, so I can't use it out of the box.
>
> Anyway, I tried to run swank.sh by hand, which (after some fiddling)
> gave me a listening swank server at port 5004, but I don't know
> how to use it for my scripts, which makes me feel really stupid. ;)
Just append your commands (e.g. (load "/path/to/foo.lisp")) to swank-
start.lisp initialization file.
Regards.
Some entity, AKA Daniel Leidisch <····@leidisch.net>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Maybe this is kind of a stupid question to ask, but I was
> wondering if it is possible to run Lisp in the background and
> have it run scripts. What I'm thinking of is something like
> (server-start) in Emacs, which lets me run emacsclient. It
> would be nice if I could do something like this:
> #!/path/to/lispclient
> (do-something)
It exists, look what slime (swank) does in emacs,
it start a lisp and opens a listener-socket.
mod-lisp does something like that for the apache http-server.
Many Cl-implementations do have 'servers' included.
You can even use Clisp as a login-shell.
But it all depends on what you want to accomplish.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
The biggest problem LISP has, is that it does not appeal to dumb people
If that failed to satisfy you start reading the HyperSpec or woman frig
mailpolicy @ http://www.clsnet.nl/mail.html
Thus spoke Cor Gest <···@clsnet.nl>:
> Some entity, AKA Daniel Leidisch <····@leidisch.net>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
>> Maybe this is kind of a stupid question to ask, but I was
>> wondering if it is possible to run Lisp in the background and
>> have it run scripts. What I'm thinking of is something like
>> (server-start) in Emacs, which lets me run emacsclient. It
>> would be nice if I could do something like this:
>> #!/path/to/lispclient
>> (do-something)
>
> It exists, look what slime (swank) does in emacs,
> it start a lisp and opens a listener-socket.
> mod-lisp does something like that for the apache http-server.
> Many Cl-implementations do have 'servers' included.
> You can even use Clisp as a login-shell.
> But it all depends on what you want to accomplish.
I'm just looking for the easiest solution for writing Lisp-scripts
that connect to a Lisp running in the background. My problem is,
that, lacking experience, I don't know where to start. Should I
have a look at swank, or read up the documentation of different
implementations? If yes, then which one?
I do most of my stuff in SBCL, but I found clisp convenient for
scripting, as it allows Shebang-lines out of the box. Since I
want to use cl-ppcre (because it's implementation-independent),
my scripts take very long to start up -- annoyingly long.
So my favorite solution would be using SBCL, running in the
background, and then connect to it to execute my Script.
Maybe someone knows a (newbie-friendly) way to accomplish this --
or some other method for executing Scripts without having to wait
~8 seconds.
Maybe it's generally an unlispy thing to run Shebanged Scripts
in Lisp? I don't know...
dhl
>
> Cor
>
>
Daniel Leidisch <····@leidisch.net> writes:
> I'm just looking for the easiest solution for writing Lisp-scripts
> that connect to a Lisp running in the background.
Just to clarify: I don't use the "#!..." syntax a lot, but my
understanding [someone correct me if I'm wrong here please] is that
naming a script in that way doesn't mean "connecting to a program
running in background" but rather "naming a program that you want to
launch each and every time you invoke the script." Doing that with a
Lisp presumably means that every time you run the script, you start a
new lisp, load all of your program support, and then execute the one
task, then shut down the lisp.
Some Lisps will do exactly what you ask, but not all will, and of
those I doubt that all of them would say that the most efficient thing
you can do is that. Not only does Lisp have to load but it has to
load your code that will execute the script, the speed of which will
vary widely between implementations depending on more details than I
have time to enumerate.
What one often does for serious work is instead to launch a Lisp that
stays running and listens on a port for connections from something
else--often either a continuously running client that doesn't have to
start every time (e.g., like a browser, which you also don't invoke
each time you want a page, but which you start once and then submit
many requests from) or from some other lightweight script.
But when you use the magic words "the easiest solution", the answers
you probably get will ignore many such options because you've focused
on ease as your primary result. And if you're doing a light number of
requests on a machine that can easily handle it, it's possible that's
just exactly what you'll want and like.
But beware if you later start to mutter that "lisp is slow" that it
may not be lisp, but rather than you have asked for a solution that
optimizes ease, not speed. Lisp, more than other languages, has quite
a range of choices that trade speed for flexibility and vice versa.
You might get a very different answer if you ask for a way of writing
scripts in a way that is efficient.
+ Kent M Pitman <······@nhplace.com>:
| Daniel Leidisch <····@leidisch.net> writes:
|
|> I'm just looking for the easiest solution for writing Lisp-scripts
|> that connect to a Lisp running in the background.
|
| Just to clarify: I don't use the "#!..." syntax a lot, but my
| understanding [someone correct me if I'm wrong here please] is that
| naming a script in that way doesn't mean "connecting to a program
| running in background" but rather "naming a program that you want to
| launch each and every time you invoke the script."
You're correct of course, but nothing stops the shebang line from
specifying a fairly lightweight program that will connect to a Lisp
running in the background (perhaps optionally starting one if one
isn't already running), feeding the script to that lisp, and printing
the result on stdout.
That way, you can have your cake and eat it too: The background Lisp
can be long-lived and loaded full of all sorts of libraries for the
shebang scripts to rely on (with asdf loading missing stuff on
demand), combined with the easy convenience of the unix command line.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Thus spoke Harald Hanche-Olsen <······@math.ntnu.no>:
> You're correct of course, but nothing stops the shebang line from
> specifying a fairly lightweight program that will connect to a Lisp
> running in the background (perhaps optionally starting one if one
> isn't already running), feeding the script to that lisp, and printing
> the result on stdout.
>
> That way, you can have your cake and eat it too: The background Lisp
> can be long-lived and loaded full of all sorts of libraries for the
> shebang scripts to rely on (with asdf loading missing stuff on
> demand), combined with the easy convenience of the unix command line.
Yes, that's exactly what I was looking for. Do you know about such a
program or script?
Regards,
dhl
+ Daniel Leidisch <····@leidisch.net>:
| Thus spoke Harald Hanche-Olsen <······@math.ntnu.no>:
|> You're correct of course, but nothing stops the shebang line from
|> specifying a fairly lightweight program that will connect to a Lisp
|> running in the background (perhaps optionally starting one if one
|> isn't already running), feeding the script to that lisp, and printing
|> the result on stdout. [...]
|
| Yes, that's exactly what I was looking for. Do you know about such a
| program or script?
Nope. If I did, my choice of words would probably have been
different. I don't think it would be terribly difficult to write such
a thing, though. The protocol would be quite simple, provided you're
not trying to establish any sort of interaction with the lisp image.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Thus spoke Kent M Pitman <······@nhplace.com>:
> Daniel Leidisch <····@leidisch.net> writes:
>
>> I'm just looking for the easiest solution for writing Lisp-scripts
>> that connect to a Lisp running in the background.
>
> Just to clarify: I don't use the "#!..." syntax a lot, but my
> understanding [someone correct me if I'm wrong here please] is that
> naming a script in that way doesn't mean "connecting to a program
> running in background" but rather "naming a program that you want to
> launch each and every time you invoke the script." Doing that with a
> Lisp presumably means that every time you run the script, you start a
> new lisp, load all of your program support, and then execute the one
> task, then shut down the lisp.
Yes, I'm aware that #!/path/to/lisp starts a new Lisp process, my
question was, if it's possible to have something like a shebang-line
which would make my script connect to a running Lisp process.
So I was asking myself, if it is possible to "#!/path/to/lispclient",
where lispclient would be some program or script which would
execute my script in an already running Lisp session, in order to
avoid having to start a new Lisp instance every time I want to run
a little script from the command line. (Some kind of "launcher"
which would work similar to running "emacsclient <file>" to edit
a file in Emacs without having to start a new Emacs process)
> Some Lisps will do exactly what you ask, but not all will, and of
> those I doubt that all of them would say that the most efficient thing
> you can do is that. Not only does Lisp have to load but it has to
> load your code that will execute the script, the speed of which will
> vary widely between implementations depending on more details than I
> have time to enumerate.
Yes, that's exactly what I want to avoid. (restarting over and
over).
> What one often does for serious work is instead to launch a Lisp that
> stays running and listens on a port for connections from something
> else--often either a continuously running client that doesn't have to
> start every time (e.g., like a browser, which you also don't invoke
> each time you want a page, but which you start once and then submit
> many requests from) or from some other lightweight script.
>
> But when you use the magic words "the easiest solution", the answers
> you probably get will ignore many such options because you've focused
> on ease as your primary result. And if you're doing a light number of
> requests on a machine that can easily handle it, it's possible that's
> just exactly what you'll want and like.
I don't think that what I'm doing at the moment could be considered
"serious work". I'm just trying to learn some Lisp, and I am not
a professional.
The reason that I'm asking for "the easiest solution" is, that I
probably couldn't handle a more complex one at my current standard
of knowledge. I've read some online tutorials and PCL, and I like to
program in Lisp more than any language I've tried, but I am looking
for a way to use my scripts or programs from the command line.
So there are two possibilities: I could go on writing scripts with
a usual shebang-line (which is inefficient) until I feel myself
ready for a "real" solution or ask for some kind of tool which I
can use /now/.
Since I'm the "learning-by-doing" kind of person, and would like
to code something I can actually use, I asked for the latter.
> But beware if you later start to mutter that "lisp is slow" that it
> may not be lisp, but rather than you have asked for a solution that
> optimizes ease, not speed. Lisp, more than other languages, has quite
> a range of choices that trade speed for flexibility and vice versa.
> You might get a very different answer if you ask for a way of writing
> scripts in a way that is efficient.
You see, the reason I asked was that I'm aware that the method I'm
currently using is slow and inefficient. ;)
Regards,
dhl
Daniel Leidisch <····@leidisch.net> writes:
> The reason that I'm asking for "the easiest solution" is, that I
> probably couldn't handle a more complex one at my current standard
> of knowledge. I've read some online tutorials and PCL, and I like to
> program in Lisp more than any language I've tried, but I am looking
> for a way to use my scripts or programs from the command line.
>
> So there are two possibilities: I could go on writing scripts with
> a usual shebang-line (which is inefficient) until I feel myself
> ready for a "real" solution or ask for some kind of tool which I
> can use /now/.
>
> Since I'm the "learning-by-doing" kind of person, and would like
> to code something I can actually use, I asked for the latter.
Hi Daniel,
I may not understand your problem fully, but if what you are doing
doesn't require command line scripts per se and you are just looking
for an environment for learning Lisp, have you tried Emacs+SLIME? It
is wonderful for learning the language, SLIME gives hints on function
arguments etc.
Best,
Tamas
--
Posted via a free Usenet account from http://www.teranews.com
Thus spoke Tamas Papp <······@gmail.com>:
> I may not understand your problem fully, but if what you are doing
> doesn't require command line scripts per se and you are just looking
> for an environment for learning Lisp, have you tried Emacs+SLIME? It
> is wonderful for learning the language, SLIME gives hints on function
> arguments etc.
Thanks for the tip, but I have been using SLIME for some time now.
You're right, it's a great tool. My question was just about Scripting,
since I want to make the transition from mere exploration to producing
something useful (even if it's just some scripts for now).
Regards,
dhl
> Best,
>
> Tamas
>
Daniel Leidisch <····@leidisch.net> writes:
> Yes, I'm aware that #!/path/to/lisp starts a new Lisp process, my
> question was, if it's possible to have something like a shebang-line
> which would make my script connect to a running Lisp process.
In computers anything is possible (as long as you have enough memory
and time). Connecting to a server is hardly a memory or time problem,
is it's definitely possible.
How would you do it? (This has nothing to do with lisp).
> I don't think that what I'm doing at the moment could be considered
> "serious work". I'm just trying to learn some Lisp, and I am not
> a professional.
Yes, if you want to do it in lisp, learning some lisp is a good idea...
> The reason that I'm asking for "the easiest solution" is, that I
> probably couldn't handle a more complex one at my current standard
> of knowledge. I've read some online tutorials and PCL, and I like to
> program in Lisp more than any language I've tried, but I am looking
> for a way to use my scripts or programs from the command line.
What do you know?
There are several ways to do IPC, (Inter Process Communications). The
most basic one, which is always available and can be implemented even
in the standard Common Lisp (therefore needing only the most basic
knowledge of lisp (or any other programming language)) is to go thru
the file system: the client stores a file somewhere, the server reads
the files, and stores the answer in some other file, which the client
reads and display.
> Since I'm the "learning-by-doing" kind of person, and would like
> to code something I can actually use, I asked for the latter.
So, let's say that you write a little interpreter that takes its
script and put it into a file in a spool directory and waits for some
result file to display. And you write a little server that takes
these files in the spool directory, loads them and writes the result
to a result file in the spool directory.
Note that there is a little trick: we don't want the reader to read
the file before it's been entirely written. We can do it easily by
writing a "job ticket" file.
Let's say you write the script files in
/var/spool/lisp-server/input/XXXXXXX.lisp
once such a file is written, you create a job ticket file:
/var/spool/lisp-server/input/XXXXXXX.job
The server searches for .job files and when it finds one, it deletes
it, and loads the corresponding .lisp file, writting the results to:
/var/spool/lisp-server/output/XXXXXXX.stdout
/var/spool/lisp-server/output/XXXXXXX.stderr
(more output streams could be used, for example, for *trace-output*, etc).
When done, it creates the job ticket file:
/var/spool/lisp-server/output/XXXXXXX.job
When the "interpreter" sees this .job file, it would dump the .stdout
file to standard output and .stderr to standard error.
Since you're a "learning-by-doing" guy, I won't do it for you...
But there is one other difficulty: scripts cannot be interpreters for
other scripts, so for your interpreter, you want a binary executable.
You can generate such an executable with most Common Lisp
implementations, but how it's done is implementation dependant.
And finally, if you did all that to launch your scripts faster, compare:
- running a simple script like:
#!/usr/bin/clisp
(print "hello")
involves:
fork, exec(/usr/bin/clisp), read, interpret the script, write
- running a simple script thru a lisp server as:
#!/usr/local/bin/lisp-client
(print "hello")
now involves:
In the client: In the server:
fork, loop: opendir readdir closedir
exec(/usr/local/bin/lisp-client), until found a job ticket
read, unlink
open, write, close, creat open, open, read,
loop: open interpret the script
until found the job ticket write, close, close, creat
unlink
read, write, close, unlink
I wouldn't bet on that to be faster, even if you'd use sockets or
shared memory to communicate between the client and the server...
>> But beware if you later start to mutter that "lisp is slow" that it
>> may not be lisp, but rather than you have asked for a solution that
>> optimizes ease, not speed. Lisp, more than other languages, has quite
>> a range of choices that trade speed for flexibility and vice versa.
>> You might get a very different answer if you ask for a way of writing
>> scripts in a way that is efficient.
>
> You see, the reason I asked was that I'm aware that the method I'm
> currently using is slow and inefficient. ;)
Last time I benchmarked it, printing "Hello World" from perl scripts,
emacs, sbcl, or clisp scripts, clisp was the fastest. I've heard
some reports that recent perl is slightly faster to start up.
Anyways, it's a difference you cannot notice, if you are a human.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Thus spoke Pascal Bourguignon <···@informatimago.com>:
> In computers anything is possible (as long as you have enough memory
> and time). Connecting to a server is hardly a memory or time problem,
> is it's definitely possible.
>
> How would you do it? (This has nothing to do with lisp).
Did you read my other posts in this thread? I am neither a
professional programmer nor a CS student. I have no idea how to
implement such a thing in any language and I made no bones about
that. Maybe it's due to my being a non native speaker that you
didn't get that.
My whole problem was, that I didn't know that one should save a core
file in order to avoid the long startup time. Richard M. Kreuter
was so kind as to explain that to me in detail and that solved
my problem.
Since I didn't know about that, I asked for the "emacsclient-like"
solution. If I may quote my first sentence in this thread: "Maybe
this is kind of a stupid question to ask" -- it apparently was,
but PCL and the other tutorials I've read just didn't mention the
saving of core-files (or maybe I've read over it).
>> I don't think that what I'm doing at the moment could be considered
>> "serious work". I'm just trying to learn some Lisp, and I am not
>> a professional.
>
> Yes, if you want to do it in lisp, learning some lisp is a good idea...
If I want to do what in Lisp? If you refer to the "serious work":
No, I don't think that I'll make my living as a programmer in
the future. The reason for me to learn how to program in Lisp is
curiosity and inquisitiveness.
> What do you know?
>
> There are several ways to do IPC, (Inter Process Communications). The
> most basic one, which is always available and can be implemented even
> in the standard Common Lisp (therefore needing only the most basic
> knowledge of lisp (or any other programming language)) is to go thru
> the file system: the client stores a file somewhere, the server reads
> the files, and stores the answer in some other file, which the client
> reads and display.
Given that I've read (and for the most part understood) PCL and
Touretzkys "Gentle Introdution" I think that I have what you call
"the most basic knowledge of Lisp". Even if it sounds pretty easy
to implement such a basic form of IPC, and it surely is trivial
for a seasoned Lisper or professional programmer, I just lack the
experience for doing such a thing at the moment.
In order to make the transition from just reading books, trying
examples and solving exercises I'm trying to write some functions
and macros that provide some Awk-like functionality. (Yes, know
there's clawk, but I want to learn something) To you, that may be
just ridiculuous or boring, but for me it's just the perfect degree
of difficulty at the moment.
Maybe I'll try implementing some Interpreters, servers and all
that jazz later on...
> So, let's say that you write a little interpreter that takes its
> script and put it into a file in a spool directory and waits for some
> result file to display. And you write a little server that takes
> these files in the spool directory, loads them and writes the result
> to a result file in the spool directory.
>
> Note that there is a little trick: we don't want the reader to read
> the file before it's been entirely written. We can do it easily by
> writing a "job ticket" file.
>
> Let's say you write the script files in
>
> /var/spool/lisp-server/input/XXXXXXX.lisp
>
> once such a file is written, you create a job ticket file:
>
> /var/spool/lisp-server/input/XXXXXXX.job
>
>
> The server searches for .job files and when it finds one, it deletes
> it, and loads the corresponding .lisp file, writting the results to:
>
> /var/spool/lisp-server/output/XXXXXXX.stdout
> /var/spool/lisp-server/output/XXXXXXX.stderr
>
> (more output streams could be used, for example, for *trace-output*, etc).
> When done, it creates the job ticket file:
>
> /var/spool/lisp-server/output/XXXXXXX.job
>
> When the "interpreter" sees this .job file, it would dump the .stdout
> file to standard output and .stderr to standard error.
>
>
> Since you're a "learning-by-doing" guy, I won't do it for you...
>
>
> But there is one other difficulty: scripts cannot be interpreters for
> other scripts, so for your interpreter, you want a binary executable.
> You can generate such an executable with most Common Lisp
> implementations, but how it's done is implementation dependant.
I can follow you, but as mentioned earlier I would have problems
putting that into practice.
> And finally, if you did all that to launch your scripts faster, compare:
>
> - running a simple script like:
> #!/usr/bin/clisp
> (print "hello")
> involves:
> fork, exec(/usr/bin/clisp), read, interpret the script, write
>
> - running a simple script thru a lisp server as:
> #!/usr/local/bin/lisp-client
> (print "hello")
> now involves:
> In the client: In the server:
> fork, loop: opendir readdir closedir
> exec(/usr/local/bin/lisp-client), until found a job ticket
> read, unlink
> open, write, close, creat open, open, read,
> loop: open interpret the script
> until found the job ticket write, close, close, creat
> unlink
> read, write, close, unlink
>
> I wouldn't bet on that to be faster, even if you'd use sockets or
> shared memory to communicate between the client and the server...
I get the point. You are surely right; running the script directly
seems to be the better solution.
> Last time I benchmarked it, printing "Hello World" from perl scripts,
> emacs, sbcl, or clisp scripts, clisp was the fastest. I've heard
> some reports that recent perl is slightly faster to start up.
> Anyways, it's a difference you cannot notice, if you are a human.
Since I'm using a saved core image I can't feel a difference, but
before I knew about that my scripts took about eight seconds to
start up because they make use of cl-ppcre, osicat and other things.
Notice that I didn't complain about Lisp's speed per se -- I was
aware that /my/ method of doing things was wrong, that's why I
asked for a better solution. Unfortunately, inspired by Emacs,
I seem to have asked for the wrong thing.
Regards,
dhl
Daniel Leidisch <····@leidisch.net> writes:
> My whole problem was, that I didn't know that one should save a core
> file in order to avoid the long startup time. Richard M. Kreuter
> was so kind as to explain that to me in detail and that solved
> my problem.
>
> Since I didn't know about that, I asked for the "emacsclient-like"
> solution. If I may quote my first sentence in this thread: "Maybe
> this is kind of a stupid question to ask" -- it apparently was,
> but PCL and the other tutorials I've read just didn't mention the
> saving of core-files (or maybe I've read over it).
But as you noted, core files and emacsclient-like stuff are two
different solutions to two different problems.
>>> I don't think that what I'm doing at the moment could be considered
>>> "serious work". I'm just trying to learn some Lisp, and I am not
>>> a professional.
>>
>> Yes, if you want to do it in lisp, learning some lisp is a good idea...
>
> If I want to do what in Lisp? If you refer to the "serious work":
> No, I don't think that I'll make my living as a programmer in
> the future. The reason for me to learn how to program in Lisp is
> curiosity and inquisitiveness.
I was refering to sending scripts to a lisp server.
>> So, let's say that you write a little interpreter that takes its
>> script and put it into a file in a spool directory and waits for some
>> result file to display. And you write a little server that takes
>> these files in the spool directory, loads them and writes the result
>> to a result file in the spool directory.
>>
>> Note that there is a little trick: we don't want the reader to read
>> the file before it's been entirely written. We can do it easily by
>> writing a "job ticket" file.
>>
>> Let's say you write the script files in
>>
>> /var/spool/lisp-server/input/XXXXXXX.lisp
>>
>> once such a file is written, you create a job ticket file:
>>
>> /var/spool/lisp-server/input/XXXXXXX.job
>>
>>
>> The server searches for .job files and when it finds one, it deletes
>> it, and loads the corresponding .lisp file, writting the results to:
>>
>> /var/spool/lisp-server/output/XXXXXXX.stdout
>> /var/spool/lisp-server/output/XXXXXXX.stderr
>>
>> (more output streams could be used, for example, for *trace-output*, etc).
>> When done, it creates the job ticket file:
>>
>> /var/spool/lisp-server/output/XXXXXXX.job
>>
>> When the "interpreter" sees this .job file, it would dump the .stdout
>> file to standard output and .stderr to standard error.
>>
>>
>> Since you're a "learning-by-doing" guy, I won't do it for you...
>>
>>
>> But there is one other difficulty: scripts cannot be interpreters for
>> other scripts, so for your interpreter, you want a binary executable.
>> You can generate such an executable with most Common Lisp
>> implementations, but how it's done is implementation dependant.
>
> I can follow you, but as mentioned earlier I would have problems
> putting that into practice.
Well, basically, you'd use DIRECTORY, WITH-OPEN-FILE, LOAD, bind the
various stream variables like *STANDARD-OUTPUT*, *STANDARD-INPUT*,
*ERROR-OUTPUT*, LOOP, SLEEP, and PATHNAME functions (MERGE-PATHNAMES,
MAKE-PATHNAME, etc).
That, plus the implementation specific function to make a binary
executable.
Once you've got it working this way, you can learn about how to use
sockets with your lisp implementation, and modify it to go thru
sockets rather than thru the file system.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Thus spoke Pascal Bourguignon <···@informatimago.com>:
>> Since I didn't know about that, I asked for the "emacsclient-like"
>> solution. If I may quote my first sentence in this thread: "Maybe
>> this is kind of a stupid question to ask" -- it apparently was,
>> but PCL and the other tutorials I've read just didn't mention the
>> saving of core-files (or maybe I've read over it).
>
> But as you noted, core files and emacsclient-like stuff are two
> different solutions to two different problems.
I agree.
>> I can follow you, but as mentioned earlier I would have problems
>> putting that into practice.
>
> Well, basically, you'd use DIRECTORY, WITH-OPEN-FILE, LOAD, bind the
> various stream variables like *STANDARD-OUTPUT*, *STANDARD-INPUT*,
> *ERROR-OUTPUT*, LOOP, SLEEP, and PATHNAME functions (MERGE-PATHNAMES,
> MAKE-PATHNAME, etc).
>
> That, plus the implementation specific function to make a binary
> executable.
>
>
> Once you've got it working this way, you can learn about how to use
> sockets with your lisp implementation, and modify it to go thru
> sockets rather than thru the file system.
Actually, I could really give it a try. I am not sure if I'm ready
for it, but I think I'll give it a shot next weekend. If my attempt
won't be too embarrassing, I'll ask for help here when I'm stuck.
Regards,
dhl
Daniel Leidisch <····@leidisch.net> writes:
> but PCL and the other tutorials I've read just didn't mention the
> saving of core-files (or maybe I've read over it).
Maybe you don't need it now, since you found how to do it with SBCL.
However, Practical Common Lisp does discuss this briefly in chapter 32.
(Section "Delivering Applications.")
Daniel Leidisch <····@leidisch.net> writes:
>
> I'm just looking for the easiest solution for writing Lisp-scripts
> that connect to a Lisp running in the background. My problem is,
> that, lacking experience, I don't know where to start. Should I have
> a look at swank, or read up the documentation of different
> implementations? If yes, then which one?
>
> I do most of my stuff in SBCL, but I found clisp convenient for
> scripting, as it allows Shebang-lines out of the box. Since I
> want to use cl-ppcre (because it's implementation-independent),
> my scripts take very long to start up -- annoyingly long.
>
> So my favorite solution would be using SBCL, running in the
> background, and then connect to it to execute my Script.
>
> Maybe someone knows a (newbie-friendly) way to accomplish this --
> or some other method for executing Scripts without having to wait
> ~8 seconds.
I don't think your problem necessitates the solution you're inquiring
about. At least, what you're asking for is only one way to do it, and
not necessarily the easiest or best.
One common way to speed up load times for Common Lisp systems is to
load the systems you want into Lisp, and then save a "core image" or
"memory image" for later execution (analogous to TeX's memory dumps,
if you're familiar with those). Both the implementations you've
named, Clisp and SBCL, support this:
http://www.sbcl.org/manual/Saving-a-Core-Image.html
http://clisp.cons.org/impnotes/image.html
Thereafter, you can tell your implementation to use the prepared
image, usually with a command-line option or something. If you have
authority to do so, you can even replace the default memory image on
your system with one you've prepared.
As for #! scripts, the details vary both among different Unixes and
among different Lisps, and so if you want to deploy your programs that
way, probably the easiest thing is to wrap them in a thin layer of Unix
shell, e.g.,
#!/bin/sh
/path/to/your/lisp --image-file-option image-file <<EOF
;; Lisp code goes here.
EOF
Transcript below [1].
The upside of this approach is that your Lisp programs will have
access to your terminal and process data, so that you can, for
example, do interactive prompting, examine environment variables, etc.
While it's possible under most Unixes to pass file descriptors over a
Unix domain socket, and therefore possible to arrange that your
scripts be run in a daemon process with access to your terminal, you'd
have to roll your own protocols for passing process data from the
client to the server, if you should care about that sort of thing.
Putting this together requires a bit more labor and
implementation-dependent fiddling than I'd suggest to a self-described
newbie (though you might find it a rewarding project).
Hope that helps,
RmK
[1] First, set up your .sbclrc to execute script files as described
here:
http://www.sbcl.org/manual/Unix_002dstyle-Command-Line-Protocol.html#Unix_002dstyle-Command-Line-Protocol
Here's a test without using a custom core image:
$ cat > ~/some-script.lisp
#!/usr/local/bin/sbcl --noinform
;; ASDF is chatty during loading (older versions of asdf send output
;; to *trace-output*).
(let ((*standard-output* (make-broadcast-stream)))
(require :cl-ppcre))
(write-line "Foo")
(quit)
$ chmod 755 ~/some-script.lisp
$ ~/some-script.lisp
Foo
$ time ~/some-script.lisp
Foo
real 0m4.701s
user 0m4.420s
sys 0m0.148s
Create the core image:
$ sbcl
<blather>
* (require :cl-ppcre)
<more blather>
NIL
* (save-lisp-and-die "sbcl-with-cl-ppcre.core")
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into /home/kreuter/sbcl-with-cl-ppcre.core:
writing 1872 bytes from the read-only space at 0x04000000
writing 1128 bytes from the static space at 0x08000000
writing 29360128 bytes from the dynamic space at 0x4f000000
done]
Prepare a script that uses this core image:
$ cat > ~/another-script.lisp
#!/bin/sh
/usr/local/bin/sbcl --noinform --core ~/sbcl-with-cl-ppcre.core --noprint <<EOF
(write-line "Foo")
(quit)
EOF
$ ~/another-script.lisp
Foo
$ time ~/another-script.lisp
Foo
real 0m0.102s
user 0m0.092s
sys 0m0.012s
Thus spoke Richard M Kreuter <·······@progn.net>:
> ...
> Hope that helps,
> RmK
> ...
Yes, it helped. Thank you very much for your elaborate explanation.
I replaced the SBCL default core with my custom one and it works like
a charm.
I still think a tool like the one I looked for would be nice to have,
because it seems to be an overkill to fire up Lisp for every script, but
for now my problem is solved.
Perhaps my nescience has inspired someone to write such a tool. ;)
Regards,
dhl
On Sat, 12 May 2007 19:26:05 +0200, Daniel Leidisch <····@leidisch.net> wrote:
> Since I want to use cl-ppcre (because it's
> implementation-independent), my scripts take very long to start up
> -- annoyingly long.
Why is that? Why don't you save an image which includes the libraries
you want to use? They shouldn't increase the startup time.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Thus spoke Edi Weitz <········@agharta.de>:
> On Sat, 12 May 2007 19:26:05 +0200, Daniel Leidisch <····@leidisch.net> wrote:
>
>> Since I want to use cl-ppcre (because it's
>> implementation-independent), my scripts take very long to start up
>> -- annoyingly long.
>
> Why is that? Why don't you save an image which includes the libraries
> you want to use? They shouldn't increase the startup time.
>
> Edi.
>
Because I'm a beginner who doesn't know his way round yet. I'll try
that. Anyway, the idea of having some way to make a script run in
a running lisp session seems nice to me.
btw. Thank you very much for cl-ppcre!
Regards,
dhl
On Sat, 12 May 2007 19:26:05 +0200, Daniel Leidisch <····@leidisch.net>
wrote:
> Thus spoke Cor Gest <···@clsnet.nl>:
>> Some entity, AKA Daniel Leidisch <····@leidisch.net>,
>> wrote this mindboggling stuff:
>> (selectively-snipped-or-not-p)
>>
>>> Maybe this is kind of a stupid question to ask, but I was
>>> wondering if it is possible to run Lisp in the background and
>>> have it run scripts. What I'm thinking of is something like
>>> (server-start) in Emacs, which lets me run emacsclient. It
>>> would be nice if I could do something like this:
>>> #!/path/to/lispclient
>>> (do-something)
>>
Well lisp runs as a separate process attached to a socket if you use
SLIME. That is what the Notice CL code does.
As such you can run any scripts against it.
As for #!... that is Unix syntax and just gives the following
text to the script. Whether it runs and completes or ruins in the
background
depends on how the script is called.
script & returns immediately.
If you want want it as a cron job most Linux-en set up hourly, weekly,
monthly
directories for that kind of thing.
If you want it to run as a daemon look into detachtty (and perhaps sudo).
That is a bit vague, but then it is not clear to me exactly what you
what to do.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Thus spoke John Thingstad <··············@chello.no>:
> Well lisp runs as a separate process attached to a socket if you use
> SLIME. That is what the Notice CL code does.
> As such you can run any scripts against it.
> As for #!... that is Unix syntax and just gives the following
> text to the script. Whether it runs and completes or ruins in the
> background
> depends on how the script is called.
>
> script & returns immediately.
> If you want want it as a cron job most Linux-en set up hourly, weekly,
> monthly
> directories for that kind of thing.
> If you want it to run as a daemon look into detachtty (and perhaps sudo).
>
> That is a bit vague, but then it is not clear to me exactly what you
> what to do.
>
Read Harald Hanche-Olson's post, I think he explained it better than I
did.
Regards,
dhl