[Openmcl-devel] Modal dialog problems with CCL 1.9 32/64 on Mountain Lion

[Gary Byers]

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
is roughly:

  - 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
    result.

    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).
>
> hth
>
> warmest regards,
>
> Ralph
>
>
> Raffael Cavallaro
> raffaelcavallaro at me.com
>
>
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>