Re: Concise/-Dx op_private output

On Fri, Sep 19, 2014 at 06:44:54PM +0100, Dave Mitchell wrote:
> After my recent work on rationalising op_private, I found quite a few
> places where Concise.pm and/or 'perl -Dx' weren't interpreting some flag
> bits in op_private, and were just displaying them numerically.  I fixed
> some obscure ones, but left some more common ones as-is.
> 
> So I'm wondering whether to fix them now. The downside of fixing is that
> any tests (both in core and CPAN/darkPAN) that examine the output of
> Concise.pm or -Dx may need fixing up.
> 
> Perhaps I should fix some, and leave others?
> 
> The ones that I'm aware of are:
> 
> padrange: the bottom 7 bits hold the pad range. This is currently
> displayed as e.g.
> 
>     padrange[$x:1,2; $y:1,2; $z:1,2; $a:1,2] lRM/LVINTRO,4
> 
> I'd change that to 
> 
>     padrange[$x:1,2; $y:1,2; $z:1,2; $a:1,2] lRM/LVINTRO,RANGE=4
> 
> Similarly, aelemfast, aelemfast_lex use 8 bits for the index: $a[100]
> gives:
> 
>     aelemfast[*a] s/100
> 
> which might become
> 
>     aelemfast[*a] s/INDEX=100
> 
> Finally (the biggy); lots of ops use the lower few bits to specify how
> many args the op expects, e.g.
> 
>     add[t3] vK/2
> 
> which might become
> 
>     add[t3] vK/ARGS=2
>

I've now changed padrange and aelemfast with v5.25.5-34-ge9fb18e,
but I've left the arg count display as /n rather than /ARGS=n,
since it would involve fixing up hundreds of tests under ext/B/t/

-- 
"I do not resent criticism, even when, for the sake of emphasis,
it parts for the time with reality".
    -- Winston Churchill, House of Commons, 22nd Jan 1941.

• Concise/-Dx op_private output by Dave Mitchell
• Re: Concise/-Dx op_private output by Dave Mitchell
• Re: Concise/-Dx op_private output by wolfsage
• Re: Concise/-Dx op_private output by Steffen Mueller
• Re: Concise/-Dx op_private output by Father Chrysostomos