@coderook/cli 0.19.0 → 0.20.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"name": "coderook",
|
|
3
3
|
"displayName": "CodeRook",
|
|
4
4
|
"description": "Save, browse and restore whole-snapshot versions of a project on CodeRook, from Claude Code.",
|
|
5
|
-
"version": "0.
|
|
5
|
+
"version": "0.20.0",
|
|
6
6
|
"author": {
|
|
7
7
|
"name": "ACCA Gaming Productions",
|
|
8
8
|
"url": "https://coderook.com"
|
|
@@ -37,7 +37,38 @@ exports.describePlan = describePlan;
|
|
|
37
37
|
* session. Naming them here means the plan can be inspected before a byte
|
|
38
38
|
* moves.
|
|
39
39
|
*/
|
|
40
|
-
|
|
40
|
+
/*
|
|
41
|
+
Below this a file travels with others in one request rather than alone.
|
|
42
|
+
|
|
43
|
+
Measured rather than guessed, twice. The first number was sixty-four
|
|
44
|
+
kilobytes, taken from a source folder where ninety-six percent of files were
|
|
45
|
+
under it. A four and a half gigabyte game then showed the opposite shape:
|
|
46
|
+
eight hundred files of three hundred kilobytes per section, each just above
|
|
47
|
+
that line and so each paying its own round trip.
|
|
48
|
+
|
|
49
|
+
What the game measured is the reason for the number. Every request costs
|
|
50
|
+
about six hundred and thirty milliseconds before any bytes move, and the
|
|
51
|
+
lane carries roughly 0.79 MB/s. So a three hundred kilobyte file spends
|
|
52
|
+
sixty percent of its time on overhead and a seven megabyte file spends
|
|
53
|
+
seven. The line belongs where the overhead stops dominating, which is a few
|
|
54
|
+
megabytes and not a few kilobytes.
|
|
55
|
+
|
|
56
|
+
Four megabytes was the first attempt and it overshot. Measured on the same
|
|
57
|
+
game twice: four hundred kilobyte files went from 1.80 to 3.24 MB/s when
|
|
58
|
+
batched, while 1.3 megabyte files went from 4.43 down to 3.88 — because
|
|
59
|
+
three concurrent batches move less than six concurrent requests once a file
|
|
60
|
+
is large enough that transfer, not overhead, dominates. The crossover is
|
|
61
|
+
around a megabyte.
|
|
62
|
+
|
|
63
|
+
It lives here, and the uploader imports it, because for a while it did not:
|
|
64
|
+
the uploader had measured its way to a megabyte while this file still said
|
|
65
|
+
sixty-four kilobytes, and sections were therefore planned by one definition
|
|
66
|
+
of "small" and then sent by another. Nothing broke, which is why it lasted —
|
|
67
|
+
the planner simply grouped files it called ordinary and the uploader batched
|
|
68
|
+
them anyway, and a second filter downstream existed to paper over the
|
|
69
|
+
disagreement.
|
|
70
|
+
*/
|
|
71
|
+
exports.PACKABLE_LIMIT = 1024 * 1024;
|
|
41
72
|
exports.CHUNK_THRESHOLD = 16 * 1024 * 1024;
|
|
42
73
|
exports.DIRECT_LIMIT = 95 * 1024 * 1024;
|
|
43
74
|
function bandOf(size) {
|
|
@@ -42,29 +42,12 @@ const CHUNK_THRESHOLD = 16 * 1024 * 1024;
|
|
|
42
42
|
*/
|
|
43
43
|
const UPLOAD_LANES = 6;
|
|
44
44
|
/*
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
A four and a half gigabyte game then showed the opposite shape: eight
|
|
50
|
-
hundred files of three hundred kilobytes per section, each just above that
|
|
51
|
-
line and so each paying its own round trip.
|
|
52
|
-
|
|
53
|
-
What the game measured is the reason for the number. Every request costs
|
|
54
|
-
about six hundred and thirty milliseconds before any bytes move, and the
|
|
55
|
-
lane carries roughly 0.79 MB/s. So a three hundred kilobyte file spends
|
|
56
|
-
sixty percent of its time on overhead and a seven megabyte file spends
|
|
57
|
-
seven. The line belongs where the overhead stops dominating, which is a few
|
|
58
|
-
megabytes and not a few kilobytes.
|
|
59
|
-
|
|
60
|
-
Four megabytes was the first attempt and it overshot. Measured on the same
|
|
61
|
-
game twice: four hundred kilobyte files went from 1.80 to 3.24 MB/s when
|
|
62
|
-
batched, while 1.3 megabyte files went from 4.43 down to 3.88 — because
|
|
63
|
-
three concurrent batches move less than six concurrent requests once a file
|
|
64
|
-
is large enough that transfer, not overhead, dominates. The crossover is
|
|
65
|
-
around a megabyte.
|
|
45
|
+
What counts as small enough to travel with others, defined once in
|
|
46
|
+
staging.ts and imported here. The planner groups sections by the same line
|
|
47
|
+
the sender batches on, which for a while they did not — see the note beside
|
|
48
|
+
PACKABLE_LIMIT for what that cost.
|
|
66
49
|
*/
|
|
67
|
-
const BATCH_FILE_LIMIT =
|
|
50
|
+
const BATCH_FILE_LIMIT = staging_js_1.PACKABLE_LIMIT;
|
|
68
51
|
/** How much one batch may carry, and how many objects it may name. */
|
|
69
52
|
const BATCH_BYTES = 24 * 1024 * 1024;
|
|
70
53
|
const BATCH_COUNT = 256;
|