[ltk-user] no error stream use
Is there some reason the error stream from Tk is not being used? In Celtic I bound that to a second global and read that (with read-line, not read since the error output is not Lisp friendly) before trying to read the regular stream. As it is read-data just flails away at error text until it hits something that upsets the reader, such as a comma. kt
On 2/2/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
Is there some reason the error stream from Tk is not being used? In Celtic I bound that to a second global and read that (with read-line, not read since the error output is not Lisp friendly) before trying to read the regular stream.
As it is read-data just flails away at error text until it hits something that upsets the reader, such as a comma.
Well, there is no deep reason - besides I do not know offhand how the support for a seperate error stream across all the lisps Ltk runs on is. For sure, it probably would remove some of the weird errors of Ltk when Tk sends something unreadable... Peter
Peter Herth wrote:
On 2/2/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
Is there some reason the error stream from Tk is not being used? In Celtic I bound that to a second global and read that (with read-line, not read since the error output is not Lisp friendly) before trying to read the regular stream.
As it is read-data just flails away at error text until it hits something that upsets the reader, such as a comma.
Well, there is no deep reason - besides I do not know offhand how the support for a seperate error stream across all the lisps Ltk runs on is. For sure, it probably would remove some of the weird errors of Ltk when Tk sends something unreadable...
Here is the change I made for Celtic: #+allegro (multiple-value-bind (stream error-stream process-id) (excl:run-shell-command #+mswindows fullstring #-mswindows (apply #'vector program program args) :input :stream :output :stream :error-output :stream :wait wt) (declare (ignorable dummy error-stream process-id)) (trc "doexec!!!> " stream error-stream process-id) (if stream (progn (setf *ewish* error-stream) stream) (error "Cannot create WISH process."))))) Then before reading *wish* (this of course in the day when that was the stream): (loop while (peek-char-no-hang *ewish*) do (break "ewish!!!!!!!> ~a" (read-line *ewish* nil nil))) That looks like it could be a little smarter and not break until all the error output was read, but that is the general idea. kt
Kenny Tilton wrote:
Peter Herth wrote:
On 2/2/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
Is there some reason the error stream from Tk is not being used? In Celtic I bound that to a second global and read that (with read-line, not read since the error output is not Lisp friendly) before trying to read the regular stream.
As it is read-data just flails away at error text until it hits something that upsets the reader, such as a comma.
Well, there is no deep reason - besides I do not know offhand how the support for a seperate error stream across all the lisps Ltk runs on is. For sure, it probably would remove some of the weird errors of Ltk when Tk sends something unreadable...
Here is the change I made for Celtic:
#+allegro (multiple-value-bind (stream error-stream process-id) (excl:run-shell-command #+mswindows fullstring #-mswindows (apply #'vector program program args) :input :stream :output :stream :error-output :stream :wait wt) (declare (ignorable dummy error-stream process-id)) (trc "doexec!!!> " stream error-stream process-id) (if stream (progn (setf *ewish* error-stream) stream) (error "Cannot create WISH process.")))))
Then before reading *wish* (this of course in the day when that was the stream):
(loop while (peek-char-no-hang *ewish*) do (break "ewish!!!!!!!> ~a" (read-line *ewish* nil nil)))
That looks like it could be a little smarter and not break until all the error output was read, but that is the general idea.
kt _______________________________________________ ltk-user site list ltk-user@common-lisp.net http://common-lisp.net/mailman/listinfo/ltk-user
FYI I have now added the above to my copy and it does not seem to be picking up the unreadable TK stuff from the error-stream. Still investigating, but I wanted to give you a heads up in case you were playing with it. kt
Kenny Tilton wrote:
Kenny Tilton wrote:
Peter Herth wrote:
On 2/2/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
Is there some reason the error stream from Tk is not being used? In Celtic I bound that to a second global and read that (with read-line, not read since the error output is not Lisp friendly) before trying to read the regular stream.
As it is read-data just flails away at error text until it hits something that upsets the reader, such as a comma.
Well, there is no deep reason - besides I do not know offhand how the support for a seperate error stream across all the lisps Ltk runs on is. For sure, it probably would remove some of the weird errors of Ltk when Tk sends something unreadable...
Here is the change I made for Celtic:
#+allegro (multiple-value-bind (stream error-stream process-id) (excl:run-shell-command #+mswindows fullstring #-mswindows (apply #'vector program program args) :input :stream :output :stream :error-output :stream :wait wt) (declare (ignorable dummy error-stream process-id)) (trc "doexec!!!> " stream error-stream process-id) (if stream (progn (setf *ewish* error-stream) stream) (error "Cannot create WISH process.")))))
Then before reading *wish* (this of course in the day when that was the stream):
(loop while (peek-char-no-hang *ewish*) do (break "ewish!!!!!!!> ~a" (read-line *ewish* nil nil)))
That looks like it could be a little smarter and not break until all the error output was read, but that is the general idea.
kt _______________________________________________ ltk-user site list ltk-user@common-lisp.net http://common-lisp.net/mailman/listinfo/ltk-user
FYI I have now added the above to my copy and it does not seem to be picking up the unreadable TK stuff from the error-stream. Still investigating, but I wanted to give you a heads up in case you were playing with it. kt
No, it works, I did not see that there are two places where the the stream is read. Tsk tsk. :) Meanwhile, here is peek-char-no-hang: (defun peek-char-no-hang (stream) (and (listen stream) (peek-char t stream))) kt
I just managed to introduce some bug. No idea where to look, thought someone strong on sockets/streams might have an idea. All my writes to Tk go thru this for debugging purposes. I can enable/disable/when-icize the write to standard output. (defun tk-send (fmt$ &rest args) "send a string to wish" (let ((text (apply 'format nil fmt$ args))) (format t "~A~%" text) (format (wish-stream *wish*) "~A~%" text) )) Now my test window does not come up without the trace. The window appears but no widgets, and the window is unresponsive. I have to have the Windows task manager kill it. Is this an easy "oh, I know what that is..." for anyone? thx, kenny
Maybe. Is force-output happening? Put an explicit one at the end of tk-send and see if that fixes it. -- Dan Knapp On Feb 9, 2006, at 2:01 PM, Kenny Tilton wrote:
I just managed to introduce some bug. No idea where to look, thought someone strong on sockets/streams might have an idea.
All my writes to Tk go thru this for debugging purposes. I can enable/disable/when-icize the write to standard output.
(defun tk-send (fmt$ &rest args) "send a string to wish" (let ((text (apply 'format nil fmt$ args))) (format t "~A~%" text) (format (wish-stream *wish*) "~A~%" text) ))
Now my test window does not come up without the trace. The window appears but no widgets, and the window is unresponsive. I have to have the Windows task manager kill it.
Is this an easy "oh, I know what that is..." for anyone?
thx, kenny _______________________________________________ ltk-user site list ltk-user@common-lisp.net http://common-lisp.net/mailman/listinfo/ltk-user
by the way, merely using TRACE to see how far I am getting before hanging is enough to make things work. (I will try a counter <g>) Also, adding force-output does not help. kenny
On 2/9/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
by the way, merely using TRACE to see how far I am getting before hanging is enough to make things work. (I will try a counter <g>)
Also, adding force-output does not help.
Sorry, I must have missed a message, what is your problem with the sockets? Peter
I do not see the preceding message I sent, so here it is (and more news below):
I just managed to introduce some bug. No idea where to look, thought someone strong on sockets/streams might have an idea.
All my writes to Tk go thru this for debugging purposes. I can enable/disable/when-icize the write to standard output.
(defun tk-send (fmt$ &rest args) "send a string to wish" (let ((text (apply 'format nil fmt$ args))) (format t "~A~%" text) (format (wish-stream *wish*) "~A~%" text) ))
Now my test window does not come up without the trace. The window appears but no widgets, and the window is unresponsive. I have to have the Windows task manager kill it.
Is this an easy "oh, I know what that is..." for anyone?
Then came.....
by the way, merely using TRACE to see how far I am getting before hanging is enough to make things work. (I will try a counter <g>)
Also, adding force-output does not help.
And now.... As expected, all sends are the same (using a counter to count them). But this makes everything work: Instead of "wm withdraw ." I do "wm iconify ." The idea of doing either is to keep the user from having to watch Tk assemble the window widget by widget. Looks funny, feels slow. My Cells-driven approach does not think about when to do things, so it just shoots ideas over to Tk as it thinks of them. :) I could work on that, but beginning with a withdraw or iconify and then ending with deiconify looked like a quick win. Someone on the TCL list told me iconfiy might put an icon on the desktop and to use withdraw instead. Maybe I should just hold off on the PACK of the top widget(s) in a window until everyone else is packed (the other way to handle creeping widget assembly). Thoughts? kt
As expected, all sends are the same (using a counter to count them). But this makes everything work:
Instead of "wm withdraw ." I do "wm iconify ."
The idea of doing either is to keep the user from having to watch Tk assemble the window widget by widget. Looks funny, feels slow. My Cells-driven approach does not think about when to do things, so it just shoots ideas over to Tk as it thinks of them. :) I could work on that, but beginning with a withdraw or iconify and then ending with deiconify looked like a quick win. Someone on the TCL list told me iconfiy might put an icon on the desktop and to use withdraw instead.
Maybe I should just hold off on the PACK of the top widget(s) in a window until everyone else is packed (the other way to handle creeping widget assembly).
Thoughts?
I actually do withdraw windows as soon as they are created to fill them in the background. So that works with all my programs. But yes, the next best thing is not to pack the toplevel container until everything else is done. Peter
Peter Herth wrote:
As expected, all sends are the same (using a counter to count them). But this makes everything work:
Instead of "wm withdraw ." I do "wm iconify ."
The idea of doing either is to keep the user from having to watch Tk assemble the window widget by widget. Looks funny, feels slow. My Cells-driven approach does not think about when to do things, so it just shoots ideas over to Tk as it thinks of them. :) I could work on that, but beginning with a withdraw or iconify and then ending with deiconify looked like a quick win. Someone on the TCL list told me iconfiy might put an icon on the desktop and to use withdraw instead.
Maybe I should just hold off on the PACK of the top widget(s) in a window until everyone else is packed (the other way to handle creeping widget assembly).
Thoughts?
I actually do withdraw windows as soon as they are created to fill them in the background. So that works with all my programs.
Good to know, thx. Yeah, worked for me, too, until I did Something. Programming! :) kt
On 2/9/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
Peter Herth wrote:
I actually do withdraw windows as soon as they are created to fill them in the background. So that works with all my programs.
Good to know, thx. Yeah, worked for me, too, until I did Something. Programming! :)
This is purely subjective (I haven't written up test cases to find out for sure), but it seems like the fastest way to do things is to withdraw the toplevel, pack from innermost to outermost, then normalize it.
Thomas F. Burdick wrote:
On 2/9/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
Peter Herth wrote:
I actually do withdraw windows as soon as they are created to fill them in the background. So that works with all my programs.
Good to know, thx. Yeah, worked for me, too, until I did Something. Programming! :)
This is purely subjective (I haven't written up test cases to find out for sure), but it seems like the fastest way to do things is to withdraw the toplevel, pack from innermost to outermost, then normalize it.
Yep. And if I want to get diabolical I can, instead of sending TK commands as they come up during a propagation, I can save them up and, at the end of any given propagation (as the ultimate step in unfinished-business handling) sort them and write them all to the stream in one blast. Of course this means Cells needs to accept before, after, around, whatever callbacks to be kicked off after every propagation. Maybe during propagation there is something in the Cells API to register an "after" callback. Possibly one-time or permanent, not that I see a big cost to registering on each propagation. This does not seem kludgy to me. One thing Cells does is neatly organize the multitudinous state changes arising from some initial state change. OTOH, as I am discovering with Tk, sometimes this well-ordered system has to deal with less well-ordered systems. Tk is a little fragile when it comes to things like: set .w1 "boo" <create a listbox with textvariable .w1 and items including "boo"> No dice. The order must be reversed or the list does not see the value .w1. ie, The usual problem with imperative vs. declarative. So a reasonable extension to Cells is a mechanism for talking to external systems sensitive to the ordering of perturbations. But I will wait until Tk proves it needs this or until some other use case comes along. ken
Kenny Tilton wrote:
Thomas F. Burdick wrote:
On 2/9/06, Kenny Tilton <ktilton@nyc.rr.com> wrote:
Peter Herth wrote:
I actually do withdraw windows as soon as they are created to fill them in the background. So that works with all my programs.
Good to know, thx. Yeah, worked for me, too, until I did Something. Programming! :)
This is purely subjective (I haven't written up test cases to find out for sure), but it seems like the fastest way to do things is to withdraw the toplevel, pack from innermost to outermost, then normalize it.
Yep. And if I want to get diabolical I can, instead of sending TK commands as they come up during a propagation, I can save them up and, at the end of any given propagation (as the ultimate step in unfinished-business handling) sort them and write them all to the stream in one blast.
Of course this means Cells needs to accept before, after, around, whatever callbacks to be kicked off after every propagation. Maybe during propagation there is something in the Cells API to register an "after" callback. Possibly one-time or permanent, not that I see a big cost to registering on each propagation.
This does not seem kludgy to me. One thing Cells does is neatly organize the multitudinous state changes arising from some initial state change. OTOH, as I am discovering with Tk, sometimes this well-ordered system has to deal with less well-ordered systems. Tk is a little fragile when it comes to things like:
set .w1 "boo" <create a listbox with textvariable .w1 and items including "boo">
No dice. The order must be reversed or the list does not see the value .w1. ie, The usual problem with imperative vs. declarative.
So a reasonable extension to Cells is a mechanism for talking to external systems sensitive to the ordering of perturbations. But I will wait until Tk proves it needs this or until some other use case comes along.
I am such an idiot (ROFL): (defmethod md-awaken :after ((self c-panedwindow)) (with-integrity (:panedwindow :finalize self) (loop for k in (^kids) do (tk-send self "~a add ~a" (^path) (path k))))) The :finalize option doing exactly what I just described, and having been created exactly for Tk. Identical minds think alike? I am such an idiot. :) kenny ps. Is this list moderated? Huge delays sometimes in posting. k
participants (4)
-
Dan Knapp -
Kenny Tilton -
Peter Herth -
Thomas F. Burdick