Custom Query (1030 matches)

(We already know this, but might as well put it on a ticket to annoy and shame us.)

The Cocoa bridge tries to be helpful by turning lisp strings into NSStrings when passing them to methods that expect an Objective-C object. These strings are never released.

Just as an initial thought, suppose we put these NSString instances into an nsstring-wrapper class. We could then keep these wrappers in a weak-key hash table (using the lisp string as the key), and use OpenMCL's termination mechanism to arrange for the NSString to be released before the nsstring-wrapper value gets it in the neck from the GC.

This was reported on info-mcl.

Entering cmd-click makes the standalone IDE quit immediately.

Console shows: [15014] OpenMCL kernel debugger: Unhandled exception 11 at 0xfffeff18, context->regs at #xbfffe1e8 Read operation to unmapped address 0x21

In foreign code at address 0xfffeff18

As of r7528 there is a bug in incremental search, which can usually be triggered by doing wrapping incremental search, back and forward a few times and then exiting it and perhaps clicking the mouse. This here is NOT a bug report about that bug. But when you do hit that bug, you get an error about NIL not being a structure, and the lisp craps out trying to show the backtrace.

I've had it happen one of two ways: sometimes it gets an exception and enters the kernel debugger. Other times it still seems to get an exception, but somehow manages to handle it and prints some backtraces about the error within the error. In the second case, you can actually just kill the window that caused the problem, and continue with the same lisp. In the first case, the lisp is hosed.

I've attached terminal output for both cases.