[svn:parrot] r37944 - trunk/src/ops

Will Coleda will at coleda.com
Tue Apr 7 18:24:46 UTC 2009


On Tue, Apr 7, 2009 at 2:03 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Tue, Apr 07, 2009 at 01:26:17PM -0400, Will Coleda wrote:
>> On Tue, Apr 7, 2009 at 11:56 AM,  <pmichaud at svn.parrot.org> 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


More information about the parrot-commits mailing list