Re: 2.17.6: assertion failed with \glissando

[Werner LEMBERG]

>> Werner Lemberg reported an assertion failure on his own build of
>> 2.17.6 here:
>>
>> http://lists.gnu.org/archive/html/bug-lilypond/2012-11/msg00047.html
>
> Werner, if this is reproducible it will need a tracker and patch and
> everything to go through the review process.  (I realize you
> probably know this).  Just want to make sure all your sleuthing
> doesn't get lost.

Well, while it is my bug report, Keith has written a patch (is it a
patch at all?  or does it just circumvent the assertion).  I don't
understand the code, and I unfortunately, have not enough time to
learn the details, so I think it is rather Keith who should file a
Rietveld issue because I can't provide improved versions of the
patches, etc.

I've filed an issue:

  http://code.google.com/p/lilypond/issues/detail?id=2983


 Werner

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

PATCH: Countdown to 20121129

[Colin Campbell]

For 20:00 MST Thursday November 29

Documentation:
Issue 2980 
: LM doc files 
in language subdirectories are incomplete and Issue 2967 
: 
@unnumberedsubsubsec should always have an accompanying @node - R 
6852077 


Enhancement:
Issue 2974 
: Patch: 
music-functions-init.ly: Avoid unnecessary use of $ instead of # - R 
6844077 
Issue 2978 
: Patch: 
Simplify calculation of pitch-alist in determine-frets-and-strings - R 
6842095 
Issue 2976 
: Patch: Allow 
ly:grob-set-nested-property! to set a single (unnested) property - R 
6847098 
Issue 2977 
: Patch: Allow 
tweaks to deal with setting nested properties. - R 6849098 

Issue 2975 
: Patch: 
beam.cc: let a loop run backwards for better Scheme-fu - R 6847096 

Issue 2973 
: Patch: 
parser.yy: give check_scheme_arg optional argument for error display - R 
6850095 


Ugly:
Issue 2527 
: Finger-flag 
collision - R 6827072 


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: Issue 2916: Document \hide and \omit (issue 6851102)

[dak]

On 2012/11/26 21:53:09, Trevor Daniels wrote:


I think you've chosen the best way forward here.


Calling a strategic retreat "the best way forward" might be putting a
bit of a spin on it.  It would have been prohibitively costly for the
ground forces to secure the conquered areas.

http://codereview.appspot.com/6851102/

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

Re: Issue 2916: Document \hide and \omit (issue 6851102)

[tdanielsmusic]

On 2012/11/26 10:03:27, dak wrote:


I agree that the effect that this has here is not really harmonizing

well with

\override (which does not allow a context spec inside of context mods,

and will

not silently ignore Bottom overrides in non-Bottom contexts), so it

might make

sense to just drop this (not-really-yet-reached) design goal and the

associated

"picky" context modifications which are not really documented on the

user or

even the concept level.


I think you've chosen the best way forward here.  Thanks.
So LGTM.

Trevor



http://codereview.appspot.com/6851102/

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

Re: markup-commands rest-by-number and rest (issue 6850073)

[thomasmorley65]

On 2012/11/26 15:09:58, benko.pal wrote:

> So I'd suggest not treating the '-' at all (to make things not more
> confusing than they already are) and letting the font backend sort
> things out.



I concur.


Ok, I'll try.


http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm

File scm/define-markup-commands.scm (right):



http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm#newcode3251

scm/define-markup-commands.scm:3251: (or multi-measure-rest (< log

1)))

there are no Petrucci rest glyphs at all; use mensural without any

further

condition.  or don't even allow petrucci as style for these markups.


Well, writing this conditions I tried to orientate myself on
`select-head-glyph´ from output-lib.scm
`select-head-glyph´ returns note-head-glyphs for some styles without
defined note-head-glyphs as well. Mostly if (< log 1)
So I tried to transfer this behaviour to rests.

