Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
support wasm32-unknown-unknown target #212
Instead we could support something like
Also note that the
Does the emscripten target actually work, at the moment? I don't get any sound when running
I tried updating stdweb, but I still couldnt get it to work. As someone suggested here, I tried adding a feature that makes wasm32-unk-unk use the emcripten host instead of null, and, surprisingly, it seems to actually work.
That being said, updating stdweb basically raised 2 problems: set_timeout now has a 'static bound on its parameter, and event_loop no longer returns never (!).
The second problem is solved easily enough by adding a js exception and an unreachable to satisfy rust's type system. I think the reason for that change is that on wasm32-unknown-unknown event_loop does nothing and instantly returns.
The other problem is, I think, a bit more serious. I don't think the current casting using a Box I'm doing here is entirely sound, but it is the only thing I believe we can do without changing the API (Also, I don't think the lack of the static requirement on the older version makes things any better - The underlying browser API we're calling is the same, if anything I think the old binding was just plain wrong. So it's not like we're doing anything worse with my changes, I think)
Here's what I did: nico-abram@17f84ec
I haven't opened a PR since I don't think there's an agreement to use web apis on unk-unk under a feature flag (At least yet?) and because of the issues (Specially around 'static) I mentioned.
I was under the impression that the stdweb::web::set_timeout without the 'static on old stdweb was unsound, so I asked in the #wg-wasm channel in the official rust discord. Someone told me that it is, in fact, unsound. So I don't think my changes make the issue worse, only explicitly require us to use unsafe to pretend the closure that should be static is.
I just wanted to add that I'll be doing a deep dive into solving CPAL's web audio support soon as a part of an upcoming funded project which I can hopefully release some more info on soon. The plan is to investigate the feasibility of each of the possible web targets, decide exactly what targets cpal can/should support, ensure their implementation(s) are on par with the other platforms, write a decent usage guide and solicit some review and feedback from the community. The current plan is to be tackling this towards the beginning of Nov, while focusing on some preceding work like assisting with landing #301 and addressing #119, #279, #205 later this month. I'll post some more info soon.