You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Michael Schmalle <ap...@teotigraphix.com> on 2012/11/29 16:30:12 UTC
[FlaconJS] pseudo emitter algorithm
Hi,
For those asking question about "where to alter" code, it's not pretty
but I think I know exactly what is going on now.
If you can understand below, you will now have some insight to where
and how the JS code actually gets created.
! Call the compiler load config compile().
JSGenerator.generate() - creates the package, class, member traits
- DirectiveProcessor.processNode(IFileNode)
- recusrsivly fill traits
-----------------------------------------------------
Basically a snippet of the recursion;
DirectiveProcessor.processNode(IFileNode)
- declarePackage(PackageNode)
- emitter.visitPackage(packageName)
- data.registerPackage(packageName)
- super.declarePackage(PackageNode)
- DirectiveProcessor.traverse(p.getScopedNode()) <- ClassNode (class {})
- for each ClassNode.getChild(i)
- processNode(ScopedBlockNode)
- JSGlobalDirectiveProcessor.declareClass(ClassNode)
- verifyClassModifiers(ClassNode)
- skins
- JSClassDirectiveProcessor cp =
backend.createClassDirectiveProcessor()
- cp.traverse(ClassNode.getScopedNode()) <- TypeScope
- for each TypeScope.getChild(i)
- processNode(TypeScope)
- JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
--------------------------------------------------------
!!!!
JavaScript source code creation after class traits have been traversed
and created;
JSEmiter.emit()
- emitClass(EmitterClassVisitor)
- IClassDefinition = getDefinition(ii.name)
- write class JSDoc
- JSEmitter.emitClass()
- Line: 3267 - 3269 is What creates a class
- "MainCode=adobe.extend("MainCode",Object,{ ... });"
- JSEmitter.emitInstanceTraits() is then called to write out the class traits
- emitTraits() is then called to do the specific if the closure
compiler flag is not set
1. emitCtor() emit constructor
- emit comma
2. emit all variables before methods
- assembles the code "MainCode.foo"
- warns if there is a private namespace collision
-
3. emit all methods other than constructor
- emit ",\n"
- emitMethod()
- emitJSDocForMethod()
- write("\tget_baz")
- write(" : ") <- assignmentOp
- write("function(")
- emitParameters(methodInfo)
- write("baz")
- write(")")
- if (returnType != null)
- write(JSDoc for return type)
- if interface method
- write(" {};\n")
- else
- write("\n")
- write(" {")
- write("\n")
- emitMethodBody()
... you get the drift
- write(" }")
- After all traits are written, control flow goes back to
JSEmitter.emitClass() line 3269
- write("\n});\n\n") // end class
- add _CLASS member to instance
- add JSDoc for prototype._CLASS
- write("MainCode.prototype._CLASS = MainCode;\n")
It will then go onto
- emitClassInfo()
- emitNamespaceInfo()
- emitJSONInfo()
if (JSSharedData.JS_FRAMEWORK_NAME)
- emitFrameworkInit();
It will then finally emit register class
- "adobe.classes.MainCode=MainCode;"
---------------
MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
MainCode._FULLNAME="MainCode";
MainCode._SUPER=Object;
MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":!0};
adobe.classes.MainCode=MainCode;
---------------
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Thanks, Mike!
EdB
On Thu, Nov 29, 2012 at 4:30 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Hi,
>
> For those asking question about "where to alter" code, it's not pretty but I
> think I know exactly what is going on now.
>
> If you can understand below, you will now have some insight to where and how
> the JS code actually gets created.
>
>
> ! Call the compiler load config compile().
>
>
> JSGenerator.generate() - creates the package, class, member traits
>
> - DirectiveProcessor.processNode(IFileNode)
> - recusrsivly fill traits
>
> -----------------------------------------------------
>
> Basically a snippet of the recursion;
>
> DirectiveProcessor.processNode(IFileNode)
> - declarePackage(PackageNode)
> - emitter.visitPackage(packageName)
> - data.registerPackage(packageName)
> - super.declarePackage(PackageNode)
> - DirectiveProcessor.traverse(p.getScopedNode()) <- ClassNode (class
> {})
> - for each ClassNode.getChild(i)
> - processNode(ScopedBlockNode)
> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
> - verifyClassModifiers(ClassNode)
> - skins
> - JSClassDirectiveProcessor cp =
> backend.createClassDirectiveProcessor()
> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
> - for each TypeScope.getChild(i)
> - processNode(TypeScope)
> -
> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>
>
> --------------------------------------------------------
>
> !!!!
> JavaScript source code creation after class traits have been traversed and
> created;
>
>
> JSEmiter.emit()
> - emitClass(EmitterClassVisitor)
> - IClassDefinition = getDefinition(ii.name)
> - write class JSDoc
>
>
>
> - JSEmitter.emitClass()
> - Line: 3267 - 3269 is What creates a class
> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>
>
>
> - JSEmitter.emitInstanceTraits() is then called to write out the class
> traits
> - emitTraits() is then called to do the specific if the closure compiler
> flag is not set
> 1. emitCtor() emit constructor
> - emit comma
> 2. emit all variables before methods
> - assembles the code "MainCode.foo"
> - warns if there is a private namespace collision
> -
> 3. emit all methods other than constructor
> - emit ",\n"
> - emitMethod()
> - emitJSDocForMethod()
> - write("\tget_baz")
> - write(" : ") <- assignmentOp
> - write("function(")
> - emitParameters(methodInfo)
> - write("baz")
> - write(")")
> - if (returnType != null)
> - write(JSDoc for return type)
> - if interface method
> - write(" {};\n")
> - else
> - write("\n")
> - write(" {")
> - write("\n")
> - emitMethodBody()
> ... you get the drift
> - write(" }")
>
> - After all traits are written, control flow goes back to
> JSEmitter.emitClass() line 3269
> - write("\n});\n\n") // end class
> - add _CLASS member to instance
> - add JSDoc for prototype._CLASS
> - write("MainCode.prototype._CLASS = MainCode;\n")
>
> It will then go onto
> - emitClassInfo()
> - emitNamespaceInfo()
> - emitJSONInfo()
>
> if (JSSharedData.JS_FRAMEWORK_NAME)
> - emitFrameworkInit();
>
> It will then finally emit register class
> - "adobe.classes.MainCode=MainCode;"
>
> ---------------
> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
> MainCode._FULLNAME="MainCode";
> MainCode._SUPER=Object;
> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":!0};
> adobe.classes.MainCode=MainCode;
> ---------------
>
> Mike
>
>
>
>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FlaconJS] pseudo emitter algorithm
Posted by Daniel Wasilewski <de...@gmail.com>.
Thanks for detailed explanation Mike!
Everything below that, is actually clear without getting into details of
recursive methods itself.
On 11/29/2012 3:30 PM, Michael Schmalle wrote:
> Hi,
>
> For those asking question about "where to alter" code, it's not pretty
> but I think I know exactly what is going on now.
>
> If you can understand below, you will now have some insight to where
> and how the JS code actually gets created.
>
>
> ! Call the compiler load config compile().
>
>
> JSGenerator.generate() - creates the package, class, member traits
>
> - DirectiveProcessor.processNode(IFileNode)
> - recusrsivly fill traits
>
> -----------------------------------------------------
>
> Basically a snippet of the recursion;
>
> DirectiveProcessor.processNode(IFileNode)
> - declarePackage(PackageNode)
> - emitter.visitPackage(packageName)
> - data.registerPackage(packageName)
> - super.declarePackage(PackageNode)
> - DirectiveProcessor.traverse(p.getScopedNode()) <- ClassNode
> (class {})
> - for each ClassNode.getChild(i)
> - processNode(ScopedBlockNode)
> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
> - verifyClassModifiers(ClassNode)
> - skins
> - JSClassDirectiveProcessor cp =
> backend.createClassDirectiveProcessor()
> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
> - for each TypeScope.getChild(i)
> - processNode(TypeScope)
> -
> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>
>
> --------------------------------------------------------
>
> !!!!
> JavaScript source code creation after class traits have been traversed
> and created;
>
>
> JSEmiter.emit()
> - emitClass(EmitterClassVisitor)
> - IClassDefinition = getDefinition(ii.name)
> - write class JSDoc
>
>
>
> - JSEmitter.emitClass()
> - Line: 3267 - 3269 is What creates a class
> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>
>
>
> - JSEmitter.emitInstanceTraits() is then called to write out the class
> traits
> - emitTraits() is then called to do the specific if the closure
> compiler flag is not set
> 1. emitCtor() emit constructor
> - emit comma
> 2. emit all variables before methods
> - assembles the code "MainCode.foo"
> - warns if there is a private namespace collision
> -
> 3. emit all methods other than constructor
> - emit ",\n"
> - emitMethod()
> - emitJSDocForMethod()
> - write("\tget_baz")
> - write(" : ") <- assignmentOp
> - write("function(")
> - emitParameters(methodInfo)
> - write("baz")
> - write(")")
> - if (returnType != null)
> - write(JSDoc for return type)
> - if interface method
> - write(" {};\n")
> - else
> - write("\n")
> - write(" {")
> - write("\n")
> - emitMethodBody()
> ... you get the drift
> - write(" }")
>
> - After all traits are written, control flow goes back to
> JSEmitter.emitClass() line 3269
> - write("\n});\n\n") // end class
> - add _CLASS member to instance
> - add JSDoc for prototype._CLASS
> - write("MainCode.prototype._CLASS = MainCode;\n")
>
> It will then go onto
> - emitClassInfo()
> - emitNamespaceInfo()
> - emitJSONInfo()
>
> if (JSSharedData.JS_FRAMEWORK_NAME)
> - emitFrameworkInit();
>
> It will then finally emit register class
> - "adobe.classes.MainCode=MainCode;"
>
> ---------------
> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
> MainCode._FULLNAME="MainCode";
> MainCode._SUPER=Object;
> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":!0};
>
> adobe.classes.MainCode=MainCode;
> ---------------
>
> Mike
>
>
>
>
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I'm typing to much (correction).
The CmcJSEmitter is used to "Generate an ABC file equivalent to the
input syntax tree."
NOT
traverse. The CmcJSEmitter traverses the AST and creates the SWF that
is then used to create the JS output.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
> Quoting Alex Harui <ah...@adobe.com>:
>
>> Very nice. Have you figured out the role of the generated CMCEmitter in
>> this process?
>
> Yes,
>
> The CmcJSEmitter (autogenerated by cmc-js.jbg) is used to traverse
> the ISWF that is created.
>
> The CmcJSEmitter and JSGeneratingReducer are created in the
> JSGenerator constructor.
>
> The actual CmcJSEmitter is used during the
> JSClassDirectiveProcessor.delcareVariable() etc. methods.
>
> Basically the processor is using the emitter to create SWF
> instructions that ultimately end up creating class traits. Once the
> tratis are created, they just keep getting recursively visited and
> more instructions created.
>
> So it's like
>
> - JSCompilationUnit.processABCBytesRequest()
> - handleABCBytesRequest()
> - JSGenerator.generate()
> - then see below ....
>
> When it gets to methods called declarePackage() for instance, block
> code instructions are created using the cmc emitter. Traits are then
> created based of them.
>
> For FalconJS this process is totally bound to SWF format.
>
> This was my point. For any developer to fix bugs here they have to
> know the SWF format. Which I don't.
>
> This is why I propsed another solution using pure AST like Jangaroo does.
>
> I am not skilled enough to understand the trade offs currently. But
> I am going to try and see if I can create the same JS code using a
> different algorithm.
>
> Mike
>
>
>
>>
>> On 11/29/12 7:30 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>>> Hi,
>>>
>>> For those asking question about "where to alter" code, it's not pretty
>>> but I think I know exactly what is going on now.
>>>
>>> If you can understand below, you will now have some insight to where
>>> and how the JS code actually gets created.
>>>
>>>
>>> ! Call the compiler load config compile().
>>>
>>>
>>> JSGenerator.generate() - creates the package, class, member traits
>>>
>>> - DirectiveProcessor.processNode(IFileNode)
>>> - recusrsivly fill traits
>>>
>>> -----------------------------------------------------
>>>
>>> Basically a snippet of the recursion;
>>>
>>> DirectiveProcessor.processNode(IFileNode)
>>> - declarePackage(PackageNode)
>>> - emitter.visitPackage(packageName)
>>> - data.registerPackage(packageName)
>>> - super.declarePackage(PackageNode)
>>> - DirectiveProcessor.traverse(p.getScopedNode()) <- ClassNode (class
>>> {})
>>> - for each ClassNode.getChild(i)
>>> - processNode(ScopedBlockNode)
>>> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
>>> - verifyClassModifiers(ClassNode)
>>> - skins
>>> - JSClassDirectiveProcessor cp =
>>> backend.createClassDirectiveProcessor()
>>> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
>>> - for each TypeScope.getChild(i)
>>> - processNode(TypeScope)
>>> -
>>> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>>>
>>>
>>> --------------------------------------------------------
>>>
>>> !!!!
>>> JavaScript source code creation after class traits have been traversed
>>> and created;
>>>
>>>
>>> JSEmiter.emit()
>>> - emitClass(EmitterClassVisitor)
>>> - IClassDefinition = getDefinition(ii.name)
>>> - write class JSDoc
>>>
>>>
>>>
>>> - JSEmitter.emitClass()
>>> - Line: 3267 - 3269 is What creates a class
>>> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>>>
>>>
>>>
>>> - JSEmitter.emitInstanceTraits() is then called to write out the
>>> class traits
>>> - emitTraits() is then called to do the specific if the closure
>>> compiler flag is not set
>>> 1. emitCtor() emit constructor
>>> - emit comma
>>> 2. emit all variables before methods
>>> - assembles the code "MainCode.foo"
>>> - warns if there is a private namespace collision
>>> -
>>> 3. emit all methods other than constructor
>>> - emit ",\n"
>>> - emitMethod()
>>> - emitJSDocForMethod()
>>> - write("\tget_baz")
>>> - write(" : ") <- assignmentOp
>>> - write("function(")
>>> - emitParameters(methodInfo)
>>> - write("baz")
>>> - write(")")
>>> - if (returnType != null)
>>> - write(JSDoc for return type)
>>> - if interface method
>>> - write(" {};\n")
>>> - else
>>> - write("\n")
>>> - write(" {")
>>> - write("\n")
>>> - emitMethodBody()
>>> ... you get the drift
>>> - write(" }")
>>>
>>> - After all traits are written, control flow goes back to
>>> JSEmitter.emitClass() line 3269
>>> - write("\n});\n\n") // end class
>>> - add _CLASS member to instance
>>> - add JSDoc for prototype._CLASS
>>> - write("MainCode.prototype._CLASS = MainCode;\n")
>>>
>>> It will then go onto
>>> - emitClassInfo()
>>> - emitNamespaceInfo()
>>> - emitJSONInfo()
>>>
>>> if (JSSharedData.JS_FRAMEWORK_NAME)
>>> - emitFrameworkInit();
>>>
>>> It will then finally emit register class
>>> - "adobe.classes.MainCode=MainCode;"
>>>
>>> ---------------
>>> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
>>> MainCode._FULLNAME="MainCode";
>>> MainCode._SUPER=Object;
>>> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":!0
>>> };
>>> adobe.classes.MainCode=MainCode;
>>> ---------------
>>>
>>> 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
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Frank Wienberg <fr...@jangaroo.net>.
Hi Alex,
perhaps I did not make the point about the output packaging format so clear.
Of course, for compilation reference, an SWC would suffice. But for
Jangaroo, it did not make any sense to use SWC or SWF for packaging, as we
would have needed to implement an additional format. Also, scanning the
"binaries" (here: JavaScript) to find the API would be cumbersome. Instead,
we use ActionScript as the module API description language and reuse the
parser we already have!
Because we want to put everything produces by a module build into a single
"artifact", we use a JAR containing the generated JS files as well as the
ActionScript describing the module API. For details, see the documentation
of the Jangaroo build
process<https://github.com/CoreMedia/jangaroo-tools/wiki/Maven-Build-Process>
.
For Falcon, it may be more natural to output SWCs containing additional
"binaries" (JavaScript), but if your only compile target is JavaScript, it
feels like an unnecessary overhead.
Does that clarify things?
Concerning the point about closed source, yes, I agree that minification /
obfuscation should suffice. After all, that's what the Java community does,
too, since Java byte code can be reverse-engineered too easily.
Greetings,
-Frank-
On Fri, Nov 30, 2012 at 5:38 PM, Alex Harui <ah...@adobe.com> wrote:
> You guys have lost me a bit.
>
> IMO, all I want as output is a series of .JS files (that would later get
> minified by GCC for release builds). I don't get how the JSEmitter's
> reliance on SWF output constructs like traits would affect the output.
> Seems like you should be able to generate the same thing from the AST.
> Potentially even faster than having to unravel the
> MethodInfo/MethodBodyInfo
> constructs.
>
> I also don't see how the fact that Falcon consumes SWCs in order to resolve
> the symbols at compilation time affects the output either. And isn't SWC
> consumption all you really need for modular development? You shouldn't
> need
> the module binaries, the two projects should be sharing a common interface.
> In my mind, modules are separate .js files loaded at different times. The
> key is if you can minify them without destroying their common interface.
> Someone said you can tune GCC to do that.
>
> Anyway, good point about closed source since all JS is open. But all
> enterprises moving to JS just be dealing with this some way already right?
> Isn't minification about as good as abc code in the SWF? You could always
> dump a SWF and get most of the algorithm back.
>
> Or maybe I'm totally missing what you guys are talking about.
>
> -Alex
>
> On 11/30/12 2:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> > Quoting Frank Wienberg <fr...@jangaroo.net>:
> >
> >> On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
> >> <ap...@teotigraphix.com>wrote:
> >>
> >>> For FalconJS this process is totally bound to SWF format.
> >>>
> >>> This was my point. For any developer to fix bugs here they have to know
> >>> the SWF format. Which I don't.
> >>>
> >>> This is why I propsed another solution using pure AST like Jangaroo
> does.
> >>>
> >>> I am not skilled enough to understand the trade offs currently. But I
> am
> >>> going to try and see if I can create the same JS code using a different
> >>> algorithm.
> >>>
> >>
> >> I guess the trade off is that the AST approach leads to a different
> >> packaging format. For Jangaroo, we use JARs that contain the generated
> JS
> >> code as well as generated AS "API stubs" (under META-INF/joo-api), that
> is
> >> the AS code is reduced to its API, using the "native" keyword. This
> allows
> >> to compile against other modules without having their source code.
> However,
> >> the consequence is that you need a different classpath and custom build
> >> tools: we created a Maven plugin that provides a custom packaging type
> >> currently called "jangaroo" that outputs a JAR in the format described
> >> above.
> >> When the output format is SWC/SWF, you more closely resemble Flash/Flex.
> >> But honestly, unless we transform ActionScript byte code into JavaScript
> >> (or interpret it in JavaScript like in Gordon's approach), we cannot use
> >> any "binary" modules, anyway, but instead all modules have to be
> recompiled
> >> for use with FalconJS, or even worse you need the complete source code
> for
> >> the whole project, which would increase build time and hinder real
> modular
> >> development as well as closed source modules--quite a show stopper for
> an
> >> Enterprise tool!
> >>
> >> -Frank-
> >>
> >
> > Ok, I didn't even think about the recompile. So in my mind, please
> > correct me if I'm wrong, the SWC/SWF probably was chosen because it IS
> > the packaging and organization structure currently. Where you are
> > using a jar as you said. Correct?
> >
> > Since you have so much experience with as->js, what is your opinion on
> > implementation? I'm asking because I might be putting a lot of work
> > into the compiler output and would like to know which direction. Do
> > you see any way of interfacing jangaroo and falcon/falconjs?
> >
> > Do you think offering the straight AST emitter(which would allow
> > granular compiles with native stubs) like yours AND the SWF/SWC option
> > and somehow getting them on the same API is something to consider?
> >
> > As I said earlier, you have some great code, I would love to work
> > together somehow to get a nice application framework our there like
> > Flex ontop of JS and whatever other language we could get to, Android,
> > iOS, whatever.
> >
> > Thanks for all your time Frank!
> >
> > Mike
> >
> >
> >
> >
> >
>
> --
> 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>.
Look at MXMLClassDirectiveProcessor. You would just make methods like processMXMLInstanceNode() spit out JS source code instead of generating ABC instructions. After all,
<Button label="OK" color="0xFF0000"/>
is just shorthand for
b = new Button();
b.label = "OK";
b.setStyle("color", 0xFF0000);
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apache@teotigraphix.com]
Sent: Friday, November 30, 2012 10:36 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Gordon, can you give me a couple class references to look at?
Can these class directives be overriden for other output type? Is this something that could be applied to the as -> js generation?
Mike
Quoting Gordon Smith <go...@adobe.com>:
> MXML codegen uses a "class directive processor" but not a BURM.
>
> - Gordon
>
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 10:08 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 9:45 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>> A note about MXML, since the parse DOES create and AST during parsing
>> of an MXML file, and MXML uses the IDefinition API, we can catch MXML
>> code at the same intersection we are getting the AS code at, the AST
>> definition stage.
> OK, I wasn't sure where the dividing line is around AST. Yes MXML
> nodes are in the parse tree, but appears to be a different set of
> nodes than what AS generates.
>>
>>>>
>>>> Using the IDefinition API, with loaded SWCs gives you member and
>>>> class resolotuion so I might actually start with that higher level
>>>> and not strictly IASNode parser nodes.
>>> It occurred to me that I think MXML does not go to AS or AST, it
>>> goes straight to ABC, so we'll be customizing that code in some way as well.
>>
>>
>>
>> I doesn't got to straight ABC, it does go to AST then ABC. Everything
>> has to be AST first to then go to JBurg ABC reducer.
> You could be right, but I've been in
> org.apache.flex.compiler.internal.as.codegen.MXMLClassDirectiveProcess
> or. I don't see it using reducers/emitters/JBurg, I see it setting
> instructions directly. But I might be missing something.
>
> --
> 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>.
Gordon, can you give me a couple class references to look at?
Can these class directives be overriden for other output type? Is this
something that could be applied to the as -> js generation?
Mike
Quoting Gordon Smith <go...@adobe.com>:
> MXML codegen uses a "class directive processor" but not a BURM.
>
> - Gordon
>
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 10:08 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 9:45 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>> A note about MXML, since the parse DOES create and AST during parsing
>> of an MXML file, and MXML uses the IDefinition API, we can catch MXML
>> code at the same intersection we are getting the AS code at, the AST
>> definition stage.
> OK, I wasn't sure where the dividing line is around AST. Yes MXML
> nodes are in the parse tree, but appears to be a different set of
> nodes than what AS generates.
>>
>>>>
>>>> Using the IDefinition API, with loaded SWCs gives you member and
>>>> class resolotuion so I might actually start with that higher level
>>>> and not strictly IASNode parser nodes.
>>> It occurred to me that I think MXML does not go to AS or AST, it goes
>>> straight to ABC, so we'll be customizing that code in some way as well.
>>
>>
>>
>> I doesn't got to straight ABC, it does go to AST then ABC. Everything
>> has to be AST first to then go to JBurg ABC reducer.
> You could be right, but I've been in
> org.apache.flex.compiler.internal.as.codegen.MXMLClassDirectiveProcessor. I
> don't see it using reducers/emitters/JBurg, I see it setting
> instructions directly. But I might be missing something.
>
> --
> 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>.
MXML codegen uses a "class directive processor" but not a BURM.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Friday, November 30, 2012 10:08 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 9:45 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> A note about MXML, since the parse DOES create and AST during parsing
> of an MXML file, and MXML uses the IDefinition API, we can catch MXML
> code at the same intersection we are getting the AS code at, the AST
> definition stage.
OK, I wasn't sure where the dividing line is around AST. Yes MXML nodes are in the parse tree, but appears to be a different set of nodes than what AS generates.
>
>>>
>>> Using the IDefinition API, with loaded SWCs gives you member and
>>> class resolotuion so I might actually start with that higher level
>>> and not strictly IASNode parser nodes.
>> It occurred to me that I think MXML does not go to AS or AST, it goes
>> straight to ABC, so we'll be customizing that code in some way as well.
>
>
>
> I doesn't got to straight ABC, it does go to AST then ABC. Everything
> has to be AST first to then go to JBurg ABC reducer.
You could be right, but I've been in
org.apache.flex.compiler.internal.as.codegen.MXMLClassDirectiveProcessor. I don't see it using reducers/emitters/JBurg, I see it setting instructions directly. But I might be missing something.
--
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
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
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 Daniel Wasilewski <de...@gmail.com>.
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
>>
>>
>
Re: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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
>
>
--
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 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
RE: [FlaconJS] pseudo emitter algorithm
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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.
In Alex's new component prototype he is using descriptor object that
translate MXML tags to a JS Array; IE
override public function get uiDescriptors():Array
{
return [
Label,
null,
"lbl",
2,
"x", 100,
"y", 25,
0,
1
}
Mike
> - Gordon
>
> -----Original Message-----
> From: Gordon Smith [mailto:gosmith@adobe.com]
> Sent: Friday, November 30, 2012 10:54 AM
> To: flex-dev@incubator.apache.org
> Subject: RE: [FlaconJS] pseudo emitter algorithm
>
> Before I do much more work on Falcon's MXML, we need to decide
> whether we're completing MXML->ABC or discarding that work.
>
> - Gordon
>
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 10:46 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 10:33 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> My point is, we would create a .js generator for MXML dialect. It
>> "might" even be adeventagious for us to create this implementation
>> becasue we "could" treat some parts of MXML differently than a plain
>> ole ActionScript class.
>>
> Yup, but keep in mind that I'm planning to check in code where MXML
> generates mostly a data structure, and very little code.
>
>
> --
> 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>.
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.
- Gordon
-----Original Message-----
From: Gordon Smith [mailto:gosmith@adobe.com]
Sent: Friday, November 30, 2012 10:54 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Before I do much more work on Falcon's MXML, we need to decide whether we're completing MXML->ABC or discarding that work.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Friday, November 30, 2012 10:46 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 10:33 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> My point is, we would create a .js generator for MXML dialect. It
> "might" even be adeventagious for us to create this implementation
> becasue we "could" treat some parts of MXML differently than a plain
> ole ActionScript class.
>
Yup, but keep in mind that I'm planning to check in code where MXML generates mostly a data structure, and very little code.
--
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 recommend completing MXML->ABC first and later switching over to MXML->datastructure.
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apache@teotigraphix.com]
Sent: Friday, November 30, 2012 10:58 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Quoting Gordon Smith <go...@adobe.com>:
> Before I do much more work on Falcon's MXML, we need to decide whether
> we're completing MXML->ABC or discarding that work.
>
> - Gordon
What are the implications of this? How then do you suggest getting MXML to compile, or a re you saying leave MXML in a model state?
Mike
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 10:46 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 10:33 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> My point is, we would create a .js generator for MXML dialect. It
>> "might" even be adeventagious for us to create this implementation
>> becasue we "could" treat some parts of MXML differently than a plain
>> ole ActionScript class.
>>
> Yup, but keep in mind that I'm planning to check in code where MXML
> generates mostly a data structure, and very little code.
>
>
> --
> 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>.
For FalconJS, I'm fine with Alex pioneering the MXML->datastructure approach, since there is no MXML->JS at all yet.
- Gordon
-----Original Message-----
From: Gordon Smith
Sent: Friday, November 30, 2012 11:01 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
I recommend completing MXML->ABC first and later switching over to MXML->datastructure.
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apache@teotigraphix.com]
Sent: Friday, November 30, 2012 10:58 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Quoting Gordon Smith <go...@adobe.com>:
> Before I do much more work on Falcon's MXML, we need to decide whether
> we're completing MXML->ABC or discarding that work.
>
> - Gordon
What are the implications of this? How then do you suggest getting MXML to compile, or a re you saying leave MXML in a model state?
Mike
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 10:46 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 10:33 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> My point is, we would create a .js generator for MXML dialect. It
>> "might" even be adeventagious for us to create this implementation
>> becasue we "could" treat some parts of MXML differently than a plain
>> ole ActionScript class.
>>
> Yup, but keep in mind that I'm planning to check in code where MXML
> generates mostly a data structure, and very little code.
>
>
> --
> 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>.
Quoting Gordon Smith <go...@adobe.com>:
> Before I do much more work on Falcon's MXML, we need to decide
> whether we're completing MXML->ABC or discarding that work.
>
> - Gordon
What are the implications of this? How then do you suggest getting
MXML to compile, or a re you saying leave MXML in a model state?
Mike
>
> -----Original Message-----
> From: Alex Harui [mailto:aharui@adobe.com]
> Sent: Friday, November 30, 2012 10:46 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> On 11/30/12 10:33 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> My point is, we would create a .js generator for MXML dialect. It
>> "might" even be adeventagious for us to create this implementation
>> becasue we "could" treat some parts of MXML differently than a plain
>> ole ActionScript class.
>>
> Yup, but keep in mind that I'm planning to check in code where MXML
> generates mostly a data structure, and very little code.
>
>
> --
> 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>.
Before I do much more work on Falcon's MXML, we need to decide whether we're completing MXML->ABC or discarding that work.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Friday, November 30, 2012 10:46 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 10:33 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> My point is, we would create a .js generator for MXML dialect. It
> "might" even be adeventagious for us to create this implementation
> becasue we "could" treat some parts of MXML differently than a plain
> ole ActionScript class.
>
Yup, but keep in mind that I'm planning to check in code where MXML generates mostly a data structure, and very little code.
--
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 10:33 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> My point is, we would create a .js generator for MXML dialect. It
> "might" even be adeventagious for us to create this implementation
> becasue we "could" treat some parts of MXML differently than a plain
> ole ActionScript class.
>
Yup, but keep in mind that I'm planning to check in code where MXML
generates mostly a data structure, and very little code.
--
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 9:45 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>> A note about MXML, since the parse DOES create and AST during parsing
>> of an MXML file, and MXML uses the IDefinition API, we can catch MXML
>> code at the same intersection we are getting the AS code at, the AST
>> definition stage.
> OK, I wasn't sure where the dividing line is around AST. Yes MXML nodes are
> in the parse tree, but appears to be a different set of nodes than what AS
> generates.
>>
>>>>
>>>> Using the IDefinition API, with loaded SWCs gives you member and class
>>>> resolotuion so I might actually start with that higher level and not
>>>> strictly IASNode parser nodes.
>>> It occurred to me that I think MXML does not go to AS or AST, it goes
>>> straight to ABC, so we'll be customizing that code in some way as well.
>>
>>
>>
>> I doesn't got to straight ABC, it does go to AST then ABC. Everything
>> has to be AST first to then go to JBurg ABC reducer.
> You could be right, but I've been in
> org.apache.flex.compiler.internal.as.codegen.MXMLClassDirectiveProcessor. I
> don't see it using reducers/emitters/JBurg, I see it setting instructions
> directly. But I might be missing something.
Take the below for instance;
MXMLFileNode(MXMLFileID) ""
MXMLDocumentNode(MXMLDocumentID) "flash.display.Sprite"
MXMLInstanceNode(MXMLInstanceID) "spark.components.Label" id="lbl"
MXMLPropertySpecifierNode(MXMLPropertySpecifierID) "x"
MXMLIntNode(MXMLIntID) "int"
MXMLLiteralNode(MXMLLiteralID) 100
MXMLPropertySpecifierNode(MXMLPropertySpecifierID) "y"
MXMLIntNode(MXMLIntID) "int"
MXMLLiteralNode(MXMLLiteralID) 25
MXMLPropertySpecifierNode(MXMLPropertySpecifierID) "text"
MXMLSingleDataBindingNode(MXMLDataBindingID) "DataBinding"
MemberAccessExpressionNode(MemberAccessExpressionID) "."
IdentifierNode(IdentifierID) "model"
IdentifierNode(IdentifierID) "labelText"
We have access to that tree when parsing. Instead of thinking we have
to parse this INTO ActionScript AST, we can think of this as MXML AST.
My point is, we would create a .js generator for MXML dialect. It
"might" even be adeventagious for us to create this implementation
becasue we "could" treat some parts of MXML differently than a plain
ole ActionScript class.
So we do have the AST at the same exact point we have ActionScript
AST. I was never saying MXML AST was ActionScript. I was saying we
have MXML AST to work with, and working with it's AST by not being
converted to ActionScript could actually be a bonus.
Note: There is nothing different about ActionScript AST when I go to
traverse it's tree. There will a a walker that knows how to traverse
the tree based on .as sematics. The same can happen for .mxml, a
woalker will know it's semantics and walk the tree correctly based on
MXML.
Also note, this is basically what JBurg does and produces. We just
want total control so there dosn't need to be experts on JBurg to fix
bugs with tree walking.
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 9:45 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> A note about MXML, since the parse DOES create and AST during parsing
> of an MXML file, and MXML uses the IDefinition API, we can catch MXML
> code at the same intersection we are getting the AS code at, the AST
> definition stage.
OK, I wasn't sure where the dividing line is around AST. Yes MXML nodes are
in the parse tree, but appears to be a different set of nodes than what AS
generates.
>
>>>
>>> Using the IDefinition API, with loaded SWCs gives you member and class
>>> resolotuion so I might actually start with that higher level and not
>>> strictly IASNode parser nodes.
>> It occurred to me that I think MXML does not go to AS or AST, it goes
>> straight to ABC, so we'll be customizing that code in some way as well.
>
>
>
> I doesn't got to straight ABC, it does go to AST then ABC. Everything
> has to be AST first to then go to JBurg ABC reducer.
You could be right, but I've been in
org.apache.flex.compiler.internal.as.codegen.MXMLClassDirectiveProcessor. I
don't see it using reducers/emitters/JBurg, I see it setting instructions
directly. But I might be missing something.
--
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 8:56 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>>
>> My only question was, were the engineers doing anything specific with
>> resolutions and such with the SWF.
> My guess is that the engineers were just leveraging the file output portion
> of Falcon. I pondered whether having the SWF constant pools around would
> make for tighter code in JS, but I don't think so.
>
>>
>> The fact that jangaroo does it with AST is good enough for me to get
>> going on a prototype. I was just trying to see if there was anything
>> where I am not reinventing the wheel. But I will, if that is the only
>> way to go since the API is externally different then jangaroo.
> So is your plan to rewrite the generator so it doesn't reduce the code to
> SWF entities via JBurg?
I don't know yet. My intuition is telling me I don't have enough facts
right now. Basically I wanted to make something inline with jangaroo's
JSCodeGenerator with the visitor pattern. I have written this type of
ActionScript code generation before, so I am no stranger to it.
My thought is this. If we rewrite the code generation using
AST/Definitions framework it will be 10 times easier to write custom
code generation backends because we will have created a tight and
clean API to do so. IE Java or whatever. This is not saying it's easy
but you would rip out 2 dependencies doing this, SWF and JBurg. This
allows a lot more possible code contributions down the road with those
two monsters out of the pie.
My advice to myself and others is this. Write all the js you want
against how the compiler spits it out right now. If I go the route and
if there are any others that want to join in, we will meet at the same
exact code generation.
Once there is a semi stable implementation using the new generator
that produces the code you want, we can steer the js in a new
direction if needed.
A note about MXML, since the parse DOES create and AST during parsing
of an MXML file, and MXML uses the IDefinition API, we can catch MXML
code at the same intersection we are getting the AS code at, the AST
definition stage.
Actually this might work even better because both .as and.mxml are on
the exact same playing field at this point in the parsing.
The problem that MXML is not converted to ActionScript is mute since
we are using the AST/Definitions... problem solved.
Mike
>>
>> Using the IDefinition API, with loaded SWCs gives you member and class
>> resolotuion so I might actually start with that higher level and not
>> strictly IASNode parser nodes.
> It occurred to me that I think MXML does not go to AS or AST, it goes
> straight to ABC, so we'll be customizing that code in some way as well.
I doesn't got to straight ABC, it does go to AST then ABC. Everything
has to be AST first to then go to JBurg ABC reducer.
Alex, this package is the key *org.apache.flex.compiler.tree.mxml*.
>> 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 8:56 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
> My only question was, were the engineers doing anything specific with
> resolutions and such with the SWF.
My guess is that the engineers were just leveraging the file output portion
of Falcon. I pondered whether having the SWF constant pools around would
make for tighter code in JS, but I don't think so.
>
> The fact that jangaroo does it with AST is good enough for me to get
> going on a prototype. I was just trying to see if there was anything
> where I am not reinventing the wheel. But I will, if that is the only
> way to go since the API is externally different then jangaroo.
So is your plan to rewrite the generator so it doesn't reduce the code to
SWF entities via JBurg?
>
> Using the IDefinition API, with loaded SWCs gives you member and class
> resolotuion so I might actually start with that higher level and not
> strictly IASNode parser nodes.
It occurred to me that I think MXML does not go to AS or AST, it goes
straight to ABC, so we'll be customizing that code in some way as well.
>
> Mike
>
>
--
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>.
Alex,
I have no idea what I am talking about. :)
I have not dealt with enterprise things at all. I'm just a programmer
in the woods so to speak.
I am just trying to clarify things before I head out on an arduous
path of creating some js from AST.
I do agree that there has to be savings by not creating a SWF then
using it to create JS, when in theory you had that AST to begin with
at the start of the compiler's parsing. It seems like the savings
would be at least 1/2. I do think there will need to be analyzers or
some type of middle ground (delegation/analyze) between the parse
stage and generation stage.
My only question was, were the engineers doing anything specific with
resolutions and such with the SWF.
The fact that jangaroo does it with AST is good enough for me to get
going on a prototype. I was just trying to see if there was anything
where I am not reinventing the wheel. But I will, if that is the only
way to go since the API is externally different then jangaroo.
Using the IDefinition API, with loaded SWCs gives you member and class
resolotuion so I might actually start with that higher level and not
strictly IASNode parser nodes.
Mike
Quoting Alex Harui <ah...@adobe.com>:
> You guys have lost me a bit.
>
> IMO, all I want as output is a series of .JS files (that would later get
> minified by GCC for release builds). I don't get how the JSEmitter's
> reliance on SWF output constructs like traits would affect the output.
> Seems like you should be able to generate the same thing from the AST.
> Potentially even faster than having to unravel the MethodInfo/MethodBodyInfo
> constructs.
>
> I also don't see how the fact that Falcon consumes SWCs in order to resolve
> the symbols at compilation time affects the output either. And isn't SWC
> consumption all you really need for modular development? You shouldn't need
> the module binaries, the two projects should be sharing a common interface.
> In my mind, modules are separate .js files loaded at different times. The
> key is if you can minify them without destroying their common interface.
> Someone said you can tune GCC to do that.
>
> Anyway, good point about closed source since all JS is open. But all
> enterprises moving to JS just be dealing with this some way already right?
> Isn't minification about as good as abc code in the SWF? You could always
> dump a SWF and get most of the algorithm back.
>
> Or maybe I'm totally missing what you guys are talking about.
>
> -Alex
>
> On 11/30/12 2:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> Quoting Frank Wienberg <fr...@jangaroo.net>:
>>
>>> On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
>>> <ap...@teotigraphix.com>wrote:
>>>
>>>> For FalconJS this process is totally bound to SWF format.
>>>>
>>>> This was my point. For any developer to fix bugs here they have to know
>>>> the SWF format. Which I don't.
>>>>
>>>> This is why I propsed another solution using pure AST like Jangaroo does.
>>>>
>>>> I am not skilled enough to understand the trade offs currently. But I am
>>>> going to try and see if I can create the same JS code using a different
>>>> algorithm.
>>>>
>>>
>>> I guess the trade off is that the AST approach leads to a different
>>> packaging format. For Jangaroo, we use JARs that contain the generated JS
>>> code as well as generated AS "API stubs" (under META-INF/joo-api), that is
>>> the AS code is reduced to its API, using the "native" keyword. This allows
>>> to compile against other modules without having their source code. However,
>>> the consequence is that you need a different classpath and custom build
>>> tools: we created a Maven plugin that provides a custom packaging type
>>> currently called "jangaroo" that outputs a JAR in the format described
>>> above.
>>> When the output format is SWC/SWF, you more closely resemble Flash/Flex.
>>> But honestly, unless we transform ActionScript byte code into JavaScript
>>> (or interpret it in JavaScript like in Gordon's approach), we cannot use
>>> any "binary" modules, anyway, but instead all modules have to be recompiled
>>> for use with FalconJS, or even worse you need the complete source code for
>>> the whole project, which would increase build time and hinder real modular
>>> development as well as closed source modules--quite a show stopper for an
>>> Enterprise tool!
>>>
>>> -Frank-
>>>
>>
>> Ok, I didn't even think about the recompile. So in my mind, please
>> correct me if I'm wrong, the SWC/SWF probably was chosen because it IS
>> the packaging and organization structure currently. Where you are
>> using a jar as you said. Correct?
>>
>> Since you have so much experience with as->js, what is your opinion on
>> implementation? I'm asking because I might be putting a lot of work
>> into the compiler output and would like to know which direction. Do
>> you see any way of interfacing jangaroo and falcon/falconjs?
>>
>> Do you think offering the straight AST emitter(which would allow
>> granular compiles with native stubs) like yours AND the SWF/SWC option
>> and somehow getting them on the same API is something to consider?
>>
>> As I said earlier, you have some great code, I would love to work
>> together somehow to get a nice application framework our there like
>> Flex ontop of JS and whatever other language we could get to, Android,
>> iOS, whatever.
>>
>> Thanks for all your time Frank!
>>
>> 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>.
You guys have lost me a bit.
IMO, all I want as output is a series of .JS files (that would later get
minified by GCC for release builds). I don't get how the JSEmitter's
reliance on SWF output constructs like traits would affect the output.
Seems like you should be able to generate the same thing from the AST.
Potentially even faster than having to unravel the MethodInfo/MethodBodyInfo
constructs.
I also don't see how the fact that Falcon consumes SWCs in order to resolve
the symbols at compilation time affects the output either. And isn't SWC
consumption all you really need for modular development? You shouldn't need
the module binaries, the two projects should be sharing a common interface.
In my mind, modules are separate .js files loaded at different times. The
key is if you can minify them without destroying their common interface.
Someone said you can tune GCC to do that.
Anyway, good point about closed source since all JS is open. But all
enterprises moving to JS just be dealing with this some way already right?
Isn't minification about as good as abc code in the SWF? You could always
dump a SWF and get most of the algorithm back.
Or maybe I'm totally missing what you guys are talking about.
-Alex
On 11/30/12 2:27 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
>> On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
>> <ap...@teotigraphix.com>wrote:
>>
>>> For FalconJS this process is totally bound to SWF format.
>>>
>>> This was my point. For any developer to fix bugs here they have to know
>>> the SWF format. Which I don't.
>>>
>>> This is why I propsed another solution using pure AST like Jangaroo does.
>>>
>>> I am not skilled enough to understand the trade offs currently. But I am
>>> going to try and see if I can create the same JS code using a different
>>> algorithm.
>>>
>>
>> I guess the trade off is that the AST approach leads to a different
>> packaging format. For Jangaroo, we use JARs that contain the generated JS
>> code as well as generated AS "API stubs" (under META-INF/joo-api), that is
>> the AS code is reduced to its API, using the "native" keyword. This allows
>> to compile against other modules without having their source code. However,
>> the consequence is that you need a different classpath and custom build
>> tools: we created a Maven plugin that provides a custom packaging type
>> currently called "jangaroo" that outputs a JAR in the format described
>> above.
>> When the output format is SWC/SWF, you more closely resemble Flash/Flex.
>> But honestly, unless we transform ActionScript byte code into JavaScript
>> (or interpret it in JavaScript like in Gordon's approach), we cannot use
>> any "binary" modules, anyway, but instead all modules have to be recompiled
>> for use with FalconJS, or even worse you need the complete source code for
>> the whole project, which would increase build time and hinder real modular
>> development as well as closed source modules--quite a show stopper for an
>> Enterprise tool!
>>
>> -Frank-
>>
>
> Ok, I didn't even think about the recompile. So in my mind, please
> correct me if I'm wrong, the SWC/SWF probably was chosen because it IS
> the packaging and organization structure currently. Where you are
> using a jar as you said. Correct?
>
> Since you have so much experience with as->js, what is your opinion on
> implementation? I'm asking because I might be putting a lot of work
> into the compiler output and would like to know which direction. Do
> you see any way of interfacing jangaroo and falcon/falconjs?
>
> Do you think offering the straight AST emitter(which would allow
> granular compiles with native stubs) like yours AND the SWF/SWC option
> and somehow getting them on the same API is something to consider?
>
> As I said earlier, you have some great code, I would love to work
> together somehow to get a nice application framework our there like
> Flex ontop of JS and whatever other language we could get to, Android,
> iOS, whatever.
>
> Thanks for all your time Frank!
>
> Mike
>
>
>
>
>
--
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 Frank Wienberg <fr...@jangaroo.net>:
> On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> For FalconJS this process is totally bound to SWF format.
>>
>> This was my point. For any developer to fix bugs here they have to know
>> the SWF format. Which I don't.
>>
>> This is why I propsed another solution using pure AST like Jangaroo does.
>>
>> I am not skilled enough to understand the trade offs currently. But I am
>> going to try and see if I can create the same JS code using a different
>> algorithm.
>>
>
> I guess the trade off is that the AST approach leads to a different
> packaging format. For Jangaroo, we use JARs that contain the generated JS
> code as well as generated AS "API stubs" (under META-INF/joo-api), that is
> the AS code is reduced to its API, using the "native" keyword. This allows
> to compile against other modules without having their source code. However,
> the consequence is that you need a different classpath and custom build
> tools: we created a Maven plugin that provides a custom packaging type
> currently called "jangaroo" that outputs a JAR in the format described
> above.
> When the output format is SWC/SWF, you more closely resemble Flash/Flex.
> But honestly, unless we transform ActionScript byte code into JavaScript
> (or interpret it in JavaScript like in Gordon's approach), we cannot use
> any "binary" modules, anyway, but instead all modules have to be recompiled
> for use with FalconJS, or even worse you need the complete source code for
> the whole project, which would increase build time and hinder real modular
> development as well as closed source modules--quite a show stopper for an
> Enterprise tool!
>
> -Frank-
>
Ok, I didn't even think about the recompile. So in my mind, please
correct me if I'm wrong, the SWC/SWF probably was chosen because it IS
the packaging and organization structure currently. Where you are
using a jar as you said. Correct?
Since you have so much experience with as->js, what is your opinion on
implementation? I'm asking because I might be putting a lot of work
into the compiler output and would like to know which direction. Do
you see any way of interfacing jangaroo and falcon/falconjs?
Do you think offering the straight AST emitter(which would allow
granular compiles with native stubs) like yours AND the SWF/SWC option
and somehow getting them on the same API is something to consider?
As I said earlier, you have some great code, I would love to work
together somehow to get a nice application framework our there like
Flex ontop of JS and whatever other language we could get to, Android,
iOS, whatever.
Thanks for all your time Frank!
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FlaconJS] pseudo emitter algorithm
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> For FalconJS this process is totally bound to SWF format.
>
> This was my point. For any developer to fix bugs here they have to know
> the SWF format. Which I don't.
>
> This is why I propsed another solution using pure AST like Jangaroo does.
>
> I am not skilled enough to understand the trade offs currently. But I am
> going to try and see if I can create the same JS code using a different
> algorithm.
>
I guess the trade off is that the AST approach leads to a different
packaging format. For Jangaroo, we use JARs that contain the generated JS
code as well as generated AS "API stubs" (under META-INF/joo-api), that is
the AS code is reduced to its API, using the "native" keyword. This allows
to compile against other modules without having their source code. However,
the consequence is that you need a different classpath and custom build
tools: we created a Maven plugin that provides a custom packaging type
currently called "jangaroo" that outputs a JAR in the format described
above.
When the output format is SWC/SWF, you more closely resemble Flash/Flex.
But honestly, unless we transform ActionScript byte code into JavaScript
(or interpret it in JavaScript like in Gordon's approach), we cannot use
any "binary" modules, anyway, but instead all modules have to be recompiled
for use with FalconJS, or even worse you need the complete source code for
the whole project, which would increase build time and hinder real modular
development as well as closed source modules--quite a show stopper for an
Enterprise tool!
-Frank-
Re: [FlaconJS] pseudo emitter algorithm
Posted by Alex Harui <ah...@adobe.com>.
OK, I think I get it now. Sounds like it is worth exploring.
On 11/29/12 10:02 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Quoting Alex Harui <ah...@adobe.com>:
>
>> So if I understand you, the notion of traits is a SWF thing? The AST has
>> different representations maybe like member, variable, function?
>
> Well yes and no.
>
> Traits IS an SWF thing. The AST is represented by like IClassNode,
> IPackageNode etc.
>
> Than we have an even more fun framework in the IDefinition like
> IClassDefinition which basically wraps the INode ast.
>
> We also have the IScopeNode which then blocks our code into the scope chunks.
>
> If we eliminate the SWF traits stuff and use IASNode or IDefinition
> API we would be solid and developers could easily get involved down
> the road.
>
> PS i know there might be things I am over looking but Jangroo uses
> this method, we just have to have some analyzers and such I would
> imagine.
>
> Theoretically using the IDefinition interfaces I could create that
> same MainCode.js output, which I am going to try and to.
>
> The IDefinition API is were you get your supers, resolving classes,
> getting super class members etc.
>
> Mike
>
>
>
>>
>> On 11/29/12 9:42 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>>> Quoting Alex Harui <ah...@adobe.com>:
>>>
>>>> Very nice. Have you figured out the role of the generated CMCEmitter in
>>>> this process?
>>>
>>> Yes,
>>>
>>> The CmcJSEmitter (autogenerated by cmc-js.jbg) is used to traverse the
>>> ISWF that is created.
>>>
>>> The CmcJSEmitter and JSGeneratingReducer are created in the
>>> JSGenerator constructor.
>>>
>>> The actual CmcJSEmitter is used during the
>>> JSClassDirectiveProcessor.delcareVariable() etc. methods.
>>>
>>> Basically the processor is using the emitter to create SWF
>>> instructions that ultimately end up creating class traits. Once the
>>> tratis are created, they just keep getting recursively visited and
>>> more instructions created.
>>>
>>> So it's like
>>>
>>> - JSCompilationUnit.processABCBytesRequest()
>>> - handleABCBytesRequest()
>>> - JSGenerator.generate()
>>> - then see below ....
>>>
>>> When it gets to methods called declarePackage() for instance, block
>>> code instructions are created using the cmc emitter. Traits are then
>>> created based of them.
>>>
>>> For FalconJS this process is totally bound to SWF format.
>>>
>>> This was my point. For any developer to fix bugs here they have to
>>> know the SWF format. Which I don't.
>>>
>>> This is why I propsed another solution using pure AST like Jangaroo does.
>>>
>>> I am not skilled enough to understand the trade offs currently. But I
>>> am going to try and see if I can create the same JS code using a
>>> different algorithm.
>>>
>>> Mike
>>>
>>>
>>>
>>>>
>>>> On 11/29/12 7:30 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> For those asking question about "where to alter" code, it's not pretty
>>>>> but I think I know exactly what is going on now.
>>>>>
>>>>> If you can understand below, you will now have some insight to where
>>>>> and how the JS code actually gets created.
>>>>>
>>>>>
>>>>> ! Call the compiler load config compile().
>>>>>
>>>>>
>>>>> JSGenerator.generate() - creates the package, class, member traits
>>>>>
>>>>> - DirectiveProcessor.processNode(IFileNode)
>>>>> - recusrsivly fill traits
>>>>>
>>>>> -----------------------------------------------------
>>>>>
>>>>> Basically a snippet of the recursion;
>>>>>
>>>>> DirectiveProcessor.processNode(IFileNode)
>>>>> - declarePackage(PackageNode)
>>>>> - emitter.visitPackage(packageName)
>>>>> - data.registerPackage(packageName)
>>>>> - super.declarePackage(PackageNode)
>>>>> - DirectiveProcessor.traverse(p.getScopedNode()) <-
>>>>> ClassNode (class
>>>>> {})
>>>>> - for each ClassNode.getChild(i)
>>>>> - processNode(ScopedBlockNode)
>>>>> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
>>>>> - verifyClassModifiers(ClassNode)
>>>>> - skins
>>>>> - JSClassDirectiveProcessor cp =
>>>>> backend.createClassDirectiveProcessor()
>>>>> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
>>>>> - for each TypeScope.getChild(i)
>>>>> - processNode(TypeScope)
>>>>> -
>>>>> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>>>>>
>>>>>
>>>>> --------------------------------------------------------
>>>>>
>>>>> !!!!
>>>>> JavaScript source code creation after class traits have been traversed
>>>>> and created;
>>>>>
>>>>>
>>>>> JSEmiter.emit()
>>>>> - emitClass(EmitterClassVisitor)
>>>>> - IClassDefinition = getDefinition(ii.name)
>>>>> - write class JSDoc
>>>>>
>>>>>
>>>>>
>>>>> - JSEmitter.emitClass()
>>>>> - Line: 3267 - 3269 is What creates a class
>>>>> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>>>>>
>>>>>
>>>>>
>>>>> - JSEmitter.emitInstanceTraits() is then called to write out the
>>>>> class traits
>>>>> - emitTraits() is then called to do the specific if the closure
>>>>> compiler flag is not set
>>>>> 1. emitCtor() emit constructor
>>>>> - emit comma
>>>>> 2. emit all variables before methods
>>>>> - assembles the code "MainCode.foo"
>>>>> - warns if there is a private namespace collision
>>>>> -
>>>>> 3. emit all methods other than constructor
>>>>> - emit ",\n"
>>>>> - emitMethod()
>>>>> - emitJSDocForMethod()
>>>>> - write("\tget_baz")
>>>>> - write(" : ") <- assignmentOp
>>>>> - write("function(")
>>>>> - emitParameters(methodInfo)
>>>>> - write("baz")
>>>>> - write(")")
>>>>> - if (returnType != null)
>>>>> - write(JSDoc for return type)
>>>>> - if interface method
>>>>> - write(" {};\n")
>>>>> - else
>>>>> - write("\n")
>>>>> - write(" {")
>>>>> - write("\n")
>>>>> - emitMethodBody()
>>>>> ... you get the drift
>>>>> - write(" }")
>>>>>
>>>>> - After all traits are written, control flow goes back to
>>>>> JSEmitter.emitClass() line 3269
>>>>> - write("\n});\n\n") // end class
>>>>> - add _CLASS member to instance
>>>>> - add JSDoc for prototype._CLASS
>>>>> - write("MainCode.prototype._CLASS = MainCode;\n")
>>>>>
>>>>> It will then go onto
>>>>> - emitClassInfo()
>>>>> - emitNamespaceInfo()
>>>>> - emitJSONInfo()
>>>>>
>>>>> if (JSSharedData.JS_FRAMEWORK_NAME)
>>>>> - emitFrameworkInit();
>>>>>
>>>>> It will then finally emit register class
>>>>> - "adobe.classes.MainCode=MainCode;"
>>>>>
>>>>> ---------------
>>>>> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
>>>>> MainCode._FULLNAME="MainCode";
>>>>> MainCode._SUPER=Object;
>>>>> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2
>>>>> ":
>>>>> !0
>>>>> };
>>>>> adobe.classes.MainCode=MainCode;
>>>>> ---------------
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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
>>
>>
--
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>:
> So if I understand you, the notion of traits is a SWF thing? The AST has
> different representations maybe like member, variable, function?
Well yes and no.
Traits IS an SWF thing. The AST is represented by like IClassNode,
IPackageNode etc.
Than we have an even more fun framework in the IDefinition like
IClassDefinition which basically wraps the INode ast.
We also have the IScopeNode which then blocks our code into the scope chunks.
If we eliminate the SWF traits stuff and use IASNode or IDefinition
API we would be solid and developers could easily get involved down
the road.
PS i know there might be things I am over looking but Jangroo uses
this method, we just have to have some analyzers and such I would
imagine.
Theoretically using the IDefinition interfaces I could create that
same MainCode.js output, which I am going to try and to.
The IDefinition API is were you get your supers, resolving classes,
getting super class members etc.
Mike
>
> On 11/29/12 9:42 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>> Very nice. Have you figured out the role of the generated CMCEmitter in
>>> this process?
>>
>> Yes,
>>
>> The CmcJSEmitter (autogenerated by cmc-js.jbg) is used to traverse the
>> ISWF that is created.
>>
>> The CmcJSEmitter and JSGeneratingReducer are created in the
>> JSGenerator constructor.
>>
>> The actual CmcJSEmitter is used during the
>> JSClassDirectiveProcessor.delcareVariable() etc. methods.
>>
>> Basically the processor is using the emitter to create SWF
>> instructions that ultimately end up creating class traits. Once the
>> tratis are created, they just keep getting recursively visited and
>> more instructions created.
>>
>> So it's like
>>
>> - JSCompilationUnit.processABCBytesRequest()
>> - handleABCBytesRequest()
>> - JSGenerator.generate()
>> - then see below ....
>>
>> When it gets to methods called declarePackage() for instance, block
>> code instructions are created using the cmc emitter. Traits are then
>> created based of them.
>>
>> For FalconJS this process is totally bound to SWF format.
>>
>> This was my point. For any developer to fix bugs here they have to
>> know the SWF format. Which I don't.
>>
>> This is why I propsed another solution using pure AST like Jangaroo does.
>>
>> I am not skilled enough to understand the trade offs currently. But I
>> am going to try and see if I can create the same JS code using a
>> different algorithm.
>>
>> Mike
>>
>>
>>
>>>
>>> On 11/29/12 7:30 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> For those asking question about "where to alter" code, it's not pretty
>>>> but I think I know exactly what is going on now.
>>>>
>>>> If you can understand below, you will now have some insight to where
>>>> and how the JS code actually gets created.
>>>>
>>>>
>>>> ! Call the compiler load config compile().
>>>>
>>>>
>>>> JSGenerator.generate() - creates the package, class, member traits
>>>>
>>>> - DirectiveProcessor.processNode(IFileNode)
>>>> - recusrsivly fill traits
>>>>
>>>> -----------------------------------------------------
>>>>
>>>> Basically a snippet of the recursion;
>>>>
>>>> DirectiveProcessor.processNode(IFileNode)
>>>> - declarePackage(PackageNode)
>>>> - emitter.visitPackage(packageName)
>>>> - data.registerPackage(packageName)
>>>> - super.declarePackage(PackageNode)
>>>> - DirectiveProcessor.traverse(p.getScopedNode()) <-
>>>> ClassNode (class
>>>> {})
>>>> - for each ClassNode.getChild(i)
>>>> - processNode(ScopedBlockNode)
>>>> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
>>>> - verifyClassModifiers(ClassNode)
>>>> - skins
>>>> - JSClassDirectiveProcessor cp =
>>>> backend.createClassDirectiveProcessor()
>>>> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
>>>> - for each TypeScope.getChild(i)
>>>> - processNode(TypeScope)
>>>> -
>>>> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>>>>
>>>>
>>>> --------------------------------------------------------
>>>>
>>>> !!!!
>>>> JavaScript source code creation after class traits have been traversed
>>>> and created;
>>>>
>>>>
>>>> JSEmiter.emit()
>>>> - emitClass(EmitterClassVisitor)
>>>> - IClassDefinition = getDefinition(ii.name)
>>>> - write class JSDoc
>>>>
>>>>
>>>>
>>>> - JSEmitter.emitClass()
>>>> - Line: 3267 - 3269 is What creates a class
>>>> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>>>>
>>>>
>>>>
>>>> - JSEmitter.emitInstanceTraits() is then called to write out the
>>>> class traits
>>>> - emitTraits() is then called to do the specific if the closure
>>>> compiler flag is not set
>>>> 1. emitCtor() emit constructor
>>>> - emit comma
>>>> 2. emit all variables before methods
>>>> - assembles the code "MainCode.foo"
>>>> - warns if there is a private namespace collision
>>>> -
>>>> 3. emit all methods other than constructor
>>>> - emit ",\n"
>>>> - emitMethod()
>>>> - emitJSDocForMethod()
>>>> - write("\tget_baz")
>>>> - write(" : ") <- assignmentOp
>>>> - write("function(")
>>>> - emitParameters(methodInfo)
>>>> - write("baz")
>>>> - write(")")
>>>> - if (returnType != null)
>>>> - write(JSDoc for return type)
>>>> - if interface method
>>>> - write(" {};\n")
>>>> - else
>>>> - write("\n")
>>>> - write(" {")
>>>> - write("\n")
>>>> - emitMethodBody()
>>>> ... you get the drift
>>>> - write(" }")
>>>>
>>>> - After all traits are written, control flow goes back to
>>>> JSEmitter.emitClass() line 3269
>>>> - write("\n});\n\n") // end class
>>>> - add _CLASS member to instance
>>>> - add JSDoc for prototype._CLASS
>>>> - write("MainCode.prototype._CLASS = MainCode;\n")
>>>>
>>>> It will then go onto
>>>> - emitClassInfo()
>>>> - emitNamespaceInfo()
>>>> - emitJSONInfo()
>>>>
>>>> if (JSSharedData.JS_FRAMEWORK_NAME)
>>>> - emitFrameworkInit();
>>>>
>>>> It will then finally emit register class
>>>> - "adobe.classes.MainCode=MainCode;"
>>>>
>>>> ---------------
>>>> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
>>>> MainCode._FULLNAME="MainCode";
>>>> MainCode._SUPER=Object;
>>>> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":
>>>> !0
>>>> };
>>>> adobe.classes.MainCode=MainCode;
>>>> ---------------
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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 Alex Harui <ah...@adobe.com>.
So if I understand you, the notion of traits is a SWF thing? The AST has
different representations maybe like member, variable, function?
On 11/29/12 9:42 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Quoting Alex Harui <ah...@adobe.com>:
>
>> Very nice. Have you figured out the role of the generated CMCEmitter in
>> this process?
>
> Yes,
>
> The CmcJSEmitter (autogenerated by cmc-js.jbg) is used to traverse the
> ISWF that is created.
>
> The CmcJSEmitter and JSGeneratingReducer are created in the
> JSGenerator constructor.
>
> The actual CmcJSEmitter is used during the
> JSClassDirectiveProcessor.delcareVariable() etc. methods.
>
> Basically the processor is using the emitter to create SWF
> instructions that ultimately end up creating class traits. Once the
> tratis are created, they just keep getting recursively visited and
> more instructions created.
>
> So it's like
>
> - JSCompilationUnit.processABCBytesRequest()
> - handleABCBytesRequest()
> - JSGenerator.generate()
> - then see below ....
>
> When it gets to methods called declarePackage() for instance, block
> code instructions are created using the cmc emitter. Traits are then
> created based of them.
>
> For FalconJS this process is totally bound to SWF format.
>
> This was my point. For any developer to fix bugs here they have to
> know the SWF format. Which I don't.
>
> This is why I propsed another solution using pure AST like Jangaroo does.
>
> I am not skilled enough to understand the trade offs currently. But I
> am going to try and see if I can create the same JS code using a
> different algorithm.
>
> Mike
>
>
>
>>
>> On 11/29/12 7:30 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>>> Hi,
>>>
>>> For those asking question about "where to alter" code, it's not pretty
>>> but I think I know exactly what is going on now.
>>>
>>> If you can understand below, you will now have some insight to where
>>> and how the JS code actually gets created.
>>>
>>>
>>> ! Call the compiler load config compile().
>>>
>>>
>>> JSGenerator.generate() - creates the package, class, member traits
>>>
>>> - DirectiveProcessor.processNode(IFileNode)
>>> - recusrsivly fill traits
>>>
>>> -----------------------------------------------------
>>>
>>> Basically a snippet of the recursion;
>>>
>>> DirectiveProcessor.processNode(IFileNode)
>>> - declarePackage(PackageNode)
>>> - emitter.visitPackage(packageName)
>>> - data.registerPackage(packageName)
>>> - super.declarePackage(PackageNode)
>>> - DirectiveProcessor.traverse(p.getScopedNode()) <- ClassNode (class
>>> {})
>>> - for each ClassNode.getChild(i)
>>> - processNode(ScopedBlockNode)
>>> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
>>> - verifyClassModifiers(ClassNode)
>>> - skins
>>> - JSClassDirectiveProcessor cp =
>>> backend.createClassDirectiveProcessor()
>>> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
>>> - for each TypeScope.getChild(i)
>>> - processNode(TypeScope)
>>> -
>>> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>>>
>>>
>>> --------------------------------------------------------
>>>
>>> !!!!
>>> JavaScript source code creation after class traits have been traversed
>>> and created;
>>>
>>>
>>> JSEmiter.emit()
>>> - emitClass(EmitterClassVisitor)
>>> - IClassDefinition = getDefinition(ii.name)
>>> - write class JSDoc
>>>
>>>
>>>
>>> - JSEmitter.emitClass()
>>> - Line: 3267 - 3269 is What creates a class
>>> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>>>
>>>
>>>
>>> - JSEmitter.emitInstanceTraits() is then called to write out the
>>> class traits
>>> - emitTraits() is then called to do the specific if the closure
>>> compiler flag is not set
>>> 1. emitCtor() emit constructor
>>> - emit comma
>>> 2. emit all variables before methods
>>> - assembles the code "MainCode.foo"
>>> - warns if there is a private namespace collision
>>> -
>>> 3. emit all methods other than constructor
>>> - emit ",\n"
>>> - emitMethod()
>>> - emitJSDocForMethod()
>>> - write("\tget_baz")
>>> - write(" : ") <- assignmentOp
>>> - write("function(")
>>> - emitParameters(methodInfo)
>>> - write("baz")
>>> - write(")")
>>> - if (returnType != null)
>>> - write(JSDoc for return type)
>>> - if interface method
>>> - write(" {};\n")
>>> - else
>>> - write("\n")
>>> - write(" {")
>>> - write("\n")
>>> - emitMethodBody()
>>> ... you get the drift
>>> - write(" }")
>>>
>>> - After all traits are written, control flow goes back to
>>> JSEmitter.emitClass() line 3269
>>> - write("\n});\n\n") // end class
>>> - add _CLASS member to instance
>>> - add JSDoc for prototype._CLASS
>>> - write("MainCode.prototype._CLASS = MainCode;\n")
>>>
>>> It will then go onto
>>> - emitClassInfo()
>>> - emitNamespaceInfo()
>>> - emitJSONInfo()
>>>
>>> if (JSSharedData.JS_FRAMEWORK_NAME)
>>> - emitFrameworkInit();
>>>
>>> It will then finally emit register class
>>> - "adobe.classes.MainCode=MainCode;"
>>>
>>> ---------------
>>> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
>>> MainCode._FULLNAME="MainCode";
>>> MainCode._SUPER=Object;
>>> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":
>>> !0
>>> };
>>> adobe.classes.MainCode=MainCode;
>>> ---------------
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>
>> --
>> 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>.
Quoting Alex Harui <ah...@adobe.com>:
> Very nice. Have you figured out the role of the generated CMCEmitter in
> this process?
Yes,
The CmcJSEmitter (autogenerated by cmc-js.jbg) is used to traverse the
ISWF that is created.
The CmcJSEmitter and JSGeneratingReducer are created in the
JSGenerator constructor.
The actual CmcJSEmitter is used during the
JSClassDirectiveProcessor.delcareVariable() etc. methods.
Basically the processor is using the emitter to create SWF
instructions that ultimately end up creating class traits. Once the
tratis are created, they just keep getting recursively visited and
more instructions created.
So it's like
- JSCompilationUnit.processABCBytesRequest()
- handleABCBytesRequest()
- JSGenerator.generate()
- then see below ....
When it gets to methods called declarePackage() for instance, block
code instructions are created using the cmc emitter. Traits are then
created based of them.
For FalconJS this process is totally bound to SWF format.
This was my point. For any developer to fix bugs here they have to
know the SWF format. Which I don't.
This is why I propsed another solution using pure AST like Jangaroo does.
I am not skilled enough to understand the trade offs currently. But I
am going to try and see if I can create the same JS code using a
different algorithm.
Mike
>
> On 11/29/12 7:30 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> Hi,
>>
>> For those asking question about "where to alter" code, it's not pretty
>> but I think I know exactly what is going on now.
>>
>> If you can understand below, you will now have some insight to where
>> and how the JS code actually gets created.
>>
>>
>> ! Call the compiler load config compile().
>>
>>
>> JSGenerator.generate() - creates the package, class, member traits
>>
>> - DirectiveProcessor.processNode(IFileNode)
>> - recusrsivly fill traits
>>
>> -----------------------------------------------------
>>
>> Basically a snippet of the recursion;
>>
>> DirectiveProcessor.processNode(IFileNode)
>> - declarePackage(PackageNode)
>> - emitter.visitPackage(packageName)
>> - data.registerPackage(packageName)
>> - super.declarePackage(PackageNode)
>> - DirectiveProcessor.traverse(p.getScopedNode()) <- ClassNode (class
>> {})
>> - for each ClassNode.getChild(i)
>> - processNode(ScopedBlockNode)
>> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
>> - verifyClassModifiers(ClassNode)
>> - skins
>> - JSClassDirectiveProcessor cp =
>> backend.createClassDirectiveProcessor()
>> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
>> - for each TypeScope.getChild(i)
>> - processNode(TypeScope)
>> -
>> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>>
>>
>> --------------------------------------------------------
>>
>> !!!!
>> JavaScript source code creation after class traits have been traversed
>> and created;
>>
>>
>> JSEmiter.emit()
>> - emitClass(EmitterClassVisitor)
>> - IClassDefinition = getDefinition(ii.name)
>> - write class JSDoc
>>
>>
>>
>> - JSEmitter.emitClass()
>> - Line: 3267 - 3269 is What creates a class
>> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>>
>>
>>
>> - JSEmitter.emitInstanceTraits() is then called to write out the
>> class traits
>> - emitTraits() is then called to do the specific if the closure
>> compiler flag is not set
>> 1. emitCtor() emit constructor
>> - emit comma
>> 2. emit all variables before methods
>> - assembles the code "MainCode.foo"
>> - warns if there is a private namespace collision
>> -
>> 3. emit all methods other than constructor
>> - emit ",\n"
>> - emitMethod()
>> - emitJSDocForMethod()
>> - write("\tget_baz")
>> - write(" : ") <- assignmentOp
>> - write("function(")
>> - emitParameters(methodInfo)
>> - write("baz")
>> - write(")")
>> - if (returnType != null)
>> - write(JSDoc for return type)
>> - if interface method
>> - write(" {};\n")
>> - else
>> - write("\n")
>> - write(" {")
>> - write("\n")
>> - emitMethodBody()
>> ... you get the drift
>> - write(" }")
>>
>> - After all traits are written, control flow goes back to
>> JSEmitter.emitClass() line 3269
>> - write("\n});\n\n") // end class
>> - add _CLASS member to instance
>> - add JSDoc for prototype._CLASS
>> - write("MainCode.prototype._CLASS = MainCode;\n")
>>
>> It will then go onto
>> - emitClassInfo()
>> - emitNamespaceInfo()
>> - emitJSONInfo()
>>
>> if (JSSharedData.JS_FRAMEWORK_NAME)
>> - emitFrameworkInit();
>>
>> It will then finally emit register class
>> - "adobe.classes.MainCode=MainCode;"
>>
>> ---------------
>> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
>> MainCode._FULLNAME="MainCode";
>> MainCode._SUPER=Object;
>> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":!0
>> };
>> adobe.classes.MainCode=MainCode;
>> ---------------
>>
>> 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>.
Very nice. Have you figured out the role of the generated CMCEmitter in
this process?
On 11/29/12 7:30 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Hi,
>
> For those asking question about "where to alter" code, it's not pretty
> but I think I know exactly what is going on now.
>
> If you can understand below, you will now have some insight to where
> and how the JS code actually gets created.
>
>
> ! Call the compiler load config compile().
>
>
> JSGenerator.generate() - creates the package, class, member traits
>
> - DirectiveProcessor.processNode(IFileNode)
> - recusrsivly fill traits
>
> -----------------------------------------------------
>
> Basically a snippet of the recursion;
>
> DirectiveProcessor.processNode(IFileNode)
> - declarePackage(PackageNode)
> - emitter.visitPackage(packageName)
> - data.registerPackage(packageName)
> - super.declarePackage(PackageNode)
> - DirectiveProcessor.traverse(p.getScopedNode()) <- ClassNode (class
> {})
> - for each ClassNode.getChild(i)
> - processNode(ScopedBlockNode)
> - JSGlobalDirectiveProcessor.declareClass(ClassNode)
> - verifyClassModifiers(ClassNode)
> - skins
> - JSClassDirectiveProcessor cp =
> backend.createClassDirectiveProcessor()
> - cp.traverse(ClassNode.getScopedNode()) <- TypeScope
> - for each TypeScope.getChild(i)
> - processNode(TypeScope)
> -
> JSGlobalDirectiveProcessor.declareFunction(FunctionNode)
>
>
> --------------------------------------------------------
>
> !!!!
> JavaScript source code creation after class traits have been traversed
> and created;
>
>
> JSEmiter.emit()
> - emitClass(EmitterClassVisitor)
> - IClassDefinition = getDefinition(ii.name)
> - write class JSDoc
>
>
>
> - JSEmitter.emitClass()
> - Line: 3267 - 3269 is What creates a class
> - "MainCode=adobe.extend("MainCode",Object,{ ... });"
>
>
>
> - JSEmitter.emitInstanceTraits() is then called to write out the class traits
> - emitTraits() is then called to do the specific if the closure
> compiler flag is not set
> 1. emitCtor() emit constructor
> - emit comma
> 2. emit all variables before methods
> - assembles the code "MainCode.foo"
> - warns if there is a private namespace collision
> -
> 3. emit all methods other than constructor
> - emit ",\n"
> - emitMethod()
> - emitJSDocForMethod()
> - write("\tget_baz")
> - write(" : ") <- assignmentOp
> - write("function(")
> - emitParameters(methodInfo)
> - write("baz")
> - write(")")
> - if (returnType != null)
> - write(JSDoc for return type)
> - if interface method
> - write(" {};\n")
> - else
> - write("\n")
> - write(" {")
> - write("\n")
> - emitMethodBody()
> ... you get the drift
> - write(" }")
>
> - After all traits are written, control flow goes back to
> JSEmitter.emitClass() line 3269
> - write("\n});\n\n") // end class
> - add _CLASS member to instance
> - add JSDoc for prototype._CLASS
> - write("MainCode.prototype._CLASS = MainCode;\n")
>
> It will then go onto
> - emitClassInfo()
> - emitNamespaceInfo()
> - emitJSONInfo()
>
> if (JSSharedData.JS_FRAMEWORK_NAME)
> - emitFrameworkInit();
>
> It will then finally emit register class
> - "adobe.classes.MainCode=MainCode;"
>
> ---------------
> MainCode._PACKAGE=adobe.globals;MainCode._NAME="MainCode";
> MainCode._FULLNAME="MainCode";
> MainCode._SUPER=Object;
> MainCode._NAMESPACES={"foo::2":!0,"bar::7:MainCode":!0,"baz::2":!0,"baz::2":!0
> };
> adobe.classes.MainCode=MainCode;
> ---------------
>
> Mike
>
>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui