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 <[email protected]> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Reply via email to