On Tue Apr 21 05:36:53 2009, bacek wrote:
On Sun Aug 24 08:06:29 2008, jk...@verizon.net wrote:
There is no more tools/dev/ops_renum.mak. Can we close this ticket?
The only reason I did not previously close it was Coke's expression of a
desire to pull this into the main Makefile. But I'll
On Sat May 10 20:22:53 2008, coke wrote:
This make file isn't preprocessed like the standard root.in: it
assumes perl is in your path, and redefines the list of OPSFILES.
Let's move the step into the core makefile, and add another
--maintainer tweak like the one for lex/yacc - either run the
On Fri Aug 22 22:10:54 2008, particle wrote:
6. A new makefile target, renumberops, invokes
tools/dev/opsrenumber.pl.
it strikes me that the makefile target and the script name should be
the same.
Changed to 'make opsrenumber'.
Patch committed to trunk, with small corrections, in r30478.
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
On Fri, Aug 22, 2008 at 7:20 PM, Will Coleda [EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:39 PM, James Keenan via RT
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
Thanks. Am close to submitting a patch. Anyone who wants to kibitz
should check out the 'opsrenum' branch from SVN.
Okay, thanks for getting back to me. Could you read the inline comments
I have inserted into Parrot::OpsRenumber::renum_op_map_file()?
Do the comments accurately reflect what needs to happen re opcode
renumbering both now and at 1.0?
You can read them here:
On Wednesday 13 August 2008 19:39:16 James Keenan via RT wrote:
Okay, thanks for getting back to me. Could you read the inline comments
I have inserted into Parrot::OpsRenumber::renum_op_map_file()?
Do the comments accurately reflect what needs to happen re opcode
renumbering both now and
On Sat, Aug 9, 2008 at 3:50 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
On Sat Aug 09 10:31:37 2008, [EMAIL PROTECTED] wrote:
On Saturday 09 August 2008 06:33:46 James Keenan via RT wrote:
What purpose remains, then, for either tools/dev/ops_renum.mak or
my
alternative,
On Wed Jul 02 09:17:44 2008, [EMAIL PROTECTED] wrote:
What purpose remains, then, for either tools/dev/ops_renum.mak or my
alternative, tools/dev/opsrenumber.pl? Is such a program only intended
to provide a number for newly added opcodes?
kid51
We haven't had any response to this
On Saturday 09 August 2008 06:33:46 James Keenan via RT wrote:
What purpose remains, then, for either tools/dev/ops_renum.mak or my
alternative, tools/dev/opsrenumber.pl? Is such a program only intended
to provide a number for newly added opcodes?
We haven't had any response to this
On Sat Aug 09 10:31:37 2008, [EMAIL PROTECTED] wrote:
On Saturday 09 August 2008 06:33:46 James Keenan via RT wrote:
What purpose remains, then, for either tools/dev/ops_renum.mak or
my
alternative, tools/dev/opsrenumber.pl? Is such a program only
intended
to provide a number for
On Wed Jul 02 09:17:44 2008, [EMAIL PROTECTED] wrote:
On Wed Jul 02 06:25:14 2008, particle wrote:
therefore, in an attempt to keep bytecode compatible across versions
of parrot, opcodes can never be deleted. instead, if opcodes are
deprecated, their function bodies should throw an
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)
On Wed, Jul 2, 2008 at 4:03 AM, James Keenan via RT
[EMAIL PROTECTED] wrote:
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
On Wed Jul 02 06:25:14 2008, particle wrote:
therefore, in an attempt to keep bytecode compatible across versions
of parrot, opcodes can never be deleted. instead, if opcodes are
deprecated, their function bodies should throw an exception explaining
that the opcode is no longer supported.
On Mon Jun 30 17:02:32 2008, coke wrote:
In a fresh checkout, if I 'make renumberops' with no local
modifications, src/ops/ops.num changes.
With my non-fresh branch, I could not confirm this.
If I rename the op store_lex to barf_lex, and run 'make renumberops',
the opcode barf_lex doesn't
On Sun Jun 22 10:04:58 2008, [EMAIL PROTECTED] wrote:
One thing I don't understand: In config/gen/makefiles/root.in, I see
the following variable assignment:
OPS_FILES = @ops@ $(GEN_OPSFILES)# line 455
There currently are no generated .ops files (I think):
GEN_OPSFILES = #
19 matches
Mail list logo
