I want to be able to modify/add code, try it out, then rewind, and try something else. Then save my changes once they work perfectly.
Simply setting breakpoints and watching variables is nice, but I can do basically the same thing by echoing/console.log'ing things. If you are going to go to the effort of making a debugger, then make it do something I can't do another way.
https://www.youtube.com/watch?v=WQZio5DlSXM https://developers.google.com/web/tools/chrome-devtools/debu... https://developers.google.com/web/tools/setup/setup-workflow...
That's quite nice, but it's only part of what I was asking for - it doesn't let you rewind. You have to reload the page each time if your edit was wrong.
It's not necessary to save state by each instruction, it's enough that it would be able to restart the current function.
Ideally it could walk back up the stack and restart other functions, but even if it was limited to just the function with the breakpoint that would be huge.
You'd have to do that anyway. If code is wrong, it corrupts state. Unless you're saying you want it to keep track of diffs of the heap, which might be interesting. But how would it handle, say, a socketIO connection that a bad edit terminates? There'd be no way to rewind that.
Maybe it doesn't matter for most work, since most work doesn't interact with persistent objects (sockets, file handles...)
Yup, that's exactly what I'm saying. Keep track of (store) the full browser state before entering a function, and when you rewind restore that exactly.
Local I/O is no problem, remote I/O will simply be restarted. Or it will error. It doesn't have to be perfect to be useful.
Mozilla actually is working on such a tool: http://rr-project.org/ (for gdb i.e native) and https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We... (for browser).
It would be awesome if they fully integrated those tools into the built in debugger.
It turns out that corrupting state isn't always such a big issue. A load of what you end up doing in js is event handlers, and by being able to replace those in realtime you can save a load of dev time.
(As ever, when this conversation comes up I complain bitterly about how Chrome only allows a single websocket connection to the debugger so you need to do weird ws proxy stuff to use live reloading and devtools at the same time....)
I also use a similar thing to have live reloading in iPython for my backend work. Honestly, I'm not sure how I ever lived without being able to swap out the code in my functions without having to rebuild all the state. It's not without issue, and you _can_ corrupt your internal state, but in practice it's fine 98% of the time.
Nope. :) Whenever you hit Ctrl-S, the VM is patched with the new definition of the function (well, the entire file's functions, really), and then execution automatically restarts at the top of the call frame. Also, at any time, you can right-click any call frame in the "Call Stack" pane and select "Restart Frame".
Yes, but I want to do that in my editor, not in the browser.
> try it out, then rewind, and try something else. Then save my changes once they work perfectly.
Certainly I do not want to copy'n'paste the code then back from browser to my editor.
Let me all do this in my editor of choice. The browser is only where I execute stuff, a debugger belongs into the editor/ide.
FWIW, I think it's planned by debugger.html project that the debugger can be used by different editors/IDEs. See the presentation at React Rally (relevant snippet is at https://www.youtube.com/watch?v=Fk--XUEorvc&feature=youtu.be...) showing the integration into emacs or even using debugger.html as CLI tool.
That is, you can already integrate quite well with some editors. I think IDEA has something similar, as well. Most of this is not in creating all new protocols and whatnot, but simply setting up reasonable defaults in tools you are already using.
It will support replaying and help go towards rewinding, although live code editing is not in there.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
I agree that "live edit" is an exciting feature. It supports a tighter feedback loop that lets you iterate in the correct context.
There are two challenges
1. transpiling, which would require a tighter integration with the project's build tools. Not impossible, but something that would require the correct UX. Chrome DevTools supports live edit now, but that is only for non source-mapped sources.
2. mapping to project sources. VS Code has done a lot of great work with source maps to map to the on disk sources with source maps. In theory, this should be easy, but there are many build tools and some edge cases with nested source maps, imagine an ember app that pulls in ember libraries which are also mapped.
With that said, this is definitely exciting and with the new front-end we can begin to work on an ambitious projects like this!
Having all the states and being able to see execution in the past blows my mind. Every debugger should support this.
The demo I saw of it -- I'm a former Mozilla employee -- was incredible. Indeed, you could step backward. It's RR for the web.
Windows doesn't come with a debugger. Linux doesn't come with a debugger. The JVM has no right-click launched debugger. CPython doesn't jump you into an interactive debug console. But all of those have a debug interface.
Leave building debuggers to others who have a clear picture of how they are using your platform.
Only by tight integration with VM/compiler you can get decent debuggers. For example Smalltalk debuggers are class above to what JS can offer today. Crass design error is ignoring debugging needs until it is too late. Adding needed hooks and state managers is expensive, just look how much effort it is now: https://bugzilla.mozilla.org/show_bug.cgi?id=1207696
I know it's a hard problem that can't be solved with static analysis like in C, indeed! I know people could do
var x = "do", y = "something", z[x + y] = function() {};
...
z[x + y] = (some other function now)
This thing is still important. The goal is to reduce the "Wtf is going on here" phase of diving into existing code. I have had to honestly abandon projects and back out of jobs with good friends because I couldn't get to that answer fast enough.
You can do so many cryptic layered indirect things with javascript, it makes unraveling it really quite hard - especially if there's a language barrier (as there was in the one I'm thinking of where I had to resign after 6 weeks in shame for a guy I had worked with for 2 years on a previous company).
I tried to build this claimed introspection tool myself in vain over the course of about 2 weeks, but diminishing returns hit and things got pretty hard. Javascript can be beautiful and simple - but it can also have cascading chains of action-at-a-distance with layers of framework scaffolding obscuring the business logic code so that the caller and the callee are not 1 frame, but 10 or 15 frames apart. [2]
My campaign to encourage people to write code in the plain in a way that hopefully any future junior developer will understand is a lifetime project.
Until I get there, tools like this would be truly invaluable. Back in the C/C++ days, it saved my butt daily.
---
[1] Excuse me for not finger pointing to specific projects. I don't find it courteous or productive. I aggressively surveyed [probably] all of them, including those offered by IDEs, in 2015.
[2] This leads to two easier tools which are
(1) the "stack and step collapser" - essentially a way to tell the debugger to ignore entire directories of code when stepping through code or printing stackdumps. Having to go through stack traces that can be literally over 100 levels with only 1 or 2 being your code is certainly a system we can improve on.
(2) a stack of stacks ... so that if an error is caught, the stack isn't smashed and replaced, but preserved in a second dimensional stack so when an error is just "some error occurred in these 1,000 lines" you can still see the previous stack.
I've often just seen stack dumps be the frameworks error handler (or the error handler erroring) and have no indication as to the actual source of the error. It's crazy how useless it can be. A stack of stacks would solve this (again, as would not coding silly things like this in the first place).
I can't imagine I'm the only person who has to deal with these problems on a daily basis. They waste so much time and leave me so flabbergasted as to how to address problems sometimes.