Re: Add Code of Conduct [Another RFC or not now?]

On Sat, Feb 08, 2020 at 11:41:11PM +0100, David Kastrup wrote: > Graham Percival writes: > > Within 2-3 weeks, I had squandered all of the good feelings and energy > > sparked from that meeting. I view that as my worst blunder from all > > my years of involvement with LilyPond. > > Hey, I had

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh File lily/include/smobs.hh (right): https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh#newcode312 lily/include/smobs.hh:312: static size_t count; It seems that this is initialized to zero

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

Because of significant disagreement, and to ensure that LilyPond contributors don't feel pushed, I am hereby officially withdrawing this proposal. I apologize for the disturbance caused by the way I have introduced this. Maybe I'll submit a revised proposal, but if I do, I'll definitely start

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

niedz., 9 lut 2020 o 00:31 napisał(a): > On 2020/02/08 22:57:13, janek wrote: > > Because of significant disagreement, and to ensure that LilyPond > contributors > > don't feel pushed, I am hereby officially withdrawing this proposal. I > apologize > > for the disturbance caused by the way I

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

On 2020/02/08 22:57:13, janek wrote: > Because of significant disagreement, and to ensure that LilyPond contributors > don't feel pushed, I am hereby officially withdrawing this proposal. I apologize > for the disturbance caused by the way I have introduced this. > > Maybe I'll submit a revised

Re: ’Pond Jobs & Their Descriptions

Kieren, I see that I've misunderstood you - I apologize. My LP time today is over, so I'll follow on this topic on the next occasion :) sob., 8 lut 2020 o 23:31 Kieren MacMillan napisał(a): > Hi Janek, > > > I appreciate the initiative, and I agree that we could use a clearer > view on the

Re: Add Code of Conduct [Another RFC or not now?]

Graham, sob., 8 lut 2020 o 21:23 Graham Percival napisał(a): > I don't have any reasons that haven't been mentioned already, > other than one meta-reason: proposals like this are very divisive. > Trying to have this discussion in the middle of a "final sprint > towards 2.20" was unfortunate. >

Re: Add Code of Conduct

James, first, I am sorry that you are so disturbed. I realize that this is partially my fault, so I apologize. sob., 8 lut 2020 o 09:23 James Lowe napisał(a): > On 07/02/2020 09:50, Han-Wen Nienhuys wrote: > > Thanks for your careful observations. > > > > First, the CoC was actually coined by

Re: Add Code of Conduct

Thomas Morley writes: > Am Sa., 8. Feb. 2020 um 14:59 Uhr schrieb Kieren MacMillan > : > >> To me, the greatest shame is that all the positive energy and >> momentum coming out of the Salzburg conference is, it seems, in real >> danger of being shut down by toxic energy of the same kind that has

Re: Add Code of Conduct

niedz., 9 lut 2020 o 00:39 David Kastrup napisał(a): > David Kastrup writes: > > > Janek Warchoł writes: > > > >> Elaine, > >> > >> pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine < > ela...@flaminghakama.com> > >> napisał(a): > >> > >>> 1) "Adopt this CoC or I will leave the community" Such

Re: Add Code of Conduct

+1 to everything Harm said, and big thanks to Werner! (and Urs, who co-organized Salzburg event) Janek sob., 8 lut 2020 o 16:52 Thomas Morley napisał(a): > Am Sa., 8. Feb. 2020 um 14:59 Uhr schrieb Kieren MacMillan > : > > > To me, the greatest shame is that all the positive energy and

Re: Add Code of Conduct

David Kastrup writes: > Janek Warchoł writes: > >> Elaine, >> >> pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine >> napisał(a): >> >>> 1) "Adopt this CoC or I will leave the community" Such threats amount to a >>> my-way-or-the-highway attitude, which is an attempt to enforce veto power >>>

Re: Add Code of Conduct

Janek Warchoł writes: > Elaine, > > pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine > napisał(a): > >> 1) "Adopt this CoC or I will leave the community" Such threats amount to a >> my-way-or-the-highway attitude, which is an attempt to enforce veto power >> in what is supposed to be a

Re: Add Code of Conduct

Elaine, pt., 7 lut 2020 o 02:28 Flaming Hakama by Elaine napisał(a): > 1) "Adopt this CoC or I will leave the community" Such threats amount to a > my-way-or-the-highway attitude, which is an attempt to enforce veto power > in what is supposed to be a collaborative / concensus / democratic >

Re: displayLilyMusic and guilev2

Thomas Morley writes: > Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup : >> >> Thomas Morley writes: >> >> > Hi, >> > >> > one problem with guilev2 are anonymous procedures. Like how to get >> > nice output for >> > >> > \void >> > \displayLilyMusic \new Voice { \applyContext #(lambda

Re: [RFC] weekly dev chats

Janek Warchoł writes: > sob., 8 lut 2020 o 23:56 David Kastrup napisał(a): > >> Janek Warchoł writes: >> > I'd be willing to organize and moderate the meetings (take care of >> > preparing the agenda and sharing the take-aways with the devel list). I >> > know that it'd be a challenge to find

Re: displayLilyMusic and guilev2

Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Hi, > > > > one problem with guilev2 are anonymous procedures. Like how to get > > nice output for > > > > \void > > \displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) > > b4 } > > >

Re: displayLilyMusic and guilev2

Thomas Morley writes: > Hi, > > one problem with guilev2 are anonymous procedures. Like how to get > nice output for > > \void > \displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 > } > > An older lily-build out of e57c27dc14 with the patches from > guilev2-work on

Re: [RFC] weekly dev chats

sob., 8 lut 2020 o 23:56 David Kastrup napisał(a): > Janek Warchoł writes: > > I'd be willing to organize and moderate the meetings (take care of > > preparing the agenda and sharing the take-aways with the devel list). I > > know that it'd be a challenge to find a time that will work for

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

Hi David (et al.), > I don't think grace notes are usually synchronized optically. According to our recent "live-from-London" keynote speaker… ;) … you are correct — in fact, in one example, she shows how grace groups [of different "sizes"] on two different staves can be compressed [to the

Re: [RFC] weekly dev chats

Janek Warchoł writes: > Hello, > > I just got inspired by the Agile Manifesto Principles[1], specifically: >> The most efficient and effective method of >> conveying information to and within a development >> team is face-to-face conversation. > > This reminded me how dynamic, positive and

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

Han-Wen Nienhuys writes: > Unfortunately, it's not obvious where to insert the skips. Consider this > > staff1 : grace 16th, whole note > > staff2 : X, whole note > > now, if X is a \clef, you probably want to insert the skip after the X, but > if X is a \once \override for the NoteHead,

Re: Add Code of Conduct [Another RFC or not now?]

Graham Percival writes: > On Sat, Feb 08, 2020 at 07:21:30PM +, Trevor wrote: >> Phil Holmes wrote 08/02/2020 17:24:56 >> Subject: Re: Add Code of Conduct [Another RFC or not now?] >> >> > - Original Message - From: "Karlin High" > > > However, I'd like to hear from David Kastrup

Re: parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

On 2020/02/08 22:02:59, dak wrote: > Uh, is this the right issue to discuss this with? Likely not, I opened a thread on -devel. > Are you completely sure that you are using a version of LilyPond compiled with > Guile-2.2.6? At least $ lilypond-git scheme-sandbox returns: GNU LilyPond

displayLilyMusic and guilev2

Hi, one problem with guilev2 are anonymous procedures. Like how to get nice output for \void \displayLilyMusic \new Voice { \applyContext #(lambda (ctx) (display ctx)) b4 } An older lily-build out of e57c27dc14 with the patches from guilev2-work on top and guile-2.0.14 returned: \new Voice {

Re: [RFC] Commit message format

+1 to all parts of the proposal from me. pt., 7 lut 2020 o 16:39 Han-Wen Nienhuys napisał(a): > Currently, on push most our commit messages look like: > > Issue XXX: Subject > > Body > Body > > > There are a couple of downsides to this format: > > * The number takes up space in the

Re: [RFC] weekly dev chats

Hi Janek, > I suggest to have weekly dev "meetings". If they are at a time when I’m available, I’d be more than happy to be involved. Regardless, it’s a great idea — in fact, I was in the middle of drafting an email to suggest it when your email came through. =) Cheers, Kieren.

Re: RFC: docker for CI

sob., 8 lut 2020 o 23:30 Janek Warchoł napisał(a): > In principle, thumbs up. However, I think it's essential that we don't try > to do too much at once; I'd suggest to focus on one most important aspect > first. To do that, I'd like to ask a helper question: what are 2 most > important reasons

Re: ’Pond Jobs & Their Descriptions

Hi Janek, > I appreciate the initiative, and I agree that we could use a clearer view on > the responsibilities and skills needed in the community. However, I am pretty > sure that creating a detailed list is not an effective way of solving this > problem. I'm pretty sure that we'd spend a

Re: RFC: docker for CI

In principle, thumbs up. However, I think it's essential that we don't try to do too much at once; I'd suggest to focus on one most important aspect first. To do that, I'd like to ask a helper question: what are 2 most important reasons for using Docker instead of Patchy? In other words, what are

[RFC] weekly dev chats

Hello, I just got inspired by the Agile Manifesto Principles[1], specifically: > The most efficient and effective method of > conveying information to and within a development > team is face-to-face conversation. This reminded me how dynamic, positive and motivating were the LP talks in

Re: ’Pond Jobs & Their Descriptions

Hi Kieren, czw., 6 lut 2020 o 00:55 Kieren MacMillan napisał(a): > Hello all! > > I’m curious as to all the various jobs/tasks required to keep Lilypond > development moving forward at the fastest possible pace and in the most > efficient possible way. Is there a single list compiled anywhere,

Re: parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

Reviewers: thomasmorley651, https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm File scm/parser-ly-from-scheme.scm (right): https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm#newcode19 scm/parser-ly-from-scheme.scm:19: (define

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

Han-Wen Nienhuys ezt írta (időpont: 2020. febr. 8., Szo 21:44): > > > If we construct the grace note grobs in a > special pass, there is nothing to synchronize them across staves. You could > have two-handed piano music where the left and right hand do grace notes in > a synchronized way. I

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

Am 08.02.20 um 21:44 schrieb Han-Wen Nienhuys: I think the right solution would be to kill grace timing altogether, and initiate some sort special "embedded" engraving pass that creates the Grace grobs all at once. That would have another downside: if we construct the grace note grobs in a

Don't let display-lily-tests use anonymous functions (issue 545550044 by d...@gnu.org)

LGTM https://codereview.appspot.com/545550044/

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

On Fri, Feb 7, 2020 at 2:46 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi all, > > Here’s the brainstorm I’ve currently got going: > > Issue #34, a.k.a. the grace note bug, is one of Lilypond’s > longest-standing and most newbie-unfriendly issues. It doesn’t appear in >

parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

Afaict, LGTM A remark: https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm File scm/parser-ly-from-scheme.scm (right): https://codereview.appspot.com/581610043/diff/569310043/scm/parser-ly-from-scheme.scm#newcode19 scm/parser-ly-from-scheme.scm:19: (define

Re: Add Code of Conduct [Another RFC or not now?]

On Sat, Feb 08, 2020 at 07:21:30PM +, Trevor wrote: > Phil Holmes wrote 08/02/2020 17:24:56 > Subject: Re: Add Code of Conduct [Another RFC or not now?] > > > - Original Message - From: "Karlin High" > > However, I'd like to hear from David Kastrup and James Lowe first. To me, > > >

Re: Add Code of Conduct [Another RFC or not now?]

Trevor writes: > Phil Holmes wrote 08/02/2020 17:24:56 > Subject: Re: Add Code of Conduct [Another RFC or not now?] > >>- Original Message - From: "Karlin High" >>However, I'd like to hear from David Kastrup and James Lowe >> first. To me, their opposition registered as the strongest.

Re: Add Code of Conduct [Another RFC or not now?]

