clisp-devel — closed list for developers and testers

[ clisp-Feature Requests-3474507 ] RENAME-FILE :if-does-not-exist does not work

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

Feature Requests item #3474507, was opened at 2012-01-16 10:24
Message generated for change (Comment added) made by d3zd3z
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3474507&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: Extend ANSI CL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Brown (d3zd3z)
Assigned to: Bruno Haible (haible)
Summary: RENAME-FILE :if-does-not-exist does not work

Initial Comment:
GNU CLISP 2.49 (2010-07-07) (built on hepworth.siccegge.de [10.70.1.67])

Software: GNU C 4.6.1 
gcc -falign-functions=4 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.  /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 5.2
libffcall 1.11
Features: 
(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 WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) a64.davidb.org [76.88.79.245]
(debian testing build)

[1]> (with-open-file (stream "first.txt" :direction :output :if-does-not-exist :create))
NIL
[2]> (with-open-file (stream "second.txt" :direction :output :if-does-not-exist :create))
NIL
[3]> (rename-file "first.txt" "second.txt" :if-exists :overwrite)

*** - EVAL/APPLY: Too many arguments (4 instead of at most 2) given to RENAME-FILE
The following restarts are available:
ABORT          :R1      Abort main loop

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

>Comment By: David Brown (d3zd3z)
Date: 2012-01-16 11:52

Message:
As documented, this does work if custom:*ansi* is nil.  However, setting
this to nil causes many other things to be different from the ANSI
standard.

So, this can be considered a feature request to either have a setting that
allows rename-file to accept the :if-exists argument, or allow it when
*ansi* is non-nil.

Note that, as far as I can tell, all implementations either: 1. always
overwrite on renames, or 2. Always allow an :if-exists argument.

ANSI does not require rename-file to fail if the destination exists. 
Without it, there is no way to atomically replace a file.

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

Comment By: Sam Steingold (sds)
Date: 2012-01-16 11:37

Message:
ANSI CL standard specifies only 2 arguments to RENAME-FILE
http://www.lispworks.com/documentation/HyperSpec/Body/f_rn_fil.htm
I agree that this might be a useful extension to the standard.
http://www.cygwin.com/acronyms/#PTC

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

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

[ clisp-Feature Requests-3474507 ] RENAME-FILE :if-does-not-exist does not work

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

Feature Requests item #3474507, was opened at 2012-01-16 10:24
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3474507&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: Extend ANSI CL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Brown (d3zd3z)
Assigned to: Bruno Haible (haible)
Summary: RENAME-FILE :if-does-not-exist does not work

Initial Comment:
GNU CLISP 2.49 (2010-07-07) (built on hepworth.siccegge.de [10.70.1.67])

Software: GNU C 4.6.1 
gcc -falign-functions=4 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.  /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 5.2
libffcall 1.11
Features: 
(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 WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) a64.davidb.org [76.88.79.245]
(debian testing build)

[1]> (with-open-file (stream "first.txt" :direction :output :if-does-not-exist :create))
NIL
[2]> (with-open-file (stream "second.txt" :direction :output :if-does-not-exist :create))
NIL
[3]> (rename-file "first.txt" "second.txt" :if-exists :overwrite)

*** - EVAL/APPLY: Too many arguments (4 instead of at most 2) given to RENAME-FILE
The following restarts are available:
ABORT          :R1      Abort main loop

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

Comment By: Sam Steingold (sds)
Date: 2012-01-16 11:37

Message:
ANSI CL standard specifies only 2 arguments to RENAME-FILE
http://www.lispworks.com/documentation/HyperSpec/Body/f_rn_fil.htm
I agree that this might be a useful extension to the standard.
http://www.cygwin.com/acronyms/#PTC

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

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

[ clisp-Feature Requests-3474507 ] RENAME-FILE :if-does-not-exist does not work

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

Feature Requests item #3474507, was opened at 2012-01-16 10:24
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3474507&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: David Brown (d3zd3z)
Assigned to: Bruno Haible (haible)
Summary: RENAME-FILE :if-does-not-exist does not work

Initial Comment:
GNU CLISP 2.49 (2010-07-07) (built on hepworth.siccegge.de [10.70.1.67])

Software: GNU C 4.6.1 
gcc -falign-functions=4 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.  /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 5.2
libffcall 1.11
Features: 
(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 WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) a64.davidb.org [76.88.79.245]
(debian testing build)

[1]> (with-open-file (stream "first.txt" :direction :output :if-does-not-exist :create))
NIL
[2]> (with-open-file (stream "second.txt" :direction :output :if-does-not-exist :create))
NIL
[3]> (rename-file "first.txt" "second.txt" :if-exists :overwrite)

*** - EVAL/APPLY: Too many arguments (4 instead of at most 2) given to RENAME-FILE
The following restarts are available:
ABORT          :R1      Abort main loop

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

>Comment By: Sam Steingold (sds)
Date: 2012-01-16 11:37

Message:
ANSI CL standard specifies only 2 arguments to RENAME-FILE
http://www.lispworks.com/documentation/HyperSpec/Body/f_rn_fil.htm
I agree that this might be a useful extension to the standard.
http://www.cygwin.com/acronyms/#PTC

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

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

[ clisp-Bugs-3474507 ] RENAME-FILE :if-does-not-exist does not work

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

Bugs item #3474507, was opened at 2012-01-16 10:24
Message generated for change (Tracker Item Submitted) made by d3zd3z
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3474507&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: David Brown (d3zd3z)
Assigned to: Bruno Haible (haible)
Summary: RENAME-FILE :if-does-not-exist does not work

Initial Comment:
GNU CLISP 2.49 (2010-07-07) (built on hepworth.siccegge.de [10.70.1.67])

Software: GNU C 4.6.1 
gcc -falign-functions=4 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.  /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 5.2
libffcall 1.11
Features: 
(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 WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) a64.davidb.org [76.88.79.245]
(debian testing build)

[1]> (with-open-file (stream "first.txt" :direction :output :if-does-not-exist :create))
NIL
[2]> (with-open-file (stream "second.txt" :direction :output :if-does-not-exist :create))
NIL
[3]> (rename-file "first.txt" "second.txt" :if-exists :overwrite)

*** - EVAL/APPLY: Too many arguments (4 instead of at most 2) given to RENAME-FILE
The following restarts are available:
ABORT          :R1      Abort main loop

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

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

clisp-cvs Digest, Vol 66, Issue 1

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: implement spinlocks for ARM
      (cli...@li...)
   2. clisp: (xlock_lock_helper): fix possible deadlock when
      acquiring... (cli...@li...)
   3. clisp: (mt_main_actions): main thread should be the same as
      any ... (cli...@li...)


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

Message: 1
Date: Tue, 10 Jan 2012 12:04:40 +0000
From: cli...@li...
Subject: clisp: implement spinlocks for ARM
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/3162a6e761f9
changeset: 15552:3162a6e761f96491c61b5f4f441f05e930ee79d0
user:      Vladimir Tzankov <vtz...@gm...>
date:      2012-01-10 13:56:38 +0200
description:
implement spinlocks for ARM

