CLISP `executables' (idiot question)
Tim Bradshaw
scripts or makefiles, with arguments. I'm on Solaris not Linux, and I
very much need to have it compiled, so I don't think any of the clever
fasl-files as executables or source-files-as-scripts are available to
me.
What I'm trying to do is to load my code, and then dump an image which
I can then get to do stuff on restart. Then I'll has a trivial script
wrapper which will do:
clisp -norc -M mymem.memn ...
THis works to restart the image, and if I give no arguments then the
function I specify to SAVEINITMEM is run. However, if I *do* give
arguments, it seems to be hard wired that the first is the name of a
file to load, and the rest are then available as *ARGS*. Well, I
thought I could get around this by
clisp -norc -M mymem.mem /dev/null $*
but in this case it looks like the restart function is not run.
So I'm stuck. There must be an easy way to do this which doesn't
involve me writing a little lisp wrapper script to go instead of
/dev/null above. Can anyone tell me what I'm doing wrong?
Thanks
--tim
Thomas F. Burdick
> I have an application I want to bundle up as somethign I can call from
> scripts or makefiles, with arguments. I'm on Solaris not Linux, and I
> very much need to have it compiled, so I don't think any of the clever
> fasl-files as executables or source-files-as-scripts are available to
> me.
Sure you can, read the implementation notes. fasl-files-as-scripts
works just fine (if you have an actual executable `clisp', not a
script) -- I do this all the time on Solaris:
$ cat shebang.txt
#!/path/to/clisp
$ cat shebang.txt hello.fas > example.fas
$ chmod u+x example.fas
$ ./example.fas
Hello, World!
$
> What I'm trying to do is to load my code, and then dump an image which
> I can then get to do stuff on restart. Then I'll has a trivial script
> wrapper which will do:
>
> clisp -norc -M mymem.memn ...
>
> THis works to restart the image, and if I give no arguments then the
> function I specify to SAVEINITMEM is run. However, if I *do* give
> arguments, it seems to be hard wired that the first is the name of a
> file to load, and the rest are then available as *ARGS*. Well, I
> thought I could get around this by
>
> clisp -norc -M mymem.mem /dev/null $*
>
> but in this case it looks like the restart function is not run.
>
> So I'm stuck. There must be an easy way to do this which doesn't
> involve me writing a little lisp wrapper script to go instead of
> /dev/null above. Can anyone tell me what I'm doing wrong?
Can't you save your image without an :INIT-FUNCTION, then launch the
application with a shell script that has it load the code you'd have
put in :INIT-FUNCTION?
BTW, the clisp-list might be a better place to ask this:
<http://sourceforge.net/mail/?group_id=1355>
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Sam Steingold
> * On the subject of "CLISP `executables' (idiot question)"
> * Sent on 17 Oct 2001 14:26:28 +0100
> * Honorable Tim Bradshaw <t...@cley.com> writes:
>
> There must be an easy way to do this which doesn't involve me writing
> a little lisp wrapper script to go instead of /dev/null above. Can
> anyone tell me what I'm doing wrong?
First, this is a CLISP-specific question, best asked on <clisp-list>
(see http://clisp.cons.org).
Second, I usually dump a memory image with all the necessary
functionality and use a tiny shell script which uses CLOCC/CLLIB/getopt
to parse *ARGS* and call the right function with the right arguments.
Third, I agree that "clisp -M foo.mem 1 2 3" should probably pass '(1 2
3) to FOO. I will look into this...
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Perl: all stupidities of UNIX in one.
Sam Steingold
> * On the subject of "CLISP `executables' (idiot question)"
> * Sent on 17 Oct 2001 14:26:28 +0100
> * Honorable Tim Bradshaw <t...@cley.com> writes:
>
$ clisp -norc -M foo.mem -x '(my-func "file" 123 :always t :new nil)'
you will encounter the QH (Quoting Hell) because () are shell specials,
but other than that you should be in good shape.
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Lisp: its not just for geniuses anymore.
Erik Naggum
| First, this is a CLISP-specific question, best asked on <clisp-list>
| (see http://clisp.cons.org).
Why do you work so hard for this separation of the Lisp community? What
if some people who do not use CLISP today would switch to it if they saw
answers to questions they would not have asked? And why favor mailing
lists and web pages when news is such a technically superior medium?
///
--
Five weeks. I have seen all the news coverage I can take for a the rest
of the year. Let me know when life has returned to normal. Thank you.
Daniel Barlow
> * Sam Steingold <s...@gnu.org>
> | First, this is a CLISP-specific question, best asked on <clisp-list>
> | (see http://clisp.cons.org).
>
> Why do you work so hard for this separation of the Lisp community? What
> if some people who do not use CLISP today would switch to it if they saw
> answers to questions they would not have asked? And why favor mailing
> lists and web pages when news is such a technically superior medium?
I can't answer for Sam, but if the equivalent question was asked
about any other Lisp implementation, three of every four answers would
have been "this is implementation-specific, you should ask your vendor
this question".
Which I personally think is a shame, because I find the threads about
other implementations interesting. However, it is apparently accepted
practice on c.l.l, and to the extent that the original poster would
usually have got a better response in a more specialized forum, it
does make some kind of sense.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Thomas F. Burdick
> * Sam Steingold <s...@gnu.org>
> | First, this is a CLISP-specific question, best asked on <clisp-list>
> | (see http://clisp.cons.org).
>
> Why do you work so hard for this separation of the Lisp community? What
> if some people who do not use CLISP today would switch to it if they saw
> answers to questions they would not have asked? And why favor mailing
> lists and web pages when news is such a technically superior medium?
I don't know about Sam Steingold, but I recommended the clisp-list
because he might get a better answer there. I also answered his
question, because, well, other people might care, too.
cbbr...@acm.org
I found myself looking, today, for a system-specific function that
probably commonly exists, but for which there is no standard name.
On some Lisps, there's a SYS:%POINTER, which provides the address of
the requested object. This isn't something that one ought to
generally be using for terribly intimate stuff, but it would be nice
to use it when specializing PRINT-OBJECT...
(defmethod print-object ((o my-funky-object) stream)
(format stream "#<~S ~A ~A ~D>"
(type-of o)
(attribute-1 o)
(attribute-2 o)
(SYS:%POINTER o)))
I didn't see anything in CLISP that seemed to do the trick, although I
didn't look spectacularly hard...
Another interesting thing that I noticed in Keene; it suggested
specializing DESCRIBE. CLISP and CMUCL both don't think it's a
method. Is that common?
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www.cbbrowne.com/info/lisp.html
"The program is manufactured by Quantel, a Silicon Valley company
located in Clearwater, Florida."
Gabe Garza
> I didn't see anything in CLISP that seemed to do the trick, although I
> didn't look spectacularly hard...
APROPOS is good. ;) SYSTEM::ADDRESS-OF looks promising.
[1]> (apropos "ADDRESS")
:ADDRESS constant
ADDRESS
SYSTEM::ADDRESS-OF function
SYSTEM::CODE-ADDRESS-OF function
FOREIGN-ADDRESS
[2]> (system::address-of 'car)
136338017
> Another interesting thing that I noticed in Keene; it suggested
> specializing DESCRIBE. CLISP and CMUCL both don't think it's a
> method. Is that common?
I'm pretty sure it's a generic function in CMUCL if PCL is loaded, at
least it is in my image:
* #'documentation
#<Standard-Generic-Function PCL::DOCUMENTATION (19) {28153BD9}>
Gabe Garza
Kalle Olavi Niemitalo
> (defmethod print-object ((o my-funky-object) stream)
> (format stream "#<~S ~A ~A ~D>"
> (type-of o)
> (attribute-1 o)
> (attribute-2 o)
> (SYS:%POINTER o)))
You could use PRINT-UNREADABLE-OBJECT with :IDENTITY T.
That would also check *PRINT-READABLY*, which you forgot.
> Another interesting thing that I noticed in Keene; it suggested
> specializing DESCRIBE. CLISP and CMUCL both don't think it's a
> method. Is that common?
DESCRIBE calls DESCRIBE-OBJECT, which you can specialize.
See the issue DESCRIBE-UNDERSPECIFIED.
Gabe Garza
> > Another interesting thing that I noticed in Keene; it suggested
> > specializing DESCRIBE. CLISP and CMUCL both don't think it's a
> > method. Is that common?
>
> I'm pretty sure it's a generic function in CMUCL if PCL is loaded, at
> least it is in my image:
>
> * #'documentation
>
> #<Standard-Generic-Function PCL::DOCUMENTATION (19) {28153BD9}>
Of course DOCUMENTATION is not DESCRIBE. *grumble*
Tim Bradshaw
> Can't you save your image without an :INIT-FUNCTION, then launch the
> application with a shell script that has it load the code you'd have
> put in :INIT-FUNCTION?
Yes, but then I need two files + a script. I want one file + a script.
--tim
Tim Bradshaw
> First, this is a CLISP-specific question, best asked on <clisp-list>
> (see http://clisp.cons.org).
Yes, I know, but I don't read that and I hoped that people where would
know.
> Second, I usually dump a memory image with all the necessary
> functionality and use a tiny shell script which uses CLOCC/CLLIB/getopt
> to parse *ARGS* and call the right function with the right
> arguments.
This would probably work.
> Third, I agree that "clisp -M foo.mem 1 2 3" should probably pass '(1 2
> 3) to FOO. I will look into this...
This would be ideal.
--tim
Tim Bradshaw
> I can't answer for Sam, but if the equivalent question was asked
> about any other Lisp implementation, three of every four answers would
> have been "this is implementation-specific, you should ask your vendor
> this question".
I've given that answer (and I'm the one who posted here).
For what it's worth my reasoning (at least in retrospect) was
something like this: I think it's pretty rude to mail to a list to
which you do not subscribe (as rude as the newsgroup postings which
say `please mail any replies as I don't read this group'), so I
wouldn't seriously consider posting to a clisp mailing list unless I
read that list, which I don't. However this is different, to me, than
a support/bug mail address which does not carry the implication of there
being a mailing list or of it being rude not to subscribe: it's just
somewhere you can mail support questions or bug reports. If there were
sa clisp support address I should have mailed there - and if there is
such an address, then I apologise for not mailing to it.
Secondly I think there is a specific issue with a system where a
vendor is selling support or where there is otherwise some contract.
There are two reasons, in this case, to use the support mail address /
web thingy / whatever. Firstly the vendor needs to differentiate
between people who have support and people who do not: if they post
answers to questions to open mailing lists or newsgroups they are
failing to do this and thus reducing the benefit of a support contract
to a customer, which will reduce the number of contracts, and hence
their income. You can get around this by bundling support - you can't
buy the product without support and may be you stop being able to use
it if you stop paying for support, but lots of people don't like these
sorts of arrangements. Secondly the vendor may have non-publishable
fixes to problems which they are unwilling to let be known in general
but they *are* willing to give to a supported customer, possibly under
non-disclosure. I've been in just this situation with machine support
contracts, where there were embarrassing (and now public) hardware
issues which had a partial software workaround.
Anyway, maybe I should have subscribed to the clisp list in this
case...
--tim
Erik Naggum
| I don't know about Sam Steingold, but I recommended the clisp-list
| because he might get a better answer there. I also answered his
| question, because, well, other people might care, too.
There is a small difference between bug reports and other clearly
implementation-specific problems on the one hand and a request for a
feature that probably would have public interest on the other. A robotic
"use the mailing list" answer to all CLISP questions splits the community
for no good reason and the competition that CLISP needs to improve will
disappear. People who agree too much get too many weird ideas and fail
to weed them out. Take IF*, for instance -- it would most probably not
have survived in a larger group of people.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
Marco Antoniotti
cbbr...@acm.org writes:
Since you are printing something of the form
#<A-TYPE ....>
The portable way to do exactly that is
(defmethod print-object ((o my-funky-object) stream)
(print-unreadable-object (o stream :type t :identity t)
(format stream "~A ~A" (attribute-1 o) (attribute-2 o))))
>
> Another interesting thing that I noticed in Keene; it suggested
> specializing DESCRIBE. CLISP and CMUCL both don't think it's a
> method. Is that common?
That is the standard. Specialize DESCRIBE-OBJECT. DESCRIBE will call
it. Keene's book was written before ANSI.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Kent M Pitman
> cbbr...@acm.org writes:
>
> > On some Lisps, there's a SYS:%POINTER, which provides the address of
> > the requested object. This isn't something that one ought to
> > generally be using for terribly intimate stuff, but it would be nice
> > to use it when specializing PRINT-OBJECT...
> >
> > (defmethod print-object ((o my-funky-object) stream)
> > (format stream "#<~S ~A ~A ~D>"
> > (type-of o)
> > (attribute-1 o)
> > (attribute-2 o)
> > (SYS:%POINTER o)))
> >
> > I didn't see anything in CLISP that seemed to do the trick, although I
> > didn't look spectacularly hard...
>
> Since you are printing something of the form
>
> #<A-TYPE ....>
>
> The portable way to do exactly that is
>
> (defmethod print-object ((o my-funky-object) stream)
> (print-unreadable-object (o stream :type t :identity t)
> (format stream "~A ~A" (attribute-1 o) (attribute-2 o))))
>
Actually, PRINT-UNREADABLE-OBJECT also has the additional benefit
that it fixes the bug in cbbrowne's code where if *PRINT-READABLY*
is true, he will fail to signal an error rather than print the object.
PRINT-UNREADABLE-OBJECT does this test implicitly, so *PRINT-READABLY*
works more reliably.
Sam Steingold
> * On the subject of "Re: CLISP `executables' (idiot question)"
> * Sent on 18 Oct 2001 09:42:21 +0100
> > First, this is a CLISP-specific question, best asked on <clisp-list>
> > (see http://clisp.cons.org).
> Yes, I know, but I don't read that and I hoped that people where would
> know.
if you use CLISP, I think you should subscribe to <clisp-list>.
Your question was of the "ask your vendor" type, IMO.
I believe it is in your interest to receive an answer, and you are more
likely to get it (and get it fast!) if you ask in the right forum.
Of course, your Freedom of Speech is sacred. :-)
> > Third, I agree that "clisp -M foo.mem 1 2 3" should probably pass
> > '(1 2 3) to FOO. I will look into this...
on a second thought, this would break the feature that regardless of the
init-function you can still execute a file.
> This would be ideal.
okay, in the current CVS, if the executable file is "" (nether UNIX nor
win32 permits such filenames, so this should be backwards compatible),
then EXT:*ARGS* is set to the list of all other arguments. E.g.:
> (defun foo () (print *args*) (quit))
> (saveinitmem "foo" :init-function #'foo)
$ clisp -M foo.mem "" 1 2 3 4
("1" "2" "3" "4")
$ echo '(print *args*)' | clisp -M foo.mem - 1 2 3
("1" "2" "3")
$
--
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Never trust a man who can count to 1024 on his fingers.
Thomas F. Burdick
Honest question:
Why does that matter?
Facetious question:
Why don't you make your app one-really-big-fasl?
Thomas F. Burdick
> * Thomas F. Burdick
> | I don't know about Sam Steingold, but I recommended the clisp-list
> | because he might get a better answer there. I also answered his
> | question, because, well, other people might care, too.
>
> There is a small difference between bug reports and other clearly
> implementation-specific problems on the one hand and a request for a
> feature that probably would have public interest on the other. A robotic
> "use the mailing list" answer to all CLISP questions splits the community
> for no good reason and the competition that CLISP needs to improve will
> disappear. People who agree too much get too many weird ideas and fail
> to weed them out. Take IF*, for instance -- it would most probably not
> have survived in a larger group of people.
I didn't mean to imply that c.l.l was an inappropriate forum for this
question. *However*, I'd bet there are people on the clisp-list who
don't read c.l.l, which would mean there's possible expertise there
going untapped.
And, for what it's worth, I think Tim Bradshaw's response (that he
doesn't ask questions to e-mail lists he doesn't subscribe to)
confirmed my reasons for urging. While that's ordinarily polite, I
think it's unwise for something like a lisp implementation's user
list. If you want to avoid asking a FAQ, just use the search feature
on the archives (which I should have pointed out when I wrote the post).
Tim Bradshaw
> Honest question:
> Why does that matter?
It's more to maintain, more to go wrong. The usual reasons.
cbbr...@acm.org
> cbbr...@acm.org writes:
> > I didn't see anything in CLISP that seemed to do the trick,
> > although I didn't look spectacularly hard...
> APROPOS is good. ;) SYSTEM::ADDRESS-OF looks promising.
>
> [1]> (apropos "ADDRESS")
> :ADDRESS constant
> ADDRESS
> SYSTEM::ADDRESS-OF function
> SYSTEM::CODE-ADDRESS-OF function
> FOREIGN-ADDRESS
>
> [2]> (system::address-of 'car)
> 136338017
That seems not unreasonable.
> > Another interesting thing that I noticed in Keene; it suggested
> > specializing DESCRIBE. CLISP and CMUCL both don't think it's a
> > method. Is that common?
> I'm pretty sure it's a generic function in CMUCL if PCL is loaded, at
> least it is in my image:
> * #'documentation
>
> #<Standard-Generic-Function PCL::DOCUMENTATION (19) {28153BD9}>
#'describe is a separate function from #documentation, no? And I'm
led to believe that Keene predates CLOS being really finalized; in the
end, the thing to specialize turned out to be DESCRIBE-OBJECT...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/sap.html
"What this list needs is a good five-dollar plasma weapon."
--paraphrased from `/usr/bin/fortune`