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

I am trying to understand the origins, motivations, and goals of this effort to adopt a Code of Conduct. Could its proponents read and comment on the following blog posts, identifying points of agreement and disagreement? https://www.wingolog.org/archives/2017/09/04/the-hardest-thing-about-hiring-

Re: Add a tentative .clang-format for LilyPond. (issue 561340043 by hanw...@gmail.com)

On 2020/02/04 23:40:03, dak wrote: > Personally, the best of two worlds would be if a ping-pong between our current > Astyle and clang-format would end up stable after one application of each. That > way, putting the code base through both Astyle and clang-format semi-regularly > would put it into

Re: Add a tentative .clang-format for LilyPond. (issue 561340043 by hanw...@gmail.com)

On 2020/02/04 22:18:23, hanwenn wrote: > On 2020/02/04 20:35:40, Dan Eble wrote: > > I'm running some of my patches through clang-format as I prepare to push them. > > > > This is an example of a kind of change it wants to make: > > > > - const array key {column_rank, dir}; > > + const array ke

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

What problem are we trying to solve here? https://codereview.appspot.com/575620043/

Re: development process

Han-Wen Nienhuys writes: > My experiences with the current Lilypond development process. > > For context, I have a busy daytime job. I work 80% so I can set aside > a couple of hours of concentrated hacking time on Friday. When I am in > my element, I can easily churn out a dozen commits in a day

Re: development process

I've just went through the patch upload process (for proposed Code of Conduct https://codereview.appspot.com/575620043/) and I agree that it should be changed. It was obscure and confusing even for me. cheers, Janek wt., 4 lut 2020 o 22:57 Han-Wen Nienhuys napisał(a): > As promised in several c

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

Reviewers: pkx166h, Message: It seems I cannot create issues on sourceforge despite having an account... > Please enter a valid tracker issue number > (or enter nothing to create a new issue): > Error code 403 > Failed URL was https://sourceforge.net/rest/p/testlilyissues/issues//new James, can

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

On Tue, Feb 4, 2020 at 7:50 PM wrote: > On 2020/02/02 22:33:50, hanwenn wrote: > > For testing, use > > > > https://github.com/hanwen/lilypond/tree/guile22-experiment > > So I ran this with the large example and I see > GC Warning: Failed to expand heap by 30635458560 bytes > a few times (that's

Re: Add a tentative .clang-format for LilyPond. (issue 561340043 by hanw...@gmail.com)

On 2020/02/04 20:35:40, Dan Eble wrote: > I'm running some of my patches through clang-format as I prepare to push them. > > This is an example of a kind of change it wants to make: > > - const array key {column_rank, dir}; > + const array key{column_rank, dir}; > > Note the space after key.

Re: PATCHES - Countdown for February 4th

Somehow https://codereview.appspot.com/577410045/ got lost in the process. OK to push? On Tue, Feb 4, 2020 at 7:34 AM wrote: > Hello, > > Here is the current patch countdown list. The next countdown will be on > February 6th. > > A quick synopsis of all patches currently in the review process ca

Rewrite define-session and define-session-public macros (issue 549510043 by d...@gnu.org)

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

Re: Use define-syntax for define-session[-public] (issue 553480044 by hanw...@gmail.com)

On 2020/02/04 21:15:44, dak wrote: > NLGTM > > This patch just punts on using an internal function, and that could be equally > well be done without involving syntax-case. > > An alternative proposal that just relies on a single external symbol in order to > achieve the original design is given a

development process

As promised in several code reviews, here my take on the current development process. I wrote it as a google doc first, so you can also go here https://docs.google.com/document/d/1BSffzjiQKMTTmr988ezMbsJyfwT9S-rxGRbYSBTv3PM/edit for inline comments. Context: - https://codereview.appspot.c

Re: Janek is coming back to LilyPond! :-)

