IRC channel logs

<jmes>Hello hello, I'm trying to play with WebGPU via hoot but I'm a bit of a noob at both. In particular I'm wondering how to import and use a foreign (js) function that returns a promise. Like navigator.gpu.requestAdapter. From js I could do ‘adapter = await navigator.gpu.requestAdapter();’

<jmes>Not quite sure what to do with js promises in hoot

<dthompson>jfred: what did you like about it? I know of it but haven't used it.

<dthompson>pukkamustard: you may want to contact nlnet about change in timeline since the grants are for 1 year afaik

<dthompson>jmes: js promises can be used from hoot by using (fibers promises)

<dthompson>curious how webgpu in hoot goes! I made a webgl triangle demo awhile back.

<dthompson>there's a significant limitation in buffer copying throughput due to wasm limitations rn

<jmes>dthompson: thank you, I'm reading the hoot docs on promises now.

<jmes>I'm oblivious to any potential limitations, I'm just dabbling a bit for now.

<dthompson>the `await` function will suspend the current fiber and wait for the promise to resolve

<jmes>So when I import the function from the host (in this case a browser), do I assume it returns a promise, or what the promise returns (say, a GPUAdapter external ref)?

<dthompson>at the wasm level, all non-primitive js heap values are (ref extern)

<dthompson>so you'd do (define-foreign ... -> (ref extern))

<jmes>Right, so it's definitely a ref. But the result of the promise would sometimes be null so I use (ref null extern)?

<dthompson>it's not about the result of the promise but the result of the function

<jmes>okay I think that's what I meant. In this example navigator.gpu.requestAdapter should return null if it doesn't find an appropriate adapter

<dthompson>if the function always returns a promise then the resturn type is (ref extern)

<dthompson>ah okay

<dthompson>then yes, (ref null extern)

<dthompson>wasm's type system requires indicating if a type may be nullable

<dthompson>you can then use the external-null? predicate from scheme to check for null

<dthompson>if non-null then you can call await on the promise

<jmes>Wait actually it returns a promise (Promise<GPUAdapter?>)

<jmes>so I should use (ref extern), then I use hoot's await and that should return either null or the adapter ref

<jmes>I think I get it

<dthompson>yeah that's right

<jmes>Nice, thanks a bunch! Hoping to get Google's "Your First WebGPU App" running with Hoot

<dthompson>good luck!

<dthompson>I think webgpu on hoot could be usable enough if per-frame buffer copying is kept to a minimum.

<jmes>I'll keep that in mind, and cross that bridge when/if I get there :P

<dthompson>sounds good :)

<jmes>Again about hoot: maybe this is obvious but how do I represent js objects?

<jmes>e.g. A foreign js function takes a js object as an argument. Can I create that js object from scheme?

<jfred>dthompson: I like that, since the apps are embedded in chatrooms, it takes one tap for anyone in the chatroom to join an app session. It's of course more limited in some ways than I imagine Navi apps will be, but it also has the advantage of all the app state living in the chatroom and not relying on an external server anywhere (which kinda forces app devs to use CRDTs if they need

<jfred>synchronization I think)

<dthompson>jfred: interesting! we intend for navi to have the same "open app from chat" flow

<dthompson>I should take another look at webxdc

<dthompson>sneek: later tell jmes: there is nothing built-in to work with js objects or arrays currently. hoot's ffi operates at the wasm type level and doesn't have awareness of that stuff.

<sneek>Will do.

<dthompson>I know that webgpu uses plain ol' js objects for descriptor objects all over the place with default behavior for unspecified keys. I would probably hide all of that from scheme and write wrappers that build each type of descriptor rather than work with js objects directly from scheme.

<dthompson>sometimes you have to manipulate those container types but I'm happier when I can avoid it. reduces js<->wasm round trips, too.

<jfred>I don't know this for sure but I suspect there might be some interesting UX takeaways you could get from looking at WeChat too, as probably the largest app that's done this kind of thing (though in that case of course heavily centralized). The literature might be mostly in Chinese though 🙂

<dthompson>heh that will be a bit of a challenge for me

<dthompson>I'm on the verge of having byzantine fault tolerant brassica chat

<dthompson>thanks to this martin kleppmann paper https://dl.acm.org/doi/10.1145/3517209.3524042

<dthompson>solution feels kinda obvious in hindsight: do what git does.

<dthompson>content addressing + signing

<jfred>:D

<dthompson>yeah it's pretty neat :)

<dthompson>it took me perhaps too long to understand what "byzantine fault" meant but an easy example is Mallet sends Alice and Bob a message with the same id but different contents. if Alice and Bob accept Mallet's messages as truth then the network will never converge to the same value.

<jfred>Ah yeah, content addressing makes sense as a way to help with that since you can verify the message ID corresponds to the message contents

<jfred>I think the Matrix protocol does that (which is partly why redactions take extra effort to support)

<dthompson>yeah everything is append-only

<dthompson>okay, brassica-chat (name probably changing soon) now has content-addressing and signing that work together

<jfred>dthompson: the name reminded me of this recently https://i.kym-cdn.com/photos/images/original/002/436/170/cb1

<dthompson>yesss I love that meme

<dthompson>that's what I had in mind when I named it

<dthompson>"I made a new p2p app"

<dthompson>"new p2p app or chat?"

<dthompson>"chat again"

<jfred>XD

<jfred>apropos

<dthompson>jfred: though I suppose it's not *just* chat again since I don't know of many other apps that combine ocaps and crdts

IRC channel logs

2025-10-30.log