Improve debugger

[francisrstokes]

Improve debugger

[francisrstokes]

Yes I was thinking websockets. A nice web interface would be perfect and allow the VM to run without being tainted with mixed input from the debugger (reading stdin while debugging is essentially impossible since the last key in the buffer is always the 'step' key.

Fancy graphics is a plus, but I'm all about small incremental developments. So the first thing would just be to be able to display the current kind of debugger output in a web browser, to be able to take debug input and send it to back to the VM, and breakpoints.

[tetsuo]

So, if I am correct, this is an in-browser websockets implementation discussed in here. Perhaps, something like node-inspector? https://github.com/node-inspector/node-inspector/

And, how about some fancy ANSI graphics and so on? :)

[tetsuo]

Fancy graphics sounded like the logical next step after building sockets 👍 Thanks for also acknowledging that it's a plus by the way 😄

I will start with a React version of the current debugger UI. Previously written a simple stack here which I believe fits perfectly in this scenario. This has websockets and also uses multiplex-rpc along with it. There could be other alternatives to multiplex-rpc these days, but this is good to go for starters I believe.

Do you want to remove the current debugger altogether? Having a debugger that works in the terminal sounds really cool. But I am not really sure if every VM should have one. Maybe we can separate those two into, debugger and inspector (which depends on the debugger) and investigate further on how this could be improved also in the terminal.

[francisrstokes]

Well the way I see it, what would be the most flexible option is to basically establish a debugger API that can be exposed from the VM when run in debug mode. Basically just a socket server that can send and receive standardised messages and act on those. Sent messages will be things like the state of the vm, and received will be things like set breakpoint, remove breakpoint, step etc.

This way it's frontend agnostic - it's easy to to create a react, angular, terminal, or whatever. So to answer your question, I think the API definition and socket server can live within this project and any frontend can be separated.

[tetsuo]

Commit d92bec8 adds a simple test for encoding and decoding snapshots.

I had to sandbox it using vm to prevent the changes from being permanent. Using browserify seemed very convenient for this task, since 16bitjs doesn't have many dependencies (none) and this should also work in browser as well (decode-snapshot), so it is also a free test.

However, I didn't like this 🏄 This can be solved better in two ways:

1- Do not use singletons, no module level caching and such.
2- Or, we can have a way to "reset" everything, but still it is not as good as removing singletons.

I thought memory, stack and registers are the only things that needed to be reset, but apparently they are not, or maybe I did wrong filling them with zeroes. But since they are module-level, there is also no way to re-instantiate them.

[francisrstokes]

@tetsuo I checked it out briefly this morning, looking great. It's strange that zeroing the memory and registers didn't work - there really isn't anything that should prevent that method of reset from working. Perhaps we can take a quick look today? If we can get that to work then we can wire a reset function directly into the cpu object. As for removing singletons, this should be really straightforward actually, since they're all required once and passed as arguments.