IRC channel logs
2026-10-01.log
back to list of logs
<mcc>dthompson: also - with the hacked guile-hoot-0.9.0 as per your instructions, running `hoot repl` fails with: error: CompileError: WebAssembly.instantiate(): Compiling function #5453 failed: local.set[0] expected type (ref eq), found i64.extend_i32_s of type i64 @+1672718 (CompileError: WebAssembly.instantiate(): Compiling function #5453 failed: local.set[0] expected type (ref eq), found i64.extend_i32_s of type i64 @+1672718) <mcc>in either of these cases I could have done something wrong but i don't obviously see what. <mcc>dthompson: I *can* however compile to what appears to be a real wasm module; I can't run it but I think this is because hoot is currently intended for web use. I notice your nodjes instructions seem to be simulating some web elements? (I *think* if I can work out how to export a symbol named _start however wasm-interp will just run it.) https://usercontent.irccloud-cdn.com/file/G3qtzlGB/image.png <mcc>i'm hopping around your docs a bit so i apologize if i'm missing something <dthompson`>mcc: nodejs is the runtime I use when outside the browser so I am surprised to see errors. what version are you using? <mcc>dthompson`: What version of what? I am using wasm-interp 1.0.36 from WABT . It is not a javascript runtime it just runs wasm <mcc>so it is closer to wasi, but i think to be wasi strictly you need to be using "components". <dthompson`>mcc: you shared an error while running 'hoot repl' that looked like it was from nodejs <dthompson`>which is the runtime we try to use by default when running in the terminal <mcc>dthompson`: Oh! Well I notice ./configure DID check for node so yes that was probably node. I am on debian stable and I have v22.12.0 installed from debian <mcc>I'm not sure what node is running because if I run nodejs --version I get v22.12.0, but that's installed from nvm. So if you take `node` out of my PATH you'll get v22.12.0 and otherwise I'm … not… sure. <dthompson>okay well either way I think it's an old enough version that hoot isn't going to work <dthompson>I'm on 24.18.0 so maybe it is an old version thing and I didn't realize we needed a newer node than what our docs state <mcc>i have nvm so i can bump to 24 <dthompson>that's the only thing I can think of that would explain those errors <mcc>i'll test that in a minute <dthompson>because I run our stuff in at least 2 different v8 environments without issue: node and chrome <dthompson>in other news, I think I have reproduced the web server error again. guess my quick fix was no good... <dthompson>mcc: regarding WASI, hoot doesn't support it now but could in the future. <dthompson>in order to run on component model runtimes (wasmtime for example) we need components that provide the things we rely on from web apis <dthompson>WASI is not a great match for hoot presently because it was built for statically typed languages with manual memory management or borrow checking semantics. <mcc>dthompson: that makes sense. Honestly, what I'm trying to use it for right this instant is using (wat->wasm) as a wasm assembler, since the wabt basic tools are somewhat underdocumented <dthompson>ah, you want the toolchain, not the compiler <mcc>Essentially. If I could get the scheme compiler that would be advantageous but it isn't so strictly necessary for what I'm doing right now <mcc>even playing around in the repl might help <mcc>dthompson: I bumped nvm to 24.21.0 and I'm getting what looks like an identical error. is there a way to get the hoot executable to report which nodejs it is using? <dthompson>the configure script will say what node is being used <mcc>aha. and looking it links to my .nvm directory… so apparently if i change the path of my local node i have to recompile hoot. <mcc>it rebuilt a "config.go" so I'm assuming that went into the executable. <mcc>same error still, it looks like <mcc>i have an old paranoia of ./configure based applications not picking up changes without clean builds… no point in trying a clean build is there? <dthompson>rebuilding config.go is correct but you could try a clean build just in case <ArneBab>sneek: later tell dthompson: I just read the presentation on infoq. Regarding consensus: do you have resources about efficient implementation of paxos or raft? Did you see that kafka is moving away from zookeeper and towards raft? https://kafka.apache.org/41/operations/kraft/ <ArneBab>sneek: other point while reading: what you’re describing as delegation sounds a lot like capabilities on the Hurd: you receive a port that allows for your operations. Would it be possible to have a mode that moves Spritely closer to the metal by mapping it to Hurd capabilities? <ArneBab>sneek: later tell dthompson: other point while reading: what you’re describing as delegation sounds a lot like capabilities on the Hurd: you receive a port that allows for your operations. Would it be possible to have a mode that moves Spritely closer to the metal by mapping it to Hurd capabilities? <dthompson>ArneBab: I don't have any opinions re: paxos vs. raft <sneek>Welcome back dthompson, you have 3 messages! <sneek>dthompson, ArneBab says: I just read the presentation on infoq. Regarding consensus: do you have resources about efficient implementation of paxos or raft? Did you see that kafka is moving away from zookeeper and towards raft? https://kafka.apache.org/41/operations/kraft/ <sneek>dthompson, ArneBab says: other point while reading: what you’re describing as delegation sounds a lot like capabilities on the Hurd: you receive a port that allows for your operations. Would it be possible to have a mode that moves Spritely closer to the metal by mapping it to Hurd capabilities? <dthompson>re: hurd: a microkernel would be a better base for an ocap OS than linux <ArneBab>dthompson: and at least with the Hurd, you have capability-based GNU Mach underneath. <ArneBab>Hurd provides a unix groups abstraction to capabilities (basically collections of capabilities that have names – the group names), but that’s built on capabilities and you can use that. <dthompson>I think they have a different notion of "capability" than we do <jfred>...but it doesn't e.g. have persistent capabilities <jfred>I've been meaning to try it out at some point <mcc>one of the things i've been wondering about <mcc>i have been looking at redox <mcc>and redox has multiple times in their docs "we want to add capability security! we want this really bad!" 
