IRC channel logs
2023-06-07.log
back to list of logs
<Zarutian_iPad>fr33domlover: re promise pipelineing: it works transparently with both Promise<T> and T being the target of the eventual send <Zarutian_iPad>but for Promise<T> as an argument you need to either use `(on …)` to await the resolvement of it or port my awaitSomeArgsFor-Function/-Method helper <Zarutian_iPad>or assure yourself that the targeted actors method behaviour only does `(<- ..)` eventual sends on the argument in question. <fr33domlover>I just realized something annoying while implementing ActivityPub-based actors: There's no standard way in AP to return a delayed result AKA fulfill a promise. It means that Activity handlers must either instantly return a result, or use an Activity later to report the result. Doing the latter using standard activities would result in huge clutter <fr33domlover>of Accept activities being sent all the time, and implementations having to figure out what sort of object is being accepted. Alternatively, I can introduce a custom Return activity for this purpose... even then, I'd have to manually implement the promise-tracking mechanism in the app's DB... ugh <fr33domlover>Why does promise pipelining apply onlyto returned promises, and not to ones pass as arguments? If I `(define c (<- car getColor))` and then somehow `(<- car setColor (+ c 1))`, wouldn't it allow to send both invocations in a single network transmission, and for `alice` to execute both invocations without needing to wait for network in between? <fr33domlover>Since the result of the 1st invocation is used as a parameter in the 2nd one <Zarutian_iPad>iff that procedure were to be augmented multiple dispatch style to handle promise arguments by basically do, in your example, `(<- c ‘+ [1])` then it would work <Zarutian_iPad>I think lisp such as guile scheme is eminently suitable for this kind of extending if you do not mind where and when the actual computation or parts thereof happen <Zarutian_iPad>which impinges on confidentiality and who-knows-what kind of considerations <Zarutian_iPad>who knows what as in which partyhas access to which information <fr33domlover>Zarutian_iPad: thanks. Asking because the Goblins docs talk only about pipelining on capabiliies returned from methods, not ones passed as arguments. Perhaps it's not implemented yet? <fr33domlover>Also: How do decide how many Vats to have in my application? Options I see: (1) have a single Vat per process, which means the entire local state is consistent but events are handled sequentially, which might severely reduce reactivity/speed because there's no concurrency? (2) maximize amount of vats to allow maximum concurrency, by having <fr33domlover>vat-per-actor as the default, and have actors spawn helper actors in the same vat as needed <Zarutian_iPad>hmm? it has not been implemented in goblins and I do not know if it will <cwebber>fr33domlover: yup, no promises in AP <cwebber>it's something I would think would be important as an extension in retrospedt <cwebber>fr33domlover: there's no direct answer to "how many actors should go in a vat"... it's mostly "what makes sense for the division of labor" <RandyFarmer[m]>1) contextual encapsulation - the actors understand each other and share context. <RandyFarmer[m]>2) a functional boundary, specifically a non-blocking event loop and message stack. <RandyFarmer[m]>For a good example of how #2 applies, perhaps dthompson can talk about how they isolated the ui in the Community Garden app. <vvvvmvr[m]>I wouldn't see vats as threads, right? Because they do sync with each other ultimately. Likely not really for concurrency? <dthompson>"contextual encapsulation" really resonates with me. in both the community garden demo and fantasary, our lisp game jam entry that we just published on sunday, the client application uses 3 vats: 1 vat for the UI, 1 vat for the game objects themselves, and 1 vat for ocapn. <dthompson>those vats represent different layers: UI, data model, and network. <dthompson>there are different approaches you can take, but I keep finding myself organizing things in layers. <dthompson>UI vats often need to be specially integrated into the UI framework, so multiple vats can be a technical necessity, not just an organization tool.