Building a business case for Ruby

Hello Joe,

Well comparing OO Perl to OO Ruby you'll have a huge win here in terms of
maintainability. If people are already comfortable with Perl then it
might be a hard sell, but I think it's easier to convert someone who isn't
a Pearl zealot from Perl to Ruby than it is from Python to Ruby.

Aside from the ones you came up with, maybe Ruby's license is better for
your business? I don't know.

I don't know anything about licenses, but this is a very good point.
Are there any functional differences between the three languages'
licenses?

They are almost the same.
There are just two exceptions and this makes look Ruby less
functional. No native threads and not very good if you want to embedd
Ruby inside a C application. But otherwise from the core language
functionality they are all the same.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

For the work I was doing, Python had the same qualities you describe. It was amazing how similar the process was. But what I was doing wasn't a huge extension, just some wrappers to calls written in C++.

If I get to do something more complex for both languages I'll provide more feedback.

Stephen

···

In message <42A5E046.1080003@hibbs.com>, Curt Hibbs <curt@hibbs.com> writes

I like the way that Ruby extensions appear (to a Ruby program) to be a *real* Ruby object/class, no different than if I had coded it in Ruby.

I'm interested to know if the same thing true of Python extensions?

--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

Hi,

Xeno Campanoli a écrit :

I can't figure out Rescue. I have the following:

   rescue SystemCallError
     print "parse failed on #{line}" + $!
     raise
   end

and it doesn't compile:

/validateMenuSpecs.rb:135: syntax error
                       rescue SystemCallError
                             ^
./validateMenuSpecs.rb:135: warning: useless use of a constant in void context
./validateMenuSpecs.rb:173: syntax error

You must have a context has the warning message tells you. So you must have something like

begin
   # do something here
rescue SystemCallError
   print "parse failed on #{ line}" + $!
   raise
end

You should then put the code that you expect to get an exception from after the begin clause.

HTH

Ghislain

Creating a PyTypeObject (C implementation of python class) in C needs
much boring work. Actually, PyTypeObject is just a huge struct which owns
about 30 fields. It would explains why Python has no base class diagram.
Most Python classes just inherit root 'object'. In a deeper sense, Python's
type system would be much closer to 'Duck Typing' than Ruby, I think.
Anyway, it would be a pain in the ass to make a python class in C without
tools such as SWIG, pyrex and BoostPython.

I like Ruby way. Creating C extensions in Ruby seems much like OOP in C,
and so much like programming Ruby itself.

···

On 6/8/05, Curt Hibbs <curt@hibbs.com> wrote:

Stephen Kellett wrote:
> In message <c715e6405060313335c5be6c7@mail.gmail.com>, Joe Van Dyk > > <joevandyk@gmail.com> writes
>
>> 1) C extensions allow us to easily integrate with external existing
>> software, but I don't know how Perl or Python does in that respect.
>
>
> Having recently written some Ruby and Python extensions I'd say they are
> about the same level of complexity. The extensions I wrote did the same
> thing for each language and took roughly the same amount of time. The
> Python extension used a bit less code and was easier to write, but the
> differences are trivial and not worth arguing over.

I like the way that Ruby extensions appear (to a Ruby program) to be a
*real* Ruby object/class, no different than if I had coded it in Ruby.

I'm interested to know if the same thing true of Python extensions?

Thanks,
Curt

--
http://nohmad.sub-port.net

Ghislain Mary wrote:

Hi,

Xeno Campanoli a écrit :

I can't figure out Rescue. I have the following:

   rescue SystemCallError
     print "parse failed on #{line}" + $!
     raise
   end

and it doesn't compile:

/validateMenuSpecs.rb:135: syntax error
                       rescue SystemCallError
                             ^
./validateMenuSpecs.rb:135: warning: useless use of a constant in void context
./validateMenuSpecs.rb:173: syntax error

You must have a context has the warning message tells you. So you must have something like

begin
  # do something here
rescue SystemCallError
  print "parse failed on #{ line}" + $!
  raise
end

I tried this:

TargetsCategoriesFH.each_line do |line|
    begin
      target, catlist = line.chomp.strip.split(/\s*:\s*/)
    rescue NoMethodError
      #print "parse failed on #{line}" + $!
      print "parse failed " + $!
      raise
    end
.
end

and I get

./validateMenuSpecs.rb:152: private method `chomp' called for nil:NilClass (NoMethodError)
        from ./validateMenuSpecs.rb:132:in `each_line'
        from ./validateMenuSpecs.rb:132

