Closed MarkWieczorek closed 5 years ago
The failures are due to the generated images being slightly different to the baseline images, which guards us from possible regressions/changes to libraries upstream. It's not a major major issue, but I thought I've fixed them recently in #352, though I was using Linux and maybe there's some differences between Linux and MacOS? There have been some recent updates to the earth relief grids and you might need to clear the cache using gmt clear data
, which should hopefully fix the grdimage
errors (but it'll take some time to redownload the files).
I see you're using GMT6.0.0, but could you try to find out what version of pygmt
you've installed? Do something like pip list | grep pygmt
, or git describe
in the pygmt local repository.
I tried gmt clear data
and reran the tests, but got the same result.
I'm working off of the last commit on master.
Could you try to find a good example of the failed images under /var/folders
, and post the expected, actual and difference PNG files? Just want to see what's the actual difference.
Here is test_grdimage-failed-diff.png
And here is test_basemap-failed-diff.png
Ok, we're hitting similar test failures in #293 after merging in changes from master, but I don't quite understand why the other PRs which are up to date with master don't have failed tests? Edit: I've looked more closely at the errors and they were are totally unrelated. I can't quite make sense of the grdimage difference though, as it seems that only the landmasses are affected... Do you have a non-grid example? E.g. from text
.
test_text_input_single_filename-failed-diff
Could you post your ghostscript version using ? This reminds me of a similar issue back in #315. Mine is ghostscript --version
9.27, Edit: Sorry, maybe use conda list | grep ghostscript
instead, which gives me 9.22.
> which gs
/usr/local/bin/gs
> ls -al /usr/local/bin/gs
lrwxr-xr-x 1 lunokhod admin 33 Nov 4 13:05 /usr/local/bin/gs@ -> ../Cellar/ghostscript/9.50/bin/gs
> gs --version
9.50
Version 9.50 aye, right, I think they're trying to get it to work upstream at https://github.com/GenericMappingTools/gmt/pull/1993...
GenericMappingTools/gmt#1993 is trying to include the gs 9.50 into the macOS bundle. It's not related to this issue.
FYI, the earth_relief_xxy grids have all changed (except 01s, 03s) so if your originals predate the new releases then new original plots are needed.
@MarkWieczorek, could you try again with pygmt.test(figures=False)
? If it all passes then I think we'll close this issue as the image differences are rather minor and can actually be safely ignored.
Ignoring the figures, I now only get one failure:
======================================================== FAILURES ========================================================
_____________________________________________ test_call_module_error_message _____________________________________________
def test_call_module_error_message():
"Check is the GMT error message was captured."
with clib.Session() as lib:
try:
> lib.call_module("info", "bogus-data.bla")
pygmt/tests/test_clib.py:210:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <pygmt.clib.session.Session object at 0x15807b390>, module = 'info', args = 'bogus-data.bla'
def call_module(self, module, args):
"""
Call a GMT module with the given arguments.
Makes a call to ``GMT_Call_Module`` from the C API using mode
``GMT_MODULE_CMD`` (arguments passed as a single string).
Most interactions with the C API are done through this function.
Parameters
----------
module : str
Module name (``'coast'``, ``'basemap'``, etc).
args : str
String with the command line arguments that will be passed to the
module (for example, ``'-R0/5/0/10 -JM'``).
Raises
------
GMTCLibError
If the returned status code of the function is non-zero.
"""
c_call_module = self.get_libgmt_func(
"GMT_Call_Module",
argtypes=[ctp.c_void_p, ctp.c_char_p, ctp.c_int, ctp.c_void_p],
restype=ctp.c_int,
)
mode = self["GMT_MODULE_CMD"]
status = c_call_module(
self.session_pointer, module.encode(), mode, args.encode()
)
if status != 0:
raise GMTCLibError(
"Module '{}' failed with status code {}:\n{}".format(
> module, status, self._error_message
)
)
E pygmt.exceptions.GMTCLibError: Module 'info' failed with status code 71:
E pygmt-session [ERROR]: GMT_COMPATIBILITY: Expects values from 6 to 6; reset to 6.
E gmtinfo [ERROR]: Error for input file: No such file (bogus-data.bla)
pygmt/clib/session.py:489: GMTCLibError
During handling of the above exception, another exception occurred:
def test_call_module_error_message():
"Check is the GMT error message was captured."
with clib.Session() as lib:
try:
lib.call_module("info", "bogus-data.bla")
except GMTCLibError as error:
msg = "\n".join(
[
"Module 'info' failed with status code 71:",
"gmtinfo [ERROR]: Error for input file: No such file (bogus-data.bla)",
]
)
> assert str(error) == msg
E assert "Module 'info...gus-data.bla)" == "Module 'info...gus-data.bla)"
E Module 'info' failed with status code 71:
E - pygmt-session [ERROR]: GMT_COMPATIBILITY: Expects values from 6 to 6; reset to 6.
E gmtinfo [ERROR]: Error for input file: No such file (bogus-data.bla)
pygmt/tests/test_clib.py:218: AssertionError
-------------------------------------------------- Captured stderr call --------------------------------------------------
pygmt-session [ERROR]: GMT_COMPATIBILITY: Expects values from 6 to 6; reset to 6.
gmtinfo [ERROR]: Error for input file: No such file (bogus-data.bla)
Ok, I think that's related with your issue at #365
If I set GMT_COMPATIBILITY = 6
in the .gmt/gmt.conf
file, this does indeed pass.
Happy to close this then?
Sure, but perhaps you should make figures=False
the default until this is worked out.
gmt version = 6.0.0 platform = macOS
In attempting to run the
pygmt.test()
suite, numerous tests fail. Here is the entire output.