-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
[WIP] WASM demo #1746
[WIP] WASM demo #1746
Conversation
crates/ra_ide_api/src/change.rs
Outdated
@@ -134,7 +133,7 @@ impl LibraryData { | |||
root_id: SourceRootId, | |||
files: Vec<(FileId, RelativePathBuf, Arc<String>)>, | |||
) -> LibraryData { | |||
let symbol_index = SymbolIndex::for_files(files.par_iter().map(|(file_id, _, text)| { | |||
let symbol_index = SymbolIndex::for_files(files.iter().map(|(file_id, _, text)| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we should just #[cfg(feature = "wasm")]
this: rayon is pretty important for perf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean target_arch="wasm32"
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, good question....
I feel like it's better to use Cargo feature, but that's just a gut feeling, so I am fine either way!
crates/wasm_demo/src/lib.rs
Outdated
} | ||
|
||
pub fn update(&mut self, code: String) -> JsValue { | ||
// TODO: how to update analyisis source? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll need AnalysisHost
and AnalysisChange
for this, but re-creating on every change is surely fine for the first stab!
crates/wasm_demo/README.md
Outdated
|
||
cd www | ||
npm i | ||
npx webpack-dev-server --host 0.0.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, we should build a static page and host it on GH pages, like here: https://github.com/matklad/tom/tree/gh-pages
I've looked at it, and this looks awesome! Let's do two things before merging though:
|
#1747 makes the scaffold for gh-pages |
println!("linked list has length: {}", list.len()); | ||
println!("{}", list.stringify()); | ||
} | ||
` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing ;
and trailing newline.
wasm-pack will be needed to build the wasm-demo (https://rustwasm.github.io/wasm-pack/installer/), where should this be added? As is node/npm, but I guess this is already there for vscode tests. |
Yeah, we already require node, so we can assume it exists. Wasm pack should be installed by website gen using cargo install |
website/src/wasm-demo/www/index.js
Outdated
let allTokens = [] | ||
|
||
function update() { | ||
console.warn("update") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please end statements with ;
? While javascript allows it, only npm doesnt use them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the JS code is still formatted/structured badly, heck it even has warn's for logging and commented-out code.
The whole file needs some serious cleaning, but I was planning to do this after implementing most of the demo-able functionality.
// install wasm-pack if not available | ||
let res = Command::new("wasm-pack").arg("--version").status(); | ||
if res.is_err() { | ||
let status = cargo().args(&["install", "wasm-pack"]).status()?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest downloading https://github.com/rustwasm/wasm-pack/releases/download/v0.8.1/wasm-pack-v0.8.1-x86_64-unknown-linux-musl.tar.gz
instead and saving a lot of time when it is not cached. You can even easily check the version and there are binaries for other platforms too. This way you can also install it to a specific location and execute it from there so you know the version matches what you expect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flip side is that we'd have to implement our own caching logic, to avoid download on every local build. I think it makes sense to defer these concerns to cargo install
and travis own caching.
Ok, I think this looks good enough to lend now, but the branch needs rebasing |
@@ -0,0 +1,202 @@ | |||
// @ts-check |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we're running this through webpack anyway, why not use TS? (that shouldn't block this PR though 🙂 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that’s actually a really great idea! I’d love to get rid of webpack if possible though, but I guess Monaco needs it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, TypeScript makes more sense indeed. I just didn't want to add the extra dependencies to ts-loader + extra config required to make TS work for now.
As for webpack, monaco does require webpack-like semantics, such as importing CSS files into JavaScript. This can probably be done with another bundler instead, but probably won't work without any tool (or just tsc).
@JasperDeSutter looks like this still has some conflicts. Perhaps it would be easier to squash down the history here to a single commit and rebase that? |
4661321
to
2abc34b
Compare
@matklad done, everything should be up-to-date now |
Tested it locally, and it works! However, given the number of deps here and the size of the .wasm file, I feel it makes sense to move the whole website do the separate repository. I'll try to look into this today |
@@ -4,6 +4,9 @@ name = "ra_ide_api" | |||
version = "0.1.0" | |||
authors = ["rust-analyzer developers"] | |||
|
|||
[features] | |||
wasm = [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this is a feature? You should be able to just check for wasm via a normal cfg based on the target?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure which is better, but, with a feature, we can check that wasm build actually builds without needing to compile to wasm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, looks like you already had a discussion about this further up.
Nope, I won't get to this today sadly :( |
1888: allow compiling ra_ide_api on wasm r=matklad a=matklad bors r+ this is from #1746 Co-authored-by: Aleksey Kladov <[email protected]>
all credit goes to @JasperDeSutter rust-lang/rust-analyzer#1746
all credit goes to @JasperDeSutter rust-lang/rust-analyzer#1746
all credit goes to @JasperDeSutter rust-lang/rust-analyzer#1746
all credit goes to @JasperDeSutter rust-lang/rust-analyzer#1746
all credit goes to @JasperDeSutter rust-lang/rust-analyzer#1746
finally got to this! https://rust-analyzer.github.io/wasm-demo.html I've moved it to the separate repo, to avoid adding mulimegabyte blobs to the git history: https://github.com/rust-analyzer/rust-analyzer.github.io The setup is pretty horrible and could be improved |
Thank you so much for bringing this all together @JasperDeSutter ! |
I think completion is one of the many things that is not implemented. It
would be cool to get completion, go to definition and file outline working
though!
…On Fri, 20 Sep 2019 at 23:24, Laurențiu Nicola ***@***.***> wrote:
That's pretty cool, but does it work? I can't get completion to yield
anything useful, not even for the List type in the demo:
[image: image]
<https://user-images.githubusercontent.com/308347/65356695-c59b2a00-dbfd-11e9-93ff-fd93fdcc14ab.png>
[image: image]
<https://user-images.githubusercontent.com/308347/65356709-d0ee5580-dbfd-11e9-9e32-40224b7d84a6.png>
[image: image]
<https://user-images.githubusercontent.com/308347/65356725-d6e43680-dbfd-11e9-9014-fbc8ce7006b2.png>
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#1746>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANB3M27ZHLROZWP3YGXGMLQKUWRRANCNFSM4ISYHU6Q>
.
|
all credit goes to @JasperDeSutter rust-lang/rust-analyzer#1746
This is a stab at #1007, having a monaco editor with rust-analyzer running in WASM.
features:
Issues when running ra_ide_api in wasm:
as for the implementation:
Started from a standard wasm-bindgen template, as explained here: https://rustwasm.github.io/docs/book/game-of-life/hello-world.html
Currently the code is executed on the main thread (not a webworker), this might be added later when things become too slow. Also, when trying this before, there was a webpack issue which generated a wrong bundle for webworkers.
value passing JS -> WASM happens through arguments for ease of use, and WASM -> JS uses serde_wasm_bindgen. This was the most ergonomic way to work with structured data, but might leave some performance on the table.
logs are filtered to
Level::Warn
, because the abundance ofInfo
logging really slows down everything a lot though theconsole_log
logger.It's a pain to try to figure out monaco's API's and how they differ from the vscode/LSP ones. The bad documentation makes me resort to plowing through the npm package code...
Still very much work-in-progress here, but I'm looking for feedback already to be sure.