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" <gosm...@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:apa...@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 <gosm...@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:apa...@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 <gosm...@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:aha...@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" <gosm...@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
