clisp-devel — closed list for developers and testers

[ clisp-Bugs-3603421 ] glibc update

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

Bugs item #3603421, was opened at 2013-02-05 06:36
Message generated for change (Tracker Item Submitted) made by vcunat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3603421&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: modules
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vladimír Čunát (vcunat)
Assigned to: Bruno Haible (haible)
Summary: glibc update

Initial Comment:
At nixos.org we're stabilizing a branch containing glibc-2.17. The problem is that the C type __swblk_t has been removed.

I made a quick fix by removing the (def-c-type __swblk_t) line from modules/bindings/glibc/linux.lisp, which made it build (clisp-2.49 with patched <bits/ipctypes.h> usage).

Is this a correct way? Are you going solve this problem as well?

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

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

Re: Porting to emscripten

[Jason M. <ja...@mi...>]

Apparently current clang (3.2) which is required for emscripten cannot
build clisp;  I built clisp with clang a long time ago (2.7 or
so) so it must be a recentish bug.
On 11:33 Wed 30 Jan     , Sam Steingold wrote:
> > * Jason Miller <wnfba@zvye.pbz> [2013-01-25 17:11:11 -0800]:
> >
> > With the message:
> >> *** - LET: variable DECLARATIONS has no value
> >
> > Any clues for how to start tracking this down?  My debugging facilities
> > are limited to
> >  1) modifying the lisp or C code
> >  2) generating a list of all C functions called
> >  3) generating a list of all branches taken and manually matching it up
> 
> you need to figure out which DECLARATIONS is void.
> edit init.lisp and replace all DECLARATIONS with DECLARATIONS-<LINE> so
> that the error message will tell you which variable in which form is
> actually undefined.
> 
> however, unless you modified init.lisp, this will lead you away from the
> problem because init.lisp works correctly on other platforms.
> 
> I think the problem is that emscripten mis-compiles control.d.
> (this will not be the first - and not the 10th either - time clisp has
> uncovered a bug in a C compiler).
> 
> -- 
> Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
> http://www.childpsy.net/ http://camera.org http://americancensorship.org
> http://memri.org http://www.PetitionOnline.com/tap12009/ http://pmw.org.il
> A man paints with his brains and not with his hands.
> 

Re: Porting to emscripten

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

> * Jason Miller <wnfba@zvye.pbz> [2013-01-25 17:11:11 -0800]:
>
> With the message:
>> *** - LET: variable DECLARATIONS has no value
>
> Any clues for how to start tracking this down?  My debugging facilities
> are limited to
>  1) modifying the lisp or C code
>  2) generating a list of all C functions called
>  3) generating a list of all branches taken and manually matching it up

you need to figure out which DECLARATIONS is void.
edit init.lisp and replace all DECLARATIONS with DECLARATIONS-<LINE> so
that the error message will tell you which variable in which form is
actually undefined.

however, unless you modified init.lisp, this will lead you away from the
problem because init.lisp works correctly on other platforms.

I think the problem is that emscripten mis-compiles control.d.
(this will not be the first - and not the 10th either - time clisp has
uncovered a bug in a C compiler).

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://camera.org http://americancensorship.org
http://memri.org http://www.PetitionOnline.com/tap12009/ http://pmw.org.il
A man paints with his brains and not with his hands.

Porting to emscripten

[Jason M. <ja...@mi...>]

Yesterday I came up with the rather stupid idea of porting clisp to
emscripten.  I've gotten the build to go rather far, as I have a
lisp.run that kind-of-sort-of works, but fails during the loading of
init.lisp here:
  
> ;; for the time being the files don't have to be searched:
> (sys::%putd 'search-file
>  (sys::make-preliminary
>   (function search-file (lambda (filename &optional extensions (keep-dirs t))
>     (declare (ignore keep-dirs))
>     (mapcan #'(lambda (directory)
>                 (let ((directory (pathname-directory directory)))
>                   (mapcan #'(lambda (extension)
>                               (let ((filename (merge-pathnames filename
>                                                 (make-pathname
>                                                  :directory directory
>                                                  :type extension))))
>                                 (if (probe-file filename) (list filename) '())))
>                           extensions)))
>             (cons #"" *load-paths*))))))

With the message:
> *** - LET: variable DECLARATIONS has no value

Any clues for how to start tracking this down?  My debugging facilities
are limited to
 1) modifying the lisp or C code
 2) generating a list of all C functions called
 3) generating a list of all branches taken and manually matching it up

-Jason

[ clisp-Bugs-3601310 ] find-symbol in LINUX is wrong.

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

Bugs item #3601310, was opened at 2013-01-17 13:14
Message generated for change (Settings changed) made by haible
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3601310&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: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: find-symbol in LINUX is wrong.

Initial Comment:

C/Break 1 USER[8]> (find-symbol "SIN" "LINUX")
LINUX:sin ;
:EXTERNAL
C/Break 1 USER[8]> (find-symbol "sin" "LINUX")
NIL ;
NIL

The consequence is that:

C/USER[15]> (defpackage :example (:use :cl :linux))

*** - (use-package (#<package linux> #<package common-lisp>) #<package example>): 27 name conflicts remain
      Which symbol with name "SIN" should be accessible in #<package example>?
The following restarts are available:
COMMON-LISP    :R1      #<package common-lisp>
LINUX          :R2      #<package linux>
ABORT          :R3      Abort main loop
C/Break 1 USER[16]> :q
C/USER[17]> 


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

Comment By: Bruno Haible (haible)
Date: 2013-01-17 14:06

Message:
Package LINUX is case-sensitive and case-inverted:

$ clisp -K full
[1]> (setq p (find-package "LINUX"))
#<PACKAGE LINUX>
[2]> (package-case-sensitive-p p)
T
[3]> (package-case-inverted-p p)
T

Please read about these concepts in http://www.clisp.org/impnotes.html
section 11.5 "Package Case-Sensitivity"
http://www.clisp.org/impnotes.html#package-case

There is no ANSI compliance issue because case-sensitive packages, and in
particular the LINUX package, are outside the scope of ANSI CL.

The name conflicts between the COMMON-LISP package and the LINUX package
are real: the two SIN functions behave differently.
[9]> (cl:sin 1000000000.0d0)
0.5458434494091139d0
[10]> (linux:sin 1000000000.0d0)
0.5458434494486996d0


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

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

[ clisp-Bugs-3601310 ] find-symbol in LINUX is wrong.

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

Bugs item #3601310, was opened at 2013-01-17 13:14
Message generated for change (Comment added) made by haible
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3601310&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: find-symbol in LINUX is wrong.

Initial Comment:

C/Break 1 USER[8]> (find-symbol "SIN" "LINUX")
LINUX:sin ;
:EXTERNAL
C/Break 1 USER[8]> (find-symbol "sin" "LINUX")
NIL ;
NIL

The consequence is that:

C/USER[15]> (defpackage :example (:use :cl :linux))

*** - (use-package (#<package linux> #<package common-lisp>) #<package example>): 27 name conflicts remain
      Which symbol with name "SIN" should be accessible in #<package example>?
The following restarts are available:
COMMON-LISP    :R1      #<package common-lisp>
LINUX          :R2      #<package linux>
ABORT          :R3      Abort main loop
C/Break 1 USER[16]> :q
C/USER[17]> 


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

>Comment By: Bruno Haible (haible)
Date: 2013-01-17 14:06

Message:
Package LINUX is case-sensitive and case-inverted:

$ clisp -K full
[1]> (setq p (find-package "LINUX"))
#<PACKAGE LINUX>
[2]> (package-case-sensitive-p p)
T
[3]> (package-case-inverted-p p)
T

Please read about these concepts in http://www.clisp.org/impnotes.html
section 11.5 "Package Case-Sensitivity"
http://www.clisp.org/impnotes.html#package-case

There is no ANSI compliance issue because case-sensitive packages, and in
particular the LINUX package, are outside the scope of ANSI CL.

The name conflicts between the COMMON-LISP package and the LINUX package
are real: the two SIN functions behave differently.
[9]> (cl:sin 1000000000.0d0)
0.5458434494091139d0
[10]> (linux:sin 1000000000.0d0)
0.5458434494486996d0


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

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

[ clisp-Bugs-3601310 ] find-symbol in LINUX is wrong.

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

Bugs item #3601310, was opened at 2013-01-17 13:14
Message generated for change (Tracker Item Submitted) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3601310&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: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: find-symbol in LINUX is wrong.

Initial Comment:

C/Break 1 USER[8]> (find-symbol "SIN" "LINUX")
LINUX:sin ;
:EXTERNAL
C/Break 1 USER[8]> (find-symbol "sin" "LINUX")
NIL ;
NIL

The consequence is that:

C/USER[15]> (defpackage :example (:use :cl :linux))

*** - (use-package (#<package linux> #<package common-lisp>) #<package example>): 27 name conflicts remain
      Which symbol with name "SIN" should be accessible in #<package example>?
The following restarts are available:
COMMON-LISP    :R1      #<package common-lisp>
LINUX          :R2      #<package linux>
ABORT          :R3      Abort main loop
C/Break 1 USER[16]> :q
C/USER[17]> 


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

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

[ clisp-Bugs-3598754 ] sort + union destroys underlying union members

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

Bugs item #3598754, was opened at 2012-12-28 07:17
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3598754&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: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: winfriedp (wplapper-2)
Assigned to: Sam Steingold (sds)
Summary: sort + union destroys underlying union members

Initial Comment:
sorting a union destroys the underlying elements. I am using 'union' and not 'nunion'.

(defconstant *NEIGHBOURS2*  (map 'simple-vector #'(lambda(cell)
  (multiple-value-bind (r c b) (lin2rcbmvb cell)
    (sort (copy-seq
    (remove cell (union (union (svref *UNIT-LIST-VL2* r)
                               (svref *UNIT-LIST-VL2* c))
                        (svref *UNIT-LIST-VL2* b))))
    #'<))) *CELLS*))
Without forcing an additional coy via copy-seq, some of *UNIT-LIST-VL2* gets modified.

Base info: Kubuntu 12.10, uname -a: Linux kunbuntu-x64 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

clisp --version
GNU CLISP 2.49 (2010-07-07) (built on allspice.buildd [127.0.1.1])
Software: GNU C 4.6.2 
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. -Wl,-Bsymbolic-functions -Wl,-z,relro  -lreadline -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) kunbuntu-x64 [127.0.1.1]

I am building the structures *UNIT-LIST-VLx* and *NEIGHBOURSx* twice, in order to show the desctructive behaviour of sort.
SBCL and CCL do the right thing for me.

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

Comment By: winfriedp (wplapper-2)
Date: 2012-12-28 08:28

Message:
I admit defeat and surrender. You can close the incident / case / bug
report.

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

Comment By: Sam Steingold (sds)
Date: 2012-12-28 08:02

Message:
this behavior is fully ANSI compliant.
UNION does NOT modify its arguments, but its return value MAY share
structure with them.
An alternative to your approach is copying the arguments to UNION and using
NUNION.

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

Comment By: Sam Steingold (sds)
Date: 2012-12-28 08:02

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

[ clisp-Bugs-3598754 ] sort + union destroys underlying union members

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

Bugs item #3598754, was opened at 2012-12-28 07:17
Message generated for change (Comment added) made by wplapper-2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3598754&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: Invalid
Priority: 5
Private: No
Submitted By: winfriedp (wplapper-2)
Assigned to: Sam Steingold (sds)
Summary: sort + union destroys underlying union members

Initial Comment:
sorting a union destroys the underlying elements. I am using 'union' and not 'nunion'.

(defconstant *NEIGHBOURS2*  (map 'simple-vector #'(lambda(cell)
  (multiple-value-bind (r c b) (lin2rcbmvb cell)
    (sort (copy-seq
    (remove cell (union (union (svref *UNIT-LIST-VL2* r)
                               (svref *UNIT-LIST-VL2* c))
                        (svref *UNIT-LIST-VL2* b))))
    #'<))) *CELLS*))
Without forcing an additional coy via copy-seq, some of *UNIT-LIST-VL2* gets modified.

Base info: Kubuntu 12.10, uname -a: Linux kunbuntu-x64 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

clisp --version
GNU CLISP 2.49 (2010-07-07) (built on allspice.buildd [127.0.1.1])
Software: GNU C 4.6.2 
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. -Wl,-Bsymbolic-functions -Wl,-z,relro  -lreadline -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) kunbuntu-x64 [127.0.1.1]

I am building the structures *UNIT-LIST-VLx* and *NEIGHBOURSx* twice, in order to show the desctructive behaviour of sort.
SBCL and CCL do the right thing for me.

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

>Comment By: winfriedp (wplapper-2)
Date: 2012-12-28 08:28

Message:
I admit defeat and surrender. You can close the incident / case / bug
report.

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

Comment By: Sam Steingold (sds)
Date: 2012-12-28 08:02

Message:
this behavior is fully ANSI compliant.
UNION does NOT modify its arguments, but its return value MAY share
structure with them.
An alternative to your approach is copying the arguments to UNION and using
NUNION.

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

Comment By: Sam Steingold (sds)
Date: 2012-12-28 08:02

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

[ clisp-Bugs-3598754 ] sort + union destroys underlying union members

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

Bugs item #3598754, was opened at 2012-12-28 07:17
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3598754&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: winfriedp (wplapper-2)
>Assigned to: Sam Steingold (sds)
Summary: sort + union destroys underlying union members

Initial Comment:
sorting a union destroys the underlying elements. I am using 'union' and not 'nunion'.

(defconstant *NEIGHBOURS2*  (map 'simple-vector #'(lambda(cell)
  (multiple-value-bind (r c b) (lin2rcbmvb cell)
    (sort (copy-seq
    (remove cell (union (union (svref *UNIT-LIST-VL2* r)
                               (svref *UNIT-LIST-VL2* c))
                        (svref *UNIT-LIST-VL2* b))))
    #'<))) *CELLS*))
Without forcing an additional coy via copy-seq, some of *UNIT-LIST-VL2* gets modified.

Base info: Kubuntu 12.10, uname -a: Linux kunbuntu-x64 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

clisp --version
GNU CLISP 2.49 (2010-07-07) (built on allspice.buildd [127.0.1.1])
Software: GNU C 4.6.2 
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. -Wl,-Bsymbolic-functions -Wl,-z,relro  -lreadline -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) kunbuntu-x64 [127.0.1.1]

I am building the structures *UNIT-LIST-VLx* and *NEIGHBOURSx* twice, in order to show the desctructive behaviour of sort.
SBCL and CCL do the right thing for me.

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

>Comment By: Sam Steingold (sds)
Date: 2012-12-28 08:02

Message:
this behavior is fully ANSI compliant.
UNION does NOT modify its arguments, but its return value MAY share
structure with them.
An alternative to your approach is copying the arguments to UNION and using
NUNION.

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

Comment By: Sam Steingold (sds)
Date: 2012-12-28 08:02

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

[ clisp-Bugs-3598754 ] sort + union destroys underlying union members

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

Bugs item #3598754, was opened at 2012-12-28 07:17
Message generated for change (Tracker Item Submitted) made by wplapper-2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3598754&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: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: winfriedp (wplapper-2)
Assigned to: Nobody/Anonymous (nobody)
Summary: sort + union destroys underlying union members

Initial Comment:
sorting a union destroys the underlying elements. I am using 'union' and not 'nunion'.

(defconstant *NEIGHBOURS2*  (map 'simple-vector #'(lambda(cell)
  (multiple-value-bind (r c b) (lin2rcbmvb cell)
    (sort (copy-seq
    (remove cell (union (union (svref *UNIT-LIST-VL2* r)
                               (svref *UNIT-LIST-VL2* c))
                        (svref *UNIT-LIST-VL2* b))))
    #'<))) *CELLS*))
Without forcing an additional coy via copy-seq, some of *UNIT-LIST-VL2* gets modified.

Base info: Kubuntu 12.10, uname -a: Linux kunbuntu-x64 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

clisp --version
GNU CLISP 2.49 (2010-07-07) (built on allspice.buildd [127.0.1.1])
Software: GNU C 4.6.2 
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. -Wl,-Bsymbolic-functions -Wl,-z,relro  -lreadline -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) kunbuntu-x64 [127.0.1.1]

I am building the structures *UNIT-LIST-VLx* and *NEIGHBOURSx* twice, in order to show the desctructive behaviour of sort.
SBCL and CCL do the right thing for me.

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

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

[ clisp-Bugs-3597512 ] eq load-time-value forms get coalesced

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

Bugs item #3597512, was opened at 2012-12-19 09:05
Message generated for change (Tracker Item Submitted) made by stassats
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3597512&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: stassats (stassats)
Assigned to: Bruno Haible (haible)
Summary: eq load-time-value forms get coalesced

Initial Comment:
When the following is compiled with compile-file
(defun foo ()
  (eq #1=(load-time-value (cons 1 2)) #1#))

the result of (foo) becomes T. And this usually manifests in macros.
CLHS states

"If nil [read-only-p] (the default), the result must be neither copied nor coalesced; it must be considered to be potentially modifiable data."
http://www.lispworks.com/reference/HyperSpec/Body/s_ld_tim.htm

The code which appears to be responsible for this is
http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/file/696bfff6e3d1/src/compiler.lisp#l8116

The patch that fixes it for me is attached, but not sure about other implications of such a change.


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

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

Re: argv[0] not available to CLISP programs

[Andrew P. <and...@gm...>]

> Are you trying to figure out whether a particular file is the "main
> script" as opposed to being loaded from some other script?
>

Yes. There's no standard name for the behavior of bundling a package API
with a usable CLI in a single code file, so I've taken to calling it
"scripted main" and begun documenting on Rosetta
Code<http://rosettacode.org/wiki/Scripted_main> how
to achieve this in a variety of programming languages. Another word for
programs this is "modulino".


> One way to do this is to check your own variable *main* and bind it if
> it is not bound already.  This is portable.
> Another way is to use SYS::*LOAD-LEVEL*, which is bound to incremented
> values by LOAD.
>

Yeah, so I'm looking for a simpler way to do this. Some languages expose
this via a variable, like $0, or a single function call.

Yet another way is EXT:ARGV
> http://clisp.org/impnotes/environment-enq.html#argv


This isn't portable. It involves CLISP-specific parsing to reliably extract
the script name, so the same code can't be used in ECL, CCL, ABCL, ...

I like my code to be very portable.


> 2 years ago you asked about this here:
>
> http://sourceforge.net/tracker/?func=detail&aid=3124233&group_id=1355&atid=351355
> can you offer a better rationale than then?
>

I agree that modifying the output of ext:*args* would break reverse
compatibility.

I agree that we don't want to break reverse compatibility.

So I'll tweak my suggestion and request that CLISP provides another
function much like ext:*args*, except that it exposes an equivalent to C's
argv[0].

An easy way to satisfy this is to make a function ext:*argv0*.

-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: argv[0] not available to CLISP programs

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

> * Andrew Pennebaker <naqerj.craaronxre@tznvy.pbz> [2012-11-20 11:43:30 -0500]:
>
> This isn't completely accurate.

what isn't?

> *LOAD-TRUENAME* is overwritten when you (load) other code files,

bound, not overwritten.

> so it doesn't let you reliably get the original script name.

I don't think I quite understand your use case.
Are you trying to figure out whether a particular file is the "main
script" as opposed to being loaded from some other script?
One way to do this is to check your own variable *main* and bind it if
it is not bound already.  This is portable.
Another way is to use SYS::*LOAD-LEVEL*, which is bound to incremented
values by LOAD.
Yet another way is EXT:ARGV http://clisp.org/impnotes/environment-enq.html#argv

2 years ago you asked about this here:
http://sourceforge.net/tracker/?func=detail&aid=3124233&group_id=1355&atid=351355
can you offer a better rationale than then?
Maybe you want to continue this discussion there?

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://www.PetitionOnline.com/tap12009/
http://americancensorship.org http://honestreporting.com http://pmw.org.il
If I had known that it was harmless, I would have killed it myself.

Re: argv[0] not available to CLISP programs

[Andrew P. <and...@gm...>]

This isn't completely accurate. *LOAD-TRUENAME* is overwritten when you
(load) other code files, so it doesn't let you reliably get the original
script name. This difference is detectable in general scripting languages
such as Ruby:

if __FILE__==$0
main
end

How can this be done in CLISP? So far, I can manage with a shebang
hack<https://github.com/mcandre/scriptname/blob/master/scriptname.lisp>,
but it prevents the code from dot slashing properly with other CLs.


On Tue, Nov 20, 2012 at 11:03 AM, Sam Steingold <sd...@gn...> wrote:

> > * Andrew Pennebaker <naqerj.craaronxre@tznvy.pbz> [2012-11-20 09:39:02
> -0500]:
> >
> > Many CL's offer a way to retrieve the Lisp script name, but CLISP
> > appears to silently drop this information.
>
> http://clisp.org/impnotes/quickstart.html#script-exec
>    The file is loaded normally, through the function LOAD (in
>    particular, the name of the script file, which is $0 in /bin/sh, can
>    be found in *LOAD-TRUENAME* and *LOAD-PATHNAME*).
>
> http://clisp.org/impnotes/faq.html#faq-fine
>
>
> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X
> 11.0.11103000
> http://www.childpsy.net/ http://www.PetitionOnline.com/tap12009/
> http://truepeace.org http://camera.org http://www.memritv.org
> He who laughs last did not get the joke.
>



-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: argv[0] not available to CLISP programs

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

> * Andrew Pennebaker <naqerj.craaronxre@tznvy.pbz> [2012-11-20 09:39:02 -0500]:
>
> Many CL's offer a way to retrieve the Lisp script name, but CLISP
> appears to silently drop this information.

http://clisp.org/impnotes/quickstart.html#script-exec
   The file is loaded normally, through the function LOAD (in
   particular, the name of the script file, which is $0 in /bin/sh, can
   be found in *LOAD-TRUENAME* and *LOAD-PATHNAME*).

http://clisp.org/impnotes/faq.html#faq-fine


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://www.PetitionOnline.com/tap12009/
http://truepeace.org http://camera.org http://www.memritv.org
He who laughs last did not get the joke.

argv[0] not available to CLISP programs

[Andrew P. <and...@gm...>]

Many CL's offer a way to retrieve the Lisp script name, but CLISP appears
to silently drop this information. I've managed a hack around this, but not
without caveats.

https://github.com/mcandre/scriptname/blob/master/scriptname.lisp

A shebang line forces the script name onto the shell arguments twice,
forcing it into ext:*args*. However, this method only works when the Lisp
script is run with Unix ./ notation (chmod a+x && ./scriptname.lisp), and
the script must be run with CLISP; Thus the script immediately loses
portability to other CL's which require their own shebangs.

Could CLISP please provide an accessor similar to ext:*args* that exposes
argv[0], as a C program would see it? Thank you.

-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: Can clisp use swank ?

[Vladimir T. <vtz...@gm...>]

On Wed, Oct 10, 2012 at 10:31 AM, z_axis <z_...@16...> wrote:
> What you said is right .I didnot load the right swank version but a version
> from slimv.
> Now it works using :spawn communication style. However, the slimv cannot do
> any evaluation after connecting to the swank server.

I do not use slimv however I can confirm that emacs/slime works as expected.
Check that slimv uses the correct files on it's side.

Re: Can clisp use swank ?

[Vladimir T. <vtz...@gm...>]

Here is what I get after changing preferred communication style to :spawn:

[1]> (load #p"~/quicklisp/dists/quicklisp/software/slime-20120909-cvs/start-swank.lisp")
..................
;; Swank started at port: 4005.
[2]> (list-threads)
(#<THREAD "Swank 4005"> #<THREAD "Swank Sentinel"> #<THREAD "main thread">)

So, I get back to the repl and have two new threads for handling swank stuff.
Wondering why you do not get the repl - can you check that you have
these new threads (after interrupting with CTRL-C)?

>> (load "~/.vim/slime/start-swank.lisp")
Please check that this launches the correct swank version.

I am running clisp built from current source repository but I do not
think this is related.

Vlad

PS: please write to clisp-devel instead directly to me.

On Wed, Oct 10, 2012 at 4:07 AM, z_axis <z_...@16...> wrote:
> $cat
> ~/quicklisp/dists/quicklisp/software/slime-20120909-cvs/swank-clisp.lisp |
> grep preferred
> (defimplementation preferred-communication-style () :spawn)
>
>> (lisp-implementation-version)
>
> "2.49 (2010-07-07) (built 3558763409) (memory 3558763794)"
>
>> *features*
>
> ((:QUICKLISP :ASDF2 :ASDF :ASDF-UNIX :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 :PC386 :UNIX)
>
>> (load "~/.vim/slime/start-swank.lisp")
>
> ...
> ;;; Swank started at port: 4005.
>
>
> then i can not use clisp unless pressing Ctrl+C to break.
>
> C(+ 1 2)
> ^C
> ** - Continuable Error
> Condition of type SYSTEM::INTERRUPT-CONDITION.
> If you continue (by typing 'continue'): Ctrl-C: User break
> The following restarts are also available:
> SKIP           :R1      skip (CREATE-SERVER PORT 4005 ...)
> RETRY          :R2      retry (CREATE-SERVER PORT 4005 ...)
> STOP           :R3      stop loading file
> /home/sw2wolf/.vim/slime/start-swank.lisp
> ABORT          :R4      Abort main loopondition of type
> SYSTEM::INTERRUPT-CONDITION.
>
>
> Regards!
>
> 在 Wed, 10 Oct 2012 03:59:30 +0800，Vladimir Tzankov <vtz...@gm...> 写道:
>
>
>> On Tue, Oct 9, 2012 at 11:03 AM, z_axis <z_...@16...> wrote:
>>>
>>> Would you like shed a light on me ?
>>> http://stackoverflow.com/questions/12650082/about-stumpwm-and-swank
>>>
>>> Once swank server is started, i can do nothing using stumpwm .
>>
>>
>> The swank server supports several communication styles. Latest version
>> does not specify preferred one for clisp and it fallbacks to
>> singlethreaded-connection. This means that all i/o, processing, etc
>> happens in the clisp main thread, i.e. you may have single swank
>> connection and start-server never returns.
>>
>> If you want to have multiple connections - change (in
>> swank-clisp.lisp) preferred-communication-style to return :spawn
>> (however did not test this - just reading the code).
>>
>> Vlad
>
>

Re: Can clisp use swank ?

[Vladimir T. <vtz...@gm...>]

On Tue, Oct 9, 2012 at 11:03 AM, z_axis <z_...@16...> wrote:
> Would you like shed a light on me ?
> http://stackoverflow.com/questions/12650082/about-stumpwm-and-swank
>
> Once swank server is started, i can do nothing using stumpwm .

The swank server supports several communication styles. Latest version
does not specify preferred one for clisp and it fallbacks to
singlethreaded-connection. This means that all i/o, processing, etc
happens in the clisp main thread, i.e. you may have single swank
connection and start-server never returns.

If you want to have multiple connections - change (in
swank-clisp.lisp) preferred-communication-style to return :spawn
(however did not test this - just reading the code).

Vlad

Re: Can clisp use swank ?

[Vladimir T. <vtz...@gm...>]

yes

On Tue, Oct 9, 2012 at 10:47 AM, z_axis <z_...@16...> wrote:
> Can clisp without thread support run swank server ?
>
> Best Regards!
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel

Can clisp use swank ?

[z_axis <z_...@16...>]

Can clisp without thread support run swank server ?

Best Regards!

[ clisp-Patches-3572516 ] Berkeley db module configure error

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

Patches item #3572516, was opened at 2012-09-27 13:03
Message generated for change (Tracker Item Submitted) made by jjames
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=3572516&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: Jerry James (jjames)
Assigned to: Nobody/Anonymous (nobody)
Summary: Berkeley db module configure error

Initial Comment:
The berkeley-db module's configure script adds -Werror to CFLAGS.  With recent versions of GCC, this code triggers a warning (and therefore an error) about the use of an uninitialized variable:

DB_ENV dbe; dbe.set_errcall(&dbe,&my_callback);

There are multiple possible fixes.  I chose to also add -Wno-uninitialized to CFLAGS in this patch.  Not adding -Werror is another option.

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

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

[ clisp-Patches-3572511 ] Fix libsvm module compilation with C compiler

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

Patches item #3572511, was opened at 2012-09-27 12:58
Message generated for change (Tracker Item Submitted) made by jjames
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=3572511&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: Jerry James (jjames)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix libsvm module compilation with C compiler

Initial Comment:
This patch fixes an error encountered while compiling the libsvm module with a C compiler.  The fix is simple and, I think, obviously correct.

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

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

[ clisp-Patches-3529607 ] Format specifier patch

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

Patches item #3529607, was opened at 2012-05-24 15:52
Message generated for change (Comment added) made by jjames
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=3529607&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: Jerry James (jjames)
Assigned to: Nobody/Anonymous (nobody)
Summary: Format specifier patch

Initial Comment:
While compiling on a 32-bit platform, I saw some GCC warnings about printf arguments not matching the corresponding format specifiers.  This patch fixes all of the warnings I saw on that platform.

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

>Comment By: Jerry James (jjames)
Date: 2012-09-27 12:56

Message:
I have attached a second version of the patch.  With this version, I see no
format specifier warnings on either 32-bit or 64-bit x86.  On the other
hand, this patch is uglier than my first attempt. :-(

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

Comment By: Sam Steingold (sds)
Date: 2012-05-24 18:37

Message:
this patch results in these warnings on amd64:

In file included from ../src/spvw.d:161:0:
../src/spvw_debug.d: In function ‘nobject_out1’:
../src/spvw_debug.d:123:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintWL’
[-Wformat]
../src/spvw_debug.d:124:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
../src/spvw_debug.d:188:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
../src/spvw_debug.d:188:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 4 has type ‘unsigned int’
[-Wformat]
../src/spvw_debug.d:188:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 5 has type ‘unsigned int’
[-Wformat]
../src/spvw_debug.d:284:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘unsigned int’
[-Wformat]
../src/spvw_debug.d:289:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat]
../src/spvw_debug.d:289:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 6 has type ‘int’ [-Wformat]
../src/spvw_debug.d:289:13: warning: format ‘%u’ expects argument of
type ‘unsigned int’, but argument 7 has type ‘long unsigned int’
[-Wformat]
../src/spvw_debug.d: In function ‘bt_out’:
../src/spvw_debug.d:362:11: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
../src/spvw_debug.d:371:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘unsigned int’
[-Wformat]
In file included from ../src/spvw.d:3996:0:
../src/spvw_memfile.d: In function ‘loadmem_from_handle’:
../src/spvw_memfile.d:1820:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
In file included from ../src/error.d:502:0:
../src/errunix.d: In function ‘errno_out_low’:
../src/errunix.d:97:3: warning: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 4 has type ‘uintL’ [-Wformat]


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

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