On 22/05/16 13:04, Phil Holmes wrote:
----- Original Message ----- From: "James Lowe" <[email protected]>
To: "David Kastrup" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, May 22, 2016 12:53 PM
Subject: Re: broken doc build (orchestra.ly)
On 21/05/16 10:38, David Kastrup wrote:
James Lowe <[email protected]> writes:
David,
On 20/05/16 17:38, David Kastrup wrote:
James <[email protected]> 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--
[james@fedorahome ~]$ 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.
I think it's likely to be what David was guessing at - David's "Issue
4842/6: Don't special-case Scheme_engraver's acknowledgers" has
affected garbage collection somehow, and this affects different
systems in different ways, because of the way the OS handles memory
allocation.
You might try rolling back to before that commit and see whether you
are OK. If so, there's an argument (I think) for Davis to revert it
until we're on firmer ground checking what it happening with make doc.
OK I'll give that a go and roll back to the commit just before all the
4842/* ones - in case I cannot just roll back to before the 4842/6 and
not break something dependent in the other 4842 changes.
I'll run it now but have to run out for an hour or so, so will report
back when I get back.
I'll try to keep an eye on staging to advance other patches as required.
Thanks,
--
Phil Holmes
--
--
James
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
