cowasm
memfs
cowasm | memfs | |
---|---|---|
8 | 3 | |
462 | 1,617 | |
1.5% | - | |
3.9 | 9.4 | |
4 months ago | 1 day ago | |
C | TypeScript | |
BSD 3-clause "New" or "Revised" License | Apache License 2.0 |
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.
cowasm
-
bsdutils: Alternative to GNU coreutils using software from FreeBSD
For fun, I ported much of BSDutils to WebAssembly. Code [1] and live demo [2]. It was much, much easier porting BSDutils than GNU coreutils, since the source code is often much smaller, and hence easier to read and understand with simpler dependencies.
[1] https://github.com/sagemathinc/cowasm/tree/main/core/coreuti...
- Wasi-JS: a JavaScript library for interacting with WASI Modules
- active now: Commits · sagemathinc/cowasm
-
SQLite 3.40.0 with WASM Support
For what it is worth, I also care about building this with zig. https://github.com/sagemathinc/cowasm/blob/main/packages/sql...
-
Adding Python support using Pyodide to our low-code framework which supported only JavaScript.
If it fits your needs and is working, then fine. Please remain aware of a different approach to what pyodide is doing based on perceived weaknesses in pyodide.
-
CoWasm: An alternative to Emscripten, based on Zig (demo: Python in the browser)
CoWasm supports WASI right now via this library https://www.npmjs.com/package/wasi-js, which I actually develop as part of CoWasm . One unusually thing I did, which goes beyond what emscripten does, is I implemented a quite a bit of posix functionality, often by writing extension code to nodejs and calling it from Javascript, because there's a lot of POSIX that Node.js doesn't expose. This only works on Mac and Linux and is also available standalone in this library https://www.npmjs.com/package/posix-node, which is implemented in Zig. You can get a sense of the scope of POSIX functionality that goes beyond what WASI defines here: https://github.com/sagemathinc/cowasm/tree/main/packages/ker...
One motivation for doing this is to try to get the full Python test suite to pass, including all the functionality that involves subprocesses, posix calls, etc. I've only got to about 85% at this point. It can be a ton of tedious work, but at least Zig helps impose some discipline (e.g, it doesn't let you ignore handling errors until later), and makes it easy to test compilation for all supported targets on every change (due to excellent cross compilation support).
memfs
-
CoWasm: An alternative to Emscripten, based on Zig (demo: Python in the browser)
I am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, which is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week).
CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...).
> how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm?
That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40
-
Encryption in PDF Specification and my attempt to do it in pdf-lib
Looks like this whole thing was motivated by the fact that, in order to get the encrypted PDF in a Buffer like they wanted, they had to save to disk and load it back. They could have instead used an in-memory filesystem such as https://github.com/streamich/memfs and just made the existing PDF library that was almost right use that.
-
I used emscripten to port a command line program to JS/web assembly, now what?
How do I populate the input files? The filesystem API in emscripten talks about MEMFS, is that the same as this? https://github.com/streamich/memfs
What are some alternatives?
coreutils - Mirror of https://gitlab.redox-os.org/redox-os/coreutils
react-native-file-access - Filesystem access for React Native
coreutils - Cross-platform Rust rewrite of the GNU coreutils
fs-jetpack - Better file system API for Node.js
bat - A cat(1) clone with wings.
hazelcast-nodejs-client - Hazelcast Node.js Client
unionfs - Use multiple fs modules at once
spacedrive - Spacedrive is an open source cross-platform file explorer, powered by a virtual distributed filesystem written in Rust.
bsdutils - Alternative to GNU coreutils using software from FreeBSD
react-cool-virtual - 😎 ♻️ A tiny React hook for rendering large datasets like a breeze.
wasi-sqlite - sqlite3 CLI for a-Shell on iOS