05:25 <re_irc> <@ubik:matrix.org> : Yeah, tried both. Still doesn't make sense.

11:58 <re_irc> <@ryan-summers:matrix.org> Given bors' retirement, does anyone know good replacements for controlling access to protected environments? Was previously using bors to protect access to HITL environments for open-source repos

11:59 <re_irc> <@ryan-summers:matrix.org> So basically, trigger a GH workflow that accesses protected secrets only if requested by an authorized user. GH's environment protection review does it, but then I have to review my own manual triggers of the workflow, which is dumb

12:06 <re_irc> <@roy.buitenhuis-tnl:matrix.org> Is the Github merge queue feature not supposed to solve what Bors was solving?

12:07 <re_irc> <@ryan-summers:matrix.org> We were co-opting bors for slightly different behavior. We actually used it to selectively kick off a hardware-in-the-loop test on a self hosted runner whenever we thought the PR was ready

12:07 <re_irc> <@ryan-summers:matrix.org> So we could do "bors try" when we wanted to kick off the run, then it created a new github check by triggering a workflow and reported back when the HITL run finished

12:08 <re_irc> <@ryan-summers:matrix.org> We don't want to run HITL on necessary every PR, and we need to restrict who is allowed to run on the HITL

12:08 <re_irc> <@ryan-summers:matrix.org> * necessarily

12:10 <re_irc> <@ryan-summers:matrix.org> Maybe running on all PRs and using concurrency to cancel older runs would solve most of this, just need to figure out the permissions side

12:12 <re_irc> <@ryan-summers:matrix.org> Hmm, actually even that doesn't work because the actual HITL run is done in a separate repo, so concurrency cancels the current job, but not the actual HITL run

23:26 <re_irc> <@shakencodes:matrix.org> My application has a EEPROM and we intend to use one page of this as a black box for writing out failure/reset conditions. What are possible ways to share the handle for writing the EEPROM between the main application, panic handler, and default exception handler? -- This seems like an ownership nightmare, but it needs to happen.

23:36 <re_irc> <@dirbaio:matrix.org> unsafely steal it in HardFault

23:36 <re_irc> <@dirbaio:matrix.org> there's no way to do it safely anyway, since HardFault can't be blocked by critical sections

23:49 <re_irc> <@shakencodes:matrix.org> Can you explain the unsafe "steal"? At the moment, I am failing to obtain the basic peripherals to talk to the with "pac::Peripherals::take()"

23:50 <re_irc> And thank you for pointing out the HardFault. Aside from the main application usages, the black-box write is followed by either a loop and watchdog reset, or a commanded reset. So I am not concerned about stealing the hardware from the main application

23:52 <re_irc> <@dirbaio:matrix.org> you can "steal" zero-sized singletons out of thin air with "let i2c: I2C4 = unsafe { core::mem::transmute(()) };"

23:53 <re_irc> <@dirbaio:matrix.org> embassy HALs also have "let i2c = unsafe { I2C4::steal() };", not sure about others

23:54 <re_irc> <@dirbaio:matrix.org> you can steal the i2c, the pins, construct the driver, then write to the eeprom

23:54 <re_irc> <@dirbaio:matrix.org> (assuming it's an i2c eeprom)