flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FalconJX] regex patterns
Date Thu, 09 Mar 2017 18:42:06 GMT
Here’s one of them:

static private const anyPrintChar:RegExp = /[^\u0009\u000a\u000d\u0020]/g; 

outputs:

org.apache.flex.textLayout.elements.SpanElement.anyPrintChar = /[^	

 ]/g;

> On Mar 9, 2017, at 8:20 PM, Harbs <harbs.lists@gmail.com> wrote:
> 
> Yes. These are from TLF. The strings are evaluated by Java. There’s no error except
on the Javascript side because the string literals become non-sensical.
> 
> We had a similar issue when porting our app. I think we used String.fromCharCode() to
get around the problem there.
> 
> Basically, we need some way to tell the compiler that any strings used in RegExp objects
should come through bit-for-bit identical and not be evaluated as Strings. I have no idea
what’s involved in doing that in Java...
> 
>> On Mar 9, 2017, at 7:43 PM, Alex Harui <aharui@adobe.com> wrote:
>> 
>> Are these from TLF?  What error are you getting?  Falcon compiles TLF as
>> part of the integration tests.  Is it the JS output that is broken?
>> 
>> Thanks,
>> -Alex
>> 
>> On 3/9/17, 1:18 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>> 
>>> I’ve come across quite a few regex patterns which break compilation.
>>> Here’s some examples:
>>> 
>>> private static const _newLineTabPattern:RegExp = /[\u0009\u000a\u000d]/g;
>>> static private const brRegEx:RegExp = /\u2028/;
>>> private static const _newLineRegex:RegExp = /\u000A|\u000D\u000A?/g;
>>> public static const anyPrintChar:RegExp = /[^\u0009\u000a\u000d\u0020]/g;
>>> public static const attrRegex:RegExp =
>>> /\s+(\w+)(?:\s*=\s*(".*?"|'.*?'|[\w\.]+))?/sg;
>>> public static const tagRegex:RegExp =
>>> /<(\/?)(\w+)((?:\s+\w+(?:\s*=\s*(?:".*?"|'.*?'|[\w\.]+))?)*)\s*(\/?)>/sg;
>>> public static const stripRegex:RegExp =
>>> /<!--.*?-->|<\?(".*?"|'.*?'|[^>"']+)*>|<!(".*?"|'.*?'|[^>"']+)*>/sg;
>>> 
>>> The last three have to do with unsupported flags, but the first four
>>> break simply because the compiler evaluates the strings and they become
>>> spaces and line breaks, etc.
>>> 
>>> What can we do to prevent the compiler from killing patterns during
>>> compilation?
>>> 
>>> Harbs
>> 
> 


Mime
View raw message