You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/12/01 00:04:14 UTC
Re: [FlaconJS] pseudo emitter algorithm
OK, what did I write that is confusing everybody?
IIUC, MXML is parsed into a different set of nodes which are then visited in
the tree walk to generate ABC codes directly. When compiling the AS in an
MXML script block or a .AS file, the AS AST nodes go through Jburg and
eventually become ABC.
FalconJS only overrides the AS AST nodes to generate JS. I don't think it
will generate anything for MXML, but I haven't tried it.
MXML -> ABC is mostly or all in MXMLClassDirectiveProcessor.java.
I think FalconJS will have to swap/overlay/override what that class does to
generate JS.
What MXML currently resolves to in ABC is the equivalent of a bunch of
functions that construct the tags in the MXML. For many reasons which I
have mentioned before, I am planning to change the ABC that it generates to
generate a data structure. And then FalconJS will need to generate the same
data structure in JS.
Does that help?
On 11/30/12 2:51 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> I'm trying to follow, but I feel the same.
>
> My main confusion came from the one thing. I've got in my mind AST is
> just AST. Abstract by definition. It represents a code logic in abstract
> form.
> Why JS would collide with AS? Why the Falcon after AST coming back to
> AS? AST says, create class, create method, create method body,
> expression and evaluate it.
> And now if JS is a target should have grammar definition how to create a
> class, method and represent evaluation. Am I missing a point of
> compilers, parsers etc?
>
>
> On 11/30/2012 7:41 PM, Michael Schmalle wrote:
>> Ok, I'm a bit confused but my brain is probably going to explode any
>> minute and that is about all from me for a bit.
>>
>> I'll just sit back and see if any other conversations come up about as
>> -> js. Maybe I'm crazy and just want to create more work for myself.
>>
>> Maybe the way it stands ABC -> js is good enough for now?
>>
>> Mike
>>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>>
>>> On 11/30/12 11:05 AM, "Michael Schmalle" <ap...@teotigraphix.com>
>>> wrote:
>>>
>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>
>>>>> I don't object to generating a data structure for V11, but I think
>>>>> that it makes more sense to do that as a second phase after ABC
>>>>> generation is working. Otherwise there are a lot of moving parts and
>>>>> progress will be slower.
>>>>
>>>> Correct me if I'm wrong Alex, but Gordon, I think Alex was talking
>>>> about JavaScript data structures produced during crosscompile of MXML.
>>> No, for both AS and JS so we have the same code paths. But fear not,
>>> the
>>> the work I did last year has a switch and all the old code paths are
>>> retained.
>>>
>>> I accept Gordon's argument that we can finish MXML handling faster by
>>> getting Falcon to generate the old code patterns.
>>>>
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Thanks Gordon, you have convinced me to learn JBurg and it's grammar.
I have enough knowledge of antlr to know sometimes rewriting
algorithms are faster.
In a way, I bet that JBurg is a lot like antlrs rewritting syntax and
idea, which I have a lot of experience with. I'm sure it's a lot like
antlrs tree walker generator (but different :) ).
Enough time has gone by for me to see the wrong assumption I made
about SWFs involvement in the generation.
Mike
Quoting Gordon Smith <go...@adobe.com>:
>> I don't know SWF format and JBurg
>
> The SWF and ABC formats are irrelevant if you want to generate JS
> code, so you wouldn't need to learn them.
>
> If you don't want to learn about the BURM I suppose you could try
> generating JS code directly from the AST. I don't know enough about
> FalconJS to know whether the BURM approach produces more efficient
> code. Understanding the BURM is not terribly hard, though. There are
> three main ideas:
>
> 1. A BURM pattern like
>
> Pattern labeledBreakStmt
> BreakID(IdentifierID(void));
>
> describes a subtree within the AST; in this case, it is describing
> the subtree
>
> BreakNode
> IdentifierNode
>
> that represents code like "break foo";
>
> 2. A BURM rule like
>
> statement = Pattern labeledBreakStmt: 0
> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>
> tells the BURM what to do when it finds such a subtree: namely, call
> the Java method reduce_labeledBreakStmt() in the
> ASGeneratingReducer, which has a slew of "reduce_XXX()" methods for
> reducing various subtrees.
>
> 3. The result of a "reduction" can be any Java object which somehow
> represents the subtree that got reduced. Often this is an
> InstructionList but it can be anything. This Java object can then be
> used in other patterns to describe more general or recursive
> patterns, as in
>
> Pattern blockStmt
> BlockID(statement stmts*);
>
> For example, this says that a block statement is a BlockNode with
> multiple child nodes which have been reduced to a 'statement'.
>
> The BURM patterns and rules should be mostly the same whether you
> are generating ABC or JS, because they depend on the AS node
> patterns that are being noticed and reduced. So I really think you'd
> be doing most of your work inside the JSGeneratingReducer. I believe
> this was Bernd's approach when he developed FalconJS. You just make
> the reduce_XXX() method produce JS strings rather than ABC
> InstructionLists.
>
> - Gordon
>
> -----Original Message-----
> From: Michael Schmalle [mailto:apache@teotigraphix.com]
> Sent: Friday, November 30, 2012 4:11 PM
> To: flex-dev@incubator.apache.org
> Subject: RE: [FlaconJS] pseudo emitter algorithm
>
> Quoting Gordon Smith <go...@adobe.com>:
>
>> I didn't follow the whole discussion. Is the issue that you were
>> planning to work on MXML->JS but Alex and I think
>> MXML->datastructure is a better approach? You don't have to accept
>> what we say. :)
>>
>> - Gordon
>
> The conversation was about exploring a straight AST to JS convertor
> and bypassing the JS emitting using SWF reducer.
>
> My point was in the discussion that I don't know SWF format and JBurg
> so trying to maintain FalconJS in it's current state would be hard for
> a lot of developers.
>
> A lot of cross compilers just work with the straight AST in our case
> the IASNode or IDefinition frameworks.
>
> I also thought having this ability would allow other targets to be
> implemented more quickly IE Java android or something...
>
> What do you think?
>
>
>> -----Original Message-----
>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>> Sent: Friday, November 30, 2012 3:55 PM
>> To: flex-dev@incubator.apache.org
>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>
>> Well considering the conversation between you two, I will ditch
>> pretty much all I said in the last 3 days. This is what I get for
>> living on a mountain...
>>
>> I have interest in the non-flash player stuff, so I guess I will
>> keep up with your conversations.
>>
>> For now, I will focus on testing the compiler and trying to get in a
>> groove somehow dealing with that. I'm going to try and document more
>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>> wrong in places.
>>
>> And, I will try to really understand Alex's prototype and see if I
>> can get my brain wrapped around that to help with some simple test
>> components.
>>
>> Mike
>>
>> Quoting Gordon Smith <go...@adobe.com>:
>>
>>> That sounds fine. We'll work in parallel:
>>>
>>> Me: MXML->ABC
>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>
>>> - Gordon
>>>
>>> -----Original Message-----
>>> From: Alex Harui [mailto:aharui@adobe.com]
>>> Sent: Friday, November 30, 2012 3:29 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>
>>>
>>>
>>>
>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>
>>>> MXML->JS doesn't exist and is not the way to go.
>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>> MXML->interpretation
>>>> by JS and later for interpretation by an ABC library written in AS.
>>> I'm pretty sure I had this all working last year in AS. I just have
>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>> so I will probably do the AS version first, but I will be keeping all
>>> of the old ABC code paths around. Right now there is some global flag
>>> that determines which code paths to go down. I might tie that to some
>>> new property in flex-config.xml or something like that.
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
That's right.
Sent from my iPad
On Dec 2, 2012, at 12:12 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Does this mean like expression statements first, statements second,
> blocks next etc?
>
> Mike
>
> Quoting Gordon Smith <go...@adobe.com>:
>
>> The bottom-upness of the BURM means that subtrees that are nearer to
>> the leaves of the AST get reduced before subtrees that nearer to the
>> root. Trees in computer science grow from the top down.
>>
>> Sent from my iPad
>>
>> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>> Interesting. Someday I will figure out what is bottom up about it.
>>>
>>> Anyway, thanks, and bottoms up!
>>>
>>> -Alex
>>>
>>>
>>> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>
>>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or
>>>> Bottom-Up Rewrite
>>>> Generator generates. A BURM reduces subtrees within an AST to an
>>>> output format
>>>> such as ABC or JS, starting with leaf nodes and working its way upward.
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>
>>>>> BURM? What does that stand for anyway? It might as well have
>>>>> been Burmese.
>>>>> It will take a while to understand :-)
>>>>>
>>>>>
>>>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>
>>>>>>> I don't know SWF format and JBurg
>>>>>>
>>>>>> The SWF and ABC formats are irrelevant if you want to generate
>>>>>> JS code, so
>>>>>> you
>>>>>> wouldn't need to learn them.
>>>>>>
>>>>>> If you don't want to learn about the BURM I suppose you could
>>>>>> try generating
>>>>>> JS code directly from the AST. I don't know enough about FalconJS to know
>>>>>> whether the BURM approach produces more efficient code. Understanding the
>>>>>> BURM
>>>>>> is not terribly hard, though. There are three main ideas:
>>>>>>
>>>>>> 1. A BURM pattern like
>>>>>>
>>>>>> Pattern labeledBreakStmt
>>>>>> BreakID(IdentifierID(void));
>>>>>>
>>>>>> describes a subtree within the AST; in this case, it is describing the
>>>>>> subtree
>>>>>>
>>>>>> BreakNode
>>>>>> IdentifierNode
>>>>>>
>>>>>> that represents code like "break foo";
>>>>>>
>>>>>> 2. A BURM rule like
>>>>>>
>>>>>> statement = Pattern labeledBreakStmt: 0
>>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>>>
>>>>>> tells the BURM what to do when it finds such a subtree: namely, call the
>>>>>> Java
>>>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a
>>>>>> slew
>>>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>>>
>>>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>>>> represents
>>>>>> the subtree that got reduced. Often this is an InstructionList
>>>>>> but it can be
>>>>>> anything. This Java object can then be used in other patterns to describe
>>>>>> more
>>>>>> general or recursive patterns, as in
>>>>>>
>>>>>> Pattern blockStmt
>>>>>> BlockID(statement stmts*);
>>>>>>
>>>>>> For example, this says that a block statement is a BlockNode
>>>>>> with multiple
>>>>>> child nodes which have been reduced to a 'statement'.
>>>>>>
>>>>>> The BURM patterns and rules should be mostly the same whether you are
>>>>>> generating ABC or JS, because they depend on the AS node
>>>>>> patterns that are
>>>>>> being noticed and reduced. So I really think you'd be doing most of your
>>>>>> work
>>>>>> inside the JSGeneratingReducer. I believe this was Bernd's
>>>>>> approach when he
>>>>>> developed FalconJS. You just make the reduce_XXX() method
>>>>>> produce JS strings
>>>>>> rather than ABC InstructionLists.
>>>>>>
>>>>>> - Gordon
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>>>> To: flex-dev@incubator.apache.org
>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>
>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>
>>>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>>>> planning to work on MXML->JS but Alex and I think
>>>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>>>> what we say. :)
>>>>>>>
>>>>>>> - Gordon
>>>>>>
>>>>>> The conversation was about exploring a straight AST to JS convertor
>>>>>> and bypassing the JS emitting using SWF reducer.
>>>>>>
>>>>>> My point was in the discussion that I don't know SWF format and JBurg
>>>>>> so trying to maintain FalconJS in it's current state would be hard for
>>>>>> a lot of developers.
>>>>>>
>>>>>> A lot of cross compilers just work with the straight AST in our case
>>>>>> the IASNode or IDefinition frameworks.
>>>>>>
>>>>>> I also thought having this ability would allow other targets to be
>>>>>> implemented more quickly IE Java android or something...
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>>
>>>>>>> Well considering the conversation between you two, I will ditch
>>>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>>>> living on a mountain...
>>>>>>>
>>>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>>>> keep up with your conversations.
>>>>>>>
>>>>>>> For now, I will focus on testing the compiler and trying to get in a
>>>>>>> groove somehow dealing with that. I'm going to try and document more
>>>>>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>>>>>> wrong in places.
>>>>>>>
>>>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>>>> can get my brain wrapped around that to help with some simple test
>>>>>>> components.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>>
>>>>>>>> That sounds fine. We'll work in parallel:
>>>>>>>>
>>>>>>>> Me: MXML->ABC
>>>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>>>>>
>>>>>>>> - Gordon
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>>>
>>>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>>>> MXML->interpretation
>>>>>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>>>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>>>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>>>>>> so I will probably do the AS version first, but I will be keeping all
>>>>>>>> of the old ABC code paths around. Right now there is some global flag
>>>>>>>> that determines which code paths to go down. I might tie that to some
>>>>>>>> new property in flex-config.xml or something like that.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Alex Harui
>>>>>>>> Flex SDK Team
>>>>>>>> Adobe Systems, Inc.
>>>>>>>> http://blogs.adobe.com/aharui
>>>>>>>
>>>>>>> --
>>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>>> http://www.teotigraphix.com
>>>>>>> http://blog.teotigraphix.com
>>>>>
>>>>> --
>>>>> Alex Harui
>>>>> Flex SDK Team
>>>>> Adobe Systems, Inc.
>>>>> http://blogs.adobe.com/aharui
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Does this mean like expression statements first, statements second,
blocks next etc?
Mike
Quoting Gordon Smith <go...@adobe.com>:
> The bottom-upness of the BURM means that subtrees that are nearer to
> the leaves of the AST get reduced before subtrees that nearer to the
> root. Trees in computer science grow from the top down.
>
> Sent from my iPad
>
> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>> Interesting. Someday I will figure out what is bottom up about it.
>>
>> Anyway, thanks, and bottoms up!
>>
>> -Alex
>>
>>
>> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>
>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or
>>> Bottom-Up Rewrite
>>> Generator generates. A BURM reduces subtrees within an AST to an
>>> output format
>>> such as ABC or JS, starting with leaf nodes and working its way upward.
>>>
>>> Sent from my iPad
>>>
>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>> BURM? What does that stand for anyway? It might as well have
>>>> been Burmese.
>>>> It will take a while to understand :-)
>>>>
>>>>
>>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>
>>>>>> I don't know SWF format and JBurg
>>>>>
>>>>> The SWF and ABC formats are irrelevant if you want to generate
>>>>> JS code, so
>>>>> you
>>>>> wouldn't need to learn them.
>>>>>
>>>>> If you don't want to learn about the BURM I suppose you could
>>>>> try generating
>>>>> JS code directly from the AST. I don't know enough about FalconJS to know
>>>>> whether the BURM approach produces more efficient code. Understanding the
>>>>> BURM
>>>>> is not terribly hard, though. There are three main ideas:
>>>>>
>>>>> 1. A BURM pattern like
>>>>>
>>>>> Pattern labeledBreakStmt
>>>>> BreakID(IdentifierID(void));
>>>>>
>>>>> describes a subtree within the AST; in this case, it is describing the
>>>>> subtree
>>>>>
>>>>> BreakNode
>>>>> IdentifierNode
>>>>>
>>>>> that represents code like "break foo";
>>>>>
>>>>> 2. A BURM rule like
>>>>>
>>>>> statement = Pattern labeledBreakStmt: 0
>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>>
>>>>> tells the BURM what to do when it finds such a subtree: namely, call the
>>>>> Java
>>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a
>>>>> slew
>>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>>
>>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>>> represents
>>>>> the subtree that got reduced. Often this is an InstructionList
>>>>> but it can be
>>>>> anything. This Java object can then be used in other patterns to describe
>>>>> more
>>>>> general or recursive patterns, as in
>>>>>
>>>>> Pattern blockStmt
>>>>> BlockID(statement stmts*);
>>>>>
>>>>> For example, this says that a block statement is a BlockNode
>>>>> with multiple
>>>>> child nodes which have been reduced to a 'statement'.
>>>>>
>>>>> The BURM patterns and rules should be mostly the same whether you are
>>>>> generating ABC or JS, because they depend on the AS node
>>>>> patterns that are
>>>>> being noticed and reduced. So I really think you'd be doing most of your
>>>>> work
>>>>> inside the JSGeneratingReducer. I believe this was Bernd's
>>>>> approach when he
>>>>> developed FalconJS. You just make the reduce_XXX() method
>>>>> produce JS strings
>>>>> rather than ABC InstructionLists.
>>>>>
>>>>> - Gordon
>>>>>
>>>>> -----Original Message-----
>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>
>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>
>>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>>> planning to work on MXML->JS but Alex and I think
>>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>>> what we say. :)
>>>>>>
>>>>>> - Gordon
>>>>>
>>>>> The conversation was about exploring a straight AST to JS convertor
>>>>> and bypassing the JS emitting using SWF reducer.
>>>>>
>>>>> My point was in the discussion that I don't know SWF format and JBurg
>>>>> so trying to maintain FalconJS in it's current state would be hard for
>>>>> a lot of developers.
>>>>>
>>>>> A lot of cross compilers just work with the straight AST in our case
>>>>> the IASNode or IDefinition frameworks.
>>>>>
>>>>> I also thought having this ability would allow other targets to be
>>>>> implemented more quickly IE Java android or something...
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>>> To: flex-dev@incubator.apache.org
>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>
>>>>>> Well considering the conversation between you two, I will ditch
>>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>>> living on a mountain...
>>>>>>
>>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>>> keep up with your conversations.
>>>>>>
>>>>>> For now, I will focus on testing the compiler and trying to get in a
>>>>>> groove somehow dealing with that. I'm going to try and document more
>>>>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>>>>> wrong in places.
>>>>>>
>>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>>> can get my brain wrapped around that to help with some simple test
>>>>>> components.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>
>>>>>>> That sounds fine. We'll work in parallel:
>>>>>>>
>>>>>>> Me: MXML->ABC
>>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>>>>
>>>>>>> - Gordon
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>>
>>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>>> MXML->interpretation
>>>>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>>>>> so I will probably do the AS version first, but I will be keeping all
>>>>>>> of the old ABC code paths around. Right now there is some global flag
>>>>>>> that determines which code paths to go down. I might tie that to some
>>>>>>> new property in flex-config.xml or something like that.
>>>>>>>
>>>>>>> --
>>>>>>> Alex Harui
>>>>>>> Flex SDK Team
>>>>>>> Adobe Systems, Inc.
>>>>>>> http://blogs.adobe.com/aharui
>>>>>>
>>>>>> --
>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>> http://www.teotigraphix.com
>>>>>> http://blog.teotigraphix.com
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Daniel Wasilewski <de...@gmail.com>.
OK, my apology, overreacted a bit. Sometimes I just need to shout up and
read the thing twice...
On 3 December 2012 04:12, Gordon Smith <go...@adobe.com> wrote:
> My statement was overly broad. All I meant was that the acronym BURM
> refers to a tree whose root is at the top. Everyone is free to orient their
> trees as they wish.
>
> Sent from my iPad
>
> On Dec 2, 2012, at 5:35 PM, "Daniel Wasilewski" <de...@gmail.com>
> wrote:
>
> > I do understand differences on conceptual level, but just trying to
> > avoid bold statements as arguments that favours one solution over
> another.
> > Because In computer science on academic level it's all comes down to
> > personal preferences of your teacher unfortunately ;)
> >
> > On 12/2/2012 10:31 PM, Michael Schmalle wrote:
> >> I think the point was;
> >>
> >> - Tree parsers such as the AS3Parser creates a Tree from the parent
> >> node down to child aka Recursive Decent Parser.
> >>
> >> - Tree walkers such as the BURM walk a parse tree from the child nodes
> >> up to the parent IE Bottom Up
> >>
> >> Mike
> >>
> >>
> >> Quoting Daniel Wasilewski <de...@gmail.com>:
> >>
> >>> huh?
> >>>
> >>> In computer science both conventions are adopted afik. Not reserved,
> >>> that someone can say, there is only 1 correct.
> >>> Polish notation or reversed polish notation is correct in computer
> >>> science?
> >>>
> >>> On 12/2/2012 8:07 PM, Gordon Smith wrote:
> >>>> The bottom-upness of the BURM means that subtrees that are nearer to
> >>>> the leaves of the AST get reduced before subtrees that nearer to the
> >>>> root. Trees in computer science grow from the top down.
> >>>>
> >>>> Sent from my iPad
> >>>>
> >>>> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
> >>>>
> >>>>> Interesting. Someday I will figure out what is bottom up about it.
> >>>>>
> >>>>> Anyway, thanks, and bottoms up!
> >>>>>
> >>>>> -Alex
> >>>>>
> >>>>>
> >>>>> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
> >>>>>
> >>>>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or
> >>>>>> Bottom-Up Rewrite
> >>>>>> Generator generates. A BURM reduces subtrees within an AST to an
> >>>>>> output format
> >>>>>> such as ABC or JS, starting with leaf nodes and working its way
> >>>>>> upward.
> >>>>>>
> >>>>>> Sent from my iPad
> >>>>>>
> >>>>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
> >>>>>>
> >>>>>>> BURM? What does that stand for anyway? It might as well have
> >>>>>>> been Burmese.
> >>>>>>> It will take a while to understand :-)
> >>>>>>>
> >>>>>>>
> >>>>>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
> >>>>>>>
> >>>>>>>>> I don't know SWF format and JBurg
> >>>>>>>> The SWF and ABC formats are irrelevant if you want to generate
> >>>>>>>> JS code, so
> >>>>>>>> you
> >>>>>>>> wouldn't need to learn them.
> >>>>>>>>
> >>>>>>>> If you don't want to learn about the BURM I suppose you could
> >>>>>>>> try generating
> >>>>>>>> JS code directly from the AST. I don't know enough about
> >>>>>>>> FalconJS to know
> >>>>>>>> whether the BURM approach produces more efficient code.
> >>>>>>>> Understanding the
> >>>>>>>> BURM
> >>>>>>>> is not terribly hard, though. There are three main ideas:
> >>>>>>>>
> >>>>>>>> 1. A BURM pattern like
> >>>>>>>>
> >>>>>>>> Pattern labeledBreakStmt
> >>>>>>>> BreakID(IdentifierID(void));
> >>>>>>>>
> >>>>>>>> describes a subtree within the AST; in this case, it is
> >>>>>>>> describing the
> >>>>>>>> subtree
> >>>>>>>>
> >>>>>>>> BreakNode
> >>>>>>>> IdentifierNode
> >>>>>>>>
> >>>>>>>> that represents code like "break foo";
> >>>>>>>>
> >>>>>>>> 2. A BURM rule like
> >>>>>>>>
> >>>>>>>> statement = Pattern labeledBreakStmt: 0
> >>>>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
> >>>>>>>>
> >>>>>>>> tells the BURM what to do when it finds such a subtree: namely,
> >>>>>>>> call the
> >>>>>>>> Java
> >>>>>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer,
> >>>>>>>> which has a
> >>>>>>>> slew
> >>>>>>>> of "reduce_XXX()" methods for reducing various subtrees.
> >>>>>>>>
> >>>>>>>> 3. The result of a "reduction" can be any Java object which
> somehow
> >>>>>>>> represents
> >>>>>>>> the subtree that got reduced. Often this is an InstructionList
> >>>>>>>> but it can be
> >>>>>>>> anything. This Java object can then be used in other patterns to
> >>>>>>>> describe
> >>>>>>>> more
> >>>>>>>> general or recursive patterns, as in
> >>>>>>>>
> >>>>>>>> Pattern blockStmt
> >>>>>>>> BlockID(statement stmts*);
> >>>>>>>>
> >>>>>>>> For example, this says that a block statement is a BlockNode
> >>>>>>>> with multiple
> >>>>>>>> child nodes which have been reduced to a 'statement'.
> >>>>>>>>
> >>>>>>>> The BURM patterns and rules should be mostly the same whether
> >>>>>>>> you are
> >>>>>>>> generating ABC or JS, because they depend on the AS node
> >>>>>>>> patterns that are
> >>>>>>>> being noticed and reduced. So I really think you'd be doing most
> >>>>>>>> of your
> >>>>>>>> work
> >>>>>>>> inside the JSGeneratingReducer. I believe this was Bernd's
> >>>>>>>> approach when he
> >>>>>>>> developed FalconJS. You just make the reduce_XXX() method
> >>>>>>>> produce JS strings
> >>>>>>>> rather than ABC InstructionLists.
> >>>>>>>>
> >>>>>>>> - Gordon
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
> >>>>>>>> Sent: Friday, November 30, 2012 4:11 PM
> >>>>>>>> To: flex-dev@incubator.apache.org
> >>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
> >>>>>>>>
> >>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
> >>>>>>>>
> >>>>>>>>> I didn't follow the whole discussion. Is the issue that you were
> >>>>>>>>> planning to work on MXML->JS but Alex and I think
> >>>>>>>>> MXML->datastructure is a better approach? You don't have to
> accept
> >>>>>>>>> what we say. :)
> >>>>>>>>>
> >>>>>>>>> - Gordon
> >>>>>>>> The conversation was about exploring a straight AST to JS
> convertor
> >>>>>>>> and bypassing the JS emitting using SWF reducer.
> >>>>>>>>
> >>>>>>>> My point was in the discussion that I don't know SWF format and
> >>>>>>>> JBurg
> >>>>>>>> so trying to maintain FalconJS in it's current state would be
> >>>>>>>> hard for
> >>>>>>>> a lot of developers.
> >>>>>>>>
> >>>>>>>> A lot of cross compilers just work with the straight AST in our
> >>>>>>>> case
> >>>>>>>> the IASNode or IDefinition frameworks.
> >>>>>>>>
> >>>>>>>> I also thought having this ability would allow other targets to be
> >>>>>>>> implemented more quickly IE Java android or something...
> >>>>>>>>
> >>>>>>>> What do you think?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
> >>>>>>>>> Sent: Friday, November 30, 2012 3:55 PM
> >>>>>>>>> To: flex-dev@incubator.apache.org
> >>>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
> >>>>>>>>>
> >>>>>>>>> Well considering the conversation between you two, I will ditch
> >>>>>>>>> pretty much all I said in the last 3 days. This is what I get for
> >>>>>>>>> living on a mountain...
> >>>>>>>>>
> >>>>>>>>> I have interest in the non-flash player stuff, so I guess I will
> >>>>>>>>> keep up with your conversations.
> >>>>>>>>>
> >>>>>>>>> For now, I will focus on testing the compiler and trying to get
> >>>>>>>>> in a
> >>>>>>>>> groove somehow dealing with that. I'm going to try and document
> >>>>>>>>> more
> >>>>>>>>> of the compiler on the wiki. Gordon feel free the correct me if
> >>>>>>>>> I'm
> >>>>>>>>> wrong in places.
> >>>>>>>>>
> >>>>>>>>> And, I will try to really understand Alex's prototype and see if
> I
> >>>>>>>>> can get my brain wrapped around that to help with some simple
> test
> >>>>>>>>> components.
> >>>>>>>>>
> >>>>>>>>> Mike
> >>>>>>>>>
> >>>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
> >>>>>>>>>
> >>>>>>>>>> That sounds fine. We'll work in parallel:
> >>>>>>>>>>
> >>>>>>>>>> Me: MXML->ABC
> >>>>>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for
> >>>>>>>>>> use in JS
> >>>>>>>>>>
> >>>>>>>>>> - Gordon
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
> >>>>>>>>>> Sent: Friday, November 30, 2012 3:29 PM
> >>>>>>>>>> To: flex-dev@incubator.apache.org
> >>>>>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> MXML->JS doesn't exist and is not the way to go.
> >>>>>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
> >>>>>>>>>>> MXML->interpretation
> >>>>>>>>>>> by JS and later for interpretation by an ABC library written
> >>>>>>>>>>> in AS.
> >>>>>>>>>> I'm pretty sure I had this all working last year in AS. I
> >>>>>>>>>> just have
> >>>>>>>>>> to dust it off. Right now it is easier/faster for me to debug
> >>>>>>>>>> in AS,
> >>>>>>>>>> so I will probably do the AS version first, but I will be
> >>>>>>>>>> keeping all
> >>>>>>>>>> of the old ABC code paths around. Right now there is some
> >>>>>>>>>> global flag
> >>>>>>>>>> that determines which code paths to go down. I might tie that
> >>>>>>>>>> to some
> >>>>>>>>>> new property in flex-config.xml or something like that.
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Alex Harui
> >>>>>>>>>> Flex SDK Team
> >>>>>>>>>> Adobe Systems, Inc.
> >>>>>>>>>> http://blogs.adobe.com/aharui
> >>>>>>>>> --
> >>>>>>>>> Michael Schmalle - Teoti Graphix, LLC
> >>>>>>>>> http://www.teotigraphix.com
> >>>>>>>>> http://blog.teotigraphix.com
> >>>>>>> --
> >>>>>>> Alex Harui
> >>>>>>> Flex SDK Team
> >>>>>>> Adobe Systems, Inc.
> >>>>>>> http://blogs.adobe.com/aharui
> >>>>> --
> >>>>> Alex Harui
> >>>>> Flex SDK Team
> >>>>> Adobe Systems, Inc.
> >>>>> http://blogs.adobe.com/aharui
> >
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
My statement was overly broad. All I meant was that the acronym BURM refers to a tree whose root is at the top. Everyone is free to orient their trees as they wish.
Sent from my iPad
On Dec 2, 2012, at 5:35 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> I do understand differences on conceptual level, but just trying to
> avoid bold statements as arguments that favours one solution over another.
> Because In computer science on academic level it's all comes down to
> personal preferences of your teacher unfortunately ;)
>
> On 12/2/2012 10:31 PM, Michael Schmalle wrote:
>> I think the point was;
>>
>> - Tree parsers such as the AS3Parser creates a Tree from the parent
>> node down to child aka Recursive Decent Parser.
>>
>> - Tree walkers such as the BURM walk a parse tree from the child nodes
>> up to the parent IE Bottom Up
>>
>> Mike
>>
>>
>> Quoting Daniel Wasilewski <de...@gmail.com>:
>>
>>> huh?
>>>
>>> In computer science both conventions are adopted afik. Not reserved,
>>> that someone can say, there is only 1 correct.
>>> Polish notation or reversed polish notation is correct in computer
>>> science?
>>>
>>> On 12/2/2012 8:07 PM, Gordon Smith wrote:
>>>> The bottom-upness of the BURM means that subtrees that are nearer to
>>>> the leaves of the AST get reduced before subtrees that nearer to the
>>>> root. Trees in computer science grow from the top down.
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>
>>>>> Interesting. Someday I will figure out what is bottom up about it.
>>>>>
>>>>> Anyway, thanks, and bottoms up!
>>>>>
>>>>> -Alex
>>>>>
>>>>>
>>>>> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>
>>>>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or
>>>>>> Bottom-Up Rewrite
>>>>>> Generator generates. A BURM reduces subtrees within an AST to an
>>>>>> output format
>>>>>> such as ABC or JS, starting with leaf nodes and working its way
>>>>>> upward.
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>>>
>>>>>>> BURM? What does that stand for anyway? It might as well have
>>>>>>> been Burmese.
>>>>>>> It will take a while to understand :-)
>>>>>>>
>>>>>>>
>>>>>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>>
>>>>>>>>> I don't know SWF format and JBurg
>>>>>>>> The SWF and ABC formats are irrelevant if you want to generate
>>>>>>>> JS code, so
>>>>>>>> you
>>>>>>>> wouldn't need to learn them.
>>>>>>>>
>>>>>>>> If you don't want to learn about the BURM I suppose you could
>>>>>>>> try generating
>>>>>>>> JS code directly from the AST. I don't know enough about
>>>>>>>> FalconJS to know
>>>>>>>> whether the BURM approach produces more efficient code.
>>>>>>>> Understanding the
>>>>>>>> BURM
>>>>>>>> is not terribly hard, though. There are three main ideas:
>>>>>>>>
>>>>>>>> 1. A BURM pattern like
>>>>>>>>
>>>>>>>> Pattern labeledBreakStmt
>>>>>>>> BreakID(IdentifierID(void));
>>>>>>>>
>>>>>>>> describes a subtree within the AST; in this case, it is
>>>>>>>> describing the
>>>>>>>> subtree
>>>>>>>>
>>>>>>>> BreakNode
>>>>>>>> IdentifierNode
>>>>>>>>
>>>>>>>> that represents code like "break foo";
>>>>>>>>
>>>>>>>> 2. A BURM rule like
>>>>>>>>
>>>>>>>> statement = Pattern labeledBreakStmt: 0
>>>>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>>>>>
>>>>>>>> tells the BURM what to do when it finds such a subtree: namely,
>>>>>>>> call the
>>>>>>>> Java
>>>>>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer,
>>>>>>>> which has a
>>>>>>>> slew
>>>>>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>>>>>
>>>>>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>>>>>> represents
>>>>>>>> the subtree that got reduced. Often this is an InstructionList
>>>>>>>> but it can be
>>>>>>>> anything. This Java object can then be used in other patterns to
>>>>>>>> describe
>>>>>>>> more
>>>>>>>> general or recursive patterns, as in
>>>>>>>>
>>>>>>>> Pattern blockStmt
>>>>>>>> BlockID(statement stmts*);
>>>>>>>>
>>>>>>>> For example, this says that a block statement is a BlockNode
>>>>>>>> with multiple
>>>>>>>> child nodes which have been reduced to a 'statement'.
>>>>>>>>
>>>>>>>> The BURM patterns and rules should be mostly the same whether
>>>>>>>> you are
>>>>>>>> generating ABC or JS, because they depend on the AS node
>>>>>>>> patterns that are
>>>>>>>> being noticed and reduced. So I really think you'd be doing most
>>>>>>>> of your
>>>>>>>> work
>>>>>>>> inside the JSGeneratingReducer. I believe this was Bernd's
>>>>>>>> approach when he
>>>>>>>> developed FalconJS. You just make the reduce_XXX() method
>>>>>>>> produce JS strings
>>>>>>>> rather than ABC InstructionLists.
>>>>>>>>
>>>>>>>> - Gordon
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>>>
>>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>>>
>>>>>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>>>>>> planning to work on MXML->JS but Alex and I think
>>>>>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>>>>>> what we say. :)
>>>>>>>>>
>>>>>>>>> - Gordon
>>>>>>>> The conversation was about exploring a straight AST to JS convertor
>>>>>>>> and bypassing the JS emitting using SWF reducer.
>>>>>>>>
>>>>>>>> My point was in the discussion that I don't know SWF format and
>>>>>>>> JBurg
>>>>>>>> so trying to maintain FalconJS in it's current state would be
>>>>>>>> hard for
>>>>>>>> a lot of developers.
>>>>>>>>
>>>>>>>> A lot of cross compilers just work with the straight AST in our
>>>>>>>> case
>>>>>>>> the IASNode or IDefinition frameworks.
>>>>>>>>
>>>>>>>> I also thought having this ability would allow other targets to be
>>>>>>>> implemented more quickly IE Java android or something...
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>>>>
>>>>>>>>> Well considering the conversation between you two, I will ditch
>>>>>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>>>>>> living on a mountain...
>>>>>>>>>
>>>>>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>>>>>> keep up with your conversations.
>>>>>>>>>
>>>>>>>>> For now, I will focus on testing the compiler and trying to get
>>>>>>>>> in a
>>>>>>>>> groove somehow dealing with that. I'm going to try and document
>>>>>>>>> more
>>>>>>>>> of the compiler on the wiki. Gordon feel free the correct me if
>>>>>>>>> I'm
>>>>>>>>> wrong in places.
>>>>>>>>>
>>>>>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>>>>>> can get my brain wrapped around that to help with some simple test
>>>>>>>>> components.
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>>>>
>>>>>>>>>> That sounds fine. We'll work in parallel:
>>>>>>>>>>
>>>>>>>>>> Me: MXML->ABC
>>>>>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for
>>>>>>>>>> use in JS
>>>>>>>>>>
>>>>>>>>>> - Gordon
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>>>>>> MXML->interpretation
>>>>>>>>>>> by JS and later for interpretation by an ABC library written
>>>>>>>>>>> in AS.
>>>>>>>>>> I'm pretty sure I had this all working last year in AS. I
>>>>>>>>>> just have
>>>>>>>>>> to dust it off. Right now it is easier/faster for me to debug
>>>>>>>>>> in AS,
>>>>>>>>>> so I will probably do the AS version first, but I will be
>>>>>>>>>> keeping all
>>>>>>>>>> of the old ABC code paths around. Right now there is some
>>>>>>>>>> global flag
>>>>>>>>>> that determines which code paths to go down. I might tie that
>>>>>>>>>> to some
>>>>>>>>>> new property in flex-config.xml or something like that.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Alex Harui
>>>>>>>>>> Flex SDK Team
>>>>>>>>>> Adobe Systems, Inc.
>>>>>>>>>> http://blogs.adobe.com/aharui
>>>>>>>>> --
>>>>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>>>>> http://www.teotigraphix.com
>>>>>>>>> http://blog.teotigraphix.com
>>>>>>> --
>>>>>>> Alex Harui
>>>>>>> Flex SDK Team
>>>>>>> Adobe Systems, Inc.
>>>>>>> http://blogs.adobe.com/aharui
>>>>> --
>>>>> Alex Harui
>>>>> Flex SDK Team
>>>>> Adobe Systems, Inc.
>>>>> http://blogs.adobe.com/aharui
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Daniel Wasilewski <de...@gmail.com>.
I do understand differences on conceptual level, but just trying to
avoid bold statements as arguments that favours one solution over another.
Because In computer science on academic level it's all comes down to
personal preferences of your teacher unfortunately ;)
On 12/2/2012 10:31 PM, Michael Schmalle wrote:
> I think the point was;
>
> - Tree parsers such as the AS3Parser creates a Tree from the parent
> node down to child aka Recursive Decent Parser.
>
> - Tree walkers such as the BURM walk a parse tree from the child nodes
> up to the parent IE Bottom Up
>
> Mike
>
>
> Quoting Daniel Wasilewski <de...@gmail.com>:
>
>> huh?
>>
>> In computer science both conventions are adopted afik. Not reserved,
>> that someone can say, there is only 1 correct.
>> Polish notation or reversed polish notation is correct in computer
>> science?
>>
>> On 12/2/2012 8:07 PM, Gordon Smith wrote:
>>> The bottom-upness of the BURM means that subtrees that are nearer to
>>> the leaves of the AST get reduced before subtrees that nearer to the
>>> root. Trees in computer science grow from the top down.
>>>
>>> Sent from my iPad
>>>
>>> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>> Interesting. Someday I will figure out what is bottom up about it.
>>>>
>>>> Anyway, thanks, and bottoms up!
>>>>
>>>> -Alex
>>>>
>>>>
>>>> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>
>>>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or
>>>>> Bottom-Up Rewrite
>>>>> Generator generates. A BURM reduces subtrees within an AST to an
>>>>> output format
>>>>> such as ABC or JS, starting with leaf nodes and working its way
>>>>> upward.
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>>
>>>>>> BURM? What does that stand for anyway? It might as well have
>>>>>> been Burmese.
>>>>>> It will take a while to understand :-)
>>>>>>
>>>>>>
>>>>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>
>>>>>>>> I don't know SWF format and JBurg
>>>>>>> The SWF and ABC formats are irrelevant if you want to generate
>>>>>>> JS code, so
>>>>>>> you
>>>>>>> wouldn't need to learn them.
>>>>>>>
>>>>>>> If you don't want to learn about the BURM I suppose you could
>>>>>>> try generating
>>>>>>> JS code directly from the AST. I don't know enough about
>>>>>>> FalconJS to know
>>>>>>> whether the BURM approach produces more efficient code.
>>>>>>> Understanding the
>>>>>>> BURM
>>>>>>> is not terribly hard, though. There are three main ideas:
>>>>>>>
>>>>>>> 1. A BURM pattern like
>>>>>>>
>>>>>>> Pattern labeledBreakStmt
>>>>>>> BreakID(IdentifierID(void));
>>>>>>>
>>>>>>> describes a subtree within the AST; in this case, it is
>>>>>>> describing the
>>>>>>> subtree
>>>>>>>
>>>>>>> BreakNode
>>>>>>> IdentifierNode
>>>>>>>
>>>>>>> that represents code like "break foo";
>>>>>>>
>>>>>>> 2. A BURM rule like
>>>>>>>
>>>>>>> statement = Pattern labeledBreakStmt: 0
>>>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>>>>
>>>>>>> tells the BURM what to do when it finds such a subtree: namely,
>>>>>>> call the
>>>>>>> Java
>>>>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer,
>>>>>>> which has a
>>>>>>> slew
>>>>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>>>>
>>>>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>>>>> represents
>>>>>>> the subtree that got reduced. Often this is an InstructionList
>>>>>>> but it can be
>>>>>>> anything. This Java object can then be used in other patterns to
>>>>>>> describe
>>>>>>> more
>>>>>>> general or recursive patterns, as in
>>>>>>>
>>>>>>> Pattern blockStmt
>>>>>>> BlockID(statement stmts*);
>>>>>>>
>>>>>>> For example, this says that a block statement is a BlockNode
>>>>>>> with multiple
>>>>>>> child nodes which have been reduced to a 'statement'.
>>>>>>>
>>>>>>> The BURM patterns and rules should be mostly the same whether
>>>>>>> you are
>>>>>>> generating ABC or JS, because they depend on the AS node
>>>>>>> patterns that are
>>>>>>> being noticed and reduced. So I really think you'd be doing most
>>>>>>> of your
>>>>>>> work
>>>>>>> inside the JSGeneratingReducer. I believe this was Bernd's
>>>>>>> approach when he
>>>>>>> developed FalconJS. You just make the reduce_XXX() method
>>>>>>> produce JS strings
>>>>>>> rather than ABC InstructionLists.
>>>>>>>
>>>>>>> - Gordon
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>>
>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>>
>>>>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>>>>> planning to work on MXML->JS but Alex and I think
>>>>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>>>>> what we say. :)
>>>>>>>>
>>>>>>>> - Gordon
>>>>>>> The conversation was about exploring a straight AST to JS convertor
>>>>>>> and bypassing the JS emitting using SWF reducer.
>>>>>>>
>>>>>>> My point was in the discussion that I don't know SWF format and
>>>>>>> JBurg
>>>>>>> so trying to maintain FalconJS in it's current state would be
>>>>>>> hard for
>>>>>>> a lot of developers.
>>>>>>>
>>>>>>> A lot of cross compilers just work with the straight AST in our
>>>>>>> case
>>>>>>> the IASNode or IDefinition frameworks.
>>>>>>>
>>>>>>> I also thought having this ability would allow other targets to be
>>>>>>> implemented more quickly IE Java android or something...
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>>>
>>>>>>>> Well considering the conversation between you two, I will ditch
>>>>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>>>>> living on a mountain...
>>>>>>>>
>>>>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>>>>> keep up with your conversations.
>>>>>>>>
>>>>>>>> For now, I will focus on testing the compiler and trying to get
>>>>>>>> in a
>>>>>>>> groove somehow dealing with that. I'm going to try and document
>>>>>>>> more
>>>>>>>> of the compiler on the wiki. Gordon feel free the correct me if
>>>>>>>> I'm
>>>>>>>> wrong in places.
>>>>>>>>
>>>>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>>>>> can get my brain wrapped around that to help with some simple test
>>>>>>>> components.
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>>>
>>>>>>>>> That sounds fine. We'll work in parallel:
>>>>>>>>>
>>>>>>>>> Me: MXML->ABC
>>>>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for
>>>>>>>>> use in JS
>>>>>>>>>
>>>>>>>>> - Gordon
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>>>>
>>>>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>>>>> MXML->interpretation
>>>>>>>>>> by JS and later for interpretation by an ABC library written
>>>>>>>>>> in AS.
>>>>>>>>> I'm pretty sure I had this all working last year in AS. I
>>>>>>>>> just have
>>>>>>>>> to dust it off. Right now it is easier/faster for me to debug
>>>>>>>>> in AS,
>>>>>>>>> so I will probably do the AS version first, but I will be
>>>>>>>>> keeping all
>>>>>>>>> of the old ABC code paths around. Right now there is some
>>>>>>>>> global flag
>>>>>>>>> that determines which code paths to go down. I might tie that
>>>>>>>>> to some
>>>>>>>>> new property in flex-config.xml or something like that.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Alex Harui
>>>>>>>>> Flex SDK Team
>>>>>>>>> Adobe Systems, Inc.
>>>>>>>>> http://blogs.adobe.com/aharui
>>>>>>>> --
>>>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>>>> http://www.teotigraphix.com
>>>>>>>> http://blog.teotigraphix.com
>>>>>> --
>>>>>> Alex Harui
>>>>>> Flex SDK Team
>>>>>> Adobe Systems, Inc.
>>>>>> http://blogs.adobe.com/aharui
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>
>>
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I think the point was;
- Tree parsers such as the AS3Parser creates a Tree from the parent
node down to child aka Recursive Decent Parser.
- Tree walkers such as the BURM walk a parse tree from the child nodes
up to the parent IE Bottom Up
Mike
Quoting Daniel Wasilewski <de...@gmail.com>:
> huh?
>
> In computer science both conventions are adopted afik. Not reserved,
> that someone can say, there is only 1 correct.
> Polish notation or reversed polish notation is correct in computer science?
>
> On 12/2/2012 8:07 PM, Gordon Smith wrote:
>> The bottom-upness of the BURM means that subtrees that are nearer
>> to the leaves of the AST get reduced before subtrees that nearer to
>> the root. Trees in computer science grow from the top down.
>>
>> Sent from my iPad
>>
>> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>> Interesting. Someday I will figure out what is bottom up about it.
>>>
>>> Anyway, thanks, and bottoms up!
>>>
>>> -Alex
>>>
>>>
>>> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>
>>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or
>>>> Bottom-Up Rewrite
>>>> Generator generates. A BURM reduces subtrees within an AST to an
>>>> output format
>>>> such as ABC or JS, starting with leaf nodes and working its way upward.
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>>
>>>>> BURM? What does that stand for anyway? It might as well have
>>>>> been Burmese.
>>>>> It will take a while to understand :-)
>>>>>
>>>>>
>>>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>
>>>>>>> I don't know SWF format and JBurg
>>>>>> The SWF and ABC formats are irrelevant if you want to generate
>>>>>> JS code, so
>>>>>> you
>>>>>> wouldn't need to learn them.
>>>>>>
>>>>>> If you don't want to learn about the BURM I suppose you could
>>>>>> try generating
>>>>>> JS code directly from the AST. I don't know enough about
>>>>>> FalconJS to know
>>>>>> whether the BURM approach produces more efficient code.
>>>>>> Understanding the
>>>>>> BURM
>>>>>> is not terribly hard, though. There are three main ideas:
>>>>>>
>>>>>> 1. A BURM pattern like
>>>>>>
>>>>>> Pattern labeledBreakStmt
>>>>>> BreakID(IdentifierID(void));
>>>>>>
>>>>>> describes a subtree within the AST; in this case, it is describing the
>>>>>> subtree
>>>>>>
>>>>>> BreakNode
>>>>>> IdentifierNode
>>>>>>
>>>>>> that represents code like "break foo";
>>>>>>
>>>>>> 2. A BURM rule like
>>>>>>
>>>>>> statement = Pattern labeledBreakStmt: 0
>>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>>>
>>>>>> tells the BURM what to do when it finds such a subtree: namely, call the
>>>>>> Java
>>>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a
>>>>>> slew
>>>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>>>
>>>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>>>> represents
>>>>>> the subtree that got reduced. Often this is an InstructionList
>>>>>> but it can be
>>>>>> anything. This Java object can then be used in other patterns
>>>>>> to describe
>>>>>> more
>>>>>> general or recursive patterns, as in
>>>>>>
>>>>>> Pattern blockStmt
>>>>>> BlockID(statement stmts*);
>>>>>>
>>>>>> For example, this says that a block statement is a BlockNode
>>>>>> with multiple
>>>>>> child nodes which have been reduced to a 'statement'.
>>>>>>
>>>>>> The BURM patterns and rules should be mostly the same whether you are
>>>>>> generating ABC or JS, because they depend on the AS node
>>>>>> patterns that are
>>>>>> being noticed and reduced. So I really think you'd be doing most of your
>>>>>> work
>>>>>> inside the JSGeneratingReducer. I believe this was Bernd's
>>>>>> approach when he
>>>>>> developed FalconJS. You just make the reduce_XXX() method
>>>>>> produce JS strings
>>>>>> rather than ABC InstructionLists.
>>>>>>
>>>>>> - Gordon
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>>>> To: flex-dev@incubator.apache.org
>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>
>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>
>>>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>>>> planning to work on MXML->JS but Alex and I think
>>>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>>>> what we say. :)
>>>>>>>
>>>>>>> - Gordon
>>>>>> The conversation was about exploring a straight AST to JS convertor
>>>>>> and bypassing the JS emitting using SWF reducer.
>>>>>>
>>>>>> My point was in the discussion that I don't know SWF format and JBurg
>>>>>> so trying to maintain FalconJS in it's current state would be hard for
>>>>>> a lot of developers.
>>>>>>
>>>>>> A lot of cross compilers just work with the straight AST in our case
>>>>>> the IASNode or IDefinition frameworks.
>>>>>>
>>>>>> I also thought having this ability would allow other targets to be
>>>>>> implemented more quickly IE Java android or something...
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>>
>>>>>>> Well considering the conversation between you two, I will ditch
>>>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>>>> living on a mountain...
>>>>>>>
>>>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>>>> keep up with your conversations.
>>>>>>>
>>>>>>> For now, I will focus on testing the compiler and trying to get in a
>>>>>>> groove somehow dealing with that. I'm going to try and document more
>>>>>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>>>>>> wrong in places.
>>>>>>>
>>>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>>>> can get my brain wrapped around that to help with some simple test
>>>>>>> components.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>>
>>>>>>>> That sounds fine. We'll work in parallel:
>>>>>>>>
>>>>>>>> Me: MXML->ABC
>>>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>>>>>
>>>>>>>> - Gordon
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>>>
>>>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>>>> MXML->interpretation
>>>>>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>>>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>>>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>>>>>> so I will probably do the AS version first, but I will be keeping all
>>>>>>>> of the old ABC code paths around. Right now there is some global flag
>>>>>>>> that determines which code paths to go down. I might tie that to some
>>>>>>>> new property in flex-config.xml or something like that.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Alex Harui
>>>>>>>> Flex SDK Team
>>>>>>>> Adobe Systems, Inc.
>>>>>>>> http://blogs.adobe.com/aharui
>>>>>>> --
>>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>>> http://www.teotigraphix.com
>>>>>>> http://blog.teotigraphix.com
>>>>> --
>>>>> Alex Harui
>>>>> Flex SDK Team
>>>>> Adobe Systems, Inc.
>>>>> http://blogs.adobe.com/aharui
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Daniel Wasilewski <de...@gmail.com>.
huh?
In computer science both conventions are adopted afik. Not reserved,
that someone can say, there is only 1 correct.
Polish notation or reversed polish notation is correct in computer science?
On 12/2/2012 8:07 PM, Gordon Smith wrote:
> The bottom-upness of the BURM means that subtrees that are nearer to the leaves of the AST get reduced before subtrees that nearer to the root. Trees in computer science grow from the top down.
>
> Sent from my iPad
>
> On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>> Interesting. Someday I will figure out what is bottom up about it.
>>
>> Anyway, thanks, and bottoms up!
>>
>> -Alex
>>
>>
>> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>
>>> The BURM is the Bottom-Up Rewrite Machine that the BURG or Bottom-Up Rewrite
>>> Generator generates. A BURM reduces subtrees within an AST to an output format
>>> such as ABC or JS, starting with leaf nodes and working its way upward.
>>>
>>> Sent from my iPad
>>>
>>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>> BURM? What does that stand for anyway? It might as well have been Burmese.
>>>> It will take a while to understand :-)
>>>>
>>>>
>>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>
>>>>>> I don't know SWF format and JBurg
>>>>> The SWF and ABC formats are irrelevant if you want to generate JS code, so
>>>>> you
>>>>> wouldn't need to learn them.
>>>>>
>>>>> If you don't want to learn about the BURM I suppose you could try generating
>>>>> JS code directly from the AST. I don't know enough about FalconJS to know
>>>>> whether the BURM approach produces more efficient code. Understanding the
>>>>> BURM
>>>>> is not terribly hard, though. There are three main ideas:
>>>>>
>>>>> 1. A BURM pattern like
>>>>>
>>>>> Pattern labeledBreakStmt
>>>>> BreakID(IdentifierID(void));
>>>>>
>>>>> describes a subtree within the AST; in this case, it is describing the
>>>>> subtree
>>>>>
>>>>> BreakNode
>>>>> IdentifierNode
>>>>>
>>>>> that represents code like "break foo";
>>>>>
>>>>> 2. A BURM rule like
>>>>>
>>>>> statement = Pattern labeledBreakStmt: 0
>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>>
>>>>> tells the BURM what to do when it finds such a subtree: namely, call the
>>>>> Java
>>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a
>>>>> slew
>>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>>
>>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>>> represents
>>>>> the subtree that got reduced. Often this is an InstructionList but it can be
>>>>> anything. This Java object can then be used in other patterns to describe
>>>>> more
>>>>> general or recursive patterns, as in
>>>>>
>>>>> Pattern blockStmt
>>>>> BlockID(statement stmts*);
>>>>>
>>>>> For example, this says that a block statement is a BlockNode with multiple
>>>>> child nodes which have been reduced to a 'statement'.
>>>>>
>>>>> The BURM patterns and rules should be mostly the same whether you are
>>>>> generating ABC or JS, because they depend on the AS node patterns that are
>>>>> being noticed and reduced. So I really think you'd be doing most of your
>>>>> work
>>>>> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
>>>>> developed FalconJS. You just make the reduce_XXX() method produce JS strings
>>>>> rather than ABC InstructionLists.
>>>>>
>>>>> - Gordon
>>>>>
>>>>> -----Original Message-----
>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>
>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>
>>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>>> planning to work on MXML->JS but Alex and I think
>>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>>> what we say. :)
>>>>>>
>>>>>> - Gordon
>>>>> The conversation was about exploring a straight AST to JS convertor
>>>>> and bypassing the JS emitting using SWF reducer.
>>>>>
>>>>> My point was in the discussion that I don't know SWF format and JBurg
>>>>> so trying to maintain FalconJS in it's current state would be hard for
>>>>> a lot of developers.
>>>>>
>>>>> A lot of cross compilers just work with the straight AST in our case
>>>>> the IASNode or IDefinition frameworks.
>>>>>
>>>>> I also thought having this ability would allow other targets to be
>>>>> implemented more quickly IE Java android or something...
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>>> To: flex-dev@incubator.apache.org
>>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>>
>>>>>> Well considering the conversation between you two, I will ditch
>>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>>> living on a mountain...
>>>>>>
>>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>>> keep up with your conversations.
>>>>>>
>>>>>> For now, I will focus on testing the compiler and trying to get in a
>>>>>> groove somehow dealing with that. I'm going to try and document more
>>>>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>>>>> wrong in places.
>>>>>>
>>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>>> can get my brain wrapped around that to help with some simple test
>>>>>> components.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>>
>>>>>>> That sounds fine. We'll work in parallel:
>>>>>>>
>>>>>>> Me: MXML->ABC
>>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>>>>
>>>>>>> - Gordon
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>>> To: flex-dev@incubator.apache.org
>>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>>
>>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>>> MXML->interpretation
>>>>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>>>>> so I will probably do the AS version first, but I will be keeping all
>>>>>>> of the old ABC code paths around. Right now there is some global flag
>>>>>>> that determines which code paths to go down. I might tie that to some
>>>>>>> new property in flex-config.xml or something like that.
>>>>>>>
>>>>>>> --
>>>>>>> Alex Harui
>>>>>>> Flex SDK Team
>>>>>>> Adobe Systems, Inc.
>>>>>>> http://blogs.adobe.com/aharui
>>>>>> --
>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>> http://www.teotigraphix.com
>>>>>> http://blog.teotigraphix.com
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
The bottom-upness of the BURM means that subtrees that are nearer to the leaves of the AST get reduced before subtrees that nearer to the root. Trees in computer science grow from the top down.
Sent from my iPad
On Nov 30, 2012, at 10:24 PM, "Alex Harui" <ah...@adobe.com> wrote:
> Interesting. Someday I will figure out what is bottom up about it.
>
> Anyway, thanks, and bottoms up!
>
> -Alex
>
>
> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>
>> The BURM is the Bottom-Up Rewrite Machine that the BURG or Bottom-Up Rewrite
>> Generator generates. A BURM reduces subtrees within an AST to an output format
>> such as ABC or JS, starting with leaf nodes and working its way upward.
>>
>> Sent from my iPad
>>
>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>> BURM? What does that stand for anyway? It might as well have been Burmese.
>>> It will take a while to understand :-)
>>>
>>>
>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>
>>>>> I don't know SWF format and JBurg
>>>>
>>>> The SWF and ABC formats are irrelevant if you want to generate JS code, so
>>>> you
>>>> wouldn't need to learn them.
>>>>
>>>> If you don't want to learn about the BURM I suppose you could try generating
>>>> JS code directly from the AST. I don't know enough about FalconJS to know
>>>> whether the BURM approach produces more efficient code. Understanding the
>>>> BURM
>>>> is not terribly hard, though. There are three main ideas:
>>>>
>>>> 1. A BURM pattern like
>>>>
>>>> Pattern labeledBreakStmt
>>>> BreakID(IdentifierID(void));
>>>>
>>>> describes a subtree within the AST; in this case, it is describing the
>>>> subtree
>>>>
>>>> BreakNode
>>>> IdentifierNode
>>>>
>>>> that represents code like "break foo";
>>>>
>>>> 2. A BURM rule like
>>>>
>>>> statement = Pattern labeledBreakStmt: 0
>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>
>>>> tells the BURM what to do when it finds such a subtree: namely, call the
>>>> Java
>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a
>>>> slew
>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>
>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>> represents
>>>> the subtree that got reduced. Often this is an InstructionList but it can be
>>>> anything. This Java object can then be used in other patterns to describe
>>>> more
>>>> general or recursive patterns, as in
>>>>
>>>> Pattern blockStmt
>>>> BlockID(statement stmts*);
>>>>
>>>> For example, this says that a block statement is a BlockNode with multiple
>>>> child nodes which have been reduced to a 'statement'.
>>>>
>>>> The BURM patterns and rules should be mostly the same whether you are
>>>> generating ABC or JS, because they depend on the AS node patterns that are
>>>> being noticed and reduced. So I really think you'd be doing most of your
>>>> work
>>>> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
>>>> developed FalconJS. You just make the reduce_XXX() method produce JS strings
>>>> rather than ABC InstructionLists.
>>>>
>>>> - Gordon
>>>>
>>>> -----Original Message-----
>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>> To: flex-dev@incubator.apache.org
>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>
>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>
>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>> planning to work on MXML->JS but Alex and I think
>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>> what we say. :)
>>>>>
>>>>> - Gordon
>>>>
>>>> The conversation was about exploring a straight AST to JS convertor
>>>> and bypassing the JS emitting using SWF reducer.
>>>>
>>>> My point was in the discussion that I don't know SWF format and JBurg
>>>> so trying to maintain FalconJS in it's current state would be hard for
>>>> a lot of developers.
>>>>
>>>> A lot of cross compilers just work with the straight AST in our case
>>>> the IASNode or IDefinition frameworks.
>>>>
>>>> I also thought having this ability would allow other targets to be
>>>> implemented more quickly IE Java android or something...
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>
>>>>> Well considering the conversation between you two, I will ditch
>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>> living on a mountain...
>>>>>
>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>> keep up with your conversations.
>>>>>
>>>>> For now, I will focus on testing the compiler and trying to get in a
>>>>> groove somehow dealing with that. I'm going to try and document more
>>>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>>>> wrong in places.
>>>>>
>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>> can get my brain wrapped around that to help with some simple test
>>>>> components.
>>>>>
>>>>> Mike
>>>>>
>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>
>>>>>> That sounds fine. We'll work in parallel:
>>>>>>
>>>>>> Me: MXML->ABC
>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>>>
>>>>>> - Gordon
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>> To: flex-dev@incubator.apache.org
>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>
>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>> MXML->interpretation
>>>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>>>> so I will probably do the AS version first, but I will be keeping all
>>>>>> of the old ABC code paths around. Right now there is some global flag
>>>>>> that determines which code paths to go down. I might tie that to some
>>>>>> new property in flex-config.xml or something like that.
>>>>>>
>>>>>> --
>>>>>> Alex Harui
>>>>>> Flex SDK Team
>>>>>> Adobe Systems, Inc.
>>>>>> http://blogs.adobe.com/aharui
>>>>>
>>>>> --
>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>> http://www.teotigraphix.com
>>>>> http://blog.teotigraphix.com
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Daniel Wasilewski <de...@gmail.com>.
LoL :)
On 12/1/2012 6:23 AM, Alex Harui wrote:
> Interesting. Someday I will figure out what is bottom up about it.
>
> Anyway, thanks, and bottoms up!
>
> -Alex
>
>
> On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
>
>> The BURM is the Bottom-Up Rewrite Machine that the BURG or Bottom-Up Rewrite
>> Generator generates. A BURM reduces subtrees within an AST to an output format
>> such as ABC or JS, starting with leaf nodes and working its way upward.
>>
>> Sent from my iPad
>>
>> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>> BURM? What does that stand for anyway? It might as well have been Burmese.
>>> It will take a while to understand :-)
>>>
>>>
>>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>
>>>>> I don't know SWF format and JBurg
>>>> The SWF and ABC formats are irrelevant if you want to generate JS code, so
>>>> you
>>>> wouldn't need to learn them.
>>>>
>>>> If you don't want to learn about the BURM I suppose you could try generating
>>>> JS code directly from the AST. I don't know enough about FalconJS to know
>>>> whether the BURM approach produces more efficient code. Understanding the
>>>> BURM
>>>> is not terribly hard, though. There are three main ideas:
>>>>
>>>> 1. A BURM pattern like
>>>>
>>>> Pattern labeledBreakStmt
>>>> BreakID(IdentifierID(void));
>>>>
>>>> describes a subtree within the AST; in this case, it is describing the
>>>> subtree
>>>>
>>>> BreakNode
>>>> IdentifierNode
>>>>
>>>> that represents code like "break foo";
>>>>
>>>> 2. A BURM rule like
>>>>
>>>> statement = Pattern labeledBreakStmt: 0
>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>
>>>> tells the BURM what to do when it finds such a subtree: namely, call the
>>>> Java
>>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a
>>>> slew
>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>
>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>> represents
>>>> the subtree that got reduced. Often this is an InstructionList but it can be
>>>> anything. This Java object can then be used in other patterns to describe
>>>> more
>>>> general or recursive patterns, as in
>>>>
>>>> Pattern blockStmt
>>>> BlockID(statement stmts*);
>>>>
>>>> For example, this says that a block statement is a BlockNode with multiple
>>>> child nodes which have been reduced to a 'statement'.
>>>>
>>>> The BURM patterns and rules should be mostly the same whether you are
>>>> generating ABC or JS, because they depend on the AS node patterns that are
>>>> being noticed and reduced. So I really think you'd be doing most of your
>>>> work
>>>> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
>>>> developed FalconJS. You just make the reduce_XXX() method produce JS strings
>>>> rather than ABC InstructionLists.
>>>>
>>>> - Gordon
>>>>
>>>> -----Original Message-----
>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>> Sent: Friday, November 30, 2012 4:11 PM
>>>> To: flex-dev@incubator.apache.org
>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>
>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>
>>>>> I didn't follow the whole discussion. Is the issue that you were
>>>>> planning to work on MXML->JS but Alex and I think
>>>>> MXML->datastructure is a better approach? You don't have to accept
>>>>> what we say. :)
>>>>>
>>>>> - Gordon
>>>> The conversation was about exploring a straight AST to JS convertor
>>>> and bypassing the JS emitting using SWF reducer.
>>>>
>>>> My point was in the discussion that I don't know SWF format and JBurg
>>>> so trying to maintain FalconJS in it's current state would be hard for
>>>> a lot of developers.
>>>>
>>>> A lot of cross compilers just work with the straight AST in our case
>>>> the IASNode or IDefinition frameworks.
>>>>
>>>> I also thought having this ability would allow other targets to be
>>>> implemented more quickly IE Java android or something...
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>>
>>>>> Well considering the conversation between you two, I will ditch
>>>>> pretty much all I said in the last 3 days. This is what I get for
>>>>> living on a mountain...
>>>>>
>>>>> I have interest in the non-flash player stuff, so I guess I will
>>>>> keep up with your conversations.
>>>>>
>>>>> For now, I will focus on testing the compiler and trying to get in a
>>>>> groove somehow dealing with that. I'm going to try and document more
>>>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>>>> wrong in places.
>>>>>
>>>>> And, I will try to really understand Alex's prototype and see if I
>>>>> can get my brain wrapped around that to help with some simple test
>>>>> components.
>>>>>
>>>>> Mike
>>>>>
>>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>>
>>>>>> That sounds fine. We'll work in parallel:
>>>>>>
>>>>>> Me: MXML->ABC
>>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>>>
>>>>>> - Gordon
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>>> To: flex-dev@incubator.apache.org
>>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>>
>>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>>> MXML->interpretation
>>>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>>>> so I will probably do the AS version first, but I will be keeping all
>>>>>> of the old ABC code paths around. Right now there is some global flag
>>>>>> that determines which code paths to go down. I might tie that to some
>>>>>> new property in flex-config.xml or something like that.
>>>>>>
>>>>>> --
>>>>>> Alex Harui
>>>>>> Flex SDK Team
>>>>>> Adobe Systems, Inc.
>>>>>> http://blogs.adobe.com/aharui
>>>>>>
>>>>>>
>>>>> --
>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>> http://www.teotigraphix.com
>>>>> http://blog.teotigraphix.com
>>>>>
>>>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
Interesting. Someday I will figure out what is bottom up about it.
Anyway, thanks, and bottoms up!
-Alex
On 11/30/12 9:48 PM, "Gordon Smith" <go...@adobe.com> wrote:
> The BURM is the Bottom-Up Rewrite Machine that the BURG or Bottom-Up Rewrite
> Generator generates. A BURM reduces subtrees within an AST to an output format
> such as ABC or JS, starting with leaf nodes and working its way upward.
>
> Sent from my iPad
>
> On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>> BURM? What does that stand for anyway? It might as well have been Burmese.
>> It will take a while to understand :-)
>>
>>
>> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>
>>>> I don't know SWF format and JBurg
>>>
>>> The SWF and ABC formats are irrelevant if you want to generate JS code, so
>>> you
>>> wouldn't need to learn them.
>>>
>>> If you don't want to learn about the BURM I suppose you could try generating
>>> JS code directly from the AST. I don't know enough about FalconJS to know
>>> whether the BURM approach produces more efficient code. Understanding the
>>> BURM
>>> is not terribly hard, though. There are three main ideas:
>>>
>>> 1. A BURM pattern like
>>>
>>> Pattern labeledBreakStmt
>>> BreakID(IdentifierID(void));
>>>
>>> describes a subtree within the AST; in this case, it is describing the
>>> subtree
>>>
>>> BreakNode
>>> IdentifierNode
>>>
>>> that represents code like "break foo";
>>>
>>> 2. A BURM rule like
>>>
>>> statement = Pattern labeledBreakStmt: 0
>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>
>>> tells the BURM what to do when it finds such a subtree: namely, call the
>>> Java
>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a
>>> slew
>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>
>>> 3. The result of a "reduction" can be any Java object which somehow
>>> represents
>>> the subtree that got reduced. Often this is an InstructionList but it can be
>>> anything. This Java object can then be used in other patterns to describe
>>> more
>>> general or recursive patterns, as in
>>>
>>> Pattern blockStmt
>>> BlockID(statement stmts*);
>>>
>>> For example, this says that a block statement is a BlockNode with multiple
>>> child nodes which have been reduced to a 'statement'.
>>>
>>> The BURM patterns and rules should be mostly the same whether you are
>>> generating ABC or JS, because they depend on the AS node patterns that are
>>> being noticed and reduced. So I really think you'd be doing most of your
>>> work
>>> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
>>> developed FalconJS. You just make the reduce_XXX() method produce JS strings
>>> rather than ABC InstructionLists.
>>>
>>> - Gordon
>>>
>>> -----Original Message-----
>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>> Sent: Friday, November 30, 2012 4:11 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>
>>> Quoting Gordon Smith <go...@adobe.com>:
>>>
>>>> I didn't follow the whole discussion. Is the issue that you were
>>>> planning to work on MXML->JS but Alex and I think
>>>> MXML->datastructure is a better approach? You don't have to accept
>>>> what we say. :)
>>>>
>>>> - Gordon
>>>
>>> The conversation was about exploring a straight AST to JS convertor
>>> and bypassing the JS emitting using SWF reducer.
>>>
>>> My point was in the discussion that I don't know SWF format and JBurg
>>> so trying to maintain FalconJS in it's current state would be hard for
>>> a lot of developers.
>>>
>>> A lot of cross compilers just work with the straight AST in our case
>>> the IASNode or IDefinition frameworks.
>>>
>>> I also thought having this ability would allow other targets to be
>>> implemented more quickly IE Java android or something...
>>>
>>> What do you think?
>>>
>>>
>>>> -----Original Message-----
>>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>>> Sent: Friday, November 30, 2012 3:55 PM
>>>> To: flex-dev@incubator.apache.org
>>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>>
>>>> Well considering the conversation between you two, I will ditch
>>>> pretty much all I said in the last 3 days. This is what I get for
>>>> living on a mountain...
>>>>
>>>> I have interest in the non-flash player stuff, so I guess I will
>>>> keep up with your conversations.
>>>>
>>>> For now, I will focus on testing the compiler and trying to get in a
>>>> groove somehow dealing with that. I'm going to try and document more
>>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>>> wrong in places.
>>>>
>>>> And, I will try to really understand Alex's prototype and see if I
>>>> can get my brain wrapped around that to help with some simple test
>>>> components.
>>>>
>>>> Mike
>>>>
>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>
>>>>> That sounds fine. We'll work in parallel:
>>>>>
>>>>> Me: MXML->ABC
>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>>
>>>>> - Gordon
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>>
>>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>>> MXML->interpretation
>>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>>> so I will probably do the AS version first, but I will be keeping all
>>>>> of the old ABC code paths around. Right now there is some global flag
>>>>> that determines which code paths to go down. I might tie that to some
>>>>> new property in flex-config.xml or something like that.
>>>>>
>>>>> --
>>>>> Alex Harui
>>>>> Flex SDK Team
>>>>> Adobe Systems, Inc.
>>>>> http://blogs.adobe.com/aharui
>>>>>
>>>>>
>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
The BURM is the Bottom-Up Rewrite Machine that the BURG or Bottom-Up Rewrite Generator generates. A BURM reduces subtrees within an AST to an output format such as ABC or JS, starting with leaf nodes and working its way upward.
Sent from my iPad
On Nov 30, 2012, at 8:45 PM, "Alex Harui" <ah...@adobe.com> wrote:
> BURM? What does that stand for anyway? It might as well have been Burmese.
> It will take a while to understand :-)
>
>
> On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>
>>> I don't know SWF format and JBurg
>>
>> The SWF and ABC formats are irrelevant if you want to generate JS code, so you
>> wouldn't need to learn them.
>>
>> If you don't want to learn about the BURM I suppose you could try generating
>> JS code directly from the AST. I don't know enough about FalconJS to know
>> whether the BURM approach produces more efficient code. Understanding the BURM
>> is not terribly hard, though. There are three main ideas:
>>
>> 1. A BURM pattern like
>>
>> Pattern labeledBreakStmt
>> BreakID(IdentifierID(void));
>>
>> describes a subtree within the AST; in this case, it is describing the subtree
>>
>> BreakNode
>> IdentifierNode
>>
>> that represents code like "break foo";
>>
>> 2. A BURM rule like
>>
>> statement = Pattern labeledBreakStmt: 0
>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>
>> tells the BURM what to do when it finds such a subtree: namely, call the Java
>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a slew
>> of "reduce_XXX()" methods for reducing various subtrees.
>>
>> 3. The result of a "reduction" can be any Java object which somehow represents
>> the subtree that got reduced. Often this is an InstructionList but it can be
>> anything. This Java object can then be used in other patterns to describe more
>> general or recursive patterns, as in
>>
>> Pattern blockStmt
>> BlockID(statement stmts*);
>>
>> For example, this says that a block statement is a BlockNode with multiple
>> child nodes which have been reduced to a 'statement'.
>>
>> The BURM patterns and rules should be mostly the same whether you are
>> generating ABC or JS, because they depend on the AS node patterns that are
>> being noticed and reduced. So I really think you'd be doing most of your work
>> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
>> developed FalconJS. You just make the reduce_XXX() method produce JS strings
>> rather than ABC InstructionLists.
>>
>> - Gordon
>>
>> -----Original Message-----
>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>> Sent: Friday, November 30, 2012 4:11 PM
>> To: flex-dev@incubator.apache.org
>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>
>> Quoting Gordon Smith <go...@adobe.com>:
>>
>>> I didn't follow the whole discussion. Is the issue that you were
>>> planning to work on MXML->JS but Alex and I think
>>> MXML->datastructure is a better approach? You don't have to accept
>>> what we say. :)
>>>
>>> - Gordon
>>
>> The conversation was about exploring a straight AST to JS convertor
>> and bypassing the JS emitting using SWF reducer.
>>
>> My point was in the discussion that I don't know SWF format and JBurg
>> so trying to maintain FalconJS in it's current state would be hard for
>> a lot of developers.
>>
>> A lot of cross compilers just work with the straight AST in our case
>> the IASNode or IDefinition frameworks.
>>
>> I also thought having this ability would allow other targets to be
>> implemented more quickly IE Java android or something...
>>
>> What do you think?
>>
>>
>>> -----Original Message-----
>>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>>> Sent: Friday, November 30, 2012 3:55 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>>
>>> Well considering the conversation between you two, I will ditch
>>> pretty much all I said in the last 3 days. This is what I get for
>>> living on a mountain...
>>>
>>> I have interest in the non-flash player stuff, so I guess I will
>>> keep up with your conversations.
>>>
>>> For now, I will focus on testing the compiler and trying to get in a
>>> groove somehow dealing with that. I'm going to try and document more
>>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>>> wrong in places.
>>>
>>> And, I will try to really understand Alex's prototype and see if I
>>> can get my brain wrapped around that to help with some simple test
>>> components.
>>>
>>> Mike
>>>
>>> Quoting Gordon Smith <go...@adobe.com>:
>>>
>>>> That sounds fine. We'll work in parallel:
>>>>
>>>> Me: MXML->ABC
>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>>
>>>> - Gordon
>>>>
>>>> -----Original Message-----
>>>> From: Alex Harui [mailto:aharui@adobe.com]
>>>> Sent: Friday, November 30, 2012 3:29 PM
>>>> To: flex-dev@incubator.apache.org
>>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>>
>>>>
>>>>
>>>>
>>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>>
>>>>> MXML->JS doesn't exist and is not the way to go.
>>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>>> MXML->interpretation
>>>>> by JS and later for interpretation by an ABC library written in AS.
>>>> I'm pretty sure I had this all working last year in AS. I just have
>>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>>> so I will probably do the AS version first, but I will be keeping all
>>>> of the old ABC code paths around. Right now there is some global flag
>>>> that determines which code paths to go down. I might tie that to some
>>>> new property in flex-config.xml or something like that.
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
BURM? What does that stand for anyway? It might as well have been Burmese.
It will take a while to understand :-)
On 11/30/12 5:36 PM, "Gordon Smith" <go...@adobe.com> wrote:
>> I don't know SWF format and JBurg
>
> The SWF and ABC formats are irrelevant if you want to generate JS code, so you
> wouldn't need to learn them.
>
> If you don't want to learn about the BURM I suppose you could try generating
> JS code directly from the AST. I don't know enough about FalconJS to know
> whether the BURM approach produces more efficient code. Understanding the BURM
> is not terribly hard, though. There are three main ideas:
>
> 1. A BURM pattern like
>
> Pattern labeledBreakStmt
> BreakID(IdentifierID(void));
>
> describes a subtree within the AST; in this case, it is describing the subtree
>
> BreakNode
> IdentifierNode
>
> that represents code like "break foo";
>
> 2. A BURM rule like
>
> statement = Pattern labeledBreakStmt: 0
> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>
> tells the BURM what to do when it finds such a subtree: namely, call the Java
> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a slew
> of "reduce_XXX()" methods for reducing various subtrees.
>
> 3. The result of a "reduction" can be any Java object which somehow represents
> the subtree that got reduced. Often this is an InstructionList but it can be
> anything. This Java object can then be used in other patterns to describe more
> general or recursive patterns, as in
>
> Pattern blockStmt
> BlockID(statement stmts*);
>
> For example, this says that a block statement is a BlockNode with multiple
> child nodes which have been reduced to a 'statement'.
>
> The BURM patterns and rules should be mostly the same whether you are
> generating ABC or JS, because they depend on the AS node patterns that are
> being noticed and reduced. So I really think you'd be doing most of your work
> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
> developed FalconJS. You just make the reduce_XXX() method produce JS strings
> rather than ABC InstructionLists.
>
> - Gordon
>
> -----Original Message-----
> From: Michael Schmalle [mailto:apache@teotigraphix.com]
> Sent: Friday, November 30, 2012 4:11 PM
> To: flex-dev@incubator.apache.org
> Subject: RE: [FlaconJS] pseudo emitter algorithm
>
> Quoting Gordon Smith <go...@adobe.com>:
>
>> I didn't follow the whole discussion. Is the issue that you were
>> planning to work on MXML->JS but Alex and I think
>> MXML->datastructure is a better approach? You don't have to accept
>> what we say. :)
>>
>> - Gordon
>
> The conversation was about exploring a straight AST to JS convertor
> and bypassing the JS emitting using SWF reducer.
>
> My point was in the discussion that I don't know SWF format and JBurg
> so trying to maintain FalconJS in it's current state would be hard for
> a lot of developers.
>
> A lot of cross compilers just work with the straight AST in our case
> the IASNode or IDefinition frameworks.
>
> I also thought having this ability would allow other targets to be
> implemented more quickly IE Java android or something...
>
> What do you think?
>
>
>> -----Original Message-----
>> From: Michael Schmalle [mailto:apache@teotigraphix.com]
>> Sent: Friday, November 30, 2012 3:55 PM
>> To: flex-dev@incubator.apache.org
>> Subject: RE: [FlaconJS] pseudo emitter algorithm
>>
>> Well considering the conversation between you two, I will ditch
>> pretty much all I said in the last 3 days. This is what I get for
>> living on a mountain...
>>
>> I have interest in the non-flash player stuff, so I guess I will
>> keep up with your conversations.
>>
>> For now, I will focus on testing the compiler and trying to get in a
>> groove somehow dealing with that. I'm going to try and document more
>> of the compiler on the wiki. Gordon feel free the correct me if I'm
>> wrong in places.
>>
>> And, I will try to really understand Alex's prototype and see if I
>> can get my brain wrapped around that to help with some simple test
>> components.
>>
>> Mike
>>
>> Quoting Gordon Smith <go...@adobe.com>:
>>
>>> That sounds fine. We'll work in parallel:
>>>
>>> Me: MXML->ABC
>>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>>
>>> - Gordon
>>>
>>> -----Original Message-----
>>> From: Alex Harui [mailto:aharui@adobe.com]
>>> Sent: Friday, November 30, 2012 3:29 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>>
>>>
>>>
>>>
>>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>>
>>>> MXML->JS doesn't exist and is not the way to go.
>>>> MXML->datastructure is a good idea. Alex will do it first for
>>>> MXML->interpretation
>>>> by JS and later for interpretation by an ABC library written in AS.
>>> I'm pretty sure I had this all working last year in AS. I just have
>>> to dust it off. Right now it is easier/faster for me to debug in AS,
>>> so I will probably do the AS version first, but I will be keeping all
>>> of the old ABC code paths around. Right now there is some global flag
>>> that determines which code paths to go down. I might tie that to some
>>> new property in flex-config.xml or something like that.
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
> I don't know SWF format and JBurg
The SWF and ABC formats are irrelevant if you want to generate JS code, so you wouldn't need to learn them.
If you don't want to learn about the BURM I suppose you could try generating JS code directly from the AST. I don't know enough about FalconJS to know whether the BURM approach produces more efficient code. Understanding the BURM is not terribly hard, though. There are three main ideas:
1. A BURM pattern like
Pattern labeledBreakStmt
BreakID(IdentifierID(void));
describes a subtree within the AST; in this case, it is describing the subtree
BreakNode
IdentifierNode
that represents code like "break foo";
2. A BURM rule like
statement = Pattern labeledBreakStmt: 0
JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
tells the BURM what to do when it finds such a subtree: namely, call the Java method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has a slew of "reduce_XXX()" methods for reducing various subtrees.
3. The result of a "reduction" can be any Java object which somehow represents the subtree that got reduced. Often this is an InstructionList but it can be anything. This Java object can then be used in other patterns to describe more general or recursive patterns, as in
Pattern blockStmt
BlockID(statement stmts*);
For example, this says that a block statement is a BlockNode with multiple child nodes which have been reduced to a 'statement'.
The BURM patterns and rules should be mostly the same whether you are generating ABC or JS, because they depend on the AS node patterns that are being noticed and reduced. So I really think you'd be doing most of your work inside the JSGeneratingReducer. I believe this was Bernd's approach when he developed FalconJS. You just make the reduce_XXX() method produce JS strings rather than ABC InstructionLists.
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apache@teotigraphix.com]
Sent: Friday, November 30, 2012 4:11 PM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Quoting Gordon Smith <go...@adobe.com>:
> I didn't follow the whole discussion. Is the issue that you were
> planning to work on MXML->JS but Alex and I think
> MXML->datastructure is a better approach? You don't have to accept
> what we say. :)
>
> - Gordon
The conversation was about exploring a straight AST to JS convertor
and bypassing the JS emitting using SWF reducer.
My point was in the discussion that I don't know SWF format and JBurg
so trying to maintain FalconJS in it's current state would be hard for
a lot of developers.
A lot of cross compilers just work with the straight AST in our case
the IASNode or IDefinition frameworks.
I also thought having this ability would allow other targets to be
implemented more quickly IE Java android or something...
What do you think?
> -----Original Message-----
> From: Michael Schmalle [mailto:apache@teotigraphix.com]
> Sent: Friday, November 30, 2012 3:55 PM
> To: flex-dev@incubator.apache.org
> Subject: RE: [FlaconJS] pseudo emitter algorithm
>
> Well considering the conversation between you two, I will ditch
> pretty much all I said in the last 3 days. This is what I get for
> living on a mountain...
>
> I have interest in the non-flash player stuff, so I guess I will
> keep up with your conversations.
>
> For now, I will focus on testing the compiler and trying to get in a
> groove somehow dealing with that. I'm going to try and document more
> of the compiler on the wiki. Gordon feel free the correct me if I'm
> wrong in places.
>
> And, I will try to really understand Alex's prototype and see if I
> can get my brain wrapped around that to help with some simple test
> components.
>
> Mike
>
> Quoting Gordon Smith <go...@adobe.com>:
>
>> That sounds fine. We'll work in parallel:
>>
>> Me: MXML->ABC
>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>
>> - Gordon
>>
>> -----Original Message-----
>> From: Alex Harui [mailto:aharui@adobe.com]
>> Sent: Friday, November 30, 2012 3:29 PM
>> To: flex-dev@incubator.apache.org
>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>
>>
>>
>>
>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>
>>> MXML->JS doesn't exist and is not the way to go.
>>> MXML->datastructure is a good idea. Alex will do it first for
>>> MXML->interpretation
>>> by JS and later for interpretation by an ABC library written in AS.
>> I'm pretty sure I had this all working last year in AS. I just have
>> to dust it off. Right now it is easier/faster for me to debug in AS,
>> so I will probably do the AS version first, but I will be keeping all
>> of the old ABC code paths around. Right now there is some global flag
>> that determines which code paths to go down. I might tie that to some
>> new property in flex-config.xml or something like that.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
On 12/3/12 12:44 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>> If you look at the prototype, it does not use nested object literals. I
>> was
>> unable to get them to perform as well as the data stream I am using or the
>> methods it is replacing.
>>
>
> So maybe we could output different code for debugging and for production?
>
I would prefer not to, so we don't have to debug the different instantiation
paths, but no strong objections.
>
>>> The idea would be to generate AS code from MXML that contains both the
>>> datastructures and the code fragments (<fx:Script>), keeping the line
>>> numbers (if possible).
>> It is probably possible to maintain line numbers for script blocks, but
>> what
>> are the advantages of maintaining line numbers in MXML?
>>
>
> For the completely declarative stuff, break points are of course not an
> argument. The only point that remains is that developers might better
> recognize their own code during debugging the more it resembles the
> original source.
> When talking about script blocks, do you mean <fx:Script> only or also
> inline event handler bodies?
> The latter should keep their line number, too.
Well, you could probably handle event handlers as well. In theory, the data
stream can be at any line in the file. It references the wrapped event
handlers.
> Maybe even binding expressions could generate code that you might want to
> debug (break when binding expression is re-assigned to property), but I'm
> not sure whether this is possible at all.
Binding will be interesting. For most bindings, I'm hoping to generate data
structures as well. Some complex bindings are an expression (e.g.
Foo="{width+somerandomfunction()}" and thus could use breakpoints.
Let's deal with this later.
>
> -Frank-
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FlaconJS] pseudo emitter algorithm
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Mon, Dec 3, 2012 at 6:45 AM, Alex Harui <ah...@adobe.com> wrote:
> On 12/2/12 2:21 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> > When you look at Jangaroo-generated JavaScript code, it closely resembles
> > the original ActionScript source code. We optimized the compiler as well
> as
> > the runtime to give the impression that the JS code is actually the AS
> code
> > that you, the developer, wrote. Every source file results in a separate
> JS
> > file, which is also loaded separately in "debug mode".
> I'm ok with that as long as it loads reasonably quickly.
>
As we only use this strategy for debugging, which is usually done with a
local web app with almost no latency, and you can enable debugging on a
per-module basis, loading time is still reasonable. While more requests
have to be made, script downloads can happen in parallel. Jangaroo debug
mode only loads the classes actually needed (= static dependencies of the
main class), so this can even be an advantage over loading the complete
code of a module.
> Even the line
> > numbers are kept precisely. This allows for debugging directly in the
> > browser without the need for any additional / new debugger tools.
> > Of course, this approach would not be possible at all when generating JS
> > code from ABC, not from AS/AST.
> >
> > We would like to provide something similar for MXML, too. So the ideal
> > solution would be a mixture of the approaches described in this thread.
> > Combine Alex' datastructures and the AST->JS approach. This is also very
> > similar to how Ext JS UIs are specified using nested JS Object literals.
> If you look at the prototype, it does not use nested object literals. I
> was
> unable to get them to perform as well as the data stream I am using or the
> methods it is replacing.
>
So maybe we could output different code for debugging and for production?
> > The idea would be to generate AS code from MXML that contains both the
> > datastructures and the code fragments (<fx:Script>), keeping the line
> > numbers (if possible).
> It is probably possible to maintain line numbers for script blocks, but
> what
> are the advantages of maintaining line numbers in MXML?
>
For the completely declarative stuff, break points are of course not an
argument. The only point that remains is that developers might better
recognize their own code during debugging the more it resembles the
original source.
When talking about script blocks, do you mean <fx:Script> only or also
inline event handler bodies? The latter should keep their line number, too.
Maybe even binding expressions could generate code that you might want to
debug (break when binding expression is re-assigned to property), but I'm
not sure whether this is possible at all.
-Frank-
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
On 12/2/12 4:36 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> I keep looking at the current FalconJS code generator and it's way
> over my head. I couldn't contribute to it until I knew how to use a
> couple key low level features such as ABC and JBurg. For now I have no
> reason and time to invest that amount of effort.
>
> Thus, brings us back to 1 week ago when I proposed writing JS from AS
> AST. And now that you brought up, "it may not be the fastest" brings
> me to my next point.
>
> The AST route is LEGIBLE. :) I read your JsCodeGenerator and in 10
> minutes I knew exactly how you implemented it!
>
> So, do you sacrifice legibility for performance right now? Also,
> Gordon brought up ABC may produce faster JavaScript emitted code, but
> he didn't know. I guess we would only know if some wicked smart
> developers created a prototype of an AST emitter, then ran benchmarks
> against the FalconJS javascript? Right? Isn't this what you would do
> in a science lab? :)
There is no reason you can't still create your own code generator straight
off the AST. You don't have to use Jburg. Especially with respect to Java
output. For JS output, I think I'm hearing Gordon say that the Jburg
mapping may be correct and complete and everything we want to change might
be in the Reducer and Emitter.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hi Frank,
Based on the last week of my rambling I know one thing, I don't have
enough knowledge of JavScript to be leading any concrete decisions
regarding the actual implementation.
I read up on the source maps, this does seem like a logical route
browser vendors would take since eventually I see JavScript not
looking like script when broswers eat it due to performance (in the
future). Maybe this is why Bob looks at it like the "webs machine
language" as well.
I keep looking at the current FalconJS code generator and it's way
over my head. I couldn't contribute to it until I knew how to use a
couple key low level features such as ABC and JBurg. For now I have no
reason and time to invest that amount of effort.
Thus, brings us back to 1 week ago when I proposed writing JS from AS
AST. And now that you brought up, "it may not be the fastest" brings
me to my next point.
The AST route is LEGIBLE. :) I read your JsCodeGenerator and in 10
minutes I knew exactly how you implemented it!
So, do you sacrifice legibility for performance right now? Also,
Gordon brought up ABC may produce faster JavaScript emitted code, but
he didn't know. I guess we would only know if some wicked smart
developers created a prototype of an AST emitter, then ran benchmarks
against the FalconJS javascript? Right? Isn't this what you would do
in a science lab? :)
> This should be possible using ABC with debug
> information, shouldn't it?
I'm not exactly sure how precise the source information in an ABC SWF
is but, obviously it saves some information because the debugger has
to know where errors occur and stacktraces when debugging an SWF in
the player.
During the SWF building phase, the builders have access to all the
code positions from the ISourceLocation API.
As far as MXML I'll let others comment since I am not involved in the
part of the compiler and it's still getting completed but what you
said makes perfect seems to me, getting it to AS would allow debugging.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
> Sorry for joining this discussion so late. Like before, I just would like
> to contribute how we approached the problem at Jangaroo.
> Some time ago, we created our own declarative, XML-based language, targeted
> at creating Ext JS UIs, thus called EXML. EXML is very similar to MXML. The
> main difference is that, to have IDE support and validation, EXML is
> XML-Schema-based. For every module containing EXML files, an XSD is
> generated, describing all available classes and their properties. EXML is
> translated to ActionScript, which is then compiled to JavaScript, so we use
> two chained compilers for EXML->AS and AS->JS.
>
> After discovering that MXML is acutally not as tied to Flex components as I
> used to think (I stumbled across this blog
> post<http://dgrigg.com/blog/2010/04/12/when-flex-goes-on-a-slimfast-diet/>),
> I experimented with using MXML to define Ext JS UIs. I already have a
> prototype of MXML support for Jangaroo on a github
> branch<https://github.com/CoreMedia/jangaroo-tools/tree/mxml>which
> uses a different approach.
> Things became quite complicated with EXML when we wanted to make EXML->AS
> generation more intelligent. The EXML->AS compiler needed to inspect
> ActionScript classes, but these again could be referring to ActionScript
> classes generated from EXML. So we have a circular dependency here, which
> was complex to deal with.
> Thus, for my MXML prototype, I chose a different approach, namely to
> integrate MXML->JS compilation directly into the Jangaroo compiler, so that
> when the compilation process needs class acme.Foo, it looks for both
> acme/Foo.as and acme/Foo.mxml. If an MXML file is found, internally, the
> compiler still generates ActionScript code, parses it into an AST, and then
> hands it on to its standard JS code generator. While this may not be the
> most efficient solution, it provides best reuse of software components and
> works great!
>
> There is one important aspect to consider when deciding which route to take.
> If you, like Bernd Paradies, see JavaScript's role in this process as an
> machine language, it is completely valid to generate JS code from ABC.
> But this is not the viewpoint we take for Jangaroo. We chose ActionScript,
> not Dart, TypeScript or Haxe, as the high-level language to compile to
> JavaScript, because it is so very similar to JavaScript. In fact, it is a
> super set of JavaScript, so that you can copy-paste JavaScript code into
> your ActionScript program and it works!
> When you look at Jangaroo-generated JavaScript code, it closely resembles
> the original ActionScript source code. We optimized the compiler as well as
> the runtime to give the impression that the JS code is actually the AS code
> that you, the developer, wrote. Every source file results in a separate JS
> file, which is also loaded separately in "debug mode". Even the line
> numbers are kept precisely. This allows for debugging directly in the
> browser without the need for any additional / new debugger tools.
> Of course, this approach would not be possible at all when generating JS
> code from ABC, not from AS/AST.
>
> We would like to provide something similar for MXML, too. So the ideal
> solution would be a mixture of the approaches described in this thread.
> Combine Alex' datastructures and the AST->JS approach. This is also very
> similar to how Ext JS UIs are specified using nested JS Object literals.
> The idea would be to generate AS code from MXML that contains both the
> datastructures and the code fragments (<fx:Script>), keeping the line
> numbers (if possible). Then compile the resulting AS to JS, using the
> AST-based method.
> The format could look like so (pseudo-code):
>
> MyPanel.mxml:
> 01 <s:Panel xmlns:s="..."
> 02 title="hello world">
> 03 <s:Button label="click me!">
> 04 <s:click>
> 05 trace('clicked ' + event.source.label);
> 06 </s:click>
> 07 </s:Button>
> 08 </s:Panel>
>
> could become something like
>
> MyPanel.as:
> 01 package ... { import ...; public class MyPanel extends Panel { public
> function MyPanel() { MxmlUtil.apply(this, {
> 02 title: "hello world", children: [
> 03 { type: Button, label: "click me!",
> 04 click: function(event:MouseEvent) {
> 05 trace('clicked ' + event.source.label);
> 06 }
> 07 }
> 08 ]});}}}
>
> When using the Jangaroo approach, this could be compiled to JavaScript,
> keeping the line numbers for code fragments. So if you set a JavaScript
> breakpoint in line 05, this would exactly correspond to line 5 of your MXML
> source code!
>
> There is just one game changer that would convince me that this effort is
> not necessary, and that is JavaScript source maps support in all major
> browsers. Then, the generated JavaScript code could look as ugly as you
> like to have it, but the compiler would still have to provide the mapping
> to the original source code. This should be possible using ABC with debug
> information, shouldn't it?
>
> What do you think?
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
On 12/2/12 2:21 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
>>
> There is one important aspect to consider when deciding which route to take.
> If you, like Bernd Paradies, see JavaScript's role in this process as an
> machine language, it is completely valid to generate JS code from ABC.
Well, I would like the release builds to run as fast as possible, but
debuggability is more important, IMO.
> But this is not the viewpoint we take for Jangaroo. We chose ActionScript,
> not Dart, TypeScript or Haxe, as the high-level language to compile to
> JavaScript, because it is so very similar to JavaScript. In fact, it is a
> super set of JavaScript, so that you can copy-paste JavaScript code into
> your ActionScript program and it works!
> When you look at Jangaroo-generated JavaScript code, it closely resembles
> the original ActionScript source code. We optimized the compiler as well as
> the runtime to give the impression that the JS code is actually the AS code
> that you, the developer, wrote. Every source file results in a separate JS
> file, which is also loaded separately in "debug mode".
I'm ok with that as long as it loads reasonably quickly.
> Even the line
> numbers are kept precisely. This allows for debugging directly in the
> browser without the need for any additional / new debugger tools.
> Of course, this approach would not be possible at all when generating JS
> code from ABC, not from AS/AST.
>
> We would like to provide something similar for MXML, too. So the ideal
> solution would be a mixture of the approaches described in this thread.
> Combine Alex' datastructures and the AST->JS approach. This is also very
> similar to how Ext JS UIs are specified using nested JS Object literals.
If you look at the prototype, it does not use nested object literals. I was
unable to get them to perform as well as the data stream I am using or the
methods it is replacing.
> The idea would be to generate AS code from MXML that contains both the
> datastructures and the code fragments (<fx:Script>), keeping the line
> numbers (if possible).
It is probably possible to maintain line numbers for script blocks, but what
are the advantages of maintaining line numbers in MXML?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FlaconJS] pseudo emitter algorithm
Posted by Frank Wienberg <fr...@jangaroo.net>.
Sorry for joining this discussion so late. Like before, I just would like
to contribute how we approached the problem at Jangaroo.
Some time ago, we created our own declarative, XML-based language, targeted
at creating Ext JS UIs, thus called EXML. EXML is very similar to MXML. The
main difference is that, to have IDE support and validation, EXML is
XML-Schema-based. For every module containing EXML files, an XSD is
generated, describing all available classes and their properties. EXML is
translated to ActionScript, which is then compiled to JavaScript, so we use
two chained compilers for EXML->AS and AS->JS.
After discovering that MXML is acutally not as tied to Flex components as I
used to think (I stumbled across this blog
post<http://dgrigg.com/blog/2010/04/12/when-flex-goes-on-a-slimfast-diet/>),
I experimented with using MXML to define Ext JS UIs. I already have a
prototype of MXML support for Jangaroo on a github
branch<https://github.com/CoreMedia/jangaroo-tools/tree/mxml>which
uses a different approach.
Things became quite complicated with EXML when we wanted to make EXML->AS
generation more intelligent. The EXML->AS compiler needed to inspect
ActionScript classes, but these again could be referring to ActionScript
classes generated from EXML. So we have a circular dependency here, which
was complex to deal with.
Thus, for my MXML prototype, I chose a different approach, namely to
integrate MXML->JS compilation directly into the Jangaroo compiler, so that
when the compilation process needs class acme.Foo, it looks for both
acme/Foo.as and acme/Foo.mxml. If an MXML file is found, internally, the
compiler still generates ActionScript code, parses it into an AST, and then
hands it on to its standard JS code generator. While this may not be the
most efficient solution, it provides best reuse of software components and
works great!
There is one important aspect to consider when deciding which route to take.
If you, like Bernd Paradies, see JavaScript's role in this process as an
machine language, it is completely valid to generate JS code from ABC.
But this is not the viewpoint we take for Jangaroo. We chose ActionScript,
not Dart, TypeScript or Haxe, as the high-level language to compile to
JavaScript, because it is so very similar to JavaScript. In fact, it is a
super set of JavaScript, so that you can copy-paste JavaScript code into
your ActionScript program and it works!
When you look at Jangaroo-generated JavaScript code, it closely resembles
the original ActionScript source code. We optimized the compiler as well as
the runtime to give the impression that the JS code is actually the AS code
that you, the developer, wrote. Every source file results in a separate JS
file, which is also loaded separately in "debug mode". Even the line
numbers are kept precisely. This allows for debugging directly in the
browser without the need for any additional / new debugger tools.
Of course, this approach would not be possible at all when generating JS
code from ABC, not from AS/AST.
We would like to provide something similar for MXML, too. So the ideal
solution would be a mixture of the approaches described in this thread.
Combine Alex' datastructures and the AST->JS approach. This is also very
similar to how Ext JS UIs are specified using nested JS Object literals.
The idea would be to generate AS code from MXML that contains both the
datastructures and the code fragments (<fx:Script>), keeping the line
numbers (if possible). Then compile the resulting AS to JS, using the
AST-based method.
The format could look like so (pseudo-code):
MyPanel.mxml:
01 <s:Panel xmlns:s="..."
02 title="hello world">
03 <s:Button label="click me!">
04 <s:click>
05 trace('clicked ' + event.source.label);
06 </s:click>
07 </s:Button>
08 </s:Panel>
could become something like
MyPanel.as:
01 package ... { import ...; public class MyPanel extends Panel { public
function MyPanel() { MxmlUtil.apply(this, {
02 title: "hello world", children: [
03 { type: Button, label: "click me!",
04 click: function(event:MouseEvent) {
05 trace('clicked ' + event.source.label);
06 }
07 }
08 ]});}}}
When using the Jangaroo approach, this could be compiled to JavaScript,
keeping the line numbers for code fragments. So if you set a JavaScript
breakpoint in line 05, this would exactly correspond to line 5 of your MXML
source code!
There is just one game changer that would convince me that this effort is
not necessary, and that is JavaScript source maps support in all major
browsers. Then, the generated JavaScript code could look as ugly as you
like to have it, but the compiler would still have to provide the mapping
to the original source code. This should be possible using ABC with debug
information, shouldn't it?
What do you think?
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
On 12/1/12 12:52 AM, "Daniel Wasilewski" <de...@gmail.com> wrote:
>>
> And that was my understanding as well. IT looks like you talking about
> ABC AST as the joint point. I don't know how different it might be from
> AS AST when you can rely on top level abstract set of OOP properties,
> when ABC seems to be a stack/procedural assembler ready to talk to
> virtual machine.
An ABC block in a SWF contains class and method descriptors
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FlaconJS] pseudo emitter algorithm
Posted by Daniel Wasilewski <de...@gmail.com>.
>
> The conversation was about exploring a straight AST to JS convertor
> and bypassing the JS emitting using SWF reducer.
>
> My point was in the discussion that I don't know SWF format and JBurg
> so trying to maintain FalconJS in it's current state would be hard for
> a lot of developers.
>
> A lot of cross compilers just work with the straight AST in our case
> the IASNode or IDefinition frameworks.
>
> I also thought having this ability would allow other targets to be
> implemented more quickly IE Java android or something...
>
> What do you think?
>
And that was my understanding as well. IT looks like you talking about
ABC AST as the joint point. I don't know how different it might be from
AS AST when you can rely on top level abstract set of OOP properties,
when ABC seems to be a stack/procedural assembler ready to talk to
virtual machine.
Does ABC has a class, method concept? or just went down to the level of
move, jump etc?
I can imagine that reverse that process to some OOP like structure you
need to back to something that will be easier to represent in JS, so you
going back to AS3 AST.
I think I get it now. But, for MXML it make sense, mxml->abc->as AST ->
js but for js target as AST-> JS is the only part we paying attention
to. Because going from mxml directly to AS or JS seems to be crazy and
less secure task.
Am I correct now in my thinking?
RE: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Gordon Smith <go...@adobe.com>:
> I didn't follow the whole discussion. Is the issue that you were
> planning to work on MXML->JS but Alex and I think
> MXML->datastructure is a better approach? You don't have to accept
> what we say. :)
>
> - Gordon
The conversation was about exploring a straight AST to JS convertor
and bypassing the JS emitting using SWF reducer.
My point was in the discussion that I don't know SWF format and JBurg
so trying to maintain FalconJS in it's current state would be hard for
a lot of developers.
A lot of cross compilers just work with the straight AST in our case
the IASNode or IDefinition frameworks.
I also thought having this ability would allow other targets to be
implemented more quickly IE Java android or something...
What do you think?
> -----Original Message-----
> From: Michael Schmalle [mailto:apache@teotigraphix.com]
> Sent: Friday, November 30, 2012 3:55 PM
> To: flex-dev@incubator.apache.org
> Subject: RE: [FlaconJS] pseudo emitter algorithm
>
> Well considering the conversation between you two, I will ditch
> pretty much all I said in the last 3 days. This is what I get for
> living on a mountain...
>
> I have interest in the non-flash player stuff, so I guess I will
> keep up with your conversations.
>
> For now, I will focus on testing the compiler and trying to get in a
> groove somehow dealing with that. I'm going to try and document more
> of the compiler on the wiki. Gordon feel free the correct me if I'm
> wrong in places.
>
> And, I will try to really understand Alex's prototype and see if I
> can get my brain wrapped around that to help with some simple test
> components.
>
> Mike
>
> Quoting Gordon Smith <go...@adobe.com>:
>
>> That sounds fine. We'll work in parallel:
>>
>> Me: MXML->ABC
>> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>>
>> - Gordon
>>
>> -----Original Message-----
>> From: Alex Harui [mailto:aharui@adobe.com]
>> Sent: Friday, November 30, 2012 3:29 PM
>> To: flex-dev@incubator.apache.org
>> Subject: Re: [FlaconJS] pseudo emitter algorithm
>>
>>
>>
>>
>> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>>
>>> MXML->JS doesn't exist and is not the way to go.
>>> MXML->datastructure is a good idea. Alex will do it first for
>>> MXML->interpretation
>>> by JS and later for interpretation by an ABC library written in AS.
>> I'm pretty sure I had this all working last year in AS. I just have
>> to dust it off. Right now it is easier/faster for me to debug in AS,
>> so I will probably do the AS version first, but I will be keeping all
>> of the old ABC code paths around. Right now there is some global flag
>> that determines which code paths to go down. I might tie that to some
>> new property in flex-config.xml or something like that.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
RE: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
I didn't follow the whole discussion. Is the issue that you were planning to work on MXML->JS but Alex and I think MXML->datastructure is a better approach? You don't have to accept what we say. :)
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apache@teotigraphix.com]
Sent: Friday, November 30, 2012 3:55 PM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Well considering the conversation between you two, I will ditch pretty much all I said in the last 3 days. This is what I get for living on a mountain...
I have interest in the non-flash player stuff, so I guess I will keep up with your conversations.
For now, I will focus on testing the compiler and trying to get in a groove somehow dealing with that. I'm going to try and document more of the compiler on the wiki. Gordon feel free the correct me if I'm wrong in places.
And, I will try to really understand Alex's prototype and see if I can get my brain wrapped around that to help with some simple test components.
Mike
Quoting Gordon Smith <go...@adobe.com>:
> That sounds fine. We'll work in parallel:
>
> Me: MXML->ABC
> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>
> - Gordon
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 3:29 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>
>> MXML->JS doesn't exist and is not the way to go.
>> MXML->datastructure is a good idea. Alex will do it first for
>> MXML->interpretation
>> by JS and later for interpretation by an ABC library written in AS.
> I'm pretty sure I had this all working last year in AS. I just have
> to dust it off. Right now it is easier/faster for me to debug in AS,
> so I will probably do the AS version first, but I will be keeping all
> of the old ABC code paths around. Right now there is some global flag
> that determines which code paths to go down. I might tie that to some
> new property in flex-config.xml or something like that.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
On 11/30/12 4:15 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> Ok so instead of emitting JS from MXML generated ABC you want to emit
> it from MXML generated data structure from the AST?
I'm not sure yet. I just found the code I did a year ago. I made changes
to MXMLClassDirectiveProcessor and never checked them in. IIRC, there all
of these methods that get called in walking the MXML parse tree that add
instructions to the various functions in the current codegen.
I generated the data structure by skipping over the instructions that create
new method entries and added other instructions and saved it all up and set
it as one giant array on the class. It worked, but might be too hacky.
In order to generate JS, my first instinct is to find a way to swap out
MXMLClassDirectiveProcessor for a JSMXMLClassDirectiveProcessor. It looks
like the FalconJS emitter returns instructions that are JS strings, so I
would try that as well.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 11/30/12 3:55 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> Well considering the conversation between you two, I will ditch pretty
>> much all I said in the last 3 days. This is what I get for living on a
>> mountain...
> I'm not sure what we said that would change your mind. I thought lots of
> folks, including me, want some flexibility in the AS->JS conversion. If you
> can help there and explore going straight from AST to JS, that would seem
> like a worthy task.
Ok, I must have misunderstood something here. Sounds good to me. I
think I am straight about what you two are talking about.
> Gordon and I and some others want to finish up MXML compilation. Gordon
> will be making it generate ABC, I will be making it generate ABC codes for a
> data structure, and later, JS for the same data structure.
Ok so instead of emitting JS from MXML generated ABC you want to emit
it from MXML generated data structure from the AST?
Mike
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
On 11/30/12 3:55 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Well considering the conversation between you two, I will ditch pretty
> much all I said in the last 3 days. This is what I get for living on a
> mountain...
I'm not sure what we said that would change your mind. I thought lots of
folks, including me, want some flexibility in the AS->JS conversion. If you
can help there and explore going straight from AST to JS, that would seem
like a worthy task.
Gordon and I and some others want to finish up MXML compilation. Gordon
will be making it generate ABC, I will be making it generate ABC codes for a
data structure, and later, JS for the same data structure.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Well considering the conversation between you two, I will ditch pretty
much all I said in the last 3 days. This is what I get for living on a
mountain...
I have interest in the non-flash player stuff, so I guess I will keep
up with your conversations.
For now, I will focus on testing the compiler and trying to get in a
groove somehow dealing with that. I'm going to try and document more
of the compiler on the wiki. Gordon feel free the correct me if I'm
wrong in places.
And, I will try to really understand Alex's prototype and see if I can
get my brain wrapped around that to help with some simple test
components.
Mike
Quoting Gordon Smith <go...@adobe.com>:
> That sounds fine. We'll work in parallel:
>
> Me: MXML->ABC
> You: MXML->datastructure, first for use in AS/ABC, then for use in JS
>
> - Gordon
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 3:29 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
>
>> MXML->JS doesn't exist and is not the way to go.
>> MXML->datastructure is a good idea. Alex will do it first for
>> MXML->interpretation
>> by JS and later for interpretation by an ABC library written in AS.
> I'm pretty sure I had this all working last year in AS. I just have
> to dust it off. Right now it is easier/faster for me to debug in
> AS, so I will probably do the AS version first, but I will be
> keeping all of the old ABC code paths around. Right now there is
> some global flag that determines which code paths to go down. I
> might tie that to some new property in flex-config.xml or something
> like that.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
RE: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
That sounds fine. We'll work in parallel:
Me: MXML->ABC
You: MXML->datastructure, first for use in AS/ABC, then for use in JS
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Friday, November 30, 2012 3:29 PM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
> MXML->JS doesn't exist and is not the way to go.
> MXML->datastructure is a good idea. Alex will do it first for
> MXML->interpretation
> by JS and later for interpretation by an ABC library written in AS.
I'm pretty sure I had this all working last year in AS. I just have to dust it off. Right now it is easier/faster for me to debug in AS, so I will probably do the AS version first, but I will be keeping all of the old ABC code paths around. Right now there is some global flag that determines which code paths to go down. I might tie that to some new property in flex-config.xml or something like that.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
On 11/30/12 3:22 PM, "Gordon Smith" <go...@adobe.com> wrote:
> MXML->JS doesn't exist and is not the way to go.
> MXML->datastructure is a good idea. Alex will do it first for interpretation
> by JS and later for interpretation by an ABC library written in AS.
I'm pretty sure I had this all working last year in AS. I just have to dust
it off. Right now it is easier/faster for me to debug in AS, so I will
probably do the AS version first, but I will be keeping all of the old ABC
code paths around. Right now there is some global flag that determines
which code paths to go down. I might tie that to some new property in
flex-config.xml or something like that.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [FlaconJS] pseudo emitter algorithm
Posted by Gordon Smith <go...@adobe.com>.
I think I agree with everything you said, Alex.
Here's my take:
AS->ABC is already done in Falcon, modulo some bug fixes.
AS->JS is kinda done in FalconJS but needs work and we may want to change it to emit different JS patterns.
MXML->ABC is 80% done in Falcon and worth completing. I'm working on determining what works, what doesn't, and fixing problems.
MXML->JS doesn't exist and is not the way to go.
MXML->datastructure is a good idea. Alex will do it first for interpretation by JS and later for interpretation by an ABC library written in AS.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Friday, November 30, 2012 3:04 PM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
OK, what did I write that is confusing everybody?
IIUC, MXML is parsed into a different set of nodes which are then visited in the tree walk to generate ABC codes directly. When compiling the AS in an MXML script block or a .AS file, the AS AST nodes go through Jburg and eventually become ABC.
FalconJS only overrides the AS AST nodes to generate JS. I don't think it will generate anything for MXML, but I haven't tried it.
MXML -> ABC is mostly or all in MXMLClassDirectiveProcessor.java.
I think FalconJS will have to swap/overlay/override what that class does to generate JS.
What MXML currently resolves to in ABC is the equivalent of a bunch of functions that construct the tags in the MXML. For many reasons which I have mentioned before, I am planning to change the ABC that it generates to generate a data structure. And then FalconJS will need to generate the same data structure in JS.
Does that help?
On 11/30/12 2:51 PM, "Daniel Wasilewski" <de...@gmail.com> wrote:
> I'm trying to follow, but I feel the same.
>
> My main confusion came from the one thing. I've got in my mind AST is
> just AST. Abstract by definition. It represents a code logic in
> abstract form.
> Why JS would collide with AS? Why the Falcon after AST coming back to
> AS? AST says, create class, create method, create method body,
> expression and evaluate it.
> And now if JS is a target should have grammar definition how to create
> a class, method and represent evaluation. Am I missing a point of
> compilers, parsers etc?
>
>
> On 11/30/2012 7:41 PM, Michael Schmalle wrote:
>> Ok, I'm a bit confused but my brain is probably going to explode any
>> minute and that is about all from me for a bit.
>>
>> I'll just sit back and see if any other conversations come up about
>> as
>> -> js. Maybe I'm crazy and just want to create more work for myself.
>>
>> Maybe the way it stands ABC -> js is good enough for now?
>>
>> Mike
>>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>>
>>> On 11/30/12 11:05 AM, "Michael Schmalle" <ap...@teotigraphix.com>
>>> wrote:
>>>
>>>> Quoting Gordon Smith <go...@adobe.com>:
>>>>
>>>>> I don't object to generating a data structure for V11, but I think
>>>>> that it makes more sense to do that as a second phase after ABC
>>>>> generation is working. Otherwise there are a lot of moving parts
>>>>> and progress will be slower.
>>>>
>>>> Correct me if I'm wrong Alex, but Gordon, I think Alex was talking
>>>> about JavaScript data structures produced during crosscompile of MXML.
>>> No, for both AS and JS so we have the same code paths. But fear
>>> not, the the work I did last year has a switch and all the old code
>>> paths are retained.
>>>
>>> I accept Gordon's argument that we can finish MXML handling faster
>>> by getting Falcon to generate the old code patterns.
>>>>
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui