Stockfighter's Jailbreak CTF trainer is live

Enter on blank lines: easy enough, will do.

Putting the compiler in the debugger was how it used to work. Everyone hated it. Also: it's using Ace, which really grinds Chrome. I can easily add a pure textarea tab that will let you edit code, if you _really_ want it.

To run a C program, do one of two things:

* Compile it in the source editor, which will generate a blob of compiler output (which is deliberately not documented) that the browser will cache.

* Use the "flash" command to write it to SPI flash.

* Use the "vmload" command to send a SPI message to the AVR to reload the program from the SPI flash.

* Use the "vmexec" command to send a SPI message to the AVR to execute the program.

OR

* Compile it in the source editor

* Type "run", which does all the rest of those things.

I like Microcorruption's UI, too. I gave this one more to do. I agree: it's not there yet! Working on it. How elaborate do you want the web-based debugger built on this API to be? :)

(I'm serious: thanks for the feedback. This section of the thread is the stuff I was hoping to get).

You all have great timing. It's very likely that something will melt down soon, but I'm not going to notice, because I'll be in a chair getting my arm inked up. It's going to be a nine-fives kind of day!

Mean feedback about the UI, especially if accompanied by an even meaner summary of what you'd rather the UI does instead, is most welcome.

Later

(Erin's Calcifer tattoo is taking longer than expected, so if you want to wait like another 15 minutes before doing whatever unforeseen sequence of things in the UI that will hard-panic all the servers, your timing will be perfect).

Yes, which is why I focused on the the last little bit which I think wasn't really productive at all. It expressed frustration, which I understand, but in an antagonistic and condescending way which doesn't add to the point at all. It's easy for a tone like that to poison a thread.

I'm glad, as one of the people it was directed towards, that you can take it positively.

I want typing "load foo.cg" and hitting enter in the debugger to print _something_, almost anything. Ideally it would print different things depending on whether foo.cg actually exists and is a valid file to try to load or not. Just some sort of feedback indicating that the command actually did something would be great.

I like the different load/flash/vmload/vmexec commands, I've certainly needed to stop at points in the middle to inspect the debugger state.

Sorry for being rude.

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.