Array sort with numeric argument

[Frost, Andrew]

Hi all

Been a little while as I've been busy with AIR stuff, but we've also got a 
Royale project ongoing and we have an issue which I'm hoping can be fixed by a 
compiler update..

The issue is really simple so I'm slightly surprised we're hitting this:
  var a : Array = [ "one", "two", "three" ];
  a.sort(Array.DESCENDING);
  trace(a);

This throws an ImplicitCoercionToUnrelatedTypeProblem
and results in:
Error: Implicit coercion of a value of type Number to an unrelated type 
Function.
  a.sort(Array.DESCENDING);

Presumably this is because the Array is a JavaScript class and it expects a 
compare function as the only option. AS3's definition of Array takes an 
optional number after the optional function (and is also very forgiving if you 
then add in extra unused parameters after those two..), so valid calls would be:
sort(Number)
sort(Function)
sort(Function, Number)
sort(Function, Number, anything else ..)
i.e. the first argument must be a function or a number; if it' a function then 
the second argument must be a number.

Note that there is code to actually handle the Array.sort() method and to check 
for a numeric first argument: if this is the case then it gets turned into 
Language.sort() - see FunctionCallEmitter.java.


So my question really is, how do we add in the extra function overload 
definitions for this?

  *   is there a "proper" way that would ensure that the error isn't thrown by 
ensuring that the function definition is correct in the first place? Perhaps 
switching it to the AS3 definition of "function 
sort(...
 
args):Array"
 ?
  *   or, given we already have some hard-coded handling for this, would it be 
okay to add a special case into the 
MethodBodySemanticChecker.checkFunctionCall() method to handle this?

I would prefer the former but am not sure whether we can just override a Java 
built-in definition, it's not quite the same as where we're adding missing 
properties such as the Array.DESCENDING stuff within the typedefs..
If this can be done from there: can anyone remind me of the steps to take? I've 
had a go at adding overrides to the "missing.js" file and then compiled the 
typedefs using ant; no errors, and it had some "copying files" reported to the 
compiler and royale-asjs projects. But I still get the same error..


Any thoughts appreciated!

thanks

   Andrew

RE: Array sort with numeric argument

[Frost, Andrew]

Hi

Thanks - so that looks like a good approach. I've just had a quick go at trying 
to hack this (the closure compiler jar file has a zip that contains this es3.js 
file..) but no joy so it looks like it needs to be built properly.

If I was just to build that closure compiler (properly), and put the resulting 
JAR file into royale-asjs/js/lib/google/closure-compiler/compiler.jar, should 
that be sufficient? .. it doesn't actually seem like that jar file is being 
loaded at all when I compile, I've just renamed two folders:
C:\Work\Royale\royale-asjs\js\lib\google
so I no longer have "closure-compiler" or "closure-library", and I'm still 
getting it building (and failing):

>c:\work\Royale\royale-asjs\js\bin\mxmlc TestArray.mxml
Using Royale Compiler codebase: c:\Work\Royale\royale-asjs\js\bin\..\..
Using Royale SDK: c:\Work\Royale\royale-asjs\js\bin\..\..
MXMLJSC
-sdk-js-lib=c:\Work\Royale\royale-asjs\js\bin\..\..\frameworks\js\Royale\generated-sources
TestArray.mxml
C:\...\TestArray.mxml(20): col: 14 Error: Implicit coercion of a value of type 
Number to an unrelated type Function.
  a.sort(Array.DESCENDING);

There's no such folder as the one being passed in to sdk-js-lib, don't know 
where that comes from but no 'Royale' folder under frameworks\js..

So basically - once the closure compiler is updated, what happens next in order 
to get these definitions to be recognised within Royale?!


thanks

   Andrew


-Original Message-
From: Alex Harui  
Sent: 26 February 2020 07:29
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Array sort with numeric argument

Hi Andrew,

IIRC, there are a few places where we've already edited the JS definition, 
which is why the typedefs use custom versions of Google Closure's externs 
instead of externs directly from their repo.

So I think it is just a matter of editing:
https://clicktime.symantec.com/3AafESw7XFxpnySNpTYup3L7Vc?u=https%3A%2F%2Fraw.githubusercontent.com%2Froyale-extras%2Fclosure-compiler%2Froyale%2Fexterns%2Fes3.js
which I believe comes from
https://clicktime.symantec.com/3wUnMy1wgiKftPWEeyrXBx7Vc?u=https%3A%2F%2Fgithub.com%2Froyale-extras%2Fclosure-compiler%2Fblob%2Fmaster%2Fexterns%2Fes3.js

If we change the parameter for Array.sort to the AS parameter list to (... 
args) instead of Function, then the final Array.as in royale-typedefs/js should 
allow anything there, and FunctionCallEmitter.java can pick up the extra cases 
and MethodBodySemanticChecker should not complain.

I think Harbs owns that repo and can update that file.

-Alex


On 2/25/20, 10:58 PM, "Frost, Andrew"  wrote:

Hi all

Been a little while as I've been busy with AIR stuff, but we've also got a 
Royale project ongoing and we have an issue which I'm hoping can be fixed by a 
compiler update..

The issue is really simple so I'm slightly surprised we're hitting this:
  var a : Array = [ "one", "two", "three" ];
  a.sort(Array.DESCENDING);
  trace(a);

This throws an ImplicitCoercionToUnrelatedTypeProblem
and results in:
Error: Implicit coercion of a value of type Number to an unrelated type 
Function.
  a.sort(Array.DESCENDING);

Presumably this is because the Array is a JavaScript class and it expects a 
compare function as the only option. AS3's definition of Array takes an 
optional number after the optional function (and is also very forgiving if you 
then add in extra unused parameters after those two..), so valid calls would be:
sort(Number)
sort(Function)
sort(Function, Number)
sort(Function, Number, anything else ..)
i.e. the first argument must be a function or a number; if it' a function 
then the second argument must be a number.

Note that there is code to actually handle the Array.sort() method and to 
check for a numeric first argument: if this is the case then it gets turned 
into Language.sort() - see FunctionCallEmitter.java.


So my question really is, how do we add in the extra function overload 
definitions for this?

  *   is there a "proper" way that would ensure that the error isn't thrown 
by ensuring that the function definition is correct in the first place? Perhaps 
switching it to the AS3 definition of "function 
sort(...<https://clicktime.symantec.com/3UhYNbMDsk619zEbD94SWgU7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fhelp.adobe.com%252Fen_US%252FFlashPlatform%252Freference%252Factionscript%252F3%252Fstatements.html%2523..._%28rest%29_parameter%26data%3D02%257C01%257Caharui%2540adobe.com%257C8bc49bc1e3da4ce469f508d7ba893372%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C637182970796966183%26sdata%3D7t7BJmqI4yGxB9AO45fBcFqxzaQDgrlE%252B8pXSaycXvU%253D%26reserved%3D0>
 
args):Array<https://

RE: Array sort with numeric argument

[Frost, Andrew]

Thanks Harbs, Alex

So yes, that worked, rebuilding the typedefs pulled down the updated stuff from 
royale-extras..
And I've also updated and re-compiled the compiler with Alex's changes just for 
good measure..

cheers

   Andrew


-Original Message-
From: Alex Harui  
Sent: 26 February 2020 19:38
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Array sort with numeric argument



On 2/26/20, 11:33 AM, "Harbs"  wrote:

Do you need me to revert?

No, your change is "ok".  It might have been better to go with ... args, but it 
doesn't really matter now, I think I've updated the compiler to handle the 3 
main cases.

-Alex

> On Feb 26, 2020, at 9:04 PM, Alex Harui  wrote:
> 
> Looks like that change is causing compiler tests to fail, so I am going 
to try to fix up FunctionCallEmitter now.
> 
> -Alex
> 
> On 2/26/20, 9:41 AM, "Alex Harui" mailto:aha...@adobe.com.INVALID>> wrote:
> 
>Hi Andrew,
> 
>Harbs updated the file on royale-extras.  So you should now be able to 
build royale-typedefs (use "mvn clean" or "ant wipe" first to clear out the old 
version), then build royale-asjs and the compiler should no longer complain 
about the args.  Then updated FunctionCallEmitter if needed to get the right 
output.
> 
>HTH,
>-Alex
> 

MX/Spark application: SystemManager generation

[Frost, Andrew]

Hi all

We've got an annoying situation with an application class that derives from the 
spark.components.Application class...
If we have an MXML file that defines a class that derives directly from this 
(or from mx.core.Application) then we get an extra class auto-generated (below) 
which derives from mx.managers.SystemManager.

The issue is, when our MXML file derives from another class, which itself 
extends the Spark (or MX) Application class, then this extra class isn't 
generated, the HTML just tries to call our application.start() method, and this 
doesn't add in the right glue code.

>From what I can see, there's a decision happening within the compiler:
org.apache.royale.compiler.internal.targets.RoyaleApplicationFrame1Info
where it's got a function:
ApplicationAndModuleDefinitions.isApplicationOrModule()
where the class definition is checked to see if it inherits from one of the 
Spark/MX/Halo application classes.

The change seems simple: we just recurse here to walk up the inheritance of the 
given class definition, until we reach the top or find that we do derive from 
one of these...

So I have a proposed change (and have pushed it to my github fork below)
https://github.com/ajwfrost/royale-compiler/commit/1c4ca15a05bd822a379e9f6fc2d3d03280806132

The issue here is that I can't work out how to test this change! I've compiled 
the compiler (at least, run 'ant' within the royale-compiler folder) and have 
also compiled the royale-asjs project after this ('ant all'), and have manually 
copied the jar files from royale-compiler\compiler\lib to royale-asjs\lib, but 
I'm not getting my new code being hit at all. So is anyone able to confirm 
whether this is actually the right place for the change, and how I can get the 
updated compiler code so that it's actually in use? I've tried running the 
compiler via Eclipse - I used to have this working but doing 'git pull' and 
getting all the recent updates has broken this somehow so I no longer have the 
compiler working for debugging it either..

thanks

   Andrew


Generated class below - this is what I want to generate even if we derive from 
spark.components.Application via an intermediary class:


/**
* @constructor
* @extends {mx.managers.SystemManager}
*/
test_mx_managers_SystemManager = function() {
  test_mx_managers_SystemManager.base(this, 'constructor');
   this.mainClassName = test;
};
goog.inherits(test_mx_managers_SystemManager, mx.managers.SystemManager);
goog.exportSymbol('test_mx_managers_SystemManager', 
test_mx_managers_SystemManager);
/**
* @type {Object.>}
*/
test_mx_managers_SystemManager.prototype.ROYALE_CLASS_INFO = { names: [{ name: 
'test_mx_managers_SystemManager', qName: 'test_mx_managers_SystemManager', 
kind: 'class' }]};

RE: MX/Spark application: SystemManager generation

[Frost, Andrew]

Thanks Alex

I hadn't known about that [Frame] metadata thing - looks exactly what we need 
though!

cheers



-Original Message-
From: Alex Harui  
Sent: 09 March 2020 16:02
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: MX/Spark application: SystemManager generation

Hi Andrew,

I believe that RoyaleApplicationFrame1Info is for SWF output only.  Large parts 
of the files in the compiler and compiler-common projects are used in JS 
transpiling, but I don't think that one is.  The JS output has its own 
factoryClass handling in MXMLRoyalePublisher.java.

Although, FWIW, the easier workaround may be to simply replicate the [Frame] 
metadata into the Application subclass.

HTH,
-Alex

Re: Unable to build with ANT

[Frost, Andrew]

Sorry, this was probably my fault when I added in that file to begin with .. 
Yishay thanks for making the correction.

Note to self: try setting my computer to both summer and winter dates when 
testing anything related to time and dates! And looking at the file's history, 
also set my location to a variety of places around the world to ensure it works 
east of here as well as west!

Oddly enough I was reading this morning that 84% of folk in Europe want to get 
rid of the daylight savings thing, and each country may end up fixing their 
time to stop the clocks changing in the future .. it would make things easier 
if this happened!

thanks

  Andrew



-Original Message-
From: Douglas McCarroll [mailto:list.apache-royal@brightworks.com] 
Sent: 28 October 2018 12:15
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Unable to build with ANT

Perhaps worth noting that while Europe switched from daylight savings time last 
night, the USA didn't. I believe that we switch next weekend. So, if there's 
something in the ant build that depends on there being a specific number of 
hours difference, then that will fail.

On Sun, Oct 28, 2018 at 5:21 AM Carlos Rovira 
wrote:

> Hi,
>
> I found a way to get ANT compilation working. "ant all" is broken so:
>
> 1.- Go to compiler: run "ant sdk"
> 2.- Go to typedefs: run "ant"
> 3.- Go to framework: run "ant"
>
> This works for now.
>
> I think the problem is related to the change of hour like Nicolas 
> suggested, since I wake up and the hour changed due to daylight saving 
> time and we have 1 hour less.
> The problem seems to be in the test run in the compiler, skipping that 
> part with "ant sdk" make the rest works ok.
>
>
>
>
>
> El dom., 28 oct. 2018 a las 10:15, Yishay Weiss 
> ()
> escribió:
>
> > Same problem here. Looking into it.
> >
> >
> >
> > 
> > From: Carlos Rovira 
> > Sent: Sunday, October 28, 2018 9:54:30 AM
> > To: dev@royale.apache.org
> > Subject: Unable to build with ANT
> >
> > Hi,
> >
> > I'm starting my day and always build with maven and then build a 
> > fresh
> SDK
> > with ANT to feed VSCode IDE.
> > Today I'm finding the "ant all" process is failing for me [1] and 
> > seems something related to time zone test failing. Is the first time 
> > I see
> this.
> > Don't see any changes that could affect in the last day, so I'm a 
> > bit
> lost
> > here.
> >
> > Hope someone could bring some light on this.
> >
> > Thanks
> >
> > [1] 
> > https://clicktime.symantec.com/a/1/2O8xnfWy4QA6AgSzR8cYnzsLODmFedbgR
> > mTd-sgzq_8=?d=5m2hCvv65cBTfe-rBB4t2rYmEDtRqTAIIORbGgCQ4qpow3fNSBz_im
> > gGyzg6cqNoPXtSQOurVLEvCByZEJVPSTJXiBpQQM_B7t0yZAnl0QcWIwwqM9axwEob5F
> > 21r1O_QhgJokNm6FzK5_SdI3sJGDST-5tc4N-VLx07jqK0BvxHq82ueWxtGYQpQ4PG5X
> > 9g5K9d4_wYdg0cnJZ6hLmY2nO7AcMnWfe3bvnXWdV3s5lKzl_rOTjK2C9hywK1BcIjWS
> > 72qukOS0zYm0-oSKEiPUELd7nM-iE8xFtMKU3ubj_ocFn9Sxzlu0n8hdsKGkq7dB5umH
> > b-plnfPoEk_h5PSktbfxiK1M8_6uhHiix2plQcozFao6odILm97uOP3vO2WG7HMU7B4x
> > tut3OTmHtVJLe25o2xQyYJyk5jDIqoUnkhWKmT39maiG_-lg%3D%3D&u=https%3A%2F
> > %2Fpaste.apache.org%2FTaYu
> >
> > --
> > Carlos Rovira
> > https://clicktime.symantec.com/a/1/rcKcsSo3mqzGZ1b0tr2KTdb5YwDfgnH3S
> > YE0zhUx8xg=?d=5m2hCvv65cBTfe-rBB4t2rYmEDtRqTAIIORbGgCQ4qpow3fNSBz_im
> > gGyzg6cqNoPXtSQOurVLEvCByZEJVPSTJXiBpQQM_B7t0yZAnl0QcWIwwqM9axwEob5F
> > 21r1O_QhgJokNm6FzK5_SdI3sJGDST-5tc4N-VLx07jqK0BvxHq82ueWxtGYQpQ4PG5X
> > 9g5K9d4_wYdg0cnJZ6hLmY2nO7AcMnWfe3bvnXWdV3s5lKzl_rOTjK2C9hywK1BcIjWS
> > 72qukOS0zYm0-oSKEiPUELd7nM-iE8xFtMKU3ubj_ocFn9Sxzlu0n8hdsKGkq7dB5umH
> > b-plnfPoEk_h5PSktbfxiK1M8_6uhHiix2plQcozFao6odILm97uOP3vO2WG7HMU7B4x
> > tut3OTmHtVJLe25o2xQyYJyk5jDIqoUnkhWKmT39maiG_-lg%3D%3D&u=http%3A%2F%
> > 2Fabout.me%2Fcarlosrovira
> >
>
>
> --
> Carlos Rovira
> https://clicktime.symantec.com/a/1/rcKcsSo3mqzGZ1b0tr2KTdb5YwDfgnH3SYE
> 0zhUx8xg=?d=5m2hCvv65cBTfe-rBB4t2rYmEDtRqTAIIORbGgCQ4qpow3fNSBz_imgGyz
> g6cqNoPXtSQOurVLEvCByZEJVPSTJXiBpQQM_B7t0yZAnl0QcWIwwqM9axwEob5F21r1O_
> QhgJokNm6FzK5_SdI3sJGDST-5tc4N-VLx07jqK0BvxHq82ueWxtGYQpQ4PG5X9g5K9d4_
> wYdg0cnJZ6hLmY2nO7AcMnWfe3bvnXWdV3s5lKzl_rOTjK2C9hywK1BcIjWS72qukOS0zY
> m0-oSKEiPUELd7nM-iE8xFtMKU3ubj_ocFn9Sxzlu0n8hdsKGkq7dB5umHb-plnfPoEk_h
> 5PSktbfxiK1M8_6uhHiix2plQcozFao6odILm97uOP3vO2WG7HMU7B4xtut3OTmHtVJLe2
> 5o2xQyYJyk5jDIqoUnkhWKmT39maiG_-lg%3D%3D&u=http%3A%2F%2Fabout.me%2Fcar
> losrovira
>

Re: Problems sending MX ArrayCollections with MX RemoteObject

[Frost, Andrew]

Hi guys

I'm not 100% sure whether this will help, but if I'm right in thinking that 
what you're trying to do is to mimic the Flash object serialisation, then I 
think that this information is actually in the public domain already..

Carlos, you wrote:
"ArrayCollection uses IExternalizable and that part is our main problem since 
we don’t have references, just simple docs but no real implementation, guides 
or notes about it."

The IExternalizable.as implementation is part of avmplus: 
https://github.com/adobe/avmplus/blob/master/core/IExternalizable.as
ArrayCollection is of course part of Flex: 
https://github.com/apache/flex-sdk/blob/master/frameworks/projects/framework/src/mx/collections/ArrayCollection.as
and you can then follow through what's happening.

And, having just done that, I'm guessing you're looking at how "readObject" 
works. Presumably you're serialising into a ByteArray, which means ultimately 
you'll end up in the heart of the avmplus code:
https://github.com/adobe/avmplus/blob/master/core/Toplevel.cpp#L1504
and
https://github.com/adobe/avmplus/blob/master/core/AvmSerializer.cpp
which is quite complex...!

Not sure if those help at all but it looks to me like it should be possible to 
have some JavaScript code to do all this. If this is the sort of area that 
you're looking at then let me know, I've got extensive experience with the 
avmplus code and have builds of it that I can tweak/play with to debug what 
happens in various scenarios! but I don't have any experience with using 
RemoteObject hence this may all be completely irrelevant..

thanks

   Andrew


-Original Message-
From: Greg Dove [mailto:greg.d...@gmail.com] 
Sent: 20 November 2018 09:47
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Problems sending MX ArrayCollections with MX 
RemoteObject

Hi Alex,

To follow on from what Carlos explained...  your initial implementation with 
AMFBinaryData was working quite well for smaller object graphs.

And I was able to make some changes to get it to special-case ArrayCollection 
for now on the reading side (it's not a proper implementation, but it was to 
get things working for now).

What I am missing is some good implementation notes ('conforming readers and 
writers must do this'). For example, I'm not sure what the object table
(rememberObject/traitsByReference) rules are for Externalizables, and it's 
really hard to 'discover' through comparisons with things like ByteArray or 
BlazeDS responses partly because the undefined output order of the fields in a 
large graph which makes direct comparison of byte sequences from the 2 sources 
not so easy.

In the end I will be happy to keep working on getting AMFBinaryData fully 
featured in my own time to help with the general MX effort, but Carlos needs 
certain things working for his project, which are our current priorities.

I do have some improvements that I can get in for AMFBinaryData in the next few 
days (I'm still refining things):
I have some code that avoids inappropriate field data for serialization:
only accessors with readwrite access (not getter only or setter only) no static 
accessors or variables excludes any field with 'Transient' metadata


But I'm still actively trying to figure out how to get the AC writing correctly 
in a complex graph, and I really need to understand what the rules are supposed 
to be. In terms of 'Externalizable' AC seems quite simple, so I thought it 
would be easy... but I think I am messing up the object reference table when I 
do this... I was hoping there might be something documented for implentation 
notes that is 'public' but 'not well publicized' that you might be aware of, 
perhaps through some of your internal connections. if we can get this fully 
fledged as quickly as possible, even if it just focused on AC for now on the 
'Externalizable'
side then that will help Alina and others as well, I think. I've had my head in 
this for a bit now, so if I have the info, I will find the time.

Hopefully you can provide some insight!
-Greg




On Tue, Nov 20, 2018 at 10:19 PM Carlos Rovira 
wrote:

> Hi Alex,
>
> Greg and I are working this days in sending MX ArrayCollection with MX 
> RemoteObject to BlazeDS. We found that part is not working.
> This is huge problem since without solving this we can't progress in 
> our migration, so hope you could take care of this issue and help us 
> to find the solution.
>
> The main problem is that we don't have or find a good reference of the 
> way it should be implemented and the format makes it difficult to discover.
> ArrayCollection uses IExternalizable and that part is our main problem 
> since we don’t have references, just simple docs but no real 
> implementation, guides or notes about it.
>
> Our better bet is that you could get some help at Adobe internally 
> since I don't think this info is in internet (at least we search 
> heavily to try to find).
>
> I think with out this problem fixed no application using MX 
> RemoteObje

Binding to private variables

[Frost, Andrew]

Hi all

I found recently that binding had stopped working when we were using private 
variables, for example:
  
where we declare:
private var _model : Model = Model.getModel();

However it works with protected/public variables..

The reason is clear when you look at the generated _bindings array, which 
contains:
  function() { return this.test_MainView__model.value; },
and then
  "_model",
  "valueChange",

So basically the watcher list is using "_model" whereas the property is 
actually generated as "test_MainView__model".

Looking at the compiler code, there's a function on the emitter which does this 
translation:
  public String formatPrivateName(String className, String name) {
return className.replace(".", "_") + "_" + name;
  }

However I can't work out how to get the watcher analyser class to access the 
emitter.. I think this is where the logic should go, because within 
"WatcherAnalyzer. analyzeIdentifierNode" we're getting the name as a string and 
creating the watcher object based on this string. So I want to do:
name = def.getBaseName();
if (def.isPrivate() && project.getAllowPrivateNameConflicts())
{
  name = 
getEmitter().formatPrivateName(def.getParent().getQualifiedName(), name);
}

My issue is that there's no access that I can see to the Emitter.

So I thought I'd ask:

  1.  does anyone know how I could actually get a valid reference to the 
emitter from this point in the code? i.e. just through the JSRoyaleProject 
object from what I can see..
  2.  or is there a better place where this should be? e.g. within getBaseName 
itself, or where the base name is set up on the definition..?
  3.  or could we move the "formatPrivateName" method to somewhere more 
accessible?
  4.  or can I just reproduce the "formatPrivateName" functionality here, and 
add comments so that future maintainers know to update two locations in case 
this changes?

The last option is simplest but very hacky.. but would appreciate thoughts on 
the best approach.


thanks

   Andrew

RE: Binding to private variables

[Frost, Andrew]

ecause the transpiler's AST walk (that uses the Emitters to generate
> the
> >>> JS) does not have the smarts for semantic analysis and similar things
> like
> >>> binding and watcher analysis.
> >>>
> >>> The clue to that is which Eclipse projects or jars the various source
> >>> files belong to.  We will try not to introduce any files from the
> >>> compiler-jx project/jar into the compiler and compiler-common
> >>> project/jars.  Doing so could create build order/dependency issues.
> And
> >>> thus, we don't want to access the Emitters from the WatcherAnalyzer,
> nor
> >>> have the WatcherAnalyzer know that it is talking to a RoyaleJSProject
> >>> instead of a RoyaleProject (the latter which is designed for SWF
> output).
> >>>
> >>> And, even if you did find a way to access the Emitter, I think the 
same
> >>> Watcher database is used for SWF output as well, so you don't always
> want
> >>> to decorate the name of private variables in the data structure.
> >>>
> >>> After a quick think, I would suggest doing a bit more digging.  I
> noticed
> >>> that in the snippet you posted, a getter function appeared to be
> correctly
> >>> generated.  Is that part of the Watcher data or the Binding data?  In
> the
> >>> ActionScript code (DataBindingBase and subclasses) the Binding data is
> >>> supposed to discriminate between "simple" property chains that it can
> >>> create more efficient Bindings for vs GenericBinding that can handle
> more
> >>> complex cases.  The idea is that in some cases, we can't just access
> the
> >>> value by an instance.propName lookup and a getterFunction is generated
> >>> instead.   This is absolutely required in SWF code since external
> classes
> >>> like the Binding classes can't access private members of the class it
> is
> >>> watching.  It has always felt like a "cheat" to me that Binding pokes
> holes
> >>> in the private access protection for Bindings, but that's pretty much
> the
> >>> only way we can do it in SWF code (which also sort of means you lose
> the
> >>> advantage of binding to private variables in the first place).  In
> fact, I
> >>> think one of the optimizations for Royale binding will be that 
bindings
> >>> will be faster/smaller on public variables than private variables.
> >>>
> >>> So, having said all that, one possible solution is to have the
> >>> ActionScript code use the getter function instead of the propertyName
> for
> >>> private variables.  I thought that the transpiler did not always
> output a
> >>> getter function if public property chains could access the value.  The
> AS
> >>> code could then know to use a function instead of the property name.
> If
> >>> some future version of JS actually does provide private access
> protection
> >>> someday, we'll be glad we did this.  Right now, the Royale JS binding
> code
> >>> has been relying on direct access to private variables, which is also 
a
> >>> "cheat", IMO.
> >>>
> >>> Another possible approach is to change what is stored in the Watcher
> >>> database.  Add new fields to store the fact that the property is
> private.
> >>> Then in MXMLRoyaleEmitter, the watcher output code should have access
> to an
> >>> emitter, and there is no need to access compiler-jx classes from the
> >>> WatcherAnalyzer.  This approach (just adding more info in the shared
> >>> Analyzer code instead of generating code) is probably more
> >>> platform/output-independent.
> >>>
> >>> Or maybe you'll need both.
> >>>
> >>> Hope that made sense.  Good luck,
> >>> -Alex
> >>>
> >>>
> >>> On 12/6/18, 6:30 AM, "Frost, Andrew"  wrote:
> >>>
> >>>Hi all
> >>>
> >>>I found recently that binding had stopped working when we were 
using
> >>> private variables, for example:
> >>&

