rdebug and rdebug-track-mode for ruby-debug 0.10.1
256 views
Skip to first unread message
Rocky Bernstein
Jun 11, 2008, 7:41:25 PM6/11/08
to emacs-o...@googlegroups.com
Recently Anders Lindgren and I (but mostly Anders) has been working on the emacs ruby-debug interaction. ruby-debug-extra-0.10.1.tar.gz is a tar of these GNU Emacs files (along with the latest manual for ruby-debug 0.10.1). I find it good enough for now, although it has quirks. I invite others to try out and/or join in the development.
There are two modes of interaction. The one Anders uses is where rdebug is called initially from emacs this sets up a number of windows for the buffers. There are buffers for the call stack, a source code, a variables/values, breakpoints, command and an output. Some of these are shown and some aren't. I tend to work in a more reduced mode where all I want to see is the command, source, stack and variables. So I have output shown in the command buffer. Anders likes to hide the command buffer opting for short-keystrokes which issue "step", "next" continue. And he has output shown separated from the command buffer in a different window.
The other mode of interaction I use all the time is a very reduced mode where I go into a shell and run rdebug-track-mode (via "turn-on-rdebug-track-mode"). I use it in rails as well.
In this mode when there is a debugger prompt in the process-buffer a filter triggers and shows the source in another window of a split frame. If you are familiar with Python, it's like pdbtrack.
For unit testing I've been using elk-test.el It's not fancy but it does the trick.
That's probably enough to get started. If this isn't appropriate for or of interest to this group, let me know.
There are two modes of interaction. The one Anders uses is where rdebug is called initially from emacs this sets up a number of windows for the buffers. There are buffers for the call stack, a source code, a variables/values, breakpoints, command and an output. Some of these are shown and some aren't. I tend to work in a more reduced mode where all I want to see is the command, source, stack and variables. So I have output shown in the command buffer. Anders likes to hide the command buffer opting for short-keystrokes which issue "step", "next" continue. And he has output shown separated from the command buffer in a different window.
The other mode of interaction I use all the time is a very reduced mode where I go into a shell and run rdebug-track-mode (via "turn-on-rdebug-track-mode"). I use it in rails as well.
In this mode when there is a debugger prompt in the process-buffer a filter triggers and shows the source in another window of a split frame. If you are familiar with Python, it's like pdbtrack.
For unit testing I've been using elk-test.el It's not fancy but it does the trick.
That's probably enough to get started. If this isn't appropriate for or of interest to this group, let me know.
Steve Molitor
Jun 24, 2008, 10:15:47 PM6/24/08
to Rails On Emacs
Rocky,
This sounds great. I'm having trouble getting it to work however.
When I run rdebug in emacs I get this:
rdebug:136:in `debug_load': no such file to load -- 3 (LoadError)
I'm passing in the default options -- 'rdebug --emacs 3 foo.rb'. It
seems that rdebug-core.el is passing '3' as the name of the ruby
script to rdebug. If I remove the '3' and run it as 'rdebug --emacs
foo.rb' I get a lisp error: ' (wrong-type-argument stringp nil)'. If
I just run it as 'rdebug foo.rb' it sort of works but it doesn't
display the current line of code in the source window, no breakpoints,
variable are displayed, etc.
I'm guessing I'm doing something stupid....
Steve
On Jun 11, 6:41 pm, "Rocky Bernstein" <rocky.bernst...@gmail.com>
wrote:
This sounds great. I'm having trouble getting it to work however.
When I run rdebug in emacs I get this:
rdebug:136:in `debug_load': no such file to load -- 3 (LoadError)
I'm passing in the default options -- 'rdebug --emacs 3 foo.rb'. It
seems that rdebug-core.el is passing '3' as the name of the ruby
script to rdebug. If I remove the '3' and run it as 'rdebug --emacs
foo.rb' I get a lisp error: ' (wrong-type-argument stringp nil)'. If
I just run it as 'rdebug foo.rb' it sort of works but it doesn't
display the current line of code in the source window, no breakpoints,
variable are displayed, etc.
I'm guessing I'm doing something stupid....
Steve
On Jun 11, 6:41 pm, "Rocky Bernstein" <rocky.bernst...@gmail.com>
wrote:
> Recently Anders Lindgren and I (but mostly Anders) has been working on the
> emacs ruby-debug interaction.
> ruby-debug-extra-0.10.1.tar.gz<.%20http://rubyforge.org/frs/download.php/35222/ruby-debug-extra-0.10.1.t...>is
> emacs ruby-debug interaction.
> a tar of these GNU Emacs files (along with the latest manual for
> ruby-debug 0.10.1). I find it good enough for now, although it has quirks. I
> invite others to try out and/or join in the development.
>
> There are two modes of interaction. The one Anders uses is where rdebug is
> called initially from emacs this sets up a number of windows for the
> buffers. There are buffers for the call stack, a source code, a
> variables/values, breakpoints, command and an output. Some of these are
> shown and some aren't. I tend to work in a more reduced mode where all I
> want to see is the command, source, stack and variables. So I have output
> shown in the command buffer. Anders likes to hide the command buffer opting
> for short-keystrokes which issue "step", "next" continue. And he has output
> shown separated from the command buffer in a different window.
>
> The other mode of interaction I use all the time is a very reduced mode
> where I go into a shell and run rdebug-track-mode (via
> "turn-on-rdebug-track-mode"). I use it in rails as well.
>
> In this mode when there is a debugger prompt in the process-buffer a filter
> triggers and shows the source in another window of a split frame. If you are
> familiar with Python, it's like pdbtrack.
>
> For unit testing I've been using
> elk-test.el<http://nschum.de/src/emacs/elk-test/>It's not fancy but it
> ruby-debug 0.10.1). I find it good enough for now, although it has quirks. I
> invite others to try out and/or join in the development.
>
> There are two modes of interaction. The one Anders uses is where rdebug is
> called initially from emacs this sets up a number of windows for the
> buffers. There are buffers for the call stack, a source code, a
> variables/values, breakpoints, command and an output. Some of these are
> shown and some aren't. I tend to work in a more reduced mode where all I
> want to see is the command, source, stack and variables. So I have output
> shown in the command buffer. Anders likes to hide the command buffer opting
> for short-keystrokes which issue "step", "next" continue. And he has output
> shown separated from the command buffer in a different window.
>
> The other mode of interaction I use all the time is a very reduced mode
> where I go into a shell and run rdebug-track-mode (via
> "turn-on-rdebug-track-mode"). I use it in rails as well.
>
> In this mode when there is a debugger prompt in the process-buffer a filter
> triggers and shows the source in another window of a split frame. If you are
> familiar with Python, it's like pdbtrack.
>
> For unit testing I've been using
Steve Molitor
Jun 24, 2008, 11:08:15 PM6/24/08
to Rails On Emacs
Never mind -- I had an older version of the ruby-debug gem. Sorry for the noise.
Steve
Steve Molitor
Jun 25, 2008, 12:41:19 AM6/25/08
to Rails On Emacs
OK the emac rdebug UI really rocks. It's way better than using netbeans, because of the interactive 'irb' like session. Thanks for developing this.
Is there a way to make it a bit more obvious to see what the current line is? I'm seeing the little arrow on the left fringe but it's a bit small. Can that icon be customized or made bigger? Can the current line be highlighted as well?
Thanks.
Steve
r
Jun 25, 2008, 5:42:52 AM6/25/08
to Rails On Emacs
On Jun 25, 12:41 am, "Steve Molitor" <stevemoli...@gmail.com> wrote:
> OK the emac rdebug UI really rocks. It's way better than using netbeans,
> because of the interactive 'irb' like session. Thanks for developing this.
> Is there a way to make it a bit more obvious to see what the current line
> is?
Obviously, since Emacs is infinitely programmable.
> OK the emac rdebug UI really rocks. It's way better than using netbeans,
> because of the interactive 'irb' like session. Thanks for developing this.
> Is there a way to make it a bit more obvious to see what the current line
> is?
> I'm seeing the little arrow on the left fringe but it's a bit small.
> Can that icon be customized or made bigger?
and the rdebug functions that use them are rdebug-set-frame-arrow()
and rdebug-set-frame-not-top-arrow() in rdebug-fns.el. Go to it.
> Can the current line be
> highlighted as well?
As I wrote before: I find it good enough for now, although it has
quirks.
If there are improvements or features by all means add them. If you
think them generally useful submit your changes back as a patch and
I'll add it to the distribution after review.
>
> Thanks.
Sure - share and enjoy!
>
> Steve
>
> On Tue, Jun 24, 2008 at 10:08 PM, Steve Molitor <stevemoli...@gmail.com>
> wrote:
>
> > Never mind -- I had an older version of the ruby-debug gem. Sorry for the
> > noise.
> > Steve
>
> > On Tue, Jun 24, 2008 at 9:15 PM, Steve Molitor <stevemoli...@gmail.com>
>
> > Never mind -- I had an older version of the ruby-debug gem. Sorry for the
> > noise.
> > Steve
>
Steve Molitor
Jun 25, 2008, 12:56:41 PM6/25/08
to emacs-o...@googlegroups.com
Thanks.
I'm having trouble however using rdebug on a rails unit test. It fires up and shows that it's on the first line of the test, but it quickly starts giving 'unknown command' errors when I try to step or continue (after setting a breakpoint). Once that starts happening nothing works. I'm using the latest ruby-debug from subversion. Is this a know issue? Am I doing something wrong?
Thanks again.
Steve
I'm having trouble however using rdebug on a rails unit test. It fires up and shows that it's on the first line of the test, but it quickly starts giving 'unknown command' errors when I try to step or continue (after setting a breakpoint). Once that starts happening nothing works. I'm using the latest ruby-debug from subversion. Is this a know issue? Am I doing something wrong?
Thanks again.
Steve
r
Jul 11, 2008, 2:25:22 PM7/11/08
to Rails On Emacs
See http://bashdb.sourceforge.net/ruby-debug.html#SEC4
Not sure what this has to do with Rails on Emacs though.
On Jun 25, 12:56 pm, "Steve Molitor" <stevemoli...@gmail.com> wrote:
> Thanks.
>
> I'm having trouble however using rdebug on a rails unit test. It fires up
> and shows that it's on the first line of the test, but it quickly starts
> giving 'unknown command' errors when I try to step or continue (after
> setting a breakpoint). Once that starts happening nothing works. I'm using
> the latest ruby-debug from subversion. Is this a know issue? Am I doing
> something wrong?
>
> Thanks again.
>
> Steve
>
Not sure what this has to do with Rails on Emacs though.
On Jun 25, 12:56 pm, "Steve Molitor" <stevemoli...@gmail.com> wrote:
> Thanks.
>
> I'm having trouble however using rdebug on a rails unit test. It fires up
> and shows that it's on the first line of the test, but it quickly starts
> giving 'unknown command' errors when I try to step or continue (after
> setting a breakpoint). Once that starts happening nothing works. I'm using
> the latest ruby-debug from subversion. Is this a know issue? Am I doing
> something wrong?
>
> Thanks again.
>
> Steve
>
Reply all
Reply to author
Forward
0 new messages