diffstat:

 src/ChangeLog |   6 +++++-
 src/xthread.d |  17 ++++++++++++++++-
 2 files changed, 21 insertions(+), 2 deletions(-)



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

Message: 2
Date: Tue, 10 Jan 2012 12:04:42 +0000
From: cli...@li...
Subject: clisp: (xlock_lock_helper): fix possible deadlock when
	acquiring...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/5f1afc8aa658
changeset: 15553:5f1afc8aa6589dcb01df40f6532a78619324b218
user:      Vladimir Tzankov <vtz...@gm...>
date:      2012-01-10 14:01:16 +0200
description:
(xlock_lock_helper): fix possible deadlock when acquiring a lock released by xcondition_wait()

diffstat:

 src/ChangeLog |   7 +++++++
 src/zthread.d |  10 ++++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)



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

Message: 3
Date: Tue, 10 Jan 2012 12:04:44 +0000
From: cli...@li...
Subject: clisp: (mt_main_actions): main thread should be the same as
	any ...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e789e5f15ae3
changeset: 15554:e789e5f15ae331a9c7c565b8b7107875f6724381
user:      Vladimir Tzankov <vtz...@gm...>
date:      2012-01-10 14:03:56 +0200
description:
(mt_main_actions): main thread should be the same as any other - initialize time, reader and set normal exit flag

diffstat:

 src/ChangeLog |  5 +++++
 src/spvw.d    |  4 ++++
 2 files changed, 9 insertions(+), 0 deletions(-)



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

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev

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

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 66, Issue 1
****************************************

[ clisp-Bugs-3467762 ] delete-file cannot delete directory symlink

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

Bugs item #3467762, was opened at 2011-12-30 18:52
Message generated for change (Comment added) made by gabalz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3467762&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: delete-file cannot delete directory symlink

Initial Comment:

The delete-file function can remove file and dead symlinks but not (alive) directory symlinks, because it always resolves the provided pathname in the directory symlink case even if it should not (according to the CLISP documentation) :

    "(DELETE-FILE pathname) deletes the pathname PATHNAME, not its TRUENAME, ..."

Problem reconstruction:
~~~~~~~~~~~~~~~~~~

ls -lR
drwxr-xr-x 2 bege users 4096 Dec 30 19:40 dir
-rw-r--r-- 1 bege users    0 Dec 30 19:26 file
lrwxrwxrwx 1 bege users    4 Dec 30 19:26 link-dead -> dead/
lrwxrwxrwx 1 bege users    3 Dec 30 19:26 link-dir -> dir
lrwxrwxrwx 1 bege users    4 Dec 30 19:26 link-file -> file

./dir:
-rw-r--r-- 1 bege users 0 Dec 30 19:40 dir-file

Then
(delete-file "dir")
*** - DELETE-FILE: "/home/bege/TEST/dir" names a directory, not a file
so the provided pathname is resolved.

However,
(delete-file "link-file")
deletes the link-file link (properly), so in this case the provided pathname is not resolved.

(delete-file "link-dead") works properly too without resolving the dead symlink.

Desired behaviour:
~~~~~~~~~~~~~~
delete-file should not resolve the pathname for a directory symlink and should delete the symlink without error.

Version
~~~~~~
clisp --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]


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

>Comment By: Gabor Balazs (gabalz)
Date: 2011-12-30 18:55

Message:
Sorry, there is a mistake in the description, but the error exist. So
correctly,

(delete-file "link-dir")
*** - DELETE-FILE: "/home/bege/TEST/dir" names a directory, not a file

/ instead of (delete-file "dir") /


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

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

[ clisp-Bugs-3467762 ] delete-file cannot delete directory symlink

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

Bugs item #3467762, was opened at 2011-12-30 18:52
Message generated for change (Tracker Item Submitted) made by gabalz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3467762&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: delete-file cannot delete directory symlink

Initial Comment:

The delete-file function can remove file and dead symlinks but not (alive) directory symlinks, because it always resolves the provided pathname in the directory symlink case even if it should not (according to the CLISP documentation) :

    "(DELETE-FILE pathname) deletes the pathname PATHNAME, not its TRUENAME, ..."

Problem reconstruction:
~~~~~~~~~~~~~~~~~~

ls -lR
drwxr-xr-x 2 bege users 4096 Dec 30 19:40 dir
-rw-r--r-- 1 bege users    0 Dec 30 19:26 file
lrwxrwxrwx 1 bege users    4 Dec 30 19:26 link-dead -> dead/
lrwxrwxrwx 1 bege users    3 Dec 30 19:26 link-dir -> dir
lrwxrwxrwx 1 bege users    4 Dec 30 19:26 link-file -> file

./dir:
-rw-r--r-- 1 bege users 0 Dec 30 19:40 dir-file

Then
(delete-file "dir")
*** - DELETE-FILE: "/home/bege/TEST/dir" names a directory, not a file
so the provided pathname is resolved.

However,
(delete-file "link-file")
deletes the link-file link (properly), so in this case the provided pathname is not resolved.

(delete-file "link-dead") works properly too without resolving the dead symlink.

Desired behaviour:
~~~~~~~~~~~~~~
delete-file should not resolve the pathname for a directory symlink and should delete the symlink without error.

Version
~~~~~~
clisp --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]


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

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

[ clisp-Bugs-3467215 ] clisp-2.49 fails tests.

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

Bugs item #3467215, was opened at 2011-12-29 18:10
Message generated for change (Comment added) made by rbruccoleri
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3467215&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: segfault
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Bruccoleri (rbruccoleri)
Assigned to: Bruno Haible (haible)
Summary: clisp-2.49 fails tests.

Initial Comment:
I am attempting to build clisp 2.49 on a Redhat Linux 64 bit system, and I'm getting repeated errors of the form:


*** - handle_fault error2 ! address = 0x33975d938 not in [0x335380000,0x3356eb170) !
SIGSEGV cannot be cured. Fault address = 0x33975d938.

when running tests. Clisp was built using libsigsegv 2.10 and the ffcall functions that came with the Clisp 2.49 distribution. I've tried Clisp 2.40 and libsigsegv 2.4 with the same result, althoughin different tests.

Here's the answers to the questions you request for filing a bug report:

   1. What is your platform (uname -a on a UNIX system)? Compiler version? GNU libc version (on GNU/Linux)?
Linux liberty.congen.com 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8 21:37:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
glibc-2.5-65.el5_7.1
   2. Where did you get the sources or binaries? When? (Absolute dates, e.g., “2006-01-17”, are preferred over the relative ones, e.g., “2 days ago”).
 I downloaded the distribution from ftp.gnu.org on Dec. 3, 2011.
   3. How did you build CLISP? (What command, options &c.)
Here's my script:

#!/bin/sh -x

ulimit -s 65536
make distclean

(cd build; make distclean)

export prefix=${BUILD_PREFIX:-/usr/local}
export LDFLAGS="-Wl,-rpath,$prefix/lib"

./configure --prefix=$prefix \
            --with-debug \
            --with-libsigsegv-prefix=${prefix} \
            --with-module=readline \
            --with-module=i18n \
            --with-module=syscalls \
            --with-module=regexp \
            build 
cd build
./makemake > Makefile
make config.lisp
make
make check

   4. What is the output of clisp --version?

[root@liberty clisp-2.49]# build/lisp.run --version

WARNING: No installation directory specified.
Please try: build/lisp.run -B /usr/local/lib/clisp
GNU CLISP 2.49 (2010-07-07) (built 2011-12-29 15:01:16)
Software: GNU C 4.1.2 20080704 (Red Hat 4.1.2-51) gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -I. -Wl,-rpath,/usr/local/lib  -lreadline -lncurses -ldl   -L/usr/local/lib -lsigsegv -lc -R/usr/local/lib libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.10
libreadline 5.1
Features: (CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp)
Installation directory: 
*** - SYSTEM::LIB-DIRECTORY: installation directory is not known, use the -B command line option to specify it or set *LIB-DIRECTORY*


   5. Please supply the full output (copy and paste) of all the error messages, as well as detailed instructions on how to reproduce them.
Please contact me for a log file of the build process.

I was able run gdb on the core dump and generate this stack trace:


[root@liberty tests]# gdb ../lisp.run core.12462 
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /vm/local/src/clisp-2.49/build/lisp.run...done.
[New Thread 12462]
Reading symbols from /usr/lib64/libreadline.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libreadline.so.5
Reading symbols from /usr/lib64/libncurses.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libncurses.so.5
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/local/lib/libsigsegv.so.2...done.
Loaded symbols for /usr/local/lib/libsigsegv.so.2
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib64/gconv/ISO8859-1.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/gconv/ISO8859-1.so
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_files.so.2
Reading symbols from /usr/lib64/gconv/ISO-2022-KR.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/gconv/ISO-2022-KR.so
Reading symbols from /usr/lib64/gconv/libKSC.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/gconv/libKSC.so
Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_dns.so.2
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libresolv.so.2

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff26179000
Core was generated by `../lisp.run -E UTF-8 -norc -B ../ -N ../locale -M ../lispinit.mem -m 30MW -L en'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000046c275 in write_char (stream_=0x2b7b3faf8bb8, ch=0x200000000000a) at ../src/stream.d:895
895         wr_ch(stream)(stream_,ch);
(gdb) where
#0  0x000000000046c275 in write_char (stream_=0x2b7b3faf8bb8, ch=0x200000000000a) at ../src/stream.d:895
#1  0x0000000000477411 in fresh_line_low (stream_=0x2b7b3faf8bb8) at ../src/stream.d:16901
#2  0x000000000047ca59 in fresh_line (stream_=0x2b7b3faf8bb8) at ../src/stream.d:16950
#3  0x000000000041b405 in quit_on_signal (sig=6) at ../src/spvw_sigterm.d:59
#4  <signal handler called>
#5  0x0000003d21e30265 in raise () from /lib64/libc.so.6
#6  0x0000003d21e31d10 in abort () from /lib64/libc.so.6
#7  0x000000000042b4d6 in gc_morris2 () at ../src/spvw_garcol.d:428
#8  gar_col_normal () at ../src/spvw_garcol.d:2327
#9  0x000000000042bb39 in do_gar_col_simple () at ../src/spvw_garcol.d:3028
#10 0x00000000004e6f2c in with_gc_statistics (fun=0x42baec <do_gar_col_simple>) at ../src/predtype.d:3162
#11 0x000000000041d0fd in gar_col_simple () at ../src/spvw_garcol.d:3036
#12 0x000000000041d2d2 in make_space_gc_true (need=128248, heapptr=0x81c448) at ../src/spvw_allocate.d:282
#13 0x000000000041df27 in allocate_vector (len=16029) at ../src/spvw_typealloc.d:107
#14 0x00000000004201a4 in get_circularities (obj=0xd0003412642b8, pr_array=true, pr_closure=false)
    at ../src/spvw_circ.d:994
#15 0x000000000048e6a0 in pr_enter_2 (stream_=0x2b7b3fad9608, obj=0x30ae, pr_xxx=0x486030 <prin_object>)
    at ../src/io.d:6605
#16 0x000000000048ebbb in pr_enter (stream_=0x101010101010101, obj=0x246, pr_xxx=0x8) at ../src/io.d:6660
#17 0x000000000048ed9a in prin1 (stream_=0x30ae, obj=0x30ae) at ../src/io.d:9979
#18 0x000000000048f14f in princ_up () at ../src/io.d:10371
#19 0x000000000048f1ad in C_princ_to_string () at ../src/io.d:10421
#20 0x0000000000437da3 in interpret_bytecode_ (closure=0x9000341264430, codeptr=0x340f728d8, 
    byteptr=<value optimized out>) at ../src/eval.d:6808
#21 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=1) at ../src/eval.d:5630
#22 0x000000000043e42a in funcall (fun=0x9000341264430, args_on_stack=1) at ../src/eval.d:4862
#23 0x00000000004384b9 in interpret_bytecode_ (closure=0x9000340f73108, codeptr=0x340f72720, 
    byteptr=<value optimized out>) at ../src/eval.d:6854
#24 0x0000000000440c84 in invoke_handlers (cond=<value optimized out>) at ../src/eval.d:772
#25 0x00000000004dc713 in C_clcs_signal (argcount=<value optimized out>, 
    rest_args_pointer=<value optimized out>) at ../src/error.d:821
#26 0x000000000042d906 in funcall_subr (fun=0x10000007f7658, args_on_stack=0) at ../src/eval.d:5222
#27 0x000000000043e414 in funcall (fun=0x10000007f7658, args_on_stack=1) at ../src/eval.d:4860
#28 0x00000000004dcd11 in signal_and_debug (condition=<value optimized out>) at ../src/error.d:206
#29 0x00000000004ddf28 in end_error (stackptr=0x2b7b3fad9568, start_driver_p=true) at ../src/error.d:346
#30 0x00000000004df789 in OS_error () at ../src/errunix.d:688
#31 0x000000000047e2d3 in C_socket_server () at ../src/stream.d:14056
#32 0x00000000004336ab in eval_subr (fun=0x10000007ff880) at ../src/eval.d:3592
#33 0x0000000000430865 in eval1 (form=<value optimized out>) at ../src/eval.d:3084
#34 0x00000000004325c0 in eval (form=0x40000cd00f8c30) at ../src/eval.d:2966
#35 0x0000000000433873 in eval_5env (form=0x30ae, var_env=0x30ae, fun_env=0x6, block_env=0xffffffffffffffff, 
    go_env=0x80, decl_env=0x101010101010101) at ../src/eval.d:1087
#36 0x00000000004338a3 in eval_noenv (form=0x30ae) at ../src/eval.d:1099
#37 0x0000000000442da2 in C_eval () at ../src/control.d:2187
#38 0x0000000000437cf6 in interpret_bytecode_ (closure=0x9000340f71208, codeptr=0x340f70fb0, 
    byteptr=<value optimized out>) at ../src/eval.d:6805
#39 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=1) at ../src/eval.d:5630
#40 0x000000000043e46a in funcall (fun=<value optimized out>, args_on_stack=1) at ../src/eval.d:4869
#41 0x0000000000437aa3 in interpret_bytecode_ (closure=0x9000341263de8, codeptr=0x340f729e8, 
    byteptr=<value optimized out>) at ../src/eval.d:6793
#42 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=0) at ../src/eval.d:5630
---Type <return> to continue, or q <return> to quit---
#43 0x000000000043e42a in funcall (fun=0x9000341263de8, args_on_stack=0) at ../src/eval.d:4862
#44 0x00000000004384b9 in interpret_bytecode_ (closure=0x9000340f73108, codeptr=0x340f72720, 
    byteptr=<value optimized out>) at ../src/eval.d:6854
#45 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=2) at ../src/eval.d:5630
#46 0x000000000043e42a in funcall (fun=0x9000340f73108, args_on_stack=2) at ../src/eval.d:4862
#47 0x00000000004384b9 in interpret_bytecode_ (closure=0x9000340f75c98, codeptr=0x340f75498, 
    byteptr=<value optimized out>) at ../src/eval.d:6854
#48 0x0000000000435799 in apply_closure (closure=0x9000340f75c98, args_on_stack=0, args=0x4000000801c80)
    at ../src/eval.d:4795
#49 0x0000000000435a1a in apply (fun=0x9000340f75c98, args_on_stack=0, other_args=0x40000cd0286fe0)
    at ../src/eval.d:4016
#50 0x000000000043867c in interpret_bytecode_ (closure=0x9000340f770c0, codeptr=0x340f76f58, 
    byteptr=<value optimized out>) at ../src/eval.d:6875
#51 0x00000000004319be in eval_closure (form=<value optimized out>) at ../src/eval.d:3862
#52 eval1 (form=<value optimized out>) at ../src/eval.d:3091
#53 0x00000000004325c0 in eval (form=0x40000cd027b3f0) at ../src/eval.d:2966
#54 0x0000000000444272 in C_unwind_protect () at ../src/control.d:1943
#55 0x00000000004321ec in eval_fsubr (form=0x40000cd027b2f0) at ../src/eval.d:3263
#56 eval1 (form=0x40000cd027b2f0) at ../src/eval.d:3101
#57 0x00000000004325c0 in eval (form=0x40000cd027b2f0) at ../src/eval.d:2966
#58 0x00000000004456cc in C_multiple_value_bind () at ../src/control.d:1854
#59 0x00000000004321ec in eval_fsubr (form=0x40000cd027b2b0) at ../src/eval.d:3263
#60 eval1 (form=0x40000cd027b2b0) at ../src/eval.d:3101
#61 0x00000000004325c0 in eval (form=0x40000cd027b2b0) at ../src/eval.d:2966
#62 0x00000000004307c0 in eval1 (form=<value optimized out>) at ../src/eval.d:3059
#63 0x00000000004325c0 in eval (form=0x40000cd027b400) at ../src/eval.d:2966
#64 0x00000000004dc147 in C_read_eval_print () at ../src/debug.d:409
#65 0x000000000042d948 in funcall_subr (fun=0x10000007f6d60, args_on_stack=2) at ../src/eval.d:5227
#66 0x000000000043e454 in funcall (fun=<value optimized out>, args_on_stack=2) at ../src/eval.d:4867
#67 0x0000000000437bc3 in interpret_bytecode_ (closure=0x9000340f99950, codeptr=0x340f42458, 
    byteptr=<value optimized out>) at ../src/eval.d:6799
#68 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=0) at ../src/eval.d:5630
#69 0x000000000043e42a in funcall (fun=0x9000340f99950, args_on_stack=0) at ../src/eval.d:4862
#70 0x00000000004441ba in C_driver () at ../src/control.d:1999
#71 0x0000000000437cf6 in interpret_bytecode_ (closure=0x9000340f42988, codeptr=0x340f423d8, 
    byteptr=<value optimized out>) at ../src/eval.d:6805
#72 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=1) at ../src/eval.d:5630
#73 0x000000000043e42a in funcall (fun=0x9000340f42988, args_on_stack=1) at ../src/eval.d:4862
#74 0x0000000000424a21 in main_actions (p=0x81c740) at ../src/spvw.d:3615
#75 0x0000000000428ab4 in main (argc=18, argv=0x7fff26049c78) at ../src/spvw.d:3885
(gdb) 

I can provide any additional files on request.
[

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

>Comment By: Robert Bruccoleri (rbruccoleri)
Date: 2011-12-29 18:21

Message:
Additional information: when I compile this version on my system in 32 bit
mode, the compilation and testing are all successful.


I put a debugging statement in the garbage collecting code in spvw_garcol.d
around line 430:

  if (p2!=p1limit) {
    fprintf(stderr, "Warning 1: p1 = %u start_p1 = %u  p2 = %u start_p2 =
%u  p1limit = %u\n",
            p1, start_p1, p2, start_p2, p1limit);
/*    abort(); */
  }

Here's an output (start_p1 and start_p2 are initialized at the top of the
function with the initial values for p1 and p2.)

Warning 1: p1 = 3507453952 start_p1 = 3506858816  p2 = 3507453968 start_p2
= 3507046928  p1limit = 3507453952

I modified all the assertion tests like this in this source file, and
attempted recompilation. I'm getting errors in other places.

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

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

[ clisp-Bugs-3467215 ] clisp-2.49 fails tests.

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

Bugs item #3467215, was opened at 2011-12-29 18:10
Message generated for change (Tracker Item Submitted) made by rbruccoleri
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3467215&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: segfault
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Bruccoleri (rbruccoleri)
Assigned to: Bruno Haible (haible)
Summary: clisp-2.49 fails tests.

Initial Comment:
I am attempting to build clisp 2.49 on a Redhat Linux 64 bit system, and I'm getting repeated errors of the form:


*** - handle_fault error2 ! address = 0x33975d938 not in [0x335380000,0x3356eb170) !
SIGSEGV cannot be cured. Fault address = 0x33975d938.

when running tests. Clisp was built using libsigsegv 2.10 and the ffcall functions that came with the Clisp 2.49 distribution. I've tried Clisp 2.40 and libsigsegv 2.4 with the same result, althoughin different tests.

Here's the answers to the questions you request for filing a bug report:

   1. What is your platform (uname -a on a UNIX system)? Compiler version? GNU libc version (on GNU/Linux)?
Linux liberty.congen.com 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8 21:37:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
glibc-2.5-65.el5_7.1
   2. Where did you get the sources or binaries? When? (Absolute dates, e.g., “2006-01-17”, are preferred over the relative ones, e.g., “2 days ago”).
 I downloaded the distribution from ftp.gnu.org on Dec. 3, 2011.
   3. How did you build CLISP? (What command, options &c.)
Here's my script:

#!/bin/sh -x

ulimit -s 65536
make distclean

(cd build; make distclean)

export prefix=${BUILD_PREFIX:-/usr/local}
export LDFLAGS="-Wl,-rpath,$prefix/lib"

./configure --prefix=$prefix \
            --with-debug \
            --with-libsigsegv-prefix=${prefix} \
            --with-module=readline \
            --with-module=i18n \
            --with-module=syscalls \
            --with-module=regexp \
            build 
cd build
./makemake > Makefile
make config.lisp
make
make check

   4. What is the output of clisp --version?

[root@liberty clisp-2.49]# build/lisp.run --version

WARNING: No installation directory specified.
Please try: build/lisp.run -B /usr/local/lib/clisp
GNU CLISP 2.49 (2010-07-07) (built 2011-12-29 15:01:16)
Software: GNU C 4.1.2 20080704 (Red Hat 4.1.2-51) gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_MODULES -I. -Wl,-rpath,/usr/local/lib  -lreadline -lncurses -ldl   -L/usr/local/lib -lsigsegv -lc -R/usr/local/lib libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.10
libreadline 5.1
Features: (CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp)
Installation directory: 
*** - SYSTEM::LIB-DIRECTORY: installation directory is not known, use the -B command line option to specify it or set *LIB-DIRECTORY*


   5. Please supply the full output (copy and paste) of all the error messages, as well as detailed instructions on how to reproduce them.
Please contact me for a log file of the build process.

I was able run gdb on the core dump and generate this stack trace:


[root@liberty tests]# gdb ../lisp.run core.12462 
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /vm/local/src/clisp-2.49/build/lisp.run...done.
[New Thread 12462]
Reading symbols from /usr/lib64/libreadline.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libreadline.so.5
Reading symbols from /usr/lib64/libncurses.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libncurses.so.5
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/local/lib/libsigsegv.so.2...done.
Loaded symbols for /usr/local/lib/libsigsegv.so.2
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib64/gconv/ISO8859-1.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/gconv/ISO8859-1.so
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_files.so.2
Reading symbols from /usr/lib64/gconv/ISO-2022-KR.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/gconv/ISO-2022-KR.so
Reading symbols from /usr/lib64/gconv/libKSC.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/gconv/libKSC.so
Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_dns.so.2
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libresolv.so.2

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff26179000
Core was generated by `../lisp.run -E UTF-8 -norc -B ../ -N ../locale -M ../lispinit.mem -m 30MW -L en'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000046c275 in write_char (stream_=0x2b7b3faf8bb8, ch=0x200000000000a) at ../src/stream.d:895
895         wr_ch(stream)(stream_,ch);
(gdb) where
#0  0x000000000046c275 in write_char (stream_=0x2b7b3faf8bb8, ch=0x200000000000a) at ../src/stream.d:895
#1  0x0000000000477411 in fresh_line_low (stream_=0x2b7b3faf8bb8) at ../src/stream.d:16901
#2  0x000000000047ca59 in fresh_line (stream_=0x2b7b3faf8bb8) at ../src/stream.d:16950
#3  0x000000000041b405 in quit_on_signal (sig=6) at ../src/spvw_sigterm.d:59
#4  <signal handler called>
#5  0x0000003d21e30265 in raise () from /lib64/libc.so.6
#6  0x0000003d21e31d10 in abort () from /lib64/libc.so.6
#7  0x000000000042b4d6 in gc_morris2 () at ../src/spvw_garcol.d:428
#8  gar_col_normal () at ../src/spvw_garcol.d:2327
#9  0x000000000042bb39 in do_gar_col_simple () at ../src/spvw_garcol.d:3028
#10 0x00000000004e6f2c in with_gc_statistics (fun=0x42baec <do_gar_col_simple>) at ../src/predtype.d:3162
#11 0x000000000041d0fd in gar_col_simple () at ../src/spvw_garcol.d:3036
#12 0x000000000041d2d2 in make_space_gc_true (need=128248, heapptr=0x81c448) at ../src/spvw_allocate.d:282
#13 0x000000000041df27 in allocate_vector (len=16029) at ../src/spvw_typealloc.d:107
#14 0x00000000004201a4 in get_circularities (obj=0xd0003412642b8, pr_array=true, pr_closure=false)
    at ../src/spvw_circ.d:994
#15 0x000000000048e6a0 in pr_enter_2 (stream_=0x2b7b3fad9608, obj=0x30ae, pr_xxx=0x486030 <prin_object>)
    at ../src/io.d:6605
#16 0x000000000048ebbb in pr_enter (stream_=0x101010101010101, obj=0x246, pr_xxx=0x8) at ../src/io.d:6660
#17 0x000000000048ed9a in prin1 (stream_=0x30ae, obj=0x30ae) at ../src/io.d:9979
#18 0x000000000048f14f in princ_up () at ../src/io.d:10371
#19 0x000000000048f1ad in C_princ_to_string () at ../src/io.d:10421
#20 0x0000000000437da3 in interpret_bytecode_ (closure=0x9000341264430, codeptr=0x340f728d8, 
    byteptr=<value optimized out>) at ../src/eval.d:6808
#21 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=1) at ../src/eval.d:5630
#22 0x000000000043e42a in funcall (fun=0x9000341264430, args_on_stack=1) at ../src/eval.d:4862
#23 0x00000000004384b9 in interpret_bytecode_ (closure=0x9000340f73108, codeptr=0x340f72720, 
    byteptr=<value optimized out>) at ../src/eval.d:6854
#24 0x0000000000440c84 in invoke_handlers (cond=<value optimized out>) at ../src/eval.d:772
#25 0x00000000004dc713 in C_clcs_signal (argcount=<value optimized out>, 
    rest_args_pointer=<value optimized out>) at ../src/error.d:821
#26 0x000000000042d906 in funcall_subr (fun=0x10000007f7658, args_on_stack=0) at ../src/eval.d:5222
#27 0x000000000043e414 in funcall (fun=0x10000007f7658, args_on_stack=1) at ../src/eval.d:4860
#28 0x00000000004dcd11 in signal_and_debug (condition=<value optimized out>) at ../src/error.d:206
#29 0x00000000004ddf28 in end_error (stackptr=0x2b7b3fad9568, start_driver_p=true) at ../src/error.d:346
#30 0x00000000004df789 in OS_error () at ../src/errunix.d:688
#31 0x000000000047e2d3 in C_socket_server () at ../src/stream.d:14056
#32 0x00000000004336ab in eval_subr (fun=0x10000007ff880) at ../src/eval.d:3592
#33 0x0000000000430865 in eval1 (form=<value optimized out>) at ../src/eval.d:3084
#34 0x00000000004325c0 in eval (form=0x40000cd00f8c30) at ../src/eval.d:2966
#35 0x0000000000433873 in eval_5env (form=0x30ae, var_env=0x30ae, fun_env=0x6, block_env=0xffffffffffffffff, 
    go_env=0x80, decl_env=0x101010101010101) at ../src/eval.d:1087
#36 0x00000000004338a3 in eval_noenv (form=0x30ae) at ../src/eval.d:1099
#37 0x0000000000442da2 in C_eval () at ../src/control.d:2187
#38 0x0000000000437cf6 in interpret_bytecode_ (closure=0x9000340f71208, codeptr=0x340f70fb0, 
    byteptr=<value optimized out>) at ../src/eval.d:6805
#39 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=1) at ../src/eval.d:5630
#40 0x000000000043e46a in funcall (fun=<value optimized out>, args_on_stack=1) at ../src/eval.d:4869
#41 0x0000000000437aa3 in interpret_bytecode_ (closure=0x9000341263de8, codeptr=0x340f729e8, 
    byteptr=<value optimized out>) at ../src/eval.d:6793
#42 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=0) at ../src/eval.d:5630
---Type <return> to continue, or q <return> to quit---
#43 0x000000000043e42a in funcall (fun=0x9000341263de8, args_on_stack=0) at ../src/eval.d:4862
#44 0x00000000004384b9 in interpret_bytecode_ (closure=0x9000340f73108, codeptr=0x340f72720, 
    byteptr=<value optimized out>) at ../src/eval.d:6854
#45 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=2) at ../src/eval.d:5630
#46 0x000000000043e42a in funcall (fun=0x9000340f73108, args_on_stack=2) at ../src/eval.d:4862
#47 0x00000000004384b9 in interpret_bytecode_ (closure=0x9000340f75c98, codeptr=0x340f75498, 
    byteptr=<value optimized out>) at ../src/eval.d:6854
#48 0x0000000000435799 in apply_closure (closure=0x9000340f75c98, args_on_stack=0, args=0x4000000801c80)
    at ../src/eval.d:4795
#49 0x0000000000435a1a in apply (fun=0x9000340f75c98, args_on_stack=0, other_args=0x40000cd0286fe0)
    at ../src/eval.d:4016
#50 0x000000000043867c in interpret_bytecode_ (closure=0x9000340f770c0, codeptr=0x340f76f58, 
    byteptr=<value optimized out>) at ../src/eval.d:6875
#51 0x00000000004319be in eval_closure (form=<value optimized out>) at ../src/eval.d:3862
#52 eval1 (form=<value optimized out>) at ../src/eval.d:3091
#53 0x00000000004325c0 in eval (form=0x40000cd027b3f0) at ../src/eval.d:2966
#54 0x0000000000444272 in C_unwind_protect () at ../src/control.d:1943
#55 0x00000000004321ec in eval_fsubr (form=0x40000cd027b2f0) at ../src/eval.d:3263
#56 eval1 (form=0x40000cd027b2f0) at ../src/eval.d:3101
#57 0x00000000004325c0 in eval (form=0x40000cd027b2f0) at ../src/eval.d:2966
#58 0x00000000004456cc in C_multiple_value_bind () at ../src/control.d:1854
#59 0x00000000004321ec in eval_fsubr (form=0x40000cd027b2b0) at ../src/eval.d:3263
#60 eval1 (form=0x40000cd027b2b0) at ../src/eval.d:3101
#61 0x00000000004325c0 in eval (form=0x40000cd027b2b0) at ../src/eval.d:2966
#62 0x00000000004307c0 in eval1 (form=<value optimized out>) at ../src/eval.d:3059
#63 0x00000000004325c0 in eval (form=0x40000cd027b400) at ../src/eval.d:2966
#64 0x00000000004dc147 in C_read_eval_print () at ../src/debug.d:409
#65 0x000000000042d948 in funcall_subr (fun=0x10000007f6d60, args_on_stack=2) at ../src/eval.d:5227
#66 0x000000000043e454 in funcall (fun=<value optimized out>, args_on_stack=2) at ../src/eval.d:4867
#67 0x0000000000437bc3 in interpret_bytecode_ (closure=0x9000340f99950, codeptr=0x340f42458, 
    byteptr=<value optimized out>) at ../src/eval.d:6799
#68 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=0) at ../src/eval.d:5630
#69 0x000000000043e42a in funcall (fun=0x9000340f99950, args_on_stack=0) at ../src/eval.d:4862
#70 0x00000000004441ba in C_driver () at ../src/control.d:1999
#71 0x0000000000437cf6 in interpret_bytecode_ (closure=0x9000340f42988, codeptr=0x340f423d8, 
    byteptr=<value optimized out>) at ../src/eval.d:6805
#72 0x000000000043e346 in funcall_closure (closure=0x30ae, args_on_stack=1) at ../src/eval.d:5630
#73 0x000000000043e42a in funcall (fun=0x9000340f42988, args_on_stack=1) at ../src/eval.d:4862
#74 0x0000000000424a21 in main_actions (p=0x81c740) at ../src/spvw.d:3615
#75 0x0000000000428ab4 in main (argc=18, argv=0x7fff26049c78) at ../src/spvw.d:3885
(gdb) 