Did you had a look on the compiled output of the new reg-tests?
This output is what I tried to achieve.
You'll see that for some styles mensural- or neomensural-glyphes are
taken, others are defaulting.

The main question is:
If there are no defined glyphs for a specific style,
should I try to select others (currently tried)
or
should I return default-glyphs (I suspect this would be much easier)?

Opinions?


http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm#newcode3299

scm/define-markup-commands.scm:3299: ;; If there is a ledger, move the

dots in

X-direction to avoid collision.
is this comment true?  I can't see how the condition below checks for

ledger.

You're right, the comment is misleading.
I selected ledgered glyphs for whole and half rests for all styles,
apart from the listed ones.
Depending on the decision which glyphs are taken (see above), I'll
change the comment and/or the code.


http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm#newcode3305

scm/define-markup-commands.scm:3305: (and (= log 1) (equal? style

'petrucci

this check looks fishy, as there are no Petrucci-style rest glyphs.


Same problem as above:
Which glyph to take, if there's none for the specified style.



http://codereview.appspot.com/6850073/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: markup-commands rest-by-number and rest (issue 6850073)

[benko . pal]

So I'd suggest not treating the '-' at all (to make things not more
confusing than they already are) and letting the font backend sort
things out.


I concur.


http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm#newcode3251
scm/define-markup-commands.scm:3251: (or multi-measure-rest (< log 1)))
there are no Petrucci rest glyphs at all; use mensural without any
further condition.  or don't even allow petrucci as style for these
markups.

http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm#newcode3299
scm/define-markup-commands.scm:3299: ;; If there is a ledger, move the
dots in X-direction to avoid collision.
is this comment true?  I can't see how the condition below checks for
ledger.

