flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Fri, 30 Nov 2012 16:56:08 GMT

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.


Quoting Alex Harui <aharui@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" <apache@teotigraphix.com> wrote:
>> Quoting Frank Wienberg <frank@jangaroo.net>:
>>> On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
>>> <apache@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

View raw message