develooper Front page | perl.perl5.porters | Postings from June 2015

Re: 5.22 breaks Coro-6.42

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
June 1, 2015 10:39
Subject:
Re: 5.22 breaks Coro-6.42
Message ID:
20150601103941.GV15483@iabyn.com
On Sun, May 31, 2015 at 05:34:00PM +0200, Max Maischein wrote:
> I did some spelunking in git history and some comparing between 5.20 and
> 5.22-RC2, and here are my findings (as on irc):
> 
> There are two errors. One can be easily fixed by reverting the patch
> c910fead7893fe9700031ee59de6b904260b5d69 :
> 
> State.xs:3472:9: error: assignment of member 'svt_get' in read-only object
>          orig_sigelem_get = PL_vtbl_sigelem.svt_get; PL_vtbl_sigelem.svt_get
>  = coro_sigelem_get;


The change in blead is fine; Coro needs fixing, as suggested by Daniel.

> The second error, I don't understand or what is the real cause:
> 
> State.xs:558:29: error: lvalue required as left operand of assignment
>    PadlistNAMES (newpadlist) = (PADNAMELIST *)SvREFCNT_inc_NN (PadlistNAMES
> (padlist));
> 
> This one was likely introduced by 9b7476d7a269a4d9bb24393ae5c8d75efe2fcab4 ,
> but that one doesn't revert easily.

That commit changed the implementation of PADNAMELISTs, and at the same
time made PadlistNAMES() be rvalue only. There doesn't seem to be part of
the API to allow you to *change* the namelist of a padlist, so I guess
Coro would have to unofficially do something like:

    PadnamelistREFCNT(PadlistNAMES(padlist));
    PadlistARRAY(newpadlist)[0] = PadlistNAMES(padlist);

It's possible that making PadlistNAMES() rvalue-only was an unintended
side-effect, and that we should fix it for 5.22.1, with something like:

    -#define PadlistNAMES(pl)	((PADNAMELIST *)*PadlistARRAY(pl))
    +#define PadlistNAMES(pl)	*((PADNAMELIST **)PadlistARRAY(pl))

but that's probably for FC to decide.

Andreas wrote:
> The ticket https://rt.cpan.org/Ticket/Display.html?id=101063 against
> Coro-6.42 may or may not have reached the author, does anybody know?

No idea. That's one of the problems with Marc not using a public bug
tracking system.

> In any case the bisect points to v5.21.6-163-g9b7476d which has been
> covered in https://rt.perl.org/Ticket/Display.html?id=123518 where
> Eval-Compile was in the focus. F.C. then submitted a patch for
> Eval-Compile.
> 
> What needs to be done?
> 
> - reopen 123518?
> - add notes to 123518 without reopening?
> - open a new ticket?

None of the above. They are both things that need fixing in Coro.

> - write to MLEHMANN?

Somebody ought to make him aware of this thread, but I'm not going to do
it. I've put up with far too much personal abuse from him to ever interact
with him again if I can avoid it.

> - add to known issues in perldelta?

I don't know.


-- 
It's not that I'm afraid to die, I just don't want to be there when it
happens.
    -- Woody Allen

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About