211–220 of 223 posts
At my job, we do Java, and it would be wonderful to have something like this. I litter System.err.println around the code then run it so I can better understand the behavior, so the idea of doing the equivalent in a recording would be awesome! I don't know how my colleagues manage with a regular debugger, it's like looking through a pinhole, you only see a tiny part of reality.
Earlier quoted context omitted.
(Replay engineer): Yes it does!
I just made an account did a recording but cannot seem to see the network request tab anywhere in the ui? I can make a brakepoint, add console.log statements and evaluate stuff (pretty cool tech) but where do I find network requests?
Earlier quoted context omitted.
Wow! Thank you so much for this comment. I have been using IntelliJ for over 10 years and I never knew this feature existed, I just gave it a try and it's incredibly useful. One thing I wish Java debuggers supported was the ability to move the instruction pointer to a different line, as has been possible in other debuggers for ages. Is it a JVM limitation maybe? I remember being able to drag the "current line" pointe…
> I remember being able to drag the "current line" pointer forwards or backwards in languages like C, C++, and C# in maybe 2003 This is because Visual Studio debugger was always state of the art.
AFAICR Borland's IDEs had that before the turn of the century.
Earlier quoted context omitted.
I'm using just a slightly outdated browser, which is probably the cause. I'm on Ungoogled Chromium 81 (by choice) which doesn't automatically update, and the ||= (boolean OR assignment) operator wasn't added until 85. Your payload appears to compile down for older browsers (as is evident by the use of `var`, unless.. you actually write code using `var`) but it misses the ||= operator transformation it seems. Thus, th…
BTW, created https://github.com/RecordReplay/devtools/issues/3619 to follow up on the logical or assignment as well. Should be fixed soon
Earlier quoted context omitted.
The problem with breakpoints is my loop runs 1000 times and I only care about the one time it errors. Making watch logic for that sometimes is too complicated or changes the outcome (race conditions especially). This seems like a great solution. I'll be checking it out!
Err, conditional breakpoints are your friend. Also, "nobody" uses breakpoints? Everyone in my team uses them all the time.
Co-founder here. It feels incredible to be sharing Replay with all of you. It's been a labor of love the past five years! Replay started off as a simple experiment in what would happen if we added a step back button and rewind button to the Debugger. We quickly realized two things. First, nobody uses breakpoints. Second, being able to share is so much more powerful than being able to rewind. Here’s how Replay works t…
>nobody uses breakpoints Lost me here, using breakpoints are an invaluable tool for people that actually take the time to use their tools correctly.
Earlier quoted context omitted.
The problem with breakpoints is my loop runs 1000 times and I only care about the one time it errors. Making watch logic for that sometimes is too complicated or changes the outcome (race conditions especially). This seems like a great solution. I'll be checking it out!
If you can trigger a debugger from a keyword it's usually pretty easy to trigger it conditionally or on an exception in the code rather than through a GUI. That works well for ruby and javascript and probably lots of others. e.g. something like the equivalent of def foo bar.map do |b| b.do_something! debugger if b.state == :something_youre_interested_in end rescue => e debugger end I'm really excited by Replay. I thi…
Earlier quoted context omitted.
Err, conditional breakpoints are your friend. Also the GP claims "nobody" uses breakpoints? Everyone in my team uses them all the time. Suppose it all depends on your language/tool chain, in my experience breakpoints are very commonly used by developers in visual studio.
I assume he referred to breakpoints in the browser.
Earlier quoted context omitted.
If you can trigger a debugger from a keyword it's usually pretty easy to trigger it conditionally or on an exception in the code rather than through a GUI. That works well for ruby and javascript and probably lots of others. e.g. something like the equivalent of def foo bar.map do |b| b.do_something! debugger if b.state == :something_youre_interested_in end rescue => e debugger end I'm really excited by Replay. I thi…
Why is that better than using your IDE? Your writing debugging code directly in you production code...
Obviously you remove that debug statement from your code after you're finished debugging.
Earlier quoted context omitted.
Why is that better than using your IDE? Your writing debugging code directly in you production code...
How would you debug something inside of a loop (1000s of values) with a line breakpoint in your IDE? Your debugger will trigger the breakpoint every single time it walks through the loop, even when everything is going fine. Now if you conditionally trigger the breakpoint inside the loop using code, it will trigger once and only if it encounters whatever error you want to catch. Obviously you remove that debug stateme…