lazy-handler-dispatch and debug-on-error

lazy-handler-dispatch and debug-on-error

[Neil Jerram]

Is there any reason why the lazy-catch around the main REPL loop in
boot-9.scm could not be changed from 

	      (lazy-catch #t
			  (lambda () <REPL>)
			  lazy-handler-dispatch)
to
	      (lazy-catch #t
			  (lambda () <REPL>)
			  (lambda args
			    (apply lazy-handler-dispatch args)))
?

The difference is that with this change, if code executed inside
<REPL> set!s lazy-handler-dispatch to a new definition, the new
definition takes effect on the first throw from the lazy catch.
Whereas without the change it only takes effect on a throw from the
next time that the lazy catch is entered.

I'm currently interested in this because it's a way of supporting some
debug-on-error function for code executed in the Guile REPL - see
debug-on-error in debugger.scm for details.  It's not a good way of
doing debug-on-error, as it doesn't help with script (guile -s) code
or with any throws that are caught by an inner catch.  But it's the
only mechanism currently available, I believe.

Thanks,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Is there any reason why the lazy-catch around the main REPL loop in
> boot-9.scm could not be changed [...]

I dont see any.  Having a comment somewhere that explains that <REPL>
is allowed to modify lazy-handler-dispatch would be good, of course.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.de> writes:

    Marius> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> Is there any reason why the lazy-catch around the main REPL loop in
    >> boot-9.scm could not be changed [...]

    Marius> I dont see any.  Having a comment somewhere that explains
    Marius> that <REPL> is allowed to modify lazy-handler-dispatch
    Marius> would be good, of course.

Does the following look OK?

				  ;; Use a closure here rather than
				  ;; just `lazy-handler-dispatch' so
				  ;; that lookup of
				  ;; lazy-handler-dispatch's value is
				  ;; deferred until a throw occurs.
				  ;; This means that if code executed
				  ;; in the REPL just above set!s
				  ;; lazy-handler-dispatch, the new
				  ;; value will be used to handle the
				  ;; next throw from the REPL.
				  (lambda args
				    (apply lazy-handler-dispatch args))))

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Does the following look OK?

Yes! :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Paul Jarc]

Neil Jerram <neil@ossau.uklinux.net> wrote:
> Is there any reason why the lazy-catch around the main REPL loop in
> boot-9.scm could not be changed from
>
> 	      (lazy-catch #t
> 			  (lambda () <REPL>)
> 			  lazy-handler-dispatch)
> to
> 	      (lazy-catch #t
> 			  (lambda () <REPL>)
> 			  (lambda args
> 			    (apply lazy-handler-dispatch args)))
> ?

FWIW, the definition of lazy-handler-distpatch itself already looks a
lot like that lambda.  It appears that you can set
default-lazy-handler inside the REPL to get the desired effect.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Neil Jerram]

>>>>> "Paul" == Paul Jarc <prj@po.cwru.edu> writes:

    Paul> FWIW, the definition of lazy-handler-distpatch itself
    Paul> already looks a lot like that lambda.  It appears that you
    Paul> can set default-lazy-handler inside the REPL to get the
    Paul> desired effect.

Yes, that's what I did before.  But that required a new variable
`default-default-lazy-handler', which set me wondering what the
original design was.

1. lazy-handler-dispatch set!able, with
   default-lazy-handler holding the default value
   (with a minor coding error in the REPL code)

Or...

2. lazy-handler-dispatch fixed
   default-lazy-handler set!able, with
   (non-existent) default-default-lazy-handler holding the default
   value

I thought that 1 was more likely.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Mikael Djurfeldt]

Neil Jerram <neil@ossau.uklinux.net> writes:

>>>>>> "Paul" == Paul Jarc <prj@po.cwru.edu> writes:
>
>     Paul> FWIW, the definition of lazy-handler-distpatch itself
>     Paul> already looks a lot like that lambda.  It appears that you
>     Paul> can set default-lazy-handler inside the REPL to get the
>     Paul> desired effect.
>
> Yes, that's what I did before.  But that required a new variable
> `default-default-lazy-handler', which set me wondering what the
> original design was.

The original design might have had something to do with being able to
cut the stack at a proper level in order to get a nice backtrace
printout.  But this should have been solved later by the introduction
of start-stack.  (You still might want to check that stack cutting
works after your change.)

M



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Neil Jerram]

>>>>> "Mikael" == Mikael Djurfeldt <mdj@mit.edu> writes:

    Mikael> The original design might have had something to do with
    Mikael> being able to cut the stack at a proper level in order to
    Mikael> get a nice backtrace printout.  But this should have been
    Mikael> solved later by the introduction of start-stack.  (You
    Mikael> still might want to check that stack cutting works after
    Mikael> your change.)

Yes, I think I might have unintentionally broken this.  I'll
investigate ...

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: lazy-handler-dispatch and debug-on-error

[Neil Jerram]

>>>>> "Neil" == Neil Jerram <neil@ossau.uklinux.net> writes:

>>>>> "Mikael" == Mikael Djurfeldt <mdj@mit.edu> writes:
    Mikael> The original design might have had something to do with
    Mikael> being able to cut the stack at a proper level in order to
    Mikael> get a nice backtrace printout.  But this should have been
    Mikael> solved later by the introduction of start-stack.  (You
    Mikael> still might want to check that stack cutting works after
    Mikael> your change.)

    Neil> Yes, I think I might have unintentionally broken this.  I'll
    Neil> investigate ...

Yes, you're quite right; my change did break this.  I've undone that
change and added the following comment.

		  ;; Note that having just
		  ;; `lazy-handler-dispatch' here is
		  ;; connected with the mechanism that
		  ;; produces a nice backtrace upon
		  ;; error.  If, for example, this is
		  ;; replaced with (lambda args (apply
		  ;; lazy-handler-dispatch args)), the
		  ;; stack cutting (in save-stack)
		  ;; goes wrong and ends up saving no
		  ;; stack at all, so there is no
		  ;; backtrace.
		  lazy-handler-dispatch))

(As far as debug-on-error is concerned, I don't now think this is a
good way to implement it anyway.)

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel