New Bug Reports/Feature Requests

Robert Helling helling at atdotde.de
Tue Feb 23 12:32:16 PST 2016


Richard,

thanks a lot for all your reports/suggestions. I believe I cannot help for many of these but here are some comments:

> On 23.02.2016, at 19:55, Richard Houser <rick at divinesymphony.net> wrote:
> 
> First off, I'd just like to say I thin Subsurface is an amazing piece of software and far superior to the proprietary crap manufacturers push out (kodos to you all), so please don't interpret this as a rant by any means. I would have submitted these tickets directly, but the email verification message still isn't coming through from the bug tracker.  If someone was to "validate" this same email that was already confirmed via the mailing list, I could submit these as tickets directly myself....
> 
> 
> Anyhow, here they are...
> 
> 
> #1 Using 4.5.3 AppImage, I located a segfault on exporting to divelogs.de <http://divelogs.de/>.
> 
> Sequence:
> (a) I imported a dive from my computer and then added a location
> (b) I realized I added that location to the wrong dive and removed it, then saved
> (c) any divelogs.de <http://divelogs.de/> export containing that dive causes a segfault
> 
> Looking through the XML (which I no longer have - sorry!), it looked like the dive was still associated to a location in the top of the xml, but that entry had no location text.  Shutting down subsurface, deleting that particular id attribute on the dive and then restarting the application let me complete the export.  I would think the correct behavior when someone removes the location text from then Notes tab and saves would be to automatically remove the association with that site entirely.

I was not able to reproduce that here on my Mac.

> #2 The imperial tank sizes appear to have some issues going back to at least 4.4.2....
> 
> It looks like someone used to metric tanks may have just taken the names of the cylinders and assumed that matched the capacity?  Sadly our stuff doesn't work that way :(.
> 
> AL80 in particular stood out.  Despite the name, these are ~77.4cuft capacity when filled to working pressure of 3000.  It would be nice if we could get a tenth position added for precision, but the big problem is the bad default.  I have to edit each and every dive after selecting AL80 at present.
> 
> The steel tanks seem to have a similar problem, but a subset of the more common sizes just happen to match up.  For example, my Faber XS-120 is close enough to 120 to look like a round off error.  However, things like the HP119 are significantly off.  This should give you a good idea what I'm talking about: (ex.): http://www.xsscuba.com/tank_steel_specs.html <http://www.xsscuba.com/tank_steel_specs.html>
> 
> Older tanks might be a bit more complicated, but at least LP72s (6.9") are still pretty common.  I have one and it's rated at 65cuft at 2250 working pressure - (when over-filled by 10% as allowed by hydro + rating that only some hydro facilities will check and stamped, that gets you up to 71cuft).  The default values listed seem to be 2466 psi, which I don't see a reference to anywhere, although it's close to an overfill rating it probably won't trash SAC calculations, but it's still a bit off.  It's definitely not the stamped rated pressure, though.

Let me quote from our source code:

        /* Most common AL cylinders */
        { "AL40", .cuft = 40, .psi = 3000 },
        { "AL50", .cuft = 50, .psi = 3000 },
        { "AL63", .cuft = 63, .psi = 3000 },
        { "AL72", .cuft = 72, .psi = 3000 },
        { "AL80", .cuft = 80, .psi = 3000 },
        { "AL100", .cuft = 100, .psi = 3300 },

        /* Metric AL cylinders */
        { "ALU7", .ml = 7000, .bar = 200 },

        /* Somewhat common LP steel cylinders */
        { "LP85", .cuft = 85, .psi = 2640 },
        { "LP95", .cuft = 95, .psi = 2640 },
        { "LP108", .cuft = 108, .psi = 2640 },
        { "LP121", .cuft = 121, .psi = 2640 },

        /* Somewhat common HP steel cylinders */
        { "HP65", .cuft = 65, .psi = 3442 },
        { "HP80", .cuft = 80, .psi = 3442 },
        { "HP100", .cuft = 100, .psi = 3442 },
        { "HP119", .cuft = 119, .psi = 3442 },
        { "HP130", .cuft = 130, .psi = 3442 },

As you see, we indeed use the nominal sizes even though they are not exact. We had a discussion in the past (but I am not able to find it either in the mailing list archives or trac) if we should use the „real“ values as shown on that web page but ended up the conclusion that that would actually be even more confusing.

> Adding full/empty buoyancy stats to the cylinder page would be really useful, IMO, as we can't always control what we get with rental tanks.  I was on HP100s one day, AL80s the next, etc.

The weight of the metal changes at least for different manufacturers so unless you weight your cylinder, which value are you going to use? The weight of the gas is of course always the same.

> #3 When I'm editing the cylinder sizes (and I assume all over the place elsewhere), I have to enter the tank type, then select the volume, then make the change, then click off somewhere else unrelated, then save.  If I leave off that second to last step, then save, it reverts to the old value.  I think that when a save is attempted, the equivalent field save action of clicking out should be done automatically in the background so the last change is not lost.

A field is only changed when the keyboard focus leaves it (changing it with every keystroke would have strange side effects as you would end up with strange values in the middle of typing a number). But you can for example use the TAB key if you don’t want to change to the mouse.

> #4 Dives exported from subsurface to divelogs.de <http://divelogs.de/> are now showing an additional 0.1lb more than what they show in subsurface.  My dives as of early September on 4.4.2 (from Mageia cauldron) are correct, but all dives I have done this February on 4.5.3 have the extra 0.1lb.  I'm guessing this subsurface is a regression post 4.4.2, but if it's not obvious, I could back things up after this trip, delete them from divelogs.de <http://divelogs.de/> and see what happens between those two different versions.
> 

My guess is that this is a rounding error: divelogs.de uses metric units internally so converting from imperial to metric and back could change the least significant digit.

> #5 Feature Request: Any chance of getting a boat field added?
> 
> I'm looking for something like we have for Buddy and Divemaster.  Captain (in some areas, they bounce around a lot between organizations) or dive operation/charter organization might be useful too.
> 

You can of course always enter what you like in the notes field. Alternatively use one of the existing fields for this (I for example never use the dive master field so I could use that for boat information if I wanted). The UI is already quite crowded so I think it is unlikely that we will add further fields lightly.

> #6 Feature Request: Any chance of getting a SAC graph option?
> 
> I think it would be useful to see where breathing went up, in particular paired with other events there, like timestamped photos and other trackable events.  In particular, on one of my recent dives, I added about 25-30lb of weight on the bottom.  It would be nice to see how much something like that acquisition or chasing an elusive lobster actually cost me in bottom time.

Do you realize that the color of the depth graph is already a representation of the momentary SAC? Given the resolution of the pressure sensor I guess it would make little sense to present finer granularity than a color coding (there is only very limited numerical precision).

Best
Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160223/133cd936/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160223/133cd936/attachment.sig>


More information about the subsurface mailing list