Eating CPAN - Was Port A Library

CPAN has 9502 modules.

So the suggestion is to port a few.

The question is which one.

Well CPAN has a notion of a dependency network.

Imagine if CPAN module XXX was missing, how many other modules would suddenly not work?

Obviously then the place to start porting is those modules which enable most other modules.

So we need a script that will chew on CPAN's dependency network and prioritise the CPAN modules.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

There are modules in CPAN that can do almost anything you need, and
most things that you don't. Having access to them would make a lot of
Ruby tasks much easier!

May I make a suggestion: Go the route of the Cygwin project. Instead
of porting individual modules, build a bridge that let's Ruby invoke
and talk to Perl. This would give us free access to (nearly) all of
CPAN. It would also make migrating a lot of Perl apps easier.

Are there any major difficulties it building a Ruby <-> Perl bridge?
Allowing Ruby code to call Perl subroutines, pass vars back and forth,
etc.?

John Carter wrote:

So we need a script that will chew on CPAN's dependency network and
prioritise the CPAN modules.

There's already one. It's called CPAN::Dependency; you can get it from CPAN.

Cheers,
Dave

John Carter wrote:

CPAN has 9502 modules.
...
So we need a script that will chew on CPAN's dependency network and
prioritise the CPAN modules.
...
From this principle, all of life and physics may be deduced.

Hi,

(Sorry if this is a duplicate; I attempted to post basically this to
c.l.r before but it hasn't shown up there or in ruby-talk.)

So, anyway, I couldn't get Perl's CPAN::Dependency to do what I wanted,
so I wrote a Ruby script to download CPAN. Well, the names of "releases"
(packages with versions; these can contain multiple modules) and their
authors and dependencies, anyway.

http://www.dave.burt.id.au/ruby/cpan/

The script downloads about 15000 pages from CPAN, one per author (5000)
plus one per current release (10000), and takes a little while, although
all the pages are small (the per release ones are just Makefile.PL, to
pull prerequisites from). It produces 800k of YAML.

I've cleaned up and processed this output (relatively trivially, sorry,
didn't save my work) to find the top 100 most-required releases. I've
got 2 versions of this list: the first is based on CPAN::Dependency's
notion of only counting authors whose releases refer to each release, to
eliminate false popularity generated by gratuitous references between an
authors own releases. The second isn't restricted like that and counts a
references for each release that lists it as a prerequisite.

The first that stands out to me, after eliminating functions that exist
or
are being developed in Ruby, is POE - Perl's event-driven networking
library. It looks quite simple to build, in comparison to Python's
Twisted,
and it seems it may be possible to build a Twisted-like interface layer
on
top of a POE port. What do Rubyists use in lieu of a Ruby event-driven
networking library?

Cheers,
Dave

···

--
Posted via http://www.ruby-forum.com/\.

You can do this with RubyInline:
http://rubyforge.org/projects/rubyinline/

···

On 2/15/06, eastcoastcoder@gmail.com <eastcoastcoder@gmail.com> wrote:

There are modules in CPAN that can do almost anything you need, and
most things that you don't. Having access to them would make a lot of
Ruby tasks much easier!

May I make a suggestion: Go the route of the Cygwin project. Instead
of porting individual modules, build a bridge that let's Ruby invoke
and talk to Perl. This would give us free access to (nearly) all of
CPAN. It would also make migrating a lot of Perl apps easier.

Are there any major difficulties it building a Ruby <-> Perl bridge?
Allowing Ruby code to call Perl subroutines, pass vars back and forth,
etc.?

Dňa Štvrtok 16 Február 2006 04:53 eastcoastcoder@gmail.com napísal:

Are there any major difficulties it building a Ruby <-> Perl bridge?
Allowing Ruby code to call Perl subroutines, pass vars back and forth,
etc.?

Horrible, terrible overhead? Personally, I'd be happier to see Parrot deliver
on the rumours to run all manners of scripts - definately a more consistent
interoperability solution than making bridges.

Also, porting is useful in that it lets you do API modifications with respect
to specific Ruby idioms. Although the bridge would let you do a sort of Ruby
bindings to Perl modules this way more quickly getting rid of recoding core
algorithms.

David Vallner

Hi,

(Sorry if this is a duplicate; I attempted to post basically this to
c.l.r before but it hasn't shown up there or in ruby-talk.)

So, anyway, I couldn't get Perl's CPAN::Dependency to do what I wanted,
so I wrote a Ruby script to download CPAN. Well, the names of "releases"
(packages with versions; these can contain multiple modules) and their
authors and dependencies, anyway.

Index of /ruby/cpan

very cool!

The script downloads about 15000 pages from CPAN, one per author (5000)
plus one per current release (10000), and takes a little while, although
all the pages are small (the per release ones are just Makefile.PL, to
pull prerequisites from). It produces 800k of YAML.

I've cleaned up and processed this output (relatively trivially, sorry,
didn't save my work) to find the top 100 most-required releases. I've
got 2 versions of this list: the first is based on CPAN::Dependency's
notion of only counting authors whose releases refer to each release, to
eliminate false popularity generated by gratuitous references between an
authors own releases. The second isn't restricted like that and counts a
references for each release that lists it as a prerequisite.

The first that stands out to me, after eliminating functions that exist
or
are being developed in Ruby, is POE - Perl's event-driven networking
library. It looks quite simple to build, in comparison to Python's
Twisted,
and it seems it may be possible to build a Twisted-like interface layer
on
top of a POE port. What do Rubyists use in lieu of a Ruby event-driven
networking library?

Would you like to share your lists somewhere (rubygarden's wiki?) so
that people interested in porting can register their intention, ask for
help, etc.?

···

On 2/23/06, Dave Burt <dave@burt.id.au> wrote:

Cheers,
Dave

--
Posted via http://www.ruby-forum.com/\.

--
thanks,
-pate
-------------------------

Neat. How do you go about using this this to do Perl? Do you need to
inline an entire perl interpreter?

Really? Have you measured?

···

On Feb 16, 2006, at 6:31 AM, David Vallner wrote:

Dňa Štvrtok 16 Február 2006 04:53 eastcoastcoder@gmail.com napísal:

Are there any major difficulties it building a Ruby <-> Perl bridge?
Allowing Ruby code to call Perl subroutines, pass vars back and forth,
etc.?

Horrible, terrible overhead?

Yup. And at RubyConf I demo'd perl specifically. I'll release it in a bit.

···

On Feb 15, 2006, at 8:33 PM, Wilson Bilkovich wrote:

On 2/15/06, eastcoastcoder@gmail.com <eastcoastcoder@gmail.com> wrote:

You can do this with RubyInline:
http://rubyforge.org/projects/rubyinline/

pat eyler wrote:

> ...
> Index of /ruby/cpan

very cool!

Thanks.

Would you like to share your lists somewhere (rubygarden's wiki?) so
that people interested in porting can register their intention, ask for
help, etc.?

The top 100 lists are there:
http://www.dave.burt.id.au/ruby/cpan/releases_most_authors_depend_on.txt
http://www.dave.burt.id.au/ruby/cpan/releases_most_releases_depend_on.txt

Feel free to add them to RubyGarden. These may be relevant pages:

(Maybe the two should be merged.)

Cheers,
Dave

···

On 2/23/06, Dave Burt <dave@burt.id.au> wrote:

Does this really mean that we would have access to all the Perl
libraries "for free"?
If so, this would be great news, Ryan!

Cheers,
Ed

···

On 2/21/06, Ryan Davis <ryand-ruby@zenspider.com> wrote:

On Feb 15, 2006, at 8:33 PM, Wilson Bilkovich wrote:

> On 2/15/06, eastcoastcoder@gmail.com <eastcoastcoder@gmail.com> wrote:
>
> You can do this with RubyInline:
> http://rubyforge.org/projects/rubyinline/

Yup. And at RubyConf I demo'd perl specifically. I'll release it in a
bit.

--
Encontrá a "Tu psicópata favorito" http://tuxmaniac.blogspot.com
  
Thou shalt study thy libraries and strive not to reinvent them without cause,
that thy code may be short and readable and thy days pleasant and productive.
-- Seventh commandment for C programmers

>

[deleted info about RubyInline's Perl capabilities]

Does this really mean that we would have access to all the Perl
libraries "for free"?

well, only if you consider having to deal with their various APIs 'for free'

If so, this would be great news, Ryan!

It's a good temporary measure, but having Ruby rewrites of the
important/useful libraries would be *much* better.

···

On 2/20/06, Edgardo Hames <ehames@gmail.com> wrote:

On 2/21/06, Ryan Davis <ryand-ruby@zenspider.com> wrote:

Cheers,
Ed

--
Encontrá a "Tu psicópata favorito" http://tuxmaniac.blogspot.com

Thou shalt study thy libraries and strive not to reinvent them without cause,
that thy code may be short and readable and thy days pleasant and productive.
-- Seventh commandment for C programmers

--
thanks,
-pate
-------------------------