[tptacek]

Snif. My feels. Right in the feels! Try as hard as you like though, you cannot make comments like these unproductive!

* You cannot "explore the filesystem". The "files" are really just bookmarks in case you want to switch between different C-like programs to deal with a level. I hate the UI more than you do, but suggestions very welcome.

* You mean "compile" as in, the debugger command? What would you like it to print? Before we split the source editor off into its own page (it used to live in a tab, and it just didn't work), the CLI was an important way to interact with the compiler. Now the command is vestigial. I suppose I could just make it print out the bytecode instructions from the compiler.

* What does "inspect the compiler" mean?

* How can I surface the documentation that explains the relationship between the compiler and the system so that it is more apparent that it exists? It's clear you didn't see it.

* Hate the web interface? You're in luck! https://starfighter.readme.io/ --- skip to "Microcontroller API reference".

* I have a hit list of improvements to the command line, but if you have more suggestions, I'd be happy for them.

* The "latency" you're seeing when you single-step programs is... the network? The clientside UI code?

Just a little, is the answer to the last question.

[gue5t]

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.

[tptacek]

If it keeps you generating feedback like that, be as mean as you like! I need stuff like this.

The source file thing is definitely strange. I could just lose it entirely; save your own files! That's how the termbox client works. It made slightly more sense when it was driven from the CLI.

"compile" in the debugger is vestigial, but if we think it makes sense to have it do something useful, let's have it do something useful. I'll have it do what the compile button does, and also print a summary of the generated program. It'll be immediately clear what it does. I'll make "load" do something sensible too.

I think more people want me to have a command line than want a completely streamlined interface, but I think I have some work to do on making the command line work better.

There is utility, later on, in looking more carefully at the individual steps of getting a program to run, but there is not much utility to it in earlier levels. I can hide those commands earlier; I didn't because that'd be kind of a tell. Earlier on this year, I wanted this interface to capture more of the annoyance of figuring out a realistically complicated target (rather than it being immediately clear what your objective was), but I'm moving away from that now.

It's definitely very tricky to write documentation for this that makes sense to reversers or embedded devs and that works for the people who've never done any of this kind of stuff. Maybe I shouldn't be trying to accomplish both things in one set of documents!

My #1 takeaway from your original comment: I need to do an audit of all the command line commands and have them all be discoverable by running them and seeing what happens. That is definitely not the case right now, and it's a very easy gap for me to close.

There shouldn't really be anything you can do in the web interface that you can't do in the API.