Re: Can't get a patch through because of weekly development releases.
Graham Percival gra...@percival-music.ca writes: On Tue, Jul 13, 2010 at 05:30:38PM -0600, Carl Sorensen wrote: Because it changes the syntax, I need to change documentation text, documentation examples in english, french, spanish, and german (plus potentially in hungarian and japanese), documentation snippets, regression tests, web examples, and convert-ly. Every one of these files needs a version. (And I haven't yet mentioned changes.tely). Hmm, I hadn't thought of that. How the mao am I supposed to get a patch reviewed? I prepared the patch for 2.13.27, then updated it for 2.13.28, and now we're at 2.13.29. The review cycle is *longer* than the release cycle! I suppose there's some way to use xargs to fund the files changed in the patch and automatically (using sed) change every occurrence of 2.13.28 to 2.13.29, but I don't have the bash script-fu to do this. If you have the patch as a single file, then (in vim) it would be %s/2.13.28/2.13.29/g But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add \path markup command, and use it for \eyeglasses. (issue1730044)
Op dinsdag 13-07-2010 om 21:49 uur [tijdzone +], schreef pnor...@gmail.com: Jan: I like your idea about using a separate module to evaluate the various commands, though IIUC, this would be duplicating the work done by the backend path procedures in output-ps.scm and output-svg.scm, since they already take a list of commands and convert them to either PostScript or SVG paths. Yes, I did not realise that / imagine we had such routines already. Would [have] be[en] nice to fold this functionality together. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyOfSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On 2010-05-25 14:33, Kieren MacMillan wrote: Hi all, I want to have independent control of the thickness and offset of the underline markup function -- unfortunately, they are currently linked (i.e., the offset is a multiple of the thickness). [...] [This mail is essentially copied from http://code.google.com/p/lilypond/issues/detail?id=1104 to have it on -devel...] @ Graham: W.r.t. http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00015.html, what's a non-developer supposed to do with his review? Post on -devel? Comment in the issue description? Both? Neither? Hi, Kieren, LGTM, but I'm not allowed to push, too. I'm just trying to follow Graham's beg for reviewers... A minor correction: (* -1 offset) can be simplified to (- offset) in the (let*) clause for y. (let* ((thick (* (ly:output-def-lookup layout 'line-thickness) [...] (y (* -1 offset)) [...] I like your default value for offset, since in normalsize text, the underline does not cross the descenders of the font. But I wonder whether both offset (linearly) and thickness (= linearly) should be scaled with font-size, for a consistent look e.g. in the ((sub-)sub-)title fields? Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On Wed, Jul 14, 2010 at 10:34:01AM +0200, Alexander Kobel wrote: [This mail is essentially copied from http://code.google.com/p/lilypond/issues/detail?id=1104 to have it on -devel...] @ Graham: W.r.t. http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00015.html, what's a non-developer supposed to do with his review? Post on -devel? Comment in the issue description? Both? Neither? A post to -devel is fine. If you have a lot of comments, it might be nice to post on the codereview google website... but merely sending an email to -devel is still incredibly helpful. Thanks for looking at this patch! (I have mixed feelings about whether or not it's useful to add a comment to the issue in the tracker. Let me do some investigations and I'll get back to you.) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
On Wed, Jul 14, 2010 at 08:47:17AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: If you have the patch as a single file, then (in vim) it would be %s/2.13.28/2.13.29/g But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. The problem is the convert-ly rule for the changed syntax -- if he wrote the rule for 2.13.25 but doesn't merge until 2.13.29, then convert-ly will have an incorrect version. This also applies to the version number in input/regression/ files. I'm not entirely certain why he's changing the version number in Documentation/ files, since those should be updated by running convert-ly on them (followed by any manual changes that are necessary)... but here we're in uncharted and definitely disorganized territory. I will write up the problem and put it in the tracker; I don't think that I'll have time make a proposal for over a week. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On 2010-07-14 10:42, Graham Percival wrote: On Wed, Jul 14, 2010 at 10:34:01AM +0200, Alexander Kobel wrote: @ Graham: W.r.t. http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00015.html, what's a non-developer supposed to do with his review? Post on -devel? Comment in the issue description? Both? Neither? A post to -devel is fine. If you have a lot of comments, it might be nice to post on the codereview google website... but merely sending an email to -devel is still incredibly helpful. Once I recognized that it's not very hard to get the build setup running (on a Linux box, I mean), I immediately appreciated the benefits of Rietveld. If the patch is there, it's of course the best option to comment there. Kieren still lacks a git setup, though, and this very patch has only been mentioned on the -devel list and the bug tracker, so I guess it's a special case. I can prepare a proper git patch and post it on Rietveld, but I'd rather do so once I have some comments about the font-size relation of this functionality. Regarding your new entry in the tracker about how to comment: Rietveld looks like the best option for reviews, but I dislike to force everybody to use it. I'm not sure how many developers really can't prepare git diffs or submit to Rietveld, but I vaguely remember and respect David's concerns to open yet another account, especially with a possible data leech, and it requires an up-and-running git. Since it requires write access to finally push the patch anyway, I propose discussions on -devel, and a link to the thread in the bug tracker for reference. Once the patch LGTEveryone, preparing the git diff-style patch should not take long. And it can be done by anybody, like me, with no need for real (LilyPond) programming experience. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
Am Mittwoch, 14. Juli 2010, um 08:47:17 schrieb David Kastrup: Graham Percival gra...@percival-music.ca writes: But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. The problem is that many regtest files and mainly documentation files contain \version 2.13.x These lines will all be out of date if a release happened while the patch was under review. And in particular for new features, which require a particular version (i.e. a new feature, or a changed syntax that needs a convert-ly rule), it is essential that the version number is really the first version where that syntax exists in the used form... 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 http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On 2010-07-14 12:15, Graham Percival wrote: On Wed, Jul 14, 2010 at 12:08:39PM +0200, Alexander Kobel wrote: Regarding your new entry in the tracker about how to comment: Rietveld looks like the best option for reviews, but I dislike to force everybody to use it. I'm not sure how many developers really can't prepare git diffs or submit to Rietveld, Everybody developer can do this. Lilybuntu makes it easy to have git and compile stuff. You're aware that Kieren reads this, too? :-) Or does this run in the virtual box under MacOS now? but I vaguely remember and respect David's concerns to open yet another account, especially with a possible data leech, and it requires an up-and-running git. I'm not happy about requiring a gmail account, but since that's necessary for the issue tracker as well, I think we just need to bite the bullet and accept it. :( Uh, correct. I completely forgot this. I never use my gmail account anyway, and the login's stored... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Mittwoch, 14. Juli 2010, um 08:47:17 schrieb David Kastrup: Graham Percival gra...@percival-music.ca writes: But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. The problem is that many regtest files and mainly documentation files contain \version 2.13.x These lines will all be out of date if a release happened while the patch was under review. Why? They will be out of date in the branch, not the release master. And once one merges with the release master, they'll be updated to the current release number as part of the merge. Am I overlooking something? And in particular for new features, which require a particular version (i.e. a new feature, or a changed syntax that needs a convert-ly rule), it is essential that the version number is really the first version where that syntax exists in the used form... If you want to work with convert-ly rules and test them in your feature branch, maybe you can use version 2.13.myfeature or similar as the release number. You'll get merge conflicts the first time around, but perhaps man git-rerere will provide a good hint how to keep the manual work required to keep updating to a minimum. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On Wed, Jul 14, 2010 at 12:21:56PM +0200, Alexander Kobel wrote: On 2010-07-14 12:15, Graham Percival wrote: On Wed, Jul 14, 2010 at 12:08:39PM +0200, Alexander Kobel wrote: Regarding your new entry in the tracker about how to comment: Rietveld looks like the best option for reviews, but I dislike to force everybody to use it. I'm not sure how many developers really can't prepare git diffs or submit to Rietveld, Everybody developer can do this. Lilybuntu makes it easy to have git and compile stuff. You're aware that Kieren reads this, too? :-) Yes. Or does this run in the virtual box under MacOS now? Lilybuntu is a virtual machine. It can be run in vmware or virtualbox on top of linux, windows, or macos. We've had two new documentation writers using lilybuntu exclusively for the past 6 months, on a mixture of windows and osx machines. It works. It's not hard. However, the instructions are not as clear as they could be. Kieren knows this. When he asked about lilypond programming a few months ago, I told him to wait until I'd worked on the lilybuntu docs. I've taken a quick glance at them, and have identified a few problems. I have not fixed those problems yet, because all the other emergencies in lilypond, including (but not exclusively) the bug squad. Any other questions? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On Wed, Jul 14, 2010 at 12:08:39PM +0200, Alexander Kobel wrote: Kieren still lacks a git setup, though, and this very patch has only been mentioned on the -devel list and the bug tracker, so I guess it's a special case. ah, ok. I missed that. I can prepare a proper git patch and post it on Rietveld, but I'd rather do so once I have some comments about the font-size relation of this functionality. ok, that would be great. Regarding your new entry in the tracker about how to comment: Rietveld looks like the best option for reviews, but I dislike to force everybody to use it. I'm not sure how many developers really can't prepare git diffs or submit to Rietveld, Everybody developer can do this. Lilybuntu makes it easy to have git and compile stuff. I need to clarify the installation instructions and verify this for myself, but once that's done, we will expect all contributors to send properly-formatted git patches, work with rietveld, etc. but I vaguely remember and respect David's concerns to open yet another account, especially with a possible data leech, and it requires an up-and-running git. I'm not happy about requiring a gmail account, but since that's necessary for the issue tracker as well, I think we just need to bite the bullet and accept it. :( Since it requires write access to finally push the patch anyway, I propose discussions on -devel, and a link to the thread in the bug tracker for reference. That's fine for this special case, and since the lilybuntu instructions aren't crystal-clear yet. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com wrote: Hi Joe, On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote: Does the attached patch help? For me, it reduces dramatically the number of times that combine_pure_heights (and also ly_scm2interval) is called, but it has very little effect on lilypond's overall running time (for the optimized build, at least). I've just tested this patch (after removing the bits which prevented it from applying; they look like they belong to a fix for issue 1152. :) It has a dramatic effect in several cases: on one 26 page score it's halved the compilation time to just over a minute. Ok, it seems like I should be benchmarking with bigger files; I was just trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on rietveld. Cheers, Joe Hi, with Joe's patch i got with my actual project's big score close to 25% reduction on lilypond run time, which is very nice! After git pull origin (onto Joe's patch) i got: Zeilenumbrüche werden berechnet...terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted Can somebody help me? Thanks, Arno ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On 2010-07-14 12:34, Graham Percival wrote: On Wed, Jul 14, 2010 at 12:21:56PM +0200, Alexander Kobel wrote: Or does this run in the virtual box under MacOS now? Lilybuntu is a virtual machine. It can be run in vmware or virtualbox on top of linux, windows, or macos. We've had two new documentation writers using lilybuntu exclusively for the past 6 months, on a mixture of windows and osx machines. Oh, that's good news. I missed that; I didn't want to be sarcastic, but rather really didn't know about it. Any other questions? Nope, thanks. :-) Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
On 7/14/10 4:21 AM, David Kastrup d...@gnu.org wrote: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Mittwoch, 14. Juli 2010, um 08:47:17 schrieb David Kastrup: Graham Percival gra...@percival-music.ca writes: But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. The problem is that many regtest files and mainly documentation files contain \version 2.13.x These lines will all be out of date if a release happened while the patch was under review. Why? They will be out of date in the branch, not the release master. And once one merges with the release master, they'll be updated to the current release number as part of the merge. Am I overlooking something? Yes. The versions that need to be put in the files need to be the version at which the new syntax is introduced, not the current version. It's not a merge conflict issue. It's an issue of tracking the version at which a new syntax is introduced. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch for underline function
On 7/14/10 4:15 AM, Graham Percival gra...@percival-music.ca wrote: On Wed, Jul 14, 2010 at 12:08:39PM +0200, Alexander Kobel wrote: Kieren still lacks a git setup, though, and this very patch has only been mentioned on the -devel list and the bug tracker, so I guess it's a special case. ah, ok. I missed that. I can prepare a proper git patch and post it on Rietveld, but I'd rather do so once I have some comments about the font-size relation of this functionality. ok, that would be great. There's already a patch on Rietveld. http://codereview.appspot.com/1347041/show We're just waiting for Kieren to revise the patch in response to the comments on the issue. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
On 7/14/10 2:46 AM, Graham Percival gra...@percival-music.ca wrote: On Wed, Jul 14, 2010 at 08:47:17AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: If you have the patch as a single file, then (in vim) it would be %s/2.13.28/2.13.29/g But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. The problem is the convert-ly rule for the changed syntax -- if he wrote the rule for 2.13.25 but doesn't merge until 2.13.29, then convert-ly will have an incorrect version. This also applies to the version number in input/regression/ files. I'm not entirely certain why he's changing the version number in Documentation/ files, since those should be updated by running convert-ly on them (followed by any manual changes that are necessary)... but here we're in uncharted and definitely disorganized territory. Because the convert-ly rules are manual rules, so doing convert-ly doesn't do any good. And I'm trying to keep the changes to only the necessary files for patch review. For example, I don't run makelsr.py, then upload the patch (because *all* of the snippets will be changed, not just the ones I changed for the patch). So I already have to get the code all patched, do a git commit, do makelsr.py, make make doc, make check. Then I do git reset --hard HEAD, git-cl upload master, and wait for a review. So for this type of patch, the overhead is quite substantial. I'm thinking of writing a script that will do the version update automatically, but I haven't done it yet... Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
'translation' of 'bound' and 'column' with regard to hairpins (for non-developers)
Hello,
I am currently trying to close out Issue 989. And one of the reg tests says
--
Hairpins extend to the extremes of the bound if there is no adjacent hairpin or
dynamic-text. If there is, the hairpin extends to the center of the column or
the bound of the text respectively
--
Can someone tell me what a/the 'bound' is? Also what is a 'column' in this case
the width of the note head (including the stem)?
the reg test is very simple
\relative c'' {
c4 \ c4 \!
c4 \ c \!\ c\!
c4 \ c c \! \fff\ c c\!
}
But I'd like to give a nicer explanation for non-developy-people.
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote:
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also ly_scm2interval)
is called, but it has very little effect on lilypond's overall
running
time (for the optimized build, at least).
I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue 1152.
:) It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.
Ok, it seems like I should be benchmarking with bigger files; I was just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.
Cheers,
Joe
Hi, with Joe's patch i got with my actual project's big score close to
25% reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:
Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Can somebody help me?
Thanks, Arno
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000, 4 GB memory, 2 GB swap space...
but was i actually had wanted to try was the question whether the layout
goes quicker with manual page breaks (since i thought that would lead to
lily only be looking for layout issues within two manual pagebreaks ...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and
hardly a difference whether the \pageBreak is commented out or not...
Yours, Arno
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
On Wed, Jul 14, 2010 at 7:09 AM, Carl Sorensen c_soren...@byu.edu wrote: On 7/14/10 4:21 AM, David Kastrup d...@gnu.org wrote: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Mittwoch, 14. Juli 2010, um 08:47:17 schrieb David Kastrup: Graham Percival gra...@percival-music.ca writes: But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. The problem is that many regtest files and mainly documentation files contain \version 2.13.x These lines will all be out of date if a release happened while the patch was under review. Why? They will be out of date in the branch, not the release master. And once one merges with the release master, they'll be updated to the current release number as part of the merge. Am I overlooking something? Yes. The versions that need to be put in the files need to be the version at which the new syntax is introduced, not the current version. It's not a merge conflict issue. It's an issue of tracking the version at which a new syntax is introduced. Is it really crucial to track this manually? The git history will already tell us when a regression test was added. Plus, we lose this manual history whenever convert-ly is run (even for changes that are orthogonal to what the regression test is checking) and it makes make check slightly less convenient if you have regression tests whose version number is higher than the last release version. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
On 7/14/10 11:12 AM, Joe Neeman joenee...@gmail.com wrote: On Wed, Jul 14, 2010 at 7:09 AM, Carl Sorensen c_soren...@byu.edu wrote: On 7/14/10 4:21 AM, David Kastrup d...@gnu.org wrote: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Mittwoch, 14. Juli 2010, um 08:47:17 schrieb David Kastrup: Graham Percival gra...@percival-music.ca writes: But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. I don't see a problem here. Just merge origin/master into your work branch occasionally, then the patch will be relative to the current version. The problem is that many regtest files and mainly documentation files contain \version 2.13.x These lines will all be out of date if a release happened while the patch was under review. Why? They will be out of date in the branch, not the release master. And once one merges with the release master, they'll be updated to the current release number as part of the merge. Am I overlooking something? Yes. The versions that need to be put in the files need to be the version at which the new syntax is introduced, not the current version. It's not a merge conflict issue. It's an issue of tracking the version at which a new syntax is introduced. Is it really crucial to track this manually? The git history will already tell us when a regression test was added. Plus, we lose this manual history whenever convert-ly is run (even for changes that are orthogonal to what the regression test is checking) and it makes make check slightly less convenient if you have regression tests whose version number is higher than the last release version. The version number of a build from the current git will be higher than the last release version. This particular patch uses changes in .cc code, so it needs to be rebuilt, and hence will always be a version ahead of the current git. If you want to do make check on a binary that's older than current git, you can always do so by checking out input/regression from the released branch. I think it is crucial to track these versions manually for at least convertrules.py and Documentation/snippets/new/*.ly. When makelsr.py is run, it adds a comment that indicates the first version for which the snippet worked, which is the version in D/s/n/. Also, as far as regression tests are concerned, if we don't have the right version in the regtest, then the regtest will be broken. That is, if the regtest uses syntax that is introduced in 2.13.29, but I used 2.13.27 because that was the current devel release when I started the patch, it won't run on 2.13.27, so the file is wrong. If we're going to have versions in the regtests, we better make sure the regtest runs on the version that's in the file, IMO. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
Carl Sorensen c_soren...@byu.edu writes: The version number of a build from the current git will be higher than the last release version. This particular patch uses changes in .cc code, so it needs to be rebuilt, and hence will always be a version ahead of the current git. That sounds like the version number for a feature branch should be something like 2.14.13.feature where x.feature x. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote:
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also ly_scm2interval)
is called, but it has very little effect on lilypond's overall running
time (for the optimized build, at least).
I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue 1152.
:) It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.
Ok, it seems like I should be benchmarking with bigger files; I was just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.
Cheers,
Joe
Hi, with Joe's patch i got with my actual project's big score close to 25%
reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:
Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Can somebody help me?
Thanks, Arno
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.
but was i actually had wanted to try was the question whether the layout
goes quicker with manual page breaks (since i thought that would lead to
lily only be looking for layout issues within two manual pagebreaks ...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and hardly
a difference whether the \pageBreak is commented out or not...
As per the discussion on bug 884, \pageBreak no longer speeds up the
page-breaking computation.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman joenee...@gmail.com wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk hamama...@gmx.de
wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote:
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also
ly_scm2interval)
is called, but it has very little effect on lilypond's overall
running
time (for the optimized build, at least).
I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue 1152.
:) It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.
Ok, it seems like I should be benchmarking with bigger files; I was
just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.
Cheers,
Joe
Hi, with Joe's patch i got with my actual project's big score close to
25%
reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:
Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Can somebody help me?
Thanks, Arno
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.
but was i actually had wanted to try was the question whether the layout
goes quicker with manual page breaks (since i thought that would lead to
lily only be looking for layout issues within two manual pagebreaks
...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and
hardly
a difference whether the \pageBreak is commented out or not...
As per the discussion on bug 884, \pageBreak no longer speeds up the
page-breaking computation.
Cheers,
Joe
Wow! First impression is huge running time reduction. Rough guess 80% for
my large score. So 400% performance gain...
But in the end it dies again with that memory error, but i wll check for
that.
In my little example it dies differently, obviously an endless loop in
grob-smob.cc:50 according to an endless backtrace in gdb.
Hope that helps?
Yours, Arno
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Let's speed up lilypond! was: scheme night-mare...
resent since topic was off-topic...
On Thu, 15 Jul 2010 00:34:40 +0200, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk hamama...@gmx.de
wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote:
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also
ly_scm2interval)
is called, but it has very little effect on lilypond's overall
running
time (for the optimized build, at least).
I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue
1152.
:) It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.
Ok, it seems like I should be benchmarking with bigger files; I was
just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.
Cheers,
Joe
Hi, with Joe's patch i got with my actual project's big score close
to 25%
reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:
Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Can somebody help me?
Thanks, Arno
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.
but was i actually had wanted to try was the question whether the
layout
goes quicker with manual page breaks (since i thought that would lead
to
lily only be looking for layout issues within two manual pagebreaks
...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and
hardly
a difference whether the \pageBreak is commented out or not...
As per the discussion on bug 884, \pageBreak no longer speeds up the
page-breaking computation.
Cheers,
Joe
Wow! First impression is huge running time reduction. Rough guess 80%
for my large score. So 400% performance gain...
But in the end it dies again with that memory error, but i wll check for
that.
In my little example it dies differently, obviously an endless loop in
grob-smob.cc:50 according to an endless backtrace in gdb.
Hope that helps?
Yours, Arno
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, Jul 14, 2010 at 3:34 PM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.
Wow! First impression is huge running time reduction. Rough guess 80% for
my large score. So 400% performance gain...
But in the end it dies again with that memory error, but i wll check for
that.
Is this with git master or with my patch for extra caching?
In my little example it dies differently, obviously an endless loop in
grob-smob.cc:50 according to an endless backtrace in gdb.
This is also a memory problem, since grob-smob.cc:50 is run as part of
guile's garbage collections.
I have uploaded my patch for comments here:
http://codereview.appspot.com/1817045
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
How do I add new noteheads to lilypond?
Hello- I've been working on and off over the last couple years at getting Lilypond to typeset twinline notation (among others) for the music notation project. Kevin Dalley's abandoned patches thankfully did most of the heavy lifting, but the noteheads he used were never posted. I believe I now know enough Metafont to have a fighting chance of add the noteheads we need. What steps do I need to take to add and enable new noteheads in lilypond? 1. Edit feta-bolletjes.mf (now something like feta-noteheads.mf) 2. Manually trigger the fonts to be rebuilt (how?) 3. Install the fonts (where?) 4. Anything else? My branch is based on 2.11.45 with Kevin Dalley's patches. It's up on github: The lily file that defines a handful of chromatic notations: http://github.com/drewm1980/lilypond-an/blob/mark_hanlon/input/musicnotation/chromatic.ly The most interesting line being: (cons twinline (vector '(2 4) '(0) 0 1 6 twinline-layout #(default do default downdo default do default downdo default do default downdo))) ... it is the downdo noteheads that are missing. The metafont file that defines noteheads: http://github.com/drewm1980/lilypond-an/blob/mark_hanlon/mf/feta-bolletjes.mf A sample code snippet that would hopefully display a scale in twinline notation: http://github.com/drewm1980/lilypond-an/blob/mark_hanlon/input/musicnotation/fontcheck/fontcheck.ly To get started I tried duplicating and renaming one of the existing noteheads to downdo, but it wasn't visible after a rebuild after liliypond. Thanks! Drew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Optimizations for pure-height approximations. (issue1817045)
http://codereview.appspot.com/1817045/diff/1/4 File scm/define-grob-properties.scm (right): http://codereview.appspot.com/1817045/diff/1/4#newcode1059 scm/define-grob-properties.scm:1059: Since the properties in this file are sorted alphabetically, this is the wrong place... http://codereview.appspot.com/1817045/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
