Pierre Perol-Schneider <pierre.schneider.pa...@gmail.com> writes: > 2014-07-02 12:13 GMT+02:00 David Kastrup <d...@gnu.org>: > > >> However, this fix does not have regtests. I would appreciate it if you >> could cook up a few short but difficult use cases for placing in the >> regtests. >> > > In order to find a sort of inspiration I've just re-wrote some snippets > from the regression in parallelMusic mode.
[a dozen rewrites] Uh, wow. Now it would be overkill to add all of them, and it also would be strange to _replace_ all of them: \parallelMusic is a somewhat specific feature and somewhat hackish at that, so I would not want to have a lot of tests intended to check something else depend on it (we have things like \relative that get a _lot_ of incidental testing through unrelated regtests, but I don't like \parallelMusic enough for that). I'll look through those and see which ones seem to be important. Of course, one important criterion would be that they pass after this patch though not before. If they pass before, they don't test for the versatility this patch should have provided. If they don't pass afterwards, of course I want to take a look as to why... Did you check the resulting snippets, or was this a "dry run"? If you did check, I don't need to do so myself. > Hope I'll find something better tomorrow. Well, a good regtest should be thorough with regard to the tested feature and keep to reasonably basic constructs otherwise. It should also be simple to make a good guess from description and result whether it does what is intended. The guitar examples I have seen in this thread (and the old 2009 one) are actually not bad as an indicator since they make a lot less musical sense when \parallelMusic breaks down. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user