Custom Query (1030 matches)

Hi,

I believe there is a new bug on CCL related to reader tables. In particular it appears that doing a copy-readtable no longer produces a deep enough copy. The following small test code illustrates the problem:

(defparameter *my-readtable* (copy-readtable))

(defun my-sharp-dot-read (stream char n)
  (declare (ignore char n stream))
  (format t "My sharp-dot-read invoked!~%"))

(let ((*readtable* *my-readtable*))
  (set-dispatch-macro-character #\# #\. 'my-sharp-dot-read))

(format t "Are they the same?  ~a~%"
        (eq (get-dispatch-macro-character #\# #\. *readtable*)
            (get-dispatch-macro-character #\# #\. *my-readtable*)))

I believe this should print:

    Are they the same?  NIL

And indeed this is what gets printed on a recent copy of SBCL and also on the slightly older version of CCL: CCL 1.11-dev-r16394M-trunk (LinuxX8664).

However, the bleeding-edge CCL, Version 1.11-dev-r16446M-trunk (LinuxX8664), instead prints:

    Are they the same?  T

I can see from the commit log that there has been some recent work on reader macros, so this is perhaps related to those recent changes.

Thanks!

Jared

Hi,

This is a very minor bug, but we ran into it in the context of a much larger system and it took awhile to figure out what was going on. This is on CCL 1.11-dev-r16394M-trunk on a Linux 2.6.32-431.el6.x86_64 system.

Setup: Create a file and several levels of symlinks to it. The following will work for this in bash:

    echo "Hello World" > 0
    for ((i=0;i < 30;i=i+1)) do ln -s $i $((i+1)) ; done

Once we get past enough symlinks, we find that CCL reports that the files do not exist:

   > (probe-file "8")
   #P"/home/users/jared/ccl-symlinks/0"
   ...
   > (probe-file "20")
   #P"/home/users/jared/ccl-symlinks/0"
   > (probe-file "21")
   NIL    ;; Bug?  Expected #P"/home/users/jared/ccl-symlinks/0"
   > (probe-file "22")
   NIL    ;; Bug?  Expected #P"/home/users/jared/ccl-symlinks/0"

We also run into problems when trying to open these files. For instance:

    (defun my-read (filename)
      (with-open-file (stream filename :direction :input)
        (read-line stream)))

    > (my-read "8")
    "Hello World"
    NIL
    > (my-read "20")
    "Hello World"
    NIL
    (my-read "21")  ;; Bug?  The file does exist...
    > Error: No such file or directory : "21"
    > While executing: CCL::MAKE-FILE-STREAM, in process listener(1).
    > Type :POP to abort, :R for a list of available restarts.
    > Type :? for other options.

From poking around, it seems like this may be due to the way that #_REALPATH is used in the implementation of %REALPATH, which is used by PROBE-FILE. It looks like the C realpath() function can return many kinds of error conditions, such as ELOOP, which don't necessarily mean that the file doesn't exist, but that the implementation of probe-file essentially just checks its return value without paying attention to the ERRNO.

FWIW, it seems that SBCL can PROBE-FILE all of these files without a problem, but it too fails to open files from "9" and above. Fortunately it provides a good error message instead of saying that the file does not exist:

    error opening #P"/home/users/jared/ccl-symlinks/9":
      Too many levels of symbolic links

Anyway this is all minor, but it would be nice if probe-file would either report that the file does indeed exist or give a "too many symlinks" error, and similarly it would be nice if opening the file either worked or produced a "too many symlinks" error instead of saying the file doesn't exist.

Thanks!

Jared

Consider the following code, which is a simplified version of stuff that can be found in CL-Yacc:

(defstruct item x)
(defstruct (sub-item (:include item) (:conc-name item-)) y)

The ANSI CL spec explicitly states that this is allowed, in the description of :CONC-NAME in the description of DEFSTRUCT. However, CCL generates a warning:

;Compiler warnings for "/home/pps/jch/struct-test.lisp" :
;   In an anonymous lambda form at position 18: Duplicate definitions of ITEM-X, in this file

It would appear that CCL generates correct code, but I believe that this is by accident.