#469: [CAGE] revisit t/tools/ops2pm/05-renum_op_map_file.t
---------------------+------------------------------------------------------
Reporter: allison | Owner: jkeenan
Type: cage | Status: closed
Priority: normal | Milestone:
Component: none | Version:
Severity: medium | Resolution: fixed
Keywords: | Lang:
Patch: | Platform:
---------------------+------------------------------------------------------
Changes (by jkeenan):
* status: assigned => closed
* resolution: => fixed
Comment:
Replying to [comment:10 allison]:
> Jim,
>
> Those have to be manually added, and that's an intentional control step,
so someone has to think about which ops are being added. But, new ops must
always be added to the end of the file (unless you want to manually
renumber all the ops that follow your insertion point, which would be
insane). What opsrenumber.pl does is put them in a sane order.
Thanks for the clarification. In r38825 and r38829, I applied the changes
contained in the attached patch, ''opsrenum.patch''.
The revised test file does not contain a test for the case where we have
added opcodes and then added those opcodes to the tail of
''src/ops/ops.num''. I tried to write such a test, but my head started
spinning with all the manipulations I would have to do to get it to work
correctly in a tempdir. So, instead, I did a fresh checkout from trunk
and proceeded to manipulate ''src/ops/core.ops'' and ''src/ops/ops.num''
until I was persuaded that ''tools/dev/opsrenumber.pl'' DWIMmed.
So I think this fixes the issue, and I am therefore closing this ticket.
Thank you very much.
kid51
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/469#comment:12>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
