At a Macro level, it doesn't really practically matter that the nearest inhabitable planet is 10 or 100 light years away. We'll never get there On a micro level it doesn't seem to matter that it takes 1ms or 10ms to complete a function or command. No one will notice.
I guess the real questions are, how long does it take to find the last line in the largest bit of text Livecode can handle, and is using lineOffset the best way to handle extremely large strings? And who needs to work with extremely long text strings in the first place?? It seems to me that this is a kind of niche application. I begin to wonder how Microsoft Word does it? If you want to find a word toward the end of a very large document, I think it's understood that it might take a while. No one expects the results to be instantaneous, so long as there is some kind of progress indicator. So my gut feeling is, for smaller strings the time it takes is really inconsequential. For larger strings it seems like adding an argument to the existing function to designate what data you want returned would suffice. Also, didn't someone do some work comparing lineOffset with repeat for each line? Once you find the line, you found it, and you could do multiple string comparisons in one pass as an added bonus. If I had an absurdly long bit of text to work with I'd do it myself. my 2ยข Bob S > On Oct 29, 2015, at 08:47 , Richard Gaskin <ambassa...@fourthworld.com> wrote: > > Currently we have the lineOffset function, a very handy way to know the > number of a line that matches whatever we're searching for in a block of > return-delimited text. > > However, like most chunk expressions it's able to do what it does by > evaluating every character in the chunk, both looking for the matching string > and counting CRs as it goes. > > Many times when we're using lineOffset it's because what we're after isnt the > line number but the text of that line. And getting that requires another > traversal of the entire chunk to "get line <lineNumber> of <chunk>". > > Given how handy chunk expressions are in LiveCode, I'm wondering if it might > be even handier to see the introduction of a new function, something that > could perhaps be called "lineAtOffset". > > Like "lineOffset", "lineAtOffset" would take the same arguments and operate > similarly, but rather than returning the number of the matching line it would > return the text of that line. > > Questions for you folks: > > 1. Is this as useful as I think it might be? > > 2. Is there a better name for the function? > > 3. Would consistency with wordOffset, trueWordOffiset, and itemOffset bog > this down to the point where we'd either have to face an inconsistent world > in which only lineAtOffset is supported or wait much longer for a more > complete implementation that would also do the others (itemAtOffset, etc). > Personally, I'd be fine if this were limited to lines since the other chunk > types aren't usually long enough in my own work to have much impact on > performance having to make two calls. But as I've noted before, sometimes > I'm too easily satisfied and others may have more demanding requirements. > > 3. Is this worth submitting to the request queue? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
