subsurface.git/core, branch v5.0.3

Planner: Correctly compute CNS and OTU for bailout segments

2021-08-19T17:58:08Z

For dives with mixed divemode, one needs to check sample.setpoint to figure out if the segment is an OC segment and the po2 needs to be computed from the gasmix and ambient pressure. This fixes #3310 Signed-off-by: Robert C. Helling

undo/device: adjust device management infrastructure

2021-08-18T20:22:02Z

We no longer need the remove infrastructure, and the edit nickname function becomes much more intuitive to use by passing in the dive computer for which we want to create a nickname instead of the internal index into the array of devices. This also removes / simplifies the device list update signals in the DiveListNotifier. Signed-off-by: Dirk Hohndel

core: add get_or_add helper for dc table

2021-08-18T20:22:02Z

This makes it much easier to manipulate dc nickname entries. In order for that to work we can't simply remove entries with empty nickname (but that isn't needed, anyway, as the code that saves XML or git already handles that case correctly). Signed-off-by: Dirk Hohndel

Don't share dive computer data allocations

2021-08-18T20:22:02Z

... it just causes problems later when we free them, since we don't do any reference counting. Signed-off-by: Linus Torvalds

Update the serial number and deviceid in sync when loading

2021-08-18T20:22:02Z

When we save the divecomputer data, we never actually save the serial value as a field. We used to rely on saving the very dodgy 'deviceid', and then look up the serial number from there. And that never really worked reliably, but we didn't really notice, because we never really _used_ the serial number anywhere. The only place the serial number is actually reliably displayed is in the "Extra data" tab, which contains the key value pairs, and that's where the original dive download code got the serial number from. So just parse that at load time too, the same way we parsed it at dive download time. In fact, do the firmware version the same way, and remove the code from the downloader, since it too can rely on 'add_extra_data()' just picking up the information directly. Signed-off-by: Linus Torvalds

Clean up divecomputer 'device' handling

2021-08-18T20:22:02Z

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

core: add downloaded GPS to existing dive site

2021-08-15T16:31:17Z

If we download a first dive computer and add a dive site to the dive (by setting a location name for example), and then download from another dive computer that provides us with GPS data, we should keep the existing dive site information, but add the GPS data from the freshly downloaded dive computer. Signed-off-by: Dirk Hohndel

export: clean up temp file after divelogs.de upload

2021-08-06T18:05:06Z

This adds a cleanup function to be called after a divelogs.de upload finishes (successful or not) to make sure the temporary zip file is closed and removed. Signed-off-by: Richard Fuchs

export: use unique temporary file for divelogs.de upload

2021-08-03T15:34:18Z

On multi-user systems with a shared directory for temporary files, using a static file name can lead to permissions problems and subsequent errors due to collisions. Use a random unique file name for each generated file to avoid these problems. Note: the temporary file generated from the divelogs.de upload is still left behind after the upload finishes. Signed-off-by: Richard Fuchs

core/import: fix string check logic

2021-07-23T18:30:17Z

The intent of the code was to check that there is a string and it has at least two characters. Since iter is the result of a strchr(iter, '|') call, we know that if iter isn't NULL, iter[0] is '|', so we only need to check the next character. Signed-off-by: Dirk Hohndel