jstime / jstime Goto Github PK
View Code? Open in Web Editor NEWanother runtime
License: Apache License 2.0
another runtime
License: Apache License 2.0
If we do end up implementing support fo WASI (#5) we may want to have a stable ABI for interfacing with V8. I'm not 100% if NAPI would be the best fit but if we can have WASI + NAPI native modules might be portable between jstime + node, which would be pretty awesome.
Need to refactor action
It seems to me that given an adequate lower-level interface, there's not much need for things like URL
, fetch
, etc. to be provided as builtins. I know this topic has been played out quite a bit in Node.js, but since this is a greenfield approach/project, I think this warrants of its own discussion.
I'm (at the moment) non-blockingly opposed (i.e. a -0 I guess) for adding WHATWG/W3C-specific builtins to the runtime as a base layer. I think it absolutely should be trivial to add such functionality and create environments that look enough like browsers to make browser code work.
Currently there is no history in the REPL. This is supported by the library we are using rustyline, how to implement it can be found in the docs https://docs.rs/rustyline/6.2.0/rustyline/
The current parsing is laughable naive.
We should be able to parse various incoming arguments including feature flags
I can't wrap my head around why, but when testing the MacOS built binaries on my local machine it take many seconds to start. This is not the case with a locally built binary using the exact same commands. I'm confused
V8 instantiates console but all the functions are noops. I believe that an inspector needs to be set up in order to functionally log.
We don't have any tests, we should have tests.
Currently there is no module loader. It would be nice to support ESM. Basic support for file system resources will likely be the easiest MVP
This one is going to be a doozy since it implies network access, streams, event pointers, promise cancellation.
It is a lot of work, but let's make fetch happen!
Right now we only print to stderr, but we don't modify the exit code when there are errors
There is a proposal -> https://github.com/webassembly/esm-integration
Implementation in Node -> nodejs/node#27659
If we want to do anything beyond running code in the JS VM we are going to need a system interface and a way to bind native code to JS.
I like the idea of using WASI as the system interface and supporting WASM modules in the loader.
Probably need one of those ๐
There is a proposal -> https://github.com/tc39/proposal-json-modules
It build on top of import assertions -> https://github.com/tc39/proposal-import-assertions
V8 does not yet support import assertions though AFAIK... but I also think that an embedder can choose if they need to require the import assertion or not, need to review the spec.
Right now I'm the only one with commit access. I definitely don't want this project to be a BDFL. I do have a high level ideology for jstime, primarily that it should do as little as possible and use standard interfaces as much as possible. With that said I have a distinct feeling that the project will evolve and adapt based on those who are involved.
With this in mind, I'm going to start drafting out a governance model for how we handle both decision making and conflict resolution. I would be particularly interested in designing a governance model based on rough consensus.
Some initial folks I would like to nominate to become collaborators include:
Currently if there is an error in user code passed to the repl things blow up. Would be nice if it didn't.
Tab completion in the REPL would be quite nice
Right now we only have 2 built ins, console and queue_microtask.
We manually add them as "builtins" in jstime_core and include them when they are snapshotted. This works for now, but is arguably not the most extensible or modular approach to the problem.
What if jstime_core had 0 builtins. Instead it had an API for defining built-ins, those built ins extending a base built-in class that jstime would know how to instantiate. If we had an extendable Builtin class (struct?) individuals could make creates that exposed their extension as a module which could just be passed to jstime_core at instantiation time
Super bad idea of what an API for defining builtins could looks like
mod jstime_console as console;
use jstime_core as jstime;
fn main() {
jstime::init(None);
let mut options = jstime::Options::default();
options.builtins.push(console);
let mut jstime = jstime::JSTime::new(options);
jstime.import("./path/to/some/file.js");
}
Super bad idea of what a Builtin class could look like
struct Bultin {
jsSource: char *inventory[], //(list of js files to run)
nativeBindings: char *inventory[], //(list of functions to bind)
snapshot: bool, // (whether to include in snapshot)
}
Then the implementation could create the functions that are to be bound and referred to in nativeBindings?
This is due to how it uses environment variables to store information about the version that can eventually be used when naming assets.
8ba3619 was an attempt to fix this, it didn't work. Needs to be revisted
Related to #44
While not entirely necessary based on the current jstime feature-set, having the URL api seems like a reasonable platform builtin, PTAL at https://github.com/jstime/jstime/tree/main/core/src/builtins for examples of our existing built ins console and queue microtask
Currently there are no stack traces being printed... it would be nice to have them
As documented in https://html.spec.whatwg.org/multipage/timers-and-user-prompts.htm
@bdougie brought this in #27 (comment)
This would include:
setTimeout()
setInterval()
clearTimeout()
clearInterval()
In deno this is how it is implemented
https://github.com/denoland/deno/blob/master/cli/global_timer.rs
https://github.com/denoland/deno/blob/master/cli/rt/11_timers.js
Definitely interesting that the JavaScript runtime extensions are implemented in deno_cli not deno_core
we currently don't implement import.meta.url
which would be nice to have, and potentially even useful at some point if we offer file system APIs ๐.
https://docs.rs/rusty_v8/0.9.1/rusty_v8/type.HostInitializeImportMetaObjectCallback.html and https://docs.rs/rusty_v8/0.9.1/rusty_v8/struct.Isolate.html#method.set_host_initialize_import_meta_object_callback are documenting the required API calls to V8
Here is it being set in deno https://github.com/denoland/deno/blob/master/core/es_isolate.rs#L84-L86
Currently the documentation for jstime is primarily in the readme. As the API expands it will be good to document using rustdoc so we can have something a bit nicer for folks to refer
error: failed to build archive: bad archive: truncated or malformed archive (offset to next archive member past the end of the archive after member counters.o)
error: aborting due to previous error
error: could not compile `rusty_v8`.
To learn more, run the command again with --verbose.
This is due to an issue in rusty_v8. Attempted to fix in c911f02 but it didn't stick
Refs: denoland/rusty_v8#543
Currently we do not save repl history between sessions. Node.js stores history in $HOME/.node_repl_history
.
rustyline does support saving + loading session data and it is documented in the readme
#48 has been open for 5 days, and we have not been able to land it due to lack of review.
How do folks feel about introducing governance that would allow unreviewed PRs without objections to land after a certain amount of time. E.g.
If a pull request has been open for 5 days it can land without review as long as there are no objections.
If another collaborator would like to revert the PR after landing they can do so without review within 48 hours.
The above text give flexibility to both keep things moving and a window for reverting the change without review if someone comes in late. In general I'm a big +1 on making reverts easy and non-controversial.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.