IRC channel logs

2023-03-29.log

back to list of logs

<jar286>I'm having 'office hours' here at 11 (11 EDT Wednesday 29 March). Anything having to do with meetings, issues, direction, policy, etc.
<jar286>I know I will probably have to announce it more widely and with more lead time. Consider this a dry run. (We actually did this impromptu a week ago and it worked pretty well.)
<tsyesika>is there anything you are wanting to discuss today?
<jar286>You and I might touch base at 10:30 - I will need to review my notes to see if we do... oh I guess that's 10 minutes from now. hang on
<jar286>(do need to)
<jar286>looking at the chat from the open PR I see "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." ??
<tsyesika>which is this?
<jar286>I'm back...
<jar286>the admin thing that seems most pressing is expanding github repo access.
<jar286>My inclination is to have access be by request to me for the next month. THen we can review at the April meeting & do something different if we want
<jar286>I already gave Dan 'write' privs. Nobody else has asked for access yet as far as I know, even if there is broad sentiment for opening it up
<jar286>tsyesika: r u there?
<tsyesika>sounds good
<tsyesika>I agree, it probably makes sense for folks to ask if they want access
<tsyesika>I'm here
<jar286>ok.... well that was easy
<jar286>how are things going?
<tsyesika>things are going well! I've addressed some of the feedback on the syrup spec and the CapTP document is going well
<tsyesika>I've also updated the ocapn.org website with the feb meeting minutes. I plan to address the feedback to march's minutes before the end of the wek
<tsyesika>*week
<jar286>I tried to follow my own "how to review the minutes" instructions and that's when I saw that comment about an unknown branch. https://github.com/ocapn/ocapn/blob/main/meeting-minutes/README.md
<jar286>maybe it doesn't matter. probably doesn't.
<jar286>just had never seen it before.
<tsyesika>hm strange, I'm not sure
<jar286>I will probably have things to say about the drafts but I'm going to try to hold my tongue until I can see them
<Zarutian_iPad>tsyesika: hi! you know what I an on about reminding you ;-)
<tsyesika>:) It's on my queue
<tsyesika>I'd be curious what you think you might have to say :) but I suspect everyone will have lots of feedback on them
<jar286>Ill hang around til 11 or so in case anyone read my invitation
<Zarutian_iPad>so, going on imperfect knowledge and over extended inference I say your comments on agoric slash endo smallcaps that are o. top of JSON will be somewhat illuminating
<Zarutian_iPad>jar286: pardon. Might have missed that invitation or mention of it,
<jar286>'office hours' nothing fancy or planned
<Zarutian_iPad>well, one thing I have come across when I start to point folks to ocaps that lot of the material is just wall of text in their eyes
<Zarutian_iPad>so I have started to put together https://gist.github.com/zarutian/ec15de4eb4780ae6e6c8f7ad1d2d49f6
<Zarutian_iPad>which is an interactive narrative written in somewhat whimsical tone
<jar286>Is there a place to talk about ocaps generally? ocapn has a fairly narrow focus. THe spritely forums have been good I think
<jar286>I mean, no reason not to talk about it here
<Zarutian_iPad>#erights and #spritely
<jar286>but when I'm in ocapn land I tend to be pretty narrowly focused
<jar286>of course
<jar286>I didn't know about #erights
<Zarutian_iPad>getting back on topic of ocapn
<Zarutian_iPad>one thing I been aiming for is splitting the captp into levels, each not needing much ‘hacktivation’ energy to implement
<jar286>you mean like chat + 2party + 3party ...? or levels of serialization? ...
<jar286>I'm glad to see others have my concern about 'implementability'
<Zarutian_iPad>starting with syrup then ontop of that 2 party captp then ontop of that using the E way of having NonceLocators on either end being the ‘bootstrap’ object
<jar286>(I always think back to the introduction of HTTP and HTML. In a week or two I had my own client and server. So easy)
<Zarutian_iPad>and having 3rd party handoff as two methods on it. .provideFor() and ,acceptFrom()
<jar286>ah
<Zarutian_iPad>s/,a/.a/
<Zarutian_iPad>plus what CapTP of E calls Promise3Desc which is the words of Alice telling Bob about Carol on VatC
<Zarutian_iPad>jar286: had similiar experience of implementing an IRC bot just from reading the apropos rfcs on the protocols when I was 12-14 years old
<jar286>I'd be interested in reading a description of the 2party bootstrap
<jar286>oh you gave a url
<jar286>wondering what you do with a .ink file
<Zarutian_iPad>the description is pretty short.
<Zarutian_iPad>re .ink run in it in an ink interpreter, one such is linked as the first comment in that .ink file
<Zarutian_iPad>might clobber an github.io thing for it later
<Zarutian_iPad>in 2party bootstrap in CapTP of E the NonceLocators at each end have, canonically, export position 0
<Zarutian_iPad>that is it.
<Zarutian_iPad> http://erights.org/javadoc/net/captp/jcomm/NonceLocator.html shows that lookupSwiss() method on NoceLocators is what is used to turn sturdyrefs to objects hosted on the vat where the NonceLocator is
<Zarutian_iPad>so basically all live refs over an captp connection arise from invocations on NonceLocator lookupSwiss() or acceptFrom() or invocations on methods on objects gotten from there or other such invocations
<jar286>got distracted sorry!
<jar286>not used to irc
<jar286>I'm using a client that's not giving notifications and I'm not sure I want notifications...
<Zarutian_iPad>it is par for the course for IRC so no worries
<jar286>well I said I'd be having office hours and then I cut out 5 minutes in
<Zarutian_iPad>notifications are something I have prune as much as I can out of my life
<jar286>I got a phone call. Now we know who has the real influence. (phone callers)
<Zarutian_iPad>“we have been trying to reach you regarding your car battery pack warranty” kind of call?
<jar286>no, a call I wanted
<jar286>from someone at MIT in an office that has a bunch of my old books which I don't want to just lose (or maybe I do)
<Zarutian_iPad>ah, book logistics thing
<jar286>I've moved so I have some more space, but I think I'd prefer to give away about 90% of them
<jar286>e.g. 'VAX Architecture Reference Manual'
<Zarutian_iPad>but the hard question is which ones
<jar286>I can tell which ones I feel good about. 'Introduction to commutative algebra' is not one of them but 'design of an optimizing compiler' is (sentimental reasons, I don't think I'll ever have a need to read it again)
<Zarutian_iPad>sorry, my english vocabulary fails me. What is ‘commutative algebra’?
<jar286>graduate level mathematics course
<Zarutian_iPad>ah right, ‘commutative’ means that the order of operations often do not matter. Just sounds strange that there is a subfield of algebra for it
<Zarutian_iPad>so back to captp discussion, I am still mulling over where the capnproto embargo disembargo stuff should sit
<jar286>yes it turns out there's a lot to say about it. This is a course that follows ring theory, modules, galois theory, and so on. I didn't really get it the way I did the earlier stuff
<Zarutian_iPad>that whole mechanism is as far as I can tell meant to preserve ordering of messages/invocations flowing from the ref holder end towards the object end of eventual reference
<jar286>I don't know about it but would be happy to learn. Remember I probably have less technical captp chops than most other people in the group
<jar286>right there's a whole discussion about message orders.
<Zarutian_iPad>glaois theory stuff was gone into a bit in control systems class but I have no idea what is meant by rings or modules in that context.
<jar286>and now I think the question is whether there should be any attempt to support any order at all.
<Zarutian_iPad>I can break it down into the example that Alice wants Bob to have access to Carol only after she has sent .foo() invocation to Carol
<Zarutian_iPad>s/she/she, Alice,/
<jar286>ring = field without division
<jar286>I don't see the value in that (11:51:06)
<Zarutian_iPad>howso?
<jar286>why does Alice want that and why does she expect it to make a difference to Carol or Bob?
<Zarutian_iPad>Alice is basically granting Bob access to Carol post .foo() effects.
<jar286>Oh I see. She has to send out two messages, and if Bob gets access too soon bad things could happen because he can squeeze in between them. But why doesn't Alice wait for an ack from Carol before introducing her to Bob?
<Zarutian_iPad>Carol might be an append only filedescriptor object for instance
<Zarutian_iPad>why does Alice not wait for an ack? round trip time delay
<jar286>OK hmm... so we're mixing up basic functionality with performance design.
<Zarutian_iPad>plus the message medium might be store and forward based and VatC is only intermittenly but regularly online
<jar286>And why do we trust the parties responsible for forcing order to do it properly?
<jar286>s/forcing/enforcing/
<Zarutian_iPad>we can trust Carol or VatC to do it because Alice is vulernable to Carol in thatregard anyway
<jar286>so does Bob's reference to carol have to have ordering requests embedded in it? I mean how does Carol know, when receiving Bob's early message, that another one is on the way?... hmm
<Zarutian_iPad>but there are ways to enforce this ontop of message orderless fabric though it is an annoyance.
<Zarutian_iPad>jar268: that is precisely the question
<jar286>"reference to Carol, but only after Carol has received message #387"
<jar286>who raised this problem? only capn proto? Or does markm talk about it?
<Zarutian_iPad>gee, I have foggy recollection of these ordering issues being talked about in the old e-lang mailinglist archives
<Zarutian_iPad>markm has talked about strict order, fifo order and E order
<jar286>I don't remember anything being tied up with introductions. But I didn't pay close attention at the time (early 2000s?)
<jar286>If you're worried about latency it seems the list of hacks to apply would be unending
<Zarutian_iPad>I am thinking that this can be expressed without the embargo/disembargo thing from capnproto
<Zarutian_iPad>ACTION reads through https://groups.google.com/g/capnproto/c/_1kBtRSC51s/m/H6tvW0BICAAJ
<Zarutian_iPad>ACTION rereads https://github.com/capnproto/capnproto/blob/master/c++/src/capnp/rpc.capnp
<Zarutian_iPad> https://github.com/capnproto/capnproto/blob/master/c++/src/capnp/rpc.capnp#L674 spefically
<Zarutian_iPad>as I understand it CapTP ofE solves this diffrently
<Zarutian_iPad>to explain it I need first explain how promises spanning vats work in E
<Zarutian_iPad>each far ref proxy, at least for promises, has an redirector (the rdr thing)
<Zarutian_iPad>so when Alice wanted to enliven a sturdyref she has to Carol then VatC captp subsystem instanciates an far ref proxy locally to stand in for remote Carol
<Zarutian_iPad>s/VatC/VatA/ was it supposed to be
<Zarutian_iPad>VatA establishes an captp connection to VatC, verifies VatCs vatid equals to the one in the sturdyref
<Zarutian_iPad>whilist the connection is being established Alice invokes foo() on Carol, which is actually invoking foo() on the local far ref proxy
<Zarutian_iPad>so the deliverOps for NonceLocator.lookupSwiss(CarolSwissNum) and Carol.foo() travel in the same packet or tcp segment
<Zarutian_iPad>in the deliverOp message for the NonceLocator.lookupSwiss() VatA gives VatC access to the redirector for the far ref proxy that Alice has for remote Carol
<Zarutian_iPad>internally that far ref proxy has a promise for the resolution of the foo() invocation (actually all invocations so far through that far ref proxy)
<Zarutian_iPad>now in the case of Carol actually not living in VatC but in VatA or VatB then the redirector is invoked to tell the far ref proxy where Carol actually lives.
<Zarutian_iPad>But here is the thing. The far ref proxy upon recieving an invocation on its redirector does not switch immediately where invocations to it should go
<Zarutian_iPad>but awaits on the promises of all the invocations done to the far ref proxy prior to the invocation of its redirector and then sends the invocations it has accumulated since to the new destination
<Zarutian_iPad>so the bar() invocation travels the same path as the foo() one did (the case prior to redirector being invoked) or it gets held up in the far ref proxy until the bar() invocation resolves
<isd><jar286> "so does Bob's reference to carol..." <- This is actually pretty easy: at the message level, to make the prior call alice sense a call message to vat C (I believe E calls this deliverOp?), and then, when she starts the handoff of carol to bob in vat B, she has to send a provide message to vat C. vat C processes messages in FIFO order, so when it sees the provide message it will have already delivered the call to carol.
<isd>bob will be unable to actually pick up the reference until then.
<Zarutian_iPad>effect of E vats being single threaded event loops each
<Zarutian_iPad> http://erights.org/javadoc/org/erights/e/elib/prim/MirandaMethods.html#__whenMoreResolved(java.lang.Object,java.lang.Object) was used (or intended to be used) for same thing as capnproto disembargo is used iirc
<isd>Disembargos are for the case where bob has pipelined calls on a promise that resolved to carol. Without them, vat B has to wait for all such calls to return before sending further calls directly to carol. Disembargos act as a kind of "end of file" marker; instead of vat B waiting, it allows vat C to know that it should just queue messages on carol from vat B until it receives the disembargo forwarded by the vat A, so bob can start sending calls
<isd>immediately.
<Zarutian_iPad>I am trying to recall if capnproto is meant to support multi threaded vats or not
<Zarutian_iPad>Carol or VatC does not know that Bob or VatB should have access to Carol until Alice tells VatC NonceLocator on VatA to VatC connection .provideFor() passing in Carol after .foo() as the gift argument
<isd>Not explicitly; capnp-C++ is single-threaded event loops like E. But Ross and I both did mutli-threading for Go and Haskell respectively, just because it fit in naturally with the language's normal idioms towards async io.
<isd>The reasoning above still works in that case; carol may not have actually seen alices call before bob picks up the cap, but it will be sitting in her mailbox, so she will still see it before she sees any of bob's calls.
<Zarutian_iPad>even iff VatB has already estabilished connection to VatC and done .acceptFrom() with the nonce from VatA, Bob can send those .bar() invocations immediately
<isd>You can kindof think of the connection object in go-capnp as a reverse proxy for all of the goroutines managing individual objects. This stuff comes up even with the vat model, because you may have proxies.
<Zarutian_iPad>isd: we agree on how CapTP of E did these thingsthen
<Zarutian_iPad>s/gsth/gs th/
<Zarutian_iPad>so the question is, is embargo and disembargo needed in ocapn or not?