IRC channel logs
2024-05-29.log
back to list of logs
<old>cwebber: Hmm. Is there a more details explanation about transaction object model? Sounds like database? <old>So with time travel, one could implement the Braid video game I suppose <old>hmm I see from your blog post. Is the entire state saved every tick or just the difference? <old>I've compiled the following form with guild copile-wasm: (define (fuz) 1) <old>I do get a .wasm file. But when I use wasm2wat from the wabt package, it prints: <old>BeginModule(version: 1) <old> BeginTypeSection(1792) <old>000000e: error: unexpected type form (got 0x5e) <old>I would just like to generate some wasm file from some Guile code to explore the binary format. But I also want to see the WAT <cwebber>old: instead of using wasm2wat, use Hoot's own disassembly tools :) <cwebber>wabt's aren't comprehensive of all the extensions we use <old>ahh nice: (wasm->wat (call-with-input-file "foo.wasm" parse-wasm)) <old>is there a list of mandatory extensions that a VM must have for supporting hoot generated wasm? <cwebber>old: tail calls, gc, and uh, I forget :) <old>If the wasm format is done correctly (I have no idea), then I assume required extensions are listed somewhere in the header of the binary <old>anyway, will use the hoot toolchain. Don't want to leave Guile REPL <dthompson>old: in addition to gc and tail calls, we also rely on multi-values. all of these things have been accepted into what will be the wasm 2.0 spec. <dthompson>and cwebber is right about wabt not being up-to-date in this regard. we've had similar issues with another tool called binaryen. due to this, our decision to write our own toolchain has really paid off. <dthompson>there's nothing in a wasm binary that says "this module requires gc and tail calls". the validation of a module at runtime will cause whatever wasm engine is being used to throw an error if it reaches an opcode it doesn't understand. <jboy>will hoot eventually conceivably allow projects that use guile bindings for a C library like raylib to compile fully to wasm? <dthompson>jboy: no the C FFI is completely incompatible. <jboy>I see dthompson. Is that true even if the C library is first compiled to wasm using emscripten? <dthompson>yes. you still need to speak in terms of wasm imports/exports to use it. <dthompson>for example, guile-opengl uses the C FFI to bind to libgl. to make guile-opengl usable on the web, it could instead generate WebGL bindings when compiling with hoot and try to make the APIs match up as much as possible. <jfred>I got thoroughly sucked in to cirkoban last night. Glad it uses localstorage for save states, haha <dthompson>I added that localstorage stuff before we really had any levels and I'm glad I did because it's nice to be able to resume where you left off. <jfred>It's a long enough and challenging enough game that it really benefits from game saves I think. I only discovered that it had saved by accident though when I accidentally caused the game to reload; might be nice if the game description mentioned that it saves your progress <jfred>I was worried it wouldn't XD <dthompson>I didn't know how many people would play long enough to care ;) <old>dthompson: thanks for the details <theruran>sorry, I disconnected. Was old's question answered about more details on the transaction object model? <jfred> theruran: I meant to post about that here, that thread and programming environment have me convinced that visual graphs are probably the right substrate for propagator programming