PATCH: Countdown to 20120124

For 20:00 Tuesday, January 24, 2012 Critical: Issue 2240 : Patch: Don't wrap EventChord around rhythmic events by default. - R 5440084 Documentation: Issue 2238

PATCH: Countdown completed

With my apologies for clearing the "send email" flag on the individual issues, the following have had their countdown, and are ready to push: 2231 Critical mtsolo Tuplet bracket makes space for dynamic but dynamic is placed underneath bracket 2228 Critical Carl.D.Sorensen

Re: Glyphs for Kievan Notation (issue 4951062)

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 we sure that the entire glyph has to fit within the char_box, including the "

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

This is a split reply from the thread "music font". http://lists.gnu.org/archive/html/lilypond-devel/2012-01/msg00752.html The title is a reference to the fist "Users versus developers" flame war of which I appear to be also at the origin. http://lists.gnu.org/archive/html/lilypond-user/2009-05/msg

Re: a patch for Patchy (was: Re: checking 2240)

2012/1/22 Janek Warchoł : > suggested changes for Patchy, which should help dealing with untracked files > like in issue 2240, are here: > https://github.com/janek-warchol/lilypond-extra/commit/301c42579299d62fb24af4fa0ea950b158649da3 This patch fails, Patchy exits with lily@gperciva-desktop:~/s

Re: 2.16 release candidate 3 imminent

On 12-01-22 10:19 AM, Graham Percival wrote: On Sun, Jan 22, 2012 at 11:25:39AM -0500, Julien Rioux wrote: Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. That's

a patch for Patchy (was: Re: checking 2240)

Hi, i don't see a way to create a patch file using github, so i've send Graham a pull request and i hope it will be ok. The changes i suggest can be seen here: https://github.com/janek-warchol/lilypond-extra/commit/301c42579299d62fb24af4fa0ea950b158649da3 Graham, if you don't want to bother about

Re: checking 2240

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 apply --reverse filename.patch > > I

Re: make doc problem

Hello, On 22 January 2012 20:05, David Kastrup wrote: > Julien Rioux writes: > >> Thanks, you're quite right CPU is not the limiting factor for the >> build. Disk access and usage of swap when compiling >> input/regression/collated-files slows down the build to a crawl for >> me. > > If it is re

Re: checking 2240

On 22/01/2012 3:00 PM, Janek Warchoł wrote: 2012/1/22 Graham Percival: why are you asking this question? Is the source code really *that* hard to read? It's 18 lines! Hey, i'm not a pro programmer. There are so many brilliant programmers here that my self-confidence is quite low; this is se

Re: checking 2240

2012/1/22 Graham Percival : > why are you asking this question?  Is the source code really > *that* hard to read?  It's 18 lines! Hey, i'm not a pro programmer. There are so many brilliant programmers here that my self-confidence is quite low; this is second time i read Python and first time i re

Re: make doc problem

On 22/01/2012 2:38 PM, David Kastrup wrote: Julien Rioux writes: I can't run -j, I have a single core. This is factually incorrect. You can run -j just fine, but you can't expect much of a speedup. On a single-core machine, make -j 2 typically gives you a speedup of maybe 15% (given suff

Re: checking 2240

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 question? Is the source code really *that* har

Re: make doc problem

Le 22/01/2012 20:22, Julien Rioux disait : On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en re

Re: checking 2240

On Sun, Jan 22, 2012 at 08:16:59PM +0100, Janek Warchoł wrote: > 2012/1/22 Graham Percival : > > Ideally you'd create a github account > > Done: > janek-warchol > > > and then I can let you push directly. > > No review? I hope i won't screw anything up. ok, you have push ability now. You don'

Re: checking 2240

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? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/

Re: make doc problem

On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez Lily

Re: checking 2240

2012/1/22 Graham Percival : > On Sun, Jan 22, 2012 at 07:58:09PM +0100, Janek Warchoł wrote: >> i'm preparing a patch addressing David's advice, but i haven't >> found how patches for Patchy are announced, reviewed and pushed.  Do i >> need to create a github account? > > Ideally you'd create a git

Re: make doc problem

On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and "make -j3 doc LANGS='fr'"

Re: make doc problem

Le 22/01/2012 19:32, Julien Rioux disait : On 22/01/2012 1:19 PM, Jean-Charles Malahieude wrote: Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), [...] I can't run -j, I have a single core. Can you please report more precisely why you can no long

Re: make doc problem

On 22/01/2012 1:32 PM, Julien Rioux wrote: The second issue I have not seen. If I correct a typo in a file in Documentation then make doc will rebuild it. OK I should check Documentation/fr right now... When I edit Documentation/fr/essay/literature.itely and issue a make doc from within build

Re: checking 2240

