Newest at the top
| 2024-10-24 22:19:46 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-24 22:13:28 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-10-24 22:11:29 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-10-24 22:09:14 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-10-24 22:07:53 +0200 | spew | (~spew@185.153.177.94) spew |
| 2024-10-24 22:07:14 +0200 | michalz | (~michalz@185.246.207.201) (Remote host closed the connection) |
| 2024-10-24 22:06:19 +0200 | spew | (~spew@201.141.99.170) (Ping timeout: 260 seconds) |
| 2024-10-24 22:04:00 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-24 22:02:52 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 244 seconds) |
| 2024-10-24 22:02:49 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-10-24 22:02:44 +0200 | hgolden | (~hgolden@169.150.203.36) hgolden |
| 2024-10-24 22:02:40 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-10-24 22:02:39 +0200 | briandaed | (~root@185.234.210.211) (Remote host closed the connection) |
| 2024-10-24 22:01:37 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-24 21:56:46 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-10-24 21:56:28 +0200 | euleritian | (~euleritia@dynamic-176-007-144-063.176.7.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-10-24 21:56:09 +0200 | euleritian | (~euleritia@dynamic-176-007-144-063.176.7.pool.telefonica.de) |
| 2024-10-24 21:55:57 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-10-24 21:55:55 +0200 | hgolden_ | (~hgolden@static-198-44-129-115.cust.tzulo.com) (Ping timeout: 264 seconds) |
| 2024-10-24 21:53:21 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-24 21:52:06 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-10-24 21:51:49 +0200 | euleritian | (~euleritia@dynamic-176-007-144-063.176.7.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-10-24 21:50:15 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-24 21:48:37 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-24 21:44:56 +0200 | sojuro | (~sojuro@syn-069-206-166-125.res.spectrum.com) |
| 2024-10-24 21:40:53 +0200 | <geekosaur> | I also know they were finding out that replacing ghc's memory manager is a major project |
| 2024-10-24 21:39:20 +0200 | <geekosaur> | I know that someone was poking at using a different memory manager with ghc, but it wasn't perceus |
| 2024-10-24 21:38:48 +0200 | <geekosaur> | exactly |
| 2024-10-24 21:38:43 +0200 | <mauke> | but that's very different from ghc's memory manager |
| 2024-10-24 21:38:29 +0200 | <mauke> | geekosaur: perceus/koka does the in-place optimization, doesn't it? |
| 2024-10-24 21:37:36 +0200 | <mauke> | which is something like a log(n) cost, assuming your tree is balanced |
| 2024-10-24 21:37:23 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-10-24 21:36:58 +0200 | <mauke> | in trees, everything "above" the replaced element has to be recreated (i.e. all the nodes back up to the root of the tree), but everything else can be reused |
| 2024-10-24 21:36:51 +0200 | <zzz> | right |
| 2024-10-24 21:35:25 +0200 | <mauke> | trees work the same way, only there are two "rest" parts |
| 2024-10-24 21:35:17 +0200 | <geekosaur> | iirc the cost of the accounting needed to prove that an in-place update is safe would be higher than assuming it's not |
| 2024-10-24 21:35:08 +0200 | <mauke> | more specifically, the initial part (up to the second element) of the list has to be recreated, and everything further "down" can be reused as is |
| 2024-10-24 21:34:55 +0200 | <zzz> | mauke: i understand that |
| 2024-10-24 21:34:45 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-10-24 21:34:45 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-10-24 21:34:21 +0200 | <mauke> | corresponding to the (:) |
| 2024-10-24 21:34:01 +0200 | <mauke> | rest can be reused, but two new nodes are allocated |
| 2024-10-24 21:33:53 +0200 | <zzz> | so no low level optimization? i can't reason about performance in these cases, it's way beyond my understanding of Haskell |
| 2024-10-24 21:33:42 +0200 | <mauke> | replacing ("updating") the second element of a list |
| 2024-10-24 21:33:21 +0200 | <mauke> | simplified example using lists: replace2nd :: a -> [a] -> [a]; replace2nd x (h : _ : rest) = h : x : rest |
| 2024-10-24 21:32:29 +0200 | <zzz> | i see |
| 2024-10-24 21:31:43 +0200 | <geekosaur> | but the popinters to other limbs can be reused |
| 2024-10-24 21:31:34 +0200 | <geekosaur> | the point here is that everything is immutable, so an entire tree limb in either case will be replaced which requires the path to that limb to be replaced |
| 2024-10-24 21:31:29 +0200 | <int-e> | Unused old parts will eventually be garbage collected. |
| 2024-10-24 21:31:11 +0200 | <int-e> | You construct new trees, reusing parts of old trees. The new parts are freshly allocated on the heap. |