\bookpart and variables

2015-02-09 Thread Werner LEMBERG

Folks,


why are variable assignments not allowed in \bookpart?  For example,
this snippet

  \bookpart {
APT = \allowPageTurn

{ c'' }
  }

fails.  In case this is just an omission, can it be fixed easily?


Werner

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


Re: \bookpart and variables

2015-02-09 Thread Urs Liska


Am 09.02.2015 um 09:31 schrieb Werner LEMBERG:

Folks,


why are variable assignments not allowed in \bookpart?  For example,
this snippet

   \bookpart {
 APT = \allowPageTurn

 { c'' }
   }

fails.  In case this is just an omission, can it be fixed easily?


If not this should help you as an easy workaround:
https://github.com/openlilylib/openlilylib/tree/master/general-tools/scheme-wrapper/parserDefine

HTH
Urs



 Werner

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



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


Re: \bookpart and variables

2015-02-09 Thread David Kastrup
Werner LEMBERG  writes:

> Folks,
>
>
> why are variable assignments not allowed in \bookpart?  For example,
> this snippet
>
>   \bookpart {
> APT = \allowPageTurn
>
> { c'' }
>   }
>
> fails.  In case this is just an omission, can it be fixed easily?

Well, as far as I can see, assignments are also not allowed in books.
And the reason mostly would be that books and bookparts don't have scope
of their own (apart from book's \paper block).  So even if it were
allowed, it would end up just the same as a global assignment outside of
the book/bookpart.

Do you have a particular use case in mind?

-- 
David Kastrup

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


Re: The status of Lilypond and Guile 2?

2015-02-09 Thread Henning Hraban Ramm
Am 2015-02-09 um 01:34 schrieb Edward d'Auvergne :

> I was wondering what the current status of Guile 2 support in Lilypond
> is?  The dev/guilev2 branch hasn't been touched since 2014-10-13.  It
> is becoming more and more impossible to run Lilypond on modern Linux
> distributions (for example see
> https://bugs.mageia.org/show_bug.cgi?id=10969).  Is there any relief
> in sight?

Have a look at the mailing list’s archives, it was discussed just yesterday or 
maybe two days before in the GSoC thread:

The problem is Guile 2’s garbage collection that’s incompatible with LilyPond’s 
internal data structures.
Only the Guile developers can really solve this; as far as I understood, there 
are a lot more issues in Guile 2; looks to me like nobody uses Guile as much as 
LilyPond...

Greetlings, Hraban
---
fiëé visuëlle
Henning Hraban Ramm
http://www.fiee.net
http://angerweit.tikon.ch/lieder/
https://www.cacert.org (I'm an assurer)





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


Re: The status of Lilypond and Guile 2?

2015-02-09 Thread David Kastrup
"Edward d'Auvergne"  writes:

> Hi,
>
> I was wondering what the current status of Guile 2 support in Lilypond
> is?  The dev/guilev2 branch hasn't been touched since 2014-10-13.

That corresponds with the last time I got a promise GUILEv2 developers
would take a look at our GC problems.

> It is becoming more and more impossible to run Lilypond on modern
> Linux distributions (for example see
> https://bugs.mageia.org/show_bug.cgi?id=10969).  Is there any relief
> in sight?

I've scheduled making the dev/guilev2 branch unnecessary for initial
GUILEv2 work this week as I got another promise.  After GUILEv2 work can
be done on master directly, GUILEv2 developers will be able to
experiment with a current master anytime they feel like following up on
promises.

So you'll be able to ask your question on the GUILE developer list
soon.

-- 
David Kastrup

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


systems-per-page and blank-page-penalty

2015-02-09 Thread Werner LEMBERG

Folks,


consider the following snippet.

  #(set-default-paper-size "a6")

  \paper {
systems-per-page = 6
blank-page-penalty = 1000

#(define page-breaking ly:page-turn-breaking)

copyright = ""
footer = ""
tagline = ""
  }

  m = \relative c' {
f'8 f, f f f f f f |
\repeat unfold 11 { f8 f f f f f f f  } |
  }

  {
\m \allowPageTurn
\m \allowPageTurn
\m
\m
  }

There is a blank page in it, and I would like to avoid that, thus the
`blank-page-penalty' parameter.  [In this demo snippet the result
would be extremely ugly, but in real-life situations with more break
points it would be much less disturbing.]

However, it doesn't work.

Looking into `page-breaking.cc' (function
`Page_breaking::space_systems_on_n_or_one_more_pages'), I see that no
blank page penalties are checked if `systems-per-page' is set.  This
looks wrong to me.


Werner


blank-page.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: \bookpart and variables

2015-02-09 Thread Werner LEMBERG
>> why are variable assignments not allowed in \bookpart? [...]
> 
> Well, as far as I can see, assignments are also not allowed in
> books.

Hmm...

> And the reason mostly would be that books and bookparts don't have
> scope of their own (apart from book's \paper block).  So even if it
> were allowed, it would end up just the same as a global assignment
> outside of the book/bookpart.

OK.  Even if \book and \bookpart don't provide `real' grouping (in the
lilypond sense), they contain data between `{' and `}' – let's call
this visual grouping.  I consider it quite natural to put stuff into
`\bookmark { ... } ' to indicate that it belongs together.

> Do you have a particular use case in mind?

Yes.  I have the following structure for a collection of piano pieces

  file-a.ly:  left = ...
  right = ...

  file-b.ly:  left = ...
  right = ...
  ...

and I would like to organize it as follows.

   \bookpart {
 \include "file-a.ly"
 \score { ... }
   }

   \bookpart {
 \include "file-b.ly"
 \score { ... }
   }

   ...

Right now, I have to do this:

   \include "file-a.ly"
   \bookpart {
 \score { ... }
   }

   \include "file-b.ly"
   \bookpart {
 \score { ... }
   }

   ...


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


Re: \bookpart and variables

2015-02-09 Thread David Kastrup
Werner LEMBERG  writes:

>>> why are variable assignments not allowed in \bookpart? [...]
>> 
>> Well, as far as I can see, assignments are also not allowed in
>> books.
>
> Hmm...
>
>> And the reason mostly would be that books and bookparts don't have
>> scope of their own (apart from book's \paper block).  So even if it
>> were allowed, it would end up just the same as a global assignment
>> outside of the book/bookpart.
>
> OK.  Even if \book and \bookpart don't provide `real' grouping (in the
> lilypond sense), they contain data between `{' and `}' – let's call
> this visual grouping.  I consider it quite natural to put stuff into
> `\bookmark { ... } ' to indicate that it belongs together.
>
>> Do you have a particular use case in mind?
>
> Yes.  I have the following structure for a collection of piano pieces
>
>   file-a.ly:  left = ...
>   right = ...
>
>   file-b.ly:  left = ...
>   right = ...
>   ...
>
> and I would like to organize it as follows.
>
>\bookpart {
>  \include "file-a.ly"
>  \score { ... }
>}
>
>\bookpart {
>  \include "file-b.ly"
>  \score { ... }
>}
>
>...
>
> Right now, I have to do this:
>
>\include "file-a.ly"
>\bookpart {
>  \score { ... }
>}
>
>\include "file-b.ly"
>\bookpart {
>  \score { ... }
>}

Well, yes.  The former arrangement suggests a locality that is not
there.  Here is an example (where I use the Scheme equivalent of
assignment):

\book {
  \bookpart {
#(define notecolor blue)
\score {
  { \override NoteHead.color = #(lambda (grob) notecolor)
c1
  }
}
  }

  \bookpart {
#(define notecolor red)
\score {
  { \override NoteHead.color = #(lambda (grob) notecolor)
c1
  }
}
  }
}

Now wouldn't you expect, assuming assignment were allowed where
#(define...) is not being used, that the bookparts would show different
colors for the noteheads?

Instead both of them have red noteheads because both use the same global
variable `notecolor' and reference it when \book starts iterating the
already assembled bookparts.

