..grumble grumble grumble vi user grumble mutter
:-) I once was not only a vi user, but an ed user...
What do I need to type to get the debugger to show me the evaluations of append?
Inside Emacs :-): go to the CiaoDgb menu, select "(Un)Debug buffer source", then call the entry point.
Outside Emacs, assuming you want to debug module 'my_module':
[mcarro(a)clip tmp]$ ciao Ciao-Prolog 1.11 #229: Wed May 26 17:41:27 CEST 2004 ?- debug_module(my_module). <--- You can select several modules {Modules selected for debugging: [my_module]} {No module is selected for source debugging}
yes ?- trace. <--- You need to type this only once {The debugger will first creep -- showing everything (trace)}
yes {trace} ?- use_module(my_module). <--- You can edit the module and reload it
yes {trace} ?- app(A, [b,c], [a,b,c]). 1 1 Call: my_module:app(_272,[b,c],[a,b,c]) ? 1 1 Fail: my_module:app(_272,[b,c],[a,b,c]) ?
no {trace} ?-
I have pasted below the part of the manual which deals with the interactive debugger (BTW, the whole manual should be available in info, html, and pdf formats):
Marking modules and files for debugging in the top-level debugger
Usually, when a program is not working properly, the programmer has a feeling of which are the modules where the fault may be. Since full-fledged debugging is only available on _interpreted_ (called _interpreted mode_ in traditional Prolog systems) modules, which are executed much slower than compiled modules, there is the posibility of telling the top level which particular modules are to be loaded in _interpreted mode_, with the aim of debugging them. The simplest way of achieving this is by executing in the Ciao shell prompt, for each suspicious module `Module' in the program, a command like this:
?- debug_module(Module).An alternative way of loading a module in interpreted mode exists which will instruct the debugger to keep track of the line numbers in the source file and to report them during debugging. This feature can be selected for a suspicious module `Module' in the program by executing a command such as:
?- debug_module_source(Module).This is most useful when running the top-level inside the `emacs' editor since in that case the Ciao emacs mode allows performing full source-level debugging in each module marked as above, i.e., the source lines being executed will be highlighted dynamically during debugging in a window showing the source code of the module.
Note that all files with no module declaration belong to the pseudo-module `user', so the command to be issued for debugging a user file, say `foo.pl', would be `debug_module(user)' or `debug_module_source(user)', and not `debug_module(foo)'.
The two ways of performing source-level debugging are fully compatible between them, i.e., Ciao allows having some modules loaded with `debug_module/1' and others with `debug_module_source/1'. To change from one interpreted mode to the other mode it suffices to select the module with the new interpreted mode (debugger mode), using the appropiate command, and reload the module.
The commands above perform in fact two related actions: first, they let the compiler know that if a file containing a module with this name is loaded, it should be loaded in interpreted mode (source or traditional). In addition, they instruct the debugger to actually prepare for debugging the code belonging to that module. After that, the modules which are to be debugged have to be (re)loaded so that they are compiled or loaded for interpretation in the appropriate way. The nice thing is that, due to the modular behaviour of the compiler/top-level, if the modules are part of a bigger application, it suffices to load the main module of the application, since this will automatically force the dependent modules which have changed to be loaded in the appropriate way, including those whose _loading mode_ has changed (i.e., changing the loading mode has the effect of forcing the required re-loading of the module at the appropriate time).
Later in the debugging process, as the bug location is isolated, typically one will want to restrict more and more the modules where debugging takes place. To this end, and without the need for reloading, one can tell the debugger to not consider a module for debugging issuing a `nodebug_module/1' command, which counteracts a `debug_module/1' or `debug_module_source/1' command with the same module name, and reloading it (or the main file).
There are also two top-level commands `set_debug_mode/1' and `set_nodebug_mode/1', which accept as argument a file spec (i.e., `library(foo)' or `foo', even if it is a user file) to be able to load a file in interpreted mode without changing the set of modules that the debugger will try to spy.