Repository navigation
feat(cse-machine): support breakpoint() as a breakpoint-navigation marker - #256
Conversation
…rker Registers breakpoint() as a no-op MISC builtin (chapters 1-4) and, in the CSE machine's step generator, detects a zero-arg call resolving (by identity, so aliases like `bp = breakpoint; bp()` are caught too) to that builtin, recording the step where it sits on top of the control into context.runtime.breakpointSteps. Threads that array out through collectSnapshots and PyCseEvaluator's sendSnapshots call so the host's breakpoint-navigation controls can consume it (paired with a protocol change in source-academy/plugins to carry it across the Conductor __cse channel). Mirrors PR source-academy#197's substitution-stepper support of the same feature (issue source-academy#189). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
package.json/yarn.lock were pointing @sourceacademy/common-cse-machine and @sourceacademy/runner-cse-machine at a local yarn-link portal (/home/vakshay/plugins) for development. That doesn't resolve for anyone else or CI, and runner-cse-machine can't be pinned to a plugins branch via Yarn's git+workspace protocol either — like web-cse-machine, it depends on the sibling common-cse-machine workspace via workspace:*, and Yarn's single-workspace git fetch doesn't build sibling workspaces first, so the prepack/rollup step can't find its dist. Reverting to the original published semver ranges so this PR's dependency diff is clean. This PR depends on source-academy/plugins#55 (adds breakpointSteps to the CSE snapshot protocol) publishing a new npm version before it will typecheck/build against real installs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Code Review
This pull request implements support for Python's breakpoint() builtin in the CSE machine interpreter. It registers the breakpoint builtin, detects its invocation during interpretation to record step indices, ensures that these steps are properly tracked and filtered, and resets the breakpoint state between runs. Comprehensive unit tests are also added. The reviewer feedback highlights three improvement opportunities: resetting other per-run state properties (changepointSteps and break) to prevent state leakage, adding a defensive check to filter out negative step indices, and applying the @Validate decorator to the new breakpoint builtin method.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…tSteps @sourceacademy/common-cse-machine ^0.2.0 -> ^0.3.0 and @sourceacademy/runner-cse-machine ^1.0.0 -> ^3.0.0, now that source-academy/plugins#55 has published (bumping the same two packages, plus web-cse-machine, to carry breakpointSteps over the CSE snapshot channel). Unblocks this PR: tsc --noEmit passes against the real published CseMachinePlugin.sendSnapshots(snapshots, breakpointSteps?) signature. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Also reset context.runtime.changepointSteps and .break in evaluateChunk, alongside breakpointSteps -- same per-run leaking-state class, since this.context persists across evaluateChunk calls but only breakpointSteps was being reset. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
One limitation worth flagging: the breakpoint-navigation detection here only recognizes a zero-argument call to Filed as a separate issue rather than fixing here, since properly closing this (making |
The root workspace's dependency block had @sourceacademy/conductor listed after @sourceacademy/runner-cse-machine instead of before it alphabetically -- yarn.lock wasn't re-normalized when common-cse-machine/runner-cse-machine were bumped. This alone was enough to fail `yarn install --frozen-lockfile` under Yarn's hardened mode (auto-enabled for fork PRs), which treats any lockfile diff, including pure reordering, as forbidden. Regenerated via a plain `yarn install`; no dependency versions changed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
martin-henz
left a comment
There was a problem hiding this comment.
Looks good. Will play for detailed feedback.
Summary
breakpoint()as a no-op MISC builtin (src/stdlib/misc.ts), so it resolves and evaluates in chapters 1-4 (previously only registered for the substitution stepper, insrc/conductor/stepper/builtins.ts).generateCSEMachineStateStream,src/engines/cse/interpreter.ts), detects a zero-arg call whose resolved callee (by identity, not source text — so aliases likebp = breakpoint; bp()are caught too) is thebreakpointbuiltin, and records the step where it sits on top of the control intocontext.runtime.breakpointSteps.breakpointStepsper run inPyCseEvaluator.evaluateChunk(the underlyingContextis long-lived across multiple "Run" clicks in a session) and threads the array out throughcollectSnapshots→PyCseEvaluator'ssendSnapshots(snapshots, breakpointSteps)call.@sourceacademy/common-cse-machineto^0.3.0and@sourceacademy/runner-cse-machineto^3.0.0, now that source-academy/plugins#55 has published.Why
Mirrors #197, which did this for the substitution stepper (chapters 1-2, issue #188). This closes the CSE-machine half: #189 "CSE Machine: breakpoint() enables big steps" — pressing the double-chevron in the CSE Machine tab should jump directly to the step(s) where
breakpoint()sits on top of the control.Companion to a frontend PR (source-academy/frontend#4083) that wires the resulting
breakpointStepsinto the existing double-chevron navigation UI.Test plan
src/tests/PyCseMachinePlugin.test.ts(breakpoint at top level, in a function, in a loop, aliased, expression-position no-op, no cross-run leakage) — all passingtsc --noEmitclean against the real published@sourceacademy/runner-cse-machine@3.0.0breakpoint()in the Playground's CSE Machine tab, confirm the double-chevron buttons jump to the breakpoint steps