Newest at the top
| 2024-11-07 14:48:02 +0100 | <[exa]> | but don't, the O(1) for hashmaps is a lie |
| 2024-11-07 14:47:30 +0100 | <[exa]> | tbh there are efficient hashy sets and maps even in haskell in https://hackage.haskell.org/package/unordered-containers |
| 2024-11-07 14:45:12 +0100 | <kuribas> | binary trees, which is are usually used in pure datatypes, have log n operations. |
| 2024-11-07 14:43:38 +0100 | <kuribas> | hashtables use mutation to insert elements. |
| 2024-11-07 14:43:17 +0100 | <Inst> | how do you use mutability to get O(1) access? |
| 2024-11-07 14:42:53 +0100 | <kuribas> | most languages depend on mutability to get O(1). Which is itself a lie, since memory access in a CPU is not O(1). |
| 2024-11-07 14:42:20 +0100 | <kuribas> | Inst: in any case, it's what you get with immutable structures. |
| 2024-11-07 14:42:07 +0100 | <kuribas> | Inst: it mostly depends on constant factors. |
| 2024-11-07 14:42:02 +0100 | sudden | (~cat@user/sudden) sudden |
| 2024-11-07 14:41:58 +0100 | <kuribas> | Inst: O(ln n) is not much different from O(1). |
| 2024-11-07 14:41:43 +0100 | <Inst> | afaik in other languages you can O(1) access objects |
| 2024-11-07 14:41:27 +0100 | <Inst> | tbh what's the deal with O(ln n) for Haskell sets and maps? |
| 2024-11-07 14:39:13 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-07 14:38:50 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-11-07 14:37:58 +0100 | longlongdouble | (~longlongd@117.225.100.25) |
| 2024-11-07 14:36:30 +0100 | longlongdouble | (~longlongd@117.234.146.164) (Ping timeout: 272 seconds) |
| 2024-11-07 14:31:18 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 276 seconds) |
| 2024-11-07 14:30:18 +0100 | sudden | (~cat@user/sudden) (Ping timeout: 252 seconds) |
| 2024-11-07 14:30:17 +0100 | CoolMa7 | (~CoolMa7@ip5f5b8957.dynamic.kabel-deutschland.de) CoolMa7 |
| 2024-11-07 14:24:56 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-07 14:16:11 +0100 | housemate | (~housemate@146.70.66.228) (Read error: Connection reset by peer) |
| 2024-11-07 14:15:57 +0100 | longlongdouble | (~longlongd@117.234.146.164) |
| 2024-11-07 14:15:54 +0100 | pavonia_ | pavonia |
| 2024-11-07 14:15:49 +0100 | pavonia | (~user@user/siracusa) (Ping timeout: 260 seconds) |
| 2024-11-07 14:15:49 +0100 | longlongdouble | (~longlongd@117.234.149.253) (Ping timeout: 260 seconds) |
| 2024-11-07 14:14:27 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Quit: Leaving) |
| 2024-11-07 14:14:02 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-11-07 14:13:22 +0100 | <Inst> | well it's deserved, his article's good |
| 2024-11-07 14:13:04 +0100 | CoolMa7 | (~CoolMa7@95.91.137.87) (Ping timeout: 272 seconds) |
| 2024-11-07 14:11:44 +0100 | pavonia_ | (~user@user/siracusa) siracusa |
| 2024-11-07 14:11:09 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 276 seconds) |
| 2024-11-07 14:07:36 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2024-11-07 14:05:24 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-07 14:04:20 +0100 | CoolMa7 | (~CoolMa7@95.91.137.87) CoolMa7 |
| 2024-11-07 14:03:54 +0100 | CoolMa7 | (~CoolMa7@ip5f5b8957.dynamic.kabel-deutschland.de) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-11-07 14:03:04 +0100 | <geekosaur> | at most the last part, I suspect, but I have this feeling it would be egoboo 😛 |
| 2024-11-07 14:01:56 +0100 | <Inst> | i hope monochrom doesn't have vex.net/~trebla on highlight? |
| 2024-11-07 14:01:43 +0100 | hgolden | (~hgolden@23.162.40.28) hgolden |
| 2024-11-07 14:01:33 +0100 | <Leary> | Inst: That's the most notable paper on the subject, but try <http://www.vex.net/~trebla/haskell/abs-type-param.html> first. |
| 2024-11-07 13:58:13 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2024-11-07 13:58:12 +0100 | <geekosaur> | also I suspect you will run into the problems I described f you do change ghcitui to stream instead of trying to read it all at once |
| 2024-11-07 13:56:22 +0100 | <geekosaur> | (getting it all as a single chunk is the lazy-programmer way 🙂 ) |
| 2024-11-07 13:56:00 +0100 | <geekosaur> | not impossible, just requires some work |
| 2024-11-07 13:55:43 +0100 | <geekosaur> | presumably you'd have to rewrite it to stream instead of reading the output all at once |
| 2024-11-07 13:55:39 +0100 | <haskellbridge> | <zwro> yes |
| 2024-11-07 13:55:29 +0100 | <geekosaur> | that sounds like a ghcitui problem |
| 2024-11-07 13:55:03 +0100 | <haskellbridge> | <zwro> geekosaur: strangely, if i don't hFlush or i disable buffering, the process explodes and consumes all my cpu+memory |
| 2024-11-07 13:54:54 +0100 | <geekosaur> | so yeh, custom ghci build would be needed |
| 2024-11-07 13:54:35 +0100 | <geekosaur> | hm, that may mean you still can't get it to stream because in a pty it'll use `LineBuffering` and you can't tell it otherwise) |
| 2024-11-07 13:53:44 +0100 | <geekosaur> | (note that, if it's not in a pty, you would have to rewrite ghci to disable output buffering; GNU stdbuf only works with GNU libc's stdio, not Haskell's) |