IRC channel logs

<ridley>Can someone explain why OCapN allows returning a Promise, which then needs listening to?

<ridley>My understanding is that when a request is made, we always set up a promise on the requester’s side to wait for the response which is expected to come in at some point in the future (but during the same session).

<ridley>It feels like accepting a promise returned over OCapN is like saying “I was already expecting a result in the future and now you are sending me a message telling me to expect a result in the future. And that if I’m interested in that future result then I need to send you another message telling you I want it.”

<ridley>What advantage does this provide over just responding once we actually have the fulfilled value ready?

<tsyesika>promises are values just like any other in OCapN and so a promise can always be fulfilled with another promise

<tsyesika>I don't think there's a specific reason, other than they can :)

<ridley>Can you provide an example of where this would be helpful? I am familiar with fulfilling promises with promises in a non-distributed environment, but I am confused as to the value in a distributed environment where there is the extra cost of network calls.

<tsyesika>I think you could probably design an implementation which only ever resolves an op:deliver to an concrete value, refr or error. But sometimes either to make implementing it easier or because for example an object may have returned a promise from the message delivered, it's easier to fulfil it with a promise

<tsyesika>I unfortunately have to go afk for a while

<ridley>No worries thanks for responding

<ridley>I see now that relevant discussions were had at the latest OCapN meeting

<trannus_aran>I don't suppose anyone here uses guix on an RPM-based foreign distro, yeah?

<trannus_aran>ACTION pokes her head in

<jfred>not I, sadly (though on lots of Debian boxen)

<trannus_aran>looks like it's working now!

<trannus_aran>I gotta make a PR to update the docs for those of us on fedora :P

<trannus_aran>semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil && mount -o remount,rw /gnu/store && restorecon -R /gnu /var/guix && systemctl restart guix-daemon.service

<trannus_aran>that seems to do it haha

<dthompson>trannus_aran: yay glad it's working!

<sneek>Welcome back dthompson, you have 1 message!

<sneek>dthompson, jlicht says: I'll be pushing a new version of node to guix master in the near future; is there a guix time-machine invocation I can use to check for any spritely-stuff breakage?

<dthompson>jlicht: I don't have a time-machine invocation handy but it's unlikely a node upgrade would break anything unless you someone disabled the wasm engine or something.

<trannus_aran>dthompson: ahhh, spoke too soon. Name resolution failures for both ci & bordeaux, so guix pull fails ;/

<trannus_aran>(I won't crowd up the chat anymore with this tho!)

<dthompson>hmm idk why that is, but you could ask in #guix if servers are down or something

IRC channel logs

2025-04-09.log