C scripting using Ruby (instead of Perl)? 
Author Message
 C scripting using Ruby (instead of Perl)?

FYI && FWIW,

    ( http://www.*-*-*.com/ )

contains the following interesting item:

    Pathologically Polluting Perl
    by Brian Ingerson

# Inline.pm is a new module that glues other programming languages to
# Perl. It allows you to write C, C++, and python code directly inside
# your Perl scripts and modules.  This is conceptually similar to the
# way you can write inline assembly language in C programs. Thus the
# name: Inline.pm.
#
# [...]
#
# In the year 2001, I would like to see bindings for
# Java,
# Ruby,       [ <---- !! ]
# fortran
# and Bash. I don't plan on authoring all of these myself. But
# I may kickstart some of them, and see if anyone's interested in
# taking over.
#
# [...]
#
# Using XS is just too hard. At least when you compare it to the rest
# of the Perl we know and love. Inline takes advantage of the existing
# frameworks for combining Perl and C, and packages it all up into one
# easy to swallow pill.

Are there any stumbling blocks to doing something like this in Ruby?

Shouldn't it be easier to do this sort of thing in Ruby (versus Perl)?

Anyone want to give it a demo-level try?

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)



Sun, 10 Aug 2003 07:27:58 GMT  
 C scripting using Ruby (instead of Perl)?
Quote:

>FYI && FWIW,

>     (http://www.perl.com/pub/2001/02/inline.html)

>contains the following interesting item:

[description of Inline.pm]

Quote:

>Are there any stumbling blocks to doing something like this in Ruby?

Someone needs to do it.

Quote:
>Shouldn't it be easier to do this sort of thing in Ruby (versus Perl)?

Well as I understand, he was able to throw it together
in Perl fairly easily because there were a bunch of
packages on CPAN he could leverage.  There were more
building blocks, and that is why it was doable.  But
working from scratch, it is probably easier to do this
kind of thing in Ruby.

Quote:
>Anyone want to give it a demo-level try?

Anyone who does should read

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/~poffice/mail/ruby-talk/...

first.

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



Sun, 10 Aug 2003 07:47:07 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:



>Subject: [ruby-talk:11194] Re: C scripting using Ruby (instead of Perl)?
>Date: Wed, 21 Feb 2001 08:47:07 +0900


>Someone needs to do it.

I'm not completely sure of whether you're talking about doing the Ruby
extension for Inline.pm or creating an Inline.rb ;)

I'm not a very good C programmer, but it's been poking at me to give this a
go for a couple of weeks.  I downloaded the python extension, didn't look
_that_ rough, 1 XS file and 1 perl module.  If anyone is actually any good
with C and willing to take this on, let me know so I can feel better about
being lazy ;)

Also, again, I'm left wondering why we couldn't do an Inline.rb?  Seems to
be an extrememly great tool that has all sorts of promise.  It would also,
most likely, help Ruby get going by allowing companies to continue to
leverage perl while looking at Ruby.

Quote:

>>Anyone want to give it a demo-level try?

>Anyone who does should read

>http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/~poffice/mail/ruby-talk/...

>first.

Thanks for the link

Mike Wilson
Unix Administrator
http://ruby.weblogs.com

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



Sun, 10 Aug 2003 09:56:34 GMT  
 C scripting using Ruby (instead of Perl)?

B> Anyone who does should read
B> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/~poffice/mail/ruby-talk/...

 The problem is here

Quote:
>> The point of this is to make it very easy to extend Perl with C

 actually *it very easy* to extend Ruby with C

 Inline.pm try to solve a perl problem (at least with 'use Inline C') which
 don't exist in ruby.

Guy Decoux



Sun, 10 Aug 2003 18:06:30 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:

>> actually *it very easy* to extend Ruby with C

B> Our definitions of "very" differ.

 From [ruby-talk:11189]

  # Using XS is just too hard. At least when you compare it to the rest
  # of the Perl we know and love.

 Using C is just too easy with ruby

B> Literally just drop the C code directly into the
B> script, and leave deciding when to recompile and how
B> to link up to Inline.

  ruby extconf.rb
  make
  make install

 If you can't do this, perhaps there is a problem

Guy Decoux



Sun, 10 Aug 2003 20:09:25 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:


[...]
> >> The point of this is to make it very easy to extend Perl with C

>  actually *it very easy* to extend Ruby with C

Our definitions of "very" differ.

Quote:
>  Inline.pm try to solve a perl problem (at least with 'use Inline C')
>which
>  don't exist in ruby.

With Inline it is easier to extend Perl with C than
it is to extend Ruby with C.  The fact that you can
also extend Perl with multiple other languages (C++,
Python, more to come) is just icing on the cake.

Literally just drop the C code directly into the
script, and leave deciding when to recompile and how
to link up to Inline.

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



Sun, 10 Aug 2003 20:00:42 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:


> >> actually *it very easy* to extend Ruby with C

>B> Our definitions of "very" differ.
[...]
>B> Literally just drop the C code directly into the
>B> script, and leave deciding when to recompile and how
>B> to link up to Inline.

>   ruby extconf.rb
>   make
>   make install

>  If you can't do this, perhaps there is a problem

I found that to be an unfair slam.

Did I ever indicate that it was not easy to extend
Ruby with C?  Not that I saw.  However I pointed out
that it could be even *easier*, hence I have a
different definition of "very easy" than you do.

I am baffled by how you got from there to suggesting
that I _can't_ figure out how to do it.

Now is it worth the extra work of getting Inline set
up just to make it easier to get C working with Ruby?
Almost certainly not.  But is it worth that work for
the potential of then being able to link in other
languages?  (Which is where Inline.pm is going in
Perl.)

The answer to that may be different...

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



Sun, 10 Aug 2003 22:35:05 GMT  
 C scripting using Ruby (instead of Perl)?
Quote:

[...]
> >  If you can't do this, perhaps there is a problem

> I found that to be an unfair slam.

Hm,

unfair slams are my domain;-)

Christoph
[...]



Sun, 10 Aug 2003 22:51:18 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:


> > >> actually *it very easy* to extend Ruby with C

> >B> Our definitions of "very" differ.

> [...]

> >B> Literally just drop the C code directly into the
> >B> script, and leave deciding when to recompile and how
> >B> to link up to Inline.

> >   ruby extconf.rb
> >   make
> >   make install

> >  If you can't do this, perhaps there is a problem

> I found that to be an unfair slam.

> Did I ever indicate that it was not easy to extend
> Ruby with C?  Not that I saw.  However I pointed out
> that it could be even *easier*, hence I have a
> different definition of "very easy" than you do.

> I am baffled by how you got from there to suggesting
> that I _can't_ figure out how to do it.

> Now is it worth the extra work of getting Inline set
> up just to make it easier to get C working with Ruby?
> Almost certainly not.  But is it worth that work for
> the potential of then being able to link in other
> languages?  (Which is where Inline.pm is going in
> Perl.)

> The answer to that may be different...

The 'answer' may be we've misconstrued the issue.  Ruby already has good
provisioning for extending Ruby with C.  But inline.pm is not about extending
Perl with C; it is about using C code snippets within Perl. These are
different 'problems'. Suppose I have a collection of words > 15 chars each
which need to be sorted with using the 12th char as key on even days of the
month when executed but using the 3rd char as key on odd days, unless the
_day_ is a Thursday _and_ the month ends in 'r' in whcih case the 8th char is
used as key. (Ok, my hypotheircals get weird).

I can write this in Perl, or in Ruby or write it in C (say my collection is
23 million such wrods)  for performance and extend Ruby.  But suppose it is
already written in C? I could translate into Perl or Ruby (which if I were
going to use it frequently might be best option) but suppose I just need it
once for a quick sysadmin hack I need to do now so the results can be used in
20 minutes? Here is where 'inline' for Perl comes in handy (just drop in the
C code and go) as it would be in Ruby.

Anyway, that's what I see as the issue, not extending but simply dropping in
'foreign' language routines I may have available on-the-fly. Seems like a
useful thing to have, yes?

Regards,

Kent Starr



Mon, 11 Aug 2003 01:40:14 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:



>> >> actually *it very easy* to extend Ruby with C

>>B> Our definitions of "very" differ.
>[...]
>>B> Literally just drop the C code directly into the
>>B> script, and leave deciding when to recompile and how
>>B> to link up to Inline.

>>   ruby extconf.rb
>>   make
>>   make install

>>  If you can't do this, perhaps there is a problem

>I found that to be an unfair slam.

>Did I ever indicate that it was not easy to extend
>Ruby with C?  Not that I saw.  However I pointed out
>that it could be even *easier*, hence I have a
>different definition of "very easy" than you do.

Quite true - it's easier to extend Ruby with C than it is to extend Perl
with C ("out of the box").  But considering Perl's Inline module, I'd have
to say it's at least as easy, if not easier, to extend Perl with C now.  
I'm doing a Language comparison matrix for an upcoming presentation and
intitially I was going to give Ruby a '4' (highest rating) and Perl a '2'
(1 is the lowest rating), but in light of Perl's Inline module, I'd have
to give Perl a 4 and Ruby a 3 - Inline actually seems to make extending
Perl with C a bit easier than extending Ruby with C.  Now, I haven't used
Inline in Perl (I read the article in The Perl Journal) and I have
extended Ruby with C - so it' possible that Inline isn't that easy when
you get down to actually using it.  Of course, we're talking mechanics
here - the other issue would be Perl's C API vs Ruby's C API.  I find
Ruby's to be very straightforward and easy to use, but I have to admit I
haven't done much with Perl in this department.

Quote:

>Now is it worth the extra work of getting Inline set
>up just to make it easier to get C working with Ruby?
>Almost certainly not.  But is it worth that work for
>the potential of then being able to link in other
>languages?  (Which is where Inline.pm is going in
>Perl.)

I actually think that at the moment, it would be more valuable to have an
Inline for Ruby that allows you to inline Perl code.

Phil



Mon, 11 Aug 2003 02:48:44 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:




[...]
>I'm doing a Language comparison matrix for an upcoming presentation and
>intitially I was going to give Ruby a '4' (highest rating) and Perl a '2'
>(1 is the lowest rating), but in light of Perl's Inline module, I'd have
>to give Perl a 4 and Ruby a 3 - Inline actually seems to make extending
>Perl with C a bit easier than extending Ruby with C.  Now, I haven't used
>Inline in Perl (I read the article in The Perl Journal) and I have
>extended Ruby with C - so it' possible that Inline isn't that easy when
>you get down to actually using it.

It really is as easy as it looks.  At least for small
things.  (I admit to not having extensively abused it
yet.)  The only gotcha that comes to mind is that your
C types need to have a typemap to Perl.  And those may
take some knowledge to make.  (You start with typemaps
to most things that you really need though.)

Ruby would, of course, also need to have appropriate
typemaps.  But those may well be easier to write from
scratch for Ruby than they are for Perl.

Of course the *right* solution is to see if Swig can be
convinced to automatically spit out the necessary
mapping... :-)

Quote:
>      Of course, we're talking mechanics
>here - the other issue would be Perl's C API vs Ruby's C API.  I find
>Ruby's to be very straightforward and easy to use, but I have to admit I
>haven't done much with Perl in this department.

I have not played extensively with this, but my bet would
be that pre-Inline this was a hands-down win for Ruby.

But with Inline, well take a look at
http://www.perl.com/pub/2001/02/inline.html and
scroll down to the section on "CPR".  No joke, that
turns Perl into a C interpreter where you can inline
and run Perl code at will.  Startup is, obviously,
much slower than an equivalent C program.  It is not,
however, too much worse than a Perl program...

Quote:

> >Now is it worth the extra work of getting Inline set
> >up just to make it easier to get C working with Ruby?
> >Almost certainly not.  But is it worth that work for
> >the potential of then being able to link in other
> >languages?  (Which is where Inline.pm is going in
> >Perl.)

>I actually think that at the moment, it would be more valuable to have an
>Inline for Ruby that allows you to inline Perl code.

The fastest way to that goal is probably to write a
Ruby binding for Inline.pm and then turn that around
(as has been done for both C and Python) to make it
look like you are writing in Ruby with an embedded
Perl interpreter available.  The reality, of course,
would be just the opposite, but sometimes appearances
matter...

As you hint, this solves the problem where Ruby is
unacceptable only because there is something that CPAN
has a module for that you don't want to reinvent in
Ruby.  Well you can easily wrap the Perl interface into
a Ruby interface, and then write in Ruby.  If you later
rewrite that piece you can then just replace the one
section and switch to using real Ruby rather than that
fake wrapper that gave you access to Perl stuff...

Of course if the functionality of Inline is of interest,
the best long-term solution is to have a straight Ruby
version.  Trust me, Ruby does not want to be passing
stuff too and from Perl when wrapping code from C, C++,
Python etc.  I think that very often a native Ruby
interface will be significantly more straightforward and
efficient than Perl's interface to either language...

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



Mon, 11 Aug 2003 04:25:37 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:
> I actually think that at the moment, it would be more valuable to have an
> Inline for Ruby that allows you to inline Perl code.

> Phil

I agree, it will be a long while before I'm as good at ruby as I am at perl.  I
am going to keep coding my OO dataserver in perl for a while.  Embedding perl
in ruby (easily) would let me build ruby wrappers prior to converting the
modules.

Ben ?? You there ??

=====
John van Vlaanderen

      #############################################

      #      Proud Sponsor of Perl/Unix of NY     #
      #        http://puny.vm.com                 #                
      #############################################

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/



Mon, 11 Aug 2003 10:30:29 GMT  
 C scripting using Ruby (instead of Perl)?

I spent about an hour looking over the Inline.pm faq on perl.com last night.

From the users admin point of view, or especially mobile development, I think
it is not, as they would like you to believe, a drop in replacement for XSUB.

Since it has to be linked to the compiler that created perl in the first place
it is completely unusable in a distributed environment.

The only practical use I can see is the accessing of shared libs, but still you
need that specific compiler.

Oddly, this product comes out of activestate which is fairly carefully trying
to prevent users from having just such an environment, especially one that is
copylefted.

Inline perl in ruby would make a lot more sense, since the perl compiler is
presumably already on the box being migrated to ruby.

Economic ramble:
I think this kind of analysis is important in defining the difference between
firms  developing revenue streams inside the development community rather than
those providing end user products, like web pages.  The first model restricts
technology by squeezing developers at the head of their revenue stream, the
latter enables it by bringing back revenue from the profit zone.

People dont want tools they want information and entertainment.

=====
John van Vlaanderen

      #############################################

      #      Proud Sponsor of Perl/Unix of NY     #
      #        http://puny.vm.com                 #                
      #############################################

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/



Tue, 12 Aug 2003 23:45:16 GMT  
 C scripting using Ruby (instead of Perl)?

Quote:
> I spent about an hour looking over the Inline.pm faq on perl.com last
> night.

> From the users admin point of view, or especially mobile development, I
> think it is not, as they would like you to believe, a drop in replacement
> for XSUB.

> Since it has to be linked to the compiler that created perl in the first
> place it is completely unusable in a distributed environment.

> The only practical use I can see is the accessing of shared libs, but still
> you need that specific compiler.

Which means that, for distributed use a Ruby 'inline.rb' would have to be
deployed as an extension with the specification that it be compiled with the
same compiler as that for Ruby.  Still, it would be useful (within that
specific environment) for on-the-fly c/c++ 'scripting' I would think.

Another thought on this: there is a prgram called EiC

http://www.kd-dev.com/~eic/

which is a command-line c interpretor. It is also embeddable, and thus a
candidate for a Ruby extension, perhaps? If nothing else, the irony of using
C as a 'scripting language' within Ruby is intriguing, yes?

Quote:
> Oddly, this product comes out of activestate which is fairly carefully
> trying to prevent users from having just such an environment, especially
> one that is copylefted.

That is because 'management' doesn't 'grok' information economy dynamics. I
tend to think the programmers there do, for the most part, however.
'Management' in most places (including the US gov) currently don't 'grok'
information economy dynamics. The failed dot coms are not because of 'bad'
business models, but significantly incomplete ones, both within and without
their specific corporate cultures. Solutions do not become or remain
solutions unless implemeted in their totality.

Quote:
> Inline perl in ruby would make a lot more sense, since the perl compiler is
> presumably already on the box being migrated to ruby.

Very definately.  The ability to leverage the exisiting solutions from CPAN
will speed adoption of Ruby within production environments. While in many
cases a Ruby solution may turn out to be cleaner, better, faster and
available in a more attractive container, the need for _now_ will take
precedence up front. So a Ruby 'inline-perl' would be a great value.

Quote:
> Economic ramble:
> I think this kind of analysis is important in defining the difference
> between firms  developing revenue streams inside the development community
> rather than those providing end user products, like web pages.  The first
> model restricts technology by squeezing developers at the head of their
> revenue stream, the latter enables it by bringing back revenue from the
> profit zone.

> People dont want tools they want information and entertainment.

Perzactly!!! You 'grok'! Implementations of solutions are of far greater
economic benefit than the tools to derive them, simply because of much
tighter binding to the multiplier effect. Ideas are 'seeds', the tools -
'soil' and 'water', and implementation is the flowering. For the majority of
people, the flowers _are_ the garden.

Regards,

Kent Starr



Wed, 13 Aug 2003 02:53:10 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. should I use ruby instead of perl

2. How to write cgi scripts with TCL instead of Perl

3. Using Python instead of Perl?

4. Using Smalltalk instead of Perl

5. UNIX SCRIPTS: Using find instead of ls

6. The Year In Scripting Languages Lua/Perl/Python/Ruby/Tcl 2002

7. Converting Perl scripts to Ruby?

8. a Perl script's interaction with Ruby's system call

9. The Year In Scripting Languages Lua/Perl/Python/Ruby/Tcl 2002

10. Teaching Ada in CS-1/2 (instead of Pascal/Modula)

11. My Perl to Ruby Story (was: perl and rub y)

12. Using Ruby as a scripting engine for C programs

 

 
Powered by phpBB® Forum Software