Re: Any brave dive computer download testers out there?

[Jérémie Guichard]

Hi guys,

I just tried Scubapro G2 over bluetooth on Android build and it did not
work, but I must say this was already the case on Android for the normal
release.
This use case was working few month ago but cannot remember the version it
was.

I'm not sure it actually helps but I attached the log file.

Jeremie



2018-04-20 23:10 GMT+07:00 Murillo Bernardes <mfbernar...@gmail.com>:

> Successfully downloaded dives on a Mac from:
> - Oceanic OCi over USB
> - Perdix AI over BLE
>
> Murillo Bernardes
>
> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard <djebr...@gmail.com>
> wrote:
>
>> Hey guys,
>>
>> Just tried this build on Windows 10: https://github.com/Subsurf
>> ace-divelog/subsurface/releases/download/continuous-NG/
>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>
>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.
>>
>> Jeremie
>>
>> 2018-04-20 9:56 GMT+07:00 Matt Thompson <math...@gmail.com>:
>>
>>>
>>>
>>> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel <d...@hohndel.org> wrote:
>>>
>>>>
>>>> We now have binaries for Windows, Mac, and Linux (AppImage only)
>>>> available in order for people to test this.
>>>>
>>>> https://github.com/Subsurface-divelog/subsurface/releases/ta
>>>> g/continuous-NG
>>>>
>>>>
>>>> I tested all three of my computers on Windows 10, macOS 10.13.4, and
>>> Fedora 27.
>>>
>>> My Aqualung i750TC worked correctly on all three platforms using the USB
>>> cable.
>>>
>>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I
>>> think the failure on Linux is a configuration issue on my part but for
>>> completeness I get the following in the console:
>>> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
>>> (atomics_cobalt_device_open)]
>>> INFO: dc_deveice_open error value of -6
>>> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
>>> and Subsurface-4.7.8-x86_64.AppImage.
>>>
>>> My Suunto D4i failed on all three platforms.  It gave various errors on
>>> the platforms:
>>> Windows 10:
>>>  the red banner at the bottom of the main window with the message
>>> "Unsupported operation"
>>>
>>> Fedora: A message box  with the message "Unable to open /dev/ttyUSB0"
>>> and a message on the console "ERROR: Failed to receive the answer. [in
>>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>>
>>> macOS: A message box with the message "Error downloading dive data"
>>>
>>>
>>>
>>> ___
>>> subsurface mailing list
>>> subsurface@subsurface-divelog.org
>>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>>
>>>
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>


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

Re: Any brave dive computer download testers out there?

[Jérémie Guichard]

Hey guys,

Just tried this build on Windows 10:
https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-NG/subsurface-4.7.8-73-ga12ea13d51f5.exe

With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.

Jeremie

2018-04-20 9:56 GMT+07:00 Matt Thompson :

>
>
> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel  wrote:
>
>>
>> We now have binaries for Windows, Mac, and Linux (AppImage only)
>> available in order for people to test this.
>>
>> https://github.com/Subsurface-divelog/subsurface/releases/ta
>> g/continuous-NG
>>
>>
>> I tested all three of my computers on Windows 10, macOS 10.13.4, and
> Fedora 27.
>
> My Aqualung i750TC worked correctly on all three platforms using the USB
> cable.
>
> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I
> think the failure on Linux is a configuration issue on my part but for
> completeness I get the following in the console:
> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
> (atomics_cobalt_device_open)]
> INFO: dc_deveice_open error value of -6
> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
> and Subsurface-4.7.8-x86_64.AppImage.
>
> My Suunto D4i failed on all three platforms.  It gave various errors on
> the platforms:
> Windows 10:
>  the red banner at the bottom of the main window with the message
> "Unsupported operation"
>
> Fedora: A message box  with the message "Unable to open /dev/ttyUSB0" and
> a message on the console "ERROR: Failed to receive the answer. [in
> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>
> macOS: A message box with the message "Error downloading dive data"
>
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Documenting coding conventions for new comers.

[Jérémie Guichard]

Ok, I'll create the new section in CodingStyle. What about converting this
file (CodingStyle) to markdown format?

2018-04-09 16:44 GMT+02:00 Dirk Hohndel :

>
> On Apr 9, 2018, at 3:26 AM, Miika Turkia  wrote:
>
>>
>> To cope with this I've prepared a change introducing a new CONVENTIONS.md
>> file that is meant to collect such information: https://github.co
>> m/Subsurface-divelog/subsurface/pull/1196 Any feedback is welcome. Since
>> it is the one convention I learned during a recent pull request I proposed,
>> I started with documenting the use of membuffer for string manipulations...
>>
>
> What is the distinction between the existing CodingStyle and the proposed
> CONVENTIONS.md? IMO, what you currently have there could have easily been
> included in the CodingStyle. Having all the essential information in single
> place sounds better for newcomers.
>
>
> I think I'll have to agree with Miika on this one. Fewer places to read
> through make it easier for people to find what they are looking for.
> One could of course argue that using membuffer and other such conventions
> technically aren't coding style, but I think with a slightly more liberal
> interpretation of that term... simply add a section called "Conventions" to
> the CodingStyle document and I think we will all be happier :-)
>
>
> Then if/when the currently discussed pull request would be approved it
>> would be nice to reflect these changes in the corresponding page on
>> https://subsurface-divelog.org. The question is: Was this page manually
>> edited in Subsurface-website repository or was it actually generated from
>> markdown? If so, is the script available somewhere?
>>
>> IIRC these are edited directly.
>
>
> The website is run on a WordPress instance that is synced (in a somewhat
> fragile manner) with a GitHub repo. So the sources for the page in question
> should be here:
>
> https://github.com/Subsurface-divelog/Subsurface-website/
> blob/master/_pages/contributing.en
>
> The translations of the website are unfortunately not as well maintained
> as one might hope (this is all volunteer work and it's tedious work...),
> but you can see the translations in the GitHub repo as well.
>
> /D
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Documenting coding conventions for new comers.

[Jérémie Guichard]

Hi everybody,

It is not easy for new comers to know about conventions and best practices
to be followed when contributing to Subsurface. This creates overhead for
new comers and code maintainers.
New comers have to extensively browse the code to find utility functions
(or end up re-implement things that already exist), figure what should be
done where, etc... and often end up having to re-implement fixes since
original pull request do not follow Subsurface development common practices.
Code maintainers spend lot of time (re)explaining such practices while
doing code reviews.

To cope with this I've prepared a change introducing a new CONVENTIONS.md
file that is meant to collect such information:
https://github.com/Subsurface-divelog/subsurface/pull/1196 Any feedback is
welcome. Since it is the one convention I learned during a recent pull
request I proposed, I started with documenting the use of membuffer for
string manipulations...

I know that the majority of frequent contributors (that are the ones
knowing such conventions) do not have much free time to spend on describing
them. On my side I'm still pretty fresh with Subsurface development and do
not yet know much of them, but do currently have some free time to spend on
this topic. So feel free to post me a small note in this thread with some
of the conventions you know about, I'll happily prepare pull request with
detailed descriptions and examples.

While I'm talking about documentation for contributors, I have a question
regarding Subsurface website, more specifically the
https://subsurface-divelog.org/documentation/contributing/ page.
I've made a (already merged) change with a mention to the usage of
CHANGELOG.md https://github.com/Subsurface-divelog/subsurface/pull/1194
I have another one (to be reviewed) fixing few spelling mistakes:
https://github.com/Subsurface-divelog/subsurface/pull/1195
Then if/when the currently discussed pull request would be approved it
would be nice to reflect these changes in the corresponding page on
https://subsurface-divelog.org. The question is: Was this page manually
edited in Subsurface-website repository or was it actually generated from
markdown? If so, is the script available somewhere?

Wish you all a great day,

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

Re: Map issue with release 4.7.8 under windows 10

[Jérémie Guichard]

When I read your reply, I looked for the file and did have it. Just to be
certain, I fully uninstalled subsurface and installed again, the file was
not there anymore. Re-downloaded the installer, re-installed now the file
is there and the map are displayed.

I was curious and I tried to reproduce the problem; went back to 4.7.7,
re-installed 4.7.8 without uninstall (as I did when the issue happened) but
everything works, so I really don't understand what happened the first
time...

Anyway seems this was a false alarm, sorry for that, and thanks for the
hint.

Jeremie

2018-04-06 1:11 GMT+07:00 Lubomir I. Ivanov <neolit...@gmail.com>:

> On 5 April 2018 at 21:02, Jérémie Guichard <jeremie.guich...@gmail.com>
> wrote:
> > Hi guys,
> >
> > I just installed latest 4.7.8 release on windows 10 machine, seems there
> is
> > an issue with map rendering. Has anybody seen the map working in windows
> > with 4.7.8?
> >
>
> yes, it works for me. just installed the official build.
> (see attached screenshot)
>
> > For me Subsurface starts but no map get displayed, running from console
> with
> > - v -v I get:
> >
> > Subsurface v4.7.8,
> > built with libdivecomputer v0.7.0-devel-Subsurface-branch
> > (d02f1c3cdcc6a04d085538578d872ec6e3282382)
> > built with Qt Version 5.10.1, runtime from Qt Version 5.10.1
> > built with libgit2 0.26.0
> > "validateGL(): created OpenGLContext."
> > "validateGL(): obtained QOpenGLFunctions."
> > "validateGL(): detected OpenGL version 4.0."
>
> the OpenGL version seems good.
>
> > added supported DC:  Suunto   Solution
> > added supported DC:  Suunto   Eon
> > ...
> > QFont::setPointSizeF: Point size <= 0 (0.00), must be greater than 0
> > Plugins Directory:  QDir( "C:/Program Files (x86)/Subsurface/plugins" ,
> > nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) ,
> > QDir::Filters( Dirs|Files|Drives|AllEntries ) )
> > qrc:/MapWidget.qml:24: Error: Cannot assign [undefined] to
> > QDeclarativeGeoMapType*
> > loading dive data from
> > ("C:\\Users\\Jérémie\\AppData\\Roaming\\Subsurface\\Jérémie.xml")
> > Unable to match dive 'program.divelog' (subsurface)
> > Unable to match dive 'version.divelog' (3)
> > Set the current dive site: 0
> > Set the current dive site: 0
> >
> > File locations:
> > ...
> >
> > My best guess is that issue has something to do with:
> > qrc:/MapWidget.qml:24: Error: Cannot assign [undefined] to
> > QDeclarativeGeoMapType*
> >
>
> are you missing the following file by any chance?:
> \plugins\geoservices\qtgeoservices_googlemaps.dll
>
> lubomir
> --
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Map issue with release 4.7.8 under windows 10

[Jérémie Guichard]

Hi guys,

I just installed latest 4.7.8 release on windows 10 machine, seems there is
an issue with map rendering. Has anybody seen the map working in windows
with 4.7.8?

For me Subsurface starts but no map get displayed, running from console
with - v -v I get:

Subsurface v4.7.8,
built with libdivecomputer v0.7.0-devel-Subsurface-branch
(d02f1c3cdcc6a04d085538578d872ec6e3282382)
built with Qt Version 5.10.1, runtime from Qt Version 5.10.1
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 4.0."
added supported DC:  Suunto   Solution
added supported DC:  Suunto   Eon
...
QFont::setPointSizeF: Point size <= 0 (0.00), must be greater than 0
Plugins Directory:  QDir( "C:/Program Files (x86)/Subsurface/plugins" ,
nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) ,
QDir::Filters( Dirs|Files|Drives|AllEntries ) )
qrc:/MapWidget.qml:24: Error: Cannot assign [undefined] to
QDeclarativeGeoMapType*
loading dive data from
("C:\\Users\\Jérémie\\AppData\\Roaming\\Subsurface\\Jérémie.xml")
Unable to match dive 'program.divelog' (subsurface)
Unable to match dive 'version.divelog' (3)
Set the current dive site: 0
Set the current dive site: 0

File locations:
...

My best guess is that issue has something to do with:
qrc:/MapWidget.qml:24: Error: Cannot assign [undefined] to
QDeclarativeGeoMapType*

I not familiar enough with qml to go further than that at this point, sorry.

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

Re: Formatting Dive tags string

[Jérémie Guichard]

Hello Thiago,

In order to not mix the two topics in the same change, I decided to keep
the conversion to QString as it was in the original code, see:
https://github.com/Subsurface-divelog/subsurface/blob/12dc1889c704c6af9125d3ef3f0d2a1c1fe603f7/desktop-widgets/tab-widgets/maintab.cpp#L574
https://github.com/Subsurface-divelog/subsurface/blob/12dc1889c704c6af9125d3ef3f0d2a1c1fe603f7/desktop-widgets/tab-widgets/maintab.cpp#L1529
https://github.com/Subsurface-divelog/subsurface/blob/12dc1889c704c6af9125d3ef3f0d2a1c1fe603f7/qt-models/divetripmodel.cpp#L430
I can now prepare a follow up change that would deal with the issue you
have raised, the advantage is that now it must be fixed in a single place :)

Thanks for the feedback,

Jeremie

2018-04-05 5:27 GMT+02:00 Thiago Macieira :

> On Wednesday, 4 April 2018 02:55:22 PDT Berthold Stoeger wrote:
> >   char *s = taglist_get_tagstring(...);
> >   QString tags(s);
> >   free(s);
>
> One minor note: this decodes the string as UTF-8. If your string is Latin1
> or
> plain US-ASCII, you should use QString::fromLatin1 or QLatin1String (same
> thing in this context).
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Formatting Dive tags string

[Jérémie Guichard]

Here is the pull request :)
https://github.com/Subsurface-divelog/subsurface/pull/1187

2018-04-04 14:35 GMT+02:00 Lubomir I. Ivanov <neolit...@gmail.com>:

> On 4 April 2018 at 14:27, Lubomir I. Ivanov <neolit...@gmail.com> wrote:
> > On 4 April 2018 at 12:36, Jérémie Guichard <djebr...@gmail.com> wrote:
> >> Hello everybody,
> >>
> >> While reviewing this change adding display for Tags in dive list view
> >> (https://github.com/Subsurface-divelog/subsurface/pull/1184), Lubomir
> and
> >> Dirk raised a concern regarding tag text that can exceed inputted buffer
> >> size. Issue comes from implementation/signature of taglist_get_tagstring
> >> function
> >> https://github.com/Subsurface-divelog/subsurface/blob/
> master/core/dive.c#L3023
> >> Certainly no current user has been using enough tags to actually
> encounter
> >> problems with this but who knows...
> >>
> >> Staring from their input and doing some code digging, here is a short
> >> overview of my findings and proposals.
> >>
> >> taglist_get_tagstring function currently prints as many full tags as
> could
> >> be fitted in the inputted buffer and returns the length of the printed
> >> string. This approach raise several issues when it comes to long tag
> lists:
> >>  a) It is not possible to know from the returned information if all tags
> >> were actually printed.
> >>  b) When a user would (in the UI) add a long tag list, the full tag
> list is
> >> (at first) indeed saved. Then, only text returned by
> taglist_get_tagstring
> >> gets displayed. This causes later edits of the tags to delete tags that
> were
> >> not displayed, not good...
> >>  c) Looking at DiveObjectHelper class the function is used with 256
> buffer
> >> size so issue would become more visible if DiveObjectHelper::tags was
> >> actually used. It seems this method is not used yet (neither in Desktop
> nor
> >> in Mobile app) but I may be wrong, please point me to its usage if you
> know
> >> one...
> >>
> >> Lubomir mentioned he could look into this 'issue' but did not have much
> free
> >> time, since I do have some on my side I can look into this change. I do
> >> prefer to consult the community before doing it though. Here are the
> >> different solutions that came to my mind:
> >>
> >>  1) Add a output parameter to last printed struct tag_entry* in the
> list to
> >> the current taglist_get_tagstring allowing callers to iterate when
> needed
> >> (not my favorite)
> >>  2) It seems strange for a UI specific function to be part of dive.h/.c
> I
> >> would rather move this functionality to 'Qt level' say in qthelper.h/.c
> (or
> >> other better location if one of you have a better proposal) and
> implement it
> >> using QStrings (avoiding the pre-allocated buffer issue). This is
> already
> >> what is done for get_gas_string for example. It is my preferred proposal
> >> since all usage I could find of taglist_get_tagstring are in Qt code and
> >> this function is purely UI related code...
> >>
> >> I do have other topics to discuss with you guys but I'll send separate
> >> emails not to mix things up.
> >>
> >
> > the function is kind of part of the C backend and we probably should
> > write it in C.
> > posted some comments in the issue thread at github about `
> > taglist_get_tagstring` as i saw this ML thread just now.
> >
>
> copy paste from here:
> https://github.com/Subsurface-divelog/subsurface/pull/1184#
> issuecomment-378566518
>
> the approach for taglist_get_tagstring() would be:
>
> - make taglist_get_tagstring() accept a single argument (only the
> list, without buffer ptr and size)
> - go through the tags and calculate required size to malloc() (also
> consider ', ')
> - malloc() a char * buffer once
> - go through the tags again and copy the tags over the buffer while adding
> ', '
> - make taglist_get_tagstring() return NULL / buffer instead of int.
> - use this buffer to create QString by the callers of
> taglist_get_tagstring() and free this buffer too:
>
> (as Berthold already pointed out)
>
> char *str_list = taglist_get_tagstring(some_tag_list);
> QSting ret(str_list);
> free(str_list);
> return ret;
>
> lubomir
> --
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Formatting Dive tags string

[Jérémie Guichard]

Hello everybody,

While reviewing this change adding display for Tags in dive list view (
https://github.com/Subsurface-divelog/subsurface/pull/1184), Lubomir and
Dirk raised a concern regarding tag text that can exceed inputted buffer
size. Issue comes from implementation/signature of taglist_get_tagstring
function
https://github.com/Subsurface-divelog/subsurface/blob/master/core/dive.c#L3023
Certainly no current user has been using enough tags to actually encounter
problems with this but who knows...

Staring from their input and doing some code digging, here is a short
overview of my findings and proposals.

taglist_get_tagstring function currently prints as many full tags as could
be fitted in the inputted buffer and returns the length of the printed
string. This approach raise several issues when it comes to long tag lists:
 a) It is not possible to know from the returned information if all tags
were actually printed.
 b) When a user would (in the UI) add a long tag list, the full tag list is
(at first) indeed saved. Then, only text returned by taglist_get_tagstring gets
displayed. This causes later edits of the tags to delete tags that were not
displayed, not good...
 c) Looking at DiveObjectHelper class the function is used with 256 buffer
size so issue would become more visible if DiveObjectHelper::tags was
actually used. It seems this method is not used yet (neither in Desktop nor
in Mobile app) but I may be wrong, please point me to its usage if you know
one...

Lubomir mentioned he could look into this 'issue' but did not have much
free time, since I do have some on my side I can look into this change. I
do prefer to consult the community before doing it though. Here are the
different solutions that came to my mind:

 1) Add a output parameter to last printed struct tag_entry* in the list to
the current taglist_get_tagstring allowing callers to iterate when needed
(not my favorite)
 2) It seems strange for a UI specific function to be part of dive.h/.c I
would rather move this functionality to 'Qt level' say in qthelper.h/.c (or
other better location if one of you have a better proposal) and implement
it using QStrings (avoiding the pre-allocated buffer issue). This is
already what is done for get_gas_string for example. It is my preferred
proposal since all usage I could find of taglist_get_tagstring are in Qt
code and this function is purely UI related code...

I do have other topics to discuss with you guys but I'll send separate
emails not to mix things up.

Cheers,

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

Re: error when saving information on the cloud

[Jérémie Guichard]

Hey Davide,

Could you run subsurface from command line with logging command line
options and send us what you get there?

If on windows:
subsurface.exe --win32console -v -v

Otherwise:
subsurface -v -v

Thanks,

Jeremie

2017-03-24 19:42 GMT+07:00 Davide DB :
> Hi guys,
>
> Could you help me with this? Same error here. I have the latest Subsurface 
> 4.6.3
>
> I followed instructions on the user manula but I found some discrepancies:
>
> I successfully created a cloud account receiving and saving the PIN.
> Then I tried to load the logbook on the clud but I got:
>
> Error connecting to subsurface cloud storage
> Unabe to open git repository
> 'https://cloud.subsurface-divelog.org//git/ [email address]'
>
> Going on the preference tab, the box marked "Cloud storage default
> file" is disabled.
> Once I restart Subsurface it's enabled.
> I marked that checkbox and now Subsurface is stuck without logbook
> because has not been created.
>
>
> PS
> I'm behind a proxy server but network connection is ok because I
> correctly see maps on the Globe
>
>
> Davide
>
>
>
>
> On 10 January 2017 at 21:11, Simon  wrote:
>> Hi
>>
>> I am using the 4.5.6 version of subsurface.
>>
>> Regards,
>>
>> Le mardi 10 janvier 2017 15:06:46 UTC-5, Miika Turkia a écrit :
>>>
>>> What version of Subsurface you are using? We are just about to release a
>>> new version that IIRC fixes similar sounding issue. You could test this out
>>> with following beta version:
>>>
>>> https://subsurface-divelog.org/downloads/subsurface-4.6-Beta-2.exe
>>>
>>> On Tuesday, January 10, 2017 at 10:01:25 PM UTC+2, Simon wrote:

 Hi everyone

 I am new to subsurface and already got some issue to put the information
 in the cloud to be able to access it on my phone... I am currently using
 windows 10, 64 bit and I do not have any dive computer yet so I enter the
 information manually. I already sync some dives to the cloud and then to my
 phone and everything worked well. Although I now receive a message saying:

 Error connecting to subsurface cloud storage
 Unabe to open git repository 'https://cloud.subsurface-divelog.org//git/
 [email address]'

 The address is good as well as the password in the preferences seems good
 (I validated via the web interface). Is there any preferences that I might
 have changed without noticing? Thanks for your help in the matter.

 Regards

 Simon




>> --
>> You received this message because you are subscribed to the Google Groups
>> "Subsurface Divelog" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to subsurface-divelog+unsubscr...@googlegroups.com.
>> To post to this group, send email to subsurface-dive...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/subsurface-divelog/502f7718-59f6-467d-b46a-e662407a785e%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Davide
> https://vimeo.com/bocio/videos
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Automatic tests - a few general questions

[Jérémie Guichard]

Hey Stefan,

The rules you mentioned do add tests, but not as part of the build itself,
there is a different target called "check" that can be used to run the
tests. Up to recently, some tests were failing under windows, this is why
the mxe build script did no enable them. Tests are now passing; I though
about enabling them together with enabling mxe build and tests in CI.
Unfortunately I was quite busy the last weeks and did not have much time to
make progress in this area... (Or to answer your questions, sorry for the
late reply)

Cheers,

Jeremie

2017-03-17 1:36 GMT+07:00 Stefan Fuchs :

