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 >