Hello Neil, On 01-03, Neil Jerram wrote: > Holger Blasum writes: > Perhaps it would make sense for the debugger to show the source > position automatically on each step? What do you think? At least gdb, pydb (python) and ocamldebug (ocd) do this. But any verbosity trade-offs are better left to your consideration ... For reference here are the current ocamldebug and pydb default styles: (ocd) s Time : 2 - pc : 4164 - module Pervasives 112 float_of_bits 0x7F_F0_00_00_00_00_00_00L<|a|> (pydb) step ?() at server.py:1 1 from SocketServer import StreamRequestHandler, ThreadingTCPServer > So are you really looking for a _non_-interactive solution then? > In that case I recommend the trace-trap and trace-until-exit > behaviours provided by (ossau trace), and `set-trace-layout' to > configure exactly what trace output you want at each trap point. Wonderful, works great ;) > Thanks. Can you suggest some wording that would make it clear that > these are not the _only_ available procedures for getting information > out of a trap context? (Perhaps something including a reference back > to 2.4.2?) Perhaps: "In addition to the trap low-level context functions given in section 2.4.2, high-level trap context access is offered by the trap context object. It is an object that ..." Perhaps merge 2.4.1 with 2.4.3 and 2.4.2 with 2.4.4? > What about instead adding a whole new "Examples" chapter before the > current "Traps" one, containing the examples that we've discussed in > this thread, and other useful ones as they arise in future? I think > that would be easier for a reader to find than an example buried > inside 2.10, and would allow 2.10 and its neighbours to keep their > existing more reference-style flavour. Yes! For more feedback, I've also been asked whether instead of the number of applications I could give the number of time. (Like in petite scheme "(time (some-evaluation))"). > Also, I'm still not quite clear what you mean by profiling. Which of > the examples that we've discussed best fits what you have in mind? The trace-trap example you gave last might fit closest. Just as a last addendum, I've run into a garbage-collection segfault with the combination minlog 4.0/guile-core.unstable-20060105/ guile-debugging-0.12/i686 GNU/Linux 2.6.14 #4. (gdb) file /usr/local/bin/guile (gdb) run guile> (use-modules (ossau breakpoints) (ossau trace)) guile> (debug-set! stack 0) guile> (debug-set! depth 0) guile> (debug-set! maxdepth 0) guile> (debug-set! indent 0) guile> (debug-set! width 0) guile> (set-trace-layout "~20@a: ~a\n" trace/source trace/info) guile> (break-in 'set-goal #:behaviour (list trace-trap trace-until-exit)) guile> (load "examples/analysis/extraction.scm.guile") Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211029280 (LWP 24947)] 0xb7f424d5 in scm_gc_mark (ptr=0xb6fb8490) at gc-mark.c:160 160 { 0xb7f36538 in scm_gc_mark (ptr=Variable "ptr" is not available. ) at gc-mark.c:168 168 scm_gc_mark_dependencies (ptr); #0 0xb7f36538 in scm_gc_mark (ptr=Variable "ptr" is not available. ) at gc-mark.c:168 #1 0xb7f363e9 in scm_gc_mark_dependencies (p=0xb6085db0) at gc-mark.c:270 #2 0xb7f3653d in scm_gc_mark (ptr=Variable "ptr" is not available. ) at gc-mark.c:168 ... Remarkably, one then can segfault gdb too by asking it via "bc -10" to spit out the ten outer 10 stack frames. #149734 0xb7f70a19 in scm_shell (argc=1, argv=0xbfbd7cd4) at script.c:737 #149735 0xb7f51515 in invoke_main_func (body_data=0xbfbd7c04) at init.c:367 #149736 0xb7f25040 in c_body (d=0xbfbd7b78) at continuations.c:359 #149737 0xb7f91106 in scm_internal_catch (tag=0x104, body=0xb7f25030 , body_data=0xbfbd7b78, handler=0xb7f25050 , handler_data=0xbfbd7b78) at throw.c:173 #149738 0xb7f2500d in scm_i_with_continuation_barrier ( body=0xb7f25030 , body_data=0xbfbd7b78, handler=0xb7f25050 , handler_data=0xbfbd7b78) at continuations.c:336 Program received signal SIGSEGV, Segmentation fault. 0x08152319 in dwarf2_frame_cache (next_frame=0xfcf0698, this_cache=0xfcf0ae8) at dwarf2-frame.c:637 (Info of last line of course comes from running "minlog from guile from gdb from gdb".) I then tried to find an easier test case to reproduce this (without the theorem prover context), but (define (rec n) (case n ((1) 1) (else (rec (- n 1))))) does *not* break guile even on things like (rec 1000000) where presumably a million of frames is on the stack(?, if not how does one turn off tail recursion optimizations and the like) ... :( Cheers, -- Holger Blasum +49-174-7313590 (gsm) GnuPG 1024D/ACDFC3B769DC1ED66B47 "It has turned out that the networking of many small computers, at many places, is more efficient than the one supercomputer - the success of the internet is based on this principle." - Angela Merkel, government declaration, 30 Nov 2005