You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, thank you so much for creating and maintaining goboscript! It has been an absolute game-changer for my productivity and workflow.
I am currently setting up an automated build, unit test, and performance benchmarking pipeline in VSCode using goboscript-mcp (tw start -l) and VSCode build tasks. My setup pipes logger outputs into the terminal and automatically terminates when it reads a custom exit marker ([PROCESS_EXIT]).
Here is my current proof-of-concept setup:
main.gs
costumes "blank.svg";
onflag {
log "Hello World from goboscript!";
// Broadcast the exit signal right before stopping
log "[PROCESS_EXIT]";
stop_all();
Questions on Optimal Build & Test Workflow
While this setup works well for standard console logs, I'm looking to refine the optimal cycle for running automated unit and performance tests:
CPU Throttling for Perf Tests: Is there a recommended way to emulate mid-tier mobile CPU performance during automated tw start -l test runs (e.g., via Chrome DevTools Protocol flags or launch options in the background)?
Timing & Benchmark Metrics: If hardware CPU throttling isn't directly scriptable through the CLI launcher, would scaling/dividing measured timing deltas (using timer or days_since_2000) serve as a reasonable proxy for target hardware performance, or is there a preferred pattern used in the community
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
First off, thank you so much for creating and maintaining goboscript! It has been an absolute game-changer for my productivity and workflow.
I am currently setting up an automated build, unit test, and performance benchmarking pipeline in VSCode using goboscript-mcp (tw start -l) and VSCode build tasks. My setup pipes logger outputs into the terminal and automatically terminates when it reads a custom exit marker ([PROCESS_EXIT]).
Here is my current proof-of-concept setup:
main.gs
costumes "blank.svg";
onflag {
log "Hello World from goboscript!";
}
tasks.json
{
"label": "Build & Run (MCP)",
"type": "shell",
"command": "tw start -l | sed '/\[PROCESS_EXIT\]/q'",
"dependsOn": "2. Load into TurboWarp",
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"reveal": "always",
"focus": true,
"clear": true
}
}
Questions on Optimal Build & Test Workflow
While this setup works well for standard console logs, I'm looking to refine the optimal cycle for running automated unit and performance tests:
CPU Throttling for Perf Tests: Is there a recommended way to emulate mid-tier mobile CPU performance during automated tw start -l test runs (e.g., via Chrome DevTools Protocol flags or launch options in the background)?
Timing & Benchmark Metrics: If hardware CPU throttling isn't directly scriptable through the CLI launcher, would scaling/dividing measured timing deltas (using timer or days_since_2000) serve as a reasonable proxy for target hardware performance, or is there a preferred pattern used in the community
My old tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "Run Goboscript Build Script",
"type": "shell",
"command": "python macro_processor.py pre && goboscript build && python macro_processor.py post && "C:\Progra~1\WindowsApps\45747ThomasWeber.TurboWarpDesktop_1.16.0.0_x64__dx91esefr5w5e\app\TurboWarp.exe" ${workspaceFolderBasename}.sb3",
"args": [],
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": []
},
{
"label": "Force Restore Macros",
"type": "shell",
"command": "python macro_processor.py post",
"problemMatcher": []
},
{
"type": "goboscript-build",
"problemMatcher": [],
"label": "goboscript: goboscript-build"
}
]
}
All reactions