Re: [Rd] misbehaviour of some tk windows, R 2.6.0 on SUSE 10.1?

From: Peter Dalgaard <p.dalgaard_at_biostat.ku.dk>
Date: Tue, 09 Oct 2007 22:31:45 +0200

Peter Dalgaard wrote:
> David Firth wrote:
>
>> I don't know whether this is specific to (my installation
>> of) SUSE 10.1, or is more general.
>>
>> With R 2.6.0, I am finding that some widgets made through
>> the tcltk package are having problems which become evident
>> through scrollbar activity. An example is demo(tkfaq) --
>> see below. To reproduce the problem, I do the following:
>> after the tk window appears, hold down the "scroll-down"
>> tab at the foot of the window for a few seconds, then
>> release. If scrolling stops (as it should, if all is
>> working correctly), do the same thing again. Repeating
>> this 2 or 3 times usually results in uncontrolled
>> (unstoppable) scrolling activity; and closing the window
>> when that happens delivers the errors that appear in the
>> transcript below.
>>
>> My R 2.6.0 was built on my own system,
>>
>> OS: SUSE linux 10.1
>> tcl: 8.4.12-14
>> tk: 8.4.12-14
>> gcc: 4.1.0-25
>>
>> Since I had not seen this behaviour with previous versions
>> of R, I did a check with R 2.5.1: a fresh build today of R
>> 2.5.1 on the same system does not appear to have the same
>> problem.
>>
>> Any ideas? Is anyone else seeing this behaviour?
>>
>> David
>>
>>
>
> Looks a bit nasty. I see it on SUSE 10.2 as well. Increasing the
> repeatinterval setting for the scrollbar helps, but even at a setting of
> 50, I still see the effect. It is usually stoppable with the middle
> button over the trough.
> The error message is what you'd expect from killing a window while
> something is trying to talk to widgets inside of it. The details of the
> popup dialog is a little more informative:
>
> while executing
> "$w cget -repeatinterval"
> (procedure "tk::ScrollSelect" line 12)
> invoked from within
> "tk::ScrollSelect .3.2 arrow2 again"
> ("after" script)
>
> I think there's a clue in there. It has the hallmarks of a race
> condition: As I understand it the autorepeat feature runs an "after"
> script which effectively presses the arrow again 5 ms later, invoking
> another "after" script, etc. A button release is supposed to kill the
> after script, but it might not do so in time, in which case it may try
> to kill something that already died, etc.
>
> Can't offhand see that we did anything to the event loop that could
> cause this, though.
>
Exactly the same behaviour on Fedora 7. Looping scrolling with 2.6.0+, no probs with 2.5.1.

Can probably eliminate OS issues and hardware then (2x3.2GHz, 64 bit SUSE vs. 600MHz, 32bit Fedora). Argh....

-- 
   O__  ---- Peter Dalgaard             Ă˜ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard_at_biostat.ku.dk)                  FAX: (+45) 35327907

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Tue 09 Oct 2007 - 20:46:13 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Thu 25 Oct 2007 - 11:37:10 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.