Re: Issue 2100: Explanation of branches for CG (issue 5539062)
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right): http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi#newcode450 Documentation/contributor/source-code.itexi:450: git rebase origin/staging Problem: approximately once every 2 weeks, origin/staging is broken. As a result, we delete the existing origin/staging branch, test a subset of patches, push them, etc etc. You've seen the mess that happens. With this recipe, the broken-staging will be in the developer's personal dev/cg branch. Is there any way we can avoid this? The only way I've thought of so far is to produce an *additional* staging-dev/cg branch from dev/cg, rebase staging-dev/cg on origin/staging, then merge (or rebase) staging-dev/cg on staging and push that. I know it really complicates stuff, but given our history of bad commits in staging, it would be sheer folly to assume that it will never happen again. I still wish that there was some way of using staging for this purpose -- then the developer would always know that dev/cg is his (unspoiled) work, origin/staging is where he wants to put it, and staging is a temporary storage location. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi#newcode491
Documentation/contributor/source-code.itexi:491: git branch -D dev/cg
I know this is from what I wrote originally, but I've changed my mind:
it's too easy for somebody to copypaste the wrong set of commands.
Could this entire @subsubheading be changed to read:
@c don't give explicit commands here, to avoid accidental copypaste
Sometimes everything goes wrong. If you want to remove a branch
regardless of losing your own work, follow the instructions in
@qq{Delete your branch (safe)} but replace the @code{-d} with a
@code{-D} on the final line.
http://codereview.appspot.com/5539062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book windows 4
I believe this will work out-of-the-box for any .TELY file, regardless of whether texi2pdf is in the path or not. Please test. http://lilypond.org/~graham/lilypond-2.15.25-4.mingw.exe - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book windows 4
Graham Percival wrote Sunday, January 15, 2012 8:23 AM I believe this will work out-of-the-box for any .TELY file, regardless of whether texi2pdf is in the path or not. Please test. http://lilypond.org/~graham/lilypond-2.15.25-4.mingw.exe Well, not quite. Two problems: 1. should be output_filename in lines 224 and 226 in book_texinfo.py 2. the parameter string to texi2pdf is wrong if texi2dvi from MiKTeX is used, so cmd needs to be set up differently on Windows platforms. I gave the correct string in an earlier note. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book windows 4
On Sun, Jan 15, 2012 at 08:59:58AM -, Trevor Daniels wrote: Graham Percival wrote Sunday, January 15, 2012 8:23 AM http://lilypond.org/~graham/lilypond-2.15.25-4.mingw.exe Well, not quite. Two problems: 1. should be output_filename in lines 224 and 226 in book_texinfo.py Whoops. Thanks, fixed. 2. the parameter string to texi2pdf is wrong if texi2dvi from MiKTeX is used, so cmd needs to be set up differently on Windows platforms. I gave the correct string in an earlier note. You're referring to http://lists.gnu.org/archive/html/lilypond-devel/2012-01/msg00474.html ? I'm not convinced that this is a good change; texi2pdf and texi2dvi are different programs, and I don't think that we should assume that the user will rename texi2dvi.exe to texi2pdf.exe. As long as this solution at least provides the default line-widths on windows with or without texi2pdf.exe, I think it's worth merging it into master. If texi2pdf.exe requires a different command-line, that can be done in a further commit. I'll make a -5 now, containing the fixed output_filename and applying the same method for latex files. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book windows 5
I believe this will at least produce the default line-widths out-of-the-box for any texinfo or latex file, regardless of whether texi2pdf is in the path or not. Please test. http://lilypond.org/~graham/lilypond-2.15.25-5.mingw.exe I am hopeful (though I am not optimistic) that it will work with texi2pdf.exe rather than texi2dvi.exe. However, I consider that a separate issue: if this version can reliably give default line-widths, I want to get it merged and 2.15.25 out the door. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 08:05:35, Graham Percival wrote: http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right): http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi#newcode450 Documentation/contributor/source-code.itexi:450: git rebase origin/staging Problem: approximately once every 2 weeks, origin/staging is broken. As a result, we delete the existing origin/staging branch, test a subset of patches, push them, etc etc. You've seen the mess that happens. With this recipe, the broken-staging will be in the developer's personal dev/cg branch. I think you misunderstand what git rebase does. git rebase origin/staging does *not* bring origin/staging into dev/cg; it creates commits that are necessary to get dev/cg from origin/staging. If origin/staging is bad, and then deleted, and then built again as a new origin/staging, the developer can get the appropriate set of commits by just reissuing git rebase origin/staging. It works the way you want it to work. dev/cg *always* holds the pristine copy of the developer's work. git rebase origin/staging doesn't change dev/cg one bit. At any time I can do git rebase master and I'll get the set of commits necessary to develop dev/cg from master. The only time this fails is if two people have been working on the same lines of the same file, in which case there will be a merge conflict, and it will need to be resolved manually. But there is nothing that can be done about this. We have to resolve the merge conflict when we do the rebase -- but it's not an artifact of git, it's a real issue. I still wish that there was some way of using staging for this purpose -- then the developer would always know that dev/cg is his (unspoiled) work, origin/staging is where he wants to put it, and staging is a temporary storage location. Why do we need a temporary storage location? The only difference between staging and origin/staging is a timing issue -- staging may be behind origin/staging because changes have happened when I did git fetch. But I can't push to origin/staging until I rebase to origin/staging. It works just the way you want it to out of the box. When I went and gathered James's commits to push to staging, I didn't make *any* changes to his work. I just created a branch, applied his patch, rebased to origin/staging, and pushed. And it went seamlessly. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On Sun, Jan 15, 2012 at 12:18:57PM +, carl.d.soren...@gmail.com wrote: I think you misunderstand what git rebase does. git rebase origin/staging does *not* bring origin/staging into dev/cg; really? wow, I completely misunderstood that. If origin/staging is bad, and then deleted, and then built again as a new origin/staging, the developer can get the appropriate set of commits by just reissuing git rebase origin/staging. ok, sounds great! - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 08:17:35, Graham Percival wrote: Could this entire @subsubheading be changed to read: Done http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 12:18:57, Carl wrote: On 2012/01/15 08:05:35, Graham Percival wrote: http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right): http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi#newcode450 Documentation/contributor/source-code.itexi:450: git rebase origin/staging Problem: approximately once every 2 weeks, origin/staging is broken. As a result, we delete the existing origin/staging branch, test a subset of patches, push them, etc etc. You've seen the mess that happens. With this recipe, the broken-staging will be in the developer's personal dev/cg branch. I think you misunderstand what git rebase does. I am afraid that this honor is entirely on your side. git rebase origin/staging does *not* bring origin/staging into dev/cg; it creates commits that are necessary to get dev/cg from origin/staging. If dev/cg is the current branch, git rebase origin/staging _does_ bring origin/staging into dev/cg, and on top of that puts all those commits that have been in dev/cg but not in origin/staging. Afterwards, dev/cg is a proper descendant of origin/staging, and the commits that have been in origin/staging are an integral part of it indistinguishable from original dev/cg commits in itself. If origin/staging is bad, and then deleted, and then built again as a new origin/staging, the developer can get the appropriate set of commits by just reissuing git rebase origin/staging. But those commits that have been excised from origin/staging are now in the set origin/staging..dev/cg and will in consequence get _reapplied_ on top of the fresh origin/staging. There are two ways out. The hairy one: git rebase the-old-origin-staging-commit-id --onto origin/staging dev/cg This will take just the commits in dev/cg that are on top of the old origin/staging and apply them on top of the new origin/staging. This requires you to keep track of what commits are your own, and which commits have sneaked into your branch from an excised staging. The less hairy one is not to rebase dev/cg on staging ever. Instead, rebase on origin (which never gets rewound): git rebase origin dev/cg And if staging is _beyond_ origin, you can now do git rebase origin/staging dev/cg~0 before testing and pushing. Note that dev/cg~0 does _not_ rebase dev/cg, but does the rebase operation on a detached HEAD. dev/cg proper remains rebased on origin/master. It works the way you want it to work. dev/cg *always* holds the pristine copy of the developer's work. git rebase origin/staging doesn't change dev/cg one bit. If dev/cg is the currently checked out branch, it most certainly will. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 12:32:21, Graham Percival wrote: On Sun, Jan 15, 2012 at 12:18:57PM +, mailto:carl.d.soren...@gmail.com wrote: I think you misunderstand what git rebase does. git rebase origin/staging does *not* bring origin/staging into dev/cg; really? wow, I completely misunderstood that. Yes. git rebase just changes the *attachment point* of the branch. So although the source code in the current directory will change with git rebase, the branch itself won't. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
Graham Percival gra...@percival-music.ca writes: On Sun, Jan 15, 2012 at 12:18:57PM +, carl.d.soren...@gmail.com wrote: I think you misunderstand what git rebase does. git rebase origin/staging does *not* bring origin/staging into dev/cg; really? wow, I completely misunderstood that. If it didn't bring it into dev/cg, what else would it do when dev/cg is the currently checked out branch (which I assume this is about)? If it didn't bring origin/staging into dev/cg, how could you then push the HEAD of dev/cg as a fastforward into origin/staging? If origin/staging is bad, and then deleted, and then built again as a new origin/staging, the developer can get the appropriate set of commits by just reissuing git rebase origin/staging. ok, sounds great! Too good to be true. See comment in the issue. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 12:43:03, Carl wrote: On 2012/01/15 12:32:21, Graham Percival wrote: On Sun, Jan 15, 2012 at 12:18:57PM +, mailto:carl.d.soren...@gmail.com wrote: I think you misunderstand what git rebase does. git rebase origin/staging does *not* bring origin/staging into dev/cg; really? wow, I completely misunderstood that. Yes. git rebase just changes the *attachment point* of the branch. So although the source code in the current directory will change with git rebase, the branch itself won't. Carl, you are wrong. You can, at your choice, read the manual page of git rebase, or do a few experiments on local branches. git rebase most certainly brings the commits of the specified branch into the checked-out branch, and puts the non-common commits in the checked-out branch on top. There is no way that the commits will get out again by a pure rebase (without --onto option), so if the commits get removed from origin/staging for some manner, they most certainly will stay in dev/cg if that has been rebased on the old origin/staging. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 12:50:21, dak wrote: On 2012/01/15 12:43:03, Carl wrote: On 2012/01/15 12:32:21, Graham Percival wrote: On Sun, Jan 15, 2012 at 12:18:57PM +, mailto:carl.d.soren...@gmail.com wrote: I think you misunderstand what git rebase does. git rebase origin/staging does *not* bring origin/staging into dev/cg; really? wow, I completely misunderstood that. Yes. git rebase just changes the *attachment point* of the branch. So although the source code in the current directory will change with git rebase, the branch itself won't. Carl, you are wrong. You can, at your choice, read the manual page of git rebase, or do a few experiments on local branches. I believe you, because you are never wrong on these things. I have read the manual page on git rebase, but apparently didn't understand it. I am currently doing the local experiments. Thank you for keeping me straight. Carl http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
After doing some testing, it appears that the following should be able to get my dev/cg applied to origin/staging, while preserving my dev/cg: git rebase origin/staging dev/cg~0 git push origin HEAD:staging David, is this correct? Thanks, Carl http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
Begin LilyPond compile, commit: e25565e23b6e7a219c594d359495817d7076eff5 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: e25565e23b6e7a219c594d359495817d7076eff5 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
James' Patchy email
Begin LilyPond compile, commit: e25565e23b6e7a219c594d359495817d7076eff5 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
Begin LilyPond compile, commit: e25565e23b6e7a219c594d359495817d7076eff5 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: e25565e23b6e7a219c594d359495817d7076eff5 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: 53ab418e0bb8f272082db295b38a1dbb2ccfca65 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? Begin LilyPond compile, commit: e25565e23b6e7a219c594d359495817d7076eff5 *** FAILED STEP *** merge from staging maybe somebody pushed a commit directly to master? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: James' Patchy email
On Sat, Jan 14, 2012 at 09:01:21AM -0800, lilypond.patchy.ja...@gmail.com wrote: Begin LilyPond compile, commit: e25565e23b6e7a219c594d359495817d7076eff5 *** FAILED STEP *** sorry, I forgot to warn you to about lines 45-46 in compile_lilypond_test.py. You may want to comment those out for now. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
- Original Message - From: Phil Holmes em...@philholmes.net To: Devel lilypond-devel@gnu.org Sent: Tuesday, December 27, 2011 11:34 AM Subject: Further work on reducing make doc output - GOP 9 I've written a shell script that has as its arguments a command line and a logfile. It runs the command, sending the output from that command to the logfile. It then returns the error status from the command line. If an error occurs, it displays a message indicating the name of the logfile. We should be able to use this to reduce the output of make doc considerably, while at the same time retaining the output in logfiles and pointing where to look in the event of a failure. I attach a set of files that can be used to show this in action. Note that one of the .texi files includes a file with errors, and, FWIW, texi2html continues happily, whereas texi2pdf stops on the error. This is also true even with error-limit =0 - texi2html seems to view errored input as simply something worth warning about. Also note the --clean option for texi2pdf - this reduces the cruft in the output directory a lot, and since we now have a separate logfile, I don't know of a reason to keep it. Please let me know if anyone knows different. I will convert this to a patch for proper review, but wanted those who understand Unix scripts to pass their eyes over a simple version first. TIA. OK - so I don't think anyone has looked at this. I think I've got 3 options: ask again here; make a patch from the test files I created, make a new directory in my lilypond-git directory and put them up, standalone, as a patch on Rietveld for review; or implement this system on the make doc build system and put the patch for review. I'm pretty much against the last one, owing to the chances of wasted time. Could anyone advise on the first 2 options? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
On 12-01-15 07:47 AM, Phil Holmes wrote: snipped OK - so I don't think anyone has looked at this. I think I've got 3 options: ask again here; make a patch from the test files I created, make a new directory in my lilypond-git directory and put them up, standalone, as a patch on Rietveld for review; or implement this system on the make doc build system and put the patch for review. I'm pretty much against the last one, owing to the chances of wasted time. Could anyone advise on the first 2 options? -- Phil Holmes It would seem reasonable to develop the test against your local doc build, then put up a patch on Rietveld for review, and possibly a Tracker item, as I can't quickly find an open one which would cover this. I suggest that because patches in the formal process seem to have a better chance of review, although not a guarantee. Regarding your scripts: can they be modified to accept a variable paper size, for those of us outside the A4 realm? Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book windows 5
Graham, you wrote Sunday, January 15, 2012 9:32 AM I believe this will at least produce the default line-widths out-of-the-box for any texinfo or latex file, regardless of whether texi2pdf is in the path or not. Please test. http://lilypond.org/~graham/lilypond-2.15.25-5.mingw.exe I believe it produces default line-widths on my setup with or without texi2pdf for texinfo files, although I've not been able to actually see a final pdf or html, as I don't have working versions of either texi2pdf or texi2html under Windows at the moment. But at least lilypond-book now runs correctly to completion under Windows on a number of .itexi files. I am hopeful (though I am not optimistic) that it will work with texi2pdf.exe rather than texi2dvi.exe. However, I consider that a separate issue: if this version can reliably give default line-widths, I want to get it merged and 2.15.25 out the door. OK by me. Let's move on. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Further work on reducing make doc output - GOP 9
- Original Message - From: Colin Campbell c...@shaw.ca I would imagine you can change/drop the @afourpaper line, although these are only ever intended as a proof of concept, so it's barely worth bothering. Regarding your scripts: can they be modified to accept a variable paper size, for those of us outside the A4 realm? Cheers, Colin -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Clickable examples in the docs
Hi, The clickable examples in the docs have stopped working. The links appear to be broken since they're missing the .ly suffix. Try the example on this page: http://lilypond.org/doc/v2.15/Documentation/learning/clickable-examples It goes to http://lilypond.org/doc/v2.15/Documentation/9e/lily-06377646 instead of http://lilypond.org/doc/v2.15/Documentation/9e/lily-06377646.ly I'm not sure how long it's been like this; I only noticed it when I looked at the changes page today. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clickable examples in the docs
Il 15/01/2012 17:51, Neil Puttock ha scritto: I'm not sure how long it's been like this; I only noticed it when I looked at the changes page today. I noticed it ten days ago and forgot to report it (sorry). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clickable examples in the docs
Hello, On 15 January 2012 17:03, Federico Bruni fedel...@gmail.com wrote: Il 15/01/2012 17:51, Neil Puttock ha scritto: I'm not sure how long it's been like this; I only noticed it when I looked at the changes page today. I noticed it ten days ago and forgot to report it (sorry). Opened as: http://code.google.com/p/lilypond/issues/detail?id=2224 -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
LGTM On 2012/01/15 08:05:35, Graham Percival wrote: With this recipe, the broken-staging will be in the developer's personal dev/cg branch. Is there any way we can avoid this? 1) We could accept it as a consequence of re-writing the public history on origin/staging. When the developer does his next rebase -i he should recognize that some commits are not his, and remove them from the rebase --or test them and fix the problem that forced the rewind of staging. 2) We could introduce both 'merge' and 'rebase' in the guide: git checkout staging git reset --hard origin/staging # reset local staging to the repository git merge dev/cg # bring your new commits into local staging git rebase -i origin/staging # rewrite local history to put the new commits last gitk # check that the commits look as you intended git push origin/staging On 2012/01/15 13:37:13, Carl wrote: git rebase origin/staging dev/cg~0 git push origin HEAD:staging 3) The example above is certainly shorter. I find it difficult to understand. It implicitly checks out the last commit in dev/cg (leaving git not on any branch). I would not have guessed that this would be supported, based on `man git rebase`. Then the command rebases that non-on-any-branch history to origin/staging and pushes that history to the repository. It leaves git in the state of being not on any branch. I think (2) is the best example for the guide. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book windows 5
Hi Phil, James Graham all, 2012/1/11 Phil Holmes em...@philholmes.net: - Original Message - From: Janek Warchoł This might be a stupid question, but i never used lilypond-book before: should i call it without any input file? If no, can you provide example input? I'll do this when I'm back from college. Meantime I've attached a test file I use - nothing special, but it should work. To make the test fair, you should also fix your PATH statement - remove any old lilypond paths from it and ensure the path the the .exe is added to the path statement before calling -book. 2012/1/11 James pkx1...@gmail.com: Janek, It is simple. Graham is right you do need to look at the doc but you can do a very simple thing [...] Does this help? Thank you, Phil and James, for your explanations about testing lilypond-book. I'm sorry that i wasn't able to read them sooner, however i hope i can use them now: 2012/1/15 Graham Percival gra...@percival-music.ca: I believe this will at least produce the default line-widths out-of-the-box for any texinfo or latex file, regardless of whether texi2pdf is in the path or not. Please test. http://lilypond.org/~graham/lilypond-2.15.25-5.mingw.exe Here's what i did (i have Windows 7 Home Premium): 1) uninstalled LilyPond 2) manually removed lilypond paths from PATH 3) installed Lily using binary Graham linked to 4) added lilypond path to PATH (it didn't work automatically) 5) went to 'foo' directory containing 'LineLength.tely' posted by Phil (attached) 6) called 'lilypond-book LineLength.tely' - it complained that it doesn't know texi2pdf, but otherwise results look ok i think... I understand that texi2pdf is not what this test is about. Below are the logs, i also attach output png files. E:\dane\foolilypond-book LineLength.tely lilypond-book.py (GNU LilyPond) 2.15.25 Reading LineLength.tely... Running texi2pdf on file c:\users\janek\appdata\local\temp\tmp7qtyva.texi to det ect default page settings. Nazwa 'texi2pdf' nie jest rozpoznawana jako polecenie wewnętrzne lub zewnętrzne, program wykonywalny lub plik wsadowy. # it doesn't know what texi2pdf is lilypond-book.py: warning: Unable to auto-detect default settings: Dissecting... Writing snippets... Processing... Running lilypond... GNU LilyPond 2.15.25 programming error: file name not normalized: E:\dane\foo\snippet-names-853151356 .ly continuing, cross fingers Processing `E:/dane/foo/snippet-map-853151356.ly' Parsing... Processing `E:/dane/foo/a1/lily-e3989e8b.ly' Parsing... Interpreting music... [8][16][24] Preprocessing graphical objects... Calculating line breaks... Drawing systems... Layout output to `/dane/foo/a1/lily-e3989e8b.eps'... Converting to PNG... Layout output to `/dane/foo/a1/lily-e3989e8b-1.eps'... Layout output to `/dane/foo/a1/lily-e3989e8b-2.eps'... Layout output to `/dane/foo/a1/lily-e3989e8b-3.eps'... Layout output to `/dane/foo/a1/lily-e3989e8b-4.eps'... Layout output to `/dane/foo/a1/lily-e3989e8b-5.eps'... Writing /dane/foo/a1/lily-e3989e8b-systems.texi... Writing /dane/foo/a1/lily-e3989e8b-systems.tex... Writing /dane/foo/a1/lily-e3989e8b-systems.count... Processing `E:/dane/foo/9b/lily-7b744797.ly' Parsing... Interpreting music... [8][16][24] Preprocessing graphical objects... Calculating line breaks... Drawing systems... Layout output to `/dane/foo/9b/lily-7b744797.eps'... Converting to PNG... Layout output to `/dane/foo/9b/lily-7b744797-1.eps'... Layout output to `/dane/foo/9b/lily-7b744797-2.eps'... Layout output to `/dane/foo/9b/lily-7b744797-3.eps'... Layout output to `/dane/foo/9b/lily-7b744797-4.eps'... Writing /dane/foo/9b/lily-7b744797-systems.texi... Writing /dane/foo/9b/lily-7b744797-systems.tex... Writing /dane/foo/9b/lily-7b744797-systems.count... Processing `E:/dane/foo/a5/lily-0c525fe4.ly' Parsing... Interpreting music... [8][16][24] Preprocessing graphical objects... Calculating line breaks... Drawing systems... Layout output to `/dane/foo/a5/lily-0c525fe4.eps'... Converting to PNG... Layout output to `/dane/foo/a5/lily-0c525fe4-1.eps'... Layout output to `/dane/foo/a5/lily-0c525fe4-2.eps'... Layout output to `/dane/foo/a5/lily-0c525fe4-3.eps'... Layout output to `/dane/foo/a5/lily-0c525fe4-4.eps'... Layout output to `/dane/foo/a5/lily-0c525fe4-5.eps'... Writing /dane/foo/a5/lily-0c525fe4-systems.texi... Writing /dane/foo/a5/lily-0c525fe4-systems.tex... Writing /dane/foo/a5/lily-0c525fe4-systems.count... Success: compilation successfully completed Compiling E:\dane\foo\LineLength.texi... Writing `E:\dane\foo\LineLength.texi'... hope this helps, Janek LineLength.tely Description: Binary data attachment: lily-0c525fe4.pngattachment: lily-7b744797.pngattachment: lily-e3989e8b.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for DotColumn not triggering vertical alignment. (issue 5538049)
LGTM. Now I see why this bug appeared. The recent changes to the beam configuration code need to know the note-spacing, which depends on the horizontal dot positions. So, dot configuration may not wait for beaming. The code configuring dots was (indirectly and wrongly) causing rest-collision to run, which (in rare cases) needs to know the beam configuration so as to avoid a stem. If I get the point, a 'pure' (read before line-breaking) estimate of rest position is always sufficient for purposes of dot configuration. (Code comment would be nice.) If so, dot-column may run on rests before rest-collision sets their final positions. This would be good, because then rest-collision would be free to avoid beams and stems. (Comments in that code warn us to try not to look at the stem.) http://codereview.appspot.com/5538049/diff/4002/lily/dot-column.cc File lily/dot-column.cc (right): http://codereview.appspot.com/5538049/diff/4002/lily/dot-column.cc#newcode216 lily/dot-column.cc:216: // do the X-offset properly. Might this comment now be obsolete? It is about the fix to issue 1088. If so, we could unravel some of this complication, later. http://codereview.appspot.com/5538049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)
Hi Patrick, your patch was pushed when i was absent; now i see that Rietveld issue is still opened. Could you close it please? http://codereview.appspot.com/5096050/ Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 19:47:10, Keith wrote: LGTM On 2012/01/15 08:05:35, Graham Percival wrote: With this recipe, the broken-staging will be in the developer's personal dev/cg branch. Is there any way we can avoid this? 1) We could accept it as a consequence of re-writing the public history on origin/staging. When the developer does his next rebase -i he should recognize that some commits are not his, and remove them from the rebase --or test them and fix the problem that forced the rewind of staging. But we should not have all developers have to suffer from one developer's mistake on staging, when there is an easy way around it. 2) We could introduce both 'merge' and 'rebase' in the guide: git checkout staging git reset --hard origin/staging # reset local staging to the repository git merge dev/cg # bring your new commits into local staging git rebase -i origin/staging # rewrite local history to put the new commits last gitk # check that the commits look as you intended git push origin/staging This would work, as long as the developer is completely aware of which commits are his and which are not. As long as the developer has abided by the one commit per patch rule, it's easy. On 2012/01/15 13:37:13, Carl wrote: git rebase origin/staging dev/cg~0 git push origin HEAD:staging 3) The example above is certainly shorter. I find it difficult to understand. It implicitly checks out the last commit in dev/cg (leaving git not on any branch). I would not have guessed that this would be supported, based on `man git rebase`. Then the command rebases that non-on-any-branch history to origin/staging and pushes that history to the repository. It leaves git in the state of being not on any branch. Yes, but I wouldn't leave it in that state. The full set of commands is git rebase origin/staging dev/cg~0 git push origin HEAD:staging git checkout dev/cg At this point, you have pushed dev/cg to staging without polluting dev/cg with staging. And you can continue to rebase dev/cg with master as needed/desired. You never have to worry about accidentally putting some reverted commit back into staging. It's completely foolproof. The examples for the guide are intended to be copy and pastable, not necessarily to teach how to use git in general. Working commands that do what we want should be preferred to commands that require a developer to follow through some steps and make it right. The way I've actually recovered commits from broken staging in the past is with cherry-picks. But those weren't my commits. Even if they were mine, probably a new branch and cherry-picking off the broken staging is easier/cleaner than rebase -i. But the incomprehensible set of commands works perfectly on a detached head, and leaves the rebased tree in garbage collection where it will eventually be automatically eliminated, which is the appropriate place. I think it is the right set of commands. Thanks, Carl I think (2) is the best example for the guide. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 14:54:22, dak wrote: An occasional git rebase origin dev/cg (which permanently rebases dev/cg on origin/master which we don't reset ever by gentlemen's agreement, meaning that if somebody does that, everybody else stops being a gentleman) should take care that most of the work needs to be done just once. My thoughts (almost) exactly. My set of commands would be git checkout dev/cg git rebase origin/master which does exactly the same thing, only with different words. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120117
For Tuesday, January 17th, 2012 Critical: Issue 2180 http://code.google.com/p/lilypond/issues/detail?id=2180: beams are detached from stems - R 5538049 http://codereview.appspot.com/5538049/ Enhancement: Issue 1846 http://code.google.com/p/lilypond/issues/detail?id=1846: Improves horizontal spacing of axis groups that SpanBar grobs traverse - R 5528081 http://codereview.appspot.com/5528081/ Issue 2177 http://code.google.com/p/lilypond/issues/detail?id=2177: Patch: Reverts public interface for simple spacer - R 5511044 http://codereview.appspot.com/5511044/ Issue 2200 http://code.google.com/p/lilypond/issues/detail?id=2200: Dots shouldn't always be placed in one column - R 4293054 http://codereview.appspot.com/4293054/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs: Explain the difference between ritardando and rallentando (issue 5544075)
LGTM. Seems like this can be pushed as soon as it gets approved by Patchy. No need for a countdown, IMO. http://codereview.appspot.com/5544075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes.tely: mention Flag changes, remove duplicate does (issue 5540058)
Looks good to me, but I wonder about the location. Thanks, Carl http://codereview.appspot.com/5540058/diff/1/Documentation/changes.tely File Documentation/changes.tely (right): http://codereview.appspot.com/5540058/diff/1/Documentation/changes.tely#newcode210 Documentation/changes.tely:210: @item I'm a bit concerned about adding this down here. Somebody who is only tracking the top of CHANGES wil miss this. I assume (but haven't checked) that this is in the right place relative to the other changes. I'd like to get some other opinions about it -- should it go here or at the top? http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes.tely: mention Flag changes, remove duplicate does (issue 5540058)
Looks good to me, but I wonder about the location. Thanks, Carl http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for DotColumn not triggering vertical alignment. (issue 5538049)
Reviewers: lemzwerg, carl.d.sorensen_gmail.com, Keith,
http://codereview.appspot.com/5538049/diff/1/lily/staff-symbol-referencer.cc
File lily/staff-symbol-referencer.cc (right):
http://codereview.appspot.com/5538049/diff/1/lily/staff-symbol-referencer.cc#newcode95
lily/staff-symbol-referencer.cc:95: Real y = (pure
On 2012/01/12 11:02:13, lemzwerg wrote:
The outermost parentheses have no effect. I suggest to remove them.
They're for code alignment purposes: it's so that the ? and : don't
align vertically with the -. There are a couple other places in the
code that use this convention (forget where).
http://codereview.appspot.com/5538049/diff/4002/lily/dot-column.cc
File lily/dot-column.cc (right):
http://codereview.appspot.com/5538049/diff/4002/lily/dot-column.cc#newcode216
lily/dot-column.cc:216: // do the X-offset properly.
On 2012/01/15 21:45:27, Keith wrote:
Might this comment now be obsolete? It is about the fix to issue
1088. If so,
we could unravel some of this complication, later.
It very well could be. After this patch is pushed, remind me to
investigate this (I'm writing myself a reminder as well).
Description:
Sketch for DotColumn not triggering vertical alignment.
Please review this at http://codereview.appspot.com/5538049/
Affected files:
A input/regression/dot-column-vertical-positioning.ly
M lily/dot-column.cc
M lily/include/staff-symbol-referencer.hh
M lily/staff-symbol-referencer.cc
Index: input/regression/dot-column-vertical-positioning.ly
diff --git a/input/regression/dot-column-vertical-positioning.ly
b/input/regression/dot-column-vertical-positioning.ly
new file mode 100644
index
..e609c7b4d03b6642f8352127501cb3e2ae8f208d
--- /dev/null
+++ b/input/regression/dot-column-vertical-positioning.ly
@@ -0,0 +1,13 @@
+\version 2.15.24
+
+\header {
+ texidoc = Dot columns should not trigger vertical spacing before
+line breaking. If the regtest issues a programming_error saying that
+vertical spacing has been called before line breaking, it has failed.
+
+}
+
+\context Staff
+ \new Voice { \voiceOne f''8.[ e''16] }
+ \new Voice { \voiceThree r8. a'16}
+
Index: lily/dot-column.cc
diff --git a/lily/dot-column.cc b/lily/dot-column.cc
index
2292d2fe0999b295623f8f9a064d7b96d90f1560..03f368d76b50703cd49055d54820417ec3248f63
100644
--- a/lily/dot-column.cc
+++ b/lily/dot-column.cc
@@ -143,7 +143,14 @@ Dot_column::calc_positioning_done (SCM smob)
}
}
- vector_sort (dots, position_less);
+ /*
+The use of pure_position_less and pure_get_rounded_position below
+are due to the fact that this callback is called before line breaking
+occurs. Because dots' actual Y posiitons may be linked to that of
+beams (dots are attached to rests, which are shifted to avoid beams),
+we instead must use their pure Y positions.
+ */
+ vector_sort (dots, pure_position_less);
for (vsize i = dots.size (); i--;)
{
if (!dots[i]-is_live ())
@@ -170,7 +177,7 @@ Dot_column::calc_positioning_done (SCM smob)
dp.x_extent_ = note-extent (commonx, X_AXIS);
}
- int p = Staff_symbol_referencer::get_rounded_position (dp.dot_);
+ int p = Staff_symbol_referencer::pure_get_rounded_position (dp.dot_);
/* icky, since this should go via a Staff_symbol_referencer
offset callback but adding a dot overwrites Y-offset. */
@@ -191,7 +198,7 @@ Dot_column::calc_positioning_done (SCM smob)
/*
Junkme?
*/
- Staff_symbol_referencer::set_position (i-second.dot_, i-first);
+ Staff_symbol_referencer::pure_set_position (i-second.dot_,
i-first);
}
me-translate_axis (cfg.x_offset () - me-relative_coordinate (commonx,
X_AXIS),
Index: lily/include/staff-symbol-referencer.hh
diff --git a/lily/include/staff-symbol-referencer.hh
b/lily/include/staff-symbol-referencer.hh
index
a3dd915c9ab85a96aed0986850f2091fdfbda3bb..179bae828f6905339b16ffa2757e67b9fb87fa12
100644
--- a/lily/include/staff-symbol-referencer.hh
+++ b/lily/include/staff-symbol-referencer.hh
@@ -33,6 +33,7 @@ public:
DECLARE_GROB_INTERFACE ();
static bool ugly_hack (Grob *);
static void set_position (Grob *, Real);
+ static void pure_set_position (Grob *, Real);
DECLARE_SCHEME_CALLBACK (callback, (SCM element));
/**
@@ -46,12 +47,19 @@ public:
static bool on_staff_line (Grob *, int);
static int line_count (Grob *);
static Real get_position (Grob *);
+ static Real pure_get_position (Grob *);
static Real staff_radius (Grob *);
static int get_rounded_position (Grob *);
+ static int pure_get_rounded_position (Grob *);
static Interval extent_in_staff (Grob *);
+
+private:
+ static void internal_set_position (Grob *, Real, bool);
+ static Real internal_get_position (Grob *, bool);
};
int compare_position (Grob *const , Grob *const );
bool position_less (Grob *const , Grob *const );
+bool pure_position_less (Grob *const ,
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/15 23:15:01, Carl wrote: On 2012/01/15 14:54:22, dak wrote: git rebase origin dev/cg My thoughts (almost) exactly. My set of commands would be git checkout dev/cg git rebase origin/master which does exactly the same thing, only with different words. I think it reaches the same work directory state, but possibly touching fewer files. If you have recently worked with something closer to master than dev/cg, that might save rebuild time. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On Sun, Jan 15, 2012 at 11:12:49PM +, carl.d.soren...@gmail.com wrote: Yes, but I wouldn't leave it in that state. The full set of commands is git rebase origin/staging dev/cg~0 git push origin HEAD:staging git checkout dev/cg LGTM At this point, you have pushed dev/cg to staging without polluting dev/cg with staging. And you can continue to rebase dev/cg with master as needed/desired. You never have to worry about accidentally putting some reverted commit back into staging. It's completely foolproof. +1 The examples for the guide are intended to be copy and pastable, not necessarily to teach how to use git in general. Working commands that do what we want should be preferred to commands that require a developer to follow through some steps and make it right. +10 - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
