<div dir="ltr">Thanks Robert,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 June 2015 at 18:12, Robert Helling <span dir="ltr"><<a href="mailto:helling@atdotde.de" target="_blank">helling@atdotde.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class=""></span><div>Thanks a lot for this. Too bad I currently have virtually no time to look at this in any detail and due to a family wedding this weekend possibly not before Monday.</div></div></blockquote><div><br></div><div>No worries.  I have things to do over the weekend too.  Your comments include plenty of good suggestions.  I'll try to get closer to a good solution, but that probably won't be before Monday.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Still a few remarks:</div><div><br></div><div>1) Could you split your patch into 2-3 patches, one for the segment type, another one for the new logic? git add -p is very helpful in doing this (as I recently learned).</div></div></blockquote><div><br></div><div>The process for altering the code involved a lot of trial and error and doing / undoing changes.  I'm sure that's not the ideal method, and it doesn't lend itself to split patches.  I'll see if I can improve that, and will look up what add -p does.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>2) Don’t use the gamix.gas.permille members directly or you will run into problems since air is stored as 0%O2+0%2He. If you want to treat the special cases separately, you are likely doublicating code. Please always use the helper functions get_o2(&gasmix) and get_he(&gasmix) if you really want the content and to test if two gases are the same, there is gasmix_distance(&gasmix1, &gasmix2).</div></div></blockquote><div><br></div><div>Thanks for the tip, that makes much more sense than comparing .permille and dealing with a new set of mathematical rules where 0% = 21%.  I saw gasmix_distance use in parts of the code, but had no idea what it did and assumed it related to some physical distance.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>3) I must say, I am not really a fan of the 0min stops. But people might convince me. What I had intended to do is to change the plan() such that after doing a gas change, it always waits for a minute (and that minute might later be configurable by the user). I think this is realistic as doing a gas change with all checks while continuously ascending is just unrealistic.</div></div></blockquote><div><br></div><div>Yes, if there is a minimum stop time in the calculated profile, the issue of 0min stops goes away - it makes executing the dive as well as outputting the plan easier.  An alternative (option) would be to postpone the gas switch until the first deco stop as Anton prefers.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>4) We could have a checkbox to turn on and off the segment type symbols (as we have for duration and runtime). If you want to try that, simply copy the code for those options.</div></div></blockquote><div><br></div><div>I'll have a go.  I originally added symbols to help me track what the code logic was actually doing, then I decided it was actually useful info that could add clarity to the plan.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>5) Just a personal preference, i would use <a href="https://en.wikipedia.org/wiki/%E2%86%97" title="↗" style="color:rgb(11,0,128);background-image:none;font-family:sans-serif;line-height:28px;text-align:center;text-decoration:none!important" target="_blank">↗</a>, <a href="https://en.wikipedia.org/wiki/%E2%86%98" title="↘" style="color:rgb(11,0,128);background-image:none;font-family:sans-serif;line-height:28px;text-align:center;text-decoration:none!important" target="_blank">↘</a>, <a href="https://en.wikipedia.org/wiki/%E2%86%92_(disambiguation)" title="→ (disambiguation)" style="color:rgb(11,0,128);background-image:none;font-family:sans-serif;line-height:28px;text-align:center;text-decoration:none!important" target="_blank">→</a> for ascent, descent and stop and not distinguish between stop and constant depth planned segment.</div></div></blockquote><div><br></div><div>Sounds Reasonable.<br></div><br></div><div class="gmail_quote">Rick<br></div></div></div></div>