OK, here's a new version of ruby-debug. Most changes are related to the remote debugging and improvements targeted for a possible GUI integration:
Wait for a client connection. With this option on, the debugger will wait for a connection, before returning control to the script. You can enable it with
-woption ofrdebugscript or by callingDebugger.wait_connection = true.Stop on connect. With this option on, the debugger will stop when a remote client establishes a connection.
rdebugscript has this parameter enabled by default, but you can disable it with-noption. In your own script you can useDebugger.stop_on_connect = trueto activate it.Controlling thread. When activating a remote debugger, a control thread is activated as well. It listens on the socket (port 8990, by default) and accepts a number of commands that you can use to control a debugger, such as add/delete breakpoints, interrupt an application, etc. This is quite helpful for a GUI frontend, where you can set breakpoints at any time while your application is running.
There are also a couple of additions to the debugger commands:
l[ist] = - displays the current exception point.
f[rame] n - switches to nth frame. You can see the list of frames and their numbers with frame or where command.
tm[ate] - if you are running Mac OSX and addicted to TextMate, this command opens the current file using this editor.
That's all for now. Enjoy.
I like the remote debugging a lot. I hope you continue this project because it’s a useful tool. The hardest part of making a tool like this is the constant irony of debugging a debugger :) Good luck! – ben @ http://rubyonrailsblog.com/
Thanks.
Sometimes, it’s a real challenge especially when trying to avoid side effects the debugger can pose on the execution of an application.
Kent,
remote debugger is cool. I hope it can help when debugging threads.
One thing I found with the latest version if you don’t use the remote is that you have to call “Debugger.start” otherwise you get this message “Debugger.start is not called yet.” and you can’t use the debugger since it raises an exception. Unless I missed that bit somewhere.
l = is awesone as I was going crazy figuring out which line I was on all the time.
“tm” is awesome.
Thanks!
Pascal, how do you start debugger then?
rdebug should call ‘Debugger.start’ automatically.
Using rails, I start using “script/server webrick” (ruby-debug does not work too well with lighttpd). Doing so worked well in the previous version. Now it raises that exception unless you call start. In all fairness, I could use “rdebug script/server” (just longer to type), but the old method used to work and I’m curious as to why this is now required.
One small suggestion about the “tm” function. I think adding a parameter to specify the frame number. I would open the file from that frame number. Like “tm 9” would open the file from the 9th frame in the callstack.
And a few more comments on the new version: I miss the fact that if a command is not recognized, it would try to evaluate the expression.
I use “l
”, “l =” and “l +” (ok, just “l”) and I was wondering if “l” and “l=” could just do the trick.And a killer feature request: save the breakpoints and display values from sessions to sessions so you can start over and be at the same point where you left off last you used it. Having a way to clear all would also be helpful ;)
And last (for now), is that the same way you have the ability to display expressions everytime you step or break, having the ability to show (some of) the stack and more source code would be helpful at times (At some point, I ended up modfying the code to get just that). Having the ability to turn it on/off would be awesome.
I just spent many many hours tracking down a pretty nasty problem, and I can’t thank you enough for ruby-debug, it was an invaluable tool!
Pascal,
This was one of the incompatible changes of 0.3 release. You have to start the debugger with Debugger.start or Debugger.start_remote in order to use it. It’s not enough to require the library. This allows for a conditional activation of debugger.
Thank you very much for other suggestions! I’ll try to implement most of them in the next release.
Good stuff.
BTW, there is the ability to display expressions everytime you step or break with using display/undisplay commands.
Kent, yes, ‘disp’ comes in very very handy at times :) and I’m using it quite often.
I’m now using rdebug and quite happy with it actually.
I look forward to the next release!