Re: Patchy email
2011/12/31 Carl Sorensen : > I suspect that we gave you commands that set it so your local staging > branch is tracking origin/master, rather than origin/staging. So *for > you*, staging is the same branch as origin/master. And I'm trying to > figure out how to diagnose this. > > For starters, can you look at the file .git/config (in your lilypond > source top-level directory)? > > Here are my entries: > > [remote "origin"] > url = carldsoren...@git.sv.gnu.org:/srv/git/lilypond.git > fetch = +refs/heads/*:refs/remotes/origin/* I have [remote "origin"] url = gnu:lilypond fetch = +refs/heads/*:refs/remotes/origin/* gnu: is a shortcut defined elsewhere. > [branch "master"] > remote = origin > merge = master « [branch "master"] remote = origin merge = refs/heads/master rebase = true » here. > [branch "staging"] > remote = origin > merge = refs/heads/staging Identical, here. > > I think the "merge = refs/heads/staging" line is the one that ties my > staging branch to origin/staging. > > > I suspect you may have the following: > > [branch "staging"] > remote = origin > merge = master No, I have [branch "staging"] remote = origin merge = refs/heads/staging > > Anyway, don't panic, and we'll get this figured out. > > Thanks, Thank you. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On 12/30/11 6:40 PM, "Francisco Vila" wrote: >2011/12/31 Carl Sorensen : >>> Begin LilyPond compile, commit: >>>2f25894efd8ad242b233d5a1d07afcfa087ebab2 >>> >>> *** FAILED STEP *** >>> >>> merge from staging >>> >>> maybe somebody pushed a commit directly to master? >> >> Francisco merged translation with staging, and apparently also with >>master. (The commit message says merge with staging, but the commit is >>on master and is the parent of staging. >> >> I suspect that we have not yet worked out the right way to deal with >>translations, and I don't know enough git to know what to recommend. >> >> David, any ideas? > >I performed a single 'merge lilypond/translation' command while on >staging. >Then I performed a single 'push origin staging' command. I have not >touched master. I did not 'git checkout master'. I did not push >master. I did not mention master on my keyboard or in my thoughts. I >have had nightmares about master in the past, but master is off my >life now. Master does not exist for me anymore. > >I suspect one way or another master and staging are the same thing, >which is not my fault. Please don't consider my email one of assigning blame, Francisco. You have a procedure that has worked for you for a long time. We changed that procedure. It's not yet worked out. The fault is in the procedure, not in the person. I suspect that we gave you commands that set it so your local staging branch is tracking origin/master, rather than origin/staging. So *for you*, staging is the same branch as origin/master. And I'm trying to figure out how to diagnose this. For starters, can you look at the file .git/config (in your lilypond source top-level directory)? Here are my entries: [remote "origin"] url = carldsoren...@git.sv.gnu.org:/srv/git/lilypond.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = master [branch "staging"] remote = origin merge = refs/heads/staging I think the "merge = refs/heads/staging" line is the one that ties my staging branch to origin/staging. I suspect you may have the following: [branch "staging"] remote = origin merge = master Anyway, don't panic, and we'll get this figured out. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: syntax highlighting in the docs (issue 1005)
On Thu, Dec 29, 2011 at 12:22:17PM +0100, Federico Bruni wrote: > I have a final draft (see files attached): > > I'm quite happy with this version. Given my time constraints, I am happy to trust you. I fully expect that you'll get complaints whenever this makes its way into the actual docs, but that's just the nature of the process. I assume that you can send an update to source-highlight in 3 months when problems are identified then? > Please let me know if you spot any error or missing item. > I'll send a patch to source-highlight in about a week. Sounds like a good plan. If you want to gather more feedback before then, you could try sending this to -user as well -- I think that's much more likely to get curious onlookers testing it. Lilypond developers tend to have so much overwork that we rarely go out of our way to look at stuff we don't need to. Janek, Valentin: despite what I just said, you two might really enjoy playing with the source highlighting. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes ugly side bars from learning (issue 5498089)
On Fri, Dec 30, 2011 at 01:12:30PM -, Phil Holmes wrote: > >I'm not too fussed about that, but the second line should be indented by > >two spaces to indicate that it's a continuation of the previous line > >(i.e. not starting its own bar). I certainly wouldn't object to having > >an explicit duration, though! > > No problem. This isn't covered in the CG, AFAICS. Yeah, it's part of the unofficial "policy" that I never got around to writing down. Sorry. > >I'm not fond of having an explicit line-width. Could this be done by > >either editing the snippet, or giving a papersize option instead? > > It's taken me far too long to work out what's going on here. ---snip issues 776 and 1691--- > My suggestion is to use an explicit line-width with a > comment above saying something like "@c Line-width is used below > because of Issue 766. If that's fixed, it can be removed.". ok, let's do that. > If we wait for issues like that to be fixed to improve the docs, > we could have grotty looking docs forever... True. It's a shame that there isn't more interest in working on "maintainability" problems, but that's just how things are. > >Please make this an > >@example > > OK - willdo. Just think all the boxes are a bit unnecessary. I'd be fine with distinguishing between "quick url box" and "lilypond material box". I'd like it if the url was indentend on its own line, but didn't have the yellow box. ETA: 1 hour if you know what you're doing with texinfo and css; otherwise 10 hours of frustration. (could you add this as a tracker issue so we don't forget?) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
2011/12/31 Carl Sorensen : >> Begin LilyPond compile, commit: 2f25894efd8ad242b233d5a1d07afcfa087ebab2 >> >> *** FAILED STEP *** >> >> merge from staging >> >> maybe somebody pushed a commit directly to master? > > Francisco merged translation with staging, and apparently also with master. > (The commit message says merge with staging, but the commit is on master and > is the parent of staging. > > I suspect that we have not yet worked out the right way to deal with > translations, and I don't know enough git to know what to recommend. > > David, any ideas? I performed a single 'merge lilypond/translation' command while on staging. Then I performed a single 'push origin staging' command. I have not touched master. I did not 'git checkout master'. I did not push master. I did not mention master on my keyboard or in my thoughts. I have had nightmares about master in the past, but master is off my life now. Master does not exist for me anymore. I suspect one way or another master and staging are the same thing, which is not my fault. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB help
On 11-12-30 12:22 AM, Graham Percival wrote: On Fri, Dec 30, 2011 at 06:12:58AM +, Carl Sorensen wrote: More information: When I ran the command by hand, I got this message: carl@carl-lilydev:~/gub/target/darwin-ppc/build/cross/gcc-4.1.1$ make tooldir='/usr/powerpc-apple-darwin7' gcc_tooldir='/usr/powerpc-apple-darwin7' Be aware that GUB will have set up certain additional things, such as a PATH (which includes the relevant .../target/.../bin/ dir), and possibly even a chroot. The use of /usr/ in there (instead of .../usr/ ) suggests a chroot to me. For a "smaller reproducible step", I'd go with something like python bin/gub darwin-ppc::gcc I think there's some vague hints about this in the README. Cheers, - Graham For additional data points: I've built an Ubuntu 10.04 VM and used GUB to build 2.15.24, which seems to work correctly, in that it produced an installer which in turn gave me a copy of lilypond that can compile .ly and which reports itself as version 2.15.24 in response to lilypond -v. Like Carl, I can't get GUB working on Ubuntu 11.x (tested 11.04 and 11.10 x86-64, and 11.10 x86-32), nor on Fedora 15 x86-64, all of which seem to use gcc 4.6, IIRC. My latest attempt on the Fedora VM fails while building python 2.4: Command barfed: cd /home/colin/gub/target/tools/build/python-2.4.5 && make BLDLIBRARY='-Wl,-rpath -Wl,\$$ORIGIN/../lib -Wl,-rpath -Wl,/home/colin/gub/target/tools/root/usr/lib -L. -lpython$(VERSION)' DESTDIR=/home/colin/gub/target/tools/install/python-2.4.5-root install Tail of target/tools/log/python.log python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h python: error while loading shared libraries: libpython2.4.so.1.0: cannot open shared object file: No such file or directory make: *** [/home/colin/gub/target/tools/src/python-2.4.5/Lib/plat-linux3] Error 127 Command barfed: cd /home/colin/gub/target/tools/build/python-2.4.5 && make BLDLIBRARY='-Wl,-rpath -Wl,\$$ORIGIN/../lib -Wl,-rpath -Wl,/home/colin/gub/target/tools/root/usr/lib -L. -lpython$(VERSION)' DESTDIR=/home/colin/gub/target/tools/install/python-2.4.5-root install Tail of target/tools/log/python.log The "missing" file, libpython2.4.so.1.0 seems to be in /home/colin/gub/target/tools/build/python-2.4.5 so I'm missing something, too. Another datum is the /plat-linux3 directory just before the make error 127: GUB is seeing the host system, which seems to be many rev levels ahead of the GUB platform itself. I had thought GUB would build itself a self-contained chroot, in which case the host system upgrades shouldn't be a factor, but that may not in fact be the case. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On Sat, Dec 31, 2011 at 12:10:14AM +, carl.d.soren...@gmail.com wrote: > On 2011/12/30 20:57:02, Graham Percival wrote: > >I'm still concerned about this type of automatic pushing. The revised > CG > >material on branches > > http://codereview.appspot.com/5484043/ > >makes a bit deal about always checking gitk -- just for 5 seconds -- > before > >pushing, and I think that's a good step. Patchy will not question any > > I think I can achieve that automatically by looking at the commit log > between staging and working. If there are no merge commits in that log, > we are good to push IIUC. Hmm. Could I interest you in adding some checks to Patchy? I'd rather have that complexity in Patchy rather than lily-git.tcl -- that way, it doesn't matter if anything weird happens on a command-line or within lily-git; we're still protected. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Patchy email
> From: lilypond-devel-bounces+c_sorensen=byu@gnu.org [lilypond-devel- > bounces+c_sorensen=byu@gnu.org] on behalf of > lilypond.patchy.gra...@gmail.com > [lilypond.patchy.gra...@gmail.com] > Sent: Friday, December 30, 2011 5:21 PM > To: gra...@percival-music.ca > Cc: lilypond-devel@gnu.org > Subject: Patchy email > > Begin LilyPond compile, commit: 2f25894efd8ad242b233d5a1d07afcfa087ebab2 > > *** FAILED STEP *** > > merge from staging > > maybe somebody pushed a commit directly to master? Francisco merged translation with staging, and apparently also with master. (The commit message says merge with staging, but the commit is on master and is the parent of staging. I suspect that we have not yet worked out the right way to deal with translations, and I don't know enough git to know what to recommend. David, any ideas? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
Begin LilyPond compile, commit: 2f25894efd8ad242b233d5a1d07afcfa087ebab2 *** 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: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2011/12/30 20:57:02, Graham Percival wrote: LGTM apart from one detail http://codereview.appspot.com/5504092/diff/5001/scripts/auxiliar/lily-git.tcl#newcode295 scripts/auxiliar/lily-git.tcl:295: git push origin HEAD:$pushHead I'm still concerned about this type of automatic pushing. The revised CG material on branches http://codereview.appspot.com/5484043/ makes a bit deal about always checking gitk -- just for 5 seconds -- before pushing, and I think that's a good step. Patchy will not question any I think I can achieve that automatically by looking at the commit log between staging and working. If there are no merge commits in that log, we are good to push IIUC. I ought to be able to check for that automatically and only do the push if there are no problems. I'll try to cook a revised patch in a bit. Thanks for the review. Carl http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20111224
2011/12/23 Colin Campbell : > For 22:00 MST Saturday The Night Before Christmas > > Enhancement: > Issue 2109: do not tinker with the position of a pitched rest - R > 5434061 could someone with push rights push this? thanks, p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
On 2011/12/30 20:57:02, Graham Percival wrote: Patchy will not question any ridiculous git history that arises due to any kind of weird series of commands in git. Maybe it would make sense if Patchy refused fast forwarding over a history involving a merge _from_ staging. I think that merges should just be from master; a merge from staging implies a merging pull, and I can't think of a situation where we would want to see those in the history of master. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Adds barNumberVisibility regtest (issue 5501088)
LGTM, please push directly to staging. oh -- was the bar numbers patch included in 2.15.23 ? if so, then technically the version string should be that, not .24. Doesn't really matter either way, though. http://codereview.appspot.com/5501088/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update lilygit.tcl (Issue 2092) (issue 5504092)
LGTM apart from one detail http://codereview.appspot.com/5504092/diff/5001/scripts/auxiliar/lily-git.tcl File scripts/auxiliar/lily-git.tcl (right): http://codereview.appspot.com/5504092/diff/5001/scripts/auxiliar/lily-git.tcl#newcode295 scripts/auxiliar/lily-git.tcl:295: git push origin HEAD:$pushHead I'm still concerned about this type of automatic pushing. The revised CG material on branches http://codereview.appspot.com/5484043/ makes a bit deal about always checking gitk -- just for 5 seconds -- before pushing, and I think that's a good step. Patchy will not question any ridiculous git history that arises due to any kind of weird series of commands in git. http://codereview.appspot.com/5504092/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates non-negative-integer? predicate. (issue 5501081)
On 2011/12/30 19:15:57, Graham Percival wrote: I'm sorry to throw my hat in the ring so late, but I prefer something explicit like non-negative-integer? I mean, the name tells it all. What is this function doing? It's checking whether something is a non-negative integer. If it's called count? then somebody might need to look up the docstring to see what it's doing. It's great to have accurate documentation, but IMO it's better if the language naming doesn't require any documentation at all. Mathematically, we could call it Z+*? but that doesn't really fit into scheme names. According to wolfram alpha, the english name for Z+* is "nonnegative integers". The point is that the respective properties are used as counts or indexes. The axioms that you care for here are the Peano axioms. "non-negative integers" starts with the set defined by the _integer_ axioms, then takes a subset. That this subset is isomorphic to the naturals is an amazing thing, but it is an indirect relation. Talking about "non-negative integers" when we are talking about contexts where the ring of integers does not make any particular sense, and negative integers are completely absurd, is distracting. It is like talking about preserving non-human primates in the rain forest when you mean apes. It does not make sense to demand a degree in mathematics for being allowed to make sense of programs. http://codereview.appspot.com/5501081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Creates non-negative-integer? predicate. (issue 5501081)
I'm sorry to throw my hat in the ring so late, but I prefer something explicit like non-negative-integer? I mean, the name tells it all. What is this function doing? It's checking whether something is a non-negative integer. If it's called count? then somebody might need to look up the docstring to see what it's doing. It's great to have accurate documentation, but IMO it's better if the language naming doesn't require any documentation at all. Mathematically, we could call it Z+*? but that doesn't really fit into scheme names. According to wolfram alpha, the english name for Z+* is "nonnegative integers". http://codereview.appspot.com/5501081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes ugly side bars from learning (issue 5498089)
- Original Message -
From:
To: ; ;
; ;
Cc: ;
Sent: Thursday, December 29, 2011 6:01 PM
Subject: Re: Removes ugly side bars from learning (issue 5498089)
http://codereview.appspot.com/5498089/diff/1/Documentation/learning/common-notation.itely
File Documentation/learning/common-notation.itely (right):
http://codereview.appspot.com/5498089/diff/1/Documentation/learning/common-notation.itely#newcode853
Documentation/learning/common-notation.itely:853: \>[ ]\! |
On 2011/12/29 13:42:10, J_lowe wrote:
If we're breaking a line then should we re-state the duration.
I.e. 8\>[
I'm not too fussed about that, but the second line should be indented by
two spaces to indicate that it's a continuation of the previous line
(i.e. not starting its own bar). I certainly wouldn't object to having
an explicit duration, though!
No problem. This isn't covered in the CG, AFAICS.
http://codereview.appspot.com/5498089/diff/1/Documentation/learning/templates.itely
File Documentation/learning/templates.itely (right):
http://codereview.appspot.com/5498089/diff/1/Documentation/learning/templates.itely#newcode162
Documentation/learning/templates.itely:162:
@lilypondfile[verbatim,quote,ragged-right,texidoc,line-width=140]
On 2011/12/29 13:42:10, J_lowe wrote:
Is any merit in preference to editing the snippet than forcing the
issue in the
Tex code within the itely file?
I'm not fond of having an explicit line-width. Could this be done by
either editing the snippet, or giving a papersize option instead?
I still think that it's a general bug if non-insane .ly code exceeds the
bounds of the box, but I can't remember where we ended up in those
bugfixes Reinhold was doing IIRC half a year ago.
It's taken me far too long to work out what's going on here. It's our old
friend instrument names. Both the templates cited have material stretching
to the right of the "page" as well as non-zero-length instrument names. See
http://code.google.com/p/lilypond/issues/detail?id=1691 and
http://code.google.com/p/lilypond/issues/detail?id=766. So it is a bug, but
I don't think we should allow a bug to mess up what the LM looks like. My
suggestion is to use an explicit line-width with a comment above saying
something like "@c Line-width is used below because of Issue 766. If that's
fixed, it can be removed.". If we wait for issues like that to be fixed to
improve the docs, we could have grotty looking docs forever...
FWIW it can be "fixed" by using papersize A6, but this leaves the example
rather too narrow - line-width produces better looking results, since it's
more easily adjusted.
http://codereview.appspot.com/5498089/diff/1/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):
http://codereview.appspot.com/5498089/diff/1/Documentation/learning/tweaks.itely#newcode4022
Documentation/learning/tweaks.itely:4022:
@file{@var{INSTALLDIR}/LilyPond.app/Contents/Resources/share/lilypond/current/}
Please make this an
@example
instead. The @* syntax is really icky; I think we should only use it if
there's no other way of getting what we want (i.e. forcing a line-break
inside a @warning{} macro, which unfortunately does not allow normal
line breaks).
http://codereview.appspot.com/5498089/
OK - willdo. Just think all the boxes are a bit unnecessary.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
