Puzzled by LC 9.6.2 error

[jmk_phd]

A presumably benign custom function that I created in LC Indy 8.10 has worked just fine, yet fails when I open and run the stack in 9.6.2 (or run a standalone built using that version).

It’s nothing complicated: Once the app reads a .csv (comma-delimited text) file into a script variable, it simply checks to determine whether a given item was recorded in text as either “T” or “F” and inserts a corresponding value (0 or 1) into a second script variable. (The “switch” control includes a “default” case that enters 0 if the text item is neither “T” nor “F”.)

Still, while the original .csv file (whether created in 8.10 or 9.62) is perfectly intact, this works as intended in 8.10 (and 8.10 builds) in creating a .csv of the scored results, but fails in 9.62 in creating the scored results file upon hitting an item (in this case 289 out of 359) with the error:

execution error (Chunk: error in range start expression)

I am at a loss to figure out why this is occurring in LC 9.6.2, whereas the exact same code and .csv files work just fine in 8.10.

If needed to track down the problem, I can post the code for the custom function. But, frankly, I don’t believe that this will help much, inasmuch as the code is not at all unique.

However, inasmuch as I am admittedly a bit lax about including error checking in my code, perhaps -- apart from the default case that I thought would deal with errors -- a line can be added to prevent this problem from entirely derailing the program.

Thanks. jeff k

[Bernard]

Just post the lines related to how you are looping (and any lines initializing the values in that loop expression). That's what the "range error" is pointing to.

[jmk_phd]

Thanks much for your reply, Bernard.

I’m not sure that posting the custom function in which the “error in range start expression” occurs will be of much help, inasmuch as the identical code works fine in LC Indy 8.10 yet breaks in 9.6.2. But here it is in plain text (sorry not quoted as code, but I tend to time out of the forum when composing a response online, so prefer composing this offline as plain text).

function doReverseScore pReverseItem
local tResult
local tThisResponse
put item pReverseItem of sScoreList into tThisResponse
switch
case tThisResponse is "F"
put sValuePresent into tResult
break
case tThisResponse = "T"
put sValueAbsent into tResult
break
default
put sValueAbsent into tResult
break
end switch
return tResult
end doReverseScore

It’s the fourth line that throws the error. The pReverseItem parameter is simply a number between 1 and 359, representing the position of the item in the .csv text file. The sScoreList is simply the contents of the comma-delimited text file read and saved earlier from a file on disk. (BTW, sValuePresent =3 and sValueAbsent = 0 are defined earlier.) The tThisResponse -- either “T” or “F” is converted to a numerical value (3 or 0) and tResult is the temporary local used to return the result to be added to the numerical score of the test scale being evaluated.

Still, I question whether the coding itself matters at all, inasmuch as the identical stack scores a half dozen original .csv files just fine in LC 8.10 (on an iMac running 10.6., yet all fail in LC 9.6.2 (on a newer iMac running Catalina). Curiously, a raw .csv created using 9.6.2 generates a file that can be scored just fine using 8.10, yet throws an error in 9.6.2.

Is the pReverseItem value 289 some magic limit when reading/processing the number of items in a .csv file? That’s consistently where LC 9.6.2 throws the error at the fourth line when processing more than a half dozen .csv files that were processed without error when running the identical stack in LC 8.10.

jeff k

[richmond62]

This may be totally OT, but I was unaware you could just use a 'bare' switch statement,
I thought you had to state what you were switching as in:

Code: Select all

on keyUp  KP
switch KP
case "k"
--- and so on

[jmk_phd]

Hi Richmond --

From my reading of the LiveCode dictionary (and past experience) the switchExpression is optional when declaring a switch. I could be wrong -- and things may have changed -- but this has never seemed to be a problem.

Please correct me if I'm wrong, but it would be truly odd as long as this worked OK at least through LC 8.10.

The name and value of the targeted variable in question does need to be specified in each "case" instance.

jeff k

[stam]

Hi Jeff,
the code you post seems fine, so may be worth stepping through the data to see if there is anything illegal inside item pReverseItem of sScoreList

Also for what it's worth, you can roughly halve the amount of text in your handler and possibly make it easier to step through:

Code: Select all

function doReverseScore pReverseItem
    local tResult
    put sValueAbsent into tResult
    if item pReverseItem of sScoreList = "F" then put sValuePresent into tResult
    return tResult
end doReverseScore

Stam

* Edit: shortened handler by 1 further line

[SparkOut]

Yeah, if the source of the argument is a csv file that's read in, I would lay money on it having some mangled data in there so that LiveCode can't interpret the contents of it to use as an item number.
Although a few versions ago, there was a mention of some changes to argument processing relating to empty versus null vs true vs false vs numeric vs text. It's possible that might be relevant but unclear. If I can find a link using this phone I will post it but don't hold your breath.

[jmk_phd]

You wrote

Yeah, if the source of the argument is a csv file that's read in, I would lay money on it having some mangled data in there so that LiveCode can't interpret the contents of it to use as an item number.

That would make sense except for the fact that the same csv files are read and processed correctly in LC 8.10, yet fail to be processed by LC 9.6.2.

So a mangled csv datafile doesn't seem to be a likely culprit.

Thanks for your help.

jeff k

[Bernard]

Try this

function doReverseScore pReverseItem
local tResult
local tThisResponse
if pReverseItem > the number of items in sScoreList then
put "error:" && pReverseItem &cr& the number of items in sScoreList &cr& item -3 to -1 of sScoreList
end if
put item pReverseItem of sScoreList into tThisResponse

Since your function doesn't loop, it looks like (somehow) a different number of items is being seen by the different versions of LC. Sounds very odd.

[richmond62]

the same csv files are read and processed correctly in LC 8.10, yet fail to be processed by LC 9.6.2.

Presumably this asks for a bug report.

What is going to be very difficult will be narrowing down what characters throw LC 9.6.2 off.

[dunbarx]

Hi.

"Switch" can be used either way, and what you want from it will usually tell you which version to use. Check the dictionary; two examples are right there and pretty clear.

Craig

[richmond62]

I thought I'd do something different and ran up a small stack in LC 8.2.0 dp2 (which, oddly enough, works on MacOS 12 beta 3):
-

-
Button 'GET DATA INTO A VAR' contains this script:

Code: Select all

on mouseUp
   put empty into fld "CHK"
   set the ink of me to srcCopy
   answer file "Choose a TEXT file to import"
   if the result = "cancel" 
   then exit mouseUp
   else
      put URL ("file:" & it) into BIGDATA
      put BIGDATA into fld "rawText2" --This is redundant and is only here because I tend to believe things when I see them.
   end if
   repeat until BIGDATA is empty
      put char 1 of BIGDATA into AZVUK
      delete char 1 of BIGDATA
      if AZVUK contains "-" then
         add 1 to fld "CHK"
      end if
   end repeat
end mouseUp

I went here: https://sample-videos.com/download-sample-csv.php

and downloaded the second free CSV file.

Opening it with BBEdit I found it contained 802 incidences of "-"

Running the stack in LC 8.2.0 dp2 produced 802 incidences, and in LC 9.6.2 (which ran significantly faster than 8.2.0)
worked just as well.

Where did I go "wrong"?

[jacque]

Is the pReverseItem value 289 some magic limit when reading/processing the number of items in a .csv file? That’s consistently where LC 9.6.2 throws the error at the fourth line when processing more than a half dozen .csv files that were processed without error when running the identical stack in LC 8.10.

Do you mean that the process works without error up to that number of items? On all your test files?

[jmk_phd]

Is the pReverseItem value 289 some magic limit when reading/processing the number of items in a .csv file? That’s consistently where LC 9.6.2 throws the error at the fourth line when processing more than a half dozen .csv files that were processed without error when running the identical stack in LC 8.10.

Do you mean that the process works without error up to that number of items? On all your test files?

Thanks for your reply, Jacque -- and I intend to get back to the other forum members who've posted such thoughtful replies as well.

In answer to your question: The program does *not* step through the items in the .csv file -- which consists merely of 359 comma-separated "T" and "F" characters -- sequentially. Rather, the .csv file is first read into a script local variable. Then each of 30 subroutines -- each corresponding to one of the subscales of the personality test -- looks up the items that belong to that subscale (each stored as a list of item positions in a custom prop) and assigns a number (0 or 3) to that "T" or "F" character. (Psychologists deliberately make things complicated by reverse-scoring some items -- so, for example, an item such as "I have many friends" earns a 3 on the "Positive Self-Image" scale while earning a 0 on the "Avoidant" scale.)

Apart from all of that, the issue seems to reside with LC 9.x.

I booted into macOS Sierra -- the last macOS that runs LC 8.10 -- and found again that every .csv datafile is read and scored correctly, whereas even in LC 9.04 the same stack throws the error.

My bad for developing apps for so long in my favored macOS Snow Leopard. Otherwise I might've caught the problem sooner.

Still, I can't see that my original code is at fault unless some obscure change was made to LC 9.

[Bernard]

Just to test (on 9.6.2 on a M1 Mac) that your problem lies elsewhere than LC's chunk handling, I created a list of numerical items and saved them into a customproperty.

I then trimmed down your handler just to the getting of item 289.

Code: Select all

on mouseup
   put doReverseScore(288) & cr after tx
   put doReverseScore(289) & cr after tx
   put doReverseScore(290) & cr after tx
   put tx
end mouseup

function doReverseScore pReverseItem
   put the uTest of this stack into ty
   put item pReverseItem of ty into tThisResponse
   return tThisResponse
end doReverseScore

output:
288
289
290

So it is not a problem with 289 items or more. I'd guess there's something wrong with your data or the values in your script local variables are changed elsewhere.