RE: ROYALE_CLASS_INFO, renaming, modules, Objects

[Frost, Andrew]

Hi

Not sure that I fully understand this but would a valid compromise be something 
where the field name isn't renamed at all automatically, but we just change it 
in the JS generation code to be "i" rather than "interfaces", and update the 
Language is/as functions to work with this property name? Not sure whether it 
would work and I don't know whether the Reflection stuff would then need to 
change too, but if this is all in the generated outputs and/or the framework's 
own code then it shouldn't be something that the end user would bother about..

thanks

   Andrew


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 11 December 2018 08:32
To: dev@royale.apache.org
Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects

I spent some time today trying to get Tour De Flex to run in production mode 
with the main app and modules being separately minified.

I've fixed a few things here and there, but an interesting issue I ran into has 
to do with the plain object we use in ROYALE_CLASS_INFO (and will apply to 
other objects).

The ROYALE_CLASS_INFO is generated on each class and has a "names" property and 
an optional "interfaces" property.  An example is:

org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { 
names: [{ name: 'PanelModel', qName: 
'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: 
[org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };

Because the field names are not quoted, then in most output, the field name 
"interfaces" is renamed and all code referencing this field is renamed as well. 
 This is good because it means that you don't have to download the word 
"interfaces" once per-class. Instead of 10 characters, it is usually one or 
two.  100 classes saves you about 900 bytes.

However, it turns out that in Tour De Flex, the main app uses Reflection and 
Reflection uses a quoted 'interfaces' string and thus, the field name 
'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules 
"interfaces" is renamed since no other code in the module has a quoted string 
for 'interfaces'.  But that means that when a module loads, the Language.is/as 
won't work since classes in the main app are using "interfaces" but the classes 
in the module are using some short name.

One solution is to always quote that field in the compiler output and Language 
is/as so it doesn't get renamed, but that means that field will never get 
renamed and you lose saving those bytes.

Another is let folks figure out their own workarounds, by adding some code that 
will prevent the renaming in the modules.

Other ideas are welcome.  I'm done for tonight.

Thoughts?
-Alex

RE: ROYALE_CLASS_INFO, renaming, modules, Objects

[Frost, Andrew]

 based on other 
code in the compile.  So if you just have:
>> 
>> Var obj:Object = { harbs: 1};
>> Public static function foo()
>> {
>>  Trace(obj.harbs);
>> }
>> 
>> Use of foo() in one compile may result in harbs being renamed, and 
another wouldn't.  And that poses a problem when data structures are shared 
between compiled outputs.
>> 
>> This is a natural way to write AS, but the JS results when minified and 
shared between app and modules can fail.  So what restrictions should we place 
if any on how folks use plain objects?
>> 
>> HTH,
>> -Alex
>> 
>> On 12/11/18, 7:36 AM, "Harbs"  wrote:
>> 
>>   I was about to make the same suggestion. We can use “I” for 
interfaces, “c” for class, “k” for kind, “n” for names. etc.
>> 
>>> On Dec 11, 2018, at 2:52 PM, Frost, Andrew  
wrote:
>>> 
>>> Hi
>>> 
>>> Not sure that I fully understand this but would a valid compromise be 
something where the field name isn't renamed at all automatically, but we just 
change it in the JS generation code to be "i" rather than "interfaces", and 
update the Language is/as functions to work with this property name? Not sure 
whether it would work and I don't know whether the Reflection stuff would then 
need to change too, but if this is all in the generated outputs and/or the 
framework's own code then it shouldn't be something that the end user would 
bother about..
>>> 
>>> thanks
>>> 
>>> Andrew
>>> 
>>> 
>>> -Original Message-
>>> From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
>>> Sent: 11 December 2018 08:32
>>> To: dev@royale.apache.org
>>> Subject: [EXTERNAL] ROYALE_CLASS_INFO, renaming, modules, Objects
>>> 
>>> I spent some time today trying to get Tour De Flex to run in production 
mode with the main app and modules being separately minified.
>>> 
>>> I've fixed a few things here and there, but an interesting issue I ran 
into has to do with the plain object we use in ROYALE_CLASS_INFO (and will 
apply to other objects).
>>> 
>>> The ROYALE_CLASS_INFO is generated on each class and has a "names" 
property and an optional "interfaces" property.  An example is:
>>> 
>>> 
org.apache.royale.html.beads.models.PanelModel.prototype.ROYALE_CLASS_INFO = { 
names: [{ name: 'PanelModel', qName: 
'org.apache.royale.html.beads.models.PanelModel', kind: 'class' }], interfaces: 
[org.apache.royale.core.IBead, org.apache.royale.core.IPanelModel] };
>>> 
>>> Because the field names are not quoted, then in most output, the field 
name "interfaces" is renamed and all code referencing this field is renamed as 
well.  This is good because it means that you don't have to download the word 
"interfaces" once per-class. Instead of 10 characters, it is usually one or 
two.  100 classes saves you about 900 bytes.
>>> 
>>> However, it turns out that in Tour De Flex, the main app uses 
Reflection and Reflection uses a quoted 'interfaces' string and thus, the field 
name 'interfaces' in ROYALE_CLASS_INFO isn't renamed, but in most modules 
"interfaces" is renamed since no other code in the module has a quoted string 
for 'interfaces'.  But that means that when a module loads, the Language.is/as 
won't work since classes in the main app are using "interfaces" but the classes 
in the module are using some short name.
>>> 
>>> One solution is to always quote that field in the compiler output and 
Language is/as so it doesn't get renamed, but that means that field will never 
get renamed and you lose saving those bytes.
>>> 
>>> Another is let folks figure out their own workarounds, by adding some 
code that will prevent the renaming in the modules.
>>> 
>>> Other ideas are welcome.  I'm done for tonight.
>>> 
>>> Thoughts?
>>> -Alex
>>> 
>> 
>> 
>> 
> 
> 
> 

Support for XML embedded via 'source' attribute

[Frost, Andrew]

Hi all

Am I missing something, or do we not yet have support for something like:
  

This is creating an XML object with ID 'myXML' but then not picking up and 
initialising it with the contents of that source file..

If this isn't implemented yet, then what would people think is the best way to 
do it: should we try to dynamically fetch the XML file at runtime? or should we 
build the XML into the JavaScript initialisation somehow?

thanks

   Andrew

Re: Support for XML embedded via 'source' attribute

[Frost, Andrew]

Hi

The only slight issue with that approach might be the asynchronous nature.. in 
the Flex world, if we embed something in this way, it's packaged into the SWF 
and available immediately, and set up during an object's initialisation prior 
to the "applicationComplete" event. If we do an async load via http, then we're 
perhaps likely to hit "applicationComplete" prior to loading it all? (Or maybe 
not, I'll have to look at how that works! I'm guessing we should be waiting for 
a browser's 'document complete' event before we kick off our initialisation?).

My only other thought on the approach to embed this into the initial JS/HTML 
file means we would need to update the compiler..

No console output is happening, but when I add breakpoints and trace what's 
happening, the XML element is being initialised as an empty object, the 
contents of the 'source' property are ignored and the source isn't found in the 
generated JS code at all.

thanks

   Andrew
 

-Original Message-
From: Piotr Zarzycki  
Sent: 09 July 2019 15:00
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Support for XML embedded via 'source' attribute

Hi Andrew,

To me if it is possible it should be a bead which is able to load external file 
and inject to source.

Do you get any kind of console output in the browser ? What will happen if you 
set full path to source property to that XML file ?

Thanks,
Piotr

wt., 9 lip 2019 o 15:52 Frost, Andrew  napisał(a):

> Hi all
>
> Am I missing something, or do we not yet have support for something like:
>   
>
> This is creating an XML object with ID 'myXML' but then not picking up 
> and initialising it with the contents of that source file..
>
> If this isn't implemented yet, then what would people think is the 
> best way to do it: should we try to dynamically fetch the XML file at runtime?
> or should we build the XML into the JavaScript initialisation somehow?
>
> thanks
>
>Andrew
>
>
>
>

-- 

Piotr Zarzycki

Patreon: 
*https://clicktime.symantec.com/32MPrsdnaA1JPJeYg4FTB6a7Vc?u=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki
<https://clicktime.symantec.com/32MPrsdnaA1JPJeYg4FTB6a7Vc?u=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki>*

RE: Support for XML embedded via 'source' attribute

[Frost, Andrew]

Thanks - that looks good! I'll have a quick play with that set-up...

many thanks

   Andrew


-Original Message-
From: Yishay Weiss  
Sent: 09 July 2019 15:10
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Support for XML embedded via 'source' attribute

Hi Andrew,



There's an example [1] here.



[1] 
https://clicktime.symantec.com/379cRpDi3zzisR6EiMpKn9v7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fexamples%2Fmxroyale%2Ftourdeflexmodules%2Fsrc%2Fexplorer.mxml



________
From: Frost, Andrew 
Sent: Tuesday, July 9, 2019 4:52:36 PM
To: dev@royale.apache.org
Subject: Support for XML embedded via 'source' attribute

Hi all

Am I missing something, or do we not yet have support for something like:
  

This is creating an XML object with ID 'myXML' but then not picking up and 
initialising it with the contents of that source file..

If this isn't implemented yet, then what would people think is the best way to 
do it: should we try to dynamically fetch the XML file at runtime? or should we 
build the XML into the JavaScript initialisation somehow?

thanks

   Andrew

RE: Support for XML embedded via 'source' attribute

[Frost, Andrew]

Hi

Okay [2] is exactly what we had, but I've just realised we didn't have this in 
a  section, which is presumably why the compiler had ignored 
it! So add this, and suddenly I get the XML object being initialised with the 
XML file being embedded into the main .js file.

Interesting difference between options 1 and 2 is that the foreign-language 
characters in the XML are only rendered properly with the second option i.e. 
embedding an fx:XML object within the fx:Declarations. I'm guessing this to do 
with the "text/plain" MIME type, but am not sure what it should be for utf-8...?

Anyway, thanks, I'm happy with this working as intended, with just the 
embarrassment of having not spotted the lack of the  section!

cheers

   Andrew


-Original Message-
From: Yishay Weiss  
Sent: 09 July 2019 15:17
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Support for XML embedded via 'source' attribute

Maybe this [2] is closer to what you want.



I've tested [1] but not [2]. According to [2] your syntax was ok, so maybe post 
a test case demonstrating your problem.



[2] 
https://clicktime.symantec.com/3L3qfBwHuGUUvLznrv57UZx7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fexamples%2Fmxroyale%2Ftourdeflexmodules%2Fsrc%2Fspark%2Fcontrols%2FTextLayout3Example.mxml




From: Yishay Weiss 
Sent: Tuesday, July 9, 2019 5:10:27 PM
To: dev@royale.apache.org
Subject: RE: Support for XML embedded via 'source' attribute

Hi Andrew,



There's an example [1] here.



[1] 
https://clicktime.symantec.com/3KaAnp9RJNu19m4mXKhSNbm7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fexamples%2Fmxroyale%2Ftourdeflexmodules%2Fsrc%2Fexplorer.mxml




From: Frost, Andrew 
Sent: Tuesday, July 9, 2019 4:52:36 PM
To: dev@royale.apache.org
Subject: Support for XML embedded via 'source' attribute

Hi all

Am I missing something, or do we not yet have support for something like:
  

This is creating an XML object with ID 'myXML' but then not picking up and 
initialising it with the contents of that source file..

If this isn't implemented yet, then what would people think is the best way to 
do it: should we try to dynamically fetch the XML file at runtime? or should we 
build the XML into the JavaScript initialisation somehow?

thanks

   Andrew

RE: Support for XML embedded via 'source' attribute

[Frost, Andrew]

I did earlier! but just checked, and no I don't. Time to add that to the system 
environment variables I think..  that might make the difference I guess; but 
for now the fx:XML insertion is working well..

thanks


-Original Message-
From: Alex Harui  
Sent: 09 July 2019 16:58
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Support for XML embedded via 'source' attribute

Are you using Windows?  Do you have the JAVA_TOOL_OPTIONS set for utf8?  I 
think some parts of the compiler may open a file expecting utf8 and other parts 
just take whatever the JRE gives it.

HTH,
-Alex

On 7/9/19, 7:31 AM, "Frost, Andrew"  wrote:

Hi

Okay [2] is exactly what we had, but I've just realised we didn't have this 
in a  section, which is presumably why the compiler had 
ignored it! So add this, and suddenly I get the XML object being initialised 
with the XML file being embedded into the main .js file.

Interesting difference between options 1 and 2 is that the foreign-language 
characters in the XML are only rendered properly with the second option i.e. 
embedding an fx:XML object within the fx:Declarations. I'm guessing this to do 
with the "text/plain" MIME type, but am not sure what it should be for utf-8...?

Anyway, thanks, I'm happy with this working as intended, with just the 
embarrassment of having not spotted the lack of the  section!

cheers

   Andrew


-Original Message-
From: Yishay Weiss  
Sent: 09 July 2019 15:17
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Support for XML embedded via 'source' attribute

Maybe this [2] is closer to what you want.



I've tested [1] but not [2]. According to [2] your syntax was ok, so maybe 
post a test case demonstrating your problem.



[2] 
https://clicktime.symantec.com/3PA7aYXBxRYfGtmFGZrpHSG7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Froyale-asjs%252Fblob%252Fdevelop%252Fexamples%252Fmxroyale%252Ftourdeflexmodules%252Fsrc%252Fspark%252Fcontrols%252FTextLayout3Example.mxml%26data%3D02%257C01%257Caharui%2540adobe.com%257C620cbae1c55e435b04bb08d7047a0b0b%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C1%257C636982794528719536%26sdata%3DVHZQCfkzFklMLMeTYIN%252FkhoyKaz60mEnpMsbTGmKAQ4%253D%26reserved%3D0




From: Yishay Weiss 
Sent: Tuesday, July 9, 2019 5:10:27 PM
To: dev@royale.apache.org
Subject: RE: Support for XML embedded via 'source' attribute

Hi Andrew,



There's an example [1] here.



[1] 
https://clicktime.symantec.com/3Y7SkRdjpgov8nE4XY6ksGN7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Froyale-asjs%252Fblob%252Fdevelop%252Fexamples%252Fmxroyale%252Ftourdeflexmodules%252Fsrc%252Fexplorer.mxml%26data%3D02%257C01%257Caharui%2540adobe.com%257C620cbae1c55e435b04bb08d7047a0b0b%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C1%257C636982794528719536%26sdata%3DvUnn28GvtdfNtcBkMUWYn8M724iSDZ9USzI2LIiV58I%253D%26reserved%3D0




From: Frost, Andrew 
Sent: Tuesday, July 9, 2019 4:52:36 PM
To: dev@royale.apache.org
Subject: Support for XML embedded via 'source' attribute

Hi all

Am I missing something, or do we not yet have support for something like:
  

This is creating an XML object with ID 'myXML' but then not picking up and 
initialising it with the contents of that source file..

If this isn't implemented yet, then what would people think is the best way 
to do it: should we try to dynamically fetch the XML file at runtime? or should 
we build the XML into the JavaScript initialisation somehow?

thanks

   Andrew

AMF and class aliases

[Frost, Andrew]

Hi all

We're trying to get a connection to work from our Royale-based code to a 
LiveCycle back-end, and having to debug why the AMF message is different 
between the Flex version and the Royale version (and trying to work out why the 
server is rejecting our initial ping message..)

One thing that's cropped up is that Flex embeds the name of the class - or 
rather, the alias of this - when it writes the object:
[RemoteClass(alias="flex.messaging.messages.CommandMessage")]

In Royale, this capability exists in the AMFBinaryData.writeObjectVariant() 
method where it's using the "localTraits", and we have:
var alias:String = classInfo.alias;// getAliasByClass(instance.constructor as 
Class); //<- @todo possible optimization: registerClassAlias implementation 
stores in the classInfo Object, access directly

The commented-out code does exactly what the new code does, which is that it 
accesses the ROYALE_CLASS_INFO structure:
var classInfo:Object = 
instance.ROYALE_CLASS_INFO;
so to make this work, we've added an extra section at the end of the 
ROYALE_CLASS_INFO for the CommandMessage (in the generated JavaScript, so this 
is not a proper solution!):

mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = { names: [{ 
name: 'CommandMessage', qName: 'mx.messaging.messages.CommandMessage', kind: 
'class' }] , alias: 'flex.messaging.messages.CommandMessage' };


Interestingly, the compiler looks at all the [RemoteClass(alias="")] tags, and 
outputs a list of these in the main application's .js file:
TestBackend.prototype.info = function() {
  return { "mixins": [mx.messaging.config.LoaderConfig, 
mx.styles.StyleManagerImpl],
"remoteClassAliases": {"mx.messaging.messages.CommandMessage": 
"flex.messaging.messages.CommandMessage", 
"org.apache.royale.net.remoting.messages.ActionMessage": 
"flex.messaging.io.amf.ActionMessage", ... etc },
"compiledLocales": ["en_US"]}};

but I can't see anywhere that this list is accessed/used.


So it looks to me like there's a discrepancy between how the compiler is trying 
to make this work, and how the framework is expecting it to be set up by the 
compiler. I was wondering if anyone know what had been going on here and 
whether we should go for one way or another .. and by preference I think, 
getting the compiler to add the alias directly into the ROYALE_CLASS_INFO as 
that seems to be a better way of doing it I think..?


thanks

   Andrew

p.s. we've had a few other issues with the AMF format, e.g. using 'unknown 
length' and having this as +1 rather than -1; plus a single message was being 
packaged as an array, whereas Flex/Flash Player doesn't do that.. I'm wondering 
whether anyone has a problem if we try to make the AMF messages generated from 
a Royale app to be as similar as possible to how the Flash Player does it..?!

Re: AMF and class aliases

[Frost, Andrew]

Oh it's that simple!

Yes I just took a look, that does appear to go through it all and set 
everything up...

Thank you!  that saved us a bit of effort trying to update the compiler ;-)




-Original Message-
From: Greg Dove  
Sent: 11 July 2019 23:27
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Hi Andrew,
'but I can't see anywhere that this list is accessed/used.'

I think you need ClassAliasBead on your Application level, which will process 
all the definitions.






On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew 
wrote:

> Hi all
>
> We're trying to get a connection to work from our Royale-based code to 
> a LiveCycle back-end, and having to debug why the AMF message is 
> different between the Flex version and the Royale version (and trying 
> to work out why the server is rejecting our initial ping message..)
>
> One thing that's cropped up is that Flex embeds the name of the class 
> - or rather, the alias of this - when it writes the object:
> [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
>
> In Royale, this capability exists in the
> AMFBinaryData.writeObjectVariant() method where it's using the 
> "localTraits", and we have:
> var alias:String = classInfo.alias;// 
> getAliasByClass(instance.constructor
> as Class); //<- @todo possible optimization: registerClassAlias 
> implementation stores in the classInfo Object, access directly
>
> The commented-out code does exactly what the new code does, which is 
> that it accesses the ROYALE_CLASS_INFO structure:
> var classInfo:Object = 
> instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra 
> section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in 
> the generated JavaScript, so this is not a proper solution!):
>
> mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> names: [{ name: 'CommandMessage', qName:
> 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> 'flex.messaging.messages.CommandMessage' };
>
>
> Interestingly, the compiler looks at all the [RemoteClass(alias="")] 
> tags, and outputs a list of these in the main application's .js file:
> TestBackend.prototype.info = function() {
>   return { "mixins": [mx.messaging.config.LoaderConfig,
> mx.styles.StyleManagerImpl],
> "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> "flex.messaging.messages.CommandMessage", 
> "org.apache.royale.net.remoting.messages.ActionMessage":
> "flex.messaging.io.amf.ActionMessage", ... etc },
> "compiledLocales": ["en_US"]}};
>
> but I can't see anywhere that this list is accessed/used.
>
>
> So it looks to me like there's a discrepancy between how the compiler 
> is trying to make this work, and how the framework is expecting it to 
> be set up by the compiler. I was wondering if anyone know what had 
> been going on here and whether we should go for one way or another .. 
> and by preference I think, getting the compiler to add the alias 
> directly into the ROYALE_CLASS_INFO as that seems to be a better way of doing 
> it I think..?
>
>
> thanks
>
>Andrew
>
> p.s. we've had a few other issues with the AMF format, e.g. using 
> 'unknown length' and having this as +1 rather than -1; plus a single 
> message was being packaged as an array, whereas Flex/Flash Player 
> doesn't do that.. I'm wondering whether anyone has a problem if we try 
> to make the AMF messages generated from a Royale app to be as similar 
> as possible to how the Flash Player does it..?!
>
>

Re: AMF and class aliases

[Frost, Andrew]

Thanks

Yes, binding is one that we're definitely also having some fun with. Wrote our 
own little binding bead for now but at some point I'll get round to looking in 
depth to see if there's a way of doing this using the 'proper' beads. In case 
you're that interested: it's for localisation where we have an object assigned 
to the class and when a property of the object is updated, it fires a "changed" 
event which we need to listen out for and then re-load in all the bound 
details, which are function calls with parameters i.e. 
this.localised.getString('id'). Tried a couple of binding beads and 
investigated what was happening, they were able to detect when the 'localised' 
variable was being changed i.e. a new one being added to 'this', but that's not 
what we're looking for. I think the use of the basic "changed" event rather 
than "ValueChangedEvent" might be confusing it..

Anyway. Getting there. There is a response coming from the server now although 
I'm not sure whether this is then getting handled properly and what the next 
event is that's going out to the server, it's not working fully yet. Trying to 
remotely debug without any access to this myself :-(


thanks

   Andrew



-Original Message-
From: Carlos Rovira  
Sent: 12 July 2019 11:45
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Yeah! we are in production with AMF for around 4 months without any issue!
So RO works great for Royale ;)

this kind of problems where something is not working and is about a missed bead 
are very typical to Royale.
Is the same with binding, statesbut our brains ends taking that into 
account and soon you'll get to that process ;)

Best

Carlos



El vie., 12 jul. 2019 a las 0:38, Greg Dove ()
escribió:

> Yes, it should just work. There is at least one working example in the 
> examples set, and it should work with CommandMessage etc, without any 
> of the tweaks that you mentioned.
>
> Carlos is using amf extensively and it is currently in use in a 
> production app.
>
> Let me know if you see any bugs.
>
> cheers,
> Greg
>
>
>
> On Fri, Jul 12, 2019 at 10:31 AM Frost, Andrew 
> 
> wrote:
>
> > Oh it's that simple!
> >
> > Yes I just took a look, that does appear to go through it all and 
> > set everything up...
> >
> > Thank you!  that saved us a bit of effort trying to update the 
> > compiler
> ;-)
> >
> >
> >
> >
> > -Original Message-
> > From: Greg Dove 
> > Sent: 11 July 2019 23:27
> > To: dev@royale.apache.org
> > Subject: [EXTERNAL] Re: AMF and class aliases
> >
> > Hi Andrew,
> > 'but I can't see anywhere that this list is accessed/used.'
> >
> > I think you need ClassAliasBead on your Application level, which 
> > will process all the definitions.
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew 
> > 
> > wrote:
> >
> > > Hi all
> > >
> > > We're trying to get a connection to work from our Royale-based 
> > > code to a LiveCycle back-end, and having to debug why the AMF 
> > > message is different between the Flex version and the Royale 
> > > version (and trying to work out why the server is rejecting our 
> > > initial ping message..)
> > >
> > > One thing that's cropped up is that Flex embeds the name of the 
> > > class
> > > - or rather, the alias of this - when it writes the object:
> > > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> > >
> > > In Royale, this capability exists in the
> > > AMFBinaryData.writeObjectVariant() method where it's using the 
> > > "localTraits", and we have:
> > > var alias:String = classInfo.alias;// 
> > > getAliasByClass(instance.constructor
> > > as Class); //<- @todo possible optimization: registerClassAlias 
> > > implementation stores in the classInfo Object, access directly
> > >
> > > The commented-out code does exactly what the new code does, which 
> > > is that it accesses the ROYALE_CLASS_INFO structure:
> > > var classInfo:Object = 
> > > instance.ROYALE_CLASS_INFO; so to make this work, we've added an 
> > > extra section at the end of the ROYALE_CLASS_INFO for the 
> > > CommandMessage (in the generated JavaScript, so this is not a proper 
> > > solution!):
> > >
> > > mx.messaging.messages.CommandM

RE: AMF and class aliases

[Frost, Andrew]

Hi

A custom bead for localization is a very good idea, yes. In this instance, 
we're looking at a migration from Flex so trying to keep as much of the 
original code the same as possible; with a custom (albeit generic) bead we've 
managed to do this. Not sure whether their code was the most efficient form 
when looked at from a Flex perspective either..

In terms of the AMF stuff, we've found a few more gotchas:
- not 100% sure if these are necessary, but we had been just setting the 
endpoint manually so that the connection could be made, but we also need to 
have the 'destination' value set on the RemoteObject, and possibly the ID as 
well. In Flex, it was only the 'destination' being set up, and the framework 
then went and got the ID and the endpoint from the configuration file... we 
might look into adding support for that services configuration file (in some 
form) to make this process a little simpler.
- the AMF serialization for classes is taking their public properties. We had 
removed the public properties and changed them into private properties plus 
public get functions, in order to avoid the warning from the Google Closure 
Compiler, but the serializer is only looking at traditional properties rather 
than at accessors. Not sure whether this is something that we should consider 
changing in the future within the framework..?

Will see whether this all works now..!

thanks

Andrew


-Original Message-
From: Alex Harui  
Sent: 15 July 2019 05:39
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

IMO, localization may perform better with a custom bead or two.  Generic 
binding must watch something for changes that might require that getString() be 
called again, but in general, either bindings to locales are set up early (so 
no change watcher is needed at all), or because of PAYG, you should pay more to 
watch something like the locale changing.  But a custom binding bead could know 
to watch whatever you are using to load localized strings instead of using the 
generic watching rules.

HTH,
-Alex

On 7/12/19, 9:12 AM, "Frost, Andrew"  wrote:

Thanks

Yes, binding is one that we're definitely also having some fun with. Wrote 
our own little binding bead for now but at some point I'll get round to looking 
in depth to see if there's a way of doing this using the 'proper' beads. In 
case you're that interested: it's for localisation where we have an object 
assigned to the class and when a property of the object is updated, it fires a 
"changed" event which we need to listen out for and then re-load in all the 
bound details, which are function calls with parameters i.e. 
this.localised.getString('id'). Tried a couple of binding beads and 
investigated what was happening, they were able to detect when the 'localised' 
variable was being changed i.e. a new one being added to 'this', but that's not 
what we're looking for. I think the use of the basic "changed" event rather 
than "ValueChangedEvent" might be confusing it..

Anyway. Getting there. There is a response coming from the server now 
although I'm not sure whether this is then getting handled properly and what 
the next event is that's going out to the server, it's not working fully yet. 
Trying to remotely debug without any access to this myself :-(


thanks

   Andrew



-Original Message-
From: Carlos Rovira  
Sent: 12 July 2019 11:45
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Yeah! we are in production with AMF for around 4 months without any issue!
So RO works great for Royale ;)

this kind of problems where something is not working and is about a missed 
bead are very typical to Royale.
Is the same with binding, statesbut our brains ends taking that into 
account and soon you'll get to that process ;)

Best

Carlos



El vie., 12 jul. 2019 a las 0:38, Greg Dove ()
escribió:

> Yes, it should just work. There is at least one working example in the 
> examples set, and it should work with CommandMessage etc, without any 
> of the tweaks that you mentioned.
>
> Carlos is using amf extensively and it is currently in use in a 
> production app.
>
> Let me know if you see any bugs.
>
> cheers,
> Greg
>
>
>
> On Fri, Jul 12, 2019 at 10:31 AM Frost, Andrew 
> 
> wrote:
>
> > Oh it's that simple!
> >
> > Yes I just took a look, that does appear to go through it all and 
> > set everything up...
> >
> > Thank you!  that saved us a bit of effort trying to update the 

Re: AMF and class aliases

[Frost, Andrew]

Thanks Carlos & Greg, we'll take a look..


-Original Message-
From: Greg Dove  
Sent: 15 July 2019 21:40
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Also, before I forget:

If your legacy flex app includes [Transient] metadata anywhere, don't forget to 
include that in the keep-as3-metadata as part of the configuration for your 
royale app version as well.
AMFBinaryData will ignore those members with Transient metadata in the amf 
serialization, as it does for ByteArray in swf.



On Tue, Jul 16, 2019 at 8:25 AM Greg Dove  wrote:

> Hi Andrew, to answer specifically about:
> > - the AMF serialization for classes is taking their public 
> > properties. We had removed the public properties and changed them 
> > into private
> properties
> > plus public get functions, in order to avoid the warning from the 
> > Google Closure Compiler, but the serializer is only looking at 
> > traditional properties rather than at accessors. Not sure whether 
> > this is something that we should consider changing in the future within the 
> > framework..?
>
> It sounds to me like the issue here is that you are only creating 
> public getters. This won't work (in swf or javascript) because AMF 
> serialization requires matching public getter/setter pairs for the 
> member to be included in the serialized amf representation of the class 
> instance.
>
> You have a few options here:
> 1. If you are confident of the use of the (presumably VO ?) classes 
> everywhere, you can suppress those warnings [1] (feel free to improve 
> that documentation if you want, as it is preliminary) 2. If you want 
> bindable classes, the easiest thing is to mark the class with 
> [Bindable] metadata (note that this is 'easy' but because of the 
> bindable support will create more code, and run slightly slower than 
> (3) below.
> 3. You can manually create getter/setter support for each of the 
> public vars.
>
> As another thing, if you ever want to test amf serialization, you can 
> do that in the same way you do things with ByteArray in swf.
> var ba:AMFBinaryData = new AMFBinaryData(); var instance:Object = {}; 
> // try other things here, myVO etc ) trace(instance); // inspect in 
> browser console ba.writeObject(instance); ba.position = 0; instance = 
> ba.readObject(); trace(instance); // inspect in browser console  The 
> above should perform the same type of deep-clone that you get when you 
> do it in swf (so long as all the class aliases are defined for the 
> instance's object tree when it is not a plain 'Object' like above)
>
> 1.
> https://clicktime.symantec.com/32sUM74kfapE27MaABaGjUj7Vc?u=https%3A%2
> F%2Fapache.github.io%2Froyale-docs%2Fcreate-an-application%2Foptimizat
> ions%2Fdoc-comment-directives.html%23royalesuppresspublicvarwarning
>
> On Tue, Jul 16, 2019 at 2:45 AM Carlos Rovira 
> 
> wrote:
>
>> Hi Andrew,
>>
>> El lun., 15 jul. 2019 a las 16:18, Frost, Andrew (<
>> andrew.fr...@harman.com>)
>> escribió:
>>
>> > Hi
>> >
>> > A custom bead for localization is a very good idea, yes. In this
>> instance,
>> > we're looking at a migration from Flex so trying to keep as much of 
>> > the original code the same as possible; with a custom (albeit 
>> > generic) bead we've managed to do this. Not sure whether their code 
>> > was the most efficient form when looked at from a Flex perspective either..
>> >
>>
>> in jewel we are using Localization in Validator.as (through core
>> ILocalizedValuesImpl)
>> but the plan is remove that in the future since Alex pointed that we 
>> should not use localization in that way. In the future, validation 
>> should separate logic from view so the validation logic should check 
>> the VO, DTOs, Pojos...
>> objects while the visuals could be changed from tooltips to static 
>> labels or whatever the user wants to inject. And the same way for 
>> localizations
>>
>>
>> > In terms of the AMF stuff, we've found a few more gotchas:
>> > - not 100% sure if these are necessary, but we had been just 
>> > setting the endpoint manually so that the connection could be made, 
>> > but we also
>> need to
>> > have the 'destination' value set on the RemoteObject, and possibly 
>> > the
>> ID
>> > as well. In Flex, it was only the 'destination' being set up, and 
>> > the framework then went and got the ID and the endpoint from the
>> configuration
>> > file... we might look into adding support for that services
>> configuration
&g

Re: AMF and class aliases

[Frost, Andrew]

Hi again

One extra question here: we have the AMF connection working fine now in Debug 
mode, but in Release mode the minifier is changing the property names of our 
JavaScript (compiled from ActionScript), but these are not being reflected in 
the objects that are deserialised.

So for example, we are receiving an ArrayCollection, and accessing one 
element's property directly e.g.:
var results : ArrayCollection = resultEvt.result as ArrayCollection;
for (var i : uint = 0; i < results.length; i++)
{
  var resultCode : String = results[i].outputArray.source[0].RESULT_CODE;
...

There are a couple of things going on:
(a) each element in the main ArrayCollection has an "outputArray" property 
which is itself an ArrayCollection. We could cast it into an ArrayCollection 
variable I guess, but instead have just added "source" so that the JavaScript 
doesn't try adding the [] operator to the ArrayCollection object directly...
(b) the contents of this ArrayCollection, in this particular case, is a simple 
object {RESULT_CODE: "OK"} - which I can see in the console when we add some 
trace. The js-debug file has the same structure as the ActionScript; but the 
js-release file has a mapping at the start "nc='RESULT_CODE'" and then accesses 
the data with " a.L(c).outputData.source[0].tP" (and that's even weirder as why 
is it 'tP' rather than 'nc'?!)


I guess the questions I have are:

1) Is there a way to prevent the Google closure compiler from minifying a 
particular property name/string?
or
2) Are we going to have to just declare classes for all of these and do a 
typecast e.g. along the lines of:
class ResultCode { [Bindable]public var RESULT_CODE; }
and then
var resultCodeObj : ResultCode = results[i].outputArray.source[0];
var resultCode : String = resultCodeObj.RESULT_CODE;


thanks

   Andrew


-Original Message-
From: Greg Dove  
Sent: 15 July 2019 21:40
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Also, before I forget:

If your legacy flex app includes [Transient] metadata anywhere, don't forget to 
include that in the keep-as3-metadata as part of the configuration for your 
royale app version as well.
AMFBinaryData will ignore those members with Transient metadata in the amf 
serialization, as it does for ByteArray in swf.



On Tue, Jul 16, 2019 at 8:25 AM Greg Dove  wrote:

> Hi Andrew, to answer specifically about:
> > - the AMF serialization for classes is taking their public 
> > properties. We had removed the public properties and changed them 
> > into private
> properties
> > plus public get functions, in order to avoid the warning from the 
> > Google Closure Compiler, but the serializer is only looking at 
> > traditional properties rather than at accessors. Not sure whether 
> > this is something that we should consider changing in the future within the 
> > framework..?
>
> It sounds to me like the issue here is that you are only creating 
> public getters. This won't work (in swf or javascript) because AMF 
> serialization requires matching public getter/setter pairs for the 
> member to be included in the serialized amf representation of the class 
> instance.
>
> You have a few options here:
> 1. If you are confident of the use of the (presumably VO ?) classes 
> everywhere, you can suppress those warnings [1] (feel free to improve 
> that documentation if you want, as it is preliminary) 2. If you want 
> bindable classes, the easiest thing is to mark the class with 
> [Bindable] metadata (note that this is 'easy' but because of the 
> bindable support will create more code, and run slightly slower than 
> (3) below.
> 3. You can manually create getter/setter support for each of the 
> public vars.
>
> As another thing, if you ever want to test amf serialization, you can 
> do that in the same way you do things with ByteArray in swf.
> var ba:AMFBinaryData = new AMFBinaryData(); var instance:Object = {}; 
> // try other things here, myVO etc ) trace(instance); // inspect in 
> browser console ba.writeObject(instance); ba.position = 0; instance = 
> ba.readObject(); trace(instance); // inspect in browser console  The 
> above should perform the same type of deep-clone that you get when you 
> do it in swf (so long as all the class aliases are defined for the 
> instance's object tree when it is not a plain 'Object' like above)
>
> 1.
> https://clicktime.symantec.com/32sUM74kfapE27MaABaGjUj7Vc?u=https%3A%2
> F%2Fapache.github.io%2Froyale-docs%2Fcreate-an-application%2Foptimizat
> ions%2Fdoc-comment-directives.html%23royalesuppresspublicvarwarning
>
> On Tue, Jul 16, 2019 at 2:45 AM Carlos Rovira 
> 
> wrote:
>
>> Hi Andrew,
>>
>> El lun., 

Re: AMF and class aliases

[Frost, Andrew]

Perfect, thanks! With a bit of a mixture of typing and then of using that 
format with the accessing, it worked.. I didn't want to have to create class 
definitions for all of these various options but just using the ["RESULT_CODE"] 
notification in ActionScript means that the generated (and minified) JavaScript 
creates it as .RESULT_CODE and this then works with the dynamically recreated 
data.

Thanks for the support, one step closer as now our release builds are picking 
up the database connection (makes our customer happier as they don't like the 
slow loading time for all the .js files in a debug build...)

cheers



-Original Message-
From: Carlos Rovira  
Sent: 22 July 2019 14:52
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Hi Andrew,

first of all if you are using ArrayCollection and not ArrayList you must 
configure that. In my code I'm using this to configure ArrayList as the type 
royale must use when send and receive java ArrayCollection:

registerClassAlias("flex.messaging.io.ArrayCollection", ArrayList);

(don't remember if Greg made it default to ArrayCollection)

about serialization/deserialization issues, maybe other could give you better 
clues than me, since all our objects are strongly typed so objects in 
collections are classes and if that classes has collections then the sub 
objects will be typed as well.

I found that when I have problems when something runs in debug mode but not in 
release mode for deserialization issues the object bracket access use to work 
always, so I think is what you need to do, so for example in you case I think 
this should work:

results[I]["outputArray"]["source"][0][RESULT_CODE]

HTH

Carlos

El lun., 22 jul. 2019 a las 11:17, Frost, Andrew ()
escribió:

> Hi again
>
> One extra question here: we have the AMF connection working fine now 
> in Debug mode, but in Release mode the minifier is changing the 
> property names of our JavaScript (compiled from ActionScript), but 
> these are not being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing one 
> element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection; 
> for (var i : uint = 0; i < results.length; i++) {
>   var resultCode : String = 
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray" 
> property which is itself an ArrayCollection. We could cast it into an 
> ArrayCollection variable I guess, but instead have just added "source" 
> so that the JavaScript doesn't try adding the [] operator to the 
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case, is 
> a simple object {RESULT_CODE: "OK"} - which I can see in the console 
> when we add some trace. The js-debug file has the same structure as 
> the ActionScript; but the js-release file has a mapping at the start 
> "nc='RESULT_CODE'" and then accesses the data with "
> a.L(c).outputData.source[0].tP" (and that's even weirder as why is it 'tP'
> rather than 'nc'?!)
>
>
> I guess the questions I have are:
>
> 1) Is there a way to prevent the Google closure compiler from 
> minifying a particular property name/string?
> or
> 2) Are we going to have to just declare classes for all of these and 
> do a typecast e.g. along the lines of:
> class ResultCode { [Bindable]public var RESULT_CODE; } and then var 
> resultCodeObj : ResultCode = results[i].outputArray.source[0]; var 
> resultCode : String = resultCodeObj.RESULT_CODE;
>
>
> thanks
>
>Andrew
>
>
> --
> Carlos Rovira
> https://clicktime.symantec.com/3R6MVFpF7GfH9MBneA8xfU97Vc?u=http%3A%2F
> %2Fabout.me%2Fcarlosrovira
>
>
>
>

ComboBox list-item renderer

[Frost, Andrew]

Hi again

Just in case someone's already done this and knows already how to set it up: we 
want to have an itemRenderer for the ListView part of a ComboBox control, i.e. 
when you click on the ComboBox button and it creates the ListView, we need a 
custom renderer. Currently it's defaulting to StringItemRenderer (from the call 
[1] within the default ItemRendererClassFactory), but we want it instead to use 
the inline MXML [2].

I'm hoping that we can set this up by adding a bead of some sort to the 
ComboBox element that will tell it what item renderer to use; all the item 
renderer examples I can find are just using a list view directly rather than 
being something that's set up via a ComboBox. So far we've created a custom 
View for the ComboBox and we are controlling the creation of the ListView, but 
this creation doesn't then set up any of the MXMLDescriptor values which are 
needed for this to work...

Hope that makes sense. Don't worry if not, we'll get to the bottom of it, but I 
wondered if someone already had done this and knew how to do it :-)

thanks

   Andrew



[1] Current way ItemRenderClassFactory selects the item renderer:
if (_strand is IItemRendererProvider && (_strand as 
IItemRendererProvider).itemRenderer) { ... }
else {
var itemRendererClass:Class = ValuesManager.valuesImpl.getValue(_strand, 
"iItemRenderer") as Class;  < we're getting StringItemRenderer here
if (itemRendererClass) { ... }
else if (!MXMLDescriptor) { ... }
<<< we want it to hit this point i.e. not get set up because it falls 
through and then uses the MXMLDescriptor value

[2] Our code:
  

 was "fx:Component"
 ... layout in here 
...  
  

  

Re: ComboBox list-item renderer

[Frost, Andrew]

Hi Carlos

I'd looked at your example, and it works fine when we're rendering a "List" 
control, but if you change your "j:List" into "j:ComboBox" then the renderer is 
no longer used...

Perhaps we need to set the renderer up on the list object that's generated 
manually .. but setting this via the "itemRenderer" property is what we'd tried 
and it didn't work, as the framework then seems to think that this is actually 
a factory object rather than a renderer (bearing in mind too that the MXML has 
already been parsed and so this 'property' is already set up as a hierarchy of 
display objects, rather than being a class that's used as the constructor for 
each renderer object..)

I'll see if I can develop the Tour de Jewel example to get that simpler case 
working first perhaps...

thanks

   Andrew


-Original Message-
From: Carlos Rovira  
Sent: 22 July 2019 16:32
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: ComboBox list-item renderer

Hi Andrew,

for this one in Royale it use to be done in CSS. For example in tour de jewel 
for List we do:

Source code in GitHub
<https://clicktime.symantec.com/35oKmCet9NJTZrZZRiqcmBC7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fexamples%2Froyale%2FTourDeJewel%2Fsrc%2Fmain%2Froyale%2FListPlayGround.mxml>



and in iconListItemRenderer you can find

.iconListItemRenderer
{
IItemRenderer: ClassReference("itemRenderers.IconListItemRenderer");
}

but as well we should can do as inline in MXML, so if that does not work it's a 
bug to solve I think...

HTH

Carlos


El lun., 22 jul. 2019 a las 17:14, Frost, Andrew ()
escribió:

> Hi again
>
> Just in case someone's already done this and knows already how to set 
> it
> up: we want to have an itemRenderer for the ListView part of a 
> ComboBox control, i.e. when you click on the ComboBox button and it 
> creates the ListView, we need a custom renderer. Currently it's 
> defaulting to StringItemRenderer (from the call [1] within the default 
> ItemRendererClassFactory), but we want it instead to use the inline 
> MXML [2].
>
> I'm hoping that we can set this up by adding a bead of some sort to 
> the ComboBox element that will tell it what item renderer to use; all 
> the item renderer examples I can find are just using a list view 
> directly rather than being something that's set up via a ComboBox. So 
> far we've created a custom View for the ComboBox and we are 
> controlling the creation of the ListView, but this creation doesn't 
> then set up any of the MXMLDescriptor values which are needed for this to 
> work...
>
> Hope that makes sense. Don't worry if not, we'll get to the bottom of 
> it, but I wondered if someone already had done this and knew how to do 
> it :-)
>
> thanks
>
>Andrew
>
>
>
> [1] Current way ItemRenderClassFactory selects the item renderer:
> if (_strand is IItemRendererProvider && (_strand as
> IItemRendererProvider).itemRenderer) { ... } else {
> var itemRendererClass:Class =
> ValuesManager.valuesImpl.getValue(_strand, "iItemRenderer") as Class; 
> <<<<< we're getting StringItemRenderer here
> if (itemRendererClass) { ... }
> else if (!MXMLDescriptor) { ... }
> <<< we want it to hit this point i.e. not get set up because it 
> falls through and then uses the MXMLDescriptor value
>
> [2] Our code:
>   
> 
> <<<< was "fx:Component"
>  ... layout 
> in here ...  
>   
> 
>   
>
>
>
>
>

--
Carlos Rovira
https://clicktime.symantec.com/3S223MPUyE5DVmaKDho7sg57Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira

RE: ComboBox list-item renderer

[Frost, Andrew]

Thanks - yes, happy to adjust our code to that sort of format, but we continue 
to hit the issue that this is a renderer for a list, being set on the list, and 
we want to have a renderer for the list that's being created at runtime from 
the combo box.

It might be that we can set the itemRenderer property of the list object as 
it's created by the combo box's view object, but this feels a little hacky and 
it would be nicer if we could accomplish this just via MXML or CSS..

cheers


-Original Message-
From: Yishay Weiss  
Sent: 22 July 2019 17:43
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: ComboBox list-item renderer

Another option is to specify the renderer class as an mxml att [1]. 
ItemRenderers are not beads, so adding them to the beads list has no effect (it 
should actually cause an RTE).



[1] 
https://clicktime.symantec.com/3L6uXLP6wp93RxE1KiZmGxT7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Ff637c857122d56f838bab21314a11900ed0add8e%2Fexamples%2Froyale%2FTodoListSampleApp%2Fsrc%2Fmain%2Froyale%2Fsample%2Ftodo%2Fviews%2FTodoListView.mxml%23L169




From: Carlos Rovira 
Sent: Monday, July 22, 2019 6:32:27 PM
To: dev@royale.apache.org 
Subject: Re: ComboBox list-item renderer

Hi Andrew,

for this one in Royale it use to be done in CSS. For example in tour de jewel 
for List we do:

Source code in GitHub
<https://clicktime.symantec.com/3FLJQLf6LAcXdburoPNGbpg7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fexamples%2Froyale%2FTourDeJewel%2Fsrc%2Fmain%2Froyale%2FListPlayGround.mxml>



and in iconListItemRenderer you can find

.iconListItemRenderer
{
IItemRenderer: ClassReference("itemRenderers.IconListItemRenderer");
}

but as well we should can do as inline in MXML, so if that does not work it's a 
bug to solve I think...

HTH

Carlos


El lun., 22 jul. 2019 a las 17:14, Frost, Andrew ()
escribió:

> Hi again
>
> Just in case someone's already done this and knows already how to set 
> it
> up: we want to have an itemRenderer for the ListView part of a 
> ComboBox control, i.e. when you click on the ComboBox button and it 
> creates the ListView, we need a custom renderer. Currently it's 
> defaulting to StringItemRenderer (from the call [1] within the default 
> ItemRendererClassFactory), but we want it instead to use the inline 
> MXML [2].
>
> I'm hoping that we can set this up by adding a bead of some sort to 
> the ComboBox element that will tell it what item renderer to use; all 
> the item renderer examples I can find are just using a list view 
> directly rather than being something that's set up via a ComboBox. So 
> far we've created a custom View for the ComboBox and we are 
> controlling the creation of the ListView, but this creation doesn't 
> then set up any of the MXMLDescriptor values which are needed for this to 
> work...
>
> Hope that makes sense. Don't worry if not, we'll get to the bottom of 
> it, but I wondered if someone already had done this and knew how to do 
> it :-)
>
> thanks
>
>Andrew
>
>
>
> [1] Current way ItemRenderClassFactory selects the item renderer:
> if (_strand is IItemRendererProvider && (_strand as
> IItemRendererProvider).itemRenderer) { ... } else {
> var itemRendererClass:Class =
> ValuesManager.valuesImpl.getValue(_strand, "iItemRenderer") as Class; 
> <<<<< we're getting StringItemRenderer here
> if (itemRendererClass) { ... }
> else if (!MXMLDescriptor) { ... }
> <<< we want it to hit this point i.e. not get set up because it 
> falls through and then uses the MXMLDescriptor value
>
> [2] Our code:
>   
> 
> <<<< was "fx:Component"
>  ... layout 
> in here ...  
>   
> 
>   
>
>
>
>
>

--
Carlos Rovira
https://clicktime.symantec.com/36TqgNnCHwLbyQEjPaEJeg57Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira

RE: ComboBox list-item renderer

[Frost, Andrew]

Thanks - yes we can try that, the issue being that we don't want all combo box 
lists to appear the same way hence trying to have something embedded into each 
bit of mxml...  



We'll take a proper look and see what we can get :-)

cheers


-Original Message-
From: Yishay Weiss  
Sent: 22 July 2019 18:17
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: ComboBox list-item renderer

Note that the overridden css is of ComboBoxList, which is by default the list 
created in runtime, not ComboBox, which is the button that creates the list.




From: Yishay Weiss 
Sent: Monday, July 22, 2019 8:13:31 PM
To: dev@royale.apache.org 
Subject: RE: ComboBox list-item renderer

Actually, have you tried something like this in your css?

ComboBoxList
{
   IItemRenderer: ClassReference("com.ccc.myRenderer");
}
From: Yishay Weiss<mailto:yishayj...@hotmail.com>
Sent: Monday, July 22, 2019 8:08 PM
Subject: RE: ComboBox list-item renderer

Oh, it looks like you're one step ahead of me. Didn't read your mail carefully 
enough. I think you can safely open a bug, or try to write the bead yourself.

From: Frost, Andrew<mailto:andrew.fr...@harman.com>
Sent: Monday, July 22, 2019 7:53 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: RE: ComboBox list-item renderer

Thanks - yes, happy to adjust our code to that sort of format, but we continue 
to hit the issue that this is a renderer for a list, being set on the list, and 
we want to have a renderer for the list that's being created at runtime from 
the combo box.

It might be that we can set the itemRenderer property of the list object as 
it's created by the combo box's view object, but this feels a little hacky and 
it would be nicer if we could accomplish this just via MXML or CSS..

cheers


-Original Message-
From: Yishay Weiss 
Sent: 22 July 2019 17:43
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: ComboBox list-item renderer

Another option is to specify the renderer class as an mxml att [1]. 
ItemRenderers are not beads, so adding them to the beads list has no effect (it 
should actually cause an RTE).



[1] 
https://clicktime.symantec.com/3L6uXLP6wp93RxE1KiZmGxT7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Ff637c857122d56f838bab21314a11900ed0add8e%2Fexamples%2Froyale%2FTodoListSampleApp%2Fsrc%2Fmain%2Froyale%2Fsample%2Ftodo%2Fviews%2FTodoListView.mxml%23L169




From: Carlos Rovira 
Sent: Monday, July 22, 2019 6:32:27 PM
To: dev@royale.apache.org 
Subject: Re: ComboBox list-item renderer

Hi Andrew,

for this one in Royale it use to be done in CSS. For example in tour de jewel 
for List we do:

Source code in GitHub
<https://clicktime.symantec.com/3FLJQLf6LAcXdburoPNGbpg7Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fexamples%2Froyale%2FTourDeJewel%2Fsrc%2Fmain%2Froyale%2FListPlayGround.mxml>



and in iconListItemRenderer you can find

.iconListItemRenderer
{
IItemRenderer: ClassReference("itemRenderers.IconListItemRenderer");
}

but as well we should can do as inline in MXML, so if that does not work it's a 
bug to solve I think...

HTH

Carlos


El lun., 22 jul. 2019 a las 17:14, Frost, Andrew ()
escribió:

> Hi again
>
> Just in case someone's already done this and knows already how to set 
> it
> up: we want to have an itemRenderer for the ListView part of a 
> ComboBox control, i.e. when you click on the ComboBox button and it 
> creates the ListView, we need a custom renderer. Currently it's 
> defaulting to StringItemRenderer (from the call [1] within the default 
> ItemRendererClassFactory), but we want it instead to use the inline 
> MXML [2].
>
> I'm hoping that we can set this up by adding a bead of some sort to 
> the ComboBox element that will tell it what item renderer to use; all 
> the item renderer examples I can find are just using a list view 
> directly rather than being something that's set up via a ComboBox. So 
> far we've created a custom View for the ComboBox and we are 
> controlling the creation of the ListView, but this creation doesn't 
> then set up any of the MXMLDescriptor values which are needed for this to 
> work...
>
> Hope that makes sense. Don't worry if not, we'll get to the bottom of 
> it, but I wondered if someone already had done this and knew how to do 
> it :-)
>
> thanks
>
>Andrew
>
>
>
> [1] Current way ItemRenderClassFactory selects the item renderer:
> if (_strand is IItemRendererProvider && (_strand as
> IItemRendererProvider).itemRenderer) { ... } else {
> var itemRendererClass:Class =
> ValuesManager.valuesImpl.getValue(_strand, "iItemRenderer") as Class; 
> <<<<< we're getting StringItemRenderer 

Re: AMF and class aliases

[Frost, Andrew]

Thanks all - some useful information there. Yes I think sending as a typed 
class would be better but we're not touching the server-side... so we have to 
have these workarounds. I can see the benefit of the minification for sure, but 
yes when there's an object being created with the property name coming from an 
AMF data stream, it then doesn't match the minified version!

Working now anyway, thanks!


   Andrew


-Original Message-
From: Greg Dove  
Sent: 23 July 2019 05:58
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Andrew, you mentioned this was being 'deserialized', so I assume this is coming 
from the server as an untyped (plain) Object?

In that case, it will be deserialized with the correct original field name from 
the server ('RESULT_CODE' in this case), but there is no typed reference to 
that in your local code, so as Alex says the release build is renaming it, and 
as suggested there needs to be more 'clues' to prevent the renaming. I believe 
Alex knows more about the rules for that than I do.

It seems that you have a way to make it work now, which is probably all you 
want.

But for completeness: another option is to send it as a typed class using 
public vars (not using any manual-coded getter/setter pair or Bindable).
class ResultCode { public var RESULT_CODE:String; } You could then cast the 
result in the same way you mentioned in your first post.

The difference here is that this will also likely rename the field access in 
the release build in the same way that you saw with the original problem, but 
amf deserialization will support that and it should therefore match up with the 
renamed field name used in your release-build local code.
So it's probably an 'in-between' option to consider, for the future.



On Tue, Jul 23, 2019 at 4:11 PM Alex Harui  wrote:

> FWIW, AIUI, the property names of plain Objects and public vars will 
> be renamed unless a quoted string of that property name is used 
> "somewhere" in the JS code.
>
> It might have worked just to use JSON-style:
> {"RESULT_CODE": "OK"}
>
> Creating a class definition causes the compiler to generate an 
> Object.defineProperties structure with the property name as a key in 
> the object structure, thus preventing the rename.
>
> If you scan the js-debug output for RESULT_CODE, you should see where 
> that string showed up and how having a variable "nc" would save bytes, 
> but the name to use for a renamable property is independent of that, 
> and I think properties are renamed before figuring out whether a local 
> variable would further save bytes.
>
> So, that's roughly the answer to #1.  For #2, you "should" use classes 
> with getter/setters instead of [Bindable] unless you need property 
> change detection at runtime in order to get code-completion and compile-time
> checking that you didn't mis-type "RESULTCODE".   There is probably a
> trade-off of how many times you'll make mistakes like that vs the time 
> to create the classes and the additional time to load the class definitions.
> It should be smaller to use [brackets] than load the classes.
>
> The new IDEs should consider a wizard to help generate those classes.
>
> HTH,
> -Alex
>
>
> On 7/22/19, 2:18 AM, "Frost, Andrew"  wrote:
>
> Hi again
>
> One extra question here: we have the AMF connection working fine 
> now in Debug mode, but in Release mode the minifier is changing the 
> property names of our JavaScript (compiled from ActionScript), but 
> these are not being reflected in the objects that are deserialised.
>
> So for example, we are receiving an ArrayCollection, and accessing 
> one element's property directly e.g.:
> var results : ArrayCollection = resultEvt.result as ArrayCollection;
> for (var i : uint = 0; i < results.length; i++)
> {
>   var resultCode : String =
> results[i].outputArray.source[0].RESULT_CODE;
> ...
>
> There are a couple of things going on:
> (a) each element in the main ArrayCollection has an "outputArray"
> property which is itself an ArrayCollection. We could cast it into an 
> ArrayCollection variable I guess, but instead have just added "source" 
> so that the JavaScript doesn't try adding the [] operator to the 
> ArrayCollection object directly...
> (b) the contents of this ArrayCollection, in this particular case, 
> is a simple object {RESULT_CODE: "OK"} - which I can see in the 
> console when we add some trace. The js-debug file has the same 
> structure as the ActionScript; but the js-release file has a mapping 
> at the start "nc='RESULT_CODE'" and the

RE: ComboBox list-item renderer

[Frost, Andrew]

Yes that's fair enough :-)

We have one outstanding question with this, about how the Royale compiler 
generates the "bindings" array. In order to get this to work with a renderer 
defined as inline MXML (rather than as a separate MXML document), we are 
creating a class that implements the IMXMLDocument interface, which is great as 
then we have the MXML array that defines this structure and we can create 
multiple renderers based on this array: this part is all working fine now, so 
we have our custom renderer...

There's one interesting issue where there's an 'id' field defined within the 
inline MXML, but I'm not sure whether it needs to be. The browser seems to cope 
okay with two elements having the same ID! but perhaps we should just have a 
usage rule where you can't include IDs within the MXML structure (or we change 
the ID to include an index, etc..)

The outstanding problem is that the child elements aren't being filled in from 
the data..  the data object has been set on the new renderer object, but this 
isn't resulting in the child elements updating their content. The bindings 
within our inline MXML structure are actually being included within the 
main/enclosing document's binding array, which is a pain because the 'data' 
object is a member of the renderer rather than of the enclosing document.

So would anyone know if there is a way we can get the compiler to generate a " 
_bindings" array that's part of a child element's MXML definition rather than 
within the main class's properties? or is that not possible, and either we have 
to try to hack a little, or we just go with the MXML renderer being always 
defined in a separate class document?

thanks

   Andrew


-Original Message-
From: Alex Harui  
Sent: 23 July 2019 07:43
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: ComboBox list-item renderer

A reminder that Royale emphasizes PAYG and has to live with DAYG (do as you 
go).  For PAYG reasons, the simplest ComboBox probably shouldn't have to 
support custom itemRenderers.  Some subclass is more than welcome to.  And I 
don't think anyone has done it yet so volunteers are welcome.

HTH,
-Alex

On 7/22/19, 11:12 AM, "Frost, Andrew"  wrote:

Thanks - yes we can try that, the issue being that we don't want all combo 
box lists to appear the same way hence trying to have something embedded into 
each bit of mxml...  



We'll take a proper look and see what we can get :-)

cheers


-Original Message-
From: Yishay Weiss  
Sent: 22 July 2019 18:17
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: ComboBox list-item renderer

Note that the overridden css is of ComboBoxList, which is by default the 
list created in runtime, not ComboBox, which is the button that creates the 
list.




From: Yishay Weiss 
Sent: Monday, July 22, 2019 8:13:31 PM
To: dev@royale.apache.org 
Subject: RE: ComboBox list-item renderer

Actually, have you tried something like this in your css?

ComboBoxList
{
   IItemRenderer: ClassReference("com.ccc.myRenderer");
}
From: Yishay Weiss<mailto:yishayj...@hotmail.com>
Sent: Monday, July 22, 2019 8:08 PM
Subject: RE: ComboBox list-item renderer

Oh, it looks like you're one step ahead of me. Didn't read your mail 
carefully enough. I think you can safely open a bug, or try to write the bead 
yourself.

From: Frost, Andrew<mailto:andrew.fr...@harman.com>
Sent: Monday, July 22, 2019 7:53 PM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: RE: ComboBox list-item renderer

Thanks - yes, happy to adjust our code to that sort of format, but we 
continue to hit the issue that this is a renderer for a list, being set on the 
list, and we want to have a renderer for the list that's being created at 
runtime from the combo box.

It might be that we can set the itemRenderer property of the list object as 
it's created by the combo box's view object, but this feels a little hacky and 
it would be nicer if we could accomplish this just via MXML or CSS..

cheers


-Original Message-
From: Yishay Weiss 
Sent: 22 July 2019 17:43
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: ComboBox list-item renderer

Another option is to specify the renderer class as an mxml att [1]. 
ItemRenderers are not beads, so adding them to the beads list has no effect (it 
should actually cause an RTE).



[1] 
https://clicktime.symantec.com/312V9KgaR3PyjyMCjLC5wZt7Vc?u=https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Froyale-asjs%252Fblob%252Ff637c857122d56f8

Re: AS3 Language Features

[Frost, Andrew]

Hi

Fascinating! I had reviewed the AS4 proposal (a long time ago now), so I 
wondered whether that might be worth checking to see if any of their ideas 
would be worth incorporating now? See [1]

A couple of thoughts from the document:

Optional fields in interfaces: I think the way the Actionscript VM works means 
that you do need slots reserved for the interface members, but I don’t think 
there is a check done when the SWF is loaded initially. So this would just be a 
problem if/when someone tried to use an interface function that wasn't actually 
implemented, most likely the Flash Player/AIR would throw a VerifyError. We 
could hack around some ABC to see whether this is the case in practice, 
perhaps..!

Functions with static methods: that's an interesting oddity.. but I can't see 
anything in avmplus that would enforce this just for 'String' or 'Array' 
functions. When you compile "a = Array(1,2,3)" you get a 'getlex' instruction 
to get the Array 'function' and then it's called with the arguments; when you 
compile "a = new Array(1,2,3)" you get a 'constructprop' call instead. So the 
compiler seems to be doing something different, but I don't think there's much 
difference happening within the virtual machine. Again, might be worth hacking 
about a little to see whether this is valid and it's just the compiler 
preventing it...

Arrow functions: this is just a compiler change, the definition of the language 
itself wouldn't change (so yes, as Carlos says, we can change the compiler for 
this..)

Interesting area :-)

cheers

   Andrew

[1] https://github.com/adobe-research/ActionScript4


-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 11 January 2019 09:49
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AS3 Language Features

Hi Harbs,

very interesting. And I think something all here wants. Since we own the 
compiler, I think we can do as much as we want. Don't have much time now, but I 
think most of the things I want are already considered in the document (typed 
Arrays, Generics...). I think AS3 needs those improvements to be considered 
along with current main stream languages like TypeScript and haXe. So Great! :)

El vie., 11 ene. 2019 a las 3:40, Alex Harui ()
escribió:

> FWIW, we already support source externs.
>
> On 1/10/19, 2:38 PM, "Harbs"  wrote:
>
> I very much would like for AS3 to get an upgrade with features. 
> That applies to improvements I the compiler output as well as truly 
> new features in the language.
>
> I’ve started some discussion with Josh on the topic, and we 
> started a Google doc to use to help figure out how we can 
> incrementally improve things.
>
> The link to the Google Doc is here:
> https://clicktime.symantec.com/382sqJFswPJA6S7Nyg4RYvY7Vc?u=https%3A%2
> F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%2
> 52Fdocs.google.com%252Fdocument%252Fd%252F188AAeny3y7bht9JbuE-RXIF_adZ
> HP5uYj0--RANpGNM%252Fedit%253Fusp%253Dsharing%26data%3D02%257C01%257Ca
> harui%2540adobe.com%257C23cdd9000eb047a61a3608d6774c65c3%257Cfa7b1b5a7
> b34438794aed2c178decee1%257C0%257C0%257C636827567358790309%26sdata%3DJ
> Kz7zftxQMkt9o3DPwoqK5xYh8u546a%252Ff0AAtLKc1xQ%253D%26reserved%3D0
> <
> https://clicktime.symantec.com/382sqJFswPJA6S7Nyg4RYvY7Vc?u=https%3A%2
> F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%2
> 52Fdocs.google.com%252Fdocument%252Fd%252F188AAeny3y7bht9JbuE-RXIF_adZ
> HP5uYj0--RANpGNM%252Fedit%253Fusp%253Dsharing%26data%3D02%257C01%257Ca
> harui%2540adobe.com%257C23cdd9000eb047a61a3608d6774c65c3%257Cfa7b1b5a7
> b34438794aed2c178decee1%257C0%257C0%257C636827567358790309%26sdata%3DJ
> Kz7zftxQMkt9o3DPwoqK5xYh8u546a%252Ff0AAtLKc1xQ%253D%26reserved%3D0
> >
>
> I enabled commenting. If someone wants edit access to the 
> document, please let me know.
>
> Thanks,
> Harbs
>
>

