Tk Source Code

I've done more experimenting with the latest test script bind-35.1.

My initial interest was to detect the effect of possibly varying initial conditions (e.g. position of the mouse pointer).

The experiment is governed by two scripts which have been attached. Essential to the experimental procedure is the consecutive execution of tests. This aspect of consecutive execution is dual in nature:
- as invocation of consecutive wish/tclsh executables (os processes), governed by "inspect-master"
- as consecutive tests within a single run of the test harness, governed by "inspect-multirun"

The script "inspect-master" is responsible for a reproducible test script invocation (twice in succession as configured now). The script "inspect-multirun" carries out the test (again multiple runs) inside the tcltest harness. "inspect-master" invokes sub-processes that in turn source "inspect-multi-run"

Attached you find the experimenting scripts and the test-scripts inspected by them.

Also attached, you find the output for several inspection runs on my systems. From these output files you can see that the latest test script in the bug-fix branch of Fossil (attached as "test-fvogel.tcl") still doesn't fail in all unpatched circumstances on my systems. Also, on my Linux system, 3 out of 4 times the test script doesn't pass for patched code.

I've added a modified test script (test-fvogel-modified) and its inspection results. On my linux system, this scripts fails in unpatched code where the unmodified script passes. However on my Windows 7 system, it doesn't perform better overall.Nevertheless, this might give you some clue about the reason for it not failing where it should (on Linux).

Also I've added a slightly adjusted copy of my original test script (test-elns.tcl), which behaves as expected, but which is still overly safe in allowing time for screen updates (but not as exceedingly as the original). I did this to have a double-check and reference case for actually having tested patched/unpatched code as intended.


Additional particulars
======================

I've seen an anomaly when warping the mouse pointer to the upper-left corner of the screen (0,0) or (1,1). This is specific to my Linux desktop KDE, which has a desktop widget fixed at that position. This widget wakes up as soon as the mouse pointer is over that position and deiconifies all windows of any program on the desktop, thus possibly spoiling test runs. Maybe it's wise to avoid that position (allowing a certain margin of inaccuracy). In fact, this remark concerns all corners and borders of the screen, since that's where desktops attach their specific functionality (docks, taskbar, ...).

=*=