[Openmcl-devel] Debugging Cocoa (was: programmatic file chooser? thanks!)
joswig at lisp.de
Thu Aug 28 17:11:38 EDT 2008
Am 28.08.2008 um 21:34 schrieb Alexander Repenning:
> Thanks Gary for the detailed response. I have just spent some time
> to write some basic GUI code based on Cocoa in LispWorks and Clozure
> CL. I could go on about the philosophical differences between LW and
> CCL wrt Cocoa but that is perhaps left best for some other time. At
> the end of the day both approaches work.
> CCL gets high scores for having defined interfaces, based on reading
> the header files I presume. LW includes no such information. As
> developer I have to define my own function/method/constant
> definitions for Cocoa and other APIs in LW. Not very practical for
> large APIs.
> The main problem, we found with CCL and Cocoa, especially vis-a-vis
> LW, is debugging. Specifically, CCL makes it hard to debug Cocoa
> call backs. Example: Say I have a window (NSWindow containing
> NSView) with a buggy event handler.
> (defmethod VIEW-LEFT-MOUSE-DOWN-EVENT-HANDLER ((Self event-test-
> Window) X Y)
> (format t "click: x=~A, y=~A~%" x y)
> (setf (x self) x)
> (setf (y self) y)
> (/ x 0) ;; division-by-zero!!!
> (print *Current-process*)
> (view-draw-contents Self))
> 1) output to OS X console does not work as interactive debugging
> tool. There is too much lag. The print/format statements, if you
> start CCL 1.2 by double clicking the OS X app will produce output in
> the OS X console with great lag time.
Probably not related to this, but I'll mention it anyway, since I have
seen this in other debugging contexts:
Sometimes the output streams are buffered (and the display gets
updated sometime later) and one needs to
call FINISH-OUTPUT or FORCE-OUTPUT after printing something to see any
debug information immediately.
Please ignore above if it does not apply here...
Rainer Joswig, Hamburg, Germany
mailto:joswig at lisp.de
More information about the Openmcl-devel