Newest at the top
| 2025-01-03 22:19:46 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-03 22:18:18 +0100 | <monochrom> | Haha only the benchmarks are documented. |
| 2025-01-03 22:17:45 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 246 seconds) |
| 2025-01-03 22:10:25 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@static-198-54-134-176.cust.tzulo.com) (Remote host closed the connection) |
| 2025-01-03 22:04:57 +0100 | ft | (~ft@p3e9bc8e9.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-01-03 22:01:47 +0100 | kimiamania | (~65804703@user/kimiamania) kimiamania |
| 2025-01-03 22:01:24 +0100 | kimiamania | (~65804703@user/kimiamania) (Quit: PegeLinux) |
| 2025-01-03 22:00:14 +0100 | itscaleb4 | itscaleb |
| 2025-01-03 22:00:14 +0100 | itscaleb | (~itscaleb@user/itscaleb) (Ping timeout: 260 seconds) |
| 2025-01-03 22:00:01 +0100 | rdcdr_ | (~rdcdr@75-172-28-251.tukw.qwest.net) (Ping timeout: 252 seconds) |
| 2025-01-03 21:58:54 +0100 | rdcdr | (~rdcdr@user/rdcdr) rdcdr |
| 2025-01-03 21:58:07 +0100 | <c_wraith> | Oh, no. PrimMonad can be transformers around one of those. |
| 2025-01-03 21:58:00 +0100 | itscaleb4 | (~itscaleb@user/itscaleb) itscaleb |
| 2025-01-03 21:56:51 +0100 | <c_wraith> | man, vector's new cabal layout really messes with haddock. The index only includes the items in the benchmark. |
| 2025-01-03 21:55:29 +0100 | <c_wraith> | is PrimMonad always either ST s or IO? |
| 2025-01-03 21:55:14 +0100 | AlexZenon | (~alzenon@5.139.233.96) |
| 2025-01-03 21:53:44 +0100 | <monochrom> | err, s/bang/seq/ e.g. let n1 = n+1 in seq n1 (writeSTRef v n1) which is what the $! does |
| 2025-01-03 21:53:35 +0100 | <EvanR> | ! is pronounced bang. $! wants to be pronounced whizbang. I say |
| 2025-01-03 21:52:51 +0100 | <monochrom> | There may be a modifySTRef' . If not, you add your own $! or bang, writeSTRef v $! (n+1) |
| 2025-01-03 21:52:39 +0100 | <EvanR> | modifySTRef' |
| 2025-01-03 21:52:38 +0100 | <EvanR> | oh there is |
| 2025-01-03 21:51:54 +0100 | <lambdabot> | a -> IO a |
| 2025-01-03 21:51:53 +0100 | <EvanR> | :t evaluate |
| 2025-01-03 21:51:52 +0100 | <EvanR> | is there an equivalent of evaluate for ST |
| 2025-01-03 21:51:17 +0100 | AlexZenon | (~alzenon@5.139.233.96) (Ping timeout: 244 seconds) |
| 2025-01-03 21:51:01 +0100 | <haskellbridge> | <magic_rb> EvanR no i dont, would be nice to do so |
| 2025-01-03 21:48:36 +0100 | <c_wraith> | If you haven't read https://apfelmus.nfshost.com/blog/2013/08/21-space-invariants.html , start there. Focus especially on the idea that what's useful is linking evaluation. |
| 2025-01-03 21:48:11 +0100 | <EvanR> | if it's like, just a number |
| 2025-01-03 21:48:03 +0100 | <EvanR> | before you modify the ST ref do you make sure to evaluate the value |
| 2025-01-03 21:46:01 +0100 | itscaleb6 | itscaleb |
| 2025-01-03 21:46:01 +0100 | itscaleb | (~itscaleb@user/itscaleb) (Ping timeout: 265 seconds) |
| 2025-01-03 21:45:17 +0100 | rdcdr | (~rdcdr@user/rdcdr) (Ping timeout: 272 seconds) |
| 2025-01-03 21:44:43 +0100 | ft | (~ft@p3e9bc8e9.dip0.t-ipconnect.de) ft |
| 2025-01-03 21:44:18 +0100 | rdcdr_ | (~rdcdr@75-172-28-251.tukw.qwest.net) |
| 2025-01-03 21:43:59 +0100 | <haskellbridge> | <magic_rb> Any tips are greatly appreciated |
| 2025-01-03 21:43:55 +0100 | itscaleb6 | (~itscaleb@user/itscaleb) itscaleb |
| 2025-01-03 21:43:48 +0100 | <haskellbridge> | <magic_rb> Well, i wrote it sooo |
| 2025-01-03 21:43:07 +0100 | ft | (~ft@p3e9bc111.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2025-01-03 21:42:00 +0100 | causal | (~eric@50.35.84.231) causal |
| 2025-01-03 21:40:17 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-01-03 21:38:30 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f650d9e6e69048fea1c.dip0.t-ipconnect.de) acidjnk |
| 2025-01-03 21:37:40 +0100 | <c_wraith> | Just in general, this doesn't look like code that was written to make it easy for users to control evaluation. |
| 2025-01-03 21:35:31 +0100 | <haskellbridge> | <magic_rb> well, a good start would be making the tuple strict |
| 2025-01-03 21:35:09 +0100 | <haskellbridge> | <magic_rb> so something is not strict which ought to be strict? |
| 2025-01-03 21:34:30 +0100 | <c_wraith> | the fact that it's doing 70% of the allocation makes me suspect it's getting the blame for evaluating something that was otherwise getting passed to it unevaluated. |
| 2025-01-03 21:33:56 +0100 | ft | (~ft@p3e9bc111.dip0.t-ipconnect.de) ft |
| 2025-01-03 21:31:58 +0100 | ft | (~ft@p3e9bcb80.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-01-03 21:29:30 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-03 21:05:47 +0100 | <haskellbridge> | <magic_rb> maybe the fact thats it generic over m is whats slowing the whole thing down? |
| 2025-01-03 21:05:33 +0100 | <haskellbridge> | <magic_rb> its an STRef internally running in IO in the end |