Closed Bug 657330 Opened 14 years ago Closed 6 years ago

Add float/float4 tests in the acceptance testsuite

Categories

(Tamarin Graveyard :: Virtual Machine, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Q2 12 - Cyril

People

(Reporter: virgilp, Unassigned)

References

Details

(Whiteboard: Tracking)

Attachments

(2 files)

Acceptance tests for float and Vector.<float>
Draft2 spec only, right now
Assignee: nobody → virgilp
Blocks: float/float4
Flags: flashplayer-qrb+
Flags: flashplayer-injection-
Flags: flashplayer-bug-
QA Contact: vm → dschaffe
Target Milestone: --- → Q2 12 - Cyril
Severity: normal → enhancement
Flags: flashplayer-triage+
QA Contact: dschaffe → brbaker
Flags: in-testsuite+
Summary: Add float tests in the acceptance testsuite → Add float/float4 tests in the acceptance testsuite
Assignee: virgilp → nobody
Priority: -- → P3
Whiteboard: Tracking
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 runtest.py 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 runtests.py... just a thought
Attachment #576539 - Flags: feedback?(lhansen)
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 on attachment 576539 [details] [diff] [review] WIP: float operators Pushed as: changeset: 6993:f89bc4f5078f tag: tip user: Brent Baker <brbaker@adobe.com> 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
Priority: P3 → --
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: