LiveCode Forums

I think even being able to command-period in the middle of I/O is new. The message is generated by separate code, I imagine. I don't mind the separate message, but I like the notion of their being the same. And this should apply to all blocking I/O. (I hope to get my feet wet in doing some LiveCode ...

I have not filed this for 'process' but I'm looking at it on Monday for 'driver'. I'll try to look at it for process, socket and stdin/stdout, but I don't know if I'll get to those. I might have filled this for 'driver', and if so it is reasonable to add to that. Or separate if you are not sure. (Wr...

The time to double the length of a string as in 'get s & s' is 2 microseconds plus a microsecond for every 3000 bytes of s. A million byte string takes about 340 microseconds to double.

I suspect there is something wrong with 'until empty' in 7.0. I think that problem shows up with other I/O.

A quick check is to see if this works:
(That's off the top of my head; I hope that is right.)

OK. Here is the stack. The original test is the button in the upper left corner. Except I took out the part that found the .2 s at 560,000 something so I got cleaner build-time stats. That is easy to add. I can set up a new one if you want. There might be fossils in one of the other buttons.

I tried building an million-element array with empty elements, indexed by consecutive integers. I compress( arrayEncode( it, "7.0")) and it got down to 1012 bytes! I saved that in a property. Now, for arrays with similar keys, I can pull this out for arrays bigger than 345,000 entries. (I'm thinking...

I think you are right. The dictionary passes the buck by saying "delimited by Unicode sentence breaks, as determined by the ICU library", but the examples might be contrary to that.

By the way, the new 7.0 arrayEncode() makes smaller binary strings and they compress well. The arrayDecode is still slow, though.

Hi, Al! I was about to say that I'm not sure it is a bug. It certainly is a nasty quirk. However, it has been slowing down today, and that is weird. It now takes 33 seconds. I'm up to 192 MB but I don't know what is normal for 7.0. I have a stack. Not very clean. I have added some other buttons to s...

The new arrayEncode(x,"7.0") packs arrays into half the size as before, but takes over twice as long. I'm good with that.

However, the arrayDecode(xe) is still slow. I would prefer it to be the faster one.

Well, this is the problem we all have with creating files that last longer than current version of file format. We still need a way to create old compatible files as well as the new, say, Unicode files. The question is then, what is the default? What should happen if I make a new standalone with 7, ...

Hi, Richard!

Well, the use is mitigated. I only needed to use it with arrayEncode(). I didn't even try it with arrayDecode(), it just worked.

I am confused about the array code comment.

I'm not sure why a command-period is needed to stop this. You can have a button that does a final read, close the process and turn off tRunning. (Did you intend to name that gRunning?) Do you have something like this? If you had to use command-period, then perhaps there is a confusion in the impleme...

It took 16 minutes to union two non-overlapping 500,000 element arrays. So, that is not a solution.

Another possibility would be to make an array of a thousand entries each with a thousand entries. I'd rather avoid that.

Maybe build with split?

The time to access the array is constant, about 3 microseconds for me, but a little higher in the 500,000 to 600,000 zone.