Re: Various clean-ups in stems and beams. (issue 6584045)

[marc]

http://codereview.appspot.com/6584045/diff/14002/input/regression/note-head-style.ly
File input/regression/note-head-style.ly (right):

http://codereview.appspot.com/6584045/diff/14002/input/regression/note-head-style.ly#newcode106
input/regression/note-head-style.ly:106: \override Staff.Stem.stencil =
#'()
Should this not rather read

\override Staff.Stem.stencil = ##f
or \omit Staff.Stem ?

http://codereview.appspot.com/6584045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Various clean-ups in stems and beams. (issue 6584045)

[m...@mikesolomon.org]

On 4 nov. 2012, at 08:22, m...@hohlart.de wrote:

> 
> http://codereview.appspot.com/6584045/diff/14002/input/regression/note-head-style.ly
> File input/regression/note-head-style.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/14002/input/regression/note-head-style.ly#newcode106
> input/regression/note-head-style.ly:106: \override Staff.Stem.stencil =
> #'()
> Should this not rather read
> 
> \override Staff.Stem.stencil = ##f
> or \omit Staff.Stem ?
> 
> http://codereview.appspot.com/6584045/

Fixed.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.pot polluted

[Federico Bruni]

Il 03/11/2012 19:04, Jean-Charles Malahieude ha scritto:

Hi John and all,

I just noticed that, because the out of tree build, lilypond.pot gets
polluted by personal path, what does not happen with an "in tree" build.

e.g. we get, when "out of tree" :

#: parser.yy:174 parser.yy:188 /home/jcharles/GIT/Mentor/lily/parser.yy:174
#: /home/jcharles/GIT/Mentor/lily/parser.yy:188
msgid "Too much lookahead"
msgstr ""

#: parser.yy:466 parser.yy:736 parser.yy:803
#: /home/jcharles/GIT/Mentor/lily/parser.yy:466
#: /home/jcharles/GIT/Mentor/lily/parser.yy:736
#: /home/jcharles/GIT/Mentor/lily/parser.yy:803
msgid "bad expression type"
msgstr ""


instead of just :

#: parser.yy:174 parser.yy:188
msgid "Too much lookahead"
msgstr ""

#: parser.yy:466 parser.yy:736 parser.yy:803
msgid "bad expression type"
msgstr ""




The full paths are obviously wrong, but relative paths (either to po/ or 
root tree) would be a benefit for translators, because po editors 
provide buttons which open the source file:line for each string.

Now the paths are missing and the editor can't find the file.

Translators are not developers, but sometimes looking at the context can 
help.  When I submitted my translation to the italian proofreader list, 
I received complaints about that.


Other projects I've contributed to use relative paths, so this should be 
possible.

--
Federico

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add alias in Spanish for espanol note names language (issue 6811060)

[David Kastrup]

Joram Berger  writes:

> Am 04.11.2012 00:17, schrieb David Kastrup:
>> Joram Berger  writes:
>>> Would it be an idea to add … "français" as aliases to "italiano"?
>>>
>>> According to my knowledge in French, the note names are the same and
>>> bémol/dièse also fits with the Italian abbreviations -b/-d.
>> 
>> I think they may be using "ut" instead of "do".
>> 
>
> I wondered, too. But from my experience when I was in France and from
> these sites, it is do. And ut is only an old form and do is the modern
> one (since the 17th century).
> http://fr.wikipedia.org/wiki/Note_de_musique
> http://fr.wikipedia.org/wiki/Ut_%28note%29

I have some Swiss accordion music here, written something like 1930 or
so and published by Schott, and they use "ut" for the French/Italian
version of the chord names.  The author would have been living in
Lausanne at that time.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add alias in Spanish for espanol note names language (issue 6811060)

[Nicolas Sceaux]

Le 4 nov. 2012 à 07:53, Joram Berger a écrit :

> Am 04.11.2012 00:17, schrieb David Kastrup:
>> Joram Berger  writes:
>>> Would it be an idea to add … "français" as aliases to "italiano"?
>>> 
>>> According to my knowledge in French, the note names are the same and
>>> bémol/dièse also fits with the Italian abbreviations -b/-d.
>> 
>> I think they may be using "ut" instead of "do".

Nowadays, we don't, except e.g. to name Mozart's mass: then we say
"La messe en ut".  But when saying the note names, it's "do".
"français" can be an alias to "italiano".

