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
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
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
>> 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
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
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
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
>>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
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
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
> +
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
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
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:
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
>>
>>
>> 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:
> 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
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
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:
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
> ---
[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
+++
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.
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
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
23 matches
Mail list logo