I can provide any additional files on request.
[

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

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

Re: Why a menorah?

[<pc...@ma...>]

> Interesting.  Thanks for your response.
>
> On Thu, Dec 29, 2011 at 2:56 PM, Stas Boukarev <sta...@gm...> wrote:
>
>> "Yves S. Garret" <you...@gm...> writes:
>>
>> > Why is it that every time I startup common lisp, I see a menorah?  Is
>> this
>> > something related to Judaism?
>> http://clisp.org/impnotes/faq.html#faq-menorah-why

  I always though it was an ascii art representing some kind of trident,
 with some extra teeth/arrows.

>> --
>> With best regards, Stas.
>>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free!
> http://p.sf.net/sfu/Citrix-VDIinabox_______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel

Paulo

Re: Why a menorah?

[Yves S. G. <you...@gm...>]

Interesting.  Thanks for your response.

On Thu, Dec 29, 2011 at 2:56 PM, Stas Boukarev <sta...@gm...> wrote:

> "Yves S. Garret" <you...@gm...> writes:
>
> > Why is it that every time I startup common lisp, I see a menorah?  Is
> this
> > something related to Judaism?
> http://clisp.org/impnotes/faq.html#faq-menorah-why
>
> --
> With best regards, Stas.
>

Re: Why a menorah?

[Stas B. <sta...@gm...>]

"Yves S. Garret" <you...@gm...> writes:

> Why is it that every time I startup common lisp, I see a menorah?  Is this
> something related to Judaism?
http://clisp.org/impnotes/faq.html#faq-menorah-why

-- 
With best regards, Stas.

Why a menorah?

[Yves S. G. <you...@gm...>]

Why is it that every time I startup common lisp, I see a menorah?  Is this
something related to Judaism?

Re: clisp+mingw

[Yaroslav K. <kav...@gm...>]

Sam Steingold wrote:
> clisp/mingw is broken ATM because, briefly, clisp sometimes uses native
> win32 sockets and sometimes it uses gnulib sockets.  It would take
> someone who understands both clisp and gnulib (both current and future!)
> to fix the problem.  One can start with my gnulib-bug complaints.

Need gnulib sockets only or mix of gnulib and native sockets?

-- 
WBR, Yaroslav Kavenchuk

Re: clisp+mingw

[Sam S. <sd...@gn...>]

> * Yaroslav Kavenchuk <xni...@tz...> [2011-12-28 10:56:40 +0300]:
>
> Clisp from mercurial head, mingw/msys "from scratch" (I reinstall all).

clisp/mingw is broken ATM because, briefly, clisp sometimes uses native
win32 sockets and sometimes it uses gnulib sockets.  It would take
someone who understands both clisp and gnulib (both current and future!)
to fix the problem.  One can start with my gnulib-bug complaints.
I no longer have any access to any windows box, so, even if I had
time/skill/desire to sort this mess out, I cannot do anything about it.

http://www.cygwin.com/acronyms/#PTC -- by Bruno, not by myself.

Sorry.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://iris.org.il http://dhimmi.com http://truepeace.org
http://jihadwatch.org http://palestinefacts.org http://camera.org
Beliefs divide, doubts unite.

clisp+mingw

[Yaroslav K. <kav...@gm...>]

Hi, All!

Clisp from mercurial head, mingw/msys "from scratch" (I reinstall all).

./configure --with-debug \
             --with-readline \
             --with-module=dirkey \
             --with-module=pcre \
             --with-module=rawsock \
             --with-module=bindings/win32 \
             --with-module=zlib \
             --with-module=libsvm \
             --disable-maintainer-mode \
             --without-dynamic-modules \
             --cbc build-full-debug &> ../build-full-debug.log

from tail of build-full-debug.log:

gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit 
-Wreturn-type -Wmissing-declarations -Wno-sign-compare 
-Wno-format-nonliteral -falign-functions=4 -D_WIN32 -g -O0 
-DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 
-DENABLE_UNICODE -DDYNAMIC_FFI -L/usr/local/lib modules.o libsvm.o -lm 
/usr/local/lib/libsvm.dll.a -L/usr/local/lib zlib.o -lz -lm rawsock.o 
cpcre.o /usr/local/lib/libpcre.dll.a -L/usr/local/lib dirkey.o 
readline.o -lreadline -ltermcap regexi.o calls.o bogomips.o -luser32 
-lole32 -loleaut32 -luuid -lversion gettext.o lisp.a libgnu.a -lintl 
/usr/local/lib/libreadline.dll.a -L/usr/local/lib -ltermcap 
/usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -luser32 -lole32 
-loleaut32 -luuid -liconv -L/usr/local/lib -lsigsegv -lws2_32 -o lisp.exe
rawsock.o: In function `C_subr_rawsock_socketpair':
g:/gnu/home/src/clisp/clisp/modules/rawsock/rawsock.c:691: undefined 
reference to `close_used_without_including_unistd_h'
rawsock.o: In function `C_subr_rawsock_sock_close':
g:/gnu/home/src/clisp/clisp/modules/rawsock/rawsock.c:1130: undefined 
reference to `close_used_without_including_unistd_h'
collect2: ld returned 1 exit status

unistd.h is present in gllib/ and in mingw as <sys/unistd.h>

$ grep warning: ../build-full-debug.log
../../src/gllib/regex_internal.c:1394:3: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/regexec.c:380:3: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/regexec.c:380:3: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/regexec.c:380:3: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/regexec.c:433:3: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/regexec.c:437:3: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/select.c:231:1: warning: no previous declaration for 
'rpl_select' [-Wmissing-declarations]
../../src/gllib/setenv.c:113:1: warning: no previous declaration for 
'__add_to_environ' [-Wmissing-declarations]
../../src/gllib/setenv.c:306:1: warning: no previous declaration for 
'clearenv' [-Wmissing-declarations]
../../src/gllib/strptime.c:416:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:465:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:492:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:583:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:617:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:630:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:635:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:640:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:646:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:655:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:665:11: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:964:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:984:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:989:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:993:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:998:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:1003:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:1009:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../../src/gllib/strptime.c:1015:15: warning: comparison of unsigned 
expression < 0 is always false [-Wtype-limits]
../src/eval.d:5767:30: warning: variable 'byteptr' might be clobbered by 
'longjmp' or 'vfork' [-Wclobbered]
../src/socket.d:831:5: warning: implicit declaration of function 'ioctl' 
[-Wimplicit-function-declaration]
../src/win32aux.d:1096:18: warning: division by zero [-Wdiv-by-zero]
../src/genclisph.d:374:3: warning: comparison of unsigned expression < 0 
is always false [-Wtype-limits]
g:/gnu/home/src/clisp/clisp/modules/syscalls/calls.c:74:1: warning: 
'FMTID_SummaryInformation' initialized and declared 'exter
n' [enabled by default]
g:/gnu/home/src/clisp/clisp/modules/syscalls/calls.c:76:1: warning: 
'FMTID_UserDefinedProperties' initialized and declared 'ex
tern' [enabled by default]
g:/gnu/home/src/clisp/clisp/modules/rawsock/rawsock.c:691:3: warning: 
implicit declaration of function 'close_used_without_inc
luding_unistd_h' [-Wimplicit-function-declaration]


My next steps? Or this error from gllib and need write into gllib mail list?
Without rawsock clisp is built, but test failed:

(FLET ((CONS (X Y) `(KONS ,X ,Y))) (LET ((CONS (SYMBOL-FUNCTION '+))) 
(FUNCALL #'CONS (FUNCALL 'CONS 1 2) (FUNCALL CONS 1 2))))
EQUAL-OK: (KONS (1 . 2) 3)

*** - Program stack overflow. RESET
(LET* ((N (MIN (1- LAMBDA-PARAMETERS-LIMIT) (CASE (READ-FROM-STRING 
(SOFTWARE-TYPE)) ((G++ I686-PC-MINGW32-G++) 256) (I686-PC-MINGW32-GCC 
512) (T 1024)))) (VARS (LOOP REPEAT N COLLECT (GENSYM)))) (EVAL `(= ,N 
(FLET ((%F ,VARS (+ ,@VARS))) (%F ,@(LOOP FOR E IN VARS COLLECT 1))))))
Real time: 0.0468762 sec.
Run time: 0.046875 sec.
Space: 546872 Bytes
Bye.
make[1]: *** [tests] Error 1
make[1]: Leaving directory `/home/src/clisp/clisp/build-debug1/tests'


attempt to build with mt:

gcc -DUSE_CUSTOM_TLS=3 -g -O2 -W -Wswitch -Wcomment -Wpointer-arith 
-Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare 
-Wno-format-nonliteral -falign-functions=4 -D_WIN32 -g -O0 
-DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 
-DENABLE_UNICODE -DMULTITHREAD -DWIN32_THREADS -DDYNAMIC_FFI 
-L/usr/local/lib  spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o 
control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o 
hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o 
debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o 
foreign.o win32aux.o zthread.o built.o ari80386.o modules.o libgnu.a 
-lintl /usr/local/lib/libreadline.dll.a -L/usr/local/lib -ltermcap 
/usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -luser32 -lole32 
-loleaut32 -luuid -liconv -L/usr/local/lib -lsigsegv -lws2_32 -o lisp.exe
time.o: In function `get_thread_run_time':
g:\gnu\home\src\clisp\clisp\build-mt-debug/../src/time.d:195: undefined 
reference to `OpenThread'
collect2: ld returned 1 exit status

-- 
WBR, Yaroslav Kavenchuk

[ clisp-Bugs-3463337 ] PROBE-FILE

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

Bugs item #3463337, was opened at 2011-12-21 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=3463337&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: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
>Assigned to: Sam Steingold (sds)
Summary: PROBE-FILE

Initial Comment:
I noticed a compliance issue with GNU CLISP 2.49 for Windows.
(probe-file pathname) signalls an error instead of NIL when the pathname does not refer to an actual file.
An error can only be signalled if (wild-pathname-p pathname) is true which was not the case.


[14]> (wild-pathname-p "c:/Program Files/")

NIL
[15]> (file-exists-p "c:/Program Files/")

*** - PROBE-FILE: No file name given: #P"C:\\Program Files\\"
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [16]> 

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

>Comment By: Sam Steingold (sds)
Date: 2011-12-21 07:28

Message:
http://clisp.org/impnotes/dir-is-not-file.html

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

Comment By: Sam Steingold (sds)
Date: 2011-12-21 07:28

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=3463337&group_id=1355

[ clisp-Bugs-3463337 ] PROBE-FILE

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

Bugs item #3463337, was opened at 2011-12-21 03:40
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3463337&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: https://www.google.com/accounts ()
Assigned to: Bruno Haible (haible)
Summary: PROBE-FILE

Initial Comment:
I noticed a compliance issue with GNU CLISP 2.49 for Windows.
(probe-file pathname) signalls an error instead of NIL when the pathname does not refer to an actual file.
An error can only be signalled if (wild-pathname-p pathname) is true which was not the case.


[14]> (wild-pathname-p "c:/Program Files/")

NIL
[15]> (file-exists-p "c:/Program Files/")

*** - PROBE-FILE: No file name given: #P"C:\\Program Files\\"
The following restarts are available:
ABORT          :R1      Abort main loop
Break 1 [16]> 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3463337&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 (Settings changed) made by sds
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: lisp error
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Jak Wings (jakwings)
Assigned to: Sam Steingold (sds)
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.

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

Comment By: Jak Wings (jakwings)
Date: 2011-12-16 10:34

Message:
errrr.....sorry for such stupid misspelling...Thanks! @_@

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

Comment By: Jak Wings (jakwings)
Date: 2011-12-16 10:34

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.

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

Comment By: Sam Steingold (sds)
Date: 2011-12-07 10:34

Message:
you have a spelling error: PLIST contains ORGIN and you are looking for
ORIGIN.
(get 'cat 'orgin 'default)
NIL

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

Comment By: Sam Steingold (sds)
Date: 2011-12-07 10:34

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=3452284&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 (Comment added) 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: lisp error
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Jak Wings (jakwings)
Assigned to: Sam Steingold (sds)
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.

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

>Comment By: Jak Wings (jakwings)
Date: 2011-12-16 10:34

Message:
errrr.....sorry for such stupid misspelling...Thanks! @_@

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

Comment By: Jak Wings (jakwings)
Date: 2011-12-16 10:34

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.

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

Comment By: Sam Steingold (sds)
Date: 2011-12-07 10:34

Message:
you have a spelling error: PLIST contains ORGIN and you are looking for
ORIGIN.
(get 'cat 'orgin 'default)
NIL

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

Comment By: Sam Steingold (sds)
Date: 2011-12-07 10:34

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=3452284&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 (Settings changed) 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: Vladimir Lidovski (litwr)
Date: 2011-12-08 00:17

Message:
Thank you very much! You should only give me this link at first. Yes, there
is no any bug. Thank you again.

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

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

Message:
the bug is in you not understanding how lisp works.

http://www.lispworks.com/documentation/HyperSpec/Body/f_sort_.htm
sort and stable-sort destructively sort sequences according to the order
determined by the predicate function.
The sorting operation can be destructive in all cases. In the case of a
vector argument, this is accomplished by permuting the elements in place.
In the case of a list, the list is destructively reordered in the same
manner as for nreverse.


m is a symbol.
its symbol-value slot contains a cons cell - the first cons cell in the
list.
after sorting that cons cell CAR and CDR contain different referents.

if you want xsort to be non-destructive, you have to copy the argument:
(defun xsort (x) (sort (copy-seq l) #'<))


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

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

Message:
Sorry but you example is wrong. See
(setq l '(3 1 2))
(setq m l)
(xsort l)
m; this is completely stupid => (1 2 3)
This is obviously a *nightmare* bug. :-(

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

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-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-08 00:17

Message:
Thank you very much! You should only give me this link at first. Yes, there
is no any bug. Thank you again.

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

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

Message:
the bug is in you not understanding how lisp works.

http://www.lispworks.com/documentation/HyperSpec/Body/f_sort_.htm
sort and stable-sort destructively sort sequences according to the order
determined by the predicate function.
The sorting operation can be destructive in all cases. In the case of a
vector argument, this is accomplished by permuting the elements in place.
In the case of a list, the list is destructively reordered in the same
manner as for nreverse.


m is a symbol.
its symbol-value slot contains a cons cell - the first cons cell in the
list.
after sorting that cons cell CAR and CDR contain different referents.

if you want xsort to be non-destructive, you have to copy the argument:
(defun xsort (x) (sort (copy-seq l) #'<))


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

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

Message:
Sorry but you example is wrong. See
(setq l '(3 1 2))
(setq m l)
(xsort l)
m; this is completely stupid => (1 2 3)
This is obviously a *nightmare* bug. :-(

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

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 (Comment added) made by sds
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: lisp error
>Status: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Jak Wings (jakwings)
>Assigned to: Sam Steingold (sds)
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.

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

>Comment By: Sam Steingold (sds)
Date: 2011-12-07 10:34

Message:
you have a spelling error: PLIST contains ORGIN and you are looking for
ORIGIN.
(get 'cat 'orgin 'default)
NIL

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

Comment By: Sam Steingold (sds)
Date: 2011-12-07 10:34

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=3452284&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-07 07:43

Message:
the bug is in you not understanding how lisp works.

http://www.lispworks.com/documentation/HyperSpec/Body/f_sort_.htm
sort and stable-sort destructively sort sequences according to the order
determined by the predicate function.
The sorting operation can be destructive in all cases. In the case of a
vector argument, this is accomplished by permuting the elements in place.
In the case of a list, the list is destructively reordered in the same
manner as for nreverse.


m is a symbol.
its symbol-value slot contains a cons cell - the first cons cell in the
list.
after sorting that cons cell CAR and CDR contain different referents.

if you want xsort to be non-destructive, you have to copy the argument:
(defun xsort (x) (sort (copy-seq l) #'<))


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

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

Message:
Sorry but you example is wrong. See
(setq l '(3 1 2))
(setq m l)
(xsort l)
m; this is completely stupid => (1 2 3)
This is obviously a *nightmare* bug. :-(

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

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-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:13

Message:
Sorry but you example is wrong. See
(setq l '(3 1 2))
(setq m l)
(xsort l)
m; this is completely stupid => (1 2 3)
This is obviously a *nightmare* bug. :-(

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

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