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

[Gary Byers]

On Tue, 28 Aug 2012, Raffael Cavallaro wrote:

>
> On Aug 28, 2012, at 9:21 AM, Gary Byers <gb at clozure.com> wrote:
>
>> 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.
>
> I am not in any way tempted to ascribe supernatural powers to any version of CCL - though I have at times been tempted to ascribe supernatural powers to you and Matthew ;^)
>
> Changing the presentation style (whatever it's called) does cause the directories to populate, and to remain populated when the style is changed back. However, subsequent calls to ccl::choose-file-dialog still show the same empty-directories-until-presentation-style-is-changed issue.
>
> It would still be useful to know why this only manifests with ccl::choose-file-dialog and not with File:Open? (nor with any other application), but that's just idle curiosity?

My current theory is that the methods invoked by the shared instance
of NSDocumentController (that implement things like File:Open) work
more reliably because they aren't as brain-dead about autoreleasing
things that need to stick around through a modal event-loop as
CCL::CHOOSE-FILE-DIALOG seems to be.  According to TFM (which I just
R'ed), the NSOpenPanel itself has to be explicitly retained on (at least)
10.6 and earlier, and I don't think that CHOOSE-FILE-DIALOG has ever bothered
to do that.


>
> Maybe its because the deprecated #/runModalForDirectory:file:types: is causing problems under Mountain Lion even for apps like CCL that are not sandboxed.

My first attempt at replacing the deprecated method with supported
ones caused my tests to start showing unpopulated directories; I'd only
seen that once before.  Alex was apparently getting reliably good results
by mixing deprecated methods with their replacements; if his results were
universally reproducible, I'd have publicly sworn off badmouthing Mountain
Lion (since it'd have been obvious that the damned thing wasn't even finished
yet.)

One of the worst aspects of bugs where things get freed prematurely is
that the worst symptoms of those bugs may only appear if and when the
freed memory is reallocated, and when and whether that happens tends
to be dependent on lots of subtle little things.  That in turn can
mean that different people see different results and different OS 
releases seem to behave differently for mysterious reasons.

I don't know if this is the only problem and I may do something other
than Fighting The Good Mountain Lion Fight (like sleep ...) before trying
to check these changes in, but it's pretty clear to me at this point that
CHOOSE-FILE-DIALOG has never been quite right in its memory management
behavior.


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