25 Mar 2024 |
FromIRC | <emery_> it's never been clear to me if adding a callback to a future is appending or setting a callback, and checking for errors is more work than cps | 20:26:56 |
FromIRC | <emery_> futures are a bad stateful object that solves problems that language should be solving instead, like C++ iterator objects | 20:28:55 |
FromIRC | <emery_> also, cps is better than jumping between stacks, which I couldn't do with solo5 because I can't allocate arbitrary memory regions for more stacks | 20:32:07 |
FromIRC | <emery_> setjmp hacks are neat but only good for hacks | 20:32:52 |
FromIRC | <emery_> I think the proc "coloring" isn't as bad as i thought it initially was, far few procs need to be colored than with asyncdispatch | 20:39:09 |
FromIRC | <disruptek> what else did you expect, and how did cps meet/not-meet those expectations. | 20:40:23 |
FromIRC | <emery_> asyncdispatch made me assume that I have to color everwhere up to the highest abstraction but with cps it stays internal | 20:40:35 |
FromIRC | <emery_> uh... | 20:40:43 |
FromIRC | <disruptek> right. | 20:40:51 |
FromIRC | <emery_> I didn't have to customize Continuation, which I thought I had to | 20:41:16 |
FromIRC | <disruptek> i really, really, really try not to impose that customization. | 20:41:38 |
FromIRC | <disruptek> it's not a requirement of insideout, either. | 20:41:59 |
FromIRC | <emery_> thats a general problem, looking for features and then looking how to use them, rather than focusing on solutions | 20:42:23 |
FromIRC | <disruptek> but it's kinda the other side of the coin; opposite generics. so it's not exactly a win. | 20:42:33 |
FromIRC | <emery_> I haven't looked at performance as yet because I'm more concerned with clean abstractions | 20:42:55 |
FromIRC | <disruptek> what do you expect of the performance. | 20:43:12 |
FromIRC | <emery_> dunno, I expect it to be within margin | 20:44:58 |
FromIRC | <emery_> I remember looking at asyncdispatch internals and being supprised by how much the code was jumping around | 20:45:31 |
FromIRC | <disruptek> memory consumption could be interesting, but it's probably not important in your use-case. | 20:46:13 |
FromIRC | <emery_> I figure memory density with cps isn't great but I don't think I'm making long chains of continuations | 20:46:32 |
FromIRC | <disruptek> right. | 20:47:01 |
FromIRC | <emery_> I want to get a demo and writeup done for april 1st, but now I sleep | 20:51:07 |
FromIRC | <disruptek> aight gn. | 20:51:15 |
FromIRC | <Zevv> well, you got yourself a good and proper user there disruptek | 21:27:02 |
FromIRC | <Zevv> i guess at this point the cps users you *do* get are on the smarter side of the spectrum and can give you some meaningful feedback | 21:29:17 |
26 Mar 2024 |
FromIRC | <disruptek> it seems to be hard for people to grasp the value proposition, or the significance of the choices made, without actually writing software with it. | 01:11:58 |
FromIRC | <disruptek> i think this is why i am both satisfied and unsatisfied with the current impl. it /does/ work well. but after building a bunch of stuff with it, i have a much better sense for how it can work better. | 01:12:57 |
| blackmius joined the room. | 20:17:22 |
varriount | In reply to @leorize-irc-bridge:envs.net <disruptek> i think this is why i am both satisfied and unsatisfied with the current impl. it /does/ work well. but after building a bunch of stuff with it, i have a much better sense for how it can work better. Howso? | 20:44:00 |
FromIRC | <disruptek> as i said earlier: tco, generics, serialization, zero-alloc, cycle-free, with support for sub-procedures and copies. | 22:02:51 |