Segfault for balloonGrobText on OttavaBracket

[Noeck]

Hi,

the following code produces a segmentation violation (if that's the same
as "Speicherzugriffsfehler") using 2.18.2 or 2.19.50. The combination of
\ottava and \balloonGrobText is required to cause the failure.

\version "2.19.50"
\new Staff \with { \consists "Balloon_engraver" }
\new Voice  {
  \balloonGrobText #'OttavaBracket #'(1 . 1) "A"
  \ottava #1 a4
}

The code probably worked with some 2.16.x version as I have the
corresponding pdf output. convert-ly does not change it.

Best,
Joram

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

convert-ly does not provide a compilable result

[Noeck]

Hi,

perhaps I am too demanding, but shouldn't this syntax be updated by
convert-ly?


\version "2.16.0"

\paper {
  system-system-spacing #'padding = #7
  nonstaff-nonstaff-spacing #'padding = #8
}

\markup \null


Running convert-ly (version 2.19.50) on it does not change the syntax
(except for the version number) but then running lilypond on it complains:

Fehler: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' or ','
  system-system-spacing
#'padding = #7


I would expect convert-ly to update this to


\paper {
  system-system-spacing.padding = #7
  nonstaff-nonstaff-spacing.padding = #8
}

Best,
Joram

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

Re: convert-ly does not provide a compilable result

[David Kastrup]

Noeck  writes:

> perhaps I am too demanding, but shouldn't this syntax be updated by
> convert-ly?
>
>
> \version "2.16.0"
>
> \paper {
>   system-system-spacing #'padding = #7
>   nonstaff-nonstaff-spacing #'padding = #8
> }
>
> \markup \null
>
>
> Running convert-ly (version 2.19.50) on it does not change the syntax
> (except for the version number) but then running lilypond on it complains:
>
> Fehler: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' or ','
>   system-system-spacing
> #'padding = #7
>
>
> I would expect convert-ly to update this to
>
>
> \paper {
>   system-system-spacing.padding = #7
>   nonstaff-nonstaff-spacing.padding = #8
> }

