LGTM
https://codereview.appspot.com/571980043/diff/581920043/lily/skyline.cc
File lily/skyline.cc (right):
https://codereview.appspot.com/571980043/diff/581920043/lily/skyline.cc#newcode164
lily/skyline.cc:164: if (ret >= x_[LEFT] && ret <= x_[RIGHT] &&
!std::isinf (ret))
Is this x_.contains
I am in favour of Gitlab.
I'm not a developer. Sometimes I contributed doc or website fixes.
My (main) work of translator won't be affected at all by this decision.
What I care most is the replacement of Sourceforge with something
better.
If choosing Gerrit means keeping Sourceforge, I would
https://codereview.appspot.com/571980043/diff/579590043/lily/skyline.cc
File lily/skyline.cc (right):
https://codereview.appspot.com/571980043/diff/579590043/lily/skyline.cc#newcode100
lily/skyline.cc:100: x_[START] = start;
On 2020/04/16 20:50:20, Dan Eble wrote:
> Initialize x_ in a member
The idea makes sense to me. I haven't reviewed the whole change.
https://codereview.appspot.com/571980043/diff/579590043/lily/skyline.cc
File lily/skyline.cc (right):
https://codereview.appspot.com/571980043/diff/579590043/lily/skyline.cc#newcode100
lily/skyline.cc:100: x_[START] = start;
This a cleanup. Most of lily tries to use Offset/Interval rather than
enumerating the Real numbers that form the interval/offset.
https://codereview.appspot.com/571980043/diff/579590043/lily/include/skyline.hh
File lily/include/skyline.hh (right):
Purpose is not clear since the code does not appear to use anything
other than the explicit endpoints.
Also, intervals are indexed by LEFT/RIGHT rather than START/STOP.
Values may be the same, but the former is a whole lot more mnemonic.
https://codereview.appspot.com/571980043/
Is there a reason Interval is better? Please add a description
https://codereview.appspot.com/571980043/diff/579590043/lily/include/skyline.hh
File lily/include/skyline.hh (right):
https://codereview.appspot.com/571980043/diff/579590043/lily/include/skyline.hh#newcode36
On Thu, Apr 16, 2020 at 7:16 AM Werner LEMBERG wrote:
>
>
> > I did some better structured measurements, with interleaved runs on
> > MSDM: [...]
>
> Have you ever tried valgrind's `callgrind` tool for profiling (and
> using `kcachegrind` for displaying the results)? While very slow it
> would
On Wed, Apr 15, 2020 at 9:15 PM Jonas Hahnfeld wrote:
> With 2.21.0 done, I'd like to restart discussion about switching our
> development platform. To recall, we had proposals about using Gerrit
> [1] (don't miss follow-ups in March [2]) and GitLab / gitlab.com [3].
>
> Simultaneously the FSF
LGTM
https://codereview.appspot.com/581910043/
Am Donnerstag, den 16.04.2020, 13:43 +0200 schrieb Jean-Charles
Malahieude:
> Hi,
>
> Wishing to merge back translation into master, I first want to have
> everything fine but, with HEAD at
>
> 2f4b432c66 framework-svg.scm: Fix 'style' tag
>
> and nothing wrong with autogen, I get
>
> make
> What would fit our use case in GitLab + CI pretty nicely are Merge
> Trains [1].
Interesting, and very nice! This looks like a very useful feature
indeed.
> Basically this has the potential to replace our current setup of
> patchy-staging: Once a patch counted down, we press "Start merge
>
Am Donnerstag, den 16.04.2020, 10:44 +0200 schrieb Werner LEMBERG:
> > To conclude, I believe we should choose one of Gerrit and GitLab and
> > have a trial to see if the processes can be carried over.
>
> I'm fine with both. If in doubt please select the one that is easier
> to manage, and
>> Have you ever tried valgrind's `callgrind` tool for profiling (and
>> using `kcachegrind` for displaying the results)? While very slow
>> it would avoid temperature issues and the like – no need to call it
>> multiple times to get reliable values.
>
> What magic does callgrind do to prevent
Hi,
Wishing to merge back translation into master, I first want to have
everything fine but, with HEAD at
2f4b432c66 framework-svg.scm: Fix 'style' tag
and nothing wrong with autogen, I get
make VERBOSE=1
# Making out/VERSION
mkdir -p ./out
echo 2.21.1 > out/VERSION
# Making
Am Donnerstag, den 16.04.2020, 07:16 +0200 schrieb Werner LEMBERG:
> > I did some better structured measurements, with interleaved runs on
> > MSDM: [...]
>
> Have you ever tried valgrind's `callgrind` tool for profiling (and
> using `kcachegrind` for displaying the results)? While very slow it
On Apr 16, 2020, at 01:16, Werner LEMBERG wrote:
>
> Have you ever tried valgrind's `callgrind` tool for profiling (and
> using `kcachegrind` for displaying the results)? While very slow it
> would avoid temperature issues and the like – no need to call it
> multiple times to get reliable
Building lilypond you get a bunch of harmless but annoying
langdefs.py: warning: lilypond-doc gettext domain not found.
and
.../podir-targets.make:14: warning: ignoring old recipe for target 'po-update'
messages. Is there a way to suppress them?
Werner
> To conclude, I believe we should choose one of Gerrit and GitLab and
> have a trial to see if the processes can be carried over.
I'm fine with both. If in doubt please select the one that is easier
to manage, and which provides good support for CI and things like
this.
Werner
On 2020/04/15 22:15:04, hanwenn wrote:
> On 2020/04/14 20:07:17, hahnjo wrote:
> > On 2020/04/14 19:14:29, hanwenn wrote:
> > > On 2020/04/14 10:22:01, hahnjo wrote:
> > > > On 2020/04/14 09:39:18, hanwenn wrote:
> > > > > it reads from the immutable_list_ if there is no override in
the
> > > > >
20 matches
Mail list logo
