subsurface Digest, Vol 14, Issue 46
Diego Mainou
Diego.Mainou at alumni.uts.edu.au
Thu Jan 10 14:09:29 PST 2013
Jan,
About the values used on the ostc. I remember discussing on their forum
something about the Buhlmann version of the tables. They are using the last
published tables by Buhlmann which were only published in German.
Sorry I can't give you the full info as I'm overseas reading on the
phone... diving in isla mujeres... near Cancun...
D
On 10/01/2013 2:09 PM, <subsurface-request at hohndel.org> wrote:
> Send subsurface mailing list submissions to
> subsurface at hohndel.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
> or, via email, send a message with subject or body 'help' to
> subsurface-request at hohndel.org
>
> You can reach the person managing the list at
> subsurface-owner at hohndel.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of subsurface digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH] gtk-gui.c: Move the download dialog related code
> to a new file (Linus Torvalds)
> 2. different tissue definiton in OSTC and subsurface (Jan Schubert)
> 3. Re: [PATCH] gtk-gui.c: Move the download dialog related code
> to a new file (Dirk Hohndel)
> 4. wrongly displayed Safetystop (Jan Schubert)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Jan 2013 11:13:59 -0800
> From: Linus Torvalds <torvalds at linux-foundation.org>
> To: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> Cc: Subsurface Mailing List <subsurface at hohndel.org>
> Subject: Re: [PATCH] gtk-gui.c: Move the download dialog related code
> to a new file
> Message-ID:
> <CA+55aFzH0QyZ4r_RfuXoXNjG_UqmEeTG=
> KnjsX+u_sTbB1G_bw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Jan 10, 2013 at 11:02 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
> >
> > gtk-gui.c still has set_dc_nickname(), remember_dc(), etc., which will
> > contribute another 200 LOC or so to a eventual nickname.c.
> > i would personally have it in a separate file, but do as you see fit, i
> > guess.
>
> Having played around with the device stuff, I really *really* hate the
> games the nickname code plays with the system config. I left it alone
> for now, but as a person who works on his dive logs on multiple
> machines (notably my laptop when actually diving, and workstation when
> not), I've grown more and more convinced that the system config is
> horribly wrong. When I get different results on different machines,
> that just makes me angry.
>
> I've had this before (and we've discussed it with Dirk outside the
> mailing list), but the nickname code is even worse - because the
> system config has different rules from the xml quoting, the XML file
> can actually end up containing a different nickname than the system
> config. I could really not be bothered to do the config quoting thing
> for the xml file, it just seemed too ugly for words.
>
> Dirk disagrees about my hatred of system configs, though, and seems to
> want to have machine-wide defaults for some things, and remember dive
> computers across different peoples xml files.
>
> I'd rather get rid of our system config code entirely, and put it all
> into the per-xml file settings. And as a side effect, that would get
> rid of most of the remember_dc and set_dc_nickname stuff.
>
> Linus
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 10 Jan 2013 20:37:08 +0100
> From: Jan Schubert <Jan.Schubert at GMX.li>
> To: Subsurface Mailing List <subsurface at hohndel.org>
> Subject: different tissue definiton in OSTC and subsurface
> Message-ID: <50EF1864.6030101 at GMX.li>
> Content-Type: text/plain; charset=ISO-8859-15
>
> I just stumbled over the fact that the OSTC seems to use different
> definitons for halftime, a and b for N2 and He for the fastest tissue
> (#1) then the definitions in subsurface. Some implementations for
> B?hlmann different between Tissue 1a and 1b, might be that this might be
> a reason, just a guess. Anyway, changig the values to the one used in
> the OSTC and also ignoring the precompiled values for 1sec I do not see
> much difference in the outcome of the calculated deco for my example (as
> in there most likely the slower tissues will lead). Attached is a diff
> for this.
>
> Also I've seen the OSTC defining more conservative values for
> satmult=0.9 (instead of 1.0) and desatmult=1.1 (1.01) which will result
> in much more conservative calculations then we see now so this might
> something which I may got wrong.
>
> Just sharing some stuff I found...
>
> Jan
>
> --
>
> diff --git a/deco.c b/deco.c
> index 0005ba1..0c9af58 100644
> --- a/deco.c
> +++ b/deco.c
> @@ -35,17 +35,17 @@ struct dive_data {
> struct gasmix *gasmix; //! current selected gas
> };
>
> -const double buehlmann_N2_a[] = {1.1696, 1.0, 0.8618, 0.7562,
> +const double buehlmann_N2_a[] = {1.2599, 1.0, 0.8618, 0.7562,
> 0.62, 0.5043, 0.441, 0.4,
> 0.375, 0.35, 0.3295, 0.3065,
> 0.2835, 0.261, 0.248, 0.2327};
>
> -const double buehlmann_N2_b[] = {0.5578, 0.6514, 0.7222, 0.7825,
> +const double buehlmann_N2_b[] = {0.5050, 0.6514, 0.7222, 0.7825,
> 0.8126, 0.8434, 0.8693, 0.8910,
> 0.9092, 0.9222, 0.9319, 0.9403,
> 0.9477, 0.9544, 0.9602, 0.9653};
>
> -const double buehlmann_N2_t_halflife[] = {5.0, 8.0, 12.5, 18.5,
> +const double buehlmann_N2_t_halflife[] = {4.0, 8.0, 12.5, 18.5,
> 27.0, 38.3, 54.3, 77.0,
> 109.0, 146.0, 187.0, 239.0,
> 305.0, 390.0, 498.0, 635.0};
> @@ -56,17 +56,17 @@ const double
> buehlmann_N2_factor_expositon_one_second[] = {
> 1.05980191127841E-004, 7.91232600646508E-005,
> 6.17759153688224E-005, 4.83354552742732E-005,
> 3.78761777920511E-005, 2.96212356654113E-005,
> 2.31974277413727E-005, 1.81926738960225E-005};
>
> -const double buehlmann_He_a[] = { 1.6189, 1.383 , 1.1919, 1.0458,
> +const double buehlmann_He_a[] = { 1.7424, 1.383 , 1.1919, 1.0458,
> 0.922 , 0.8205, 0.7305, 0.6502,
> 0.595 , 0.5545, 0.5333, 0.5189,
> 0.5181, 0.5176, 0.5172, 0.5119};
>
> -const double buehlmann_He_b[] = {0.4770, 0.5747, 0.6527, 0.7223,
> +const double buehlmann_He_b[] = {0.4245, 0.5747, 0.6527, 0.7223,
> 0.7582, 0.7957, 0.8279, 0.8553,
> 0.8757, 0.8903, 0.8997, 0.9073,
> 0.9122, 0.9171, 0.9217, 0.9267};
>
> -const double buehlmann_He_t_halflife[] = {1.88, 3.02, 4.72, 6.99,
> +const double buehlmann_He_t_halflife[] = {1.51, 3.02, 4.72, 6.99,
> 10.21, 14.48, 20.53, 29.11,
> 41.20, 55.19, 70.69, 90.34,
> 115.29, 147.42, 188.24, 240.03};
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 10 Jan 2013 12:06:48 -0800 (PST)
> From: Dirk Hohndel <dirk at hohndel.org>
> To: Linus Torvalds <torvalds at linux-foundation.org>, "Lubomir I.
> Ivanov" <neolit123 at gmail.com>
> Cc: Subsurface Mailing List <subsurface at hohndel.org>
> Subject: Re: [PATCH] gtk-gui.c: Move the download dialog related code
> to a new file
> Message-ID: <20130110120648.839853.FMU5557 at air.gr8dns.org>
> Content-Type: text/plain
>
> Linus Torvalds <torvalds at linux-foundation.org> writes:
>
> > On Thu, Jan 10, 2013 at 11:02 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
> wrote:
> >>
> >> gtk-gui.c still has set_dc_nickname(), remember_dc(), etc., which will
> >> contribute another 200 LOC or so to a eventual nickname.c.
> >> i would personally have it in a separate file, but do as you see fit, i
> >> guess.
> >
> > Having played around with the device stuff, I really *really* hate the
> > games the nickname code plays with the system config. I left it alone
> > for now, but as a person who works on his dive logs on multiple
> > machines (notably my laptop when actually diving, and workstation when
> > not), I've grown more and more convinced that the system config is
> > horribly wrong. When I get different results on different machines,
> > that just makes me angry.
>
> The problem is that while you are a user of Subsurface I don't think you
> are the typical user. Most people will use Subsurface on one system with
> one (or a few) local XML files on that system.
>
> I think the number of people who have a remote git server on which they
> have their divelog XML file and connect to that git server from numerous
> clients to then use a local installation of Subsurface against the local
> copy of that remote XML file is... two (you and me).
>
> So while I completely understand and comiserate with your anger - I
> don't think I am willing to make changes that create a worse experience
> for N-2 users only to create a better one for 2.
>
> And even if 2 is wrong and there are a few dozen people like us - I
> still think the vast majority of users DON'T use it like that.
>
> > I've had this before (and we've discussed it with Dirk outside the
> > mailing list), but the nickname code is even worse - because the
> > system config has different rules from the xml quoting, the XML file
> > can actually end up containing a different nickname than the system
> > config. I could really not be bothered to do the config quoting thing
> > for the xml file, it just seemed too ugly for words.
>
> Yes, the quoting difference is stupid and annoying. Thankfully few
> people think that adding commas or curly braces to their device names
> provides significant value. I certainly didn't feel it was useful enough
> to add additional encoding code to the config code.
>
> But let me be very clear here - that code is hacky shit that should be
> replaced with something much cleaner and more robust. It just happens to
> work for me and in my limited time to work on Subsurface I preferred to
> implement new things (like deco or the dive planner) instead of getting
> the config code perfect.
>
> mea culpa.
>
> > Dirk disagrees about my hatred of system configs, though, and seems to
> > want to have machine-wide defaults for some things, and remember dive
> > computers across different peoples xml files.
>
> Yes. I think for most people the use case works kind of like this
>
> one system on which they run Subsurface
> one main XML file that is their dive log
> occasional other XML files if they want to test something or work with a
> subset of their dives
>
> Not having a system config means that if you use a file other than your
> main XML file, all your settings are gone (and oh, btw - at least the
> name of the default XML file name has to go into the system
> config... you're in a catch22 otherwise).
>
> To me getting different columns shown, different deco parameters,
> different pO2 warning levels, etc, just because I use a different XML
> file is just plain wrong and a SHITTY user experience. And if I were the
> one proposing and implementing that and you for the first time opened an
> empty file and suddenly got a different user experience you'd be yelling
> your head off about the stupid brainless moron who pulled that piece of
> shit code out of his ass. (I hope this was an adequate approximation of
> what you would say. If it was too soft spoken, I apologize - I'm not
> used to acting like this in public)
>
> > I'd rather get rid of our system config code entirely, and put it all
> > into the per-xml file settings. And as a side effect, that would get
> > rid of most of the remember_dc and set_dc_nickname stuff.
>
> Yes it would. It would also get rid of a big chunk of the useability
> improvements that we have made (e.g., default XML file) and would mean
> that opening a different XML file means all the user's settings are
> gone. That is not an acceptable trade-off to me.
>
> Now we can, of course, talk about a different solution. Instead of
> storing everything in the system config store only two file names there:
> the default divelog XML file and the default settings XML file. And move
> all other settings into the settings XML file, which you can share via
> git (or not, if you prefer to have random default settings when starting
> with an empty XML file). The amount of code required to do that would
> actually be fairly small and it would create the same user experience
> for Joe User (assuming we do this right) and would allow you to get your
> very special "but Linus is different" feature. And heck, if I am wrong
> and it is actually 20% of our users that behave like you then this is an
> even bigger plus.
>
> What do you think, would that address your issue?
>
> Of course, the next question then becomes "what are the precedence rules
> between the settings in the divelog file and the settings in the
> settings file?" (my guess is the divelog file wins) and "when are things
> stored in the settings file?" (they clearly are always stored in the
> divelog file).
>
> /D
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 10 Jan 2013 21:09:14 +0100
> From: Jan Schubert <Jan.Schubert at GMX.li>
> To: Subsurface Mailing List <subsurface at hohndel.org>
> Subject: wrongly displayed Safetystop
> Message-ID: <50EF1FEA.8010402 at GMX.li>
> Content-Type: text/plain; charset="iso-8859-15"
>
> In all of my profiles from OSTC and Predator I get a Safetystop
> displayed in the mouse over dialog after the official deco is finished
> until surfacing. The stop seems to be displayed regardless if the
> calculated deco is finished or not but only seems to be there in cases
> there is deco calculated. Funny enough, in some cases it also seems to
> be there before a deco got calculated, I did not find any specific
> pattern so far.
>
> Tracking down I found that the there is even an entry for "stoptime" in
> the XML, so the GUI is correct, but I've no idea where this is coming from.
>
> The safety stop should not be there and there is not even such a thing
> like safety stop implemented in the Predator. Any ideas?
>
> Find an example dive attached.
>
> HTH,
> Jan
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: safetystop.xml
> Type: text/xml
> Size: 30214 bytes
> Desc: not available
> URL: <
> http://lists.hohndel.org/pipermail/subsurface/attachments/20130110/4b478d38/attachment.xml
> >
>
> ------------------------------
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
> End of subsurface Digest, Vol 14, Issue 46
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130110/5a25b1a6/attachment-0001.html>
More information about the subsurface
mailing list