<re_irc> <@t​halesfragoso:m​atrix.org> It seems that the maintainer in case B has no life to be doing work on all PRs that get proposed
<re_irc> <@f​irefrommoonlight:m​atrix.org> Bottom line is the process should allow merging code tha timproves the library expeditiously. Regardless of the nature of the roadblocks, if they're there, you won't get contributions
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's me
<re_irc> <@f​irefrommoonlight:m​atrix.org> I will merge anything tha timproves the code
<re_irc> <@f​irefrommoonlight:m​atrix.org> And if I dont' like details, I'll fix them myself in a commit
<re_irc> <@t​halesfragoso:m​atrix.org> I don't saying you're wrong, but I'm also don't saying the others are wrong to want some standards
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm saying you shouldn't leave out key functionality, then not let PRs that add it stagnate
<re_irc> <@f​irefrommoonlight:m​atrix.org> A lot of this is for the reason you identified: Lack of maintainer time
<re_irc> <@f​irefrommoonlight:m​atrix.org> There's no easy fix, but my reasoning is in regards to the result, which is a broken process
<re_irc> <@t​halesfragoso:m​atrix.org> Well, standards are standards, should apply to all work, be it a typo fix or new feature
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm more concerned with the result, which is making better libs
<re_irc> <@f​irefrommoonlight:m​atrix.org> And I understand where you're coming from too, or projects can spin out of control, alienate users through breaking changes etc
<re_irc> <@f​irefrommoonlight:m​atrix.org> In the case I referred to, I fragmented the stm 32 HAL eco a bit because I couldn't get through the PR process
<re_irc> <@f​irefrommoonlight:m​atrix.org> Not ideal, but only option left
<re_irc> <@t​halesfragoso:m​atrix.org> And like I said before, I truly don't judge you
<re_irc> <@f​irefrommoonlight:m​atrix.org> We've been talking on different sides of this, but I think we fundamentally agree
<re_irc> <@t​halesfragoso:m​atrix.org> Sure
<re_irc> <@f​irefrommoonlight:m​atrix.org> We need the formal process you're referring to long-term
<re_irc> <@t​halesfragoso:m​atrix.org> I myself find it hard to know where to draw the line, decisions suck heh
Wetmelon has quit [Ping timeout: 265 seconds]
<re_irc> <@t​halesfragoso:m​atrix.org> But yeah, I will make them when needed
<re_irc> <@a​damgreig:m​atrix.org> bradleyharden: https://github.com/adamgreig/stm32ral
<re_irc> <@a​damgreig:m​atrix.org> on svd2rust 478, I think the result of our discussions was "the proposed change is good, but isn't enough by itself to be worth breaking so much existing code*, so let's wait on that one until we can significantly rearchitect svd2rust, which we need to do eventually due to the deref issue anyway"
<re_irc> <@a​damgreig:m​atrix.org> *I know semver and rust-embedded being young and fresh means we should also be able to break things fairly quickly, but it's still a balance, and every time we do it fractures the whole ecosystem until bits can get caught up
<re_irc> <@a​damgreig:m​atrix.org> projects are still using cortex-m v0.5, even our own discovery book
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: Would you like me to hold off on the RFC?
<re_irc> <@a​damgreig:m​atrix.org> and svd2rust updates take time to propagate to the PACs (stm32-rs still isn't updated to svd2rust 0.18/0.19, my fault but it major changes are required to stm32-rs because of how it now handles validating enums), which then take time to propagate to the HALs, etc etc
<re_irc> <@a​damgreig:m​atrix.org> hmm
<re_irc> <@a​damgreig:m​atrix.org> not sure
<re_irc> <@f​irefrommoonlight:m​atrix.org> This is a minor improvement and a breaking change (But I do agree it's a clear winner other than being breaking)
<re_irc> <@a​damgreig:m​atrix.org> we've had two breaking releases of svd2rust since that discussion
<re_irc> <@f​irefrommoonlight:m​atrix.org> So your call to hold off makes sense
<re_irc> <@a​damgreig:m​atrix.org> yea, I don't think anyone ended up disagreeing on it being a clear improvement aside from being breaking
<re_irc> <@a​damgreig:m​atrix.org> the only debate is over if/when the tradeoff makes sense
<re_irc> <@a​damgreig:m​atrix.org> a problem we have come to discover with our current voting/rfc process is that RFCs don't expire, they just wait until they have a qualified majority and then pass
<re_irc> <@a​damgreig:m​atrix.org> a bit like US constitutional amendments I guess :P
<re_irc> <@f​irefrommoonlight:m​atrix.org> How would you go about changing that? (Presumably to one with a ~1 week no/go deadline)
<re_irc> <@f​irefrommoonlight:m​atrix.org> (?)
<re_irc> <@a​damgreig:m​atrix.org> 202 years for the 27th right? hopefully we don't ever take that long
<re_irc> <@a​damgreig:m​atrix.org> 1 week is probably too short, since we'd at least want time to discuss it in a meeting or two, but 1 month is probably reasonable
<re_irc> <@f​irefrommoonlight:m​atrix.org> Sounds good
<re_irc> <@a​damgreig:m​atrix.org> it would be changed by an RFC to the working group https://github.com/rust-embedded/wg#rfcs
<re_irc> <@a​damgreig:m​atrix.org> brb a sec
<re_irc> <@a​damgreig:m​atrix.org> such an rfc sounds sensible to me, just so we can close out old rfcs (and always come back to them in the future if someone really wants to), but I don't know how much it would actually help solve any problems
<re_irc> <@a​damgreig:m​atrix.org> in other words, I don't think it would make more people vote on things or work on stuff
<re_irc> <@a​damgreig:m​atrix.org> firefrommoonlight: I'd like to see svd2rust eventually incorporate this change; I'd also like to see it change a lot as we rearchitecture it into something better, but maybe it's still worth taking the small improvement now until we actually get anywhere with the latter
<re_irc> <@a​damgreig:m​atrix.org> but maybe dirbaio's fork will provide some inspiration there
<re_irc> <@b​radleyharden:m​atrix.org> adamgreig thanks for teaching me something about my own government history:
<re_irc> <@b​radleyharden:m​atrix.org> > The proposed congressional pay amendment was largely forgotten until 1982, when Gregory Watson, a 19-year-old sophomore at the University of Texas at Austin, wrote a paper for a government class in which he claimed that the amendment could still be ratified. An unconvinced teaching assistant graded the...
<re_irc> ... paper poorly, motivating Watson to launch a nationwide campaign to complete its ratification.
<re_irc> <@a​damgreig:m​atrix.org> I love the "get revenge on teaching assistants giving poor grades" story. I always wondered about it every time I gave someone even a well deserved poor mark, lol
Wetmelon has joined #rust-embedded
radens has joined #rust-embedded
emerent has quit [Ping timeout: 268 seconds]
emerent has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <@b​radleyharden:m​atrix.org> lol
<re_irc> <@b​radleyharden:m​atrix.org> > In 2017, Elkins submitted a grade change form with Waite's signature and a grade change to A+.
<re_irc> <@b​radleyharden:m​atrix.org> Only took 35 years for that grade change
<re_irc> <@f​irefrommoonlight:m​atrix.org> Love it
rjframe has quit [Quit: Leaving]
Wetmelon has quit [Ping timeout: 268 seconds]
fabic has quit [Ping timeout: 258 seconds]
radens has quit [Quit: Connection closed for inactivity]
fabic has joined #rust-embedded
starblue3 has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
neceve has joined #rust-embedded
GenTooMan has quit [Remote host closed the connection]
<re_irc> <@b​arafael:m​atrix.org> The microbit discovery-style book works on ubit v1 or also on v2?
<re_irc> <@h​untc:m​atrix.org> barafael: Looks to me that the code is mostly written for v1
<re_irc> <@b​arafael:m​atrix.org> :D part of the reason was to get a book for more available hardware
<re_irc> <@h​untc:m​atrix.org> barafael: Just checking that you're referring to https://droogmic.github.io/microrust/index.html
<re_irc> <@r​obyoung:m​atrix.org> The microbit crate has only recently been updated to support the V2 boards. I don't think the book has been updated to reflect that yet.
<re_irc> <@b​arafael:m​atrix.org> Christopher Hunt: yes, that one :)
<re_irc> <@b​arafael:m​atrix.org> robyoung: great stuff!
<re_irc> <@r​obyoung:m​atrix.org> There is also this rewrite of the discover book but I'm not sure what state that is in. https://github.com/rust-embedded/discovery/tree/rewrite
crabbedhaloablut has quit [*.net *.split]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: FWIW Ito me it's not a clear improvement, just different. But I appreciate some people feeling otherwise, maybe I'm just too used to the current syntax to not mind it. 🤷‍♂️
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
phoenix has left #rust-embedded [WeeChat 3.0.1]
rjframe has joined #rust-embedded
<re_irc> <@e​vils.devils:m​atrix.org> i'm trying to get some keystrokes out of a blue pill when pressing a foot pedal wired to it
<re_irc> <@e​vils.devils:m​atrix.org> i know keyberon exists, seems like all the projects that use it use RTIC
<re_irc> <@e​vils.devils:m​atrix.org> does anyone know if that's a requirement?
<re_irc> <@e​vils.devils:m​atrix.org> (i don't need any fancy features, or even best response time, i'm even ok if i can only press one of the two pedals at a time)
<re_irc> <@e​vils.devils:m​atrix.org> i just want something as minimal and simple as possible as i'm really unfamiliar with Rust
GenTooMan has joined #rust-embedded
<re_irc> <@s​ympatron:m​atrix.org> adamgreig: In my opinion, situations like this automatically lead to a merge. That was what I was trying to say.
<re_irc> <@s​ympatron:m​atrix.org> I didn't have the full picture about svd2rust and I understand that it makes sense to bundle breaking changes.
<re_irc> <@s​ympatron:m​atrix.org> Maybe something like this could still be accepted if the things it's waiting on takes too long.
<re_irc> <@s​ympatron:m​atrix.org> (I am not talking about this particular case, but rather the general case)
<re_irc> <@a​damgreig:m​atrix.org> We do already have that sort of policy - the required threshold for approval is not unanimous approval but a qualified majority, starting at 50% of the relevant team (and no objections) and dropping to 33% after two weeks and then just any two approvals by people not whoever proposed the rfc (and no objections...
<re_irc> ... by team members)
<re_irc> <@a​damgreig:m​atrix.org> In other words a non controversial rfc is approved if two team members approve it and no one objects for a few weeks
<re_irc> <@a​damgreig:m​atrix.org> It's clearly still not working very well but we also have very few RFCs to vote on anyway; my feeling is that the root problem here was how much (or little) maintainer time svd2rust was getting rather than policies around approving PRs, but I don't know what to do about that problem (maybe accept loads more...
<re_irc> ... PRs and hope it leads to more people invested in helping maintain?)
<re_irc> <@s​ympatron:m​atrix.org> Sounds reasonable
<re_irc> <@s​ympatron:m​atrix.org> Didn't know that
<re_irc> <@s​ympatron:m​atrix.org> It's kind of sad that a project with so many dependents gets so little love
<re_irc> <@s​ympatron:m​atrix.org> But I can see why this is a difficult thing in OSS
<re_irc> <@s​ympatron:m​atrix.org> As long as nobody gets paid, you can't really blame anyone
<re_irc> <@b​radleyharden:m​atrix.org> evils, you definitely don't need RTIC. Are you familiar with embedded programming in general? You could do it by polling the foot pedal every so often. Or you could set up external interrupts. Exactly how you do that will depend on your specific board, HAL, etc.
<re_irc> <@a​damgreig:m​atrix.org> I think everyone here wants to see embedded for rust get better and many have and are willing to put a lot of time into it, but definitely it's difficult to implement effective ways to get people working together while maintaining some stability and supporting lots of use cases
<re_irc> <@a​damgreig:m​atrix.org> I'm sure we (as in the WG) could be doing it a lot better too; right now it feels like lots of non-wg contributors have collectively more time or energy than wg members have to manage it
<re_irc> <@e​vils.devils:m​atrix.org> though i like to think i'm comfortable enough with the concept to see learning Rust as the bigger hurdle :P
<re_irc> <@e​vils.devils:m​atrix.org> bradleyharden: i've done a tiny bit of arduino stuff a few years ago...
<re_irc> <@a​damgreig:m​atrix.org> If you've already seen some examples using rtic it might be the easiest way to go; the complexity it adds probably more than balances out the complexity of trying to do the same things without it
<re_irc> <@b​radleyharden:m​atrix.org> adamgreig, polling would probably be simpler than both though
<re_irc> <@a​damgreig:m​atrix.org> Yea, I guess if you can do everything in one main loop without worrying about interrupts then that's probably simplest
<re_irc> <@e​vils.devils:m​atrix.org> yea and i have a stalled previous project that's definitely going to need RTIC
<re_irc> <@e​vils.devils:m​atrix.org> though the current thing is so straight-forward it seems like learning RTIC on top of just getting the basics done is a bad idea
<re_irc> <@b​radleyharden:m​atrix.org> If you want simple, I would avoid interrupts. But I agree that RTIC makes using interrupts easier than it would be without
<re_irc> <@e​vils.devils:m​atrix.org> i guess it's in the name for a reason :P
<re_irc> <@e​vils.devils:m​atrix.org> i guess i'm just going to have to look at the RTIC based keyberon projects and try to look past the RTIC stuff
<re_irc> <@s​ympatron:m​atrix.org> My main frustration right now is that I would love to switch to Rust at work to get away from C. And the ecosystem is already 95% there, but I can't add the rest at work and have very little free time to work on it. So I am basically stuck until someone else adds the missing things by chance 😞
<re_irc> <@t​herealprof:m​atrix.org> sympatron: I guess a lot of us are in the same boat.
<re_irc> <@a​damgreig:m​atrix.org> And probably all with different 5%s :p
<re_irc> <@t​herealprof:m​atrix.org> Anyway, the point of merging something is really moot if there's not even a PR.
<re_irc> <@j​amesmunns:m​atrix.org> sympatron: This is probably not useful, but if anyone finds a blocker like this, and your company is willing to pay to make it go away, Ferrous (and a number of other freelancers I'd be happy to refer you to) are often exactly the fix here.
<re_irc> <@j​amesmunns:m​atrix.org> Despite costing money, we often know exactly the problem you are experiencing, and can solve the problem well, and quickly. And you have the choice of making the solution open source or not, depending on your domain (both have plusses and minuses).
<re_irc> <@j​amesmunns:m​atrix.org> Often, managers are more receptive to this than you might think, because "fixed cost to make problem go away" is a pretty compelling value proposition.
<re_irc> <@j​amesmunns:m​atrix.org> (and can be budgeted for, etc.)
<re_irc> <@j​amesmunns:m​atrix.org> Anyway, DMs always open, even if you don't end up booking Ferrous to solve the problem.
<re_irc> <@j​amesmunns:m​atrix.org> I coach a lot of engineers, managers, and engineering managers. Happy to talk at whatever the relevant level is.
<re_irc> <@j​amesmunns:m​atrix.org> `</plug>`
neceve has quit [Remote host closed the connection]
<re_irc> <@s​ympatron:m​atrix.org> Btw does anybody here know when alloc can be used on stable? Is there any ETA?
<re_irc> <@t​halesfragoso:m​atrix.org> sympatron: Probably no ETA, but see https://github.com/rust-lang/rust/issues/66741
<re_irc> <@f​irefrommoonlight:m​atrix.org> sympatron: What specific blockers are you running into? There are always ways around it. You should never wait on a PR merge to continue with your goals
<re_irc> <@d​irbaio:m​atrix.org> If you can't get your job to switch to rust, switch jobs 😜
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think the Rust ecosystem for Cortex-M, at least, is in a good enough position that the missing features etc are patchable without being an expert
fabic has quit [Ping timeout: 265 seconds]
rjframe has quit [Quit: Leaving]
SomeWeirdAnon has joined #rust-embedded
Wetmelon has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> btw, I'm working on getting that "color sequencer" crate I've been talking about lately open-sourced. It's up here, I'm working on the docs for it now :)
<re_irc> <@j​amesmunns:m​atrix.org> https://github.com/jamesmunns/choreographer
<re_irc> <@j​amesmunns:m​atrix.org> In case anyone has been following my "pretty LED patterns" tweets as of late.
<re_irc> <@a​rbitrix:m​atrix.org> jamesmunns
<re_irc> <@j​amesmunns:m​atrix.org> I appreciate it!
<re_irc> <@r​iskable:m​atrix.org> FYI: A while back folks were asking me how I used a `Config.toml` in my Riskeyboard 70 keyboard firmware project. The project is nowhere near ready for production use but I uploaded the code today in case anyone wants to see how I handled the whole `build.rs` to `userconfig.rs` to...
<re_irc> ... `include!(concat!(env!("CARGO_MANIFEST_DIR"), "/src/config_structs.rs"));` stuff: https://github.com/riskable/riskeyboard70
fabic has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> wonder how else you could use the config structs inside build.rs
<re_irc> <@a​damgreig:m​atrix.org> obviously can't import them from your own crate because it's not built yet
<re_irc> <@a​damgreig:m​atrix.org> but seems kinda overkill to put them in a separate crate and depend on it from both build script and main crate
<re_irc> <@a​damgreig:m​atrix.org> I guess include!() works fine
<re_irc> <@r​iskable:m​atrix.org> The `build.rs` `include!`s the `config_structs.rs` right at the top so it can understand the configuration types and uses the `toml` module to parse `Config.toml` into those structs then dumps the resulting Rust code into `config.rs` (which is mostly empty) via `include!(concat!(env!("OUT_DIR"),...
<re_irc> ... "/userconfig.rs"));`. This way the code in `main.rs` can have `mod config; mod config_structs;` at the top and "just use" the configured values throughout the code.
<re_irc> <@r​iskable:m​atrix.org> If there's a better way to handle a bunch of user-configurable items like this I'm all ears
<re_irc> <@s​ajattack:m​atrix.org> serde?
<re_irc> <@s​ajattack:m​atrix.org> it sounds like you just want rust structs in toml, unless I'm misunderstanding, that sounds overcomplicated
<re_irc> <@r​iskable:m​atrix.org> The plan is to move most of the code out of `main.rs` and into hardware-agnostic files and instead have something like a `keyboards` directory that contains the platform-specific boilerplate and imports the stuff that's actually used by the firmware. I still haven't figured out a way for end users to be able to...
<re_irc> ... specify which pins go where though
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@r​iskable:m​atrix.org> sajattack: I don't understand what you're suggesting... Can you be more specific?
<re_irc> <@s​ajattack:m​atrix.org> you can just put your config options in a struct and ser/de it
<re_irc> <@s​ajattack:m​atrix.org> no need to have intermediary rust files
<re_irc> <@r​iskable:m​atrix.org> Don't you need an allocator for that to work though?
<re_irc> <@s​ajattack:m​atrix.org> hm, maybe
<re_irc> <@r​iskable:m​atrix.org> ...if it's in the main.rs that is
<re_irc> <@r​iskable:m​atrix.org> That code you showed me isn't `#![no_std]`
<re_irc> <@s​ajattack:m​atrix.org> yeah
<re_irc> <@r​iskable:m​atrix.org> This is the only method I've been able to get working without having an allocator in `main.rs`
<re_irc> <@s​ajattack:m​atrix.org> I would make a desktop application that uses serde to generate the rust files then. I don't understand why that part needs to run on the controller.
<re_irc> <@r​iskable:m​atrix.org> If it's in `main.rs` then it's running on the controller :D
<re_irc> <@s​ajattack:m​atrix.org> but it's just a config
<re_irc> <@r​iskable:m​atrix.org> Right, that's why `build.rs` reads the config and converts it to rust code that winds up in `config.rs`
<re_irc> <@s​ajattack:m​atrix.org> right
<re_irc> <@r​iskable:m​atrix.org> It's no problem for `build.rs` to use `std` (with an allocator)
<re_irc> <@s​ajattack:m​atrix.org> right then why were you complaining about my thing not being no_std?
<re_irc> <@s​ajattack:m​atrix.org> the main.rs here is a desktop tool that builds our binaries, not something running on a no_std platform
<re_irc> <@r​iskable:m​atrix.org> "You want rust structs in toml..." Then you give me an example of a `std` program using `fs` to read a toml in `main.rs` haha
<re_irc> <@s​ajattack:m​atrix.org> alright well it seems we're talking past eachother
<re_irc> <@r​iskable:m​atrix.org> Show me how you'd do it in a `no_std` firmware. That's all
<re_irc> <@r​iskable:m​atrix.org> I need a better example because I'm too new to Rust. I don't get it
<re_irc> <@s​ajattack:m​atrix.org> I think what you're doing is fine now that I understand it better
<re_irc> <@r​iskable:m​atrix.org> But it *can't* be fine! It's stupidly complicated! haha
<re_irc> <@r​iskable:m​atrix.org> There's *got* to be a better way!
<re_irc> <@r​iskable:m​atrix.org> Anyone that wants to help me out with my code is going to need a 20-minute introductory session on the bizarre layout of everything haha
<re_irc> <@s​ajattack:m​atrix.org> haha
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc> <@b​raincode:m​atrix.org> evils: RTIC and Arduino are in a particular impasse at the moment last time I checked: I tried to port my RTIC mouse from STM32F0 to AVR 328P and there’s some refactoring needed on RTIC needed to make this multi-targeting nicer/better.
<re_irc> <@b​raincode:m​atrix.org> (According to RTIC devs)
<re_irc> <@b​raincode:m​atrix.org> “Then it would be a lot easier, for now you would need to implement an entire codegen backend for AVR”
SomeWeirdAnon has quit []
Wetmelon has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
Wetmelon has joined #rust-embedded