[Openmcl-devel] Modal dialog problems with CCL 1.9 32/64 on Mountain Lion
alexander.repenning at Colorado.EDU
Wed Aug 29 23:04:36 UTC 2012
I think I have here a pretty Kosher (uses retain, does not use depreciated functions) version of the dialog + memory surge problem. This version of choose-file-dialog is completely stripped of any non essential activity. It does not even return the path, i.e., there is no practical value to this function.
Please have a go and see if you can or cannot experience that Memory surge phenomenon. Please follow the instructions closely. Otherwise you may miss the issues at sometimes can be kind subtle.
;; CCL 1.8.1 64 (Mac App store) crash on Mountain Lion 10.8.1
(defun choose-file-dialog2 ()
;; 100% kosher: retain, no use of depreciated calls
(let ((panel (#/retain (#/openPanel ns:ns-open-panel))))
(defun THE-AMAZING-MEMORY-SURGE ()
(dotimes (i 100)
(ccl::process-run-function "pretent to load project" #'(lambda () )))))
;; this will pop up a file chooser for a number of times. Each time just press ESC and watch the Activity Monitor.
;; Set view > update frequency in Actvity Monitor to very often (0.5s) for best results
;; Watch out for Clozure CL % CPU and Real Mem
;; for some time Real Mem will go up gradually (memory leak) then at some unpredicatable time it will SURGE to GIGABITES of memory and ultimately crash CCL
;; with with-autorelease-pool CCL may crash quite quickly with a Unhandled exception 10, comment out if needed
On Aug 28, 2012, at 3:08 PM, Gary Byers wrote:
> 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
> 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
>> warmest regards,
>> Raffael Cavallaro
>> raffaelcavallaro at me.com
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel