<yandrik[m]>
There might be ways to use Prompt Chaining here, especially on GPT-4. Basically do "Translate this", then "Here's the original, here's the translation, list all errors or possible inaccuracies", and then "Improve this translation"
<yandrik[m]>
I assume using the API is the best way here, as the full context length of the models can be used. GPT-3.5 16k might be good enough, and way cheaper actually. But haven't tried this out in that way yet
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has joined #rust-embedded
<JamesMunns[m]>
<thejpster[m]> "James Munns: i'm trying to..." <- if you're willing to change the underlying data type, I can't think of anything that would be terrible about it, but it's been a minute since I thought about that. There was some reason I didn't make it generic over T.
nex8192 has left #rust-embedded [Error from remote client]
<JamesMunns[m]>
<thejpster[m]> "Also, "ring_around_the_senders..." <- You can run tests in release mode, I think there's also a "short test" feature in bbqtest, it might be called something silly like "travisci" or something tho.
<dhylands[m]>
<phaseonx11[m]> "*sigh* that makes so much..." <- The biggest mistake I see people (and vendors) making is confusing the 7-bit i2c address with the 8-bit byte being sent out which contains the address.
<JamesMunns[m]>
JamesMunns[m]: It *might* have just been that I needed to initialize the buffer with values, and I do it by zeroing, so POD integers should be fine, but otherwise it'd have to be T: Default or something. Not 100%.
<thejpster[m]>
I tried, and it compiled and passed the tests, but didn't work on hardware. So I switched to a heapless Queue and that's fine.
<JamesMunns[m]>
thejpster[m]: That sounds worrying!
<thejpster[m]>
Also, it was a bit nasty creating `struct BBBufferGeneric` and `type BBBuffer<'a, N> = BBBufferGeneric<'a, N, u8>`
<JamesMunns[m]>
Which hardware?
<thejpster[m]>
RP2040
<thejpster[m]>
I may have just been releasing / committing wrong.
<thejpster[m]>
An API which just grabs one sample at a time is harder to get wrong.
<JamesMunns[m]>
thejpster[m]: Yup, if you can stand one in one out, heapless queue is great
<JamesMunns[m]>
I almost exclusively use bbqueue where I want DMA on at least one end, or I have a very large batch where a strided memcpy can warm up
<JamesMunns[m]>
thejpster[m]: If you have the code somewhere in a commit I can peek, but if you got it working already then nbd :)
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
corecode[m] has joined #rust-embedded
<corecode[m]>
oh meh, bindgen doesn't translate most #define constants, so most of my vendor peripheral pointers are missing
<corecode[m]>
i guess people in here do hardcore only-rust stuff?
emerent has quit [Ping timeout: 246 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
starblue has quit [Ping timeout: 260 seconds]
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
Yeah, the bot DMs you whenever your "irc clone" shows up, which drops off if you haven't sent a message in like a day or something
<dngrsspookyvisio>
bridges are noisy. I tend to block them.
<huegene[m]>
<dngrsspookyvisio> "huegene: if you want to look..." <- oh great thanx!
<dngrsspookyvisio>
The serial-ws bridge is pretty complex, you won't need that typically. Reasons are explained in the readme - if you're not targeting web, just open a serial port and tx rx
WSalmon has quit [Read error: Connection reset by peer]
WSalmon has joined #rust-embedded
<whitequark[cis]>
yeah, blocking the bridge bot is a perfectly fine solution
<whitequark[cis]>
<K900> "Does it just kick you out from..." <- let me check the logs, I think I might be hitting a connection limit
<K900>
I think it's working as intended
<whitequark[cis]>
the limit for idling is one week
<whitequark[cis]>
so if you dont say anything for a week you'll be disconnected
<whitequark[cis]>
a lot of these numbers is just an initial estimate I made since I didn't really know what the profile of the bridge would be
<K900>
OK I was definitely not idle for a week
starblue has joined #rust-embedded
<whitequark[cis]>
then it was something else yea
<whitequark[cis]>
sometimes connections just drop for no reason
<phaseonx11[m]>
<GrantM11235[m]> "That should work as long as..." <- When I use a struct literal to define the style (MonoTextStyle) gives me this error: "cannot create non-exhaustive struct using struct expression [E0639]"
<phaseonx11[m]>
When trying to use the builder like in my image, I get this error:
<phaseonx11[m]>
"cannot call non-const fn `embedded_graphics::mono_font::MonoTextStyleBuilder::<'_, embedded_graphics::pixelcolor::BinaryColor>::font` in constants [E0015] Note: calls in constants are limited to constant functions, tuple structs and tuple variants"
<phaseonx11[m]>
phaseonx11[m]: I feel like there's something silly I'm missing... :/
<JamesMunns[m]>
Worth asking in #rust-embedded-graphics:matrix.org too, btw
<JamesMunns[m]>
But I think if they marked it non-exhaustive AND their builder isn't const fns, then I don't think there's a way to do it.
<phaseonx11[m]>
JamesMunns[m]: Oh...well, that's fun XD
<phaseonx11[m]>
phaseonx11[m]: At least I know it isn't me. I kind of assumed it was. So I guess the only choice here, is to constantly rebuild the style on every call :/ sad times.
<phaseonx11[m]>
phaseonx11[m]: Thanks for your help though! Much appreciated.
<JamesMunns[m]>
I think building styles are typically pretty cheap, just putting some ints in a struct, but I totally get wanting to avoid unnecessary work.
<phaseonx11[m]>
JamesMunns[m]: I am just following my programmer instincts heh it just seemed odd to me that you'd have to keep rebuilding something as simple as a text style, but I'm not sure honestly :/
<phaseonx11[m]>
phaseonx11[m]: To be fair though, I've had a way easier experience doing embedded in rust than C or C++, I'm so glad this is something you can do with rust
<dngrsspookyvisio>
dngrsspookyvisio: and/or as mentioned there, if you don't need `mut`, try `core::cell::OnceCell`
<phaseonx11[m]>
dngrsspookyvisio: I'll look into this. This reminds me of lazy_static, which I've used in "regular" rust.
<phaseonx11[m]>
phaseonx11[m]: Thanks for the tip!
<phaseonx11[m]>
Rust embedded graphics said:
<phaseonx11[m]>
"While it's not the most elegant option, you can make a (obviously, non-const) function and build the style in that fn. Then, you call it where you would use the constant. I expect it to optimize away so it's I think only code aesthetics"
<phaseonx11[m]>
So I guess the expectation is that you'll have to gen it on every call.
<phaseonx11[m]>
(for anyone else that might run into this in the future)
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrsspookyvisio>
<phaseonx11[m]> "Thanks for the tip!" <- yw!
danielb[m] has joined #rust-embedded
<danielb[m]>
alternatively, we could fix embedded-graphics, maybe :)
<danielb[m]>
though that's not up to me
<danielb[m]>
* to me (also please don't take my word as gospel, I'm just a user, too ^^ )
jamwaffles[m] has joined #rust-embedded
<jamwaffles[m]>
On mobile so might be talking crap but I think we need proper const generics before it’s possible to fix, no?
<danielb[m]>
jamwaffles[m]: no, just `C: PixelColor` if I can believe my experiments
<danielb[m]>
then the compiler won't have problems deconstructing self in a const fn
<jamwaffles[m]>
Oh that’s an easy fix then! PRs accepted… I’m still burned out on e-g
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
<phaseonx11[m]>
If anyone could provide me some guidance, I wouldn't mind putting in the PR.