[#8815] Segfault in libc strlen, via rb_str_new2 — "Sean E. Russell" <ser@...>

Howdy,

12 messages 2006/09/09
[#8817] Re: Segfault in libc strlen, via rb_str_new2 — Eric Hodel <drbrain@...7.net> 2006/09/09

On Sep 8, 2006, at 10:10 PM, Sean E. Russell wrote:

Re: [PATCH] rdoc capture output (help message)

From: "greg weber" <eegreg@...>
Date: 2006-09-29 12:52:00 UTC
List: ruby-core #8953
It looks like you could seperate this out into a rake task, but then
you would have a hard-coded dependency between your program and the
rake task.  Now every script that I have will require a rake task to
generate documentation instead of just running rdoc.  And if someone
else uses and modifies the script and wants to document it they will
have to create a rake task.  There are probably lots of things built
into Ruby that could be seperated into a rake task, but that would not
be very convennient.  Also, I think this is a feature that many
beginners that are not already familiar with rake may want to use.

I started documenting usage for my scripts using RDoc::Usage- under
the premise that it followed the motto Don't Repeat Yourself.  Then I
discovered that when I changed something about my options I was
maintaing both my options and my RDoc documentation, and I was not
following DRY.
Then I discovered that optparse is already very capable of generating
a usage statement, and I realized I should be using that- except that
there would be no rdoc documentation.  So this feature is just a
natural step in the direction of DRY.

What is the downside to including this?
The only one I see is that there is an extra option, making the usage
message for rdoc even harder to read.  I think the real problem here
is that rdoc's options should be seperated into regular and extended
(or advanced) options.  If you would like, you can give me a list of
which options should be listed as extended options, and I can submit
such a patch.

Greg Weber

In This Thread