wasm broken: panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: StringError("operation not supported on wasm yet") }

[iceiix]

#92 added support for compiling for the wasm32-unknown-unknown target for WebAssembly, but it fails to run, panicking with "operation not supported on wasm yet" - need to adapt all code to support wasm (or compile it out with #[cfg(not(target_arch = "wasm32"))]):

[Error] panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: StringError("operation not supported on wasm yet") }', src/libcore/result.rs:1009:5

Stack:

__wbg_new_a99726b0abef495b
__wbg_new_a99726b0abef495b@http://localhost:8080/bootstrap.js:59:103
wasm-stub@[wasm code]
<?>.wasm-function[console_error_panic_hook::hook::he1fad92af5701fc6]@[wasm code]
<?>.wasm-function[core::ops::function::Fn::call::hde3e92baaac0baf2]@[wasm code]
<?>.wasm-function[std::panicking::rust_panic_with_hook::h869ce4541d4e3554]@[wasm code]
<?>.wasm-function[std::panicking::continue_panic_fmt::h0ad726c0b188da91]@[wasm code]
<?>.wasm-function[rust_begin_unwind]@[wasm code]
<?>.wasm-function[core::panicking::panic_fmt::h4d67173bc68f6d5a]@[wasm code]
<?>.wasm-function[core::result::unwrap_failed::h69fb4e02ca2192a0]@[wasm code]
<?>.wasm-function[<core::result::Result<T, E>>::unwrap::h79a8a390611a2b6e]@[wasm code]
<?>.wasm-function[stevenarella::console::Vars::save_config::h541aec1a47a53665]@[wasm code]
<?>.wasm-function[stevenarella::main::hbc764074c370a7d5]@[wasm code]
<?>.wasm-function[main]@[wasm code]
wasm-stub@[wasm code]
main@[native code]
eval code
eval@[native code]
./index.js@http://localhost:8080/0.bootstrap.js:34:5
__webpack_require__@http://localhost:8080/bootstrap.js:90:34
__webpack_require__@[native code]
promiseReactionJob@[native code]


	__wbg_error_f7214ae7db04600c (stevenarella.js:38)
	__wbg_error_f7214ae7db04600c (bootstrap.js:65:106)
	wasm-stub
	<?>.wasm-function[console_error_panic_hook::hook::he1fad92af5701fc6]
	<?>.wasm-function[core::ops::function::Fn::call::hde3e92baaac0baf2]
	<?>.wasm-function[std::panicking::rust_panic_with_hook::h869ce4541d4e3554]
	<?>.wasm-function[std::panicking::continue_panic_fmt::h0ad726c0b188da91]
	<?>.wasm-function[rust_begin_unwind]
	<?>.wasm-function[core::panicking::panic_fmt::h4d67173bc68f6d5a]
	<?>.wasm-function[core::result::unwrap_failed::h69fb4e02ca2192a0]
	<?>.wasm-function[<core::result::Result<T, E>>::unwrap::h79a8a390611a2b6e]
	<?>.wasm-function[stevenarella::console::Vars::save_config::h541aec1a47a53665]
	<?>.wasm-function[stevenarella::main::hbc764074c370a7d5]
	<?>.wasm-function[main]
	wasm-stub
	main
	Eval Code
	eval
	./index.js (0.bootstrap.js:34)
	__webpack_require__ (bootstrap.js:90)
	__webpack_require__
	promiseReactionJob
[Error] Error importing `index.js`: – Error: Unreachable code should not be executed (evaluating 'stevenarella__WEBPACK_IMPORTED_MODULE_0__["main"]()')
Error: Unreachable code should not be executed (evaluating 'stevenarella__WEBPACK_IMPORTED_MODULE_0__["main"]()')
	(anonymous function)
	promiseReactionJob

This particular error appears to come from the Rust standard library: https://github.com/rust-lang/rust/blob/190feb65290d39d7ab6d44e994bd99188d339f16/src/libstd/sys/wasm/mod.rs#L70-L73

pub fn unsupported_err() -> crate::io::Error {
    crate::io::Error::new(crate::io::ErrorKind::Other,
                   "operation not supported on wasm yet")
}

from fs::File::create("conf.cfg") in src/console.mod.rs, relevant: https://stackoverflow.com/questions/53304832/loading-a-file-from-wasm. But once this particular issue is resolved, more incompatibilities will be uncovered, including in winit iceiix/winit#2 and glutin iceiix/glutin#1, which should wrap WebGL.

(Another option besides wasm32-unknown-unknown is wasm32-unknown-emscripten, which would fix File APIs because Emscripten has implementations for the web platform already, but Rust with Emscripten isn't as well supported: rust-windowing/winit#767 and https://rustwasm.github.io is all about wasm32-unknown-unknown, where the implementations are in pure Rust instead (albeit less complete at the moment).)

[iceiix]

It is instructive to see what other games are doing. Zemeroth posted this on their blog with many technical details: https://ozkriff.github.io/2019-05-13--devlog-zemeroth-v0-5/. For the rendering backend investigation (#34). They had a custom engine Häte2d but migrated to ggez and wrote some helpers on top for scene management and widgets. ggez "Good Game Easily" seems to be quite a well supported project with a lot of steam behind it. They used to use SDL2 (like Steven) but moved to winit with ggez 0.5-rc1. Unfortunately, ggez is 2D-only. Not in the running for a graphics backend replacement for this project.

For the math library, they were using cgmath but migrated to nalgebra, as that's what ggez uses. Steven uses cgmath. There is this post: Cgmath looking for new maintainers with some concern about the future of cgmath but it works well so I'm deciding against switching for now.

More interesting, WebAssembly support. Stuck on dependences myself. What did Zemeroth do? They use a separate crate called good-web-game which implements a subset of compatible API for wasm32-unknown-unknown, using WebGL1 and WebGL2 canvases. That's pretty cool. The blog post is worth reading to see how they substituted one crate for another depending on the target (wasm or not), having a different main() but much of the same code. This may be what has to be done in Stevenarella to replace crates with native dependencies with web-based equivalents.

[iceiix]

https://www.reddit.com/r/rust/comments/8y3fei/how_do_modules_like_stdfs_and_stdnet_work_with/ confirms they don't. But an idea of how to adopt without rewriting, implement the same methods to replace what is needed in std, and conditionalize on imports. Then there is no need to change the Rust compiler to adopt the no-op implementations there. Something like this works:

use cfg_if::cfg_if;

cfg_if! {
    if #[cfg(target_arch = "wasm32")] {
        struct File {}
        impl File {
            fn open(_: &str) {
            }
        }
    } else {
        use std::fs::File;
    }
}

fn main() {
    let f = File::open("/tmp/a");
    println!("f = {:?}", f);
}

for both cargo run and cargo build --target wasm32-unknown-unknown. Similar pattern for other parts of the standard library.

The question then becomes how to implement it, essentially a web filesystem (etc). It has been done: https://github.com/emscripten-core/emscripten/blob/incoming/src/library_fs.js - perhaps port this code or at least the interesting bits. Alternatively, implement it from scratch. But surely this is not too much of an unusual requirement for someone else not to already have done the work.

stdweb's File? https://docs.rs/stdweb/0.4.17/stdweb/web/struct.File.html - nope, this doesn't work:

use cfg_if::cfg_if;

cfg_if! {
    if #[cfg(target_arch = "wasm32")] {
        use stdweb::web::File;
    } else {
        use std::fs::File;
    }
}

fn main() {
    let f = File::open("/tmp/a");
    println!("f = {:?}", f);
}

not the same API:

error[E0599]: no function or associated item named `open` found for type `stdweb::webapi::file::File` in the current scope
  --> src/main.rs:12:19
   |
12 |     let f = File::open("/tmp/a");
   |             ------^^^^
   |             |
   |             function or associated item not found in `stdweb::webapi::file::File`

[iceiix]

Looking at getting basic printing functionality working to help debug, added println! at very beginning of fn main() but it isn't logged to the console. http://crates.io/crates/wasm-glue purports to do this but requires nightly: DeMille/wasm-glue#2

https://rustwasm.github.io/docs/book/game-of-life/debugging.html actually has an example of a console logging macro:

extern crate web_sys;

// A macro to provide `println!(..)`-style syntax for `console.log` logging.
macro_rules! log {
    ( $( $t:tt )* ) => {
        web_sys::console::log_1(&format!( $( $t )* ).into());
    }
}

[iceiix]

File operations are invoked very early when loading/saving the console settings:

    let con = Arc::new(Mutex::new(console::Console::new()));
    let (vars, vsync) = {
        let mut vars = console::Vars::new();
        vars.register(CL_BRAND);
        auth::register_vars(&mut vars);
        settings::register_vars(&mut vars);
        vars.load_config();     // ****** here
        vars.save_config();    // ******
        let vsync = *vars.get(settings::R_VSYNC);
        (Rc::new(vars), vsync)
    };

[iceiix]

There's a brand new target which may solve many of these problems: wasm32-wasi. Targets the WebAssembly System Interface: https://wasi.dev. Available only in nightly, but looks like basically what I'm looking for. To run there is a runtime: https://github.com/CraneStation/wasmtime/ which has an informative introduction to WASI https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-intro.md and a WASI tutorial: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-tutorial.md. The examples given use the standard filesystem APIs and works on the web (with a polyfill, and off the web with some interesting capabilities-based sandboxing system), perfect.

Unfortunately the www/ setup, which I based on the rustwasm tutorials https://rustwasm.github.io/wasm-pack/book/, is all using wasm32-unknown-unknown, but they mention wasi in their weekly update: https://rustwasm.github.io/2019/03/28/this-week-in-rust-and-wasm-015.html to be standardized: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Can wasm-pack target wasi?

Testing building with cargo +nightly build --target wasm32-wasi. At least much of the work to build for the other wasm32's should be reusable since I conditionalize on target_arch = "wasm32"

[iceiix]

cargo +nightly build --target wasm32-wasi fails with 31 import errors in glutin for some reason:

warning: dropping unsupported crate type `cdylib` for target `wasm32-wasi`

error[E0432]: unresolved import `glutin::VirtualKeyCode`
  --> src/ui/mod.rs:21:5
   |
21 | use glutin::VirtualKeyCode;
   |     ^^^^^^^^^^^^^^^^^^^^^^ no `VirtualKeyCode` in the root

error[E0432]: unresolved import `glutin::VirtualKeyCode`
 --> src/settings.rs:3:5
  |
3 | use glutin::VirtualKeyCode;
  |     ^^^^^^^^^^^^^^^^^^^^^^ no `VirtualKeyCode` in the root

error[E0433]: failed to resolve: could not find `EventsLoop` in `glutin`
   --> src/main.rs:222:35
    |
222 |     let mut events_loop = glutin::EventsLoop::new();
    |                                   ^^^^^^^^^^ could not find `EventsLoop` in `glutin`
...

probably due to iceiix/glutin@5ff18de, which keys off target_os = unknown instead of target_arch = wasm32?

[iceiix]

Fixed glutin missing on wasm32-wasi in c6b753b but it requires a different entrypoint than wasm32-unknown-unknown:

error: entry symbol `main` defined multiple times
   --> src/main.rs:194:1
    |
194 | / pub fn main() {
195 | |     let opt = Opt::from_args();
196 | |
197 | |     set_panic_hook();
...   |
354 | |     }
355 | | }
    | |_^
    |
    = help: did you use #[no_mangle] on `fn main`? Use #[start] instead

actually, need to remove #[wasm_bindgen]