On Sat, Sep 15, 2012 at 2:25 AM, <[email protected]> wrote: > Hey all, > > In my quest to debug issue 2801, I stumbled upon behavior in LilyPond that > is non-deterministic. You'll see four attached files: a simple diff to > apply to current master, two .ly files, and a python script to run in the > same directory as the LilyPond files. > > 1) Apply the diff and compile. The diff prints out the name of a grob and > its extent to stderr every time Grob::extent is called. > 2) Download the files and the python script to the same directory. Change > the Lilypond executable in the python script as need be. The python script > overwrites log0.txt and log1.txt, so make sure you don't have important > files named that. > 3) Oscillate between foo.ly and bar.ly in the python script. > > foo.ly is deterministic whereas bar.ly is not. bar.ly will usually > produce non-deterministic behavior before it hits 20 runs. > > The only difference between the two files is the presence of a slur. > > As a test, I rewound Lilypond to 26e8b94f358244216a83c1a6653d5a72c1a1c5e7 > (about 2 years ago) and did the same thing - it is still not deterministic, > but at different points in the compilation process. > > I realize that LilyPond may be using containers that do not guarantee the > order of things (i.e. sets) and that the test I've written may not be a > good reflection of what "deterministic" should mean. However, for > debugging purposes, I think it's important that when LilyPond compiles the > same score, the extents measured and the order in which they're measured > remain constant. Otherwise, finding changes in extents, offsets, and > skylines is difficult. > > I think it's important to get 2-3 people brainstorming to figure out where > and why this is happening. >
There are some places where we sort by pointer (for example, in Grob_array::remove_duplicates). _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
