Re: broken doc build (orchestra.ly)

[James Lowe]

On 21/05/16 10:38, David Kastrup wrote:
> James Lowe <address@hidden> writes:
>
> > David,
> >
> > On 20/05/16 17:38, David Kastrup wrote:
> > > James <address@hidden> writes:
> > >
> > > > I don;t know what the lilypond.pot stuff does but could that have been
> > > > the problem?
> > > Unlikely.  I think it may be the distribution of files across parallel
> > > builds, where the few snippets using the Scheme_engraver poison the
> > > session so that it crashes during an unrelated snippet (or when exiting)
> > > later on.
> > >
> > > That is, if we can show that the Scheme_engraver code actually gets
> > > exercised during the runs that crash.
> > Well if you need me to try some 'hacked up' code or try some specific
> > compilation options etc. to get output for you, let me know.
> >
> > All I can say to Knut is that, for the last couple of days anyway, the
> > 'problem' seems to have gone away.
> Garbage collection problems are elusive.  I was surprised that Knut was
> able to reproduce them well enough for bisection (though bisection does
> not employ much redundancy if at all, so if a problem triggers randomly,
> you'll still end up with a particular commit labelled as culprit).
>
> At any rate, Werner had pushed a spelling correction commit that ended
> up staying in staging for a looooong time (days I think) but then got
> passed to master pretty fast once _another_ commit was pushed on top of
> it.
>
> That also reeks a bit of Patchy failure for sort-of random but
> reproducible conditions.  At any rate, I pushed a slightly amended patch
> for issue 4851 now.  _If_ it was a garbage collection issue on some
> topic I suspected, it might make the problem go away.  Let's hear from
> Knut.

My make doc issue has come back :(

Taking a few more minutes to try and diagnose the problem - it is the 
same again, as Knut had. With the same error on processing orchestra.ly.

This file in ../ly-examples/ is used only for the examples page of the 
website but I cannot fathom how to 'build' that small section of the 
website on its own as I can when I test lilypond-book sections while 
doing doc edits (i.e. create a small, standalone .tely file and then run 
lilypond-book against it).

So all I could do was compile LP and run it against orchestra.ly 
(including dpreview=t - or use --png option) as this file is only used 
to generate a png for the website.

I get this (after copying orchestra.ly to test.ly outside of the LP dir):

--snip--

address@hidden ~]$ lilypond --pdf -dpreview=t test.ly
GNU LilyPond 2.19.43
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
programming error: cyclic dependency: calculation-in-progress 
encountered for #'adjacent-pure-heights (VerticalAxisGroup)
continuing, cross fingers
programming error: cyclic dependency: calculation-in-progress 
encountered for #'adjacent-pure-heights (VerticalAxisGroup)
continuing, cross fingers
programming error: cyclic dependency: calculation-in-progress 
encountered for #'adjacent-pure-heights (VerticalAxisGroup)
continuing, cross fingers
programming error: cyclic dependency: calculation-in-progress 
encountered for #'adjacent-pure-heights (VerticalAxisGroup)
continuing, cross fingers
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-M4Tdno'...
Converting to `test.pdf'...
Deleting `/tmp/lilypond-M4Tdno'...
Success: compilation successfully completed

--snip--

Thinking this programming error was something to do with it, I rolled 
back my git to a couple of versions back when it was all seemingly OK 
but I still get the same programming error, so while that is not ideal, 
it is not unusual - I believe I reported (and created issues) for some 
programming errors being reported when we compile some of the xml files.

Again, I am stumped.

--
--

James