<cr1901>
jamesmunns: Yes, indeed, Merry Christmas to me. I'll take a look now and merge it
<cr1901>
jamesmunns: What is your comment about "serde has built-in impls for String" about? Was I trying to impl' Ser/De for String types?
<re_irc>
< (@jamesmunns:beeper.com)> No, I don't think so, but you need the String ser/de impls for deriving the types that contain them
<re_irc>
< (@jamesmunns:beeper.com)> They are only implemented for string with the alloc or std features active. I chose alloc because you also used alloc
<cr1901>
Oooooh, I see. It looks like I opted to serialize using &str, and manually convert
<cr1901>
I think my intent is eventually I want a solution w/o alloc, but the serializers don't have a way to squirrel away a reference to a &str in a higher stack frame
<cr1901>
Although a json serializer w/o alloc does exist, so it must be possible
<re_irc>
< (@jamesmunns:beeper.com)> I could make you a version that has borrowed strs?
<cr1901>
How do you implement the Deserialize trait?
<re_irc>
< (@jamesmunns:beeper.com)> Serde will already automatically borrow strs and byte slices
<re_irc>
< (@jamesmunns:beeper.com)> On-device, the slice will be static anyway, so you'll have &'static strs
<cr1901>
I already accepted your current PR... if it doesn't take long, would you be willing to change the InfoMem to use borrowed strs?
<cr1901>
(Make it a second PR)
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, gimme a couple minutes
<cr1901>
I used alloc because I didn't think I had a choice.
<cr1901>
>so you'll have &'static strs (well, it'll be &'static u8, but I imagine that serde "does the right thing" before returning a &'static str that aliases)
<cr1901>
(like checking that each u8 is valid
<re_irc>
< (@jamesmunns:beeper.com)> yep, it does the utf8 check
<cr1901>
jamesmunns: Ack thanks. How is managed different from CoW?
<re_irc>
< (@jamesmunns:beeper.com)> the "Owned" branch only exists when the "std" flag is active
<re_irc>
< (@jamesmunns:beeper.com)> so on-MCU, you're limited to ONLY the borrowed variant.
<cr1901>
Ahhh, interesting...
<re_irc>
< (@jamesmunns:beeper.com)> err, variant, not branch, but you get what I mean.
<cr1901>
yes indeed. Is managed not maintained, or just too heavy, or?
<cr1901>
(I'm going to accept, I'm just wondering :P)
<re_irc>
< (@jamesmunns:beeper.com)> it doesn't have a string variant, just T and [T]
<re_irc>
< (@jamesmunns:beeper.com)> would require more shenanigans.
<cr1901>
Ahhh, cool, works for me
<cr1901>
If I find a better crate, I'll use that instead of the homebrew solution
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, if you find one, lemme know
<cr1901>
Should the feature be called alloc? (String exists when alloc does, correct?)
<re_irc>
< (@jamesmunns:beeper.com)> you could have an alloc feature instead, you'd want to change the types a bit, but yeah
<cr1901>
I'll accept as-is and play around w/ it
<re_irc>
< (@jamesmunns:beeper.com)> lemme know, if you want to prefer alloc over std, or offer both/either I guess? that should work
<re_irc>
< (@jamesmunns:beeper.com)> k, cook
<cr1901>
not sure what types would need to be changed
<cr1901>
I think what I would want is "alloc" and "std" feature, where "std" automatically enables the "alloc" feature as well
<re_irc>
< (@jamesmunns:beeper.com)> all doable!
<re_irc>
< (@jamesmunns:beeper.com)> in "!std + alloc" you'd need to gate the extern crate alloc stuff
<re_irc>
< (@jamesmunns:beeper.com)> (and include "alloc::alloc::String" maybe?)
<cr1901>
IIRC, std::String is alloc::alloc::String under a different binding
<cr1901>
like how std::result::Result is core::result::Result
<re_irc>
< (@jamesmunns:beeper.com)> yeah, but when you are "!std" it's not in the prelude
<cr1901>
ahhhh
<re_irc>
< (@jamesmunns:beeper.com)> right now I'm just doing "impl From<...> for String" and stuff
<re_irc>
< (@jamesmunns:beeper.com)> Also, "InfoStr"'s impl of "Serialize" and "Deserialize" are good (IMO) examples of how you can "cheat" on ser/de impls, instead of doing the full visitor like you were previously.
<re_irc>
< (@jamesmunns:beeper.com)> you can "defer" to another type's impl of ser/de
<cr1901>
Maybe I shouldn't have lost my patience yesterday
<cr1901>
err, two days ago*
<re_irc>
< (@jamesmunns:beeper.com)> plus I think (?) this should all be portable if you wanted to use, say, JSON instead of postcard
<re_irc>
< (@jamesmunns:beeper.com)> (modulo some things, like I don't think I would handle escape chars in json, because I always try to take borrowed instead of owned)
<re_irc>
< (@jamesmunns:beeper.com)> There's more complicated cfg stuff I could do for that, but it's probably not necessary.
<cr1901>
I don't follow what you mean by escape chars in json. But also, supporting JSON for this is not in my plans.
<re_irc>
< (@jamesmunns:beeper.com)> you can't borrow the value in the case of something like "{ "example": "foo\"bar" }"
<re_irc>
< (@jamesmunns:beeper.com)> because the borrowed value WANTS to ignore the "\", but it can't. Normally, if you were deser'ing to a "Cow<str>", it would try to take the borrowed form, and if escaping is required, it would deser to a String instead and remove the escape characters.
<cr1901>
hrm, no you can't (unless you had a special escapedstring type that has Eq impl for other types :P
<re_irc>
< (@jamesmunns:beeper.com)> well, you also can't do "as_str()"
<cr1901>
ahhh
<re_irc>
< (@jamesmunns:beeper.com)> because there is no "contiguous slice" to borrow - you have to mutate the "\" away.
<re_irc>
< (@jamesmunns:beeper.com)> (and deser only takes a "&")
<re_irc>
< (@jamesmunns:beeper.com)> well, it's complicated. but yeah.
<re_irc>
< (@jamesmunns:beeper.com)> not relevant, probably :)
<cr1901>
JSON is weird to deserialize in environments w/o allocation for several reasons. This is just another
<cr1901>
(It's also uhh... not really amenable to "only keep part of the structure in memory at any given time")
<cr1901>
Well, at least libjsmn wasn't lol... if you tried deserializing an array, you couldn't peek into that array until the entire deser was done
<cr1901>
When I created a backup program for my old DOS machines, I wanted to read a config from JSON, but the "deser the entire array of file metadata" was too strict for me
<cr1901>
so I rolled my own format. And never wrote a restore tool :D
<re_irc>
< (@jamesmunns:beeper.com)> whew lol
<re_irc>
< (@jamesmunns:beeper.com)> Anyway, it's probably bedtime for me, hope those commits helped :)
<cr1901>
They did, and I got an alloc feature working
<cr1901>
thanks for the help, now the crate looks closer to how I intended
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
genpaku has quit [Ping timeout: 248 seconds]
genpaku has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<sigmaris>
Is there any feature in embedded-hal to slow down / delay in a write_read transaction?
<Lumpio->
sigmaris: Would write, delay, read work?
<Lumpio->
Or does it really require a repeated start with a delay
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
IlPalazzo-ojiisa has joined #rust-embedded
cr1901 has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
<cr1901>
jamesmunns: Suppose I have a struct InfoMem<T> {
<cr1901>
bar: u16,
<cr1901>
foo: u8,
<cr1901>
baz: u32
<cr1901>
extra: Option<T>,
<cr1901>
}; (example). If I know apriori the structure of a postcard-serialized data structure except for the T part 1/2
<cr1901>
is there a generic postcard-Node type like there is for JSON that I can deserialize into?
<cr1901>
while keeping the remaining layout?
<cr1901>
(the schema types don't impl Deserialize, so I can't attempt to deserialize "T" into them)
<re_irc>
< (@jamesmunns:beeper.com)> There's not really anything like serde json Value, what are you trying to achieve?
<cr1901>
jamesmunns: Hold that thought for tonight, my PCBs arrived, so I'm going to solder one
<re_irc>
< (@jamesmunns:beeper.com)> Nice! Looking forward to it :)
<re_irc>
< (@firefrommoonlight:matrix.org)> Hi! When using the Knurling stack (Probe-run, flip-link etc), what considerations are there for memory.x sections? Ie I noticed if I C+P from CubeIDe's Flash files, it can't find DTCMRAM; must be named RAM. So, this begs the question, for the other RAM sections, would I name them RAM_D1, or something else like SRAM1 (in H7xx hal example?) Thanks!
<re_irc>
Mostly relevant on STM32H7
<re_irc>
< (@firefrommoonlight:matrix.org)> I'm low proficiency on this stuff in general, ie how you use it beyond setting up a valid memory.x