On 3/29/20, 3:39 PM, "lilypond-devel on behalf of Han-Wen Nienhuys"
wrote:
On Sun, Mar 29, 2020 at 11:33 PM wrote:
>
> > Remove references to test-output-distance.ly.
> >
> > It was removed in commit 8a74a0e ("Remove
> > input/regression/test-output-distance.ly")
On Mar 29, 2020, at 17:39, Han-Wen Nienhuys wrote:
>> test-output-distance was removed on the grounds that the self-test
>> serves the same purpose, but I don't see how it does.
>
> Could you elaborate? What failure scenario are you worried about?
My question is, how does the self-test "verify
On Sun, Mar 29, 2020 at 11:33 PM wrote:
>
> > Remove references to test-output-distance.ly.
> >
> > It was removed in commit 8a74a0e ("Remove
> > input/regression/test-output-distance.ly")
>
> I must have slept through that. Had I been paying attention, I would
> have pointed out what the
> Remove references to test-output-distance.ly.
>
> It was removed in commit 8a74a0e ("Remove
> input/regression/test-output-distance.ly")
I must have slept through that. Had I been paying attention, I would
have pointed out what the documentation you propose to remove says:
This test
Simon Albrecht writes:
> Let's be honest, they really had to get their stuff together to keep
> any ground all against Dorico.
I think they may still have the higher ground. But Dorico is moving
much faster.
LilyPond is like Switzerland. High ground, but nobody goes there.
--
David Kastrup
>> No holdup, but I would like to see an LSR import to synchronize
>> documentation with snippets.
>
> I think that's standard as part of the release procedure?
Ah, ok, excellent.
Werner
- Original Message -
From: "David Kastrup"
To: "Werner LEMBERG"
Cc:
Sent: Sunday, March 29, 2020 6:10 PM
Subject: Re: Anything missing for 2.21.0?
Werner LEMBERG writes:
Anybody can think of a holdup?
No holdup, but I would like to see an LSR import to synchronize
Dan Eble writes:
> On Mar 29, 2020, at 14:46, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
Anybody can think of a holdup?
>>>
>>> convert-ly is broken:
> ...
>> Oh wow, how did that happen?
>>
>> Oh, and now I remember that
Dan Eble writes:
> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>
>> Anybody can think of a holdup?
>
> convert-ly is broken:
>
> find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
> Traceback (most recent call last):
> File "/home/user/lilypond-build/out/bin/convert-ly",
Jean-Charles Malahieude writes:
> Le 29/03/2020 à 18:59, David Kastrup a écrit :
>> Jean-Charles Malahieude writes:
>>>
>>> But, please, pick up the po files I mentioned (ca, da, de, eo, es, fr,
>>> it, ja, nl, sv) which are in advance on stable/2.20. As I work on
>>> local clones (one per
Let's be honest, they really had to get their stuff together to keep any ground
all against Dorico.
Best, Simon
> On 27.03.2020 - 15:26, Shane Brandes wrote:
>
>
> They are really on the ball on that one.
>
>
> -Shane
>
>
> On Fri, Mar 27, 2020 at 10:09 AM Valentin Villenave
> wrote:
>
On Mar 29, 2020, at 15:31, David Kastrup wrote:
> I was actually only planning to touch convertrules.py . Sigh.
Sure, don't let it bother you.
—
Dan
Dan Eble writes:
> On Mar 29, 2020, at 14:46, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
Anybody can think of a holdup?
>>>
>>> convert-ly is broken:
> ...
>> Oh wow, how did that happen?
>>
>> Oh, and now I remember that
On Mar 29, 2020, at 14:46, David Kastrup wrote:
>
> Dan Eble writes:
>
>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>>
>>> Anybody can think of a holdup?
>>
>> convert-ly is broken:
...
> Oh wow, how did that happen?
>
> Oh, and now I remember that there was a convert-ly thing about
Dan Eble writes:
> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>
>> Anybody can think of a holdup?
>
> convert-ly is broken:
>
> find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
> Traceback (most recent call last):
> File "/home/user/lilypond-build/out/bin/convert-ly",
On Mar 29, 2020, at 11:54, David Kastrup wrote:
>
> Anybody can think of a holdup?
convert-ly is broken:
find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
Traceback (most recent call last):
File "/home/user/lilypond-build/out/bin/convert-ly", line 236, in do_conversion
newstr
https://codereview.appspot.com/549780044/diff/553810043/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):
https://codereview.appspot.com/549780044/diff/553810043/Documentation/contributor/regressions.itexi#newcode240
Le 29/03/2020 à 18:59, David Kastrup a écrit :
Jean-Charles Malahieude writes:
But, please, pick up the po files I mentioned (ca, da, de, eo, es, fr,
it, ja, nl, sv) which are in advance on stable/2.20. As I work on
local clones (one per branch), I can copy them and push onto staging
(they
Werner LEMBERG writes:
>> Anybody can think of a holdup?
>
> No holdup, but I would like to see an LSR import to synchronize
> documentation with snippets.
I think that's standard as part of the release procedure?
--
David Kastrup
> Anybody can think of a holdup?
No holdup, but I would like to see an LSR import to synchronize
documentation with snippets.
Werner
Jean-Charles Malahieude writes:
> Le 29/03/2020 à 17:54, David Kastrup a écrit :
>> [Repeat message since I got the address of translations wrong]
>> I see that translation-status is in master. The web site is still
>> getting fixed (including MacOSX download links), so we'd probably better
>>
On 2020/03/29 14:23:29, lemzwerg wrote:
> Minor doc nits.
I’ll include those fixes in the next patch set.
https://codereview.appspot.com/575330043/
Am Sonntag, den 29.03.2020, 17:54 +0200 schrieb David Kastrup:
> [Repeat message since I got the address of translations wrong]
>
> I see that translation-status is in master. The web site is still
> getting fixed (including MacOSX download links), so we'd probably better
> wait with the big
Le 29/03/2020 à 17:54, David Kastrup a écrit :
[Repeat message since I got the address of translations wrong]
I see that translation-status is in master. The web site is still
getting fixed (including MacOSX download links), so we'd probably better
wait with the big announcements until that
I see that translation-status is in master. The web site is still
getting fixed (including MacOSX download links), so we'd probably better
wait with the big announcements until that is there.
But roll the release? It's just the first unstable in a series anyway.
Anybody can think of a
On Sun, Mar 29, 2020 at 4:12 PM wrote:
>
> On 2020/03/29 13:55:41, hanwenn wrote:
> > On 2020/03/29 13:52:48, hanwenn wrote:
> > > retain existing
> >
> > how's this? This leaves things backward compatible.
>
> Ugly and a maintenance burden since the code is used twice. Anything
> wrong with my
Minor doc nits.
https://codereview.appspot.com/575330043/diff/549780043/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/575330043/diff/549780043/Documentation/changes.tely#newcode67
Documentation/changes.tely:67: @item The labels can be changed
On 2020/03/29 13:55:41, hanwenn wrote:
> On 2020/03/29 13:52:48, hanwenn wrote:
> > retain existing
>
> how's this? This leaves things backward compatible.
Ugly and a maintenance burden since the code is used twice. Anything
wrong with my proposal? It does not have duplicate code, makes
On 2020/03/29 14:01:31, Malte Meyn wrote:
> label-alignments for VoltaBrackets and line spanners, changes entry
This needs a regtest and a convert-ly rule. Can someone help me with the
latter? All \overrides etc. have to change stencil-align-dir-y = NUMBER
to label-alignments = NUMBER-PAIR.
On 2020/03/29 13:55:41, hanwenn wrote:
> On 2020/03/29 13:52:48, hanwenn wrote:
> > retain existing
>
> how's this? This leaves things backward compatible.
>
> Note that we're currently incoherent, because you can't do
>
> (let ((n 0)) (define sym val))
"incoherent" means in conflict with
On 2020/03/29 13:52:48, hanwenn wrote:
> retain existing
how's this? This leaves things backward compatible.
Note that we're currently incoherent, because you can't do
(let ((n 0)) (define sym val))
so coherency is probably not a great argument for keeping things as is.
https://codereview.appspot.com/553580043/diff/571810043/mf/gen-emmentaler-brace.fontforge.py
File mf/gen-emmentaler-brace.fontforge.py (right):
https://codereview.appspot.com/553580043/diff/571810043/mf/gen-emmentaler-brace.fontforge.py#newcode40
mf/gen-emmentaler-brace.fontforge.py:40: #
Hello,
Here is the current patch countdown list. The next countdown will be on
March 31st
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
***
Push:
5864 improve Rational infinity initialization - Dan Eble
33 matches
Mail list logo
