> Second, two notes about the branch: > > In a fresh checkout, if I 'make renumberops' with no local > modifications, src/ops/ops.num changes. > If I rename the op store_lex to barf_lex, and run 'make renumberops', > the opcode barf_lex doesn't show up in src/ops/ops.num. (But, > store_lex vanishes) >
I have found the code which causes (at least the) 2nd problem Coke describes and know how to fix it. See the opsrenum branch. But whether my fix is correct or not depends on two questions: (1) Is the following passage from the inline comments in src/ops/ops.num still valid? # once an opcode is added to this file it should never be # removed. Opcodes that are in here but that have no corresponding # function backing them (because, for example, they've been deleted, # which shouldn't ever happen once we hit production) should be mapped # by the ops processing programs to an exception op If it *is* valid, then any renaming of an opcode should leave that op's *current* name and number in number.ops unchanged. The *new* name for the opcode should presumably be pushed on to the end of the list. But this runs counter to the generally programming principle that we should get rid of old, unused code. Why is this case different? Which leads to the next question: (2) Why do we maintain number.ops as a *static file of source code at all*? Why is it in the repository? If a given Parrot developer, for a given instance of Parrot configuration and build, renumbers the opcodes (either because the list of opcodes has changed or just for the hell of it), why must that renumbering be inflicted on all other Parrot developers -- which it would be as the result of 'svn ci'? Thank you very much. kid51