I was pretty sure of having programmed that.  There is issue 4068 doing
such a rule, but also reverting it again.  Presumably I did not think
the rule robust enough to be enabled permanently.  But obviously this is
a problem we should not just ignore.  Perhaps do a version that will
work after a line beginning and/or { ?

-- 
David Kastrup

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

Re: convert-ly does not provide a compilable result

[David Kastrup]

David Kastrup  writes:

> David Kastrup  writes:
>
>> Noeck  writes:
>>
>>> perhaps I am too demanding, but shouldn't this syntax be updated by
>>> convert-ly?
>>>
>>>
>>> \version "2.16.0"
>>>
>>> \paper {
>>>   system-system-spacing #'padding = #7
>>>   nonstaff-nonstaff-spacing #'padding = #8
>>> }
>>>
>>> \markup \null
>>>
>>>
>>> Running convert-ly (version 2.19.50) on it does not change the syntax
>>> (except for the version number) but then running lilypond on it complains:
>>>
>>> Fehler: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' or ','
>>>   system-system-spacing
>>> #'padding = #7
>>>
>>>
>>> I would expect convert-ly to update this to
>>>
>>>
>>> \paper {
>>>   system-system-spacing.padding = #7
>>>   nonstaff-nonstaff-spacing.padding = #8
>>> }
>>
>> I was pretty sure of having programmed that.  There is issue 4068 doing
>> such a rule,
>
> 
>
>> but also reverting it again.  Presumably I did not think the rule
>> robust enough to be enabled permanently.  But obviously this is a
>> problem we should not just ignore.  Perhaps do a version that will
>> work after a line beginning and/or { ?

That issue states:

When pushed to staging, another commit reverting the convert-ly rule
will be added since we don't want to apply somewhat generic patterns
like those on unknown user-provided code when unchanged code remains
valid.

But the "when unchanged code remains valid" part is gone: unchanged code
became invalid with


The discussion for the code review for that patch suggests that I was of
the opinion that such a convert-ly rule was in place after all.

So yes: this needs fixing.

-- 
David Kastrup

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

Re: convert-ly does not provide a compilable result

[David Kastrup]

David Kastrup  writes:

> Noeck  writes:
>
>> perhaps I am too demanding, but shouldn't this syntax be updated by
>> convert-ly?
>>
>>
>> \version "2.16.0"
>>
>> \paper {
>>   system-system-spacing #'padding = #7
>>   nonstaff-nonstaff-spacing #'padding = #8
>> }
>>
>> \markup \null
>>
>>
>> Running convert-ly (version 2.19.50) on it does not change the syntax
>> (except for the version number) but then running lilypond on it complains:
>>
>> Fehler: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' or ','
>>   system-system-spacing
>> #'padding = #7
>>
>>
>> I would expect convert-ly to update this to
>>
>>
>> \paper {
>>   system-system-spacing.padding = #7
>>   nonstaff-nonstaff-spacing.padding = #8
>> }
>
> I was pretty sure of having programmed that.  There is issue 4068 doing
> such a rule,



> but also reverting it again.  Presumably I did not think the rule
> robust enough to be enabled permanently.  But obviously this is a
> problem we should not just ignore.  Perhaps do a version that will
> work after a line beginning and/or { ?

-- 
David Kastrup

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

Re: Bug: parenthesize before line break

[Thomas Morley]

2017-04-11 23:28 GMT+02:00 Jon Arnold :
> Trying again on this, and I've attached a PNG this time.
>
> On Tue, Apr 4, 2017 at 2:59 PM, Jon Arnold 
> wrote:
>
>> When I try to parenthesize a breathe mark that is right before a line
>> break, Lilypond engraves the parentheses on the next line to the left of
>> the clef sign, rather than the line that it should be.
>>
>>
>> %%% BUG REPORT START
>> %parenthesize just before line break prints on next line
>> \version "2.19.58"
>>
>> \relative c'' {
>>   b4 c \parenthesize \breathe d f \parenthesize \breathe \break
>>   e \parenthesize \breathe d c \parenthesize \breathe a
>> }
>>
>> %%% BUG REPORT END
>>


Thanks for the bug report.

It's now
https://sourceforge.net/p/testlilyissues/issues/5118/

See there for a possible work-around.

Best,
  Harm

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

Re: Bug: parenthesize before line break

[Jon Arnold]

Trying again on this, and I've attached a PNG this time.

On Tue, Apr 4, 2017 at 2:59 PM, Jon Arnold 
wrote:

> When I try to parenthesize a breathe mark that is right before a line
> break, Lilypond engraves the parentheses on the next line to the left of
> the clef sign, rather than the line that it should be.
>
>
> %%% BUG REPORT START
> %parenthesize just before line break prints on next line
> \version "2.19.58"
>
> \relative c'' {
>   b4 c \parenthesize \breathe d f \parenthesize \breathe \break
>   e \parenthesize \breathe d c \parenthesize \breathe a
> }
>
> %%% BUG REPORT END
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley  wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik :
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn :


 Am 09.04.2017 um 20:53 schrieb Thomas Morley:
> I would have expected the whole bracket to be (much) smaller, instead
> only the part of the bracket left from TupletNumber is affected.

 How do you expect any sensible output from that? 10 is so much that the
 “left” end of the bracket is right from the right e
>>>
>>> Well, this happens while trying some heavy overrides, shanghaiing other 
>>> grobs.
>>> Sometimes, doing extreme things leads to detecting some weakness...
>>>
>>> I'm attempting to solve the request at
>>> http://lilypond.1069038.n5.nabble.com/Drawing-wavy-line-across-the-bars-tt201843.html
>>> in an automagical manner.
>>>
>>> Look at the attached picture.
>>> The text is the TupletNumber, the wavy line the TupletBracket. ;)
>>> Though, it gives wrong output, if the TupletBracket is not long
>>> enough. Moving the left end via shorten-pair to make room for the text
>>> gives the strange result then.
>>> Probably another property to use? It's still work in progress and it's
>>> still possible I don't get to stable state...
>>> Maybe TupletBracket is the wrong grob anyway and I should try
>>> HorizontalBracket or another Bracket. Looks I can't go for real
>>> spanners, because there ending gives a warning, when I try to let them
>>> print to the real end of a bar _and_ this bar is the last in the
>>> piece.
>>> Which may be a bug of its own:
>>>
>>> {
>>> c'1\startTextSpan
>>> \break
>>> c'1 <>\stopTextSpan
>>> }
>>>
>>> returns:
>>>
>>> atest-53.ly:1095:12: programming error: bounds of this piece aren't 
>>> breakable.
>>> c'1
>>>\startTextSpan
>>> atest-53.ly:1095:12: continuing, cross fingers
>>>
>>> The visual output is ok, though.
>>
>> TextSpanner seems like a more natural grob to co-opt!
>
> No doubt.
> Though, I found no way around the issue above. Obviouly I was too lazy
> to look into scheme-text-spanner.ly-code.
>
> Thanks a lot for it.
>
> Meanwhile I've gotten a stable code for the TupletBracket.
> I think I'll post it.
>
> And then look for the TextSpanner...
>
>
>>
>> The text spanner has its bounds set to NoteColumns. (Broken bounds
>> will be set to NonMusicalPaperColumn later.)  In your example, the
>> engraver runs out of NoteColumns and tries to set the right bound to
>> PaperColumn, which apparently doesn't work  I can put a patch for this
>> forward.
>
> That would be great!
> Ofcourse the same happens for the TrillSpanner, maybe other spanners as well.
> No clue whether this can be fixed in one go.
>

Scratch that...  There are times when the bound of a TextSpanner needs
to be set to a PaperColumn.  As for example:

{
  R1\startTextSpan
  R1\stopTextSpan
}

It's just that you will get that programming error when the
PaperColumn is at the very end of the score.  No idea how to fix that.
I do think that the error --  "bounds of this piece aren't breakable"
-- is very obscure and ought to be rewritten.  It's not "piece," as in
"this piece of music I'm typesetting."  Apparently it's saying that
one possibility of segmenting the spanner for line breaks is
impossible.  In this case, it's a little ridiculous, since we're
talking about breaking the spanner at the very end of the score..

David.

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