From flex-dev-return-15778-apmail-incubator-flex-dev-archive=incubator.apache.org@incubator.apache.org Sun Dec 2 20:07:44 2012 Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3CDB7E5D4 for ; Sun, 2 Dec 2012 20:07:44 +0000 (UTC) Received: (qmail 20388 invoked by uid 500); 2 Dec 2012 20:07:43 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 20361 invoked by uid 500); 2 Dec 2012 20:07:43 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 20351 invoked by uid 99); 2 Dec 2012 20:07:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Dec 2012 20:07:43 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gosmith@adobe.com designates 64.18.1.189 as permitted sender) Received: from [64.18.1.189] (HELO exprod6og105.obsmtp.com) (64.18.1.189) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Dec 2012 20:07:35 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKULu08lkrYC6EXqBqiakECJkiIZteEfre@postini.com; Sun, 02 Dec 2012 12:07:15 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qB2K4M1v028509 for ; Sun, 2 Dec 2012 12:04:22 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qB2K7CNc013915; Sun, 2 Dec 2012 12:07:13 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 2 Dec 2012 12:07:12 -0800 From: Gordon Smith To: "flex-dev@incubator.apache.org" CC: "flex-dev@incubator.apache.org" Date: Sun, 2 Dec 2012 12:07:13 -0800 Subject: Re: [FlaconJS] pseudo emitter algorithm Thread-Topic: [FlaconJS] pseudo emitter algorithm Thread-Index: Ac3QyJ2VUI7QydiyQ3KVS2KDpx2HbQ== Message-ID: <05AE47C3-E3FA-49ED-ADB8-6F32A8DB8006@adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org The bottom-upness of the BURM means that subtrees that are nearer to the le= aves 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" wrote: > Interesting. Someday I will figure out what is bottom up about it. >=20 > Anyway, thanks, and bottoms up! >=20 > -Alex >=20 >=20 > On 11/30/12 9:48 PM, "Gordon Smith" wrote: >=20 >> The BURM is the Bottom-Up Rewrite Machine that the BURG or Bottom-Up Rew= rite >> 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. >>=20 >> Sent from my iPad >>=20 >> On Nov 30, 2012, at 8:45 PM, "Alex Harui" wrote: >>=20 >>> BURM? What does that stand for anyway? It might as well have been Bur= mese. >>> It will take a while to understand :-) >>>=20 >>>=20 >>> On 11/30/12 5:36 PM, "Gordon Smith" wrote: >>>=20 >>>>> I don't know SWF format and JBurg >>>>=20 >>>> The SWF and ABC formats are irrelevant if you want to generate JS code= , so >>>> you >>>> wouldn't need to learn them. >>>>=20 >>>> If you don't want to learn about the BURM I suppose you could try gene= rating >>>> JS code directly from the AST. I don't know enough about FalconJS to k= now >>>> whether the BURM approach produces more efficient code. Understanding = the >>>> BURM >>>> is not terribly hard, though. There are three main ideas: >>>>=20 >>>> 1. A BURM pattern like >>>>=20 >>>> Pattern labeledBreakStmt >>>> BreakID(IdentifierID(void)); >>>>=20 >>>> describes a subtree within the AST; in this case, it is describing the >>>> subtree >>>>=20 >>>> BreakNode >>>> IdentifierNode >>>>=20 >>>> that represents code like "break foo"; >>>>=20 >>>> 2. A BURM rule like >>>>=20 >>>> statement =3D Pattern labeledBreakStmt: 0 >>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p); >>>>=20 >>>> tells the BURM what to do when it finds such a subtree: namely, call t= he >>>> Java >>>> method reduce_labeledBreakStmt() in the ASGeneratingReducer, which has= a >>>> slew >>>> of "reduce_XXX()" methods for reducing various subtrees. >>>>=20 >>>> 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 descr= ibe >>>> more >>>> general or recursive patterns, as in >>>>=20 >>>> Pattern blockStmt >>>> BlockID(statement stmts*); >>>>=20 >>>> For example, this says that a block statement is a BlockNode with mult= iple >>>> child nodes which have been reduced to a 'statement'. >>>>=20 >>>> 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 yo= ur >>>> work >>>> inside the JSGeneratingReducer. I believe this was Bernd's approach wh= en he >>>> developed FalconJS. You just make the reduce_XXX() method produce JS s= trings >>>> rather than ABC InstructionLists. >>>>=20 >>>> - Gordon >>>>=20 >>>> -----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 >>>>=20 >>>> Quoting Gordon Smith : >>>>=20 >>>>> 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. :) >>>>>=20 >>>>> - Gordon >>>>=20 >>>> The conversation was about exploring a straight AST to JS convertor >>>> and bypassing the JS emitting using SWF reducer. >>>>=20 >>>> 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. >>>>=20 >>>> A lot of cross compilers just work with the straight AST in our case >>>> the IASNode or IDefinition frameworks. >>>>=20 >>>> I also thought having this ability would allow other targets to be >>>> implemented more quickly IE Java android or something... >>>>=20 >>>> What do you think? >>>>=20 >>>>=20 >>>>> -----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 >>>>>=20 >>>>> 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... >>>>>=20 >>>>> I have interest in the non-flash player stuff, so I guess I will >>>>> keep up with your conversations. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Mike >>>>>=20 >>>>> Quoting Gordon Smith : >>>>>=20 >>>>>> That sounds fine. We'll work in parallel: >>>>>>=20 >>>>>> Me: MXML->ABC >>>>>> You: MXML->datastructure, first for use in AS/ABC, then for use in J= S >>>>>>=20 >>>>>> - Gordon >>>>>>=20 >>>>>> -----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 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 11/30/12 3:22 PM, "Gordon Smith" wrote: >>>>>>=20 >>>>>>> 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 al= l >>>>>> of the old ABC code paths around. Right now there is some global fl= ag >>>>>> that determines which code paths to go down. I might tie that to so= me >>>>>> new property in flex-config.xml or something like that. >>>>>>=20 >>>>>> -- >>>>>> Alex Harui >>>>>> Flex SDK Team >>>>>> Adobe Systems, Inc. >>>>>> http://blogs.adobe.com/aharui >>>>>=20 >>>>> -- >>>>> Michael Schmalle - Teoti Graphix, LLC >>>>> http://www.teotigraphix.com >>>>> http://blog.teotigraphix.com >>>=20 >>> --=20 >>> Alex Harui >>> Flex SDK Team >>> Adobe Systems, Inc. >>> http://blogs.adobe.com/aharui >=20 > --=20 > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui >=20