Re: changing shape of the G clef (issue4664070)
2011/7/9 : > Please add an issue to the tracker, with images of both clefs, so we can > see the comparison side by side. There should be pdf versions of both > clefs, or high-resolution images (1200 dpi or so). http://code.google.com/p/lilypond/issues/detail?id=1752 i'll add some pdfs tomorrow, i hope that image attached will be sufficient for now. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing shape of the G clef (issue4664070)
Please add an issue to the tracker, with images of both clefs, so we can see the comparison side by side. There should be pdf versions of both clefs, or high-resolution images (1200 dpi or so). Thanks, Carl http://codereview.appspot.com/4664070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
changing shape of the G clef (issue4664070)
Reviewers: Reinhold, james.lowe_datacore.com, x.scheuer_gmail.com, Message: A tip to speed up work if you try to modify clef shape: use this script to generate a dvi preview of glyphs (no need to run make, and it also shows metafont control points): #!/bin/bash mf '\mode:=proof; input feta20' gftodvi feta20.2602gf \ && mv feta20.dvi feta20new.proof.dvi Description: changing shape of the G clef makes upper loop smaller, bottom crook sticks less, vertical line is more evenly curved. Also the upper loop is slightly bigger in reduced version of the clef than in the regular version, to fit stafflines well. Please review this at http://codereview.appspot.com/4664070/ Affected files: M mf/feta-clefs.mf Index: mf/feta-clefs.mf diff --git a/mf/feta-clefs.mf b/mf/feta-clefs.mf index 4522395cf6e08f20072b30aec272a10802ef90a7..8976fa1aabcd4dd2674a5062cd04414c82c283ae 100644 --- a/mf/feta-clefs.mf +++ b/mf/feta-clefs.mf @@ -317,6 +317,11 @@ def draw_gclef (expr reduction) = reduced_ss# = staff_space# * reduction; define_pixels (reduced_ss); + % G clef has now a smaller upper loop than it used to have. + % Too small loop in reduced clef (G_change) interacts badly + % with stafflines, so we make reduced clef's loop a bit bigger. + reduced_loop_correction := min (max (0.925, (0.55 + 0.5 * reduction)), 1); + thinness = 0.095 staff_space + 0.75 linethickness; downstroke_dir = unitvector (14, -75); downstroke_angle = angle downstroke_dir; @@ -333,7 +338,7 @@ def draw_gclef (expr reduction) = thinnib = thinness; set_char_box (0, 1.71 * breapth_factor * reduced_ss#, - 2.6 * reduced_ss#, 5 * reduced_ss#); + 2.435 * reduced_ss#, 4.6 * reduced_ss# / reduced_loop_correction); center := (breapth_factor * reduced_ss, 0); @@ -356,32 +361,32 @@ def draw_gclef (expr reduction) = y5r = .37 reduced_ss + ypart center; penpos5 (thickness, upward_swoosh_angle); - z6 = center + whatever * downstroke_dir; - y6 = ypart center + 2 reduced_ss; + z6 = center + whatever * downstroke_dir - (0.033, 0) * reduced_ss; + y6 = ypart center + 1.9 reduced_ss / reduced_loop_correction; % penpos6 is computed later - z7l - z6 = whatever * (z5 - z6) ; - y7l = 3.5 reduced_ss; + z7l - z6 = whatever * (z5 - z6); + y7l = 3.25 reduced_ss / reduced_loop_correction; penpos7 (thickness, upward_swoosh_angle); - x9 = .7 [x10, x7r]; - top y9l = 5 reduced_ss; - penpos9 (1.45 thickness, -70); + x9 = .8 [x10, x7r]; + top y9l = 4.6 reduced_ss / reduced_loop_correction; + penpos9 (1.45 thickness, -75); - x11 - x13r = 1.5 reduced_ss + 0.5 thinnib; - y11 = ypart center - 47/28 reduced_ss; - y12 = ypart center - 71/28 reduced_ss; + x11 - x13r = 1.42 * reduced_ss + 0.5 thinnib; + y11 = ypart center - 43/28 reduced_ss; + y12 = ypart center - 66/28 reduced_ss; y13 = .48 [y12, y4r]; x12r = xpart (.45 [z13r, z11] + .75 reduced_ss * downstroke_dir); % z10 = center + whatever * dir (downstroke_angle - 1.5); - x10 = x6 - 2 thinnib; - y10 = ypart center + 3.5 reduced_ss; + x10 = x6 - 1.65 thinnib * reduction; + y10 = ypart center + 3.15 reduced_ss / reduced_loop_correction; y10l - y10r = 1.0 thickness; z10r - z10l = .7 thinnib * dir (downstroke_angle + 90) + whatever * downstroke_dir; z10 = .5 [z10l, z10r]; - z11 = center + whatever * downstroke_dir + (-0.05 reduced_ss, 0); + z11 = center + whatever * downstroke_dir + (0.02 reduced_ss, 0); penpos11 (thinnib, start_angle + 90); penpos12 (thinnib, bot_angle + 90); @@ -403,7 +408,7 @@ def draw_gclef (expr reduction) = z10' = point 0.3 of pat; penpos10' (1.3 thinnib, angle (direction 0.3 of pat) + 50); - z11' = point 1.5 of pat; + z11' = point 1.5 of pat - (-0.033, 0.5) * reduced_ss; penpos11' (thinnib, angle (direction 1.5 of pat) + 90); z21l = z20l; ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
2011/7/8 Wols Lists : > It's certainly muddied the waters! :-) I'll try baling the bilges and > see what comes of it :-) Wol, i'm sorry that i cannot help you here - i'm not familiar enough in internals and also don't handle scheme well. However, i can say that what Carl tells us sounds right to me :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Sorry for being silent for some time, i got distracted by other things... 2011/7/7 Wols Lists : > On 07/07/11 08:59, Janek Warchoł wrote: >> 2011/7/7 Wols Lists : >>> On 06/07/11 20:31, lemniskata.bernoull...@gmail.com wrote: > >> >>> And it's the one supplied with lilypond - I assumed it formatted the >>> code as per lilypond guidelines ... >> >> It isn't, mostly because there were no precisely defined guidelines >> for a long time - sorry for that... >> We've just discussed it and we're implementing a solution, so soon >> this won't be a problem anymore. >> If you have a patch that wasn't processed by fixcc, send it to me, but >> if you don't, i'll take care of this. >> > Oops. I should have known better - I follow the kernel a little and they > moan there that format changes should always be in their own patch... > > No. I don't have a patch without the format changes, sorry :-( But it's > a mistake I doubt I'll make again! :) As for this patch, i'll handle adapting it to fit our style guidelines (if necessary). > Out of curiosity, what fix are you proposing? Something with git-hooks? I haven't followed the discussion about technical details, but IIRC you can find it by searching for mails with topic "GOP-PROP 3 - C++ formatting" and "Adapt fixcc.py to use Astyle". cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR update
On Fri, Jul 8, 2011 at 12:02 PM, Graham Percival wrote: > So why the \version changes in Valentin's commit? Yeah, I did notice that; I figured it made sense because of the major version bump. (But there probably is a better reason out there :-) Cheers, Valentin. PS: I hope you're having an enjoyable trip! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
Reverted sentence about \version.
Ready to go?
http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):
http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi#newcode311
Documentation/web/community.itexi:311: Specify which release of LilyPond
you are using with a
On 2011/07/07 10:26:39, Graham Percival wrote:
On 2011/07/06 17:44:37, Janek Warchol wrote:
> Hmm, what about "Specify which "code{\version} of LilyPond you are
using."?
hmm, that's better, but it still feels a bit wordy.
I'm not feeling enthusiastic about this change. Do we have any
evidence that
"include the \version number" is misunderstood? If you can point to 3
emails to
bug-lilypond where people misunderstood this, then I'm fine with a
more wordy
explanation.
No, i don't have any proofs, it was just a guess. Scrap it then.
(that said, adding the @code{} around \version is still a good change)
Done.
http://codereview.appspot.com/4636082/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: text on analysis brackets
On 8 July 2011 21:09, David Nalesnik wrote: > So to refine the original question: Is there any way to do this > without multi-voice trickery? I'm afraid this is a bug in the Horizontal_bracket_engraver, so until it's fixed your only other option would be to roll you own engraver in Scheme. I've logged it on the bugtracker (http://code.google.com/p/lilypond/issues/detail?id=1751) and plan on pushing a fix tomorrow. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: text on analysis brackets
On 7/8/11, David Nalesnik wrote:
> Hi, all --
>
> I'd like to be able to add text to analysis brackets, and I'm running
> into a problem with nested brackets.
>
> In the attached file, I'd like the last bracket to have "b" over it,
> but it takes its text from the previous incomplete bracket.
>
> (It seems I can add as many nested brackets as I like with different
> text, as long as they have the same starting-point.)
>
> Is there anything I can do to make this approach work?
>
Hi, again --
It just dawned on me that I can use different voices, like so:
\version "2.14.1"
#(define (label text)
(lambda (grob)
;; adapted from LSR snippet, "Center text below hairpin dynamics"
(ly:stencil-aligned-to
(ly:stencil-combine-at-edge
(ly:stencil-aligned-to (ly:horizontal-bracket::print grob) X CENTER)
Y (ly:grob-property grob 'direction)
(ly:stencil-aligned-to (grob-interpret-markup grob (markup
text)) X CENTER)
0.2)
X LEFT)))
\layout {
\context {
\Voice
\consists "Horizontal_bracket_engraver"
}
}
\new Staff <<
\new Voice \relative c'' {
\override HorizontalBracket #'direction = #UP
c4-\tweak #'stencil #(label "A")\startGroup
-\tweak #'stencil #(label "a")\startGroup
d4\stopGroup
e4
d4\stopGroup
}
\new Voice {
s4
s4
\override HorizontalBracket #'direction = #UP
\override NoteColumn #'ignore-collision = ##t
\hideNotes
e''4-\tweak #'stencil #(label "b")\startGroup
d''4\stopGroup
}
>>
So to refine the original question: Is there any way to do this
without multi-voice trickery?
Best,
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
text on analysis brackets
Hi, all --
I'd like to be able to add text to analysis brackets, and I'm running
into a problem with nested brackets.
In the attached file, I'd like the last bracket to have "b" over it,
but it takes its text from the previous incomplete bracket.
(It seems I can add as many nested brackets as I like with different
text, as long as they have the same starting-point.)
Is there anything I can do to make this approach work?
Best,
David
\version "2.14.1"
\paper { tagline = ##f }
#(define (label text)
(lambda (grob)
;; adapted from LSR snippet, "Center text below hairpin dynamics"
(ly:stencil-aligned-to
(ly:stencil-combine-at-edge
(ly:stencil-aligned-to (ly:horizontal-bracket::print grob) X CENTER)
Y (ly:grob-property grob 'direction)
(ly:stencil-aligned-to (grob-interpret-markup grob (markup text)) X CENTER)
0.2)
X LEFT)))
\layout {
\context {
\Voice
\consists "Horizontal_bracket_engraver"
}
}
\relative c'' {
\override HorizontalBracket #'direction = #UP
c4-\tweak #'stencil #(label "A")\startGroup
-\tweak #'stencil #(label "a")\startGroup
d4\stopGroup
%% following tweak seems to have no effect
e4-\tweak #'stencil #(label "b")\startGroup
d4\stopGroup\stopGroup
}
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 4: lessons from 2.14 (probable decision)
http://lilypond.org/~graham/gop/gop_4.html I made some quick graphs, so I recommend looking online. ** Proposal summary What went well, what went badly? This is a discussion only; it will be summarized, and we will refer back to it in future policy decisions, but no new policies will be decided in this round. We’ll have (at least) two sections: one for facts that anybody considers relevant, and one for thoughts and commentary. ** History A brief history of releases: date (-MM-DD) version comment 2008-10-28 2.11.63 nobody checking regtests 2008-11-17 2.11.64 2008-11-29 2.11.65 2008-12-23 2.12.0 2009-01-01 somewhere around here, Graham becomes officially release manager, but Han-Wen still builds the actual releases 2009-01-01 2.12.1 2009-01-25 2.12.2 2009-02-28 2.13.0 2009-06-01 2.13.1 note jump in time! 2009-06-27 2.13.2 first Graham release? 2009-07-03 2.13.3 2009-09-09 Graham arrives in Glasgow, gets a powerful desktop computer, and begins serious work on GUB (sending bug reports to Jan). It takes approximately 100 hours until GUB is stable enough to make regular releases. 2009-09-24 2.13.4 2009-10-02 2.13.5 2009-10-22 2.13.6 2009-11-05 2.13.7 ... 2010-01-13 2.12.3 ... 2010-03-19 2.13.16 Bug squad starts doing a few regtest comparisons, but IIRC the effort dies out after a few weeks (BLUE) ... 2010-08-04 2.13.29 Phil starts checking regtests (BLUE) ... 2011-01-12 2.13.46 release candidate 1 (GREEN) ... 2011-05-30 2.13.63 release candidate 7 (GREEN) 2011-06-06 2.14.0 bugs-2.13-visualization.png zoom-2.13-visualization.png ** Carl’s analysis of the bugs lilypond-issues-analysis.csv lilypond-issues-analysis-trim-duplicates.csv There 148 issues marked with Priority=Critical in the tracker. I’ve done an analysis, and it looks to me like there was initially a backlog of critical issues that weren’t fixed, and little work was being done to eliminate critical issues. Somewhere about 2010-08-01, critical issues started to disappear, but occasional new ones appeared. There were a couple of major changes that introduced unanticipated regressions (new spacing code, beam collision avoidance). These produced more than the expected number of regressions. It appears to me that we didn’t really get serious about eliminating critical bugs until about 2010-06-15 or so. After that point, the number of critical bugs more-or-less steadily decreased until we got to a release candidate. Of particular interest, the first release candidate of 2.14 was released on 2011-01-12. Over the next 10 days, about a dozen bugs were reported and fixed. Release candidate 2 came out on 2011-02-09. No surge of bugs occurred with this release. Candidate 3 came out on 2011-03-13; we got 2 bugs per week. Candidate 4 came out on 2011-03-29; 2 new bugs. Candidate 6 came out on 2011-04-07. We got a couple of bugs per week. ** Notes, commentary, and opinions Han-Wen: “Overall, I think this cycle took too long” Mike: I agree Graham: +1 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Does type checking for all context property sets. (issue4654090)
On 7/8/11 2:48 AM, "m...@apollinemike.com" wrote: > On Jul 7, 2011, at 6:38 PM, Han-Wen Nienhuys wrote: > >> On Wed, Jul 6, 2011 at 4:19 AM, wrote: >>> Reviewers: , >>> >>> Message: >>> I tried this with my local branch and I noticed no slow-down (I'm sure >>> there is one, but it certainly is not prohibitive). It gets rid of any >>> potential segfaults from bad property sets in the layout block. >> >> Can you do a real measurement ? Have the code print out timestamps at >> start & end of translation, and run a 10 times with and without. >> > > Note that there is an outlier in the no context property checking. I've shown > means with and without the largest/smallest dropped. > > Time of translation (just before the call to lilypond-main and start of > interpretation and just before the message "Interpreting..."), 10 runs with > context property checking (in microseconds) > [261539, 261617, 261597, 261030, 265018, 260641, 282217, 262489, 262616, > 265436] > mean: 264420.0 > mean w/ outliers dropped: 262667.75 > > Time of translation, 10 runs with no context property checking (in > microseconds) > [258837, 259777, 261231, 261915, 261306, 259702, 260661, 260903, 262827, > 317991] > mean: 266515.0 > mean w/ outliers dropped: 261040.25 According to my statistics, there are no outliers (i.e., no points that are more than 3 standard deviations away from the mean. Whether one eliminates the "outliers", or whether one does not, the conclusion is the same. There is no statistically significant difference in translation time between the two versions. (The version with context checking has a slightly smaller mean in this data set, but the difference is not even close to being statistically significant -- 1/3 of the smaller standard deviation, 1/9 of the larger). The statistical conclusion has to be "no slow-down". Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Thu, Jul 07, 2011 at 01:16:21PM +0100, Graham Percival wrote: > * We do not change the output of make, make doc, or any of the > other make commands - this is the default. > * We use the variable QUIET_BUILD to signal to the make system > that we want the minimum of progress output visible on the > terminal, with all other output going to logfiles I think we should use logfiles by default -- actually, we should use logfiles exclusively -- and then display bits of logfiles if that seems helpful in debugging problems. That said, I do not think that we should hide the ((make output)). In other words: - all output from make(1) should be be on the console. - all output not from make(1) should be in logfiles. - all output from make(1) might be saved to a logfile in addition to being on the console, if we can find a sensible file to put it in. > * Wherever possible, stderr output should go to *.err.log and > stdout output to *.log I'm personally not wild about the difference in length between .err.log and .log... but I also think that the suggestions that we combine those anyway are certainly worth considering. > * Running (for example) make -s QUIET_BUILD=1 doc should give > the occasional progress message to indicate where it has > reached in the build process, but a such a rate that it’s > easy to read and a volume that allows the user to see the > top of the output in terminal Disagree. We don't need occasional progress messages; the only case that it might have been useful was caused from a lack of communication. Once people know how things go, they're not useful. > * Ideally, running (for example) make -s QUIET_BUILD=1 on a > build that fails should make it easy to see the file causing > the build to fail. I think we should omit the "-s QUIET_BUILD=1" from that sentence. It should always be easy to see why a build fails. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Fri, Jul 08, 2011 at 09:10:40AM +0200, Matthias Kilian wrote: > On Fri, Jul 08, 2011 at 08:24:37AM +0200, Jan Nieuwenhuizen wrote: > > * Passing --enable-silent-rules to configure will cause build rules to > > be less verbose; the option --disable-silent-rules is the default and > > will cause normal verbose output. > > The problem with the too verbose build output in lilypond is not > related at all to the *make* output, IMHO. --enable-silent-rules > only hides crucial information. Absolutely! I think we really need to distinguish between ((make output)) and ((the output that you get after you type make)); so far we've been using those concepts interchangably. > Heck, at OpenBSD we even spent time to force > --disable-silent-rules on all software packages by default, > because it just sucks if a build fails and you don't see the > exact command line parameters passed to the compiler or the > linker. True -- although sometimes configuration is done via environment variables, which may or may not be displayed on the exact command line. (i.e. if something happens inside a subshell) I'd like to have a general policy that we don't use environment vars (at least, not within the build system) -- if you cut&paste the exact command-line that you see in the make output, you should get exactly the same behaviour (assuming that there's no difference in files on the computer). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR update
On Fri, Jul 08, 2011 at 11:43:18AM +0200, Francisco Vila wrote: > 2011/7/8 Francisco Vila : > > 2011/7/8 Graham Percival : > >> I see snippets which have only updated > >> \version > > > > It has been very common in the past. Yes, but AFAIK I fixed that. > > Right; it could be a bug of convert-ly. > > I have checked that [current version of] convert-ly -d -e does not > change 2.14.0 to 2.15 if that is the only change. So why the \version changes in Valentin's commit? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds redirect-lilypond-output option to lilypond-book (issue4664060)
On Mon, Jul 04, 2011 at 04:23:06PM +0100, Phil Holmes wrote: > - Original Message - From: > To: ; > >Or maybe just make the "child returned" into "Error: could not complete > >command", or maybe "Error: child returned > >__insert_error_code_interpretation__" ? > > AFAICS this is a doddle to change. I'll do this as a follow up > piece of work unless you want it earlier. Later piece of work is fine. I guess that now we'll wait for this patch to get onto the countdown. > >- it's a bit weird to see tons of output even when using the > >--redirect-lilypond-output. Would it be possible to make a > > --use-logfiles > >option which automatically turns on --redirect-lilypond-output, but also > >captures stderr+stdlog and writes *those* to a file? > >(and maybe in addition to writing the log file, it would display the > >"Error: child returned __blah_blah__" line) > > Don't think so, at present. From my reading of the Python, progress > and error messages mostly go to stderr, as does the error message. > To make it so that we don't see progress but do see the error > message would be something of a rewrite of how progress and errors > are handled in lilylib and lilypond-book. So, we need the GOP > debate on stderr versus stdout. ok, that makes sense. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR update
2011/7/8 Graham Percival : > I see snippets which have only updated > \version It has been very common in the past. > Could somebody inverstigate this? > > AFAICS the instructions here are still good: > http://lilypond.org/doc/v2.15/Documentation/contributor/lsr-to-git > and makelsr.py contains "convert -d -e", so IIRC this shouldn't > happen. Right; it could be a bug of convert-ly. As I said, it has been very common but maybe it was before the -d option was implemented. -- 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: LSR update
2011/7/8 Francisco Vila : > 2011/7/8 Graham Percival : >> I see snippets which have only updated >> \version > > It has been very common in the past. > >> Could somebody inverstigate this? >> >> AFAICS the instructions here are still good: >> http://lilypond.org/doc/v2.15/Documentation/contributor/lsr-to-git >> and makelsr.py contains "convert -d -e", so IIRC this shouldn't >> happen. > > Right; it could be a bug of convert-ly. I have checked that [current version of] convert-ly -d -e does not change 2.14.0 to 2.15 if that is the only change. -- 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: Does type checking for all context property sets. (issue4654090)
On Jul 7, 2011, at 6:38 PM, Han-Wen Nienhuys wrote: > On Wed, Jul 6, 2011 at 4:19 AM, wrote: >> Reviewers: , >> >> Message: >> I tried this with my local branch and I noticed no slow-down (I'm sure >> there is one, but it certainly is not prohibitive). It gets rid of any >> potential segfaults from bad property sets in the layout block. > > Can you do a real measurement ? Have the code print out timestamps at > start & end of translation, and run a 10 times with and without. > Note that there is an outlier in the no context property checking. I've shown means with and without the largest/smallest dropped. Time of translation (just before the call to lilypond-main and start of interpretation and just before the message "Interpreting..."), 10 runs with context property checking (in microseconds) [261539, 261617, 261597, 261030, 265018, 260641, 282217, 262489, 262616, 265436] mean: 264420.0 mean w/ outliers dropped: 262667.75 Time of translation, 10 runs with no context property checking (in microseconds) [258837, 259777, 261231, 261915, 261306, 259702, 260661, 260903, 262827, 317991] mean: 266515.0 mean w/ outliers dropped: 261040.25 Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
LSR update
I see snippets which have only updated \version Could somebody inverstigate this? AFAICS the instructions here are still good: http://lilypond.org/doc/v2.15/Documentation/contributor/lsr-to-git and makelsr.py contains "convert -d -e", so IIRC this shouldn't happen. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
On Fri, Jul 08, 2011 at 08:24:37AM +0200, Jan Nieuwenhuizen wrote: > Almost right. However, try not to invent something new. Please just > use the autoconf/automake behaviour, which follows mostly the convention > that Linux and Git git have set. > >http://www.gnu.org/s/hello/manual/automake/Options.html > > To summarize > > the user of the package may influence the verbosity at configure run > time as well as at make run time: > > * Passing --enable-silent-rules to configure will cause build rules to > be less verbose; the option --disable-silent-rules is the default and > will cause normal verbose output. > > [we could change this default] Please no. The problem with the too verbose build output in lilypond is not related at all to the *make* output, IMHO. --enable-silent-rules only hides crucial information. Heck, at OpenBSD we even spent time to force --disable-silent-rules on all software packages by default, because it just sucks if a build fails and you don't see the exact command line parameters passed to the compiler or the linker. Ciao, Kili ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
