Re: Several float to int potential rounding errors/inconsistencies

[Jérémie Guichard]

Hey guys,

Thanks for the help on this topic!

I have now updated my pull request with the different proposed changes.
The first commit changes all rint to lrint. Based on Lubomir
recommendation, I went through the different places to check (and use)
lrintf where necessary. Doing so I found two places that looked strange to
me since (to my understanding) it was using rint on the result of an
integer division, this seemed curious! This is why I changed the code to
use double/float division. Please have a closer look there:

In dive.h the gas_mnd function:
rint(mbar_to_depth(maxambient, dive) / roundto) * roundto;

In parse-xml.c the divinglog_profile function:
rint(atoi(cns) / 10)

Second commit, fixes all warnings raised by "-Wfloat-conversion", I made
the change from round to lrint in uemis code too.

Unfortunately I could not enable the flag in that commit since travis seems
to be using gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 that do not include
this option... Nevertheless it may be a good idea to make use of the option
so should we:
1. Upgrade travis build to use more recent version of gcc and add the flag
unconditionally?
2. Add the flag under a cmake gcc version condition so that people using
more recent version of gcc in their dev env be warned about the mistakes?
3. Since 1 could be annoying to people still using older gcc in their dev
env, we could upgrade travis but still put the flag behind a condition like
proposed in 2?

With this change, TestParse will now pass on Windows too, we now only have
TestPreference failing! Getting there :)

Best regards,

Jérémie

2017-03-08 9:21 GMT+07:00 Jérémie Guichard :

> I'm looking into that right now :)
>
> 2017-03-08 7:18 GMT+07:00 Dirk Hohndel :
>
>> On Tue, Mar 07, 2017 at 09:43:06AM -0800, Linus Torvalds wrote:
>> > On Tue, Mar 7, 2017 at 9:20 AM, Lubomir I. Ivanov 
>> wrote:
>> > >
>> > > lrint() seems to build for me with mingw 4.9.2.
>> >
>> > .. in fact, I notice that we had a couple of places in the GPS
>> > coordinates code that already used 'lrint()', so it must work.
>> >
>> > The uemis code has a few places that use 'round()' instead of rint() -
>> > those should probably be converted to 'lrint()' as well.
>>
>> Would you be willing to run the script, make the other changes you
>> suggest, and send a patch / pull request?
>>
>> I'm really swamped this week.
>>
>> /D
>>
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Jérémie Guichard]

I'm looking into that right now :)

2017-03-08 7:18 GMT+07:00 Dirk Hohndel :

> On Tue, Mar 07, 2017 at 09:43:06AM -0800, Linus Torvalds wrote:
> > On Tue, Mar 7, 2017 at 9:20 AM, Lubomir I. Ivanov 
> wrote:
> > >
> > > lrint() seems to build for me with mingw 4.9.2.
> >
> > .. in fact, I notice that we had a couple of places in the GPS
> > coordinates code that already used 'lrint()', so it must work.
> >
> > The uemis code has a few places that use 'round()' instead of rint() -
> > those should probably be converted to 'lrint()' as well.
>
> Would you be willing to run the script, make the other changes you
> suggest, and send a patch / pull request?
>
> I'm really swamped this week.
>
> /D
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Dirk Hohndel]

On Tue, Mar 07, 2017 at 09:43:06AM -0800, Linus Torvalds wrote:
> On Tue, Mar 7, 2017 at 9:20 AM, Lubomir I. Ivanov  wrote:
> >
> > lrint() seems to build for me with mingw 4.9.2.
> 
> .. in fact, I notice that we had a couple of places in the GPS
> coordinates code that already used 'lrint()', so it must work.
> 
> The uemis code has a few places that use 'round()' instead of rint() -
> those should probably be converted to 'lrint()' as well.

Would you be willing to run the script, make the other changes you
suggest, and send a patch / pull request?

I'm really swamped this week.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Import dives from Smart Trak software?

[Anton Lundin]

On 07 March, 2017 - Rick Walsh wrote:

> On 7 Mar 2017 2:53 AM, "Anton Lundin"  wrote:
> 
> On 06 March, 2017 - Jenny Ough wrote:
> 
> > Hi team
> >
> 
> Hi Jenny, great to see another Australian here.
> 
> >
> > Just wondering if I would be able to import my dives from my existing
> > SmartTrak software into your software? No multiple gas dives - just either
> > air or nitrox. Screen shot below. My computer died, so all the details you
> > see below have been manually input.
> 
> There's a tool, smrtk2ssrf, which does the one-off task of converting a
> SmartTrak logbook into a ssrf-logbook. It's currently a Linux-only tool,
> but if you're not capable, comfortable or otherwise able to run it,
> there are probably plenty of folks here on the list who can do the
> actual converting for you.
> 
> > I'm about to purchase a Shearwater Perdix - does Subsurface talk to that
> > computer?
> 
> Subsurface works great with Shearwater Perdix.
> 
> 
> Anton, I thought there was still an issue with the Perdix using only BLE,
> rather than regular Bluetooth, and we are not yet with supporting BLE. Can
> you confirm?
> 
> Subsurface definitely works great with the Shearwater Petrel.

