I think you can set -compiler.compress=false and get Falcon to produce a
SWF that the old swfdump can dump.

On 11/1/14, 10:55 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

>Well I sent the output of the default compiler through the default
>swfdump -abc with the falcon built swf of the same project using
>falcon-swfdump -abc ... unfortunateley I can't really compare the two
>directly. The falcon version is far more readable than the default one
>but is more than twice the size. From a brief look it does seem as if the
>generated code is as it should (even after commenting out the problematic
>code).
>
>Would really need to have a tool that automatically compiles a project
>with both and creates the swfdump of the results in a compareable way as
>my current manual way is rather anoying.
>
>Chris
>
>________________________________________
>Von: Alex Harui <aha...@adobe.com>
>Gesendet: Samstag, 1. November 2014 15:14
>An: dev@flex.apache.org
>Betreff: Re: AW: [FALCON] Bindable interfaces?
>
>On 11/1/14, 6:25 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>
>>Ok ... digging through the handling of Bindable metadata it seems that
>>the code that was causing problems was redundant. The logic in
>>ASCompilationUnit that changed the parent class of classes extending
>>Object seems obsolete because even if commenting out the entire code in
>>ASCompilationUnit binding stil seems to work.
>>
>>So I guess we should remove this particular piece of code from
>>ASCompilationUnit. Probably this would also get rid of the problems I was
>>having.
>
>I would recommend find out where else the change to extend
>IEventDispatcher happens, and then maybe Gordon/Darrell would have a
>better opinion on how it should work.
>
>>
>>Well I tried to compare the generated outputs, but couldn't manage to
>>keep the generated output.
>>While looking for the reason for this, in
>>flex-falcon/compiler/src/org/apache/flex/compiler/config/Configuration.ja
>>v
>>a
>>
>>I could see that the configuration of
>>compiler.keep-generated-actionscript is marked as not supported and isn't
>>implemented at all. I don't quite know how I should compare the output.
>
>It is true that Falcon does not keep-generated-actionscript.  It generates
>ABC directly from the AST.  That allows the opportunity to output ABC
>patterns that don’t have true or readable AS equivalents someday.  I don’t
>think that is done now, but think about tail-call optimizations and things
>like that.
>
>Maybe I wasn’t clear, but I’m trying to say that MXMLC is the gold
>standard.  You want to compare MXMLC’s output with and without [Bindable]
>and then teach Falcon to do the same.  Keep-generated-actionscript should
>work there for a lot of it, but I would also use SWFDump -abc to see
>things that aren’t apparent in the generated AS.
>
>-Alex
>

Reply via email to