Custom Query (1030 matches)
Results (442 - 444 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #763 | invalid | FP exception handling and "random" FP exceptions | ||
| Description |
On at least some fairly recent versions of OSX, using drag-and-drop to drag text around in the Cocoa IDE generates an FP exception (invalid operation IIRC). This happens deep in some CG text-drawing code that's invoked by CCL calling the superclass's #/mouseDown: method, and we report it as an arithmetic error. The error's likely to just be confusing and disruptive to the user. We can work around this particular bug by disabling FP exceptions around the next-method call. We generally try to report FP exceptions that occur in foreign code; this certainly makes sense if (for instance) #_sin is called as part of the implementation of CL:SIN. It's less clear that it's desirable or useful to try to detect and report FP exceptions that have nothing to do with CL math functions, though we've traditionally done so. |
|||
| #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 |
|||
| #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 ... |
|||
