Fastest way to know the contents of the latest line of a doc

[danielrr]

Hi all,

The subject of the message says almost all: What's the fastest way in LiveCode to know the contents of the latest line of a very long text document? And not just the last line, but the nth line?

best,

Daniel

[mrcoollion]

Put the text in a field or variable (in this case a field named "NameOfTheFieldWithTheText").

Put the below code in a button and voila...

Code: Select all

on mouseUp
    put line 9 of fld "NameOfTheFieldWithTheText" into tText
    answer tText
    put the last line of of fld "NameOfTheFieldWithTheText" into tText
    answer tText
end mouseUp

Regards,

Paul

[danielrr]

I mentioned "long" document to point to the case where the contents of the file are too long to be copied in memory. Of course you can just read the whole file and return the last line or the nth line. But in cases when such procedure is not advisable due to memory limitations, what's the fastest way to do it?

best,

Daniel

[mrcoollion]

Try this..

Code: Select all

on mouseUp
    answer file "Please choose the file you want to work with"
    put it into tFile
    if there is a file tFile then 
        put tFile into tDocumentPathAndName
    else
        answer "No file captured"
        exit mouseup
    end if
    get line 9 of URL ("file:" & tDocumentPathAndName) 
    put it into tText
    answer tText
    get the last line of URL ("file:" & tDocumentPathAndName) 
    put it into tText
    answer tText
end mouseUp

Tested it with a txt filetype.

Regards,

Paul

[dunbarx]

Mr. Coollion's method seems pretty straightforward.

But just curious; what kind of document are you thinking of? The text portion of the Encyclopedia Britannica is only 100MB or so (my estimate). That is not even close to the memory limits of the usual computers these days.

Craig Newman

[danielrr]

Code: Select all

get the last line of URL ("file:" & tDocumentPathAndName) 

Woah! Thanks. That's even better that I had expected.
The only problem with this kind of Wunder answers is that they make me wonder how much I'm still missing. By the way, how does *that* works?

best,

Daniel

[danielrr]

Mr. Coollion's method seems pretty straightforward.

But just curious; what kind of document are you thinking of? The text portion of the Encyclopedia Britannica is only 100MB or so (my estimate). That is not even close to the memory limits of the usual computers these days.

Craig Newman

Craig, I think you don't need to aproach the 100MB file to find yourself waiting too much time for the program to finits her duty when it comes to the situation where you need to consult many big files many times.

[dunbarx]

Hmmm.

Please explain what you are doing. I work almost never with external files.

In LC. I have a 3,000,000 line field with 150 MB of text. I can get any line in 10 ticks. If I put that dataset into an external file, and ask for the millionth line, it takes about the same time. What are you doing?

Craig

Oh yes.

[FourthWorld]

In LC. I have a 3,000,000 line field with 150 MB of text. I can get any line in 10 ticks. If I put that dataset into an external file, and ask for the millionth line, it takes about the same time.

Does it? 150 MBs is a big malloc. It would be interesting to know the load time separate from the seek time.

@Daniel: if you have a fairly confident sense of the max length of each line, you could use the seek command to seek to a location within the file that's safely far enough away from the file length to be sure to get a complete line, read at that point until EOF, and then get the last line of the resulting buffer in "it".

In fact, as I think about this you may not even need the extra "seek" statement, since IIRC the "read" command has as optional "at" param that can be used to set a starting offset within the file.

[capellan]

Once upon a time, I copied in a 4.7 Gb DVD the full decompressed text of Wikipedia (in spanish)
with the purpose of creating an Offline Wikipedia Reader using LiveCode.

After some failed tests and multiple experiments, I ended up splitting the big file in hundreds
of small text files. Each small text file was indexed and compressed. Accessing data with this method
resulted much, much faster than retrieving data from a single big file.

Al