So as long as everything refers to global variables _and_ bookparts are
not iterated when they are encountered but only after the complete music
expressions in a book have been collected, we are just asking for
trouble by allowing assignment in places where the actual execution
happens at a different time than the assignments would.

-- 
David Kastrup

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


Re: \bookpart and variables

2015-02-09 Thread Werner LEMBERG

> Here is an example (where I use the Scheme equivalent of
> assignment): [...]

Interesting.  Note that

  foo = \relative c' { c d e f g }
  \bookpart {
\foo
  }

  foo = \relative c'' { g f e d c }
  \bookpart {
\foo
  }

fortunately works as expected (this is, different notes in different
\bookparts), while

  #(define notecolor blue)
  \bookpart {
\score {
  { \override NoteHead.color = #(lambda (grob) notecolor)
c1
  }
}
  }

  #(define notecolor red)
  \bookpart {
\score {
  { \override NoteHead.color = #(lambda (grob) notecolor)
c1
  }
}
  }

gives a red notehead both times.  So I think that your comparison is
not completely valid, since lilypond's `variables' are obviously
expanded at a different time than Scheme assignments.

Is this documented somewhere?


Werner

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


Re: \bookpart and variables

2015-02-09 Thread David Kastrup
Werner LEMBERG  writes:

>> Here is an example (where I use the Scheme equivalent of
>> assignment): [...]
>
> Interesting.  Note that
>
>   foo = \relative c' { c d e f g }
>   \bookpart {
> \foo
>   }
>
>   foo = \relative c'' { g f e d c }
>   \bookpart {
> \foo
>   }
>
> fortunately works as expected (this is, different notes in different
> \bookparts), while
>
>   #(define notecolor blue)
>   \bookpart {
> \score {
>   { \override NoteHead.color = #(lambda (grob) notecolor)
> c1
>   }
> }
>   }
>
>   #(define notecolor red)
>   \bookpart {
> \score {
>   { \override NoteHead.color = #(lambda (grob) notecolor)
> c1
>   }
> }
>   }
>
> gives a red notehead both times.  So I think that your comparison is
> not completely valid, since lilypond's `variables' are obviously
> expanded at a different time than Scheme assignments.

