On 14 Mar 2017 5:29 AM, "Jérémie Guichard" wrote:
Ho!
I didn't realized I used the -Wfloat-conversion on C code only and not C++
when I did my previous round of float/double to int patch!
Looking into that now. There is a bunch of new warnings adding the flag but
seems (at
Pull request ready :)
https://github.com/Subsurface-divelog/subsurface/pull/254
2017-03-14 2:00 GMT+07:00 Linus Torvalds :
> On Mon, Mar 13, 2017 at 11:29 AM, Jérémie Guichard
> wrote:
> >
> > Looking into that now. There is a bunch of new
On Mon, Mar 13, 2017 at 11:29 AM, Jérémie Guichard wrote:
>
> Looking into that now. There is a bunch of new warnings adding the flag but
> seems (at first look) to be managable.
Yeah, I was afraid there would be some infrastructure stuff, but it
all looks like our source.
>
Ho!
I didn't realized I used the -Wfloat-conversion on C code only and not C++
when I did my previous round of float/double to int patch!
Looking into that now. There is a bunch of new warnings adding the flag but
seems (at first look) to be managable.
Working on the patch right now...
On Mon, Mar 13, 2017 at 09:07:31AM -0700, Linus Torvalds wrote:
> On Mon, Mar 13, 2017 at 12:35 AM, Rick Walsh wrote:
> >
> > void PlannerSettingsWidget::setAscRate75(int rate)
> > {
> > -
> > SettingsObjectWrapper::instance()->planner_settings->setAscrate75(rate *
On Mon, Mar 13, 2017 at 12:35 AM, Rick Walsh wrote:
>
> void PlannerSettingsWidget::setAscRate75(int rate)
> {
> -
> SettingsObjectWrapper::instance()->planner_settings->setAscrate75(rate *
> UNIT_FACTOR);
> +
>
As reported on the mailing list, the ascent/descent rates are sometimes not
what is expected. E.g. setting the ascent rate to 10m/min results in an actual
ascent rate of 9m/min. This is due to truncating the ascent rate preference,
then effectively rounding up the time to reach each stop to 2s