11:58 <Socke> is it somehow possible to do a match expression but with a &str as scrutinee and regex patterns as patterns? this would greatly simplify my code

11:59 <Socke> is there maybe a library that offers some kind of macro for this?

12:21 <JamesMunns[m]> if you have a no-std library for regex, you can do something like:... (full message at <https://catircservices.org/_irc/v1/media/download/AdJtjw-d8BBrUfEpPCdWnHPcirqbDWXQvQeTWQRboSKNq29_4nkXJJZaAbrkGUnxrRJzj8t4r4V8djpHFw8J5bC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9tcHR1T0VFZXlmUEFiVEpXbFlDVENCY3I>)

12:22 <JamesMunns[m]> I believe https://docs.rs/regex-automata/latest/regex_automata/ is no_std, and is what the main regex crate is built on top of, but I believe it has a much less convenient set of APIs.

12:24 <marmrt[m]> regex appears to have a std feature flag, so there should be some no_std support there

12:24 <JamesMunns[m]> marmrt[m]: it might still require alloc

12:25 <JamesMunns[m]> https://github.com/rust-lang/regex/blob/9870c06e6c772daaad7ab612faab29130753e41c/src/lib.rs#L1315-L1323

12:25 <JamesMunns[m]> extern crate alloc is unconditional there

16:04 <Socke> JamesMunns[m]: oh i'm not under no-std, so std would also be fine

16:18 <Lumpio[m]> Does that give you access to the match results though

16:19 <Lumpio[m]> As in, captures

16:20 <JamesMunns[m]> Lumpio[m]: Nope

16:20 <Lumpio[m]> You could probably write a macro_rules for it if you need to do it a lot I guess

16:21 <Lumpio[m]> Otherwise if let Some(c) = re1.captures(...) { ... } else if let ... would work I guess

16:21 <Lumpio[m]> s//`/, s/.../...`/

16:22 <Lumpio[m]> Could even potentially do it as a normal function if you don't mind a slightly odd syntax when calling it

16:22 <alex[m]1> I'm doing some research about doing CI on real hardware. I've seen some intriguing stuff in Embassy's teleprobe (like a test runner). I've scoured awesome-testing but I haven't found much- does anybody know any interesting public prior art on testing (e.g. running tests on a variety of boards, collecting results, etc.) or even something more reduced in scope (like mediating access to dev boards)?

17:01 <mameluc[m]> <alex[m]1> "I'm doing some research about..." <- looking for something similar myself. Bookmarked https://robotframework.org/ a while ago but I have no clue if it fits the bill

17:08 <Lumpio[m]> Robot Framework is probably one of the worst programming languages I've used. One space is an identifier characters, two or more is a separator? Who came up with this...

17:12 <i509vcb[m]> I'd certainly be interested in some sort of testing framework for the mspm0 hal

17:13 <i509vcb[m]> At this point at least I can reasonably acquire at least one of each model in some size

17:20 <jessebraham[m]> <alex[m]1> "I'm doing some research about..." <- We are using `probe-rs` and `embedded-test` for `esp-hal`, been working reasonably well for us for a number of months now.

17:23 <alex[m]1> jessebraham[m]: I'd somehow missed embedded-test, thanks!

17:49 <Kaspar[m]> <alex[m]1> "I'm doing some research about..." <- I built something for RIOT (a C rtos), http://ci.riot-os.org. It uses a fleet of pi and a homegrown job distribution. We'll upgrade this soon for rust based firmwares, probably re-using teleprobe. I'm super interested in collaborating!

19:15 <almindor[m]> what's the fastest nostd way of filling a (power of 2 sized) [u8] buffer from a small [u8; count <= 4] buffer by repetition? something like the .repeat call for Vec but just "filling up existing" instead

19:25 <GrantM11235[m]> as_chunks_unchecked_mut looks like it works pretty well, but it's not stable yet https://rust.godbolt.org/z/PbPPf8hWc

19:32 <JamesMunns[m]> uh maybe something like dest.iter_mut().zip(src.iter().repeat()).for_each(|(d, s)| *d = *s);?

19:33 <almindor[m]> I think this works: https://rust.godbolt.org/z/PePsav48h

19:34 <almindor[m]> at least, I don't think I can get closer than that on stable

19:35 <almindor[m]> note: for me I can do separate cases of data sizes to 4

19:37 <GrantM11235[m]> JamesMunns[m]: Lol, the optimizer really doesn't like that https://rust.godbolt.org/z/6G17asxKz

19:38 <JamesMunns[m]> https://rust.godbolt.org/z/7z16avsEK

19:38 <JamesMunns[m]> yeah, it works better with a fixed size

19:42 <JamesMunns[m]> JamesMunns[m]: This one looks a bit longer, but the other one just lowers to a memcpy, which is confusing because I don't see any loops, but I also don't know rv32 asm very well

20:13 <M9names[m]> If you want really fast, are okay with unsafe and can control creation of the buffer, I'd align(4) the buffer then align_to<u16> or align_to<u32> and use slice::fill

20:15 <almindor[m]> right, this works for size 2 and 4, for 3 I'd still need to fill by byte

20:16 <M9names[m]> Oh right, yep!

20:16 <almindor[m]> it seems though the difference is not big enough for the effort, even checked basic fill by byte seems to b eok

21:41 <demon1[m]> is it possible to use freertos-rust with cortex-m0? it doesn't build because std::sync is missing (m0 doesn't support atomics)

22:50 <thejpster[m]> M0+ supports atomic load and store but not CAS. So the core::sync module definitely exists. But why std::sync? That seems odd to me.