Christian,
You're quite correct. It would appear that the final act in the continuation is to load the file. Hence the recursive loop. Can't say why though. Maybe a bug perhaps?
Nick Walton
On 11 Jun 2008, at 10:56, Cristian Baboi wrote:
On Wed, 11 Jun 2008 12:50:36 +0300, Nicholas Walton nwalton@mac.com wrote:
I think you've had finger slip somewhere, when I ran the example the results where as expected
I don't know what is expected. If you run the whole file from gambit-c, you'll get what I wrote. If you omit the last line from the file and enter it at the prompt, you don't get the loop. However, the question was about the different results in plt-scheme and gambit-c. I don't know which one is wrong.
Gambit v4.2.2
(define (call/ccc x) (call-with-current-continuation x))
(define coco 1)
(begin (display "begin") (newline) (call/ccc (lambda (c) (set! coco c))) (display "again") (newline) (display "end") (newline) ) begin again end
(coco 13) again end
Nick Walton
________ Information from NOD32 ________ This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com
Afficher les réponses par date
Christian,
You're quite correct. It would appear that the final act in the continuation is to load the file. Hence the recursive loop. Can't say why though. Maybe a bug perhaps?
Nick Walton
I tryed this:
(define (call/ccc x) (call-with-current-continuation x))
(define coco 1) (define (run) (begin (display "begin") (newline) (call/ccc (lambda (c) (set! coco c))) (display "again") (newline) (display "end") (newline) ) )
(run) (coco 13)
and this time I've got: - mzscheme: begin again end again end
- gambit-c: begin again end again end again end again end again end ....
________ Information from NOD32 ________ This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com
Here's an update on the gambit debugging in Eclipse. I'm using DBGp (a debug protocol) and DLTK - the Dynamic Languages Toolkit for Eclipse. It uses a TCP connection to connect to Eclipse, and it should support threads too. Its a little odd, but each thread has to manage its own debug connection.
I have a working stack trace showing up in Eclipse. Now I just need to figure out how best to hook in Gambit so that whenever REPL is called form an exception, step or interrupt, that it will call my "dbgp-repl" instead of the standard one.
I've been using it a little, and it is *wonderful* being able to just inspect stack frames and inside closures with a few clicks, rather than having to type stuff over and over again into the repl. More fancy tracing will also be possible. I keep reading this stuff about how Scheme doesn't need a debugger... and I just don't get it. I think everybody has just gotten used to not having one. A real debugger is going to be great.
Anyway, I really need some *advice*. I'd like to just hook into an existing Gambit install, without having to make a custom build. If this is not possible, I can make a custom build.
I am not sure if I can just redefine ##repl, that doesn't seem to work anyway. Any ideas?
William
More progess on Eclipse/Gambit debug:
I modified the gambit sources to create a hook allowing me to replace ##repl-within. This works pretty well (works great for hitting (step) calls in the code), but I can't get real stepping (analogous to ,s and ,l) to work. As expected, it is stepping into my debug monitor code, rather than stepping through the program being debugged. I can't tell how the stepper decides what code to step or not step.. its pretty complicated.
Any hints?
William
William Cook wrote:
Here's an update on the gambit debugging in Eclipse. I'm using DBGp (a debug protocol) and DLTK - the Dynamic Languages Toolkit for Eclipse. It uses a TCP connection to connect to Eclipse, and it should support threads too. Its a little odd, but each thread has to manage its own debug connection.
I have a working stack trace showing up in Eclipse. Now I just need to figure out how best to hook in Gambit so that whenever REPL is called form an exception, step or interrupt, that it will call my "dbgp-repl" instead of the standard one.
I've been using it a little, and it is *wonderful* being able to just inspect stack frames and inside closures with a few clicks, rather than having to type stuff over and over again into the repl. More fancy tracing will also be possible. I keep reading this stuff about how Scheme doesn't need a debugger... and I just don't get it. I think everybody has just gotten used to not having one. A real debugger is going to be great.
Anyway, I really need some *advice*. I'd like to just hook into an existing Gambit install, without having to make a custom build. If this is not possible, I can make a custom build.
I am not sure if I can just redefine ##repl, that doesn't seem to work anyway. Any ideas?
William
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
I don't have time for a long explanation, but I can say this... make sure all your new code (for your debugger) is compiled. Otherwise stepping will actually step into the new code.
Marc
On 16-Jun-08, at 11:10 PM, William Cook wrote:
More progess on Eclipse/Gambit debug:
I modified the gambit sources to create a hook allowing me to replace ##repl-within. This works pretty well (works great for hitting (step) calls in the code), but I can't get real stepping (analogous to ,s and ,l) to work. As expected, it is stepping into my debug monitor code, rather than stepping through the program being debugged. I can't tell how the stepper decides what code to step or not step.. its pretty complicated.
Any hints?
William
-
Cristian Baboi -
Marc Feeley -
Nicholas Walton -
William Cook