Can we attack the 'not enough libraries' thing straight on?

[d***@candle.superlink.net]

Hi --

We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."

I'm not saying it's not true... but I'm getting worried that we're
settling into a culture where Ruby is "that great language that
doesn't have the equivalent of CPAN," and that as that reputation
spreads, it's going to be harder to shake it off later -- even when
lots more modules have been written.

So: is there a process by which we can identify *exactly* what all the
missing modules are? And then write them? :-)

The role of CPAN in all this needs to be kept in perspective. There's
no obligation on [the] Ruby[ community]'s part to duplicate CPAN
module by module. In fact, it's quite interesting to look at other
archives, such as <http://www.haskell.org/libraries>.

Also, I would advocate not getting embroiled in issues of naming,
specifically hierarchical module naming (text/soundex,
algorithms/sort/qsort, etc.). The main thing is for software to come
into existence, and for its availability to be publicized. If we try
to work out in advance questions like who gets to write the
authoritative x/y/z module, etc., the chances are fairly good that
nothing will ever get done.

So, all you almost-satisfied Ruby programmers, what's missing? :-)


David

[Joey Gibson]

On Thu, 23 Jan 2003 10:36:31 +0900, ***@candle.superlink.net wrote:

||| We've all heard this: "Ruby is great, but it doesn't have the
||| equivalent of CPAN."

I've been using Ruby since 2000 (I think) and I considered abandoning it
after reading Bruce Eckels make that exact point, but then I thought about
it and decided to stick with it. Ruby is too good a language (and fun too!)
to just scrap it because of this "library imbalance" which may or may not
ever affect me. IOW, there may be 10 times more libraries available for
Perl and Python, but how many of them do I actualy need?

||| So, all you almost-satisfied Ruby programmers, what's missing? :-)

One part of cpan that I really like is the cpan shell that let's you query
what you have, find what you need and install it. I haven't looked at the
Perl code for that to see how complicated a task that is, but it's a very
nice thing to have.

Joey


--
http://www.joeygibson.com

[Hal E. Fulton]

----- Original Message -----
From: "Joey Gibson" <***@joeygibson.com>
To: "ruby-talk ML" <ruby-***@ruby-lang.org>
Sent: Wednesday, January 22, 2003 7:58 PM
Subject: Re: Can we attack the 'not enough libraries' thing straight on?

Post by Joey Gibson
||| So, all you almost-satisfied Ruby programmers, what's missing? :-)
One part of cpan that I really like is the cpan shell that let's you query
what you have, find what you need and install it. I haven't looked at the
Perl code for that to see how complicated a task that is, but it's a very
nice thing to have.

True, but a meta-issue.

The question at hand (correct me if I'm wrong, David) is:
What libraries (i.e., *content*) does CPAN have that you
wish Ruby had? (Ditto for Python's repository.)

Hal

[d***@candle.superlink.net]

Hi --

Post by Hal E. Fulton
----- Original Message -----
Sent: Wednesday, January 22, 2003 7:58 PM
Subject: Re: Can we attack the 'not enough libraries' thing straight on?

Post by Joey Gibson
||| So, all you almost-satisfied Ruby programmers, what's missing? :-)
One part of cpan that I really like is the cpan shell that let's you query
what you have, find what you need and install it. I haven't looked at the
Perl code for that to see how complicated a task that is, but it's a very
nice thing to have.

True, but a meta-issue.
What libraries (i.e., *content*) does CPAN have that you
wish Ruby had? (Ditto for Python's repository.)

And Haskell's, and whatever. Yes, I was asking a non-meta question --
very nuts and bolts :-)


David

[Dave Thomas]

Post by Joey Gibson
||| We've all heard this: "Ruby is great, but it doesn't have the
||| equivalent of CPAN."
I've been using Ruby since 2000 (I think) and I considered abandoning it
after reading Bruce Eckels make that exact point, but then I thought about
it and decided to stick with it.

I was sitting across the table from Bruce last week (while Andy was
belly dancing, but that's another story) and mentioned that article. He
said he was planning on withdrawing it. That might have been second
thoughts, or I might have been leaning forward somewhat too agressively
(or it might be that the belly dancing was just too scary).

It would be very nice if Ruby could grow to have a sufficient number of
libraries, and if those libraries worked synergistically together. Think
how wonderful it would be to have something that was both powerful and
concise.


Dave

[ahoward]

On Thu, 23 Jan 2003, Joey Gibson wrote:

<snip>

IOW, there may be 10 times more libraries available for Perl and Python, but
how many of them do I actualy need?

<snip>

a very good point. just today i had to write a perl script and was
overwhelmed in modules and add-ons - many of which simply weren't needed. one
idea i've had is the idea of 'candidate libraries' : anyone who's worked with
the c++ boost libraries knows what i'm talking about, but here's a short and
sweet explanation

* libraries wishing to become part of the ruby standard library should
follow some sort of standards (naming being one of them) and perhaps fit
into some overall package management system (like the cpan shell). they
should install in standard places, have standard docs (in fact it'd be
great if there were a site_ruby/doc directory doccumenting every thing
installed on your system), etc.

* other modules can do what they please

this is one idea CPAN lacks - a central set of standards which modules must
conform to (unit testing for modules?) and a way to separte the really good
modules from all the chatter and useless crap...

just some some thoughts...

-a
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ***@fsl.noaa.gov
| Phone: [phone]
| Fax: [phone]
====================================

[Tim Bates]

Post by ahoward
this is one idea CPAN lacks - a central set of standards which modules must
conform to (unit testing for modules?) and a way to separte the really good
modules from all the chatter and useless crap...

Debian GNU/Linux gets this just right, IMHO. They have a policy that packages
wishing to be placed on their central set of package mirrors must adhere to,
a proper dependency system, mirroring of packages so they're always available
and not dependant on the author's personal server/ISP (one of my pet hates
about RAA), command-line and curses tools for installing/removing/viewing
packages and their dependancies, policies concerning the quality, quantity
and location of documentation, etc... This packaging system is the one and
only reason I use Debian over any other Linux distribution. It would take a
significant amount of effort to get such a beast running for Ruby, but once
done I think the benefits would be phenomenal.

Tim Bates

[Timon Christl]

Post by Tim Bates

Post by ahoward
this is one idea CPAN lacks - a central set of standards which modules must
conform to (unit testing for modules?) and a way to separte the really good
modules from all the chatter and useless crap...

Debian GNU/Linux gets this just right, IMHO. They have a policy that packages
wishing to be placed on their central set of package mirrors must adhere to,
a proper dependency system, mirroring of packages so they're always available
and not dependant on the author's personal server/ISP (one of my pet hates
about RAA), command-line and curses tools for installing/removing/viewing
packages and their dependancies, policies concerning the quality, quantity
and location of documentation, etc... This packaging system is the one and
only reason I use Debian over any other Linux distribution. It would take a
significant amount of effort to get such a beast running for Ruby, but once
done I think the benefits would be phenomenal.

I would like to contribute a few thoughts on the topic. When installing
additional ruby packages the first thing you have to do currently is
looking into the README file to see if the package is installed via

ruby extconf.rb && make && make test && make site-install

or

ruby install.rb

or

ruby install.rb config && ruby install.rb setup && ruby install.rb install

or perhaps it's something completely different (The example commands
above were taken from: ruby-gnome-all-0.29, rdoc-beta-1, date2-3).

It would be very nice if installation works just like software written
using GNU autoconf (./configure && make && make install). All the
package managers of the various linux distributions use a uniform way of
installation, generally something like "retrieve that thing from
harddisk/from the web, unpack it, then run a certain script with a
fixed, predefined name to actually install it". What exactly that
script does it not important, but the interface should not vary. My
proposition would be: installation of ruby modules is done via

ruby install.rb

which configures the package, builds it and installs it. Nothing more
and nothing less.

[Massimiliano Mirra]

Post by Tim Bates

Post by ahoward
this is one idea CPAN lacks - a central set of standards which modules must
conform to (unit testing for modules?) and a way to separte the really good
modules from all the chatter and useless crap...

Debian GNU/Linux gets this just right, IMHO. They have a policy that packages
wishing to be placed on their central set of package mirrors must adhere to,
a proper dependency system, mirroring of packages so they're always available
and not dependant on the author's personal server/ISP (one of my pet hates
about RAA), command-line and curses tools for installing/removing/viewing
packages and their dependancies, policies concerning the quality, quantity
and location of documentation, etc... This packaging system is the one and
only reason I use Debian over any other Linux distribution. It would take a
significant amount of effort to get such a beast running for Ruby, but once
done I think the benefits would be phenomenal.

rpkg was meant to be just that and went as far as handlig dependencies
and compiling on the fly. Unfortunately some months ago I got busy
with another job and at about the same time the new RAA and
raa-install were announced, interest in it declined somewhat and I
felt less of in a hurry to complete it.

(Actually, in the last week two persons contacted me because they
couldn't access it anymore on allruby.com, so maybe I wasn't totally
right.)


Massimiliano

[d***@candle.superlink.net]

Hi --

Post by ahoward
* libraries wishing to become part of the ruby standard library should
follow some sort of standards (naming being one of them) and perhaps fit
into some overall package management system (like the cpan shell). they
should install in standard places, have standard docs (in fact it'd be
great if there were a site_ruby/doc directory doccumenting every thing
installed on your system), etc.
* other modules can do what they please

The standard library is a different matter -- at least, that term is
generally reserved for the stuff in the distribution itself. RAA is
all add-on -- the well-named stuff as well as the miscellany :-)


David

[ahoward]

Post by d***@candle.superlink.net

Post by ahoward
* libraries wishing to become part of the ruby standard library should
follow some sort of standards (naming being one of them) and perhaps fit
into some overall package management system (like the cpan shell). they
should install in standard places, have standard docs (in fact it'd be
great if there were a site_ruby/doc directory doccumenting every thing
installed on your system), etc.
* other modules can do what they please

The standard library is a different matter -- at least, that term is
generally reserved for the stuff in the distribution itself. RAA is
all add-on -- the well-named stuff as well as the miscellany :-)

look at boost and you'll understand what i meant : the idea is that _very
good_ modules (like, say, amrita) are all _potential_ candidates for inclusion
into a standard library and thus should somehow be 'comformant'. for an
example of how NOT to do this open up ten or so of the 'standard' modules
which ship with perl! if the authors who write such good modules (rdoc,
amrita, testunit, etc) had a set of module standards to follow it would be
trival to incorporate them into the next release of ruby, and the cvs version
before that.

-a
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ***@fsl.noaa.gov
| Phone: [phone]
| Fax: [phone]
====================================

[Gavin Sinclair]

[Comparing to C++ boost system]
* libraries wishing to become part of the ruby standard library should
follow some sort of standards (naming being one of them) and perhaps fit
into some overall package management system (like the cpan shell). they
should install in standard places, have standard docs (in fact it'd be
great if there were a site_ruby/doc directory doccumenting every thing
installed on your system), etc.
* other modules can do what they please
this is one idea CPAN lacks - a central set of standards which modules must
conform to (unit testing for modules?) and a way to separte the really good
modules from all the chatter and useless crap...

Good ideas. It's great to have a repository that anybody can
contribute to, and we do need to be able know which ones are well
implemented and supported. I wish someone who has used a lot of
packages (i.e. not me) would write a summary of packages they think
are ready for the big time. Also along these lines, I believe the RAA
should mandate a standard for versioning. Everything should be
versioned x.y.z, with perhaps some allowance for alpha, beta,
whatever. Version numbers based on dates or descriptions are not
particularly informative.

About "standard docs", I think this is the way forward:
- packages have a doc directory
- this gets installed along with the package so it ends up in
something like
site_ruby/1.6/froboz/doc/package.info
/index.html

- it can therefore be determined which packages have been installed
and have documentation installed

This allows different programs to programatically access all package
documentation. The particular program I have in mind might be called
'rdb' (for Ruby Documentation Browser) and would do the following:
- build a list of all installed package doco (using package.info for
description etc.)
- generate an HTML page containing links to all available package
doco (the index.html files, which represent RDoc output and
contain the README etc. as well as the API doc)
- open a browser to that page

There you have it. One command to access all of your available
package documentation. Of course it can take an argument so you can
access a particular package doco easily.

I mention this in this thread because I have a suspicion that Ruby's
reputation for a lack of libraries is superficial. There are a lot of
libraries; we just don't always access them very well. Setting some
standards and easing access are easy things to do, and they can only
encourage effort in creating more high-quality libraries, and higher
quality documentation for those libraries.

One technical nit: not all libraries conform to the pattern whereby
they install in a single directory.

Anyway, things like package management require community evolution.
Judging by the number of RAA entries, the Engligh-speaking Ruby
community has evolved to the point where some standards ought to be
enforced to help us make sense of it all.

Gavin

[Eric Hodel]

Post by Gavin Sinclair
- packages have a doc directory
- this gets installed along with the package so it ends up in
something like
site_ruby/1.6/froboz/doc/package.info
/index.html
- it can therefore be determined which packages have been installed
and have documentation installed

I _very_ _strongly_ disagree with installing docs in my lib dir. Of
course, anything in the FreeBSD ports tree should be moving over to
/usr/local/share/doc/ruby, but if I am installing a non ported package
I do not want it cluttering up my lib dir with things that are not
libraries.

from hier(9) on FreeBSD:
lib/ archive libraries

...

share/

...

doc/ miscellaneous documentation; ...

[Simon Cozens]

Post by d***@candle.superlink.net
Also, I would advocate not getting embroiled in issues of naming,
specifically hierarchical module naming (text/soundex,
algorithms/sort/qsort, etc.)

David, I respect you and I agree with you; but on this point I have to
differ. As I've said several times in the past, if people don't use
authoritative names for modules, they'll use cutesy names, and you'll
never know that Foozilla is a module to parse SGML. I know that if I
go to CPAN and get something called SGML::Parser then it's reasonably
likely to be a SGML parser. Naming is important!

Please, let's not forget lessons we learnt - even today: someone was
asking for a Ruby Lisp interpreter. Now, what would that be called?
Language::LISP? Scheme.rb? No, of course, it was given the eminently
sensible name of Rouge, from which one could determine, well,
absolutely nothing at all, except that it might have something to do
with makeup. Naming is important!

The things that CPAN has that Ruby doesn't have:
1) sensibly named modules
2) reasonably comprehensive documentation
3) that's it. Go forth and hackify.

[Hal E. Fulton]

----- Original Message -----
From: "Simon Cozens" <***@simon-cozens.org>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-***@ruby-lang.org>
Sent: Wednesday, January 22, 2003 8:02 PM
Subject: Re: Can we attack the 'not enough libraries' thing straight on?

Post by Simon Cozens

Post by d***@candle.superlink.net
Also, I would advocate not getting embroiled in issues of naming,
specifically hierarchical module naming (text/soundex,
algorithms/sort/qsort, etc.)

David, I respect you and I agree with you; but on this point I have to
differ. As I've said several times in the past, if people don't use
authoritative names for modules, they'll use cutesy names, and you'll
never know that Foozilla is a module to parse SGML. I know that if I
go to CPAN and get something called SGML::Parser then it's reasonably
likely to be a SGML parser. Naming is important!
Please, let's not forget lessons we learnt - even today: someone was
asking for a Ruby Lisp interpreter. Now, what would that be called?
Language::LISP? Scheme.rb? No, of course, it was given the eminently
sensible name of Rouge, from which one could determine, well,
absolutely nothing at all, except that it might have something to do
with makeup. Naming is important!

Pardon me while I play David's Advocate. :)

Yes, names are important. But what DAB is addressing is the
fact that people always say RAA < CPAN. And he wants to
know: What are the top things missing? And I want to know, too.

The point is: Let's not discuss naming conventions IN THIS
THREAD. Let's discuss what new libraries are needed.

And after all: Packages can be renamed MUCH more quickly than
they can be developed.

Post by Simon Cozens
1) sensibly named modules
2) reasonably comprehensive documentation
3) that's it. Go forth and hackify.

If that's true, then it's not so much an issue of content
as of organization. But I'm not convinced everyone thinks
the way you do on this.

FWIW, I'm not a Perl hacker, so I don't really have an
opinion. There's nothing from CPAN that I miss. :)

Hal

[d***@candle.superlink.net]

Hi --

Post by Simon Cozens

Post by d***@candle.superlink.net
Also, I would advocate not getting embroiled in issues of naming,
specifically hierarchical module naming (text/soundex,
algorithms/sort/qsort, etc.)

David, I respect you and I agree with you; but on this point I have to
differ. As I've said several times in the past, if people don't use
authoritative names for modules, they'll use cutesy names, and you'll
never know that Foozilla is a module to parse SGML. I know that if I
go to CPAN and get something called SGML::Parser then it's reasonably
likely to be a SGML parser. Naming is important!

Would it surprise you to learn that I rather knew I'd hear from you in
response to that part of my post? :-)

The thing is, names can be mapped later, and arbitrarily many views of
a module archive can be created. My concern is that the process of
deciding up front what things should be called, what to do about
multiple versions of modules, how to deal with badly written
"official" modules, etc., is potentially endless, and that if people
are waiting for that to happen, we'll never get the modules we need.

Post by Simon Cozens
Please, let's not forget lessons we learnt - even today: someone was
asking for a Ruby Lisp interpreter. Now, what would that be called?
Language::LISP? Scheme.rb? No, of course, it was given the eminently
sensible name of Rouge, from which one could determine, well,
absolutely nothing at all, except that it might have something to do
with makeup. Naming is important!

Yes, but what if there are five Lisp interpreters? And what if some
of them are better than others? Same for SGML parsers, etc. Somehow
there has to be a mechanism for people to write software that they
want to write, and for it to be distributed on something other than a
winner-take-all basis. That, in turn, means that even if there's a
naming hierarchy, it will never be the whole story. And that,
finally, means that there's no reason to wait to write software until
that naming hierarchy is agreed upon (whatever that even means -- I
don't even know that such a process is possible).

Post by Simon Cozens
1) sensibly named modules
2) reasonably comprehensive documentation
3) that's it. Go forth and hackify.

OK, but what modules do we need? :-) Or are you saying that (some of)
the software in question is there but hidden under names that make
people think it's not there?


David

[Daniel Carrera]

Post by d***@candle.superlink.net
OK, but what modules do we need? :-) Or are you saying that (some of)
the software in question is there but hidden under names that make
people think it's not there?

I don't know what Simon thinks, but I really do think that exactly. It
took me a while to find NArray. The only reason why I can find it in RAA
now is because I already know it exists.

I suspect that there are more libraries in RAA that I'd be interested in
and I just don't know are there.

[Simon Cozens]

Post by Daniel Carrera
I don't know what Simon thinks, but I really do think that exactly. It
took me a while to find NArray. The only reason why I can find it in RAA
now is because I already know it exists.

Right. I believe there are decent Ruby modules for handling MIME mails;
of course, I can't find them, because they're not sensibly named.

But hey, that doesn't matter! All that matters is that people deliver
an unindexable, undocumentable, inexplicable mass of code. Then we'll
catch up with CPAN, right?

[d***@candle.superlink.net]

Hi --

Post by Simon Cozens

Post by Daniel Carrera
I don't know what Simon thinks, but I really do think that exactly. It
took me a while to find NArray. The only reason why I can find it in RAA
now is because I already know it exists.

Right. I believe there are decent Ruby modules for handling MIME mails;
of course, I can't find them, because they're not sensibly named.

Any package that doesn't turn up on an RAA search for "mime" doesn't
deserve to be found. Even if it's called "marcel", it should have
"mime" in its description.

Post by Simon Cozens
But hey, that doesn't matter! All that matters is that people deliver
an unindexable, undocumentable, inexplicable mass of code. Then we'll
catch up with CPAN, right?

Parts of CPAN, anyway :-)

But honestly, no one is advocating the kind of disorder you're
describing here. There are some different views and ideas on the
table, but I think we all agree that things should be documented,
indexed, searchable, etc.


David

[Tom Sawyer]

want to here a crazy idea?

make require internet capable:

require 'http://www.ruby.or/raa/somepackage/code.rb'

oh, it gets crazier. before going out on the internet require will look for it
locally. if it is available locally great, but if the package is not
installed locally then it will use raainstall to install it. then finish the
require. in essence, all code in the RAA gets a namespace according to the
url and that is used for the require.

crazy?
--
tom sawyer, aka transami
***@transami.net


.''.
.''. . *''* :_\/_: .
:_\/_: _\(/_ .:.*_\/_* : /\ : .'.:.'.
.''.: /\ : ./)\ ':'* /\ * : '..'. -=:o:=-
:_\/_:'.:::. | ' *''* * '.\'/.' _\(/_'.':'.'
: /\ : ::::: = *_\/_* -= o =- /)\ ' *
'..' ':::' === * /\ * .'/.\'. '._____
* | *..* : |. |' .---"|
* | _ .--'| || | _| |
* | .-'| __ | | | || |
.-----. | |' | || | | | | | || |
___' ' /"\ | '-."". '-' '-.' '` |_.
------------------------------------------------------------

[Wai-Sun Chia]

Post by Tom Sawyer
want to here a crazy idea?
require 'http://www.ruby.or/raa/somepackage/code.rb'
oh, it gets crazier. before going out on the internet require will look for it
locally. if it is available locally great, but if the package is not
installed locally then it will use raainstall to install it. then finish the
require. in essence, all code in the RAA gets a namespace according to the
url and that is used for the require.
crazy?

Any security guy/gal will freak out here!
Can you say "trojan"? Nope I don't mean contraceptives.. ;-)

To do what you describe securely, you'll need authentication mechanisms
via signatures, hashes, key-servers, etc. It'll turn pretty complex and
nightmarish in a blink of an eye...

[ahoward]

Post by Tom Sawyer
want to here a crazy idea?
require 'http://www.ruby.or/raa/somepackage/code.rb'
oh, it gets crazier. before going out on the internet require will look for it
locally. if it is available locally great, but if the package is not
installed locally then it will use raainstall to install it. then finish the
require. in essence, all code in the RAA gets a namespace according to the
url and that is used for the require.
crazy?

ever use the cpan module?

crazy.


_UNLESS_ certain modules could conform to an ample enough set of standards to
abosolutely guarantee a seamless automated intall - this is, of course, why
the cpan module never seems to work (it does not have this).

-a
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ***@fsl.noaa.gov
| Phone: [phone]
| Fax: [phone]
====================================

[NAKAMURA, Hiroshi]

Hi, Tom,

Sent: Thursday, January 23, 2003 1:01 PM
want to here a crazy idea?
require 'http://www.ruby.or/raa/somepackage/code.rb'

I find a joy to hear this kind of "crazy" idea that seems
to be hard or impossible. :)

Why don't you search RAA for example with keywords require
and download? You find
http://www.ruby-lang.org/raa/list.rhtml?name=net-require

It checks local file as a repository, not RAA.

ATTN: from the source;
| This library is *not* production quality but just proof-of-concept.

Regards,
// NaHi

[Warren Brian Noronha]

dear devels
it would also be nice to have all the libs assorted like
File/
Filetools.....
......
IO/
Pipe.....
IPC/
Msg
SysV......
regards
warren brian noronha
***@freedomink.org

On Thu, 23 Jan 2003 13:01:52 +0900

Post by Tom Sawyer
want to here a crazy idea?
require 'http://www.ruby.or/raa/somepackage/code.rb'
oh, it gets crazier. before going out on the internet require will look for it
locally. if it is available locally great, but if the package is not
installed locally then it will use raainstall to install it. then finish the
require. in essence, all code in the RAA gets a namespace according to the
url and that is used for the require.
crazy?
--
tom sawyer, aka transami
.''.
.''. . *''* :_\/_: .
:_\/_: _\(/_ .:.*_\/_* : /\ : .'.:.'.
.''.: /\ : ./)\ ':'* /\ * : '..'. -=:o:=-
:_\/_:'.:::. | ' *''* * '.\'/.' _\(/_'.':'.'
: /\ : ::::: = *_\/_* -= o =- /)\ ' *
'..' ':::' === * /\ * .'/.\'. '._____
* | *..* : |. |' .---"|
* | _ .--'| || | _| |
* | .-'| __ | | | || |
.-----. | |' | || | | | | | || |
___' ' /"\ | '-."". '-' '-.' '` |_.
------------------------------------------------------------

[Gavin Sinclair]

Post by Warren Brian Noronha
it would also be nice to have all the libs assorted like
File/
Filetools.....
......
IO/
Pipe.....
IPC/
Msg
SysV......

This would be nice. In the volunteer, every man do his bit, world of
Ruby library development, it's not possible to centrally manage this,
though.

However, Ruby has a nice ability to create aliases to classes/modules,
so someone could manage a file that looks like this (I'll demonstrate
with IPC, since File and IO are built-in classes):

module IPC
module Msg
require 'ipcmsglib' # Fictitious library installed on system
include IpcMsgLib
# IpcMsgLib::foo now available as IPC::Msg::foo
end

module SysV
require 'sysvipc' # Fictitious library installed on system
include SysVIPC
# SysVIPC::quux now available as IPC::SysV::quux
end
end


This could be broken up substantially to save startup time, so the
IPC::SysV module is defined in 'ipc/sysv', so only when you require
that library does it fetch and include the real SystemV IPC library.

To avoid treading on other namespaces, you'd probably put all of this
in its own module Std, and directory 'std'. So code looks like this:

require 'std/ipc/msg'

Std::IPC::Msg::foo ...

Or this:

require 'std/ipc' # we get everything available in IPC

include Std # include this for convenience if safe

IPC::Msg::foo ...
IPC::SysV::quux ...


I think this is a good idea, but unlikely to happen anytime soon.
It's nice that Ruby can do it, though. There may be quicker ways to
implement it, too, like "IPC::SysV = ::SysVIPC" or something, but I
wanted to highlight conditional library mapping.

Gavin

[Simon Cozens]

Post by Gavin Sinclair
This would be nice. In the volunteer, every man do his bit, world of
Ruby library development, it's not possible to centrally manage this,
though.

That's odd; I wonder how it's possible that it works in the volunteer,
every man do his bit, world of Perl library development.

[Gavin Sinclair]

Post by Simon Cozens

Post by Gavin Sinclair
This would be nice. In the volunteer, every man do his bit, world of
Ruby library development, it's not possible to centrally manage this,
though.

That's odd; I wonder how it's possible that it works in the volunteer,
every man do his bit, world of Perl library development.

Fair point, but it's a matter of where the community's at. I'm sure
Perl wasn't always as organised as it is now. Ruby is extremely lucky
to be able to learn many things from Perl, but it still takes time.

