Parrot::Ops2pm::Base::prepare_ops(): Seek feedback on possible rephrasing of warning

James E Keenan jkeen at verizon.net
Mon Apr 27 00:54:19 UTC 2009


This is a case where, before filing a new TT, I would like some user 
feedback.

Parrot::Ops2pm::Base::prepare_ops() is a method inherited by both 
Parrot::Ops2pm and Parrot::OpsRenumber.  The former is the class 
underlying tools/build/ops2pm.pl, one of the programs invoked by make 
during the Parrot build process.  prepare_ops() calls the following code 
on each .ops file provided as a command-line argument to ops2pm.pl:

         my $temp_ops = Parrot::OpsFile->new( [$f], $self->{nolines} );
         die "$self->{script}: Could not read ops file '$f'!\n"
             unless defined $temp_ops;

         my $experimental = $f =~ /experimental/;

         if (! ref $temp_ops->{OPS}) {
             my $message = "OPS invalid for $f";
             if ($experimental) {
                 # empty experimental.ops file is OK.
                 warn $message;
                 next;
             }
             else {
                 die $message;
             }
         }

As I understand this, each .ops file is processed via Parrot::OpsFile 
and is examined to make sure it's not malformed.  If, for example, an 
.ops file doesn't have any ops code in it, then ops2pm.pl should die 
with an 'OPS invalid' error message.

However, an exception is made for src/ops/experimental.ops, since at any 
point in Parrot's development there may or may not be experimental 
opcodes in that file and hence in force.  So instead of die-ing with an 
'OPS invalid' message, we simply warn.

I was pondering DEPRECATED.pod this weekend.  That file states that now 
is the time to get rid of the 'trap' experiment opcode:

        experimental ops [eligible in 1.1]
            src/ops/experimental.ops - only the "trap" opcode remains

(Note:  I can't find a TT specifically tied to this deprecation notice.)

I started to prepare a patch eliminating the 'trap' opcode from 
experimental.ops.  That would eliminate the last remaining opcode from 
that file, though the file -- now nothing but POD -- would presumably 
remain in case we added experimental opcodes in the future.  And that 
zeroing out of opcodes began to set off the warning described above 
while I was running 'make buildtools_tests'.  Only problem:  the warning 
was pretty much useless, as '$f' is either undefined or an empty string, 
so the warning only reads:

   OPS invalid for at line 158 lib/Parrot/Ops2pm/Base.pm

Now, since most people don't run the buildtools tests, most people will 
never see this warning.  Indeed, I never saw it myself, because until 
now we were never close to having zero experimental opcodes in force. 
But since I run those tests at least once before each release, I would 
like to change the warning to something more meaningful, such as:

   No opcodes found in experimental.ops

Comments?  Thank you very much.

kid51



More information about the parrot-dev mailing list