fabic has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> you have two versions of cortex-m in the tree
<re_irc> <@d​irbaio:m​atrix.org> check what they are with `cargo tree`
<re_irc> <@d​irbaio:m​atrix.org> also maybe try `cargo update`
<re_irc> <@d​khayes117:m​atrix.org> @dirbaio:matrix.org: Already did that, and it fixed it
<re_irc> <@d​irbaio:m​atrix.org> oh I see you already posted that you solved it.. but I can see the message from phone and not desktop???
<re_irc> <@d​irbaio:m​atrix.org> refreshed and it's now there
<re_irc> <@d​irbaio:m​atrix.org> wtf
<re_irc> <@d​irbaio:m​atrix.org> :D
<re_irc> <@d​irbaio:m​atrix.org> 🤷‍♂️
<re_irc> <@d​khayes117:m​atrix.org> Weird, thanks for the thought! Can some one explain how the % works here? Is this remainder or modulo?
<re_irc> <@d​khayes117:m​atrix.org> for i in 0..=7 {
<re_irc> <@d​khayes117:m​atrix.org> }
<re_irc> <@d​khayes117:m​atrix.org> let next = (i + 1) % 8;
<re_irc> <@d​khayes117:m​atrix.org> next = 1,2,3,4,5,6,7,0
<re_irc> <@d​irbaio:m​atrix.org> isn't remainder and modulo the same?
<re_irc> <@d​irbaio:m​atrix.org> anyway
<re_irc> <@d​irbaio:m​atrix.org> ah, hm but that shouldn't matter here since you don't have negative numbers right?
<re_irc> <@d​irbaio:m​atrix.org> when i=7, you get 8%8 which is 0
<re_irc> <@d​irbaio:m​atrix.org> TIL that modulo and remainder are not the same 🤣
<re_irc> <@d​khayes117:m​atrix.org> Yep, that one I get. I don't understand how 1%8 = 1
<re_irc> <@d​irbaio:m​atrix.org> but they're the same for positive integers
<re_irc> <@d​irbaio:m​atrix.org> 1%8 = 1 because if you divide 1/8, you end up with 0, and a remainder of 1
<re_irc> <@d​khayes117:m​atrix.org> My understanding is that 1/8 = 0.125 which is truncated to 0, how is remainder 1?
<re_irc> <@d​irbaio:m​atrix.org> remainder is what you're left with that's not multiple of 8 after dividing by 8
<re_irc> <@d​irbaio:m​atrix.org> 43%8 = 3
<re_irc> <@d​irbaio:m​atrix.org> because 43/8 gives you 5, and 8*5 is 40, so you have 3 "left", which is the remainder
<re_irc> <@d​khayes117:m​atrix.org> oh I see, since 1 can't be divided by 8, then it doesn't divide it it just returns the original 1
<re_irc> <@d​khayes117:m​atrix.org> so 0 divisions with 1 left over
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
Wetmelon has quit [Ping timeout: 240 seconds]
<re_irc> <@f​irefrommoonlight:m​atrix.org> Btw, I have that same error where I can't see the "fixed it" post on desktop, but can on phone
<re_irc> <@d​khayes117:m​atrix.org> After I posted the solution, my following posts would show above it like it was always the last comment
<re_irc> <@j​duchniewicz:m​atrix.org> Not wanting to kick the hornet nest, I feel like it this group could use more formality, like regular rust wg’s. Or maybe at least something akin to Zulip’s threads, so one can track easily some topics instead of scrolling messages endlessly (typical IRC)
fabic has quit [Ping timeout: 244 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <@r​yan-summers:m​atrix.org> I think a tool like Zulip would make more sense if we had more defined teams etc. - I don't know if things are currently structured enough for it, and I think the approach right now is for topic-specific discussions to occur in respective Github repos/orgs
<re_irc> <@r​yan-summers:m​atrix.org> Generally what I've seen is that this is mainly just a chat room to connect with people, and technical discussions etc. generally happen via issues and PRs
<re_irc> <@r​yan-summers:m​atrix.org> I personally got really overwhelmed and confused when I first jumped on the Rust team Zulip
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc> <@j​duchniewicz:m​atrix.org> I am interested in topic here but the sheer amount of info going through daily is too much to follow(and sieve through) if I don’t dedicate special time to it. That is why I like topics - they make reading it and contributing to it async much easier.
<re_irc> <@j​duchniewicz:m​atrix.org> Of course the argument of too much info is valid, but assuming there was a subgroup for embedded rust on Zulip, it would make async jumping on and off to the discussion much easier
<re_irc> <@j​duchniewicz:m​atrix.org> Thing that IRC kind of destroys is multiple discussions at the same time/prolonged discussions
<re_irc> <@j​duchniewicz:m​atrix.org> *or at least deals poorly with
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
<re_irc> <@j​amesmunns:m​atrix.org> Github also has a new discussions feature
<re_irc> <@j​amesmunns:m​atrix.org> If there's interest, we could probably enable that for the /wg repo
<re_irc> <@j​amesmunns:m​atrix.org> Here's an example repo using them: https://github.com/prisma/prisma/discussions
<re_irc> <@j​amesmunns:m​atrix.org> (I worry a bit about moderation bandwidth - any public space needs to be maintained)
<re_irc> <@j​amesmunns:m​atrix.org> BUT, if someone feels strongly about this, and is someone who has been active in discussions here before, lemme know. If people are willing to be moderators, I'd be willing to try it out (speaking from a resource team perspective)
<re_irc> <@T​imSmall:m​atrix.org> FWIW I had a dig, and threads are on the Matrix roadmap, but not looking like they'll get implemented imminently.
fabic has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
unmanbearpig has quit [Ping timeout: 272 seconds]
rjframe has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> As Ryan said, the crux here is how you use it, and what the intent is. Right now, this chat is a mix of lots of things - for example, technical questions, API questions, sharing projects, discussing approaches for public APIs etc. Some make sense as a chat, some don't. If your goal is to stay caught up...
<re_irc> ... on everything posted here, I agree that chat isn't a good medium. But I don't think that's ever an expectation with chat, since it's so tough
<cr1901> You're gonna be in for a world of pain if you try to read everything on IRC/Matrix chat
<re_irc> <@y​atekii:m​atrix.org> @jamesmunns:matrix.org: we have it on the probe-rs repo and it virtually hasn't been used. I am not sure if we encourage it not enough or where it's lacking, but I guess just activating it didn't help at least for us :)
<re_irc> <@t​halesfragoso:m​atrix.org> It's good for asking questions, people use it a lot on the actix repo
<re_irc> <@t​halesfragoso:m​atrix.org> But apart from that, not sure if it's that nice for discussions
<re_irc> <@y​atekii:m​atrix.org> yeah :) I mean it has + & - :) It keeps everythign well documented and maybe a bit more civilized, but a discussion is more drawn out and one can loose track because of that :)
<re_irc> <@y​atekii:m​atrix.org> I loved the video call last night. I felt that it was really productive even tho we had a lot of offtopic too
<re_irc> <@t​halesfragoso:m​atrix.org> Heh, I didn't even know what it was about, just got a notification in the room from element
<re_irc> <@t​halesfragoso:m​atrix.org> But yeah, very cool, I have to get back to looking at probe-rs, have to update the nrf-recover repo
<re_irc> <@y​atekii:m​atrix.org> yeah basically we were discussing/working on sequences
<re_irc> <@y​atekii:m​atrix.org> which will make nrf-recover obsolete :P
<re_irc> <@y​atekii:m​atrix.org> because it will be built in
<re_irc> <@y​atekii:m​atrix.org> and work for any chip where it is implemented
<re_irc> <@y​atekii:m​atrix.org> but it still takes some time :)
<re_irc> <@t​halesfragoso:m​atrix.org> Just don't erase the chip without asking like pyocd...
<re_irc> <@y​atekii:m​atrix.org> no, that is not the idea. we wont ever do that
<re_irc> <@y​atekii:m​atrix.org> the idea is that it is easy to have custom functions run
<re_irc> <@y​atekii:m​atrix.org> so you get a catalogue of custom functions per chip
<re_irc> <@y​atekii:m​atrix.org> which then can be conveniently be run from cargo-flash or whatever the tool
<re_irc> <@y​atekii:m​atrix.org> and ofc the library
<re_irc> <@t​halesfragoso:m​atrix.org> Cool, already inside probe-rs ? Or plug and play ?
<re_irc> <@t​halesfragoso:m​atrix.org> Ah, got it
<re_irc> <@y​atekii:m​atrix.org> yeah so the idea is that we define those in rust inside probe-rs for trhe chips that need them to work to start
<re_irc> <@t​halesfragoso:m​atrix.org> @yatekii:matrix.org: Yeah, the tool will be nrf-recover, só not obsolete hahaha
<re_irc> <@y​atekii:m​atrix.org> and then we extend it to some script language with which you can define sequences just like you define the rest in the target yamls
<re_irc> <@y​atekii:m​atrix.org> @thalesfragoso:matrix.org: well yeah, but the idea is that you do not need a different tool for each chip :)
<re_irc> <@y​atekii:m​atrix.org> the idea is that cargo-flash can check whether the chip is locked for each chip and if it is it will ask if it should unlock and do exactly that if the answer is yes :)
<re_irc> <@t​halesfragoso:m​atrix.org> Sure, makes sense to have at each tool that can do flashing
<re_irc> <@y​atekii:m​atrix.org> so you doi not need nrf-recover, nrf-lock, stm-recover, stm-trace-enable etc :D
<re_irc> <@y​atekii:m​atrix.org> I mean sequences are not only for recovering :) they also handle complicated reset sequences (required for quite some cores, specifically the atsamd ones, they handle tracing setup, etc.
<re_irc> <@y​atekii:m​atrix.org> theoretically we can extend the system, so any chip can have custom sequences, for example "flash softdevice"
<re_irc> <@y​atekii:m​atrix.org> but witha general purpose clean system
<re_irc> <@y​atekii:m​atrix.org> not all over the place etc
<re_irc> <@t​halesfragoso:m​atrix.org> Great ideas
<re_irc> <@y​atekii:m​atrix.org> thats way in the future tho :D
<re_irc> <@y​atekii:m​atrix.org> for starters this will make samd work better, make multicore like lpc55sxx, nrf53, stm32wb possible and unlocking of chips possible
starblue3 has quit [Ping timeout: 268 seconds]
<re_irc> <@y​atekii:m​atrix.org> with sequences you should be completely free of any other tools :)
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm going to experiment with stm32wb soon - but haven't done any testing beyond main core stuff you could do on any MCU
<re_irc> <@y​atekii:m​atrix.org> @firefrommoonlight:matrix.org: tiwalun has done quite some fy
<re_irc> <@y​atekii:m​atrix.org> mostly BLE stuff tho I believe
Wetmelon has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Great. I remember someone earlier posting this prior art for Bluetooth: https://github.com/eupn/stm32wb55
<re_irc> <@f​irefrommoonlight:m​atrix.org> The IPCC and HSEM don't seem especially tough to set up from RM, but havent't tried, and there may be subtleties on the software side
<re_irc> <@y​atekii:m​atrix.org> yeah, I just know he did, don't know about the actual state of the chip :)
thejpster has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
thejpster has quit [Remote host closed the connection]
starblue3 has joined #rust-embedded
jasperw has joined #rust-embedded
starblue3 has quit [Ping timeout: 264 seconds]
neceve has quit [Ping timeout: 252 seconds]
Shell has quit [Ping timeout: 244 seconds]
starblue3 has joined #rust-embedded
VShell has joined #rust-embedded
VShell is now known as Shell
Shell has joined #rust-embedded
Shell has quit [Changing host]
<re_irc> <@s​ympatron:m​atrix.org> Regarding yesterday's discussion about proposing changes to the rust ecosystem and whether to try to fix or fork I want to add my 2 cents: IMO (permanent) forking should be the last resort. Removing fragmentation later on is a huge effort and will probably only happen in the form of dying forks. Additionally I...
<re_irc> ... agree with dirbaio that changes should be accepted more easily in general. Rust embedded is still in early stages so anyone using one of the main crates (which are almost all pre 1.0) should be expecting breaking changes. If we cling to all the bad decisions made in the beginning just to avoid the dreaded breaking changes the outcome...
<re_irc> ... will not be pleasant to work with. My personal pet peeve is svd2rust #478 where the OP correctly (IMO) pointed out a confusing API and proposed something strictly better (again IMO) which was then postponed after a lengthy discussion to "maybe sometime" because it might not be **that** big of an issue although it would probably be an...
<re_irc> ... easy fix and the breaking changes in dependent crates would be easy to fix, too. As I said, I think the current API of many core crates is just not mature enough to consider it carved in stone and breaking changes should be expected by users. That's what SemVer is for. Postponing necessary changes increases technical dept. The longer...
<re_irc> ... you wait the more people depend on the current API and the harder it becomes to change things.
<re_irc> <@t​herealprof:m​atrix.org> sympatron: I would pretty much fully agree with your sentiment, with the one exception of the mentioned #478. Whether the proposed API is actually an all-around improvement is debateable at least and I very much disagree with the idea of changing something for the sake of change.
<re_irc> <@s​ympatron:m​atrix.org> I wouldn't change something for the sake of change either. But I think the API is questionable in this case and annoyed me quite a bit while working on atsamd-rs.
<re_irc> <@t​herealprof:m​atrix.org> Fair enough, but people do have other opinions about that as well. And with proponents not participating in the required experimentation and discussion it's really hard to see why this wouldn't be change for the sake of change.
<re_irc> <@t​herealprof:m​atrix.org> If someone took on the onus of actually providing some evidence of some benefits (or at least lack of disadvantages) we could pick up the discussion.
<re_irc> <@t​herealprof:m​atrix.org> I don't recall anyone being terrible opposed to the change either...
<re_irc> <@s​ympatron:m​atrix.org> What I meant was that the change has only benefits in my opinion with the exception of being a breaking change. And I was arguing that the change should be made in these cases. It seems we disagree on this particular example, but that was not the point I was trying to make.
<re_irc> <@s​ympatron:m​atrix.org> therealprof: As far as I could see in the discussion the only disadvantage was that it was a breaking change.
<re_irc> <@t​herealprof:m​atrix.org> There might be more but we don't know since no one experimented with it. I vaguely recall concerns about worse code generation for example.
<re_irc> <@t​herealprof:m​atrix.org> But this goes back to the starting point of the discussion: This is not a company with a fixed budget working on a product but fully driven by contributions.
<re_irc> <@t​herealprof:m​atrix.org> We tried multiple times to discuss this and move this forward but had to drop the discussion due to lack of interest.
<re_irc> <@t​herealprof:m​atrix.org> You're very much welcome to put the required work into the proposal to help us make some progress.
<re_irc> <@t​halesfragoso:m​atrix.org> Iirc a lot of people were in favor of breaking svd2rust in general, so I wouldn't say that change didn't land because of breaks
<re_irc> <@s​ympatron:m​atrix.org> You are right. This wasn't meant to sound like a demand, if it came across that way. I know all maintainers are volunteers and I am very thankful for all the work the community put into it.
<re_irc> <@s​ympatron:m​atrix.org> In this particular case I might actually try to work on it, if I find the time for it.
<re_irc> <@s​ympatron:m​atrix.org> But I found that this is difficult in general. Many projects are quite complex. Implementing a change you need in a complex foreign project can be extremely hard or (depending on your skillset) impossible to do. So as a user you're often dependent on the help of the maintainers. I think this is sometimes the...
<re_irc> ... cause of frustration. Not because of unwillingness to do it themselves, but because of inability.
<re_irc> <@t​herealprof:m​atrix.org> thalesfragoso: Well, I wouldn't say "in favour" but indeed we're willing to accept breakage if there're some real gain.
<re_irc> <@t​herealprof:m​atrix.org> sympatron: I agree that some shepherding or guidance might be necessary and it might be possible to provide that; no one is asking that a contributor implements something on their own. What is required is that someone steps up, starts working on it and best case also show up in the Tuesday meeting to discuss...
<re_irc> ... the concept and the steps to get there.
<re_irc> <@t​halesfragoso:m​atrix.org> I want to decouple singletons and get rid of references, that should break a few things, heh
<re_irc> <@t​halesfragoso:m​atrix.org> But I still need to get familiar with the code base to propose some real code :/
starblue3 has quit [Ping timeout: 258 seconds]
<re_irc> <@t​herealprof:m​atrix.org> The code is not terribly complex (although the funnelling through `quote` and `proc-macro` which are not meant for code generation adds some weird quirks). The real complexity comes from the tool not doing anything standalone. You need to feed some svd through it, take the code, adapt some HAL (or application...
<re_irc> ... code) for the new PAC and test with that. Any such iteration can take quite a lot of time and there's little possibility for automation.
<re_irc> <@t​herealprof:m​atrix.org> It would be immensely useful for testing if we could (instead of going through PAC code on the filesystem) directly process the SVD into code in the HAL by invoking some proc-macro magic. I had some ideas to implement that a long while ago but then some pandemic hit and shrunk my time budget for embedded...
<re_irc> ... stuff to very close to zero...
<re_irc> <@t​halesfragoso:m​atrix.org> We're doing some experimentation already, it's going great, but it isn't a pac for direct use
<re_irc> <@t​halesfragoso:m​atrix.org> It's more for HALs writers, I would like to have both though
<re_irc> <@t​halesfragoso:m​atrix.org> That's why I want to decouple the singletons
<re_irc> <@b​radleyharden:m​atrix.org> Would it be possible to make the PAC API, more C-like? By that I mean use bitwise operators. I know there are various bit-centric crates that do that. But I don't know if that could work well with VolatileCells. It also might not work well with enum fields.
<re_irc> <@t​halesfragoso:m​atrix.org> bradleyharden: Adam's ral is a bit like that
<re_irc> <@f​irefrommoonlight:m​atrix.org> sympatron: I wasn't familiar with that Issue on GIthub, but have lamented out it independently. I fully agree with making the change. It's a minor syntax hassle that comes up all the time when using PACs. It's more notable when using `[cfg()]` inside the `modify`, since that changes whether a given line...
<re_irc> ... will be the final one or not. My workaround has been to duplicate the terminator under all cfg branches; not ideal
<re_irc> <@t​halesfragoso:m​atrix.org> But still not a lot of bitwise
<re_irc> <@b​radleyharden:m​atrix.org> Adam's ral?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Re how the process should have agone:
<re_irc> <@f​irefrommoonlight:m​atrix.org> - One or more maintainers who are authorized to make design decisions agrees.
<re_irc> <@f​irefrommoonlight:m​atrix.org> - couchand writes the Issue with sufficient reasoning, as he did
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's it
<re_irc> <@f​irefrommoonlight:m​atrix.org> Should be a quick process; that issue is from 2020
<re_irc> <@t​halesfragoso:m​atrix.org> That was several disagreements
<re_irc> <@t​halesfragoso:m​atrix.org> And discussions
<re_irc> <@t​halesfragoso:m​atrix.org> iirc it was pending not to do it
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ultimately, you need a small group of people, or 1 person with authority to make decisions
<re_irc> <@t​halesfragoso:m​atrix.org> Someone would probably need to make a RFC
<re_irc> <@f​irefrommoonlight:m​atrix.org> He or she or they should take all arguments and feedback into account, but not be bound by it. Just make the right call using the best info
<re_irc> <@f​irefrommoonlight:m​atrix.org> If you need unilateral agreement, you get mediocrity and stagnation
<re_irc> <@t​halesfragoso:m​atrix.org> You can't have one person taking all decisions though
<re_irc> <@t​halesfragoso:m​atrix.org> I mean, you can, but that isn't how the wg is organized
<re_irc> <@t​halesfragoso:m​atrix.org> And this is probably following guidelines of the rust project itself
<re_irc> <@t​halesfragoso:m​atrix.org> You don't need unilateral agreement, you just need majority
<re_irc> <@f​irefrommoonlight:m​atrix.org> Good point
<re_irc> <@b​radleyharden:m​atrix.org> To be honest, while I agree that syntax is better, I'm not super excited to update an entire HAL for it. There are benefits, but I don't know that it's worth the effort. I would rather see a more comprehensive change
<re_irc> <@f​irefrommoonlight:m​atrix.org> I was perhaps being too ideal, when there are multiple ways to approach this
<re_irc> <@f​irefrommoonlight:m​atrix.org> I was projecting a bit on how I like to run projects
<re_irc> <@t​halesfragoso:m​atrix.org> I think the way forward for that change in specific is someone that really wants it to write a RFV
<re_irc> <@f​irefrommoonlight:m​atrix.org> I just don't want to have a different syntax on the final item in a `modify`
<re_irc> <@t​halesfragoso:m​atrix.org> And the team will vote
<re_irc> <@f​irefrommoonlight:m​atrix.org> Esp due to me often using `cfg` to support multiple MCUs that have small changes
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - could just put a stake in the ground where you vote, then it's either merged or marked "will not change" on the spot, instead of fading into obscurity
<re_irc> <@t​halesfragoso:m​atrix.org> Well, there wasn't a RFC
<re_irc> <@f​irefrommoonlight:m​atrix.org> For some context, I went through a period where I had many PRs open in f3xx hal and l4xx hal, and they were largely ignored, or we'd get into minor argument about syntax and code style. I eventually gave up and made a new HAL, since I saw no alternative. I agree that this fragmentation isn't good - but...
<re_irc> ... if you're forced into it, it will happen
<re_irc> <@f​irefrommoonlight:m​atrix.org> So this is an issue of the issue creator not following the process?
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'll do the RFC: IF I can get someone with merge authority to confirm they're onboard and it won't stagnate
<re_irc> <@t​halesfragoso:m​atrix.org> It isn't not following the process per se, the issue is great and detailed, probably just need to put in the RFC model and submit a PR
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie if getting a change made involves a good deal of administrative effort, and you feel it will go nowhere even if you put the effort, the effort won't be made
<re_irc> <@t​halesfragoso:m​atrix.org> No single person has the merge authority
<re_irc> <@f​irefrommoonlight:m​atrix.org> I may take a stab at this tomorrow
<re_irc> <@t​halesfragoso:m​atrix.org> firefrommoonlight: w.r.t code style, guidelines, you can't blame the maintainers to not want to merge things that don't follow the established guidelines
<re_irc> <@t​halesfragoso:m​atrix.org> Apart from that, I agree that some PRs get estagnated for lack of work force
<re_irc> <@f​irefrommoonlight:m​atrix.org> In minor code style things, the answer is merge, patch to fix code style. Done. Instead of leaving the functionality out, or having an async convo/commit pattern with days or weeks between each communication
<re_irc> <@t​halesfragoso:m​atrix.org> But it's volunteer work after all, and a lot of people don't even are doing that for work (even remotely)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - that seems to be a big limitation
<re_irc> <@t​halesfragoso:m​atrix.org> firefrommoonlight: Why have it later ? Why not before the merge, if you plan to do the fix why postpone it ?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Going back and forth until the maintainer is satisfied can be a long process (it was in the cases I referred to).
<re_irc> <@t​halesfragoso:m​atrix.org> Indeed, I don't disagree with you, but I also don't see the merge, ask later, as the solution to all
<re_irc> <@f​irefrommoonlight:m​atrix.org> Case A: "OK, I'm glad you added this functionality, but you could please reformat it with rust fmt to meet the checker" "OK, done". (3 days later: "OK, but why is this written this way, why not the other' "Becaues yadada" (a week later)" "Any updates on merging this?" "We need to agree on how to handle...
<re_irc> ... how this function is layed out" "I give up"
<re_irc> <@f​irefrommoonlight:m​atrix.org> Case B: "OK, this PR's a bit messy, but I agree we need this functionality. Merged. I just committed a patch to make the code better"
<re_irc> <@f​irefrommoonlight:m​atrix.org> (Done within the hour)