[Feature Request] Synchronous Notecard Text Find/Count Functions
complete
Lucia Nightfire
On April 18, last year in the Server user group meeting, a developer mentioned interest in implementing BUG-4906.
Since that time, a synchronous notecard line reading function was implemented.
Still, interest in implementing notecard text find/count functions continued.
Since we now have a synchronous notecard line reading function, I feel it is necessary to update the spec of how find/count functions should work.
list llNotecardTextFind(string name, string pattern, integer start, integer count, list options)
The above function works similar to llLinksetDataFindKeys() in that it uses regex and synchronous return.
Instead of keynames, notecard line numbers/columns where line data matched pattern are returned instead.
If name is not in inventory nor a UUID, start is outside of notecard line count or no matches found, this function returns an empty list.
If notecard data is not cached, a list containing NAK is returned.
With a list of notecard lines where matches were found, llGetNotecardLineSync() can used to read line data synchronously as well.
string name - Name of notecard in inventory or UUID
string pattern - A regular expression describing which notecard line numbers/columns to return.
integer start - The first occurrence of pattern to return.
integer count - The number of occurrences of pattern to return from start.
list options - Provision for optional inputs and a modular means of updating the functionality of this function in the future.
One Linden mentioned wanting the means of including occurrence counts with line numbers.
Another Linden mentioned the desire for case sensitive searches.
Another method could be a way to look for blank only.
The options param would allow for this work to be added in a follow-up.
integer llNotecardTextCount(string name, string pattern, list options)
The above function works similar to llLinksetDataCountFound() in that it uses regex and synchronous return.
A count of the number of matches made is returned.
If more than one match is found on a line, the match count is used, not 1, so the overall count can potentially be greater than number of notecard lines.
string name - Name of notecard in inventory or UUID
string pattern - A regular expression describing which notecard line numbers to return.
list options - Provision for optional inputs and a modular means of updating the functionality of this function in the future.
This is the safe means of checking for presence of search terms in notecards without worry of stack-heaping the script.
If a count is returned that could stack-heap a script, a looped alternative can then be made using llNotecardTextFind() with an incremented start param and lower count param.
Log In
Lucia Nightfire
Since the first implementation of this function allowed for both line numbers and column numbers (substringindex) to be returned, I talked with the developer about the inclusion of start and count inputs to ward against stack-heap scenarios. I updated the spec to make start/count based on occurrence instead of line numbers. This will allow for operation closest to that of llLinksetDataFindKeys().
rhet0rica Resident
Looks like it materialized as https://wiki.secondlife.com/wiki/LlFindNotecardTextSync although there's no mention yet at https://releasenotes.secondlife.com/categories/simulator.html .
Kinda bummed we didn't get a general-purpose string regex function. What gives?!
Lucia Nightfire
rhet0rica Resident
The current implementation is not to requested spec.
The current implementation does not allow the end-user to avoid stack-heaps.
The requested spec did.
I'm hoping to negotiate a change before the feature is available on aditi.
As far as general regex for strings, we can only hope that https://feedback.secondlife.com/scripting-features/p/llregex-functions is eventually implemented.
rhet0rica Resident
Lucia Nightfire Looks like you got your wish! Rider just added a count parameter to the wiki page about an hour ago.
This post was marked as
complete
Bleuhazenfurfle Resident
This, but, regex is excessive for many uses, and we don't want 101 versions of every single search command to cover all use cases.
See: https://github.com/secondlife/jira-archive/issues/10230 (and my prematurely closed additional notes at https://feedback.secondlife.com/scripting-features/p/matching-all-the-things ).
Lucia Nightfire
Bleuhazenfurfle Resident
The beauty of regex is you don't have to use any of its handlers for a simple, case-sensitive search. The search term alone is intuitive enough for beginners.
Bleuhazenfurfle Resident
Lucia Nightfire: Not saying I
don't
want regex as an option… Just the downside, is it's excessive for most use cases, and problematic if you want to search for a user-provided term, as already noted somewhere in those links I provided. If regex is going to be the one-stop search method, then we need at a minimum, a function to regex-quote strings, and a function to "build" regex's according to search methods I mention in those links — all of which I also mention in those links. At that point, it would have been easier and more efficient to just do what I mention in those links, and, all that can be done internally anyhow as a stepping-stone — as I also mention in those links. (There seems to be a bit of a theme going on here…)