burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
braincode[m] has quit [Quit: Idle timeout reached: 172800s]
frostie314159[m] has joined #rust-embedded
<frostie314159[m]>
Hi, does anyone know, how I can create an array of static buffers using static_cell?
Mark[m] has quit [Quit: Idle timeout reached: 172800s]
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
Ehhh, the same way you create anything else with static_cell?
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
tamme[m] has quit [Quit: Idle timeout reached: 172800s]
notafbihoneypot[ has quit [Quit: Idle timeout reached: 172800s]
<frostie314159[m]>
I've been trying for sometime now, but it always fails to compile. What I'm trying to achieve is, I want to have an array, with a length controlled by a constant. That array should contain `&'static mut [u8; BUFFER_SIZE]`, i tried using `array::from_fn`, but it fails saying the static cell was already initialized.
<frostie314159[m]>
So the type of the array would be `[&'static mut [u8; BUFFER_SIZE]; BUFFER_COUNT]`
<DominicFischer[m>
You need to do that in two steps I think. One to create a static [[u8; BUFFER_SIZE]; BUFFER_COUNT] and another to split up the buffers. I don't recall a good way to do the seconds step, especially if you want to store that in a static as well.
rom4ik15 has joined #rust-embedded
Socke has quit [Ping timeout: 248 seconds]
ivche_ has joined #rust-embedded
AdamHorden has quit [Ping timeout: 252 seconds]
rom4ik1 has quit [Ping timeout: 252 seconds]
rom4ik15 is now known as rom4ik1
ivche has quit [Ping timeout: 248 seconds]
ivche_ is now known as ivche
ello_ has quit [Ping timeout: 252 seconds]
crabbedhaloablut has quit [Ping timeout: 272 seconds]
mathu has quit [Ping timeout: 272 seconds]
loki_val has joined #rust-embedded
AdamHorden has joined #rust-embedded
mathu has joined #rust-embedded
ello has joined #rust-embedded
Socke has joined #rust-embedded
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
takkaryx[m] has joined #rust-embedded
<takkaryx[m]>
probably a more generic rust question than an embedded specific one, but is there a way to define an environment variable for the build.rs script specifically in the cargo.toml? I'm trying to give it a relative path to a directory to search for some auto-generated code, but the [env] portion of the Cargo seems to only be present in the compilation of the crate, not in the build.rs script where I'm generating some code.
<takkaryx[m]>
* probably a more generic rust question than an embedded specific one, but is there a way to define an environment variable for the build.rs script specifically in the cargo.toml? I'm trying to give it a relative path to a directory to search for some auto-generated code, but the [env] portion of the Cargo seems to only be present in the compilation of the crate, not in the build.rs script where I'm generating some code. ATM
<takkaryx[m]>
I've given it an absolute path, but I'd prefer something a bit safer.
cr1901 has quit [Read error: Connection reset by peer]
PedroFerreira[m] has quit [Quit: Idle timeout reached: 172800s]
<Lumpio->
I'm fairly sure [env] should be available in build.rs, what are you using to read the variable?
<Lumpio->
ttps://doc.rust-lang.org/cargo/reference/config.html#env yeah even the docs give build scripts as the first example
<Lumpio->
+h
<takkaryx[m]>
std::env::var("ENV_VAR").unwrap
<Lumpio->
Ooooh you said cargo.toml
<takkaryx[m]>
hmmm, I printed out all the full env with a simple loop, and the [env] variable wasn't present....
<Lumpio->
It goes in cargo's config.toml not the crate cargo.toml
<Lumpio->
There is no [env] in cargo.toml
<takkaryx[m]>
wait, it has to be the config.toml....
<takkaryx[m]>
derp, ok, I read it all correctly, and just misread which toml to use XD
<takkaryx[m]>
thanks!
cr1901 has joined #rust-embedded
dngrs[m] has joined #rust-embedded
<dngrs[m]>
is there an easy way to figure out which dependency drags in std?
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
<dngrs[m]> "is there an easy way to figure..." <- cargo tree -e features -i <some top level dep>
<vollbrecht[m]>
that lets you view in reverse how feature come in
<dngrs[m]>
vollbrecht[m]: mmmhm this requires the dep using `std` (or similar) as feature name but yeah I guess that's close enough, thx
<vollbrecht[m]>
ah yeah with std in particular you are right that it can be problematic if a crate doesn't use such a feature explicitly