Rinf bindings are not ready - Sending consecutive signals

[johnwaltonvi]

Hi, i'm trying send 2 signals to dart from rust and getting "Rinf bindings are not ready".
Seems to only be doing this on wasm32 though as it worked on a windows' .exe test.
I tried adding a time delay but same result.
Any ideas on why this is happening or a solution? Thanks!

(Terminal)

DMWriteRequestOutputSignal: 
Rinf bindings are not ready
ChartProviderOutputSignal: 
Rinf bindings are not ready

while let Some(signal_pack) = receiver.recv().await {
    // ........

    // SEND TO DISK MANAGER
    let mut data_write_request_output_signal: DMWriteRequestOutputSignal = exchange.into();
    data_write_request_output_signal.candles = candles.clone();
    data_write_request_output_signal.send_signal_to_dart();

    interval.tick().await;

    // SEND TO CHART PROVIDER
    ChartProviderOutputSignal {
        candles: candles.clone(),
    }
    .send_signal_to_dart();
}

[temeddix]

Hi, I've been trying to reproduce the error, but had no luck. The example app in our repository was working fine on the web without using timers. I've also tried clearing build artifacts and compiling the app again.

The main cause of your problem is Dart's initialization function is not doing its work properly.

To dive deeper into this problem, I want to ask you a few questions:

• Are you writing flutter run with necessary web header arguments, as you can get from the rinf server command?
• Do your pubspec.yaml and native/hub/Cargo.toml both use Rinf 8.0.0?
• Are you compiling your app in debug mode, or release mode?

[temeddix]

Or possibly, could you clone the example app(flutter_package/example) in this repo and test if it runs correctly?

[johnwaltonvi]

Looks like the issue was due to sending an i64 value in the message in wasm32. Changed it to a i32 and it works fine :)

To answer the above, yes and yes and debug mode.

Just wanted to say I really appreciate the work you did in version 8. Love this project.

[temeddix]

Thank you for your kind words :)

A few months ago, there was an issue with large types (i64, i128, etc.) when using the wasm32-unknown-unknown compilation target in rustc, the Rust compiler. It seemed to have been fixed, but it might now be manifesting in a different way—although I haven't investigated further.