maulingmonkey / cargo-html Goto Github PK

I can't seem to override _start, even with #![no_main] or rustflags = ["-C", "link-args=--no-entry"]. That said, I can define an alternative entry point (_start2 in the example bellow) which will show up as a module export that could be called instead of _start:

extern "C" {
    fn __wasm_call_ctors();
    fn __original_main() -> i32;
}

#[no_mangle]
pub extern "C" fn _start2() {
    unsafe { __wasm_call_ctors() };
    unsafe { __original_main() };
}

cargo-html could check for __cargo_html_start and call that instead of _start if present?

References of note for _start functions:
WebAssembly/wasi-libc/libc-bottom-half/crt/crt1.c
WebAssembly/wasi-libc/libc-bottom-half/crt/crt1-command.c
WebAssembly/wasi-libc/libc-bottom-half/crt/crt1-reactor.c

Only really necessary for blocking I/O, and only for some targets

Both of these have their own loader nonsense and import generation stuff

WASI currently lacks APIs for this, but there's nothing saying I can't roll my own as a proof of concept.

Questions:

• Wait for stack manipulation functions, or double down on asyncify?
• Should infinite loops be preempted? (rewrite WASM with walrus to insert yields? perhaps just insert call __wasi_sched_yields before asyncify pass? i32.const 12; call __increment_retired_instruction_counter?)
• WebWorkers provide actual parallel execution, but require extra HTTP headers and prohibit DOM access
• wasm_bindgen callbacks - treat as if executing in an implicit thread pool? APIs currently don't require Send/Sync, so probably unsound?
• ...?

I've tried the examples, and they work fine in Chrome but not in Firefox 85 on Linux.

This is the error in the inspector console in Firefox.

Uncaught ReferenceError: SharedArrayBuffer is not defined
    SharedCircularBuffer SharedCircularBuffer.ts:64
    main_dom guess.html:350
    <anonymous> guess.html:600
SharedCircularBuffer.ts:64:17

HTMLConsole ?

• path_filestat_set_size - controls an unenumerated list of syscalls. Implementing for path_open, but does this mean I can't append either? or is it merely truncation that's problematic? Upstreamed discussion @ https://github.com/WebAssembly/WASI/issues/409
• poll_fd_readwrite - polling FDs not yet implemented at all

• wasm-pack support 2d282cf
• cargo web support f784cd1

Via annotations perhaps?

https://github.com/bytecodealliance/cargo-wasi

• Using a mixture of [WASI] and ### See Also hyperlinks, think I prefer the former.
• Excessive multi-line docs
• Decide upon a consistent enum doc style

monochrome-amber currently uses some text-shadow shenannigans to look better for bright-on-black colors, would be nice to make them conditional to avoid bluring "regular" text.

investigate / file issues / make dev nodes

Building hello-world * chrome * release frequently crashes wasm-opt:

                            Building HTML pages
     Running `C:\Users\MaulingMonkey\AppData\Local\.wasm-pack\wasm-opt-171374efd61df962\wasm-opt.exe --asyncify C:\local\cargo-html\examples\target\wasm32-wasi\release\hello-world.wasm --output C:\local\cargo-html\examples\target\wasm32-wasi\release\hello-world.async.wasm`
error: `C:\Users\MaulingMonkey\AppData\Local\.wasm-pack\wasm-opt-171374efd61df962\wasm-opt.exe --asyncify C:\local\cargo-html\examples\target\wasm32-wasi\release\hello-world.wasm --output C:\local\cargo-html\examples\target\wasm32-wasi\release\hello-world.async.wasm` failed: exit code -1073741819
error: process didn't exit successfully: `target\debug\cargo-html.exe html --manifest-path examples/Cargo.toml -p hello-world --release` (exit code: 1)
error: process didn't exit successfully: `xtask\target\debug\xtask.exe run -p cargo-html -- html --manifest-path examples/Cargo.toml -p hello-world --release` (exit code: 1)
The terminal process "C:\Windows\System32\cmd.exe /d /c cargo html -p hello-world --release" terminated with exit code: 1.

-1073741819 == C0000005 == Access Violation

The browser support table in the README lists iOS Safari | ✔️ 14.4+ (copy-pasted from lib.rs because the emoji doesn't copy-paste from the GitHub rendering) but, in my tests, (using a minimal HTML file that just uses a control string, a <noscript> element, and document.write), iOS 14.4.2 Safari seems to insist on running with JavaScript disabled when loading an HTML file off the internal storage via the Files app.

(I think it's just insisting on using the embeddable WebKit view without a means to load local files in full-blown Safari and, in typical iOS fashion, using "simple" UIs to make things ambiguous and confusing.)

This makes the README either very misleading (if the single-file HTML is only useful on iOS when served from a remote server), or in need of clarification on how to enable the supported configuration.

Even if JavaScript is unavailable on iOS Safari, I'd still be interested in using cargo-html if HTML+CSS without JavaScript or WebAssembly support is a supported configuration, since it'd mean I could retire the Python-based analogue to cargo-html that I hacked together for translating CSV-format "books to watch for a the used book store" lists into expandable/collapsible/filterable HTML outlines to be copied onto a phone with no SIM. (The output of which does work on Firefox for Android, pre-"you get the six extensions we like and you'll be happy with it" version but not in iOS Safari.)

A lot of work is done even if the build is up to date.

0. Rebuild typescript (cargo-html xtask / dev builds only)
   • npm install ... (300-400ms)
   • tsc ... (fast)
1. Initial wasm builds
   • cargo build ... spam (commands internally skip rebuilding / are fast)
   • wasm-pack spam (???)
   • cargo web spam (???)
2. Asyncification
   • wasm-opt spam (commands now explicitly skipped by 73494cb)
3. HTMLification
   • HTML generation (skipped by 8246b3c)

Tracking page: https://github.com/MaulingMonkey/cargo-html/wiki/WASI-syscalls

build, open, test?

https://github.com/WebAssembly/wasi-libc/blob/5ccfab77b097a5d0184f91184952158aa5904c8d/libc-bottom-half/sources/__wasilibc_initialize_environ.c

Looks like rust should be able to check environ...

cargo html --manifest-path examples/Cargo.toml -p quicksilver-demo appears to be invoking cargo build --target=wasm32-wasi --manifest-path examples/Cargo.toml --bins.

1. This isn't limited to the quicksilver-demo package
2. quicksilver-demo's bin is getting built despite not being WASI compatible

• Move use of +crt-static
• Remove tsc ... from vscode / ci
• More complicated integration testing?

https://github.com/bytecodealliance/wasmtime/tree/main/crates/test-programs/wasi-tests/src/bin
https://github.com/bytecodealliance/wasmtime/tree/9abae356e004d2f901eff6f3317625180180e864/crates/test-programs/wasi-tests/src/bin

• Easy to screw up endian
• Easy to write near-null values by accident
• ...?

CI has started failing. Related upstream issue implies this isn't a wasm-bindgen bug: rustwasm/wasm-bindgen#2554

Waiting until wip/cursor is merged

• asyncify_page_count
• const [a-z] regexp

There's currently no way to show a touchscreen keyboard to make console input usable.

Console might not fit sanely on screen, investigate scaling options etc.

Could use file/line/span information

wasm-pack --version frequently fails in CI. Possibly related to crashing wasm-opt ?

Currently the crate is only used to find/install wasm-opt. Either this should be slimmed down (it adds hundreds of dependencies!), or the crate should be used to replace the command line use of wasm-pack.

Internal elements can be generated by javascript

I should use this for things.

• Double down on console support. Make console games. Live a console life.
• New ecosystem. Make a fake graphics device. /dev/webgl? non-wasi syscalls?
• Hijack the wasm-bindgen ecosystem for fun and profit. fn main() { newcrate::run(async { ... }); } ?