Mhmm, wouldn't it be better to simply define `M_PI` if it is not
defined? GNU options might not be available with other compilers...
https://codereview.appspot.com/579270051/
> If Werner likes it, I'm fine with it.
I do like it, and it is completely non-intrusive since it gets used
locally only for those people who set up a proper git hook (or call
`clang-format` manually).
https://codereview.appspot.com/561340043/
>> This sounds promising.
>>
>>> -fexcess-precision=standard is not implemented for languages
>>> other than C.
>>
>> Never mind.
>
> Hm. Maybe
>
> -mfpmath=sse
>
> instead? The problem with switching the whole FPU to reduced precision
> is that some library functions
Reviewers: arnold.wendl_siemens.com2,
Message:
This adds Masamichi-san's suggestions from
https://codereview.appspot.com/577450043/
Comment #7
Sorry, for the new issue, initiated by accident
This does _not_ reflect the discussion of
On 2020/01/31 10:45:42, trueroad wrote:
> Hello Arnold.
> Thank you for your patch.
>
> If I understand correctly, we only need check the definitions of
`__x86__` and
> `__i386__` check.
>
> In x86_64 environment, neither `__x86__` nor `__i386__` are defined.
>
> ```
> $ echo |
Hi all,
I wanted to get a better understanding from my impression of the
significant increase in traffic on lilypond-devel.
For this I did some statistics on James' "PATCHES - Countdown"
messages. Since patches are counted multiple times while flowing
through the process I think the only
Am 31.01.2020 um 10:07 schrieb Federico Bruni:
I have a second thought about this.
The whole point of setting a blank root password was that
systemd-nspawn required a root login (at least 2 years ago). In fact
in the README I suggested to log in as root and then change to dev.
But I see that I
Urs Liska writes:
> Am Freitag, den 31.01.2020, 18:38 +0100 schrieb:
>> Urs Liska writes:
>>
>> > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
>> > > On 2020/01/29 12:20:10, mail5 wrote:
>> > > > Unfortunately I haven't set up a build system on my new
>> > > > computer
>> > >
Am 30.01.2020 um 14:17 schrieb fedel...@gmail.com:
https://codereview.appspot.com/561360043/diff/565550050/Documentation/contributor/quick-start.itexi
File Documentation/contributor/quick-start.itexi (right):
Am Freitag, den 31.01.2020, 18:38 +0100 schrieb David Kastrup:
> Urs Liska writes:
>
> > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
> > > On 2020/01/29 12:20:10, mail5 wrote:
> > > > Unfortunately I haven't set up a build system on my new
> > > > computer
> > > > yet,
> > >
LGTM
https://codereview.appspot.com/581560049/
Am Freitag, den 31.01.2020, 22:45 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > I accidentally pushed my branch for issue #5702 (Disable C++
> > exceptions) instead of issue #5690 (Tiny fixes for extractpdfmark).
> > I immediately reset staging and it now
On 31/01/2020 21:45, David Kastrup wrote:
Jonas Hahnfeld writes:
I accidentally pushed my branch for issue #5702 (Disable C++
exceptions) instead of issue #5690 (Tiny fixes for extractpdfmark).
I immediately reset staging and it now has the correct commits, fingers
crossed that patchy did not
Jonas Hahnfeld writes:
> I accidentally pushed my branch for issue #5702 (Disable C++
> exceptions) instead of issue #5690 (Tiny fixes for extractpdfmark).
> I immediately reset staging and it now has the correct commits, fingers
> crossed that patchy did not yet pick up the wrong refs...
>
>
On 31/01/2020 21:02, Jonas Hahnfeld wrote:
I accidentally pushed my branch for issue #5702 (Disable C++
exceptions) instead of issue #5690 (Tiny fixes for extractpdfmark).
I immediately reset staging and it now has the correct commits, fingers
crossed that patchy did not yet pick up the wrong
I accidentally pushed my branch for issue #5702 (Disable C++
exceptions) instead of issue #5690 (Tiny fixes for extractpdfmark).
I immediately reset staging and it now has the correct commits, fingers
crossed that patchy did not yet pick up the wrong refs...
Sorry for any inconvenience this may
https://codereview.appspot.com/579270043/diff/579270044/lily/main.cc
File lily/main.cc (right):
https://codereview.appspot.com/579270043/diff/579270044/lily/main.cc#newcode760
lily/main.cc:760: sane_putenv("GUILE_AUTO_COMPILE", "1", false); //
disable auto-compile
On 2020/01/31 19:43:34,
https://codereview.appspot.com/579270043/diff/579270044/lily/main.cc
File lily/main.cc (right):
https://codereview.appspot.com/579270043/diff/579270044/lily/main.cc#newcode760
lily/main.cc:760: sane_putenv("GUILE_AUTO_COMPILE", "1", false); //
disable auto-compile
Shouldn't the comment be
> Stop using non-const references in function signatures
Carrying the discussion over from [1], I would like to hear a clear
decision that this is the way LilyPond is going to be coded--something
more definite than one person proposing a change and another saying it
looks good. If this is the
On 2020/01/31 18:33:09, hanwenn wrote:
> On 2020/01/31 18:22:47, Dan Eble wrote:
> > On 2020/01/31 17:52:45, hanwenn wrote:
> > > you can do a local alias
> > >
> > > vector<> = *vec;
> > >
> > > to aid readability.
> >
> > The more I think about banning non-const reference parameters, the
On Fri, Jan 31, 2020 at 7:43 PM Dan Eble wrote:
> > Can we have this discussion on a thread separate from this code review?
> > I want this code to go in.
>
> Well, you can't prevent people from replying to their email, but neither can
> their replies prevent you from pushing commits.
Well, I'm
On Jan 31, 2020, at 13:33, hanw...@gmail.com wrote:
>
> On 2020/01/31 18:22:47, Dan Eble wrote:
>> On 2020/01/31 17:52:45, hanwenn wrote:
>>> you can do a local alias
>>>
>>> vector<> = *vec;
>>>
>>> to aid readability.
>>
>> The more I think about banning non-const reference parameters, the
On 2020/01/31 18:06:00, hanwenn wrote:
> Will james pick this up automatically now, or does it need
> an LGTM?
James should pick it up automatically now.
https://codereview.appspot.com/561340043/
On 2020/01/31 18:33:38, Carl wrote:
> IIUC, this is a .clang-format that can be (but is not required to be)
used to
> format source code and prevent comments about formatting.
>
> At this point, we are not enforcing a shift to clang-format as the
code standard
> for LilyPond.
>
> If this is
IIUC, this is a .clang-format that can be (but is not required to be)
used to format source code and prevent comments about formatting.
At this point, we are not enforcing a shift to clang-format as the code
standard for LilyPond.
If this is true, LGTM.
If we are enforcing a shift to
On 2020/01/31 18:22:47, Dan Eble wrote:
> On 2020/01/31 17:52:45, hanwenn wrote:
> > you can do a local alias
> >
> > vector<> = *vec;
> >
> > to aid readability.
>
> The more I think about banning non-const reference parameters, the
more I'm
> against it. Google's coding standards may work
On 2020/01/31 17:52:45, hanwenn wrote:
> you can do a local alias
>
> vector<> = *vec;
>
> to aid readability.
The more I think about banning non-const reference parameters, the more
I'm against it. Google's coding standards may work for them, but their
rationale* for this one is weak. How
On 2020/01/31 12:35:45, Dan Eble wrote:
> On 2020/01/31 09:39:33, hanwenn wrote:
> > I've applied your suggestion; PTAL.
>
> If Werner likes it, I'm fine with it. I haven't tried it myself
because I want
> to avoid being drawn into discussing the details of the style, but I
like seeing
>
On 2020/01/31 18:01:32, hanwenn wrote:
> > The second underscore makes this stand out from the other functions
in this
> > group.
>
> it does. Do you have a suggestion to improve?
ly_scm2utf8string? ly_scm2utf8?
https://codereview.appspot.com/577440043/
On 2020/01/31 12:22:22, Dan Eble wrote:
> On 2020/01/29 06:43:19, hanwenn wrote:
> > score performer
>
> Does this relate to the lexer change, or does it belong on its own?
changed description.
https://codereview.appspot.com/577440044/
On 2020/01/30 15:03:02, Dan Eble wrote:
>
https://codereview.appspot.com/577440043/diff/553450043/lily/include/lily-guile.hh
> File lily/include/lily-guile.hh (right):
>
>
https://codereview.appspot.com/577440043/diff/553450043/lily/include/lily-guile.hh#newcode60
> lily/include/lily-guile.hh:60:
On 2020/01/31 17:38:55, Dan Eble wrote:
> On 2020/01/30 23:22:46, hanwenn wrote:
> > In the lily/ directory
> >
> > git grep 'vector<[^>]\+> &' *c|grep -v const
> >
> > returns 20 results, which is pretty small, given the number of
methods in the
> > code base. A cursory inspection suggests
On 2020/01/30 23:22:46, hanwenn wrote:
> In the lily/ directory
>
> git grep 'vector<[^>]\+> &' *c|grep -v const
>
> returns 20 results, which is pretty small, given the number of methods
in the
> code base. A cursory inspection suggests that Mike introduced most of
these, and
> I would have
Urs Liska writes:
> Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
>> On 2020/01/29 12:20:10, mail5 wrote:
>> > Unfortunately I haven't set up a build system on my new computer
>> > yet,
>> so this
>> > patch is not tested locally at all, so I'm humbly waiting for the
>>
Dan Eble writes:
> On Jan 31, 2020, at 08:31, David Kastrup wrote:
>> -fexcess-precision=style
>> This option allows further control over excess precision on
>> machines where floating-point operations occur in a format
>> with more precision or range than
Masamichi Hosoda writes:
>>> -fexcess-precision=style
>>> This option allows further control over excess precision on
>>> machines where floating-point operations occur in a format
>>> with more precision or range than the IEEE standard and
>>>
>> -fexcess-precision=style
>> This option allows further control over excess precision on
>> machines where floating-point operations occur in a format
>> with more precision or range than the IEEE standard and
>> interchange floating-point types. By
I've now consolidated the various replies to my original suggestions - sorry
it's been so long. Unfortunately I spent far too much time fighting VirtualBox
and Linux without as much success as I'd like. So here are my - fairly small-
documentation ideas. Sorry I couldn't make formal patches but
On Jan 31, 2020, at 08:31, David Kastrup wrote:
> -fexcess-precision=style
> This option allows further control over excess precision on
> machines where floating-point operations occur in a format
> with more precision or range than the IEEE standard and
>
ArnoldTheresius writes:
> trueroad wrote
>> Hello Arnold.
>> Thank you for your patch.
>>
>> If I understand correctly, we only need check the definitions of
>> `__x86__` and `__i386__` check.
>>
>> In x86_64 environment, neither `__x86__` nor `__i386__` are defined.
>>
>> ```
>> $ echo |
On 2020/01/31 09:39:33, hanwenn wrote:
> I've applied your suggestion; PTAL.
If Werner likes it, I'm fine with it. I haven't tried it myself because
I want to avoid being drawn into discussing the details of the style,
but I like seeing movement toward a better process.
trueroad wrote
> Hello Arnold.
> Thank you for your patch.
>
> If I understand correctly, we only need check the definitions of
> `__x86__` and `__i386__` check.
>
> In x86_64 environment, neither `__x86__` nor `__i386__` are defined.
>
> ```
> $ echo | x86_64-w64-mingw32-gcc -dM -E - | grep
On 2020/01/29 06:43:19, hanwenn wrote:
> score performer
Does this relate to the lexer change, or does it belong on its own?
https://codereview.appspot.com/577440044/
ezt írta (időpont: 2020. jan. 31., P, 11:55):
>
>
> https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc
> File lily/parse-scm.cc (right):
>
> https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc#newcode77
> lily/parse-scm.cc:77: const Input *hi =
https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc
File lily/parse-scm.cc (right):
https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc#newcode77
lily/parse-scm.cc:77: const Input *hi = >start_;
On 2020/01/31 10:49:13, benko.pal wrote:
> I understand
https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc
File lily/parse-scm.cc (right):
https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc#newcode77
lily/parse-scm.cc:77: const Input *hi = >start_;
I understand (and like) adding the const, but can't
Hello Arnold.
Thank you for your patch.
If I understand correctly, we only need check the definitions of
`__x86__` and `__i386__` check.
In x86_64 environment, neither `__x86__` nor `__i386__` are defined.
```
$ echo | x86_64-w64-mingw32-gcc -dM -E - | grep "__x86__"
$ echo |
On 2020/01/29 12:19:54, Dan Eble wrote:
> On 2020/01/29 07:41:40, lemzwerg wrote:
> > The output looks good. BTW, for the sake of Emacs, it would be nice
if two
> > spaces after a full dot could be retained in comments. Does such an
option
> > exist?
>
> Retaining everything with
Hello,
Here is the current patch countdown list. The next countdown will be on
February 2nd.
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/ [1]
PUSH:
5704 fixcc.py: change recommended use in --help - David
Il giorno ven 31 gen 2020 alle ore 09:07 Michael Käppler
ha scritto:
> Am 30.01.2020 um 15:08 schrieb Federico Bruni:
> > I see that it's possible to log in as root user without any password
> _even
> > in the virtual machine_. Not good.
> That was my point.
> > I used the --password="" in the
Dan Eble wrote
> On Jan 30, 2020, at 05:17,
> trueroad@
> wrote:
>>
>> How about this patch?
>> Sorry, not tested.
>
> Bringing the _FPU_SETCW() branch and the asm() branch closer together is
> an improvement.
> (I don't have the resources to test this patch.)
Yes,
bringing _FPU_SETCW() and
Am 30.01.2020 um 15:08 schrieb Federico Bruni:
I see that it's possible to log in as root user without any password _even
in the virtual machine_. Not good.
That was my point.
I used the --password="" in the Makefile to avoid the step to set the
password when starting the container with
52 matches
Mail list logo
