13:29 <fridtjof[m]> to hell with this idle kicking thing

13:29 <fridtjof[m]> there's apparently a bug (might file an issue later) where your matrix client(s? only some of them? idk?) will just drop rooms you're no longer part of from the room list

13:33 <fridtjof[m]> There's a "Historical" section (which does contain two rooms i just left on my own), but it's so unreliable that I had to remember the channels I was in off the top of my head. It kind of felt like it was actively gaslighting me

13:33 <whitequark[m]> Element?

13:33 <fridtjof[m]> yeah

13:33 <whitequark[m]> yes, it does have some bugs that feel like it's gaslighting you

13:33 <whitequark[m]> i'm very unhappy about it

13:34 <agg> the irc bridge kicking thing is really annoying, not least because it's not clear how good it is about the "30 days idle" thing

13:34 <whitequark[m]> the developers do seem to care at least

13:34 <agg> but it seems like a complicated political issue more than anything

13:34 <whitequark[m]> yes

13:35 <agg> i don't fully understand freenode's policy given the prevalence of discord/mattermost/etc bots anyway, though the matrix "one connection per bridged user" thing is nicer to interact with

13:35 <agg> but we have so many people kicked from the rust-embedded channel who don't even care about irc anyway, which is annoying

13:35 <whitequark[m]> they seem to dislike connection storms when the bridge flops

13:36 <agg> as though freenode never has netsplits

13:36 <fridtjof[m]> Yeah, the puzzling part is that it does not seem to properly account for read status when kicking people. I regularly read this channel, yet I got kicked anyway

13:36 <fridtjof[m]> From skimming related issues, there might have been performance issues that kept them from fixing this...?

13:38 <fridtjof[m]> here: https://github.com/matrix-org/matrix-appservice-irc/issues/1194

13:41 <agg> huh, i hope that gets deployed then, looks like it would help

13:41 <agg> i thought it already used presence to detect idle rather than purely sending messages, jeez

13:45 <fridtjof[m]> at least it does seem to keep history, and "only" lets the room fall off the list

13:45 <russss> yeah I feel like these are Matrix's issues rather than Freenode's

13:46 <sknebel> FWIW, Freenode does allow smaller bridges that behave (=are stable) to turn that setting off

13:47 <agg> maybe we should self-host a bridge for the one channel then, even in the worst case flop it would only affect us and total user count would be low, hum

13:50 <fridtjof[m]> I think most of the annoyances associated with IRC autokick could be alleviated simply by fixing element's UX around kicking/leaving and historical rooms

13:50 <agg> or just remove them from the irc side and re-connect them when they say something, but that's where it hits the policy issue perhaps

13:56 <russss> fwiw freenode has no problem with us (irccloud) keeping users connected while they're active or paying. We only auto-disconnect users if they're non-paying after 2 hours of inactivity (based on whether they have the app open, not whether they're talking).

13:56 <russss> so this is why I say I suspect it's Matrix's problem, I don't see why they shouldn't keep people connected if they're reading the channel

13:57 <russss> I also don't feel like Matrix's gateway is substantially less reliable than irccloud these days.

16:15 <sorear> how is the bridge these days on randomly losing messages or delaying them for >hour

16:25 <whitequark[m]> try it

17:35 <gruetzkopf> i should (but freenode is one of the more reliable networks for my bouncer connection)

17:37 <sorear> if it's relatively reliable then I won't get much information from brief casual use

20:11 <fest> hmm, I've read in the irclogs that it should be easy to saturate the USB port. it appears I'm overrunning the fifo in no time, so I wonder how exactly am I supposed to hold it correctly

20:11 <whitequark[m]> what are you doing?

20:13 <fest> so far I've got an iface.read(339*256*2) in applet's run(), and ~6MiB/s worth of FIFO writes in the design. in the design I'm outputting fifo's w_rdy signal to output, which I observe with external logic analyzer. I'm seeing the output going low after ~4k bytes (in_fifo depth

20:14 <fest> the data I receive until fifo overflow is correct (every line from sensor starts with known pattern)

20:14 <whitequark[m]> are you calling iface.read in a loop?

20:15 <fest> so far I've got just one iface.read call, and in the logic analyzer I'm triggering on the very start of execution

20:16 <fest> oh,

20:16 <fest> mm, no, I didn't get the right amount of data if iface.read returned early

20:16 <fest> wouldn't*

20:16 <whitequark[m]> you're hitting a buffering issue, most likely

20:17 <fest> last I worked with fx2 I was seeing such issues when not enough transfers had been enqueued

20:18 <whitequark[m]> use the `-vvv` CLI option to see how the transfers are queued

20:25 <fest> hmm, it appears I'm receiving data in small chunks, so I probably have to look how flushing works

20:28 <fest> yep, disabling auto_flush helped

20:28 <fest> thank's for the pointer!