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 systemd
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
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 Ma
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 K
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 ReflowComments:
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 | x86_64-w64-mingw32
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 = &ps->start_;
I understand (and like) adding the const, but can't u
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 = &ps->start_;
On 2020/01/31 10:49:13, benko.pal wrote:
> I understa
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 = &ps->sta
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/
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/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.
https://codereview.appsp
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 | x86_
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
>
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
>> -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
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
>>> interc
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 the
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
>> automated
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 pro
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 that
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 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/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: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
> movement
On 2020/01/31 17:52:45, hanwenn wrote:
> you can do a local alias
>
> vector<> &v = *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. Ho
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<> &v = *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 wor
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 clang-forma
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 true,
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 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<> &v = *vec;
>>>
>>> to aid readability.
>>
>> The more I think about banning non-const reference parameters, th
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 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<> &v = *vec;
> > >
> > > to aid readability.
> >
> > The more I think about banning non-const reference parameters, the
> 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 way
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 chang
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, thomas
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 ca
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 ref
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...
>
> Sor
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
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 has
LGTM
https://codereview.appspot.com/581560049/
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,
> > > so
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):
https://codereview.appspot.com/561360043/diff/565550050/Documentation/contributor/quick
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 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
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 relevant
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 | x86_64-w64-mingw3
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
https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg008
>> 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 might
LGTM
https://codereview.appspot.com/561390043/diff/563450046/lily/score-engraver.cc
File lily/score-engraver.cc (right):
https://codereview.appspot.com/561390043/diff/563450046/lily/score-engraver.cc#newcode200
lily/score-engraver.cc:200: // This double the heap. TODO: don't do this
if we get cl
LGTM
https://codereview.appspot.com/581580043/
Some nits.
https://codereview.appspot.com/581570043/diff/563450043/scm/markup-macros.scm
File scm/markup-macros.scm (right):
https://codereview.appspot.com/581570043/diff/563450043/scm/markup-macros.scm#newcode419
scm/markup-macros.scm:419: "Lookup procedure in the current module, or
return #f"
> 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/
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/
55 matches
Mail list logo
