Add float/float4 tests in the acceptance testsuite



7 years ago
7 years ago


(Reporter: virgilp, Unassigned)


(Blocks: 2 bugs)

Q2 12 - Cyril
Dependency tree / graph
Bug Flags:
in-testsuite +
flashplayer-injection -
flashplayer-qrb +
flashplayer-bug -
flashplayer-triage +


(Whiteboard: Tracking)


(2 attachments)



7 years ago
Acceptance tests for float and Vector.<float>


7 years ago
Blocks: 615489

Comment 1

7 years ago
Created attachment 532979 [details] [diff] [review]
acceptance tests for float support

Draft2 spec only, right now


7 years ago
Assignee: nobody → virgilp
Blocks: 613140
Flags: flashplayer-qrb+
Flags: flashplayer-injection-
Flags: flashplayer-bug-
QA Contact: vm → dschaffe
Target Milestone: --- → Q2 12 - Cyril


7 years ago
Severity: normal → enhancement
Flags: flashplayer-triage+
QA Contact: dschaffe → brbaker


7 years ago
Flags: in-testsuite+
Summary: Add float tests in the acceptance testsuite → Add float/float4 tests in the acceptance testsuite


7 years ago
Assignee: virgilp → nobody
Priority: -- → P3
Whiteboard: Tracking

Comment 2

7 years ago
Created attachment 576539 [details] [diff] [review]
WIP: float operators

lhansen: Based on some whiteboard sketching we did while in Waltham, this is a work in progress of trying to get a base set of testcases that can then be reused in various scenarios such as global functions, package level and class methods. Before I go much further with this I just wanted to get some quick feedback on whether or not this is what you were thinking of.

I had also started working on doing this with an interface but quickly bumped into the issue that the interface must be defined in the public namespace and implemented in the public namespace, which would mean that the include file would then not function outside of a class wrapper.

IF we added a <testname>.regexp file handler to the we COULD do some preprocessing on the source file prior to compiling. This would then allow us to do things such as:

function foo() --> public function foo()
function foo() --> static function foo()

Or any other manipulation of the file you wanted to do. While this would be pretty powerful it would not be as easy to compile the variations outside of using just a thought
Attachment #576539 - Flags: feedback?(lhansen)

Comment 3

7 years ago
Comment on attachment 576539 [details] [diff] [review]
WIP: float operators

Nice.  This will test a ton of combinations.

Another combination is of course one ("Unbound") where early binding in the JIT is not possible because the top-level variable is created dynamically by an assignment to an unbound name.  And yet other cases where there are multiple namespaces open and the variable is in one of them.

BTW each of the driver files should probably have a short comment about what it tests / what distinguishes it from other cases, since that can be hard to see at first glance.

Perhaps even better: For asmicro and jsmicro I've insisted that the test cases be self-identifying, all must contain a single-line descriptor:

var DESC = "...";

which can be used by the test case; it is additionally well-defined to grep test case directories for "var DESC" and then see what tests we have.  See the README files in those directories.
Attachment #576539 - Flags: feedback?(lhansen) → feedback+

Comment 4

7 years ago
Comment on attachment 576539 [details] [diff] [review]
WIP: float operators

Pushed as:

changeset:   6993:f89bc4f5078f
tag:         tip
user:        Brent Baker <>
date:        Wed Nov 30 06:19:01 2011 -0500
summary:     Bug 657330: initial checkin of including float operator functions at various levels of code, class, toplevel, package. There is more to come but this is the foundation that the rest will be based on

Open items:
1) unbound: assignment to a toplevel variable that is dynamically created, will not compile with strict mode
2) multiple namespaces: multiple open namespaces and the var that is being assigned is only in one namespace
3) qualified namespaces: assignment to a qualified namespace


7 years ago
Priority: P3 → --
You need to log in before you can comment on or make changes to this bug.