IRC channel logs
2025-03-06.log
back to list of logs
<andreas-e>Hello janneke! I have read up on the IRC log and notice you fall into the same traps as me :) I have also had problems with "sleep". <andreas-e>Another thing to avoid: nested vats. (with-vat vat ... (with-vat vat ...)) creates a deadlock, as far as I can see. <andreas-e>Then I also used (with-vat vat1 ... (with-vat vat2 ...)) which sort of worked, but slowed things down enormously. <fantazo>do you know of any projects which use goblins? <andreas-e>Which does not work. I notice that in the first link, it uses "define*" to define the actor type. <andreas-e>The second approach works, the first one does not. <andreas-e>If it helps, I can paste a complete example. <andreas-e>If I replace "define" by "define-actor" for ^greeter, the example works (it is a slightly simplified version of the example behind the first link above). <tsyesika>will look in a moment, just in a meeting <andreas-e>With define-actor my code now works in principle. But I realise that I try to persist a ^cell which contains a list of far actors from somewhere else on the network. This does not work, right? <tsyesika>I think what's happened is I was re-introducing the old greeter object from the tutorial and trying to explain why it doesn't persist and I was going to show the persistable version <tsyesika>you need to use define-actor and the greeter in the first link has other problems that I think I was or have talked about. Basically you have this inner `number-of-times` cell, this needs to be included in the portrait either by lifting it up to the constructor or specifying the portrait function using #:portrait <tsyesika>I'll file an issue saying these docs need improving as they're confusing as they currently are <andreas-e>And you agree I cannot persist actors that enter a cell in my vat from elsewhere in the network? <tsyesika>correct, you can persist far-refrs (references to objects in another vat, but on the same machine) using persistence registries, but you cannot persist remote references (references to object across CapTP) <tsyesika>if you'd like to persist remote references, you should probably persist mycapn along with a sturdyref so you can enliven it upon restoration <tsyesika>it is a little annoying having to thread mycapn throughout your code and get sturdyrefs for remote refrs. the mycapn issue could be fixed eventually with something like this: https://gitlab.com/spritely/guile-goblins/-/issues/267 but the greater issue of just wanting to persist remote references is a lot harder to solve. I'm not sure sure how we'd go about that <andreas-e>Thanks! I actually do not *want* to persist these far references, just the list that contains them, and I am even more happy if it remains empty... The goal is to keep the sturdyref the same over multiple runs, not the content of the actor. I have found a dirty trick by setting #:persist-on to #f. <andreas-e>Does the documentation explain how one can "manually" persist instead of on churn? <dthompson>iirc we don't provide any control over when persistence occurs <tsyesika>andreas-e: you can have a custom list actor which doesn't include it's contents in its portrait (or could even filter out remote refrs) <andreas-e>Interesting! But #:persist-on #f seems to work as well and, I suppose, just stores the initial empty list. <andreas-e>In any case, the corresponding .syrup file has been written only on the first invocation and since then remains the same. <andreas-e>And I am very happy with the empty list in my context. <tsyesika>you can technically turn off persistence on churns and use `vat-take-portrait!` to take portraits, you probably don't want to <andreas-e>Thanks for the pastebin code and the explanations! <tsyesika>It's mostly there so that if you want to avoid persistence overhead in performance specific use cases, you can manually control when persistence happens <tsyesika>the issue with using it in this approach is, the vat is taking its initial portrait of the graph, and I'm assuming you'll never call vat-take-portrait! so none of the list entries get persisted. The issue is your graph never changes <tsyesika>if you were to call vat-take-portrait! it'd try and persist the far refrs <tsyesika>it's better to specify the portrait and control what data you want to appear in the graph that way <andreas-e>But in my application I am fine with the graph to not be persisted, this is why I call it a dirty trick. I just want its sturdyref to remain the same.