incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: Writable AST and Code generation for Falcon was: [Re: [jira] [Commented] (FLEX-33330) ... )
Date Sun, 30 Dec 2012 17:45:20 GMT

Quoting Alex Harui <aharui@adobe.com>:

>
>
>
> On 12/30/12 4:57 AM, "Michael Schmalle" <apache@teotigraphix.com> wrote:
>
>>
>> Quoting Alex Harui <aharui@adobe.com>:
>>
>>>
>>>
>>>
>>> On 12/29/12 8:52 AM, "Michael Schmalle" <apache@teotigraphix.com> wrote:
>>>
>>>> I know when I wrote ASDoc, I was able to resolve everything but I used
>>>> the MXML compiler as a base. I just need to really understand what is
>>>> going on now. I takled the multithreading in FalconJx, but when I
>>>> debug, the multithreading is over after;
>>>>
>>>>
>>>>                  final File outputFolder = new  
>>>> File(outputFile.getParent());
>>>>                  List<ICompilationUnit> reachableCompilationUnits 

>>>> = project
>>>>
>>>> .getReachableCompilationUnitsInSWFOrder(ImmutableSet
>>>>                                  .of(mainCU));
>>>>
>>>> Once this returns I swear it's synced back on 1 thread. After that
>>>> call I loop through all reachable units and produce .js files for each.
>>> Interesting.  I agree by the time you get here we're back on one thread.
>>> But I'm pretty sure the reducers and emitters have been called at least for
>>> some threads by then.
>>>
>>> I hadn't noticed that was when you were starting your tree walk for
>>> FalconJx.  I thought you were walking in response to the abcbytes request,
>>> but I'm pretty sure when I'm debugging FalconJS, that happens while many
>>> threads are spinning.
>>
>> Yes, this is true. I spent 2 hours on this now and have figured it out.
>>
>> Really, I think there are multiple ways you can implement things here.
>> With the current FalconJS they utilized the existing production
>> framework.
>>
>> Honestly, the way I first did it, I don't see a real problem with it
>> other than not using the multiple threads to create the actual
>> javascript source code (String) like I am doing.

> Yes, I agree you will get correct output by waiting until the threads are
> done, but then are you going to create degenerate reducers/emitters so you
> don't spend time creating ABC instruction lists which is what the threads
> seem to be doing?  Otherwise, you will be inefficient by whatever time is
> spent generating ABC.
>

> create degenerate reducers/emitters

What does this mean?

In FalconJx there is no ABC generation whatsoever. I use the AST and  
FileNode requests; nothing else. So I am parsing and creating the file  
scopes in multiple threads. After all compilation units have their  
file scopes created, I loop through them synchronously to create the  
.js code and save it to disk.

I see being able to alter AST right after this stage. I also see that  
it might just be possible to put the compiler back into multithreaded  
mode to do the below .js source code generation.

The walker is a top down traverse that visits each nod with an emitter  
that saves it's output to a buffer writer. Once walking the FileNode  
is complete, the buffer is flushed to the relevant .js file. Then the  
next compilation unit is processed in the same fashion.

Does this make sense?

PS I was only looking at FalconJS to see what algorithms they were  
using, like I said I ditched ABC for a straight top down traverse and  
emittion strategy.

> --
> 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


Mime
View raw message