[jawsscripts] Re: One of my wilder debugging discoveries
- From: "Jim Snowbarger" <Snowman@xxxxxxxxxxxxxxxx>
- To: <jawsscripts@xxxxxxxxxxxxx>
- Date: Fri, 22 Nov 2013 22:49:14 -0600
ah yes, isn't Braille a wonderful thing? Jumps right out atcha when you
look at it like that. And to be such a cute logical trick.
That's amusing, if I'm sure a bit annoying at the time.
But, doantchaa just feel good when figuring something subtle out like that?
Always makes me feel like a sharp cookie. A lot of people would miss that
one.
You know, they could have obviated the problem without using semicolons, if
they had just said, no fair assigning the results of a boolean comparison to
a variable. Lots of folks would take umbridge at that. But,
It wouldn't be that bad. Though I do wonder about the computational
efficiency implications.
But, for example, in the C language, where I make my living:
if (x = 3)
would be legal but unfavored practice. Double equal signs required by most
coding standards. A single equal sign causes assignment, not comparison.
While it's the way we talk, when we write that way, C thinks we mean
something diferent than what we do, and everybody gets confused.
It's legal, but an easy mistake to make. So, people generally eschew such
usage.
Sure, In that case, it was part of a conditional, so it's not quite the same
as what doug described. But, I don't know 'bout you guys, but I find it
much less readable to say,
x = (2 == i)
than to say,
x = FALSE
if (i == 2) then
x = TRUE
endif
Less compact, but more like I think.
But anyway. Straight talk's just easier on my head, specially at times when
my cookie is not so sharp.
----- Original Message -----
From: "Doug Lee" <doug.lee@xxxxxxxxxxxxxxxx>
To: <jawsscripts@xxxxxxxxxxxxx>
Sent: Thursday, November 21, 2013 10:27 AM
Subject: [jawsscripts] One of my wilder debugging discoveries
This just seems worth writing down for its oddity...
I was debugging a 23,000-line script this morning. Recently I started
getting really strange behavior when trying to assign collections to
variables in part of the code: I started getting the integer 1 in
place of a collection, with no obvious reason. I tried myriad
solutions and debugging tricks, sayString/sayInteger lines, etc.
Then I added a sayInteger at a particular point in the code, and presto,
the thing started working! "How strange," I thought, "that shouldn't
affect anything, it's not making an assignment..."
So I took the new line out, and the odd wrong behavior resumed.
On reading more carefully, I found that the next line after the
sayInteger I had put in began with a spurious less-than sign (<).
Apparently I had mistakenly copied that line out of a diff output
file, in which less-than signs indicate removed lines and greater-than
signs indicate added ones.
I should mention here two things: I read with punctuation off, and in
my actual code files, which are sometimes something like templates, I
use a double less-than to indicate a translatable symbol; so I am
accustomed to ignoreing less-than signs as I read anyway.
The previous line in the file was an assignment like
cLocation = locations[index]
in other words, an assignment from an array to a collection variable. The
line after that was a plain old function call, we'll say MyFunc(). So
the code before my sayInteger was added looked like
cLocation = locations[index]
< myFunc()
The JAWS script compiler treats end-of-line no different than a space
most of the time, so it read the above two lines like
cLocation = locations[index] < myFunc()
which actually means, assign to cLocations the integer (boolean) value
of the question, is locations[index] less than the return value of
myFunc()?
It so happens that myFunc() returns True, which as an integer is
1. I guess the integer value of the collection at locations[index]
was 0, so the above question's result was True, which is also a 1
when taken as an integer. This is how cLocation was getting set
to 1 instead of a collection.
Now, when I put the sayInteger call in, why did I get a different
result? The code would then look like
cLocation = locations[index]
sayInteger(...)
< myFunc()
Now the spurious less-than sign doesn't affect the assignment. JAWS
will actually make the comparison
sayInteger(...) < myFunc()
but then discard it because it's not being assigned to anything.
This had the net effect of making my cLocation assignment work
again.
And they wonder why it is said we'll spend 90% of our time debugging. :-)
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
__________�
View the list's information and change your settings at
http://www.freelists.org/list/jawsscripts
__________�
View the list's information and change your settings at
http://www.freelists.org/list/jawsscripts
Other related posts: