On Sat, Aug 16, 2008 at 11:39 PM, James Keenan via RT
Post by James Keenan via RTThe patch attached, diff.trunk.opsrenum.txt, is an improved solution to
the problem posed by Coke in the OP of this RT. Here are its features,
working from the surface (e.g., file name changes) down to the method
that does the renumbering of opcodes.
1. Renames lib/Parrot/Ops2pm/Utils.pm to lib/Parrot/Ops2pm.pm. Renames
the directory where the tests for this package are found from
t/tools/ops2pmutils/ to t/tools/ops2pm. Makes appropriate changes in
names within files.
2. Takes the method that did -- and continues to do -- the rewriting of
the ops.num file, renum_op_map_file(), out of lib/Parrot/Ops2pm.pm and
places it in its own module, lib/Parrot/OpsRenumber.pm. This is done so
that the methods that are used in tools/build/ops2pm.pl are found in one
package while the method used in tools/dev/opsrenumber.pl is placed in a
package of its own.
3. Two methods that are used in both lib/Parrot/Ops2pm.pm and
lib/Parrot/OpsRenumber.pm are extracted and placed in a module of their
own: lib/Parrot/Ops2pm/Base.pm. Those methods are new() (the
constructor) and prepare_ops() (which invokes Parrot::OpsFile, which
does the actual parsing of ops files).
So far, all generic refactoring which is fine.
Post by James Keenan via RT4. Parrot::OpsRenumber::renum_op_map_file() has been revised so that it
will behave properly before Parrot 1.0 -- when deletion of opcodes is
still permitted -- and after 1.0 -- when no deletions are permitted.
This flexibility is attained by providing it with the Parrot major
version as an argument. This before-and-after functionality is tested
in a heavily revised t/tools/ops2pm/05-renum_op_map_file.t. Several new
sample files used in testing have been added to the distribution.
I know you were implementing Jerry's requirement here, and that's good.
I do wonder what the plan is for opcodes that are marked deprecated
(which we can do today.) ; once they go past deprecated (before 1.0,
we'd just delete them), what will happen when they are executed? will
we add a :removed pragma on the opcode definition that will simply
throw an exception when they are invoked? Will we just silently
translate them to a noop?
What about the case when we experimentally add an opcode between
official releases, but back it out before the next release? What
counts as an official release? How are we going to number the
intervening releases? Do we have a version indicator to mark as
stable/unstable/experimental/Don't Touch This Without A Hazmat Suit?
What about experimental.ops? is that going to survive with its special
treatment into post-1.0?
I apologize for not asking these questions immediately following
Jerry's original post, but I thought I had until version 0.99 to think
about it. =-)
These questions asked... I'm don't think they block application of the
patch at all; I think these are all questions that should be answered
in a new docs/project/release_strategy.pod which can then spawn TODOs
as necessary.
Post by James Keenan via RT5. The name of the program that invokes Parrot::OpsRenumber is changed
from tools/dev/ops_renum.mak to tools/dev/opsrenumber.pl. It is, after
all, a Perl 5 program, so we provide it with a file name extension
consistent with other programs in tools/dev/.
6. A new makefile target, renumberops, invokes tools/dev/opsrenumber.pl.
Please review, particularly lib/Parrot/OpsRenumber.pm and
t/tools/ops2pm/05-renum_op_map_file.t, which is where most of the really
new stuff is found and/or demonstrated.
I don't have any questions regarding these tests that are unique to
these particular tests.
Post by James Keenan via RTThis patch probably does not do
what Coke requested in the OP, but I don't actually know how to do that.
That is lost in the mists of time, but I'm pretty sure I was looking
for a way to make the dependencies smarter here so we didn't have to
remember to run it. That probably conflicts with Jerry's post-1.0
strictures, however, so I'm not entirely sure that it's relevant
anymore. However, the fact that it's a standard perl script now
instead of a unixy makefile...
Post by James Keenan via RTBut this refactoring should get us closer to that objective.
...Exactly.
VMNWIHTEM[0]: The copyright in a lot of the new files seems to be
2007. Should it be 2008?
Thank you for digging into this.
[0] Very Minor Nit Which I Hate To Even Mention
--
Will "Coke" Coleda