Re: Problem with uploading patch
Hi Harm, On Fri, Jul 13, 2012 at 11:38 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Hi Janek, UFF!! Thanks a lot. Your hint about the wrong server was it. I overlooked it in the log and I've absolutely no idea how it could happen that the server was changed. Glad i helped! BTW, git config -e opened an editor where I could change that. Nice, i didn't know about it. PS it would be cool to do some git workshops one day. Are you coming to David's place in August? Hm, I havn't talked to David about it. My problem is, that my vacations are terminated then, I've to work the whole weeks before and after that weekend. I could arrive Saturday noon at the earliest and had to take off Sunday evening. Does this make sense? I don't know how far from David do you live, but if you're in Germany or Benelux, i'd say it makes sense. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: clear policy discussions
On Sat, Jul 14, 2012 at 4:56 AM, Graham Percival gra...@percival-music.ca wrote: David, I realize that you are angry, but please stop using words like monkey I'm responsible for monkey. You asked to stop using it, but i continued to do so (not because of malice - i just didn't find good replacement). I apologize. We are currently discussing how to change it, so I see little benefit in arguing over precisely how bad the current policy is. Hear, hear! +10 Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with uploading patch
Janek Warchoł janek.lilyp...@gmail.com writes: Hi Harm, On Fri, Jul 13, 2012 at 11:38 PM, Thomas Morley thomasmorle...@googlemail.com wrote: Hi Janek, UFF!! Thanks a lot. Your hint about the wrong server was it. I overlooked it in the log and I've absolutely no idea how it could happen that the server was changed. Glad i helped! BTW, git config -e opened an editor where I could change that. Nice, i didn't know about it. PS it would be cool to do some git workshops one day. Are you coming to David's place in August? Hm, I havn't talked to David about it. My problem is, that my vacations are terminated then, I've to work the whole weeks before and after that weekend. I could arrive Saturday noon at the earliest and had to take off Sunday evening. Does this make sense? I don't know how far from David do you live, 2 hours by car. Not much more by train except for the final 10 miles. Placing the meeting across a weekend was quite intended to cater for time limitations of semi-local participants. but if you're in Germany or Benelux, i'd say it makes sense. Yup. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line_count fixes (issue 6211047)
http://codereview.appspot.com/6211047/diff/20001/lily/bar-line.cc File lily/bar-line.cc (right): http://codereview.appspot.com/6211047/diff/20001/lily/bar-line.cc#newcode151 lily/bar-line.cc:151: Real const gap_to_find = (1.0 + 3 * staffline) / staff_space; It seems you want Real const gap_to_find = (dot.extent(Y_AXIS).length() + 3 * staffline ) / staff_space *2 ; where the *2 is because you compare the gap_to_find with differences of staff positions, and the distance of a staff space is two positions (as E to G). http://codereview.appspot.com/6211047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sets TabVoice Stem height to ##f (issue 6303065)
http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc#newcode710 lily/stem.cc:710: if (calc_beam !beam !unsmob_stencil (me-get_property (stencil))) On 2012/06/11 16:33:27, Keith wrote: If you have time to test the output, consider removing the test for calc_beam, Bad suggestion, apparently, given that it disconnects the stems form merged triangle note-heads. I'll put back the test for calc_beam after I get through regression testing. http://codereview.appspot.com/6303065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable 2.16 releases (dictator)
On Sat, Jul 14, 2012 at 6:15 AM, Graham Percival gra...@percival-music.ca wrote: Let’s appoint David Kastrup as the “benevolent dictator” of the stable/2.16 git branch. +1 Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2: 2 - Stable releases and roadmap (radical change)
On Sat, Jul 14, 2012 at 6:31 AM, Graham Percival gra...@percival-music.ca wrote: On Wed, Jul 11, 2012 at 05:48:48PM +0200, Janek Warchoł wrote: On Tue, Jun 26, 2012 at 10:55 PM, Graham Percival gra...@percival-music.ca wrote: To avoid slowing down programming to a crawl, I figure that we’ll identify some subset of these regtests and have a separate make regtests-quick command which only evaluates that subset. As a rule of thumb, I’d say that the regtests-quick target should take as long as a make from scratch. *very* good idea! +20 Well, there's no reason why this needs to be tied to a specific release policy. There's certainly no harm in implementing the basic infrastructure of make regtests-quick, leaving any debate about exacty which files qualify for the quick test. Problem is, somebody needs to sit down and do it. Do you feel like adding that? ok, but not until GSoC finishes. If anyone else is interested, go for it. - 10-100 (?) hours of helpful users organizing and writing .ly files to cover all (? or most?) functionality I can help here. - somebody to organize the entire effort I can help here. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable 2.16 releases (dictator)
Graham Percival gra...@percival-music.ca writes: I will officially introduce this next Tuesday, but since it's now a hot topic, let's have an extra round of discussion and fixing before then. http://lilypond.org/~graham/gop/gop_3.html *** Summary Let’s appoint David Kastrup as the “benevolent dictator” of the stable/2.16 git branch. Well, it definitely makes sense before an extra round of discussion that I acknowledge to be willing to take that job. Which I do. I don't commit to more than that at the current point of time (it is still quite likely that I will have to abandon LilyPond in order to make a living), and it is also possible that I will at one point of time seek out a transfer of control. After the first release, the focus of branch maintenance will go from _defining/shaping_ a stable release to _maintaining_ it. That seriously changes the importance of avoiding new regressions even of minor nature, and rules out most useful changes that are not strictly confined in effect on current behavior and/or bugfixes. While the next stable release branch is far from being released, well-isolated _additions_ in functionality without effect on previously valid files may be subject to consideration. In any case, after the first release of the stable branch decisions on it should become quite more conservative, and it may be that handing responsibility off might make for a better fit. It is also conceivable that a rule-based approach will work better when the release urgency is gone, though I consider it likely that overruling automatisms would more likely happen in the opposite direction, namely excluding updates that may have passed the formal review times, but which the maintainer is not sufficiently confident about. Long talk short: this is not as much a policy but a plan. It does not tell us how to proceed once the plan has reached its goals (or failed to do so), something which a policy would. But I think we will be better set to draft a formal policy when we have seen the outcome from this plan. [...] To complete the discussion David and I were having about the possibility of using revert as an option to fix a critical bug, I looked at a few recent critical regressions, namely those which caused Release Canditates 6 and 7 to be abandoned. None of these could have been easily fixed by reversion, either because the fix was complicated, the original source was too old for revert to be safe, or the cause was external to LP. So reversion offers no easy answer. It will likely often be a good answer. Just not reliably enough to turn it into a hard and fast rule. *** Details The policy is: David Kastrup has sole authority over what goes into stable/2.16 and which release(s) will have a version number of 2.16.x, until 2012 Dec 31. Or until he asks to relinquish control, or there is sufficient agreement among core developers that he should. In more detail, this means: - he decides when to have 2.16.0. - he may classify issues as being issue-Critical, but he can still make a 2.16.x release even if there are Critical issues if he chooses to do so. Nobody else can denote issues as being Critical. Being able to look at a list of Critical issues is useful to make sure no oversights happen. So I'd propose that we use the same rules as before for marking issues as Critical (in particular, letting a regression automatically imply a Critical issue), but that I have the leeway of downmarking and/or ignoring them. I am not entirely happy with that, partly because we have too few categories of Critical, and I think not all of what may be considered Critical is really exclusively related to the next stable release. - translators do not merge or cherry-pick onto stable/2.16 unless specifically requested to do so. Or the other direction. stable/2.16 will basically be a candidate for release, and if that candidate is dropped, the next candidate quite possibly is not a direct descendant of the previous candidate, since usually a candidate will be some unstable release plus additional fixes/reverts/cherry-picks. So nobody should cherry-pick or merge _from_ this branch either, in particular not into the mainline, since release-specific fixes might be unsuitable for the development branch. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A series of gitdiff patches from offline development
Am 13.07.2012 10:08, schrieb ArnoldTheresius: Well, I found it so ugly the Segno in the staff does not cooperate with the \repeat volta command. I installed on my WIN7 offline computer the lilydef VM, got a tarball from GIT (HTML user interface), and tested my ideas to change it. In contact with harm6 and Marc Hohl on this toppic, I had a look to the 'end hook suppression on the volta brackets based on the barline type'. There I worked to move the 'list of bar lines' from C++ source code to a staff context property. Next I had the idea to suppress the 'repeated triggers due to grace notes during the same main moment' in the engravers for the repeat bar lines (by \repeat command) and for the volta bracket. The idea of Marc Hohl was, to make these topic separete pathes, so now I have exported three git diff extractions to files. Here a short description of my diffs: [...] What shall I do next? Post the three files (11 KB, 6 KB, 5 KB) here in the mailing list? I think this would be the best opinion. Regards, Marc Or somewhere in http://git.sv.gnu.org/gitweb/?p=lilypond.git ? ArnoldTheresius ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable 2.16 releases (dictator)
David Kastrup wrote Saturday, July 14, 2012 9:30 AM Graham Percival gra...@percival-music.ca writes: Let’s appoint David Kastrup as the “benevolent dictator” of the stable/2.16 git branch. I'm happy to go along with this. It's hardly a policy, but it will definitely move things along! Well, it definitely makes sense before an extra round of discussion that I acknowledge to be willing to take that job. Which I do. Thanks David. After the first release, the focus of branch maintenance will go from _defining/shaping_ a stable release to _maintaining_ it. That seriously changes the importance of avoiding new regressions even of minor nature, and rules out most useful changes that are not strictly confined in effect on current behavior and/or bugfixes. While the next stable release branch is far from being released, well-isolated _additions_ in functionality without effect on previously valid files may be subject to consideration. I don't understand exactly what you are saying here. I get the drift, but it would be helpful if you could explain it with reference to stable branches and master more precisely. In any case, after the first release of the stable branch decisions on it should become quite more conservative, and it may be that handing responsibility off might make for a better fit. It is also conceivable that a rule-based approach will work better when the release urgency is gone, though I consider it likely that overruling automatisms would more likely happen in the opposite direction, namely excluding updates that may have passed the formal review times, but which the maintainer is not sufficiently confident about. So during some period a few weeks prior to the next stable, selected updates passing review might be marked 'patch-hold' rather than 'patch-push'? I'd be happy with that. - he decides when to have 2.16.0. - he may classify issues as being issue-Critical, but he can still make a 2.16.x release even if there are Critical issues if he chooses to do so. Nobody else can denote issues as being Critical. Being able to look at a list of Critical issues is useful to make sure no oversights happen. So I'd propose that we use the same rules as before for marking issues as Critical (in particular, letting a regression automatically imply a Critical issue), but that I have the leeway of downmarking and/or ignoring them. I suggest that you keep any such decision to yourself until just before the next stable is built, or defer making it until then. Otherwise interest in fixed such bugs will wane. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable 2.16 releases (dictator)
Trevor Daniels t.dani...@treda.co.uk writes: David Kastrup wrote Saturday, July 14, 2012 9:30 AM After the first release, the focus of branch maintenance will go from _defining/shaping_ a stable release to _maintaining_ it. That seriously changes the importance of avoiding new regressions even of minor nature, and rules out most useful changes that are not strictly confined in effect on current behavior and/or bugfixes. While the next stable release branch is far from being released, well-isolated _additions_ in functionality without effect on previously valid files may be subject to consideration. I don't understand exactly what you are saying here. I get the drift, but it would be helpful if you could explain it with reference to stable branches and master more precisely. Priorities may change after the first stable release of a major version branch. With respect to this proposal: priorities may change after 2.16.1. In any case, after the first release of the stable branch decisions on it should become quite more conservative, and it may be that handing responsibility off might make for a better fit. It is also conceivable that a rule-based approach will work better when the release urgency is gone, though I consider it likely that overruling automatisms would more likely happen in the opposite direction, namely excluding updates that may have passed the formal review times, but which the maintainer is not sufficiently confident about. So during some period a few weeks prior to the next stable, selected updates passing review might be marked 'patch-hold' rather than 'patch-push'? I'd be happy with that. No. Development is not affected unless I specifically ask for it. But it need not really be put into a policy. If it turns out that it is necessary, I expect other developers to listen like I would listen to them in turn if they have a problem affecting their work. Basically the only policy this boils down to is people committing patches should read lilypond-devel regularly. We might consider special subject lines to make it easier to keep track of important things. Again, this is not specific to the 2.16 release process in itself. - he decides when to have 2.16.0. - he may classify issues as being issue-Critical, but he can still make a 2.16.x release even if there are Critical issues if he chooses to do so. Nobody else can denote issues as being Critical. Being able to look at a list of Critical issues is useful to make sure no oversights happen. So I'd propose that we use the same rules as before for marking issues as Critical (in particular, letting a regression automatically imply a Critical issue), but that I have the leeway of downmarking and/or ignoring them. I suggest that you keep any such decision to yourself until just before the next stable is built, or defer making it until then. Otherwise interest in fixed such bugs will wane. And in the interest of making a release, I want to have people prioritize on those bugs that will affect the release. That's the main point of having priorities in the first place. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: clear policy discussions
Graham Percival gra...@percival-music.ca writes: On Fri, Jul 13, 2012 at 06:23:57PM +0100, Phil Holmes wrote: - Original Message - From: Trevor Daniels t.dani...@treda.co.uk a) a release-meister with responsibility to take all decisions. That's what Han-Wen used to do, I believe. It worked quite well, although Graham will have more of an inside view than I. It worked well in general, but not without a few quirks. The 2.12 release caught many people off guard: http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00553.html http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00602.html I also recall that the translators wanted additional notice so that they could clear up some loose ends before a major stable release. The current setup was in large part a reaction to that confusion -- make it absolutely clear to absolutely everybody when a release would happen, and therefore avoid any panic list of major problems discovered in the actual release. Well, it makes perfect sense to announce release plans and decision criteria in advance when imminent within a short time span. I would expect this to catch fewer people off-guard than springing a release on them according to some rules written years before in the CG. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: clear policy discussions
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Jul 14, 2012 at 4:56 AM, Graham Percival gra...@percival-music.ca wrote: David, I realize that you are angry, but please stop using words like monkey I'm responsible for monkey. You asked to stop using it, but i continued to do so (not because of malice - i just didn't find good replacement). I apologize. I think I started it. Sorry for that. There actually was no disrespect towards any person intended: I used it to describe the minimum requirements the current policies were relying on from a release manager, and apart from being a loaded term, it is actually inaccurate since monkeys are not particularly known for following instructions. Robot would have been a quite better fit (though Asimov would likely be in violent disagreement). In any case I agree that pittoresque analogies do not actually help the discussion. We are currently discussing how to change it, so I see little benefit in arguing over precisely how bad the current policy is. Hear, hear! +10 Agreed. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable 2.16 releases (dictator)
On Sat, Jul 14, 2012 at 11:30 AM, David Kastrup d...@gnu.org wrote: Trevor Daniels t.dani...@treda.co.uk writes: I suggest that you keep any such decision to yourself until just before the next stable is built, or defer making it until then. Otherwise interest in fixed such bugs will wane. And in the interest of making a release, I want to have people prioritize on those bugs that will affect the release. That's the main point of having priorities in the first place. Do you think we shall have a priority field in our tracker again? Don't get me wrong: i don't want to give priorities to all issues! I think that abandoning old priorities was reasonable because they didn't mean anything. It would only make sense to use 2 or 3 levels (critical, high, low(?)) and use them sparingly (no more than a dozen high-priority issues, preferably just a few). Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable 2.16 releases (dictator)
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Jul 14, 2012 at 11:30 AM, David Kastrup d...@gnu.org wrote: Trevor Daniels t.dani...@treda.co.uk writes: I suggest that you keep any such decision to yourself until just before the next stable is built, or defer making it until then. Otherwise interest in fixed such bugs will wane. And in the interest of making a release, I want to have people prioritize on those bugs that will affect the release. That's the main point of having priorities in the first place. Do you think we shall have a priority field in our tracker again? Don't get me wrong: i don't want to give priorities to all issues! I think that abandoning old priorities was reasonable because they didn't mean anything. It would only make sense to use 2 or 3 levels (critical, high, low(?)) and use them sparingly (no more than a dozen high-priority issues, preferably just a few). At the current point of time, Critical seems to be enough. Basically it means that the effects from this bug impact current operations rather than just the users/developers affected by it directly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parenthesizeStencil and bracketifyStencil (issue 6397043)
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: Phil Holmes m...@philholmes.net Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org Sent: Friday, July 13, 2012 11:13 PM Subject: Re: parenthesizeStencil and bracketifyStencil (issue 6397043) 2012/7/13 Phil Holmes m...@philholmes.net: (...) So - if your changes will break the snippet, but will only work in in future versions, copy the snippet to snippets/new and update it there. Copy or cut and paste? What about %% and then run scripts/auxiliar/makelsr.py ? -Harm Copy will be fine. makelsr uses the version in /new to overwrite the tarball version. It's not always _necessary_ to run makelsr, since if you create a patch with a new snippet in /new, the LSR-meister (i.e. me) will at some point run makelsr and therefore update snippets. However, if the changes break the snippet completely, and this breaks make doc, then you should run makelsr and then also include the new version of the snippet in /snippets in the patch. Hope this makes some sense. It's difficult to explain. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds support for cross-staff-stems (issue 6344092)
- Original Message - From: gra...@percival-music.ca To: philehol...@googlemail.com; tdanielsmu...@googlemail.com Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Saturday, July 14, 2012 2:39 AM Subject: Re: Adds support for cross-staff-stems (issue 6344092) http://codereview.appspot.com/6344092/diff/7001/input/regression/cross-staff-stems.ly File input/regression/cross-staff-stems.ly (right): http://codereview.appspot.com/6344092/diff/7001/input/regression/cross-staff-stems.ly#newcode2 input/regression/cross-staff-stems.ly:2: Sorry, I was unclear. I meant to ask for your new snippet to be a regtest in *addition* to a snippet, not as a replacement. We do not expect users to look at regtests, so it's important to discuss this functionality in a snippet or the docs. In addition, the regtest should still have a texidoc header (like other regtests) -- I meant to only ask you to remove the lsrtags and doctitle from the regtest version of the snippet. http://codereview.appspot.com/6344092/ I think I intended it to remain in snippets/new - it looks like my patch hasn't picked it up. I'll also add texidoc to explain the regtest's function. It's my intention to update the cross-staff stems part of the NR once this is in master. New patch will be created over the weekend. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2: 2 - Stable releases and roadmap (radical change)
Hi, Keith, somehow i had overlooked this part of your email: On Wed, Jun 27, 2012 at 7:33 AM, Keith OHara k-ohara5...@oco.net wrote: For any changed test then, it is probably worth reading the header, to see if a subtle change that looks harmless happens to be the point of the test (and would presumably cause other trouble). I was thinking about it, too (see regtests about very small differencies thread on devel). My conclusion is that using bigger staff (or font) size should be a good solution: it makes the changes more visible and immediately focuses reader's attention. See commit e8fc7813b17822c138150807484197ef8d4e7c21. Oh, and there's one more thing about regtests that came to my mind: we should perhaps have some sort of special category for regtests requiring manual attention (example: issue 2656 concerns only Windows). Of course these tests would be ran seldom (only when a new dev release happens perhaps?). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parenthesizeStencil and bracketifyStencil (issue 6397043)
Hi,
this is really cool!
A few general remarks:
- is there a command to turn it off?
- there already is a command \parenthesize. Your function seems to be
smarter (at least in some cases); would it be to combine them? Having
two similar functions is confusing.
- i get a segmentation fault when i tried to parenthesize a NoteColumn.
- it produces bad results when used on stemmed NoteHead's. [1]
- there are unsymmetric results for dynamics:
\relative c' {
\bracketifyStencil DynamicText
c1\p c\mp c\mf c\f
}
\relative c' {
\parenthesizeStencil DynamicText
c1\p c\mp c\mf c\f
}
I'm quite sure they are caused by glyphs bounding boxes which are
inappropriate for this task. Have you seen Mike's work on stencil
skylines (tracker 2148, Rietveld 5626052)? I think that it would be
useful here. See
http://lilypond-stuff.1065243.n5.nabble.com/skyline-integrals-test-results-2148-R-5626052-tp5705594p5705602.html
(skylines demonstration (patchset 40) to see what is it all about.
[1] introducing inner- and outer-extents should help here. I'm working
on introducing them, together with general_alignment method. See this
issue and linked message
http://code.google.com/p/lilypond/issues/detail?id=2613 (it will take
some time to implement this fully, though).
thanks!
Janek
http://codereview.appspot.com/6397043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Texinfo help, please
Le 13/07/2012 10:23, Phil Holmes disait :
- Original Message - From: Graham Percival
Anyway, my current understanding is that there are three realistic
options:
1)
--- linewidth --
fromsome kind of
emergency-stretch-tweak
--- linewidth --
2)
manually insert a @* before every @file{} in the docs which would
produce an overfull hbox, to force a linebreak.
(I reject the option of breaking within a filename)
3)
manually reword any sentence including a @file{} which would
produce an overfull hbox.
Phil's patch currently does #2 and #3. I am not fond of those
options, since it means that we need to take extra care when
writing or editing docs. I would rather see #1.
Thoughts, objections?
- Graham
I've just checked and in total I added 4 @* forced linebreak entries -
all of them in pure lists of filenames. I believe the output in the NR
in all these cases is infinitely better than it was, and considerably
better than right-justified - I've effectively left-justified the lists,
that's all.
As for how hard doing this would make for future authors. 1) It's
unlikely they'll need to do it. I've done it twice in over 800 pages.
2) A simple instruction in the CG to check any change you make, and if
you've got non-breaking text consider a line break would also fix it.
As for the re-word - it wasn't perfect before and it's not perfect now.
Both express(ed) the intent without problem.
My suggestion - unless there are _real_ problems with my patch (and
there aren't) let's start focusing on other shitty bits of
documentation now that I've fixed this shitty element of the NR.
There's no problem with accepting this patch and then, if anyone finds
it a real problem, making changes in the future for example, improving
how filenames are handled and deleting the 4 instances of forced line
breaks.
I just had a look at the French version (random pages), and I agree that
it looks ugly more than sometimes.
Rewording is naturally done with translations, but I will have to reword
many rewordings in order to deliver something more visually fluent...
I think that most of these bad presentations are due to the fact that
proofreading is done with the HTML version. We should then advocate
that the final draft before pushing a patch that touches any part of
the documentation, should be checked with the PDF version of the
concerned manual.
Cheers,
Jean-Charles
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Verification request
Graham, Please see http://code.google.com/p/lilypond/issues/detail?id=2585 -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds support for cross-staff-stems (issue 6344092)
Please review final updates. http://codereview.appspot.com/6344092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds support for cross-staff-stems (issue 6344092)
LGTM.
Scheme-only patches are nice, because we don't have to book Linux to try
them out.
I would not hesitate to put this in before 2.16, because it is adds
capability without changing anything existing.
http://codereview.appspot.com/6344092/diff/12002/Documentation/snippets/new/cross-staff-stems.ly
File Documentation/snippets/new/cross-staff-stems.ly (right):
http://codereview.appspot.com/6344092/diff/12002/Documentation/snippets/new/cross-staff-stems.ly#newcode17
Documentation/snippets/new/cross-staff-stems.ly:17:
The demonstration is rather repetitive, and as a regression test the
odd-looking output made me think something was wrong. I suggest
{
\new PianoStaff
\new Staff {
b d'4 r d'16\ e'8. g8 r\!
}
\new Staff {
\clef bass
\voiceOne
\autoBeamOff
\crossStaff { e g4 e, g16 a8. c8} d
}
}
http://codereview.appspot.com/6344092/diff/12002/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/6344092/diff/12002/ly/music-functions-init.ly#newcode230
ly/music-functions-init.ly:230: (grob-interpret-markup grob
(format-compound-time args)))
You should probably leave the indent in place.
http://codereview.appspot.com/6344092/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
parser.yy: remove `fraction' (issue 6399045)
It is too unfriendly to say unexpected '/' to someone who wrote
{\times 2/ 3 { b2 b b }}. We need at least a conversion rule like
(\d)\s*/\s*(\d) = \1/\2
http://codereview.appspot.com/6399045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug with 2.15.39 fixed with 2.15.42: good job but no reg test
Patch pushed. On Tue, 10 Jul 2012 22:40:49 -0700, Frédéric Bron frederic.b...@m4x.org wrote: patch proposed. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix Issue 2146 Illegal entry in bfrange block in ToUnicode CMap (issue 6399046)
wow, awesome work! http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi File Documentation/common-macros.itexi (right): http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi#newcode16 Documentation/common-macros.itexi:16: % code stolen from Heiko Oberdiek's `ifpdf' package sorry to nitpick, but could you use the word copied instead? there's no benefit to waving a red flag to anybody doing casual greps and looking for trouble. http://codereview.appspot.com/6399046/diff/1/configure.in File configure.in (right): http://codereview.appspot.com/6399046/diff/1/configure.in#newcode66 configure.in:66: _NCSB_SOURCE_FILES_= what's the convention for leading _ in names? I havent' encountered this before. http://codereview.appspot.com/6399046/diff/1/scripts/build/lys-to-tely.py File scripts/build/lys-to-tely.py (right): http://codereview.appspot.com/6399046/diff/1/scripts/build/lys-to-tely.py#newcode69 scripts/build/lys-to-tely.py:69: code stolen from Heiko Oberdiek's `ifpdf' package ditto http://codereview.appspot.com/6399046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Issue 2146 Illegal entry in bfrange block in ToUnicode CMap (issue 6399046)
Reviewers: Graham Percival,
Message:
Hi Graham,
Thanks for the quick review, I'll upload another patch when I get
another review or at the earliest this week-end.
Please also note my comments on the bug tracker w.r.t. distribution of
lilypond.map and documentation.
http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi
File Documentation/common-macros.itexi (right):
http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi#newcode16
Documentation/common-macros.itexi:16: % code stolen from Heiko
Oberdiek's `ifpdf' package
On 2012/07/15 00:21:16, Graham Percival wrote:
sorry to nitpick, but could you use the word copied instead?
there's no
benefit to waving a red flag to anybody doing casual greps and looking
for
trouble.
OK, I had not thought of that.
http://codereview.appspot.com/6399046/diff/1/configure.in
File configure.in (right):
http://codereview.appspot.com/6399046/diff/1/configure.in#newcode66
configure.in:66: _NCSB_SOURCE_FILES_=
On 2012/07/15 00:21:16, Graham Percival wrote:
what's the convention for leading _ in names? I havent' encountered
this
before.
It was just my lack of imagination for a variable that should go through
filtering (namely checking for Cyrillic) before being AC_SUBSTed. If
using an underscore is really not appropriate, then I'll invent some
variable name.
Description:
Fix Issue 2146 Illegal entry in bfrange block in ToUnicode CMap
Please review this at http://codereview.appspot.com/6399046/
Affected files:
M Documentation/common-macros.itexi
M config.make.in
M configure.in
M make/lilypond-vars.make
M make/substitute.make
M scripts/build/lys-to-tely.py
M tex/GNUmakefile
A tex/lilypond.map.in
Index: Documentation/common-macros.itexi
diff --git a/Documentation/common-macros.itexi
b/Documentation/common-macros.itexi
index
baff739e3cfce1bde7ccf04a13d4708ae16d9ce8..b5577b1459bd923e74a4c4ce2a1147f5ef084919
100644
--- a/Documentation/common-macros.itexi
+++ b/Documentation/common-macros.itexi
@@ -10,6 +10,21 @@
@set txicodequoteundirected
@set txicodequotebacktick
+@c Trick to use with proper font mappings the same NCSB fonts as
+@c LilyPond instead of those provided by TeX distribution
+@tex
+% code stolen from Heiko Oberdiek's `ifpdf' package
+% to call \pdfmapfile only in PDF mode
+\begingroup\expandafter\expandafter\expandafter\endgroup
+ \expandafter\ifx\csname pdfoutput\endcsname\relax
+\else
+ \ifnum\pdfoutput1 %
+ \else
+\pdfmapfile{=lilypond.map}
+ \fi
+\fi
+@end tex
+
@c * Displaying text *
Index: config.make.in
diff --git a/config.make.in b/config.make.in
index
3ed8e53b05b5dde9123bec6be15e7debf7ed5511..aa674379e3dcaa8679195c722f377c6b3ce84922
100644
--- a/config.make.in
+++ b/config.make.in
@@ -90,6 +90,7 @@ vimdir = $(lilypond_datadir)/vim
NCSB_SOURCE_FILES = @NCSB_SOURCE_FILES@
+NCSB_DIR = @NCSB_DIR@
## PROGRAMS
Index: configure.in
diff --git a/configure.in b/configure.in
index
0189be15b2aedb767832d777eccd8c6955dde845..972cc25d40d4a644f6b11814da54a702bd9d2d47
100644
--- a/configure.in
+++ b/configure.in
@@ -62,13 +62,14 @@ STEPMAKE_COMPILE
AC_CHECK_PROG(FCLIST, fc-list, fc-list)
AC_MSG_CHECKING([New Century Schoolbook PFB files])
AC_SUBST(NCSB_SOURCE_FILES)
+AC_SUBST(NCSB_DIR)
+_NCSB_SOURCE_FILES_=
if test $NCSB_DIR != ; then
- NCSB_SOURCE_FILES=
for f in c059013l c059016l c059033l c059036l; do
if test ! -f $NCSB_DIR/$f.pfb; then
STEPMAKE_WARN($NCSB_DIR does not contain $f.pfb.)
else
- NCSB_SOURCE_FILES=$NCSB_DIR/$f.pfb $NCSB_SOURCE_FILES
+ _NCSB_SOURCE_FILES_=$NCSB_DIR/$f.pfb $_NCSB_SOURCE_FILES_
fi
done
else
@@ -78,14 +79,23 @@ else
| head -n 1`
NCSB_FILE=`echo $NCSB_FILE | sed 's/^\(.*\):$/\1/g'`
NCSB_FILE=`$PYTHON $srcdir/scripts/auxiliar/readlink.py $NCSB_FILE`
- NCSB_SOURCE_FILES=$NCSB_FILE $NCSB_SOURCE_FILES
+ _NCSB_SOURCE_FILES_=$NCSB_FILE $_NCSB_SOURCE_FILES_
done
+NCSB_DIR=`AS_DIRNAME($NCSB_FILE)`
else
AC_MSG_RESULT(not found)
echo Can't find Century Schoolbook files. Install FontConfig's
fc-list,
echo or use --with-ncsb-dir
fi
fi
+NCSB_SOURCE_FILES=
+for f in $_NCSB_SOURCE_FILES_; do
+ if test `grep Cyrillic $f` = ; then
+STEPMAKE_WARN($f does not have Cyrillic characters.)
+ else
+NCSB_SOURCE_FILES=$f $NCSB_SOURCE_FILES
+ fi
+done
AC_MSG_RESULT($NCSB_SOURCE_FILES)
AC_LANG([C++])
Index: make/lilypond-vars.make
diff --git a/make/lilypond-vars.make b/make/lilypond-vars.make
index
57cddb16ee37c75cd6cf850deed8cf1430e3d4cb..322dd9090cd6f09c3f81ec9253d3e1652d289be1
100644
--- a/make/lilypond-vars.make
+++ b/make/lilypond-vars.make
@@ -75,6 +75,8 @@ endif
TEXINPUTS=$(top-src-dir)/tex/::
export TEXINPUTS
+TEXFONTMAPS=$(top-build-dir)/tex/$(outdir)::
+export TEXFONTMAPS
export LYDOC_LOCALEDIR:=
Re: Fix Issue 2146 Illegal entry in bfrange block in ToUnicode CMap (issue 6399046)
On Sun, Jul 15, 2012 at 12:37:15AM +, john.mander...@gmail.com wrote: configure.in:66: _NCSB_SOURCE_FILES_= On 2012/07/15 00:21:16, Graham Percival wrote: what's the convention for leading _ in names? I havent' encountered this before. It was just my lack of imagination for a variable that should go through filtering (namely checking for Cyrillic) before being AC_SUBSTed. If using an underscore is really not appropriate, then I'll invent some variable name. I wouldn't say that it was really not appropriate, but it looked to me like a special GNUMakefile or stepmake convention. Maybe call it NCSB_SOURCE_FILES_UNFILTERED or something like that? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Check in Texinfo 2012-07-03.16 (issue 6374068)
I can't see any diff on rietveld, but presumably there's so much being changed that a diff wouldn't be helpful anyway. If a make doc looks good to you, and you're willing to handle any potential fall-out from breakage at this point in the release cycle, then as far as I'm concerned you can push directly to staging. OTOH, if you'd rather wait until 2.17, that's cool too. http://codereview.appspot.com/6374068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds support for cross-staff-stems (issue 6344092)
LGTM http://codereview.appspot.com/6344092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Texinfo help, please
On Sat, Jul 14, 2012 at 02:49:21PM +0100, Trevor Daniels wrote: Jean-Charles Malahieude wrote Saturday, July 14, 2012 1:29 PM I think that most of these bad presentations are due to the fact that proofreading is done with the HTML version. We should then advocate that the final draft before pushing a patch that touches any part of the documentation, should be checked with the PDF version of the concerned manual. I would hope not, as that would preclude my doing any more documentation work. Agreed. Checking multiple output formats is *way* too much work. If somebody really cares about the presentation, they're welcome to start reviewing docs and making changes as necessary. (but make sure send stuff for review after one hour of work, so that we can settle any general questions arising before you make a lot of changes in a direction that we don't approve of) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Texinfo help, please
On Fri, Jul 13, 2012 at 09:23:00AM +0100, Phil Holmes wrote: My suggestion - unless there are _real_ problems with my patch (and there aren't) let's start focussing on other shitty bits of documentation now that I've fixed this shitty element of the NR. ... ok. By my working rule (he who does the work, makes the rules), I can't object. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser.yy: remove `fraction' (issue 6399045)
Reviewers: Keith,
Message:
On 2012/07/14 21:29:42, Keith wrote:
It is too unfriendly to say unexpected '/' to someone who wrote
{\times 2/ 3 {
b2 b b }}. We need at least a conversion rule like (\d)\s*/\s*(\d)
= \1/\2
In the existing code base, that would reach the following:
input/regression/figured-bass-continuation-modifiers.ly:6 4 38
6\\ 4! 3! 6 4- 3+ 6/ 4\+ 3 6 4\! 3+ 6\+ 4\+ 3++
input/regression/figured-bass-slashed-numbers.ly: 0/ 1/ 2/ 3/ 4/ 5/
6/ 7/ 8/ 9/ 10/ 11/ 12/ 13/ 100/
input/regression/figured-bass.ly:3\+ [5/] 7/ [9 11]
input/regression/figured-bass.ly:3 6/
Do we have evidence of people using 2/ 3 anywhere? It is not like it
was ever documented to work.
Description:
parser.yy: remove `fraction'
Previously the parser recognized fractions as well as the lexer. The
effect
was that in certain contexts it was possible to use spaces around the
slash.
This necessitated lookahead in parsing and is not apparently used
anywhere.
It also does not help in making the input look consistent.
Please review this at http://codereview.appspot.com/6399045/
Affected files:
M lily/parser.yy
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index
44284f6178fdc407edf4edf3a0507418f9594826..98ee4ef7028ca97aae685601af97b5d5ccd27eb6
100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -475,7 +475,6 @@ If we give names, Bison complains.
%type scm event_function_event
%type scm figure_list
%type scm figure_spec
-%type scm fraction
%type scm full_markup
%type scm full_markup_list
%type scm function_arglist
@@ -1550,11 +1549,6 @@ function_arglist_backup:
$$ = check_scheme_arg (parser, @3,
$3, $1, $2);
}
- | function_arglist_backup REPARSE fraction
- {
- $$ = check_scheme_arg (parser, @3,
- $3, $1, $2);
- }
;
function_arglist:
@@ -1574,7 +1568,7 @@ function_arglist_common:
$$ = check_scheme_arg (parser, @3,
$3, $2, $1);
}
- | EXPECT_SCM function_arglist_closed_optional fraction
+ | EXPECT_SCM function_arglist_closed_optional FRACTION
{
$$ = check_scheme_arg (parser, @3,
$3, $2, $1);
@@ -1713,7 +1707,7 @@ function_arglist_closed_common:
$$ = check_scheme_arg (parser, @3,
$3, $2, $1);
}
- | EXPECT_SCM function_arglist_closed_optional fraction
+ | EXPECT_SCM function_arglist_closed_optional FRACTION
{
$$ = check_scheme_arg (parser, @3,
$3, $2, $1);
@@ -2636,13 +2630,6 @@ multiplied_duration:
}
;
-fraction:
- FRACTION { $$ = $1; }
- | UNSIGNED '/' UNSIGNED {
- $$ = scm_cons ($1, $3);
- }
- ;
-
dots:
/* empty */ {
$$ = 0;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Check in Texinfo 2012-07-03.16 (issue 6374068)
Reviewers: Graham Percival, Message: On 2012/07/15 01:45:06, Graham Percival wrote: I can't see any diff on rietveld, but presumably there's so much being changed that a diff wouldn't be helpful anyway. If a make doc looks good to you, and you're willing to handle any potential fall-out from breakage at this point in the release cycle, then as far as I'm concerned you can push directly to staging. OTOH, if you'd rather wait until 2.17, that's cool too. Downloading the raw patch works, and so does looking at the dev/texinfo branch in git I uploaded the changes two times without success: I have no idea what makes Rietveld go wrong here. The indexes look ok to me. Werner claimed that this Texinfo version would make it possible to improve formatting. If 2.16 comes with a better printed manual, that's not wrong. I have not seen positive evidence to this effect, or more specific information about what would be needed to make use of the additional possibilities, and who would do the work. Description: Check in Texinfo 2012-07-03.16 Fix for indexing macros. Please review this at http://codereview.appspot.com/6374068/ Affected files: M tex/texinfo.tex ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Issue 2146 Illegal entry in bfrange block in ToUnicode CMap (issue 6399046)
http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi File Documentation/common-macros.itexi (right): http://codereview.appspot.com/6399046/diff/1/Documentation/common-macros.itexi#newcode16 Documentation/common-macros.itexi:16: % code stolen from Heiko Oberdiek's `ifpdf' package On 2012/07/15 00:37:15, John Mandereau wrote: On 2012/07/15 00:21:16, Graham Percival wrote: sorry to nitpick, but could you use the word copied instead? there's no benefit to waving a red flag to anybody doing casual greps and looking for trouble. OK, I had not thought of that. Unless I am mistaken, ifpdf would have been released under the LPPL, and we release under the incompatible GPL. Just write \ifpdf \pdfmapfile... \fi since Texinfo defined \ifpdf for us. http://codereview.appspot.com/6399046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Issue 2146 Illegal entry in bfrange block in ToUnicode CMap (issue 6399046)
http://codereview.appspot.com/6399046/diff/1/configure.in File configure.in (right): http://codereview.appspot.com/6399046/diff/1/configure.in#newcode66 configure.in:66: _NCSB_SOURCE_FILES_= On 2012/07/15 00:37:15, John Mandereau wrote: On 2012/07/15 00:21:16, Graham Percival wrote: what's the convention for leading _ in names? I havent' encountered this before. It was just my lack of imagination for a variable that should go through filtering (namely checking for Cyrillic) before being AC_SUBSTed. If using an underscore is really not appropriate, then I'll invent some variable name. Why does the underscore help here? The answer should likely be a code comment as well. http://codereview.appspot.com/6399046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser.yy: remove `fraction' (issue 6399045)
On Sat, 14 Jul 2012 19:14:41 -0700, d...@gnu.org wrote: Do we have evidence of people using 2/ 3 anywhere? I don't know of any scores with spaces alongside the / . ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
