Bug in ruby?

[Hugh Sasse]

You might want to look up the definition of evidence, this is stretching
the word way, WAY too far.

Are we talking evidence for civil or criminal cases here?
I have provided evidence for diagnostic messages pointing to the point
in the line where the error occurs. I concede that usually this is
for syntax errors. See below.

I haven't been able to get either .NET/C# or Java to show me where on a
line a NRE/NRE occured.

The arrows you mention are probably for compile-time errors. Read: while

They generally are, I agree. I can't assert "always", and no, I
can't provide a counter example.

the source code is being read, is present in it's textual
representation, and the errors detected are ones that can be determined
from the structure of the source code. A NPE is a *runtime* error, long
after the textual form of the code is under green pastures.

There are reasons for not throwing that information away in an
interpreter.

So it looks like Ruby does this occasionally itself.
[...]

It is completely irrelevant if some languages detect some classes of
errors with precise source code locations, or that Ruby does this sort
of diagnostics at parse-time for other classes of errors than the one at
hand, when you can't bring a specific, valid counterexample to my

I don't tend to keep things with errors like this in lying around,
and can't remember off the top of my head.

statement, which is that I can't recall a language that does that for
runtime errors, specifically of the dangling pointer class of errors.

We are not discussing pointers. We are discussing method calls on
objects that don't support them, and stating where in the computation
this occurred.

Provide me with an example where a runtime problem in a complex
expression like the one you mentioned gives you exact source code
position, preferrably in a programming language I've actually heard of
before (there's enough of those), and I'll concede this point.

Just because nobody does it yet, it doesn't mean it can't be done.
[...]

Specifically, it doesn't imply (except in wishful thinking) that it
should be the job of the interpreter to provide possibly (probably)
unrelated "this -might- have gone wrong" type of information. The Ruby

If it has the AST, it shouldn't have to be probabilistic. I'm
specifically not saying this is easy, I'm saying it is desirable,
and that I accept constraints.

[...]

to losing interpreter runtime efficiency (from keeping full program
source code intact in memory, for example) to provide heuristic diagnostics.

For heuristic (guesswork), I'd agree. For sufficient exactitude, then
under control of an option (like -w) I'd be in favour.

For me, it is undesirable. If it's a problem that can be solved within
the standard library by providing a set of DbC -ish metaprogramming
features, be it so. Same if it's a missing feature that can be
implemented without ambiguous output.

I don't see how one could do that for something internal to the interpreter.

And for features that are clearly in the domain of code analysis tools,
I'm clearly against. Yes, such tools are absent in the Ruby domain. This
however doesn't imply the core interpreter should become one. I don't
want it to become a full-blown development tool, or any other form of
bloated monstrosity, the core responsibility of the interpreter is to
run Ruby code, and say when it can't stating the immediate reason why.

It's that 'statement of the reason why' I'd like improved.
Obviously there are trade-offs, and it is up to Matz. I'm simply
adding my voice to those that wish for improved diagnostics. If it
is impossible, or not practical at this time, or some other
sufficient constraint to prevent this, then fine. But if it is not
being done because there is no apparent desire for this, then I'd
like to say there is some desire for this. I fully accept that
this may run counter to other desirable attributes, such as speed
of execution, and a decision may not go in favour of better diagnostics
as a result. But to quote an early version of the Ruby Newsgroup FAQ:
http://www.rubycentral.com/faq/ruby_newsgroup_faq.txt
'You could characterize the Ruby philosophy as "there's a better way
to do it" (TABWTDI).'

Hugh

 

[Jim Cochrane]

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

def parse(string, starting, ending)
istart = string.index(starting) + starting.length
iend = string.index(ending, istart)
return string.slice(istart, iend - istart)
end

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

Just out of wild curiosity, did you ever figure this thing out? We're
very eager to learn of bugs in Ruby so they may be fixed although it really
looks like this was your error. Surely, it's not outrageous to think that
string.index(starting) can return nil. Was this the case for you?

It's not only not outrageous - if one reads the spec., it's obvious:

----------------------------------------------------------- String#index
str.index(substring [, offset]) => fixnum or nil
str.index(fixnum [, offset]) => fixnum or nil
str.index(regexp [, offset]) => fixnum or nil
------------------------------------------------------------------------
Returns the index of the first occurrence of the given _substring_,
character (_fixnum_), or pattern (_regexp_) in _str_. Returns +nil+
if not found. If the second parameter is present, it specifies the
position in the string to begin the search.

"hello".index('e') #=> 1
"hello".index('lo') #=> 3
"hello".index('a') #=> nil
"hello".index(101) #=> 1
"hello".index(/[aeiou]/, -3) #=> 4


--

 

[Jim Cochrane]

Jim Cochrane wrote:

/ ...


No, I left that one off my list because it was simple human error, not
really software-related. One outfit was using English units, the other one
Metric, and they failed to realize the discrepancy until the spacecraft was
of course.

The error I am speaking of caused a Mars spacecraft to shut down its descent
engine prematurely due to the misreading of a sensor. At least that's the
best theory so far for a spacecraft that didn't have any terminal phase
telemetry.

Thanks for the clarification. I had forgotten that there were two
different major Mars-mission errors.

Yep. Another bad one.


I think that one was mostly bad mechanical design. They were trying to do
away with human baggage handlers entirely.

I did a bit of googling/reading on it when I posted the link. It sounded
like the main cause was bad management and planning - poorly managed
requirements creep, not allocating enough time for thorough analysis of a
complext system, etc. I think there were several system-design flaws,
some of which were mechanical, but I believe I read that software
defects also contributed to the problem. Just a general, overall
foobar-ification. (I've not heard how much, if any, of the original
DIA system is still in use these days; it'd be interesting to find out.)

--

 

[Hugh Sasse]

Pardon my top posting, but I addressed these points in Ruby-Talk:226309.
Hugh