LC problems with a not so gigantic stack

[dunbarx]

I have a stack with three fields and a few buttons I whipped up to process some data. In one of the fields I pasted a text file of about 1.2M. I did not think this overlarge. The stack crashed immediately.

After reopening, LC slows to a crawl in any action I perform that directly involves that field, like resizing it, and forget trying to edit it in any way. The beachball appears, and more often than not LC will crash.

Saving the stack takes several seconds. I can pull the data from that field without issue via script control and do my work, but I have to be careful never to go physically near that particular field.

I could restart from scratch, but am here to ask if this is unusual.

I am on a Mac Mini M2, OS 13.4 (Ventura) and LC 9.6.9.

Craig

[FourthWorld]

What is the encoding of the text?

[bn]

Hi Craig,

I just tested with a 3.4 Mb text file (The Project Gutenberg EBook of War and Peace, by Leo Tolstoy) and put it into a field.

I had no problem with that on a similar Mac as you used in LC 9.6.10.

I suspect that the problem you experience has to do with line length. What I mean is that the individual lines are too long. What you see can easily be caused by that. There is no limit on the length of a text but there is a limit of how long a line can be:

From the user guide in section "LiveCode Memory Limits" page 57:
Maximum length of a line in a field:
65,536 characters storage
No more than 32,786 pixels wide for display

And crashes are common in my experience when approaching /exceeding those limits.

You could test this by loading the text into a variable and then check the lenghts of the lines.
If you find that lines approach or exceed those limits I would rethink how to structure the data.

But of course it could be something different altogether.

Kind regards
Bernd

[dunbarx]

Ah, Bernd.

And Richard likely was on the same trail with his question.

Indeed, the text file I brought over was a single long line of words, and I mean long. Most of the work I did with it was parsing it into actual lines based on iterated layers of scattered identifiable words that I used as delimiters.

I never knew there was a line length limit for fields. I assumed, like with variables, that there was none. HC had a 30K field limit due to its reliance on textEdit. When LC came along, I seem to recall that limit just went away, and I was thrilled, since I had to kludge around the HC limit for decades.

Anyway, LC dealt with it as best it could, pretty well, I guess, and by that I mean it allowed the clipBoardData to force that text into a field, allowed the field to hold it, though barely, and for me to access the field text under script control. Once the text was in a variable, everything was fine.

Thank you.

Craig

[FourthWorld]

Yeah, calculating line wraps for display eats a LOT of time.

[dunbarx]

Yeah, calculating line wraps for display eats a LOT of time.

And crashes LC reliably? The string was 1.5 MB, but I have played around with a few gadgets that produced and manhandled strings that long, this way and that, and all acted virtually instantly.

It is a field thing especially, I assume.

Craig

[dunbarx]

Hmmm.

When I say "...crashes LC reliably?" I meant that nothing happened for 20 or 30 seconds, and invoking the "Force Quit" gadget showed that LC was unresponsive. So does that mean LC is dead, or just mostly dead, as Billy Crystal said in the movie "The Princess Bride"?

Craig

[FourthWorld]

Yeah, calculating line wraps for display eats a LOT of time.

And crashes LC reliably? The string was 1.5 MB, but I have played around with a few gadgets that produced and manhandled strings that long, this way and that, and all acted virtually instantly.

It is a field thing especially, I assume.

Fields are complex, but without a sample stack it's hard to say exactly what's going on. 1.5MB doesn't seem very long for a 30-second render.

[jacque]

When I say "...crashes LC reliably?" I meant that nothing happened for 20 or 30 seconds, and invoking the "Force Quit" gadget showed that LC was unresponsive. So does that mean LC is dead, or just mostly dead, as Billy Crystal said in the movie "The Princess Bride"?

That doesn't sound like a crash, it's more of a hang. LC is involved in a long process and isn't sending any data to the OS. Your script is likely in a loop trying to process line endings and the OS noticed there was no interaction. Adding a "wait 0 with messages" inside a loop might fix it.

[dunbarx]

Jacque.

Adding a "wait 0 with messages" inside a loop might fix it.

One of the coolest of gadgets to know.

But I had no loops. I only tried to paste the contents of the clipBoard into an empty field. That was messy enough. All my subsequent activity was simply getting the contents of that field into a variable. Once that worked, everything worked.

I needed to "see" the raw pasted data in order to figure out how to work the text. As I said, I had to identify certain words within it to set delimiters in order to parse the original string into workable lines that made sense to me.

I could have kept it in the clipBoardData, now that I think about it, and simply put the clipboard into a variable directly. No fields needed, but who knew? I had to see a lot of real estate, and I never thought about pulling a variable out of the debugger and viewing it that way. The "variable viewing" stack could have been resized massively, and shown as much as the large field I had.

Craig

[jacque]

Except the variable viewing stack also uses a field.

[dunbarx]

Jacque.

Except the variable viewing stack also uses a field.

So my favorite maxim, "everything is just a stack" cuts me two ways.

Craig

[dunbarx]

Jacque.

So I went to my stack, put the field into a variable and set a breakpoint. All OK.

And variable viewing stack acts just like the field did. I recall someone I know told me that.

"Hung up", someone said, I see that LC is "not responding". After 25 minutes, I force quit.

So the lesson here is, for fields: don't, just don't.

Craig

[FourthWorld]

So the lesson here is, for fields: don't, just don't.

Fields are for displaying text. If you don't need to read it, yeah, no need for the extra rendering overhead. But if you do need to read it, you'll need to read it.

So, fields: as needed.

[dunbarx]

Richard.

I do use fields.

But never again with a 1.5MB single line of text..

Craig