dherring | 10 Feb 05:20 2010

fix for ltk on mswin?

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
(Continue reading)

Peter Herth | 18 Feb 21:36 2010
Picon

Re: fix for ltk on mswin?

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 <at> 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*
(Continue reading)

Peter Herth | 18 Feb 21:49 2010
Picon

Re: [patch] Improved ttk treeview support

Hi Daniel, finally merged it in... its nice to see how fast it is to
display all symbols, as
this is a huge table!.

I also managed to merge in a bunch of other patches today. If in the
next days nothing
seems to have broken by this, I think we can post this as a release
candidate for the
next "official" Ltk release.
(One warning: the geometry method returns now a properly parsed list
instead of a string).

Peter

On Fri, Jan 1, 2010 at 10:02 PM, Daniel Herring <dherring <at> tentpost.com> wrote:
> Hi Peter,
>
> Please consider the attached patch against
> http://ltk.rplay.net/svn/branches/ltk/repl <at> 215
>
> It implements several essential treeview commands; they are being used to
> implement a symbol/package browser for ABLE.
> http://common-lisp.net/project/able/
>
> The attached treeview-example.lisp demonstrates their usage.
> * (load "treeview-example.lisp")
> * (ltk-user::show-symbols :ltk-user)
>
> Thanks,
> Daniel
(Continue reading)

dherring | 19 Feb 05:26 2010

Re: fix for ltk on mswin?

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
(Continue reading)

Peter Herth | 19 Feb 08:41 2010
Picon

Re: fix for ltk on mswin?

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 <at> 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
(Continue reading)

Peter Herth | 19 Feb 12:14 2010
Picon

Re: fix for ltk on mswin?

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

dherring | 20 Feb 05:40 2010

Re: fix for ltk on mswin?

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...
(Continue reading)

dherring | 20 Feb 06:34 2010

Re: fix for ltk on mswin?

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.

 <at>  <at>  -681,7 +681,7  <at>  <at>  proc moveToStart {sb} {

 (defun init-tcl (&key debug-tcl)
   (let ((translation "lf"))
(Continue reading)


Gmane