Ok, I took a nose first dive into some documentation and this and here
is what I came up with:


Shearwater Perdix has a "Smart Ready Bluetooth Interface"

Shearwater Perdix AI has a "Bluetooth Smart Interface"


According to random internet sites[1,2] "Smart ready" means v2(classic)
and v4(btle), while "Smart" means v4(btle) only.


So, that basically says: Perdix works with Subsurface while Perdix AI
doesn't. Subsurface only does v2(classic) currently.


//Anton



1. http://www.laptopmag.com/articles/just-what-is-bluetooth-4-0-anyway
2. https://en.wikipedia.org/wiki/Bluetooth§


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

smkt2ssrfgas switching

[Alessandro Volpi]

Dear Salva,

in one of last messages I wrote that the gas/tank switching events were
correctly recorded.

This is true for most dives.

Nevertheless I have found an exception : exceptions are always there; if
you look carefully for them you will always find at least one of them.

The glitch is probably related to the naming conventions for tanks adopted
by SmartTec and Galaileo, before the upgrade to Galileo Trimix.

GalileoTrimix tank names range from T1 to T0 ( it should be T10 ... ).

Standard UWATEC computer are supporting only 3 tanks, denominated T1 T2 and
TD; TD means Decompression Tank.

The problem is that the user is not allowed to define T2 unless TD has been
defined; for example if you dive with a 15 liter tank with air and a small
3 liter tank filled with Nitrox 35, you are forced to call this tank TD and
not T2.

Dives #418 and # 419 in my logbook were carried out according to the
example.

The result is that the subsurface tank table displays a T2 "ghost tank"
with the same Start and End pressures of the TD "physical tank". The gas
switch is displayed as a switch to tank T2 ... It should be displayed as a
switch to tank T3, since this is the subsurface name for TD.

It is likely that the bug is to be found in the subsurface code and not in
smtk2ssrf, since the tank descriptors seem to be OK if the .xml is opened
with vim.

I am sending this message to your attention, since i guess that the gas
switch event handling is carried out by smtk2ssrf .. perhaps I am wrong

The files .slg and .xml can be found in my Dropbox folder.

Very best regards.

Alessandro
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Linus Torvalds]

On Tue, Mar 7, 2017 at 9:20 AM, Lubomir I. Ivanov  wrote:
>
> lrint() seems to build for me with mingw 4.9.2.

.. in fact, I notice that we had a couple of places in the GPS
coordinates code that already used 'lrint()', so it must work.

The uemis code has a few places that use 'round()' instead of rint() -
those should probably be converted to 'lrint()' as well.

   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Lubomir I. Ivanov]

On 7 March 2017 at 19:11, Linus Torvalds  wrote:
> On Mon, Mar 6, 2017 at 8:50 PM, Linus Torvalds
>  wrote:
>>
>> Ugh, yes. Mainly because it warns even about the "cast rint() to an
>> integer" case:
>
> Actually, the correct thing to do is to use lrint(), but my very dim
> memory is that this didn't work on Windows.
>
> Dirk (or anybody else with a Windows build), does this build:
>
> git grep -l '\
> it just replaces 'rint()" calls with 'lrint()'.
>
> If it does build, you should just commit it. Otherwise we'd need some
> Windows helper macro to implement it, possibly just
>
>#ifdef WIN32
> #define lrint(x) ((long)rint(x))
>#endif
>
> or similar.
>
> That gets rid of the worst noise, and leaves just real (but admittedly
> likely not very important) float->integer conversion warnings.
>

lrint() seems to build for me with mingw 4.9.2.
if it works for Dirk's Windows build, then its good to go.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Linus Torvalds]

On Mon, Mar 6, 2017 at 8:50 PM, Linus Torvalds
 wrote:
>
> Ugh, yes. Mainly because it warns even about the "cast rint() to an
> integer" case:

Actually, the correct thing to do is to use lrint(), but my very dim
memory is that this didn't work on Windows.

Dirk (or anybody else with a Windows build), does this build:

git grep -l '\integer conversion warnings.

Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

[Jef Driesen]

On 2017-03-03 14:08, Salvador Cuñat wrote:

On Fri, Mar 03, 2017 at 10:50:23AM +0100, Salvador Cuñat wrote:

El 03/03/2017 09:53, "Anton Lundin"  escribió:
>
> I guess its easiest just to modify the libdivecomputer call to dump the
> profile data to a file. That way smtk2ssrf can generate the raw dive
> dumps that Jef is looking for.
>
Probably. There shouldn't be any problem. Will try to dump 2/3 
affected

dives, with headers and without them.


Attached some files. Those named "complete" includes profile and a
faked header (as datatrak logs imported into smarttrak lack of their
own).


At first sight, it looks like the profile is truncated. (I can't really 
confirm that, because I don't know how long the dive should be.) The 
last sample isn't complete. The size check for the extra decompression 
byte fails.


I wonder if this happens only for export from the smarttrak, or also for 
dives downloaded directly from the dive computer. Any chance you can get 
me a memory dump from the same dive computer?


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface