Feel free to close if this is not the right direction

Ah - thanks!

Actually I'd rather that we remove the parseFileSync and leave it up to the caller to load the data. The TOML module should only deal with parsing, not with I/O.

Would you mind a revised PR that removes parseFileSync (or just moves it to the test module - if that is needed there)?

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

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

This PR changes CLI flags --help and --version to subcommands.

• Changes to deno --version: It has been renamed to deno version subcommand, so effectively you no longer can do deno --version some_file.ts

$ deno version
deno: 0.3.9
v8: 7.4.238
typescript: 3.4.1

• Changes to deno --help: Deno still has deno --help and deno -h. Additionally a new subcommand deno help is present which can be used two-fold:

$ deno help // works just like deno -h
deno

USAGE:
    deno [FLAGS] [OPTIONS] [SUBCOMMAND]
...

$ deno help <subcommand> // display help for subcommand

$ deno help eval
Eval script

USAGE:
    deno eval <code>

FLAGS:
    -h, --help    Prints help information

ARGS:
    <code>

@ry if #2189 is a go, I'll add it to this PR as well

As NodeJs 12 has been released it would be nice to have it in the benchmarks.

ref: https://nodejs.org/en/blog/release/v12.0.0/

Yes. And note that node_tcp with v12 has overtaken deno_core_single ... we have more work to do.

I wasn’t able to come up with a test for this issue... I think the only think we could do is scan the executable for unwanted paths. But I believe #2208 is fixed now.

Fixes #2208

despite this integration test: https://github.com/denoland/deno/blob/master/tests/types.test

./tools/build.py && ./tools/integration_tests.py --filter types.test

passes

Let’s do “deno run” in a different PR. That has a higher likelihood of breaking something.

Closes #2206

cc @bartlomieju

' i'd like to reserve 'deno compile' for bundling into an executable

@bartlomieju separate PR please

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

Could you also rename the file tools/prefetch_test.py to tools/fetch_test.py?

Issue: https://github.com/denoland/deno/issues/2203

Fixes #2208

despite this integration test: https://github.com/denoland/deno/blob/master/tests/types.test

If you reload the page once (and wait a minute) it will work. Terrible UX.

Seems that the url changed:

curl -fsSL https://deno.land/x/install/install.sh | sh -s v0.3.9
-#O#- #   #                                                                           
curl: (22) The requested URL returned error: 404 Not Found

linux build died but i restarted it and it should work now.

@kevinkassimo Ok sure. Does anyone want to start a repo outside of denoland for this? We can point people to it in the manual as the semi-official binding layer. I feel like things might move faster if I'm not in the loop. If it works out and is useful we can consider moving it into deno_std later.

Will node programs be able to run via deno? Will there be an adapter? I think that's pretty important if deno adaption is to increase.

duplicate of https://github.com/denoland/deno/issues/2184

I don't think this constant makes thing easier or more maintainable.

@jorsi Nice start! I've pushed a few commits - I ran ./tools/format.py and converted the address variable into an owned String so it could be passed to the callbacks (which need ownerships of variables they capture, since these callbacks are executed in the thread pool)

There's a test web server that is running during the tests at tools/http_server.py but it doesn't support HTTPS. Ideally we could modify that to also host a HTTPS server for testing.

get should method should return string

PS: I build a website for Deno's Web-Platform-Tests https://deno.dev/wpt/

@justjavac Wow - Nice site!

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

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

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

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

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

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...

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

Fixes all the eslint warnings raised by Deno 0.3.8

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

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 ？

@kevinkassimo I'm not opposed to doing it in a separate repo - but why do they need to different kind of issue trackers?

@kevinkassimo I'm not opposed to doing it in a separate repo - but why do they need to different kind of issue trackers?

Ok, but do we still keep the cache handling of the cookies in the ServerRequest class?

No. I think it's fine to keep this in the external modules. It's an extra import, but frameworks can make that easier for people. Many users of http/server.ts will not need cookies, if we can keep some functionality out we should.

@zekth Ideally just a function.

import { getCookies } from "https://deno.land/std/http/cookies.ts"

getCookies(request);

Something like this?

Can this moved into a separate module? I’d rather http/server.ts stay lean

@zekth @hayd I mean - the scheme of using command-line arguments to filter the tests isn't necessarily necessary. What if we start js/unit_tests.ts with full permissions and use revokePermission()? I'm not sure that works - but I'm suggesting that we think outside the box, and refactor this entire system, rather than bike shedding on how to represent the test filter in a string.

A helpful first step towards this (and to better understand the problem) would be to port tools/unit_tests.py to Deno.

Dispatch is now dynamic dispatch, slightly less efficent. The immeasurable perf hit is a reasonable trade the API simplicity that is gained here.

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

If the dispatcher isn't set in Config currently Deno.core.dispatch() causes a panic. But I think it would be cool, in the future, to have Deno.core.dispatch() throw a JS error instead.

I think there are many cases where you would want to use the deno crate but not want to implement ops.. For example if you wanted to make a very simple d8 style program. It's also nice to have small examples of using the isolate without having to also implement dispatch.

F is called on random threads, so it needs to be thread safe

make it same with Deno.symlink(). It `s my mistake.

Possible value:

• 'dir'
• 'file'
• 'symlink'
• ~null~ undefined

/** Creates `newname` as a symbolic link to `oldname`. The type argument can be
 * set to `dir` or `file` and is only available on Windows (ignored on other
 * platforms).
 *
 *       await Deno.symlink("old/name", "new/name");
 */
export function symlink(
  oldname: string,
  newname: string,
  type?: string
): Promise<void>;

It's becoming clear that Deno is going to have several distinct tools as subcommands, like "info" and "prefetch" each with (potentially) their own options. I suggest we not have a default command, as it introduces complexity at the flag parsing layer and makes it unclear what flags belong to "run" vs other subcommands.

What do people think? It's slightly less ergonomic, but I think we can address that in other ways.

cc @bartlomieju

Fixes https://github.com/denoland/deno/issues/1311

Ref https://github.com/tokio-rs/tokio/pull/1052 Ref https://github.com/tokio-rs/tokio/pull/1055