incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject RE: [FlaconJS] pseudo emitter algorithm
Date Sat, 01 Dec 2012 01:36:21 GMT
> 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
>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com


Mime
View raw message