date:20120506

Carl Sorensen c_soren...@byu.edu writes:

 On May 5, 2012, at 8:16 PM, David Kastrup d...@gnu.org wrote:

 
 But what about \footnote: that does not have this problem.
 
 In fact, isn't  generally prettier than s1*0?  Should we be using it
 in code and documentation rather than s1*0?


 What a great idea!  No notes generated; the duration doesn't change. 

 Does  take any time?

No.  Time for  is registered by putting the same duration on every
element inside of the EventChord.

There is a drawback, though.  q is changed.  Now q is implemented as 
but with the current duration on it.  Which would mean that the total
moment of

{ c4  q }

would likely change when q gets expanded.  While c _is_ considered for
q for consistency's sake, perhaps  should be made to leave it alone.

-- 
David Kastrup

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

Re: Substitute for s1*0

2012-05-06 Thread Werner LEMBERG


 There is a drawback, though.  q is changed.  Now q is implemented as
  but with the current duration on it.  Which would mean that the
 total moment of
 
 { c4  q }
 
 would likely change when q gets expanded.  While c _is_ considered
 for q for consistency's sake, perhaps  should be made to leave it
 alone.

Sounds good.


Werner

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

Re: Lilypond miscompiled on Fedora 17

Pavel Roskin pro...@gnu.org writes:

 Quoting David Kastrup d...@gnu.org:

 We can probably use yes:400600[0-2]) here: 4.6.3 is supposed to contain
 the fix.

 Thank you for opening a separate ticket for it (2514) and reviewing my
 ticket (2513)!

Well, it means that my ticket goes through earlier, you will have to
rebase and resubmit your patch, just because I squeezed in a separate
ticket for something that is trivial.

Turned out, though, that it was quite less trivial than I imagined (and
the problem rather hard to track down and hard to test for), so
submitting it as a separate ticket with separate testing made more sense
than I was planning for.

-- 
David Kastrup


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

Re: Substitute for s1*0



David Kastrup wrote Sunday, May 06, 2012 2:57 AM


In fact, isn't  generally prettier than s1*0?  Should we be using it
in code and documentation rather than s1*0?


Definitely prettier, but maybe not so transparent as s1*0.
It is not intuitively obvious that an empty chord takes no
time and does not affect the current duration, rather than
being equivalent to an s, which of course takes the current
duration.  


Perhaps both should appear in the documentation, with a
word of explanation.  Users can then choose which they 
prefer.


Trevor


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

Re: Substitute for s1*0

On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote:
 
 David Kastrup wrote Sunday, May 06, 2012 2:57 AM
 
 In fact, isn't  generally prettier than s1*0?  Should we be using it
 in code and documentation rather than s1*0?
 
 Definitely prettier, but maybe not so transparent as s1*0.

+1

What about defining a
  null
or
  n
note name?  Then we could write
  c4 n\footnote

- Graham

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

Re: Substitute for s1*0

Trevor Daniels t.dani...@treda.co.uk writes:

 David Kastrup wrote Sunday, May 06, 2012 2:57 AM

 In fact, isn't  generally prettier than s1*0?  Should we be using it
 in code and documentation rather than s1*0?

 Definitely prettier, but maybe not so transparent as s1*0.

I disagree.

Quick: tell me what you would expect without too much thinking (imagine
you are a naive user) from the following:

\new Staff 
  \relative c'' { c4 d e f s1*0-\markup Oops c d e f g1 } \\
  \relative c' { c4 d e f -\markup Wow c d e f g1 }


That's not really a competition, is it?

 It is not intuitively obvious that an empty chord takes no
 time and does not affect the current duration, rather than
 being equivalent to an s, which of course takes the current
 duration.  

 Perhaps both should appear in the documentation, with a
 word of explanation.  Users can then choose which they prefer.

Multiplied durations are an advanced concept.  I prefer leaving their
explanation for the cases where they are required rather than
introducing them as a meme with side effects quite beyond those
intended for the meme.

There would be a reasonably good case for letting the current duration
in the parser always retain a factor of 1/1 instead of the fully
multiplied duration.  Or only consider durations with factor 1/1 for
duration tracking in the parser.

It would most likely almost always be more useful.  It would also be
less consistent.  In contrast, making  be invisible to q is a rather
minimally invasive change which also makes sure that the total time of
music does not change because of expanding repeat chords.

-- 
David Kastrup

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

Re: Substitute for s1*0

Graham Percival gra...@percival-music.ca writes:

 On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote:
 
 David Kastrup wrote Sunday, May 06, 2012 2:57 AM
 
 In fact, isn't  generally prettier than s1*0?  Should we be using it
 in code and documentation rather than s1*0?
 
 Definitely prettier, but maybe not so transparent as s1*0.

 +1

 What about defining a
   null
 or
   n
 note name?  Then we could write
   c4 n\footnote

What's the duration of
c n
?

What is the duration of
n4
?

Where is the point in a note name that does not take to the current
duration?  How is that making things simpler?

-- 
David Kastrup

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

Re: Substitute for s1*0

David Kastrup d...@gnu.org writes:

 Graham Percival gra...@percival-music.ca writes:

 On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote:
 
 David Kastrup wrote Sunday, May 06, 2012 2:57 AM
 
 In fact, isn't  generally prettier than s1*0?  Should we be using it
 in code and documentation rather than s1*0?
 
 Definitely prettier, but maybe not so transparent as s1*0.

 +1

 What about defining a
   null
 or
   n
 note name?  Then we could write
   c4 n\footnote

 What's the duration of
 c n
 ?

 What is the duration of
 n4
 ?

 Where is the point in a note name that does not take to the current
 duration?  How is that making things simpler?

Though of course 2 has the side effect of changing the current
duration in the parser to 2 without having a duration, either.  All in
all, I find

-\markup { Something }

more natural for no duration than

n-\markup { Something }

And it also has a natural representation in music already.

\displayLilyMusic -\markup { Something }

displays

-\markup \line { Something}

Oops.  Ok, need to fix that as well.  But \displayMusic outputs
something sensible.

-- 
David Kastrup


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

Re: Substitute for s1*0

2012-05-06 Thread Francisco Vila

Is s*0 valid? It would not change default duration of next note. Cannot
test right now, sorry.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

CG guide to building GUB (issue 6199045)

2012-05-06 Thread PhilEHolmes


Reviewers: Graham Percival, J_lowe,

Message:
Please review

Description:
Some notes on how to set up a GUB build environment.

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

Affected files:
  M Documentation/contributor/build-notes.itexi


Index: Documentation/contributor/build-notes.itexi
diff --git a/Documentation/contributor/build-notes.itexi  
b/Documentation/contributor/build-notes.itexi
index  
a1e258cc91a369eb8b65d06c70a8e2efe411f3d6..b2c4416eacbbc75b4bb70ea54833db2622ae9927  
100644

--- a/Documentation/contributor/build-notes.itexi
+++ b/Documentation/contributor/build-notes.itexi
@@ -15,6 +15,7 @@ chapter.}
 * Doc build::
 * Website build::
 * Building an Ubuntu distro::
+* Building GUB::
 @end menu


@@ -1501,3 +1502,68 @@ Test iso by installing in VM and repeating steps  
above for

 getting source files and building lp and docs.

 @end enumerate
+
+@node Building GUB
+@section Building GUB
+
+GUB - the Grand Unified Builder - is used to build the release
+versions of LilyPond.  For background information, see
+@ref{Grand Unified Builder (GUB)}.  The simplest way to set up a
+GUB build environment is to use a virtual machine with LilyDev
+(@ref{LilyDev}).  Follow the instructions on that page to set this
+up.  Make sure that your virtual machine has enough disk space -
+a GUB installation takes over 30 GBytes of disk space, and if you
+allocate too little, it will fail during the setting up stage and
+you will have to start again.  64 GBytes should be sufficient.
+
+While GUB is being built, any interruptions are likely to make it
+impossible to restart.  If at all possible, leave the build to
+continue uniterrupted.
+
+Download GUB and start the set up:
+
+@example
+git clone git://github.com/janneke/gub.git
+cd gub
+make bootstrap
+@end example
+
+This downloads and installs a number of packages.  You may find
+some fail during download and you will need to download them
+manually.  For example, the perl archive.  If this happens,
+download it from
+@uref{http://www.cpan.org/src/5.0/perl-5.10.0.tar.gz}, saving the
+archive to @file{gub/downloads/perl/}.  Continue the set up with:
+
+@example
+make bootstrap
+@end example
+
+Once this has completed successfully, you can build the LilyPond
+release package.  However, this uses an archived version of the
+regression tests, so it is better to download this first.
+Download the test output from lilypond.org:
+
+@smallexample
+@uref{http://lilypond.org/download/binaries/test-output/lilypond-2.15.33-1.test-output.tar.bz2}
+@end smallexample
+
+Copy the tarball into @file{gub/regtests/}, and tell the build
+system that you have done this:
+
+@example
+touch regtests/ignore
+@end example
+
+Now start the GUB build:
+
+@example
+make lilypond
+@end example
+
+That's it.  This will build LilyPond from current master.  To build
+the current unstable release, run:
+
+@example
+make LILYPOND_BRANCH=release/unstable lilypond
+@end example



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

Re: CG guide to building GUB (issue 6199045)

2012-05-06 Thread graham

great start; a few notes for you or James to investigate.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi
File Documentation/contributor/build-notes.itexi (right):

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1517
Documentation/contributor/build-notes.itexi:1517: you will have to start
again. 64 GBytes should be sufficient.
I'm quite happy with recommending a large disk size for this, but my own
gub/ dir (including target/) is 14 megs, and that directory is untouched
since building 2.15.38.

If yours is larger, do you have multiple target/ directories (i.e. a
backup?), or is it because the filesystem itself only stores larger
files, or lots of old regtest tarballs, or...?

again, I'm totally on board with recommending a large disk. I just
think it would be good to investigate this discrepancy.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1520
Documentation/contributor/build-notes.itexi:1520: impossible to restart.
If at all possible, leave the build to
I'd say extremely difficult here, instead of impossible. You can
find the package that failed to build, then force a complete rebuild
with some archaic set of commands that are probably listed in the
README, then continue as expected... but it's easier just to nuke the
whole target/ dir and start from scratch.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1526
Documentation/contributor/build-notes.itexi:1526: git clone
git://github.com/janneke/gub.git
please point to my gub dir now, since it has extra bugfixes compared to
Jan's version.
https://github.com/gperciva/gub

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1535
Documentation/contributor/build-notes.itexi:1535:
@uref{http://www.cpan.org/src/5.0/perl-5.10.0.tar.gz}, saving the
could you (or James) double-check this?

According to my notes from 2012 Feb 17, manual attention is only needed
for
bin/gub tools::netpbm
bin/gub tools::rsync
http://code.google.com/p/lilypond/issues/detail?id=2184

http://codereview.appspot.com/6199045/

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

Re: Substitute for s1*0

Francisco Vila paconet@gmail.com writes:

 Is s*0 valid?

No.  *0 is part of the duration, not some magical repeat count.

 It would not change default duration of next note.

It should, if it were allowed.

-- 
David Kastrup

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

Re: Substitute for s1*0

2012-05-06 Thread Pavel Roskin


Quoting Graham Percival gra...@percival-music.ca:


On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote:


David Kastrup wrote Sunday, May 06, 2012 2:57 AM

In fact, isn't  generally prettier than s1*0?  Should we be using it
in code and documentation rather than s1*0?

Definitely prettier, but maybe not so transparent as s1*0.


+1

What about defining a
  null
or
  n
note name?  Then we could write
  c4 n\footnote


My preference is z.  There are fewer words that start with z than  
with n and it's easy to remember z as shorthand for zero.


Reusing symbols like  and  for new meanings would turn Lilypond  
sources into something like Perl.


--
Regards,
Pavel Roskin

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

Re: CG guide to building GUB (issue 6199045)

2012-05-06 Thread PhilEHolmes

On 2012/05/06 11:27:47, Graham Percival wrote:

great start; a few notes for you or James to investigate.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi

File Documentation/contributor/build-notes.itexi (right):

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1517

Documentation/contributor/build-notes.itexi:1517: you will have to

start again.

64 GBytes should be sufficient.
I'm quite happy with recommending a large disk size for this, but my

own gub/

dir (including target/) is 14 megs, and that directory is untouched

since

building 2.15.38.

If yours is larger, do you have multiple target/ directories (i.e. a

backup?),

or is it because the filesystem itself only stores larger files, or

lots of old

regtest tarballs, or...?

again, I'm totally on board with recommending a large disk. I just

think it

would be good to investigate this discrepancy.

The filesystem I created was 64 Gigs, and it shows 36.8 free - so 30
gigs is the bare minimum. My GUB directory is about 12 Gigs, and my
total file size is around 17 Gigs, so there's other stuff like file
system overhead, swap, etc., using up some other space.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1520

Documentation/contributor/build-notes.itexi:1520: impossible to

restart. If at

all possible, leave the build to
I'd say extremely difficult here, instead of impossible. You can

find the

package that failed to build, then force a complete rebuild with some

archaic

set of commands that are probably listed in the README, then continue

expected... but it's easier just to nuke the whole target/ dir and

start from

scratch.

I've changed it to say almost impossible.

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1526

Documentation/contributor/build-notes.itexi:1526: git clone
git://github.com/janneke/gub.git
please point to my gub dir now, since it has extra bugfixes compared

to Jan's

version.
https://github.com/gperciva/gub

I assume git://github.com/gperciva/gub is the correct syntax for the git
clone?

http://codereview.appspot.com/6199045/diff/1/Documentation/contributor/build-notes.itexi#newcode1535

Documentation/contributor/build-notes.itexi:1535:
@uref{http://www.cpan.org/src/5.0/perl-5.10.0.tar.gz}, saving the
could you (or James) double-check this?

According to my notes from 2012 Feb 17, manual attention is only

needed for

bin/gub tools::netpbm
bin/gub tools::rsync
http://code.google.com/p/lilypond/issues/detail?id=2184

It did fail for me consistently, a number of times. However, I'm only
really giving it as an example of what to do if any package fails to
download.

http://codereview.appspot.com/6199045/

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

Re: CG guide to building GUB (issue 6199045)

2012-05-06 Thread graham


On 2012/05/06 13:06:09, PhilEHolmes wrote:

The filesystem I created was 64 Gigs, and it shows 36.8 free - so 30

gigs is the

bare minimum.  My GUB directory is about 12 Gigs, and my total file

size is

around 17 Gigs,


ah, that makes sense.  I was only looking at the directory, but of
course the most important thing somebody needs to know is how large to
make the partition.


 https://github.com/gperciva/gub



I assume git://github.com/gperciva/gub is the correct syntax for the

git clone?

Yes, that's what I see on the github page.  I haven't tested it myself,
but that looks like the right form... no wait.  I see this:
git://github.com/gperciva/gub.git
(with an extra .git at the end)



 According to my notes from 2012 Feb 17, manual attention is only

needed for

   bin/gub tools::netpbm
   bin/gub tools::rsync
 http://code.google.com/p/lilypond/issues/detail?id=2184



It did fail for me consistently, a number of times.


Before or after Feb 17?


However, I'm only really
giving it as an example of what to do if any package fails to

download.

My point is that you shouldn't need to poke around inside the downloads/
directory manually, and AFAIK the above commands are the only ones that
you need to do.  I'm sure that I completely wiped my target/ and
download/ directories and rebuilt from scratch, so in Feb it was
possible to avoid poking around manually.  Something may have changed
before or after then, of course.

Hopefully James will run these instructions later this afternoon and
then he can tell us if there's any problems or not.

- Graham

http://codereview.appspot.com/6199045/

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

Re: Substitute for s1*0

Pavel Roskin pro...@gnu.org writes:

 Quoting Graham Percival gra...@percival-music.ca:

 On Sun, May 06, 2012 at 08:58:11AM +0100, Trevor Daniels wrote:

 David Kastrup wrote Sunday, May 06, 2012 2:57 AM

 In fact, isn't  generally prettier than s1*0?  Should we be using it
 in code and documentation rather than s1*0?

 Definitely prettier, but maybe not so transparent as s1*0.

 +1

 What about defining a
   null
 or
   n
 note name?  Then we could write
   c4 n\footnote

 My preference is z.  There are fewer words that start with z than
 with n and it's easy to remember z as shorthand for zero.

 Reusing symbols like  and  for new meanings would turn Lilypond
 sources into something like Perl.

It is not a reuse.  It already works fine.  q does not behave
consistently when used around it, but that is basically a one-line
change and a problem of q.  \displayLilyMusic does not show it right,
but since it is valid input, that is more the problem of
\displayLilyMusic rather than anything else.  I am just fixing that.

There may be a case for making
 { c4 d } { -. -- } 
produce the same output/stream-events as { c4-. d-- }: that would be a
decent expectation.

However, chords   do not carry duration information by themselves but
only by virtue of propagating it to their elements, of which there are
none in  .

I am not fond of the behavior of 4 (the duration, short of setting the
default duration in the parser, will get ignored) and will readily admit
that.  However,  is rather idiomatic and thus one will less likely
fancy the idea of writing 4 than one would writing z4, and the
inconsistency in behavior when writing the former strikes me as less
unsavory than of the latter:  ...  works as a duration override.  You
can write

sample = c2

 \sample 4

and the result will be a quarter note.  That a content-less chord does
not catch durations is somewhat understandable.  For something called z,
this is a bit less obvious.

-- 
David Kastrup


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

Re: Your Gnu package lilypond

On Sun, May 06, 2012 at 05:15:59AM -0400, John Darrington wrote:
 Thank you for your very comprehensive reply, which inspired me to 
 look at the lilypond website.  It is indeed very elaborate and
 certainly gives a very professional impression. (There are however
 a few terminology issues which I think need attention - See section
 14 of the GNU Maintainers guide 
 http://www.gnu.org/prep/maintain/maintain.html )

Janek, how about you fix this.  I found one instance:


http://lilypond.org/freedom.html
has a big Free Software at the top.  The only place open
source is mentioned is almost at the bottom of the page, in the
quote
 “Gift culture”: the Free Software (or “Open Source”) movement
has created many great software projects, such as GNU/Linux,
Mozilla Firefox, and Battle for Wesnoth. Having benefitted from
these projects, some developers want to “give back” to the
community. 

I suppose that you're objecting because I wrote or in there, and
you would rather that I replace that or with sometimes
erroneously referred to as ?



but you should review the rest of the website to see if there's
any other terminology issues.

- Graham

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

Re: how to remove a file

2012-05-06 Thread Federico Bruni


I'm putting -devel in CC.
Sorry for pushing, I'm in a hurry: I'd like to send the patches within 
tonight.


Il 06/05/2012 15:53, Federico Bruni ha scritto:

Hi,

I have to remove the .texidoc file of a snippet which has been removed:

diff --git
a/Documentation/snippets/piano-template-with-centered-dynamics.ly
b/Documentation/snippets/piano-template-with-centered-dynamics.ly
deleted file mode 100644
index f56fc58..000
--- a/Documentation/snippets/piano-template-with-centered-dynamics.ly
+++ /dev/null


I wonder if I should use 'rm' or 'git rm'.
I know that the difference is that rm keeps the file in the git index,
while git rm removes it both from index and working copy.
I think that I should use git rm, but I prefer asking as I have a poor
understanding of git.

Thanks,
Federico


I made a try:

$ git rm 
Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc
error: 
'Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc' has 
local modifications

(use --cached to keep the file, or -f to force removal)

What's the recommended method?

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

Re: Substitute for s1*0



David Kastrup wrote Sunday, May 06, 2012 9:34 AM


Quick: tell me what you would expect without too much thinking (imagine
you are a naive user) from the following:

\new Staff 
 \relative c'' { c4 d e f s1*0-\markup Oops c d e f g1 } \\
 \relative c' { c4 d e f -\markup Wow c d e f g1 }

That's not really a competition, is it?


Well, that's a poor example, as neither form is needed when
there is a string of notes or s's.  So this particular issue
doesn't really arise in practice.

Actually, I don't think s1*0 appears in the docs.  Might be
in an LSR snippet, I guess.  But I've no problem with
documenting , as long as a realistic example showing
when it is useful can be found.

Trevor


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

Re: Substitute for s1*0

Trevor Daniels t.dani...@treda.co.uk writes:

 David Kastrup wrote Sunday, May 06, 2012 9:34 AM

 Quick: tell me what you would expect without too much thinking (imagine
 you are a naive user) from the following:

 \new Staff 
  \relative c'' { c4 d e f s1*0-\markup Oops c d e f g1 } \\
  \relative c' { c4 d e f -\markup Wow c d e f g1 }

 That's not really a competition, is it?

 Well, that's a poor example, as neither form is needed when
 there is a string of notes or s's.  So this particular issue
 doesn't really arise in practice.

 Actually, I don't think s1*0 appears in the docs.

dak@lola:/usr/local/tmp/lilypond$ git grep 's1\*0' Documentation
Documentation/de/extending/scheme-tutorial.itely:@{  \music s1*0-.- @}
Documentation/de/notation/changing-defaults.itely:  s1*0^Small, thicker 
stems, no time signature
Documentation/de/notation/changing-defaults.itely:  s1*0^Different
Documentation/de/notation/keyboards.itely:e''2\p\ d''\ s1*0\!
Documentation/de/notation/pitches.itely:s1*0^\markup { B-Klarinette benutzen }
Documentation/de/notation/spacing.itely:   #{ s1*0^\markup { \typewriter 
#context } #})
Documentation/de/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/de/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/de/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/de/notation/staff.itely:s1*0^\markup { \tiny flute }
Documentation/de/notation/vocal.itely:  s1*0^\markup { \right-align { \tiny 
Flute } }
Documentation/de/notation/vocal.itely:  s1*0_\markup { \right-align { \tiny 
Clar. } }
Documentation/es/extending/scheme-tutorial.itely:@{  \music s1*0-.- @}
Documentation/es/notation/changing-defaults.itely:  s1*0^Small, thicker 
stems, no time signature
Documentation/es/notation/changing-defaults.itely:  s1*0^Different
Documentation/es/notation/keyboards.itely:e''2\p\ d''\ s1*0\!
Documentation/es/notation/pitches.itely:s1*0^\markup { Switch to B\flat 
clarinet }
Documentation/es/notation/spacing.itely:   #{ s1*0^\markup { \typewriter 
#context } #})
Documentation/es/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/es/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/es/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/es/notation/staff.itely:s1*0^\markup { \tiny flute }
Documentation/es/notation/vocal.itely:  s1*0^\markup { \right-align { \tiny 
Flute } }
Documentation/es/notation/vocal.itely:  s1*0_\markup { \right-align { \tiny 
Clar. } }
Documentation/extending/scheme-tutorial.itely:@{  \music s1*0-.- @}
Documentation/fr/extending/scheme-tutorial.itely:@{  \musique s1*0-.- @}
Documentation/fr/notation/changing-defaults.itely:  s1*0^Small, thicker 
stems, no time signature
Documentation/fr/notation/changing-defaults.itely:  s1*0^Different
Documentation/fr/notation/keyboards.itely:e''2\p\ d''\ s1*0\!
Documentation/fr/notation/pitches.itely:s1*0^\markup { Switch to B\flat 
clarinet }
Documentation/fr/notation/spacing.itely:   #{ s1*0^\markup { \typewriter 
#context } #})
Documentation/fr/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/fr/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/fr/notation/staff.itely:  s1*0^\markup { \tiny flute }
Documentation/fr/notation/staff.itely:s1*0^\markup { \tiny flute }
Documentation/fr/notation/vocal.itely:  s1*0^\markup { \right-align { \tiny 
Flute } }
Documentation/fr/notation/vocal.itely:  s1*0_\markup { \right-align { \tiny 
Clar. } }
Documentation/included/note-head-style.ly:  s1*0^\markup { default }
Documentation/included/note-head-style.ly:  s1*0^\markup { altdefault }
Documentation/included/note-head-style.ly:  s1*0^\markup { baroque }
Documentation/included/note-head-style.ly:  s1*0^\markup { neomensural }
Documentation/included/note-head-style.ly:  s1*0^\markup { mensural }
Documentation/included/note-head-style.ly:  s1*0^\markup { petrucci }
Documentation/included/note-head-style.ly:  s1*0^\markup { harmonic }
Documentation/included/note-head-style.ly:  s1*0^\markup { harmonic-black }
Documentation/included/note-head-style.ly:  s1*0^\markup { harmonic-mixed }
Documentation/included/note-head-style.ly:  s1*0^\markup { diamond }
Documentation/included/note-head-style.ly:  s1*0^\markup { cross }
Documentation/included/note-head-style.ly:  s1*0^\markup { xcircle }
Documentation/included/note-head-style.ly:  s1*0^\markup { triangle }
Documentation/included/note-head-style.ly:  s1*0^\markup { slash }
Documentation/it/notation/pitches.itely:s1*0^\markup { Switch to B\flat 
clarinet }
Documentation/ja/notation/changing-defaults.itely:  s1*0^Small, thicker 
stems, no time signature
Documentation/ja/notation/changing-defaults.itely:  s1*0^Different
Documentation/ja/notation/keyboards.itely:e''2\p\ d''\ s1*0\!
Documentation/ja/notation/pitches.itely:s1*0^\markup { Switch to B\flat 
clarinet }
Documentation/ja/notation/spacing.itely:   #{ s1*0^\markup { \typewriter

Re: Substitute for s1*0

Trevor Daniels t.dani...@treda.co.uk writes:

 David Kastrup wrote Sunday, May 06, 2012 9:34 AM

 Quick: tell me what you would expect without too much thinking (imagine
 you are a naive user) from the following:

 \new Staff 
  \relative c'' { c4 d e f s1*0-\markup Oops c d e f g1 } \\
  \relative c' { c4 d e f -\markup Wow c d e f g1 }

 That's not really a competition, is it?

 Well, that's a poor example, as neither form is needed when
 there is a string of notes or s's.  So this particular issue
 doesn't really arise in practice.

I prefer things not to blow up even for poor examples.  s1*0 will change
the current parser duration to something that works quite unexpectedly
for the average user, and it will rarely be the last duration in the
whole file.

-- 
David Kastrup


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

Re: Substitute for s1*0

Janek Warchoł janek.lilyp...@gmail.com writes:

 On Sun, May 6, 2012 at 6:56 AM, Werner LEMBERG w...@gnu.org wrote:
 In fact, isn't  generally prettier than s1*0?  Should we be using
 it in code and documentation rather than s1*0?

 What a great idea!  No notes generated; the duration doesn't
 change.

 Indeed!  I wasn't aware that  is valid syntax at all.

 +1

URL:http://code.google.com/p/lilypond/issues/detail?id=2517 makes 
work as expected with \displayLilyMusic and transparent for chord
repeats q.

In contrast to other new features, it will not be necessary to refrain
from using it instead of s1*0 in examples intended for LilyPond 2.14 or
older, so I am copying the user list with this discovery of an old
feature.

Mentioning this in the Changes section will make sense when
simultaneously changing most of the uses of s1*0 in the docs, and I
think I am done for the day right now.  If someone wants to pick this
up, I will not be unhappy.  Followups of this side-thread directed to
the general user list.

-- 
David Kastrup

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

Intregrating lilypond.pot update to 'make release'

2012-05-06 Thread Jean-Charles Malahieude


Hi Jan and Graham,

Since I got a problem the last time I notified the Free Translation 
Project of a new lilypond.pot, I'd like to have it updated during the 
releasing process.


What you'll find in the enclosed patch is an attempt to adapt
'make po-replace' in order to have an automatically well-formed .pot 
included in 'make dist'.


I'll let Graham, if he agrees with this matter, incorporate a call to 
po-replace in his 'make release'.


Cheers,
Jean-Charles
diff --git a/po/README b/po/README
index 7b9c400..b4c7571 100644
--- a/po/README
+++ b/po/README
@@ -28,12 +28,13 @@ automatically notified to lilypond-devel@gnu.org list by the FTP
 robot; you can also see LilyPond page on FTP.
 
 
-2) updating lilypond.pot: run 'make po-replace' at toplevel, clean up
-lilypond.pot header to make it look like its previous state, commit
-only lilypond.pot to Git and reset all .po files, roll a tarball with
-'make dist', upload it somewhere on the web (or wait for the release),
-and send a notification to FTP coordinator with a link to the tarball.
-
+2) updating lilypond.pot: run 'make po-replace' at toplevel, commit
+lilypond.pot to Git, roll a tarball with 'make dist', upload it
+somewhere on the web (or wait for the release), and send a notification
+to FTP coordinator with a link to the tarball.
+Running 'po-update' at top-level and openning either po/out/fr.po or
+po/out/es.po gives you an idea of the changes that have affected
+the sources (number of fuzzy and untranslated stings).
 
 Rationale
 =
diff --git a/stepmake/stepmake/po-targets.make b/stepmake/stepmake/po-targets.make
index 05088ee..bb6215c 100644
--- a/stepmake/stepmake/po-targets.make
+++ b/stepmake/stepmake/po-targets.make
@@ -1,5 +1,14 @@
-
-
+XGETTEXT_OPTIONS = \
+	--default-domain=$(package) \
+	--from-code=UTF-8 \
+	--join \
+	--add-comments \
+	--msgid-bugs-address=http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs; \
+	--package-name=$(package) \
+	--package-version=$(VERSION)
+
+sed-header = \# Translation of LilyPond\n\# Copyright \(C\) 1998--2012 Han-Wen Nienhuys, Jan Nieuwenhuizen.\n\# This file is distributed under the same license as the LilyPond package.
+sed-content = Content-Type: text\/plain; charset=UTF-8\\n
 
 
  UGH!
@@ -21,12 +30,14 @@ ALL_PO_SOURCES = $(ALL_C_SOURCES) $(ALL_CC_SOURCES) $(PYTHON_SCRIPTS_IN) $(PY_MO
 local-po:
 ifneq ($(strip $(ALL_PO_SOURCES)),)
 	@echo $(ALL_PO_SOURCES)
-	xgettext --default-domain=$(package) --join \
-	 --output-dir=$(po-dir)/$(outdir) --add-comments \
+	xgettext $(XGETTEXT_OPTIONS) --output-dir=$(po-dir)/$(outdir) \
 	 --keyword=_ --keyword=_f --keyword=_i \
 	 $(XGETTEXT_FLAGS) $(ALL_PO_SOURCES)
 endif
 endif
+	sed -i '1,2d' $(po-dir)/$(outdir)/$(package).po
+	sed -i -e 's/^\# This file is distributed.*/$(sed-header)/' $(po-dir)/$(outdir)/$(package).po
+	sed -i -e 's/^\Content-Type: text\/plain.*/$(sed-content)/' $(po-dir)/$(outdir)/$(package).po
 
 
 po-update: po
diff --git a/stepmake/stepmake/podir-targets.make b/stepmake/stepmake/podir-targets.make
index 0b831c5..fdfa5ef 100644
--- a/stepmake/stepmake/podir-targets.make
+++ b/stepmake/stepmake/podir-targets.make
@@ -29,4 +29,3 @@ po-changes:
 
 po-replace: po-update
 	mv $(outdir)/$(package).po $(package).pot
-	mv $(outdir)/*.po .
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: how to remove a file

On Sun, May 06, 2012 at 05:32:08PM +0200, Federico Bruni wrote:
 I made a try:
 
 $ git rm 
 Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc
 error: 
 'Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc'
 has local modifications
 (use --cached to keep the file, or -f to force removal)
 
 What's the recommended method?

Use -f to force removal?  Yes, that's recommended.

- Graham

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

translators: fix your open source mistranslations

I have a bit more information about the terminology problems.
Although the English website is relatively ok (I remember
specifically thinking about free software vs. open source while
writing it -- but Janek should still fix the little bits I
missed), some translations are wrong.

For example,

On Sun, May 06, 2012 at 11:30:19AM -0400, John Darrington wrote:
 My system happens to be set up in a German locale, so  I see the German
 translations by default.  On the front page I see:
 
   LilyPond ist ein Open Source-Programm 
 
 In fact it seems that in many (all?) places  Free Software has been 
 mistranslated as Open Source.

Free software and open source do not mean the same thing; if
in doubt, find some official GNU guide on translations or
something.


We have historically not had much to do with GNU, but it seems
that we're moving into an era where we have closer ties.  This
will mean a bit of extra administrative work to match unavoidable
GNU policies.

- Graham

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

Re: Intregrating lilypond.pot update to 'make release'

On Sun, May 06, 2012 at 06:19:42PM +0200, Jean-Charles Malahieude wrote:
 What you'll find in the enclosed patch is an attempt to adapt
 'make po-replace' in order to have an automatically well-formed .pot
 included in 'make dist'.

Please upload patches to rietveld with git-cl, as specified here:
http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers

With specific regards to the release, I would need a patch to the
CG release process instructions:
http://lilypond.org/doc/v2.15/Documentation/contributor/minor-release-checklist

For reliability, I never deviate from this checklist.

- Graham

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

Re: translators: fix your open source mistranslations

2012-05-06 Thread Jean-Charles Malahieude


Le 06/05/2012 18:31, Graham Percival disait :

I have a bit more information about the terminology problems.
Although the English website is relatively ok (I remember
specifically thinking about free software vs. open source while
writing it -- but Janek should still fix the little bits I
missed), some translations are wrong.

For example,

On Sun, May 06, 2012 at 11:30:19AM -0400, John Darrington wrote:

My system happens to be set up in a German locale, so  I see the German
translations by default.  On the front page I see:

   LilyPond ist ein Open Source-Programm

In fact it seems that in many (all?) places  Free Software has been
mistranslated as Open Source.


Free software and open source do not mean the same thing; if
in doubt, find some official GNU guide on translations or
something.


We have historically not had much to do with GNU, but it seems
that we're moving into an era where we have closer ties.  This
will mean a bit of extra administrative work to match unavoidable
GNU policies.



Just two instances in GSoC node that I'm not sure they should be 
transformed:


fr (translation)]$ git grep -n 'open source'
web/community.itexi:930:étudiants pour écrire du code au bénéfice de 
projets @emph{open source}.
web/community.itexi:931:Google a travaillé de concert avec la communauté 
@emph{open source} afin




By the way, http://www.gnu.org/manual/ links to
http://lilypond.org/web/documentation
instead of http://www.lilypond.org/manuals.html

Cheers,
Jean-Charles


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

Re: staff_radius fixes (issue 6202048)

2012-05-06 Thread benko . pal


this patch makes staff_radius work in cases when line-positions is

overridden.

so long staff_radius assumed overriding at most line-count.


sorry, I forgot to mention that
- staff-radius behaved incorrectly also when staff-space is overridden
- there's one slight difference in the regression test
ledger-lines-varying-staves.ly, where line-positions is overridden.

http://codereview.appspot.com/6202048/

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

Re: translators: fix your open source mistranslations

On Sun, May 06, 2012 at 07:02:20PM +0200, Jean-Charles Malahieude wrote:
 
 Just two instances in GSoC node that I'm not sure they should be
 transformed:
 
 fr (translation)]$ git grep -n 'open source'
 web/community.itexi:930:étudiants pour écrire du code au bénéfice de
 projets @emph{open source}.
 web/community.itexi:931:Google a travaillé de concert avec la
 communauté @emph{open source} afin

Hmm.  The English version is a direct quote from google's website,
and of course one should never change direct quotes.  Now if
you're translating the quote for some reason, then I guess you
should try to keep as close to the original meaning as possible...
and in google's case, they definitely mean open source instead
of free software.

So I guess those shouldn't be changed, and if that's it in the
French translation then I guess you're fine.

- Graham

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

Re: [translations] Re: how to remove a file

2012-05-06 Thread Francisco Vila

2012/5/6 Federico Bruni fedel...@gmail.com:
 I'm putting -devel in CC.
 Sorry for pushing, I'm in a hurry: I'd like to send the patches within
 tonight.

 Il 06/05/2012 15:53, Federico Bruni ha scritto:

 Hi,

 I have to remove the .texidoc file of a snippet which has been removed:

 diff --git
 a/Documentation/snippets/piano-template-with-centered-dynamics.ly
 b/Documentation/snippets/piano-template-with-centered-dynamics.ly
 deleted file mode 100644
 index f56fc58..000
 --- a/Documentation/snippets/piano-template-with-centered-dynamics.ly
 +++ /dev/null


 I wonder if I should use 'rm' or 'git rm'.
 I know that the difference is that rm keeps the file in the git index,
 while git rm removes it both from index and working copy.
 I think that I should use git rm, but I prefer asking as I have a poor
 understanding of git.

use git rm, otherwise we are tracking an empty file. We want do not
track it anymore.

 I made a try:

 $ git rm
 Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc
 error:
 'Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc'
 has local modifications
 (use --cached to keep the file, or -f to force removal)

 What's the recommended method?

either use -f or:

  git checkout HEAD
Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc
  git rm Documentation/it/texidocs/piano-template-with-centered-dynamics.texidoc

The first line makes the file to be as it was before you changed it

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: translators: fix your open source mistranslations

2012-05-06 Thread Francisco Vila

2012/5/6 Graham Percival gra...@percival-music.ca:
 On Sun, May 06, 2012 at 07:02:20PM +0200, Jean-Charles Malahieude wrote:

 Just two instances in GSoC node that I'm not sure they should be
 transformed:

 fr (translation)]$ git grep -n 'open source'
 web/community.itexi:930:étudiants pour écrire du code au bénéfice de
 projets @emph{open source}.
 web/community.itexi:931:Google a travaillé de concert avec la
 communauté @emph{open source} afin

 Hmm.  The English version is a direct quote from google's website,
 and of course one should never change direct quotes.  Now if
 you're translating the quote for some reason, then I guess you
 should try to keep as close to the original meaning as possible...
 and in google's case, they definitely mean open source instead
 of free software.

 So I guess those shouldn't be changed, and if that's it in the
 French translation then I guess you're fine.

We have in English

http://lilypond.org/freedom.html
“Gift culture”: the Free Software (or “Open Source”) movement has created...

http://lilypond.org/reviews.html
“Wonderful free (open source) software [..]

I think the first is wrong; the second is an exact quote from something wrong.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: translators: fix your open source mistranslations

On Sun, May 06, 2012 at 09:36:38PM +0200, Francisco Vila wrote:
 2012/5/6 Graham Percival gra...@percival-music.ca:
  So I guess those shouldn't be changed, and if that's it in the
  French translation then I guess you're fine.
 
 We have in English
 
 http://lilypond.org/freedom.html
 “Gift culture”: the Free Software (or “Open Source”) movement has created...

Yes, I've asked Janek to fix that one.

 http://lilypond.org/reviews.html
 “Wonderful free (open source) software [..]
 
 I think the first is wrong; the second is an exact quote from something wrong.

Yes.

ok, I've just looked at the home page in every language, and the
only one that appears to say open source is German.

*shrug*
I guess it was just bad luck that a German GNU person looked at
the website?

- Graham

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

Re: Substitute for s1*0



David Kastrup wrote Sunday, May 06, 2012 4:44 PM

Trevor Daniels t.dani...@treda.co.uk writes:


Actually, I don't think s1*0 appears in the docs.


Documentation/notation/vocal.itely:  s1*0^\markup { \right-align { \tiny 
Flute } }
Documentation/notation/vocal.itely:  s1*0_\markup { \right-align { \tiny 
Clar. } }


Ha!  I think I even wrote these two myself!  :)
Shows how unreliable (my) memory can be :(

I've no objection to the docs being changed to use an empty chord
but its semantics will need to be introduced somewhere.  The best place
is probably the LM, in 2.2.4 Combining notes into chords.

Trevor




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

Re: Substitute for s1*0

On Sun, May 06, 2012 at 10:17:05PM +0100, Trevor Daniels wrote:
 
 I've no objection to the docs being changed to use an empty chord
 but its semantics will need to be introduced somewhere.  The best place
 is probably the LM, in 2.2.4 Combining notes into chords.

I'm still not happy with an empty chord, especially in the
Learning Manual.  I think it leads to the perlization of
lilypond, where we end up looking like a ridiculous language like
Haskell.

I'm ok with using  as a quick hack for things like convert-ly
rules, so I'm not arguing against David's patch.  But I wouldn't
want to see  becoming part of our basic vocabulary.  I still
think that a n or z or \null would be more clear if there's
a solid reason to have such a musical event in a
non-computer-modified score.

- Graham

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

Re: Substitute for s1*0