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.
--
Vladimir Zolotych ······@eurocom.od.ua
In article <················@naggum.net> on Tue, 03 Apr 2001 10:42:28
-0500, "Erik Naggum" <····@naggum.net> wrote:
> 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 - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "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.
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> 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 debugger, 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
Tim Bradshaw <···@tfeb.org> writes:
> "Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
>
>
> > 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 debugger, 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 debugger 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.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
"Joe Marshall" <···@content-integrity.com> wrote in message ·················@content-integrity.com...
> Tim Bradshaw <···@tfeb.org> writes:
>
> > "Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> >
> >
> > > 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 debugger, 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 debugger 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
Joe Marshall <···@content-integrity.com> writes:
>
> 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 debugger 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 debugger, or that
there might actually be a debugger 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