profile
viewpoint
Till Schneidereit tschneidereit @mozilla Berlin, Germany https://twitter.com/tschneidereit

issue commentbytecodealliance/wasmtime-py

Publish wheels to GitHub releases

I just realize that perhaps this is perhaps mostly useful with a "moving tag release" (a Term I just made up) like the dev release we have for Wasmtime. But since we don't have that for wasmtime-py, maybe there's less value in this than I initially thought.

tschneidereit

comment created time in a day

Pull request review commentbytecodealliance/wasmtime-py

Make the README a little more clear and neat, and add a link to flake8

  ## Installation -You can install this extension via:+To install wasmtime-py, run this command in your terminal: -```-pip install wasmtime+```bash+$ pip install wasmtime ``` -Currently only x86\_64 Windows, macOS, and Linux are supported for this Python-extension.+The package currently supports x86\_64 Windows, macOS, and Linux.

(The 3.6+ is anticipating the merge of #21, of course)

tobych

comment created time in 3 days

Pull request review commentbytecodealliance/wasmtime-py

Make the README a little more clear and neat, and add a link to flake8

  ## Installation -You can install this extension via:+To install wasmtime-py, run this command in your terminal: -```-pip install wasmtime+```bash+$ pip install wasmtime ``` -Currently only x86\_64 Windows, macOS, and Linux are supported for this Python-extension.+The package currently supports x86\_64 Windows, macOS, and Linux.

Would it make sense to also state the Python requirements here? I.e. "The package currently supports 64-bit builds of Python 3.6+ on x86_64 Windows, macOS, and Linux"? (We do have Aarch64 support, too, but it seems like the install story there isn't yet fully sorted out.)

tobych

comment created time in 3 days

issue openedbytecodealliance/wasmtime-py

Publish wheels to GitHub releases

Before splitting out wasmtime-py into its own repository, we also published the wheels to the Wasmtime releases. It'd be nice if we could do that again in this repo.

created time in 3 days

issue commentbytecodealliance/wasmtime-py

Compilation error: Implementation limit exceeded

That's probably bytecodealliance/wasmtime#1734, so should hopefully be fixed once that PR lands.

@alexcrichton would it be feasible to have wasmtime-py respect RUST_LOG?

whitequark

comment created time in 6 days

issue commentbytecodealliance/wasmtime

Add build instructions for Aarch64 cross-compilation

* This is typically extremely difficult to obtain on macOS and Windows.

Oh, and this is where the "if feasible" comes in :)

tschneidereit

comment created time in 9 days

issue commentbytecodealliance/wasmtime

Add build instructions for Aarch64 cross-compilation

@alexcrichton thank you for the explanation, that makes a lot of sense. Based on this Twitter thread, I tried building for Aarch64 myself, and honestly simply didn't know where to even begin. If there is good general documentation, perhaps we could link to that in our docs? Something like "follow this general guide, then take these exact steps for Wasmtime, specifically".

Also, I just realized that it'd be good to have this both for building the shared library and CLI, and for embedding in other Rust projects. I think the ladder is what @autodidaddict, @dlmanning, and @squillace are talking about in that Twitter thread.

tschneidereit

comment created time in 9 days

issue commentbytecodealliance/wasmtime

Support arm (non tier 1) platforms

@brooksmtownsend thank you for reporting this! I think v0.15.0 might indeed be too old: I think the new backend hadn't landed by then, and we certainly didn't do aarch64 builds in CI. We do do that by now, see the dev and v0.16.0 releases.

However, the cross-compilation process isn't documented (at least that I could find). I just filed #1720 to rectify that. Here's the patch that added aarch64 builds to CI, in case you're interested.

jacobrosenthal

comment created time in 10 days

issue commentbytecodealliance/wasmtime

Add build instructions for Aarch64 cross-compilation

Oh, and ideally we'd have this for both Wasmtime and Cranelift, but those are probably separate tasks.

tschneidereit

comment created time in 10 days

issue openedbytecodealliance/wasmtime

Add build instructions for Aarch64 cross-compilation

We're creating aarch64 builds in CI, but for people wanting to do so themselves using cross-compilation, it's hard to figure out how.

We should have documentation for how to do this for at least x64 Linux, but ideally also macOS and, if feasible, Windows.

CC @alexcrichton

created time in 10 days

push eventbytecodealliance/wasmtime.dev

Daz Wilkin

commit sha d31240470c1b5d48b8d1c749622e92a0e8cc3481

Nit: Switch to `./wasmtime` to run `cargo build` (#6)

view details

push time in 11 days

issue commentbytecodealliance/wasmtime

WASI: expand networking functions

But we still want BSD sockets :)

As @pchickey said, low level sockets do make sense. I'm not aware of anyone currently driving the process of working out a proposal for a WASI module. If that's something you'd be interested in helping drive, opening an issue in the WASI spec repository might make sense. See the recent issue on WASI-nn as an example. (Though of course something not as fully fleshed out definitely works as a starting point!)

We'd be happy to provide help with implementations in Wasmtime, be they experimental to support the standards process, or production-quality to already serve use cases!

npmccallum

comment created time in 12 days

issue commentbytecodealliance/wasmtime

Support arm (non tier 1) platforms

@brooksmtownsend we'd love to hear how things are going, so it'd be great if you could report back here. Do note that #1494 just landed, so ARM64 support is quite new, which might mean running into early-adopter issues. Which mostly means that hearing how things are going would be even more appreciated :D

jacobrosenthal

comment created time in 14 days

push eventbytecodealliance/wasmtime

Cerberuser

commit sha f5eab5225fbd9e119353b90a656e3eff1de1d087

Fixed links in compare-llvm.md (#1690) Several links were broken by line-breaks between the link caption and the link itself. This commit fixes them by moving each on its own line. Co-authored-by: k.bagrov <k.bagrov@g.nsu.ru>

view details

push time in 14 days

PR merged bytecodealliance/wasmtime

Fixed links in compare-llvm.md cranelift cranelift:docs

Several links were broken by line-breaks between the link caption and the link itself. This PR fixes them by moving each on its own line.

+8 -7

1 comment

1 changed file

Cerberuser

pr closed time in 14 days

issue commentbytecodealliance/wasmtime

Cranelift 0.63: Breaking Unwind API

To clarify, I do agree that Cranelift should eventually get a better story for documenting breaking changes. More importantly, it should get a somewhat more stable API and reduce the amount of breaking changes. That should probably happen before a 1.0 release, but we don't have firm plans for either at this time.

@jyn514, in the meantime, I'm curious to hear more about how you think a change log would help. The tls example seems like it'd be addressed better by improving the API docs, and I'm not entirely sure what a change log would've contained that'd have helped here.

The best I can come up with is something like "Add TLS (thread local storage) support for ELF targets to Cranelift", as the PR says, but would that have helped in figuring out what to pass for your usage of declare_data? ISTM that anything beyond that should really be API docs, but perhaps there's a way to address this that's reasonably low-effort and better than API docs?

syrusakbary

comment created time in 23 days

issue commentbytecodealliance/wasmtime

Support Emscripten

That'd be a theoretical option, but a) it'd amount to a global switch making everything insecure, which we don't think is a good idea, and b) the ABI has other issues, as described in the post I linked to, so it's not just the security issue that made us decide not to support it.

redradist

comment created time in a month

issue closedbytecodealliance/wasmtime

Support Emscripten

Feature

It would be nice if wasmtime add support applications that compiled with Emscripten Toolchain

Benefit

It would be possible to run application compiled with Emscripten

Alternatives

There are other run-time that support WASI, but it also supports Emscripten like https://github.com/wasmerio/wasmer

closed time in a month

redradist

issue commentbytecodealliance/wasmtime

Support Emscripten

We explicitly decided not to support the Emscripten ABI in Wasmtime. The WASI announcement post contains an explanation of the important differences, and in particular the safety guarantees that WASI runtimes can make.

The most important reason for not also supporting the Emscripten ABI is that as soon as a runtime also supports an ABI that doesn't make those guarantees, you can no longer trust any content executed by that runtime in the same way.

I'll close this issue, and hope this explanation makes sense!

redradist

comment created time in a month

issue commentbytecodealliance/wasmtime

Cranelift 0.63: Breaking Unwind API

However, I feel some of the breaking changes in Cranelift have been taken with only wasmtime in mind and no input from external users.

I will repeat what I said in that tweet: even if we wanted to, which we don't, we couldn't possibly only take Wasmtime into consideration when making changes to Cranelift, because we have other projects that are very high priority, with Firefox being one of them.

As you can no doubt tell, Cranelift is undergoing significant changes right now. I appreciate that those cause work for downstream projects. Given that we're very much not making any API (or behavior) stability guarantees yet, I don't think us putting in the extra work of breaking out documentation of larger changes into a changelog would make a meaningful difference to the amount of work required to keep up, either.

One way to avoid that churn is to wait it out and stick to a specific version of Cranelift until things have settled down a bit.

syrusakbary

comment created time in a month

issue commentbytecodealliance/wasmtime

Finish implementing x86 32-bits

Thank you for bringing this up, and for starting to work on it!

I at least wasn't aware of the unfortunate situation with 64-bit Python on Windows, which I agree makes this more important.

One thing to be aware of is that we're in the middle of a pretty big change to Cranelift, involving a rewrite of the instruction selector (and register allocator, but I don't think that's too important here.) I'm not sure how that factors in, but @cfallin, @bnjbvr, or @julian-seward1 would.

htfy96

comment created time in a month

issue commentbytecodealliance/wasmtime

Debugging C/C++ WASM code doesn't work

Oh, of course. I wonder if we could warn about this somehow. @yurydelendik could we do something like detect that a debugger is attached and warn if we don't have debug info for the JITted code?

TerryGuo

comment created time in a month

issue commentWebAssembly/tool-conventions

Documentation Section

FWIW, we plan on doing something like this for the Rust toolchain. I don't think we have a firm timeline for it, though.

lachlansneff

comment created time in a month

issue commentbytecodealliance/wasmtime

Debugging C/C++ WASM code doesn't work

CC @yurydelendik

TerryGuo

comment created time in a month

issue commentbytecodealliance/wasmtime

arm32 support

Indeed! \o/

Note that it's not yet entirely complete, and not passing the entire test suite. It's getting close, though!

jmkrauz

comment created time in a month

issue commentbytecodealliance/wasmtime

Don't set warnings as errors in Rust nightly builds in CI

I think this makes sense, yes. We should probably still keep warn-as-error for beta and release builds, meaning we would still get breakage unrelated to changes, but much more rarely.

If we don't have warn-as-error anywhere, I fear we'll quickly see a lot of warnings creep up, making it harder to discern things that should really be addressed from those we don't care about.

bnjbvr

comment created time in a month

issue commentbytecodealliance/wasmtime-demos

Getting an error when I tried the dotnet demo on .net core 3.1

what do we think about retiring this repo in favor of essentially copying the demo as a walkthrough into each wasmtime-<lang> repo?

I think that makes a lot of sense!

ajbennet

comment created time in a month

issue commentbytecodealliance/wasmtime-demos

Getting an error when I tried the dotnet demo on .net core 3.1

CC @peterhuene, who'll have the most insights here.

ajbennet

comment created time in a month

Pull request review commentbytecodealliance/wasmtime

Automatically label Cranelift new-backend PRs as such

 "cranelift:wasm":   - "cranelift/wasm/**"   - "cranelift/wasmtests/**"+  +"cranelift:area:aarch64":+  - "cranelift/codegen/src/machinst/*"

Ok, that makes sense :)

bnjbvr

comment created time in a month

pull request commentWebAssembly/js-types

Merge with upstream.

I don't have write access, but I bet @rossberg does :)

Ms2ger

comment created time in a month

Pull request review commentbytecodealliance/wasmtime

Automatically label Cranelift new-backend PRs as such

 "cranelift:wasm":   - "cranelift/wasm/**"   - "cranelift/wasmtests/**"+  +"cranelift:area:aarch64":+  - "cranelift/codegen/src/machinst/*"

Isn't machinst ISA independent? I.e., won't this labeling be wrong as soon as work on supporting other ISAs for the new isel framework picks up?

bnjbvr

comment created time in a month

push eventbytecodealliance/wasmtime.dev

bjorn3

commit sha f1e376f0f34847e6bf35e81d458db1df1c6efb2c

Don't try to install wasm2obj (#5) It doesn't exist anymore

view details

push time in a month

PR merged bytecodealliance/wasmtime.dev

Don't try to install wasm2obj

It doesn't exist anymore

Fixes https://github.com/bytecodealliance/wasmtime/issues/1552

+1 -1

0 comment

1 changed file

bjorn3

pr closed time in a month

issue closedbytecodealliance/wasmtime

Installation script fails because wasm2obj is not in the archive

Hi, I wanted to try wasmtime (on opensuse 15.1 x86_64) so I simply ran the install script as described on the project homepage

curl https://wasmtime.dev/install.sh -sSf | bash
  Installing latest version of Wasmtime (dev)
    Checking for existing Wasmtime installation
    Fetching archive for Linux, version dev
https://github.com/cranestation/wasmtime/releases/download/dev/wasmtime-dev-x86_64-linux.tar.xz 
######################################################################## 100.0% -#O#-  #   #                                                                 
    Creating directory layout
  Extracting Wasmtime binaries
wasmtime-dev-x86_64-linux/
wasmtime-dev-x86_64-linux/README.md
wasmtime-dev-x86_64-linux/wasmtime
wasmtime-dev-x86_64-linux/LICENSE
cp: cannot stat '/tmp/tmp.2lBZFrJIZA/wasmtime-dev-x86_64-linux/wasm2obj': No such file or directory

Indeed, it turns out wasm2obj is not in https://github.com/cranestation/wasmtime/releases/download/dev/wasmtime-dev-x86_64-linux.tar.xz (I also checked https://github.com/bytecodealliance/wasmtime/releases/download/v0.15.0/wasmtime-v0.15.0-x86_64-linux.tar.xz)

tar tvf wasmtime-dev-x86_64-linux.tar.xz yields:
drwxr-xr-x runner/docker     0 2020-03-31 23:54 wasmtime-v0.15.0-x86_64-linux/
-rwxr-xr-x runner/docker 13738648 2020-03-31 23:54 wasmtime-v0.15.0-x86_64-linux/wasmtime
-rw-r--r-- runner/docker    12243 2020-03-31 23:54 wasmtime-v0.15.0-x86_64-linux/LICENSE
-rw-r--r-- runner/docker     3684 2020-03-31 23:54 wasmtime-v0.15.0-x86_64-linux/README.md

The install script fails on this line

  # copy the files to the specified directory
  # binaries go into the bin folder
  cp "$extracted_path/wasmtime" "$extracted_path/wasm2obj" "$copy_to/bin"

Is the content of the archive incorrect or is wasm2obj no longer needed ?

closed time in a month

laaglu

issue commentbytecodealliance/wasmtime

Support MinGW as a wasmtime target

That makes a lot of sense to me, yes. Thank you for the clarification!

alexcrichton

comment created time in a month

issue commentbytecodealliance/wasmtime

Support MinGW as a wasmtime target

Ah, I now see the wasmtime-go issue. I guess the question is how many people will want to run Go programs on Windows, which I don't have a good handle on.

alexcrichton

comment created time in a month

issue commentbytecodealliance/wasmtime

Support MinGW as a wasmtime target

Do you know how complicated that would be initially—and how much of a maintenance burden it'd be on an ongoing basis? If neither is a concern, this makes sense to me. Otherwise, I think we should let the be driven by use cases.

alexcrichton

comment created time in a month

issue commentbytecodealliance/wasmtime

Setting vmemoryuse to 3G causes OOM errors

IIUC, this is probably caused by an optimization Wasmtime/Cranelift, just as some other WebAssembly runtimes, employs: instead of doing explicit bounds checks for all memory accesses, the runtime reserves 8GB of guard pages before and after a Wasm instance's memory, which are marked as PROT_NONE, triggering a trap on access, which is then handled by the runtime. For more details, see this write-up an implementation plan for V8.

CC @sunfishcode, who knows infinitely more about this than me :)

As an aside, Perlwasm is very exciting! 🎉

plicease

comment created time in a month

issue commentbytecodealliance/wasmtime

Support for Interface Types in wasmtime API

I don't think that interface types are the place to push UTF-8

Note that when it comes to Interface Types, we'll implement what gets standardized, so if the Interface Types proposal ends up only supporting UTF-8, then we'll only implement that. I.e., arguments for additional encoding should be made to the WebAssembly CG, not here.

alexcrichton

comment created time in 2 months

pull request commentbytecodealliance/wasmtime

Add Go as an embedding to the book

I think including the embeddings in the README is a very good idea! And I also like how you linked to things, so 👍 from me!

alexcrichton

comment created time in 2 months

issue commentbytecodealliance/wasmtime

linking: multiple memories error

cc @alexcrichton

Alphapage

comment created time in 2 months

issue commentbytecodealliance/wasmtime

OCI-compatible proposal for wrappering wasmtime

Microsoft's Krustlet project might be a better approach, depending on details of your use case.

If that doesn't work, note that we'll have Go bindings for Wasmtime soon, too.

leonwanghui

comment created time in 2 months

issue commentbytecodealliance/wasmtime

Why not publish wasmtime-cli itself?

Oh, hah—serves to show how it's been since I tried this! @clouds56, my apologies for the misinformation.

@alexcrichton that sounds good to me, yes.

clouds56

comment created time in 2 months

issue commentbytecodealliance/wasmtime

Why not publish wasmtime-cli itself?

cargo install wasmtime installs the cli, so that should work as expected.

However, using the installer as described on wasmtime.dev has advantages, such as not needing to compile, and setting up a directory for a cache which makes uses of the same .wasm file much faster after the first compile.

clouds56

comment created time in 2 months

push eventbytecodealliance/wasmtime-demos

Samrat Man Singh

commit sha 33c7ecc50631a49bf0817a3ee5dcd8e43844a632

Rename REAMDE.md to README.md

view details

Till Schneidereit

commit sha 5e2c642bd0ef94e222dc598f30aae63e771af2f3

Merge pull request #20 from samrat/patch-1 Rename REAMDE.md to README.md

view details

push time in 2 months

push eventbytecodealliance/wasmtime

Prathyush

commit sha e2f6c0805231daa0524d7c770d11ced6dfe961a2

Remove superfluous are (#1326)

view details

push time in 2 months

PR merged bytecodealliance/wasmtime

Remove superfluous are

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

This is a simple grammatical fix on the prose.

+1 -1

0 comment

1 changed file

prathyvsh

pr closed time in 2 months

push eventbytecodealliance/wasmtime

Samrat Man Singh

commit sha 66aec23a0bb45a0bbe53eb7e9f722fd691af483e

Fix typo in comment (#1324)

view details

push time in 2 months

PR merged bytecodealliance/wasmtime

Fix typo in comment
+1 -1

0 comment

1 changed file

samrat

pr closed time in 2 months

push eventbytecodealliance/wasmtime

Jakub Konka

commit sha 02c31691513ef7d60f868128320e316db5dd00e8

Autolabel wasi-common PRs as wasi (#1279) It seems we missed that one in the labeler, so adding now.

view details

push time in 3 months

PR merged bytecodealliance/wasmtime

Reviewers
Autolabel wasi-common PRs as wasi

It seems we missed that one in the labeler, so adding now.

+1 -0

0 comment

1 changed file

kubkon

pr closed time in 3 months

pull request commentbytecodealliance/wasmtime

Write .debug_frame information

Ok, makes sense. Should we perhaps close this PR and you open a new one with that new purpose, though?

yurydelendik

comment created time in 3 months

MemberEvent

issue commentbytecodealliance/wasmtime

Master branch seems to have lost a dependency

Indeed, initializing submodules was missing from the build instructions. I created #1258 to address that.

icefoxen

comment created time in 3 months

PR opened bytecodealliance/wasmtime

Reviewers
Add instructions to initialize git submodules to build docs

Simple docs fix for #1229.

+10 -0

0 comment

1 changed file

pr created time in 3 months

create barnchtschneidereit/wasmtime

branch : fix-build-docs

created branch time in 3 months

pull request commentbytecodealliance/wasmtime

cranelift-module: expose trap information when defining functions

Lets get @tschneidereit to add you as a collab so you can merge these when they're ready to go

Agreed!

froydnj

comment created time in 3 months

issue openedbytecodealliance/wasmtime

Should fuzzing be re-enabled in test-all.sh?

In #580, fuzzing was disabled in the test-all.sh script. Should it be re-enabled now that the blocking issue is resolved?

CC @sunfishcode

created time in 3 months

pull request commentbytecodealliance/wasmtime

[cranelift] Fix repository link in Cranelift's Cargo.toml

The patch should now address all relevant mentions of the Cranelift repository. Those that still exist are to issues and pull requests that were closed before the merger, and shouldn't be updated, or part of meeting notes, which I think also shouldn't be updated.

tschneidereit

comment created time in 3 months

push eventtschneidereit/wasmtime

Alex Crichton

commit sha 8597930eed2e5e92c78ec4cb6d6b39d80c5ea220

rename PassiveElemIndex to ElemIndex and same for PassiveDataIndex (#1188) * rename PassiveElemIndex to ElemIndex and same for PassiveDataIndex (#1411) * rename PassiveDataIndex to DataIndex * rename PassiveElemIndex to ElemIndex * Apply renamings to wasmtime as well * Run rustfmt Co-authored-by: csmoe <csmoe@msn.com>

view details

Takanori Ishibashi

commit sha 3848bf54f750914924fd6f880ec058460f4a8c34

Fix link (#1203)

view details

Darin Morrison

commit sha 2300eec8a52e9450077cb737dbc814471e7615b2

Implement hex parsing for imm16 and imm32

view details

Darin Morrison

commit sha c459579396c81bce1c98e30ddc944bb56994ddb6

Add tests for hex parsing

view details

Darin Morrison

commit sha d68437e1e6415d62116829dcf18f94b9070230e0

Update SIMD tests to use hex literals

view details

Alex Crichton

commit sha fe9debfed377c61cfd79b49e9eff0feb080b6d99

Update WASI submodule to update transitive wast crate (#1207) One less version to build!

view details

Alex Crichton

commit sha f7c2a58d236bf23819139930bf1e469a47e08140

Disable caches in CLI tests (#1204) Avoids creating extraneous directories while testing in your home directory. Closes #1197

view details

Yury Delendik

commit sha 732c646bec77d0ccd4c8b9df7a77619aee747ded

Add wasmtime.h and wasi.h to package (#1211)

view details

Alex Crichton

commit sha 77e17d8f7119191f5fd46640e2f110d157b3258c

Add a wasmtime-specific `wasmtime_wat2wasm` C API (#1206) * Add a wasmtime-specific `wasmtime_wat2wasm` C API This commit implements a wasmtime-specific C API for converting the text format to the binary format. An upstream spec issue exists for adding this to the C API, but in the meantime we can experiment with our own version of this API and use it in the C# extension, for example! Closes #1000 * Reorder arguments * Use wasm_byte_vec_t for input `*.wat` * Mark wat input as const * Return an error message and use `fixed` * Actually include the error message * Use `fixed` in `Module.cs` as well

view details

Nathan Froyd

commit sha 0f49a830c9fc597f03b060493c3db79f3ab68b22

cranelift-module: expose trap information when defining functions The current interface of `cranelift-module` requires consumers who want to be informed about traps to discover that information through `Module::Product`, which is backend-specific. Since it's advantageous to manipulate this information in a backend-agnostic way, this patch changes `Module::define_function{,_bytes}` to return information about the traps contained in the function being defined.

view details

Ryan Hunt

commit sha 07f335dca6a50cd8f7bcb850d3a5681755f08261

Rename 'an block' to 'a block' Missed this in the automatic rename of 'Ebb' to 'Block'.

view details

Peter Huene

commit sha 1a15cec63bd75a68c8af0c457922d2e57db6de96

Merge pull request #1217 from eqrion/kill-ebb/typos Rename 'an block' to 'a block'

view details

Maciej Woś

commit sha 8acfdbdd8aa550d1b84e0ce1e6222a6605d14e38

add more wrappers and getters (#1222)

view details

Yury Delendik

commit sha d5c0f6bff8a2f96f8c1b55f2e079dceba95e0c1e

Fix infinite loop in DWARF address transform algorithm (#1228)

view details

Alex Crichton

commit sha 19d8ff2bf50a96976a8ed57d3c90c2bc230c3fd0

Remove reader_parse_test/translate_module fuzz targets (#1212) This commit removes the two fuzz targets that we imported from cranelift when cranelift merged in. These have both uncovered a few issues in the fuzz targets themselves, for example: * `translate_module` - this doesn't verify the wasm is valid a head of time and cranelift is known to panic on translating invalid wasm modules. We also already do a lot of fuzzing of translation of wasm modules, so this isn't necessarily buying us anything over what we're already fuzzing. * `reader_parse_test` - discovered in #1205 we already found some "bugs" in this but it may not necessarily rise to the level of "needs to be run on oss-fuzz for us to find more bugs" yet. It looks like this is still somewhat internal so we can re-enable when we've got folks to fix the fuzz bugs coming in. Closes #1205

view details

Jakub Konka

commit sha 135a48ca7e9a45d7d31911753e602e6de8b14e2a

wasi-common error cleanup: part 1, yanix (#1226) * Reuse std::io::Error for raw *nix errno This commit removes custom `yanix::Errno` and instead (as was previously suggested) reuses `std::io::Error` to generate and wrap raw *nix errno value. * Update wasi-common to use new Yanix error type This commit updates `wasi-common` to use new way of handling raw OS error in `yanix`; i.e., via re-use of `std::io::Error` instead of a custom `Errno` enum. * Fix formatting * Unwrap if io::Error created from raw OS error This commit calls `unwrap` on `err` if that one was created via `io::Error::last_os_error()`. It also refactors error matching in several syscalls on the BSD platform (mainly).

view details

Ryan Hunt

commit sha 4aa8776a9bb47f5ac9c1ab2f7201ebe815ecc8e3

Skip non-branching blocks now that we're using basic blocks This is a rebase of [1]. In the long term, we'll want to simplify these analysis passes. For now, this is simple and will reduce the number of instructions processed in certain cases. [1] https://github.com/bytecodealliance/cranelift/pull/866

view details

Nathan Froyd

commit sha 2bb309634217268c16e5558319d9b7b78e78c61e

change interfaces to use slices instead of `Vec`

view details

Yury Delendik

commit sha 6f88fd9af110d9aae6ae4c09f445801250baa45f

Disable/ignore debug_dwarf tests in "cargo test" (#1233)

view details

Nick Fitzgerald

commit sha ab317bc0dd063b38b0e91ae0380ee24e19d65a64

CI: Run fuzzer corpora with `RUST_BACKTRACE=1` This way if we get regression panics -- like in https://github.com/bytecodealliance/wasmtime/pull/1192 -- then we actually have some hope of debugging them properly.

view details

push time in 3 months

push eventbytecodealliance/wasmtime

Dan Gohman

commit sha fbe29da5cc1c0847af176f151f114a6a535534ff

Miscelaneous docs updates and fixes. (#1249) Update references to things in CraneStation which have moved, WASI documentation which has moved to the WASI repo, and fix a few typos.

view details

push time in 3 months

delete branch bytecodealliance/wasmtime

delete branch : docs-misc

delete time in 3 months

PR merged bytecodealliance/wasmtime

Miscelaneous docs updates and fixes. wasmtime

Update references to things in CraneStation which have moved, WASI documentation which has moved to the WASI repo, and fix a few typos.

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+30 -2437

0 comment

17 changed files

sunfishcode

pr closed time in 3 months

push eventbytecodealliance/wasmtime

Till Schneidereit

commit sha 0afa334f3e68c029ec93e9d6762796ada2a810b6

Update issue templates - Include the `cranelift` label for Cranelift bug reports - Add a Wasmtime bug report template

view details

push time in 3 months

pull request commentbytecodealliance/wasmtime

Write .debug_frame information

@yurydelendik what's the status of this PR, are there parts that we should still land, or is this superseded by things that landed in the meantime?

yurydelendik

comment created time in 3 months

push eventbytecodealliance/wasmtime

Alex Pyrgiotis

commit sha 07212780d3136a206480796be7281e8508dd1ddb

CI: Use an HTTPS download link for LLVM (#1254)

view details

push time in 3 months

PR merged bytecodealliance/wasmtime

CI: Use an HTTPS download link for LLVM

Since releases.llvm.org has an HTTPS endpoint as well, there's no reason not to use it.

+1 -1

0 comment

1 changed file

apyrgio

pr closed time in 3 months

issue closedWebAssembly/wasi-libc

Environment variables are broken

I just encountered this issue when updating @wasmer/wasi to be compatible with wasi_snapshot_preview1).

Having this file:

use std::env;

fn main() {
    let existing = env::var_os("WASM_EXISTING");
    println!("should be set (WASM_EXISTING): {:?}", existing);
    let unexisting = env::var_os("WASM_UNEXISTING");
    println!("shouldn't be set (WASM_UNEXISTING): {:?}", unexisting);

    env::set_var("WASM_EXISTING", "NEW_VALUE");
    let existing = env::var_os("WASM_EXISTING");
    println!("Set existing var (WASM_EXISTING): {:?}", existing);
    env::set_var("WASM_UNEXISTING", "NEW_VALUE");
    let unexisting = env::var_os("WASM_UNEXISTING");
    println!("Set unexisting var (WASM_UNEXISTING): {:?}", unexisting);

    println!("All vars in env:");
    for (key, value) in env::vars() {
        println!("{}: {}", key, value);
    }
}

Compiling it with rustc env.rs --target wasm32-wasi -O

If running it without env vars:

wasmer packages/wasi/test/rs/wasi_snapshot_preview1/env.wasm

This will show the correct output:

should be set (WASM_EXISTING): None
shouldn't be set (WASM_UNEXISTING): None
Set existing var (WASM_EXISTING): Some("NEW_VALUE")
Set unexisting var (WASM_UNEXISTING): Some("NEW_VALUE")
All vars in env:
WASM_EXISTING: NEW_VALUE
WASM_UNEXISTING: NEW_VALUE

However, the following will fail (without printing anything) with error code 71:

wasmer packages/wasi/test/rs/wasi_snapshot_preview1/env.wasm --env "WASM_EXISTING=VALUE"

Note: this issue is independent of the runtime, it also happens in any other runtimes

closed time in 3 months

syrusakbary

issue commentWebAssembly/wasi-libc

Environment variables are broken

@MarkMcCaskey, thanks for clearing this up!

syrusakbary

comment created time in 3 months

issue commentbytecodealliance/wasmtime

Set up bot like Servo's @highfive to @-mention people when files in a subdirectory are modified?

Relatedly, we can also set up a GitHub Action to auto-label pull requests based on changed files: https://github.com/actions/labeler/blob/master/README.md

fitzgen

comment created time in 3 months

issue commentbytecodealliance/wasmtime

WasmTime.Net: Access to Handle in Memory Class

CC @peterhuene

christophwille

comment created time in 3 months

issue commentbytecodealliance/wasmtime

Debugging in Cranelift

@yurydelendik is there anything left to do here, or does our debugging support fully cover what's requested here?

lachlansneff

comment created time in 3 months

issue commentbytecodealliance/wasmtime

Multi-value returns do not work in Windows ABI

CC @fitzgen

krk

comment created time in 3 months

push eventbytecodealliance/bytecodealliance.org

dependabot[bot]

commit sha c5706893c078ac47b17cebedb7098d905ba3cb1c

Bump nokogiri from 1.10.5 to 1.10.9 (#4) Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.10.5 to 1.10.9. - [Release notes](https://github.com/sparklemotion/nokogiri/releases) - [Changelog](https://github.com/sparklemotion/nokogiri/blob/v1.10.9/CHANGELOG.md) - [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.10.5...v1.10.9) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 3 months

PR merged bytecodealliance/bytecodealliance.org

Bump nokogiri from 1.10.5 to 1.10.9 dependencies

Bumps nokogiri from 1.10.5 to 1.10.9. <details> <summary>Release notes</summary>

Sourced from nokogiri's releases.

1.10.9 / 2020-03-01

Fixed

  • [MRI] Raise an exception when Nokogiri detects a specific libxml2 edge case involving blank Schema nodes wrapped by Ruby objects that would cause a segfault. Currently no fix is available upstream, so we're preventing a dangerous operation and informing users to code around it if possible. [#1985, #2001]
  • [JRuby] Change NodeSet#to_a to return a RubyArray instead of Object, for compilation under JRuby 9.2.9 and later. [#1968, #1969] (Thanks, @​headius!)

1.10.8 / 2020-02-10

Security

[MRI] Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in #1992. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.

1.10.7 / 2019-12-03

Bug

  • [MRI] Ensure the patch applied in v1.10.6 works with GNU patch. #1954

1.10.6 / 2019-12-03

Bug

  • [MRI] Fix FreeBSD installation of vendored libxml2. [#1941, #1953] (Thanks, @​nurse!)

</details> <details> <summary>Changelog</summary>

Sourced from nokogiri's changelog.

1.10.9 / 2020-03-01

Fixed

  • [MRI] Raise an exception when Nokogiri detects a specific libxml2 edge case involving blank Schema nodes wrapped by Ruby objects that would cause a segfault. Currently no fix is available upstream, so we're preventing a dangerous operation and informing users to code around it if possible. [#1985, #2001]
  • [JRuby] Change NodeSet#to_a to return a RubyArray instead of Object, for compilation under JRuby 9.2.9 and later. [#1968, #1969] (Thanks, @​headius!)

1.10.8 / 2020-02-10

Security

[MRI] Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in #1992. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.

1.10.7 / 2019-12-03

Bug

  • [MRI] Ensure the patch applied in v1.10.6 works with GNU patch. #1954

1.10.6 / 2019-12-03

Bug

  • [MRI] Fix FreeBSD installation of vendored libxml2. [#1941, #1953] (Thanks, @​nurse!) </details> <details> <summary>Commits</summary>
  • e2e191d version bump to v1.10.9
  • 50f8fde update CHANGELOG
  • 9b5deef Change return type to RubyArray
  • ae054f7 update CHANGELOG for #1985
  • 71bcaf0 Work around a bug in libxml2
  • 6ce10d1 version bump to v1.10.8
  • 2320f5b update CHANGELOG for v1.10.8
  • 4a77fdb remove patches from the hoe Manifest
  • 570b6cb update to use rake-compiler ~1.1.0
  • 2cdb68e backport libxml2 patch for CVE-2020-7595
  • Additional commits viewable in compare view </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 months

push eventbytecodealliance/bytecodealliance.org

Till Schneidereit

commit sha 49874f7c28708ddfc35ddf1c28db7cede11cd52c

Remove some unused css rules

view details

Till Schneidereit

commit sha e8f501419d65e958b4c9b0c856547e6efe24c1e6

Add major projects to main menu

view details

Till Schneidereit

commit sha e0e9c6605c868b2d2186d9712e97cbe375165df5

Tweaks to styling, and fixed Cranelift links

view details

push time in 3 months

delete branch bytecodealliance/bytecodealliance.org

delete branch : dependabot/bundler/nokogiri-1.10.8

delete time in 3 months

push eventbytecodealliance/bytecodealliance.org

dependabot[bot]

commit sha b45e51bbf5b084d01c79ac0c8f54f09469e7ebe9

Bump nokogiri from 1.10.5 to 1.10.8 (#3) Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.10.5 to 1.10.8. - [Release notes](https://github.com/sparklemotion/nokogiri/releases) - [Changelog](https://github.com/sparklemotion/nokogiri/blob/master/CHANGELOG.md) - [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.10.5...v1.10.8) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 3 months

PR merged bytecodealliance/bytecodealliance.org

Bump nokogiri from 1.10.5 to 1.10.8 dependencies

Bumps nokogiri from 1.10.5 to 1.10.8. <details> <summary>Release notes</summary>

Sourced from nokogiri's releases.

1.10.8 / 2020-02-10

Security

[MRI] Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in #1992. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.

1.10.7 / 2019-12-03

Bug

  • [MRI] Ensure the patch applied in v1.10.6 works with GNU patch. #1954

1.10.6 / 2019-12-03

Bug

  • [MRI] Fix FreeBSD installation of vendored libxml2. [#1941, #1953] (Thanks, @​nurse!)

</details> <details> <summary>Changelog</summary>

Sourced from nokogiri's changelog.

1.10.8 / 2020-02-10

Security

[MRI] Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in #1992. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.

1.10.7 / 2019-12-03

Fixed

  • [MRI] Ensure the patch applied in v1.10.6 works with GNU patch. [#1954]

1.10.6 / 2019-12-03

Fixed

  • [MRI] Fix FreeBSD installation of vendored libxml2. [#1941, #1953] (Thanks, @​nurse!) </details> <details> <summary>Commits</summary>
  • 6ce10d1 version bump to v1.10.8
  • 2320f5b update CHANGELOG for v1.10.8
  • 4a77fdb remove patches from the hoe Manifest
  • 570b6cb update to use rake-compiler ~1.1.0
  • 2cdb68e backport libxml2 patch for CVE-2020-7595
  • e6b3229 version bump to v1.10.7
  • 4f9d443 update CHANGELOG
  • 80e67ef Fix the patch from #1953 to work with both git and patch
  • 7cf1b85 Fix typo in generated metadata
  • d76180d add gem metadata
  • Additional commits viewable in compare view </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 months

push eventbytecodealliance/bytecodealliance.org

Till Schneidereit

commit sha 5d9fc15df3d12c3572f497dca7c4950731b0d6f1

Cleanup of navigation code and css

view details

Till Schneidereit

commit sha fec49e330f0a523250bb1ee5e39300edfe545c0a

Rework FAQs and remove now redundant Webflow script

view details

push time in 3 months

push eventCraneStation/wasi-libc

Dan Gohman

commit sha 0cc57ac7b4c0e48a9e4a99e52538c793f2516f31

Multi-license wasi-libc under Apache and MIT licenses. (#174) Multi-license wasi-libc under the Apache-2.0 WITH LLVM-exception, Apache-2.0, and MIT licenses.

view details

push time in 3 months

PR merged CraneStation/wasi-libc

Multi-license wasi-libc under Apache and MIT licenses.

Multi-license wasi-libc under the Apache-2.0 WITH LLVM-exception, Apache-2.0, and MIT licenses.

+478 -861

0 comment

12 changed files

sunfishcode

pr closed time in 3 months

create barnchtschneidereit/wasmtime

branch : fix-cl-repo

created branch time in 3 months

more