Custom Query (1030 matches)
Results (586 - 588 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 ... |
|||
| #761 | notabug | libc not found | ||
| Description |
After installing Debian Lenny (stable) and the latest version of CCL-trunk and usocket, I get an error if I run (usocket:get-host-name) because #_gethostname is not found. This is because libc.so is not found in directory /lib. When I add a link to libc.so in /lib then all is well and it works. There /is/ a link to libc.so in the /usr/lib directory but ccl ignores it. I'm not sure whether ccl's goal is to be newbie-friendly, but if it is I think it would be wise to look for libc in all the usual places (/lib /usr/lib) on linux. Thanks |
|||
