Am 24.02.16 um 07:42 schrieb Dirk Hohndel:
On Wed, Feb 24, 2016 at 08:10:04AM +0200, Miika Turkia wrote:
On Wed, Feb 24, 2016 at 12:52 AM, Dirk Hohndel wrote:
On Tue, Feb 23, 2016 at 01:55:28PM -0500, Richard Houser wrote:
#4 Dives exported from subsurface to divelogs.de are now showing an
ad
I completely agree that the metric to imperial tank measurement conversions
suck, but I think there may be more to it than just the compressibility and
temperature aspects. The Luxfer cylinder site seems to have been down about two
weeks, but the third-party references I can find in the online t
My id there is DiverMidMi, so feel free to look at the whole logbook. All my
logs before this February display the values I see in Subsurface. Those were
initially entered in 4.4.2. The new dives from this month show the excess
weight. I can supply the actual Subsurface xml entries after I g
OK, found the uploaded DLD file.
This dive: https://en.divelogs.de/dive/1659944
has 9.1in the XML
So converting this to lbs: Divide by 0.4536 gives me 20.06 lbs, which is
diplayed as 20.1 lbs (I do round to one digit for displaying).
So now the question is: At which point did the 9.1 get its va
I think I see the bug in XSLT transform, naturally hidden in common
templates and not on the actual file doing the conversion to
divelogs.de format. Looks like using only one decimal has been there
from the beginning. Makes me wonder if Richard has just been lucky
with an earlier version of Subsurf
Thank you for the prompt investigation.
I would be happy to test this whenever you are ready (or you could use my
subsurface div XML), but I've had some trouble trying to build 4.5.3. I might
need an AppImage to do so.
On February 24, 2016 8:49:31 AM EST, Miika Turkia
wrote:
>I think I see t
Signed-off-by: Miika Turkia
---
xslt/commonTemplates.xsl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xslt/commonTemplates.xsl b/xslt/commonTemplates.xsl
index 86f9cda..15c8686 100644
--- a/xslt/commonTemplates.xsl
+++ b/xslt/commonTemplates.xsl
@@ -127,7 +127,7 @@
We use random numbers for file names, both temporary filename when
creating a zip for divelogs.de upload and for filename on form data for
facebook upload. This does not require for true randomness but we still
want these to not be constant on each run of Subsurface. Thus we need to
initialize the
On 24 February 2016 at 09:18, Linus Torvalds
wrote:
> On Feb 23, 2016 15:46, "Linus Torvalds" wrote:
>>
>
>> (b) air is not actually entirely compressible.
>>
>> This is a fairly small factor at 3000psi, but it's a factor.
>> HOWEVER. The rule for cylinder sizing is that the stated cylinder
On 24 February 2016 at 16:56, Lubomir I. Ivanov wrote:
> On 24 February 2016 at 09:18, Linus Torvalds
>
> for the given data set i found the following polynomial regressions,
> which should be OK interpolants due to the fact the data set exhibits
> hyperbolic behaviour.
*parabolic
lubomir
--
___
On Wed, Feb 24, 2016 at 2:01 AM, Richard Houser wrote:
>
> As an imperial tank user, it's just really confusing to have Subsurface
> reporting different cuft values than the tanks I'm using, even if the
> underlying conversion calculations are correct.
I don't understand. If you are using an AL80
Hi,
> On 24.02.2016, at 08:28, Dirk Hohndel wrote:
>
> Robert is the usual suspect for stuff like this :-)
and in fact, Robert is looking into this issue. He decided to get the physics
(somewhat) right by using a van der Waals (or related) equation rather than a
random fit function but still
On Wed, Feb 24, 2016 at 12:15 PM, Robert Helling wrote:
>
> and in fact, Robert is looking into this issue. He decided to get the
> physics (somewhat) right by using a van der Waals (or related) equation
> rather than a random fit function but still has to do a bit of math before a
> patch is comi
This is a lot more questionable than my previous set of patches (the
pressure interpolation round), but let's see if people see any issues with
it.
The first patch in the series doesn't actually change anything, it just
makes sure a function that will be changed is private, and removes another
From: Linus Torvalds
Date: Wed, 24 Feb 2016 11:08:50 -0800
Subject: [PATCH 1/3] gas pressures: do some initial cleanup
This marks "surface_volume_multiplier()" static in preparation for
changing it to use an actual honest-to-goodness compressibility
estimation. Without that, it wasn't obvious t
From: Linus Torvalds
Date: Wed, 24 Feb 2016 11:31:03 -0800
Subject: [PATCH 2/3] gas pressures: do not use gas compressibility for cylinder
naming
This actually didn't make a difference for the common case, since our
simplified gas compressibility model had a compressibility factor of 1.0
up to
From: Linus Torvalds
Date: Wed, 24 Feb 2016 12:14:53 -0800
Subject: [PATCH 3/3] gas pressures: use an actual compressibility table for air
We could in theory make this dependent on the gasmix, but for now let's
just assume (incorrectly) that everything we breathe acts like air.
Signed-off-by: L
Dear Subsurface (mobile) team,
about two weeks ago, Marco came to the VDG (KDE's design group) asking for a
new name for Plasma Mobile Components.
The reasoning behind this request was that with them becoming their own KDE
framework and Subsurface mobile showing that they work very well outside
On Wed, Feb 24, 2016 at 11:47 AM, Linus Torvalds
wrote:
>
> So you can add your *specific* cylinder type by editing the tank info
> details completely. You should be able to (for example), specify your
> cylinder by editing the cylinder information to be (take a Worthington
> HP119 as an example):
This is a seprate series of patches (it's on top of my first series in my
tree, but I think it would apply independently) that came out of me
looking at our cylinder size handling.
In particular, it came out of me noticing:
"If you pick an existing type without work-pressure (eg a 10 l metric
From: Linus Torvalds
Date: Wed, 24 Feb 2016 14:42:56 -0800
Subject: [PATCH 1/2] Don't use "get_volume_string()" for cylinder size string
We had two totally different usage cases for "get_volume_string()": one
that did the obvious "show this volume as a string", and one that tried
to show a cylin
From: Linus Torvalds
Date: Wed, 24 Feb 2016 14:51:21 -0800
Subject: [PATCH 2/2] Show both the nominal and "real" size for an imperial
cylinder
This is questionable, but perhaps useful.
When showing imperial cylinder sizes, show both the nominal value (with
no compensation for compressibility o
On Wed, Feb 24, 2016 at 01:28:06PM -0800, Linus Torvalds wrote:
> - double bar = pressure.mbar / 1000.0;
> +#define ARRAY_SIZE(array) (sizeof(array)/sizeof(array[0]))
> +double gas_compressibility_factor(struct gasmix *gas, double bar)
> +{
> + static const struct z_factor {
> +
On Wed, Feb 24, 2016 at 01:26:30PM -0800, Linus Torvalds wrote:
>
> The first patch in the series doesn't actually change anything, it just
> makes sure a function that will be changed is private, and removes another
> one that isn't actually used and is questionable to begin with. So that
> pa
On Wed, Feb 24, 2016 at 03:00:41PM -0800, Linus Torvalds wrote:
>
> This is a seprate series of patches (it's on top of my first series in my
> tree, but I think it would apply independently) that came out of me
> looking at our cylinder size handling.
>
> In particular, it came out of me notic
On Feb 24, 2016 15:43, "Dirk Hohndel" wrote:
>
> But this bothers me. from 60 to 80 to 100 bar the z_factor goes UP!
> That just seems wrong. Maybe there's something in the physics that I don't
> get that makes this a magic range, but still... this at least needs an
> explanation.
I have no idea
On Wed, Feb 24, 2016 at 03:58:41PM -0800, Linus Torvalds wrote:
> On Feb 24, 2016 15:43, "Dirk Hohndel" wrote:
> >
> > But this bothers me. from 60 to 80 to 100 bar the z_factor goes UP!
> > That just seems wrong. Maybe there's something in the physics that I don't
> > get that makes this a magic
On Feb 24, 2016 15:58, "Linus Torvalds"
wrote:
>
> I have no idea of what the physical explanation is, but if you look at the
> compressibility graphs it turns out to not even be hugely unusual. To use
> a highly technical term, they are some "funky shit".
Looking into it a bit more, it looks lik
When you are looking into the tank editing, would you please try a couple tanks
completely from the imperial specs we get from the manufacturers spec sheets?
When I'm shopping for this stuff, I don't typically see water volume
measurements.
Examples:
Luxfer AL80 77.4cuft 3000psi (from manufac
On Wed, Feb 24, 2016 at 5:20 PM, Richard Houser wrote:
> When you are looking into the tank editing, would you please try a couple
> tanks completely from the imperial specs we get from the manufacturers spec
> sheets?
I don't think that's reasonable, outside of some specialized cylinder
model ed
30 matches
Mail list logo
