develooper Front page | perl.perl5.porters | Postings from November 2005

RE: [PATCH] sort/multicall patch

Thread Previous | Thread Next
From:
Paul Marquess
Date:
November 4, 2005 06:45
Subject:
RE: [PATCH] sort/multicall patch
Message ID:
00c101c5e14e$49ed6300$631c140a@myopwv.com
I forgot to mention that t/f_sort.t is failing in a few of the smoke builds
as well. Not sure if it is related. See

http://www.mail-archive.com/daily-build-reports@perl.org/msg30845.html
http://www.mail-archive.com/daily-build-reports@perl.org/msg30832.html

Paul

> -----Original Message-----
> From: Paul Marquess [mailto:Paul.Marquess@ntlworld.com]
> Sent: 04 November 2005 14:37
> To: 'Robin Houston'
> Cc: 'Nicholas Clark'; 'Rafael Garcia-Suarez'; perl5-porters@perl.org
> Subject: RE: [PATCH] sort/multicall patch
> 
> I could only reproduce it on a redhat3 box. My other Linux box was fine.
> 
> Regarding the patch - sorry, no joy. It doesn't print the
> 
>    Sort subroutine didn't return single value
> 
> message anymore, but it still fails. The order of the array elements is
> almost inverted from what was expected.
> 
> This is what I expected to get from the sort
> 
> a a2345 abc b c d def e f g h i j jklmno k l m n o p q r s t u v w x y z
> 
> and this is what I actually got
> 
> z y x w v u t s r q p o n m l k j jklmno i h g f e d def c b a abc a2345
> 
> 
> Paul
> 
> > -----Original Message-----
> > From: Robin Houston [mailto:robin@cpan.org]
> > Sent: 04 November 2005 13:52
> > To: Paul Marquess
> > Cc: 'Nicholas Clark'; 'Rafael Garcia-Suarez'; perl5-porters@perl.org
> > Subject: Re: [PATCH] sort/multicall patch
> >
> > On Fri, Nov 04, 2005 at 10:57:34AM -0000, Paul Marquess wrote:
> > > I see that quite a few of the smoke builds have been failing in
> DB_File
> > over
> > > the last few days. I assume this is related to the sort/multicall
> patch,
> > > given that this is what I got when I build bleed on redhat3.
> >
> > Interesting, thanks.
> >
> > I can't reproduce that problem here, but the patch below fixes a
> > bug that could cause the problem you report. Does it fix the
> > problem?
> >
> > Robin
> >
> > --- pp_ctl.c.orig	2005-11-04 13:31:15.000000000 +0000
> > +++ pp_ctl.c	2005-11-04 13:48:45.000000000 +0000
> > @@ -1949,6 +1949,7 @@
> >  				     * sort block, which is a CXt_NULL
> >  				     * not a CXt_SUB */
> >  	    dounwind(0);
> > +	    PL_stack_sp = PL_stack_base + 1;
> >  	    return 0;
> >  	}
> >  	else
> > @@ -1957,8 +1958,12 @@
> >      if (cxix < cxstack_ix)
> >  	dounwind(cxix);
> >
> > -    if (CxMULTICALL(&cxstack[cxix]))
> > +    if (CxMULTICALL(&cxstack[cxix])) {
> > +	gimme = cxstack[cxix].blk_gimme;
> > +	if (gimme != G_ARRAY)
> > +	    PL_stack_sp = PL_stack_base + (gimme == G_SCALAR ? 1 : 0);
> >  	return 0;
> > +    }
> >
> >      POPBLOCK(cx,newpm);
> >      switch (CxTYPE(cx)) {
> > --- t/op/sort.t.orig	2005-11-04 13:36:39.000000000 +0000
> > +++ t/op/sort.t	2005-11-04 13:47:08.000000000 +0000
> > @@ -5,7 +5,7 @@
> >      @INC = '../lib';
> >  }
> >  use warnings;
> > -print "1..141\n";
> > +print "1..143\n";
> >
> >  # these shouldn't hang
> >  {
> > @@ -790,3 +790,13 @@
> >  # Using return() should be okay even in a deeper context
> >  @b = sort {while (1) {return ($a <=> $b)} } 1..10;
> >  ok("@b", "1 2 3 4 5 6 7 8 9 10", "return within loop");
> > +
> > +# Using return() should be okay even if there are other items
> > +# on the stack at the time.
> > +@b = sort {$_ = 7 + do{return $b<=> $a}} 1..10;
> > +ok("@b", "10 9 8 7 6 5 4 3 2 1", "return with SVs on stack");
> > +
> > +# As above, but with a sort sub rather than a sort block.
> > +sub ret_with_stacked { $_ = 7 + do {return $b <=> $a} }
> > +@b = sort ret_with_stacked 1..10;
> > +ok("@b", "10 9 8 7 6 5 4 3 2 1", "return with SVs on stack");


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