profile
viewpoint

denoland/deno 68221

A secure JavaScript and TypeScript runtime

Kitura/BlueSocket 1174

Socket framework for Swift using the Swift Package Manager. Works on iOS, macOS, and Linux.

Kitura/HeliumLogger 164

A lightweight logging framework for Swift

indutny/caine 141

Friendly butler

IBM-Swift/SwiftyJSON 112

The better way to deal with JSON data in Swift

Kitura/Configuration 63

Hierarchical configuration manager for Swift applications

Kitura/Kitura-CouchDB 45

CouchDB adapter for Kitura

Kitura/Kitura-Credentials 41

A pluggable framework for validating user credentials in a Swift server using Kitura

creationix/luvmonkey 39

Spidermonkey shell with libuv bindings built-in.

bnoordhuis/phode 32

we put the async in php

issue commentdenoland/rusty_v8

Shrink library size

This recipe below on linux. I would kindly ask any mac users to make it work on OS X in order to find out whether it fixes #465.

# Make sure to first successfully build `rusty_v8`, preferrably *NOT* from
# source. It should be possible to do this for the debug build as well.
cargo test --release
cd target/release/gn_out/obj

# Back up the original librusty_v8.a
[ ! -f librusty_v8_orig.a ] && mv librusty_v8.a librusty_v8_orig.a

# Do black magic
ld -r -whole-archive -L. -l rusty_v8_orig -o temp1.o
objcopy temp1.o temp2.o --wildcard --localize-hidden --localize-symbol '*'
objcopy temp2.o rusty_v8.o --wildcard --globalize-symbol 'v8__*' --globalize-symbol 'v8_inspector__*' --globalize-symbol 'std__*'
rm -f librusty_v8.a
ar crs librusty_v8.a rusty_v8.o

# Verify: the expected line count is somewhere in the 400-500 range.
nm --extern-only --defined-only librusty_v8.a | wc -l
# ```
# 439
# ```

# Verify: the `nm` output should look similar.
nm --extern-only --defined-only librusty_v8.a
# ```
# rusty_v8.o:
# 0000000000000000 T std__shared_ptr__v8__ArrayBuffer__Allocator__CONVERT__std__unique_ptr
# 0000000000000000 T std__shared_ptr__v8__ArrayBuffer__Allocator__COPY
# 0000000000000000 T std__shared_ptr__v8__ArrayBuffer__Allocator__get
# 0000000000000000 T std__shared_ptr__v8__ArrayBuffer__Allocator__reset
# 0000000000000000 T std__shared_ptr__v8__ArrayBuffer__Allocator__use_count
# «...snip...»
# 0000000000000000 T v8_inspector__V8Inspector__Channel__sendResponse
# 0000000000000000 T v8_inspector__V8Inspector__DELETE
# 0000000000000000 T v8_inspector__V8Inspector__connect
# 0000000000000000 T v8_inspector__V8Inspector__contextCreated
# 0000000000000000 T v8_inspector__V8Inspector__create
# ```

# It should be possible to build rusty_v8 with the new librusty_v8.a.
cd ../../../..
touch build.rs
unset V8_FROM_SOURCE
cargo test --release
bnoordhuis

comment created time in 9 minutes

issue commentdenoland/deno

Error when using Deno.mkdir on Windows with absolute path

I can reproduce this issue:

PS D:\deno> deno --version
deno 1.4.6
v8 8.7.220.3
typescript 4.0.3
PS D:\deno> cat .\test.js
const dirname = new URL('../../data', import.meta.url);
console.log(dirname.toString());
await Deno.mkdir(dirname, {recursive: true});
PS D:\deno> deno run -A .\test.js
file:///D:/data
error: Uncaught Error: The filename, directory name, or volume label syntax is incorrect. (os error 123)
    at processResponse (core.js:226:13)
    at Object.jsonOpAsync (core.js:244:12)
    at async Object.mkdir (deno:cli/rt/30_fs.js:100:5)
    at async file:///D:/deno/test.js:3:1
PS D:\deno>

The problem appears to be that deno.exe is trying to create the directory D:\deno\file:\D:\data. So deno is not treating the URL as an (absolute) URL, but as a relative file path.

coyotte508

comment created time in 2 hours

issue commentdenoland/rusty_v8

Shrink library size

https://gist.github.com/piscisaureus/15de3964a3106711baa8e57aeccd0446

bnoordhuis

comment created time in 9 hours

issue commentdenoland/rusty_v8

Shrink library size

command:

ld -r -O3 --exclude-libs ALL -nostdlib -no-whole-archive --as-needed --discard-locals --gc-sections --entry v8__Function__New --Bwarn-constructors -L. -l rusty_v8 -o rusty_v8_minimal.o

bnoordhuis

comment created time in 11 hours

issue commentdenoland/rusty_v8

Shrink library size

@bnoordhuis Unfortunately that doesn't quite do the trick tho. I arrived at pretty much the same after some toying with ld, but with that command there's still a boatload of libc++ functions in the resulting object file.

(They may be tagged 'weak w/ default', but still visible, so it won't solve https://github.com/denoland/rusty_v8/issues/465)

bnoordhuis

comment created time in 11 hours

issue commentdenoland/rusty_v8

Segfaults if "use rusty_v8;" in wgpu application (OSX)

Ideally librusty_v8.a would only include object code for the functions defined in src/bindings.cc (or at least the other functions should be hidden / non-exported). However I have no clue how to achieve that.

@bnoordhuis Do you know?

FredrikNoren

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

push eventpiscisaureus/ical

Bert Belder

commit sha fea6e4f7942ab3bb9c25a673abf1c48bbd35a74a

Update

view details

push time in 5 days

push eventpiscisaureus/ical

Bert Belder

commit sha d6e6cd4d9fe96b889c6e4053d20a4e1bdb3ee476

Update

view details

push time in 5 days

push eventpiscisaureus/ical

Bert Belder

commit sha 40c42870a5a007340920629051d63e20edd5a008

First blood

view details

push time in 6 days

push eventpiscisaureus/ical

Bert Belder

commit sha 2bf014f904e8762b31a326a4f49b51f17abe4b2c

First blood

view details

push time in 6 days

create barnchpiscisaureus/ical

branch : master

created branch time in 6 days

created repositorypiscisaureus/ical

created time in 6 days

issue openedswc-project/swc

swc incorrectly discards export statements and (most) comments

piscisaureus@guru:~/d/swc_bug$ swc --version
@swc/cli: 0.1.27
@swc/core: 1.2.36
piscisaureus@guru:~/d/swc_bug$ cat .swrc
{
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "exportNamespaceFrom": true,
      "topLevelAwait": true
    },
    "target": "es2020"
  }
}
piscisaureus@guru:~/d/swc_bug$ cat in.js

import something from "../module_with_default_export.js"; /* This!? */

import { something_else } from "http://bonzo.com/mod"; // There?

/* Hello! */ export * from "./stuff.js"; /* Maybe like this? */ let _var; // Or so?

piscisaureus@guru:~/d/swc_bug$ swc in.js -o out.js
piscisaureus@guru:~/d/swc_bug$ cat out.js
import something from "../module_with_default_export.js";
import { something_else } from "http://bonzo.com/mod";
/* Hello! */ export * from "./stuff.js";
var _var; // Or so?
  • Most comments are gone.
  • The export statement from the last line is gone.
  • Most newlines are also gone. I comparatively miss them the least, but I did not ask swc to minify my source...

https://gist.github.com/fe73e5b27d35acbcb0fb53c9927fb849

created time in 6 days

Pull request review commentdenoland/deno

fix: top-level-await module execution

 impl JsRuntime {   /// `AnyError` can be downcast to a type that exposes additional information   /// about the V8 exception. By default this type is `JsError`, however it may   /// be a different type if `RuntimeOptions::js_error_create_fn` has been set.-  pub fn mod_evaluate(&mut self, id: ModuleId) -> Result<(), AnyError> {+  pub fn dyn_mod_evaluate(+    &mut self,+    load_id: ModuleLoadId,+    id: ModuleId,+  ) -> Result<(), AnyError> {+    self.shared_init();++    let state_rc = Self::state(self.v8_isolate());+    let context = self.global_context();+    let context1 = self.global_context();++    let module_handle = state_rc+      .borrow()+      .modules+      .get_info(id)+      .expect("ModuleInfo not found")+      .handle+      .clone();++    let status = {+      let scope =+        &mut v8::HandleScope::with_context(self.v8_isolate(), context);+      let module = module_handle.get(scope);+      module.get_status()+    };++    if status == v8::ModuleStatus::Instantiated {+      // IMPORTANT: Top-level-await is enabled, which means that return value+      // of module evaluation is a promise.+      //+      // Because that promise is created internally by V8, when error occurs during+      // module evaluation the promise is rejected, and since the promise has no rejection+      // handler it will result in call to `bindings::promise_reject_callback` adding+      // the promise to pending promise rejection table - meaning JsRuntime will return+      // error on next poll().+      //+      // This situation is not desirable as we want to manually return error at the+      // end of this function to handle it further. It means we need to manually+      // remove this promise from pending promise rejection table.+      //+      // For more details see:+      // https://github.com/denoland/deno/issues/4908+      // https://v8.dev/features/top-level-await#module-execution-order+      let scope =+        &mut v8::HandleScope::with_context(self.v8_isolate(), context1);+      let module = v8::Local::new(scope, &module_handle);+      let maybe_value = module.evaluate(scope);++      // Update status after evaluating.+      let status = module.get_status();++      if let Some(value) = maybe_value {+        assert!(+          status == v8::ModuleStatus::Evaluated+            || status == v8::ModuleStatus::Errored+        );+        let promise = v8::Local::<v8::Promise>::try_from(value)+          .expect("Expected to get promise as module evaluation result");+        let promise_id = promise.get_identity_hash();

We do it with modules too - and that should also change.

I'd assign the promise a number and stick it in a HashMap<u64, v8::Globalv8::Promise>

bartlomieju

comment created time in 6 days

PullRequestReviewEvent

issue commentdenoland/deno

Issues building for void-linux

Gn is typically downloaded by the cargo_gn crate somewhere into the build directory. You can bring your own, but then you need to set the GN environment variable to point at it. We download it from here btw - https://github.com/denoland/ninja_gn_binaries/tags

shizonic

comment created time in 6 days

issue commentdenoland/deno

Issues building for void-linux

gn should also be automatically installed though.

I wonder if you’re on a 32 bit system. We don’t support 32 bit builds.

shizonic

comment created time in 6 days

issue commentdenoland/deno

discussion: --location=<URL> option

Reading material: https://github.com/whatwg/html/issues/1888

nayeemrmn

comment created time in 6 days

issue commentdenoland/deno

deno run fails when local app data location path length exceeds 260 characters on Windows

I suspect the restriction you’re running into is that the current working directory can’t use UNC paths.

This is why e.g. node can work long paths just fine, but it can’t chdir() into them or run executables with long paths.

Note that the “long paths feature“ that you’re talking about is something else - it goes a step further and allows “regular” paths to be long.

I wasn’t aware that enabling long paths allows chdir()ing into a directory of over 260 characters long. But I think it still can’t be an “\?\” path.

dsherret

comment created time in 6 days

issue commentdenoland/deno

third_party submodule isn't included in release tarball

Note that rusty_v8 will actually download clang automatically so it should "just work". But we don't test on void-linux so I'm sure there will be some surprises.

shizonic

comment created time in 6 days

create barnchpiscisaureus/loader

branch : wip

created branch time in 6 days

push eventpiscisaureus/loader

Bert Belder

commit sha 79631116b69fa81ca07939265bed75725831b465

import_scanner: use String instead of [u8]

view details

Bert Belder

commit sha 5690734c1dff47ca03eadb85d38e1bed1b750881

Add "build script" for building wasm and generating js wrapper

view details

Bert Belder

commit sha 901f7eff052a61d238b108fe4d63d050cff9e451

Add wasm-pack output to the repo

view details

Bert Belder

commit sha fcb97081ed7d0569fdcb0d86dab28f0ef3e16fe3

Minor things

view details

push time in 7 days

Pull request review commentdenoland/rusty_v8

Add Isolate::set_promise_hook()

 fn promise_reject_callback_no_value() {   } } +#[test]+fn promise_hook() {+  extern "C" fn hook(+    type_: v8::PromiseHookType,+    promise: v8::Local<v8::Promise>,+    _parent: v8::Local<v8::Value>,+  ) {+    let scope = &mut unsafe { v8::CallbackScope::new(promise) };+    let scope = &mut v8::HandleScope::new(scope);+    let context = promise.creation_context(scope);

Actually nevermind - this is a test... 🤦

bnoordhuis

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentdenoland/rusty_v8

Add Isolate::set_promise_hook()

 fn promise_reject_callback_no_value() {   } } +#[test]+fn promise_hook() {+  extern "C" fn hook(+    type_: v8::PromiseHookType,+    promise: v8::Local<v8::Promise>,+    _parent: v8::Local<v8::Value>,+  ) {+    let scope = &mut unsafe { v8::CallbackScope::new(promise) };+    let scope = &mut v8::HandleScope::new(scope);+    let context = promise.creation_context(scope);

Since you are going to call a function that is bound to context, I think you should also enter said context. Otherwise the function now suddenly "sees" a different global object which can cause weird behavior. Vice versa it may not be undesirable to leak the innards of the current context to the creation context. So I'd suggest to use a ContextScope here.

bnoordhuis

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentdenoland/rusty_v8

Add Isolate::set_promise_hook()

 fn promise_reject_callback_no_value() {   } } +#[test]+fn promise_hook() {+  extern "C" fn hook(+    type_: v8::PromiseHookType,+    promise: v8::Local<v8::Promise>,+    _parent: v8::Local<v8::Value>,+  ) {+    let scope = &mut unsafe { v8::CallbackScope::new(promise) };+    let scope = &mut v8::HandleScope::new(scope);

This is unnecessary. V8 creates a HandleScope for us already. Passing the CallbackScope created 1 line above will work anywhere a HandleScope is needed.

bnoordhuis

comment created time in 7 days

PullRequestReviewEvent

pull request commentdenoland/rusty_v8

Add Isolate::set_promise_hook()

wait

bnoordhuis

comment created time in 7 days

issue openeddenoland/deno

Awaiting never-resolved promise makes Deno hang & hot spin.

deno run this.

// x.js
await new Promise(() => {});

It spins because there is nothing happening any more, and tokio can't block the event loop for us (it expects no events to happen).

Deno should either:

  • exit
  • throw an exception similar to UncaughtException. Maybe AwaitNeverException or something?

created time in 7 days

push eventpiscisaureus/loader

Bert Belder

commit sha ad48b765b60bfdd1e4d116a12df6a18fca087c19

Create Rust crate for extracting import specifiers from source code

view details

push time in 8 days

pull request commentdenoland/deno

Fix CI two times

I would say if we run into more bugs or have to introduce more complexity, it would be probably better to simply remove the whole thing.

It's a lot of stuff for a few minutes gain.

Maybe this experience will give us some hints on why our builds are so slow (and caching not effective) and it can be improved.

If not I agree then let's just turn it off.

BTW from-scratch release build & run tests in 10 minutes! I need an XL at home. It usually takes at least 30 minutes for me...

piscisaureus

comment created time in 10 days

delete branch denoland/deno

delete branch : fix-ci

delete time in 10 days

PR merged denoland/deno

Reviewers
Fix CI two times

<!-- Before submitting a PR, please read https://github.com/denoland/deno/blob/master/docs/contributing.md

  1. Give the PR a descriptive title.

Examples of good title: - fix(std/http): Fix race condition in server - docs(console): Update docstrings - feat(doc): Handle nested reexports

Examples of bad title: - fix #7123 - update docs - fix bugs

  1. Ensure there is a related issue and it is referenced in the PR text.
  2. Ensure there are tests that cover the changes.
  3. Ensure cargo test passes.
  4. Ensure ./tools/format.py passes without changing files.
  5. Ensure ./tools/lint.py passes. -->
+30 -0

0 comment

1 changed file

piscisaureus

pr closed time in 10 days

push eventdenoland/deno

Bert Belder

commit sha f911dc3afe521e018553d98bc904870817f5310f

