New Czech PO file for 'lilypond' (version 2.15.9)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Czech team of translators. The file is available at: http://translationproject.org/latest/lilypond/cs.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)
LGTM. Good work! The only think I'd ask is that you change the markup syntax before pushing the patch. I think that, if the distinction between footnote and auto-footnote is going to be eliminated, it needs to be categorical. http://codereview.appspot.com/5527058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)
http://codereview.appspot.com/5527058/diff/1/python/convertrules.py File python/convertrules.py (right): http://codereview.appspot.com/5527058/diff/1/python/convertrules.py#newcode3362 python/convertrules.py:3362: From an orthogonal point of view, those variables should be either named `matchstring' and `matcharg' or `matchastring' and `matchanarg'... It's not really important, but I prefer the former. http://codereview.appspot.com/5527058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)
Thanks, David! http://codereview.appspot.com/5527058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part (issue 5530043)
On Tue, Jan 10, 2012 at 12:15:43AM -0500, Pavel Roskin wrote: > Quoting Graham Percival : > > >Great point! Could you add a comment to this effect to the top of > >this file? there's no way that I'll remember otherwise. > > I believe the comment belongs to some other file that describes the > release process. We won't look at it. Trust me, we're just not that organized. A comment at the top of the search.ithml file is much less likely to be ignored. > >We want to keep all stable docs available for historical reasons, > >but I'm not opposed to directing people to > > /doc/stable/ > > /doc/development/ > >rather than vX.Y. If you feel like looking into this, the > >htaccess is in Documentation/web/server/ > > When searching for Lilypond related topics on Google, I constantly > get directed to v2.12 unless I add "v2.15" to the search line. But > I often want to find information both on the Lilypond site and > elsewhere, so adding "v2.15" would lose the external links. > > I'm not against hosting historic documentation, but it would be nice > to "deemphasize" is somehow. Yes, and using the /doc/stable/ vs. /doc/devel/ links would surely de-emphasize it. We could even tell google to ignore the old doc pages, although I'm not certain we want it removed from the cache entirely... but given their pagerank algorithm, if we didn't have so many links to the explicit /doc/vX.Y/ pages, those pages would be de-emphasized already. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part (issue 5530043)
Quoting Graham Percival : On Mon, Jan 09, 2012 at 02:10:24PM +, plros...@gmail.com wrote: I totally share your sentiment, but we depend on an external entity here, which we cannot control. Suppose we go from 2.15.x to 2.17.x and put the documentation under "v2.17". For some time, Google won't have the new location in its index, so the search would get nothing. It would be better to keep "v2.15" in the search for a while and have a redirection from "v2.15" to "v2.17". Great point! Could you add a comment to this effect to the top of this file? there's no way that I'll remember otherwise. I believe the comment belongs to some other file that describes the release process. If we keep things as is, the version change in the search would need to be done some time after the release. I don't know how fast Google would index the new pages. In the ideal case (which means changing the site layout), everything should be done at the time of the release and no "alarms" should be needed for additional changes. Speaking of redirections, I would prefer that Lilypond had just two versions of its documentation online - latest "stable" and latest "development". "v2.12" and "v2.14" shoould redirect to "stable", "v2.15" should redirect to "development". We want to keep all stable docs available for historical reasons, but I'm not opposed to directing people to /doc/stable/ /doc/development/ rather than vX.Y. If you feel like looking into this, the htaccess is in Documentation/web/server/ When searching for Lilypond related topics on Google, I constantly get directed to v2.12 unless I add "v2.15" to the search line. But I often want to find information both on the Lilypond site and elsewhere, so adding "v2.15" would lose the external links. I'm not against hosting historic documentation, but it would be nice to "deemphasize" is somehow. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part (issue 5530043)
On Mon, Jan 09, 2012 at 02:10:24PM +, plros...@gmail.com wrote: > I totally share your sentiment, but we depend on an external entity > here, which we cannot control. Suppose we go from 2.15.x to 2.17.x and > put the documentation under "v2.17". For some time, Google won't have > the new location in its index, so the search would get nothing. It > would be better to keep "v2.15" in the search for a while and have a > redirection from "v2.15" to "v2.17". Great point! Could you add a comment to this effect to the top of this file? there's no way that I'll remember otherwise. > Speaking of redirections, I would > prefer that Lilypond had just two versions of its documentation online - > latest "stable" and latest "development". "v2.12" and "v2.14" shoould > redirect to "stable", "v2.15" should redirect to "development". We want to keep all stable docs available for historical reasons, but I'm not opposed to directing people to /doc/stable/ /doc/development/ rather than vX.Y. If you feel like looking into this, the htaccess is in Documentation/web/server/ - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets rid of PostScript inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048)
On Mon, Jan 09, 2012 at 02:24:45PM -, Phil Holmes wrote: > It > actually looks like the only substantive change if with the > Documentation/snippets/bar-chords-notation-for-guitar--with-text-spanner.ly > which is duplicated in snippets/new. Mike - you only need to edit > the one in snippets/new - the other should be updated in the LSR, > and it will appear in snippets/ when an LSR import is run. Correct in general, but the overall goal is to let Mike build the docs again. As such, I think it's appropriate to dump the change in snippets/new/ and run makelsr himself. If this was just a doc clarification, then I'd suggest it be done the other way. > If this sounds right - I can do the edit and will do the import at > some time. There's also 3 other files with essentially null changes > to them - might be a cleaner patch if you get rid of these. Yes... the git history would be slightly more clear if he did a local makelsr, then changed the one file in snippets/new/, then did another local makelsr. But in this case I didn't think it was worth asking for that level of bureaucracy. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Hairpin #'minimum-length does not apply to real length of the hairpin
On Sun, Jan 8, 2012 at 3:39 PM, Xavier Scheuer wrote:
> Hi,
>
> I noticed this while replying to James.
>
> \override Hairpin #'minimum-length = #8 does not take into account the
> fact that a hairpin can be shortened by the presence of a DynamicText.
>
> "minimum-length" is applied not the real length of the hairpin, but to
> the length of the hairpin **if it would not have been shortened by the
> presence of a dynamic**. IMHO it should apply to the _real length_ of
> the hairpin (the printed one!), even if it is a "shortened hairpin"
> (hey, it is usually these "shortened hairpins" that we —the users— want
> to lengthen when we \override Hairpin #'minimum-length !!).
>
> It is not easy to explain this, I hope the following code will help you
> to understand better what I mean.
>
> Snippet
>
> \version "2.15.24"
>
> \relative c' {
> c1\< |
> c\mf |
> \override Hairpin #'minimum-length = #8
> c\> |
> % this "shortened" (due to the presence of the DynamicText) hairpin
> % does not have a _real_ minimum-length of #8 !
> c1\ppp\<^"too short!" |
> \override Hairpin #'minimum-length = #12
> c\fff\> |
> c\> |
> \revert Hairpin #'minimum-length
> c\mf\> |
> c\p
> }
>
> End of snippet
>
> Cheers,
> Xavier
>
> --
> Xavier Scheuer
Greetings Xavier and list members -
This has been submitted as issue 2207 :
http://code.google.com/p/lilypond/issues/detail?id=2207
I designated it "ugly", but I'm not sure that's the best category.
Ralph
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)
On 9 January 2012 20:49, wrote: > Looks *very* good to me! > > I really like having only one \footnote command; it's intuitive for > users. Thanks for doing this! On the shoulders of Giants eh David ;) I can help with the doc if you like, perhaps download the diff file from the tracker, apply it and give it back for you to apply on your patch? -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)
Looks *very* good to me! I really like having only one \footnote command; it's intuitive for users. Thanks for doing this! http://codereview.appspot.com/5527058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)
Does this do anything to the \auto-footnote command as well? http://codereview.appspot.com/5527058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suggestion - increase default beam thickness
Personally I find the thicker beams look much better. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suggestion - increase default beam thickness
On Sat, 7 Jan 2012 01:54:06 +0100 Janek Warchoł wrote: > W dniu 7 stycznia 2012 01:40 użytkownik Carl Sorensen > napisał: ... > > Are you measuring staff space in pixels from the top of one staff > > line to the top of the next staff line? > > Yes, exactly like that. I was often measuring one sample in several > places (and estimating an average) because the shapes are not perfect. Comparing scanned data to internal numbers is not a fair comparison. When scanning, the lines can get blurred and then they are converted to black-and-white based on the darkness settings. Lines can get thicker or thinner. The most fair comparison would be between the original score on paper and the score produced by Lilypond, also printed on paper. You may need a microscope to measure the widths. As an alternative to the microscope, you can compare scanned scores, but only if both scores were scanned by the same scanner with the same settings. Also, the scans should be grayscale or better, not black-and-white, so that you can measure the human-perceived width rather than a computer-calculated boundary that can be affected by the color of the paper and the ink. This way, you would be using the same method to measure the original and the new data. Lilypond should imitate printed scores, not scanned scores. -- Regards, Pavel Roskin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
- Original Message - From: "Graham Percival" To: Cc: Sent: Monday, January 09, 2012 8:22 AM Subject: Re: Patchy email On Sun, Jan 08, 2012 at 10:37:51PM -0800, lilypond.patchy.gra...@gmail.com wrote: *** FAILED BUILD *** nice make doc -j3 CPU_COUNT=3 Previous good commit: 820c7ff5d380e8ca52057717ab3176b5e40107fd Current broken commit: 42984d05239a3c3be1ea859ba5214ce140448afc The error message from this is the same as we had on jan 7: --- Error ignored by lilylib lilypond-book.py (GNU LilyPond) 2.15.25 Error trapped by lilypond-book Please see /main/large-tmp/lilypond-autobuild/build/out/lybook-db/snippet-names-1740910883.log --- when that file only contains: --- GNU LilyPond 2.15.25 Forking into jobs: (18440 18439 18438) job 2 terminated with signal: 11 fatal error: Children (2) exited with errors. - Further info on this. You should be able to find the logfile lilypond-multi-run-2.log (the 2 is the job number/child number as above). If it's still there and not been nuked by a subsequent build, see what that says. As a general rule, if you get a logfile with "Forking into jobs" you'll also get these multi-run logs, with the job/child number indicating the logfile to examine next. That said, when I deliberately cause a multi-cpu job to fail, I get this more helpful logfile: GNU LilyPond 2.15.25 Forking into jobs: (6264 6263 6262 6261 6260 6259 6258 6257 6256) logfile lilypond-multi-run-7.log (exit 1): pets/2d/lily-4a739af2-31.pdf'... Converting to `/home/phil/TestFolder/MultiSnippets/2d/lily-4a739af2-32.pdf'... Writing /home/phil/TestFolder/MultiSnippets/2d/lily-4a739af2-systems.texi... Writing /home/phil/TestFolder/MultiSnippets/2d/lily-4a739af2-systems.tex... Writing /home/phil/TestFolder/MultiSnippets/2d/lily-4a739af2-systems.count... fatal error: failed files: "93/lily-d1ddc9d7.ly" fatal error: Children (7) exited with errors. I'm beginning to suspect that we have a random build failure, rather than an actual problem in staging right now (or even on Jan 7). This is the only case where I haven't seen any info in the logs. I've had a quick look on the web for signal:11 and most answers seem to indicate a segmentation fault. The lack of the further diagnostic info in the logfile might point to this as well. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets rid of PostScriptinbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048)
- Original Message - From: To: Sent: Monday, January 09, 2012 4:32 PM Subject: Re: Gets rid of PostScriptinbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048) On Mon, 9 Jan 2012 14:24:45 -, Phil Holmes wrote: - Original Message - From: To: Cc: ; Sent: Monday, January 09, 2012 5:14 AM Subject: Re: Gets rid of PostScript inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048) LGTM I'm vaguely curious as to what's the difference between this postscript and the regtest for postscript, but that's no reason to hold up development. Besides, the lilypond markup is easier to understand than the postscript, so this is a good change to make even if it wasn't a build problem. http://codereview.appspot.com/5529048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Whoah. This is changes to snippets in the snippet directory. It actually looks like the only substantive change if with the Documentation/snippets/bar-chords-notation-for-guitar--with-text-spanner.ly which is duplicated in snippets/new. Mike - you only need to edit the one in snippets/new - the other should be updated in the LSR, and it will appear in snippets/ when an LSR import is run. However, the snippets/new one takes priority so it shouldn't make ant difference when this is done. Hey Phil, I only changed the one in snippets new and then ran scripts/auxiliar/makelsr.py (this is the procedure specified in the CG). Cheers, MS OK. Sounds good, thanks. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets rid of PostScript inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048)
On Mon, 9 Jan 2012 14:24:45 -, Phil Holmes wrote: - Original Message - From: To: Cc: ; Sent: Monday, January 09, 2012 5:14 AM Subject: Re: Gets rid of PostScript inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048) LGTM I'm vaguely curious as to what's the difference between this postscript and the regtest for postscript, but that's no reason to hold up development. Besides, the lilypond markup is easier to understand than the postscript, so this is a good change to make even if it wasn't a build problem. http://codereview.appspot.com/5529048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Whoah. This is changes to snippets in the snippet directory. It actually looks like the only substantive change if with the Documentation/snippets/bar-chords-notation-for-guitar--with-text-spanner.ly which is duplicated in snippets/new. Mike - you only need to edit the one in snippets/new - the other should be updated in the LSR, and it will appear in snippets/ when an LSR import is run. However, the snippets/new one takes priority so it shouldn't make ant difference when this is done. Hey Phil, I only changed the one in snippets new and then ran scripts/auxiliar/makelsr.py (this is the procedure specified in the CG). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part(issue 5530043)
- Original Message - From: To: ; Cc: ; Sent: Monday, January 09, 2012 2:10 PM Subject: Re: Doc search: update to version 2.15, use it in the "site:" part(issue 5530043) I totally share your sentiment, but we depend on an external entity here, which we cannot control. Suppose we go from 2.15.x to 2.17.x and put the documentation under "v2.17". For some time, Google won't have the new location in its index, so the search would get nothing. It would be better to keep "v2.15" in the search for a while and have a redirection from "v2.15" to "v2.17". Speaking of redirections, I would prefer that Lilypond had just two versions of its documentation online - latest "stable" and latest "development". "v2.12" and "v2.14" shoould redirect to "stable", "v2.15" should redirect to "development". That would solve the issue with hardcoded version numbers and keep Google happy. +1 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Usage - added link for Windows users (issue 5521056)
- Original Message - From: To: Cc: ; Sent: Monday, January 09, 2012 9:04 AM Subject: Re: Doc: Usage - added link for Windows users (issue 5521056) On 2012/01/09 08:46:36, Graham Percival wrote: LGTM, but are you sure that the info on the Windows download page is good for lilypond-book, as well as for lilypond itself? on my own windows machine: --snip-- C:\Program Files\LilyPond\usr\bin>lilypond-book.py --version 2.14.2 C:\Program Files\LilyPond\usr\bin>lilypond --version GNU LilyPond 2.14.2 Copyright (c) 1996--2011 by Han-Wen Nienhuys Jan Nieuwenhuizen and others. This program is free software. It is covered by the GNU General Public License and you are welcome to change it and/or distribute copies of it under certain conditions. Invoke as `lilypond --warranty' for more information. C:\Program Files\LilyPond\usr\bin> --snip- The instructions on the current webpage say --anip-- ... the name of the folder which contains LilyPond executable files like this: [pre-set paths];DIR\LilyPond\usr\bin Note: DIR will generally be C:\Program Files. and click “OK” button to close the window. --snip-- James is correct in the assertion that you only need DIR\LilyDir\usr\bin to run lily and -book. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
- Original Message - From: "Graham Percival" To: Cc: Sent: Monday, January 09, 2012 8:22 AM Subject: Re: Patchy email On Sun, Jan 08, 2012 at 10:37:51PM -0800, lilypond.patchy.gra...@gmail.com wrote: *** FAILED BUILD *** nice make doc -j3 CPU_COUNT=3 Previous good commit: 820c7ff5d380e8ca52057717ab3176b5e40107fd Current broken commit: 42984d05239a3c3be1ea859ba5214ce140448afc The error message from this is the same as we had on jan 7: --- Error ignored by lilylib lilypond-book.py (GNU LilyPond) 2.15.25 Error trapped by lilypond-book Please see /main/large-tmp/lilypond-autobuild/build/out/lybook-db/snippet-names-1740910883.log --- when that file only contains: --- GNU LilyPond 2.15.25 Forking into jobs: (18440 18439 18438) job 2 terminated with signal: 11 fatal error: Children (2) exited with errors. - I'm beginning to suspect that we have a random build failure, rather than an actual problem in staging right now (or even on Jan 7). This is the only case where I haven't seen any info in the logs. - Graham You get that forking (I believe) because of the CPU_COUNT setting. If it's a reproducible error, it might be easier to find if you lose that setting temporarily. Please feel free to raise an issue saying the log file is not helpful in this case. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets rid of PostScript inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048)
- Original Message - From: To: Cc: ; Sent: Monday, January 09, 2012 5:14 AM Subject: Re: Gets rid of PostScript inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048) LGTM I'm vaguely curious as to what's the difference between this postscript and the regtest for postscript, but that's no reason to hold up development. Besides, the lilypond markup is easier to understand than the postscript, so this is a good change to make even if it wasn't a build problem. http://codereview.appspot.com/5529048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Whoah. This is changes to snippets in the snippet directory. It actually looks like the only substantive change if with the Documentation/snippets/bar-chords-notation-for-guitar--with-text-spanner.ly which is duplicated in snippets/new. Mike - you only need to edit the one in snippets/new - the other should be updated in the LSR, and it will appear in snippets/ when an LSR import is run. However, the snippets/new one takes priority so it shouldn't make ant difference when this is done. If this sounds right - I can do the edit and will do the import at some time. There's also 3 other files with essentially null changes to them - might be a cleaner patch if you get rid of these. I think only Graham can comment on this - could you confirm, please, GP? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
Janek Warchoł writes: > According to our motto the aim of LilyPond is "music engraving to > everyone" - i'd say it's a very good goal. It would mean that a > person with average computer skills (like navigating a web browser and > using word processor) should be able to create very good engravings of > not-so-complicated music (e.g. Mozart's "Ave Verum"). I think we're > quite far from this goal; conductor of our choir didn't manage to > switch to LilyPond. So he did not manage to spell music in LilyPond in a few days. I am sure he tried to spell words in English for longer than that before he gave up. "Navigating a web browser" are not "average computer skills". Those are not computer skills at all. You need more computer skills to program a video recorder. LilyPond is a batch processing system. It is not an interactive program. You need to spell out the tasks. People for which working with a command line is an unsurmountable challenge won't work with LilyPond. They might get along with some GUI thingy that drives LilyPond as its backend. The one thing where LilyPond needs to refocus is getting away more from the "fiddle around" stuff where you poke a program with a stick for getting results rather than specifying your task. But specifying your task in a computer-comprehensible way is not avoidable. In the areas of TeX/LaTeX and Emacs programming, I have hit a few surprise candidates without programming background who put together a significant body of macros and functions for their own work. Pretty much always it turned out that they were specialists in Oriental or antique languages. LilyPond is similar. We can hope to get into a direction where it requires less fiddling and programming skills, but writing things directly in a computer language will always require logic, language and thinking skills. FORTRAN is a computer language in which good mathematicians can write efficient numerical algorithms without tremendous programming skills. As a result, there is a large corpus of numeric programming libraries in FORTRAN. It's not all that nice of a programming language, but it does not add much of a distraction for a mathematician writing down numeric code and/or using that of others. If LilyPond manages a state where it does not get in the way of composers writing down music, that is about the best one can hope to achieve. The tools and workflow can be made smoother, but that's it. Don't _ever_ try to sell LilyPond to somebody who is not warm enough with a computer to have a preferred editor. In that case, you should rather sell something like Frescobaldi. Something which the user can actually touch and see. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part (issue 5530043)
I totally share your sentiment, but we depend on an external entity here, which we cannot control. Suppose we go from 2.15.x to 2.17.x and put the documentation under "v2.17". For some time, Google won't have the new location in its index, so the search would get nothing. It would be better to keep "v2.15" in the search for a while and have a redirection from "v2.15" to "v2.17". Speaking of redirections, I would prefer that Lilypond had just two versions of its documentation online - latest "stable" and latest "development". "v2.12" and "v2.14" shoould redirect to "stable", "v2.15" should redirect to "development". That would solve the issue with hardcoded version numbers and keep Google happy. http://codereview.appspot.com/5530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Section on Upbeats made clearer (issue 5520056)
Note that this is misleading:
\relative c' {
\partial 4
c4
\applyContext #(lambda (ctx)
(newline)
(display (ly:context-current-moment ctx)))
c1
}
-> #
The Rational class doesn't display negative rationals unless they're
infinite.
http://codereview.appspot.com/5520056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Section on Upbeats made clearer (issue 5520056)
On 2012/01/09 12:58:58, Neil Puttock wrote:
http://codereview.appspot.com/5520056/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
http://codereview.appspot.com/5520056/diff/1/Documentation/notation/rhythms.itely#newcode1366
Documentation/notation/rhythms.itely:1366: The @code{\partial
@var{duration}}
can also be written as;
On 2012/01/09 05:08:58, Graham Percival wrote:
> if this was true, then surely there would be no difference between
\partial
and
> \set blah after the piece had begun. However, the @knownissues
claims that
you
> should only use \partial in the beginning.
It's almost the same. The main difference is that \partial uses an
iterator to
set measurePosition. It ensures grace notes don't mess up the timing
(which can
affect beaming) and allows \displayMusic to pick up the correct
duration.
I mean \displayLilyMusic of course.
http://codereview.appspot.com/5520056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Section on Upbeats made clearer (issue 5520056)
http://codereview.appspot.com/5520056/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
http://codereview.appspot.com/5520056/diff/1/Documentation/notation/rhythms.itely#newcode1366
Documentation/notation/rhythms.itely:1366: The @code{\partial
@var{duration}} can also be written as;
On 2012/01/09 05:08:58, Graham Percival wrote:
if this was true, then surely there would be no difference between
\partial and
\set blah after the piece had begun. However, the @knownissues
claims that you
should only use \partial in the beginning.
It's almost the same. The main difference is that \partial uses an
iterator to set measurePosition. It ensures grace notes don't mess up
the timing (which can affect beaming) and allows \displayMusic to pick
up the correct duration.
http://codereview.appspot.com/5520056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to check clef type?
2012/1/8 Janek Warchoł : > ok, i think i understand what you said (that's a success :) ), but i > don't know what should i use instead of glyph-name callback - a hint > please? Write an offset callback instead? It should be safe to access glyph-name at that point. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: "include" music-function
Hello again, Am 07.01.2012 09:42, schrieb David Kastrup: Actually, this is quite too complicated... (ly:parser-include-string parser (format #f "\\include ~S" file)) should likely be all that is needed here. Sorry for thinking too complicated. so its just: --snip-- #(define-public includeLocal (define-music-function (parser location file)(string?) (let ((outname (format "~A.ly" (ly:parser-output-name parser))) (locname (car (ly:input-file-line-char-column location ; condition when to include (if (or (string=? outname locname) (string-suffix? outname locname)) (ly:parser-include-string parser (format "\\include \"~A\"\n" file))) (make-music 'SequentialMusic 'void #t --snip-- So another solution to issue 1096, Carl mentioned, could be: --snip-- #(define-public includeIf (define-music-function (parser location pred file)(procedure? string?) (if (pred parser location) (ly:parser-include-string parser (format "\\include \"~A\"\n" file))) (make-music 'SequentialMusic 'void #t))) \includeIf #(lambda (parser location) (not (defined? 'defs))) "defs.ly" --snip-- where in "defs.ly" somewhere defs is defined. Or the given lambda looks into a singleton containing all filenames already included or ... Of course one could use just --snip-- #(define-public includeIfNotDef (define-music-function (parser location sym file)(symbol? string?) (if (not (defined? sym)) (ly:parser-include-string parser (format "\\include \"~A\"\n" file))) (make-music 'SequentialMusic 'void #t))) \includeIfNotDef #'defs "defs.ly" --snip-- Conclusion: To write a different include music-function, use (ly:parser-include-string parser (format "\\include \"~A\"\n" file)) so that this can be done in global context. The other function I implemented is also only changing the parser-include-string and removes ly:gulp-file. This is working for me and I am sharing it here, but I don't want to bother anyone to look thru this code. The only thing I'd like to know is: In %load-path the scheme search-path is stored ... where is the lilypond-search-path stored? I propably just didn't saw in the docs? To explain the other include function a little bit (see below): The directory containing the file named in location is reference point for the directory search. Because ly:find-file doesn't find directories, I cannot refer to that. (It would be nice, but I'd call it a special thing and not an issue ;) ). One could use a reference file and include all siblings matching the pattern or ... or ... This fits for me: If I have a collection of files to include "part-.ly" in a directory called "parts" I can place a file "parts.ly" in the upper directory containing --snip-- \includePattern "parts" "part-[0-9][0-9].ly" --snip-- Parameters: 1 - string? directory to search 2 - string? regular expression to match filenames The include order is not predictable, so the include files should contain variable definitions and not typeset by themself. Of course one could first collect all filenames in a list, sort it and then do the inclusion with for-each over that list. But there might be many other ideas, how to search and include part-files. Cheers, Jan-Peter --snip-- #(use-modules (ice-9 regex)) #(define-public includePattern (define-music-function (parser location idir pattern)(string? string?) (let* ((normalize-list (lambda (path) (let ((ret '())) (for-each (lambda (e) (set! ret (cond ((equal? e "..")(if (> (length ret) 1) (cdr ret) '())) ((equal? e ".") ret) (else `(,e ,@ret) path) (reverse ret (normalize-path (lambda (s) (string-join (normalize-list (string-split s #\/)) "/" 'infix))) (extract-path (lambda (location) (let* ((loc (car (ly:input-file-line-char-column location))) (dirmatch (string-match "(.*/).*" loc)) (dirname (if (regexp-match? dirmatch) (normalize-path (match:substring dirmatch 1)) "./"))) dirname ))) (dirname (string-append (extract-path location) idir))) (if (not (eq? #\. (string-ref dirname 0))) (set! dirname (normalize-path dirname))) (if (or (= (string-length dirname) 0) (not (eq? #\/ (string-ref dirname (- (string-length dirname) 1) (set! dirname (string-append dirname "/"))) (if (or (not (file-exists? dirname)) (not (eq? 'directory (stat:type (stat dirname) (set! dirname #f)) (if dirname (let* ((dir (opendir dirname)) (entry (readdir dir))) (while (
Re: Patchy email
On Jan 9, 2012, at 10:18 AM, Graham Percival wrote: > On Mon, Jan 09, 2012 at 08:22:50AM +, Graham Percival wrote: >> On Sun, Jan 08, 2012 at 10:37:51PM -0800, lilypond.patchy.gra...@gmail.com >> wrote: >>> *** FAILED BUILD *** >>> >>> nice make doc -j3 CPU_COUNT=3 >>> >>> Previous good commit: 820c7ff5d380e8ca52057717ab3176b5e40107fd >>> >>> Current broken commit: 42984d05239a3c3be1ea859ba5214ce140448afc >> >> I'm beginning to suspect that we have a random build failure, >> rather than an actual problem in staging right now (or even on Jan >> 7). This is the only case where I haven't seen any info in the >> logs. > > A new staging build just succeeded. It's just possible that > Mike's fix 5e4ca89 solved it, or it could be sheer random fluke. > This is not a happy situation. > My guy says random fluke - if ghostscript had caused the failure in the previous build, there would have been the ghostscript stack trace in the log files :( Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Mon, Jan 09, 2012 at 08:22:50AM +, Graham Percival wrote: > On Sun, Jan 08, 2012 at 10:37:51PM -0800, lilypond.patchy.gra...@gmail.com > wrote: > > *** FAILED BUILD *** > > > > nice make doc -j3 CPU_COUNT=3 > > > > Previous good commit: 820c7ff5d380e8ca52057717ab3176b5e40107fd > > > > Current broken commit: 42984d05239a3c3be1ea859ba5214ce140448afc > > I'm beginning to suspect that we have a random build failure, > rather than an actual problem in staging right now (or even on Jan > 7). This is the only case where I haven't seen any info in the > logs. A new staging build just succeeded. It's just possible that Mike's fix 5e4ca89 solved it, or it could be sheer random fluke. This is not a happy situation. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Usage - added link for Windows users (issue 5521056)
On 2012/01/09 08:46:36, Graham Percival wrote: LGTM, but are you sure that the info on the Windows download page is good for lilypond-book, as well as for lilypond itself? on my own windows machine: --snip-- C:\Program Files\LilyPond\usr\bin>lilypond-book.py --version 2.14.2 C:\Program Files\LilyPond\usr\bin>lilypond --version GNU LilyPond 2.14.2 Copyright (c) 1996--2011 by Han-Wen Nienhuys Jan Nieuwenhuizen and others. This program is free software. It is covered by the GNU General Public License and you are welcome to change it and/or distribute copies of it under certain conditions. Invoke as `lilypond --warranty' for more information. C:\Program Files\LilyPond\usr\bin> --snip- The instructions on the current webpage say --anip-- ... the name of the folder which contains LilyPond executable files like this: [pre-set paths];DIR\LilyPond\usr\bin Note: DIR will generally be C:\Program Files. and click “OK” button to close the window. --snip-- James http://codereview.appspot.com/5521056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Usage - added link for Windows users (issue 5521056)
LGTM, but are you sure that the info on the Windows download page is good for lilypond-book, as well as for lilypond itself? http://codereview.appspot.com/5521056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Sun, Jan 08, 2012 at 10:37:51PM -0800, lilypond.patchy.gra...@gmail.com wrote: > *** FAILED BUILD *** > > nice make doc -j3 CPU_COUNT=3 > > Previous good commit: 820c7ff5d380e8ca52057717ab3176b5e40107fd > > Current broken commit: 42984d05239a3c3be1ea859ba5214ce140448afc The error message from this is the same as we had on jan 7: --- Error ignored by lilylib lilypond-book.py (GNU LilyPond) 2.15.25 Error trapped by lilypond-book Please see /main/large-tmp/lilypond-autobuild/build/out/lybook-db/snippet-names-1740910883.log --- when that file only contains: --- GNU LilyPond 2.15.25 Forking into jobs: (18440 18439 18438) job 2 terminated with signal: 11 fatal error: Children (2) exited with errors. - I'm beginning to suspect that we have a random build failure, rather than an actual problem in staging right now (or even on Jan 7). This is the only case where I haven't seen any info in the logs. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
