IRC channel logs

<ArneBab>sneek: later tell dthompson: I missed that -- neat! Thank you!

<kestrelwx>ArneBab: I think that `'()` ends up being a `Null` instance, rather than the JS `null`. I've tried `#f` and `'()` and ended up with a `() => null` helper.

<ArneBab>I wonder whether that’s a bug, because reflect.scm maps () to null

<kestrelwx>I only see the other way around, I'm not too sure what `()` maps to. Probably these values from `reflect.wat`?

<ArneBab>there’s a match with ()

<ArneBab>(I checked the source)

<dthompson>ArneBab: reflect.scm is not related to the JS interface

<sneek>dthompson, you have 1 message!

<sneek>dthompson, ArneBab says: I missed that -- neat! Thank you!

<dthompson>that's for hoot reflection from the guile vm

<dthompson>kestrelwx is right that the empty list is mapped to an instance of a Null class in JS

<ridley>Hello people

<ridley>Is tsyesika back and does she have time for an OCapN question?

<dthompson>tsyesika is back! we're in a meeting now I'll mention this

<tsyesika>hey ridley

<ridley>hello hello

<tsyesika>I do have time for an OCapN question :)

<ridley>oh yay thank you

<ridley>I've been trying to understand how goblins decides whether or not to enable promise pipelining (by including an answer-pos in op:deliver)

<ridley>I tried digging into the code last week and it seemed like maybe whenever someone does a <- it is automatically enabled? Or I've failed to parse the scheme

<tsyesika>Yeah so when you do a `<-` to a remote-refr it'll create a new "question finder" which is basically a little token attached to the promise and known by CapTP. Promises with this question-finder attached get an answer-pos in CapTP

<tsyesika>then if you send a message to this promise (which is a result of `<-`) goblins will see the question finder and CapTP will be able to look up the answer-pos it used to be able to pipeline

<ridley>So, rephrasing to make sure I understand, any `<-` to a remote-refr will have promise pipelining enabled? So you would not do an op:deliver without an answer-pos?

<tsyesika>I think that's correct yeah

<ridley>Okay so I *can* understand scheme

<tsyesika>ACTION double checks :)

<ridley>My question was going to be regarding an edge case if you didn't automatically enable it. But if you're automatically enabled it then you wouldn't be affected by the thing I found.

<tsyesika>there is a branch of goblins https://codeberg.org/spritely/goblins/src/branch/main/goblins/ocapn/captp.scm#L665 which doesn't have question finders, I'll see if I can page back in when that'll ever happen

<ridley>I was looking at https://codeberg.org/spritely/goblins/src/branch/main/goblins/core.scm#L1547 which makes it look like you always attach a question finder on a <-

<ridley>to a remote refr

<tsyesika>yeah, if you do a `(<- <remote-refr> ...)` then it'll always have a question finder and thus always have an answer-pos

<ridley>okay thank you for confirming

<ridley>so goblins does not make use of the draft spec's current ability to not provide an answer-pos

<ridley>(outgoing)

<tsyesika>that's what I'm trying to figure out :)

<tsyesika>there's quite a few code paths to send messages to things

<tsyesika>I _think_ though I've not tested it and it's a weird thing to do, you could pass a remote actor as your fulfill or error handler for an `on` (that has `#:promise? #f`) and have it happen https://codeberg.org/spritely/goblins/src/branch/main/goblins/core.scm#L1639

<tsyesika>would have to test it to be a 100%

<tsyesika>I think that might be it

<ridley>don't worry about testing it for my case

<ridley>thank you for your time

<tsyesika>generally speaking though, no goblins always wants to setup a `answer-pos` so that in the future you can pipeline on it

<ridley>yeah, I had wondered if there was an optimization step because including an answer-pos (I think) takes extra resources

<ridley>so allowing devs to say whether or not they want to enable pipelining on a call can save resourcs

<ridley>but also feels like a giant pain to use

<tsyesika>yeah it does, we don't have any static analysis to be able to determine if a promise is used for pipelining in the future, so we set everything up so it can be

<ridley>Yeah, without static analysis you'd need like <-pp and <-npp or something

<ridley>And I would not be excited about having to think about that as someone using goblins

<ridley>or my thing

<ridley>This has also made me more in favour of kumavis' proposal to get rid of resolve-me-desc on op:deliver and require op:listen

<tsyesika>I'm a bit on the fence, I tried implementing it in goblins so that we didn't have a resolve-me-desc unless we did an `on`, I still think it's very doable, just hard to get it right across the goblins codebase. Having said that wanting to listen to a promise is a common use-case so being able to quickly avoid an extra message send is nice for little cost

<tsyesika>but in goblins I think we could always do that `op:listen` after all `op:deliver` messages for now, so I don't think this change would cause us any major issues

<ridley>On my side it seems very doable. For me it logically fits in with how promises work.

<ridley>I don't like the extra message send. That's my biggest concern. But also if you're already always enabling answer-pos that's also an extra gc message send every time you don't pipeline.

<ridley>It's not a dealbreaker for me but I keep coming across little things that make me like the proposal more and more.

<ridley>Anyway, that can be a conversation for another day

<ridley>Thanks for your time. Presumably talk to you tomorrow

<ArneBab>dthompson: thank you for the clarification!

IRC channel logs

2025-11-10.log