Re: Issues cylinder table (2x) when re-edit planned dive in planner

[Stefan Fuchs]

Hi Robert,

> By accident I just figured out that the issue I described is not
> linked to re-planning a dive but to having 4 cylinders or more in the
> cylinder table in the planner.
> Means you can also plan a new dive and increase to 4 cylinders to
> cause the issue (messed up cylinder table). If you then remove one
> cylinder again and reduce to number of cylinders to 3 or less the
> additional table row disappears again.
I believe I fixed it:
https://github.com/Subsurface-divelog/subsurface/pull/245

Best regards
Stefan


-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Jérémie Guichard]

Hey guys,

I've added the flag conditionally as discussed in previous mail, and
updated the pull request. Meanwhile I was able to fix the failure in
TestPreferences (in a separate pull request). Once both are merged, all
tests will be passing on Windows/wine. Yuhu!

I'm not familiar with Travis at all, but if nobody has time to look into
preparing the env for mxe build and wine test I could look into that.

Best regards,

Jeremie

2017-03-08 21:34 GMT+07:00 Dirk Hohndel :

> On Wed, Mar 08, 2017 at 02:42:28PM +0700, Jérémie Guichard wrote:
> >
> > Unfortunately I could not enable the flag in that commit since travis
> seems
> > to be using gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 that do not include
> > this option... Nevertheless it may be a good idea to make use of the
> option
> > so should we:
> > 1. Upgrade travis build to use more recent version of gcc and add the
> flag
> > unconditionally?
>
> No, we are still supporting Trusty and this would fail our Trusty builds
> in general
>
> > 2. Add the flag under a cmake gcc version condition so that people using
> > more recent version of gcc in their dev env be warned about the mistakes?
>
> Yes, that would be my preference
>
> > 3. Since 1 could be annoying to people still using older gcc in their dev
> > env, we could upgrade travis but still put the flag behind a condition
> like
> > proposed in 2?
>
> I don't see the value of having this in travis - unless you build tests
> that rely on the output of this flag.
>
> /D
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Minor formatting comments

[John Smith]

A few small formatting comments

In planning view, gradient factors are "GF low" and "GF high" and are given % 
in the pull down.
In preferences they are "GFLow" and "GFHigh" and are unit less.

VPM-B settings are called "Conservatism level" in planning and have no positive 
indicator, in preference it's labelled " VPM-B Conservatism" and has a positive 
sign in front

In preferences you have the units for pO2 for example, as part of the 
descriptor but in planning you have the units in the pull down. In fact you 
also have the units shown with the value in the information window as well.

Firstly, are these descriptors worth standardising and if so can someone point 
me towards a suitable git interface for windows so that I can try doing this 
myself

Sent from my iPad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Minor formatting comments

[John Smith]

A few small formatting comments

In planning view, gradient factors are "GF low" and "GF high" and are given % 
in the pull down.
In preferences they are "GFLow" and "GFHigh" and are unit less.

VPM-B settings are called "Conservatism level" in planning and have no positive 
indicator, in preference it's labelled " VPM-B Conservatism" and has a positive 
sign in front

In preferences you have the units for pO2 for example, as part of the 
descriptor but in planning you have the units in the pull down. In fact you 
also have the units shown with the value in the information window as well.

Firstly, are these descriptors worth standardising and if so can someone point 
me towards a suitable git interface for windows so that I can try doing this 
myself

Sent from my iPad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: smkt2ssrfgas switching

[Salvador Cuñat]

Good Afternoon Alessandro.

On Thu, Mar 09, 2017 at 09:45:08PM +, Alessandro Volpi wrote:
> 
> The issue is NOT SO IMPORTANT, but I would suggest that you consider the
> possibility of using a different criterion to select the tanks WHICH ARE
> ACTUALLY BEEN USED. Such a criterion could be to look for the presence of
> the tank DESCRIPTION or the definition of tank VOLUME,  instead of checking
> the existence of the START PRESSURE value. It is very unlikely that a
> SmartTrak user  is going to waste time with the manual input of data for
> tanks which HAVE NOT BEEN ACTUALLY USED. On the other hand the tank type
> and/or the tank volume CAN ALWAYS BE MANUALLY INSERTED, even when a
> pressure transmitter is paired but not working.
> 
> I do not know how much work is required for implementing such program
> modification. If this implies a significant effort there are surely more
> important things to be done first ...
> 
In the end. I think the easiest (and probably saner) way will be to
drop the tank data from libdivecomputer and relay only in the data
from smarttrak (as this *should* include all data from the divecomputer
and any other manually added by the user).

Should be easy to implement an will avoid duplicities.

Thanks Alessandro.

BTW, I've been reviewing the topic of manually added bookmarks on
smarttrak with new eyes and didn't seem as impossible as before, in
fact looks like it's quite easy. If I have a little time this weekend,
will fix the tanks topic and will do a first stab at the bookmarks.

Regards.

Salva.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC 2 problem

[Anton Lundin]

On 10 March, 2017 - Robert Helling wrote:

> Hi,
> 
> on FB, there is a user who can set up the bluetooth connection from a Mac 
> running Sierra to his OSTC but then the download fails with
> 
> INFO: Open: name=00:80:25:4A:CD:CA
> ERROR: Failed to open the serial port. [in ../../src/hw_ostc3.c:344 
> (hw_ostc3_device_open)]
> 
> 
> Anybody any idea what to respond?

Hard to say anything from that log.

Nothing on stdout/stderr from subsurface?


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: WIP - Tabbs rework

[Tomaz Canabrava]

I'll rebase against master and resend.


On Fri, Mar 10, 2017 at 12:43 PM, Martin Měřinský  wrote:

> git apply 0030-Pass-the-parent-everywhere.patch
> error: patch failed: desktop-widgets/maintab.h:51
> error: desktop-widgets/maintab.h: patch does not apply
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

[Jef Driesen]

On 2017-03-10 11:05, Alessandro Volpi wrote:
I still do not understand for which type of DC does Jef want to get a 
the

"memory dump".  I should be able to provide the memory dump of SmartTec
and/or Galileo Trimix.


To check whether smarttrak has truncated the profile data, I would like 
to compare the data in the smarttrak database with the same data 
directly downloaded from the dive computer. But that's only possible if 
(1) you still have that dive computer and (2) those dives are still on 
the dive computer. I don't know if that's the case or not. Reading back 
through the thread, I see those dives were from an old Aladin Air Z O2, 
so the answer is probably no.


Of course you may still send those memory dumps! I can always use extra 
data for better testing. At the moment I only have one memory dump from 
the models you have.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: WIP - Tabbs rework

[Martin Měřinský]

git apply 0030-Pass-the-parent-everywhere.patch
error: patch failed: desktop-widgets/maintab.h:51
error: desktop-widgets/maintab.h: patch does not apply
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage

[Alessandro Volpi]

Thanks for the explanation.

I still do not understand for which type of DC does Jef want to get a the
"memory dump".  I should be able to provide the memory dump of SmartTec
and/or Galileo Trimix.

Best regards.

Alessandro

On Fri, Mar 10, 2017 at 7:40 AM, Anton Lundin  wrote:

> On 09 March, 2017 - Alessandro Volpi wrote:
>
> > I have at present a Galileo Sol with Trimix software and a SmartTec.
> >
> > Which computer are you referring to ?
> >
> > What is the "memory dump" you are speaking about  ?  Is it the result of
> a
> > direct download from the DC to subsurface ? Or is it the .slg file from
> > SmartTrak ? Or something else ?
>
>
> In subsurface you go import -> from dive computer -> and check Save
> libdivecomputer logfile and Save libdivecomputer dumpfile and email
> those to Jef.
>
> That takes a "raw" memory dump from the divecomputer, which he later can
> use to verify how the dive profile looks at the source, ie the dive
> computer.
>
>
> //Anton
>
>
> --
> Anton Lundin+46702-161604
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Diveplanner questions

[Anton Lundin]

On 10 March, 2017 - Anton Lundin wrote:

> On 09 March, 2017 - John Smith wrote:
> 
> > I am playing with the planner and have a few questions, hopefully showing 
> > my lack of knowledge rather than bugs []
> > 
> > 
> > I have 4.6.3.36 running on W10.
> > 
> > 
> > Firstly, although i have all the ascent rates set to 10m/min, the ascent 
> > rate in the profile window shows 9m/min.
> > 
> 
> After some testing, i think this is due to that all the spinboxes
> doesn't trigger update on the plan. Try to change the depth or duration
> up and down and the plan will be re-calculated with the right values.

Nope. It wasn't. I was just a bad tester.

Its just a artifact of which depths and time steps that the planner
works with. Ex, if you change all the Ascent speeds to 15m/min, the
profile for that dive will be 15m/min.

The planner tries to match the configured Ascent speeds, but if they
don't align with the depth/time, it errors to the side of caution, and
accents a bit slower.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Diveplanner questions

[Anton Lundin]

On 09 March, 2017 - John Smith wrote:

> I am playing with the planner and have a few questions, hopefully showing my 
> lack of knowledge rather than bugs []
> 
> 
> I have 4.6.3.36 running on W10.
> 
> 
> Firstly, although i have all the ascent rates set to 10m/min, the ascent rate 
> in the profile window shows 9m/min.
> 

After some testing, i think this is due to that all the spinboxes
doesn't trigger update on the plan. Try to change the depth or duration
up and down and the plan will be re-calculated with the right values.

This loks to be a bug.

> 
> 
> Secondly, I cannot set the altitude to 0m and the Atm pressure to 1000mbar. I 
> also found that as soon as you change the altitude to a negative value, the 
> atm pressure changes too 689mbar whatever the altitude values is.
> 

... desktop-widgets/diveplanner.cpp:225

void DivePlannerWidget::heightChanged(const int height)
{
int pressure = (int) (1013.0 * exp(- (double) units_to_depth((double) 
height) / 780.0));


... core/dive.c:251

unsigned int units_to_depth(double depth)


Robert: You wrote the heightChanged code, can you fix that?


> Finally, in almost all of the profiles I generated, the calculated ceiling. 
> information window and tissues seem to show that deco is clear some time 
> before the profile shows it is time to ascend


Thats due to the fact that the planner works with "steps" of minutes
there. It waits until the next full minute before moving on.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface