Anyone able to guide me on why I can be getting this error on my tests?
The #[tokio::test] macro requires rt or rt-multi-thread.
It is more a Rust question than a Solana one, but I have been following the examples (and I am learning Rust), so just felt here would be a good place to post hte quesiton.
I have solana-program-test = "1.6.2".
Hrm... I'm not sure then. Maybe try adding https://github.com/solana-labs/solana/blob/364af3a3e01e258694e16aed57838d36305aa9c3/program-test/Cargo.toml#L25 explicitly?
Under dev-dependencies though.
You cargo.toml should have tokio and tokio-test
tokio = { version = "1.24.2", features = ["full"] }
tokio-test ="0.4.2"
This will install the optional rt-multi-thread dependency.
Related
How do I enable crate features per-platform in a Cargo.toml configuration? I've tried two methods, neither of which work.
Method 1:
[target.'cfg(windows)'.dependencies.rusqlite]
version = "0.19.0"
features = ["bundled"]
[target.'cfg(unix)'.dependencies.rusqlite] # same behavior with cfg(not(windows))
version = "0.19.0"
Method 2:
[target.'cfg(windows)'.dependencies]
rusqlite = { version = "0.19.0", features = ["bundled"] }
[target.'cfg(unix)'.dependencies]
rusqlite = { version = "0.19.0" }
I'm trying to use the 'bundled' feature only on Windows platforms, but regardless of which way I try to configure cargo it always adds the 'bundled' feature when building on an Ubuntu system.
Is it possible to enable features only on one platform?
Is it possible to enable features only on one platform?
No, it is not possible, due to Cargo issue #1197.
See also:
How can I optionally pass rustc flags depending on a Cargo feature?
I'm currently trying to learn Rust (for embedded specifically), coming from a background of C for embedded systems and Python.
So far, I've been reading Rust Programming Language and Rust for Embedded, and read a few blog posts on the web.
I want my first project to be a simple "Blinky", where an LED blinks infinitely. I've got an STM32L152CDISCOVERY board with an STM32L152 chip in it (basically same as STM32L151), which is a Cortex M3.
Instead of implementing everything from scratch, I want to leverage existing crates and HALs. I've found two that seem promising: stm32l1 and stm32l1xx-hal. I've tried to read the documentation of each of them and also part of the source code, but I still can't figure out how to use them correctly.
Got a few questions about Rust and about the crates:
I see that stm32l1xx-hal has a dependency on stm32l1. Do I need to add both as a dependency in my Cargo.toml file? Or will that create problems related to ownership?
Is this the correct way to add them? Why is the second one added like that [dependencies.stm32l1]?
[dependencies]
cortex-m-rt = "0.6.10"
cortex-m-semihosting = "0.3.3"
panic-halt = "0.2.0"
stm32l1xx-hal = "0.1.0"
[dependencies.stm32l1]
version = "0.13.0"
features = ["stm32l151", "rt"]
To blink the LD4 (which is connected to PB4 PB6), I've got to enable the GPIOB in the RCC register and then configure the pin to push pull output. By inspecting the documentation of stm32l1xx-hal, I see that there is an RCC struct and a PB4 struct with the method into_push_pull_output. However, I still don't understand how to use these structs: how to import them or how to get an instance of them.
I've seen code examples for stm32l1 but not for stm32l1xx-hal. I know that I can do this:
use stm32l1::{stm32l151};
...
let p = stm32l151::Peripherals::take().unwrap();
p.RCC.ahbenr.modify(|_,w| w.gpiopben().set_bit());
But in the source code of stm32l1xx-hal I see that the RCC part is already done in impl GpioExt for $GPIOX, but I don't know how to get to this "Parts" functionality.
Any help that points me in the right direction is appreciated.
I got some help from a Discord community. The answers were (modified a bit by me):
stm32l1xx-hal already depends on stm32l1 as seen here. There's no need to import it twice. It is enough to add to Cargo.toml:
[dependencies.stm32l1xx-hal]
version = "0.1.0"
default-features = false
features = ["stm32l151", "rt"]
Note that the default-features = false is optional, but without it the compiler was giving me an error.
The syntaxes are equivalent, but as I said above, I only need to add the HAL one. You can add curly braces {} in the first style to add the options, such as:
stm32l1xx-hal = { version = "0.1.0", features = ["stm32l151", "rt"]}
The right code for doing the blinky (which was on PB6, not PB4, sigh) was:
#![no_main]
#![no_std]
use panic_halt as _;
use cortex_m_rt::entry;
use stm32l1xx_hal::delay::Delay;
use stm32l1xx_hal::gpio::GpioExt;
use stm32l1xx_hal::hal::digital::v2::OutputPin;
use stm32l1xx_hal::rcc::{Config, RccExt};
use stm32l1xx_hal::stm32::Peripherals;
use stm32l1xx_hal::stm32::CorePeripherals;
use stm32l1xx_hal::time::MicroSeconds;
#[entry]
fn main() -> ! {
let p = Peripherals::take().unwrap();
let cp = CorePeripherals::take().unwrap();
// Get LED pin PB6
let gpiob = p.GPIOB.split();
let mut led = gpiob.pb6.into_push_pull_output();
// Set up a delay
let rcc = p.RCC.freeze(Config::default());
let mut delay = Delay::new(cp.SYST, rcc.clocks);
loop {
// Turn LED On
led.set_high().unwrap();
delay.delay(MicroSeconds(1_000_000_u32));
// Turn LED Off
led.set_low().unwrap();
delay.delay(MicroSeconds(1_000_000_u32));
}
}
For me, the key was to understand that the split method can be called from the Peripherals because stm32l1xx-hal implemented split for a struct defined in stm32l1. In other words, the HAL crate is not only defining new structs, but also extending functionality for existing structs. I need to wrap my head around trait design patterns.
I am following the vulkano tutorial to open a window and create a surface with vulkano-win.
Most of the tutorial is dated which I've been able to work around so far, however I have not been able to find a solution.
Currently, I get the following error when I call let window = WindowBuilder::new().build_vk_surface(&events_loop, instance.clone())
error[E0599]: no method named build_vk_surface found for struct winit::window::WindowBuilder in the current scope
I have checked the library and the version of vulkano_win and it seems to properly extend WindowBuilder I will post the dependencies in my Cargo.toml below.
[dependencies]
vulkano = "0.19"
vulkano-shaders = "0.18"
winit = "0.23"
vulkano-win = "0.19"
image = "0.23"
P.S. - There is a legacy instance of this happening on a much older (2 yr ago) version of vulkano_win here. I suspect this has been fixed since I have checked the dependencies for the vulkano_win library and they use the newer and restructured versions of winit there:
https://github.com/vulkano-rs/vulkano/issues/943
I have checked the library and the version of vulkano_win and it seems to properly extend WindowBuilder I will post the dependencies in my Cargo.toml below.
In short, you are correct. The issue is that the VkSurfaceBuild trait, is implemented for winit 0.22's WindowBuilder and not winit 0.23's WindowBuilder.
So to fix your issue, you need to update your Cargo.toml to use winit 0.22 instead of 0.23.
Example:
[dependencies]
vulkano = "0.19"
vulkano-shaders = "0.19"
vulkano-win = "0.19"
winit = "0.22"
Additionally, your confusion might come from browsing the repository.
In the repository both vulkano-win and the examples uses winit 0.23.
However, remember that the current state of the repository is not necessarily the same as what was released in 0.19.
On GitHub you can select tags, and view the commit that was the 0.19 release.
If you then look at vulkano-win and the examples, you'll see that they all use winit 0.22.
If you really want to use winit 0.23. Then you could depend directly on the repository. Like this:
[dependencies]
vulkano = { git = "https://github.com/vulkano-rs/vulkano" }
vulkano-win = { git = "https://github.com/vulkano-rs/vulkano" }
vulkano-shaders = { git = "https://github.com/vulkano-rs/vulkano" }
winit = "0.23"
However, one breaking change to the repository, could potentially ruin your build. So use with caution.
How were able to determine how that trait was implemented over the 0.22 WindowBuilder but not the 0.23 WindowBuilder?
Unsure if there's a fancy way of doing it, but an easy way is to just go to VkSurfaceBuild on docs.rs, then at "Implementations on Foreign Types" if you click on WindowBuilder, then it redirects to winit 0.22.2 docs.
Alternatively, you can also check your Cargo.lock. If you attempt to use winit 0.23, then your Cargo.lock would contain two winit versions:
[[package]]
name = "winit"
version = "0.22.2"
...
[[package]]
name = "winit"
version = "0.23.0"
...
If you then peek at vulkano-win then you can see it uses winit 0.22.2:
[[package]]
name = "vulkano-win"
version = "0.19.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0b9a02addddf5532396d11dbb822f77d87ca17a00c918e4c8a0a125d6c207e2b"
dependencies = [
"cocoa 0.20.2",
"metal",
"objc",
"vulkano",
"winit 0.22.2",
]
If there's no duplicate versions, it would just say "winit" like the others.
I'm trying to use rand::SmallRng. The documentation says
This PRNG is feature-gated: to use, you must enable the crate feature small_rng.
I've been searching and can't figure out how to enable "crate features". The phrase isn't even used anywhere in the Rust docs. This is the best I could come up with:
[features]
default = ["small_rng"]
But I get:
Feature default includes small_rng which is neither a dependency nor another feature
Are the docs wrong, or is there something I'm missing?
Specify the dependencies in Cargo.toml like so:
[dependencies]
rand = { version = "0.7.2", features = ["small_rng"] }
Alternatively:
[dependencies.rand]
version = "0.7.2"
features = ["small_rng"]
Both work.
I've got a toy project that's using the Amethyst game engine. I'm trying to write my own System for collecting user input, similar to the FlyMovementSystem and ArcBallRotationSystem they have implemented here.
It appears the right way to go about collecting mouse movements is via an EventChannel<Event>, where Event comes from the winit crate, which Amethyst depends on, but does not re-export.
What's the "right" way to reference the same winit::Event that Amethyst does?
Should I add winit to my Cargo.toml file? If so, what is the recommended way to specify the version? (Is there some keyword I can use instead of a specific version number, to allow me to "inherit" the dependency from Amethyst?)
Is referencing sub-dependencies actually discouraged? If so, what should I be doing instead?
There is currently no great solution to this problem. The best workaround is to add a direct dependency on the same version of the transitive dependency:
[dependencies]
foo = "0.1"
bar = "0.2" # `foo` depends on bar 0.2 and we need to keep these in sync
You can use tools like cargo tree to manually identify the versions needed by foo and keep your Cargo.toml up to date. I highly recommend adding a comment specifying why you've picked a specific version.
If the crate is very difficult to use without also using the underlying dependency alongside it, I'd also encourage you to file an issue with the parent crate to request that they re-export what is needed. A good example of this is the Tokio crate, which re-exports large chunks of the futures crate.
Similar to your idea, I proposed having a way to use the same version as a dependency. Instead, the Cargo team opted to add the distinction of public and private dependencies. While this will be a better solution from an engineering point of view, very little progress has been made on the implementation of it.
See also:
Why is a trait not implemented for a type that clearly has it implemented?
I'm leaving #Shepmaster's answer as the accepted one, as it answers the general question I was going for. But thanks to a gentle push from #trentcl, in case anyone found this question specifically for its relation to Amethyst, here's what I ended up doing.
Don't try to get the winit::Events at all.
When you attach an InputBundle<AX, AC> to your GameData, it sets up an InputSystem<AX, AC>, which re-publishes winit::Events in the form of InputEvent<AC>.
It does this by setting up an EventChannel<InputEvent<AC>> as a Resource, which you can access via the Read type in the ECS system. EventChannels and their usage are explained in the Amethyst Book.
I've since switched to a different approach for handling my user input, but here's roughly what it looked like (note: Amethyst a little after v0.10.0):
pub struct MouseMovementSystem {
reader: Option<ReaderId<InputEvent<()>>>, // AC = ()
}
impl<'s> System<'s> for MouseMovementSystem {
type SystemData = (
Read<'s, EventChannel<InputEvent<()>>>,
/* and others */
}
fn run(&mut self, (events, /* and others */): Self::SystemData) {
let foo = events.read(self.reader.as_mut().unwrap())
.yadda_yadda(/* ... */); // event processing logic
do_stuff(foo);
}
fn setup(&mut self, res: &mut Resources) {
use amethyst::core::specs::prelude::SystemData;
Self::SystemData::setup(res);
self.reader = Some(res.fetch_mut::<EventChannel<InputEvent<()>>>().register_reader());
}
}