torbscript/language
Watch
1
0
Fork
You've already forked language
 0
Code Issues 145 Pull requests 6 Projects Releases 16 Packages 3 Wiki Activity Actions 11

debugger: hold and release the workers, the stop-the-world handshake (step 2b of #41) #719

New issue
Closed
opened 2026-11-12 17:40:42 +00:00 by orion · 13 comments
orion commented 2026-11-12 17:40:42 +00:00
Collaborator

Context

Step 2b of #41 (epic). #586 (PR #603) moved a debugged thread's position onto its interpreter (DebugThread on Registers); a debugged run still keeps every task on one worker (workersFor in compiler/src/vm/interpret.trb returns no extra interpreters when main.debugger.isSome()). What is left of step 2 is letting a debugged program use several workers: the runtime must hold and release the other workers while one thread is stopped, and each worker needs an interpreter with a thread record under the debugger.

Source

DEBUGGER.md sections 14 and 20

Goal

Under the debugger a program may run on more than one worker: when any thread stops, every other worker is held until the session resumes, and a stop reports the stopped thread only. A debugged run that does not ask for more than one worker behaves exactly as today.

Design (decided by the loop, see the comments)

  • Workers. A debugged run keeps one worker by default; it uses more only where the program asks for them explicitly (manifest tasks { workers } or TORB_WORKERS). So no existing session changes, and a run stays deterministic unless the program opted in. With more than one worker, workersFor no longer returns early for main.debugger.isSome(): every ring worker after the first and every thread of the blocking pool gets Registers with a DebugThread, as for a plain run. Runs that run scripts, confinesTasks programs and coverage runs keep their early return.
  • Kernel hold and release (runtime/task.c, two new KernelOperations beside DebugTasks, with the C side in runtime/machine.c): DebugHold is called by the thread that stops. It sets the hold, then waits until every other program thread is quiescent: parked at a statement, idle in its scheduler (asleep on its queue), or inside a native call that blocks (readLine, a sleep, a wait on IO, an offload body in a native call). DebugRelease clears the hold and wakes the parked threads. Only one thread holds the world at a time (a lock in the kernel); a thread that reaches a stop while another holds simply parks.
  • Parking. A held thread parks at its next statement, before it evaluates breakpoints or steps (so a breakpoint it reaches while another thread is stopped is reported at the next stop after the resume, never lost and never a second stop). A thread that wakes from idle or from a blocking native call while the hold is on parks before it runs program code. The check is one atomic read per statement of a debugged run only; the non-debugged loop is untouched.
  • Shared Debugger state is written only while the world is held. stop already runs with every other worker parked. poll (reading the channel every pollInterval statements) reads the channel under the debugger lock; if it has something to apply (pause, setBreakpoints, setExceptionBreakpoints) it brackets that with hold and release, so no worker reads the breakpoint table while it is rebuilt.
  • Stepping. next, stepIn, stepOut release every worker, but the step is ended only by the thread that began it (Debugger records which); other workers run free and may hit breakpoints or a pause. continue releases all. This keeps section 14's "act on the position where the program stopped, whichever threadId the client names".
  • Threads and frames. threads is unchanged (answered at once from DebugTasks). The stack of a thread whose task is parked at a statement on another worker is read from that worker's DebugThread (its runningTask is the task's block) and that worker's registers, not from the task block; a task that waits or has not started keeps today's path. stopped still carries the thread that stopped and allThreadsStopped: true.
  • Sessions and workers. A session directory may carry its manifest (tests/debug/<name>/project.trb with tasks { workers: 2 }) so the session starts a multi-worker run; if torb debug does not take the manifest's pool, tools/debug.sh passes TORB_WORKERS from an optional <name>.workers file instead (the implementer checks which one holds and records it).

Requirements

  • R1. When a thread of a debugged run stops, the system shall hold every other worker, including the blocking pool's threads, before it answers the first request, and keep them held until continue, next, stepIn or stepOut releases them.
  • R2. While the world is held, the system shall not run a statement or change a task's state on any other worker, so threads, stackTrace, scopes and variables read a program that stands.
  • R3. Where two threads reach a stop at about the same time, the system shall stop one and park the other at its statement, and shall report the parked thread's stop at the next stop after the resume.
  • R4. Where a debugged run asks for one worker, the system shall run exactly as before: no extra interpreter, no hold traffic beyond a hold on an empty set of other workers.
  • R5. Without the debugger nothing changes: the non-debugged loop reads no new field and workersFor takes the same path as today.

Acceptance criteria

  • runtime/tests/pool_test.c (runtime unit test, tier A) has a test with at least three workers: a thread calls the hold while the others run a statement counter; after the hold returns the counters stand (read twice, 50 ms apart, equal), after the release they advance; a worker asleep in its queue and a thread in a blocking native call do not stop the hold from returning, and neither runs program code until the release
  • A new session tests/debug/workers.dap (program tests/debug/workers/main.trb, a manifest or .workers file giving it 2 or more workers) with two tasks that really run on two workers (ordered by channel handshakes, not sleeps): a breakpoint stops one task; threads and stackTrace of the other task show its frame at the statement where it is parked; an evaluate of a loop counter of the parked task answers the same value twice, with other requests between the two, and its work (a print after the breakpoint's line, the second task's completion) appears in the output only after continue; after continue the program runs to its end with the right output and exit code 0
  • workers.expected is byte-identical across 50 consecutive local runs of sh tools/debug.sh --filter workers of the CI-built torb (the implementer states the count in the PR; the forge CI runs it on every lane)
  • Every other session of tests/debug/ produces a byte-identical .expected: no .dap or .expected file changes (the default stays one worker)
  • A stop in a task on a worker other than the main thread reports threadId of that task and walks the frames of that worker's DebugThread (a unit test or the session: stackTrace of the stopped task shows its own frames, not main's)
  • A breakpoint hit by a second worker while the first is stopped is not lost: after continue the session stops at it with the right threadId (in workers.dap, order forced by a channel)
  • sh tools/gates.sh a green in forge CI; no torb run of a program without the debugger changes (the existing tools/debug-cost.sh numbers do not move beyond noise, read from the tier B job when it runs)
  • DEBUGGER.md section 14: the decision text and the table row say a debugged program runs on one worker by default and on the workers it asks for, and describe the hold; section 20: the pool item is marked done (both steps); docs/ROADMAP.md / the epic's step 2b updated if they list it; skills/ regenerated if docs under the skill source change

Seed

Settled: no seed impact. Two new KernelOperation cases are ordinary compiler code (as DebugTasks in #403 was) compiled by the seed; no new syntax, no std name the compiler looks up by string, no driver flag, no new native. The runtime gets two kernel operations and a hold in task.c; the seed ships the runtime of its commit, so the seed need not know them. No seed refresh is needed, and the loop touches no seed.

Size

Settled: one PR, two Conventional Commits.

  1. feat(runtime): hold and release the workers for a debugger - the kernel operations DebugHold/DebugRelease (compiler/src/backend/bytecode/format.trb, runtime/machine.c), the hold in runtime/task.c and its test in runtime/tests/pool_test.c; nothing in the VM calls it yet.
  2. feat(vm): debug a program on more than one worker - workersFor, the park at a statement, the handshake in reachStatement/poll, frames of a parked thread, the session tests/debug/workers, and the DEBUGGER.md update.

If the second commit proves too large for one review, the first commit lands alone as its own PR and the epic's step 2b gets a checklist (2b-i hold in the kernel, 2b-ii the VM handshake and the session); the loop then files 2b-ii just in time.

Dependencies

Builds on #586 (merged, PR #603) and #403 (merged). Part of #41.

## Context Step 2b of #41 (epic). #586 (PR #603) moved a debugged thread's position onto its interpreter (`DebugThread` on `Registers`); a debugged run still keeps every task on one worker (`workersFor` in compiler/src/vm/interpret.trb returns no extra interpreters when `main.debugger.isSome()`). What is left of step 2 is letting a debugged program use several workers: the runtime must hold and release the other workers while one thread is stopped, and each worker needs an interpreter with a thread record under the debugger. ## Source [DEBUGGER.md sections 14 and 20](https://git.torb.dev/torbscript/language/src/branch/main/docs/design/DEBUGGER.md) ## Goal Under the debugger a program may run on more than one worker: when any thread stops, every other worker is held until the session resumes, and a stop reports the stopped thread only. A debugged run that does not ask for more than one worker behaves exactly as today. ## Design (decided by the loop, see the comments) - **Workers.** A debugged run keeps **one worker by default**; it uses more only where the program asks for them explicitly (manifest `tasks { workers }` or `TORB_WORKERS`). So no existing session changes, and a run stays deterministic unless the program opted in. With more than one worker, `workersFor` no longer returns early for `main.debugger.isSome()`: every ring worker after the first and every thread of the blocking pool gets `Registers` with a `DebugThread`, as for a plain run. Runs that run scripts, `confinesTasks` programs and coverage runs keep their early return. - **Kernel hold and release** (`runtime/task.c`, two new `KernelOperation`s beside `DebugTasks`, with the C side in `runtime/machine.c`): `DebugHold` is called by the thread that stops. It sets the hold, then waits until every other program thread is quiescent: parked at a statement, idle in its scheduler (asleep on its queue), or inside a native call that blocks (`readLine`, a sleep, a wait on IO, an `offload` body in a native call). `DebugRelease` clears the hold and wakes the parked threads. Only one thread holds the world at a time (a lock in the kernel); a thread that reaches a stop while another holds simply parks. - **Parking.** A held thread parks at its next `statement`, before it evaluates breakpoints or steps (so a breakpoint it reaches while another thread is stopped is reported at the next stop after the resume, never lost and never a second stop). A thread that wakes from idle or from a blocking native call while the hold is on parks before it runs program code. The check is one atomic read per statement of a debugged run only; the non-debugged loop is untouched. - **Shared `Debugger` state is written only while the world is held.** `stop` already runs with every other worker parked. `poll` (reading the channel every `pollInterval` statements) reads the channel under the debugger lock; if it has something to apply (`pause`, `setBreakpoints`, `setExceptionBreakpoints`) it brackets that with hold and release, so no worker reads the breakpoint table while it is rebuilt. - **Stepping.** `next`, `stepIn`, `stepOut` release every worker, but the step is ended only by the thread that began it (`Debugger` records which); other workers run free and may hit breakpoints or a pause. `continue` releases all. This keeps section 14's "act on the position where the program stopped, whichever `threadId` the client names". - **Threads and frames.** `threads` is unchanged (answered at once from `DebugTasks`). The stack of a thread whose task is parked at a statement on another worker is read from that worker's `DebugThread` (its `runningTask` is the task's block) and that worker's registers, not from the task block; a task that waits or has not started keeps today's path. `stopped` still carries the thread that stopped and `allThreadsStopped: true`. - **Sessions and workers.** A session directory may carry its manifest (`tests/debug/<name>/project.trb` with `tasks { workers: 2 }`) so the session starts a multi-worker run; if `torb debug` does not take the manifest's pool, `tools/debug.sh` passes `TORB_WORKERS` from an optional `<name>.workers` file instead (the implementer checks which one holds and records it). ## Requirements - R1. When a thread of a debugged run stops, the system shall hold every other worker, including the blocking pool's threads, before it answers the first request, and keep them held until `continue`, `next`, `stepIn` or `stepOut` releases them. - R2. While the world is held, the system shall not run a statement or change a task's state on any other worker, so `threads`, `stackTrace`, `scopes` and `variables` read a program that stands. - R3. Where two threads reach a stop at about the same time, the system shall stop one and park the other at its statement, and shall report the parked thread's stop at the next stop after the resume. - R4. Where a debugged run asks for one worker, the system shall run exactly as before: no extra interpreter, no hold traffic beyond a hold on an empty set of other workers. - R5. Without the debugger nothing changes: the non-debugged loop reads no new field and `workersFor` takes the same path as today. ## Acceptance criteria - [ ] `runtime/tests/pool_test.c` (runtime unit test, tier A) has a test with at least three workers: a thread calls the hold while the others run a statement counter; after the hold returns the counters stand (read twice, 50 ms apart, equal), after the release they advance; a worker asleep in its queue and a thread in a blocking native call do not stop the hold from returning, and neither runs program code until the release - [ ] A new session `tests/debug/workers.dap` (program `tests/debug/workers/main.trb`, a manifest or `.workers` file giving it 2 or more workers) with two tasks that really run on two workers (ordered by channel handshakes, not sleeps): a breakpoint stops one task; `threads` and `stackTrace` of the other task show its frame at the statement where it is parked; an `evaluate` of a loop counter of the parked task answers the same value twice, with other requests between the two, and its work (a `print` after the breakpoint's line, the second task's completion) appears in the output only after `continue`; after `continue` the program runs to its end with the right output and exit code 0 - [ ] `workers.expected` is byte-identical across 50 consecutive local runs of `sh tools/debug.sh --filter workers` of the CI-built `torb` (the implementer states the count in the PR; the forge CI runs it on every lane) - [ ] Every other session of `tests/debug/` produces a byte-identical `.expected`: no `.dap` or `.expected` file changes (the default stays one worker) - [ ] A stop in a task on a worker other than the main thread reports `threadId` of that task and walks the frames of that worker's `DebugThread` (a unit test or the session: `stackTrace` of the stopped task shows its own frames, not `main`'s) - [ ] A breakpoint hit by a second worker while the first is stopped is not lost: after `continue` the session stops at it with the right `threadId` (in `workers.dap`, order forced by a channel) - [ ] `sh tools/gates.sh a` green in forge CI; no `torb run` of a program without the debugger changes (the existing `tools/debug-cost.sh` numbers do not move beyond noise, read from the tier B job when it runs) - [ ] DEBUGGER.md section 14: the decision text and the table row say a debugged program runs on one worker by default and on the workers it asks for, and describe the hold; section 20: the pool item is marked done (both steps); `docs/ROADMAP.md` / the epic's step 2b updated if they list it; `skills/` regenerated if docs under the skill source change ## Seed Settled: no seed impact. Two new `KernelOperation` cases are ordinary compiler code (as `DebugTasks` in #403 was) compiled by the seed; no new syntax, no std name the compiler looks up by string, no driver flag, no new native. The runtime gets two kernel operations and a hold in `task.c`; the seed ships the runtime of its commit, so the seed need not know them. No seed refresh is needed, and the loop touches no seed. ## Size Settled: one PR, two Conventional Commits. 1. `feat(runtime): hold and release the workers for a debugger` - the kernel operations `DebugHold`/`DebugRelease` (`compiler/src/backend/bytecode/format.trb`, `runtime/machine.c`), the hold in `runtime/task.c` and its test in `runtime/tests/pool_test.c`; nothing in the VM calls it yet. 2. `feat(vm): debug a program on more than one worker` - `workersFor`, the park at a statement, the handshake in `reachStatement`/`poll`, frames of a parked thread, the session `tests/debug/workers`, and the DEBUGGER.md update. If the second commit proves too large for one review, the first commit lands alone as its own PR and the epic's step 2b gets a checklist (2b-i hold in the kernel, 2b-ii the VM handshake and the session); the loop then files 2b-ii just in time. ## Dependencies Builds on #586 (merged, PR #603) and #403 (merged). Part of #41.
orion commented 2026-11-12 17:40:50 +00:00
Author
Collaborator

[loop:torbscript] intake: in scope (DEBUGGER.md sections 14 and 20, step 2b of #41), no duplicate, no owner question, no seed impact expected. next: refine

[loop:torbscript] intake: in scope (DEBUGGER.md sections 14 and 20, step 2b of #41), no duplicate, no owner question, no seed impact expected. next: refine
orion commented 2026-11-12 17:40:50 +00:00
Author
Collaborator

[loop:torbscript] claim refine by session:loop-torbscript-20261112 until 2026-11-12T20:45:00Z

[loop:torbscript] claim refine by session:loop-torbscript-20261112 until 2026-11-12T20:45:00Z
orion commented 2026-11-12 17:42:52 +00:00
Author
Collaborator

[loop:torbscript] decided by the loop: (1) a debugged run keeps one worker by default and uses more only when the program asks (manifest tasks { workers } or TORB_WORKERS) - this leaves every existing tests/debug session byte-identical and the default run deterministic, which a multi-worker default would not; (2) the hold is a kernel operation pair in runtime/task.c (DebugHold/DebugRelease) with one holder at a time, workers park at their next statement before breakpoint/step evaluation, idle workers and threads in blocking native calls count as quiescent - so a stop never waits for a readLine and no breakpoint is lost; (3) shared Debugger state is written only while the world is held (poll brackets a channel request that changes state with hold/release); (4) a step is ended only by the thread that began it, other workers run free during it; (5) the stack of a task parked on another worker is read from that worker's DebugThread; (6) no seed impact: two new KernelOperation cases are ordinary compiler code, as DebugTasks was, and the runtime ships with the seed's commit; (7) size: one PR, two commits (runtime hold + C test, then VM handshake + session + docs), falling back to a 2b-i/2b-ii checklist on #41 if the second commit is too large. No owner question: all technical, none on the owner list.

[loop:torbscript] decided by the loop: (1) a debugged run keeps one worker by default and uses more only when the program asks (manifest `tasks { workers }` or `TORB_WORKERS`) - this leaves every existing `tests/debug` session byte-identical and the default run deterministic, which a multi-worker default would not; (2) the hold is a kernel operation pair in `runtime/task.c` (`DebugHold`/`DebugRelease`) with one holder at a time, workers park at their next `statement` before breakpoint/step evaluation, idle workers and threads in blocking native calls count as quiescent - so a stop never waits for a `readLine` and no breakpoint is lost; (3) shared `Debugger` state is written only while the world is held (poll brackets a channel request that changes state with hold/release); (4) a step is ended only by the thread that began it, other workers run free during it; (5) the stack of a task parked on another worker is read from that worker's `DebugThread`; (6) no seed impact: two new `KernelOperation` cases are ordinary compiler code, as `DebugTasks` was, and the runtime ships with the seed's commit; (7) size: one PR, two commits (runtime hold + C test, then VM handshake + session + docs), falling back to a 2b-i/2b-ii checklist on #41 if the second commit is too large. No owner question: all technical, none on the owner list.
orion commented 2026-11-12 17:42:53 +00:00
Author
Collaborator

[loop:torbscript] refine: body rewritten to the definition of ready (testable criteria, design points in DEBUGGER.md sections 14 and 20, seed: no impact, size: one PR in two commits), label ready set. next: implementation

[loop:torbscript] refine: body rewritten to the definition of ready (testable criteria, design points in DEBUGGER.md sections 14 and 20, seed: no impact, size: one PR in two commits), label `ready` set. next: implementation
orion commented 2026-11-12 17:53:18 +00:00
Author
Collaborator

[loop:torbscript] claim implementation by session:loop-torbscript-20261112 until 2026-11-12T23:50:00Z

[loop:torbscript] claim implementation by session:loop-torbscript-20261112 until 2026-11-12T23:50:00Z
orion commented 2026-11-12 18:00:14 +00:00
Author
Collaborator

Checkpoint. Done: runtime hold/park/quiet + kernel ops debug.hold/debug.release (91/92) + pool test, one commit d42ab40e. In flight: CI on PR #722. Branch loop/719-debug-worker-hold. Next: CI green, review; the VM half (workersFor, statement park, tests/debug/workers, DEBUGGER.md) stays open on this issue.

Checkpoint. Done: runtime hold/park/quiet + kernel ops debug.hold/debug.release (91/92) + pool test, one commit d42ab40e. In flight: CI on PR #722. Branch loop/719-debug-worker-hold. Next: CI green, review; the VM half (workersFor, statement park, tests/debug/workers, DEBUGGER.md) stays open on this issue.
orion commented 2026-11-12 18:45:45 +00:00
Author
Collaborator

[loop:torbscript] implementation: runtime half landed as PR #722 (#722): torb_debug_hold/release/park and the quiet bracket for blocking calls in runtime/task.c, kernel ops debug.hold (91) and debug.release (92), pool test. Split: the VM half (workersFor, the park at a statement, the handshake, tests/debug/workers, DEBUGGER.md) is not in it; the PR says Refs #719 so this issue stays open for it. CI at hand-off: commit messages, bootstrap (linux-x64) and release-sync green; tier A/B, same-C and playground still running, gates pending. next: review

[loop:torbscript] implementation: runtime half landed as PR #722 (https://git.torb.dev/torbscript/language/pulls/722): torb_debug_hold/release/park and the quiet bracket for blocking calls in runtime/task.c, kernel ops debug.hold (91) and debug.release (92), pool test. Split: the VM half (workersFor, the park at a statement, the handshake, tests/debug/workers, DEBUGGER.md) is not in it; the PR says Refs #719 so this issue stays open for it. CI at hand-off: commit messages, bootstrap (linux-x64) and release-sync green; tier A/B, same-C and playground still running, gates pending. next: review
orion commented 2026-11-12 23:57:42 +00:00
Author
Collaborator

[loop:torbscript] claim implementation by session:loop-torbscript-20261113 until 2026-11-13T05:55:00Z

[loop:torbscript] claim implementation by session:loop-torbscript-20261113 until 2026-11-13T05:55:00Z
orion commented 2026-11-13 00:54:27 +00:00
Author
Collaborator

[loop:torbscript] implementation: the VM half landed as PR #726 (#726), branch loop/719-debug-workers-vm, one commit 'feat(vm): debug a program on more than one worker' (workersFor, park at a statement, handshake, frames of a parked thread, tests/debug/workers, DEBUGGER.md). The worker ended after opening the PR; CI at hand-off: commit messages, touches, pdisc, bootstrap green, tier A, JS conformance, playground, gates still pending. The claim is released with this note. next: waiting (CI on PR #726; a CI fix gets a fresh worker)

[loop:torbscript] implementation: the VM half landed as PR #726 (https://git.torb.dev/torbscript/language/pulls/726), branch loop/719-debug-workers-vm, one commit 'feat(vm): debug a program on more than one worker' (workersFor, park at a statement, handshake, frames of a parked thread, tests/debug/workers, DEBUGGER.md). The worker ended after opening the PR; CI at hand-off: commit messages, touches, pdisc, bootstrap green, tier A, JS conformance, playground, gates still pending. The claim is released with this note. next: waiting (CI on PR #726; a CI fix gets a fresh worker)
orion commented 2026-11-13 01:26:53 +00:00
Author
Collaborator

[loop:torbscript] claim implement by session:loop-torbscript-20261113 until 2026-11-13T07:30:00Z

PR #726: tier A (linux-x64) is red on d6a9d391 (run 2631 job 5); a fix worker reads the failure and pushes a fix to loop/719-debug-workers-vm.

[loop:torbscript] claim implement by session:loop-torbscript-20261113 until 2026-11-13T07:30:00Z PR #726: tier A (linux-x64) is red on d6a9d391 (run 2631 job 5); a fix worker reads the failure and pushes a fix to loop/719-debug-workers-vm.
orion commented 2026-11-13 01:30:30 +00:00
Author
Collaborator

[loop:torbscript] implementation: PR #726 tier A (linux-x64) failed on one gate, tests/debug against .expected (torb debug) (14 passed, 1 failed): tests/debug/workers differed only in the two threads answers (request_seq 7 and 11), which listed one task more than workers.expected had - task 4 (id 5). That is not a bug in the VM half: the leader waits in fromFollower.next(), and ChannelSource.next() is the native task received(channel), a real task that waits, so by the rule of DEBUGGER.md section 14 (every task that waits is a thread) it is listed until the follower has offered. Every other line of the session (stop events, frames, ids, evaluates) matched. Fix: workers.expected now lists task 4 in those two answers and workers.dap says why (commit fix(vm): list the leader's pending next() as a thread in the workers session, 2 files). New head: ec5457d6. CI at the time of writing: run just started on ec5457d6, all jobs pending (the previous tier A took 35 min); the other checks of d6a9d391 that finished were green. Not run locally (gates run in forge CI only).

[loop:torbscript] implementation: PR #726 tier A (linux-x64) failed on one gate, `tests/debug against .expected (torb debug)` (14 passed, 1 failed): `tests/debug/workers` differed only in the two `threads` answers (request_seq 7 and 11), which listed one task more than `workers.expected` had - `task 4` (id 5). That is not a bug in the VM half: the leader waits in `fromFollower.next()`, and `ChannelSource.next()` is the native task `received(channel)`, a real task that waits, so by the rule of DEBUGGER.md section 14 (every task that waits is a thread) it is listed until the follower has offered. Every other line of the session (stop events, frames, ids, evaluates) matched. Fix: `workers.expected` now lists `task 4` in those two answers and `workers.dap` says why (commit `fix(vm): list the leader's pending next() as a thread in the workers session`, 2 files). New head: ec5457d6. CI at the time of writing: run just started on ec5457d6, all jobs pending (the previous tier A took 35 min); the other checks of d6a9d391 that finished were green. Not run locally (gates run in forge CI only).
orion commented 2026-11-13 01:30:30 +00:00
Author
Collaborator

[loop:torbscript] release implement: fix pushed (ec5457d6) for the red tier A; CI of the new head is pending, the next tick judges it

[loop:torbscript] release implement: fix pushed (ec5457d6) for the red tier A; CI of the new head is pending, the next tick judges it
argus closed this issue 2026-11-13 07:19:11 +00:00
orion commented 2026-11-13 07:19:53 +00:00
Author
Collaborator

Merged as PR #726 (head 7b0e7593, merged by argus). Post-merge state: no "After merge" section in the PR; the change is on main, but in no release. The repo builds images on x.y.z tags (release.yml, images.yml) and the manifests say 0.1.0 with no tag cut (docs/design/RELEASE.md line 58). Next step, not done in this run: a release-cut PR (version bump in project.trb, compiler/project.trb, editors/vscode/package.json and languageVersion in compiler/src/package/version.trb, reviewer argus), then tag the release commit. The release version and the plan for the untagged 0.1.0/0.2.0 line are still open in the release plan. Verification: the workers session tests/debug/workers.dap has not been run locally; CI on main decides.

Merged as PR #726 (head 7b0e7593, merged by argus). Post-merge state: no "After merge" section in the PR; the change is on main, but in no release. The repo builds images on x.y.z tags (release.yml, images.yml) and the manifests say 0.1.0 with no tag cut (docs/design/RELEASE.md line 58). Next step, not done in this run: a release-cut PR (version bump in project.trb, compiler/project.trb, editors/vscode/package.json and languageVersion in compiler/src/package/version.trb, reviewer argus), then tag the release commit. The release version and the plan for the untagged 0.1.0/0.2.0 line are still open in the release plan. Verification: the workers session tests/debug/workers.dap has not been run locally; CI on main decides.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
loop/779-std-transform-2d
loop/776-web-middleware-app
loop/125-cli-completions
loop/783-registry-commands-std-cli
loop/781-xxhash-lz4-frame
loop/763-tierb-probe
probe/763-tier-b
loop/705-fix-candidate
orion/456-tierb-probe
loop/164-measure2
loop/207-measure
loop/164-prototype
probe/207-count
loop/205-measure
loop/140-hide-staged
nightly-20261113
nightly-20261112
nightly-20261111
nightly-20261103
nightly-20261031
nightly-20261029
nightly-20261027
nightly-20261026
nightly-20261025
nightly-20261024
nightly-20261023
nightly-20261021
nightly-20261020
nightly-20261015
nightly-20261014
seeds
Labels
Clear labels   
loop
Backlog item of the project loop (Orion), see CONTRIBUTING

  
queue/failed
Ejected from the merge queue (conflict or red CI)

  
queue/queued
Approved, waiting in the merge queue

  
ready
Refined to the definition of ready

  
status/parked
Parked with a reason in the newest loop comment

No labels
loop
queue/failed
queue/queued
ready
status/parked
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
torbscript/language#719
No description provided.