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