Few bugs and a feature req from testing Subsurface

Dirk Hohndel dirk at hohndel.org
Sat Mar 15 13:23:48 PDT 2014


On Sat, 2014-03-15 at 12:41 -0700, Linus Torvalds wrote:
> On Sat, Mar 15, 2014 at 12:26 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> > So here's what I'm proposing to fix the current implementation
> >
> > a) if no default cylinder is set, don't just use AL80. Disable the
> > default cylinder logic
> >
> > b) if a default cylinder is set, ONLY use it for the first cylinder of a
> > DC
> >
> > Linus, will this address your issues?
> 
> Yes, that works for me, and I think is more sensible.

OK, I just pushed out two commits that make these two changes.

>  The whole
> "default cylinder" concept doesn't really make sense if you carry
> multiple cylinders, since even if you do have defaults, they would
> likely not be a single default cylinder (ie a recreational diver might
> have a tiny 3cuft spare-air thing (0.4l cylinder), and a tech diver
> might have a default 40cuft (5.8l) deco bottle).
> 
> So I don't think it ever makes sense to fill in the default for all
> cylinders, unless you make that default cylinder config option be a
> _list_ of cylinders to be used by default.

Let's not even go there.

> >> Anyway, what we probably *should* do (after the two bugs above get
> >> sorted out) is likely to say that when you delete a cylinder, you
> >> delete all gas change events associated with it too. That would give
> >> us a way to fix up the above issue by the user just saying "I really
> >> only had the first cylinder, so delete that bogus second cylinder",
> >> and everything would work out right. But right now, deleting that
> >> second cylinder has bigger problems than "the gas change event
> >> remains".
> >
> > I like this. When I understood what caused the odd situation Miika was
> > seeing I was wondering what to do about it after the fact. This seems
> > like a clean solution.
> 
> Well, there are issues with that model too, and there are more complex
> cases that we simply don't handle well at all.
> 
> For example, a user might decide to "edit" a cylinder by deleting it
> and creating a new one. That sounds like a bad idea ("don't do that
> then"), but it's actually valid in some cases, notably if you want to
> change the order of cylinders, so it's not *entirely* crazy. How would
> we re-associate gases with dive computers and with pressure readings?

This comes back to our strained relationship with cylinders and gases.
It is rather unfortunate that our cylinder switches are modeled as gas
switches. I think it was also Miika who pointed out that you cannot have
two cylinders with the same gas in this scenario (mind you, some dive
computers don't allow that, either. Shearwater Petrel is one of them as
I found out a few weeks ago when I used air in two cylinders during a
training dive (the students had dual 95s, I had dual 46s and needed a
little more air to make sure we didn't have to end the dive early
because of me).

> And with bad gasmix information (which isn't that uncommon, with
> Miika's case as an example) _and_ multiple actual real cylinders, more
> complex cases can happen.

Yes. I think the only way to fix this unholy mess is to really separate
the concept of "which cylinder am I breathing from" from "which gas am I
breathing".

> I've fixed a few cases in my history by just editing things by hand.
> And it's probably special enough that in the end that may be what we
> have to have as a fallback. So the "delete cylinder" approach may work
> for the really simple cases, but they are hopefully the only ones that
> are common enough to worry about.

I don't think we'll be able to come up with a reasonable UI that can
deal with all cases and all the failure cases in a useful manner. I have
many dives with three different gases (one of them trimix) where I took
four dive computers, only two of which do trimix and one of which
supports only one tank. To make matters worse, I have at least one dive
where I had the two stage gases in different order in my two trimix
computers. We do surprisingly well when merging the data from these
dives, but I'm not even sure HOW one could clean this up correctly.

/D



More information about the subsurface mailing list