On Sun, Jan 22, 2012 at 07:58:09PM +0100, Janek Warchoł wrote: > In an old e-mail i've found a link to what looks like Patchy source code > https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py Correct. > and i'm preparing a patch addressing David's advice, but i

Re: checking 2240

Hi, 2012/1/22 David Kastrup : > Graham Percival writes: >> With respect to this patch, you have 4 options: >> - modify Patchy to do the appropriate build stuff. >> - recruit somebody else to modify Patchy for you. >> [...] > > [Patchy's automated testing got confused by stale files in its work

Re: make doc problem

- Original Message - From: "Julien Rioux" To: "Phil Holmes" Cc: "Jean-Charles Malahieude" ; "LilyPond Bugs" ; "LilyPond Devel" Sent: Sunday, January 22, 2012 6:35 PM Subject: Re: make doc problem On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this a

Re: make doc problem

On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes I've hit a roadblock with issue 2125 which attempted to fix

Re: make doc problem

On 22/01/2012 1:19 PM, Jean-Charles Malahieude wrote: Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), which means 40' for a "make doc LANGS='fr' and about 2 hours for all languages, I now have to "make doc-clean" in order to view a corrected typo. I

Re: make doc problem

- Original Message - From: "Jean-Charles Malahieude" To: "Lily Bugs" ; "lilypond-devel" ; "Julien Rioux" Sent: Sunday, January 22, 2012 6:19 PM Subject: make doc problem Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), which means 40' f

Re: Glyphs for Kievan Notation (issue 4951062)

http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284 lily/stem.cc:284: string style = robust_symbol2string (heads[0]->get_property ("style"), "default"); I think Aleksandr is right. See h

make doc problem

Hi all! Not only that I can no longer use "-j" on a first build (it is OK on the next builds), which means 40' for a "make doc LANGS='fr' and about 2 hours for all languages, I now have to "make doc-clean" in order to view a corrected typo. I've tried a "touch masterfile.tely" before "make doc" b

Some notes on 2240

I am currently writing a talk paper on "recent developments in LilyPond" which contains a few developments that have not in good conscience happened on more than my computer. I don't want to hold up 2240 on them, however. I currently have commit 8180dc91c26431e05913576cedfb9d92d64ce439 Author:

Re: 2.16 release candidate 3 imminent

On Sun, Jan 22, 2012 at 11:25:39AM -0500, Julien Rioux wrote: > Well, as it turns out, I could not find any version on the website > where those regtests looked normal. It looks like the lilypond-book > regtests had not been checked in a long time. That's what I suspected. > I also could not be >

Re: Fix issue 2228: Add option for strictBeatBeaming (issue 5556054)

LGTM. I'm not sure if the word "flags" should be used here. http://codereview.appspot.com/5556054/diff/2001/input/regression/beamlet-point-toward-beat.ly File input/regression/beamlet-point-toward-beat.ly (right): http://codereview.appspot.com/5556054/diff/2001/input/regression/beamlet-point-t

Re: Fix beaming-pattern for compound meters (issue 5545067)

Hi Carl, is this patch obsolete and replaced by http://codereview.appspot.com/5556054 ? If so, please close this issue. thanks, Janek http://codereview.appspot.com/5545067/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/

Re: Spelling fixes in comments and documentation (issue 5562043)

All these changes are very minor and harmless. Changes in translated files lay on English comments. http://codereview.appspot.com/5562043/diff/1/Documentation/po/cs.po File Documentation/po/cs.po (right): http://codereview.appspot.com/5562043/diff/1/Documentation/po/cs.po#newcode10524 Documenta

Re: 2.16 release candidate 3 imminent

On 21/01/2012 2:48 PM, Graham Percival wrote: On Sat, Jan 21, 2012 at 02:28:15PM -0500, Julien Rioux wrote: I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: ok, good to know! I'm sure that you've done this already, but make su

Re: checking 2240

Graham Percival writes: > On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote: >> >> So please accept my apologies that I can't defend this patch further >> today. It does not mean that I am not serious about it, and I >> definitely believe that if Graham double-checks the comments on

Re: checking 2240 (was: 2.16 release candidate 3 imminent)

On Jan 22, 2012, at 12:44 PM, Graham Percival wrote: > > (I don't want to put Mike on the spot, but a week ago I sent > him this same email and he fixed the relevant problem in Patchy, > so he might be willing to modify Patchy for this) See spot run! Run spot run! I have compositions coming

checking 2240 (was: 2.16 release candidate 3 imminent)

On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote: > > So please accept my apologies that I can't defend this patch further > today. It does not mean that I am not serious about it, and I > definitely believe that if Graham double-checks the comments on this > patch, he'll find the re

Re: music-cause

Graham Percival writes: > On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote: >> >> Anybody actually using the "music-cause"? Inside of LilyPond, the only >> appearance (apart from its declaration) would be >> >> /* >> ES TODO: This is a temporary fix. Stream_events should not

Re: music-cause

On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote: > > Anybody actually using the "music-cause"? Inside of LilyPond, the only > appearance (apart from its declaration) would be > > /* > ES TODO: This is a temporary fix. Stream_events should not be > aware of music. > */ >

music-cause

Anybody actually using the "music-cause"? Inside of LilyPond, the only appearance (apart from its declaration) would be /* ES TODO: This is a temporary fix. Stream_events should not be aware of music. */ e->set_property ("music-cause", self_scm ()); It would likely have some minor

Re: 2.16 release candidate 3 imminent

I have to go in "hold the horses" mode now since I have a deadline for a LilyPond talk paper http://chemnitzer.linux-tage.de/2012/info/index?cookielang=en> coming up today (I already bargained an extension), and I need to get that finished in order to get it into print. So please accept my apolog

Re: 2.16 release candidate 3 imminent

David Kastrup writes: > David Kastrup writes: > >> David Kastrup writes: >> >>> If I write >>> myC = >>> #(define-music-function (parser location) () #{ c #}) >>> then I can't currently write >>> <\myC>4 or similar. It would just not work. And there is no way to >>> define this function, #{ #

Re: 2.16 release candidate 3 imminent

David Kastrup writes: > David Kastrup writes: > >> If I write >> myC = >> #(define-music-function (parser location) () #{ c #}) >> then I can't currently write >> <\myC>4 or similar. It would just not work. And there is no way to >> define this function, #{ #} or not, in a manner that could wo

Re: 2.16 release candidate 3 imminent

David Kastrup writes: > If I write > myC = > #(define-music-function (parser location) () #{ c #}) > then I can't currently write > <\myC>4 or similar. It would just not work. And there is no way to > define this function, #{ #} or not, in a manner that could work both in > chords as well as ou

Re: 2.16 release candidate 3 imminent

"m...@apollinemike.com" writes: > After reading through this e-mail, I'm ok with the patch with one > caveat about regtests (see below). > > On Jan 22, 2012, at 9:08 AM, David Kastrup wrote: > >> Music expressions _represent_ the input, as opposed to stream events >> which represent the typesetti

Re: 2.16 release candidate 3 imminent

Am 21.01.2012 20:17, schrieb Carl Sorensen: On 1/21/12 11:47 AM, "Marc Hohl" wrote: I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between < c\3 e\2 g\1> and< c e g>\3\2\1 once these changes are implemented? The latter wo

Re: 2.16 release candidate 3 imminent

On Jan 22, 2012, at 10:25 AM, David Kastrup wrote: > Please reread the above paragraph, in particular where I say "without a > music argument". Sorry - I missed that. This is exactly the type of function that I'd like to see in the regtests. Cheers, MS _

Re: 2.16 release candidate 3 imminent

"m...@apollinemike.com" writes: > After reading through this e-mail, I'm ok with the patch with one > caveat about regtests (see below). > > On Jan 22, 2012, at 9:08 AM, David Kastrup wrote: > >> Music expressions _represent_ the input, as opposed to stream events >> which represent the typesetti

Re: 2.16 release candidate 3 imminent

> I'd like to see regtests in one of these commits that uses two or three > simple functions in the form \foo c and <\foo c> that show this distinction. > > I thought that any music function could look through its argument, see if was > an event chord or a note event, and act on it accordingly.

Re: 2.16 release candidate 3 imminent

After reading through this e-mail, I'm ok with the patch with one caveat about regtests (see below). On Jan 22, 2012, at 9:08 AM, David Kastrup wrote: > Music expressions _represent_ the input, as opposed to stream events > which represent the typesetting task. > If this is truly the distincti

Re: music font

Il 22/01/2012 09:40, Emilio Grazzi ha scritto: [...] Interpretazione della musica... errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita errore di programmaz

Re: music font

Thanks Janek for your suggestion. I'm looking at the gonville readme but it will take me some time to understand, I'll let you know. Of course I've tried some shortcuts before, I opened lilypond font (the 20pt weight) in a font-editor, modified some glyphs and dropped an otf replacing the old on

Re: music font

Graham Percival writes: > On Sun, Jan 22, 2012 at 12:05:46AM +0100, Xavier Scheuer wrote: >> I am not a developer, just a simple user. >> >> But I must say I am a bit disappointed no developer (except Janek) >> replied to your e-mail. > > And I'm a bit disappointed that you keep on whining about

Re: 2.16 release candidate 3 imminent

"m...@apollinemike.com" writes: > On Jan 21, 2012, at 10:15 PM, David Kastrup wrote: > >> "m...@apollinemike.com" writes: >> >>> On Jan 21, 2012, at 7:58 PM, David Kastrup wrote: >> >>> >>>that all articulation events will be pulled out of NoteEvents or >>> >>>RestEvents and broadcas