Beta Test / Technical

[seandepagnier]

Anyone seen this?

I have issue with this recent commit, but somehow it is only a problem on x86 for me:

Author: David Register <bdbcat@yahoo.com>
Date:   Wed Sep 21 12:14:15 2016 -0400

    Improve vector line-string object rendering for improved performance and smaller memory footprint.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index b9fd1a1..6dd296f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -445,6 +445,7 @@ INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/include ${CMAKE_SOURCE_DIR}/src)
 IF(NOT WIN32 AND NOT APPLE )
   ADD_DEFINITIONS( "-Wall -Wno-unused -fexceptions -rdynamic" )
   ADD_DEFINITIONS( " -g -fno-strict-aliasing")
+  ADD_DEFINITIONS( " -std=c++0x")
   IF(CMAKE_BUILD_TYPE MATCHES "Debug")
     ADD_DEFINITIONS( " -O0")
   ENDIF(CMAKE_BUILD_TYPE MATCHES "Debug")

resulting problem

[ 28%] Building CXX object CMakeFiles/WXCURL.dir/src/wxcurl/base.cpp.o
/usr/bin/c++   -DOCPN_HAVE_X11 -DOCPN_USE_PORTAUDIO -DTIXML_USE_STL -DUSE_GARMINHOST -DUSE_GLU_TESS -DUS
E_LZMA -DUSE_RENDER_CAIRO -DUSE_S57 -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__OCPN_USE_CURL__ -D__WXGTK__ 
-DocpnUSE_GL -DocpnUSE_SVG -isystem /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem /usr/
include/wx-3.0 -I/home/sean/build/OpenCPN/include -I/home/sean/build/OpenCPN/src -I/home/sean/build/Open
CPN/src/wxcurl -I/usr/include/freetype2 -I/usr/include/x86_64-linux-gnu/freetype2 -I/usr/include/glib-2.
0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/u
sr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/inc
lude -I/home/sean/build/OpenCPN/src/wxsvg/include/wxSVG -I/home/sean/build/OpenCPN/src/wxsvg/include/wxS
VGXML -I/home/sean/build/OpenCPN/src/wxsvg/include -I/home/sean/build/OpenCPN/src/wxsvg/src -I/home/sean
/build/OpenCPN/src/nmea0183 -I/home/sean/build/OpenCPN/src/mygdal -I/home/sean/build/OpenCPN/src/garmin/
jeeps -I/home/sean/build/OpenCPN/src/texcmp/lz4 -I/home/sean/build/OpenCPN/src/texcmp/squish -I/home/sea
n/build/OpenCPN/build/CMakeFiles/include  -pthread  -std=c++0x -g   -Wall -Wno-unused -fexceptions -rdyn
amic  -g -fno-strict-aliasing  -O0  -DPREFIX=\"/usr/local\" -o CMakeFiles/WXCURL.dir/src/wxcurl/base.cpp
.o -c /home/sean/build/OpenCPN/src/wxcurl/base.cpp
In file included from /usr/include/wx-3.0/wx/gdicmn.h:23:0,
                 from /usr/include/wx-3.0/wx/event.h:20,
                 from /usr/include/wx-3.0/wx/wx.h:24,
                 from /home/sean/build/OpenCPN/src/wxcurl/base.cpp:19:
/home/sean/build/OpenCPN/src/wxcurl/base.cpp: In member function ‘virtual wxTimeSpan wxCurlProgressBaseE
vent::GetEstimatedTime() const’:  
/home/sean/build/OpenCPN/src/wxcurl/base.cpp:225:30: error: ‘isnan’ was not declared in this scope
     if (nBytesPerSec == 0 || wxIsNaN(nBytesPerSec))
                              ^
/home/sean/build/OpenCPN/src/wxcurl/base.cpp:225:30: note: suggested alternative:
In file included from /usr/include/wx-3.0/wx/math.h:58:0,
                 from /usr/include/wx-3.0/wx/gdicmn.h:23,
                 from /usr/include/wx-3.0/wx/event.h:20,
                 from /usr/include/wx-3.0/wx/wx.h:24,
                 from /home/sean/build/OpenCPN/src/wxcurl/base.cpp:19:
/usr/include/c++/5/cmath:641:5: note:   ‘std::isnan’
     isnan(_Tp __x)
     ^
In file included from /usr/include/wx-3.0/wx/gdicmn.h:23:0,
                 from /usr/include/wx-3.0/wx/event.h:20,
                 from /usr/include/wx-3.0/wx/wx.h:24,
                 from /home/sean/build/OpenCPN/src/wxcurl/base.cpp:19:
/home/sean/build/OpenCPN/src/wxcurl/base.cpp: In member function ‘std::__cxx11::string wxCurlProgressBaseEvent::GetHumanReadableSpeed(const string&, int) const’:
/home/sean/build/OpenCPN/src/wxcurl/base.cpp:251:23: error: ‘isnan’ was not declared in this scope
     if (speed == 0 || wxIsNaN(speed))
                       ^
/home/sean/build/OpenCPN/src/wxcurl/base.cpp:251:23: note: suggested alternative:
In file included from /usr/include/wx-3.0/wx/math.h:58:0,
                 from /usr/include/wx-3.0/wx/gdicmn.h:23,
                 from /usr/include/wx-3.0/wx/event.h:20,
                 from /usr/include/wx-3.0/wx/wx.h:24,
                 from /home/sean/build/OpenCPN/src/wxcurl/base.cpp:19:
/usr/include/c++/5/cmath:641:5: note:   ‘std::isnan’
     isnan(_Tp __x)
     ^
CMakeFiles/WXCURL.dir/build.make:65: recipe for target 'CMakeFiles/WXCURL.dir/src/wxcurl/base.cpp.o' failed
make[2]: *** [CMakeFiles/WXCURL.dir/src/wxcurl/base.cpp.o] Error 1
make[2]: Leaving directory '/home/sean/build/OpenCPN/build'
CMakeFiles/Makefile2:420: recipe for target 'CMakeFiles/WXCURL.dir/all' failed
make[1]: *** [CMakeFiles/WXCURL.dir/all] Error 2
make[1]: Leaving directory '/home/sean/build/OpenCPN/build'
Makefile:152: recipe for target 'all' failed
make: *** [all] Error 2

[bdbcat]

Dan...

You get the issue clearly, I think.

re:
But it seems to me a bad practice to have cached data that can't be unambiguously linked to the parent data in a bidirectional way. I believe that's a necessary condition to be able to know if each piece of the cache is valid or invalid.

I'm not sure we ever need to get from the SENC back to the source. We always (?) generate the SENC name dynamically from the requested source cell name, and then validate that SENC state against the state of the source. Rebuild the SENC if necessary.

Indeed, we certainly do not want to embed the source filename in the SENC file, since we are moving toward full platform portability of SENC files in support of some new chart architectures contemplated.

So I think creating the SENC file name from a simple hash of the source file full path name will do the job, just leading to longer and more abstruse file names in the (still flat) SENC directory.

We already use the same approach for the OpenGL Raster texture cache files. The file names there are truly ugly,

  file:///home/dsr/.opencpn
/raster_texture_cache/0272D5422E3D554D5A7F30C8565E9AF3B4D492FC.

This allows multiple charts in the same way contemplated here. So I think we are OK.


I'll implement for ENC. Should be quick and clean.

Comments?
Dave

[bdbcat]

Sean....

The definition of isnan changed in recent libraries, but wxWidgets has not caught up. We need those new libraries for some improved hash map stuff in ENC processing.

I'm on another branch at the moment, so I can't get to the code.

But, take a look at the bottom of dychart.h. There is a fixup there involving isnan on linux systems. I think you need to modify that to recognise the mingw case as well.

Let me know.
Dave

[seandepagnier]

Dave,

I am not compiling for mingw.

This is linux x86_64 gcc 5.4

I think the solution is to use ::isnan or std::isnan or ? wxIsNaN apparently is defined to be "isnan" which gets blocked by the new standard....


Are you saying it's a wx bug? Can we for now use the new standard of c++ only for the senc file (that doesn't use wxIsNaN ?

[bdbcat]

Sean...

Does this not work for you?

#undef wxIsNaN
#define wxIsNaN std::isnan
#endif

Which cpp file has trouble?

Dave

[bdbcat]

cagney, et al...

I have implemented new logic for naming SENC files. In github now.

This code ties the SENC to the source .000 cell file location using a simple hash subset. So we can support duplicate-but-different SENC file creation.

Now, maybe, PaEC will work correctly for arbitrarily arranged chart trees.

Good Luck
Dave

[Hakan]

Dave..
- Built wo problem using W10 and VS2013.
- Running PaEC used around two minutes more but that's no problem. This function is seldom used.
- And this is so nice. I previously had some gaps for canal parts in Germany and Poland but they are now complete! No new files added. I thought they where missing from the chart sources but the old code obviously didn't found them.
- The old PaEC method produced 1466 SENC files and this 743 for the same chart files. And still more charts found??
- The old SENC files still remains if I don't delete them manually. Is that anything we should take care of for the "normal" users? Would the "Force Full Database Rebuild" also delete SENC files?

Thanks
Håkan

[cagney]

Dave

Yes it works as expected now

+I deleted the old SENC directory, and renamed three updates files in the chart tree.
+PaEC first run took 29 minutes.
+Restored the three renamed update files.
+PaEC took 21 seconds !!!. It updated three files, no more.
+No activity when briefly panning around.

PaEC-log5.txt.pdf

Thanks
Thomas

[rgleason]

Git fetched, built & installed on Win10
* master 3c6b227 Implement extended SENC naming scheme to avoid SENC name
Ran Options > Charts > "Prepare all ENC"
It ran for about 20 minutes (have done this 3x's). I have eastern seaboard NOAA and now ACE Inland + Bouys.

There were no errors or black screens.

I am using Intel HD Graphics 3000 with OpenGL because OpenCPN with OpenGL now crashes with my Nvidia Geforce 540M. I've jut tested the Nvidia which passes all glviewer tests from 4.3 to 3.0 and is faster and better than the Intel graphics. Any suggestions?

Also I have a blue spinner that does not go away. Any ideas?
PS: Memory is about 443mb and CPU 0 for Opencpn.

Its very nice not to have Senc interruptions, but I'd love to try this with my Nvidia and OpenGL.

[seandepagnier]

Dave,

Yes, it works.... with a lot of patches, I made pull request.

I think wxIsNaN is broken in c++x0? For now use std::isnan?

[bdbcat]

Sean...

I think I will simply revert the commit that broke IsNan. I don't really require std::unordered-map, it is just an optimization. Maybe too early for c++x0.... I had no idea there would be so much breakage.

Dave

[seandepagnier]

Dave,

can you use c++x0 on just that one file?

[nohal]

Dave...
I don't think it's actually THAT bad - maybe we can use the good aspect of it and start moving from WX to stdlib in the core - long term it has just advantages IMO (actually on macOS moving to -std=c++11 would be even more desirable for the future)...

Pavel

[CarCode]

Originally Posted by nohal

Dave...
I don't think it's actually THAT bad - maybe we can use the good aspect of it and start moving from WX to stdlib in the core - long term it has just advantages IMO (actually on macOS moving to -std=c++11 would be even more desirable for the future)...

Pavel

I second this.
Gerhard

[rgleason]

Also I have a blue spinner that does not go away. Any ideas?

Blue spinner went away, for no apparent reason.

By the way, I think it was awhile ago that I started crashing with opengl on when using the Nvidia Gefforce 540M. I was trying to get something done and just used the Intel HD graphics (with or without OpenGL) or Nvidia without OpenGL until now.

Bdbcat I don't think recent programming caused this (it could be a driver, but I don't believe that's that problem, because both cards pass glviewer tests) Just wanted to let you know its not associated with anything your doing now.