unionfs
graaljs
unionfs | graaljs | |
---|---|---|
1 | 17 | |
200 | 1,623 | |
- | 1.0% | |
6.8 | 9.9 | |
8 days ago | 7 days ago | |
TypeScript | C++ | |
The Unlicense | Universal Permissive License v1.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.
unionfs
-
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
graaljs
-
An ES5-compliant JavaScript interpreter, written in Java
I would guess that depends on the licensing context in which it will be running, since Rhino is MPLv2 <https://github.com/mozilla/rhino/blob/Rhino1_7_14_Release/LI...> and OP's repo is MIT whereas Graal is UPLv1 <https://github.com/oracle/graaljs/blob/graal-23.1.2/LICENSE>. GitHub's license gizmo claims it is OSI/FSF approved, but Oracle gonna Oracle and they for sure have more lawyers than you do
-
A list of JavaScript engines, runtimes, interpreters
graaljs
- GraalJS: Node.js compliant JavaScript implementation built on GraalVM by Oracle
-
Latest Deno release supports NPM packages
Here: https://github.com/oracle/graaljs
-
No one cares about Bun's speed. Your CI does though
It's by Oracle: https://github.com/oracle/graaljs; seems to be built to interop w/ GraalVM based languages/services
-
R Shiny App Equivalent
If you need you can run JavaScript from within Java using Graal.js or Nashorn. To evaluate dynamic user input (Strings) you could also use a ScriptEngine (e.g. JavaScript) or dynamically compile inputs to Java using the JShell API.
-
CoWasm: An alternative to Emscripten, based on Zig (demo: Python in the browser)
That's just incredibly cool, my congratulations!
Foremost, my apologies if this is a nonsensical question. I haven't been soaking in the WASM ecosystem enough to know how much WASM is "just" JS versus ... something else.
Caveat aside, I saw one of the commits mention jython, which notoriously has ancient (and probably incredibly incomplete) python 2.x support; do you know if python-wasm would run on top of GraalJS (https://github.com/oracle/graaljs#nodejs-support)?
Separately, do you want issues related to zython.org in the cowasm issue tracker? It returns 405 (method not allowed) over and over on POST https://zython.org/python-wasm-sw/read-signal for me
-
Dear Oracle, Please Release the JavaScript Trademark
Must be a fork because I found my own commits haha
https://github.com/oracle/graaljs/commits?author=styfle
-
Microsoft proposes type syntax for JavaScript
Discussion reference https://github.com/oracle/graaljs/issues/239
What are some alternatives?
memfs - JavaScript file system utilities
TypeScript - TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
cowasm - CoWasm: Collaborative WebAssembly for Servers and Browsers. Built using Zig. Supports Python with extension modules, including numpy.
deno - A modern runtime for JavaScript and TypeScript.
wajic - WebAssembly JavaScript Interface Creator
deno-exec
zx - A tool for writing better scripts
truffleruby - A high performance implementation of the Ruby programming language, built on GraalVM.
graalpython - A Python 3 implementation built on GraalVM
graalvm-ce-builds - GraalVM CE binaires built by the GraalVM community
doom.d - My somewhat modular emacs config.
enso - Hybrid visual and textual functional programming.