Custom Query (1030 matches)

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.

Very occasionally, one sees something like (from memory) :

Error: wrong number of args to FOO:
       2 arguments provided, 2 accepted

(however exactly that's presented/worded.)

A working theory is that that's icache-related and that the comparison of nargs with a constant and the conditional UUO that follows are in different cache lines and some instruction other than the comparison is actually executed instead. (That's a working theory only because this error was a symptom of failure to flush the icache on an iOS system.)

If it happens again, we should try to determine the address of the code vector and see if it's plausible that the first and second instructions are in different cache lines.

(The lisp kernel -may- try to determine the cache line size from information in the ELF aux vector or via sysctl or something like that; I'm not sure if it does, and it's unlikely that the value is used.)

Several people have reported (​http://clozure.com/pipermail/openmcl-devel/2010-October/012207.html) that the IDE can fail to start properly; one symptom is that creation of the initial listener can fail with a message to the effect that a Hemlock buffer named "Untitled" already exists.

This seems to be caused by the fact that an earlier attempt to create a listener fails (after the "Untitled" Hemlock buffer is created) because some instances of some hybrid objects (HEMLOCK-TEXT-STORAGE and friends) aren't properly initialized, which in turn seems to be due to the fact that the hash table which maps ObjC classes to sets of init keywords has been an EQL hash table; if foreign addresses of classes change, there's a good chance that classes won't be found in that table and their instances won't be correctly initialized.

We canonicalize ObjC class pointers and preserve them across sessions. *CLASS-INIT-KEYWORDS* should hash on identity, not foreign address.

This should be fixed in a minute. It was introduced in the trunk in r14263.