Hello -
I know almost nothing about LISP. Hope the newbie questions aren't
too irritating:
I have a rather large in-hosue executable that I inherited that runs on the old
Sun4 architecture. I'd like to port this program to other operating systems,
but I don't have source.
The name of the tool is of the form 'akcl-foo', and when I run it without
arguments, I am at an interpreter prompt. (lisp-implementation-type) says
"Kyoto Common Lisp", (lisp-implementation-version) says "June 3, 1987". First
question: is ths Austin-Kyoto Common Lisp, or just Kyoto Common Lisp? If AKCL,
which version?
Second question: what exactly is this -- that is, how come without
arguments I seem to be at a fully functional interpreter? Is this
what is known as an image?
Third: can I somehow list defined objects? More generally, what
commands are available for listing information about the state
of the interpreter?
Finally, and I realize this is probably just wishful thinking -
if the system really is in two pieces, and interpreter and the
defined objects, can I 1) somehow separate the two, 2) reconstruct
the lisp source to compiled objects and 3) rebuild the system
on another architecture?
Any and all answers appreciated.
Remove x from above to reply, if present.
-usman
Usman Muzaffar <·····@nwux.edu> writes:
> The name of the tool is of the form 'akcl-foo', and when I run it
> without arguments, I am at an interpreter
> prompt. (lisp-implementation-type) says "Kyoto Common Lisp",
> (lisp-implementation-version) says "June 3, 1987". First question:
> is ths Austin-Kyoto Common Lisp, or just Kyoto Common Lisp? If AKCL,
> which version?
No idea, but you could try doing
(lisp-implementation-type)
and
(lisp-implementation-version)
to the prompt you get and see if it tells you. Those functions are
defined to return strings that describe the implementation. It's
very implementation-dependent what the format is, but you'll know
immediately if it's of use to you or not.
> Second question: what exactly is this -- that is, how come without
> arguments I seem to be at a fully functional interpreter? Is this
> what is known as an image?
Probably the image has code in it that is watching the command line
arguments for a particular configuration of args and processing stuff
only in that case. I know other lisp implementations that do that.
Often this is so that you can either use the standard lisp arguments
or your own. For example, to dump out a new image with patches, you
could start it, load up some patches, and dump it out again. And
the dumped image would again be looking for command line arguments
either for the lisp itself or for the application.
> Third: can I somehow list defined objects? More generally, what
> commands are available for listing information about the state
> of the interpreter?
This is not a dissimilar question to asking "my friend fred died and
i have his brain. how can i find out what he knew?" There are a lot
of storage locations of various kinds and some of them will tell you
things and some won't. Figuring out what's there would be hard to do
in a general-purpose way. You can find out what packages of stuff
are there by doing (list-all-packages). You can find out the symbols
in each package by using
(do-symbols (s "SOME-PACKAGE") (print s))
You can find out for any symbol if it has a value by doing
(boundp symbol)
or if it has a function definition by doing
(fboundp symbol)
or if it has properties on it by doing
(symbol-plist symbol)
or if it is a class name by doing
(find-class symbol)
and there are probably other things you'd want to do, too,
but I can't think of them offhand. The above will probably give
you more raw info than you know what to do with and you'll start to
understand about poor fred and all the things he knew that you
didn't want to know about.
> Finally, and I realize this is probably just wishful thinking -
> if the system really is in two pieces, and interpreter and the
> defined objects, can I 1) somehow separate the two, 2) reconstruct
> the lisp source to compiled objects and 3) rebuild the system
> on another architecture?
I really doubt it. If the definitions of functions were only loaded
interpreted and were not compiled there is some chance you could print
out their definitions and reconstruct part of your system, but even
then you'd probably leave out critical setup steps. I'd say that to at
leaest 10 decimal places the answer is 99.9999999999% that you cannot
do this.
This is addressed to the original poster of course.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> Usman Muzaffar <·····@nwux.edu> writes:
(...)
> > Third: can I somehow list defined objects? More generally, what
> > commands are available for listing information about the state
> > of the interpreter?
(...)
> You can find out what packages of stuff
> are there by doing (list-all-packages). You can find out the symbols
> in each package by using
> (do-symbols (s "SOME-PACKAGE") (print s))
> You can find out for any symbol if it has a value by doing
> (boundp symbol)
> or if it has a function definition by doing
> (fboundp symbol)
> or if it has properties on it by doing
> (symbol-plist symbol)
> or if it is a class name by doing
> (find-class symbol)
> and there are probably other things
(...)
Also, you can add to your arsenal DESCRIBE and INSPECT (don't know
if AKCL implemented them well) and, if the programmers that produced
the image at hand had bothered to include doc-strings, DOCUMENTATION.
(After you have determined available symbols.) E.g. in an imagined
Common Lisp implementation (AKCL probably does not do it in exactly
the same way):
> (defun foo () "Returns the smallest random number." 17)
FOO
> (describe (symbol-function 'foo))
#<INTERPRETED-FUNCTION FOO #x01234567> is an interpreted function of
zero arguments.
> (documentation 'foo 'function)
"Returns the smallest random number."
> (setf l (list '(a b c) d))
((A B C) D)
> (describe l)
((A B C) D) is a list of two elements.
> (inspect l)
((A B C) D) is a list of two elements.
:I n to recursively inspect the n-th element
:S n to change the n-th element
:H for other inspector commands
Inspector> :S 1
new value: last
Inspector> :I 0
(A B C) is a list of three elements.
Inspector> :A
Abort to Lisp top-level.
> l
((A B C) LAST)
You apparently have a pretty old version of Austin Kyoto Common Lisp
(which on the other hand might be the last version, as it became
GNU Common Lisp at some point). This is not the best Common Lisp
implementation in the world, so you may have lots of headaches with it.
> > Finally, and I realize this is probably just wishful thinking -
> > if the system really is in two pieces, and interpreter and the
> > defined objects, can I 1) somehow separate the two, 2) reconstruct
> > the lisp source to compiled objects and 3) rebuild the system
> > on another architecture?
>
> I really doubt it. If the definitions of functions were only loaded
> interpreted and were not compiled there is some chance you could print
> out their definitions and reconstruct part of your system, but even
> then you'd probably leave out critical setup steps. I'd say that to at
> leaest 10 decimal places the answer is 99.9999999999% that you cannot
> do this.
I second this.
By `system' I assume you mean the application that was implemented in
Lisp and saved in the image.
Is it really critical for you to extract the application from the image?
Trying to do this, especially in the absence of documentation (in
particular documentation about the implementation), may lead to these
results, one positive and one negative:
(1) you improve your hacking skills, and learn a lot of useful things;
(2) you have no `distilled' whole application eventually, just some
pieces.
So you should consider the price (in terms of your time and effort)
you are willing to pay for that.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <················@nwux.edu>,
Usman Muzaffar <·····@nwux.edu> writes:
> ...
> The name of the tool is of the form 'akcl-foo', and when I run it without
> arguments, I am at an interpreter prompt. (lisp-implementation-type) says
> "Kyoto Common Lisp", (lisp-implementation-version) says "June 3, 1987". First
> question: is ths Austin-Kyoto Common Lisp, or just Kyoto Common Lisp? If AKCL,
As far as I know, GCL (GNU Common Lisp) is based on AKCL (could be just
renamed. Checking out the GCL documentation might help you further.
Hartmann Schaffer