Subsurface minimum gas calculation - First version for review

Robert Helling helling at atdotde.de
Tue Feb 21 02:44:59 PST 2017


Stefan,

> On 21.02.2017, at 11:02, Stefan Fuchs <sfuchs at gmx.de> wrote:
> 
>> the problem is that for computers that don’t have gas information, the interpolation of cylinder pressures is only done at the plot stage. The information is in struct plot_data which you find in profile.h, in particular in cylinderindex and pressure[2] (to access the latter there is a macro, for usage see profile.c. Strictly speaking, that is to handle the CCR case which you want to avoid anyway but it’s better to use this as an accessor).
>> 
> Hmmm... plot_data is rather difficult to access from planner.c. Or do I miss any easy way to do this?

Hmm. That’s true. Problem is: during planning, so far, we don’t track gas usage but compute it only later. Concretely, in planner.c

static void create_dive_from_plan(struct diveplan *diveplan, bool track_gas)

close to the bottom there is

			update_cylinder_pressure(&displayed_dive, sample[-1].depth.mm, depth, time - sample[-1].time.seconds,

This might be a place where one could inject a test if rock bottom is exceeded if that value is already known at that stage. Alternatively, you might have to store the pressure vs time information or you store the rock bottom value for the gas with the dive and generate the warning only in the plotting stage (close to where the gas pressure curves are created). Thinking about this, I guess the latter is what I would go for.

> 
>> And as I said: I think it’s cleaner to add an event to the dive rather than plot directly to the profile. Simply use
>> 
>> struct event *add_event(struct divecomputer *dc, unsigned int time, int type, int flags, int value, const char *name)
>> 
> Yes, clear. For a test I created a dummy event @25min in this way:
> add_event(&dive->dc, 60*25, SAMPLE_EVENT_AIRTIME, 0, 0, "Minimum gas exceeded");
> 
> 
> When looking for add_event I stumbled across s.th <http://s.th/>.:
> I know that one has to be careful where and when it is ok to translate the name of an event. But my guess is that for this event (line 195, diveprofileitem.cpp) we would be allowed to translate it:
> add_event(&displayed_dive.dc, entry->sec, SAMPLE_EVENT_CEILING, -1, max / 1000, "planned waypoint above ceiling");
> 
> What do you think? Ok to change this to:
> add_event(&displayed_dive.dc, entry->sec, SAMPLE_EVENT_CEILING, -1, max / 1000, translate("gettextFromC", "Planned waypoint above ceiling"));
> 
> And then there is another one in planner.c where I'm not sure:
> add_event(dc, lasttime, SAMPLE_EVENT_PO2, 0, po2, "SP change");
> 

Hmm. I guess, there is no easy answer. There are uses of the name string like in dive.c:

struct event *get_next_event(struct event *event, const char *name)

where we search for events by name (“gaschange” being a prominent example). This would break if we started translating event names. We would have at least then to search for translated strings (and that I would consider quite ugly).

[Here is a break where I started actually looking into the source about event names]

From what I see, I would say, translating event names is wrong. At least for the internal storage. They should only be translated when displayed to the user. For that I see for example:

void DiveEventItem::setupToolTipString()
{
	// we display the event on screen - so translate
	QString name = gettextFromC::instance()->tr(internalEvent->name);

in diveeventiteM.cpp

Maybe my understanding of how the translation works is wrong but I thought, we can only translate strings that are already known at compile time (but the actual translation happens at runtime). Please somebody correct me if I am wrong!

So, I guess, we actually need to teach all possible event names to the translation system. I have no idea how too do that. Maybe you could look into this? And then make sure, the names only get translated when displaying them to the user (i.e. event.name always holds untranslated strings).

I don’t know if you are aware of this, but these kinds of things are much easier to do when using Qt Creator as an editor (rather than a pure text editor): For example by right clicking on “name” in some occurrence of event.name and selecting “Find usages” gives me over a hundred places where this struct member is used in our source.

Best
Robert



--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F





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


More information about the subsurface mailing list