09:22:33 Hi everyone, I've developed a Rust-based monitoring TUI (Sentinel Lite) for the upcoming FCMP++ Stressnet on May 6th. I have a CCS proposal drafted and ready to go. Could a maintainer help me get a GitLab account at repo.getmonero.org to submit it? Here is a demo of the tool in action: https://vimeo.com/1186644452 09:51:37 video is a tui that tries to determine the amount of time it took for each blocks to be verified by the node... with rpc. 09:51:45 plowsof i beg you give me the perm 09:55:40 forgot to say its says simulated and mock rpc, so no real measure and the simulated measures are throwin bullshit numbers. Like somehow block 3000001 being verified in 20ms and 2 second later 3000002 being verified in 84 ms. make sense 09:56:01 I CANNOT STAND IT BAN THIS CLANKER RIGHT NOW 10:54:46 .merge+ 10012 10:54:46 Added 12:36:40 Hey SyntheticBird, you're 100% correct the demo is running on a mock RPC and simulated logs. Although with this being a Dev group I assumed this would be understood. Eagle eyes, though nice catch. Better to feed it junk data now to ensure the telemetry holds up when the actual Stressnet hits on May 6th. I could mirror real feedback, but the point stands in that 3000ms spikes are n 12:36:40 ot just possible, they are expected. This is exactly what we what we are looking for in a stress-test scenario. The demo just shows you that reality in 60 seconds instead of waiting for a bad block event. Thanks for the feedback though, but I dont think this constitutes a ban. 12:37:54 Hey SyntheticBird, you're 100% correct the demo is running on a mock RPC and simulated logs. Although with this being a Dev group I assumed this would be understood. Eagle eyes, though nice catch. Better to feed it junk data now to ensure the telemetry holds up when the actual Stressnet hits on May 6th. I could mirror real feedback, but the point stands in that 3000ms spikes are n 12:37:54 ot just possible, they are expected. This is exactly what we what we are looking for in a stress-test scenario. The demo just shows you that reality in 60 seconds instead of waiting for a bad block event. Thanks for the feedback though, but I dont think this constitutes a ban. 12:39:41 I also tried to make that as clear as possible by showing both terminals from the start. 12:49:05 "Although with this being a Dev group I assumed this would be understood." Such assumptions are always risky. Better to be crystal clear from the outset, to avoid any misunderstandings. 12:49:54 "I also tried to make that as clear as possible by showing both terminals from the start." Well, even when watching the video full screen, text was hard to read for me, because of the unfortunately low contrast of blue on black. 13:26:35 .merge+ 10465 13:26:35 Added 15:57:12 For some reason, I keep getting segfaults when running `ctest` in `build/debug/tests/unit_tests` 15:57:38 Meanwhile, it works perfectly fine on the CI with the same branch (well, some tests don't pass, but it doesn't segfault) 15:59:26 https://paste.debian.net/hidden/3335f89f 15:59:55 The errors seem to come from `boosted_tcp_server` which my changes have nothing to do with 17:23:47 jpk68: if you compile master branch, do you get the same error? 17:25:49 Will attempt, thanks 17:25:56 Unrelated: I think issue #8562 can be closed 17:33:06 selsta: Yes, it also segfaults on master 17:33:51 ok, one last test could you also checkout v0.18.4.6 tag, and run tests there? just to make sure there is no regression here 17:36:04 Does it segfault w/o your changes? 17:36:13 Yes, I tested on master ^ 17:36:28 The issue is unrelated to my changes 17:43:34 selsta: It also fails on v0.18.4.6, but with an exception instead of segfault 19:22:28 Okay, I eventually got the tests working just by deleting the problematic ones... does look like a regression happened, though