Le jeudi 24 décembre 2009 à 03:28 +0100, Francisco Vila a écrit :
> Now I understand why I had to touch the music itself to make snippets
> regenerated on a set of exercises.
I hope my patch on Rietveld will completely fix this:
- all fragment options are taken into account in the hash, so a chang
2009/12/23 John Mandereau :
> Hi guys,
>
> In my way of fixing lilypond-book hashing, I'm afraid I'll have to
> revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
> md5 hashing strategy", because ignoring fragment options for the hash
> which have an impact on music typesetting
Hello,
In my translated downloads page, I can not make
@downloadStableLinuxNormal and others to appear properly expanded.
I can only find the macro downloadStableLinuxNormal defined in
generated files (and therefore not able to find it by means of git
grep) such as input/regression/out-test/versi
Hi folks,
Please review
http://codereview.appspot.com/183048
Best,
John
signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypon
2009/12/23 John Mandereau :
> Hi guys,
>
> In my way of fixing lilypond-book hashing, I'm afraid I'll have to
> revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
> md5 hashing strategy", because ignoring fragment options for the hash
> which have an impact on music typesetting
On 12/23/09 5:37 PM, "Francisco Vila" wrote:
> Hello, I have news from the process of creation of the Spanish list on
> GNU. As you can follow in https://savannah.gnu.org/task/?9148 , my
> project was initially accepted. I created the list, but the saga has
> not ended well by this route. They
Le jeudi 24 décembre 2009 à 01:37 +0100, Francisco Vila a écrit :
> - The Spanish description has accented characters, I'd like them to
> appear properly listed like others do.
>
> (btw I don't understand the reasons given for the latter not being
> satisfied; if the host can not do it, how can
Hello, I have news from the process of creation of the Spanish list on
GNU. As you can follow in https://savannah.gnu.org/task/?9148 , my
project was initially accepted. I created the list, but the saga has
not ended well by this route. They have just told me
"Ask the LilyPond mantainer to creat
Le mercredi 23 décembre 2009 à 23:17 +, Graham Percival a écrit :
> Yes; that's why we changed the hash calculation from self.ly() to
> self.full_ly()
You meant the opposite.
> -- produced lily-abcd1234 filename would not
> depend on the fragment options,
This is wrong. lilypond-book rel
Just to add a bit to the brainstorming:
The uppermost lace of our G-clef already was slightly oversized.
I cannot explain why, but latest proposals I've seen are getting it
even greater.
Anyone appreciates the same?
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
No le de
On Thu, Dec 24, 2009 at 12:05:32AM +0100, John Mandereau wrote:
> Le mercredi 23 décembre 2009 à 22:45 +, Graham Percival a écrit :
> > Remember why we did this: the regtest filenames weren't matching
> > up between versions because the [options] changed.
>
> Sorry for having been idle at that
Le mercredi 23 décembre 2009 à 22:45 +, Graham Percival a écrit :
> Remember why we did this: the regtest filenames weren't matching
> up between versions because the [options] changed.
Sorry for having been idle at that time, but regtest comparison
shouldn't prevent us from changing lilypond-
On Wed, Dec 23, 2009 at 08:55:23PM +0100, John Mandereau wrote:
> In my way of fixing lilypond-book hashing, I'm afraid I'll have to
> revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
> md5 hashing strategy", because ignoring fragment options for the hash
> which have an impac
Le mercredi 23 décembre 2009 à 09:41 -0700, Carl Sorensen a écrit :
> Having reviewed all four of the clefs, I think I like 3 the best, but I have
> a hard time deciding between 3 and 4. Either of them seems fine to me.
Looking at two-by-two comparisons of cropped graphics sent on the list,
I agr
Le lundi 21 décembre 2009 à 21:44 -0800, Mark Polesky a écrit :
> Except that once I designate a remote branch `origin', I
> need to name the other branch something else?
If you do "git branch -a", you may discover that the remote branch is
actually origin/BRANCH_NAME, origin is just a "remote" (w
Le lundi 21 décembre 2009 à 21:44 -0800, Mark Polesky a écrit :
> Except that once I designate a remote branch `origin', I
> need to name the other branch something else? My
> understanding is hazy, but from the build directory of my
> `master' repo, adding the lilypond/translation branch as in
>
Hi guys,
In my way of fixing lilypond-book hashing, I'm afraid I'll have to
revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
md5 hashing strategy", because ignoring fragment options for the hash
which have an impact on music typesetting is wrong. I'll not simply
revert that
Le mercredi 23 décembre 2009 à 18:49 +, Graham Percival a écrit :
> file from VC not distributed: lilypond-2.13.10/Documentation/es/web.texi
> file from VC not distributed:
> lilypond-2.13.10/Documentation/es/web/GNUmakefile
> file from VC not distributed:
> lilypond-2.13.10/Documentation/es/w
Le mercredi 23 décembre 2009 à 19:51 +0100, Jan Nieuwenhuizen a écrit :
> Also, it seems that the nl.po has not been updated with the latest
> 2.13.9 strings; so you might run into problems getting this accepted
> until that is fixed, along with the newly introduced strings.
I'm waiting a reply fr
Martin, can you take care of this until the tp-robot accepts it?
http://translationproject.org/html/robot.html
Also, it seems that the nl.po has not been updated with the latest
2.13.9 strings; so you might run into problems getting this accepted
until that is fixed, along with the newly int
file from VC not distributed: lilypond-2.13.10/Documentation/es/web.texi
file from VC not distributed: lilypond-2.13.10/Documentation/es/web/GNUmakefile
file from VC not distributed:
lilypond-2.13.10/Documentation/es/web/basic-authors.itexi
file from VC not distributed:
lilypond-2.13.10/Documentati
On 12/23/09 12:41 AM, "Marc Hohl" wrote:
> Carl Sorensen schrieb:
>>
>> On 12/22/09 12:45 AM, "Marc Hohl" wrote:
>>
>>
>>> Carl Sorensen schrieb:
>>>
On 12/21/09 1:52 PM, "Marc Hohl" wrote:
> [...]
>
>
>> I like it much better.
Le lundi 21 décembre 2009 à 22:28 +0100, Translation Project Robot a
écrit :
> A new POT file for textual domain 'lilypond' has been made available
> to the language teams for translation. It is archived as:
>
> http://translationproject.org/POT-files/lilypond-2.13.7.pot
What is this? The P
On 12/23/09 12:49 AM, "Marc Hohl" wrote:
> Marc Hohl schrieb:
>> [...]
>> Here it is again.
>>
>> Marc
>>
> Is the patch I sent ok? Applying it would simplify my attempts to do
> some further font work (i.e. "rotating" the G clef slightly and preparing
> an alternate segno sign - Issue 659).
There is a comment at the bottom of feta-din-code.mf - basically p and
f were larger and more pronounced than the other letters in a couple
of editions I analyzed.
On Tue, Dec 22, 2009 at 4:48 AM, Werner LEMBERG wrote:
>
> Han-Wen,
>
>
> do you remember why the dynamic signs `m' and `p' have a di
Le mercredi 23 décembre 2009 à 12:58 -0200, Haake care of both things
later.
> My take is that independent lp-book runs (by make -jX) share ly file
> snippets.
I've never seen any proof of this situation. I tried to make sure make
doesn't call simultaneous lilypond-book instances, and AFAIK it ha
2009/12/23 John Mandereau :
> Le vendredi 18 décembre 2009 à 00:38 -0200, Han-Wen Nienhuys a écrit :
>> We already have a plausible explanation, and a fairly simple solution:
>> use flock() in ly:parse-file on the .ly file.
>
> I think it's better to sanitize lilypond-book behaviour instead, namely
Le mercredi 23 décembre 2009 à 08:41 +0100, Marc Hohl a écrit :
> Carl Sorensen schrieb:
> > Looks good to me. I'd also like to see half-way between this attempt and
> > the first attempt, not because I think this is wrong, but because I tend to
> > find optimum settings by finding "not enough" an
Le vendredi 18 décembre 2009 à 00:38 -0200, Han-Wen Nienhuys a écrit :
> We already have a plausible explanation, and a fairly simple solution:
> use flock() in ly:parse-file on the .ly file.
I think it's better to sanitize lilypond-book behaviour instead, namely
fixing relevant_contents and make
Le dimanche 13 décembre 2009 à 15:55 +, Graham Percival a écrit :
> diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
> index 392ddd0..b9731f1 100644
> --- a/scripts/lilypond-book.py
> +++ b/scripts/lilypond-book.py
> @@ -1273,7 +1273,11 @@ left-margin-default right-margin-defaul
Le dimanche 20 décembre 2009 à 13:58 -0800, Mark Polesky a écrit :
> If a less verbose build output if desired, the variable
> QUIET_BUILD may be set to 1 on make command line, or in
> ‘local.make’ at top of the build tree.
>
> How do I make this work? Neither of these work for me:
>
> QUIET_BUI
David Kastrup schrieb:
Marc Hohl writes:
Carl Sorensen schrieb:
Looks good to me. I'd also like to see half-way between this attempt
and the first attempt, not because I think this is wrong, but because
I tend to find optimum settings by finding "not enough" and "too
much" and going
Marc Hohl writes:
> Carl Sorensen schrieb:
>
>> Looks good to me. I'd also like to see half-way between this attempt
>> and the first attempt, not because I think this is wrong, but because
>> I tend to find optimum settings by finding "not enough" and "too
>> much" and going between those two.
33 matches
Mail list logo
