Release Step 002 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_002 and run the following commands:
git push

You will need your Apache/Github username and 2FA token.

Release Step 001 Succeeded

[Apache Royale CI Server]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_001 and run the following commands:
git push
git checkout release/0.9.6
git push -u origin release/0.9.6

You will need your Apache/Github username and 2FA token.

Royale_Release_Step_001 - Build # 49 - Failure!

[Apache Royale CI Server]

Royale_Release_Step_001 - Build # 49 - Failure:

Check console output at 
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/Royale_Release_Step_001/49/
 to view the results.

Re: Problems dealing with bead substitution in Royale

[Alex Harui]

It looks like a reasonable subsystem design, but given that we have a lot of 
code running just fine without this, and that bead substitution should be a 
very rare situation, I'm having trouble understanding why we would want to add 
an entire just-in-case subsystem.

Asking beads for their interests breaks encapsulation.  Why should the outside 
world know or care?  Just so you can remove a bead?  Some really sophisticated 
beads may not register all interests/event listeners at once, or dynamically 
figure out interests/events.  Then this whole subsystem would get bigger.

Regarding the benefits you listed:
1) Having "parent" object know about their children has led to lots of problems 
in Flex and Royale.  Think of creationPolicy="all" and modules sticking in 
memory or modules not loading because the parent already contained the classes 
in the module because it referenced the module.  It is much better to abstract 
the "children" away from the "parent".  That principle of encapsulation allows 
deferred instantiation and loading.
2) I don't understand what indirection you are referring to.
3) I didn't understand this point either.
4) We could try again to make all strands IEventDispatcher, or see if we can 
teach the compiler to allow IStrand and IStrandEventDispatcher.  That would be 
independent of this proposal.
5) A central function with a giant switch statement, IMO, also breaks 
encapsulation and adds handler overhead.  Think of how subclasses would 
override behavior in the base class.  Each subclass would have its own switch 
statement.
6) Shared beads should be relative rare as well, but I'm not clear how this 
proposal helps.

If the main concern is trying to get a bead to clean up when removed, let's 
stop and try to find a PAYG way for that, not a just-in-case way for that.  
Let's see if we can agree on:
1) Should every bead be removable?  I would say no.
2) If only certain beads need to be removable, then a separate interface with a 
cleanup methods should suffice.
3) Beads that want to have removable versions should have protected, not 
private event handlers.  Then a subclass could add removability.

IMO, the solution to removing beads is really this simple and doesn't require a 
whole new subsystem.

There might be some good things to keep from the proposal.  Maybe there should 
be a base class for all beads.  If you want to create a branch and see if it 
makes HelloWorld smaller, then that would be a win.  Maybe that base class can 
have a "host" or "eventStrand" property that implements IEventDispatcher to 
reduce the number of times we write "as EventDispatcher" and maybe that will 
also make HelloWorld smaller.  Maybe there can then be a subclass of that 
baseclass that adds removeability, but I would rather it be added at the end of 
the inheritance chain otherwise folks will opt-in on it "just-in-case".

I would need to understand more about why we need an entirely different 
callback/notification/event subsystem.  There are definitely some lighterweight 
models out there, but we've already paid for DOM Events, and then how do folks 
decide which one to use.

But my main objection is patterns that break encapsulation and require the 
parent to know about the child.   Hopefully other parts of the proposal can be 
tweaked.

My 2 cents,
-Alex

On 2/19/19, 9:31 AM, "Harbs"  wrote:


> On Feb 19, 2019, at 5:14 PM, Carlos Rovira  
wrote:
> 
> Hi Harbs,
> 
> I finally could take a look at you notification system, I can  intuit a
> good idea but still need more info or explanation from you to get the
> benefits. My questions is more about the global thinking of the
> notification idea more than an implementation question:
> 
> 1.- why we have tow methods "notify" and "sendNotification"? naming seems
> refer to the same purpose right?

“notify” is a convenience method which uses  sendNotification. Since the 
vast majority of notifications do not need a payload, “notify” allows for 
easier sending of the notifications.

