Hi group
My clisp and slime lisp environments react in different ways.
I am using windows XP with emacs 22.1 windows version. I use cygwin
for a bash envornment, and I have a clisp that came with cygwin to
which I also point the inferior-lisp-program.
For slime, I took Peter Seibel's lispbox, but I call it from my emacs
instead of the one that comes with the box. AND, I am a new lisp
user. Recipe for questions.
So, here are two instances where clisp and slime behave in a different
manner:
1) In clisp, *load-paths* is defined as (#P"./" "~/lisp/**/").
Evaluating *load-paths* in slime will bring me to the debugger.
2) In clisp (make-pathname :device "C") causes an error, but slime
will happily return a correct pathname.
Any guesses as to what parts of the setup can cause such different
behavior? If need be, I can provide the lispbox.el and relevant part
of .emacs.
Just in case that I slime is running a different version of clisp
(anything is possible), how can I check with version of clisp I am
running. Is there a *lisp-version* like command that can help me
identify which clisp I am running?
Thanks,
Mirko
·············@gmail.com writes:
> Hi group
>
> My clisp and slime lisp environments react in different ways.
>
> I am using windows XP with emacs 22.1 windows version. I use cygwin
> for a bash envornment, and I have a clisp that came with cygwin to
> which I also point the inferior-lisp-program.
>
> For slime, I took Peter Seibel's lispbox, but I call it from my emacs
> instead of the one that comes with the box. AND, I am a new lisp
> user. Recipe for questions.
Still, you don't say what lisp implementation you're using under emacs
and slime...
> So, here are two instances where clisp and slime behave in a different
> manner:
>
> 1) In clisp, *load-paths* is defined as (#P"./" "~/lisp/**/").
> Evaluating *load-paths* in slime will bring me to the debugger.
It could be useful to actuall READ the error message, and try to
UNDERSTAND what it says...
> 2) In clisp (make-pathname :device "C") causes an error, but slime
> will happily return a correct pathname.
It can also be useful to read the implementation manual to know what
implementation specific API is implemented by your specific
implementation.
In the case of clisp, that's the clisp implementation notes. For
example, the chapter about pathname could give useful information:
http://clisp.cons.org/impnotes/path-components.html
It looks like clisp expects a symbol, not a string.
> Any guesses as to what parts of the setup can cause such different
> behavior? If need be, I can provide the lispbox.el and relevant part
> of .emacs.
My bet is that you don't use clisp under emacs/slime, but some other
implementation, probably sbcl.
> Just in case that I slime is running a different version of clisp
> (anything is possible), how can I check with version of clisp I am
> running. Is there a *lisp-version* like command that can help me
> identify which clisp I am running?
Interactively, you can use functions such as APROPOS, DESCRIBE and
DOCUMENTATION:
(apropos "VERSION" "CL")
(apropos "IMPLEMENTATION" "CL")
(describe 'cl:lisp-implementation-version)
(documentation 'cl:lisp-implementation-version 'function)
Unfortunately, describe and documentation don't always return useful
information. Better to refer to the Common Lisp HyperSpec for CL
stuff, and to your implementation manual for implementation specific
stuff (and of course, to the documentation or sources of the various
libraries ("systems") you may use.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jul 16, 5:54 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> ·············@gmail.com writes:
> > Hi group
>
> > My clisp and slime lisp environments react in different ways.
>
> > I am using windows XP with emacs 22.1 windows version. I use cygwin
> > for a bash envornment, and I have a clisp that came with cygwin to
> > which I also point the inferior-lisp-program.
>
> > For slime, I took Peter Seibel's lispbox, but I call it from my emacs
> > instead of the one that comes with the box. AND, I am a new lisp
> > user. Recipe for questions.
>
> Still, you don't say what lisp implementation you're using under emacs
> and slime...
>
they are *both* (see below) gnu clisp
> > So, here are two instances where clisp and slime behave in a different
> > manner:
>
> > 1) In clisp, *load-paths* is defined as (#P"./" "~/lisp/**/").
> > Evaluating *load-paths* in slime will bring me to the debugger.
>
> It could be useful to actuall READ the error message, and try to
> UNDERSTAND what it says...
>
ok. It sai_d_ EVAL: variable *load-paths* has no value
> > 2) In clisp (make-pathname :device "C") causes an error, but slime
> > will happily return a correct pathname.
>
> It can also be useful to read the implementation manual to know what
> implementation specific API is implemented by your specific
> implementation.
>
> In the case of clisp, that's the clisp implementation notes. For
> example, the chapter about pathname could give useful information:
>
> http://clisp.cons.org/impnotes/path-components.html
>
> It looks like clisp expects a symbol, not a string.
>
> > Any guesses as to what parts of the setup can cause such different
> > behavior? If need be, I can provide the lispbox.el and relevant part
> > of .emacs.
>
> My bet is that you don't use clisp under emacs/slime, but some other
> implementation, probably sbcl.
>
very close to the correct answer. Enough to win the bet.
It turns out that I had two clisp implementations. One from lispbox,
and the other from cygwin. I tried to hide the clisp from lispbox by
renaming the directories (I appended aaa to the emacs, clisp, and
practicals directories. Well, lispbox still managed to find the clisp
in its distribution (machine beats human, again).
Once I actually moved the directories to a /temp folder, slime &
lispbox accessed the same clisp, and I get the same behavior:
lispbox's clisp does not have *load-paths* defined, but can understand
the windows directory structure. cygwin's clisp has *load-paths*
defined, but follows a posix directory structure. To access files on
C:, I had to create a /c folder in cygwin's directory tree and point
C: to it.
> > Just in case that I slime is running a different version of clisp
> > (anything is possible), how can I check with version of clisp I am
> > running. Is there a *lisp-version* like command that can help me
> > identify which clisp I am running?
>
> Interactively, you can use functions such as APROPOS, DESCRIBE and
> DOCUMENTATION:
>
> (apropos "VERSION" "CL")
> (apropos "IMPLEMENTATION" "CL")
Thank you. Staring at the output of (apropos "VERSION") helped me to
find (lisp-implementation-version), which confirmed your suspicions.
>
> (describe 'cl:lisp-implementation-version)
> (documentation 'cl:lisp-implementation-version 'function)
>
> Unfortunately, describe and documentation don't always return useful
> information. Better to refer to the Common Lisp HyperSpec for CL
> stuff, and to your implementation manual for implementation specific
> stuff (and of course, to the documentation or sources of the various
> libraries ("systems") you may use.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NOTE: The most fundamental particles in this product are held
> together by a "gluing" force about which little is currently known
> and whose adhesive power can therefore not be permanently
> guaranteed.
Thanks again,
Mirko
·············@gmail.com writes:
> they are *both* (see below) gnu clisp
> ok. It sai_d_ EVAL: variable *load-paths* has no value
In this case, the difference is in the package used by the current
package. IIRC, the lisp-box cleans the COMMON-LISP-USER package to
avoid implementation dependant importations, like this *LOAD-PATH*
variable which is not a standard variable. You shouldn't take the
habit of using it directly either. Write:
#+clisp CUSTOM:*LOAD-PATH*
#-clisp (error "How do I get the load path in ~A" (lisp-implementation-type))
Well, interactively, you can just type: CUSTOM:*LOAD-PATH*
but in programs, it may be a good idea to mark implementation specific
forms like this.
To clean the CL-USER package yourself, you can add:
;; Clean the packages imported into COMMON-LISP-USER:
(MAPC (LAMBDA (USED) (UNUSE-PACKAGE USED "COMMON-LISP-USER"))
(set-difference
(COPY-SEQ (PACKAGE-USE-LIST "COMMON-LISP-USER"))
(delete nil (list ;; A list of all the "CL" packages possible:
(FIND-PACKAGE "COMMON-LISP")
#| (FIND-PACKAGE "IMAGE-BASED-COMMON-LISP") ... |# ))))
in your ~/.clisprc
> Once I actually moved the directories to a /temp folder, slime &
> lispbox accessed the same clisp, and I get the same behavior:
> lispbox's clisp does not have *load-paths* defined, but can understand
> the windows directory structure. cygwin's clisp has *load-paths*
> defined, but follows a posix directory structure. To access files on
> C:, I had to create a /c folder in cygwin's directory tree and point
> C: to it.
Indeed clisp on cygwin behaves like on a unix system, where the only
valid value for :DEVICE is NIL.
Note that in the *FEATURES*, it has both: :UNIX and :WIN32, IIRC, so
you may write:
(make-pathname :device #-clisp (error "How do I set a device in ~A"
(lisp-implementation-type))
#+(and clisp unix) NIL
#+(and clisp (not unix) win32) "C")
Note that instead of explicitely setting a device, you can also get it
implicitely:
(make-pathname :name "FILE" :type "TXT" :case :common
:defaults (user-homedir-pathname))
Or:
(setf *default-pathname-defaults (user-homedir-pathname))
(make-pathname :name "FILE" :type "TXT" :case :common)
So you don't have to care on what device (or host or directory, etc)
the file is stored, these slots being taken from the defaults pathname.
You can also use logical-pathname to avoid hardcoding these paths, but
I'll leave that to another post.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jul 17, 2:25 am, Pascal Bourguignon <····@informatimago.com> wrote:
> ·············@gmail.com writes:
> > they are *both* (see below) gnu clisp
> > ok. It sai_d_ EVAL: variable *load-paths* has no value
>
> In this case, the difference is in the package used by the current
> package. IIRC, the lisp-box cleans the COMMON-LISP-USER package to
> avoid implementation dependant importations, like this *LOAD-PATH*
> variable which is not a standard variable. You shouldn't take the
> habit of using it directly either. Write:
>
> #+clisp CUSTOM:*LOAD-PATH*
> #-clisp (error "How do I get the load path in ~A" (lisp-implementation-type))
>
> Well, interactively, you can just type: CUSTOM:*LOAD-PATH*
> but in programs, it may be a good idea to mark implementation specific
> forms like this.
>
> To clean the CL-USER package yourself, you can add:
>
> ;; Clean the packages imported into COMMON-LISP-USER:
> (MAPC (LAMBDA (USED) (UNUSE-PACKAGE USED "COMMON-LISP-USER"))
> (set-difference
> (COPY-SEQ (PACKAGE-USE-LIST "COMMON-LISP-USER"))
> (delete nil (list ;; A list of all the "CL" packages possible:
> (FIND-PACKAGE "COMMON-LISP")
> #| (FIND-PACKAGE "IMAGE-BASED-COMMON-LISP") ... |# ))))
>
> in your ~/.clisprc
>
(This is a useful command)
To clarify, I thought that *load-paths* is used by load when searching
for files. I now re-read your reply in this thread: "packages, load
paths and environment" started by Florian Leitner. I did not
appreciate that *load-paths* is not part of the standard.
I was trying to load a bunch of files in the plisp package. The files
are in the compiler and compiler/common-lisp directories of the
distribution. My current implementation is
In .clisp.lisp:
(setq *lisp-dir* (make-pathname :directory '(:absolute
"usr" "local" "share"
"lisp")))
;;(I thought that would be a good place to keep external libraries)
In load-plisp.lisp:
(let* ((plisp-dir (merge-pathnames
(make-pathname :directory '(:relative "plisp"))
*lisp-dir*))
(plisp-compiler-dir (merge-pathnames
(make-pathname :directory '(:relative "compiler"))
plisp-dir))
(plisp-common-lisp-dir (merge-pathnames
(make-pathname :directory
'(:relative "common-lisp"))
plisp-compiler-dir)))
(dolist (x '("vars" "macros" "top" "compile" "output" "defps"
"args" "names" "flow" "util"))
(load (merge-pathnames (make-pathname :name x :type "lisp")
plisp-compiler-dir)) )
(dolist (x '("bind" "control" "functional" "lisp-util"
"loop" "mvalues" "numeric" "for"))
(load (merge-pathnames (make-pathname :name x :type "lisp")
plisp-common-lisp-dir)) )
)
(I am currently trying to figure out if I can simplify this a bit by
specifying *load-pathname* before calling doing a load ...)
> > Once I actually moved the directories to a /temp folder, slime &
> > lispbox accessed the same clisp, and I get the same behavior:
> > lispbox's clisp does not have *load-paths* defined, but can understand
> > the windows directory structure. cygwin's clisp has *load-paths*
> > defined, but follows a posix directory structure. To access files on
> > C:, I had to create a /c folder in cygwin's directory tree and point
> > C: to it.
>
> Indeed clisp on cygwin behaves like on a unix system, where the only
> valid value for :DEVICE is NIL.
>
> Note that in the *FEATURES*, it has both: :UNIX and :WIN32, IIRC, so
> you may write:
>
> (make-pathname :device #-clisp (error "How do I set a device in ~A"
> (lisp-implementation-type))
> #+(and clisp unix) NIL
> #+(and clisp (not unix) win32) "C")
>
> Note that instead of explicitely setting a device, you can also get it
> implicitely:
>
> (make-pathname :name "FILE" :type "TXT" :case :common
> :defaults (user-homedir-pathname))
>
> Or:
>
> (setf *default-pathname-defaults (user-homedir-pathname))
> (make-pathname :name "FILE" :type "TXT" :case :common)
>
> So you don't have to care on what device (or host or directory, etc)
> the file is stored, these slots being taken from the defaults pathname.
I may switch to that. Initially, I wanted to put the various
"libraries" into a systems directory. But I really don't need to do
that at my current level of lisp expertise. Putting them in a /home/
subdirectory should be plenty for now.
>
> You can also use logical-pathname to avoid hardcoding these paths, but
> I'll leave that to another post.
Yes, lets do that some other time :-)
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NOTE: The most fundamental particles in this product are held
> together by a "gluing" force about which little is currently known
> and whose adhesive power can therefore not be permanently
> guaranteed.
Mirko
·············@gmail.com writes:
> In .clisp.lisp:
>
> (setq *lisp-dir* (make-pathname :directory '(:absolute
> "usr" "local" "share"
> "lisp")))
>
> ;;(I thought that would be a good place to keep external libraries)
>
> In load-plisp.lisp:
>
> (let* ((plisp-dir (merge-pathnames
> (make-pathname :directory '(:relative "plisp"))
> *lisp-dir*))
> (plisp-compiler-dir (merge-pathnames
> (make-pathname :directory '(:relative "compiler"))
> plisp-dir))
> (plisp-common-lisp-dir (merge-pathnames
> (make-pathname :directory
> '(:relative "common-lisp"))
> plisp-compiler-dir)))
>
> (dolist (x '("vars" "macros" "top" "compile" "output" "defps"
> "args" "names" "flow" "util"))
> (load (merge-pathnames (make-pathname :name x :type "lisp")
> plisp-compiler-dir)) )
>
> (dolist (x '("bind" "control" "functional" "lisp-util"
> "loop" "mvalues" "numeric" "for"))
> (load (merge-pathnames (make-pathname :name x :type "lisp")
> plisp-common-lisp-dir)) )
> )
>
> (I am currently trying to figure out if I can simplify this a bit by
> specifying *load-pathname* before calling doing a load ...)
*LOAD-PATHNAME* is set by LOAD to let the file know what it is.
Otherwise it should be NIL.
What you can use is *DEFAULT-PATHNAME-DEFAULTS*:
(let ((*DEFAULT-PATHNAME-DEFAULTS* *list-dir*))
(dolist (x ...)
(load (make-pathname :name x :type "lisp"))))
Here is how you can use *LOAD-PATHNAME*:
-----------(loader.lisp)------------
(defparameter *resources-dir*
(merge-pathnames
(make-pathname :directory '(:relative "resources")
:name nil :type nil :version nil
:defaults *load-pathname*)
*load-pathname* nil))
(dolist (file '("packages" "macros" "utilities" "stuff" "application"))
(load (make-pathname :name file :defaults *load-pathname*)))
------------------------------------
So now, when you run:
(load "/some/path/to/loader.lisp")
LOAD will bind *LOAD-PATHNAME* to the truename of loader.lisp, and
the make-pathname will therefore build the pathname of the other files
in that same directory, and *RESOURCE-DIR* will refer a sub directory
in the same directory where the sources are, so the application can
use it to find other resource files.
Note how I pass *LOAD-PATHNAME* both as :DEFAULTS to MAKE-PATHNAME and
as second argument to MERGE-PATHNAMES. In MAKE-PATHNAME, it's to
build a correct pathname in the same HOST and DEVICE as the
*LOAD-PATHNAME*, so the merge can be done correctly. When you mix
different kind of pathnames (logical vs. physical), or pathnames with
devices on MS-Windows, it is important to use the right defaults.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.