Re: New short and long lyric ties. (issue 4912041)
Pushed as 2fff263f10fd542454455994aea5ff3bbe075c7d http://codereview.appspot.com/4912041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add some polyphonically directed grobs (issue 4387046)
Pushed as f9251331576c94fa6aa4b85776917d3774b13b63 http://codereview.appspot.com/4387046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
documentation: regtests with assertions, --disable-optimising
Hey all, Since --disable-optimising enables assertion, making regtests should be done with that option, as Neil Puttock mentioned http://codereview.appspot.com/4974075/#msg12 I think it's useful to add a note about this in the documentation in chapter 9.3 Compiling regression testshttp://lilypond.org/doc/v2.15/Documentation/contributor-big-page#compiling-regression-tests . It seems I'm not the only one who didn't know. Piers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
All of the previously-reported bugs are now squashed with this newest patchset: the regtests only show two changes that results in things moving (and one change that shows nothing moving but a lot of green...weird), both of which seem to be welcome side effects of the code consolidation in beam-quanting. Cheers, MS http://codereview.appspot.com/4961041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
musicxml2ly: use either work-title or movement-title as title
Hey Reinhold, here is a small patch for the title issue. hth patrick 0001-musicxml2ly-use-either-work-title-or-movement-title-.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
ianhuli...@gmail.com writes:
Looks pretty cool, apart from some involved Scheme which I couldn't
really unravel totally (see below).
Will this patch allow us to get rid of the abomination of
\afterGraceFraction by recasting \afterGrace to have an optional
parameter
\afterGrace {note} {gracenotes} [spacing-fraction]
You'd rather have to make this
\afterGrace [spacing-fraction] {note} {gracenotes}
or similar. I am not too clear on just what would work as an argument
type for spacing-fraction. Scheme as in #'(15 . 16) or a duration as in
1*15/16 (ugh, what with the 1?).
Personally, I'd likely just go for
\afterGrace \times 15/16 {note} {gracenotes}
\afterGrace can easily check whether it gets scaled music and unpack
it. If you really want to write scaled music, you can do so as
\afterGrace { \times 15/16 ...
in which case you get a sequential music event as topmost expression
which you leave alone.
This will turn out weird if you did
somemacro = \times 2/3 { }
and then use
\afterGrace \somemacro ...
because then you'll likely have no idea what happens. Or if you do
\afterGrace on tuplets without bothering to enclose them in braces.
This would work fine without involving any functionality from this patch
series.
Or you do
\afterGrace [spacing-duration] ...
instead and forget about the fraction (durations can be fractions after
all).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1873 in lilypond: Added glyphs for Kievan Notation
Janek, 2011/9/18 Janek Warchoł janek.lilyp...@gmail.com: 2011/9/18 Janek Warchoł janek.lilyp...@gmail.com: 2011/9/16 Aleksandr Andreev aleksandr.andr...@gmail.com: If I recall correctly, undocumented glyphs will break the build (see Documentation/included/font-table.ly). Neil is correct, the documentation won't compile, it gives the message: Unlisted glyphs in Documentation/included/font-table.ly I've added the necessary code to font-table.ly However, my documentation still won't compile. I get the following message: cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 make[3]: Leaving directory `/home/sasha/lilypond-git/build/Documentation/de' make[2]: *** [WWW-1] Error 2 rm out-www/weblinks.itexi make[2]: Leaving directory `/home/sasha/lilypond-git/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/sasha/lilypond-git/build' make: *** [doc-stage-1] Error 2 Doesn't look like this has something to do with the Kievan glyphs. What is web.texi? web.texi is a file in Documentation/ directory, but I don't know why such an error could appear... This is one of those messages that is misleading. I get this (and a variation of this with Authors.texi) all the time usually because 1. I forgot to make before I make doc 2. I applied a patch with some incorrect syntax 3. I did a git pull and there was a change that meant I should have done a ../configure (assuming you are using an out of tree build) (for example a load of branch merges from translation since my last pull). As Mike says, for the sake of a few minutes to run ../configure ; make It maybe easier to nuke the out of tree build dir and start again. I've been doing make and make doc so many times every day that you end up knowing which 'errors' you can ignore and which you can just run 'make' again and it will just work. We know that the build system for doc is not perfect, but we are getting there slowly. Regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: possible bad output in mensural-ligatures.ly
i've noticed something strange in mensural-ligatures.ly: in the last system, a flat symbol collides with the notes (attached). Should it look like this? this is an impossible ligature, LilyPond should (but never did) refuse it (with an explanation). (note that accidentals are very rare in mensural music and practically nonexistent within ligaturae.) p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds StemTremolo to the note column's element list. (issue 5067041)
On 2011/09/19 05:45:04, MikeSol wrote: While working on flags, I noticed that horizontal spacing changes when a grob is part of a NoteColumn's element list. I went back to StemTremolos and tested this out: run the code below with and without this patch: I'm getting deja vu here Mike. Wasn't this your original idea for fixing the collisions with tremolos? Are you saying we need both the pure-height function *and* the addition of StemTremolo to NoteColumn's elements array? Cheers, Neil http://codereview.appspot.com/5067041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds StemTremolo to the note column's element list. (issue 5067041)
On Sep 19, 2011, at 7:02 PM, n.putt...@gmail.com wrote: On 2011/09/19 05:45:04, MikeSol wrote: While working on flags, I noticed that horizontal spacing changes when a grob is part of a NoteColumn's element list. I went back to StemTremolos and tested this out: run the code below with and without this patch: I'm getting deja vu here Mike. Wasn't this your original idea for fixing the collisions with tremolos? Indeed, but it was my idea only because I had no clue what I was doing. I still have no clue what I'm doing, but I have a better sense how to frame that about which I have no clue. Are you saying we need both the pure-height function *and* the addition of StemTremolo to NoteColumn's elements array? Yup. Or rather not that we need this, but that: (a) StemTremolos in the element array result in different visual output from their not being part of the element array; and (b) Given that the stem, arpeggio, and flag are part of the element array, it seems that the StemTremolo belongs to this family and should thus have the same impact on spacing (meaning it should belong to the array). What I'd really like to know is why the spring ideal and minimum distances are different just by virtue of its belonging to the array, but I have a feeling the answer lies deep in the bowels of the horizontal spacing code and I don't have time to get to the bottom of that in the foreseeable future. For now, it seems like this is the right move to take. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)
http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm File scm/document-identifiers.scm (right): http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm#newcode31 scm/document-identifiers.scm:31: On 2011/09/18 22:57:39, Bertrand Bordage wrote: Why a new line? Done. http://codereview.appspot.com/4974078/diff/3001/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/4974078/diff/3001/scm/lily.scm#newcode353 scm/lily.scm:353: (ly:format On 2011/09/18 22:57:39, Bertrand Bordage wrote: Err... Why is this required? Be careful with the indentation: there shouldn't be tabulators. ly:format call removed, tabs converted to spaces. http://codereview.appspot.com/4974078/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)
New patch-set uploaded. Ian http://codereview.appspot.com/4974078/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 13: patch management tools
Appropriately enough for “unlucky” number 13, this proposal is not well-prepared. However, I’m bringing it forward in in the interest of transparency and possibly gathering momentum. http://lilypond.org/~graham/gop/gop_13.html ** Proposal summary There is a fair amount of confusion with the current setup. Let’s either: 1. Find a different patch management tool 2. Find a different patch and issue management tool 3. Write a few python scripts to make our lives better I favor the last option. ** Rationale Nobody seems happy with the current state of affairs. ** Different patch and issue managment tools There are a few alternatives that have been mentioned. I spent about two minutes looking at each website while having my Sunday dinner (can of corn, cheddar cheese, and a handful of strawberries), and I’m not impressed. Of course, this is an absolutely RIDICULOUSLY insignificant amount of effort to spend on something this fundamental to our project. If anybody wants to seriously examine some or all of these, I’m happy to withdraw this proposal until we have some actual evidence. * http://github.com: has an issue tracker, but it’s rather limited. Nice merging capabilities, though. * http://code.google.com/p/gerrit/: appears to be a fork of Rietveld. Not certain about hosting. * http://trac.edgewall.org/: based on a wiki, requires a host. * http://www.redmine.org/: written in ruby, require a host. * http://codestriker.sourceforge.net/: not certain about git support. * http://www.reviewboard.org/: offers hosting. ** Integrated tool? There is some desire to have an integrated tool to handle both issues and patches. At the present time, I am against any move away from our google code issue tracker. * We don’t want to host any tracker ourselves; google has more bandwidth than God, and anecdotally the issue tracker is very stable. It becomes read-only for a few hours once every couple of months, but that’s no problem. * We have a huge investiment in the current issue tracker; moving hundreds of bugs would be a pain. Trust me, I was the one who added the old bugs from cvs to the current tracker. * Google code issue tracker has the slickest interface for bug handling that I’ve ever seen. I’m not saying there’s not some unknown system out there that rocks, but in all my years of experience with numberous open-source projects, google code is far better than anything else. ** Python scripts Instead of a different tool, I think we should automate tasks with python. Google code has a python api which is absolutely fantastic: http://code.google.com/p/support/wiki/IssueTrackerAPIPython With that api, we can automatic a lot, with very little programming time required: * 30-120 minutes: modify git-cl to automatically add a Patch-new issue whenever there’s an upload. If the issue description contains issue 1234 or fix 1234, it adds the rietveld url to the appropriate issue instead. I’ve already forked the git-cl repo and started work on this on https://github.com/gperciva/git-cl * 1-3 hours: write a script that checks that every Patch-new can apply to master, compiles correctly, and creates a regtest comparison so the local human can check it and make it Patch-review instead. If there’s a problem before the regtest comparison, the script automatically changes it to Patch-needs_work. * 1-2 hours: script that creates the patch countdowns. Any patch for a Type-Critical or Type-Maintainability is included, then it brings the total up to 10 patches, and sends the email to -devel. * 1-5 hours: automatically switch any Patch-review to Patch-needs_work if there are any non-LGTM comments. * 30-60 minutes: moves any Patch-needs_work to Patch-abandoned after 100 days of inactivity. * Almost certainly more. ** Implementation notes Now that I’ve seen how nice the gdata API is, I’m sorely tempted to cancel GOP for the next couple of weeks so that I can write all the scripts myself. If somebody else wants to do it (with or without any mentoring from me), that’s fine. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
Am Tuesday, 20. September 2011, 01:09:20 schrieb Graham Percival: ** Different patch and issue managment tools I have only looked at a few code review tools... * http://code.google.com/p/gerrit/: appears to be a fork of Rietveld. Not certain about hosting. While gerrit is tailored for git, it is really limited to git. E.g. -) You can only upload whole commits and each commit will have one separate review. With rietveld we can have a review for the diff of several commits combined, with gerrit you will have one review per commit. -) To submit a review, you have to push to a really strange gerrit branch on the server, so you have to know quite a lot about git, or accept some strange syntax... Definitely not something we want to require from newcomers or non- coders. * http://www.reviewboard.org/: offers hosting. The problem is that there is no simple tool to create a review. There are some python scripts, but they need separate installation (as administrator) using some custom python installation framework, and there is no tool like git-cl to store the issue within the branch. * 30-120 minutes: modify git-cl to automatically add a Patch-new issue whenever there’s an upload. If the issue description contains issue 1234 or fix 1234, it adds the rietveld url to the appropriate issue instead. I’ve already forked the git-cl repo and started work on this on https://github.com/gperciva/git-cl BTW, we can also install a post-commit hook on the git server that closes an issue if the commit message contains something like Fixes # or so. KDE uses keywords: BUG: ... (closes the given bug(s)) CCBUG: ... (adds the commit msg as a comment to the bug(s)) CCMAIL: ... etc. * 1-3 hours: write a script that checks that every Patch-new can apply to master, compiles correctly, and creates a regtest comparison so the local human can check it and make it Patch-review instead. If there’s a problem before the regtest comparison, the script automatically changes it to Patch-needs_work. The problem is that if someone pushes a broken commit, it will cause all patches to Patch-needs_work, even if the patch is not to blame... * 1-5 hours: automatically switch any Patch-review to Patch-needs_work if there are any non-LGTM comments. If one of my comments does not contain LGTM, that does NOT mean that I have objections. Rather, I might be giving some input and ideas, or have a question, but I just don't feel qualified enough to give the go. If I object to a patch, I clearly state it. Absense of LGTM does definitely NOT mean my objection. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On Tue, Sep 20, 2011 at 02:08:42AM +0200, Reinhold Kainhofer wrote: Am Tuesday, 20. September 2011, 01:09:20 schrieb Graham Percival: ** Different patch and issue managment tools * 1-3 hours: write a script that checks that every Patch-new can apply to master, compiles correctly, and creates a regtest comparison so the local human can check it and make it Patch-review instead. If there’s a problem before the regtest comparison, the script automatically changes it to Patch-needs_work. The problem is that if someone pushes a broken commit, it will cause all patches to Patch-needs_work, even if the patch is not to blame... That's why the script would/should check that master compiles, before trying any of the patches. Naturally, if master fails, it sends a panic email to lilypond-devel. That email would include a list of all people who pushed to master since the last commit which is known to compile. Whatever happens with the patch tools, I'm imagining a does master compile script running at least once every 24 hours. * 1-5 hours: automatically switch any Patch-review to Patch-needs_work if there are any non-LGTM comments. If one of my comments does not contain LGTM, that does NOT mean that I have objections. Rather, I might be giving some input and ideas, or have a question, but I just don't feel qualified enough to give the go. If I object to a patch, I clearly state it. Absense of LGTM does definitely NOT mean my objection. That's a question of how much intelligence+time we want to put into this script... and of course the behaviour of any of these scripts can (and should!) be overridden by the Patch Meister (or any developer, really) at the first sign of trouble. Even if we have a completely stupid LGTM or bust patch, the Patch Meister just weighs: - examine all patches from the countdown, then mark them Patch-needs_work or Patch-push? - examine all patches marked Patch-needs_work from a script, and check that it's valid - examine nothing until a programmer complains about a false Patch-needs_work. I think a false negative would happen about 10% of the time. Is it worth it? maybe yes, maybe not... hey, we could even throw some Bayesian machine learning into the process! :) At this point, I'm not endorsing any particular behavior of these scripts; I'm just saying that the python gdata modules gives us an enormous amount of power to automate whatever we want to automate. I think we should pursue this option, rather than trying to move to different hosting tool(s). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On 11-09-19 06:25 PM, Graham Percival wrote: On Tue, Sep 20, 2011 at 02:08:42AM +0200, Reinhold Kainhofer wrote: Am Tuesday, 20. September 2011, 01:09:20 schrieb Graham Percival: ** Different patch and issue managment tools * 1-3 hours: write a script that checks that every Patch-new can apply to master, compiles correctly, and creates a regtest comparison so the local human can check it and make it Patch-review instead. If there’s a problem before the regtest comparison, the script automatically changes it to Patch-needs_work. The problem is that if someone pushes a broken commit, it will cause all patches to Patch-needs_work, even if the patch is not to blame... That's why the script would/should check that master compiles, before trying any of the patches. Naturally, if master fails, it sends a panic email to lilypond-devel. That email would include a list of all people who pushed to master since the last commit which is known to compile. Whatever happens with the patch tools, I'm imagining a does master compile script running at least once every 24 hours. * 1-5 hours: automatically switch any Patch-review to Patch-needs_work if there are any non-LGTM comments. If one of my comments does not contain LGTM, that does NOT mean that I have objections. Rather, I might be giving some input and ideas, or have a question, but I just don't feel qualified enough to give the go. If I object to a patch, I clearly state it. Absense of LGTM does definitely NOT mean my objection. That's a question of how much intelligence+time we want to put into this script... and of course the behaviour of any of these scripts can (and should!) be overridden by the Patch Meister (or any developer, really) at the first sign of trouble. Even if we have a completely stupid LGTM or bust patch, the Patch Meister just weighs: - examine all patches from the countdown, then mark them Patch-needs_work or Patch-push? - examine all patches marked Patch-needs_work from a script, and check that it's valid - examine nothing until a programmer complains about a false Patch-needs_work. I think a false negative would happen about 10% of the time. Is it worth it? maybe yes, maybe not... hey, we could even throw some Bayesian machine learning into the process! :) As the Patch Meister in question, it would be nice to have a guaranteed link between the tracker and Rietveld, such that every patch on Rietveld has a corresponding tracker number. ATM, it is pretty much impossible to find a list of lilypond=-related patches on Rietveld without doing a search on each developer's login, where they are known to the Patch Meister. Given the one-to-one link, we're looking in a single, well-understood place, and finding everything related to issues (bugs and enhancements) with associated patches (bug fixes and proposed enhancements). My python is diplomatically described as rudimentary, but Graham's suggestions sound like the way to go, IMHO. 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
Re: Glyphs for Kievan Notation (issue 4951062)
Fixed alignment issue based on comments by lemzwerg. http://codereview.appspot.com/4951062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20110921
For 22:00 MDT Wednesday September 21, and *far* too early for an Autumnal equinox! Issue 1898 http://code.google.com/p/lilypond/issues/detail?id=1898: Unifies mensural ligatures with blot-diameter - R 5030053 http://codereview.appspot.com/5030053/ Issue 1894 http://code.google.com/p/lilypond/issues/detail?id=1894: Prunes stem::length down to the bare minimum - R 5057041 http://codereview.appspot.com/5057041/ Issue 155 http://code.google.com/p/lilypond/issues/detail?id=155: \parenthesize does not take accidentals into account - R 5047048 http://codereview.appspot.com/5047048/ (bonus points for the age of this dude, Joe!) Issues 1193 http://code.google.com/p/lilypond/issues/detail?id=1193: Enhancement: internal ledger lines and1292 http://code.google.com/p/lilypond/issues/detail?id=1292: Enhancement: twelve-notation support - R 4974075 http://codereview.appspot.com/4974075/ Issue 1301 http://code.google.com/p/lilypond/issues/detail?id=1301: Strange collision of note and clef - R 4841052 http://codereview.appspot.com/4841052/: Progress on loose columns. Issue 1663 http://code.google.com/p/lilypond/issues/detail?id=1663: Images missing on web site - R 4963046 http://codereview.appspot.com/4963046/ Issue 1889 http://code.google.com/p/lilypond/issues/detail?id=1889: Lilypond-book: Improve options handling by processing everything in one place - R 5030044 http://codereview.appspot.com/5030044/ Issue 1890 http://code.google.com/p/lilypond/issues/detail?id=1890: Compiler warnings in make on 64-bit systems - R 5039043 http://codereview.appspot.com/5039043/ Issue 1891 http://code.google.com/p/lilypond/issues/detail?id=1891: New alist to replace special characters - R 4553056 http://codereview.appspot.com/4553056/ Issue 1893 http://code.google.com/p/lilypond/issues/detail?id=1893: Terminates outside_staff_callback early if a grob is outside a slur's X-extent - R 5056041 http://codereview.appspot.com/5056041/ Issue 935 http://code.google.com/p/lilypond/issues/detail?id=935: Enhancement: optional arguments in music functions - R 5023044 http://codereview.appspot.com/5023044/ 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
Re: PATCH: Countdown to 20110921
Colin Campbell c...@shaw.ca writes: Issue 935: Enhancement: optional arguments in music functions - R 5023044 Cancel countdown. I am still fuzzing with avoiding O(n^2) rules for n syntax classes, and trying to cater for multiple optional arguments in a row. Doing both is a challenge requiring quite a bit of cleanup, and applying the current patch would be a step backward. Hope to get something working soon. I have a working version right now, but don't like to leave ~80 shift/reduce conflicts (basically 2n with n being the number of terminal symbols that may start an argument). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 155: parentheses include accidentals and dots. (issue 5047048)
Hey Joe, For some reason, the scm files say Upload in progress. This may come from a MIME type issue for scm files (upload.py doesn't know that scm files correspond to Scheme language files). I forget how to fix this, but I know the fix has been suggested somewhere on the list. Cheers, MS http://codereview.appspot.com/5047048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
Hey Bertrand, Could you show an example, in the regtest, of how one would write: ndash; (or whatever) such that ndash; appeared (meaning the string ndash; - not the replacement n-dash). http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 155: parentheses include accidentals and dots. (issue 5047048)
Thanks, I've re-uploaded it and it seems to work now. Joe On Mon, Sep 19, 2011 at 10:19 PM, mts...@gmail.com wrote: Hey Joe, For some reason, the scm files say Upload in progress. This may come from a MIME type issue for scm files (upload.py doesn't know that scm files correspond to Scheme language files). I forget how to fix this, but I know the fix has been suggested somewhere on the list. Cheers, MS http://codereview.appspot.com/5047048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
On Mon, Sep 19, 2011 at 9:35 PM, David Kastrup d...@gnu.org wrote:
Colin Campbell c...@shaw.ca writes:
Issue 935: Enhancement: optional arguments in music functions - R
5023044
Cancel countdown. I am still fuzzing with avoiding O(n^2) rules for n
syntax classes, and trying to cater for multiple optional arguments in a
row. Doing both is a challenge requiring quite a bit of cleanup, and
applying the current patch would be a step backward. Hope to get
something working soon. I have a working version right now, but don't
like to leave ~80 shift/reduce conflicts (basically 2n with n being the
number of terminal symbols that may start an argument).
Have you considered adding a special syntax for optional arguments?
Like \foo[opt]{mandatory} in tex...
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
