| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This PR optimizes `DOMException` constructor increasing performance of
all Web APIs that throw a `DOMException` (ie: `AbortSignal`)
**main**
```
cpu: 13th Gen Intel(R) Core(TM) i9-13900H
runtime: deno 1.37.1 (x86_64-unknown-linux-gnu)
new DOMException() 9.66 µs/iter 103,476.8 (8.47 µs … 942.71 µs) 9.62 µs 11.29 µs 14.04 µs
abort writeTextFileSync 16.45 µs/iter 60,775.5 (13.65 µs … 1.33 ms) 16.39 µs 20.59 µs 24.12 µs
abort readFile 16.25 µs/iter 61,542.2 (15.12 µs … 621.14 µs) 16.18 µs 19.59 µs 22.33 µs
```
**this PR**
```
cpu: 13th Gen Intel(R) Core(TM) i9-13900H
runtime: deno 1.37.1 (x86_64-unknown-linux-gnu)
benchmark time (avg) iter/s (min … max) p75 p99 p995
----------------------------------------------------------------------------- -----------------------------
new DOMException() 2.37 µs/iter 421,657.0 (2.33 µs … 2.58 µs) 2.37 µs 2.58 µs 2.58 µs
abort writeTextFileSync 7.1 µs/iter 140,760.1 (6.94 µs … 7.68 µs) 7.13 µs 7.68 µs 7.68 µs
abort readFile 5.48 µs/iter 182,648.2 (5.3 µs … 5.69 µs) 5.56 µs 5.69 µs 5.69 µ
```
```js
Deno.bench("new DOMException()", () => {
new DOMException();
});
Deno.bench("abort writeTextFileSync", () => {
const ac = new AbortController();
ac.abort();
try {
Deno.writeTextFileSync("/tmp/out", "x", { signal: ac.signal });
} catch {}
});
Deno.bench("abort readFile", async () => {
const ac = new AbortController();
ac.abort();
try {
await Deno.readFile("/tmp/out", { signal: ac.signal });
} catch {}
});
```
|
|
Creates the `cli::npm::managed` module and starts moving more
functionality into it.
|
|
Use the `core.byteLength` op for string utf8 length calculation in
`node:buffer`
```
# This patch
file:///Users/divy/gh/deno/buffer.mjs
benchmark time (avg) iter/s (min … max) p75 p99 p995
----------------------------------------------------------------- -----------------------------
Buffer#from 272.11 ns/iter 3,675,029.3 (268.41 ns … 301.15 ns) 271.62 ns 295.5 ns 301.15 ns
# Deno 1.37.1
file:///Users/divy/gh/deno/buffer.mjs
benchmark time (avg) iter/s (min … max) p75 p99 p995
----------------------------------------------------------------- -----------------------------
Buffer#from 411.28 ns/iter 2,431,428.8 (393.82 ns … 439.92 ns) 418.85 ns 434.4 ns 439.92 ns
```
|
|
|
|
Add `test-http-url.parse*` tests for Node compat.
|
|
(#20714)
Exposes
[`metadata`](https://jupyter-client.readthedocs.io/en/latest/messaging.html#metadata)
to the `Deno.jupyter.broadcast` API.
```js
await Deno.jupyter.broadcast(msgType, content, metadata);
```
The metadata is required for
[`"comm_open"`](https://github.com/jupyter-widgets/ipywidgets/blob/main/packages/schema/messages.md#instantiating-a-widget-object-1)
for with `jupyter.widget` target.
|
|
|
|
fixes #20454
Current KV queues implementation assumes that `enqueue` and
`listenQueue` are called on the same instance of `Deno.Kv`. It's
possible that the same Deno process opens multiple KV instances pointing
to the same fs path, and in that case `listenQueue` should still get
notified of messages enqueued through a different KV instance.
|
|
This makes `CliNpmResolver` a trait. The terminology used is:
- **managed** - Deno manages the node_modules folder and does an
auto-install (ex. `ManagedCliNpmResolver`)
- **byonm** - "Bring your own node_modules" (ex. `ByonmCliNpmResolver`,
which is in this PR, but unimplemented at the moment)
Part of #18967
|
|
This is required from BYONM (bring your own node_modules).
Part of #18967
|
|
|
|
This is what we do for deno install, so it should be fine here
https://github.com/denoland/deno_install/pull/219
Closes https://github.com/denoland/deno/issues/20683
|
|
Accidentally removed in
https://github.com/denoland/deno/commit/69b7166c20b47d320fc85e33dca9414c92ec9c6f
|
|
|
|
For the following example, if I set the encoding to `base64url`, it'll
throw an unexpected TypeError:
```ts
import { Buffer } from "node:buffer";
Buffer.from("IntcImhlbGxvXCI6XCJoZGQvZStpXCJ9Ig", "base64url").toString();
// error: Uncaught TypeError: src.subarray is not a function
// const buf = Buffer.from(
// ^
// at blitBuffer (ext:deno_node/internal/buffer.mjs:1779:15)
// at Uint8Array.base64urlWrite (ext:deno_node/internal/buffer.mjs:691:10)
// at Object.write (ext:deno_node/internal/buffer.mjs:2195:11)
// at Uint8Array.write (ext:deno_node/internal/buffer.mjs:794:14)
// at fromString (ext:deno_node/internal/buffer.mjs:214:22)
// at _from (ext:deno_node/internal/buffer.mjs:119:12)
// at Function.from (ext:deno_node/internal/buffer.mjs:157:10)
// at file:///Users/foodieats/temp/buffer1.ts:3:20
```
The error caused by `base64urlWrite` function, it should call
`forgivingBase64UrlDecode` not `forgivingBase64UrlEncode`
Also fixed #20563 .
|
|
Also a drive-by cleanup elsewhere (removing unused enum).
Fixes #20702
|
|
This is the release commit being forwarded back to main for 1.37.1
Co-authored-by: littledivy <littledivy@users.noreply.github.com>
|
|
This patch adds support for [key
expiration](https://docs.deno.com/kv/manual/key_expiration) in the
remote backend.
|
|
This fixes the `TypeError: Database closed` error during shutdown.
|
|
|
|
Closes https://github.com/denoland/deno/issues/20591
---------
Co-authored-by: Kyle Kelley <rgbkrk@gmail.com>
|
|
```
Updating deno_core v0.217.0 -> v0.218.0
Updating deno_ops v0.93.0 -> v0.94.0
Updating deno_semver v0.5.0 -> v0.5.1
Updating fastrand v2.0.0 -> v2.0.1
Updating serde_v8 v0.126.0 -> v0.127.0
Updating sha2 v0.10.7 -> v0.10.8
Updating time v0.3.28 -> v0.3.29
Updating time-core v0.1.1 -> v0.1.2
Updating time-macros v0.2.14 -> v0.2.15
```
|
|
For #20683
|
|
|
|
|
|
This API is providing hoops to jump through with undergoing migration to
`#[op2]` macro.
The overhead of supporting this API is non-trivial and besides internal
use of it in test sanitizers is very rarely used in the wild.
|
|
|
|
Use the [scopeguard](https://docs.rs/scopeguard/) defer macro to run
cleanup code for `new_slab_future`.
This means it can be a single async function, avoiding the need to
create a struct and implement `PinnedDrop`
Async cleanup in Rust is awkward because async functions may be
cancelled at any await point when their Future is dropped.
The scopeguard approach comes from the following articles:
* [How to think about `async`/`await` in
Rust](http://cliffle.com/blog/async-inversion/)
* [Async Cancellation
I](https://blog.yoshuawuyts.com/async-cancellation-1/) (Reddit
[discussion](https://www.reddit.com/r/rust/comments/qrhg39/blog_post_async_cancellation/))
|
|
This helps reduce flakes where a test starts an HTTP server and makes a
request using fetch, then shuts down the server, then starting a new
test with a new server, but the connection pool still has a "not quite
closed yet" connection to the old server, and a new request to the new
server gets sent on the closed connection, which obviously errors out.
|
|
Right now, if one of the linters fails, the all other ones continue
running in the background. This fixes this by waiting until all linters
are done before settling.
|
|
|
|
Use fast ops for test registration. This speeds up `Deno.test` and
`t.step()` significantly (2x over Deno 1.37.0).
|
|
Previously could flake on the op sanitizer because the
`await makeTempFile()` promise could leak out of the test. Now we ensure
the request is fully handled before returning.
|
|
Speeds up `Deno.test` calls by a bit.
|
|
(#20641)
Builds on top of #20622 to fix #10854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`Array.from` has optional second argument. Calling `map` is not required
for this case.
|
|
|
|
fixes #20635
|
|
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
|
|
|
|
|
|
resourceForReadableStream (#20622)
We can go one level down in abstraction and avoid using the public
`ReadableStream` APIs.
This patch ~5% perf boost on small ReadableStream:
```
Running 10s test @ http://localhost:8080/
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 148.32us 108.95us 3.88ms 95.71%
Req/Sec 33.24k 2.68k 37.94k 73.76%
668188 requests in 10.10s, 77.74MB read
Requests/sec: 66162.91
Transfer/sec: 7.70MB
```
main:
```
Running 10s test @ http://localhost:8080/
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 150.23us 67.61us 4.39ms 94.80%
Req/Sec 31.81k 1.55k 35.56k 83.17%
639078 requests in 10.10s, 74.36MB read
Requests/sec: 63273.72
Transfer/sec: 7.36MB
```
|
|
|
