Re: Behaviour of chord repetition in \relative mode
Nicolas Sceaux writes:
> Le 12 déc. 2009 à 14:01, David Kastrup a écrit :
>>
>> { G4 g D // | /// // / // | \time 3/4 G g / | D // // | /// // // | }
>
> Memorizing more than one chord/note (e.g. 3 chords/notes), and accessing
> them using q, qq, qqq, would do it?
Sure. The slashes are, well, cute, but probably a mountain of slashes
like the above is not necessarily more readable.
The advantage of involving the parser is that one does know just how
much to memorize at most, and the memorization can be done by the parser
where it is easier to implement rigid and predictable rules (and avoid
input which just "happens to work" at one time and might break on
unrelated issues later).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Behaviour of chord repetition in \relative mode
"Trevor Daniels" writes:
> Nicolas Sceaux wrote Saturday, December 12, 2009 3:39 PM
>>
>
>> Le 12 déc. 2009 à 14:01, David Kastrup a écrit :
>>>
>>> { G4 g D // | /// // / // | \time 3/4 G g / | D // // | /// // // |
>>> }
>>
>> Memorizing more than one chord/note (e.g. 3 chords/notes), and
>> accessing
>> them using q, qq, qqq, would do it?
>
> Hhm. So when a single new chord is entered explicitly the chords
> held in qq and qqq all move down one? Not sure this is a good
> syntax.
One could use something akin to named editor registers. Those won't
shift.
2-!1-. 4-.-!2 @11-> @2
being equivalent to
2-. 4-. 1-> 4-.
Again, this syntax is not the prettiest.
> If in an existing score I later replace a q with an explicit chord all
> the following q, qq and qqq will need changing too.
Yes. But q, qq, and qqq are not intended for use all across the score,
but rather in confined places. I am not sure that this is all too bad
for writing. But I also am not sure that this is all too good for
reading.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debugging help on lilypond
Carl Sorensen writes: > On 12/12/09 2:27 PM, "Joe Neeman" wrote: > >> On Sat, 2009-12-12 at 14:15 -0700, Carl Sorensen wrote: >>> So I've finally gotten to a point where I think I know what to do with the >>> autobeaming code to make it work properly in 4/4 time with a 1/16 note in >>> the second beat. >>> >>> I've written code to try to fix it. The code seems to execute properly >>> through my changes, but then it gets into a problem, and I get this error >>> message: >>> >>> terminate called after throwing an instance of 'std::out_of_range' >>> what(): vector::_M_range_check >>> Abort trap >>> >>> >>> So I try running it in gdb, and I get the same error. >> >> At this point, you should be able to type "bt" to get a backtrace. You >> can move up and down through the frames by typing "up" and "down" or you >> can jump to the 23rd frame with "fr 23". Once you are in a frame, you >> can examine all of the local variables. The first few frames will >> probably be non-lilypond code, so you'll want to ignore them. > > > Thanks, Joe. This really helped. > > Now I have another problem. I have something that seems impossible to me. Without _any_ analysis of the actual problem, I am just regurgitating some keyword-triggered advice from Emacs' DEBUG file. You might have compiled without optimization in which case it does not apply. This particular option might be considered useful generally since otherwise debugging any abort/failed assertion (and what's the use of abort without debugging?) becomes quite useless. Spent days on hunting down an "impossible bug" more than once. ** When you are trying to analyze failed assertions, it will be essential to compile Emacs either completely without optimizations or at least (when using GCC) with the -fno-crossjumping option. Failure to do so may make the compiler recycle the same abort call for all assertions in a given function, rendering the stack backtrace useless for identifying the specific failed assertion. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Behaviour of chord repetition in \relative mode
Le 13 déc. 2009 à 11:05, David Kastrup a écrit :
>> If in an existing score I later replace a q with an explicit chord all
>> the following q, qq and qqq will need changing too.
>
> Yes. But q, qq, and qqq are not intended for use all across the score,
> but rather in confined places. I am not sure that this is all too bad
> for writing. But I also am not sure that this is all too good for
> reading.
When used with parsimony, it can be helful, and not too bad for reading.
For instance, when there are loads of triplets like the following (I
faced that case a week ago, and was frustrated not being able to use q):
\times 2/3 { qq }
Also, it would solve the chords only vs. all notes issue. If it is
possible to refer to the two or three previous notes, then all chords and
simple notes (even rests: e.g. d4\rest) can be memorized.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
issue classification debate
I wanted to wait until GOP started, but it seems there's a lot of interest in this now. Here's my proposed new classifications for issues. There are four hopefully-not-really-contradictory goals, listed in order: 1. easy for core developers to find the type of bug they want to work on 2. easy for new developers to find the type of bug they want to work on. 3. easy for non-technical, non-musically-literate, inexperienced Bug Meisters to add+classify items[*]. 4. understandable by normal users who haven't read the issue tag descriptions in the CG. [*] This isn't an insult directed at our current Bug Meisters; it's just my observation that we cannot afford to require that the bug meister know anything about lilypond programming, or even be an expert lilypond user. We don't have enough volunteers to be that picky. But that's ok; remember, I did a great job (if I may say so myself) despite not having a clue how vocal music worked, either in printed music or in lilypond. %% for Type, we match the first relevant item on the list. Type-collision: keep Type-defect: keep. However, this will now include all defects, not just "minor code changes". (see below) Type-documentation: keep Type-build: new type, but I think it's worth it. Used for GUB, makefiles, stepmake, and python scripts which are used in the build system. Type-scripts: convert-ly, lilypond-book, etc. Type-enhancement: keep. However, this will now only be for "new features", not "large code fixes". (see below) Type-other: keep Defect vs. Enhancement: historically, the idea was that a fix which required a large amount of new code would be an enhancement. For example, if two grobs were colliding but it would require a new piece of architecture to detect the collision, this would be classified as an enhancement. I've had any number of debates / clarifications about this over the years, and I'm sick of it. I'd like to say that an enhancement would be a new user-visible feature (such as the baroque tablature stuff), while anything that fixed the expected behaviour would be a collision or defect. This proposal might violate goal #1 (be convenient for core developers). I'm willing to drop this proposal if they speak out against it, but I'd really like this to go through, since nobody else understands the current distinction. %% for now, only Critical will block a stable release. In the future, it would be nice %% to consider High as also release-blocking, but that's not on the cards yet. Priority-Critical: segfaults, or a regression within the last two stable versions (right now, against 2.10.33)anything currently ranked as High would become Critical. Priority-High: this is Werner's "really annoying" idea. Priority-Medium: keep. Also, any regression later against a version less than 2.10.33 will become a medium item (unless the output is sufficiently bad to qualify it as High). Priority-Low: keep Priority-Postponed: keep At the moment I have no ideas as to how to assign any priority below High. If anybody could propose guidelines that inexperienced, non-musically-literate Bug Meisters could follow, that would be great. The best I can think of is to say "try to have 20% postponed, 40% low, 30% medium, and 10% high" and let them try to do relative rankings. %% Opsys: no change %% Tags Regression: new tag, taking over the old Priority-Regression. As stated above, very old regressions no longer get release-blocking priority. bounty, maintability, patch, frog, performance, security: keep Warning: renamed from "warning-nitpick" due to the way google deals with tags. I'm going to add a link to "label:warning" from the CG, since these are AFAIK easy things for Frogs to work on. Remove engraving and usability: these now get wrapped into the normal issue type and priorities. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification debate
Hi Graham, Graham Percival wrote: I wanted to wait until GOP started, but it seems there's a lot of interest in this now. Here's my proposed new classifications for issues. There are four hopefully-not-really-contradictory goals, listed in order: 1. easy for core developers to find the type of bug they want to work on 2. easy for new developers to find the type of bug they want to work on. 3. easy for non-technical, non-musically-literate, inexperienced Bug Meisters to add+classify items[*]. 4. understandable by normal users who haven't read the issue tag descriptions in the CG. [*] This isn't an insult directed at our current Bug Meisters; it's just my observation that we cannot afford to require that the bug meister know anything about lilypond programming, or even be an expert lilypond user. We don't have enough volunteers to be that picky. But that's ok; remember, I did a great job (if I may say so myself) despite not having a clue how vocal music worked, either in printed music or in lilypond. %% for Type, we match the first relevant item on the list. Type-collision: keep Type-defect: keep. However, this will now include all defects, not just "minor code changes". (see below) Type-documentation: keep Type-build: new type, but I think it's worth it. Used for GUB, makefiles, stepmake, and python scripts which are used in the build system. Just a thought, use two new types: Type-kit-generation: for GUB and other things that generate the build Type-build: for the build files themselves that actually compile and install Lily on a particular platform. E.g. you could classify a bug using this type to get an emergency patch out so Lily will build on a specific platform, and then handle any GUB changes under a kit-generation issue so you and Jan could spend a bit more time getting GUB to produce the right thing. Type-scripts: convert-ly, lilypond-book, etc. Type-enhancement: keep. However, this will now only be for "new features", not "large code fixes". (see below) Type-other: keep Defect vs. Enhancement: historically, the idea was that a fix which required a large amount of new code would be an enhancement. For example, if two grobs were colliding but it would require a new piece of architecture to detect the collision, this would be classified as an enhancement. I've had any number of debates / clarifications about this over the years, and I'm sick of it. I'd like to say that an enhancement would be a new user-visible feature (such as the baroque tablature stuff), while anything that fixed the expected behaviour would be a collision or defect. This proposal might violate goal #1 (be convenient for core developers). I'm willing to drop this proposal if they speak out against it, but I'd really like this to go through, since nobody else understands the current distinction. Which side of the line does *user-perceived* missing functionality go? In the sense of it's something Lilypond hasn't done yet, but users coming to Lilypond with experience of other music-setting software feel is really lacking. E.g. former Igor user reporting midi-playback not observing dynamic and tempo changes and repeats. The user may feel this is a defect, developers may take the view it's an enhancement request. We need a decision here, not a debate. My feeling would be log it as an enhancement request, but make sure you record that the original reporter considers it a defect. %% for now, only Critical will block a stable release. In the future, it would be nice %% to consider High as also release-blocking, but that's not on the cards yet. Priority-Critical: segfaults, or a regression within the last two stable versions (right now, against 2.10.33)anything currently ranked as High would become Critical. Priority-High: this is Werner's "really annoying" idea. Priority-Medium: keep. Also, any regression later against a version less than 2.10.33 will become a medium item (unless the output is sufficiently bad to qualify it as High). Priority-Low: keep Priority-Postponed: keep At the moment I have no ideas as to how to assign any priority below High. If anybody could propose guidelines that inexperienced, non-musically-literate Bug Meisters could follow, that would be great. The best I can think of is to say "try to have 20% postponed, 40% low, 30% medium, and 10% high" and let them try to do relative rankings. %% Opsys: no change %% Tags Regression: new tag, taking over the old Priority-Regression. As stated above, very old regressions no longer get release-blocking priority. bounty, maintability, patch, frog, performance, security: keep Warning: renamed from "warning-nitpick" due to the way google deals with tags. I'm going to add a link to "label:warning" from the CG, since these are AFAIK easy things for Frogs to work on. Does this cover things like the compilation squawks we see currently in the C++ files: warning converting int64 -> int may change a value, and su
Re: issue classification debate
On Sun, Dec 13, 2009 at 12:36 PM, Ian Hulin wrote: > Hi Graham, > Graham Percival wrote: >> >> >> %% for Type, we match the first relevant item on the list. >> Type-build: new type, but I think it's worth it. Used for GUB, >> makefiles, stepmake, and python scripts which are used in the build >> system. > > Just a thought, use two new types: > Type-kit-generation: for GUB and other things that generate the build > Type-build: for the build files themselves that actually compile and install > Lily on a particular platform. E.g. you could classify a bug using this > type to get an emergency patch out so Lily will build on a specific > platform, and then handle any GUB changes under a kit-generation issue so > you and Jan could spend a bit more time getting GUB to produce the right > thing. I'd rather not have too many Types; 8 is already pushing it. We're not going to have all that many build issues, anyway. :) > Which side of the line does *user-perceived* missing functionality go? In > the sense of it's something Lilypond hasn't done yet, but users coming to > Lilypond with experience of other music-setting software feel is really > lacking. E.g. former Igor user reporting midi-playback not observing > dynamic and tempo changes and repeats. The user may feel this is a defect, > developers may take the view it's an enhancement request. > We need a decision here, not a debate. My feeling would be log it as an > enhancement request, but make sure you record that the original reporter > considers it a defect. It would be logged as an enhancement, with no record that the original reporter thought it was a defect. We don't need yet another layer of virtual paperwork to take care of; the initial reporter's opinions about the classification don't matter. >> Warning: renamed from "warning-nitpick" due to the way google deals with >> tags. >> I'm going to add a link to "label:warning" from the CG, since these are >> AFAIK easy things for Frogs to work on. > > Does this cover things like the compilation squawks we see currently in the > C++ files: warning converting int64 -> int may change a value, and suchlike? Hmm... I guess it could. I hadn't really thought about that. The basic idea behind "warnings" is "the output is exactly as expected, but either 1) it should generate a warning (say, a bar-line check failed?) or 2) it generates a false warning (generally a programming error"). We can apply this to the compilation process as well. ... hmm, now I'm wondering if such issues would be better put under Build. Actually, I'm pretty certain I'd rather see them in Build. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue classification debate
On Sun, Dec 13, 2009 at 1:06 PM, Ian Hulin wrote: > Was just looking in CG section 6.2. Does Status value *Accepted* mean that > the defect is definitely reproducible by more than one person on more than > one computer? Is this one of the bugmeister's criteria for accepting an > issue? If it isn't, should it be? "Accepted" is the default value when the bug meister adds something. It goes - accepted - started (sometimes; we're not very strict about this) - fix - verified "New" means that somebody ignored the "PLEASE DO NOT ADD ITEMS DIRECTLY" message and added something directly to the tracker. When a Bug Meister looks at such items, they either mark it invalid, duplicate, or accepted. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
2009/12/13 Mark Polesky : > Is there a way to improve this? I don't want to put too > much extra stress on CPU1 if I run `make check' alot. Or am > I being paranoid? make -j5 CPU_COUNT=5 check Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue #305 still has `started' status?
2009/12/12 Werner LEMBERG : > have you finished your work on fixing #305? I can vaguely remember > something into this direction ... Not yet; I'm trying to sort out a consistent method for allowing explicit directions to override the alignment spanner. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 2:00 PM, Neil Puttock wrote: > 2009/12/13 Mark Polesky : > >> Is there a way to improve this? I don't want to put too >> much extra stress on CPU1 if I run `make check' alot. Or am >> I being paranoid? > > make -j5 CPU_COUNT=5 check Be warned that sometimes lilypond-book has hash collisions in the filename, which can lead to weird compile errors when one process finished dealing with aa/lily-.ps (and thus deletes it), while another process has finished generating aa/lily-.ps but hasn't started running ps2pdf yet, and thus doesn't find the file that it just wrote. http://code.google.com/p/lilypond/issues/detail?id=867 If you use that command and something breaks, run "make check", wait 10 seconds or so, then cancel that, and then re-run the fancier command. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
2009/12/13 Graham Percival : > Be warned that sometimes lilypond-book has hash collisions in the > filename, which can lead to weird compile errors when one process > finished dealing with aa/lily-.ps (and thus deletes it), while > another process has finished generating aa/lily-.ps but hasn't > started running ps2pdf yet, and thus doesn't find the file that it > just wrote. I used to use -j3 CPU_COUNT=3 on my dual-core system, but since changing back to -j2 CPU_COUNT=2, I've had no hash collisions; it doesn't make any difference to the build times as far as I can tell. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 2:18 PM, Neil Puttock wrote: > 2009/12/13 Graham Percival : > >> Be warned that sometimes lilypond-book has hash collisions in the >> filename, which can lead to weird compile errors when one process >> finished dealing with aa/lily-.ps (and thus deletes it), while >> another process has finished generating aa/lily-.ps but hasn't >> started running ps2pdf yet, and thus doesn't find the file that it >> just wrote. > > I used to use -j3 CPU_COUNT=3 on my dual-core system, but since > changing back to -j2 CPU_COUNT=2, I've had no hash collisions; it > doesn't make any difference to the build times as far as I can tell. It's a serious annoyance for me, since I have a quad-core system. Building the docs for GUB takes at least twice as long as generating all the binaries and their installers! I don't think it would be hard to fix this issue for anybody who knows python, but I'm too busy putting out fires to take a look at it. :( Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 12:13 PM, Graham Percival wrote: > On Sun, Dec 13, 2009 at 2:00 PM, Neil Puttock wrote: >> 2009/12/13 Mark Polesky : >> >>> Is there a way to improve this? I don't want to put too >>> much extra stress on CPU1 if I run `make check' alot. Or am >>> I being paranoid? >> >> make -j5 CPU_COUNT=5 check > > Be warned that sometimes lilypond-book has hash collisions in the > filename, which can lead to weird compile errors when one process > finished dealing with aa/lily-.ps (and thus deletes it), while > another process has finished generating aa/lily-.ps but hasn't > started running ps2pdf yet, and thus doesn't find the file that it > just wrote. Do you have real evidence for that? We use 10 hex digits, yielding 2^40 combinations, so a 2^20 (one in a million) chance of collisions. I think it is more likely that there is some kind of bug going on, given the state of the build system. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 2:26 PM, Han-Wen Nienhuys wrote: > On Sun, Dec 13, 2009 at 12:13 PM, Graham Percival > wrote: >> On Sun, Dec 13, 2009 at 2:00 PM, Neil Puttock wrote: >>> 2009/12/13 Mark Polesky : >>> Is there a way to improve this? I don't want to put too much extra stress on CPU1 if I run `make check' alot. Or am I being paranoid? >>> >>> make -j5 CPU_COUNT=5 check >> >> Be warned that sometimes lilypond-book has hash collisions in the >> filename, which can lead to weird compile errors when one process >> finished dealing with aa/lily-.ps (and thus deletes it), while >> another process has finished generating aa/lily-.ps but hasn't >> started running ps2pdf yet, and thus doesn't find the file that it >> just wrote. > > Do you have real evidence for that? We use 10 hex digits, yielding > 2^40 combinations, so a 2^20 (one in a million) chance of collisions. What happens if we include a regtest in the docs? Or include a snippet in the docs? There's probably one or two .ly files in Documentation/snippets/ that get compiled in 3 places (snippets.tely, rhythms.itely, and expressive.itely, for example). No matter what the hash function is, hash(X) == hash(X). Unless we use a pseudo-random hash function. :) This bug occurred right after we changed the hash function to only look at the snippet contents without including the preamble, which makes it more likely that it's a "snippet frmo 1 manual coliding with the same snippet in another manual, but with slightly different compile options" thing. > I think it is more likely that there is some kind of bug going on, > given the state of the build system. I've seen weird bugs that have to do with scheme not finding a file (I'm not 90% certain it was a .ps file), when the .ly file was definitely there. Those bugs go away when I do a single-threaded bug. These multi-threaded bugs are not consistent. (a few days ago, I tried replicating it in a tiny lilypond-book file with 8 identical snippets; out of about 20 attempts to compile it, it failed once) I tried dumping a "print 'PANIC'" in lilypond-book in the function that generates the name if it found an existing file there already. It panicked. I tried adding a "time.sleep(10)" if it detected the file already existing, but that didn't end up helping. (this was back in Oct, not earlier this week.) At this point, I gave up and changed gub/specs/lilypond-docs.py in GUB to "parallel_build_broken = True", because there were much more important problems in GUB at the time. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
Han-Wen Nienhuys writes: > On Sun, Dec 13, 2009 at 12:13 PM, Graham Percival > wrote: >> On Sun, Dec 13, 2009 at 2:00 PM, Neil Puttock wrote: >>> 2009/12/13 Mark Polesky : >>> Is there a way to improve this? I don't want to put too much extra stress on CPU1 if I run `make check' alot. Or am I being paranoid? >>> >>> make -j5 CPU_COUNT=5 check >> >> Be warned that sometimes lilypond-book has hash collisions in the >> filename, which can lead to weird compile errors when one process >> finished dealing with aa/lily-.ps (and thus deletes it), while >> another process has finished generating aa/lily-.ps but hasn't >> started running ps2pdf yet, and thus doesn't find the file that it >> just wrote. > > Do you have real evidence for that? We use 10 hex digits, yielding > 2^40 combinations, so a 2^20 (one in a million) chance of collisions. If we are talking about 2 particular files colliding. If we are talking about a collision in n files, there are n(n+1)/2 combinations all of which have a 2^20 chance of collision (of course, those are not independent collisions, but the approximation is pretty good). A 1% chance of collision is (first order approximation) achieved when n(n+1)/2=1, meaning n is something like 140. Close enough to make 40 bits feel uncomfortable. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 12:44 PM, David Kastrup wrote: >>> Be warned that sometimes lilypond-book has hash collisions in the >>> filename, which can lead to weird compile errors when one process >>> finished dealing with aa/lily-.ps (and thus deletes it), while >>> another process has finished generating aa/lily-.ps but hasn't >>> started running ps2pdf yet, and thus doesn't find the file that it >>> just wrote. >> >> Do you have real evidence for that? We use 10 hex digits, yielding >> 2^40 combinations, so a 2^20 (one in a million) chance of collisions. > > If we are talking about 2 particular files colliding. If we are talking > about a collision in n files, there are n(n+1)/2 combinations all of > which have a 2^20 chance of collision (of course, those are not > independent collisions, but the approximation is pretty good). A 1% > chance of collision is (first order approximation) achieved when > n(n+1)/2=1, meaning n is something like 140. > > Close enough to make 40 bits feel uncomfortable. This is trivially fixed by changing the line ## let's not create too long names. self.checksum = hash.hexdigest ()[:10] in lilypond-book.py, I doubt that this will fix the problem though. Note that the proposed race condition would also require the colliding files to be processed by different lilypond subprocesses, and be passing through the (ps -> pdf) conversion of the same file at the same time. theoretically, not impossible but I would not bet my money on this being the problem. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
Han-Wen Nienhuys writes: > On Sun, Dec 13, 2009 at 12:44 PM, David Kastrup wrote: > Be warned that sometimes lilypond-book has hash collisions in the filename, which can lead to weird compile errors when one process finished dealing with aa/lily-.ps (and thus deletes it), while another process has finished generating aa/lily-.ps but hasn't started running ps2pdf yet, and thus doesn't find the file that it just wrote. >>> >>> Do you have real evidence for that? We use 10 hex digits, yielding >>> 2^40 combinations, so a 2^20 (one in a million) chance of collisions. >> >> If we are talking about 2 particular files colliding. If we are talking >> about a collision in n files, there are n(n+1)/2 combinations all of >> which have a 2^20 chance of collision (of course, those are not >> independent collisions, but the approximation is pretty good). A 1% >> chance of collision is (first order approximation) achieved when >> n(n+1)/2=1, meaning n is something like 140. >> >> Close enough to make 40 bits feel uncomfortable. > > This is trivially fixed by changing the line > > ## let's not create too long names. > self.checksum = hash.hexdigest ()[:10] > > in lilypond-book.py, I doubt that this will fix the problem though. > > Note that the proposed race condition would also require the colliding > files to be processed by different lilypond subprocesses, and be > passing through the (ps -> pdf) conversion of the same file at the > same time. > > theoretically, not impossible but I would not bet my money on this > being the problem. Well, make does the equivalent of a tsort on its dependencies, and I would not surprised if the tiebreaker was an alphabetical sort on filenames. So if the hashed filenames pass through make (no idea if they do), even just two threads are likely to be be hit by a hash collision. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
race condition in writing lilypond-book filenames
diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
index 392ddd0..b9731f1 100644
--- a/scripts/lilypond-book.py
+++ b/scripts/lilypond-book.py
@@ -1273,7 +1273,11 @@ left-margin-default right-margin-default)"
directory = os.path.split(path)[0]
if not os.path.isdir (directory):
os.makedirs (directory)
-out = file (path + '.ly', 'w')
+filename = path + '.ly'
+if os.path.exists(filename):
+print "PANIC! ", filename, "already exists!"
+sys.exit(1)
+out = file (filename, 'w')
out.write (self.full_ly ())
file (path + '.txt', 'w').write ('image of music')
make doc-clean
make clean
nice make -j3
...
Reading /home/gperciva/src/lilypond/Documentation/usage/lilypond-book.itely...
Dissecting...
Writing snippets...PANIC!
/main/src/build-lilypond/out/lybook-db/85/lily-dabb3c4a.ly already
exists!
make[1]: *** [out/usage.texi] Error 1
make[1]: *** Waiting for unfinished jobs
rm out/web.texi
make[1]: Leaving directory `/main/src/build-lilypond/Documentation'
make: *** [all] Error 2
I'm honestly surprised I got this with a simple "make" instead of "make doc".
... oh wait, this file is , which is at the beginning of the
LM. Of course it would generate the same file multiple times... once
for the HTML output, once for PDF, maybe a third time for info?
... oh wait *2, just running "make" shouldn't generate the HTML/PDF.
Hmm... maybe the second time through, it was generating a translation
of the LM?
In any case, we definitely have the same filename being used multiple
times when building lilypond. Is this a problem? I can't say for
certainty, but I *do* know that unpredictable race conditions occur in
the docs when building with more than one process.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
Oh wait - there is one thing I did not think about: snippets may be shared by different documents, so if you use make -jX it is conceivable that make invokes two separate lilypond processes that have non-empty intersection of their arguments. For now, the easy fix is to use -j1 with CPU_COUNT for building the docs. A more elaborate solution would be either some kind of locking, or to check whether the .ps / .pdf exists before actually processing the .ly; the latter is still suscepitible to races, though, but a check could make the opportunity window smaller. A last solution would be to unshare the snippet database, but that would mean a lot of double processing and extra disk usage, because every translation would have to do 90% of the snippets all over again, and store them separately. On Sun, Dec 13, 2009 at 1:48 PM, David Kastrup wrote: > Han-Wen Nienhuys writes: > >>> If we are talking about 2 particular files colliding. If we are talking >>> about a collision in n files, there are n(n+1)/2 combinations all of >>> which have a 2^20 chance of collision (of course, those are not >>> independent collisions, but the approximation is pretty good). A 1% >>> chance of collision is (first order approximation) achieved when >>> n(n+1)/2=1, meaning n is something like 140. >>> >>> Close enough to make 40 bits feel uncomfortable. >> >> This is trivially fixed by changing the line >> >> ## let's not create too long names. >> self.checksum = hash.hexdigest ()[:10] >> >> in lilypond-book.py, I doubt that this will fix the problem though. >> >> Note that the proposed race condition would also require the colliding >> files to be processed by different lilypond subprocesses, and be >> passing through the (ps -> pdf) conversion of the same file at the >> same time. >> >> theoretically, not impossible but I would not bet my money on this >> being the problem. > > Well, make does the equivalent of a tsort on its dependencies, and I > would not surprised if the tiebreaker was an alphabetical sort on > filenames. > > So if the hashed filenames pass through make (no idea if they do), even > just two threads are likely to be be hit by a hash collision. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 3:55 PM, Han-Wen Nienhuys wrote: > Oh wait - there is one thing I did not think about: snippets may be > shared by different documents, Yes, that was my point about snippets being included in snippets.tely and (for example) rhythms.itely. > For now, the easy fix is to use -j1 with CPU_COUNT for building the docs. Yes; that became the recommended way in Oct. But it's much slower than it would otherwise be. > A more elaborate solution would be either some kind of locking, or to > check whether the .ps / .pdf exists before actually processing the > .ly; the latter is still suscepitible to races, though, but a check > could make the opportunity window smaller. I think a .lock would be good. That's the typical solution to everything when it comes to parallel processing. :) Cheers,, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 2:02 PM, Graham Percival wrote: >> Oh wait - there is one thing I did not think about: snippets may be >> shared by different documents, > > Yes, that was my point about snippets being included in snippets.tely > and (for example) rhythms.itely. > >> For now, the easy fix is to use -j1 with CPU_COUNT for building the docs. > > Yes; that became the recommended way in Oct. But it's much slower > than it would otherwise be. That surprises me. I thought the majority of the time was spent running LilyPond, which would be efficient with CPU_COUNT set, so the difference should be small. >> A more elaborate solution would be either some kind of locking, or to >> check whether the .ps / .pdf exists before actually processing the >> .ly; the latter is still suscepitible to races, though, but a check >> could make the opportunity window smaller. > > I think a .lock would be good. That's the typical solution to > everything when it comes to parallel processing. :) Right - the script should do an flock() on the database directory when opening it. (doesnt work on NFS though) -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dynamics context spacing issues
2009/10/13 Neil Puttock :
> 2009/10/12 Joe Neeman :
>
>> Thanks for testing. Do you have an example to show the problem? It was
>> certainly my intention to have Dynamics work with alignment-distances.
>
> Sure, try this:
I've had another look at this, and it seems the only way to get this
to work is to switch off 'staff-affinity and set the distances for
each axis-group (including the loose lines):
upper = \relative c'' {
\clef treble
a4 b c d
}
lower = \relative c {
\clef bass
a2 c
}
dynamics = {
s2\fff\> s4 s\!\pp
}
pedal = {
s2\sustainOn s\sustainOff
}
\score {
\new PianoStaff = "PianoStaff_pf" <<
\new Staff = "Staff_pfUpper" \upper
\new Dynamics = "Dynamics_pf" \dynamics
\new Staff = "Staff_pfLower" \lower
\new Dynamics \pedal
>>
\layout {
\context {
\Score
\override NonMusicalPaperColumn #'line-break-system-details =
#'((alignment-distances . (10 10 5)))
}
\context {
\Dynamics
\revert VerticalAxisGroup #'staff-affinity
% this was in the original template, but probably should be
% added to engraver-init.ly
\override DynamicLineSpanner #'Y-offset = ##f
}
}
}
Am I mistaken in thinking alignment-distances is supposed to ignore
the loose lines between staves?
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 02:27:53PM -0200, Han-Wen Nienhuys wrote: > On Sun, Dec 13, 2009 at 2:02 PM, Graham Percival > wrote: > >> For now, the easy fix is to use -j1 with CPU_COUNT for building the docs. > > > > Yes; that became the recommended way in Oct. But it's much slower > > than it would otherwise be. > > That surprises me. I thought the majority of the time was spent > running LilyPond, which would be efficient with CPU_COUNT set, so the > difference should be small. Ack! Sorry, I misread your solution. It never occurred to me to try -j1 CPU_COUNT=4. I'll do that tomorrow. > >> A more elaborate solution would be either some kind of locking, or to > >> check whether the .ps / .pdf exists before actually processing the > >> .ly; the latter is still suscepitible to races, though, but a check > >> could make the opportunity window smaller. > > > > I think a .lock would be good. That's the typical solution to > > everything when it comes to parallel processing. :) > > Right - the script should do an flock() on the database directory when > opening it. > > (doesnt work on NFS though) On the entire directory, or just on the lybook-db/??/ dir? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: race condition in writing lilypond-book filenames
Hi,
On Sun, Dec 13, 2009 at 03:55:00PM +, Graham Percival wrote:
> diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
> index 392ddd0..b9731f1 100644
> --- a/scripts/lilypond-book.py
> +++ b/scripts/lilypond-book.py
> @@ -1273,7 +1273,11 @@ left-margin-default right-margin-default)"
> directory = os.path.split(path)[0]
> if not os.path.isdir (directory):
> os.makedirs (directory)
> -out = file (path + '.ly', 'w')
> +filename = path + '.ly'
> +if os.path.exists(filename):
> +print "PANIC! ", filename, "already exists!"
> +sys.exit(1)
> +out = file (filename, 'w')
> out.write (self.full_ly ())
> file (path + '.txt', 'w').write ('image of music')
It's still possible that a file gets overwritten, for example if
one process creates the output file *after* another process checked
wether it exists, but *before* that other process actually creates
the file.
Anyway, I had an idea after seeing that diff...
> In any case, we definitely have the same filename being used multiple
> times when building lilypond. Is this a problem? I can't say for
> certainty, but I *do* know that unpredictable race conditions occur in
> the docs when building with more than one process.
If the a file with the same name always has the same content,
regardless from which document it has been generated, would something
like the following help (no real code, i'm not good at all if it
comes to python)?
- write the output to a temporary file (with a unique filename, but
within the same directory)
- after writing the temporary file, test wether a file with the final
name (path + '.ly') already exists
- if not, just rename the tempory file to the final name
- if it already existed, remove the temporary file (here one could
additionally compare the two files and error out if they differ)
There's still a race here (again, between the check wether the final
file exists and the actual renaming). However, if equally named
files are expected to have the same content, this race doesn't
matter, because renaming a file is an atomic operation, and because
the final file will always be complete.
Ciao,
Kili
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Tracker 918, Add extra RemoveEmpty*StaffContext functions to support "Frenched" scores (issue165096)
On 2009/12/12 00:12:16, Ian Hulin wrote: I've implemented Neil's comments, re-run regression tests locally and uploaded amended patches to Rietveld. Thanks! I think this should be ready to push now. Nearly there: You're playing catch-up with the \version strings. :) Both hara-kiri-rhythmicstaff.ly and hara-kiri-tabstaff.ly still need reformatting in the same way as hara-kiri-drumstaff.ly Cheers, Neil http://codereview.appspot.com/165096 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Debugging help on lilypond
Quoting David Kastrup: Without _any_ analysis of the actual problem, I am just regurgitating some keyword-triggered advice from Emacs' DEBUG file. You might have compiled without optimization in which case it does not apply. This particular option might be considered useful generally since otherwise debugging any abort/failed assertion (and what's the use of abort without debugging?) becomes quite useless. Spent days on hunting down an "impossible bug" more than once. I've compiled LilyPond using --disable-optimizing, so it should be debuggable. I'm running gdb directly from the command prompt, rather than through Emacs, so I don't think the optimization of Emacs should apply. But if I'm wrong in these assumptions, I'd be happy to have you tell me and give me some pointers as to what to do. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature
2009/12/11 Trevor Daniels : > I've just posted patch set 3 to Reitveld, after quite > some struggles with juggling regression-testing and > doc-building in a too-small virtual ubuntu system. > > See http://codereview.appspot.com/164063 Looks fine to me apart from some formatting nitpicks. I'll post some comments on Rietveld shortly. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: race condition in writing lilypond-book filenames
On Sun, Dec 13, 2009 at 05:49:13PM +0100, Matthias Kilian wrote:
> If the a file with the same name always has the same content,
> regardless from which document it has been generated, would something
> like the following help (no real code, i'm not good at all if it
> comes to python)?
Don't laugh at me -- I can't even test this here on OpenBSD, because
I don't have all prerequisites available in the necessery versions.
diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
index 392ddd0..35a1d8a 100644
--- a/scripts/lilypond-book.py
+++ b/scripts/lilypond-book.py
@@ -1273,8 +1273,17 @@ left-margin-default right-margin-default)"
directory = os.path.split(path)[0]
if not os.path.isdir (directory):
os.makedirs (directory)
-out = file (path + '.ly', 'w')
+out = tempfile.NamedTemporaryFile(mode = 'w', suffix = '.lytmp',
+ dir = directory, delete = False)
out.write (self.full_ly ())
+out.close()
+filename = path + '.ly'
+if os.path.exists(filename):
+# What else? Print a warning? Compare both files and error
+# out if they differ?
+os.remove(out.name)
+else:
+os.rename(out.name, filename)
file (path + '.txt', 'w').write ('image of music')
def relevant_contents (self, ly):
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
On Sun, Dec 13, 2009 at 2:46 PM, Graham Percival wrote: >> >> A more elaborate solution would be either some kind of locking, or to >> >> check whether the .ps / .pdf exists before actually processing the >> >> .ly; the latter is still suscepitible to races, though, but a check >> >> could make the opportunity window smaller. >> > >> > I think a .lock would be good. That's the typical solution to >> > everything when it comes to parallel processing. :) >> >> Right - the script should do an flock() on the database directory when >> opening it. >> >> (doesnt work on NFS though) > > On the entire directory, or just on the lybook-db/??/ dir? I was thinking about the NFS case, as this is something I encounter at Google in some of my projects, which I think we should not try to cater for. The lock could just be per file, using file system locks (which are simple to use and efficient). Probably ly:parse-file should just lock and unlock the file while processing it. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix STEPMAKE_GET_VERSION for OpenBSD
Hi,
I have this as a patch in the lilypond port of OpenBSD for years
(since 2006, IIRC), and it looks like I still need it for the
development branch. Without this, configure isn't able to detect
the versions of at least texi2html, makeinfo and bison. (I really
don't remember the reason, too much time has passed since I made
this patch)
Please be sure that it doesn't blow up configure on other systems.
Ciao,
Kili
diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4
index 83c07c3..59a2267 100644
--- a/stepmake/aclocal.m4
+++ b/stepmake/aclocal.m4
@@ -32,9 +32,14 @@ AC_DEFUN(STEPMAKE_GET_VERSION, [
## for compatibility reasons.
## grab the first version number in --version output.
-eval _ver=\"\`("$1" --version || "$1" -V) 2>&1 | grep '\(^\|
\)[0-9][0-9]*\.[0-9]' \
-| head -n 1 \
- | tr ' ' '\n' | sed 's/\([0-9][0-9]*\.[0-9][0-9.]*\).*/\1/g' | grep
'\(^\| \)[0-9][0-9]*\.[0-9]' | head -n 1\`\"
+eval '_ver=\`'"$1"' --version 2>&1\` || _ver=\`'"$1"' -V 2>&1\` &&
+_ver=\`echo $_ver |
+ grep '\''[0-9]\.[0-9]'\'' |
+ head -n 1 |
+ tr '\'' '\'' '\''\n'\'' |
+ grep '\''[0-9]\.[0-9]'\'' |
+ head -n 1 |
+ sed '\''s/\([0-9.]*\).*/\1/g'\''\`'
if test -z "$_ver"; then
## If empty, try date [fontforge]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: UTF-8 support needs implementing to fix all bidi/rtl/ltr issues
On 2009-12-11, Ted Walther wrote: > Thank you for filing that bug issue! How are things progressing? Also, > can I make a $100 donation in gratitude to the person implementing the > fix? Who is the responsible party to send the money to? I think this issue is fixed now. As Valentin noted, please wait until 2.13.10 is released to verify that everything works for you. Looking at your Shema4.ly file again, you should be able to get this working with 2.13.9 or earlier. Try wrapping some of the multi-character Hebrew syllables with U+202D and U+202C; for example, יש should be rendered left-to-right. You'll see erroneous warnings (that will be fixed in 2.13.10), but the file should compile fine. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build failure on OS X: "error: template class without a name"
2009/12/12 Harmath Dénes : > And yes, this solved the problem! You're right, flex is among the > dependencies. > Concluding it, I think two things may be worth adding to the CG 2.1.6: > * the workaround of the C++ related problem: perl -pi -e > 's|__vector|lily_vector|g' flower/include/std-vector.hh Isn't this something we should fix in the LilyPond source instead, so we don't have to worry about it anymore? -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
Le dimanche 13 décembre 2009 à 16:48 +0100, David Kastrup a écrit : > So if the hashed filenames pass through make (no idea if they do) They don't, they pass between lilypond-book and lilypond. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Hi Trevor,
Here are a few comments as promised earlier.
Cheers,
Neil
http://codereview.appspot.com/164063/diff/5001/5002
File Documentation/changes.tely (right):
http://codereview.appspot.com/164063/diff/5001/5002#newcode73
Documentation/changes.tely:73: \new TabStaff
trailing space
http://codereview.appspot.com/164063/diff/5001/5002#newcode79
Documentation/changes.tely:79: \set fretLabels = #`(,(markup
#:with-color red "a")
trailing space
http://codereview.appspot.com/164063/diff/5001/5002#newcode80
Documentation/changes.tely:80: "b"
trailing space
http://codereview.appspot.com/164063/diff/5001/5003
File input/regression/tablature-letter.ly (right):
http://codereview.appspot.com/164063/diff/5001/5003#newcode23
input/regression/tablature-letter.ly:23: \set fretLabels = #`("α" "β"
"γ")
#'
http://codereview.appspot.com/164063/diff/5001/5005
File lily/grob.cc (right):
http://codereview.appspot.com/164063/diff/5001/5005#newcode160
lily/grob.cc:160: /* Call the scheme procedure stencil-whiteout in
scm/stencils.scm */
I'd use { } here if you want this comment placed before the code.
http://codereview.appspot.com/164063/diff/5001/5005#newcode162
lily/grob.cc:162: retval = *unsmob_stencil (scm_call_1 (
If you newline at the parenthesis, the following lines should be
indented accordingly, but this will make the line quite long so it's
probably better to start on the following line:
retval
= *unsmob_stencil (scm_call_1 (ly_lily_module_constant
("stencil-whiteout"),
retval.smobbed_copy()));
http://codereview.appspot.com/164063/diff/5001/5010
File scm/translation-functions.scm (right):
http://codereview.appspot.com/164063/diff/5001/5010#newcode398
scm/translation-functions.scm:398: (make-vcenter-markup
(make-vcenter-markup
(cond
((= 0 (length labels))
(string (integer->char (+ fret (char->integer #\a)
((and (<= 0 fret) (< fret (length labels)))
(list-ref labels fret))
(else
(ly:warning "No label for fret ~a (~a on string ~a);
only ~a fret labels provided"
fret pitch string-number (length labels))
".")
http://codereview.appspot.com/164063/diff/5001/5010#newcode414
scm/translation-functions.scm:414: (make-vcenter-markup
(make-vcenter-markup
(format
"~a"
(- (ly:pitch-semitones pitch)
(list-ref tuning
;; remove 1 because list index starts at 0
;;and guitar string at 1.
(1- string-number))
http://codereview.appspot.com/164063/diff/5001/5010#newcode432
scm/translation-functions.scm:432: (make-vcenter-markup
(make-vcenter-markup
(let ((fret (- (ly:pitch-semitones pitch)
(list-ref tuning (1- string-number)
(number->string (cond
((and (> fret 0) (= string-number 5))
(+ fret 5))
(else fret)))
http://codereview.appspot.com/164063
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Try to fix ties in midi. (issue174080)
Hi Reinhold,
This looks OK, but I don't think you need to use a list any more.
Cheers,
Neil
http://codereview.appspot.com/174080/diff/1003/1004
File lily/tie-performer.cc (right):
http://codereview.appspot.com/174080/diff/1003/1004#newcode34
lily/tie-performer.cc:34: Head_audio_event_tuple () { }
{}
http://codereview.appspot.com/174080/diff/1003/1004#newcode46
lily/tie-performer.cc:46: // We don't really need a list or deque here.
A vector would suffice. However,
Remove all this?
Since the error was caused by a naming conflict for the struct, you can
use a vector now, though it's less convenient for removing the tied
heads.
http://codereview.appspot.com/174080/diff/1003/1004#newcode89
lily/tie-performer.cc:89: // for each tied note, store the info and its
end moment, so we can
trailing space
http://codereview.appspot.com/174080/diff/1003/1004#newcode90
lily/tie-performer.cc:90: // later on check whether (1) the note is
still ongoing and (2) how
trailing space
http://codereview.appspot.com/174080/diff/1003/1004#newcode103
lily/tie-performer.cc:103: for ( it = heads_to_tie_.begin() ; (!found)
&& (it != heads_to_tie_.end()); it++ )
indentation
for (it = heads_to_tie_.begin ();
!found && (it != heads_to_tie_.end ());
it++;)
http://codereview.appspot.com/174080/diff/1003/1004#newcode133
lily/tie-performer.cc:133: class end_moment_passed
indentation:
{
protected:
Moment now;
etc.
http://codereview.appspot.com/174080/diff/1003/1004#newcode139
lily/tie-performer.cc:139: bool operator() (const
Head_audio_event_tuple& value) {return (value.end_moment_ <= now); }
bool operator() (const Head_audio_event_tuple &value) {
return (value.end_moment_ <= now);
}
http://codereview.appspot.com/174080/diff/1003/1004#newcode155
lily/tie-performer.cc:155: heads_to_tie_.splice (heads_to_tie_.end(),
now_heads_);
heads_to_tie_.end ()
http://codereview.appspot.com/174080/diff/1003/1004#newcode157
lily/tie-performer.cc:157: heads_to_tie_.splice (heads_to_tie_.end(),
now_tied_heads_);
heads_to_tie_.end ()
http://codereview.appspot.com/174080
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
Hi Han-Wen, Le dimanche 13 décembre 2009 à 13:55 -0200, Han-Wen Nienhuys a écrit : > Oh wait - there is one thing I did not think about: snippets may be > shared by different documents, so if you use make -jX it is > conceivable that make invokes two separate lilypond processes that > have non-empty intersection of their arguments. I don't understand this. I made sure that no simultaneous lilypond-book instances can run simultaneously (unless you make run several instances of 'make doc' simultaneously in the same build tree) a bit more than one year ago, and AFAICT this still works. If it doesn't in any case, I expect a report. > For now, the easy fix is to use -j1 with CPU_COUNT for building the docs. If the make trick I mentioned above works, then the problem is not with -j make flag but with CPU_COUNT greater than one, which tells lilypond-book to run as many lilypond instances (I'm sure you know this, this is only to make it clear). > A more elaborate solution would be either some kind of locking, or to > check whether the .ps / .pdf exists before actually processing the > .ly; the latter is still suscepitible to races, though, but a check > could make the opportunity window smaller. I hope we can figure out a simpler solution, like lengthening the hashes, and/or even better really avoiding processing the same snippet twice (if it ever happens). > A last solution would be to unshare the snippet database, but that > would mean a lot of double processing and extra disk usage, because > every translation would have to do 90% of the snippets all over again, > and store them separately. Gosh, our docs are already generous enough with disk usage :-) Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make check' overworks one core on my Core2 quad
Le dimanche 13 décembre 2009 à 16:13 -0200, Han-Wen Nienhuys a écrit : > The lock could just be per file, using file system locks (which are > simple to use and efficient). Probably ly:parse-file should just lock > and unlock the file while processing it. This may be the best solution if we fail at sorting this issue in lilypond-book, where IMO all the causes of this issue are. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Don't use __attribute__ ((pure)) for unsmob
This one makes lilypond build with good old gcc-3.3.5 (which is the
default compiler on OpenBSD). It's probably debatable wether it'll
slow down lilypond runtime and accelerate global warming, so if you
don't like it, let me know; I could also add some #ifdefs (or just
keep the patch file in the OpenBSD port).
Ciao,
Kili
diff --git a/configure.in b/configure.in
index 6253b66..c1cd146 100644
--- a/configure.in
+++ b/configure.in
@@ -90,10 +90,10 @@ AC_MSG_RESULT($NCSB_SOURCE_FILES)
STEPMAKE_PYTHON(REQUIRED, 2.4)
-STEPMAKE_GCC(REQUIRED, 3.4)
+STEPMAKE_GCC(REQUIRED, 3.3.5)
STEPMAKE_CXX(REQUIRED)
-STEPMAKE_GXX(REQUIRED, 3.4)
+STEPMAKE_GXX(REQUIRED, 3.3.5)
STEPMAKE_CXXTEMPLATE
STEPMAKE_STL_DATA_METHOD
STEPMAKE_LIB(REQUIRED)
diff --git a/lily/include/smobs.hh b/lily/include/smobs.hh
index 27f9ff4..8b8e4c3 100644
--- a/lily/include/smobs.hh
+++ b/lily/include/smobs.hh
@@ -114,7 +114,7 @@
static int print_smob (SCM s, SCM p, scm_print_state*); \
public: \
static SCM equal_p (SCM a, SCM b); \
- static CL *unsmob (SCM s) __attribute__((pure)) \
+ static CL *unsmob (SCM s)\
{\
if (SCM_NIMP (s) && SCM_CELL_TYPE (s) == smob_tag_)\
return (CL *) SCM_CELL_WORD_1 (s); \
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: UTF-8 support needs implementing to fix all bidi/rtl/ltr issues
Thanks Patrick. Do you accept AlertPay or Moneybooker payments? With the new fix, can I just wrap a stanza in U+202A .. U+202C to get the desired effect? At some point, when RTL is implemented for the musical notes, I may want to let the Hebrew do the natural thing, and put in some U+202B..U+202C to make the English text stay in sync with it. Ted On Sun, Dec 13, 2009 at 11:15:51AM -0800, Patrick McCarty wrote: On 2009-12-11, Ted Walther wrote: Thank you for filing that bug issue! How are things progressing? Also, can I make a $100 donation in gratitude to the person implementing the fix? Who is the responsible party to send the money to? I think this issue is fixed now. As Valentin noted, please wait until 2.13.10 is released to verify that everything works for you. Looking at your Shema4.ly file again, you should be able to get this working with 2.13.9 or earlier. Try wrapping some of the multi-character Hebrew syllables with U+202D and U+202C; for example, should be rendered left-to-right. You'll see erroneous warnings (that will be fixed in 2.13.10), but the file should compile fine. Thanks, Patrick -- Nothing is true unless it makes you laugh, But you don't understand it until it makes you weep. Name:Ted Walther Phone: 208-310-7032 Skype: tederific Email: t...@reactor-core.org Address: #225 17700 58 Ave, Cloverdale, BC V3S1L6 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Remove event swallower engravers/translators
Hi everybody, While puzzling over the purpose of the method try_music (), I noticed that the only engravers/translators to use this method are the type swallowers/Swallow_engraver/performer. Since this method appears to have been junked when the translator listener macros were introduced for stream events, none of these translators serves any useful purpose. Furthermore, all events are either listened to (in at least one engraver/performer) or explicitly declared as unlistened (e.g., HarmonicEvent), so there's no need to silence them: they no longer generate `event junked' warnings. I've posted a patch on Rietveld which removes the following translators: Note_swallow_translator Rest_swallow_translator Skip_event_swallow_translator String_number_engraver Swallow_engraver Swallow_performer Please review here: http://codereview.appspot.com/174085 Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Try to fix ties in midi. (issue174080)
Reviewers: Neil Puttock,
http://codereview.appspot.com/174080/diff/1003/1004
File lily/tie-performer.cc (right):
http://codereview.appspot.com/174080/diff/1003/1004#newcode46
lily/tie-performer.cc:46: // We don't really need a list or deque here.
A vector would suffice. However,
On 2009/12/13 20:04:09, Neil Puttock wrote:
Since the error was caused by a naming conflict for the struct, you
can use a
vector now, though it's less convenient for removing the tied heads.
Exactly, and for that reason, I now prefer a list. In fact, the new
check removed arbitrary elements from the list, which is less efficient
for vectors. Also, splice is not available for vectors, but vector
joining has to be done manually...
http://codereview.appspot.com/174080/diff/1003/1004#newcode133
lily/tie-performer.cc:133: class end_moment_passed
On 2009/12/13 20:04:09, Neil Puttock wrote:
{
protected:
Sigh, About everthing possible is indented with the style, just these
keywords are not :( Not very consistent.
Okay, will change.
Description:
Fix the memory corruption issues I had by renaming the data structure
(shadowing was causing the corruption!).
Also fix the Issue found by Hu Haipeng that a note ending in one voice
would terminate all ongoing ties in all other notes, since so far the
code never checked whether the starting note of the tie was still going
on.
Also, use the correct moment comparison (remove if the end moment is
lower **or equal** to the moment that has just been processed).
Please review this at http://codereview.appspot.com/174080
Affected files:
M lily/tie-performer.cc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixed MIME for images on tracker
Hello all, here are long-awaited good news for users of the issue tracker: http://code.google.com/p/support/issues/detail?id=1163 -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com No le des el mando a distancia a Microsoft. No utilices Windows 7. http://windows7sins.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Remove event swallower engravers/translators
LGTM On Sun, Dec 13, 2009 at 8:34 PM, Neil Puttock wrote: > Hi everybody, > > While puzzling over the purpose of the method try_music (), I noticed > that the only engravers/translators to use this method are the type > swallowers/Swallow_engraver/performer. Since this method appears to > have been junked when the translator listener macros were introduced > for stream events, none of these translators serves any useful > purpose. Furthermore, all events are either listened to (in at least > one engraver/performer) or explicitly declared as unlistened (e.g., > HarmonicEvent), so there's no need to silence them: they no longer > generate `event junked' warnings. > > I've posted a patch on Rietveld which removes the following translators: > > Note_swallow_translator > Rest_swallow_translator > Skip_event_swallow_translator > String_number_engraver > Swallow_engraver > Swallow_performer > > Please review here: http://codereview.appspot.com/174085 > > Regards, > Neil > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
