Custom Query (1030 matches)
Results (460 - 462 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #757 | fixed | char names for ascii control chars | ||
| Description |
Porting some code from lispworks/sbcl I note that the char names for things like #\SOH et. al. are not defined. (loop for x in '("#\NUL" "#\SOH" "#\STX" "#\ETX" "#\EOT" "#\ENQ" "#\ACK" "#\BEL" "#\BS" "#\HT" "#\NL" "#\VT" "#\NP" "#\CR" "#\SO" "#\SI") collect (ignore-errors (read-from-string x))) |
|||
| #758 | fixed | ARM-specific error during compilation | ||
| Description |
During compilation (often if not always during compilation of some file in "ccl:level-0;ARM;"), our build system sometimes gets the following error (or something very, very much like it): > Error: value 0 is not of the expected type LIST. > While executing: MEMEQL, in process listener(1). This is ultimately due to the fact that *FEATURES* is getting bound to '(0 . 0) in COMPILE-FILE, but it's not clear how/why that happens. In the backtrace in: http://setf.clozure.com:8010/builders/linuxarm/builds/72/steps/shell_2/logs/stdio the local variable VALUES has the value ((0 . 0)), and *FEATURES* is bound to the CAR of that value (via PROGV.) VALUES is effectively bound to the value returned by: (list (append nil *features*)) I've seen this happen, but haven't yet been able to determine why. There are lots of suspects ... |
|||
| #765 | fixed | asdf2 uninterns itself during build | ||
| Description |
You can see a description of the problem and a solution at: http://common-lisp.net/pipermail/asdf-devel/2010-October/001708.html A trace is shown at: http://paste.lisp.org/+2H95 [This paste will automatically go away in 6 days.] In a nutshell, ASDF2 will unintern portions of itself if ASDF is already loaded and it is loaded again during the build process. The solution is to start ccl with the --no-init option before invoking (ccl:rebuild-ccl :full t) so that any "(require :asdf)" form in .ccl-init is bypassed. I don't think any code changes need be done to ccl, but it would be nice if something would be mentioned in the ccl documentation, otherwise this conflict between asdf and ccl is going to show up again. Perhaps section "3.3 Building Everything" of the Clozure CL Documentation would be a good place to document this issue. |
|||
