LGTM now, thanks!
https://codereview.appspot.com/579270051/
On 2020/02/01 18:55:50, lemzwerg wrote:
> > In `-std=c++11`, most POSIX functions/definitions cannot
> > be used.
> > Also `putenv ()` and `chroot ()` cannot be used.
>
> What about using
>
> AC_USE_SYSTEM_EXTENSIONS
>
> instead (in `configure.in`) to activate many POSIX functionality?
done.
> 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 doc string,
so thanks for the fix!
https://codereview.
On 2020/02/01 21:15:10, hanwenn wrote:
>
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 i
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/include/score-engraver.hh
> > > > File lily/include/sco
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
An interesting DOC string method... defin
On 01/02/2020 21:18, hanw...@gmail.com wrote:
On 2020/02/01 20:55:22, Dan Eble wrote:
On 2020/02/01 20:10:15, hanwenn wrote:
Can I ask that we don't do this on a code review, but in a separate
thread?
Why? The review is where the patch meister (James) looks when he
decides
whether to advan
https://codereview.appspot.com/581580043/diff/561400052/lily/pitch.cc
File lily/pitch.cc (right):
https://codereview.appspot.com/581580043/diff/561400052/lily/pitch.cc#newcode162
lily/pitch.cc:162: if (qt < int (sizeof (accname) / sizeof
(accname[0])))
On 2020/02/01 21:19:46, Dan Eble wrote:
> s
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/include/score-engraver.hh
> > > File lily/include/score-engraver.hh (right):
> > >
> > >
> >
>
https://code
I approve of your use of braces for even single-statement blocks.
https://codereview.appspot.com/581580043/diff/561400052/lily/pitch.cc
File lily/pitch.cc (right):
https://codereview.appspot.com/581580043/diff/561400052/lily/pitch.cc#newcode162
lily/pitch.cc:162: if (qt < int (sizeof (accname) /
On 2020/02/01 20:55:22, Dan Eble wrote:
> On 2020/02/01 20:10:15, hanwenn wrote:
> > Can I ask that we don't do this on a code review, but in a separate
thread?
>
> Why? The review is where the patch meister (James) looks when he
decides
> whether to advance the patch through the countdown. If t
David?
https://codereview.appspot.com/553480044/
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"
On 2020/02/
https://codereview.appspot.com/581580043/diff/557260048/lily/pitch.cc
File lily/pitch.cc (right):
https://codereview.appspot.com/581580043/diff/557260048/lily/pitch.cc#newcode162
lily/pitch.cc:162: if (qt >= 0 && qt < int (sizeof(accname) /
sizeof(const char*))) {
On 2020/02/01 11:19:12, Dan Ebl
LGTM
https://codereview.appspot.com/577440043/
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
On 2020/02/01 11:36:19, hanwenn wrote:
> rebase; rename.
PTAL
https://codereview.appspot.com/577440043/
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#newcode33
lily/include/score-engraver.hh:33: GC_word last_gc_count_;
On 2020/
On 2020/02/01 20:10:15, hanwenn wrote:
> Can I ask that we don't do this on a code review, but in a separate
thread?
Why? The review is where the patch meister (James) looks when he
decides whether to advance the patch through the countdown. If there
were no activity here, he might advance the p
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/01/31 19:30:48, Dan Eble wrote:
> > Stop using non-const references in function signatures
>
> Carrying the discussion over from [1], I would like to hear a clear
decision
Can I ask that we don't do this on a code review, but in a separate
thread?
https://codereview.appspot.com/5774400
On Sat, Jan 11, 2020 at 11:22 PM Carl Sorensen wrote:
>
>
> On 1/11/20, 8:48 PM, "lilypond-devel on behalf of Kieren MacMillan"
> kieren_macmil...@sympatico.ca> wrote:
>
> Hi Marnen,
>
> > New version is now available at
> >
> https://bintray.com/marnen/lilypond-darwin-64/download_f
LGTM
https://codereview.appspot.com/557270049/
LGTM
https://codereview.appspot.com/553490051/
> In `-std=c++11`, most POSIX functions/definitions cannot
> be used.
> Also `putenv ()` and `chroot ()` cannot be used.
What about using
AC_USE_SYSTEM_EXTENSIONS
instead (in `configure.in`) to activate many POSIX functionality?
https://codereview.appspot.com/579270051/
Very nice, thanks! LGTM
https://codereview.appspot.com/575600044/
On 2020/02/01 12:06:02, Dan Eble wrote:
> I see two uses of strdup.
> The one in piano-pedal-engraver looks like it could be eliminated by
using
> std::string instead of a C string.
See https://codereview.appspot.com/557270049/ .
It seems worthwhile independent of the gnu++11 question.
https://co
On Sat, Jan 11, 2020 at 6:05 PM Stanton Sanderson
wrote:
> > On Jan 11, 2020, at 3:29 PM, lilypond-devel-requ...@gnu.org wrote:
> >
> > New version is now available at
> >
> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
> >
Am Samstag, den 01.02.2020, 12:10 -0500 schrieb Dan Eble:
> On Feb 1, 2020, at 11:26, Jonas Hahnfeld <
> hah...@hahnjo.de
> > wrote:
> > +# disable Python's hash randomization until 'make check' is fixed
> > +PYTHONHASHSEED=0
> > +export PYTHONHASHSEED
>
> Looks good, works fine.
Now in staging.
LGTM
(didn't look very closely though)
https://codereview.appspot.com/555220043/diff/553480046/scripts/lilypond-book.py
File scripts/lilypond-book.py (left):
https://codereview.appspot.com/555220043/diff/553480046/scripts/lilypond-book.py#oldcode426
scripts/lilypond-book.py:426: return hash ('
On Feb 1, 2020, at 11:26, Jonas Hahnfeld wrote:
>
> +# disable Python's hash randomization until 'make check' is fixed
> +PYTHONHASHSEED=0
> +export PYTHONHASHSEED
Looks good, works fine.
—
Dan
On 2020/02/01 15:04:41, trueroad wrote:
> In `-std=c++11`, most POSIX functions/definitions cannot be used.
> Also `putenv ()` and `chroot ()` cannot be used.
But is it the case that the implementations of those functions requires
GNU C++ extensions, or is it the case that their header files are n
LGTM, but I'm no guru.
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#newcode432
scripts/lilypond-book.py:432: snippet_names_file = 'snippet-n
pkx1...@poste.net writes:
> OK this explains that last couple of patch tests.
>
> e.g. - https://cloud-u8zj2dc4b.yourownnet.eu/s/p7SJnLKpswT2E5W
>
> All I guess I am concerned with is knowing if these 'cell count
> thingies' matter or not if I am going to get them all the time now.
>
> I don't wan
On 01/02/2020 15:15, Jonas Hahnfeld wrote:
Am Samstag, den 01.02.2020, 09:55 -0500 schrieb Dan Eble:
I've noticed a subjective increase in profiling differences in regtests since
updating to the latest master this morning
(bc8a3fa7e4f12bf5ac1eb0293bfab658d52c4ae8), even from one run to another
On 01/02/2020 16:17, Dan Eble wrote:
On Feb 1, 2020, at 10:15, Jonas Hahnfeld wrote:
How distracting are the profiling differences for your work? I'm
obviously not a big fan of reverting bc8a3fa7e4, but I also don't want
to block anybody else from making progress.
The log differences are more
Am Samstag, den 01.02.2020, 11:17 -0500 schrieb Dan Eble:
> On Feb 1, 2020, at 10:15, Jonas Hahnfeld <
> hah...@hahnjo.de
> > wrote:
> > How distracting are the profiling differences for your work? I'm
> > obviously not a big fan of reverting bc8a3fa7e4, but I also don't want
> > to block anybody e
On Feb 1, 2020, at 10:15, Jonas Hahnfeld wrote:
> How distracting are the profiling differences for your work? I'm
> obviously not a big fan of reverting bc8a3fa7e4, but I also don't want
> to block anybody else from making progress.
The log differences are more annoying than the profile differen
On Feb 1, 2020, at 09:59, David Kastrup wrote:
>
> even with a reference parameter. Of course this does not "really" give
> an indication about this being in-out, but neither does &variant.
That's an important point. What indicates that a parameter is _not_ an
out-parameter is "const". You m
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 our Windows executables just
>> >> moved to 64bit but that seems like the more
Am Samstag, den 01.02.2020, 09:55 -0500 schrieb Dan Eble:
> I've noticed a subjective increase in profiling differences in regtests since
> updating to the latest master this morning
> (bc8a3fa7e4f12bf5ac1eb0293bfab658d52c4ae8), even from one run to another on
> unchanged code.
>
> There are al
In `-std=c++11`, most POSIX functions/definitions cannot be used.
Also `putenv ()` and `chroot ()` cannot be used.
These missing raises error in compiling LilyPond.
We can define `M_PI` if there is no `M_PI` definition.
We can implement `strdup ()` alternative by using only strict C++11
standard f
nine.fierce.ball...@gmail.com writes:
> Consider this function from lily/tie-formatting-problem.cc:
>
> void
> Tie_formatting_problem::score_ties (Ties_configuration *ties) const
> {
> if (ties->scored_)
> return;
>
> score_ties_configuration (ties);
> sc
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 our Windows executables just
> >> moved to 64bit but that seems like the more complicated option yet. And
> >>
I've noticed a subjective increase in profiling differences in regtests since
updating to the latest master this morning
(bc8a3fa7e4f12bf5ac1eb0293bfab658d52c4ae8), even from one run to another on
unchanged code.
There are also log differences that might be correlated, with some test cases
hav
Masamichi Hosoda writes:
You provided a lot of good information in your post, but the
conclusion was not entirely clear.
Are you suggesting requiring SSE2 at this time?
>>>
>>> Yes. It appears to get used anyway for 64bit executables, and it seems
>>> safe enough to demand it for
Hi David,
Am Samstag, den 01.02.2020, 14:52 +0100 schrieb David Kastrup:
> I have mostly followed Jonas' proposals. Rebasing his stable-2.20
> branch on the current state delivers the following rather small difference:
>
> commit 26e346a54a4706d973cc5ad9eb2354364550a1d9 (HEAD)
> Author: Werner L
>>> You provided a lot of good information in your post, but the
>>> conclusion was not entirely clear.
>>> Are you suggesting requiring SSE2 at this time?
>>
>> Yes. It appears to get used anyway for 64bit executables, and it seems
>> safe enough to demand it for 32bit executables.
>
> +1
> far
Consider this function from lily/tie-formatting-problem.cc:
void
Tie_formatting_problem::score_ties (Ties_configuration *ties) const
{
if (ties->scored_)
return;
score_ties_configuration (ties);
score_ties_aptitude (ties);
ties->scored_ = true;
I have mostly followed Jonas' proposals. Rebasing his stable-2.20
branch on the current state delivers the following rather small difference:
commit 26e346a54a4706d973cc5ad9eb2354364550a1d9 (HEAD)
Author: Werner Lemberg
Date: Wed Oct 9 12:35:10 2019 +0200
granados.ly: Improved and updat
On 2020/01/29 06:43:19, hanwenn wrote:
> score performer
removed unused: looks good.
changing references to pointers: looks BD.
https://codereview.appspot.com/577440044/
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 1:04 PM David Kastrup wrote:
>> >> Of course these are no scientifically hardened results - but they match
>> >> the feeling of excited frenzy visible on this list. However sustainable
>> >> the effect may be, the short term impact of the develop
On Sat, Feb 1, 2020 at 1:04 PM David Kastrup wrote:
> >> Of course these are no scientifically hardened results - but they match
> >> the feeling of excited frenzy visible on this list. However sustainable
> >> the effect may be, the short term impact of the developer meeting and
> >> the conferen
On 2020/02/01 12:06:02, Dan Eble wrote:
> I see two uses of strdup.
> The one in piano-pedal-engraver looks like it could be eliminated by
using
> std::string instead of a C string.
> The one in relocate.cc looks like it could be replaced by
strlen+malloc+strncpy.
I can work on a patch for these.
On Feb 1, 2020, at 06:39, David Kastrup wrote:
>
>> You provided a lot of good information in your post, but the
>> conclusion was not entirely clear.
>> Are you suggesting requiring SSE2 at this time?
>
> Yes. It appears to get used anyway for 64bit executables, and it seems
> safe enough to d
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 12:59 AM Urs Liska wrote:
>>
>> 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.
On 2020/02/01 08:04:36, trueroad wrote:
> Even if we define `M_PI`, an error raises since there is no `strdup
()`.
I see two uses of strdup.
The one in piano-pedal-engraver looks like it could be eliminated by
using std::string instead of a C string.
The one in relocate.cc looks like it could be r
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 12:59 AM Urs Liska wrote:
>>
>> 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.
Reviewers: ,
Message:
If we want to retain this functionality, I will implement this via
importlib.util.spec_from_file_location() +
importlib.util.module_from_spec(). But I would like to keep complexity
to a minimum, hence remove unused functionality.
Description:
lilypond-book: Remove custom pac
On Sat, Feb 1, 2020 at 12:59 AM Urs Liska wrote:
>
> 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 t
Preliminary reaction: I don't like it. This might be a case of missing
includes which are implicitly included in one case and not in another.
https://codereview.appspot.com/579270051/
Dan Eble writes:
> On Feb 1, 2020, at 05:05, David Kastrup wrote:
>>
>> Frankly, I think that it would be better if our Windows executables just
>> moved to 64bit but that seems like the more complicated option yet. And
>> 32bit systems kept around a whole lot longer even after processors
>> be
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 11:11 AM David Kastrup wrote:
>> >> Here is an example that shows better how things work, and what might
>> >> be the cause of my problems. Is it right that programmatically set
>> >> contents of "current-module" are not serialized into the compi
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-engraver.hh:26: #include
On 2020/02/01 11:00:40
On Feb 1, 2020, at 05:05, David Kastrup wrote:
>
> Frankly, I think that it would be better if our Windows executables just
> moved to 64bit but that seems like the more complicated option yet. And
> 32bit systems kept around a whole lot longer even after processors
> became 64bit-capable because
On Sat, Feb 1, 2020 at 11:11 AM David Kastrup wrote:
> >> Here is an example that shows better how things work, and what might
> >> be the cause of my problems. Is it right that programmatically set
> >> contents of "current-module" are not serialized into the compiled
> >> file?
> >>
> >>(def
https://codereview.appspot.com/581580043/diff/557260048/lily/pitch.cc
File lily/pitch.cc (right):
https://codereview.appspot.com/581580043/diff/557260048/lily/pitch.cc#newcode162
lily/pitch.cc:162: if (qt >= 0 && qt < int (sizeof(accname) /
sizeof(const char*))) {
Instead of casting to int and c
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-engraver.hh:26: #include
This effectively adds
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#newcode33
lily/include/score-engraver.hh:33: GC_word last_gc_count_;
FYI: Bec
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://codereview.appspot.com/572600048/diff/548660043
Han-Wen Nienhuys writes:
> +lilypond-devel for visibility.
>
> On Sat, Feb 1, 2020 at 10:54 AM Han-Wen Nienhuys wrote:
>>
>> Here is an example that shows better how things work, and what might
>> be the cause of my problems. Is it right that programmatically set
>> contents of "current-module"
Masamichi Hosoda 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 negative performance?
>> I ju
+lilypond-devel for visibility.
On Sat, Feb 1, 2020 at 10:54 AM Han-Wen Nienhuys wrote:
>
> Here is an example that shows better how things work, and what might
> be the cause of my problems. Is it right that programmatically set
> contents of "current-module" are not serialized into the compiled
Reviewers: lemzwerg,
Message:
On 2020/02/01 07:10:17, lemzwerg wrote:
> 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...
`-std=c++11` cannot use not only `M_PI` but also POSIX functions such as
`strdup ()`.
Eve
74 matches
Mail list logo