wt., 21 sty 2020 o 19:33 Kieren MacMillan napisał(a): > 1. Wonderful to have you back! > 2. There’s this lyrics thing maybe you could take a look at…? ;) :-) Hopefully it can be one of the next things I work on. But contributing process must come first. J

Re: Janek is coming back to LilyPond! :-)

Hello (again), I guess an explanation of the silence on my side is in place... For some time now I'm struggling with some personal problems that make me, well, occasionally "unusable". Unfortunately one such situation occurred after I wrote, and I managed to pull myself together only this week. I

Re: [testlilyissues:issues] #5719 Tie formatting maintenance

> On Feb 4, 2020, at 16:14, Dan Eble wrote: > > Begin forwarded message: >> >> Subject: [testlilyissues:issues] #5719 Tie formatting maintenance > ... >> commit 937e413c0f399b2ec44785b7ca29d61cf7b24cff >> Author: Dan Eble >> Date: Fri Jan 31 13:48:35 2020 -05

Re: Use define-syntax for define-session[-public] (issue 553480044 by hanw...@gmail.com)

NLGTM This patch just punts on using an internal function, and that could be equally well be done without involving syntax-case. An alternative proposal that just relies on a single external symbol in order to achieve the original design is given as Tracker issue: 5735 (https://sourceforge.net/p

Fwd: [testlilyissues:issues] #5719 Tie formatting maintenance

Begin forwarded message: > > Subject: [testlilyissues:issues] #5719 Tie formatting maintenance ... > commit 937e413c0f399b2ec44785b7ca29d61cf7b24cff > Author: Dan Eble > Date: Fri Jan 31 13:48:35 2020 -0500 The changes for Issue 5719 remove a header file. If you

Re: Add a tentative .clang-format for LilyPond. (issue 561340043 by hanw...@gmail.com)

I'm running some of my patches through clang-format as I prepare to push them. This is an example of a kind of change it wants to make: - const array key {column_rank, dir}; + const array key{column_rank, dir}; Note the space after key. The setting that controls this is SpaceBeforeCpp11Braced

Re: Fix convert-ly with Python 3 (issue 555260044 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py#newcode361 scripts/convert-ly.py:361: f = f On 2020/02/04 19:45:33, dak wrote: > That line looks spuriou

Re: Fix convert-ly with Python 3 (issue 555260044 by jonas.hahnf...@gmail.com)

https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/555260044/diff/567150044/scripts/convert-ly.py#newcode361 scripts/convert-ly.py:361: f = f That line looks spurious. Any reason for keeping it in? ht

Re: Fix convert-ly with Python 3 (issue 555260044 by jonas.hahnf...@gmail.com)

Reviewers: dak, Message: On 2020/02/04 19:32:10, dak wrote: > Foreseeable consequences for Python 2.7? None, because the minimum version is Python 3.5 Description: Fix convert-ly with Python 3 The error was "'str' object has no attribute 'decode'", so it already is decoded. The encoding seems t

Fix convert-ly with Python 3 (issue 555260044 by jonas.hahnf...@gmail.com)

Foreseeable consequences for Python 2.7? https://codereview.appspot.com/555260044/

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

On 2020/02/02 22:33:50, hanwenn wrote: > For testing, use > > https://github.com/hanwen/lilypond/tree/guile22-experiment So I ran this with the large example and I see GC Warning: Failed to expand heap by 30635458560 bytes a few times (that's 30 GB, my laptop only has 8 GB!!) and finally warning:

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

"Phil Holmes" writes: > - Original Message - From: "David Kastrup" >> Wow. Ok, maybe I'll just apply this patch then (though I'll at >> least >> remove the conditioning on Apple here as the problem is rather likely >> platform independent) and Phil may have another round. >> -- >> Davi

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

- Original Message - From: "David Kastrup" Wow. Ok, maybe I'll just apply this patch then (though I'll at least remove the conditioning on Apple here as the problem is rather likely platform independent) and Phil may have another round. -- David Kastrup Will kick this off again tom

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

David Kastrup writes: > Halving the useful range before overflows is a problem, so I'll stick > with most of the guards. Though I am skeptical that stuff exceeding I64 > has much of a chance of working well, anyway. I have pushed a slightly modified version of the patch (removing the __APPLE__

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Am Dienstag, den 04.02.2020, 11:08 -0500 schrieb Dan Eble: > On Feb 4, 2020, at 11:02, Jonas Hahnfeld < > hah...@hahnjo.de > > wrote: > > > That would be my impulse as well. It is not like this code appears to > > > have notable drawbacks for the unafflicted platforms. > > > > Except for very fun

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

On Feb 4, 2020, at 11:02, Jonas Hahnfeld wrote: >> That would be my impulse as well. It is not like this code appears to >> have notable drawbacks for the unafflicted platforms. > > Except for very funny overflows and negative signs if the value is too > large to fit into I64 ;-P > > unsigned l

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Jonas Hahnfeld writes: > Am Dienstag, den 04.02.2020, 16:57 +0100 schrieb David Kastrup: >> Dan Eble < >> d...@faithful.be >> > writes: >> >> > On Feb 4, 2020, at 09:44, Masamichi Hosoda < >> > truer...@trueroad.jp >> > > wrote: >> > > +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86, >>

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Am Dienstag, den 04.02.2020, 17:03 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble: > > > > On Feb 4, 2020, at 10:32, Jonas Hahnfeld < > > > > hah...@hahnjo.de > > > > > > > > > wrote: > > > > > > > >

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Jonas Hahnfeld writes: > Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble: >> > On Feb 4, 2020, at 10:32, Jonas Hahnfeld < >> > hah...@hahnjo.de >> > > wrote: >> > >> > Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda: >> > > > > $ >> > > > > ~gub/gub/target/linux-x86/r

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Am Dienstag, den 04.02.2020, 16:57 +0100 schrieb David Kastrup: > Dan Eble < > d...@faithful.be > > writes: > > > On Feb 4, 2020, at 09:44, Masamichi Hosoda < > > truer...@trueroad.jp > > > wrote: > > > +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86, > > > +// it seems that static cast fr

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble: > > On Feb 4, 2020, at 10:32, Jonas Hahnfeld < > > hah...@hahnjo.de > > > wrote: > > > > Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda: > > > > > $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c > > > >

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Dan Eble writes: > On Feb 4, 2020, at 09:44, Masamichi Hosoda wrote: >> >> +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86, >> +// it seems that static cast from `unsigned long long` to `double` >> +// by x86 SSE2 raises an internal compile error. >> +// However, static cast from `signe

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

> On Feb 4, 2020, at 10:32, Jonas Hahnfeld wrote: > > Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda: $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2 -mfpmath=sse -I include -I .. rational.cc >> $ ~gub/gub/target/freebsd-x86/root/usr/

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

On Feb 4, 2020, at 09:44, Masamichi Hosoda wrote: > > +// FIXME: workaround: In GUB, g++ 4.9.4 for darwin-x86, > +// it seems that static cast from `unsigned long long` to `double` > +// by x86 SSE2 raises an internal compile error. > +// However, static cast from `signed long long` to `double` >

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda: > >> $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2 > >> -mfpmath=sse -I include -I .. rational.cc > > >> $ ~gub/gub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd6-g++ -c > >> -msse2 -mfpmath=sse -I

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

>> $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2 >> -mfpmath=sse -I include -I .. rational.cc >> $ ~gub/gub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd6-g++ -c -msse2 >> -mfpmath=sse -I include -I .. rational.cc > > So this only affects darwin-x86 which confirms

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

- Original Message - From: "David Kastrup" To: "Masamichi Hosoda" Cc: ; Sent: Tuesday, February 04, 2020 2:56 PM Subject: Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com) Wouldn't the same problem occur on Wind

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

