Puzzled by LC 9.6.2 error

[jmk_phd]

Although I'd given up on LC Indy 9.x just to make the app work for now -- which may come back to bite me later when required to support newer versions of macOS and Windows -- I definitely will pursue the very smart debugging strategies suggested by Bernard, AxWald, and AndyP.

For example, it may be that a .csv text file created in the LC 8.10 standalone -- which holds all 359 responses as comma-delimited items -- is no longer read properly in LC 9.x. (Note that the standalone built using LC 8.10 works just fine when creating and reading document files.)

I've triple-checked the .csv files and confirmed that no enry is faulty.

I've never tried the CSV validator recommended by Bernand, but I definitely will.

In reply to AndyP, I've actually scrutinized the raw CSV files by importing these into Excel. No hidden returns or end lines spotted.

I've yet to try AxWald's very ingenious code for parsing CSV, but will do so soon.

I am incredibly grateful to the forum members who have proposed better solutions, even after I gave up on 9.x that caused my app to fail in the IDE. (The the 8.10 Win/Mac standalones seem to work just fine at least for now, if not into the future.)

Thanks,

jeff k

[jacque]

If it worked in LC 8 but fails in LC 9 then it sounds like a regression bug. I'd submit a bug report.
https://quality.livecode.com

[Bernard]

In reply to AndyP, I've actually scrutinized the raw CSV files by importing these into Excel. No hidden returns or end lines spotted.
[...]
I am incredibly grateful to the forum members who have proposed better solutions, even after I gave up on 9.x that caused my app to fail in the IDE.

One of the issues with CSV is that often tools have built in tricks for automatically dealing with edge cases. That's what Excel might be doing.

There are people parsing CSV with LC every day. It's just about the simplest kind of processing (in principle).

To submit a bug report you'll need to provide your CSV file and a minimal stack which exhibits the problem. We're flying blind here. And we've probably reached the end of what we can do without seeing at least the CSV file.

[AxWald]

Hi,

as Jacque said.

If this line:

Code: Select all

   put item pReverseItem of sScoreList into tThisResponse

blows up in LC 9 but runs flawlessly in LC 8 then there's something buried in the code. Something that doesn't smell well.

What happens:

1. LC evaluates pReverseItem as an integer
2. Then it evaluates sScoreList as CSV (Char Separated Values), using the itemDelimiter.
3. and tries to extract item (pReverseItem) of it.
4. The result then is put into tThisResponse.

So, what could go wrong?

• value(pReverseItem) could be "not an integer". This will cause an error if it's used to extract a certain (numbered) item.
• sScoreList? Even "put item 256 of empty" doesn't throw an error, just returns empty. This seems harmless.
• If tThisResponse isn't locked for some unknown reason there's hardly a cause for error. A variable is overwritten or, if it doesn't exist, created.

Thus the most likely cause is that pReverseItem has a value somewhere that's interpreted as:
- an integer in LC 8, and
- as "not an integer" in LC 9.
This looks like a serious anomaly for me, and should be investigated, IMO.

Have fun!

[bn]

@ Jeff K.

does the CSV data pass through a field? I.e. do you put the CSV data into a field before processing and retrieve the data from there? Just a wild guess that the comma delimited data is wider than a field allows.
If I recall that correctly the width limit of fields are more stricly enforced in recent versions of LC.

Kind regards
Bernd

[jmk_phd]

To all --

Although I remain convinced that there is a glitch somewhere in how LC 9.x handles my original 8.10 stack -- at least six raw data .csv files are processed without error when run in the IDE LC 8.10, yet all fail in LC 9.2 -- I've been unable to reproduce the error when running a new stack that includes only a very bare-bones version of the scoring routine, handling only 3 of the 31 scales (and ignoring both the demographic information and response times included in the the raw .csv data file).

I will persist -- assuming that at some point I must recreate the standalones in LC 9.x or later to maintain compatibility with future versions of Win/Mac -- but the problem is apparently buried somewhere deep in the code. If ever I find the fix -- probably no time soon -- I will report back here.

Meanwhile, I am grateful beyond words for all the help and suggestions that everyone has provided. So much time borrowed from your own work just to help out with the odd glitch that I'd encountered is humbling, esp because there is no way to return the favor.

I don't know that this matters, but it may be wise advice that -- unlike me -- LC programmers use the latest available version of the IDE.

Best wishes.

jeff k

[stam]

Hi Jeff,

Most here will happily take time to help, not only because that's what this forum is for, but it's also a diversion and perhaps equally importantly it probably isn't a glitch in LC but if it is, it should be corrected.

I've been watching this thread with interest, but it all boils down to being able to reproduce the error, to see what exactly may be causing it, and that's not possible to do with the posts here, as everyone has to speculate and try and guess what the issue is.

is there any way you can share a simplified stack and the actual offending CSV?
I'm pretty sure you'd have an answer within 24 hours if you did...

Stam

[jmk_phd]

Stam --

You wrote

Is there any way you can share a simplified stack and the actual offending CSV?

I did in fact prepare a very simple stack -- just one button with a bare-bones script that scored just 3 of the 30 scales, skipping the demographic and response time info, and embedding the various lists contained in custom props instead as local or script variables.

My hope was that this short, easy to follow version of the offending script would -- as awful as this sounds -- display the error that occurs when the stack is run in LC 9.x but not 8.10, thereby enabling forum members to reproduce the problem. But this simple stack ran okay in 9.x. So the problem may be with a call to a custom prop in 9.x. (I've not yet tested this by employing custom props in this simple stack.)

Still, it is the case that the full stack runs fine in the 8.10 IDE, yet fails in the 9.x IDE.

Although posted not long ago, the actual standalone app (code-signed for Win) built using LC 8.10 is available as a free download and works just fine. Personality tests are second only to cooking recipes in popularity on the web, so anyone interested is welcome to give it a try. Just be aware that because the 359-item questionnaire is bilingual (including both English and Spanish audioclips), with several options to score and generate test reports in either language, it is a rather large download. (Thanks to LC for supporting the compressed .au audiofile format!) :

https://www.choca-assessments.com/eas-sabe-5/

Of course, I will report back here if/when I track down the problem.

jeff k

[jmk_phd]

Well, what a "Catch-22" : The macOS standalone built with LC 8.10 works fine, but cannot be notarized by Apple ("The binary uses an SDK older than the 10.9 SDK"). Unlike other standalones built with LC 9.x -- which do pass notarization -- this macOS app does still fail to execute the scoring feature both in the IDE and as a standalone.

So I'm basically back to square one. The colleague for whom I developed the app probably cares only about having a Windows version -- which does work entirely as expected as a code-signed standalone -- but I hate to abandon the macOS version.

Thanks for everyone's help. I'll be stepping through the code again in the hope of spotting something.

jeff k

[jmk_phd]

I believe that I've narrowed in on the reason why my app ran fine in LC 8.10 yet failed in LC 9.6.x:

I've rewritten the problem script to hard-code in local variables the lists that previously were stored in and retrieved from custom properties in the stack. (I'd held these in custom props to simplify making any updates to those lists.)

While doing this rewrite, I found that copy-pasting these lists from the custom props to local variables sometimes -- but not always -- resulted in an error message: "Compilation error at line xx (Script, missing "" after literal, char 1")

Retyping each list manually -- instead of copy-pasting from the custom prop -- into that line of code corrected every such error.

The script runs without error in LC 9.6.3.

Just speculation: Some of those custom property lists -- which had been copy-pasted from Excel into those custom props years ago -- may have included a glitch that was ignored/tolerated by LC 8.10, yet caught by LC 9.6.x.

I don't know that this helps anyone else, but it does confirm some thoughtful suggestions offered previously by forum members.

jeff k