headers
Hugh Sasse Staff Elec Eng | 2 Mar 2005 19:02
Picon
Picon

ri doesn't know about __FILE__

I was trying to produce an informative error message for a script
and wanted to find out what line number information I could pick up.
ISTR there is a __LINE__ or __line__ variable, but have not found it
looking quickly.  So I tried ri.  It doesn't know about itns hgs 209

brains hgs 209 %> ri __LINE__
Nothing known about __LINE__
brains hgs 210 %> ri __FILE__
Nothing known about __FILE__
brains hgs 211 %> ri '$0'
Nothing known about $0
brains hgs 212 %> ri 'ARGV'
Nothing known about ARGV
brains hgs 213 %>

but my ri works (lots of classes turn up information.)..

Should this information make it into ri? Else, why not?

I'm not sure what is happening with ri given that Rdoc maintnance
is to be adopted by someone, so I'm sending this here rather than to
Dave Thomas.

         Thank you,
         Hugh
Permalink | Reply | 35 comments |
headers
Tanaka Akira | 6 Mar 2005 03:58

Re: implementing #to_pp, and pp.rb doc diffs (Re: Requesting addition to IRB (configurable standard output))

In article <20050226025441.GA17581 <at> ensemble.local>,
  Sam Roberts <sroberts <at> uniserve.com> writes:

> Even after converting the docs to rdoc format, I see no simpler way.

Thank you for the rdocification.  It is merged.

I'm not sure that to_pp is a name good enough for Kernel.
--

-- 
Tanaka Akira
Permalink | Reply | 0 comments |
headers
Sam Roberts | 8 Mar 2005 04:01
Favicon

[doc patch] socket.c - #getsockopt + #setsockopt


I posted earlier setsockopt docs. There was a one char typo causing
unsightly html formatting. This is fixed.

Also, now there is getsockopt documentation.

Index: socket.c
===================================================================
RCS file: /src/ruby/ext/socket/socket.c,v
retrieving revision 1.108.2.24
diff -u -r1.108.2.24 socket.c
--- socket.c	28 Feb 2005 02:45:15 -0000	1.108.2.24
+++ socket.c	8 Mar 2005 02:59:09 -0000
 <at>  <at>  -272,6 +272,51  <at>  <at> 
     return Qnil;
 }

