Figure.wiggle: Reorder input parameter to 'data, x, y, z'

[seisman]

Description of proposed changes

Address #1479

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If adding new functionality, add an example to docstrings or tutorials.

Slash Commands

You can write slash commands (/command) in the first line of a comment to perform
specific operations. Supported slash commands are:

• /format: automatically format and lint the code
• /test-gmt-dev: run full tests on the latest GMT development version

[seisman]

Any idea why the docs CI suddenly fails?

[weiji14]

Any idea why the docs CI suddenly fails?

I don't understand either. The scheduled docs build worked 10 hours ago at https://github.com/GenericMappingTools/pygmt/actions/runs/1292065680. The logs for this PR show this error message:

ValueError: did not find a match in any of xarray's currently installed IO backends ['netcdf4', 'scipy']. Consider explicitly selecting one of the installed engines via the ``engine`` parameter, or installing additional IO dependencies, see:
http://xarray.pydata.org/en/stable/getting-started-guide/installing.html
http://xarray.pydata.org/en/stable/user-guide/io.html

but I thought we fixed that in #1264, and xarray is still on v0.19.0. Also, the Vercel docs build have failed too, so it's not a GitHub Actions thing.

I did try to build the docs locally though, and it seems that I can't download the remote data files somehow. E.g. doing gmt which -Vi @tut_bathy.nc gives me:

gmt [INFORMATION]: Downloading file http://oceania.generic-mapping-tools.org/gmt_data_server.txt ...
gmt [INFORMATION]: Unable to download file http://oceania.generic-mapping-tools.org/gmt_data_server.txt
gmt [INFORMATION]: Libcurl Error: HTTP response code said error
gmt [INFORMATION]: Failed to get remote file http://oceania.generic-mapping-tools.org/gmt_data_server.txt
gmt [INFORMATION]: Unable to obtain remote information file gmt_data_server.txt
gmt [INFORMATION]: Remote download is currently deactivated
gmt [INFORMATION]: Failed to get remote file http://oceania.generic-mapping-tools.org/gmt_hash_server.txt
gmt [INFORMATION]: Unable to obtain remote hash table gmt_hash_server.txt
gmtwhich [INFORMATION]: Writing Data Table to Standard Output stream
gmtwhich [ERROR]: File tut_bathy.nc not found!

But accessing the link at http://oceania.generic-mapping-tools.org/gmt_data_server.txt works in a browser (though it redirects to https). So not sure what's breaking 😕

[maxrjones]

Any idea why the docs CI suddenly fails?

I don't understand either. The scheduled docs build worked 10 hours ago at https://github.com/GenericMappingTools/pygmt/actions/runs/1292065680. The logs for this PR show this error message:

ValueError: did not find a match in any of xarray's currently installed IO backends ['netcdf4', 'scipy']. Consider explicitly selecting one of the installed engines via the ``engine`` parameter, or installing additional IO dependencies, see:
http://xarray.pydata.org/en/stable/getting-started-guide/installing.html
http://xarray.pydata.org/en/stable/user-guide/io.html

but I thought we fixed that in #1264, and xarray is still on v0.19.0. Also, the Vercel docs build have failed too, so it's not a GitHub Actions thing.

I did try to build the docs locally though, and it seems that I can't download the remote data files somehow. E.g. doing gmt which -Vi @tut_bathy.nc gives me:

gmt [INFORMATION]: Downloading file http://oceania.generic-mapping-tools.org/gmt_data_server.txt ...
gmt [INFORMATION]: Unable to download file http://oceania.generic-mapping-tools.org/gmt_data_server.txt
gmt [INFORMATION]: Libcurl Error: HTTP response code said error
gmt [INFORMATION]: Failed to get remote file http://oceania.generic-mapping-tools.org/gmt_data_server.txt
gmt [INFORMATION]: Unable to obtain remote information file gmt_data_server.txt
gmt [INFORMATION]: Remote download is currently deactivated
gmt [INFORMATION]: Failed to get remote file http://oceania.generic-mapping-tools.org/gmt_hash_server.txt
gmt [INFORMATION]: Unable to obtain remote hash table gmt_hash_server.txt
gmtwhich [INFORMATION]: Writing Data Table to Standard Output stream
gmtwhich [ERROR]: File tut_bathy.nc not found!

But accessing the link at http://oceania.generic-mapping-tools.org/gmt_data_server.txt works in a browser (though it redirects to https). So not sure what's breaking 😕

I had the same problems starting a few hours ago with the remote files. Download was successful with CLI curl. Pinging @PaulWessel as an FYI that others are encountering the same issue.

[PaulWessel]

I tried and got the same error. But notice that this works

curl -k -L https://oceania.generic-mapping-tools.org/gmt_data_server.txt

while this doesn't:

curl -k -L http://oceania.generic-mapping-tools.org/gmt_data_server.txt

So since we have not changed gmt from using http in these calls, presumably something happened to the server. Note I updated CentOS today which installed lots of updated libs etc, including gmt6.2. How would that break anything? It clearly works via https but not http. Perhaps SOEST RCF did something ?

[weiji14]

Well, manually switching to https worked, i.e. with GMT_DATA_SERVER=https://oceania.generic-mapping-tools.org gmt which -Vi -Gc @tut_bathy.nc:

gmt [INFORMATION]: Downloading file https://oceania.generic-mapping-tools.org/gmt_data_server.txt ...
gmt [INFORMATION]: Downloading file https://oceania.generic-mapping-tools.org/gmt_hash_server.txt ...
gmtwhich [INFORMATION]: Writing Data Table to Standard Output stream
gmtwhich [INFORMATION]:   -> Download cache file: @tut_bathy.nc
gmtwhich [INFORMATION]: Downloading file https://oceania.generic-mapping-tools.org/cache/tut_bathy.nc ...
/home/username/.gmt/cache/tut_bathy.nc

[seisman]

@GenericMappingTools/pygmt-maintainers Please give this PR high priority, as other issues (e.g., #1546, #1547, #1479) are waiting for the fix in this PR.