clisp-devel — closed list for developers and testers

[ clisp-Bugs-3114096 ] Conformity and convenience problems with pathnames

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

Bugs item #3114096, was opened at 2010-11-21 04:28
Message generated for change (Tracker Item Submitted) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3114096&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: Conformity and convenience problems with pathnames

Initial Comment:
Hello,

It is well known that implementations of CL pathnames have been greatly
implementation dependant.  However, the standard still specifies clear
behavior for logical pathnames, for one thing, and for the other, since
there are several implementations working on the same POSIX systems
(unix including linux and MacOSX; and MS-Windows), it is desirable that
all implementations converge in their handling of pathnames on these
plateforms.

Personnaly, I resolved to use logical pathnames and logical-pathname
translations as much as possible, and to use make-pathname to build
portably physical pathnames. 

However, most implementations have problems dealing with these two
aspects.   To improve the situation, I wrote a little script to check
the behavior of implementations in these two aspects.

The script can be found at:

ftp://ftp.informatimago.com/users/pjb/lisp/check-pathnames.lisp

Since I'm sending a similar message to most implementation  lists, it
might be better, if there is any need for 'language lawyer' discussions,
to direct them to news:comp.lang.lisp.


Here are the results for clisp:
------------------------------------------------------------------------
[pjb@kuiper :0.0 ~]$ clisp -ansi -norc 
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> (load "/home/pjb/src/lisp/check-pathnames.lisp")
;; Loading file /home/pjb/src/lisp/check-pathnames.lisp ...
================================================================================

Test and probe conforming logical pathnames, and their translation to
unix physical pathnames.

We want to check the good working of logical pathnames, and the
translation of logical pathnames to physical pathnames, in a
semi-standard way on unix systems.

Namely, given the logical host and its translations:

  (setf (logical-pathname-translations "LOGICAL") nil)
  (setf (logical-pathname-translations "LOGICAL") 
        '((#P"LOGICAL:**;*.*" #P"/tmp/**/*.*")
          (#P"LOGICAL:**;*"   #P"/tmp/**/*")))

#P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
must be the same as (make-pathname :host "LOGICAL"
                                   :directory '(:absolute "DIR" "SUBDIR")
                                   :name "NAME" :type "TYPE" :version :newest
                                   :case :common)
and must translate to: #P"/tmp/dir/subdir/name.type" on unix.



Merging physical pathnames specified with :case :common is also tested:

  (merge-pathnames (make-pathname :directory '(:relative "DIR" "SUBDIR")
                                  :name "NAME" :type "TYPE" :version :newest
                                  :case :common :default #1=#P"/tmp/")
                    #1# nil)

must give #P"/tmp/dir/subdir/name.type".

================================================================================
The customary case for the file system of CLISP (2.49 (2010-07-07) (built 
3498306068) (memory 3498306421)) is lower case.

================================================================================
(MAKE-PATHNAME :HOST "LOGICAL" :DEVICE :UNSPECIFIC :DIRECTORY
 (:ABSOLUTE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :VERSION :NEWEST :CASE
 :COMMON)


LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.type.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  
--------------------------------------------------------------------------------
Failed assertion: (DIRLIST= (PATHNAME-DIRECTORY PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-DIRECTORY PATH :CASE :COMMON) = (:ABSOLUTE "dir" "subdir")
    and: (POP EXPECTED-VALUES) = (:ABSOLUTE "DIR" "SUBDIR")
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-NAME PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-NAME PATH :CASE :COMMON) = "name"
    and: (POP EXPECTED-VALUES) = "NAME"
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-TYPE PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-TYPE PATH :CASE :COMMON) = "type"
    and: (POP EXPECTED-VALUES) = "TYPE"
--------------------------------------------------------------------------------
Failed assertion: (STRING= EXPECTED-PRINTED (PRIN1-TO-STRING PATH))
   with: EXPECTED-PRINTED = "#P\"LOGICAL:DIR;SUBDIR;NAME.TYPE\""
    and: (PRIN1-TO-STRING PATH) = "#P\"LOGICAL:dir;subdir;name.type.NEWEST\""

It would be better if logical pathnames were printed using upper case
letters, mostly because of 19.3.1.1.7, and because:

    22.1.1 Overview of The Lisp Printer

    Reading a printed representation typically produces an object that is
    equal to the originally printed object. 

and

    2.4.8.14 Sharpsign P

    #P reads a following object, which must be a string.

    #P<<expression>> is equivalent to #.(parse-namestring '<<expression>>),
    except that #P is not affected by *read-eval*.

and

    Function PARSE-NAMESTRING

    * If host is nil and thing is a syntactically valid logical pathname
      namestring containing an explicit host, then it is parsed as a
      logical pathname namestring.

and

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring
    When parsing words and wildcard-words, lowercase letters are translated to uppercase.

Notice that means that a logical pathname built with mixed cases (or
lower case), cannot be printed readably with a conforming syntax (but
it doesn't matter, since it's not a conforming logical pathname
anyways).
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-HOST PATH :CASE :LOCAL) (POP EXPECTED-VALUES))
   with: (PATHNAME-HOST PATH :CASE :LOCAL) = "LOGICAL"
    and: (POP EXPECTED-VALUES) = "logical"
19.2.2.1.2  makes no exception for pathname-host of logical pathnames.



================================================================================
(MAKE-PATHNAME :HOST "logical" :DEVICE :UNSPECIFIC :DIRECTORY
 (:ABSOLUTE "dir" "subdir") :NAME "name" :TYPE "type" :VERSION :NEWEST :CASE
 :LOCAL)


LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.type.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  
--------------------------------------------------------------------------------
Failed assertion: (DIRLIST= (PATHNAME-DIRECTORY PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-DIRECTORY PATH :CASE :COMMON) = (:ABSOLUTE "dir" "subdir")
    and: (POP EXPECTED-VALUES) = (:ABSOLUTE "DIR" "SUBDIR")
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-NAME PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-NAME PATH :CASE :COMMON) = "name"
    and: (POP EXPECTED-VALUES) = "NAME"
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-TYPE PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-TYPE PATH :CASE :COMMON) = "type"
    and: (POP EXPECTED-VALUES) = "TYPE"
--------------------------------------------------------------------------------
Failed assertion: (STRING= EXPECTED-PRINTED (PRIN1-TO-STRING PATH))
   with: EXPECTED-PRINTED = "#P\"LOGICAL:DIR;SUBDIR;NAME.TYPE\""
    and: (PRIN1-TO-STRING PATH) = "#P\"LOGICAL:dir;subdir;name.type.NEWEST\""

It would be better if logical pathnames were printed using upper case
letters, mostly because of 19.3.1.1.7, and because:

    22.1.1 Overview of The Lisp Printer

    Reading a printed representation typically produces an object that is
    equal to the originally printed object. 

and

    2.4.8.14 Sharpsign P

    #P reads a following object, which must be a string.

    #P<<expression>> is equivalent to #.(parse-namestring '<<expression>>),
    except that #P is not affected by *read-eval*.

and

    Function PARSE-NAMESTRING

    * If host is nil and thing is a syntactically valid logical pathname
      namestring containing an explicit host, then it is parsed as a
      logical pathname namestring.

and

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring
    When parsing words and wildcard-words, lowercase letters are translated to uppercase.

Notice that means that a logical pathname built with mixed cases (or
lower case), cannot be printed readably with a conforming syntax (but
it doesn't matter, since it's not a conforming logical pathname
anyways).
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-HOST PATH :CASE :LOCAL) (POP EXPECTED-VALUES))
   with: (PATHNAME-HOST PATH :CASE :LOCAL) = "LOGICAL"
    and: (POP EXPECTED-VALUES) = "logical"
19.2.2.1.2  makes no exception for pathname-host of logical pathnames.

--------------------------------------------------------------------------------
Failed assertion: 
(PATHNAME-EQUAL #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
 (MAKE-PATHNAME :HOST "LOGICAL" :DEVICE :UNSPECIFIC :DIRECTORY
  '(:ABSOLUTE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :VERSION :NEWEST :CASE
  :COMMON))
   with: #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST" = #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
    and: 
(MAKE-PATHNAME :HOST "LOGICAL" :DEVICE :UNSPECIFIC :DIRECTORY
 '(:ABSOLUTE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :VERSION :NEWEST :CASE
 :COMMON) = #P"LOGICAL:dir;subdir;name.type.NEWEST"

LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "TYPE"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "TYPE"
Version   : :NEWEST
--------------------  

LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.type.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  
;; Loaded file /home/pjb/src/lisp/check-pathnames.lisp
T
[2]> (quit)
Bye.
[pjb@kuiper :0.0 ~]$ 


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

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

Re: 2.49 check-tests-parallel fails.

[<pj...@in...>]

Vladimir Tzankov <vtz...@gm...> writes:

> On 11/18/10, Pascal J. Bourguignon <pj...@in...> wrote:
>>
>> Compiling 2.49 on gentoo x86_64 fails in the check-tests-parallel:
>>
>
> It's normal. Hashtables and CLOS are not thread safe yet.
> Calling defclass, defmethod, etc simultaneously from different threads
> causes undefined behavior (including segfaults).
> Usually I run check-tests-parallel with clos and mop tests disabled.

Ok.


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

Re: 2.49 check-tests-parallel fails.

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

On 11/18/10, Pascal J. Bourguignon <pj...@in...> wrote:
>
> Compiling 2.49 on gentoo x86_64 fails in the check-tests-parallel:
>

It's normal. Hashtables and CLOS are not thread safe yet.
Calling defclass, defmethod, etc simultaneously from different threads
causes undefined behavior (including segfaults).
Usually I run check-tests-parallel with clos and mop tests disabled.

Vladimir

2.49 check-tests-parallel fails.

[<pj...@in...>]

Compiling 2.49 on gentoo x86_64 fails in the check-tests-parallel:


(
(("format-a:--ABc  --ende-*CDDDDR" '
(PROGNAROGN  (DEFGENERIC FOREIGN-FREE TEST-MC66-2 (FPCALLBACK) (): METHOD-COMBINATION4)MC66
 "xyz") (:METHOD (X) (LIST X))) (TEST-MC66-2 'A))
(
(("format-a:--ABc  --ende-*CDDDDR" '
(PROGNAROGN  (DEFGENERIC FOREIGN-FREE TEST-MC66-2 (FPCALLBACK) (): METHOD-COMBINATION4)MC66
 "xyz") (:METHOD (X) (LIST X))) (TEST-MC66-2 'A))

*** - handle_fault error2 ! address = 0xd00033423 not in [0xcccd77ed0,0xcccf4a000) !
(EQL-OK: FORMAT NIL "format-a:--~5,2a--ende-*" 
'|ABc|)
(EQL-OK: FORMAT NIL "format-a:--~5,2a--ende-*" 
'|ABc|)
EQL-OK: ERROR
 be cured. Fault address = 0xd00033423.

*** - handle_fault error2 ! address = 0x3340d1000 not in [0x333d28000,0x334090d58) !
GC count: 343
SIGSEGV cannot be cured. Fault address = 0x3340d1000.
Space collected by GC:GC count: 343
 330387632
Space collected by GC: 330387632
Run time: 22 159630
Run time: 22 160630
Real time: 48 432938
Real time: 48 433152
GC time: 0 876863
GC time: 0 876863
Permanently allocated: 176760 bytes.
Permanently allocated: 176760 bytes.Currently in use: 5898464 bytes.

Free space: 1187322 bytes.
Currently in use: 5898464 bytes.
Free space: 1187322 bytes.
make[1]: *** [parallel] Segmentation fault
make[1]: Leaving directory `/data/src/languages/clisp/clisp-2.49/build/tests'
make: *** [check-tests-parallel] Error 2



My compilation script is:

------------------------------------------------------------------------
#!/bin/bash 
VERSION=2.49

cd "$(dirname "$0")"
LOGBASE="$(pwd)/$(basename "$0")"

rm -rf  clisp-${VERSION}
tar jxf clisp-${VERSION}.tar.bz2
cd      clisp-${VERSION}

echo '// Configuring and Compiling'
./configure \
    --prefix=/data/languages/clisp-${VERSION} \
    --cbc build \
    --with-threads=POSIX_THREADS \
    --with-module=berkeley-db \
    --with-module=bindings/glibc \
    --with-module=clx/new-clx \
    --with-module=dbus \
    --with-module=gdbm \
    --with-module=gtk2 \
    --with-module=i18n \
    --with-module=libsvm \
    --with-module=pari \
    --with-module=pcre \
    --with-module=postgresql \
    --with-module=queens \
    --with-module=rawsock \
    --with-module=readline \
    --with-module=regexp \
    --with-module=syscalls \
    --with-module=wildcard \
    --with-module=zlib \
    --hyperspec=http://localhost/local/lisp/www.lispworks.com/documentation/HyperSpec/ \
    > "${LOGBASE}".configure.log  2>&1 \
    && ( echo '// Making all' ; make -C build all     > "${LOGBASE}".make-all.log       2>&1 ) \
    && ( echo '// Intalling'  ; make -C build install > "${LOGBASE}".make-install.log   2>&1 )
------------------------------------------------------------------------

Linux kuiper 2.6.34-xen-r3-kvm-nvidia-joy-c7 #3 SMP Fri Oct 8 12:01:59 CEST 2010 x86_64 Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz GenuineIntel GNU/Linux

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

[ clisp-Bugs-3110367 ] :case :common for logical pathnames.

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

Bugs item #3110367, was opened at 2010-11-17 00:33
Message generated for change (Comment added) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3110367&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: Rejected
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: :case :common for logical pathnames.

Initial Comment:
When creating a logical pathname with make-pathname, :case :common, the pathname components are downcased.  

I would argue that the customary case for logical pathnames is upper case, since:

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring

    When parsing words and wildcard-words, lowercase letters are translated to uppercase. 

I'd expect (string= (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
                               (pathname-name #P"TEST:FILE.DATA"))
and of course (string= "FILE" (pathname-name #P"TEST:FILE.DATA"))
and similarly for the other pathname components.

[pjb@kuiper :0.0 ~]$ clisp -norc -ansi
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> (setf (logical-pathname-translations "TEST") nil)
NIL
[2]> (setf (logical-pathname-translations "TEST") (quote ((#P"TEST:**;*.*" "/tmp/**/*.*")
                                                     (#P"TEST:**;*" "/tmp/**/*"))))
((#P"TEST:**;*.*" "/tmp/**/*.*") (#P"TEST:**;*" "/tmp/**/*"))
[3]> (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
"file"
[4]> (pathname-name #P"TEST:FILE.DATA")
"FILE"
[5]> 


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

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-17 09:04

Message:
I forgot the definition of print-pathname:

(defun print-pathname (pathname)
  (format t "~%~A ~S~%" (type-of pathname) pathname)
  (format t "--------------------  :case :local (default)~%")
  (format t "~&~{~{~@(~9A~) : ~S~&~}~}"
          (mapcar (lambda (name field) (list name (funcall field
pathname)))
                  '(host device directory name type version)
                  '(pathname-host pathname-device pathname-directory
                    pathname-name pathname-type pathname-version)))
  (format t "--------------------  :case :common~%")
  (format t "~&~{~{~@(~9A~) : ~S~&~}~}"
          (mapcar (lambda (name field arguments) (list name (apply field
pathname arguments)))
                  '(host device directory name type version)
                  '(pathname-host pathname-device pathname-directory
                    pathname-name pathname-type pathname-version)
                  '((:case :common) (:case :common) (:case :common)
                    (:case :common) (:case :common) ())))
  (format t "--------------------  ~%")
  pathname)


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

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-17 09:04

Message:
- I agree, I was wrong, 19.3.1.1.7 doesn't apply.

- make-pathname creates a logical pathname when the :host parameter is
  a logical host, in clisp, as in any conforming implementation.

- I was also wrong with:
  (pathname-name (make-pathname :host "TEST" :name  "FILE" :type "DATA"
:case :common))
  it should indeed return "file"; this is correctly implemented in clisp.

- but the other form, (pathname-name #P"TEST:FILE.DATA") should return
  "file", not "FILE", because by default the :case parameter of
  pathname-name is :local, and "19.2.2.1.2.2 Common Case in Pathname
  Components" mentions that round trip should be information
  preserving (including case for local pathnames).


Actually there are other problems.  In an implementation where the
customary case is lower case, the pathname accessors cannot return the
same case with and without :case :common, but this is what clisp does:


CL-USER> (print-pathname (make-pathname :host "LOGICAL" :device
:unspecific :directory '(:absolute "DIR" "SUBDIR") :name  "NAME" :type
"DATA" :version nil :case :common))

LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.data"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "data"
Version   : NIL
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "data"
Version   : NIL
--------------------  
#P"LOGICAL:dir;subdir;name.data"
CL-USER> (print-pathname #P"LOGICAL:dir;subdir;name.data")

LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.DATA"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  
#P"LOGICAL:DIR;SUBDIR;NAME.DATA"
CL-USER> (print-pathname #P"LOGICAL:DIR;SUBDIR;NAME.DATA")

LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.DATA"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  
#P"LOGICAL:DIR;SUBDIR;NAME.DATA"



There is also the problem that the result of:
 (make-pathname :host "LOGICAL" :device :unspecific :directory '(:absolute
"DIR" "SUBDIR") :name  "NAME" :type "DATA" :version nil :case :common)
is printed as #P"LOGICAL:dir;subdir;name.data".

It should be printed using the logical pathname syntax, that is, in
upper case, because:

1- it is a logical pathname,

2- its printed form should be readable as the 'same' logical pathname,
   that is, a pathname with the same components,

3- #P gives the string to parse-namestring, without addionnal
  argument, therefore :host is nil, and in this case, for the string
  to be parsed as a logical pathname, it needs to have the logical
  pathname syntax, which takes only upper case letters.

4- when reading back this lowercase form, we don't read the same
   pathname as originally returned by the make-pathname form.



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

Comment By: Bruno Haible (haible)
Date: 2010-11-17 02:39

Message:
The behaviour of :case :common is specified in CLHS section 19.2.2.1.2.2
http://www.lispworks.com/documentation/HyperSpec/Body/19_bbabb.htm
For clisp, the "filesystem's customary case" is lowercase, both on Unix
and on Windows.

The section you cite, 19.3.1.1.7, doesn't apply for two reasons:
1) It applies only to logical pathnames. But
  (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common)
yields an ordinary pathname in clisp. If you want a logical pathname, use
the LOGICAL-PATHNAME function.
2) It applies to the parsing of namestrings for logical pathnames
that contain lowercase letters.
In your example (make-pathname :host "TEST" :name "FILE" :type "DATA"
:case :common)
all of these are upper case, therefore the contents of 19.3.1.1.7 doesn't
apply.


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

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

[ clisp-Bugs-3110367 ] :case :common for logical pathnames.

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

Bugs item #3110367, was opened at 2010-11-17 00:33
Message generated for change (Comment added) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3110367&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: Rejected
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: :case :common for logical pathnames.

Initial Comment:
When creating a logical pathname with make-pathname, :case :common, the pathname components are downcased.  

I would argue that the customary case for logical pathnames is upper case, since:

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring

    When parsing words and wildcard-words, lowercase letters are translated to uppercase. 

I'd expect (string= (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
                               (pathname-name #P"TEST:FILE.DATA"))
and of course (string= "FILE" (pathname-name #P"TEST:FILE.DATA"))
and similarly for the other pathname components.

[pjb@kuiper :0.0 ~]$ clisp -norc -ansi
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> (setf (logical-pathname-translations "TEST") nil)
NIL
[2]> (setf (logical-pathname-translations "TEST") (quote ((#P"TEST:**;*.*" "/tmp/**/*.*")
                                                     (#P"TEST:**;*" "/tmp/**/*"))))
((#P"TEST:**;*.*" "/tmp/**/*.*") (#P"TEST:**;*" "/tmp/**/*"))
[3]> (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
"file"
[4]> (pathname-name #P"TEST:FILE.DATA")
"FILE"
[5]> 


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

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-17 09:04

Message:
- I agree, I was wrong, 19.3.1.1.7 doesn't apply.

- make-pathname creates a logical pathname when the :host parameter is
  a logical host, in clisp, as in any conforming implementation.

- I was also wrong with:
  (pathname-name (make-pathname :host "TEST" :name  "FILE" :type "DATA"
:case :common))
  it should indeed return "file"; this is correctly implemented in clisp.

- but the other form, (pathname-name #P"TEST:FILE.DATA") should return
  "file", not "FILE", because by default the :case parameter of
  pathname-name is :local, and "19.2.2.1.2.2 Common Case in Pathname
  Components" mentions that round trip should be information
  preserving (including case for local pathnames).


Actually there are other problems.  In an implementation where the
customary case is lower case, the pathname accessors cannot return the
same case with and without :case :common, but this is what clisp does:


CL-USER> (print-pathname (make-pathname :host "LOGICAL" :device
:unspecific :directory '(:absolute "DIR" "SUBDIR") :name  "NAME" :type
"DATA" :version nil :case :common))

LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.data"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "data"
Version   : NIL
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "data"
Version   : NIL
--------------------  
#P"LOGICAL:dir;subdir;name.data"
CL-USER> (print-pathname #P"LOGICAL:dir;subdir;name.data")

LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.DATA"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  
#P"LOGICAL:DIR;SUBDIR;NAME.DATA"
CL-USER> (print-pathname #P"LOGICAL:DIR;SUBDIR;NAME.DATA")

LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.DATA"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "DATA"
Version   : NIL
--------------------  
#P"LOGICAL:DIR;SUBDIR;NAME.DATA"



There is also the problem that the result of:
 (make-pathname :host "LOGICAL" :device :unspecific :directory '(:absolute
"DIR" "SUBDIR") :name  "NAME" :type "DATA" :version nil :case :common)
is printed as #P"LOGICAL:dir;subdir;name.data".

It should be printed using the logical pathname syntax, that is, in
upper case, because:

1- it is a logical pathname,

2- its printed form should be readable as the 'same' logical pathname,
   that is, a pathname with the same components,

3- #P gives the string to parse-namestring, without addionnal
  argument, therefore :host is nil, and in this case, for the string
  to be parsed as a logical pathname, it needs to have the logical
  pathname syntax, which takes only upper case letters.

4- when reading back this lowercase form, we don't read the same
   pathname as originally returned by the make-pathname form.



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

Comment By: Bruno Haible (haible)
Date: 2010-11-17 02:39

Message:
The behaviour of :case :common is specified in CLHS section 19.2.2.1.2.2
http://www.lispworks.com/documentation/HyperSpec/Body/19_bbabb.htm
For clisp, the "filesystem's customary case" is lowercase, both on Unix
and on Windows.

The section you cite, 19.3.1.1.7, doesn't apply for two reasons:
1) It applies only to logical pathnames. But
  (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common)
yields an ordinary pathname in clisp. If you want a logical pathname, use
the LOGICAL-PATHNAME function.
2) It applies to the parsing of namestrings for logical pathnames
that contain lowercase letters.
In your example (make-pathname :host "TEST" :name "FILE" :type "DATA"
:case :common)
all of these are upper case, therefore the contents of 19.3.1.1.7 doesn't
apply.


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

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

[ clisp-Bugs-3110367 ] :case :common for logical pathnames.

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

Bugs item #3110367, was opened at 2010-11-17 00:33
Message generated for change (Comment added) made by haible
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3110367&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: Rejected
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: :case :common for logical pathnames.

Initial Comment:
When creating a logical pathname with make-pathname, :case :common, the pathname components are downcased.  

I would argue that the customary case for logical pathnames is upper case, since:

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring

    When parsing words and wildcard-words, lowercase letters are translated to uppercase. 

I'd expect (string= (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
                               (pathname-name #P"TEST:FILE.DATA"))
and of course (string= "FILE" (pathname-name #P"TEST:FILE.DATA"))
and similarly for the other pathname components.

[pjb@kuiper :0.0 ~]$ clisp -norc -ansi
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> (setf (logical-pathname-translations "TEST") nil)
NIL
[2]> (setf (logical-pathname-translations "TEST") (quote ((#P"TEST:**;*.*" "/tmp/**/*.*")
                                                     (#P"TEST:**;*" "/tmp/**/*"))))
((#P"TEST:**;*.*" "/tmp/**/*.*") (#P"TEST:**;*" "/tmp/**/*"))
[3]> (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
"file"
[4]> (pathname-name #P"TEST:FILE.DATA")
"FILE"
[5]> 


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

>Comment By: Bruno Haible (haible)
Date: 2010-11-17 02:39

Message:
The behaviour of :case :common is specified in CLHS section 19.2.2.1.2.2
http://www.lispworks.com/documentation/HyperSpec/Body/19_bbabb.htm
For clisp, the "filesystem's customary case" is lowercase, both on Unix
and on Windows.

The section you cite, 19.3.1.1.7, doesn't apply for two reasons:
1) It applies only to logical pathnames. But
  (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common)
yields an ordinary pathname in clisp. If you want a logical pathname, use
the LOGICAL-PATHNAME function.
2) It applies to the parsing of namestrings for logical pathnames
that contain lowercase letters.
In your example (make-pathname :host "TEST" :name "FILE" :type "DATA"
:case :common)
all of these are upper case, therefore the contents of 19.3.1.1.7 doesn't
apply.


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

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

Re: 1e15 notation

[Julian S. <ju...@ci...>]

On Tue, Nov 16, 2010 at 7:47 PM, Andrew Pennebaker
<and...@gm...> wrote:
> (format nil "~r" 1e15) => "nine hundred and ninety-nine trillion, nine
> hundred and ninety-nine billion, nine hundred and ninety-five million, nine
> hundred and four thousand"

Try (format nil "~r" 1L15) or set *read-default-float-format*.
 (see http://www.lispworks.com/documentation/HyperSpec/Body/v_rd_def.htm)

-- 
Julian Squires

1e15 notation

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

I was playing around with FORMAT when I noticed that some number literals
are mishandled.

(format nil "~r" 1e12) => "one trillion"

1e12 => 1.0E12

That works, but not this:

(format nil "~r" 1e15) => "nine hundred and ninety-nine trillion, nine
hundred and ninety-nine billion, nine hundred and ninety-five million, nine
hundred and four thousand"

1e15 => 1.0E15

Until that works, I'll stick with:

(format nil "~r" 1000000000000000) => "one quadrillion"

Cheers,
Andrew Pennebaker

[ clisp-Bugs-3110367 ] :case :common for logical pathnames.

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

Bugs item #3110367, was opened at 2010-11-17 00:33
Message generated for change (Tracker Item Submitted) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3110367&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: :case :common for logical pathnames.

Initial Comment:
When creating a logical pathname with make-pathname, :case :common, the pathname components are downcased.  

I would argue that the customary case for logical pathnames is upper case, since:

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring

    When parsing words and wildcard-words, lowercase letters are translated to uppercase. 

I'd expect (string= (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
                               (pathname-name #P"TEST:FILE.DATA"))
and of course (string= "FILE" (pathname-name #P"TEST:FILE.DATA"))
and similarly for the other pathname components.

[pjb@kuiper :0.0 ~]$ clisp -norc -ansi
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> (setf (logical-pathname-translations "TEST") nil)
NIL
[2]> (setf (logical-pathname-translations "TEST") (quote ((#P"TEST:**;*.*" "/tmp/**/*.*")
                                                     (#P"TEST:**;*" "/tmp/**/*"))))
((#P"TEST:**;*.*" "/tmp/**/*.*") (#P"TEST:**;*" "/tmp/**/*"))
[3]> (pathname-name (make-pathname :host "TEST" :name "FILE" :type "DATA" :case :common))
"file"
[4]> (pathname-name #P"TEST:FILE.DATA")
"FILE"
[5]> 


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

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

Re: gensym, gentemp with threads

[<don...@is...>]

I've not tried to test the recent changes specifically, but at least I
can report that my nightly ap5 builds seem unaffected.  They use
gentemp and gensym a lot.  But they don't use more than one thread.
The do run in both #+MT and #-MT versions though.

Vladimir Tzankov writes:
 > On 11/1/10, Sam Steingold <sd...@gn...> wrote:
 > > I think using a mutex in getsym & gentems (and not binding
 > > *gensym-counter* in every thread) is a good idea.
 > > these functions are usually called in macroexpansion, so they are not
 > > too speed-critical and not particularly prone to deadlocks.
 > 
 > I've re-implemented and committed gensym and gentemp. Please review them.

Re: gensym, gentemp with threads

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

On 11/1/10, Sam Steingold <sd...@gn...> wrote:
> I think using a mutex in getsym & gentems (and not binding
> *gensym-counter* in every thread) is a good idea.
> these functions are usually called in macroexpansion, so they are not
> too speed-critical and not particularly prone to deadlocks.

I've re-implemented and committed gensym and gentemp. Please review them.

Vladimir

Re: clisp-2.49 fix for FreeBSD

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

> From: "Joseph S. Atkinson" <js...@Fr...>
>
> --- ./src/makemake.in.orig	2010-11-08 19:22:10.000000000 -0500
> +++ ./src/makemake.in	2010-11-08 19:22:50.000000000 -0500
> @@ -1424,7 +1424,7 @@
>      freebsd2* | netbsd* | openbsd*)
>        XCC_CREATESHARED='ld -Bshareable -o $lib $libs'
>        ;;
> -    freebsd3* | gnu* | linux* | cygwin* | mingw* | k*bsd* | dragonfly*)
> +    freebsd* | gnu* | linux* | cygwin* | mingw* | k*bsd* | dragonfly*)
>        XCC_CREATESHARED='${CC} ${CFLAGS} ${CLFLAGS} -shared -o $lib $libs'
>        ;;
>      hpux9* | hpux10*)

this patches dead (removed) code.
we now use libtool to set XCC_CREATESHARED:

if [ "${with_dynamic_modules}" != no ]; then # not on msvc
  # Support for dynamic loading.
  eval "`./libtool --tag=CC --config | grep '^pic_flag='`"
  eval XCC_PICFLAG=\"${pic_flag}\"
  eval "`./libtool --tag=CC --config | grep '^archive_cmds='`"
  CC='${CC}' libobjs='$libs' deplibs='${CLFLAGS}' compiler_flags='${CFLAGS}' \
    soname='$dll' lib='$lib' output_objdir='$dyndir' \
    eval XCC_CREATESHARED=\"${archive_cmds}\"
  test "${verbose}" = true -o "${verbose}" = yes && \
    echo "XCC_CREATESHARED = ${XCC_CREATESHARED}" >&2
fi

Joseph, could you please try cvs head?
thanks!

(Next time please use sf.net mailing lists or trackers for support
instead of mailing individual developers.
Please see <http://clisp.cons.org/impnotes/faq.html#help> for details.)

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid)
http://www.PetitionOnline.com/tap12009/ http://jihadwatch.org
http://palestinefacts.org http://www.memritv.org http://camera.org
will write code that writes code that writes code for food

[ clisp-Bugs-3105348 ] Internal error: statement in file "rawsock.c", line 1362 has

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

Bugs item #3105348, was opened at 2010-11-08 16:35
Message generated for change (Comment added) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3105348&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: lisp error
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Sam Steingold (sds)
Summary: Internal error: statement in file "rawsock.c", line 1362 has

Initial Comment:
*** - Internal error: statement in file "rawsock.c", line 1362 has been reached!!

while executing: 

(let ((socket (rawsock:socket :inet :dgram 0)))
 (setf (rawsock:socket-option socket LINUX:O_NONBLOCK) t))



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

>Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-08 18:58

Message:
Ok.  I didn't realize it was fcntl.  Sorry for the noise.

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

Comment By: Sam Steingold (sds)
Date: 2010-11-08 18:06

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: 2010-11-08 18:01

Message:
actually, it is setfable!
(posix:stream-options socket :NONBLOCK t)

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

Comment By: Sam Steingold (sds)
Date: 2010-11-08 17:26

Message:
why do you expect setsockopt to accept O_NONBLOCK?
this is a fcntl option, so you want to use posix:stream-options
http://clisp.sourceforge.net/impnotes/syscalls.html#fcntl
alas, it it not setfable yet

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

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-08 16:45

Message:
Notice that O_NONBLOCK seems to be a valid option for sockets, since it's
mentionned in 
http://www.opengroup.org/onlinepubs/009695399/functions/recvfrom.html

If no messages are available at the socket and O_NONBLOCK is not set on
the socket's file descriptor, recvfrom() shall block until a message
arrives. If no messages are available at the socket and O_NONBLOCK is set
on the socket's file descriptor, recvfrom() shall fail and set errno to
[EAGAIN] or [EWOULDBLOCK].


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

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

[ clisp-Bugs-3105348 ] Internal error: statement in file "rawsock.c", line 1362 has

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

Bugs item #3105348, was opened at 2010-11-08 10:35
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3105348&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: lisp error
>Status: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Sam Steingold (sds)
Summary: Internal error: statement in file "rawsock.c", line 1362 has

Initial Comment:
*** - Internal error: statement in file "rawsock.c", line 1362 has been reached!!

while executing: 

(let ((socket (rawsock:socket :inet :dgram 0)))
 (setf (rawsock:socket-option socket LINUX:O_NONBLOCK) t))



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

Comment By: Sam Steingold (sds)
Date: 2010-11-08 12:06

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: 2010-11-08 12:01

Message:
actually, it is setfable!
(posix:stream-options socket :NONBLOCK t)

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

Comment By: Sam Steingold (sds)
Date: 2010-11-08 11:26

Message:
why do you expect setsockopt to accept O_NONBLOCK?
this is a fcntl option, so you want to use posix:stream-options
http://clisp.sourceforge.net/impnotes/syscalls.html#fcntl
alas, it it not setfable yet

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

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-08 10:45

Message:
Notice that O_NONBLOCK seems to be a valid option for sockets, since it's
mentionned in 
http://www.opengroup.org/onlinepubs/009695399/functions/recvfrom.html

If no messages are available at the socket and O_NONBLOCK is not set on
the socket's file descriptor, recvfrom() shall block until a message
arrives. If no messages are available at the socket and O_NONBLOCK is set
on the socket's file descriptor, recvfrom() shall fail and set errno to
[EAGAIN] or [EWOULDBLOCK].


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

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

[ clisp-Bugs-3105348 ] Internal error: statement in file "rawsock.c", line 1362 has

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

Bugs item #3105348, was opened at 2010-11-08 10:35
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3105348&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: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Sam Steingold (sds)
Summary: Internal error: statement in file "rawsock.c", line 1362 has

Initial Comment:
*** - Internal error: statement in file "rawsock.c", line 1362 has been reached!!

while executing: 

(let ((socket (rawsock:socket :inet :dgram 0)))
 (setf (rawsock:socket-option socket LINUX:O_NONBLOCK) t))



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

>Comment By: Sam Steingold (sds)
Date: 2010-11-08 12:01

Message:
actually, it is setfable!
(posix:stream-options socket :NONBLOCK t)

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

Comment By: Sam Steingold (sds)
Date: 2010-11-08 11:26

Message:
why do you expect setsockopt to accept O_NONBLOCK?
this is a fcntl option, so you want to use posix:stream-options
http://clisp.sourceforge.net/impnotes/syscalls.html#fcntl
alas, it it not setfable yet

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

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-08 10:45

Message:
Notice that O_NONBLOCK seems to be a valid option for sockets, since it's
mentionned in 
http://www.opengroup.org/onlinepubs/009695399/functions/recvfrom.html

If no messages are available at the socket and O_NONBLOCK is not set on
the socket's file descriptor, recvfrom() shall block until a message
arrives. If no messages are available at the socket and O_NONBLOCK is set
on the socket's file descriptor, recvfrom() shall fail and set errno to
[EAGAIN] or [EWOULDBLOCK].


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

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

[ clisp-Bugs-3105348 ] Internal error: statement in file "rawsock.c", line 1362 has

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

Bugs item #3105348, was opened at 2010-11-08 10:35
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3105348&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: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
>Assigned to: Sam Steingold (sds)
Summary: Internal error: statement in file "rawsock.c", line 1362 has

Initial Comment:
*** - Internal error: statement in file "rawsock.c", line 1362 has been reached!!

while executing: 

(let ((socket (rawsock:socket :inet :dgram 0)))
 (setf (rawsock:socket-option socket LINUX:O_NONBLOCK) t))



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

>Comment By: Sam Steingold (sds)
Date: 2010-11-08 11:26

Message:
why do you expect setsockopt to accept O_NONBLOCK?
this is a fcntl option, so you want to use posix:stream-options
http://clisp.sourceforge.net/impnotes/syscalls.html#fcntl
alas, it it not setfable yet

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

Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-08 10:45

Message:
Notice that O_NONBLOCK seems to be a valid option for sockets, since it's
mentionned in 
http://www.opengroup.org/onlinepubs/009695399/functions/recvfrom.html

If no messages are available at the socket and O_NONBLOCK is not set on
the socket's file descriptor, recvfrom() shall block until a message
arrives. If no messages are available at the socket and O_NONBLOCK is set
on the socket's file descriptor, recvfrom() shall fail and set errno to
[EAGAIN] or [EWOULDBLOCK].


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

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

[ clisp-Bugs-3105348 ] Internal error: statement in file "rawsock.c", line 1362 has

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

Bugs item #3105348, was opened at 2010-11-08 16:35
Message generated for change (Comment added) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3105348&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: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: Internal error: statement in file "rawsock.c", line 1362 has

Initial Comment:
*** - Internal error: statement in file "rawsock.c", line 1362 has been reached!!

while executing: 

(let ((socket (rawsock:socket :inet :dgram 0)))
 (setf (rawsock:socket-option socket LINUX:O_NONBLOCK) t))



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

>Comment By: Pascal J. Bourguignon (informatimago)
Date: 2010-11-08 16:45

Message:
Notice that O_NONBLOCK seems to be a valid option for sockets, since it's
mentionned in 
http://www.opengroup.org/onlinepubs/009695399/functions/recvfrom.html

If no messages are available at the socket and O_NONBLOCK is not set on
the socket's file descriptor, recvfrom() shall block until a message
arrives. If no messages are available at the socket and O_NONBLOCK is set
on the socket's file descriptor, recvfrom() shall fail and set errno to
[EAGAIN] or [EWOULDBLOCK].


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

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

[ clisp-Bugs-3105348 ] Internal error: statement in file "rawsock.c", line 1362 has

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

Bugs item #3105348, was opened at 2010-11-08 16:35
Message generated for change (Tracker Item Submitted) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3105348&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: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: Internal error: statement in file "rawsock.c", line 1362 has

Initial Comment:
*** - Internal error: statement in file "rawsock.c", line 1362 has been reached!!

while executing: 

(let ((socket (rawsock:socket :inet :dgram 0)))
 (setf (rawsock:socket-option socket LINUX:O_NONBLOCK) t))



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

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

[ clisp-Bugs-3104464 ] Additional Installation Option for OS X

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

Bugs item #3104464, was opened at 2010-11-06 23:51
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3104464&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: web pages
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andrew de Andrade (malandrew)
>Assigned to: Sam Steingold (sds)
Summary: Additional Installation Option for OS X

Initial Comment:
On the CLISP homepage there are instructions on how to install CLISP using MacPorts and Fink, however there is now another package manager option that is quite good and gaining popularity. It is Homebrew.

For those with Homebrew installed, they can install CLISP by typing the following at the terminal command prompt:
$ brew install lisp

http://mxcl.github.com/homebrew/
https://github.com/mxcl/homebrew


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

>Comment By: Sam Steingold (sds)
Date: 2010-11-07 01:33

Message:
thanks

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

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

[ clisp-Bugs-3104464 ] Additional Installation Option for OS X

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

Bugs item #3104464, was opened at 2010-11-06 23:51
Message generated for change (Tracker Item Submitted) made by malandrew
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3104464&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andrew de Andrade (malandrew)
Assigned to: Bruno Haible (haible)
Summary: Additional Installation Option for OS X

Initial Comment:
On the CLISP homepage there are instructions on how to install CLISP using MacPorts and Fink, however there is now another package manager option that is quite good and gaining popularity. It is Homebrew.

For those with Homebrew installed, they can install CLISP by typing the following at the terminal command prompt:
$ brew install lisp

http://mxcl.github.com/homebrew/
https://github.com/mxcl/homebrew


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

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

Re: exemption-wait question

[<don...@is...>]

Vladimir Tzankov writes:
 > On 11/3/10, Don Cohen <don...@is...> wrote:
 > > I am running this from emacs, but not slime.  I don't even have an
 > > inferior lisp buffer.
 > > Might this be related to the fact that the code is binding all the
 > > normal streams to the socket?
 > 
 > I guess it is related.
 > In emacs/slime - if I do:
 > (let ((s *standard-output*))
 >   (loop for x in (mt:LIST-THREADS) do
 >         (format t "-- ~a --~&" x)
 >         (mt:thread-interrupt x :function
 >           (lambda () (let ((*standard-output* s)) (ext:show-stack 1 3))))))
 > all output goes into *slime-repl* buffer.
 > 
 > In your example:
 > > (loop for x in (mt:LIST-THREADS) do
 > >  (format t "-- ~a --~&" x)
 > >  (mt:thread-interrupt x :function
 > >  (lambda () (let ((*debug-io* *dbg*))(ext:show-stack 1 3)))))
 > > where *dbg* is the value of *debug-io* in the debugging thread.
 > *dbg* is special variable I guess?
I guess so - it's created by doing 
(setf *dbg* *standard-output*)
Isn't that supposed to make it a global (which is also special) var?
in the thread about to do the loop.

 > If so - in each thread being interrupted you bind *debug-io* to per
 > thread binding of *dbg* (if any) or to its global value BUT NOT to
 > *dbg* value in debugging thread.
If that were the case then those interrupts should be getting errors.
That should put them into the debugger (if not in an error catcher).

Re: exemption-wait question

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

On 11/3/10, Don Cohen <don...@is...> wrote:
> I am running this from emacs, but not slime.  I don't even have an
> inferior lisp buffer.
> Might this be related to the fact that the code is binding all the
> normal streams to the socket?

I guess it is related.
In emacs/slime - if I do:
(let ((s *standard-output*))
  (loop for x in (mt:LIST-THREADS) do
        (format t "-- ~a --~&" x)
        (mt:thread-interrupt x :function
          (lambda () (let ((*standard-output* s)) (ext:show-stack 1 3))))))
all output goes into *slime-repl* buffer.

In your example:
> (loop for x in (mt:LIST-THREADS) do
>  (format t "-- ~a --~&" x)
>  (mt:thread-interrupt x :function
>  (lambda () (let ((*debug-io* *dbg*))(ext:show-stack 1 3)))))
> where *dbg* is the value of *debug-io* in the debugging thread.
*dbg* is special variable I guess?
If so - in each thread being interrupted you bind *debug-io* to per
thread binding of *dbg* (if any) or to its global value BUT NOT to
*dbg* value in debugging thread.

Re: exemption-wait question

[<don...@is...>]

Vladimir Tzankov writes:
 > On 11/3/10, Don Cohen <don...@is...> wrote:
 > > Sam Steingold writes:
 > >  > > > (loop for x in (mt:LIST-THREADS) do
 > >  > > >  (format t "-- ~a --~&" x)
 > >  > > >  (mt:thread-interrupt x :function
 > >  > > >  (lambda () (let ((*debug-io* *dbg*))(ext:show-stack 1 3)))))
 > >  > > > where *dbg* is the value of *debug-io* in the debugging thread.
 > >  > > This still doesn't work.
 > >  > > How can I use one thread to see a stack trace for another one?
 > >  >
 > >  > show-stack prints to *standard-output*
 > > That was my original attempt.
 > > If I change debug-io above to standard-output I get the same thing.
 > > The thread where I do the loop shows the format for all threads but
 > > the backtrace only for itself.
 > 
 > I observe this when I run the above in emacs/slime. The output for
 > all threads (besides "self" one) goes into *inferior-lisp* buffer.
 > When the above is run in the console all threads dump their stack
 > as expected.

I am running this from emacs, but not slime.  I don't even have an
inferior lisp buffer.
Might this be related to the fact that the code is binding all the
normal streams to the socket?

(defun debug-server() 
  (let ((server (socket:socket-server 8215 :interface "localhost"))) 
       (unwind-protect 
           (loop 
            (let ((socket (socket:socket-accept server :buffered nil))) 
              (show-socket-addrs socket) 
              (let ((tlist (loop for x in (mt:list-threads) as i from 1 
                             when (mt:thread-active-p x) collect (cons i x))) 
                    ans) 
                (print tlist socket) 
                (print "debug which thread (enter the number)" socket) 
                (when (setf ans (cdr (assoc (read socket) tlist))) 
                  (mt:thread-interrupt 
                   ans 
                   :function 
                   (lambda nil 
                     (let ((*standard-input* socket) 
                           (*standard-output* socket) 
                           (*debug-io* socket) 
                           (*error-output* socket) 
                           (*trace-output* socket) 
                           (*query-io* socket)) 
                       (unwind-protect 
                           (break "debug") 
                         (close socket))))))))) 
         (socket:socket-server-close server)))) 
 
(mt:make-thread #'debug-server :name "debug-server") 


I then connect by running telnet in a shell in emacs (in screen in
xterm in ssh in ...)

Re: exemption-wait question

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

On 11/3/10, Don Cohen <don...@is...> wrote:
> Sam Steingold writes:
>  > > > (loop for x in (mt:LIST-THREADS) do
>  > > >  (format t "-- ~a --~&" x)
>  > > >  (mt:thread-interrupt x :function
>  > > >  (lambda () (let ((*debug-io* *dbg*))(ext:show-stack 1 3)))))
>  > > > where *dbg* is the value of *debug-io* in the debugging thread.
>  > > This still doesn't work.
>  > > How can I use one thread to see a stack trace for another one?
>  >
>  > show-stack prints to *standard-output*
> That was my original attempt.
> If I change debug-io above to standard-output I get the same thing.
> The thread where I do the loop shows the format for all threads but
> the backtrace only for itself.

I observe this when I run the above in emacs/slime. The output for all
threads (besides "self" one) goes into *inferior-lisp* buffer.
When the above is run in the console  all threads dump their stack as expected.