Re: Cleanup beam scoring code. (issue4001046)
> There is one diff remaining: see the attached file. I introduced > some streamlining of an inner loop, which affects the way we handle > beams that start/end with invisible stems. > > The compare image is the new one. I have no examples of tremolo beams > handy, but the new layout actually looks better to me. For me, it doesn't. While the old behaviour is not optimal, the new one looks really worse to me, especially in bar 3 (which is admittedly a quite artificial example). The most important issue for me: Why is there no slant of the beams? I currently have not enough time to closely follow the new code, but I suggest that `stemless tremolos' are handled similar to the tremolos within the 1/4 bars, but with shorter stems (this means that for computing the positions, the routine should pretend that there *are* stems). IMHO, the ideal vertical position is somewhere in the middle between the two images, *with* slant. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup beam scoring code. (issue4001046)
On 2/1/11 8:34 PM, "Han-Wen Nienhuys" wrote: > There is one diff remaining: see the attached file. I introduced > some streamlining of an inner loop, which affects the way we handle > beams that start/end with invisible stems. > > The compare image is the new one. I have no examples of tremolo beams > handy, but the new layout actually looks better to me. > > What do you guys think? I much prefer the new one. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup beam scoring code. (issue4001046)
There is one diff remaining: see the attached file. I introduced some streamlining of an inner loop, which affects the way we handle beams that start/end with invisible stems. The compare image is the new one. I have no examples of tremolo beams handy, but the new layout actually looks better to me. What do you guys think? On Wed, Feb 2, 2011 at 1:30 AM, wrote: > On 2011/02/01 22:12:13, Graham Percival wrote: >> >> I see some fairly crazy beams in >> input/regression/spacing-to-grace.ly >> input/regression/accidental-contemporary.ly >> ... etc... >> there's some really steep slopes. > > 0 > > Fixed for real now. > > > http://codereview.appspot.com/4001046/ > -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen <><>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup beam scoring code. (issue4001046)
On 2011/02/01 22:12:13, Graham Percival wrote: I see some fairly crazy beams in input/regression/spacing-to-grace.ly input/regression/accidental-contemporary.ly ... etc... there's some really steep slopes. 0 Fixed for real now. http://codereview.appspot.com/4001046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
LGTM On Tue, Feb 1, 2011 at 7:49 PM, wrote: > LGTM > > http://codereview.appspot.com/4095041/ > -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use queue for prioritizing slur scores. (issue4073048)
Thanks. Pushed. On Tue, Feb 1, 2011 at 8:55 PM, wrote: > LGTM, and I can confirm clean regtest comparison. > > > http://codereview.appspot.com/4073048/diff/1/lily/include/slur-configuration.hh > File lily/include/slur-configuration.hh (right): > > http://codereview.appspot.com/4073048/diff/1/lily/include/slur-configuration.hh#newcode68 > lily/include/slur-configuration.hh:68: friend class > Slur_configuration_less; > Indent. > > http://codereview.appspot.com/4073048/ > -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regression tests for white mensural ligature enhancements (issue3989049)
On Tue, Feb 01, 2011 at 10:33:17PM +0100, Benkő Pál wrote: > 2011/1/31 : > > http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode966 > > Documentation/notation/ancient.itely:966: \[ d\longa > > Can we put note durations for the first note of every new line (again as > > per the CG)? > > I'm afraid I don't get this. all first notes have duration, don't they? The first note on *every line*. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add Modal transformations (issue4126042)
Might it be worth having some predefined scales, i.e. \diatonicScale and
\pentatonicScale and the like?
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode823
Documentation/notation/pitches.itely:823: In a musical composition that
is based on a scale, a motive is frequently transformed in various ways.
wrap at 72 chars, please.
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode824
Documentation/notation/pitches.itely:824: It may be @emph{transposed} to
start at different
No @emph here, since the reader already knows about tranposition.
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode825
Documentation/notation/pitches.itely:825: places in the scale, it may be
@emph{inverted} around
Technically, this should be @notation{inverted}, since it's a musical
term. The output is the same, but using @notation instead would let us
theoretically change the display of all notation terms at once, if we
had some reason to do so.
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode828
Documentation/notation/pitches.itely:828: Lilypond provides functions
that may be used to apply these transformations to a motive.
I don't think we need a whole paragraph-sentence for this.
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode831
Documentation/notation/pitches.itely:831: Any note that does not is left
untransformed.}
This could be rewritten with half the number of words, and a clearer
single sentence. And since it's inside a @warning, I'm going to insist
on it.
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode838
Documentation/notation/pitches.itely:838: @funindex \modalTranspose
at the moment, we're writing out (elsewhere in the docs)
funindex \foo
funindex foo
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode840
Documentation/notation/pitches.itely:840: A motive can be transposed
within a given scale. The syntax is
Remove "the syntax is".
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode851
Documentation/notation/pitches.itely:851: motive = \relative c' { c8 d e
f g a b c }
I've never seen it spelled that way; I've always seen "motif".
I'm not saying that this is necessarily wrong, but please double-check.
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode862
Documentation/notation/pitches.itely:862: Any scale may be specified.
Here is an example with a pentatonic scale:
Remove "Here is an example..."
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode871
Documentation/notation/pitches.itely:871: \modalTranspose ges ees'
\blackNoteScale \motive
WTM is a "black note scale"? I'm a cellist.
What's wrong with \pentatonic? or pentatonicScale ?
http://codereview.appspot.com/4126042/diff/4002/Documentation/notation/pitches.itely#newcode899
Documentation/notation/pitches.itely:899: A motive can be inverted
within a given scale around a given pivot note. The syntax is
Remove "the syntax is"
http://codereview.appspot.com/4126042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Issue 1035 -- Add context property for negative frets (issue4056041)
LGTM, and passes regtests. http://codereview.appspot.com/4056041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme extension for playback experiments
> "Bernard" == Bernard Hurley writes: Bernard> Hi On Fri, Jan 28, 2011 at 11:14:56PM -0800, Dennis Raddle Bernard> wrote: >> I am completely new to LilyPond, but it seems like a good way to >> get beautiful notation, and, I hope, experiment with playback >> algorithms that add human touch. What I wonder is whether the >> Scheme extension language would let me easily examine the notes, >> dynamics, hairpins, articulations, and ornaments in the file and >> write that into some custom file format that can be processed by >> some of my Python scripts that experiment with human touch >> playback. >> Bernard> This link might be of interest to you: Bernard> http://www.nicta.com.au/people/chubbp/articulate It's also worth looking at the Director Musices work from http://www.speech.kth.se/music/performance/download/ Peter C ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Use queue for prioritizing slur scores. (issue4073048)
LGTM, and I can confirm clean regtest comparison. http://codereview.appspot.com/4073048/diff/1/lily/include/slur-configuration.hh File lily/include/slur-configuration.hh (right): http://codereview.appspot.com/4073048/diff/1/lily/include/slur-configuration.hh#newcode68 lily/include/slur-configuration.hh:68: friend class Slur_configuration_less; Indent. http://codereview.appspot.com/4073048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cleanup beam scoring code. (issue4001046)
I see some fairly crazy beams in input/regression/spacing-to-grace.ly input/regression/accidental-contemporary.ly ... etc... there's some really steep slopes. I know you said there was another patch coming, so all well and good. http://codereview.appspot.com/4001046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
LGTM http://codereview.appspot.com/4095041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Messed up adding issue 1499
On Tue, Feb 01, 2011 at 09:09:50PM -, Trevor Daniels wrote: > > Graham Percival wrote Tuesday, February 01, 2011 7:16 PM > >He's on holiday, so I did it. > > Any idea why my entry as contributor fails? It looks right. If you mean "why couldn't I edit that field", then I'd double-check that you're logged in. If you mean "why can't I be set to be the owner of this issue", then... I couldn't set it to you with the @googlemail part in there, but when I took it out I could set it to you. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regression tests for white mensural ligature enhancements (issue3989049)
(I don't know what happened to my reply, trying again.)
2011/1/31 :
> Just some minor syntax changes to make it read better. I hope no one is
> offended.
on the contrary!
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely
> File Documentation/notation/ancient.itely (left):
>
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#oldcode500
> Documentation/notation/ancient.itely:500:
> General: There is an inconsistency using 'notehead' vs 'note head', so
> we need to pick one and stick with it. There is nothing in the CG (yet)
> and so we could make a policy if someone has a strong opinion on this.
done.
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely
> File Documentation/notation/ancient.itely (right):
>
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode682
> Documentation/notation/ancient.itely:682: The @code{blackpetrucci} style
> gives noteheads usable in black
> "The @code{blackpetrucci} style produces ..."
done.
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode687
> Documentation/notation/ancient.itely:687: can be different if coloratio
> is used e.g. to notate triplets).
> "Because note head style does not influence flag count, a semiminima
> should be notated as @code{a8*2} not @code{a4) otherwise it will look
> like a minima."
>
> Then start a new para with no parenthesis:
>
> "The multiplyer can be differerent..."
modified, but not exactly this way. I wanted the multiplyer sentence
refer to the blackpetrucci section, not to the semipetrucci one.
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode813
> Documentation/notation/ancient.itely:813: using pitched rests.
> "Longa rests are not grouped automatically so have to be done manually
> by "
done.
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode942
> Documentation/notation/ancient.itely:942: property @code{flexa-width}.
> The length of a flexa can be set by the note head property
> @code{flexa-width}.
done.
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode966
> Documentation/notation/ancient.itely:966: \[ d\longa
> Can we put note durations for the first note of every new line (again as
> per the CG)?
I'm afraid I don't get this. all first notes have duration, don't they?
> http://codereview.appspot.com/3989049/diff/3002/Documentation/notation/ancient.itely#newcode1014
> Documentation/notation/ancient.itely:1014: Accidentals may collide with
> previous notes.
> Can we also suggest (if possible) any useful ways to avoid this or tell
> the user how they can workaround this - for instance using some 'hack'
> or spacing parameter - maybe even reference another section if it is
> useful. I just feel that stating this without a possible workaround is
> not as helpful as we could be, even if it is informative.
I'm afraid (based on the horrible horizontal spacing around ligatures)
that such a workaround is not possible. fortunately this situation is
very rare.
http://codereview.appspot.com/3989049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regression tests for white mensural ligature enhancements (issue3989049)
sorry Graham; next time I'll try to remember to open a new issue after pushing. p http://codereview.appspot.com/3989049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Messed up adding issue 1499
Graham Percival wrote Tuesday, February 01, 2011 7:16 PM On Tue, Feb 01, 2011 at 04:18:38PM -, Trevor Daniels wrote: Phil, could you please fix this up for me? Although I am listed as a contributor the entry for me that appears in the pull-down list for owner is not acceptable for some reason. He's on holiday, so I did it. Thanks Graham. Any idea why my entry as contributor fails? It looks right. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Avoid most double slashes
On Tue, Feb 01, 2011 at 09:13:59PM +0100, Francisco Vila wrote: > 2011/2/1 Graham Percival : > >> - $(buildscript-dir)/output-distance --create-images --output-dir > >> $(RESULT_DIR) input/regression/out-test-baseline input/regression/out-test/ > >> + $(buildscript-dir)/output-distance --create-images --output-dir > >> $(RESULT_DIR) input/regression/out-test-baseline input/regression/out-test > > > > is out-test a file or a directory? I mean, output-distance could > > be writing a logfile called "out-test". > > Yes. But if out-test-baseline is a directory, also is out-test. The > former came w/o slash, looks poor that the latter comes with. That sounds like a good reason to add a slash to out-test-baseline. > > of course, the whole thing is a mess anyway, so you could argue > > that it doesn't matter if we make it messier. > > No, this is not my argument. My aim is to be slightly more coherent > and not put random, unneeded slashes at the end. Those "random, unneeded slashes" lets a reader know immediately that the name is a directory. If there's no final slash, then how do I know if it's supposed to be a directory or a file? The only way to tell is by memorizing the build directory layout. > > It's something we can (and should) avoid if we ever reach a > > critical mass of developers sufficiently fed up with the current > > build system that we can realistically create a new one, but until > > then, my instinct is to leave it alone. > > That's why you didn't do it, my instinct was to improve it and that's > why I did it. I don't see this as an improvement. I'm not saying that I want to revert it -- I don't care that much. But I definitely don't think that this improved the readability of the makefiles. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Avoid most double slashes
2011/2/1 Graham Percival : > On Tue, Feb 01, 2011 at 03:36:21PM +0100, Francisco Vila wrote: >> 2011/2/1 Francisco Vila : >> > Hello. I've been very busy parsing doc logs and there is something >> > thatkind of annoys me: double slashes everywhere. IMHO directories in >> > build scripts should end in their bare names if they are going to be >> > joined with a filename by means of a slash anyway, NOT end in slash >> > 'just in case'. > > How annoying is this? I agree that the output is annoying, but I > quite like seeing them in the makefiles. I mean, look at this: > >> - $(buildscript-dir)/output-distance --create-images --output-dir >> $(RESULT_DIR) input/regression/out-test-baseline input/regression/out-test/ >> + $(buildscript-dir)/output-distance --create-images --output-dir >> $(RESULT_DIR) input/regression/out-test-baseline input/regression/out-test > > is out-test a file or a directory? I mean, output-distance could > be writing a logfile called "out-test". Yes. But if out-test-baseline is a directory, also is out-test. The former came w/o slash, looks poor that the latter comes with. > IMO, removing all the > extra slashes means that the makefiles are slightly less readable, > and requires slightly more familiarity and memorization of the > build process. > > of course, the whole thing is a mess anyway, so you could argue > that it doesn't matter if we make it messier. No, this is not my argument. My aim is to be slightly more coherent and not put random, unneeded slashes at the end. > It's something we can (and should) avoid if we ever reach a > critical mass of developers sufficiently fed up with the current > build system that we can realistically create a new one, but until > then, my instinct is to leave it alone. That's why you didn't do it, my instinct was to improve it and that's why I did it. Ah, that did not end the whole sroty because many double slashes still remain, I must say. If the commit has not been truly harmless (it's been for me but it's not been proven it's for everybody) let's revert it. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regression tests for white mensural ligature enhancements (issue3989049)
On Mon, Jan 31, 2011 at 11:17:46AM +, pkx1...@gmail.com wrote:
> Just some minor syntax changes to make it read better. I hope no one is
> offended.
Not offended, but unfortunately I already pushed it. Could you
make these changes to git?
I don't want to slow down code development by asking non-English
speakers to revise text a lot. As long as the doc team can
understand it, I think it's best for programmers to be
programming.
> Documentation/notation/ancient.itely:500:
> General: There is an inconsistency using 'notehead' vs 'note head', so
> we need to pick one and stick with it. There is nothing in the CG (yet)
> and so we could make a policy if someone has a strong opinion on this.
gperciva@futoi:~/src/lilypond/Documentation/contributor$ grep
notehead *
doc-work.itexi:@emph{Note head} NOT notehead.
that seems like a pretty clear policy. I didn't check this in the
patch, though.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Avoid most double slashes
On Tue, Feb 01, 2011 at 03:36:21PM +0100, Francisco Vila wrote: > 2011/2/1 Francisco Vila : > > Hello. I've been very busy parsing doc logs and there is something > > thatkind of annoys me: double slashes everywhere. IMHO directories in > > build scripts should end in their bare names if they are going to be > > joined with a filename by means of a slash anyway, NOT end in slash > > 'just in case'. How annoying is this? I agree that the output is annoying, but I quite like seeing them in the makefiles. I mean, look at this: > - $(buildscript-dir)/output-distance --create-images --output-dir > $(RESULT_DIR) input/regression/out-test-baseline input/regression/out-test/ > + $(buildscript-dir)/output-distance --create-images --output-dir > $(RESULT_DIR) input/regression/out-test-baseline input/regression/out-test is out-test a file or a directory? I mean, output-distance could be writing a logfile called "out-test". IMO, removing all the extra slashes means that the makefiles are slightly less readable, and requires slightly more familiarity and memorization of the build process. of course, the whole thing is a mess anyway, so you could argue that it doesn't matter if we make it messier. *shrug* It's something we can (and should) avoid if we ever reach a critical mass of developers sufficiently fed up with the current build system that we can realistically create a new one, but until then, my instinct is to leave it alone. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Messed up adding issue 1499
On Tue, Feb 01, 2011 at 04:18:38PM -, Trevor Daniels wrote: > Phil, could you please fix this up for me? Although I am listed as > a contributor the entry for me that appears in the pull-down list > for owner is not acceptable for some reason. He's on holiday, so I did it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Avoid most double slashes
2011/2/1 Werner LEMBERG : > >>> I know that you shouldn't fix what doesn't need fixing; at least >>> this does not break anything, this is the test I've made with the >>> patch applied: [...] > > IMHO, this is exactly the kind of a patch which you should directly > apply without asking for approval... > Right then, I'll apply it, but I have not tested any of the binaries other than Linux in my system. If windows build breaks, I'll revert it immediately. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Avoid most double slashes
>> I know that you shouldn't fix what doesn't need fixing; at least >> this does not break anything, this is the test I've made with the >> patch applied: [...] IMHO, this is exactly the kind of a patch which you should directly apply without asking for approval... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add Modal transformations (issue4126042)
First stab at documentation now added. Comments from anyone familiar with these operations welcome. Trevor http://codereview.appspot.com/4126042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Messed up adding issue 1499
While adding issue 1499 I inadvertently made John Mandereau the owner. Sorry John! Phil, could you please fix this up for me? Although I am listed as a contributor the entry for me that appears in the pull-down list for owner is not acceptable for some reason. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Avoid most double slashes
2011/2/1 Francisco Vila : > Hello. I've been very busy parsing doc logs and there is something > thatkind of annoys me: double slashes everywhere. IMHO directories in > build scripts should end in their bare names if they are going to be > joined with a filename by means of a slash anyway, NOT end in slash > 'just in case'. > > I know that you shouldn't fix what doesn't need fixing; at least this > does not break anything, this is the test I've made with the patch > applied: > > time ( make clean && ./autogen.sh && make && make doc-clean && make doc ) > > [32Mb of output later...] > > Mirroring... > Processing HTML pages for offline target... > find ./out-www/offline-root -type l | xargs rm -f > make[1]: Leaving directory `/home/fravd/source/lilypond' > > real 105m17.622s > user 93m34.935s > sys 10m16.579s > > So the program builds, the docs build and look good, and 'make > install' succeeds. > > Attached. OOPS! here is the right patch. Sorry! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com From 20c8ee6b707a15138e4b8072b91da5ebe1299d64 Mon Sep 17 00:00:00 2001 From: Francisco Vila Date: Mon, 31 Jan 2011 16:53:16 +0100 Subject: [PATCH] Build: end directories in their bare names and avoid some double slashes in logs. --- Documentation/GNUmakefile |2 +- Documentation/pictures/pdf/GNUmakefile|2 +- GNUmakefile.in| 16 ++-- lily/GNUmakefile |2 +- ly/GNUmakefile|2 +- make/ly-rules.make|2 +- make/website.make | 34 ++-- ps/GNUmakefile|2 +- scm/GNUmakefile |2 +- scripts/auxiliar/build-coverage.sh|8 +++--- stepmake/aclocal.m4 |2 +- stepmake/stepmake/documentation-vars.make |2 +- stepmake/stepmake/install-targets.make|2 +- stepmake/stepmake/makedir-vars.make |2 +- stepmake/stepmake/texinfo-targets.make|2 +- stepmake/stepmake/toplevel-targets.make |2 +- tex/GNUmakefile |2 +- 17 files changed, 43 insertions(+), 43 deletions(-) diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index e061e62..d424629 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -84,7 +84,7 @@ INFO_FILES = $(INFO_DOCS:%=$(outdir)/%.info) ifeq ($(out),www) INFO_IMAGES_DIR = lilypond -DEST_INFO_IMAGES_SUBDIR = Documentation/ +DEST_INFO_IMAGES_SUBDIR = Documentation endif include $(depth)/make/stepmake.make diff --git a/Documentation/pictures/pdf/GNUmakefile b/Documentation/pictures/pdf/GNUmakefile index e81f999..72ac2bc 100644 --- a/Documentation/pictures/pdf/GNUmakefile +++ b/Documentation/pictures/pdf/GNUmakefile @@ -1,4 +1,4 @@ -depth = ../../../ +depth = ../../.. PDF_FILES = $(call src-wildcard,*.pdf) diff --git a/GNUmakefile.in b/GNUmakefile.in index ca3d099..f8e1d15 100644 --- a/GNUmakefile.in +++ b/GNUmakefile.in @@ -70,8 +70,8 @@ local-clean-ChangeLog: dist-toplevel-txt-files: top-doc -mkdir -p $(distdir) - ln $(TOPDOC_TXT_FILES) $(distdir)/ - ln $(top-src-dir)/stepmake/aclocal.m4 $(distdir)/ + ln $(TOPDOC_TXT_FILES) $(distdir) + ln $(top-src-dir)/stepmake/aclocal.m4 $(distdir) info: $(foreach d, $(INFO_DIRECTORIES),$(MAKE) -C $(d) out=www info && ) true @@ -101,7 +101,7 @@ ifeq ($(out),www) # installed in non-recursing target from TOP-SRC-DIR install-WWW: -$(INSTALL) -m 755 -d $(DESTDIR)$(webdir) - rsync -rl --exclude='*.signature' $(outdir)/offline-root/ $(DESTDIR)$(webdir) + rsync -rl --exclude='*.signature' $(outdir)/offline-root $(DESTDIR)$(webdir) $(MAKE) -C Documentation omf-local-install install-info-WWW: @@ -210,7 +210,7 @@ $(tree-share-prefix)/mf-link-tree link-mf-tree: $(tree-share-prefix)/lilypond-fo rm -f $(tree-share-prefix)/fonts/type1/* && \ cd $(tree-share-prefix)/fonts/otf && \ ln -s ../../../../../../mf/$(outconfbase)/*.otf . - -cd $(tree-share-prefix)/fonts/ && \ + -cd $(tree-share-prefix)/fonts && \ ln -s ../../../../../mf/$(outconfbase)/fonts.conf . -cd $(tree-share-prefix)/fonts/svg && \ ln -s ../../../../../../mf/$(outconfbase)/*.svg . @@ -253,7 +253,7 @@ test: @echo @echo 'grep sourcefilename `grep -L systems.texi out/lybook-testdb/*/*log|sed s/log/ly/g`' @echo - $(MAKE) -C input/regression/ out=test local-test + $(MAKE) -C input/regression out=test local-test $(MAKE) -C input/regression/musicxml out=test local-test $(MAKE) -C input/regression/abc2ly out=test local-test $(MAKE) -C input/regression/lilypond-book out=test local-test @@ -264,7 +264,7 @@ test-baseline: fi $(MAKE) $(MAKE) test - $(MAKE) out=test -C input/regression/ local-test-baseline + $(MAKE) out=test -C input/regression local-test-baseline $(MAKE) out=test -C input/regression/musicxml local-test-baseline $(MAKE) out
[PATCH] Avoid most double slashes
Hello. I've been very busy parsing doc logs and there is something
thatkind of annoys me: double slashes everywhere. IMHO directories in
build scripts should end in their bare names if they are going to be
joined with a filename by means of a slash anyway, NOT end in slash
'just in case'.
I know that you shouldn't fix what doesn't need fixing; at least this
does not break anything, this is the test I've made with the patch
applied:
time ( make clean && ./autogen.sh && make && make doc-clean && make doc )
[32Mb of output later...]
Mirroring...
Processing HTML pages for offline target...
find ./out-www/offline-root -type l | xargs rm -f
make[1]: Leaving directory `/home/fravd/source/lilypond'
real105m17.622s
user93m34.935s
sys 10m16.579s
So the program builds, the docs build and look good, and 'make
install' succeeds.
Attached.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
From e3c5b227c931b8750a9ef50d71db3e29413d36da Mon Sep 17 00:00:00 2001
From: Francisco Vila
Date: Sun, 30 Jan 2011 19:37:02 +0100
Subject: [PATCH 4/5] Doc: additions to Chinese documentation and web.
---
Documentation/lily_index_search.php|4 +-
Documentation/lilypond-texi2html.init | 395 +++-
make/website.make |5 +-
python/langdefs.py |5 +-
scripts/build/create-weblinks-itexi.py | 57 +-
scripts/build/website_post.py | 10 +-
6 files changed, 411 insertions(+), 65 deletions(-)
diff --git a/Documentation/lily_index_search.php b/Documentation/lily_index_search.php
index f1b1e17..21c2020 100644
--- a/Documentation/lily_index_search.php
+++ b/Documentation/lily_index_search.php
@@ -1,5 +1,5 @@
"en", "de"=>"de", "nl"=>"nl", "jp"=>"jp", "hu"=>"hu", "fr"=>"fr", ""=>"en");
+ $languages = array ("en"=>"en", "de"=>"de", "nl"=>"nl", "ja"=>"ja", "hu"=>"hu", "fr"=>"fr", "zh"=>"zh", ""=>"en");
$manuals = array ("essay"=>"essay", "extending"=>"extending", "learning"=>"learning", "notation"=>"notation", "usage"=>"usage");
$lang = $languages[$_REQUEST['lang']];
@@ -59,4 +59,4 @@
if ($form_submitted) {
echo "\n";
}
-?>
\ No newline at end of file
+?>
diff --git a/Documentation/lilypond-texi2html.init b/Documentation/lilypond-texi2html.init
index 5734091..2993bdb 100644
--- a/Documentation/lilypond-texi2html.init
+++ b/Documentation/lilypond-texi2html.init
@@ -91,9 +91,14 @@ use Encode qw(decode);
#
my $LY_LANGUAGES = {};
-$LY_LANGUAGES->{'fr'} = {
-'Back to Documentation Index' => 'Retour à l\'accueil de la documentation',
-'Thanks to ${webdev_link} for hosting ${lily_site}.' => 'Remerciements à ${webdev_link} pour l\'hébergement de ${lily_site}.',
+$LY_LANGUAGES->{'cs'} = {
+'Back to Documentation Index' => '',
+'Thanks to ${webdev_link} for hosting ${lily_site}.' => '',
+};
+
+$LY_LANGUAGES->{'de'} = {
+'Back to Documentation Index' => 'Zur Dokumentationsübersicht',
+'Thanks to ${webdev_link} for hosting ${lily_site}.' => '',
};
$LY_LANGUAGES->{'es'} = {
@@ -101,15 +106,11 @@ $LY_LANGUAGES->{'es'} = {
'Thanks to ${webdev_link} for hosting ${lily_site}.' => 'Agradecemos a ${webdev_link} el alojamiento de ${lily_site}.',
};
-$LY_LANGUAGES->{'de'} = {
-'Back to Documentation Index' => 'Zur Dokumentationsübersicht',
-'Thanks to ${webdev_link} for hosting ${lily_site}.' => '',
+$LY_LANGUAGES->{'fr'} = {
+'Back to Documentation Index' => 'Retour à l\'accueil de la documentation',
+'Thanks to ${webdev_link} for hosting ${lily_site}.' => 'Remerciements à ${webdev_link} pour l\'hébergement de ${lily_site}.',
};
-$LY_LANGUAGES->{'ja'} = {
-'Back to Documentation Index' => 'ドキュメント インデックスに戻る',
-'Thanks to ${webdev_link} for hosting ${lily_site}.' => '',
-};
$LY_LANGUAGES->{'hu'} = {
'Back to Documentation Index' => 'Vissza a dokumentációk jegyzékéhez',
@@ -121,9 +122,20 @@ $LY_LANGUAGES->{'it'} = {
'Thanks to ${webdev_link} for hosting ${lily_site}.' => '',
};
+$LY_LANGUAGES->{'ja'} = {
+'Back to Documentation Index' => 'ドキュメント インデックスに戻る',
+'Thanks to ${webdev_link} for hosting ${lily_site}.' => '${lily_site} をホスティングしてくれている ${webdev_link} に感謝します。',
+};
+
+
$LY_LANGUAGES->{'nl'} = {
'Back to Documentation Index' => 'Terug naar de Documentatieindex',
-'Met dank aan ${webdev_link} voor het hosten van ${lily_site}.' => '',
+'Thanks to ${webdev_link} for hosting ${lily_site}.' => 'Met dank aan ${webdev_link} voor het hosten van ${lily_site}.',
+};
+
+$LY_LANGUAGES->{'zh'} = {
+'Back to Documentation Index' => '',
+'Thanks to ${webdev_link} for hosting ${lily_site}.' => '',
};
# FIXME: request the translations below then send them to texi2html/texinfo devs
@@ -411,45 +423,180 @@ $LANGUAGES->{'ja'} = {
'About This Document' => 'このドキュメントについて',
'April' => '4 月'
Re: Bug in ties over barlines
W dniu 31 stycznia 2011 17:06 użytkownik Carl Sorensen napisał: > On 1/31/11 3:04 AM, "Jan Warchoł" wrote: >> 2011/1/24 Phil Holmes >>> >>> If you use >>> >>> #(set-accidental-style 'modern-cautionary) >>> then you get the parenthesised accidental automatically, as requested. >> >> Indeed, thanks for the remainder. >> However, in my opinion it is necessary to *change* the 'default', >> 'voice' and 'forget' accidental styles, because their current >> behaviour result in wrongly typeset music. If the last note in the >> following example doesn't get a natural, it's *impossible* to tell >> that it's not another ces: >> >> ces'1~ | ces' >> ces'1( | c') >> >> It may be argued that the slur looks different than the tie, but it's >> not enough. >> I'm sure that engraving books will agree with me - may someone check this? > > I think that it would be fine to have a rule added that says "if we're > across a barline, and the scale step is the same, but the accidental is > different, and the slur is two notes long ending on the current note, > display a cautionary accidental in order to avoid confusion with a tie." +1, except that i think it should be unparenthesized (at least in accidental styles like default and voice, that don't use parenthesized accidentals at all). 2011/1/31 Alexander Kobel : > But IMHO the important point here is the fact that the notation can be > ambigous without the accidental, and is definitely clear with it. No > matter if ? or !. +1. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1120 in a way to avoid issues 1472, 1474 (issue4095041)
On 2011/01/31 19:50:38, Carl wrote: Since the 0.1s are all part of a Separation_item, what if we defined a new grob-property default-separation, and set the value to 0.1 for NonMusicalPaperColumn, NoteColumn, and PaperColumn, since these are the grobs having separation_item_interface? Done; and I like it. Only NoteColumn needed the padding to restore 2.12.3s good note spacing. I gave a nonzero padding to NonMusicalPaperColumn because the grobs in such columns all seem to want the same padding. http://codereview.appspot.com/4095041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
