re-planning a planned dive

Tomaz Canabrava tcanabrava at kde.org
Tue Aug 19 20:44:42 PDT 2014


You are making my job too easy =)
Em 19/08/2014 23:42, "Dirk Hohndel" <dirk at hohndel.org> escreveu:

> This was one of the outstanding features that we didn't get done in time
> for 4.2. And it turned out to be on the one hand not very hard, on the
> other hand fairly instrumental to finding quite a few bugs that were still
> lurking here and there in the planner code. I think more of the commits in
> this series end up fixing old issues than adding new capabilities. And
> certainly 3/4 of the time working on this was spent on observing the
> issues, understanding their causes and coming up with reasonable fixes for
> them.
>
> That said, as usual I have hidden some very cute bugs in the new code,
> just to make sure that you guys read what I commit and test it. So please
> get started, as always the first one to find a bug in my code will win a
> valuable price!
>
> So where are the limitations of the current implementation?
>
> It seems to work quite well in my testing (but who knows once Henrik,
> Joakim, Robert and the other usual suspects start doing their testing).
>
> But there is one rather interesting issue: right now we don't save whether
> a sample was manually entered or created by our deco (or ascent)
> algorithm. Or more precisely, we've never saved this in the past and we
> still don't save this information to disk. Which means that when you
> re-plan such a dive the dive points table will contain ALL waypoints of
> the dive, including the ascent and deco stops (and all such points will
> have handlers in the profile). This is of course undesirable (even though
> it isn't really hard to get rid of them - especially in the dive points
> table it's really easy to just delete them all and they get automagically
> recreated by the planning algorithm).
>
> For now I have only implemented an in memory solution. The idea is that
> while you are planning a dive you may go back and forth and try multiple
> things. And as long as you don't save the planned dive, restart Subsurface
> and read it in again, you can continue to make changes as you'd expect.
> Only the dive data points that you entered before are in the table and
> have handles in the profile. All the other poinst (gas changes, ascent,
> deco stops, transitions) will get recalculated on the fly as if you never
> left planning mode.
>
> But once the planned dive is written to disk and read back we are back to
> what I describe above - ALL waypoints are treated as if they were user
> entered.
>
> I have a hunch that this is sufficient for most reasonable use cases, but
> the simply fact how hard it is to explain this makes me wonder if we
> shouldn't save this data to disk, anyway. It obviously would be easy to
> add to both XML and git save and parse routines... but I didn't want to
> add this until the likely users of this feature have commented if that
> would be important to them.
>
> And until all of you had some time to poke holes into my architecture and
> implementation for this.
>
> /D
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140820/6cdbffbf/attachment.html>


More information about the subsurface mailing list