I get this: Starting program: /home/rshann/local/bin/denemo -n -a "(d-Critical \"Critical error\")(d-Quit)" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Denemo - MESSAGE : Loading preference file: /home/rshann/.denemo-1.1.1/denemorc Denemo - MESSAGE : Denemo version 1.1.1 Denemo - MESSAGE : Loaded keymap /home/rshann/git-denemo/denemo/actions/Default.commands Arranger Profile Denemo - CRITICAL: Critical error [Inferior 1 (process 12323) exited normally] (gdb)
Richard On Tue, 2013-12-17 at 16:54 +0100, Éloi Rivard wrote: > Well I might have an idea. I have set the level of scheme errors from > Warning to Critical. Maybe in your configuration Critical warnings are > fatal (i.e. kills the program). > > > If you run denemo -n -a "(d-Critical \"Critical error\")(d-Quit)", > does your program ends normally or fail ? > > > > 2013/12/17 Richard Shann <[email protected]> > On Tue, 2013-12-17 at 14:50 +0100, Éloi Rivard wrote: > > Hi, > > > > I have some good news, I added a test named "coverage" that > reads > > Defaults.commands and tests every command it finds in it > (1012 tests > > for the moment). For each command the tests checks if > > coverage-data/COMMAND.scm exists, and execute it if it > exists. Else it > > simply launch denemo with '-a "(d-COMMAND)(d-Quit)". > > > > > > This is still a very weak test, since there is no argument > passed to > > the commands, and since that results are not checked. But at > least it > > can check for some segfaults. This test double our test > coverage (we > > were around 10% now, we are at 20%). The coverage test is > very long. > > > > > > To keep things clean, a test should be created every time a > command is > > created (in tests/coverage-data/COMMAND.scm). Tests should > be as > > simple as possible, and provoke failure when the result > obtained is > > not the one expected. > > > > > > More generally, each implemented feature and each fixed bug > should > > have its own test. > > > > > > > > Next step is to also test builtin functions declared in > > scheme-identifiers.c and find a way to run GUI tests, and > add some > > unit tests for often used functions. > > > This is excellent stuff. A couple of points - one is there is > a > deliberate scheme error generated in the score-checking > command (a bad > idea of course). And, I have had Denemo terminate recently as > a result > of scheme errors, which it never did with the old handler. I > haven't > been able to figure out the conditions when this happens, but, > of > course, it makes it very difficult to find this out. > > Richard > > > > > > > -- > Éloi Rivard - [email protected] > > « On perd plus à être indécis qu'à se tromper. » > _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
