Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support wasm32-unknown-unknown target #212

Open
jice-nospam opened this issue Mar 13, 2018 · 7 comments
Open

support wasm32-unknown-unknown target #212

jice-nospam opened this issue Mar 13, 2018 · 7 comments

Comments

@jice-nospam
Copy link

@jice-nospam jice-nospam commented Mar 13, 2018

This compile and runs fine with wasm32-unknown-unknown target, but doesn't produce any sound. Are you planning to support this target? Any idea why it doesn't work right now ?

@tomaka

This comment has been minimized.

Copy link
Collaborator

@tomaka tomaka commented Mar 13, 2018

Supporting the wasm32-unknown-unknown is "ideologically" wrong. Playing/recording sounds requires some knowledge about the environment (like which OS is running), and unknown, as it says, doesn't give any information. We could support it by making assumptions, but sooner or later that will probably backfire.

Instead we could support something like wasm32-unknown-web or wasm32-unknown-node or something similar. There are some active debates in the Rust community about this topic in general.

Also note that the emscripten target should already work.

@jice-nospam

This comment has been minimized.

Copy link
Author

@jice-nospam jice-nospam commented Mar 13, 2018

This makes sense. I was referring to supporting the web platform without emscripten. There's no wasm32-unknown-web target yet so that's mainly what wasm32-unknown-unknown is used for. So I guess it's a wait-and-see subject for now.

@newpavlov

This comment has been minimized.

Copy link

@newpavlov newpavlov commented Jan 25, 2019

It's possible to add wasm-bindgen and/or stdweb feature which users will have to enable in application crate to get support on wasm32-unknown-unknown, in a certain sense it will be an ersatz for the proper target triplet.

@nico-abram

This comment has been minimized.

Copy link

@nico-abram nico-abram commented Oct 5, 2019

Does the emscripten target actually work, at the moment? I don't get any sound when running cargo web start --example beep --target wasm32-unknown-emscripten (On firefox)

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.

@nico-abram

This comment has been minimized.

Copy link

@nico-abram nico-abram commented Oct 6, 2019

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.

@mitchmindtree

This comment has been minimized.

Copy link
Member

@mitchmindtree mitchmindtree commented Oct 7, 2019

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.

@nico-abram

This comment has been minimized.

Copy link

@nico-abram nico-abram commented Oct 25, 2019

Just dropping this here for anyone who missed it (Found it on the rust reddit) https://nannou.cc/posts/moss_grant_announce/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.