Newest at the top
| 2024-05-31 20:38:14 +0200 | andrewboltachev | (~andrey@178.141.226.53) () |
| 2024-05-31 20:36:58 +0200 | bontaq | (~user@ool-45779c03.dyn.optonline.net) |
| 2024-05-31 20:35:17 +0200 | average | (uid473595@user/average) |
| 2024-05-31 20:33:27 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 268 seconds) |
| 2024-05-31 20:33:16 +0200 | fireking04 | (~user@112.206.71.35) (Remote host closed the connection) |
| 2024-05-31 20:27:33 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-31 20:26:06 +0200 | michalz | (~michalz@185.246.207.205) |
| 2024-05-31 20:25:09 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 272 seconds) |
| 2024-05-31 20:10:11 +0200 | bontaq | (~user@ool-45779c03.dyn.optonline.net) (Ping timeout: 264 seconds) |
| 2024-05-31 20:08:11 +0200 | yin | (~yin@user/zero) (Ping timeout: 256 seconds) |
| 2024-05-31 20:00:33 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-31 19:50:39 +0200 | Angelz | (Angelz@user/angelz) |
| 2024-05-31 19:50:39 +0200 | Angelz | (Angelz@2605:6400:30:fc15:d55b:fa6c:bd14:9973) (Changing host) |
| 2024-05-31 19:40:54 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 256 seconds) |
| 2024-05-31 19:37:30 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-31 19:26:41 +0200 | titibandit | (~user@user/titibandit) |
| 2024-05-31 19:26:08 +0200 | andrei_n | (~andrei.n@2a02:a03f:c091:a800:66f8:a011:89:520f) |
| 2024-05-31 19:25:51 +0200 | andrei_n | (~andrei.n@2a02:a03f:c091:a800:66f8:a011:89:520f) (Remote host closed the connection) |
| 2024-05-31 19:24:18 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-31 19:23:56 +0200 | euleritian | (~euleritia@dynamic-176-000-194-148.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-31 19:18:30 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-31 19:05:15 +0200 | srk | (~sorki@user/srk) |
| 2024-05-31 19:02:00 +0200 | ridcully | (~ridcully@p508ac2b4.dip0.t-ipconnect.de) |
| 2024-05-31 19:01:43 +0200 | ridcully_ | (~ridcully@p508ac2b4.dip0.t-ipconnect.de) (Quit: WeeChat 4.2.1) |
| 2024-05-31 19:00:53 +0200 | heartbur1 | (~gass@81.4.123.134) (Read error: Connection reset by peer) |
| 2024-05-31 18:58:29 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-05-31 18:55:48 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2024-05-31 18:55:32 +0200 | <geekosaur> | StateT is (s -> (s,a)), ReaderT is (r -> a) |
| 2024-05-31 18:51:22 +0200 | <andrewboltachev> | aha |
| 2024-05-31 18:50:53 +0200 | <geekosaur> | it's usually optimized away since they're very simple wrappers |
| 2024-05-31 18:50:16 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-31 18:50:15 +0200 | <andrewboltachev> | Is using StateT/ReaderT fast? Or that's not how people handle that |
| 2024-05-31 18:49:21 +0200 | <geekosaur> | although exponential is more common |
| 2024-05-31 18:49:04 +0200 | <geekosaur> | algorithm also matters, if you've accidentally done something like Ackermann it'll really suck with large inputs |
| 2024-05-31 18:48:32 +0200 | euleritian | (~euleritia@dynamic-176-000-194-148.176.0.pool.telefonica.de) |
| 2024-05-31 18:48:24 +0200 | <andrewboltachev> | wow I don't have to use '@' sorry |
| 2024-05-31 18:48:13 +0200 | zmt00 | (~zmt00@user/zmt00) |
| 2024-05-31 18:47:50 +0200 | <lambdabot> | Unknown command, try @list |
| 2024-05-31 18:47:50 +0200 | <andrewboltachev> | @geekosaur: yes. might be! I have a tree-like data structure. When I have array of 16 (big) items, and process one by one, it handles very quickly. But 16 items together in an array, and wrapped in another thing (I use Vector) just hangs |
| 2024-05-31 18:47:37 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 272 seconds) |
| 2024-05-31 18:45:10 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2024-05-31 18:44:48 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-05-31 18:44:19 +0200 | <geekosaur> | which is likely if you're running it in ghci |
| 2024-05-31 18:44:09 +0200 | <geekosaur> | that, or you're just very unoptimized |
| 2024-05-31 18:42:59 +0200 | <geekosaur> | that is, they appear to have data dependencies that might not exist, leading to excessive recomputation? |
| 2024-05-31 18:42:38 +0200 | <geekosaur> | although your problem sounds more like it's reprocessing stuff, which may mean you have code that's being interpreted as functions |
| 2024-05-31 18:42:35 +0200 | <lambdabot> | https://wiki.haskell.org/Learning_Haskell |
| 2024-05-31 18:42:35 +0200 | <andrewboltachev> | @Leary thanks. Will try |
| 2024-05-31 18:40:34 +0200 | <Leary> | andrewboltachev: I don't know about memory limits, but code interpreted by ghci isn't optimised. If you actually compile the code with -O and run the binary, it should execute many times faster and will likely use less memory too. |
| 2024-05-31 18:39:51 +0200 | fireking04 | (~user@112.206.71.35) |