ci: fix rusty_v8 binary download unavailable (#7898) A recent change in rustc or cargo made it so that rusty_v8's `build.rs`, which is responsible for downloading `librusty_v8.a`, does not get rebuilt or re-run when its build output directory is restored from the Github Actions cache. However, rusty_v8's custom build script does not save the download to its build output directory; it puts the file in `target/debug|release/gn_out/obj` instead. To get CI going again we opted to add `target/*/gn_out` to the Github Actions cache. A more robust fix would be make rusty_v8 save the download to the cargo-designated output directory.

view details

Bert Belder

commit sha 265c25754b56c60f72dd2a67cbb4c12696c7b3bb

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 265c25754b56c60f72dd2a67cbb4c12696c7b3bb

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 82eeebc445480ef1986a0cd92850e6c1fa74cacd

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 7b3786983598c30a08b591c36f34b43c7aeec379

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 220d3d569b79b8cd419d766cecf72a89acd81070

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventpiscisaureus/loader

Bert Belder

commit sha c35d61354b0e9f8dd0e42c95dcfdbd1d08c1b79e

Improve comments and code readability

view details

Bert Belder

commit sha 54a04dc72b51349b1793ef933e3a369bc317664a

Use a redirect to limit the number of imported "dummy" modules

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 4e1c0f16ef4e6b5bcce5e6d4e48f48562a23c9dd

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 9db7390dbd809295c0f64b8eb704bf16ddbfd21b

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 1e2c7995486cad2e7c4ca60c27669f3699f4781a

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha c1afc526710be8906867441142c823d95175533c

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha c860e98f9ee091981d9331b9cb7eb3cd8116f88b

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 5c949c089ecde3202d2594babbd7ef0a9b9a58f5

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha 5134b1ee5bb2ecc5a70f60eca06406a3a0a4ac1d

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha a96a386234c20532998aed504eb3b656788d9b57

ci: add workaround for MacOS + Cargo + Github Actions cache bug (#7898)

view details

push time in 10 days

push eventdenoland/deno

Bert Belder

commit sha f911dc3afe521e018553d98bc904870817f5310f

ci: fix rusty_v8 binary download unavailable (#7898) A recent change in rustc or cargo made it so that rusty_v8's `build.rs`, which is responsible for downloading `librusty_v8.a`, does not get rebuilt or re-run when its build output directory is restored from the Github Actions cache. However, rusty_v8's custom build script does not save the download to its build output directory; it puts the file in `target/debug|release/gn_out/obj` instead. To get CI going again we opted to add `target/*/gn_out` to the Github Actions cache. A more robust fix would be make rusty_v8 save the download to the cargo-designated output directory.

view details

push time in 10 days

issue commentdenoland/deno

Tests failing, CI green

Could it be that those are the 6 ignored tests after all?

piscisaureus

comment created time in 10 days

issue openeddenoland/deno

Tests failing, CI green

From: https://github.com/denoland/deno/runs/1231321926?check_suite_focus=true#step:17:2019

<...snip...>
test ASYNC: reading non-empty directory ... FAILED (7ms)
test SYNC: reading empty the directory ... ok (3ms)
test SYNC: reading a non-empty directory ... FAILED (5ms)
test Directories are correctly identified ... ok (4ms)
test Files are correctly identified ... ok (2ms)
test Symlinks are correctly identified ... ok (3ms)
test File name is correct ... ok (2ms)
test Socket and FIFO pipes aren't yet available ... ok (2ms)
test ASYNC: setting existing uid/gid works as expected (non-Windows) ... ok (6ms)
test SYNC: setting existing uid/gid works as expected (non-Windows) ... ok (5ms)
test ASYNC: Permissions are changed (non-Windows) ... ok (5ms)
test SYNC: Permissions are changed (non-Windows) ... ok (4ms)
test ASYNC: renaming a file ... test std_tests ... ok

test result: ok. 285 passed; 0 failed; 6 ignored; 0 measured; 0 filtered out
<...snip...>

created time in 10 days

PR opened denoland/deno

Maybe fix CI

<!-- Before submitting a PR, please read https://github.com/denoland/deno/blob/master/docs/contributing.md

  1. Give the PR a descriptive title.

Examples of good title: - fix(std/http): Fix race condition in server - docs(console): Update docstrings - feat(doc): Handle nested reexports

Examples of bad title: - fix #7123 - update docs - fix bugs

  1. Ensure there is a related issue and it is referenced in the PR text.
  2. Ensure there are tests that cover the changes.
  3. Ensure cargo test passes.
  4. Ensure ./tools/format.py passes without changing files.
  5. Ensure ./tools/lint.py passes. -->
+1 -0

0 comment

1 changed file

pr created time in 10 days

create barnchdenoland/deno

branch : fix-ci

created branch time in 10 days

PullRequestReviewEvent

push eventpiscisaureus/loader

Bert Belder

commit sha e658c9355a13601465212ec2c14ff04c6dcaab4f

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha 5b48140c8478af9c3d457c201ef42908ab6d8700

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha c4a53d704be646fac53a66d6058b9535b76d6a6d

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha 42a148c61f4f483b19bf2c190e2ec88eb373ce24

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha f7b4327da7e47f92a3abdb3d090416f91d8370d7

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha 9340c75e33844c46f514351246a637ee159dabc7

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha d546582b6883060239a86faadc258bcf5dd6d7d0

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha 8fcc451d4bb0363823e0a2362677a37251463f79

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha 9a91d232906db80b13603df508b6b591761e711d

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha 8a5da2b5d0468064925a790d3420210fb02e16d1

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha b889b49efb0eb59f732cf4043e09b08ccf767050

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha ea2f8128c74a2363cd35805383f66d02e91dbee0

Loader hook prototype

view details

push time in 11 days

push eventpiscisaureus/loader

Bert Belder

commit sha 8a950c46250bfa4b92c52562f940cf90847918e0

Loader hook prototype

view details

push time in 11 days

issue commentdenoland/rusty_v8

Script::compile sometimes throw maximum call stack size exceeded

@piscisaureus You've probably thought about this issue before. Ideas?

It seems that Locker does park/unpark some thread specific state so that could be it.

rusty_v8 did have Locker at some point but its removal was forced through by someone else, who one day got very upset that function calls were involved and those could be observed with dtrace.

abnud1

comment created time in 12 days

push eventpiscisaureus/loader

Bert Belder

commit sha fe7e795c845e6b89bf9799f2c3c625715799016b

fixes

view details

push time in 12 days

push eventpiscisaureus/loader

Bert Belder

commit sha 8f5c6ac62b2e70f582ebf9cb9313bc48742da14e

wip

view details

push time in 12 days

push eventpiscisaureus/loader

Bert Belder

commit sha e27ac529a0bcd8cf12572340384d390f7a019635

Clean up & tweak

view details

push time in 12 days

create barnchpiscisaureus/loader

branch : master

created branch time in 12 days

created repositorypiscisaureus/loader

created time in 12 days

pull request commentdenoland/deno

fix(cli/ops/fs): Don't replace Windows path separators

Thanks @nayeemrmn, we needed this! I messed up the commit message - sorry about that.

nayeemrmn

comment created time in 12 days

push eventdenoland/deno

Nayeem Rahman

commit sha c226d3af2572c93af21f5a3261ede4dd8855685e

fix(cli/ops/fs): Don't force Windows paths separate paths with forward slash (#7833)

view details

push time in 12 days

PR closed denoland/deno

Reviewers
fix(cli): realPath honors non-unc win32 path separator cli user feedback wanted windows
  • closes #5685

<!-- Before submitting a PR, please read https://github.com/denoland/deno/blob/master/docs/contributing.md -->

Description:

This PR tries to fix path separator returned by realPah.

It looks like issue stemmed from https://github.com/rust-lang/rust/issues/42869. Canonicalize on windows returns UNC path, stripping unc host (https://github.com/denoland/deno/blob/master/cli/ops/fs.rs?rgh-link-date=2020-06-02T04%3A57%3A06Z#L584) will leave rest of path do not honor win32 path separator. Given std canonicalize does not provide workaround yet, stripping UNC via drop-in replacement (gitlab.com/kornelski/dunce) seems the easiest way to fix instead of re-implementing UNC stripping logics.

It may possible using another crate may not be desired or other way to workaround may exist.

+16 -8

2 comments

4 changed files

kwonoj

pr closed time in 12 days

PR merged denoland/deno

fix(cli/ops/fs): Don't replace Windows path separators

Fixes #5685. Closes #6073.

+25 -22

1 comment

2 changed files

nayeemrmn

pr closed time in 12 days

issue closeddenoland/deno

realPathSync returns paths with UNIX "/" separator on Windows

Observed on Deno 1.0.1, for example:

PS C:\Users\srackham> deno eval "console.log(Deno.realPathSync('.'))"
C:/Users/srackham

Other Deno path APIs return '\' separated paths on Window e.g. Deno.cwd().

closed time in 12 days

srackham
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentdenoland/deno

fix(core): module execution with top level await

 impl JsRuntime {       .expect("ModuleInfo not found");     let mut status = module.get_status(); +    let (sender, receiver) = mpsc::channel(1);

Yeah I don't have any suggestions either...

bartlomieju

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentdenoland/deno

fix(core): module execution with top level await

 impl JsRuntime {       .expect("ModuleInfo not found");     let mut status = module.get_status(); +    let (sender, receiver) = mpsc::channel(1);
  • Using a channel within a thread ... not my favorite pattern ever.
  • Wouldn't a Oneshot work just as well?
bartlomieju

comment created time in 14 days

PullRequestReviewEvent

pull request commentdenoland/deno

fix(core): module execution with top level await

The strategy seems sound to me. Also underlines the need for this monster to be refactored...

bartlomieju

comment created time in 14 days

Pull request review commentdenoland/deno

fix(core): module execution with top level await

 impl JsRuntime {         let promise_id = promise.get_identity_hash();         let mut state = state_rc.borrow_mut();         state.pending_promise_exceptions.remove(&promise_id);+        let promise_global = v8::Global::new(scope, promise);+        state+          .pending_mod_evaluate+          .insert(id, (promise_global, sender));       } else {         assert!(status == v8::ModuleStatus::Errored);       }     } -    match status {-      v8::ModuleStatus::Evaluated => Ok(()),-      v8::ModuleStatus::Errored => {-        let exception = module.get_exception();-        exception_to_err_result(scope, exception)-          .map_err(|err| attach_handle_to_error(scope, err, exception))+    Ok(receiver)+  }++  pub async fn mod_evaluate(&mut self, id: ModuleId) -> Result<(), AnyError> {

What happens if you try to tokio::select! on both the result of mod_evaluate and the JsRuntime itself?

That either isn't or shouldn't be possible. You need a &mut reference to a Future to poll it, so you can't poll X and a container with X in it at the same time.

bartlomieju

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentdenoland/deno

fix(core): module execution with top level await

 mod tests {     let a_id_fut = runtime.load_module(&spec, None);     let a_id = futures::executor::block_on(a_id_fut).expect("Failed to load"); -    runtime.mod_evaluate(a_id).unwrap();+    futures::executor::block_on(runtime.mod_evaluate(a_id)).unwrap();

OK so no nesting. Awesome!

bartlomieju

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentdenoland/deno

fix(core): module execution with top level await

 mod tests {     let a_id_fut = runtime.load_module(&spec, None);     let a_id = futures::executor::block_on(a_id_fut).expect("Failed to load"); -    runtime.mod_evaluate(a_id).unwrap();+    futures::executor::block_on(runtime.mod_evaluate(a_id)).unwrap();

I mean block_on or equivalent... [tokio_main] qualifies too I think... You should be able to replace block_on with tokio's block_on, like this. If it doesn't panic we're golden.

bartlomieju

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentdenoland/deno

fix(core): module execution with top level await

 mod tests {     let a_id_fut = runtime.load_module(&spec, None);     let a_id = futures::executor::block_on(a_id_fut).expect("Failed to load"); -    runtime.mod_evaluate(a_id).unwrap();+    futures::executor::block_on(runtime.mod_evaluate(a_id)).unwrap();

The issue with this is the following: Normally you can't block_on inside a block_on. Both tokio and futures crate will panic. However the "futures" crate doesn't detect tokio's presence, so this works. However the outer event loop may not make progress (depending on the kind of i/o, operating system etc.)

Correct me if this is not a case of nested block_on and I am mistaken.

bartlomieju

comment created time in 14 days

PullRequestReviewEvent

PR closed denoland/deno

Update in code invalid

<!-- Before submitting a PR, please read It carefully https://github.com/denoland/deno/blob/master/docs/contributing.md -->

+0 -0

1 comment

1 changed file

parth377

pr closed time in 18 days

push eventparth377/deno

Bert Belder

commit sha 650dd78fd44f0a90430be4038d60c8c3e6b2445b

💩

view details

push time in 18 days

PullRequestEvent

pull request commentdenoland/rusty_v8

Add ValueSerializer, ValueDeserializer bindings for structured clone in deno

Apologies for the delay, I’ll land this soon.

inteon

comment created time in 19 days

more