Hi, I see most of the discussions here seem to be architectural, is there a better place for questions about trying out the current implementation of Hoot and debugging issues there?
Specifically I (not really a web frontend person, and also not a schemer, yet) wanted to try some modifications to the REPL demo from Scheme in Scheme on Wasm in the browser -- Spritely Institute , just to get a feel for the environment. It’s a cool demo
I notice that when you give it an undefined symbol, it refreshes the current line - and shows an error in the (firefox) browser console that is mostly from reflect.js:
I don’t expect refined backtraces from a demo, but I wasn’t clear if the js-runtime part is just for the demo or is part of Hoot proper. Also tips on how to debug Hoot would be cool - I am new enough with this world that I’m not sure how to hook up logging to the console.
Here is a fine place to talk about Hoot, but you can also open issues on GitLab when that makes sense!
As you’ve noticed, there really isn’t any error handling in the REPL demo. This is for 2 reasons: 1) We were still building out the exception system at the time and 2) some parts of the runtime do not throw proper Scheme errors. Attempting to eval (+ 1 "two") will cause a wasm crash, for example.
All the stuff in js-runtime is the Hoot runtime integration layer. It includes reflect.js, the library for bootstrapping Hoot applications on the web and inspecting Scheme values from JS, and two helper wasm modules: reflect.wasm and wtf8.wasm (for strings).
Debugging is a bit of a mixed bag right now, because debugging wasm in general is not the best experience yet. The upcoming Hoot 0.3.0 release will print out structured Scheme exception messages when an uncaught exception crashes the program, which will be a big improvement as you’ll finally know what the error details are. The release will also fix some of the remaining places where proper Scheme exceptions are not being thrown.
The mixed JS/wasm backtraces will continue to be the only real backtrace you’ll see, for now. A true Scheme backtrace isn’t really feasible with the current state of the wasm spec and we need to wait for some additional extensions to get adopted by browsers.
For low-level wasm debugging, 0.3.0 will add an optional feature to add wasm debug names to binaries, so when you look at the diassembly in the dev console you’ll see the original names of wasm types, functions, etc. which is going to make low level debugging a lot easier. We’re also continuing to work on our own wasm interpreter and REPL tools for it.
The best debugging tip I can give is pretty silly, but it’s the old reliable technique: print debugging. The pk (short for “peek”) procedure is handy for this, as you can wrap any expression in pk and it will print all arguments it is given while also returning the last value. For example (pk 'test 1 2 3) will print the values test, 1, 2, 3 and return 3. You can also use display and friends.
I’m trying to use display and pk to debug, but I’m getting unbound top-level display errors when I try to use it. Do I have to import something to use display? From googling around it seems like it should be built in.
Hoot is based primarily on R7RS-small with some (and ever more) Guile extensions. pk does not exist in standard Scheme (as far as I know), and display is in the scheme write library in R7RS. You’ll need to import (scheme write) for display and (hoot debug) for pk/peek.
