Suggestion: Replace Appveyor with Github actions

[pjb7687]

This is a suggestion to replace windows build by Appveyor with by Github actions.

Pros:

• Free parallel builds
• Faster build thanks to actions/cache (https://github.com/actions/cache)
• Longer build time limit (6 hours instead of 1 hour)

Cons:

• Hard to RDP into the build session (although it seems to be possible using this: https://github.com/nelsonjchen/reverse-rdp-windows-github-actions/)

[pjb7687]

Latest successful build:
https://github.com/pjb7687/gdl/actions/runs/492167346

[slayoo]

Does GA provide 32 bit environments?
If not, I vote for keeping both as currentlu 32-bit Appveyor builds are the only place we check 32-bit compilation!

And, firs of all, big thanks for adding GA scripts!

[pjb7687]

Does GA provide 32 bit environments?
If not, I vote for keeping both as currentlu 32-bit Appveyor builds are the only place we check 32-bit compilation!

And, firs of all, big thanks for adding GA scripts!

Hi, yes, of course you can compile 32bit builds in GA. Actually both Appveyor and GA vms are 64 bit, but what we are doing is 32bit cross-compilation.

You can see i686 build artifacts in the provided link.

[pjb7687]

Now the latest build includes GRIB. I just contributed to MSYS2 repo (msys2/MINGW-packages#7659). So what do you think? No other objections yet?

[maynardGK]

I am all in favor of new structural changes ...
I've just had the chance to test the driver patch more fully, the new driver can't handle the following, it will put a plot on window 1 but not 2,3,4 or 5:

fs=findgen(40) & !prompt="" & iw=-1
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
wshow,iw,0
wshow,iw-1,0
wshow,iw-2,0
wshow,iw-2,/icon
wshow,iw-2,0
wshow,iw-3,0
wshow,0,0,/icon
wshow,0
end

[pjb7687]

I am all in favor of new structural changes ...
I've just had the chance to test the driver patch more fully, the new driver can't handle the following, it will put a plot on window 1 but not 2,3,4 or 5:

fs=findgen(40) & !prompt="" & iw=-1
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
iw++&window,iw,xs=512,ys=512,xp=128*iw,yp=128*iw&plot,fs,chars=iw,thi=iw
wshow,iw,0
wshow,iw-1,0
wshow,iw-2,0
wshow,iw-2,/icon
wshow,iw-2,0
wshow,iw-3,0
wshow,0,0,/icon
wshow,0
end

Thanks! I am merging this, and lets handle it then...

[pjb7687]

@maynardGK Would you mind opening a new issue?

[maynardGK]

Done. I also had trouble manipulating keyboard focus using the wx driver, which would be preferred over wingcc when widgets/plots are involved.

[GillesDuvert]

Hi @pjb7687 , I've tested this with the PR#882 . We can get rid of Appveyor, especially since it fails now consistently.
GitHub actions are fast indeed.
For the sake of the planet, would it be possible to get only ONE quick compilation to test the compilation passes (may need several restarts after code editing), then get a quick artifact to rapidly test the added features of bug correction are working. Probably on the debug+all features version (without MPI).
This perhaps, by passing a special flag to the cmake.yml?
Then, a different way to finally create all the artifacts as done now.

[GillesDuvert]

BTW, PR#882 is about replacing the X11 and WIN drivers by wxWidgets by default, and have all the widgets working exactly as IDL.
It's near-perfect under linux, a few bizarre things under Windows (refresh of graphics, size of some text widgets). Difficult for me to test why those discrepancies with unix, as wxWidgets is meant to be 'transparent". I'll have to leave theses petty details to windows developers...

[pjb7687]

Hi @pjb7687 , I've tested this with the PR#882 . We can get rid of Appveyor, especially since it fails now consistently.
GitHub actions are fast indeed.
For the sake of the planet, would it be possible to get only ONE quick compilation to test the compilation passes (may need several restarts after code editing), then get a quick artifact to rapidly test the added features of bug correction are working. Probably on the debug+all features version (without MPI).
This perhaps, by passing a special flag to the cmake.yml?
Then, a different way to finally create all the artifacts as done now.

Fully agree, makes total sense. For the environment, from now on PRs only trigger x86_64 debug full build on Github Actions.

[pjb7687]

BTW, PR#882 is about replacing the X11 and WIN drivers by wxWidgets by default, and have all the widgets working exactly as IDL.
It's near-perfect under linux, a few bizarre things under Windows (refresh of graphics, size of some text widgets). Difficult for me to test why those discrepancies with unix, as wxWidgets is meant to be 'transparent". I'll have to leave theses petty details to windows developers...

I remember we have already discussed this in Paris several years ago... This will be fantastic, then all plotting functions have one single codebase, therefore, it should be much easier to manage.

[GillesDuvert]

looks good now with wxWidgets. Plots are IMHO perfect. widgets have a font problem under windows, so labels etc are wrong -- certainly easy to fix. They are also slow, but this will disappear in the final release.
I've mentioned somewhere the artifacts should not carry all the plplot directory, only colormaps, it's a bit more complicated. But it definitely works without the subdirectories 'example', 'ss', and 'tcl'.