unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Entering the interactive debugger
@ 2014-09-02 19:03 Carlos Pita
  2014-09-02 19:20 ` Thompson, David
  0 siblings, 1 reply; 6+ messages in thread
From: Carlos Pita @ 2014-09-02 19:03 UTC (permalink / raw
  To: guile-user

Hi all, although I have some experience with lisps, I'm still new to
guile and I'm having some trouble figuring out how to invoke the
interactive debugger at some arbitrary point in my code. Something like:

	; code here
	(debug)
	; more code here

The closer solution I could find in the manual is:

	add-trap-at-source-location! file user-line

Any suggestion?

Thank you in advance

Cheers
--
Carlos






^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Entering the interactive debugger
  2014-09-02 19:03 Entering the interactive debugger Carlos Pita
@ 2014-09-02 19:20 ` Thompson, David
  2014-09-02 19:57   ` Thompson, David
  2014-09-02 20:14   ` Taylan Ulrich Bayirli/Kammer
  0 siblings, 2 replies; 6+ messages in thread
From: Thompson, David @ 2014-09-02 19:20 UTC (permalink / raw
  To: Carlos Pita; +Cc: Guile User

On Tue, Sep 2, 2014 at 3:03 PM, Carlos Pita <carlosjosepita@gmail.com> wrote:
> Hi all, although I have some experience with lisps, I'm still new to
> guile and I'm having some trouble figuring out how to invoke the
> interactive debugger at some arbitrary point in my code. Something like:
>
>         ; code here
>         (debug)
>         ; more code here
>
> The closer solution I could find in the manual is:
>
>         add-trap-at-source-location! file user-line
>
> Any suggestion?

I don't know of any straightforward solution, but I would also like
such a feature.  I don't think it would be too difficult to write a
'debug' procedure using the 'debug-trap-handler' procedure in (system
repl error-handling) as inspiration.  Basically, you'd need to capture
the current stack and spawn a new REPL in debug mode that uses that
stack.

Additionally, I noticed that the (system repl debug) module has this
at the bottom of the file:

;; (define (debug)
;;   (run-debugger
;;    (narrow-stack->vector
;;     (make-stack #t)
;;     ;; Narrow the `make-stack' frame and the `debug' frame
;;     2
;;     ;; Narrow the end of the stack to the most recent start-stack.
;;     (and (pair? (fluid-ref %stacks))
;;          (cdar (fluid-ref %stacks))))))

I'm guess it no longer functions, but maybe it will help you!

- Dave



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Entering the interactive debugger
  2014-09-02 19:20 ` Thompson, David
@ 2014-09-02 19:57   ` Thompson, David
  2014-09-02 20:14   ` Taylan Ulrich Bayirli/Kammer
  1 sibling, 0 replies; 6+ messages in thread
From: Thompson, David @ 2014-09-02 19:57 UTC (permalink / raw
  To: Carlos Pita; +Cc: Guile User

On Tue, Sep 2, 2014 at 3:20 PM, Thompson, David
<dthompson2@worcester.edu> wrote:
> On Tue, Sep 2, 2014 at 3:03 PM, Carlos Pita <carlosjosepita@gmail.com> wrote:
>> Hi all, although I have some experience with lisps, I'm still new to
>> guile and I'm having some trouble figuring out how to invoke the
>> interactive debugger at some arbitrary point in my code. Something like:
>>
>>         ; code here
>>         (debug)
>>         ; more code here
>>
>> The closer solution I could find in the manual is:
>>
>>         add-trap-at-source-location! file user-line
>>
>> Any suggestion?
>
> I don't know of any straightforward solution, but I would also like
> such a feature.  I don't think it would be too difficult to write a
> 'debug' procedure using the 'debug-trap-handler' procedure in (system
> repl error-handling) as inspiration.  Basically, you'd need to capture
> the current stack and spawn a new REPL in debug mode that uses that
> stack.
>

The stack isn't properly narrowed because I couldn't figure out how to
make narrow-stack->vector do what I wanted, but here's a 'debug'
procedure that worked for me.

(use-modules (system repl repl)
             (system repl debug))

(define (debug)
  (let ((stack (narrow-stack->vector (make-stack #t))))
    (start-repl #:debug (make-debug stack 0 "Entered debugger" #f))))

- Dave



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Entering the interactive debugger
  2014-09-02 19:20 ` Thompson, David
  2014-09-02 19:57   ` Thompson, David
@ 2014-09-02 20:14   ` Taylan Ulrich Bayirli/Kammer
  2014-09-03  2:08     ` Carlos Pita
  1 sibling, 1 reply; 6+ messages in thread
From: Taylan Ulrich Bayirli/Kammer @ 2014-09-02 20:14 UTC (permalink / raw
  To: Thompson, David; +Cc: Carlos Pita, Guile User

"Thompson, David" <dthompson2@worcester.edu> writes:

> On Tue, Sep 2, 2014 at 3:03 PM, Carlos Pita <carlosjosepita@gmail.com> wrote:
>> Hi all, although I have some experience with lisps, I'm still new to
>> guile and I'm having some trouble figuring out how to invoke the
>> interactive debugger at some arbitrary point in my code. Something like:
>>
>>         ; code here
>>         (debug)
>>         ; more code here
>>
>> The closer solution I could find in the manual is:
>>
>>         add-trap-at-source-location! file user-line
>>
>> Any suggestion?
>
> I don't know of any straightforward solution, but I would also like
> such a feature.  I don't think it would be too difficult to write a
> 'debug' procedure using the 'debug-trap-handler' procedure in (system
> repl error-handling) as inspiration.  Basically, you'd need to capture
> the current stack and spawn a new REPL in debug mode that uses that
> stack.

Couldn't you just use (error)?  It will enter the debugger if run from
the REPL or otherwise when debugging is enabled on the VM or so (I don't
know the details), though it will abort if run stand-alone; not sure if
that's enough for your purposes.

Taylan



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Entering the interactive debugger
  2014-09-02 20:14   ` Taylan Ulrich Bayirli/Kammer
@ 2014-09-03  2:08     ` Carlos Pita
  2014-09-05 13:57       ` mhw
  0 siblings, 1 reply; 6+ messages in thread
From: Carlos Pita @ 2014-09-03  2:08 UTC (permalink / raw
  To: Taylan Ulrich Bayirli/Kammer; +Cc: Guile User, Thompson, David

Thank you very much, Dave!

> Couldn't you just use (error)?  It will enter the debugger if run from

I'm doing exactly that, but then there is the limitation that this
would be postmortem debugging and sometimes I want to suspend
execution, examine the environment, and *resume* execution.

Cheers
--
Carlos



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Entering the interactive debugger
  2014-09-03  2:08     ` Carlos Pita
@ 2014-09-05 13:57       ` mhw
  0 siblings, 0 replies; 6+ messages in thread
From: mhw @ 2014-09-05 13:57 UTC (permalink / raw
  To: Carlos Pita; +Cc: guile-user

Carlos Pita <carlosjosepita@gmail.com> writes:

> Thank you very much, Dave!
>
>> Couldn't you just use (error)?  It will enter the debugger if run from
>
> I'm doing exactly that, but then there is the limitation that this
> would be postmortem debugging and sometimes I want to suspend
> execution, examine the environment, and *resume* execution.

You can set breakpoints using the ",break" or ",break-at-source" REPL
commands.  See ",help debug" for more info.

For now, to achieve the effect you desire, you could create a procedure
that simply returns the value of some global variable.  Set a breakpoint
on that procedure, and then use that procedure as your "enter debugger"
procedure.  If you want it to resume execution, set the global to your
desired value and continue.

I agree that it would be nice to include a procedure in Guile that does
this more nicely.

      Mark



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-09-05 13:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-02 19:03 Entering the interactive debugger Carlos Pita
2014-09-02 19:20 ` Thompson, David
2014-09-02 19:57   ` Thompson, David
2014-09-02 20:14   ` Taylan Ulrich Bayirli/Kammer
2014-09-03  2:08     ` Carlos Pita
2014-09-05 13:57       ` mhw

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).