Quoting Alex Harui <aha...@adobe.com>:
On 12/29/12 8:52 AM, "Michael Schmalle" <apa...@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.
So yeah, I can see where I could implement the same strategy now and
get the string source production in the multple spawned threads.
What confused me in the beginning was the loop using the JSWriter,
that is single threaded. What it's going is looping through each
compilation unit, taking the ABC bytes which are ACTUALLY String bytes
(created in the buildAndCollectProblems() of the JSTarget) and then
writing them to disk synchronously.
There is obviously a need for tooling that requires access to the AST
in the middle of a compile. We CAN do this since all requests are
async, just because we want to compile async first, adjust AST or
analyze, update compilation units or projects, dosn't mean we could
then go and call handleABCRequest async after all that is done.
It's important to note that all the;
- handleABCBytesRequest()
- handleFileScopeRequest()
- handleOutgoingDependenciesRequest()
- handleSWFTagsRequest()
- handleSyntaxTreeRequest()
Can all be called at different times. That is why they abstract the
the ITarget because different targets (SWC, SWF, JS etc.) need to
execute these requests in different orders.
I'm not talking about messing around with how SWF production works
either right now. Experiementing with this stuff in the JS cross
compiler will show results and if people want to adjust the SWF
compiler to allow the compiler hooks we will have positivly figured
out where it's safe to add them.
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
