IRC channel logs
2024-09-04.log
back to list of logs
<dpk>it is possible to run a Scheme REPL in the browser with Hoot? <andreas-e>Hello! Is there a way to non-blockingly test in Goblins whether a promise is resolved? <dthompson>dpk: good timing on this question! it will be possible in the upcoming release. wingo has been working hard on getting 'eval' to work and I quickly wired it up to a web interface last night. <dthompson>our interpreter will be limited for now as we don't have the full macro expander implemented, so no user-defined macros yet. <dpk>great, time to write my own macro expander :D <dpk>(only half joking there …) <dthompson>the next release will have the real expander. <dthompson>it's just a complicated thing so we focused on a basic eval first <dthompson>andreas-e: no you can't ask if a promise is resolved <dpk>i could do such a good joke right now and just jump on Twitch and let you all watch me working on my own syntax-case implementation :D <dpk>unfortunately i have never streamed on Twitch and it seems complicated so let’s not bother :D <andreas-e>Hm, this is annoying; it would be a solution to my problem of distributing computation tasks from a server to a number of clients. The idea is that I send out the tasks and immediately get back a list of promises. Then if one of them resolves, I can retrieve its value and send the next task to the client which is now idle. <andreas-e>My first idea was to use not all-of*, but something that could be called some-of*. <andreas-e>Then I have no idea how to solve the problem. I need a means of non-blockingly query which clients are idle, so that I can schedule the tasks. Maybe one option would be that at the end of a task, I client would report itself back as idle now. It might work, but also feels rather twisted. <dthompson>dpk: streaming on twitch is pretty easy actually thanks to OBS <dthompson>andreas-e: so you'd want to use 'on' to handle the promises in the way you need. I agree that 'all-of' isn't a good fit because you don't want to wait for them all. <dthompson>upon fulfillment of one promise you'd send more work. <dthompson>the actor that is coordinating this would have some queue it's pulling tasks from <andreas-e>Exactly! But how do I test whether one of a set of promises is fulfilled? Because I do not know in which order the promises will be fulfilled. I do not think I can use "on" because it blocks. <dthompson>'on' will register a handler to be called upon fulfillment. that's what you want. <andreas-e>Oh, I see; so the fulfilled-handler could put the client back in the idle queue (which would require passing the client identity as additional parameter through some function calls); this is an interesting solution. It is a bit similar to what I have sketched above, where at the end of its task the client reregisters itself with the server, except that it happens in the server itself. I will give it a thought, thanks a lot! <dthompson>dpk: btw the main branch has all the eval stuff if you want to try it out. (hoot eval) is the module and (hoot interaction-environment) has the proc for constructing a reasonable top-level env <andreas-e>Well, I am too enfused with C; instead of passing "global" variables as function parameters, I suppose I may as well consider them captured in a closure. So the fulfilled-handler has access to the client itself already. <dthompson>yes, lexical scope is your friend (and your security model) :) <jfred>ahhh all this chat has me wanting to play around with Goblins some more again <jfred>I haven't had all that much motivation for side projects lately though, and setting up my Pocket Reform has taken up a chunk of that XD