Re: Problems building Subsurface for Android

[Joakim Bygdell]

On 3 February 2017 at 07:59, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> On 03/02/2017 08:25, Joakim Bygdell wrote:
>
> Wilhelm,
>
> You can create a workaround for that error if you edit this file:
> Qt/5.7/android_armv7/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake
>
> Comment out line 101
> set_property(TARGET Qt5::Core PROPERTY INTERFACE_COMPILE_FEATURES
> cxx_decltype)
>
> --
> Jocke
>
> Thanks very much, Jocke. After doing the above, I get:
>
> -- system name Android
> -- Found Qt for Android: /home/willem/src/Qt/5.7/android_armv7
> -- Found Android SDK: /home/willem/src/subsurface/../android-sdk-linux
> -- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
> -- Found ANT: /usr/bin/ant
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/willem/src/subsurface-build-arm
> Scanning dependencies of target version
> Built target version
> cp: missing destination file operand after 
> '/home/willem/src/subsurface/android
> android-mobile'
>

Looks like it is line 382.

>
> I tried finding the offending cp in build.sh but I was not successful
> because there are no markers in the above log that I can use to locate the
> cp. E.g. there is no string "Scanning for dependencies" in the shell
> script, probably generated by cmake. Any ideas?
> Kind regards,
> willem
>
> Remove the quotations on line 383 and try again, that fixed it for me.


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

Fwd: Re: Problems building Subsurface for Android

[Willem Ferguson]

 Forwarded Message 
From:   25 2017 <>
X-Account-Key:  account2
X-UIDL: 0001b5f34f262ed4
X-Mozilla-Status:   0013
X-Mozilla-Status2:  
X-Mozilla-Keys: 
Return-path: 


Envelope-to:willemfergu...@zoology.up.ac.za
Delivery-date:  Fri, 03 Feb 2017 08:26:12 +0200
Received: 	from [137.215.6.44] (helo=mail.up.ac.za) by zoology.up.ac.za 
with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.77) (envelope-from 
) id 
1cZXK0-We-2U for willemfergu...@zoology.up.ac.za; Fri, 03 Feb 2017 
08:26:12 +0200
Received: 	from mail.up.ac.za ([127.0.0.1]) by mail.up.ac.za with esmtp 
(Exim 4.84_2) (envelope-from 
) id 
1cZXJw-00075b-Ke for willemfergu...@zoology.up.ac.za; Fri, 03 Feb 2017 
08:26:11 +0200
Received: 	from mail-lf0-f42.google.com ([209.85.215.42] 
helo=mail-lf0-f42.google.com) by spamcontrol.up.ac.za with ESMTP 
(2.0.2); 3 Feb 2017 08:26:07 +0200
Received: 	by mail-lf0-f42.google.com with SMTP id z134so4931175lff.3 
for ; Thu, 02 Feb 2017 22:26:08 -0800 
(PST)
X-Google-DKIM-Signature: 	v=1; a=rsa-sha256; c=relaxed/relaxed; 
d=1e100.net; s=20161025; 
h=x-gm-message-state:delivered-to:delivered-to:dkim-signature 
:mime-version:in-reply-to:references:from:date:message-id:subject:to 
:precedence:list-id:list-unsubscribe:list-archive:list-post 
:list-help:list-subscribe:cc:errors-to:sender; 
bh=xGhr855RjADh+l9qjoBMjiR5zcICiWy9Tc1R/0Pzk14=; 
b=TW7pKHHAV7pBxDpveVHykTB4cYhgj3PeAq2u/blBjSzFYad8xp+SupKBoCeZPcay4k 
OjqDS7+cOsbfRtV/aCK6cLHu3x3sTzG/tdqLX6vyhWLPy6WhKTo/TEjdx7NxwjfZ5hQ1 
WPCoz1CFUXFsft/zi8QI+E3m/54AEzwAnm+zGlLIsZY63kbFn3twqozVGWuMZCmgSglg 
0Azqb/HOa9i58MIWv0IjvJWUvKlqbtWwCo8JJ9rHEka3i4++jUGF36RCsrcAle6qe7Vy 
QA5IaevySQKkqmxFsYuwvDkjeqKkUOhKG2D/lz4668FSUpZ5cjaqJAypecRsUFr1jlcx qzjg==
X-Gm-Message-State: 
AIkVDXI9PYRSd7U6D4eLhrs6vWVHUtbo+EdCDbNGcYtPWz4FkWpgS4xo+RWu1N4/RubCqG71OIFp7XuZ9QCPgaFdoaENPcA= 

X-Received: 	by 10.25.20.84 with SMTP id 
k81mr4451563lfi.172.1486103165346; Thu, 02 Feb 2017 22:26:05 -0800 (PST)

X-Forwarded-To: willemfergu...@zoology.up.ac.za
X-Forwarded-For:fergusonwil...@gmail.com willemfergu...@zoology.up.ac.za
Delivered-To:   fergusonwil...@gmail.com
Received: 	by 10.25.163.135 with SMTP id m129csp464875lfe; Thu, 2 Feb 
2017 22:26:04 -0800 (PST)
X-Received: 	by 10.84.151.69 with SMTP id 
i63mr18634609pli.122.1486103163901; Thu, 02 Feb 2017 22:26:03 -0800 (PST)
Received: 	from mail.subsurface-divelog.org (mailhost.gr8dns.org. 
[198.145.64.141]) by mx.google.com with ESMTP id 
x15si19791301pgo.355.2017.02.02.22.26.03; Thu, 02 Feb 2017 22:26:03 
-0800 (PST)
Received-SPF: 	neutral (google.com: 198.145.64.141 is neither permitted 
nor denied by best guess record for domain of 
subsurface-boun...@subsurface-divelog.org) client-ip=198.145.64.141;
Authentication-Results: 	mx.google.com; dkim=neutral (body hash did not 
verify) header.i=@gmail.com; spf=neutral (google.com: 198.145.64.141 is 
neither permitted nor denied by best guess record for domain of 
subsurface-boun...@subsurface-divelog.org) 
smtp.mailfrom=subsurface-boun...@subsurface-divelog.org; dmarc=fail 
(p=NONE sp=NONE dis=NONE) header.from=gmail.com
Received: 	by mail.subsurface-divelog.org (Postfix, from userid 112) id 
AAED02956E; Thu, 2 Feb 2017 22:26:02 -0800 (PST)
Received: 	from mhs.subsurface-divelog.org (localhost [IPv6:::1]) by 
mail.subsurface-divelog.org (Postfix) with ESMTP id 27B7829523; Thu, 2 
Feb 2017 22:26:00 -0800 (PST)

X-Original-To:  subsurface@subsurface-divelog.org
Delivered-To:   subsurface@subsurface-divelog.org
Received: 	by mail.subsurface-divelog.org (Postfix, from userid 112) id 
ACE5C29520; Thu, 2 Feb 2017 22:25:58 -0800 (PST)
Received: 	from mailhost.gr8dns.org (mhg.gr8dns.org [192.168.1.5]) by 
mail.subsurface-divelog.org (Postfix) with ESMTP id A633729518 for 
; Thu, 2 Feb 2017 22:25:56 -0800 (PST)
Received: 	by mailhost.gr8dns.org (Postfix, from userid 112) id 
9ABD0288DA; Thu, 2 Feb 2017 22:25:56 -0800 (PST)

X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on 
mhg.gr8dns.org
X-Spam-Level:   
X-Spam-Status: 	No, score=-2.8 required=5.0 
tests=BAYES_00,FREEMAIL_FROM, 
HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID 
autolearn=ham autolearn_force=no version=3.4.1
Received: 	from mail-io0-f174.google.com (mail-io0-f174.google.com 
[209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 
(128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet 
Authority G2" (not verified)) by mailhost.gr8dns.org (Postfix) with 
ESMTPS id 791D6200F9 for ; Thu, 2 Feb 
2017 22:25:54 -0800 (PST)
Received: 	by mail-io0-f174.google.com with SMTP id j18so10933445ioe.2 
for 

Re: Problems building Subsurface for Android

[Joakim Bygdell]

Wilhelm,

On 3 February 2017 at 06:20, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> On 03/01/2017 09:17, Joakim Bygdell wrote:
>
> On 3 January 2017 at 06:35, Willem Ferguson  za> wrote:
>
> CMake Error in CMakeLists.txt:
>>   No known features for CXX compiler
>>
>>   "GNU"
>>
>>   version 4.9.
>>
> I have seen that as well on my old mac.
> If I remember correctly it seemed to be an issue between an older version
> of GCC and the cmake flags.
>
> If you go into the build directory and run the ccmake command you should
> get a better error output.
>
> --
> Jocke
>
> Which directory do you refer to as  the build directory? ~/src?
>
> On my machine there is currently no build directory in
> src/subsurface/packaging/android.
>
> Clearly, src/subsurface/build is inappropriate.
>
> I am trying to get a better diagnostic than the above one.
>
> Kind regards,
>
> willem
>
>
> You can create a workaround for that error if you edit this file:
Qt/5.7/android_armv7/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake

Comment out line 101
set_property(TARGET Qt5::Core PROPERTY INTERFACE_COMPILE_FEATURES
cxx_decltype)

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

Re: Problems building Subsurface for Android

[Rick Walsh]

On 3 February 2017 at 16:20, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> On 03/01/2017 09:17, Joakim Bygdell wrote:
>
> On 3 January 2017 at 06:35, Willem Ferguson  za> wrote:
>
> CMake Error in CMakeLists.txt:
>>   No known features for CXX compiler
>>
>>   "GNU"
>>
>>   version 4.9.
>>
> I have seen that as well on my old mac.
> If I remember correctly it seemed to be an issue between an older version
> of GCC and the cmake flags.
>
> If you go into the build directory and run the ccmake command you should
> get a better error output.
>
> --
> Jocke
>
> Which directory do you refer to as  the build directory? ~/src?
>
> On my machine there is currently no build directory in
> src/subsurface/packaging/android.
>
It should be src/subsurface-mobile-build-$ARCH

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

Re: Problems building Subsurface for Android

[Willem Ferguson]

On 03/01/2017 09:17, Joakim Bygdell wrote:
On 3 January 2017 at 06:35, Willem Ferguson 
> wrote:


CMake Error in CMakeLists.txt:
  No known features for CXX compiler

  "GNU"

  version 4.9.

I have seen that as well on my old mac.
If I remember correctly it seemed to be an issue between an older 
version of GCC and the cmake flags.


If you go into the build directory and run the ccmake command you 
should get a better error output.


--
Jocke


Which directory do you refer to as  the build directory? ~/src?

On my machine there is currently no build directory in 
src/subsurface/packaging/android.


Clearly, src/subsurface/build is inappropriate.

I am trying to get a better diagnostic than the above one.

Kind regards,

willem


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

Re: Fwd: importing smarttrak slg logs

[Salvador Cuñat]

Sorry Alessandro, didn't see this post and answered yours and Willem
previous one.

2017-02-02 22:33 GMT+01:00 Alessandro Volpi :

> Dear Willem and Salvador,
>
> I have decided to restart from scratch, in order to get a working
> smtk2ssrf.
>
> My present subsurface installation from the Fedora 24 repo is working and,
> since the application was installed, the shared object
> libssrfmarblewidget.so is now present on my system.
>
> I have found that a package named glib2-2.48.2-1.fc24.x86_64 is already
> installed in my system, as required for building smtk2ssrf.
>
> I also installed package mdbtools with its dependencies. Therefore modules
> glib2 and libmdb are now in my system, as shown in the attached file
> locate_required_modules_output.txt .
>
> I have then created my src folder in /opt/src . The subsurface build
> package was downloaded in /opt/src/subsurface .
>
> I have edited file CMakeLists.txt setting the option SMARTTRAK_IMPORT to
> ON.
>
> A new build procedure was then started issuing the command  :
> ./subsurface/scripts/build.sh | tee subsurface_build_log.txt . The
> resulting log file is attached
> File /opt/src/subsurface/build/CMakeFiles/CMakeOutput.log is also
> attached.
>
> Surprisingly the build failed, since the libmdb module could not be found
> : "Checking for module 'libmdb' --   No package 'libmdb' found"
>
>
This is what my libraries look like; standard configuration without manual
links and it's correctly detected by cmake.

$ ldconfig -p |grep libmdb
libmdbsql.so.2 (libc6,x86-64) =>
/usr/lib/x86_64-linux-gnu/libmdbsql.so.2
libmdbsql.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libmdbsql.so
libmdb.so.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libmdb.so.2
libmdb.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libmdb.so

$ ls -al /usr/lib/x86_64-linux-gnu/libmdb.*
-rw-r--r-- 1 root root 150126 oct 24 23:17
/usr/lib/x86_64-linux-gnu/libmdb.a
-rw-r--r-- 1 root root935 oct 24 23:17 /usr/lib/x86_64-linux-gnu/
libmdb.la
lrwxrwxrwx 1 root root 15 oct 24 23:17
/usr/lib/x86_64-linux-gnu/libmdb.so -> libmdb.so.2.0.1
lrwxrwxrwx 1 root root 15 oct 24 23:17
/usr/lib/x86_64-linux-gnu/libmdb.so.2 -> libmdb.so.2.0.1
-rw-r--r-- 1 root root  86112 oct 24 23:17
/usr/lib/x86_64-linux-gnu/libmdb.so.2.0.1

I'll take a look tomorrow afternoon in a Fedora25 VM, no guarantees, I've
been out of Red Hat derivatives for too long.

Regards.

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

Re: doing a 4.6.1 release

[Salvador Cuñat]

Good night.

2017-02-02 7:12 GMT+01:00 Willem Ferguson :


>
> b) Let's see if its possible to build an AppImage of the Scubapro
> SmartTrak import tool? I think Salva offered to look at that.
>

I'am almost done with it.  I've put a link with a test appimage in
Alessandro's thread you can try.  It fails with a Xcb Qt plugins related
error on most systems I've tried, not all of them.  Ideas about this would
be appreciated, as gooogled solutions are failing for me once and again.
BTW I've solved the localized time crash Dirk reported some days ago. Will
send the patches tomorrow.

Regards.

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

Re: redirecting debug output to a file on Windows

[Linus Torvalds]

On Thu, Feb 2, 2017 at 2:46 PM, Lubomir I. Ivanov  wrote:
> *stderr = *stdout; // seems safe

Don't. It's definitely not safe. It quite likely doesn't even compile
in a number of situations, since there is nothing to keep people from
using an opaque type for the stdio "FILE" type. In fact, that's more
commonly the case than not.

So it might work. Or it might compile and not work. Or it might not
even compile.

You're likely better off using two different files.

Or try the "freopen()" thing to the same file, but use "a" (append) as
the mode (and make both stdout and stderr be line buffered, or
unbuffered).

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

Re: redirecting debug output to a file on Windows

[Dirk Hohndel]

On Fri, Feb 03, 2017 at 12:46:51AM +0200, Lubomir I. Ivanov wrote:
> 
> ok, so i've created a standalone test case and it appears that this
> type of redirection never worked.
> 
> that's because the application EXE is a GUI application (-mwindows)
> and even if we redirect text to some console (via AttachConsole()), we
> cannot redirect the output of the executable call to a file, like so:
> gui_windows_test.exe > test.log
> 
> because the GUI executable itself has no output, if that makes sense.

I would have bet that it worked. But I looked through the email archive
and couldn't find actual PROOF that it worked...

> solutions:
> 
> 1) my last patch...it writes separate log files for stderr / stdout
> it can write the output to the same file with this (mod in
> windows.c::subsurface_console_init()):
> 
> const char *location = logfile ? "subsurface.log" : "CON";
> console_desc.out = freopen(location, "w", stdout);
> *stderr = *stdout; // seems safe
> setvbuf(stderr, NULL, _IONBF, 0); // disable buffering
> setvbuf(stdout, NULL, _IONBF, 0);

I think having it write to two files is fine. I really see this as a very
rarely used oddity if we really need someone to be able to capture debug
output on Windows. This shouldn't be necessary and I don't want us to
spend too much time on making it perfect.

One question, though: is the other win32console option still needed?

> 2) create a windows console application
> stderr / stdout redirection of a windows console application will work for 
> sure.
> 
> also define WIN32_CONSOLE_APP (-DWIN32_CONSOLE_APP)
> 
> QMAKE had this:
> CONFIG += console
> 
> for CMAKE:
> http://stackoverflow.com/questions/2753761/how-do-i-tell-cmake-not-to-create-a-console-window

I guess I'm confused what the pros and cons are... i.e., we gain the
ability to rediret stdout/stderr, what do we lose?

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

Re: redirecting debug output to a file on Windows

[Lubomir I. Ivanov]

On 2 February 2017 at 21:56, Dirk Hohndel  wrote:
> On Thu, Feb 02, 2017 at 09:51:47PM +0200, Lubomir I. Ivanov wrote:
>>
>> attached is updated patch to write separate output files:
>> subsurface_err.log
>> subsurface_out.log
>
> Good enough for the use case.
>
>> the real, clean solution, of course is to redirect from the CMD line,
>> but i have no idea why it no longer works.
>> i'm pretty sure that i've tried that and it worked when i wrote the
>> custom console code for windows.
>
> As I said, I am quite certain that this used to work.
> I love it when things stop working and no one knows why.
>

ok, so i've created a standalone test case and it appears that this
type of redirection never worked.

that's because the application EXE is a GUI application (-mwindows)
and even if we redirect text to some console (via AttachConsole()), we
cannot redirect the output of the executable call to a file, like so:
gui_windows_test.exe > test.log

because the GUI executable itself has no output, if that makes sense.

*nix has that, but Windows doesn't.

solutions:

1) my last patch...it writes separate log files for stderr / stdout
it can write the output to the same file with this (mod in
windows.c::subsurface_console_init()):

const char *location = logfile ? "subsurface.log" : "CON";
console_desc.out = freopen(location, "w", stdout);
*stderr = *stdout; // seems safe
setvbuf(stderr, NULL, _IONBF, 0); // disable buffering
setvbuf(stdout, NULL, _IONBF, 0);

2) create a windows console application
stderr / stdout redirection of a windows console application will work for sure.

also define WIN32_CONSOLE_APP (-DWIN32_CONSOLE_APP)

QMAKE had this:
CONFIG += console

for CMAKE:
http://stackoverflow.com/questions/2753761/how-do-i-tell-cmake-not-to-create-a-console-window

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

Re: Inconsistencies: Showing planner details in dive list

[Dirk Hohndel]

On Thu, Feb 02, 2017 at 09:36:21PM +0100, Robert Helling wrote:
> Willem,
> 
> > On 01 Feb 2017, at 15:37, Robert Helling  wrote:
> > 
> > I think an easy approach would be as follows: Yes, we only have one set of 
> > cylinders per dive, but you don’t have to use all of them, only those with 
> > corresponding gas switch events are shown on the profile (I guess, people, 
> > please correct me). So when merging a real dive with a planned one, we 
> > could put both lists of cylinders in the dive and only use half of them in 
> > the events of a specific “dive computer”.
> > 
> 
> I have just created a pull request on github. Could you please test it this 
> is what you want?

I appreciate that you are tackling all these. I had enough comments to the
commits that I wasn't quite willing to pull this, though :-(

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

Re: Inconsistencies: Showing planner details in dive list

[Willem Ferguson]

>From phone.  Will do, thanks Robert.

On 02 Feb 2017 22:36, "Robert Helling"  wrote:

Willem,

On 01 Feb 2017, at 15:37, Robert Helling  wrote:

I think an easy approach would be as follows: Yes, we only have one set of
cylinders per dive, but you don’t have to use all of them, only those with
corresponding gas switch events are shown on the profile (I guess, people,
please correct me). So when merging a real dive with a planned one, we
could put both lists of cylinders in the dive and only use half of them in
the events of a specific “dive computer”.


I have just created a pull request on github. Could you please test it this
is what you want?

Thanks
Robert

PS: I have not attacked the „spurious gas changes“ problem you also
reported, yet.

___
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: redirecting debug output to a file on Windows

[Lubomir I. Ivanov]

On 2 February 2017 at 21:12, Lubomir I. Ivanov  wrote:
>  const char *location = logfile ? "subsurface.log" : "CON";
>
> console_desc.out = freopen(location, "w", stdout);
> console_desc.err = freopen(location, "w", stderr);

^ this *probably* won't work for stderr, though.

i did not try it.

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

Re: Android/OSi comparison against Windows 10

[Dirk Hohndel]

On Thu, Feb 02, 2017 at 06:46:08PM +0100, Joakim Bygdell wrote:
> >
> > Some settings already seems to be saved to cloud storage, tank-bar being
> > one.
> >
> >
> > Is it? Where? All I am aware of are
> > - autogroup
> > - units
> > and the divecomputers
> >
> 
> I did an quick and dirty test by adding the tank-bar to the mobile-profile.
> And the visibility of it mirrors the settings on desktop at the time of
> saving to cloud.

Are you testing this by running Subsurface-mobile on your desktop
computer, or running it on Android?
For convenience reasons, Subsurface-mobile actually reads your Subsurface
preferences when run on the desktop (that way it picks up proxy settings,
for example, without needing a UI to set those). So that is NOT the same
as getting those preferences through cloud storage...

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

Re: redirecting debug output to a file on Windows

[Lubomir I. Ivanov]

On 2 February 2017 at 18:37, Dirk Hohndel  wrote:
> Lubomir (and others)
>
> I know this used to work, but somehow it doesn't any more...
>
> subsurface.exe 1> dbg.txt 2>&1
>
> instead this prints to stdout and dbg.txt stays completely empty.
>
> Any idea how I can get it to do what I want to do (i.e., collect all
> output in a file)?
>

the command line redirection (>) isn't working and i don't know why. i
wonder if it ever worked.
tried like 5 different solutions, to no avail.

alternative solution / patch attached.

what it does:
- uses a new win32 specific command line argument --win32log
- the freopen() call in windows.c::subsurface_console_init() now knows
if we want to log the output to a file or to the CON (console)
"device"
- eventually it can both output to the console and write to a file

you can apply it and use like so:
cd 
subsurface.exe --win32log -v -v -v

a file subsurface.log will be written.

lubomir
--
From 8706882d300402121d2e281f2fb014c823c404b5 Mon Sep 17 00:00:00 2001
From: "Lubomir I. Ivanov" 
Date: Thu, 2 Feb 2017 21:00:51 +0200
Subject: [PATCH] Win32: add the --win32log option to log stdout and stderr to
 a file

Adding --win32log as the first command line option on Windows
will now log all stdout and stderr output to the file
subsurface.log in the working directory.

This change required a new argument 'bool logfile' to be added to:
subsurface_console_init() which is defined in all platform files
(linux.c, macos.c, etc.)

Example usage:
subsurface.exe --win32log -v -v -v

Signed-off-by: Lubomir I. Ivanov 
---
 core/android.cpp|  4 +++-
 core/dive.h |  2 +-
 core/linux.c|  3 ++-
 core/macos.c|  5 +++--
 core/subsurfacestartup.c|  5 -
 core/windows.c  |  9 ++---
 subsurface-desktop-main.cpp | 12 +---
 7 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/core/android.cpp b/core/android.cpp
index ef55f08..5eb8c59 100644
--- a/core/android.cpp
+++ b/core/android.cpp
@@ -187,8 +187,10 @@ int subsurface_zip_close(struct zip *zip)
 }
 
 /* win32 console */
-void subsurface_console_init(bool dedicated)
+void subsurface_console_init(bool dedicated, bool logfile)
 {
+	(void)dedicated;
+	(void)logifle;
 	/* NOP */
 }
 
diff --git a/core/dive.h b/core/dive.h
index 2578850..95fb5f8 100644
--- a/core/dive.h
+++ b/core/dive.h
@@ -730,7 +730,7 @@ extern void *subsurface_opendir(const char *path);
 extern int subsurface_access(const char *path, int mode);
 extern struct zip *subsurface_zip_open_readonly(const char *path, int flags, int *errorp);
 extern int subsurface_zip_close(struct zip *zip);
-extern void subsurface_console_init(bool dedicated);
+extern void subsurface_console_init(bool dedicated, bool logfile);
 extern void subsurface_console_exit(void);
 extern bool subsurface_user_is_root(void);
 
diff --git a/core/linux.c b/core/linux.c
index b81f6bf..b050472 100644
--- a/core/linux.c
+++ b/core/linux.c
@@ -215,9 +215,10 @@ int subsurface_zip_close(struct zip *zip)
 }
 
 /* win32 console */
-void subsurface_console_init(bool dedicated)
+void subsurface_console_init(bool dedicated, bool logfile)
 {
 	(void)dedicated;
+	(void)logifle;
 	/* NOP */
 }
 
diff --git a/core/macos.c b/core/macos.c
index 500412c..20a575b 100644
--- a/core/macos.c
+++ b/core/macos.c
@@ -201,9 +201,10 @@ int subsurface_zip_close(struct zip *zip)
 }
 
 /* win32 console */
-void subsurface_console_init(bool dedicated)
+void subsurface_console_init(bool dedicated, bool logfile)
 {
-	(void) dedicated;
+	(void)dedicated;
+	(void)logifle;
 	/* NOP */
 }
 
diff --git a/core/subsurfacestartup.c b/core/subsurfacestartup.c
index 7bff437..f240d13 100644
--- a/core/subsurfacestartup.c
+++ b/core/subsurfacestartup.c
@@ -187,7 +187,8 @@ static void print_help()
 	printf("\n --survey  Offer to submit a user survey");
 	printf("\n --user= Choose configuration space for user ");
 	printf("\n --cloud-timeout=  Set timeout for cloud connection (0 < timeout < 60)");
-	printf("\n --win32consoleCreate a dedicated console if needed (Windows only). Add option before everything else\n\n");
+	printf("\n --win32consoleCreate a dedicated console if needed (Windows only). Add option before everything else");
+	printf("\n --win32logWrite the program output to subsurface.log (Windows only). Add option before everything else\n\n");
 }
 
 void parse_argument(const char *arg)
@@ -245,6 +246,8 @@ void parse_argument(const char *arg)
 			}
 			if (strcmp(arg, "--win32console") == 0)
 return;
+			if (strcmp(arg, "--win32log") == 0)
+return;
 		/* fallthrough */
 		case 'p':
 			/* ignore process serial number argument when run as native macosx app */
diff --git a/core/windows.c b/core/windows.c
index 58d3bea..551cbf5 100644
--- a/core/windows.c
+++ b/core/windows.c
@@ -377,11 +377,12 @@ static struct {
 	FILE *out, *err;
 } 

Re: Android/OSi comparison against Windows 10

[Joakim Bygdell]

On 2 February 2017 at 18:41, Dirk Hohndel  wrote:

>
> On Feb 2, 2017, at 9:32 AM, Joakim Bygdell  wrote:
>
> On 2 February 2017 at 18:17, Dirk Hohndel  wrote:
>>
>>
>> Is this something I should hold 4.6.1 for?
>>
> No, not really.
> It it turns out to be simple I can have something done by Sunday morning
> your time.
> It is all about fine tuning the relative positions of the objects in the
> profile.
>
>
> But that's all in Subsurface-mobile. So that isn't really relevant for a
> 4.6.1 release.
> Storing the settings in cloud storage is what I'm most concerned about.
> And Sunday morning isn't a hard cut-off. We can wait another week if
> that's what
> it takes
>
> Or more specifically - this obviously has two components, the one where it
>> saves the relevant settings in git, and the one where it then uses that
>> information in Subsurface-mobile. Obviously the latter is pointless
>> without the former. It might be good to have the code that saves the
>> relevant settings to cloud storage in 4.6.1 so that once we are able to
>> test the changes to the mobile app, the average user actually has those
>> settings in their cloud storage, right?
>>
>
> Some settings already seems to be saved to cloud storage, tank-bar being
> one.
>
>
> Is it? Where? All I am aware of are
> - autogroup
> - units
> and the divecomputers
>

I did an quick and dirty test by adding the tank-bar to the mobile-profile.
And the visibility of it mirrors the settings on desktop at the time of
saving to cloud.

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

Re: Android/OSi comparison against Windows 10

[Dirk Hohndel]

> On Feb 2, 2017, at 9:32 AM, Joakim Bygdell  wrote:
> 
> On 2 February 2017 at 18:17, Dirk Hohndel  > wrote:
> 
> Is this something I should hold 4.6.1 for?
> No, not really.
> It it turns out to be simple I can have something done by Sunday morning your 
> time.
> It is all about fine tuning the relative positions of the objects in the 
> profile.

But that's all in Subsurface-mobile. So that isn't really relevant for a 4.6.1 
release.
Storing the settings in cloud storage is what I'm most concerned about.
And Sunday morning isn't a hard cut-off. We can wait another week if that's what
it takes

> Or more specifically - this obviously has two components, the one where it
> saves the relevant settings in git, and the one where it then uses that
> information in Subsurface-mobile. Obviously the latter is pointless
> without the former. It might be good to have the code that saves the
> relevant settings to cloud storage in 4.6.1 so that once we are able to
> test the changes to the mobile app, the average user actually has those
> settings in their cloud storage, right?
>  
> Some settings already seems to be saved to cloud storage, tank-bar being one. 

Is it? Where? All I am aware of are
- autogroup
- units
and the divecomputers

/D

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

Re: Problems building Subsurface for Android

[Joakim Bygdell]

On 2 February 2017 at 17:01, Dirk Hohndel  wrote:

> >
> > originating at the line:
> >
> > "$SUBSURFACE_SOURCE"/../libdivecomputer/configure --host=${BUILDCHAIN}
> --prefix="$PREFIX" --enable-static --disable-shared --enable-examples=no
> >
> > Does any one have an idea?
> >
> > Of course there is not a libdivecomputer directory in src because I
> started with a clean src directory.
> >
> > Do I need a manual install of libdivecomputer? As fa ar I am aware this
> should not be necessary.
>
> It looks like the Android build.sh doesn't do that, yet.
>
No, but the android-build.sh sets up the current src directory correctly.
The only time this will be an issue is when people runs the build script in
packagin/android directly without running any of the other scripts first.


> Goes to show you that whatever we do, we always make assumptions.
>
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>



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

Re: Re: Problems building Subsurface for Android

[Joakim Bygdell]

Wilhelm,
On 2 February 2017 at 17:28, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

>
>
> On 02/02/2017 18:01, Dirk Hohndel wrote:
>
>>
>> I get the folowing scripting error in build.sh:
>>>
>>> ~/src/libdivecomputer-build-arm ~/src
>>> subsurface/packaging/android/build.sh: line 296:
>>> /home/willem/src/subsurface/../libdivecomputer/configure: No such file
>>> or directory
>>>
>> autoreconf --install
>> in the libdivecomputer directory should take care of that.
>> For odd reasons I sometimes have to run that twice
>> The Android build instructions assume that this is a libdivecomputer
>> directory that has already been used for builds.
>> I guess we could should fix that in the Android build
>>
>>  There is no libdivecomputer directory in src. I have such a directory in
> my backup/src directory which contains the Linux build resources.
> However, in the current src there is a directory
> libdivecomputer-build-arm. But if I remember correctly, I do not need
> the 'normal' libdivecomputer but one that has some Android-specific
> things?? The only other way to get the 'normal' directory is to download
> it from the libdivecomputer website?
> Kind regards,
> willem


The libdivecomputer-build-arm contains the output when the script builds
libdivecomputer for the arm archtecture.
But in order to do so it needs aces to the libdivecomputer sources, and
that folder should be in the same directory as your subsurface folder.
You should be able to symlink your libdivecomputer folder from backup/src
to the current src folder.
If you have built the linux version you will have to do a clean before
building for arm.

If you look in your current src folder there vill be a number of
"-build-arm" folders, those contain the modules built for arm architecture
for subsurface-mobile.


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



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

Re: Fwd: Re: Problems building Subsurface for Android

[Dirk Hohndel]

On Thu, Feb 02, 2017 at 06:28:21PM +0200, Willem Ferguson wrote:
> On 02/02/2017 18:01, Dirk Hohndel wrote:
> > 
> > > I get the folowing scripting error in build.sh:
> > > 
> > > ~/src/libdivecomputer-build-arm ~/src
> > > subsurface/packaging/android/build.sh: line 296: 
> > > /home/willem/src/subsurface/../libdivecomputer/configure: No such file or 
> > > directory
> > autoreconf --install
> > in the libdivecomputer directory should take care of that.
> > For odd reasons I sometimes have to run that twice
> > The Android build instructions assume that this is a libdivecomputer 
> > directory that has already been used for builds.
> > I guess we could should fix that in the Android build
> > 
>  There is no libdivecomputer directory in src. I have such a directory in
> my backup/src directory which contains the Linux build resources.
> However, in the current src there is a directory
> libdivecomputer-build-arm. But if I remember correctly, I do not need
> the 'normal' libdivecomputer but one that has some Android-specific
> things?? The only other way to get the 'normal' directory is to download
> it from the libdivecomputer website?

For some reason the Android script assumes that you have subsurface and
libdivecomputer sources in place. The former makes sense (because you have
the script, so the source should be there), the latter I'm not so sure
about.

Simply do this

cd ~/src
ln -s ~/backup/src/libdivecomputer .

now things should work.

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

redirecting debug output to a file on Windows

[Dirk Hohndel]

Lubomir (and others)

I know this used to work, but somehow it doesn't any more...

subsurface.exe 1> dbg.txt 2>&1

instead this prints to stdout and dbg.txt stays completely empty.

Any idea how I can get it to do what I want to do (i.e., collect all
output in a file)?

Thanks

/D

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

Fwd: Re: Problems building Subsurface for Android

[Willem Ferguson]

On 02/02/2017 18:01, Dirk Hohndel wrote:



I get the folowing scripting error in build.sh:

~/src/libdivecomputer-build-arm ~/src
subsurface/packaging/android/build.sh: line 296: 
/home/willem/src/subsurface/../libdivecomputer/configure: No such file or 
directory

autoreconf --install
in the libdivecomputer directory should take care of that.
For odd reasons I sometimes have to run that twice
The Android build instructions assume that this is a libdivecomputer directory 
that has already been used for builds.
I guess we could should fix that in the Android build


 There is no libdivecomputer directory in src. I have such a directory in
my backup/src directory which contains the Linux build resources.
However, in the current src there is a directory
libdivecomputer-build-arm. But if I remember correctly, I do not need
the 'normal' libdivecomputer but one that has some Android-specific
things?? The only other way to get the 'normal' directory is to download
it from the libdivecomputer website?
Kind regards,
willem


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

Re: Problems building Subsurface for Android

[Dirk Hohndel]

> On Feb 2, 2017, at 7:45 AM, Willem Ferguson  
> wrote:
> 
> I am back at my hobby of trying to build Subsurface-desktop to run on 
> Android. This is to test the FTDI interface.
> 
> Building subsurface/packaging/android/build.sh with
> 
> export SUBSURFACE_DESKTOP=ON
> 
> I get the folowing scripting error in build.sh:
> 
> ~/src/libdivecomputer-build-arm ~/src
> subsurface/packaging/android/build.sh: line 296: 
> /home/willem/src/subsurface/../libdivecomputer/configure: No such file or 
> directory

autoreconf --install
in the libdivecomputer directory should take care of that.
For odd reasons I sometimes have to run that twice
The Android build instructions assume that this is a libdivecomputer directory 
that has already been used for builds.
I guess we could should fix that in the Android build

> 
> originating at the line:
> 
> "$SUBSURFACE_SOURCE"/../libdivecomputer/configure --host=${BUILDCHAIN} 
> --prefix="$PREFIX" --enable-static --disable-shared --enable-examples=no
> 
> Does any one have an idea?
> 
> Of course there is not a libdivecomputer directory in src because I started 
> with a clean src directory.
> 
> Do I need a manual install of libdivecomputer? As fa ar I am aware this 
> should not be necessary.

It looks like the Android build.sh doesn't do that, yet.

Goes to show you that whatever we do, we always make assumptions.

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

Problems building Subsurface for Android

[Willem Ferguson]

I am back at my hobby of trying to build Subsurface-desktop to run on 
Android. This is to test the FTDI interface.


Building subsurface/packaging/android/build.sh with

export SUBSURFACE_DESKTOP=ON

I get the folowing scripting error in build.sh:

~/src/libdivecomputer-build-arm ~/src
subsurface/packaging/android/build.sh: line 296: 
/home/willem/src/subsurface/../libdivecomputer/configure: No such file or 
directory

originating at the line:

"$SUBSURFACE_SOURCE"/../libdivecomputer/configure --host=${BUILDCHAIN} 
--prefix="$PREFIX" --enable-static --disable-shared --enable-examples=no

Does any one have an idea?

Of course there is not a libdivecomputer directory in src because I started 
with a clean src directory.

Do I need a manual install of libdivecomputer? As fa ar I am aware this should 
not be necessary.

Kind regards,
willem


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