Re: Current master non-deterministic

[Joe Neeman]

On Sat, Sep 15, 2012 at 2:25 AM, <address@hidden> 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).