Commit graph

7 commits

Author SHA1 Message Date
Berthold Stoeger
185b4678ff tests: work on sorted dive lists
The dive list will be changed to an always-sorted list where one can
use binary search.

However, this makes some tests fail, because they only use parse_dive(),
which doesn't do any sorting.

To fix this future problem, sort the tables before performing the tests.
This provides a more realistic setup, as in the actual application,
the dive list will always be sorted on import.

Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-06-17 00:03:28 +02:00
Linus Torvalds
6c4e890960 Clean up divecomputer 'device' handling
We have this odd legacy notion of a divecomputer 'device', that was
originally just basically the libdivecomputer 'EVENT_DEVINFO' report
that was associated with each dive.  So it had firmware version,
deviceid, and serial number.

It had also gotten extended to do 'nickname' handling, and it was all
confusing, ugly and bad.  It was particularly bad because it wasn't
actually a 'per device' thing at all: due to the firmware field, a dive
computer that got a firmware update forced a new 'device'.

To make matters worse, the 'deviceid' was also almost random, because
we've calculated it a couple of different ways, and libdivecomputer
itself has changed how the legacy 32-bit 'serial number' is expressed.

Finally, because of all these issues, we didn't even try to make the
thing unique, so it really ended up being a random snapshot of the state
of the dive computer at the time of a dive, and sometimes we'd pick one,
and sometimes another, since they weren't really well-defined.

So get rid of all this confusion.

The new rules:

 - the actual random dive computer state at the time of a dive is kept
   in the dive data. So if you want to know the firmware version, it
   should be in the 'extra data'

 - the only serial number that matters is the string one in the extra
   data, because that's the one that actually matches what the dive
   computer reports, and isn't some random 32-bit integer with ambiguous
   formatting.

 - the 'device id' - the thing we match with (together with the model
   name, eg "Suunto EON Steel") is purely a hash of the real serial
   number.

   The device ID that libdivecomputer reports in EVENT_DEVINFO is
   ignored, as is the device ID we've saved in the XML or git files. If
   we have a serial number, the device ID will be uniquely associated
   with that serial number, and if we don't have one, the device ID will
   be zero (for 'match anything').

   So now 'deviceid' is literally just a shorthand for the serial number
   string, and the two are joined at the hip.

 - the 'device' managament is _only_ used to track devices that have
   serial numbers _and_ nicknames. So no more different device
   structures just because one had a nickname and the other didn't etc.

   Without a serial number, the device is 'anonymous' and fundamentally
   cannot be distinguished from other devices of the same model, so a
   nickname is meaningless. And without a nickname, there is no point in
   creating a device data structure, since all the data is in the dive
   itself and the device structure wouldn't add any value..

These rules mean that we no longer have ambiguous 'device' structures,
and we can never have duplicates that can confuse us.

This does mean that you can't give a nickname to a device that cannot be
uniquely identified with a serial number, but those are happily fairly
rare (and mostly older ones).  Dirk said he'd look at what it takes to
give more dive computers proper serial numbers, and I already did it for
the Garmin Descent family yesterday.

(Honesty in advertizing: right now you can't add a nickname to a dive
computer that doesn't already have one, because such a dive computer
will not have a device structure.  But that's a UI issue, and I'll sort
that out separately)

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-18 13:22:02 -07:00
Robert C. Helling
2064ce06cc Fix pO2 for CCR at shallow depths
Even when diving a CCR, the pO2 cannot exceed ambient
pressure. This only makes a difference at shallow depths.

Fix this in the calculation of OTUs and CNS.

This affects some tests that now have slightly different CNS and OTU values.

Suggested-by: Justin Ashworth
Signed-off-by: Robert C. Helling <helling@atdotde.de>
2021-02-26 08:42:30 -08:00
Linus Torvalds
62e95fdc86 Save SAC, OTU and CNS in the XML export
We do _not_ read them back, since they are calculated values, although I
guess we could aim to do that too at some point in case we have an
import from somewhere else that has these values but not the profile (or
gas use) to actually calculate them.

Fix test-cases that are checked by TestParse (but nothing else) to match.

Requested-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-14 13:27:07 -07:00
Berthold Stoeger
17526ded58 cleanup: move clearing of device nodes to clear_dive_file_data()
It makes no sense to keep the device nodes if all the other data
is cleared. Let's do this automatically and not explicitly.
This ensures that the function is also called on mobile.
Currently it was only called on desktop.

Weirdly, the parser-tests were expecting that the device nodes
were not reset by clear_dive_file_data() and therefore divecomputers
were accumulating in the test results. Thus, the additional
computers had to be removed from the expected test results.

Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-04-24 10:40:12 -07:00
Miika Turkia
0c564a4579 Fix test parsing as new DC appears in the XML files
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
2017-11-27 13:42:10 -08:00
Dirk Hohndel
ec20d36f3c Add test for merging multiple cylinders
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-02-09 22:22:12 -08:00