Basic WebAssembly support with minimal Javascript API #615 #1986
Conversation
|
Very impressive, thank you a lot! Compilation for WASM seems worth mentioning in the |
|
Ok! I'll try. Also I noticed that section about native installing on windows is a bit outdated because now a simple Also, I have an impression that to do serious constraint programming with prolog on the web, swi-prolog was the only choice (I don't think tau-prolog supports |
|
Now README.md is updated. Can this be merged soon? Since I'll probably be unable to modify this within a week or so... very busy with a tricky large-scale C++ refactor :-S |
README.md
Outdated
| @@ -145,6 +145,88 @@ It will generate a very basic MSI file which installs the main executable and a | |||
|
|
|||
| Scryer Prolog must be built with **Rust 1.63 and up**. | |||
|
|
|||
| ### Building WebAssembly | |||
|
|
|||
| Scryer Prolog has basic WebAssembly support. However, none of the default features are currently supported. You can manually change the default features in `Cargo.toml` from | |||
There was a problem hiding this comment.
No need to edit Cargo.toml --no-default-features command line flag or default-features = false in [dependencies] should be sufficient
There was a problem hiding this comment.
Should work with wasm-pack build as an extra option.
There was a problem hiding this comment.
Should work with
wasm-pack buildas an extra option.
I agree that passing --no-default-features to wasm-pack should theoretically work and is the recommended way. I even mentioned it in my other PR #1966.
However, it doesn't work on my PC (windows 10). I don't know why. wasm-pack seemed to ignore all extra parameters including --offline. I had to do a regular cargo build --offline and let wasm-pack "remember" I was using --offline last time. And I feel bad to write something in README.md that doesn't work for myself...
After some struggle I wrote down these silly instructions that at least should work for everyone. Anyway, writing the recommended way should be better. Do you think I should keep the workaround in case anyone else is facing the same problem, or remove it for now until I find the real cause on my side? I couldn't find any similar issue on github or stackoverflow so probably I'm the only one having this issue? 8-)
There was a problem hiding this comment.
@rujialiu: Personally, I think the instructions @Skgland posted seem preferable because they do not require any changes in existing files. If these instructions should work, but do not work for you, then could you please consider filing this as an issue in the wasm-pack repository so that others will also benefit from the correction? Thank you a lot!
There was a problem hiding this comment.
Just to add: I think none of this is any reason to delay merging this PR, because we can easily tweak the instructions at any time! To me, it seems preferable to merge this work as soon as possible so that other PRs can already take it into account.
|
Why are the CI tests now suddenly failing? Is this due to conflicting changes that have since been merged? |
Looks to me like the CI runners had Network issues |
|
@Skgland: How can we trigger the CI tests again? I think everything works as intended with these changes, but the failed tests make it appear as if there were still a problem with them! |
|
https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs should explain this though I don't know if anyone besides @mthom has sufficient access rights (write access) to do it. |
|
Alternatively one could push a new commit to trigger a new CI run. If there are no further change to incorporate into an additional commit, one could for example rebase on master and then force push with lease the rebased commits. |
|
@rujialiu: Could you please consider doing this, i.e., rebasing, so that this PR is clearly visible as passing all CI tests? This may be a good opportunity to also apply two small typographic corrections to the README changes:
The PR looks great in all other respects. Thank you a lot! |
Ok! I'll do this when I have some time. I need to look at how to resolve conflicts first. |
…ently 6/12 crypto functions supported. Tested in browser with all default features disabled.
rujialiu
force-pushed
the
wasm32-support
branch
from
6863988 to
b6ce6b7
Compare
|
Done. It turns out that the confusing conflicts are from |
|
Aaaaaw yes, please consider announcing this in the discussions, and thank you so much @rujialiu !!! |
Ok! Will do it when I have some time! |
Currently 6/12 crypto functions supported. Tested in browser with all default features disabled.