| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Speeds up startup time, reduces runtime heap size.
|
|
|
|
|
|
* Native ES modules
This is a major refactor of internal compiler.
Before: JS and TS both were sent through the typescript compiler where
their imports were parsed and handled. Both compiled to AMD JS and
finally sent to V8
Now: JS is sent directly into V8. TS is sent through the typescript
compiler, but tsc generates ES modules now instead of AMD. This
generated JS is then dumped into V8.
This should much faster for pure JS code. It may improve TS compilation
speed.
In the future this allows us to separate TS out of the runtime heap and
into its own dedicated snapshot. This will result in a smaller runtime
heap, and thus should be faster.
Some tests were unfortunately disabled to ease landing this patch:
1. compiler_tests.ts which I intend to bring back in later commits.
2. Some text_encoding_test.ts tests which made the file invalid utf8.
See PR for a discussion.
Also worth noting that this is necessary to support WASM
|
|
This reverts commit 3d03f5b0cb3c513e449f3aaa5d35c493b72f47b4.
|
|
|
|
- Improves speed and binary size significantly.
- Makes deno_last_exception() output a JSON structure.
- Isolate::execute and Isolate::event_loop now return
structured, mapped JSError objects on errors.
- Removes libdeno functions:
libdeno.setGlobalErrorHandler()
libdeno.setPromiseRejectHandler()
libdeno.setPromiseErrorExaminer()
In collaboration with Ryan Dahl.
|
|
|
|
|
|
|
|
|
|
Pro:
time ./out/debug/deno tests/error_001.ts 3.0s -> 0.4s
Con:
time ./tool/build.py snapshot 33s -> 1m52s
out/debug/gen/snapshot_deno.bin 39M -> 121M
|
|
- Running repl from js side.
- Add tests for repl behavior.
- Handle ctrl-C and ctrl-D.
|
|
|
|
|
|
Fixes #993
|
|
|
|
|
|
Fixes #935
|
|
|
|
This better disambiguates with the msg_generated.ts module, which in JS
we call "fbs", but would be better called "msg".
|
|
|
|
|
|
And send() -> sendSync()
|
|
|
|
Refactors handlers.rs
The idea is that all Deno "ops" (aka bindings) should map onto
a Rust Future. By setting the "sync" flag in the Base message
users can determine if the future is executed immediately or put
on the event loop.
In the case of async futures, a promise is automatically created.
Errors are automatically forwarded and raised.
TODO:
- The file system ops in src/handler.rs are not using the thread pool
yet. This will be done in the future using tokio_threadpool::blocking.
That is, if you try to call them asynchronously, you will get a promise
and it will act asynchronous, but currently it will be blocking.
- Handlers in src/handler.rs returned boxed futures. This was to make
it easy while developing. We should try to remove this allocation.
|
|
- Adding a ModuleId type alias to specify original url or local file of
dependency
- Modifying ModuleMetaData class to contain ModuleId
- Adding a --deps flag
|
|
Also removes assignCmdId as it's currently unused.
|
|
|
|
|
|
|
|
Adds compiler_test.ts
|
|
With help from Thomas Ghysels <info@thomasg.be>
|
|
In particular this allow -D for logging debug output.
|
|
Fixes #419, #414.
|
|
|
|
|
|
|
|
|
|
This change increases size:
out/debug/obj/libdeno/from_snapshot.o 19M -> 34M
out/release/deno 32M -> 47M
|
|
|
|
|
|
- Add build scripts for Rust flatbuffers.
- Rewrites some reply.cc methods in Rust.
- Changes some struct elements to table in msg.fbs (rust flatbuffers
lacks support currently)
- Renames handlers_test to test_rs.
- This reorg is needed to make progress on the code cache handler.
|
|
|
|
|
|
Implements code_fetch handler in Rust.
Add ability to embed string assets (for typescript declaration files)
Remove deno_cc and deno_cc_nosnapshot targets.
|
|
* send()/recv() now operate on TypedArrays rather than ArrayBuffers.
* Remove a copy (through ArrayBuffer.slice()) from the send path.
* Remove a copy (through v8::ArrayBuffer::New()) from the return path.
* After moving a buffer from JS to native, the ArrayBuffer object and
it's views are made inaccessible ('neutered').
* `struct deno_buf` now holds two [ptr, length] tuples, one for the actual
memory allocation, and one for the logical data contained therein.
This is necessary because flatbuffers fills it's buffer bottom-up, so
the serialized blob doesn't start at beginning of the buffer, but
somewhere in the middle.
|
|
This allows for correlating response messages to the command message that
caused them.
|
