starteddenoland/deno

started time in 35 minutes

push eventdenoland/deno

Deployment Bot (from Travis CI)

commit sha 6f0121a1957bd7e4bdcc20dc71faa79a8c0950ba

Deploy denoland/deno to github.com/denoland/deno.git:gh-pages

view details

push time in an hour

PR opened denoland/deno

dialTLS - WIP - Feedback and lifetime question

I am having trouble building with the following error:

error[E0621]: explicit lifetime required in the type of `base`
    --> ../../cli\ops.rs:1645:3
     |
1615 |   base: &msg::Base<'_>,
     |         -------------- help: add explicit lifetime `'static` to the type of `base`: `&msg::Base<'static>`
...
1645 |   Box::new(op)
     |   ^^^^^^^^^^^^ lifetime `'static` required

From the tokio-rustls example at https://github.com/quininer/tokio-rustls/blob/0.9/examples/client/src/main.rs, I see they use the .map(drop), which I assume is affecting the lifetime of the returned stream. However, any time I try to map(drop) the promise I can't build it with:

error[E0271]: type mismatch resolving `<fn(std::boxed::Box<[u8]>) {std::mem::drop::<std::boxed::Box<[u8]>>} as std::ops::FnOnce<(std::boxed::Box<[u8]>,)>>::Output == std::boxed::Box<[u8]>`
    --> ../../cli\ops.rs:1646:3
     |
1646 |   Box::new(op)
     |   ^^^^^^^^^^^^ expected (), found struct `std::boxed::Box`
     |
     = note: expected type `()`
                found type `std::boxed::Box<[u8]>`
     = note: required because of the requirements on the impl of `futures::Future` for `futures::Map<futures::AndThen<futures::AndThen<futures::AndThen<futures::MapErr<resolve_addr::ResolveAddrFuture, fn(resolve_addr::ResolveAddrError) -> errors::DenoError {<errors::DenoError as std::convert::From<resolve_addr::ResolveAddrError>>::from}>, futures::MapErr<tokio_tcp::stream::ConnectFuture, fn(std::io::Error) -> errors::DenoError {<errors::DenoError as std::convert::From<std::io::Error>>::from}>, [closure@../../cli\ops.rs:1631:17: 1634:8]>, futures::MapErr<tokio_rustls::Connect<tokio_tcp::stream::TcpStream>, fn(std::io::Error) -> errors::DenoError {<errors::DenoError as std::convert::From<std::io::Error>>::from}>, [closure@../../cli\ops.rs:1635:17: 1643:8 address:_]>, std::result::Result<std::boxed::Box<[u8]>, errors::DenoError>, [closure@../../cli\ops.rs:1644:17: 1644:67 cmd_id:_]>, fn(std::boxed::Box<[u8]>) {std::mem::drop::<std::boxed::Box<[u8]>>}>`
     = note: required for the cast to the object type `dyn futures::Future<Error=errors::DenoError, Item=std::boxed::Box<[u8]>> + std::marker::Send`

error: aborting due to previous error

The error is over my head at this point. Any feedback or help would be appreciated.

+97 -2

0 comment

6 changed files

pr created time in an hour

push eventdenoland/deno

Ryan Dahl

commit sha 7fc9d7d62a864d1e6af0e77291a105726f73279c

