search

tudat-team / tudatpy-feedstock

A conda-smithy repository for tudatpy.
https://tudat-team.github.io/tudatpy/
BSD 3-Clause "New" or "Revised" License
4 stars 3 forks source link

SPICE(FILEREADFAILED) - osx filepath management broken #1

Closed geoffreygarrett closed 4 years ago

geoffreygarrett commented 4 years ago

Attempting to load any kernels using default file path strings in tudatpy in osx will result in the following error:

================================================================================

Toolkit version: N0066

SPICE(FILEREADFAILED) -- An Attempt to Read a File Failed

Attempt to read from file '/Users/michaelgarrett/miniconda3/envs/test/resource'
failed. IOSTAT = -1.

A traceback follows.  The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> GETFAT

Oh, by the way:  The SPICELIB error handling actions are USER-TAILORABLE.  You
can choose whether the Toolkit aborts or continues when errors occur, which
error messages to output, and where to send the output.  Please read the ERROR
"Required Reading" file, or see the routines ERRACT, ERRDEV, and ERRPRT.

================================================================================

The path which is passed to spice is in actual fact get_resource_path(), without the final '/'.

Initial thoughts were that there was an issue with the path concatenation inside tudat-resources/include/tudat/resource.h and the way that filepaths are padded with placeholder in conda.

Further investigation:

>>> print(get_spice_kernel_path())
/Users/michaelgarrett/miniconda3/envs/test/resource/spice_kernels/

Which is correct, although when observing the raw string:

>>> get_spice_kernel_path()
'/Users/michaelgarrett/miniconda3/envs/test/resource\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00/spice_kernels/'

It seems that the size of the variable containing the path information needs to be defined beforehand (I assume using char types rather than std::string). The following was found when printing a filepath stored in tudatpy. A temporary fix is to redefine 'spice_interface.load_standard_kernels()with a higher level functionload_standard_spice_kernels()` which redefines the function in python, removing the escape sequence.

geoffreygarrett commented 4 years ago

https://gitter.im/conda-forge/conda-forge.github.io/archives/2019/01/22

Isuru Fernando @isuruf Jan 22 2019 21:59 UTC
Returning the prefix as a compile time constant std::string might lead to issues with prefix replacement

Chris Burr @chrisburr Jan 22 2019 22:07 UTC
Because it can end up having lots of null bytes in the middle of a string like /my/prefix/sysroot\x00\x00\x00/usr/include?
geoffreygarrett commented 4 years ago

This does not occur on linux, perhaps this is clang specific?

>>> get_spice_kernel_path()
'/home/ggarrett/miniconda3/envs/tenv1/resource/spice_kernels/'
>>> print(get_spice_kernel_path())
/home/ggarrett/miniconda3/envs/tenv1/resource/spice_kernels/
geoffreygarrett commented 4 years ago

Not an elegant fix, but I'm grateful the 1 hour builds on TravisCI in an attempt to fix this is over. (I do not have access to a mac at the moment). Setting up a VM on my desktop at home is definitely on the to-do list.

https://github.com/conda/conda-build/issues/1674

#define MYPREFIX "/some/path/with/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla"
std::string p_wrong = MYPREFIX;
std::string p_correct = std::string(MYPREFIX).c_str();

Issue is specifically with clangxx as mentioned by tovrstra here.