--
Carlos Rovira
https://clicktime.symantec.com/3RfjSKYPAhcxAu1UQ1kfrf77Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira

Re: URLRequest

[Frost, Andrew]

Hi

I'd proposed a change for URLLoader to allow you to post binary data [1], but 
actually there's already a class "URLBinaryLoader" which had this functionality 
already... so probably we need to create a similar class, "URLVariablesLoader" 
perhaps.

For the URLVariables class, it looks like this isn't implemented yet, but it 
should be fairly straightforward as all you need to do is url-encode the string 
and then the 'data' in your URL request can be set via the 'toString()' method, 
which I guess will need casting to an Object.

Worth looking at the documentation for the Flash version of URLVariables [2]; 
basically, you pass it your string (in the constructor or in the 'decode' 
method) and then the "toString()" method should return the URL-encoded string 
per the example in [2]. That string can just be used in the parameter that's 
passed in to the XMLHttpRequest 'send()' call - see the "post" example in [3].

Hope that helps!

thanks

Andrew


[1] https://github.com/apache/royale-asjs/pull/345
[2] 
https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/URLVariables.html
[3] https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send


-Original Message-
From: Olaf Krueger [mailto:m...@olafkrueger.net] 
Sent: 30 January 2019 08:23
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: URLRequest

Hi,
unfortunately, I am not sure about URLLoader.
But you may want to give HTTPService a try, something like this [1].
You should find some examples here anywhere [2].

Maybe this helps,
Olaf

[1]
var service:HTTPService = new HTTPService(); service.url = "..."; 
service.method = "POST";

//var header:HTTPHeader = new HTTPHeader(...); //service.contentType = "..."; 
//service.headers = new Array(header);

service.contentData = "...";
service.addEventListener("complete", onComplete); 
service.addEventListener("ioError", onFault); service.send();

[2]
https://clicktime.symantec.com/3XDYEYEvRP6yiHaXvjgdzx77Vc?u=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Froyale



--
Sent from: 
https://clicktime.symantec.com/37Ro7ZbXBwWL17uhQUQPE6v7Vc?u=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F

RE: Let's bump Royale version to 1.0

[Frost, Andrew]

Hi

I would agree with Justin here, my only addition would be that when we hit 1.0 
status, some of the APIs should become immutable – for example things like 
BinaryData and so on, should not then be changed later on. If you have an 
application which compiles against Royale 1.0, it should also compile (and 
work) against any later release (at least 1.x release perhaps; compatibility 
doesn’t necessarily have to go across major versions?).

The component libraries and new functionality can always be added, so 1.0 isn’t 
a “final” version, it just means that you can go ahead without having to make 
changes because someone has updated an API leaving you with code that no longer 
compiles.

I also agree that Royale isn’t the easiest thing to get started with .. so #2 
and #3 below are pretty key.

We can help with #7 if anyone needs support :-)

thanks

   Andrew


From: Justin M. Hill [mailto:jus...@prominic.net]
Sent: 24 April 2019 20:21
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Let's bump Royale version to 1.0


I agree with Piotr.

Perception matters.  1.0 does not need to be perfect, it just needs to be good 
enough.   And Royale is good enough to be called 1.0 in my opinion.   It has 2 
production applications -- ones from Harbs and Carlos are already running on it 
from what I understand.


Royale needs to get traction in the market.


Many people will not pay attention until the following items occur:

1) A version 1.0 is released

2) There are clear tutorials which can get people started quickly [the 
Moonshine team has agreed to fund a few videos to get this started]

3) It is very easy for new developers to get started with the technology [the 
Moonshine IDE accomplishes this with first class support for Royale, Flex, and 
ActionScript]

3) Documentation is improved, easy to read, friendly, and up-to-date

4) Marketing ensues explaining why people should look at Royale compared to 
React, ExtJS, Angular, etc.   If these articles can get written, the Moonshine 
IDE team is willing to help fund some Google and other campaigns to bring 
traction.

5) Multiple IDEs support Royale well -- not just Moonshine IDE and Visual 
Studio Code.   Eclipse, IntelliJ, FlashDevelop also all need to support Royale.

6) Testimonials from other companies who have ported Flex or created fresh 
Royale applications become commonplace and trust starts to build that the 
conversion is possible

7) A consulting ecosystem needs to exist where it is fast for newcomers / 
explorers to decide the technology is worth pursuing and want to engage with a 
consultant to help them along the journey.


Of the above items, the first and easiest thing to control is whether we call 
the software 1.0 or not.   I last had this discussing 28 months ago with Alex 
in Seattle.   A huge amount of work has gone into Royale since then.

As the saying goes:  the enemy of good enough is perfection.

Please, consider pushing the release to 1.0.

Thank you,

Justin Hill


[Inactive hide details for dev-digest-help---04/24/2019 08:33:01 AM---dev 
Digest 24 Apr 2019 13:32:50 - Issue 1958 Topics 
(m]dev-digest-help---04/24/2019 08:33:01 AM---dev Digest 24 Apr 2019 13:32:50 
- Issue 1958 Topics (messages 9856 through 9859)


- Message from Piotr Zarzycki 
mailto:piotrzarzyck...@gmail.com>> on Wed, 24 Apr 
2019 11:56:47 +0200 -
To:

dev@royale.apache.org

Subject:

Let's bump Royale version to 1.0


Hi Team,

Lately, I’m working with Royale framework more and more. Once you know the
framework better from the inside your productivity skyrockets and it is
similar to what we had in Flex. The question comes up - why do we actually
cannot bump our version to 1.0? I’d like to see that happen with the
upcoming release or at least the following one.

What’s holding us back?

Is it lack of features? What if I don’t have some feature in 1.0, but I
will add it in 1.1? This is still fine in my opinion.

Or is it bugs? Because guess how people are seeing us after 5 years of
development and still with leading 0. They think “highly unstable”. And
because this continues for so long they think the project might, in fact,
be dead.

I would like to ask you Team to consider making our upcoming version (or
the following one) as 1.0.

Let’s find the answer in this thread. Post your arguments: “Why not?”, “Why
yes?”

Thanks,
--

Piotr Zarzycki

Patreon: 
*https://www.patreon.com/piotrzarzycki
>*

Re: Let's bump Royale version to 1.0

[Frost, Andrew]

One other thought ... currently the way people ask for support is via these 
mailing lists. Which are okay but I'm always conscious that I'm potentially 
spamming people, plus the volume of mails is such that I have a rule to push 
all these into a folder that I then review every day or two..

But if I want to find something out, I tend not to go search the mailing list, 
I tend to search online. Looking through mailing list threads isn't the easiest 
(and search engines don't necessarily pick things up from them very well) but a 
major source of support is Stack Overflow... I use this a lot with my other 
work and there's a lot of information there.

Apache Royale doesn't appear to have a tag; when I search for "royale" all I 
got was stuff about "Clash Royale"; there are however 8 questions with "flexjs" 
tags.

But wouldn't it be good for people to add questions and to contribute answers 
there, both from the user perspective and perhaps also the dev perspective? 
Would be interested in people's thoughts... (and perhaps I'll have to dig out 
my SO credentials to start contributing there)

thanks

  Andrew


-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 26 April 2019 10:39
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Let's bump Royale version to 1.0

Hi Angelo, that's great! :)

any help here is very appreciated.

Share in a new mail a concrete contribution before starting to work on it, so 
we can know about it and help you on the task so your work fit perfectly in the 
overall picture.

I'd like to create videos too, and people asked about it in facebook and 
twitter. Do you have skills in creating videos?



El vie., 26 abr. 2019 a las 10:47, Angelo Lazzari ()
escribió:

> Yes, i can give some slots to help with documentation or example 
> project or so... I think tutorial videos could be help to understand 
> rapidly the platform and could help new user to get ready in a few 
> hours to start build their project.
>
> Angelo
>
> On Fri, Apr 26, 2019 at 10:42 AM Carlos Rovira 
> 
> wrote:
>
> > Agree with latest comments.
> >
> > I think we should work in docs and ease the start of new users to 
> > target
> > 1.0
> > And in the process fix some few things (i.e: don't want to reach 1.0 
> > with Jewel Table in its current state and API)
> >
> > What do you think?
> >
> > If you all agree could you think on how to contribute to that 
> > effort? Can we have as a near goal to bring 1.0 planing ourselves to 
> > donate some
> hours
> > to Apache Royale to make this happen? If some of us help in the 
> > current state I think we can get to it sooner.
> >
> > Thanks
> >
> >
> > El vie., 26 abr. 2019 a las 9:57, Angelo Lazzari (<
> > lazzari.ang...@gmail.com>)
> > escribió:
> >
> > > I am completely agree with Olaf: start using a new platform where 
> > > the documentation is not complete, clean and updated it is a 
> > > really bad thing...and it would be a potential reason to increase 
> > > the difficulty
> to
> > > adopt the platform...
> > >
> > > Angelo
> > >
> > > El vie., 26 abr. 2019 8:54, Olaf Krueger 
> > escribió:
> > >
> > > > Hi,
> > > >
> > > > Basically, I think it's important to provide a great developer
> > > experience.
> > > > IMO, that's more important than trying to implement missing features.
> > > >
> > > > One thing to achieve this is documentation of course.
> > > > Thanks to all of you there already exist a lot of docs, but it 
> > > > feels
> a
> > > bit
> > > > messy because they are hosted at different places, e.g.:
> > > >
> > > > - royale-docs repo
> > > > - royale-asjs wiki
> > > > - royale-asjs Readme
> > > > - 
> > > > https://clicktime.symantec.com/3SEvxFs2HbjNAgsLBEtNLr17Vc?u=http
> > > > s%3A%2F%2Froyale.apache.org
> > > > - ...?
> > > >
> > > > As a user, it's hard to get an overview of what is available... 
> > > > and
> > > where.
> > > > Maybe it's a good idea to consolidate the docs before releasing 1.0.
> > > >
> > > > Just my 2 cents,
> > > > Olaf
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from: 
> > > > https://clicktime.symantec.com/3LM5ngUtumonkv3VTyrZRJ77Vc?u=http
> > > > %3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > https://clicktime.symantec.com/38jVp7aJ4ouZou8k1qd97Hn7Vc?u=http%3A%
> > 2F%2Fabout.me%2Fcarlosrovira
> >
>
>
> --
> Angelo Lazzari
> mobile: +34 683 137 087
> mail: lazzari.ang...@gmail.com
>
>
>
> --
> --
> Verify the correspondence of the addressee; otherwise, notify that to 
> the sender and, conscious of the responsibility for the undue use, 
> destroy the message and its copies.
>
> --
> --
>


--
Carlos Rovira
https://clicktime.symantec.com/38jVp7aJ4ouZou8k1qd97Hn7V

RE: extending IUIBase with interfaces (was: Re: Version property (was: Let's bump Royale version to 1.0))

[Frost, Andrew]

Hi Carlos

Isn't this similar to the challenge that Adobe had with EventDispatcher? which 
I think is why there are two possibilities:
a) derive from EventDispatcher
b) implement IEventDispatcher

In the second case, you have to create an instance of EventDispatcher within 
your class, and then you have to implement the IEventDispatcher functions with 
calls to the EventDispatcher object. So it's not zero-effort, but it's not too 
bad (and probably the best option you can get without multiple inheritance..). 
Yes there's repeated code, but it's limited to one line per function so is 
relatively easy to copy/paste.

Not 100% sure if the same approach can be applied in the scenario you're 
talking about, but that might help perhaps..? So the functionality you want to 
repeat would go into a class ("ClassSelectorListSupportImpl"?) and you create 
one of these in each of the classes that derive from UIBase/Group/etc and 
implement IClassSelectorLitsSupport.

Some alternatives perhaps:
- I'm also wondering whether you could create a helper function that actually 
adjusted the class prototype and programmatically added the necessary functions 
to your classes... ?
- the repeated functionality could be put into other .as files and just 
'included' in the classes? I know, this is a major hack, but I've seen it done 
:-(


Hope it helps..

thanks

   Andrew



-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 29 April 2019 18:04
To: dev@royale.apache.org
Subject: [EXTERNAL] extending IUIBase with interfaces (was: Re: Version 
property (was: Let's bump Royale version to 1.0))

Hi Alex,

initial problem is: I want to add to all jewel components (that use to have 
UIBase as common class) a new interface and implement the methods. In concrete 
interface is: IClassSelectorListSupport

So the expected result should be to make all Jewel components implement 
IClassSelectorListSupport, but to avoid repeat code in all classes we need a 
root for all the components.

Perfect point would be UIBase, but we can't add at that point for PAYG reasons.

Current solution in Jewel is to create StyledUIBase that is

public class StyledUIBase extends UIBase implements IClassSelectorListSupport

but this makes other classes like jewel Group that extend html Group have 
UIBase in the hierarchical chain instead StyledUIBase, so we need to make Group 
as this:

public class Group extends org.apache.royale.html.Group implements 
IClassSelectorListSupport

same for

public class DataContainerBase extends
org.apache.royale.core.DataContainerBase implements IClassSelectorListSupport

This make we have 3 classes that are duplicating the same exact code 
implementing in the same maner addClass, removeClass, etc..

what can we do for this cases?

Hope is more clear now,

thanks



El lun., 29 abr. 2019 a las 17:41, Alex Harui ()
escribió:

>
> @Carlos, I couldn't understand your scenario.  Feel free to start a 
> separate thread on it.  The key aspect, as a guess, is trying to avoid 
> code that assumes that an instance is a subclass of a particular base 
> class instead of an implementation of an interface.
>
> HTH,
> -Alex
>
> On 4/29/19, 7:29 AM, "Carlos Rovira"  wrote:
>
> @Mark, if you use Maven, then artifacts in the poms are all what 
> you need,
> so maven takes care of pulling all right dependencies you need.
>
> @Alex, about extending IUIBase, my own experience is that beads 
> are a very
> good way to extend/compose more code you need, but extending core
> interfaces like the one you said is not the case. Let me put you an
> example: For Jewel I use "StyledUIBase" that extends "UIBase" to add
> IClassSelectorListSupport, the css CRUD API (addClass, 
> removeClass,
> etc..):
>
> public class StyledUIBase extends UIBase implements
> IClassSelectorListSupport
>
> This makes that some components are easy to extend but others need 
> to be
> recreate. There are lots of cases in Jewel where I need to
>
> If you search in Jewel for implements IClassSelectorListSupport
>  you'll find Jewel Group, Jewel DataContainerBase and Jewel Table, are
> implementing that class while, so they are not StyledUIBase in 
> it's core
> are standard UIBase and at its level we implement the interface and add
> again all methods repeating the code. So we are duplicating that 
> code all
> that times.
>
> I think this is one of the few things I don't like in Jewel, If 
> you know
> some way to do this in a better way, I can change it
>
> thanks
>
> --
Carlos Rovira
https://clicktime.symantec.com/37RX7Zfo3fgsrnBKZDX18bM7Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira

The start of a FullCalendar Royale component...

[Frost, Andrew]

Hi

Something that Dany Dhondt wrote recently, about using the "fullcalendar" React 
component, got me to wondering how easy it was to wrap these sorts of third 
party components into Royale.

The answer turned out to be: it's pretty straightforward. I'm not sure I've 
used the best approach (no 'typedefs' or anything) but I've created some 
wrapper classes that can be used from MXML to drop in a calendar component and 
add events etc. Lots of extra work to do to get it to the stage where it's as 
functional as the JS/React etc versions, but the lack here is (a) time and (b) 
documentation (I can't see a full API for the various FullCalendar classes..!)

Hope it's useful for folk to see how quickly this can be done...

https://github.com/ajwfrost/royale-playground/tree/master/CalendarProject
(the wrapper classes are in src/io/fullcalendar, and the mxml file that uses 
them is just src/CalendarProject.mxml .. I've been using Moonshine and just 
uploaded the whole project so there's lots of irrelevant files in there too!)


thanks

   Andrew

Re: The start of a FullCalendar Royale component...

[Frost, Andrew]

Hi

Responding (belatedly!) to a few of these points:

- I need to look at how to get those typedefs working! as yes, it would be 
great to not have to use the obj["property"] notation!
- Equally: yes I found it useful to redefine the API. I don't like the way that 
everything is specified as a property within a config object that's passed in 
to the constructor, though it seems a common pattern in JavaScript. For me, I 
would to set up individual properties, so hopefully that's what this approach 
can achieve (and of course, now each property is set within the mxml tag)
- I just grabbed the latest source for that component, turns out to be 4.1.0.. 
I didn't get on so well with trying to actually find the API for the calendar 
in order to reproduce everything it can do, so was mostly working of the 
samples and demo code, trying to make sure the same thing could be done in 
Royale.

One interesting part I found was setting the header: rather than defining a 
class with a 'center' property (as I didn't know what other properties it might 
have) I just left this as an Object, and then in MXML I could use  to define it. Which struck me as incredibly flexible! - 
although not ideal I think, as then you lose all the benefits of the type 
checking and it wouldn't have corrected me if I spelt "center" and "centre", 
etc...

The injection of the script/css tags was interesting, I didn't want to have to 
pull in everything all at once, hence separating out the 'plugins' into 
different classes actually really helped with that. Probably it would be useful 
to have some interfaces defined so that we can identify which plugins are also 
views, and get the view-specific settings for these 'properly' rather than 
testing for the existence of a particular property..

Anyway: lots could be improved here, but it was a useful exercise..


thanks

   Andrew


-Original Message-
From: Dany Dhondt [mailto:archeme...@mac.com.INVALID] 
Sent: 03 May 2019 07:28
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: The start of a FullCalendar Royale component...

The (very) good news is that is IS possible. To me as a developer (and others 
we’re hoping to use Royale), it is vital to know that it can be done. At some 
point in developing an application with Royale, we’ll stumble on some 
functionality or component which just isn’t available in Royale. At that point, 
it is simply not acceptable to say ‘well hey, it can’t be done right now but 
come back in a year or so’. 
FullCalendar is a good example because every developer will need a calendar 
component sooner or later. FC is becoming a standard in javascript (+70k 
downloads a week).
@Andrew, I’ll post the FullCalendar question on StackOverflow. Could you answer 
it? That way, Royale will emerge too when people search on the FullCalendar tag.
Another question: did you use the 4.x version of FC or the (older) 3.x version?

Thanks
Dany

> Op 3 mei 2019, om 07:55 heeft Piotr Zarzycki  het 
> volgende geschreven:
> 
> Hi Andrew,
> 
> First of all Thank you for using Moonshine! I think there is one good 
> advantage to going by your approach instead typedefs. You can redefine 
> API to completely new if you don't like in the original component. 
> Those new API may have a bit more of a AS3 style etc.
> 
> Thanks,
> Piotr
> 
> On Fri, May 3, 2019, 6:26 AM Alex Harui  wrote:
> 
>> Hi Andrew,
>> 
>> That's cool!  Thank you for demonstrating that such a thing can be done.
>> 
>> I'm not sure there is a "best approach" for doing something like 
>> this.  It really depends on how much time you want to put into it.  
>> If you want to use a 3rd-party component in your app and only want to 
>> use a few APIs, then the approach you took is fine and solves your problem 
>> quickly.
>> 
>> On the other hand, if you want to make it complete and offer it to 
>> others to use you may find that creating typedefs for the options and 
>> calendar objects and other objects you are wrapping will eliminate 
>> the need to use bracket access such as  'options["defaultView"] = 
>> _defaultView;' and thus allow the IDE to offer better code-assist and 
>> catch typos so you don't later waste time debugging why 
>> 'options["defaultview"]' is not working.
>> 
>> Thanks,
>> -Alex
>> 
>> On 5/2/19, 2:07 PM, "Frost, Andrew"  wrote:
>> 
>>Hi
>> 
>>Something that Dany Dhondt wrote recently, about using the 
>> "fullcalendar" React component, got me to wondering how easy it was 
>> to wrap these sorts of third party components into Royale.
>> 
>>The answer turned out to be: it's prett

Re: AIR and Royale

[Frost, Andrew]

Yes, me :-)

I'm pushing Royale internally, I think it has a lot of promise - although I 
still do find it a little frustrating at times internally! In terms of what 
support you can give, the sorts of things you're already doing are great, but 
yes it might mean we lean a little more on this mailing list if we're facing 
tricky issues.

We have one sales case in particular at the moment which has the potential to 
be very big, we're hoping they move forwards with a proof of concept project 
which would take a small part of their app and port this to Royale. A few 
issues we've found so far from investigations:
- their flex code is embedding icons that are contained within a SWF. Royale 
compiler didn't seem to like this, not sure whether it's just syntax or whether 
we need to pull all the assets out (not a big job, we can automate that..)
- they have binding using functions e.g. 
text="{localizationHelper.getString('fieldName')}", which caused an issue when 
generating the JavaScript code as the string-within-a-string seemed to upset 
the parser. We can look at this later perhaps though..
- when we got it compiling, the main thing was with responsiveness i.e. trying 
to get the app to resize and for all the internal elements to then resize. We 
may use the MX emulation classes for this but it still looked like more support 
is needed - although we only looked briefly at this.

Once those issues are sorted though, we would have one big task (to recreate a 
very advanced data grid control that they'd developed in Flex/Flash) and a lot 
of the rest - around the AS3 logic - should fall into place! I'm hoping we can 
convince them to go with this solution..


thanks

   Andrew



-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 04 June 2019 14:41
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AIR and Royale

Well to start with: Does anyone know anyone working for them?

I’d like to hear from them what it would take for them to push Royale more.

> On Jun 4, 2019, at 4:10 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> what's the kind of support you're thinking ?
> 
> 
> 
> El mar., 4 jun. 2019 a las 9:36, Piotr Zarzycki 
> ()
> escribió:
> 
>> Hi Harbs,
>> 
>> I was exactly think the same about that, so I'm keeping finger 
>> crossed to that effort.
>> 
>> Thanks,
>> Piotr
>> 
>> wt., 4 cze 2019 o 09:34 Harbs  napisał(a):
>> 
>>> I just heard about this announcement.[1]
>>> 
>>> I went over to the Harman site and was reading this page.[2]
>>> 
>>> I was particularly struck by this statement:
>>> 
>>> HARMAN’s offerings also include consultancy, support and migration 
>>> services for companies looking to move their applications away from 
>>> Flash technologies over to HTML5 via solutions such as Angular, 
>>> Apache Royale
>> and
>>> other JavaScript based frameworks.
>>> 
>>> 
>>> Considering that they mention Royale explicitly as the number 2
>> framework,
>>> I’m guessing they will be pushing Royale to a certain degree. We 
>>> should probably look to support that effort.
>>> 
>>> [1]https://clicktime.symantec.com/3L9wbF4uCYccj7EQCUBeXbp7Vc?u=https
>>> %3A%2F%2Ftheblog.adobe.com%2Fthe-future-of-adobe-air%2F < 
>>> https://clicktime.symantec.com/3L9wbF4uCYccj7EQCUBeXbp7Vc?u=https%3A
>>> %2F%2Ftheblog.adobe.com%2Fthe-future-of-adobe-air%2F>
>>> [2]https://clicktime.symantec.com/36DC33RH3RXctPTGAK4XztY7Vc?u=https
>>> %3A%2F%2Fservices.harman.com%2Fpartners%2Fadobe < 
>>> https://clicktime.symantec.com/36DC33RH3RXctPTGAK4XztY7Vc?u=https%3A
>>> %2F%2Fservices.harman.com%2Fpartners%2Fadobe>
>> 
>> 
>> 
>> --
>> 
>> Piotr Zarzycki
>> 
>> Patreon: 
>> *https://clicktime.symantec.com/32dvoAS1WTaQP1E2yQmx5pn7Vc?u=https%3A
>> %2F%2Fwww.patreon.com%2Fpiotrzarzycki
>> > %2F%2Fwww.patreon.com%2Fpiotrzarzycki>*
>> 
> 
> 
> --
> Carlos Rovira
> https://clicktime.symantec.com/3Peb7VMJWFagYLtTD2HSBGD7Vc?u=http%3A%2F
> %2Fabout.me%2Fcarlosrovira

Re: Embedded Assets (was Re: AIR and Royale)

[Frost, Andrew]

Thanks, Alex & Carlos

Yes I agree basically, embedding something in terms of how Flex does it isn't 
something that's relevant for Royale or HTTP-based solutions in the same way, 
and we certainly don't want to end up encoding something into text base64 
formats..

It might be nice to have the compiler do some magic to recognise this scenario 
and to grab the swf file, extract the image and then change the mxml so that it 
just becomes a url reference.. but that's probably a lot of work compared to 
just doing this as a manual operation which is just a one-off update needed in 
the code.

So that:

is turned into something like


Anyway, if we get asked to do this then I'll take a look to see whether it 
could be merged into the toolchain somehow.. having a quick look into the SWF 
it could be fun as these icons are actually not just pure images but include 
some shape output from the Flash/Animate authoring tools too.. but I guess we 
can just have some quick AS3 tool to extract these with the appropriate shape 
and save them to png..

For now I'll wait to see whether the project does actually go ahead!!

thanks

   Andrew


-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 06 June 2019 11:33
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)

Hi,

I think in the case of HTML, does not have sense to me the concept of Embed 
like in Flex. Maybe of SWF target or others (don't know if WebAsm could benefit 
from something like this) Maybe for HTML use something like Embed metadata, 
could just copy the assets to the resources folder to be available, since like 
Alex said, a request per asset is needed and making other kind of big file 
seems strange in this case (maybe not). Although we have solved the copying of 
assets in different ways through compiler for libraries and ANT/MAVEN 
automation in Application.

for me this could be something to investigate in the future, but with low 
priority, since I think we still have bigger fish to fry

just my 2...


El mié., 5 jun. 2019 a las 18:07, Alex Harui ()
escribió:

> Regarding embedded assets in Royale:
>
> There is no embedded asset support at this time because it is not 
> obvious to me it will be worth it.  We need a volunteer to devise a 
> strategy that works and implement it.
>
> In Flex/Flash, my understanding is that folks embedded assets to save 
> on server requests for assets like images.  That makes sense because, 
> since a SWF is a compressed binary and most assets are compressed 
> binaries, you can essentially append the assets to the SWF.
>
> However, for Royale in the browser, every implementation of "embedding"
> I've seen seems to Base64 encode the asset, converting it to text and 
> increasing the number of bytes.  And the resulting Base64 bytes may 
> deteriorate the gzip compression of the .html file.
>
> Flash also had frames in the SWF and assets could be embedded on later 
> frames allowing a download progress bar to show up before all of the 
> rest of the SWF is downloaded.  I don't know what the equivalent for 
> that is without Flash.
>
> I believe another advantage of embedding in Flash was that the asset 
> was ready to be instantiated and placed on the display list right 
> away.  I'm not clear that an embedded Base64 image can be used in an 
>  tag and prevent "popping" given that Royale generates the  tags 
> dynamically.
>
> So, we need a volunteer to create some examples of how to use browser 
> embedding in dynamically generated  tags so we can see if there 
> will be any benefit or not.  And if not, possibly explore other 
> options, such as delivering all assets in one true binary blob somehow.
>
> HTH,
> -Alex
>
> On 6/5/19, 7:05 AM, "Frost, Andrew"  wrote:
>
> Yes, me :-)
>
> I'm pushing Royale internally, I think it has a lot of promise - 
> although I still do find it a little frustrating at times internally! 
> In terms of what support you can give, the sorts of things you're 
> already doing are great, but yes it might mean we lean a little more 
> on this mailing list if we're facing tricky issues.
>
> We have one sales case in particular at the moment which has the 
> potential to be very big, we're hoping they move forwards with a proof 
> of concept project which would take a small part of their app and port 
> this to Royale. A few issues we've found so far from investigations:
> - their flex code is embedding icons that are contained within a SWF.
> Royale compiler didn't seem to like this, not sure whether it's just 
> syntax or whether we need to pull all the assets out (not a big job, 
> we can automate that..)
> - they have binding

Re: Embedded Assets (was Re: AIR and Royale)

[Frost, Andrew]

Thanks! I'd not seen that page before, looks useful :-)

cheers


-Original Message-
From: Andrew Wetmore [mailto:cottag...@gmail.com] 
Sent: 06 June 2019 14:07
To: dev@royale.apache.org; Carlos Rovira 
Subject: [EXTERNAL] Re: Embedded Assets (was Re: AIR and Royale)

I just added a brief statement about using a URL instead of embedding assets in 
Royale in the "Flex Equivalents" page [1].

@Carlos Rovira  , where does that page appear when a 
user is looking through the documentation? I can't find my way to it through 
the compiled Help Docs, or in the ToC.

RE: Royale Commercial Support Page (was: Fwd: AIR and Royale)

[Frost, Andrew]

Hi

Please count us in! Let me know if you have a length in mind for the 
description, we could expand upon that..


* NAME: HARMAN Connected Services
* SHORT DESCRIPTION (if applies): Software services company with web 
development teams plus background in Adobe technologies
* LOGO (if applies) (PNG, background transparent, good resolution (at least 
above 800px): Can be downloaded from 
https://www.dropbox.com/s/72spasyd5o7f7ok/Harman%20Primary%20Corporate%20Logo%20CMYK.png?dl=0
* WEBSITE URL: https://services.harman.com
* CONTACT PERSON (in case of individual can be same as NAME): Andrew Frost
* EMAIL OF CONTACT: andrew.fr...@harman.com
* PHONE OF CONTACT: +447752 490699
* APACHE ROYALE CONTRIBUTOR: yes via PRs and potentially directly, pending our 
legal dept :-(


thanks

   Andrew

-Original Message-
From: Carlos Rovira [mailto:carlosrov...@apache.org] 
Sent: 07 June 2019 10:24
To: dev@royale.apache.org
Subject: [EXTERNAL] Royale Commercial Support Page (was: Fwd: AIR and Royale)

Hi,

I'll be creating a page on the website in the following days with a list of 
third party providers that offers commercial support for Apache Royale, in the 
lines we saw in the links shared by Dave Fisher as examples in other Apache 
products.

It could be companies or individuals.

Anyone that wants to be listed, please share here the following data:

* NAME
* SHORT DESCRIPTION (if applies)
* LOGO (if applies) (PNG, background transparent, good resolution (at least 
above 800px)
* WEBSITE URL
* CONTACT PERSON (in case of individual can be same as NAME)
* EMAIL OF CONTACT
* PHONE OF CONTACT
* APACHE ROYALE CONTRIBUTOR (if the company or individual has people 
contributing to this project, or if is an individual contributes to this
project)

thanks


-- Forwarded message -
De: Carlos Rovira 

If you consider this ok, I can create a thread so companies that want to be 
listed, can express they want to, and I can create a page in our site with the 
logos and urls and maybe more (contact person?, ...)

thanks



--
Carlos Rovira
https://clicktime.symantec.com/3K3p6aWscq5ynav4MdyiTSC7Vc?u=http%3A%2F%2Fabout.me%2Fcarlosrovira

Re: Migrating Enterprise Flex Application

[Frost, Andrew]

Hi

At a guess, if it's hanging on that "Loading configuration" line, then your xml 
config needs to change.

My suggestions would be to start by stripping out all of the external SWC 
libraries that you're trying to use - these may need replacing/migrating too; 
then if it's still hanging on the "Loading configuration: 
C:\devenv\ii\trunk\components\FlexUIPlatform\build\resources\flex\gradle-flex-config.xml"
 message, you could try editing that file (or e.g. copying to 
gradel-royale-config.xml and editing that) and take out elements of this which 
don't look like they're needed..

Worst case, you may need to load up the Royale compiler into Eclipse and see 
what's actually happening (Alex wrote a good guide for this at 
https://github.com/apache/royale-compiler/wiki/Developer-Guide). I just checked 
but can't see any way of getting the compiler to output any more verbose 
details to the command line.

Your application seems pretty complex from looking at all those dependencies, 
so it may be worth starting with a simpler/basic example just to get used to 
the tools and options. Or if you share your flex-config xml file then someone 
might be able to spot a problem with it.. 

Hope that helps..

Andrew


-Original Message-
From: chembali [mailto:chemb...@hotmail.com] 
Sent: 27 June 2018 10:28
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Migrating Enterprise Flex Application

Another road block. The command to compile the first component using compc is 
the following.

C:\devenv\ii\trunk\tools\flex\flex4.1-adobe\bin\compc -compiler.locale=en_US 
-load-config=C:\devenv\ii\trunk\components\FlexUIPlatform\build/resources/flex/gradle-flex-config.xml
-compiler.source-path=C:\devenv\ii\trunk\components\FlexUIPlatform/src-flexui
-compiler.source-path=C:\devenv\ii\trunk\components\FlexUIPlatform/src-gen/flexui
-include-sources+=C:\devenv\ii\trunk\components\FlexUIPlatform\src-flexu
-include-sources+i\com 
-include-sources+=C:\devenv\ii\trunk\components\FlexUIPlatform\src-flexu
-include-sources+i\cosm 
-include-sources+=C:\devenv\ii\trunk\components\FlexUIPlatform\src-gen\f
-include-sources+lexui\com
-compiler.source-path=C:\devenv\ii\trunk\components\FlexUIPlatform/res-flexui/locale/{locale}
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\flexlib.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\automation.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\Cairngorm.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\CairngormEnterprise.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\diagrammer.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\drumbeatinsight.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\FlexSpy.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\granite.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\kap-layouts-1.6.2.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\kap-licence-1.6.1-commercial.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\MaskedTextInput.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\multicolumnform.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-flexui\svg-1.6.2.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\build\flex\flexuiplatform-asset.swc
-output=C:\devenv\ii\trunk\components\FlexUIPlatform\build\flex\flexuiplatform.swc

This command works fine and creates the .swc file.

I just changed 'C:\devenv\ii\trunk\tools\flex\flex4.1-adobe\bin\compc' to 
'C:/devenv/apache-royale/royale-asjs/bin/compc' to invoke the Royale compc and 
it is hanging.

Here is the output..

C:\devenv\ii\trunk\components\InfogixInsight>C:/devenv/apache-royale/royale-asjs
/bin/compc -compiler.locale=en_US
-load-config=C:\devenv\ii\trunk\components\Fle
xUIPlatform\build/resources/flex/gradle-flex-config.xml
-compiler.source-path=C:
\devenv\ii\trunk\components\FlexUIPlatform/src-flexui
-compiler.source-path=C:\d
evenv\ii\trunk\components\FlexUIPlatform/src-gen/flexui
-include-sources+=C:\dev
env\ii\trunk\components\FlexUIPlatform\src-flexui\com
-include-sources+=C:\deven
v\ii\trunk\components\FlexUIPlatform\src-flexui\cosm
-include-sources+=C:\devenv
\ii\trunk\components\FlexUIPlatform\src-gen\flexui\com
-compiler.source-path=C:\
devenv\ii\trunk\components\FlexUIPlatform/res-flexui/locale/{locale}
-compiler.e
xternal-library-path+=C:\devenv\ii\trunk\components\FlexUIPlatform\lib-f
xternal-library-path+lexui\fl
exlib.swc
-compiler.external-library-path+=C:\devenv\ii\trunk\components\FlexUIP
latform\lib-f

RE: Migrating Enterprise Flex Application

[Frost, Andrew]

Yes I just tried with your config file, I don't get anything hanging although 
I've got a later Flex SDK so some of the paths/SWC files you're including from 
that are coming up with errors..

Maybe it's worth a slightly more verbose output from the compiler so that we 
can see how far it's getting.. Alex would you think it's worth doing something 
'official' with a -verbose flag, in case this sort of thing needs to be 
examined in the future? Or it could just be a one-off hack (or using the 
Eclipse debugger to walk through the compilation process to find the issue..).

thanks

   Andrew


-Original Message-
From: chembali [mailto:chemb...@hotmail.com] 
Sent: 28 June 2018 09:46
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Migrating Enterprise Flex Application

I got the nightly build apache-royale-0.9.3-bin-js-swf.zip on June 22. It looks 
like the issue may not be related to the flex-config.xml. I tried to compile 
another component source and it went ahead and compiled the component giving a 
bunch of compile errors. It did not hang though.



--
Sent from: 
https://clicktime.symantec.com/a/1/w8-0aepjtghwJrEW5GLyuRkoS-VeQzvX48OL59I1DMk=?d=OjYvciyyDRLwFT_tUfjYlUA--SsRn5GZapZJdWKYQ6H7T8y5egtT4QsxyO4aNl92BLSp4rGFrBlHLq4Ta6VcLODkcYMaZ7MizXNd0fVujSh3fpenzlFPXntcVkYsWIzK81EpCYgYYMdkM_P4LuDAswrmxQiWPSdBuZOe7tUeI0kiHPX5SAy068B1zgf1H10LmvV8EwdZHLsrXn-GRsOKejIuZ6IVREqX3oz-aAfWWAS_N8JlWMMhtfiv8fpqyp6ci46w4XK4cOLoL3nMdYPPEEIdRbvkJqfDb0tnVNJV2w7I50xWcHCVmVaTDQn-25XAymk5OWyDvZNKi0cyNKrfNmGBUWMa-XqlVtd1aPCkLt0izrYZLRIJkDvsEPH1YVlXPL2mMYgN5DFZzuvASlDHTwIsdZzgb5Yx3w%3D%3D&u=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F

Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Hi guys

I'm getting errors with the Royale compiler when trying to access the 
properties of a Date object ("Error: Access of possibly undefined property 
fullYear through a reference with static type Date.")

Having looked into it, this is because the JavaScript 'Date' object has 
"getFullYear" and "setFullYear", rather than set/get functions. There looks 
like there's some clever code going on within BinaryOperatorEmitter.java which 
should be able to handle this and translate the output (which it does, and 
which works fine), but we're getting the AccessUndefinedMemberProblem error 
reported prior to this.

It looked to me as if there were a few possible workarounds for this, but I was 
thinking it might be better if someone a little more familiar with the compiler 
code was to look at this? I put in a hack within the 
"MethodBodySemanticChecker" class, in the "checkMemberAccess" method:
IDefinition def = utils.getDefinition(member_node);

// Is this a special case of "Date" where access to properties need to 
be functions?
if ( (def == null) && (iNode instanceof MemberAccessExpressionNode) )
{
IExpressionNode left  = ((MemberAccessExpressionNode) 
iNode).getLeftOperandNode();
IExpressionNode right = ((MemberAccessExpressionNode) 
iNode).getRightOperandNode();
if (left instanceof IdentifierNode && right instanceof 
IdentifierNode)
{
  ITypeDefinition classLeft = left.resolveType(project);
  if (classLeft != null && 
classLeft.getBaseName().equals("Date") )
  {
// is the right hand side one of our acceptable 
elements?
String memberName = ((IdentifierNode) right).getName();
final String[] allowed = { "time", "fullYear", "month", 
"date", "fullYearUTC",
   "monthUTC", 
"dateUTC", "hours", "minutes", "seconds",
   "milliseconds", 
"hoursUTC", "minutesUTC",
   
"secondsUTC","millisecondsUTF" };
if ( Arrays.asList(allowed).contains(memberName) ) 
return;
  }
}
}
if ( def == null && utils.definitionCanBeAnalyzed(member) )
{

This works - and the other BinaryOperatorEmitter code then kicks in to output 
the correct JavaScript - but it's not very elegant! and may screw up if anyone 
has created their own something.Date class .. so I was thinking it would be 
better to be fixed by an expert!

Let me know if you'd like me to raise an issue on the royale-compiler github 
project for this..

thanks

  Andrew

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Actually this will definitely need more effort/investigation, as this only 
helped with the ActionScript within my test MXML file (below); it didn't help 
when I had an assignment. So maybe the 'get' is sorted with the below but the 
'set' needs to be sorted within the MethodBodySemanticChecker.checkLValue() 
method?

thanks

---
Code from TextButton's click handler; compiles with my below hack:
   var tgt : TextButton = event.target as TextButton;
  var date : Date = new Date();
   if (tgt) tgt.text = "Thanks: " + date.toTimeString() + ".." + date.fullYear;

Code that fails to compile still:
   date.fullYear = 2016;



-Original Message-
From: Frost, Andrew [mailto:andrew.fr...@harman.com] 
Sent: 28 June 2018 17:04
To: dev@royale.apache.org
Subject: [EXTERNAL] Royale compiler not handling Date.fullYear etc

Hi guys

I'm getting errors with the Royale compiler when trying to access the 
properties of a Date object ("Error: Access of possibly undefined property 
fullYear through a reference with static type Date.")

Having looked into it, this is because the JavaScript 'Date' object has 
"getFullYear" and "setFullYear", rather than set/get functions. There looks 
like there's some clever code going on within BinaryOperatorEmitter.java which 
should be able to handle this and translate the output (which it does, and 
which works fine), but we're getting the AccessUndefinedMemberProblem error 
reported prior to this.

It looked to me as if there were a few possible workarounds for this, but I was 
thinking it might be better if someone a little more familiar with the compiler 
code was to look at this? I put in a hack within the 
"MethodBodySemanticChecker" class, in the "checkMemberAccess" method:
IDefinition def = utils.getDefinition(member_node);

// Is this a special case of "Date" where access to properties need to 
be functions?
if ( (def == null) && (iNode instanceof MemberAccessExpressionNode) )
{
IExpressionNode left  = ((MemberAccessExpressionNode) 
iNode).getLeftOperandNode();
IExpressionNode right = ((MemberAccessExpressionNode) 
iNode).getRightOperandNode();
if (left instanceof IdentifierNode && right instanceof 
IdentifierNode)
{
  ITypeDefinition classLeft = left.resolveType(project);
  if (classLeft != null && 
classLeft.getBaseName().equals("Date") )
  {
// is the right hand side one of our acceptable 
elements?
String memberName = ((IdentifierNode) right).getName();
final String[] allowed = { "time", "fullYear", "month", 
"date", "fullYearUTC",
   "monthUTC", 
"dateUTC", "hours", "minutes", "seconds",
   "milliseconds", 
"hoursUTC", "minutesUTC",
   
"secondsUTC","millisecondsUTF" };
if ( Arrays.asList(allowed).contains(memberName) ) 
return;
  }
}
}
if ( def == null && utils.definitionCanBeAnalyzed(member) )
{

This works - and the other BinaryOperatorEmitter code then kicks in to output 
the correct JavaScript - but it's not very elegant! and may screw up if anyone 
has created their own something.Date class .. so I was thinking it would be 
better to be fixed by an expert!

Let me know if you'd like me to raise an issue on the royale-compiler github 
project for this..

thanks

  Andrew

Re: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Hi

Thanks Alex for the explanation and background! Yes I think that the 
BinaryOperatorEmitter code is kicking in to do the actual conversion during the 
emitting phase, so that bit works fine; it was just earlier on (and as you 
suggest, a think it's trying to build some ABC from the parsed tree which is 
where this issue came up - ASCompilationUnit.handleABCBytesRequest is lower 
down the call stack..)

I hadn't spotted the 'missing.js' file; presumably then, this is compiled into 
the js.swc file ...

First try: I just added the blank definition "Date.prototype.fullYear;" to the 
bottom of missing.js per Harbs' suggestion, and built js.swc again (had to 
manually then copy it into the royale-asjs folder?); this solved the 
compilation error but then I think the later conversion to getFullYear() didn't 
work as this returned "undefined" when I called it...

Second try: adding the below to missing.js:
Date.prototype.__defineGetter__("fullYear", function() { return 
this.getFullYear(); });
just didn't work; the generated SWC file didn't include any properties on the 
Date object.

I've tried a couple of other things but I'm not sure how it would be possible 
to add separate get/set methods using this mechanism.. or maybe the translation 
needs to change so that it has higher priority?

I'll do a little more digging, unless anyone knows how we could map different 
functions to the set/get methods? Maybe with the below updates, it makes more 
sense to change the specialCaseDate function..

thanks

   Andrew


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 28 June 2018 19:31
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Yes. That sounds like a good solution to me.

Adding:
/**
 * @type {number}
 */
Date.prototype.time;

/**
 * @type {number}
 */
Date.prototype.fullYear;

Etc… to missing.js should do it.

Harbs

> On Jun 28, 2018, at 8:36 PM, Alex Harui  wrote:
> 
> It's only been the past year or so that we've got the "JS Only" configuration 
> working where you compile against js.swc instead of playerglobal.  And I 
> suspect that nobody has tried Date until you just did.  We could say that, if 
> you are compiling against js.swc you are expected to use the APIs for the 
> browser and can't use Date.fullYear, but because specialCaseDate already 
> exists, we have the choice of adding Date.fullYear to the missing.js file in 
> royale-typedefs/js/src/main/javascript.  Then I think you would be allowed to 
> use Date.fullYear and it would get transpiled correctly.
> 
> I don't see any harm in adding SWF APIs to js.swc if we know how to transpile 
> them.  What do others think?  It would be great if you could give that a try.

RE: Migrating Enterprise Flex Application

[Frost, Andrew]

Sure thing, we'll take a look at this... 

-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 28 June 2018 17:57
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Migrating Enterprise Flex Application

Hi Andrew,

Yes, a --verbose flag would be a great idea.  Do you want to volunteer to add 
it?   Could be a good way to get to know the code base.

Thanks,
-Alex

On 6/28/18, 2:01 AM, "Frost, Andrew"  wrote:

Yes I just tried with your config file, I don't get anything hanging 
although I've got a later Flex SDK so some of the paths/SWC files you're 
including from that are coming up with errors..

Maybe it's worth a slightly more verbose output from the compiler so that 
we can see how far it's getting.. Alex would you think it's worth doing 
something 'official' with a -verbose flag, in case this sort of thing needs to 
be examined in the future? Or it could just be a one-off hack (or using the 
Eclipse debugger to walk through the compilation process to find the issue..).

thanks

   Andrew


-Original Message-
From: chembali [mailto:chemb...@hotmail.com] 
Sent: 28 June 2018 09:46
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Migrating Enterprise Flex Application

I got the nightly build apache-royale-0.9.3-bin-js-swf.zip on June 22. It 
looks like the issue may not be related to the flex-config.xml. I tried to 
compile another component source and it went ahead and compiled the component 
giving a bunch of compile errors. It did not hang though.



--
Sent from: 
https://clicktime.symantec.com/a/1/orlsiMBzJdC4naKh6jmNWDWIZmfWyRE1hh7_nu4ox48=?d=Tm5ZtgpweIf0znthMCpBeAN9sj7fPueHiDeEtJgEISAuD7VwIEm9M2EoEjhMAVYj-ffkpw39SdD_q98fffbu5K7l5Zd2z7v3LlVQF-7SBkS6gEHHjCsKOgUdEHF9wxG8fm0yMRUHzNjW2UGPNIzdrPWZUesebtTvkD7pPivlBG9ggkc-e7l3veOXJuhOdJymoYw7bXI-kgTbVlOgFkScaW6zEk55ObigVzqNmQgcUIlEBdV3MBQJPaaADxXywFepvZmAncyqtmOmVeo5x3ufl7nnmIly3yDkcK9Y9W66cFZAgPt_nTrdL0_rLfbt0CvMaEV0wQy_hGL_DHSEs_B2jH5u1v00Kv3rC2GBHv0EufuSiUPDh0NC9X40NoGMW470gz5u4ys9y7_eBvAZwKA1mlQ5eoQXcJy3dJJGdVmHRypC0mvP&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fclicktime.symantec.com%252Fa%252F1%252Fw8-0aepjtghwJrEW5GLyuRkoS-VeQzvX48OL59I1DMk%253D%253Fd%253DOjYvciyyDRLwFT_tUfjYlUA--SsRn5GZapZJdWKYQ6H7T8y5egtT4QsxyO4aNl92BLSp4rGFrBlHLq4Ta6VcLODkcYMaZ7MizXNd0fVujSh3fpenzlFPXntcVkYsWIzK81EpCYgYYMdkM_P4LuDAswrmxQiWPSdBuZOe7tUeI0kiHPX5SAy068B1zgf1H10LmvV8EwdZHLsrXn-GRsOKejIuZ6IVREqX3oz-aAfWWAS_N8JlWMMhtfiv8fpqyp6ci46w4XK4cOLoL3nMdYPPEEIdRbvkJqfDb0tnVNJV2w7I50xWcHCVmVaTDQn-25XAymk5OWyDvZNKi0cyNKrfNmGBUWMa-XqlVtd1aPCkLt0izrYZLRIJkDvsEPH1YVlXPL2mMYgN5DFZzuvASlDHTwIsdZzgb5Yx3w%25253D%25253D%2526u%253Dhttp%25253A%25252F%25252Fapache-royale-development.20373.n8.nabble.com%25252F%26data%3D02%257C01%257Caharui%2540adobe.com%257Ce60151af4e8f4a95110908d5dcd5abf0%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C1%257C636657732626882909%26sdata%3Dw5MQHFUNnBLFfQHJoY2X%252FsgP2AJrTmRj2TugHEIdqf0%253D%26reserved%3D0

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Okay here's the conclusion:

JSRoyaleEmitter.isDateProperty() is returning false now, because we do actually 
have a definition for the property name (rightDef is no longer null, so we 
don't go into the next check..).

isDateProperty() is called from three places (BinaryOperatorEmitter, 
MemberAccessEmitter, VarDeclarationEmitter) but then where necessary it uses 
the actual DatePropertiesSetters/Getters lists to convert the output.

Given that we don't have any other properties on the Date object, it should be 
feasible to add an extra condition under the "rightDef instanceof 
AccessorDefinition", to also check "rightDef instanceof VariableDefinition" and 
return true (unless people think we should also go through the 
DatePropertiesSetters/Getters lists to double-check that it's a property that 
can be converted?)

This now works: so with the changes to the missing.js, we also have:
if (leftDef != null && 
leftDef.getQualifiedName().equals("Date"))
{
if (rightDef instanceof AccessorDefinition)
return true;
+   else if (rightDef instanceof VariableDefinition)
+   return true;
else if (rightDef == null && 
rightNode.getNodeID() == ASTNodeID.IdentifierID)
{
if (writeAccess)
{

and it works...



thanks

   Andrew


-Original Message-
From: Frost, Andrew [mailto:andrew.fr...@harman.com] 
Sent: 28 June 2018 19:37
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Hi

Thanks Alex for the explanation and background! Yes I think that the 
BinaryOperatorEmitter code is kicking in to do the actual conversion during the 
emitting phase, so that bit works fine; it was just earlier on (and as you 
suggest, a think it's trying to build some ABC from the parsed tree which is 
where this issue came up - ASCompilationUnit.handleABCBytesRequest is lower 
down the call stack..)

I hadn't spotted the 'missing.js' file; presumably then, this is compiled into 
the js.swc file ...

First try: I just added the blank definition "Date.prototype.fullYear;" to the 
bottom of missing.js per Harbs' suggestion, and built js.swc again (had to 
manually then copy it into the royale-asjs folder?); this solved the 
compilation error but then I think the later conversion to getFullYear() didn't 
work as this returned "undefined" when I called it...

Second try: adding the below to missing.js:
Date.prototype.__defineGetter__("fullYear", function() { return 
this.getFullYear(); }); just didn't work; the generated SWC file didn't include 
any properties on the Date object.

I've tried a couple of other things but I'm not sure how it would be possible 
to add separate get/set methods using this mechanism.. or maybe the translation 
needs to change so that it has higher priority?

I'll do a little more digging, unless anyone knows how we could map different 
functions to the set/get methods? Maybe with the below updates, it makes more 
sense to change the specialCaseDate function..

thanks

   Andrew


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com]
Sent: 28 June 2018 19:31
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Yes. That sounds like a good solution to me.

Adding:
/**
 * @type {number}
 */
Date.prototype.time;

/**
 * @type {number}
 */
Date.prototype.fullYear;

Etc… to missing.js should do it.

Harbs

> On Jun 28, 2018, at 8:36 PM, Alex Harui  wrote:
> 
> It's only been the past year or so that we've got the "JS Only" configuration 
> working where you compile against js.swc instead of playerglobal.  And I 
> suspect that nobody has tried Date until you just did.  We could say that, if 
> you are compiling against js.swc you are expected to use the APIs for the 
> browser and can't use Date.fullYear, but because specialCaseDate already 
> exists, we have the choice of adding Date.fullYear to the missing.js file in 
> royale-typedefs/js/src/main/javascript.  Then I think you would be allowed to 
> use Date.fullYear and it would get transpiled correctly.
> 
> I don't see any harm in adding SWF APIs to js.swc if we know how to transpile 
> them.  What do others think?  It would be great if you could give that a try.

RE: Migrating Enterprise Flex Application

[Frost, Andrew]

Hi again

Having looked briefly: there is a 'verbose' option already (but it's hidden); 
but it only changes a couple of outputs (of theme information in MXMLC.java). I 
am wondering whether a number of levels would be good rather than just "verbose 
or not", but perhaps that's over-complicating it...

The easiest way to do this would be to use a class with a static function to do 
all the output. Currently there are calls to "System.out.println" dotted 
throughout the code, so we could switch these all to "CompilerOutput.println", 
and have a new "CompilerOutput.verbose()" method too... 

Any objections to a class with a static member function for this? i.e. a global 
function :-)

cheers

   Andrew


-Original Message-
From: Frost, Andrew [mailto:andrew.fr...@harman.com] 
Sent: 28 June 2018 19:38
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Migrating Enterprise Flex Application

Sure thing, we'll take a look at this... 

-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 28 June 2018 17:57
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Migrating Enterprise Flex Application

Hi Andrew,

Yes, a --verbose flag would be a great idea.  Do you want to volunteer to add 
it?   Could be a good way to get to know the code base.

Thanks,
-Alex

On 6/28/18, 2:01 AM, "Frost, Andrew"  wrote:

Yes I just tried with your config file, I don't get anything hanging 
although I've got a later Flex SDK so some of the paths/SWC files you're 
including from that are coming up with errors..

Maybe it's worth a slightly more verbose output from the compiler so that 
we can see how far it's getting.. Alex would you think it's worth doing 
something 'official' with a -verbose flag, in case this sort of thing needs to 
be examined in the future? Or it could just be a one-off hack (or using the 
Eclipse debugger to walk through the compilation process to find the issue..).

thanks

   Andrew


-Original Message-
From: chembali [mailto:chemb...@hotmail.com] 
Sent: 28 June 2018 09:46
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Migrating Enterprise Flex Application

I got the nightly build apache-royale-0.9.3-bin-js-swf.zip on June 22. It 
looks like the issue may not be related to the flex-config.xml. I tried to 
compile another component source and it went ahead and compiled the component 
giving a bunch of compile errors. It did not hang though.



--
Sent from: 
https://clicktime.symantec.com/a/1/orlsiMBzJdC4naKh6jmNWDWIZmfWyRE1hh7_nu4ox48=?d=Tm5ZtgpweIf0znthMCpBeAN9sj7fPueHiDeEtJgEISAuD7VwIEm9M2EoEjhMAVYj-ffkpw39SdD_q98fffbu5K7l5Zd2z7v3LlVQF-7SBkS6gEHHjCsKOgUdEHF9wxG8fm0yMRUHzNjW2UGPNIzdrPWZUesebtTvkD7pPivlBG9ggkc-e7l3veOXJuhOdJymoYw7bXI-kgTbVlOgFkScaW6zEk55ObigVzqNmQgcUIlEBdV3MBQJPaaADxXywFepvZmAncyqtmOmVeo5x3ufl7nnmIly3yDkcK9Y9W66cFZAgPt_nTrdL0_rLfbt0CvMaEV0wQy_hGL_DHSEs_B2jH5u1v00Kv3rC2GBHv0EufuSiUPDh0NC9X40NoGMW470gz5u4ys9y7_eBvAZwKA1mlQ5eoQXcJy3dJJGdVmHRypC0mvP&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fclicktime.symantec.com%252Fa%252F1%252Fw8-0aepjtghwJrEW5GLyuRkoS-VeQzvX48OL59I1DMk%253D%253Fd%253DOjYvciyyDRLwFT_tUfjYlUA--SsRn5GZapZJdWKYQ6H7T8y5egtT4QsxyO4aNl92BLSp4rGFrBlHLq4Ta6VcLODkcYMaZ7MizXNd0fVujSh3fpenzlFPXntcVkYsWIzK81EpCYgYYMdkM_P4LuDAswrmxQiWPSdBuZOe7tUeI0kiHPX5SAy068B1zgf1H10LmvV8EwdZHLsrXn-GRsOKejIuZ6IVREqX3oz-aAfWWAS_N8JlWMMhtfiv8fpqyp6ci46w4XK4cOLoL3nMdYPPEEIdRbvkJqfDb0tnVNJV2w7I50xWcHCVmVaTDQn-25XAymk5OWyDvZNKi0cyNKrfNmGBUWMa-XqlVtd1aPCkLt0izrYZLRIJkDvsEPH1YVlXPL2mMYgN5DFZzuvASlDHTwIsdZzgb5Yx3w%25253D%25253D%2526u%253Dhttp%25253A%25252F%25252Fapache-royale-development.20373.n8.nabble.com%25252F%26data%3D02%257C01%257Caharui%2540adobe.com%257Ce60151af4e8f4a95110908d5dcd5abf0%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C1%257C636657732626882909%26sdata%3Dw5MQHFUNnBLFfQHJoY2X%252FsgP2AJrTmRj2TugHEIdqf0%253D%26reserved%3D0

RE: Migrating Enterprise Flex Application

[Frost, Andrew]

Hi

The MXML looks fine, but of course that will be pulling in some of your other 
AS classes which is where the problem might lie. 

I think you'll need to continue the divide-and-conquer approach by trying it 
without other bits e.g. take out the FilterAndMainContainer object, script back 
the attributes for the ResizableTitleWindow, etc.

If the below XML still fails then I'd suggest the error is within your 
ResizableTitleWindow ActionScript class:

http://www.adobe.com/2006/mxml";
  
xmlns:filter="com.infogix.iitap.component.flexuiplatform.controls.filter.*">



Probably you'll find/fix the issue before we manage to get any useful verbose 
compiler output set up...!

thanks

   Andrew


-Original Message-
From: chembali [mailto:chemb...@hotmail.com] 
Sent: 29 June 2018 05:43
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Migrating Enterprise Flex Application

I narrowed the compiler hanging issue down to one mxml file in my source. It is 
hanging during the compilation of the below mxml file. I removed this file from 
the source and the compiling seems to be fine. Here is the mxml file for your 
reference. I couldn't notice anything that could cause the compile to hang. 
Please share your thoughts.

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Yes - it needed changes both in the typedefs and in the compiler; and also, 
this is just to workaround the syntax checking part, as the conversion that was 
already present will now kick in..

Did a few tests on it and noticed that I could assign to the timezoneOffset 
[read-only] property, although nothing actually happened when I did so. So I've 
added a check for this one, it feels a bit manual/hacky but I don't know of any 
alternative approach..

Pull requests just created on the typedefs and the compiler projects; they 
should really be taken together otherwise it could get problematic!

thanks

   Andrew


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 28 June 2018 22:17
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

I think Andrew got it right, but I believe he is still adding fullYear and 
others to Date in missing.js.  It is ok for us to add APIs that exist in Flash 
that don't exist in the browser if we map them to browser APIs that do exist.  
In this case, the browser's Date.getFullYear/setFullYear.  No polyfill is 
needed.  We have done this sort of thing for other mismatches between Flash and 
the browser.  It is smaller/faster to handle these known builtin APIs in the 
compiler than to create polyfills for them when we can.  But Language does 
contain some polyfills for Array.

The reason Andrew had to add the lines he did is because in externs/typedefs 
like missing.js, the only way to specify an Accessor (a getter/setter) is by 
having a corresponding definition in an interface in the externs.  Date doesn't 
implement any interfaces, so the definition ends up as a Variable (a var).  The 
code for isDateProperty was expecting the Flash definition of Date which does 
have fullYear and all other properties as Accessor.  I think it was reasonable 
to allow Variables as well.

Andrew, if you can package up your changes as patches or pull requests, that 
would be great.  I probably won't be able to get to it until Sunday, but maybe 
someone else will accept your changes.

Thanks,
-Alex

On 6/28/18, 12:14 PM, "Harbs"  wrote:

It sounds like you’re right and adding it to the Date definitions in 
missing.js is not the right way to go about it. That assumes it’s defined in 
the browser which it’s not… The only way that would work would be to polypill 
the global Date object which we don’t want to do.

I’m guessing something along the lines of your original suggestion is the 
right way to go about it, but I’m definitely not an expert on the compiler.

Thanks,
Harbs
    
    > On Jun 28, 2018, at 10:07 PM, Frost, Andrew  
wrote:
> 
> Okay here's the conclusion:
> 
> JSRoyaleEmitter.isDateProperty() is returning false now, because we do 
actually have a definition for the property name (rightDef is no longer null, 
so we don't go into the next check..).
> 
> isDateProperty() is called from three places (BinaryOperatorEmitter, 
MemberAccessEmitter, VarDeclarationEmitter) but then where necessary it uses 
the actual DatePropertiesSetters/Getters lists to convert the output.
> 
> Given that we don't have any other properties on the Date object, it 
should be feasible to add an extra condition under the "rightDef instanceof 
AccessorDefinition", to also check "rightDef instanceof VariableDefinition" and 
return true (unless people think we should also go through the 
DatePropertiesSetters/Getters lists to double-check that it's a property that 
can be converted?)
> 
> This now works: so with the changes to the missing.js, we also have:
>   if (leftDef != null && 
leftDef.getQualifiedName().equals("Date"))
>   {
>   if (rightDef instanceof AccessorDefinition)
>   return true;
> + else if (rightDef instanceof VariableDefinition)
> + return true;
>   else if (rightDef == null && 
rightNode.getNodeID() == ASTNodeID.IdentifierID)
>   {
>   if (writeAccess)
>       {
> 
> and it works...
> 
> 
> 
> thanks
> 
>   Andrew
> 
> 
> -Original Message-
> From: Frost, Andrew [mailto:andrew.fr...@harman.com] 
> Sent: 28 June 2018 19:37
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc
> 
> Hi
> 
> Thanks Alex for the explanation and background! Yes I think that the 
BinaryOperatorEmitter code is kic

Re: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

".. not yet" is probably the most appropriate response!!

I had wondered whether it would need some formal self-tests adding, I'll have a 
dig around to see how to do this bit :-)

thanks

   Andrew


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 29 June 2018 13:35
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Cool. Are there compiler tests for these Date additions?

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Hi

Those date tests already test the mapping, and are running fine. They're not 
getting stuck at the earlier stage which is where the original problem lay. So 
I'd been thinking of adding a new test file under the below folder, where other 
AS-specific testing is happening:
royale-compiler/compiler/src/test/java/as

In terms of the read-only properties, I would have hoped that the definition in 
missing.js could be written:
/**
 * @type {number}
 * @property
 * @readonly
 */
Date.prototype.timezoneOffset;

but the JSDoc parser isn't able to pick up/report upon the 'property' or 
'readonly' usage. We could add support for these perhaps, manually within the 
FieldReference.java file (which is where these properties are coming in 
currently) we could manually look for the "@property" and/or "@readonly" tags 
within the comment.getOriginalCommentString() value; I would have preferred to 
be able to call "comment.isReadOnly" or similar, but to get to that requires 
changing Google's code..

So yes, hold off doing anything with the pull requests for now, I'll see 
whether I can get it to do things from the typedefs side of things...

One extra note: I'm finding two "missing.js" files which aren't being kept in 
sync at all (by the build tools); is this by design or should there be some 
kind of a link between them?
royale-typedefs\js\src\main\javascript\missing.js
royale-compiler\compiler-externc\src\test\resources\typedefs\unit_tests\missing.js


thanks

   Andrew



-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 29 June 2018 17:38
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

There are Date tests in TestRoyaleGlobalClasses.java

In this case, the issue may be in how to set up a copy of the tests to work 
with js.swc instead of playerglobal.swc.

Regarding read-only properties, I think the externc compiler might have a way 
of doing that.  It would likely involve one of the JSDoc annotations or an 
interface.  And the result should be a getter without a setter.  I don't have 
time to look for it right now.  It would be best to deal with this in the 
typedefs instead of in the compiler, IMO.

My 2 cents,
-Alex

On 6/29/18, 7:47 AM, "Frost, Andrew"  wrote:

".. not yet" is probably the most appropriate response!!

I had wondered whether it would need some formal self-tests adding, I'll 
have a dig around to see how to do this bit :-)

thanks

   Andrew


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 29 June 2018 13:35
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Cool. Are there compiler tests for these Date additions?

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Hi

Well @const is at least supported by the Google classes; with a slight change 
in FieldReference.java to actually set the internal flag ("this.isConst = 
comment.hasConstAnnotation();") then it changes the ActionScript declaration so 
that it's now:
public const timezoneOffset:Number = 13;

And when you try to assign to it, you get 
TestRoyale.mxml(38): col: 5 Error: Illegal assignment to a variable specified 
as constant.
date.timezoneOffset = 55;
^

So it kind of works in flagging up a bad bit of code, but from an ActionScript 
perspective it's not right, we should be getting an 
"AssignToReadOnlyPropertyProblem" rather than an "AssignToConstProblem".

The options as I see it:
1) live with this as a slightly incorrect warning, as it's very unlikely to 
happen (shouldn't occur in the AS3 code to start with assuming that compiles 
already in Flex) and it's the simplest/most elegant change
2) have specific code in the SemanticUtils class which knows about this 
particular Date property and is looking out for it by name ... not very 
efficient and something of a hack!
3) extend the closure compiler to support some of the other JSDoc annotations 
so that we can generate property getters/setters and create read-only 
properties. Possibly the most "correct" solution but not so good from a 
maintainability perspective if we have to change the Google code...


In terms of testing: as you said, the 'missing.js' in the royale-compiler 
folders is for the compiler's testing, so if we add extra testing for the 
compiler with these new properties then we need that file to also include those 
extra Date things. I guess it's not a massive maintenance issue if these files 
are hardly ever changing.. I just wanted to be sure I wasn't missing some step 
in the process that did an automatic sync from one to the other. The same is 
true of the js.swc, it's being generated in the royale-typedefs folder and 
currently I'm manually copying it to the royale-asjs folder... but for that 
one, there must be something that copies it over, as that js/lib folder doesn't 
exist in the original source!


thanks

   Andrew



-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 30 June 2018 07:19
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Interesting.  In 
https://clicktime.symantec.com/a/1/untftVdsWwPmiJWAVt3nm3wg6v4ZACZ9RDBNQjuszM0=?d=bbejT-O_-jFYytoEIpecgb-HW7JAfVy-JYJKJjpirj9WyJta8y-Vetrzg91hMyjxwIZDBbGoPRETuW8R-_GJ2QI3JFRNDooGe4nnEJmgsbOCgX9zvdpNOtRejsS_vQ96JFtVBei96NlGXnAeb9O-n2UPHrthFwLfNhxhivyLhutMuYZf1_Bwf9uhuogWi4XEGnREN0VeGK-7HR-0IXBlFkwvMeyJ_r7KS89xbvNmYhN1EFExUVrPWOSGUU7bDbqQGwx_iQnLVTX8Lj1IsNPJvd8qUgJnR5R6P-smt5q_FBaLNjsRWDWI0U_XMUyRIY_5-Kz1H2BKLxZppDcoEdbSVn_k9bD-Eo7722e3Jajt9nKt5EOvpU8kzNvIgbQxRNW4JbQ0gyaaZG-838aZUMmtuoW39NTiDdhoowZejUVmDmKstEs8NbBBtOnE3Ck%3D&u=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler
 it mentions @const as the annotation.  That might already work and if not, we 
should probably make it work.

The missing.js in royale-compiler is just there to get the compiler's tests to 
run.  The royale-typedefs repo has a dependency on royale-compiler, so we can't 
create a circular dependency by having royale-compiler require royale-typedefs 
missing.js.  They don't need to be kept in sync.  The royale-compiler version 
should be minimal.  The one in royale-typedefs is intended to make a library 
with the right and complete Browser APIs.

HTH,
-Alex

On 6/29/18, 3:55 PM, "Frost, Andrew"  wrote:

Hi

Those date tests already test the mapping, and are running fine. They're 
not getting stuck at the earlier stage which is where the original problem lay. 
So I'd been thinking of adding a new test file under the below folder, where 
other AS-specific testing is happening:
royale-compiler/compiler/src/test/java/as

In terms of the read-only properties, I would have hoped that the 
definition in missing.js could be written:
/**
 * @type {number}
 * @property
 * @readonly
 */
Date.prototype.timezoneOffset;

but the JSDoc parser isn't able to pick up/report upon the 'property' or 
'readonly' usage. We could add support for these perhaps, manually within the 
FieldReference.java file (which is where these properties are coming in 
currently) we could manually look for the "@property" and/or "@readonly" tags 
within the comment.getOriginalCommentString() value; I would have preferred to 
be able to call "comment.isReadOnly" or similar, but to get to that requires 
changing Google's code..

So yes, hold off doing anything with the pull request

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Hi

Even if we get the latest version, they still don't support a "readonly" 
annotation:
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/parsing/Annotation.java
lists the ones that are supported.

And I tried updating to the newest jar file, got some weird errors so I think 
that way would lead to a lot more work.

We do get the original Javadoc comment come into our parsing function, so we 
could do a free-text search for "@readonly" within this? Might be the simplest 
route until(?) Google add this support properly..

Alternatively you suggest using ExternCConfiguration: having looked into this, 
I think the process would be:
1) update the externc-config.xml file to include something like 
DatetimezoneOffset 
 (so a bit like the "exclude" list where we don't include things like 
Array.toSource etc)
2) update the ExternCConfiguration.java file to handle this input field (like 
the "setExcludes" handler for the "exclude" mapping..) and put in place a new 
"ReadOnlyMember" element and list to hold this
3) in the FieldReference.emit() method, check if this element is in the 
read-only property list; if it is, treat it like an accessor but only with a 
'get' method.

So I'm thinking this latter approach is a nicer one and fits more with the rest 
of how things are done... I'll update the pull requests later on after running 
through this and also adding some tests...

cheers

   Andrew



-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 30 June 2018 08:00
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Yeah, if @const becomes const in AS, that probably isn't right.

I just found this:  
https://clicktime.symantec.com/a/1/t8Vt55bBn1paDRrO_tcbGDw3nOt-4_f5sEQDRaUr78g=?d=lhuiLMs5TaNvmSSfvLo9lH6b9M276TThXO9G60OlPgOsY0f-pENIrkec8khCn7viL4JfEe1fvVJVaiQjQh6BhiYP7C_O9RJunWasASxHmucjtZZQBzeCviGxf9lrMUs0zxkkPNHBoa_rq8QP8-dOSlYcneP9T5WOgjLYBeKsizspqFWxP5Szt6O6GYS1QKNQtcPvwoh5NSOLYeB2K3j46FeJyZfM51xmX1vX4JN5xKWd1bY4mOAK6B9Kr7A2u6i65r0iSYuzL8ok9ybJXKGK43QxR_nahrgFSKD2Bg-0iMujUKi8uNlZ5kOGSzi3oE0ByPCbF-4QIZtYTa3V7zQ1AaG4rQnICykl0p0UohbhZZrVdA2536sB_xwCGEKvHXA0Hf5_evEzsPHoxiB5HeyKiYQW8vzNmmT3CSqOKfakgQLVd_4l5xMYQ7AeYmU%3D&u=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fissues%2F139
I don't have time to investigate further right now, so if you have time that 
would be great.  We might need to update which version of Google Closure we are 
using.

Regarding the options you listed, I think goal is to generate the right AS 
classes with a getter and no setter.  If Google still doesn't handle @readonly, 
we could add a field to the ExternCConfiguration where you specify which APIs 
should be read-only and correct the output AS.

HTH,
-Alex

On 6/29/18, 11:46 PM, "Frost, Andrew"  wrote:

Hi

Well @const is at least supported by the Google classes; with a slight 
change in FieldReference.java to actually set the internal flag ("this.isConst 
= comment.hasConstAnnotation();") then it changes the ActionScript declaration 
so that it's now:
public const timezoneOffset:Number = 13;

And when you try to assign to it, you get 
TestRoyale.mxml(38): col: 5 Error: Illegal assignment to a variable 
specified as constant.
date.timezoneOffset = 55;
^

So it kind of works in flagging up a bad bit of code, but from an 
ActionScript perspective it's not right, we should be getting an 
"AssignToReadOnlyPropertyProblem" rather than an "AssignToConstProblem".

The options as I see it:
1) live with this as a slightly incorrect warning, as it's very unlikely to 
happen (shouldn't occur in the AS3 code to start with assuming that compiles 
already in Flex) and it's the simplest/most elegant change
2) have specific code in the SemanticUtils class which knows about this 
particular Date property and is looking out for it by name ... not very 
efficient and something of a hack!
3) extend the closure compiler to support some of the other JSDoc 
annotations so that we can generate property getters/setters and create 
read-only properties. Possibly the most "correct" solution but not so good from 
a maintainability perspective if we have to change the Google code...


In terms of testing: as you said, the 'missing.js' in the royale-compiler 
folders is for the compiler's testing, so if we add extra testing for the 
compiler with these new properties then we need that file to also include those 
extra Date things. I guess it's not a massive maintenance issue if these files 
are hardly ever changing.. I just wanted to be sure I wasn't missing some step 
in the process that did an automatic 

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Latest on this:

With the changes in the compiler per the below suggestion (externc-config.xml 
and ExternCConfiguration changes), we can generate the below code (as extracted 
from js.swc):

public function get timezoneOffset():Number{
return (null);
}

And everything looks good... works well, we get the right warning out when we 
try to assign a value to timezoneOffset.
Changes are visible in 
https://github.com/ajwfrost/royale-compiler/commit/8157465fbe05022136ae7b405f316e89ee809c97
but I've not yet created the pull request on this project..


In terms of testing: to properly test this, we need to add an external test for 
it (i.e. running through the full compile sequence), so I looked at where there 
are some current tests that do this:
royale-compiler\compiler\src\test\java\as\ASExpressionTests.java etc
and then copy/pasted one of these into a new file "ASDateTests.java". However 
this is causing weird errors: when I build the royale-compiler project without 
this file, I get:

tests:
[junit] Running as.ASExpressionTests
[junit] looking for C:\Work\Royale\royale-compiler\env.properties
[junit] environment property - FLEX_HOME = null
[junit] environment property - PLAYERGLOBAL_HOME = null
[junit] environment property - PLAYERGLOBAL_VERSION = 11.1
[junit] environment property - TLF_HOME = null
[junit] environment property - AIR_HOME = null
[junit] environment property - FLASHPLAYER_DEBUGGER = null
[junit] environment property - ASJS_HOME = C:\Work\Royale\royale-asjs
[junit] environment property - GOOG_HOME = null
[junit] Generating test:
[junit] Compiling test:
[junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests7333543909053470191.as
 
[junit] 
[junit] 608 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests7333543909053470191.swf
 in 0.817 seconds
[junit] After compile:
[junit] Unexpected compilation problems:
[junit] 
[junit] Generating test:
[junit] Compiling test:
[junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests3291256200729799168.as
 
[junit] 
[junit] 595 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests3291256200729799168.swf
 in 0.112 seconds
[junit] After compile:
[junit] Unexpected compilation problems:
 ... 
[junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.493 sec
The "unexpected compilation problems" seem to be 'expected' as the result is 
that the tests all pass..

But when I have a new file ASDateTests.java, I get:
tests:
[junit] Running as.ASDateTests
[junit] looking for C:\Work\Royale\royale-compiler\env.properties
[junit] environment property - FLEX_HOME = null
[junit] environment property - PLAYERGLOBAL_HOME = null
[junit] environment property - PLAYERGLOBAL_VERSION = 11.1
[junit] environment property - TLF_HOME = null
[junit] environment property - AIR_HOME = null
[junit] environment property - FLASHPLAYER_DEBUGGER = null
[junit] environment property - ASJS_HOME = C:\Work\Royale\royale-asjs
[junit] environment property - GOOG_HOME = null
[junit] Generating test:
[junit] Compiling test:
[junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASDateTests3525997529829206058.as
 
[junit] 
[junit] 592 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASDateTests3525997529829206058.swf
 in 0.853 seconds
[junit] After compile:
[junit] Unexpected compilation problems:
[junit] 
[junit] as_ASDateTests_ASDateTests_simpleTernary_swfdump.xml
[junit] 
[junit] 
.. there follows a dump of the SWF contents ...
[junit] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 
1.725 sec


I'm not sure why it's treating my new file differently from the existing ones 
... any hints/thoughts?! It seems like all I have to do to include these tests 
is to create this file in the relevant folder, but maybe there's another step 
that I'm missing?

thanks

   Andrew




-Original Message-
From: Frost, Andrew [mailto:andrew.fr...@harman.com] 
Sent: 02 July 2018 10:14
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Royale compiler not handling Date.fullYear etc

Hi

Even if we get the latest version, they still don't support a "readonly" 
annotation:
https://clicktime.symantec.com/a/1/T83CUIducqI9Lkpsqh8xgxVIyLMGnJbMonLa5_1_9kg=?d=a9uxnQqkSmG7oTXapoG51ZcBcs2YQHVAyX7jtig52n_nvBCIyavSa7KScNwp1Pl-KH

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Ah - thank you! Will look at that later and create a pull request once 
everything is in there and testing itself properly..

cheers

   Andrew


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 02 July 2018 16:51
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Ah yes, the swfdumps...

So when tests that produce a SWF run without the Flash playerglobal and 
standalone debugger, the test harness runs SWFDump and compares the output.  
The reference copies of the swfdumps are in 
compiler/src/test/resources/swfdumps and the files have a naming scheme I hope 
you can decode.  So, when you add a new test and it can't find the reference 
swfdump, it will dump what it found to make it easy for you to copy the swfdump 
and make it the reference copy.  So copy the console output of the swfdump and 
create the reference file and it should be ok after that.

Thanks,
-Alex

On 7/2/18, 8:42 AM, "Frost, Andrew"  wrote:

Latest on this:

With the changes in the compiler per the below suggestion 
(externc-config.xml and ExternCConfiguration changes), we can generate the 
below code (as extracted from js.swc):

public function get timezoneOffset():Number{
return (null);
}

And everything looks good... works well, we get the right warning out when 
we try to assign a value to timezoneOffset.
Changes are visible in 
https://clicktime.symantec.com/a/1/wviiW6QxLi8ypSnU5H09X2xjni7YMbYvK77LEkO5CDc=?d=_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo34PLSaC9n5J08tWjYr684YeBkkWxnp2HcZdkgNzuQomI_AxW87-eGOUJ6BX3fpIq_85GevpLOLDtImXR9QSgOqRr8CPPdoqGLktBiwqfyZgvoybKudC2IK3zCmJoehcWoBmeXjp5BYTa2y0nIyvPd5uIG0WYm3JsJ2SYir9Lo6eyi-l_jT5qujCB9duN6TZDMw6d3nk9CU1DUlTgmpu8sTVpksO772_ZC0g-UQ0XAwzNaKvyauEqoa7Dn0h61XfQp5AqHmj6fdgrYEtUrlQQYC5UE3i8HxOcaCgOYGOEQ1GClok3NDQMETE1dyjN20C1N_Z-dWb1-qNMzyGi732Hk-nT_kq4IjD3YDuNeJwtk0wYZ42ik8c4M-nNHDMcZJfnVJf9_MWpQBY7o3JH2Vdg%3D%3D&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fajwfrost%252Froyale-compiler%252Fcommit%252F8157465fbe05022136ae7b405f316e89ee809c97%26data%3D02%257C01%257Caharui%2540adobe.com%257C71b34e8a1cca401a8f6d08d5e032645e%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636661429411013521%26sdata%3D6DNQpiY0msNOA2%252Fj0CiWEvv94X1JfDIacwOlm9nzqqE%253D%26reserved%3D0
but I've not yet created the pull request on this project..


In terms of testing: to properly test this, we need to add an external test 
for it (i.e. running through the full compile sequence), so I looked at where 
there are some current tests that do this:
royale-compiler\compiler\src\test\java\as\ASExpressionTests.java etc
and then copy/pasted one of these into a new file "ASDateTests.java". 
However this is causing weird errors: when I build the royale-compiler project 
without this file, I get:

tests:
[junit] Running as.ASExpressionTests
[junit] looking for C:\Work\Royale\royale-compiler\env.properties
[junit] environment property - FLEX_HOME = null
[junit] environment property - PLAYERGLOBAL_HOME = null
[junit] environment property - PLAYERGLOBAL_VERSION = 11.1
[junit] environment property - TLF_HOME = null
[junit] environment property - AIR_HOME = null
[junit] environment property - FLASHPLAYER_DEBUGGER = null
[junit] environment property - ASJS_HOME = C:\Work\Royale\royale-asjs
[junit] environment property - GOOG_HOME = null
[junit] Generating test:
[junit] Compiling test:
[junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests7333543909053470191.as
 
[junit] 
[junit] 608 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests7333543909053470191.swf
 in 0.817 seconds
[junit] After compile:
[junit] Unexpected compilation problems:
[junit] 
[junit] Generating test:
[junit] Compiling test:
[junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests3291256200729799168.as
 
[junit] 
[junit] 595 bytes written to 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp\ASExpressionTests3291256200729799168.swf
 in 0.112 seconds
[junit] After compile:
[junit] Unexpected compilation problems:
 ... 
[junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.493 sec
The "unexpected compilation problems" seem to be 'expected' as the result 
is that the tests all pass..

But when I have a new file ASDateTests.java, I get:
tests:

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Another update: the swfdumps are all done and it's all working fine and testing 
itself properly, I had to change another externc-config.xml file along with the 
other missing.js file to ensure that the 'testing' libraries are [roughly] 
equivalent to the actual files used in compilation..

Seems to be working to me and, I hope, is an acceptable solution. It required a 
lot more changes than I'd originally thought!

Pull requests are:
Typedefs: https://github.com/apache/royale-typedefs/pull/2
Compiler: https://github.com/apache/royale-compiler/pull/46

If you have the typedefs changes but not the compiler ones, then your Date 
properties will start coming through as undefined, as it will miss the 
transpiling bit where it converts e.g. "date.day" into "date.getDay()"...

Let me know of any issues (or please add to the discussion comments on the pull 
request instead?)

cheers

   Andrew



-Original Message-
From: Frost, Andrew [mailto:andrew.fr...@harman.com] 
Sent: 02 July 2018 16:53
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Royale compiler not handling Date.fullYear etc

Ah - thank you! Will look at that later and create a pull request once 
everything is in there and testing itself properly..

cheers

   Andrew


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 02 July 2018 16:51
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

Ah yes, the swfdumps...

So when tests that produce a SWF run without the Flash playerglobal and 
standalone debugger, the test harness runs SWFDump and compares the output.  
The reference copies of the swfdumps are in 
compiler/src/test/resources/swfdumps and the files have a naming scheme I hope 
you can decode.  So, when you add a new test and it can't find the reference 
swfdump, it will dump what it found to make it easy for you to copy the swfdump 
and make it the reference copy.  So copy the console output of the swfdump and 
create the reference file and it should be ok after that.

Thanks,
-Alex

On 7/2/18, 8:42 AM, "Frost, Andrew"  wrote:

Latest on this:

With the changes in the compiler per the below suggestion 
(externc-config.xml and ExternCConfiguration changes), we can generate the 
below code (as extracted from js.swc):

public function get timezoneOffset():Number{
return (null);
}

And everything looks good... works well, we get the right warning out when 
we try to assign a value to timezoneOffset.
Changes are visible in 
https://clicktime.symantec.com/a/1/wviiW6QxLi8ypSnU5H09X2xjni7YMbYvK77LEkO5CDc=?d=_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo34PLSaC9n5J08tWjYr684YeBkkWxnp2HcZdkgNzuQomI_AxW87-eGOUJ6BX3fpIq_85GevpLOLDtImXR9QSgOqRr8CPPdoqGLktBiwqfyZgvoybKudC2IK3zCmJoehcWoBmeXjp5BYTa2y0nIyvPd5uIG0WYm3JsJ2SYir9Lo6eyi-l_jT5qujCB9duN6TZDMw6d3nk9CU1DUlTgmpu8sTVpksO772_ZC0g-UQ0XAwzNaKvyauEqoa7Dn0h61XfQp5AqHmj6fdgrYEtUrlQQYC5UE3i8HxOcaCgOYGOEQ1GClok3NDQMETE1dyjN20C1N_Z-dWb1-qNMzyGi732Hk-nT_kq4IjD3YDuNeJwtk0wYZ42ik8c4M-nNHDMcZJfnVJf9_MWpQBY7o3JH2Vdg%3D%3D&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fajwfrost%252Froyale-compiler%252Fcommit%252F8157465fbe05022136ae7b405f316e89ee809c97%26data%3D02%257C01%257Caharui%2540adobe.com%257C71b34e8a1cca401a8f6d08d5e032645e%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636661429411013521%26sdata%3D6DNQpiY0msNOA2%252Fj0CiWEvv94X1JfDIacwOlm9nzqqE%253D%26reserved%3D0
but I've not yet created the pull request on this project..


In terms of testing: to properly test this, we need to add an external test 
for it (i.e. running through the full compile sequence), so I looked at where 
there are some current tests that do this:
royale-compiler\compiler\src\test\java\as\ASExpressionTests.java etc
and then copy/pasted one of these into a new file "ASDateTests.java". 
However this is causing weird errors: when I build the royale-compiler project 
without this file, I get:

tests:
[junit] Running as.ASExpressionTests
[junit] looking for C:\Work\Royale\royale-compiler\env.properties
[junit] environment property - FLEX_HOME = null
[junit] environment property - PLAYERGLOBAL_HOME = null
[junit] environment property - PLAYERGLOBAL_VERSION = 11.1
[junit] environment property - TLF_HOME = null
[junit] environment property - AIR_HOME = null
[junit] environment property - FLASHPLAYER_DEBUGGER = null
[junit] environment property - ASJS_HOME = C:\Work\Royale\royale-asjs
[junit] environment property - GOOG_HOME = null
[junit] Generating test:
[junit] Compiling test:
[junit] 
-external-library-path=C:\Work\Royale\royale-compiler\compiler-externc\target\js.swc
 
C:\Work\Royale\royale-compiler\compiler\target\junit-temp

RE: Royale compiler not handling Date.fullYear etc

[Frost, Andrew]

Arg! Sorry, missed those when I was looking at the AS3 documentation...

I've not set my environment up to generate the SWF outputs, I might do that 
just for completion and to try to avoid such issues in the future!

Thanks

   Andrew


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 03 July 2018 17:46
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale compiler not handling Date.fullYear etc

One glitch did show up after the merge, however.  The tests as configured will 
be run against playerglobal.swc for folks who are configured with the Flash/AIR 
SDKs.  I was expecting some other error, but the first thing it caught was that 
Date.day and Date.dayUTC are also read-only (makes sense given that it would 
not be obvious what to do if you change Tuesday to Wednesday.  It could be any 
Wednesday).

So I am going to add those two to the readonly list and update the tests to 
expect errors.  I will probably worry about making this set of tests always run 
against the JS-only config some other day.  Maybe you or some other volunteer 
wants to deal with it.  Probably not that important, IMO.

Anyway, still a great job and thanks for contributing.

-Alex

On 7/3/18, 9:31 AM, "Alex Harui"  wrote:

Hi Andrew,

I just accepted your pull requests.  Great Job!

Yes, I know it was more work than expected, but actually you did a lot more 
than just handle Date APIs.  You provided a way to specify readonly vars in 
externs and provided a pile of new tests.

Hope to see more contributions like these.

Thanks,
-Alex

On 7/3/18, 3:57 AM, "Frost, Andrew"  wrote:

Another update: the swfdumps are all done and it's all working fine and 
testing itself properly, I had to change another externc-config.xml file along 
with the other missing.js file to ensure that the 'testing' libraries are 
[roughly] equivalent to the actual files used in compilation..

Seems to be working to me and, I hope, is an acceptable solution. It 
required a lot more changes than I'd originally thought!

Pull requests are:
Typedefs: 
https://clicktime.symantec.com/a/1/H8du73qyd2P59dgc_NBig5kKS-MSuqeeLzkLnUuGc2g=?d=XVM8wcUx4AVvvnx4aYpF00yk_Eyt9QZZF_c65XW-bGLlOqoBAmP4EZZZHcq3CxBBmKZpgajW8vxVFLmNQUwTkz-h3EmNKlq8UyFiYyklTfyKmivIVAaXa-6Uh22WNmrQPgipIQ5Bl1dYRZXx8v2FZ83ZkYErcY9kwfeFH2td0tJLDs3UuRtInu7Pg3ez7ZpidUYN_NR6xuesnpZ1PdAMKNZA0LhumZmir0NVprDmnsJ1BkaWAy6vXkO3GNuS4KHFrBe1VUQvY5uWuwGnqkMRvZA1N-hVF8cfY4bUQjZbFWjb9oxrU7AbQrtv2GodpVQWdsNUjpiczlfhcvVk8VhPuVjsGma93Tj8zXHuFsMOZxZYg1sTepHUbWoMXGQVGUmK1Jk6EAJ7zyL4lVjxzkNAJ31si4DjoouXLo5Q-D0w0B2oRQ14_ii9MfaNRuJ93qk%3D&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Froyale-typedefs%252Fpull%252F2%26data%3D02%257C01%257Caharui%2540adobe.com%257C23fabd6b67b94e1dc16008d5e0d3d550%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636662122786567530%26sdata%3DQ%252FnpJJ657LMOQFUvytn5k4LWbVVw3YancGcyqU%252F9MSI%253D%26reserved%3D0
Compiler: 
https://clicktime.symantec.com/a/1/7ckP0xBvPXAikG7TS7fGtLEmtYORNspA7ffmJ61oStE=?d=XVM8wcUx4AVvvnx4aYpF00yk_Eyt9QZZF_c65XW-bGLlOqoBAmP4EZZZHcq3CxBBmKZpgajW8vxVFLmNQUwTkz-h3EmNKlq8UyFiYyklTfyKmivIVAaXa-6Uh22WNmrQPgipIQ5Bl1dYRZXx8v2FZ83ZkYErcY9kwfeFH2td0tJLDs3UuRtInu7Pg3ez7ZpidUYN_NR6xuesnpZ1PdAMKNZA0LhumZmir0NVprDmnsJ1BkaWAy6vXkO3GNuS4KHFrBe1VUQvY5uWuwGnqkMRvZA1N-hVF8cfY4bUQjZbFWjb9oxrU7AbQrtv2GodpVQWdsNUjpiczlfhcvVk8VhPuVjsGma93Tj8zXHuFsMOZxZYg1sTepHUbWoMXGQVGUmK1Jk6EAJ7zyL4lVjxzkNAJ31si4DjoouXLo5Q-D0w0B2oRQ14_ii9MfaNRuJ93qk%3D&u=https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Froyale-compiler%252Fpull%252F46%26data%3D02%257C01%257Caharui%2540adobe.com%257C23fabd6b67b94e1dc16008d5e0d3d550%257Cfa7b1b5a7b34438794aed2c178decee1%257C0%257C0%257C636662122786567530%26sdata%3DL%252B3cknwmPbt4rvzFd7sDguzXXNspXHUdnVY4UVIPnW0%253D%26reserved%3D0

If you have the typedefs changes but not the compiler ones, then your 
Date properties will start coming through as undefined, as it will miss the 
transpiling bit where it converts e.g. "date.day" into "date.getDay()"...

Let me know of any issues (or please add to the discussion comments on 
the pull request instead?)

cheers

   Andrew
    
    

-Original Message-
From: Frost, Andrew [mailto:andrew.fr...@harman.com] 
Sent: 02 July 2018 16:53
To: dev@royale.apache.org
Subject: [EXTERNAL] RE: Royale compiler not handling Date.fullYear etc

Ah - thank you! Will look at that later and create a pull request once 
everything is in there and testing itself properly..

cheers

   Andrew


-Original Message-

Query on Royale dependency generation

[Frost, Andrew]

Hi guys

I'd been getting an error when running a simple Royale application:
Uncaught TypeError: Cannot read property 'BIG_ENDIAN' of undefined
at new org.apache.royale.utils.BinaryData (BinaryData.js:28)

the line in question is from the constructor:
org.apache.royale.utils.BinaryData = function(bytes) {
  bytes = typeof bytes !== 'undefined' ? bytes : null;
  this._endian = org.apache.royale.utils.Endian.BIG_ENDIAN;
and "Endian" is undefined.

After a little digging I found this is because the BinaryData object is being 
constructed without the JS engine having knowledge of the "Endian" class: 
something went wrong with the google dependency thing. In my generated html 
page I have a line:
goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
['org.apache.royale.utils.BinaryData'], 
['org.apache.royale.utils.IBinaryDataInput', 
'org.apache.royale.utils.IBinaryDataOutput']);
and if I change this to:
goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
['org.apache.royale.utils.BinaryData'], 
['org.apache.royale.utils.IBinaryDataInput', 
'org.apache.royale.utils.IBinaryDataOutput', 'org.apache.royale.utils.Endian']);
then it works.

Looking at where this comes from in the compiler:
compiler-jx/src/main/java/org/apache/royale/compiler/internal/graph/GoogleDepsWriter.java
function "generateDeps" is creating these lists, and if the "removeCirculars" 
value is true (which it is by default unless changed on the command-line) then 
we add dependencies for the interfaces that we implement (gd.fileInfo.impls) 
and any static dependencies (gd.fileInfo.staticDeps) but we don't add the 
actual dependencies that were calculated (gd.deps or gd.fileInfo.deps - both of 
these contain the Endian definition).

So I can fix my project by updating the compiler to do:
  if (gd.fileInfo.deps != null)
deps.addAll(gd.fileInfo.deps);
and then it works: the generated line though is:
goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
['org.apache.royale.utils.BinaryData'], ['goog.DEBUG', 
'org.apache.royale.utils.Endian', 'org.apache.royale.utils.IBinaryDataInput', 
'org.apache.royale.utils.IBinaryDataOutput']);


So my questions:

  1.  where is the fault here? Am I right in thinking that there's a missing 
set of dependencies that need to also be added per the above snippet, or should 
the Endian definition be listed as a dependency in the gd.fileInfo.staticDeps 
list (which is null for me)
  2.  presumably we don't want "goog.DEBUG" to end up in the dependency list: 
is there a sensible way of getting rid of this (or should we just manually 
filter out anything starting "goog.")?
  3.  if we should be adding these dependencies separately, is there a 
preference for "gd.deps" vs "gd.fileInfo.deps"?

thanks

   Andrew

RE: Query on Royale dependency generation

[Frost, Andrew]

Hi

I'm not using it on my build command line, i.e. it's set as the default 'true'.

If I do set it to 'false' then I get what I would expect from the code, i.e. it 
ignores the interfaces and just outputs the discovered dependencies - including 
the google one:
goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
['org.apache.royale.utils.BinaryData'], ['goog.DEBUG', 
'org.apache.royale.utils.Endian']);

But now I get hundreds of errors from the browser's JS engine e.g. 
IStatesObject.js:42 Uncaught TypeError: Cannot read property 'IEventDispatcher' 
of undefined
at IStatesObject.js:42
(anonymous) @ IStatesObject.js:42
IUIBase.js:58 Uncaught TypeError: Cannot read property 'IEventDispatcher' of 
undefined
at IUIBase.js:58
(anonymous) @ IUIBase.js:58
IBeadModel.js:38 Uncaught TypeError: Cannot read property 'IEventDispatcher' of 
undefined
at IBeadModel.js:38
(anonymous) @ IBeadModel.js:38
Event.js:33 Uncaught TypeError: Cannot read property 'Event' of undefined
at Event.js:33
(anonymous) @ Event.js:33
base.js:2484 Uncaught TypeError: Cannot read property 'prototype' of undefined
at Object.goog.inherits (base.js:2484)
at UIBase.js:44
goog.inherits @ base.js:2484
(anonymous) @ UIBase.js:44
base.js:2484 Uncaught TypeError: Cannot read property 'prototype' of undefined
at Object.goog.inherits (base.js:2484)
at eventtarget.js:96
goog.inherits @ base.js:2484
(anonymous) @ eventtarget.js:96
base.js:2484 Uncaught TypeError: Cannot read property 'prototype' of undefined
at Object.goog.inherits (base.js:2484)
at HTMLElementWrapper.js:28
.


I'm assuming I'm not meant to be editing the html dependency list manually 
(there's another one to change, Namespace.js has a dependency on Language.js 
due to the use of "is") so unless something here is project-specific that's 
changing how it's outputting/parsing the dependencies, I'm not sure what's up.

If anyone has a project that uses BinaryData, are they able to check what they 
see in the generated HTML for that one, to see whether it's just me who doesn't 
have the Endian dependency added..? FWIW I've been trying both with 0.9.2 
downloaded via NPM, and the latest develop branch (well perhaps a week out of 
date now..)

thanks

   Andrew


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 19 July 2018 12:18
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

Are you using the -remove-circulars compiler option?

> On Jul 19, 2018, at 1:05 PM, Frost, Andrew  wrote:
> 
> Hi guys
> 
> I'd been getting an error when running a simple Royale application:
> Uncaught TypeError: Cannot read property 'BIG_ENDIAN' of undefined
>at new org.apache.royale.utils.BinaryData (BinaryData.js:28)
> 
> the line in question is from the constructor:
> org.apache.royale.utils.BinaryData = function(bytes) {  bytes = typeof 
> bytes !== 'undefined' ? bytes : null;  this._endian = 
> org.apache.royale.utils.Endian.BIG_ENDIAN;
> and "Endian" is undefined.
> 
> After a little digging I found this is because the BinaryData object is being 
> constructed without the JS engine having knowledge of the "Endian" class: 
> something went wrong with the google dependency thing. In my generated html 
> page I have a line:
> goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
> ['org.apache.royale.utils.BinaryData'], 
> ['org.apache.royale.utils.IBinaryDataInput', 
> 'org.apache.royale.utils.IBinaryDataOutput']);
> and if I change this to:
> goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
> ['org.apache.royale.utils.BinaryData'], 
> ['org.apache.royale.utils.IBinaryDataInput', 
> 'org.apache.royale.utils.IBinaryDataOutput', 
> 'org.apache.royale.utils.Endian']);
> then it works.
> 
> Looking at where this comes from in the compiler:
> compiler-jx/src/main/java/org/apache/royale/compiler/internal/graph/Go
> ogleDepsWriter.java function "generateDeps" is creating these lists, 
> and if the "removeCirculars" value is true (which it is by default unless 
> changed on the command-line) then we add dependencies for the interfaces that 
> we implement (gd.fileInfo.impls) and any static dependencies 
> (gd.fileInfo.staticDeps) but we don't add the actual dependencies that were 
> calculated (gd.deps or gd.fileInfo.deps - both of these contain the Endian 
> definition).
> 
> So I can fix my project by updating the compiler to do:
>  if (gd.fileInfo.deps != null)
&

RE: Query on Royale dependency generation

[Frost, Andrew]

Hi

Yes (it's weird!) - okay so I just set the -remove-circulars option to true 
explicitly but still no change (from the default).

If you look in your html file, do you get just:
goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
['org.apache.royale.utils.BinaryData'], 
['org.apache.royale.utils.IBinaryDataInput', 
'org.apache.royale.utils.IBinaryDataOutput']);
for the dependencies of it?

In the big list of dependencies at the start, then yes Endian is showing up 
there. BinaryData isn't in that big list, because this is a dependency of 
another of my classes (which is in the list). It's constructor is being called 
because there's a static property being initialised i.e.
static private var _bytes : BinaryData = new BinaryData();


From a bit more digging, the issue (whether it happens or not) seems to be due 
to the order in which the files are loaded; there can be a specific order be 
applied in terms of ensuring that the dependencies are loaded before the 
classes that require them, but there isn't a dependency link between BinaryData 
and Endian (as you can see from your compiled .js files). So without this 
dependency, it seems like luck? as to which order these go in?

I've just created another project and this one works fine, but in the network 
info I can that Endian.js is being loaded prior to BinaryData.js. I can't see 
why this would be: it seems to just be down to the order that the big 
dependency list at the start of the html script is written. And I can't 
actually see why with one project, I'm ending up with one of our own classes 
early on in that list ... which means I currently have two solutions for fixing 
this: (a) add the endian dependency to the binarydata line in the html; (b) 
reorder the main list of dependencies at the top of the html to make endian 
appear earlier on. Neither of these are a good solution when this file is 
generated on every build!!

So: am I right in thinking that the dependency list for the BinaryData.js 
should include the Endian one? i.e. this is wrong:
goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
['org.apache.royale.utils.BinaryData'], 
['org.apache.royale.utils.IBinaryDataInput', 
'org.apache.royale.utils.IBinaryDataOutput']);

If so, then that needs to change (somehow) and it would then solve my problem...

thanks

   Andrew


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 19 July 2018 13:32
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

The Endian dependency should be added to the main application dependency. The 
entire list should be included there. (I have 872 dependencies listed.) 
‘org.apache.royale.utils.Endian’ is one of them.

I am also using URLStream and URLBinaryLoader which list Endian as a 
dependency, so it’s possible it’s being pulled from there. I’m not sure I have 
an application which uses BinaryData without one of those.

> On Jul 19, 2018, at 3:19 PM, Harbs  wrote:
> 
> That’s weird. I believe the default is false (although I think the default 
> should be true).
> 
> Try setting -remove-circulars to true. I think that should resolve it.
> 
> Yes. I’m using BinaryData extensively.
> 
>> On Jul 19, 2018, at 3:15 PM, Frost, Andrew  wrote:
>> 
>> Hi
>> 
>> I'm not using it on my build command line, i.e. it's set as the default 
>> 'true'.
>> 
>> If I do set it to 'false' then I get what I would expect from the code, i.e. 
>> it ignores the interfaces and just outputs the discovered dependencies - 
>> including the google one:
>> goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
>> ['org.apache.royale.utils.BinaryData'], ['goog.DEBUG', 
>> 'org.apache.royale.utils.Endian']);
>> 
>> But now I get hundreds of errors from the browser's JS engine e.g. 
>> IStatesObject.js:42 Uncaught TypeError: Cannot read property 
>> 'IEventDispatcher' of undefined
>>   at IStatesObject.js:42
>> (anonymous) @ IStatesObject.js:42
>> IUIBase.js:58 Uncaught TypeError: Cannot read property 'IEventDispatcher' of 
>> undefined
>>   at IUIBase.js:58
>> (anonymous) @ IUIBase.js:58
>> IBeadModel.js:38 Uncaught TypeError: Cannot read property 'IEventDispatcher' 
>> of undefined
>>   at IBeadModel.js:38
>> (anonymous) @ IBeadModel.js:38
>> Event.js:33 Uncaught TypeError: Cannot read property 'Event' of undefined
>>   at Event.js:33
>> (anonymous) @ Event.js:33
>> base.js:2484 Uncaught TypeError: Cannot read property 'prototype' of 
>> undefined
>>   at Obje

RE: Query on Royale dependency generation

[Frost, Andrew]

Hi

> If it’s in the big list, it should be initialized correctly.
.. but depending on the order of the big list, things will be initialised in 
different orders...

> Are you initializing a BinaryData as a static const (or preinitialized var)?
Yes
> i.e. public static const DATA:BinaryData = new BinaryData() is a no-no.
So - why is this a no-no? I'm trying to convert an ActionScript class that 
Adobe wrote a long time ago, which has the equivalent using ByteArray. Are you 
saying that it's not possible to do certain things with ActionScript in Royale 
that are fine when you're targeting Flash?
I know it's not a great practice to have this sort of thing but I would hope 
that there is some level of parity between the ActionScript code that you can 
write for each of the targets; plus, as I've found, all that's needed for this 
construct to work 100% of the time is if we could specify the correct 
dependencies for the BinaryData class.

> I’d really like to have the compiler delay loading of static consts and var 
> to the very end of the loading. That would allow this pattern…
True, and possibly that could work, but surely it would also be allowed if we 
generated the line:
goog.addDependency('../../../org/apache/royale/utils/BinaryData.js',
  ['org.apache.royale.utils.BinaryData'], [ 'org.apache.royale.utils.Endian', 
  'org.apache.royale.utils.IBinaryDataInput', 
'org.apache.royale.utils.IBinaryDataOutput']);

So regardless of all the discussion, I would quite like to find out why the 
'Endian' isn't listed as a dependency when all this html/JS stuff is 
generated... likewise some of the other constructs where something depends on 
something else (e.g. "is" is being used in the Namespace constructor, but I'm 
creating a Namespace prior to the Language.js file being loaded..)

I guess we can't actually wait until the end of loading everything until we 
start to initialise things, unless we change how the JS code is output (i.e. to 
have a single static initialiser for the class which is run after everything is 
loaded, rather than declaring all the static properties with initialisation 
in-place..)

Interesting problem!

thanks

   Andrew


-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com] 
Sent: 19 July 2018 14:19
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

If it’s in the big list, it should be initialized correctly.

Are you initializing a BinaryData as a static const (or preinitialized var)?

i.e. public static const DATA:BinaryData = new BinaryData() is a no-no.

I’d really like to have the compiler delay loading of static consts and var to 
the very end of the loading. That would allow this pattern…

> On Jul 19, 2018, at 4:06 PM, Frost, Andrew  wrote:
> 
> Hi
> 
> Yes (it's weird!) - okay so I just set the -remove-circulars option to true 
> explicitly but still no change (from the default).
> 
> If you look in your html file, do you get just:
> goog.addDependency('../../../org/apache/royale/utils/BinaryData.js', 
> ['org.apache.royale.utils.BinaryData'], 
> ['org.apache.royale.utils.IBinaryDataInput', 
> 'org.apache.royale.utils.IBinaryDataOutput']);
> for the dependencies of it?
> 
> In the big list of dependencies at the start, then yes Endian is showing up 
> there. BinaryData isn't in that big list, because this is a dependency of 
> another of my classes (which is in the list). It's constructor is being 
> called because there's a static property being initialised i.e.
> static private var _bytes : BinaryData = new BinaryData();
> 
> 
> From a bit more digging, the issue (whether it happens or not) seems to be 
> due to the order in which the files are loaded; there can be a specific order 
> be applied in terms of ensuring that the dependencies are loaded before the 
> classes that require them, but there isn't a dependency link between 
> BinaryData and Endian (as you can see from your compiled .js files). So 
> without this dependency, it seems like luck? as to which order these go in?
> 
> I've just created another project and this one works fine, but in the network 
> info I can that Endian.js is being loaded prior to BinaryData.js. I can't see 
> why this would be: it seems to just be down to the order that the big 
> dependency list at the start of the html script is written. And I can't 
> actually see why with one project, I'm ending up with one of our own classes 
> early on in that list ... which means I currently have two solutions for 
> fixing this: (a) add the endian dependency to the binarydata line in the 
> html; (b) reorder the main list of dependencies at the top of the html 

RE: Query on Royale dependency generation

[Frost, Andrew]

Hi guys

Thanks for the details. Harbs, I see what you mean now, and yes I can work 
around it in the source code by changing how the variable is initialised.

I guess circular dependencies are a little tricky from a JavaScript 
perspective! It's easier in ActionScript due to the way the player sets things 
up (although when we tried the "verifyAll" setting in avmplus, we ran into 
similar problems with some SWCs...)

In terms of the options, I guess my preference would be '2', where the static 
initialisers are output using the pattern that Harbs suggests. For now I can 
switch to that pattern manually, but I can add that idea to the list of things 
to investigate when we have more time..


thanks

   Andrew




-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 19 July 2018 18:04
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

For sure, there are probably still bugs in the remove-circulars calculation.  
But, before debugging these problems, make sure you remove the entire 
bin/js-debug folder.  The JS files in there are modified by the dependency 
management code and could get stale.

The fundamental problem is that goog.provides, goog.requires, and 
goog.addDependency result in 

RE: Query on Royale dependency generation

[Frost, Andrew]

Yes good point: so to protect ourselves it might be that we need to try to 
mimic what the avmplus does and just call a 'class initialiser' method to set 
up all the static properties, when the class is first referenced. Although I'm 
not sure whether we can detect from JavaScript when the class is first 
referenced..?!

In terms of trying to make the dependency emitter a little more clever: aren't 
we always going to face problems if there really are two classes that have a 
reference to each other? So a real circular reference that can't be resolved? 
Maybe this isn't so common in real life... I guess if it doesn't yet know that 
it's emitting a static initializer then yes there's a more basic issue to 
address!

thanks

   Andrew


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 20 July 2018 15:55
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

Personally, I'm not convinced the problem is truly different in SWF vs JS, 
other than that in JS, the google closure compiler and 
goog.provides/requires/addDependency don't really let you specify the 
difference between static and non-static initializer dependencies.  I think you 
may have seen that when you played with the "verifyAll" setting.

The main difference, AIUI, is that the Flash runtime only initializes the 
statics on a class when first used instead of when loaded.  JS initializes all 
statics when loaded.  But I think that the order in many cases still matters in 
the SWF.  I see code in the SWF output section of the compiler that figures out 
the order of classes to output into the SWF.  There is a DependencyGraph that 
is managed by the compiler.  It is possible that the problem is simply a matter 
of translating that SWF order into the goog.provides/requires/addDependency.

I think that at Emitter time, we can know that we are initializing a static 
initializer and can record that information in the output for use in 
GoogDepsWriter.

I worry that the workaround in #2 may not always work.  The workaround changes 
when the initializer runs, but I wonder if there will be scenarios where the 
initializers are still going to be needed "early".

Whether we do #2 or #3, the Emitter logic still needs to detect that it is 
outputting a static initializer.  So it isn't clear that it is worth the 
overhead of outputting different code vs just leaving more data for 
GoogDepsWriter.

My 2 cents,
-Alex

On 7/20/18, 6:49 AM, "Frost, Andrew"  wrote:

Hi guys

Thanks for the details. Harbs, I see what you mean now, and yes I can work 
around it in the source code by changing how the variable is initialised.

I guess circular dependencies are a little tricky from a JavaScript 
perspective! It's easier in ActionScript due to the way the player sets things 
up (although when we tried the "verifyAll" setting in avmplus, we ran into 
similar problems with some SWCs...)

In terms of the options, I guess my preference would be '2', where the 
static initialisers are output using the pattern that Harbs suggests. For now I 
can switch to that pattern manually, but I can add that idea to the list of 
things to investigate when we have more time..


thanks

   Andrew




-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 19 July 2018 18:04
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

For sure, there are probably still bugs in the remove-circulars 
calculation.  But, before debugging these problems, make sure you remove the 
entire bin/js-debug folder.  The JS files in there are modified by the 
dependency management code and could get stale.

The fundamental problem is that goog.provides, goog.requires, and 
goog.addDependency result in