Building a business case for Ruby

[Xeno Campanoli]

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

 

[Ghislain Mary]

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

 

[Xeno Campanoli]

Hi,

Xeno Campanoli a écrit :


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

 

[Xeno Campanoli]

Ghislain Mary wrote:

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

 

[gabriele renzi]

Stephen Kellett ha scritto:

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]

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?

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

 

[Rick Nooner]

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.

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

 

[Gyoung-Yoon Noh]

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.

=20
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.
=20
I'm interested to know if the same thing true of Python extensions?
=20
Thanks,
Curt
=20
=20

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

 

[John W. Long]

. . .

I just wrote a long message to a friend about this issue. I quote
here what I can:




Short Answer:
Because Ruby is better and Perl is harmful. Or better
yet, because Perl cannot match what Ruby has to offer.
But, this needs more explanation.

Long Answer:

No amount of physical evidence (or particular
attribute of the language) is going to make or break the
decision. You make the decision by your gut and then find
evidence to support that decision. The only trick is to
get others to make that same 'gut' decision.

. . .

Jim, this is a wonderful case for Ruby. Could you write it up somewhere
as an article? It would be helpful for others in the same situation as Joe.