Yoshiya Hinosawa
199a8ca4c5
fix(ext/node/net): emit error
before close
when connection is refused ( #24656 )
2024-07-24 20:33:45 +09:00
Divy Srivastava
2549e5154c
perf: optimize Buffer.from("base64") for forgiving-base64 conforming input ( #24346 )
2024-06-26 06:24:58 -07:00
Bartek Iwańczuk
345423cf76
refactor: Use virtul ops module ( #22175 )
...
Follow up to #22157 .
This leaves us with 4 usages of `ensureFastOps()` in `deno` itself.
There's also about 150 usages of `Deno.core.ops.<op_name>` left as well.
2024-01-29 22:02:26 +01:00
Bartek Iwańczuk
909986fa6e
refactor: migrate 'ext/node' extension to virtual ops module ( #22157 )
...
Follow up to https://github.com/denoland/deno/pull/22135
2024-01-29 14:58:08 +01:00
Bartek Iwańczuk
942fb5e038
chore: upgrade deno_core ( #22124 )
...
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
2024-01-26 14:04:07 -05:00
Bartek Iwańczuk
9951506506
fix(node): remove deprecation warnings ( #22120 )
...
Closes https://github.com/denoland/deno/issues/22116
2024-01-26 00:36:03 +01:00
Kenta Moriuchi
515a34b4de
refactor: use core.ensureFastOps()
( #21888 )
2024-01-10 15:37:25 -07:00
cions
881a62869d
fix: android support ( #19437 )
...
<!--
Before submitting a PR, please read https://deno.com/manual/contributing
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
2. Ensure there is a related issue and it is referenced in the PR text.
3. Ensure there are tests that cover the changes.
4. Ensure `cargo test` passes.
5. Ensure `./tools/format.js` passes without changing files.
6. Ensure `./tools/lint.js` passes.
7. Open as a draft PR if your work is still in progress. The CI won't
run
all steps, but you can add '[ci]' to a commit message to force it to.
8. If you would like to run the benchmarks on the CI, add the 'ci-bench'
label.
-->
---------
Signed-off-by: Matt Mastracci <matthew@mastracci.com>
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
2024-01-10 06:04:14 -07:00
Kenta Moriuchi
e7e25db24f
chore: update deno_lint for CI ( #21802 )
2024-01-05 15:03:06 +00:00
Kenta Moriuchi
b2cd254c35
fix: strict type check for cross realms ( #21669 )
...
Deno v1.39 introduces `vm.runInNewContext`. This may cause problems when
using `Object.prototype.isPrototypeOf` to check built-in types.
```js
import vm from "node:vm";
const err = new Error();
const crossErr = vm.runInNewContext(`new Error()`);
console.assert( !(crossErr instanceof Error) );
console.assert( Object.getPrototypeOf(err) !== Object.getPrototypeOf(crossErr) );
```
This PR changes to check using internal slots solves them.
---
current:
```
> import vm from "node:vm";
undefined
> vm.runInNewContext(`new Error("message")`)
Error {}
> vm.runInNewContext(`new Date("2018-12-10T02:26:59.002Z")`)
Date {}
```
this PR:
```
> import vm from "node:vm";
undefined
> vm.runInNewContext(`new Error("message")`)
Error: message
at <anonymous>:1:1
> vm.runInNewContext(`new Date("2018-12-10T02:26:59.002Z")`)
2018-12-10T02:26:59.002Z
```
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-01-04 09:42:38 +05:30
Divy Srivastava
ad65440092
fix(ext/node): UdpSocket ref and unref ( #21777 )
2024-01-04 08:51:39 +05:30
David Sherret
7e72f3af61
chore: update copyright to 2024 ( #21753 )
2024-01-01 19:58:21 +00:00
Bartek Iwańczuk
f85d65e066
chore: update deno_core to 0.240.0 ( #21726 )
2023-12-28 19:30:07 +00:00
Kenta Moriuchi
68241234fa
fix(console): inspect for {Set,Map}Iterator
and Weak{Set,Map}
( #21554 )
2023-12-19 15:05:49 +09:00
Bartek Iwańczuk
c1fc7b2cd5
refactor: pull 'core', 'internals', 'primordials' from ES module ( #21462 )
...
This commit refactors how we access "core", "internals" and
"primordials" objects coming from `deno_core`, in our internal JavaScript code.
Instead of capturing them from "globalThis.__bootstrap" namespace, we
import them from recently added "ext:core/mod.js" file.
2023-12-07 14:21:01 +01:00
Leo Kettmeir
32c041c8d7
Reland "fix(ext/console): fix inspecting iterators error. ( #20720 )" ( #21370 )
2023-11-28 16:07:48 +01:00
Bartek Iwańczuk
9b9ec44db7
Revert "fix(ext/console): fix inspecting iterators error. ( #20720 )" ( #21191 )
...
This reverts commit 0209f7b469
.
Reverting because it causes failures on `main`:
https://github.com/denoland/deno/pull/20720#issuecomment-1809166755
2023-11-13 22:16:23 +00:00
Chen Su
0209f7b469
fix(ext/console): fix inspecting iterators error. ( #20720 )
...
Fixes #19776 and #20676 .
2023-11-13 20:13:20 +01:00
Divy Srivastava
09204107d8
fix: implement node:tty ( #20892 )
...
Fixes #21012
Closes https://github.com/denoland/deno/issues/20855
Fixes https://github.com/denoland/deno/issues/20890
Fixes https://github.com/denoland/deno/issues/20611
Fixes https://github.com/denoland/deno/issues/20336
Fixes `create-svelte` from https://github.com/denoland/deno/issues/17248
Fixes more reports here:
- https://github.com/denoland/deno/issues/6529#issuecomment-1432690559
- https://github.com/denoland/deno/issues/6529#issuecomment-1522059006
- https://github.com/denoland/deno/issues/6529#issuecomment-1695803570
2023-10-30 15:53:08 +00:00
Divy Srivastava
ab3c9d41e4
fix(ext/node): implement uv.errname ( #20785 )
...
Fixes https://github.com/denoland/deno/issues/20617
2023-10-05 18:27:20 +00:00
Chen Su
507f24c474
fix(ext/node): fix TypeError in Buffer.from with base64url encoding. ( #20705 )
...
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 .
2023-09-27 07:54:19 -06:00
Bartek Iwańczuk
aaff69db3f
perf(node/net): optimize socket reads for 'npm:ws' package ( #20449 )
...
Fixes performance regression introduced by
https://github.com/denoland/deno/pull/20223 and
https://github.com/denoland/deno/pull/20314 . It's enough to have one
"shared" buffer per socket
and no locking mechanism is required.
2023-09-11 20:38:57 +02:00
Aapo Alasuutari
9d6584c16f
perf(ext/node): Optimise Buffer string operations ( #20158 )
...
Extracted from https://github.com/denoland/deno/pull/17815
Optimise Buffer's string operations, most significantly when dealing
with ASCII and UTF-16. Base64 and HEX encodings are affected to much
lesser degrees.
## Performance
### String length 15
With very small strings we're at break-even or sometimes even lose a tad
bit of performance from creating a `DataView` that ends up not paying
for itself.
**This PR:**
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string 1.15 µs/iter 871,388.6 (728.78 ns … 1.56 µs) 1.23 µs 1.56 µs 1.56 µs
Buffer.from base64 string 1.63 µs/iter 612,790.9 (1.31 µs … 1.96 µs) 1.77 µs 1.96 µs 1.96 µs
Buffer.from utf16 string 1.41 µs/iter 707,396.3 (915.24 ns … 1.93 µs) 1.61 µs 1.93 µs 1.93 µs
Buffer.from hex string 1.87 µs/iter 535,357.9 (1.56 µs … 2.19 µs) 2 µs 2.19 µs 2.19 µs
Buffer.toString ascii string 154.58 ns/iter 6,469,162.8 (149.69 ns … 198 ns) 154.51 ns 182.89 ns 191.91 ns
Buffer.toString base64 string 161.65 ns/iter 6,186,189.6 (150.91 ns … 181.15 ns) 165.18 ns 171.87 ns 174.94 ns
Buffer.toString utf16 string 292.74 ns/iter 3,415,959.8 (285.43 ns … 312.47 ns) 295.25 ns 310.47 ns 312.47 ns
Buffer.toString hex string 89.61 ns/iter 11,159,315.6 (81.09 ns … 123.77 ns) 91.09 ns 113.62 ns 119.28 ns
```
**Main:**
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string 1.26 µs/iter 794,875.8 (1.07 µs … 1.46 µs) 1.31 µs 1.46 µs 1.46 µs
Buffer.from base64 string 1.65 µs/iter 607,853.3 (1.38 µs … 2.01 µs) 1.69 µs 2.01 µs 2.01 µs
Buffer.from utf16 string 1.34 µs/iter 744,894.6 (1.09 µs … 1.55 µs) 1.45 µs 1.55 µs 1.55 µs
Buffer.from hex string 2.01 µs/iter 496,345.8 (1.54 µs … 2.6 µs) 2.26 µs 2.6 µs 2.6 µs
Buffer.toString ascii string 150.16 ns/iter 6,659,630.5 (144.99 ns … 166.68 ns) 152.4 ns 157.26 ns 159.14 ns
Buffer.toString base64 string 164.73 ns/iter 6,070,692.0 (158.77 ns … 185.63 ns) 168.48 ns 175.74 ns 176.68 ns
Buffer.toString utf16 string 150.61 ns/iter 6,639,864.0 (148.2 ns … 168.29 ns) 150.93 ns 157.21 ns 168.15 ns
Buffer.toString hex string 94.21 ns/iter 10,614,972.9 (86.21 ns … 98.75 ns) 95.43 ns 97.99 ns 98.21 ns
```
### String length 1500
With moderate lengths we already see great upsides for `Buffer.from()`
with ASCII and UTF-16.
**This PR:**
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string 5.79 µs/iter 172,562.6 (4.72 µs … 4.71 ms) 5.04 µs 10.3 µs 11.67 µs
Buffer.from base64 string 5.08 µs/iter 196,678.9 (4.97 µs … 5.76 µs) 5.08 µs 5.76 µs 5.76 µs
Buffer.from utf16 string 9.68 µs/iter 103,316.5 (7.14 µs … 3.44 ms) 10.32 µs 13.42 µs 15.21 µs
Buffer.from hex string 53.7 µs/iter 18,620.2 (49.37 µs … 2.2 ms) 54.74 µs 72.2 µs 81.07 µs
Buffer.toString ascii string 6.63 µs/iter 150,761.3 (5.59 µs … 1.11 ms) 6.08 µs 15.68 µs 24.77 µs
Buffer.toString base64 string 460.57 ns/iter 2,171,224.4 (448.33 ns … 511.73 ns) 465.05 ns 495.54 ns 511.73 ns
Buffer.toString utf16 string 6.52 µs/iter 153,287.0 (6.47 µs … 6.66 µs) 6.53 µs 6.66 µs 6.66 µs
Buffer.toString hex string 3.68 µs/iter 271,965.4 (3.64 µs … 3.82 µs) 3.68 µs 3.82 µs 3.82 µs
```
**Main:**
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string 11.46 µs/iter 87,298.1 (8.53 µs … 834.1 µs) 9.61 µs 83.31 µs 87.3 µs
Buffer.from base64 string 5.4 µs/iter 185,027.8 (5.07 µs … 7.49 µs) 5.44 µs 7.49 µs 7.49 µs
Buffer.from utf16 string 20.3 µs/iter 49,270.8 (13.55 µs … 649.11 µs) 18.8 µs 113.93 µs 125.17 µs
Buffer.from hex string 52.03 µs/iter 19,218.9 (48.74 µs … 2.59 ms) 52.84 µs 67.05 µs 73.56 µs
Buffer.toString ascii string 6.46 µs/iter 154,822.5 (6.32 µs … 6.69 µs) 6.52 µs 6.69 µs 6.69 µs
Buffer.toString base64 string 440.19 ns/iter 2,271,764.6 (427 ns … 490.77 ns) 444.74 ns 484.64 ns 490.77 ns
Buffer.toString utf16 string 6.89 µs/iter 145,106.7 (6.81 µs … 7.24 µs) 6.91 µs 7.24 µs 7.24 µs
Buffer.toString hex string 3.66 µs/iter 273,456.5 (3.6 µs … 4.02 µs) 3.64 µs 4.02 µs 4.02 µs
```
### String length 2^20
With massive lengths we the difference in ASCII and UTF-16 parsing
performance is enormous.
**This PR:**
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
-------------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string 4.1 ms/iter 243.7 (2.64 ms … 6.74 ms) 4.43 ms 6.26 ms 6.74 ms
Buffer.from base64 string 3.74 ms/iter 267.6 (2.91 ms … 4.92 ms) 3.96 ms 4.31 ms 4.92 ms
Buffer.from utf16 string 7.72 ms/iter 129.5 (5.91 ms … 11.03 ms) 7.97 ms 11.03 ms 11.03 ms
Buffer.from hex string 35.72 ms/iter 28.0 (34.71 ms … 38.42 ms) 35.93 ms 38.42 ms 38.42 ms
Buffer.toString ascii string 78.92 ms/iter 12.7 (42.72 ms … 94.13 ms) 91.64 ms 94.13 ms 94.13 ms
Buffer.toString base64 string 833.62 µs/iter 1,199.6 (638.05 µs … 5.97 ms) 826.86 µs 2.45 ms 2.48 ms
Buffer.toString utf16 string 79.35 ms/iter 12.6 (69.72 ms … 88.9 ms) 86.66 ms 88.9 ms 88.9 ms
Buffer.toString hex string 31.04 ms/iter 32.2 (4.3 ms … 46.9 ms) 37.21 ms 46.9 ms 46.9 ms
```
**Main:**
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
-------------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string 18.66 ms/iter 53.6 (15.61 ms … 23.26 ms) 20.62 ms 23.26 ms 23.26 ms
Buffer.from base64 string 4.7 ms/iter 212.9 (2.94 ms … 9.07 ms) 4.65 ms 9.06 ms 9.07 ms
Buffer.from utf16 string 33.49 ms/iter 29.9 (31.24 ms … 35.67 ms) 34.08 ms 35.67 ms 35.67 ms
Buffer.from hex string 39.38 ms/iter 25.4 (38.66 ms … 42.36 ms) 39.58 ms 42.36 ms 42.36 ms
Buffer.toString ascii string 77.68 ms/iter 12.9 (67.46 ms … 95.68 ms) 84.71 ms 95.68 ms 95.68 ms
Buffer.toString base64 string 825.53 µs/iter 1,211.3 (655.38 µs … 6.69 ms) 816.62 µs 3.07 ms 3.13 ms
Buffer.toString utf16 string 76.54 ms/iter 13.1 (66.9 ms … 85.26 ms) 83.63 ms 85.26 ms 85.26 ms
Buffer.toString hex string 38.56 ms/iter 25.9 (33.83 ms … 46.56 ms) 45.33 ms 46.56 ms 46.56 ms
```
2023-09-07 14:41:16 -06:00
David Sherret
3fc19dab47
feat: support import attributes ( #20342 )
2023-09-07 09:09:16 -04:00
Matt Mastracci
7adaf613bf
fix(ext/node): shared global buffer unlock correctness fix ( #20314 )
...
The fix for #20188 was not entirely correct -- we were unlocking the
global buffer incorrectly. This PR introduces a lock state that ensures
we only unlock a lock we have taken out.
2023-08-28 15:28:39 -06:00
Matt Mastracci
c37b9655b6
fix(ext/node): simultaneous reads can leak into each other ( #20223 )
...
Reported in #20188
This was caused by re-use of a global buffer `BUF` during simultaneous
async reads.
2023-08-22 14:45:10 +00:00
Divy Srivastava
33dc5d2622
fix(node): implement TLSSocket._start ( #20120 )
...
Closes https://github.com/denoland/deno/issues/19983
Closes https://github.com/denoland/deno/issues/18303
Closes https://github.com/denoland/deno/issues/16681
Closes https://github.com/denoland/deno/issues/19978
2023-08-11 11:57:41 +00:00
Divy Srivastava
51b3534b3d
fix(ext/node): check if resource can be used with write_vectored ( #19868 )
...
Fixes https://github.com/denoland/deno/issues/19766
Fixes https://github.com/denoland/deno/issues/19846
2023-07-18 23:34:26 +02:00
Divy Srivastava
e4870d84be
perf(ext/node): native vectored write for server streams ( #19752 )
...
```
# main
$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 106182.250000
Msg/sec: 110279.750000
^C
# this PR
$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 131632.250000
Msg/sec: 134754.250000
^C
```
2023-07-07 22:17:08 +05:30
Divy Srivastava
57fae55d82
perf(ext/node): optimize net streams ( #19678 )
...
~4.5x improvement in `npm:ws` echo benchmark:
```
$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 101083.750000
Msg/sec: 103606.000000
^C
$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 24906.750000
Msg/sec: 28478.000000
^C
```
2023-07-05 22:45:10 +05:30
Bartek Iwańczuk
01f0d03ae8
refactor: rename built-in node modules from ext:deno_node/ to node: ( #19680 )
...
Closes https://github.com/denoland/deno/issues/19510
2023-07-02 20:19:30 +02:00
Bartek Iwańczuk
f372688f22
fix: lint on main branch ( #19622 )
2023-06-27 17:35:19 +09:00
Kenta Moriuchi
e16b74d792
chore(ext/node): disable prefer-primordials on a per-file basis ( #19553 )
2023-06-27 15:18:22 +09:00
Martin Fischer
801b9ec62d
chore: fix typos ( #19572 )
2023-06-26 09:10:27 -04:00
VlkrS
ea97af312f
feat: Adaptations to support OpenBSD port ( #19153 )
2023-06-12 13:14:27 +03:00
Bartek Iwańczuk
a11681a9b0
refactor(node): use internal io and fs APIs ( #19267 )
2023-05-26 16:18:27 +02:00
Yoshiya Hinosawa
f520284081
refactor(ext/node): remove polyfills/_core.ts ( #18766 )
2023-04-20 13:24:28 +09:00
Bartek Iwańczuk
e5b2815b39
Reland "refactor: remove Deno[Deno.internal].nodeUnstable namespace" ( #18475 )
...
This reverts commit 357bcfcf79
.
2023-03-28 14:44:22 +02:00
Bartek Iwańczuk
357bcfcf79
Revert "refactor: remove Deno[Deno.internal].nodeUnstable namespace (… ( #18458 )
...
…#18449)"
This reverts commit d1a9c4cd7c
.
Appears this made CI very flaky on macOS, but I can't repeat it locally
yet
2023-03-27 14:25:17 +00:00
Bartek Iwańczuk
d1a9c4cd7c
refactor: remove Deno[Deno.internal].nodeUnstable namespace ( #18449 )
...
Since we can preserve ops in the snapshot these days, we no longer
need to have "Deno[Deno.internal].nodeUnstable" namespace.
Instead, various built-in Node.js modules can use appropriate APIs
directly.
2023-03-27 02:15:08 +02:00
Bartek Iwańczuk
72fe9bb470
refactor: rename InternalModuleLoader to ExtModuleLoader, use ext: scheme for snapshotted modules ( #18041 )
...
This commit renames "deno_core::InternalModuleLoader" to
"ExtModuleLoader" and changes the specifiers used by the
modules loaded from this loader to "ext:".
"internal:" scheme was really ambiguous and it's more characters than
"ext:", which should result in slightly smaller snapshot size.
Closes https://github.com/denoland/deno/issues/18020
2023-03-08 12:44:54 +01:00
Divy Srivastava
c9c782940e
chore(ext/node): cleanup empty internal_bindings ( #18032 )
2023-03-05 10:53:42 -04:00
Bartek Iwańczuk
b40086fd7d
refactor(core): include_js_files! 'dir' option doesn't change specifiers ( #18019 )
...
This commit changes "include_js_files!" macro from "deno_core"
in a way that "dir" option doesn't cause specifiers to be rewritten
to include it.
Example:
```
include_js_files! {
dir "js",
"hello.js",
}
```
The above definition required embedders to use:
`import ... from "internal:<ext_name>/js/hello.js"`.
But with this change, the "js" directory in which the files are stored
is an implementation detail, which for embedders results in:
`import ... from "internal:<ext_name>/hello.js"`.
The directory the files are stored in, is an implementation detail and
in some cases might result in a significant size difference for the
snapshot. As an example, in "deno_node" extension, we store the
source code in "polyfills" directory; which resulted in each specifier
to look like "internal:deno_node/polyfills/<module_name>", but with
this change it's "internal:deno_node/<module_name>".
Given that "deno_node" has over 100 files, many of them having
several import specifiers to the same extension, this change removes
10 characters from each import specifier.
2023-03-05 02:31:38 +00:00
Yoshiya Hinosawa
3187e4e909
fix(ext/node): util.types.isSharedArrayBuffer ( #17836 )
2023-02-26 11:23:53 +09:00
Divy Srivastava
0aeb8bc759
perf(ext/node): move winerror binding to rust ( #17792 )
...
16873 lines of JS removed from the snapshot.
2023-02-16 19:19:32 +05:30
Bartek Iwańczuk
d47147fb6a
feat(ext/node): embed std/node into the snapshot ( #17724 )
...
This commit moves "deno_std/node" in "ext/node" crate. The code is
transpiled and snapshotted during the build process.
During the first pass a minimal amount of work was done to create the
snapshot, a lot of code in "ext/node" depends on presence of "Deno"
global. This code will be gradually fixed in the follow up PRs to migrate
it to import relevant APIs from "internal:" modules.
Currently the code from snapshot is not used in any way, and all
Node/npm compatibility still uses code from
"https://deno.land/std/node " (or from the location specified by
"DENO_NODE_COMPAT_URL"). This will also be handled in a follow
up PRs.
---------
Co-authored-by: crowlkats <crowlkats@toaxl.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
2023-02-14 17:38:45 +01:00