Re: Set indent based on instrument name (issue 6457049)

[mtsolo]

Hey Phil!

First and foremost, congrats on this work.  I'm thrilled to see you
venturing into the C++ side.  You're tackling an issue that, while just
a few lines of code, uses a lot of advanced LilyPond structures, so it's
not easy.  My suggestions don't have to do with the math (all of it is
fine) but rather a way to restructure your work so that it fits better
into how LilyPond code works.

At the engraver level, it is generally not a good idea to touch layout
information.  When this happens, it is usually to kill grobs or set
properties.  Avoid measuring extents when engraving is happening because
they could be dependent on other callbacks which could trigger many
layout decisions before engraving is finished.

Here, what I would do is use the Pointer_group_interface to add two grob
arrays to the root system of instrument names - one that contains all
InstrumentName grobs with instrumentName and one that contains all
InstrumentName grobs with shortInstrumentName.  You can stash these in
two separate vectors and then loop through the vectors, invoking
Pointer_group_interface::add_grob in a finalize method for the engraver.
 Then, create two properties of the system grob called
instrument-name-length and short-instrument-name-length and two
callbacks that look up the appropriate grob array and do the X-extent
calculations you do in the engraver.  To avoid code-duping, they can
likely use an internal function for most of their work.  Properties, in
LilyPond, are the best way to stash information.  You almost never want
to create global variables or class member variables to do this.

Then, in paper-score.cc, create functions
  Real Paper_score::get_instrument_name_length ()
and
  Real Paper_score::get_short_instrument_name_length ()
These function will check to see if there is one or many systems and, if
so, glean the instrument name length or short instrument name length
from that.  Otherwise, it will return 0.

Then, for line_dimensions_int (Output_def *def, int n), make two extra
arguments where you pass in the results of these functions.  These will
replace the global variables you're creating in output-def.cc.  It works
because line_dimensions_int is only ever called when a Paper_score is
available, so you can always interrogate the Paper_score for the
appropriate indent values before making the function call.

These changes will make the code more maintainable and less prone to
kick up bugs in other areas.  Let me know if you have any questions!

Cheers,
MS


http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc
File lily/instrument-name-engraver.cc (right):

