Newest at the top
| 2024-11-12 21:15:52 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 21:15:21 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 21:14:08 +0100 | zenmov | (zenmov@user/dymenshen) dymenshen |
| 2024-11-12 21:10:24 +0100 | jrm | (~jrm@user/jrm) jrm |
| 2024-11-12 21:08:53 +0100 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2024-11-12 21:07:29 +0100 | ft | (~ft@p4fc2a216.dip0.t-ipconnect.de) ft |
| 2024-11-12 21:06:27 +0100 | <EvanR> | mutable stuff can be faster but ghc puts a tax on all mutable refs for gc purposes |
| 2024-11-12 21:05:40 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 21:05:10 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 21:04:45 +0100 | <EvanR> | bailsman, it seems like a fold over an IntMap might be more idiomatic and worth benchmarking (again) |
| 2024-11-12 21:01:45 +0100 | hellwolf | (~user@2001:1530:70:545:ac66:99b5:ab1c:ca1) (Ping timeout: 246 seconds) |
| 2024-11-12 21:00:38 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-12 21:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-12 20:58:15 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-11-12 20:56:26 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-11-12 20:56:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-12 20:55:54 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2024-11-12 20:55:30 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-12 20:55:05 +0100 | <tomsmeding> | bwe: indeed, you put the haddocks on the function where it's defined, and with the not-home haddock option you ensure that the documentation gets generated in the right place |
| 2024-11-12 20:54:59 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-12 20:52:30 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-11-12 20:51:37 +0100 | sprotte24 | (~sprotte24@p200300d16f2cc30041d9df5443f92151.dip0.t-ipconnect.de) |
| 2024-11-12 20:46:51 +0100 | <bailsman> | This kind of thing should start and end with profiling probably |
| 2024-11-12 20:46:45 +0100 | <bailsman> | Does code like this `for_ [0 .. MV.length v - 1)] (MV.modify v f)` have any performance gotchas? I somehow got it into my head that I want to mutate data in place for performance reasons, but I'm slowly starting to have more and more doubts. |
| 2024-11-12 20:42:26 +0100 | <int-e> | oh, one more: unsuccessfullyDupablePerformIO :: IO a -> a; unsuccessfullyDupablePerformIO = error (error "I'm afraid I cannot do that, Dave") |
| 2024-11-12 20:39:45 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-12 20:39:26 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-12 20:39:22 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-11-12 20:37:25 +0100 | arthurvl | (~arthurvl@2a02-a469-f5e2-1-83d2-ca43-57a2-dc81.fixed6.kpn.net) (Ping timeout: 265 seconds) |
| 2024-11-12 20:36:42 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-12 20:35:02 +0100 | <EvanR> | and be willing to find the counterexamples which prove yourself wrong |
| 2024-11-12 20:34:27 +0100 | <EvanR> | and then proving what you did worked |
| 2024-11-12 20:33:58 +0100 | <EvanR> | but this mindset requires respecting abstractions in play, once the game starts |
| 2024-11-12 20:33:20 +0100 | <EvanR> | instead of breaking the system, maybe study ways of constructing a new system which is safe and does the optimizations |
| 2024-11-12 20:32:56 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-12 20:31:23 +0100 | <int-e> | . o O ( unsuccessfullyPerformIO :: IO a -> a; unsuccessfullyPerformIO = error "I'm afraid I cannot do that, Dave" ) |
| 2024-11-12 20:30:31 +0100 | <Rembane> | int-e: ...while studying the dark arts? |
| 2024-11-12 20:29:32 +0100 | <int-e> | avoid success at all cost? |
| 2024-11-12 20:29:13 +0100 | <EvanR> | it's just not that kind of language |
| 2024-11-12 20:29:04 +0100 | <EvanR> | I've never really had any success violating haskell's semantics |
| 2024-11-12 20:28:42 +0100 | <EvanR> | exactly |
| 2024-11-12 20:28:27 +0100 | <bailsman> | I don't though. |
| 2024-11-12 20:28:04 +0100 | <EvanR> | but someone noted the existence of unsafeThaw which is your trap door into "I know what I'm doing" |
| 2024-11-12 20:27:09 +0100 | <EvanR> | since it is |
| 2024-11-12 20:27:06 +0100 | <EvanR> | it certainly would still be treated like a mutable array |
| 2024-11-12 20:26:17 +0100 | <bailsman> | I would like most of the code to be regular normal pure code |
| 2024-11-12 20:25:57 +0100 | <bailsman> | I wonder if that still causes the compiler to think the data is "actually mutable" and disables a ton of optimizations |
| 2024-11-12 20:25:54 +0100 | <EvanR> | which is a different subject from increasing the performance of working with an array |
| 2024-11-12 20:25:33 +0100 | <EvanR> | what I just suggested as in response to "compiler stops me from writing to it when I don't want to, because... I might accidentally write code to write to it for some reason" |
| 2024-11-12 20:24:48 +0100 | <bailsman> | If that's easy to do, why isn't it how freeze/thaw already works? |