smtk2ssrf : tank description imported as unknown
In my last message I wrote : > The simple solution is to open SmartTrak and to manually insert a 200 bar start pressure for the > first ( or unique ) tank in the few dives where such piece of information is not available; doing that > the tank description for the first tank is expected to be included in the .xml file , even when the > diver does not remember the Start or End pressure for the concerned dive. Yesterday night I tried to set to 200 bars as the Start pressure for the dives; this would have been the solution of the "unknown tank" issue. And it was indeed, with a few exceptions. In fact if you start a dive without the pressure transmitter or with a non working transmitter and you DO NOT REMEMBER TO ERASE THE TRANSMITTER PAIRING DATA, the result is that the Start and End Pressure of the concerned tank are set to 0. MOREOVER THE SmartTrak software prevents the user to manually insert such data: IT IS STUPID ... BUT IT IS THE ACTUAL BEHAVIOR OF SmartTrak ... Best regards. Alessandro ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
smtk2ssrf AppImage on Subsurface downloads page
I believe sufficient energy and testing has gone into smtk2ssrf so that we can make the AppImage available on the downloads page? My motivation is that very few divers have the skills to build an AppImage themselves. Making the AppImage avalable avoids the need to build one. Kind regards, willem ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: manual edit of depth and time when adding / editing dives
On Sat, Mar 04, 2017 at 07:59:57AM +0100, Stefan Fuchs wrote: > Good morning, > > Update, still no real debug built but GDB also with this exe gives some > hints :-) I believe that I may have figured out what was causing the crashes for you. Can you test the latest master (I merged this into master to get broader testing). We should also have current daily builds available /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Several float to int potential rounding errors/inconsistencies
Good morning/afternoon/evening all, I've been lately trying to get subsurface tests to pass under windows. In the current state, TestParse and TestPreferences are the two ones still failing... In short, the error raised by TestParse is caused by a rounding error when converting dm4 sample depth from float meters to int millimeters. The inconsistency was raised running the test on windows but same behavior can be seen on linux for certain float values too. Have a look at the changes in the pull request here for the details: https://github.com/Subsurface-divelog/subsurface/pull/233 The fix in itself is easy, surround the booean_value * 1000 with a rint: "rint(booean_value * 1000)" when it is assigned to the integer variable... As I was commenting in the pull request, I have identified several other potential similar rounding issues. The exact same one in dm5_dive code, in maxdepth computation for both dm4_dive and dm5_dive and many other places in parse-xml.c code and some as well (but in lesser amount) in other parts of the code. The one fixed here is the only one that was highlighted by a test failure (when running TestParse on windows). How should we proceed forward? 1. My original goal was more to get all tests passing under windows so it could get integrated in CI, TestPreference is still failing... So we could simply pull this change and get back to this issue later, focusing first on test execution for windows CI. 2. Fix "blindly" all potential rounding errors, but I'm not really clear on what could be the side effect(s) of this. 3. Spend time creating test cases that would highlight each rounding errors but the task is huge, not always straight forward (blob data), and current test philosophy seem to be closer to quick functional testing rather than deep regression testing. What is your point of view here? Best regards, Jérémie ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface