Marc Hohl m...@hohlart.de 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
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_BUILD=1
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-default)
2009/12/23 John Mandereau john.mander...@gmail.com:
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
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 has
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 w...@gnu.org wrote:
Han-Wen,
do you remember why the dynamic signs `m' and `p'
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 POT
On 12/23/09 12:41 AM, Marc Hohl m...@hohlart.de wrote:
Carl Sorensen schrieb:
On 12/22/09 12:45 AM, Marc Hohl m...@hohlart.de wrote:
Carl Sorensen schrieb:
On 12/21/09 1:52 PM, Marc Hohl m...@hohlart.de wrote:
[...]
I like it much better. But I think
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:
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
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 from
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:
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 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
CG
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
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 time,
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
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 relies
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
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 some
On 12/23/09 5:37 PM, Francisco Vila paconet@gmail.com 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
2009/12/23 John Mandereau john.mander...@gmail.com:
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
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
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
2009/12/23 John Mandereau john.mander...@gmail.com:
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
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 change
26 matches
Mail list logo
