headers
Sam Roberts | 8 Jul 2005 16:48
Favicon

docs patch for class IPSocket, class Socket, and Socket.getservbyname, Socket.getaddrinfo

I don't have the time to continue, but if somebody is interested, I
think the following is fairly useful - get rid of the comment before
committing.

Note that I don't know what some of the possible AI_ flags do, thus the
"...".

Its against the 1.8 src, sorry.

Cheers,
Sam

Index: socket.c
===================================================================
RCS file: /src/ruby/ext/socket/socket.c,v
retrieving revision 1.108.2.29
diff -u -r1.108.2.29 socket.c
--- socket.c	2 Jul 2005 15:22:11 -0000	1.108.2.29
+++ socket.c	8 Jul 2005 14:40:38 -0000
 <at>  <at>  -2236,6 +2236,36  <at>  <at> 
     return rb_str_new(ptr, len);
 }

+/*
+ * Document-class: IPSocket
+ *
+ * IPSocket is the parent of TCPSocket and UDPSocket and implements function
+ * common to them.
+ *
+ * A number of APIs in IPSocket, Socket, and their descendants return an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lothar Scholz | 10 Jul 2005 09:33

Re: RubyDoc error for "File"

Hello Ryan,

RD> On Jun 26, 2005, at 8:30 AM, Lothar Scholz wrote:

>> not really an error but a missing information, could someone please
>> add the information that "File" inherits from "IO".

RD> Actually, from what I can tell, there is no information to add. It
RD> SHOULD be extracted from the C code. I did some poking and it looks
RD> like it IS extracted from the C code, but somehow isn't making its
RD> way all the way to generation. I'm not sure why either. With the  
RD> exception of the exception classes (punny), there aren't many other
RD> areas where there are legitimate subclasses in core. This is one of
RD> them, so there might be a weird edgecase bug that slipped through,
RD> but I'll be damned if I can find it.

Hmmm, have you tried other C extensions.

Im using FOX to test my new RDOC/RI browser, which is using the
inheritance information a lot. But FOX is using
separate ruby source code for documentation.

What about QT, WxRuby, GTK and other packages that have huge
inheritance structures ? Anybody tried to generate RDOC for them ?

If this can't be figured out automatically what about adding some
extra hints to the rdoc code ?

--

-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Kellett | 10 Jul 2005 17:38

test::unit

current text for the test::unit --help stands as

------

Test::Unit automatic runner.
Usage: asm.rb [options] [-- untouched arguments]

     -r, --runner=RUNNER              Use the given RUNNER.
                                      (c[onsole], f[ox], g[tk], g[tk] 
2, t[k])
     -n, --name=NAME                  Runs tests matching NAME.
                                      (patterns may be used).
     -t, --testcase=TESTCASE          Runs tests in TestCases  
matching TESTCASE.
                                      (patterns may be used).
     -v, --verbose=[LEVEL]            Set the output level (default  
is verbose).
                                      (s[ilent], p[rogress], n 
[ormal], v[erbose])
         --                           Stop processing options so that  
the
                                      remaining options will be  
passed to the
                                      test.
     -h, --help                       Display this help.

Deprecated options:
         --console                    Console runner (use --runner).
         --gtk                        GTK runner (use --runner).
         --fox                        Fox runner (use --runner).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Kearns | 11 Jul 2005 15:25
Picon

Re: test::unit

I was knocking together a zsh completion function the other day for
testrb and found this a little confusing at first as well.

How about?

On Sun, Jul 10, 2005 at 05:38:59PM +0200, Alexander Kellett wrote:
> current text for the test::unit --help stands as
> 
> ------
> 
> Test::Unit automatic runner.
> Usage: asm.rb [options] [-- untouched arguments]
> 
>     -r, --runner=RUNNER              Use the given RUNNER.
>                                      (c[onsole], f[ox], g[tk], g[tk]2, t[k])
>     -n, --name=NAME                  Runs tests matching NAME.

      -n, --name=NAME                  Run all tests matching method NAME.

>                                      (patterns may be used).
>     -t, --testcase=TESTCASE          Runs tests in TestCases matching TESTCASE.

      -t, --testcase=NAME              Run all tests in TestCases matching class NAME

"tests in TestCases matching TESTCASE" is a little difficult for me to
process. :-)

-     -a, --add=TORUN                  Add TORUN to the list of things to run; can be a file or a directory.
+     -a, --add=FILE                   Add FILE to the list of things to run; can be a file or a directory.
(Continue reading)

Permalink | Reply | 0 comments |
headers
mathew | 12 Jul 2005 04:12
Picon
Favicon
Gravatar

Documenting methods for which there is no source

I started work on documenting RSS. However, all of the normal methods 
you'd use to traverse the parsed RSS object hierarchy seem to be 
implemented via reflection. Hence, there's no actual code to stick 
comments around to get Rdoc to document the methods.

Is there a way to deal with this kind of situation using Rdoc? If not, I 
guess I'll submit what I have so far, as it's better than nothing...

mathew
Permalink | Reply | 7 comments |
headers
Sam Roberts | 12 Jul 2005 04:30
Favicon

Re: Documenting methods for which there is no source

Quoting meta <at> pobox.com, on Mon, Jul 11, 2005 at 09:12:25PM -0500:
> I started work on documenting RSS. However, all of the normal methods 
> you'd use to traverse the parsed RSS object hierarchy seem to be 
> implemented via reflection. Hence, there's no actual code to stick 
> comments around to get Rdoc to document the methods.

Yeah, its an oddity of dynamic code.

I think you could make a kind of skeleton of rss classes, with the
methods and no bodies, and run rdoc over it. Crude, but effective.

> Is there a way to deal with this kind of situation using Rdoc? If not, I 
> guess I'll submit what I have so far, as it's better than nothing...

And nothing is pretty close to what there is.

The most annoying thing I find with the RSS encoder is failures seem to
return nil. No exception, no error message, you call a method, get nil
back, and then have to start reading the code, and thats not so easy
because many of the methods don't actually exist in text form, they are
created on the fly.

So, anything you can do to help this situation is much appreciated!

Thanks,
Sam
Permalink | Reply | 6 comments |
headers
mathew | 12 Jul 2005 06:14
Picon
Favicon
Gravatar

Re: Documenting methods for which there is no source

Sam Roberts wrote:

>The most annoying thing I find with the RSS encoder is failures seem to
>return nil. No exception, no error message, you call a method, get nil
>back, and then have to start reading the code, and thats not so easy
>because many of the methods don't actually exist in text form, they are
>created on the fly.
>  
>

Well, I have to say that having spent some hours working my way through 
it, I don't like the RSS library as a decoder of RSS. It seems to be a 
literal translation of the standards into code, rather than something 
designed to be easy and convenient to use. As a result, you need to know 
what kind of RSS feed you're parsing, because the API for accessing the 
parsed objects is different depending on the input format--your code may 
work fine for RSS2.0, and then fall over with a nil when fed RSS1.0 by 
the next feed.

I had a look on the web for other Ruby RSS implementations, and based on 
what I found I'm assuming this one got chosen for the standard library 
because it was the first one to implement at least three major flavors 
of RSS, i.e. the first to be fairly complete. I was kinda hoping it was 
better as an encoder.

I try to avoid wheel-reinvention, but this particular wheel is just 
begging for it...

mathew
(Continue reading)

Permalink | Reply | 5 comments |
headers
James Britt | 12 Jul 2005 06:52
Favicon

Re: Documenting methods for which there is no source

mathew wrote:
> ...
> I had a look on the web for other Ruby RSS implementations, and based on 
> what I found I'm assuming this one got chosen for the standard library 
> because it was the first one to implement at least three major flavors 
> of RSS, i.e. the first to be fairly complete. I was kinda hoping it was 
> better as an encoder.
> 
> I try to avoid wheel-reinvention, but this particular wheel is just 
> begging for it...

There has been discussion and criticism of this library on ruby-talk. 
The code may been improved since then, though you may have to install 
the new library independently as I do not think it is in the current 
Ruby stable version.  Maybe in Ruby 1.8.3

Jim Wierich's XML Builder library makes it quite easy to construct 
proper XML, so if you know what it is you need to include in your feed 
it may be a better choice.

Poke around the numerous Ruby on Rails sites; I believe there some 
example of people using Builder to hand-roll RSS.

James
Permalink | Reply | 0 comments |
headers
Sam Roberts | 14 Jul 2005 04:57
Favicon

Re: Documenting methods for which there is no source

Quoting meta <at> pobox.com, on Mon, Jul 11, 2005 at 11:14:54PM -0500:
> Sam Roberts wrote:
> 
> >The most annoying thing I find with the RSS encoder is failures seem to
> >return nil. No exception, no error message, you call a method, get nil
> >back, and then have to start reading the code, and thats not so easy
> >because many of the methods don't actually exist in text form, they are
> >created on the fly.
> > 
> >
> 
> Well, I have to say that having spent some hours working my way through 
> it, I don't like the RSS library as a decoder of RSS. It seems to be a 
> literal translation of the standards into code, rather than something 
> designed to be easy and convenient to use. As a result, you need to know 

I think thats a good design - start with a solid implementation of the
data structures, add easy and convenient APIs on top. Some work was
started with the RSS::Maker API, which I like a lot, and stole the
design for my vCard encoding API.

But... the encoding API just returns nil instead of raising descriptive
exceptions when something is wrong. Thats not a reason to start from
scratch, it just needs better error reporting!

On the decoding side, it seems to be completely missing an easy to use
API. Oops.

I've sympathy with the author, I've had similar problems, many people's
idea of easy is "does what i want to do", but how is he to know what you
(Continue reading)

Permalink | Reply | 3 comments |
headers
mathew | 14 Jul 2005 18:50
Picon
Favicon
Gravatar

Re: Documenting methods for which there is no source

Sam Roberts wrote:

>maybe you could contribute a nice high-level decoding API, so rather
>than reinvention a wheel, you contribute a comfortably padded
>gyro-stabilized unicycle to fit onto the existing wheel!
>

I started work on it a couple of days ago. So far I have it parsing all 
well-formed variants of RSS into a unified data structure. It uses a lot 
of reflection, but the methods are all regular or attr_accessor type 
methods. I'm trying to keep the code easy to understand. This may limit 
the extent to which I can cope with malformed feeds, but I'll worry 
about that when the time comes...

I've been trying to think of a good module name. I don't want to use 
'RSS', because it's already taken, and the library will (I hope) 
eventually parse Atom as well. Best I can come up with so far is 
'Syndication', with  Syndication::FeedParser returning a 
Syndication::Feed, and so on.

This is my third attempt at an implementation of RSS parsing. Hopefully 
this time I'll end up with something really good (and releasable) :-)

mathew
Permalink | Reply | 2 comments |

Gmane