Newest at the top
| 2025-11-23 22:36:38 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-11-23 22:36:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-11-23 22:32:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-23 22:23:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-11-23 22:19:51 +0100 | ouilemur | (~jgmerritt@user/ouilemur) (Quit: WeeChat 4.7.0) |
| 2025-11-23 22:17:33 +0100 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-11-23 22:17:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-23 22:16:16 +0100 | Nachtgespenst | (~user@user/siracusa) siracusa |
| 2025-11-23 22:13:09 +0100 | <int-e> | While a FUN is basically just a pointer to a piece of code that can be jumped into once all the arguments are supplied and put on the stack |
| 2025-11-23 22:12:47 +0100 | <[exa]> | *phew* |
| 2025-11-23 22:12:40 +0100 | <[exa]> | ok |
| 2025-11-23 22:12:38 +0100 | <[exa]> | ah yes otherwise it's FUN. |
| 2025-11-23 22:11:28 +0100 | <int-e> | Well, not really because a PAP always has at least one argument applied. |
| 2025-11-23 22:11:12 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-11-23 22:09:35 +0100 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2025-11-23 22:08:16 +0100 | <[exa]> | if I got it right |
| 2025-11-23 22:08:11 +0100 | <[exa]> | oh these are for small functions, like PAP but nicely static without the extra metadata? |
| 2025-11-23 22:07:49 +0100 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 264 seconds) |
| 2025-11-23 22:06:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-11-23 22:03:52 +0100 | <int-e> | (FUN* objects are unapplied; the distinction is made to support function applications in the mutator, not for the benefit of GC) |
| 2025-11-23 22:03:43 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-23 22:03:35 +0100 | <[exa]> | I recall some paper that did like 16 variants of these for all combinations of packed&unpacked things |
| 2025-11-23 22:03:18 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) (Read error: Connection reset by peer) |
| 2025-11-23 22:03:07 +0100 | <int-e> | I should use CONSTR_ for this |
| 2025-11-23 22:03:01 +0100 | <int-e> | hmm |
| 2025-11-23 22:03:00 +0100 | <[exa]> | oh so it's a shortcut essentially. OK |
| 2025-11-23 22:02:42 +0100 | <int-e> | Stuff like FUN_0_1 exists for small arities to avoid this extra lookup. |
| 2025-11-23 22:02:10 +0100 | <int-e> | [exa]: Well stuff like "FUN" looks at more data in the info table to figure out which heap object fields are pointers and which are nonpointers. So it's not *just* the type. |
| 2025-11-23 22:02:08 +0100 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 240 seconds) |
| 2025-11-23 22:01:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-23 22:01:18 +0100 | <int-e> | I think I don't know what your "that" was. |
| 2025-11-23 22:01:04 +0100 | <[exa]> | as in, no other info should be needed, hopefully |
| 2025-11-23 22:00:39 +0100 | <[exa]> | I thought these completely define the pointers handling |
| 2025-11-23 21:59:44 +0100 | <int-e> | evcuate+scavenge are still the main workers for the copying GC |
| 2025-11-23 21:58:43 +0100 | <[exa]> | or no wait that got slashed later, right? |
| 2025-11-23 21:58:39 +0100 | <int-e> | yeah |
| 2025-11-23 21:58:32 +0100 | <[exa]> | that's what the evacuate/scavenge "methods" were for, no? |
| 2025-11-23 21:58:29 +0100 | <int-e> | s/often largely/largely deal/ (editing gone wrong) |
| 2025-11-23 21:58:00 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 252 seconds) |
| 2025-11-23 21:57:36 +0100 | <int-e> | The most prominent use of these closure types is for guiding garbage collection, because that'll often largely with pointers to a heap object and no further information, and then has to enumerate children and/or copy the object. |
| 2025-11-23 21:56:50 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-23 21:53:13 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2025-11-23 21:51:25 +0100 | <[exa]> | cool |
| 2025-11-23 21:51:20 +0100 | <[exa]> | *into |
| 2025-11-23 21:51:04 +0100 | <[exa]> | ah true makes sense, it doesn't cost anything to throw them int to the impl tables and we get inspectable heap |
| 2025-11-23 21:50:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-11-23 21:49:42 +0100 | <[exa]> | oh so this is an indirect tag |
| 2025-11-23 21:48:25 +0100 | gratefulgrapefru | (~greatfulg@user/gratefulgrapefru) (Quit: Client closed) |
| 2025-11-23 21:47:45 +0100 | <EvanR> | is it like tagged union |
| 2025-11-23 21:47:36 +0100 | <int-e> | EvanR: you're it |