On Tue, Apr 7, 2009 at 2:03 PM, Patrick R. Michaud <[email protected]> wrote: > On Tue, Apr 07, 2009 at 01:26:17PM -0400, Will Coleda wrote: >> On Tue, Apr 7, 2009 at 11:56 AM, <[email protected]> wrote: >> > Author: pmichaud >> > Date: Tue Apr 7 15:56:46 2009 >> > New Revision: 37944 >> > URL: https://trac.parrot.org/parrot/changeset/37944 >> > >> > Log: >> > [lex]: Add find_caller_lex opcode for getting lexicals from callers' >> > scopes. >> > Note that "make realclean" is probably required. >> > >> > Modified: >> > trunk/src/ops/ops.num >> > trunk/src/ops/var.ops >> >> Looks like the ops were renumbered with this commit; can we get the >> renumbering undone, and just add this at the end? > > Sure. If opsrenumbering is no longer allowed/desired, we > should eliminate the target from the makefile.
Nevermind. Per allison on #parrot, renumbering opcodes is fine post 1.0, and perhaps we'll revisit this topic later. In the meantime, renumber away. (so this commit can stay) >> Also, was there discussion or a ticket regarding a new opcode? > > There's been discussion off-and-on, but nothing formal. The > opcode that was added is needed for core PGE and PCT updates, > and there's not a good PIR workaround available (not to mention > that the opcode form is far more efficient). > >> Also, adding non-experimental opcodes implies updating PBC_COMPAT. > > You're correct, I forgot about that. Will fix. > >> Also, should new opcodes be added in experimental.ops until we're sure >> we're keeping them? (this may have already been decided elsewhere) > > I'll leave this for further discussion. I have no problem with > placing the ops in experimental for now, but I suspect we'll > end up needing them or keeping for quite some time (at least until > there's a significant refactor of Parrot context handling). > > Thanks, > > Pm > -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
