guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stack traces


From: Catonano
Subject: Re: Stack traces
Date: Sat, 10 Jun 2017 11:58:23 +0200

2017-05-18 15:38 GMT+02:00 Christopher Allan Webber <address@hidden>
:

> Amirouche writes:
>
> > Le 27/02/2017 à 21:23, Andy Wingo a écrit :
> >> On Sat 18 Feb 2017 20:59, Amirouche <address@hidden> writes:
> >>
> >>> How do you access variables in the REPL?
> >> ,locals
> >>
> >> Andy
> > It doesn't display something that I can use.
>
> (Returning to this few-months-old thread...)
>
> Yes, I frequently find that ,locals does not display much
> information... it seems to be a toss-up whether the variables I need
> will be contained in it, so I've reduced the amount I use the actual
> debugger system in Guile a lot.  A shame, because it seems really nice.
>
> Because of this, I think I do what a lot of Guile hackers do (which is
> totally undocumented in the manual, so only people who have been hanging
> around with someoen else who knows tend to know about it), which is to
> use (pk) everywhere.  It's not as nice as being able to play with local
> variables at the REPL though!
>
> Matt's example from earlier in the thread seems simple enough... as a
> recap:
>
> (use-modules (system repl repl))
> (use-modules (system repl debug))
>
> (define-syntax-rule (trap-here)
>   (start-repl
>    #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)))
>
> (define (foo)
>   (let iter ((sum 0) (vals '(1 2 3 5 8 2)))
>     (trap-here)
>     (if (null? vals) sum
>         (iter (+ sum (car vals)) (cdr vals)))))
>
> (foo)
>
> Looking at that, I would *think* that at minimum, sum and vals would be
> available when I run ,locals.  I couldn't understand why they weren't:
>
> scheme@(guile-user)> (foo)
> scheme@(guile-user) [1]> ,locals
>   No local variables.
>
> But then I ran ,optimize, and that made it obvious what's happening:
>
> (define (foo)
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   (start-repl
>     #:debug
>     (make-debug
>       (stack->vector (make-stack #t))
>       0
>       "trap!"
>       #t))
>   21)
>
> Ah... the compiler was being so smart that it did all the work up front
> already! ;) Pretty cool from a performance and optimization perspective
> (I'm still floored that Guile is able to do optimizations like that!),
> but it's not as helpful from a debugging perspective maybe?
>
> Maybe there could be a way to do something like this:
>
> scheme@(guile-user)> ,optimize-less
> ;;; * user re-evaluates code they want to debug *
> scheme@(guile-user)> (foo)
> scheme@(guile-user) [1]> ,locals
>   Local variables:
>   $23 = sum = 0
>   $24 = vals = '(1 2 3 5 8 2)
> scheme@(guile-user) [1]> ,q
> ;;; User has done debugging
> scheme@(guile-user)> ,optimize-more
> ;;; User can now re-evaluate their code with all the optimizations in
> ;;; place!
> scheme@(guile-user)>
>
> Thoughts?
>  - Chris
>
>

This is an extremely informative message, per se. Precious insights

Thanks


reply via email to

[Prev in Thread] Current Thread [Next in Thread]