Re: NR: 1.4.1 Replaced deprecated snippet w\ @lilypond (issue60840048)
- Original Message - From: To: ; Cc: ; Sent: Sunday, February 09, 2014 9:35 AM Subject: Re: NR: 1.4.1 Replaced deprecated snippet w\ @lilypond (issue60840048) On 2014/02/08 21:55:15, dak wrote: Is there any way in which one can actually delete this snippet file without getting it carried back in via LSR? According to CG 7.4: "Snippets used in the documentation are in '$LILYPOND_GIT/Documentation/snippets'. This directory contains a complete set of the snippets in the LSR which are tagged with 'docs'." So, you would just need to remove the "docs" tag? My 2 cents? Jean-Charles Correct. Please confirm that this snippet is to be removed from the docs, and I'll do it. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Updating Ubuntu
Still using Ubuntu 10.04 and the update manager is proposing updates to libcurl. I think last time something of this sort happened I lost the ability to connect to lilypond.org via my SSH login: the versions locally and remotely were incompatible. Is this likely to happen again if I accept the updates, and if I did and it did, is there a way of backing them out again? Thanks for any help. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to remove a changed clef glyph from the end of staff line
- Original Message - From: James To: Marc Hohl ; lilypond-devel@gnu.org Sent: Wednesday, February 05, 2014 1:44 PM Subject: Re: How to remove a changed clef glyph from the end of staff line Does that mean that the break-visibility function is broken for clefs or doesn't work now (as opposed to way-back-when) or that the documentation here: I _think_ that what's happening may be that you get the normal clef modifier (which normally comes before the barline where the clef changes) and this appears at the end of the line (i.e. before the bar line) and then you get the normal clef restatement at the start of the line. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Default padding of portato dashes
- Original Message - From: "Urs Liska" To: ; "LilyPond Development Team" Sent: Tuesday, February 04, 2014 12:07 PM Subject: Default padding of portato dashes Hi, I'm so often adjusting the padding of portato dashes (increasing the padding) that I'd like to ask if we should change the built-in default values for that. Opinions? Urs Examples, please? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about the make check tests
Think it's worth putting this up as an Issue, so as not to lose it. -- Phil Holmes - Original Message - From: James To: Phil Holmes Cc: Developers List Sent: Tuesday, January 21, 2014 9:20 PM Subject: Re: Question about the make check tests Hello, On 19 January 2014 11:11, Phil Holmes wrote: - Original Message - From: "James" To: "Developers List" Sent: Saturday, January 18, 2014 8:43 PM Subject: Question about the make check tests Is it worth pursuing? It's not that hard for me to go through each of the .ly files above and find out which reg test it is. But I wanted to check in case these sorts of errors would be expected in the make check phase. James I think it is: it seems to me that we should aim to have all the "make" activities proceed without error. For simple make (especially on 64 bit system) that's probably ambitious. However, I think we should aim for zero errors on make check. Well I went through the 16 .ly files that popped up programming errors in the logs. Of which seven, when compiled directly as a .ly file with current build 2.19.1 of LP didn't show any errors. That left 9 which still did. I have zipped them up and attached them. Each ly file contains the code (obviously) but also the verbose output (cut/pasted from a lilypond --pdf -V command) pasted underneath. I Hope this is useful to someone. James PS just to remind everyone. I simply did a make, make test-baseline and an immediate make check with no changes in between. I also haven't done a convert-ly on these files either (just in case that also needs to be considered). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: Parenthesize error
- Original Message -
From: "Phil Holmes"
To: "Developers List"
Sent: Wednesday, January 22, 2014 4:49 PM
Subject: Parenthesize error
Anyone know why
{ c4 -\parenthesize -\f }
Gives the error "programming error: Don't know how to parenthesize
spanners." but still appears to work?
--
Phil Holmes
Forwarding from another email address.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [THANKS] new spacing/compression warning
- Original Message - From: "Kieren MacMillan" To: "Lilypond-User Mailing List" Cc: "LilyPond Development Team" Sent: Tuesday, January 21, 2014 2:42 PM Subject: [THANKS] new spacing/compression warning Hello all, Just wanted to thank whoever(s) made the new spacing warning read (e.g.,) warning: compressing over-full page by 1.9 staff-spaces warning: page 6 has been compressed This is SO helpful (to me, anyways), as it gives me an exact idea of which pages are compressed, by how much, and whether it’s worth trying to fix the problem. Thank you!!! Kieren. = Worship Keith, I think: http://code.google.com/p/lilypond/issues/detail?id=3281 Fixed 2.19 with a backport to 2.18.1 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about the make check tests
- Original Message - From: "James" To: "Developers List" Sent: Saturday, January 18, 2014 8:43 PM Subject: Question about the make check tests Is it worth pursuing? It's not that hard for me to go through each of the .ly files above and find out which reg test it is. But I wanted to check in case these sorts of errors would be expected in the make check phase. James I think it is: it seems to me that we should aim to have all the "make" activities proceed without error. For simple make (especially on 64 bit system) that's probably ambitious. However, I think we should aim for zero errors on make check. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pre-review questions about image(s) and translations
- Original Message - From: "Urs Liska" To: Sent: Wednesday, January 15, 2014 11:30 PM Subject: Re: Pre-review questions about image(s) and translations Hm, now I see that I can't use a LilyPond example on the website (I mean to let it auto-generate), this works only inside manuals. For comparable images, e.g. the ones on Text Input, I see different localized ones in the pictures folder of lilypond-extra, but no source where they might have been generated from. So the question remains open: How do I provide new images to the website that should be translated? AFAIK there is no facility to translate images for use on the website. Any images that are wanted on the website can be sent to me and I'll add them to lilypond-extra. If it was needed to have translated images, others could be added as imagename-de.png or similar and referenced from the translation. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fixing German's Wikipedia entry of LilyPond
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "Urs Liska" ; "Joram Berger" ; Sent: Monday, January 13, 2014 9:58 AM Subject: Re: fixing German's Wikipedia entry of LilyPond "Phil Holmes" writes: Having spent the time on the Stockhausen, I think it would be a shame not to update the page with the good example. Shouldn't we rather put this up on our own example page, to complement the set there? I think that it would make an excellent addition. As an _only_ example for LilyPond's capabilities, it seems a bit outlandish. I agree that it's disappointing after you put this amount of work into it and that this should have been considered earlier in the discussion. I'm not overworried about that - I did it as an exercise. -- David Kastrup Anyway: http://code.google.com/p/lilypond/issues/detail?id=3803 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fixing German's Wikipedia entry of LilyPond
- Original Message - From: "Phil Holmes" To: "James" ; "Werner LEMBERG" ; "Devel" Sent: Sunday, January 12, 2014 1:32 PM Subject: Re: fixing German's Wikipedia entry of LilyPond - Original Message - From: James To: Werner LEMBERG ; Devel The pedal symbol clashes with the dynamic in bar 3 and there is a clash of a tuplets in the second upper bar with accidentals - which I believe is http://code.google.com/p/lilypond/issues/detail?id=3766 Anyway, I have done as much as I can. Attached the before and after files for anyone else who wants to finish this off. James The pedal / dynamic clash in bar 3 is pretty bad: is this a known bug? -- Phil Holmes Fairly certain the clash is caused by the crossing music. I'm working on an improved version, closer to the version on youtube. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fixing German's Wikipedia entry of LilyPond
- Original Message - From: James To: Werner LEMBERG ; Devel The pedal symbol clashes with the dynamic in bar 3 and there is a clash of a tuplets in the second upper bar with accidentals - which I believe is http://code.google.com/p/lilypond/issues/detail?id=3766 Anyway, I have done as much as I can. Attached the before and after files for anyone else who wants to finish this off. James The pedal / dynamic clash in bar 3 is pretty bad: is this a known bug? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Images on "Introduction" and "Features"
- Original Message - From: "Urs Liska" However, independently from this concrete image: What is the way to add new images to the website/docs? I suppose they somehow have to get into the lilypond-extra repo? Yes, IIRC. I can do that, as can GP. I don't know who else has push access. It always takes me ages to remember how to push to that repo, though. I believe the work flow is that you must get the image into the -extra repo before pushing any changes that would use that image to staging/master. If you do this the other way round, the build of the actual website will fail. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 3.0?
- Original Message - From: "Urs Liska" To: "LilyPond Development Team" Sent: Thursday, January 09, 2014 10:53 AM Subject: 3.0? Please don't beat me up, but that's something I wondered about for quite some time: Is there _any_ notion what a LilyPond 3.0 may be? I mean 2.0 followed on 1.8, and now we're already towards .20 Is there any general idea about what would make the next major program version? Urs Fundamental changes to the approach taken? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Introduction: Rename "Our Goal" box (issue 48430043)
- Original Message - From: "Carl Peterson" To: "Phil Holmes" Cc: "Urs Liska" ; "Lilypond Dev" Sent: Tuesday, January 07, 2014 2:18 PM Subject: Re: Web:Introduction: Rename "Our Goal" box (issue 48430043) On Tue, Jan 7, 2014 at 9:16 AM, Phil Holmes wrote: - Original Message - From: "Urs Liska" I believe I had suggested "purpose." I realize that's not much better than goal/mission, but it's less corporate than "mission," and is more focused on why we exist than what we think we've accomplished (as goal and objective are), in my opinion. Carl P. Yes I recall that. For me this somehow sounds wrong - but again that may be due to my non-native "ear". Phil, what do you think about "purpose"? Urs To me, it's a very uninspiring word. NASA had a goal of landing a man on the moon (http://history.nasa.gov/moondec.html). Its purpose was much more mundane. -- Phil Holmes Would "vision" be better? I realize this will sound to some people as corporate as "mission," but there you go. Sigh. Visions are defined as not achievable - that's the point of them. Please feel free to write to JFK about his poor choice of words. The more I consider it, the better "goal" is. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Introduction: Rename "Our Goal" box (issue 48430043)
- Original Message - From: "Phil Holmes" To: "Urs Liska" ; "Carl Peterson" Cc: "Lilypond Dev" Sent: Tuesday, January 07, 2014 2:16 PM Subject: Re: Web:Introduction: Rename "Our Goal" box (issue 48430043) - Original Message - From: "Urs Liska" I believe I had suggested "purpose." I realize that's not much better than goal/mission, but it's less corporate than "mission," and is more focused on why we exist than what we think we've accomplished (as goal and objective are), in my opinion. Carl P. Yes I recall that. For me this somehow sounds wrong - but again that may be due to my non-native "ear". Phil, what do you think about "purpose"? Urs To me, it's a very uninspiring word. NASA had a goal of landing a man on the moon (http://history.nasa.gov/moondec.html). Its purpose was much more mundane. -- Phil Holmes Found the quote: "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." http://www.jfklibrary.org/JFK/JFK-Legacy/NASA-Moon-Landing.aspx -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Introduction: Rename "Our Goal" box (issue 48430043)
- Original Message - From: "Urs Liska" I believe I had suggested "purpose." I realize that's not much better than goal/mission, but it's less corporate than "mission," and is more focused on why we exist than what we think we've accomplished (as goal and objective are), in my opinion. Carl P. Yes I recall that. For me this somehow sounds wrong - but again that may be due to my non-native "ear". Phil, what do you think about "purpose"? Urs To me, it's a very uninspiring word. NASA had a goal of landing a man on the moon (http://history.nasa.gov/moondec.html). Its purpose was much more mundane. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web:Introduction: Rename "Our Goal" box (issue 48430043)
- Original Message - From: To: Cc: ; Sent: Tuesday, January 07, 2014 10:45 AM Subject: Re: Web:Introduction: Rename "Our Goal" box (issue 48430043) https://codereview.appspot.com/48430043/diff/1/Documentation/web/introduction.itexi File Documentation/web/introduction.itexi (right): https://codereview.appspot.com/48430043/diff/1/Documentation/web/introduction.itexi#newcode14 Documentation/web/introduction.itexi:14: @subheading Our Mission On 2014/01/07 10:17:47, PhilEHolmes wrote: I dislike this intensely. It smacks of corporate nonsense - read the text that large conglomerates have under "Our mission". Please leave it as goal, or something similar and non-corporate. Too bad you didn't notice that in one of my earlier suggestions... I did, but was not sure what you were proposing to change, as opposed to just making suggestions. I don't like the "Goal" because it sounds too much like something unachieved. Any other suggestions? "Our goal" :-) No less achieved than a mission. https://codereview.appspot.com/48430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: Merge conflict
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "Devel" Sent: Sunday, January 05, 2014 2:46 PM Subject: Re: Fw: Merge conflict "Phil Holmes" writes: ----- Original Message - From: "Phil Holmes" To: "Devel" Sent: Sunday, January 05, 2014 12:19 PM Subject: Merge conflict I'm trying to create a 2.19.0 build and running into merge conflicts. Following the CG, I've done: git fetch git checkout release/unstable git merge origin/master This creates a number of merge conflicts: changes.tely is an obvious one. Is there something that can be simply done to sort the conflicts out? -- Phil Holmes Forwarding from a different email address. Well, we released 2.17.97 from the stable branch, but the release process still used release/unstable. It has a number of reverts in it compared to the unstable branch. We don't want _any_ of that in 2.19.0. We basically have two options: a) reset release/unstable and recreate it from scratch That had been what I thought easiest and most sensible, once I'd spent a bit longer thinking. [snip] So I think I'll just bump release/unstable to master. And then you can do git fetch git checkout release/unstable git reset --hard origin/release/unstable git merge origin/master # should be a noop or fast forward and then continue from there. -- David Kastrup Thanks. Willdo. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: Merge conflict
- Original Message - From: "Phil Holmes" To: "Devel" Sent: Sunday, January 05, 2014 12:19 PM Subject: Merge conflict I'm trying to create a 2.19.0 build and running into merge conflicts. Following the CG, I've done: git fetch git checkout release/unstable git merge origin/master This creates a number of merge conflicts: changes.tely is an obvious one. Is there something that can be simply done to sort the conflicts out? -- Phil Holmes Forwarding from a different email address. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc - English only?
- Original Message - From: "Urs Liska" To: "LilyPond Development Team" Sent: Saturday, January 04, 2014 8:04 AM Subject: Make doc - English only? Is there a way to make doc without transltations? When working on the website I use make WEB_LANGS='' website, but is there an equivalent for the docs? I know I don't need that for development (while working I generate individual sections, and for checking one _does_ need the translations. But it would be nice to have a local doc (like the "doc tarball") but English only. Anyway, I just realized that I don't need to download these huge tarballs anymore since I can build the docs myself from Git :-) Urs -- Urs Liska openlilylib.org http://lilypond.org/doc/v2.17/Documentation/contributor/generating-documentation -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
- Original Message - From: "Kieren MacMillan" To: "Lilypond-User Mailing List" Cc: "Lilypond Dev" Sent: Friday, January 03, 2014 4:24 PM Subject: when is 2.19 going to be released? Hello all, Now that 2.18 has been released (kudos, by the way!!!), when is the unstable branch going to be updated? I like to be on the bleeding edge… ;) Thanks, Kieren. ___ Well, you need to compile your own version then :-) Unless anyone complains, probably this weekend. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Announcing 2.18.0 widely?
- Original Message - From: "Trevor Daniels" To: "David Kastrup" ; Sent: Thursday, January 02, 2014 3:37 PM Subject: Re: Announcing 2.18.0 widely? BTW, are the number of downloads recorded anywhere? It would be interesting to track this for stable releases. Google analytics should track this. If you can persuade GP to log in and check.... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building Lilypond documentation
AFAICS it will be complaining about the directory below where the logfile is found. -- Phil Holmes - Original Message - From: Sven Axelsson To: lilypond-devel@gnu.org Sent: Thursday, January 02, 2014 11:29 AM Subject: Building Lilypond documentation I've decided to get at least a little active in Lilypond development, and thought I should start with getting my development environment up and running. I get some weird errors when building the different doc targets, such as: make[4]: Entering directory `/lilydev/build/input/regression/lilypond-book' /lilydev/./input/regression/lilypond-book/GNUmakefile:24: warning: overriding commands for target `out-www/collated-files.list' /lilydev/./make/lysdoc-rules.make:6: warning: ignoring old commands for target `out-www/collated-files.list' make[4]: Circular out-www/collated-files.list <- suffix-tely.tely dependency dropped. make[4]: Circular out-www/collated-files.list <- texinfo-include-file.tely dependency dropped. make[4]: Circular out-www/collated-files.list <- texinfo-include-language-detection.tely dependency dropped. make[4]: Circular out-www/collated-files.list <- texinfo-language-detection.tely dependency dropped. make[4]: Circular out-www/collated-files.list <- texinfo-musicxml-file-options.tely dependency dropped. make[4]: Circular out-www/collated-files.list <- texinfo-musicxml-file.tely dependency dropped. make[4]: Circular out-www/collated-files.list <- texinfo-papersize-docs.tely dependency dropped. make[4]: Circular out-www/texinfo-include-file.texi <- texinfo-include-file.tely dependency dropped. make[4]: Circular out-www/texinfo-include-language-detection.texi <- texinfo-include-language-detection.tely dependency dropped. make[4]: Circular out-www/texinfo-language-detection.texi <- texinfo-language-detection.tely dependency dropped. make[4]: Circular out-www/texinfo-musicxml-file-options.texi <- texinfo-musicxml-file-options.tely dependency dropped. make[4]: Circular out-www/texinfo-musicxml-file.texi <- texinfo-musicxml-file.tely dependency dropped. make[4]: Circular out-www/texinfo-papersize-docs.texi <- texinfo-papersize-docs.tely dependency dropped. /lilydev/build/scripts/build/out/run-and-check "DEPTH=../../.. AJAX_SEARCH= TOP_SRC_DIR=/lilydev PERL_UNICODE=SD texi2html --error-limit=0 --I=/lilydev/input/regression/lilypond-book --I=./out-www --I=/lilydev/build/./out-www/xref-maps --init-file=/lilydev/Documentation/lilypond-texi2html.init --output=out-www/suffix-tely.html out-www/suffix-tely.texi" "suffix-tely.texilog.log" Please check the logfile suffix-tely.texilog.log for errors And "suffix-tely.texilog.log" contains "*** out-www/ not writable". Not sure which one of the many out-www folders that is referring to, but they are all writable as far as I can see. I am probably missing something simple here. I'd appreciate if someone can give me a hint. Thanks -- Sven Axelsson ++[>++>+++>++>++ ><<<<<-]>.+..>+.>+.<<-.>>+.>.<<. +++.>-.<<++.>>.<++.>>>++.<<<<.>>.<. -- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: "Jean-Charles Malahieude" To: "Urs Liska" ; "Phil Holmes" ; Sent: Wednesday, January 01, 2014 5:50 PM Subject: Re: contributing instructions are misleading! Le 01/01/2014 18:07, Urs Liska disait : Am 01.01.2014 18:02, schrieb Phil Holmes: - Original Message - From: "Urs Liska" But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? I compile on native Fedora. I don't know by how would be multiplied a 90 minutes "make -j3 && make -j3 doc" on my dual-core with 2gigs RAM when launched in a VM. Happy new year, Jean-Charles I can "make doc" in a VM in under 15 minutes. It depends on the architecture of the native CPU. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Content of "Introduction"->"Our Goal"
- Original Message - From: "Urs Liska" To: "LilyPond Development Team" Sent: Wednesday, January 01, 2014 5:03 PM Subject: Content of "Introduction"->"Our Goal" [snip] I think the sentence could be: "The result is a system which frees composers from the details of layout, allowing them to focus on creating music." and would be completely clear. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: "Urs Liska" To: "Phil Holmes" ; Sent: Wednesday, January 01, 2014 5:07 PM Subject: Re: contributing instructions are misleading! Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. Is that true? Most Lilypond devs work in a VM? As David points out, I didn't say that - merely that many do; so you are just about guaranteed support if you take this route. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: "Urs Liska" To: Sent: Wednesday, January 01, 2014 4:41 PM Subject: Re: contributing instructions are misleading! That's a point I'd like to say something about. The CG's insistence on Lilydev can be somewhat offputting. I didn't think I'd need Lilydev and wasn't keen on installing a virtual machine only to run a (presumably outdated) Ubuntu inside an up-to-date Linux. I don't understand this at all. VMs are superb ways of running any number of different environments on the same desktop, at no risk whatever. FWIW all the current lilypond "release" builds are done on a VM, since GUB won't run on my 64 bit environment. Why the antipathy to VMs? But you're led to believe that LilyDev is the canonical environment for working on LilyPond, and if you dare to go another route you'll be on your own and heading for trouble. Well - since you're the only one running your specific environment, that's generally true. With a VM that many of us run, it's not. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about Snippets new vs LSR
- Original Message - From: "James" To: "Phil Holmes" ; "Developers List" Sent: Friday, December 20, 2013 12:29 PM Subject: Re: Question about Snippets new vs LSR On 20/12/13 10:45, Phil Holmes wrote: - Original Message - From: "Pkx" To: "Developers List" So I have a tracker issue that recommends changing a snippet that comes from the LSR but with a syntax that won't work with the current version of LP in the LSR (which I think is 2.14.something right?). So in that case if I create a new snippet, what do I do with the snippet already created? Delete it, or just remove it from the ref in the NR (where the example is) and give the new snippet a different name? Ignore it. When makelsr.py is run, it first converts the snippets in Documentation/snippets and then works on Documentation/snippets/new, thus overwriting any in Documentation/snippets with any new version. So your new snippet has to go in Documentation/snippets/new I haven't done snippets for a while so have forgotten and the CG is not clear in the matter. James Hope that's clear. I think so. 1. Keep the same file name 2. Put in Snippets/new - which then forces an overwrite of the old snippet with the same filename Yep. With regard to the patch, I guess I git-cl upload with *just* the patch but I have to test the patch with makelsr.py run on my local tree so that it really tests the make-doc? You can certainly do this, and the run of makelsr and make doc after making the patch should also be done, to be safe. Then when I push, I push it with the makelsr.py or do I push and then makelsr.py and then push that as a separate patch? Either. If you simply upload the patch as created without makelsr, it's one of my jobs (which I'm often rather lax about) to run makelsr and get the updates into the docs. Oh... one more. If I overwrite the snippet that will no longer work in the version that LSR uses, I assume we don't 'push' that snippet up to the LSR and break something there? Correct. If we ever manage to update the LSR, myself Thomas and David N would probably be persuaded to push the updated versions into the LSR. That's a bit of a game, though. Thanks again. James -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Question about Snippets new vs LSR
- Original Message - From: "Pkx" To: "Developers List" So I have a tracker issue that recommends changing a snippet that comes from the LSR but with a syntax that won't work with the current version of LP in the LSR (which I think is 2.14.something right?). So in that case if I create a new snippet, what do I do with the snippet already created? Delete it, or just remove it from the ref in the NR (where the example is) and give the new snippet a different name? Ignore it. When makelsr.py is run, it first converts the snippets in Documentation/snippets and then works on Documentation/snippets/new, thus overwriting any in Documentation/snippets with any new version. So your new snippet has to go in Documentation/snippets/new I haven't done snippets for a while so have forgotten and the CG is not clear in the matter. James Hope that's clear. _______ -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: .bib files in our Web/Doc pages - how to edit?
- Original Message -
From: "James"
To: "Developers List"
Sent: Monday, December 16, 2013 9:28 PM
Subject: .bib files in our Web/Doc pages - how to edit?
Hello,
I'd like to add our Turkish Professor's book to the Publications and am
unsure about the syntax/format of the syntax.
So for example one entry that exists is:
@inproceedings{reinhold01,
title = {OrchestralLily: A Package for Professional Music Publishing
with LilyPond and LATEX},
author = {Reinhold Kainhofer},
booktitle = {The Linux Audio Conference 2010 (LAC2010)},
year = 2010,
note = {(@uref{http://lilypond.org/website/pdf/reinhold-LAC-2010.pdf,
PDF 767k})}
}
While most of it is self explanatory I don't understand the format of the
author as it appears at the start of the entry:
@inproceedings{reinhold01,
...
}
Is there some convention that I need to use?
Also just to check, I could not find that these .bib files were generated
from some other source (like an Appendix for instance) but they are the
'root' files that I would edit?
Thanks
James
What Urs said. It is the .bib files you edit. I know you will, but do be
sure to do a full make doc and check the entry is there - I _think_ it
should work, but best to be safe.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual->Web
- Original Message - From: "Urs Liska" To: "Phil Holmes" ; "David Kastrup" Cc: "Graham Percival" ; "LilyPond Development Team" Sent: Monday, December 16, 2013 11:26 AM Subject: Re: Website questions: Manual->Web Am 14.12.2013 12:20, schrieb Phil Holmes: - lilypond.org/web/ : the old website What is this old stuff good for? Confusing search engines into misleading people there seems to be its main purpose nowadays. It's not totally clear whether it has other functions at the moment that could disrupt the regular operations when removed. -- David Kastrup http://code.google.com/p/lilypond/issues/detail?id=1272 Does this mean we can expect the old web to disappear in the foreseeable future? Urs Next summer, unless someone else does or I get some surprise free time. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tweet or http://lilypond.org/productions.html
- Original Message - From: "James" My only issue with the pondings is it looked like there was some more 'syntax' I had to learn for the xml stuff. I can handle tags but the other special character stuff looked tiresome. I think you have to escape special characters: > for example. https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references is a rather more exhaustive list... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tweet or http://lilypond.org/productions.html
- Original Message - From: "James" To: "Devel" Sent: Sunday, December 15, 2013 1:29 PM Subject: tweet or http://lilypond.org/productions.html Hello, I tried to look back on the old discussions when we set up the Pondings and I am not sure where the tweet/web line should be drawn (if it should be drawn at all). That is the tweet is I assume going to be rather ephemeral whereas the website is going to be around for a while in terms of being search-able. So for example David K added a Ponding recently: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=49eb1b3eab84975c67613986c65f60f731c9818b Which is great but I see no reason why this would not be better served in the 'productions' part of the website. Are there any strong opinions? James Broadly, I think the Pondings are for what are essentially adverts for new or upcoming things. The website is for something we endorse and are proud of. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048)
- Original Message - From: "David Kastrup" To: "Carl Peterson" Cc: "James" ; "Lilypond Dev" ; "Phil Holmes" Sent: Saturday, December 14, 2013 2:27 PM Subject: Re: Enable manual-specific styling of documentation; issue 3714 (issue 36480048) Carl Peterson writes: On Sat, Dec 14, 2013 at 1:50 AM, James wrote: On 14/12/13 05:57, Carl Peterson wrote: I have updated the patch in Rietvald But not the tracker. So the patch will not get tested. Please remember to either use git-cl or change the tracker to patch-new whenever you make a change in Rietveld, we need to make sure that and new patch doesn't break anything in current master no matter how innocuous you think the changes are. I am using git-cl. However, I think that there's an error message popping up saying that it can't edit the issue tracker. That may be since I'm not a project member on the Google Code site. Uh, yes. Phil? -- David Kastrup Added. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual->Web
- Original Message - From: "David Kastrup" To: "Urs Liska" Cc: "Graham Percival" ; "Phil Holmes" ; "LilyPond Development Team" Sent: Saturday, December 14, 2013 10:04 AM Subject: Re: Website questions: Manual->Web Urs Liska writes: Am 14.12.2013 05:01, schrieb Graham Percival: On Fri, Dec 13, 2013 at 03:40:03PM -, Phil Holmes wrote: I _think_ the odd place of "web" in the manuals hierarchy is down to it being the only part of the documentation that built using "make website" - it has something of a split personality between being part of the documentation and the website. No, there's three separate issues here. - lilypond.org/web/ : the old website What is this old stuff good for? Confusing search engines into misleading people there seems to be its main purpose nowadays. It's not totally clear whether it has other functions at the moment that could disrupt the regular operations when removed. -- David Kastrup http://code.google.com/p/lilypond/issues/detail?id=1272 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website questions: Manual->Web
- Original Message - From: "Urs Liska" To: "LilyPond Development Team" Sent: Thursday, December 12, 2013 8:34 PM Subject: Website questions: Manual->Web I've raised this issue already, but I think it needs to be considered in its own thread: What to do with Manuals->Web? When I go there I can download the whole website as a PDF. OK, this makes sense. Getting it as one big HTML page also makes sense. [but where can I get it in info format?) But clicking on "Web (split HTML)" brings you to a copy of the whole website, just several directories below the original. This is irritating, to say the least. If this page is there for the first two items I mentioned the text in the left box should definitely be clarified. Currently this "manual" leads the reader to believe that he gets yet one more manual, with some general information. Are there more purposes to that page than providing the PDF and Big HTML versions of the website that I don't see? And there is one more thing I stumbled over (although I don't find an instance of it right now): There are links from within the "real" manuals that seem to link to the website but actually point to that "web" manual (i.e. pages below lilypond.org/doc/2.17/web). If there isn't a point I didn't see so far I tend to suggest: - Completely rewrite the "Web" box on "Manuals->Web" - Clarify the "Read it" box and remove the link to "Web (split HTML) Does someone have any enlightenment available for me? Urs I _think_ the odd place of "web" in the manuals hierarchy is down to it being the only part of the documentation that built using "make website" - it has something of a split personality between being part of the documentation and the website. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
- Original Message - From: "Carl Sorensen" To: "Phil Holmes" ; "Carl Peterson" Cc: "Lilypond Dev" Sent: Friday, December 13, 2013 3:31 PM Subject: Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048) On 12/13/13 6:04 AM, "Phil Holmes" wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. I just did a google search for "google issue tracker quota". Most of the items that show up are requests for quota increases; as far as I can see none has been turned down. I think we should just go ahead and ask for an increase in the quota; I expect they will grant it to us. Thanks, Carl == I do, whenever we're running out. It's just easier not to have to. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
- Original Message - From: "Carl Peterson" To: "James" Cc: "Lilypond Dev" Sent: Friday, December 13, 2013 2:01 PM Subject: Re: Enable manual-specific styling of documentation;issue 3714(issue 36480048) On Fri, Dec 13, 2013 at 8:31 AM, James wrote: On 13/12/13 13:04, Phil Holmes wrote: Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. Sorry about that. I'll delete the comment once I've had a chance to make edits to the CSS file and produce new examples. Unfortunately, deleting them does not remove them from the quota, either! Best to leave them now. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048)
Thanks for what you're doing, but please don't put a lot of images on the Google Issue tracker. For bizarre reasons only known to themselves, the storage available for attachments is _very_ limited. By accident you've just used about 1/25 of our remaining quota. -- Phil Holmes - Original Message - From: Carl Peterson To: Carl Peterson Cc: Lilypond Dev Sent: Thursday, December 12, 2013 10:58 PM Subject: Re: Enable manual-specific styling of documentation; issue 3714(issue 36480048) On Thu, Dec 12, 2013 at 1:06 AM, wrote: Message: Patch for initial solution to issue 3714, regarding color-coding of manuals. Please review this at https://codereview.appspot.com/36480048/ I have submitted follow-up patches to Rietveld to address comments regarding the duplicate CSS definitions. I also found where a change to simplify the manual-specific definition caused a problem with the "default" color choices (when a specific color set has not been defined), and have corrected this. For those who need a visual of these changes, I've uploaded screenshots to the Google Code issue. https://code.google.com/p/lilypond/issues/detail?id=3714. Regards, Carl P. -- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
- Original Message - From: "Werner LEMBERG" To: Cc: ; ; Sent: Tuesday, December 10, 2013 9:43 AM Subject: Re: anyone notice speed of 2.17.95 on Windows ? \faster-but-uglier \a-lot-faster-but-a-lot-uglier \ridiculously-fast-and-heinously-ugly :-) With some serious names, this could be quite useful. TBH I potentially wouldn't use them. When I benchmarked with and without skylines, I found there was only a noticeable difference with a lot of markup or similar: "normal" music had almost no effect. As a result, I concluded with skylining was the correct default. However, an option similar to \pointAndClickOff would be simple and could be handy: it could include a number of sensible attempted speed ups. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.17.97 upload
The way uploads of binaries works, is that we (i.e. me) upload them to the lilypond.org website, and then I presume a cron job on linuxaudio.org copies them to their server, which presumably has fewer restrictions in terms of bandwidth. I've checked, and the latest binaries are on the lilypond.org server, so it appears that the copying over step has failed. I have no control over this, other than an email to the admins. It would clearly be possible to download them from lilypond.org - the URL is in the clear to work out. I'm loathe to publicise it, though, in case we kill the internet connection of the server. Any thoughts? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updates of .po files from FTP
- Original Message - From: "David Kastrup" To: "Jean-Charles Malahieude" Cc: "lilypond-devel" ; "Phil Holmes" Sent: Sunday, December 08, 2013 9:19 AM Subject: Re: updates of .po files from FTP David Kastrup writes: Jean-Charles Malahieude writes: Le 07/12/2013 13:16, David Kastrup disait : Jean-Charles Malahieude writes: Hi David, I've downloaded updated files from the FTP and created a patch to be applied on branch stable/2.18. Wouldn't those be better applied to translation and then merged into both stable/2.18 and master from there? Or have the .po files already diverged? Since translation branch is at 2.17.95, which is behind stable, a merge should be done before applying to translation? I see. I'll check what to do here. Phil, don't you update the PO files as part of a release anyway? Does the patch by Jean-Charles do anything differently? -- David Kastrup As part of the build process, I do this: make -C $LILYPOND_BUILD_DIR po-replace mv $LILYPOND_BUILD_DIR/po/lilypond.pot po/ TBH I have no idea what that actually does... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
- Original Message - From: "Janek Warchoł" To: "LilyPond Development Team" Sent: Saturday, December 07, 2013 5:15 PM Subject: contributing instructions are misleading! hi, i'm infuriated. A new contributor had turned up, read CG and sent his patch to the "frogs" mailing list, which, as far as i know, is dead (and since lilynet is down, i'm not sure it's actually working at all). This is absolutely unacceptable. Not only is our contributing process complicated, but the instructions we give are misleading! I'm so angry that I'll actually go through the CG and update the instructions right now, and will push directly to staging. I don't want to waste time on discussions this time, and i dont' actually have time to go through formal review. Any comments and adjustments are welcome - please just send follow-up patches. If anyone doesn't like what i'm going to do, please protest swiftly. best, Janek The CG is developer material. Feel free to correct it and push to staging _if_ you've checked it with a full make _and_ a make doc. I frequently do. If you can't check with make/make doc, create a patch and let James test it and then push without countdown. Remember, it's only wrong because you, me, David and everyone else who contributes didn't notice it and correct it. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A thought on Windows Experience (was: useability, promoting, etc)
- Original Message - From: "Francisco Vila" To: "LilyPond-User list" ; "LilyPond-Devel list" Sent: Wednesday, December 04, 2013 5:24 PM Subject: A thought on Windows Experience (was: useability, promoting, etc) Warning. I this message, "Why don't we" does not mean "do it, you slave". It means just asking "do you think it's a worthwhile idea?" The thread about usability and promoting has forked too much and my thoughts are somewhat related to both. I am crossposting to hear users feedback also, sorry for that. I keep seeing newcomers double-clicking the LilyPond icon on the desktop despite of our warnings about not to do that. LaTeX is also just a typesetting engine and people do not try to work with it by first clicking on a desktop icon, do they? I don't really know what's the Windows LaTeX experience like, but I can assume the user base of LaTeX is far greater than LilyPond's, and newcomers have always an experienced user in the nearby ready to help. That's the "critical mass" effect that Finale and Sibelius already have and we don't. Despite of having a README just in front of your eyes, IMO we should expect people will always try to "open lilypond" to work in a typical program window. Why don't we just give them what they want? That is: a program you open. All programs are "opened" and it doesn't matter how hard we try, most people want to open the program. We could make the lilypond icon to launch a shell applet to open ly projects and a button to compile. Of course, a console output window and a PDF pre-viewer are necessary. I see the drag-drop ritual in the tutorial too few standard, too weird and too much lilypond-specific. That scares newcomers. But wait: this has been done. Valentin Villenave dit it once. A bundle that installed a PDF viewer and a small button panel with all the most basic operatons. I don't remember if it included a message output. But wait again: Frescobaldi already does this. It is super-easy to install on windows and it has got all the necessary items: an editor, a pre-viewer and a message output panel. Of course it has many, many more features, but even so it is lightweight (unlike the now almost defunct jEdit/lilypondtool). Why don't we do a cut-down Frescobaldi-like shell for the absolute beginner? The File->Open... menu entry must include a sub-menu with a lot of ready_to_compile fancy or real-world examples. Yes, we already promote easier environments, but in my opinion the bare minimum we offer is too weak as to be useful for all except mid-high level nerdies. I always think all you do to lower the entry threshold is never enough and ours is currently a bit too high. It's not the language, it's the experience. And never forget Windows users are potentially way more numerous than command line users. For me, I'd say that we should not install Frescobaldi as a pre-requisite of running Lily on Windows. I'm a heavy Windows user, and would not want another program installed by default. I've not used it, but I do understand that many people feel it's excellent - so an option would be to promote it more heavily for Windows users? I am willing to look at improving the Windows experience, although this would need to wait until my degree finishes next Summer. However, there's one thing I don't know: what should happen when you double-click a .ly file in Explorer: open an editor or compile the file? And if the former, how should the file be compiled? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tag for 2.17.96 is missing in git
- Original Message - From: "Werner LEMBERG" To: Cc: ; Sent: Sunday, December 01, 2013 3:53 PM Subject: Re: tag for 2.17.96 is missing in git Hmm. So why do we have commit 9918cd9f8d8f5461c6ad7e086fd93de59960eb95 Author: Phil Holmes Date: Sun Nov 24 22:05:16 2013 + Release: bump VERSION. in the `master' branch? This looks incorrect to me, given that we currently derive 2.17.9X tarballs from the `stable' branch, right? VERSION is out of step on master and stable, so needs bumping separately on each. But I think we must not use 2.17.9X for the `master' branch! Such tags should be only used on `stable'. It's totally confusing if a developer reports a problem with, say, 2.17.97, and we have to ask `on stable or on master?'... IMHO, releases from `master' should use 2.19.XX. Then we can add proper tags also so that e.g. `git describe' returns meaningful results. This is the version of VERSION on master: PACKAGE_NAME=LilyPond MAJOR_VERSION=2 MINOR_VERSION=19 PATCH_LEVEL=0 MY_PATCH_LEVEL= VERSION_STABLE=2.16.2 VERSION_DEVEL=2.17.96 This is the version on stable/2.18: PACKAGE_NAME=LilyPond MAJOR_VERSION=2 MINOR_VERSION=17 PATCH_LEVEL=97 MY_PATCH_LEVEL= VERSION_STABLE=2.16.2 VERSION_DEVEL=2.17.96 So any builds made from master will be version 2.19.0 - the VERSION_DEVEL is only used for text entries on the website, I believe. Builds from stable/2.18 will be version 2.17.97. So I think it's right that the tag for 2.17.96 is also in stable/2.18? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tag for 2.17.96 is missing in git
- Original Message - From: "Werner LEMBERG" To: Cc: Sent: Sunday, December 01, 2013 3:23 PM Subject: Re: tag for 2.17.96 is missing in git Forget that: it seems that the tag already exists, it's just not present on the master branch (because it's in the stable branch): 050744bbb706525840a3014cd72b06fde945fa4d OK. Yes, I have it here as well. Hmm. So why do we have commit 9918cd9f8d8f5461c6ad7e086fd93de59960eb95 Author: Phil Holmes Date: Sun Nov 24 22:05:16 2013 + Release: bump VERSION. in the `master' branch? This looks incorrect to me, given that we currently derive 2.17.9X tarballs from the `stable' branch, right? Werner VERSION is out of step on master and stable, so needs bumping separately on each. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tag for 2.17.96 is missing in git
- Original Message - From: "Werner LEMBERG" To: Sent: Sunday, December 01, 2013 6:42 AM Subject: tag for 2.17.96 is missing in git Please add a tag for the 2.17.96 release! That's strange - I did the release as close to the standard way as I could, and the release process normally adds a tag automatically. Could someone with more git knowledge than me do this, please? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LILY-GIT PITA
- Original Message - From: "James" To: "Devel" Sent: Wednesday, November 27, 2013 9:05 PM Subject: LILY-GIT PITA Hello, Am i the only one using lily-git.tcl of the *active* dev team? I ask because since it was changed a couple of years or so ago that it *always* assumes you want/need to be on dev/local_working it really makes it a PITA for me to work with. I've been trying to make a simple patch this evening to a separate branch stable/2.18 for one minor tely file and I then forget that I can then no longer just make 3 clicks and patch, no matter where I am. I have do some stuff I have no idea how to do to merge or rebase or branch or some such stuff just to get a patch formed. I've managed to screw up my LILYPOND_GIT dir twice now - headless with merge conflicts on a load of files I have not even any interest in. It's wasted time (and it is a wasted because I have learned nothing doing this) and end up restoring my *whole LilyDev VM* just to get a clean set of trees. Yes I can just download the source only but then I have to screw about with my git config and ssh and all that jazz and it's just easier to restore a VM from a backup frankly and then pull. If I am the only one using this tcl utility - and I think I am. Can someone just put it back so that it can create a patch and amend existing commit based on the branch I am on *now* not what it thinks I should be on? It really has put me off making any more doc contributions because I end up having to relearn all the git cli each time as I don't live and breathe git and the instructions in the CG assume some broad knowledge that I don't have. It's become a game of luck as to whether I end up with a patch or a borked tree. I don't develop separate branches and those that are skilled enough to do that don't use Lily-git.tcl. I used to be a big lily-git user, but now rarely do. That's not because I found it messed me about, but because I learnt enough not to need it. I've learnt the git commit syntax and the git patch syntax (generally git format-patch origin/master, iirc) well enough not to need it. So if there are problems with it, they don't hit me, I'm afraid. I also find gitk is my friend. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Repeats starting and ending in mid-bar?
- Original Message - From: "David Kastrup" To: Sent: Sunday, November 17, 2013 2:57 PM Subject: Repeats starting and ending in mid-bar? Hi, I'm occasionally repondering the barline |: :| issue and I want to know if anybody's music typesetting theory text or private music library has examples of repeats starting and/or ending in mid-bar. I seem to remember that there is some weakened double bar in use for that, something like ||: :|| instead of the current .|: :|. (according to our notation). Do I remember right? -- David Kastrup Gould only uses the colon; thin line; thick line; style of repeat, whether it's a bar line or not. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More verbose doc build
- Original Message - From: "Joseph Rushton Wakeling" To: Sent: Sunday, October 27, 2013 3:54 PM Subject: More verbose doc build Hello all, The building of the various manuals takes quite a long time, but the build process itself is silent so it's not easy to tell if they're actually progressing or have somehow hung. e.g. currently I'm just seeing: LILYPOND_VERSION=2.17.29 /usr/bin/python -tt ../scripts/lilypond-book.py -I . -I ./out-www -I /home/joseph/code/lily/pond/Documentation/snippets/out -I /home/joseph/code/lily/pond/Documentation/included -I /home/joseph/code/lily/pond/Documentation/pictures -I /home/joseph/code/lily/pond/Documentation -I /home/joseph/code/lily/pond/input/regression --process='/home/joseph/code/lily/pond/out/bin/lilypond -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlezh --header=texidoc --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2' --output=./out-www --format=texi-html --loglevel=WARN --info-images-dir=lilypond --lily-output-dir /home/joseph/code/lily/pond/out/lybook-db --redirect-lilypond-output learning.tely ... and no change, despite the fact that top reveals various changes of different tools being called. Is there a way to get slightly more verbose output? Thanks & best wishes, -- Joe make -v will give you a heck of a lot of output, although there are some very long processes that may still be silent. I've done hundreds of doc builds and never seen it hang. Best is to go make a cup of coffee. You can also check CPU usage. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Linux Audio link to 'Lilypond'
- Original Message - From: "James" To: "Phil Holmes" ; "Devel" Sent: Sunday, October 20, 2013 1:21 PM Subject: Re: Linux Audio link to 'Lilypond' On 20/10/13 12:53, Phil Holmes wrote: - Original Message - From: "James" To: "Devel" Sent: Sunday, October 20, 2013 12:40 PM Subject: Linux Audio link to 'Lilypond' Hello, Is anyone who 'manages' the Linuxaudio website (or anyone who knows anyone from it) able to explain if I click http://linuxaudio.org/members Then look for LilyPond Software Design Support, custom development and maintenance for the LilyPond music typesetter Then click on the link I get taken here: http://www.lilypond-design.com/ - which is a 'this URL is available to buy' site. Maybe there is some 'history' and this URL was owned by one of the current/older devs but no longer, but I've never really understood the relationship (if there is one) between the linuxaudio site and lilypond in general other than a place to host our binaries. Is it more apt to get the link to point to our lilypond.org site or am I missing something? James My understanding is that, for us, the sole purpose of the LinuxAudio site is as one with a high bandwidth internet connection that is therefore suitable for hosting our large downloads. I'm guessing that the LilyPond Software Design site used to be one where there could be something like additional support for lily - typesetting maybe? and it's now fallen into disuse. If you think it's important I could contact the maintainer of the site? -- Phil Holmes It's not a huge deal, although we did talk about getting LilyDev3 up there didn't we as it is nigh on now 1.8GB in size. James I discussed lilydev3 with GP - he thinks it's too big for LinuxAudio, and for testing purposes it would be best to appeal for a hoster on -user. I assume that's a compressed size? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Linux Audio link to 'Lilypond'
- Original Message - From: "James" To: "Devel" Sent: Sunday, October 20, 2013 12:40 PM Subject: Linux Audio link to 'Lilypond' Hello, Is anyone who 'manages' the Linuxaudio website (or anyone who knows anyone from it) able to explain if I click http://linuxaudio.org/members Then look for LilyPond Software Design Support, custom development and maintenance for the LilyPond music typesetter Then click on the link I get taken here: http://www.lilypond-design.com/ - which is a 'this URL is available to buy' site. Maybe there is some 'history' and this URL was owned by one of the current/older devs but no longer, but I've never really understood the relationship (if there is one) between the linuxaudio site and lilypond in general other than a place to host our binaries. Is it more apt to get the link to point to our lilypond.org site or am I missing something? James My understanding is that, for us, the sole purpose of the LinuxAudio site is as one with a high bandwidth internet connection that is therefore suitable for hosting our large downloads. I'm guessing that the LilyPond Software Design site used to be one where there could be something like additional support for lily - typesetting maybe? and it's now fallen into disuse. If you think it's important I could contact the maintainer of the site? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB failing
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "Heikki Tauriainen" ; "Devel" Sent: Sunday, October 20, 2013 11:47 AM Subject: Re: GUB failing "Phil Holmes" writes: I'm getting the following when trying to compile a GUB build: /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/midi-item.cc: In member function 'virtual std::string Midi_control_function_value_change::to_string() const': /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/midi-item.cc:403: error: 'lround' was not declared in this scope make[1]: *** [out/midi-item.o] Error 1 I assume it's something to do with the midi pan changes, and is a compiler incompatibility between the GUB and normal compilers, but I don't know how to fix it. It would seem it will need an update to midi-item.cc. lround is part of the C99 standard. For one thing, we are using C++ rather than C, for another, we don't rely on standards as new as that. -- David Kastrup So will we have to wait for Heikki to provide a fix, or are you able to fix it yourself? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB failing
I'm getting the following when trying to compile a GUB build: /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/midi-item.cc: In member function 'virtual std::string Midi_control_function_value_change::to_string() const': /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/midi-item.cc:403: error: 'lround' was not declared in this scope make[1]: *** [out/midi-item.o] Error 1 I assume it's something to do with the midi pan changes, and is a compiler incompatibility between the GUB and normal compilers, but I don't know how to fix it. It would seem it will need an update to midi-item.cc. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.18 schedule/incoming issues
- Original Message - From: "David Kastrup" To: Sent: Saturday, October 12, 2013 5:12 PM Subject: 2.18 schedule/incoming issues Ok folks, I am currently swamped: we recently had an influx of near-trivial documentation bugs/requests that would warrant attention. There are also smaller bits and pieces, but here is the beef on the 2.18 situation: I would think that the best thing is for you to concentrate on the issues that might currently prevent 2.18 being ready to go. Your work on fixing issues as they arrive is admirable, but (AFAIK) has not been our normal process - rather we have ensured that the bug is in the tracker and then left it until someone picks it up at some point in the future. This might be less responsive for users, but it's the way it is. You could even stop monitoring -user for a while - there's no requirement for devs to monitor that list, and many of the users are good enough to answer questions as they arise there - that would allow you to focus more clearly on cleaning up the code ready for a 2.18 release. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
- Original Message - From: "Jean-Charles Malahieude" To: "lilypond-devel" Sent: Saturday, October 05, 2013 3:32 PM Subject: Fedora and mpost Hi all! Since Fedora's version of mpost is 1.802, I'm now unable to build LilyPond from scratch, and have not the resources to rebuild the Texlive package in order to upgrade. Is there any workaround other than locally revert Julien's commit? TIA, Jean-Charles Could you use a virtual machine? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3572: convert-ly should produce several backup files for eachinvokation (issue 14383044)
- Original Message - From: To: Cc: ; Sent: Friday, October 04, 2013 9:05 PM Subject: Issue 3572: convert-ly should produce several backup files for eachinvokation (issue 14383044) Reviewers: , https://codereview.appspot.com/14383044/diff/1/Documentation/usage/updating.itely File Documentation/usage/updating.itely (right): https://codereview.appspot.com/14383044/diff/1/Documentation/usage/updating.itely#newcode172 Documentation/usage/updating.itely:172: @item -h,--help Actually, where is the point in deleting those spaces? It's not done for -l, and cross-checking with GNU tools shows that their help messages offset the long option forms with a space. So what gives with this form of interpunction? Short of any argument, I'll put the space back in (or in in the first place) everywhere. I deleted it for consistency. Feel free to add one in throughout as an alternative form of consistency. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
- Original Message - From: To: ; ; ; ; Cc: ; Sent: Friday, October 04, 2013 3:53 PM Subject: Re: Add backup option to convert-ly (Issue 3572) (issue 14040043) > With the current code, if there is no file~, the backup file will always > (even in the presence of -n) be called file~, but file~ is much more > prone to overwriting accidentally than file.~1~ not least of all by > convert-ly (when called without -n option at a later point of time) > itself. Well, that's the whole point of this patch. Without this new code, the backup is always over-written. With it, using the -b option prevents over-writing. No, it doesn't. If I have one particularly important revision and no previous backup file, and I very much want to preserve the particularly important revision, let's assume that I do convert-ly -edn file.ly I'm really confused here. -n is the option for no-version. How is this related to backup? once, and do future calls to convert-ly only via convert-ly -ed file.ly Does that mean that the important revision will be preserved? No, it will get overwritten by the future calls of convert-ly -ed because when _no_ previous backup file is present, the first "numbered" backup will be named "file.ly~" rather than "file.ly.~1~". And I think that's a mistake. And while we are at it: the loop has the condition while os.path.exists(back_up) and os.path.isfile(back_up): for skipping over existing files. The second part of the condition is nonsensical since it means that a name will be used for backing up even if it is already taken by a directory or fifo or socket. https://codereview.appspot.com/14040043/ I presume Eluze put it in for a specific reason which I don't know. Eluze? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
- Original Message - From: To: ; ; ; Cc: ; Sent: Friday, October 04, 2013 3:24 PM Subject: Re: Add backup option to convert-ly (Issue 3572) (issue 14040043) https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py#newcode241 scripts/convert-ly.py:241: while os.path.exists(back_up) and os.path.isfile(back_up): I'd do a repeat-until loop here in order to keep non-numbered and numbered backup files strictly separate. With the current code, if there is no file~, the backup file will always (even in the presence of -n) be called file~, but file~ is much more prone to overwriting accidentally than file.~1~ not least of all by convert-ly (when called without -n option at a later point of time) itself. Well, that's the whole point of this patch. Without this new code, the backup is always over-written. With it, using the -b option prevents over-writing. I don't understand your point here, but would re-iterate - this patch fixes the reported issue. When it's pushed, further tinkering is possible, so let's just push a patch that simply adds a new option without changing existing options one iota. The expectation is that a file created with -n option will not be deleted automatically. Naming the first "numbered" backup file file~ will violate that expectation. The expectation of the current code is that backups are overwritten. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notehead bug
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc: "Devel"
Sent: Thursday, October 03, 2013 6:18 PM
Subject: Re: Black mensural notehead bug
"Phil Holmes" writes:
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc: "Devel"
Sent: Thursday, October 03, 2013 5:37 PM
Subject: Re: Black mensural notehead bug
"Phil Holmes" writes:
This looks wrong to me:
\relative c'' {
\override NoteHead.style = #'mensural
\cadenzaOn
s1 a \longa a \breve a1 \bar "|"
\override NoteHead.style = #'blackmensural
s1 a \longa a \breve a1 \bar "|"
}
There is no blackmensural style as such as far as I can see. Do you
mean blackpetrucci?
There are glyphs - for example noteheads.sM1blackmensural so I guessed
the style.
Guessing is your privilege, but as long as you don't guess something
supported by the manuals, I don't see anything that can be called a bug.
The manuals for ancient notation continue to have some defects...
It seems to me you shouldn't need to select a petrucci style to get
these glyphs?
Petrucci uses mensural noteheads scaled to a different size. So it's
not that surprising that Blackpetrucci uses blackmensural noteheads.
So we have any other style using _those_ noteheads?
Well, I don't know without further digging. However, there is a notation
style called black mensural, and it seems only logical that Lilypond should
support this using the available glyphs.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Black mensural notehead bug
- Original Message -
From: "David Kastrup"
To: "Phil Holmes"
Cc: "Devel"
Sent: Thursday, October 03, 2013 5:37 PM
Subject: Re: Black mensural notehead bug
"Phil Holmes" writes:
This looks wrong to me:
\relative c'' {
\override NoteHead.style = #'mensural
\cadenzaOn
s1 a \longa a \breve a1 \bar "|"
\override NoteHead.style = #'blackmensural
s1 a \longa a \breve a1 \bar "|"
}
There is no blackmensural style as such as far as I can see. Do you
mean blackpetrucci?
--
David Kastrup
There are glyphs - for example noteheads.sM1blackmensural so I guessed the
style. It seems to me you shouldn't need to select a petrucci style to get
these glyphs?
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Black mensural notehead bug
This looks wrong to me:
\relative c'' {
\override NoteHead.style = #'mensural
\cadenzaOn
s1 a \longa a \breve a1 \bar "|"
\override NoteHead.style = #'blackmensural
s1 a \longa a \breve a1 \bar "|"
}
--
Phil Holmes
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
- Original Message - From: "Eluze" To: Sent: Monday, September 30, 2013 11:07 PM Subject: Re: Add backup option to convert-ly (Issue 3572) (issue 14040043) Phil Holmes-2 wrote On 2013/09/30 15:10:00, PhilEHolmes wrote: Julien - I'm not convinced that's a good idea. It would mean that, once you'd "turned numbering on", then you couldn't turn it off except by deleting all the numbered files. I think it's better to let the user select, based on the command line switches. By deleting or renaming the _first_ numbered file. I think that's ok as a default, but it might make sense to have an option -n0 or whatever that explicitly turns it off even when there are already numbered backups. It was Eluze's enhancement and his coding. Let's let him decide. to clarify: my intention was to have a backup to which I can revert if necessary (and I don't have to go back to an original file which could be hard to find) I see 2 main scenarios: a) convert-ly a single file - in my system I press ctrl+F11 (or the corresponding pop-up item) and it's done. if for any reason I forget I've already done this and I press this combination a second time my original is gone. b) convert-ly a full folder (eg. a piece with lots of files or the whole LSR) - here I would copy the whole folder to a new one (mentioning the version) and convert the original. if something goes wrong I still have the original. for this I don't need a backup from LilyPond. the choice of the backup's name is secondary - I'm happy with any of the proposed versions (1 or 2 tildes). now to the sophisticated mechanisms: if there is a (recognized) backup in one or the other form in the *whole* folder, convert-ly should prompt for a decision - numbered or not!? this is most likely beyond your (or my) intention. should we specify more clearly the risks of and how to handle convert-ly? Eluze I think the review is taking a fairly simple issue to make it too complex. Let's go with what we now have. If it's not friendly, we can always change it. Note that this does not change existing operation in any way. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
- Original Message - From: To: ; ; Cc: ; Sent: Monday, September 30, 2013 4:29 PM Subject: Re: Add backup option to convert-ly (Issue 3572) (issue 14040043) On 2013/09/30 15:10:00, PhilEHolmes wrote: Julien - I'm not convinced that's a good idea. It would mean that, once you'd "turned numbering on", then you couldn't turn it off except by deleting all the numbered files. I think it's better to let the user select, based on the command line switches. By deleting or renaming the _first_ numbered file. I think that's ok as a default, but it might make sense to have an option -n0 or whatever that explicitly turns it off even when there are already numbered backups. https://codereview.appspot.com/14040043/ It was Eluze's enhancement and his coding. Let's let him decide. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Failed 'make' with 2.17.27 from tarball
- Original Message - From: "Thomas Morley" To: "David Kastrup" Cc: "lilypond-devel" Sent: Monday, September 30, 2013 12:15 PM Subject: Re: Failed 'make' with 2.17.27 from tarball 2013/9/30 David Kastrup : David Kastrup writes: Not necessary, that's quite sufficient. I should be able to reproduce this, I guess. I have no problems _without_ a separate build directory. Now trying with one. Yes, it bombs. So we managed to distribute a setup that will refrain from building ly-grammar.txt in a separate build directory. Rerunning make will regenerate parser.cc and parser.hh and then recompile from there (first time around) (Huh?). But the grammar file will remain missing. Deleting ../Documentation/out/ly-grammar.txt will not help, so while my including it in the distribution did nothing for a build with a separate build directory, it also does not seem to be what is causing the problem. Can we bisect this somehow, assuming that 2.17.26 worked? -- David Kastrup If I find a 2.17.26-tarball I could test with it this evening (off for work now) Compiling 2.17.25 from tarball definitly worked. -Harm It's on the Savannah site: http://git.savannah.gnu.org/cgit/lilypond.git/ -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unverified issues?
- Original Message - From: "Eluze" To: "Janek Warchoł" Cc: "David Kastrup" ; "Phil Holmes" ; "LilyPond Development Team" Sent: Sunday, September 29, 2013 11:26 PM Subject: Re: Unverified issues? Am 29.09.2013 23:45, schrieb Janek Warchoł: 2013/9/29 David Kastrup : "Phil Holmes" writes: From: "Eluze" I will treat what's left tomorrow (I'm not the only bug squad member allowed to do it!) But you seem the most efficient at this :-) So what? If you find that some worker in a factory line is more efficient as the next best worker, do you think good management would be to fire all the rest? Will that get more work done or less? I think Phil's message was meant just as a compliment... so I understood it - thanks ;-) but weeks ago I already told how unfair this system is: Phil's releases happen on week-ends usually and then it's my turn - the others rarely get the opportunity to get accustomed to verifying. As Graham said, if you want to limit the time you spend, and spend it on other bug squad duties, fine - leave loads unverified. If you've still got them next week, complain! -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: verification and bulk edit [Re: Unverified issues?]
- Original Message - From: "David Kastrup" To: "Federico Bruni" Cc: "Eluze" ; "lilypond-devel" Sent: Sunday, September 29, 2013 6:07 PM Subject: Re: verification and bulk edit [Re: Unverified issues?] Federico Bruni writes: 2013/9/29 Eluze >> Traditionally Eluze works through these on a Monday. Let's check the >> situation on Tuesday. > > Ah, ok. I will treat what's left tomorrow (I'm not the only bug squad member allowed to do it!) I've cleared some of them, you won't have to work too much tomorrow :-) This is a boring task and it should be shared as possible between all bug squad members. Also, I'm thinking about a way of making it easier. Most of the times we have only to check if the committish pasted by the developer is really in master. If we add a field "Committish" (where the developer should paste the committish), then the bug squad can show the column Committish and work on the list page instead of having to open each issue. Then we copy&paste each committish in gitk and when we have verified all of them we can use the bulk edit to mark all the issues as Verified in one shot (never tried but I hope it works). What do you think about it? It matches the theory. In practice, I've been startled quite a few times when bug squad members not just verified the commit to be present but also reported back when it turned out that the claimed functionality did not actually accompany the commit. The verification you spell out here could be done by a web crawler and would be done in seconds. The verification from the bug squad appears to do a more thorough job on average. When changing the issue tracker, you get a field for specifying what the tracker should do next after changing the current issue. If you use "go to next issue", it will move to the next issue matching the search. That seems rather efficient, and it would appear that the bug squad reading the issue description and possibly more leads to an improvement of the results. The question is whether we can significantly improve the efficiency without sacrificing more quality than desirable. -- David Kastrup Graham and I used to debate this. His view was that all that is required of Bug Squad members is to verify that a claimed fix was committed. This would lend itself well to autoverification, should someone have the time to write an autoverify-bot. I would live with that for Issues marked as something like "Patch-pushed". I do think that claimed fixes to real bugs should have a tiny example, and the bug squad should confirm that the tiny example no longer fails. This could argue for a more rigorous approach to bug acceptance: no example, no report. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unverified issues?
- Original Message - From: "Eluze" To: Sent: Sunday, September 29, 2013 4:00 PM Subject: Re: Unverified issues? dak wrote "Phil Holmes" < mail@ > writes: The issue tracker shows for <URL:http://code.google.com/p/lilypond/issues/list?can=1&q=status%3Afixed>; 48 unverified issues. Most of them can be verified since 2.17.27 has been released. Some have Fixed_2_17_28 in spite of already being in 2.17.27. Traditionally Eluze works through these on a Monday. Let's check the situation on Tuesday. Ah, ok. I will treat what's left tomorrow (I'm not the only bug squad member allowed to do it!) Eluze But you seem the most efficient at this :-) -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unverified issues?
- Original Message - From: "David Kastrup" To: Sent: Sunday, September 29, 2013 1:15 PM Subject: Unverified issues? The issue tracker shows for http://code.google.com/p/lilypond/issues/list?can=1&q=status%3Afixed> 48 unverified issues. Most of them can be verified since 2.17.27 has been released. Some have Fixed_2_17_28 in spite of already being in 2.17.27. I'd like a better record before branching the stable release branch. -- David Kastrup Traditionally Eluze works through these on a Monday. Let's check the situation on Tuesday. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad is localized?
These both need a bit of study to work out how to fix them. Can you raise an issue for them, please? -- Phil Holmes - Original Message - From: Federico Bruni To: Phil Holmes Cc: Graham Percival ; David Kastrup ; lilypond-devel Sent: Sunday, September 29, 2013 10:57 AM Subject: Re: lilypad is localized? 2013/9/29 Federico Bruni 2013/9/28 Federico Bruni 2013/9/28 Phil Holmes I believe lilypad for Windows is localised - see https://github.com/gperciva/lilypad/tree/master/windows All those .rc files are Windows resource files in different languages. I've no idea how it works, though. I think I can test it later I've just remembered that I have a virtualbox file with Windows inside I confirm that LilyPad is localized: let me know if you need screenshots for italian website.. Two issues to fix IMO: 1. Welcome_to_Lilypond should be translated 2. The installation wizard was in english, even if my locale in Windows is italian Generate PDF and Edit source (right-click menu) are not translated. So only the menu items are translated. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR imports and version numbers?
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: Sent: Saturday, September 28, 2013 1:36 PM Subject: Re: LSR imports and version numbers? "Phil Holmes" writes: The bumping of version numbers is a pain for me, too - it makes it tedious to check what makelsr has _really_ done. I think we should have 2 alternatives: a) bump the version if the file is updated, and not if it hasn't or b) bump to the current version regardless. We should use a) with makelsr. There is a question in my mind as to what a) should bump the version to: i) current version; or ii) version that the update related to. Simplest is probably i). Uh, i) is what's currently happening and it's _exactly_ what causes this annoyance. Any file imported from the LSR (which is at 2.14 or similar) that gets changed at all gets bumped up to current. Since the imports are a one-way street, we just get an increasingly larger number of files getting bumped up to current on each import. -- David Kastrup Ah - OK - I understand now. I'd forgotten that we always start with "old" files, rather than the most recent "updated" file. Yes, if we can make option ii) work, it would solve this problem. I'm in favour. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR imports and version numbers?
- Original Message - From: "David Kastrup" To: Sent: Saturday, September 28, 2013 1:25 PM Subject: LSR imports and version numbers? Hi, I've seen the last LSR import do nothing but bump the version number on a large number of files from 2.17.25 to 2.15.27. Now that's consistent with the current documentation on convert-ly which states: The following options can be given: -d,--diff-version-update increase the \version string only if the file has actually been changed. Without this option (or when any conversion has changed the file), the version header reflects the last considered conversion rule. Now this documentation was written by myself after reverse-engineering the code. But frankly, it does not make sense. If the version is not even touched unless the file is changed, then it does not make sense to update the version number to the last _considered_ conversion rather than the last version actually making a difference. _Without_ using -d, it's ok that the version header is bumped across all conversions that will not be considered in future. But it does not make sense to do that when the _trigger_ for an update is an actually happening conversion. Can we agree on that? Because if we can, it will mean that LSR imports will not keep increasing version numbers higher than necessary, I think. -- David Kastrup The bumping of version numbers is a pain for me, too - it makes it tedious to check what makelsr has _really_ done. I think we should have 2 alternatives: a) bump the version if the file is updated, and not if it hasn't or b) bump to the current version regardless. We should use a) with makelsr. There is a question in my mind as to what a) should bump the version to: i) current version; or ii) version that the update related to. Simplest is probably i). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypad is localized?
- Original Message - From: "Graham Percival" To: "David Kastrup" Cc: "lilypond-devel" Sent: Saturday, September 28, 2013 8:26 AM Subject: Re: lilypad is localized? On Sat, Sep 28, 2013 at 08:24:13AM +0200, David Kastrup wrote: So the real question _if_ it is localized is how you can figure out the translations used in the localized versions so that you can _copy_ them into the documentation and/or put better translations in _both_ places. Graham? I have a very vague memory of seeing different language pngs in Documentation/pictures/, but that's it. I certainly have no direct knowledge of windows lilypad. If there's nothing obvious in Documentation/pictures/ then I'd just assume there's no localization. - Graham I believe lilypad for Windows is localised - see https://github.com/gperciva/lilypad/tree/master/windows All those .rc files are Windows resource files in different languages. I've no idea how it works, though. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Stem direction snippet
I've added a snippet (http://lsr.dsi.unimi.it/LSR/Item?id=751) to master that explains how to set stem direction based on surrounding notes. Anyone object to my adding it to selected snippets in http://www.lilypond.org/doc/v2.16/Documentation/notation/inside-the-staff#stems - I think it makes a useful piece of information. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Release News - to include something about convert.ly
I did mean to consider doing something like that with the most recent release, but also forgot... "Please remember that new releases can require syntax changes. Please use convert-ly (web link) to make most of these automatically." -- Phil Holmes - Original Message - From: James To: Devel Sent: Friday, September 27, 2013 4:49 PM Subject: Release News - to include something about convert.ly Hello, Would it be worthwhile that we add an extra sentence in the 'release news' (Documentation / web / news-front.itexi) informing users that they might need to use convert.ly - just that we occasionally get users 'forgetting' or not knowing that they _might_ need to use convert.ly for newer versions. I'm not sure what one would say, but I always mean to mention this and keep forgetting. James -- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no critical: 2.18 is close?
- Original Message - From: "David Kastrup" To: "Federico Bruni" Cc: "lilypond-devel" Sent: Friday, September 27, 2013 1:33 PM Subject: Re: no critical: 2.18 is close? Federico Bruni writes: I see there's no critical issue in the tracker. I remember that you used to publish release candidates of next stable when we have no critical issues. So I wonder if the releae of 2.18 is close or there's something that it's blocking it.. The release of 2.18 is not "close" since we first need to branch off a release branch. There is still the regression in \fill-line which needs addressing. I would have liked to get an overhaul of \partcombine work in as well, but the last reviewed state is not where I would have felt confident saying "this is what's going to stay" so it seems more appropriate to just deliver the old stuff. There is context handling murkiness which I have not got to the state where removing inexplicable workarounds would have no effects any more. But that's not a regression. And so on. I think after letting 2.17.27 settle for a few days, we are ready to create the branch. We still might make another 2.17 release afterwards to get some exposure to final fixes (like the \fill-line markup), but it better not have any syntax changes requiring convert-ly rules unless they are going to end up in 2.18 as well. Issue 3566 is a candidate for this "may or may not make it" threshold. But I think having a release of 2.18 ready in about three weeks seems possible enough that we should try. -- David Kastrup +1 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: "Joseph Rushton Wakeling" To: "Trevor Daniels" ; "Phil Holmes" ; "David Kastrup" Cc: "LilyPond Development Team" Sent: Thursday, September 26, 2013 4:09 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 16:37, Trevor Daniels wrote: Almost exactly what I was about to reply, but Phil beat me to it! In fact I think I remember helping you add the Contemporary music headings some time ago, or was it someone else? The section originates with me but I got diverted into trying to create a more elegant solution for how to rewrite accidentals in transposed music. It was all related to the need for an effective chromatic transposition solution that also worked well with arbitrary microtonal accidentals. I was also rather discouraged by the fact that the quarter-tone arrow notation issue didn't find a solution -- see: https://code.google.com/p/lilypond/issues/detail?id=1278 I think it's waiting for someone to propose how it could be represented in LilyPond. If _someone_ were to do that, it might progress - it was only a few months ago it was last looked at. Good job I didn't get discouraged by the problems with piano pedal notation. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: "Joseph Rushton Wakeling" To: "David Kastrup" Cc: "Jan Nieuwenhuizen" ; "Janek Warchoł" ; "LilyPond Development Team" ; "Phil Holmes" ; "Graham Percival" Sent: Thursday, September 26, 2013 2:22 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 15:04, David Kastrup wrote: How many substantial patches would you expect yourself to be contributing in the wake of such a move per month to LilyPond? Don't know. Most of my potential contributions to Lilypond are likely to be documentation -- among other things I'd like to revisit and finish up the Contemporary Music section. That would be something that we desperately need. The NR documentation on Contemporary Notation is shockingly poor. I would be prepared to accept almost any form of input from you with the words that improve that section of the NR and would be happy to type "git cl upload" on your behalf, in order to get the patches reviewed. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: "Janek Warchoł" To: "Phil Holmes" Cc: "LilyPond Development Team" ; "David Kastrup" ; "Joseph Wakeling" ; "Graham Percival" Sent: Thursday, September 26, 2013 1:06 PM Subject: Re: improving our contributing tools and workflow Hi, to make things clear: i do not intend to attack anyone personally, or imply that anyone has bad will or malicious intentions. I only want to explain how the situation looks like from my point of view. 2013/9/26 Phil Holmes : Janek wrote: 2013/9/26 Phil Holmes : > Good luck. Let me give a Graham-style warning. Don't invest any more > time > and effort initially than the amount you can discard without problem. > That's > to say - don't put months of work with the risk that the other > contributors > won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. Because your message sounds pessimistic. It sounds like you consider it likely that my attempt to do something good will fail. It sounds like you are not concerned with ensuring that this initiative suceeds and brings benefit to all, but rather you are thinking about the damage and problems it can bring. I thought I made this clear - I was repeating something Graham said to me on a number of occasions. He would argue it was realistic, not pessimistic. You have to be aware of the fact that, simply by working hard on a problem does not guarantee that the effort expended will be rewarded. Here's a direct quote from him - clearly you don't fall into the category of new contributor, but the warning still applies: "We've had bad experiences where a helpful and enthusiastic new contributor misunderstood the instructions, ran off and did 5 hours of work instead of 10 minutes, and none of the main developers wanted to take the time to deal with the results of the 5-hour work, so the whole thing was wasted. (literally wasted, as in "the project would have received more benefit from the 10-minute job instead of the 5-hour work")" Check the results of the grand regression test review. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: "Joseph Rushton Wakeling" To: "David Kastrup" ; "Janek Warchoł" Cc: "Phil Holmes" ; "LilyPond Development Team" ; "Graham Percival" Sent: Thursday, September 26, 2013 12:51 PM Subject: Re: improving our contributing tools and workflow On 26/09/13 12:26, David Kastrup wrote: The dean is annoyed: "Why can't you be like the mathematicians? They just need pencils, paper, and a wastebasket and will work for years. And the philosophers don't even need a wastebasket..." Not any more, either for mathematicians or philosophers ... :-) You can't make decisions without evaluating things, and evaluating things does not even mean that the work will lead to a change from the current state of affairs. It may make you realize that minor changes will already address some problems, for example. Quite, but one of the problems we have right now is that it's not clear what the broad requirements are. For example -- we know that GitHub is out because of its proprietary nature. That means that no one is going to waste time setting up a trial system using GitHub. There are surely other things that can be clarified now so as to not evaluate systems that are going to be rejected out of hand. For example -- is it essential that any solution proposed work well with Google Code issues? Or will consideration be given to a solution that involves an alternative issue tracker? As far as I'm concerned, Google Code could be changed. I find its restriction on attachments annoying. However, a replacement would have to be able to import _all_ the issues lodged there with all their detail and attachments, and provide similar facilities. If it made other stuff easier, great. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: "Janek Warchoł" To: "Phil Holmes" Cc: "LilyPond Development Team" ; "David Kastrup" ; "Joseph Wakeling" ; "Graham Percival" Sent: Thursday, September 26, 2013 11:13 AM Subject: Re: improving our contributing tools and workflow > > Good luck. Let me give a Graham-style warning. Don't invest any more > time > and effort initially than the amount you can discard without problem. > That's > to say - don't put months of work with the risk that the other > contributors > won't accept the change and all that valuable work is junked. This sounds like you're not going to participate in this. Do i understand correctly? It also sounds very discouraging to me. Janek I don't see why you would get that impression. I will participate as usual, although noting that my summer vacation ends this weekend. I was simply reiterating something that Graham said to me on a number of occasions - don't assume that the work you do will be accepted - it's always possible that anything done on a collaborative project won't be. Patches are criticised, changed and occasionally junked, and the same can apply to proposals for changes in tools and processes - so don't become too committed and expend more work than you can afford to lose. Ever. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving our contributing tools and workflow
- Original Message - From: "Janek Warchoł" To: "LilyPond Development Team" ; "David Kastrup" ; "Joseph Wakeling" ; "Phil Holmes" ; "Graham Percival" Sent: Thursday, September 26, 2013 10:48 AM Subject: improving our contributing tools and workflow Hi all, after a long discussion i think it's time to gradually move towards doing things :-) David is going to talk with Savannah people - that's great! Other things that are worth looking at are: - gitorious - gerrit - something else i've forgotten? I'm going to have a short break from LilyPond to regenerate myself (as the discussion was quite exhausting and time-consuming), and then i'll go straight to this issue. I think i'll start by trying gitorious (of course to make some real testing i will need help from someone else). I suppose that by this time we'll know how the situation with Savannah looks like. In a truly Grahamic spirit, i'm going to focus on this issue and not participate in anything else on the mailing list until we're done (with the exception of Tie Crusade which i hope to resurrect). Good luck. Let me give a Graham-style warning. Don't invest any more time and effort initially than the amount you can discard without problem. That's to say - don't put months of work with the risk that the other contributors won't accept the change and all that valuable work is junked. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Joseph Rushton Wakeling" To: Sent: Tuesday, September 24, 2013 3:53 PM Subject: Re: we now have "lilypond" organization on GitHub On 23/09/13 12:59, Graham Percival wrote: Reviewing patches? Explaining why we reject a patch (I don't think we can fairly reject a patch unless we explain why)? Those are significant costs. What are the most common reasons for doc patch rejection? Poor syntax; poor explanation; unnecessary; failure to compile; failure to follow standards. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Joseph Rushton Wakeling" To: Sent: Tuesday, September 24, 2013 3:47 PM Subject: Re: we now have "lilypond" organization on GitHub On 24/09/13 15:45, David Kastrup wrote: "you" is you. So start fixing it. You know better than everybody else what is in need of fixing, so go ahead. Every time I raise usability issues related to the contribution tools, I run into this big wall of denial that there is actually a problem. And rather than recognizing this as a concern of someone who wants to contribute, you throw it back at me as somehow a sign of inadequate commitment, that I complain without solving the problem. I freely admit that I don't have all the technical skills needed to provide a solution to this problem. But I _do_ know what user experience I have contributing to other projects, and it is very, very different to what I have when trying to contribute to Lilypond. I don't think that it is wrong (or unhelpful) of me to point out that difference. The thing is, even if I _did_ have all the technical skills required, or if I invested time and effort to learn them, do I have any guarantee that my work would be rewarded with acceptance of my solution? The hostile reception to my saying, "Here are a set of usability problems" doesn't exactly encourage my hope that a solution would be welcomed. If you were able to develop a more usable set of tools that is a) compatible with our code base and development environment b) does not require a large developer investment to adopt and c) provides the same functionality as we currently have (e.g. review, test), I would be more than happy to press for its adoption. The reason that you're getting a less than enthusiastic reception is that it would seem unlikely that anyone would want to devote that amount of time. But if you were to do it, sure, I'm convinced we'd do our best to take it on. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Joseph Rushton Wakeling" To: "Phil Holmes" ; "Graham Percival" Cc: Sent: Tuesday, September 24, 2013 2:40 PM Subject: Re: we now have "lilypond" organization on GitHub On 24/09/13 15:34, Phil Holmes wrote: I imagine that one problem of using a VM is that it makes it much more difficult/slow to run such local tests? Not with current servers. GUB is built in a VM, much faster than most people could do it natively. Running on servers, sure. I was thinking of the case where people wanted to run the test suite on their own machine before submitting. OK. I should have said not with current CPUs. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Joseph Rushton Wakeling" To: "Graham Percival" Cc: Sent: Tuesday, September 24, 2013 2:02 PM Subject: Re: we now have "lilypond" organization on GitHub I imagine that one problem of using a VM is that it makes it much more difficult/slow to run such local tests? Not with current servers. GUB is built in a VM, much faster than most people could do it natively. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Janek Warchoł" To: "Phil Holmes" Cc: "Urs Liska" ; "David Kastrup" ; "Julien Rioux" ; "LilyPond Developmet Team" ; "Han-Wen Nienhuys" Sent: Sunday, September 22, 2013 4:30 PM Subject: Re: we now have "lilypond" organization on GitHub 2013/9/22 Phil Holmes : IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly in a Virtual Machine) provides git and git-cl. Git allows a developer to create a patch with 2 commands: git commit and git format-patch. That can be uploaded to Rietveld with a single command (possibly 2 commands, depending on what you were doing earlier). When the review is passed, it can be pushed to staging with 4 simple commands; or mailed to -devel for any active developer without push access - these are very rare. How hard is that? Hard. It takes at least an hour (more probably 2 hours) to install all this stuff and find and read relevant information (when i was installing lilydev my first time, it took me half of the night). And don't forget additional 5 GB of space you need for the VM, and that you have to use a completely new, unfamiliar environment (i.e. a new OS). Compare it to something like github (i'm not saying we should use github, that's just an example) when it takes 2 minutes and you can do everything in your browser (obviously, i'm speaking about small patches). To me, the difference is obvious. Janek Not comparing like with like. LilyDev provides a complete build environment; GitHub doesn't. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "Urs Liska" To: "David Kastrup" Cc: "Julien Rioux" ; "LilyPond Developmet Team" ; "Han-Wen Nienhuys" Sent: Sunday, September 22, 2013 1:57 PM Subject: Re: we now have "lilypond" organization on GitHub Am 16.09.2013 12:50, schrieb David Kastrup: Graham Percival writes: On Mon, Sep 16, 2013 at 10:49:42AM +0200, David Kastrup wrote: What's wrong with GitHub, anyway? It requires separate accounts and credentials (much more likely to be a target for attacks), has its own "terms of service", may choose to discontinue projects based on commercial criteria, can cause tool lock-in and so on, relies on its own proprietary software. All the above is true, but github also provides a nicer way for developers to interact with git, by at least one order of magnitude. So the question is what we should be telling the Savannah operators to make working on GNU projects using Git more feasible. What about asking them to provide Gerrit as a service? As far as I've read: - LilyPond uses Rietveld, which isn't designed for git workflows. - Rietveld isn't integrated in the process of getting code into lilypond/master, but rather an artificial detour. - For example the issue of commit messages that are finally pushed and don't match the reviewed code is probably related to that. - Gerrit _is_ designed for git workflows. - You could grant developer accounts to, say, anybody expressing serious intentions to contribute - These could have the right to push the Gerrit - The core developers have the right to approve/reject proposals as well as pushing directly to the main repo - Approval of a patch immediately merges it into the main code base. - This would make the way for externals' code into the main code base more straightforward and transparent. Urs IMHO this is solving a problem that doesn't exist. Using LilyDev (possibly in a Virtual Machine) provides git and git-cl. Git allows a developer to create a patch with 2 commands: git commit and git format-patch. That can be uploaded to Rietveld with a single command (possibly 2 commands, depending on what you were doing earlier). When the review is passed, it can be pushed to staging with 4 simple commands; or mailed to -devel for any active developer without push access - these are very rare. How hard is that? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond benchmarking
- Original Message - From: "Keith OHara" To: Sent: Saturday, September 21, 2013 8:38 PM Subject: Re: Lilypond benchmarking Phil Holmes philholmes.net> writes: > I've done quite a bit of work trying to see what's going on and have > discovered that something introduced between (I think) 2.17.18 and 2.17.19 > has affected how lily determines whether it can fit another system in. > With ragged-bottom set and annotate spacing, on one of my scores 17.19 > shows 49.07 space left and the next system having an extent of 44.7. > Despite that it puts that system on the following page. The earlier > version fits it in, albeit with the complaint "warning: cannot fit music > on page: ragged-spacing was requested, but page was compressed". Without > ragged-bottom, that complaint is not there. > commit 51560f756aa3ab37592c815062e733998accf79c align-interface.cc: Clarify code for empty staves This commit was made in the middle of our trying to get the page-breaker and page-layout to agree on how to handle empty staves. (issue 3160 3161 1669 and 3338) http://code.google.com/p/lilypond/issues/detail?id=3338#c18 However, this commit was supposed to clarify code without changing any behavior. I made it a separate commit so it would revert cleanly, and it does http://codereview.appspot.com/13768045 but I hesitate to go back to the old, rather sneaky, code. Is it possible to minimize an example, so we see if the old behavior is something we want? (as opposed to something that did what you wanted but for mysterious reasons.) I can provide a non-minimised example (Mikado song number 5). It's non trivial to make it minimal, because of the interaction with system size. The example takes about 20 sec to compile on Windows and about 3 on my build machine. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond benchmarking
- Original Message - From: "Keith OHara" To: Sent: Saturday, September 21, 2013 8:49 PM Subject: Re: Lilypond benchmarking Phil Holmes philholmes.net> writes: Summary: 2.12 was very slow and unreliable on large scores. 2.14, 2.16 and 2.17.26 are similar: it look like current devel is slower where there's a lot of interleaving of notes and dynamics to be done, which is probably to be expected with the more sophisticated skylining code. I'd conclude there is no fundamental performance problem with our current build. I assume your tables show the numbers of minutes required to typeset the input ? Seconds, not minutes :-) FWIW, I find my build machine on Ubuntu is much faster. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB news
I've built a new release of Lilypond (a day earlier than normal owing to concerts tomorrow) but at present I can't log in to lilypond.org to do the upload - there's a permissions problem. I've asked Graham whether he can help and am awaiting his response. If it's not fixed today I'll rebuild the release once it is fixed. Just announcing this in case anyone is monitoring release/unstable and wondering where the build is. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond benchmarking
- Original Message - From: "Phil Holmes" To: "David Kastrup" Cc: Sent: Saturday, September 21, 2013 4:37 PM Subject: Re: Lilypond benchmarking - Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "James" ; Sent: Saturday, September 21, 2013 2:12 PM Subject: Re: Lilypond benchmarking "Phil Holmes" writes: 2.12 - 162 pages; 2.14 - 147; 2.16 - 142; 2.17.26 - 158pp. 2.17 is noticeably looser, but I concluded I'd adjust some of the spacing controls to fit more to a page. That's actually a real problem. Now 2.17.27 will have some padding significantly reduced (halved?) if I understand Keith correctly, so we should get some pages more out. If I remember correctly, the skyline code made it desirable to increase some paddings to avoid jamming things too closely. And also if I remember correctly, the page break decisions do _not_ make use of skylines. Instead, skylines are only used for spreading out the page _after_ pagebreaking, so the net result will be more pages rather than fewer. I may have understood something wrong here. However, if my understanding is _not_ mistaken here, I think we should not release 2.18 before we have integrated the interstaff positioning using skylines into the page breaking decisions. And of course, the distance between two successive skylines should be measured _once_ at most. It probably needs to become a part of vertical spacing rods or something. -- David Kastrup I've done quite a bit of work trying to see what's going on and have discovered that something introduced between (I think) 2.17.18 and 2.17.19 has affected how lily determines whether it can fit another system in. With ragged-bottom set and annotate spacing, on one of my scores 17.19 shows 49.07 space left and the next system having an extent of 44.7. Despite that it puts that system on the following page. The earlier version fits it in, albeit with the complaint "warning: cannot fit music on page: ragged-spacing was requested, but page was compressed". Without ragged-bottom, that complaint is not there. Bisecting. -- Phil Holmes 51560f756aa3ab37592c815062e733998accf79c is the first bad commit commit 51560f756aa3ab37592c815062e733998accf79c Author: Keith OHara Date: Wed May 25 23:43:08 2011 -0700 align-interface.cc: Clarify code for empty staves -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond benchmarking
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "James" ; Sent: Saturday, September 21, 2013 2:12 PM Subject: Re: Lilypond benchmarking "Phil Holmes" writes: 2.12 - 162 pages; 2.14 - 147; 2.16 - 142; 2.17.26 - 158pp. 2.17 is noticeably looser, but I concluded I'd adjust some of the spacing controls to fit more to a page. That's actually a real problem. Now 2.17.27 will have some padding significantly reduced (halved?) if I understand Keith correctly, so we should get some pages more out. If I remember correctly, the skyline code made it desirable to increase some paddings to avoid jamming things too closely. And also if I remember correctly, the page break decisions do _not_ make use of skylines. Instead, skylines are only used for spreading out the page _after_ pagebreaking, so the net result will be more pages rather than fewer. I may have understood something wrong here. However, if my understanding is _not_ mistaken here, I think we should not release 2.18 before we have integrated the interstaff positioning using skylines into the page breaking decisions. And of course, the distance between two successive skylines should be measured _once_ at most. It probably needs to become a part of vertical spacing rods or something. -- David Kastrup I've done quite a bit of work trying to see what's going on and have discovered that something introduced between (I think) 2.17.18 and 2.17.19 has affected how lily determines whether it can fit another system in. With ragged-bottom set and annotate spacing, on one of my scores 17.19 shows 49.07 space left and the next system having an extent of 44.7. Despite that it puts that system on the following page. The earlier version fits it in, albeit with the complaint "warning: cannot fit music on page: ragged-spacing was requested, but page was compressed". Without ragged-bottom, that complaint is not there. Bisecting. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond benchmarking
2.12 - 162 pages; 2.14 - 147; 2.16 - 142; 2.17.26 - 158pp. 2.17 is noticeably
looser, but I concluded I'd adjust some of the spacing controls to fit more to
a page.
--
Phil Holmes
- Original Message -
From: James
To: lilypond-devel@gnu.org
Sent: Saturday, September 21, 2013 1:37 PM
Subject: Re: Lilypond benchmarking
On 21/09/13 13:31, Phil Holmes wrote:
David made the comment that we'd no information on the performance of the
latest development release on large project, so I thought I'd do a little
benchmarking. This has been done on windows vista 64 bit.
I've used 4 benchmarking tests: a) \repeat unfold xx c''4; b) \repeat
unfold 500 { c''4 c' \f c''' g } (this gives the skylining code something to
do, which the simple one in a) doesn't); c) the Finale to Act I of the Mikado,
which I created as code about 3 years ago, and runs to 496 bars and up to 30
voices and d) The full score for the Mikado, about 150 pages but set as a
number (about 20) of separate \score blocks. The main problem I've got is
laying the results out in a text-only email, so I've attached them as a little
image.
Summary: 2.12 was very slow and unreliable on large scores. 2.14, 2.16 and
2.17.26 are similar: it look like current devel is slower where there's a lot
of interleaving of notes and dynamics to be done, which is probably to be
expected with the more sophisticated skylining code. I'd conclude there is no
fundamental performance problem with our current build.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Phil,
How many pages does the full score take comparatively - a lot of the page
breaking stuff was done between 2.12 and 2.16, I'm curious if you flicked
through it and noticed any horrendous spacing or big gaps between staffs or at
the end of sections.
Thanks for the insight.
James
--
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond benchmarking
- Original Message -
From: "David Kastrup"
To:
Sent: Saturday, September 21, 2013 1:37 PM
Subject: Re: Lilypond benchmarking
"Phil Holmes" writes:
David made the comment that we'd no information on the performance of
the latest development release on large project, so I thought I'd do a
little benchmarking. This has been done on windows vista 64 bit.
I've used 4 benchmarking tests: a) \repeat unfold xx c''4; b) \repeat
unfold 500 { c''4 c' \f c''' g } (this gives the skylining code
something to do, which the simple one in a) doesn't); c) the Finale to
Act I of the Mikado, which I created as code about 3 years ago, and
runs to 496 bars and up to 30 voices and d) The full score for the
Mikado, about 150 pages but set as a number (about 20) of separate
\score blocks. The main problem I've got is laying the results out in
a text-only email, so I've attached them as a little image.
Summary: 2.12 was very slow and unreliable on large scores. 2.14,
2.16 and 2.17.26 are similar: it look like current devel is slower
where there's a lot of interleaving of notes and dynamics to be done,
which is probably to be expected with the more sophisticated skylining
code. I'd conclude there is no fundamental performance problem with
our current build.
The numbers for 2.17.26 are generally about 30% slower than 2.16.
That's quite more than the skyline code as such should be accountable
for. Definitely looks like we should bother with some profiling.
--
David Kastrup
It's actually faster with test a), which is why I think it's skylining
stuff.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond benchmarking
David made the comment that we'd no information on the performance of the
latest development release on large project, so I thought I'd do a little
benchmarking. This has been done on windows vista 64 bit.
I've used 4 benchmarking tests: a) \repeat unfold xx c''4; b) \repeat unfold
500 { c''4 c' \f c''' g } (this gives the skylining code something to do,
which the simple one in a) doesn't); c) the Finale to Act I of the Mikado,
which I created as code about 3 years ago, and runs to 496 bars and up to 30
voices and d) The full score for the Mikado, about 150 pages but set as a
number (about 20) of separate \score blocks. The main problem I've got is
laying the results out in a text-only email, so I've attached them as a
little image.
Summary: 2.12 was very slow and unreliable on large scores. 2.14, 2.16 and
2.17.26 are similar: it look like current devel is slower where there's a
lot of interleaving of notes and dynamics to be done, which is probably to
be expected with the more sophisticated skylining code. I'd conclude there
is no fundamental performance problem with our current build.
--
Phil Holmes
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we now have "lilypond" organization on GitHub
- Original Message - From: "David Kastrup" To: "Urs Liska" Cc: "Julien Rioux" ; "LilyPond Developmet Team" ; "Han-Wen Nienhuys" Sent: Wednesday, September 18, 2013 1:37 PM Subject: Re: we now have "lilypond" organization on GitHub Urs Liska writes: Am 18.09.2013 14:28, schrieb Janek Warchoł: 2013/9/18 Janek Warchoł : 2013/9/17 Urs Liska : But as far as I've understood, code doesn't get into upstream master that way anyway, there is the Rietveld code review stage in between? How do commits (from developers) actually end up in master? It's c) they are usually not pushed to any branch, unless it's a big or long-running change (think "Mike's skylines"). If you want to base some new work on a yet unmerged patch, you usually need to ask the author to push the branch. OK, and if someone without push access (e.g. me) had something to contribute, would the following process seem right? 1) Upload a patch to Rietveld and go through review, possibly changing the code. The contributor's guide details the tools and workflows that make it easy to get right. It's possible to do it manually as well, of course. 2) When review is finished prepare a patch file (or series of patch files) and find someone with push access whom I can send it to? Yup. Strictly, not necessarily even that. I've pushed patches picked up from Rietveld. It's more work for the pusher, but can be done. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
- Original Message -
From:
To:
Cc:
Sent: Tuesday, September 17, 2013 5:37 PM
Subject: Patchy email
16:31:10 (UTC) Begin LilyPond compile, previous commit at
88ce02a0c97434ae1b3903395e5664ce2fbf7e35
16:31:21 Merged staging, now at: 88ce02a0c97434ae1b3903395e5664ce2fbf7e35
16:31:22 Success: ./autogen.sh --noconfigure
16:31:42 Success: /tmp/lilypond-autobuild/configure --disable-optimising
16:31:51 Success: nice make clean
16:37:48 *** FAILED BUILD ***
nice make -j3 CPU_COUNT=3
Previous good commit: 75988240e6ba28320ce5d835670712cc09cbd966
Current broken commit: 88ce02a0c97434ae1b3903395e5664ce2fbf7e35
16:37:48 *** FAILED STEP ***
merge from staging
Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
16:37:48 Traceback (most recent call last):
File
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
line 528, in handle_staging
self.build (issue_id=issue_id)
File
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
line 316, in build
issue_id)
File
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
line 266, in runner
raise FailedCommand ("Failed runner: %s\nSee the log file %s" %
(command, this_logfilename))
FailedCommand: Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
That's a surprise. I ran make doc on that commit and it passed OK. I've
got a few minutes before leaving for a rehearsal - I'll try a clean make.
If the logfile is available, I'd like to see it.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
- Original Message -
From: "David Kastrup"
To:
Sent: Tuesday, September 17, 2013 5:59 PM
Subject: Re: Patchy email
"Phil Holmes" writes:
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
line 266, in runner
raise FailedCommand ("Failed runner: %s\nSee the log file %s" %
(command, this_logfilename))
FailedCommand: Failed runner: nice make -j3 CPU_COUNT=3
See the log file log-staging-nice-make--j3-CPU_COUNT=3.txt
That's a surprise.
Not really. Use of unescaped { and } inside of @example (totally
annoying to get that right, I quite remember this from the last time I
edited this @lilypond/@example mix in this chapter).
I ran make doc on that commit and it passed OK.
Unlikely. Perhaps some dependencies are broken.
I've got a few minutes before leaving for a rehearsal - I'll try a
clean make. If the logfile is available, I'd like to see it.
I pushed a fix to staging. Let's see whether this makes it.
--
David Kastrup
make doc against a non-clean tree was OK - it rebuilt the web pages without
a problem. I've just run make and you're right - it was the {} that cause
the problem in makeinfo. Thanks for sorting this.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
