gregoirehenry / rust-spice

WOW! The complete NASA/NAIF Spice toolkit is actually usable on Rust

🌌🛰️

rust-spice's Issues

Cell API

Should #10 go in, i basically have no reason to continue working on my attempt at a wrapper (which is a good thing, i don't have the time lol).

One thing i have done, which is, i think, still on the roadmap for this repo, is work out a cell API.

Here is the link: https://github.com/mkalte666/naifspice-rs/blob/main/src/naifspice/src/cell.rs
EDIT: yes i am aware of the dumb compare_some func (instead of assert_eq!(whatever.pop(), Some(what_i_expect));), though i am not sure what my brain was doing when i wrote this. woops.

If you are interested, i can instead work this into a PR for this one. I think last time i worked on it i only had some nicety functionality left to do.

It is basically a re-implementation of the whole cell struct (which is stack-allocated with macros anyway) into pure rust. Hand filling the fields for each type instead of the c macro. What i, so far, did not manage to do was implement this copy-free for strings (Because of String vs CString). However, if i didn't miss anything, these are for one time copy actions into or out of the API anyway, so this might be a ok for a first attempt anyway.

What do you think? There are two other things i have done - feature flag for the chrono crate and some more advanced error handling around the one built into spice. The former would be easy to also just PR in here, while the latter might need significant rework, but would be also really really nice.

Have a good week!

Builder pattern for writer functions

Hello! I'm creating this issue in response to your recommendation on implementing a builder-like pattern to call spkw09. This probably applies to most writer modules as a lot of them take a similar number of arguments.

There are a number of good typestate crates available for deriving a builder pattern for structs, however, I couldn't find any for functions. Of course, implementing a simple builder would be trivial using some struct that holds arguments in Options that can be unwrapped when the function call is dispatched. However, this would mean that leaving an option unset and then trying to dispatch the call would result in a runtime error when it really should be a compile time error - especially for use cases like mine, where the call to spkw09 happens after a lot of number crunching that can take a few minutes to complete.

One possible solution would be introducing a new struct like SPKSegment9 that we can derive a typestate builder pattern for (using something like typed-builder). The API could look something like this:

let mut segment = SPKSegment9::builder()
    .body(399)
    .states(&mut states)    
    // ...
    .build();
spice::spkw09(handle, &mut segment);

With this approach, calling build() before setting all fields results in a compile time error. You could also write the same segment to multiple kernels without much of a hassle. The only downside in my eyes is the introduction of a new struct that doesn't exist in CSPICE.

I don't want to rush this with a subpar custom builder implementation since the solution should ideally be robust enough to be used for other future writer module wrappers. What do you think? I can throw together a PR for the above idea if you like.

Cheers, have a nice day!

Thread Safety

The c library is, as far as i know, not thread safe.
Thus using anything currently provided by this library (be it wrapped or not) also is not.
However, functions like spice::str2et can be called from different threads. That breaks stuff.

I am, for now, using this ugly ugly ugly thing to keep stuff from breaking for me:

https://github.com/mkalte666/satwatch/blob/2545d4d980104fe35527f14b8494385258a157b9/src/libspace/src/spice_lock.rs#L1

I think it would be nice to be forced to call something like spice::new() returning an object that provides the whole api.
Users can then wrap it in an arc to keep being able to put stuff into other threads, being forced to use proper synchronization.

It seems like a bit of a niche case, but at least making sure users don't end up with weird errors cause they don't know they cant access stuff from other threads seems like a good idea to me.
I might be missing something somewhere, so if thats the case, id be happy to be corrected and have that pointed out for me.

In any case, have a good weekend :D