Congrats Andrew! Well done! wt., 3 lip 2018 o 18:31 Alex Harui <aha...@adobe.com.invalid> 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" <andrew.fr...@harman.com> 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&data=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530&sdata=Q%2FnpJJ657LMOQFUvytn5k4LWbVVw3YancGcyqU%2F9MSI%3D&reserved=0 > Compiler: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fpull%2F46&data=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530&sdata=L%2B3cknwmPbt4rvzFd7sDguzXXNspXHUdnVY4UVIPnW0%3D&reserved=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" <andrew.fr...@harman.com> 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&data=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530&sdata=6hEzv0grDYsQ3AHulsQ15RkUFlAprJAhN7LDMUXsqso%3D&reserved=0 > 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\ASExpressionTests7333543909053 > 470191.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\ASExpressionTests3291256200729 > 799168.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] <?xml version="1.0" encoding="UTF-8"?> > [junit] <!-- Parsing swf > file:/C:/Work/Royale/royale-compiler/compiler/target/junit-temp/ASDateTests3525997529829206058.swf > --> > .. 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%2F34_ApVH89ZYMA6skDKzoAhaFarF5_Q-YHNeF3Yt77Xs%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%25252Fclicktime.symantec.com%25252Fa%25252F1%25252FT83CUIducqI9Lkpsqh8xgxVIyLMGnJbMonLa5_1_9kg%25253D%25253Fd%25253Da9uxnQqkSmG7oTXapoG51ZcBcs2YQHVAyX7jtig52n_nvBCIyavSa7KScNwp1Pl-KHVyOVX10_IT-KhaR3dogyBF_PhM8l3mUniTusdETZeur68fGw663Yj8q73kuaKvNSfxQjwF-6v9sicptU6c945r2TlZu66048QF9Hc5OfDqAjf3LVZb5gbp2xebFV7gzThYfrj1WT851Sp6LaTuiiQKrNJnk-b2P2hiwTctWCrxALua42IS-8UJgp9t515EbpW7BWVMaS7827cZqn5K1H5bcXQ2kYGEL8HrJLm5nnsDgC9IpTYdOcwHuxR3TmYpp6ymdh14dZ6Mc2O9_fpD1E9WaZW9n2sYlFHXAMQFYuvNMQeXTSETZlJ0B0fYtPOnVyR-jL7hXo3MptfdPzl3nzfuVaJFJaVoPEXU5m8yhCn-2McWhLwPf0UNxPbmL58COzo4KqYtEqA%2525253D%252526u%25253Dhttps%2525253A%2525252F%2525252Fgithub.com%2525252Fgoogle%2525252Fclosure-compiler%2525252Fblob%2525252Fmaster%2525252Fsrc%2525252Fcom%2525252Fgoogle%2525252Fjavascript%2525252Fjscomp%2525252Fparsing%2525252FAnnotation.java%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C71b34e8a1cca401a8f6d08d5e032645e%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636661429411023530%2526sdata%253D5QX90Py%25252BYSblXW%25252BRjKw4q9IouS9O6QYCuXN%25252FcndrJ00%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530&sdata=hEl0rpHLA%2Bq9TVOnEXt8nybUN7z9xAMMnwbmssQzYZU%3D&reserved=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 > <field-readonly><class>Date</class><name>timezoneOffset</name></field-readonly> > (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%2FQUWhsoxKtWnoa75S5qhiHUOQqaPDxNbZ7aRKeLE1_2U%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%25252Fclicktime.symantec.com%25252Fa%25252F1%25252Ft8Vt55bBn1paDRrO_tcbGDw3nOt-4_f5sEQDRaUr78g%25253D%25253Fd%25253DlhuiLMs5TaNvmSSfvLo9lH6b9M276TThXO9G60OlPgOsY0f-pENIrkec8khCn7viL4JfEe1fvVJVaiQjQh6BhiYP7C_O9RJunWasASxHmucjtZZQBzeCviGxf9lrMUs0zxkkPNHBoa_rq8QP8-dOSlYcneP9T5WOgjLYBeKsizspqFWxP5Szt6O6GYS1QKNQtcPvwoh5NSOLYeB2K3j46FeJyZfM51xmX1vX4JN5xKWd1bY4mOAK6B9Kr7A2u6i65r0iSYuzL8ok9ybJXKGK43QxR_nahrgFSKD2Bg-0iMujUKi8uNlZ5kOGSzi3oE0ByPCbF-4QIZtYTa3V7zQ1AaG4rQnICykl0p0UohbhZZrVdA2536sB_xwCGEKvHXA0Hf5_evEzsPHoxiB5HeyKiYQW8vzNmmT3CSqOKfakgQLVd_4l5xMYQ7AeYmU%2525253D%252526u%25253Dhttps%2525253A%2525252F%2525252Fgithub.com%2525252Fgoogle%2525252Fclosure-compiler%2525252Fissues%2525252F139%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257C71b34e8a1cca401a8f6d08d5e032645e%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C0%25257C636661429411023530%2526sdata%253D8%25252F%25252FVIPCYKVmYbNzmsKLIWPe3pj9aLtL2ZLJvW9fEvDc%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C23fabd6b67b94e1dc16008d5e0d3d550%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662122786567530&sdata=eeaOYqkTqPAoWQVvGcPgvCs8Ldw0xt2hJXpYkUQEzs0%3D&reserved=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" <andrew.fr...@harman.com> > 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%2FJu25ASzndEjOnqYNDd7xiVeQME8ALGuo-URR6C3y6WI%3D%3Fd%3DlhuiLMs5TaNvmSSfvLo9lH6b9M276TThXO9G60OlPgOsY0f-pENIrkec8khCn7viL4JfEe1fvVJVaiQjQh6BhiYP7C_O9RJunWasASxHmucjtZZQBzeCviGxf9lrMUs0zxkkPNHBoa_rq8QP8-dOSlYcneP9T5WOgjLYBeKsizspqFWxP5Szt6O6GYS1QKNQtcPvwoh5NSOLYeB2K3j46FeJyZfM51xmX1vX4JN5xKWd1bY4mOAK6B9Kr7A2u6i65r0iSYuzL8ok9ybJXKGK43QxR_nahrgFSKD2Bg-0iMujUKi8uNlZ5kOGSzi3oE0ByPCbF-4QIZtYTa3V7zQ1AaG4rQnICykl0p0UohbhZZrVdA2536sB_xwCGEKvHXA0Hf5_evEzsPHoxiB5HeyKiYQW8vzNmmT3CSqOKfakgQLVd_4l5xMYQ7AeYmU%253D%26u%3Dhttps%253A%252F%252Fna01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fclicktime.symantec.com%25252Fa%25252F1%25252FuntftVdsWwPmiJWAVt3nm3wg6v4ZACZ9RDBNQjuszM0%25253D%25253Fd%25253DbbejT-O_-jFYytoEIpecgb-HW7JAfVy-JYJKJjpirj9WyJta8y-Vetrzg91hMyjxwIZDBbGoPRETuW8R-_GJ2QI3JFRNDooGe4nnEJmgsbOCgX9zvdpNOtRejsS_vQ96JFtVBei96NlGXnAeb9O-n2UPHrthFwLfNhxhivyLhutMuYZf1_Bwf9uhuogWi4XEGnREN0VeGK-7HR-0IXBlFkwvMeyJ_r7KS89xbvNmYhN1EFExUVrPWOSGUU7bDbqQGwx_iQnLVTX8Lj1IsNPJvd8qUgJnR5R6P-smt5q_FBaLNjsRWDWI0U_XMUyRIY_5-Kz1H2BKLxZppDcoEdbSVn_k9bD-Eo7722e3Jajt9nKt5EOvpU8kzNvIgbQxRNW4JbQ0gyaaZG-838aZUMmtuoW39NTiDdhoowZejUVmDmKstEs8NbBBtOnE3Ck%2525253D%252526u%25253Dhttps%2525253A%2525252F%2525252Fgithub.com%2525252Fgoogle%2525252Fclosure-compiler%2525252Fwiki%2525252FAnnotating-JavaScript-for-the-Closure-Compiler%2526data%253D02%25257C01%25257Caharui%252540adobe.com%25257Cb7acdaa31fda47dff0c508d5de553e2e%25257Cfa7b1b5a7b34438794aed2c178decee1%25257C0%25257C1%25257C636659380078411962%2526sdata%253DoCQLuHrDHlf9BSbfTC%25252F2UJgSlMLkKV2kNQ0z3FX%25252F%25252Bxk%25253D%2526reserved%253D0&data=02%7C01%7Caharui%40adobe.com%7C71b34e8a1cca401a8f6d08d5e032645e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636661429411023530&sdata=lqXDq0EMQ9xVe%2FcLOKXLzlRIMfxI%2BAUaBo7H7FWLMQM%3D&reserved=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" <andrew.fr...@harman.com> > 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" > <andrew.fr...@harman.com> 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? > > > > > > > > > > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
