<dngrsspookyvisio>
Otherwise I'd take a look at how e.g. the cmsis-dsp crate handles things (that's arm, not xtensa, for xtensa specifics you could ask the #esp-rs room)
<dngrsspookyvisio>
I'd personally rather extend the rust port since there's going to be a lot of friction back and forth when it's a proper driver and not just a fancy math library like cmsis
<diondokter[m]>
You can use type aliases to have to type less text, or use generics to only use the trait implementations
<fat_hamster[m]>
Thanks I'll give that a go!
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time! I'm still gluing together the agenda but it'l be https://hackmd.io/l00L7w3BRo-mHBZD7KBcJQ, please add anything you'd like to discuss or announce, and we'll start in a few mins :)
<adamgreig[m]>
if I'm really lucky I'll finish shoving food into my mouth first too, heh
<adamgreig[m]>
OK, let's begin! looks like it might be quite a quiet one today
<adamgreig[m]>
only brief announcement is that embedded-io 0.5 (https://crates.io/crates/embedded-io) has been released by the HAL team who now maintain it
<adamgreig[m]>
and it contains the traits we expect to encourage people to use for serial ports rather than anything in embedded-hal
<dirbaio[m]>
o/
<adamgreig[m]>
I think that's it for announcements from me though, anyone have anything else?
<dirbaio[m]>
also, embedded-nal-async and embassy already updated to the embedded-io traits
<dirbaio[m]>
* the embedded-io 0.5 traits
<dirbaio[m]>
if anyone's using either embedded-hal Serial traits, or embedded-io 0.4, we'd appreciate if you try updating and give feedback
<dirbaio[m]>
since embedded-hal 1.0 will not have serial traits at all
<adamgreig[m]>
talking of embedded-hal 1.0, then, what's the next steps look like? I think it's basically down to documentation and getting a little more wide-spread experience with the traits now?
<dirbaio[m]>
not many hals/drivers have updated to the 1.0 alphas :S
<adamgreig[m]>
so skip a beta?
<dirbaio[m]>
not sure what good a beta would do
<dirbaio[m]>
at this point we don't have any known design flaws in the traits, so what we have now is what we'd release
<adamgreig[m]>
yea, I assume at this point most people who haven't implemented it are waiting for it to be more settled, so 1.0-rc1 seems like a nice step
<dirbaio[m]>
unless someone comes up with compelling arguments to change something
<dirbaio[m]>
yeah
<dirbaio[m]>
hopefully rc1 instead of alphaX signals to people that no more breaking changes are expected
<dirbaio[m]>
so more people try upgrading
<diondokter[m]>
dirbaio[m]: Indeed, used one of the alpha spi crates and for a moment the client was a bit anxious
<diondokter[m]>
s/crates/traits/
<dirbaio[m]>
clients 😭
<eldruin[m]>
I have done some underlying work in rust-spidev and rust-i2cdev and there is already a PR to upgrade l-e-h to alpha.11
<eldruin[m]>
serialport-rs could add support for embedded-io and then use embedded-hal-compat for reverse compatibility
<eldruin[m]>
I wanted to bring up translations of the books again
<adamgreig[m]>
ah shoot sorry diondokter, I'll do that now before the c-s stuff
<diondokter[m]>
adamgreig[m]: I'm not in hurry to merge it
<diondokter[m]>
* not in a hurry to
<adamgreig[m]>
I am :P
<diondokter[m]>
But it would be nice at some point
<adamgreig[m]>
eldruin: go ahead
<eldruin[m]>
alright so there is inteerst in translating the embedded book and the discovery bopk
<eldruin[m]>
s/bopk/book/
<eldruin[m]>
there is a chinese translation of one of them where the author seems keen in keeping it up to date, so might be a candidate for a gettext approach
<eldruin[m]>
there is also a guy waiting to start a korean translation of the discovery book
<eldruin[m]>
(I may have mixed both books, sorry I cannot tell the bunch of issues appart)
<eldruin[m]>
anyway
<eldruin[m]>
as a PoC we agreed on adding a spanish translation first
<eldruin[m]>
and I have a 50% one
<eldruin[m]>
it proved very simple to do by uploading the file to transifex
<eldruin[m]>
so the question would be how do we want to proceed with that
<eldruin[m]>
wait for 100% spanish and then merge?
<adamgreig[m]>
if anything a mostly-complete spanish is probably more representative :P
<eldruin[m]>
I am not sure what that means :)
<adamgreig[m]>
you'd get to also try doing a few updates and see how it looks when parts aren't fully translated and all that
<adamgreig[m]>
I guess what I mean is the concept is proved before you get to 100% completion on translation probably, but it would be nice for it to be enough translated to be useful to a spanish speaker
<adamgreig[m]>
if your experience is that "this is a nice way to translate it" and the team's overall is "this is a nice way to manage/store/publish translations", I think we'd be in a good place to merge it
<adamgreig[m]>
it sounded like we also still need to decide if we even include the translation files in the main repo or what, though
<eldruin[m]>
ok thanks
<eldruin[m]>
I think it is already useful as it is, and I hope to complete it at some point or add collaborators (the nice thing about transifex)
<eldruin[m]>
transifex is very nice way to translate because you can collaborate with several people extremely easily
<eldruin[m]>
however, what I have not tested is how the merge works once there have been changes to the original source
<eldruin[m]>
I think the po files need to be included in the repo
<eldruin[m]>
the original one could be left out though
<eldruin[m]>
but again, I am not sure how an older po file can be applied to a more current book version
<eldruin[m]>
read I have not looked into it, might be a solved problem, maybe not, maybe needs work on the CI front
<eldruin[m]>
* read: I
<eldruin[m]>
however, I have used chatgpt for the translation and it has been mostly flawless, so it bears the question, do we need to manually translate books anymore?
<adamgreig[m]>
I guess google translate has been available the whole time too but people still seem keen on making translations
<eldruin[m]>
I see it is a nice onboarding way but I am not sure the whole translation and its management actually makes sense
<adamgreig[m]>
interesting
<eldruin[m]>
sorry, not trying to be a downer
<eldruin[m]>
:)
<adamgreig[m]>
no, it's a good point!
<eldruin[m]>
there is obviously people willing to do it/ think it would be helpful to do it
<adamgreig[m]>
my only similar experience is trying to read chinese datasheets and certainly for that sort of technical text machine translation is fine (or anyway good enough)
<adamgreig[m]>
I haven't had to read technical documentation like the embedded books in another language so dunno what the feeling is really
<adamgreig[m]>
if people are willing to translate and we can make it easy for them that seems worthwhile, and certainly no problem linking to translations etc
<adamgreig[m]>
but maybe you think it's not worth spending much wg team time handling translations?
<eldruin[m]>
I used chatgpt 3.5 and it only chose some different technical words but only in one snippet there was an actual logical error
<eldruin[m]>
* logical error in the translation
<eldruin[m]>
adamgreig[m]: I am not sure
<eldruin[m]>
it is also not possible right now to just feed the whole book to chatgpt, like with google translate
<eldruin[m]>
also, I do not know how the quality of google translate is
<eldruin[m]>
even that might be enough
<eldruin[m]>
I am just wondering
<eldruin[m]>
what do you guys think?
starblue has joined #rust-embedded
<adamgreig[m]>
what specifically do you think we do? I don't feel like I have much of a say in whether the translations are more useful than machine translation, but I'm open to saying "we'll just link to translations" or "here are po files but handle the rest in your own repo" or whatever
<eldruin[m]>
no idea :) we can leave AI out of the question and just continue with the current approach
<eldruin[m]>
IIUC, we could have just a language switching widget in the books
<eldruin[m]>
separate repos for the translations get pretty outdated
<eldruin[m]>
even the original ones get outdated quickly
<eldruin[m]>
we could then generate the pot file and upload it to transifex and then create translations for different languages, where users can collaborate easily, then sometimes get the translated po files and update them in the book repos
<eldruin[m]>
but we definitely need a streamlined process in CI, it would get unmanageable otherwise
<eldruin[m]>
I do not have the time to really do the whole thing, that's why I start to wonder
<adamgreig[m]>
yea, it's one thing for volunteers to handle the translations, but I guess then managing this part of it is a bunch of work
<adamgreig[m]>
a hardship of this channel being primarily english-speaking is we don't hear much from the people who presumably would most want the translations, so it's hard to judge how beneficial they are
<adamgreig[m]>
even if the CI made ongoing management easy, setting that up to work properly in the first place sounds like a fair chunk of work
<eldruin[m]>
indeed
<adamgreig[m]>
let's continue discussing it next week then, I think it's worth working out what we want the policy to be but it doesn't seem like anyone has super strong views either way
<adamgreig[m]>
shame as that might make decisions easier :p but i suppose in the absence of anyone volunteering to manage the translations it's probably best to keep it to something people do separately and we can link to
<adamgreig[m]>
anyway, that's all for today, thanks everyone!