Re: Royale compiler not handling Date.fullYear etc
No worries. I didn't see it either. The Flash environment picked it up. It also picked up that some of the tests may not be properly implemented. The date test is using 'Sat Jun 30 23:59:59 GMT-0800 2018' and then Date.date+=1, but when you have the Flash SDK, it actually runs this code and it isn't doing the right thing, at least in my time zone. I'm looking into that now. It is hard to write tests for different time zones and different runtime environments. I'm glad you got us most of the way there. Later, -Alex On 7/3/18, 10:03 AM, "Frost, Andrew" wrote: 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FH8du73qyd2P59dgc_NBig5kKS-MSuqeeLzkLnUuGc2g%3D%3Fd%3DXVM8wcUx4AVvvnx4aYpF00yk_Eyt9QZZF_c65XW-bGLlOqoBAmP4EZZZHcq3CxBBmKZpgajW8vxVFLmNQUwTkz-h3EmNKlq8UyFiYyklTfyKmivIVAaXa-6Uh22WNmrQPgipIQ5Bl1dYRZXx8v2FZ83ZkYErcY9kwfeFH2td0tJLDs3UuRtInu7Pg3ez7ZpidUYN_NR6xuesnpZ1PdAMKNZA0LhumZmir0NVprDmnsJ1BkaWAy6vXkO3GNuS4KHFrBe1VUQvY5uWuwGnqkMRvZA1N-hVF8cfY4bUQjZbFWjb9oxrU7AbQrtv2GodpVQWdsNUjpiczlfhcvVk8VhPuVjsGma93Tj8zXHuFsMOZxZYg1sTepHUbWoMXGQVGUmK1Jk6EAJ7zyL4lVjxzkNAJ31si4DjoouXLo5Q-D0w0B2oRQ14_ii9MfaNRuJ93qk%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252Fapache%25252Froyale-typedefs%25252Fpull%25252F2%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C23fabd6b67b94e1dc16008d5e0d3d550%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636662122786567530%2526sdata%253DQ%25252FnpJJ657LMOQFUvytn5k4LWbVVw3YancGcyqU%25252F9MSI%25253D%2526reserved%253D0=02%7C01%7Caharui%40adobe.com%7Cd39e10024e8d42b49b5008d5e106e101%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662342019465396=YRzeG0EY17vQ7gX3UYr2T7oJIBjTICGoRc3fdXjVkTI%3D=0 Compiler: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2F7ckP0xBvPXAikG7TS7fGtLEmtYORNspA7ffmJ61oStE%3D%3Fd%3DXVM8wcUx4AVvvnx4aYpF00yk_Eyt9QZZF_c65XW-bGLlOqoBAmP4EZZZHcq3CxBBmKZpgajW8vxVFLmNQUwTkz-h3EmNKlq8UyFiYyklTfyKmivIVAaXa-6Uh22WNmrQPgipIQ5Bl1dYRZXx8v2FZ83ZkYErcY9kwfeFH2td0tJLDs3UuRtInu7Pg3ez7ZpidUYN_NR6xuesnpZ1PdAMKNZA0LhumZmir0NVprDmnsJ1BkaWAy6vXkO3GNuS4KHFrBe1VUQvY5uWuwGnqkMRvZA1N-hVF8cfY4bUQjZbFWjb9oxrU7AbQrtv2GodpVQWdsNUjpiczlfhcvVk8VhPuVjsGma93Tj8zXHuFsMOZxZYg1sTepHUbWoMXGQVGUmK1Jk6EAJ7zyL4lVjxzkNAJ31si4DjoouXLo5Q-D0w0B2oRQ14_ii9MfaNRuJ93qk%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252Fapache%25252Froyale-compiler%25252Fpull%25252F46%2526data%253D02%25257C0
RE: Royale compiler not handling Date.fullYear etc
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=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=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-
From: Alex Harui [mailto:aha
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-typedefs%2Fpull%2F2=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530=Q%2FnpJJ657LMOQFUvytn5k4LWbVVw3YancGcyqU%2F9MSI%3D=0
Compiler:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fpull%2F46=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530=L%2B3cknwmPbt4rvzFd7sDguzXXNspXHUdnVY4UVIPnW0%3D=0
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FwviiW6QxLi8ypSnU5H09X2xjni7YMbYvK77LEkO5CDc%3D%3Fd%3D_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo
Re: Royale compiler not handling Date.fullYear etc
Congrats Andrew! Well done!
wt., 3 lip 2018 o 18:31 Alex Harui napisał(a):
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-typedefs%2Fpull%2F2=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530=Q%2FnpJJ657LMOQFUvytn5k4LWbVVw3YancGcyqU%2F9MSI%3D=0
> Compiler:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fpull%2F46=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530=L%2B3cknwmPbt4rvzFd7sDguzXXNspXHUdnVY4UVIPnW0%3D=0
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FwviiW6QxLi8ypSnU5H09X2xjni7YMbYvK77LEkO5CDc%3D%3Fd%3D_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo34PLSaC9n5J08tWjYr684YeBkkWxnp2HcZdkgNzuQomI_AxW87-eGOUJ6BX3fpIq_85GevpLOLDtImXR9QSgOqRr8CPPdoqGLktBiwqfyZgvoybKudC2IK3zCmJoehcWoBmeXjp5BYTa2y0nIyvPd5uIG0WYm3JsJ2SYir9Lo6eyi-l_jT5qujCB9duN6TZDMw6d3nk9CU1DUlTgmpu8sTVpksO772_ZC0g-UQ0XAwzNaKvyauEqoa7Dn0h61XfQp5AqHmj6fdgrYEtUrlQQYC5UE3i8HxOcaCgOYGOEQ1GClok3NDQMETE1dyjN20C1N_Z-dWb1-qNMzyGi732Hk-nT_kq4IjD3YDuNeJwtk0wYZ42ik8c4M-nNHDMcZJfnVJf9_MWpQBY7o3JH2Vdg%253D%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252Fajwfrost%25252Froyale-compiler%25252Fcommit%25252F8157465fbe05022136ae7b405f316e89ee809c97%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C71b34e8a1cc
Re: Royale compiler not handling Date.fullYear etc
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-typedefs%2Fpull%2F2=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530=Q%2FnpJJ657LMOQFUvytn5k4LWbVVw3YancGcyqU%2F9MSI%3D=0
Compiler:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fpull%2F46=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530=L%2B3cknwmPbt4rvzFd7sDguzXXNspXHUdnVY4UVIPnW0%3D=0
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FwviiW6QxLi8ypSnU5H09X2xjni7YMbYvK77LEkO5CDc%3D%3Fd%3D_zziaDODDuvZwC8YjWYfsPGmQ13A3Q5xBbMSUHKZIo34PLSaC9n5J08tWjYr684YeBkkWxnp2HcZdkgNzuQomI_AxW87-eGOUJ6BX3fpIq_85GevpLOLDtImXR9QSgOqRr8CPPdoqGLktBiwqfyZgvoybKudC2IK3zCmJoehcWoBmeXjp5BYTa2y0nIyvPd5uIG0WYm3JsJ2SYir9Lo6eyi-l_jT5qujCB9duN6TZDMw6d3nk9CU1DUlTgmpu8sTVpksO772_ZC0g-UQ0XAwzNaKvyauEqoa7Dn0h61XfQp5AqHmj6fdgrYEtUrlQQYC5UE3i8HxOcaCgOYGOEQ1GClok3NDQMETE1dyjN20C1N_Z-dWb1-qNMzyGi732Hk-nT_kq4IjD3YDuNeJwtk0wYZ42ik8c4M-nNHDMcZJfnVJf9_MWpQBY7o3JH2Vdg%253D%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252Fajwfrost%25252Froyale-compiler%25252Fcommit%25252F8157465fbe05022136ae7b405f316e89ee809c97%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C71b34e8a1cca401a8f6d08d5e032645e%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636661429411013521%2526sdata%253D6DNQpiY0msNOA2%25252Fj0CiWEvv94X1JfDIacwOlm9nzqqE%25253D%2526reserved%253D0=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530=6hEzv0grDYsQ3AHulsQ15RkUFlAprJAhN7LDMUXsqso%3D=0
but I've not yet
RE: Royale compiler not handling Date.fullYear etc
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=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\ASExpressionTests7333543909053470
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=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:
[junit] Running as.ASDat
Re: Royale compiler not handling Date.fullYear etc
teTests3525997529829206058.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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FT83CUIducqI9Lkpsqh8xgxVIyLMGnJbMonLa5_1_9kg%3D%3Fd%3Da9uxnQqkSmG7oTXapoG51ZcBcs2YQHVAyX7jtig52n_nvBCIyavSa7KScNwp1Pl-KHVyOVX10_IT-KhaR3dogyBF_PhM8l3mUniTusdETZeur68fGw663Yj8q73kuaKvNSfxQjwF-6v9sicptU6c945r2TlZu66048QF9Hc5OfDqAjf3LVZb5gbp2xebFV7gzThYfrj1WT851Sp6LaTuiiQKrNJnk-b2P2hiwTctWCrxALua42IS-8UJgp9t515EbpW7BWVMaS7827cZqn5K1H5bcXQ2kYGEL8HrJLm5nnsDgC9IpTYdOcwHuxR3TmYpp6ymdh14dZ6Mc2O9_fpD1E9WaZW9n2sYlFHXAMQFYuvNMQeXTSETZlJ0B0fYtPOnVyR-jL7hXo3MptfdPzl3nzfuVaJFJaVoPEXU5m8yhCn-2McWhLwPf0UNxPbmL58COzo4KqYtEqA%253D%26u%3Dhttps%253A%252F%252Fgithub.com%252Fgoogle%252Fclosure-compiler%252Fblob%252Fmaster%252Fsrc%252Fcom%252Fgoogle%252Fjavascript%252Fjscomp%252Fparsing%252FAnnotation.java=02%7C01%7Caharui%40adobe.com%7C71b34e8a1cca401a8f6d08d5e032645e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636661429411023530=5QX90Py%2BYSblXW%2BRjKw4q9IouS9O6QYCuXN%2FcndrJ00%3D=0
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2Ft8Vt55bBn1paDRrO_tcbGDw3nOt-4_f5sEQDRaUr78g%3D%3Fd%3DlhuiLMs5TaNvmSSfvLo9lH6b9M276TThXO9G60OlPgOsY0f-pENIrkec8khCn7viL4JfEe1fvVJVaiQjQh6BhiYP7C_O9RJunWasASxHmucjtZZQBzeCviGxf9lrMUs0zxkkPNHBoa_rq8QP8-dOSlYcneP9T5WOgjLYBeKsizspqFWxP5Szt6O6GYS1QKNQtcPvwoh5NSOLYeB2K3j46FeJyZfM51xmX1vX4JN5xKWd1bY4mOAK6B9Kr7A2u6i65r0iSYuzL8ok9ybJXKGK43QxR_nahrgFSKD2Bg-0iMujUKi8uNlZ5kOGSzi3oE0ByPCbF-4QIZtYTa3V7zQ1AaG4rQnICykl0p0UohbhZZrVdA2536sB_xwCGEKvHXA0Hf5_evEzsPHoxiB5HeyKiYQW8vzNmmT3CSqOKfakgQLVd_4l5xMYQ7AeYmU%253D%26u%3Dhttps%253A%252F%252Fgithub.com%252Fgoogle%252Fclosure-compiler%252Fissues%252F139=02%7C01%7Caharui%40adobe.com%7C71b34e8a1cca401a8f6d08d5e032645e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636661429411023530=8%2F%2FVIPCYKVmYbNzmsKLIWPe3pj9aLtL2ZLJvW9fEvDc%3D=0
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
RE: Royale compiler not handling Date.fullYear etc
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-KHVyOVX10_IT-KhaR3dogyBF_PhM8l3mUniTusdETZ
Re: Royale compiler not handling Date.fullYear etc
Hi Andrew,
I agree with your conclusions. Upon further investigation, Google Closure just
closed those bugs as duplicates and the original issue remains open. So adding
some field to the ExternCConfig sounds like the easiest path for now.
Thanks,
-Alex
On 7/2/18, 2:14 AM, "Frost, Andrew" wrote:
Hi
Even if we get the latest version, they still don't support a "readonly"
annotation:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fblob%2Fmaster%2Fsrc%2Fcom%2Fgoogle%2Fjavascript%2Fjscomp%2Fparsing%2FAnnotation.java=02%7C01%7Caharui%40adobe.com%7C0dc93c78a4d94e4d834208d5dffc3e41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636661196836331609=BIj4sZ6G1RxdVqd2nGYA9do9hujoNGjCRrrIXqY%2Bw5Y%3D=0
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2Ft8Vt55bBn1paDRrO_tcbGDw3nOt-4_f5sEQDRaUr78g%3D%3Fd%3DlhuiLMs5TaNvmSSfvLo9lH6b9M276TThXO9G60OlPgOsY0f-pENIrkec8khCn7viL4JfEe1fvVJVaiQjQh6BhiYP7C_O9RJunWasASxHmucjtZZQBzeCviGxf9lrMUs0zxkkPNHBoa_rq8QP8-dOSlYcneP9T5WOgjLYBeKsizspqFWxP5Szt6O6GYS1QKNQtcPvwoh5NSOLYeB2K3j46FeJyZfM51xmX1vX4JN5xKWd1bY4mOAK6B9Kr7A2u6i65r0iSYuzL8ok9ybJXKGK43QxR_nahrgFSKD2Bg-0iMujUKi8uNlZ5kOGSzi3oE0ByPCbF-4QIZtYTa3V7zQ1AaG4rQnICykl0p0UohbhZZrVdA2536sB_xwCGEKvHXA0Hf5_evEzsPHoxiB5HeyKiYQW8vzNmmT3CSqOKfakgQLVd_4l5xMYQ7AeYmU%253D%26u%3Dhttps%253A%252F%252Fgithub.com%252Fgoogle%252Fclosure-compiler%252Fissues%252F139=02%7C01%7Caharui%40adobe.com%7C0dc93c78a4d94e4d834208d5dffc3e41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636661196836331609=Q1nsKBTBxFETuFUUOXqMjx8v7E96Y0pZGBpQ%2BNWEwzI%3D=0
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)
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://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=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 sync from one to the other. The same is
true of the js.swc, it's being generated in the royale-typ
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://github.com/google/closure-compiler/issues/139
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 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FuntftVdsWwPmiJWAVt3nm3wg6v4ZACZ9RDBNQjuszM0%3D%3Fd%3DbbejT-O_-jFYytoEIpecgb-HW7JAfVy-JYJKJjpirj9WyJta8y-Vetrzg91hMyjxwIZDBbGoPRETuW8R-_GJ2QI3JFRNDooGe4nnEJmgsbOCgX9zvdpNOtRejsS_vQ96JFtVBei96NlGXnAeb9O-n2UPHrthFwLfNhxhivyLhutMuYZf1_Bwf9uhuogWi4XEGnREN0VeGK-7HR-0IXBlFkwvMeyJ_r7KS89xbvNmYhN1EFExUVrPWOSGUU7bDbqQGwx_iQnLVTX8Lj1IsNPJvd8qUgJnR5R6P-smt5q_FBaLNjsRWDWI0U_XMUyRIY_5-Kz1H2BKLxZppDcoEdbSVn_k9bD-Eo7722e3Jajt9nKt5EOvpU8kzNvIgbQxRNW4JbQ0gyaaZG-838aZUMmtuoW39NTiDdhoowZejUVmDmKstEs8NbBBtOnE3Ck%253D%26u%3Dhttps%253A%252F%252Fgithub.com%252Fgoogle%252Fclosure-compiler%252Fwiki%252FAnnotating-JavaScript-for-the-Closure-Compiler=02%7C01%7Caharui%40adobe.com%7Cb7acdaa31fda47dff0c508d5de553e2e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636659380078411962=oCQLuHrDHlf9BSbfTC%2F2UJgSlMLkKV2kNQ0z3FX%2F%2Bxk%3D=0
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
RE: Royale compiler not handling Date.fullYear etc
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=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 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 find
Re: Royale compiler not handling Date.fullYear etc
Interesting. In
https://github.com/google/closure-compiler/wiki/Annotating-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 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
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
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
".. 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
Cool. Are there compiler tests for these Date additions?
> On Jun 29, 2018, at 3:03 PM, Frost, Andrew wrote:
>
> 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...
>>
>>
>>
RE: Royale compiler not handling Date.fullYear etc
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 kicking in to do the actual conversion during the
em
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 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.
Re: Royale compiler not handling Date.fullYear etc
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 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
RE: Royale compiler not handling Date.fullYear etc
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: 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: 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: Royale compiler not handling Date.fullYear etc
Hi Andrew,
Thanks for looking into this. I'm totally guessing, but it may be that the
problem is somewhere completely different than you are thinking. In
BinaryOperatorEmitter, there is already a "specialCaseDate" method that should
have done the right thing, but I think that code was designed to handle
compiling against SWF libraries and transpiling to AS and we've never dealt
with compiling against JS libraries and transpiling.
For the first years of FlexJS we mainly compiled against SWF libraries and
transpiled. This is still allowed in Royale and works great if you are not
using any SWF specific APIs. Such a configuration uses playerglobal.swc or
airglobal.swc. Then Date. fullYear is defined, but the output in
BinaryOperatorEmitter should get called and output getFullYear/setFullYear.
Unless it broke recently.
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.
FWIW, this illustrates some of the pieces of the compiler. Each source file as
assigned a CompilationUnit. The CompilationUnit built the parse tree. The
parsing phase doesn't really know much about what APIs are available so it
correctly built the parse tree (AST). Then, the CompilationUnit tries to
reduce each AST to SWF byte code even if you only want JS output because the
reduce has the semantic analysis code. That's where the compiler realized that
Date.fullYear was not defined in any source or library. So I'm guessing you
have to define it by adding it to js.swc. Then once all APIs and dependencies
have been found, the output code like BinaryOperatorEmitter kicks in and
outputs JS and looks for special cases like Date.fullYear and outputs
Date.getFullYear/setFullYear instead.
HTH,
-Alex
On 6/28/18, 9:30 AM, "Frost, Andrew" wrote:
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
RE: Royale compiler not handling Date.fullYear etc
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
