Hi Peter,
Thanks for getting back to LTK.
Hmm, Windows is strange :). But your explanation is the best I have
heard for the windows problems so far... so I added
#+mswindows (sleep 1)
The waiting for a prompt has only one problem - tcl doesn't send a prompt when run as a subprocess.
I've poked at this a bit more; the sleep doesn't fix all my problems. It appears that incomplete commands are being flushed to wish and/or ltk is overflowing a stream buffer somewhere. For example, running ltktest with a trace on read-wish, I see errors like
LTK::READ-WISH returned (:ERROR "value for "-textvaria" missing") or Error sending command to wish: on #<BASIC-CHARACTER-OUTPUT-STREAM ISO-8859-1 (PIPE/1092) #x8D5F2BE> : Invalid argument during write or LTK::READ-WISH returned (:ERROR "missing close-brace")
This appears to be a race condition; the error changes randomly with each run (though the above are the most common). Sometimes the test almost works, other times it stops early. I did have to comment out the section which draws the lines -- that almost never worked. Similarly, theme-names generally fails (or whatever else does the first read-wish). For some reason, the situation can be aggravated by adding flush-wish in various places.
But the first sleep at least lets Tk's window appear.
- Daniel
P.S. I'm debugging this in an attempt to get ABLE running.
Hi Daniel,
just to make sure, you are running the repl branch? This should make the communication more robust. However this was mostly tested on diverse flavors of Unix (mainly Solaris). The current code does however take no care how long the lines are that are sent to TCL. If you look into flush-wish, you will find some disabled code to limit the line length sent to TCL. It really sounds as if we should make sure only to send short lines over the pipe.
Peter
On Fri, Feb 19, 2010 at 5:26 AM, dherring@tentpost.com wrote:
Hi Peter,
Thanks for getting back to LTK.
Hmm, Windows is strange :). But your explanation is the best I have
heard for the windows problems so far... so I added
#+mswindows (sleep 1)
The waiting for a prompt has only one problem - tcl doesn't send a prompt when run as a subprocess.
I've poked at this a bit more; the sleep doesn't fix all my problems. It appears that incomplete commands are being flushed to wish and/or ltk is overflowing a stream buffer somewhere. For example, running ltktest with a trace on read-wish, I see errors like
LTK::READ-WISH returned (:ERROR "value for "-textvaria" missing") or Error sending command to wish: on #<BASIC-CHARACTER-OUTPUT-STREAM ISO-8859-1 (PIPE/1092) #x8D5F2BE> : Invalid argument during write or LTK::READ-WISH returned (:ERROR "missing close-brace")
This appears to be a race condition; the error changes randomly with each run (though the above are the most common). Sometimes the test almost works, other times it stops early. I did have to comment out the section which draws the lines -- that almost never worked. Similarly, theme-names generally fails (or whatever else does the first read-wish). For some reason, the situation can be aggravated by adding flush-wish in various places.
But the first sleep at least lets Tk's window appear.
- Daniel
P.S. I'm debugging this in an attempt to get ABLE running.
ltk-user site list ltk-user@common-lisp.net http://common-lisp.net/mailman/listinfo/ltk-user
Hi Daniel,
I just committed a LTk version which has the parameter *max-line-length* to limit the line length in the communication with TCL - perhaps playing around with that value brings any progress.
Peter
Peter wrote:
I just committed a LTk version which has the parameter *max-line-length* to limit the line length in the communication with TCL - perhaps playing around with that value brings any progress.
Unfortunately, that didn't fix it. I tried 100, 200, ..., 500.
I am starting to understand my way around this part of the code, and have isolated a consistent failure.
LTK says (send-wish "proc senddatastring {s} { global server
puts $server "(:data \"[escape $s]\")" flush $server } ")
If I add a (read-data) after this, it says LTK::READ-WISH returned (:ERROR "missing close-brace")
If the definition is changed to a single line, (send-wish "proc senddatastring {s} {global server; puts $server "(:data \"[escape $s]\")"; flush $server} ") LTK::READ-WISH hangs because there is no error...
This appears to be an issue with all multi-line procedure definitions -- but the ones in init-tcl work fine...
Still poking around.
- Daniel
Daniel wrote:
Still poking around.
Doh! I found my problem. Either commenting out
#fconfigure stdin -encoding utf-8 -translation ~a #fconfigure stdout -encoding utf-8
or enabling (setf translation "crlf") fixes all my problems. Why I didn't see this earlier? Why did I let the :lispworks scare me away?
The Ltk examples and ABLE both work fine now.
A major benefit of the (sleep 1) was to let Tk appear before Ltk sent it bad commands. However, it should not be removed; I still need it for proper operation under clisp.
By my understanding, SBCL is the only lisp that doesn't translate ~% as \r\n on MS platforms. Thus every other CL on windows should get the crlf translation.
Here are my recommended patches to the current repl/ltk.lisp. With them, Ltk::ltktest and ABLE::start ran properly under both clozure-1.4 and clisp-2.48. Note that Clozure puts :windows on *features*, and Clisp uses :win32.
@@ -681,7 +681,7 @@ proc moveToStart {sb} {
(defun init-tcl (&key debug-tcl) (let ((translation "lf")) - #+(and :lispworks :windows) (setf translation "crlf") + #+(and (or windows win32) (not sbcl)) (setf translation "crlf")
(format (wish-stream *wish*) "set buffer "" set server stdout @@ -764,7 +764,7 @@ fconfigure stdout -encoding utf-8 (if (null (wish-stream *wish*)) (progn (setf (wish-stream *wish*) (or stream (do-execute *wish-pathname* *wish-args*))) - #+mswindows (sleep 1) + #+(or windows win32) (sleep 1) (setf (wish-call-with-condition-handlers-function *wish*) (make-call-with-condition-handlers-function debugger-class)) ;; perform tcl initialisations
Later, Daniel
2010/2/20 dherring@tentpost.com:
Daniel wrote:
Still poking around.
Doh! I found my problem. Either commenting out
#fconfigure stdin -encoding utf-8 -translation ~a #fconfigure stdout -encoding utf-8
or enabling (setf translation "crlf") fixes all my problems. Why I didn't see this earlier? Why did I let the :lispworks scare me away?
I guess the fact that we use SBCL on Windows (when we develop on Windows at all) is showing here. Your patch looks like it's probably The Right Thing. And I guess we'll have a new SBCL/Windows bug when SBCL finally grows crlf support.
The Ltk examples and ABLE both work fine now.
A major benefit of the (sleep 1) was to let Tk appear before Ltk sent it bad commands. However, it should not be removed; I still need it for proper operation under clisp.
This is worrisome. If it's only clisp where this causes problems, maybe we can see if there's any clisp-specific way of waiting for the subprocess to be ready for input.
-Thomas
Thomas F. Burdick wrote:
2010/2/20 dherring@tentpost.com:
A major benefit of the (sleep 1) was to let Tk appear before Ltk sent it bad commands. However, it should not be removed; I still need it for proper operation under clisp.
This is worrisome. If it's only clisp where this causes problems, maybe we can see if there's any clisp-specific way of waiting for the subprocess to be ready for input.
Yes the sleep is bad, but I don't feel like debugging it further. FWIW, a (sleep 0.1) is too short, but a (sleep 0.5) seems to work. Thus we apply a margin of safety and conclude (sleep 1) is good. ;)
Unfortunately, I don't see a way to wait for the subprocess. http://clisp.cons.org/impnotes.html#run-prog
The docs do mention a possible deadlock; so its possible the sleep could be restricted to clisp on win32. http://clisp.cons.org/impnotes.html#pipe
- Daniel
-
dherring＠tentpost.com -
Peter Herth -
Thomas F. Burdick