Re: Problem with make
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Thursday, 22. September 2011, 01:55:15 schrieb David Kastrup: yep, happens about 10% of the time for me. Running make again fixes it. (almost always -- the chance of two failing runs is about 1%. That's happened twice to me that I can recall) - - - happens to me nearly every time i make. You get news.tely and authors.texi. Failing. Run make again and it's fine. Never had two on the trot like graham. [..] That points to either a problem with parallel make processes, or more likely a time stamp resolution problem. I only get such a problem if I call make -j3 (or something other 1). I have never experienced it with make, so my guess would be that the dependencies of our texinfo files are not complete. That would probably mean that one make process determines that a dependency is available and up to date and proceeds on this assumption, and then another make process removes that file as a sideeffect of building a different target before the first make process has finished working with the file. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
Pushed as 829f0ded77ee44ea6f0566fb5e5318802a8857ad. http://codereview.appspot.com/5030053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
Graham Percival writes: +1 Automatic indentation *does* solve real problems. My point exactly: use Emacs. Gee, I wonder why we haven't seen any more patches from that new contributor? /sarcasm This looks like a contributor who needs some guidance. The first thing I notice is benko.pal aargh, that's not too readable. what I actually suggest is replacing lines 204-207 of 204 if ((left_to_do_ - note_dur.get_length ()) Rational (0)) 205 event-set_property(autosplit-end, ly_bool2scm (true)); 206 else 207 event-set_property(autosplit-end, ly_bool2scm (false)); by event-set_property (autosplit-end, ly_bool2scm (left_to_do_ - note_dur.get_length () 0)); which has nothing to do with indentation. Yes, the space before the parentheses is missing, but that is of an other order of importance than the code duplication. I very much doubt whether indentation is the issue here; it could very well be the policy of taking patches, or how Rietveld enables or steers that policy. If I were a contributor, something like this Graham Percival I've identified a few more questionable lines, although maybe you should wait for a lilypond C++ expert to look at them. lily/tie-engraver.cc:190: (assume this should be indented with: 1 tab + 2 spaces would really be putting me off. It should suffice to say: please fix indentation (there is enough other code to spot the errors) and possibly say we use GNU style. Luckily we can now say: run fixcc. However, it seems that we lack a good policy on when to just apply a patch from a new contributor, fix minor nits, apply it, and email them the result: Thanks for your patch, I have applied it with small modifications/indentation nits, see below. While you should possibly not be doing that more than 2 or 3 times, this is a very efficient way of integrating patches and communicating what kind of code we expect. Also, it seems to me that the Rietveld interface triggers and facilitates talk/discussion rather than code massaging. It could well be that that sending GIT patches [or git urls] over email, and responding either with inline comments or with an alternative/evolutionary GIT patch is much more efficient. The GNU project is completely irrelevant. The GNU style explicitly states that We don’t think of these recommendations as requirements How can you say that? It is very relevant. Not making something a requirement transfers the responsibility of taking a sound choice to the maintainers. Of course, life is easier if maintainers follow recommendations. Long ago we chose to use the GNU style. Isn't that pretty clear? We saw no good reason to deviate from other GNU projects and it was an easy choice because we used Emacs. The GNU project uses and recommends Emacs as its editor and as long as everyone does, none of this comes up. Please find an indenter that does what Emacs does. Most every .scm is indented by Emacs now. I have no objection to having this script indent in the same way that emacs does. Great! I truly hope that all the time that this GNU project is spending on enabling the use of other editors, rather than advocating the use of, GNU Emacs will pay off. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
Graham Percival writes: Yep. I'd describe it as three websites It's a royal mess. There is some value in having issues.google.com than only a bugs mailing list, but there is indeed also a cost. Any ideas on how to deal with people who only want to deal with email? We may want to have a look at the new http://bugs.gnu.org , an implementation of debbugs. Debbugs works great with just email. I would like to know if it has git support, you really want to link your git commits (Fixed: #1233.) to the debbugs database and vice versa. My vague recollection is that the google project tools have easy support for email as long as everybody is using google accounts. What does this support look like? It would be pretty weird to require this, otoh, if it would really fix our royal mess, we may want to consider it. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
I'd like to add a note to this effect in the CG - anyone object? -- Phil Holmes - Original Message - From: pkx1...@gmail.com To: Phil Holmes em...@philholmes.net; Graham Percival gra...@percival-music.ca Cc: Devel lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 12:05 AM Subject: RE: Problem with make hello, On Wed, Sep 21, 2011 at 05:13:00PM +0100, Phil Holmes wrote: On my fast build system, I can't currently get a successful make. Abort changes, pull, clean build directory. The build ends with: ... As you see, the problem is a missing AUTHORS.texi. The odd thing is that on previous make runs, I get yep, happens about 10% of the time for me. Running make again fixes it. (almost always -- the chance of two failing runs is about 1%. That's happened twice to me that I can recall) - - - happens to me nearly every time i make. You get news.tely and authors.texi. Failing. Run make again and it's fine. Never had two on the trot like graham. I probably run make about 10 times a day at the moment, checking patches. I'm used to it and just assumed it was one of our build quirks. You'll see lots more on faster machines in my own personal experience. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 12:59 AM Subject: Re: Problem with make David Kastrup d...@gnu.org writes: pkx1...@gmail.com pkx1...@gmail.com writes: hello, On Wed, Sep 21, 2011 at 05:13:00PM +0100, Phil Holmes wrote: On my fast build system, I can't currently get a successful make. Abort changes, pull, clean build directory. The build ends with: ... As you see, the problem is a missing AUTHORS.texi. The odd thing is that on previous make runs, I get yep, happens about 10% of the time for me. Running make again fixes it. (almost always -- the chance of two failing runs is about 1%. That's happened twice to me that I can recall) - - - happens to me nearly every time i make. You get news.tely and authors.texi. Failing. Run make again and it's fine. Never had two on the trot like graham. I probably run make about 10 times a day at the moment, checking patches. I'm used to it and just assumed it was one of our build quirks. You'll see lots more on faster machines in my own personal experience. That points to either a problem with parallel make processes, or more likely a time stamp resolution problem. When file modification dates are only accessed with second resolution (because the info is not available in the file system type, or the application does not use it) and a process for updates is quite fast, an updated dependent file may seem to have the same time stamp as its original. Expounding on that theory and doing pattern matching: does the problem get better or worse when you replace the in python/book_snippets.py:781: os.stat (single)[stat.ST_MTIME]))): with = ? I'll have a look. It may have nothing whatsoever to do with your problem, but that's a reference to a modification time I can see in the code. And what file system do you have? fat32 does not support more than second resolution IIRC. Whatever Ubuntu uses as a default. On my windows systems I always use NTFS. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
- Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com To: lilypond-devel@gnu.org Cc: David Kastrup d...@gnu.org Sent: Thursday, September 22, 2011 2:07 AM Subject: Re: Problem with make Am Thursday, 22. September 2011, 01:55:15 schrieb David Kastrup: yep, happens about 10% of the time for me. Running make again fixes it. (almost always -- the chance of two failing runs is about 1%. That's happened twice to me that I can recall) - - - happens to me nearly every time i make. You get news.tely and authors.texi. Failing. Run make again and it's fine. Never had two on the trot like graham. [..] That points to either a problem with parallel make processes, or more likely a time stamp resolution problem. I only get such a problem if I call make -j3 (or something other 1). I have never experienced it with make, so my guess would be that the dependencies of our texinfo files are not complete. Cheers, Reinhold I was getting it when I went from make -j9 to make -j5, but didn't want to be bothered with running a single core. I'm assuming you're correct, though. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On Sep 22, 2011, at 10:49 AM, Jan Nieuwenhuizen wrote: Graham Percival writes: Yep. I'd describe it as three websites It's a royal mess. There is some value in having issues.google.com than only a bugs mailing list, but there is indeed also a cost. Any ideas on how to deal with people who only want to deal with email? We may want to have a look at the new http://bugs.gnu.org , an implementation of debbugs. Debbugs works great with just email. I would like to know if it has git support, you really want to link your git commits (Fixed: #1233.) to the debbugs database and vice versa. My vague recollection is that the google project tools have easy support for email as long as everybody is using google accounts. What does this support look like? It would be pretty weird to require this, otoh, if it would really fix our royal mess, we may want to consider it. Jan This discussion is a bit out of my league, but because it is out of my league, I've been asking myself the question that I ask myself when confronted with something out of my league: namely, has anyone done a survey of what other projects use and how it works for them? I've seen a few e-mails to the tune of Project X uses tool Y, but it'd be great to know concretely the pros and cons of all of these options from projects that, like LilyPond, have stuck with one of these bug tracking and patch review systems for a while and can give a good perspective of its pluses and minuses. I don't know anything about open source projects outside of LilyPond, but could someone branched into other GNU projects perhaps collect this sort of info? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
- Original Message - From: Graham Percival gra...@percival-music.ca To: Janek Warchoł janek.lilyp...@gmail.com Cc: Phil Holmes m...@philholmes.net; carl.d.soren...@gmail.com; Aleksandr Andreev aleksandr.andr...@gmail.com; lemzw...@googlemail.com; reinhold.kainho...@gmail.com; lilypond-devel@gnu.org; percival.music...@gmail.com Sent: Thursday, September 22, 2011 5:31 AM Subject: Re: Glyphs for Kievan Notation (issue 4951062) On Thu, Sep 22, 2011 at 06:22:13AM +0200, Janek Warchoł wrote: Overnight i tried making doc on current master and it failed too. ef8dd3eaee73588faf1a6687407a6fda60cff591 worked perfectly in ubuntu 10.04 (not quite lilydev) for me a few hours ago. 63cfd5548c42a98c7dae43f1f92e67772969e53c worked with no problems in GUB. Looks like the error message is the same: writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 ... you know, I'm now remembering a nasty bug I saw last Christmas. Are you using the latest lilydev with all upgrades? In particular, all kernel upgrades? The previous version of lilydev had mysterious+magical problems, when running inside virtualbox, due to a kernel issue. It was very reproducible, but only inside virtualbox, but it went away in the latest version of lilydev so I stopped investigating. Cheers, - Graham == It's here: https://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00200.html It appears that Aleksandr has exactly this same problem. I ceased to be troubled by it when I upgraded to the latest version of lilydev. Janek, Aleksandr - could you confirm what system you're getting make doc failing on? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
James, could you put this through the ringer? It's on patch countdown and I don't really trust my regtesting abilities all too much. Thanks. http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
Am Thursday, 22. September 2011, 09:58:05 schrieb David Kastrup: Reinhold Kainhofer reinh...@kainhofer.com writes: I only get such a problem if I call make -j3 (or something other 1). I have never experienced it with make, so my guess would be that the dependencies of our texinfo files are not complete. That would probably mean that one make process determines that a dependency is available and up to date and proceeds on this assumption, and then another make process removes that file as a sideeffect of building a different target before the first make process has finished working with the file. Exactly. Make copies the *.texi file from the source to the build dir, runs extract-texi-filenames.py and then removes it again... I haven't looked into which stepmake snippet has these rules, but that's what I understand from the output of make. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
Hello, On Thu, Sep 22, 2011 at 10:21 AM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com To: lilypond-devel@gnu.org Cc: David Kastrup d...@gnu.org Sent: Thursday, September 22, 2011 2:07 AM Subject: Re: Problem with make Am Thursday, 22. September 2011, 01:55:15 schrieb David Kastrup: yep, happens about 10% of the time for me. Running make again fixes it. (almost always -- the chance of two failing runs is about 1%. That's happened twice to me that I can recall) - - - happens to me nearly every time i make. You get news.tely and authors.texi. Failing. Run make again and it's fine. Never had two on the trot like graham. [..] That points to either a problem with parallel make processes, or more likely a time stamp resolution problem. I only get such a problem if I call make -j3 (or something other 1). I have never experienced it with make, so my guess would be that the dependencies of our texinfo files are not complete. Cheers, Reinhold I was getting it when I went from make -j9 to make -j5, but didn't want to be bothered with running a single core. I'm assuming you're correct, though. No. It does happen with just a make (I use a single core VM at work for Simple testing) just not very often. I also find that when I am testing patches that there are some patches that never give me this problem, but I've never been able to figure it out (for example if it is just *.cc files patches or *.ly files or some other combination) to give me any more clues. I can start to look a bit harder if people want or am happy to test theories as I, like phil, have a powerful machine so it is only a few minutes. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/22 Phil Holmes m...@philholmes.net: On Thu, Sep 22, 2011 at 06:22:13AM +0200, Janek Warchoł wrote: Overnight i tried making doc on current master and it failed too. ef8dd3eaee73588faf1a6687407a6fda60cff591 worked perfectly in ubuntu 10.04 (not quite lilydev) for me a few hours ago. 63cfd5548c42a98c7dae43f1f92e67772969e53c worked with no problems in GUB. Looks like the error message is the same: writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 ... you know, I'm now remembering a nasty bug I saw last Christmas. Are you using the latest lilydev with all upgrades? In particular, all kernel upgrades? The previous version of lilydev had mysterious+magical problems, when running inside virtualbox, due to a kernel issue. It was very reproducible, but only inside virtualbox, but it went away in the latest version of lilydev so I stopped investigating. Cheers, - Graham == It's here: https://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00200.html It appears that Aleksandr has exactly this same problem. I ceased to be troubled by it when I upgraded to the latest version of lilydev. Janek, Aleksandr - could you confirm what system you're getting make doc failing on? I know that Aleks uses Ubuntu Natty (not Lilydev). I use Lilydev - probably not the newest version, how can i check it? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
David, On Thu, Sep 22, 2011 at 10:37 AM, d...@gnu.org wrote: James, could you put this through the ringer? It's on patch countdown and I don't really trust my regtesting abilities all too much. Thanks. http://codereview.appspot.com/5083045/ No problem, I'll update the tracker to Patch-New (as that's my trigger to test the patch) and then if it's ok I'll set it back and update the Rietveld as well. I won't be able to do this until this evening (BST). -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Problem with make on a commit *after* Davids last '\pushAtTag' commit - 264022bd6ebfed3220c0272d2c4a1c8ef9db4028
Hello, I'm getting the following error when I tried to 'make' this morning. --snip-- /home/jlowe/lilypond-git/ly/string-tunings-init.ly:128:0: error: syntax error, unexpected MUSIC_FUNCTION \makeDefaultStringTunings #defaultStringTunings ] [/home/jlowe/lilypond-git/ly/property-init.ly] [/home/jlowe/lilypond-git/ly/grace-init.ly] [/home/jlowe/lilypond-git/ly/midi-init.ly [/home/jlowe/lilypond-git/ly/performer-init.ly]] [/home/jlowe/lilypond-git/ly/paper-defaults-init.ly [/home/jlowe/lilypond-git/ly/titling-init.ly]] [/home/jlowe/lilypond-git/ly/context-mods-init.ly] [/home/jlowe/lilypond-git/ly/engraver-init.lyBacktrace: In unknown file: ?: 0* [lilypond-main (/home/jlowe/lilypond-git/ly/generate-documentation)] In /home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/lily.scm: 816: 1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...) 816: 2* [lilypond-all (/home/jlowe/lilypond-git/ly/generate-documentation)] 829: 3 (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...) 840: 4* [for-each #procedure #f # #] In unknown file: ?: 5* [#procedure #f (x) /home/jlowe/lilypond-git/ly/generate-documentation] In /home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/lily.scm: 842: 6* (let* (# # #) (if separate-logs #) (if ping-log #) ...) 853: 7* [lilypond-file #procedure #f # ...] 879: 8 [catch ly-file-failed #procedure #f () #procedure #f (x . args)] In unknown file: ?: 9* [#procedure #f ()] In /home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/lily.scm: 880: 10* [ly:parse-file /home/jlowe/lilypond-git/ly/generate-documentation] /home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/lily.scm:880:21: In procedure ly:parse-file in expression (ly:parse-file file-name): /home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/lily.scm:880:21: Unbound variable: guitar-tuning make[1]: *** [out/internals.texi] Error 1 make[1]: Leaving directory `/home/jlowe/lilypond-git/build/Documentation' make: *** [all] Error 2 jlowe@jlowe-lilydevVM:~/lilypond-git/build$ --snip-- The last successful make I did was for Davids last '\pushAtTag' commit - 264022bd6ebfed3220c0272d2c4a1c8ef9db4028 so somewhere after that is where the problem occured. I've gone back through the commits but cannot see anything specific that changes 'string-tunings-init.ly' but I see nothing. It was from a newly created out-of-tree build. Can someone check this? -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
Update done. I think the C part is ok. There's maybe a few things to change in the doc. Shall I wait for a countdown or push directly? Bertrand http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Problem with git push
On my new machine, I get: phil@Ubuntu:~/lilypond-git$ git push --dry-run To ssh://philhol...@git.sv.gnu.org/srv/git/lilypond.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'ssh://philhol...@git.sv.gnu.org/srv/git/lilypond.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. phil@Ubuntu:~/lilypond-git$ I did See the 'Note about fast-forwards' section of 'git push --help' but it didn't help me at all. Could anyone point me to what the problem is and how to fix it, please? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Janek 2011/9/22 Janek Warchoł janek.lilyp...@gmail.com: I know that Aleks uses Ubuntu Natty (not Lilydev). I use Lilydev - probably not the newest version, how can i check it? System - Administration - System Monitor click on the first tab : ) That's the GUI way. You can also do some other things to get bits and pieces cat /etc/issue or cat /etc/lsb-release HTH -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make on a commit *after* Davids last '\pushAtTag' commit- 264022bd6ebfed3220c0272d2c4a1c8ef9db4028
On 22 September 2011 12:48, Phil Holmes m...@philholmes.net wrote: We probably need to learn how to use git bisect... It's David's most recent commit: 6c3445a0791831d450573cf583da36aecac5322c Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
- Original Message - From: Phil Holmes em...@philholmes.net To: Devel lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 12:44 PM Subject: Problem with git push On my new machine, I get: phil@Ubuntu:~/lilypond-git$ git push --dry-run To ssh://philhol...@git.sv.gnu.org/srv/git/lilypond.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'ssh://philhol...@git.sv.gnu.org/srv/git/lilypond.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. phil@Ubuntu:~/lilypond-git$ I did See the 'Note about fast-forwards' section of 'git push --help' but it didn't help me at all. Could anyone point me to what the problem is and how to fix it, please? -- Phil Holmes Same problem on my VM, so I think it's either the status of git, or my username - not anything machine specific. I was getting the same problem last night. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make on a commit *after* Davids last '\pushAtTag' commit - 264022bd6ebfed3220c0272d2c4a1c8ef9db4028
David Kastrup d...@gnu.org writes: Peekay Ex pkx1...@gmail.com writes: Hello, I'm getting the following error when I tried to 'make' this morning. --snip-- /home/jlowe/lilypond-git/ly/string-tunings-init.ly:128:0: error: syntax error, unexpected MUSIC_FUNCTION Am bisecting right now, this is likely caused by a change of mine I considered totally trivial. I know I know. Reverted. I have no clue whatsoever what could possibly cause this error, probably something related to parser lookahead at inconvenient times. It is always the trivial things that I mess up. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
I'm just trying to push a single commit on master. -- Phil Holmes - Original Message - From: Bertrand Bordage To: Phil Holmes Cc: lilypond-devel@gnu.org ; David Kastrup Sent: Thursday, September 22, 2011 1:13 PM Subject: Re: Problem with git push You can specify what you want to push: git push --dry-run origin [hash]:[branch] This will push every commit between [hash] and origin, assuming we stay in [branch]. Bertrand___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
The commit you want to push must follow origin/master. If it does, just do: git push --dry-run origin [hash_of_the_commit]:master This will push this single commit. If not, you have to rebase so that the commit follows origin/master: git rebase -i origin An editor opens, where you can change the order of the commits: pick [small_hash1] [name1] pick [small_hash2] [name2] pick [small_hash2] [name2] Rewrite this list so that the commit you want to push is on top. Then git push origin [hash]:master Bertrand ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Hi Phil, Janek, Aleksandr - could you confirm what system you're getting make doc failing on? Yes, I'm running Ubuntu Natty (not Lilydev). More specifically, Linux sasha-desktop 2.6.38-11-generic #48-Ubuntu x86_64 GNU/Linux Aleks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)
Some concerns and a handful of questions (as usual in my case).
http://codereview.appspot.com/5096050/diff/1/python/musicexp.py
File python/musicexp.py (right):
http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode63
python/musicexp.py:63: self.print_verbatim ('\\version 2.15.13')
Isn't this a mistake?
If not, can it not be hardcoded?
http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode283
python/musicexp.py:283: return False
Can you add a comment saying what does this do?
I'd appreciate it, because i don't know :)
http://codereview.appspot.com/5096050/diff/1/python/musicxml.py
File python/musicxml.py (right):
http://codereview.appspot.com/5096050/diff/1/python/musicxml.py#newcode176
python/musicxml.py:176: for r in source:
What does this do?
Can you add a comment explaining this?
http://codereview.appspot.com/5096050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
I've just used lily-git to do a hard reset of my git, reapplied the changes, recommitted and redone the push --dry-run and am still getting the same error. I'm not quite sure what it means for commit you want to push must follow origin/master but it's definitely the sole commit which is on the latest version of master. -- Phil Holmes - Original Message - From: Bertrand Bordage To: Phil Holmes Cc: lilypond-devel@gnu.org ; David Kastrup Sent: Thursday, September 22, 2011 1:40 PM Subject: Re: Problem with git push The commit you want to push must follow origin/master. If it does, just do: git push --dry-run origin [hash_of_the_commit]:master This will push this single commit. If not, you have to rebase so that the commit follows origin/master: git rebase -i origin An editor opens, where you can change the order of the commits: pick [small_hash1] [name1] pick [small_hash2] [name2] pick [small_hash2] [name2] Rewrite this list so that the commit you want to push is on top. Then git push origin [hash]:master Bertrand___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
2011/9/22 Phil Holmes m...@philholmes.net: I've just used lily-git to do a hard reset of my git, reapplied the changes, recommitted and redone the push --dry-run and am still getting the same error. I'm not quite sure what it means for commit you want to push must follow origin/master but it's definitely the sole commit which is on the latest version of master. Doesn't To prevent you from losing history, non-fast-forward updates were rejected... after pull -r mean that there is some conflict and that your commit cannot be applied to master? (i don't know how pull -r would succeed if that was the case, but...) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)
Welcome to the wonderful world of LilyPond development!
Most changes look fine, but there are some things that can't be
submitted yet. See my comments.
Most important: Please edit the source file in scripts/musicxml2ly.py
and don't modify the installed musicxml2ly file and copy it over to the
source tree! In particular, the source code contains identifiers like
@TOPLEVEL_VERSION@, which will be replaced by the build system with
proper values, so that we don't have to hardcode things like version or
python path!
So,
-) Modify only the scripts/musicxml2ly.py and python/musicexp.py and
python/musicxml.py
-) Run make (you can kill it after a few seconds, as soon as all python
files are processed, which happends right at the beginning)
-) You can't run scripts/musicxml2ly.py directly, but rather the built
out/bin/musicxml2ly
For the last item, on my computer, I have created a simply wrapper
script ~/.bin/musicxml2ly (if ~/.bin is in your PATH environment
variable), which contains only:
reinhold@curie:~$ cat .bin/musicxml2ly
#!/bin/sh
exec ~/lilypond/lilypond/out/bin/musicxml2ly $@
You can then simply call musicxml2ly, and the built musicxml2ly will be
called.
http://codereview.appspot.com/5096050/diff/1/python/musicexp.py
File python/musicexp.py (right):
http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode63
python/musicexp.py:63: self.print_verbatim ('\\version 2.15.13')
On 2011/09/22 12:50:43, janek wrote:
Isn't this a mistake?
I suppose it is a mistake. The source should contain @TOPLEVEL_VERSION@,
which will be replaced by the current version by make.
http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode283
python/musicexp.py:283: return False
These functions should not be placed here. The pitch language functions
are here, because the Pitch class is next. The midi functions don't
belong here.
http://codereview.appspot.com/5096050/diff/1/python/musicxml.py
File python/musicxml.py (right):
http://codereview.appspot.com/5096050/diff/1/python/musicxml.py#newcode252
python/musicxml.py:252: return None
Please don't exactly duplicate get_file_description!
A much cleaner solution would be to rename get_file_description to
get_miscellaneous and return a hash of all miscellaneous fields (note
that the 'name' attribute is REQUIRED in the MusicXML specification)...
Something like:
def get_miscellaneous (self):
misc = self.get_named_children ('miscellaneous')
ret = []
for m in misc:
misc_fields = m.get_named_children ('miscellaneous-field')
for mf in misc_fields:
if hasattr (mf, 'name'):
ret[mf.name] = mf.get_text ()
else:
// Print a warning here...
return ret
Instead of the if hasattr you can also use mf.get('name', '').
Of course, you'll have to adjust musicxml2ly.py, too. But at least this
solution is more general, and the logic to abuse a description misc
field for the texidoc is implemented in the main file, not in a library
file.
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py
File scripts/musicxml2ly.py (right):
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode1
scripts/musicxml2ly.py:1: #!/usr/bin/python
Please don't modify the compiled musicxml2ly and copy it to the source
tree. Rather modify the scripts/musicxml2ly.py in the source tree and
call make. To run it, simply call out/bin/musicxml2ly.
The source code MUST have the @TARGET_PYTHON@, @relocate-preamble@, etc.
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode33
scripts/musicxml2ly.py:33:
Same as above: Needs to be @relocate-preamble@ in the code!
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode210
scripts/musicxml2ly.py:210: set_if_exists ('subtitle',
movement_title.get_text ())
else is missing (if there is no work, then no title will be set at
all, even if movement_title exists). I would structure the if as follows
(pseudocode):
if work:
'title' = work_title
if movement_title:
'subtitle' = movement_title
elif movement_title:
'title' = movement_title
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode221
scripts/musicxml2ly.py:221: #set_if_exists ('tagline',
ids.get_encoding_software ())
Simply remove the code without comment.
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode231
scripts/musicxml2ly.py:231: #set_if_exists ('miscellaneous',
ids.get_miscellaneous ());
If you change get_miscellaneous to a hash, you can extract the
'description' here for the texidoc, and loop through all fields to
insert custom header fields for them.
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode2596
scripts/musicxml2ly.py:2596: p.version = ('''%prog (LilyPond)
2.15.13\n\n'''
@TOPLEVEL_VERSION@
http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode2797
scripts/musicxml2ly.py:2797:
Re: Problem with git push
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: Bertrand Bordage bordage.bertr...@gmail.com; David Kastrup d...@gnu.org; lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 2:05 PM Subject: Re: Problem with git push 2011/9/22 Phil Holmes m...@philholmes.net: I've just used lily-git to do a hard reset of my git, reapplied the changes, recommitted and redone the push --dry-run and am still getting the same error. I'm not quite sure what it means for commit you want to push must follow origin/master but it's definitely the sole commit which is on the latest version of master. Doesn't To prevent you from losing history, non-fast-forward updates were rejected... after pull -r mean that there is some conflict and that your commit cannot be applied to master? (i don't know how pull -r would succeed if that was the case, but...) cheers, Janek = That's what it appears to mean - but since I've done all the commands that should reset my git to be exactly the same as master, then done a 3 line change to lily/GNUmakefile, I can't see how there can actually be a conflict. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
Am Donnerstag, 22. September 2011, 13:44:20 schrieb Phil Holmes: On my new machine, I get: phil@Ubuntu:~/lilypond-git$ git push --dry-run To ssh://philhol...@git.sv.gnu.org/srv/git/lilypond.git ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'ssh://philhol...@git.sv.gnu.org/srv/git/lilypond.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. phil@Ubuntu:~/lilypond-git$ I did See the 'Note about fast-forwards' section of 'git push --help' but it didn't help me at all. Could anyone point me to what the problem is and how to fix it, please? Someone has pushed a patch to the server, which you have not yet fetched. Pushing in git simply means to set the server's code tree to the exact same state as you have on your harddisk. Since you don't have that latest commit yet, git warns you that pushing would discard that patch and that you should fetch the latest commits from the server before pushing. Simply fetch from the server: git pull --rebase or git fetch origin git rebase origin/master Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.15.12 regtest problems
There are 2 significant problems I've found with 2.15.12. The first is shown in the Les Nereides regtest - a fingering indication goes missing. I've attached a crop of the difference between 2.15.12 and 2.15.10 - 2.15.12 is in red. You'll see that the 1 on the top of the note in bar 5 has gone. The second is performance. On longer scores, 2.15.12 is _much_ slower. An example is the mozart horn regtest, which has gone from about 14 seconds to 27 seconds on my system. I've not been able to check much more, because of subtle differences between the treble clef in 15.12 and 15.10, but that's a starter. -- Phil Holmes attachment: les-nereides-crop.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.12 regtest problems
Phil Holmes em...@philholmes.net writes: There are 2 significant problems I've found with 2.15.12. The first is shown in the Les Nereides regtest - a fingering indication goes missing. I've attached a crop of the difference between 2.15.12 and 2.15.10 - 2.15.12 is in red. You'll see that the 1 on the top of the note in bar 5 has gone. The second is performance. On longer scores, 2.15.12 is _much_ slower. An example is the mozart horn regtest, which has gone from about 14 seconds to 27 seconds on my system. Just to make sure it is not again me who is at fault: could you quickly check that the delay does not appear to happen already before the Interpreting music message? While it is quite unlikely that the parser will burn through significant time, it would be reassuring to have this doubt out of the way. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.12 regtest problems
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 3:01 PM Subject: Re: 2.15.12 regtest problems Phil Holmes em...@philholmes.net writes: There are 2 significant problems I've found with 2.15.12. The first is shown in the Les Nereides regtest - a fingering indication goes missing. I've attached a crop of the difference between 2.15.12 and 2.15.10 - 2.15.12 is in red. You'll see that the 1 on the top of the note in bar 5 has gone. The second is performance. On longer scores, 2.15.12 is _much_ slower. An example is the mozart horn regtest, which has gone from about 14 seconds to 27 seconds on my system. Just to make sure it is not again me who is at fault: could you quickly check that the delay does not appear to happen already before the Interpreting music message? While it is quite unlikely that the parser will burn through significant time, it would be reassuring to have this doubt out of the way. -- David Kastrup Visually, it looks like it's the Preprocessing graphical objects that's slower. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
- Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com Simply fetch from the server: git pull --rebase Well, I was sure I must have done that at one point, but I've done it now and success :-) Thanks Reinhold. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.12 regtest problems
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 3:01 PM Subject: Re: 2.15.12 regtest problems Phil Holmes em...@philholmes.net writes: There are 2 significant problems I've found with 2.15.12. The first is shown in the Les Nereides regtest - a fingering indication goes missing. I've attached a crop of the difference between 2.15.12 and 2.15.10 - 2.15.12 is in red. You'll see that the 1 on the top of the note in bar 5 has gone. The second is performance. On longer scores, 2.15.12 is _much_ slower. An example is the mozart horn regtest, which has gone from about 14 seconds to 27 seconds on my system. Just to make sure it is not again me who is at fault: could you quickly check that the delay does not appear to happen already before the Interpreting music message? While it is quite unlikely that the parser will burn through significant time, it would be reassuring to have this doubt out of the way. Visually, it looks like it's the Preprocessing graphical objects that's slower. Sounds like Mike. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building faillure
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: Bernardo Barros bernardobarr...@gmail.com; Devel lilypond-devel@gnu.org; lilypond-user lilypond-u...@gnu.org Sent: Tuesday, September 20, 2011 11:29 PM Subject: Re: building faillure On Tue, Sep 20, 2011 at 10:08:26AM +0100, Phil Holmes wrote: $(outdir)/general-scheme.o: $(outdir)/version.hh $(outdir)/lily-guile.o: $(outdir)/version.hh $(outdir)/lily-version.o: $(outdir)/version.hh ... Graham: git grep version.hh gives: lily/general-scheme.cc:#include version.hh lily/lexer.ll:#include version.hh lily/lily-guile.cc:#include version.hh lily/lily-version.cc:#include version.hh lily/main.cc:#include version.hh lily/relocate.cc:#include version.hh lily/warn-scheme.cc:#include version.hh I think it could make the build system more robust to make ordering by adding lexer.ll, main.cc, relocate.cc and warn-scheme.cc to the target list for version.hh? Yes please. Add the lines, check that you can compile from scratch, then push directly. Now pushed as 29447b3a224f52444f0ec74225eb9e6af0591223 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building faillure
Phil Holmes m...@philholmes.net writes: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: Bernardo Barros bernardobarr...@gmail.com; Devel lilypond-devel@gnu.org; lilypond-user lilypond-u...@gnu.org Sent: Tuesday, September 20, 2011 11:29 PM Subject: Re: building faillure On Tue, Sep 20, 2011 at 10:08:26AM +0100, Phil Holmes wrote: $(outdir)/general-scheme.o: $(outdir)/version.hh $(outdir)/lily-guile.o: $(outdir)/version.hh $(outdir)/lily-version.o: $(outdir)/version.hh ... Graham: git grep version.hh gives: lily/general-scheme.cc:#include version.hh lily/lexer.ll:#include version.hh lily/lily-guile.cc:#include version.hh lily/lily-version.cc:#include version.hh lily/main.cc:#include version.hh lily/relocate.cc:#include version.hh lily/warn-scheme.cc:#include version.hh I think it could make the build system more robust to make ordering by adding lexer.ll, main.cc, relocate.cc and warn-scheme.cc to the target list for version.hh? Yes please. Add the lines, check that you can compile from scratch, then push directly. Now pushed as 29447b3a224f52444f0ec74225eb9e6af0591223 There is no such thing as lexer.ll.o and most of the stuff seems already mentioned in out/*.dep. Isn't this activism? I think the following is much more glaring: # list parser.hh first: making parser.hh removes parser.cc OUT_DIST_FILES=$(addprefix $(outdir)/,parser.hh parser.cc) We can't really have a situation like that described in the comment if we want to have parallel compilation to work. Either we need a _single_ rule for parser.hh and parser.cc (not much else makes sense), or one needs to juggle with -o and -d in order to make sure that generating the header file does not stomp over the C file and vice versa. Since non-matching output files are a bad idea anyway, I'd prefer a single rule. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
- Original Message - From: Phil Holmes m...@philholmes.net To: Reinhold Kainhofer reinh...@kainhofer.com; lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 3:28 PM Subject: Re: Problem with git push - Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com Simply fetch from the server: git pull --rebase Well, I was sure I must have done that at one point, but I've done it now and success :-) Thanks Reinhold. Update. That fixed it on my VM (slow) machine but not my real Ubuntu (fast) machine. Unless there are other commands I can try, I'm seriously thinking I may have to nuke my git directory and start again :-( -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
2011/9/22 Phil Holmes m...@philholmes.net: - Original Message - From: Phil Holmes m...@philholmes.net To: Reinhold Kainhofer reinh...@kainhofer.com; lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 3:28 PM Subject: Re: Problem with git push - Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com Simply fetch from the server: git pull --rebase Well, I was sure I must have done that at one point, but I've done it now and success :-) Thanks Reinhold. Update. That fixed it on my VM (slow) machine but not my real Ubuntu (fast) machine. Unless there are other commands I can try, I'm seriously thinking I may have to nuke my git directory and start again :-( I can try pushing itin the evening if you send it to us. Maybe i'l find what should be done. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
On Thu, Sep 22, 2011 at 11:44:29AM +0200, Reinhold Kainhofer wrote: Exactly. Make copies the *.texi file from the source to the build dir, runs extract-texi-filenames.py and then removes it again... Ouch. Is there any compelling reason to 1) not run extract-texi-filename.py on the original file, or 2) not remove the file? I mean, it's not like a small text file is going to change our 1.5 Gb build directory much. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
Graham Percival gra...@percival-music.ca writes: On Thu, Sep 22, 2011 at 11:44:29AM +0200, Reinhold Kainhofer wrote: Exactly. Make copies the *.texi file from the source to the build dir, runs extract-texi-filenames.py and then removes it again... Ouch. Is there any compelling reason to 1) not run extract-texi-filename.py on the original file, or 2) not remove the file? I mean, it's not like a small text file is going to change our 1.5 Gb build directory much. not remove the file does not help if the file is not properly in the dependency lists since then changes in one process are not synchronized with usage in another process. Temporary files can't properly be targets in a makefile. So they must not collide with the generation of other files and must be used exclusively in one rule, possibly by creating unique file names for them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.12 regtest problems
On 22 September 2011 17:38, Graham Percival gra...@percival-music.ca wrote: On Thu, Sep 22, 2011 at 02:46:38PM +0100, Phil Holmes wrote: There are 2 significant problems I've found with 2.15.12. Could we get issues for these? I should probably cancel the release countdown. I can't verify either problem here. The missing fingering would've shown up in the regtest comparison, and running the snippet locally produces correct output. Master is faster on my system than 2.15.10 (both optimised and unoptimised), mainly due to the lack of cyclic redundancy error spamming. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with git push
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: Reinhold Kainhofer reinh...@kainhofer.com; lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 4:20 PM Subject: Re: Problem with git push 2011/9/22 Phil Holmes m...@philholmes.net: - Original Message - From: Phil Holmes m...@philholmes.net To: Reinhold Kainhofer reinh...@kainhofer.com; lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 3:28 PM Subject: Re: Problem with git push - Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com Simply fetch from the server: git pull --rebase Well, I was sure I must have done that at one point, but I've done it now and success :-) Thanks Reinhold. Update. That fixed it on my VM (slow) machine but not my real Ubuntu (fast) machine. Unless there are other commands I can try, I'm seriously thinking I may have to nuke my git directory and start again :-( I can try pushing itin the evening if you send it to us. Maybe i'l find what should be done. = I've pushed from my VM - but Reinhold has provided a lot of help and I'm still struggling, some I'll nuke git tomorrow and start from scratch. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes em...@philholmes.net Cc: pkx1...@gmail.com; Devel lilypond-devel@gnu.org Sent: Thursday, September 22, 2011 5:35 PM Subject: Re: Problem with make On Thu, Sep 22, 2011 at 10:17:50AM +0100, Phil Holmes wrote: I'd like to add a note to this effect in the CG - anyone object? yes; I'd rather see an issue in the tracker instead. Can I suggest that this is rather overkill for an update to the CG? I'd not disagree at all over notation ref, or code, but the CG isn't supposed to be finely crafted words, it's supposed to be a quick source of reference for contributors. You'll note that I thought pushing directly to it was OK when I added stuff about regtest comparisons. I think this is the same. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rietveld workflow problems
On 9/21/11 10:29 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: 2011/9/21 Carl Sorensen c_soren...@byu.edu: Reviews in Google Code are done on branches, and each commit on the branch is visible and reviewable. Looks interesting, however i seem to be unable to add comments - probably because i'm not a project member. Could you enable adding comments by non-project members and could we mess with that repository a bit by sending bogus reviews etc? Done. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement define-event-function (issue 5083045)
Passes make and reg tests http://codereview.appspot.com/5083045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
Couldn't find a tracker issue for this, however it passes make and reg tests. http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
parser.yy: allow composite_music to also consist of a MUSIC_IDENTIFIER. (issue 5090045)
Passes make and reg tests http://codereview.appspot.com/5090045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
Hello, On Thu, Sep 22, 2011 at 6:49 PM, Graham Percival gra...@percival-music.ca wrote: On Thu, Sep 22, 2011 at 06:22:55PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca On Thu, Sep 22, 2011 at 10:17:50AM +0100, Phil Holmes wrote: I'd like to add a note to this effect in the CG - anyone object? yes; I'd rather see an issue in the tracker instead. Can I suggest that this is rather overkill for an update to the CG? I'd not disagree at all over notation ref, or code, but the CG isn't supposed to be finely crafted words, it's supposed to be a quick source of reference for contributors. You'll note that I thought pushing directly to it was OK when I added stuff about regtest comparisons. I think this is the same. oh, sorry, I was unclear. I don't want to see this bug documented in the CG; I want to see this bug fixed. It's going to be a 1-3 line fix to some build file. I'm optimistic that this can be achieved within a week. As such, I don't want an extra note in the CG that we'll have to remove in a few days. Cheers, - Graham if it is of any use, the last 3 patches I have just tested for David, none gave me make failures at all. I even did two of them again twice, just to see if it was a fluke. So it seems to be the 'type' of files that get patched perhaps that generate this oddity? Reitveld issues 5023044, 5090045, 5083045. regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
music notation dyslexia
Hi all, my daughter plays the harp (2nd year), but has some difficult to read the music notation: she is dyslexic. His difficulty consists in identify correctly the symbols, so a G may be a B or viceversa. An idea should be to use different colors (for pdf), e.g. B=violet, A=brown, and so on... may be useful? thanks in advance. Mauro ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music notation dyslexia
Hello, On Thu, Sep 22, 2011 at 8:24 PM, Mauro mrossol...@yahoo.it wrote: Hi all, my daughter plays the harp (2nd year), but has some difficult to read the music notation: she is dyslexic. His difficulty consists in identify correctly the symbols, so a G may be a B or viceversa. An idea should be to use different colors (for pdf), e.g. B=violet, A=brown, and so on... may be useful? Like this? http://lsr.dsi.unimi.it/LSR/Item?id=242 regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music notation dyslexia
Hello, On Thu, Sep 22, 2011 at 8:24 PM, Mauro mrossol...@yahoo.it wrote: Hi all, my daughter plays the harp (2nd year), but has some difficult to read the music notation: she is dyslexic. His difficulty consists in identify correctly the symbols, so a G may be a B or viceversa. An idea should be to use different colors (for pdf), e.g. B=violet, A=brown, and so on... This is probably more what you want http://lsr.dsi.unimi.it/LSR/Item?id=572 -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
Pushed as 83055a30e52c14b0fd49d6df3eb1c7af476ecb4b http://codereview.appspot.com/5023044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
Peekay Ex pkx1...@gmail.com writes: Hello, On Thu, Sep 22, 2011 at 6:49 PM, Graham Percival gra...@percival-music.ca wrote: On Thu, Sep 22, 2011 at 06:22:55PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca On Thu, Sep 22, 2011 at 10:17:50AM +0100, Phil Holmes wrote: I'd like to add a note to this effect in the CG - anyone object? yes; I'd rather see an issue in the tracker instead. Can I suggest that this is rather overkill for an update to the CG? I'd not disagree at all over notation ref, or code, but the CG isn't supposed to be finely crafted words, it's supposed to be a quick source of reference for contributors. You'll note that I thought pushing directly to it was OK when I added stuff about regtest comparisons. I think this is the same. oh, sorry, I was unclear. I don't want to see this bug documented in the CG; I want to see this bug fixed. It's going to be a 1-3 line fix to some build file. I'm optimistic that this can be achieved within a week. As such, I don't want an extra note in the CG that we'll have to remove in a few days. Cheers, - Graham if it is of any use, the last 3 patches I have just tested for David, none gave me make failures at all. I even did two of them again twice, just to see if it was a fluke. So it seems to be the 'type' of files that get patched perhaps that generate this oddity? Reitveld issues 5023044, 5090045, 5083045. All of my patches tend to touch lily/parser.yy and lily/lexer.ll and not much else. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
On Thu, Sep 22, 2011 at 10:23:00AM +0200, Jan Nieuwenhuizen wrote: Graham Percival writes: Gee, I wonder why we haven't seen any more patches from that new contributor? /sarcasm This looks like a contributor who needs some guidance. Yes. It should suffice to say: please fix indentation (there is enough other code to spot the errors) and possibly say we use GNU style. Luckily we can now say: run fixcc. There is nothing lucky about that; we spent somewhere between 20 to 40 developer-hours producing the current fixcc. Note that before spending that time, we could *not* say use GNU style or use emacs, since our code did not follow either of those styles (and running fixcc on certain files actually caused them to fail to compile!). I think this was a decent trade-off. Of course it would have been nice if we could have done it in only 10 hours of developer-time, but I'm not surprised it took as long as it did, and at least it's done now. But don't call it lucky; a number of people worked very hard to make it possible. However, it seems that we lack a good policy on when to just apply a patch from a new contributor, fix minor nits, apply it, and email them the result: Thanks for your patch, I have applied it with small modifications/indentation nits, see below. While you should possibly not be doing that more than 2 or 3 times, this is a very efficient way of integrating patches and communicating what kind of code we expect. Yes; the problem is a lack of mentors. I have done this many times for documentation patches when I was mentoring new doc writers. *shrug* It's not as though I haven't been advertising and pleading developers to mentor new contributors. As a group, we are collectively not very interested in giving personal help to new contributors. At this point, I think the only sensible thing is to accept that this is the way we are, and plan our other policies around that. Related: high context vs. low context cultures in open source, from one of the Mozilla people. http://stormyscorner.com/2011/09/does-open-source-exclude-high-context-cultures.html We are almost exclusively low context culture in lilypond. I invested a lot of time trying to create a high (or at least medium context) culture during the Grand Documentation Project, but we all know how that ended up. At this point, I think we simply need to accept that lilypond development is a fairly individual, low context culture, and gear our policies towards that. And also accept that we'll have far fewer contributors than we could have. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-guile updates and CG: Scheme-C interface section. (issue 4917044)
Since it has C changes as well, I'd prefer it to go through a countdown. http://codereview.appspot.com/4917044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On Thu, Sep 22, 2011 at 10:49:56AM +0200, Jan Nieuwenhuizen wrote: Graham Percival writes: Any ideas on how to deal with people who only want to deal with email? We may want to have a look at the new http://bugs.gnu.org , an implementation of debbugs. Hmm, clunky user interface. My vague recollection is that the google project tools have easy support for email as long as everybody is using google accounts. What does this support look like? Both these comments came from email: http://code.google.com/p/lilypond/issues/detail?id=1#c13 http://codereview.appspot.com/4917044/#msg8 I have a vague recollection that there was some extra trick involved in reply via email to the issue tracker. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
2011/9/22 Graham Percival gra...@percival-music.ca: On Thu, Sep 22, 2011 at 10:49:56AM +0200, Jan Nieuwenhuizen wrote: Graham Percival writes: Any ideas on how to deal with people who only want to deal with email? We may want to have a look at the new http://bugs.gnu.org , an implementation of debbugs. Hmm, clunky user interface. My vague recollection is that the google project tools have easy support for email as long as everybody is using google accounts. What does this support look like? Both these comments came from email: http://code.google.com/p/lilypond/issues/detail?id=1#c13 http://codereview.appspot.com/4917044/#msg8 I have a vague recollection that there was some extra trick involved in reply via email to the issue tracker. I think it's the mailing list used in cc field that messes things. Also, IIRC the e-mail answer was added as comment when you replied to lilypond@... rather than codesite-noreply@... cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/22 Peekay Ex pkx1...@gmail.com: Janek 2011/9/22 Janek Warchoł janek.lilyp...@gmail.com: I use Lilydev - probably not the newest version, how can i check it? System - Administration - System Monitor click on the first tab : ) It says janek-lilydev5 (that's my username and virtual machine name i guess), Ubuntu release 10.04 (lucid), Kernel Linux 2.6.32-26-generic, GNOME 2.30.2 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
Am Thursday, 22. September 2011, 21:42:14 schrieb Peekay Ex: if it is of any use, the last 3 patches I have just tested for David, none gave me make failures at all. I even did two of them again twice, just to see if it was a fluke. So it seems to be the 'type' of files that get patched perhaps that generate this oddity? I would expect that the problem doesn't appear when no texinfo files are concerned. So pure C++ code changes shouldn't have any influence. On the other hand, it might be that either a new version number might cause such problems, or a rebuild due to changes in some texinfo file... That's all just speculation, though, based on experience and gut feeling. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make
On Thu, Sep 22, 2011 at 11:52:36PM +0200, Reinhold Kainhofer wrote: That's all just speculation, though, based on experience and gut feeling. Based on my spectulation and gut feeling from seeing this off and on for the past IIRC 1.5 years, it happens more often when you're building from an existing build dir (instead of a new one), and it happens more often the more -jX options you use. On my computer, with -j3 by default, I saw it something like 10% of the time when building from an existing build dir, and something like 2% of the time when building from a new build dir. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
FWIW, I updated my kernel by installing the latest Ubuntu updates. I also did a git rebase. I still get the same problem. A 2011/9/22 Janek Warchoł janek.lilyp...@gmail.com: 2011/9/22 Peekay Ex pkx1...@gmail.com: Janek 2011/9/22 Janek Warchoł janek.lilyp...@gmail.com: I use Lilydev - probably not the newest version, how can i check it? System - Administration - System Monitor click on the first tab : ) It says janek-lilydev5 (that's my username and virtual machine name i guess), Ubuntu release 10.04 (lucid), Kernel Linux 2.6.32-26-generic, GNOME 2.30.2 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Text hyphenation
Hi Bertrand, 2011/9/23 Bertrand Bordage bordage.bertr...@gmail.com: Hi everyone, I started working on automatic hyphenation (see the attached PDF). I rewrote wordwrap-stencils into a wordwrap-markups and it works great, but I do have a question before continuing. Do you think I should start by: * implementing hyphenation rules; * creating a user-settable hyphenation list; * making a system that allows to specify where a word is breakable (like \- in LaTeX); I vote for this because it seems most multi-language friendly. I.e., implementing hyphenation rules for all major languages (i'm interested at least in english, polish and latin) seems a big pain (or are free libraries about it avaiable?). * abandoning this idea and making a more serious music-only patch? Creating a user-settable list would certainly be the easiest thing to do, but is the ugliest solution. A mix of the three is the best: the rules for the common cases, the list for special cases and something like \- for more flexibility. +1 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music notation dyslexia
2011/9/22 Peekay Ex pkx1...@gmail.com: Hello, On Thu, Sep 22, 2011 at 8:24 PM, Mauro mrossol...@yahoo.it wrote: Hi all, my daughter plays the harp (2nd year), but has some difficult to read the music notation: she is dyslexic. His difficulty consists in identify correctly the symbols, so a G may be a B or viceversa. An idea should be to use different colors (for pdf), e.g. B=violet, A=brown, and so on... This is probably more what you want http://lsr.dsi.unimi.it/LSR/Item?id=572 You may also be interested in this: http://lilypond.org/doc/v2.15/Documentation/notation-big-page.html#note-heads HTH, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
automatic daily checker
Get my github lilypond-extra repository: https://github.com/gperciva/lilypond-extra then look at: auto-compile/compile-lilypond-test.py follow the instructions to set up your ramdisk (700 megs or 2048 megs, depending on whether you want to bother with the docs or not), then run it: python auto-compile/compiler-lilypond-test.py It automatically keeps track of the last known good compile, so if it ever fails, you know that somebody did something naughty since the last time you ran it. No guessing about well, I think I compiled it last night at around 10pm, but it wasn't a completely clean build, so maybe it happened before then but it didn't recompile that or xyz. NB: you need your $LILYPOND_GIT environment variable set up before you run this. In bash, do: export LILYPOND_GIT = $HOME/lilypond-git/ assuming that's the right dir. I highly recommend putting that line in your .bashrc I'm thinking about setting my computer to run this automatically every day (without the doc-build), but does somebody with a fast computer want to do this every 12 hours instead? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic daily checker
Am Friday, 23. September 2011, 00:52:24 schrieb Graham Percival: It automatically keeps track of the last known good compile, so if it ever fails, you know that somebody did something naughty since the last time you ran it. No guessing about well, I think I compiled it last night at around 10pm, but it wasn't a completely clean build, so maybe it happened before then but it didn't recompile that or xyz. FWIW, I'm rebuilding binaries and docs from scratch every night on my office machine to create the docs on http://kainhofer.com/~lilypond, so we already have some kind of daily compilation check... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic daily checker
On Fri, Sep 23, 2011 at 01:03:08AM +0200, Reinhold Kainhofer wrote: Am Friday, 23. September 2011, 00:52:24 schrieb Graham Percival: It automatically keeps track of the last known good compile, so if it ever fails, you know that somebody did something naughty since the last time you ran it. No guessing about well, I think I compiled it last night at around 10pm, but it wasn't a completely clean build, so maybe it happened before then but it didn't recompile that or xyz. FWIW, I'm rebuilding binaries and docs from scratch every night on my office machine to create the docs on http://kainhofer.com/~lilypond, so we already have some kind of daily compilation check... However, - you're not building them from scratch - you don't keep a record of which commits could build - AFAIK you don't check the logs daily -- at least, I haven't seen you emailing -devel saying somebody broke git master between ab12345 and ef6787 If somebody breaks git master, I don't want anybody to find out because their build failed. I want an automatic script to discover the failing, and tell me BEFORE I try to do any work. Granted, there's a trade-off between compiling every single commit vs. available computer power, but I still wish that nobody was ever surprised that git master failed to compile. This script is also the first step towards an automatic dev/staging branch, but I want the basics tested before I move ahead to work on that stuff. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic daily checker
Am Friday, 23. September 2011, 01:12:13 schrieben Sie: On Fri, Sep 23, 2011 at 01:03:08AM +0200, Reinhold Kainhofer wrote: FWIW, I'm rebuilding binaries and docs from scratch every night on my office machine to create the docs on http://kainhofer.com/~lilypond, so we already have some kind of daily compilation check... However, - you're not building them from scratch I am. I nuke the build dir before each build. - you don't keep a record of which commits could build Nope. - AFAIK you don't check the logs daily -- at least, I haven't seen you emailing -devel saying somebody broke git master between ab12345 and ef6787 If a build fails, I get a mail from the cronjob (which contains also the ~200 last output lines from make). However, since the error message is usually buried in thousands of lines of make commands and debug output, I usually don't bother to even try to find the error message. If somebody breaks git master, I don't want anybody to find out because their build failed. I want an automatic script to discover the failing, and tell me BEFORE I try to do any work. Granted, there's a trade-off between compiling every single commit vs. available computer power, but I still wish that nobody was ever surprised that git master failed to compile. Sure, I understand this - and I certainly like it. I just wanted to point out that I'm already doing automated nightly builds, although detecting build failures is not the main purpose, but rather a byproduct. This script is also the first step towards an automatic dev/staging branch, but I want the basics tested before I move ahead to work on that stuff. I haven't looked at it, but Jenkins (http://jenkins-ci.org/) is about continuous integration (i.e. automated builds to detect build failures or regtest failures). It might be overkill for us, but still, there are solutions for exactly this task. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic daily checker
On Fri, Sep 23, 2011 at 01:30:47AM +0200, Reinhold Kainhofer wrote: Am Friday, 23. September 2011, 01:12:13 schrieben Sie: - you're not building them from scratch I am. I nuke the build dir before each build. oh, good! I didn't realize that. :) - you don't keep a record of which commits could build Nope. This key, IMO. We have an average of 2-10 commits per day; when master breaks next time, I wouldn't be surprised if we don't even need to guess. And if it's not obvious, then hey; it's a couple of git bisects to figure out why. - AFAIK you don't check the logs daily -- at least, I haven't seen If a build fails, I get a mail from the cronjob (which contains also the ~200 last output lines from make). However, since the error message is usually buried in thousands of lines of make commands and debug output, I usually don't bother to even try to find the error message. True enough. That's what I'm trying to change. The first step is to automatically identify a narrow range of commits. The next step (in the auto-detection direction, rather than dev/staging) is to automatically extract the info from a failing build (outside of make doc). The final step is to improve the doc build system so that we can get information from that. This script is also the first step towards an automatic dev/staging branch, but I want the basics tested before I move ahead to work on that stuff. I haven't looked at it, but Jenkins (http://jenkins-ci.org/) is about continuous integration (i.e. automated builds to detect build failures or regtest failures). It might be overkill for us, but still, there are solutions for exactly this task. Hmm, Jenkins is java-based. :) I agree that there's stuff out there. Maybe I'm suffering from NIH syndrome yet again, but I think that a few 100-200-line python scripts written by ourselves, specifically for our use case, will end up being better for us. Don't get me wrong; if somebody wants to pop in and say hey, my day job uses XYZ. Give me half an hour and I'll set up exactly what you want, great! But plans for this type of system have been floating around for months, and nobody's stepped forward with such an offer. Writing a set of python scripts like this is a nice way for me to unwind, and I'm only expecting to spend a total of 10-20 hours on this, so I'm happy with the potential NIH-ness of this. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
While we are at it: the docs compilation failed tonight... Unfortunately, the output does not give any error message, so I have no idea what is wrong. Cheers, Reinhold -- Weitergeleitete Nachricht -- Betreff: GDP Docs compilation FAILED (2011.09.23-03:32) Datum: Friday, 23. September 2011, 03:32:10 Von: Lilypond developmen lilyp...@fam.tuwien.ac.at An: reinh...@fam.tuwien.ac.at possibilities for six: (six sixT sixRT sixTR sixR sixRT1q six1qTR sixRT1h six1hTR sixRT3q six3qTR sixRTF sixFTR six1qT sixT1q six1q six1qT1h six1hT1q six1qT3q six3qT1q six1qTF sixFT1q six1hT sixT1h six1h six1hT3q six3qT1h six1hTF sixFT1h six3qT sixT3q six3q six3qTF sixFT3q sixFT sixF) lh possibilities for high-e: (high-e high-eT) possibilities for high-ees: (high-ees high-eesT) possibilities for ees: (ees eesT) possibilities for cis: (cis cisT) possibilities for low-bes: (low-bes low-besT) possibilities for low-b: (low-b low-bT) possibilities for low-c: (low-c low-cT) possibilities for low-d: (low-d low-dT) possibilities for d: (d dT) possibilities for c: (c cT) possibilities for thumb-cis: (thumb-cis thumb-cisT) rh possibilities for bes: (bes besT) possibilities for f: (f fT) possibilities for fis: (fis fisT) possibilities for gis: (gis gisT) possibilities for thumb-bes: (thumb-bes thumb-besT) possibilities for thumb-e: (thumb-e thumb-eT) possibilities for thumb-fis: (thumb-fis thumb-fisT) Printing keys in verbose mode for: flute cc possibilities for one: (one oneT oneRT oneTR oneR oneRT1q one1qTR oneRT1h one1hTR oneRT3q one3qTR oneRTF oneFTR one1qT oneT1q one1q one1qT1h one1hT1q one1qT3q one3qT1q one1qTF oneFT1q one1hT oneT1h one1h one1hT3q one3qT1h one1hTF oneFT1h one3qT oneT3q one3q one3qTF oneFT3q oneFT oneF) possibilities for two: (two twoT twoRT twoTR twoR twoRT1q two1qTR twoRT1h two1hTR twoRT3q two3qTR twoRTF twoFTR two1qT twoT1q two1q two1qT1h two1hT1q two1qT3q two3qT1q two1qTF twoFT1q two1hT twoT1h two1h two1hT3q two3qT1h two1hTF twoFT1h two3qT twoT3q two3q two3qTF twoFT3q twoFT twoF) possibilities for three: (three threeT threeRT threeTR threeR threeRT1q three1qTR threeRT1h three1hTR threeRT3q three3qTR threeRTF threeFTR three1qT threeT1q three1q three1qT1h three1hT1q three1qT3q three3qT1q three1qTF threeFT1q three1hT threeT1h three1h three1hT3q three3qT1h three1hTF threeFT1h three3qT threeT3q three3q three3qTF threeFT3q threeFT threeF) possibilities for four: (four fourT fourRT fourTR fourR fourRT1q four1qTR fourRT1h four1hTR fourRT3q four3qTR fourRTF fourFTR four1qT fourT1q four1q four1qT1h four1hT1q four1qT3q four3qT1q four1qTF fourFT1q four1hT fourT1h four1h four1hT3q four3qT1h four1hTF fourFT1h four3qT fourT3q four3q four3qTF fourFT3q fourFT fourF) possibilities for five: (five fiveT fiveRT fiveTR fiveR fiveRT1q five1qTR fiveRT1h five1hTR fiveRT3q five3qTR fiveRTF fiveFTR five1qT fiveT1q five1q five1qT1h five1hT1q five1qT3q five3qT1q five1qTF fiveFT1q five1hT fiveT1h five1h five1hT3q five3qT1h five1hTF fiveFT1h five3qT fiveT3q five3q five3qTF fiveFT3q fiveFT fiveF) possibilities for six: (six sixT sixRT sixTR sixR sixRT1q six1qTR sixRT1h six1hTR sixRT3q six3qTR sixRTF sixFTR six1qT sixT1q six1q six1qT1h six1hT1q six1qT3q six3qT1q six1qTF sixFT1q six1hT sixT1h six1h six1hT3q six3qT1h six1hTF sixFT1h six3qT sixT3q six3q six3qTF sixFT3q sixFT sixF) lh possibilities for bes: (bes besT) possibilities for b: (b bT) possibilities for gis: (gis gisT) rh possibilities for bes: (bes besT) possibilities for d: (d dT) possibilities for dis: (dis disT) possibilities for ees: (ees eesT) possibilities for cis: (cis cisT) possibilities for c: (c cT) possibilities for gz: (gz gzT) Success: compilation successfully completed Compiling /data/lilypond/build/Documentation/out-www/notation/wind.texi... Writing `/data/lilypond/build/Documentation/out-www/notation/wind.texi'... Processing include: notation/chords.itely Reading /data/lilypond/lilypond/Documentation/notation/chords.itely... Dissecting... Writing snippets... Processing... Running lilypond... Forking into jobs: (9702 9701) Success: compilation successfully completed Compiling /data/lilypond/build/Documentation/out-www/notation/chords.texi... Writing `/data/lilypond/build/Documentation/out-www/notation/chords.texi'... Processing include: notation/contemporary.itely Reading /data/lilypond/lilypond/Documentation/notation/contemporary.itely... Dissecting... Writing snippets... All snippets are up to date... Compiling /data/lilypond/build/Documentation/out- www/notation/contemporary.texi... Writing `/data/lilypond/build/Documentation/out- www/notation/contemporary.texi'... Processing include: notation/ancient.itely Reading
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
On Fri, Sep 23, 2011 at 03:35:26AM +0200, Reinhold Kainhofer wrote: While we are at it: the docs compilation failed tonight... Thanks! Unfortunately, the output does not give any error message, so I have no idea what is wrong. Well, the output contains this: ... fatal error: failed files: be/lily-48175def.ly A decent build system would take that filename, grep it for \sourcefilename, and tell us *that* information, instead of the current useless output. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Hello,
On Fri, Sep 23, 2011 at 3:46 AM, Reinhold Kainhofer
reinh...@fam.tuwien.ac.at wrote:
Am Friday, 23. September 2011, 04:35:06 schrieben Sie:
fatal error: failed files: be/lily-48175def.ly
A decent build system would take that filename, grep it for
\sourcefilename, and tell us *that* information, instead of the
current useless output. :)
A decent build system (or rather lilypond itself) would have already printed
out the correct file name, and it would automatically display the error
message, which should have appeared on stderr anyway.
This is the file that is failing:
--snip--
%% Generated by lilypond-book.py
%% Options: [exampleindent=10.16\mm,indent=0\mm,line-width=160\mm,quote]
\include lilypond-book-preamble.ly
%
% Start cut--pastable-section
%
\paper {
indent = 0\mm
line-width = 160\mm
line-width = 160\mm - 2.0 * 10.16\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.00) (* mm 1))
}
\layout {
}
%
% ly snippet:
%
\sourcefileline 3228
\markup {
\with-link #label {
\italic { This links to the page containing the label... }
}
}
%
% end ly snippet
%
--snip--
--
--
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.12 regtest problems
Phil Holmes email at philholmes.net writes: There are 2 significant problems I've found with 2.15.12. The first is shown in the Les Nereides regtest - a fingering indication goes missing. Confirming. The missing fingering indication is hidden under a note head in the other voice. The change from Stem to Flag for 2.15.12 is necessary to see the problem. I'll try to reduce to a minimal example but it will take a while; there are lots of interacting overrides in that torture-test. The second is performance. On longer scores, 2.15.12 is _much_ slower. Confirming. On average compilation takes 1.5 times as long as it did with 2.14.2, so not as bad as your factor of 2. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.12 regtest problems
Phil Holmes email at philholmes.net writes: I've not been able to check much more, because of subtle differences between the treble clef in 15.12 and 15.10, but that's a starter. But the G clef changed between .8 and .9 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: GDP Docs compilation FAILED (2011.09.23-03:32)
Hello again.. On Fri, Sep 23, 2011 at 5:34 AM, Peekay Ex pkx1...@gmail.com wrote: Hello, On Fri, Sep 23, 2011 at 3:46 AM, Reinhold Kainhofer reinh...@fam.tuwien.ac.at wrote: Am Friday, 23. September 2011, 04:35:06 schrieben Sie: fatal error: failed files: be/lily-48175def.ly A decent build system would take that filename, grep it for \sourcefilename, and tell us *that* information, instead of the current useless output. :) I used gitk to roll back the head to David's first branch merge http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=31dc6e0a1b454c1186052f36cfac3e2e7c20325e and a full make doc (from a fresh build dir) worked fine. So the issue, by deduction, is somewhere in his second merged branch (Merge branch 'musicfunction-optional-arguments' - 83055a30e52c14b0fd49d6df3eb1c7af476ecb4b) and/or onwards. Hope that helps. Sorry David :( -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
