On Tue, 2006-06-06 at 10:17 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> > On Tue, 2006-06-06 at 09:18 +0200, Han-Wen Nienhuys wrote:
> >> Joe Neeman schreef:
> >>> Just to make things a bit weirder, I have a working copy with
> >>> modifications that _should_ be completely irrelevant (the
> >>> spacing-stick-out patch). In this working copy, I get the second png
> >>> file no matter what.
> >>>
> >>> Can anyone shed light on this?
> >> This could be a nasty bug caused by GC interactions. When you do "make
> >> web" the file is compiled between 400 others, and memory management
> >> errors might trigger some problems. Which version of GUILE do you run?
> >
> > 1.6.7, strangely enough. I could have sworn I got 1.8.0 working...
OK, I have a snapshot of 1.8.0 working, but that doesn't help. It has
something to do with the sorting of elements. As far as I can tell, this
is what's happening:
InstrumentName Piano's support contains
VerticalAxisGroup's elements contains
InstrumentName Right's support contains
VerticalAxisGroup (the same one!)
So if we call Piano->get_offset, it calls VerticalAxisGroup->extent,
which calls Right->get_offset, which calls VerticalAxisGroup->extent
which is a calculation-in-progress, so we get any empty interval.
If we call Right->get_offset _before_ we call Piano->get_offset,
VerticalAxisGroup is not a calculation-in-progress, so we get the actual
extent. That is, we get different answers depending on the order in
which we call things.
My workaround is not to add VerticalAxisGroups to the support of
InstrumentNames. (ie comment out instrument-name-engraver.cc:76). This
seems to work OK because the support still contains the various
SystemStartXXX which are to the left of the staff anyway.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
