2009/6/16 Pavel Sanda <[email protected]>: >> I have created a version that actually has documentation: >> >> www.ucc.asn.au/~mccabedj/lyxtestc.tar.gz > > nice. can you post permission like this to the devel list? > http://marc.info/?l=lyx-devel&m=119072721929143
I hereby grant permission to licence my contributions to LyX under the Gnu General Public Licence, version 2 or later. > i will commit your work to the trunk/development/keytest. would it be ok > to move the development of scripts here? Sure. >> > btw John if you are getting those crashes through the script would it be >> > possible >> > to log keys which lead to the crash and thus giving us some clue howto >> > reproduce? >> >> Yes. I logged 6.1MB of keystrokes. I'm adding in timestamps so we can >> compare time of crash with the time of crash. > > ugh. this is not reproducible. i think two things needed for usability: > 1. each bug one file of keystrokes > 2. backtrace mode to reduce number of keystroke. something like try if crashes > last step, if not kill lyx and try two steps, 4 steps, 8, 16 ... or some > similar kind of bisection. > >> > if its too much keys, it maybe possible to automatize searching for subset >> > of keys >> > interval which leads to the crash... >> >> Yes even given that many of these crashes may be intermittent, it >> sounds feasible to develop some sort of evolutionary algorithm. We >> don't even need to create new genes, just discard. > > i have in mind only very simple thing as noted in poin 2 above. I was thinking that we would have an array for keycodes. Randomly pick i,j and remove i...j inclusive from the array of keycodes. If it does not crash, replace i...j to their original positions. Repeat until the user stops the process or the last 100 iterations didn't remove any keycodes. I imagine that even for intermittent faults this would give a fairly minimal array after a few hours. -- John C. McCabe-Dansted PhD Student University of Western Australia