Also, difference in languages engender difference in community
attitudes, approaches, capabilities, etc., although I can't really
elaborate on that.

What do you think of the idea I put forward, though? I thought it was
right up your alley :)

Gavin

[Gavin Sinclair]

Post by Simon Cozens

Post by Gavin Sinclair
This would be nice. In the volunteer, every man do his bit, world of
Ruby library development, it's not possible to centrally manage this,
though.

That's odd; I wonder how it's possible that it works in the volunteer,
every man do his bit, world of Perl library development.

Sorry, another reply.

Is it *centrally* managed in the Perl world? If not, I'd like to know
more about the processes that allow a decentralised planning model to
succeed. But I imagine that with the size of the Perl community,
there must be a few people qualified and inclined to take on the task.

The diminunitive size of the Ruby community only allows for one or two
people to manage a set of library mappings, as I proposed, and
probably not even that.

Gavin

[Simon Cozens]

Post by Gavin Sinclair
Is it *centrally* managed in the Perl world?

Nope. People who are given CPAN access (anyone who asks for it,
basically) is implicitly trusted to know where would be a sensible
namespace to put their libraries. Most of the time they get it right,
because most of the time they know that people won't find their
modules as easily if they don't get it right.

There's also the ***@perl.org list for those who aren't sure
whether or not they're likely to get it right, but peer pressure,
documentation and a very large set of sensible example namings
make it pretty easy.

[Daniel Carrera]

Post by Gavin Sinclair
IPC::Msg::foo ...
IPC::SysV::quux ...
I think this is a good idea, but unlikely to happen anytime soon.

Gavin,

I think it's a great idea. Why can't it happen any time soon?
There can be a person or two who could try to sort RAA into appropriate
categories and those people can do this. They don't have to be the
original developers.

Once the current RAA is sorted out, we can ask that authors of additional
modules select an appropriate category for their module.

Your idea allows for a good structuring if RAA without forcing each
contributor to agree to rename their module.

What would be the simplest way to get this into people's computers?
Perhaps an 'aliases.rb' module that people can download? Then the
download page of each module in RAA could have a link to this
'aliases.rb'. Or is this a bad idea?

[Gavin Sinclair]

Post by Daniel Carrera

Post by Gavin Sinclair
IPC::Msg::foo ...
IPC::SysV::quux ...
I think this is a good idea, but unlikely to happen anytime soon.

Gavin,
I think it's a great idea. Why can't it happen any time soon?
There can be a person or two who could try to sort RAA into appropriate
categories and those people can do this. They don't have to be the
original developers.

Well, it's just that it takes a lot of non-core effort for
questionable gain. It's "nice" but not essential. And categorising
things like that is completely non-trivial.

I suppose you could make it easy by just maintaining a single text
file, or perhaps a Ruby hash, describing the mappings, and dynamically
building the modules on startup.

Post by Daniel Carrera
Once the current RAA is sorted out, we can ask that authors of additional
modules select an appropriate category for their module.
Your idea allows for a good structuring if RAA without forcing each
contributor to agree to rename their module.
What would be the simplest way to get this into people's computers?
Perhaps an 'aliases.rb' module that people can download? Then the
download page of each module in RAA could have a link to this
'aliases.rb'. Or is this a bad idea?

I think 'std' (for standardization) is probably a more appropriate
name, and the most appropriate way to 'distribute' it is to maintain a
package of libraries that are referenced. This way people can have a
"standard" set of libraries (sounding like a bad name now - nothing to
do the Ruby "standard library") that can be kept updated with small
patches etc.

That makes the project more worthwhile, because you're sorting the
wheat from the chaff as well as tackling the naming issue.

Gavin

[Warren Brian Noronha]

i dont mind helping u dudes to sort it out

On Sat, 25 Jan 2003 07:00:49 +0900

Post by Gavin Sinclair

Post by Daniel Carrera

Post by Gavin Sinclair
IPC::Msg::foo ...
IPC::SysV::quux ...
I think this is a good idea, but unlikely to happen anytime soon.

Gavin,
I think it's a great idea. Why can't it happen any time soon?
There can be a person or two who could try to sort RAA into appropriate
categories and those people can do this. They don't have to be the
original developers.

Well, it's just that it takes a lot of non-core effort for
questionable gain. It's "nice" but not essential. And categorising
things like that is completely non-trivial.
I suppose you could make it easy by just maintaining a single text
file, or perhaps a Ruby hash, describing the mappings, and dynamically
building the modules on startup.

Post by Daniel Carrera
Once the current RAA is sorted out, we can ask that authors of additional
modules select an appropriate category for their module.
Your idea allows for a good structuring if RAA without forcing each
contributor to agree to rename their module.
What would be the simplest way to get this into people's computers?
Perhaps an 'aliases.rb' module that people can download? Then the
download page of each module in RAA could have a link to this
'aliases.rb'. Or is this a bad idea?

I think 'std' (for standardization) is probably a more appropriate
name, and the most appropriate way to 'distribute' it is to maintain a
package of libraries that are referenced. This way people can have a
"standard" set of libraries (sounding like a bad name now - nothing to
do the Ruby "standard library") that can be kept updated with small
patches etc.
That makes the project more worthwhile, because you're sorting the
wheat from the chaff as well as tackling the naming issue.
Gavin

[Gavin Sinclair]

Well, the first and difficult step is to create a plain text file that
maps hypothetical categorisations to existing libraries. I have no
experience whatsoever to do this.

Are you able to create such a mapping?

Gavin

Post by Warren Brian Noronha
i dont mind helping u dudes to sort it out
On Sat, 25 Jan 2003 07:00:49 +0900

Post by Daniel Carrera

Post by Gavin Sinclair
IPC::Msg::foo ...
IPC::SysV::quux ...
I think this is a good idea, but unlikely to happen anytime soon.

Gavin,
I think it's a great idea. Why can't it happen any time soon?
There can be a person or two who could try to sort RAA into appropriate
categories and those people can do this. They don't have to be the
original developers.

[Peter Kwangjun Suk]

On Fri, 24 Jan 2003 23:10:00 +0900

Post by Warren Brian Noronha
dear devels
it would also be nice to have all the libs assorted like
File/
Filetools.....
......
IO/
Pipe.....
IPC/
Msg
SysV......

In the Smalltalk community, there are a variety of open license libraries which could be ported quite rapidly. (Smalltalk is Homomorphic to a subset of Ruby, so porting is mostly mindless.)

In particular, you Ruby-istas might be interested in many of the things on this page:

<http://www.cincomsmalltalk.com:8080/CincomSmalltalkWiki/VW+GoodiesParc>

You'll have to check on licenses by individual package.

--Peter Kwangjun Suk

(P.S. Someone mentioned cryptographic algorithms. At one time the VisualWorks 5i implementations of some block ciphers (like DES) were running 3% *faster* than RSA Data securities' DLLs in C. Yes, that's right, 3% faster than the same algorithm in C. And these were pure Smalltalk implementions. Just shows what you can do with great generational GC, good design, and a great JIT VM. I happen to be working on running Ruby on Smalltalk VMs.)

[Robert Feldt]

Post by Peter Kwangjun Suk
--Peter Kwangjun Suk
(P.S. Someone mentioned cryptographic algorithms. At one time the
VisualWorks 5i implementations of some block ciphers (like DES) were
running 3% *faster* than RSA Data securities' DLLs in C. Yes, that's
right, 3% faster than the same algorithm in C. And these were pure
Smalltalk implementions. Just shows what you can do with great
generational GC, good design, and a great JIT VM. I happen to be
working on running Ruby on Smalltalk VMs.)

Can you give an update on this project? I remember you described the
general idea some time back but don't remeber the details. I'd love to see
this happen...

Regards,

Robert

[Warren Brian Noronha]

one wish would be to see tvision lib being developed by the original developer or the community. its a amasing and powerfull console ui lib
some one should really help bring it up to speed.

On Sat, 25 Jan 2003 01:11:13 +0900

Post by Peter Kwangjun Suk
On Fri, 24 Jan 2003 23:10:00 +0900

Post by Warren Brian Noronha
dear devels
it would also be nice to have all the libs assorted like
File/
Filetools.....
......
IO/
Pipe.....
IPC/
Msg
SysV......

In the Smalltalk community, there are a variety of open license libraries which could be ported quite rapidly. (Smalltalk is Homomorphic to a subset of Ruby, so porting is mostly mindless.)
<http://www.cincomsmalltalk.com:8080/CincomSmalltalkWiki/VW+GoodiesParc>
You'll have to check on licenses by individual package.
--Peter Kwangjun Suk
(P.S. Someone mentioned cryptographic algorithms. At one time the VisualWorks 5i implementations of some block ciphers (like DES) were running 3% *faster* than RSA Data securities' DLLs in C. Yes, that's right, 3% faster than the same algorithm in C. And these were pure Smalltalk implementions. Just shows what you can do with great generational GC, good design, and a great JIT VM. I happen to be working on running Ruby on Smalltalk VMs.)

[David Garamond]

Post by d***@candle.superlink.net

Post by Simon Cozens

Post by Daniel Carrera
I don't know what Simon thinks, but I really do think that exactly. It
took me a while to find NArray. The only reason why I can find it in RAA
now is because I already know it exists.

Right. I believe there are decent Ruby modules for handling MIME mails;
of course, I can't find them, because they're not sensibly named.

Any package that doesn't turn up on an RAA search for "mime" doesn't
deserve to be found. Even if it's called "marcel", it should have
"mime" in its description.

1) what if i have installed, say, 150 packages from RAA. i forgot which
modules are the mime modules. of course i can search RAA again, or i can
do a "grep -r" on my site_ruby/ directory. but with perl modules i can
do "man -k MIME" or just know that it will be below the MIME/ subdirectory.

2) what if i have several ruby packages tarballs laying around in my
download directory...

3) what if i am looking at someone else's ruby code and see "require
'marcel'", "require 'bobbit'", "require 'hamster'", ...

encoding some metada (esp. the categorical one) into the
namespace/filename itself will make things much easier, much more
predictable, much more organized. take a look at RPM packages for
another example (in this case, an RPM filename include the
architecture/type/version/release metadata).

[d***@candle.superlink.net]

Hi --

Post by David Garamond

Post by d***@candle.superlink.net

Post by Simon Cozens

Post by Daniel Carrera
I don't know what Simon thinks, but I really do think that exactly. It
took me a while to find NArray. The only reason why I can find it in RAA
now is because I already know it exists.

Right. I believe there are decent Ruby modules for handling MIME mails;
of course, I can't find them, because they're not sensibly named.

Any package that doesn't turn up on an RAA search for "mime" doesn't
deserve to be found. Even if it's called "marcel", it should have
"mime" in its description.

1) what if i have installed, say, 150 packages from RAA. i forgot which
modules are the mime modules. of course i can search RAA again, or i can
do a "grep -r" on my site_ruby/ directory. but with perl modules i can
do "man -k MIME" or just know that it will be below the MIME/ subdirectory.

I was talking specifically about searching on RAA, which I thought was
what Simon meant.

I think that somehow my advocacy of the idea of getting "missing"
modules written sooner rather than later (even if naming/hierarchy
issues haven't been worked out yet) has been taken to mean that I
advocate some kind of chaos and non-searchability among Ruby modules.
I don't; I just advocate finding a way that will work, and that can
happen soon, to put an end to the "not enough libraries" rap on Ruby.

Judging from what people have been saying, it's sounding to me like
that process will be a mixture of writing modules and continuing to
make it easier to search RAA on different views.

As for searching on one's system: I think it's a given that it's good
to be able to do very high-level things to get information about
modules, and to retrieve modules. Whether it's man -k or something
else (rpkg -something, or whatever), there's no question that easy
indexing and searching are key.

Post by David Garamond
2) what if i have several ruby packages tarballs laying around in my
download directory...

I guess you'd use a package analyzing utility (of which there are
several in the works, I believe :-) to analyze the contents.

Post by David Garamond
3) what if i am looking at someone else's ruby code and see "require
'marcel'", "require 'bobbit'", "require 'hamster'", ...
encoding some metada (esp. the categorical one) into the
namespace/filename itself will make things much easier, much more
predictable, much more organized. take a look at RPM packages for
another example (in this case, an RPM filename include the
architecture/type/version/release metadata).

My main qualm about this has always been at the last link in each
chain -- that is, the "c.rb" in "a/b/c.rb". One problem is that if
there's one franchise holder for each potential module space, then if
that person's module isn't very good, there are all sorts of problems.
(I'm undiplomatic enough to suggest that this might happen, but would
probably be too diplomatic and/or cowardly to flag it publicly if it
did :-)

Another problem is that more than one person might well write
perfectly useable modules in the same domain, which might differ from
each other in matters of API but each be to some people's taste.
There has to be room for these.

That's why, at the very least, I would advocate naming along the lines
of text/soundex/dbsndx.rb and text/soundex/marcel.rb, rather than
text/soundex.rb.

(I have no problem with the latter style for things in the standard
distribution.)

I admit too that I have a distaste for this kind of categorization,
because it freezes a particular, sometimes unconvincing snapshot of
how the pie is sliced. But I haven't come up with any way to do away
with it entirely.


David

[David Garamond]

Post by d***@candle.superlink.net
My main qualm about this has always been at the last link in each
chain -- that is, the "c.rb" in "a/b/c.rb". One problem is that if
there's one franchise holder for each potential module space, then if
that person's module isn't very good, there are all sorts of problems.
(I'm undiplomatic enough to suggest that this might happen, but would
probably be too diplomatic and/or cowardly to flag it publicly if it
did :-)

