Re: [PATCH] for GUB - NSIS: rework uninstall logic for LilyPad.
Thanks, applied and it still compiles. We'll find out if it works in a few hours. Cheers, - Graham On Tue, Jul 13, 2010 at 1:43 AM, Patrick McCarty pnor...@gmail.com wrote: Hi, Here is a patch for GUB that fixes an uninstallation issue for Windows LilyPad: http://code.google.com/p/lilypond/issues/detail?id=1179 Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] for GUB - NSIS: Speed up uninstallers.
Thanks, applied and it still compiles. We'll find out if it works in a few hours. Cheers, - Graham On Sun, Jul 11, 2010 at 5:09 AM, Patrick McCarty pnor...@gmail.com wrote: Hello, The changes found in this patch make the GUB Windows uninstallers *much* faster. Before, uninstalling LilyPond on Windows could take up to 10 minutes, and these changes appear to have cut that time down to about 20 seconds. As the commit description notes, I incorporated the recent script improvements from this wiki page: http://nsis.sourceforge.net/Uninstall_only_installed_files Let me know if there are any problems. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Revised autobeam settings patch (issue1682049)
Thanks for the careful review!
Carl
http://codereview.appspot.com/1682049/diff/35001/36004
File Documentation/notation/rhythms.itely (right):
http://codereview.appspot.com/1682049/diff/35001/36004#newcode1055
Documentation/notation/rhythms.itely:1055: predefined default values for
these values can be found in
On 2010/07/11 23:31:50, Neil Puttock wrote:
for these properties
Done.
http://codereview.appspot.com/1682049/diff/35001/36004#newcode1060
Documentation/notation/rhythms.itely:1060: \score{
On 2010/07/11 23:31:50, Neil Puttock wrote:
\score {
Done.
http://codereview.appspot.com/1682049/diff/35001/36004#newcode1730
Documentation/notation/rhythms.itely:1730: @funindex beamExceptions
On 2010/07/11 23:31:50, Neil Puttock wrote:
+ beatStructure
Done, + alphabetized the entries.
http://codereview.appspot.com/1682049/diff/35001/36004#newcode1755
Documentation/notation/rhythms.itely:1755: for the beam type, use it to
determine the valid places where
On 2010/07/11 23:31:50, Neil Puttock wrote:
beam-type ?
I think not, because we're not talking about an argument to a function
call or an entry in an alist here. We're talking about something that
comes from the music. But I could be convinced otherwise.
http://codereview.appspot.com/1682049/diff/35001/36004#newcode1824
Documentation/notation/rhythms.itely:1824: @emph{complete} exceptions
list. That is, every exception that should
On 2010/07/11 23:31:50, Neil Puttock wrote:
lists
Changed to singular for all. beamExceptions is now a context property,
and there is only *one* beamException value at any given time.
http://codereview.appspot.com/1682049/diff/35001/36009
File
Documentation/snippets/new/conducting-signs,-measure-grouping-signs.ly
(right):
http://codereview.appspot.com/1682049/diff/35001/36009#newcode16
Documentation/snippets/new/conducting-signs,-measure-grouping-signs.ly:16:
the measure. @code{time} and @code{set-time-signature} both apply
On 2010/07/11 23:31:50, Neil Puttock wrote:
@code{\time}
Done.
http://codereview.appspot.com/1682049/diff/35001/36009#newcode18
Documentation/snippets/new/conducting-signs,-measure-grouping-signs.ly:18:
@code{beatStructure} or @code{baseUnit} that are set in
On 2010/07/11 23:31:50, Neil Puttock wrote:
baseMoment
Done.
http://codereview.appspot.com/1682049/diff/35001/36014
File input/regression/auto-beam-beaming-override.ly (right):
http://codereview.appspot.com/1682049/diff/35001/36014#newcode11
input/regression/auto-beam-beaming-override.ly:11: \version 2.13.27
On 2010/07/11 23:31:50, Neil Puttock wrote:
2.13.28
Done.
http://codereview.appspot.com/1682049/diff/35001/36016
File input/regression/beaming-ternary-metrum.ly (right):
http://codereview.appspot.com/1682049/diff/35001/36016#newcode2
input/regression/beaming-ternary-metrum.ly:2: \version 2.13.27
On 2010/07/11 23:31:50, Neil Puttock wrote:
2.13.28
Done.
http://codereview.appspot.com/1682049/diff/35001/36017
File input/regression/les-nereides.ly (right):
http://codereview.appspot.com/1682049/diff/35001/36017#newcode1
input/regression/les-nereides.ly:1: \version 2.13.27
On 2010/07/11 23:31:50, Neil Puttock wrote:
2.13.28
Done.
http://codereview.appspot.com/1682049/diff/35001/36019
File lily/beam-engraver.cc (right):
http://codereview.appspot.com/1682049/diff/35001/36019#newcode309
lily/beam-engraver.cc:309: baseMoment ,
On 2010/07/11 23:31:50, Neil Puttock wrote:
move to top
Done.
http://codereview.appspot.com/1682049/diff/35001/36025
File lily/timing-translator.cc (right):
http://codereview.appspot.com/1682049/diff/35001/36025#newcode62
lily/timing-translator.cc:62: context ()-set_property (baseMoment,
On 2010/07/11 23:31:50, Neil Puttock wrote:
add to translator doc (+ others missing)
Done.
http://codereview.appspot.com/1682049/diff/35001/36026
File ly/bagpipe.ly (right):
http://codereview.appspot.com/1682049/diff/35001/36026#newcode12
ly/bagpipe.ly:12: \version 2.13.27
On 2010/07/11 23:31:50, Neil Puttock wrote:
2.13.28
Done.
http://codereview.appspot.com/1682049/diff/35001/36028
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/1682049/diff/35001/36028#newcode21
ly/music-functions-init.ly:21: \version 2.13.27
On 2010/07/11 23:31:50, Neil Puttock wrote:
2.13.28
Done.
http://codereview.appspot.com/1682049/diff/35001/36028#newcode675
ly/music-functions-init.ly:675: (revert-time-signature-setting
time-signature context))
On 2010/07/11 23:31:50, Neil Puttock wrote:
indent
Done.
http://codereview.appspot.com/1682049/diff/35001/36030
File scm/auto-beam.scm (right):
http://codereview.appspot.com/1682049/diff/35001/36030#newcode62
scm/auto-beam.scm:62: (not (eq? (member moment beat-structure) #f)))
On 2010/07/11 23:31:50, Neil Puttock wrote:
(pair? (member moment beat-structure))
Oh, OK. We return at least a single-item list if it's a member.
http://codereview.appspot.com/1682049/diff/35001/36030#newcode127
scm/auto-beam.scm:127: ;; no rule applies, so end at
Re: Revised autobeam settings patch (issue1682049)
A new patch set has been uploaded. Thanks, Carl http://codereview.appspot.com/1682049/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add \path markup command, and use it for \eyeglasses. (issue1730044)
I am currently working on integrating my work with Mike's new stencil routines, so I'll post a new patch when that's ready. Jan: I like your idea about using a separate module to evaluate the various commands, though IIUC, this would be duplicating the work done by the backend path procedures in output-ps.scm and output-svg.scm, since they already take a list of commands and convert them to either PostScript or SVG paths. Thanks, Patrick http://codereview.appspot.com/1730044/diff/17001/12002 File scm/define-markup-commands.scm (right): http://codereview.appspot.com/1730044/diff/17001/12002#newcode2782 scm/define-markup-commands.scm:2782: (make-override-markup '(line-cap-style . butt) On 2010/06/26 13:35:59, Carl wrote: indentation -- (make-override-markup is indented too far. Fixed, thanks. http://codereview.appspot.com/1730044/diff/17001/12003 File scm/output-ps.scm (right): http://codereview.appspot.com/1730044/diff/17001/12003#newcode279 scm/output-ps.scm:279: (ly:warning (_ unknown line-cap-style: ~S) On 2010/06/26 13:35:59, Carl wrote: Apparently there's a whitespace error on this line, as it wraps with nothing visible on the wrapped part. This is an artifact of the way Rietveld chose to display the diff. If you look at the line numbers, you'll see that everything lines up fine. http://codereview.appspot.com/1730044/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
Hi Joe, On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote: Does the attached patch help? For me, it reduces dramatically the number of times that combine_pure_heights (and also ly_scm2interval) is called, but it has very little effect on lilypond's overall running time (for the optimized build, at least). I've just tested this patch (after removing the bits which prevented it from applying; they look like they belong to a fix for issue 1152. :) It has a dramatic effect in several cases: on one 26 page score it's halved the compilation time to just over a minute. On Haipeng's `Harmonious' score (http://lists.gnu.org/archive/html/lilypond-user/2010-07/msg00122.html), I get the following results (both optimized): master: 3m40.766s patched: 2m3.297s Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Broken stem tremolos
Hi Reinhold,
I've been looking at Haipeng's `Harmonious' score, and it's thrown up
a problem with single note tremolos when they're not sequential:
\repeat tremolo 4 c16
works fine, but
\repeat tremolo 4 c16\mf
results in an incorrectly scaled note, since `make-repeat' reads the
dynamic as the second child of the repeated music (the same happens
with other events encapsulated in the EventChord, such as
articulations).
I've added a patch which fixes this by setting the child-count
correctly. Does it look OK?
Cheers,
Neil
From 1651046f900d47c5be6f3db47b3485bd07d3ec4e Mon Sep 17 00:00:00 2001
From: Neil Puttock n.putt...@gmail.com
Date: Tue, 13 Jul 2010 23:17:26 +0100
Subject: [PATCH] Fix bare stem tremolos.
* scm/music-functions.scm (make-repeat):
don't use length of 'elements for non-sequential repeat tremolos
---
scm/music-functions.scm | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/scm/music-functions.scm b/scm/music-functions.scm
index 9f173ff..ae02fb6 100644
--- a/scm/music-functions.scm
+++ b/scm/music-functions.scm
@@ -265,9 +265,14 @@ through MUSIC.
(set! (ly:music-property r 'element) main)
(set! (ly:music-property r 'repeat-count) (max times 1))
(set! (ly:music-property r 'elements) talts)
-(if (and (equal? name tremolo) ( (length (ly:music-property main 'elements)) 0))
+(if (and (equal? name tremolo)
+ (pair? (ly:music-property main 'elements)))
;; This works for single-note and multi-note tremolos!
- (let* ((children (length (ly:music-property main 'elements)))
+ (let* ((children (if (music-is-of-type? main 'sequential-music)
+ ;; \repeat tremolo n { ... }
+ (length (ly:music-property main 'elements))
+ ;; \repeat tremolo n c4
+ 1))
;; # of dots is equal to the 1 in bitwise representation (minus 1)!
(dots (1- (logcount (* times children
;; The remaining missing multiplicator to scale the notes by
@@ -282,7 +287,6 @@ through MUSIC.
(set! (ly:music-property r 'tremolo-type) tremolo-type)
(if (not (integer? mult))
(ly:warning (_ invalid tremolo repeat count: ~a) times))
- ;; \repeat tremolo n c4
;; Adjust the time of the notes
(ly:music-compress r (ly:make-moment 1 children))
;; Adjust the displayed note durations
--
1.7.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Can't get a patch through because of weekly development releases.
I appreciate the desire for frequent development releases, but there's got to be some better way to work with this that I don't understand. I'm trying to get a major patch approved that changes the syntax for autobeaming. Because it changes the syntax, I need to change documentation text, documentation examples in english, french, spanish, and german (plus potentially in hungarian and japanese), documentation snippets, regression tests, web examples, and convert-ly. Every one of these files needs a version. (And I haven't yet mentioned changes.tely). How the mao am I supposed to get a patch reviewed? I prepared the patch for 2.13.27, then updated it for 2.13.28, and now we're at 2.13.29. The review cycle is *longer* than the release cycle! I suppose there's some way to use xargs to fund the files changed in the patch and automatically (using sed) change every occurrence of 2.13.28 to 2.13.29, but I don't have the bash script-fu to do this. I'm starting to feel like I'll never get this 41-file patch off of my current issues and into the closed list. Any suggestions for better ways to handle this would be greatly appreciated. Thanks, Carl (can you tell I'm more than slightly frustrated over trying to chase version numbers?) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
On Tue, Jul 13, 2010 at 05:30:38PM -0600, Carl Sorensen wrote: Because it changes the syntax, I need to change documentation text, documentation examples in english, french, spanish, and german (plus potentially in hungarian and japanese), documentation snippets, regression tests, web examples, and convert-ly. Every one of these files needs a version. (And I haven't yet mentioned changes.tely). Hmm, I hadn't thought of that. How the mao am I supposed to get a patch reviewed? I prepared the patch for 2.13.27, then updated it for 2.13.28, and now we're at 2.13.29. The review cycle is *longer* than the release cycle! I suppose there's some way to use xargs to fund the files changed in the patch and automatically (using sed) change every occurrence of 2.13.28 to 2.13.29, but I don't have the bash script-fu to do this. If you have the patch as a single file, then (in vim) it would be %s/2.13.28/2.13.29/g But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. (my overall feeling is that a patch should not be closely tied to the release cycle, and that the proper solution would be to separate them somewhat -- a copypaste xarg line, or pre-made script for updating the version numbers, is probably the best way forward) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com wrote: Hi Joe, On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote: Does the attached patch help? For me, it reduces dramatically the number of times that combine_pure_heights (and also ly_scm2interval) is called, but it has very little effect on lilypond's overall running time (for the optimized build, at least). I've just tested this patch (after removing the bits which prevented it from applying; they look like they belong to a fix for issue 1152. :) It has a dramatic effect in several cases: on one 26 page score it's halved the compilation time to just over a minute. Ok, it seems like I should be benchmarking with bigger files; I was just trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on rietveld. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken stem tremolos
Am Mittwoch, 14. Juli 2010, um 00:18:32 schrieb Neil Puttock: Hi Reinhold, I've been looking at Haipeng's `Harmonious' score, and it's thrown up a problem with single note tremolos when they're not sequential: \repeat tremolo 4 c16 works fine, but \repeat tremolo 4 c16\mf results in an incorrectly scaled note, since `make-repeat' reads the dynamic as the second child of the repeated music (the same happens with other events encapsulated in the EventChord, such as articulations). Ah, good catch! I've added a patch which fixes this by setting the child-count correctly. Does it look OK? Yes, it makes sense. I've pushed it and also added two regtest cases to check for correct scaling with articulations/dynamics on notes inside a tremolo repeat. 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 http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't get a patch through because of weekly development releases.
On 7/13/10 5:41 PM, Graham Percival gra...@percival-music.ca wrote: On Tue, Jul 13, 2010 at 05:30:38PM -0600, Carl Sorensen wrote: Because it changes the syntax, I need to change documentation text, documentation examples in english, french, spanish, and german (plus potentially in hungarian and japanese), documentation snippets, regression tests, web examples, and convert-ly. Every one of these files needs a version. (And I haven't yet mentioned changes.tely). Hmm, I hadn't thought of that. How the mao am I supposed to get a patch reviewed? I prepared the patch for 2.13.27, then updated it for 2.13.28, and now we're at 2.13.29. The review cycle is *longer* than the release cycle! I suppose there's some way to use xargs to fund the files changed in the patch and automatically (using sed) change every occurrence of 2.13.28 to 2.13.29, but I don't have the bash script-fu to do this. If you have the patch as a single file, then (in vim) it would be %s/2.13.28/2.13.29/g Ahh, this provides a workable idea. But if you're working on a separate branch (as is right and proper for a major change), then I'm not certain how to go about it. I'm looking forward to opinions. git diff master version-patch sed s/2.13.28/2.13.29/g version-patch new-version-patch git checkout master git branch -f new-version git checkout new-version git apply new-version-patch git diff old-branch update-version-patch git checkout old-branch git apply update-version-patch git branch -D new-version I think this will work. It's quite a few commands, but much less than editing 41 files! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
