t/steps/auto/frames-01.t: Failures following pcc_reapply merge

[jkeenan]

With the merge of the pcc_reapply branch into trunk today at r41972, the following changes were made to config/auto/frames.pm:

svn diff -r {2009-10-20} config/auto/frames.pm      
Index: config/auto/frames.pm
===================================================================
--- config/auto/frames.pm       (revision 41946)
+++ config/auto/frames.pm       (working copy)
@@ -40,6 +40,7 @@
 
 sub _call_frames_buildable {
     my $conf = shift;
+
     my $osname  = $conf->data->get('osname');
     my $cpuarch = $conf->data->get('cpuarch');
     my $nvsize  = $conf->data->get('nvsize');
@@ -49,8 +50,10 @@
         $can_build_call_frames = $conf->options->get('buildframes');
     }
     else {
-        $can_build_call_frames = ($nvsize == 8 && $cpuarch eq 'i386'
-            && $osname ne 'darwin');
+        # Temporary disable build frames automatically.
+        #$can_build_call_frames = ($nvsize == 8 && $cpuarch eq 'i386'
+        #    && $osname ne 'darwin');
+        $can_build_call_frames = 0;
     }
     return $can_build_call_frames;
 }

This temporary disabling of build frames functionality had the effect of causing two failures in t/steps/auto/frames-01.t:

prove -v t/steps/auto/frames-01.t
...
not ok 12 - Result is 'yes', as expected

#   Failed test 'Result is 'yes', as expected'
#   at t/steps/auto/frames-01.t line 47.
#          got: 'no'
#     expected: 'yes'
ok 13 - _call_frames_buildable() returned true value, as expected
ok 14 - _call_frames_buildable() returned false value, as expected
not ok 15 - _call_frames_buildable() returned true value, as expected (i386/non darwin/8)

#   Failed test '_call_frames_buildable() returned true value, as expected (i386/non darwin/8)'
#   at t/steps/auto/frames-01.t line 72.

Apparently no one ran perl Configure.pl --test at the time of merge. The failing tests should either have been modified to conform to the new code in auto::frames or they should have been TODOed and a TT created to track the TODO item.

I'm going to elect to follow the second course of action. This ticket exists to track the restoration of 'normal' build frames functionality and the full testing of the code by which we probe for that functionality.

Thank you very much.

kid51

[jkeenan]

Two tests in t/steps/auto/frames-01.t TODOed at r41998. TODO comment also added to config/auto/frames.pm.

[jkeenan]

Replying to jkeenan:

Two tests in t/steps/auto/frames-01.t TODOed at r41998. TODO comment also added to config/auto/frames.pm.

I would like to remind those Parrot developers working on libjit and frames that we still have to deal with the problem of two tests in t/steps/auto/frames-01.t that were TODO-ed out before the last release.

prove -v t/steps/auto/frames-01.t 
t/steps/auto/frames-01.t .. 
1..27
ok 1 - use config::init::defaults;
...
ok 11 - Got defined result
not ok 12 - Result is 'yes', as expected 
# TODO build frames temporarily disabled at pcc_reapply merge: TT #1132

#   Failed (TODO) test 'Result is 'yes', as expected'
#   at t/steps/auto/frames-01.t line 50.
#          got: 'no'
#     expected: 'yes'
ok 13 - _call_frames_buildable() returned true value, as expected
ok 14 - _call_frames_buildable() returned false value, as expected
not ok 15 - _call_frames_buildable() returned true value, 
#     as expected (i386/non darwin/8) 
# TODO build frames temporarily disabled at pcc_reapply merge: TT #1132

#   Failed (TODO) test '_call_frames_buildable() returned true value, 
#     as expected (i386/non darwin/8)'
#   at t/steps/auto/frames-01.t line 79.
ok 16 - _call_frames_buildable() returned false value, as expected (i386/darwin/8)
...

Can we get these examined before next week's release?

Thank you very much.

kid51

[plobsing]

Replying to jkeenan:

These tests are for the OS/arch detection for frame building capability evaluation. This detection (and associated testing) was turned off when the OS/arch specific frame builder we had was abandoned.

We don't currently have a replacement for the frame builder, so our capability detection system currently doesn't really make decisions, so we can't really test the ability of our capability detection system to make decisions.

These tests do serve as a good guideline for testing of future system property detection (eg: is llvm installed?) for future frame builder systems. In the absence of an actual frame builder system and associated capability detection system, I propose we leave them.

[jkeenan]

Since I have no idea when we're going to get a replacement for the frame builder, there's no point in keeping this ticket open. We'll let the TODO-ed tests sit.

Thank you very much.

kid51