Beta Test / Technical

[rgleason]

Thanks, Dave. I see the grib_pi.dll mentioned now. .. Will do this.

[rgleason]

Git question after troubles with compiling due to grib_pi file issues.
A. I simply deleted the plugins/grib_pi directory then "git fetch" and "git pull origin master" .
B. The plugins/grib_pi directory reappeared. I thought it might have essentially cloned a full new grib_pi directory but files are missing, and the the weather routing plugin is complaining now.

Is there a way to clone a subdirectory (plugins/grib_pi) and get back on track?
I found this Git instruction and some references to submodules, but I am not sure that will accomplish what I want.

I'd like to execute a "git clone plugins/grib_pi" command OR a git pull origin master/plugins/grib_pi to bring my repository into compliance with the branch "origin master".

Then I'd like to be able to update the entire repository with the usual git fetch and git pull origin master.

Any suggestions would be appreciated.

[rgleason]

PS - did this, but the po directory does not exist, and the src directory only has two of the files now.


C:\Data-Dart\Up-Soft\Navigation\opencpn-git\plugins\grib_pi>git ls-files
CMakeLists.txt
GRIB.fbp
po/POTFILES.in
po/cs.po
po/da.po
po/de.po
po/el_GR.po
po/es.po
po/et.po
po/fi_FI.po
po/fr.po
po/grib_pi.pot
po/hu.po
po/it.po
po/nb_NO.po
po/nl.po
po/pl.po
po/pl_PL.po
po/pt_BR.po
po/pt_PT.po
po/ru.po
po/sv.po
po/tr_TR.po
po/zh_TW.po
src/GribOverlayFactory.cpp
src/GribOverlayFactory.h
src/GribReader.cpp
src/GribReader.h
src/GribRecord.cpp
src/GribRecord.h
src/GribRecordSet.h
src/GribSettingsDialog.cpp
src/GribSettingsDialog.h
src/GribUIDialog.cpp
src/GribUIDialog.h
src/GribUIDialogBase.cpp
src/GribUIDialogBase.h
src/IsoLine.cpp
src/IsoLine.h
src/bzip2/blocksort.c
src/bzip2/bzlib.c
src/bzip2/bzlib.h
src/bzip2/bzlib_private.h
src/bzip2/compress.c
src/bzip2/crctable.c
src/bzip2/decompress.c
src/bzip2/huffman.c
src/bzip2/randtable.c
src/email.cpp
src/email.h
src/folder.xpm
src/grib.svg
src/grib_pi.cpp
src/grib_pi.h
src/grib_pi.svg
src/icons.cpp
src/icons.h
src/icons.sh
src/msg.h
src/smapi.cpp
src/smapi.h
src/zlib-1.2.3/zconf.h
src/zlib-1.2.3/zlib.h
src/zuFile.cpp
src/zuFile.h

[rgleason]

I just received an email from Alexandre Rio,

"I recently created a devel package for OpenCPN, so that plugins can be built separately. I patch yours, hope you'll enjoy it.
Please, see the wiki page and the build page, where the OpenCPN-devel package is."

This might be very useful for development, however I read it is for the OpenSUS development, and I'd like to know more about how this all works and if plugins can be compiled separately from using OpenSus, and what that means. Has anyone else tried this? It looks easy enough to do. Can anyone comment? I certainly could have used this earlier.

The writeup is here, I've read it.
https://en.opensuse.org/OpenCPN-build-plugins

Pretty comprehensive list of plugins:
https://build.opensuse.org/project/s...o:OpenCPN:head

I am not so sure this will also work with Windows compilation?

[reflectionsv37]

Hi Dave!!

I was happy to see the export of multiple waypoints in this release! I just had a need to export a selected group of my waypoints and noticed a slight problem.

After selecting the waypoints and clicking Export Selected, I noticed that the save dialog box is not showing the names of other GPX files in the folder. I typed in the name of a known GPX file in the folder and OpenCPN recognized that the file name already existed and asked if I wanted to overwrite the file, as it should.

I'll be sharing this GPX exported file with other users tomorrow and will let you know if there are any issues when importing the file.

Thanks for making this upgrade!!!

Gene

[rgleason]

Pavel, Dave, others.

Sean's plugins Weatherfax and Weather_Routing no longer compile due to certain errors with cutil.h and georef.c

http://www.cruisersforum.com/forums/...ml#post1339659

http://www.cruisersforum.com/forums/...ml#post1335370

Can you advise? Particularly with regard to cutil.h Has something changed that requires us to change code in the plugins?

Thanks.

[bdbcat]

Rick....

I noticed this before in Sean's code.
In the CmakeLists.txt, Sean uses direct references to the OpenCPN source tree, e.g.

#include {OCPN Source Tree}/include/cutil.h.

.or.
../../src/wxJSON/jsonval.cpp

This is not allowed, and is sure to break sooner or later. Plugin source trees may take local copies of anything that they want from the OCPN tree. But the only thing that may be used dynamically is OCPNPlugin.h

What is happening here is that the master branch is evolving, as it should. And some change in the base code broke the PlugIn source.
So sorry, but that will happen often if PlugIn devs don't follow the rules

Said another way: PlugIns must maintain their own local copies of all the files they need to build, independent of the main OCPN source tree. All you really need from the main tree is OCPNPlugIn.h, and it need not be current. It only needs to be current up to the PlugIn API revision supported by the PlugIn in question.

Take a look at Dashboard. It contains local copies of all the NMEA decoding classes, and they are simply clones of the same files in the base code. Not links. That's the way our PlugIn API works.

And another view: Unless a PlugIn changes its API revision requirement, there must be no need to re-build a PlugIn for a new base version. We promise backward compatibility this way.

Thanks
Dave

[rgleason]

Thankyou Dave,
How would we fix this? Go back to the version where it compiles properly, and trace the external file refs to opencpn base, then copy and change the path in the code?

Is there a good way to search the plugin src to find these illegal references?

[bdbcat]

Rick...

Go back to the version where it compiles properly, and trace the external  file refs to opencpn base, then copy and change the path in the code?

Yes.

The easiest way to find the bad references would be to move the PlugIn build tree completely out of the OCPN build tree. Then, the affected files won't be found by relative reference, and you will get a lot of build errors. Fix them one at a time by copying the files you need from an earlier version of OCPN, say 3.2.2. Put the copied files into the new PlugIn build tree. Fix CMakeLists.txt. Straightforward, if tedious...

Dave

[rgleason]

See post http://www.cruisersforum.com/forums/...ml#post1315430

After selecting the waypoints and clicking Export Selected, I noticed that the save dialog box is not showing the names of other GPX files in the folder. I typed in the name of a known GPX file in the folder and OpenCPN recognized that the file name already existed and asked if I wanted to overwrite the file, as it should.

Gene [reflectionsv37] Downloaded current beta 3.3.814 and reports "Just checked the 814 version and Dave must have already fixed it!! He's good!!!"

Thank you Gene. Your help with Tracker (Votes etc,) is appreciated.

[rgleason]

Dave,

re Bad Plugin References Post #1044
re Illegal Direct Plugin References to Opencpn Source Tree [inevitable break sometime] Post #1042

Thank you. Will try when I have some time.

I'm leaving a Comment in Developer's manual about this.PlugIn API | Official OpenCPN Homepage new comment about Plugin Dependencies.

[dominig]

Hello,

I try to keep a ready to run up-to-date Beta for people who can test but are not developpers.
I do that for OpenSUSE.
https://build.opensuse.org/project/monitor /Application:Geo:OpenCPN:beta?arch_i586=1&defaults= 0&failed=1&repo_openSUSE_12_1=1
For the last few weeks I have not bee able to build a beta because I always get a plug in which fails. This week bad guy is
aisradar_pi (see log bellow)

Would it be possible for each plugin maintainer to keep a tag of their latest valid beta in a know place (ideally on the Wiki download page) in order to be able to rebuild a valid Beta with the plug-ins for test and validation.

And obviously such tag would even be more important to build stable image.

Best would be to set the tag to be the same for OpenCPN main and the plug-ins.
(e.g. last main code Beta tag is 3.3.814)

Having daily broken is less surprising even if I have to say that my last successful dayling build is now very old (Aug 15, 2013)

Regards

Dominig


Scanning dependencies of target aisradar_pi [ 182s] [ 70%]
Building CXX object plugins/radar_pi/CMakeFiles/aisradar_pi.dir/src/aisradar_pi.cpp.o [ 182s]
In file included from /home/abuild/rpmbuild/BUILD/OpenCPN-1378864470/plugins/radar_pi/src/aisradar_pi.cpp:35:0: [ 182s]
/home/abuild/rpmbuild/BUILD/OpenCPN-1378864470/plugins/radar_pi/src/aisradar_pi.h:44:33: fatal error: opencpn/ocpn_plugin.h: No such file or directory [ 182s]
compilation terminated. [ 182s] make[2]: *** [plugins/radar_pi/CMakeFiles/aisradar_pi.dir/src/aisradar_pi.cpp.o] Error 1 [ 182s] make[1]: *** [plugins/radar_pi/CMakeFiles/aisradar_pi.dir/all] Error 2

[rgleason]

I'm leaving a Comment in Developer's manual about this.PlugIn API | Official OpenCPN Homepage new comment about Bad External File References and Plugin Dependencies.

See Developer Manual - Plugin Troubleshooting

[Hakan]

Misplaced text element, _texto, in CM93 charts.
When using scales around 80000, the "C" parts, texto elements are generally located at wrong positions. The divergences are not equal but differ a lot from object to object. When using scales from ~70000, the "E" parts, everything is correct.
The faults are probably nothing new but I haven't recognised it before. Are the text locations controlled by OCPN or the CM93 data base?

[bdbcat]

dominig...

There is no need to rebuild PlugIns on each new main program Beta. In fact, there is good reason NOT to.

PlugIns are designed to be backward compatible. That is, any old PlugIn should (must) work correctly with any more recent OCPN main program.
If it does not, we want to know about it. The solution to such a problem lies in the OCPN Beta, not the older PlugIn.

However, if the PlugIns are correctly built without main source tree dependencies, then they will build fine independent of updates to the OCPN main code. But there is no reason to do so unless the PlugIn itself has changed.

The reason for all this is as follows: PlugIn developers must have some assurance that all their hard work will not evaporate on the next Release of OpenCPN. So PlugIns, once functional, will always be functional.

I hope this is clear.

Thanks
Dave