clisp-devel — closed list for developers and testers

[ clisp-Bugs-3451264 ] odd error with sort

[SourceForge.net <no...@so...>]

Bugs item #3451264, was opened at 2011-12-05 03:40
Message generated for change (Comment added) made by litwr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3451264&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Vladimir Lidovski (litwr)
Assigned to: Sam Steingold (sds)
Summary: odd error with sort

Initial Comment:
It is about GNU CLISP strange behaviours. The version 2.33/2.48/2.49 were tested. Can anybody explain this oddness?

(defun xsort (l) (sort l #'<)) ;XSORT
(setq l '(3 1 2)) ;(3 1 2)
(xsort l) ;(1 2 3)
l ; surprize! (1 2 3)

The ordinal lisp function XSORT takes its argument by value but the presence of SORT-function in its body converts argument to passed by reference! Are there any reasonable explanation? BTW the POP-function doesn't make surprize:

(defun xpop (l) (pop l)) ;XPOP
(setq l '(3 1 2)) ;(3 1 2)
(xpop l) ;3
l ;(3 2 1)


----------------------------------------------------------------------

>Comment By: Vladimir Lidovski (litwr)
Date: 2011-12-07 00:05

Message:
Thank you. These behaviours of SORT can produce nightmare side effects. The
SORT is destructive. This is ok but XSORT is programmed as normal function!
IMHO these odd things should be well documented. IMHO this is severe bug
without proper documentation.


----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2011-12-05 08:43

Message:
This is the way lisp works.
sort is a destructive function, it modifies the list structure.
other CL implementations use different modifications, so l might not be the
sorted list.
however, both behaviors are standard-compliant.
try this:
(setq m l)
(setq s (xsort l))
(eq m l) ==> t, because xsort cannot modify l
(eq s l) ==> t, because that's how clisp works

pop is a macro, so it modifies the its argument's value.
xpop is a function, so it cannot modify the value of l.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2011-12-05 08:43

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3451264&group_id=1355

[ clisp-Bugs-3452284 ] #'get DEFAULT value for existent properties with a value nil

[SourceForge.net <no...@so...>]

Bugs item #3452284, was opened at 2011-12-06 03:17
Message generated for change (Tracker Item Submitted) made by jakwings
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3452284&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jak Wings (jakwings)
Assigned to: Bruno Haible (haible)
Summary: #'get DEFAULT value for existent properties with a value nil

Initial Comment:
Sorry, my English is a little poor.

Linux name 2.6.38-13-generic #52-Ubuntu SMP Tue Nov 8 16:48:07 UTC 2011 i686 i686 i386 GNU/Linux

I build it just by "sudo apt-get install clisp"

~$ clisp --version
GNU CLISP 2.48 (2009-07-28) (built 3508041772) (memory 3527376723)
Software: GNU C 4.5.2 
i686-linux-gnu-gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -Wl,-Bsymbolic-functions  /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 5.2
Features: 
(ASDF2 ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER BERKELEY-DB
 CLX-ANSI-COMMON-LISP CLX READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP
 CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS
 LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline linux clx bdb)
Installation directory: /usr/lib/clisp-2.48/
User language: ENGLISH
Machine: I686 (I686) name [127.0.1.1]

PROBLEM:

[29]> (symbol-plist 'cat)
(ORGIN NIL SIZE SMALL SEX FEMALE)
[30]> (get 'cat 'origin 'unknown)
UNKNOWN
[31]> (get 'cat 'origin-ex 'unknown)
UNKNOWN
The book《Common Lisp: An Introduction to Symbolic Computation》says, "There is one way to distinguish a symbol having a property FOO with value
NIL from a symbol that does not have a FOO property at all."
SO, is this a implementation problem?
Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3452284&group_id=1355

[ clisp-Bugs-3450953 ] self-recursive dead-link

[SourceForge.net <no...@so...>]

Bugs item #3450953, was opened at 2011-12-04 19:54
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Open
>Resolution: None
Priority: 5
Private: No
Submitted By: Gabor Balazs (gabalz)
Assigned to: Bruno Haible (haible)
Summary: self-recursive dead-link

Initial Comment:

CLISP cannot probe/list a dead link which points to itself.
The probe-file, probe-pathname, directory functions always end up in an infinite loop which results to a UNIX error.

Setup:
~~~~

mkdir /tmp/TEST
cd /tmp/TEST
ln -s dead dead
ls -l dead
lrwxrwxrwx 1 bege users 4 Dec  4 20:45 dead -> dead

Problem:
~~~~~~

CLISP> (probe-pathname "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (probe-file "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep :circle t)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

Desired behavior:
~~~~~~~~~~~~~

CLISP> (probe-file "dead") => NIL
CLISP> (probe-pathname "dead") => NIL

CLISP> (directory "./*" :if-does-not-exist :keep) => (#P"/tmp/TEST/dead")
or
CLISP> (directory "./*" :if-does-not-exist :keep :circle t) => (#P"/tmp/TEST/dead")

Version:
~~~~~~
GNU CLISP 2.49 (2010-07-07) (built 3529014440) (memory 3529014964)
Software: GNU C 4.5.3 
gcc -O2 -march=core2 -fomit-frame-pointer -pipe -Wa,--noexecstack -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -Wl,-O1 -Wl,--as-needed  /usr/lib64/libreadline.so -lncurses -ldl /usr/lib64/libavcall.a /usr/lib64/libcallback.a  -L/usr/lib64 -lsigsegv -L/usr/lib64 -lc libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
libreadline 6.2
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER MT SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib64/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) localhost [127.0.0.1]

`bg`


----------------------------------------------------------------------

>Comment By: Sam Steingold (sds)
Date: 2011-12-05 11:13

Message:
Throwing a system error is, effectively, an admission of defeat.
CLISP can do better.

----------------------------------------------------------------------

Comment By: Gabor Balazs (gabalz)
Date: 2011-12-05 11:10

Message:
Furthermore, the error situation is not swept under the rug. It could be
handled exactly the same way as usual dead link. When the dead link is not
self-recursive, one can list it by the (directory "./*" :full t
:if-does-not-exist :keep) call. When the link is dead, the corresponding
entry will be a single pathname instead of a (file-pathname file-truename
file-write-date-as-decoded-time file-length) list. This is how dead links
can be found in CLISP. Then based on the pathname, it is possible to check
whether a dead link is self-recursive or not. So I don't see any
information being lost by my proposal.

----------------------------------------------------------------------

Comment By: Gabor Balazs (gabalz)
Date: 2011-12-05 11:05

Message:
Some rationale:

ABCL, CCL, ECL, SBCL, SCL can handle this situation without error.

The ls, ls -l UNIX commands can handle this situation without error.

But most importantly, a self-recursive dead link cannot be listed in CLISP.
The directory command will always result an ELOOP error without the
:discard or :ignore options. So the directory function either ignores these
dead links completely or produces an error. This means that such
self-recursive dead links cannot be handled in CLISP at all and directories
having them cannot be deleted as well.

It would be desirable to have an option for the directory function with
which it is able to list these self-recursive dead links too.


----------------------------------------------------------------------

Comment By: Bruno Haible (haible)
Date: 2011-12-05 10:41

Message:
When there is a cycle in the resolution of symbolic links, it is not one of
the common situations:
- A link without target can be fixed by adding a file at the target
location.
- A link with target can be open()ed.
The UNIX designers found it useful to assign the error code ELOOP to a
situation other than these two.

I don't see a compelling reason why CLISP should deviate from the usual
UNIX treatment of this situation.

What you propose is equivalent to sweeping an error situation under the
rug.
This is sometimes justified, with a good, compelling, convincing,
universally accepted rationale.
But you have not provided such a rationale in this case.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

[ clisp-Bugs-3450953 ] self-recursive dead-link

[SourceForge.net <no...@so...>]

Bugs item #3450953, was opened at 2011-12-04 19:54
Message generated for change (Comment added) made by gabalz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Gabor Balazs (gabalz)
Assigned to: Bruno Haible (haible)
Summary: self-recursive dead-link

Initial Comment:

CLISP cannot probe/list a dead link which points to itself.
The probe-file, probe-pathname, directory functions always end up in an infinite loop which results to a UNIX error.

Setup:
~~~~

mkdir /tmp/TEST
cd /tmp/TEST
ln -s dead dead
ls -l dead
lrwxrwxrwx 1 bege users 4 Dec  4 20:45 dead -> dead

Problem:
~~~~~~

CLISP> (probe-pathname "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (probe-file "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep :circle t)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

Desired behavior:
~~~~~~~~~~~~~

CLISP> (probe-file "dead") => NIL
CLISP> (probe-pathname "dead") => NIL

CLISP> (directory "./*" :if-does-not-exist :keep) => (#P"/tmp/TEST/dead")
or
CLISP> (directory "./*" :if-does-not-exist :keep :circle t) => (#P"/tmp/TEST/dead")

Version:
~~~~~~
GNU CLISP 2.49 (2010-07-07) (built 3529014440) (memory 3529014964)
Software: GNU C 4.5.3 
gcc -O2 -march=core2 -fomit-frame-pointer -pipe -Wa,--noexecstack -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -Wl,-O1 -Wl,--as-needed  /usr/lib64/libreadline.so -lncurses -ldl /usr/lib64/libavcall.a /usr/lib64/libcallback.a  -L/usr/lib64 -lsigsegv -L/usr/lib64 -lc libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
libreadline 6.2
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER MT SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib64/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) localhost [127.0.0.1]

`bg`


----------------------------------------------------------------------

Comment By: Gabor Balazs (gabalz)
Date: 2011-12-05 11:10

Message:
Furthermore, the error situation is not swept under the rug. It could be
handled exactly the same way as usual dead link. When the dead link is not
self-recursive, one can list it by the (directory "./*" :full t
:if-does-not-exist :keep) call. When the link is dead, the corresponding
entry will be a single pathname instead of a (file-pathname file-truename
file-write-date-as-decoded-time file-length) list. This is how dead links
can be found in CLISP. Then based on the pathname, it is possible to check
whether a dead link is self-recursive or not. So I don't see any
information being lost by my proposal.

----------------------------------------------------------------------

Comment By: Gabor Balazs (gabalz)
Date: 2011-12-05 11:05

Message:
Some rationale:

ABCL, CCL, ECL, SBCL, SCL can handle this situation without error.

The ls, ls -l UNIX commands can handle this situation without error.

But most importantly, a self-recursive dead link cannot be listed in CLISP.
The directory command will always result an ELOOP error without the
:discard or :ignore options. So the directory function either ignores these
dead links completely or produces an error. This means that such
self-recursive dead links cannot be handled in CLISP at all and directories
having them cannot be deleted as well.

It would be desirable to have an option for the directory function with
which it is able to list these self-recursive dead links too.


----------------------------------------------------------------------

Comment By: Bruno Haible (haible)
Date: 2011-12-05 10:41

Message:
When there is a cycle in the resolution of symbolic links, it is not one of
the common situations:
- A link without target can be fixed by adding a file at the target
location.
- A link with target can be open()ed.
The UNIX designers found it useful to assign the error code ELOOP to a
situation other than these two.

I don't see a compelling reason why CLISP should deviate from the usual
UNIX treatment of this situation.

What you propose is equivalent to sweeping an error situation under the
rug.
This is sometimes justified, with a good, compelling, convincing,
universally accepted rationale.
But you have not provided such a rationale in this case.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

[ clisp-Bugs-3450953 ] self-recursive dead-link

[SourceForge.net <no...@so...>]

Bugs item #3450953, was opened at 2011-12-04 19:54
Message generated for change (Comment added) made by gabalz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Gabor Balazs (gabalz)
Assigned to: Bruno Haible (haible)
Summary: self-recursive dead-link

Initial Comment:

CLISP cannot probe/list a dead link which points to itself.
The probe-file, probe-pathname, directory functions always end up in an infinite loop which results to a UNIX error.

Setup:
~~~~

mkdir /tmp/TEST
cd /tmp/TEST
ln -s dead dead
ls -l dead
lrwxrwxrwx 1 bege users 4 Dec  4 20:45 dead -> dead

Problem:
~~~~~~

CLISP> (probe-pathname "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (probe-file "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep :circle t)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

Desired behavior:
~~~~~~~~~~~~~

CLISP> (probe-file "dead") => NIL
CLISP> (probe-pathname "dead") => NIL

CLISP> (directory "./*" :if-does-not-exist :keep) => (#P"/tmp/TEST/dead")
or
CLISP> (directory "./*" :if-does-not-exist :keep :circle t) => (#P"/tmp/TEST/dead")

Version:
~~~~~~
GNU CLISP 2.49 (2010-07-07) (built 3529014440) (memory 3529014964)
Software: GNU C 4.5.3 
gcc -O2 -march=core2 -fomit-frame-pointer -pipe -Wa,--noexecstack -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -Wl,-O1 -Wl,--as-needed  /usr/lib64/libreadline.so -lncurses -ldl /usr/lib64/libavcall.a /usr/lib64/libcallback.a  -L/usr/lib64 -lsigsegv -L/usr/lib64 -lc libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
libreadline 6.2
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER MT SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib64/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) localhost [127.0.0.1]

`bg`


----------------------------------------------------------------------

Comment By: Gabor Balazs (gabalz)
Date: 2011-12-05 11:05

Message:
Some rationale:

ABCL, CCL, ECL, SBCL, SCL can handle this situation without error.

The ls, ls -l UNIX commands can handle this situation without error.

But most importantly, a self-recursive dead link cannot be listed in CLISP.
The directory command will always result an ELOOP error without the
:discard or :ignore options. So the directory function either ignores these
dead links completely or produces an error. This means that such
self-recursive dead links cannot be handled in CLISP at all and directories
having them cannot be deleted as well.

It would be desirable to have an option for the directory function with
which it is able to list these self-recursive dead links too.


----------------------------------------------------------------------

Comment By: Bruno Haible (haible)
Date: 2011-12-05 10:41

Message:
When there is a cycle in the resolution of symbolic links, it is not one of
the common situations:
- A link without target can be fixed by adding a file at the target
location.
- A link with target can be open()ed.
The UNIX designers found it useful to assign the error code ELOOP to a
situation other than these two.

I don't see a compelling reason why CLISP should deviate from the usual
UNIX treatment of this situation.

What you propose is equivalent to sweeping an error situation under the
rug.
This is sometimes justified, with a good, compelling, convincing,
universally accepted rationale.
But you have not provided such a rationale in this case.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

[ clisp-Bugs-3450953 ] self-recursive dead-link

[SourceForge.net <no...@so...>]

Bugs item #3450953, was opened at 2011-12-04 19:54
Message generated for change (Comment added) made by haible
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Gabor Balazs (gabalz)
Assigned to: Bruno Haible (haible)
Summary: self-recursive dead-link

Initial Comment:

CLISP cannot probe/list a dead link which points to itself.
The probe-file, probe-pathname, directory functions always end up in an infinite loop which results to a UNIX error.

Setup:
~~~~

mkdir /tmp/TEST
cd /tmp/TEST
ln -s dead dead
ls -l dead
lrwxrwxrwx 1 bege users 4 Dec  4 20:45 dead -> dead

Problem:
~~~~~~

CLISP> (probe-pathname "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (probe-file "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep :circle t)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

Desired behavior:
~~~~~~~~~~~~~

CLISP> (probe-file "dead") => NIL
CLISP> (probe-pathname "dead") => NIL

CLISP> (directory "./*" :if-does-not-exist :keep) => (#P"/tmp/TEST/dead")
or
CLISP> (directory "./*" :if-does-not-exist :keep :circle t) => (#P"/tmp/TEST/dead")

Version:
~~~~~~
GNU CLISP 2.49 (2010-07-07) (built 3529014440) (memory 3529014964)
Software: GNU C 4.5.3 
gcc -O2 -march=core2 -fomit-frame-pointer -pipe -Wa,--noexecstack -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -Wl,-O1 -Wl,--as-needed  /usr/lib64/libreadline.so -lncurses -ldl /usr/lib64/libavcall.a /usr/lib64/libcallback.a  -L/usr/lib64 -lsigsegv -L/usr/lib64 -lc libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
libreadline 6.2
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER MT SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib64/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) localhost [127.0.0.1]

`bg`


----------------------------------------------------------------------

>Comment By: Bruno Haible (haible)
Date: 2011-12-05 10:41

Message:
When there is a cycle in the resolution of symbolic links, it is not one of
the common situations:
- A link without target can be fixed by adding a file at the target
location.
- A link with target can be open()ed.
The UNIX designers found it useful to assign the error code ELOOP to a
situation other than these two.

I don't see a compelling reason why CLISP should deviate from the usual
UNIX treatment of this situation.

What you propose is equivalent to sweeping an error situation under the
rug.
This is sometimes justified, with a good, compelling, convincing,
universally accepted rationale.
But you have not provided such a rationale in this case.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

[ clisp-Bugs-3451264 ] odd error with sort

[SourceForge.net <no...@so...>]

Bugs item #3451264, was opened at 2011-12-05 03:40
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3451264&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Vladimir Lidovski (litwr)
>Assigned to: Sam Steingold (sds)
Summary: odd error with sort

Initial Comment:
It is about GNU CLISP strange behaviours. The version 2.33/2.48/2.49 were tested. Can anybody explain this oddness?

(defun xsort (l) (sort l #'<)) ;XSORT
(setq l '(3 1 2)) ;(3 1 2)
(xsort l) ;(1 2 3)
l ; surprize! (1 2 3)

The ordinal lisp function XSORT takes its argument by value but the presence of SORT-function in its body converts argument to passed by reference! Are there any reasonable explanation? BTW the POP-function doesn't make surprize:

(defun xpop (l) (pop l)) ;XPOP
(setq l '(3 1 2)) ;(3 1 2)
(xpop l) ;3
l ;(3 2 1)


----------------------------------------------------------------------

>Comment By: Sam Steingold (sds)
Date: 2011-12-05 08:43

Message:
This is the way lisp works.
sort is a destructive function, it modifies the list structure.
other CL implementations use different modifications, so l might not be the
sorted list.
however, both behaviors are standard-compliant.
try this:
(setq m l)
(setq s (xsort l))
(eq m l) ==> t, because xsort cannot modify l
(eq s l) ==> t, because that's how clisp works

pop is a macro, so it modifies the its argument's value.
xpop is a function, so it cannot modify the value of l.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2011-12-05 08:43

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3451264&group_id=1355

[ clisp-Bugs-3451264 ] odd error with sort

[SourceForge.net <no...@so...>]

Bugs item #3451264, was opened at 2011-12-05 03:40
Message generated for change (Tracker Item Submitted) made by litwr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3451264&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimir Lidovski (litwr)
Assigned to: Bruno Haible (haible)
Summary: odd error with sort

Initial Comment:
It is about GNU CLISP strange behaviours. The version 2.33/2.48/2.49 were tested. Can anybody explain this oddness?

(defun xsort (l) (sort l #'<)) ;XSORT
(setq l '(3 1 2)) ;(3 1 2)
(xsort l) ;(1 2 3)
l ; surprize! (1 2 3)

The ordinal lisp function XSORT takes its argument by value but the presence of SORT-function in its body converts argument to passed by reference! Are there any reasonable explanation? BTW the POP-function doesn't make surprize:

(defun xpop (l) (pop l)) ;XPOP
(setq l '(3 1 2)) ;(3 1 2)
(xpop l) ;3
l ;(3 2 1)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3451264&group_id=1355

[ clisp-Bugs-3450953 ] self-recursive dead-link

[SourceForge.net <no...@so...>]

Bugs item #3450953, was opened at 2011-12-04 19:54
Message generated for change (Tracker Item Submitted) made by gabalz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gabor Balazs (gabalz)
Assigned to: Bruno Haible (haible)
Summary: self-recursive dead-link

Initial Comment:

CLISP cannot probe/list a dead link which points to itself.
The probe-file, probe-pathname, directory functions always end up in an infinite loop which results to a UNIX error.

Setup:
~~~~

mkdir /tmp/TEST
cd /tmp/TEST
ln -s dead dead
ls -l dead
lrwxrwxrwx 1 bege users 4 Dec  4 20:45 dead -> dead

Problem:
~~~~~~

CLISP> (probe-pathname "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (probe-file "dead")
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

CLISP> (directory "./*" :if-does-not-exist :keep :circle t)
*** - UNIX error 40 (ELOOP): Too many levels of symbolic links

Desired behavior:
~~~~~~~~~~~~~

CLISP> (probe-file "dead") => NIL
CLISP> (probe-pathname "dead") => NIL

CLISP> (directory "./*" :if-does-not-exist :keep) => (#P"/tmp/TEST/dead")
or
CLISP> (directory "./*" :if-does-not-exist :keep :circle t) => (#P"/tmp/TEST/dead")

Version:
~~~~~~
GNU CLISP 2.49 (2010-07-07) (built 3529014440) (memory 3529014964)
Software: GNU C 4.5.3 
gcc -O2 -march=core2 -fomit-frame-pointer -pipe -Wa,--noexecstack -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -Wl,-O1 -Wl,--as-needed  /usr/lib64/libreadline.so -lncurses -ldl /usr/lib64/libavcall.a /usr/lib64/libcallback.a  -L/usr/lib64 -lsigsegv -L/usr/lib64 -lc libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
libreadline 6.2
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER MT SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib64/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) localhost [127.0.0.1]

`bg`


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3450953&group_id=1355

Re: feature wish: init file

[Anton V. <avo...@ya...>]

02.11.2011, 09:11, "Raymond Toy" <toy...@gm...>:

>  On 11/1/11 3:06 AM, Anton Vodonosov wrote:
>>   I am on Windows 7, CLISP 2.49, Emacs 23.2.1, slime-20110730-cvs.
>  Oh.  Perhaps that's a problem on windows or with your version of slime.
>  I ran my test on Mac OS X with slime 2011-08-18 and xemacs 21.5beta.

For the record, I found the reason.

It's Emacs.

It wants to use environment variable HOME to determine the location where
to store the .emacs file. On Windows HOME is usually absent,
and Emacs then uses APPDATA variable instead. 

So far OK.

But then Emacs sets the HOME variable to the value of APPDATA.

The processes it starts (e.g. lisp implementation for slime) inherit the HOME
variable.

On Windows my home directory is C:\Users\anton\. 
APPDATA points to C:\Users\anton\AppData\Roaming\.

CLISP (and other lisps) determine C:\Users\anton as the value of
(user-homedir-pathname), even it the HOME environment variable is absent.
And that's where .clisprc.lisp is stored.

But when they inherit HOME from Emacs, they use it's value (which
is set by Emacs to C:\Users\anton\AppData\Roaming\), and .clisprc 
is not found.

Best regards,
- Anton

[ clisp-Bugs-3432970 ] Case-sensitive structs miscompiled? [suggested fix]

[SourceForge.net <no...@so...>]

Bugs item #3432970, was opened at 2011-11-03 13:37
Message generated for change (Comment added) made by mak08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Kappert (mak08)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Case-sensitive structs miscompiled? [suggested fix]

Initial Comment:
It seems that keywords are stored incorrectly in the fasl for case-sensitive struct literals:

$ cat struct-case.cl
(defpackage "STORE" (:modern t))
(in-package store)

(defstruct book title author)

(defmacro defbook-expand (title author)
  (make-book :title title :author author))

(defvar *et-book* (defbook-expand  "aTitle" "anAuthor"))
......
cs-user> (compile-file "/home/michael/Projects/scratch/struct-case.cl")
;; Compiling file /home/michael/Projects/scratch/struct-case.cl ...
;; Wrote file /home/michael/Projects/scratch/struct-case.fas
0 errors, 0 warnings
#P"/home/michael/Projects/scratch/struct-case.fas"
nil
nil
cs-user> (load *)
;; Loading file /home/michael/Projects/scratch/struct-case.fas ...
; Evaluation aborted on #<system::simple-keyword-error #x0003348AA920>.
cs-user> 

The struct literal appears in the fasl as
S(|STORE|::|book| :|title| "aTitle" :|author| "anAuthor")


----------------------------------------------------------------------

>Comment By: Michael Kappert (mak08)
Date: 2011-11-07 12:55

Message:
This is probably much too crude, but it fixes the problem for me: I think
keywords should always be printed in upppercase in pr_structure_default. I
could see no regressions in make check (tested only on Ubuntu). 

diff -r 8f5a8b96a72d src/io.d
--- a/src/io.d	Mon Oct 17 14:59:11 2011 +0300
+++ b/src/io.d	Mon Nov 07 21:48:12 2011 +0100
@@ -8409,7 +8409,7 @@
         {    /* Print (symbol-name (clos:slot-definition-name slot)): */
           var object obj = TheSlotDefinition(*slot_)->slotdef_name;
           if (!symbolp(obj)) goto bad_clas;
-          pr_like_symbol(stream_,Symbol_name(obj)); /* print symbolname
of component */
+          pr_symbol_part(stream_,Symbol_name(obj),false,false); /* print
symbolname of component */
         }
         JUSTIFY_SPACE;
         JUSTIFY_LAST(true);


----------------------------------------------------------------------

Comment By: Michael Kappert (mak08)
Date: 2011-11-04 14:58

Message:
Now it seems more like a bug in the print-object method for structs:
cs-user> (defstruct foo bar)
foo
cs-user> (let ((*print-readably* nil)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
#S(foo :bar "bar")
18
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB220>.
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :BAR "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB240>.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

[ clisp-Bugs-3432970 ] Case-sensitive structs miscompiled?

[SourceForge.net <no...@so...>]

Bugs item #3432970, was opened at 2011-11-03 13:37
Message generated for change (Comment added) made by mak08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Kappert (mak08)
Assigned to: Nobody/Anonymous (nobody)
Summary: Case-sensitive structs miscompiled?

Initial Comment:
It seems that keywords are stored incorrectly in the fasl for case-sensitive struct literals:

$ cat struct-case.cl
(defpackage "STORE" (:modern t))
(in-package store)

(defstruct book title author)

(defmacro defbook-expand (title author)
  (make-book :title title :author author))

(defvar *et-book* (defbook-expand  "aTitle" "anAuthor"))
......
cs-user> (compile-file "/home/michael/Projects/scratch/struct-case.cl")
;; Compiling file /home/michael/Projects/scratch/struct-case.cl ...
;; Wrote file /home/michael/Projects/scratch/struct-case.fas
0 errors, 0 warnings
#P"/home/michael/Projects/scratch/struct-case.fas"
nil
nil
cs-user> (load *)
;; Loading file /home/michael/Projects/scratch/struct-case.fas ...
; Evaluation aborted on #<system::simple-keyword-error #x0003348AA920>.
cs-user> 

The struct literal appears in the fasl as
S(|STORE|::|book| :|title| "aTitle" :|author| "anAuthor")


----------------------------------------------------------------------

>Comment By: Michael Kappert (mak08)
Date: 2011-11-04 14:58

Message:
Now it seems more like a bug in the print-object method for structs:
cs-user> (defstruct foo bar)
foo
cs-user> (let ((*print-readably* nil)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
#S(foo :bar "bar")
18
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :bar "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB220>.
cs-user> (let ((*print-readably* t)) (read-from-string (format nil "~s"
#s(foo :BAR "bar"))))
; Evaluation aborted on #<system::simple-keyword-error #x0003348EB240>.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

[ clisp-Bugs-3432970 ] Case-sensitive structs miscompiled?

[SourceForge.net <no...@so...>]

Bugs item #3432970, was opened at 2011-11-03 13:37
Message generated for change (Tracker Item Submitted) made by mak08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Kappert (mak08)
Assigned to: Nobody/Anonymous (nobody)
Summary: Case-sensitive structs miscompiled?

Initial Comment:
It seems that keywords are stored incorrectly in the fasl for case-sensitive struct literals:

$ cat struct-case.cl
(defpackage "STORE" (:modern t))
(in-package store)

(defstruct book title author)

(defmacro defbook-expand (title author)
  (make-book :title title :author author))

(defvar *et-book* (defbook-expand  "aTitle" "anAuthor"))
......
cs-user> (compile-file "/home/michael/Projects/scratch/struct-case.cl")
;; Compiling file /home/michael/Projects/scratch/struct-case.cl ...
;; Wrote file /home/michael/Projects/scratch/struct-case.fas
0 errors, 0 warnings
#P"/home/michael/Projects/scratch/struct-case.fas"
nil
nil
cs-user> (load *)
;; Loading file /home/michael/Projects/scratch/struct-case.fas ...
; Evaluation aborted on #<system::simple-keyword-error #x0003348AA920>.
cs-user> 

The struct literal appears in the fasl as
S(|STORE|::|book| :|title| "aTitle" :|author| "anAuthor")


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3432970&group_id=1355

Re: feature wish: init file

[Raymond T. <toy...@gm...>]

On 11/1/11 3:06 AM, Anton Vodonosov wrote:
> Hello.
>
> 01.11.2011, 06:32, "Raymond Toy" <toy...@gm...>:
>> On 10/31/11 2:43 PM, Anton Vodonosov wrote:
>>
>>>  Is it possible to have some init file for CLISP which is executed always
>>>  (in contrast to .clisprc which is executed only when CLISP is started with
>>>  REPL, but not when started from SLIME).
>> Do you mean slime starts clisp without loading .clisprc?   Because clisp
>> does load .clisprc when I start clisp with slime.
> Yes, for me .clisprc is not loaded. 
>
> I am on Windows 7, CLISP 2.49, Emacs 23.2.1, slime-20110730-cvs.

Oh.  Perhaps that's a problem on windows or with your version of slime. 
I ran my test on Mac OS X with slime 2011-08-18 and xemacs 21.5beta.

Ray

Re: feature wish: init file

[Anton V. <avo...@ya...>]

01.11.2011, 14:06, "Anton Vodonosov" <avo...@ya...>:

> And another possibility would be to install quicklisp loader (or init file loader)
> is CUSTOM:*INIT-HOOKS* (http://www.clisp.org/impnotes/custom-init-fini.html#init-hooks).
>
> E.e.
>    (push (lambda () (load (merge-pathnames "my-clisp-init.lisp" (user-homedir-pathname)))))
> before saving the image [the code is not tested].
>

I mean
    (push (lambda () (load (merge-pathnames "my-clisp-init.lisp" (user-homedir-pathname))))
          CUSTOM:*INIT-HOOKS*)

Re: feature wish: init file

[Anton V. <avo...@ya...>]

Hello.

01.11.2011, 06:32, "Raymond Toy" <toy...@gm...>:
> On 10/31/11 2:43 PM, Anton Vodonosov wrote:
>
>>  Is it possible to have some init file for CLISP which is executed always
>>  (in contrast to .clisprc which is executed only when CLISP is started with
>>  REPL, but not when started from SLIME).
>
> Do you mean slime starts clisp without loading .clisprc?   Because clisp
> does load .clisprc when I start clisp with slime.

Yes, for me .clisprc is not loaded. 

I am on Windows 7, CLISP 2.49, Emacs 23.2.1, slime-20110730-cvs.

In .emacs I have 
(setq inferior-lisp-program "clisp.exe")


01.11.2011, 06:58, "Pascal J. Bourguignon" <pj...@in...>:

> Now that I think about it, if quicklisp hardwires pathnames, then you
> could instead load it when you load the image by setting a init
> function:
>
> clisp -q -norc -ansi
> ;; No change to the original image, but:
> (ext:saveinitmem "~/bin/ql-clisp"
>                  :executable t
>                  :init-function (lambda ()
>                                   (let ((quicklisp-init (merge-pathnames
>                                         "quicklisp/setup.lisp" (user-homedir-pathname))))
>                                      (when (probe-file quicklisp-init)
>                                         (load quicklisp-init)))))
>
> Also, for global scripts, you could install quicklisp in a global
> location and use it instead of a user specific quicklisp installation.

And another possibility would be to install quicklisp loader (or init file loader) 
is CUSTOM:*INIT-HOOKS* (http://www.clisp.org/impnotes/custom-init-fini.html#init-hooks).

E.e.  
   (push (lambda () (load (merge-pathnames "my-clisp-init.lisp" (user-homedir-pathname)))))
before saving the image [the code is not tested].

Best regards,
- Anton

Re: feature wish: init file

[Pascal J. B. <pj...@in...>]

"Fernando L. Canizo" <co...@lu...> writes:

> On Mon, 31 Oct 2011 22:56:44 +0100, "Pascal J. Bourguignon"
> <pj...@in...> wrote:
>
>> Anton Vodonosov <avo...@ya...> writes:
>> 
>> > Is it possible to have some init file for CLISP which is executed
>> 
>> clisp -q -norc -ansi
>> (load "quicklisp/setup.lisp")
>> (ext:save-init-mem "~/bin/ql-clisp" :executable t)
>> (ext:quit)
>> 
>> and now on use ~/bin/ql-clisp instead of clisp.
>> 
>> Not tested, it may not work.  Notably, quicklisp/setup.lisp probably
>> hard-wires pathnames, so it probably won't work if launched from
>> another account.
>
> I tried it verbatim and it didn't worked, it seems in my installation
> ext:save-init-mem is mapped to saveinitmem, in fact I have no package
> EXT.

No, it's me, I didn't try and didn't remember that saveinitmem is a word
in clisp ;-) Sorry about that.


> But I made it work like this:
>
> $ clisp -q -norc -ansi
> ;; this is suggested configuration for rc file by quicklisp docs
> (let ((quicklisp-init (merge-pathnames
>       "quicklisp/setup.lisp" (user-homedir-pathname)))) 
>    (when (probe-file quicklisp-init) 
>       (load quicklisp-init)))
> (saveinitmem "~/bin/ql-clisp" :executable t)
> (quit)

Now that I think about it, if quicklisp hardwires pathnames, then you
could instead load it when you load the image by setting a init
function:

clisp -q -norc -ansi
;; No change to the original image, but:
(ext:saveinitmem "~/bin/ql-clisp"
                 :executable t
                 :init-function (lambda ()
                                  (let ((quicklisp-init (merge-pathnames
                                        "quicklisp/setup.lisp" (user-homedir-pathname)))) 
                                     (when (probe-file quicklisp-init) 
                                        (load quicklisp-init)))))

                                        
Also, for global scripts, you could install quicklisp in a global
location and use it instead of a user specific quicklisp installation.
 
-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: feature wish: init file

[Raymond T. <toy...@gm...>]

On 10/31/11 2:43 PM, Anton Vodonosov wrote:
> Hello.
>
> Is it possible to have some init file for CLISP which is executed always 
> (in contrast to .clisprc which is executed only when CLISP is started with
> REPL, but not when started from SLIME).

Do you mean slime starts clisp without loading .clisprc?   Because clisp
does load .clisprc when I start clisp with slime.

Ray

Re: feature wish: init file

[Fernando L. C. <co...@lu...>]

On Mon, 31 Oct 2011 22:56:44 +0100, "Pascal J. Bourguignon"
<pj...@in...> wrote:

> Anton Vodonosov <avo...@ya...> writes:
> 
> > Is it possible to have some init file for CLISP which is executed
> 
> clisp -q -norc -ansi
> (load "quicklisp/setup.lisp")
> (ext:save-init-mem "~/bin/ql-clisp" :executable t)
> (ext:quit)
> 
> and now on use ~/bin/ql-clisp instead of clisp.
> 
> Not tested, it may not work.  Notably, quicklisp/setup.lisp probably
> hard-wires pathnames, so it probably won't work if launched from
> another account.

I tried it verbatim and it didn't worked, it seems in my installation
ext:save-init-mem is mapped to saveinitmem, in fact I have no package
EXT.

But I made it work like this:

$ clisp -q -norc -ansi
;; this is suggested configuration for rc file by quicklisp docs
(let ((quicklisp-init (merge-pathnames
      "quicklisp/setup.lisp" (user-homedir-pathname)))) 
   (when (probe-file quicklisp-init) 
      (load quicklisp-init)))
(saveinitmem "~/bin/ql-clisp" :executable t)
(quit)

-- 
Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++

Re: feature wish: init file

[Pascal J. B. <pj...@in...>]

Anton Vodonosov <avo...@ya...> writes:

> Is it possible to have some init file for CLISP which is executed always 
> (in contrast to .clisprc which is executed only when CLISP is started with
> REPL, but not when started from SLIME).
>
> The motivation is to have quicklisp always available for lisp code executed
> by CLISP.

clisp -q -norc -ansi
(load "quicklisp/setup.lisp")
(ext:save-init-mem "~/bin/ql-clisp" :executable t)
(ext:quit)

and now on use ~/bin/ql-clisp instead of clisp.

Not tested, it may not work.  Notably, quicklisp/setup.lisp probably
hard-wires pathnames, so it probably won't work if launched from another
account.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

feature wish: init file

[Anton V. <avo...@ya...>]

Hello.

Is it possible to have some init file for CLISP which is executed always 
(in contrast to .clisprc which is executed only when CLISP is started with
REPL, but not when started from SLIME).

The motivation is to have quicklisp always available for lisp code executed
by CLISP.

Best regards,
- Anton

[ clisp-Bugs-3429859 ] Tab on empty line causes clisp to freak out

[SourceForge.net <no...@so...>]

Bugs item #3429859, was opened at 2011-10-28 22:26
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3429859&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Julien Durillon ()
Assigned to: Bruno Haible (haible)
Summary: Tab on empty line causes clisp to freak out

Initial Comment:
In the REPL, when I press the <tab> key without having started a identifier (you know, for completion), I get the following message : 

[1]> You are in the top-level Read-Eval-Print loop.
Help (abbreviated :h) = this list
Use the usual editing capabilities.
(quit) or (exit) leaves CLISP.
[1]> 

Then, Whatever I do, clisp gets busy (like really busy : takes 100% of my CPU), and I need to kill -9 it from outside.

FYI, I'm using clisp 2.48 on a Gentoo. (Compiled with libreadline support)




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3429859&group_id=1355

[ clisp-Bugs-3427590 ] random state not maintained correctly

[SourceForge.net <no...@so...>]

Bugs item #3427590, was opened at 2011-10-23 20:26
Message generated for change (Comment added) made by haible
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3427590&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Dodier (robert_dodier)
Assigned to: Bruno Haible (haible)
Summary: random state not maintained correctly

Initial Comment:
Clisp doesn't seem to maintain the random state correctly.

Here's an example from the CLHS. 
See: http://www.lispworks.com/documentation/HyperSpec/Body/v_rnd_st.htm#STrandom-stateST
I have adapted it by putting in the required argument for RANDOM.

 (setq snap-shot (make-random-state))
 ;; The series from any given point is random,
 ;; but if you backtrack to that point, you get the same series.
 (list (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100)))
       (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100))))

Expected output: first two lists are the same, second two lists are the same.
That is the behavior shown in the CLHS example.
(I don't see any reason to believe the output displayed in the CLHS is inconsistent with the CLHS's descriptions of *RANDOM-STATE* and MAKE-RANDOM-STATE.)

Actual output:

 ((61 35 13 7 80 62 20 2 22 86) (8 6 74 57 36 32 39 71 92 14) (65 29 40 51 38 72 16 75 74 9) (70 65 29 40 51 38 72 16 75 74))


I tried the same example w/ ECL and with SBCL, and in both cases they show the expected behavior.

$ uname -a
Linux robert-laptop 2.6.24.6 #1 SMP Sat Jan 1 00:37:06 MST 2011 i686 GNU/Linux

$ clisp --version
GNU CLISP 2.49 (2010-07-07) (built 3517447027) (memory 3517449770)
Software: GNU C 4.2.4 (Ubuntu 4.2.4-1ubuntu4) 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -I.  -lncurses -ldl   -L/home/robert/tmp/clisp-2.49/tools/i686-pc-linux-gnu/lib -lsigsegv -lc libgnu_cl.a 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
Features: 
(REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS
 LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /usr/local/lib/clisp-2.49/
User language: ENGLISH
Machine: I686 (I686) robert-laptop [127.0.0.1]



----------------------------------------------------------------------

>Comment By: Bruno Haible (haible)
Date: 2011-10-24 11:11

Message:
It's a regression: Your test case worked fine in version 2.34 and was
broken in version 2.35 and newer.

----------------------------------------------------------------------

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2011-10-23 21:13

Message:
Works for me... (a x86_64 linux).

C/USER[11]> (lisp-implementation-version)
"2.49 (2010-07-07) (built 3499302370) (memory 3499302538)"
C/USER[12]>  (setq snap-shot (make-random-state))
 
#S(RANDOM-STATE
#*0100001010101110101011111110101110000000111111000110100010101101)
C/USER[13]> ;; The series from any given point is random,
 ;; but if you backtrack to that point, you get the same series.
 (list (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100)))
       (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100))))
((74 0 50 49 43 98 99 84 72 99) (74 0 50 49 43 98 99 84 72 99) (93 64 22
39 34 85 20 0 9 60) (93 64 22 39 34 85 20 0 9 60))

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3427590&group_id=1355

[ clisp-Bugs-3427590 ] random state not maintained correctly

[SourceForge.net <no...@so...>]

Bugs item #3427590, was opened at 2011-10-23 20:26
Message generated for change (Comment added) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3427590&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Dodier (robert_dodier)
Assigned to: Bruno Haible (haible)
Summary: random state not maintained correctly

Initial Comment:
Clisp doesn't seem to maintain the random state correctly.

Here's an example from the CLHS. 
See: http://www.lispworks.com/documentation/HyperSpec/Body/v_rnd_st.htm#STrandom-stateST
I have adapted it by putting in the required argument for RANDOM.

 (setq snap-shot (make-random-state))
 ;; The series from any given point is random,
 ;; but if you backtrack to that point, you get the same series.
 (list (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100)))
       (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100))))

Expected output: first two lists are the same, second two lists are the same.
That is the behavior shown in the CLHS example.
(I don't see any reason to believe the output displayed in the CLHS is inconsistent with the CLHS's descriptions of *RANDOM-STATE* and MAKE-RANDOM-STATE.)

Actual output:

 ((61 35 13 7 80 62 20 2 22 86) (8 6 74 57 36 32 39 71 92 14) (65 29 40 51 38 72 16 75 74 9) (70 65 29 40 51 38 72 16 75 74))


I tried the same example w/ ECL and with SBCL, and in both cases they show the expected behavior.

$ uname -a
Linux robert-laptop 2.6.24.6 #1 SMP Sat Jan 1 00:37:06 MST 2011 i686 GNU/Linux

$ clisp --version
GNU CLISP 2.49 (2010-07-07) (built 3517447027) (memory 3517449770)
Software: GNU C 4.2.4 (Ubuntu 4.2.4-1ubuntu4) 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -I.  -lncurses -ldl   -L/home/robert/tmp/clisp-2.49/tools/i686-pc-linux-gnu/lib -lsigsegv -lc libgnu_cl.a 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
Features: 
(REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS
 LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /usr/local/lib/clisp-2.49/
User language: ENGLISH
Machine: I686 (I686) robert-laptop [127.0.0.1]



----------------------------------------------------------------------

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2011-10-23 21:13

Message:
Works for me... (a x86_64 linux).

C/USER[11]> (lisp-implementation-version)
"2.49 (2010-07-07) (built 3499302370) (memory 3499302538)"
C/USER[12]>  (setq snap-shot (make-random-state))
 
#S(RANDOM-STATE
#*0100001010101110101011111110101110000000111111000110100010101101)
C/USER[13]> ;; The series from any given point is random,
 ;; but if you backtrack to that point, you get the same series.
 (list (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100)))
       (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100))))
((74 0 50 49 43 98 99 84 72 99) (74 0 50 49 43 98 99 84 72 99) (93 64 22
39 34 85 20 0 9 60) (93 64 22 39 34 85 20 0 9 60))

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3427590&group_id=1355

[ clisp-Bugs-3427590 ] random state not maintained correctly

[SourceForge.net <no...@so...>]

Bugs item #3427590, was opened at 2011-10-23 12:26
Message generated for change (Tracker Item Submitted) made by robert_dodier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3427590&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Dodier (robert_dodier)
Assigned to: Bruno Haible (haible)
Summary: random state not maintained correctly

Initial Comment:
Clisp doesn't seem to maintain the random state correctly.

Here's an example from the CLHS. 
See: http://www.lispworks.com/documentation/HyperSpec/Body/v_rnd_st.htm#STrandom-stateST
I have adapted it by putting in the required argument for RANDOM.

 (setq snap-shot (make-random-state))
 ;; The series from any given point is random,
 ;; but if you backtrack to that point, you get the same series.
 (list (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100)))
       (loop for i from 1 to 10 collect (random 100))
       (let ((*random-state* snap-shot))
         (loop for i from 1 to 10 collect (random 100))))

Expected output: first two lists are the same, second two lists are the same.
That is the behavior shown in the CLHS example.
(I don't see any reason to believe the output displayed in the CLHS is inconsistent with the CLHS's descriptions of *RANDOM-STATE* and MAKE-RANDOM-STATE.)

Actual output:

 ((61 35 13 7 80 62 20 2 22 86) (8 6 74 57 36 32 39 71 92 14) (65 29 40 51 38 72 16 75 74 9) (70 65 29 40 51 38 72 16 75 74))


I tried the same example w/ ECL and with SBCL, and in both cases they show the expected behavior.

$ uname -a
Linux robert-laptop 2.6.24.6 #1 SMP Sat Jan 1 00:37:06 MST 2011 i686 GNU/Linux

$ clisp --version
GNU CLISP 2.49 (2010-07-07) (built 3517447027) (memory 3517449770)
Software: GNU C 4.2.4 (Ubuntu 4.2.4-1ubuntu4) 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -I.  -lncurses -ldl   -L/home/robert/tmp/clisp-2.49/tools/i686-pc-linux-gnu/lib -lsigsegv -lc libgnu_cl.a 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
Features: 
(REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS
 LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /usr/local/lib/clisp-2.49/
User language: ENGLISH
Machine: I686 (I686) robert-laptop [127.0.0.1]



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3427590&group_id=1355