* lazy-handler-dispatch and debug-on-error
@ 2003-11-12 23:18 Neil Jerram
2003-11-13 20:51 ` Marius Vollmer
2003-11-17 15:02 ` Paul Jarc
0 siblings, 2 replies; 9+ messages in thread
From: Neil Jerram @ 2003-11-12 23:18 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: lazy-handler-dispatch and debug-on-error
2003-11-12 23:18 lazy-handler-dispatch and debug-on-error Neil Jerram
@ 2003-11-13 20:51 ` Marius Vollmer
2003-11-14 21:11 ` Neil Jerram
2003-11-17 15:02 ` Paul Jarc
1 sibling, 1 reply; 9+ messages in thread
From: Marius Vollmer @ 2003-11-13 20:51 UTC (permalink / raw)
Cc: Guile Development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: lazy-handler-dispatch and debug-on-error
2003-11-13 20:51 ` Marius Vollmer
@ 2003-11-14 21:11 ` Neil Jerram
2003-11-15 0:55 ` Marius Vollmer
0 siblings, 1 reply; 9+ messages in thread
From: Neil Jerram @ 2003-11-14 21:11 UTC (permalink / raw)
Cc: Guile Development
>>>>> "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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: lazy-handler-dispatch and debug-on-error
2003-11-12 23:18 lazy-handler-dispatch and debug-on-error Neil Jerram
2003-11-13 20:51 ` Marius Vollmer
@ 2003-11-17 15:02 ` Paul Jarc
2003-11-17 21:13 ` Neil Jerram
1 sibling, 1 reply; 9+ messages in thread
From: Paul Jarc @ 2003-11-17 15:02 UTC (permalink / raw)
Cc: Guile Development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: lazy-handler-dispatch and debug-on-error
2003-11-17 15:02 ` Paul Jarc
@ 2003-11-17 21:13 ` Neil Jerram
2003-11-26 17:27 ` Mikael Djurfeldt
0 siblings, 1 reply; 9+ messages in thread
From: Neil Jerram @ 2003-11-17 21:13 UTC (permalink / raw)
>>>>> "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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: lazy-handler-dispatch and debug-on-error
2003-11-17 21:13 ` Neil Jerram
@ 2003-11-26 17:27 ` Mikael Djurfeldt
2003-11-27 21:03 ` Neil Jerram
0 siblings, 1 reply; 9+ messages in thread
From: Mikael Djurfeldt @ 2003-11-26 17:27 UTC (permalink / raw)
Cc: djurfeldt, Guile Development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: lazy-handler-dispatch and debug-on-error
2003-11-26 17:27 ` Mikael Djurfeldt
@ 2003-11-27 21:03 ` Neil Jerram
2003-12-06 11:57 ` Neil Jerram
0 siblings, 1 reply; 9+ messages in thread
From: Neil Jerram @ 2003-11-27 21:03 UTC (permalink / raw)
Cc: Guile Development
>>>>> "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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: lazy-handler-dispatch and debug-on-error
2003-11-27 21:03 ` Neil Jerram
@ 2003-12-06 11:57 ` Neil Jerram
0 siblings, 0 replies; 9+ messages in thread
From: Neil Jerram @ 2003-12-06 11:57 UTC (permalink / raw)
Cc: Guile Development
>>>>> "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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-12-06 11:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-12 23:18 lazy-handler-dispatch and debug-on-error Neil Jerram
2003-11-13 20:51 ` Marius Vollmer
2003-11-14 21:11 ` Neil Jerram
2003-11-15 0:55 ` Marius Vollmer
2003-11-17 15:02 ` Paul Jarc
2003-11-17 21:13 ` Neil Jerram
2003-11-26 17:27 ` Mikael Djurfeldt
2003-11-27 21:03 ` Neil Jerram
2003-12-06 11:57 ` Neil Jerram
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).