Running Lisp programs non-interactively 
Author Message
 Running Lisp programs non-interactively

Hello

I'm using CMUCL 18c on Slackware 7.0.

May I ask you about "standalone" usage of a
Lisp program ? To make my question more clear
I'll describe what I done and then just ask you
to say what do you think about that and how you
do such things ?

I wrote more or less significant program. Composed
.system files (for DEFSYSTEM) to bring things together.
Now when I debugged it (in general of course) I'd like
to run it periodically, and non-interactively (e.g.
from CRONTAB). Things the program does completely
being kept in files and databases.

Then I done. Created core file say MY.CORE. Created file
say LOAD.LISP that looks like the following (at the top
level):

;; Loading needed binaries (FASL files)

(mk:oos "lib" 'load :load-source-if-no-binary t)
(mk:oos "transformer" 'load ...)

;; Call the function that do the job
(do-job)
(quit)

The MY.CORE contains the basic stuff such as DEFSYSTEM etc.
All other things specific to this particular task are
loaded in LOAD.CORE.

CRONTAB entry contains

0 5 * * * $HOME/job.sh >> /var/log/my.log 2>&1

and JOB.SH just does

/usr/local/bin/lisp -core MY.CORE -batch -load LOAD.LISP

Any feedback will be welcome.

--



Sat, 20 Sep 2003 21:40:03 GMT  
 Running Lisp programs non-interactively

Quote:
> Any feedback will be welcome.

Apart from what Erik has already mentioned, one thing that may be of
concern is to make sure that you do something sensible with *all*
errors.  `Something sensible' may well be `print a message and quit',
or it may be something more complex, but for a program run from cron
it probably is not `attempt to get into the de{*filter*}, repeatedly read
EOF and die horribly'.

I have a little web-server which I use to talk to various
applications, which runs as a daemon.  I recently (today) discovered
that if the browser does bad things the stream open to it can get into
a bad state, and I didn't have enough error protection in the
appropriate bit of code, so it fell about.  Now it has a judicious
IGNORE-ERRORS there (because WITH-OPEN-STREAM will close the stream
anyway, and it's too small to do logging (seriously, it's only about 4
functions, a logger would make it significantly larger!)).

--tim



Sun, 21 Sep 2003 02:39:17 GMT  
 Running Lisp programs non-interactively


Quote:
>   You probably want an image/core that does not start the
>   read-eval-print loop, but rather one of your own functions.  You
>   should be able to specify this when you dump an image/core.  I have no
>   idea how CMUCL does this, however.

* (describe 'save-lisp)

SAVE-LISP is an external symbol in the EXTENSIONS package.
Function: #<Function SAVE-LISP {103B9941}>
Function arguments:
  (core-file-name &key (purify t) (root-structures nil)
   (environment-name "Auxiliary") (init-function #'%top-level) (load-init-file t)
   (site-init "library:site-init") (print-herald t) (process-command-line t))
Function documentation:
  Saves a CMU Common Lisp core image in the file of the specified name.  The
  following keywords are defined:

<SNIP>

  :init-function
      This is the function that starts running when the created core file is
  resumed.  The default function simply invokes the top level
  read-eval-print loop.  If the function returns the lisp will exit.

<SNIP>

So all that's needed is to define a function that does what's in the
LOAD.LISP file and pass that as the :init-function argument.

--
-> -/-                       - Rahul Jain -                       -\- <-

-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.



Sun, 21 Sep 2003 05:15:08 GMT  
 Running Lisp programs non-interactively

Quote:


> > Any feedback will be welcome.

> Apart from what Erik has already mentioned, one thing that may be of
> concern is to make sure that you do something sensible with *all*
> errors.  `Something sensible' may well be `print a message and quit',
> or it may be something more complex, but for a program run from cron
> it probably is not `attempt to get into the de{*filter*}, repeatedly read
> EOF and die horribly'.

What planet are you from?  The standard way of handling an error in a
C program running on a unix system is to ignore it and proceed with
the bogus return value.  This usually eventually leads to an illegal
instruction or bad address, at which you core dump.  Attempting to get
into the de{*filter*} and dying attempting to read EOF is a more elaborate
way of getting the same effect.

If you are an advanced unix weenie, you might detect the bad value and
quit, but printing a message before doing so is just coddling the
uninformed.  If you *must* print a diagnostic, ensure that you print
it to an undocumented log file.  Mentioning that the user is not a
typewriter is encouraged.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.*-*-*.com/ - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----



Mon, 22 Sep 2003 00:49:08 GMT  
 Running Lisp programs non-interactively

Quote:



> > > Any feedback will be welcome.

> > Apart from what Erik has already mentioned, one thing that may be of
> > concern is to make sure that you do something sensible with *all*
> > errors.  `Something sensible' may well be `print a message and quit',
> > or it may be something more complex, but for a program run from cron
> > it probably is not `attempt to get into the de{*filter*}, repeatedly read
> > EOF and die horribly'.

> What planet are you from?  The standard way of handling an error in a
> C program running on a unix system is to ignore it and proceed with
> the bogus return value.  This usually eventually leads to an illegal
> instruction or bad address, at which you core dump.  Attempting to get
> into the de{*filter*} and dying attempting to read EOF is a more elaborate
> way of getting the same effect.

> If you are an advanced unix weenie, you might detect the bad value and
> quit, but printing a message before doing so is just coddling the
> uninformed.  If you *must* print a diagnostic, ensure that you print
> it to an undocumented log file.  Mentioning that the user is not a
> typewriter is encouraged.

You forgot to mention that the diagnostic produced should be obscure,
just in case they find the log file, for example:

(format logstream "Fatal Error:~S in module ~S:~S~%   Recommended action:~S~%"
  (gensym) (gensym) (gensym) (gensym))

Geoff



Mon, 22 Sep 2003 01:31:19 GMT  
 Running Lisp programs non-interactively

Quote:

> What planet are you from?  The standard way of handling an error in a
> C program running on a unix system is to ignore it and proceed with
> the bogus return value.  This usually eventually leads to an illegal
> instruction or bad address, at which you core dump.  Attempting to get
> into the de{*filter*} and dying attempting to read EOF is a more elaborate
> way of getting the same effect.

Oh no, I think this isn't right at all.  You should not ever leave any
trace that you might have tried to get into the de{*filter*}, or that
there might actually be a de{*filter*} linked with your system.  Apart
from anything else some of the messages might reveal that you are
doing politically unsound things like checking array bounds, which
would never do.  In fact most lisp systems have a way to poke at
arbitrary memory, so the correct error handler will do something like
(loop while t do (poke (random #x100000000) (random #x100000000)))
until something suitably catastrophic happens to replicate the kinds
of failures people know and love.

It's very important that Lisp meets modern expectations in this kind
of way.

--tim



Mon, 22 Sep 2003 02:10:41 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. To run passwd non-interactively for normal users.

2. running smalltalk non-interactively

3. tpsfix NON-interactively?? what's the trick

4. running non-compiled LISP from the command-line?

5. Running non GUI programs

6. Run a non-cobol program

7. Printing of individually returned values when running interactively

8. Problems running Python interactively from GNU-Win32 bash pro mpt

9. Problems running Python interactively from GNU-Win32 bash prompt

10. Running TCL interactively

11. Easy way to interactively use Ruby with program

12. interactively debug tcl program

 

 
Powered by phpBB® Forum Software