No, they aren't.  This is not due to a difference between LilyPond and
Scheme.  If you override with #notecolor you'll again get two different
colors.  But #(lambda (grob) notecolor) is called at iteration time, and
at that time the second assignment to notecolor has already happened.

> Is this documented somewhere?

That iteration and parsing happen at different times?  It's not all that
surprising.  If we write
\score { ...
  \midi ...
  \layout ...
}
then we get two instances of iteration for the music starting the
score.  It's not all that surprising that it is only read in once.

We don't allow assignments inside of music expressions either, and again
the reason is not as much that it wouldn't be possible to allow them
there, but rather that people would be surprised that "reassigning" a
variable inside of music will affect previous uses of it and not be in
any conceivable way synchronized with the "flow" of music.

-- 
David Kastrup

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


Re: systems-per-page and blank-page-penalty

2015-02-09 Thread James Lowe
On 09/02/15 10:19, Werner LEMBERG wrote:
> consider the following snippet.
> 
> #(set-default-paper-size "a6")
> 
> \paper { systems-per-page = 6 blank-page-penalty = 1000
> 
> #(define page-breaking ly:page-turn-breaking)
> 
> copyright = "" footer = "" tagline = "" }
> 
> m = \relative c' { f'8 f, f f f f f f | \repeat unfold 11 { f8 f f
> f f f f f  } | }
> 
> { \m \allowPageTurn \m \allowPageTurn \m \m }
> 
> There is a blank page in it, and I would like to avoid that, thus
> the `blank-page-penalty' parameter.  [In this demo snippet the
> result would be extremely ugly, but in real-life situations with
> more break points it would be much less disturbing.]
> 
> However, it doesn't work.
> 
> Looking into `page-breaking.cc' (function 
> `Page_breaking::space_systems_on_n_or_one_more_pages'), I see that
> no blank page penalties are checked if `systems-per-page' is set.
> This looks wrong to me.
> 
> 
> Werner

Maybe I'm being a bit hasty but

https://code.google.com/p/lilypond/issues/detail?id=4285

James

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


Re: \bookpart and variables

2015-02-09 Thread Werner LEMBERG
>> So I think that your comparison is not completely valid, since
>> lilypond's `variables' are obviously expanded at a different time
>> than Scheme assignments.
> 
> No, they aren't.  This is not due to a difference between LilyPond
> and Scheme.  If you override with #notecolor you'll again get two
> different colors.  But #(lambda (grob) notecolor) is called at
> iteration time, and at that time the second assignment to notecolor
> has already happened.
> 
>> Is this documented somewhere?
> 
> That iteration and parsing happen at different times?  It's not all
> that surprising.

