This post will be me thinking out loud. Feel free to ignore.
*Background*
On my fastest machine, all unit tests run in 34 seconds when using the
curses gui, compared with 59 seconds when using the Qt gui. I spend a lot
of time running unit tests, and it would be worthwhile to increase their
speed. Also, redrawing the screen with qt makes unit tests fragile: they
can fail if focus changes while tests are running.
All guis represent Leo's *visual elements* (log, body, and tree frames,
minibuffer, dialogs, etc.). Various unit tests depend on the properties of
those visual elements (and especially Leo's underlying data structures) in
various not-too-clear ways. An important aim of this project is to clarify
these hidden relationships.
*The idea*
Unit tests might run more quickly than even the curses gui by running unit
tests with a *string gui*, a gui that represents all visual elements by
strings only (along with ints representing insert point and selection
range). In that case, redrawing would be a do-nothing. Visual elements
would be represented by subclasses of the leoFrame.StringTextWrapper class,
a simple and thoroughly tested class.
*New and deprecated commands*
*If* this new scheme can be made to work, there would be three new commands:
run-all-unit-tests-with-string-gui
run-marked-unit-tests-with-string-gui
run-selected-unit-tests-with-string-gui
The run-*-unit-tests-locally commands must be retains so we can test the
real qt (or curses) gui when the gui code changes. However, I am thinking
of deprecating the run-*-unit-tests-externally commands. I hardly ever use
them, and I have forgotten why I thought they ever were useful. Perhaps
they run faster :-)
*Summary*
This is a highly experimental project. Just disabling redraws causes lots
of tests to fail. It remains to be seen whether using a string gui will
compromise important unit tests.
But regardless of outcome, there will be gains resulting from deep study of
the code:
1. Recent revs have removed all code associated with the _editPosition ivar
and editPosition and setEditPosition methods of various (subclasses) of the
LeoFrame class. Such do-nothing ivars and methods are pure cruft, and they
can be very confusing.
2. Study of the code and failing unit tests, will reveal subtle
interactions between the unit tests, the gui redraw code and Leo's core.
I'll be documenting what I find.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
