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: [FlexJS] Testing AS -> JS translation
Date Mon, 17 Dec 2012 18:57:43 GMT

Quoting Erik de Bruin <erik@ixsoftware.nl>:

> Mike,
>
> I try to talk about FalconJx, as I believe you call your "version" of
> the AS -> JS compiler when I talk about your work.

Ok, I understand. I'm trying to stay away from the phrase of "my way".  
I just see it as an alternative that I understand. Which means I can  
actually develop it.

I refer to FlexJS
> when I talk about the project to allow the user to write in an AS
> based framework (either based on Alex's approach or a new one, based
> on my experiences setting this up).
>
> Am I correct in assuming that the FalconJx compiler will take any AS
> files and translate it to JS using the rules we're working on in the
> Wiki?

Word, that is exactly what it does. Not to mention it will also  
generate valid AS3 code from the AST as well. I'm actually writing it  
against AS3 code generation first because it is the way I see getting  
to most precise and comprehensive tests. Once it generates AS3 and is  
tested, we override what we need for JS emitters and test that  
separately.


I mean, I can build a framework in AS (like Alex's, or maybe
> even use Flex itself) and build a complimentary framework in JS (like
> Alex did) and as long as the functionalities of these frameworks
> match, the user code can be put through FalconJx and the output should
> run, correct? How about MXML?

Yes, that is correct. I am doing no black majic here. We are just  
setting the foundation and rules for the language translations. Like I  
said, having the compiler be able to spit out compilable AS3 code  
first means the JS translation and how solid the compiler will be  
increases a bunch in my opinion.

I know, maybe others would just jump straight to JS output but, not  
me. I have to much experience to know that a thorough foundation will  
allow us to hit lightspeed down the road. Besides, I have the time  
right now to do this right IMHO.

Mike


> EdB
>
>
>
> On Mon, Dec 17, 2012 at 7:21 PM, Michael Schmalle
> <apache@teotigraphix.com> wrote:
>> That's a bit up in the air right now I think.
>>
>> The way I'm writing tests is AS -> JS google closure. But I'm right in the
>> middle of refactoring the emitter classes.
>>
>> The tests I'm writing can be run from ant or whatever, just like the Falcon
>> tests. I just haven't made a build file yet.
>>
>> Have you looked at the source code for FalconJx and it's tests?
>>
>> We don't want to duplicate work but I need to write these tests first. All I
>> know is, once I get these emitters refactored, the JS output is going to be
>> what the closure compiler wants. So we could just write an extension in the
>> assertOut() method that maybe could tests with Jasmine as well? I don't know
>> I have never used Jasmine testing.
>>
>> PS, my days with FalconJS are numbered, I've decided it's to complicated for
>> what I see a relatively simple solution for just getting plain JS, so I
>> probably won't be working on that code base at all, I think Alex is doing
>> something with the code.
>>
>> Mike
>>
>>
>> Quoting Erik de Bruin <erik@ixsoftware.nl>:
>>
>>> Hi,
>>>
>>> I'm trying to figure out how to build tests for the AS to JS cross
>>> compilation.
>>>
>>> Should we write AS "strings" and have a script put those through the
>>> FalconJS/FalconJx compiler and compare the result with a pre-defined
>>> "intermediate JS" result? If so, what would be the best tool to write
>>> those tests in? Ant? Shell script? Something else?
>>>
>>> I'll be writing the JS tests in Jasmine (mainly because that's what I
>>> know), to test the result from putting the FalconJx output through the
>>> Google Closure Compiler and later on the Closure Builder.
>>>
>>> Preferably we would be able to integrate both test suites, so we can
>>> test AS -> "final JS" in one go.
>>>
>>> Thoughts?
>>>
>>> EdB
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>
>> --
>> 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
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com


Mime
View raw message