You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Martin Heidegger <mh...@leichtgewicht.at> on 2012/04/16 03:05:29 UTC
[RT] MXMLC tests & future was: MXMLC now in trunk
I have spent some time reading through the Compiler(s) and I have now
stopped wondering why ASdoc (for one) is so slow. Anyways: trying to
make the compiler "better" seems almost impossible without tests. But
then also: It is my understanding that the compiler lacks layers that
would allow to test just "parts" of the compiler which in turn means: We
needed to test all of the MXMLC for a acceptable reliability. For the
unit tests I guess we will be finished with that task by the time Falcon
arrives or even a few months later - depending on our efforts and
without unit tests I do not feel comfortable deploying any changes to
the public even if Gorden Smith mentioned that the framework tests
should cover some parts: not all of them for certain! So here is my
basic question: Are the current compilers a "dead-birth" In other words:
One time release and never touch and wait for Falcon? I want to engage
in it but there seems hardly a good strategy for that. I am looking for
advice how to get going.
@Michael Labriola mentioned that he wants to build acceptance test if
you are up for a pair session I am willing to join over the net.
Acceptance tests should work for Falcon too, right?
yours
Martin.
On 12/04/2012 03:04, Alex Harui wrote:
> Infra was kind enough to import it last night. I’m still verifying it, but so far, it looks good. Feel free to take a look. I think the next step is to move a few files from Carol’ whiteboard and see if it will build.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [RT] MXMLC tests & future was: MXMLC now in trunk
Posted by Alex Harui <ah...@adobe.com>.
On 4/16/12 8:26 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
>
> @Alex No chance to get the unit tests? ;)
I found some tests, but I am under the impression that they may not be
sufficient. With Gordon saying that it is reasonable to test by checking
output SWFs, I have made looking into it a lower priority than Mustella.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [RT] MXMLC tests & future was: MXMLC now in trunk
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 16/04/2012 16:40, Left Right wrote:
>>
>> swfxprinter.java is in the donation and converts ABC code to text.
>> Something like it could be used to do analysis.
>>
>> I believe Martin meant something like a tool that mechanically proves that
> the generated bytecode is not erroneous. For example, if you have a....
Actually the ABC is not enough because bitmaps, fonts etc. have to be
tested too. It is really
about all the Bytecode. swfxprinter could help making tests more
readable though.
I think it would be reasonable to categorize the tests in:
- API (all the effects of the compiler switches)
- Code Structure (are all the constructs defined in AS3 available in the
swf/output)
- Code Quality (does the bytecode work properly, does it generate code
that results in memory leaks, is it fast, etc.)
Code structure tests are easiest implemented just using a flash player
and "describeType". Some parts of
code quality can be tested using AS3 - but performance has to be tested
with bytecode analysis. The API is best
tested in Java but then again: The API is not really well defined at the
moment.
@Alex No chance to get the unit tests? ;)
yous
Martin.
Re: [RT] MXMLC tests & future was: MXMLC now in trunk
Posted by Left Right <ol...@gmail.com>.
>
>
> swfxprinter.java is in the donation and converts ABC code to text.
> Something like it could be used to do analysis.
>
> I believe Martin meant something like a tool that mechanically proves that
the generated bytecode is not erroneous. For example, if you have a
conditional branch you want to check that after conditional branch joins
back the execution routine all attempts to read / write from / to registers
address the same (or same kind of) values. There are of course plenty of
checks. Some (like this one) the compiler must do - it's a basic sanity
check, but some more complex, the compiler doesn't do (for example, it is
possible to analyze whether you are trying to read from a register
containing null pointer) etc. These checks are usually very expensive in
terms of performance, but I don't see why / how SWF execution must be
involved, it's actually better if it's not involved, because some problems
aren't possible to solve by a increasing the number of tests - they will
tend to be infinite or just too many.
Best.
Oleg
Re: [RT] MXMLC tests & future was: MXMLC now in trunk
Posted by Alex Harui <ah...@adobe.com>.
On 4/15/12 9:56 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> On 16/04/2012 13:21, Alex Harui wrote:
>> I wouldn't say "never touch". There is probably a bug or two worth fixing.
>> But I would save any major changes for Falcon.
>
> Well, I would. Have seen too many "features" that resulted in more bugs.
> Hardly any functionality
> that never breaks anything.
I would save "feature" work for Falcon. But I can imagine there are bug
fixes worth taking.
>
>> The proper way to test the compiler is out of my area of expertise.
>
> Is it so different from other code? Test the public API if it does whats
> its supposed to :)
And that's why it is out of my area. Is the public API of a compiler its
command-line options? Or the public API of classes in the jars?
>
>> I would think that one way would be to code up a set of SWFs and see if they
>> continue to output correctly. Such a thing would be useful for Falcon as
>> well.
> Hmm... sounds like bytecode analysis best written in a language that
> supports threading. Using the FlashPlayer for that will be terribly
> slow. Sounds like fun.
swfxprinter.java is in the donation and converts ABC code to text.
Something like it could be used to do analysis.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [RT] MXMLC tests & future was: MXMLC now in trunk
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 16/04/2012 13:21, Alex Harui wrote:
> I wouldn't say "never touch". There is probably a bug or two worth fixing.
> But I would save any major changes for Falcon.
Well, I would. Have seen too many "features" that resulted in more bugs.
Hardly any functionality
that never breaks anything.
> The proper way to test the compiler is out of my area of expertise.
Is it so different from other code? Test the public API if it does whats
its supposed to :)
Fortunately most classes are public...
> I would think that one way would be to code up a set of SWFs and see if they
> continue to output correctly. Such a thing would be useful for Falcon as
> well.
Hmm... sounds like bytecode analysis best written in a language that
supports threading. Using the FlashPlayer for that will be terribly
slow. Sounds like fun.
yours
Martin.
Re: [RT] MXMLC tests & future was: MXMLC now in trunk
Posted by Alex Harui <ah...@adobe.com>.
On 4/15/12 6:05 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> Are the current compilers a "dead-birth" In other words:
> One time release and never touch and wait for Falcon?
I wouldn't say "never touch". There is probably a bug or two worth fixing.
But I would save any major changes for Falcon.
>
> @Michael Labriola mentioned that he wants to build acceptance test if
> you are up for a pair session I am willing to join over the net.
> Acceptance tests should work for Falcon too, right?
The proper way to test the compiler is out of my area of expertise. I would
think that one way would be to code up a set of SWFs and see if they
continue to output correctly. Such a thing would be useful for Falcon as
well.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui