You are currently not logged in! Enter your authentication credentials below to log in. You need to have cookies enabled to log in.
This shows you the differences between two versions of the page.
|
articles:regex [2021-04-09 11:34 SLT] sei Change one of the labels to do...while |
articles:regex [2023-04-08 15:31 SLT] (current) sei Wizardry and Steamworks pages now deleted due to a DMCA |
||
|---|---|---|---|
| Line 526: | Line 526: | ||
| ==== Motivation ==== | ==== Motivation ==== | ||
| - | There's a page in the Second Life wiki that introduces a so-called "[[http://wiki.secondlife.com/wiki/LSL_Regex_Engine|regex engine]]", to disprove the argument that a "regular expression engine in LSL will not work well". However, the argument is basically framed as a [[https://en.wikipedia.org/wiki/Straw_man|straw-man]]: it builds an engine that is so limited that it isn't even capable of parsing most regular languages, and therefore can't really be characterized as a regular expression engine in the theoretical sense. | + | There was a page in the Second Life wiki titled "LSL Regex Engine", which is now gone due to a DMCA applying to all of the Wizardry and Steamworks pages, that introduced a so-called "regex engine" to disprove the argument that a "regular expression engine in LSL will not work well". However, the argument was basically framed as a [[https://en.wikipedia.org/wiki/Straw_man|straw-man]]: it built an engine that was so limited that it wasn't even capable of parsing most regular languages, and therefore couldn't really be characterized as a regular expression engine in the theoretical sense. |
| - | So I (Sei Lisa) set up to build an engine that is able to parse any regular language (limited in practice by LSL memory of course), using a large enough subset of the syntax of [[https://pubs.opengroup.org/onlinepubs/7908799/xbd/re.html#tag_007_004|POSIX EREs]] as to guarantee that all regular languages are covered. The result is not too practical, but it also isn't as bad as I thought. It is able to understand somewhat complex regular expressions (see tests), though the cost of parsing (compiling) is prohibitive with complex expressions for run-time use; however, the cost of matching is not extremely bad, and it might even find some practical applications. My advice is not to use it with long input text (say 40 chars or more), because matching is not too fast. Matching speed also depends on the complexity of the (compiled version of the) regular expression itself, so be careful with that if using it in any serious application. Run some benchmarks with your regex and be careful to limit the length of the input text if necessary. | + | So I (Sei Lisa) set up to build an engine that is able to parse any regular language (limited in practice by LSL memory of course), using a large enough subset of the syntax of [[https://pubs.opengroup.org/onlinepubs/7908799/xbd/re.html#tag_007_004|POSIX EREs]] as to guarantee that all regular languages are covered. The result is not too practical, but it also isn't as bad as I thought. It is able to understand somewhat complex regular expressions, though the cost of parsing (compiling) is prohibitive with complex expressions for run-time use; however, the cost of matching is not extremely bad, and it might even find some practical applications. My advice is not to use it with long input text, say 40 chars or more, because matching is not too fast. Matching speed also depends on the complexity of the (compiled version of the) regular expression itself, so be careful with that if using it in any serious application. Run some benchmarks with your regex and be careful to limit the length of the input text if necessary. |