[gue5t]

The user interface is appalling. Whoever designed this has managed to produce worse ergonomics than a single 1970s-style terminal, for essentially a similar set of tasks (editing text+binary files and piping data through commands).

I see some discussion of "files", but seem unable to list them or explore the filesystem. I don't know if this in-game filesystem is supposed to be on the "AVR" device or an imaginary "developer machine". Where do the outputs of running commands like "compile" go? Why can't I inspect the compiler? What actually comprises the state of the system I'm interacting with? If this is notionally to find good developers, why is the UI sandboxed inside a web browser, where building and using tools (which is what good developers and reverse engineers do) is incredibly painful?

Half the commands produce no output and make no visible change to any state, e.g. "load garbage". Almost all commands silently ignore extra parameters. There's no tab completion, no history search, commands don't even show up in the output log...

Links and commands seem to randomly be assigned to either always open in new tabs or load in the current tab of the browser, both in the "debugger" and help pages.

Moving through command history puts the cursor at the left hand side of the prompt. There's noticeable latency when single-stepping the program, which is just astounding.

Did nobody try to use this shit, even a little?

[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.

[archimag0]

- Can't have the compiler side by side with the debugger, even though there's plenty of room on the screen

- When the PC jumps, the highlighted instruction doesn't follow, leaving you lost when stepping through a program

- Can't hit enter on a blank line to repeat previous command

- No 'finish' debugger command?

- Seem to end up in random functions when stepping over simple instructions

- Am I supposed to type 'flash' or 'run' to execute my compiled program? Sometimes the one I just compiled gets executed, sometimes the one I compiled previously - how can we view what's being executed?

I really enjoyed microcorruption, and thought that UI was fine, but this feels like a step backwards.

[tptacek]

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).

[archimag0]

Thanks for replying - I just wanted to dive in and get stuck into the levels, but found the UI so confusing that I just gave up - particularly as someone with no AVR experience, and with the tutorial dying half way through.

The biggest pain point was figuring out what was executing. As I mentioned, I would be playing around in the compiler, hit compile and save, and then attempt to run it in the debugger. The 'run' command either seemed to have no effect, or would run a previously compiled program, not the one I'd just written. Even typing 'reset' didn't help.

The memory didn't seem to be updating in real time either, which made things even more confusing!

Running in Firefox if that makes a difference.

[nialo]

I haven't tried this, but https://github.com/ketchupsalt/debugger might be of interest to you.

More generally, it's not actually sandboxed inside a web browser, you can interact with system through REST-ish API as well. see https://starfighter.readme.io/docs/retrieve-device-status for some documentation on that. It's obviously pretty inconvenient to get a full debugger type experience that way, but I don't really see how they could make it less sandboxed, given the constraint that the authoritative copy of everything must run on their servers for security.

I do wish all the commands gave some sort of feedback, load in particular is super frustrating that way.

[gue5t]

This line seems like a bug to me (assigning the int 16 to a variable that should be of an enumerated type {I8, I16, I32, S, R}, though I don't know if Go has those):

https://github.com/ketchupsalt/debugger/blob/master/commandl...

[tptacek]

There are probably a zillion little bugs in that thing (I haven't used it in months) but if people really want it to work, I'm probably less than 4 concerted hours from making it workable.

[tptacek]

Which "load" command? What's the feedback you're looking for?

Did you write a C program, click the compile button, and now want to run it? Just type "run".

There's an in-game reason why we break out the flash/load/exec commands the way we do, but "run" does all the fiddly steps.

[nialo]

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.

[tptacek]

Oh.

Yep, like "compile", that command is vestigial (the source editor used to live in a tab, and, ironically, the file saving stuff made more sense that way, driven from commands on the CLI).

Yep, I can make "load" do that. Give me a few hours, though! It's an easy task, but I'm tethered through my iPhone right now.

[nialo]

I personally am in no rush for this, all my discretionary coding time is currently going to a work sample for an opportunity Starfighter found me at the moment.

[kbenson]

> Did nobody try to use this shit, even a little?

Isn't that moving a bit beyond useful or informative and helpful to a discussion to aggressive and antagonistic? Is this free game/tool/resource actually causing you that much agitation?

[tptacek]

There was a lot of useful stuff in that comment!

[kbenson]

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.