well, in the CPAN world, a/b indicates category. no single person
control this so there is room for everybody. you just have to name your
module sensibly, and if someone else has already taken that name, find
another sensible one. it's usually not that crowded enough that this
system works fine until today.

take for instance the Mail:: namespace:

http://www.cpan.org/modules/by-module/Mail/

as you can see, there are many many mail-related modules, some overlap
in functionality. for parsing mbox there's Mail::MboxParser,
Mail::Folder::Mbox, and probably several others that i haven't checked
out. they seem to live quite happily together and no one seems to occupy
or take hold of the namespace in a way that makes people think that
there is only one obvious mbox parsing module.

the good thing about this is that, since there are many choices for a
particular task, two things might happen:

1) natural selection, survival of the fittest;

2) one or more people will initiate an effort to make a superset/general
module (e.g. Mail::Box). the resulting module might be good or bad, but
in the specific case of Mail::Box, the author tries hard to merge all
the good things from all the other existing modules and tries to do
things better. it seems, so far so good.

Post by d***@candle.superlink.net
Another problem is that more than one person might well write
perfectly useable modules in the same domain, which might differ from
each other in matters of API but each be to some people's taste.
There has to be room for these.

yes, there always is.

Post by d***@candle.superlink.net
That's why, at the very least, I would advocate naming along the lines
of text/soundex/dbsndx.rb and text/soundex/marcel.rb, rather than
text/soundex.rb.

yes, fine with me too. at least the "text/soundex" part is there. in
CPAN there is the ***@perl.org mailing list where people discuss
these issues. i believe there are some cases where a proposed module
name/namespace is too general and others recommended another name.

we can also enforce this, if desired. say the first and second level of
the namespace is reserved for category only.

Post by d***@candle.superlink.net
(I have no problem with the latter style for things in the standard
distribution.)
I admit too that I have a distaste for this kind of categorization,
because it freezes a particular, sometimes unconvincing snapshot of
how the pie is sliced. But I haven't come up with any way to do away
with it entirely.

well, if there are 1000+ public modules out there (and we like that to
happen for ruby right?), people will sooner or later tend to organize
the namespace anyway. it's nice to have one standardized way to do this.
on the other hand, organizing the namespace _will_ encourage people to
submit their modules into the community (as is the case with CPAN). so i
see it as a win-win situation.

[d***@candle.superlink.net]

Hi --

[I wrote:]

Post by d***@candle.superlink.net
I admit too that I have a distaste for this kind of categorization,
because it freezes a particular, sometimes unconvincing snapshot of
how the pie is sliced. But I haven't come up with any way to do away
with it entirely.

well, if there are 1000+ public modules out there (and we like that to
happen for ruby right?),

I certainly do -- I even started a thread trying to encourage it :-)

people will sooner or later tend to organize the namespace
anyway. it's nice to have one standardized way to do this. on the
other hand, organizing the namespace _will_ encourage people to
submit their modules into the community (as is the case with
CPAN). so i see it as a win-win situation.

I have to say, I think that lack of community encouragement to submit
modules is definitely not part of the problem here. RAA is actually
quite active, and there's lots of encouragement, explicit and
otherwise, to share code there. It's interesting in this connection
that a number of people feel that the problem revolves more around
searching and retrieval than around missing modules.

As for categories: it's probably a somewhat abstract point, but I've
always wondered whether decisions to group certain things together has
an effect on how people perceive the possibilities of software usage.
For example, an archive might have an XML section, but no SGML
section.... and it might have a Text section that's unconnected to
the XML section, and so forth. In the end, I suppose one has to bite
the bullet and go with the familiar "AI, Algorithms, Benchmark,
Calendar...."-style view, but I'm intrigued by the possibility of
dynamic, equally (but differently) stratified views.

Of course this is purely an archive-searching thing. On one's system,
a given module has to go somewhere specific.

ANYWAY... in order to live up to my own goal of not getting embroiled
in discussions about naming at the expense of writing modules, I
really should go look at Hal's list and choose a module! :-)


David

[Tom Sawyer]

not to get on the name issue, but the easy solution is to have a very-brief
description field along with the name, hence:

Package Name Descriptor
Rouge Lisp Interpretor

tom sawyer, aka transami
***@transami.net


.''.
.''. . *''* :_\/_: .
:_\/_: _\(/_ .:.*_\/_* : /\ : .'.:.'.
.''.: /\ : ./)\ ':'* /\ * : '..'. -=:o:=-
:_\/_:'.:::. | ' *''* * '.\'/.' _\(/_'.':'.'
: /\ : ::::: = *_\/_* -= o =- /)\ ' *
'..' ':::' === * /\ * .'/.\'. '._____
* | *..* : |. |' .---"|
* | _ .--'| || | _| |
* | .-'| __ | | | || |
.-----. | |' | || | | | | | || |
___' ' /"\ | '-."". '-' '-.' '` |_.
------------------------------------------------------------

[Wai-Sun Chia]

I agree exactly.
Let the author choose whatever's the name which he/she like, regardless
whether it's a program or a library (if you can't even name your own
baby, that takes the fun out of a lot of things, right?)

Just need a bunch of meta-data, which gets indexed, sorted and stored.
Users can then search for name (which can be very "cutesy"), category
(e.g. graphics, application, library, etc.), function, description, etc.

Post by Tom Sawyer
not to get on the name issue, but the easy solution is to have a very-brief
Package Name Descriptor
Rouge Lisp Interpretor
tom sawyer, aka transami
.''.
.''. . *''* :_\/_: .
:_\/_: _\(/_ .:.*_\/_* : /\ : .'.:.'.
.''.: /\ : ./)\ ':'* /\ * : '..'. -=:o:=-
:_\/_:'.:::. | ' *''* * '.\'/.' _\(/_'.':'.'
: /\ : ::::: = *_\/_* -= o =- /)\ ' *
'..' ':::' === * /\ * .'/.\'. '._____
* | *..* : |. |' .---"|
* | _ .--'| || | _| |
* | .-'| __ | | | || |
.-----. | |' | || | | | | | || |
___' ' /"\ | '-."". '-' '-.' '` |_.
------------------------------------------------------------

[Rich]

What happens when the RAA goes down??

I've always wanted to apply the principles of Napster/Kazaa-like
availability to code libraries/depots.

Concept::

1. Everyone has a 'server' that they run on the computer that holds the
source they want publicised.

2. Each folder on the 'serving' computer would act as a new 'namespace'...
all folders under my RAA 'login'...

3. When I want some extra functionality, I open an interface on my computer
to this distributed network, and search or browse until I find what I need.

Extraneous things like naming conventions will be 'isolated' within each
'distributed server' run on each computer. Ruby won't 'look' bad because of
naming problems... and those with ~issues~ of conformance would fall by the
wayside, since no one would want their code.

my code could be referenced ....


http://www.ruby-lang.org/en/raa.rb?richardLyman.internet.html.linkValidator.
rb

Anyway... I normally get ignored, but I thought I'd put it out... ;-)

-Rich

[Iain 'Spoon' Truskett]

Post by Rich
What happens when the RAA goes down??
I've always wanted to apply the principles of Napster/Kazaa-like
availability to code libraries/depots.
1. Everyone has a 'server' that they run on the computer that holds
the source they want publicised.

The real idea is that RAA or whatever has mirrors.

Were you to go down a p2p path, I'd recommend a Freenet variant. That
way each node holds more than just what it's owner is actively sharing.

Complete mirrors are nicer though. More concrete and it means I can just
rsync (or equiv) a local mirror =)


cheers,

[MikkelFJ]

Post by d***@candle.superlink.net

Post by Simon Cozens
Please, let's not forget lessons we learnt - even today: someone was
asking for a Ruby Lisp interpreter. Now, what would that be called?
Language::LISP? Scheme.rb? No, of course, it was given the eminently
sensible name of Rouge, from which one could determine, well,
absolutely nothing at all, except that it might have something to do
with makeup. Naming is important!

Yes, but what if there are five Lisp interpreters? And what if some
of them are better than others? Same for SGML parsers, etc. Somehow

We have seen this with Test::Unit which as I understand is a merger of two
earlier modules.
I think a module should be codenamed whatever - and at some point it may or
may not be integrated into a core language module where it would be given a
more clinical name - like Test::Unit.

That said, too many modules have too weird codenames - I stil have
difficulties remembering what Amrita and O... ehh O... you know the
framework that is also known as SeaSide for Smalltalk ... Really my brain
doesn't work that way.

One could codename modules like "Green Lisp" to distinguish it from a
potential future "Blue Lisp", yet I would instantly know it was a Lisp
module.

Mikkel

[ahoward]

Post by MikkelFJ
One could codename modules like "Green Lisp" to distinguish it from a
potential future "Blue Lisp", yet I would instantly know it was a Lisp
module.

i think all branches in the naming tree should be 'well accepted' (perhaps
even voted on) leaving the author to name the leaves, eg:

Language::LISP::Blue
Language::LISP::Green
HTML::Template::Amrita

etc.

best of both worlds.

-a
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ***@fsl.noaa.gov
| Phone: [phone]
| Fax: [phone]
====================================

[Mark Wilson]

The following is my initial, and not yet complete, proposal on
categories for the libraries section of the RAA. It is based on CPAN,
with some modifications.


Bundles

Business
e-commerce
finance

Compression

Data Structures and Manipulation
Algorithm
Array
Binary
Enumerable
Graph
Hash
Math
Queue
Stack
Time
Tree

Database
MySQL
Postgresql

Development Support
Benchmark
CVS
Debugging
Design Patterns
Integrated Development Environment
Testing

Internationalization
I18N

Mail and Usenet News

Media
Audio
Graphics
Icons
MIDI
Mp3
Speech

Networking
Distributed Computing

Operating System Interfaces
Be
BSD
Dos
Linux
Mac
Solaris
Windows

Science
Biology
Computer Science
AI
Languages
C
Forth
Lisp
Lua
Python
Physics
Chemistry

Security
Cryptography

[String, Language, Text] Processing
PDF
regular expressions
yaml

User Interfaces
Fox
Gtk
Qt
Text (curses, etc.?)
Tk
Wx
X Windows

World Wide Web
CGI
Jabber

As an additional note, some of the items in the current RAA
applications category probably belong in the libraries category (yaml
is one example).

[Iain 'Spoon' Truskett]

Post by Mark Wilson
The following is my initial, and not yet complete, proposal on
categories for the libraries section of the RAA. It is based on CPAN,
with some modifications.
Mail and Usenet News
Networking
Distributed Computing
World Wide Web
CGI
Jabber

Um, why is Jabber in WWW?

For reference, where would ssh, telnet, ICQ and IRC libraries end up?



cheers,

[Mark Wilson]

[snip] Um, why is Jabber in WWW?
For reference, where would ssh, telnet, ICQ and IRC libraries end up?
[snip]

CPAN puts Jabber stuff under WWW. But if that's silly, it shouldn't be
copied. ssh, telnet, icq and irc libraries should probably go under
'networking and www' -- especially if that's where you would expect to
find them.

[Piers Harding]

Well - Jabber is out with the IETF, in an attempt to get it to become a
bonifide Internet Protocol and standard, so it should live with other
internet protocols probably - such as http-access, etc ?

Cheers.

Post by Mark Wilson

[snip] Um, why is Jabber in WWW?
For reference, where would ssh, telnet, ICQ and IRC libraries end up?
[snip]

CPAN puts Jabber stuff under WWW. But if that's silly, it shouldn't be
copied. ssh, telnet, icq and irc libraries should probably go under
'networking and www' -- especially if that's where you would expect to
find them.

[Iain 'Spoon' Truskett]

[snip] Um, why is Jabber in WWW?
For reference, where would ssh, telnet, ICQ and IRC libraries end up?
[snip]

CPAN puts Jabber stuff under WWW. But if that's silly, it shouldn't be
copied.

Ah. I think it's because Net::Jabber can operate via http. Or something.
You'll also find Net::Jabber under the general network header.

ssh, telnet, icq and irc libraries should probably go under
'networking and www' -- especially if that's where you would expect to
find them.

I'd be tempted to divide up networking and www. WWW is large enough to
be a category on its own. Much like you had Mail/News separate.



cheers,

[Dave Thomas]

Post by Iain 'Spoon' Truskett

CPAN puts Jabber stuff under WWW. But if that's silly, it shouldn't be
copied.

Ah. I think it's because Net::Jabber can operate via http. Or something.
You'll also find Net::Jabber under the general network header.

ssh, telnet, icq and irc libraries should probably go under
'networking and www' -- especially if that's where you would expect to
find them.

I'd be tempted to divide up networking and www. WWW is large enough to
be a category on its own. Much like you had Mail/News separate.

Folks:

I think there's a hint here. The real world isn't hierarchical. Why are
we assuming the archive should be?

Dave

[Wai-Sun Chia]

Post by Simon Cozens
Please, let's not forget lessons we learnt - even today: someone was
asking for a Ruby Lisp interpreter. Now, what would that be called?
Language::LISP? Scheme.rb? No, of course, it was given the eminently
sensible name of Rouge, from which one could determine, well,
absolutely nothing at all, except that it might have something to do
with makeup. Naming is important!

But then, what the heck is a "mozilla" anyway? Is it some sort of a
Japanese monster?
Or a "gnumeric"? Huh?
Or a "squid"? Seafood?

My point is, software are like indviduals. If our parents named us with
names that describe our ethnicity, origin, and functions, then I'll be
called "Chinese dude who doesn't live in China, and likes to program in
Ruby".

My dual-cents, of course.

[Yukihiro Matsumoto]

Hi,

In message "Re: Can we attack the 'not enough libraries' thing straight on?"
on 03/01/23, Wai-Sun Chia <***@hp.com> writes:

|But then, what the heck is a "mozilla" anyway? Is it some sort of a
|Japanese monster?
|Or a "gnumeric"? Huh?
|Or a "squid"? Seafood?

Or a "Ruby"? Gem? ;-)

Libraries and programs have different naming requirement. I think
Simon was referring library naming convention.

matz.

[Simon Cozens]

Post by Yukihiro Matsumoto
Libraries and programs have different naming requirement. I think
Simon was referring library naming convention.

Precisely. It's all covered in
http://www.oreillynet.com/cs/weblog/view/wlg/2225

Programs should have attractive names; libraries should have functional
names.

[Tanaka Akira]

Post by Simon Cozens
Programs should have attractive names; libraries should have functional
names.

Rouge is a program. Maybe Amrita is a better example?

[Daniel Carrera]

Post by d***@candle.superlink.net
So, all you almost-satisfied Ruby programmers, what's missing? :-)

<disclaimer>These are opinions. Other people might disagree</disclaimer>

1) Find a more accessible domain name. www.ruby-lang.org/raa is not as
easy to remember as www.cpan.org. Unfortunatelly
(ruby|cran|raa).(org|net) are all taken.

2) I agree with the idea of naming conventions.

3) RAA is hard to browse. I think that a setup of the style of
www.search.cpan.org is best.

Post by d***@candle.superlink.net
Hi --
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."
I'm not saying it's not true... but I'm getting worried that we're
settling into a culture where Ruby is "that great language that
doesn't have the equivalent of CPAN," and that as that reputation
spreads, it's going to be harder to shake it off later -- even when
lots more modules have been written.
So: is there a process by which we can identify *exactly* what all the
missing modules are? And then write them? :-)
The role of CPAN in all this needs to be kept in perspective. There's
no obligation on [the] Ruby[ community]'s part to duplicate CPAN
module by module. In fact, it's quite interesting to look at other
archives, such as <http://www.haskell.org/libraries>.
Also, I would advocate not getting embroiled in issues of naming,
specifically hierarchical module naming (text/soundex,
algorithms/sort/qsort, etc.). The main thing is for software to come
into existence, and for its availability to be publicized. If we try
to work out in advance questions like who gets to write the
authoritative x/y/z module, etc., the chances are fairly good that
nothing will ever get done.
So, all you almost-satisfied Ruby programmers, what's missing? :-)
David
--
David Alan Black
Web: http://pirate.shu.edu/~blackdav

[Dossy]

Post by Daniel Carrera
3) RAA is hard to browse. I think that a setup of the style of
www.search.cpan.org is best.

I've been thinking (okay, dreaming) of a small snippet of Ruby code that
could turn the interactive Ruby shell (irb) into a RAA browser, much
like CPAN.pm for Perl. I imagined:

$ irb
irb(main):001:0> require 'raa'
true

irb(main):002:0> raa.install 'Foo::Bar'
...fetches the Foo::Bar module from RAA...
...installs it using setup.rb or whatever...

irb(main):002:0> raa.updates
...displays a list of currently installed modules, their versions, and
the latest version available according to RAA...

You get the idea. Is this attractive to anyone? Hasn't this been
/done/ already?

Using irb seems right to me -- leverage readline support if irb has it,
etc.

-- Dossy

[Daniel Carrera]

Post by Dossy
$ irb
irb(main):001:0> require 'raa'
true
irb(main):002:0> raa.install 'Foo::Bar'
...fetches the Foo::Bar module from RAA...
...installs it using setup.rb or whatever...
irb(main):002:0> raa.updates
...displays a list of currently installed modules, their versions, and
the latest version available according to RAA...
You get the idea. Is this attractive to anyone? Hasn't this been
/done/ already?

I think that's a great idea. I don't know if it's been done.

[why the lucky stiff]

Post by Dossy
I've been thinking (okay, dreaming) of a small snippet of Ruby code that
could turn the interactive Ruby shell (irb) into a RAA browser, much
$ irb
irb(main):001:0> require 'raa'
true

require 'raainstall'

=> true

Post by Dossy
irb(main):002:0> raa.install 'Foo::Bar'
...fetches the Foo::Bar module from RAA...
...installs it using setup.rb or whatever...

RAAInstall.install( 'yaml' )

Unarchiving yamlrb-0.49.tar.gz with gnu tar
yamlrb-0.49/
yamlrb-0.49/samples/
yamlrb-0.49/samples/okayRpc-client.rb
yamlrb-0.49/samples/okayRpc-server.rb
yamlrb-0.49/samples/okayNews-validate.rb
...and so on..
=> [#<RAAInstall::Package:0x40260cc8 @depends=[], @require=nil,
@versionModule=nil,
@download_url="http://prdownloads.sourceforge.net/yaml4r/yamlrb-0.49.tar.gz",
@version=[0, 49], @appId=nil>]

Post by Dossy
irb(main):002:0> raa.updates
...displays a list of currently installed modules, their versions, and
the latest version available according to RAA...

RAAInstall.showall

=> ["acl", "activeattr", "aes-rb", "aiura", ... ]

So the last one isn't exactly what you requested.. so.. come on over to
the raa-install list and tell us what you want!
[http://lists.sourceforge.net/lists/listinfo/narf-lib-raainstall]

More on the raa-install API itself at
[http://www.rubygarden.org/ruby?QuickGuideToRaaInstall]

_why

[NAKAMURA, Hiroshi]

Hi,

Sent: Thursday, January 23, 2003 11:21 AM
<disclaimer>These are opinions. Other people might disagree</disclaimer>

For me as well.

1) Find a more accessible domain name. www.ruby-lang.org/raa is not as
easy to remember as www.cpan.org. Unfortunatelly
(ruby|cran|raa).(org|net) are all taken.

How do you feel raa.ruby-lang.org ?

3) RAA is hard to browse. I think that a setup of the style of
www.search.cpan.org is best.

I don't use CPAN modules so I seldom use CPAN search...

What is the most significant point of all the features which
CPAN search have and RAA don't have, do you think? We'll
change it better and better untill RAA.succ comes.

Regards,
// NaHi

[Gavin Sinclair]

Post by NAKAMURA, Hiroshi

Post by Daniel Carrera
1) Find a more accessible domain name. www.ruby-lang.org/raa is not as
easy to remember as www.cpan.org. Unfortunatelly
(ruby|cran|raa).(org|net) are all taken.

How do you feel raa.ruby-lang.org ?

It's logical and compelling.

Post by NAKAMURA, Hiroshi

Post by Daniel Carrera
3) RAA is hard to browse. I think that a setup of the style of
www.search.cpan.org is best.

I don't use CPAN modules so I seldom use CPAN search...
What is the most significant point of all the features which
CPAN search have and RAA don't have, do you think? We'll
change it better and better untill RAA.succ comes.

I never use it, but in order to justify this "me too"-ish post, I did
my bit and tried to answer your question anyway :)

search.cpan.org provides the following features:

1. Clear enumeration of categories up front

In contrast to RAA's very hierachical structure, CPAN seems to be
organised around 26 categories. When I used to use it, I actually
found it confusing, as I roughly knew what I was looking for, but
couldn't decide which of 2 or 3 categories was the most logical place
to find it. So I used it for browsing, but was never convinced that
it all made sense.

2. Search options (search in modules, distros, or authors, or all)

Pretty straightforward really. RAA's not so big that it needs this.
Search all works fine.

3. Browse by author

Good idea, but annoyingly over-hypertext. I want to browse all
authors on one page, with an index up the top using anchors. This
forces you onto a different page for each author.

I'd like this feature in RAA.

4. Recent updates

Browse the last 7 days of "uploads". I hate arbitrary limits - why
not allow you to go further back. But it's good anyway.

RAA should allow you to view "recent updates" separately from "recent
additions", but I've carped on about that enough and you've agreed to
support it in future. \(^o^)/

5. About/Mirrors/Feedback

Various meta-information/services.

6. FAQ

RAA should have one, including plans for future updates.


So I dug into a search to see what functionality I could find. I
searched for MIDI in Modules and got 33 results. (MIDI in all got 413
or something. Go figure.)

Good feature: change the number of entries per page. The output is
nice and neat; RAA could take an example here.

Bad feature: it's not well organised. Several results seem related.
They are not all top-level modules; some are bits of modules, or
something. E.g. MIDI, MIDI::Event, MIDI::Opus, MIDI::Score and more
(all by the same author) are separate search results! So much for the
33 different MIDI modules I expected!


That concludes my tour of search.cpan.org. I don't see any killer
feature in it that puts any daylight between it and RAA, just a more
professional look and a few little things. I've said it before, but
the last major update to RAA was a quantum leap, and the whole
community applauds your efforts (^^)// so the pace of improvement is
already very good.

Cheers,
Gavin

PS. See http://club.pep.ne.jp/~hiroette/en/facemarks/index.html for
the great Japanese smileys!

[Daniel P. Zepeda]

Getting back to the original poster's question, "what is not available?",
I grepped through my Perl sources for 'use' to find what modules I'd be
missing if I had
to write any of that over again:

What I found was that the "missing" things fell into 4 basic categories

1. Things that Ruby already has in the core, or that
Ruby's design obviates the need for, which Perl needed a
module to add the functionality
2. Things I wrote myself that were project-specific
3. Things that are not a big deal, could probably code up in less
than an hour
4. Truly missing needed functionality

In the not-a-big-deal category:

User::grent
User::pwent -- Password a group utilities. Admittedly, not a big deal,
searched for 'password'
Proc::killall - kills off a process by name, searched for 'process' and
'killall'

In the truly missing category:

Net::DNS - A DNS interface, to create and process query packets
- searched for 'DNS'
CPAN

There *was* a last category in my mind, things that I didn't know
about and was pleasantly surprised to find:

SNMP - an interface to UCD SNMP

and

sablot - an interface to the ginger alliance's XLST engine.


Of those things I say are missing, I did search RAA and the Pickaxe class
and
standard library guides, for the obvious keyword with no results.


I find it telling that the OP asked for what pieces were missing, but the
discussion tended to naming conventions and module management. There *is*
a ton of stuff on CPAN, but a lot of it is not needed, because Ruby
obviates
the need for it, and of course, my list is not exhaustive, just my
experiences.
Maybe after all the discussion is done, we'll find that CPAN is huge
because
it has to be, to add stuff to Perl that Ruby already has, and that the
small
size of Ruby doesn't show the lack of available functionality, but the
power
of the core Ruby.

[NAKAMURA, Hiroshi]

Hi, Daniel,

Sent: Saturday, January 25, 2003 2:47 AM
sablot - an interface to the ginger alliance's XLST engine.

Do you see
http://www.ruby-lang.org/raa/search.rhtml?search=sablot ?
Isn't it what you want? Though I once saw its author
blogged that it's not completed yet...

Regards,
// NaHi

[Daniel P. Zepeda]

On Sat, 25 Jan 2003 13:34:25 +0900

Post by NAKAMURA, Hiroshi
Hi, Daniel,

Sent: Saturday, January 25, 2003 2:47 AM
sablot - an interface to the ginger alliance's XLST engine.

Do you see
http://www.ruby-lang.org/raa/search.rhtml?search=sablot ?
Isn't it what you want? Though I once saw its author
blogged that it's not completed yet...

No, No, you misunderstood, sablot and the interface to UCD-SNMP were
things I *found* that I didn't know about already, and was just pleased
that they were already there! It was bad to include those last two in the
same post, others were confused too.

Using sablotron with XML is a great abstraction tool for doing Web work,
among other things, so I like using it. When I was searching through RAA
and the Pickaxe for all the Perl modules I use, I was so delighted to find
a Ruby interface to sablotron that I added those to say: "Oooh, these are
here, I'm delighted."

Post by NAKAMURA, Hiroshi
Regards,
// NaHi

[NAKAMURA, Hiroshi]

Hi, Daniel,

Sent: Saturday, January 25, 2003 1:48 PM

Post by NAKAMURA, Hiroshi

Post by Daniel P. Zepeda
sablot - an interface to the ginger alliance's XLST engine.

Do you see
http://www.ruby-lang.org/raa/search.rhtml?search=sablot ?
Isn't it what you want? Though I once saw its author
blogged that it's not completed yet...

No, No, you misunderstood, sablot and the interface to UCD-SNMP were
things I *found* that I didn't know about already, and was just pleased
that they were already there! It was bad to include those last two in the
same post, others were confused too.

Oops. I'm very sorry for bothering you with the post.
I should be careful when hacking/reading a language...

Regards,
// NaHi

[Gabriel Emerson]

This only takes into account the web site for CPAN... the real power is in
perl -MCPAN -eshell...

Post by Gavin Sinclair
That concludes my tour of search.cpan.org. I don't see any killer
feature in it that puts any daylight between it and RAA, just a more
professional look and a few little things. I've said it before, but
the last major update to RAA was a quantum leap, and the whole
community applauds your efforts (^^)// so the pace of improvement is
already very good.

[NAKAMURA, Hiroshi]

Hi, Gavin and Daniel,

