David Kastrup wrote
> Dan Eble <
> dan@
> > writes:
>
> ...
> Hm. Maybe
>
> -mfpmath=sse
>
> instead? The problem with switching the whole FPU to reduced precision
> is that some library functions might not expect that, so it is making me
> queasy. On the other hand, using SSE might have a
David Kastrup wrote
> ArnoldTheresius <
> Arnold.Wendl@
> > writes:
>
> ...
> None of the following GCC options would help?
> ...
>-ffloat-store
> ...
>-fexcess-precision=style
> ...
>-ffast-math
> ...
> --
> David Kastrup
Only -ffloat-store did show the desired effect
On 02/02/2020 22:33, Han-Wen Nienhuys wrote:
For me, juggling 15 different outstanding code reviews at the same
time is the bane of the current development process.
what do you suggest?
James
For testing, use
https://github.com/hanwen/lilypond/tree/guile22-experiment
in particular, you need
https://github.com/hanwen/lilypond/commit/b696550379831ecec1519be6d59cd8a3003e5329
for the UTF-8 parsing. I fixed this a week ago, but due to the delays
in getting the preceding fix in ("cleanup
jonas.hahnf...@gmail.com writes:
> I just tried to reproduce the timings for commits already in master and
> this patch. To be honest I don't see a clear picture yet.
>
> Yes, this change seems to improve the time spent for garbage collection,
> but the real time reported by "time" only decreases
I just tried to reproduce the timings for commits already in master and
this patch. To be honest I don't see a clear picture yet.
Yes, this change seems to improve the time spent for garbage collection,
but the real time reported by "time" only decreases by a fraction (less
than 50% of the saved t
On Sun, Feb 2, 2020 at 4:28 PM wrote:
> > Please see Taylan's reply to the guile-devel list, which gives a
> succinct
> > explanation of why inner functions in macros can never work in the
> Guile 2.x
> > compiler. So we either forego compilation (at a 1.5 sec startup cost)
> or we
> > rewrite th
Reviewers: Dan Eble, dak,
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc
File lily/spring.cc (right):
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119
lily/spring.cc:119: avg_stretch /= static_cast (springs.size ());
On 2020/02/02 18:51:08
On 2020/02/02 15:17:04, hanwenn wrote:
> *say
Yep, LGTM.
https://codereview.appspot.com/581570043/
On 2020/02/02 18:51:08, Dan Eble wrote:
> LGTM
>
> https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc
> File lily/spring.cc (right):
>
>
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119
> lily/spring.cc:119: avg_stretch /= static_cast (springs.
LGTM
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc
File lily/spring.cc (right):
https://codereview.appspot.com/547560044/diff/555240043/lily/spring.cc#newcode119
lily/spring.cc:119: avg_stretch /= static_cast (springs.size ());
This is not an issue with this change, but
LGTM
https://codereview.appspot.com/563460043/diff/557300058/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):
https://codereview.appspot.com/563460043/diff/557300058/lily/page-layout-problem.cc#newcode739
lily/page-layout-problem.cc:739: = overflow / static_cast
(space_count
On 2020/02/02 15:33:05, hahnjo wrote:
> > > I'd probably have chosen txt.
> >
> > Ok, will do.
>
> Meh: I did the change and it works, but subprocess_system in
python/lilylib.py
> will still output the .ly name. As this file doesn't exist anymore, it
will just
> make investigations in case of an
nine.fierce.ball...@gmail.com writes:
>> 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 an
pkx1...@posteo.net writes:
> Hello,
>
> On 29/01/2020 22:47, d...@gnu.org wrote:
>> 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):
>>
>> https://co
Reviewers: dak,
Message:
On 2020/02/02 15:44:48, dak wrote:
> > However as far as I understand the MusicXML specification, a
> must always have either a , or , or .
>
> Wouldn't percussion notes generally be "unpitched"? What happens for
such
> notes?
Yes, they are in valid MusicXML. This is h
> However as far as I understand the MusicXML specification, a
must always have either a , or , or .
Wouldn't percussion notes generally be "unpitched"? What happens for
such notes?
https://codereview.appspot.com/559440043/
On 2020/02/02 13:26:04, hahnjo wrote:
> On 2020/02/02 13:21:58, Dan Eble wrote:
> > On 2020/02/02 09:52:37, hahnjo wrote:
> > >
> >
>
https://codereview.appspot.com/555220043/diff/553480046/scripts/lilypond-book.py#newcode432
> > > scripts/lilypond-book.py:432: snippet_names_file =
'snippet-names-%
On 2020/02/02 14:01:33, hanwenn wrote:
> https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm
> File scm/lily.scm (right):
>
>
https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm#newcode111
> scm/lily.scm:111: "This defines a variable @var{name} with the
starting v
*say
https://codereview.appspot.com/581570043/
On 2020/02/01 22:35:38, lemzwerg wrote:
> > you need to read the comment at the top of the file too..
>
> Well, ...
>
> > I think this function should not have been pulbic,
> > and suspect it is only so some of the macros can work.
>
> ... even a non-public function should have an understandable
On 2020/02/02 14:41:51, dan_faithful.be wrote:
> On Feb 2, 2020, at 09:15, mailto:hanw...@gmail.com wrote:
> >
> >> I don't like this methodology, what's the difference over disabling
> >> -Wconversion
> >
> > My selfish is reason is that it gets the warnings out of the way of
> > whomever is not
On Feb 2, 2020, at 09:15, hanw...@gmail.com wrote:
>
>> I don't like this methodology, what's the difference over disabling
>> -Wconversion
>
> My selfish is reason is that it gets the warnings out of the way of
> whomever is not interested in fixing casts, including myself.
About 1/3 of the rem
> I don't like this methodology, what's the difference over disabling
> -Wconversion
My selfish is reason is that it gets the warnings out of the way of
whomever is not interested in fixing casts, including myself.
The reason why this methodology is better approach overall is that it
actually p
https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm
File scm/lily.scm (right):
https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm#newcode111
scm/lily.scm:111: "This defines a variable @var{name} with the starting
value
On 2020/02/01 21:37:50, dak wrote:
> An in
On 2020/02/02 13:45:34, hahnjo wrote:
> On 2020/02/02 13:43:25, hanwenn wrote:
> > jonas' comments
>
> The uploaded diff has the wrong base, it's reverting quite some
changes from
> master.
I hate Rietveld.
Fixed.
https://codereview.appspot.com/561390043/
LGTM
https://codereview.appspot.com/551430044/
On 2020/02/02 13:43:25, hanwenn wrote:
> jonas' comments
The uploaded diff has the wrong base, it's reverting quite some changes
from master.
https://codereview.appspot.com/561390043/
https://codereview.appspot.com/561390043/diff/565600046/configure.ac
File configure.ac (right):
https://codereview.appspot.com/561390043/diff/565600046/configure.ac#newcode270
configure.ac:270: PKG_CHECK_MODULES(BDWGC, bdw-gc)
On 2020/02/02 13:21:09, hahnjo wrote:
> This should fail if not found
LGTM
We probably have quite a number of those leftovers that are completely
irrelevant by now. I almost lean towards stipulating that any code for
pre-Guile-1.8.8 can be removed directly without review, but then if
something does go wrong by accident, we at least have a bit of a trace
to see what
On 2020/02/02 13:21:58, Dan Eble wrote:
> On 2020/02/02 09:52:37, hahnjo wrote:
> >
>
https://codereview.appspot.com/555220043/diff/553480046/scripts/lilypond-book.py#newcode432
> > scripts/lilypond-book.py:432: snippet_names_file =
'snippet-names-%s.ly' %
> > checksum
> > On 2020/02/01 16:54:40, D
On 2020/02/02 09:52:37, hahnjo wrote:
>
https://codereview.appspot.com/555220043/diff/553480046/scripts/lilypond-book.py#newcode432
> scripts/lilypond-book.py:432: snippet_names_file =
'snippet-names-%s.ly' %
> checksum
> On 2020/02/01 16:54:40, Dan Eble wrote:
> > It's strange that this is named *
https://codereview.appspot.com/561390043/diff/565600046/configure.ac
File configure.ac (right):
https://codereview.appspot.com/561390043/diff/565600046/configure.ac#newcode270
configure.ac:270: PKG_CHECK_MODULES(BDWGC, bdw-gc)
This should fail if not found, you're using it unconditionally
https
On 2020/02/01 11:00:41, hahnjo wrote:
>
https://codereview.appspot.com/561390043/diff/557260051/lily/include/score-engraver.hh
> File lily/include/score-engraver.hh (right):
>
>
https://codereview.appspot.com/561390043/diff/557260051/lily/include/score-engraver.hh#newcode26
> lily/include/score-en
On 2020/02/01 21:59:14, dak wrote:
> On 2020/02/01 21:23:51, hanwenn wrote:
> > On 2020/02/01 20:59:06, dak wrote:
> > > On 2020/02/01 20:49:09, hanwenn wrote:
> > > > On 2020/02/01 11:00:41, hahnjo wrote:
> > > > >
> > > >
> > >
> >
>
https://codereview.appspot.com/561390043/diff/557260051/lily/in
On 2020/02/02 09:49:50, hahnjo wrote:
> On 2020/02/01 20:49:09, hanwenn wrote:
> > On 2020/02/01 11:00:41, hahnjo wrote:
> > >
> >
>
https://codereview.appspot.com/561390043/diff/557260051/lily/include/score-engraver.hh
> > > File lily/include/score-engraver.hh (right):
> > >
> > >
> >
>
https://c
Am Sa., 1. Feb. 2020 um 16:49 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Am Sa., 1. Feb. 2020 um 12:39 Uhr schrieb David Kastrup :
> >>
> >> Dan Eble writes:
> >>
> >> > On Feb 1, 2020, at 05:05, David Kastrup wrote:
> >> >>
> >> >> Frankly, I think that it would be better if ou
> Nothing? I am currently proposing that we compile with
>
> -mfpmath=sse -msse2
>
> as options which should shift arithmetic off to the SSE2 instruction set
> which doesn't work with 80-bit arithmetic. That would be a default way
> of compilation.
I've created a patch for master.
https://sou
https://codereview.appspot.com/555220043/diff/553480046/scripts/lilypond-book.py
File scripts/lilypond-book.py (right):
https://codereview.appspot.com/555220043/diff/553480046/scripts/lilypond-book.py#newcode409
scripts/lilypond-book.py:409: checksum = hashlib.md5 ()
On 2020/02/01 17:13:02, hanw
On 2020/02/01 20:49:09, hanwenn wrote:
> On 2020/02/01 11:00:41, hahnjo wrote:
> >
>
https://codereview.appspot.com/561390043/diff/557260051/lily/include/score-engraver.hh
> > File lily/include/score-engraver.hh (right):
> >
> >
>
https://codereview.appspot.com/561390043/diff/557260051/lily/includ
Hello,
Here is the current patch countdown list. The next countdown will be on
February 4th.
A quick synopsis of all patches currently in the review process can be
found here:
http://philholmes.net/lilypond/allura/
***
Push:
5710 GUILE 2: Increase initial heap - Han-Wen Nienhuys
h
41 matches
Mail list logo
