Re: Change syntax for woodwind-diagram markup (issue1946043)
carl.d.soren...@gmail.com writes: > On 2010/08/14 19:47:59, Neil Puttock wrote: >> Since these are bound with defaults above, you don't need to use > chain-assoc-get > >> (radius size) > > Done. I forgot about how nifty the new interface is that David made > possible. Actually, the niftiness is due to Nicolas and was there before my changes, but a) restricted to Lilypond-internal markup functions (which the woodwinds now are, so they could already have used this). b) basically undocumented, partly justifiable because the functionality was not user-accessible anyway. And I am not all too sure that b) is much better than previously. I just noticed that the documentation says If the command uses properties from the PROPS arguments, the `#:properties' keyword can be used, to specify which properties are used, and their default values. and there is no mention whatsoever of the property symbols being bound to the respective property in the function body. In short: the documentation would not have helped you remember the niftiness which you forgot. Since it was me that moved the niftiness into user-accessible and thus to-be-documented realms, that is my fault. Sorry. I'll commit a fix soonish. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with 2.13.30?
Patrick McCarty wrote Sunday, August 15, 2010 7:27 AM On Sat, Aug 14, 2010 at 5:23 PM, Patrick McCarty wrote: On Sat, Aug 14, 2010 at 4:10 PM, Trevor Daniels wrote: The mingw binary of 2.13.30 gives the following error under Vista on my system: Running lilypond-book Traceback (most recent call last): File "c:/program files/lilypond/usr/bin/lilypond-book.py", line 86, in ? import book_base as BookBase File "out/book_base.py", line 4, in ? File "out/book_snippets.py", line 9, in ? File "c:\Program Files\LilyPond\usr\lib\python2.4\subprocess.py", line 352, in ? import msvcrt ImportError: No module named msvcrt Lilypond-book returned code 1 Could someone else please try this to see if this is a problem with the release or my system. I can reproduce the problem with Wine, running the following: $ wine python.exe lilypond-book.py I've never tried this before, so I don't know whether or not this worked with 2.11.29 or earlier. One further note: This could be related to Jan's recent changes to the MinGW Python build in GUB. Something related to "msvcrt" was added here: http://github.com/janneke/gub/commit/e3d46689d881045ceb2dbf31d7d4573709f781d8#L1R136 Hhm, looks suspicious, but I'm out of my depth here. Earlier recent GUB releases gave a different problem which I reported to the bug list on 7 July: http://lists.gnu.org/archive/html/bug-lilypond/2010-07/msg00060.html Graham thought this might have been caused by Reinhold's refactoring of lilypond-book. For my LilyPond work since then I've used lilypond-book from 2.13.14, which still works fine. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change syntax for woodwind-diagram markup (issue1946043)
On 8/15/10 2:39 AM, "David Kastrup" wrote: > carl.d.soren...@gmail.com writes: > >> On 2010/08/14 19:47:59, Neil Puttock wrote: >>> Since these are bound with defaults above, you don't need to use >> chain-assoc-get >> >>> (radius size) >> >> Done. I forgot about how nifty the new interface is that David made >> possible. > > Actually, the niftiness is due to Nicolas and was there before my > changes, but > > a) restricted to Lilypond-internal markup functions (which the woodwinds >now are, so they could already have used this). > > b) basically undocumented, partly justifiable because the functionality >was not user-accessible anyway. > > And I am not all too sure that b) is much better than previously. I > just noticed that the documentation says > >If the command uses properties from the PROPS arguments, the > `#:properties' keyword can be used, to specify which properties are > used, and their default values. > > and there is no mention whatsoever of the property symbols being bound > to the respective property in the function body. > > In short: the documentation would not have helped you remember the > niftiness which you forgot. This may be so, but even if the documentation were there I would probably have missed it, because when I first learned user-defined markups, I learned to do the chain-assoc-get from props. And so I just had old habits. > > Since it was me that moved the niftiness into user-accessible and thus > to-be-documented realms, that is my fault. > > Sorry. I'll commit a fix soonish. > I don't see any fault to be assigned. But I do agree that some improved documentation (probably in Extending) would be useful. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with 2.13.30?
Trevor Daniels wrote: > > The mingw binary of 2.13.30 gives the following error > under Vista on my system: > > Running lilypond-book > Traceback (most recent call last): > File "c:/program files/lilypond/usr/bin/lilypond-book.py", line > 86, in ? > import book_base as BookBase > File "out/book_base.py", line 4, in ? > File "out/book_snippets.py", line 9, in ? > File "c:\Program Files\LilyPond\usr\lib\python2.4\subprocess.py", > line 352, in > ? > import msvcrt > ImportError: No module named msvcrt > Lilypond-book returned code 1 > 2.13.23 is fine whereas 2.13.25 + higher have the above messages ( i haven't loaded 2.13.24)! -- View this message in context: http://old.nabble.com/Problem-with-2.13.30--tp29439728p29441287.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR down?
On 14 August 2010 10:35, Phil Holmes wrote: > > I've not been able to access the LSR since Friday. Is it down? It seems, indeed. And according to downforeveryoneorjustme.com it is down for everyone. http://downforeveryoneorjustme.com/http://lsr.dsi.unimi.it/ Cheers, Xavier PS: Cc to Sebastiano Vigna, just in case... -- Xavier Scheuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Half-baked unused features.
Hi, I'm just trying to improve the documentation of define-markup-command and define-markup-command-list. Those commands have some functionality for defining aliases to existing commands. For one thing, I have my doubts that this works properly, for another, it complicates implementation and documentation (it was never documented in lilypond-extending, anyhow). So I am leaning towards throwing it all out as I've checked that "make test-clean && make test" is not affected. I'm making sure that throwing this stuff out is a separate commit from improving the documentation, so it can easily be reverted iff somebody considers it desirable. What is the general stance towards cleanup (of unused dormant stuff never documented for general use) like that as long as it is contained in separate commits and not intermingled with other changes? Should it be wrapped in a full review process? Or is it ok to just do it, and revert it on the slim chance that somebody wants to complete, regress-test, and document the implementation at some point of time? And if somebody wants to do that, would it not be sufficiently easy for him to do the revert in his own repository, and commit everything once it is ready and coherent? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On 8/15/10 6:48 AM, "David Kastrup" wrote: > > > Hi, I'm just trying to improve the documentation of > define-markup-command and define-markup-command-list. Those commands > have some functionality for defining aliases to existing commands. For > one thing, I have my doubts that this works properly, for another, it > complicates implementation and documentation (it was never documented in > lilypond-extending, anyhow). > > So I am leaning towards throwing it all out as I've checked that "make > test-clean && make test" is not affected. > > I'm making sure that throwing this stuff out is a separate commit from > improving the documentation, so it can easily be reverted iff somebody > considers it desirable. > > What is the general stance towards cleanup (of unused dormant stuff > never documented for general use) like that as long as it is contained > in separate commits and not intermingled with other changes? IMO, getting rid of bit-rotted code is always a good idea. > Should it > be wrapped in a full review process? I think so. The full review process for removing old stuff is generally very short and sweet (post the patch, somebody important says OK), so I don't think it hurts a bit to do it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Carl Sorensen writes: > On 8/15/10 6:48 AM, "David Kastrup" wrote: > >> Hi, I'm just trying to improve the documentation of >> define-markup-command and define-markup-command-list. Those commands >> have some functionality for defining aliases to existing commands. For >> one thing, I have my doubts that this works properly, for another, it >> complicates implementation and documentation (it was never documented in >> lilypond-extending, anyhow). >> >> So I am leaning towards throwing it all out as I've checked that "make >> test-clean && make test" is not affected. >> >> I'm making sure that throwing this stuff out is a separate commit from >> improving the documentation, so it can easily be reverted iff somebody >> considers it desirable. >> >> What is the general stance towards cleanup (of unused dormant stuff >> never documented for general use) like that as long as it is contained >> in separate commits and not intermingled with other changes? > > IMO, getting rid of bit-rotted code is always a good idea. > >> Should it >> be wrapped in a full review process? > > I think so. The full review process for removing old stuff is > generally very short and sweet (post the patch, somebody important > says OK), so I don't think it hurts a bit to do it. It only involves creating a separate branch, moving the change there, removing the change from all ongoing development in related areas (and/or postponing work on them until the review process of the bitrot change has come to a close), creating a Rietveld issue, uploading the changes to Rietveld, monitoring all progress on it, repeating a full regtest for any proposed modifications and juggling with merge/cherry-pick while doing the parallel development and so on. So yes, it does hurt in my opinion. And since cleanup like that comes up usually as a side-effect of doing serious work for which one can't sensibly maintain a Rietveld review in parallel (since we are talking about overlapping patches which Rietveld does not handle sanely) but has to wait for the cleanup review to complete in its own time frame, it stops other work in progress, at a rate hardly less than a day per cleanup in the affected area. So I disagree with the "short and sweet" bit because we don't have the infrastructure to do this in parallel with related work on the same code. In particular if that related work is progressing in a branch. So the real question probably is more or less "What balance between developer sanity, project policies, and developer responsibility are we aiming for?", and likely the answer depends on the developer, too. Personally, I lean towards thinking that stuff that is not used within Lilypond, has no user-level documentation and has never been in the regression tests or snippets should be fair game. If only to finally convince the person who actually needs it go to the pain of completing its implementation. Or maybe the question is just "what's it worth to keep David from whining?". -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On 8/15/10 7:39 AM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On 8/15/10 6:48 AM, "David Kastrup" wrote: >> >> >> IMO, getting rid of bit-rotted code is always a good idea. >> >>> Should it >>> be wrapped in a full review process? >> >> I think so. The full review process for removing old stuff is >> generally very short and sweet (post the patch, somebody important >> says OK), so I don't think it hurts a bit to do it. > > It only involves creating a separate branch, moving the change there, > removing the change from all ongoing development in related areas > (and/or postponing work on them until the review process of the bitrot > change has come to a close), creating a Rietveld issue, uploading the > changes to Rietveld, monitoring all progress on it, repeating a full > regtest for any proposed modifications and juggling with > merge/cherry-pick while doing the parallel development and so on. No, you said it was all in one commit. So you have a branch with that commit and you keep rebasing it. It's quite easy to do. And you don't have to eliminate the change from the ongoing development in the related area; if you're confident it's worth eliminating then eliminate it in your development work. And if it's really not used, then removing it will have no effect whatsoever on your downstream stuff. I don't think I've *ever* seen anyone propose modifications in bitrotted stuff to be removed. I think your argument doesn't match with the reality of the situation. > > So yes, it does hurt in my opinion. And since cleanup like that comes > up usually as a side-effect of doing serious work for which one can't > sensibly maintain a Rietveld review in parallel (since we are talking > about overlapping patches which Rietveld does not handle sanely) but has > to wait for the cleanup review to complete in its own time frame, it > stops other work in progress, at a rate hardly less than a day per > cleanup in the affected area. When uploading patches to Rietveld one can choose whatever commit is desired as the reference for the upload, so I think that overlapping patches can be handled without too much difficulty. > > So I disagree with the "short and sweet" bit because we don't have the > infrastructure to do this in parallel with related work on the same > code. In particular if that related work is progressing in a branch. > > So the real question probably is more or less "What balance between > developer sanity, project policies, and developer responsibility are we > aiming for?", and likely the answer depends on the developer, too. > Personally, I lean towards thinking that stuff that is not used within > Lilypond, has no user-level documentation and has never been in the > regression tests or snippets should be fair game. If only to finally > convince the person who actually needs it go to the pain of completing > its implementation. I'm not the final arbiter here, but I don't think that we should move to a mode that says "Any developer who wants to can remove code without getting approval." I don't think it's at all unreasonable to ask you to post a patch showing what you intend to remove. > > Or maybe the question is just "what's it worth to keep David from > whining?". I learned long ago (I have 7 children) that you can't stop children from whining. You just have to ignore them when they whine so they can't see any benefit from whining. Otherwise, whining becomes a never-ending tactic. So, if you ask me, the answer would be "can't change anything in response to David's whining." Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On Sun, Aug 15, 2010 at 2:39 PM, David Kastrup wrote: > Carl Sorensen writes: > >>> What is the general stance towards cleanup (of unused dormant stuff >>> never documented for general use) like that as long as it is contained >>> in separate commits and not intermingled with other changes? ?>> >>> Should it >>> be wrapped in a full review process? >> >> I think so. The full review process for removing old stuff is >> generally very short and sweet (post the patch, somebody important >> says OK), so I don't think it hurts a bit to do it. we don't *have* a "full review process" in any meaningful sense of the term. Especially not for "cleaning up" things. As evidence, consider: http://codereview.appspot.com/1724041/show - big initial patch - lots of comments about splitting up the patch into smaller, easily-understood portions - contributor (an unknown person, BTW) does what we ask - NOBODY bloody looks at it. The reworked patch has been rotting away for almost 2 months. That's a huge black mark against our development process. I haven't complained about this previously because I didn't see any point... I mean, it's not like we have developers sitting around on their thumbs. We've all been working on new features or 2.14 stuff or the like. Also, there's 12 other patches, many from "top tier" developers, waiting for review. No point fussing about a relatively low-priority patch. Besides, I don't like complaining about anything that I'm not willing to fix myself, and I haven't had a chance to get familiar with that side of lilypond. > So yes, it does hurt in my opinion. Agreed. IMO, as long as the cleanup patches are on their own distinct commits, go ahead. That said, I'm not a good authority on .c and .scm changes to lilypond. > Personally, I lean towards thinking that stuff that is not used within > Lilypond, has no user-level documentation and has never been in the > regression tests or snippets should be fair game. I agree. As a general rule of thumb, if the docs compile from scratch, the regtests are not affected, and you honestly believe that it's unused code, go ahead and remove it. If somebody uses lots of weird scheme stuff and really wants them to work, they should make a regtest. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Carl Sorensen writes: > On 8/15/10 7:39 AM, "David Kastrup" wrote: > >> Carl Sorensen writes: >> >>> On 8/15/10 6:48 AM, "David Kastrup" wrote: >>> >>> >>> IMO, getting rid of bit-rotted code is always a good idea. >>> Should it be wrapped in a full review process? >>> >>> I think so. The full review process for removing old stuff is >>> generally very short and sweet (post the patch, somebody important >>> says OK), so I don't think it hurts a bit to do it. >> >> It only involves creating a separate branch, moving the change there, >> removing the change from all ongoing development in related areas >> (and/or postponing work on them until the review process of the bitrot >> change has come to a close), creating a Rietveld issue, uploading the >> changes to Rietveld, monitoring all progress on it, repeating a full >> regtest for any proposed modifications and juggling with >> merge/cherry-pick while doing the parallel development and so on. > > No, you said it was all in one commit. So you have a branch with that > commit and you keep rebasing it. I don't have that branch yet. > When uploading patches to Rietveld one can choose whatever commit is > desired as the reference for the upload, so I think that overlapping > patches can be handled without too much difficulty. Whatever. I'll jump through the hoops for now. I am not confident that I will consider doing cleanup worth the trouble in future. If you have to invest those resources, it distracts from what you actually wanted to be doing. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On 8/15/10 8:06 AM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On 8/15/10 7:39 AM, "David Kastrup" wrote: >> >>> Carl Sorensen writes: >>> On 8/15/10 6:48 AM, "David Kastrup" wrote: IMO, getting rid of bit-rotted code is always a good idea. > Should it > be wrapped in a full review process? I think so. The full review process for removing old stuff is generally very short and sweet (post the patch, somebody important says OK), so I don't think it hurts a bit to do it. >>> >>> It only involves creating a separate branch, moving the change there, >>> removing the change from all ongoing development in related areas >>> (and/or postponing work on them until the review process of the bitrot >>> change has come to a close), creating a Rietveld issue, uploading the >>> changes to Rietveld, monitoring all progress on it, repeating a full >>> regtest for any proposed modifications and juggling with >>> merge/cherry-pick while doing the parallel development and so on. >> >> No, you said it was all in one commit. So you have a branch with that >> commit and you keep rebasing it. > > I don't have that branch yet. > >> When uploading patches to Rietveld one can choose whatever commit is >> desired as the reference for the upload, so I think that overlapping >> patches can be handled without too much difficulty. > > Whatever. I'll jump through the hoops for now. I am not confident that > I will consider doing cleanup worth the trouble in future. If you have > to invest those resources, it distracts from what you actually wanted to > be doing. Well, FWIW, Graham agrees with you and not with me, so you could follow Graham's advice instead of mine. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Graham Percival writes: > > we don't *have* a "full review process" in any meaningful sense of the > term. Especially not for "cleaning up" things. > > As evidence, consider: > http://codereview.appspot.com/1724041/show > > - big initial patch > - lots of comments about splitting up the patch into smaller, > easily-understood portions > - contributor (an unknown person, BTW) does what we ask > - NOBODY bloody looks at it. The reworked patch has been rotting away > for almost 2 months. > > That's a huge black mark against our development process. > Not the process per se, but try doing this on Rietveld. Those are lots of changes in small files. For every single change, you need to tell the web interface to show you the file difference. You look at it, it looks ok. Now you need to navigate back to the list of changed files, remember which file you just looked at, select the next file in the list, navigate to its change overview. And so on. If you just work with the diff posted on the list, you can read and review the whole kaboodle in one session/bunch. Rietveld is nice for changes confined to one file. The more files you want to review in one patch set, the worse you have to click forth and back while remembering where you are in sequence. After your above, quite justified tirade, I went to that changeset with the intent to review it. After clicking around for a while, I ran out of motivation. This is the sort of change you want to review and comment on in one piece. Linearly. Without being forced to do hundreds of mouse clicks. The scroll wheel should be all you need unless you want to comment. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Carl Sorensen writes: > On 8/15/10 8:06 AM, "David Kastrup" wrote: > >> Whatever. I'll jump through the hoops for now. I am not confident >> that I will consider doing cleanup worth the trouble in future. If >> you have to invest those resources, it distracts from what you >> actually wanted to be doing. > > Well, FWIW, Graham agrees with you and not with me, so you could > follow Graham's advice instead of mine. There is sufficient disagreement that I consider it useful to get a more qualified point of view. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On 8/15/10 8:15 AM, "David Kastrup" wrote: > Graham Percival writes: > >> >> we don't *have* a "full review process" in any meaningful sense of the >> term. Especially not for "cleaning up" things. >> >> As evidence, consider: >> http://codereview.appspot.com/1724041/show >> >> - big initial patch >> - lots of comments about splitting up the patch into smaller, >> easily-understood portions >> - contributor (an unknown person, BTW) does what we ask >> - NOBODY bloody looks at it. The reworked patch has been rotting away >> for almost 2 months. >> >> That's a huge black mark against our development process. >> > > Not the process per se, but try doing this on Rietveld. Those are lots > of changes in small files. For every single change, you need to tell > the web interface to show you the file difference. You look at it, it > looks ok. Now you need to navigate back to the list of changed files, > remember which file you just looked at, select the next file in the > list, navigate to its change overview. Or you can just use j to go to the next file on the list or k to go to the previous file on the list (or click on those respective links). I never go back to the main issue page during a review. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On Sun, Aug 15, 2010 at 3:15 PM, David Kastrup wrote: > Graham Percival writes: > >> That's a huge black mark against our development process. > > Not the process per se, but try doing this on Rietveld. Those are lots > of changes in small files. For every single change, you need to tell > the web interface to show you the file difference. You look at it, it > looks ok. Now you need to navigate back to the list of changed files, > remember which file you just looked at, select the next file in the > list, navigate to its change overview. *that's* your beef?! space, j, space, j... that's how I'd approach that patch. Rietveld uses javascript to provide keyboard navigation; it uses the vi-style j/k to move between files. > And so on. If you just work with the diff posted on the list, you can > read and review the whole kaboodle in one session/bunch. Main view of the issue, top of the list of files: download raw patch set. This, annoying, is missing the commit message (although that's easy to see in the main issue description), but the plain diff part is... err... a plain diff. :) That's exactly as useful as a diff sent via email. If you want to pipe it through your own fancy diff display tool, go ahead. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup wrote: > Carl Sorensen writes: > >> Well, FWIW, Graham agrees with you and not with me, so you could >> follow Graham's advice instead of mine. > > There is sufficient disagreement that I consider it useful to get a more > qualified point of view. That would hurt if I didn't agree with you completely. :-) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Graham Percival writes: > On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup wrote: >> Carl Sorensen writes: >> >>> Well, FWIW, Graham agrees with you and not with me, so you could >>> follow Graham's advice instead of mine. >> >> There is sufficient disagreement that I consider it useful to get a >> more qualified point of view. > > That would hurt if I didn't agree with you completely. :-) Why would it hurt you if I check what my actual efforts for "jumping through the proper hoops" are? While my "I am put off by it even before trying" data point is relevant for fresh volunteers, it is less important for problems specific to people with commit access. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On Sun, Aug 15, 2010 at 3:47 PM, David Kastrup wrote: > Graham Percival writes: > >> On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup wrote: >>> There is sufficient disagreement that I consider it useful to get a >>> more qualified point of view. >> >> That would hurt if I didn't agree with you completely. :-) > > Why would it hurt you if I check what my actual efforts for "jumping > through the proper hoops" are? no, no... that was a joke. I was making a joke about your (justified) saying that my point of view was not qualified. I mean, completely rewritten / reinterpreted for humorous effect: Carl: Graham said it was ok, so go ahead. David: yeah, well... Graham is an idiot, so I can't trust him. Graham: ouch, but not really, because I agree that I'm an idiot. ... ok, maybe it wasn't as funny as I thought it was initially. [which just lends further credence to my idiot-ness] Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Carl Sorensen writes: > On 8/15/10 7:39 AM, "David Kastrup" wrote: > >> Carl Sorensen writes: >> >>> On 8/15/10 6:48 AM, "David Kastrup" wrote: >>> >>> >>> IMO, getting rid of bit-rotted code is always a good idea. >>> Should it be wrapped in a full review process? >>> >>> I think so. The full review process for removing old stuff is >>> generally very short and sweet (post the patch, somebody important >>> says OK), so I don't think it hurts a bit to do it. >> >> It only involves creating a separate branch, moving the change there, >> removing the change from all ongoing development in related areas >> (and/or postponing work on them until the review process of the bitrot >> change has come to a close), creating a Rietveld issue, uploading the >> changes to Rietveld, monitoring all progress on it, repeating a full >> regtest for any proposed modifications and juggling with >> merge/cherry-pick while doing the parallel development and so on. > > No, you said it was all in one commit. So you have a branch with that > commit and you keep rebasing it. It's quite easy to do. And you don't have > to eliminate the change from the ongoing development in the related area; if > you're confident it's worth eliminating then eliminate it in your > development work. The development work should go up to Rietveld, the cleanup should go up to Rietveld. git-cl can associate only one review per branch. So I need to fork out the cleanup from the middle of the branch. Possibly by rebasing it to the tip of the branch and then creating a branch from HEAD~1, cherrypicking HEAD. No wait, more likely to the bottom and then just labelling a new branch there. Whatever. I'll figure it out. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: release 2.14 timeline
2010/8/13 Graham Percival : > Translators: at the moment, I'm cautiously predicting that 2.14.0 will > be 4 to 8 weeks away. You will have at least 2 weeks (14 days) notice > before 2.14.0 -- each release candidate is such a warning. Francisco, > you're in charge of sending this to the translator list, and/or > sending private emails to relevant people. Starting on next Wed 18 or Thu 19 I'll become more available for a wide spectrum of tasks. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
David Kastrup writes: > Carl Sorensen writes: > >> On 8/15/10 7:39 AM, "David Kastrup" wrote: >> >>> Carl Sorensen writes: >>> On 8/15/10 6:48 AM, "David Kastrup" wrote: IMO, getting rid of bit-rotted code is always a good idea. > Should it > be wrapped in a full review process? I think so. The full review process for removing old stuff is generally very short and sweet (post the patch, somebody important says OK), so I don't think it hurts a bit to do it. >>> >>> It only involves creating a separate branch, moving the change there, >>> removing the change from all ongoing development in related areas >>> (and/or postponing work on them until the review process of the bitrot >>> change has come to a close), creating a Rietveld issue, uploading the >>> changes to Rietveld, monitoring all progress on it, repeating a full >>> regtest for any proposed modifications and juggling with >>> merge/cherry-pick while doing the parallel development and so on. >> >> No, you said it was all in one commit. So you have a branch with that >> commit and you keep rebasing it. It's quite easy to do. And you don't have >> to eliminate the change from the ongoing development in the related area; if >> you're confident it's worth eliminating then eliminate it in your >> development work. > > The development work should go up to Rietveld, the cleanup should go > up to Rietveld. git-cl can associate only one review per branch. So > I need to fork out the cleanup from the middle of the branch. > Possibly by rebasing it to the tip of the branch and then creating a > branch from HEAD~1, cherrypicking HEAD. No wait, more likely to the > bottom and then just labelling a new branch there. Whatever. I'll > figure it out. Ok, moving it to the bottom of the branch was a bad idea: moving the cleanup across other changes done before it causes rebase conflicts galore. So I'll have to branch off the feature branch, meaning that my diffs will not be applicable to the unchanged origin. Maybe I can rebase after moving it out? But that should be similarly expensive. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On 8/15/10 9:14 AM, "David Kastrup" wrote: > > The development work should go up to Rietveld, the cleanup should go up > to Rietveld. git-cl can associate only one review per branch. So I > need to fork out the cleanup from the middle of the branch. Possibly by > rebasing it to the tip of the branch and then creating a branch from > HEAD~1, cherrypicking HEAD. No wait, more likely to the bottom and then > just labelling a new branch there. Whatever. I'll figure it out. if it were me, I'd create a new branch, then chop out all the old stuff. Then create a new branch from the cleaned branch, which will be the development branch. Now you've got the cleaned branch available for the Rietveld review, and the development branch available for review relative to the cleaned branch. Both reviews are easily maintainable; if you update the cleaned branch, you just rebase the development branch. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Review: remove markup function aliasing mechanism (was: Half-baked unused features.)
The aliasing functionality is unused in the current source code, not documented at user level, and not sure to be fully working (there are no regtests to check). Documenting it complicates the documentation without an immediately visible user benefit. The patch likely does not apply to a pristine source, but I checked that it still passes the regtests. http://codereview.appspot.com/1995042> -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Carl Sorensen writes: > On 8/15/10 7:39 AM, "David Kastrup" wrote: > >> Carl Sorensen writes: >>> >>> I think so. The full review process for removing old stuff is >>> generally very short and sweet (post the patch, somebody important >>> says OK), so I don't think it hurts a bit to do it. >> >> It only involves creating a separate branch, moving the change there, >> removing the change from all ongoing development in related areas >> (and/or postponing work on them until the review process of the >> bitrot change has come to a close), creating a Rietveld issue, >> uploading the changes to Rietveld, monitoring all progress on it, >> repeating a full regtest for any proposed modifications and juggling >> with merge/cherry-pick while doing the parallel development and so >> on. > > No, you said it was all in one commit. So you have a branch with that > commit and you keep rebasing it. It's quite easy to do. The rebase is in conflict with the other development. I tried that first, but stopped before seriously working on the rebase conflicts (experience tells me that one such conflict is followed by number of conflicts in the same series, making this very tiresome since your conflict resolution leads to more conflicts later). Saving time less experienced gitters would likely expend. At the cost of making the review less usable (patches won't apply to user source). So up to now, just a bit more than 30 minutes of work. "short and sweet, doesn't hurt a bit". Huh. > And if it's really not used, then removing it will have no effect > whatsoever on your downstream stuff. Except for merge conflicts. Huh. > I don't think I've *ever* seen anyone propose modifications in > bitrotted stuff to be removed. Huh? The area is not bitrotted. Only an unused subfeature that is scattered across it. > I think your argument doesn't match with the reality of the situation. I think it does. And I am the one working on it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Carl Sorensen writes: > On 8/15/10 9:14 AM, "David Kastrup" wrote: > >> >> The development work should go up to Rietveld, the cleanup should go up >> to Rietveld. git-cl can associate only one review per branch. So I >> need to fork out the cleanup from the middle of the branch. Possibly by >> rebasing it to the tip of the branch and then creating a branch from >> HEAD~1, cherrypicking HEAD. No wait, more likely to the bottom and then >> just labelling a new branch there. Whatever. I'll figure it out. > > if it were me, I'd create a new branch, then chop out all the old stuff. > Then create a new branch from the cleaned branch, which will be the > development branch. > > Now you've got the cleaned branch available for the Rietveld review, and the > development branch available for review relative to the cleaned branch. > Both reviews are easily maintainable; if you update the cleaned branch, you > just rebase the development branch. The cleanup, among other things, basically changes (define ... (if some-condition whatever-and-quite-long whatever-else) ) into (define ... whatever-and-quite-long ) Since all the other work is going on in whatever-and-quite-long, and since the cleanup changes its indentation, every rebase affects the whole area repeatedly and will require manual conflict resolution. "just rebase" is a mess for that reason. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Review: start work on markup doc and code (was: Half-baked unused features.)
http://codereview.appspot.com/1991043> -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: release 2.14 timeline
Le 15/08/2010 17:20, Francisco Vila disait : 2010/8/13 Graham Percival: Translators: at the moment, I'm cautiously predicting that 2.14.0 will be 4 to 8 weeks away. You will have at least 2 weeks (14 days) notice before 2.14.0 -- each release candidate is such a warning. Francisco, you're in charge of sending this to the translator list, and/or sending private emails to relevant people. Starting on next Wed 18 or Thu 19 I'll become more available for a wide spectrum of tasks. Paco, Please wait until I've pushed the French version of running before merging into master. It should be before tomorrow's brunch. Thereafter, I wont have full access to the web for the next two weeks unless vacation-shortage. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
>> Should it be wrapped in a full review process? > > I think so. The full review process for removing old stuff is > generally very short and sweet (post the patch, somebody important > says OK), so I don't think it hurts a bit to do it. Well, IMHO, for trivial things: Just do it! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
shortInstrumentName getting clipped on the left margin of PDF page.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Has anyone noticed this problem on the second and following pages of PDF output, I've reproduced this with 2.13.17 and with 2.13.29. I'd like to know if anyone else has noticed this. The shortInstrumentNames you should see are: Picc 1 Picc 2 Fl 1 Fl 2 Fl 3 Fl 4 Fl 5 A. Fl B. Fl I only see the rightmost character on the left of the page, with the penultimate character only half printed. I would have attached the output but gnu.org spam filter decided it was spam and bounced the message. I haven't attached any source here either as I've used orchestrallily to generate the stave declarations, and this is a really long piece using a lot of different files. Any observations or suggestions? Cheers, Ian Hulin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMaGw6AAoJEBqidDirZqAS7ZcH/A/dory3u/SvAxW69OuNOS2z XGN+mMJbMOZ0i+OG/vnG0medi8evophpRyT5OhJSWbjkOYDoZ4gy2oXTdb5omXzk BPLOLMa4dQScTcWbxqafYklGWtwWt8mUChPDeZE8sba/bK5b58LwhUpxVJJDtLyu Mdg4EnkmqDIstf2NusFkYTgeyE/05BlGbYnIv/FABfJPeTKhj1PH1mOzoSr6prml F6SzZKk5EZQME12+DOWRFxooCCBcWcTUJp4kxjkZXd8EcknGEkYFg0Pw3zKtD95O mtXELSeBAhekZs2X0maunLvKSooMtcHPWI4gaU+V/HKbVISJ7Du+xFgnTHgDUiA= =+eiN -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
On 8/15/10 9:40 AM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On 8/15/10 7:39 AM, "David Kastrup" wrote: >> >>> Carl Sorensen writes: I think so. The full review process for removing old stuff is generally very short and sweet (post the patch, somebody important says OK), so I don't think it hurts a bit to do it. >>> >>> It only involves creating a separate branch, moving the change there, >>> removing the change from all ongoing development in related areas >>> (and/or postponing work on them until the review process of the >>> bitrot change has come to a close), creating a Rietveld issue, >>> uploading the changes to Rietveld, monitoring all progress on it, >>> repeating a full regtest for any proposed modifications and juggling >>> with merge/cherry-pick while doing the parallel development and so >>> on. >> >> No, you said it was all in one commit. So you have a branch with that >> commit and you keep rebasing it. It's quite easy to do. > > The rebase is in conflict with the other development. I tried that > first, but stopped before seriously working on the rebase conflicts > (experience tells me that one such conflict is followed by number of > conflicts in the same series, making this very tiresome since your > conflict resolution leads to more conflicts later). Saving time less > experienced gitters would likely expend. At the cost of making the > review less usable (patches won't apply to user source). > > So up to now, just a bit more than 30 minutes of work. "short and > sweet, doesn't hurt a bit". Huh. But if you don't have a patch that applies to user source, how can you "remove the feature in a single commit"? It seems that the problem you're having right now is one of isolating the removal of the old code. Your first email said "if I remove the old code in a separate commit that can be reverted" or something to that effect. The problem you're talking about now is a problem of isolating the removal, not one of waiting for review on Rietveld. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
markup.scm: Remove unused and untested aliasing functionality from define-markup{,-list}-command (issue1995042)
LGTM. Further info: This code has been in the file since 114c05e7b0e992de7dbdd0958d23eb8d2ab1eaae (the file name at that time was scm/new-markup.scm). I think that the alternate syntax has never been used in the main source tree; it could have been used (but it's doubtful) in an individual user's source code, so there should probably be a Changes entry when this patch is pushed. Carl http://codereview.appspot.com/1995042/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
markup documentation improvements. Not yet finished, but the base for a different Rietveld review. (issue1991043)
LGTM. Thanks http://codereview.appspot.com/1991043/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Half-baked unused features.
Carl Sorensen writes: > On 8/15/10 9:40 AM, "David Kastrup" wrote: > >> Carl Sorensen writes: >> >>> On 8/15/10 7:39 AM, "David Kastrup" wrote: >>> Carl Sorensen writes: > > I think so. The full review process for removing old stuff is > generally very short and sweet (post the patch, somebody important > says OK), so I don't think it hurts a bit to do it. It only involves creating a separate branch, moving the change there, removing the change from all ongoing development in related areas (and/or postponing work on them until the review process of the bitrot change has come to a close), creating a Rietveld issue, uploading the changes to Rietveld, monitoring all progress on it, repeating a full regtest for any proposed modifications and juggling with merge/cherry-pick while doing the parallel development and so on. >>> >>> No, you said it was all in one commit. So you have a branch with that >>> commit and you keep rebasing it. It's quite easy to do. >> >> The rebase is in conflict with the other development. I tried that >> first, but stopped before seriously working on the rebase conflicts >> (experience tells me that one such conflict is followed by number of >> conflicts in the same series, making this very tiresome since your >> conflict resolution leads to more conflicts later). Saving time less >> experienced gitters would likely expend. At the cost of making the >> review less usable (patches won't apply to user source). >> >> So up to now, just a bit more than 30 minutes of work. "short and >> sweet, doesn't hurt a bit". Huh. > > But if you don't have a patch that applies to user source, how can you > "remove the feature in a single commit"? It seems that the problem > you're having right now is one of isolating the removal of the old > code. Your first email said "if I remove the old code in a separate > commit that can be reverted" or something to that effect. The problem, as pointed out already, is that the commit affects the bulk of the indentation in the respective functions, while changing only few lines of substance. And that means that it conflicts with any other ongoing work on the same code areas. That means that rebasing across any such other work is going to lead to merge conflicts. > The problem you're talking about now is a problem of isolating the > removal, not one of waiting for review on Rietveld. The size of the patch in lines is making the difference here. If git were smarter about resolving pure indentation conflicts (possibly causing nightmares for Python addicts; but actually a useful resolution would have to be indentation-correct in other languages as well), this would be less of a problem. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Latest Doc Patch from Graham
In the patch Author: Graham Percival 2010-08-15 19:14:33 Committer: Graham Percival 2010-08-15 19:14:33 Parent: cfe29e5a0720f8e5ca7e220c77e9cf8ab2d08306 (Doc: CG: add warning about test-output-distance.) Branches: master, remotes/origin/master Follows: release/2.13.30-1 Precedes: Doc: CG: begin cleaning up Releases chapter. I read a number of changes like +...@item * write preface section for manual. +...@item * submit pots for translation: send url of tarball to translation@@iro.umontreal.ca, mentioning lilypond-VERSION.pot +...@item * Check reg test It would seem to me that adding the @item lines should be accompanied by getting rid of the pseudo bullets " *" in order to avoid duplicate markup. I have not actually looked at the typeset or HTML version. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Latest Doc Patch from Graham
On Mon, Aug 16, 2010 at 05:00:37AM +0200, David Kastrup wrote: > > In the patch > > Doc: CG: begin cleaning up Releases chapter. > > I read a number of changes like > > +...@item > * write preface section for manual. Yes. > It would seem to me that adding the @item lines should be accompanied by > getting rid of the pseudo bullets " *" in order to avoid duplicate > markup. Yes. At that point, I was mechanically adding @item s; I'm more concerned about the content. The commit messages is "begin cleaning up", and that chapter is such a mess that I didn't think it really mattered. However, it's bad practice, and I certainly wouldn't accept doc patches like that from other people. I'll avoid this in the future. Sorry, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
git merge drivers (was: Half-baked unused features.)
* David Kastrup wrote on Mon, Aug 16, 2010 at 04:16:49AM CEST: > The problem, as pointed out already, is that the commit affects the bulk > of the indentation in the respective functions, while changing only few > lines of substance. > > And that means that it conflicts with any other ongoing work on the same > code areas. That means that rebasing across any such other work is > going to lead to merge conflicts. [...] > If git were smarter about resolving pure indentation conflicts FWIW, git allows you to provide your own merge driver for specific types of files. For example, gnulib provides a git-merge-changelog driver that helps merging GNU-style ChangeLog files. Also, git has a few drivers of its own. > (possibly causing nightmares for Python addicts; but actually a useful > resolution would have to be indentation-correct in other languages as > well), this would be less of a problem. No nightmares when you delimit your driver to a specific set of files. I'm not sure it's worth for this specific issue though. Cheers, Ralf ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