> 2.- this system should be better to handle things like bead removal so the
> bead knows how to do it, right? how this is performed? have we got a
> cleaning method in the bead that should know how to clean itself to do 
this?

Yes. Basically, you can ask any bead for a list of its interests, and that 
list is used to both add and remove bead references in the strand. The bead 
does not need to clean itself. A ututiliy method can completely strip a bead 
off a strand including all references necessary for notification. Take a look 
how that’s done here:

Re: [royale-compiler] 05/05: ParametersEmitter: fixed automatic type coercion and added some tests (closes #74)

[Alex Harui]

SWF output might do more error checking and coercion than JS output, so if you 
were having trouble figuring out what to change for Vector, I was suggesting 
that you look in some of that code.  Sounds like you got it working?  Then my 
email doesn’t matter.

-Alex

On 2/19/19, 8:53 AM, "Josh Tynjala"  wrote:

I'm not exactly sure what you'd like me to check in SWF output. Can you add 
some more detail?

- Josh

On 2019/02/19 16:37:04, Alex Harui  wrote: 
> For #1, did you test using SWF output?  There's a small chance it will do 
more checks than the JS output.
> 
> -Alex
> 
> On 2/19/19, 8:03 AM, "Josh Tynjala"  wrote:
> 
> 1. b.moveTo(Number(path.pathPoints[0].anchor.x), 
Number(path.pathPoints[0].anchor.y));
> 
> I have determined that the compiler is not correctly resolving the 
type of pathPoints[0]. It should be PathPointVO because we're dealing with a 
Vector, but it's being resolved as * instead, which is how regular Arrays are 
handled.
> 
> I can see that this issue with resolving the type also affects code 
intelligence in VSCode. Members of PathPointVO are not available in the 
completion list for pathPoints[0].
> 
> I have checked Flash Builder, and the type of a Vector item seems to 
be known because the correct completion items are suggested. Additionally, a 
compiler error is created for the following code in Flash Builder, but not from 
Royale:
> 
> var firstItem:SomeOtherType = pathPoints[0];
> 
> > Error: Implicit coercion of a value with static type PathPointVO to 
a possibly unrelated type SomeOtherType.
> 
> This indicates to me that Adobe fixed this issue in ASC 2.0 after the 
donation of "Falcon" to Apache, and we should do the same.
> 
> Once the correct type is resolved here, there won't be any coercion 
emitted.
> 
>  2. paragraph.setStyle("tabXML", 
escape(org.apache.royale.utils.Language.string(para.tabXML.toXMLString(;
> 
> Confirmed.
> 
> Interestingly, in VSCode, toXMLString() is provided in the completion 
list, but hover and goto definition are not working on it. This indicates to me 
that the compiler is not correctly resolving toXMLString(), so it's falling 
back to * for the type.
> 
> Also interestingly, Flash Builder provides hover for toXMLString(), 
but no compiler error when assigning to another type. I suspect that XML is 
getting special treatment in FB, and ASC 2.0 does not resolve the type of 
anything on XML either.
> 
> It looks like the emitter needs a special case for XML and I can 
manually resolve certain types. There may be some logic for this already in one 
of the emitters. I'll make sure that it works the same everywhere.
> 
> 3. 
doc.retrieveFile(org.apache.royale.utils.Language.string(file.attribute('loc').toString()));
> 
> This is basically the same as 2. Lack of type resolution for XML.
> 
> 4. stroke.setLineStyle(1, 65535, 1);
> 
> This was a result of ensuring that numeric literals are emitted 
correctly for integers. The value is the same, but it's just formatted a 
different way. I think that I had the option of emitting the literal with a 
specific radix, so I may be able to detect and preserve the 0x formatting.
> 
> 5. 
xml.setNodeKind(org.apache.royale.utils.Language.string(this.XML__nodeKind));
> 
> This looks to be the same as 2 and 3. Again, lack of type resolution 
for XML.
> 
> - Josh
> 
> On 2019/02/10 10:02:53, Harbs  wrote: 
> > The commit seems to break some things for me.
> > 
> > I’m working on finding the exact problem, but I’m noticing issues 
along the way:
> > 
> > 1.
> > In function:
> > function drawPath(path:BezierPathVO,b:PathBuilder):void
> > 
> > The following:
> > b.moveTo(path.pathPoints[0].anchor.x,path.pathPoints[0].anchor.y);
> > 
> > compiles to:
> > b.moveTo(Number(path.pathPoints[0].anchor.x), 
Number(path.pathPoints[0].anchor.y));
> > 
> > pathPoints is of type Vector.
> > and PathPointVO anchor is of type Point
> > 
> > x and y should be inferrable that they are Numbers and it should 
compile unchanged.
> > 
> > 2.
> > paragraph.setStyle("tabXML", escape(para.tabXML.toXMLString()));
> > 
> > Compiles to:
> > paragraph.setStyle("tabXML", 
escape(org.apache.royale.utils.Language.string(para.tabXML.toXMLString(;
> > 
> > para.tabXML is typed as XML and toXMLString() should be 
recognizable as a String and Language.string() should not be called.
> > 
> > 3.
> > var file:XML = files[i];
> > 

Jenkins build is back to normal : royale-asjs_MXTests #520

[Apache Royale CI Server]

See 

Heads-up on coming updates to reflection and AMF

[Greg Dove]

Just a fyi about what I am working on

I am currently working on AMFBinaryData updates to support:

IExternalizable
dynamic class instances
I expect to also support IDynamicPropertyWriter

And refactoring the AMFBinaryData class to be a subclass of BinaryData
(this part is done) and have an api that mirrors the IDataInput/IDataOutput
in flash.
IDataInput and IDataOutput extend the IBinaryDataInput and
IBinaryDataOutput counterparts.
The only inconsistencies at this point for those ByteArraylike interfaces
will be the missing implementation of multibyte string support in
javascript and support for AMF0. I think both of these are low priority.
But maybe they could be addressed in the future if there is need.

There is one 'breaking' change that was required in BinaryData with these
changes.
I had to change the writeBytes/readBytes method signatures.
The original method signature is still available but will become
writeBinaryData/readBinaryData
Aside from the addition of the one extra method here, the changes to
BinaryData are very 'light'

I will check the rest of the framework and make those changes if they are
necessary anywhere. But this would be a simple search and replace fix for
code that relies on the current implementation for anything outside the
framework.

This change is to permit the writeBytes/readBytes methods to work with the
native bytes array classes (so: ByteArray in flash and ArrayBuffer in js,
and that means that the interface remains compatible with the original
flash interface on swf)

Along with these updates, the AMFNetConnection class will be updated to use
the new AMFBinaryData api.

The main part of the above is basically already done locally, but I am
still working on the first two parts. I've kept AMFBinaryData in the
network lib for now, but I think it probably belongs in core, and just
AMFNetConnection could use it in Network lib... something maybe to consider
for later.

So the cloning support via AMFBinaryData will become pretty much the same
as flash ByteArray:

myamfData.writeObject(myRoyalObject);
myamfData.position=0;
var copy:MyRoyaleObject = myamfData.readObject() as MyRoyaleObject;

For the reflection updates, they are corequisite for some of the AMF
updates.
There is a fix for some issues that were introduced a few months back that
broke the lazy evaulation of the getters in TypeDefinition.
There's also a fix for another error exposed by the recent numeric coercion
updates  that Josh added to the compiler (which is great).
There will be new reflection utility methods to detect if an object is
dynamic and to get its dynamic fields (separate to sealed properties).
These can probably be reused in some of the mx code. Some of these may need
tuning and improvements over time.

The UnitTests manual test project will become functional again, with new
tests for some of the new functionality/classes. (I am using it to test
between swf and js as I work on things).

Anyway, I hope to have changes in the next few days. Thought I would let
you know in advance...

Jenkins build is back to normal : royale-asjs_jsonly #2500

[Apache Royale CI Server]

See 

Build failed in Jenkins: royale-asjs_MXTests #519

[Apache Royale CI Server]

See 


--
[...truncated 2.02 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

Jenkins build is back to normal : royale-asjs_jsonly #2498

[Apache Royale CI Server]

See 

Re: [royale-compiler] 05/05: ParametersEmitter: fixed automatic type coercion and added some tests (closes #74)

[Josh Tynjala]

My latest improvements to the compiler should resolve these 5 issues with 
coercion.

- Josh

On 2019/02/19 16:03:05, Josh Tynjala  wrote: 
> 1. b.moveTo(Number(path.pathPoints[0].anchor.x), 
> Number(path.pathPoints[0].anchor.y));
> 
> I have determined that the compiler is not correctly resolving the type of 
> pathPoints[0]. It should be PathPointVO because we're dealing with a Vector, 
> but it's being resolved as * instead, which is how regular Arrays are handled.
> 
> I can see that this issue with resolving the type also affects code 
> intelligence in VSCode. Members of PathPointVO are not available in the 
> completion list for pathPoints[0].
> 
> I have checked Flash Builder, and the type of a Vector item seems to be known 
> because the correct completion items are suggested. Additionally, a compiler 
> error is created for the following code in Flash Builder, but not from Royale:
> 
> var firstItem:SomeOtherType = pathPoints[0];
> 
> > Error: Implicit coercion of a value with static type PathPointVO to a 
> > possibly unrelated type SomeOtherType.
> 
> This indicates to me that Adobe fixed this issue in ASC 2.0 after the 
> donation of "Falcon" to Apache, and we should do the same.
> 
> Once the correct type is resolved here, there won't be any coercion emitted.
> 
>  2. paragraph.setStyle("tabXML", 
> escape(org.apache.royale.utils.Language.string(para.tabXML.toXMLString(;
> 
> Confirmed.
> 
> Interestingly, in VSCode, toXMLString() is provided in the completion list, 
> but hover and goto definition are not working on it. This indicates to me 
> that the compiler is not correctly resolving toXMLString(), so it's falling 
> back to * for the type.
> 
> Also interestingly, Flash Builder provides hover for toXMLString(), but no 
> compiler error when assigning to another type. I suspect that XML is getting 
> special treatment in FB, and ASC 2.0 does not resolve the type of anything on 
> XML either.
> 
> It looks like the emitter needs a special case for XML and I can manually 
> resolve certain types. There may be some logic for this already in one of the 
> emitters. I'll make sure that it works the same everywhere.
> 
> 3. 
> doc.retrieveFile(org.apache.royale.utils.Language.string(file.attribute('loc').toString()));
> 
> This is basically the same as 2. Lack of type resolution for XML.
> 
> 4. stroke.setLineStyle(1, 65535, 1);
> 
> This was a result of ensuring that numeric literals are emitted correctly for 
> integers. The value is the same, but it's just formatted a different way. I 
> think that I had the option of emitting the literal with a specific radix, so 
> I may be able to detect and preserve the 0x formatting.
> 
> 5. 
> xml.setNodeKind(org.apache.royale.utils.Language.string(this.XML__nodeKind));
> 
> This looks to be the same as 2 and 3. Again, lack of type resolution for XML.
> 
> - Josh
> 
> On 2019/02/10 10:02:53, Harbs  wrote: 
> > The commit seems to break some things for me.
> > 
> > I’m working on finding the exact problem, but I’m noticing issues along the 
> > way:
> > 
> > 1.
> > In function:
> > function drawPath(path:BezierPathVO,b:PathBuilder):void
> > 
> > The following:
> > b.moveTo(path.pathPoints[0].anchor.x,path.pathPoints[0].anchor.y);
> > 
> > compiles to:
> > b.moveTo(Number(path.pathPoints[0].anchor.x), 
> > Number(path.pathPoints[0].anchor.y));
> > 
> > pathPoints is of type Vector.
> > and PathPointVO anchor is of type Point
> > 
> > x and y should be inferrable that they are Numbers and it should compile 
> > unchanged.
> > 
> > 2.
> > paragraph.setStyle("tabXML", escape(para.tabXML.toXMLString()));
> > 
> > Compiles to:
> > paragraph.setStyle("tabXML", 
> > escape(org.apache.royale.utils.Language.string(para.tabXML.toXMLString(;
> > 
> > para.tabXML is typed as XML and toXMLString() should be recognizable as a 
> > String and Language.string() should not be called.
> > 
> > 3.
> > var file:XML = files[i];
> > doc.retrieveFile(file.@loc.toString());
> > 
> > Compiles to:
> > doc.retrieveFile(org.apache.royale.utils.Language.string(file.attribute('loc').toString()));
> > 
> > The compiler should know that toString() is a string and doesn’t need 
> > Language.string()
> > 
> > 4.
> > Another interesting change:
> > stroke.setLineStyle(1,0x00,1);
> > 
> > Now becomes:
> > stroke.setLineStyle(1, 65535, 1);
> > 
> > I’m not sure whether this is something we should be concerned about or not.
> > 
> > 5.
> > XML has many cases where you have something like this:
> > xml.setNodeKind(_nodeKind);
> > becomes
> > xml.setNodeKind(org.apache.royale.utils.Language.string(this.XML__nodeKind));
> > 
> > Although everything is strings…
> > 
> > 
> > 
> > 
> > 
> > 
> > > On Feb 6, 2019, at 6:40 PM, joshtynj...@apache.org wrote:
> > > 
> > > This is an automated email from the ASF dual-hosted git repository.
> > > 
> > > joshtynjala pushed a commit to branch develop
> > > in repository https://gitbox.apache.org/repos/asf/royale-compiler.git
> > > 
> > > 

Re: Breaking Compiler Change

[Harbs]

It exists to make Flex uses compatible with Royale when the type could not be 
determined.

It’s possible that the new coercions might make it no longer necessary, but 
this whole thread started because the XML split method was still being called, 
so I’m not sure that we’re there yet…

> On Feb 20, 2019, at 12:57 AM, Josh Tynjala  wrote:
> 
> Here is where it is defined in Royale:
> 
> https://github.com/apache/royale-asjs/blob/e02f896f3510a90aff00d852dac4401e2705fcf3/frameworks/projects/XML/src/main/royale/XML.as#L2767
> 
> It does not exist in Flash. I'm trying to determine why it exists in Royale 
> and if it's still necessary.
> 
> - Josh
> 
> On 2019/02/19 22:49:03, Alex Harui  wrote: 
>> I'm confused.  Where is the ASDoc for XML.split?  
>> 
>> On 2/19/19, 2:41 PM, "Josh Tynjala"  wrote:
>> 
>>I was just playing around with XML in Flash, and I tried this code:
>> 
>>var xml:XML = ;
>>var parts:Array = xml.split("/");
>> 
>>It compiles, but I get the following runtime error:
>> 
>>> TypeError: Error #1006: value is not a function.
>> 
>>To work in Flash, I need to assign the XML instance to a String first so 
>> that the type is coerced.
>> 
>>var xml:XML = ;
>>var str:String = xml;
>>var parts:Array = str.split("/");
>> 
>>Why exactly does the Royale XML class include these methods from String? 
>> Could it be because we were previously missing the automatic type coercion 
>> in some situations (like parameters and returns)? Assuming that the coercion 
>> correctly handles converting XML to string now, could these methods be 
>> safely removed?
>> 
>>- Josh
>> 
>>On 2019/02/19 19:15:27, Harbs  wrote: 
>>> The methods in XML are there to allow XML to behave as if it’s a String or 
>>> a Number.
>>> 
>>> In JS, the signature of split is "undefined|Number". That becomes “*” in 
>>> AS3 considering AS3 does not have “dual” types.
>>> 
>>> 
 On Feb 19, 2019, at 8:59 PM, Josh Tynjala  wrote:
 
 My gut feeling would be to strive for consistency in how the automatic 
 type conversion behaves. If some function calls have it, and others don't, 
 that's potentially confusing. Someone used to AS3 behavior might expect 
 undefined to become NaN, and they'll wonder why it didn't happen in one 
 place when it happens in others. (That particular one may be rare, but 
 some of the other conversions will definitely be expected to have 
 consistency, like converting to int or String).
 
 I guess what I don't understand it this: Why is the limit parameter typed 
 as * here?
 
 split(delimiter:* = undefined, limit:* = undefined):Array
 
 To me, there doesn't seem to be any reason to accept non-numeric values 
 for limit. This seems like a perfect situation to take advantage of typing 
 because that's why we've chosen AS3 over JS.
 
 - Josh
 
 On 2019/02/19 17:36:23, Harbs  wrote: 
> I did not mean that Number(undefined) shouldn’t become NaN. That’s 
> correct behavior. I was questioning the coercion here.
> 
> I already changed XML to used bracketed access for this problem.
> 
> I’m not thrilled about passing in a number to split. My gut tells me that 
> it’s probably slower than undefined. (Although for XML methods it’s 
> probably not that big a deal.)
> 
> I’m more concerned about client code. Native JS methods don’t really have 
> the same signatures as Flash ones and JS is pretty good about handling 
> all kinds of data types correctly. I’m wondering if it really makes sense 
> to coerce types that are passed into native JS methods.
> 
> Thoughts?
> Harbs
> 
>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala  wrote:
>> 
>> I tested the following code in Flash:
>> 
>> var num:Number = undefined;
>> trace(num); //NaN
>> 
>> Assigning undefined to a Number results in NaN in Flash.
>> 
>> The XML signature for split() should probably look like this instead:
>> 
>> split(delimiter:* = undefined, limit:Number = 0x7fff):Array
>> 
>> It looks like String defines the limit parameter's type as Number, or 
>> this coercion wouldn't be happening, so it would make sense to me for 
>> XML to use the same type.
>> 
>> - Josh
>> 
>> On 2019/02/10 11:08:14, Harbs  wrote: 
>>> Found it in XML:
>>> 
>>> public function 
>>> split(separator:*=undefined,limit:*=undefined):Array
>>> {
>>> return s().split(separator,limit);
>>> }
>>> 
>>> Becomes:
>>> 
>>> XML.prototype.split = function(separator, limit) {
>>> separator = typeof separator !== 'undefined' ? separator : undefined;
>>> limit = typeof limit !== 'undefined' ? limit : undefined;
>>> return this.XML_s().split(separator, Number(limit));
>>> };
>>> 
>>> Number(limit) 

Migrating an app from Apache Flex to Apache Royale (tweet thread)

[Carlos Rovira]

Hi,

just want to share our recent experience migrating an Apache Flex
application to Apache Royale.
So I post a thread of 17 tweets here:

https://twitter.com/carlosrovira/status/1098333642751950848

Hope the info will be useful :)

Enjoy and don't forget to share if that was useful for you! :)

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

Jenkins build is back to normal : royale-asjs_jsonly #2495

[Apache Royale CI Server]

See 

Re: Problems dealing with bead substitution in Royale

[Carlos Rovira]

Hi Harbs

El mar., 19 feb. 2019 a las 18:30, Harbs () escribió:

>
>
> Yes. Basically, you can ask any bead for a list of its interests, and that
> list is used to both add and remove bead references in the strand. The bead
> does not need to clean itself. A ututiliy method can completely strip a
> bead off a strand including all references necessary for notification. Take
> a look how that’s done here:
>
> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-5f2744f9620d90c13d8759c4a326e8cbR27
>
>
I think most of the time, beads would need some code on its own that should
be run when removed, but anyway maybe that's no a problem

>
> Benefits:
> 1. Beads do not reference the Strand at all. All references are from the
> Strand to the bead.

2. Event listeners have a lot of indirection when they are launched. It’s
> much easier to step through notification dispatching.
> 3. Because notifications have no callback passing, there’s less chance of
> memory leaks due to callback references.
> 4. Currently, the framework has countless uses of “_strand as
> IEventDispatcher”. This is not something I’m thrilled with. Notifications
> make things much cleaner.
> 5. There’s a single entry point for notifications in a bead. I think that
> makes things easier to grok.
> 6. I think notifications makes it cleaner to use a single bead on multiple
> strands (if so desired).
>

ok, seems good


>
> > 4.- Do you see some drawback? or what's the flaw points we can get over
> the
> > traditional event dispatch system?
>
> Here’s the drawbacks that I see:
> 1. We’re adding some additional weight to strands and beads.
>

in some places I think we should not be extremely purist.


> 2. Some of the events that we’re dispatching are used on different beads
> such as “layoutNeeded” where we’re laying out children relative to their
> parents. Cases like that will be needed to be handled.
>
> Regarding #1. I think the additional weight is more than offset by code
> saved by not having to attach so many event handlers.
> Regarding #2: Events can still be used when they make sense, or maybe
> there’s some other way to handle layout issues. Not 100% sure on the best
> way to handle that problem.
>
> > Sorry, if I need more explanation, but I still trying to figure what's
> all
> > about. Hope with your explanation I'll see the big picture
> >


For me seems ok. I understand that although we add this we always can rely
on the old system, and migrate if we want different parts little by little
right?. And don't seems to much code added, so for me this doesn't break
PAYG. As I said before I think we should not be purist to the limit.
Maybe I'd need to experiment a bit with all this stuff to end understanding
and assimilate.

What do think others? any problem to add this notification system?

thanks



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

Re: Does Oracle's new 2019 Java licensing affects Royale?

[Carlos Rovira]

Hi Olaf,

before comment anything, I must say that I didn't read the new license, but
IICRC the changes was for new Java 11 version

Anyway, Royale is using Java 8, and our code can be compiled with either,
Oracle Java, or OpenJDK. So, that means for me, that if Oracle could make
some change in license that could be a problem, people could always go with
any Open JDK out there.

Maybe not an answer based on the license terms that you could expect, but
maybe we don't have to worry by any Oracle changes. I thing they do that in
order to target big enterprises and customers that could generate some
profit for them paying some maintenance or support service.

Best

Carlos


El mié., 20 feb. 2019 a las 9:15, Olaf Krueger ()
escribió:

> Hi,
> like many other companies, we have to deal here with Oracles new Java
> strategy [1].
> I am not familiar with Java and it seems to me that there is a lot of
> confusion about the future of Java out there.
> (For those which are interesting in this topic, this is a good summary [2])
>
> However, I wonder if those changes affect Royale (or all those other Open
> source projects out there based on Java) in whatever respect?
>
> Thanks,
> Olaf
>
>
> [1] https://www.oracle.com/technetwork/java/javase/overview/index.html
> [2] https://dzone.com/articles/eliminating-java-update-confusion
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>


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

Jenkins build is back to normal : royale-asjs_MXTests #515

[Apache Royale CI Server]

See 

Build failed in Jenkins: royale-asjs_MXTests #514

[Apache Royale CI Server]

See 


Changes:

[carlosrovira] fix a regression in jewel item render that removes other content 
when

--
[...truncated 2.02 MB...]
[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

[mxmlc] using source file: 

Jenkins build is back to normal : TourDeFlexMigration #532

[Apache Royale CI Server]

See 

Does Oracle's new 2019 Java licensing affects Royale?

[Olaf Krueger]

Hi,
like many other companies, we have to deal here with Oracles new Java
strategy [1].
I am not familiar with Java and it seems to me that there is a lot of
confusion about the future of Java out there.
(For those which are interesting in this topic, this is a good summary [2])

However, I wonder if those changes affect Royale (or all those other Open
source projects out there based on Java) in whatever respect?

Thanks,
Olaf


[1] https://www.oracle.com/technetwork/java/javase/overview/index.html
[2] https://dzone.com/articles/eliminating-java-update-confusion



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