+/*
+ * Document-method: setsockopt
+ * call-seq: setsockopt(level, optname, optval)
+ *
+ * Sets a socket option. These are protocol and system specific, see your
+ * local sytem documentation for details.
+ *
+ * === Parameters
+ * * +level+ is an integer, usually one of the SOL_ constants such as
+ *   Socket::SOL_SOCKET, or a protocol level.
+ * * +optname+ is an integer, usually one of the SO_ constants, such
+ *   as Socket::SO_REUSEADDR.
+ * * +optval+ is the value of the option, it is passed to the underlying
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Britt | 8 Mar 2005 04:24
Favicon

Re: [doc patch] socket.c - #getsockopt + #setsockopt

Sam Roberts wrote:
> I posted earlier setsockopt docs. There was a one char typo causing
> unsightly html formatting. This is fixed.
> 
> Also, now there is getsockopt documentation.

Thank you!

James
Permalink | Reply | 1 comment |
headers
Sam Roberts | 8 Mar 2005 05:01
Favicon

Re: [doc patch] socket.c - #getsockopt + #setsockopt

Quoting jbritt <at> ruby-doc.org, on Mon, Mar 07, 2005 at 08:24:48PM -0700:
> Sam Roberts wrote:
> >I posted earlier setsockopt docs. There was a one char typo causing
> >unsightly html formatting. This is fixed.
> >
> >Also, now there is getsockopt documentation.
> 
> Thank you!

My pleasure.

Cheers,
Sam
Permalink | Reply | 0 comments |
headers
Sam Roberts | 8 Mar 2005 05:06
Favicon

can somebody show me how to document constants in C exts?


I'd like to document stuff like:

  #ifdef	INADDR_ANY
      sock_define_const("INADDR_ANY", INADDR_ANY);
  #endif

Any suggestions, or even a pointer to a C lib that has a number of
consts documented in a way people like, so I can do it like that?

A lot just need to have their (possible, its sys dependent) existence
listed.

Or maybe I should just put example code that lists all the socket
constants?

Thanks
Sam
Permalink | Reply | 1 comment |
headers
Gavin Sinclair | 8 Mar 2005 12:17
Picon

Re: can somebody show me how to document constants in C exts?

On Tuesday, March 8, 2005, 3:06:03 PM, Sam wrote:

> I'd like to document stuff like:

>   #ifdef	INADDR_ANY
>       sock_define_const("INADDR_ANY", INADDR_ANY);
>   #endif

> Any suggestions, or even a pointer to a C lib that has a number of
> consts documented in a way people like, so I can do it like that?

I've no idea, but my gut feeling is that this kind of documentation is
not supported.

> A lot just need to have their (possible, its sys dependent) existence
> listed.

> Or maybe I should just put example code that lists all the socket
> constants?

That seems like the best idea.

Cheers,
Gavin
Permalink | Reply | 0 comments |
headers
Gavin Sinclair | 8 Mar 2005 12:23
Picon

Re: ri doesn't know about __FILE__

On Thursday, March 3, 2005, 5:02:22 AM, Hugh wrote:

[...]

>  brains hgs 212 %>> ri 'ARGV'
>  Nothing known about ARGV

> but my ri works (lots of classes turn up information.)..

> Should this information make it into ri? Else, why not?

Dave Thomas is still firmly in control of RI, AFAIK, and I don't think
he'd be keen on adding that kind of stuff to RI, but that's just my
instinct.  Others (James and Jim, from memory) have expressed keenness
for that kind of feature on this list in the past.  Me, I can take it
or leave it.  Some kind of command-line Ruby reference would be sweet,
but I don't strongly believe that RI should be that tool (you know,
tools doing one thing well and all that).

> I'm not sure what is happening with ri given that Rdoc maintnance
> is to be adopted by someone, so I'm sending this here rather than to
> Dave Thomas.

I didn't/don't know about RDoc maintenance changing hands.  The fact
that it's in Ruby CVS means that all opinions (and patches!) are fair
game, IMO.  If you want to pursue the matter, Hugh, I suggest
ruby-core.

Cheers,
Gavin
(Continue reading)

Permalink | Reply | 34 comments |
headers
Hugh Sasse Staff Elec Eng | 8 Mar 2005 12:55
Picon
Picon

Re: ri doesn't know about __FILE__

On Tue, 8 Mar 2005, Gavin Sinclair wrote:

> On Thursday, March 3, 2005, 5:02:22 AM, Hugh wrote:
> 
> [...]
> 
> >  brains hgs 212 %>> ri 'ARGV'
> >  Nothing known about ARGV
>
         [...]
> or leave it.  Some kind of command-line Ruby reference would be sweet,
> but I don't strongly believe that RI should be that tool (you know,
> tools doing one thing well and all that).

I don't see the significance of the separation: these things are as
much part of ruby as Array or Hash.
> 
> > I'm not sure what is happening with ri given that Rdoc maintnance
> > is to be adopted by someone, so I'm sending this here rather than to
> > Dave Thomas.
> 
> I didn't/don't know about RDoc maintenance changing hands.  The fact

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/4305

> that it's in Ruby CVS means that all opinions (and patches!) are fair
> game, IMO.  If you want to pursue the matter, Hugh, I suggest
> ruby-core.
> 
> Cheers,
(Continue reading)

Permalink | Reply | 33 comments |
headers
Gavin Sinclair | 8 Mar 2005 13:57
Picon

Re: ri doesn't know about __FILE__

On Tuesday, March 8, 2005, 10:55:05 PM, Hugh wrote:

>> or leave it.  Some kind of command-line Ruby reference would be sweet,
>> but I don't strongly believe that RI should be that tool (you know,
>> tools doing one thing well and all that).

> I don't see the significance of the separation: these things are as
> much part of ruby as Array or Hash.

Yeah, but where do you stop?  RI is clearly aimed at documenting
classes and methods.  If it's to go beyond that to include ARGV etc.,
then you need a new rationale for it.  Arbitrarily adding things makes
it difficult to remember what's in there and what's not.

I'd say the right thing is to leave RI as it is, and look at Pickaxe
for other parts of Ruby.

Beyond that, I'd recommend getting the FAQ in good condition and
offering a command-line interface to that, viz.

  $ rubyfaq ARGV
  [shows all Q&A involving "ARGV"]

Gavin
Permalink | Reply | 32 comments |

Gmane