This tests for the planner getting the gases in the
manually entered part of the dive wrong (as here: from
incorrect value returned by get_gasmix_at_time.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Add a checkbox that triggers replacement of all English characters by
x's in notes, buddy, dive guide and (while we are at it) suit.
This is ment for people sharing logs for debugging that are concious
about privacy issues. It leaves the lenth of strings in tact as well
as special charcters as those might be needed to track down a particular
parsing problem.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
In a previous commit, the get_gasmix_* functions were changed to
return by value. For consistency, also pass gasmix by value.
Note that on common 64-bit platforms struct gasmix is the size
of a pointer [2 * 32 bit vs. 64 bit] and therefore uses the
same space on the stack. On 32-bit platforms, the stack use
is probably doubled, but in return a dereference is avoided.
Supporting arbitrary gas-mixes (H2, Ar, ...) will be such an
invasive change that going back to pointers is probably the
least of our worries.
This commit is a step in const-ifying input parameters (passing
by value is the ultimate way of signaling that the input parameter
will not be changed [unless there are references to said parameter]).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a divemode column to the planner model and a
corresponding field to struct divepoint and fill it
in the corresponding functions.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
For UI responsiveness, we need to be able to run the planner in the background. This needs the
planner state to be localized (and we need to pass a pointer around).
In order to not let too many lines overrun (and to save typing in the future)
I have renamed instances of struct deco_state to ds. Yes this should have gone
to a separate commit but I accidentally commit --amend'ed it.
Computing of planner variations is temporarily disabled.
Unlock the planner when returning early
So we don't deadlock in add dive and recreational mode (which
use the planner without actually planning).
Signed-off-by: Robert C. Helling <helling@atdotde.de>
... and reset deco information in profile ceiling computation.
The planner test then needs to know about the struct holding the deco
state.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
...rather than use a global variable and a macro.
This should be a no-op in preparation to allow planning
several versions of a dive.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Wfloat-conversion enabled for C++ part of the code
Fix warnings raised by the flag using lrint
Original issue reported on the mailing list:
The ascent/descent rates are sometimes not what is expected.
E.g. setting the ascent rate to 10m/min results in an actual
ascent rate of 9m/min.
This is due to truncating the ascent rate preference,
then effectively rounding up the time to reach each stop to 2s intervals.
The result being that setting the ascent rate to 10m/min
results in 20s to ascend 3m (9m/min), when it should be exactly 18s.
Reported-by: John Smith <noseygit@hotmail.com>
Reported-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
Add automatic tests in TestPlan for minimum gas:
- Copy minimum gas result (pressure) to diveplan.
- Add cylinder size and working pressure for bottom gas to every dive in TestPlan
Hint: Unrealistic cylinder sizes (100l, 200l) have to be used for the very long and deep dives in TestPlan
- Add minimum gas check for every dive
- Add two additional test dives in TestPlan which produce sane minimum gas results with 24l tank
Hint: Deco check for these new dives is commented out at the moment
Signed-off-by: Stefan Fuchs <sfuchs@gmx.de>
This patch eliminates the difference between the saturation and
desaturation rates. This was probably once meant as a conservative
measure but the desaturation rate was increased rather than the
saturation rate (which is probably a typo, as reported by Stefan).
Since there is no good basis for this anyway, this patch sets
both factors to 1.0 (and if accepted the whole factor business
should be removed).
This makes our deco times slightly longer. But in the past,
we had introduced a 1.2% fudge factor in the critical radius
calculation to add conservatism and match the benchmark better.
Removing this fudge factor brings us close to the benchmarks.
Expected test values updated.
Reported-by: Stefan <sjti@gmx.net>
Signed-off-by: Robert C. Helling <helling@atdotde.de>
In the beginning of the diveplan, divedatapoints of zero
duration indicate available gases with the depth giving
the suggested switch depth. Zero-duration datapoints in
the middle of the dive do not have this meaning and should
thus be ignored when composing the gaslist.
The tests should have these gas defining segments in the beginning.
This fixes a problem when replanning a dive that would change
to random gases during deco.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
This is to avoid confusion with planner.display_deco_mode.
When accessing the "current deco mode" use the decoMode()
helper function.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
A few more fixes for things that broke in commit 7be962bfc2 ("Move
subsurface-core to core and qt-mobile to mobile-widgets").
[Dirk Hohndel: slightly edited and overlap with Linus' patch removed]
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The purpose of testing against known Subsurface runtimes is to warn (when test
is run in verbose mode) if the runtime has altered. Before the next release, we
should update the known Subsurface runtimes to match current behaviour, so we
are alerted when we change something during the next release cycle.
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit 9d8b0ad introduces the copy_prefs function, and uses it to replace prefs
= default_prefs. We need to include subsurfacestartup.h for it to work in
testplan.cpp, otherwise TestPlan_build fails.
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When just assigning one structure to the other we copy the string
pointers. If we then modify those strings in the copy, we happily free
the strings of the original. And then resetting the preferences equally
happily reused those strings, pointing to long since freed memory.
I think what I did now is excessive for the current use case in that it
copies a ton of strings that are unset in the default_prefs. But I figured
this is a rarely used function and I might as well do it correctly.
Also, once we implement multi user support with per user preferences we
will be copying completely populated preferences around (at least that's
my guess).
Fixes#940
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The VPM-B benchmark results are all based on nominal/zero conservatism, so we
should make sure we use zero conservatism in the tests.
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If variables were accidentally carried through from a previous calculated plan,
subsequent plan could be affected. This test aims to detect if this happens.
Commit 8994270 corrected such a bug. If it were reverted, this test would fail
(as it should).
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
... as the former was introduced only in Qt 5.5 in order to make the
test build also with 5.4
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We should compare the calculated runtime against the runtime previously
calculated by Subsurface, expecting them to match exactly, in order to detect if
a change has been made. We still compare against a benchmark, allowing some
difference.
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is useful for determining why we calculate a difference profile
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add more VPM-B planner tests. The "expected" total run time is taken as the
total run time produced by the Fortran VPM-B program. For all these tests, the
results are within two minutes, which is a good result, but most are classified
as a "fail".
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a test for 100 m for 60 min dive on trimix using VPM-B
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With these values I reproduce the runtimes from the UI.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This sets up a standard dive scenario (30 minutes at 260ft/79m, EAN36 and
Oxygen as deco gases, last stop at 20ft/6m) and calls the planner to set
up a dive plan given certain standard gases.
Instead of trying to verify the complete plans it checks that we switch to
the deco gases at the right depth and the complete duration of the dive
matches our expectation.
The test intentionally fails right now for imperial as we have the wrong
switch depth for Oxygen. See how useful tests are?
On the downside, the test does NOT produce the same plan as Subsurface
when I try to create a consistent setup for both - and I have not been
able to figure out why. There must be some other parameters that I'm not
setting, but I haven't identified them, yet. It's very small differences,
for example in the metric case the stops at 21m, 9m, and 6m are each one
minute shorter in the test than it what Subsurface calculates.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
