Sent from my iPhone
> On Feb 8, 2018, at 2:10 PM, Alex Harui <[email protected]> wrote: > > We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default. > The difference between Flex and Royale is that Royale currently crunches > your code through the Google Closure Compiler with ADVANCED_OPTIMIZATIONS > and that messes up how you use plain objects. > > IMO, there is enough to gain from using ValueObjects (code hinting, > type-checking, etc) that we should promote use of them and make it really > easy to use them, like creating typedefs via some utility. IOW, if it > only took 5 minutes to generate ValueObjects for your JSON responses, > would you just use them because it saved you time making mistakes using > plain object? > > But if enough folks want to use plain objects in production (this is not > an issue for the bin/js-debug version) I have no objection to making it > work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since > that is easy, or take the time to add another compiler option and fork the > output code generators to generate different code (and write tests for all > of that). Would ADVANCED_OPTIMIZATIONS plus this new option be worth it > over SIMPLE_OPTIMIZATIONS? > > If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be > fatter, but I don't know by how much. But that is a consideration if > folks are going to care about download size. A comparison would help. I don’t know what scale you have in mind. FWIW - If someone hosting a Royale app truly cares then there are additional outside the scope of Royale solutions like gzip and PageSpeed. Regards, Dave > > Thoughts? > -Alex > > On 2/8/18, 1:55 PM, "[email protected] on behalf of Carlos Rovira" > <[email protected] on behalf of [email protected]> wrote: > >> but why to complicate this so much? I think we always had in Flex/Flash >> the >> opportunity to make this without any additional config. >> Why not left it as it always was? >> >> thanks >> >> 2018-02-08 19:48 GMT+01:00 Alex Harui <[email protected]>: >> >>> I'm not disagreeing. I think the question is whether we need yet another >>> compiler option to generate bracket notation for objects or just ask >>> folks >>> to use SIMPLE_OPTIMIZATIONS. And whether we switch to >>> SIMPLE_OPTIMIZATIONS by default. I can think of lots of other things to >>> work on besides this new option if we have rough equivalents. >>> >>> -Alex >>> >>> On 2/8/18, 10:36 AM, "[email protected] on behalf of Carlos >>> Rovira" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>>> Although I'm pro typed, I agree with Josh that we should not enforce >>>> that. >>>> That's one of the great points in Flash/Flex. >>>> For make things quick, I use simple objects with bracket notation, when >>>> the >>>> application is more relevant I go the right typed path. >>>> It's up to the developer decide when they want one or another. >>>> >>>> >>>> >>>> 2018-02-08 18:50 GMT+01:00 Josh Tynjala <[email protected]>: >>>> >>>>> Nothing frustrated me more about Royale/FlexJS than the fact that I >>>>> couldn't use untyped objects without bracket notation. It's a very >>> bad >>>>> user >>>>> experience when trying to consume JSON, or even when choosing to >>> create >>>>> my >>>>> own object literals. While it's a good best practice to create value >>>>> objects, that shouldn't be forced on everyone. I frequently use >>> untyped >>>>> objects when prototyping because it's more convenient. They're also >>>>> useful >>>>> in example code to reduce boilerplate that isn't particularly >>> relevant >>>>> to >>>>> the concept/feature that you're trying to demonstrate. And, of >>> course, >>>>> there's the already mentioned JSON. >>>>> >>>>> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS >>> the >>>>> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly >>>>> larger file size is an acceptable trade off, if it reduces the >>>>> frustration >>>>> of this situation. Especially for new users who will absolutely think >>>>> its a >>>>> serious bug in the Royale compiler. However, as Harbs notes here, if >>> the >>>>> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be >>>>> retained. >>>>> The compiler could generate code differently when something resolves >>> as >>>>> the >>>>> Object type. The emitter could translate dot notation normally most >>> of >>>>> the >>>>> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it >>>>> detects Object, switch to bracket notation instead. I believe it >>> would >>>>> also >>>>> need to add quotes around properties defined in object literals. >>>>> >>>>> Ideally, the following code should work properly out of the box: >>>>> >>>>> var obj:Object = {one: 1, "two": 2}; >>>>> obj.three = 3; >>>>> obj["four"] = 4; >>>>> var one:Number = obj["one"]; >>>>> var two:Number = obj.two; >>>>> var three:Number = obj["three"]; >>>>> var four:Number = obj.four; >>>>> >>>>> The compiler would probably emit something like this to make it work >>>>> with >>>>> the Closure compiler's ADVANCED_OPTIMIZATIONS: >>>>> >>>>> var obj:Object = {"one": 1, "two": 2}; >>>>> obj["three"] = 3; >>>>> obj["four"] = 4; >>>>> var one:Number = obj["one"]; >>>>> var two:Number = obj["two"]; >>>>> var three:Number = obj["three"]; >>>>> var four:Number = obj["four"]; >>>>> >>>>> Again, that's only for when something is typed as Object. If >>> something >>>>> actually has a class, let Closure compiler go nuts and rename >>>>> everything it >>>>> wants. >>>>> >>>>> - Josh >>>>> >>>>>> On 2018/02/06 08:51:19, Gabe Harbs <[email protected]> wrote: >>>>>> Quite sure. In my angular app I was using an older version of the >>>>> closure compiler to minify the js files. I was using the default >>> options >>>>> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object >>>>> literals >>>>> didn’t get renamed. >>>>>> >>>>>> I think most modern app frameworks use other tools such as Babel >>> for >>>>> magnification, but I believe that handles object literals correctly >>> too. >>>>>> >>>>>> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s >>> killing >>>>> object literals. I’m proposing a compiler *option* to allow to >>> continue >>>>> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which >>>>> should >>>>> not be renamed. >>>>>> >>>>>> Harbs >>>>>> >>>>>>> On Feb 6, 2018, at 9:38 AM, Alex Harui <[email protected]> >>>>> wrote: >>>>>>> >>>>>>> Are you sure Angular and React minify your code instead of >>> running >>>>> it >>>>>>> against their minified framework? >>>>>>> >>>>>>> -Alex >>>>>>> >>>>>>> On 2/5/18, 11:22 PM, "Gabe Harbs" <[email protected]> wrote: >>>>>>> >>>>>>>>> Maybe I'm missing something. I don't think Royale has any >>> extra >>>>>>>>> problems >>>>>>>>> with JSON objects than other JS Frameworks have. If you want >>> to >>>>> minify, >>>>>>>>> you have to use brackets and strings. >>>>>>>> >>>>>>>> It does. >>>>>>>> >>>>>>>> I’ve written angular apps and I’ve never had to worry about >>> using >>>>> bracket >>>>>>>> notation for minifying simple js objects. I’m pretty sure the >>> same >>>>> is >>>>> for >>>>>>>> React, etc. >>>>>>>> >>>>>>>>> On Feb 5, 2018, at 11:34 PM, Alex Harui >>> <[email protected] >>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Maybe I'm missing something. I don't think Royale has any >>> extra >>>>>>>>> problems >>>>>>>>> with JSON objects than other JS Frameworks have. If you want >>> to >>>>> minify, >>>>>>>>> you have to use brackets and strings. If you don't want to >>>>> minify, >>>>> then >>>>>>>>> you don't need to worry about that. Am I wrong about that? >>>>>>>>> >>>>>>>>> >>>>>>>>> JSON has something like a "reviver". Has anyone played with >>> that >>>>> to >>>>> see >>>>>>>>> if it can be used to convert straight to VO's? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -Alex >>>>>>>>> >>>>>>>>>> On 2/5/18, 1:08 PM, "Gabe Harbs" <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> An additional point: >>>>>>>>>> >>>>>>>>>> How do you propose handling json that’s multiple levels deep? >>>>> Walk >>>>> the >>>>>>>>>> json and construct VOs on each level? That seems to me just as >>>>> bad >>>>> as >>>>>>>>>> the >>>>>>>>>> problem. Imagine you just want foo.baz.thingy.uid? You’d need >>> to >>>>>>>>>> create a >>>>>>>>>> VO of foo, baz and thingy or be forced to use >>>>>>>>>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not >>>>> going to >>>>>>>>>> remember to do that until their release build doesn’t work… >>>>>>>>>> >>>>>>>>>> Creating VOs means you can’t simply use JSON.parse(). You’d >>> need >>>>> your >>>>>>>>>> own >>>>>>>>>> parser for each type of json you’re consuming. OK. Maybe not >>> full >>>>>>>>>> parsing, but the constructors for these VOs will get pretty >>>>> messy — >>>>>>>>>> especially if the structure is a bit fluid. >>>>>>>>>> >>>>>>>>>> Harbs >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs >>> <[email protected]> >>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> In theory, everything you say is true. It might even be good >>>>> practice. >>>>>>>>>>> >>>>>>>>>>> I’m telling you that this was a pain point when migrating my >>>>> app. >>>>>>>>>>> Simply declaring types as VOs didn't solve the problem for >>> me. >>>>> The >>>>> way >>>>>>>>>>> I’ve found that’s needed to solve the problem was passing the >>>>> object >>>>>>>>>>> literal into a VO constructor and declaring the variables >>> using >>>>>>>>>>> bracketed access. I was likely going about it wrong, but it >>> was >>>>> easier >>>>>>>>>>> to just go with the bracketed literals. >>>>>>>>>>> >>>>>>>>>>> Again: Suggesting using VOs (if we can figure out easy >>>>> instructions to >>>>>>>>>>> do so) is probably a good idea and better recommended >>> practice, >>>>> but >>>>>>>>>>> people live on the edge using other JS frameworks, and I’d >>>>> rather >>>>> not >>>>>>>>>>> make it harder than it needs to be if they do want to use >>>>> untyped >>>>>>>>>>> object >>>>>>>>>>> literals. >>>>>>>>>>> >>>>>>>>>>> Harbs >>>>>>>>>>> >>>>>>>>>>>> On Feb 5, 2018, at 8:01 PM, Alex Harui >>>>> <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> It was great to skip type-checking in Flash at times, but >>> the >>>>> runtime >>>>>>>>>>>> was >>>>>>>>>>>> also strongly typed. Also, JS was not a practical language >>> for >>>>>>>>>>>> Flash. >>>>>>>>>>>> It >>>>>>>>>>>> is more risky to do skip type-checking in Royale for JS. >>> These >>>>> new >>>>>>>>>>>> cars >>>>>>>>>>>> with lane warnings are a rough analogy. They only let you >>> be >>>>> less >>>>>>>>>>>> attentive on nice new painted highways. Flash's runtime >>>>> wouldn't >>>>> let >>>>>>>>>>>> you >>>>>>>>>>>> make type mismatches so it effectively had lane lines. JS >>> is a >>>>> road >>>>>>>>>>>> without lane lines. A ValueObject keeps your eyes on the >>> road. >>>>> An >>>>>>>>>>>> ounce >>>>>>>>>>>> of prevention is better than a pound of cure. >>>>>>>>>>>> >>>>>>>>>>>> IMO, you might be better off writing a bead that you can >>> pass a >>>>> JSON >>>>>>>>>>>> object and it will generate the AS class for you to copy >>> from >>>>> the >>>>>>>>>>>> clipboard and paste into a file. Then you could guess at >>> the >>>>> types. >>>>>>>>>>>> That >>>>>>>>>>>> wouldn't require compiler changes and would encourage early >>>>>>>>>>>> prevention. >>>>>>>>>>>> >>>>>>>>>>>> Just an idea, >>>>>>>>>>>> -Alex >>>>>>>>>>>> >>>>>>>>>>>> On 2/5/18, 9:39 AM, "Gabe Harbs" <[email protected]> >>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Yeah. That’s what you’ve argued in the past, and in a pure >>>>> world >>>>>>>>>>>>> you’d be >>>>>>>>>>>>> right. >>>>>>>>>>>>> >>>>>>>>>>>>> However, I’d prefer the option to be practical when dealing >>>>> with >>>>>>>>>>>>> more >>>>>>>>>>>>> data types. Being forced to fiddle with properly typed >>> objects >>>>>>>>>>>>> *always* >>>>>>>>>>>>> is too confining IMO. What I personally ended up doing when >>>>> dealing >>>>>>>>>>>>> with >>>>>>>>>>>>> APIs and the like was the make sure to quote everything in >>> my >>>>> app >>>>>>>>>>>>> rather >>>>>>>>>>>>> than declare VOs even though finding all the instances >>> were a >>>>> pain. >>>>>>>>>>>>> >>>>>>>>>>>>> I think it’s pretty common for folks to use untyped objects >>>>>>>>>>>>> *especially* >>>>>>>>>>>>> when dealing with APIs in classic Flex apps. It seem overly >>>>>>>>>>>>> draconian >>>>>>>>>>>>> to >>>>>>>>>>>>> make that a requirement for Royale. >>>>>>>>>>>>> >>>>>>>>>>>>> Part of the attraction of ActionScript has been that it’s >>>>>>>>>>>>> *optionally* >>>>>>>>>>>>> typed. Minification in JS makes the optional typing pretty >>>>> weak. >>>>>>>>>>>>> >>>>>>>>>>>>>> If you don't care about SWF support, you can quickly make >>>>>>>>>>>>>> ValueObjects >>>>>>>>>>>>>> just for the compiler. >>>>>>>>>>>>> >>>>>>>>>>>>> Quickly? I’m not sure how. >>>>>>>>>>>>> >>>>>>>>>>>>> My $0.02. >>>>>>>>>>>>> Harbs >>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 5, 2018, at 7:28 PM, Alex Harui >>>>> <[email protected] >>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> IMO, your proposal sort of defeats the purpose of >>>>> ActionScript >>>>> and >>>>>>>>>>>>>> Royale, >>>>>>>>>>>>>> which is to provide a type system at compile time. Not >>> only >>>>> should >>>>>>>>>>>>>> you >>>>>>>>>>>>>> want to address your JSON fields, but you should want to >>> have >>>>> them >>>>>>>>>>>>>> type-checked, and that you spelled the field name >>> correctly. >>>>>>>>>>>>>> Otherwise, >>>>>>>>>>>>>> the compiler is going to also allow you to mistype: >>>>>>>>>>>>>> >>>>>>>>>>>>>> var name = myProps["nme"]; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> And there will be no errors. And similarly: >>>>>>>>>>>>>> >>>>>>>>>>>>>> var myObj:Object = { >>>>>>>>>>>>>> nme: "foo", >>>>>>>>>>>>>> age : 30.1415 >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Will be allowed when it probably shouldn't. And also, you >>>>> could >>>>>>>>>>>>>> then >>>>>>>>>>>>>> use >>>>>>>>>>>>>> myObj when you intended to use myOtherObj and nobody will >>>>> know >>>>>>>>>>>>>> until >>>>>>>>>>>>>> you >>>>>>>>>>>>>> try to debug in JS. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you don't care about SWF support, you can quickly make >>>>>>>>>>>>>> ValueObjects >>>>>>>>>>>>>> just for the compiler. In ASDoc, the ValueObject is never >>>>>>>>>>>>>> instantiated. >>>>>>>>>>>>>> It is just like a typedef for the compiler. >>>>>>>>>>>>>> >>>>>>>>>>>>>> HTH, >>>>>>>>>>>>>> -Alex >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/5/18, 8:43 AM, "Gabe Harbs" <[email protected]> >>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> JSON Objects are not destroyed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yeah. I know, but untyped js literals are pretty much >>>>> useless >>>>> in >>>>>>>>>>>>>>> minified >>>>>>>>>>>>>>> Royale apps. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Propose a way to determine that a data structure >>>>>>>>>>>>>>>> is external and what the compiler should generate and >>>>> implement >>>>>>>>>>>>>>>> it. >>>>>>>>>>>>>>>> IMO, >>>>>>>>>>>>>>>> the answer is to create ValueObjects. That is >>> essentially >>>>>>>>>>>>>>>> typedefs >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> AFAIK, there is no way to automate typedef generation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I already made a suggestion once: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For untyped Objects, the compiler could convert dot >>>>> notation to >>>>>>>>>>>>>>> bracket >>>>>>>>>>>>>>> notation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The other half of that would be to convert all object >>>>> literals >>>>> to >>>>>>>>>>>>>>> “quoted” literals automatically. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So if I have a function: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> function parseMyJson(json:String):Object{ >>>>>>>>>>>>>>> return JSON.parse(json); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> var myProps:Object = parseMyJson(json); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> var name:string = myProps.name; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would become: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> function parseMyJson(json){ >>>>>>>>>>>>>>> return JSON.parse(json); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> var myProps = parseMyJson(json); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> var name = myProps["name"]; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And this: >>>>>>>>>>>>>>> var myObj:Object = { >>>>>>>>>>>>>>> name: "foo", >>>>>>>>>>>>>>> age : 30 >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would become: >>>>>>>>>>>>>>> var myObj = { >>>>>>>>>>>>>>> "name": "foo", >>>>>>>>>>>>>>> "age" : 30 >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These two features would have solved almost all >>> minification >>>>>>>>>>>>>>> issues >>>>>>>>>>>>>>> I’ve >>>>>>>>>>>>>>> run into. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’d love to work on this myself, but I’m still not up to >>>>> making >>>>>>>>>>>>>>> any >>>>>>>>>>>>>>> major >>>>>>>>>>>>>>> changes to the compiler… :-( >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Feb 5, 2018, at 6:13 PM, Alex Harui >>>>> <[email protected]> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <[email protected]> >>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I’ll try to work on this. It’s pretty slow loading the >>>>> debug >>>>>>>>>>>>>>>>> build. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I still maintain there should be a compiler setting or >>>>> language >>>>>>>>>>>>>>>>> feature >>>>>>>>>>>>>>>>> to prevent objects produced from JSON being destroyed >>> on >>>>>>>>>>>>>>>>> minification. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> JSON Objects are not destroyed. The code referencing >>> their >>>>>>>>>>>>>>>> fields >>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>> has those names changed. Propose a way to determine >>> that a >>>>> data >>>>>>>>>>>>>>>> structure >>>>>>>>>>>>>>>> is external and what the compiler should generate and >>>>> implement >>>>>>>>>>>>>>>> it. >>>>>>>>>>>>>>>> IMO, >>>>>>>>>>>>>>>> the answer is to create ValueObjects. That is >>> essentially >>>>>>>>>>>>>>>> typedefs >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> AFAIK, there is no way to automate typedef generation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, you can turn off minification for the app as a >>> whole. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Other ideas welcome, >>>>>>>>>>>>>>>> -Alex >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This remains a pain point for developing apps and >>> having >>>>> to >>>>>>>>>>>>>>>>> create >>>>>>>>>>>>>>>>> VOs >>>>>>>>>>>>>>>>> for every API is a drag. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Feb 5, 2018, at 10:21 AM, Alex Harui >>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" >>> <[email protected]> >>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Typo. I meant js-reease. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yeah, at some later point in time someone should build >>>>> Value >>>>>>>>>>>>>>>>>> Objects >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> the JSON and get js-release working. Maybe after this >>>>> release. >>>>>>>>>>>>>>>>>> I'm >>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>> trying to make the ASDoc useful. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm going to add Events to the class detail page and >>>>> anchor >>>>>>>>>>>>>>>>>> links >>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> lists to the details and maybe a simple >>> search-for-class >>>>>>>>>>>>>>>>>> feature, >>>>>>>>>>>>>>>>>> then I >>>>>>>>>>>>>>>>>> think it will be time for a release. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Alex >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Feb 4, 2018, at 8:08 AM, Alex Harui >>>>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Do you mean SWF support? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Carlos Rovira >>>> https://na01.safelinks.protection.outlook.com/?url= >>> http%3A%2F%2Fabout.me%2 >>>> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >>> 7C16f65e18ee564aa421b308d5 >>>> 6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0% >>> 7C636537118603984962&s >>>> data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0 >>> >>> >> >> >> -- >> Carlos Rovira >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2fde110ce8564489482608d5 >> 6f3ebb3a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537237863888227&s >> data=NzRRhywOm8%2FOHplSf0Q3f6dHLc480KaWNxYLScrFpRQ%3D&reserved=0 >
