PATCH: Countdown to 20120126

For 20:00 MST or so, Thursday January 26, 2012 Documentation: Issue 2189 : Doc: NR add to \partial for clearer understanding - R 5520056 Issue 2248

Re: Glyphs for Kievan Notation (issue 4951062)

On 2012/01/25 00:01:16, aleksandr.andreev wrote: I'm getting the error described above by Julien when running make test. I guess I have to wait for that patch to be pushed. If you time `texi2html --help' in your terminal, what do you see next to the --error-limit line? For me, it says 1000, w

Re: Glyphs for Kievan Notation (issue 4951062)

There is a difference, compare the position of "kievan" markups in pdfs Ah, OK, I see it now. You've forgotten about one char_box, see below. I fixed this one as well as the char_box for the clef. I've run make and regtests from scratch on a freshly-updated source. I'm getting the error

Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)

http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc File lily/music-scheme.cc (right): http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc#newcode79 lily/music-scheme.cc:79: "Is @var{obj} a proper (non-rhythmic) event object?") On 2012/01/24 22:47:32, Neil Put

Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)

On 2012/01/24 22:47:31, Neil Puttock wrote: Great work David. I like how \harmonic works properly for single notes now. :) As opposed to an earlier version of the patch or to LilyPond's previous behavior? All of your code comments are quite spot on and touch some sore spots that I decided wou

Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)

Great work David. I like how \harmonic works properly for single notes now. :) http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc File lily/music-scheme.cc (right): http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc#newcode79 lily/music-scheme.cc:79: "Is

Re: checking 2240

On 24/01/2012 6:35 AM, David Kastrup wrote: I think the pairing git apply --index filename.patch git reset --hard has less potential to go wrong if there is a problem at any time. I actually don't really understand why we bother with restoring the tree anyway instead of removing it and doing

Re: checking 2240

On Tue, Jan 24, 2012 at 05:33:28PM -0500, Julien Rioux wrote: > On 22/01/2012 2:50 PM, Graham Percival wrote: > > try: > > autoCompile.configure() > > autoCompile.patch(patch_filename) > > autoCompile.build(quick_make=True, > >issue_id=iss

Re: Glyphs for Kievan Notation (issue 4951062)

only one change left. On 2012/01/23 01:02:13, aleksandr.andreev wrote: Regarding comments by Jan: >> I guess it should be 2.5 staff_space or something I changed the depth and height parameters as you suggested. However, I do not see any difference, in the reg tests or in my test files. Are

Re: Implements rhythmic-music-iterator (issue 5554048)

"m...@apollinemike.com" writes: > On Jan 18, 2012, at 3:53 PM, d...@gnu.org wrote: > >> Where would be the point? If I plan to touch up the stream event before >> broadcasting it, I can't use the everything-included report_event >> anyway. If I plan to touch up the music event in a manner equiv

Re: reduced development time

"m...@apollinemike.com" writes: > On Jan 16, 2012, at 1:24 PM, Graham Percival wrote: > >> 2.15.26 is released, containing the fix for issue 1933 >> lilypond-book on windows. This marks the end of my active >> development work for the next ten weeks: until the end of March, I >> am reducing my l

Re: checking 2240

On 22/01/2012 2:50 PM, Graham Percival wrote: On Sun, Jan 22, 2012 at 08:43:26PM +0100, Janek Warchoł wrote: One quick question: Patchy checks patches one at a time, doesn't it? I.e. applies a patch (doesn't commit), tests, unapplies and moves to another patch? ... why are you asking this que

Re: somebody needs to run staging before 29 Jan

Janek Warchoł writes: >>  Keeping the staging-merge going would be about five people >> committing to 50€ a month.  That is, of course, not enough for me to >> live on.  It merely means that taking on this duty will not further >> reduce the amount of time I can spend on LilyPond in total. > > T

Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)

