| 21 Apr 2026 |
 zoë (@blokyk) | haha yeah i stumbled on that exact article while trying to understand how to use it | 09:38:17 |
 Qyriad | Because, yknow, C++ | 09:38:17 |
| zoë (@blokyk) | god stack traces being a Generator has been a thorn in my side every time i've made a repl-related cl >:| | 09:40:53 |
| zoë (@blokyk) | * god stack traces being a Generator has been a thorn in my side every time i've made a repl-related cl, it's so annoying to work with >:| | 09:41:11 |
| zoë (@blokyk) | * god stack traces being a Generator has been a thorn in my side every time i've made a debugger-related cl, it's so annoying to work with >:| | 09:42:18 |
| zoë (@blokyk) | * god stack frames being a Generator has been a thorn in my side every time i've made a debugger-related cl, it's so annoying to work with >:| | 09:44:08 |
 Sergei Zimmerman (xokdvium) | In reply to @qyriad:katesiria.org
There's an open PR for it, but views::enumerate is surprisingly tricky https://brevzin.github.io/c++/2022/12/05/enumerate/ I hate that enumerate uses a signed type… | 10:11:29 |
| Qyriad | gods I know right | 10:11:58 |
| Sergei Zimmerman (xokdvium) | It’s like the classic C++ committee stupidity. Like why difference_type | 10:12:27 |
| Sergei Zimmerman (xokdvium) | There’s a mandatory talk about views::filter | 10:13:51 |
| Sergei Zimmerman (xokdvium) | It’s so full of footguns like being not thread safe | 10:14:06 |
| Sergei Zimmerman (xokdvium) | Or rather “it’s not thread safe if you call begin() for the first time concurrently” | 10:14:48 |
| Sergei Zimmerman (xokdvium) | And modifying elements is also UB when it changes the predicate | 10:15:38 |
 antifuchs | * All the lixcon talks I’ve seen recordings of so far are super great! Thanks for sharing them with all of us who couldn’t make it | 12:00:02 |
| zoë (@blokyk) | with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i want to get a vibe-check for it first | 12:26:04 |
| zoë (@blokyk) | * with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i'd like to get a vibe-check for it first | 12:38:30 |
| zoë (@blokyk) | * with regards to #1175, does saving each typed line ourselves (e.g. in an std::list or std::vector?) and then appending it to the file sound good? if so i can try to make a CL for it, but i'd like to get a vibe-check about it first | 12:38:35 |
 piegames | Hm, would simply saving the history after each command also work around the issue? | 12:46:25 |
| piegames | (Not sure if that's a good idea either) | 12:46:41 |
| zoë (@blokyk) | no unfortunately, unless we also reload the history before each prompt, because otherwise we'll still be writing the "outdated" history to the file | 12:48:12 |
| zoë (@blokyk) | for most people it shouldn't be an enormous burden, but idk it feels dirty and pretty fragile | 12:50:44 |
| piegames | In reply to @blokyk:matrix.org
no unfortunately, unless we also reload the history before each prompt, because otherwise we'll still be writing the "outdated" history to the file That's what I meant yes | 12:55:12 |
| zoë (@blokyk) | * for most people it shouldn't be an enormous burden, but idk it feels dirty and pretty fragile (we'd be at the mercy of disk I/O timings) | 12:56:10 |
| zoë (@blokyk) | * for most people it shouldn't be an enormous burden, but idk it feels dirty and pretty fragile (+we'd be at the mercy of disk I/O timings) | 12:56:21 |
| zoë (@blokyk) | personally i don't feel like that's a better solution :/
in part because of the aforementioned fragility+timing, but also because it'd then have the side effect of sharing the history between every repl session, which is an antifeature imo (i often have two repl sessions side-by-side to trying out different things, or i open a quick repl to check something for a bigger expr or something; if both sessions are shared i have to wade through the other repl's history while trying to navigate the current session's history because they're now all confusingly interleaved... there's a reason i generally disable zsh's SHARE_HISTORY option @_@) | 13:04:06 |
| piegames | I see | 13:11:14 |
 goldstein | offtopic, but thank you for teaching me I can just disable SHARE_HISTORY, this was annoying me immensely | 14:46:20 |
| zoë (@blokyk) | there's actually multiple mutually-exclusive settings that control zsh, each one making you go "wait, the other one didn't do that?!" :D
| 14:51:54 |
| 16 May 2024 |
|  zrsk joined the room. | 13:54:49 |
 samrose | In reply to @lunaphied:lunaphied.me
I think there were a few CLs on the Gerrit but nothing being actively worked The other thing that I could do if it helps is test things and try to find bugs. I did do some C++ work in the past, but may lack the time to do it justice here at least for about 30 days or so | 15:55:29 |