core: Add test for snapshotting from Rust (#2197)

view details

push time in an hour

PR merged denoland/deno

Add rust test for snapshotting
+78 -35

0 comment

5 changed files

ry

pr closed time in an hour

PR opened denoland/deno_std

fix ensureLink broken. close #358

fix #358

+4 -3

0 comment

2 changed files

pr created time in an hour

starteddenoland/deno

started time in an hour

push eventdenoland/deno

Deployment Bot (from Travis CI)

commit sha 0898a787345a70973297c64d9965b79ebcb199aa

Deploy denoland/deno to github.com/denoland/deno.git:gh-pages

view details

push time in 2 hours

push eventdenoland/deno

Ryan Dahl

commit sha f6948235079b1d6050a2d3c98891844cb97595f5

Fix symlinkSyncNotImplemented (#2198)

view details

push time in 2 hours

PR merged denoland/deno

Fix symlinkSyncNotImplemented

<!-- Before submitting a PR read https://deno.land/manual.html#contributing -->

+4 -1

0 comment

1 changed file

ry

pr closed time in 2 hours

push eventdenoland/deno_std

Ryan Dahl

commit sha 4f6a070e1c7cbe7aad281bb8dc0b6435239f4cdc

Bump CI to v0.3.8 (#357)

view details

push time in 2 hours

PR merged denoland/deno_std

Bump CI to v0.3.8
+1 -1

0 comment

1 changed file

ry

pr closed time in 2 hours

Pull request review commentdenoland/deno

Add rust test for snapshotting

 impl Isolate {     let shared = SharedQueue::new(RECOMMENDED_SIZE);      let needs_init = true;-    // Seperate into Option values for eatch startup type-    let (startup_snapshot, startup_script) = match startup_data {-      StartupData::Snapshot(d) => (Some(d), None),-      StartupData::Script(d) => (None, Some(d)),-      StartupData::None => (None, None),-    };-    let libdeno_config = libdeno::deno_config {-      will_snapshot: 0,-      load_snapshot: match startup_snapshot {-        Some(s) => Snapshot2::from(s),-        None => Snapshot2::empty(),-      },++    let mut startup_script: Option<Script> = None;+    let mut libdeno_config = libdeno::deno_config {+      will_snapshot: if config.will_snapshot { 1 } else { 0 },+      load_snapshot: Snapshot2::empty(),       shared: shared.as_deno_buf(),       recv_cb: Self::pre_dispatch,     };++    // Seperate into Option values for eatch startup type

eatch -> each

ry

comment created time in 2 hours

push eventdenoland/deno

Ryan Dahl

commit sha 6bece270b2719a66b564a411fc28c3b32ae0b105

Upgrade CI to Node v12 (#2193)

view details

push time in 2 hours

PR merged denoland/deno

Upgrade CI to Node v12

<!-- Before submitting a PR read https://deno.land/manual.html#contributing -->

+3 -2

0 comment

2 changed files

ry

pr closed time in 2 hours

starteddenoland/deno

started time in 3 hours

starteddenoland/deno

started time in 4 hours

starteddenoland/deno

started time in 4 hours

starteddenoland/deno

started time in 4 hours

starteddenoland/deno

started time in 4 hours

starteddenoland/deno

started time in 6 hours

starteddenoland/deno

started time in 6 hours

starteddenoland/deno

started time in 6 hours

starteddenoland/deno

started time in 6 hours

starteddenoland/deno

started time in 7 hours

issue commentdenoland/deno

feature-request: Expose the same API in node.js

@ry Since I believe most of the issues will be about incompatibilities with Node API instead of proposing new functionalities

WillAvudim

comment created time in 7 hours

starteddenoland/deno

started time in 7 hours

starteddenoland/deno

started time in 8 hours

starteddenoland/deno

started time in 8 hours

starteddenoland/deno

started time in 8 hours

starteddenoland/deno

started time in 8 hours

PR closed denoland/deno

temp

<!-- Before submitting a PR read https://deno.land/manual.html#contributing -->

+100 -62

0 comment

3 changed files

fewf

pr closed time in 9 hours

PR opened denoland/deno

temp

<!-- Before submitting a PR read https://deno.land/manual.html#contributing -->

+100 -62

0 comment

3 changed files

pr created time in 9 hours

PR opened denoland/deno

Fix symlinkSyncNotImplemented

<!-- Before submitting a PR read https://deno.land/manual.html#contributing -->

+4 -1

0 comment

1 changed file

pr created time in 9 hours

starteddenoland/deno

started time in 9 hours

Pull request review commentdenoland/deno

[WIP] permissions whitelist

 pub fn parse_flags(matches: ArgMatches) -> DenoFlags {   if matches.is_present("allow-read") {     flags.allow_read = true;   }+  if let Some(read_wl) = matches.values_of("read-wl") {+    flags.read_whitelist = read_wl.map(|s| s.to_string()).collect();+  }   if matches.is_present("allow-write") {     flags.allow_write = true;   }+  if let Some(write_wl) = matches.values_of("write-wl") {+    flags.write_whitelist = write_wl.map(|s| s.to_string()).collect();+  }   if matches.is_present("allow-net") {     flags.allow_net = true;   }+  if let Some(net_wl) = matches.values_of("net-wl") {

Semantically using - under --allow-net to signify blacklist is a bit of a stretch. Also imo one char difference is too small.

Another flag for --reject-net or something?

afinch7

comment created time in 9 hours

Pull request review commentdenoland/deno

[WIP] permissions whitelist

 pub fn parse_flags(matches: ArgMatches) -> DenoFlags {   if matches.is_present("allow-read") {     flags.allow_read = true;   }+  if let Some(read_wl) = matches.values_of("read-wl") {+    flags.read_whitelist = read_wl.map(|s| s.to_string()).collect();+  }   if matches.is_present("allow-write") {     flags.allow_write = true;   }+  if let Some(write_wl) = matches.values_of("write-wl") {+    flags.write_whitelist = write_wl.map(|s| s.to_string()).collect();+  }   if matches.is_present("allow-net") {     flags.allow_net = true;   }+  if let Some(net_wl) = matches.values_of("net-wl") {

I was pondering it for some time now and @hayd's idea seems pretty ergonomic, but... consider that if there's a whitelist, people will probably want a blacklist as well. Surely this would be solvable by adding some special syntax (maybe -?, eg. --allow-net=127.0.0.1,-0.0.0.0,). But then again that would add some unneeded cognitive overhead and magic... Ideas?

CC @rsp might be interested

afinch7

comment created time in 10 hours

PR opened denoland/deno

Snapshots2

<!-- Before submitting a PR read https://deno.land/manual.html#contributing -->

+77 -35

0 comment

5 changed files

pr created time in 10 hours

starteddenoland/deno

started time in 10 hours

Pull request review commentdenoland/deno

[WIP] permissions whitelist

 pub fn parse_flags(matches: ArgMatches) -> DenoFlags {   if matches.is_present("allow-read") {     flags.allow_read = true;   }+  if let Some(read_wl) = matches.values_of("read-wl") {+    flags.read_whitelist = read_wl.map(|s| s.to_string()).collect();+  }   if matches.is_present("allow-write") {     flags.allow_write = true;   }+  if let Some(write_wl) = matches.values_of("write-wl") {+    flags.write_whitelist = write_wl.map(|s| s.to_string()).collect();+  }   if matches.is_present("allow-net") {     flags.allow_net = true;   }+  if let Some(net_wl) = matches.values_of("net-wl") {

Naming wise why not reuse the original, so that --allow-net is equivalent to --allow-net=*.

afinch7

comment created time in 10 hours

starteddenoland/deno_install

started time in 10 hours

pull request commentdenoland/deno

[WIP] permissions whitelist

This looks great!

afinch7

comment created time in 10 hours

issue closeddenoland/deno

allow-read allow-write permissions constrained to specific directories

It seems like allow-read and allow-write are very wide open permissions when all you want to do is maybe read a configuration file from the same directory as the script is located in. Would be nice to have the ability to specific which directory you want to grant the read and/or write permissions to. Also, would be nice to be able to easily allow them for the directory that the script is located in.

closed time in 10 hours

ejsmith

issue commentdenoland/deno

allow-read allow-write permissions constrained to specific directories

Awesome! I was trying to find an existing issue, but I couldn't find it.

ejsmith

comment created time in 10 hours

issue commentdenoland/deno

allow-read allow-write permissions constrained to specific directories

Discussion for reference: #2081 Related PR: #2129

ejsmith

comment created time in 10 hours

starteddenoland/deno

started time in 10 hours

issue openeddenoland/deno

allow-read allow-write permissions constrained to specific directories

It seems like allow-read and allow-write are very wide open permissions when all you want to do is maybe read a configuration file from the same directory as the script is located in. Would be nice to have the ability to specific which directory you want to grant the read and/or write permissions to. Also, would be nice to be able to easily allow them for the directory that the script is located in.

created time in 10 hours

issue commentdenoland/deno

Provide JS API to dependency information

Depends on how you parse the deps but the order may not be lost.

ry

comment created time in 11 hours

issue commentdenoland/deno

Provide JS API to dependency information

Yeah that works.. My only concern is that the ordering of the imports would be lost - but that might be recoverable from the object anyway(?) also the ordering of the imports is not very important info...

ry

comment created time in 11 hours

issue openeddenoland/deno

Use globalThis instead

Is this a good time to refactor this to use globalThis which has been supported since v8 v7.1?

https://github.com/denoland/deno/blob/d68b44b6b2fad6c321aa01a039030bb98c5be88d/js/window.ts#L7

created time in 11 hours

issue commentdenoland/deno

Implement Cache​Storage

If you read the whole issue there is same concern about Cache Session and so on

Ah!

davidbarratt

comment created time in 11 hours

issue commentdenoland/deno

Implement Cache​Storage

If you read the whole issue there is same concern about Cache Session and so on

davidbarratt

comment created time in 11 hours

issue commentdenoland/deno

Implement Cache​Storage

There is already an issue about the implementation of different kind of Storage : #1657

That's a different API / Interface. :)

davidbarratt

comment created time in 11 hours

issue commentdenoland/deno

Provide JS API to dependency information

took me a sec to get started on this--sorry!

@ry when we spoke, i think we considered that the JSON structure could be a nested array like:

[
  [
    "dep1", [
      ["subdep1", [["subsubdep1", []]],
      ["subdep2", []]
    ]
  ],
  [
    "dep2", []
  ]
]

but I'm think it might be better as a nested object, like:

{
  dep1: {
    subdep1: {
      subsubdep1: {}
    },
    subdep2: {}
  },
  dep2: {}
}

what do you think?

ry

comment created time in 11 hours

issue commentdenoland/deno

Implement Cache​Storage

There is already an issue about the implementation of different kind of Storage : https://github.com/denoland/deno/issues/1657

davidbarratt

comment created time in 11 hours

issue commentdenoland/deno_std

Module fs is broken.

cc @axetroy

AlvaroBernalG

comment created time in 11 hours

starteddenoland/deno

started time in 11 hours

PR opened denoland/deno_std

http: Cookie extend

Add delCookie and setCookie.

I have a concern about the multiple Set-Cookie header. It's common to use BUT Headers does not give us the possibility to do this. Do you think any workaround is possible? I think we can keep it like this for the moment and work on multiple Set-Cookie headers handling in a future PR.

Also Days / Months format are hardcoded in the module because ATM there is some discussions about embedding or not the ICU in Deno which may break this module.

+281 -6

0 comment

2 changed files

pr created time in 12 hours

starteddenoland/deno_std

started time in 12 hours

issue openeddenoland/deno_std

Module fs is broken.

Hello good people of Denoland,

The module fs is throwing the following error :

deno_std/fs/ensure_link.ts:42:30 - TS2693: 'PathType' only refers to a type, but is being used as a value here.

42 if (destFilePathType !== PathType.file) {

The reason why nobody has realised that the module is failing is because is not being required inside the main test file.

created time in 12 hours

fork VariableVasasMT/deno

A secure JavaScript/TypeScript runtime built with V8, Rust, and Tokio

https://deno.land/

fork in 12 hours

starteddenoland/deno

started time in 12 hours

fork yudgnut/deno

A secure JavaScript/TypeScript runtime built with V8, Rust, and Tokio

https://deno.land/

fork in 12 hours

starteddenoland/deno

started time in 12 hours

starteddenoland/deno

started time in 12 hours

issue openeddenoland/deno

Implement Cache​Storage

I noticed that CacheStorage hasn't been implemented yet, so here's a task to implement it. Thank you for all your hard work! :)

created time in 13 hours

issue commentdenoland/deno

Add ICU in embedded v8

AFAIK, even Node.js does not include full ICU sometimes on certain platform. It'd would be better off adding new flag that allows users to use whichever ICU they want on instead of embedding it because of it's size. An awesome package like full-icu is used in such case.

zekth

comment created time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 13 hours

starteddenoland/deno

started time in 14 hours

starteddenoland/deno

started time in 14 hours

starteddenoland/deno

started time in 14 hours

issue commentdenoland/deno

Deno advantages and potential

Hey guys, I am in the process of growing some love to Deno and I have something which is bothering me.

I know Ryan likes TypeScript. But will Deno have any real benefit from using it at the core? I mean, will the runtime use raw TypeScript to squeeze performance, maybe passing types somehow to V8 or another underlying component, providing better performance than just JS?

I think this should be taken into consideration, of course, not because of my preferences but because JS community is used to optimizations (because of the times of IE and the culture of V8 vs SomeMonkey). We also see some runtimes almost reaching Java on some algorithm benchmarks and the contrary could be seen as a kind of regression, maybe, IMHO.

The point is: is Deno really focusing on some Unix-y light, fast, optimal approach or this is not one of the main guidelines, if not the main guideline?

cllty

comment created time in 14 hours

starteddenoland/deno

started time in 14 hours

fork light-bringer/deno

A secure JavaScript/TypeScript runtime built with V8, Rust, and Tokio

https://deno.land/

fork in 15 hours

starteddenoland/deno

started time in 15 hours

PR opened denoland/deno

Upgrade CI to Node v12

<!-- Before submitting a PR read https://deno.land/manual.html#contributing -->

+3 -3

0 comment

2 changed files

pr created time in 15 hours

starteddenoland/deno

started time in 15 hours

delete branch denoland/deno_std

delete branch : upgrade

delete time in 15 hours

push eventdenoland/deno_std

Ryan Dahl

commit sha aad8b69fdd842e5be786727b64eda73f9371280b

trigger

view details

push time in 15 hours

starteddenoland/deno

started time in 15 hours

push eventdenoland/deno_std

Vincent LE GOFF

commit sha 4543b563a9a01c8c168aafcbfd9d4634effba7fc

Eslint fixes (#356) Make warnings fail

view details

push time in 15 hours

PR merged denoland/deno_std

Eslint fixes

Fixes all the eslint warnings raised by Deno 0.3.8

+949 -807

3 comments

88 changed files

zekth

pr closed time in 15 hours

push eventdenoland/deno_std

Vincent LE GOFF

commit sha 1d8544788648b4c571d10b9a55cc3670a1cbf69c

http : Add cookie module (#338)

view details

push time in 15 hours

PR merged denoland/deno_std

http : Add cookie module

cookie is now part of ServerRequest and can be accessed by ServerRequest.cookie Resolve https://github.com/denoland/deno_std/issues/334

+47 -0

7 comments

3 changed files

zekth

pr closed time in 15 hours

issue closeddenoland/deno_std

discuss: cookie

node use cookie

req.headers.cookie && req.headers.cookie.split(';').forEach(function (Cookie) { var parts = Cookie.split('='); Cookies[parts[0].trim()] = (parts[1] || '').trim(); });

How does deno read the cookie ?

closed time in 15 hours

runnerSnail

starteddenoland/deno

started time in 15 hours

starteddenoland/deno

started time in 15 hours

starteddenoland/deno

started time in 15 hours

starteddenoland/deno

started time in 15 hours

starteddenoland/deno

started time in 16 hours

more