«

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 :
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.?

On 2/15/06, <> 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.?
>

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

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:ependency; you can get it from CPAN.

http://search.cpan.org/~saper/CPAN-D.../Dependency.pm

Cheers,
Dave

D=C5=88a =C5=A0tvrtok 16 Febru=C3=A1r 2006 04:53 n=
ap=C3=ADsal:
> 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 deliv=
er=20
on the rumours to run all manners of scripts - definately a more consistent=
=20
interoperability solution than making bridges.

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

David Vallner

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

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

> D=C5=88a =C5=A0tvrtok 16 Febru=C3=A1r 2006 04:53 =
=20
> nap=C3=ADsal:
>> Are there any major difficulties it building a Ruby <-> Perl bridge?
>> Allowing Ruby code to call Perl subroutines, pass vars back and =20
>> forth,
>> etc.?
>>
>
> Horrible, terrible overhead?

Really? Have you measured?

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

> On 2/15/06, <> 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.

On 2/21/06, Ryan Davis <ryand-> wrote:
>
> On Feb 15, 2006, at 8:33 PM, Wilson Bilkovich wrote:
>
> > On 2/15/06, <> 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.
>

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



--
Encontr=E1 a "Tu psic=F3pata favorito" http://tuxmaniac.blogspot.com
=09
Thou shalt study thy libraries and strive not to reinvent them without caus=
e,
that thy code may be short and readable and thy days pleasant and productiv=
e.
-- Seventh commandment for C programmers

On 2/20/06, Edgardo Hames <> wrote:
> On 2/21/06, Ryan Davis <ryand-> wrote:
> >

[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.

>
> Cheers,
> Ed
>
>
>
> --
> Encontr=E1 a "Tu psic=F3pata favorito" http://tuxmaniac.blogspot.com
>
> Thou shalt study thy libraries and strive not to reinvent them without ca=
use,
> that thy code may be short and readable and thy days pleasant and product=
ive.
> -- Seventh commandment for C programmers
>
>


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