Re: PATCH: Countdown delayed by Monster Trucks
2011/7/31 James Lowe james.l...@datacore.com: I imagine some underground bunker with walls of charts and a big map of the lilypond code with ladies wearing headsets pushing flags around with all our names on them. And Graham watches everything smoking a cigar :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 3)
Graham Percival wrote Sunday, July 31, 2011 12:34 AM Are there any problems with those guidelines? Not from me. Let's give them a try. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1518/3798 - Release Date: 07/30/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
Graham Percival gra...@percival-music.ca writes: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1771 My take on this (if nobody is going to protest in the next few hours) is to revert the flawed fix. Reason: we get rid of a critical issue. The original bug fixer does not appear to be in the queue for fixing the effects of his patch, and the patch adds a considerable amount of material. For me this means that it is easier to think about fixing the original bug than it is thinking about the flawed fix. I'll revert in my personal copy and start thinking from there. However, it will be about noonish before I actually have time. The other critical bug appears to be related with multithreading, and I consider it likely, given its random appearance, that it will mainly affect multicore systems. I don't have such a one. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1771 My take on this (if nobody is going to protest in the next few hours) is to revert the flawed fix. I think that's entirely reasonable. IMO, if there's no clear offer of a fix within 48 hours of a bad commit, we should revert it. The other critical bug appears to be related with multithreading, and I consider it likely, given its random appearance, that it will mainly affect multicore systems. I don't have such a one. I thought lilypond was single-threaded? Or is the C++ stuff single-threaded, but the guile stuff multi-threaded? I mean, I know that functional programming is great for multi-threaded work in general, but I didn't think that we used it as such. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
Graham Percival gra...@percival-music.ca writes: On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1771 My take on this (if nobody is going to protest in the next few hours) is to revert the flawed fix. I think that's entirely reasonable. IMO, if there's no clear offer of a fix within 48 hours of a bad commit, we should revert it. The other critical bug appears to be related with multithreading, and I consider it likely, given its random appearance, that it will mainly affect multicore systems. I don't have such a one. I thought lilypond was single-threaded? Or is the C++ stuff single-threaded, but the guile stuff multi-threaded? I mean, I know that functional programming is great for multi-threaded work in general, but I didn't think that we used it as such. Guile explicitly differentiates functions map and map-in-order. In theory, it would be free to evaluate map in multiple threads. I have no indication that it does so and would be quite surprised if they indeed had as fine-grained threading as that. But this bug has been reported as occuring non-deterministically even in successive runs on the same machine, and there are rather few things that can introduce such stochastic behavior (another possibility would be timer-triggered garbage collection). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
Graham Percival gra...@percival-music.ca writes: On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1771 My take on this (if nobody is going to protest in the next few hours) is to revert the flawed fix. I think that's entirely reasonable. IMO, if there's no clear offer of a fix within 48 hours of a bad commit, we should revert it. Within 48 hours of pinpointing the bad commit. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
David Kastrup wrote Sunday, July 31, 2011 8:42 AM Graham Percival gra...@percival-music.ca writes: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1771 My take on this (if nobody is going to protest in the next few hours) is to revert the flawed fix. +1 The original bug fixer does not appear to be in the queue for fixing the effects of his patch, and the patch adds a considerable amount of material. Fixing LilyPond is rarely trivial. In my experience the first fix one thinks of is usually flawed (and the second ...) We need to be doubly cautious when applying fixes from casual contributors. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1518/3799 - Release Date: 07/30/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
On Sun, Jul 31, 2011 at 10:04:59AM +0200, David Kastrup wrote: But this bug has been reported as occuring non-deterministically even in successive runs on the same machine, and there are rather few things that can introduce such stochastic behavior (another possibility would be timer-triggered garbage collection). In C++ code, I'd suspect some uninitalized variables (especially since it always seems to work on the second run on a machine that failed in the first run). But since that throw() message seems to come from guile, and AFAIK you can't have an unitalized variable in guile, I guess that's not an issue? Or could we be setting a guile variable from some (uninitalized) C++ variable? It's a shame that we can't (usefully) run valgrind on lilypond, or that nobody's experiented with llvm or even AFAIK the more sophisticated gcc options. Finding uninitalized variables is a task that can be done by the computer; humans should never need to theorize about whether that's a cause or not. Just run the program with a trusted tool, and then you'll either find the variables, or else you can cross that off from the list of possibilities. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
Graham Percival gra...@percival-music.ca writes: On Sun, Jul 31, 2011 at 10:04:59AM +0200, David Kastrup wrote: But this bug has been reported as occuring non-deterministically even in successive runs on the same machine, and there are rather few things that can introduce such stochastic behavior (another possibility would be timer-triggered garbage collection). In C++ code, I'd suspect some uninitalized variables (especially since it always seems to work on the second run on a machine that failed in the first run). Modern operating systems don't give your code any leftovers from a previous run. That would be a security violation. And even user stack initialization below the stack pointer is not stochastical. System processes (like those triggered by interrupts and/or preemption) use their own stack, and again: it would be a security violation if a user process could access any information from their operation. So the sources for variation in successive identical runs are very limited. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 3)
LGTM. 2011/7/31 Graham Percival gra...@percival-music.ca: We have somebody willing to work on this stuff. He's twiddling his thumbs until we get the basic guidelines down. Of course there will be technical implementation problems to work out later, but I'm really hoping that he can start work; it's been a month! Are there any problems with those guidelines? If you disagree with a point (or if I have not convinced you that you should accept the proposal), please speak up. If you would like to add a point, please speak up. http://lilypond.org/~graham/gop/gop_5.html ** Proposal summary If there are no build problems, there should be no change to people’s workflow. If there are build problems, then it should be easier to find out why it’s failing. ** Rationale When the lilypond build breaks, it’s too hard to figure out why it broke. We see emails to lilypond-devel approximately once every two months about broken builds. On a subjective note, Graham has been the documentation editor since 2003, but even he cannot reliably pinpoint the cause of a failing doc build within 10 minutes. We waste a ridiculous amount of time, effort, and patience on build problems. ** Sea of output Before any of the current work on reducing output from make, the result of a make doc was over 500,000 lines of text. The prime reason for the output being so verbose is that all the processes that run as a result of the call to make echo their output to the screen, often in verbose mode. Lilypond itself produces around 370,000 lines of output as a result of lilypond-book building all the snippets. Much of this output can be redirected to logfiles and so the impossible-to-read clutter on the screen is cut out and could be referred to later. ** Proposal details When you run make or make doc, * All output will be saved to various log files, with the exception of output directly from make(1). * By default, no other output will be displayed on the console, with one exception: if a build fails, we might display some portion(s) of log file(s) which give useful clues about the reason for the failure. The user may optionally request additional output to be printed; this is controlled with the VERBOSE=x flag. In such cases, all output will still be written to log files; the console output is strictly additional to the log files. * Logfiles from calling lilypond (as part of lilypond-book) will go in the relevant ‘build/out/lybook-db/12/lily-123456.log’ file. All other logfiles will go in the ‘build/logfiles/’ directory. * Both stderr and stdout will be saved in *.log. The order of lines from these streams should be preserved. * There will be no additional “progress messages” during the build process. If you run make --silent, a non-failing build should print absolutely nothing to the screen. * Ideally, a failing build should provide hints about the reason why it failed, or at least hints about which log file(s) to examine. ** Don’t cause more build problems However, there is a danger in this approach, that vital error messages can also be lost, thus preventing the cause of the failure of a make being found. We therefore need to be exceptionally careful to move cautiously, include plenty of tests, and give time for people to experiment/find problems in each stage before proceeding to the next stage. ** Implementation notes There is an existing make variable QUIET_BUILD, which alter the amount of output being displayed (http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables ). We are not planning on keeping this make variable. The standard way for GNU packages to give more output is with a V=x option. Presumably this is done by increasing x? If we support this option, we should still write log files; we would simply print more of the info in those log files to screen. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
W dniu 31 lipca 2011 01:23 użytkownik James Lowe james.l...@datacore.com napisał: Then what would be the purpose of \once \override; or is that your point? Yeah, making \once \override work like \tweak is my point. But i'm not sure about it, it's just an idea for GLISS. W dniu 31 lipca 2011 01:48 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 7/30/11 4:37 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does I guess we'll have this out in GLISS. But I think it would be a major inconvenience. If I want to have the all the notes at the current instant made red, I can do it with a single call to \once \override. If we make \once \override work like \tweak, I'd need a call for each note head. Definately it's a topic for GLISS. 2011/7/31 David Kastrup d...@gnu.org: Carl Sorensen c_soren...@byu.edu writes: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, you need to do \tweak ... c Yeah... While i can learn to live with that (albeit very painfully), there are plenty of people whose minds would simply blow because of this (you know, ordinary people without geek-skills). I have some more to say about this, but i guess it will be best suited when we discuss GOP-PROP roadmap of future development. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make doc failing
- Original Message - From: James Lowe james.l...@datacore.com To: lilypond-devel@gnu.org Sent: Sunday, July 31, 2011 1:40 AM Subject: Make doc failing Hello, I'm not able to make doc. The last time it worked was around wed last week (I don't make doc that often). [snip] FYI I ran a completely new build last night UK time - nuked the build directory, pulled git and ran make; make website and make doc. All was OK. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
hi Bertrand, the patch is correct, AFAICS; see some minor improvements below. minor concerns (which shouldn't delay acception): 1. about the very existence of usable-duration-logs - ok, it's generic, but who uses this genericity? is it not always (0 -1 -2 -3)? is it not always a range with lower end -3? is it not always a range? 2. comments, more descriptive names, e.g. round_up instead of round in calc_measure_duration_log; measure_count instead of measures (and l), symbol_count instead of count in church_rest http://codereview.appspot.com/4536068/diff/37004/lily/multi-measure-rest.cc File lily/multi-measure-rest.cc (right): http://codereview.appspot.com/4536068/diff/37004/lily/multi-measure-rest.cc#newcode163 lily/multi-measure-rest.cc:163: closest_usable_duration_log = minimum_usable_duration_log; I think these two lines can be moved after the loop http://codereview.appspot.com/4536068/diff/37004/lily/multi-measure-rest.cc#newcode257 lily/multi-measure-rest.cc:257: int mdl = calc_measure_duration_log (me); move this before the loop http://codereview.appspot.com/4536068/diff/37004/lily/multi-measure-rest.cc#newcode268 lily/multi-measure-rest.cc:268: k = mdl + i; I'd write lines 254-268 like /* find the longest usable rest fitting into l: k identifies a canditate by its duration-log, length is its duration (in mdl units) */ int k = longest_church_rest; int length = 1 (mdl - k); for (; length l; ++k) length = 1; l -= length; http://codereview.appspot.com/4536068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Full measure rest should take more horizontal space
Hello,
In my everyday use of LilyPond I am often annoyed by the fact that
—especially in tighter situations— full measure rests take very
little horizontal space, hence their measure width are much more
*compressed* than neighbouring measures.
This results in IMHO poor output.
I do not know what engraving references say about the horizontal
_measure width_ in the case of full measure rest but I would have
expected a full measure rest to take as much horizontal space as the
corresponding-duration note (full measure-duration note).
Someone could confirm this?
Snippet
%% Full measure rest should take as much horizontal space as a note of
%% the same duration.
%% Currently the whole rest measure widths are smaller than
%% corresponding duration note and they are much more compressed in
%% tighter situations.
%%
%% Note that the width of a full measure rest should adapt to its
%% duration, hence the solution of defining minimum-length is not
%% suitable for different time signatures. A full measure rest in
%% 2/4 should have a smaller width than a full measure rest in 4/4
%% because a whole takes much horizontal space than a half note.
%%
\version 2.15.7
test = \relative c' {
c1
R1
c1
R1
\repeat unfold 2 c1
R1*2
\repeat unfold 2 c1
R1
\repeat unfold 2 c1
R1*2
\repeat unfold 2 c1
R1
c1
R1
c1
c1
}
\score {
\new Staff {
c'1^current full bar rest width
\test
}
}
\score {
\new Staff {
c'1^new (expected) full bar rest width
\test
}
\layout {
\context {
\Voice
\override MultiMeasureRest #'minimum-length = #8
}
}
}
End of snippet
Cheers,
Xavier
--
Xavier Scheuer x.sche...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtests for 2.15.7
tuplet-rest.ly is different and looks like http://code.google.com/p/lilypond/issues/detail?id=1720 has been fixed. Except it's down as patch needs work. Explanation, please? dynamics-alignment-breaker.ly: the hairpin has moved above the stave display-lily-tests.log: \revert Voice . TextScript #'direction \revert Voice . Tie #'direction + \revert Voice . TupletBracket #'direction \unset Voice . graceSettings \revert Voice . NoteColumn #'horizontal-shift \revert Voice . MultiMeasureRest #'staff-position Otherwise OK. -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Modify chord-name-engraver to call capo-handler (issue4800051)
New patch uploaded. Passes regtests made from scratch. http://codereview.appspot.com/4800051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Incorporates suggestions from Neil into footnotes. (issue4798063)
Reviewers: ,
Message:
Hey all,
These incorporate several comments from Neil regarding automatic
footnotes. Sorry for having missed them before, Neil!
Cheers,
MS
Description:
Incorporates suggestions from Neil into footnotes.
Please review this at http://codereview.appspot.com/4798063/
Affected files:
M input/regression/footnote-auto-numbering-page-reset.ly
M input/regression/footnote-auto-numbering.ly
M ly/music-functions-init.ly
M scm/lily-library.scm
Index: input/regression/footnote-auto-numbering-page-reset.ly
diff --git a/input/regression/footnote-auto-numbering-page-reset.ly
b/input/regression/footnote-auto-numbering-page-reset.ly
index
06a347ebdad08ff72bb90787252d826d303162c1..dc3fa468b5c10de78b3391929d478e847ae9f8e2
100644
--- a/input/regression/footnote-auto-numbering-page-reset.ly
+++ b/input/regression/footnote-auto-numbering-page-reset.ly
@@ -1,6 +1,11 @@
\version 2.15.7
\header {
- texidoc = Lilypond does footnotes.
+ texidoc = This is an example of automatic footnote numbering
+where the number is reset on each page. It uses the symbol-footnotes
+numbering function, which assigns the symbols *, †, ‡, § and ¶ to
+successive footnotes, doubling up on the symbol after five footnotes
+have been reached.
+
}
\paper {
Index: input/regression/footnote-auto-numbering.ly
diff --git a/input/regression/footnote-auto-numbering.ly
b/input/regression/footnote-auto-numbering.ly
index
fe4babe1a013ee17d0703a8648cc0cc05e1c19aa..3c0b410956082d0ec5d38d124c942d6e14c37123
100644
--- a/input/regression/footnote-auto-numbering.ly
+++ b/input/regression/footnote-auto-numbering.ly
@@ -1,6 +1,10 @@
\version 2.15.7
\header {
- texidoc = Lilypond does footnotes.
+ texidoc = This is an example of automatic footnote numbering
+where the number is not reset on each page. It uses the default
+numbering function, which assigns numbers starting at 1 to successive
+footnotes.
+
}
\paper {
Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index
3535a0a6a7b0dc5a03188dca78078e178ede3f16..2278f85a266387dbedef8a3d3192917b2193d126
100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -361,7 +361,7 @@ the number appears at @var{offset}. Note that, for
this to take effect,
auto-numbering must be turned on in the paper block. Otherwise, no
number will appear. Use like @code{\\once}))
#{
- \footnoteGrob $grob-name $offset \markup { } $footnote
+ \footnoteGrob $grob-name $offset \markup { \null } $footnote
#})
footnote =
@@ -389,7 +389,7 @@ Otherwise, no number will appear. Use like
@code{\\tweak}))
(make-music 'FootnoteEvent
'X-offset (car offset)
'Y-offset (cdr offset)
- 'text (markup )
+ 'text (make-null-markup)
'footnote-text footnote))
grace =
Index: scm/lily-library.scm
diff --git a/scm/lily-library.scm b/scm/lily-library.scm
index
34c9cb3820096c04603fd358393651bb165491e1..ede65ff5e2a54b88d303e0a2429e3980384c7022
100644
--- a/scm/lily-library.scm
+++ b/scm/lily-library.scm
@@ -746,23 +746,6 @@ Handy for debugging, possibly turned off.
(reverse matches))
-(define-public (random-string pool n)
- Produces a random lowercase string of length n
- (define (helper alphabet out num)
-(let ((rand (random (string-length pool
- (if ( num 1)
- out
- (helper alphabet
- (string-concatenate `(,out
-,(substring alphabet
-rand
-(+ 1 rand
- (- num 1)
- (helper pool n))
-
-(define-public (random-lowercase-string n)
- (random-string abcdefghijklmnopqrstuvwxyz n))
-
;; other
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Full measure rest should take more horizontal space
Wow, i'm CCed! Why? 2011/7/31 Xavier Scheuer x.sche...@gmail.com: Hello, In my everyday use of LilyPond I am often annoyed by the fact that —especially in tighter situations— full measure rests take very little horizontal space, hence their measure width are much more *compressed* than neighbouring measures. This results in IMHO poor output. I think i agree that full measure rest should take the same amount of space as full measure note. I do not know what engraving references say about the horizontal _measure width_ in the case of full measure rest but I would have expected a full measure rest to take as much horizontal space as the corresponding-duration note (full measure-duration note). Someone could confirm this? The only way of confirmation that comes to my mind (as i don't have any engraving books) is to go to imslp.org, click 'random page' 30 times and see what appears... It is a very brutal method. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Full measure rest should take more horizontal space
- Original Message - From: Janek Warchoł lemniskata.bernoull...@gmail.com To: Xavier Scheuer x.sche...@gmail.com Cc: lilypond-devel lilypond-devel@gnu.org; bug-lilypond bug-lilyp...@gnu.org Sent: Sunday, July 31, 2011 11:52 AM Subject: Re: Full measure rest should take more horizontal space Wow, i'm CCed! Why? 2011/7/31 Xavier Scheuer x.sche...@gmail.com: Hello, In my everyday use of LilyPond I am often annoyed by the fact that —especially in tighter situations— full measure rests take very little horizontal space, hence their measure width are much more *compressed* than neighbouring measures. This results in IMHO poor output. I think i agree that full measure rest should take the same amount of space as full measure note. I do not know what engraving references say about the horizontal _measure width_ in the case of full measure rest but I would have expected a full measure rest to take as much horizontal space as the corresponding-duration note (full measure-duration note). Someone could confirm this? The only way of confirmation that comes to my mind (as i don't have any engraving books) is to go to imslp.org, click 'random page' 30 times and see what appears... It is a very brutal method. cheers, Janek Gould and Read both strongly imply that a WMR should take up the same space as the equivalent note: we could discuss whether this is always a semi-breve, or whether it represents the timed length of the note in other time sigs than 4/4. Gould says Position a rest exactly as if it were a note of equivalent duration [except] the semi-breve rest is placed at the visual centre of the bar. Read says Written rests [..] are always given a time-value: that is, the rest symbols merely substitute for a written note value. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
2011/7/31 David Kastrup d...@gnu.org: Graham Percival gra...@percival-music.ca writes: On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1771 My take on this (if nobody is going to protest in the next few hours) is to revert the flawed fix. I think that's entirely reasonable. IMO, if there's no clear offer of a fix within 48 hours of a bad commit, we should revert it. Within 48 hours of pinpointing the bad commit. +1. If we manage to get stable releases every few months, i think a policy of reverting any flawed commit that appeared after last stable release (i mean x in 2.x.y, not y) would be good. I can help with these bugs when i close currently opened issues and sort out my repository after grand fixcc-ing (estimated to happen next weekend). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests for 2.15.7
On So., 31. Jul. 2011 11:52:47 CEST, Phil Holmes m...@philholmes.net wrote: dynamics-alignment-breaker.ly: the hairpin has moved above the stave Yes, expected, issue was fixed. display-lily-tests.log: \revert Voice . TextScript #'direction \revert Voice . Tie #'direction + \revert Voice . TupletBracket #'direction \unset Voice . graceSettings \revert Voice . NoteColumn #'horizontal-shift \revert Voice . MultiMeasureRest #'staff-position It seems the tuplet bracket direction (see your fisrt difference) is now also included in voiceOne and the like. Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1780 - Guile V2 deprecation warnings re format calls with no dest parameter (issue4808063)
On 2011/07/30 22:59:11, Reinhold wrote: I think that you forgot to rebase your branch to origin/master before uploading that patch. Your version does not have some of the latest patches in the git tree, so it appears that you are reverting some of those patches. http://codereview.appspot.com/4808063/diff/1/scm/define-markup-commands.scm File scm/define-markup-commands.scm (left): http://codereview.appspot.com/4808063/diff/1/scm/define-markup-commands.scm#oldcode1491 scm/define-markup-commands.scm:1491: (ly:stencil-translate-axis stacked-stencil (- (car stacked-extent)) X ))) Are you sure you want to revert this patch of mine? http://codereview.appspot.com/4808063/diff/1/scm/define-markup-commands.scm#oldcode1966 scm/define-markup-commands.scm:1966: main-stencil Same goes here... Have you rebased your git branch to origin/master before running git cl upload origin/master? It seems your current branch does not have some of the latest patches. Nice catch, Reinhold, I'll re-implement David's patch after a re-base and upload another patchset for review. Ian http://codereview.appspot.com/4808063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Am Sunday, 31. July 2011, 01:48:16 schrieb Carl Sorensen: On 7/30/11 4:37 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does It would be. With the current \once\override you can also change all object in the whole score. With a tweak you have to change each and every voice separately. I guess we'll have this out in GLISS. But I think it would be a major inconvenience. If I want to have the all the notes at the current instant made red, I can do it with a single call to \once \override. If we make \once \override work like \tweak, I'd need a call for each note head. Yes, I'd argue strongly against removing \once\override. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Pixel comparison of 2.14.2 regtests
Comparing with 2.14.0. Lots of changes because of the new brace shape. Some minor staff positioning changes. Beams in different places on 2 tests: see the attached. -- Phil Holmes Bug Squad attachment: tuplet-bracket-cross-staff.pngattachment: note-line.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Am Sunday, 31. July 2011, 01:56:02 schrieb David Kastrup: Carl Sorensen c_soren...@byu.edu writes: The principles: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, It works on the whole chord, unfortunately (similar to how \harmonic and fingering do only work within a chord). In other words, it's equivalent to \tweak c Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
Am Sunday, 31. July 2011, 07:45:20 schrieb Graham Percival: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1732 This is unfortunate, since it means that we can't have a release candidate on Aug 01. Without a reproducible test case, it's simply not possible to debug the problem. As I mentioned in my comment, the GUILE error message indicates an error in the threaded code. But there is no other indication where the problem might be. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Sunday, 31. July 2011, 01:56:02 schrieb David Kastrup: Carl Sorensen c_soren...@byu.edu writes: The principles: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, It works on the whole chord, unfortunately (similar to how \harmonic and fingering do only work within a chord). In other words, it's equivalent to \tweak c Like with the hierarchy of contexts that makes it a mess to figure out just where and when to set a property, the tweak should percolate to where it makes sense. Personally, I'd consider it more predictable if c did not create a chord, but it would likely make a mess of existing music functions and their application designed by reverse engineering. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
Hi Pál (besides, are you Pál Benkő the chess master?) Thanks for this nice review. 1. about the very existence of usable-duration-logs - ok, it's generic, but who uses this genericity? is it not always (0 -1 -2 -3)? is it not always a range with lower end -3? is it not always a range? It can be something else. Some recent editors are also using half and quarter rests. One may also want to only have whole rests, so I guess we don't have to hard-code -3. I don't honestly know if this has to be range or if bounds would be enough. I solved the issue I mentioned in the last comment, so that church rests only pick duration logs from usable-duration-logs. I applied the other changes. Thanks again, Bertrand http://codereview.appspot.com/4536068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 3)
Am Sunday, 31. July 2011, 01:34:16 schrieb Graham Percival: ** Proposal details When you run make or make doc, * All output will be saved to various log files, with the exception of output directly from make(1). * By default, no other output will be displayed on the console, with one exception: if a build fails, we might display some portion(s) of log file(s) which give useful clues about the reason for the failure. I don't like this at all. This means that we won't see ANY warnings triggered by snippets in the docs. Shouldn't we ensure that the examples in the documentation compile nicely without warnings (we shouldn't advocate code that causes warnings!)? To see the warnings, you'll then have to wade through thousands of log files... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Bar line shading in PNGs
Don't think this is a problem, but it is a bit interesting. I've been trying to run my pixel comparator to compare 15.7 to 15.5 and getting a difference in the bar lines of every image - presumably owing to the work to stop the PDF artefacts. Looking carefully at the bar lines, you can see they're not actually black - they're various shades of grey, in both versions. The difference is that the shading has changed. I attach 2 highly magnified images - one with normal contrast, and one with it adjusted to emphasise the shading. -- Phil Holmes Bug Squad attachment: accidentalenh.jpgattachment: accidental.jpg___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 3)
When you run make or make doc, * All output will be saved to various log files, with the exception of output directly from make(1). * By default, no other output will be displayed on the console, with one exception: if a build fails, we might display some portion(s) of log file(s) which give useful clues about the reason for the failure. I don't like this at all. This means that we won't see ANY warnings triggered by snippets in the docs. Shouldn't we ensure that the examples in the documentation compile nicely without warnings (we shouldn't advocate code that causes warnings!)? To see the warnings, you'll then have to wade through thousands of log files... Well, it should be not too difficult to let the build system create a directory called `log-errors' and do soft links to the corresponding error log files. Ditto for a `log-warnings'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 3)
- Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com To: lilypond-devel@gnu.org Sent: Sunday, July 31, 2011 4:40 PM Subject: Re: GOP-PROP 5: build system output (probable 3) Am Sunday, 31. July 2011, 01:34:16 schrieb Graham Percival: ** Proposal details When you run make or make doc, * All output will be saved to various log files, with the exception of output directly from make(1). * By default, no other output will be displayed on the console, with one exception: if a build fails, we might display some portion(s) of log file(s) which give useful clues about the reason for the failure. I don't like this at all. This means that we won't see ANY warnings triggered by snippets in the docs. Shouldn't we ensure that the examples in the documentation compile nicely without warnings (we shouldn't advocate code that causes warnings!)? To see the warnings, you'll then have to wade through thousands of log files... make doc already produces hundreds of warnings. It might be thousands, I've not counted. I don't see anyone paying any attention to them. The point is that most devs simply don't notice them - 1 warning line is less than .0002% of the output. The aim is to reduce this pointless output and make it easier to focus on warnings, but we have to do it in ways that are possible. This is what's proposed. Please can we stop re-going over this and get to a point where I can do something? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
make doc
Hi Phil, I don't know if this is in relation with your work on extract_texi_filenames.py and don't remember if it was spitted before. Many of the calls to this script, especially each time it will process an out-www/web.texi I get something weird with searchpath: No such file: file.itexi Search path: .:./out-www:. I'm in sync with 54b02666750062788185bd3f99e644d621e348c2 and about to push some xref-fixes on the French version. If interested, the 10 Mo of logs are available. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
On Sun, Jul 31, 2011 at 10:26:11AM +0200, David Kastrup wrote: Modern operating systems don't give your code any leftovers from a previous run. That would be a security violation. I'm certain that I've seen an uninitialized variable being 123456789 in some cases, and 0 in others. I sincerly doubt that modern operating systems remember what collection of bits were in memory at just before the first initialization, so the security step would surely be simply writing 0s to that location in memory. I think it's quite reasonable that if C++ interpreted a random collection of bits (i.e. uninitailized memory), guile would barf when trying to do some math with the resulting value. But since that pile of bits would be set to 0 on program exit, and if the initial programmer just assumed that uninitialized variables were 0 (as they are in java), that would very neatly explain why we've never seen two successive runs of this problem. And even user stack initialization below the stack pointer is not stochastical. Hmm, I may be misunderstanding this sentence due to my relative ignorance of low-level OS stuff (I had a quite varied career as an undergraduate). If you mean the computer starts reserving pieces of memory for variables in different places in memory on each run, then my 0-theorizing above is false. But I'm pretty certain that I've seen student programs (running in 3-year-old cygwin on windows 2000, so perhaps not the most secure of environments) share unitialized variable locations across program runs. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Modify chord-name-engraver to call capo-handler (issue4800051)
On 31/07/11 11:35, lemniskata.bernoull...@gmail.com wrote:
New patch uploaded. Passes regtests made from scratch.
http://codereview.appspot.com/4800051/
Assuming that it's okay and is applied, I've redone my docu patch. The
snippet prints a four-bar phrase with just the standard chord (to trap
the regression that bit us this time :-), then sets the capoPitch to
print transposed chords for the next four bars, then sets capoVertical
to print chords one above the other for the last four bars.
iirc that will then become the regression test for this feature?
Cheers,
Wol
From fa8b9103ad01ec813807eedf9cea8fedb03d6f94 Mon Sep 17 00:00:00 2001
From: Wol anth...@youngman.org.uk
Date: Sun, 31 Jul 2011 17:10:13 +0100
Subject: [PATCH 2/2] Document the use of the capoPitch and capoVertical
properties
---
Documentation/notation/chords.itely | 50 +++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/Documentation/notation/chords.itely
b/Documentation/notation/chords.itely
index 1109075..982ed4b 100644
--- a/Documentation/notation/chords.itely
+++ b/Documentation/notation/chords.itely
@@ -506,6 +506,56 @@ Rests passed to a @code{ChordNames} context will cause the
}
@end lilypond
+@cindex Transposing guitar chords for capo
+
+If the @code{capoPitch} property is set, then the chords will additionally be
printed
+transposed for a guitar with the capo set appropriately. By default the chords
are
+printed on one line, but if the @code{capoVertical} property is set, the
chords will be
+printed one above the other.
+
+In make-pitch, leave the first argument at 0, the second argument is the
+interval (-2 is a third), and the third argument adjusts it up or down a
+semitone.
+
+@lilypond[verbatim,quote,ragged-right]
+
+ \new ChordNames \chordmode {
+c1
+r1
+g1
+c1
+\break
+c1
+r1
+g1
+c1
+\break
+c1
+r1
+g1
+c1
+ }
+ \chordmode {
+c1
+r1
+g1
+c1
+\break
+\set ChordNames.capoPitch = #(ly:make-pitch 0 -2 -1/2)
+c1
+r1
+g1
+c1
+\break
+\set ChordNames.capoVertical = ##t
+c1
+r1
+g1
+c1
+ }
+
+@end lilypond
+
@snippets
@c Keep index entries with following snippet
--
1.7.3.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
Graham Percival gra...@percival-music.ca writes: On Sun, Jul 31, 2011 at 10:26:11AM +0200, David Kastrup wrote: Modern operating systems don't give your code any leftovers from a previous run. That would be a security violation. I'm certain that I've seen an uninitialized variable being 123456789 in some cases, and 0 in others. I sincerly doubt that modern operating systems remember what collection of bits were in memory at just before the first initialization, so the security step would surely be simply writing 0s to that location in memory. If the stack never previously was used to that depth. I did not say that you don't get leftovers from previous function calls. And yes, you usually get zeros for uninitialized memory. And even user stack initialization below the stack pointer is not stochastical. Hmm, I may be misunderstanding this sentence due to my relative ignorance of low-level OS stuff (I had a quite varied career as an undergraduate). If you mean the computer starts reserving pieces of memory for variables in different places in memory on each run, then my 0-theorizing above is false. That's not what I mean, though Linux indeed nowadays has kernel parameters for randomizing its virtual storage layout to make it harder to developer exploits for system libraries. If bugs pop up only occasionally, it might be worth switching this off and see whether it stabilizes the problem in either direction. But I'm pretty certain that I've seen student programs (running in 3-year-old cygwin on windows 2000, so perhaps not the most secure of environments) share unitialized variable locations across program runs. Windows 2000 (not NT-based IIRC) does not usefully employ memory protection IIRC, so likely Cygwin does not add all too much on top. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
On 31/07/11 17:47, David Kastrup wrote: Windows 2000 (not NT-based IIRC) does not usefully employ memory protection IIRC, so likely Cygwin does not add all too much on top. Windows 2000 most definitely IS NT-based. You're thinking of Windows ME, which is the last of the DOS7/Win9x line. Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
Wols Lists antli...@youngman.org.uk writes: On 31/07/11 17:47, David Kastrup wrote: Windows 2000 (not NT-based IIRC) does not usefully employ memory protection IIRC, so likely Cygwin does not add all too much on top. Windows 2000 most definitely IS NT-based. You're thinking of Windows ME, which is the last of the DOS7/Win9x line. Ok. It might have been that the security implications of uninitialized memory have not caught up with NT/2000 development at that point of time. It took quite some time before Linux closed that leak, too. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Incorporates suggestions from Neil into footnotes. (issue4798063)
On 2011/07/31 10:46:54, MikeSol wrote: Hey all, These incorporate several comments from Neil regarding automatic footnotes. Sorry for having missed them before, Neil! Cheers, MS Forgot to mention that this passes regtests. Cheers, MS http://codereview.appspot.com/4798063/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Out of town
Hey all, I'll be out of town until Monday(ish) and my internet connection will be spotty at best. Sorry in advance for any lag in responding to the list. In case anyone in the UK wants to attend a concert of my LilyPonderful piece norman (age 1), it'll be playing in Saint Paul's Hall in Huddersfield, England on Thursday evening @ 8pm. Come one come all! Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests for 2.15.7
On Jul 31, 2011, at 11:52 AM, Phil Holmes wrote:
tuplet-rest.ly is different and looks like
http://code.google.com/p/lilypond/issues/detail?id=1720 has been fixed.
Except it's down as patch needs work. Explanation, please?
1720 is not really fixed - it is just that LilyPond makes smarter automatic
decisions. If you force the bracket down, it'll still collide. So, I'd change
the example to include a manual override for the TupletBracket direction but
keep the issue open.
\context Voice \relative c'' {
\override TupletBracket #'direction = #DOWN
\time 2/4
\times 2/3 { r c,,, c''' }
}
Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilynet down?
Hi all! Is there any problem with www.lilynet.net ? I'm landing at Test Page for the Apache HTTP Server on Fedora telling me: This page is used to test the proper operation of the Apache HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly, but has not yet been configured. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue4553056)
I updated the patch. There's now a list of special characters and a \replace command for markups. The escape character is now '§'. It's the only one that works great with lyrics. And it isn't used elsewhere in LilyPond's syntax. The syntax for using the list of special characters #(include-special-characters) is a bit ackward but I didn't found anything better. Regards, Bertrand http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Make doc failing
Phil, From: Phil Holmes [m...@philholmes.net] Sent: 31 July 2011 10:14 To: James Lowe; lilypond-devel@gnu.org Subject: Re: Make doc failing - Original Message - From: James Lowe james.l...@datacore.com To: lilypond-devel@gnu.org Sent: Sunday, July 31, 2011 1:40 AM Subject: Make doc failing Hello, I'm not able to make doc. The last time it worked was around wed last week (I don't make doc that often). [snip] FYI I ran a completely new build last night UK time - nuked the build directory, pulled git and ran make; make website and make doc. All was OK. -- Thanks, I have done that just now and it does indeed build ok. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Out of town
Mike, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of m...@apollinemike.com [m...@apollinemike.com] Sent: 31 July 2011 18:30 To: lilypond-devel (lilypond-devel@gnu.org) Subject: Out of town Hey all, I'll be out of town until Monday(ish) and my internet connection will be spotty at best. Sorry in advance for any lag in responding to the list. In case anyone in the UK wants to attend a concert of my LilyPonderful piece norman (age 1), it'll be playing in Saint Paul's Hall in Huddersfield, England on Thursday evening @ 8pm. Come one come all! I knew I'd heard this venue before for Contemporary music. http://www.bbc.co.uk/programmes/b00yhq6n [last year's link] No doubt the will be re-recording a new programme for this year and it will be broadcast at some point for all us UK people to hear. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GOP-PROP 5: build system output (probable 3)
Hello, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Phil Holmes [m...@philholmes.net] Sent: 31 July 2011 17:17 To: Reinhold Kainhofer; lilypond-devel@gnu.org Subject: Re: GOP-PROP 5: build system output (probable 3) - Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com To: lilypond-devel@gnu.org Sent: Sunday, July 31, 2011 4:40 PM Subject: Re: GOP-PROP 5: build system output (probable 3) To see the warnings, you'll then have to wade through thousands of log files... make doc already produces hundreds of warnings. It might be thousands, I've not counted. I don't see anyone paying any attention to them. --- +1 BTW - I did offer to help with the 'missing node stuff' in the translations a while back on the lists, but I don't know what to do exactly but if it's a case of just wading through tely files and putting in English strings or removing them - which is boring I know - I can do this). regards james ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Close loopholes in note-collision logic (issue4293054)
Passes Make and reg tests http://code.google.com/p/lilypond/issues/detail?id=1792#c1 http://codereview.appspot.com/4293054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue4553056)
passes make and reg tests http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Lilynet down?
Hello, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Jean-Charles Malahieude [lily...@orange.fr] Sent: 31 July 2011 18:41 To: Lily Bugs; lilypond-devel Subject: Lilynet down? Hi all! Is there any problem with www.lilynet.net ? I'm landing at Test Page for the Apache HTTP Server on Fedora telling me: This page is used to test the proper operation of the Apache HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly, but has not yet been configured. --- Me too! --snip-- If you are a member of the general public: The fact that you are seeing this page indicates that the website you just visited is either experiencing problems, or is undergoing routine maintenance. --snip-- Sunday evening...I am guessing this is routine maintenance. Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: PATCH: Countdown delayed by Monster Trucks
Hello From: lemniskata.bernoull...@gmail.com [lemniskata.bernoull...@gmail.com] on behalf of Jan Warchoł [lemniskata.bernoulli...@gmail.com] Sent: 31 July 2011 07:10 To: James Lowe Cc: Graham Percival; Devel Subject: Re: PATCH: Countdown delayed by Monster Trucks 2011/7/31 James Lowe james.l...@datacore.com: I imagine some underground bunker with walls of charts and a big map of the lilypond code with ladies wearing headsets pushing flags around with all our names on them. And Graham watches everything smoking a cigar :) No...stroking a white fluffy cat you mean? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
opening eps files in Lilydev
Hi, my Lilydev cannot open eps files which are produced by running regression tests. I have installed everything that shows when i search for eps viewer in Software Center, but it didn't help. I tried gv, but it crashed on them. Suggestions? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
Passes Make and there is a reg test difference which looks ok. I created a tracker http://code.google.com/p/lilypond/issues/detail?id=1794 so people can see this but also because this has been going on for a while and the tracker will at least keep this on people's radars. http://codereview.appspot.com/4536068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: opening eps files in Lilydev
hello, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Janek Warchoł [lemniskata.bernoull...@gmail.com] Sent: 31 July 2011 21:09 To: lilypond-devel@gnu.org Subject: opening eps files in Lilydev Hi, my Lilydev cannot open eps files which are produced by running regression tests. I have installed everything that shows when i search for eps viewer in Software Center, but it didn't help. I tried gv, but it crashed on them. Suggestions? cheers, Janek Download Acrobat Reader from Adobe They have a Linux Version you can install the .deb file James PS shhh! Don't tell Jan N ;) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Modify chord-name-engraver to call capo-handler (issue4800051)
2011/7/31 Wols Lists antli...@youngman.org.uk: Assuming that it's okay and is applied, I've redone my docu patch. Uploaded to Rietveld. I see one trailing whitespace (after By default the chords are), also there should be two spaces after a period which ends sentence. The snippet prints a four-bar phrase with just the standard chord (to trap the regression that bit us this time :-), then sets the capoPitch to print transposed chords for the next four bars, then sets capoVertical to print chords one above the other for the last four bars. iirc that will then become the regression test for this feature? Yes, a regression test should contain a similar snippet. Could you add the regression test file to your commit? (create a new file in input/regression, named appropriately, use 'git add input/regression/your regtest filename' to add it to what would be commited, and commit. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: opening eps files in Lilydev
W dniu 31 lipca 2011 22:39 użytkownik James Lowe james.l...@datacore.com napisał: Download Acrobat Reader from Adobe They have a Linux Version you can install the .deb file I had it installed already (i don't remember whether i used sudo apt-get or a .deb file, but i think it doesn't matter), and it doesn't work - says Adobe Reader could not open 'tabulature-full-notation.eps' because it is either not a supported file type or because the file has been damaged. PS shhh! Don't tell Jan N ;) :) thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown delayed by Monster Trucks
W dniu 31 lipca 2011 22:07 użytkownik James Lowe james.l...@datacore.com napisał: From: Jan Warchoł [lemniskata.bernoulli...@gmail.com] And Graham watches everything smoking a cigar :) No...stroking a white fluffy cat you mean? I didn't know Winston had a cat! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
buglet in mf2pt1 2.4.4
Scott,
the patch below is needed to avoid a non-integer argument to hsbw in
the definition of `.notdef'. LilyPond produces such fonts
(e.g. feta-braces-a), causing the following two warnings:
t1asm: unknown charstring command `91.60803'
fontforge: Stack underflow on hsbw in .notdef
[Note to LilyPonders: This problem is harmless and can be completely
ignored.]
Werner
==
--- mf2pt1.old 2008-01-28 05:41:00.0 +0100
+++ mf2pt1 2011-07-31 23:54:51.0 +0200
@@ -726,7 +726,7 @@
{
print OUTFILE ENDTRAILER;
/.notdef {
-0 @{[$fontbbox[2]-$fontbbox[0]]} hsbw
+0 @{[frac_string (frac_approx ($fontbbox[2] - $fontbbox[0]))]}hsbw
endchar
} ND
end
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)
On 2011/07/31 20:10:30, J_lowe wrote: Passes Make and there is a reg test difference which looks ok. I created a tracker http://code.google.com/p/lilypond/issues/detail?id=1794 so people can see this but also because this has been going on for a while and the tracker will at least keep this on people's radars. Actually I made a mistake in my reg check process (missed the make after the patch apply). It now looks as Bertrand says it should. http://codereview.appspot.com/4536068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Modify chord-name-engraver to call capo-handler (issue4800051)
On 31/07/11 22:00, Janek Warchoł wrote:
2011/7/31 Wols Lists antli...@youngman.org.uk:
Assuming that it's okay and is applied, I've redone my docu patch.
Uploaded to Rietveld. I see one trailing whitespace (after By
default the chords are), also there should be two spaces after a
period which ends sentence.
The snippet prints a four-bar phrase with just the standard chord
(to trap the regression that bit us this time :-), then sets the capoPitch
to print transposed chords for the next four bars, then sets capoVertical
to print chords one above the other for the last four bars.
iirc that will then become the regression test for this feature?
Yes, a regression test should contain a similar snippet. Could you
add the regression test file to your commit? (create a new file in
input/regression, named appropriately, use 'git add
input/regression/your regtest filename' to add it to what would be
commited, and commit.
Regression test attached. I've looked at the other regression tests and
tried to make it similar. Basically just put the header stuff above my
test/docu snippet.
Cheers,
Wol
From cf59539f59324583bbe595343e6ea3ca0c754791 Mon Sep 17 00:00:00 2001
From: Wol anth...@youngman.org.uk
Date: Sun, 31 Jul 2011 23:13:38 +0100
Subject: [PATCH 3/3] Add regression test for guitar capos
---
input/regression/chord-capo.ly | 44
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 input/regression/chord-capo.ly
diff --git a/input/regression/chord-capo.ly b/input/regression/chord-capo.ly
new file mode 100644
index 000..aa669e2
--- /dev/null
+++ b/input/regression/chord-capo.ly
@@ -0,0 +1,44 @@
+\version 2.14.0
+
+\header{
+ texidoc=Properties capoPitch, capoVertical: display chordnames, suitably
+transposed for a guitar capo, either in a line or one above the other.
+
+}
+
+
+ \new ChordNames \chordmode {
+c1
+r1
+g1
+c1
+\break
+c1
+r1
+g1
+c1
+\break
+c1
+r1
+g1
+c1
+ }
+ \chordmode {
+c1
+r1
+g1
+c1
+\break
+\set ChordNames.capoPitch = #(ly:make-pitch 0 -2 -1/2)
+c1
+r1
+g1
+c1
+\break
+\set ChordNames.capoVertical = ##t
+c1
+r1
+g1
+c1
+ }
+
--
1.7.3.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Modify chord-name-engraver to call capo-handler (issue4800051)
On 7/31/11 4:17 PM, Wols Lists antli...@youngman.org.uk wrote: On 31/07/11 22:00, Janek Warchoł wrote: 2011/7/31 Wols Lists antli...@youngman.org.uk: Assuming that it's okay and is applied, I've redone my docu patch. Uploaded to Rietveld. I see one trailing whitespace (after By default the chords are), also there should be two spaces after a period which ends sentence. The snippet prints a four-bar phrase with just the standard chord (to trap the regression that bit us this time :-), then sets the capoPitch to print transposed chords for the next four bars, then sets capoVertical to print chords one above the other for the last four bars. Do we need four bars? Why not just do three bars -- one with capoPitch '(), another with capoPitch set, and a third with capoVertical? We like to get examples and regtests as simple as can be. iirc that will then become the regression test for this feature? Yes, a regression test should contain a similar snippet. Could you add the regression test file to your commit? (create a new file in input/regression, named appropriately, use 'git add input/regression/your regtest filename' to add it to what would be commited, and commit. Regression test attached. I've looked at the other regression tests and tried to make it similar. Basically just put the header stuff above my test/docu snippet. This is exactly the right procedure. Thanks! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue4553056)
On 7/31/11 11:41 AM, bordage.bertr...@gmail.com bordage.bertr...@gmail.com wrote: I updated the patch. There's now a list of special characters and a \replace command for markups. The escape character is now '§'. It's the only one that works great with lyrics. And it isn't used elsewhere in LilyPond's syntax. This escape is not available on US keyboards, so it's as much work to use the escape character as to put in the UTF character directly. For me, as a US user, that seems to negate the purpose for the patch. What was the problem with the previous escape characters? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue4553056)
Ouch...
The problem with '' is that it fails on lyrics:
this works:
\new Lyrics \lyricmode { as; }
but this doesn't:
\new Lyrics \lyricmode { s; }
There is the same kind of issues with almost every easy-to-type special
character:
@ % $ # \ / ^ ~ + = * ; ( ) [ ] { }
This is the exact list of every possible escape characters for a french
keyboard under linux:
§ £ µ € ¤ ¹ ² ' ` © ¨ ø Ø ≤ ≥ « » “ ” ↓ ¬ × ÷ ¿ ¡ ∕ ⋅ …
Of course, only a few of them are available under windows:
§ £ µ € ¤ ' `
If we consider US, british, german and spanish keyboards, this only
gives these two very bad characters:
' `
The best solution may be to solve this lyric problem first :\
Bertrand
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Anything speaking against this simplification?
On Sat, Jul 30, 2011 at 5:19 PM, David Kastrup d...@gnu.org wrote: music_list in parser.yy temporarily maintains an awkward half-self-referential data structure in order to have fast append. It makes more sense in my opinion to use prepend and reverse afterwards. Fast append in theory may show minimally better cache coherency at the cost of uglier code and uglier data structures. So I'd just like to do the following (no full regtest yet). Comments? I'm fine either way. Originally all lists in the parser were C++ ones (doubly linked IIRC) with a consistent direction. Having the Scheme lists not reverse direction may have seemed easier at the time. The performance overhead (even if you used non-destructive reverse) is probably neglible; I wouldn't bother measuring it. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc
On Sun, Jul 31, 2011 at 06:29:33PM +0200, Jean-Charles Malahieude wrote: No such file: file.itexi Search path: .:./out-www:. Extremely normal; happens all the time. :( Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Modify chord-name-engraver to call capo-handler (issue4800051)
New patch set uploaded (adding a regtest). 2011/8/1 Wols Lists antli...@youngman.org.uk: Regression test attached. I've looked at the other regression tests and tried to make it similar. Great! http://codereview.appspot.com/4800051/diff/14003/input/regression/chord-capo.ly File input/regression/chord-capo.ly (right): http://codereview.appspot.com/4800051/diff/14003/input/regression/chord-capo.ly#newcode4 input/regression/chord-capo.ly:4: texidoc=Properties capoPitch, capoVertical: display chordnames, suitably trailing whitespace here http://codereview.appspot.com/4800051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fixcc.py run on Aug 01
Graham Percival graham at percival-music.ca writes: I will be running fixcc.py on the git repo Tabs-to-spaces and trailing-spaces-strip are now done by the Python script, so you don't need to do these steps by hand. Apologies for the inconvenience; this should be a one-time painful transition. I did a dry run on my outstanding patches and found it inconvenient, but not really painful. I thought the option git rebase --ignore-whitespace might make everything automatic, but I still needed to hand-merge. (In fact, git did just well without the option, on my patches.) There were two nits that I had found with fixcc after discussion died down. One of them makes a couple files change on the /second/ run of fixcc. People might end up running the script twice, and then would need to merge these files. Therefore I pushed my (well-tested) nitpick fix. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
