{5} Assigned, Active Tickets by Owner (Full Description) (33 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

gb (24 matches)

Ticket Summary Component Milestone Type Created
#101 mmap failures sometimes ignored Runtime (threads, GC) defect Sep 1, 2007

On some platforms (depending on OS kernel settings that control overcommit policy), attempts to grow the heap after GC fail (the mmap() call fails.) The lisp kernel ignores the return value, and wackiness ensues.

#145 Handling exceptions (lisp errors, NSExceptions ...) in the event thread IDE Cocoa IDE v1 defect Oct 26, 2007

There are probably several problems with the mechanism(s) used to handle/report exceptions that occur on the Cocoa event thread.

(It is likely that we'd eventually want higher-level debugging facilities - a window based backtrace dialog, interaction with the inspector and other IDE facilities, etc. - to be available when an error occurs during event processing; that's a separate set of issues, and it's likely that anything that we eventually do to address them depend on the issues described here.)

It is necessary that exceptions on the event thread:

  • do not block the event process. I've seen log output that shows that the event thread tries to enter a break loop. When the IDE is run standalone, it fills the log file prompting for input from /dev/null.
  • unwind the stack in a way that gives both lisp exception handling and unwind-protect cleanup code and any ObjC runtime handlers/cleanups a chance to run. The latter means different things in 32-bit ObjC runtimes than in the 64-bit case. In both cases, it means that lisp errors that occur during ObjC callbacks have to be handled by forcing the callback to raise an NSException on return and by treating NSExceptions that occur during lisp functions that call ObjC methods as lisp errors.
  • handle any recursive errors (while printing backtrace info or elsewhere) with the same concerns
  • provide as much debugging info as practical (this is currently just stack traces written to standard output.)

I think that we've seen evidence of all of these things failing in some circumstances, sometimes in combination.

We may want to split this ticket into several smaller tickets, but I think that it'd be good to isolate "problems related to exception handling" from things like "backtrace in a TTY is hard to read".

#384 Linux-files performance regression Performance defect Dec 3, 2008
(defun test-open (n)
  (dotimes (i n)
    (with-open-file (f "tmp.dat" :direction :output :if-exists :supersede)
      (write-string "(ho hum)" f))
    (with-open-file (f "tmp.dat")
      (read-char f))))

I ran this test function multiple times in working-0711 branch versions r11088 and r11089 and 11089 is consistently slower on average, e.g.

Form (TEST-OPEN 250) in Version 1.2-r11089-working-0711  (LinuxX8664)
    Elapsed        User      System          GC        Alloc   Minor   Major   Swaps
    257,019      95,986      36,994       1,319    2,896,000       0       0       0
    251,092      88,986      41,994       2,206    2,896,000       0       0       0
    134,011      72,989      54,992       1,145    2,896,000      32       0       0
    125,924      78,988      46,993       1,147    2,896,000       0       0       0
    130,112      79,988      48,992       2,295    2,896,000       0       0       0
    128,157      78,988      47,993       1,146    2,896,000       0       0       0
    216,794      77,988      50,992       1,147    2,896,000       0       0       0
    277,051      78,988      51,992       2,292    2,896,000       0       0       0
    255,427      77,988      51,992       1,158    2,896,000       0       0       0
    267,159      85,987      44,993       1,142    2,896,000       0       0       0
    253,114      90,986      39,994       1,152    2,896,000       0       0       0
    274,699      80,988      49,993       2,272    2,896,000       0       0       0
    163,449      80,988      46,993       1,158    2,896,000       0       0       0
    127,657      81,987      45,993       1,146    2,896,000       0       0       0
    128,554      81,988      46,992       2,305    2,896,000       0       0       0
    127,557      77,988      47,993       1,148    2,896,000       0       0       0
    127,986      68,990      57,991       1,137    2,896,000       0       0       0
    129,109      73,988      54,992       2,285    2,896,000       0       0       0
    330,468      72,989      56,991       1,141    2,896,000       0       0       0
    298,654      84,987      43,994       1,155    2,896,000       0       0       0
    261,672      86,987      43,993       2,309    2,896,000       0       0       0
    266,398      80,988      48,992       1,136    2,896,000       0       0       0
    264,178      85,987      43,994       8,139    2,896,000       0       0       0
    265,669      85,987      45,993       2,256    2,896,000       0       0       0
    273,692      79,987      47,993       1,132    2,896,000       0       0       0
    142,433      71,990      54,991       1,154    2,896,000       0       0       0
    128,478      84,987      42,994       2,288    2,896,000       0       0       0
    126,702      90,986      34,994       1,144    2,896,000       0       0       0
    127,519      70,989      55,992       1,127    2,896,000       0       0       0
    128,295      75,988      50,992       1,134    2,896,000       0       0       0
    129,247      88,987      39,994       2,269    2,896,000       0       0       0
    134,055      82,987      44,993       1,139    2,896,000       0       0       0
    127,377      76,989      50,992       1,146    2,896,000       0       0       0
    197,773      81,987      46,993       3,014    2,896,000       0       0       0
    259,379      83,987      46,993       9,137    2,896,000       0       0       0
    265,179      86,987      44,993       1,122    2,896,000       0       0       0
    274,282      66,990      64,990       2,260    2,896,000       0       0       0
    268,083      89,986      39,994       1,135    2,896,000       0       0       0
    127,310      74,989      51,992       1,134    2,896,000       0       0       0
    127,727      73,989      52,992       2,303    2,896,000       0       0       0

Averages in Version 1.2-r11089-working-0711  (LinuxX8664)
    197,486      80,888      48,143       1,909    2,896,000       1       0       0
Form (TEST-OPEN 250) in Version 1.2-r11088-working-0711  (LinuxX8664)
    Elapsed        User      System          GC        Alloc   Minor   Major   Swaps
    129,391      75,988      52,992       1,391    2,896,000       0       0       0
    131,708      81,988      46,992       2,228    2,896,000       0       0       0
    131,589      84,987      46,993       1,118    2,896,000       0       0       0
    127,003      76,988      49,993       1,168    2,896,000       0       0       0
    135,771      83,987      50,992       2,317    2,896,000       0       0       0
    129,387      74,989      53,992       1,114    2,896,000       0       0       0
    133,612      84,987      46,993       1,112    2,896,000       0       0       0
    130,583      95,985      33,994       2,273    2,896,000       0       0       0
    129,508      71,989      57,992       1,112    2,896,000       0       0       0
    136,809      89,987      37,994       2,239    2,896,000       0       0       0
    130,573      88,986      41,994       1,160    2,896,000       0       0       0
    130,016      89,987      38,994       1,162    2,896,000       0       0       0
    129,686      90,986      38,994       2,214    2,896,000       0       0       0
    130,396      78,988      49,992       1,121    2,896,000       0       0       0
    128,936      80,987      47,993       1,119    2,896,000       0       0       0
    130,901      85,987      44,993       2,214    2,896,000       0       0       0
    136,721      92,986      36,994       1,105    2,896,000       0       0       0
    129,541      78,988      49,993       2,237    2,896,000       0       0       0
    131,080      79,988      48,992       1,105    2,896,000       0       0       0
    129,769      84,987      43,994       1,151    2,896,000       0       0       0
    129,451      85,987      42,993       2,224    2,896,000       0       0       0
    129,559      84,987      44,993       1,104    2,896,000       0       0       0
    128,017      82,987      44,993       1,105    2,896,000       0       0       0
    136,464      90,987      38,994       2,261    2,896,000       0       0       0
    128,916      81,987      46,993       1,110    2,896,000       0       0       0
    131,120      86,987      43,994       2,220    2,896,000       0       0       0
    127,700      73,989      53,991       1,163    2,896,000      32       0       0
    128,964      84,987      43,994       1,151    2,896,000       0       0       0
    128,882      78,988      49,992       1,195    2,896,000       0       0       0
    131,082      73,989      56,991       2,286    2,896,000       0       0       0
    128,631      86,986      41,994       1,155    2,896,000       0       0       0
    130,047      72,989      56,991       1,153    2,896,000       0       0       0
    130,789      89,987      40,994       2,356    2,896,000       0       0       0
    129,741      72,988      55,992       1,186    2,896,000       0       0       0
    128,347      93,986      34,994       1,155    2,896,000       0       0       0
    129,799      85,987      42,994       2,278    2,896,000       0       0       0
    174,095      75,989      54,991       1,146    2,896,000       0       0       0
    253,844      81,987      46,993       1,155    2,896,000       0       0       0
    275,874      79,988      53,992       1,133    2,896,000       0       0       0
    271,273      91,986      42,994       2,282    2,896,000       0       0       0

Averages in Version 1.2-r11088-working-0711  (LinuxX8664)
    141,889      83,337      46,568       1,537    2,896,000       1       0       0

Note that 11089 is comparable to 11088 in some runs, but it has a lot more cases where the elapsed time almost doubles, and that's what brings up its average.

Elsewhere, Greg has isolated the problem to the syscall changes in linux-files.lisp, and Gary has identified a possible suspect in C library glue; I haven't tried either against this test case yet, wanted to get it recorded first.

#423 Save and restore editor window positions IDE Cocoa IDE v1 defect Feb 9, 2009

Split off from ticket #197. Develop a system for remembering window placement. This should apply to editors, listeners, and the various tools. Also remember selection and scroll position. When you quit the IDE, remember which windows are open, and the next time the IDE is started, reopen the same tools and editors in the same positions.

This is default behavior. Add and document globals that allows this behavior to be turned off or modified. Also, make sure there's a way to set default positions for new editors and listeners.

#436 Failure expanding defsetf with &rest parameter ANSI CL Compliance defect Feb 21, 2009


(defsetf value (place &rest args) (new-value)

`(set-value ,new-value ,place ,@args))

Try it out with the following example declarations as a backdrop:

(defmethod value-at ((vec vector) &key at)

(aref vec at))

(defun value (x &rest args &key at)

(if (null at)


(apply #'value-at x args)))

(defparameter myvec (make-array 5))

next try:

(setf (value myvec :at 3) 15)

An explicit macroexpand produces a correct conversion:

(LET* ((#:G1204 MYVEC)

(#:G1203 :AT) (#:G1202 3))

(DECLARE (IGNORABLE #:G1204 #:G1203 #:G1202)) (MULTIPLE-VALUE-BIND (#:G1201) 15


(SET-VALUE #:G1201 #:PLACE . #:ARGS))

#:G1204 #:G1203 #:G1202)))

But in actual use at runtime, the attempted expansion produces an error:

value #:ARGS is not of the expected type LIST.

[Condition of type TYPE-ERROR]

As a workaround, I defined an alternative to defsetf:

(defun (setf value) (new-value place &rest args)

(apply #'set-value new-value place args))

While this may actually be a preferable way to do things, the fact that the defsetf expansion produces an error is still troubling.

  • DM

#460 Japanese input methods don't work IDE Cocoa IDE v? defect Apr 21, 2009

The Japanese input methods don't work in editor or listener windows. Other complex input methods (Chinese, etc.) are probably also affected.

#477 Hemlock confused by this newfangled Unicode thing IDE defect May 19, 2009

A lot of stuff in Hemlock (syntax tables, etc.) is confused by non-ASCII characters; this can cause searching and (lisp-)syntax-aware navigation to behave strangely.

#569 ccl:close-shared-library seems to loop forever? Foreign Function Interface defect Jul 24, 2009

I am on Ubuntu Karmic (prerelease) with Version 1.4-dev-r12385M-trunk (LinuxX8664)

Quite often it seems to be impossible to unload a shared library -- close-shared-library gets stuck -- maybe related to trying to unload a library that has symbols on which another library depends?

I just made this simple test case but did not investigate further. Let me know if you cannot reproduce it.

(defvar *libs* nil)

(loop for lib in '("libxcb.so.1" "libxcb-shm.so.0")

do (push (ccl:open-shared-library lib) *libs*))


(ccl:close-shared-library (first (reverse *libs*)) :completely t)

Does not return.

Interrupt from Emacs

[Condition of type SIMPLE-ERROR]


0: [CONTINUE] Continue from break. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [ABORT] Return to SLIME's top level. 3: [ABORT-BREAK] Reset this thread 4: [ABORT] Kill this thread



#822 run-program and save-application don't work together Runtime (threads, GC) defect Feb 27, 2011

When I start a program with run-program and then save an application via save-application, then the next time the application is run and quits, there is a memory fault.

My guess: Clozure registers started applications somewhere. After the image was saved and restarted, this list of course is empty. Solution: Forget all active processes during save-application.


*(7FEA07A39BB0) : 0 (LISP-THREAD-SUSPEND-COUNT #<LISP-THREAD listener [tcr @ #x7F5718C44570] #x3020005B538D>) 175
 (7FEA07A39C10) : 1 (PROCESS-ACTIVE-P #<A Foreign Pointer [stack-allocated] #x7F5718C44570>) 141
 (7FEA07A39C30) : 2 (PREPARE-TO-QUIT NIL) 429
 (7FEA07A39CF8) : 4 (FUNCALL #'#<(:INTERNAL QUIT)>) 509
 (7FEA07A39DE8) : 7 (FUNCALL #'#<CCL::XCMAIN> 17591790266418) 701
 (7FEA07A39E70) : 8 (%PASCAL-FUNCTIONS% 1 17591790266418) 397
*(7FEA07A39ED8) : 9 (%NANOSLEEP ???) NIL
 (7FEA07A39F28) : 10 (%NANOSLEEP 0 330000000) 589
 (7FEA07A39F90) : 11 (HOUSEKEEPING-LOOP) 501

#947 list navigation in Hemlock can enter infinite loop IDE defect Apr 1, 2012

Executing Hemlock's "Forward List" command (C-M-n) can enter an infinite loop if there's no list after point (and likewise for "Backward List" when there's no list before point.)

(This was reported on openmcl-devel early on 4/1/2012; the message isn't yet in the mailing list archive.)

The bug is in the %LIST-OFFSET macro: if DIRECTION-CHAR returns NIL, the expansion should return NIL rather than conflate NIL and :NEWLINE.

#1022 CCL does not start on win7 (32bit) Runtime (threads, GC) defect Oct 3, 2012

Since some windows updates on our site, ccl does not start anymore on windows7 32 bit.

If I start ccl inside a dos shell: wx86cl.exe

I get the following error message immediately.

Can't allocate required TLS indexes. First available index value was 32

Using the latest version of ccl from svn gives me the same error. We can reproduce this error on all win32 machines we can access.

I attached a list of windows updates installed on my pc since Sept 19. I know that I used CCL successfully that day the last time on windows. (win-patches.txt)

I leave the priority to normal, althought this is really a kind of blocker on win32.

#1088 lambda docstrings can't be read ANSI CL Compliance defect Jun 7, 2013

According to CLHS, the docstrings of lambdas are supposed to be successfully read. Unfortunately, Clozure CL doesn't. Is it on plan? Or just a feature?


(documentation (lambda () "a function which always returns NIL" nil) 'function)
;; => "a function which always returns NIL"


(documentation (lambda () "a function which always returns NIL" nil) 'function)
;; => NIL

Additional Information:

((lambda () "a strange behavior"))
;; => "a strange behavior"

Maybe this behavior should only be taken if there's only one form in it...

#1089 Cannot support non-ANSI (in this case, Chinese) path names ANSI CL Compliance defect Jun 7, 2013

Clozure CL seems to have a full support of Unicode. Unfortunately, the pathnames are still poor. These problems are all about pathnames so I believe there's something wrong with CCL's pathname code. Well, maybe not, but they are exactly bugs.

(I don't know which "Component" should this ticket go to, so I chose "ANSI CL Compliance".)

Problem 1: CCL can't start properly if CCL is placed in a directory whose (full) pathname contains Chinese characters

Results in this case:

> Error: The value NIL is not of the expected type (OR STRING PATHNAME STREAM).
> While executing: PATHNAME-DIRECTORY, in process Initial(0).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Skip (possibly crucial) startup function CCL::INIT-LOGICAL-DIRECTORIES.
> Type :? for other options.
1 > :pop
> Error: There is no package named "ASDF/FIND-SYSTEM" .
> While executing: CCL::%FASL-NVPACKAGE, in process listener(1).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Retry finding package with name "ASDF/FIND-SYSTEM".
> Type :? for other options.
1 > :pop
Welcome to Clozure Common Lisp Version 1.9-r15757  (LinuxX8664)!

Problem 2: Can't load a file whose (full) pathname contains Chinese characters

? (load "~/下載/hello.lisp")
> Error: File "~/下載/hello.lisp" does not exist.
> While executing: CCL::%LOAD, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > 

Okay, let's see what shell shows:

mike@laptop ~/下載> cat hello.lisp 
(format t "hello 世界~%")

Well... What's just happened? Let's see what will happen if hello.lisp isn't here

? (load "~/hello.lisp")
hello 世界

#1112 #[-+] reader macros don't nest correctly ANSI CL Compliance defect Sep 16, 2013

This function prints (C), (B), (B), (A) as tested under SBCL and CLISP on x86/darwin.

(defun test ()
  (print (read-from-string "#-x86 #-darwin (a) (b) (c)"))
  (print (read-from-string "#-x86 #+darwin (a) (b) (c)"))
  (print (read-from-string "#+x86 #-darwin (a) (b) (c)"))
  (print (read-from-string "#+x86 #+darwin (a) (b) (c)"))

CCL prints (B), (C), (B), (A) by the following rationale:

In the first test, 'x86' is true so a form must be discarded. 'darwin' is true so the '(a)' reads as NIL due to read-suppress being T. NIL is the expression skipped by the #-x86 making (b) the next expression. etc.

This is probably what you want:

Index: l1-reader.lisp
--- l1-reader.lisp	(revision 15900)
+++ l1-reader.lisp	(working copy)
@@ -2950,7 +2950,7 @@
 (defun read-feature (stream)
-  (let* ((f (let* ((*package* *keyword-package*))
+  (let* ((f (let* ((*package* *keyword-package*) (*read-suppress* nil))
               (read stream t nil t))))
     (labels ((eval-feature (form)
                (cond ((atom form)

#1113 defstruct types aren't properly recognized by subsequent forms ANSI CL Compliance defect Sep 18, 2013


(defstruct a-type)
(defun b ()
  (the a-type t))

Error: Unknown type specifier: A-TYPE While executing: CCL::%%TYPEP, in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts.

CLHS says: If a defstruct form appears as a top level form, the compiler must make the structure type name recognized as a valid type name in subsequent declarations (as for deftype) and make the structure slot readers known to setf. Compiling

(defstruct a-type)
(defun b ()
  (the a-type t))

#1142 ccl crashes after calling (quit) Compiler defect Jan 21, 2014

Steps to reproduce (using cygwin):

  1. Grab the latest revision (16010)
    cd /cygdrive/c/ccl
    svn update
  2. Rebuild the kernel:
    cd lisp-kernel/win32
  1. Rebuild ccl
    cd ../..
    (ccl:rebuild-ccl :clean t)
    ;Loading #P"C:/ccl/level-0/l0-pred.wx32fsl"...
    ;Loading #P"C:/ccl/level-0/l0-symbol.wx32fsl"...
    ;Loading #P"C:/ccl/level-0/l0-utils.wx32fsl"...
    ;Loading #P"C:/ccl/level-0/nfasload.wx32fsl"...
    ;Wrote bootstrapping image: #P"C:/ccl/wx86-boot32.image"
    ;Wrote heap image: #P"C:/ccl/wx86cl.image"
  1. Call (quit)
    %eax = 0x000000c4
    %ecx = 0x01bcf20c
    %edx = 0x0000ee00
    %ebx = 0x7ffdee88
    %esp = 0x01bcf524
    %ebp = 0x000253d6
    %esi = 0x01bcf9e0
    %edi = 0x00000000
    %eip = 0x7ffdfec7
    %eflags = 0x00010693
    %cs = 0x001b
    %ds = 0x0023
    %ss = 0x0023
    %es = 0x0023
    %fs = 0x003b
    %gs = 0x0000
    Exception on foreign stack
    Exception occurred while executing foreign code

#1200 %safe-get-objc-class apparently isn't completely safe Objective-C Bridge defect Jun 19, 2014

It appears that %safe-get-objc-class can sometimes botch it.

Welcome to Clozure Common Lisp Version 1.10-dev-r16119  (DarwinX8664)!
? (require 'objc-support)
? (df '%safe-get-objc-class)
;; "ccl:objc-bridge;objc-support.lisp.newest":29457-29773
    (leaq (@ (:^ L0) (% rip)) (% fn))       ;     [0]
    (cmpl ($ 8) (% nargs))                  ;     [7]
    (jne L477)                              ;    [10]
    (pushq (% rbp))                         ;    [16]
    (movq (% rsp) (% rbp))                  ;    [17]
    (pushq (% arg_z))                       ;    [20]
    (cmpb ($ 26) (% imm0.b))                ;   [240]
    (jne L493)                              ;   [243]
    (movq (@ -5 (% temp0)) (% imm0))        ;   [249]
    (movq (@ 80 (% rcontext)) (% temp2))    ;   [253]
    (movq (% imm0) (@ 16 (% temp2)))  Unhandled exception 10 at 0x7fff8a266097, context->regs at #xb029b960
Exception occurred while executing foreign code
 at objc_msgSend + 23
received signal 10; faulting address: 0x18
? for help
[19015] Clozure CL kernel debugger: b

(#x0000000020E19160) #x000030200143B454 : #<Function %SAFE-GET-OBJC-CLASS #x000030200143B2FF> + 341
(#x0000000020E191C8) #x000030200142E5F4 : #<Function LOOKUP-TAGGED-INSTANCE-CLASS #x000030200142E59F> + 85
(#x0000000020E191F0) #x0000302000469FC4 : #<Function (:INTERNAL RECOGNIZE RECOGNIZE-OBJC-OBJECT) #x0000302000469E6F> + 341
(#x0000000020E19218) #x000030000024779C : #<Function CLASSIFY-FOREIGN-POINTER #x000030000024768F> + 269

#1354 Array element not set if array is declared Compiler defect Mar 19, 2016

Found this while modifying some code in maxima:

(defvar *z* (make-array 2 :element-type '(complex double-float)
			:initial-contents '(#C(2.0 3.0) #C(-1.0 -1.0))))

(defun $rfft (z)
  (declare (type (simple-array (complex double-float) (*)) z))
  (let* ((n (ash (length z) 1))
	 (result (make-array (1+ (length z)) :element-type '(complex double-float)
			     :initial-element #c(42d0 0))))
    (declare (type (simple-array (complex double-float) (*)) result))

    (when (< n 3)
      (return-from $rfft ($fft input)))
	;;(declare (optimize (speed 3) (safety 0 )))
      ;; Compute FFT of shorter complex vector.  NOTE: the result
      ;; returned by fft has scaled the output by the length of
      ;; z.  That is, divided by n/2.  For our final result, we want to
      ;;     divide by n, so in the following bits of code, we have an
      ;;     extra factor of 2 to divide by.
      ;;(setf z (fft-r2-nn z))

      (format t "z = ~A~%" z)
      ;; Reconstruct the FFT of the original from the parts
      (setf (aref result 0)
	    (complex (* 0.5
			(+ (realpart (aref z 0))
			   (imagpart (aref z 0))))

      (format t "result = ~A~%" result)

After compiling this, run ($rfft *z*). The printed output for result doesn't change, even though set explicitly set the first element to something different from #c(42.0 0).

Remove the declaration, and the output is correct.

(lisp-implementation-version) is Version 1.11-R16635 (Darwinx8664), on OSX 10.11.3

#1355 bad regspec: NIL compiling with speed 3 safety 0 Compiler defect Mar 19, 2016

Compile the following (same code as ticket #1354):

(defun $rfft (z)
  (declare (type (simple-array (complex double-float) (*)) z))
  (let* ((n (ash (length z) 1))
	 (result (make-array (1+ (length z)) :element-type '(complex double-float)
			     :initial-element #c(42d0 0))))
    (declare (type (simple-array (complex double-float) (*)) result))

    (when (< n 3)
      (return-from $rfft ($fft input)))
	(declare (optimize (speed 3) (safety 0)))
      ;; Compute FFT of shorter complex vector.  NOTE: the result
      ;; returned by fft has scaled the output by the length of
      ;; z.  That is, divided by n/2.  For our final result, we want to
      ;;     divide by n, so in the following bits of code, we have an
      ;;     extra factor of 2 to divide by.
      ;;(setf z (fft-r2-nn z))

      (format t "z = ~A~%" z)
      ;; Reconstruct the FFT of the original from the parts
      (setf (aref result 0)
	    (complex (* 0.5
			(+ (realpart (aref z 0))
			   (imagpart (aref z 0))))

      (format t "result = ~A~%" result)

This produces the error message:

  bad regspec: NIL

If I remove the declaration from locally or change safety to 1, there's no error.

Version is Version 1.11-R16635 (Darwinx8664) running on OSX 10.11.3.

#409 Handling of invalid type specifiers Runtime (threads, GC) enhancement Jan 20, 2009

Certain things are clearly invalid in contexts where type specifiers are expected.

Only class objects, symbols, or lists whose CARs are symbols are potentially type specifiers. CCL currently signals a SIMPLE-ERROR whenever it encounters an attempt to use some other type of object as a type specifier; this error may be signaled at compile/macroexpand-time or at runtime.

Class objects are always valid type specifiers, as are symbols that name built-in types and conses whose CARs name builtin types (assuming that the CDRs of those lists contain an appropriate number of forms:


is valid,


is clearly not a valid type specifier (and never can be.)

Some symbols can only be used as operators in compound type specifiers; this is only true of builtin types. (We don't enforce this, and treat AND and (AND) as being equivalent.) For some type X defined via DEFTYPE, X and (X) are equivalent (and both are valid if either is. (We may define some builtin types via DEFTYPE.)

Some symbols name builtin types that can be used as atomic type specifiers or as operators in compound type specifiers. (CONS and STRING are examples of such symbols.)

Some symbols can only be meaningfully used as atomic type specifiers. This is true of any builtin type that doesn't explicitly allow compound use and of symbols that would be interpreted as class names. (SEQUENCE SYMBOL) is clearly never a valid type specifier. If X is not a builtin type, then whether or not (X ...) is valid may depend on whether or not X is a proper class name or a user-defined type name, and this can change over time (though the compiler's allowed to assume that class names and superclass relationships that exist at compile-time will exist at runtime.)

The type system generally allows for the possibility that a type-specifier can be referenced (at compile/macroexpand time, certainly) before it's defined. In many cases (type predicates on slots in standard objects, MAKE-ARRAY, ...) an unknown type specifier is treated as if it specified the universal type T at runtime. I don't know to what extent existing code may rely on this behavior. (It wouldn't be totally unreasonable to issue a deferred warning for forward-referenced types and to try to resolve those warnings at the end of a compilation unit.)

It is probably reasonable (and less controversial) to distinguish between "unknown, possibly forward-referenced type specifiers" and "definitely invalid type specifiers". The latter class includes both things like 17 and things like (SEQUENCE FOO), and it's not clear that there's a significant difference between those cases. (The latter case "looks" more legitimate and may be more prevalent in some user code, but it's not really clear that there's a difference.)

There's pretty clearly a difference between (SEQUENCE FOO) and NOT-DEFINED-YET-BUT-MIGHT-BE-SOON, and runtime use of the former would be well-justified in signaling an error (as might compile-time use.)

#995 CCL internal lock contention during multi-threaded computation Performance enhancement Jul 21, 2012

We have a multithreaded computation that uses TYPEP a lot to filter results but is experiencing performance issues.

There's an internal recursive-lock in the CCL type system that causes reporting threads to block a noticeable amount of time. The lock is 'lock' in l1-typesys.lisp in the form that defines clear-type-cache values-specifier-type and is closed over those functions.

And our culprit is a simple TYPEP.

Not much happens while the lock is grabbed; for a (typep <obj> '<class-name>) call, it's basically an sxhash and an svref. But with many processes all filtering entries from their database session identity maps by type, there's a lot of contention.

We can refactor our application to have fewer calls to TYPEP.

But CCL implementers might be interested in some lock-free algorithm , for instance using persistent datastructures for the type cache, or some structure that only requires a lock when writing.

Xref: ITA bug 119154

#375 ccl::%svref with "large" fixnum indices Compiler defect Nov 4, 2008

I'm not sure if this is limited to just %svref (it might happen for other vector types in unsafe code, but:

? (defun foo (v)
  (%svref v 40000))
> Error: bad regspec: NIL
> While executing: %HARD-REGSPEC-VALUE, in process listener(1).

Some of the x8664 constants may also be a bit off, but x8632::max-32-bit-constant-index is supposed to be an upper bound on the largest integer we can use to access an element in a 32-bit vector, i.e., a little bit less than MOST-POSITIVE-FIXNUM when misc-data-offset/misc-float-offset are accounted for. This number was much smaller on PPC, where constent displacements have to fit in 16 bits.

#234 [ACL2] Garbage Collection Performance on OpenMCL Runtime (threads, GC) enhancement Jan 31, 2008

The folks at UTexas have been playing around with mergesort, and since you're already improving the garbage collector, you would probably like to see this problematic example.

Can you make running the below example with garbage collection enabled as fast as (or at least closer in performance to) executing when the garbage collector has really large GC thresholds? With GC effectively disabled, non-parallelized code speeds up by a factor close to 15. And parallelized code (via my threading library) speeds up by a factor close to 100.

This smaller example yields a slow down of about 3 when using default garbage collection thresholds. This example runs on ACL2-3.3 compiled with OpenMCL x86-64.

If you would like, I can also send you the parallelized mergesort example. Running this would require you to download PACL2, but you've done this before, so maybe this would be a good thing to do.

Thanks, David

(include-book "finite-set-theory/osets/sets" :dir :system)

(defmacro assign$ (name value)
 `(make-event (pprogn (f-put-global
                       (quote ,name)
                      (value '(value-triple nil)))))

(in-package "SETS")

(defun integers (n acc)
 (if (zp n)
     (reverse acc)
   (integers (1- n) (cons n acc))))

(ACL2::assign$ int-list (integers 3200000 nil))
; For true dramatic effect use this commented out version instead
; (ACL2::assign$ int-list (integers 32000000 nil))

(ACL2::cw "Timing the serial verions of mergesort")

(ACL2::assign$ serial-result (time$ (SETS::mergesort-exec (@ int-list))))

(ccl:set-lisp-heap-gc-threshold (* 4 16777216))
(ccl:configure-egc (expt 2 16) (expt 2 17) (expt 2 17))
; For true dramatic effect use this commented out version instead
; (ccl:configure-egc (expt 2 30) (expt 2 31) (expt 2 32))


  (let ((*package* (find-package "CCL")))
    (eval (read-from-string "

 ;;; Work of Gary Byers.

 ;;; The #_ and #$ reader macros in the code below are part of
 ;;; OpenMCL's ffi; you'd basically need to hide this code in
 ;;; a file that's isolated from other implementations.
 (defun acl2::physical-memory ()
    (rlet ((info :sysinfo))
      (if (eql 0 (#_sysinfo info))
        (pref info :sysinfo.totalram))))"))))

 (defparameter *gc-min-threshold* (expt 2 31))

 (defparameter *max-mem-usage*
   (let ((phys (physical-memory)))
     (max (floor (* 6/8 phys))

 (defun set-and-reset-gc-thresholds ()
   (let ((n (max (- *max-mem-usage* (ccl::%usedbytes))
     (cond ((not (eql n (ccl::lisp-heap-gc-threshold)))
            (ccl::set-lisp-heap-gc-threshold n)
   (cond ((not (eql *gc-min-threshold*
          (ccl::set-lisp-heap-gc-threshold *gc-min-threshold*)

 (defun set-max-mem-usage (max)
   (setf *max-mem-usage* max)

  #'(lambda ()
       (slot-value ccl:*application*


 (ccl::gc-verbose t t)
 (ccl:egc nil)


(ACL2::cw "GC Disabled.  Timing the serial verions of mergesort (again)")

(ACL2::assign$ serial-result (time$ (SETS::mergesort-exec (@ int-list))))

#478 MCL subset of LispM-style package specifications in modeline IDE Cocoa IDE v? enhancement May 20, 2009

From http://clozure.com/pipermail/openmcl-devel/2009-May/009514.html:

In MCL one can have the package name in a list on the mode line (ie ";-*- mode: lisp; Package: (:DATA) -*-") and that means create the package if it does not exit. That exact and useful convention does not work in CCL.

gz (1 match)

Ticket Summary Component Milestone Type Created
#235 make-array does not check the validity of its :element-type argument Compiler enhancement Feb 1, 2008

"Version 1.2-r8284S (LinuxX8664)"

make-array does not verify that the :element-type is a valid type.

mikel (4 matches)

Ticket Summary Component Milestone Type Created
#512 The icon displayed in the finder differs from that in the dock IDE defect May 28, 2009

The CCL IDE's icon mysteriously changes when the application in opened and displayed in the dock.

In the finder, it appears as the (CCL) text in red on a transparent background. In the dock the (CCL) logo is backed by a graded cyan fill.

I would expect the icon's appearance to be consistent between the finder and the dock.

Clozure Common Lisp version 1.3 (12149M-trunk)

#529 Lisp>Load Buffer and Lisp files with defpackage + in-package, -> 'no package' error IDE defect Jun 5, 2009

Following text in a buffer:


(defpackage "FOO" (:use "CL"))

(in-package "FOO")

(defun foo () 'bar)


1) Open a file with above contents and place the cursor at the end of the buffer.

2) use the menu entry Lisp>Load Buffer


Welcome to Clozure Common Lisp Version 1.3-r12088M (DarwinX8664)! ?

Error: There is no package named "FOO" . While executing: #<STANDARD-METHOD CCL::READ-TOPLEVEL-FORM (GUI::COCOA-LISTENER-INPUT-STREAM T)>, in process Listener(6).

The same happens with this:

1) create a new editor window

2) paste above text into the window

3) save the buffer

4) use the menu entry Lisp>Load Buffer

#537 IDE does not complete swank load at startup IDE Cocoa IDE v? defect Jun 13, 2009

Set up a SLIME configuration that identifies the Cocoa IDE is the Lisp you want to run. For example:

(add-to-list 'slime-lisp-implementations

`(ccl-ide ("/Users/mikel/Valise/clozure/ccl/bin/ccl-ide") ) t)

...where ccl-ide is a shell script that executes the lisp kernel inside the IDE's app bundle:

CCL_DEFAULT_DIRECTORY="/Users/mikel/Valise/clozure/ccl/source" DD=${CCL_DEFAULT_DIRECTORY} CCL_DEFAULT_DIRECTORY=${DD} exec ${DD}/Clozure\ CL64.app/Contents/MacOS/dx86cl64 "$@"

The IDE starts up, but the SLIME connection never completes; it hangs waiting for a response from the swank server that it expects the Lisp to be running.

If you abort SLIME's attempt to connect, then manually load and start swank, you can then obtain a working SLIME connection.

If you follow the same procedure with a CCL kernel and image that are not an IDE build (for example, with the CCL kernel and image that are built by default with the CCL distribution) then SLIME startup completes normally.

Perhaps there is a problem with the way that the IDE handles command-line arguments at startup?

SLIME passes a string like the following to CCL for evaluation at startup:

(progn (load "/Users/mikel/emacs/site/slime/swank-loader.lisp" :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall (read-from-string "swank:start-server") "/var/folders/In/InwJX++UGgy+fa2kvmnfAU+++TI/-Tmp-/slime.16025" :coding-system "iso-latin-1-unix"))

(Taken verbatim from a failed SLIME startup). Note that one way to obtain a working SLIME connection is to abort the startup connection, copy the string like the one above from the Emacs buffer that reports that it's waiting for the connection, and eval it in the Cocoa listener window. That evaluation completes successfully and reports the port on which swank is running; thereafter you can obtain a working SLIME connection by using M-x slime-connect to connect to the reported port.

#192 Fix "Load Buffer..." and related menu-items IDE enhancement Nov 28, 2007

For completeness sake, CCL should have "Load File..." and "Compile File..." menu items. These could be on the "Lisp" menu, as a new section underneath the current section containing "Execute Selection," "Load Buffer," etc.

rme (3 matches)

Ticket Summary Component Milestone Type Created
#400 lisp API for managing text attributes IDE Cocoa IDE v1 enhancement Jan 12, 2009

Define and implement an API for managing text attributes in editor buffers.

It's not a near-term goal to make these text attributes persistent (i.e., to somehow save them with the file, via extended attributes on files or whatever), though it might be worthwhile to keep such a possibility in mind when designing the API.

This interface needs to map fairly well onto the approach that NSAttributedString uses (since we'll be using it to implement part NSAttributedString's functionality). See http://developer.apple.com/documentation/Cocoa/Conceptual/AttributedStrings/Concepts/AttrStrings.html

#1383 Use xcrun to find SDKROOT for Darwin-based systems other defect Sep 12, 2016

In the Makefiles for Darwin-based systems, you can use the following to find the SDKROOT instead of hardcoding it to /:

SDKROOT = "$(shell xcrun --sdk macosx --show-sdk-path)"

That way people don’t have to have the Command Line Tools package installed to build CCL.

#176 Apropos dialog should display a little bit more information about the symbols IDE Cocoa IDE v1 enhancement Nov 10, 2007

The Apropos dialog displays a list of Symbols.

There should be more information about the symbols:

a) Is it external/inherited/internal?

b) There should be a columns for small icons (small capital letter on colored background?) displaying: does it name a class, a function (macro, special form), has it a value, a property list, is it a hemlock command, a type, ...?

Clicking on one of the icons should edit the definition (class, function, variable, type, ...).

Moving the mouse over one of the icons could display a small transparent window with a rendering of the corresponding documentation string.

There could also be a small line above the displayed results, where one could select to only search in external symbols. Small check boxes aligned in the column of above icons also could filter the search for examples to display only classes.

It would also save keystrokes if the search is 'live' - typing characters displays the results without the need to press the return key.

xach (1 match)

Ticket Summary Component Milestone Type Created
#1167 Add filter to list definitions window IDE enhancement Mar 12, 2014

It would be nice if the new list definitions window had a text entry field that could be used to filter the output. Only definitions that contain the entered text would be shown.

Note: See TracReports for help on using and creating reports.