Karlin High writes: > On 2/8/2020 11:24 AM, Phil Holmes wrote: >> I remain strongly opposed to a CoC. > > Clearly noted; thanks for responding. I have nothing further to say on > this topic just now; it's pretty much all been covered in prior > messages. > > I'm sorry if I got your name wrong. I

Re: Add Code of Conduct [Another RFC or not now?]

pkx1...@posteo.net writes: > Anyway to answer Karlin's request, I am probably the last person in > the 'dev' team to worry about. Yes I seem to do a lot of 'work' but it > *is* just 'janitorial' duties (which is a rather good way to explain > it) and, assuming we do manage to get the automation

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

On 2020/02/08 20:05:53, hanwenn wrote: > Use smob count as memory proxy This looks good to me now; softcoding the 2000 is left as an exercise to the reader in another commit https://codereview.appspot.com/561390043/

Re[2]: Add Code of Conduct [Another RFC or not now?]

Phil Holmes wrote 08/02/2020 17:24:56 Subject: Re: Add Code of Conduct [Another RFC or not now?] - Original Message - From: "Karlin High" However, I'd like to hear from David Kastrup and James Lowe first. To me, their opposition registered as the strongest. I remain strongly opposed

Re: Add Code of Conduct [Another RFC or not now?]

Hi Karlin, > In my opinion, positive things have indeed come out of these threads. They > may not be what any one person had in mind, but that's to be expected > whenever a community discusses something. That’s exactly what I was going to say. =) Best, Kieren.

Re: Add Code of Conduct [Another RFC or not now?]

On 2/8/2020 12:46 PM, pkx1...@posteo.net wrote: then something positive would have come out of this CoC thread after all. Thanks for your response; clearly noted. Phil Holmes makes builds. James Lowe manages issue and patch reviews. Hopefully I can remember this. In my opinion, positive

Re: Add Code of Conduct [Another RFC or not now?]

On 08/02/2020 17:50, Werner LEMBERG wrote: GNU Kind Communication Guidelines To-may-to, To-mah-to Werner. Anyway to answer Karlin's request, I am probably the last person in the 'dev' team to worry about. Yes I seem to do a lot of 'work' but it *is* just 'janitorial' duties (which is a

Re: Add Code of Conduct [Another RFC or not now?]

Am 8. Februar 2020 19:23:34 MEZ schrieb Karlin High : >On 2/8/2020 11:24 AM, Phil Holmes wrote: >> I remain strongly opposed to a CoC. > >Clearly noted; thanks for responding. I have nothing further to say on >this topic just now; it's pretty much all been covered in prior >messages. > >I'm

Re: RFC: docker for CI

On Sat, Feb 8, 2020 at 7:24 PM Jonas Hahnfeld wrote: > > the point is that you can take a snapshot of the full build at a point > in time. As long as the C++ code doesn't change dramatically between that > point and the commit to be tested, you'd get cache hits on a "clean" build > at a new

Re: RFC: docker for CI

