Re: Improve HTML output of regression tests (issue 5342042)
http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py File scripts/build/output-distance.py (right): http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode1304 scripts/build/output-distance.py:1304: if len (args) % 2 == 1: why is there a mod here? Surely we just want to check if the length of args is 0 (or maybe 1 depending on how they're counted). As it currently stands, doesn't it print usage whenever there's an odd number of arguments? http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py File scripts/build/output-distance.py (right): http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode1304 scripts/build/output-distance.py:1304: if len (args) % 2 == 1: On 2011/11/07 08:52:52, Graham Percival wrote: why is there a mod here? Surely we just want to check if the length of args is 0 (or maybe 1 depending on how they're counted). As it currently stands, doesn't it print usage whenever there's an odd number of arguments? Uh, yes? See line 1313: the argument list consists of an arbitrary number of _pairs_. http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
On 2011/11/07 09:15:04, dak wrote: Uh, yes? See line 1313: the argument list consists of an arbitrary number of _pairs_. Right - it's comparing (baseline, check) pairs. I didn't introduce the modulo, I just made it explicit which is more legible than relying on Python's interpretation of 0 as False and 1 as True. http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes in chord names formatting (1503, 1572) (issue 4981052)
On 2011/11/07 00:15:48, Graham Percival wrote: On Sun, Nov 06, 2011 at 03:52:15PM +, mailto:adam.spi...@gmail.com wrote: > I've done a corresponding patch for changes.tely but I don't have > permissions to upload it to this issue that's because Janek uploaded the original issue. Could you just make a new one? just ignore the old codereview issue. Uploading a new patch with git-cl, and associate it with issue tracker 1503 or 1572. - Graham Whoops, I forgot that Carl already created a separate issue for the new version of this patch series: http://codereview.appspot.com/5320074 So this one (4981052) should be ignored entirely now, and closed/deleted when Janek gets back. http://codereview.appspot.com/4981052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
Thanks Carl, I've made these changes, and I've also made a corresponding patch for changes.tely, but I don't think I have permission to upload new patch sets for either to this issue since it says "Can't Edit" at the top-left - can you give me permission? (If not, this is yet another reason Rietveld sucks. It all seems way too locked down to me.) In lieu of a patch set, the amended patch series is available here (freshly rebased on master): https://github.com/aspiers/lilypond/commits/jazz http://codereview.appspot.com/5320074/diff/14001/input/regression/chord-additional-pitch-prefix.ly File input/regression/chord-additional-pitch-prefix.ly (right): http://codereview.appspot.com/5320074/diff/14001/input/regression/chord-additional-pitch-prefix.ly#newcode1 input/regression/chord-additional-pitch-prefix.ly:1: \version "2.15.16" On 2011/11/05 14:33:32, Carl wrote: Will need to be adjusted when it's ready to commit. Right now, it should be 2.15.17. Version of new snippets is always one greater than the current release version. Done. http://codereview.appspot.com/5320074/diff/14001/scm/define-context-properties.scm File scm/define-context-properties.scm (right): http://codereview.appspot.com/5320074/diff/14001/scm/define-context-properties.scm#newcode380 scm/define-context-properties.scm:380: (minorChordModifier ,markup? "How should minor chords be formatted On 2011/11/05 14:33:32, Carl wrote: I'd prefer "Markup displayed following the root for a minor chord." Done. http://codereview.appspot.com/5320074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 07, 2011 at 11:56:42AM +, adam.spi...@gmail.com wrote: > Thanks Carl, I've made these changes, and I've also made a corresponding > patch for changes.tely, but I don't think I have permission to upload > new patch sets for either to this issue since it says "Can't Edit" at > the top-left - can you give me permission? I doubt it. Just upload a new issue. > (If not, this is yet another > reason Rietveld sucks. It all seems way too locked down to me.) It's not build for collaborate patch editing. The idea is that you have a patch, you upload it. Make a few small modifications, go ahead and upload it to the same rietveld number... but anything major and you should just make a new rietveld number. Numbers are cheap, after all. Note that problems like this are fairly rare. If we had an active "frog meister", he'd be taking care rieveld for any inexperienced contributors. And experienced developers like you would be directed to git-cl, so nobody would have uploaded any patches for you anyway. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Added new node for Custom Footnotes (issue 5315053)
"m...@apollinemike.com" writes: > I guess because we are not indicating a grob i.e. > > c-\autoFootnote #'(1 . -1.25) > > vs > > \autoFootnote #'NoteHead #'(1 . -1.25) > c4 > > Which does the same thing. > > Mike any comment on this? > > > Yup - exactly. The postfix operator only ever works in chords and > will apply to NoteHeads. > { } > > > It seems to infer, now that Graham has phrased it like this, that > note > head grobs in this case are 'assumed' and not needed to be > specified > like a slur or beam grob etc. > > > > It'd be nice if this were more robust so that it could apply to other > things like scripts, but for now, it only works with notes. This > could be a known issue if you'd like. It is not clear to me whether this "known issue" is due to limitations of music functions. Would a changed behavior of music functions help? I still have to tackle music functions inside of chords in order to make the music function set reasonably orthogonal, so if you have suggestions in that area... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 11:56:42AM +, adam.spi...@gmail.com wrote: >> Thanks Carl, I've made these changes, and I've also made a corresponding >> patch for changes.tely, but I don't think I have permission to upload >> new patch sets for either to this issue since it says "Can't Edit" at >> the top-left - can you give me permission? > > I doubt it. Just upload a new issue. So then we would have *three* Rietveld issues tracking the same thing. >> (If not, this is yet another >> reason Rietveld sucks. It all seems way too locked down to me.) > > It's not build for collaborate patch editing. The idea is that > you have a patch, you upload it. Make a few small modifications, > go ahead and upload it to the same rietveld number... but anything > major and you should just make a new rietveld number. Numbers are > cheap, after all. > > Note that problems like this are fairly rare. If we had an active > "frog meister", he'd be taking care rieveld for any inexperienced > contributors. And experienced developers like you would be > directed to git-cl, so nobody would have uploaded any patches for > you anyway. Understood, but I still think this workflow is fundamentally flawed. However I'm aware this is not the time nor place to discuss this further. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Nov 7, 2011, at 5:34 AM, "Adam Spiers" wrote: > On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival > wrote: >> On Mon, Nov 07, 2011 at 11:56:42AM +, adam.spi...@gmail.com wrote: >>> Thanks Carl, I've made these changes, and I've also made a corresponding >>> patch for changes.tely, but I don't think I have permission to upload >>> new patch sets for either to this issue since it says "Can't Edit" at >>> the top-left - can you give me permission? >> >> I doubt it. Just upload a new issue. > > So then we would have *three* Rietveld issues tracking the > same thing. > >>> (If not, this is yet another >>> reason Rietveld sucks. It all seems way too locked down to me.) >> >> It's not build for collaborate patch editing. The idea is that >> you have a patch, you upload it. Make a few small modifications, >> go ahead and upload it to the same rietveld number... but anything >> major and you should just make a new rietveld number. Numbers are >> cheap, after all. >> >> Note that problems like this are fairly rare. If we had an active >> "frog meister", he'd be taking care rieveld for any inexperienced >> contributors. And experienced developers like you would be >> directed to git-cl, so nobody would have uploaded any patches for >> you anyway. > > Understood, but I still think this workflow is fundamentally flawed. > However I'm aware this is not the time nor place to discuss this > further. I'll get the update posted today. For this patch, I'm serving as adam's frog meister since last Thursday. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 07, 2011 at 12:34:15PM +, Adam Spiers wrote: > On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival > wrote: > > I doubt it. Just upload a new issue. > > So then we would have *three* Rietveld issues tracking the > same thing. The google code issue is our pointer. Rietveld is our memory. We have one object in memory (the rietveld issue you're going to upload), and two objects which have been de-referenced (Janek's and Carl's uploads). Our machine has infinite memory (because it's run on google servers, and they have more bandwidth than god, and also more processing power than the NSA [1]). Garbage collection happens whenever Carl and Janek get around to it. Stop wasting time -- both mine and yours -- trying to handle the memory manually. Unless you're writing kernel or DSP code, programmers outgrew that in the 90s. We're not going to lose the de-referenced pointers, so it's not a memory leak. capiche? [1] this is almost certainly false, but it's such a nice pithy quote that I couldn't resist inventing it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 07, 2011 at 12:44:42PM +, Carl Sorensen wrote: > > I'll get the update posted today. For this patch, I'm serving as > adam's frog meister since last Thursday. Adam is a very experienced developer, and he already knows how to use git-cl. He's even patched it! He's not a frog, so he doesn't need a frog meister. Waiting for you to upload stuff adds a completely unnecessary delay and annoyance to the process. With anybody else, your assistance would be extremely valuable and appreciated, but in this case I don't see it adding any value. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 12:34:15PM +, Adam Spiers wrote: >> On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival >> wrote: >> > I doubt it. Just upload a new issue. >> >> So then we would have *three* Rietveld issues tracking the >> same thing. > > The google code issue is our pointer. Rietveld is our memory. We > have one object in memory (the rietveld issue you're going to > upload), and two objects which have been de-referenced (Janek's > and Carl's uploads). > Our machine has infinite memory (because it's run on google > servers, and they have more bandwidth than god, and also more > processing power than the NSA [1]). Garbage collection happens > whenever Carl and Janek get around to it. > > Stop wasting time -- both mine and yours -- trying to handle the > memory manually. Unless you're writing kernel or DSP code, > programmers outgrew that in the 90s. Sure, but it's the de-referencing which worries me for two reasons: 1. These older review issues contain potentially useful history about the review process, so allowing them to be garbage collected doesn't sound safe to me. 2. It's not always clear that they have been de-referenced, which can easily cause confusion. Case in point - I accidentally updated an old issue within the last 24 hours because I forgot a new one had superceded it. And I was directly involved with the creation of both! This could have been avoided by closing the old issue except for Rietveld's inflexible ACL model. I suppose a workaround could be to put a comment at the bottom "THIS ISSUE IS NOW RETIRED, SEE ISSUE 12345". I'll do that from now on. > We're not going to lose the de-referenced pointers, so it's not a > memory leak. Your analogy was working quite nicely until this point, but I don't know what you mean by "de-referenced pointers". I'm guessing you meant "de-referenced objects", but then what would the garbage collection you refer to actually do? > capiche? Almost. It's still an over-complex system though. Ultimately I think it boils down to (a) Rietveld having a lowest common denominator approach to revision control systems rather than properly supporting git/mercurial, and (b) having two sub-par systems (Rietveld and Google Code) when one comprehensive integrated system would be much better (not sure that such a beast exists yet, but github looks pretty damn good these days, maybe also Gerrit). > [1] this is almost certainly false, but it's such a nice pithy > quote that I couldn't resist inventing it. :-) Actually I suspect it's true. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 7, 2011 at 2:13 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 12:44:42PM +, Carl Sorensen wrote: >> I'll get the update posted today. For this patch, I'm serving as >> adam's frog meister since last Thursday. > > Adam is a very experienced developer, and he already knows how to > use git-cl. He's even patched it! He's not a frog, so he doesn't > need a frog meister. > > Waiting for you to upload stuff adds a completely unnecessary > delay and annoyance to the process. With anybody else, your > assistance would be extremely valuable and appreciated, but in > this case I don't see it adding any value. Yeah, thanks a lot Carl for your help so far but it probably is simpler at this stage if I just do a git cl upload into a fresh ticket. Hopefully this time everyone will have run out of ideas for how to improve the patch series and it can be pushed to staging soon :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On Mon, Nov 07, 2011 at 02:44:01PM +, Adam Spiers wrote: > On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival > wrote: > > The google code issue is our pointer. Rietveld is our memory. We > > Sure, but it's the de-referencing which worries me for two reasons: > > 1. These older review issues contain potentially useful history about >the review process, so allowing them to be garbage collected >doesn't sound safe to me. True, although our entire review kind-of sucks when people have large-ish new features. But this is also a fairly rare: we had a race condition between uploading of patches and your knowledge of our development process. Or maybe it's a starving philosopher problem... beginners need a waiter to allocate and pick up forks for them, while developers are encouraged to look around the table and decide which forks to use for themselves. > 2. It's not always clear that they have been de-referenced, which can >easily cause confusion. > I suppose a workaround could >be to put a comment at the bottom "THIS ISSUE IS NOW RETIRED, SEE >ISSUE 12345". I'll do that from now on. We've done stuff like that occasionally. > > We're not going to lose the de-referenced pointers, so it's not a > > memory leak. > > Your analogy was working quite nicely until this point, but I don't > know what you mean by "de-referenced pointers". I'm guessing you > meant "de-referenced objects", oops, yes. > but then what would the garbage > collection you refer to actually do? Since not everybody is using the new git-cl, and since the new git-cl isn't bullet-proof in any case, we tend to lose approximately 5% of our patches. ... I'll pause a moment while you get over your shock. Done? ok, great. The traditional solution is to manually click on people's names, i.e. http://codereview.appspot.com/user/dak and look at all the patches under the "Created by dak". 19 times out of 20, between 20% - 80% of those patches are still actively discussed or being worked on. (yes, that's a large range, but I wanted to keep my 95% confidence interval) Up to 60% of those patches have been pushed and can be "garbage collected" (i.e. dak logs in and clicks the round "x" beside the patch), and up to 30% of those patches were forgotten about. A few reminders, a quick round of reviewing later, that patch can be pushed, and we've got one more bugfix or new feature. The benefit of running garbage collection is to reduce the number of patches that have already been pushed. That should make it easier to spot the forgotten patches. (in practice, of course we run garbage collection and lost-resource finding algorithms at the same time, since that means that we only traverse our list once) There's also patches that people attach to comments on the google code issue tracker. Those are even easier to lose. > > capiche? > > Almost. It's still an over-complex system though. Other than GOP, we haven't put any serious effort into scaling up development. Back in 2009, we had a huge technical debt (lots of regressions blocking a stable release). It took over a year of dedicated work just to reach the stability of 2.12. We still have tons of technical debt, but at the moment I think our "social debt" is even worse. We don't have a good workflow for dealing with the amount and skills of developers. At the moment we're stumbling forward with hack on top of hack. GOP is an attempt to systematically clear up that social debt, until we get to a level at which we can move back to tackling the technical debt. And somewhere in this mix, we have people clamoring for systematic revamping and committment to our input syntax, i.e. GLISS. I'm actually beginning to think that we should cut GOP short; just institute a few more hacks to keep development rolling forward, then run GLISS for half a year or something to take some of that pressure off. The bottleneck in this whole process is my absolute committment to working for 10 hours a week on lilypond; no more, no less. I've spent multiple weeks working more than 50 hours on lilypond, and that just isn't sensible for my career. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
Only stylistic comments: http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py File scripts/build/output-distance.py (right): http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode8 scripts/build/output-distance.py:8: from cgi import escape Since the style within lilypond's python sources is to import the module into the namespace, it would be nice to keep to that style, e.g. "import cgi" here, and then... http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode462 scripts/build/output-distance.py:462: str = '%s' % escape(str) ...use "cgi.escape (str)" here. The space before the parenthesis is also to keep the consistent style. http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
make doc failure on fresh build tree
The below error was caused by 'make -j2 doc' on a fresh build tree - any ideas? /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/extending.texi The style file: /home/adam/music/software/lilypond.git/Documentation/lily-bib.bst Database file #1: /home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/snippets.texi extract_texi_filenames.py: Processing out-www/extending.texi extract_texi_filenames.py: Processing out-www/snippets.texi Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/extending.texi' (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi' make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map] Error 1 make[2]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build' make: *** [doc-stage-1] Error 2 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
- Original Message - From: "Adam Spiers" To: Sent: Monday, November 07, 2011 5:00 PM Subject: make doc failure on fresh build tree The below error was caused by 'make -j2 doc' on a fresh build tree - any ideas? /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/extending.texi The style file: /home/adam/music/software/lilypond.git/Documentation/lily-bib.bst Database file #1: /home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/snippets.texi extract_texi_filenames.py: Processing out-www/extending.texi extract_texi_filenames.py: Processing out-www/snippets.texi Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/extending.texi' (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi' make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map] Error 1 make[2]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build' make: *** [doc-stage-1] Error 2 Have you run make first? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
Hello, On Mon, Nov 7, 2011 at 5:14 PM, Phil Holmes wrote: > - Original Message - From: "Adam Spiers" > > To: > Sent: Monday, November 07, 2011 5:00 PM > Subject: make doc failure on fresh build tree > > >> The below error was caused by 'make -j2 doc' on a fresh build tree - >> any ideas? >> >> >> /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames >> -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation >> -I /home/adam/music/software/lilypond.git/Documentation -o >> /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps >> out-www/extending.texi >> The style file: >> /home/adam/music/software/lilypond.git/Documentation/lily-bib.bst >> Database file #1: >> >> /home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib >> >> /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames >> -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation >> -I /home/adam/music/software/lilypond.git/Documentation -o >> /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps >> out-www/snippets.texi >> extract_texi_filenames.py: Processing out-www/extending.texi >> extract_texi_filenames.py: Processing out-www/snippets.texi >> Traceback (most recent call last): >> File >> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", >> line 304, in >> Traceback (most recent call last): >> File >> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", >> line 304, in >> (lang_suffix, sections) = extract_sections (filename) >> File >> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", >> line 142, in extract_sections >> f = open (filename, 'r') >> IOError: [Errno 2] No such file or directory: 'out-www/extending.texi' >> (lang_suffix, sections) = extract_sections (filename) >> File >> "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", >> line 142, in extract_sections >> f = open (filename, 'r') >> IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi' >> make[2]: *** >> [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map] >> Error 1 >> make[2]: *** Waiting for unfinished jobs >> make[2]: *** >> [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map] >> Error 1 >> make[2]: Leaving directory >> `/home/adam/.GIT/3rd-party/lilypond/build/Documentation' >> make[1]: *** [WWW-1] Error 2 >> make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build' >> make: *** [doc-stage-1] Error 2 > > > Have you run make first? > and if you have - I've noticed that since I last did a make doc there have been some translation merges, so what I do is roll back git to before they were added and at least see if you can make doc there The last known good commit that I did a full make doc on was 4bc910c81829ce9ae0a8c44d339bcdcf12d03802 about 2 days ago. regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)
On 2011/11/06 21:30:18, adam.spiers wrote: I disagree - there is no way to be sure that the cause of the StopIteration really was the user failing to run make test-baseline first. For example he could have run it but then something else accidentally (or deliberately) deleted those directories. That's why I deliberately phrased it as a question - it's intended to prompt the user into switching their brain into diagnostics mode. If they choose to ignore the warnings, well, that's their problem :-) Hmmm... If you're giving a warning, just state the facts, making it a question is bad "headology" as they may interpret it as *you* being unsure of what you're reporting. It's a detail, and doesn't need to be a deal-breaker. You're right, though, if they can't RTFW (Read The Finely-crafted Warning (:==:)), they deserve everything they get. Having the diagnostic LGTM. Ian http://codereview.appspot.com/5361042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
- Original Message - From: "Peekay Ex" To: "Phil Holmes" ; "Adam Spiers" Cc: Sent: Monday, November 07, 2011 5:26 PM Subject: Re: make doc failure on fresh build tree Hello, On Mon, Nov 7, 2011 at 5:14 PM, Phil Holmes wrote: - Original Message - From: "Adam Spiers" To: Sent: Monday, November 07, 2011 5:00 PM Subject: make doc failure on fresh build tree The below error was caused by 'make -j2 doc' on a fresh build tree - any ideas? /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/extending.texi The style file: /home/adam/music/software/lilypond.git/Documentation/lily-bib.bst Database file #1: /home/adam/music/software/lilypond.git/Documentation/essay/engravingbib.bib /home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames -I ./out-www -I /home/adam/music/software/lilypond.git/Documentation -I /home/adam/music/software/lilypond.git/Documentation -o /home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps out-www/snippets.texi extract_texi_filenames.py: Processing out-www/extending.texi extract_texi_filenames.py: Processing out-www/snippets.texi Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in Traceback (most recent call last): File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 304, in (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/extending.texi' (lang_suffix, sections) = extract_sections (filename) File "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", line 142, in extract_sections f = open (filename, 'r') IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi' make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/extending.xref-map] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [/home/adam/.GIT/3rd-party/lilypond/build/./out-www/xref-maps/snippets.xref-map] Error 1 make[2]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/adam/.GIT/3rd-party/lilypond/build' make: *** [doc-stage-1] Error 2 Have you run make first? and if you have - I've noticed that since I last did a make doc there have been some translation merges, so what I do is roll back git to before they were added and at least see if you can make doc there The last known good commit that I did a full make doc on was 4bc910c81829ce9ae0a8c44d339bcdcf12d03802 about 2 days ago. Latest master makes doc clean on my system. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
On Sun, 06 Nov 2011 23:34:37 -0800, wrote: http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface.cc#newcode96 lily/pure-from-neighbor-interface.cc:96: && (grace == LEFT ? has_grace : !has_grace)) On 2011/11/07 01:25:30, Keith wrote: In fact, why even use a loop over grace-ness if the actions within the loop occur only for one of two passes through ? I'm not sure what you mean...the actions apply for both passes. Well, the condition we are commenting on is inside an if() that protects the only action in the loop over grace. The loop takes action for just the one value of 'grace = (has_grace? LEFT : RIGHT);'. The other statements inside the loop over 'grace' look to be loop-invariants. I realize that do{}while(flip()!=LEFT) is a LilyPond idiom, but in this case it seems more clear to update array element that needs it, without looping over the other case. This is saying "if the closest column is a grace-note-column, include the next-closest column as well." This gets rid of any accidental overlap problems at the expense of potentially adding a little extra vertical space to the page-spacer calculations, but this extra space seems to be so minimal as to not be a problem (not unlike pure heights for beamed stems, which could also slightly overshoot their actual height). I had not realized that the results of the pure-from-neighbor system influence the page-spacing. This is inconvenient. Now I have some idea why there is so much effort to increase the height only as much as needed. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
Please close this issue as it's now superceded by http://codereview.appspot.com/5343050/ - thanks! http://codereview.appspot.com/5320074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)
New version attached. http://codereview.appspot.com/5361042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
New patch set uploaded. http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py File scripts/build/output-distance.py (right): http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode8 scripts/build/output-distance.py:8: from cgi import escape On 2011/11/07 15:53:49, Julien Rioux wrote: Since the style within lilypond's python sources is to import the module into the namespace, it would be nice to keep to that style, e.g. "import cgi" here, and then... Done. http://codereview.appspot.com/5342042/diff/1/scripts/build/output-distance.py#newcode462 scripts/build/output-distance.py:462: str = '%s' % escape(str) On 2011/11/07 15:53:49, Julien Rioux wrote: ...use "cgi.escape (str)" here. The space before the parenthesis is also to keep the consistent style. Done. http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
On Mon, Nov 07, 2011 at 05:00:23PM +, Adam Spiers wrote: > extract_texi_filenames.py: Processing out-www/snippets.texi > Traceback (most recent call last): > File > "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", > line 304, in > Traceback (most recent call last): > File > "/home/adam/.GIT/3rd-party/lilypond/build/scripts/build/out/extract_texi_filenames", I've honestly never seen that kind of a warning. > IOError: [Errno 2] No such file or directory: 'out-www/snippets.texi' hmm. First, it's possible that a change to a GNUmakefile could require you to re-run autogen.sh and configure. Second, it's just possible that your disk partition is out of space. (I lost half a day last week trying to track down an apparent bug in imagemagick that just turned out to be my /tmp being full) Failing either of these, I guess we're into git bisect time, which of course sucks for doc-building if you're not Phil or James. I know that Phil can build the docs, but hopefully James' computer will fail in this same way? (assuming it's not the autogen issue) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
On 7 November 2011 19:32, Graham Percival wrote: > Failing either of these, I guess we're into git bisect time, which > of course sucks for doc-building if you're not Phil or James. I > know that Phil can build the docs, but hopefully James' computer > will fail in this same way? I've just finished building the docs without incident. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
On Nov 7, 2011, at 10:46 AM, Keith OHara wrote: > >> This is saying "if the closest column is a grace-note-column, include >> the next-closest column as well." This gets rid of any accidental >> overlap problems at the expense of potentially adding a little extra >> vertical space to the page-spacer calculations, but this extra space >> seems to be so minimal as to not be a problem (not unlike pure heights >> for beamed stems, which could also slightly overshoot their actual >> height). > > I had not realized that the results of the pure-from-neighbor system > influence the page-spacing. This is inconvenient. Now I have some idea why > there is so much effort to increase the height only as much as needed. > I misspoke - in this case, it does not. But it does potentially add unwanted horizontal space. All pure heights influence page-spacing. Try: \relative c' { \override Staff . BarLine #'Y-extent = #(ly:make-unpure-pure-container '(-100 . 10) '(-2 . 2)) \repeat unfold 52 { a b c d } } extra-spacing-height, which is what this current patch adds, has no influence on vertical spacing. But there is so much effort to increase the height as needed for the following reason. CASE 1 \new GrandStaff << \new Staff \relative c { \override Staff . BarLine #'extra-spacing-height = #'(-1 . 1) \override TextScript #'extra-spacing-width = ##f \repeat unfold 52 { dis4 dis dis dis^"foo bar" } } \new Staff \repeat unfold 52 R1 >> Build this with current master and you'll see the span bar problem fixed but the text script elongating the measure. CASE TWO \new GrandStaff << \new Staff \relative c { \override TextScript #'extra-spacing-width = ##f \repeat unfold 52 { dis4 dis dis dis^"foo bar" } } \new Staff \repeat unfold 52 R1 >> Build this with the most current version of my patch and the text script won't elongate the measure (it did with older versions of my patch, but your comments made me realize a flaw in the way the interface worked, so thank you!). In a future patch, I can imagine the creation of a new grob, SpacingStub, that replaces extra spacing height. Two would be attached to every grob, and they would allow for more fine-tuned break alignment. For example, to achieve accidentals that don't cross over barlines but are allowed to get snug like the examples you added to the tracker, the SpacingStub could have a different spacing-alist than BarLine to allow this to happen. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
On Mon, Nov 7, 2011 at 7:34 PM, Neil Puttock wrote: > On 7 November 2011 19:32, Graham Percival wrote: > >> Failing either of these, I guess we're into git bisect time, which >> of course sucks for doc-building if you're not Phil or James. I >> know that Phil can build the docs, but hopefully James' computer >> will fail in this same way? > > I've just finished building the docs without incident. I ran it again without -j2 and it completed fine. *shrug* ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
I am not in favor of the tab-to-space change in scm/chord-ignatzek-names.scm, since we don't yet have agreement on removing tabs from .scm files, AFAICS. However, if nobody else is worried about it, I won't complain. I'd prefer to have the tabs gone. And if we can do it through the backdoor, I'm OK with it. Thanks, Carl http://codereview.appspot.com/5343050/diff/1/Documentation/changes.tely File Documentation/changes.tely (right): http://codereview.appspot.com/5343050/diff/1/Documentation/changes.tely#newcode64 Documentation/changes.tely:64: Support for jazz-like chords has been improved: Lydian and altered Perhaps change "chords" to "chord-naming" in this line. http://codereview.appspot.com/5343050/diff/1/input/regression/chord-additional-pitch-prefix.ly File input/regression/chord-additional-pitch-prefix.ly (right): http://codereview.appspot.com/5343050/diff/1/input/regression/chord-additional-pitch-prefix.ly#newcode4 input/regression/chord-additional-pitch-prefix.ly:4: @code{additionalPitchPrefix}." We may not want to have the syntax in the texidoc. We try to avoid "talking through the code" in the NR; I think it's probably a good idea to keep the same policy in the regression tests. http://codereview.appspot.com/5343050/diff/1/scm/chord-ignatzek-names.scm File scm/chord-ignatzek-names.scm (right): http://codereview.appspot.com/5343050/diff/1/scm/chord-ignatzek-names.scm#newcode47 scm/chord-ignatzek-names.scm:47: (car ps) I don't think we should have the tab-to-space conversion in .scm files, because we don't have an agreement on removing tabs from .scm files, AFAICS. I removed this change from your branch when I posted my review set. If others are happy with it, given the time already spend on getting this patch approved, I won't object. http://codereview.appspot.com/5343050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
Passes make but two reg test diffs - see http://code.google.com/p/lilypond/issues/detail?id=1503#c32 James http://codereview.appspot.com/5343050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: avoid cryptic StopIteration failure from make when 'make check' is run before 'make test-baseline' (issue 5361042)
Passes Make and no reg test diffs. James http://codereview.appspot.com/5361042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve HTML output of regression tests (issue 5342042)
passes make and no reg test diffs. james http://codereview.appspot.com/5342042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
Passes make but lots of reg test diffs as usual http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-7-Nov-2011-td4962666.html Jame http://codereview.appspot.com/5323062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com wrote: > I am not in favor of the tab-to-space change in > scm/chord-ignatzek-names.scm, since we don't yet have agreement on > removing tabs from .scm files, AFAICS. True, but I assume that other parts of the patch set depend on this, and high-quality work, so I vote for turning a blind eye to this change and accepting the patch set. > We may not want to have the syntax in the texidoc. We try to avoid > "talking through the code" in the NR; I think it's probably a good idea > to keep the same policy in the regression tests. We have either an official or semi-official policy that developers can do whatever the mao they want in the regression tests. They're not documentation, no user should ever see them, so as long as it's clear what is being tested and what the output should look like (if there's doubt), it's not worth fussing about their texidocs. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
On Mon, Nov 7, 2011 at 9:13 PM, Graham Percival wrote: > On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com wrote: >> I am not in favor of the tab-to-space change in >> scm/chord-ignatzek-names.scm, since we don't yet have agreement on >> removing tabs from .scm files, AFAICS. > > True, but I assume that other parts of the patch set depend on > this, and high-quality work, so I vote for turning a blind eye to > this change and accepting the patch set. Thanks - I tried removing it and rebasing, but it was more work than I have time for. I'm already about 1000% over budget on all this. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 11 -- beamlet points in wrong direction on tuplet (issue 4941041)
New patchset uploaded http://codereview.appspot.com/4941041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
Adam Spiers writes: > On Mon, Nov 7, 2011 at 9:13 PM, Graham Percival > wrote: >> On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com wrote: >>> I am not in favor of the tab-to-space change in >>> scm/chord-ignatzek-names.scm, since we don't yet have agreement on >>> removing tabs from .scm files, AFAICS. >> >> True, but I assume that other parts of the patch set depend on >> this, and high-quality work, so I vote for turning a blind eye to >> this change and accepting the patch set. > > Thanks - I tried removing it and rebasing, but it was more work than > I have time for. Which is _exactly_ the reason why gratuitous spacing changes are a bad idea. Because it makes rebasing more work than people have time for. In this case, the damage is already done, so there seems little point in investing the effort for trying to get back again. > I'm already about 1000% over budget on all this. Welcome to the club. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
On Mon, Nov 7, 2011 at 10:11 PM, David Kastrup wrote: > In this case, the damage is already done, so there seems little point in > investing the effort for trying to get back again. Especially considering my first patch submission did *not* have gratuitous whitespace changes, and I only put them in after I was asked to during a review. It's probably cost me more time than it has anyone else. Let's not waste any more time on the matter now. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 11 -- beamlet points in wrong direction on tuplet (issue 4941041)
Make passes but make check fails on \sourcefilename "/home/jlowe/lilypond-git/input/regression/beamlet-point-toward-beat.ly" \sourcefileline 0 \version "2.15.17" \header { \texidoc = " Beamlets should point in the direction of the beat to which they belong. " } \relative c' { b16. b32 b32 b16. b16.[ b32 b b b b16.] } James http://codereview.appspot.com/4941041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 11 -- beamlet points in wrong direction on tuplet (issue 4941041)
New patch set http://codereview.appspot.com/4941041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
On 11/7/11 2:48 PM, "Adam Spiers" wrote: >On Mon, Nov 7, 2011 at 9:13 PM, Graham Percival > wrote: >> On Mon, Nov 07, 2011 at 08:13:46PM +, carl.d.soren...@gmail.com >>wrote: >>> I am not in favor of the tab-to-space change in >>> scm/chord-ignatzek-names.scm, since we don't yet have agreement on >>> removing tabs from .scm files, AFAICS. >> >> True, but I assume that other parts of the patch set depend on >> this, and high-quality work, so I vote for turning a blind eye to >> this change and accepting the patch set. > >Thanks - I tried removing it and rebasing, but it was more work than >I have time for. I'm already about 1000% over budget on all this. As I mentioned earlier, I agree with this decision. However, I should mention that I rebased things to take that whitespace change out, and if Graham had let me finish serving as frog-meister for this patch (I got the assignment to do so last Thursday), we'd have a patch set up without the whitespace changes. I don't want to revisit any of these decisions for this time -- let's just get the bugfix in the maoing source tree. But I *am* a bit frustrated that my work was all in vain. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Internals questions - \include and LilyPond assignments
On Sun, Nov 6, 2011 at 5:11 PM, Ian Hulin wrote: > Hi all, > > A couple of questions in case someone with more internal code-fu than me > can save me rummaging around in the guts of the C++ code, just so I can > get a handle on some behaviour I've noted trying to get LilyPond to fire > up with Guile V2.0.3. > > 1. Does processing a file via \include cause a new LilyPond scope -> > generating a new "anonymous" Guile module for that file? no. > 2. How and when does a LilyPond assignment > blah = { lily-statements... } > get compiled down in to a scheme (define blah )? > Guile V2 complains about stuff like > ignatzekExceptionMusic = { blah blah2 blah3} this happens when the parser decides it can reduce the input to an assignment, assignment: assignment_id '=' identifier_init { PARSER->lexer_->set_identifier ($1, $3); } the actual work is in the function scm_module_define (mod, sym, val); there is some trickiness with ordering. The parser may do look ahead up to the #( .. ) you have before it decide to do the reduction. In doubt, you can force it by inserting a dummy scheme statement in between both assignments. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes to jazz chord displays (issue 5320074)
On 11-11-07 12:08 PM, adam.spi...@gmail.com wrote: Please close this issue as it's now superceded by http://codereview.appspot.com/5343050/ - thanks! http://codereview.appspot.com/5320074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Adam, you are the creator of the Rietveld issue, so you need to log on and edit the issue. You should see a "closed" button and be sure to update the issue. I share your frustration with the pair of band-aids we are using, BTW! Cheers, Colin Campbell Rank and file patch nanny -- 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: Internals questions - \include and LilyPond assignments
Han-Wen Nienhuys writes: > On Sun, Nov 6, 2011 at 5:11 PM, Ian Hulin wrote: >> Hi all, >> >> A couple of questions in case someone with more internal code-fu than me >> can save me rummaging around in the guts of the C++ code, just so I can >> get a handle on some behaviour I've noted trying to get LilyPond to fire >> up with Guile V2.0.3. >> >> 1. Does processing a file via \include cause a new LilyPond scope -> >> generating a new "anonymous" Guile module for that file? > > no. > >> 2. How and when does a LilyPond assignment >> blah = { lily-statements... } >> get compiled down in to a scheme (define blah )? >> Guile V2 complains about stuff like >> ignatzekExceptionMusic = { blah blah2 blah3} > > this happens when the parser decides it can reduce the input to an assignment, > > assignment: > assignment_id '=' identifier_init { > PARSER->lexer_->set_identifier ($1, $3); > } > > > the actual work is in the function > > scm_module_define (mod, sym, val); > > there is some trickiness with ordering. The parser may do look ahead > up to the #( .. ) you have before it decide to do the reduction. > > In doubt, you can force it by inserting a dummy scheme statement in > between both assignments. I currently have a patch in review (will submit a regtest-passing version in the next hour) that makes $... take over the job of #(ly:export ...) in general instead just half-bakedly in #{ ... #}. Once ly:export is retired, # can be made to just _read_ a Scheme expression in the lexer, and let the _parser_ evaluate it when it is used (this is not possible while ly:export is functional). That should seriously decrease the potential for Premature Evaluation. Until then, #(begin) is a good interjaculation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The value of LilyPond, according to Ohloh
I think the number is way off. AFAICS at http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all stable branches as separate. Last time I looked lilypond was around 100k lines of code (a quick look says it 200k now; I suspect the GNU headers as a cause). 390 man years looks exaggeratedl, since I wrote most of it (at least before 2007), and it took me much less than 300 years. Realistically, lilypond may represent 20-40 man years, considering I must have put in well over 10 personally. On Sat, Nov 5, 2011 at 12:01 AM, Carl Sorensen wrote: > So I was googling for yaffut to see what I could learn about it, and I > found that ohloh has a rating system for the projects in its database. > > I looked up LilyPond, and found it: > > http://www.ohloh.net/p/lilypond > > > The factoids about it are very complimentary. > > One interesting point -- the estimated value of LilyPond is $16,000,000 > > Over 1 million lines of code. > > The estimated developer time is 309 man years > > LilyPond is a *real* software project. > > Just an interesting fact. > -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
On 11-11-07 12:46 PM, Adam Spiers wrote: On Mon, Nov 7, 2011 at 7:34 PM, Neil Puttock wrote: On 7 November 2011 19:32, Graham Percival wrote: Failing either of these, I guess we're into git bisect time, which of course sucks for doc-building if you're not Phil or James. I know that Phil can build the docs, but hopefully James' computer will fail in this same way? I've just finished building the docs without incident. I ran it again without -j2 and it completed fine. *shrug* ___ ISTR there's a long standing problem with forking make doc, although the initial make to [roduce the binaries seems not to mind. 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: The value of LilyPond, according to Ohloh
Han-Wen Nienhuys writes: > I think the number is way off. AFAICS at > http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all > stable branches as separate. > > Last time I looked lilypond was around 100k lines of code (a quick > look says it 200k now; I suspect the GNU headers as a cause). 390 man > years looks exaggeratedl, since I wrote most of it (at least before > 2007), and it took me much less than 300 years. Your output is likely not average for the industry. Writing and committing a half-hour change took you just half an hour instead of five hours of red tape from you and three hours of red tape each from three other persons. We are getting there, but that's not what you have been working with. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The value of LilyPond, according to Ohloh
On Mon, Nov 7, 2011 at 11:38 PM, David Kastrup wrote: >> I think the number is way off. AFAICS at >> http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all >> stable branches as separate. >> >> Last time I looked lilypond was around 100k lines of code (a quick >> look says it 200k now; I suspect the GNU headers as a cause). 390 man >> years looks exaggeratedl, since I wrote most of it (at least before >> 2007), and it took me much less than 300 years. > > Your output is likely not average for the industry. Writing and > committing a half-hour change took you just half an hour instead of five > hours of red tape from you and three hours of red tape each from three > other persons. We are getting there, but that's not what you have been > working with. In the early days (the "good old days") we didn't have a regression test (I checked in the first version in may 2006). Beyond all kinds of interesting stuff, I also committed several half hour changes that had me staring at gdb for hours (and sometimes days) on end. They were partly to blame on the nightly sessions with Jan that involved drinking whiskey besides hacking, put some of them were really hard, and I today I wonder how I ever kept things running without having any sort of testing framework. Let's not forget that some of the red tape we have today is there for good reason. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The value of LilyPond, according to Ohloh
Han-Wen Nienhuys writes: > On Mon, Nov 7, 2011 at 11:38 PM, David Kastrup wrote: >>> I think the number is way off. AFAICS at >>> http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all >>> stable branches as separate. >>> >>> Last time I looked lilypond was around 100k lines of code (a quick >>> look says it 200k now; I suspect the GNU headers as a cause). 390 man >>> years looks exaggeratedl, since I wrote most of it (at least before >>> 2007), and it took me much less than 300 years. >> >> Your output is likely not average for the industry. Writing and >> committing a half-hour change took you just half an hour instead of five >> hours of red tape from you and three hours of red tape each from three >> other persons. We are getting there, but that's not what you have been >> working with. > > Let's not forget that some of the red tape we have today is there for > good reason. There are always good reasons. One reason is that single persons are not a dependable resource. As to "most of it": in the number of commits (naturally misleading as changes tend to be larger in the starting stage) it is about a third: git shortlog -ns|awk '{n+=$1;if(NR<20)print};END{print n}' 6381 Han-Wen Nienhuys 3092 Graham Percival 2474 Jan Nieuwenhuizen 1270 John Mandereau 1224 Francisco Vila 910 Reinhold Kainhofer 782 Joe Neeman 574 Werner Lemberg 526 Neil Puttock 500 Trevor Daniels 488 Carl D. Sorensen 415 Heikki Junes 409 Till Rettig 379 Jean-Charles Malahieude 352 Patrick McCarty 286 Mats Bengtsson 172 Valentin Villenave 170 David Kastrup 166 James Lowe 22101 I have to admit that I was surprised at the rather small contribution I have made according to that metric. Of course my own vanity wants to ascribe some of that to red tape. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The value of LilyPond, according to Ohloh
Han-Wen Nienhuys writes: > On Mon, Nov 7, 2011 at 11:38 PM, David Kastrup wrote: >>> I think the number is way off. AFAICS at >>> http://www.ohloh.net/p/lilypond/enlistments?page=2, they counted all >>> stable branches as separate. >>> >>> Last time I looked lilypond was around 100k lines of code (a quick >>> look says it 200k now; I suspect the GNU headers as a cause). 390 man >>> years looks exaggeratedl, since I wrote most of it (at least before >>> 2007), and it took me much less than 300 years. >> >> Your output is likely not average for the industry. Writing and >> committing a half-hour change took you just half an hour instead of five >> hours of red tape from you and three hours of red tape each from three >> other persons. We are getting there, but that's not what you have been >> working with. > > In the early days (the "good old days") we didn't have a regression > test (I checked in the first version in may 2006). Beyond all kinds of > interesting stuff, I also committed several half hour changes that had > me staring at gdb for hours (and sometimes days) on end. I committed several changes recently that had me staring at bison output tables for weeks. Call me stupid, but argument scanning in the grammar is specified from back to front while actually done front to back. Which means that you need to invert time and causality when thinking about the rules. I think there was some jocular programming language that had COMEFROM instead of GOTO. Intercal or something? Except that this is not a joke, and I don't think there is a better way. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Let #{ ... #} pass its $ handling to environment cloning (issue 5340053)
Reviewers: , Message: I am replacing this review by a new one. Description: Let #{ ... #} pass its $ handling to environment cloning Permit ly:parser-clone to receive an environment lexer.ll: add $ for immediate export. Please review this at http://codereview.appspot.com/5340053/ Affected files: M lily/include/lily-parser.hh M lily/lexer.ll M lily/lily-parser-scheme.cc M lily/lily-parser.cc M lily/parse-scm.cc M scm/parser-ly-from-scheme.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
On Mon, 07 Nov 2011 11:36:09 -0800, m...@apollinemike.com wrote: On Nov 7, 2011, at 10:46 AM, Keith OHara wrote: I had not realized that the results of the pure-from-neighbor system influence the page-spacing. I misspoke - in this case, it does not. But it does potentially add unwanted horizontal space. \new GrandStaff << \new Staff \relative c { \override TextScript #'extra-spacing-width = ##f \repeat unfold 52 { dis4 dis dis dis^"foo bar" } } \new Staff \repeat unfold 52 R1 >> Build this with the most current version of my patch and the text script won't elongate the measure (it did with older versions of my patch, but your comments made me realize a flaw in the way the interface worked, so thank you!). Now, if someone overrides TextScript's 'extra-spacing-width like this, he probably /intends/ to change the horizontal spacing. Do you plan to remove 'extra-spacing-width in the near future? The concept of what constitutes a "neighbor" is getting complicated. Horizontal spacing will change based on complicated details which will surprise me when I forget how it works (in about a week) : \new GrandStaff << \new Staff \repeat unfold 5 R1 \new Staff { \override TextScript #'extra-spacing-width = ##f dis4 dis dis dis^"sliding-over" | dis4 dis dis dis^"sliding-over-not" | R1*2 f''1 } >> ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
Mike, Now that we understand that we can adjust 'extra-spacing-height for note-spacing, without messing up line-breaking or page-spacing, let's revisit the big picture. On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com wrote: On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote: What is the overall plan for the new engravers? Currently, LilyPond has no mechanism to calculate the Y-extents of Itemsin a relative way. You can't say "make the height of grob X such thatit is always Y larger than that of grob Z." So far, so good. This is necessary for grobs (like barlines) that need to block certain grobs that fall above and below them. Idem for Staves, idem for time signatures.Currently, LilyPond accomplishes this through hardcoded values (check out the extra-spacing-height for TimeSignature, for example), which potentially catches unwanted fuzz (a text script with '(0 . 0) for extra-spacing-width and low padding will be shifted over numerical time signatures but notcommon time). Well, it depends on /why/ we need the blocking. If the goal is to avoid collisions, we use the extents plus extra-spacing-* For horizontal spacing based on the meaning of the grobs, we have the 'space-alist. Grobs that need prominence relative to their non-colliding neighbors can benefit from your pure-from-neighbor-interface. Span Bars need space to avoid collisions. Separating SpanBars into segments, as you did for issue 910, seems wise because in the case of issue 910 they can print as segments. Using the "as tall as my neighbor" concept for SpanBarStubs, seems unwise. \new PianoStaff << \new Staff { R1*5 } \new Staff { e'1 | b'16 4.. r2 | e''16 4.. r2 | 2 r2 | 2 r2 } >> In general, I'd like to see the Pure_from_neighbor_engraver take care of theextra spacing heights for all grobs that are ordered by break alignments, asall of them should prevent overhang. This patch already does a good chunk of work for that. But that is issue 1955.<>___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
On Nov 7, 2011, at 8:19 PM, Keith OHara wrote: > Mike, > Now that we understand that we can adjust 'extra-spacing-height > for note-spacing, without messing up line-breaking or page-spacing, > let's revisit the big picture. > > On Fri, 04 Nov 2011 00:12:01 -0700, m...@apollinemike.com > wrote: > >> On Nov 3, 2011, at 11:39 PM, k-ohara5...@oco.net wrote: >> >>> What is the overall plan for the new engravers? >>> >> Currently, LilyPond has no mechanism to calculate the Y-extents of Itemsin a >> relative way. You can't say "make the height of grob X such thatit is >> always Y larger than that of grob Z." > > So far, so good. > >> This is necessary for grobs (like barlines) that need to block certain grobs >> that fall above and below them. Idem for Staves, idem for time >> signatures.Currently, LilyPond accomplishes this through hardcoded values >> (check out >> the extra-spacing-height for TimeSignature, for example), which potentially >> catches unwanted fuzz (a text script with '(0 . 0) for extra-spacing-width >> and low padding will be shifted over numerical time signatures but notcommon >> time). > > Well, it depends on /why/ we need the blocking. > If the goal is to avoid collisions, we use the extents plus extra-spacing-* > For horizontal spacing based on the meaning of the grobs, we have the > 'space-alist. > Grobs that need prominence relative to their non-colliding neighbors can > benefit > from your pure-from-neighbor-interface. > > Span Bars need space to avoid collisions. > > Separating SpanBars into segments, as you did for issue 910, seems wise > because > in the case of issue 910 they can print as segments. > I'm OK with getting rid of all of this pure-from-neighbor and span-bar-stub stuff and just create several SpanBars instead of one SpanBar with gaps in its stencil. I can reuse code I've already written, so it's not that bad. But, my question is: was it ever a good idea to have the pure heights of span bars calculated the way they were? SpanBars are inherently cross staff, so how can they estimate a correct Y-extent without triggering a VerticalAlignment? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
On Mon, 07 Nov 2011 20:51:14 -0800, m...@apollinemike.com wrote: I'm OK with getting rid of all of this pure-from-neighbor and span-bar-stub stuff and just create several SpanBars instead of one SpanBar with gaps in its stencil. I can reuse code I've already written, so it's not that bad. Would you do it as a revert of 4f49b000 followed by a commit to make a clean fix for issue 910 ? But, my question is: was it ever a good idea to have the pure heights of span bars calculated the way they were? SpanBars are inherently cross staff, so how can they estimate a correct Y-extent without triggering a VerticalAlignment? The correct height for SpanBars during note-spacing would be whatever corresponds to the tentative staff-spacing used during horizontal spacing -- the spacing table for which you recently implemented caching. SpanBars did have that as their Y-extent in 2.14. (But of course they did not have the proper gaps in their skylines, if somebody used 'allow-span-bar=#f) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
Hello, On Tue, Nov 8, 2011 at 1:35 AM, Colin Campbell wrote: > On 11-11-07 12:46 PM, Adam Spiers wrote: >> >> On Mon, Nov 7, 2011 at 7:34 PM, Neil Puttock wrote: >>> >>> On 7 November 2011 19:32, Graham Percival >>> wrote: >>> Failing either of these, I guess we're into git bisect time, which of course sucks for doc-building if you're not Phil or James. I know that Phil can build the docs, but hopefully James' computer will fail in this same way? >>> >>> I've just finished building the docs without incident. >> >> I ran it again without -j2 and it completed fine. *shrug* >> >> ___ >> > > > ISTR there's a long standing problem with forking make doc, although the > initial make to [roduce the binaries seems not to mind. > Yes there is or 'was' I've noticed that in the last few days I have been running make -j7 I have *not* been getting those weird 'authors.texi' type errors or those 'file not found' type problems that 'go away' running make again. Every patch that has applied has passed make with no issues at all. Whereas previously I'd have to run make twice nearly every time. So I wonder if any recent build changes have made the difference. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The value of LilyPond, according to Ohloh
> git shortlog -ns|awk '{n+=$1;if(NR<20)print};END{print n}' > 6381Han-Wen Nienhuys > 3092Graham Percival > 2474Jan Nieuwenhuizen > 1270John Mandereau > 1224Francisco Vila >910Reinhold Kainhofer >782Joe Neeman >574Werner Lemberg >526Neil Puttock >500Trevor Daniels >488Carl D. Sorensen >415Heikki Junes >409Till Rettig >379Jean-Charles Malahieude >352Patrick McCarty >286Mats Bengtsson >172Valentin Villenave >170David Kastrup >166James Lowe > 22101 > > I have to admit that I was surprised at the rather small > contribution I have made according to that metric. Indeed. Regarding my contributions, I wonder exactly the opposite. :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel