Re: RFC: Statistics in Subsurface

[Dirk Hohndel via subsurface]

> On May 12, 2020, at 6:38 PM, Hartley Horwitz via subsurface 
>  wrote:
> > Here's a crazy idea how this could look for example:
> > 
> > The filters are built incrementally, with a drop down menu that allows you
> > to add criteria or constraints. Like date range, tags, people, etc
> > 
> 
> I really like the idea of building the filters incrementally.  This style of 
> user interface is showing up in other tools I use, so I think it will feel 
> familiar.   I also believe most people filter on just one thing most of the 
> time, then occasionally go for more complex filters with many criteria.  At 
> least that's my pattern of use. 

I completely agree with that. Which would make this incremental setup neat.

> > once the user picks one, that is added to the list and can be populated.
> > In the example the user first added 'date' and then 'tags'.
> > The tags one shows the idea of having additional options (all/any/none and
> > substr/starts/exact, just like we have today). Using font size and font
> > color to make this seem less cluttered.
> 
> Later on, Dirk is asking questions about visualization of the stats.  That's 
> a tough one.  I"m not convinced we're a good judge of the average user.  For 
> example, the box & wiskers plots are something I deal with at work, so they 
> are very familiar and compact.  That said, some of my colleagues look at 
> those things blankly, especially when the distributions are non gaussian.   I 
> don't know how to satisfy all, but I think good filtering and simple 
> min/mean/max are already valuable.

So here you mention min/mean/max - so something like the second graph I posted?
Or more like this?


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

Re: RFC: Statistics in Subsurface

[Dirk Hohndel via subsurface]

> On May 12, 2020, at 7:00 PM, Hartley Horwitz via subsurface 
>  wrote:
> 
> I keep saying "candlestick" when I mean to say "box and whiskers". My 
> mistake. You are spot on correct, the error is mine.
> 
> As much as I use stats in my job, I wonder what the value of knowing the 
> upper quartile is of my SAC rate or any other parameter that I may be 
> tracking.  For diving planning purposes I'd need to use my max air 
> consumption after filtering the dive list to get appropriate dives.   I don't 
> think this is providing the average user with useful data.  It's got 
> mathematical pureness to provide a 5-number data visualization assuming the 
> filtered list provides a statistically significant number of data points.  
> Other than that, do we care? Should we care?  I will send a sample box plot 
> to a diving friend of mine who's a part-time dive pro.  I'd be surprised if 
> he knows how to interpret it.  Histograms are more readily understood but 
> unfortunately take up a lot of space, and the issue of choosing the bin size 
> gets challenging as you've discussed when it comes to depth.   

Can you create a visual to show us what you would prefer? I'm not sure what you 
mean here by Histogram?

/D

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

Re: RFC: Statistics in Subsurface

[Hartley Horwitz via subsurface]

> -- Forwarded message --
> From: Dirk Hohndel 
> To: Willem Ferguson 
> Cc: Subsurface Mailing List 
> Bcc:
> Date: Tue, 12 May 2020 14:24:28 -0700
> Subject: Re: RFC: Statistics in Subsurface
>
> On May 12, 2020, at 12:41 PM, Willem Ferguson <
> willemfergu...@zoology.up.ac.za> wrote:
>
> snip..

> Lastly, I do not like candlestick graphs because the application in
> econometrics does not include the equivalent of a mean value. It is meant
> to indicate the limits and sometimes direction of change within a specific
> time period giving rise to the candle forming the central part of the
> graph. In my opinion a minimal box and whisker approach is more readily
> interpretable.
>
>
> I keep saying "candlestick" when I mean to say "box and whiskers". My
> mistake. You are spot on correct, the error is mine.
>

As much as I use stats in my job, I wonder what the value of knowing the
upper quartile is of my SAC rate or any other parameter that I may be
tracking.  For diving planning purposes I'd need to use my max air
consumption after filtering the dive list to get appropriate dives.   I
don't think this is providing the average user with useful data.  It's got
mathematical pureness to provide a 5-number data visualization assuming the
filtered list provides a statistically significant number of data points.
Other than that, do we care? Should we care?  I will send a sample box plot
to a diving friend of mine who's a part-time dive pro.  I'd be surprised if
he knows how to interpret it.  Histograms are more readily understood but
unfortunately take up a lot of space, and the issue of choosing the bin
size gets challenging as you've discussed when it comes to depth.

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

Re: RFC: Statistics in Subsurface

[Hartley Horwitz via subsurface]

>
> -- Forwarded message --
> From: Berthold Stoeger 
> To: Dirk Hohndel 
> Cc: willemfergu...@zoology.up.ac.za, subsurface@subsurface-divelog.org
> Bcc:
> Date: Tue, 12 May 2020 07:46:00 +0200
> Subject: Re: RFC: Statistics in Subsurface
> On Dienstag, 12. Mai 2020 00:02:06 CEST Dirk Hohndel wrote:
>
> > Here's a crazy idea how this could look for example:
> >
> > The filters are built incrementally, with a drop down menu that allows
> you
> > to add criteria or constraints. Like date range, tags, people, etc
> >
>

I really like the idea of building the filters incrementally.  This style
of user interface is showing up in other tools I use, so I think it will
feel familiar.   I also believe most people filter on just one thing most
of the time, then occasionally go for more complex filters with many
criteria.  At least that's my pattern of use.


> > once the user picks one, that is added to the list and can be populated.
> > In the example the user first added 'date' and then 'tags'.
> > The tags one shows the idea of having additional options (all/any/none
> and
> > substr/starts/exact, just like we have today). Using font size and font
> > color to make this seem less cluttered.


Later on, Dirk is asking questions about visualization of the stats.
That's a tough one.  I"m not convinced we're a good judge of the average
user.  For example, the box & wiskers plots are something I deal with at
work, so they are very familiar and compact.  That said, some of my
colleagues look at those things blankly, especially when the distributions
are non gaussian.   I don't know how to satisfy all, but I think good
filtering and simple min/mean/max are already valuable.

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

Re: RFC: Statistics in Subsurface

[Dirk Hohndel via subsurface]

> On May 12, 2020, at 12:41 PM, Willem Ferguson 
>  wrote:
> I am comfortable with your points of view, above. The 10m or 10min increments 
> could easily be configurable. For instance a person with OW certification 
> (dives to 18m only with almost all dives in the 10-18m range) would probably 
> want at most  a 5m increment in depth. Unless I understand you wrongly 
> (again).  Normally with statistical software (like R) the default increment 
> is determined by the (max-min) range of the data as well as the number of 
> data points being plotted. Of course I would not like an increment of 3.674 m 
> of depth as might be the case when increment is automatically calculated by 
> machine. My only point is that a single fixed increment is possibly 
> restrictive and it would help if there were a simple rule to do some 
> adjustment of the increment.
> 

It's those details that tend to make something go from "straight forward" to 
"crazy tricky".
No, I definitely don't want 3.764m increments, but some people might want 3.04m 
increments (ten feet). Getting this almost right for most people is easy (ask 
the user how many data points they would like, and then round so in their unit 
system the result is marginally pleasant). Getting exactly what people would 
want is likely about as painful as my initial over-engineered idea.

> As far as specifying categories like tags I like the present UI where one 
> could specify a number of tags to be included in the filter, giving great 
> flexibility. Again my impression of such a plot possibly differs from yours. 
> I like your binary set idea (a set including compared to a set excluding). 
> But I would more realistically often want to compare (e.g. SAC when comparing 
> two tags "air" and "nitrox"), a use case which does not necessarily imply a 
> binary comparison because it could compare 3 or 4 tags. Does this make sense 
> at all?
> 

It makes sense for people who are able to use sets of tags in a meaningful way 
- one could have a mutually exclusive set of three tags (say, air, nitrox, 
trimix) and create statistics over them. Of course the results become "strange" 
if dives potentially have multiple of those tags.
Again, to get this "mostly right" is fairly easy. To cover all the crazy corner 
cases is what's hard.

> Lastly, I do not like candlestick graphs because the application in 
> econometrics does not include the equivalent of a mean value. It is meant to 
> indicate the limits and sometimes direction of change within a specific time 
> period giving rise to the candle forming the central part of the graph. In my 
> opinion a minimal box and whisker approach is more readily interpretable.
> 

I keep saying "candlestick" when I mean to say "box and whiskers". My mistake. 
You are spot on correct, the error is mine.

> I am very excited that this discussion is actually happening that that a 
> window of opportunity exists with people like Tomaz and Berthold interested 
> in being involved. 

I am, too. And I am determined to have something that is so well specified and 
sketched that we will actually get to a result that fulfills our wishes.
Which is why I wish more people were engaged in the conversation.

/D

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

Fwd: Re: RFC: Statistics in Subsurface

[Willem Ferguson via subsurface]

 Forwarded Message 
Subject:Re: RFC: Statistics in Subsurface
Date:   Tue, 12 May 2020 21:41:08 +0200
From:   Willem Ferguson 
Reply-To:   willemfergu...@zoology.up.ac.za
Organization:   University of Pretoria
To: Dirk Hohndel 



On 2020/05/12 20:49, Dirk Hohndel wrote:

Hi Willem,

Thanks for responding... I wish more people got involved into these 
conversations. But usually topics like this get two or three of the 
300+ people here to respond. And then ten more will complain after we 
have done the next release and they notice for the first time that we 
added a feature...


On May 12, 2020, at 12:59 AM, Willem Ferguson 
> wrote:


I understand Berthold's request with respect to temporal sequences. 
When developing such a temporal facility there is an important 
caveat. Emphatically, such temporal representations do not provide 
any clear *explanation* of anything: it is just a temporal pattern. 
For instance a decrease in SAC rate over time does not necessarily 
imply any improvement in physiological ability but may reflect 
adoption of new equipment or change in dive sites. Any explanation of 
a temporal trend is dependent on the understanding of the USER, not 
on the SOFTWARE. So, when dealing with temporal trends, one needs to 
consider carefully the intended type of use of it. I think Berthold 
is more concerned with continuous variables such as temperature, SAC, 
dive duration, depth, etc which could probably be reasonably easily 
implemented. To represent categorical variables such as tags, dive 
mode, people and suit (one could even add dive site) is a totally 
different issue requiring a totally different type of visual 
representation.




I was in complete agreement until the very last sentence. I don't 
understand why this 'per se' requires a "totally different type of 
visual representation".
Let's say I am charting SAC over my criteria. Let's assume I'm using 
box and whiskers charts to easily show the quartiles. The values on 
x-axis have implications for the interpretation, of course, but 
whether the x-axis is months of the year, the suit worn, the maximum 
depth of the dive, the tags present on the dive (e.g., teaching dive 
or non-teaching dive) has absolutely no impact on how this should be 
visually represented...


It would help, in this discussion, if one were to distinguish between 
the filtering aspect and the statistics display aspect and state that 
with respect to the argument. In Dirk's artwork above, I am not sure 
how the constraints will be used. Are we talking of the filtering 
process or the stats display mechanism? Let's say "Suit" is a 
constraint and two dates are provided. I am not sure what the 
expected result of the operation would be. Ahh, the problems of 
communication.




What I was trying to describe was a way to create criteria that can be 
used for columns in the visualization. You go through this filter 
process, name the result, and that name becomes one of the available 
labels over which you can chart the values.

Again, as I said before, I may simply be over-engineering this.

In general, in my opinion, the existing filter layout is a good 
starting point (I would add the variables of dive depth and dive 
duration because they are the two variables that fundamentally define 
a dive). As a filtering mechanism the current implementation is 
ultra-flexible.




While I respect your opinion, let me politely state that personally I 
believe that the current filter widget is a disaster and extremely 
unintuitive to use. That's not a criticism of the original author, nor 
of the people who have added to it - but yeah, that thing is a mess.


As far as UI for filter sets are concerned the minimum component 
count would include: Combobox of existing named filters within the 
set. Button: add current filter to filter set. These could 
potentially reside at the top right of the current filter panel. But 
there might be a need to give filter set a name as well. That would 
need a text box.




Making the current widget more convoluted and more confusing was not a 
direction that I was envisioning us to go.



Maybe we need to rain in the crazy German and go back to something 
much more basic. Something like ten predefined sets of criteria. And 
only apply them to the filtered dive list.


So.
(1) per month
(2) per year
(3) per trip
(4) by max depth in 10m increments
(5) by duration in 10min increments
(6) by min temperature in 10F / 5C increments
(7) by type (for people who track more than SCUBA)
(8) by suit (that's likely a fairly small set for most people)
(9) by tags (that one I'm unclear about - would likely need some more 
ability to influence how this is drawn - but straight forward would be 
to draw them in pairs of two, left one represents with the tag, right 
one without the tag)

(10) by people? (no idea how / why)
(11) by full text? (no idea how / why)

If we drop the last 

Re: Windows / OS X, differences in dive planning results

[Attilla de Groot via subsurface]

> On 11 May 2020, at 18:06, Attilla de Groot via subsurface 
>  wrote:
> 
> Either way, I will try to get you some better screenshots. I have to boot a 
> Windows VM though, apologies for that.

I tried to reproduce the issue on my own machine. Couldn’t reproduce it, so we 
can close this.


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

UI element proposal :-)

[Dirk Hohndel via subsurface]

Tangentially related to the statistics discussion... here's a QML UI element 
that I came up with to use for those any/all/none filters...

(let's hope an animated gif works to show this off)




enjoy :-)

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

Re: [OS X] git-load: string marker after running out of strings ('name')

[Attilla de Groot via subsurface]

> On 12 May 2020, at 19:55, Linus Torvalds  
> wrote:
> 
> Don't worry about it, and you should probably just ignore it (at least
> as long as it says 'name' or 'description' - 

Perfect, thanks. :-)

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

Re: RFC: Statistics in Subsurface

[Dirk Hohndel via subsurface]

It looks like Mail.app on my Mac failed to attach the images. Here they are...



> On May 12, 2020, at 11:49 AM, Dirk Hohndel via subsurface 
>  wrote:
> 
> Hi Willem,
> 
> Thanks for responding... I wish more people got involved into these 
> conversations. But usually topics like this get two or three of the 300+ 
> people here to respond. And then ten more will complain after we have done 
> the next release and they notice for the first time that we added a feature...
> 
>> On May 12, 2020, at 12:59 AM, Willem Ferguson 
>> mailto:willemfergu...@zoology.up.ac.za>> 
>> wrote:
>> I understand Berthold's request with respect to temporal sequences. When 
>> developing such a temporal facility there is an important caveat. 
>> Emphatically, such temporal representations do not provide any clear 
>> *explanation* of anything: it is just a temporal pattern. For instance a 
>> decrease in SAC rate over time does not necessarily imply any improvement in 
>> physiological ability but may reflect adoption of new equipment or change in 
>> dive sites. Any explanation of a temporal trend is dependent on the 
>> understanding of the USER, not on the SOFTWARE. So, when dealing with 
>> temporal trends, one needs to consider carefully the intended type of use of 
>> it. I think Berthold is more concerned with continuous variables such as 
>> temperature, SAC, dive duration, depth, etc which could probably be 
>> reasonably easily implemented. To represent categorical variables such as 
>> tags, dive mode, people and suit (one could even add dive site) is a totally 
>> different issue requiring a totally different type of visual representation.
>> 
> 
> I was in complete agreement until the very last sentence. I don't understand 
> why this 'per se' requires a "totally different type of visual 
> representation".
> Let's say I am charting SAC over my criteria. Let's assume I'm using box and 
> whiskers charts to easily show the quartiles. The values on x-axis have 
> implications for the interpretation, of course, but whether the x-axis is 
> months of the year, the suit worn, the maximum depth of the dive, the tags 
> present on the dive (e.g., teaching dive or non-teaching dive) has absolutely 
> no impact on how this should be visually represented...
> 
>> It would help, in this discussion, if one were to distinguish between the 
>> filtering aspect and the statistics display aspect and state that with 
>> respect to the argument. In Dirk's artwork above, I am not sure how the 
>> constraints will be used. Are we talking of the filtering process or the 
>> stats display mechanism? Let's say "Suit" is a constraint and two dates are 
>> provided. I am not sure what the expected result of the operation would be. 
>> Ahh, the problems of communication.
>> 
> 
> What I was trying to describe was a way to create criteria that can be used 
> for columns in the visualization. You go through this filter process, name 
> the result, and that name becomes one of the available labels over which you 
> can chart the values.
> Again, as I said before, I may simply be over-engineering this.
> 
>> 
>> In general, in my opinion, the existing filter layout is a good starting 
>> point (I would add the variables of dive depth and dive duration because 
>> they are the two variables that fundamentally define a dive). As a filtering 
>> mechanism the current implementation is ultra-flexible.
>> 
> 
> While I respect your opinion, let me politely state that personally I believe 
> that the current filter widget is a disaster and extremely unintuitive to 
> use. That's not a criticism of the original author, nor of the people who 
> have added to it - but yeah, that thing is a mess.
> 
>> As far as UI for filter sets are concerned the minimum component count would 
>> include: Combobox of existing named filters within the set. Button: add 
>> current filter to filter set. These could potentially reside at the top 
>> right of the current filter panel. But there might be a need to give filter 
>> set a name as well. That would need a text box.
>> 
> 
> Making the current widget more convoluted and more confusing was not a 
> direction that I was envisioning us to go.
> 
> 
> Maybe we need to rain in the crazy German and go back to something much more 
> basic. Something like ten predefined sets of criteria. And only apply them to 
> the filtered dive list.
> 
> So.
> (1) per month
> (2) per year
> (3) per trip
> (4) by max depth in 10m increments
> (5) by duration in 10min increments
> (6) by min temperature in 10F / 5C increments
> (7) by type (for people who track more than SCUBA)
> (8) by suit (that's likely a fairly small set for most people)
> (9) by tags (that one I'm unclear about - would likely need some more ability 
> to influence how this is drawn - but straight forward would be to draw them 
> in pairs of two, left one represents with the tag, right one without the tag)
> (10) by people? (no idea how / why)
> (11) by full 

Re: RFC: Statistics in Subsurface

[Dirk Hohndel via subsurface]

Hi Willem,

Thanks for responding... I wish more people got involved into these 
conversations. But usually topics like this get two or three of the 300+ people 
here to respond. And then ten more will complain after we have done the next 
release and they notice for the first time that we added a feature...

> On May 12, 2020, at 12:59 AM, Willem Ferguson 
>  wrote:
> I understand Berthold's request with respect to temporal sequences. When 
> developing such a temporal facility there is an important caveat. 
> Emphatically, such temporal representations do not provide any clear 
> *explanation* of anything: it is just a temporal pattern. For instance a 
> decrease in SAC rate over time does not necessarily imply any improvement in 
> physiological ability but may reflect adoption of new equipment or change in 
> dive sites. Any explanation of a temporal trend is dependent on the 
> understanding of the USER, not on the SOFTWARE. So, when dealing with 
> temporal trends, one needs to consider carefully the intended type of use of 
> it. I think Berthold is more concerned with continuous variables such as 
> temperature, SAC, dive duration, depth, etc which could probably be 
> reasonably easily implemented. To represent categorical variables such as 
> tags, dive mode, people and suit (one could even add dive site) is a totally 
> different issue requiring a totally different type of visual representation.
> 

I was in complete agreement until the very last sentence. I don't understand 
why this 'per se' requires a "totally different type of visual representation".
Let's say I am charting SAC over my criteria. Let's assume I'm using box and 
whiskers charts to easily show the quartiles. The values on x-axis have 
implications for the interpretation, of course, but whether the x-axis is 
months of the year, the suit worn, the maximum depth of the dive, the tags 
present on the dive (e.g., teaching dive or non-teaching dive) has absolutely 
no impact on how this should be visually represented...

> It would help, in this discussion, if one were to distinguish between the 
> filtering aspect and the statistics display aspect and state that with 
> respect to the argument. In Dirk's artwork above, I am not sure how the 
> constraints will be used. Are we talking of the filtering process or the 
> stats display mechanism? Let's say "Suit" is a constraint and two dates are 
> provided. I am not sure what the expected result of the operation would be. 
> Ahh, the problems of communication.
> 

What I was trying to describe was a way to create criteria that can be used for 
columns in the visualization. You go through this filter process, name the 
result, and that name becomes one of the available labels over which you can 
chart the values.
Again, as I said before, I may simply be over-engineering this.

> In general, in my opinion, the existing filter layout is a good starting 
> point (I would add the variables of dive depth and dive duration because they 
> are the two variables that fundamentally define a dive). As a filtering 
> mechanism the current implementation is ultra-flexible.
> 

While I respect your opinion, let me politely state that personally I believe 
that the current filter widget is a disaster and extremely unintuitive to use. 
That's not a criticism of the original author, nor of the people who have added 
to it - but yeah, that thing is a mess.

> As far as UI for filter sets are concerned the minimum component count would 
> include: Combobox of existing named filters within the set. Button: add 
> current filter to filter set. These could potentially reside at the top right 
> of the current filter panel. But there might be a need to give filter set a 
> name as well. That would need a text box.
> 

Making the current widget more convoluted and more confusing was not a 
direction that I was envisioning us to go.


Maybe we need to rain in the crazy German and go back to something much more 
basic. Something like ten predefined sets of criteria. And only apply them to 
the filtered dive list.

So.
(1) per month
(2) per year
(3) per trip
(4) by max depth in 10m increments
(5) by duration in 10min increments
(6) by min temperature in 10F / 5C increments
(7) by type (for people who track more than SCUBA)
(8) by suit (that's likely a fairly small set for most people)
(9) by tags (that one I'm unclear about - would likely need some more ability 
to influence how this is drawn - but straight forward would be to draw them in 
pairs of two, left one represents with the tag, right one without the tag)
(10) by people? (no idea how / why)
(11) by full text? (no idea how / why)

If we drop the last three this seems fairly obvious how to do.

Next comes the question of visualization. That might depend on the data (so the 
columns of the yearly statistics). At first glance I thought that box and 
whiskers charts might be useful, or more simplified min / avg / max charts (so 
floating bar with a circle 

Re: [OS X] git-load: string marker after running out of strings ('name')

[Linus Torvalds via subsurface]

On Tue, May 12, 2020 at 10:55 AM Linus Torvalds
 wrote:
>
> I'll send Dirk a pull request to just remove the warning.

Done.

Dirk - holler if you want me to just merge trivial things like this
(after the tests pass, of course).

It's removing not just the warning, but the whole test for the
zero-sized string case, because without the warning it's no longer
even a special condition any more.

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

Re: [OS X] git-load: string marker after running out of strings ('name')

[Linus Torvalds via subsurface]

On Tue, May 12, 2020 at 4:04 AM Attilla de Groot via subsurface
 wrote:
>
> Since the upgrade to 4.9.4 I get the message "git-load: string marker
> after running out of strings ('name’)” in a large red bar on the
> bottom of the window when starting Subsurface. It doesn’t seem to
> affect anything.

The problem isn't new, it's just that now we report about it. We had a
problem with a save format that would corrupt the event name for dive
mode changes. We actually have a fix in place so that we restore the
event names, but the warning will happen every time you load a dive
that has that old sign of corruption.

So it's benign, and we probably should make the warning much less
noticeable (just put it in the logs as a debug message).

> Is there anything I can provide to give some more useful information on this?

Don't worry about it, and you should probably just ignore it (at least
as long as it says 'name' or 'description' - the first is about a
divemode event, the second is a similar error we had wrt cylinder
descriptions).

The error is very prominent because there was some worry that we had
other issues going on, but I think we sorted it all out and we should
just de-emphasize it.

I'll send Dirk a pull request to just remove the warning.

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

Re: Re-syncing with Jef's upstream..

[Jef Driesen via subsurface]

On 8/05/2020 00:57, Linus Torvalds wrote:

Ok, so I've just spent several hours re-synchronizing our subsurface
branch with Jef's upstream.

...


I'll have a look, allthough that might take a while. Been a bit busy with real 
life during the corona crisis (day job, kids and family), so a bit less time 
left for libdivecomputer right now :-(



Jef - that "Suunto Eon Steel: sort the dive list properly" commit is
very much a bug-fix. You should take it, regardless of any subsurface
interface issues.


A wasn't aware of any issues there. I will look into it.


So is the BlueLink Pro thing, for that matter.


The bluelink pro fix is a bit problematic. There are indeed cases where 
splitting the command makes things work (mainly for subsurface users it seems). 
But I have also reports where it actually causes the communication to fail, 
while the plain libdivecomputer version works fine. So the result is that 
whatever approach we take, it's going to break for some users. That's why I 
didn't apply that change.


So far I haven't been able to figure out what the pattern is. Is this something 
related to the dive computer model, the operating system, or the BLE framework 
(Qt, .NET, Android)? I want to collect some information on that, to see if we 
can implement something that works for everyone. I'll need some more data from 
users.


Another thing that crossed my mind is to implement some kind of autodetection. 
Start with one approach, and if that fails switch to the other one.



The rest is mostly either new backends (ie the Garmin Descent and the
Deeplu Cosmiq), or the extended string interface support.

Anyway, exactly *because* the new tree is bit-for-bit identical
between the NG and DS9 branches, there's no difference on a code level
between the two, and the only real difference is that DS9 makes it
much easier to see what the changes are from Jef's point.


I usually do a diff once in a while to check the changes, but this is certainly 
easier!


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

[OS X] git-load: string marker after running out of strings ('name')

[Attilla de Groot via subsurface]

Hi,

Since the upgrade to 4.9.4 I get the message "git-load: string marker after 
running out of strings ('name’)” in a large red bar on the bottom of the window 
when starting Subsurface. It doesn’t seem to affect anything.

Is there anything I can provide to give some more useful information on this?


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

Re: Current rating in log (OS X)

[Attilla de Groot via subsurface]

> On 11 May 2020, at 17:37, Dirk Hohndel  wrote:
> 
> 
> 
>> On May 11, 2020, at 7:28 AM, Attilla de Groot via subsurface 
>>  wrote:
>> 
>> Hi,
>> 
>> Yesterday I updated to the latest Subsurface version on OS X and I notcied 
>> that the Information tab was updated. This has a small display bug as in the 
>> attached screenshot.
>> 
>> I think that with “Current” Strong/Weak should be reversed or perhaps not 
>> indicated in stars. :-)
> 
> There was some discussion about that when those new measurements were 
> introduced.
> We settled on "the number of stars should reflect how good, how comfortable, 
> how fun a dive was".
> So weak current, low surge, great visibility, etc.
> 
> I find myself at times disagreeing with this (even though it was MY 
> suggestion), but every time I step back and ask myself "what's a dive with 
> all ratings 5 stars - which is what we are trained as consumers to think of 
> as 'perfect'?"
> And high surge, high current, high chill don't fit that perception. So that's 
> why I think what we do is correct.

Ok, I didn't want to restart any discussion around this. It seems that you have 
given it sufficient thought and I can see that reasoning.


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