LGTM
https://codereview.appspot.com/565560043/
https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc
File lily/main.cc (right):
https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc#newcode174
lily/main.cc:174: /* x86 defaults to using 80-bit extended precision
arithmetic. This can cause
On 2020/01/29 23:54:27,
Reviewers: ,
Description:
https://sourceforge.net/p/testlilyissues/issues/5712/
... into context_create and context_find_or_create. This trades the
obscurity of a boolean constant for the clarity of specific names.
Please review this at https://codereview.appspot.com/565560043/
Affected files
https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc
File lily/main.cc (right):
https://codereview.appspot.com/577450043/diff/579260043/lily/main.cc#newcode174
lily/main.cc:174: /* x86 defaults to using 80-bit extended precision
arithmetic. This can cause
I missed this comment
On 2020/01/29 22:36:03, Carl wrote:
> While this answer is specific, it could be clearer, IMO:
>
> Reviewing the Intel Manuals at
>
https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf
> Section 4.2.2.
>
> We can see that the 64 bit significand of Double Extended
https://codereview.appspot.com/572600048/diff/548660043/Documentation/snippets/new/non-traditional-key-signatures.ly
File Documentation/snippets/new/non-traditional-key-signatures.ly
(right):
While this answer is specific, it could be clearer, IMO:
Reviewing the Intel Manuals at
https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf
Section 4.2.2.
We can see that the 64 bit significand of Double Extended Precision
refers to an 80-bit floating point
The comment could be more helpful. Explaining what this code does is
more important than explaining that it replaces something that no longer
exists.
I've found this documentation on the x87 FPU Control Word:
http://home.agh.edu.pl/~amrozek/x87.pdf
Section 8.1.4.
It looks like the value 0x027f
Reviewers: ,
Description:
Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries
Issue 4943
As Issue 4943 on Windows compilation was triggered by
missing _FPU_SETCW() in the MINGW libraries, an alternate call to
initiate the X87 FPU setup as an inline-assembler command is added
-
Am Mi., 29. Jan. 2020 um 16:41 Uhr schrieb Dan Eble :
>
>
>
> > On Jan 29, 2020, at 10:17, Masamichi Hosoda wrote:
> >
> >> I ask because, in the german forum Arnold found a method to cure some
> >> windows-only bugs., about mis-predicted force and probably several
> >> assertion-failures:
> >>
Am Mi., 29. Jan. 2020 um 16:17 Uhr schrieb Masamichi Hosoda
:
>
> > I ask because, in the german forum Arnold found a method to cure some
> > windows-only bugs., about mis-predicted force and probably several
> > assertion-failures:
> >
Am Mi., 29. Jan. 2020 um 13:21 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi all,
> >
> > iirc in Salzburg there was the plan to do a 2.19.84-release, soon
> > followed by stable 2.20
> > May I ask how's the state of 2.19.84?
>
> I just got news from Phil (who had been offline
https://codereview.appspot.com/579250043/
> On Jan 29, 2020, at 10:17, Masamichi Hosoda wrote:
>
>> I ask because, in the german forum Arnold found a method to cure some
>> windows-only bugs., about mis-predicted force and probably several
>> assertion-failures:
>> https://lilypondforum.de/index.php/topic,609.msg3463.html#msg3463
>
LGTM
Just two thoughts:
1. I'm not sure why you suggest how to set the root password, as the dev
user can get admin privileges via sudo.
2. While keyboard configuration is a step needed for any non-US
contributor, reconfiguring the locales should be useful only for
translators, unless I miss
> I ask because, in the german forum Arnold found a method to cure some
> windows-only bugs., about mis-predicted force and probably several
> assertion-failures:
> https://lilypondforum.de/index.php/topic,609.msg3463.html#msg3463
The patch is very interesting.
I've tried x87mant53.dll showed in
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
> > tests to succeed or
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
> tests to succeed or fail ...
I don't like the "use-modules clauses adjusted accordingly". I don't
Reviewers: ,
Message:
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 tests to succeed or fail ...
Description:
Move Guile-style modules from scm to scm-modules
As an initial step towards a
https://codereview.appspot.com/577410045/diff/551410043/lily/parse-scm.cc
File lily/parse-scm.cc (right):
https://codereview.appspot.com/577410045/diff/551410043/lily/parse-scm.cc#newcode59
lily/parse-scm.cc:59:
Pouring oil on the fire... Rietveld highlighting indicates non-empty
lines
Thomas Morley writes:
> Hi all,
>
> iirc in Salzburg there was the plan to do a 2.19.84-release, soon
> followed by stable 2.20
> May I ask how's the state of 2.19.84?
I just got news from Phil (who had been offline for a while) and he
plans to set to it this weekend, time allowing.
> I ask
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:false might be the only way.
LGTM.
Excuse my Phone spellcheck
From: lilypond-devel on
behalf of hanw...@gmail.com
Sent: Tuesday, January 28, 2020 10:59:08 PM
To: lemzw...@googlemail.com ;
nine.fierce.ball...@gmail.com ;
rietveld...@tutanota.com
Cc: re...@codereview-hr.appspotmail.com ;
On 2020/01/29 06:06:15, dak wrote:
> Oh, I am sorry to have been misleading with my comment
forgiven
https://codereview.appspot.com/563430046/
On 2020/01/29 10:24:12, lemzwerg wrote:
>
> Is there ever a reason for the user to change the value?
Say, to speed up testing?
https://codereview.appspot.com/547540043/
On 2020/01/29 06:36:07, hanwenn wrote:
>
> BTW - I don't want to tell a C++ expert how to use the language in
general. If
> we were in an alternate reality where we could start from scratch we
could
> reconsider the decision to not use non-const references in structs and
function
> arguments.
Hi all,
iirc in Salzburg there was the plan to do a 2.19.84-release, soon
followed by stable 2.20
May I ask how's the state of 2.19.84?
I ask because, in the german forum Arnold found a method to cure some
windows-only bugs., about mis-predicted force and probably several
assertion-failures:
LGTM
https://codereview.appspot.com/547540043/diff/561380043/lily/main.cc
File lily/main.cc (right):
https://codereview.appspot.com/547540043/diff/561380043/lily/main.cc#newcode772
lily/main.cc:772: sane_putenv("GC_INITIAL_HEAP_SIZE", "40M", false);
Do you think it makes sense to mention this
One final question before I start working on some package code
proposal:
All the basic Scheme files are loaded in lily.scm with
(for-each ly:load init-scheme-files)
What does this do internally? I.e. how is the visibility handled of
definitions/bindings from names in files loaded with ly:load
On Sat, Jan 25, 2020 at 1:47 PM Han-Wen Nienhuys wrote:
> 7.2 seconds end-to-end includes 1.7s of GC, and 2.0s of reading/compiling SCM.
>
> On guile 1.8, with GS disabled, the end to end runtime is
>
> 3.568s including 0.33s for GC and 0.32s for reading the SCM.
>
> These timings are internally
30 matches
Mail list logo
