Newest at the top
| 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 |
| 2025-01-03 21:04:47 +0100 | <haskellbridge> | <magic_rb> https://paste.tomsmeding.com/2PZ3zHir I've got that implementation of a sparseset, i already sprinkled in INLINEs but i dont quite under stand why im getting the following prof output https://paste.tomsmeding.com/jjgSGOAa sparsesets should be fast, especially with an "exists" query as thats O(1) |
| 2025-01-03 21:01:35 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-03 21:00:41 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-03 21:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-03 20:54:14 +0100 | AlexZenon | (~alzenon@5.139.233.96) |
| 2025-01-03 20:51:52 +0100 | AlexZenon | (~alzenon@5.139.233.96) (Ping timeout: 244 seconds) |
| 2025-01-03 20:48:16 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-01-03 20:47:11 +0100 | ash3en | (~Thunderbi@146.70.124.222) ash3en |
| 2025-01-03 20:45:57 +0100 | ash3en | (~Thunderbi@146.70.124.222) (Ping timeout: 248 seconds) |
| 2025-01-03 20:43:25 +0100 | AlexZenon | (~alzenon@5.139.233.96) |
| 2025-01-03 20:37:55 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-01-03 20:37:17 +0100 | ash3en | (~Thunderbi@146.70.124.222) ash3en |
| 2025-01-03 20:37:03 +0100 | ash3en | (~Thunderbi@146.70.124.222) (Read error: Connection reset by peer) |
| 2025-01-03 20:36:21 +0100 | AlexZenon | (~alzenon@5.139.233.96) (Ping timeout: 248 seconds) |
| 2025-01-03 20:30:19 +0100 | Guest58 | (~Guest58@94.250.89.162) (Client Quit) |
| 2025-01-03 20:29:54 +0100 | Guest58 | (~Guest58@94.250.89.162) |
| 2025-01-03 20:27:25 +0100 | OftenFaded | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-03 20:25:53 +0100 | janvogt | (~janvogt@ip-109-192-067-222.um38.pools.vodafone-ip.de) (Remote host closed the connection) |
| 2025-01-03 20:25:49 +0100 | janvogt_ | (~janvogt@ip-109-192-067-222.um38.pools.vodafone-ip.de) (Remote host closed the connection) |
| 2025-01-03 20:25:27 +0100 | janvogt_ | (~janvogt@ip-109-192-067-222.um38.pools.vodafone-ip.de) |
| 2025-01-03 20:25:12 +0100 | janvogt | (~janvogt@ip-109-192-067-222.um38.pools.vodafone-ip.de) |