07:21 <re_irc> <@nihal.pasham:matrix.org> this just popped up in my reading list - https://hightec-rt.com/en/products/rust.. not sure if this is a recent development or its been out for a while. Does anyone happen to know more about their (new) compiler.

07:31 <re_irc> <@jamesmunns:beeper.com> Press release seems to be from two days ago: https://www.presseagentur.com/hightec/detail.php?pr_id=6561&lang=en

07:32 <re_irc> <@jamesmunns:beeper.com> > “The topic of Rust compatibility has been a frequent point of discussion in recent engagements with AURIX customers”, said Ralf Koedel, Vice President Microcontroller at Infineon

07:32 <re_irc> 👀👀👀

07:34 <re_irc> <@jamesmunns:beeper.com> > type-state API

07:34 <re_irc> made it into the marketing copy :D

10:15 <re_irc> <@halfbit:matrix.org> supporting tricore and aurix is really quite something

10:23 <re_irc> <@adamgreig:matrix.org> I look forward to the unreproducible library bug reports :p

10:23 <re_irc> <@adamgreig:matrix.org> Presumably it's rustc on top of their own llvm platform support and a custom target and some crates?

10:43 <re_irc> <@halfbit:matrix.org> most likely

15:59 <re_irc> <@jamesmunns:beeper.com> Even the proprietary armcc (or whatever it is called these days) is llvm based, seen other proprietary toolchains based on (sometimes archaic, not always tho) versions of llvm.

16:00 <re_irc> <@jamesmunns:beeper.com> In safety critical, KNOWN defects (like against older llvm versions) aren't that terrible of a problem, as long as you can detect when affected, or say things like "you must do a code review that checks you never do X while doing Y".

16:16 <re_irc> <@adamgreig:matrix.org> The llvm based one is called armclang, armcc is the version before they used llvm aiuu

16:16 <re_irc> <@adamgreig:matrix.org> * aiui

16:29 <re_irc> <@jamesmunns:beeper.com> I used a c89 armcc "back in the day" 😅

16:32 <re_irc> <@sensiblefolk:matrix.org> https://psion.agg.io/_matrix/media/r0/download/matrix.org/vgIluFHjzunSXItjHOaJgnJc/Voice%20message-%21BHcierreUuwCMxVqOf%3Amatrix.org.ogg

17:04 <re_irc> <@almindor:matrix.org> ah heh, didn't realize this is bridged to irc :D

17:22 <cr1901> jamesmunns: Your idea for Infomem to supply a generic slice/vec to represent the user-payload that needs to further be deserialized was a great one. 1/2

17:23 <cr1901> However, I think I'm stuck now and could use some help if you're up for it. Maybe postcard has something to help that I haven't seen yet

18:06 <cr1901> Nevermind... I figured it out

18:06 <cr1901> (yes, postcard does have something to help)

20:06 <re_irc> <@almindor:matrix.org> hmm is it possible to have a "&[&str]" out of a "Enum { Something(Struct { field1: String, field2: String ) }" without any allocation? e.g. I essentially want "&[&struct.field1, &struct.field2]" but it seems Rust needs the slice to live somewhere...

20:09 <re_irc> <@almindor:matrix.org> something like https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d10e7b6ba24994547f116f1f4edee858

20:10 <re_irc> <@almindor:matrix.org> seems like there really is no reason for allocations here given we're essentially just referencing the fields

20:10 <re_irc> <@k900:0upti.me> You need an allocation for the slice itself

20:10 <re_irc> <@k900:0upti.me> You can make it a "[&str; 2]"

20:10 <re_irc> <@k900:0upti.me> That way it'll be a known fixed size

20:11 <re_irc> <@almindor:matrix.org> hmm I guess that'll work, it's just coz of a simpleton interface I'm forced into that doesn't accept IntoIter or anything but just a &[]

20:14 <re_irc> <@jamesmunns:beeper.com> : Yep, &[&str] is what gets harder

20:14 <re_irc> <@jamesmunns:beeper.com> (a slice with an unknown number of references on it)

20:15 <re_irc> <@mbrossard:matrix.org> : armcc and armclang are also sometimes referred to respectively ARMC5 and ARMC6.

20:16 <re_irc> <@almindor:matrix.org> it's also a problem if there's change in size, e.g. imagine that enum having 2 variants with different count of fields

20:17 <re_irc> <@jamesmunns:beeper.com> Yup, the hard part is "where does the "[&str]" live if not in a Vec?

20:17 <re_irc> <@almindor:matrix.org> I guess I could unwrap "one layer up" and have the structs provide a function each

20:17 <re_irc> <@jamesmunns:beeper.com> (you can use a heapless vec for this

20:17 <re_irc> <@jamesmunns:beeper.com> * this)

20:30 <re_irc> <@jamesmunns:beeper.com> Yup, the hard part is "where does the "[&str]" live if not in a Vec"?

20:30 <re_irc> <@jamesmunns:beeper.com> Or - like you said, find some way for it not to be an unbounded slice of slices.

20:38 <cr1901> jamesmunns: I've done it! https://github.com/cr1901/postcard-infomem/blob/main/src/seq.rs#L174-L209 Sequential postcard processing with deferred user payload

20:40 <re_irc> <@jamesmunns:beeper.com> Noice!

21:18 <re_irc> <@jamesmunns:beeper.com> cr1901: re https://github.com/cr1901/postcard-infomem/blob/main/src/seq.rs#L49 - I can explain that if you'd like

21:19 <re_irc> <@jamesmunns:beeper.com> But basically, "take" is a clean steal of a buffer of a given lifetime (replacing it with &[]), where just subslicing would make a temporary lifetime shorter than 'a, which you can't put back in the 'a-shaped hole.

21:32 <re_irc> <@jamesmunns:beeper.com> (that's simplifying a bit, but can explain more with some examples if you/anyone wants. I've run into "this shaped problem" a couple times in postcard and bbqueue before, i had to have smarter people like simonsapin explain it to me the first time :D)