> We currently have the problem that the compiler used in GUB for > compiling 32bit binaries gets an internal compiler fault for those > options. > > We'll need to figure out whether a newer compiler does the trick, and if > it does, update GUB. Or find a different way of

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Masamichi Hosoda writes: We currently have the problem that the compiler used in GUB for compiling 32bit binaries gets an internal compiler fault for those options. We'll need to figure out whether a newer compiler does the trick, and if it does, update GUB. Or fin

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Am Dienstag, den 04.02.2020, 23:44 +0900 schrieb Masamichi Hosoda: > >>> We currently have the problem that the compiler used in GUB for > > >>> compiling 32bit binaries gets an internal compiler fault for those > > >>> options. > > >>> > > >>> We'll need to figure out whether a newer compiler

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

>>> We currently have the problem that the compiler used in GUB for >>> compiling 32bit binaries gets an internal compiler fault for those >>> options. >>> >>> We'll need to figure out whether a newer compiler does the trick, and if >>> it does, update GUB. Or find a different way of proceeding.

Re: Issue 5733: Fix various type-conversion warnings (issue 559450053 by nine.fierce.ball...@gmail.com)

Reviewers: lemzwerg, Message: On 2020/02/04 10:45:58, lemzwerg wrote: > lily/accidental-placement.cc:62: scm_from_long (stagger ? context_hash : 1)); > Are you actually trying clang-format? There's one space too much :-) I was too lazy to deal with Han-Wen's config file as a patch. Now that it

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Masamichi Hosoda writes: >> We currently have the problem that the compiler used in GUB for >> compiling 32bit binaries gets an internal compiler fault for those >> options. >> >> We'll need to figure out whether a newer compiler does the trick, and if >> it does, update GUB. Or find a differen

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

> We currently have the problem that the compiler used in GUB for > compiling 32bit binaries gets an internal compiler fault for those > options. > > We'll need to figure out whether a newer compiler does the trick, and if > it does, update GUB. Or find a different way of proceeding. > > I'll se

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

ArnoldTheresius writes: > Thomas Morley-2 wrote >> Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup < > >> dak@ > >> >: >> ... >> >> Ok, thanks for the explanation. >> >> Iiuc, this would make this patch superfluous and it should be abandoned. >> As I'm only shepherding it, I'll wait for

GUB fail

David K warned me this morning that my attempt to build 2.19.84 might fail with a compiler error. It did. The error output is: /home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/rational.cc:43:1: internal compiler error: in gen_reg_rtx, at emit

Issue 5733: Fix various type-conversion warnings (issue 559450053 by nine.fierce.ball...@gmail.com)

LGTM https://codereview.appspot.com/559450053/diff/547570044/lily/accidental-placement.cc File lily/accidental-placement.cc (right): https://codereview.appspot.com/559450053/diff/547570044/lily/accidental-placement.cc#newcode62 lily/accidental-placement.cc:62: scm_from_long (stagger ? context_h

Re: Use define-syntax for define-session[-public] (issue 553480044 by hanw...@gmail.com)

On 2020/02/04 08:56:49, hanwenn wrote: > On 2020/02/03 12:11:08, dak wrote: > > > What is wrong with the code I propose in this change? > > > > You mean define-syntax? I'd like to avoid it for now since people have no way > > of getting acquainted with it, and most new developers have never worke

Re: Use define-syntax for define-session[-public] (issue 553480044 by hanw...@gmail.com)

On 2020/02/03 12:11:08, dak wrote: > > What is wrong with the code I propose in this change? > > You mean define-syntax? I'd like to avoid it for now since people have no way > of getting acquainted with it, and most new developers have never worked with > Scheme before. I don't understand this

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

Thomas Morley-2 wrote > Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup < > dak@ > >: > ... > > Ok, thanks for the explanation. > > Iiuc, this would make this patch superfluous and it should be abandoned. > As I'm only shepherding it, I'll wait for Arnold. > For now I'll set the issue t