6 ms·

The wild thing is that scripting languages don't have that kind of a debugger.

glandium 7y ago
Javascript does, with caveats. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
- The_rationalist 7y ago
  Is there any equivalent on chromium? I believe Firefox devtools have been ported to chromium.
  - sanxiyn 7y ago
    As far as I know, there isn't. This needs substantial support in the engine, so "devtools have been ported to chromium" is not enough.
yvdriess 7y ago
Depends. Image-based runtime languages such as Smalltalk and various Lisps will, crudely put, pause at the site of the error and give you options to fix it and continue. That already covers 99% of the OP's issues with gdb. edit: Implied is that image-based runtimes by definition produce reproducible snapshots of the error, with the full power of the Lisp or Smalltalk introspection tools. Edit-continue is the icing.
- sanxiyn 7y ago
  Not at all. Edit and continue is only a small part of what debuggers can be.
- vidarh 7y ago
  Doesn't need an image based runtime either. Ruby's "pry" is inspired by Smalltalk, in that it's providing functionality to manipulate the running environment, edit and reload code etc., and continue. During development I almost always have a make target to drop me in a pry session with all the app code loaded and initialized so I can play with the code as it is actually used.
- roca 7y ago
  OP here. Edit-and-continue addresses none of my issues with gdb. Read the paragraph "If you use a traditional interactive debugger..." again?
  - yvdriess 7y ago
    I think you are missing the implications of working with image-based language runtimes. The CI or even the client can attaches the live image of the error, the programmer opens up the image when he opens the ticket and has the full venerable introspection tools of CL or Smalltalk. This directly addresses the reproducability issue you raised in said paragraph. There are indeed occasions where you need a proper rr-like trace, but what fraction of bugs fall into that category. For illustration purposes: Grammarly has an example of fixing an intermittent network bug on a production server under load on the much-HN-linked blog post: https://tech.grammarly.com/blog/running-lisp-in-production https://tech.grammarly.com/blog/running-lisp-in-production
    - roca 7y ago
      The image contains the state that the point where the error was raised, but AFAIK it doesn't contain the history leading up to that. It's more like a coredump than an rr recording, right?
    - roca 7y ago
      > There are indeed occasions where you need a proper rr-like trace, but what fraction of bugs fall into that category. Good question. I guess it depends on what you mean by "need". If you mean "for what fraction of bugs will a developer be unable to figure out the bug, given only the state where the error surfaced, but given unlimited time", I don't know. Most developers I've worked with either have rr recordings available or they do the work to reproduce the bug locally so they can work backwards to the root cause by rerunning the test, so their experiences don't reflect those constraints. If you mean "for what fraction of bugs is it valuable to have an rr recording", I think the answer is very clearly "almost all". Many rr users, some on this very HN thread, will testify that debugging with rr is almost always better than debugging with gdb alone, whether or not they are able to reproduce the bug on-demand for debugging with gdb.
- greggman2 7y ago
  My experience is this is only if it's your own code and you have a full mental model of the state of the program. I worked on a lisp project and the lead would see a crash, type some lisp, continue, app would run. The rest of the team not so much. Maybe we were all just bad lisp programmers.
j88439h84 7y ago
Python has several
- jacobush 7y ago
  "There's more than one way to do it"
BiteCode_dev 7y ago
Python had one: https://morepypy.blogspot.com/2016/07/reverse-debugging-for-python.html?m=1 https://morepypy.blogspot.com/2016/07/reverse-debugging-for-... Never got popular enough to be ported to cpython, let alone python 3. It's no surprise though: my experience is that most python devs don't know how to use a debugger. In fact, the huge majority of tutorials to learn python don't include one, nor they give explanation about python -m, venv, pip, the python path and other very important basis. Even the people using pdb don't know very important commands like until, jump, up or tbreak.
- maest 7y ago
  Jupyter notebooks are also hilariously debug-unfriendly.
  - BiteCode_dev 7y ago
    Pdb works fine in notebooks though, and that's one of the numerous reasons students should learn it first, before any GUI debugger.
    - missjellyfish 7y ago
      That implies that students don‘t stop listening as soon as anyone mentions command line. Those who desperately need a debugger to learn are the first ones to not use it because of no GUI.
  - prennert 7y ago
    Wait what? Do you know about the %debug magic? It is the best thing ever, particularly when prototyping in the notebook which keeps most of the state. I saw Fernando Pérez use it in a YouTube video. Shame I cannot find it anymore. He was saying he debugs his code only by placing 1/0 in the part of the code he wants to inspect. After the exception is thrown %debug allows you to step into the stack and explore it via a repl. I found that crazy and tried it it. It is life changing. That's how I debug my python code for years now.
oldmanhorton 7y ago
Node-ChakraCore had Time Travel Debugging with editor support in VS Code

Javascript does, with caveats. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...

The_rationalist 7y ago
Is there any equivalent on chromium? I believe Firefox devtools have been ported to chromium.
- sanxiyn 7y ago
  As far as I know, there isn't. This needs substantial support in the engine, so "devtools have been ported to chromium" is not enough.

yvdriess 7y ago

Depends. Image-based runtime languages such as Smalltalk and various Lisps will, crudely put, pause at the site of the error and give you options to fix it and continue. That already covers 99% of the OP's issues with gdb. edit: Implied is that image-based runtimes by definition produce reproducible snapshots of the error, with the full power of the Lisp or Smalltalk introspection tools. Edit-continue is the icing.

sanxiyn 7y ago
Not at all. Edit and continue is only a small part of what debuggers can be.
vidarh 7y ago
Doesn't need an image based runtime either. Ruby's "pry" is inspired by Smalltalk, in that it's providing functionality to manipulate the running environment, edit and reload code etc., and continue. During development I almost always have a make target to drop me in a pry session with all the app code loaded and initialized so I can play with the code as it is actually used.
roca 7y ago
OP here. Edit-and-continue addresses none of my issues with gdb. Read the paragraph "If you use a traditional interactive debugger..." again?
- yvdriess 7y ago
  I think you are missing the implications of working with image-based language runtimes. The CI or even the client can attaches the live image of the error, the programmer opens up the image when he opens the ticket and has the full venerable introspection tools of CL or Smalltalk. This directly addresses the reproducability issue you raised in said paragraph. There are indeed occasions where you need a proper rr-like trace, but what fraction of bugs fall into that category. For illustration purposes: Grammarly has an example of fixing an intermittent network bug on a production server under load on the much-HN-linked blog post: https://tech.grammarly.com/blog/running-lisp-in-production https://tech.grammarly.com/blog/running-lisp-in-production
  - roca 7y ago
    The image contains the state that the point where the error was raised, but AFAIK it doesn't contain the history leading up to that. It's more like a coredump than an rr recording, right?
  - roca 7y ago
    > There are indeed occasions where you need a proper rr-like trace, but what fraction of bugs fall into that category. Good question. I guess it depends on what you mean by "need". If you mean "for what fraction of bugs will a developer be unable to figure out the bug, given only the state where the error surfaced, but given unlimited time", I don't know. Most developers I've worked with either have rr recordings available or they do the work to reproduce the bug locally so they can work backwards to the root cause by rerunning the test, so their experiences don't reflect those constraints. If you mean "for what fraction of bugs is it valuable to have an rr recording", I think the answer is very clearly "almost all". Many rr users, some on this very HN thread, will testify that debugging with rr is almost always better than debugging with gdb alone, whether or not they are able to reproduce the bug on-demand for debugging with gdb.
greggman2 7y ago
My experience is this is only if it's your own code and you have a full mental model of the state of the program. I worked on a lisp project and the lead would see a crash, type some lisp, continue, app would run. The rest of the team not so much. Maybe we were all just bad lisp programmers.

j88439h84 7y ago

Python has several

jacobush 7y ago
"There's more than one way to do it"

BiteCode_dev 7y ago

Python had one: https://morepypy.blogspot.com/2016/07/reverse-debugging-for-python.html?m=1 https://morepypy.blogspot.com/2016/07/reverse-debugging-for-... Never got popular enough to be ported to cpython, let alone python 3. It's no surprise though: my experience is that most python devs don't know how to use a debugger. In fact, the huge majority of tutorials to learn python don't include one, nor they give explanation about python -m, venv, pip, the python path and other very important basis. Even the people using pdb don't know very important commands like until, jump, up or tbreak.

maest 7y ago
Jupyter notebooks are also hilariously debug-unfriendly.
- BiteCode_dev 7y ago
  Pdb works fine in notebooks though, and that's one of the numerous reasons students should learn it first, before any GUI debugger.
  - missjellyfish 7y ago
    That implies that students don‘t stop listening as soon as anyone mentions command line. Those who desperately need a debugger to learn are the first ones to not use it because of no GUI.
- prennert 7y ago
  Wait what? Do you know about the %debug magic? It is the best thing ever, particularly when prototyping in the notebook which keeps most of the state. I saw Fernando Pérez use it in a YouTube video. Shame I cannot find it anymore. He was saying he debugs his code only by placing 1/0 in the part of the code he wants to inspect. After the exception is thrown %debug allows you to step into the stack and explore it via a repl. I found that crazy and tried it it. It is life changing. That's how I debug my python code for years now.

oldmanhorton 7y ago

Node-ChakraCore had Time Travel Debugging with editor support in VS Code