Newest at the top
| 2026-07-02 16:35:07 +0000 | <tomsmeding> | oh right, no _retry_ |
| 2026-07-02 16:34:59 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-07-02 16:34:49 +0000 | <tomsmeding> | it's just two readTVar and two writeTVar |
| 2026-07-02 16:34:42 +0000 | <tomsmeding> | what does "this function never retries" even mean |
| 2026-07-02 16:34:07 +0000 | <lambdabot> | <hint>:1:38: error: parse error on input `of' |
| 2026-07-02 16:34:05 +0000 | <absentia> | > Efficiently read the entire contents of a TQueue into a list. This function never retries. |
| 2026-07-02 16:34:02 +0000 | <lambdabot> | NB: no module named ‘TQueue’ is imported. |
| 2026-07-02 16:34:02 +0000 | <lambdabot> | Not in scope: ‘TQueue.html#’ |
| 2026-07-02 16:34:01 +0000 | <absentia> | > https://hackage.haskell.org/package/stm-2.5.3.1/docs/Control-Concurrent-STM-TQueue.html#v:flushTQu… |
| 2026-07-02 16:33:59 +0000 | <absentia> | very concretely, this one |
| 2026-07-02 16:33:17 +0000 | <tomsmeding> | absentia: what do you mean with a non-retrying STM operation? |
| 2026-07-02 16:26:49 +0000 | <absentia> | bot still had OK latency though... i would hope so if it's checking the damn queue every couple nanoseconds.. |
| 2026-07-02 16:26:28 +0000 | <absentia> | months, if not years... |
| 2026-07-02 16:26:25 +0000 | <absentia> | this means that function has been working like that, busy looping and maxxing CPU, for like |
| 2026-07-02 16:26:15 +0000 | <absentia> | this is extremely embarassing |
| 2026-07-02 16:25:16 +0000 | <absentia> | lots of red herrings but eventually steered to a solution with measurable improvement |
| 2026-07-02 16:25:01 +0000 | <absentia> | i do admit i had to rubberduck this with GLM 5.2 |
| 2026-07-02 16:24:22 +0000 | <absentia> | i bet if i put a pipeline back in it might improve throughput by reducing roundtrips |
| 2026-07-02 16:24:12 +0000 | <absentia> | and now i'm seeing moderate traffic to the DB through pg_stat_activity |
| 2026-07-02 16:24:05 +0000 | <absentia> | i replaced the busyloop with a properly retrying version |
| 2026-07-02 16:23:59 +0000 | <absentia> | the cost centers in Hasql were a red herring |
| 2026-07-02 16:23:52 +0000 | <absentia> | implying mass allocation and CPU burn to GC |
| 2026-07-02 16:23:48 +0000 | <absentia> | it was in fact busy looping |
| 2026-07-02 16:23:44 +0000 | <absentia> | thinking it would block and retry if no transactions were committed to STM |
| 2026-07-02 16:23:28 +0000 | <absentia> | i used what is a NON-retrying STM operation |
| 2026-07-02 16:23:19 +0000 | <absentia> | i may be an idiot. |
| 2026-07-02 16:23:17 +0000 | <absentia> | fuck. |
| 2026-07-02 16:18:38 +0000 | <probie> | Are you sure it's not something silly like forgetting to commit a transaction? |
| 2026-07-02 16:16:43 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-07-02 16:14:51 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-07-02 16:10:35 +0000 | Googulator71 | Googulator |
| 2026-07-02 16:08:58 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 253 seconds) |
| 2026-07-02 16:06:12 +0000 | <absentia> | because hasql is actually a fantastic library |
| 2026-07-02 16:06:07 +0000 | <absentia> | and exhibit the issue |
| 2026-07-02 16:06:03 +0000 | <absentia> | should make a fucking docker image |
| 2026-07-02 16:05:09 +0000 | <absentia> | maybe this software |
| 2026-07-02 16:05:01 +0000 | <absentia> | need to feel something burning |
| 2026-07-02 16:04:58 +0000 | <absentia> | i wish i had a cigarette |
| 2026-07-02 16:04:54 +0000 | <absentia> | smfh |
| 2026-07-02 16:04:51 +0000 | <absentia> | it should be UTTERLY TRIVIAL |
| 2026-07-02 16:04:49 +0000 | <absentia> | i need a break from this problem but i am so frustrated/obsessed |
| 2026-07-02 16:04:42 +0000 | <absentia> | i can't do this any more |
| 2026-07-02 16:02:45 +0000 | <absentia> | hnngh... |
| 2026-07-02 16:02:37 +0000 | <absentia> | and maybe i could even fix it |
| 2026-07-02 16:02:34 +0000 | <absentia> | maybe it would make for a nice bug report |
| 2026-07-02 16:02:29 +0000 | <absentia> | i probably could |
| 2026-07-02 16:02:23 +0000 | <absentia> | sigh |
| 2026-07-02 16:01:10 +0000 | <tomsmeding> | (apart from having to set up a new database etc) |
| 2026-07-02 16:01:03 +0000 | <tomsmeding> | have you tried making a minimal reproducer of this problem? Given the hypothesis, that should not be complicated |
| 2026-07-02 16:00:32 +0000 | <absentia> | oh right |