Ruby on Windows: debugger questions and comments

[JC]

'm evaluating scripting languages for a client. Ruby as a language
seems immediately likeable (I love the Smalltalk influence) but the
tools and their documentation seem likely to cause big problems for
Windows users. (Thelanguage docs otoh are exemplary.) In particular:

1. It seems that the debugger built into FreeRIDE doesn't work under
Windows? If this is true, why on earth doesn't the debugger pop a
dialog box saying this when you try to use it??? Leaving around a
broken debugger without any warning to users in a development
environment makes Ruby look so bad compared to the standard Python and
Perl distributions. A few minutes effort would at least stop Ruby from
looking unreliable.

2. Could someone tell me where I could find documentation on the debug
mode for the interpreter? Its use might be self-evident to people who
have to use GDB type tools every day, but for those of who don't still
use use the Pony Express a page or two of docs would help.

3. Can anyone recommend another Ruby debugger? I've briefly tried
Arachno (bizarrely it doesn't seem to show the value of variables) -
is there anything else?

Thanks.

 

[Curt Hibbs]

1. It seems that the debugger built into FreeRIDE doesn't work under
Windows? If this is true, why on earth doesn't the debugger pop a
dialog box saying this when you try to use it??? Leaving around a
broken debugger without any warning to users in a development
environment makes Ruby look so bad compared to the standard Python and
Perl distributions. A few minutes effort would at least stop Ruby from
looking unreliable.

The latest version of FreeRide, and the version of FreeRIDE that comes with
the One-Click Ruby Installer for Windows, both have working debuggers.

Curt

 

[Tobias Luetke]

Off topic but here goes:

I know this sounds like a long stretch but after writing thousands of
lines of production code in ruby my observation is that the lack of
debugger is actually beneficial for the project because it results in
better test coverage.
When i encounter a bug or observe an oddity I go ahead and write a
small test case for it which doesn't take much longer than using the
debugger. After I'm done I'm left with the certainty that it works
just like after using a debugger, however I also know it will never
break again because now i got a test case double checking it for me.

3. Can anyone recommend another Ruby debugger? I've briefly tried
Arachno (bizarrely it doesn't seem to show the value of variables) -
is there anything else?

Rails ships with a breakpointer. This opens an IRB session on the spot
when you put the method call "breakpoint" anywhere in your code.

 

[JC]

The latest version of FreeRide, and the version of FreeRIDE that comes with
the One-Click Ruby Installer for Windows, both have working debuggers.

Curt

So why does the FreeRIDE homepage say: "Unfortunately, the debugger
still does not work on Windows. We are actively trying to resolve this
problem."? And why does the Ruby 182-14 install that I downloaded NOT
having aworking debugger?

 

[Daniel Berger]

JC wrote:

3. Can anyone recommend another Ruby debugger? I've briefly tried
Arachno (bizarrely it doesn't seem to show the value of variables) -
is there anything else?

Thanks.

There is also the debugger that comes with RDT (the Ruby plugin for
Eclipse). Visit http://rubyeclipse.sf.net

Regards,

Dan

 

[Ville Mattila]

3. Can anyone recommend another Ruby debugger? I've briefly tried
Arachno (bizarrely it doesn't seem to show the value of variables) -
is there anything else?

Arachno ruby show variable values just fine, at least for me. I'm using
Arachno 0.4. Have you enabled break point and is the debuggee state pane
visible for you?

- Ville

 

[JC]

Arachno ruby show variable values just fine, at least for me. I'm using
Arachno 0.4. Have you enabled break point and is the debuggee state pane
visible for you?

- Ville

As far as I can tell given the lack of docs, yes. I can set
breakpoints and I can even see what variables are in scope, but I'm
not getting values.

 

[JC]

JC wrote:


There is also the debugger that comes with RDT (the Ruby plugin for
Eclipse). Visit http://rubyeclipse.sf.net

Regards,

Dan

Thanks - I'll check.

 

[JC]

So why does the FreeRIDE homepage say: "Unfortunately, the debugger
still does not work on Windows. We are actively trying to resolve this
problem."? And why does the Ruby 182-14 install that I downloaded NOT
having aworking debugger?

Further comments: if I run rubygems, then the debugger semi-works - ie
I can step through code but see the state of variables (which seems
pretty pointless).

Comments:

- Five minutes of documentation would have made using the debugger
such as it is much smooother. Yes, there had been some sort of
"require rubgems" message, but that's not the same as saying "there's
a separate program caled rubygemsetcetc.exe that you if have to run to
make the debugger work" - this looked like a library error at first,
then when I checked the FreeRIDE site simply like a completely broken
debugger.

- A debugger that won't show variable values (if this is the case)
should be documented in the faq and Ride help.

I know these tools are written for volunteers for free, but if want
Ruby to spread the last thing you want is tools that cause FUD. Right
now that's what you have - when even basic tools are this poorly
documented its bound to settle new users. A few minutes documentation
effort would avoid this. You don't have to get the debugger to work,
but you really should document how to switch it on (!) and what its
limitations are. This is literally ten minutes effort.

 

[Stephen Kellett]

3. Can anyone recommend another Ruby debugger? I've briefly tried
Arachno (bizarrely it doesn't seem to show the value of variables) -
is there anything else?

Not a debugger, but various coverage, profiling, thread analysis and
flow tracing tools (which do show the variable values). Windows
NT/W2K/XP.

http://www.softwareverify.com

Stephen

 

[Pit Capitain]

- Five minutes of documentation would have made using the debugger
such as it is much smooother.

I'm sure you did what you suggested and sent the missing documentation to the
FreeRide maintainers, did you?

Regards,
Pit

 

[Pit Capitain]

I'm sure you did what you suggested and sent the missing documentation to the
FreeRide maintainers, did you?

Sorry, this doesn't sound as it was intended to. What I wanted to say was: if
you could spend some minutes to sum up your experiences and send them to the
FreeRide maintainers in order to enhance their docs, then others could benefit
from the things you've learned.

Regards,
Pit

 

[Florian Gross]

Rails ships with a breakpointer. This opens an IRB session on the spot
when you put the method call "breakpoint" anywhere in your code.

And it works outside of Rails as well -- just copy the breakpoint*.rb
and binding_of_caller.rb files over to somewhere where your application
finds them, do require 'breakpoint' and place breakpoint() calls in your
code to get an IRB session right there at that spot. Ruby's powerful
introspection abilities will then easily let you examine variables,
instance_variables, methods, call stack and much more.

By default those sessions will be inline, meaning they will happen via
the application's regular STDIN/OUT which is usually okay for Ruby
tools, but not for CGI applications, daemons etc. -- for those cases you
should do a single Breakpoint.activate_drb call (you can do this right
after the require) and the breakpoints will wait in server mode until
you connect with breakpoint_client.rb. (ruby breakpoint_client.rb)

If there's any questions regarding this I'd be pleased to answer them.

 

[James G. Britt]

I'm sure you did what you suggested and sent the missing documentation to the
FreeRide maintainers, did you?

If JC did, that would be great.

But if JC didn't, so what?

It pains me when people thoughtful enough to point out errors and
omissions are chided for failing to personally address the problems
they are reporting.

It discourages people from making suggestions, which helps no one.

Is JC the even best or correct person to write the proper
documentation? It is one thing to note that documentation is unclear
or incomplete, and quite another to provide an accurate remedy.

James

 

[JC]

If JC did, that would be great.

But if JC didn't, so what?

It pains me when people thoughtful enough to point out errors and
omissions are chided for failing to personally address the problems
they are reporting.

It discourages people from making suggestions, which helps no one.

Is JC the even best or correct person to write the proper
documentation? It is one thing to note that documentation is unclear
or incomplete, and quite another to provide an accurate remedy.

James

Yes, it does seem strange to suggest that someone who doesn't know how
to use the tool - and may never use it again, given the problems (I
suspect I'll recommend my client uses Python) - should write the docs.
Beside the obvious (or rather, really, REALLY obvious problems) the
idea of an ordinary user rather than a tool's author writing docs
misses the point that there maybe features and limitations that only
the author maybe able to document.

 

[jason_watkins]

2. Could someone tell me where I could find documentation on the debug
mode for the interpreter? Its use might be self-evident to people who
have to use GDB type tools every day, but for those of who don't still
use use the Pony Express a page or two of docs would help.

http://www.rubycentral.com/book/trouble.html

In particular, the command list table at the bottom of the page. Just
re-discovered this chapter in the book on the train ride to work this
morning, trying to figure out a problem I'm having.

 

[Pit Capitain]

Yes, it does seem strange to suggest that someone who doesn't know how
to use the tool - and may never use it again, given the problems (I
suspect I'll recommend my client uses Python) - should write the docs.
Beside the obvious (or rather, really, REALLY obvious problems) the
idea of an ordinary user rather than a tool's author writing docs
misses the point that there maybe features and limitations that only
the author maybe able to document.

Come on, James, in your previous mail you talked about what you had to do to
make the debugger "semi-work" and that five minutes would be enough to add this
knowledge to the docs. You seemed to know exactly what you were missing. I was
not suggesting that you write about things you don't know.

You tried to work with FreeRide, a program that is provided "as is". You found
things that should be improved. Now what? You wrote about the problems here in
the mailing list, but unfortunately this thread is about windows debuggers, not
especially about the FreeRide debugger. On the other hand, you could have given
feedback directly to the FreeRide team in the form of a bug report, a patch, or
a feature request. What do you think is the better way to improve the current
situation?

Regards,
Pit

 

[JC]

(e-mail address removed) wrote in message

http://www.rubycentral.com/book/trouble.html

In particular, the command list table at the bottom of the page. Just
re-discovered this chapter in the book on the train ride to work this
morning, trying to figure out a problem I'm having.

Thank you, Jason - that's really useful.

 

[JC]

On the other hand, you could have given

feedback directly to the FreeRide team in the form of a bug report, a patch, or
a feature request. What do you think is the better way to improve the current
situation?

Regards,
Pit

Pit -

This really is getting silly - I've already told you that the FreeRIDE
people are reading this thread, and that I've mailed them - and I can
now say they are busy fixing the bug. As for why I didn't mail them
before posting, at that stage I wasn't even sure that it was a bug
rather than my mis-using the debugger, making a the newsgroup
definitely the most appropriate place to start. The time to post a bug
report is when you actually understand what the problem is - not at
the earliest possible moment you can confuse and disrupt development.

 

[Pit Capitain]

This really is getting silly - I've already told you that the FreeRIDE
people are reading this thread, and that I've mailed them - and I can
now say they are busy fixing the bug. As for why I didn't mail them
before posting, at that stage I wasn't even sure that it was a bug
rather than my mis-using the debugger, making a the newsgroup
definitely the most appropriate place to start. The time to post a bug
report is when you actually understand what the problem is - not at
the earliest possible moment you can confuse and disrupt development.

James, I didn't want to upset you. If I did, then please accept my apologies.
I'm glad your experiences will not wither (is this correct?) here in the mailing
list but instead will help to improve FreeRide.

Regards,
Pit