Please see typescript (sorry, copy/paste not working in X right now)
i have test.scm, which forks off a thread (<thread #2>) which forever does: (pp 'yay); so I can see it print (+ "asdf" 1) ; just to generate an error
I'm running gsc with -:dar, so i want debugging support, for all threads, and get thrown into a REPL when an error occurs.
Here are my questions:
1) in my primordial thread, why do I have to execute some command (like "(void)") before I get thrown into the REPL in thread2? if everything is running concurrently, why does the error in thread2 not pop up immediately and get me thrown into a REPL?
2) in thread 2, after hitting ,(c 0) ... why don' i immediately get an "yay"? (if it's continuing from that error, it should jump back to the (pp 'yay))
3) after printing said 'yay', why do I have to hit (void) in the thread #1 before getting the error repl in thread 2? why doesn't the error immediately happen
4) it seems like i'm ping-ponging between the two threads on the REPL. Is there anyway I can control this myself? (i.e. some command to jump me to thread1, some to jump me to thread2?)
Thanks!
Afficher les réponses par date
On 20-May-09, at 12:03 AM, lowly coder wrote:
Please see typescript (sorry, copy/paste not working in X right now)
i have test.scm, which forks off a thread (<thread #2>) which forever does: (pp 'yay); so I can see it print (+ "asdf" 1) ; just to generate an error
I'm running gsc with -:dar, so i want debugging support, for all threads, and get thrown into a REPL when an error occurs.
Here are my questions:
- in my primordial thread, why do I have to execute some command
(like "(void)") before I get thrown into the REPL in thread2? if everything is running concurrently, why does the error in thread2 not pop up immediately and get me thrown into a REPL?
That's because, by default, the REPL's interaction channel is the console and you have a single console. So all threads interacting with the user (either REPL or calls to pp) are competing to get control of this single console to do their interaction. A thread will acquire the console on entry to the REPL and relinquish the console when an expression is evaluated (most comma commands don't relinquish the console). When the "acquire" operation succeeds and the thread is different from the previous thread that acquired the console, a message is displayed to indicate that the console is servicing the REPL of a different thread.
The error doesn't immediately pop up because the primordial thread is running a REPL, so it has acquired exclusive access to the console.
- in thread 2, after hitting ,(c 0) ... why don' i immediately get
an "yay"? (if it's continuing from that error, it should jump back to the (pp 'yay))
Because the other thread (primordial thread) was waiting to acquire the console, and it acquired it at the moment thread 2 relinquished it.
- after printing said 'yay', why do I have to hit (void) in the
thread #1 before getting the error repl in thread 2? why doesn't the error immediately happen
Same as 2). The console is being multiplexed fairly between the two threads that need to access it.
- it seems like i'm ping-ponging between the two threads on the
REPL. Is there anyway I can control this myself? (i.e. some command to jump me to thread1, some to jump me to thread2?)
You can use the ,(v #2) command to visit thread #2. But that's mainly useful to interrupt a thread in mid execution.
The ideal solution is to use an IDE which can present to the user several independent interaction windows. For example the Jazz IDE (Jedi).
Alternatively, you can try the following "remote-debugging" code (for Unix + X11) which will pop up a new xterm for each REPL. It is meant as a proof of concept, so I'm not sure how much mileage you can get out of it.
Marc
The following problem may be just a reflection of my poor programming abilities, but I'm hope there's a good solution to this: I run $ gsc
(load "server.scm")
-- starts: (thread 2), (thread 3)
; back here at primordial thread
The primordial thread is to let me have an interactive REPL thread 2 does actual work thread 3 listens on socket 8080 for remote commands to execute (this is is how I get vim/emacs to send commands to the repl, stuff like (load "foo.scm")); this command is then executed inside thread 2; (so thread 3 practically never has any exceptions, even when foo.scm doesn't parse properly)
The problem is -- foo.scm often has errors, either syntactical or run time errors.
Thus, thread #2 throws an exception, and I have to deal with it in the primordial thread, typically like
-- thread #1 --
(void)
-- thread #2 -- exception blah blah blah
,(c 0) (void)
-- thread #1 --
Now, here's what I would like -- whenever thread 2 throws an exception, I want thread 3 to get notified, and somehow resume it when a new file gets loaded; however, if I don't load a new file, I want to be able to debug it in the REPL.
Better explained:
thread 2 throws an exception:
choice 1: I go to REPL, type (void) into thread #1, and debug it manually
choice 2: I don't care about the exception, I'm in emacs/vim, I send another (load "foo.scm") into thread 3, and thread 3 tells thread 2 to (a) resume and (b) (load "foo.scm")
Anyone else run into this problem? How did you solve it?
Thanks!
On Wed, May 20, 2009 at 6:29 AM, Marc Feeley feeley@iro.umontreal.cawrote:
On 20-May-09, at 12:03 AM, lowly coder wrote:
Please see typescript (sorry, copy/paste not working in X right now)
i have test.scm, which forks off a thread (<thread #2>) which forever does: (pp 'yay); so I can see it print (+ "asdf" 1) ; just to generate an error
I'm running gsc with -:dar, so i want debugging support, for all threads, and get thrown into a REPL when an error occurs.
Here are my questions:
- in my primordial thread, why do I have to execute some command (like
"(void)") before I get thrown into the REPL in thread2? if everything is running concurrently, why does the error in thread2 not pop up immediately and get me thrown into a REPL?
That's because, by default, the REPL's interaction channel is the console and you have a single console. So all threads interacting with the user (either REPL or calls to pp) are competing to get control of this single console to do their interaction. A thread will acquire the console on entry to the REPL and relinquish the console when an expression is evaluated (most comma commands don't relinquish the console). When the "acquire" operation succeeds and the thread is different from the previous thread that acquired the console, a message is displayed to indicate that the console is servicing the REPL of a different thread.
The error doesn't immediately pop up because the primordial thread is running a REPL, so it has acquired exclusive access to the console.
- in thread 2, after hitting ,(c 0) ... why don' i immediately get an
"yay"? (if it's continuing from that error, it should jump back to the (pp 'yay))
Because the other thread (primordial thread) was waiting to acquire the console, and it acquired it at the moment thread 2 relinquished it.
- after printing said 'yay', why do I have to hit (void) in the thread #1
before getting the error repl in thread 2? why doesn't the error immediately happen
Same as 2). The console is being multiplexed fairly between the two threads that need to access it.
- it seems like i'm ping-ponging between the two threads on the REPL. Is
there anyway I can control this myself? (i.e. some command to jump me to thread1, some to jump me to thread2?)
You can use the ,(v #2) command to visit thread #2. But that's mainly useful to interrupt a thread in mid execution.
The ideal solution is to use an IDE which can present to the user several independent interaction windows. For example the Jazz IDE (Jedi).
Alternatively, you can try the following "remote-debugging" code (for Unix
- X11) which will pop up a new xterm for each REPL. It is meant as a proof
of concept, so I'm not sure how much mileage you can get out of it.
Marc
When I run this code,
xterm 1 & 2 don't show any errors xterm 3 is just _blank_; it doesn't show the gsi prompt; suggestions for what may be wrong?
Thanks!
On Wed, May 20, 2009 at 6:29 AM, Marc Feeley feeley@iro.umontreal.cawrote:
On 20-May-09, at 12:03 AM, lowly coder wrote:
Please see typescript (sorry, copy/paste not working in X right now)
i have test.scm, which forks off a thread (<thread #2>) which forever does: (pp 'yay); so I can see it print (+ "asdf" 1) ; just to generate an error
I'm running gsc with -:dar, so i want debugging support, for all threads, and get thrown into a REPL when an error occurs.
Here are my questions:
- in my primordial thread, why do I have to execute some command (like
"(void)") before I get thrown into the REPL in thread2? if everything is running concurrently, why does the error in thread2 not pop up immediately and get me thrown into a REPL?
That's because, by default, the REPL's interaction channel is the console and you have a single console. So all threads interacting with the user (either REPL or calls to pp) are competing to get control of this single console to do their interaction. A thread will acquire the console on entry to the REPL and relinquish the console when an expression is evaluated (most comma commands don't relinquish the console). When the "acquire" operation succeeds and the thread is different from the previous thread that acquired the console, a message is displayed to indicate that the console is servicing the REPL of a different thread.
The error doesn't immediately pop up because the primordial thread is running a REPL, so it has acquired exclusive access to the console.
- in thread 2, after hitting ,(c 0) ... why don' i immediately get an
"yay"? (if it's continuing from that error, it should jump back to the (pp 'yay))
Because the other thread (primordial thread) was waiting to acquire the console, and it acquired it at the moment thread 2 relinquished it.
- after printing said 'yay', why do I have to hit (void) in the thread #1
before getting the error repl in thread 2? why doesn't the error immediately happen
Same as 2). The console is being multiplexed fairly between the two threads that need to access it.
- it seems like i'm ping-ponging between the two threads on the REPL. Is
there anyway I can control this myself? (i.e. some command to jump me to thread1, some to jump me to thread2?)
You can use the ,(v #2) command to visit thread #2. But that's mainly useful to interrupt a thread in mid execution.
The ideal solution is to use an IDE which can present to the user several independent interaction windows. For example the Jazz IDE (Jedi).
Alternatively, you can try the following "remote-debugging" code (for Unix
- X11) which will pop up a new xterm for each REPL. It is meant as a proof
of concept, so I'm not sure how much mileage you can get out of it.
Marc
On 17-Jun-09, at 12:19 AM, lowly coder wrote:
When I run this code,
xterm 1 & 2 don't show any errors xterm 3 is just _blank_; it doesn't show the gsi prompt; suggestions for what may be wrong?
Thanks!
Please add some context:
1) On what OS? (give the output of: uname -a) 2) Using which version of Gambit (give the output of: gsi -v)
Did you try the example from the remote-debugger.tar.gz code? How did you adapt it to your application?
Marc
~$ uname -a Linux x 2.6.27-7-generic #1 SMP Fri Oct 24 06:40:41 UTC 2008 x86_64 GNU/Linux
~$ gsi -v v4.4.2 20090315000833 x86_64-unknown-linux-gnu
(Ubuntu Linux)
I didn't make any changes ... I just followed the README file.
On Wed, Jun 17, 2009 at 6:31 AM, Marc Feeley feeley@iro.umontreal.cawrote:
On 17-Jun-09, at 12:19 AM, lowly coder wrote:
When I run this code,
xterm 1 & 2 don't show any errors xterm 3 is just _blank_; it doesn't show the gsi prompt; suggestions for what may be wrong?
Thanks!
Please add some context:
- On what OS? (give the output of: uname -a)
- Using which version of Gambit (give the output of: gsi -v)
Did you try the example from the remote-debugger.tar.gz code? How did you adapt it to your application?
Marc
On 17-Jun-09, at 4:08 PM, lowly coder wrote:
~$ uname -a Linux x 2.6.27-7-generic #1 SMP Fri Oct 24 06:40:41 UTC 2008 x86_64 GNU/Linux
~$ gsi -v v4.4.2 20090315000833 x86_64-unknown-linux-gnu
(Ubuntu Linux)
I didn't make any changes ... I just followed the README file.
It seems that there is a problem with the procedure tcp-client-peer- socket-info on Linux. In the remote debugging code this is only used for synchronization (to make sure the xterm has started before sending it stuff to display).
Here's how to fix debugger.scm:
1) remove the call (tcp-client-peer-socket-info port)
2) before the first (let loop () ... insert (thread-sleep! 2)
Marc
On 17-Jun-09, at 6:29 PM, Marc Feeley wrote:
On 17-Jun-09, at 4:08 PM, lowly coder wrote:
~$ uname -a Linux x 2.6.27-7-generic #1 SMP Fri Oct 24 06:40:41 UTC 2008 x86_64 GNU/Linux
~$ gsi -v v4.4.2 20090315000833 x86_64-unknown-linux-gnu
(Ubuntu Linux)
I didn't make any changes ... I just followed the README file.
It seems that there is a problem with the procedure tcp-client-peer- socket-info on Linux. In the remote debugging code this is only used for synchronization (to make sure the xterm has started before sending it stuff to display).
Here's how to fix debugger.scm:
remove the call (tcp-client-peer-socket-info port)
before the first (let loop () ... insert (thread-sleep! 2)
Marc
Indeed this problem only happens on Linux. A patch which fixes this problem has been committed to the repository. You should be able to run the original code on Linux now.
Marc
Confirming that everything appears to wotk using git repo's latest Gambit.
On Thu, Jun 18, 2009 at 10:36 AM, Marc Feeley feeley@iro.umontreal.cawrote:
On 17-Jun-09, at 6:29 PM, Marc Feeley wrote:
On 17-Jun-09, at 4:08 PM, lowly coder wrote:
~$ uname -a
Linux x 2.6.27-7-generic #1 SMP Fri Oct 24 06:40:41 UTC 2008 x86_64 GNU/Linux
~$ gsi -v v4.4.2 20090315000833 x86_64-unknown-linux-gnu
(Ubuntu Linux)
I didn't make any changes ... I just followed the README file.
It seems that there is a problem with the procedure tcp-client-peer- socket-info on Linux. In the remote debugging code this is only used for synchronization (to make sure the xterm has started before sending it stuff to display).
Here's how to fix debugger.scm:
remove the call (tcp-client-peer-socket-info port)
before the first (let loop () ... insert (thread-sleep! 2)
Marc
Indeed this problem only happens on Linux. A patch which fixes this problem has been committed to the repository. You should be able to run the original code on Linux now.
Marc
Right now, in xterm 3, if I do:
(define x (make-thread ...some code to throw an error...)) (thread-start! x) ; a new xterm window pops up (thread-terminate! x)
now, my new xterm window is useless, however it still sticks around -- is there a way to have that xterm window auto vanish on the thread being killed?
[I'm not quite seeing an ibvious way to do this.[
Thanks!
On Fri, Jun 19, 2009 at 10:10 AM, lowly coder lowlycoder@huoyanjinjing.comwrote:
Confirming that everything appears to wotk using git repo's latest Gambit.
On Thu, Jun 18, 2009 at 10:36 AM, Marc Feeley feeley@iro.umontreal.cawrote:
On 17-Jun-09, at 6:29 PM, Marc Feeley wrote:
On 17-Jun-09, at 4:08 PM, lowly coder wrote:
~$ uname -a
Linux x 2.6.27-7-generic #1 SMP Fri Oct 24 06:40:41 UTC 2008 x86_64 GNU/Linux
~$ gsi -v v4.4.2 20090315000833 x86_64-unknown-linux-gnu
(Ubuntu Linux)
I didn't make any changes ... I just followed the README file.
It seems that there is a problem with the procedure tcp-client-peer- socket-info on Linux. In the remote debugging code this is only used for synchronization (to make sure the xterm has started before sending it stuff to display).
Here's how to fix debugger.scm:
remove the call (tcp-client-peer-socket-info port)
before the first (let loop () ... insert (thread-sleep! 2)
Marc
Indeed this problem only happens on Linux. A patch which fixes this problem has been committed to the repository. You should be able to run the original code on Linux now.
Marc
On 19-Jun-09, at 11:47 PM, lowly coder wrote:
Right now, in xterm 3, if I do:
(define x (make-thread ...some code to throw an error...)) (thread-start! x) ; a new xterm window pops up (thread-terminate! x)
now, my new xterm window is useless, however it still sticks around -- is there a way to have that xterm window auto vanish on the thread being killed?
[I'm not quite seeing an ibvious way to do this.[
Thanks!
I've improved the remote debugger to implement this and also REPL line- editing with history. See the attached file.
Marc
Here is a slight improvement that puts the name of the thread on the title bar of the xterm running that thread's REPL.
Marc
-
lowly coder -
Marc Feeley