Re: Cloud Site Issue

[Peter Zaal]

On Wed, Aug 15, 2018 at 3:56 AM Dirk Hohndel  wrote:

>
> Are there ways to mark things on the server so that the browsers don’t
>> cache the .js files that we send? Because that’s the #1 source of user
>> problems - old versions of files in the browser cache.
>
>
> A pretty quick solution would be to configure the Apache server. We just
> need to send the proper caching headers (specifically, we need apache to
> send the *no-cache *header, the browser will handle the rest).
>
> *One method to do so here:*
>
> Add a .htaccess file to the root of the web directory, and add the
> following:
>
> 
> Header set Cache-Control "no-cache"
> Header set Pragma "no-cache"
> 
>
> To add more files to the caching rule, just add them in the parens above,
> separated by a pipe.
>
> If you want to do it for all of the files just use:
>
> 
> ...
> 
>
> Happy to discuss further or help implement on the server. My one concern
> about the above approach is how does the stat.js file get created? Is it
> made on request? Or is it updated in some sort of user directory each time
> the server gets a cloud sync? If it's made on request, we'll just need to
> make sure the response handler is also giving the no-cache header.
>
>
> The files are created on every push to a user's repo, but are otherwise
> static.
>

Just to mention another solution is to add a query parameter with a random
value at the url, e.g. \myscript.js?t=
Either with an random number for every request, or have the number changed
only with every update of the script. The latter is the best since this
will allow the browser to get the script only the first time and use it
from cache the next times.

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

Re: Cloud Site Issue

[Dirk Hohndel]

> On Aug 14, 2018, at 5:22 PM, Bryan Oliver  wrote:
> 
> That should happen fairly quickly… usually faster than people are able to 
> test. I wonder what delayed it.
> 
> I think it was user error. When I sent the second email stating it worked, I 
> had tried it on my phone (and that was the first time I had requested it from 
> my phone, aka no cache). Then I went back to my desktop, and still no dice 
> until I cleared cache like you mentioned.

Ah, ok. That explains it and makes me feel better.

> Are there ways to mark things on the server so that the browsers don’t cache 
> the .js files that we send? Because that’s the #1 source of user problems - 
> old versions of files in the browser cache.
> 
> A pretty quick solution would be to configure the Apache server. We just need 
> to send the proper caching headers (specifically, we need apache to send the 
> no-cache header, the browser will handle the rest).
> 
> One method to do so here:
> 
> Add a .htaccess file to the root of the web directory, and add the following:
> 
> 
>   Header set Cache-Control "no-cache"
>   Header set Pragma "no-cache"
> 
> 
> To add more files to the caching rule, just add them in the parens above, 
> separated by a pipe.
> 
> If you want to do it for all of the files just use:
> 
> 
> ...
> 
> 
> Happy to discuss further or help implement on the server. My one concern 
> about the above approach is how does the stat.js file get created? Is it made 
> on request? Or is it updated in some sort of user directory each time the 
> server gets a cloud sync? If it's made on request, we'll just need to make 
> sure the response handler is also giving the no-cache header. 

The files are created on every push to a user's repo, but are otherwise static.
I'll try your suggestion. Thanks.

> There are many more areas where we would love to get help - your areas of 
> expertise are a bit vague, can you provide some more background (if you don’t 
> want to do that in public than personal email to me is fine, too).
> 
> I'll shoot you an email.  

Great!

/D

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

Re: Cloud Site Issue

[Bryan Oliver]

>
> That should happen fairly quickly… usually faster than people are able to
> test. I wonder what delayed it.


I think it was user error. When I sent the second email stating it worked,
I had tried it on my phone (and that was the first time I had requested it
from my phone, aka no cache). Then I went back to my desktop, and still no
dice until I cleared cache like you mentioned.

Are there ways to mark things on the server so that the browsers don’t
> cache the .js files that we send? Because that’s the #1 source of user
> problems - old versions of files in the browser cache.


A pretty quick solution would be to configure the Apache server. We just
need to send the proper caching headers (specifically, we need apache to
send the *no-cache *header, the browser will handle the rest).

*One method to do so here:*

Add a .htaccess file to the root of the web directory, and add the
following:


Header set Cache-Control "no-cache"
Header set Pragma "no-cache"


To add more files to the caching rule, just add them in the parens above,
separated by a pipe.

If you want to do it for all of the files just use:


...


Happy to discuss further or help implement on the server. My one concern
about the above approach is how does the stat.js file get created? Is it
made on request? Or is it updated in some sort of user directory each time
the server gets a cloud sync? If it's made on request, we'll just need to
make sure the response handler is also giving the no-cache header.


There are many more areas where we would love to get help - your areas of
> expertise are a bit vague, can you provide some more background (if you
> don’t want to do that in public than personal email to me is fine, too).


I'll shoot you an email.

thanks,
Bryan


On Tue, Aug 14, 2018 at 5:16 PM Dirk Hohndel  wrote:

> On Aug 14, 2018, at 2:13 PM, Bryan Oliver 
> wrote:
>
> Update, I just checked again and they are now showing up. I guess it just
> took a while.
>
>
> That should happen fairly quickly… usually faster than people are able to
> test. I wonder what delayed it.
>
> One issue is that often browsers cache some of the files we modify - see
> below :-)
>
> On Tue, Aug 14, 2018, 4:45 PM Bryan Oliver 
> wrote:
>
>> Hey Dirk,
>>
>> I was attempting to play with the cloud.subsurface-divelog.org site
>> today. I manually entered a dive into the Mobile app and then processed a
>> Manual sync. It shows up without issue in the Desktop app, but has yet to
>> show up on the site. Do I need to run something else to get it to show up
>> there?
>>
>> Also thought I'd mention, web and web mobile are areas I can do a lot of
>> work on. So if we have any ideas for improving/adding to the cloud web page
>> I'd be happy to take on some of those challenges. I didn't see anything in
>> the github issues (granted I only looked for a brief time) so thought I'd
>> mention it here.
>>
>
> Are there ways to mark things on the server so that the browsers don’t
> cache the .js files that we send? Because that’s the #1 source of user
> problems - old versions of files in the browser cache.
>
> There are many more areas where we would love to get help - your areas of
> expertise are a bit vague, can you provide some more background (if you
> don’t want to do that in public than personal email to me is fine, too).
>
> Thanks
>
> /D
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cloud Site Issue

[Dirk Hohndel]

> On Aug 14, 2018, at 2:13 PM, Bryan Oliver  wrote:
> 
> Update, I just checked again and they are now showing up. I guess it just 
> took a while.

That should happen fairly quickly… usually faster than people are able to test. 
I wonder what delayed it.

One issue is that often browsers cache some of the files we modify - see below 
:-)

> On Tue, Aug 14, 2018, 4:45 PM Bryan Oliver  > wrote:
> Hey Dirk, 
> 
> I was attempting to play with the cloud.subsurface-divelog.org 
>  site today. I manually entered a dive 
> into the Mobile app and then processed a Manual sync. It shows up without 
> issue in the Desktop app, but has yet to show up on the site. Do I need to 
> run something else to get it to show up there?
> 
> Also thought I'd mention, web and web mobile are areas I can do a lot of work 
> on. So if we have any ideas for improving/adding to the cloud web page I'd be 
> happy to take on some of those challenges. I didn't see anything in the 
> github issues (granted I only looked for a brief time) so thought I'd mention 
> it here.

Are there ways to mark things on the server so that the browsers don’t cache 
the .js files that we send? Because that’s the #1 source of user problems - old 
versions of files in the browser cache.

There are many more areas where we would love to get help - your areas of 
expertise are a bit vague, can you provide some more background (if you don’t 
want to do that in public than personal email to me is fine, too).

Thanks

/D

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

Re: Cloud Site Issue

[Bryan Oliver]

Update, I just checked again and they are now showing up. I guess it just
took a while.

On Tue, Aug 14, 2018, 4:45 PM Bryan Oliver 
wrote:

> Hey Dirk,
>
> I was attempting to play with the cloud.subsurface-divelog.org site
> today. I manually entered a dive into the Mobile app and then processed a
> Manual sync. It shows up without issue in the Desktop app, but has yet to
> show up on the site. Do I need to run something else to get it to show up
> there?
>
> Also thought I'd mention, web and web mobile are areas I can do a lot of
> work on. So if we have any ideas for improving/adding to the cloud web page
> I'd be happy to take on some of those challenges. I didn't see anything in
> the github issues (granted I only looked for a brief time) so thought I'd
> mention it here.
>
> cheers,
> Bryan
>
>
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Cloud Site Issue

[Bryan Oliver]

Hey Dirk,

I was attempting to play with the cloud.subsurface-divelog.org site today.
I manually entered a dive into the Mobile app and then processed a Manual
sync. It shows up without issue in the Desktop app, but has yet to show up
on the site. Do I need to run something else to get it to show up there?

Also thought I'd mention, web and web mobile are areas I can do a lot of
work on. So if we have any ideas for improving/adding to the cloud web page
I'd be happy to take on some of those challenges. I didn't see anything in
the github issues (granted I only looked for a brief time) so thought I'd
mention it here.

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

Re: Troubles with SmartTrak log import

[TACHOUERES Franck]

Hi everyone,

I just achieved my diving log import completion.
Smtk2ssrf worked fine for all my dives except the #412 (found by dichotomy).

So now I have a complete ssrf log with many dive curves and i am glad with
that!

A big thank you for all your work ;-)

Regards,
Franck

2018-08-14 19:52 GMT+02:00 Linus Torvalds :

> On Sat, Aug 11, 2018 at 2:35 AM Salvador Cuñat 
> wrote:
> >
> > The issue is quite weird:
> > 1.- I can only reproduce it with Franck's file.
> > 2.- It crashes with previous versions (at least not a regression).
> > 3.- We get a SIGBUS while running release mode, but not in debug mode.
>
> Have you tried running it under valgrind?
>
> valgrind is quite good at finding "oops, the program does something
> wrong" that causes random memory corruption etc.
>
> How do you even build that SmartTrak importer? Not that I'll likely
> have any time to look at it since I'm in the kernel merge window hell
> right now.
>
>Linus
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Troubles with SmartTrak log import

[Linus Torvalds]

On Sat, Aug 11, 2018 at 2:35 AM Salvador Cuñat  wrote:
>
> The issue is quite weird:
> 1.- I can only reproduce it with Franck's file.
> 2.- It crashes with previous versions (at least not a regression).
> 3.- We get a SIGBUS while running release mode, but not in debug mode.

Have you tried running it under valgrind?

valgrind is quite good at finding "oops, the program does something
wrong" that causes random memory corruption etc.

How do you even build that SmartTrak importer? Not that I'll likely
have any time to look at it since I'm in the kernel merge window hell
right now.

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

Re: OSTC firmware upgrade partially broken

[Dirk Hohndel]

> On Aug 14, 2018, at 7:59 AM, Jef Driesen  wrote:
> 
> On 2018-08-14 16:47, Dirk Hohndel wrote:
>>> On Aug 14, 2018, at 7:40 AM, Jan Mulder  wrote:
>>> Since May 19, 2018 Heinrichs-Weikamp introduced something new with respect 
>>> to firmware numbering. On that date a version was released called 2.97 SP1. 
>>> As I found a simple bug related to CNS display yesterday, I was looking at 
>>> the HW website and found out that I never had a message from Subsurface 
>>> about this new version of the firmware.
>>> Some observations:
>>> 1) libdivecomputer seems to report the same (integer) version number for 
>>> 2.97 and 2.97-SP1. I just upgraded my OSTC3+, and the version stays 609. 
>>> This seems something for Jef, but not sure this breaks anything at the 
>>> Subsurface end
>> We have the version string in Subsurface. Does that change? It
>> certainly appears to deal with X.Y.Z plus a bit for 'beta'.
>> You can see it under extra data.
> 
> That's the decoding of the OSTC4 firmware version. For the OSTC3 it's just X.Y

Thanks, Jef - I noticed that after sending the email :-(

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

Re: OSTC firmware upgrade partially broken

[Jef Driesen]

On 2018-08-14 16:47, Dirk Hohndel wrote:

On Aug 14, 2018, at 7:40 AM, Jan Mulder  wrote:

Since May 19, 2018 Heinrichs-Weikamp introduced something new with 
respect to firmware numbering. On that date a version was released 
called 2.97 SP1. As I found a simple bug related to CNS display 
yesterday, I was looking at the HW website and found out that I never 
had a message from Subsurface about this new version of the firmware.


Some observations:
1) libdivecomputer seems to report the same (integer) version number 
for 2.97 and 2.97-SP1. I just upgraded my OSTC3+, and the version 
stays 609. This seems something for Jef, but not sure this breaks 
anything at the Subsurface end


We have the version string in Subsurface. Does that change? It
certainly appears to deal with X.Y.Z plus a bit for 'beta'.
You can see it under extra data.


That's the decoding of the OSTC4 firmware version. For the OSTC3 it's 
just X.Y


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

Re: OSTC firmware upgrade partially broken

[Dirk Hohndel]

> On Aug 14, 2018, at 7:40 AM, Jan Mulder  wrote:
> 
> Since May 19, 2018 Heinrichs-Weikamp introduced something new with respect to 
> firmware numbering. On that date a version was released called 2.97 SP1. As I 
> found a simple bug related to CNS display yesterday, I was looking at the HW 
> website and found out that I never had a message from Subsurface about this 
> new version of the firmware.
> 
> Some observations:
> 1) libdivecomputer seems to report the same (integer) version number for 2.97 
> and 2.97-SP1. I just upgraded my OSTC3+, and the version stays 609. This 
> seems something for Jef, but not sure this breaks anything at the Subsurface 
> end

We have the version string in Subsurface. Does that change? It certainly 
appears to deal with X.Y.Z plus a bit for 'beta'.
You can see it under extra data.

> 2) A HW download of a .txt is used by Subsurface to detect the latest 
> firmware version available. This .txt looks like this:
> 
> 
> [2.97]
> MD5: ec864820ee576841a2805227d7b39a99
> 
> - Stable Version - SP1
> 
> 
> [2.97]
> MD5: 2f97a168530d2c86a43bbe382dde92ad
> 
> - Stable Version -
> 
> 
> etc.
> 
> 
> And we do a simple check of the first line. And, we do not detect a 2.97 SP1 
> version like this. For us (Subsurface) the easiest way out might be to ask HW 
> to number these SP releases like 2.97.1 or explicitly define the new firmware 
> versioning scheme, and add some parsing for the SP deal at our end.

Yes, that would seem better. Matthias, is this something you could change on 
your end? Because in the text file the [2.97] does look unchanged to the 
previous one below...

> 3) And just upgraded my OSTC to 2.97 SP1 using Subsurface (manual selection 
> of the proper .hex file) and that works just fine. So its the notification to 
> the user that there is a newer firmware version available that is broken.

I'm glad - that part should be the easier one to fix :-)

Thanks for the report, Jan.

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

OSTC firmware upgrade partially broken

[Jan Mulder]

Since May 19, 2018 Heinrichs-Weikamp introduced something new with 
respect to firmware numbering. On that date a version was released 
called 2.97 SP1. As I found a simple bug related to CNS display 
yesterday, I was looking at the HW website and found out that I never 
had a message from Subsurface about this new version of the firmware.


Some observations:
1) libdivecomputer seems to report the same (integer) version number for 
2.97 and 2.97-SP1. I just upgraded my OSTC3+, and the version stays 609. 
This seems something for Jef, but not sure this breaks anything at the 
Subsurface end
2) A HW download of a .txt is used by Subsurface to detect the latest 
firmware version available. This .txt looks like this:



[2.97]
MD5: ec864820ee576841a2805227d7b39a99

- Stable Version - SP1


[2.97]
MD5: 2f97a168530d2c86a43bbe382dde92ad

- Stable Version -


etc.


And we do a simple check of the first line. And, we do not detect a 2.97 
SP1 version like this. For us (Subsurface) the easiest way out might be 
to ask HW to number these SP releases like 2.97.1 or explicitly define 
the new firmware versioning scheme, and add some parsing for the SP deal 
at our end.


3) And just upgraded my OSTC to 2.97 SP1 using Subsurface (manual 
selection of the proper .hex file) and that works just fine. So its the 
notification to the user that there is a newer firmware version 
available that is broken.


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