Make doc - English only?
Is there a way to make doc without transltations? When working on the website I use make WEB_LANGS='' website, but is there an equivalent for the docs? I know I don't need that for development (while working I generate individual sections, and for checking one _does_ need the translations. But it would be nice to have a local doc (like the doc tarball) but English only. Anyway, I just realized that I don't need to download these huge tarballs anymore since I can build the docs myself from Git :-) Urs -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc - English only?
- Original Message - From: Urs Liska u...@openlilylib.org To: LilyPond Development Team lilypond-devel@gnu.org Sent: Saturday, January 04, 2014 8:04 AM Subject: Make doc - English only? Is there a way to make doc without transltations? When working on the website I use make WEB_LANGS='' website, but is there an equivalent for the docs? I know I don't need that for development (while working I generate individual sections, and for checking one _does_ need the translations. But it would be nice to have a local doc (like the doc tarball) but English only. Anyway, I just realized that I don't need to download these huge tarballs anymore since I can build the docs myself from Git :-) Urs -- Urs Liska openlilylib.org http://lilypond.org/doc/v2.17/Documentation/contributor/generating-documentation -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regtest for new glyphs necessary?
Am 03.01.2014 08:03, schrieb Keith OHara: Marc Hohl marc at hohlart.de writes: I am about to upload a patch for these four glyphs within the next days, but I wanted to ask whether a new (or enhanced existing) regtest is necessary for this type of enhancement? They could conceivably be broken accidentally, by a mistaken change to our .mf files or a metafont bug, so a regression test is useful. LilyPond probably has too many tests, but you could add to 'clefs.ly' Ok, thanks for the tip. I rearranged clefs.ly so that both normal-sized and smaller clefs are covered by the regtest, I hope that this is ok. http://codereview.appspot.com/47840043 Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtest enhanced for the new clefs (issue 47840043)
https://codereview.appspot.com/47840043/diff/1/input/regression/clefs.ly File input/regression/clefs.ly (right): https://codereview.appspot.com/47840043/diff/1/input/regression/clefs.ly#newcode1 input/regression/clefs.ly:1: \version 2.19.1 This version will not make Patchy happy. We are at 2.19.0, at least today. https://codereview.appspot.com/47840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtest enhanced for the new clefs (issue 47840043)
Am 04.01.2014 17:59, schrieb d...@gnu.org: https://codereview.appspot.com/47840043/diff/1/input/regression/clefs.ly File input/regression/clefs.ly (right): https://codereview.appspot.com/47840043/diff/1/input/regression/clefs.ly#newcode1 input/regression/clefs.ly:1: \version 2.19.1 This version will not make Patchy happy. We are at 2.19.0, at least today. Sorry, done. BTW, the name of the patchset is chosen from the last local commit message – strange, but changed now ;-) https://codereview.appspot.com/47840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Le 01/01/2014 20:45, James disait : On 01/01/14 17:50, Jean-Charles Malahieude wrote: I compile on native Fedora. I don't know by how would be multiplied a 90 minutes make -j3 make -j3 doc on my dual-core with 2gigs RAM when launched in a VM. Probably not as much as you think. Assuming you have reasonably modern CPUs with VT-x/d enabled. It's very convenient to use a VM than your own base system, but it does take disk space I guess (for the extra OS). You also get trivial abilities to clone/snapshot and/or freeze VMs that I have found helpful in the past. Indeed before Patchy scripts it was how I used to test patches without having to keep rebuilding a baseline image for the reg test comparisons. My box is now 7 years old and doesn't seem to accept VT-x/d. It is not a problem of space but of resources. I work in local clones with git clone -l -s -n --branch translation . ../Traduc However, how often are you building full doc? And why - when we have others who do this. We have scripts don't we that allow you to build *just* sections or *just* languages instead of everything. It's not like it's mandatory for most, if hardly any, developers. […] I consider it mandatory for translators to build from scratch when updating multiple files, before pushing on the translation branch. Here is my work-flow: 1- update the text and add new texidocs when needed, 2- make -j3 doc LANGS=fr (less than 10 min.) 3- check the logs and proofread in a browser (more fluent reading than source file) 4- commit and push Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Giving Thanks (and Preachin' the Gospel)
Hi all, Trying this again without the images… =( Kieren. On Jan 4, 2014, at 1:34 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hello all, Just wanted to let you know two things. 1. I was a guest lecturer at the Michigan State University School of Music last month. Although most of my [short and varied] presentation to the composition department was ostensibly about my music and career, I gave a BIG plug to our favourite engraving app. Everything I said just got them more and more excited about Lilypond — you should have seen their minds being blown when I told them about polymetrics and the recent “Ferneyhough-style interrupted polyphony”. And of course, when I showed them the untweaked (but styled) output of my full orchestra score(s), they were appropriately stunned: Screen Shot 2014-01-04 at 1.32.42 PM.png This was the top of the [lovely] first page of my big arrangement of “The 12 Days of Christmas”… 2. The promotional CD for “Robin Hood: The Legendary Musical Comedy” (from last year’s Hart House Theatre production) is almost ready. I thought you’d get a kick out of this corner of the liner notes: Screen Shot 2014-01-04 at 1.24.30 PM.png This said “Thank Yous” and the list included “Lilypond Developers Community”… I really do appreciate everything that the heavy lifters do (you know who you are) — I continue to be in awe of how good you make me look, at least on score paper. =) With gratitude, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
DOC: CG: Add information on texlive-lang-cyrillic (Issue 3774) (issue 47870045)
Reviewers: , Message: Please review this patch. Thanks, Carl Description: DOC: CG: Add information on texlive-lang-cyrillic (Issue 3774) Add commands necessary to add the required texlive-lang-cyrillic to LilyDev 2.6 Please review this at https://codereview.appspot.com/47870045/ Affected files (+10, -0 lines): M Documentation/contributor/quick-start.itexi Index: Documentation/contributor/quick-start.itexi diff --git a/Documentation/contributor/quick-start.itexi b/Documentation/contributor/quick-start.itexi index 22ea0591b10c33022aea51adb0d93b9d956f9cd8..9dcf55baf234e985696a61c045d064a67cfa4bb4 100644 --- a/Documentation/contributor/quick-start.itexi +++ b/Documentation/contributor/quick-start.itexi @@ -161,6 +161,16 @@ reboot the virtual machine. It will not try to restart the installer but start the virtual machine proper. LilyDev is now installed and running! +@item +The current version of LilyPond requires the texlive-lang-cyrillic +package. This package is not part of LilyDev 2.6. Add the package +to LilyDev with: + +@example +sudo apt-get install texlive-lang-cyrillic +@end example + + @end enumerate @knownissues ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
DOC: CG: Add mirror for LilyDev (Issue 3775) (issue 47890043)
Reviewers: ,
Message:
Please review.
Description:
DOC: CG: Add mirror for LilyDev (Issue 3775)
Add url to CG for a mirror for LilyDev.
Please review this at https://codereview.appspot.com/47890043/
Affected files (+6, -0 lines):
M Documentation/contributor/quick-start.itexi
Index: Documentation/contributor/quick-start.itexi
diff --git a/Documentation/contributor/quick-start.itexi
b/Documentation/contributor/quick-start.itexi
index
22ea0591b10c33022aea51adb0d93b9d956f9cd8..cad9826ccaf04b189223e1ca95dac4fccf87796b
100644
--- a/Documentation/contributor/quick-start.itexi
+++ b/Documentation/contributor/quick-start.itexi
@@ -68,6 +68,12 @@ Some advanced users might want this file too:
@end smallexample
(If you don't recognize what this file is, then you don't need it.)
+An alternate site for obtaining these files is available:
+@smallexample
+@uref{http://www.et.byu.edu/~sorensen/ubuntu-LilyDev-remix-2.6.iso}
+@uref{http://www.et.byu.edu/~sorensen/ubuntu-LilyDev-remix-2.6.iso.md5}
+@end smallexample
+
@node Installing LilyDev in VirtualBox
@unnumberedsubsec Installing LilyDev in VirtualBox
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LILY-GIT PITA
On 1/2/14 9:41 AM, Carl Peterson carlopeter...@gmail.com wrote: Just now seeing this (I don't think I was subscribed when Carl S. wrote this). After my recent experience with lily-git.tcl and submitting a patch, one thing I would request is that, if possible, some kind of automatic line wrapping be built into its processing of the commit message (i.e., if a line exceeds n characters, go back to the last space prior to the nth character and replace with a line break). This will avoid the issue of poorly wrapped lines, which both David K and Janek have messaged me about. I don't recall that particular point being discussed in the CG. I think that instead of doing the automatic line break, we should just document it properly in the CG. I don't know how I'd implement an automatic word wrap, and I don't think it's worth spending the time on figuring out how to do it. But if you'd like to do it, I'd certainly be happy to review a proposed patch. Thanks, Carl S. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly
File ly/satb.ly (right):
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode1
ly/satb.ly:1:
Missing \version number is causing an error when running convert-ly.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode68
ly/satb.ly:68: (if (defined? name) name (if (pair? default) (car
default) '#{#})))
'#{#} is expensive. I'd rather use *unspecified* here.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode70
ly/satb.ly:70: #(define (sym . strings) (string-symbol (apply
string-append strings)))
For an include file (rather than a module), this and some other macro
names seem awfully likely to cause collisions.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode84
ly/satb.ly:84: (let ((above (if (pair? optionals) (car optionals) #f)))
(if x y #f) is easier to understand and write as (and x y), in
particular if x takes up considerable space.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode93
ly/satb.ly:93: #{#})))
Why #{#} unquoted? That evaluates at macro placement time. But I'd use
*unspecified* anyway.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode97
ly/satb.ly:97: \new Staff = #(identity ,name) \with {
Why #(identity ,name) here instead of #,name ?
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode104
ly/satb.ly:104: \clef #(identity ,clef)
What's with the identity? It does not make sense.
I'll skip the copious other occurences but they should be fixed.
https://codereview.appspot.com/41990043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add Changes entries for bare rhythms and \beamExceptions (issue 47850043)
Hi David Suggestion for wording the bare durations change. I like the way this lets you code tied notes with varying durations, too! Cheers and Happy New Year, Ian https://codereview.appspot.com/47850043/diff/40001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/47850043/diff/40001/Documentation/changes.tely#newcode69 Documentation/changes.tely:69: You can now code free-standing duration items in a music sequence to specify a sequence of several notes at the same pitch with varying rhythms. Any such free-standing durations take their pitch from the previous note or chord specified with a pitch value. This may be useful for writing rhythms to percussion parts to make the input more readable, or for specifying rhythms for music or scheme functions. Here are two examples showing how this feature makes for much more readable input: https://codereview.appspot.com/47850043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: License of files in Documentation/pictures and ability to distribute them unclear
On Fri, Jan 03, 2014 at 03:28:22PM -0800, Don Armstrong wrote: There are a lot of files in Documentation/pictures which have no clear license, and unfortunately, the git log for them isn't clear at all either. Indeed; those should be clarified. Some of them cannot be distributed by lilypond either, for example, logo-debian.png is the Debian Restricted Use Logo.[1] Oops. Yes, we should replace it with the open use logo. http://www.debian.org/logos/index.en.html It's great that a lot of them have the source which they were built from present, but there are some which are still missing the source. [For example, logo-debian.png can (and probably should) be built directly from the SVG[2] at the appropriate size (or just the SVG used).] Due to our website hosting situation, it would be awkward to build it directly. As for SVG, I'm not familiar with browser and texinfo support. We still have something like 50% users on windows; can IE display SVGs yet? Also, can texinfo 4.13a handle SVGs? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Double G clef, tenor G clef, varpercussion clef and varC clef (issue 47840043)
https://codereview.appspot.com/47840043/diff/20001/mf/feta-clefs.mf File mf/feta-clefs.mf (right): https://codereview.appspot.com/47840043/diff/20001/mf/feta-clefs.mf#newcode186 mf/feta-clefs.mf:186: reduced_ss# = staff_space# * reduction; Uh, oh, the diff here on Rietveld is so big and unreadable because you've converted tabs to spaces, probably inadvertently. Please post another revision of your patch that fixes this, and ensure that your editor doesn't do this conversion automatically again. https://codereview.appspot.com/47840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: License of files in Documentation/pictures and ability to distribute them unclear
On Sat, Jan 4, 2014 at 10:51 PM, Graham Percival gra...@percival-music.ca wrote: On Fri, Jan 03, 2014 at 03:28:22PM -0800, Don Armstrong wrote: It's great that a lot of them have the source which they were built from present, but there are some which are still missing the source. [For example, logo-debian.png can (and probably should) be built directly from the SVG[2] at the appropriate size (or just the SVG used).] Due to our website hosting situation, it would be awkward to build it directly. As for SVG, I'm not familiar with browser and texinfo support. We still have something like 50% users on windows; can IE display SVGs yet? Also, can texinfo 4.13a handle SVGs? SVG support in browsers is still incomplete, last I checked. IE9 has partial support, according to Wikipedia's article on SVG. Regardless, it's not ideal. Nor is live building practical, for the reason Graham mentioned (it would require running a server-side script with every image request to see if the image is available, build the image if necessary, then serve the image). However, an alternative would be to somehow build the SVG to PNG at the expected size(s) as part of make. Not sure what that would take, though, or if it would add yet another dependency to the list. Carl P. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
I'm not a lawyer, but the year in a copyright notice is supposed to be the year of original publication. If you have a document first published in 2012 with a Copyright 2012 notice and you change the year to 2014 without making any other changes, the original publication year is still 2012 but now the copyright notice is incorrect, which makes it legally equivalent to no notice at all (although copyright notices have little legal meaning anyway in Berne Convention countries). See here, for example: http://www.quizlaw.com/copyrights/what_happens_if_there_is_an_er.php It makes sense to bump the user-visible copyright notices of lilypond, convert-ly, and the like to whatever year those tools were last substantively changed, and to update the notices in individual files to reflect when they were last changed, but a global search-and-replace is probably a bad idea. -- Ben On Sat, Jan 4, 2014 at 3:50 PM, Carl Sorensen carl.d.soren...@gmail.comwrote: In response to issue 3765, I ran make grand-replace to update all copyright notices to 2014. It looks like I no longer have push privileges, so I couldn't push the patch to staging. Anyway, here's the patch, if somebody would please push it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
I'm not a lawyer, but the year in a copyright notice is supposed to be the year of original publication. If you have a document first published in 2012 with a Copyright 2012 notice and you change the year to 2014 without making any other changes, [...] Looks like a mistake in the conversion script. `2012' should be changed to `2012-2014', of course. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
On Sun, Jan 05, 2014 at 08:09:45AM +0100, Werner LEMBERG wrote: I'm not a lawyer, but the year in a copyright notice is supposed to be the year of original publication. If you have a document first published in 2012 with a Copyright 2012 notice and you change the year to 2014 without making any other changes, [...] Looks like a mistake in the conversion script. `2012' should be changed to `2012-2014', of course. GNU maintainer's guide discourages that: http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices However, it's also true that the guide says that copyright numbers should only be updated if there's a nontrivial change to the file. That's different from past lilypond policy. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
Looks like a mistake in the conversion script. `2012' should be changed to `2012-2014', of course. GNU maintainer's guide discourages that: http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices What exactly does it discourage? However, it's also true that the guide says that copyright numbers should only be updated if there's a nontrivial change to the file. You've misread, I think: The guide doesn't say `file' but `package'. In general, this means that the copyright of *all* files of the LilyPond package[*] should be updated. Werner [*] However, not all files distributed with lilypond are also part of the package, cf. `texinfo.tex' or `mf2pt1.mp'. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
On Sun, Jan 05, 2014 at 08:42:59AM +0100, Werner LEMBERG wrote: Looks like a mistake in the conversion script. `2012' should be changed to `2012-2014', of course. GNU maintainer's guide discourages that: http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices What exactly does it discourage? Perhaps discourage is too strong a term: You can use a range (‘2008-2010’) instead of listing individual years (‘2008, 2009, 2010’) if and only if: 1) every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and 2) you make an explicit statement in a README file about this usage. However, it's also true that the guide says that copyright numbers should only be updated if there's a nontrivial change to the file. You've misread, I think: The guide doesn't say `file' but `package'. In general, this means that the copyright of *all* files of the LilyPond package[*] should be updated. I don't get the same impression from that page. It begins by saying You should maintain a proper copyright notice and a license notice in each nontrivial file in the package. [*] However, not all files distributed with lilypond are also part of the package, cf. `texinfo.tex' or `mf2pt1.mp'. Indeed. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
