IRC channel logs
2025-09-22.log
back to list of logs
<dthompson>omentic: I generally avoid dealing with collections over the ffi, but when needed we wrap an interface to get/set/etc. <dthompson>omentic: variable arity is not possible because it's not possible in wasm <omentic>dthompson: hmm, thx. i think i'll probably go with iterating things into a scheme array absent of other options then <omentic>what this is for is ex. having a (child-nodes extern) proc to give you back a (list extern) <omentic>i think i do probably want the convenience of it as a scheme native list over the performance downside... but a bit unfortunate to not be able to convert the list memory repr directly into scheme. ah well tho, does not come up *too* often <dthompson>omentic: yeah you just can't do that with wasm, generally. <dthompson>host objects are opaque to the guest and vice versa <dthompson>if you have an externref for a js array the only possible way to iterate over it is to make N+1 calls out to JS <dthompson>the same is true for iterating a scheme vector from js <omentic>dthompson: makes sense, i s'pose i'm more used to normal ffi where memory layout is inspectable <dthompson>omentic: yeah, there's stronger security properties on wasm gc objects. the plus side is that it means wasm gc is a capability system which is great. <omentic>well... did you see the recent wasm prototype chaining capability escape? 😄 <omentic>something i'm sure the spec will fix (for some reason browser vendors didn't want to?). but pretty funny regardless that js's complexity is so much such that it snuck its way in <dthompson>it's a js problem, nothing wasm can do about it <dthompson>still a capability system, js just has some footguns in it <dthompson>it's too easy to grant more privilege than you intended <omentic>it's a hilarious bug but yeah, just sanitize before passing capabilities to modules and you're good <dthompson>hopefully there can be some systematic way to ensure you aren't introducing this vulnerability because having to do it manually for each wasm input is only going to lead to vulnerabilities slipping in <dthompson>2 party only, no 3rd party handoffs. no gc. no sturdyrefs. <dthompson>some interesting things like the http batch "netlayer" and the special map function <dthompson>civodul: today's shepherd race condition investigation is around logging. from what I can tell, there's no synchronization between service startup messaging ("service foo has been started.", etc.) and therefore it's *possible* for a child process' log messages to reach the shepherd log *before* shepherd's own startup messages. <dthompson>logging.sh fails for us every now and then because the "aaaaa" message isn't found when running 'herd status root', and we've found that it's due to log message ordering where sometimes "aaaaa" isn't a recent enough message to be shown in the status output. <dthompson>so we're playing the game of "does upstream prevent this from happening somehow or did we just make it easier to lose the race?"