Il giorno lun 1 lug 2019 alle 8:03, Federico Bruni
ha scritto:
Yes, I run Fedora 30 since it was released and I can compile lilypond
without any problem using the package available in Fedora.
I've now built the rpm for version 1.0.3 and it works as well. I'll
submit the new version to the Fedo
Hello,
Here is the current patch countdown list. The next countdown will be on
July 29th
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
Push:
5536 musicxml2ly broken in all lilypond installers since 2.1
On 25.07.19 21:21, Karlin High wrote:
Exactly correct! All of the Linux and FreeBSD builds succeeded, and
these Windows and macOS components are failing.
You should also try
bin/gub mingw::lilypond
bin/gub mingw::lilypad
to build the lilypond and lilypad executables for mingw/windows.
[Moving the discussion to lilypond-devel.]
>> A loop?
Attached a new version of the patch, now using a loop.
Werner
diff --git a/lily/horizontal-bracket-engraver.cc b/lily/horizontal-bracket-engraver.cc
index 608af35965..a42268a357 100644
--- a/lily/horizontal-bracket-engraver.cc
+++ b/lil
Werner LEMBERG writes:
> [Moving the discussion to lilypond-devel.]
>
>>> A loop?
>
> Attached a new version of the patch, now using a loop.
>
>
> Werner
>
> diff --git a/lily/horizontal-bracket-engraver.cc
> b/lily/horizontal-bracket-engraver.cc
> index 608af35965..a42268a357 100644
> --- a
14:39:40 (UTC) Begin LilyPond compile, previous commit at
1c51a616e289fffb918942c8f1e189ab50809157
14:39:51 Merged staging, now at:1c51a616e289fffb918942c8f1e189ab50809157
14:39:52Success:./autogen.sh --noconfigure
14:40:08Success:/tmp/
pat...@gnu.org writes:
> 14:39:40 (UTC) Begin LilyPond compile, previous commit at
> 1c51a616e289fffb918942c8f1e189ab50809157
> 14:39:51 Merged staging, now at: 1c51a616e289fffb918942c8f1e189ab50809157
> 14:39:52 Success:./autogen.sh --noconfigure
> 14:40:08 Suc
David Kastrup writes:
> pat...@gnu.org writes:
>
>> 14:39:40 (UTC) Begin LilyPond compile, previous commit at
>> 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:39:51 Merged staging, now at: 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:39:52 Success:./autogen.sh --noc
>> diff --git a/lily/horizontal-bracket-engraver.cc
>> b/lily/horizontal-bracket-engraver.cc
>> index 608af35965..a42268a357 100644
>> --- a/lily/horizontal-bracket-engraver.cc
>> +++ b/lily/horizontal-bracket-engraver.cc
>> @@ -56,10 +56,23 @@ Horizontal_bracket_engraver::listen_note_grouping
>
David Kastrup writes:
> David Kastrup writes:
>
>> fatal: Not a valid object name master
>>
>> Apparently, the patch from
>> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>> Author: Knut Petersen
>> Date: Sun Jul 7 13:16:05 2019 +0200
>>
>> Optimize tree.gittxt messages
>>
>> W
15:04:59 (UTC) Begin LilyPond compile, previous commit at
95a26f04acfa14068edff2d4457bfeca12ad80fc
15:05:03 Merged staging, now at:95a26f04acfa14068edff2d4457bfeca12ad80fc
15:05:03Success:./autogen.sh --noconfigure
15:05:19Success:/tmp/
pat...@gnu.org writes:
> 15:04:59 (UTC) Begin LilyPond compile, previous commit at
> 95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:05:03 Merged staging, now at: 95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:05:03 Success:./autogen.sh --noconfigure
> 15:05:19 Suc
Werner LEMBERG writes:
> OK, more comments added to the source code.
>
> I wish that other parts of lilypond are having similarly detailed
> comments...
Well, that's exactly the reason to be adding them according to Immanuel
Kant's seminal writings on coding standards.
--
David Kastrup
__
Werner LEMBERG writes:
>>> diff --git a/lily/horizontal-bracket-engraver.cc
>>> b/lily/horizontal-bracket-eng
>if (d == STOP)
> {
>pop_count_++;
> - if (pop_count_ > bracket_stack_.size ())
> +
> + // Since N `L' events create N HorizontalBracket grobs we need (at
> +
Le 26/07/2019 à 09:44, Federico Bruni a écrit :
Jean-Charles, version 1.0.3 is now available in Fedora 30 repositories.
And version 1.1.0 is in rawhide.
As I've cloned the repository and built it without any problem,
everything is fine.
Cheers,
Jean-Charles
___
>>if (d == STOP)
>> {
>>pop_count_++;
>> - if (pop_count_ > bracket_stack_.size ())
>> +
>> + // Since N `L' events create N HorizontalBracket grobs we need (at
>> + // most) N `R' events to finish them. However, at this particular
>> + // moment, a single-mom
Hello,
On 26/07/2019 16:13, David Kastrup wrote:
David Kastrup writes:
David Kastrup writes:
fatal: Not a valid object name master
Apparently, the patch from
commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
Author: Knut Petersen
Date: Sun Jul 7 13:16:05 2019 +0200
Optimize tree.gi
James writes:
> Hello,
>
> On 26/07/2019 16:13, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> David Kastrup writes:
>>>
fatal: Not a valid object name master
Apparently, the patch from
commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
Author: Knut Petersen
Da
Werner LEMBERG writes:
>>>if (d == STOP)
>>> {
>>>pop_count_++;
>>> - if (pop_count_ > bracket_stack_.size ())
>>> +
>>> + // Since N `L' events create N HorizontalBracket grobs we need (at
>>> + // most) N `R' events to finish them. However, at this particular
>>
>> If someone is going to rewrite the algorithm, the order of events
>> should be obeyed.
>
> For simultaneous events, LilyPond has no order.
Oh. This means that
c'\startGroup\stopGroup
and
c'\stopGroup\startGroup
can't be reliably distinguished?
> That's why one needs to have one phas
Werner LEMBERG writes:
>>> If someone is going to rewrite the algorithm, the order of events
>>> should be obeyed.
>>
>> For simultaneous events, LilyPond has no order.
>
> Oh. This means that
>
> c'\startGroup\stopGroup
>
> and
>
> c'\stopGroup\startGroup
>
> can't be reliably distinguishe
On 26.07.19 20:36, David Kastrup wrote:
Unless Knut is also running patchy now that he has commit access (and
perhaps didn't have a clean master?).
(I don't want to cast aspersions, but it might be a genuine mistake if
it was Knut). Knut?
I rather doubt that it was Knut since I mentioned the
Knut Petersen writes:
> On 26.07.19 20:36, David Kastrup wrote:
>>
>>> Unless Knut is also running patchy now that he has commit access (and
>>> perhaps didn't have a clean master?).
>>>
>>> (I don't want to cast aspersions, but it might be a genuine mistake if
>>> it was Knut). Knut?
>> I rather
On 27.07.19 07:56, David Kastrup wrote:
What happened to the musicxml2ly patch? It vanished from staging.
Shall I push it again?
It didn't pass patchy testing on my computer with failures in the
musicxml files. So it appears to have a problem with, uh, Python
2.7.16+ (according to python --ve
On 27.07.19 05:20, Karlin High wrote:
On Fri, Jul 26, 2019 at 4:36 AM Knut Petersen wrote:
You should also try
bin/gub mingw::lilypond
bin/gub mingw::lilypad
Both of those worked, before setting up qemu.
I would try the qemu method first, because it would be easier to use for more
people.
25 matches
Mail list logo