Sent: Saturday, January 25, 2003 12:25 AM

Post by NAKAMURA, Hiroshi

Post by Daniel Carrera
1) Find a more accessible domain name. www.ruby-lang.org/raa is not as
easy to remember as www.cpan.org. Unfortunatelly
(ruby|cran|raa).(org|net) are all taken.

How do you feel raa.ruby-lang.org ?

It's logical and compelling.

We ruby-lang.org admins are talking about its possibility.

Post by NAKAMURA, Hiroshi

Post by Daniel Carrera
3) RAA is hard to browse. I think that a setup of the style of
www.search.cpan.org is best.

I don't use CPAN modules so I seldom use CPAN search...
What is the most significant point of all the features which
CPAN search have and RAA don't have, do you think? We'll
change it better and better untill RAA.succ comes.

I never use it, but in order to justify this "me too"-ish post, I did
my bit and tried to answer your question anyway :)

Thank you for your great summary. Much help us.

1. Clear enumeration of categories up front
In contrast to RAA's very hierachical structure, CPAN seems to be
organised around 26 categories. When I used to use it, I actually
found it confusing, as I roughly knew what I was looking for, but
couldn't decide which of 2 or 3 categories was the most logical place
to find it. So I used it for browsing, but was never convinced that
it all made sense.

Sure. CPAN seems to have many(26) top categories, compared
with RAA has only 4 top categories. But from another point;
CPAN top categories are for library, right? RAA library section
has 86 subcategories now.
http://www.ruby-lang.org/raa/cat.rhtml?category_major=Library

Hmm. Should RAA have independent library (metadata) archive
such as RLA: Ruby Library Archive?

Too few prepared category(4: Doc, Ports, App, and Lib) and
too much author opened free category(86 for Lib, now) are
exactly a big problem of RAA. But continuous categorizing
(not only at once, continuously) is much more than one or two
person do.

2. Search options (search in modules, distros, or authors, or all)
Pretty straightforward really. RAA's not so big that it needs this.
Search all works fine.

Sure. It's on our ToDo so you'll see in the future.

3. Browse by author
Good idea, but annoyingly over-hypertext. I want to browse all
authors on one page, with an index up the top using anchors. This
forces you onto a different page for each author.
I'd like this feature in RAA.

http://www.ruby-lang.org/raa/owners.html
and
http://www.ruby-lang.org/raa/owner.rhtml?id=8
We already have a pae for each owner?
Do you mean that the owner listing page might be simplified?

4. Recent updates
Browse the last 7 days of "uploads". I hate arbitrary limits - why
not allow you to go further back. But it's good anyway.

For now, please use YARAA: http://ruby.yi.org/raa/ .
Metadata is replicated via SOAP between RAA(master) and
YARAA(replica). YARAA developed features will be integrated
to RAA in the future.

RAA should allow you to view "recent updates" separately from "recent
additions", but I've carped on about that enough and you've agreed to
support it in future. \(^o^)/

Yeah. I hope you'll see in this month.

5. About/Mirrors/Feedback
Various meta-information/services.
6. FAQ
RAA should have one, including plans for future updates.

I like those to have.

So I dug into a search to see what functionality I could find. I
searched for MIDI in Modules and got 33 results. (MIDI in all got 413
or something. Go figure.)
Good feature: change the number of entries per page. The output is
nice and neat; RAA could take an example here.

Sure. I pushed it the ToDo list.

That concludes my tour of search.cpan.org. I don't see any killer
feature in it that puts any daylight between it and RAA, just a more
professional look and a few little things. I've said it before, but
the last major update to RAA was a quantum leap, and the whole
community applauds your efforts (^^)// so the pace of improvement is
already very good.

Again, many thanks for your survey. I'll try to reflect your
suggestions.

PS. See http://club.pep.ne.jp/~hiroette/en/facemarks/index.html for
the great Japanese smileys!

I didn't know the site. Good explanation. \(^-^)/

Regards,
// NaHi

[Gavin Sinclair]

Post by NAKAMURA, Hiroshi

Post by Gavin Sinclair
3. Browse by author
Good idea, but annoyingly over-hypertext. I want to browse all
authors on one page, with an index up the top using anchors. This
forces you onto a different page for each author.
I'd like this feature in RAA.

http://www.ruby-lang.org/raa/owners.html
and
http://www.ruby-lang.org/raa/owner.rhtml?id=8
We already have a pae for each owner?
Do you mean that the owner listing page might be simplified?

No, I saw that RAA had it just recently, and it's better than the CPAN
version. No simplification necessary.

Gavin

[j***@ruby-doc.org]

Post by NAKAMURA, Hiroshi
What is the most significant point of all the features which
CPAN search have and RAA don't have, do you think? We'll
change it better and better untill RAA.succ comes.

Um, on CPAN, module authors seem to write better descriptions of their code. Very frustrating to go to RAA, and see:

Name Short Description
SomeNonDescriptiveName SomeNonDescriptiveName



Can't search what isn't there.


James

Post by NAKAMURA, Hiroshi
Regards,
// NaHi

[NAKAMURA, Hiroshi]

Hi,

Sent: Saturday, January 25, 2003 1:10 AM

Post by NAKAMURA, Hiroshi
What is the most significant point of all the features which
CPAN search have and RAA don't have, do you think? We'll
change it better and better untill RAA.succ comes.

Name Short Description
SomeNonDescriptiveName SomeNonDescriptiveName

As you may know, it's from historical reason.
"Short Description" field is added in Oct. 2002 and we RAA
maintainer only filled it with its name.

I hope owners to change "short description" to describe their
project more clearly.

Regards,
// NaHi

[Daniel Carrera]

Post by NAKAMURA, Hiroshi

Post by Daniel Carrera
1) Find a more accessible domain name. www.ruby-lang.org/raa is not as
easy to remember as www.cpan.org. Unfortunatelly
(ruby|cran|raa).(org|net) are all taken.

How do you feel raa.ruby-lang.org ?

Sounds great. I like it.

Post by NAKAMURA, Hiroshi

Post by Daniel Carrera
3) RAA is hard to browse. I think that a setup of the style of
www.search.cpan.org is best.

I don't use CPAN modules so I seldom use CPAN search...
What is the most significant point of all the features which
CPAN search have and RAA don't have, do you think? We'll
change it better and better untill RAA.succ comes.

In Gavin's response, points 1., 2., and 4. are essentially what I had in
mind. I think they would make a big difference. I liked all his other
points as well.

[Matt Armstrong]

Post by d***@candle.superlink.net
So: is there a process by which we can identify *exactly* what all
the missing modules are? And then write them? :-)

Yes: time and patience.

In fact, I think we are attacking the 'not enough libraries' thing
straight on -- or as straight on as possible given the volunteer and
highly organic nature of this kind of effort.

I have to assume that the same process that has happened with Perl and
Python will happen with Ruby. As it matures, more and more quality
modules will come into existence.

Post by d***@candle.superlink.net
So, all you almost-satisfied Ruby programmers, what's missing? :-)

As a completely-satisfied Ruby programmer, I don't find much lacking.
:-)

[Piers Harding]

OK.

Having just been thru the exercise of translating a major Perl module
(SAP::Rfc) to Ruby, I noticed a number of things that I found self
saying "I wish Ruby had this".

Firstly - you cannot ignore the power of CPAN (or equivalently well
organised software archives). CPAN (INMHO) is the root of the power of
Perl. To put it in Borg terms - it is the collective conciousness of
the Perl community, its works/achievements, and standardisation efforts.

When developing the module - there was no ONE set of modules that
defined/generated the install process, managing the documentation, and
enforcing a common set of standards. With Perl - it is a very powerfull
thing that a user can download a module (XXX::YYY) and know almost 100%
guaranteed that all they have to do is go: perl Makefile.PL && make test
&& make install; and then go perldoc XXX::YYY, and they are off and
racing. CPAN, and the gate-keepers of CPAN are instrumental in ensuring
this high standard of consistancy, that is such a winning formula (ok -
sure there are some warts, but it is still highly successful). All my
Perl modules that are uploaded to CPAN run thru a simple set of checks
to ensure that they have a certain set of things defined. There is even
a "smokehouse" system where by new modules/versions that are uploaded
are built, and checked for consistency (does it have the correct
documentation elements README, Changes, MANIFEST, perldoc etc.), and
whether they just plain work at all (ie. have a test suite, and whether
the test suite runs).

As mentioned elsewhere on this thread - the CPAN shell is missing. It
is not so much that the shell is missing, it is that it would not be
possible to have a successful "CPAN shell" for Ruby, because of the lack
of (some may say rigid) standards for publishing modules. The shell
works because there is a workable lowest common denominator of standards
to work with - as described above.

I think that in order to step up to the next level, Ruby will have to
address these issues, for the good of the Ruby community - without it -
how would an archive of many thousands of contributions thrive, without
creating needless duplication of effort, and keeping the barrier to
entry for new commers as low as possible?

Cheers.

Post by d***@candle.superlink.net
Hi --
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."
I'm not saying it's not true... but I'm getting worried that we're
settling into a culture where Ruby is "that great language that
doesn't have the equivalent of CPAN," and that as that reputation
spreads, it's going to be harder to shake it off later -- even when
lots more modules have been written.
So: is there a process by which we can identify *exactly* what all the
missing modules are? And then write them? :-)
The role of CPAN in all this needs to be kept in perspective. There's
no obligation on [the] Ruby[ community]'s part to duplicate CPAN
module by module. In fact, it's quite interesting to look at other
archives, such as <http://www.haskell.org/libraries>.
Also, I would advocate not getting embroiled in issues of naming,
specifically hierarchical module naming (text/soundex,
algorithms/sort/qsort, etc.). The main thing is for software to come
into existence, and for its availability to be publicized. If we try
to work out in advance questions like who gets to write the
authoritative x/y/z module, etc., the chances are fairly good that
nothing will ever get done.
So, all you almost-satisfied Ruby programmers, what's missing? :-)
David
--
David Alan Black
Web: http://pirate.shu.edu/~blackdav

[Berger, Daniel]

Post by ahoward

Post by ahoward
this is one idea CPAN lacks - a central set of standards

which modules

Post by ahoward
must conform to (unit testing for modules?) and a way to

separte the

Post by ahoward
really good modules from all the chatter and useless crap...

Good ideas. It's great to have a repository that anybody can
contribute to, and we do need to be able know which ones are
well implemented and supported. I wish someone who has used
a lot of packages (i.e. not me) would write a summary of
packages they think are ready for the big time. Also along
these lines, I believe the RAA should mandate a standard for
versioning. Everything should be versioned x.y.z, with
perhaps some allowance for alpha, beta, whatever. Version
numbers based on dates or descriptions are not particularly
informative.
- packages have a doc directory
- this gets installed along with the package so it ends up in
something like
site_ruby/1.6/froboz/doc/package.info
/index.html
- it can therefore be determined which packages have been installed
and have documentation installed
This allows different programs to programatically access all
package documentation. The particular program I have in mind
might be called 'rdb' (for Ruby Documentation Browser) and
- build a list of all installed package doco (using package.info for
description etc.)
- generate an HTML page containing links to all available package
doco (the index.html files, which represent RDoc output and
contain the README etc. as well as the API doc)
- open a browser to that page
There you have it. One command to access all of your
available package documentation. Of course it can take an
argument so you can access a particular package doco easily.
I mention this in this thread because I have a suspicion that
Ruby's reputation for a lack of libraries is superficial.
There are a lot of libraries; we just don't always access
them very well. Setting some standards and easing access are
easy things to do, and they can only encourage effort in
creating more high-quality libraries, and higher quality
documentation for those libraries.
One technical nit: not all libraries conform to the pattern
whereby they install in a single directory.

A few of us here in Denver are working on this issue. See
http://development.faeriemud.org/ModuleBuilder/. There's a link to CVS as
well.

As far as standards, here is how the file layout is gonna be until someone
threatens me with a pair of pliers and a blowtorch (or Michael and Martin
kick me off the project):

Layout will be based on package name. A script (ala h2xs, but with a better
name and no assumptions that C is present) will be provided to autogenerate
the directory & file layout. The initial version of this script is called
"rbuildmaker.rb" (name subject to change) and can be found under the bin
directory on the cvs page (follow the links from the url provided above).

Examples:

package "foo" - all package names will be lower case

foo/
lib/ - foo.rb (plus whatever other libs)
doc/ - documentation
test/ - test cases here
CHANGES - changelog
install.rb - a revamped, consistent, standard install script
MANIFEST - listing of package contents
test.rb - will run any unit tests included (for a "make test", or the
like)
INSTALL - installation instructions
LICENSE - Licensing information (perhaps relegated to rd2)

package "foo-bar"

foo-bar/
lib/foo/bar.rb
...

In the second example, bar.rb would then be installed in the sitelibdir (by
default - would be configurable) under the directory "foo". My feeling is
that documentation should be as well (if provided). I wouldn't mind
autogenerating and installing ri docs or man pages either. Keeping
everything in the sitelibdir would also make it easier to determine what 3rd
party modules have been installed on your system. I can't think of a reason
not to install in the sitelibdir, unless it's a permissions/administration
issue.

Some stub documenation will be automatically created for you as well. For
example, using the foo-bar package, the bar.rb file will start off like
this:

module Foo
class Bar
VERSION = "0.1.0"
# Add code here
def self.VERSION
VERSION
end
end
end
=begin
= Description
# Add description
= Synopsis
# Add synopsis
= Class Methods
# Add class method docs
= Instance Methods
# Add instance method docs
= Constants
# Add constant docs
= Author
# Your name, email address, irc nick, whatever
= License
# Ruby's by default. Change as desired.
= Copyright
(C) #{current-year} All Rights Reserved. Change as desired
=end

Thus, package name matches directory layout matches module-class hierarchy.

A couple of points to head off questions:

lower case - You can make your package name whatever case you like, but all
of *mine* are going to be lower case. Most people seem to follow this
tradition anyway. Let's make it a standard.

stub - don't bug me about the stub documentation details. It's JUST STUB
DOCUMENTATION. I don't expect it to survive long. It's just there as a
guideline and to remind you to document certain things, like your License
and Copyright.

rd2 - if you prefer rdoc, delete and retype as you see fit. See my point
about "stub" above.

hypocrisy - I admit I do not follow these standards 100% in my own packages
(but I'm close). However, I plan on converting all them where they differ
eventually.

Now, autogenerating a file layout is easy. It's the install.rb script
that's going to be the heart of this project (and thus most difficult).

Questions anyone?

Regards,

Dan

[Curt Hibbs]

I would like to support something like this in FreeRIDE as part of our
project-management/deployment support (which does not yet exist), and I
would appreciate it if you could keep us informed as the project progresses.

Thank you,
Curt

-----Original Message-----
A few of us here in Denver are working on this issue. See
http://development.faeriemud.org/ModuleBuilder/. There's a link to CVS as
well.
As far as standards, here is how the file layout is gonna be until someone
threatens me with a pair of pliers and a blowtorch (or Michael and Martin
Layout will be based on package name. A script (ala h2xs, but
with a better
name and no assumptions that C is present) will be provided to
autogenerate
the directory & file layout. The initial version of this script is called
"rbuildmaker.rb" (name subject to change) and can be found under the bin
directory on the cvs page (follow the links from the url provided above).
package "foo" - all package names will be lower case
foo/
lib/ - foo.rb (plus whatever other libs)
doc/ - documentation
test/ - test cases here
CHANGES - changelog
install.rb - a revamped, consistent, standard install script
MANIFEST - listing of package contents
test.rb - will run any unit tests included (for a "make
test", or the
like)
INSTALL - installation instructions
LICENSE - Licensing information (perhaps relegated to rd2)
package "foo-bar"
foo-bar/
lib/foo/bar.rb
...
In the second example, bar.rb would then be installed in the
sitelibdir (by
default - would be configurable) under the directory "foo". My feeling is
that documentation should be as well (if provided). I wouldn't mind
autogenerating and installing ri docs or man pages either. Keeping
everything in the sitelibdir would also make it easier to
determine what 3rd
party modules have been installed on your system. I can't think of a reason
not to install in the sitelibdir, unless it's a permissions/administration
issue.
Some stub documenation will be automatically created for you as well. For
example, using the foo-bar package, the bar.rb file will start off like
module Foo
class Bar
VERSION = "0.1.0"
# Add code here
def self.VERSION
VERSION
end
end
end
=begin
= Description
# Add description
= Synopsis
# Add synopsis
= Class Methods
# Add class method docs
= Instance Methods
# Add instance method docs
= Constants
# Add constant docs
= Author
# Your name, email address, irc nick, whatever
= License
# Ruby's by default. Change as desired.
= Copyright
(C) #{current-year} All Rights Reserved. Change as desired
=end
Thus, package name matches directory layout matches module-class hierarchy.
lower case - You can make your package name whatever case you
like, but all
of *mine* are going to be lower case. Most people seem to follow this
tradition anyway. Let's make it a standard.
stub - don't bug me about the stub documentation details. It's JUST STUB
DOCUMENTATION. I don't expect it to survive long. It's just there as a
guideline and to remind you to document certain things, like your License
and Copyright.
rd2 - if you prefer rdoc, delete and retype as you see fit. See my point
about "stub" above.
hypocrisy - I admit I do not follow these standards 100% in my
own packages
(but I'm close). However, I plan on converting all them where they differ
eventually.
Now, autogenerating a file layout is easy. It's the install.rb script
that's going to be the heart of this project (and thus most difficult).
Questions anyone?
Regards,
Dan

[Gabriel Emerson]

My only response is a vague one. I mostly agree with you, re: naming and
stuff, but whatever we do I'd rather have something more like CPAN and
less like Vaults of Parnassus.

CPAN is more or less professional-looking. Maybe it is the massive
hierarchy or the cool colons. VoP looks like a grab bag.

If you want 5 Lisp interpreters, call them Lang::Lisp::Rouge,
Lang::Lisp::Lithp, whatever. The category is important, the base name
isn't so much. As long as you have a path to find them.

Now to address your actual post. Maybe we should have a web site. A
person can go in and request a CPAN module, based on their actual need for
it, maybe with a comment on why it would be a Good Thing To Have. People
could respond with the names of existing modules and why they fit the
bill, or someone could volunteer to write it, and maintain a progress bar.

As far as slavishly copying CPAN APIs, sometimes that's a good idea, and
sometimes it's a really bad idea. As far as copying the guts, I'd almost
always advocate doing it from scratch using Ruby best practices. Hacking
around nasty Perlisms is no fun.

We now have WriteExcel thanks to someone just adopting a module and
porting it. It's not like it's impossible to do.

My alternative solution is to just stop talking about CPAN around dblack.

--Gabriel

[Matt Armstrong]

Post by Gabriel Emerson
Now to address your actual post. Maybe we should have a web site. A
person can go in and request a CPAN module, based on their actual need for
it, maybe with a comment on why it would be a Good Thing To Have.

For one attempt:

[ruby-talk:20560]

http://www.rubygarden.org/ruby?LibraryModules

Some of the requests are for stuff Ruby already has. It'd be
interesting to see a mapping of CPAN modules to Ruby modules.

[John Carter]

Post by d***@candle.superlink.net
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."

Sigh! I was going to keep out of this one, but the responses so far have
sucked me into it....

I don't need CPAN and I don't want such a beast.

I want a distribution. A bundle.

A CPAN is a tangled web of dependencies.

A distribution (like Redhat / Debian / Mandrake / ...) is that tangled
web snapshotted, bundled, flattened out, smoothed and co-tested.

ie. When I install version X.Y of any distribution I get...
a) A Large bundle of goodies.
b) Where each goodie has been tested to operate at some reasonable level
of stability.
c) And the elements of the Bundle have been tested to interoperate!

Item a) means I can get stuck in and start working straight away. The
batteries are included.

Item b) means I'm not on the bleeding edge so I have reasonable confidence
that I can deploy the latest stable version to a customer and it will
just work.

Item c) means the risk of mutually incompatible module versions has been
removed for me.

You may object that distributions remove flexibility, some people wanting
slim bundles some wanting fat.

Just the same as you can get tiny Linux distributions I envisage there
will be tiny Ruby distributions.

Want to script something that must be deployed on a thousand Windows
clients but @@%$&^%$ windows cmd.exe is too pathetic to
contemplate?

Install a "tiny ruby" distro and away you go.

Want decent script engine for an embedded platform? Install a tiny linux
distro with a tiny ruby script distro.

Want to write something large and powerful? Install the fat distro and
away you go.

Where we are now is want module X, you must pull down item Y Version y1.y1
and item Z Version z1.z2. (You better hope the servers for X, Y and Z are
up when you want them.) Now you want module W as well, for that you need
module S and module Y Version y2.y2 which is incompatible with Y version
y1.y1

Oh dear.

I see Ruby 1.8.0 promises to have a lot more goodies bundled with it, I am
extremely glad.

But perhaps the Ruby bundle should be small as possible. Same as the Linux
kernel. Just Ruby and no libraries or extensions. This is so that "tiny
ruby" distributions can easily be created.

And then there should be a Fat Ruby, developed along the lines of the
Debian distribution, but with a far faster release cycle.

I propose that Matz strip the Ruby 1.8.0 Kernel to the minimum. Make
it really the smallest thing that will be useful. (Perhaps a better
definition would be the smallest thing that would not have to be patched
to make the "Fat Ruby" distribution.)

I propose that at least two Sourceforge projects be started up.

A "tiny ruby" that can be the engine for a Windows installer / scripter.

A "Fat Ruby" that evolves very much like the Debian project, but hopefully
faster. The "Fat Ruby" distro V1.0 should aim to have _every_ mature /
usable item on RAA in it.




John Carter Phone : [phone]
Tait Electronics Fax : [phone]
PO Box 1645 Christchurch Email : ***@tait.co.nz
New Zealand

John's law :-

All advances in computing have arisen through the creation of an
additional level of indirection, the trick is to work out which
indirection is actually useful.

[Piers Harding]

I agree with you that ultimately distributions, and "certified
collections" of packages are probably an ultimate goal, but I would
suggest that one reason why this works for RedHat is that RedHat is a
commercial entity, and they (as an entity) have the man power/time and
the money to do it. Additionally - Perl5 is a distribution - it
contains a lot of packages that people generally use such as libwww,
CGI, Data::Dumper, the list goes on for a long way.

Saying that CPAN is a tangled web of dependencies is not viewing it for
what it is. It is a place that a community can publish its work, to a
given set of standards, knowing that that work can be resonably searched
for. Developing a repository of modules, and surround information
should be kept separate form how we access that information - for
example the CPAN shell neatly deals with package retrieval, including
dealing with mirror site, and manages drilling into the dependencies
issue.

In fact - I urge you all to check out the many facets of CPAN, so that
you can understand it fully.
http://pause.cpan.org - authors portal
http://search.cpan.org - main directory interface, with access to
documentation, versions, and how to get in touch with authors, and
interest groups etc.
http://rt.cpan.org - a relatively new effort to assisst with
maintenance, and bug tracking.

then there are any number of supporting sites such as
http://www.perldoc.com, etc.

Cheers.

Post by John Carter

Post by d***@candle.superlink.net
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."

Sigh! I was going to keep out of this one, but the responses so far have
sucked me into it....
I don't need CPAN and I don't want such a beast.
I want a distribution. A bundle.
A CPAN is a tangled web of dependencies.
A distribution (like Redhat / Debian / Mandrake / ...) is that tangled
web snapshotted, bundled, flattened out, smoothed and co-tested.
ie. When I install version X.Y of any distribution I get...
a) A Large bundle of goodies.
b) Where each goodie has been tested to operate at some reasonable level
of stability.
c) And the elements of the Bundle have been tested to interoperate!
Item a) means I can get stuck in and start working straight away. The
batteries are included.
Item b) means I'm not on the bleeding edge so I have reasonable confidence
that I can deploy the latest stable version to a customer and it will
just work.
Item c) means the risk of mutually incompatible module versions has been
removed for me.
You may object that distributions remove flexibility, some people wanting
slim bundles some wanting fat.
Just the same as you can get tiny Linux distributions I envisage there
will be tiny Ruby distributions.
Want to script something that must be deployed on a thousand Windows
contemplate?
Install a "tiny ruby" distro and away you go.
Want decent script engine for an embedded platform? Install a tiny linux
distro with a tiny ruby script distro.
Want to write something large and powerful? Install the fat distro and
away you go.
Where we are now is want module X, you must pull down item Y Version y1.y1
and item Z Version z1.z2. (You better hope the servers for X, Y and Z are
up when you want them.) Now you want module W as well, for that you need
module S and module Y Version y2.y2 which is incompatible with Y version
y1.y1
Oh dear.
I see Ruby 1.8.0 promises to have a lot more goodies bundled with it, I am
extremely glad.
But perhaps the Ruby bundle should be small as possible. Same as the Linux
kernel. Just Ruby and no libraries or extensions. This is so that "tiny
ruby" distributions can easily be created.
And then there should be a Fat Ruby, developed along the lines of the
Debian distribution, but with a far faster release cycle.
I propose that Matz strip the Ruby 1.8.0 Kernel to the minimum. Make
it really the smallest thing that will be useful. (Perhaps a better
definition would be the smallest thing that would not have to be patched
to make the "Fat Ruby" distribution.)
I propose that at least two Sourceforge projects be started up.
A "tiny ruby" that can be the engine for a Windows installer / scripter.
A "Fat Ruby" that evolves very much like the Debian project, but hopefully
faster. The "Fat Ruby" distro V1.0 should aim to have _every_ mature /
usable item on RAA in it.
John Carter Phone : [phone]
Tait Electronics Fax : [phone]
New Zealand
John's law :-
All advances in computing have arisen through the creation of an
additional level of indirection, the trick is to work out which
indirection is actually useful.

[Massimiliano Mirra]

Post by Piers Harding
I agree with you that ultimately distributions, and "certified
collections" of packages are probably an ultimate goal, but I would
suggest that one reason why this works for RedHat is that RedHat is a
commercial entity, and they (as an entity) have the man power/time and
the money to do it.

Debian is not a commercial entity and yet is the distribution with the
best package management (way better than Red Hat anyway).


Massimiliano

[Piers Harding]

Fair comment. I must admit to not being that conversant with Debian,
but I guess the main thing that I am driving at is that Ruby could
benefit from a lot of what the CPAN infrastructure has to offer, and the
model by which it has developed has been thru a classic ( and healthy )
Open Source Bazaar style development cycle.

I really want to see Ruby succeed, as it has an enormous amount to
offer, but not openly accepting and learning and embracing the good
things that can be learnt from other Languages, would be a terrible
mistake.

Cheers.

Post by Massimiliano Mirra

Post by Piers Harding
I agree with you that ultimately distributions, and "certified
collections" of packages are probably an ultimate goal, but I would
suggest that one reason why this works for RedHat is that RedHat is a
commercial entity, and they (as an entity) have the man power/time and
the money to do it.

Debian is not a commercial entity and yet is the distribution with the
best package management (way better than Red Hat anyway).
Massimiliano

[Daniel P. Zepeda]

On Thu, 23 Jan 2003 10:36:31 +0900

Post by d***@candle.superlink.net
Hi --
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."

<snip>

Post by d***@candle.superlink.net
So, all you almost-satisfied Ruby programmers, what's missing? :-)

libwww-ruby

Post by d***@candle.superlink.net
David
--
David Alan Black
Web: http://pirate.shu.edu/~blackdav

[Daniel P. Zepeda]

On Fri, 24 Jan 2003 14:56:14 +0900

Post by Joey Gibson
On Thu, 23 Jan 2003 10:36:31 +0900

Post by d***@candle.superlink.net
Hi --
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."

<snip>

Post by d***@candle.superlink.net
So, all you almost-satisfied Ruby programmers, what's missing? :-)

libwww-ruby

Oh never mind, there is http-access. I guess I didn't look hard enough.
Instead of inputting www in the search, I put libwww in the RAA search and
didn't find it originally.

Sorry.

Post by Joey Gibson

Post by d***@candle.superlink.net
David
--
David Alan Black
Web: http://pirate.shu.edu/~blackdav

--
(Remove commas for address)

[Sperberg, Roger]

Post by Daniel Carrera
1) Find a more accessible domain name. www.ruby-lang.org/raa
is not as
easy to remember as www.cpan.org. Unfortunatelly
(ruby|cran|raa).(org|net) are all taken.

rubyarchive.org

rubylib.org


Roger Sperberg

Roger Sperberg
Aspen Publishers
New York, NY 10036
***@aspenpubl.com

[Berger, Daniel]

-----Original Message-----

<snip>

User::grent
User::pwent -- Password a group utilities. Admittedly, not a
big deal

I'm not sure what you mean here. Are you referring to stuff in the 'etc'
module?

searched for 'password'
Proc::killall - kills off a process by name, searched for
'process' and 'killall'

# Equivalent
require "sys-proctable"
Sys::ProcTable.ps{ |p| kill if p.ppid == 2122 }

This module came up first in a search for "process" on the RAA, btw. The
name was derived from Dan Urist's Proc::ProcessTable Perl module.

I find it telling that the OP asked for what pieces were
missing, but the
discussion tended to naming conventions and module
management. There *is* a ton of stuff on CPAN, but a lot of
it is not needed, because Ruby obviates the need for it, and
of course, my list is not exhaustive, just my experiences.
Maybe after all the discussion is done, we'll find that CPAN
is huge because it has to be, to add stuff to Perl that Ruby
already has, and that the small size of Ruby doesn't show the
lack of available functionality, but the power of the core Ruby.

I agree with you here. Note the hoard of "Class::" modules that Ruby simply
doesn't need, for example.

Regards,

Dan

[Daniel P. Zepeda]

On Sat, 25 Jan 2003 03:59:22 +0900

Post by ahoward

-----Original Message-----

<snip>

User::grent
User::pwent -- Password a group utilities. Admittedly, not a
big deal

I'm not sure what you mean here. Are you referring to stuff in the
'etc' module?

Yes, I guess so. I can't find any documentation on it, but I know it is
there because

ruby -e 'require "etc"'

works.

I don't see any reference to it in the Built-in Classes and Methods or
Standard Library in the Pickaxe, or am I not looking hard enough?

Post by ahoward

searched for 'password'
Proc::killall - kills off a process by name, searched for
'process' and 'killall'

# Equivalent
require "sys-proctable"
Sys::ProcTable.ps{ |p| kill if p.ppid == 2122 }
This module came up first in a search for "process" on the RAA, btw.
The name was derived from Dan Urist's Proc::ProcessTable Perl module.

Sure enough. Not sure why I didn't see it the first time. I see it is the
first entry, guess I was going too fast and got sloppy.

Thanks for the pointers! That knocks those off the list.

Post by ahoward
Regards,
Dan

[Daniel P. Zepeda]

On Sat, 25 Jan 2003 04:29:59 +0900

Post by Daniel P. Zepeda
On Sat, 25 Jan 2003 03:59:22 +0900

Post by ahoward

-----Original Message-----

<snip>

User::grent
User::pwent -- Password a group utilities. Admittedly, not a
big deal

I'm not sure what you mean here. Are you referring to stuff in the
'etc' module?

Yes, I guess so. I can't find any documentation on it, but I know it is
there because
ruby -e 'require "etc"'
works.
I don't see any reference to it in the Built-in Classes and Methods or
Standard Library in the Pickaxe, or am I not looking hard enough?

Well, for those who know the 'C' equivelants, I suppose no documentation

Post by Daniel P. Zepeda
ruby -e 'require "etc"; puts Etc.methods'|m

group
getpwnam
getgrnam
getpwuid
getgrgid
getlogin
passwd
private_instance_methods
clone
class_variables
public_class_method
const_set
ancestors
protected_instance_methods
class_eval
method_defined?
const_get
name
<
<=>
public_instance_methods

<much more snipped>

[Joel VanderWerf]

Post by Daniel P. Zepeda
ruby -e 'require "etc"; puts Etc.methods'|m

BTW...

irb(main):006:0> Etc.methods - Etc.class.instance_methods(true)
["getgrnam", "getpwuid", "getgrgid", "getlogin", "passwd", "group",
"getpwnam"]

Less to snip.

[Berger, Daniel]

-----Original Message-----
Net::DNS - A DNS interface, to create and process query packets
- searched for 'DNS'

Oops - forgot to mention:

require "resolv" - part of the standard distro (under 'lib'). In fact,
there are a few things in lib that aren't documented in any book I've seen.

SNMP - an interface to UCD SNMP

I see two on the RAA.

Regards,

Dan

[Daniel P. Zepeda]

On Sat, 25 Jan 2003 05:41:28 +0900

Post by Berger, Daniel

-----Original Message-----
Net::DNS - A DNS interface, to create and process query packets
- searched for 'DNS'

require "resolv" - part of the standard distro (under 'lib'). In fact,
there are a few things in lib that aren't documented in any book I've seen.

Well, see, there you go. Everything I've ever needed in a Perl module is
already there. Just didn't know where to look, or the documentation isn't
quite out there yet. It seems some documentation, and some additional
comments in the RAA are all *I* needed. I still haven't seen anyone else
say, "well there is X module that I couldn't do my project in Ruby
without, so I had to do it in Perl" -- oh, except to make it easy with
something equivalent to the CPAN shell:

perl -MCPAN -e shell

So, Daniel, do you have a pointer for that too? I thought I knew a good
bit about ruby, but I've had some eye openers today, I need to shut up and
dig through the distribution sources...


I think this just goes to show that everyone should get over their CPAN
envy, because it is un-necessary.

Post by Berger, Daniel

SNMP - an interface to UCD SNMP

I see two on the RAA.
Regards,
Dan

[David Garamond]

Post by d***@candle.superlink.net
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."
So, all you almost-satisfied Ruby programmers, what's missing? :-)

yes, a CPAN equivalent is currently missing. however, worry not because
ruby will attract enough perl programmers that sooner or later they will
recreate a CPAN for ruby :-)

i'm widly guessing that of 10 perl programmers that migrate to/try out
other languages:

- 1 will settle to python;
- 7-8 will settle to ruby;
- 1-2 will settle to other language;

ruby tries very hard to be a better perl, while python is just too
different from perl that perl programmers will miss all these features:

- builtin regexes;
- command line options (-i, -n, -p);
- special variables ($_, $0..$9);
- tainting;
- all that nice quoting operators (qw//, qr//, qq//);
- obfuscatability (sp?);
- etc.

[d***@candle.superlink.net]

Hi --

Post by David Garamond

Post by d***@candle.superlink.net
We've all heard this: "Ruby is great, but it doesn't have the
equivalent of CPAN."
So, all you almost-satisfied Ruby programmers, what's missing? :-)

yes, a CPAN equivalent is currently missing. however, worry not because
ruby will attract enough perl programmers that sooner or later they will
recreate a CPAN for ruby :-)

Rumor has it that a number of Ruby programmers have already manifested
an interest in this problem domain :-)

Post by David Garamond
i'm widly guessing that of 10 perl programmers that migrate to/try out
- 1 will settle to python;
- 7-8 will settle to ruby;
- 1-2 will settle to other language;
ruby tries very hard to be a better perl, while python is just too
- builtin regexes;
- command line options (-i, -n, -p);
- special variables ($_, $0..$9);
- tainting;
- all that nice quoting operators (qw//, qr//, qq//);

However, from the Ruby ToDo file:

* discourage use of symbol variables (e.g. $/, etc.) in manual
* discourage use of Perlish features by giving warnings.

:-)

Post by David Garamond
- obfuscatability (sp?);

Not sure about the spelling, but people should be warned that it's
not one of Ruby strong points :-)


David

[David Garamond]

Post by d***@candle.superlink.net

Post by David Garamond
ruby tries very hard to be a better perl, while python is just too
- builtin regexes;
- command line options (-i, -n, -p);
- special variables ($_, $0..$9);
- tainting;
- all that nice quoting operators (qw//, qr//, qq//);

* discourage use of symbol variables (e.g. $/, etc.) in manual
* discourage use of Perlish features by giving warnings.

hm, i wonder what is the list of features that the author (matz?) decide
as perlish and should be discouraged. so far i've been excited because
many of the nifty perl features are present in ruby. (i admit these
usually only mean the builtin regex operator, the perl re language [with
only few differences], the flexible quoting mechanism, and the command
line options. i almost never use $/ and the likes nowadays).

[Yukihiro Matsumoto]

Hi,

In message "Re: wait for more perl programmers! (Re: Can we attack the 'not enough libraries' thing straight on?)"
on 03/01/25, David Garamond <***@icqmail.com> writes:

|> * discourage use of symbol variables (e.g. $/, etc.) in manual
|> * discourage use of Perlish features by giving warnings.
|
|hm, i wonder what is the list of features that the author (matz?) decide
|as perlish and should be discouraged.

* symbol variables
* regexp in conditional expression
* range (../...) in conditonal expression

matz.

[Rudolf Polzer]

Post by Yukihiro Matsumoto
In message "Re: wait for more perl programmers! (Re: Can we attack the 'not enough libraries' thing straight on?)"
|> * discourage use of symbol variables (e.g. $/, etc.) in manual
|> * discourage use of Perlish features by giving warnings.
|
|hm, i wonder what is the list of features that the author (matz?) decide
|as perlish and should be discouraged.
* symbol variables

This probably also includes $1 etc, doesn't it?

Post by Yukihiro Matsumoto
* regexp in conditional expression

What's that? Just things like

if str =~ /regexp/
# ...
end

or do you just mean REs applied to $_?

Post by Yukihiro Matsumoto
* range (../...) in conditonal expression

I never really understood these in Perl, anyway - and if there is one
thing I do not like it's a side effect in an operator to itself. For example,

def foo(bar)
42.times() do |count|
foo(nil) if bar
if (count == 17) .. (count == 23)
p count
end
end
end
foo(17)

It does what it looks like and shows that ".." creates two internal
variables here: one for the inner and one for the outer call. One can make
this as confusing as one wants by using more procedures, iterators etc.

I'd like this much better:

rop = RangeOp.new()
# ...
if rop[count == 17, count == 23]
p count
end

or even

rop = RangeOp.new() do
count == 17, count == 23
end
# ...
if rop.test()
p count
end

maybe

rop = RangeOp.new() do |c|
c == 17, c == 23
end
# ...
if rop.test(count)
p count
end

because it's much clearer and it's obvious where the temporary is.
Additionally, this "RangeOp" can be implemented completely in Ruby,
so the interpreter doesn't need to support it.

[gabriele renzi]

Post by Yukihiro Matsumoto
|hm, i wonder what is the list of features that the author (matz?) decide
|as perlish and should be discouraged.
* symbol variables
* regexp in conditional expression
* range (../...) in conditonal expression
matz.

I hope you're not going to remove

case string
when /re/
....
end

I *love* it :)

Anyway:
will be a way to deactivate these warning ?
or
are these warning actvated from "-w" ?
or
we get them and there is no way to avoid them ?

[Yukihiro Matsumoto]

Hi,

In message "Re: wait for more perl programmers! (Re: Can we attack the 'not enough libraries' thing straight on?)"
on 03/01/26, gabriele renzi <***@rc1.vip.lng.yahoo.com> writes:

|> * regexp in conditional expression

|I hope you're not going to remove
|
|case string
|when /re/
|....
|end
|
|I *love* it :)

I don't mean this one. I meant "regexp in conditional" as in:

while gets
print if /Ruby/
end

By the way "print" without argument is also a Perlish feature to be
removed in the future.

matz.

[MikkelFJ]

Post by d***@candle.superlink.net

Post by David Garamond
- obfuscatability (sp?);

Not sure about the spelling, but people should be warned that it's
not one of Ruby strong points :-)

Why not? Spelling mistakes are ideal for obfuscation ;-)

Mikkel

[Martin DeMello]

Post by David Garamond
- obfuscatability (sp?);

s/obfuscatability/playfulness

martin