Hello,
I tried installing the clisp. The file I used is clisp-linu-elf.tar from
my linu cdrom. It created a directory clisp-1996-07-22
The first instruction is make. And I believe this was successfully done.
Subsequently the next instruction is typing
base/lisp.run -M base/lispinit.mem
(compile-file "src/config")
The output I got was
> (compile-file "src/config")
*** - nonexistent directory: #"/proc/445/fd/4/"
1. Break>
> (load "src/config")
*** - nonexistent directory: #"/proc/445/fd/4/"
1. Break>
I have checked my directory and obtained:
[/root]# ls /proc/445/fd/
0 1 2 3
Can someone help me with the installation? or suggest some other
implementation of lisp that would hopefully work. Thanks.
BTW, my linux is Red Hat Kernel version 2.0.0 and I tried starting from
source files which gave me a lot of compilation errors.
Thanks a lot
Lik Wee
> I tried installing the clisp. The file I used is clisp-linu-elf.tar from
> my linu cdrom. It created a directory clisp-1996-07-22
>
> The first instruction is make. And I believe this was successfully done.
> Subsequently the next instruction is typing
> base/lisp.run -M base/lispinit.mem
> (compile-file "src/config")
>
> The output I got was
>
> > (compile-file "src/config")
>
> *** - nonexistent directory: #"/proc/445/fd/4/"
This is a mistake in the README. It should actually tell you to do
> (compile-file "src/config.lsp")
Why does CLISP behave so strange when you type in the name of a nonexistent
file? It assumes that the file (without extension ".lsp") exists somewhere
below your $HOME directory and starts searching. In your case there is
apparently somewhere a symbolic link to / , and when the search examines
/proc on Linux, it falls into some pitfall. Sorry.
Bruno
Bruno Haible (······@ma2s2.mathematik.uni-karlsruhe.de) wrote:
: > *** - nonexistent directory: #"/proc/445/fd/4/"
: below your $HOME directory and starts searching. In your case there is
: apparently somewhere a symbolic link to / , and when the search examines
: /proc on Linux, it falls into some pitfall. Sorry.
Some people are using login root. It's obvious that CLISP should not
choke on /proc, but I don't know what the bug is.
Jo"rg Ho"hle.
············@gmd.de http://zeus.gmd.de/~hoehle/amiga-clisp.html
Bruno Haible wrote:
> Why does CLISP behave so strange when you type in the name of a nonexistent
> file? It assumes that the file (without extension ".lsp") exists somewhere
> below your $HOME directory and starts searching. In your case there is
> apparently somewhere a symbolic link to / , and when the search examines
> /proc on Linux, it falls into some pitfall. Sorry.
aargh, you mean it searches the entire directory tree under your home
directory? ouch.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
>>>>> "Gareth" == Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
Gareth> Bruno Haible wrote:
>> Why does CLISP behave so strange when you type in the name of a nonexistent
>> file? It assumes that the file (without extension ".lsp") exists somewhere
>> below your $HOME directory and starts searching. In your case there is
>> apparently somewhere a symbolic link to / , and when the search examines
>> /proc on Linux, it falls into some pitfall. Sorry.
Gareth> aargh, you mean it searches the entire directory tree under your home
Gareth> directory? ouch.
I believe it's configurable so if you don't like it you can change
it. Look up *load-paths*.
Ray
Gareth McCaughan <·····@dpmms.cam.ac.uk> writes:
> Bruno Haible wrote:
> > Why does CLISP behave so strange when you type in the name of a nonexistent
> > file? It assumes that the file (without extension ".lsp") exists somewhere
> > below your $HOME directory and starts searching. In your case there is
> > apparently somewhere a symbolic link to / , and when the search examines
> > /proc on Linux, it falls into some pitfall. Sorry.
> aargh, you mean it searches the entire directory tree under your home
> directory? ouch.
Actually, if you look at the definition of *load-paths* in config.lsp before
you compile it, you find it is
(defparameter *load-paths* '(#"./" #"./**/" "~/**/"))
which you can change to just
(defparameter *load-paths* '(#"./"))
which I think restricts this searching to just the current directory.
Of course, this can cause problems with applications that assume the original
definition of *load-paths*.
--
T. Kurt Bond, ·············@cpmx.saic.com