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`
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
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
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
> > >
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,
>>
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:
> > > >
> > > >
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
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
> 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
- 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
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
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__
>> $ ~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
> 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
>>
$
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
"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.
>> --
>>
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:
>> > > > > $
>> > > > >
- 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
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.
What problem are we trying to solve here?
https://codereview.appspot.com/575620043/
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?
> 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 nine.fierce.ball...@gmail.com
>> Date: Fri Jan 31 13:48:35 2020
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:
-
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
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
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
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.
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
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
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
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
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
Foreseeable consequences for Python 2.7?
https://codereview.appspot.com/555260044/
Begin forwarded message:
>
> Subject: [testlilyissues:issues] #5719 Tie formatting maintenance
...
> commit 937e413c0f399b2ec44785b7ca29d61cf7b24cff
> Author: Dan Eble nine.fierce.ball...@gmail.com
> Date: Fri Jan 31 13:48:35 2020 -0500
The changes for Issue 5719 remove a header file. If you
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
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
LGTM
https://codereview.appspot.com/549510043/
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
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
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
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
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 to
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 ?
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
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
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?
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
>>> 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.
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
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
> 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
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
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
53 matches
Mail list logo