> I wondered, too. But from my experience when I was in France and from
> these sites, it is do. And ut is only an old form and do is the modern
> one (since the 17th century).

I'm currently typesetting a work by Rameau, from a heavily (I was about
to say evilly) corrected manuscrit.  Below one correction, a barely
readable note has been spelled to reduce confusion: "ut" (not "do").
So it seems that as far as 18th century, "ut" was somewhat still used to
name that note.

Nicolas


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Musicology Lectures

[James]

Hello,

I thought this might be of interest to some who transcribe old/ancient
editions of music, or to those who have a general interest in things
like 'composers intent'.

This is a single lecture - contains full transcript and video as well
as audio (reading the transcript it is obvious that some reference to
'projected' material is being made during the lecture - so maybe the
video would be better - but just having the transcript doesn't really
detract).

Anyway:

Overview:

Musical notation is both inexact and changeable; the assumptions of
one period may be lost on following generations, and the greater part
of written music still remains unpublished at the present day. The
challenges of editing and presenting a text, either of a well-known
classic or of an unknown writer differ in music from those faced in
the similar worlds of literature or Biblical criticism. The dilemmas
created by composers' second thoughts and revisions, and disciples'
'improvements' require a 'correct' way of presenting obsolete
information to the modern performer and raise questions which can both
change our attitude to familiar works and resurrect forgotten
treasures.

http://www.gresham.ac.uk/lectures-and-events/from-composer-to-printed-page

There are also a lot of other interesting Music-related (as well as
other diverse subjects - I stumbled across this while stumbling (I do
a lot of stumbling on the internet it seems!) over an interesting
lecture on the history of food publications.

Regards

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Releases 2.17.6 and 2.16.1

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: ; "David Kastrup" 
Sent: Saturday, November 03, 2012 9:57 PM
Subject: Re: Releases 2.17.6 and 2.16.1



On Sat, Nov 03, 2012 at 04:29:53PM -, Phil Holmes wrote:

I finished building 2.17.6 about 30 minutes ago.  Gub failed again,
but I know how to fix this manually and have done so, so it's ready
for upload.


I suggest a moratorium on releases until GUB works.  Too many
things can go wrong when manual steps are required.


TBH, I don't think I've ever had a completely problem-free GUB build, except 
when running the very long build from scratch.  As it stands, I do 
understand what's going wrong and the manual steps to correct that and am 
pretty clear that this is down to the signature problem.  A simple way to 
prevent it is to delete the signature directory, but I'd prefer to try to 
fix it.



I've just pushed a
commit to gperciva/gub that will likely fix this - although this is
somewhat "by inspection" so if anyone knows more of the internals of
gub and can comment, I'd be happy.


This looks questionable to me:

-NATIVE_BUILD_COMMITTISH=$(shell cat
$(LILYPOND_REPO_BRANCH_DIR)/refs/heads/$(LILYPOND_DIRRED_BRANCH))
+NATIVE_BUILD_COMMITTISH=$(shell cat
$(LILYPOND_REPO_DIR)/git/refs/heads/$(LILYPOND_DIRRED_BRANCH))

Isn't _BRANCH_DIR vs. _DIR how we distinguish between master and
release/unstable and stable/2.16 ?



Running lilypond make with the print target now prints out quite a lot of 
these variables.  It gives:


LILYPOND_DIRRED_BRANCH git.sv.gnu.org/lilypond.git/release/unstable
LILYPOND_FLATTENED_BRANCH git.sv.gnu.org--lilypond.git-release-unstable
BUILD_PACKAGE git://git.sv.gnu.org/lilypond.git?branch=release/unstable
DOC_PACKAGE git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable
TEST_PACKAGE git://git.sv.gnu.org/lilypond-test.git?branch=release/unstable
NATIVE_BUILD_COMMITTISH bcda814afef1e8e11a376fbac6d5367ffa78fcbd
LILYPOND_REPO_BRANCH_DIR 
downloads/lilypond/git.sv.gnu.org/lilypond.git/release/

LILYPOND_REPO_DIR downloads/lilypond

On my GUB system, there is no directory anything like 
downloads/lilypond/git.sv.gnu.org, so I'm unclear what 
LILYPOND_REPO_BRANCH_DIR is intended to point to.  As you see, 
LILYPOND_DIRRED_BRANCH points to foo/release/unstable, and I believe it is 
this that is used to distinguish the various buld targets.


On further inspection, I wonder whether it's an error of logic.  From 
lilypond.make, we have:


LILYPOND_REPO_BRANCH_DIR=$(LILYPOND_REPO_DIR)/$(dir 
$(LILYPOND_DIRRED_BRANCH))


and the original command for the committish was:

NATIVE_BUILD_COMMITTISH=$(shell cat 
$(LILYPOND_REPO_BRANCH_DIR)/refs/heads/$(LILYPOND_DIRRED_BRANCH))


so LILYPOND_DIRRED_BRANCH was effectively added to the path twice.  Can't 
see it would ever have worked - think you must have been deleting the 
signature files?


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Musicology Lectures

[Phil Holmes]

- Original Message - 
From: "James" 

To: "Devel" ; 
Sent: Sunday, November 04, 2012 11:26 AM
Subject: Musicology Lectures



Hello,

I thought this might be of interest to some who transcribe old/ancient
editions of music, or to those who have a general interest in things
like 'composers intent'.

This is a single lecture - contains full transcript and video as well
as audio (reading the transcript it is obvious that some reference to
'projected' material is being made during the lecture - so maybe the
video would be better - but just having the transcript doesn't really
detract).



Thanks - I'll definitely watch this after the Grand Prix...

--
Phil Holmes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add alias in Spanish for espanol note names language (issue 6811060)

[Francisco Vila]

2012/11/4 David Kastrup :
> Eluze  writes:
>
>> Joram Berger wrote
>>> As far as I see, there is no language "french" or "français".
>>> Would it be an idea to add "french", "francais" and "français" as
>>> aliases to "italiano" (like "español" above)?
>>
>> do you really want to add /francais/?
>
> It's not likely more scary to the French than "espanol" is to the
> Spanish.

Exactly.

>  Basically there are two options making sense to me: native
> language name in utf-8, or English language name ("french", "spanish").
>
> But misspelled native language name seems unattractive as primary
> interface.

They are non-existant words in any language. We should keep them for
some time for compatibility and warn about deprecation. I added
'español' as a proof of concept without taking into account other
languages. Then, if we want (I think yes) to add more aliases, it can
be implemented better than repeating the trick for each. I can do it
later.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add alias in Spanish for espanol note names language (issue 6811060)

[David Kastrup]

Francisco Vila  writes:

> 2012/11/4 David Kastrup :
>> Eluze  writes:
>>
>>> Joram Berger wrote
 As far as I see, there is no language "french" or "français".
 Would it be an idea to add "french", "francais" and "français" as
 aliases to "italiano" (like "español" above)?
>>>
>>> do you really want to add /francais/?
>>
>> It's not likely more scary to the French than "espanol" is to the
>> Spanish.
>
> Exactly.
>
>>  Basically there are two options making sense to me: native
>> language name in utf-8, or English language name ("french", "spanish").
>>
>> But misspelled native language name seems unattractive as primary
>> interface.
>
> They are non-existant words in any language. We should keep them for
> some time for compatibility and warn about deprecation. I added
> 'español' as a proof of concept without taking into account other
> languages.

I think we should have the English aliases as well.  After all, all the
rest of the LilyPond language is based on English, so accepting the
language names in English seems reasonable, and it provides a way of
writing ASCII-only input.

Language names in LaTeX are english, german, french, spanish ... so at
least the people using Lilypond-book in connection with LaTeX will have
some naive expectation work out when using these aliases.

And frankly, I consider

\language "deutsch"

a slightly odd combination.

> Then, if we want (I think yes) to add more aliases, it can be
> implemented better than repeating the trick for each. I can do it
> later.

Something like define-language-alias, probably.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Busy Developer's Summary 4: please help!

[Janek Warchoł]

Hi people,

this week i was reading the lists quite randomly and i don't know what
should be in the summary apart from the information that commit
f25b23eb6fbbf83489dfac39f1908ab13a75b4b9
updated all our documentation with new "#'-less" syntax (~700 files
changed, ~7000 lines in total).

what else should be here?
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Busy Developer's Summary 4: please help!

[David Kastrup]

Janek Warchoł  writes:

> Hi people,
>
> this week i was reading the lists quite randomly and i don't know what
> should be in the summary apart from the information that commit
> f25b23eb6fbbf83489dfac39f1908ab13a75b4b9
> updated all our documentation with new "#'-less" syntax (~700 files
> changed, ~7000 lines in total).
>
> what else should be here?

The update involved a number of changes to bring the music function APIs
in line with the change, its possibilities and restrictions.  You can
probably just siphon off the information from
http://codereview.appspot.com/6813079>.  It did not appear yet in
2.17.6.

2.17.6 is released.  Probably looking at the issue tracker by using the
"Modified" column (you need to press the ... column to get it offered)
as a sorting criterion will help you see which issues have been touched
(be sure to search "All issues" rather than "open issues") will help you
figure out what issues saw work (and or fixes or commits) in that time
span:

http://code.google.com/p/lilypond/issues/list?can=1&q=&sort=-modified&colspec=ID+Type+Status+Stars+Owner+Patch+Needs+Summary+Modified&x=type&cells=tiles>

2.16.1 has had its translations finished as far as I can see and I still
need to evaluate a few things to decide what to include and what to
revert for 2.16.1.  So it is expected early next week.

There were two different patch proposals for permitting numbers into
identifiers, both using non-obvious special forms of identifiers.  Both
have been put on hold for now as there may be better solutions depending
on ongoing work possible at a later point of time.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Design flaw in Rest_collision

[m...@mikesolomon.org]

Hey team,

I finally had a couple hours to get back into LilyPond development and, as 
often happens after a pause, I immediately ran into something that I hadn't 
spotted before and that needs fixing.

If a Rest being managed by a RestCollision, a call to Grob::extent with any 
common refpoint other than the Rest itself will trigger at some point 
Rest_collision:calc_positinioning_done which itself looks up Rest extents at 
line 168.  This is a circular dependency.

If I'm reading this wrong then let me know, but if not, it needs to be fixed.  
Otherwise, getting a rest's extent can randomly lead to circular dependencies.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Various clean-ups in stems and beams. (issue 6584045)

[aleksandr . andreev]

http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly
File input/regression/kievan-notation.ly (right):

http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly#newcode12
input/regression/kievan-notation.ly:12: c4 c4 c8 [ d8 ] c4 c2 b,\longa
We should add an unbeamed eighth note to the regtest, since its correct
appearance is now controlled by

note-head::calc-kievan-duration-log

Maybe something like

c4 c8 c8[ d8] c4 c2 b,\longa

http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly
File input/regression/note-head-style.ly (right):

http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly#newcode108
input/regression/note-head-style.ly:108: \override Staff.Dots.style =
#'kievan
Why can't we use the new function here, e.g.,

\kievanOn

http://codereview.appspot.com/6584045/diff/13014/ly/engraver-init.ly
File ly/engraver-init.ly (right):

http://codereview.appspot.com/6584045/diff/13014/ly/engraver-init.ly#newcode1150
ly/engraver-init.ly:1150: \override Stem.length = #0.0
It seems like we also need something like:

\override Flag.stencil = ##f

Otherwise "flags" appear on Kievan eighth notes.

http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly
File ly/property-init.ly (right):

http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly#newcode310
ly/property-init.ly:310: \override Stem.length = #0.0
Also need here:

\override Flag.stencil = ##f

http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly#newcode323
ly/property-init.ly:323: \revert Stem.length
And here:

\revert Flag.stencil

http://codereview.appspot.com/6584045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Various clean-ups in stems and beams. (issue 6584045)

[aleksandr . andreev]

On 2012/11/03 18:21:09, mike7 wrote:

On 3 nov. 2012, at 12:26, mailto:d...@gnu.org wrote:



>

http://codereview.appspot.com/6584045/diff/1/scm/output-lib.scm#newcode85

> scm/output-lib.scm:85: (left-height (if (= direction DOWN)
> Is direction sure to be non-null?
>



Thanks again for the review.  Aleksandr can respond to this better

than I can.


Cheers,
MS



Sorry for the delay in responding -- weekends are always very busy for
me. The default direction is set to DOWN in Beam::calc_direction,
starting on line 291.

http://codereview.appspot.com/6584045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Various clean-ups in stems and beams. (issue 6584045)

[aleksandr . andreev]

http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly
File input/regression/kievan-notation.ly (right):

http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly#newcode13
input/regression/kievan-notation.ly:13: \bar "kievan"
Sorry, I missed one more thing.

Evidently, after 2790, this line should now be:
\bar "k"

http://codereview.appspot.com/6584045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Design flaw in Rest_collision

[Keith OHara]

mike  mikesolomon.org  mikesolomon.org> writes:

> If a Rest being managed by a RestCollision, a call to Grob::extent with any 
> common refpoint other than the Rest itself will trigger at some point 
> Rest_collision:calc_positioning_done ...
> 

Not more than once.
rest-collision.cc:calc_positioning_done() sets 'positioning-done' to true,
presumably to indicate that it has taken responsibility for positioning all
the rests within this RestCollision object.

Rests in outer voices do not often need to move to avoid rests in inner
voices, but when they do, it seems to work correctly:

\new Staff \with {\override StaffSymbol #'staff-space = 0.7 } <<
 \new Voice {\voiceOne r2 g''2}
 \new Voice {\voiceThree r4 e''4 c''2}
 \new Voice {\voiceFour r4. e'8 g'2}
 \new Voice {\voiceTwo r2 c'2} >>



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Gub pango-1.26.0-darwin-cx-font.patch

[Jeremiah Benham]

Does anyone know what happened to this patch pango-1.26.0-darwin-cx-font.patch. 
I
don't see it in ./patches/ . I built denemo for mingw, darwin, and linux 
targets.
Unfortunately I am having font issues with pangocairo with darwin. I am 
wondering
if this patch will fix this.

Thanks,
Jeremiah




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCH: Countdown to 20121106

[Colin Campbell]

For 20:00 MST Tuesday November 6

Enhancement:
Issue 2933 : 
allow optional octavation signs for clefs - R 6813044 

Issue 2944 
: Patch: Gobble 
empty strings passed as arguments to python scripts - R 6819066 

Issue 2945 
: Patch: 
Document symbol list changes. - R 6813079 



Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Design flaw in Rest_collision

[m...@mikesolomon.org]

On 5 nov. 2012, at 00:42, Keith OHara  wrote:

> mike  mikesolomon.org  mikesolomon.org> writes:
> 
>> If a Rest being managed by a RestCollision, a call to Grob::extent with any 
>> common refpoint other than the Rest itself will trigger at some point 
>> Rest_collision:calc_positioning_done ...
>> 
> 
> Not more than once.
> rest-collision.cc:calc_positioning_done() sets 'positioning-done' to true,
> presumably to indicate that it has taken responsibility for positioning all
> the rests within this RestCollision object.
> 

True.  This avoids circular dependencies for the positioning done property, and 
the translate_axis call in force_shift_callback_rest avoids circular dependency 
issues for Y-offset, but there is no protection against circular dependencies 
for the extents.

> Rests in outer voices do not often need to move to avoid rests in inner
> voices, but when they do, it seems to work correctly:
> 
> \new Staff \with {\override StaffSymbol #'staff-space = 0.7 } <<
> \new Voice {\voiceOne r2 g''2}
> \new Voice {\voiceThree r4 e''4 c''2}
> \new Voice {\voiceFour r4. e'8 g'2}
> \new Voice {\voiceTwo r2 c'2} >>
> 

I'm having trouble forcing this to come to the surface - I can only get it to 
trigger in some experimental work.  However, I'm positive that the circular 
dependency exists.  Here's a reduction of what's going on.

1) rest->extent (common, Y_AXIS)
2) Rest::height
3) Rest::generic_extent_callback
4) Rest::brew_internal_stencil
5) Rest::glyph_name
6) Staff_symbol_referencer::get_position
7) rest->relative_coordinate (common, Y_AXIS);
8) Rest_collision::force_shift_callback_rest
9) Rest_collision::calc_positioning_done
10) rest->extent (common, Y_AXIS)

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Design flaw in Rest_collision

[m...@mikesolomon.org]

On 5 nov. 2012, at 06:51, m...@mikesolomon.org wrote:

> 1) rest->extent (common, Y_AXIS)
> 2) Rest::height
> 3) Rest::generic_extent_callback
> 4) Rest::brew_internal_stencil
> 5) Rest::glyph_name
> 6) Staff_symbol_referencer::get_position
> 7) rest->relative_coordinate (common, Y_AXIS);
> 8) Rest_collision::force_shift_callback_rest
> 9) Rest_collision::calc_positioning_done
> 10) rest->extent (common, Y_AXIS)

A better way to describe it just to wrap heads around it, with the circular 
dependency underlined:

Rest extents depend on their stencil.  This stencil depends on placement on/off 
the staff.  Placement may depend on the placement of other rests.  To calculate 
the placement of other rests, we need to shift all of them.  The amount of 
space one must shift depends on the extent of the rest.

Does anyone see a way to break it?  Or am I thinking through this wrong?

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel