| Age | Commit message (Collapse) | Author |
|---|
|
On Tue, Feb 26, 2013 at 6:19 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
> Miika Turkia <miika.turkia@gmail.com> writes:
>
>> On Tue, Feb 26, 2013 at 5:54 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
>>> Miika Turkia <miika.turkia@gmail.com> writes:
>>>
>>>> On Tue, Feb 26, 2013 at 6:45 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
>>>>> I added a few test dives exported from other software (Dm3, DiveLog 5.08,
>>>>> JDiveLog 10.2 from Mac - last one doesn't parse because of encoding... Also
>>>>> a composed XML zip file from DiveLog isn't supported, yet)
>>>>> Find them under dives
>>>>
>>>> Now this gets interesting. Is there ANY logic in the units in the
>>>> dives/TestDiveDiveLog5.08.xml? It seems that some of the temperatures
>>>> are in C (Airtemp and Watertemp) and some in F (samples). Otherwise I
>>>> would guess we are talking metric here, but I do not see any specs
>>>> (another log I have seen from DivingLog had all the units in metric,
>>>> as far as I could guess). BTW is the Weight in kg or lb?
>>>
>>> I have purchased DivingLog and should be able to create any combination
>>> of data for the test file that we could possibly want. I'll do a set in
>>> a moment that describe what SHOULD be there in their notes, maybe that
>>> will clear things up.
>>>
>>> That said, I really want to release 3.0.1 in the next couple of hours,
>>> so this may have to wait for 3.0.2 (if we end up needing that) or 3.1.
>>>
>>>> The divelogs.de UDCF format looks like it shouldn't take long to write
>>>> support for. I'll look into it this evening.
>>>
>>> It is evening for you, right? No pressure, just making sure I understand
>>> what may be coming in in patches in the next hour or two
>>
>> I currently have one version of the DivingLog XSLT. So a bit of
>> verification and that could possibly be used as is. However, this
>> could use a bit more testing than a new support to make sure things
>> are not going to be any worse than they currently are.
>>
>> I have not started with the UDCF yet, but that could be reasonably
>> fast to implement. However, no guarantees. (And yes, it is evening for
>> me)
>
> I can hold off 3.0.1 a couple hours longer if that is a realistic thing
> to do. I don't see the UDCF as that important since we have a different
> format from them that we support. So I think the best possible DivingLog
> support would be my preference.
>
> I'll add a few more exported dives from DivingLog next (and fix the
> naming of the existing ones).
In that case, here is the DivingLog XSLT if anyone can give it a test.
miika
From 4a62058f4f6fd4780f04bce6e1fe45e20abcf33f Mon Sep 17 00:00:00 2001
From: Miika Turkia <miika.turkia@gmail.com>
Date: Tue, 26 Feb 2013 17:46:53 +0200
Subject: [PATCH] XSLT for DivingLog
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Two XML files, one all imperial, one all metric
Quick inspection shows that there is no indication whatsoever on metric vs
imperial in the file. That is of course completely moronic and makes
automated import more or less impossible.
I also added a different zip file from DivingLog - quick analysis shows
that this is simply the corresponding xml file, wrapped in a zip
container. So this should be trivial to add.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
The DLD is imported perfectly, the udcf is not.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Suuntu DM3
DiveLog 5.08 XML
DiveLog 5.08 UDDF
DiveLog 5.08 UDCF
DiveLog 5.08 compressed zip (we don't support that)
JDiveLig 10.2 from Mac (fails because of ecoding)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
We computed a made-up average depth based on the maximum depth, and used
that. That's questionable even if we didn't have any explicit average
depth to begin with, but it's particularly wrong if we did have an
explicit average depth to use.
Now, admittedly we have no way to actually create fake dives like this
with a particular average depth, so this really doesn't make any
difference in real life. But we should do this right.
Also, make the XML be in the format that subsurface actually saves
things in (mainly things like cylinder sizes having an extra decimal
place, but also ordering of XML elements).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
This assumes that you are not breathing your cylinders while at the
surface, which may or may not be correct, but is usually the right
thing. Regardless, we're better off giving a conservative (higher) SAC
rate estimate for a diver that breathes his cylinder at the surface too
than giving an artificially low one because the diver ended up using his
snorkel and we didn't take that into account.
NOTE! This basically calculates a better duration and average depth than
the ones we end up showing in the dive list. Maybe we should actually
show this "no-surface-time" duration and average depth instead of the
ones we do show?
That's a separate question, though.
Added a test-case for the surface case to the sac-test.xml dives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
We even documented that we did SAC in bar*l/min, but the "S" in SAC
stands for "Surface". So we should normalize SAC rate to surface
pressure, not one bar.
It's a tiny 1% difference, and doesn't actually matter in practice, but
it's noticeable when you want to explicitly test for SAC-rate by
creating a test-dive that averages exactly 10m. Suddenly you don't get
the round numbers you expect.
[ Side note: 10m is not _exactly_ one extra atmosphere according to our
calculations, but it's darn close in sea water: the standard salinity
of 1.03 kg/l together with the standard acceleration of 9.81m/s^2
gives an additional pressure of 1.01 bar, which is within a fraction
of a percent of one ATM.
Of course, divers have likely chosen that value exactly for the math
to come out that way, since the true average salinity of seawater is
actually slightly lower ]
So here's a few test-dives, along with the SAC rate fixup to make them
look right.
(There's also a one-liner to dive.c that makes the duration come out
right if the last sample has a non-zero depth, and the previous sample
did not: one of my original test-dives did the "average 10m depth" by
starting at 0 and ending at 20m, and dive.c got a tiny bit confused
about that ;)
[ The rationale for me testing our SAC rate calculations in the first
place was that on snorkkeli.net user "Poltsi" reported that our SAC rate
calculations differ from the ones that Suunto DM4 reports. So I wanted
to verify that we did things right.
Note that Poltsi reported differences larger than the difference of
BAR/ATM, so this is not the cause. I'll continue to look at this. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Making sure that this doesn't cause divisions by zero and that the scaling
and positioning doesn't get messed up by it (right now it doesn't look
great).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
With Pierre-Yves' commit with a map widget, here are a couple of example
GPS locations from my own dives.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Loading these two XML files created a divelist with two trips that each
started at the same time but that were NOT linked together (because the
code in insert_trip detected that they started at the same time). Since
the trips were not linked together, trying to then merge those two trips
from the UI got us into an infinite loop, trying to move a dive from one
trip into the same trip (as the code couldn't find the trip that wasn't
linked into the dive_trip_list).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Previously we could end up with a bogus dive with all zero data in it.
Adding dives/test24.xml to be able to test that we handle this case
correctly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
They still had the old "date only" format, but the code now relies on date
and time being both set.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Playing with these shows that there are still some issues with handling
multiple files correctly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
This allows us to check what we display in the dive list and how we sort
it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
...and never commited
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
I thought we had fixed this before - but I guess it got broken again
somewhere. We now make sure that the plot_info ends on an entry with
depth 0.
Added test14 to verify the fix.
Also fixed cut'n'paste errors in a few test dive files.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
In some situations we could end up with no sample pressure and no
interpolated pressure at time = 0. This is now fixed.
Fix notes in test dive the exposed the issue.
Also change the code in create_plot_info to keep the number of samples and
the number of corresponding pi entries in separate variables. This avoids
future changes from breaking if they assume they can access
dive->sample[nr_samples - 1] (which is a reasonable assumption to make).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
The notes now reflect things that were fixed in the last commits.
Also added more test dives to test other boundary cases.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
As much as Linus' dives may be fun to look at, they don't help us test the
app. Writing these test dives I already found a couple of bugs - and I'm
just getting started.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
They had multiple "root" entries (all called 'dive'), which makes baby
Jesus cry.
So just enclose them all in one root entry (called 'dives') that
magically turns it all into parseable xml.
Yeah, that really helps make the world a better place.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
(and add a reminder of how they came to be)
Gaah. XML is *stupid*. It's not easy to parse for humans or for
computers, and some of these XML files are just disgusting. But maybe
they can be turned into something usable with libxml.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
Miika Turkia
Dirk Hohndel
Linus Torvalds
Henrik Brautaset Aronsen