Hi list,
I recently made the eerie discovery that all my programs that use Ltk have suddenly stopped working under Windows. I've been a happy user of Ltk for many years. It has always worked flawlessly on all platforms for me, and indeed, on my Linux box, it has continued to work very well.
There has been no changes in my program, wish.exe or in my computer (except for maybe auto-updates?). The recent problems vary slightly in their symptoms, so here's a try at accurately describing some scenarios:
On first trying to show a window by, eg (with-ltk () (show-main)) or (ltk-eyes), my Lisp (clisp-2.48, which is single threaded) blocks as it should, and
1. on one windows XP SP3 box, a window appears normally. However, mousing over the window causes the mouse cursor to turn into the hour-glass symbol, and the window becomes unresponsive (though I can minimize/restore it, it does not "redisplay").
2. on another windows XP SP3 box, no window appears.
In both cases, breaking on the clisp REPL (C-c) causes an Error dialog box to pop up:
"Win32 error 0 (ERROR_SUCCERSS): The operation completed successfully.
Do you wish to invoke the debugger?"
Upon invoking the debugger, everything seems normal to me, since we are supposed to be blocking on read-preserving-whitespace:
<1/255> #<SYSTEM-FUNCTION SHOW-STACK> 3 <2/248> #<COMPILED-FUNCTION SYSTEM::PRINT-BACKTRACE> <3/242> #<COMPILED-FUNCTION SYSTEM::DEBUG-BACKTRACE> <4/233> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2 <5/230> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2-3> <6/226> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS> 2 <7/212> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2> <8/210> #<SYSTEM-FUNCTION SYSTEM::DRIVER> <9/170> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP> <10/167> #<SYSTEM-FUNCTION INVOKE-DEBUGGER> <11/164> #<COMPILED-FUNCTION LTK::DEBUG-POPUP> <12/161> #<COMPILED-FUNCTION LTK::DEBUG-ERROR> <13/157> #<COMPILED-FUNCTION LTK::MAKE-CONDITION-HANDLER-FUNCTION-1-1> <14/152> #<SYSTEM-FUNCTION SIGNAL> 1 <15/124> #<SYSTEM-FUNCTION READ-PRESERVING-WHITESPACE> <16/119> #<COMPILED-FUNCTION LTK:READ-EVENT> <17/116> #<COMPILED-FUNCTION LTK::MAIN-ITERATION-PROC-EVENT> <18/103> #<COMPILED-FUNCTION LTK::MAIN-ITERATION> <19/101> #<COMPILED-FUNCTION LTK::MAINLOOP-1> <20/99> #<COMPILED-FUNCTION LTK::MAKE-CONDITION-HANDLER-FUNCTION-1-1-5> <21/88> #<COMPILED-FUNCTION LTK::MAKE-CONDITION-HANDLER-FUNCTION-1-1> <22/85> #<COMPILED-FUNCTION LTK::COMPUTE-CALL-WITH-DEBUGGER-HOOK-USE-DEFAULT-DEBUGGER> ...etc
Alternatively, clicking "No" (don't invoke debugger) returns me to the first screen and everything works normally again (so break & continue is a kludgy way to get this working, at least on the computers I've seen).
Another alternative (for windows box 1 above) is to not BREAK in clisp, but to close it forcibly, whereupon the Tk window stops hanging/freezing. Of course, any attempt to use it (button clicks) result in this error dialog box (cannot communicate to non-existent Lisp):
Application Error: "Error: error writing "stdout": broken pipe"
Clicking to show more details gives:
error writing "stdout": broken pipe error writing "stdout": broken pipe while executing "puts "(:callback "$s")"" (procedure "callback" line 1) invoked from within "callback w6" invoked from within ".w2.w3.w5.w6 invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke]" (procedure "tk::ButtonUp" line 24) invoked from within "tk::ButtonUp .w2.w3.w5.w6" (command bound to event)
Though pointless, it does what I expected, so I'm just providing the above for reference.
I've also tried out the repl branch here:
http://ltk.rplay.net/svn/branches/ltk/repl/ltk.lisp
[Sidenote: I pushed :tk84 onto *features*, and consequently had to make some patches (treeview not defined under #+tk84). Do you think the patch shows the right way to go about this? I also noticed that the newer Ttk buttons take vastly different (DEFARGS type) arguments. Of interest to me specifically, :is font no longer supported under the Ttk "branch"?]
The patched repl branch works on windows box 2, but showed no improvement (same behaviour) on windows box 1.
It has been very confusing having the carpet yanked out from under me after using Ltk (albeit casually, on and off) for so many years. My best guess at the moment is that it is something in the latest Windows upgrade has broken the pipe between Lisp and wish. I intend to investigate piping functionality some more later. I will also need to debug this on another computer later, so who knows what other behaviour I'll see.
Has anyone else experienced any trouble similar to this? I'll probably also be trying out this suggestion (I don't understand what it does) for windows box 1.
http://common-lisp.net/pipermail/ltk-user/2010-February/000712.html
Daniel mentioned earlier in that thread that there have been lots of issues reported on XP, but I've always been under the impression that Ltk is solid for Windows. Have I been mistaken? Any other suggestions (both quick hacks and permanent fixes) for how to go about this?
Yong.
Hi Yong,
I tried using Ltk a while back (running Phil's Able editor), and immediately ran into the kind of problem you report. I found that bringing up a msgbox as the first thing to do, and dismissing it by pressing Enter (*not *by clicking) was one way to avoid the hang. Unfortunately that's all I can add. I'm pretty sure there are a few more people that would be very happy to see this bug get fixed. I hit it and just stopped trying to do GUI programming, so if it get's fixed, I'll be very happy, and willing to test things on my 'eerie' computer.
Regards, Jon
On Mon, Oct 4, 2010 at 8:24 PM, Theam Yong Chew senatorzergling@gmail.comwrote:
Hi list,
I recently made the eerie discovery that all my programs that use Ltk have suddenly stopped working under Windows.
.....
On 10/4/2010 8:47 PM, Jonathan Johansen wrote:
Hi Yong,
I tried using Ltk a while back (running Phil's Able editor), and immediately ran into the kind of problem you report. I found that bringing up a msgbox as the first thing to do, and dismissing it by pressing Enter (*not *by clicking) was one way to avoid the hang. Unfortunately that's all I can add. I'm pretty sure there are a few more people that would be very happy to see this bug get fixed. I hit it and just stopped trying to do GUI programming,...
Bah, desktop programming is so 20th century. Get qooxlisp, make qooxdoo your slave GUI.
:)
kt
On Tue, 5 Oct 2010, Jonathan Johansen wrote:
I tried using Ltk a while back (running Phil's Able editor), and immediately ran into the kind of problem you report. I found that bringing up a msgbox as the first thing to do, and dismissing it by pressing Enter (not by clicking) was one way to avoid the hang. Unfortunately that's all I can add. I'm pretty sure there are a few more people that would be very happy to see this bug get fixed. I hit it and just stopped trying to do GUI programming, so if it get's fixed, I'll be very happy, and willing to test things on my 'eerie' computer.
So the patches I sent several months ago make things work 100% on my xp box. It is my belief that the problem is some oddity of how ms-broken-windows handles process creation and/or stream i/o.
What I saw (e.g. the ABLE window not appearing until after I terminated clisp) lead me to believe that ltk was writing everything to the wish shell before it entered the Tk event loop; thus Tk never received notification of pending data until the stream was closed. Strategic placement of a (sleep 1) solved my problem and reinforced my belief.
That said, I did a bunch of tinkering, never breaking out proper debug tools. Its possible I just moved a race condition away from my computer and towards others. To diagnose this properly, someone needs to break out the debuggers and attach to both lisp and wish after the startup hang. Backtraces should show what each is doing, hopefully pointing out where the deadlock occurs.
These links may help. http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Later, Daniel
On 10/4/2010 9:27 PM, Daniel Herring wrote:
On Tue, 5 Oct 2010, Jonathan Johansen wrote:
I tried using Ltk a while back (running Phil's Able editor), and immediately ran into the kind of problem you report. I found that bringing up a msgbox as the first thing to do, and dismissing it by pressing Enter (not by clicking) was one way to avoid the hang. Unfortunately that's all I can add. I'm pretty sure there are a few more people that would be very happy to see this bug get fixed. I hit it and just stopped trying to do GUI programming, so if it get's fixed, I'll be very happy, and willing to test things on my 'eerie' computer.
So the patches I sent several months ago make things work 100% on my xp box. It is my belief that the problem is some oddity of how ms-broken-windows handles process creation and/or stream i/o.
What I saw (e.g. the ABLE window not appearing until after I terminated clisp) lead me to believe that ltk was writing everything to the wish shell before it entered the Tk event loop; thus Tk never received notification of pending data until the stream was closed. Strategic placement of a (sleep 1) solved my problem and reinforced my belief.
That said, I did a bunch of tinkering, never breaking out proper debug tools. Its possible I just moved a race condition away from my computer and towards others. To diagnose this properly, someone needs to break out the debuggers and attach to both lisp and wish after the startup hang. Backtraces should show what each is doing, hopefully pointing out where the deadlock occurs.
These links may help. http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx http://www.microsoft.com/whdc/devtools/debugging/default.mspx
This link might help: http://common-lisp.net/project/cffi/
It's time for LTk to lose the stream crutch. FFI isn't /that/ hard, and it only needs to be done by the LTk maintainers.
kt
On Mon, 4 Oct 2010, Kenneth Tilton wrote:
This link might help: http://common-lisp.net/project/cffi/
It's time for LTk to lose the stream crutch. FFI isn't /that/ hard, and it only needs to be done by the LTk maintainers.
Yes Kenny, we know about the intarwebs and FFI. :)
Re HTML: The HTML canvas owes a bit to its Tk ancestor. That said, none of the webkit implementations were ready for writing standalone apps last I checked (a few months ago); and I personally hate browser "apps".
Somehow writing CL glue to a handful of nonstandard layers that sanitize the mass of overengineered, underperforming HTML technologies (including Flash) just doesn't appeal to me. For all that effort, one could write a better custom gui in C++ using the enjoyable Qt framework and implement a simple FFI layer for passing application-specific data. Plus its more reliably portable. For the squeamish, there are also bindings like CommonQt.
Re FFI: There was a Tk interface that used FFI. http://www.cliki.net/Lisp-Tk Didn't cells have such a beast as well?
The LTk design has some nice features over an FFI layer: - better portability across ABI changes (the TCL language is the standard API; the C interface is less so), generally easier to invoke wish than locate a library, etc. - it is trivial to install a small "thin app" and host all the functionality (including gui code and upgrades) on a remote server - it is trivial to bypass LTk and invoke Tk directly; this is useful when binding new features, or when the LTk interface is suboptimal - IMO it is generally easier to debug (echo the streams vs invoke gdb)
Streams aren't a crutch. Port 80, maybe; but streams, no.
If I were starting a new GUI toolkit today, I think it would be built on a lower, simpler substrate with more possibilities for novel widgets and user interactions: OpenGL/OpenAL and DirectX.
:)
- Daniel
On 10/4/2010 10:41 PM, Daniel Herring wrote:
If I were starting a new GUI toolkit today, I think it would be built on a lower, simpler substrate with more possibilities for novel widgets and user interactions: OpenGL/OpenAL and DirectX.
Done. Tcl/Tk/Togl -> OpenGL/OpenAL or Snack/GraphicsMagick/FTGL. If Cello is still on c-l.net. I know Frank G had started on resuurection of Cello.
btw, If you want OpenGL you'll want FFI. Lemme know if you need a link to CFFI.
:)
kt
On 10/4/10, Theam Yong Chew senatorzergling@gmail.com wrote:
...
Sorry, it seems I have forgotten to attach the patch I mentioned below
I've also tried out the repl branch here:
http://ltk.rplay.net/svn/branches/ltk/repl/ltk.lisp
[Sidenote: I pushed :tk84 onto *features*, and consequently had to make some patches (treeview not defined under #+tk84). Do you think the patch shows the right way to go about this? I also noticed that the newer Ttk buttons take vastly different (DEFARGS type) arguments. Of interest to me specifically, :is font no longer supported under the Ttk "branch"?]
...
It has been very confusing having the carpet yanked out from under me after using Ltk (albeit casually, on and off) for so many years. My best guess at the moment is that it is something in the latest Windows upgrade has broken the pipe between Lisp and wish. I intend to investigate piping functionality some more later. I will also need to debug this on another computer later, so who knows what other behaviour I'll see.
This "another computer" didn't have any problems. Along with a few other things I've observed, I now think it's likely to be a coincidence that my programs broke on two computers at the same time. It's probably not due to a Windows update. At least for now, I am not urgently needing any fixes.
Has anyone else experienced any trouble similar to this? I'll probably also be trying out this suggestion (I don't understand what it does) for windows box 1.
http://common-lisp.net/pipermail/ltk-user/2010-February/000712.html
I thought I was going to try the "translate" stuff suggested there, but it is already in the repl branch, so I didn't see any improvements after playing about a bit with the various suggestions there.
As for your replies, thanks for the tip, Jonathan: using a popup box is a nicer way than my ugly C-c breaking & continuing. With appropriate social engineering, users won't know any better. Daniel's suggestions for debugging is quite involved, and if I were to do it, it will probably need to be attempted at a much later date. Thanks for the nice explanation of the tradeoffs involved in using pipes/streams.
PS Kenny, is qooxdoo's workflow like using Ltk? Does it work well for interactive exploration: widget creation, callbacks into Lisp closures, dynamically changing screen, etc?
Yong.
-
Daniel Herring -
Jonathan Johansen -
Kenneth Tilton -
Theam Yong Chew