[Openmcl-devel] Debugging Cocoa (was: programmatic file chooser? thanks!)
ralex at cs.colorado.edu
Thu Aug 28 19:34:31 UTC 2008
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!!!
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
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel