I put in some code to handle whitespace chars. Or do we need to handle
all chars in some unicode ranges?
-Alex
On 3/9/17, 10:42 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>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.li...@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 <aha...@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.li...@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*(\/?)>/s
>>>>g;
>>>> 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
>>>
>>
>
