flower: Clean up libc-extension

flower: Clean up libc-extension

Individual commits:
1) Remove unused includes of libc-extension.hh

2) Rewrite String_convert::to_upper, ::to_lower via std::transform

3) Rename my_round to round_halfway_up
    
The function differs from std::round() in the handling of negative
numbers: While std::round() rounds halfway cases away from zero,
round_halfway_up (as the name suggests) rounds them up for historic
reasons.
This can apparently be relied upon at least when manually positioning
ties (input/regression/tie-single-manual.ly). In the long run, these
cases should be identified and taken care of individually. Keep this
function for the time being, but DO NOT USE in newly written code.

While passing by, move some system headers last (this helps avoid issues
that one of LilyPond's headers depends on other system headers being
loaded first) and add them if apparently used in the file.

[hahnjo, 2020-03-17 21:06:42]

https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
File input/regression/tie-single-manual.ly (right):

https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
input/regression/tie-single-manual.ly:19: \override Tie.staff-position = #-7.4
I'm not really happy about tweaking this test like this. It relies on rounding
halfway always up (my_round) instead of away from zero (std::round). I think
this is a coincidence, but if we want to retain this I need to go through all
replacements of my_round -> std::round and check if the argument could be
negative...

[hanwenn, 2020-03-17 21:27:52]

https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
File input/regression/tie-single-manual.ly (right):

https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
input/regression/tie-single-manual.ly:19: \override Tie.staff-position = #-7.4
On 2020/03/17 21:06:42, hahnjo wrote:
> I'm not really happy about tweaking this test like this. It relies on rounding
> halfway always up (my_round) instead of away from zero (std::round). I think
> this is a coincidence, but if we want to retain this I need to go through all
> replacements of my_round -> std::round and check if the argument could be
> negative...

couldn't you inline my_round into the call site that needs this and add a
comment? The change otherwise risks breaking user tweaks, which we should avoid
if we can.

[lemzwerg, 2020-03-17 21:28:35]

https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
File input/regression/tie-single-manual.ly (right):

https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
input/regression/tie-single-manual.ly:19: \override Tie.staff-position = #-7.4
> I'm not really happy about tweaking this test like this.
> It relies on rounding halfway always up (my_round)
> instead of away from zero (std::round). I think this is
> a coincidence, but if we want to retain this I need to
> go through all replacements of my_round -> std::round
> and check if the argument could be negative...

Hmm.  Are you talking about rounding to integers?  If `staff-position` is a
floating point value, LilyPond takes it as an exact value, see
`has_manual_delta_y`.  So there shouldn't be any rounding here...

I've accidentally added this to the documentation today, see issue #4955.

[hahnjo, 2020-03-17 21:36:41]

On 2020/03/17 21:27:52, hanwenn wrote:
>
https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
> File input/regression/tie-single-manual.ly (right):
> 
>
https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
> input/regression/tie-single-manual.ly:19: \override Tie.staff-position = #-7.4
> On 2020/03/17 21:06:42, hahnjo wrote:
> > I'm not really happy about tweaking this test like this. It relies on
rounding
> > halfway always up (my_round) instead of away from zero (std::round). I think
> > this is a coincidence, but if we want to retain this I need to go through
all
> > replacements of my_round -> std::round and check if the argument could be
> > negative...
> 
> couldn't you inline my_round into the call site that needs this and add a
> comment? The change otherwise risks breaking user tweaks, which we should
avoid
> if we can.

Yes, that was my thought. The problem is that I don't know in which call sites
could exhibit negative values, possibly all of them?

On 2020/03/17 21:28:35, lemzwerg wrote:
>
https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
> File input/regression/tie-single-manual.ly (right):
> 
>
https://codereview.appspot.com/553740043/diff/547780043/input/regression/tie-...
> input/regression/tie-single-manual.ly:19: \override Tie.staff-position = #-7.4
> > I'm not really happy about tweaking this test like this.
> > It relies on rounding halfway always up (my_round)
> > instead of away from zero (std::round). I think this is
> > a coincidence, but if we want to retain this I need to
> > go through all replacements of my_round -> std::round
> > and check if the argument could be negative...
> 
> Hmm.  Are you talking about rounding to integers?  If `staff-position` is a
> floating point value, LilyPond takes it as an exact value, see
> `has_manual_delta_y`.  So there shouldn't be any rounding here...

Yes. I hope I've marked the correct rounding that I found out to be responsible
for the difference.

https://codereview.appspot.com/553740043/diff/547780043/lily/tie-formatting-p...
File lily/tie-formatting-problem.cc (right):

https://codereview.appspot.com/553740043/diff/547780043/lily/tie-formatting-p...
lily/tie-formatting-problem.cc:908: conf.position_ = (int) std::round
(specifications_[i].manual_position_);
IIRC this is the call site that influences the regression test.

[Dan Eble, 2020-03-18 00:17:12]

Jonas,

I'm low on energy, so I'm not going to review this now, but I there are a few
points I want to mention.

1. thanks for cleaning things up!
2. maybe the rounding change should wait for 2.21.1
3. please don't look at real.hh/cc; I've got a patch for it that I'm waiting to
post

[hahnjo, 2020-03-18 07:20:32]

On 2020/03/18 00:17:12, Dan Eble wrote:
> Jonas,
> 
> I'm low on energy, so I'm not going to review this now, but I there are a few
> points I want to mention.
> 
> 1. thanks for cleaning things up!
> 2. maybe the rounding change should wait for 2.21.1

I'll rework the patch to keep the rounding functionality; it may break user
markup.

> 3. please don't look at real.hh/cc; I've got a patch for it that I'm waiting
to
> post

Great, looking forward to more cleanups in this area.

[hahnjo, 2020-04-11 15:59:32]

Rename my_round() to round_halfway_up()

[hahnjo, 2020-04-11 16:04:22]

On 2020/04/11 15:59:32, hahnjo wrote:
> Rename my_round() to round_halfway_up()

As promised, the updated patch keeps the functionality. However I've renamed the
function and added clear documentation that it should not be used in new code.