Am Samstag, den 08.02.2020, 19:18 +0100 schrieb Han-Wen Nienhuys: > > > On Sat, Feb 8, 2020 at 2:05 PM Jonas Hahnfeld wrote: > > > > * if instead we build images for every commit, then incremental > > > > building of a provided patch will be fast(er) (_if_ it doesn't touch > > > > any header

Re: Add Code of Conduct [Another RFC or not now?]

On 2/8/2020 11:24 AM, Phil Holmes wrote: I remain strongly opposed to a CoC. Clearly noted; thanks for responding. I have nothing further to say on this topic just now; it's pretty much all been covered in prior messages. I'm sorry if I got your name wrong. I know "Phil Holmes" and "James

Re: RFC: docker for CI

On Fri, Feb 7, 2020 at 9:48 PM Dan Eble wrote: > On Feb 7, 2020, at 15:21, Han-Wen Nienhuys wrote: > >>> * use a headless browser to take a image snapshot of the top of > regtest > >>> result page. > >>> > >> Sounds convoluted. Why not attach the difference images directly? > > > > Those

Re: RFC: docker for CI

On Sat, Feb 8, 2020 at 2:05 PM Jonas Hahnfeld wrote: > > > > * if instead we build images for every commit, then incremental > > > building of a provided patch will be fast(er) (_if_ it doesn't touch > > > any header file). But what's then the point of using ccache, we can > > > just trigger a

Re: event queue with thread for c++

On Sat, Feb 8, 2020 at 6:46 PM Jonas Hahnfeld wrote: > > > > Does this already solve your needs? > > I found a way, using pthread_create. Unfortunately, it's doesn't really > work, because there is no way to discover the size of the live set. > > Hm, spawning a new thread for every heap

Re: Add Code of Conduct [Another RFC or not now?]

- Original Message - From: "Werner LEMBERG" To: Cc: ; ; ; ; Sent: Saturday, February 08, 2020 5:50 PM Subject: Re: Add Code of Conduct [Another RFC or not now?] However, I'd like to hear from David Kastrup and James Lowe first. To me, their opposition registered as the

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

>>> See the line above which is in CMU Concrete! > >> ??? I use Emacs to read my e-mail, and emacs is configured to use >> the font 'DejaVu Sans Mono' on my GNU/Linux box. This font >> contains Cyrillic glyphs... > > I composed that line in the email using CMU Concrete. Presumably > your

Re: Add Code of Conduct [Another RFC or not now?]

On 2/8/20, 10:55 AM, "lilypond-devel on behalf of David Kastrup" wrote: Werner LEMBERG writes: >>> However, I'd like to hear from David Kastrup and James Lowe >>> first. To me, their opposition registered as the strongest. >> >> I remain strongly opposed to a CoC.

Re: Add Code of Conduct [Another RFC or not now?]

Werner LEMBERG writes: >>> However, I'd like to hear from David Kastrup and James Lowe >>> first. To me, their opposition registered as the strongest. >> >> I remain strongly opposed to a CoC. > > Hmm. What about simply using the GNU Kind Communication Guidelines, > maybe adding 'LilyPond' at

Re: Add Code of Conduct [Another RFC or not now?]

>> However, I'd like to hear from David Kastrup and James Lowe >> first. To me, their opposition registered as the strongest. > > I remain strongly opposed to a CoC. Hmm. What about simply using the GNU Kind Communication Guidelines, maybe adding 'LilyPond' at some strategic places?

Re: event queue with thread for c++

Am Samstag, den 08.02.2020, 18:36 +0100 schrieb Han-Wen Nienhuys: > > > On Sat, Feb 8, 2020 at 4:23 PM David Kastrup wrote: > > > Does this already solve your needs? > > > > I found a way, using pthread_create. Unfortunately, it's doesn't really > work, because there is no way to discover

Re: event queue with thread for c++

Han-Wen Nienhuys writes: > On Sat, Feb 8, 2020 at 4:23 PM David Kastrup wrote: > >> >> > Does this already solve your needs? >> > > I found a way, using pthread_create. Unfortunately, it's doesn't really > work, because there is no way to discover the size of the live set. Frankly, if a

Re: event queue with thread for c++

On Sat, Feb 8, 2020 at 4:23 PM David Kastrup wrote: > > > Does this already solve your needs? > I found a way, using pthread_create. Unfortunately, it's doesn't really work, because there is no way to discover the size of the live set. > > Jonas > > It's worth pointing out that almost _all_

Re: Add Code of Conduct [Another RFC or not now?]

- Original Message - From: "Karlin High" However, I'd like to hear from David Kastrup and James Lowe first. To me, their opposition registered as the strongest. I remain strongly opposed to a CoC. -- Phil Holmes

Re: Add Code of Conduct

Am Samstag, den 08.02.2020, 17:52 +0100 schrieb David Kastrup: > Urs Liska writes: > > > Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup: > > > Thomas Morley writes: > > > > > > > P.S. that 'make test-baseline' failed, I'll need to investigate > > > > after > > > > sending this.

Re: Add Code of Conduct

Urs Liska writes: > Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup: >> Thomas Morley writes: >> >> > P.S. that 'make test-baseline' failed, I'll need to investigate >> > after >> > sending this. >> > >> > >> >> input/regression/display-lily-tests.ly:230:1: fatal error: Test

Re: Add Code of Conduct

Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup: > Thomas Morley writes: > > > P.S. that 'make test-baseline' failed, I'll need to investigate > > after > > sending this. > > > > > > input/regression/display-lily-tests.ly:230:1: fatal error: Test > unequal: BUG. > in =

Re: Add Code of Conduct

Thomas Morley writes: > P.S. that 'make test-baseline' failed, I'll need to investigate after > sending this. > > input/regression/display-lily-tests.ly:230:1: fatal error: Test unequal: BUG. in = \applyOutput Foo #(lambda (arg) (list)) out = \applyOutput Foo ##f \test ##[ \applyOutput Foo

Re: Add Code of Conduct

Kieren MacMillan writes: > Hi Harm, > > Fair points, all. > >> Again a big, big THANK YOU to Werner and all who made it possible!! > > +1! Major seconded. >> Not going into details of the CoC-discussion, why not handle it as what it >> is: >> It's a patch. Review showed there are too many

Re: Add Code of Conduct

Hi Harm, Fair points, all. > Again a big, big THANK YOU to Werner and all who made it possible!! +1! > Not going into details of the CoC-discussion, why not handle it as what it is: > It's a patch. Review showed there are too many objections. Thus it > should be set to 'needs work' or

Re: Add Code of Conduct

Thomas Morley writes: > Although my time is very limited during the usual workingweek, I'd > love to do more on the guile-v2-thingy or at least doing tests for the > already done work, etc. Instead I write this mail (okay, a 'make > test-baseline' runs in the background) or read through very

Re: Add Code of Conduct [Another RFC or not now?]

On 2/8/2020 9:17 AM, David Kastrup wrote: I've proposed looking at the GNU Kind Communication Guidelines as something that one can point to and aim to heed. . It has certainly worthwhile advice. Thanks for the link. I saw it earlier,

Re: Add Code of Conduct

Am Sa., 8. Feb. 2020 um 14:59 Uhr schrieb Kieren MacMillan : > To me, the greatest shame is that all the positive energy and momentum coming > out of the Salzburg conference is, it seems, in real danger of being shut > down by toxic energy of the same kind that has led to the community

Re: event queue with thread for c++

Jonas Hahnfeld via Discussions on LilyPond development writes: > Am Freitag, den 07.02.2020, 19:26 +0100 schrieb Han-Wen Nienhuys: >> Hey Dan, >> >> I thought you might know this. >> >> To do >> https://codereview.appspot.com/561390043/ >> properly, I have to expand >> the heap when GC

Re: Add Code of Conduct [Another RFC or not now?]

Karlin High writes: > I think the Code of Conduct discussion is reaching (or has reached) > the point of exhaustion and is unlikely to be productive if continued > further in current directions. It seems there is pretty strong > opposition to adopting the Contributor Covenant Code of Conduct as

Re: Splitting Staves

Hi David, > the programming/Scheme layer of LilyPond often allows to _map_ > a problem description in composer terms to an approach in LilyPond terms. > So sometimes finding a consistent way of describing and structuring a > problem may garner the necessary help from the list that then provides a

Re: Splitting Staves

Kieren MacMillan writes: > Hi Dan (et al.), > >> On Feb 6, 2020, at 09:32, Kieren MacMillan >> wrote: >>> So what I want to work on is some sort of ”Splittable Staff“. > > Just to be clear, Valentin wrote that, not me. =) > >> This terminology looks at the use case from a point of view that

Re: event queue with thread for c++

Am Freitag, den 07.02.2020, 19:26 +0100 schrieb Han-Wen Nienhuys: > Hey Dan, > > I thought you might know this. > > To do > https://codereview.appspot.com/561390043/ > properly, I have to expand > the heap when GC notifies us that a collection took place. Unfortunately, > libgc notifications

Re: Add Code of Conduct [Another RFC or not now?]

I think the Code of Conduct discussion is reaching (or has reached) the point of exhaustion and is unlikely to be productive if continued further in current directions. It seems there is pretty strong opposition to adopting the Contributor Covenant Code of Conduct as originally proposed. I'm

Re: Splitting Staves

Hi Dan (et al.), > On Feb 6, 2020, at 09:32, Kieren MacMillan > wrote: >> So what I want to work on is some sort of ”Splittable Staff“. Just to be clear, Valentin wrote that, not me. =) > This terminology looks at the use case from a point of view that might not be > very consistent with

