<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jun 11, 2018 at 9:47 AM Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sounds sensible. I suspect performance is not impacted whatsoever since regex patterns tend to get precompiled... but we'll see. Getting the expressions right is our first priority, optimization (if relevant) can follow in the future.<br></blockquote><div><br></div><div><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Talking about getting them right, </span>I spotted a typo in the SFImage regex. An extra, leftover }., which allowed '}" as a hex character.</div><div><br></div><div>Here is the fixed version:</div><div><br></div><div>^\s*(\d|[1-9]\d+)(\s+(\d|[1-9]\d+)){2}(\s+((0x(\d|[a-f]|[A-F]){1,8})|[1-9]\d+|\d))*\s*$<br></div><div><br></div><div><a href="https://regex101.com/r/CJ1h80/6/tests">https://regex101.com/r/CJ1h80/6/tests</a></div><div><br></div><div>What actually triggered spotting the typo was this cool regex visualization service:</div><div><br></div><div><a href="https://regexper.com/#%28%28%5Cd%7C%5B1-9%5D%5Cd%2B%29%28%5Cs%2B%28%5Cd%7C%5B1-9%5D%5Cd%2B%29%29%7B2%7D%28%5Cs%2B%28%280x%28%5Ba-f%5D%7C%5BA-F%5D%7C%5Cd%5D%29%7B1%2C8%7D%29%7C%5B1-9%5D%5Cd%2B%7C%5Cd%29%29*%5Cs%29*">https://regexper.com/#%28%28%5Cd%7C%5B1-9%5D%5Cd%2B%29%28%5Cs%2B%28%5Cd%7C%5B1-9%5D%5Cd%2B%29%29%7B2%7D%28%5Cs%2B%28%280x%28%5Ba-f%5D%7C%5BA-F%5D%7C%5Cd%5D%29%7B1%2C8%7D%29%7C%5B1-9%5D%5Cd%2B%7C%5Cd%29%29*%5Cs%29*</a></div><div><br></div><div>-Andreas</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On 6/9/2018 10:43 AM, Andreas Plesch wrote:<br>
> On Sat, Jun 9, 2018 at 1:19 PM, Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
>> good point... i've been grouping them just to keep the regexes a slight bit<br>
>> more readable, less possibility of error. we could do cleanup of those<br>
>> (group) parentheses if it is preferable.<br>
> <br>
> The parens do look more readable, at least to the casual regex reader.<br>
> Parens usually are used for capturing, eg. referencing the matched<br>
> group later although I am not sure if this is possible with XML<br>
> regexes which seem more basic. To regex regulars parens therefore may<br>
> cause human interpreters to look for those references. Also - at least<br>
> outside of XML - performance may be impacted from using a lot of<br>
> grouping.<br>
> <br>
> Probably best to just leave the parens.<br>
> <br>
> Tangentially, repeated ranges also look not so nice but are apparently<br>
> common: [0-9a-fA-F]<br>
> [0-9]|[a-f|[A-F] reads better to me and that is why I preferred that.<br>
> Not sure about any performance implications.<br>
> <br>
> -Andreas<br>
> <br>
>><br>
>> On 6/9/2018 8:45 AM, Andreas Plesch wrote:<br>
>>><br>
>>> On Sat, Jun 9, 2018 at 8:30 AM, Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
>>>><br>
>>>> On 6/8/2018 3:13 PM, Don Brutzman wrote:<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> * These regexes all assume that leading/trailing whitespace has been<br>
>>>>> removed. It is possible to prepend/append regex constructs such as (\s)+<br>
>>>>> to<br>
>>>>> consume outer whitespace.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> correction: zero or more whitespace characters (\s)* rather than one or<br>
>>>> more<br>
>>>> whitespace characters (\s)+<br>
>>><br>
>>><br>
>>> Yes, but it is not necessary to group the \s class: \s*. I am not sure<br>
>>> if prepending/appending is preferable to using the collapse whitepace<br>
>>> XML restriction. Since there are more fluent regex than XML readers,<br>
>>> it may be.<br>
>>><br>
>>> -Andreas<br>
>><br>
>><br>
>><br>
>> all the best, Don<br>
>> --<br>
>> Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
>> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
>><br>
> <br>
> <br>
> <br>
<br>
<br>
all the best, Don<br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div></div>