subsurface.git/core, branch v5.0.2

desktop: Add the capability to copy / paste dive number and date / time.

2021-05-19T22:15:34Z

This is adding the capability to select 'Dive number' and 'Date / Time' in the 'Copy dive components' dialog, and then copy them into the clipboard. When using 'Paste dive components, these values will then be pasted into the selected dive(s). This is intended to help with workflows that import dive information from two different sources, like general information from another logging program, and CCR ppO2 sensor readings from a unit log, and then stitch them together into one cohesive entry with all data per dive. Copied data is also output into formatted text when pasting the clipboard outside of the application: ``` Dive number: 401 Date / time: Sun 2 May 2021 12:00 AM ``` No translations have been added as of now - I could not find any information on how strings are translated for this project. Signed-off-by: Michael Keller

profile: rename GF_LINE color to DURATION_LINE

2021-05-08T11:40:24Z

The color was misnamed, since it has only been used for the duration line for quite some time (since 893bea700c98 to be exact). Signed-off-by: Berthold Stoeger

profile: remove DiveAmbPressureItem

2021-05-08T11:40:24Z

This was replaced by the tissue map in 893bea700c98. Signed-off-by: Berthold Stoeger

The planner should not always ascent from the depth of

2021-05-07T15:16:41Z

the last manually entered waypoint but consider the possibility that it should first top where we are before the next stop depth has cleared. Reported-by: David Carron Signed-off-by: Robert C. Helling

xml parsing: add XML_PARSE_HUGE flag to xmlReadMemory()

2021-04-21T15:39:29Z

It looks like libxml2 has some internal limitations by default that causes parse failures in some situations. Avoid them with XML_PARSE_HUGE. Without this, you get errors like test.xml:349250: parser error : internal error: Huge input lookup όμουν τουλάχιστον αλλά +2kg και ενδεχομένως +4 ^ when something in the xml file grows too large. I don't know libxml2 internals, so I have no idea what exactly goes wrong, but the docs say: XML_PARSE_HUGE = 524288 : relax any hardcoded limit from the parser and that makes us successfully parse the Greek file from Kostas. Reported-by: Kostas Katsioulis Signed-off-by: Linus Torvalds

cleanup: don't hardcode array length

2021-04-19T19:51:01Z

Move the ARRAY_SIZE macro into a header file and use it to determine the number of cloud servers that we need to check. Suggested-by: Linus Torvalds Signed-off-by: Dirk Hohndel

cloudstorage: update remote if cloud server changes

2021-04-19T19:51:01Z

If we can't reach the cloud server in the URL (which might come from the settings or be passed in by the user), we try the alternative server(s). If we end up changing servers, we need to update the remote that we have already parsed from the URL. Signed-off-by: Dirk Hohndel

cloudstorage: try alternative server if first connection fails

2021-04-19T19:51:01Z

If we can't reach our preferred server, try using a different one. The diff makes more sense when ignoring white space. With this we check the connection to the cloud server much earlier and in case of failure to connect try a different cloud_base_url. Signed-off-by: Dirk Hohndel

cloudstorage: create consistent local directory names

2021-04-19T19:51:01Z

With the new names for the cloud server we'd get different local cache directory names depending on which server gets used. In order to avoid that, normalize the name before generating the hash that determines the local directory name. Additionally, the old code had an extra '/' in the URL, due to the way the URL was assembled. Again, to match the existing hash for people upgrading from older Subsurface versions, add that to our normalized name as well. Signed-off-by: Dirk Hohndel

cloudstorage: try to pick between multiple cloud servers

2021-04-19T19:51:01Z

The backend infrastructure will soon be able to support more than one cloud server which automagically stay in sync with each other. One critical requirement for that to work is that once a session was started with one of the servers, the complete session happens with that server - we must not switch from server to server while doing a git transaction. To make sure that's the case, we aren't trying to use DNS tricks to make this load balancing scheme work, but instead try to determine at program start which server is the best one to use. Right now this is super simplistic. Two servers, one in the US, one in Europe. By default we use the European server (most of our users appear to be in Europe), but if we can figure out that the client is actually in the Americas, use the US server. We might improve that heuristic over time, but as a first attempt it seems not entirely bogus. The way this is implemented is a simple combination of two free webservices that together appear to give us a very reliable estimate which continent the user is located on. api.ipify.org gives us our external IP address ip-api.com gives us the continent that IP address is on If any of this fails or takes too long to respond, we simply ignore it since either server will work. One oddity is that if we decide to change servers we only change the settings that are stored on disk, not the runtime preferences. This goes back to the comment above that we have to avoid changing servers in mid sync. Signed-off-by: Dirk Hohndel