Wasm support

[Easyoakland]

I've got Wasm support mostly working at this repo.
I also updated to clapv4.

Since you can't spawn multiple processes in Wasm it's set up to use an async main and poll the resulting future concurrently with the gui as explained here.

The file functionality has to come from within the main function the user of the library provides since you have to read a full file to memory instead of being able to use paths directly. For example using rfd's AsyncFileDialog

Also since stdout, stderr, stdin, etc... can't be redirected without nightly I used a custom logger that writes any logs to the gui instead of stdout.

A demo which uses these changes is visible here

I don't know if there's interest in merging some of these features here or not, but I thought it was worth bringing to attention.

[mkatychev]

This is really nice, what would it take to some of the wasm support put upstream?

[Easyoakland]

• @mkatychev An upstream maintainer (I think this is @MichalGniadek) would have to be present and interested in merging it. I would be mostly willing to fix things as needed to make this happen, but I won't file a pull request until I see something indicating it might be merged.
• You should be able to use the fork as a git dependency (https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html). I'm not opposed to fixing issues filed on the fork, though keep in mind it's a hobby.
• I'm not interested in publishing the fork on crates.io, so if the issue is that you would like to publish a crate with the fork as a dependency, then yes that will rely on upstream merging since I believe crates.io has a policy of only depending on other crates on crates.io.

[mkatychev]

Thanks for the reply, I think up-streaming this addition would fare better than maintaining a fork. My question was more along the lines of what mutually exclusive compilation flags to do you foresee this would add (to for example handle wasm32 compilation targets)

[Easyoakland]

My question was more along the lines of what mutually exclusive compilation flags to do you foresee this would add (to for example handle wasm32 compilation targets)

I don't know what you mean. You compile with cargo build --target wasm32-unknown-unknown. You then serve the resulting wasm in your webpage. (Or use trunk or similar to mostly automate this).

[mkatychev]

I've gone through your changes, I think I answered my own question.