OpenCPN Beta Version 3.3.1731 Released

[CarCode]

Originally Posted by bdbcat

Gerhard....

Latest GRIB is broken in what way?

Thanks
Dave

Does not show any overlays nor any data.
Reverted back and all is working again.

Gerhard

[CarCode]

BTW: GshhsPolyReader::crossing1() crashes also.

I'm really not amused about Sean.

Gerhard

[bdbcat]

Gerhard...

1. Grib: Current github works for me on Windows and Linux. See pix. Not tested Mac yet. That's next.

2. Acknowledge the crash on gshhs.cpp
If you want to test further, you may patch gshhs.cpp and remove all occurrences of "assert(...), or replace them with "wxASSERT(...)

Dave

[CarCode]

Thanks, assert() has been already patched here.
Dunno why grib 2.3 doesn't work. Got back to 2.2 and it is OK.

Gerhard

[Ptizef]

New git hub today (windows )
- OpenCPN do not compile (problem symbol extern on GshhsPolyReader::crossing1Init(void) )
- Grib-Pi compile OK but do not work with previous git's opencpn.exe
- nothing displayed (barbed arrows, colored overlays etc ..
- crash if I try to change any setting

Jean Pierre

[CarCode]

Jean Pierre,

la meme choose ici avec Mac OS X.
Je ne suis pas content avec les modificationes d'un certaine personne.

Gerhard

[CarCode]

BTW Since implementing "Merge pull request #135 from seandepagnier/master" my CPU usage climbed up to 38 percent.
I got it down to 3-4 percent before.

I vote to: please do not kill us anymore with these "optimizations".
There are still some other tasks like a final s63 plugin.

Gerhard

[bcn]

Gerhard,

don't understand your "panic mode".

Dave laid out the next steps in the post #160 in this thread -
and regressions in a case like this are no surprise.
Errors neither - that's what testing of a beta is about, isn't it?

So your testing helps, yes.

Hubert

[CarCode]

Hubert,

es ist keine Panik, aber schlichtweg eine Unverschämheit wie dieser Kerl die Sourcen kaputt macht. Vielleicht verstehst Du das nicht so...

Gerhard

[bcn]

Originally Posted by CarCode

Hubert,

es ist keine Panik, aber schlichtweg eine Unverschämheit wie dieser Kerl die Sourcen kaputt macht. Vielleicht verstehst Du das nicht so...

Gerhard

translation:

"this is no panic but it is just impertinent how this guy is destroying the sources.
Perhaps you don't understand this in this way.."


--> #160 of this thread...

btw.: S63 works with either of the beta versions and people are sailing with it.
And the nice thing about Open Software is that we don't have deadlines.
So why being impatient? Or nervous?

Hubert

[CarCode]

Hubert,

I think you don't get it.
S63 plugin is still beta and users don't use betas especially if they have to pay for it.
Instead of eliminating bugs there are always new bugs in the main code.
That is very frustating.

Gerhard

[bcn]

Well,

the idea is that the S63 PI will go 1.0 with the next beta.
And on the other hand if somebody now wants to use S63 charts - that works.
Makes no difference for us if there are 15, 150 or 15.000 users of the PI.
But we are implied to have it stable and reliable, be assured.

And if the number of bugs increases or is getting more comfortable thats just the normal process. Remember the Debian release cycles just in case.

No reason for frustration for me - just testing and reporting in order to add my grain of salt to the development cycle.

Good night

Hubert

[seandepagnier]

Originally Posted by bdbcat

Gerhard...

1. Grib: Current github works for me on Windows and Linux. See pix. Not tested Mac yet. That's next.

2. Acknowledge the crash on gshhs.cpp
If you want to test further, you may patch gshhs.cpp and remove all occurrences of "assert(...), or replace them with "wxASSERT(...)

Dave

Dave, does using wxASSERT instead of assert fix the crashes? assert was already being used in gshhs.cpp so I assumed it is ok to use there.

Originally Posted by Ptizef

Hi
I tried to find the commit using git-bisect

I found this is between
this commit :
12/05/2014
3.3.1712
100fdbccce6865ebb356d67bad289ff5ff8f6c73
which is the last I can compile and test with OK result

And this one :

15/05/2014
Correct glCanvas setup for Windows proc addr location search.
2e0754af9bf41347cf4cb6fd6b108c8880b3011d

with is the fisrt I can compile and test NO OK


Between them, I was unable to test because either they do not compile or they crash


But the more important is I think I've found a fix for the problem with this patch :


//

@@ -1430,7 +1432,7 @@ void GRIBOverlayFactory:rawGLTexture( GLuint texture, int width, int height,
glEnable(GL_TEXTURE_RECTANGLE_ARB);
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, texture);

- glDisable( GL_MULTISAMPLE );

glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);



//
After suppressing this line which seemed curious, I was unable to reproduce the display problem on both my machines


I will post a pull request for that patch


Jean Pierre

The glDisable should not hurt anything, but also shouldn't be there, so you are right to delete that line. Perhaps your driver uses multisampling to emulate something.

Originally Posted by Ptizef

New git hub today (windows )
- OpenCPN do not compile (problem symbol extern on GshhsPolyReader::crossing1Init(void) )

windows handles function linkages in a different way, so the build error only shows up there. I have fixed the problem, sorry for the trouble. I have pushed the change to my fork (github.com/seandepagner/OpenCPN) and will post a pull request.

- Grib-Pi compile OK but do not work with previous git's opencpn.exe
- nothing displayed (barbed arrows, colored overlays etc ..
- crash if I try to change any setting

Jean Pierre

It works for me, the changes are to use polar interpolations instead of vector interpolation, and provide time slices for moving gribs.

My guess is that the new routine breaks only on certain grib files. I will try with more grib files, but if you could post the one that isn't working it would help.

[bdbcat]

Sean...

1. wxASSERT fixes the assert crash. Dunno why, exactly.

2. I have fixed the Windows linkage problems in gshhs, and will be in my next batch of commits. So no need for a pull request. Actually, the problem was a bad diff in the git commit. The entire method GshhsPolyReader::crossing1Init() went missing. I have no idea how linux actually linked the full binary....

3. I also would like to see specific GRIB files that cause trouble, so I can add them to my test pool.

4. I am close to a Beta release, tomorrow probably. So you may wish to hold off on any tweaks for a couple of days, please.

Thanks
Dave

[Ptizef]

Hi Dave, Sean

Ok I think I have understood
It work ( at least the first test ) with Saildocs's files
But it do not work with Zygrib's files
I faced that problem in the past and found they have a difference. I think they have a negative DJ or something like that don't remember exactly and no time this morning to search. I joint a file as example

I confirm : No display and crash when changing setting and interpolate is selected

Jean Pierre