You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Michael Schmalle <te...@gmail.com> on 2016/03/01 18:40:41 UTC
Forking the Falcon compiler for Starling/Feathers MXML generation
Would I even need to fork it?
I mentioned to Josh that I use MXML and Feathers extensively for these
audio apps I am about to release on Android which means I have a high stake
in the tech at the moment.
That tinkerer side of me feels I could do something about this but I am at
a loss of what I need to do to get the ball rolling.
If I could get this project to work, this would be huge for the project
since the Falcon compiler could actually start to be used in production. It
also means I would have a monetary reason to be able to contribute to the
development and learning deeper of the compiler.
Alex, I need some advice man. :) Where would I even begin?
Below is what I posted on Josh's Feathers SDK issue, just me talking to
myself.
Mike
"
I'm putting this here just so if anybody else reads it and wants to chime
in.
Background; I have worked extensively with the Falcon compiler mainly in
creating/writing the FalconJX compiler FlexJS uses to cross compile AS/MXML
to JS.
The problem I see is that I wrote a traversing framework that was a visitor
and walker implementation which was an abstraction outside of the actual
AST Falcon produces when it parses AS3.
The actual MXML compiler uses JBurg and is completely outside of my
knowledge base. I don't off the top of my head know of any hooks to extend
MXML generation or even how to start.
I do understand "what" the original compiler does as far as setting up AS
to be compiled again so the theory is there for me but I am totally lacking
in the vision from start to end of what I need to do to get Falcon to
produce different byte code since there is no code generation pass.
Anyway, I think this could be HUGE for Starling and Feathers if it could be
done since then we could add a whole bunch of specific things that could
enhance the dynamic nature of constructing a Starling/Feathers
mobile/desktop app."
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Michael Schmalle <te...@gmail.com>.
On Tue, Mar 1, 2016 at 6:48 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/1/16, 3:43 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>
>
> >The problem as you have stated is there are multiple threads running and I
> >can't just go in a rip stuff apart. I don't see why the if blocks of the
> >children as data can't be separated. To me that would make things much
> >more
> >clear for future dev.
>
> If you have the time, go for it.
>
Well it's something I will think about. I can't see doing this right
without getting my hands dirty. It would be in a month or so probably April
but I think the best way for me to figure out what needs to be done is
complete a task like this, will server two purposes, one it will get me
into the code on a low level so I actually understand what I am doing, two
it will create a non cluttered surface so I can see what I want to do.
>
> >
> >Now I remember how this all works, the BURM is calling the directives
> >which
> >then are calling their builders. The BURM is actually traversing the AST
> >of
> >AS3.
>
> I think the Directives call the BURM which calls the reducer which calls
> the emitter. But I could be wrong about that.
>
Yeah you are right, I really meant that the BURM traverses the dark
recesses of the AST like statements and expressions. But yeah, the
directives are calling BURM methods on it's contexts which just ends up
being recursive back on the directive.
>
> >
> >I can't remember without looking but what is parsing the MXML? Is that
> >JFlex?
>
> I don't know for sure, I think it is custom code in MXMLTreeBuilder. I
> don't think it uses one of the parsing libraries but I could definitely be
> wrong. I haven't come across a grammar or even a DTD + XML handler for it.
>
>
Yup it's JFlex
/**
* This class is a scanner generated by
* <a href="http://www.jflex.de/">JFlex</a> 1.6.0
* from the specification file
<tt>C:/Users/Teoti/Documents/ApacheFlex/git/flex-falcon/compiler/src/org/apache/flex/compiler/internal/parsing/mxml/RawMXMLTokenizer.lex</tt>
*/
for RawMXMLTokenizer.java
Mike
> -Alex
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
On 3/1/16, 3:43 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>The problem as you have stated is there are multiple threads running and I
>can't just go in a rip stuff apart. I don't see why the if blocks of the
>children as data can't be separated. To me that would make things much
>more
>clear for future dev.
If you have the time, go for it.
>
>Now I remember how this all works, the BURM is calling the directives
>which
>then are calling their builders. The BURM is actually traversing the AST
>of
>AS3.
I think the Directives call the BURM which calls the reducer which calls
the emitter. But I could be wrong about that.
>
>I can't remember without looking but what is parsing the MXML? Is that
>JFlex?
I don't know for sure, I think it is custom code in MXMLTreeBuilder. I
don't think it uses one of the parsing libraries but I could definitely be
wrong. I haven't come across a grammar or even a DTD + XML handler for it.
-Alex
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Michael Schmalle <te...@gmail.com>.
Yeah when I was speaking about a backend I didn't mean as verbose as the js
backends. I just meant when compiling for say Feathers, why have code even
close to anything Flex SDK. There is a line between MXML AST and Flex
styles, effects, design layer... ehe...
The problem as you have stated is there are multiple threads running and I
can't just go in a rip stuff apart. I don't see why the if blocks of the
children as data can't be separated. To me that would make things much more
clear for future dev.
Now I remember how this all works, the BURM is calling the directives which
then are calling their builders. The BURM is actually traversing the AST of
AS3.
I can't remember without looking but what is parsing the MXML? Is that
JFlex?
Mike
On Tue, Mar 1, 2016 at 6:31 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/1/16, 3:17 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>
> >
> >In my ignorant view right now I would say the goal is to make the MXML
> >compiler have a backend for the framework API hooks, this would be correct
> >in my head, the right way to direct.
>
> Well, better abstraction is probably always good. I don't know if the
> framework abstraction can be completely encapsulated in a "backend". I
> think there is some resolving going on during the building of the AST that
> required knowing what namespaces and classes are being used for data
> binding. So right now there are several things dictated in the
> -config.xml. IMO, it would be just as fine if all of the output
> differences were defined in the -config.xml file so that there was just
> one backend for mxml-children-as-data. The name of the flag has meaning:
> I think the goal is to not have the compiler generate code for MXML, but
> rather generate data that the framework can turn into code.
>
> Then you could compile your app with a flex-config.xml and switch to a
> feathers-config.xml and it wouldn't change too much of the internal logic.
>
> There is a potential runtime advantage to MXML as data as well. With
> MXMLC, all of the generated code is run once (and in Flash/AIR
> JIT-compiled once as well) which is wasteful. With MXML as data, there is
> no generated code to run and JIT compile once, the code that "interprets"
> the data gets run many times which is a better use of JIT compilation and
> supposedly the runtime optimizations in the browser.
>
> >
> >I'm only guessing right now but some of my guesses have worked out pretty
> >well. :)
>
> Yes they have, and I'm very interested in what you will come up with in
> this regard.
>
> Thanks,
> -Alex
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
On 3/1/16, 3:17 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>
>In my ignorant view right now I would say the goal is to make the MXML
>compiler have a backend for the framework API hooks, this would be correct
>in my head, the right way to direct.
Well, better abstraction is probably always good. I don't know if the
framework abstraction can be completely encapsulated in a "backend". I
think there is some resolving going on during the building of the AST that
required knowing what namespaces and classes are being used for data
binding. So right now there are several things dictated in the
-config.xml. IMO, it would be just as fine if all of the output
differences were defined in the -config.xml file so that there was just
one backend for mxml-children-as-data. The name of the flag has meaning:
I think the goal is to not have the compiler generate code for MXML, but
rather generate data that the framework can turn into code.
Then you could compile your app with a flex-config.xml and switch to a
feathers-config.xml and it wouldn't change too much of the internal logic.
There is a potential runtime advantage to MXML as data as well. With
MXMLC, all of the generated code is run once (and in Flash/AIR
JIT-compiled once as well) which is wasteful. With MXML as data, there is
no generated code to run and JIT compile once, the code that "interprets"
the data gets run many times which is a better use of JIT compilation and
supposedly the runtime optimizations in the browser.
>
>I'm only guessing right now but some of my guesses have worked out pretty
>well. :)
Yes they have, and I'm very interested in what you will come up with in
this regard.
Thanks,
-Alex
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Michael Schmalle <te...@gmail.com>.
On Tue, Mar 1, 2016 at 6:11 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/1/16, 2:32 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>
> >>
> >> >
> >> >What does -mxml-children-as-data actually do? Does it output something?
> >>
> >> It tells the compiler to generate these data structures and API calls
> >> instead of generating the Flex SDK code that MXMLC does.
> >>
> >>
> >Ok, so the MXML compiler "does" have ties to the Flex SDK API but not
> >directly in the directives correct?
>
> Well, when you look in MXMLClassDirectiveProcessor you will see lots of
> code forks for when -mxml-children-as-data is true. I suppose at some
> point someone could do more refactoring to clean it up. It just hasn't
> been a priority. One side of the fork generates the MXMLC code, the other
> generates the data structures I've described in this thread.
>
>
Yup, carrying on from my last post I already had an intuition that class
needs to be refactored and abstracted for the very same reason you stated.
I can imagine what it would look like if you ripped all the Flex SDK out
and placed it into a FlexClassDirective and used a strategy to call it.
It seems to me that this would be somewhat of a backend like we have with
JS and AS in the FlaconJX framework.
What is really kewl is I think I will actually be a ble to do this and
maybe break it a part to be able to add those flags that would direct the
compiler which way to actually generate the hooks.
In my ignorant view right now I would say the goal is to make the MXML
compiler have a backend for the framework API hooks, this would be correct
in my head, the right way to direct.
I'm only guessing right now but some of my guesses have worked out pretty
well. :)
Mike
> -Alex
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
On 3/1/16, 2:32 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>>
>> >
>> >What does -mxml-children-as-data actually do? Does it output something?
>>
>> It tells the compiler to generate these data structures and API calls
>> instead of generating the Flex SDK code that MXMLC does.
>>
>>
>Ok, so the MXML compiler "does" have ties to the Flex SDK API but not
>directly in the directives correct?
Well, when you look in MXMLClassDirectiveProcessor you will see lots of
code forks for when -mxml-children-as-data is true. I suppose at some
point someone could do more refactoring to clean it up. It just hasn't
been a priority. One side of the fork generates the MXMLC code, the other
generates the data structures I've described in this thread.
-Alex
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Michael Schmalle <te...@gmail.com>.
On Tue, Mar 1, 2016 at 5:27 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/1/16, 2:08 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>
> >Hmm, interesting. There are a couple things here I misinterpreted from my
> >journey through the code a couple years ago.
> >
> >It's great to hear that there are no dependencies, I think one major thing
> >Josh had to do was mangle how Event was handled since MXMLC required
> >flash.events.Event for bindings.
> >
> >So basically it's synthesizing implementation calls that the sub framework
> >must implement to use it's children API IE in Feathers it would be
> >addChild() of the Starling framework.
> >
> >From what you have written, it seems like this might now be as hard as I
> >originally thought. I guess i need to open Eclipse and look at the code.
>
> Rats, you were supposed to get the impression that it would be easy. But
> you might be right that it is hard. I don't know the Starling/Feathers
> code. The main file to look at is MXMLClassDirectiveProcessor
>
>
HAHA I made a typo, where I wrote "now" I meant "not". :)
> >
> >So generateMXMLAttributes() is setting instance properties on StarlingApp?
>
> All it does is hand in the properties, styles and events on the top-level
> tag. What the implementation does is up to the framework.
>
Ok, I am not sounding eloquent today, I guess that is what I meant, it
passes properties that must be set on the instance by the implementing
framework.
>
> >
> >What does -mxml-children-as-data actually do? Does it output something?
>
> It tells the compiler to generate these data structures and API calls
> instead of generating the Flex SDK code that MXMLC does.
>
>
Ok, so the MXML compiler "does" have ties to the Flex SDK API but not
directly in the directives correct? I know, I know I should just look at
the code again. :)
Mike
> -Alex
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
On 3/1/16, 2:08 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>Hmm, interesting. There are a couple things here I misinterpreted from my
>journey through the code a couple years ago.
>
>It's great to hear that there are no dependencies, I think one major thing
>Josh had to do was mangle how Event was handled since MXMLC required
>flash.events.Event for bindings.
>
>So basically it's synthesizing implementation calls that the sub framework
>must implement to use it's children API IE in Feathers it would be
>addChild() of the Starling framework.
>
>From what you have written, it seems like this might now be as hard as I
>originally thought. I guess i need to open Eclipse and look at the code.
Rats, you were supposed to get the impression that it would be easy. But
you might be right that it is hard. I don't know the Starling/Feathers
code. The main file to look at is MXMLClassDirectiveProcessor
>
>So generateMXMLAttributes() is setting instance properties on StarlingApp?
All it does is hand in the properties, styles and events on the top-level
tag. What the implementation does is up to the framework.
>
>What does -mxml-children-as-data actually do? Does it output something?
It tells the compiler to generate these data structures and API calls
instead of generating the Flex SDK code that MXMLC does.
-Alex
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Michael Schmalle <te...@gmail.com>.
Hmm, interesting. There are a couple things here I misinterpreted from my
journey through the code a couple years ago.
It's great to hear that there are no dependencies, I think one major thing
Josh had to do was mangle how Event was handled since MXMLC required
flash.events.Event for bindings.
So basically it's synthesizing implementation calls that the sub framework
must implement to use it's children API IE in Feathers it would be
addChild() of the Starling framework.
>From what you have written, it seems like this might now be as hard as I
originally thought. I guess i need to open Eclipse and look at the code.
So generateMXMLAttributes() is setting instance properties on StarlingApp?
What does -mxml-children-as-data actually do? Does it output something?
Mike
On Tue, Mar 1, 2016 at 4:35 PM, Alex Harui <ah...@adobe.com> wrote:
> I don't know what Josh did to MXMLC to get it to work for
> Starling/Feathers. I have encouraged him in the past to try to work
> directly with the Falcon output. IMO, MXMLC should be abandoned.
>
> Falcon supposedly has no real ties to any particular ActionScript
> framework. MXMLC generated code that expected the Flex SDK to be around.
>
> Maybe the best place to start is with a simple Starling/Feathers app
> written with some MXML and AS. Run it through Falcon with
> -mxml-children-as-data and see what you get. It won't run right away, but
> will give us tangible issues to discuss. In theory, you won't need to
> touch any of the JBurg stuff at all. The MXML reduction does not use
> JBurg except for any AS code in event handlers and script blocks.
>
> What Falcon currently does is add one method and a few new properties to
> the subclass. So for some MXML like
>
> ---- MyApp.mxml ----
> <StarlingApp width="900" height="600">
> <FeathersComponent id="foo" label="bar" />
> </StarlingApp>
> ---- MyApp.mxml ----
>
> The effective output (because there is no generated AS output from Falcon)
> is something like:
>
> public class MyApp extends StarlingApp
> {
> public function MyApp()
> {
> super();
> generateMXMLAttributes([2, "width", false, 900, "height", false,
> 600]);
> }
>
> override public function get MXMLDescriptor():Array
> {
> return [1, FeathersComponent, 2, "id", false, "foo", "label",
> false, "bar"];
> }
> }
>
> IOW, any base-class for an MXML file must support:
>
> public function generateMXMLAttributes(data:Array):void
>
> public function get MXMLDescriptor():Array;
>
>
> Another property called mxmlsd is added for state-dependent nodes. Not
> sure if you will need that.
>
> There might even be a better way to do this, and better names. The reason
> it is this way is because I think it is better to have some requirements
> on the base classes of the framework rather than have the output assume
> other kinds of lifecycle calls: addElement vs addChild, when to
> instantiate child nodes, etc. By passing in MXML as data, the framework
> gets to decide when to actually apply properties, map them to different
> things, etc.
>
> HTH,
> -Alex
>
> On 3/1/16, 9:40 AM, "Michael Schmalle" <te...@gmail.com> wrote:
>
> >Would I even need to fork it?
> >
> >I mentioned to Josh that I use MXML and Feathers extensively for these
> >audio apps I am about to release on Android which means I have a high
> >stake
> >in the tech at the moment.
> >
> >That tinkerer side of me feels I could do something about this but I am at
> >a loss of what I need to do to get the ball rolling.
> >
> >If I could get this project to work, this would be huge for the project
> >since the Falcon compiler could actually start to be used in production.
> >It
> >also means I would have a monetary reason to be able to contribute to the
> >development and learning deeper of the compiler.
> >
> >Alex, I need some advice man. :) Where would I even begin?
> >
> >Below is what I posted on Josh's Feathers SDK issue, just me talking to
> >myself.
> >
> >Mike
> >
> >"
> >
> >I'm putting this here just so if anybody else reads it and wants to chime
> >in.
> >
> >Background; I have worked extensively with the Falcon compiler mainly in
> >creating/writing the FalconJX compiler FlexJS uses to cross compile
> >AS/MXML
> >to JS.
> >
> >The problem I see is that I wrote a traversing framework that was a
> >visitor
> >and walker implementation which was an abstraction outside of the actual
> >AST Falcon produces when it parses AS3.
> >
> >The actual MXML compiler uses JBurg and is completely outside of my
> >knowledge base. I don't off the top of my head know of any hooks to extend
> >MXML generation or even how to start.
> >
> >I do understand "what" the original compiler does as far as setting up AS
> >to be compiled again so the theory is there for me but I am totally
> >lacking
> >in the vision from start to end of what I need to do to get Falcon to
> >produce different byte code since there is no code generation pass.
> >
> >Anyway, I think this could be HUGE for Starling and Feathers if it could
> >be
> >done since then we could add a whole bunch of specific things that could
> >enhance the dynamic nature of constructing a Starling/Feathers
> >mobile/desktop app."
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Michael Schmalle <te...@gmail.com>.
Alex, I think you have known me long enough o see where I am headed with
this. I agree with everything you have said and it's more of a conceptual
issue with me right now. I have definitely proven to myself that once I
figure out the actual problem I can usually solve it pretty quick.
I guess it's that I don't have the compiler setup right now to do a simple
test so I am still in the dark. I did look at
MXMLClassDirectiveProcessorand the light bulb went on, I remember looking
at this class extensively years ago.
So my main thought is what you have side, the compiler MXML, should require
an interface which it seems it does, the framework should hook into it
without worrying about anything. TO me a well design compiler would do this
and if it doesn't it wasn't designed the way we need it.
Mike
On Tue, Mar 1, 2016 at 6:07 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 3/1/16, 2:30 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>
> >Hey Om,
> >
> >This is all purely hypothetical in my head right now so I may be missing
> >something as well but the first goal is to use Feathers out right, that
> >means hooking into Josh's classes.
>
> I think that's the key. You can continue to have forks of compilers that
> don't require touching existing AS code, or touch and/or wrap the AS code
> so we only need one compiler. I'm hoping to convince folks that the
> latter takes less energy from the greater community.
>
> Of course, if someone can come up with a set of compiler options that
> allows us to dictate enough aspects of the generated code to abstract
> between differences in frameworks that would probably be ok, but IMO it is
> more than just addChild/addElement. In Flex, children are not always
> created at certain points in the lifecycle. There is a concept of
> Navigators that have deferred instantiation: the children are not created
> until you navigate to that Tab or Page. The current Falcon output says
> "here are your child descriptors. You figure out what to do with it".
>
> Another consideration is that unlike the Flex SDK which has MXMLC in the
> code base, Falcon is currently its own code base and potentially its own
> release cycle, so trying to minimize interdependencies between the
> frameworks and compilers seems like a good idea, and almost every bug can
> be fixed by AS developers of the framework; they don't have to learn
> enough about Java and how to build the compiler.
>
> -Alex
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
On 3/1/16, 2:30 PM, "Michael Schmalle" <te...@gmail.com> wrote:
>Hey Om,
>
>This is all purely hypothetical in my head right now so I may be missing
>something as well but the first goal is to use Feathers out right, that
>means hooking into Josh's classes.
I think that's the key. You can continue to have forks of compilers that
don't require touching existing AS code, or touch and/or wrap the AS code
so we only need one compiler. I'm hoping to convince folks that the
latter takes less energy from the greater community.
Of course, if someone can come up with a set of compiler options that
allows us to dictate enough aspects of the generated code to abstract
between differences in frameworks that would probably be ok, but IMO it is
more than just addChild/addElement. In Flex, children are not always
created at certain points in the lifecycle. There is a concept of
Navigators that have deferred instantiation: the children are not created
until you navigate to that Tab or Page. The current Falcon output says
"here are your child descriptors. You figure out what to do with it".
Another consideration is that unlike the Flex SDK which has MXMLC in the
code base, Falcon is currently its own code base and potentially its own
release cycle, so trying to minimize interdependencies between the
frameworks and compilers seems like a good idea, and almost every bug can
be fixed by AS developers of the framework; they don't have to learn
enough about Java and how to build the compiler.
-Alex
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Michael Schmalle <te...@gmail.com>.
Hey Om,
This is all purely hypothetical in my head right now so I may be missing
something as well but the first goal is to use Feathers out right, that
means hooking into Josh's classes. He does use a Bootstrap class to start
the app and that is what you are talking about with Application, that is
the boostrap, but from there is has not much else.
But I am not going to say much more until I get my head around the actual
problem which I don't have, just wanted to throw this out there.
Mike
On Tue, Mar 1, 2016 at 5:16 PM, OmPrakash Muppirala <bi...@gmail.com>
wrote:
> If I may, there might be a better approach by just doing it within the
> FlexJS framework. You should be able to create a
> org.apache.flex.starling.Application.as class where a starling display
> list
> is used instead of the regular display list. You can follow the pattern
> that the org.apache.flex.jquery.Application.as or
> org.apache.flex.createjs.Application.as follows.
>
> Once you have the basic application setup, you should be able to construct
> individual components and use the Starling display list as you go. You
> might have to create a new version of UIBase (and possible other classes)
> to use the starling display list instead.
>
> And theoretically, for each of these starling based classes, you could have
> the COMPILE::JS versions that do the same/similar thing on Canvas/WebGL.
> Something along the lines of https://github.com/matrix3d/spriteflexjs
>
> Just a thought. I might be missing something big here.
>
> Thanks,
> Om
>
> On Tue, Mar 1, 2016 at 1:35 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > I don't know what Josh did to MXMLC to get it to work for
> > Starling/Feathers. I have encouraged him in the past to try to work
> > directly with the Falcon output. IMO, MXMLC should be abandoned.
> >
> > Falcon supposedly has no real ties to any particular ActionScript
> > framework. MXMLC generated code that expected the Flex SDK to be around.
> >
> > Maybe the best place to start is with a simple Starling/Feathers app
> > written with some MXML and AS. Run it through Falcon with
> > -mxml-children-as-data and see what you get. It won't run right away,
> but
> > will give us tangible issues to discuss. In theory, you won't need to
> > touch any of the JBurg stuff at all. The MXML reduction does not use
> > JBurg except for any AS code in event handlers and script blocks.
> >
> > What Falcon currently does is add one method and a few new properties to
> > the subclass. So for some MXML like
> >
> > ---- MyApp.mxml ----
> > <StarlingApp width="900" height="600">
> > <FeathersComponent id="foo" label="bar" />
> > </StarlingApp>
> > ---- MyApp.mxml ----
> >
> > The effective output (because there is no generated AS output from
> Falcon)
> > is something like:
> >
> > public class MyApp extends StarlingApp
> > {
> > public function MyApp()
> > {
> > super();
> > generateMXMLAttributes([2, "width", false, 900, "height", false,
> > 600]);
> > }
> >
> > override public function get MXMLDescriptor():Array
> > {
> > return [1, FeathersComponent, 2, "id", false, "foo", "label",
> > false, "bar"];
> > }
> > }
> >
> > IOW, any base-class for an MXML file must support:
> >
> > public function generateMXMLAttributes(data:Array):void
> >
> > public function get MXMLDescriptor():Array;
> >
> >
> > Another property called mxmlsd is added for state-dependent nodes. Not
> > sure if you will need that.
> >
> > There might even be a better way to do this, and better names. The
> reason
> > it is this way is because I think it is better to have some requirements
> > on the base classes of the framework rather than have the output assume
> > other kinds of lifecycle calls: addElement vs addChild, when to
> > instantiate child nodes, etc. By passing in MXML as data, the framework
> > gets to decide when to actually apply properties, map them to different
> > things, etc.
> >
> > HTH,
> > -Alex
> >
> > On 3/1/16, 9:40 AM, "Michael Schmalle" <te...@gmail.com>
> wrote:
> >
> > >Would I even need to fork it?
> > >
> > >I mentioned to Josh that I use MXML and Feathers extensively for these
> > >audio apps I am about to release on Android which means I have a high
> > >stake
> > >in the tech at the moment.
> > >
> > >That tinkerer side of me feels I could do something about this but I am
> at
> > >a loss of what I need to do to get the ball rolling.
> > >
> > >If I could get this project to work, this would be huge for the project
> > >since the Falcon compiler could actually start to be used in production.
> > >It
> > >also means I would have a monetary reason to be able to contribute to
> the
> > >development and learning deeper of the compiler.
> > >
> > >Alex, I need some advice man. :) Where would I even begin?
> > >
> > >Below is what I posted on Josh's Feathers SDK issue, just me talking to
> > >myself.
> > >
> > >Mike
> > >
> > >"
> > >
> > >I'm putting this here just so if anybody else reads it and wants to
> chime
> > >in.
> > >
> > >Background; I have worked extensively with the Falcon compiler mainly in
> > >creating/writing the FalconJX compiler FlexJS uses to cross compile
> > >AS/MXML
> > >to JS.
> > >
> > >The problem I see is that I wrote a traversing framework that was a
> > >visitor
> > >and walker implementation which was an abstraction outside of the actual
> > >AST Falcon produces when it parses AS3.
> > >
> > >The actual MXML compiler uses JBurg and is completely outside of my
> > >knowledge base. I don't off the top of my head know of any hooks to
> extend
> > >MXML generation or even how to start.
> > >
> > >I do understand "what" the original compiler does as far as setting up
> AS
> > >to be compiled again so the theory is there for me but I am totally
> > >lacking
> > >in the vision from start to end of what I need to do to get Falcon to
> > >produce different byte code since there is no code generation pass.
> > >
> > >Anyway, I think this could be HUGE for Starling and Feathers if it could
> > >be
> > >done since then we could add a whole bunch of specific things that could
> > >enhance the dynamic nature of constructing a Starling/Feathers
> > >mobile/desktop app."
> >
> >
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
On 3/1/16, 2:45 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>On Tue, Mar 1, 2016 at 2:24 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> That's a valid approach as well, but probably has the overhead of
>>wrapping
>> a lot of their classes to conform to IUIBase.
>
>
>Do you mean work overhead? That would be a one time thing, right?
>Or runtime overhead? I doubt if porting over stuff to conform IUIBase
>would
>cause runtime overhead...
Well, if you have to wrap things, I suppose there is at least some runtime
overhead, but I was mainly referring to framework developer effort
required to implement the APIs and patterns expected in IUIBase. The
addChild/addElement thing is probably painful and could be confusing to
existing developers.
The other thing they would get, though is swappability. If they wrap
enough of Feathers so there is a close match of the existing FlexJS UI
widget APIs, then folks can swap in the Feathers set more easily.
I would love to see someone try it so we understand the costs.
-Alex
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Tue, Mar 1, 2016 at 2:24 PM, Alex Harui <ah...@adobe.com> wrote:
> That's a valid approach as well, but probably has the overhead of wrapping
> a lot of their classes to conform to IUIBase.
Do you mean work overhead? That would be a one time thing, right?
Or runtime overhead? I doubt if porting over stuff to conform IUIBase would
cause runtime overhead...
> You would probably get a lot
> of other things like Binding and States for free though.
>
Yes, biggest advantage is you get MXML support for free since everything is
already set up.
Thanks,
Om
>
> -Alex
>
> On 3/1/16, 2:16 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
> >If I may, there might be a better approach by just doing it within the
> >FlexJS framework. You should be able to create a
> >org.apache.flex.starling.Application.as class where a starling display
> >list
> >is used instead of the regular display list. You can follow the pattern
> >that the org.apache.flex.jquery.Application.as or
> >org.apache.flex.createjs.Application.as follows.
> >
> >Once you have the basic application setup, you should be able to construct
> >individual components and use the Starling display list as you go. You
> >might have to create a new version of UIBase (and possible other classes)
> >to use the starling display list instead.
> >
> >And theoretically, for each of these starling based classes, you could
> >have
> >the COMPILE::JS versions that do the same/similar thing on Canvas/WebGL.
> >Something along the lines of https://github.com/matrix3d/spriteflexjs
> >
> >Just a thought. I might be missing something big here.
> >
> >Thanks,
> >Om
> >
> >On Tue, Mar 1, 2016 at 1:35 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> I don't know what Josh did to MXMLC to get it to work for
> >> Starling/Feathers. I have encouraged him in the past to try to work
> >> directly with the Falcon output. IMO, MXMLC should be abandoned.
> >>
> >> Falcon supposedly has no real ties to any particular ActionScript
> >> framework. MXMLC generated code that expected the Flex SDK to be
> >>around.
> >>
> >> Maybe the best place to start is with a simple Starling/Feathers app
> >> written with some MXML and AS. Run it through Falcon with
> >> -mxml-children-as-data and see what you get. It won't run right away,
> >>but
> >> will give us tangible issues to discuss. In theory, you won't need to
> >> touch any of the JBurg stuff at all. The MXML reduction does not use
> >> JBurg except for any AS code in event handlers and script blocks.
> >>
> >> What Falcon currently does is add one method and a few new properties to
> >> the subclass. So for some MXML like
> >>
> >> ---- MyApp.mxml ----
> >> <StarlingApp width="900" height="600">
> >> <FeathersComponent id="foo" label="bar" />
> >> </StarlingApp>
> >> ---- MyApp.mxml ----
> >>
> >> The effective output (because there is no generated AS output from
> >>Falcon)
> >> is something like:
> >>
> >> public class MyApp extends StarlingApp
> >> {
> >> public function MyApp()
> >> {
> >> super();
> >> generateMXMLAttributes([2, "width", false, 900, "height", false,
> >> 600]);
> >> }
> >>
> >> override public function get MXMLDescriptor():Array
> >> {
> >> return [1, FeathersComponent, 2, "id", false, "foo", "label",
> >> false, "bar"];
> >> }
> >> }
> >>
> >> IOW, any base-class for an MXML file must support:
> >>
> >> public function generateMXMLAttributes(data:Array):void
> >>
> >> public function get MXMLDescriptor():Array;
> >>
> >>
> >> Another property called mxmlsd is added for state-dependent nodes. Not
> >> sure if you will need that.
> >>
> >> There might even be a better way to do this, and better names. The
> >>reason
> >> it is this way is because I think it is better to have some requirements
> >> on the base classes of the framework rather than have the output assume
> >> other kinds of lifecycle calls: addElement vs addChild, when to
> >> instantiate child nodes, etc. By passing in MXML as data, the framework
> >> gets to decide when to actually apply properties, map them to different
> >> things, etc.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 3/1/16, 9:40 AM, "Michael Schmalle" <te...@gmail.com>
> >>wrote:
> >>
> >> >Would I even need to fork it?
> >> >
> >> >I mentioned to Josh that I use MXML and Feathers extensively for these
> >> >audio apps I am about to release on Android which means I have a high
> >> >stake
> >> >in the tech at the moment.
> >> >
> >> >That tinkerer side of me feels I could do something about this but I
> >>am at
> >> >a loss of what I need to do to get the ball rolling.
> >> >
> >> >If I could get this project to work, this would be huge for the project
> >> >since the Falcon compiler could actually start to be used in
> >>production.
> >> >It
> >> >also means I would have a monetary reason to be able to contribute to
> >>the
> >> >development and learning deeper of the compiler.
> >> >
> >> >Alex, I need some advice man. :) Where would I even begin?
> >> >
> >> >Below is what I posted on Josh's Feathers SDK issue, just me talking to
> >> >myself.
> >> >
> >> >Mike
> >> >
> >> >"
> >> >
> >> >I'm putting this here just so if anybody else reads it and wants to
> >>chime
> >> >in.
> >> >
> >> >Background; I have worked extensively with the Falcon compiler mainly
> >>in
> >> >creating/writing the FalconJX compiler FlexJS uses to cross compile
> >> >AS/MXML
> >> >to JS.
> >> >
> >> >The problem I see is that I wrote a traversing framework that was a
> >> >visitor
> >> >and walker implementation which was an abstraction outside of the
> >>actual
> >> >AST Falcon produces when it parses AS3.
> >> >
> >> >The actual MXML compiler uses JBurg and is completely outside of my
> >> >knowledge base. I don't off the top of my head know of any hooks to
> >>extend
> >> >MXML generation or even how to start.
> >> >
> >> >I do understand "what" the original compiler does as far as setting up
> >>AS
> >> >to be compiled again so the theory is there for me but I am totally
> >> >lacking
> >> >in the vision from start to end of what I need to do to get Falcon to
> >> >produce different byte code since there is no code generation pass.
> >> >
> >> >Anyway, I think this could be HUGE for Starling and Feathers if it
> >>could
> >> >be
> >> >done since then we could add a whole bunch of specific things that
> >>could
> >> >enhance the dynamic nature of constructing a Starling/Feathers
> >> >mobile/desktop app."
> >>
> >>
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
That's a valid approach as well, but probably has the overhead of wrapping
a lot of their classes to conform to IUIBase. You would probably get a lot
of other things like Binding and States for free though.
-Alex
On 3/1/16, 2:16 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>If I may, there might be a better approach by just doing it within the
>FlexJS framework. You should be able to create a
>org.apache.flex.starling.Application.as class where a starling display
>list
>is used instead of the regular display list. You can follow the pattern
>that the org.apache.flex.jquery.Application.as or
>org.apache.flex.createjs.Application.as follows.
>
>Once you have the basic application setup, you should be able to construct
>individual components and use the Starling display list as you go. You
>might have to create a new version of UIBase (and possible other classes)
>to use the starling display list instead.
>
>And theoretically, for each of these starling based classes, you could
>have
>the COMPILE::JS versions that do the same/similar thing on Canvas/WebGL.
>Something along the lines of https://github.com/matrix3d/spriteflexjs
>
>Just a thought. I might be missing something big here.
>
>Thanks,
>Om
>
>On Tue, Mar 1, 2016 at 1:35 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> I don't know what Josh did to MXMLC to get it to work for
>> Starling/Feathers. I have encouraged him in the past to try to work
>> directly with the Falcon output. IMO, MXMLC should be abandoned.
>>
>> Falcon supposedly has no real ties to any particular ActionScript
>> framework. MXMLC generated code that expected the Flex SDK to be
>>around.
>>
>> Maybe the best place to start is with a simple Starling/Feathers app
>> written with some MXML and AS. Run it through Falcon with
>> -mxml-children-as-data and see what you get. It won't run right away,
>>but
>> will give us tangible issues to discuss. In theory, you won't need to
>> touch any of the JBurg stuff at all. The MXML reduction does not use
>> JBurg except for any AS code in event handlers and script blocks.
>>
>> What Falcon currently does is add one method and a few new properties to
>> the subclass. So for some MXML like
>>
>> ---- MyApp.mxml ----
>> <StarlingApp width="900" height="600">
>> <FeathersComponent id="foo" label="bar" />
>> </StarlingApp>
>> ---- MyApp.mxml ----
>>
>> The effective output (because there is no generated AS output from
>>Falcon)
>> is something like:
>>
>> public class MyApp extends StarlingApp
>> {
>> public function MyApp()
>> {
>> super();
>> generateMXMLAttributes([2, "width", false, 900, "height", false,
>> 600]);
>> }
>>
>> override public function get MXMLDescriptor():Array
>> {
>> return [1, FeathersComponent, 2, "id", false, "foo", "label",
>> false, "bar"];
>> }
>> }
>>
>> IOW, any base-class for an MXML file must support:
>>
>> public function generateMXMLAttributes(data:Array):void
>>
>> public function get MXMLDescriptor():Array;
>>
>>
>> Another property called mxmlsd is added for state-dependent nodes. Not
>> sure if you will need that.
>>
>> There might even be a better way to do this, and better names. The
>>reason
>> it is this way is because I think it is better to have some requirements
>> on the base classes of the framework rather than have the output assume
>> other kinds of lifecycle calls: addElement vs addChild, when to
>> instantiate child nodes, etc. By passing in MXML as data, the framework
>> gets to decide when to actually apply properties, map them to different
>> things, etc.
>>
>> HTH,
>> -Alex
>>
>> On 3/1/16, 9:40 AM, "Michael Schmalle" <te...@gmail.com>
>>wrote:
>>
>> >Would I even need to fork it?
>> >
>> >I mentioned to Josh that I use MXML and Feathers extensively for these
>> >audio apps I am about to release on Android which means I have a high
>> >stake
>> >in the tech at the moment.
>> >
>> >That tinkerer side of me feels I could do something about this but I
>>am at
>> >a loss of what I need to do to get the ball rolling.
>> >
>> >If I could get this project to work, this would be huge for the project
>> >since the Falcon compiler could actually start to be used in
>>production.
>> >It
>> >also means I would have a monetary reason to be able to contribute to
>>the
>> >development and learning deeper of the compiler.
>> >
>> >Alex, I need some advice man. :) Where would I even begin?
>> >
>> >Below is what I posted on Josh's Feathers SDK issue, just me talking to
>> >myself.
>> >
>> >Mike
>> >
>> >"
>> >
>> >I'm putting this here just so if anybody else reads it and wants to
>>chime
>> >in.
>> >
>> >Background; I have worked extensively with the Falcon compiler mainly
>>in
>> >creating/writing the FalconJX compiler FlexJS uses to cross compile
>> >AS/MXML
>> >to JS.
>> >
>> >The problem I see is that I wrote a traversing framework that was a
>> >visitor
>> >and walker implementation which was an abstraction outside of the
>>actual
>> >AST Falcon produces when it parses AS3.
>> >
>> >The actual MXML compiler uses JBurg and is completely outside of my
>> >knowledge base. I don't off the top of my head know of any hooks to
>>extend
>> >MXML generation or even how to start.
>> >
>> >I do understand "what" the original compiler does as far as setting up
>>AS
>> >to be compiled again so the theory is there for me but I am totally
>> >lacking
>> >in the vision from start to end of what I need to do to get Falcon to
>> >produce different byte code since there is no code generation pass.
>> >
>> >Anyway, I think this could be HUGE for Starling and Feathers if it
>>could
>> >be
>> >done since then we could add a whole bunch of specific things that
>>could
>> >enhance the dynamic nature of constructing a Starling/Feathers
>> >mobile/desktop app."
>>
>>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by OmPrakash Muppirala <bi...@gmail.com>.
If I may, there might be a better approach by just doing it within the
FlexJS framework. You should be able to create a
org.apache.flex.starling.Application.as class where a starling display list
is used instead of the regular display list. You can follow the pattern
that the org.apache.flex.jquery.Application.as or
org.apache.flex.createjs.Application.as follows.
Once you have the basic application setup, you should be able to construct
individual components and use the Starling display list as you go. You
might have to create a new version of UIBase (and possible other classes)
to use the starling display list instead.
And theoretically, for each of these starling based classes, you could have
the COMPILE::JS versions that do the same/similar thing on Canvas/WebGL.
Something along the lines of https://github.com/matrix3d/spriteflexjs
Just a thought. I might be missing something big here.
Thanks,
Om
On Tue, Mar 1, 2016 at 1:35 PM, Alex Harui <ah...@adobe.com> wrote:
> I don't know what Josh did to MXMLC to get it to work for
> Starling/Feathers. I have encouraged him in the past to try to work
> directly with the Falcon output. IMO, MXMLC should be abandoned.
>
> Falcon supposedly has no real ties to any particular ActionScript
> framework. MXMLC generated code that expected the Flex SDK to be around.
>
> Maybe the best place to start is with a simple Starling/Feathers app
> written with some MXML and AS. Run it through Falcon with
> -mxml-children-as-data and see what you get. It won't run right away, but
> will give us tangible issues to discuss. In theory, you won't need to
> touch any of the JBurg stuff at all. The MXML reduction does not use
> JBurg except for any AS code in event handlers and script blocks.
>
> What Falcon currently does is add one method and a few new properties to
> the subclass. So for some MXML like
>
> ---- MyApp.mxml ----
> <StarlingApp width="900" height="600">
> <FeathersComponent id="foo" label="bar" />
> </StarlingApp>
> ---- MyApp.mxml ----
>
> The effective output (because there is no generated AS output from Falcon)
> is something like:
>
> public class MyApp extends StarlingApp
> {
> public function MyApp()
> {
> super();
> generateMXMLAttributes([2, "width", false, 900, "height", false,
> 600]);
> }
>
> override public function get MXMLDescriptor():Array
> {
> return [1, FeathersComponent, 2, "id", false, "foo", "label",
> false, "bar"];
> }
> }
>
> IOW, any base-class for an MXML file must support:
>
> public function generateMXMLAttributes(data:Array):void
>
> public function get MXMLDescriptor():Array;
>
>
> Another property called mxmlsd is added for state-dependent nodes. Not
> sure if you will need that.
>
> There might even be a better way to do this, and better names. The reason
> it is this way is because I think it is better to have some requirements
> on the base classes of the framework rather than have the output assume
> other kinds of lifecycle calls: addElement vs addChild, when to
> instantiate child nodes, etc. By passing in MXML as data, the framework
> gets to decide when to actually apply properties, map them to different
> things, etc.
>
> HTH,
> -Alex
>
> On 3/1/16, 9:40 AM, "Michael Schmalle" <te...@gmail.com> wrote:
>
> >Would I even need to fork it?
> >
> >I mentioned to Josh that I use MXML and Feathers extensively for these
> >audio apps I am about to release on Android which means I have a high
> >stake
> >in the tech at the moment.
> >
> >That tinkerer side of me feels I could do something about this but I am at
> >a loss of what I need to do to get the ball rolling.
> >
> >If I could get this project to work, this would be huge for the project
> >since the Falcon compiler could actually start to be used in production.
> >It
> >also means I would have a monetary reason to be able to contribute to the
> >development and learning deeper of the compiler.
> >
> >Alex, I need some advice man. :) Where would I even begin?
> >
> >Below is what I posted on Josh's Feathers SDK issue, just me talking to
> >myself.
> >
> >Mike
> >
> >"
> >
> >I'm putting this here just so if anybody else reads it and wants to chime
> >in.
> >
> >Background; I have worked extensively with the Falcon compiler mainly in
> >creating/writing the FalconJX compiler FlexJS uses to cross compile
> >AS/MXML
> >to JS.
> >
> >The problem I see is that I wrote a traversing framework that was a
> >visitor
> >and walker implementation which was an abstraction outside of the actual
> >AST Falcon produces when it parses AS3.
> >
> >The actual MXML compiler uses JBurg and is completely outside of my
> >knowledge base. I don't off the top of my head know of any hooks to extend
> >MXML generation or even how to start.
> >
> >I do understand "what" the original compiler does as far as setting up AS
> >to be compiled again so the theory is there for me but I am totally
> >lacking
> >in the vision from start to end of what I need to do to get Falcon to
> >produce different byte code since there is no code generation pass.
> >
> >Anyway, I think this could be HUGE for Starling and Feathers if it could
> >be
> >done since then we could add a whole bunch of specific things that could
> >enhance the dynamic nature of constructing a Starling/Feathers
> >mobile/desktop app."
>
>
Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Posted by Alex Harui <ah...@adobe.com>.
I don't know what Josh did to MXMLC to get it to work for
Starling/Feathers. I have encouraged him in the past to try to work
directly with the Falcon output. IMO, MXMLC should be abandoned.
Falcon supposedly has no real ties to any particular ActionScript
framework. MXMLC generated code that expected the Flex SDK to be around.
Maybe the best place to start is with a simple Starling/Feathers app
written with some MXML and AS. Run it through Falcon with
-mxml-children-as-data and see what you get. It won't run right away, but
will give us tangible issues to discuss. In theory, you won't need to
touch any of the JBurg stuff at all. The MXML reduction does not use
JBurg except for any AS code in event handlers and script blocks.
What Falcon currently does is add one method and a few new properties to
the subclass. So for some MXML like
---- MyApp.mxml ----
<StarlingApp width="900" height="600">
<FeathersComponent id="foo" label="bar" />
</StarlingApp>
---- MyApp.mxml ----
The effective output (because there is no generated AS output from Falcon)
is something like:
public class MyApp extends StarlingApp
{
public function MyApp()
{
super();
generateMXMLAttributes([2, "width", false, 900, "height", false, 600]);
}
override public function get MXMLDescriptor():Array
{
return [1, FeathersComponent, 2, "id", false, "foo", "label",
false, "bar"];
}
}
IOW, any base-class for an MXML file must support:
public function generateMXMLAttributes(data:Array):void
public function get MXMLDescriptor():Array;
Another property called mxmlsd is added for state-dependent nodes. Not
sure if you will need that.
There might even be a better way to do this, and better names. The reason
it is this way is because I think it is better to have some requirements
on the base classes of the framework rather than have the output assume
other kinds of lifecycle calls: addElement vs addChild, when to
instantiate child nodes, etc. By passing in MXML as data, the framework
gets to decide when to actually apply properties, map them to different
things, etc.
HTH,
-Alex
On 3/1/16, 9:40 AM, "Michael Schmalle" <te...@gmail.com> wrote:
>Would I even need to fork it?
>
>I mentioned to Josh that I use MXML and Feathers extensively for these
>audio apps I am about to release on Android which means I have a high
>stake
>in the tech at the moment.
>
>That tinkerer side of me feels I could do something about this but I am at
>a loss of what I need to do to get the ball rolling.
>
>If I could get this project to work, this would be huge for the project
>since the Falcon compiler could actually start to be used in production.
>It
>also means I would have a monetary reason to be able to contribute to the
>development and learning deeper of the compiler.
>
>Alex, I need some advice man. :) Where would I even begin?
>
>Below is what I posted on Josh's Feathers SDK issue, just me talking to
>myself.
>
>Mike
>
>"
>
>I'm putting this here just so if anybody else reads it and wants to chime
>in.
>
>Background; I have worked extensively with the Falcon compiler mainly in
>creating/writing the FalconJX compiler FlexJS uses to cross compile
>AS/MXML
>to JS.
>
>The problem I see is that I wrote a traversing framework that was a
>visitor
>and walker implementation which was an abstraction outside of the actual
>AST Falcon produces when it parses AS3.
>
>The actual MXML compiler uses JBurg and is completely outside of my
>knowledge base. I don't off the top of my head know of any hooks to extend
>MXML generation or even how to start.
>
>I do understand "what" the original compiler does as far as setting up AS
>to be compiled again so the theory is there for me but I am totally
>lacking
>in the vision from start to end of what I need to do to get Falcon to
>produce different byte code since there is no code generation pass.
>
>Anyway, I think this could be HUGE for Starling and Feathers if it could
>be
>done since then we could add a whole bunch of specific things that could
>enhance the dynamic nature of constructing a Starling/Feathers
>mobile/desktop app."