memory-control
team
| memory-control | team | |
|---|---|---|
| 5 | 3 | |
| 19 | 1,404 | |
| - | 0.0% | |
| 0.0 | 0.0 | |
| over 1 year ago | over 4 years ago | |
| WebAssembly | ||
| GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
memory-control
-
Extism Makes WebAssembly Easy
Indeed, webassembly is moving extremely slowly. I started a project years ago expecting https://github.com/WebAssembly/memory-control/blob/main/prop... and https://github.com/WebAssembly/memory64 to be fixed at some point. Neither are yet, and the project still suffers from it to this day.
I think wasm is still great without these fixes, but I have lost confidence in the idea that wasm will reach its full potential any time soon.
-
The Tug-of-War over Server-Side WebAssembly
Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/prop..., which provides memory protection.
-
How do Rust WebAssembly apps free unused memory?
But researching it a bit I found this issue, so it clearly seems to be a problem for a bunch of people out there. And apparently both V8 and Spidermonkey have already addressed this quite recently, see this issue.
-
WebAssembly and C++
FWIW there is a proposal in the works to add page-based protection, which will allow unmapping the 0 page, restoring the trap-on-null-deref behavior that is important for many languages with safety checks.
https://github.com/WebAssembly/memory-control
team
-
The Tug-of-War over Server-Side WebAssembly
Further down that GitHub issue, it mentions the problem has been fixed:
* https://github.com/rust-lang/rust/issues/71871#issuecomment-...
* https://github.com/rust-lang/rust/pull/79998
Weirdly though, there's another issue (opened prior) that's ongoing and seems to indicate things aren't fixed after all:
* https://github.com/rustwasm/team/issues/291
-
Rust mod team resignation
As for all the rust-wasm stuff, the dispute makes little sense. The "opposition" wants her to transfer publishing rights to a Github group actively being sunsetted and portraying it as a power struggle, yet this struggle is taking place in an issue Williams started in an effort to transfer ownership. Based on the last comments, it looks like publishing rights have been distributed to other members so the whole narrative is effectively moot.
-
rust / emscripten / wasm / opengl / sdl2 / porting..
I don't have direct WebAssembly experience (So far, my projects have either required stuff not compatible with WASI or been DOM-centric "must degrade gracefully with JavaScript disabled" stuff) but this thread looks like a good starting point for answering that question.
What are some alternatives?
multi-memory - Multiple per-module memories for Wasm
wasi-threads
asm-dom - A minimal WebAssembly virtual DOM to build C++ SPA (Single page applications)
TSC - The Node.js Technical Steering Committee
sycamore - A library for creating reactive web apps in Rust and WebAssembly
browser_wasi_shim - A WASI shim for in the browser
wajic - WebAssembly JavaScript Interface Creator
hangover - Hangover runs simple Win32 applications on arm64 Linux
interface-types
noah - Bash on Ubuntu on macOS
gc - Branch of the spec repo scoped to discussion of GC integration in WebAssembly
team - Rust teams structure