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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
