flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FalconJX] compiling non-browser javascript
Date Mon, 02 May 2016 04:02:19 GMT
We've recently made changes to allow keywords in more places.  I
personally don't enjoy doing that work, but maybe Josh will.


On 5/1/16, 12:34 PM, "Harbs" <harbs.lists@gmail.com> wrote:

>I get the same error for other reserved words:
>On May 1, 2016, at 10:28 PM, Harbs <harbs.lists@gmail.com> wrote:
>> I manually deleted most of the core classes to get it to compile.
>> I’m now getting an error which I don’t know if it’s valid or a bug in
>> 		public function findKeyStrings(for:String):String{return null;}
>> 		public function translateKeyString(for:String):String{return null;}
>> When trying to compile a class which contains code like this, I get:
>> 'for' is not allowed here
>> Is “for” really not allowed as the name of a parameter, or i it a bug
>>that the compiler thinks it’s a for loop?
>> Harbs
>> On May 1, 2016, at 3:50 PM, Harbs <harbs.lists@gmail.com> wrote:
>>> Here’s my stab at producing ActionScript files from the OMV files:
>>> The output is actually pretty good. I get error-free output on
>>>InDesign files with the exception of File types because I don’t yet
>>>have the core types linked. Photoshop output is not as good, for the
>>>most part because the OMV files types are not all true types.
>>> I do have a question though (before I even got to the point where I’m
>>>trying to use this to cross-compile code): When I run the base classes
>>>through the app, I get a bunch of classes which do not compile into a
>>>SWC very well. At least part of the problem is due to the fact that
>>>they confluct with core classes, and I’m not sure how to best handle
>>>this. Here’s a link of the as code:
>>> I’m not sure how to best handle this. If anyone has good ideas, please
>>>let me know.
>>> On Apr 25, 2016, at 9:28 PM, Harbs <harbs.lists@gmail.com> wrote:
>>>> I was guessing that the release would probably work. I am concerned
>>>>about debugging though.
>>>> I will probably try this suggestion next week and see how far I can
>>>>get without further help. Chances are I’ll be back here before I’m
>>>>successful though… ;-)
>>>> Thanks!
>>>> Harbs
>>>> On Apr 25, 2016, at 6:27 PM, Alex Harui <aharui@adobe.com> wrote:
>>>>> On 4/25/16, 8:16 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:
>>>>>> In the bin/js-release directory, all of the generated JavaScript
>>>>>> concatenated into a single file, so it no longer uses
>>>>>>goog.require(). That
>>>>>> should work in environments that cannot load multiple scripts.
>>>>> I was about to suggest that as well.  By default, the single-file
>>>>> is minified so is hard to debug.  You can add
>>>>> -js-compiler-option="--compilation_level WHITESPACE_ONLY"
>>>>> to the cross-compile and I think you'll still get a single file
>>>>> goog.require but it will be debuggable.
>>>>> These options are handled by the compiler code in a Publisher.
>>>>> MXMLFlexJSPublisher has this default behavior.  You can subclass it
>>>>> create a different js-output-type get it to spit a single-file to the
>>>>> js-debug and a minified single-file to js-release.  It will take a
>>>>> time, though, as gathering in a single file is done by the Google
>>>>> Compiler.  But you don't to know much about compilers to make a
>>>>> Publisher.  Everything is compiled at that point and you are
>>>>> dealing with files and configs for GCC.
>>>>> A harder task is to make the goog.require replaceable with some other
>>>>> pattern.
>>>>> -Alex

View raw message