Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding in the Debugger (2007)

tidyfirst.substack.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Coding in the Debugger (2007)

#21

Post by melvinroest »

For my job I work in Pharo. So I am still doing this all the time, haha.

What’s also really neat is to be able to work “inspector-driven”. By that I mean to inspect an object and send messages to it directly in order to understand how to interact with it. This becomes even more true if you need some temporary global data that has no permanent reference to hang around for a bit longer.

Question: I want to make a tutorial about creating a Selenium scraper with Pharo along with some data visualization and post it on here. I have noticed that Pharo is really strong on those things. Does anyone have an idea which site I should pick? Perhaps Hacker News itself? Also, the tricks I will be showing there would also be really handy for Selenium web tests. I wonder if people ok HN would be interested in that.

Re: Coding in the Debugger (2007)

#22

Post by pulse7 »

In Smalltalk this was always possible! In Java the default JVM implementation is able to do "hot code swapping" only for method bodies. Smalltalk was able to replace everything - even class restructuring. There was a research project at Sun/Oracle [1] to add JVM support for all possible changes in "hot code swapping"... but the implementation was not incorporated into JVM because of increased maintenance complexity so the author made a JVM fork and named it DCEVM and is maintaining it [2]. I thing this project is also connected with HotSwapAgent [3]. There is also a completely different commercial implementation of the hot-swapping capability for Java called JRebel [4] which is used on many software development projects...

[1] https://ssw.jku.at/dcevm/ [2] http://dcevm.github.io [3] http://hotswapagent.org [4] https://www.jrebel.com

Re: Coding in the Debugger (2007)

#23

Post by squeaky-clean »

fiedzia wrote: post #12
tester756 wrote: post #2

This is debugger driven development In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly. Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc. Once you try this you'll never want to go back to print-debugging (except for specific cases)

the power of debugging in interpreted languages is so far unbeatable. I have a shortcut for "import pudb; pudb.set_trace" in my IDE (pudb is pdb with UI)

I used to use OzCode in C# around 2014 or so, and from my memory it was better than anything available today for an interpreted language.

Just looked it up again since it's been so long. Looks like DataDog acquired them and are ending the product for an in-house replacement, quite a shame.

Re: Coding in the Debugger (2007)

#24

Post by lysecret »

I love doing this in Python/Pycharm. I feel like there are three development modes:

1. Greenfield new development, on unknown parameters (complicated APIs, data frames). I like to use Jupyter Notebooks for that. I use them like a really powerful repl, nothing lives permanently in a Notebook.

2. Type Driven Domain Driven development. Either as a result of building a running MVP through 1, or on a domain you control / understand well. You start from frist principles and model out the flow in Types (usually DataClasses in Python).

3. Debugger driven "Adding Features/ Debugging". Obviously, we use the Debugger to debug, but it can also be very powerful to add a feature to a large system.

Re: Coding in the Debugger (2007)

#25

Post by Calzifer »

I still do this all the time with Java. Especially because the application is rather slow to start or setup whatever I want to debug. It can also influence how you structure the code. In my opinion to the better.

If you mutate state all over a method it is harder to "restart" the method after changing it. Instead I tend to either not mutate state and return the result or work with local variables and just change the object at the very end of the method.

Or might start to more separate a lock/transaction from what is processed within because when "restarting" the method you don't want to relock it.

Re: Coding in the Debugger (2007)

#26

Post by Calzifer »

tester756 wrote: post #2

This is debugger driven development In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly. Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc. Once you try this you'll never want to go back to print-debugging (except for specific cases)

You can also run arbitrary code at any breakpoint (at least for Java with Eclipse).

Want to check the content of a buffered image? Just run ImageIO.write(...) while the application is stopped. Want to check the current working directory? Paths.get(".").toAbsolutePath()

Heck you can even add code as breakpoint condition (which does not need to stop at the breakpoint), e.g. for some on the fly print debug. Changing values does not have to be a manual process but can also be injected as breakpoint condition.

Re: Coding in the Debugger (2007)

#27

Post by pjmlp »

fiedzia wrote: post #12
tester756 wrote: post #2

This is debugger driven development In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly. Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc. Once you try this you'll never want to go back to print-debugging (except for specific cases)

the power of debugging in interpreted languages is so far unbeatable. I have a shortcut for "import pudb; pudb.set_trace" in my IDE (pudb is pdb with UI)

Some compiled languages do offer similar REPL tooling,

Java, Scala, .NET (VB, C#, F#), C++, Haskell (Leksah/GHCi), OCaml

Re: Coding in the Debugger (2007)

#28

Post by pjmlp »

squeaky-clean wrote: post #23
fiedzia wrote: post #12

Earlier quoted context omitted.

the power of debugging in interpreted languages is so far unbeatable. I have a shortcut for "import pudb; pudb.set_trace" in my IDE (pudb is pdb with UI)

I used to use OzCode in C# around 2014 or so, and from my memory it was better than anything available today for an interpreted language. Just looked it up again since it's been so long. Looks like DataDog acquired them and are ending the product for an in-house replacement, quite a shame.

VS has hot-reload nowadays anyway, and a REPL.

Re: Coding in the Debugger (2007)

#29

Post by whizzter »

simula67 wrote: post #19
tester756 wrote: post #2

This is debugger driven development In programming environments with very powerful debuggers like .NET this is relatively common since it allows you to do a lot of stuff at fly. Change values, evaluate expressions, change function's code, jump ahead and behind, etc, etc. Once you try this you'll never want to go back to print-debugging (except for specific cases)

It is also possible to do most of that with Python in Pycharm (except maybe jump behind?). This is why going from Python to Go can feel like going backward. IMO, even compiled languages should have an "interpreted mode" for development. Once the development is complete, the code can still be compiled to get the benefits of runtime performance.

It's mostly a matter of engineering, Visual C++ has had the ability to change function bodies and continuing running from the point of a crash (as long as data wasn't badly corrupted) since at least Visual Studio 6 (Yes, back in 1998!!!).

Re: Coding in the Debugger (2007)

#30

Post by Conscat »

heyoni wrote: post #15
Conscat wrote: post #7

Earlier quoted context omitted.

Sadly rr cannot work on software that makes any kind of call to GPUs, so its usefulness is pretty limited on a lot of larger software. But when it's usable, imo it's amazing.

Sorry this might sound stupid but does that include software with UIs? I’m thinking of a browser where it can be gpu accelerated or not.

If the UI is not GPU accelerated while you are recording, rr will work fine. You can even have GPU calls in the code while recording, they just can't be on code paths that are taken. So a simple command line flag that makes the code choose to use CPU rendering instead of GPU rendering should be fine.

That said, GPU rendering is one of the things that deterministic replay could be most useful for, so it's unfortunate that this doesn't work in rr for now.

Post reply on HN