IRC channel logs
2025-03-10.log
back to list of logs
<andreas-e>What is the type of things I get out of an inbox actor? Is it always a local promise, or can it also be an object if the inbox is not empty when queried? <andreas-e>More precisely, at some point in time I want to run "on" on stuff that come out of the inbox. <tsyesika>it can be an object or other value if the inbox has one ready to hand you <andreas-e>Thanks, that is bad news! So I need to distinguish types using local-promise-refr?, I suppose. But actually I was using "all-on*" on a list of things coming out of the inbox, so I do not see how to solve this easily (looking at the definition of all-on will probably give an answer). <tsyesika>you can pass a non-promise value into `on` and it'll work fine <tsyesika>`(on 'foobar (lambda (my-foobar) ...))` works as you might expect <tsyesika>all-of should also accept non-promise values as it's just using `on` behind the scenes <andreas-e>Ah, excellent! That indeed completely solves my question. <janneke>i read the ticker/ticky in the manual and wondered if the "if an actor implements a method" was something generally usable/available <janneke>however, it now seems to me that my specific "problem" is better handled in another way <dthompson>janneke: there's nothing built-in to the actor model that allows that kind of introspection. for many reasons, references to actors are opaque. <janneke>dthompson: thanks, i guess that makes sense <binarydigitz01>is the example for tor ocapn updated? I've been trying to run the server program (bob) as is, but i've been getting errors... <jfred>That is old and from the Racket days of Goblins so it doesn't translate 1:1 to guile-goblins, but... :) <regtur>jfred: I am actually looking into declaring interfaces including their behavior/protocols for the actor model and to have contacts derived from them checked both at runtime, but also by a model checker. <regtur>In the meantime, how would we handle "No such method"? <juli>For the time being, `#:catch` or equivalent and then checking the message or the exception object. <juli>(pondering) It might be worth defining a unique exception object for error-handling code to match on... <jboy>I am experimenting with persistence, and now the RNG seems to have turned deterministic. Is that to be expected? <tsyesika>jboy: not sure I understand what you're doing. what's the random number generator you're referring to? <jboy>I'm calling guile's random function to select an element at random from a list to (re-)name my actor. This works fine, but after a few runs, random generates the same number over and over. <tsyesika>that shouldn't be the case, I don't know why aurie would be having any impact on that <tsyesika>sorry the persistence system (aurie is the internal codename) <jboy>thanks, I suppose the error is somewhere else then! <jboy>haha, apparently just a general guile lesson I had to learn: "Note that the initial value of *random-state* is the same every time Guile starts up. Therefore, if you don’t pass a state parameter ... you’ll get the same sequence of “random” numbers on every run." <old>but that's the same for every pseudo-random library no? <jboy>python sets the state automatically <tsyesika>sorry the persistence system (aurie is the internal codename) <tsyesika>oops :) I alt tabbed to the wrong window xD <tsyesika>(then pressed up and enter thinking it was my terminal) <dthompson>jboy: yup, gotta seed the PRNG first if you want different results each run. <regtur>juli: Thanks for referring me to the on #:catch (I missed that), but guile still prints a back trace. I guess I want to override no-such-method, is that possible tsyesika? <ridley>I’ve been trying to understand some of the ocapn design decisions. <ridley>Overall I feel like the documentation has been pretty helpful, so big congrats on that. <ridley>There is something I can’t figure out though. It seems that objects have a unique identifier through sturdyrefs, which contain all necessary info to message that object. But then instead of using sturdyrefs for message delivery, it looks like they are only being used to bootstrap into a session-specific identifier on the import/export table which <ridley>is then used for delivery. Why the extra round trip for bootstrapping if we already have an identifier for the object? <ridley>Does an object importer become aware of the sturdyref to reconnect to that object if/when the session is closed? If so, how? <ridley>You are all smarter than me so I know there must be reasons for these things. I just can’t figure out what they are. <tsyesika>Sturdyrefs are generally things you can bootstrap OCapN connections with, but once you have them you can share references to other objects in band. Most objects within a OCapN session don't typically have sturdyrefs <tsyesika>sturdyrefs are also something explicitly given out <ridley>So if most objects don't have sturdyrefs, when a session fails, how do they get reconnected? By bootstrapping some object that does have a sturdyref that'll then re-reference them? <tsyesika>of course you could build an application where you register a sturdyref of all the objects shared, but that's not a typical case <tsyesika>you might for example have a sturdyref to the chatrooms you join, but the user objects within them you might learn by asking the room who's in it upon connection <dthompson>yeah sturdyrefs are how you get into an ocapn network for the first time. they're an out-of-band capability <ridley>Is a goblins object aware of its own sturdyref or how are they managed in goblins? <dthompson>to create a sturdyref, you register an object with a netlayer <ridley>Okay so the mycapn manages the sturdyrefs then <dthompson>you could have the same object accessible via many sturdyrefs if you wanted <dthompson>so the object doesn't know anything about them. there's a separate registry. <ridley>I guess this gives application developers a bit more control over object access then too since you can decide what is bootstrappable. <ridley>Coincidentally this also helps me understand third party handoffs better because I was confused about all the rigamarole when you could just pass a sturdyref. But with an updated understanding of what sturdyrefs are for I see why they are necessary. <dthompson>I should clarify that by "many sturdyrefs" I meant for many different netlayers. you couldn't have many different sturdyrefs to an object using the same netlayer. <ridley>Has there been progress on the multiple netlayer thing? I've been reading through some of the old minutes where it was being discussed but haven't made it to present time yet <ridley>Is it still a possibility in the future or has it been decided against? <tsyesika>goblins supports multiple netlayers but goblins' CapTP right now will only share handoffs which work over the netlayer being used. We also don't currently have a way of encoding multiple netlayers within in one sturdyref <tsyesika>it's a possibility for the future and something I'm looking forward to us working on :) <ridley>one more question if that is okay <ridley>reading on third-party handoffs, it seems to me that they rely on all sessions being live for the handoff to complete. If there is some sort of store-and-forward netlayer being used, will that potentially cause a lot of handoffs to break? <regtur>tsyesika: thanks, it took me a while but I finally figured out, by just reading the code in methods.scm, how to apply you hint and avoid the no-such-method exception. <tsyesika>ridley: potentially a store and forward netlayer could mean they don't all have to be online, but 3rd party handoffs are designed assuming they all are <tsyesika>not sure quite the impacts of store and forward on all mechanisms until we implement one, it might not be a solution to this <ridley>okay, that fits with what was going on in my brain <ridley>thanks for helping me understand the things <jfred>dthompson: and now a merged pull request, at that! <dthompson>jfred: now I need to figure out how to build and run webkit locally so I test this and see if things work now if there are more layers to this onion