obsidian-typst icon indicating copy to clipboard operation
obsidian-typst copied to clipboard

Fix compiler worker not fetching wasm binary correctly

Open OverHash opened this issue 1 year ago • 5 comments

See issue #59 for why this patch is needed.

Essentially, inside the web worker environment, the global 'Response' does not exist. As a result, wasm-bindgen's attempt to fetch the binary and parse the Response object does not work.

This patch sends the entire wasm binary through to WebAssembly.instantiate.

OverHash avatar Jul 30 '24 23:07 OverHash

Hm its annoying that it has to be done this way, and please don't format the code with tabs, use 2 spaces instead.

Could you also make a bug report on the obsidian forums with your findings: https://forum.obsidian.md/c/bug-reports/7 I don't know if they're aware of this. I would make one but you seem to have a better grasp on it than I do.

fenjalien avatar Aug 06 '24 12:08 fenjalien

@fenjalien I reformatted the compiler.worker.ts with two spaces.

I don't have an Obsidian forums account sorry, but here's the relevant details

  • On Obsidian v1.6.3, it is known that this plugin worked fine. The Response object existed under the globals of web workers that were spawned.
  • Either on Obsidian v1.6.4, or more likely Obsidian v1.6.5, the globals available inside a web worker was cut down significantly. This list omitted the Response object, making functions like wasm-bindgen produce JS code which incorrectly goes down the wrong path (the else path in this case).
  • Strangely enough, calling functions like fetch inside the worker do return a Response object. It appears to be that it's just the global that does not exist. I'm not quite sure how this is possible.

This means that plugins like obsidian-typst cannot fetch resources inside a web worker very well. The resources need to be fetched in the main thread before they are passed to the worker.

I unfortunately couldn't find any more details than that. If you have an Obsidian forums account, publishing with those details might be enough for a developer of Obsidian to track down the issue though on their end.

OverHash avatar Aug 07 '24 00:08 OverHash

I can confirm that after building from scratch this did fix the problem for me. It does appear however that the patch is broken due to an update to the rust-compiler that broke type-inference in time 0.3.34, a dependency of the rust-section. I had to run cargo update in the rust-section to update dependencies, after which I could compile successfully. @OverHash

lukasfri avatar Sep 03 '24 14:09 lukasfri

Thanks for the report @lukasfri. Looks like it is https://github.com/time-rs/time/issues/681

OverHash avatar Sep 03 '24 22:09 OverHash

I want to try this patch because I also see #59 errors.

But when I run npm run wasm-build I see

error: could not compile `memchr` (lib) due to 480 previous errors
Error: Compiling your crate to WebAssembly failed
Caused by: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: cd "compiler" && "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

I already followed this steps

Obsidian Version: 1.7.6 Machine: MacOS M1 Pro Cargo Version: 1.82.0


Update: i uninstalled homebrew's rust and reinstalled rust via:

$ curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

chardskarth avatar Nov 15 '24 05:11 chardskarth