Believe it or not, it *is* surprising.  You have to stumble upon nasty
side effects to start thinking about the issue.  Being a long-term
user and developer of lilypond, even I skipped the `fine print' until
now.

> We don't allow assignments inside of music expressions either, and
> again the reason is not as much that it wouldn't be possible to
> allow them there, but rather that people would be surprised that
> "reassigning" a variable inside of music will affect previous uses
> of it and not be in any conceivable way synchronized with the "flow"
> of music.

You are correct, of course, but this is not obvious at a first glance.
Could you add a corollary of our e-mail exchange on this topic to the
documentation?  Perhaps a section `When does variable expansion
happen?'...


Werner

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


Re: \bookpart and variables

2015-02-09 Thread David Kastrup
Werner LEMBERG  writes:

>> We don't allow assignments inside of music expressions either, and
>> again the reason is not as much that it wouldn't be possible to
>> allow them there, but rather that people would be surprised that
>> "reassigning" a variable inside of music will affect previous uses
>> of it and not be in any conceivable way synchronized with the "flow"
>> of music.
>
> You are correct, of course, but this is not obvious at a first glance.
> Could you add a corollary of our e-mail exchange on this topic to the
> documentation?  Perhaps a section `When does variable expansion
> happen?'...

I'll try keeping it in mind.  In mean time, scores have \header blocks,
and books have \paper blocks, and some information can be put there and
will indeed stay local to those blocks and scores and books.  One can't
usefully _change_ variables there: the meaningful uses are basically as
constants given a value that they keep.

If we find that we are missing tools for organizing scores in a useful
manner, we'll need to think about how we can arrive at semantics that
better reflect what people want to put into their sources while still
working well for the kind of batch parsing we employ (and which will
likely eventually be our road into comparatively reliable MusicXML ex-
and import).

-- 
David Kastrup

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


Re: systems-per-page and blank-page-penalty

2015-02-09 Thread Werner LEMBERG
> Maybe I'm being a bit hasty but
> 
> https://code.google.com/p/lilypond/issues/detail?id=4285

Thanks.  It perhaps makes sense to add the PDF file also...


Werner

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


Re: Allow independent adjustment of minimum length for spanner siblings (issue 201140043 by david.nales...@gmail.com)

2015-02-09 Thread thomasmorley65

LGTM

https://codereview.appspot.com/201140043/

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


Re: Clean up inconsistencies in engraver-init.ly and performer-init.ly (issue 199460043 by thomasmorle...@gmail.com)

2015-02-09 Thread thomasmorley65

On 2015/02/09 06:09:34, lemzwerg wrote:

LGTM.  It would be nice if David's checker script could be added, too.


More, I'd consider it a good idea to use the checker on the current
patch again.
There was such a mess that I'm not sure I corrected all.



https://codereview.appspot.com/199460043/diff/20001/ly/performer-init.ly

File ly/performer-init.ly (right):



https://codereview.appspot.com/199460043/diff/20001/ly/performer-init.ly#newcode174

ly/performer-init.ly:174: \accepts ChordNames
I wonder whether it makes sense to sort the many \accept lines

alphabetically...

I'd happily do it, though, why alpabetically? And why only for the lines
with \accept, could be done for the context-defs as well.
And it's also thinkable to sort it following context-hierarchy: first
bottom-contexts like Voice, then Staff up to Score and Global.
Or vice versa...

What do others think?

https://codereview.appspot.com/199460043/

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


Web: introduction.itexi fix typo (Vim -> Emacs) (issue 197530043 by paulwmor...@gmail.com)

2015-02-09 Thread paulwmorris

Reviewers: ,

Message:
Just fixing a typo on the website.
-Paul

Description:
Web: introduction.itexi fix typo (Vim -> Emacs)

Please review this at https://codereview.appspot.com/197530043/

Affected files (+1, -1 lines):
  M Documentation/web/introduction.itexi


Index: Documentation/web/introduction.itexi
diff --git a/Documentation/web/introduction.itexi  
b/Documentation/web/introduction.itexi
index  
dc755d528abb0c8d636f9802accd5e8a85342347..3942a42959cdc68ca1a0ee4374eca928d294144b  
100644

--- a/Documentation/web/introduction.itexi
+++ b/Documentation/web/introduction.itexi
@@ -1305,7 +1305,7 @@ with LilyPond source files.  A developer  has written
 If you are not already familiar with Emacs then you may probably prefer
 to use a different editor for writing LilyPond input files.

-More information on setting up Vim can be found in
+More information on setting up Emacs can be found in
 @rprogram{Text editor support}.

 @subsubheading Vim



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


Web: CSS: remove vendor prefixed border-radius (issue 200340043 by paulwmor...@gmail.com)

2015-02-09 Thread paulwmorris

Reviewers: ,

Message:
Please review, thanks.

Description:
Web: CSS: remove vendor prefixed border-radius

No need for these anymore:
-moz-border-radius
-webkit-border-radius

Please review this at https://codereview.appspot.com/200340043/

Affected files (+2, -24 lines):
  M Documentation/css/lilypond-manuals.css
  M Documentation/css/lilypond-website.css


Index: Documentation/css/lilypond-manuals.css
diff --git a/Documentation/css/lilypond-manuals.css  
b/Documentation/css/lilypond-manuals.css
index  
8950b847a712bdf7f169793a833c5ebe7ec57fee..04a6877d8dbd833ba2568d7d5834ec3b6757ba29  
100644

--- a/Documentation/css/lilypond-manuals.css
+++ b/Documentation/css/lilypond-manuals.css
@@ -513,8 +513,7 @@ div#search p, div#search form {
   padding: 0;
   border: 1px solid green;
   /* Experimental rounded corners */
-  -moz-border-radius: 10px;
-  -webkit-border-radius: 10px;
+  border-radius: 10px;
   margin: 1em;
 }

@@ -532,7 +531,6 @@ body.contributor .warning { border-color: #00; }
   padding: 0;
   border: 1px solid green;
   /* Experimental rounded corners */
-  -moz-border-radius: 10px;
-  -webkit-border-radius: 10px;
+  border-radius: 10px;
   margin: 0.5em 0.5em 2em 3em;
 }
Index: Documentation/css/lilypond-website.css
diff --git a/Documentation/css/lilypond-website.css  
b/Documentation/css/lilypond-website.css
index  
032feebdd964a4a8aa66774e2d46eb5d43a922fb..60c0f815a404a2af79121d65dcc90e31e4b85b8b  
100644

--- a/Documentation/css/lilypond-website.css
+++ b/Documentation/css/lilypond-website.css
@@ -75,10 +75,6 @@ div#tocframe {
   font-size: 100%;
   line-height: 1;
   padding: 0;
-  -moz-border-radius-bottomleft: 7px;
-  -moz-border-radius-bottomright: 7px;
-  -webkit-border-bottom-left-radius: 7px;
-  -webkit-border-bottom-right-radius: 7px;
   border-bottom-left-radius: 7px;
   border-bottom-right-radius: 7px;
   margin: 0;
@@ -96,8 +92,6 @@ div#tocframe {
 }

 #tocframe > ul:first-child > li:first-child a {
-  -moz-border-radius-bottomleft: 7px;
-  -webkit-border-bottom-left-radius: 7px;
   border-bottom-left-radius: 7px;
 }

@@ -107,8 +101,6 @@ div#tocframe {
 }

 #tocframe > ul:first-child > li:last-child {
-  -moz-border-radius-bottomright: 7px;
-  -webkit-border-bottom-right-radius: 7px;
   border-bottom-right-radius: 7px;
 }

@@ -137,8 +129,6 @@ div#tocframe {
   padding: 0.1em 0.1em 0.1em 0.6em;
   border: 0;
   margin: 0;
-  -moz-border-radius: 7px;
-  -webkit-border-radius: 7px;
   border-radius: 7px;
 }

@@ -194,20 +184,12 @@ div#tocframe {
 }

 #tocframe .toc .toc li:first-child a {
-  -moz-border-radius-topleft: 7px;
-  -moz-border-radius-bottomleft: 7px;
-  -webkit-border-top-left-radius: 7px;
-  -webkit-border-bottom-left-radius: 7px;
   border-top-left-radius: 7px;
   border-bottom-left-radius: 7px;
   border-left: 1px solid rgba(85, 130, 70, 0.25);
 }

 #tocframe .toc .toc li:last-child a {
-  -moz-border-radius-topright: 7px;
-  -moz-border-radius-bottomright: 7px;
-  -webkit-border-top-right-radius: 7px;
-  -webkit-border-bottom-right-radius: 7px;
   border-top-right-radius: 7px;
   border-bottom-right-radius: 7px;
 }
@@ -888,8 +870,6 @@ div.color4 h3 {
   padding: 0;
   border: 1px solid green;
   /* Experimental rounded corners */
-  -moz-border-radius: 10px;
-  -webkit-border-radius: 10px;
   border-radius: 10px;
   margin: 1em;
 }



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