http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm#newcode3305
scm/define-markup-commands.scm:3305: (and (= log 1) (equal? style
'petrucci
this check looks fishy, as there are no Petrucci-style rest glyphs.

http://codereview.appspot.com/6850073/

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

Re: markup-commands rest-by-number and rest (issue 6850073)

[dak]

On 2012/11/26 11:51:03, dak wrote:

On 2012/11/26 11:37:26, benko.pal wrote:



> I just meant that instead of checking several times whether dealing

with

> multi-measure rest or not, you may convert duration log at a single

place

(with
> the caveat of turning a negative sign to 'M' instead of '-').



Probably even without the caveat.  I think that some code fairly close

to the

font backend does this conversion.  I remember distinctly going nuts

over those

character names at some point of time because I could not figure out

why a minus

did not cause problems.


lily/font-metric.cc:

Stencil
Font_metric::find_by_name (string s) const
{
  replace_all (&s, '-', 'M');

So I'd suggest not treating the '-' at all (to make things not more
confusing than they already are) and letting the font backend sort
things out.

http://codereview.appspot.com/6850073/

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

Re: markup-commands rest-by-number and rest (issue 6850073)

[dak]

On 2012/11/26 11:37:26, benko.pal wrote:


I just meant that instead of checking several times whether dealing

with

multi-measure rest or not, you may convert duration log at a single

place (with

the caveat of turning a negative sign to 'M' instead of '-').


Probably even without the caveat.  I think that some code fairly close
to the font backend does this conversion.  I remember distinctly going
nuts over those character names at some point of time because I could
not figure out why a minus did not cause problems.

http://codereview.appspot.com/6850073/

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

Re: markup-commands rest-by-number and rest (issue 6850073)

[benko . pal]

On 2012/11/25 23:03:43, thomasmorley65 wrote:

On 2012/11/21 08:05:09, benko.pal wrote:
[...]
> there are no separate glyphs for rests and multi measure rests: the

M in glyph

> names stands not for MultiMeasure, but for Minus.



Didn't know that.



> that makes for rewriting the
> cond below, I'm afraid, but it will be simpler.



Well, I want the markup-commands to produce different output depending

on the

used style. I can't see an other way, than to write detailed

conditions.

OTOH, I tried to consider your hint and to write them concise.


I just meant that instead of checking several times whether dealing with
multi-measure rest or not, you may convert duration log at a single
place (with the caveat of turning a negative sign to 'M' instead of
'-').

http://codereview.appspot.com/6850073/

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

Re: Issue 2916: Document \hide and \omit (issue 6851102)

[dak]

Reviewers: Trevor Daniels, thomasmorley65,


http://codereview.appspot.com/6851102/diff/3001/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):

http://codereview.appspot.com/6851102/diff/3001/Documentation/learning/tweaks.itely#newcode1499
Documentation/learning/tweaks.itely:1499: \omit Staff.Clef
On 2012/11/26 08:34:37, Trevor Daniels wrote:

That's really confusing.  If a context is
specified in an \override in the same location
it generates no warning or error but becomes
ineffective.  Unless this can be changed
this needs much more explanation.


The underlying rationale was that music containing overrides is
_filtered_ when used in context modifications, and only those overrides
applying to a context of the proper type are actually being applied.

I think the idea was to be able to cram \time, \clef and other stuff
into one \global context modification and use that everywhere, sorting
itself out properly.

I agree that the effect that this has here is not really harmonizing
well with \override (which does not allow a context spec inside of
context mods, and will not silently ignore Bottom overrides in
non-Bottom contexts), so it might make sense to just drop this
(not-really-yet-reached) design goal and the associated "picky" context
modifications which are not really documented on the user or even the
concept level.

Description:
Issue 2916: Document \hide and \omit

Also fixes a few other inaccuracies.

Please review this at http://codereview.appspot.com/6851102/

Affected files:
  M Documentation/learning/tweaks.itely



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

Re: Fix for issue 2967 [was Re: Your Patches]

[James]

Hello,

On 25 November 2012 22:43, Trevor Daniels  wrote:
>
> Francisco Vila wrote Sunday, November 25, 2012 5:15 PM
>
>> 2012/11/25 Trevor Daniels :
>>
 --snip--
 WARNING: Unable to find node 'Creating titles' in book notation.
 *** Undefined node `Single staff' in @ref (in
 out-www/learning/fundamental.texi l. 3171)
 Max error number exceeded
 --snip--

 unfortunately the build scripts don't say *which* log to look at (i.e.
 there are learning.bigtexi.log files in all the languages - most are 0
 bytes).

 But it does stop make doc.
>>>
>>> Thanks James.  I think this is because Documentation/nl/learning does
>>> not contain the templates.itely file, so make doc defaults to using
>>> that file from Documentation/learning, which has different node
>>> names after this patch is applied.
>>
>>> All the language directories contain templates.itely except nl, so
>>> the fix is probably to copy this file (before this patch) into nl.
>>
>> I think you're right. Seems strange why a fix for a problem caused by
>> a patch that does not touch anything in nl/ , is to copy an old file
>> with different node names, but it's true.
>
> I've uploaded a new patch-set for
> http://codereview.appspot.com/6852077
> which adds the missing .itely files to Documentation/nl/learning and
> Documentation/hu/learning.  Make doc should now complete
> successfully, cross fingers.
>
> James: as this is uncertain and I'm not really in a position to run
> a full make doc at present would you be able to check this patch
> before it gets to a countdown?  I'll send you a format-patch
> of this change separately as it's quite large.  Thanks.
>
This makes doc with no errors.

James

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

Re: Issue 2916: Document \hide and \omit (issue 6851102)

[tdanielsmusic]

http://codereview.appspot.com/6851102/diff/3001/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):

http://codereview.appspot.com/6851102/diff/3001/Documentation/learning/tweaks.itely#newcode1499
Documentation/learning/tweaks.itely:1499: \omit Staff.Clef
That's really confusing.  If a context is
specified in an \override in the same location
it generates no warning or error but becomes
ineffective.  Unless this can be changed
this needs much more explanation.

http://codereview.appspot.com/6851102/

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