It seems strange that there are a set of names associated with blobs of data (source code) but the tools for managing that name->blobs map (querying which names are mapped, removing a mapping from the map, etc.) are incomplete. The source code editor allows views and updates, but I don't see how I would do garbage collection, and one can't perform views or updates from the debugger, but is expected to refer to the names there (in the "compile" command, and possibly others?).

Also about the "compile" command in the debugger (which is what I meant), it's unclear what state is mutated when I type "compile level_1.cg" and hit enter--it claims to have compiled and loaded 361 bytes, but I don't see a location into which they were loaded (checking the memory tab shows 32 bytes that don't resemble a program binary... is there somewhere else I should be looking?). If I subsequently type "run", it claims "no valid compiled program loaded". Is the program that I compiled and which was reportedly loaded not valid? Or do the "compile" and "run" commands' output refer to different notions of "loaded"?

By inspecting the compiler, I mean seeing what it does and how. Is the compiler inside or outside the trusted codebase of the handheld trading thing? Is there a way to hand-craft bytecode?

I also don't really understand why "compile" would load anything into anything else. Maybe there's a more clear name for the command?

Or, if you can remove the entire command prompt in favor of a more streamlined read-edit-test workflow, that seems ideal in terms of intelligibility. I would suggest making the programmatical interface more prominent (present it as a first-class alternative to the Web one). Since the idea of the site seems to be demonstrating developer ability, I expect many users will be put off at the notion of using a Web UI to do significant amounts of programming; even JS coders don't live in the one-line REPL of a browser inspector.

How do I get to those docs? I browsed the list on the left of https://www.stockfighter.io/trainer/dox but didn't see anything that explained where programs are stored after compilation. The "Command Reference" mentions compile, but the relationship between compile/run/flash/vmload/vmexec isn't clearly described; is "run" simply a convenience wrapper around the others (excluding compile)? What does the "vm" prefix imply? Why does compile take an argument, but the rest don't? Is there utility in, say, compiling and flashing, but not vmloading, a program (e.g. cache invalidation if we can flash underneath a different running program)? Or is this needless flexibility?

I originally skipped the guided tour, figuring that since I'm familiar with machine-level debugging and AVR in particular it would be a waste of time, but now see that it explains some of the expected workflow, though it's mixed with explanations of basic architecture concepts.