[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Stack traces,
Catonano <=