Hi Reinhold, On 2012/01/24 17:06:57, Reinhold wrote: What about --use-source-file-names? I just tested this. I used lilypond-book --use-source-file-names --output=out file1, where `file1' includes `file2'. In the output, we link to `file2', so that part looks correct. But the file `file2' is n

Re: Doc: NR Section on Upbeats made clearer (issue 5520056)

mostly LGTM http://codereview.appspot.com/5520056/diff/7001/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/5520056/diff/7001/Documentation/notation/rhythms.itely#newcode1358 Documentation/notation/rhythms.itely:1358: The @va

Re: Glyphs for Kievan Notation (issue 4951062)

On 2012/01/24 15:39:22, aleksandr.andreev wrote: Looks like it's complaining about a "Top" node in collated-files.texi and another "Top" node in papersize-docs.texi. This is reported here: http://code.google.com/p/lilypond/issues/detail?id=2223#c3 I fix for this is in review. Regards, Julien

Re: Doc: NR 5.5.5 Adv tweaks - Unpure-pure containers (issue 5569050)

On 2012/01/24 11:27:42, Graham Percival wrote: If you actually ran "make" and it didn't die, please report this as a build problem, because there's no way that makeinfo should have let this pass. Once issues 2219 is fixed, makeinfo will stop on the first error. Hopefully it considers undefine

Re: somebody needs to run staging before 29 Jan

2012/1/24 David Kastrup : > I'll hopefully will have received a new laptop by then, but it needs > more setup work than the last one (I can't just take over the hard disk > like previously, as it is ATA->SATA). > > It will be a Core duo, but still not really fast.  Obviously putting > myself respon

Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)

http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py File python/book_snippets.py (left): http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode806 python/book_snippets.py:806: self.ext = os.path.splitext (os.path.basename (self.filename))[1] On 2012/01/22 0

Re: Glyphs for Kievan Notation (issue 4951062)

- Original Message - From: To: ; ; ; ; ; ; ; ; ; ; ; Cc: ; Sent: Tuesday, January 24, 2012 3:39 PM Subject: Re: Glyphs for Kievan Notation (issue 4951062) When I go to make the regression tests, I get the following error message: texi2html --I=/home/sasha/lilypond-git/input/reg

Re: Glyphs for Kievan Notation (issue 4951062)

When I go to make the regression tests, I get the following error message: texi2html --I=/home/sasha/lilypond-git/input/regression/lilypond-book --I=./out-test -I /home/sasha/lilypond-git/Documentation --I=/home/sasha/lilypond-git/build/./out-test/xref-maps --init-file=/home/sasha/lilypond-git/Do

Re: somebody needs to run staging before 29 Jan

2012/1/24 Graham Percival : > In order to reduce our bus factor[1] -- especially considering the > distinctly non-zero possibility that I'll be gone at the end of > March -- somebody else needs to run the Patchy staging-merge > script.  To make this more presssing, I am refusing to run this > scrip

Re: somebody needs to run staging before 29 Jan

Graham Percival writes: > In order to reduce our bus factor[1] -- especially considering the > distinctly non-zero possibility that I'll be gone at the end of > March -- somebody else needs to run the Patchy staging-merge > script. To make this more presssing, I am refusing to run this > script

Re: checking 2240

David Kastrup writes: > Graham Percival writes: > >> On Tue, Jan 24, 2012 at 12:35:17PM +0100, David Kastrup wrote: >>> has less potential to go wrong if there is a problem at any time. I >>> actually don't really understand why we bother with restoring the tree >>> anyway instead of removing i

change bugreports expected response time (issue 5575047)

Reviewers: , Message: Graham noticed that we fail to examine bugreports in 24 hours, so let's change the information on website. http://lists.gnu.org/archive/html/lilypond-devel/2012-01/msg00839.html Description: change bugreports expected response time Please review this at http://codereview.

Re: user vs. user (was: User vs Developer: Round 2 (and half-time?)(was: Re: music font)

2012/1/24 Graham Percival : > Our published materials says "24 hours": > > [...] we should update that accordingly. http://codereview.appspot.com/5575047/ and stop worrying. :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org

Re: somebody needs to run staging before 29 Jan

2012/1/24 Graham Percival : > 1. more people need to know how to run the script. > (it's not hard; far easier than setting up apache) I'm working on Patchy with Julien. Please be patient - i have a few exams on university (last one on February 2nd). > On Tue, Jan 24, 2012 at 01:08:21PM +0100,

Re: checking 2240

Graham Percival writes: > On Tue, Jan 24, 2012 at 12:35:17PM +0100, David Kastrup wrote: >> has less potential to go wrong if there is a problem at any time. I >> actually don't really understand why we bother with restoring the tree >> anyway instead of removing it and doing the next test from

Re: somebody needs to run staging before 29 Jan

On Tue, Jan 24, 2012 at 01:08:21PM +0100, m...@apollinemike.com wrote: > >2. it would be good to have something in the CG about Patchy. > > ...you can do this. I have 3.5 hours remaining until Jan 29. Given how often we have emergencies come up, I think I need to reserve my time for those. If no

Re: user vs. user (was: User vs Developer: Round 2 (and half-time?)(was: Re: music font)

On Tue, Jan 24, 2012 at 12:27:56PM -, Phil Holmes wrote: > >Of course, a 96-hour reponse rate isn't precisely fantastic, but > >it's a start. > > Well - TBH time isn't of the essence as a general rule. Whether a > bug gets added to the tracker in one day or 3 rarely affects the > overall deve

Re: user vs. user (was: User vs Developer: Round 2 (and half-time?)(was: Re: music font)

- Original Message - From: "Graham Percival" To: "Janek Warchoł" Cc: ; "lilypond-user" Sent: Tuesday, January 24, 2012 11:57 AM Subject: user vs. user (was: User vs Developer: Round 2 (and half-time?)(was: Re: music font) Let's take a look at the current statistics, shall we? htt

Re: somebody needs to run staging before 29 Jan

1. more people need to know how to run the script. (it's not hard; far easier than setting up apache) I can do this if... 2. it would be good to have something in the CG about Patchy. ...you can do this. I also think that Patchy needs to be part of the LilyPond source. Cheers, MS __

Re: User vs Developer: Round 2 (and half-time?)

Xavier Scheuer writes: > Dear Graham, dear Developers, > >> I did not crawl out of my mother's womb knowing about lilypond >> internals, or even about programming at all. Any knowledge I have >> was from hard work: reading source code, reading public emails on >> the list archives, and learning

somebody needs to run staging before 29 Jan

In order to reduce our bus factor[1] -- especially considering the distinctly non-zero possibility that I'll be gone at the end of March -- somebody else needs to run the Patchy staging-merge script. To make this more presssing, I am refusing to run this script myself after 29 Jan 2012. [1] http:

user vs. user (was: User vs Developer: Round 2 (and half-time?) (was: Re: music font)

On Tue, Jan 24, 2012 at 01:50:13AM +0100, Janek Warchoł wrote: > > 2012/1/23 Xavier Scheuer : > > why I never *demand* > > developers to fix an issue, even if it is one that is really annoying > > my ego in almost every score I typeset. > > One thing comes to my mind: you are talking about bugs t

Re: checking 2240

On Tue, Jan 24, 2012 at 12:35:17PM +0100, David Kastrup wrote: > has less potential to go wrong if there is a problem at any time. I > actually don't really understand why we bother with restoring the tree > anyway instead of removing it and doing the next test from a freshly > created > git clo

Re: checking 2240

Janek Warchoł writes: > Hi Julien, > > 2012/1/22 Julien Rioux : >> Hi Janek, >> The autoCompile.patch part is defined here: >> https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L140 >> >> You'll see that the code uses >> git apply filename.patch >> and >> git

Re: Doc: NR 5.5.5 Adv tweaks - Unpure-pure containers (issue 5569050)

very funny. http://codereview.appspot.com/5569050/diff/4001/Documentation/notation/changing-defaults.itely File Documentation/notation/changing-defaults.itely (right): http://codereview.appspot.com/5569050/diff/4001/Documentation/notation/changing-defaults.itely#newcode3721 Documentation/notati

Re: Doc: NR Section on Upbeats made clearer (issue 5520056)

looks mostly good. http://codereview.appspot.com/5520056/diff/7001/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/5520056/diff/7001/Documentation/notation/rhythms.itely#newcode1358 Documentation/notation/rhythms.itely:1358:

Re: Doc: NR Section on Upbeats made clearer (issue 5520056)

http://codereview.appspot.com/5520056/diff/1/Documentation/notation/rhythms.itely File Documentation/notation/rhythms.itely (right): http://codereview.appspot.com/5520056/diff/1/Documentation/notation/rhythms.itely#newcode1350 Documentation/notation/rhythms.itely:1350: partial measure @emph{befo