[Openmcl-devel] Modal dialog problems with CCL 1.9 32/64 on Mountain Lion
gb at clozure.com
Tue Aug 28 13:21:12 UTC 2012
I've generally had trouble reproducing this, and I confess that I've generally
been a little skeptical about what's been reported. The basis of that skepticism
- CCL::CHOOSE-FILE-DIALOG in the Cocoa IDE is a fairly thin wrapper around the
Cocoa NSOpenPanel class: it allocates an NSOpenPanel object, initializes that
object according to options passed to CHOOSE-FILE-DIALOG, runs the NSOpenPanel
via some flavor of #/runModal, and returns a lispified version of the Cocoa-level
NSOpenPanel isn't subclassed and none of its methods are overridden by lisp
code; AFAIK, CCL::CHOOSE-FILE-DIALOG hasn't changed much in a long time.
When I hear people claim that CHOOSE-FILE-DIALOG behaves differently with
10.8 and certain versions of CCL than it has otherwise, I wonder how it would
do that if it wanted to. Even if the different behavior was
attributable to some kind of memory-corruption or memory-initialization bug,
those kinds of bugs tend not to lead to predictable, repeatable behavior
that affects multiple users/machines/minor OS versions.
The claim sounds like it's based on primitive superstition, but that does
leave open the question of what IS going on.
- there's a known bug in 64-bit CCL on OSX that can cause lisp thread creation
to go into a horrible CPU-burning/memory-thrashing state. I think that that
bug's been present for a long time (since PPC64 days), but it's apparently
much easier to trigger on 10.8 (and/or recent versions of CCL) than it has been.
The problem ultimately has to do with whether or not #_malloc (actually #_calloc)
returns a 64-bit pointer whose high 32 bits are 0 and there can be many factors
that affect that (many of them subtle), and the fix is to stop assuming that
it does and allocate such pointers ourselves.
That's been fixed (in the trunk for a few weeks and in the 1.8 tree
for a few days) in svn; the symptoms happen to be very similar to
what people have reported seeing with CHOOSE-FILE-DIALOG, but the
CHOOSE-FILE-DIALOG problems seem to occur for at least some people
in 32-bit CCL (which was never affected by this thread-creation
problem) and in freshly-updated 64-bit versions.
- Between the time that CHOOSE-FILE-DIALOG calls #/runModalForDirectory:file:types:
and the time that that call returns, no lisp-defined methods in the CCL process
are called. But.
The Open and Save panels provide controls/buttons that affect how the directory
hierarchy is presented (as icons, as something like a table view, as something
like an NSBrowser, etc.) Mountain Lion ("New! Improved! More
buttons on NSOpenPanel!") provides a few more of theses
presentation-control buttons, and some of these presentation styles offer
thumbnail-like previews of the (tentatively) selected file ("Now with support
for QuickLook ... or QuickView ... or whatever it's called!"). AFAIK, this
is implemented by telling the application associated with a given file
type to draw the thumbnail (presumably by running the app with some offscreen
graphics environment and quite possibly by doing some caching.)
For a file with the extension .lisp (or .lsp, or .cl), the application in
question is ... well, the LispWorks IDE want's to associate itself with at
least some of those file types, as may other applications, as does the CCL
IDE. Several factors seem to be involved in determining what application is
globally associated with .lisp files (including "what application was installed
most recently" and "what would be the worst choice OSX could possibly make".)
If multiple versions of the CCL IDE are installed, using the version that is
running CHOOSE-FILE-DIALOG may be too good a choice; using an installed version
of 64-bit CCL that's subject to the thread-creation bug described above might
be one of the worst possible choices and therefore attractive to Mountain Lion.
If that was what was happening - we call CHOOSE-FILE-DIALOG and some other
version of CCL is run to draw thumbnails and that version thrashes around
hysterically ... well, that might at least partly explain what people are
seeing. (It's not clear how another instance of CCL thrashing around would
affect the copy that's doing the CHOOSE-FILE-DIALOG, but I don't fully understand
how thumbnail drawing works or what the relationship is between the
process requesting the thumbnail and the process drawing it.)
I'm of the school of thought that believes that if we all just close our
eyes and pretend that [Mountain] Lion doesn't exist, sooner or later it'll
go away; accordingly, I only use a system with Mountain Lion installed on
it very occasionally and only use it for testing, and the CCL versions that
I have installed on it tend to be fairly well up-to-date (and not subject to
the thread-creation problem.) I don't generally see the problems with
CHOOSE-FILE-DIALOG that other people report. That's consistent with the
theory that I'm proposing; I haven't yet thought of anything that's not
consistent with that theory. It's a good theory, but good theories aren't
necessarily correct ones.
The one time that I saw anything like this involved trying to generate a
thumbnail for a fairly large .jpg file. That hung for several minutes;
when I tried to force the application to quit, nothing happened. (I believe
that this may be the result of Apple trying to make MacOS more like their
iDevices, but who knows ?) It finally occurred to me that I could cancel
out of the NSOpenPanel and when I did everything seemed to be back to normal,
but when I called CHOOSE-FILE-DIALOG again the displayed directory contents
were empty. I used one of the presentation-style buttons to change the view
and files/directories reappeared and they were still there when I reverted
back to the presentation style I'd been using originally. People who are
tempted to ascribe supernatural powers to some versions of CCL (powers that
allow it to hide some files/directories that would otherwise appear) might
want to try toggling the presentation style (whatever it's called) to see
if this is just a Mountain Lion display/caching bug.
On Mon, 27 Aug 2012, Raffael Cavallaro wrote:
> On Aug 27, 2012, at 8:27 PM, Alexander Repenning <Alexander.Repenning at colorado.edu> wrote:
>> We tried 10.8.1 and even (early) 10.8.2
>> nothing changed for us.
> I'm running 10.8.1 and using 1.9-dev-r15450M-trunk (DarwinX8664 and DarwinX8632). I get the same multi-minute hangs before choose file dialogs are populated that you're seeing with both 32 and 64 bit IDEs. I do not see this with any other application.
> Interestingly, if I choose File:Open? (or hit cmd-O) I do *not* see this behavior - it manifests only when calling (ccl::choose-file-dialog).
> warmest regards,
> Raffael Cavallaro
> raffaelcavallaro at me.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel