Rinex crate does not build

[aaronrphillips]

I have attempted to build the crate (both natively and in a Docker container) using both published versions and the git repo:

• rinex = { git = "https://github.com/georust/rinex" }
• rinex = { version = "0.16" }

In all cases, I'm seeing errors like the following

error[E0308]: `?` operator has incompatible types
   --> /Users/USER/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rinex-0.15.6/src/header.rs:773:56
    |
773 |                           time_of_first_obs.time_scale = c
    |  ________________________________________________________^
774 | |                             .timescale()
775 | |                             .ok_or(ParsingError::TimescaleParsing(c.to_string()))?;
    | |__________________________________________________________________________________^ expected `hifitime::TimeScale`, found `hifitime::timescale::TimeScale`
    |
    = note: `?` operator cannot convert from `hifitime::timescale::TimeScale` to `hifitime::TimeScale`
    = note: `hifitime::timescale::TimeScale` and `hifitime::TimeScale` have similar names, but are actually distinct types
note: `hifitime::timescale::TimeScale` is defined in crate `hifitime`
   --> /Users/USER/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hifitime-4.0.0-alpha/src/timescale/mod.rs:87:1
    |
87  | pub enum TimeScale {
    | ^^^^^^^^^^^^^^^^^^
note: `hifitime::TimeScale` is defined in crate `hifitime`
   --> /Users/USER/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hifitime-3.9.0/src/timescale.rs:70:1
    |
70  | pub enum TimeScale {
    | ^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `hifitime` are being used?

It appears that gnss-rs is using hifitime v4.0.0-alpha, while rinex itself is using v3.9.0

[gwbres]

Hello,

the past 3 months of the nyx repo have caused our ecosystem to be broken and difficult to maintain. Things are too bad to explain everything without being lenghty, I will summarize the two scenarios that impact general users

Main branch

The main branch has been building fine since yesterday. So it all depends on when you tried it. Builds does not mean works fine, post processed navigation is broken until @ChristopherRabotin helps fixing the ANISE upgrade.

So, depending on what you're interested in, the main branch is not an option. It's impossible for us to give the main branch as a reasonnable option. Now............ one more problem being the following, that you discovered

Previous tags

I tried version = 0.16.1 (latest stable) and I confirm that it now also fails to build with the same error.

The problem comes from I pushed gnss-rs upgrade to nyx-alpha as v2.2.0. And we depend on gnss-rs=2.0 or 2.2 in a few places, so cargo picks up the -alpha version (latest) and it cause imcompatibilities.

This means most recents tags are now broken.

Unfortunately i don't have time nor enough motivation to work on all of this. GNSS is no part of my job (very far from it), and when it comes to GNSS i had many many topics to work on that were far from maintenance bs. To help people get a solution, I will downgrade to hifitime-3 so we can stabilize everything

[ChristopherRabotin]

All,

To provide a bit more context here, RINEX depends on Nyx, which itself depends on ANISE. Nyx is undergoing the final steps in a two-year long update. Testing of this monumental update requires a number of pre-releases. In so doing, I missed a use case that RINX had: it needs embedded planetary and ephemeris data so as to not require users to provide their own files for related computations.

There was an initial hotfix for this, but I hadn't tested it in a relevant environment. I'm currently working on another hot fix here: https://github.com/nyx-space/anise/pull/277 . I hope to get this merged soon, and with it, release version 0.4.1 of ANISE. I still need to determine which Nyx version I will release this update in, assuming that such a release is required too: I have a lot of work left for stable 2.0.0 of Nyx.

[gwbres]

Hello Chris, I think you don't understand the problem.

RINEX main builds fine since yesterday. We are aligned on Nyx + ANISE. We do not have the embedded planetary set, but that is subsidary. We simply use what you designed for 0.4.0 at first and we'll deal with that later.

RINEX main does not work as navigation is now broken, it comes from the construction of an ANISE compatible object (try_keplerian()), and it happens to fail in either RTK or RINEX:nav.

While on the other hand, we have just discovered that how I aligned gnss-rs to hifitime-4 has caused the previous tags to go rogue...

IMO, the best thing to do is to continue and fix our main branch quickly so it becomes the new standard. On my side, I may have to find a solution to fix "older" tags as well, so the crates.io content is "cleaner"

[ChristopherRabotin]

The try_keplerian fails because the frame does not specify a gravitational parameter https://docs.rs/anise/latest/src/anise/astro/orbit.rs.html#66 .

There are two ways to fix this:

1. Fetch the frame information from an Almanac using frame_from_uid](https://docs.rs/anise/latest/anise/almanac/struct.Almanac.html#method.frame_from_uid)
2. Use the build-in Earth J2000 constant frame (which does not have any gravitational parameter by default), and call with_mu_km3_s2 with 398_600.441_5, which is a common value for the gravitational parameter of the Earth (but not the one used in lunar missions usually).

[gwbres]

thank's so much for the clarification, I will look into this by the end of this week

[ChristopherRabotin]

Okay. I have fixed the embed ephem feature this morning, and will be releasing 0.4.1 this evening. I need to check that it's fully compatible in terms of dependencies as Nyx 2.0.0-rc and hifitime. I'm almost certain that it is.

[ChristopherRabotin]

ANISE 0.4.1 is now available: https://github.com/nyx-space/anise/releases/tag/0.4.1 . The publication on crates.io should happen automatically and shortly. I'll monitor to make sure that it's published.

[gwbres]

gnss_rtk and rinex now both point to anise 0.4.1, build still passes. I gave it a try and it did not change the navigation behavior. I need to look into what you previously said in detail

[gwbres]

@aaronrphillips, @ChristopherRabotin,

I'll close this, considering we now have options to build the libraries (main is to be prefered). As far as its behavior goes, it's a different topic we will tacle in the next few days. I'll see what I can propose for the recent tags

[ChristopherRabotin]

Is the behavior different? I'd be interested to learn more about what you are seeing. ANISE is a significant improvement in the models over what Nyx had before. ANISE has also been independently validated for a large number of calculations outside of the validation tests on github.

[aaronrphillips]

I'm not sure how you have the build set up for this, but when I use

rinex = { git = "https://github.com/georust/rinex", branch = "main" }

I'm still unable to get it to build in a project. I've got a project set up to debug this:

[package]
name = "bugcheck"
version = "0.1.0"
edition = "2021"

[dependencies]
rinex = { git = "https://github.com/georust/rinex", branch = "main" }

but this gives me:

63.89 error[E0412]: cannot find type `Station` in this scope
63.89     --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/1e35c5a/rinex/src/lib.rs:1708:31
63.89      |
63.89 1708 |                     &BTreeMap<Station, HashMap<Observable, DorisObservationData>>,
63.89      |                               ^^^^^^^ not found in this scope
63.89      |
63.89 help: consider importing this struct through its public re-export
63.89      |
63.89 53   + use crate::doris::Station;
63.89      |
63.89 
64.31 error[E0599]: no function or associated item named `max_dtoe` found for struct `ephemeris::Ephemeris` in the current scope
64.31    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/1e35c5a/rinex/src/navigation/ephemeris.rs:252:25
64.31     |
64.31 100 | pub struct Ephemeris {
64.31     | -------------------- function or associated item `max_dtoe` not found for this struct
64.31 ...
64.31 252 |         let dur = Self::max_dtoe(sv.constellation)?;
64.31     |                         ^^^^^^^^ function or associated item not found in `Ephemeris`
64.31 
64.38 error[E0599]: no method named `kepler` found for reference `&ephemeris::Ephemeris` in the current scope
64.38    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/1e35c5a/rinex/src/navigation/ephemeris.rs:278:31
64.38     |
64.38 278 |         let mut kepler = self.kepler()?;
64.38     |                               ^^^^^^ method not found in `&Ephemeris`
64.38 
64.48 error[E0599]: no method named `perturbations` found for reference `&ephemeris::Ephemeris` in the current scope
64.48    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/1e35c5a/rinex/src/navigation/ephemeris.rs:283:34
64.48     |
64.48 283 |         let perturbations = self.perturbations()?;
64.48     |                                  ^^^^^^^^^^^^^ method not found in `&Ephemeris`
64.48 
64.48 error[E0689]: can't call method `sqrt` on ambiguous numeric type `{float}`
64.48    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/1e35c5a/rinex/src/navigation/ephemeris.rs:305:45
64.48     |
64.48 305 |         let v_k = ((1.0 - kepler.e.powi(2)).sqrt() * sin_e_k).atan2(cos_e_k - kepler.e);
64.48     |                                             ^^^^
64.48 
64.49 error[E0689]: can't call method `sin_cos` on ambiguous numeric type `{float}`
64.49    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/1e35c5a/rinex/src/navigation/ephemeris.rs:309:54
64.49     |
64.49 309 |         let (sin2_phi_k, cos2_phi_k) = (2.0 * phi_k).sin_cos();
64.49     |                                                      ^^^^^^^
64.49 
64.49 error[E0689]: can't call method `sqrt` on ambiguous numeric type `{float}`
64.49    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/1e35c5a/rinex/src/navigation/ephemeris.rs:330:62
64.49     |
64.49 330 |         let fd_phi_k = ((1.0 + kepler.e) / (1.0 - kepler.e)).sqrt()
64.49     |                                                              ^^^^
64.49 
65.10 Some errors have detailed explanations: E0412, E0599, E0689.
65.10 For more information about an error, try `rustc --explain E0412`.
65.11 error: could not compile `rinex` (lib) due to 7 previous errors

(I've also tried rinex = 16.1 to see if new versions of nested dependencies would fix things, but got the same result as posted previously in this thread).

Any advice you can give that would help me get a version of this to compile (less concerned w/the behavioral issues at this point) would be much appreciated

[gwbres]

Hello,

it seems like some navigation code is called outside the navigation feature, we're currently working on this and wanted to improve the definition of this feature. I will give this a try tomorrow and will let you know. Although, this kind of error should be picked up by CI, because we build in default state as well

[gwbres]

(I've also tried rinex = 16.1 to see if new versions of nested dependencies would fix things, but got the same result as posted previously in this thread).

Yes, the previous tags are now faulty.

I have confirmed the errors by using your Cargo script. I don't have a clear explanation, it looks like a problem with Cargo workspace once again. The build works fine when running inside the tree, but it should not.

I'm thinking we should introduce a small example like what you did, not to be published, that would provide the ultimate test.

Right now, I'm simply pushing the few fixes that will permit the build, and we will have to either reconsider our CI scripts or introduce other tests. I initiated a discussion on discord.

[gwbres]

you can try the newer main branch

[gwbres]

The main branch has been stable for about 3 weeks now. I will publish a new tag today

[aaronrphillips]

I did a clean build (from main) this afternoon and it's still not compiling. I get the following:

28.20 error[E0433]: failed to resolve: use of undeclared crate or module `anise`
28.20  --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/70242aa/rinex/src/navigation/ephemeris.rs:9:5
28.20   |
28.20 9 | use anise::{
28.20   |     ^^^^^ use of undeclared crate or module `anise`
28.20 
28.20 error[E0432]: unresolved import `crate::prelude::Almanac`
28.20    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/70242aa/rinex/src/navigation/ephemeris.rs:5:15
28.20     |
28.20 5   |     prelude::{Almanac, Constellation, Duration, Epoch, TimeScale, SV},
28.20     |               ^^^^^^^ no `Almanac` in `prelude`
28.20     |
28.20 note: found an item that was configured out
28.20    --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/70242aa/rinex/src/lib.rs:102:19
28.20     |
28.20 102 |         prelude::{Almanac, Frame, Orbit},
28.20     |                   ^^^^^^^
28.20     = note: the item is gated behind the `nav` feature
28.20 
28.21 error: cannot find macro `html` in this scope
28.21   --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/70242aa/rinex/src/meteo/sensor.rs:31:9
28.21    |
28.21 31 |         html! {
28.21    |         ^^^^
28.21 
28.24 error[E0405]: cannot find trait `Render` in this scope
28.24   --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/70242aa/rinex/src/meteo/sensor.rs:29:6
28.24    |
28.24 29 | impl Render for Sensor {
28.24    |      ^^^^^^ not found in this scope
28.24 
28.25 error[E0412]: cannot find type `Markup` in this scope
28.25   --> /usr/local/cargo/git/checkouts/rinex-9f7137e49ca09e9f/70242aa/rinex/src/meteo/sensor.rs:30:25
28.25    |
28.25 30 |     fn render(&self) -> Markup {
28.25    |                         ^^^^^^ not found in this scope
28.25 
28.47 Some errors have detailed explanations: E0405, E0412, E0432, E0433.
28.47 For more information about an error, try `rustc --explain E0405`.
28.48 error: could not compile `rinex` (lib) due to 5 previous errors

[gwbres]

Hello, I'm afraid I'm unable to reproduce this problem. Are we sure that 9f7137e49ca09e9f is not more than 3 weeks old ? I juste retested the default and --all-feature build, both passed. What were the build options you used ?

[ChristopherRabotin]

@aaronrphillips , could you also run cargo update prior to the build? I believe that this refreshes your local cargo cache, and I've solved build issues in the past (with unrelated crates) just by running that command.

[gwbres]

could you also run cargo update prior to the build

Cargo update will save you if you're pointing to local folders or remote servers.

It looks like once again a cargo workspace issue. We can reproduce as long as we do not build inside the workspace. Because we have internal dependencies within the workspace, it looks like Cargo picks up the worst case scenario (in terms of dependencies) and applies it whatever happens. In our case, that would be a top level app (rinex-cli) which requires pretty much all-features everywhere. It really looks like it kills the ability to test "simpler" build options within the workspace.

As you can see, the errror he picked up are real errors. Yet, our CI and the way I use the toolkit (by running Cli which is built within the workspace), is not able to pick it up

I was about to say we should introduce the dummy app (simple #include), but once again it won't work, because it should not be within the workspace !

Right now, I will simply host a dummy test app in my own github, and regularly use it "to test". But it's impossible to maintain. I think we should talk to people who maintain cargo

[gwbres]

In summary, the problem comes from local internal dependencies within a Cargo workspace, stuff like "path = .../" to refer to local libs, in conjonction to crate features.

Adding a test-app within the workspace does not work, because you fall in that very same situation. Say test-app depends on github.com/rinex and not "../rinex", you can only have a unique source for an entire workspace, so we windup using github.com/rinex solely.

Right now I'm using an external tester, as you did and will fix the last 2 or 3 errors quickly. We definitely have to take a look at the cargo topics

[gwbres]

I created an external lib tester, it tests all the libraries and all crate features. I'm almost done it's running late here, I will conclude this tomorrow morning.

I will try to run the tester regularly, but I doubt this is a reasonnable workflow. We'll see what the people from cargo have to say. It's totally possible that we're missing something in our setup.

[gwbres]

All errors fixed with the PR i am about to merge right now.

In short: building within the workspace falsely passed, because it seems to resolve the highest level worst case dependencies. Unless, we're not using the workspace correctly ?

@ChristopherRabotin do you understand what's happening here ? the problem is to be able to test simpler or default build options, within a workspace like ours

Does that mean one is supposed to do cargo build -r -p $pkg ?

• No, I just tested, because you get a unique target folder (build products) as long as you're working at the workspace root position.

• the answer is cd $pkg && cargo build -r (build within dedicated $pkg), and that means we have to rework our CI scripts

Checkout how I reworked them if it helps

[ChristopherRabotin]

I don't yet understand the source of the issue, but I will look more closely at how the workspace is set up. I didn't know that one could cd into a workspace crate and build it such that it has its own target folder: ANISE is the only lib I maintain that uses workspaces, and I use the --workspace flag in the CI scripts to choose which crate to include or exclude.

[gwbres]

I didn't know that one could cd into a workspace crate

it can be useful

I use the --workspace flag

I was not aware of this flag. Our case is we have a -cli applicatio that uses local reference with "--all-features" requirement. I'm not even sure what the Workspace docs say about inclusion and exclusion would answer our need. The conclusion to our problem is simple, the CI script was not powerful enough or incorrectly set up. But it also comes from the fact that the workspace does not behave like I thought it would. Now it garantees sane build in all case scenarios. It's OK and very convient to have a global compilation at the root of the workspace, our tutorials are based on this for example