* Add documentation for building programs using AssemblyScript.
* Add the assemblyscript hello world as an example and display it inline.
* Move the AssemblyScript hello world into the docs directory.
That way Cargo doesn't try to run it like a Rust example.
This patch adds initial support for ittapi which is an open
source profiling api for instrumentation and tracing and profiling
of jitted code. Result files can be read by VTune for analysis
Build:
cargo build --features=vtune
Profile: // Using amplxe-cl from VTune
amplxe-cl -v -collect hostpost target/debug/wasmtime --vtune test.wasm
* Add examples of linking and WASI
This commit adds two example programs, one for linking two modules
together and one for instantiating WASI. The linkage example
additionally uses WASI to get some meaningful output at this time.
cc #1272
* Add examples to the book as well
* More links!
* Ignore examples from rustdoc testsing
* More example updates
* More ignored
* Enable jitdump profiling support by default
This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:
* Pass in a list of finished functions instead of just a range to
ensure that we're emitting jit dump data for a specific module rather
than a whole `CodeMemory` which may have other modules.
* Define `ProfilingStrategy` in the `wasmtime` crate to have everything
locally-defined
* Add support to the C API to enable profiling
* Documentation added for profiling with jitdump to the book
* Split out supported/unsupported files in `jitdump.rs` to avoid having
lots of `#[cfg]`.
* Make dependencies optional that are only used for `jitdump`.
* Move initialization up-front to `JitDumpAgent::new()` instead of
deferring it to the first module.
* Pass around `Arc<dyn ProfilingAgent>` instead of
`Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>`
The `jitdump` Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!
* Spice up the project README, fill out more docs
This is an attempt to spruce up wasmtime's README.md file as well as
fill out more of the missing documentation in the `docs/` folder.
There's still a long way to go but I hoped here to mostly move around
existing information and add new information. As always happy to have
feedback!
* Tweak CLI wording
* Remove no-longer relevant clause
* Update sandboxing docs
* Handle comments
The `wasmtime` release procees seems like it's been a bit ad-hoc up to
this point, so I figured it'd be good to try to document what we do
today and codify what should be done as well as a form of release
checklist.
I've noticed that we have a number of releases (like v0.11.0) but the
`Cargo.toml` files in the repository don't reflect the current version
of `wasmtime`. Additionally I've noticed that the [most recent release]
ended up having failed tests because `Cargo.toml` was modified but
`Cargo.lock` wasn't updated. I'm hoping that by having a checklist we
can avoid these sorts of accidental issues in the future!
[release]: https://github.com/bytecodealliance/wasmtime/runs/434690272
This commit adds the skeleton of a new set of documentation for
`wasmtime` in the existing `docs` directory. This documentation is
organized and compiled with [mdbook] which the Rust project uses for
most of its own documentation as well. At a previous meeting we
brainstormed a rough skeleton of what the documentation in this book
would look like, and I've transcribed that here for an example of how
this is rendered and how it can be laid out. No actual documentation is
written yet.
This commit also additionally adds necessary support to auto-publish
both this book documentation and API documentation every time a commit
is pushed to the `master` branch. All HTML will be automatically pushed
to the `gh-pages` branch so long as the CI passes, and this should get
deployed to https://cranestation.github.io/wasmtime.
I've done a few dry-runs and I think this'll all work, but we'll likely
tweak a few things here and there after running this through CI to make
sure everything looks just as we'd like. My hope though is that after
this lands we can start actually filling out all the documentation and
being able to review it as well.
[mdbook]: https://crates.io/crates/mdbook
