| 22 Mar 2024 |
 FromIRC | <Zevv> locals get lifted so memory localization is worse | 05:01:07 |
| FromIRC | <Zevv> and your code gets split into n little functions, so there are less assumptions the compiler can depend on | 05:01:49 |
| FromIRC | <Zevv> otoh: first measure | 05:02:19 |
| FromIRC | <Zevv> in practice, this has not yet hit me. tight inner loops that dont call out to CPS are left as they were | 05:03:05 |
 varriount | I wonder if the compiler could support a kind of "optimizations API" that would allow CPS code generation to create iterators, and actually say "yes, these are only going to be run once, in-order". | 06:41:52 |
| varriount | Zevv: What are you currently using CPS for? | 06:42:38 |
| FromIRC | <Zevv> nothing, actually. | 06:58:19 |
| FromIRC | <Zevv> im not nimming at all. i just hang around here for the sick jokes and frgrancy of social awkwardness | 06:59:03 |
| FromIRC | <disruptek> varriount: which compiler. | 12:46:53 |
| 25 Mar 2024 |
| FromIRC | <emery_> yet another CPS dispatcher https://git.sr.ht/~ehmry/solo5_dispatcher | 17:08:13 |
| FromIRC | <emery_> I'm sitting on a Solo5 unikernel port for Nim, I can port it over to Nimskull as well | 17:08:40 |
| FromIRC | <emery_> still working out the bugs in the TCP stack | 17:09:39 |
| FromIRC | <disruptek> was it hard to do. | 17:10:10 |
| FromIRC | <emery_> not at all, solo5 just has timers and nonblocking read on ethernet devices to worry about, so it was a lot easier than trying to make it work with asyncdispatch | 17:17:11 |
| FromIRC | <disruptek> do you have any recommendations for how we should convey this to other users who are intimidated by the prospect of authoring a dispatcher. | 17:50:42 |
| FromIRC | <Zevv> yeah excellent question | 18:19:50 |
| FromIRC | <Zevv> the thing is, it *is* not hard to do. | 18:19:56 |
| FromIRC | <Zevv> we've made a dozen by now. | 18:20:01 |
| FromIRC | <Zevv> yours are complicated only because of the threading involved | 18:20:20 |
| FromIRC | <disruptek> we're obviously missing /something/. | 18:28:21 |
| FromIRC | <Zevv> people don't want to make dispatchers | 18:32:09 |
| FromIRC | <Zevv> they want ready made ones with documentation | 18:33:25 |
 saem | Maybe the word dispatcher is scary, try calling it a run-loop or some more benign sounding thing. | 18:40:24 |
| FromIRC | <Zevv> CPS also sounds scary | 19:53:56 |
| FromIRC | <Zevv> cally it something fuzzy and warm | 19:54:11 |
| FromIRC | <Zevv> like 'monad' or something | 19:54:18 |
| FromIRC | <emery_> well initially I thought I was going to use a Continuation type from one library and then define my own for my application and do handoffs from one type to another, and choosing a dispatcher was a big deal | 20:21:58 |
| FromIRC | <emery_> but now I just think of CPS as some calling code later, with slightly different environment than a {.closure.} | 20:22:55 |
| FromIRC | <emery_> my syndicate library is ported over to nim-sys but I don't expose CPS through the library API, it's just used internally for scheduling | 20:24:31 |
| FromIRC | <emery_> in short, using the {.cps.} and {.cpsMagic.} in a few places is easier than allocating futures and setting callbacks on them | 20:25:52 |
