I use this stack to handle text in very different ways. Whenever the text I'm using is ASCII, I open it with LC 6.5 or 6.6, since it is much, much faster than LC7 (with large chunks of text It may be dozens of times faster). But when I have to deal with Unicode, I have to open it with LC7.
Well, I have come to learn the hard way that none of the DP versions are really stable (that is by definition, so no problem here). The ugly things come mainly when trying to process large chunks of text, or you request many repetitions in the same handler (as when you try to recode text). In such cases it may well happen that LC provides corrupted output (aleatory non UTF chars) randomly. With a little bit of patience (an depending on python for the chunks that LC definitely can't handle) I can go on.
Now the problem: when I try to process one big chunk of text inside this program (150.000 chars), most of the time one line at the time, LC7 crashes. For instance, the following code (using the whole text) will make LC crash some times, some times not
Code: Select all
repeat while " " is in bigText
replace " " with " " in bigText
end repeat
The problem occurs with all versions of LC7, from 7 to 10. No message of corrupted stack appears. I'm using MacOS 10.9.4 on an iMac and a powerBook. I restarted the computer several times.
My question is threefold:
1. Is there a way to say whether a stack is corrupted? Is there such a thing as a temporary state of LC where a stack seems to be corrupted, but after the state has been corrected, the stack will return to normal functioning?
2. If one is to conclude that the stack is corrupted, is there a way to save a clean copy of the stack (and I don't mean just the scripts, but the whole stack). If the problem is located in one substack Is it enough to clone the substack?
3. Say the stack is clean? How do yo u deal with large Unicode texts to avoid crashes?
many thanks and best wishes
Daniel (praying every day for a stable version of LC7)