Beta Test / Technical

[Psyches]

Originally Posted by CarinaPDX

The 1.3.6 RC has a couple of very obvious issues when I execute it on 10.6.2, which I would like to report or at least check to see if they are being tracked already. Where are Mac-specific bugs being tracked? For that matter, is the bug tracker on Sourceforge the place for general bugs?

There are two or three threads that are currently dealing with Mac development, which is confusing to say the least. I suspect that one of the problems I have noted was already fixed by a patch Erwin developed and referred to on a different thread. Wouldn't it be best to have a single, sticky thread dedicated to Mac development?

I would like to be a beta tester, if nothing else, for the Mac versions. Is there a mailing list to alert testers to new versions needing testing?

I'm not being critical here - I just want to help move this great project forward.

I'd suggest the best place for bugs is sourceforge for both general and specific bugs. But for help and general info passing, the most recent active Mac thread I'm aware of is here although the title is I guess too specific.

We can tailor sourceforge some as needed, if needed. If folks have suggestions, please let me know. As for the best way to proceed for Mac beta testing and continued dev, I defer to the Mac crowd.

Mark

[idpnd]

Find two below two screenshots with CMAP and a raster chart in the exact same spot (054 34.676 N 008 34.217 E) to illustrate the drying heights CMAP display bug as reported at sf.net.

This [indication] is used on areas that emerge at low tidal levels (displayed in green in opencpn), to calculate when it is possible to pass them at higher tide (Drying Height: Clearance in meters (or feet in old charts) above the chart datum).

[HamishB]

Hi,

** opencpn.org is down and needs to be renewed ASAP before a squatter grabs it!!



FYI OpenCpn 1.3.6 has been included on the new Live DVD/virtual machine/USB stick put out by OSGeo, along with some sample data and getting started docs. (and about 30 other free geo projects to try) The LiveDVD will be handed out to hundreds of people at various conferences over the few next months.

I don't have the bandwidth to download the entire thing from where I am and it goes off to the printers very soon, so if anyone is interested and able to check it out and test that all is working as expected it would really help out. It's sort of a bad look if our app doesn't work correctly!

version 3.0rc4 (or newer) at:
http://download.osgeo.org/livedvd/

See the main help icon on the desktop for getting started info such as location and enabling of the sample NOAA charts.


thanks,
Hamish

[idpnd]

Thanks for the info Hamish..

This can apparently be launched via your web browser?

Live GIS Disc - OSGeo Wiki

[cagney]

First reported on the Sorceforge site by "sailias"

Now the problem. Loading the NOAA vector charts (all of them) by means of adding the root archive all charts get indexed and displayed on the base grid of available maps.

However when you click on one of the designated chart outlines in green, the programs start its process to load the chart but consistently fails. I checked the log file and its not helpful. Running top Im at 100 percent CPU utilization.

So was wondering what is the proper way to add NOAA vector charts, so that it does not create a endless loop or whatever is causing 100 percent CPU usage.

Sailias is using "System is Ubuntu Remix 9.10 on an Asus Netbook 1000HE with 2G memory".

I tested on Ubuntu 9.10, no problem.
But.....I found the same problem on Eeepc 901 with an Atom processor.

I think that "top" reports wrong CPU values. I have seen total values way above 100% at the same time load average hovers just below 1.0 with very little else running. For example OpenCPN shows 100% and starting Firefox shows this program at 69% at the same time, for a short while, and a few other programs showing 1 or 2 %.
Linux is not hung, you can continue with other tasks, nevertheless OpenCPN is stuck.

Starting OpenCPN through ddd reveals that the program seems to be stuck in an eternal loop between

gettimeofday ()

from libc.so.6 and

__kernel_vsyscall ()

wxGetLocalTimeMillis ()

comes just before the gettimeofday call.

This problem only comes up with S57 charts, not CM93 or raster charts.

Anyone with ideas how to solve this?

Thomas

[idpnd]

Not sure about the cycle in the code, but regarding top there certainly may be more processor load than processor time; anything that doesn't get done accumulates in the "load" indicator at the top right

"top - 19:18:21 up 11:52, 4 users, load average: 0.43, 0.30, 0.21"

[Psyches]

Thomas, can you post a stack trace of the hung thread?

[sinbad7]

If it's any help, I have all the Dutch S57 waterways charts loaded and never had any problems. Perhaps your charts are of a 'protected' nature or are faulty? I am running Vista on an Acer laptop.

[cagney]

Thank you Psyches, here it is.
Sorry sinbad, nothing exotic, plain US std ENC charts.
It's a bit unclear above, my eeepc is also running ubuntu 9.10 netbook remix, same as sailias. My first test was on my std box with an old amd athlon processor.
Thomas

[Psyches]

Originally Posted by cagney

Thank you Psyches, here it is.
Sorry sinbad, nothing exotic, plain US std ENC charts.
It's a bit unclear above, my eeepc is also running ubuntu 9.10 netbook remix, same as sailias. My first test was on my std box with an old amd athlon processor.
Thomas

Ah, I see. The gpsd read is the culprit. You might try disabling nmea while charts are being set up.

But it'd be good to know what's really going on there. The S57 chart import is a known perf hog - I posted a fairly long thread about it a few months ago. Here's the wxWidgets culprit. If you search for "wxSocketBase::_Wait", you'll see the potential problem area. In this case, the seconds param is -1 and millis is 0; it'd be interesting to see what the other relevant values are. It's possible we're hard-looping - but maybe we're just taking an inordinate amount of time slowly reading position bytes.

Mark

[champ8242]

There was a report of two eeepc's unable to start (looping) OpenCPN on Windows 7 starter. I tested OpenCPN on W7S on a laptop without problems

[cagney]

Psyches, you are right.
Unexpectedly gpsd was running by default, even though it is supposed to start when you plug in your gps.

So the temporary fix is easy:

$ sudo killall gpsd

Once gpsd is out of the way, there is no problem with the SENC creation.

The real PITA is that we have been down this lane before, if my memory serves me right.....
It is time to sort this out in the code!
I also think that a batch conversion possibility for S57 charts is called for, this should run when you install the charts. That way these charts will be installed once and for all, ready for use.

Thomas

[Psyches]

Originally Posted by cagney

Unexpectedly gpsd was running by default, even though it is supposed to start when you plug in your gps.

Great, glad you found a work around...

The real PITA is that we have been down this lane before, if my memory serves me right.....
It is time to sort this out in the code!
I also think that a batch conversion possibility for S57 charts is called for, this should run when you install the charts. That way these charts will be installed once and for all, ready for use.

Totally agree re: batch conversion. Also I really think the SENC create and use could be less piggy. If you have a pointer to the last time around this prob, I'll do a bit of self-education. I don't generally look at the Linux-specific stuff much.

Mark

[cagney]

Psyches

Last time this issue was up, was last august here:
http://www.cruisersforum.com/forums/...tml#post325002
See also, posts #837,#838, and #852.
I don't think any follow up was done. Dave will know if he made any adjustments to the code as a result of this.
We now know that the problem is still there,..... and that my memory span is below 6.5 months.

Thomas

[sailias]

Greets:

Can confirm that turning off gpsd did the trick. Many thanks for this wonderfull application as I been waiting a long time for this. Actually discovered the app on the OpenGeo DVD iso testing gpdrive which is too much work to process all the tiles, does not do vector charts and no editing capability. For other uses however its very good.

If you need a test monkey, not a coder, but can read some with instructions, feel free to ping me on or off list as would love to help sort out this application. Combined with zygrib, and a couple of other linux apps, the navigation component for my sail boat is at 99 percent linux which is the intend, just my personal preference, not a distro war.

Again, many thanks

Chris H.