11:53 <JamesMunns[m]> For the WG members here, we've been asked for feedback from the `build-std` team about their current RFC: https://github.com/rust-embedded/wg/discussions/863#discussioncomment-14139904. Since it's a decently long document, I'm sharing it here before the meeting if you have a chance to read it before.

11:58 <JamesMunns[m]> In particular, I'm gunna tag @mabez, @thejpster, @dirbaio, @Amit, and @Kaspar, since you all might have unique views on build-std (if not, no worries, that's just like my opinion :D)

12:00 <JamesMunns[m]> (for clarity, that's an attempt to ping the esp32, ferrocene, embassy, tock-os, and ariel ecosystems, who might have different views on build-std)

12:01 <JamesMunns[m]> I've also pinged the oxide folks out of band (they don't hang here much), and if there are other communities I missed, please do ping them too.

12:03 <JamesMunns[m]> To note, we've been asked to filter/limit feedback through the WG at the moment, so please comment on the discussion rather than the RFC if you are not wg members, but please do gather any opinions so we can curate + forward on. There is and will be lots of feedback, so let's not overwhelm the build-std folks who are doing us a solid here getting this work pushed through :)

12:04 <JamesMunns[m]> Ah probably good measure to ping @korken89 for RTIC folks as well :)

12:20 <diondokter[m]> Hmmm... ok

12:20 <diondokter[m]> https://github.com/davidtwco/rfcs/blob/905684d3037f68c33f5bde1f3cca417eff848270/text/0000-build-std/3-motivation.md?plain=1#L94-L100

12:20 <diondokter[m]> optimize-for-size and panic-immediate-abort aren't part of this effort it seems (though they won't get blocked either)

12:23 <diondokter[m]> Does panic-immediate-abort do more than just setting panic=abort? Because it seems that's getting in as part of the compilation profile (same as the rest of the code you compile)

12:24 <chrysn[m]> Yeah, seems those we need are out of scope. Not necessarily bad; as the authors say, that'll make adding those in later easier b/c that'll work w/o being held up in the whole issue -- just makes reading all that for no immediately tangible benefit a bit harder to push through.

12:25 <diondokter[m]> chrysn[m]: Once stable, you'll still be able to compile core/alloc with opt-level s or z, which is still a win

12:26 <diondokter[m]> I don't think I've ever used a tier 3 target, but it's nice for non/barely supported platforms too

12:47 <Kaspar[m]> hmmm, removing the cli flag because [poor ux](https://github.com/davidtwco/rfcs/blob/905684d3037f68c33f5bde1f3cca417eff848270/text/0000-build-std/4-stage-1a.md?plain=1#L485-L487) doesn't vibe with me.

12:47 <Kaspar[m]> Ariel is building for a dozen rustc targets from a single workspace, only a subset of the builds for a subset of the targets need build-std. So the cargo configuration is not the right place to put this IMO. *probably* this can still be enabled via `CARGO_TARGET_<triple>_BUILD_STD=foo`, or `cargo --config target.<triple>.build-std=foo`, but then includes the redundant and awkward triple info.

12:47 <Kaspar[m]> IMO for embedded, the cargo configuration is too static.

12:48 <Kaspar[m]> * hmmm, removing the cli flag (`-Zbuild-std`) because [poor ux](https://github.com/davidtwco/rfcs/blob/905684d3037f68c33f5bde1f3cca417eff848270/text/0000-build-std/4-stage-1a.md?plain=1#L485-L487) doesn't vibe with me.

12:48 <Kaspar[m]> Ariel is building for a dozen rustc targets from a single workspace, only a subset of the builds for a subset of the targets need build-std. So the cargo configuration is not the right place to put this IMO. _probably_ this can still be enabled via `CARGO_TARGET_<triple>_BUILD_STD=foo`, or `cargo --config target.<triple>.build-std=foo`, but then includes the redundant and awkward triple info.

12:49 <JamesMunns[m]> (please do capture this feedback in the discussion, so we don't lose it in chat history)

16:28 <Noah[m]1> Can anyone here tell me where I best poll egress in smoltcp? do I just periodically do that? or when I get a packet? or when the phy sent the last packet?

16:30 <chrysn[m]> Playing around with trouble, is there any existing example of a peripheral taking both the GATT server and client role? I've found so far that I can indeed clone the Connection and thus build both a server and a GattClient, but so far characteristic_by_uuid does not terminate (the again I'm not 100% sure that the characteristic is successfully published at the central, so still in deep debugging).

17:11 <lulf[m]> chrysn: using both here https://github.com/lulf/watchful (but an older rev, so could be there's a regression)

17:17 <chrysn[m]> thanks! not surprised to see something time related here :-)