> Hi Dirk,
> Am 16.03.2017 um 18:55 schrieb Dirk Hohndel:
>
>
> On Mar 16, 2017, at 10:25 AM, Stefan Fuchs  wrote:
>
> Hi All,
>
> currently I try to learn how the automatic tests work :-)
> I think I almost understood what I have to do to add automatic tests for
> the minimum gas calculation but I first have a few general questions:
>
> - In linux build building the tests is ON by default, in mxe build it is
> OFF. Could we switch this ON there by default as well?
>
>
> This is simply a CMake variable - so your build script can pass in ON or
> OFF as you want.
>
> Yes, this is what the mxe-based-build.sh is doing. But it is hard coded to
> OFF inside the script. I was wondering if we can (should?) change this to
> ON to be in line with the default for the linux build which is ON.
> https://github.com/Subsurface-divelog/subsurface/blob/
> master/packaging/windows/mxe-based-build.sh#L299
>
> - My assumption is that if building tests is ON, the tests will be run as
> well during build. For linux this should work immediately. For mxe build I
> need wine to run the windows exe files. I installed wine and in fact I can
> now run the exe tests under linux. But I'm still not sure if they are
> automatically run during build (both linux and MXE). Where will the test
> results go? There is nothing in build.log or winbuild.log or stdout.
>
>
> Tests are NOT automatically run when doing a build - and I'd find this
> extremely annoying when I'm working on a feature, TBH.
>
> Yes, you're right. For me this would be even worse with my slow HW ;-(
> My misunderstanding comes from reading these lines:
> https://github.com/Subsurface-divelog/subsurface/blob/
> master/tests/CMakeLists.txt#L66
> I thought this is preparing to run the tests during build because it
> checks for wine? Or is this obsolete? Or am I simply not reading this
> correctly?
>
> 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
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Planner: ascent and descent rates should be rounded rather than truncated

[Jérémie Guichard]

Pull request ready :)
https://github.com/Subsurface-divelog/subsurface/pull/254


2017-03-14 2:00 GMT+07:00 Linus Torvalds <torva...@linux-foundation.org>:

> On Mon, Mar 13, 2017 at 11:29 AM, Jérémie Guichard <djebr...@gmail.com>
> wrote:
> >
> > Looking into that now. There is a bunch of new warnings adding the flag
> but
> > seems (at first look) to be managable.
>
> Yeah, I was afraid there would be some infrastructure stuff, but it
> all looks like our source.
>
> > Working on the patch right now...
>
> Thanks.
>
>   Linus
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Planner: ascent and descent rates should be rounded rather than truncated

[Jérémie Guichard]

Ho!
I didn't realized I used the -Wfloat-conversion on C code only and not C++
when I did my previous round of float/double to int patch!

Looking into that now. There is a bunch of new warnings adding the flag but
seems (at first look) to be managable.

Working on the patch right now...

2017-03-14 0:11 GMT+07:00 Dirk Hohndel :

> On Mon, Mar 13, 2017 at 09:07:31AM -0700, Linus Torvalds wrote:
> > On Mon, Mar 13, 2017 at 12:35 AM, Rick Walsh 
> wrote:
> > >
> > >  void PlannerSettingsWidget::setAscRate75(int rate)
> > >  {
> > > -   
> > > SettingsObjectWrapper::instance()->planner_settings->setAscrate75(rate
> * UNIT_FACTOR);
> > > +   
> > > SettingsObjectWrapper::instance()->planner_settings->setAscrate75(rate
> * UNIT_FACTOR + 0.5);
> > >  }
> >
> > These should all definitely use "lrint()" rather than " + 0.5"
> > together with the integer truncation.
>
> Agreed since UNIT_FACTOR is a floating point number.
>
> Can you send a patch / pull request that does that instead?
>
> Thanks
>
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android App

[Jérémie Guichard]

Made a fast walk through, did not find anything significant...

2017-03-12 14:19 GMT+07:00 Anton Lundin :

> On 11 March, 2017 - Dirk Hohndel wrote:
>
> > I would like to update the app. It would be nice if a few people could
> try the new Subsurface-mobile that's available in the beta test channel...
> Just as a check to make sure I didn't break anything obvious
> >
>
> LGTM
>
>
> //Anton
>
>
> --
> Anton Lundin+46702-161604
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
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 <d...@hohndel.org>:

> 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

Re: DM5 Data structure changes

[Jérémie Guichard]

Hello Max,

I guess the easiest would be to look at the dm4_dive and dm5_dive functions
in subsurface core/parse-xml.c file
https://github.com/Subsurface-divelog/subsurface/blob/master/core/parse-xml.c

Good reading,

Jeremie

2017-03-09 16:27 GMT+07:00 Max Lindqvist :

> Hi,
>
> I am working on a small program for analysing freedive data from Sunnto
> DM4.
>
> I’ve got some troubles understanding the SampleBlob and found this email
> from the link below.
>
> http://lists.subsurface-divelog.org/pipermail/subsurface/2014-November/
> 015798.html
>
> Could you give some advice on how I can convert bytes 4-7 to a depth in
> meters?
>
> Best regards,
>
> Max
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
___
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,

Thanks for the help on this topic!

I have now updated my pull request with the different proposed changes.
The first commit changes all rint to lrint. Based on Lubomir
recommendation, I went through the different places to check (and use)
lrintf where necessary. Doing so I found two places that looked strange to
me since (to my understanding) it was using rint on the result of an
integer division, this seemed curious! This is why I changed the code to
use double/float division. Please have a closer look there:

In dive.h the gas_mnd function:
rint(mbar_to_depth(maxambient, dive) / roundto) * roundto;

In parse-xml.c the divinglog_profile function:
rint(atoi(cns) / 10)

Second commit, fixes all warnings raised by "-Wfloat-conversion", I made
the change from round to lrint in uemis code too.

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?
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?
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?

With this change, TestParse will now pass on Windows too, we now only have
TestPreference failing! Getting there :)

Best regards,

Jérémie

2017-03-08 9:21 GMT+07:00 Jérémie Guichard <djebr...@gmail.com>:

> I'm looking into that right now :)
>
> 2017-03-08 7:18 GMT+07:00 Dirk Hohndel <d...@hohndel.org>:
>
>> On Tue, Mar 07, 2017 at 09:43:06AM -0800, Linus Torvalds wrote:
>> > On Tue, Mar 7, 2017 at 9:20 AM, Lubomir I. Ivanov <neolit...@gmail.com>
>> wrote:
>> > >
>> > > lrint() seems to build for me with mingw 4.9.2.
>> >
>> > .. in fact, I notice that we had a couple of places in the GPS
>> > coordinates code that already used 'lrint()', so it must work.
>> >
>> > The uemis code has a few places that use 'round()' instead of rint() -
>> > those should probably be converted to 'lrint()' as well.
>>
>> Would you be willing to run the script, make the other changes you
>> suggest, and send a patch / pull request?
>>
>> I'm really swamped this week.
>>
>> /D
>>
>
>
___
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]

I'm looking into that right now :)

2017-03-08 7:18 GMT+07:00 Dirk Hohndel :

> On Tue, Mar 07, 2017 at 09:43:06AM -0800, Linus Torvalds wrote:
> > On Tue, Mar 7, 2017 at 9:20 AM, Lubomir I. Ivanov 
> wrote:
> > >
> > > lrint() seems to build for me with mingw 4.9.2.
> >
> > .. in fact, I notice that we had a couple of places in the GPS
> > coordinates code that already used 'lrint()', so it must work.
> >
> > The uemis code has a few places that use 'round()' instead of rint() -
> > those should probably be converted to 'lrint()' as well.
>
> Would you be willing to run the script, make the other changes you
> suggest, and send a patch / pull request?
>
> I'm really swamped this week.
>
> /D
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Several float to int potential rounding errors/inconsistencies

[Jérémie Guichard]

Good morning/afternoon/evening all,

I've been lately trying to get subsurface tests to pass under windows. In
the current state, TestParse and TestPreferences are the two ones still
failing...

In short, the error raised by TestParse is caused by a rounding error when
converting dm4 sample depth from float meters to int millimeters. The
inconsistency was raised running the test on windows but same behavior can
be seen on linux for certain float values too. Have a look at the changes
in the pull request here for the details:
https://github.com/Subsurface-divelog/subsurface/pull/233

The fix in itself is easy, surround the booean_value * 1000 with a rint:
"rint(booean_value * 1000)" when it is assigned to the integer variable...

As I was commenting in the pull request, I have identified several other
potential similar rounding issues. The exact same one in dm5_dive code, in
maxdepth computation for both dm4_dive and dm5_dive and many other places
in parse-xml.c code and some as well (but in lesser amount) in other parts
of the code.

The one fixed here is the only one that was highlighted by a test failure
(when running TestParse on windows). How should we proceed forward?

   1. My original goal was more to get all tests passing under windows so
   it could get integrated in CI, TestPreference is still failing... So we
   could simply pull this change and get back to this issue later, focusing
   first on test execution for windows CI.
   2. Fix "blindly" all potential rounding errors, but I'm not really clear
   on what could be the side effect(s) of this.
   3. Spend time creating test cases that would highlight each rounding
   errors but the task is huge, not always straight forward (blob data), and
   current test philosophy seem to be closer to quick functional testing
   rather than deep regression testing.

What is your point of view here?


Best regards,


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

Re: Subsurface-Mobile download from dive computer

[Jérémie Guichard]

Hello guys,

I was lately thinking that being able to load dives from dive computer
directly to mobile app would be a great addition. I already use an OTG
cable to plug thumb or hard drives to my mobile when I want to back things
up without PC or fast internet connection. My guess is that it could be
feasible to use that connector to simply plug computer and mobile to each
other and get the recorded dives this way.

Seeing the title of your post, it seems this is what you are working on, am
I right?

If so, I would be more than willing to give a hand here :)

Cheers,

Jeremie

2017-03-03 2:31 GMT+07:00 Dirk Hohndel :

>
> > On Mar 2, 2017, at 10:48 AM, Willem Ferguson <
> willemfergu...@zoology.up.ac.za> wrote:
> >
> > Hallo Dirk,
> >
> > I am in a position now to try some more towards achieving FTDI downloads.
> >
> > Between April 2016 and now one hell of a lot has changed on the QML
> side. Most importantly, Kirigami (largely?) replaced mobilecomponents. The
> folder mobile-widgets replaced the previous qt-mobile.
> >
> > 1) What of the archived mobilecomponents code for
> downloadFromDiveComputer from 2016 is still usable? Would it be better to
> start from scratch?
>
> It should still mostly work. I haven't played with it in a while, but I
> don't think the changes required should be too hard.
>
> > 2) Do you have any useful reference material about Kirigami?
>
> We are still using Kirigami 1, so that would be http://notmart.org/misc/
> kirigami1-docs/html/
>
> > 3) Any suggestions would be appreciated.
>
> I'd start with that see where you get stuck. Marco ist still on the
> mailing list and usually extremely helpful when you have specific questions.
>
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Open / Save to cloud on Windows 10

[Jérémie Guichard]

Hi guys,

Pull request sent (https://github.com/Subsurface-divelog/subsurface/pull/222
)
Sorry for the late reply, these days were quite busy with a bit of coding
but mainly with my Instructor Training Course :)

Based on your recommendations I've added a subsurface_stat portability
function. There I used the corresponding widechar implementation wstat()
for windows (after utf8 to utf16 conversion) and simply called the normal
stat() otherwise. It seems to work nicely.

>From what I understand when reading msdn, stat() is actually expecting a
path encoded with the codepoint that is defined in system settings so it
can be many things but rarely utf8... Win32 only apps do not face issues
since they would read this from user input or other win32 api that are
already returning paths/stings encoded with that codepoint. In our case
everything is converted to utf8 before being returned to the app level. At
least this is my current understanding of the issue we faced.

Since I like to work with tests, I made some little changes to the testing
code in order to be able to run cross compiled tests under windows too. And
added a case that test specificaly our issue.
The changes I've made there are not yet providing a fully flavored solution
(but it is a step forward, that allowed me to test without too much
troubles).

What could come next (but I prefer to do this in a separate change) would
be:
- Packaging of the tests together with dependencies and test data for
windows run
 (currently I went the hard way of manually copying what I needed)
- Making test execution not depending on user name. (All cloud part of
TestGitStorage implementation uses default path based on user dir to
execute tests.)
- Make test data user independent. (When I run the tests I get many:
"didn't find picture entry for
/home/hohndel/subsurface/dives/images/PA102039.jpg"
caused by hard coded path in the test cases)
- I still could not run TestPreferences.exe I get a strange missing
dependency message (certainly explained by my manual copy of the
dependencies ;))
- Some issue with recently added TestMerge and TestParse caused by a
trailing \r in the value from written file
   Actual   (readin.takeFirst()) : ""
   Expected (written.takeFirst()): "\r"

For now I got TestGitStorage to:
1. Reproduce the issue when the fix was not there. see log below, I cut off
the missing image messages
2. Pass once the fix is included. see log below too

Have a look at the pull request, I will be happy to make any improvements
or fixes to the change. (I will not be unhappy if you pull it in as is)

Cheers,

Jeremie

Before:
* Start testing of TestGitStorage *
Config: Using QtTest library 5.7.0, Qt 5.7.0 (i386-little_endian-ilp32
shared (dynamic) release build; by GCC 4.9.4)
PASS   : TestGitStorage::initTestCase()
PASS   : TestGitStorage::testSetup()
PASS   : TestGitStorage::testGitStorageLocal(ASCII path)
FAIL!  : TestGitStorage::testGitStorageLocal(Non ASCII path) Compared
values are not the same
   Actual   (save_dives(qUtf8Printable(testDirName + "[test]"))): -1
   Expected (0) : 0
/home/jeremie/dev/subsurface-win/subsurface/tests/testgitstorage.cpp(81) :
failure location
FAIL!  : TestGitStorage::testGitStorageCloud() Compared values are not the
same
   Actual   (parse_file(qUtf8Printable(cloudTestRepo))): -1
   Expected (0): 0
/home/jeremie/dev/subsurface-win/subsurface/tests/testgitstorage.cpp(107) :
failure location
FAIL!  : TestGitStorage::testGitStorageCloudOfflineSync() Compared values
are not the same
   Actual   (parse_file(qUtf8Printable(localCacheRepo))): -1
   Expected (0) : 0
/home/jeremie/dev/subsurface-win/subsurface/tests/testgitstorage.cpp(129) :
failure location
FAIL!  : TestGitStorage::testGitStorageCloudMerge() Compared values are not
the same
   Actual   (parse_file(qUtf8Printable(localCacheRepoSave))): -1
   Expected (0) : 0
/home/jeremie/dev/subsurface-win/subsurface/tests/testgitstorage.cpp(179) :
failure location
FAIL!  : TestGitStorage::testGitStorageCloudMerge2() Compared values are
not the same
   Actual   (parse_file(qUtf8Printable(localCacheRepo))): -1
   Expected (0) : 0
/home/jeremie/dev/subsurface-win/subsurface/tests/testgitstorage.cpp(227) :
failure location
FAIL!  : TestGitStorage::testGitStorageCloudMerge3() Compared values are
not the same
   Actual   (parse_file(qUtf8Printable(cloudTestRepo))): -1
   Expected (0): 0
/home/jeremie/dev/subsurface-win/subsurface/tests/testgitstorage.cpp(284) :
failure location
PASS   : TestGitStorage::cleanupTestCase()
Totals: 4 passed, 6 failed, 0 skipped, 0 blacklisted, 20258ms
* Finished testing of TestGitStorage *

After:
* Start testing of TestGitStorage *
Config: Using QtTest library 5.7.0, Qt 

Re: Open / Save to cloud on Windows 10

[Jérémie Guichard]

Hey guys,

I narrowed it!

It took me a little while to get the windows dev env in place, but
instructions in packaging/windows/mxe-based-build.sh were very helpful.
Only one little call to curl's buildconf script is missing in
mxe-based-build.sh but once done manually the rest went smoothly. I may fix
this in a separate commit, maybe together with automatically cloning
dependencies from github...
It "only" took 8h to build mxe inside the vm, thanks to the warning in the
comments and from Dirk's last message, I started the build before going to
bed :)

Back to the non-ASCII user name/path for local checkout of the repository,
the issue is caused by the call to stat(sys/stat.h) that do not support
non-ASCII paths. I could not find a place that was stating it explicitly
but seems reasonable explanation. Since the cloning and checkout itself
works in libgit2 I made some digging in that code and there a set of
portability functions are used (p_stat) with simple mapping to system's
stat() for posix systems and specific implementations using win32 APIs for
win case.

As a proof of concept I added an ugly: "extern int p_stat(const char* path,
struct stat* buf);" on top of git-access.c and used it in get_remote_repo
and is_git_repository (these are the 2 only places stat function is used in
the whole project). It fixed my issue (I could Open and Save could
storage)...

Now what should we take as a fix:
1. The ugly extern
Cons
I call it ugly since (in libgit2) that function is not actually exposed in
the headers, not sure how Android and iOS apps are built (actually
linked...) so it could caused some issues there.
I have to mention the "bad design" / hidden dependency to libgit2 internals
argument too.

Pros
On the other hand it is quite an easy fix for the time we do not encounter
other compatibility issues in other places of the soft.
It is (currently) limited to *git*-access.c so (if it does not raise issues
on other platforms/targets) having a tight coupling to libgit2 internals
could be acceptable.

2. Implement our own portable is_dir
In all the places stat function is used, it is to check if the path is a
directory (and exists). Going through a portable stat is a bit "overkill"
(processing to provide all the elements that output "struct stat" needs)
when we only need to know if we have a directory. Not that this part of the
code is actually perf critical, it is always good to ask ourselves the
question.
Plus it makes the code a bit more readable. I think this option is my
favorite and would avoid issues in other platforms (if they exist at all).

3. Implement our own portable stat
The choice between this option and the previous is_dir proposal is always
hard when it comes to portability (specifically with windows).
Should you port system calls or should you write client code using higher
level abstractions is always a big debate.
Furthermore, in bigger projects that use multiple 3rd party libs the
portage is often already done in several of the included libs, so writing
yet another port results in adding code that typically already exists
multiple times in your final binary...
I'm more often working with C++ so I tend to love abstractions, when it
comes to C the choice is a bit harder.
Subsurface core is, from my point of view, higher level code so I would go
for abstraction, but I'm curious to hear about other point of views.

3. Other proposal?
There could be other solutions I have overseen, do you guys think about
something else?


I'm still a bit fresh with this project and do not have yet an overview of
all use cases, platforms and targets that are involved, this is why I
preferred to ask before proposing a pull request with changes that could
have side effects...
On a related point, I have not looked yet on how testing is done, (and how
far it goes) I would be more than happy to extend the test with this use
case, I'd only need a bit of guidance.

While we are talking about porting, is there a thread I could look into to
understand the choice that was made to go for cross compilation rather than
building on target? cmake is quite helpful in that regard. Maybe the main
reason is that most developer do not want to install a win VM to check
their code do build there :)

Cheers,

Jeremie



2017-02-19 23:24 GMT+07:00 Dirk Hohndel <d...@hohndel.org>:

> On Sun, Feb 19, 2017 at 05:32:15PM +0700, Jérémie Guichard wrote:
> >
> > Computer is Suunto Zoop. With Suunto DM5 I have to sync multiple times
> > before all logs are synced...
>
> Yeah, DM5 is a very special piece of s... err... software.
>
> > I'll take a look into translations, I normally use English interfaces,
> just
> > switched to french to see the status, seems pretty complete though some
> > translations could be improved. I guess I'm a bit late for the 4.6.2...
> > Website seems to be a bit more behind...
>
> Yes, 4.6.2 will h

Open / Save to cloud on Windows 10

[Jérémie Guichard]

Hey Dirk,

Thanks for the fast reply!

Computer is Suunto Zoop. With Suunto DM5 I have to sync multiple times
before all logs are synced...

I'll take a look into translations, I normally use English interfaces, just
switched to french to see the status, seems pretty complete though some
translations could be improved. I guess I'm a bit late for the 4.6.2...
Website seems to be a bit more behind...

Indeed I used official 4.6.1 installer.

No specific ACLs on the directory. But my user name do contains the french
"é". So I created a new user with only ASCII chars, cloud storage features
Open/Save are working fine. You have found the issue, yepee!!!

How should I proceed? ticket, fix, etc. I must admit I'm not there yet with
setting up dev env, I only got to build from source yesterday in the ubuntu
virtual machine... (btw I had a short attempt to do so using linux
subsystem for windows but did not succeed...)

Cheers,

Jeremie


2017-02-19 14:41 GMT+07:00 Dirk Hohndel <d...@hohndel.org>:

> On Sun, Feb 19, 2017 at 02:05:18PM +0700, Jérémie Guichard wrote:
> > Hi guys,
> >
> > First of all, I'd like to thank you all for the job well done, though
> many
> > improvements and features are to come, subsurface is quite complete and
> > useful. I could add that in my case importing logs from dive computer
> > actually works better than computer's proprietary software! (There I have
> > to sync multiple times before all my logs actually get imported while
> with
> > subsurface it works in one shot and "out of the box"...)
>
> Cool. Which dive computer is that?
>
> > I have several ideas for features and improvements (that I could help
> > coding) and am more willing to participate with translation effort, (my
> > mother tongue is French).
>
> Awesome. There are two different angles to translations: the application
> itself (I think the French translation is fairly complete) which is done
> through Transifex, and our website, where we have a slighly odd setup to
> translate things through a github repository and pull request for that
> (https://github.com/Subsurface-divelog/subsurface-website)
>
> > I'd like to deal with one issue that is pretty
> > important for me since I want to use the mobile app too, the "cloud
> > storage".
> >
> > In the current state, on my Windows 10 machine, whenever I try to: "Open
> > cloud storage" in end up with a "Error connecting to Subsurface cloud
> > storage". Same thing if I log some dives and try to "Save to cloud
> > storage". Using an Ubuntu virtual machine, the same operations succeeds.
> > (So no issue with credentials or unregistered account)
>
> I assume this is with our official 4.6.1 installer, downloaded from our
> website?
>
> > Starting the app with logging options (--win32console --verbose -v -v), I
> > get such messages (for the "Open Cloud Storage")
> >
> > git_remote_repo: accessing
> > https://cloud.subsurface-divelog.org//git/xx...@xxx.xxx
> > git storage: 0 % ( start git interaction )
> > git storage: create_local_repo
> > Cloud storage: checking connection to cloud server
> > Checking cloud connection...
> > git storage: 0 % ( waited 1 sec for cloud connetion )
> > Cloud storage: successfully checked connection to cloud server
> > git storage: 0 % ( successfully checked cloud connection )
> > git storage: calling git_clone()
> > *git storage: returned from git_clone() with error -4*
> >
> > According to libgit2 git2/errors.h this is
> >  GIT_EEXISTS = -4, /**< Object exists preventing operation */
> >
> > This lead me to navigate
> > to  C:\Users\\AppData\Roaming\Subsurface\cloudstorage and delete the
> > contained git repo.
> > At that point I can actually get my cloud stored dives locally. If I try
> > the "Open cloud storage" again the original error comes again unless I
> > delete the git repo again.
> >
> > Now if I edit or add a dive, and "Save to cloud storage", same error.
> > I delete the git repo, then "Save to cloud storage"
>
> Yikes. That's weird.
>
> > git_remote_repo: accessing
> > https://cloud.subsurface-divelog.org//git/xx...@xxx.xxx
> > git storage: 0 % ( start git interaction )
> > git storage: create_local_repo
> > Cloud storage: checking connection to cloud server
> > Checking cloud connection...
> > git storage: 0 % ( waited 1 sec for cloud connetion )
> > Cloud storage: successfully checked connection to cloud server
> > git storage: 0 % ( successfully checked cloud connection )
> > git storage: calling git_clone()
> > de