Jenkins build is back to normal : royale-typedefs #606

2018-08-08 Thread apacheroyaleci
See 




Jenkins build is back to normal : royale-compiler #376

2018-08-08 Thread apacheroyaleci
See 




Build failed in Jenkins: royale-compiler #375

2018-08-08 Thread apacheroyaleci
See 


--
[...truncated 84.08 KB...]

css.tree:
 [echo] Generating CSSTree
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xmx512m

antlr:

set.unknown.tree.handler.patterns.uptodate:

unknown.tree.handler.patterns:
[mkdir] Created dir: 

 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xmx512m

set.cmc.emitter.uptodate:

cmc.emitter:
 [echo] Generating CmcEmitter
[mkdir] Created dir: 

 [java] Using Language Adaptor : jburg.burg.emitlangs.EmitJava
 [java] Using i-node adapter 
org.apache.royale.compiler.internal.as.codegen.IASNodeAdapter
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xmx512m
 [java] Adding @SuppressWarnings({"rawtypes", "unchecked", "unused"}) to 
class: 


set.css.emitter.uptodate:

css.emitter:
 [echo] Generating CSSEmitter
[mkdir] Created dir: 

 [java] Using Language Adaptor : jburg.burg.emitlangs.EmitJava
 [java] Using i-node adapter jburg.burg.inode.DefaultAdapter
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xmx512m
 [java] Adding @SuppressWarnings({"rawtypes", "unchecked", "unused"}) to 
class: 


jburg:

eclipse:

src.depend:

compile:
[javac] Compiling 1545 source files to 

[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] 
:29:
 warning: [overrides] Class DefinitionPriority overrides equals, but neither it 
nor any superclass overrides hashCode method
[javac] public final class DefinitionPriority implements IDefinitionPriority
[javac]  ^
[javac] 
:1486:
 warning: [overrides] Class UserDefinedNamespaceReference overrides equals, but 
neither it nor any superclass overrides hashCode method
[javac] private static class UserDefinedNamespaceReference implements 
INamespaceResolvedReference
[javac]^
[javac] 
:46:
 warning: [overrides] Class MetaTagsNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class MetaTagsNode extends ContainerNode implements 
IMetaTagsNode
[javac]^
[javac] 
:29:
 warning: [overrides] Class TypedTagNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class TypedTagNode extends MetaTagNode implements 
ITypedTagNode
[javac]^
[javac] 
:32:
 warning: [overrides] Class DefaultPropertyTagNode overrides equals, but 
neither it nor any superclass overrides hashCode method
[javac] public class DefaultPropertyTagNode extends MetaTagNode implements 
IDefaultPropertyTagNode
[javac]^
[javac] 
:30:
 warning: [overrides] Class EffectTagNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public final class EffectTagNode extends 

Re: XML filters broke

2018-08-08 Thread Harbs
OK. I think I cherry-picked the files, although there were some conflicts. I 
hope I resolved them correctly.

> On Aug 9, 2018, at 12:45 AM, Alex Harui  wrote:
> 
> The ones in Storage seem to have very different APIs that the flash versions 
> and are in a different package.  I'm not sure it is worth worrying about 
> right now.
> 
> AIUI, the ones in Network are intended to mimic the flash versions and are 
> what our users are looking for.
> 
> My 2 cents,
> -Alex
> 
> On 8/8/18, 2:43 PM, "Harbs"  wrote:
> 
>It looks like we have duplicate classes in Storage and Network. I think we 
> need to pick which package these classes belong in.
> 
> 
>> On Aug 9, 2018, at 12:38 AM, Alex Harui  wrote:
>> 
>> There's an IDataInput/IDataOutput in the Network.swc in the develop branch 
>> that would be useful to have in the feature/MXRoyale branch.  I don't want 
>> to stop to do a full merge right now.
>> 
>> -Alex
>> 
>> On 8/8/18, 2:36 PM, "Harbs" > > wrote:
>> 
>>   What’s the issue with IDataInput/IDataOutput? Cherrypicked from where?
>> 
>>> On Aug 8, 2018, at 11:48 PM, Alex Harui  wrote:
>>> 
>>> Won’t know until we try it.  I'll adjust XMLList as needed.  I have an 
>>> actual test case with Tour De Flex to work with.
>>> 
>>> If you have time to cherrypick IDataInput/IDataOutput for our users that 
>>> would be helpful.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> On 8/8/18, 1:31 PM, "Harbs"  wrote:
>>> 
>>>  Are you sure the logic to reassign this will work here?
>>> 
>>>  I’m willing to rewrite the code in XMLList to use call if you think it’ll 
>>> make things easier in the compiler…
>>> 
 On Aug 8, 2018, at 11:03 PM, Alex Harui  wrote:
 
 
 
 On 8/8/18, 12:59 AM, "Harbs" >>> > wrote:
 
 Does “this” in call/apply even work for a function which is not a 
 prototype function? I thought in that case “this” is the global context.
 
 From my testing, the 'this' can be re-assigned as we want it.
 
 I think 6a is kind of ambiguous. Why do you think there’s a difference 
 between the following (other than avoiding ambiguous this references)?
 
 Because there is already code that distinguishes when 'this' is supposed 
 to be used.  So we should use it instead of crafting a whole other set of 
 code that has a more difficult problem to solve, like whether an 
 expression is relative to a parameter and if so, which parameter?
 
 My 2 cents,
 -Alex
 
 function() { return (over40(parseInt(this.age))) }
 and 
 function(node) { return (over40(parseInt(node.age))) }
 
 Although in fact, I think it would need to be:
 
 function(node) { return (over40(parseInt(node.child(“age” }
 
> On Aug 8, 2018, at 10:33 AM, Alex Harui  wrote:
> 
> EmitterUtils.writeThis seems to be working ok.  I think it would be 
> better/correct to use it here.  I'm not sure if node as a parameter 
> creates the same scope chain as node being the this pointer.  I think no, 
> I don't think parameters are involved in lexical scoping.   IMO, 6a in 
> the spec is saying we should make node the 'this' pointer in JS.
> 
> My 2 cents,
> -Alex
> 
> On 8/7/18, 10:54 AM, "Harbs"  wrote:
> 
> I’m not following you. Wouldn’t we need the same logic to figure out 
> where to insert “this”? I’m not sure what practical difference there 
> would be between “node" and “this”, other than using apply or call. 
> Passing in the XML node seems cleaner to me.
> 
>> On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
>> 
>> Yup.  After thinking about it some more, it occurs to me that we took 
>> the wrong starting point.  Right now code like:
>> 
>> over40(parseInt(age))
>> 
>> Results in:
>> 
>> function(node) { return (over40(parseInt(age))) }
>> 
>> And then the XML filter calls that function passing itself in as the 
>> node.
>> 
>> And this discussion has been about trying to figure out where to add the 
>> "node" parameter.  But now I think that 6a in the spec is really saying 
>> that the 'this' pointer should be the node.  We should transpile that 
>> filter expression like any other function body but assume it is a 
>> function run in the context of the node, like a new method on 
>> XML/XMLList, or maybe more like an anonymous function.
>> 
>> So if I'm right, then the output should be:
>> 
>> function() { return (over40(parseInt(this.age))) }
>> 
>> This is what the transpiler would have output if you had subclassed XML 
>> and added this method to it.  And then the code in XML.SWC that applies 
>> the filter has to use Function.apply/call passing the node as the 'this' 
>> pointer.
>> 
>> If we do that, then the EmitterUtils.writeE4xFilterNode would go away, 
>> and 

Re: XML filters broke

2018-08-08 Thread Alex Harui
The ones in Storage seem to have very different APIs that the flash versions 
and are in a different package.  I'm not sure it is worth worrying about right 
now.

AIUI, the ones in Network are intended to mimic the flash versions and are what 
our users are looking for.

My 2 cents,
-Alex

On 8/8/18, 2:43 PM, "Harbs"  wrote:

It looks like we have duplicate classes in Storage and Network. I think we 
need to pick which package these classes belong in.


> On Aug 9, 2018, at 12:38 AM, Alex Harui  wrote:
> 
> There's an IDataInput/IDataOutput in the Network.swc in the develop 
branch that would be useful to have in the feature/MXRoyale branch.  I don't 
want to stop to do a full merge right now.
> 
> -Alex
> 
> On 8/8/18, 2:36 PM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>What’s the issue with IDataInput/IDataOutput? Cherrypicked from where?
> 
>> On Aug 8, 2018, at 11:48 PM, Alex Harui  wrote:
>> 
>> Won’t know until we try it.  I'll adjust XMLList as needed.  I have an 
actual test case with Tour De Flex to work with.
>> 
>> If you have time to cherrypick IDataInput/IDataOutput for our users that 
would be helpful.
>> 
>> Thanks,
>> -Alex
>> 
>> On 8/8/18, 1:31 PM, "Harbs"  wrote:
>> 
>>   Are you sure the logic to reassign this will work here?
>> 
>>   I’m willing to rewrite the code in XMLList to use call if you think 
it’ll make things easier in the compiler…
>> 
>>> On Aug 8, 2018, at 11:03 PM, Alex Harui  
wrote:
>>> 
>>> 
>>> 
>>> On 8/8/18, 12:59 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
>>> 
>>>  Does “this” in call/apply even work for a function which is not a 
prototype function? I thought in that case “this” is the global context.
>>> 
>>> From my testing, the 'this' can be re-assigned as we want it.
>>> 
>>>  I think 6a is kind of ambiguous. Why do you think there’s a difference 
between the following (other than avoiding ambiguous this references)?
>>> 
>>> Because there is already code that distinguishes when 'this' is 
supposed to be used.  So we should use it instead of crafting a whole other set 
of code that has a more difficult problem to solve, like whether an expression 
is relative to a parameter and if so, which parameter?
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>>  function() { return (over40(parseInt(this.age))) }
>>>  and 
>>>  function(node) { return (over40(parseInt(node.age))) }
>>> 
>>>  Although in fact, I think it would need to be:
>>> 
>>>  function(node) { return (over40(parseInt(node.child(“age” }
>>> 
 On Aug 8, 2018, at 10:33 AM, Alex Harui  
wrote:
 
 EmitterUtils.writeThis seems to be working ok.  I think it would be 
better/correct to use it here.  I'm not sure if node as a parameter creates the 
same scope chain as node being the this pointer.  I think no, I don't think 
parameters are involved in lexical scoping.   IMO, 6a in the spec is saying we 
should make node the 'this' pointer in JS.
 
 My 2 cents,
 -Alex
 
 On 8/7/18, 10:54 AM, "Harbs"  wrote:
 
 I’m not following you. Wouldn’t we need the same logic to figure out 
where to insert “this”? I’m not sure what practical difference there would be 
between “node" and “this”, other than using apply or call. Passing in the XML 
node seems cleaner to me.
 
> On Aug 7, 2018, at 6:50 PM, Alex Harui  
wrote:
> 
> Yup.  After thinking about it some more, it occurs to me that we took 
the wrong starting point.  Right now code like:
> 
> over40(parseInt(age))
> 
> Results in:
> 
> function(node) { return (over40(parseInt(age))) }
> 
> And then the XML filter calls that function passing itself in as the 
node.
> 
> And this discussion has been about trying to figure out where to add 
the "node" parameter.  But now I think that 6a in the spec is really saying 
that the 'this' pointer should be the node.  We should transpile that filter 
expression like any other function body but assume it is a function run in the 
context of the node, like a new method on XML/XMLList, or maybe more like an 
anonymous function.
> 
> So if I'm right, then the output should be:
> 
> function() { return (over40(parseInt(this.age))) }
> 
> This is what the transpiler would have output if you had subclassed 
XML and added this method to it.  And then the code in XML.SWC that applies the 
filter has to use Function.apply/call passing the node as the 'this' pointer.
> 
> If we do that, then the EmitterUtils.writeE4xFilterNode would go 
away, and JSRoyaleEmitter.emitE4xFilter would temporarily change the 
model.currentClass and maybe a few other things to reference 

Re: XML filters broke

2018-08-08 Thread Harbs
It looks like we have duplicate classes in Storage and Network. I think we need 
to pick which package these classes belong in.


> On Aug 9, 2018, at 12:38 AM, Alex Harui  wrote:
> 
> There's an IDataInput/IDataOutput in the Network.swc in the develop branch 
> that would be useful to have in the feature/MXRoyale branch.  I don't want to 
> stop to do a full merge right now.
> 
> -Alex
> 
> On 8/8/18, 2:36 PM, "Harbs"  > wrote:
> 
>What’s the issue with IDataInput/IDataOutput? Cherrypicked from where?
> 
>> On Aug 8, 2018, at 11:48 PM, Alex Harui  wrote:
>> 
>> Won’t know until we try it.  I'll adjust XMLList as needed.  I have an 
>> actual test case with Tour De Flex to work with.
>> 
>> If you have time to cherrypick IDataInput/IDataOutput for our users that 
>> would be helpful.
>> 
>> Thanks,
>> -Alex
>> 
>> On 8/8/18, 1:31 PM, "Harbs"  wrote:
>> 
>>   Are you sure the logic to reassign this will work here?
>> 
>>   I’m willing to rewrite the code in XMLList to use call if you think it’ll 
>> make things easier in the compiler…
>> 
>>> On Aug 8, 2018, at 11:03 PM, Alex Harui  wrote:
>>> 
>>> 
>>> 
>>> On 8/8/18, 12:59 AM, "Harbs" >> > wrote:
>>> 
>>>  Does “this” in call/apply even work for a function which is not a 
>>> prototype function? I thought in that case “this” is the global context.
>>> 
>>> From my testing, the 'this' can be re-assigned as we want it.
>>> 
>>>  I think 6a is kind of ambiguous. Why do you think there’s a difference 
>>> between the following (other than avoiding ambiguous this references)?
>>> 
>>> Because there is already code that distinguishes when 'this' is supposed to 
>>> be used.  So we should use it instead of crafting a whole other set of code 
>>> that has a more difficult problem to solve, like whether an expression is 
>>> relative to a parameter and if so, which parameter?
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>>  function() { return (over40(parseInt(this.age))) }
>>>  and 
>>>  function(node) { return (over40(parseInt(node.age))) }
>>> 
>>>  Although in fact, I think it would need to be:
>>> 
>>>  function(node) { return (over40(parseInt(node.child(“age” }
>>> 
 On Aug 8, 2018, at 10:33 AM, Alex Harui  wrote:
 
 EmitterUtils.writeThis seems to be working ok.  I think it would be 
 better/correct to use it here.  I'm not sure if node as a parameter 
 creates the same scope chain as node being the this pointer.  I think no, 
 I don't think parameters are involved in lexical scoping.   IMO, 6a in the 
 spec is saying we should make node the 'this' pointer in JS.
 
 My 2 cents,
 -Alex
 
 On 8/7/18, 10:54 AM, "Harbs"  wrote:
 
 I’m not following you. Wouldn’t we need the same logic to figure out where 
 to insert “this”? I’m not sure what practical difference there would be 
 between “node" and “this”, other than using apply or call. Passing in the 
 XML node seems cleaner to me.
 
> On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
> 
> Yup.  After thinking about it some more, it occurs to me that we took the 
> wrong starting point.  Right now code like:
> 
> over40(parseInt(age))
> 
> Results in:
> 
> function(node) { return (over40(parseInt(age))) }
> 
> And then the XML filter calls that function passing itself in as the node.
> 
> And this discussion has been about trying to figure out where to add the 
> "node" parameter.  But now I think that 6a in the spec is really saying 
> that the 'this' pointer should be the node.  We should transpile that 
> filter expression like any other function body but assume it is a 
> function run in the context of the node, like a new method on 
> XML/XMLList, or maybe more like an anonymous function.
> 
> So if I'm right, then the output should be:
> 
> function() { return (over40(parseInt(this.age))) }
> 
> This is what the transpiler would have output if you had subclassed XML 
> and added this method to it.  And then the code in XML.SWC that applies 
> the filter has to use Function.apply/call passing the node as the 'this' 
> pointer.
> 
> If we do that, then the EmitterUtils.writeE4xFilterNode would go away, 
> and JSRoyaleEmitter.emitE4xFilter would temporarily change the 
> model.currentClass and maybe a few other things to reference an XML 
> object.
> 
> Thoughts?
> -Alex
> 
> PS: Regarding adding tests, the filter tests have two variables.  "var a" 
> sets up the XML, "var b" is the result of the filter.  getVariable 
> returns the nodes for "a" then we go get child(1) which is "b" and then 
> emit it to see what we get.
> 
> On 8/7/18, 3:51 AM, "Harbs"  > wrote:
> 
> I’m also pretty sure that the following from Mozilla’s page[1] will not 
> work correctly:
> 

Re: XML filters broke

2018-08-08 Thread Alex Harui
There's an IDataInput/IDataOutput in the Network.swc in the develop branch that 
would be useful to have in the feature/MXRoyale branch.  I don't want to stop 
to do a full merge right now.

-Alex

On 8/8/18, 2:36 PM, "Harbs"  wrote:

What’s the issue with IDataInput/IDataOutput? Cherrypicked from where?

> On Aug 8, 2018, at 11:48 PM, Alex Harui  wrote:
> 
> Won’t know until we try it.  I'll adjust XMLList as needed.  I have an 
actual test case with Tour De Flex to work with.
> 
> If you have time to cherrypick IDataInput/IDataOutput for our users that 
would be helpful.
> 
> Thanks,
> -Alex
> 
> On 8/8/18, 1:31 PM, "Harbs"  wrote:
> 
>Are you sure the logic to reassign this will work here?
> 
>I’m willing to rewrite the code in XMLList to use call if you think 
it’ll make things easier in the compiler…
> 
>> On Aug 8, 2018, at 11:03 PM, Alex Harui  wrote:
>> 
>> 
>> 
>> On 8/8/18, 12:59 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
>> 
>>   Does “this” in call/apply even work for a function which is not a 
prototype function? I thought in that case “this” is the global context.
>> 
>> From my testing, the 'this' can be re-assigned as we want it.
>> 
>>   I think 6a is kind of ambiguous. Why do you think there’s a difference 
between the following (other than avoiding ambiguous this references)?
>> 
>> Because there is already code that distinguishes when 'this' is supposed 
to be used.  So we should use it instead of crafting a whole other set of code 
that has a more difficult problem to solve, like whether an expression is 
relative to a parameter and if so, which parameter?
>> 
>> My 2 cents,
>> -Alex
>> 
>>   function() { return (over40(parseInt(this.age))) }
>>   and 
>>   function(node) { return (over40(parseInt(node.age))) }
>> 
>>   Although in fact, I think it would need to be:
>> 
>>   function(node) { return (over40(parseInt(node.child(“age” }
>> 
>>> On Aug 8, 2018, at 10:33 AM, Alex Harui  
wrote:
>>> 
>>> EmitterUtils.writeThis seems to be working ok.  I think it would be 
better/correct to use it here.  I'm not sure if node as a parameter creates the 
same scope chain as node being the this pointer.  I think no, I don't think 
parameters are involved in lexical scoping.   IMO, 6a in the spec is saying we 
should make node the 'this' pointer in JS.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 8/7/18, 10:54 AM, "Harbs"  wrote:
>>> 
>>>  I’m not following you. Wouldn’t we need the same logic to figure out 
where to insert “this”? I’m not sure what practical difference there would be 
between “node" and “this”, other than using apply or call. Passing in the XML 
node seems cleaner to me.
>>> 
 On Aug 7, 2018, at 6:50 PM, Alex Harui  
wrote:
 
 Yup.  After thinking about it some more, it occurs to me that we took 
the wrong starting point.  Right now code like:
 
 over40(parseInt(age))
 
 Results in:
 
 function(node) { return (over40(parseInt(age))) }
 
 And then the XML filter calls that function passing itself in as the 
node.
 
 And this discussion has been about trying to figure out where to add 
the "node" parameter.  But now I think that 6a in the spec is really saying 
that the 'this' pointer should be the node.  We should transpile that filter 
expression like any other function body but assume it is a function run in the 
context of the node, like a new method on XML/XMLList, or maybe more like an 
anonymous function.
 
 So if I'm right, then the output should be:
 
 function() { return (over40(parseInt(this.age))) }
 
 This is what the transpiler would have output if you had subclassed 
XML and added this method to it.  And then the code in XML.SWC that applies the 
filter has to use Function.apply/call passing the node as the 'this' pointer.
 
 If we do that, then the EmitterUtils.writeE4xFilterNode would go away, 
and JSRoyaleEmitter.emitE4xFilter would temporarily change the 
model.currentClass and maybe a few other things to reference an XML object.
 
 Thoughts?
 -Alex
 
 PS: Regarding adding tests, the filter tests have two variables.  "var 
a" sets up the XML, "var b" is the result of the filter.  getVariable returns 
the nodes for "a" then we go get child(1) which is "b" and then emit it to see 
what we get.
 
 On 8/7/18, 3:51 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
 
 I’m also pretty sure that the following from Mozilla’s page[1] will 
not work correctly:
 
 var people = 
   
 Bob
 32
   
   
 Joe
 46
   

Re: XML filters broke

2018-08-08 Thread Harbs
What’s the issue with IDataInput/IDataOutput? Cherrypicked from where?

> On Aug 8, 2018, at 11:48 PM, Alex Harui  wrote:
> 
> Won’t know until we try it.  I'll adjust XMLList as needed.  I have an actual 
> test case with Tour De Flex to work with.
> 
> If you have time to cherrypick IDataInput/IDataOutput for our users that 
> would be helpful.
> 
> Thanks,
> -Alex
> 
> On 8/8/18, 1:31 PM, "Harbs"  wrote:
> 
>Are you sure the logic to reassign this will work here?
> 
>I’m willing to rewrite the code in XMLList to use call if you think it’ll 
> make things easier in the compiler…
> 
>> On Aug 8, 2018, at 11:03 PM, Alex Harui  wrote:
>> 
>> 
>> 
>> On 8/8/18, 12:59 AM, "Harbs" > > wrote:
>> 
>>   Does “this” in call/apply even work for a function which is not a 
>> prototype function? I thought in that case “this” is the global context.
>> 
>> From my testing, the 'this' can be re-assigned as we want it.
>> 
>>   I think 6a is kind of ambiguous. Why do you think there’s a difference 
>> between the following (other than avoiding ambiguous this references)?
>> 
>> Because there is already code that distinguishes when 'this' is supposed to 
>> be used.  So we should use it instead of crafting a whole other set of code 
>> that has a more difficult problem to solve, like whether an expression is 
>> relative to a parameter and if so, which parameter?
>> 
>> My 2 cents,
>> -Alex
>> 
>>   function() { return (over40(parseInt(this.age))) }
>>   and 
>>   function(node) { return (over40(parseInt(node.age))) }
>> 
>>   Although in fact, I think it would need to be:
>> 
>>   function(node) { return (over40(parseInt(node.child(“age” }
>> 
>>> On Aug 8, 2018, at 10:33 AM, Alex Harui  wrote:
>>> 
>>> EmitterUtils.writeThis seems to be working ok.  I think it would be 
>>> better/correct to use it here.  I'm not sure if node as a parameter creates 
>>> the same scope chain as node being the this pointer.  I think no, I don't 
>>> think parameters are involved in lexical scoping.   IMO, 6a in the spec is 
>>> saying we should make node the 'this' pointer in JS.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 8/7/18, 10:54 AM, "Harbs"  wrote:
>>> 
>>>  I’m not following you. Wouldn’t we need the same logic to figure out where 
>>> to insert “this”? I’m not sure what practical difference there would be 
>>> between “node" and “this”, other than using apply or call. Passing in the 
>>> XML node seems cleaner to me.
>>> 
 On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
 
 Yup.  After thinking about it some more, it occurs to me that we took the 
 wrong starting point.  Right now code like:
 
 over40(parseInt(age))
 
 Results in:
 
 function(node) { return (over40(parseInt(age))) }
 
 And then the XML filter calls that function passing itself in as the node.
 
 And this discussion has been about trying to figure out where to add the 
 "node" parameter.  But now I think that 6a in the spec is really saying 
 that the 'this' pointer should be the node.  We should transpile that 
 filter expression like any other function body but assume it is a function 
 run in the context of the node, like a new method on XML/XMLList, or maybe 
 more like an anonymous function.
 
 So if I'm right, then the output should be:
 
 function() { return (over40(parseInt(this.age))) }
 
 This is what the transpiler would have output if you had subclassed XML 
 and added this method to it.  And then the code in XML.SWC that applies 
 the filter has to use Function.apply/call passing the node as the 'this' 
 pointer.
 
 If we do that, then the EmitterUtils.writeE4xFilterNode would go away, and 
 JSRoyaleEmitter.emitE4xFilter would temporarily change the 
 model.currentClass and maybe a few other things to reference an XML object.
 
 Thoughts?
 -Alex
 
 PS: Regarding adding tests, the filter tests have two variables.  "var a" 
 sets up the XML, "var b" is the result of the filter.  getVariable returns 
 the nodes for "a" then we go get child(1) which is "b" and then emit it to 
 see what we get.
 
 On 8/7/18, 3:51 AM, "Harbs" >>> > wrote:
 
 I’m also pretty sure that the following from Mozilla’s page[1] will not 
 work correctly:
 
 var people = 
   
 Bob
 32
   
   
 Joe
 46
   
 ;
 
 function over40(i) {
 return i > 40;
 }
 
 alert(people.person.(over40(parseInt(age))).name); // Alerts Joe
 
 

Re: XML filters broke

2018-08-08 Thread Alex Harui
Won’t know until we try it.  I'll adjust XMLList as needed.  I have an actual 
test case with Tour De Flex to work with.

If you have time to cherrypick IDataInput/IDataOutput for our users that would 
be helpful.

Thanks,
-Alex

On 8/8/18, 1:31 PM, "Harbs"  wrote:

Are you sure the logic to reassign this will work here?

I’m willing to rewrite the code in XMLList to use call if you think it’ll 
make things easier in the compiler…

> On Aug 8, 2018, at 11:03 PM, Alex Harui  wrote:
> 
> 
> 
> On 8/8/18, 12:59 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>Does “this” in call/apply even work for a function which is not a 
prototype function? I thought in that case “this” is the global context.
> 
> From my testing, the 'this' can be re-assigned as we want it.
> 
>I think 6a is kind of ambiguous. Why do you think there’s a difference 
between the following (other than avoiding ambiguous this references)?
> 
> Because there is already code that distinguishes when 'this' is supposed 
to be used.  So we should use it instead of crafting a whole other set of code 
that has a more difficult problem to solve, like whether an expression is 
relative to a parameter and if so, which parameter?
> 
> My 2 cents,
> -Alex
> 
>function() { return (over40(parseInt(this.age))) }
>and 
>function(node) { return (over40(parseInt(node.age))) }
> 
>Although in fact, I think it would need to be:
> 
>function(node) { return (over40(parseInt(node.child(“age” }
> 
>> On Aug 8, 2018, at 10:33 AM, Alex Harui  wrote:
>> 
>> EmitterUtils.writeThis seems to be working ok.  I think it would be 
better/correct to use it here.  I'm not sure if node as a parameter creates the 
same scope chain as node being the this pointer.  I think no, I don't think 
parameters are involved in lexical scoping.   IMO, 6a in the spec is saying we 
should make node the 'this' pointer in JS.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 8/7/18, 10:54 AM, "Harbs"  wrote:
>> 
>>   I’m not following you. Wouldn’t we need the same logic to figure out 
where to insert “this”? I’m not sure what practical difference there would be 
between “node" and “this”, other than using apply or call. Passing in the XML 
node seems cleaner to me.
>> 
>>> On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
>>> 
>>> Yup.  After thinking about it some more, it occurs to me that we took 
the wrong starting point.  Right now code like:
>>> 
>>> over40(parseInt(age))
>>> 
>>> Results in:
>>> 
>>> function(node) { return (over40(parseInt(age))) }
>>> 
>>> And then the XML filter calls that function passing itself in as the 
node.
>>> 
>>> And this discussion has been about trying to figure out where to add 
the "node" parameter.  But now I think that 6a in the spec is really saying 
that the 'this' pointer should be the node.  We should transpile that filter 
expression like any other function body but assume it is a function run in the 
context of the node, like a new method on XML/XMLList, or maybe more like an 
anonymous function.
>>> 
>>> So if I'm right, then the output should be:
>>> 
>>> function() { return (over40(parseInt(this.age))) }
>>> 
>>> This is what the transpiler would have output if you had subclassed XML 
and added this method to it.  And then the code in XML.SWC that applies the 
filter has to use Function.apply/call passing the node as the 'this' pointer.
>>> 
>>> If we do that, then the EmitterUtils.writeE4xFilterNode would go away, 
and JSRoyaleEmitter.emitE4xFilter would temporarily change the 
model.currentClass and maybe a few other things to reference an XML object.
>>> 
>>> Thoughts?
>>> -Alex
>>> 
>>> PS: Regarding adding tests, the filter tests have two variables.  "var 
a" sets up the XML, "var b" is the result of the filter.  getVariable returns 
the nodes for "a" then we go get child(1) which is "b" and then emit it to see 
what we get.
>>> 
>>> On 8/7/18, 3:51 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
>>> 
>>>  I’m also pretty sure that the following from Mozilla’s page[1] will 
not work correctly:
>>> 
>>>  var people = 
>>>
>>>  Bob
>>>  32
>>>
>>>
>>>  Joe
>>>  46
>>>
>>>  ;
>>> 
>>>  function over40(i) {
>>>  return i > 40;
>>>  }
>>> 
>>>  alert(people.person.(over40(parseInt(age))).name); // Alerts Joe
>>> 
>>>  

Re: XML filters broke

2018-08-08 Thread Harbs
Are you sure the logic to reassign this will work here?

I’m willing to rewrite the code in XMLList to use call if you think it’ll make 
things easier in the compiler…

> On Aug 8, 2018, at 11:03 PM, Alex Harui  wrote:
> 
> 
> 
> On 8/8/18, 12:59 AM, "Harbs"  > wrote:
> 
>Does “this” in call/apply even work for a function which is not a 
> prototype function? I thought in that case “this” is the global context.
> 
> From my testing, the 'this' can be re-assigned as we want it.
> 
>I think 6a is kind of ambiguous. Why do you think there’s a difference 
> between the following (other than avoiding ambiguous this references)?
> 
> Because there is already code that distinguishes when 'this' is supposed to 
> be used.  So we should use it instead of crafting a whole other set of code 
> that has a more difficult problem to solve, like whether an expression is 
> relative to a parameter and if so, which parameter?
> 
> My 2 cents,
> -Alex
> 
>function() { return (over40(parseInt(this.age))) }
>and 
>function(node) { return (over40(parseInt(node.age))) }
> 
>Although in fact, I think it would need to be:
> 
>function(node) { return (over40(parseInt(node.child(“age” }
> 
>> On Aug 8, 2018, at 10:33 AM, Alex Harui  wrote:
>> 
>> EmitterUtils.writeThis seems to be working ok.  I think it would be 
>> better/correct to use it here.  I'm not sure if node as a parameter creates 
>> the same scope chain as node being the this pointer.  I think no, I don't 
>> think parameters are involved in lexical scoping.   IMO, 6a in the spec is 
>> saying we should make node the 'this' pointer in JS.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 8/7/18, 10:54 AM, "Harbs"  wrote:
>> 
>>   I’m not following you. Wouldn’t we need the same logic to figure out where 
>> to insert “this”? I’m not sure what practical difference there would be 
>> between “node" and “this”, other than using apply or call. Passing in the 
>> XML node seems cleaner to me.
>> 
>>> On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
>>> 
>>> Yup.  After thinking about it some more, it occurs to me that we took the 
>>> wrong starting point.  Right now code like:
>>> 
>>> over40(parseInt(age))
>>> 
>>> Results in:
>>> 
>>> function(node) { return (over40(parseInt(age))) }
>>> 
>>> And then the XML filter calls that function passing itself in as the node.
>>> 
>>> And this discussion has been about trying to figure out where to add the 
>>> "node" parameter.  But now I think that 6a in the spec is really saying 
>>> that the 'this' pointer should be the node.  We should transpile that 
>>> filter expression like any other function body but assume it is a function 
>>> run in the context of the node, like a new method on XML/XMLList, or maybe 
>>> more like an anonymous function.
>>> 
>>> So if I'm right, then the output should be:
>>> 
>>> function() { return (over40(parseInt(this.age))) }
>>> 
>>> This is what the transpiler would have output if you had subclassed XML and 
>>> added this method to it.  And then the code in XML.SWC that applies the 
>>> filter has to use Function.apply/call passing the node as the 'this' 
>>> pointer.
>>> 
>>> If we do that, then the EmitterUtils.writeE4xFilterNode would go away, and 
>>> JSRoyaleEmitter.emitE4xFilter would temporarily change the 
>>> model.currentClass and maybe a few other things to reference an XML object.
>>> 
>>> Thoughts?
>>> -Alex
>>> 
>>> PS: Regarding adding tests, the filter tests have two variables.  "var a" 
>>> sets up the XML, "var b" is the result of the filter.  getVariable returns 
>>> the nodes for "a" then we go get child(1) which is "b" and then emit it to 
>>> see what we get.
>>> 
>>> On 8/7/18, 3:51 AM, "Harbs" >> > wrote:
>>> 
>>>  I’m also pretty sure that the following from Mozilla’s page[1] will not 
>>> work correctly:
>>> 
>>>  var people = 
>>>
>>>  Bob
>>>  32
>>>
>>>
>>>  Joe
>>>  46
>>>
>>>  ;
>>> 
>>>  function over40(i) {
>>>  return i > 40;
>>>  }
>>> 
>>>  alert(people.person.(over40(parseInt(age))).name); // Alerts Joe
>>> 
>>>  
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X%2FProcessing_XML_with_E4Xdata=02%7C01%7Caharui%40adobe.com%7C441a59794e0f493d1c7b08d5fd04d3f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636693119531996112sdata=i5AMXcWmppuFIqNky5A5a3A3m9NG2x30NrzCxDw37Ss%3Dreserved=0
>>>  
>>> 
>>>  
>>> 

Re: XML filters broke

2018-08-08 Thread Alex Harui


On 8/8/18, 12:59 AM, "Harbs"  wrote:

Does “this” in call/apply even work for a function which is not a prototype 
function? I thought in that case “this” is the global context.

From my testing, the 'this' can be re-assigned as we want it.

I think 6a is kind of ambiguous. Why do you think there’s a difference 
between the following (other than avoiding ambiguous this references)?

Because there is already code that distinguishes when 'this' is supposed to be 
used.  So we should use it instead of crafting a whole other set of code that 
has a more difficult problem to solve, like whether an expression is relative 
to a parameter and if so, which parameter?

My 2 cents,
-Alex

function() { return (over40(parseInt(this.age))) }
and 
function(node) { return (over40(parseInt(node.age))) }

Although in fact, I think it would need to be:

function(node) { return (over40(parseInt(node.child(“age” }

> On Aug 8, 2018, at 10:33 AM, Alex Harui  wrote:
> 
> EmitterUtils.writeThis seems to be working ok.  I think it would be 
better/correct to use it here.  I'm not sure if node as a parameter creates the 
same scope chain as node being the this pointer.  I think no, I don't think 
parameters are involved in lexical scoping.   IMO, 6a in the spec is saying we 
should make node the 'this' pointer in JS.
> 
> My 2 cents,
> -Alex
> 
> On 8/7/18, 10:54 AM, "Harbs"  wrote:
> 
>I’m not following you. Wouldn’t we need the same logic to figure out 
where to insert “this”? I’m not sure what practical difference there would be 
between “node" and “this”, other than using apply or call. Passing in the XML 
node seems cleaner to me.
> 
>> On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
>> 
>> Yup.  After thinking about it some more, it occurs to me that we took 
the wrong starting point.  Right now code like:
>> 
>> over40(parseInt(age))
>> 
>> Results in:
>> 
>> function(node) { return (over40(parseInt(age))) }
>> 
>> And then the XML filter calls that function passing itself in as the 
node.
>> 
>> And this discussion has been about trying to figure out where to add the 
"node" parameter.  But now I think that 6a in the spec is really saying that 
the 'this' pointer should be the node.  We should transpile that filter 
expression like any other function body but assume it is a function run in the 
context of the node, like a new method on XML/XMLList, or maybe more like an 
anonymous function.
>> 
>> So if I'm right, then the output should be:
>> 
>> function() { return (over40(parseInt(this.age))) }
>> 
>> This is what the transpiler would have output if you had subclassed XML 
and added this method to it.  And then the code in XML.SWC that applies the 
filter has to use Function.apply/call passing the node as the 'this' pointer.
>> 
>> If we do that, then the EmitterUtils.writeE4xFilterNode would go away, 
and JSRoyaleEmitter.emitE4xFilter would temporarily change the 
model.currentClass and maybe a few other things to reference an XML object.
>> 
>> Thoughts?
>> -Alex
>> 
>> PS: Regarding adding tests, the filter tests have two variables.  "var 
a" sets up the XML, "var b" is the result of the filter.  getVariable returns 
the nodes for "a" then we go get child(1) which is "b" and then emit it to see 
what we get.
>> 
>> On 8/7/18, 3:51 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
>> 
>>   I’m also pretty sure that the following from Mozilla’s page[1] will 
not work correctly:
>> 
>>   var people = 
>> 
>>   Bob
>>   32
>> 
>> 
>>   Joe
>>   46
>> 
>>   ;
>> 
>>   function over40(i) {
>>   return i > 40;
>>   }
>> 
>>   alert(people.person.(over40(parseInt(age))).name); // Alerts Joe
>> 
>>   
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X%2FProcessing_XML_with_E4Xdata=02%7C01%7Caharui%40adobe.com%7C441a59794e0f493d1c7b08d5fd04d3f9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636693119531996112sdata=i5AMXcWmppuFIqNky5A5a3A3m9NG2x30NrzCxDw37Ss%3Dreserved=0
 

 

Re: Migrating Enterprise Flex Application

2018-08-08 Thread Harbs
What is missing?

> On Aug 8, 2018, at 8:28 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> just notice that current versions of IDataInput and IDataOutput are
> incomplete. The rest of missed methods should be added and as well added to
> implementor classes
> 
> just my 2ctns
> 
> 2018-08-08 9:29 GMT+02:00 Alex Harui :
> 
>> In the develop branch, there is an IDataInput/IDataOutput in the Network
>> SWC.  I will try to cherry pick that into feature/MXRoyale after I finish
>> up another thing I'm currently working on.  You could probably get the
>> nightly from the develop branch and use that Network.swc.
>> 
>> HTH,
>> -Alex
>> 
>> On 8/7/18, 11:44 PM, "chembali"  wrote:
>> 
>>My current code uses IDataInput/iDataOutput classes in Flash util. What
>>classes can I use to replace them? I saw IBinaryDataOutput in Royale,
>> but it
>>does not have the writeObject() and readObject() apis.
>> 
>> 
>> 
>>--
>>Sent from: https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fapache-royale-development.20373.n8.nabble.
>> com%2Fdata=02%7C01%7Caharui%40adobe.com%
>> 7C0673e721af074e9eb88508d5fcfa5b3f%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C1%7C636693074577954430sdata=UVE28CmyyV975aj%
>> 2FaFaSQaxXaY30Ifd3fUx1of8ZLpM%3Dreserved=0
>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira



Build failed in Jenkins: royale-compiler #374

2018-08-08 Thread apacheroyaleci
See 


Changes:

[aharui] allow/ignore some errors because the transpiler will generate some 
other

[aharui] allow substitutions in method visibility

[aharui] handle simple XML expressions.  Sometimes we don't get an

--
[...truncated 83.66 KB...]

set.css.tree.uptodate:

css.tree:
 [echo] Generating CSSTree
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

antlr:

set.unknown.tree.handler.patterns.uptodate:

unknown.tree.handler.patterns:
[mkdir] Created dir: 

 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

set.cmc.emitter.uptodate:

cmc.emitter:
 [echo] Generating CmcEmitter
[mkdir] Created dir: 

 [java] Using Language Adaptor : jburg.burg.emitlangs.EmitJava
 [java] Using i-node adapter 
org.apache.royale.compiler.internal.as.codegen.IASNodeAdapter
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [java] Adding @SuppressWarnings({"rawtypes", "unchecked", "unused"}) to 
class: 


set.css.emitter.uptodate:

css.emitter:
 [echo] Generating CSSEmitter
[mkdir] Created dir: 

 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [java] Using Language Adaptor : jburg.burg.emitlangs.EmitJava
 [java] Using i-node adapter jburg.burg.inode.DefaultAdapter
 [java] Adding @SuppressWarnings({"rawtypes", "unchecked", "unused"}) to 
class: 


jburg:

eclipse:

src.depend:

compile:
[javac] Compiling 1545 source files to 

[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] 
:29:
 warning: [overrides] Class DefinitionPriority overrides equals, but neither it 
nor any superclass overrides hashCode method
[javac] public final class DefinitionPriority implements IDefinitionPriority
[javac]  ^
[javac] 
:1486:
 warning: [overrides] Class UserDefinedNamespaceReference overrides equals, but 
neither it nor any superclass overrides hashCode method
[javac] private static class UserDefinedNamespaceReference implements 
INamespaceResolvedReference
[javac]^
[javac] 
:46:
 warning: [overrides] Class MetaTagsNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class MetaTagsNode extends ContainerNode implements 
IMetaTagsNode
[javac]^
[javac] 
:29:
 warning: [overrides] Class TypedTagNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class TypedTagNode extends MetaTagNode implements 
ITypedTagNode
[javac]^
[javac] 
:32:
 warning: [overrides] Class DefaultPropertyTagNode overrides equals, but 
neither it nor any superclass overrides hashCode method
[javac] public class DefaultPropertyTagNode extends MetaTagNode implements 
IDefaultPropertyTagNode
[javac]^
[javac] 

Re: Migrating Enterprise Flex Application

2018-08-08 Thread Carlos Rovira
Hi,

just notice that current versions of IDataInput and IDataOutput are
incomplete. The rest of missed methods should be added and as well added to
implementor classes

just my 2ctns

2018-08-08 9:29 GMT+02:00 Alex Harui :

> In the develop branch, there is an IDataInput/IDataOutput in the Network
> SWC.  I will try to cherry pick that into feature/MXRoyale after I finish
> up another thing I'm currently working on.  You could probably get the
> nightly from the develop branch and use that Network.swc.
>
> HTH,
> -Alex
>
> On 8/7/18, 11:44 PM, "chembali"  wrote:
>
> My current code uses IDataInput/iDataOutput classes in Flash util. What
> classes can I use to replace them? I saw IBinaryDataOutput in Royale,
> but it
> does not have the writeObject() and readObject() apis.
>
>
>
> --
> Sent from: https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache-royale-development.20373.n8.nabble.
> com%2Fdata=02%7C01%7Caharui%40adobe.com%
> 7C0673e721af074e9eb88508d5fcfa5b3f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C1%7C636693074577954430sdata=UVE28CmyyV975aj%
> 2FaFaSQaxXaY30Ifd3fUx1of8ZLpM%3Dreserved=0
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira


Build failed in Jenkins: royale-compiler #373

2018-08-08 Thread apacheroyaleci
See 


--
[...truncated 57.81 KB...]
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestPackageNamespace
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.01 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestReferenceModel
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
0.002 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestTypeTypedefs
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.03 sec
[junit] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

main:

jar-test:
 [echo] using externc.jar from C:/Program Files 
(x86)/Jenkins/workspace/royale-compiler/compiler-jx/lib
 [java] Math parameters not found!  0
 [java] Reflect parameters not found!  0
 [java] chrome parameters not found!  0
 [java] app parameters not found!  0
 [java] webstore parameters not found!  0
 [java] runtime parameters not found!  0
 [java] Intl parameters not found!  0
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [java] 6.267976 seconds

download:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is ${ROYALE_COMPILER_HOME}
 [echo] ROYALE_COMPILER_HOME is 


prepare:
 [echo] Making lib directory 


all:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:
 [echo] checking for 


download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:
 [echo] checking for 


download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:
 [echo] checking for 


download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:
 [echo] checking for 


download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:
 [echo] checking for 


download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

RE: [royale-asjs] branch feature/MXRoyale updated: RichTextEditor.mxml Added

2018-08-08 Thread Alina Kazi
Sure I will be more careful next time.

Thanks,
Alina

-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: Monday, August 06, 2018 10:03 PM
To: dev@royale.apache.org; comm...@royale.apache.org
Subject: Re: [royale-asjs] branch feature/MXRoyale updated: RichTextEditor.mxml 
Added

Hi Alina,

This did not compile for me.  Please make sure your changes build before 
committing.

Thanks,
-Alex

On 8/6/18, 2:56 AM, "alinak...@apache.org"  wrote:

This is an automated email from the ASF dual-hosted git repository.

alinakazi pushed a commit to branch feature/MXRoyale
in repository 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.gitdata=02%7C01%7Caharui%40adobe.com%7Ccdac898b4cbb4d71b05a08d5fb82eff4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636691462175795993sdata=jLzQztKIVyrbO4XOHfIBUYaxvcfo4SQh0qTshi9hFpQ%3Dreserved=0


The following commit(s) were added to refs/heads/feature/MXRoyale by this 
push:
 new ebaf942  RichTextEditor.mxml Added
ebaf942 is described below

commit ebaf94268e59ee796fd39bf1d5dbc240788737c8
Author: alinakazi 
AuthorDate: Mon Aug 6 14:56:50 2018 +0500

RichTextEditor.mxml Added
---
 .../main/royale/mx/controls/RichTextEditor.mxml| 1078 

 1 file changed, 1078 insertions(+)

diff --git 
a/frameworks/projects/MXRoyale/src/main/royale/mx/controls/RichTextEditor.mxml 
b/frameworks/projects/MXRoyale/src/main/royale/mx/controls/RichTextEditor.mxml
new file mode 100644
index 000..15b9a2c
--- /dev/null
+++ 
b/frameworks/projects/MXRoyale/src/main/royale/mx/controls/RichTextEditor.mxml
@@ -0,0 +1,1078 @@
+
+
+
+
+
+ http://www.adobe.com/2006/mxml; xmlns="*" 
minWidth="220" minHeight="200" width="325" height="300">
+
+
+
+
+
+ 
+_sans
+_serif
+_typewriter
+Arial
+Courier
+Courier New
+Geneva
+Georgia
+Helvetica
+Times New Roman
+Times
+Verdana
+
+
+ 
+8
+9
+10
+11
+12
+14
+16
+18
+20
+22
+24
+26
+28
+36
+48
+72
+
+
+
+
+
+
+
+
+
+ 
+
+
+
+
+
+
+
+ 
+
+
+ 
+
+ 
+
+ 
+
+
+
+
+
+
+
+
+
+ 
+
+
+
+
+
+
+
+
+ 
+
+
+
+
+
+
+
+ 
+
+







Build failed in Jenkins: Royale-asjs_MXRoyale #60

2018-08-08 Thread apacheroyaleci
See 


Changes:

[harbs] XML reference added to SparkRoyale (#267)

--
[...truncated 390.84 KB...]
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//antlr.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//commons-cli.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//commons-io.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//commons-lang-2.6.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//guava.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//jburg.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//jflex.jar

download-dependency:
 [copy] Warning: C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\in\temp\jflex-1.6.0 does not 
exist.
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//lzma-sdk.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//flex-tool-api.jar

download-dependency:

main:

setup:

set.raw.as.tokenizer.uptodate:

raw.as.tokenizer:

set.raw.asdoc.tokenizer.uptodate:

raw.asdoc.tokenizer:

set.raw.mxml.tokenizer.uptodate:

raw.mxml.tokenizer:

jflex:

set.as.parser.uptodate:

as.parser:

set.metadata.parser.uptodate:

metadata.parser:

set.css.lexer.and.parser.uptodate:

css.lexer.and.parser:
 [echo] Generating CSSLexer and CSSParser
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8


Build failed in Jenkins: royale-asjs_jsonly #1290

2018-08-08 Thread apacheroyaleci
See 


Changes:

[harbs] Fixed Spelling. (#265)

--
[...truncated 356.85 KB...]
 [echo] Generating CmcEmitter
[mkdir] Created dir: 
c:\jenkins\workspace\royale-compiler\compiler\target\generated-sources\jburg\org\apache\royale\compiler\internal\as\codegen
 [java] Using Language Adaptor : jburg.burg.emitlangs.EmitJava
 [java] Using i-node adapter 
org.apache.royale.compiler.internal.as.codegen.IASNodeAdapter
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [java] Adding @SuppressWarnings({"rawtypes", "unchecked", "unused"}) to 
class: 
c:\jenkins\workspace\royale-compiler\compiler\target\generated-sources\jburg\org\apache\royale\compiler\internal\as\codegen\CmcEmitter.java

set.css.emitter.uptodate:

css.emitter:
 [echo] Generating CSSEmitter
[mkdir] Created dir: 
c:\jenkins\workspace\royale-compiler\compiler\target\generated-sources\jburg\org\apache\royale\compiler\internal\css\codegen
 [java] Using Language Adaptor : jburg.burg.emitlangs.EmitJava
 [java] Using i-node adapter jburg.burg.inode.DefaultAdapter
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
 [java] Adding @SuppressWarnings({"rawtypes", "unchecked", "unused"}) to 
class: 
c:\jenkins\workspace\royale-compiler\compiler\target\generated-sources\jburg\org\apache\royale\compiler\internal\css\codegen\CSSEmitter.java

jburg:

eclipse:

src.depend:

compile:
[javac] Compiling 1545 source files to 
c:\jenkins\workspace\royale-compiler\compiler\target\classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.5
[javac] warning: [options] source value 1.5 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.5 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\projects\DefinitionPriority.java:29:
 warning: [overrides] Class DefinitionPriority overrides equals, but neither it 
nor any superclass overrides hashCode method
[javac] public final class DefinitionPriority implements IDefinitionPriority
[javac]  ^
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\definitions\NamespaceDefinition.java:1486:
 warning: [overrides] Class UserDefinedNamespaceReference overrides equals, but 
neither it nor any superclass overrides hashCode method
[javac] private static class UserDefinedNamespaceReference implements 
INamespaceResolvedReference
[javac]^
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\tree\as\metadata\MetaTagsNode.java:46:
 warning: [overrides] Class MetaTagsNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class MetaTagsNode extends ContainerNode implements 
IMetaTagsNode
[javac]^
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\tree\as\metadata\TypedTagNode.java:29:
 warning: [overrides] Class TypedTagNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class TypedTagNode extends MetaTagNode implements 
ITypedTagNode
[javac]^
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\tree\as\metadata\DefaultPropertyTagNode.java:32:
 warning: [overrides] Class DefaultPropertyTagNode overrides equals, but 
neither it nor any superclass overrides hashCode method
[javac] public class DefaultPropertyTagNode extends MetaTagNode implements 
IDefaultPropertyTagNode
[javac]^
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\tree\as\metadata\EffectTagNode.java:30:
 warning: [overrides] Class EffectTagNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public final class EffectTagNode extends BaseDefinitionMetaTagNode 
implements IEffectTagNode
[javac]  ^
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\tree\as\metadata\EventTagNode.java:33:
 warning: [overrides] Class EventTagNode overrides equals, but neither it nor 
any superclass overrides hashCode method
[javac] public class EventTagNode extends BaseDefinitionMetaTagNode 
implements IEventTagNode
[javac]^
[javac] 
c:\jenkins\workspace\royale-compiler\compiler\src\main\java\org\apache\royale\compiler\internal\tree\as\metadata\EventTriggerTagNode.java:32:
 warning: [overrides] Class 

Re: XML filters broke

2018-08-08 Thread Harbs
Does “this” in call/apply even work for a function which is not a prototype 
function? I thought in that case “this” is the global context.

I think 6a is kind of ambiguous. Why do you think there’s a difference between 
the following (other than avoiding ambiguous this references)?

function() { return (over40(parseInt(this.age))) }
and 
function(node) { return (over40(parseInt(node.age))) }

Although in fact, I think it would need to be:

function(node) { return (over40(parseInt(node.child(“age” }

> On Aug 8, 2018, at 10:33 AM, Alex Harui  wrote:
> 
> EmitterUtils.writeThis seems to be working ok.  I think it would be 
> better/correct to use it here.  I'm not sure if node as a parameter creates 
> the same scope chain as node being the this pointer.  I think no, I don't 
> think parameters are involved in lexical scoping.   IMO, 6a in the spec is 
> saying we should make node the 'this' pointer in JS.
> 
> My 2 cents,
> -Alex
> 
> On 8/7/18, 10:54 AM, "Harbs"  wrote:
> 
>I’m not following you. Wouldn’t we need the same logic to figure out where 
> to insert “this”? I’m not sure what practical difference there would be 
> between “node" and “this”, other than using apply or call. Passing in the XML 
> node seems cleaner to me.
> 
>> On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
>> 
>> Yup.  After thinking about it some more, it occurs to me that we took the 
>> wrong starting point.  Right now code like:
>> 
>> over40(parseInt(age))
>> 
>> Results in:
>> 
>> function(node) { return (over40(parseInt(age))) }
>> 
>> And then the XML filter calls that function passing itself in as the node.
>> 
>> And this discussion has been about trying to figure out where to add the 
>> "node" parameter.  But now I think that 6a in the spec is really saying that 
>> the 'this' pointer should be the node.  We should transpile that filter 
>> expression like any other function body but assume it is a function run in 
>> the context of the node, like a new method on XML/XMLList, or maybe more 
>> like an anonymous function.
>> 
>> So if I'm right, then the output should be:
>> 
>> function() { return (over40(parseInt(this.age))) }
>> 
>> This is what the transpiler would have output if you had subclassed XML and 
>> added this method to it.  And then the code in XML.SWC that applies the 
>> filter has to use Function.apply/call passing the node as the 'this' pointer.
>> 
>> If we do that, then the EmitterUtils.writeE4xFilterNode would go away, and 
>> JSRoyaleEmitter.emitE4xFilter would temporarily change the 
>> model.currentClass and maybe a few other things to reference an XML object.
>> 
>> Thoughts?
>> -Alex
>> 
>> PS: Regarding adding tests, the filter tests have two variables.  "var a" 
>> sets up the XML, "var b" is the result of the filter.  getVariable returns 
>> the nodes for "a" then we go get child(1) which is "b" and then emit it to 
>> see what we get.
>> 
>> On 8/7/18, 3:51 AM, "Harbs" > > wrote:
>> 
>>   I’m also pretty sure that the following from Mozilla’s page[1] will not 
>> work correctly:
>> 
>>   var people = 
>> 
>>   Bob
>>   32
>> 
>> 
>>   Joe
>>   46
>> 
>>   ;
>> 
>>   function over40(i) {
>>   return i > 40;
>>   }
>> 
>>   alert(people.person.(over40(parseInt(age))).name); // Alerts Joe
>> 
>>   
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X%2FProcessing_XML_with_E4Xdata=02%7C01%7Caharui%40adobe.com%7C47aa707c6e664beeafe308d5fc53afbd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636692358717325505sdata=I1dJz1%2BApUMPtSZNoFFWF68u1IeygB6fiIF%2FKM9zq4Y%3Dreserved=0
>>  
>> 
>>  
>> >  
>> >
>> 
>>> On Aug 7, 2018, at 1:41 PM, Harbs  wrote:
>>> 
>>> OK. I fixed the issue, but there’s a couple of loose ends:
>>> 
>>> 1. I don’t know how to add unit tests for these cases. In the current unit 
>>> tests, I see 

Re: XML filters broke

2018-08-08 Thread Alex Harui
EmitterUtils.writeThis seems to be working ok.  I think it would be 
better/correct to use it here.  I'm not sure if node as a parameter creates the 
same scope chain as node being the this pointer.  I think no, I don't think 
parameters are involved in lexical scoping.   IMO, 6a in the spec is saying we 
should make node the 'this' pointer in JS.

My 2 cents,
-Alex

On 8/7/18, 10:54 AM, "Harbs"  wrote:

I’m not following you. Wouldn’t we need the same logic to figure out where 
to insert “this”? I’m not sure what practical difference there would be between 
“node" and “this”, other than using apply or call. Passing in the XML node 
seems cleaner to me.

> On Aug 7, 2018, at 6:50 PM, Alex Harui  wrote:
> 
> Yup.  After thinking about it some more, it occurs to me that we took the 
wrong starting point.  Right now code like:
> 
> over40(parseInt(age))
> 
> Results in:
> 
> function(node) { return (over40(parseInt(age))) }
> 
> And then the XML filter calls that function passing itself in as the node.
> 
> And this discussion has been about trying to figure out where to add the 
"node" parameter.  But now I think that 6a in the spec is really saying that 
the 'this' pointer should be the node.  We should transpile that filter 
expression like any other function body but assume it is a function run in the 
context of the node, like a new method on XML/XMLList, or maybe more like an 
anonymous function.
> 
> So if I'm right, then the output should be:
> 
> function() { return (over40(parseInt(this.age))) }
> 
> This is what the transpiler would have output if you had subclassed XML 
and added this method to it.  And then the code in XML.SWC that applies the 
filter has to use Function.apply/call passing the node as the 'this' pointer.
> 
> If we do that, then the EmitterUtils.writeE4xFilterNode would go away, 
and JSRoyaleEmitter.emitE4xFilter would temporarily change the 
model.currentClass and maybe a few other things to reference an XML object.
> 
> Thoughts?
> -Alex
> 
> PS: Regarding adding tests, the filter tests have two variables.  "var a" 
sets up the XML, "var b" is the result of the filter.  getVariable returns the 
nodes for "a" then we go get child(1) which is "b" and then emit it to see what 
we get.
> 
> On 8/7/18, 3:51 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>I’m also pretty sure that the following from Mozilla’s page[1] will 
not work correctly:
> 
>var people = 
>  
>Bob
>32
>  
>  
>Joe
>46
>  
>;
> 
>function over40(i) {
>return i > 40;
>}
> 
>alert(people.person.(over40(parseInt(age))).name); // Alerts Joe
> 
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X%2FProcessing_XML_with_E4Xdata=02%7C01%7Caharui%40adobe.com%7C47aa707c6e664beeafe308d5fc53afbd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636692358717325505sdata=I1dJz1%2BApUMPtSZNoFFWF68u1IeygB6fiIF%2FKM9zq4Y%3Dreserved=0
 

 
>
> 
>> On Aug 7, 2018, at 1:41 PM, Harbs  wrote:
>> 
>> OK. I fixed the issue, but there’s a couple of loose ends:
>> 
>> 1. I don’t know how to add unit tests for these cases. In the current 
unit tests, I see “getNode” and “getVariable” being used. I don’t know the 
logic in setting up tests.
>> 2. I’m not quite sure what "parentNode.getChild(0)” does. What is the 
parent node and will this cause my second case of e.employee.(1 == @id) to 
fail? Removing the check against firstChild caused the 
testXMLFilterWithAttribute test to fail because it prepended “node.” to 
“length()”.
>> 
>> P.S. I finally got debugging from Eclipse working on the compiler, so 
hopefully I’ll 

Re: Migrating Enterprise Flex Application

2018-08-08 Thread Alex Harui
In the develop branch, there is an IDataInput/IDataOutput in the Network SWC.  
I will try to cherry pick that into feature/MXRoyale after I finish up another 
thing I'm currently working on.  You could probably get the nightly from the 
develop branch and use that Network.swc.

HTH,
-Alex

On 8/7/18, 11:44 PM, "chembali"  wrote:

My current code uses IDataInput/iDataOutput classes in Flash util. What
classes can I use to replace them? I saw IBinaryDataOutput in Royale, but it
does not have the writeObject() and readObject() apis.



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2Fdata=02%7C01%7Caharui%40adobe.com%7C0673e721af074e9eb88508d5fcfa5b3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636693074577954430sdata=UVE28CmyyV975aj%2FaFaSQaxXaY30Ifd3fUx1of8ZLpM%3Dreserved=0




Build failed in Jenkins: Royale-asjs_MXRoyale #59

2018-08-08 Thread apacheroyaleci
See 


Changes:

[noreply] Update LinearGradient.as

--
[...truncated 392.25 KB...]
 [echo] Making lib directory C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external

all:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//antlr.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//commons-cli.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//commons-io.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//commons-lang-2.6.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//guava.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//jburg.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//jflex.jar

download-dependency:
 [copy] Warning: C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\in\temp\jflex-1.6.0 does not 
exist.
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//lzma-sdk.jar

download-dependency:
 [echo] basedir is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for C:\Program Files 
(x86)\Jenkins\workspace\royale-compiler\compiler/lib/external//flex-tool-api.jar

download-dependency:

main:

setup:

set.raw.as.tokenizer.uptodate:

raw.as.tokenizer:

set.raw.asdoc.tokenizer.uptodate:

raw.asdoc.tokenizer:

set.raw.mxml.tokenizer.uptodate:

raw.mxml.tokenizer:

jflex:

set.as.parser.uptodate:

as.parser:


Re: Migrating Enterprise Flex Application

2018-08-08 Thread chembali
My current code uses IDataInput/iDataOutput classes in Flash util. What
classes can I use to replace them? I saw IBinaryDataOutput in Royale, but it
does not have the writeObject() and readObject() apis.



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/