Re: 2.16.1
Federico Bruni fedel...@gmail.com writes: Il giorno 21/ott/2012 05:17, David Kastrup d...@gnu.org ha scritto: Phil Holmes em...@philholmes.net writes: David, I see you've done a lot of moving updates into 2.16.1. When do you expect to want a release for this? I've asked on the translator list whether they want to get something translated from all the cherry-picking, and feedback is incomplete yet. Hi David, When did you ask? I may have missed your email.. I hope translati...@lilynet.net is not a dead list (or did its list server die, or is it moderated with no moderator ever approving posts?). At any rate, I sent several messages. The first I can only find in my mailing logs (Friday), but not in my mailing list archives. Too bad. Probably sitting in the translator list moderation queue. I append the second one which presumably got a reply from Francisco only because I replied to an old thread, thus directing a direct copy to him as well. The first mail mentioned the following presumably translator-relevant output (since last translation merge) dak@lola:/usr/local/tmp/lilypond$ git log origin/translation..origin/stable/2.16 --oneline Documentation d47930b Doc: extend description of glissandi (2844) 6cb3cdb Web: Add Elysium to Easier Editing section 1141313 Doc: document \time command fully (2807) dcddb2c inserted \clef treble_8 b2bdfeb Doc: delete obsolete para on two-pass spacing (2828) 6da27f9 Doc: Typos to LM - Fundamental and tweaks.itely ba92a17 Doc: extend explanation of relative-includes (2558) bcd8bd5 Doc: improve footnote documentation (2547) a885534 Doc: clarify the use of a Scheme engraver. 4239aa2 Web: Removed note about MacOS Lion not supported ac604de add website link to tunefl.com 629fc59 Doc: NR 3.2.1: clarify titles and \header blocks (2652) 5fd9cdc Fix over-long lines in glossary 44011e3 Issue 2760: CG wants all engravers to have double-quotes around them 6969857 Doc: MG: add incomplete dominant seventh chord (2749) 5b14676 Document landscape and portrait suffixes for paper size 35d565c Doc: standardise level 5 headings (2730) c586c49 Doc: added link to conversion tools from Encore to lilypond enc2ly and I am not sure the Web entries need translations (or whether it was not utterly stupid to cherry-pick them in the first place), but they _are_ compiled into local HTML and info information even if we don't display them prominently on the live web pages. I have no really good idea about the changes document. I lean to pasting a single link there to our bug tracker, listing Fixed_2_16_1 labels. I think that all translators should update the inaccuracies in LM. I'll try to do it today, even if I'm abroad and with a Windows laptop. ---BeginMessage--- If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. I am willing to take care of that and of the translation merges into staging when translation is still based on stable. Since one purpose of getting staging up to date with regard to translations is to be able to do extensive convert-ly work, the merging might be a bit tricky until things move over completely. I am not sure when translators will want to move their focus to master rather than stable again: it might be possible to create a branch translation-stable for working on stable branch translations, but I would like to phase out stable branch work eventually and so a separate translation-stable can still be left for a time when we feel we really need it. Probably cherry-picking will be enough if commits for unstable-only material are kept separate well enough. At any rate, with this plan it is more or less up to the translators to decide when they think 2.16.1 is ready. There is not much I cherry-picked into the stable branch since the last translation merge, and I'd not like to wait much longer than a week for 2.16.1 in consequence, but 2.16.2 will likely take quite longer. People fine with that? -- David Kastrup ---End Message--- -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
David Kastrup d...@gnu.org writes: I hope translati...@lilynet.net is not a dead list (or did its list server die, or is it moderated with no moderator ever approving posts?). At any rate, I sent several messages. At least the second one with cc to several individuals. From: David Kastrup d...@gnu.org Subject: Re: [translations] Git translation branch policy change: merge with and from stable/2.16 To: Francisco Vila paconet@gmail.com Cc: Jean-Charles Malahieude lily...@orange.fr, John Mandereau john.mander...@gmail.com, Translations list at lilynet translati...@lilynet.net Date: Sat, 20 Oct 2012 12:44:29 +0200 (21 hours, 30 minutes, 46 seconds ago) If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. The only reaction to that was a mail from Francisco which did not much to address this part of my plan. I did this right now, and afterwards discovered that there is a branch translation-staging. It is obvious that I suffer from a case of having not kept track of how translations are actually organized, so it may be possible that someone would need to hand-advance translation-staging to match translation, assuming that the organization of translation/translation-staging is similar to master/staging with regard to automatic testing. Ugh. Sorry for that. With the apparent lack of replies/comments/interest (possibly due to the translation list just downing any contribution from non-list-members), I felt I needed to move ahead in _some_ manner. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. At any rate, probably somebody who is reasonably sure to be able to write to the translators list should copy this kind of information/question there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
David Kastrup d...@gnu.org writes: I'll merge stable/2.16 into translation. That should be unproblematic. The only reaction to that was a mail from Francisco which did not much to address this part of my plan. I did this right now, and afterwards discovered that there is a branch translation-staging. It is obvious that I suffer from a case of having not kept track of how translations are actually organized, so it may be possible that someone would need to hand-advance translation-staging to match translation, assuming that the organization of translation/translation-staging is similar to master/staging with regard to automatic testing. Ugh. Sorry for that. With the apparent lack of replies/comments/interest (possibly due to the translation list just downing any contribution from non-list-members), I felt I needed to move ahead in _some_ manner. Ok, it would appear that translation had been ahead translation-staging already before my merge, so it seems I should take no guesses here and just let people who actually know what translation-staging is for deal with it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16.1
2012/10/21 David Kastrup d...@gnu.org: I hope translati...@lilynet.net is not a dead list (or did its list server die, or is it moderated with no moderator ever approving posts?). At any rate, I sent several messages. The first I can only find in my mailing logs (Friday), but not in my mailing list archives. Too bad. Probably sitting in the translator list moderation queue. I append the second one which presumably got a reply from Francisco only because I replied to an old thread, thus directing a direct copy to him as well. Yes, you are not allowed to post on translators mailing list, in fact your email is missing from the archives. It's just because you are not subscribed, I don't think there's any moderation. We can see only the reply from Francisco: http://lilypond-translations.3384276.n2.nabble.com/Git-translation-branch-policy-change-merge-with-and-from-stable-2-16-td7572469i20.html A bit confusing, since it is an old thread and I didn't receive your email before Francisco's reply. Maybe next time write to Francisco and he will forward your message to translators list, keeping you in CC. Or ask Valentine to be subscribed (it's a low volume list). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Git translation branch policy change: merge with and from stable/2.16
Le 20/10/2012 20:33, Francisco Vila disait : 2012/10/20 David Kastrup d...@gnu.org: If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. The only problems I foresee, will come from original English docs. As we have not translated anything new since the fork, all translated material is directly dumpable there. Not blindly, though, you know what I mean. I think you mean all @lilypond that might have changed in-between? I am willing to take care of that and of the translation merges into staging when translation is still based on stable. How is this useful? Here I can see a clear need of two translation branches. It translation is based on stable, we can not work on devel branch. That's what I feared since the freeze: having to maintain two sets of translations. Since one purpose of getting staging up to date with regard to translations is to be able to do extensive convert-ly work, the merging might be a bit tricky until things move over completely. My proposal is to move to devel branch, merge master on translation and forget about stable. We have been freezed for too long. Not a line of any new material in devel releases has been translated. I am not sure when translators will want to move their focus to master rather than stable again: it might be possible to create a branch translation-stable for working on stable branch translations, but I would like to phase out stable branch work eventually and so a separate translation-stable can still be left for a time when we feel we really need it. Probably cherry-picking will be enough if commits for unstable-only material are kept separate well enough. Agreed. But specifically, you mean cherry-picking translation--staging or translation--stable? I think what should be done is translation synchronizes with staging translation-stable synchronizes with staging/x.y so, there would be 1- one merry-go-round: staging-master-translation-staging 2- cherry-picking from master towards stable when needed 3- one merry-go-round stable -- translation-stable At any rate, with this plan it is more or less up to the translators to decide when they think 2.16.1 is ready. There is not much I cherry-picked into the stable branch since the last translation merge, and I'd not like to wait much longer than a week for 2.16.1 in consequence, but 2.16.2 will likely take quite longer. People fine with that? The question is: translators, do you plan to update yet something for stable? whe we are reasonably done with stable, let's forget it and move to staging. As for Spanish, I am done. Can not speak for others. I just updated the searchbox before having some visitors yesterday. Everything is up to date on my side for 2.16. One might check the result of a po-replace before releasing. I'll be on vacation between nov. 5 and 11 (except one day for my mother's 80th birthday). Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Git translation branch policy change: merge with and from stable/2.16
Jean-Charles Malahieude lily...@orange.fr writes: Le 20/10/2012 20:33, Francisco Vila disait : 2012/10/20 David Kastrup d...@gnu.org: If it is ok with people, I'd propose the following course in order to get the ball rolling again: I'll merge stable/2.16 into translation. That should be unproblematic. Then I'll merge translation into staging. This will require a bit of cleanup and conflict resolution. The only problems I foresee, will come from original English docs. As we have not translated anything new since the fork, all translated material is directly dumpable there. Not blindly, though, you know what I mean. I think you mean all @lilypond that might have changed in-between? I am willing to take care of that and of the translation merges into staging when translation is still based on stable. How is this useful? Here I can see a clear need of two translation branches. It translation is based on stable, we can not work on devel branch. That's what I feared since the freeze: having to maintain two sets of translations. I think that we will likely leave the stable branch behind soon with regard to documentation maintenance. Our documentation is improving all the while, and much of it remains applicable to the stable branch. At the same time, there are several significant changes going forward, and those will affect a large ratio of documentation, partly semiautomatically, meaning that cherry-picking changes without extensive merge conflicts will get harder and harder. It is important for us to work on documentation designed to match ongoing work, cater for the future of LilyPond rather than its past. We don't have two separate teams maintaining stable and unstable branches (in fact, it is a conflict of interest that I am still responsible for the stable branch). So I don't really see much of an alternative to focusing documentation improvements, even where they tend to apply equally well to past versions, on master. If we have master the best and most consistent we can make it, this will end up in a stable release after all. Not 2.16, but 2.18. So I really think we should move translations over, and live with the documentation of 2.16 being the best we could make it for 2.16. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
make scripts on Windows (cygwin)
I'd like to update the italian translation before 2.16.1 release. I have a problem: I'm abroad until Friday and I only have a Windows laptop. I guess that you will recommend LilyDev. Not tried yet, as I'm not really interested in compiling Lilypond. I just need to be able to run some make commands for the translation maintenance. I've installed Cygwin and the packages needed for compiling (well, I hope so). But I get an error when I run configure: $ ./configure configure: error: cannot run /bin/sh stepmake/bin/config.sub $ sh sh.exe shasum shimeng.dll shrpubw.exe sha1sum.exe shdocvw.dll shimgvw.dll shsetup.dll sha224sum.exe shell32.dll shlwapi.dll shsvcs.dll sha256sum.exe shellstyle.dll shmtool.exe shuf.exe sha384sum.exe shfolder.dllshopt shunimpl.dll sha512sum.exe shgina.dll shpafact.dllshutdown.exe shacct.dll shift shred.exe shwebsvc.dll $ sh configure configure: error: cannot run /bin/sh stepmake/bin/config.sub Can any Windows user help me? Thanks, Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still alive
Trevor Daniels t.dani...@treda.co.uk writes: m...@mikesolomon.org: Tuesday, October 09, 2012 10:29 AM On 9 oct. 2012, at 11:39, Trevor Daniels t.dani...@treda.co.uk wrote: m...@mikesolomon.org wrote Tuesday, October 09, 2012 9:19 AM Just a quick ping to let you know that I'm not dead - I've been swamped w/ work recently and just got engaged so I'm planning out a wedding (w00t!). Congratulations! Does she _really_ know what she's letting herself in for ;) She's NUTS! Sounds like an excellent match, then! URL:http://pbfcomics.com/129/ gives a perspective on the better half angle of this observation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Git translation branch policy change: merge with and from stable/2.16
Le 21/10/2012 13:15, David Kastrup disait : Jean-Charles Malahieude lily...@orange.fr writes: That's what I feared since the freeze: having to maintain two sets of translations. I think that we will likely leave the stable branch behind soon with regard to documentation maintenance. Our documentation is improving all the while, and much of it remains applicable to the stable branch. At the same time, there are several significant changes going forward, and those will affect a large ratio of documentation, partly semiautomatically, meaning that cherry-picking changes without extensive merge conflicts will get harder and harder. It is important for us to work on documentation designed to match ongoing work, cater for the future of LilyPond rather than its past. We don't have two separate teams maintaining stable and unstable branches (in fact, it is a conflict of interest that I am still responsible for the stable branch). So I don't really see much of an alternative to focusing documentation improvements, even where they tend to apply equally well to past versions, on master. If we have master the best and most consistent we can make it, this will end up in a stable release after all. Not 2.16, but 2.18. Fine with me. So I really think we should move translations over, and live with the documentation of 2.16 being the best we could make it for 2.16. Do we translators first update what you just merged from stable? I'm on it at the present (my wife is conducting a choir rehearsal of King Arthur this afternoon). Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make scripts on Windows (cygwin)
Federico Bruni fedel...@gmail.com writes: I'd like to update the italian translation before 2.16.1 release. I have a problem: I'm abroad until Friday and I only have a Windows laptop. I guess that you will recommend LilyDev. Not tried yet, as I'm not really interested in compiling Lilypond. I just need to be able to run some make commands for the translation maintenance. I've installed Cygwin and the packages needed for compiling (well, I hope so). If you are not interested in wasting the rest of your week (and probably the next month) throwing good time after bad time fighting things that almost, but not quite work, you should seriously give LilyDev a try. Its main motivation is not having gcc available (that one is perfectly available standalone on Windows) but rather all the little things when you just need to be able to run some make commands. Disclaimer: I have not touched either Windows, Cygwin, or virtual environments for years. But I still habe the scars to show. But I get an error when I run configure: $ ./configure configure: error: cannot run /bin/sh stepmake/bin/config.sub $ sh sh.exe shasum shimeng.dll shrpubw.exe sha1sum.exe shdocvw.dll shimgvw.dll shsetup.dll sha224sum.exe shell32.dll shlwapi.dll shsvcs.dll sha256sum.exe shellstyle.dll shmtool.exe shuf.exe sha384sum.exe shfolder.dllshopt shunimpl.dll sha512sum.exe shgina.dll shpafact.dllshutdown.exe shacct.dll shift shred.exe shwebsvc.dll $ sh configure configure: error: cannot run /bin/sh stepmake/bin/config.sub Can any Windows user help me? Well, Cygwin has an idea of where /bin is situated. ls /bin might tell you that. Or maybe not. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Git translation branch policy change: merge with and from stable/2.16
Jean-Charles Malahieude lily...@orange.fr writes: Le 21/10/2012 13:15, David Kastrup disait : So I really think we should move translations over, and live with the documentation of 2.16 being the best we could make it for 2.16. Do we translators first update what you just merged from stable? I'm on it at the present (my wife is conducting a choir rehearsal of King Arthur this afternoon). I am not intending to roll out 2.16.1 in a state the translators consider inconsistent. If we have a good chance of telling Phil to get the release machinery in action by next weekend, that would be great. I still don't have a good plan for the release announcements and changes.tely, and at least the latter should likely also be translated, so it should get wrapped up in the next few days if translators are to have a chance to get stuff done by the end of following week. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Git translation branch policy change: merge with and from stable/2.16
2012/10/21 Jean-Charles Malahieude lily...@orange.fr: So I really think we should move translations over, and live with the documentation of 2.16 being the best we could make it for 2.16. Do we translators first update what you just merged from stable? I'm on it at the present (my wife is conducting a choir rehearsal of King Arthur this afternoon). Yes, please wait for the update (at least from me). Then we can move to 2.17, I agree. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.5?
- Original Message - From: Phil Holmes m...@philholmes.net To: lilypond-devel@gnu.org; David Kastrup d...@gnu.org Sent: Wednesday, October 17, 2012 6:24 PM Subject: Re: 2.17.5? - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, October 17, 2012 5:46 PM Subject: 2.17.5? Hi, can we get a release of 2.17.5 soonish? Since there are numerous files sporting a \version 2.17.5 header in master, it is impossible to let any patch requiring a convert-ly run itself be successfully reviewed while PATCH_LEVEL is still stuck at 5 since a reliable application of convert-ly rules can only happen when those convert at least to 2.17.6 now, and then LilyPond will refuse to compile them. I can put the required version bump into the reviewed issue itself, but that requires backing out before committing, obviously, and at that time at the latest it is necessary to have 2.17.5 released. -- David Kastrup I'm aiming for this weekend. Generally, I'm expecting to create a new release every 2 weeks. -- Phil Holmes For everyone's information, please note that the website is in a somewhat unusual state. Something (I don't know what - waiting on GP's thoughts) seems to have gone wrong with the website upload, and so most of it shows 2.17.4, but the manuals etc. are at 2.17.5. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix extra spacing in Kievan notation (issue 6684051)
On Tue, Oct 16, 2012 at 10:06 PM, aleksandr.andr...@gmail.com wrote: The GSoC issues do not deal with packed spacing, so this is somewhat different, though related. Do you have any ideas for how this issue could be addressed differently? Has there been any work on the various GSoC issues? Yes, and it waits to be merged to master. Unfortunately, some things need considerable discussion before merging, and i'm very short on time :( best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Create \temporary for doing overrides without pop-first set (issue 6687044)
There was some controversy with this patch, but it was counted down and noone found anything wrong with the actual code. Some people are not sure whether we want to have \temporary or something else, but they can change it in the future if they want. For now, this patch adds something that is missing and allows to fix some bugs, so i'm going to push it on Tuesday or so; there's no point in wasting David's work. cheers, janek http://codereview.appspot.com/6687044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.5?
Phil Holmes m...@philholmes.net writes: For everyone's information, please note that the website is in a somewhat unusual state. Something (I don't know what - waiting on GP's thoughts) seems to have gone wrong with the website upload, and so most of it shows 2.17.4, but the manuals etc. are at 2.17.5. I seem to remember that is standard behavior. At least I remember frequently reading something along the lines I am waiting for the website to update before officially announcing the release. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make scripts on Windows (cygwin)
2012/10/21 David Kastrup d...@gnu.org: Federico Bruni fedel...@gmail.com writes: [..] I've installed Cygwin and the packages needed for compiling (well, I hope so). If you are not interested in wasting the rest of your week (and probably the next month) throwing good time after bad time fighting things that almost, but not quite work, you should seriously give LilyDev a try. Its main motivation is not having gcc available (that one is perfectly available standalone on Windows) but rather all the little things when you just need to be able to run some make commands. I've installed LilyDev: very easy and fast (except for 1 GB download). Disclaimer: I have not touched either Windows, Cygwin, or virtual environments for years. But I still habe the scars to show. :-) But I get an error when I run configure: $ ./configure configure: error: cannot run /bin/sh stepmake/bin/config.sub $ sh sh.exe shasum shimeng.dll shrpubw.exe sha1sum.exe shdocvw.dll shimgvw.dll shsetup.dll sha224sum.exe shell32.dll shlwapi.dll shsvcs.dll sha256sum.exe shellstyle.dll shmtool.exe shuf.exe sha384sum.exe shfolder.dllshopt shunimpl.dll sha512sum.exe shgina.dll shpafact.dllshutdown.exe shacct.dll shift shred.exe shwebsvc.dll $ sh configure configure: error: cannot run /bin/sh stepmake/bin/config.sub Can any Windows user help me? Well, Cygwin has an idea of where /bin is situated. ls /bin might tell you that. Or maybe not. yes, he knows it and sh is there: $ ls /bin | grep ^sh sh.exe sha1sum.exe sha224sum.exe sha256sum.exe sha384sum.exe sha512sum.exe shasum shmtool.exe shred.exe shuf.exe No idea why it can't run that command. Nevermind, I'll use LilyDev. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New bar line interface: take whichBar into account (issue 6695046)
Was it not for Graham Percival, to whom i dedicate all my code reviews, i would have not find enough willpower to write a review! (seriously!) :) So, Marc, the problem is that convert-ly rule didn't convert commands involving whicBar context property? Like, \set Staff.whichBar = \|:\ should be converted to set Staff.whichBar = \.|:\? If so, please write it a bit more explicitely in the commit message, and reference Bar Line Interface's issue number and committish. Other than this, LGTM. cheers, Janek http://codereview.appspot.com/6695046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New bar line interface: include whichBar in convert-ly rule for bar line changes (issue 6695046)
Reviewers: janek, Message: On 2012/10/21 16:46:36, janek wrote: Was it not for Graham Percival, to whom i dedicate all my code reviews, i would have not find enough willpower to write a review! (seriously!) :) So, Marc, the problem is that convert-ly rule didn't convert commands involving whicBar context property? Like, \set Staff.whichBar = \|:\ should be converted to set Staff.whichBar = \.|:\? If so, please write it a bit more explicitely in the commit message, and reference Bar Line Interface's issue number and committish. Other than this, LGTM. cheers, Janek OK, will do. Description: This is a follow-up of Issue 2790 and commit cced43289cf170305e6e6517180659a1c4fa91db. The whichBar property is not set explicitly anywhere in the sources and thus was forgotten in the commit above. Please review this at http://codereview.appspot.com/6695046/ Affected files: M python/convertrules.py M scm/define-context-properties.scm Index: python/convertrules.py diff --git a/python/convertrules.py b/python/convertrules.py index 6eeb392ee4feda35bcb118feb8fb0b960aaefdf8..5d44fd7a150c7fb33e241c247330ae754392ff4f 100644 --- a/python/convertrules.py +++ b/python/convertrules.py @@ -3399,7 +3399,7 @@ def conv (str): matcharg + ), r\\shape\2\1, str) return str -barstring=r(\\bar|defaultBarType|segnoType|doubleRepeatType| startRepeatType|endRepeatType|doubleRepeatSegnoType|startRepeatSegnoType| endRepeatSegnoType)(\s*[=]?\s*[#]?) +barstring=r(\\bar|whichBar|defaultBarType|segnoType|doubleRepeatType| startRepeatType|endRepeatType|doubleRepeatSegnoType|startRepeatSegnoType| endRepeatSegnoType)(\s*[=]?\s*[#]?) @rule ((2, 17, 5), rNew bar line interface) def conv(str): Index: scm/define-context-properties.scm diff --git a/scm/define-context-properties.scm b/scm/define-context-properties.scm index c1c006cf06f0d347de07fdc5a0a3fb42bb4a13cd..76c5191bf1518b9a2e3e81eaefb274db877871d2 100644 --- a/scm/define-context-properties.scm +++ b/scm/define-context-properties.scm @@ -576,7 +576,7 @@ of bar line to create. Example: @example -\\set Staff.whichBar = \|:\ +\\set Staff.whichBar = \.|:\ @end example @noindent ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New bar line interface: include whichBar in convert-ly rule for bar line changes (issue 6695046)
Thanks, Marc! i suggest to abbreviate the committish (first 10 digits should be enough - git recognizes abbreviated committishes as long as they are unique) - first line of the commit message should be around 50-60 chars for the sake of nice display in logs. best sorry for nitpicking LGTM, Janek http://codereview.appspot.com/6695046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Busy Developers' Summary 2: what happened this week
Hi all, second issue of BDS - this week was definitely less busy than previous one. __ It seems that we're finally close to removing misleading deprecated old website (lilypond.org/web/) - see http://code.google.com/p/lilypond/issues/detail?id=1272 It was decided (i.e. nobody came up with a better idea) to dump the results of the GLISS user poll (conducted by Harm on the German LilyPond forum) into the tracker: http://lists.gnu.org/archive/html/lilypond-devel/2012-10/msg00543.html David Kastrup discovered that override, which operates on property stacks, is (contrary to what one might think) not a push, but a pop+push. Because of that, it's impossible to make a temporary override and then go back to previous (non-default) value. There was a lot of controversy about the desired naming and design of various property-changing commands; as a result David got frustrated and abandoned his patch. Since the patch itself works, i'm going to push it on Tuesday so as to not waste David's work - if we decide that we want a different design, we can always change it later. http://lists.gnu.org/archive/html/lilypond-devel/2012-10/msg00432.html https://codereview.appspot.com/6687044/ http://lists.gnu.org/archive/html/lilypond-devel/2012-10/msg00562.html Discussion about allowing to specify context-grob-properties arguments without #' continues (Context.Grob considered as symbol list and others). If i understand correctly, http://codereview.appspot.com/6651053 reflects the current state of this (very cool!) proposal. smile! I think David will be happy to hear that his work is awesome :) (or hear some constructive criticism ;) ) /smile! __ If i missed anything (quite likely, since i'm just skimming most of the emails), add it in a reply! I think it would also be great if David wrote a short summary about the status of Context.Grob considered as symbol list. best, and see you on Tuesday Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20121023
For 20:00 MDT Tuesday October 23 Enhancement: Issue 2445 http://code.google.com/p/lilypond/issues/detail?id=2445: Center a number above a measure - R 6730044 http://codereview.appspot.com/6730044/ Issue 2914 http://code.google.com/p/lilypond/issues/detail?id=2914: Patch: prevent collision of ligatures and next note - R 6740046 http://codereview.appspot.com/6740046/ Issue 2915 http://code.google.com/p/lilypond/issues/detail?id=2915: Patch: New bar line interface: adds volta bracket regtest; minor changes - R 6737051 http://codereview.appspot.com/6737051/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
