John M. Adams writes:
 > Being new to acl and lisp in general, I'd be interested in your
 > descriptions of development and debug work patterns.  I'm coming from
 > 9 years of C/C++.  When I think debugger, I think gdb.  In my initial
 > look at the acl environment, I'm seeing something I would describe as
 > relatively primitive.  Mind you, I may simply be lacking the
 > appropriate, informed perspective.
 > 

The debugger may look primitive but stepping is not as easy as in more 
low level languages. Try fully macro expanding some of your code and
look where the parts you wrote end up and how much implementation
dependent code is around it and how many implementation internal
functions are called. You might think the compiler could simply track
the macro expansions but even this is problematical. It has no way of
knowing at which level to stop expanding. If you take something like
Waters' SERIES package, which basically does a full code walk of the
forms you write with it to generate code, should the compiler treat it 
as user code or not? (It recently took me about an hour to trace an
ACL compiler bug that was generated by the SERIES macrology) In C and
C++ generally there is a straight forward relationship between a line
of code and the assembly generated. C++ just adds more function calls
in disguise. So gdb can shine with these languages because they're
fairly primitive.

 > Any general wisdom about debugging in the acl environment would be
 > welcome.  I've read the debugging.html.
 > 

On the other hand, I find I rarely miss a gdb-like debugger for
ACL. The interactive environment coupled with the backtrace is more
powerful than gdb's post mortem traces of a problem that is often
caused by memory corruption 10 function calls ago. Another facility
you can use to your advantage is ADVICE. If you need stuff more
advanced than TRACE allows you to do, do a :BEFORE ADVICE to check
preconditions or :AFTER to check results. Suppose you have a complex
data structure that gets trashed someplace. Write a function that
checks the invariants on the data structure and ADVICE all the
functions that modify the data structure to call that function after
they're done and BREAK when it's not satisfied.

-- 
Lieven Marchand <bewoner.dma.be at mal>
If there are aliens, they play Go. -- Lasker