Here is the current countdown list.
The next countdown will begin June 19th.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!1410 binaries: Fix linking of libintl on macOS - Jonas Hahnfeld
https://gitlab.com
Jean Abou Samra writes:
> Le 17/06/2022 à 23:49, David Kastrup a écrit :
>> Jean Abou Samra writes:
>>
>>> By the way, I have a side question. Suppose I have determined
>>> that I need to mark the local variable scm_obj with
>>> scm_remember_upto_here in this code:
>>>
>>> SCM scm_obj = get_it_f
Jean Abou Samra writes:
> Le 17/06/2022 à 23:46, David Kastrup a écrit :
>> Nope. They are on the stack. They may either be immediate SCM values
>> with nothing on the heap (like SCM_EOL or small integers), or they may
>> point to a heap cell. In that case, scanning the stack during GC will
>>
Le 17/06/2022 à 23:49, David Kastrup a écrit :
Jean Abou Samra writes:
By the way, I have a side question. Suppose I have determined
that I need to mark the local variable scm_obj with
scm_remember_upto_here in this code:
SCM scm_obj = get_it_from_somewhere ();
return something_that_needs_sc
Le 17/06/2022 à 23:46, David Kastrup a écrit :
Nope. They are on the stack. They may either be immediate SCM values
with nothing on the heap (like SCM_EOL or small integers), or they may
point to a heap cell. In that case, scanning the stack during GC will
pick up the SCM values and mark th
Jean Abou Samra writes:
> By the way, I have a side question. Suppose I have determined
> that I need to mark the local variable scm_obj with
> scm_remember_upto_here in this code:
>
> SCM scm_obj = get_it_from_somewhere ();
>
> return something_that_needs_scm_obj_alive;
>
> // Is this correct?
>
Jean Abou Samra writes:
> Hi,
>
> Once again, the more I try to understand how GC works at
> the C++ level, the more I get lost. Of course, not being
> too good at low-level programming doesn't help. Take this
> random exported function:
>
>
> LY_DEFINE (ly_duration_less_p, "ly:duration
Le 17/06/2022 à 23:20, Jean Abou Samra a écrit :
Hi,
Once again, the more I try to understand how GC works at
the C++ level, the more I get lost. Of course, not being
too good at low-level programming doesn't help. Take this
random exported function:
LY_DEFINE (ly_duration_less_p, "ly:durat
Hi,
Once again, the more I try to understand how GC works at
the C++ level, the more I get lost. Of course, not being
too good at low-level programming doesn't help. Take this
random exported function:
LY_DEFINE (ly_duration_less_p, "ly:duration
On 2022-06-17 9:36 am, Ian Kelling wrote:
Aaron Hill writes:
On 2022-06-17 9:07 am, Ian Kelling wrote:
Can confirm: no appreciable delay. Moderation could make sense here,
although it would not explain why regular users of the lists
experience
this delay intermittently. Is there some compo
Aaron Hill writes:
> On 2022-06-17 9:07 am, Ian Kelling wrote:
> Can confirm: no appreciable delay. Moderation could make sense here,
> although it would not explain why regular users of the lists experience
> this delay intermittently. Is there some component that randomly
> selects emails f
Jean Abou Samra writes:
> Regarding listhelper, I didn't know about it. I'm not sure
> if it's enabled on lilypond-user or lilypond-devel, but judging
> from
> https://savannah.gnu.org/maintenance/ListHelperAntiSpam/,
> it is not enabled on lilypond-user-fr (there's no non-human address
> in th
On 2022-06-17 9:07 am, Ian Kelling wrote:
Aaron Hill writes:
In case it helps, your very message to the list was delayed
significantly.
I presume I hadn't posted to lilypond-devel before, so it was held for
moderation and the listhelpers were asleep, they approved it after they
woke up. So,
Le 17/06/2022 à 18:07, Ian Kelling a écrit :
Aaron Hill writes:
In case it helps, your very message to the list was delayed
significantly.
I presume I hadn't posted to lilypond-devel before, so it was held for
moderation and the listhelpers were asleep, they approved it after they
woke up. So
Ian Kelling writes:
> Aaron Hill writes:
>
>> In case it helps, your very message to the list was delayed
>> significantly.
>
> I presume I hadn't posted to lilypond-devel before, so it was held for
> moderation and the listhelpers were asleep, they approved it after they
> woke up. So, this w
Aaron Hill writes:
> In case it helps, your very message to the list was delayed
> significantly.
I presume I hadn't posted to lilypond-devel before, so it was held for
moderation and the listhelpers were asleep, they approved it after they
woke up. So, this was case #1. Again, I encourage the
Le 17/06/2022 à 16:15, Aaron Hill a écrit :
On 2022-06-16 7:54 pm, Ian Kelling wrote:
#3, least common: sometimes there is an issue with a specific mail
server which causes delays. This can often be fixed. I'm happy to check
if that is the case, just email the details of the message to
mail..
On 2022-06-16 7:54 pm, Ian Kelling wrote:
#3, least common: sometimes there is an issue with a specific mail
server which causes delays. This can often be fixed. I'm happy to check
if that is the case, just email the details of the message to
mail...@gnu.org. If it hasn't been posted, wait at lea
Jean Abou Samra writes:
> Hello, dear administrators of GNU list servers,
>
> Sorry for the possible double post, I was not sure which address to
> send this to. This is to let you know that mailing lists related
> to the GNU LilyPond project have recently been experiencing abnormal
> distribut
On Fri, Jun 17, 2022 at 2:11 PM Dan Eble wrote:
>
> I have a regression test that should fail if a BarLine grob is created. It
> is sufficient to override BarLine.glyph-name to make it obvious in the visual
> diff.
>
> Is there a simpler, more direct, or more robust way to test this?
You could
Le 17/06/2022 à 14:02, Dan Eble a écrit :
I have a regression test that should fail if a BarLine grob is created. It is
sufficient to override BarLine.glyph-name to make it obvious in the visual diff.
Is there a simpler, more direct, or more robust way to test this?
Maybe
\override Staff.B
I have a regression test that should fail if a BarLine grob is created. It is
sufficient to override BarLine.glyph-name to make it obvious in the visual diff.
Is there a simpler, more direct, or more robust way to test this?
I suppose I could add an engraver that warns about each BarLine it
ac
On Jun 17, 2022, at 02:18, Jean Abou Samra wrote:
>
>> we do. Does lilypond want one or more of their lists to be one of the
>> initial group to move to mailman 3?
>
> Yes, I'd be in favor of doing that. Others, what do you
> think?
fine
—
Dan
23 matches
Mail list logo
