There have been many reports of ltk not starting properly on mswin boxes. I have an XP box that consistently shows this problem. The basic symptom is that when tk should appear, the active titlebar is grayed out but nothing else happens. When the lisp process is closed, the tk window full of ltk widgets appears.
A few years ago, there were a couple reports on this list containing workarounds. However, I couldn't get any of them to work.
After poking at this for a long time, I came up with the following patch. I can't guarantee 100% success, but it hasn't failed and it points to a possible obscure problem in ltk.
;; open subprocess (if (null (wish-stream *wish*)) (progn - (setf (wish-stream *wish*) (or stream (do-execute *wish-pathname* *wish-args*)) + (setf (wish-stream *wish*) (or stream (do-execute *wish-pathname* *wish-args*))) + (sleep 1) + (setf (wish-call-with-condition-handlers-function *wish*) (apply #'make-condition-handler-function keys)) ;; perform tcl initialisations
Basically, it appears to me that due to scheduler timing, ltk may be writing to wish before it is ready, somehow causing the wish gui event loop to hang. The (sleep 1) is sketchy, but would it be hard to have ltk wait until it reads a wish prompt? ISTR there was a reason why this is a common pattern in expect.
Thanks, Daniel
P.S. Need... sleep....z.z.z.z.zzzzzzz
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.
Peter
On Wed, Feb 10, 2010 at 5:20 AM, dherring@tentpost.com wrote:
There have been many reports of ltk not starting properly on mswin boxes. I have an XP box that consistently shows this problem. The basic symptom is that when tk should appear, the active titlebar is grayed out but nothing else happens. When the lisp process is closed, the tk window full of ltk widgets appears.
A few years ago, there were a couple reports on this list containing workarounds. However, I couldn't get any of them to work.
After poking at this for a long time, I came up with the following patch. I can't guarantee 100% success, but it hasn't failed and it points to a possible obscure problem in ltk.
;; open subprocess (if (null (wish-stream *wish*)) (progn
- (setf (wish-stream *wish*) (or stream (do-execute *wish-pathname*
*wish-args*))
- (setf (wish-stream *wish*) (or stream (do-execute *wish-pathname*
*wish-args*)))
- (sleep 1)
- (setf
(wish-call-with-condition-handlers-function *wish*) (apply #'make-condition-handler-function keys)) ;; perform tcl initialisations
Basically, it appears to me that due to scheduler timing, ltk may be writing to wish before it is ready, somehow causing the wish gui event loop to hang. The (sleep 1) is sketchy, but would it be hard to have ltk wait until it reads a wish prompt? ISTR there was a reason why this is a common pattern in expect.
Thanks, Daniel
P.S. Need... sleep....z.z.z.z.zzzzzzz
ltk-user site list ltk-user@common-lisp.net http://common-lisp.net/mailman/listinfo/ltk-user
-
dherring＠tentpost.com -
Peter Herth