Re: a beaming regression?
Phil Holmes philholmes.net> writes: > > i think the output of beam-shortened-lengths.ly doesn't look good > What exactly is the problem? The self-description says the up-pointing stems should be shortened, but they are not. We didn't see it in real music because the bug depends on the \override Beam #'skip-quanting = ##t I entered http://code.google.com/p/lilypond/issues/detail?id=2257 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to Snday
There are no issues for review today, other than David's #2247, which has already been pushed, but he is leaving it up for a few days, just in case. 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: make doc problem
On 2012-01-27 00:00, Julien Rioux wrote: On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? Please check the -devel mailing list (e.g. thread "Memleaks or not" last August/September), where I already observed this. I fully agree that after one file is processed, lilypond should reset to its initial state and not need more memory than before. I have no idea why the memory is going up like it does. To me it doesn't look like a classical memleak, but rather somthing with the Guile garbage collection... 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: make doc problem
On 26/01/2012 6:14 PM, Graham Percival wrote: On Thu, Jan 26, 2012 at 05:57:43PM -0500, Julien Rioux wrote: On 22/01/2012 2:58 PM, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. Could we redistribute the regression test input files into subfolders of say ~50 files each, possibly sorting them into categories if it makes sense? Wanted to do that for ages, but that's not something to get into now. But this shouldn't be an issue -- don't we split it into lists of IIRC 300 files? We had some kind of emergency bugfix like that. ... yeah, see make/lysdoc-rules.make You may want to look into that; perhaps changing the division from 300 to 50 would speed up the build? - Graham The `echo' command-line is broken down into 300-file chunks. They all still end up into one collated-files.tely Anyway, it kind of sounds like a workaround or an emergency action as you say. Were the memory released at each snippet then it shouldn't be an issue. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On Thu, Jan 26, 2012 at 05:57:43PM -0500, Julien Rioux wrote: > On 22/01/2012 2:58 PM, Julien Rioux wrote: > >Thanks, you're quite right CPU is not the limiting factor for the build. > >Disk access and usage of swap when compiling > >input/regression/collated-files slows down the build to a crawl for me. > > Could we redistribute the regression test input files into > subfolders of say ~50 files each, possibly sorting them into > categories if it makes sense? Wanted to do that for ages, but that's not something to get into now. But this shouldn't be an issue -- don't we split it into lists of IIRC 300 files? We had some kind of emergency bugfix like that. ... yeah, see make/lysdoc-rules.make You may want to look into that; perhaps changing the division from 300 to 50 would speed up the build? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote: On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold Is it a bug? We're talking about lilypond running with the -dread-input-files flag here. Once a snippet has been processed and lilypond moves on to the next one, there is no reason to hold onto the memory used by the previous snippet, right? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:58 PM, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. Could we redistribute the regression test input files into subfolders of say ~50 files each, possibly sorting them into categories if it makes sense? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a beaming regression?
"Janek Warchol" wrote in message news:CANYDDppbpzXAeepYCZ24rpu+RVQm21gO9beMCw357jxj_w=g...@mail.gmail.com... Hi, i think the output of beam-shortened-lengths.ly doesn't look good, see in current regtests http://www.lilypond.org/doc/v2.15/input/regression/collated-files.html . Am i missing something? cheers, Janek AFAICS looks the same in 2.12, so not a regression. Which version is better? What exactly is the problem? -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
a beaming regression?
Hi, i think the output of beam-shortened-lengths.ly doesn't look good, see in current regtests http://www.lilypond.org/doc/v2.15/input/regression/collated-files.html . Am i missing something? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plans for changing chord repeat implementations
Nicolas Sceaux writes: > Le 26 janv. 2012 à 11:00, David Kastrup a écrit : > >> The bad news is that absolute pitch friends would have to call the \q >> function (any better name for it?) explicitly. Since q is an input >> convenience, and relative pitch is also an input convenience, I don't >> think that there would be much of an affected user base. > > What would be the impact of your solution on this kind of code? > Is it just about adding e.g. \q before the block? Yes, that would be all. Otherwise you would get an error message telling you to do so once q hits the iterators (the sole purpose of its iterator would be to create that error; \q/\relative would replace all traces of q with the final chord so that one would no longer see the history). I am not particularly happy about that, but a) \relative needs its own sequencing, so if we sequence in the parser, we have two competing ways of creating sequences. b) sequencing in the parser needs to either do a lot of copying just-in-case, or face breakage when music functions and iterators and other stuff modify music (which they are permitted to do). c) sequencing automatically "at the last possible moment" (when iterating) differs even more with sequencing in \relative mode, and has its own set of surprises. As you can see mentioned in the hand-waving comments already (and the bug I want to fix is just the tip of the iceberg), this is all rather shaky. Making the sequencing explicit (and relative as a user-made sequencing point seems like one reasonable spot where doing this automatically seems to make good sense to me, while I don't see a similarly obvious place when \relative is _not_ being used) makes the feature and its implications and side-effects straightforward. Right after \relative is a good time. I don't see anything equally convincing in absolute music, in particular that one must _not_ apply \q _before_ \relative, and one usually does not know in advance whether music is going to pass through \relative yet. And if you delay completely to iteration time, it will not just show identical chords when using \relative, but also across using \transpose and similar. Which also seems awkward. Maybe I am picking the wrong balance point for awkwardness here. No idea. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs: Explain the difference between ritardando and rallentando (issue 5544075)
Pavel, I pushed this for you author Pavel Roskin Thu, 26 Jan 2012 21:22:32 + (21:22 +) committer James Lowe Thu, 26 Jan 2012 21:22:32 + (21:22 +) commit 05efb98f2e3ff68f4bb8221db640b0174bfcde93 Please close this issue. Thanks. James http://codereview.appspot.com/5544075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes.tely: mention Flag changes, remove duplicate "does" (issue 5540058)
Pavel, I pushed for you. author Pavel Roskin Thu, 26 Jan 2012 21:17:13 + (21:17 +) committer James Lowe Thu, 26 Jan 2012 21:19:06 + (21:19 +) commit 224246365f67fb44799fee4eb00e5debea5a35ec Can you close this issue here? James http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plans for changing chord repeat implementations
Le 26 janv. 2012 à 11:00, David Kastrup a écrit :
> The bad news is that absolute pitch friends would have to call the \q
> function (any better name for it?) explicitly. Since q is an input
> convenience, and relative pitch is also an input convenience, I don't
> think that there would be much of an affected user base.
I do use absolute pitch mode, together with the q shortcut, so the
affected user base is non-nil. \relative is to save characters, but `q'
is more than that, it also improves to maintain and read code, so it's
not surprising to see absolute mode and `q' together. Here is a real
word example copied from my code base:
{
R2. |
8-"pincé" q q q q q |
q q q q q q |
q q q q |
q q q q |
q4 r2 |
r8 q q q q |
8 q q q 4 |
4 r2 |
8 q q q q q |
q q q q q q |
r2 4 |
8 q q q q q |
q q q q r4 |
}
What would be the impact of your solution on this kind of code?
Is it just about adding e.g. \q before the block?
Nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: "Reinhold Kainhofer" To: "Julien Rioux" Cc: ; Sent: Thursday, January 26, 2012 4:13 PM Subject: Re: make doc problem On 22/01/2012 20:58, Julien Rioux wrote: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. Cheers, Reinhold It only takes that amount of memory for big builds. I've never seen much over 1 Gig total memory during a make with 8 CPUs all running lilypond. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: silly question: does make doc include running regtests?
- Original Message - From: "Neil Puttock" To: "Janek Warchoł" Cc: "LilyPond Developmet Team" Sent: Thursday, January 26, 2012 5:00 PM Subject: Re: silly question: does make doc include running regtests? 2012/1/26 Janek Warchoł : A potentially silly question: does make doc include running regtests? (i don't mean regtest comparison, just compiling all the snippets) I don't see anything about it in CG. Yes. Cheers, Neil +1 Probably the single longest factor in a make doc. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: silly question: does make doc include running regtests?
2012/1/26 Janek Warchoł : > A potentially silly question: does make doc include running regtests? > (i don't mean regtest comparison, just compiling all the snippets) > I don't see anything about it in CG. Yes. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
silly question: does make doc include running regtests?
A potentially silly question: does make doc include running regtests? (i don't mean regtest comparison, just compiling all the snippets) I don't see anything about it in CG. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 20:58, Julien Rioux wrote: > Thanks, you're quite right CPU is not the limiting factor for the > build. Disk access and usage of swap when compiling > input/regression/collated-files slows down the build to a crawl for me. The problem here is that lilypond builds up memory from 400MB to ~1GB without releasing... Most of these allocations don't seem to be memory leaks, but rather due to guile. 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: Tasks remaining for 2.16 release?
2012/1/26 Graham Percival : >> g) get the translations up to par where there are translation workers > > no, Yes >we've never bothered with that in the past, _we_ have actuall bothered. > and this would > push the release back to 2013 or later Don't underestimate us. Say better 2014. Jokes aside, please allow some time for us to do our work. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tasks remaining for 2.16 release?
2012/1/26 David Kastrup : > As far as I can see, the snippet _code_ is not subject to translation > issues, Right. Just make sure any _needed_ (backwards-incompatible) change in code is made in translations as well. > so e) can be pretty much done in parallel. Translation work > strictly speaking depends on everything else being frozen, but some > overlap should be tolerable. Yes as long as we have 1-2 weeks to finish everything after the rest is finished. If plans to release include forking the stable branch, I would like that also the translation branch is forked at the same time. Otherwise it is nearly unmanageable. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tasks remaining for 2.16 release?
On Thu, Jan 26, 2012 at 12:33:31PM +0100, David Kastrup wrote: > > a) feature freeze. Nothing added that requires documentation changes. why bother? the two-week release candidate takes care of this. > b) get rid of all critical issues yes > c) release candidate(s) yes > d) proofread the docs for obvious mistakes no, we've never bothered with that in the past, and this would push the release back to summer or later > e) make sure all appropriate regtests are there no, we've never bothered with that in the past, and this would push the release back to summer or later > f) update the snippets for stuff that could now be done easier no, we've never bothered with that in the past, and this would push the release back to summer or later > g) get the translations up to par where there are translation workers no, we've never bothered with that in the past, and this would push the release back to 2013 or later > h) release. yes I'd be tempted to add "update LSR to 2.14", but: a) that's not likely to happen due to lack of interest amongst active users (this isn't a developer-only task!) b) we've never bothered with that before - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Tasks remaining for 2.16 release?
Well, here is what I can think off my head. a) feature freeze. Nothing added that requires documentation changes. b) get rid of all critical issues c) release candidate(s) d) proofread the docs for obvious mistakes e) make sure all appropriate regtests are there f) update the snippets for stuff that could now be done easier g) get the translations up to par where there are translation workers h) release. As far as I can see, the snippet _code_ is not subject to translation issues, so e) can be pretty much done in parallel. Translation work strictly speaking depends on everything else being frozen, but some overlap should be tolerable. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change bugreports expected response time (issue 5575047)
On 2012/01/25 22:37:20, mail_philholmes.net wrote: As a Brit, I would write it slightly less definitively. "Please allow a few days". I probably shouldn't have found that as funny as I did. :) I still don't like that, though. As a user, when I report a bug, I want to know that it's been acknowledged -- or at the very least, I want to know when I should get a response. How about we make this 4 days to cover ourselves? We can always decrease that number after a while if things are working out. http://codereview.appspot.com/5575047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Plans for changing chord repeat implementations
Hi, the default chord repeat code contains stuff like ;; If previous-chord has an length property, then it means that it ;; has been processed by a music iterator. In other words, the chord ;; has been memorized from an other music block, which is certainly not ;; what the user has intended, as anywy the result will be buggy. ;; In that case, raise a warning. Ok, this is all sort of madness. Music functions are _free_ to change their arguments and quite a number of them do, not just \relative. It does not do to keep just a pointer to a chord since by the time one actually uses it, it can be trashed in a number of ways. Having a music iterator run over it is just one of many possibilities. Copying the whole chord just because it might get used is expensive and unnecessary. _If_ we try doing this in the parser (and I don't see a really good other place that is reasonably convenient for the user), we should not copy the chord, but just the list of pitches. After all, this is what the documentation of q as far as I can see _claims_ is copied. There is the added complication that a chord can contain more than just pitches: it is possible to have drum types instead. And of course anything sneaked in as rhythmic events via music functions. Of course, when running through \relative or a similarly applied music function that runs over a whole expression in one go would be able to work just with pointers. I have taken a look at the regtests and rest of LilyPond. The only cases where q is being used is either inside of \relative or explicitly for testing absolute mode. So I lean towards removing repeated chord tracking from the parser altogether. You would need to explicitly run a music function for doing the last chord substitutions. to_relative could be made to set a flag when encountering a repeated chord, so that \relative would automatically run the repeated chord substitutor at the end when it was required. That would mean _no_ problems with chords changing under the parser, _no_ need to extract pitches or other information just-in-case, no input syntax change when used simultanously with \relative, and no performance impact when the user does not actually use that feature. It would also reopen the door to extract more than just pitches. The bad news is that absolute pitch friends would have to call the \q function (any better name for it?) explicitly. Since q is an input convenience, and relative pitch is also an input convenience, I don't think that there would be much of an affected user base. Machine-generated output would rarely have to use q. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
