String gui - sounds promising for multiple reasons. - A lot of my work's on plugins, which aren't really covered by unit tests. But when I do want to run unit tests, it's a hassle because usually 10ish fail on my system from master, i.e. before testing my changes. So I have to commit, checkout master, count failing tests, checkout changes, check count hasn't changed. This is bad test wise because I don't check that the *same* tests are failing, although it's unlikely I'd introduce a problem that didn't increase the number of failures.
Really a long winded statement of a known issue, not all unit tests run on all systems. - I wonder if the string gui would be an entry point for super light weight implementation of interfaces for Leo (~embedded Leo). leoBridge is sort of such an entry point, but I think it only gives you c, p, p.h/p.b etc. - there's no abstraction of things like selected range etc. Sounds like the string gui would have such abstractions. Not sure, but wonder if that might turn out to be very useful. Cheers -Terry On Tue, 13 Jun 2017 06:59:33 -0700 (PDT) "Edward K. Ream" <edream...@gmail.com> wrote: > 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
