Re: Crash when planning CCR dive
Sure, I'll give it a go and get back to you. It'll have to be after work though.
Paul
On 15 Dec 2014 08:25, Robert C. Helling hell...@atdotde.de wrote:Paul,unless I hear otherwise I would currently assume this issue is there for your binary/your build only. Could you make sure you are indeed building the latest master and nothing else? Perhaps do a make distclean and git reset —hard origin/master first and then start again with make.On 14.12.2014, at 15:39, Paul Sargent paul.lionseye@icloud.com wrote:This is on the current head (9fe458ea2e30), running on Mac OS 10.10.1.What I did was:# make clean# qmake INCLUDEPATH=/usr/local/include /usr/local/Cellar/sqlite/3.8.7.1/include LIBS=-L/usr/local/Cellar/sqlite/3.8.7.1/lib -L/usr/local/lib -config debug# make# open Subsurface.appBTW, in my Mac build directories, I created a soft link subsurface - Subsurface.app/Contents/MacOS/Subsurface so I can run the binary as./subsurfacewhich gives me STDOUT/STDERR on the terminal (which opening the Subsurface.app doesn’t). The disadvantage is that this runs it without an icon and the window opens in the back rather than in the front.Attaching the debugger gave:* thread #1: tid = 0x7eef0, 0x0001084e41c3 subsurfacefill_missing_tank_pressures(dive=0x00038a4008774e80, pi=0x7fff5774eef8, track_pr=0x7fff5774ec20, o2_flag=false) 675 at gaspressures.c:301, queue = com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x0001084e41c3 subsurfacefill_missing_tank_pressures(dive=0x00038a4008774e80, pi=0x7fff5774eef8, track_pr=0x7fff5774ec20, o2_flag=false) 675 at gaspressures.c:301 298 299 // If there is a valid segment but no tank pressure .. 300 interpolate = get_pr_interpolate_data(segment, pi, i, pressure); // Set up an interpolation structure- 301 if(dive-cylinder[cyl].cylinder_use == OC_GAS) { 302 303 /* if this segment has pressure_time, then calculate a new interpolated pressure */ 304 if (interpolate.pressure_time) {(lldb) p cyl(int) $0 = -1Hmm, unless this is originating from uninitialized memory, a cylinder number -1 could only come from dive-oxygen_cylinder_index (or the corresponding function get_cylinder_idx_by_use() if no oxygen cylinder is defined. In the place you quote, however, since commit 13934b0f this should have been caught a few lines above. Are you sure you have that commit?BestRobert___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Crash when planning CCR dive
On 14 Dec 2014, at 22:38, Davide DB dbdav...@gmail.com wrote: How I start with a blank dive? I see that the panner initialize itself with data from the current dive. How to start from scratch without using a new logbook? I am running without any other dives in the system. Starting Subsurface doesn’t load any dives automatically for me. I think that’s because I don’t save my dives in the default location as I have them in a synced folder across machines. Paul ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Crash when planning CCR dive
This is on the current head (9fe458ea2e30), running on Mac OS 10.10.1.
What I did was:
# make clean
# qmake INCLUDEPATH+=/usr/local/include
/usr/local/Cellar/sqlite/3.8.7.1/include
LIBS+=-L/usr/local/Cellar/sqlite/3.8.7.1/lib -L/usr/local/lib -config debug
# make
# open Subsurface.app
and then:
Log - Plan Dive
Enter a single gas of 18/45
Enter a single segment of 70m for 30mins (Drop to first depth is on)
Change segment setpoint to 1.3
Crashes every time. There’s a backtrace at bottom of this mail, along with a
screenshot showing the screen prior to changing the set-point.
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 org.hohndel.subsurface 0x00010b8841c3
fill_missing_tank_pressures + 675
1 org.hohndel.subsurface 0x00010b883d5d
populate_pressure_information + 685
2 org.hohndel.subsurface 0x00010b8810e0 create_plot_info_new
+ 224
3 org.hohndel.subsurface 0x00010b96b5ac
ProfileWidget2::plotDive(dive*, bool) + 828
4 org.hohndel.subsurface 0x00010b96b268
ProfileWidget2::replot() + 56
5 org.hohndel.subsurface 0x00010b9ebb7e
ProfileWidget2::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) +
446
6 QtCore 0x00010ee19d71
QMetaObject::activate(QObject*, QMetaObject const*, int, void**) + 2037
7 QtCore 0x00010ee5ae95
QAbstractItemModel::dataChanged(QModelIndex const, QModelIndex const) + 57
8 org.hohndel.subsurface 0x00010b8b3d51
DivePlannerPointsModel::editStop(int, divedatapoint) + 385
9 org.hohndel.subsurface 0x00010b8b3b8c
DivePlannerPointsModel::setData(QModelIndex const, QVariant const, int) + 860
Attaching the debugger gave:
* thread #1: tid = 0x7eef0, 0x0001084e41c3
subsurface`fill_missing_tank_pressures(dive=0x00038a4008774e80,
pi=0x7fff5774eef8, track_pr=0x7fff5774ec20, o2_flag=false) + 675 at
gaspressures.c:301, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x0001084e41c3
subsurface`fill_missing_tank_pressures(dive=0x00038a4008774e80,
pi=0x7fff5774eef8, track_pr=0x7fff5774ec20, o2_flag=false) + 675 at
gaspressures.c:301
298
299 // If there is a valid segment but no tank pressure ..
300 interpolate = get_pr_interpolate_data(segment, pi, i,
pressure); // Set up an interpolation structure
- 301 if(dive-cylinder[cyl].cylinder_use == OC_GAS) {
302
303 /* if this segment has pressure_time, then
calculate a new interpolated pressure */
304 if (interpolate.pressure_time) {
(lldb) p cyl
(int) $0 = -1___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Crash when planning CCR dive
On 14 Dec 2014, at 14:39, Paul Sargent paul.lions...@icloud.com wrote: Crashes every time. There’s a backtrace at bottom of this mail, along with a screenshot showing the screen prior to changing the set-point. Whoops, I forgot the screen shot. Bit big for mail, so I posted it. http://imgur.com/r8ChZAN http://imgur.com/r8ChZAN ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Support different salinity in planner
On 15 Nov 2014, at 11:01, Henrik Brautaset Aronsen subsurf...@henrik.synth.no wrote: Here's what Shearwater says: « Fresh Water = 1000kg/m³ EN13319 = 1020 kg/m³ Salt Water = 1025 to 1035 kg/m³ The EN13319 (European CE standard for dive computers) value is between fresh and salt and is the Predator default value. The EN13319 value corresponds to a 10m increase in depth for pressure increase of 1 bar. Sorry to resurrect, but that last statement is patently wrong. It would be 1.02 bar, which is pretty close to an atmosphere (1.01325 bar) but still not 1-to-1. This stuff would be so much easier if everyone used the same (correct) units for this stuff. Where’s my dive computer that has a display in kPa or bar? Then I could dive in custard and everything would still work, well… except the regulators. signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Support different salinity in planner
On 18 Nov 2014, at 15:46, Paul Sargent paul.lions...@icloud.com wrote: The EN13319 (European CE standard for dive computers) value is between fresh and salt and is the Predator default value. The EN13319 value corresponds to a 10m increase in depth for pressure increase of 1 bar. Sorry to resurrect, but that last statement is patently wrong. It would be 1.02 bar, which is pretty close to an atmosphere (1.01325 bar) but still not 1-to-1. No, I was wrong. Ignore me. Gravity gets in there with it’s nearly 10, but not quite stuff. 1.020 kg/m³ does indeed work out to ~1 bar I’ll shut up now. signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Poseidon CCR dives: Nitrogen loading
On 7 Nov 2014, at 10:36, Robert Helling hell...@atdotde.de wrote: Now, in the CCR case, things are a bit more complicated as there is not _the_ current cylinder, there are two, diluent and oxygen. For the purpose of deco calculation (and anything that is related to what gas is the diver currently breathing), I would still argue that the “current” cylinder should be the diluent as we have to know the diluent for fill_pressures to determine the breathing gas. I would say that the notion of the “Current Cylinder” being the diluent works well. It’s the only gas that might ever change during a CCR dive. That is, you may change diluent, but you’ll never change from O2 to something else. Also if you look at the three types of SCUBA equipment that exist from a philosophical point of view: OC Equipment allows you to take a gas, breath it once, and vent it. SCR Equipment allows you to take a gas, breath it ’n’ times, and vent it. CCR Equipment allows you to take a gas, breath it a infinite number of times, with no venting (in theory) It’s fairly obvious (to me) that the common element is the breathing gas / drive gas / diluent gas, but for some reason we call it different things. The difference on SCR / CCR is the mechanisms employed to extend that gas. It just so happens that a CCR has an O2 supply to make it work, almost the same way that it could have a battery.* It’s a resource you track, and make sure it doesn’t run out, but apart from that it’s of little interest. (I’d actually be tempted not to have it as part of the normal gas list for this reason. Instead have it in it’s own special area.) I think you’ll find more commonality in the code for different dives types if you go this way. Paul * Of course, what makes CCR more complex is that we take advantage of the O2 supply to mix an ideal inspired gas, so that’s no longer constant. If it wasn’t for that, gas consumption rate would be the only difference between the 3.___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Importing CCR data [was: CCR Testing]
On 1 Nov 2014, at 10:57, Miika Turkia miika.tur...@gmail.com wrote: Together they give enough information to know what the diver was breathing at any time. Thanks, this gives me something to work on. The current Shearwater import is indeed quite limited in this regard. And of course the whole CCR concept was not there when I wrote the transformation. Indeed, and I think we’re going to find things rather fluid as we decide what’s useful information to have from a CCR dive. Willem’s building a road with the Poseidon work he’s doing, but it’s quite an esoteric rebreather, so I think we’ll find some concepts map well to others, and some won’t. The CSV import has no options for Gasses, Setpoints, OC/CC mode, ppO2 Sensors, all of which are in this file. I agree the dialog is a limiting factor here. I think there is also a problem with how these concepts map into the Subsurface XML. Fields are named similarly to the XML. I am thinking of 3 different options for this: 1) just keep it as it is and hope that CCR divers have better import option than the CSV 2) Implement the setpoints and other info under the hood with no configuration options for users 3) Make a new tab for CCR import Personally I would of course prefer something that does not include GUI work, but overall I kinda like the third approach. At minimum, implement another tab for the CCR import and possibly cimplify the current CSV import for recreational divers. I just wonder if tech divers will need all the fields in current CSV import when diving OC. Any comments on these? Anton, what is your opinion? CSV is nice to have as a fall back. There’s always going to be a computer / rebreather that we don’t support, and having CSV available gives a user a fighting chance. Even if it’s a limited set of info. If you’ve got a better method for a particular device (e.g. XML, or a specific format of CSV) you’re going to do that. My opinion is that for the configurable CSV import it has to be limited, otherwise you’ll be on a never ending quest to try to build in more flexibility. Time Depth Water Temp ppO2 (Single Value - CCR/SCR) CC/OC (CCR) Stop Depth …and then it’s a manual process to enter gasses / switch depths. (I’ve dropped off NDL, CNS, TTS, pressure from the current list. CNS is calculable. NDL TTS aren’t that important if you’ve got the ceiling IMHO. Pressure I assume is cylinder pressure - How many do you want? Possibly just 1, but no more) Things like multiple sensor readings, or multiple gasses probably need to be limited to known vendors. There’s just too many ways they could be represented. - Is an O2 sensor reading in bar or millivolts? - Is a breathing gas a number into a gas table, an fO2/fHe, or a ppO2/ppHe? - Is a set point column boolean Hi/Lo, or a value? Any dialog box that deals with all of that is going to be huge. So I’d keep the options low (as present, maybe trimming a couple), and add a couple more for CCR/SCR. Then have predefined schemes which are able to do more under the hood (e.g. APD, Seabear, etc) My 2p. Paul signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Globe missing
I tend to get it with the text output of the dive planner too. On 29 Oct 2014 17:08, Tomaz Canabrava tcanabr...@kde.org wrote: Yes, we can make it unshirinkable. I actually liked the hability to hide, but I can remove it. Em 29/10/2014 15:01, Dirk Hohndel d...@hohndel.org escreveu: On Wed, Oct 29, 2014 at 12:58:23PM -0400, John Van Ostrand wrote: Thanks. Boy does that makes me feel stupid. The full window view also had the same issue. I find this actually super annoying... Tomaz, can we enforce a minimum width for the Marble window? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On 27 Oct 2014, at 17:56, Rodrigo Severo rodr...@fabricadeideias.com wrote: For example: A one hour dive should be 20bar (60 litres) out of a standard 3 litre cylinder - just calculating 1 litre a minute. That's just way off. I always use about ~50 bar on a ~40 metre dive, so I tend to make sure I've got at least 100 bar when I jump in. (or have a missed a different method of calculating things in the various mails?) The method of calculation is just that but, as I see things, it would happen the other way around: After this dive Subsurface would show you that your oxygen SAC is 2,5 l/min (50 bar of a 3 l cylinder used on an hour dive). So on your next planning you should use 2,5 l/min for oxygen and not the usual 1 l/min. The problem here is that going from a one hour to a two hour dive doesn’t double my O2 use. I might go from 50 bar to 70 bar (i.e. Same use for the ascent aspects, another 20 bar for the extra hour). To me it sounds to me like we’d need a SAC component (litres/min) and an ascent component (litres/metre.bar). Diluent would just have a descent component (litres/metre.bar). In the example above reasonable figure might be: - O2 SAC: 1 litre/min - O2 Ascent: 30bar * 3l = 90l 90l / 40 metres = 2.25 litres/metre 2.25l / 2.5 bar (Avg. Pressure during ascent) = 0.9l / metre.bar - Diluent Descent: 50bar * 3l = 150l 150l / 40 metres = 3.75l / metre 3.75l / 2.5 bar (Avg. Pressure during descent) = 1.5l / metre.bar Paul signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
CCR Testing
I've been spending a bit of time this morning playing with CCR Dives on the latest git version (ee7c86f206f5465df0f0ade08b13da3b8062e67f). This is quite a long mail, but just trying to get everything down. Dive Logs - I dive with two computers on all my CCR dives. There's a Shearwater Predator on the unit which monitors the cells, and I use an OSTC 2C as a backup in fixed ppO2 mode. Looking at old dives I think most of my problems at the moment are really around importing. - Importing from Shearwater Desktop via XML, all my dives are air dives. - Importing from Shearwater Desktop via CSV isn't configurable enough. - Old logs imported from my OSTC into Subsurface 3.x and brought forward have gas change events in them, but limited information about gasses. Only really matters when I've done OC ascents from a CCR dive (Called 'Bailing out', done in emergencies and training). Loading up one of my old OSTC CCR training dives that included bailouts, the log knew that the switch had taken place (placed an icon), and seemed to calculate deco correctly, but it seemed to think I'd switched to the same gas. This was until I added the gas manually to the dive, and then it associated correctly. Neither the deco or the O2,N2,He graphs changed with the addition of gasses. It also seems that what it's done is take the changes as diluent switches, and stayed on CC. I say this because the ppO2 is fixed throught all the gas switches. I've yet to try importing from the computers themselves, will try and report back. I think I can only get the bailout dive from my OSTC though. I wasn't diving my Shearwater (although I do have the computer dump files that Shearwater desktop saves) Dive Planning - I've noticed is that if I plan a dive and include bailout gasses, then it'll switch to them during ascent, but not off CCR (ppO2 is still fixed). I have to delete the gasses to avoid it doing this. Inserting a extra dive segment with a Setpoint of 0.0, causes a gas switch to the bailout gas, and a bailout warning triangle, but the ppO2 graph stays fixed at the original setpoint, which suggests things aren't right. For CCR planning I'd say we to either have a button to switch between CC and OC ascent, or be able to see both together. Both are important, and you need to be able to play with the plan whilst refering to both. Having them as two separate dives is a pain. For fun I put a plan in that is well beyond me, but some of my friends have done. have done. - Descent rate 20m/min - All ascent rates 10m/min - Drop to first depth checked. - 130m - duration 11m - GF 30/85 - Setpoint 1.3 - One gas - 10/70 The graph turns red because the first stop is above the ceiling. This didn't seem to happen with 4.2. Doing my standard 30m at 70 metres diving 1.3ppO2 on 16/40 no bailout plan, I've noticed that the plan has become slightly shorter (113 mins instead of 121 mins in 4.2). This brings it more in line with other programs. Conclusion -- Honestly, for me, I'm not sure what's really changed since 4.2. I know there are changes, but pretty much everything I've done I could do with 4.2. There are a couple of exceptions. - Tissue Graph: I like. - Tank Bar: Really like, but for me would be really useful if it distinguished between OC CC too. In general the behaviour is the same as 4.2 (apart from the deco). Maybe once I can actually get ppO2 data imported then I might notice a difference. signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Importing CCR data [was: CCR Testing]
On 28 Oct 2014, at 14:56, Miika Turkia miika.tur...@gmail.com wrote: On Tue, Oct 28, 2014 at 4:00 PM, Paul Sargent paul.lions...@icloud.com wrote: Looking at old dives I think most of my problems at the moment are really around importing. - Importing from Shearwater Desktop via XML, all my dives are air dives. Can you provide sample XML with clear description of what is missing/wrong. Well, if it is only the gas info missing, then that should be quite obvious without any more info… I’ve attached a gripped copy. 3806974B#94_6-18-2014.xml.gz Description: GNU Zip compressed data As you can see there’s a lot of fields. Thankfully they are all named sensibly. Biggest ones are: - fractionO2 and fractionHe. These define the breathing gas on OC, and the diluent on CC. - averagePPO2 The measured ppO2 in the breathing loop of the CCR - currentCircuitSetting 0 = Closed Circuit 1 = Open Circuit Together they give enough information to know what the diver was breathing at any time. - Importing from Shearwater Desktop via CSV isn't configurable enough. Is it about not enough data can be imported? Here again, a sample file and info on what should be fixed/implemented would be helpful. I just wonder how much options we can sanely have on the import dialog. Again, I’ve attached a gripped copy. 3806974B#94_6-18-2014.csv.gz Description: GNU Zip compressed data The CSV import has no options for Gasses, Setpoints, OC/CC mode, ppO2 Sensors, all of which are in this file. I agree the dialog is a limiting factor here. I think there is also a problem with how these concepts map into the Subsurface XML. Fields are named similarly to the XML. - Old logs imported from my OSTC into Subsurface 3.x and brought forward have gas change events in them, but limited information about gasses. Only really matters when I've done OC ascents from a CCR dive (Called 'Bailing out', done in emergencies and training). I wonder if there is information missing or are the old logs incorrectly parsed. I’m wondering the same. I’ve attached a copy of that too (Bailout dive.xml) exported from subsurface. All three attachments are the same dive. Bailout dive.xml.gz Description: GNU Zip compressed data Paul signature.asc Description: Message signed with OpenPGP using GPGMail ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Oct 27, 2014, at 03:42 PM, Rodrigo Severo rodr...@fabricadeideias.com wrote: Bill, I agree: 1/2 foot is noise, 10 m is significant. What value do you think we should use as limit? I just proposed 1 m on my previous email to Robert but I'm not sure if this value is big enough. What do you think? It'd be interesting to put some code together, run it on real dive data and see how the predicted number compared with the measured one. Until you do I think it'd be difficult to know where the noise filter level needs to be set. Would tracking only the size of the counter lungs be sufficient? I don't think any of this is necessary, neither counter lungs volume nor loop volume as I mentioned on my previous email. Without knowing has much gas is in the loop (note: not counter lung size, which is part of the maximum loop volume) you can't know how much diluent to add to maintain it*. Example: 5l of gas in the loop. Decend from surface to 10m (2bar). I need to double the mass of gas in the loop to maintain volume, hence I need to add 5l (surface equivalent mass**). Counter lung (maximum) volume is irrelevent, because divers try not to run maximum volume. In fact they try to run minimum volume (i.e. 1 human lung full) because doing so uses less gas and is easier to control (buoyancy). You probably need to work out an average of what this diver tends to do (like SAC) and use that in predictions. Paul * Similarly, You can't know how much O2 to add to raise the ppO2 by some amount without knowing how much gas is in the loop. Hence ascents are tricky too ** Terminology when talking about amounts of gas under pressure is hard. Really we should talk about masses of gas, but we don't. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
On Oct 27, 2014, at 04:26 PM, William Perry wmpe...@kadath.us wrote: I can probably get my instructor to run a download against a bunch of shearwaters or Nitek Qs with the 4th cell monitoring if we need test data for subsurface or libdivecomputer. I've got tons of Shearwater data. Can probably get Inspiration data really easily as well. Paul ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] Poseidon MK6 import
Ok, I'll try to put some time aside over the next couple of days to have a play. On Oct 27, 2014, at 05:05 PM, Dirk Hohndel d...@hohndel.org wrote: On Mon, Oct 27, 2014 at 03:23:11PM +, Paul Sargent wrote: So who are the rebreather divers besides Willem who are helping to get this right and are especially testing this as thoroughly as possible. I'd hate to release 4.3 and announve rebreather support and then have to say never mind... I'm certainly happy to look over as much as I can, but it's limited by what I can exercise from my dive data. As far as I can tell a number of the patches recently deal with utilising ppO2 data from the sensors, and the only unit we can import ppO2 data from is a MkVI. I don't dive a MkVI, so whilst I can test planning CCR dives, or imported constant ppO2 CCR dives from an OSTC, I can't exercise everything. And that's fine. Let me know what you'd like me to attack ;-) Everything that you CAN use. So for the dives that you import, do the things that we show make sense? Is there a way they could (should?) make more sense? Does the planning seem right? Pieces missing? I simply notice that almost every time I do something that I usually don't play much with, I quickly find little bugs. And I worry that that's the experience for a lot of our users as well. And especially since tech divers appear to be a reasonably big part of our user base, I want to make sure we get this right :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Use of o2 cell data in CCR dive logs
Hi Willem, On Oct 13, 2014, at 11:37 AM, Willem Ferguson willemfergu...@zoology.up.ac.za wrote: Hope you do not mind me changing the topic title. No problem. Thank you very much for your response. The philosophy here is to get the system working for a fully logged CCR system and then to expand this foundation to others. I think you and I disagree on what makes a foundation good to build on. My concern is the code that you're writing looks like it's very specifc to one or two CCRs, and adding further ones in the future will be more difficult because of this. Looking at the patch you've generated so far I could see it growing into a huge amount of code with lots of code paths specific to particular CCRs, all deep in the decompression calculations.That seems like it could grow into a maintainance problem. One of the important things a CCR diver wants to know is to assess the accuracy of the oxygen management system. As a fellow CCR diver I don't have it that at the top of my priority list, but that might be just me. Regardless, I addressed that. I wasn't saying to throw that data away. Just that it would only be used for reference and fault finding (as you describe) once the dive has been initially imported. Of course, code talks, and you're the one writing the code, but I'm interested in helping where / when I can. Paul ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
