On 2006-11-21, Paul L. [email protected] wrote:
AliasX Neo wrote:
…
This application needs to get done
tonight, and I really can’t afford anymore time on this tiny little bug.Famous last words.
So, how’d it go? Was it finished in time and under budget? 
Jim C. wrote:
So, how’d it go? Was it finished in time and under budget?
I think the OP is a student, in any case someone who isn’t that into
programming as recreation.
Professionals don’t conceptualize program flaws as “this tiny little
bug”.
There is no such thing. All the tiny little bugs that weren’t so tiny
…
the one that disabled a US Navy destroyer running NT (after someone
entered
a zero into a user-level application and precipitated a divide-by-zero
error that brought down the entire network), which then drifted out of
control as the sailor geeks tried to restart the network. The bug that
caused the Airbus to fly into the trees during an air show low pass
(passengers on board).
The microcode bug that caused Intel processors to produce incorrect math
results, and damaged their reputation for a while.
The bug that cause Mars Polar Explorer to prematurely shut down its
engine
and fall the last 100 meters to the surface of Mars, never to be heard
from
again.
“Tiny little bug.” No such thing.
Jim C. wrote:
/ …
The bug that cause Mars Polar Explorer to prematurely shut down its
engine and fall the last 100 meters to the surface of Mars, never to be
heard from again.Due to a missing or incorrect unit conversion, right?!
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.
Or how about the Ariane 5 (
http://www.around.com/ariane.html
).
Yep. Another bad one.
I don’t remember ever hearing a description of the defect (or
defects) that caused the DIA baggage sysgtem to fail (
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html
).
I think that one was mostly bad mechanical design. They were trying to
do
away with human baggage handlers entirely.
On 2006-11-22, Paul L. [email protected] wrote:
Famous last words.
So, how’d it go? Was it finished in time and under budget?
I think the OP is a student, in any case someone who isn’t that into
programming as recreation.
Yes, that’s pretty apparent - I was being jocular, or perhaps,
facetious.
Professionals don’t conceptualize program flaws as “this tiny little bug”.
You would hope not, but from what I’ve seen in the industry, I’d not be
surprised to hear about such a statement.
There is no such thing. All the tiny little bugs that weren’t so tiny …
the one that disabled a US Navy destroyer running NT (after someone entered
a zero into a user-level application and precipitated a divide-by-zero
error that brought down the entire network), which then drifted out of
control as the sailor geeks tried to restart the network. The bug that
caused the Airbus to fly into the trees during an air show low pass
(passengers on board).The microcode bug that caused Intel processors to produce incorrect math
results, and damaged their reputation for a while.
Yep - famous bugs.
The bug that cause Mars Polar Explorer to prematurely shut down its engine
and fall the last 100 meters to the surface of Mars, never to be heard from
again.
Due to a missing or incorrect unit conversion, right?!
“Tiny little bug.” No such thing.
Or how about the Ariane 5 (
http://www.around.com/ariane.html
). I don’t remember ever hearing a description of the defect (or
defects) that caused the DIA baggage sysgtem to fail (
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html
).
Maybe a more severe word than “bug” needs to be invented.
Charles D Hixson wrote:
/ …
OTOH, it’s also true that by compiling every time I enter a new
definition I can generally handle this error with minimal problems …
but it would be a lot easier to include sufficient context markers to
ensure localization of errors.
Another solution makes use of a beautifier, frequently applied, that
shows
how one is getting off track or misinterpreting the indentations. This
is
how I sort things out as they get deep and complex.
I still prefer curly braces around everything, but that style is clearly
going out of fashion.
On 21.11.2006 23:28, Leslie V. wrote:
On 11/21/06, Charles D Hixson [email protected] wrote:
David V. wrote:
In this case the bug was in the message not stating which variable had a
nil value. You may not think of it as serious, but he reports spending
several hours on it, and I’d call that a bug.
Frankly, in this case I would attribute that to the bug searcher and not
the language. The message is pretty clear, it gives a line number and
an easy explanation. With that, you can immediately spot where it goes
wrong - even if you are unsure whether to look at the right or left side
of the “+”.
Remember, Ruby is being recommended to total neophytes as a good
language to start with. That means that good diagnostic error messages
are essential!I have also previously requested that this get fixed in a future Ruby.
It’s very annoying to try and guess which could be the offending
variable in a complex expression, and it wastes a lot of time. It
would surely be very easy for Ruby to say which variable was nil.
Actually I am not sure about this. The reason is this: the fact that
the method does not exist in the receiver is not detected prior to
runtime. And the object in question could potentially be referenced via
any number of variables (including being part of an Array). As such the
interpreter would have to remember several variable names per thread per
object to actually be able to resolve this properly. Or it would have
to go back to the source to determine this. And what do you do in this
case where it is the result of a method call? As you see, it is not
that easy and can incur some overhead you might not want to pay either.
Having said that, nobody forces you to create complex expressions. You
can help readability and maintainability a lot if you break those down -
which in turn makes debugging easier.
In some of my latest scripts I have this:
def preventNil(*args)
args.each_with_index do |arg, i|
raise ArgumentError.new(“argument #{i} cannot be nil”) if arg.nil?
end
end
I’d be interested to hear if there are nicer solutions to this problem.
The problem I see here is that the fact it’s not nil does not tell you
that it is actually a proper value. So at best you only catch some
errors with this approach.
Kind regards
robert
Leslie V. wrote:
variables that point to nil in the interpreter, and the culprit is also
usually an expression. Finding the possible expressions that returned a
nil would require tracing back to the literal in the stack frames, and
even then the last one wouldn’t have to be the cause of the problem. I
stand by my point that this is not the job of a core language runtime,
but of manual or automated code review.It just seems like it would be easier than that, since Ruby is an
interpreter. Doesn’t the last sub-expression get stored in a string
somewhere as the expression is parsed?
Remember in modern interpreted languages that interpretation and
execution
are separate phases. The bug this thread is about was a runtime bug, not
one of interpretation. Once runtime begins in earnest, such niceties as
variable identities and even sometimes line numbers are lost in the name
of
efficiency.
Anyway, I am just now noticing that 5+nil and nil+5 return different
error messages. As long as an operator is unique in an expression, it
should be easy to figure out which is nil.
In this case, some simple, focused testing strategies needed to be
applied.
Notwithstanding the OP’s insistence that he tried everything, there was
an
obvious test he didn’t apply.
“AliasX Neo” [email protected] wrote in message
news:[email protected]…
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?
Thank you…
Hugh S. wrote:
/ …
Coding defensively and using sanity checks on the return value of #index
and other methods that may return nil would also have helped.This doesn’t mean that is is undesirable that Ruby do more.
At the expense of runtime speed. Every added hand-holding feature in
effect
at runtime decreases runtime speed.
This is shifting the burden from the developers of ruby
to the many users of it.
Your suggestion shifts the burden from developers of Ruby code to the
end
users of Ruby programs, who would have to put up with time-costly error
detection features running in the background meant to detect and
describe
runtime errors that ought to have been caught during the design phase.
IMHO this entire class of problem is better dealt with by better design
and
better testing, not more loquacious error messages during runtime.
On 2006-11-22, Paul L. [email protected] 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.
).
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.)
Pardon my top posting, but I addressed these points in Ruby-Talk:226309.
Hugh
On 2006-11-22, Just Another Victim of the Ambient M.
[email protected] wrote:
iend = string.index(ending, istart)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:
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs