On Sat, Aug 16, 2008 at 11:39 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > The 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. > 4. 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. > 5. 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. > This 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... > But 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 very much. > kid51 > > Thank you for digging into this. [0] Very Minor Nit Which I Hate To Even Mention -- Will "Coke" Coleda
