Attempting to run on device fails with there is no reactor running, must be called from the context of a Tokio 1.x runtime

[paulyoung]

For me, cargo playdate run --device fails with the following. Using --simulator works as expected.

    Finished staticlib of hello-world
        Skip drop hello-world, can't build rlib targeting playdate
   Packaging (single-target) hello-world (source: staticlib, target: bin)
    Finished hello-world v0.1.0 (/Users/py/projects/paulyoung/hello-world)
     Running hello-world on the '/dev/cu.usbmodemXXXX_XXXXXXXX'
thread 'main' panicked at /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/tokio-serial-5.4.4/src/lib.rs:78:24:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[paulyoung]

With RUST_BACKTRACE=1:

    Finished staticlib of hello-world
        Skip drop hello-world, can't build rlib targeting playdate
   Packaging (single-target) hello-world (source: staticlib, target: bin)
    Finished hello-world v0.1.0 (/Users/py/projects/paulyoung/hello-world)
     Running hello-world on the '/dev/cu.usbmodemXXXX_XXXXXXXX'
thread 'main' panicked at /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/tokio-serial-5.4.4/src/lib.rs:78:24:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: tokio::runtime::scheduler::Handle::current::panic_cold_display
   3: tokio::runtime::scheduler::Handle::current
   4: tokio_serial::SerialStream::open
   5: <serialport::SerialPortBuilder as tokio_serial::SerialPortBuilderExt>::open_native_async
   6: playdate_device::serial::Interface::open
   7: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
   8: <futures_util::future::try_future::try_flatten::TryFlatten<Fut,<Fut as futures_core::future::TryFuture>::Ok> as core::future::future::Future>::poll
   9: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  10: <futures_util::future::try_future::try_flatten::TryFlatten<Fut,<Fut as futures_core::future::TryFuture>::Ok> as core::future::future::Future>::poll
  11: <futures_util::stream::futures_unordered::FuturesUnordered<Fut> as futures_core::stream::Stream>::poll_next
  12: <futures_util::stream::stream::flatten::Flatten<St,<St as futures_core::stream::Stream>::Item> as futures_core::stream::Stream>::poll_next
  13: <futures_util::stream::stream::flatten::Flatten<St,<St as futures_core::stream::Stream>::Item> as futures_core::stream::Stream>::poll_next
  14: futures_lite::future::block_on
  15: cargo_playdate::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[paulyoung]

Not sure if this is still an issue but can't get this far after upgrading Rust to the nightly version used in this repository: #315

[boozook]

That's strange because it was in betas only. It should be fixed in 0.4.x, actual is 0.4.3.
What version did you use? I'll try to reproduce.

As a proof, in that screencast made two days ago, was used the latest version at that moment.

[boozook]

Okay, I reproduced the problem. Thanks for the report! 👍

[boozook]

@paulyoung,
While I'm fixing it, I suggest workaround is to remove specifying a specific device port (path).
Specifying the serial port path forces the program to use exactly the serial interface. The bug is its incorrect use in that context.
So, I recommend removing the serial port path specification. If you have many Playdate devices connected at the same time, you should instead specify the serial number of a specific device. Or not if there is only one device. This way cargo-playdate will find the device itself and use a different interface (usb bulk) if possible, and as fallback serial port will used.

Examples:

• --device
• --device=PDU1-XXXX... or --device=PDU1_XXXX...
• PLAYDATE_SERIAL_DEVICE="PDU1..." cargo playdate run ... --device

[boozook]

@paulyoung, I hope this is fixed in cargo-playdate v0.4.4 (crates.io), I can't reproduce it anymore. Thank you so much!

[paulyoung]

The workaround appears to work, and after upgrading cargo-playdate I don't see the error either. Thanks for the fix!

I plan on getting a second device but for now I'll remove the serial device environment variable.

I still can't get past the device showing "sharing DATA segment as USB drive" and "Eject disk to reboot" though. My terminal says Running hello-world on a device and eventually exits but the device stays the same.

I should file a separate issue about that but I'm still using the nightly release from 2023-12-28 because of #315, so will wait until I can get past that first.

[boozook]

I still can't get past the device showing "sharing DATA segment as USB drive" and "Eject disk to reboot" though. My terminal says Running hello-world on a device and eventually exits but the device stays the same.

I suppose user have no permissions to eject device, as well as for unmount.
Just for experiment, could you try with sudo?
Later after other bugs I'll take it and will do proper errors and reporting for that part and then add fallback method "unmount with pdutil that in the SDK" if it can it, I'm not sure 🤔. But anyway that shouldn't help with permissions.

FYI: There is also another option to eject with perms, but it totally unsafe and risky - send scsi command to reset. It can break data and entire file system. It probably safe with os-level lock, but I don't want to do so risk thing now.

[paulyoung]

Perhaps worth noting that when inspecting the device while mounted and also after manually ejecting the device, the game isn't installed.

[paulyoung]

Here's what happens if I try with sudo:

sudo cargo playdate run --device    
Password:
thread 'main' panicked at /private/tmp/nix-build-cargo-package-0.0.1.drv-0/source/support/build/src/assets/resolver.rs:87:34:
Env var "PLAYDATE_SDK_PATH" not found

Perhaps a bug related to #279 or #290?

[paulyoung]

It looks like using sudo within a Nix dev shell is confusing things.

[paulyoung]

I needed to use sudo -E cargo playdate run --device to not reset the environment, but that didn't help.

I still can't get past the device showing "sharing DATA segment as USB drive" and "Eject disk to reboot" though. My terminal says Running hello-world on a device and eventually exits but the device stays the same.

I'll open an issue.