[Openmcl-devel] Debugging Cocoa (was: programmatic file chooser? thanks!)

[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. Output from processes such as the APPKIT- 
PROCESS do not write to the listener. It can sometimes take quite some  
while for that output to show up. The solution is to start CCL via a  
terminal window. In that case the output will show up in that terminal  
window and will do so about 1000 times faster. The MCL had its problem  
too. It opened up a listener per thread in case of output. For CCL I  
think it would be good to have just ALL the output be routed to the  
listener. Perhaps there could be a before method called with the  
current-process allowing developers to customize output, e.g., by  
preceding output from certain processes with some prefix prompt.


2) notice the bug in the method above (division by zero). In the main  
thread an error would be raised. In the APPKIT-PROCESS there is no  
evidence of the bug. No error message. No user prompting with  
continuation. No opportunity to enter backtrace. Is there some  
implicit error handler in the APPKIT-PROCESS that simply ignores all  
the errors raised? This makes things hard to debug because one does  
not even suspect a problem. LW, in contrast, not only catches the  
error in the usual way (raising a division-by-zero condition) but also  
allows a backtrace including getting to the point in the source  
causing the problem. This is very nice. Is there a simple way to get  
around this?


- detail: Why is the backtrace window in CCL 1.2 a drop shadow less  
window? Looks like a bug to me.
- ps: a good way to explore Cocoa functionality is via XCode. It  
includes some nice documentation browsers

all the best,  Alex



On Aug 28, 2008, at 4:18 AM, Gary Byers wrote:

> When learning CL, there were probably some fairly major concepts
> that needed to be absorbed, including:
>
>   - macros
>   - syntax (or the near total absence of it)
>   - the general notion that everything's a function that returns
>     some number of values, and that most primitive operations
>     (arithmetic, array/string access) are expressed as function calls
>   - closures and higher-order functions
>   - special variables and dynamic binding
>   - lambda-lists and variadic functions
>   - garbage collection (which might or might not be a new concept)
>   - CLOS
>   - the reader, packages ..
>   - the fact that there's a fairly rich library of standard functions
>     for dealing with common data structures
>   - ...
>
>

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/20080828/ab36935a/attachment.htm>