PATCHES - Countdown to June 19
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/lilypond/lilypond/-/merge_requests/1410 !1409 New figured bass accidentals - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1409 !1406 Allow #t as an abbreviation in \defineBarLine - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1406 Countdown: !1412 Implement chord grid notation - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1412 !1411 time-signature-settings.scm: Minor improvements - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/1411 !1408 Fix sometimes misplaced dashed SpanBar - Thomas Morley https://gitlab.com/lilypond/lilypond/-/merge_requests/1408 !1407 Doc: Info: Revise dir entries and make process - John Wheeler https://gitlab.com/lilypond/lilypond/-/merge_requests/1407 Review: !1413 Drop \RemoveEmptyStaffContext, etc. - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1413 !1404 Implement Scheme operators via GOOPS for some smob types - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1404 New: No patches in New at this time. Waiting: !913 release: binaries with cairo - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/913 Cheers, Colin
Re: GC and simple smobs??
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_from_somewhere (); >>> >>> return something_that_needs_scm_obj_alive; >>> >>> // Is this correct? >>> scm_remember_upto_here (scm_obj); >>> >>> >>> Might the compiler detect that return exits the function and >>> ignore the scm_remember_upto_here? >> return; releases the stack frame. "return >> something_that_needs_scm_obj_alive;" is not a valid pattern unless the >> returned value itself is an SCM that will cover scm_obj in its GC scope. > > > > Well, I was thinking of something like this: > > Pitch *p = unsmob (scm_pitch); > return *p; > scm_remember_upto_here (scm_pitch); // ?? Not a good pattern. Just use Pitch p = ... scm_remember_upto_here is not a magic instruction to the compiler but just C code that requires scm_pitch to be still defined. Putting it into a code path that is not being executed is useless. -- David Kastrup
Re: GC and simple smobs??
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 >> pick up the SCM values and mark the associated cells in the heap. > > > > Well, OK, they are small stack values each storing a pointer to > a heap object. Right? Yup. Not a pointer in the C meaning but a pointer in the SCM-encoded manner. >> Why? There is no allocation happening anywhere, so there is no >> reason to do garbage collection. At least I think that is the >> rationale also covering a lot of Guile-internal code. > > > If I understand you correctly, this code doesn't need it, but it would > if there were a call to scm_something () between LY_ASSERT_SMOBbing > and the call to Duration::compare? Yes. In this case it might make more sense not to store pointers but actual durations, like Duration d1 = *LY_ASSERT_SMOB (...); > I thought you said it was unclear whether BDWGC could run outside of > Guile allocations, but if it doesn't, I am happy. I have no idea. It is somewhat troubling that Guile2 is a lot more prone to trigger GC problems than Guile1. -- David Kastrup
Re: GC and simple smobs??
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_scm_obj_alive; // Is this correct? scm_remember_upto_here (scm_obj); Might the compiler detect that return exits the function and ignore the scm_remember_upto_here? return; releases the stack frame. "return something_that_needs_scm_obj_alive;" is not a valid pattern unless the returned value itself is an SCM that will cover scm_obj in its GC scope. Well, I was thinking of something like this: Pitch *p = unsmob (scm_pitch); return *p; scm_remember_upto_here (scm_pitch); // ?? where I thought GC could happen between 'unsmob' and 'return *p', making p a dangling pointer. If you are correct about GC only being triggered upon (Guile) allocations, that wouldn't be a concern.
Re: GC and simple smobs??
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 the associated cells in the heap. Well, OK, they are small stack values each storing a pointer to a heap object. Right? The unsmobbed a and b are thus pointers to data on the BDWGC heap. Correct. Since they are pointers to the part of the SCM that stores the C++ object, and not to the start of the SCM value, they won't cause the SCM to be marked by their mere existence on the stack. Correct. p1 and p2 are not used after the LY_ASSERT_SMOB calls. The compiler could drop them before the end of the function. Unlikely since that would mess up the stack frame, but let's assume so. In that case, nothing protects p1 and p2 between the two LY_ASSERT_SMOB lines and the Duration::compare. If the ly:duration Why? There is no allocation happening anywhere, so there is no reason to do garbage collection. At least I think that is the rationale also covering a lot of Guile-internal code. If I understand you correctly, this code doesn't need it, but it would if there were a call to scm_something () between LY_ASSERT_SMOBbing and the call to Duration::compare? I thought you said it was unclear whether BDWGC could run outside of Guile allocations, but if it doesn't, I am happy. This pattern looks somewhat frequent, so I hope I am wrong. If so, where is my mistake? Hopefully above. Thanks for replying. Jean
Re: GC and simple smobs??
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? > scm_remember_upto_here (scm_obj); > > > Might the compiler detect that return exits the function and > ignore the scm_remember_upto_here? return; releases the stack frame. "return something_that_needs_scm_obj_alive;" is not a valid pattern unless the returned value itself is an SCM that will cover scm_obj in its GC scope. -- David Kastrup
Re: GC and simple smobs??
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 2, 0, 0, (SCM p1, SCM p2),
> R"(
> Is @var{p1} shorter than @var{p2}?
> )")
> {
> auto *const a = LY_ASSERT_SMOB (Duration, p1, 1);
> auto *const b = LY_ASSERT_SMOB (Duration, p2, 2);
>
> if (Duration::compare (*a, *b) < 0)
> return SCM_BOOL_T;
> else
> return SCM_BOOL_F;
> }
>
>
>
> This is my understanding:
>
> Duration is a Simple_smob type.
>
> That means a Duration object can be allocated either on the stack
> or on the BDWGC heap.
>
> Since p1 and p2 are SCM, they are BDWGC-heap-allocated in this case.
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 the associated cells in the heap.
> The unsmobbed a and b are thus pointers to data on the BDWGC heap.
Correct.
>
> Since they are pointers to the part of the SCM that stores the C++
> object, and not to the start of the SCM value, they won't cause the
> SCM to be marked by their mere existence on the stack.
Correct.
> p1 and p2 are not used after the LY_ASSERT_SMOB calls. The compiler
> could drop them before the end of the function.
Unlikely since that would mess up the stack frame, but let's assume so.
> In that case, nothing protects p1 and p2 between the two LY_ASSERT_SMOB
> lines and the Duration::compare. If the ly:duration call, Guile itself might not hold references to the duration objects.
> If that happens, a crash would ensue.
Why? There is no allocation happening anywhere, so there is no reason
to do garbage collection. At least I think that is the rationale also
covering a lot of Guile-internal code.
> This pattern looks somewhat frequent, so I hope I am wrong. If so,
> where is my mistake?
Hopefully above.
--
David Kastrup
Re: GC and simple smobs??
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:duration 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? scm_remember_upto_here (scm_obj); Might the compiler detect that return exits the function and ignore the scm_remember_upto_here?
GC and simple smobs??
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
Re: Distribution delays on mailing lists for GNU LilyPond
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 component that randomly selects emails for moderation regardless of past decisions? That is probably due to case #2, which as I said, we can solve by first migrating the list to mailman 3. Got it. Will wait patiently for the migration. :) -- Aaron Hill
Re: Distribution delays on mailing lists for GNU LilyPond
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 for moderation regardless of past decisions? That is probably due to case #2, which as I said, we can solve by first migrating the list to mailman 3.
Re: Distribution delays on mailing lists for GNU LilyPond
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 the list of moderators that I see in the administrative > interface). That is right. The listhelpers can't help with lists that expect posts in languages other than english. It is enabled on lilypond-devel. I will get around to replying to other things you said later.
Re: Distribution delays on mailing lists for GNU LilyPond
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, this was case #1. Again, I encourage the lilypond list owner/admin to recruit more moderators to approve first time posts. Aaron, I'm removing you from the Cc, so this message will still go through the list to you, take a look at how long it takes to get to you now. 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 for moderation regardless of past decisions? -- Aaron Hill
Re: Distribution delays on mailing lists for GNU LilyPond
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, this was case #1. Again, I encourage the lilypond list owner/admin to recruit more moderators to approve first time posts. Aaron, I'm removing you from the Cc, so this message will still go through the list to you, take a look at how long it takes to get to you now. Perhaps. On the other hand, I am seeing the same on lilypond-user-fr, which doesn't use listhelper as I said. For example: Return-Path: Authentication-Results: kundenserver.de; dkim=pass header.i=@vintherine.org Received: from lists.gnu.org ([209.51.188.17]) by mx.kundenserver.de (mxeue009 [212.227.15.41]) with ESMTPS (Nemesis) id 1Mt6Lp-1nkJpm1mrx-00tXdN for ; Thu, 09 Jun 2022 21:23:11 +0200 Received: from localhost ([::1]:37186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzNkM-0001y2-CD for j...@abou-samra.fr; Thu, 09 Jun 2022 15:23:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzLzl-R9-7H for lilypond-user...@gnu.org; Thu, 09 Jun 2022 13:30:57 -0400 Received: from relay7-d.mail.gandi.net ([2001:4b98:dc4:8::227]:34745) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzLzi-00054U-TP for lilypond-user...@gnu.org; Thu, 09 Jun 2022 13:30:56 -0400 Received: (Authenticated sender: v...@bigre.org) by mail.gandi.net (Postfix) with ESMTPSA id E761620002 for ; Thu, 9 Jun 2022 17:30:49 + (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vintherine.org; s=gm1; t=1654795850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=qtL7ZoxhH5qvtrA3Ja2FLoGDmA3t//V+txXCroOWRpI=; b=X/BykxpiS4OW92PdRlzTAtH9Bc39i0wRzdfJuKzs6JWU1cmMMpp4jMkcjIFTY1yVjr6IRj 6XJsF9me9jZAIqo/BSU/DlghxdRGvkoLHNQxaMA5nEqJ38Oh57kCzdcv8aySAb3Pxjd0Hp ULB8ktIRvpUMO09sleiTZGzqRZ0WLz6oVNu7eXQZOqop49VspJ+B21Cg2kOJCZspDR5bUu fcZHL0J8oVxHn0UD+Uq264XUE7T/JqINPF1WyEWkQBZxVYAV/q0hDvFRROViS0Hld1fBxx kJ0n3KBMhj6u3TFZP77JP7BM/xFuw2RPJnTaj577FJrQtJM6r3qp7xO9RotgSw== Message-ID: Date: Thu, 9 Jun 2022 19:30:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: fr-FR To: Liste de diffusion Lilypond From: Vincent Gay Subject: Fonctionnement de la liste Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2001:4b98:dc4:8::227; envelope-from=v...@vintherine.org; helo=relay7-d.mail.gandi.net
Re: Distribution delays on mailing lists for GNU LilyPond
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 was case #1. Again, I encourage the lilypond list > owner/admin to recruit more moderators to approve first time posts. > > Aaron, I'm removing you from the Cc, so this message will still go > through the list to you, take a look at how long it takes to get to you now. > > > - Ian So, in this case, it took only about 4 seconds for mailman to process it (lists.gnu.org): Received: from lists.gnu.org ([209.51.188.17]:40470) by mail.fsf.org with esmtps (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1o2EZ7-005RuS-73 for i...@fsf.org; Fri, 17 Jun 2022 12:11:21 -0400 Received: from localhost ([::1]:53074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2EZ7-0007Be-0V for i...@fsf.org; Fri, 17 Jun 2022 12:11:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33708) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2EZ3-0007BV-26 for lilypond-devel@gnu.org; Fri, 17 Jun 2022 12:11:17 -0400
Re: Distribution delays on mailing lists for GNU LilyPond
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 lilypond list owner/admin to recruit more moderators to approve first time posts. Aaron, I'm removing you from the Cc, so this message will still go through the list to you, take a look at how long it takes to get to you now. - Ian
Re: Distribution delays on mailing lists for GNU LilyPond
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...@gnu.org. If it hasn't been posted, wait at least 3 hours from when you sent it. Please include the message-id header, from, to, subject, and as close to possible the exact time it was sent including a timezone. In case it helps, your very message to the list was delayed significantly. Here are the relevant headers (with some details redacted): Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by "my mail server" for <"my email">; Fri, 17 Jun 2022 13:02:10 + (GMT) Received: from localhost ([::1]:60372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2Bbz-0005Z5-5C for "my email"; Fri, 17 Jun 2022 09:02:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49270) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <"your email">) id 1o22dr-0004L7-V8 for lilypond-devel@gnu.org; Thu, 16 Jun 2022 23:27:27 -0400 Received: from mail.fsf.org ([2001:470:142::13]:48672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <"your email">) id 1o22dq-0004YE-LM for lilypond-devel@gnu.org; Thu, 16 Jun 2022 23:27:26 -0400 [...] Date: Thu, 16 Jun 2022 22:54:34 -0400 Message-ID: <87k09g7yw2@fsf.org> The major delay appears to happen after eggs.gnu.org hands off to lists.gnu.org, when lists.gnu.org gets the email a second(?) time from "localhost" (lists1p.gnu.org) almost ten hours later. Good point. I checked a couple other list messages I remembered took a long time to arrive and the delay is systematically occurring in that transfer. Jean
Re: Distribution delays on mailing lists for GNU LilyPond
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 least 3 hours from when you sent it. Please include the message-id header, from, to, subject, and as close to possible the exact time it was sent including a timezone. In case it helps, your very message to the list was delayed significantly. Here are the relevant headers (with some details redacted): Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by "my mail server" for <"my email">; Fri, 17 Jun 2022 13:02:10 + (GMT) Received: from localhost ([::1]:60372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2Bbz-0005Z5-5C for "my email"; Fri, 17 Jun 2022 09:02:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49270) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <"your email">) id 1o22dr-0004L7-V8 for lilypond-devel@gnu.org; Thu, 16 Jun 2022 23:27:27 -0400 Received: from mail.fsf.org ([2001:470:142::13]:48672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <"your email">) id 1o22dq-0004YE-LM for lilypond-devel@gnu.org; Thu, 16 Jun 2022 23:27:26 -0400 [...] Date: Thu, 16 Jun 2022 22:54:34 -0400 Message-ID: <87k09g7yw2@fsf.org> The major delay appears to happen after eggs.gnu.org hands off to lists.gnu.org, when lists.gnu.org gets the email a second(?) time from "localhost" (lists1p.gnu.org) almost ten hours later. -- Aaron Hill
Re: Distribution delays on mailing lists for GNU LilyPond
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 > distribution delays. Even though this has been a problem in the > past, it seems to be exacerbated somewhat. On lilypond-user and > lilypond-user-fr at least, it is not infrequent for me to receive > message two or three hours later. Some have reported routinely > receiving emails one or two days after the fact, cf. > https://lists.gnu.org/archive/html/lilypond-user/2022-05/msg00399.html > This is a nail in the project's feet, as people are doing duplicated > work to answer support questions, and are less encouraged to > step in discussions that are exhausted hours before they get > into their inboxes. > > Is this expected? Could something be done about it? > > Thank you for your assistance. > > Best regards, > Jean Abou Samra (developer on GNU LilyPond) Hi, I work at FSF and am the main person there who works on the mailing lists. There are some common causes of delays. #1, most common: When someone posts to the list from an address that has never posted before, the message gets held until a moderator approves it to ensure it isn't spam. Once approved, their future posts are not held for moderation. The moderators are usually just the listhelper team, which is about 2 people who do this a few times a day. That is described here: http://listhelper.nongnu.org/. That can be done much more often if there are people who do moderation. All that needs to happen is that the list administrator/owner gives out the moderation password to people, and optionally add their address to the list moderator field so they get notified when a message is held for moderation. lilypond-devel has their list owner/admin listed as d...@gnu.org. So, I would ask them about that. #2, sometimes mailman gets hung up and delays sending out messages. We don't really know why, but we know that in order to debug the issue, we need to first move to mailman 3. Mailman 2 is no longer supported upstream. There is a good chance the issue will just go away when we move. Mailman 3 also has some nice features like allowing people to post directly from a web archive interface (the current archive interface will continue to exist in mailman 3, there will be 2 or more archive interfaces). We want to have a few lists try out mailman 3 to detect any issues before we move all the lists. Initially, the listhelpers won't be able to help remove spam, they will need a few months to port over their automation to mailman 3. There could be other bumps, but we will work hard to address them and if needed, move lists back to mailman 2 while we do. Does lilypond want one or more of their lists to be one of the initial group to move to mailman 3? #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 least 3 hours from when you sent it. Please include the message-id header, from, to, subject, and as close to possible the exact time it was sent including a timezone. -- Ian Kelling | Senior Systems Administrator, Free Software Foundation GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF https://fsf.org | https://gnu.org
Re: Testing that no grob is created
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 add a callback in the System grob (or in a similar grouping Grob at staff level) that counts the number of bar lines included in the 'elements property. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Testing that no grob is created
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.BarLine.before-line-breaking = #error ?
Testing that no grob is created
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 acknowledges, and enable the warning-as-error option. Any other ideas? — Dan
Re: Distribution delays on mailing lists for GNU LilyPond
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
Re: Distribution delays on mailing lists for GNU LilyPond
>> 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? I support that, at least for 'lilypond-devel'. Werner
Re: Distribution delays on mailing lists for GNU LilyPond
Hi, Thanks for your reply. Le 17/06/2022 à 04:54, Ian Kelling a écrit : 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 distribution delays. Even though this has been a problem in the past, it seems to be exacerbated somewhat. On lilypond-user and lilypond-user-fr at least, it is not infrequent for me to receive message two or three hours later. Some have reported routinely receiving emails one or two days after the fact, cf. https://lists.gnu.org/archive/html/lilypond-user/2022-05/msg00399.html This is a nail in the project's feet, as people are doing duplicated work to answer support questions, and are less encouraged to step in discussions that are exhausted hours before they get into their inboxes. Is this expected? Could something be done about it? Thank you for your assistance. Best regards, Jean Abou Samra (developer on GNU LilyPond) Hi, I work at FSF and am the main person there who works on the mailing lists. There are some common causes of delays. #1, most common: When someone posts to the list from an address that has never posted before, the message gets held until a moderator approves it to ensure it isn't spam. Once approved, their future posts are not held for moderation. The moderators are usually just the listhelper team, which is about 2 people who do this a few times a day. That is described here: http://listhelper.nongnu.org/. That can be done much more often if there are people who do moderation. All that needs to happen is that the list administrator/owner gives out the moderation password to people, and optionally add their address to the list moderator field so they get notified when a message is held for moderation. lilypond-devel has their list owner/admin listed as d...@gnu.org. So, I would ask them about that. For us, it is also happening with posts from active people who are definitely subscribed to the lists. (I'm also one of the admins on lilypond-user-fr, so I see what posts are moderated there, and delays are happening for posts that didn't need moderation.) #2, sometimes mailman gets hung up and delays sending out messages. We don't really know why, but we know that in order to debug the issue, we need to first move to mailman 3. Mailman 2 is no longer supported upstream. There is a good chance the issue will just go away when we move. Mailman 3 also has some nice features like allowing people to post directly from a web archive interface (the current archive interface will continue to exist in mailman 3, there will be 2 or more archive interfaces). We want to have a few lists try out mailman 3 to detect any issues before we move all the lists. Initially, the listhelpers won't be able to help remove spam, they will need a few months to port over their automation to mailman 3. There could be other bumps, but we will work hard to address them and if needed, move lists back to mailman 2 while 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? 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 the list of moderators that I see in the administrative interface). Does this need approval from the list admins? We'd then have to contact the person behind d...@gnu.org (I don't even know who they are). They are apparently the admin for lilypond-user and lilypond-devel. For lilypond-user-fr, I am an admin, so I can give my approval. (Valentin, in CC, is the other admin.) I'm actually pretty eager to have a web interface allowing to post, even if it justs opens a mailto link as far as I can judge from https://mail.python.org/archives/. Back in the days, lilypond-user-fr had a Nabble interface. When Nabble was discontinued, many people said they preferred that and some weren't even understanding how to use the list by email. HyperKitty archives are also much more usable than the current ones because they don't split threads by month. It has happened to me to miss that a thread had continued because it crossed month boundaries. #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 least 3 hours from when you sent it. Please include the message-id header, from, to, subject, and as close to possible the exact time it was sent including a timezone. I don't know how to know if this the cause rather than #2. The thread
