Re: Stack traces

[Catonano]

2017-05-18 15:38 GMT+02:00 Christopher Allan Webber 
:

> Amirouche writes:
>
> > Le 27/02/2017 à 21:23, Andy Wingo a écrit :
> >> On Sat 18 Feb 2017 20:59, Amirouche  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

Re: Stack traces

[Andy Wingo]

On Thu 18 May 2017 15:38, Christopher Allan Webber  
writes:

> 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.

This is related to the "basic register allocation" task from
https://wingolog.org/archives/2016/02/04/guile-compiler-tasks.

> But then I ran ,optimize, and that made it obvious what's happening:

Ah, yes you might also have to disable partial evaluation.  Note that
,optimize basically runs only partial evaluation and not the other
phases of the compiler.

> scheme@(guile-user)> ,optimize-less
> scheme@(guile-user)> ,optimize-more

Not a bad idea :)  Probably should use the same mechanism as "guild
compile"'s -O0, -O1, -O2 etc logic.

Andy

Re: Stack traces

[Matt Wette]

> On May 18, 2017, at 6:38 AM, Christopher Allan Webber 
>  wrote:
> 
> Amirouche writes:
> 
>> Le 27/02/2017 à 21:23, Andy Wingo a écrit :
>>> On Sat 18 Feb 2017 20:59, Amirouche  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!

> 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

Thanks for the insight.  That explains a lot.

Matt

Re: Stack traces

[Christopher Allan Webber]

Amirouche writes:

> Le 27/02/2017 à 21:23, Andy Wingo a écrit :
>> On Sat 18 Feb 2017 20:59, Amirouche  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

Re: Stack traces

[Amirouche]

Le 27/02/2017 à 21:23, Andy Wingo a écrit :

On Sat 18 Feb 2017 20:59, Amirouche  writes:


How do you access variables in the REPL?

,locals

Andy

It doesn't display something that I can use.

Re: Stack traces

[Matt Wette]

> On Feb 18, 2017, at 11:59 AM, Amirouche  wrote:
> How do you access variables in the REPL?

To be determined.  Just starting, and I’m guessing this part is going to be 
nontrivial: some may optimized away, some (e.g., those set!) are boxed, etc.

Re: Stack traces

[Amirouche]

Le 18/02/2017 à 17:58, Matt Wette a écrit :

On Feb 18, 2017, at 7:53 AM, Amirouche  wrote:
Le 18/02/2017 à 16:50, Amirouche a écrit :

Le 18/02/2017 à 01:13, Matt Wette a écrit :

(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)

It looks like that. Except `iter` should be defined in the namespace of the 
REPL.

Maybe iter is complicated, but at least sum and vals.

Hmm.   The procedure “foo” without the "(trap-here)” is just a simple program 
(using named let) that I want to debug.
So I add the “(trap-here)” to get into the debugger at that spot in the 
program, like I would add “pdb.set_trace()” in python.

Matt



How do you access variables in the REPL?

Re: Stack traces

[Amirouche]

Le 18/02/2017 à 16:50, Amirouche a écrit :



Le 18/02/2017 à 01:13, Matt Wette a écrit :

(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)
It looks like that. Except `iter` should be defined in the namespace 
of the REPL.





Maybe iter is complicated, but at least sum and vals.

Re: Stack traces

[Amirouche]

Le 18/02/2017 à 01:13, Matt Wette a écrit :

(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)
It looks like that. Except `iter` should be defined in the namespace of 
the REPL.

Re: Stack traces

[Matt Wette]

> On Feb 15, 2017, at 7:36 AM, Christopher Allan Webber 
>  wrote:
> 
> One thing that we see requested a lot is how to do the equivalent of:
> 
>  import pdb
>  pdb.set_trace()
> 
> in python, just dumping something to "trigger" the debugger somewhere.
> I seem to remember getting some arcane code to do something similar, but
> maybe we can just have a simple invocation that people could put
> anywhere.  (Amirouche has been raising this one also I think.)
> 

I am playing with this.  It does dump me into the debugger but the interaction 
is not wonderful (like pdb.set_trace()). 
However, this is context for working in that direction (i.e., pdb.set_trace()):

mwette$ cat trapper.scm 
(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)

mwette$ guile
GNU Guile 2.0.13
[…]
scheme@(guile-user)> (load "trapper.scm")
[…]
scheme@(guile-user) [1]> ,bt
[…]
In /Users/mwette/proj/scheme/myproj/potluck/trapper.scm:
 10:4  1 (foo)
In unknown file:
   0 (make-stack #t)
scheme@(guile-user) [1]> 

Re: Stack traces

[Matt Wette]

> On Feb 15, 2017, at 7:36 AM, Christopher Allan Webber 
>  wrote:
> 
> One thing that we see requested a lot is how to do the equivalent of:
> 
>  import pdb
>  pdb.set_trace()
> 
> in python, just dumping something to "trigger" the debugger somewhere.
> I seem to remember getting some arcane code to do something similar, but
> maybe we can just have a simple invocation that people could put
> anywhere.  (Amirouche has been raising this one also I think.)
> 

^^^This is exactly what I yearn for.  I asked about this before and got the 
following hint, but could not get anything to work.



(use-modules (system repl repl))
(Use-modules (system repl debug))
...
(start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t))

Re: Stack traces

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hello,
>
> Cecil McGregor  skribis:
>
>> My first problem lies in the lack of a decent debugger.
>> (I can hear the screams of more enlightened Guilers
>> already!) The stack traces seldom provide filenames
>> and line numbers to hint where a problem might hide.
>> While I've read advice to allow the appearance of
>> filenames/line numbers, I still can't seem to
>> consistently find these in a stack trace.
>>
>> I would really like the filename/line number to appear
>> in a stack trace with the actual source code and not
>> some partially opaque macro expansion.
>
> Could you mock up the stack trace as you would like to see it displayed?
>
> I think it would be helpful because what you write here is a common
> complaint, but it’s also something that seasoned Guilers no longer
> realize because they’re used to it.  So a fresh eye on what it should
> look like is great.
>
> There are also deeper technical issues, such as tail calls, but we can
> put them aside for now.
>
> Thanks,
> Ludo’.

One thing that we see requested a lot is how to do the equivalent of:

  import pdb
  pdb.set_trace()

in python, just dumping something to "trigger" the debugger somewhere.
I seem to remember getting some arcane code to do something similar, but
maybe we can just have a simple invocation that people could put
anywhere.  (Amirouche has been raising this one also I think.)