Re: Add Code of Conduct

Hi James, > What a shame. To me, the greatest shame is that all the positive energy and momentum coming out of the Salzburg conference is, it seems, in real danger of being shut down by toxic energy of the same kind that has led to the community attrition over the last 5-7 years. Just an

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

Hi Wol, > The worry is that said developer may decide his talents > are better spent elsewhere, and he'll quit ... We need to weigh that concert against the documented reality that multiple other developers have already done so, and the worry that more might follow (or never join in the first

Re: Mac 64-bit builds: Guile segfault?

On Sat, Feb 8, 2020 at 8:39 AM Thomas Morley wrote: [...] > > There are some reports of segfaulting builds of guile "Segfault while > building on 64-bit Cygwin" > https://lists.gnu.org/archive/html/guile-devel/2020-01/msg00112.html > > I doubt it's relevant, though. Those reports are for

Re: Mac 64-bit builds: Guile segfault?

Am Sa., 8. Feb. 2020 um 13:51 Uhr schrieb Marnen Laibow-Koser : > > Folks— > > From the feedback I’ve been getting, it looks like my 64-bit Mac builds are > working well for most people. However, one user—one only one of two Macs > he has access to—is consistently getting a segfault with these

Re: Mac 64-bit builds: Guile segfault?

> On 8 Feb 2020, at 13:51, Marnen Laibow-Koser wrote: > > From the feedback I’ve been getting, it looks like my 64-bit Mac builds are > working well for most people. However, one user—one only one of two Macs > he has access to—is consistently getting a segfault with these builds right >

Re: RFC: docker for CI

Am Samstag, den 08.02.2020, 13:51 +0100 schrieb David Kastrup: > Jonas Hahnfeld via Discussions on LilyPond development > < > lilypond-devel@gnu.org > > writes: > > > Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys: > > > Considerations > > > == > > > > > > * Because

Re: RFC: docker for CI

Jonas Hahnfeld via Discussions on LilyPond development writes: > Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys: >> >> Considerations >> == >> >> * Because the build happens inside a container, we can test multiple >> builds. We could build against guile 1.8 and

Mac 64-bit builds: Guile segfault?

Folks— >From the feedback I’ve been getting, it looks like my 64-bit Mac builds are working well for most people. However, one user—one only one of two Macs he has access to—is consistently getting a segfault with these builds right around the time that it loads Guile and/or lily.scm (he says

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

- Saturday, February 8, 2020, 5:03:15 AM, you wrote: >> Теноры >> Very odd - I've just installed a CMU font and it's got all the >> Russian alphabet. > What exactly do you mean with 'installing'? I'm talking about the > creation of PDF files using xelatex, using only

Re: RFC: docker for CI

Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys: > Proposal: rather than using the patchy scripts for validating > LilyPond, we use docker images. > > General idea > > > There is a script ("driver") that drives docker running on a dedicated > build machine ("host").

Re: Integration of Guilev2 branches into master

David Kastrup writes: > David Kastrup writes: >> Han-Wen Nienhuys writes: >> >>> On Fri, Feb 7, 2020 at 6:54 PM David Kastrup wrote: >>> I propose that I am going to pick up the pieces of not-actually-formally-reviewed patches making up the bulk of them and put them,

PATCHES - Countdown for February 8th

Hello, Here is the current patch countdown list. The next countdown will be on February 10th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ *** Push: 5733 Fix various type-conversion warnings - Dan Eble

Re: Add Code of Conduct

On 07/02/2020 09:50, Han-Wen Nienhuys wrote: Thanks for your careful observations. First, the CoC was actually coined by Mike, and I saw it as a proposal to bring LilyPond into the next decade. What is that even supposed to mean? Again empty, ]words that sound 'nice' but mean nothing. A