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

Alexander Repenning alexander.repenning at Colorado.EDU
Tue Aug 28 07:10:09 PDT 2012

On Aug 28, 2012, at 7:21 AM, Gary Byers wrote:

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

The proof is in the pudding. It just does. The code below (not completely sure where this came from, I think this was posted sometime but got seriously hacked over time) interestingly does NOT exhibit this behavior (32/64). There probably should be in in-main-thread in there.

____________ file chooser not hanging on moutain lion ______________

(defun NATIVE-STRING (String) "
  Return a native string"
  (#/autorelease (ccl::%make-nsstring String)))

(defun ns-array-from-list (list)
  "The list must be an array of ns-objects"
  (let ((nsa (#/array ns:ns-array)))
    (dolist (list-item list)
      (setf nsa (#/arrayByAddingObject: nsa list-item)))

(defun choose-file-dialog (&key 
                           (button-string "Open") 
                           (window-title "Choose a File") 
                           (allow-multiple-files nil)
                           (window-position (ns:make-ns-point 100 100))
  (let* ((panel (#/openPanel ns:ns-open-panel))
	 ;(dc (#/sharedUserDefaultsController ns:ns-user-defaults-controller))
         ;(values (#/values dc))
	 ;(key #@"cclDirectory")
         (file-types +null-ptr+)
    ;; Kind of nasty code just to change the title of the cancel button, need to go through two layers of subviews to find the button and change its title.  
    (if cancel-button-string
      (let ((subviews (gui::list-from-ns-array (#/subviews (#/contentView panel)))))
        (dolist (subview subviews)
          (if (equal (type-of subview) 'NS:NS-VIEW)
            (let ((subviews2 (gui::list-from-ns-array (#/subviews subview))))
              (dolist (subview2 subviews2)
                (if (equal (type-of subview2) 'NS:NS-BUTTON )
                  (if (equal (#/title subview2) (native-string "Cancel"))
                    (#/setTitle: subview2 (native-string cancel-button-string))))))))))
    (when file-type-string-list
      (setf file-type-string-list (mapcar #'native-string file-type-string-list))
      (setf file-types (ns-array-from-list file-type-string-list)))
    (when button-string
      (setf button-string (ccl::%make-nsstring button-string))
      (#/setPrompt: panel button-string))
    (when window-title
      (setf window-title (ccl::%make-nsstring window-title))
      (#/setTitle: panel window-title))
    (when prompt
      (setf prompt (ccl::%make-nsstring prompt))
      (#/setMessage: panel  prompt))
    (#/setAllowsMultipleSelection: panel allow-multiple-files)
    (#/setCanChooseDirectories: panel nil)
    (#/setCanChooseFiles: panel t)
    (#/setFrameOrigin: panel window-position)
    ;#-cocotron (#/setAllowedFileTypes:  panel (#/arrayWithObject: ns:ns-array (native-string "lisp")))
    ;#-cocotron (#/makeKeyAndOrderFront: panel +null-ptr+)
    #-cocotron (#/orderFront: panel +null-ptr+)
    (when (eql (#/runModalForDirectory:file:types: panel
						   (native-string directory)
      (if allow-multiple-files
        (let ((filenames (gui::list-from-ns-array (#/filenames Panel))))
          (dotimes (i (length filenames))
            (setf (elt filenames i) (pathname (ccl::lisp-string-from-nsstring (elt filenames i)))))
        (pathname (ccl::lisp-string-from-nsstring (#/objectAtIndex: (#/filenames Panel) 0)))))))


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

AFAIK this did not fix any of the problems we have. And it does not explain the problem on 32 bit. 


Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20120828/e664030f/attachment.htm>

More information about the Openmcl-devel mailing list