So I don't think N65 would have changed anything, the most recent build on Travis was about two weeks ago and the tests all passed. Otherwise the only thing I see that could be off is that in the 'testKernels.txt' file is that there is no space between the "=" and "(". So if that is indeed what the file looks like, then I think you will need to add a space in between those two characters.

Could you make sure that you have pulled the most recent commit of the master branch? If you haven't updated in a while it may be worth spending the time to uninstall and reinstall with the most recent commit. If you still have the same (or different) issue after that let me know.

Thanks!
-Andrew

from spiceypy.

Thanks for the quick feedback. The reason there's no space in =( is because I was trying to see if this fixed the issue. Normally the line looks like "KERNELS_TO_LOAD = (".

I'll clean out the installation and reinstall the latest commit.

thanks for your help.
J.

from spiceypy.

ok gotcha, let me know how it goes!

from spiceypy.

I take it that this worked for you, I will mark this issue as resolved in 24 hours if no response comes.

from spiceypy.

Not exactly. But I think the issue is neither with SpiceyPy nor N0065... I'm working in the IPython Notebook and I think I've observer a semi-systematic behaviour. If I perform any SPICE call that elicits an error the Kernel Pool is or appears to be wiped. So any subsequent calls to the pool fail. Furthermore, if I simply re-furnsh the kernels I get the original BADVARASSIGN error I posted above...

For now my work-around is (1) to pickle large dataframes and (2) restarted the Notebook Kernel (everything is a kernel these days) if I get an error... at least it encourages me to check my code before I run it.

BTW. I don't know if you work with the IPYTHON NOTEBOOK but the errors don't appear in the notebook, but in the terminal from which the notebook was started...

Cheers, thanks for the support.

from spiceypy.

I'm having exactly the same issue. Using IPython I cd into the kernel directory and do (from tutorials)

SpiceyPy.furnsh("naif0008.tls")

and I get

Toolkit version: N0065

SPICE(INVALIDNODE) --

HEAD was 0. TAIL was 0. Valid range is 1 to 26003.

A traceback follows. The name of the highest level module is first.
furnsh_c --> FURNSH --> ZZLDKER --> LDPOOL --> ZZRVAR --> ZZCLN --> LNKFSL

Toolkit version: N0065

SPICE(BADVARASSIGN) --

The first item following the assignment operator should be the value of a
variable or a left parenthesis '(' followed by a value for a variable. This is
not true on line 1 of the text kernel file 'naif0008.tls'.

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

from spiceypy.

Dang it - it started working - Just confirmed what @johnnycakes79 mentioned. If you do something wrong you have to restart python for it to correct itself

from spiceypy.

Sorry I haven't looked into this yet, it is either:
A). Something unique to SpiceyPy in that in compiling the shared library some behavior in the spice error handling changes.
B). A change in the N65 version of Spice.
C). In the __init__.py I set the error report mode to be "report" use erract. This may have some unexpected behavior from what is reported in the NAIF documentation. It will be a few days until I have the time to check, but it would be worth experimenting with the other available modes and try calling SpiceyPy.reset() as well to see if you can get the Spice error handling to reset.

Give option C a try, I am eager to hear how it goes!

from spiceypy.

@johnnycakes79 @RossWilliamson So I want to look into this one a bit, have either of you attempted calling SpiceyPy.reset() yet to see if that clears up the issue? Also if there is a easy way to trigger this issue let me know. Also I want to rename this issue to something that reflects what has been discussed above, any objections?

from spiceypy.

So I had a chance to play around with SpiceyPy this weekend with ipython, I have now observed this behavior and I am going to find time to look into it. I think it is just the nature of the default error reporting mode. The issues with furnsh appear to be from user error or unexpected issues with user provided paths.

from spiceypy.

Just back from vacation! Will try to get back on top of this and other SpiceyPy issues in the coming week or so.

from spiceypy.

So after looking into this a bit, this appears to be the correct behavior of the error report mode "report" which SpiceyPy sets in the init.py for the package. For more info on what modes exist please check out: "http://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/cspice/erract_c.html".

Now the next part gets a bit philosophical, if the user sets the mode "ignore" no spice errors are reported and subsequent calls using the kernel pool do function. But as this stops any errors being reported it will be up to the user to determine is something bad happened. The alternative mode is "return" which does still report errors however calls will fail silently until SpiceyPy.reset() is called.

I think that the ideal solution would still report errors, but without forcing the user to call reset. Or maybe that is fine?

from spiceypy.

Sorry for the heithaus, what I ended up doing was setting the default error action (via spice.erract) to "return" mode and I wrote a decorator that compensates for the lack of error checking in that mode. I ended up finding that changing the way spice error message are reported is tricky, and hard to do consistently across python versions and platforms. So instead I expanded the decorator I wrote to mimic the formatting of how spice prints out the error. Unfortunately at the moment the stack trace is not helpful as it just points to the line in the decorator the error was thrown, so I need to see if I can modify it to point to the wrapper function definition.

As this changes a lot of things, I will probably hold off merging this into the main branch for a while.

from spiceypy.