http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc#newcode116
lily/instrument-name-engraver.cc:116: SCM Text_scheme =
Text_interface::interpret_markup (layout->self_scm (),
Ditto for variable names - use lowercase.

http://codereview.appspot.com/6457049/diff/4001/lily/instrument-name-engraver.cc#newcode121
lily/instrument-name-engraver.cc:121: Real Text_len =
Text_int[MAX]-Text_int[MIN];
Real text_len = text_int.length ();

http://codereview.appspot.com/6457049/

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

Re: [Lilypond-auto] Issue 1320 in lilypond: Enhancement: user-customizable barlines through a Scheme interface.

[Marc Hohl]

Am 01.08.2012 03:42, schrieb lilyp...@googlecode.com:

Updates:
Labels: -Patch-countdown Patch-push

Comment #56 on issue 1320 by colinpkc...@gmail.com: Enhancement: 
user-customizable barlines through a Scheme interface.

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

Counted down to 20120731, please push.




Pushed as

a1b73185eae2f07dfee3cfcac0a6f11a15075ffe

to staging.

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

Patchy email

[lilypond-auto]

04:35:11 (UTC) Begin LilyPond compile, previous commit at   
1c980a9906a7ea01b9f99487e75580f7232f2491

04:35:12 *** FAILED STEP ***

merge from staging

Command 'git branch test-master-lock origin/master' returned non-zero 
exit status 128

fatal: A branch named 'test-master-lock' already exists.


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

Re: Syntax-question about nested functions/procedures

[David Kastrup]

Thomas Morley  writes:

> Hi,
>
> fiddling around with a new patch for issue 2646 I tried to integrate
> default-parenthesize into another function.
> The following returns an error when uncommenting \override
> Score.ParenthesesItem #'font-size = #0 and applying it to an
> articulation.
>
> \version "2.15.42"
>
> parenthesizeII =
> #(define-music-function (parser location mus) (ly:music?)
>
> (define (proc arg)
> ;; from music-functions-init.ly
> (if (memq 'event-chord (ly:music-property arg 'types))
  (if (music-is-of-type? arg 'event-chord)

is a bit more readable.
>;; arg is an EventChord -> set the parenthesize property
>;; on all child notes and rests
>(for-each
>   (lambda (ev)
> (if (or (memq 'note-event (ly:music-property ev 'types))
> (memq 'rest-event (ly:music-property ev 'types)))
> (set! (ly:music-property ev 'parenthesize) #t)))
>   (ly:music-property arg 'elements))
>;; No chord, simply set property for this expression:
>(set! (ly:music-property arg 'parenthesize) #t))
>arg)
> #{
>
> %\override Score.ParenthesesItem #'font-size = #0
> $(proc mus)
> #})

Without override, it is a single music expression.  With override, it is
sequential music containing an override as first element and the input
as second element, and sequential music can't be a post-event.

An override has permanent effect, and even \once\override affects
everything at a given timestep.  More likely than not, you want a tweak.

>
> \relative c' {
>   % works
>   \parenthesizeII a'4-1
>
>   % returns an error when uncommenting the
>   % font-size-override above
> a4-\parenthesizeII-1
> }
>
> What's wrong and how to do it better?

Well, here is an only slightly tongue-in-cheek version which first lets
\parenthesize to the job and then tweaks everything it finds
parenthesized.  If you copy the core of \parenthesize, as you did above,
you would likely manipulate the 'tweak music property yourself,
prepending an appropriate tweak.

\version "2.15.42"

parenthesizeII =
#(define-music-function (parser location mus) (ly:music?)
  (map-some-music
(lambda (m)
  (and (ly:music-property m 'parenthesize #f)
   #{ \tweak ParenthesesItem #'font-size #0 #m #}))
#{ \parenthesize #mus #}))

\relative c' {
% works
\parenthesizeII a'4-1
a4-\parenthesizeII-1
}

-- 
David Kastrup


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

PATCH: Countdown to 20120812

[Colin Campbell]

For 21:00 MDT Thursday August 2

Documentation:
Issue 2640 
: doc 
enhancement for \headers - R 6456047 



Enhancement:
Issue 2705 
: Patch: Parse 
music inside of output definitions in "notes" mode - R 6455059 




Also, I'll be ABEND from Friday Aug 3 to (effectively) Monday Aug 13, so 
I'd be grateful if a voluntgeer would carry on with the Patch Nanny 
tasks during that time.


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

Doc: Clarify automatic beam setting (2701) (issue 6452072)

[tdanielsmusic]

Reviewers: ,

Message:
For Graham, really:


http://codereview.appspot.com/6452072/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6452072/diff/1/Documentation/notation/rhythms.itely#newcode2007
Documentation/notation/rhythms.itely:2007: @i{@strong{Beaming based on
@code{baseMoment} and @code{beatStructure}}}
I don't like this either, but it was already used elsewhere in this
section.  We already have unnumberedsubsubsec, so can't use that.

Description:
Doc: Clarify automatic beam setting (2701)

Explain at the beginning the precedence of the
rules, and include an example to show how to
disable beamExceptions.

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

Affected files:
  M Documentation/notation/rhythms.itely


Index: Documentation/notation/rhythms.itely
diff --git a/Documentation/notation/rhythms.itely  
b/Documentation/notation/rhythms.itely
index  
ed9424c45550e97fe87711672944f980132d6615..79859641291d21ceb7ba37c83e86465647896b9b  
100644

--- a/Documentation/notation/rhythms.itely
+++ b/Documentation/notation/rhythms.itely
@@ -1984,6 +1984,28 @@ new beam starts.
 @funindex \set
 @funindex set

+When automatic beaming is enabled, the placement of automatic beams
+is determined by three context properties:
+@code{baseMoment}, @code{beatStructure}, and @code{beamExceptions}.
+If a @code{beamExceptions} rule is defined for the time signature in
+force, that rule is used to determine the beam placement.  If no
+@code{beamExceptions} rule is defined for the time signature in force,
+the beam placement is determined by the settings of @code{baseMoment}
+and @code{beatStructure}.
+
+By default, @code{beamExceptions} rules are defined for most common
+time signatures, so the @code{beamException} rules must be disabled
+if automatic beaming is to be based on @code{baseMoment} and
+@code{beatStructure}.  The @code{beamExceptions} rules are disabled
+by
+
+@example
+\set Timing.beamExceptions = #'()
+@end example
+
+
+@i{@strong{Beaming based on @code{baseMoment} and @code{beatStructure}}}
+
 In most instances, automatic beams will end at the end of a beat.
 The ending points for beats are determined by the context properties
 @code{baseMoment} and @code{beatStructure}.  @code{beatStructure}
@@ -2001,6 +2023,25 @@ c16^"(2+3)" c c c c |
 c16^"(3+2)" c c c c |
 @end lilypond

+If a common time signature is being used, @code{beamExceptions}
+@emph{must} be disabled to enable @code{beatStructure} to work.
+The @code{\set Timing.beamExceptions = #'()} command can always
+be included if beaming is being determined by @code{beatStructure}.
+
+@lilypond[quote,relative=2,verbatim]
+\time 4/4
+a8^"default" a a a a a a a
+
+\set Timing.baseMoment = #(ly:make-moment 1 4)
+\set Timing.beatStructure = #'(1 1 1 1)
+a8^"no change" a a a a a a a
+
+\set Timing.beamExceptions = #'()
+\set Timing.baseMoment = #(ly:make-moment 1 4)
+\set Timing.beatStructure = #'(1 1 1 1)
+a8^"changed" a a a a a a a
+@end lilypond
+
 Beam setting changes can be limited to specific contexts.  If no
 setting is included in a lower-level context, the setting of the
 enclosing context will apply.
@@ -2065,6 +2106,8 @@ By default @code{baseMoment} is set to one over the  
denominator of

 the time signature. Any exceptions to this default can be found in
 @file{scm/time-signature-settings.scm}.

+@i{@strong{Beaming based on @code{beamExceptions}}}
+
 Special autobeaming rules (other than ending a beam on a beat)
 are defined in the @code{beamExceptions} property.




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

Patchy email

[lilypond-auto]

22:35:09 (UTC) Begin LilyPond compile, previous commit at   
1c980a9906a7ea01b9f99487e75580f7232f2491

22:35:09 *** FAILED STEP ***

merge from staging

Command 'git branch test-master-lock origin/master' returned non-zero 
exit status 128

fatal: A branch named 'test-master-lock' already exists.


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

Re: GOP2-3 - GLISS or not

[Joseph Rushton Wakeling]

On 30/07/12 17:52, Graham Percival wrote:

In general, yes.  But some aspects of our syntax haven't been
around for a long time -- footnotes, woodwind fingering, compound
meters, etc.  Do we have the best syntax for those?  I mean,
maybe David can figure out a way to allow us to write
   \compoundMeter (3+2)/8
or simply
   \time (3+2)/8
instead of
   \compoundMeter #(3 2 8)


That's another very good case for careful thought.  Just some examples of what 
you might have to handle if you want to cover the gamut of expression in 20th 
century notation:


 (3+2+3)/8

 3/8 + 2/8 + 3/16

 (3+2)/8 + 3/16

 3.5/8   [or  (3+1/2)/8 ...]

 (2 + 1/3)/4   [Boulez in Le Marteau Sans Maitre]

 4/8 + 1/10

 3/8 + 4/10 + (3+2+2)/12

Note that these are all _logical_ extensions of traditional time signatures. 
There's no reason in principle why they can't all be supported.  But (just as an 
example) if you try,


  \compoundMeter #'((3 2 3 8) (1 10))

  c'4. c'4 c'4. \times 4/5 { c'8 } |
  c'4. c'4 c'4. \times 4/5 { c'8 } |

... with current Lilypond, you get an error:

  warning: strange time signature found: 11/10
  ERROR: In procedure ly:make-moment:
  ERROR: Wrong type argument in position 1 (expecting integer): 15/4

... even though Lilypond supports so-called "irrational meters" like 3/10, 
11/24, etc. (and if you replace the compound meter in the above example with a 
straightforward 11/10 time signature, it works fine).


You get a similar error with the following:

  \compoundMeter #'((4 2/3 4))

  c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
  c'4 c'4 c'4 c'4 \times 2/3 { 4 } |

That is,

  Parsing...ERROR: In procedure ly:make-moment:
  ERROR: Wrong type argument in position 1 (expecting integer): 14/3

... which can again be avoided by using the equivalent time signature of 7/6.

This is probably actually quite easy to fix, but _as things stand_ it seems to 
me that compound time signatures probably need some careful consideration with 
respect to the styles and use-cases out there.


Based on the above it's _probably_ just an internals issue and not a syntax 
problem (I can make bug reports accordingly), but it's another contemporary 
music issue to throw into the mix regarding syntax.


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

Syntax-question about nested functions/procedures

[Thomas Morley]

Hi,

fiddling around with a new patch for issue 2646 I tried to integrate
default-parenthesize into another function.
The following returns an error when uncommenting \override
Score.ParenthesesItem #'font-size = #0 and applying it to an
articulation.

\version "2.15.42"

parenthesizeII =
#(define-music-function (parser location mus) (ly:music?)

(define (proc arg)
;; from music-functions-init.ly
(if (memq 'event-chord (ly:music-property arg 'types))
   ;; arg is an EventChord -> set the parenthesize property
   ;; on all child notes and rests
   (for-each
(lambda (ev)
  (if (or (memq 'note-event (ly:music-property ev 'types))
  (memq 'rest-event (ly:music-property ev 'types)))
  (set! (ly:music-property ev 'parenthesize) #t)))
(ly:music-property arg 'elements))
   ;; No chord, simply set property for this expression:
   (set! (ly:music-property arg 'parenthesize) #t))
   arg)
#{

%\override Score.ParenthesesItem #'font-size = #0
$(proc mus)
#})

\relative c' {
% works
\parenthesizeII a'4-1

% returns an error when uncommenting the
% font-size-override above
a4-\parenthesizeII-1
}

What's wrong and how to do it better?


-Harm

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

Re: Changes make test to allow output to be reviewed in a browser (issue 6442068)

[graham]

I'm extremely cautious about _removing_ the ps output, since that might
break the regtest comparisons in GUB.  Have you / could you test this?

I'd be much happier if this patch created pngs *in addition* to ps.  I
don't think we need to worry about making the process 10% or even 20%
slower.


http://codereview.appspot.com/6442068/diff/1/make/lysdoc-vars.make
File make/lysdoc-vars.make (left):

http://codereview.appspot.com/6442068/diff/1/make/lysdoc-vars.make#oldcode10
make/lysdoc-vars.make:10: LILYPOND_BOOK_FLAGS += --use-source-file-names
why?

http://codereview.appspot.com/6442068/

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

Changes make test to allow output to be reviewed in a browser (issue 6442068)

[PhilEHolmes]

Reviewers: Graham Percival,

Message:
Please review.

Description:
As the title says, really.  To date, running make test creates only .ps
files which it's difficult to check.  This changes the output to .png,
which means that collated-files.html can be opened by a browser and the
reg tests checked.

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

Affected files:
  M make/lilypond-vars.make
  M make/lysdoc-targets.make
  M make/lysdoc-vars.make


Index: make/lilypond-vars.make
diff --git a/make/lilypond-vars.make b/make/lilypond-vars.make
index  
5c5e1efe3e0a171d74607787988e0a3e289c96b1..4603406d46f23c525e930fcda711f74fe6da6227  
100644

--- a/make/lilypond-vars.make
+++ b/make/lilypond-vars.make
@@ -69,9 +69,6 @@ LILYPOND_BOOK_FLAGS += --skip-lily-check
 else
 LILYPOND_BOOK_PROCESS = $(LILYPOND_BINARY)
 endif
-ifeq ($(out),test)
-LILYPOND_BOOK_FLAGS += --skip-png-check
-endif

 TEXINPUTS=$(top-src-dir)/tex/::
 export TEXINPUTS
Index: make/lysdoc-targets.make
diff --git a/make/lysdoc-targets.make b/make/lysdoc-targets.make
index  
5290e3962feb6cbc06192050791facc66f2349fe..638f9da41bc8461ad0e9941da894717f3145e56c  
100644

--- a/make/lysdoc-targets.make
+++ b/make/lysdoc-targets.make
@@ -16,6 +16,6 @@ local-test:
echo -e '\n\n\n' ; \
(cd $(top-src-dir) && git diff ) ; \
fi > $(outdir)/tree.gittxt
-	$(MAKE) LILYPOND_BOOK_LILYPOND_FLAGS="-dbackend=eps --formats=ps  
$(LILYPOND_JOBS) -dseparate-log-files -dinclude-eps-fonts  
-dgs-load-lily-fonts --header=texidoc -I  
$(top-src-dir)/Documentation/included/ -ddump-profile  
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1"  
LILYPOND_BOOK_WARN= $(outdir)/collated-files.html  
LYS_OUTPUT_DIR=$(top-build-dir)/out/lybook-testdb
+	$(MAKE) LILYPOND_BOOK_LILYPOND_FLAGS="-dbackend=eps --formats=png  
$(LILYPOND_JOBS) -dseparate-log-files -dinclude-eps-fonts  
-dgs-load-lily-fonts --header=texidoc -I  
$(top-src-dir)/Documentation/included/ -ddump-profile  
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1"  
LILYPOND_BOOK_WARN= $(outdir)/collated-files.html  
LYS_OUTPUT_DIR=$(top-build-dir)/out/lybook-testdb
 	rsync -L -a --exclude 'out-*' --exclude 'out' --exclude mf --exclude  
source --exclude mf $(top-build-dir)/out/share $(outdir)


Index: make/lysdoc-vars.make
diff --git a/make/lysdoc-vars.make b/make/lysdoc-vars.make
index  
337460c3da1ae494f868813a5f251e81bb7a071e..93d9902a6240afd8c98254178fc42c53d131e6b2  
100644

--- a/make/lysdoc-vars.make
+++ b/make/lysdoc-vars.make
@@ -6,6 +6,3 @@ ifeq ($(COLLATED_FILES),)
 COLLATED_FILES = $(sort $(TEXINFO_SOURCES) $(LY_FILES) $(OUT_LY_FILES) )
 endif

-ifeq ($(out),test)
-LILYPOND_BOOK_FLAGS += --use-source-file-names
-endif



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

Re: Fwd: Using MSH Paris Nord server

[John Mandereau]

Il giorno mar, 31/07/2012 alle 12.12 +0200, John Mandereau ha scritto:
> I'm currently setting up the server with the default (OpenId), but I
> don't mind changing it if there are strong wishes for the other option.

Uh oh, OpenId login hits on the firewall (I haven't requested outgoing
HTTPS connexions to be accepted), and the network administrator is on
vacation until August 8th, so don't hold your breath.  I could mess with
setting up HTTP Authenication and an account management service (not
included in Gerrit), but this would take me oodles of time (taking into
account security to a reasonable extent) as I've never done it.

Best,
John


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

Re: Unify the lexer's idea of words and commands across all modes. (issue 6445056)

[Trevor Daniels]

 wrote Tuesday, July 31, 2012 11:52 AM

>> http://codereview.appspot.com/6445056/diff/1/lily/lexer.ll#newcode390
>> lily/lexer.ll:390: {RESTNAME}/[-_] |
>> Why is this trailing context added?  I don't see
>> what this would match that wouldn't be matched
>> by the following line.
> 
> Flex picks the longest matching pattern.  Apparently that includes
> trailing contexts.  Without this pattern, r-. does not trigger the
> {RESTNAME} rule but rather the {WORD}/[-_] rule coming later.  And for
> the {WORD}/[-_] rule, the trailing context is needed to keep flex from
> requiring backup states.

Thanks.  Understood.  Probably worth a comment in the
code as this is not immediately obvious.

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

Re: Set indent based on instrument name (issue 6457049)

[Trevor Daniels]

Graham Percival wrote Tuesday, July 31, 2012 4:41 PM

> One slight quibble: if a user explicitly sets indent=1\cm, then I
> think it's fair to let the instrument name go off the left-hand
> side of the page.

I agree.  This probably means making the default for indent
(and short-indent) to be call-backs so they are overridden
if the user explicitly sets indent ( and .. ).  That's assuming
call-backs can be made to work for these variables.  I
don't know if this is true or not, but I don't see why not.

Trevor


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

Re: Problems with make test

[Graham Percival]

On Tue, Jul 31, 2012 at 05:31:17PM +0100, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
> 
> >collated-files.html only shows the differences, not the actual
> >files.  Furthermore, these differences are calculated based on the
> >.eps or something like that, and text is *not* included in the
> >comparison!  For various reasons, the original authors of this
> >system deliberately did not use a pixel-based checker.
> 
> After make test, out-test/collated-files.html currently shows a
> complete list of all the compiled regtests, but with broken links to
> the tests themselves and to the images.  make test doesn't do
> comparisons, AFAIK.

Yes, you're correct.  I was thinking about the regtest comparison,
sorry.

> I'll put this for review unless you say it's a waste of time.

Not a waste of time at all; this sounds extremely valuable!
Please send it in.

- Graham

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

Re: Patchy's built docs on the web

[John Mandereau]

Il giorno mar, 31/07/2012 alle 17.08 +0100, Graham Percival ha scritto:
> I suppose that something could go at the very bottom of that page,
> but it's kind-of full already.  If we _do_ add anything like that,
> then we should thank GNU first and foremost, then google code,
> then rietveld, then mshparisnord.

Sure.  I realized that we didn't have these thanks on the old website
http://lilypond.org/web/
I raised this because I signed to mention this support "whenever as
necessary", so I thought a mention on the website would be fine.


> Perhaps we should rename the current "sponsoring" page to
> something else ("supported development?"  it's a bit long, though)
> and use the "sponsoring" page for entities which have donated
> services or hardware.

Fine, or we could instead add a page called "Hosting support".

As soon as we agree on something, I'll provide a patch, but we don't
quickly find a good way to handle this, I'll just drop a new item.

Best,
John


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

Re: Problems with make test

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: "Devel" 
Sent: Tuesday, July 31, 2012 4:48 PM
Subject: Re: Problems with make test



On Tue, Jul 31, 2012 at 11:22:25AM +0100, Phil Holmes wrote:

So I open collated-files.html, to find that there are no images to
eyeball. The HTML expects PNG files, but very few are created (in
particular, the one I want...).


collated-files.html only shows the differences, not the actual
files.  Furthermore, these differences are calculated based on the
.eps or something like that, and text is *not* included in the
comparison!  For various reasons, the original authors of this
system deliberately did not use a pixel-based checker.


After make test, out-test/collated-files.html currently shows a complete 
list of all the compiled regtests, but with broken links to the tests 
themselves and to the images.  make test doesn't do comparisons, AFAIK.  My 
recent experience with the failing make test tells me that debugging 
problems with make test is now _much_ harder than with make doc, and it 
seems to me that being unable to run make test and view the output is not 
helpful.  I've got a patch ready that fixes this, by adding png to the 
output formats and jiggling other options.  Because of the additional 
output, it takes a bit longer (16% = 17 seconds on my machine).  If I delete 
the option of the PS output, it actually runs just under 10% quicker.  I'll 
put this for review unless you say it's a waste of time.


--
Phil Holmes 



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

Re: Patchy's built docs on the web

[Graham Percival]

On Tue, Jul 31, 2012 at 05:51:17PM +0200, John Mandereau wrote:
> All that said, I'd like to advertise that this server is provided by
> http://www.mshparisnord.fr on lilypond.org in addition to the home page
> of the server http://194.254.171.80. The Thanks pages on the former
> website and docs no longer exist, thanks are now spread over relevant
> sections; maybe a frame in http://lilypond.org/development.html would
> fit, wouldn't it?

I suppose that something could go at the very bottom of that page,
but it's kind-of full already.  If we _do_ add anything like that,
then we should thank GNU first and foremost, then google code,
then rietveld, then mshparisnord.

Perhaps we should rename the current "sponsoring" page to
something else ("supported development?"  it's a bit long, though)
and use the "sponsoring" page for entities which have donated
services or hardware.

- Graham

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

Re: Patchy's built docs on the web

[John Mandereau]

Il giorno mar, 31/07/2012 alle 16.27 +0100, Phil Holmes ha scritto:
> I'm assuming that changes to patchy will make this an "opt-in" option - I 
> don't want to ftp megs of files from home whenever I run patchy...

Sure.  BTW my changes don't add support for upload with
FTP/SSH/Rsync/whatever protocol, but simply hardlinking the files under
out-www/offline-root to save them out of the way of next Patchy run (the
server has only a 20 GB hard disk, and uploading docs to another
location may cost more bandwidth than the traffic generated by browsing
them directly, when you think there are all the signature and txt files
and whatnot).

All that said, I'd like to advertise that this server is provided by
http://www.mshparisnord.fr on lilypond.org in addition to the home page
of the server http://194.254.171.80. The Thanks pages on the former
website and docs no longer exist, thanks are now spread over relevant
sections; maybe a frame in http://lilypond.org/development.html would
fit, wouldn't it?

Best,
John


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

Re: Problems with make test

[Graham Percival]

On Tue, Jul 31, 2012 at 11:22:25AM +0100, Phil Holmes wrote:
> So I open collated-files.html, to find that there are no images to
> eyeball. The HTML expects PNG files, but very few are created (in
> particular, the one I want...).

collated-files.html only shows the differences, not the actual
files.  Furthermore, these differences are calculated based on the
.eps or something like that, and text is *not* included in the
comparison!  For various reasons, the original authors of this
system deliberately did not use a pixel-based checker.

(at the present time I make no judgement about the validity of
their reasons, mainly because I can't remember what they were but
I know that they know far more than me about this stuff so I'm
content to trust them.  But if you want to investigate this later,
I could help dig up the old emails and then you could play around
with the build system and GUB)

> .ps files are created, but if I
> double click these, all I get is an image saying 'Loading...'

There _are_ ways of viewing the output from those .ps files
(although I could have sworn that the real data was in the .eps
files, not .ps -- also, watch out for foo.eps vs. foo-1.eps.  IIRC
the real data is in foo-1.eps!).  However, it requires finding the
right file(s), possibly specifying additional font information,
etc.

> Are we aware that make test doesn't create a usable document from
> which to view the output, or is it just an oddity of my system?

I'm aware that there are difficulties.  I have a vague sense that
this has been discussed within the past year and one of the
Germans (David/Werner/Reinhold) posted instructions for viewing
the output with ghostscript.

- Graham

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

Re: Set indent based on instrument name (issue 6457049)

[Graham Percival]

On Tue, Jul 31, 2012 at 04:13:20PM +0100, Phil Holmes wrote:
> - Original Message - From: "David Kastrup" 
> >So _how_ are you trying to accommodate?  Increase indent until the
> >instrument name fits wholly in the text width?  Let it stick out
> >somewhat?  How much?
> 
> Increase the indent until it accommodates the instrument name.

+1

> If the user then discovers they have only one note per line
> because of a stupidly long name, they have the option of changing
> the name, putting it in a column, changing the font, etc.  But they
> don't need to keep experimenting with indents.

One slight quibble: if a user explicitly sets indent=1\cm, then I
think it's fair to let the instrument name go off the left-hand
side of the page.  But unless the user messes around with the
indent, there's no excuse for violating page margins (let alone
page size!).

- Graham

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

Re: Patchy's built docs on the web

[Phil Holmes]

- Original Message - 
From: "John Mandereau" 

To: "Lily devel" 
Sent: Tuesday, July 31, 2012 4:18 PM
Subject: Patchy's built docs on the web



When lilypond-patchy-staging.py a.k.a. Patchy succesfully builds on MSH
Paris Nord server, it now puts the docs on

http://194.254.171.80/lilypond-web/master/

This is intended for use by all developers and contributors; I'm not
sure whether it duplicates docs on kainhofer.com/~lilypond/, it depends
on how Reinhold builds them.

(Sorry for the address with the IP, but I have no control over
lilynet.net or other sensible domains).
I want to test it a few more times before pushing Patchy changes to Git.

John



Looks good as a way of letting people who can't compile the docs see the 
output of their work - especially the PDFs.


I'm assuming that changes to patchy will make this an "opt-in" option - I 
don't want to ftp megs of files from home whenever I run patchy...


--
Phil Holmes 



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

Patchy's built docs on the web

[John Mandereau]

When lilypond-patchy-staging.py a.k.a. Patchy succesfully builds on MSH
Paris Nord server, it now puts the docs on

http://194.254.171.80/lilypond-web/master/

This is intended for use by all developers and contributors; I'm not
sure whether it duplicates docs on kainhofer.com/~lilypond/, it depends
on how Reinhold builds them.

(Sorry for the address with the IP, but I have no control over
lilynet.net or other sensible domains).
I want to test it a few more times before pushing Patchy changes to Git.

John


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

Re: Set indent based on instrument name (issue 6457049)

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 
Cc: 
Sent: Tuesday, July 31, 2012 3:40 PM
Subject: Re: Set indent based on instrument name (issue 6457049)



"Phil Holmes"  writes:


I can't actually help here since either problem description or what the
patch is trying to achieve is utterly absent from the issue.

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

"Set indent based on instrument name" is all that is described
anywhere.  _How_ the indent is supposed to be based on instrument names,
_when_ it is supposed to be based on instrument names, _what_ instrument
names it is supposed to be base on, _which_ indent is supposed to be
based on instrument names, _what_ problem this is trying to solve:

I draw a blank.  I can't even suggest what variables and organization to
use here since I have no clue what the problem is, and what the solution
tries to achieve.


Apologies - I intended to link to
http://code.google.com/p/lilypond/issues/detail?id=766 but clearly
omitted to do so.

The problem is that the left indent of staves is fixed with no
consideration of whether there is an instrument name to fit into that
indent.  So we can just about get away with "Violin", but any name
like "Baroque violin with horse hair strings" simply falls off the
left of the paper unless indent is manually adjusted.  The same is
true of short indent/short instrument name. In the same way that
lilypond moves music to avoid clashes and overlaps, it should
automatically adjust indent to accommodate the instrument names
used. IMHO it's the current worst example of poor typesetting that
lilypond provides.


So _how_ are you trying to accommodate?  Increase indent until the
instrument name fits wholly in the text width?  Let it stick out
somewhat?  How much?


Increase the indent until it accommodates the instrument name.  That's the 
_only_ sensible option (and it's what Sibelius does, FWIW).  If the user 
then discovers they have only one note per line because of a stupidly long 
name, they have the option of changing the name, putting it in a column, 
changing the font, etc.  But they don't need to keep experimenting with 
indents.



What's worse is that the images used in the documentation _do_ shift
right to accommodate instrument names, with the result that the image
pushes off the left of the page, and black bars result.


They probably also shift left, basically ignoring indent completely.
Cropping images based on contents rather than extent is always asking
for problems.


It's how our documentation system works.


I'm not trying to take a shortcut - I'm wandering down the only road I
can find.  I first asked for some pointers as to how to do this a week
ago, and since then I've been trying to work out a solution.  It took
me all day on Sunday to get the version that counted letters, and all
day yesterday to work out how to go from
markup->SCM->stencil->interval->length.  I actually think that's a
fair improvement and I'm pretty pleased with progress so far.

I now understand I need to either store the indent length in something
to do with a score context, or re-initialise it whenever a new score
is created. I'll have a go at working out how to do that, but I don't
even understand how to access contexts from c++, so it seems like it
would be a continuing number of days of poring over the code to find
out.

Any pointers (pun not intended) you could give to help me on my way
would be appreciated.


Where do indent and shortindent end up being used?  That's where the
results of your calculations likely need to be available.  And what kind
of variables you need to use depends on how the results from your
calculation are supposed to travel to the site of use.



There are 2 activities at work here.  The first is lilypond detecting and 
acting upon instrumentName/shortInstrumentName (I'll call this name in 
future) changes.  It does this with the Instrument_name_engraver and 
processes all the name changes before the indent is used to set the music. 
line_dimensions_int is then called by constrained-breaking.cc and 
page-layout-problem.cc to calculate where the music will be placed and then 
to place it on the stave.


--
Phil Holmes 



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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

"Phil Holmes"  writes:

>> I can't actually help here since either problem description or what the
>> patch is trying to achieve is utterly absent from the issue.
>>
>> http://code.google.com/p/lilypond/issues/detail?id=2703>
>>
>> "Set indent based on instrument name" is all that is described
>> anywhere.  _How_ the indent is supposed to be based on instrument names,
>> _when_ it is supposed to be based on instrument names, _what_ instrument
>> names it is supposed to be base on, _which_ indent is supposed to be
>> based on instrument names, _what_ problem this is trying to solve:
>>
>> I draw a blank.  I can't even suggest what variables and organization to
>> use here since I have no clue what the problem is, and what the solution
>> tries to achieve.
>
> Apologies - I intended to link to
> http://code.google.com/p/lilypond/issues/detail?id=766 but clearly
> omitted to do so.
>
> The problem is that the left indent of staves is fixed with no
> consideration of whether there is an instrument name to fit into that
> indent.  So we can just about get away with "Violin", but any name
> like "Baroque violin with horse hair strings" simply falls off the
> left of the paper unless indent is manually adjusted.  The same is
> true of short indent/short instrument name. In the same way that
> lilypond moves music to avoid clashes and overlaps, it should
> automatically adjust indent to accommodate the instrument names
> used. IMHO it's the current worst example of poor typesetting that
> lilypond provides.

So _how_ are you trying to accommodate?  Increase indent until the
instrument name fits wholly in the text width?  Let it stick out
somewhat?  How much?

> What's worse is that the images used in the documentation _do_ shift
> right to accommodate instrument names, with the result that the image
> pushes off the left of the page, and black bars result.

They probably also shift left, basically ignoring indent completely.
Cropping images based on contents rather than extent is always asking
for problems.

> I'm not trying to take a shortcut - I'm wandering down the only road I
> can find.  I first asked for some pointers as to how to do this a week
> ago, and since then I've been trying to work out a solution.  It took
> me all day on Sunday to get the version that counted letters, and all
> day yesterday to work out how to go from
> markup->SCM->stencil->interval->length.  I actually think that's a
> fair improvement and I'm pretty pleased with progress so far.
>
> I now understand I need to either store the indent length in something
> to do with a score context, or re-initialise it whenever a new score
> is created. I'll have a go at working out how to do that, but I don't
> even understand how to access contexts from c++, so it seems like it
> would be a continuing number of days of poring over the code to find
> out.
>
> Any pointers (pun not intended) you could give to help me on my way
> would be appreciated.

Where do indent and shortindent end up being used?  That's where the
results of your calculations likely need to be available.  And what kind
of variables you need to use depends on how the results from your
calculation are supposed to travel to the site of use.

-- 
David Kastrup

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

Re: Set indent based on instrument name (issue 6457049)

[Graham Percival]

On Tue, Jul 31, 2012 at 03:47:42PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > I think this is a bit too far.  Phil is trying to solve a
> > long-standing *extremely* annoying bug for documentation writers
> > which has not attracted much attention from "real" programmers.
> 
> I can't actually help here since either problem description or what the
> patch is trying to achieve is utterly absent from the issue.
> 
> http://code.google.com/p/lilypond/issues/detail?id=2703>

Right.  Looking at the pdf output of this:

\version "2.13.3"
\new Staff \with {
  instrumentName = "this is a really really long instrument name"
}{
  c'
}

I only see "rument name" to the left of the staff; the rest runs
off the left-hand side of the pdf page.  Printing text outside of
the page margins (let alone the page itself!) is bad.
http://code.google.com/p/lilypond/issues/detail?id=766

Phil is trying to solve this by automatically increasing
  \paper{ indent=5\cm} }
so that there's enough room to print the instrument name.  (5cm
picked randomly; it's intended to be long enough to print "this is
a really really long instrument name")

Changing the indent is not necessarily the best solution (although
I can't think of anything better), nor is his approach necessarily
the best method of implementing it.  But the bottom line is that
the above example produces a sucky pdf right now.

- Graham

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

Re: Set indent based on instrument name (issue 6457049)

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Tuesday, July 31, 2012 2:47 PM
Subject: Re: Set indent based on instrument name (issue 6457049)



Graham Percival  writes:


On Tue, Jul 31, 2012 at 02:14:17PM +0200, David Kastrup wrote:

And if you think this is purely hypothetical, check out
Documentation/snippets/incipit.ly.


David, thank you for identifying a specific problematic example.


There are exceptions to every rule.  But if you are calling for an
exception because you lack the skills for following the rule, it is
unlikely that your skills are sufficient for correctly identifying the
exception.


I think this is a bit too far.  Phil is trying to solve a
long-standing *extremely* annoying bug for documentation writers
which has not attracted much attention from "real" programmers.


I can't actually help here since either problem description or what the
patch is trying to achieve is utterly absent from the issue.

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

"Set indent based on instrument name" is all that is described
anywhere.  _How_ the indent is supposed to be based on instrument names,
_when_ it is supposed to be based on instrument names, _what_ instrument
names it is supposed to be base on, _which_ indent is supposed to be
based on instrument names, _what_ problem this is trying to solve:

I draw a blank.  I can't even suggest what variables and organization to
use here since I have no clue what the problem is, and what the solution
tries to achieve.


Apologies - I intended to link to 
http://code.google.com/p/lilypond/issues/detail?id=766 but clearly omitted 
to do so.


The problem is that the left indent of staves is fixed with no consideration 
of whether there is an instrument name to fit into that indent.  So we can 
just about get away with "Violin", but any name like "Baroque violin with 
horse hair strings" simply falls off the left of the paper unless indent is 
manually adjusted.  The same is true of short indent/short instrument name. 
In the same way that lilypond moves music to avoid clashes and overlaps, it 
should automatically adjust indent to accommodate the instrument names used. 
IMHO it's the current worst example of poor typesetting that lilypond 
provides.


What's worse is that the images used in the documentation _do_ shift right 
to accommodate instrument names, with the result that the image pushes off 
the left of the page, and black bars result.  This means that _every_ 
snippet with an instrument name requires experimentation and hand crafting 
to make it fit the docs.  Ugh.



I don't think that he realizes that he's asking for an exemption,
so no need to be rude about it.  Please either give us some hints
about how to store the information in an acceptable manner,


I can't since I have no idea what the code is supposed to do.  At the
current point of time I am pretty much reduced to stating that whatever
the code may be trying to do, it will not work reliably, and point out
why.

But I can't help doing it right if I don't even get a chance to guess
_what_ to do right.


or wait until Keith or Mike or somebody else has time to help.  Phil
is *precisely* the kind of person that we want to be helping with
lilypond, so please don't discourage him.


Well, he is trying to take a shortcut here.  I can tell him that the
shortcut is a dead end, but I since I have no idea where he actually
wants to go, I can't suggest an alternative path.

--
David Kastrup



I'm not trying to take a shortcut - I'm wandering down the only road I can 
find.  I first asked for some pointers as to how to do this a week ago, and 
since then I've been trying to work out a solution.  It took me all day on 
Sunday to get the version that counted letters, and all day yesterday to 
work out how to go from markup->SCM->stencil->interval->length.  I actually 
think that's a fair improvement and I'm pretty pleased with progress so far.


I now understand I need to either store the indent length in something to do 
with a score context, or re-initialise it whenever a new score is created. 
I'll have a go at working out how to do that, but I don't even understand 
how to access contexts from c++, so it seems like it would be a continuing 
number of days of poring over the code to find out.


Any pointers (pun not intended) you could give to help me on my way would be 
appreciated.


--
Phil Holmes 



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

Re: Set indent based on instrument name (issue 6457049)

[Phil Holmes]

- Original Message - 
From: 
To: ; ; 
; ; 

Cc: ; 
Sent: Tuesday, July 31, 2012 2:36 PM
Subject: Re: Set indent based on instrument name (issue 6457049)




http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc
File lily/output-def.cc (right):

http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc#newcode275
lily/output-def.cc:275: set_inst_name_len (Real long_inst_name_len, Real
short_inst_name_len)
Correct me if I am wrong, but it does not seem like you initialize
long_name_len/short_name_len other than globally.  Meaning that the
instrument names of the whole LilyPond run (possibly over thousands of
documentation snippets) are relevant for the results at the end.

http://codereview.appspot.com/6457049/



Correct.  I realised that last night, and this is why make test fails.  I 
sent an email identifying this as a problem, although I realise you can't 
possibly read every email.  The lengths need to be reset whenever there is a 
new score block.


--
Phil Holmes 



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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

Graham Percival  writes:

> On Tue, Jul 31, 2012 at 02:14:17PM +0200, David Kastrup wrote:
>> And if you think this is purely hypothetical, check out
>> Documentation/snippets/incipit.ly.
>
> David, thank you for identifying a specific problematic example.
>
>> There are exceptions to every rule.  But if you are calling for an
>> exception because you lack the skills for following the rule, it is
>> unlikely that your skills are sufficient for correctly identifying the
>> exception.
>
> I think this is a bit too far.  Phil is trying to solve a
> long-standing *extremely* annoying bug for documentation writers
> which has not attracted much attention from "real" programmers.

I can't actually help here since either problem description or what the
patch is trying to achieve is utterly absent from the issue.

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

"Set indent based on instrument name" is all that is described
anywhere.  _How_ the indent is supposed to be based on instrument names,
_when_ it is supposed to be based on instrument names, _what_ instrument
names it is supposed to be base on, _which_ indent is supposed to be
based on instrument names, _what_ problem this is trying to solve:

I draw a blank.  I can't even suggest what variables and organization to
use here since I have no clue what the problem is, and what the solution
tries to achieve.

> I don't think that he realizes that he's asking for an exemption,
> so no need to be rude about it.  Please either give us some hints
> about how to store the information in an acceptable manner,

I can't since I have no idea what the code is supposed to do.  At the
current point of time I am pretty much reduced to stating that whatever
the code may be trying to do, it will not work reliably, and point out
why.

But I can't help doing it right if I don't even get a chance to guess
_what_ to do right.

> or wait until Keith or Mike or somebody else has time to help.  Phil
> is *precisely* the kind of person that we want to be helping with
> lilypond, so please don't discourage him.

Well, he is trying to take a shortcut here.  I can tell him that the
shortcut is a dead end, but I since I have no idea where he actually
wants to go, I can't suggest an alternative path.

-- 
David Kastrup


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

Re: Set indent based on instrument name (issue 6457049)

[dak]

http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc
File lily/output-def.cc (right):

http://codereview.appspot.com/6457049/diff/4001/lily/output-def.cc#newcode275
lily/output-def.cc:275: set_inst_name_len (Real long_inst_name_len, Real
short_inst_name_len)
Correct me if I am wrong, but it does not seem like you initialize
long_name_len/short_name_len other than globally.  Meaning that the
instrument names of the whole LilyPond run (possibly over thousands of
documentation snippets) are relevant for the results at the end.

http://codereview.appspot.com/6457049/

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

Re: Set indent based on instrument name (issue 6457049)

[Graham Percival]

On Tue, Jul 31, 2012 at 02:14:17PM +0200, David Kastrup wrote:
> And if you think this is purely hypothetical, check out
> Documentation/snippets/incipit.ly.

David, thank you for identifying a specific problematic example.

> There are exceptions to every rule.  But if you are calling for an
> exception because you lack the skills for following the rule, it is
> unlikely that your skills are sufficient for correctly identifying the
> exception.

I think this is a bit too far.  Phil is trying to solve a
long-standing *extremely* annoying bug for documentation writers
which has not attracted much attention from "real" programmers.
He never claimed that he posses great skills, and he hasn't been
steeped in "minimize state" programmer culture of object-oriented
programming (to say nothing of functional programming!).  That's
why I used my analogy of nose picking, despite the fact that of
course there's reasons why it's ok in certain circumstances[1].
I figured that was a fast way to communicate that you really
shouldn't use them unless you know it's ok.

I don't think that he realizes that he's asking for an exemption,
so no need to be rude about it.  Please either give us some hints
about how to store the information in an acceptable manner, or
wait until Keith or Mike or somebody else has time to help.  Phil
is *precisely* the kind of person that we want to be helping with
lilypond, so please don't discourage him.

[1] for example, I use a static int in my FFT convolution class
because libfftw is not thread-safe and has a global variables as
part of their constructor/destructor.  :(

- Graham

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

Re: Set indent based on instrument name (issue 6457049)

[Bernard Hurley]

On Tue, Jul 31, 2012 at 12:59:16PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > On Mon, Jul 30, 2012 at 11:44:28PM +0100, Bernard Hurley wrote:
> >> On Mon, Jul 30, 2012 at 10:14:37PM +0100, Phil Holmes wrote:
> >> > - Original Message - From: 
> >> >> lily/output-def.cc:38: Real long_name_len = 0.0;
> >> >> could these be class member variables instead of global variables?
> >> >
> >> > I don't believe so.  I'd be happy to be corrected by someone who 
> >> > understands this better than I do, but my understanding of c++ (which I 
> >> > guess at based on c#) says that, in order to access a class member 
> >> > variable, you need to have an instantiation of the class. 
> >
> > That is true.
> >
> >> In C++ variables can be declared static. If this is done all instances of
> >> the class share the same instance of the variable and it can exist
> >> even if the class has no instances see:
> >
> > Yes, that's also true.
> >
> > Let me rephrase my concern: in C++-land, having a global variable
> > (including static variables) are viewed upon like picking one's
> > nose.
> 
> That's total nonsense with regard to static member variables.  There are
> perfectly valid reasons to have variables per-class (which is what a
> static member variable is) rather than per instance, for example for
> class reflection (information about the class itself, like its name and
> other stuff).  C++ uses the equivalent of static members for its virtual
> function tables.
> 
> For information _flow_ bound to instances, one would not use global
> variables.
> 
> It sounds like this would be the case here.
>

Moreover a static member variable can be declared private when it is
only available to methods of the class. This deals with the usual
objections to global variables.

Bernard Hurley

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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

"Phil Holmes"  writes:

>>> Question is - is it OK to modify my code to use statics,
>>
>> No.  Even engravers at score level are running in parallel, like when
>> using a \score markup or using the part combiner or quoting music and so
>> on.  Static variables just don't work in this setting.
>
> I'm sure that's not a problem here - the instrument name engraver
> finishes its work before the output-def indent code is called at all,
> so the name engraver "corrects" the indent before it's ever used.

If every name itself is a score, you'll trash your global variables
before all names have been typeset.

And if you think this is purely hypothetical, check out
Documentation/snippets/incipit.ly.

There are exceptions to every rule.  But if you are calling for an
exception because you lack the skills for following the rule, it is
unlikely that your skills are sufficient for correctly identifying the
exception.

-- 
David Kastrup

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

Re: GOP2-3: GLISS (update 1)

[Graham Percival]

On Tue, Jul 31, 2012 at 11:26:12AM +0100, Trevor Daniels wrote:
> 
> Graham Percival wrote Monday, July 30, 2012 7:11 PM
> 
> > \version "2.16.0"
> > \score {
...
> >  \midi {}
> > }
> 
> Currently this code produces no pdf and, if \layout {} is 
> added, no titles.
> 
> Was this an intentional suggestion for a change in syntax, 
> or just an oversight?

An oversight.  I've added the \layout{}.  How am I supposed to
print headers inside a \score [1]?  anyway, I moved the \header{}
outside of the \score and it now seems to work.

Thanks for the suggestion and warning!  New version uploaded.

[1] that was a rhetorical question; if I actually wanted to know
how to print a title properly, I'd RTFM.

- Graham

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

Re: Set indent based on instrument name (issue 6457049)

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Tuesday, July 31, 2012 12:50 PM
Subject: Re: Set indent based on instrument name (issue 6457049)



"Phil Holmes"  writes:

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Tuesday, July 31, 2012 12:04 PM
Subject: Re: Set indent based on instrument name (issue 6457049)



"Phil Holmes"  writes:


I'd be happy to change it if someone could suggest an improvement.
When I initially asked how this could be done, Keith said:

"Maybe each Instrument_name_engraver, one for each staff, could push
information to a central location"

which does sound rather like a global variable.


More like a Score-level context property.  And/or a grob announced on an
interface that an engraver at Score level listens to.

--
David Kastrup


Whoosh.  Straight over my head...


It may be worth asking on the user list.  That's the sort of thing
Thomas Morley and David Nalesnik are constantly cranking out in Scheme.


Question is - is it OK to modify my code to use statics,


No.  Even engravers at score level are running in parallel, like when
using a \score markup or using the part combiner or quoting music and so
on.  Static variables just don't work in this setting.


I'm sure that's not a problem here - the instrument name engraver finishes 
its work before the output-def indent code is called at all, so the name 
engraver "corrects" the indent before it's ever used.



or should I bother you with trying to understand what this means and
how to do it?


Since Keith were making the suggestions, he would know better what he
was envisioning here.


Don't think he's around at present - modem problems.

--
Phil Holmes 



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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: "David Kastrup" 
> To: 
> Sent: Tuesday, July 31, 2012 12:04 PM
> Subject: Re: Set indent based on instrument name (issue 6457049)
>
>
>> "Phil Holmes"  writes:
>>
>>> I'd be happy to change it if someone could suggest an improvement.
>>> When I initially asked how this could be done, Keith said:
>>>
>>> "Maybe each Instrument_name_engraver, one for each staff, could push
>>> information to a central location"
>>>
>>> which does sound rather like a global variable.
>>
>> More like a Score-level context property.  And/or a grob announced on an
>> interface that an engraver at Score level listens to.
>>
>> -- 
>> David Kastrup
>
> Whoosh.  Straight over my head...

It may be worth asking on the user list.  That's the sort of thing
Thomas Morley and David Nalesnik are constantly cranking out in Scheme.

> Question is - is it OK to modify my code to use statics,

No.  Even engravers at score level are running in parallel, like when
using a \score markup or using the part combiner or quoting music and so
on.  Static variables just don't work in this setting.

> or should I bother you with trying to understand what this means and
> how to do it?

Since Keith were making the suggestions, he would know better what he
was envisioning here.

-- 
David Kastrup


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

Re: Set indent based on instrument name (issue 6457049)

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Tuesday, July 31, 2012 12:04 PM
Subject: Re: Set indent based on instrument name (issue 6457049)



"Phil Holmes"  writes:


I'd be happy to change it if someone could suggest an improvement.
When I initially asked how this could be done, Keith said:

"Maybe each Instrument_name_engraver, one for each staff, could push
information to a central location"

which does sound rather like a global variable.


More like a Score-level context property.  And/or a grob announced on an
interface that an engraver at Score level listens to.

--
David Kastrup


Whoosh.  Straight over my head...

Question is - is it OK to modify my code to use statics, or should I bother 
you with trying to understand what this means and how to do it?


--
Phil Holmes 



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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

"Phil Holmes"  writes:

> I'd be happy to change it if someone could suggest an improvement.
> When I initially asked how this could be done, Keith said:
>
> "Maybe each Instrument_name_engraver, one for each staff, could push
> information to a central location"
>
> which does sound rather like a global variable.

More like a Score-level context property.  And/or a grob announced on an
interface that an engraver at Score level listens to.

-- 
David Kastrup


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

Re: Set indent based on instrument name (issue 6457049)

[David Kastrup]

Graham Percival  writes:

> On Mon, Jul 30, 2012 at 11:44:28PM +0100, Bernard Hurley wrote:
>> On Mon, Jul 30, 2012 at 10:14:37PM +0100, Phil Holmes wrote:
>> > - Original Message - From: 
>> >> lily/output-def.cc:38: Real long_name_len = 0.0;
>> >> could these be class member variables instead of global variables?
>> >
>> > I don't believe so.  I'd be happy to be corrected by someone who 
>> > understands this better than I do, but my understanding of c++ (which I 
>> > guess at based on c#) says that, in order to access a class member 
>> > variable, you need to have an instantiation of the class. 
>
> That is true.
>
>> In C++ variables can be declared static. If this is done all instances of
>> the class share the same instance of the variable and it can exist
>> even if the class has no instances see:
>
> Yes, that's also true.
>
> Let me rephrase my concern: in C++-land, having a global variable
> (including static variables) are viewed upon like picking one's
> nose.

That's total nonsense with regard to static member variables.  There are
perfectly valid reasons to have variables per-class (which is what a
static member variable is) rather than per instance, for example for
class reflection (information about the class itself, like its name and
other stuff).  C++ uses the equivalent of static members for its virtual
function tables.

For information _flow_ bound to instances, one would not use global
variables.

It sounds like this would be the case here.

-- 
David Kastrup

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

Re: Unify the lexer's idea of words and commands across all modes. (issue 6445056)

[dak]

Reviewers: Trevor Daniels,

Message:
On 2012/07/31 08:47:53, Trevor Daniels wrote:

Just a query really, to help my understanding.



Trevor



http://codereview.appspot.com/6445056/diff/1/lily/lexer.ll
File lily/lexer.ll (right):



http://codereview.appspot.com/6445056/diff/1/lily/lexer.ll#newcode390
lily/lexer.ll:390: {RESTNAME}/[-_]  |
Why is this trailing context added?  I don't see
what this would match that wouldn't be matched
by the following line.


Flex picks the longest matching pattern.  Apparently that includes
trailing contexts.  Without this pattern, r-. does not trigger the
{RESTNAME} rule but rather the {WORD}/[-_] rule coming later.  And for
the {WORD}/[-_] rule, the trailing context is needed to keep flex from
requiring backup states.

Description:
Unify the lexer's idea of words and commands across all modes.

A "word" (a string recognized even when not quoted) and a "command"
(something starting with \ and followed by letters and other folderol,
indicating a Scheme control sequence or similar) get the same syntax
in all modes:

A "word" is a sequence of alphabetic characters possibly containing
single dashes or underlines inside (not at the beginning or end).

A "command" is a "word" preceded by a backslash.


This is a large syntax change.  It should not be put on countdown
automatically.

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

Affected files:
  M lily/lexer.ll


Index: lily/lexer.ll
diff --git a/lily/lexer.ll b/lily/lexer.ll
index  
07bb33c6f7187979356d7e6ffac05cca3ba095a5..0824f21eb356e918251c458e692170694b55a227  
100644

--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -150,18 +150,14 @@ SCM (* scm_parse_error_handler) (void *);
 A  [a-zA-Z\200-\377]
 AA {A}|_
 N  [0-9]
-AN {AA}|{N}
 ANY_CHAR   (.|\n)
 PUNCT  [][()?!:'`]
 SPECIAL_CHAR   [&@]
 NATIONAL   [\001-\006\021-\027\031\036]
 TEX{AA}|-|{PUNCT}|{NATIONAL}|{SPECIAL_CHAR}
-DASHED_WORD{A}({AN}|-)*
-DASHED_KEY_WORD\\{DASHED_WORD}
+WORD   {A}([-_]{A}|{A})*
+COMMAND\\{WORD}

-
-
-ALPHAWORD  {A}+
 UNSIGNED   {N}+
 E_UNSIGNED \\{N}+
 FRACTION   {N}+\/{N}+
@@ -171,8 +167,6 @@ WHITE   [ \n\t\f\r]
 HORIZONTALWHITE[ \t]
 BLACK  [^ \n\t\f\r]
 RESTNAME   [rs]
-NOTECOMMAND\\{A}+
-MARKUPCOMMAND  \\({A}|[-_])+
 LYRICS ({AA}|{TEX})[^0-9 \t\n\r\f]*
 ESCAPED[nt\\'"]
 EXTENDER   __
@@ -393,15 +387,18 @@ BOM_UTF8  \357\273\277
error (_ ("end quote missing"));
exit (1);
 }
+{RESTNAME}/[-_]|
 {RESTNAME} {
char const *s = YYText ();
yylval.scm = scm_from_locale_string (s);
return RESTNAME;
 }
+q/[-_] |
 q  {
return CHORD_REPETITION;
 }

+R/[-_] |
 R  {
return MULTI_MEASURE_REST;
 }
@@ -476,11 +473,13 @@ BOM_UTF8  \357\273\277
 }

 {
-   {ALPHAWORD} {
+   {WORD}/[-_] |
+   {WORD}  {
return scan_bare_word (YYText_utf8 ());
}

-   {NOTECOMMAND}   {
+   {COMMAND}/[-_]  |
+   {COMMAND}   {
return scan_escaped_word (YYText_utf8 () + 1);
}
{FRACTION}  {
@@ -537,7 +536,8 @@ BOM_UTF8\357\273\277
yylval.scm = scm_c_read_string (YYText ());
return UNSIGNED;
}
-   {NOTECOMMAND}   {
+   {COMMAND}/[-_]  |
+   {COMMAND}   {
return scan_escaped_word (YYText_utf8 () + 1);
}
{LYRICS} {
@@ -563,10 +563,12 @@ BOM_UTF8  \357\273\277
}
 }
 {
-   {ALPHAWORD} {
+   {WORD}/[-_] |
+   {WORD}  {
return scan_bare_word (YYText_utf8 ());
}
-   {NOTECOMMAND}   {
+   {COMMAND}/[-_]  |
+   {COMMAND}   {
return scan_escaped_word (YYText_utf8 () + 1);
}
{FRACTION}  {
@@ -598,7 +600,7 @@ BOM_UTF8\357\273\277
return CHORD_CARET;
}
. {
-   return YYText ()[0]; // ALPHAWORD catches all multibyte.
+   return YYText ()[0]; // WORD catches all multibyte.
}
 }

@@ -607,7 +609,8 @@ BOM_UTF8\357\273\277
\\score {
return SCORE;
}
-   {MARKUPCOMMAND} {
+   {COMMAND}/[-_]  |
+   {COMMAND} {
string str (YYText_utf8 () + 1);

 int token_type = MARKUP_FUNCTION;
@@ -702,10 +705,12 @@ BOM_UTF8  \357\273\277
 }

 {
-   {DASHED_WORD}   {
+   {WORD}/[-_] |
+   {WORD}  {
return scan_bare_word (YYText_utf8 ());
}
-   {DASHED_KEY_WORD}   {
+   {COMMAND}/[-_]  |
+   {COMMAND}   {
return scan_escaped_word (YYText_utf8 () + 1);
}
 }



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

Re: GOP2-3: GLISS (update 1)

[Trevor Daniels]

Graham Percival wrote Monday, July 30, 2012 7:11 PM

> ** Subset for first phase
> 
> In greater detail: I’m suggesting that we have multiple rounds of
> syntax stabilization. The proposed elements of current lilypond
> notation which we will stabilize is captured by these two files:
> 
> \version "2.16.0"
> \score {
>  \new Staff {
>\new Voice {
>  \partial 8 d8 |
>  c4 d' e, f'' |
>  \times 2/3 {a4 b c} \grace {d16} d2 |
>  \acciaccatura {b16} c2 \appoggiatura {b16} c2 |
>}
>  }
>  \header {
>title = "don't overwrite this title"
>composer = "the lilypond GLISS team"
>  }
>  \midi {}
> }

Currently this code produces no pdf and, if \layout {} is 
added, no titles.

Was this an intentional suggestion for a change in syntax, 
or just an oversight?
 
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Problems with make test

[Phil Holmes]

OK - my instrument names/indent patch breaks make test.  Took me a while to 
find out why, but it's stem-length-estimation.ly, which crams a load of 
notes onto a single small page.  I suspect that the indent set on the 
previous score is hanging over into this one, causing it to be unable to get 
it on one page.  I'd like to check this.


So I open collated-files.html, to find that there are no images to eyeball. 
The HTML expects PNG files, but very few are created (in particular, the one 
I want...).  .ps files are created, but if I double click these, all I get 
is an image saying 'Loading...'


Are we aware that make test doesn't create a usable document from which to 
view the output, or is it just an oddity of my system?


--
Phil Holmes



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

Re: Fwd: Using MSH Paris Nord server

[John Mandereau]

Il giorno lun, 30/07/2012 alle 15.21 +0100, Graham Percival ha scritto:
> Ok.  I just want to emphasize that you could easily spend 20 hours
> setting this up, but then have the response be "no, we prefer the
> old system".

I got it :-P


> oh, logins just occurred to me.  Can gerrit let people log in with
> their google accounts (IIRC there's an api for that), or would we
> all need to make new accounts on the gerrit server?

The two options are
* using OpenId, see http://openid.net/get-an-openid/ (with the suboption
of restricting it to logins through HTTPS, or to Google accounts)
* setting up HTTP(S) authentification, requiring all of us to make new
accounts on that server.

I'm currently setting up the server with the default (OpenId), but I
don't mind changing it if there are strong wishes for the other option.

John


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

Re: Patchy email

[John Mandereau]

Il giorno mar, 31/07/2012 alle 09.45 +0100, Phil Holmes ha scritto:
> From: 
> > 04:35:09 (UTC) Begin LilyPond compile, previous commit at 
> > 1c980a9906a7ea01b9f99487e75580f7232f2491
> >
> > 04:35:11 Merged staging, now at: 1c980a9906a7ea01b9f99487e75580f7232f2491

> > 07:00:18 *** FAILED BUILD ***
> >
> > nice make doc -j2 CPU_COUNT=2 "WEB_TARGETS=online offline"
> >
> > Previous good commit:
> >
> > Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491
> >
> > 07:00:18 *** FAILED STEP ***
> >
> > merge from staging
> >
> > Failed runner: nice make doc -j2 CPU_COUNT=2 "WEB_TARGETS=online offline"
> >
> > See the log file 
> > log-staging-nice-make-doc--j2-CPU_COUNT=2-"WEB_TARGETS=online-offline".txt

> I'm confused by this.  AFAICS there's nothing in staging and therefore 
> nothing for patchy to do.  Wonder whether it's local repo got confused by an 
> old non-compiling patch?

No, it's me playing with Patchy, having blanked last_known in the config
file and trying to build with GCC flags for optimization (I already
noticed that this saves 2 minutes on "make test") and install built
documentation to make it available on the web.  I interrupted this build
as configure didn't get CXXFLAGS from the config file.  As the first two
lines of the log show an identical committish, I hoped not to raise
comments, but anyway I have disabled email sending the build I restarted
at 7:30 UTC and will enable it again when I finish a hacking round on
Patchy (I'd also like it to include more logs in the email when it
fails, or copy them to a configurable location for web access).

Cheers,
John


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

Unify the lexer's idea of words and commands across all modes. (issue 6445056)

[tdanielsmusic]

Just a query really, to help my understanding.

Trevor



http://codereview.appspot.com/6445056/diff/1/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6445056/diff/1/lily/lexer.ll#newcode390
lily/lexer.ll:390: {RESTNAME}/[-_]  |
Why is this trailing context added?  I don't see
what this would match that wouldn't be matched
by the following line.

http://codereview.appspot.com/6445056/

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

Re: Patchy email

[Phil Holmes]

- Original Message - 
From: 

To: 
Cc: 
Sent: Tuesday, July 31, 2012 8:00 AM
Subject: Patchy email


04:35:09 (UTC) Begin LilyPond compile, previous commit at 
1c980a9906a7ea01b9f99487e75580f7232f2491


04:35:11 Merged staging, now at: 1c980a9906a7ea01b9f99487e75580f7232f2491

04:35:13 Success: ./autogen.sh --noconfigure

04:35:38 Success: ../configure --disable-optimising

04:35:58 Success: nice make clean

04:42:46 Success: nice make -j2 CPU_COUNT=2 "WEB_TARGETS=online offline"

05:02:14 Success: nice make test -j2 CPU_COUNT=2 "WEB_TARGETS=online 
offline"


07:00:18 *** FAILED BUILD ***

nice make doc -j2 CPU_COUNT=2 "WEB_TARGETS=online offline"

Previous good commit:

Current broken commit: 1c980a9906a7ea01b9f99487e75580f7232f2491

07:00:18 *** FAILED STEP ***

merge from staging

Failed runner: nice make doc -j2 CPU_COUNT=2 "WEB_TARGETS=online offline"

See the log file 
log-staging-nice-make-doc--j2-CPU_COUNT=2-"WEB_TARGETS=online-offline".txt



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



I'm confused by this.  AFAICS there's nothing in staging and therefore 
nothing for patchy to do.  Wonder whether it's local repo got confused by an 
old non-compiling patch?


--
Phil Holmes 



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

Re: Set indent based on instrument name (issue 6457049)

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Bernard Hurley" 
Cc: "Phil Holmes" ; ; 
; ; 


Sent: Tuesday, July 31, 2012 12:12 AM
Subject: Re: Set indent based on instrument name (issue 6457049)



On Mon, Jul 30, 2012 at 11:44:28PM +0100, Bernard Hurley wrote:

On Mon, Jul 30, 2012 at 10:14:37PM +0100, Phil Holmes wrote:
> - Original Message - From: 
>> lily/output-def.cc:38: Real long_name_len = 0.0;
>> could these be class member variables instead of global variables?
>
> I don't believe so.  I'd be happy to be corrected by someone who
> understands this better than I do, but my understanding of c++ (which I
> guess at based on c#) says that, in order to access a class member
> variable, you need to have an instantiation of the class.


That is true.


In C++ variables can be declared static. If this is done all instances of
the class share the same instance of the variable and it can exist
even if the class has no instances see:


Yes, that's also true.

Let me rephrase my concern: in C++-land, having a global variable
(including static variables) are viewed upon like picking one's
nose.  If there is absolutely no other way to achieve one's goal,
it could be tolerated.  But I would be very surprised if this
could not be implemented without global variables, so I think
another draft of the patch will be necessary.

Hopefully somebody familiar with lilypond internals can skim the
patch (it's quite small) and give a suggestion as to how to avoid
the global variables.


I'd be happy to change it if someone could suggest an improvement.  When I 
initially asked how this could be done, Keith said:


"Maybe each Instrument_name_engraver, one for each staff, could push
information to a central location"

which does sound rather like a global variable.

--
Phil Holmes 



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