On Thu, Dec 11, 2008 at 10:41 PM, Anton Vodonosov <avodonosov@...> wrote:
> on Wednesday, December 10, 2008, 6:30:33 PM Juan wrote:
> Great, thanks. It looks like you yourself do not use these features.
> I also remember that you do not use SLIME. What is your development
> technique? How do you find errors?
I must admit I am very primitive, and due to the nature of coding I
have to do I spend most of the time either in the GDB (C debugging) or
in the lisp interpreter, where debugging is much easier.
Since I am developing the lisp library, it does not make sense to
compile and then debug, but rather load a completely interpreted image
using ./ecl_min bare.lsp and then (si::top-level) from the directory
in which ECL is built. That is why I did not notice that backtraces
did not work for compiled code.
I admit, though, that the current debugging interface is still rough
and does not work fully as it should. There should be an API to access
backtraces, or even better to walk through the execution stack,
inspecting as much as it is possible without really consing new
structures -- required for critical or exhausted memory bugs --.
Ideally, this should be mixed with the ability to debug the C stack
itself, so that the setting (DEBUG 3) becomes irrelevant.
> Using your commit as a starting point for search, I found a way to
> override optimization settings in all the libraries, and compile
> everything with DEBUG 3 level.
Do the libraries override the debug settings? That is not a clever
design. Otherwise it should suffice to do (proclaim '(optimize (debug
3))) before building the library, not redefining a function from the
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)