This is the second time this has showed up on the front page and I'll say the same thing I said last time. The title of this post is totally misleading. The article presents a very high level overview of some concepts that could be important to consider if you decide to write a scala/java debugger, but you won't have any idea how to write a debugger after reading this.
I am a fan of python.
when developing python and needing a breakpoint I just write
>> import pdb;pdb.set_trace()
in the respective line and can then execute the code till that point and have all the current variables available in the console.
This was missing for me when I started doing stuff in scala, so I hacked something to be able to do the same in Scala and jump straight to the REPL(unfortunately variables need to be passed explicitly here, but most of the REPL functionality works:
I always wonder why more languages don't have this, which I call repl at point, or repl with context. Not sure if there is a more standard name. Even clojure with its generally awesome repl support doesn't have it.
It avoided having to pass in variables explicitly by using groovy's AST transform ability (macros) to examine the code for which variables would be in scope and pass those into the repl automatically. I wonder if something similar would be possible in scala?
No I think they are related but different. For instance with pdb or the clojure repl I"ll add entire new functions or classes and try them out.
With gdb or jdb that might be theoretically possible but it certainly is not convenient or commonly done. Typically your stretching things with a complicated one liner expression.
But you are right concepts are pretty close, its just that I find a lot of things that call themselves "debuggers" don't have the ability to add new code. Things that call themselves "repls" dont' have the ability to stop at a point or context like a debugger. pdb being the exception. Why can't we have tools that do both things well.
Any decent Java IDEs can do this for you. I'm not sure if that capability covers Scala.
You can set a breakpoint (conditional or not), and have every thing within that context available for you. The next step is to launch an "Evaluation window" where you can execute Java code.
If you were to set the breakpoint at the web-application level (as opposed to plain Java process/class/console-app), you can get information of the Threads and Frames as well.
This techniques have been available for quite some time in the IDEs... that is provided you're not allergic to IntelliJ/NetBeans/Eclipse.
Best part: no code change.
I have no comment for those who prefer VIM/Emacs and bemoaned the lack of powerful stuff they got from other environments.
Yes, if you have an IDE you don't have this problem at all.
I am more with the VIM/Emacs crowd though I guess.
I didn't know though that you could create an "evaluation window" in Eclipse. I really liked the refactoring features in Eclipse though and miss them sometimes.
- You can set "Step Filtering" to avoid JDK standard classes (or libraries that you know won't cause the bugs)
- The Expression Evaluation also supports code-assist/code-completion
It's really tough to beat IDEs like Eclipse and IntelliJ these days with plenty contributors and strong companies behind them churning new features everyday.
