incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Sat, 01 Dec 2012 04:44:43 GMT
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" <gosmith@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 <gosmith@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 <gosmith@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" <gosmith@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


Mime
View raw message