with the rescue code commented out, I get:

./validateMenuSpecs.rb:153: private method `chomp' called for nil:NilClass (NoMethodError)
        from ./validateMenuSpecs.rb:132:in `each_line'
        from ./validateMenuSpecs.rb:132

Again.

···

You should then put the code that you expect to get an exception from after the begin clause.

HTH

Ghislain

--
Xeno Campanoli, xeno@eskimo.com, http://www.eskimo.com/~xeno
Pride before justice equals destabilization.
Power before truth equals destruction.
Profit before environment equals death.

Stephen Kellett ha scritto:

···

In message <42A5E046.1080003@hibbs.com>, Curt Hibbs <curt@hibbs.com> writes

I like the way that Ruby extensions appear (to a Ruby program) to be a *real* Ruby object/class, no different than if I had coded it in Ruby.

I'm interested to know if the same thing true of Python extensions?

For the work I was doing, Python had the same qualities you describe. It was amazing how similar the process was. But what I was doing wasn't a huge extension, just some wrappers to calls written in C++.

If I get to do something more complex for both languages I'll provide more feedback.

well, but IIRC python's extensions have this bad thing that you have to handle the refcounting by yourself instead of relying on a real gc, am I wrong?

Xeno Campanoli wrote:

Ghislain Mary wrote:

Okay. I got it. The raise was repeating the error. xc

···

Hi,

Xeno Campanoli a écrit :

I can't figure out Rescue. I have the following:

   rescue SystemCallError
     print "parse failed on #{line}" + $!
     raise
   end

and it doesn't compile:

/validateMenuSpecs.rb:135: syntax error
                       rescue SystemCallError
                             ^
./validateMenuSpecs.rb:135: warning: useless use of a constant in void context
./validateMenuSpecs.rb:173: syntax error

You must have a context has the warning message tells you. So you must have something like

begin
  # do something here
rescue SystemCallError
  print "parse failed on #{ line}" + $!
  raise
end

I tried this:

TargetsCategoriesFH.each_line do |line|
   begin
     target, catlist = line.chomp.strip.split(/\s*:\s*/)
   rescue NoMethodError
     #print "parse failed on #{line}" + $!
     print "parse failed " + $!
     raise
   end
.
end

and I get

./validateMenuSpecs.rb:152: private method `chomp' called for nil:NilClass (NoMethodError)
       from ./validateMenuSpecs.rb:132:in `each_line'
       from ./validateMenuSpecs.rb:132

with the rescue code commented out, I get:

./validateMenuSpecs.rb:153: private method `chomp' called for nil:NilClass (NoMethodError)
       from ./validateMenuSpecs.rb:132:in `each_line'
       from ./validateMenuSpecs.rb:132

Again.

You should then put the code that you expect to get an exception from after the begin clause.

HTH

Ghislain

--
Xeno Campanoli, xeno@eskimo.com, http://www.eskimo.com/~xeno
Pride before justice equals destabilization.
Power before truth equals destruction.
Profit before environment equals death.

I think you may be right, but for the work I was doing, the process was very similar for both languages. Thats why I made the comment about doing something more complex. Not all extensions involve creating objects.

Stephen

···

In message <Bwwpe.48835$795.1509211@twister1.libero.it>, gabriele renzi <surrender_it@remove-yahoo.it> writes

  For the work I was doing, Python had the same qualities you describe. It was amazing how similar the process was. But what I was doing wasn't a huge extension, just some wrappers to calls written in >>C++.
If I get to do something more complex for both languages I'll provide more feedback.

well, but IIRC python's extensions have this bad thing that you have to handle the refcounting by yourself instead of relying on a real gc, am I wrong?

--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

I have written complex extensions for both Ruby and Python in both C and
C++. C is pretty straightforward to wrap for both languages. They are
similar enough that the process can be somewhat automated (SWIG).

Complex C++ is another matter entirely. Generally a translation layer
needs to be written to handle at least the C++/Ruby exception translation
or you'll end up with severe memory leaks or core dumps. The process
is non-trivial for both Ruby and Python but it can be done. SWIG can
help here but there is still alot of manual work that has to be done.

Rick

···

On Wed, Jun 08, 2005 at 06:10:27PM +0900, Stephen Kellett wrote:

I think you may be right, but for the work I was doing, the process was
very similar for both languages. Thats why I made the comment about
doing something more complex. Not all extensions involve creating
objects.

--
Rick Nooner
rick@nooner.net