Re: [rt.cpan.org #85336] Fails often when tested in parallel

2014-07-02 Thread sisyph...@optusnet.com.au via RT 
Wed Jul 02 05:52:27 2014: Request 85336 was acted upon.
Transaction: Correspondence added by sisyph...@optusnet.com.au
   Queue: Inline
 Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
   Broken in: 0.53
Severity: (no value)
   Owner: Nobody
  Requestors: a...@cpan.org, ken...@cpan.org
  Status: open
 Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 


- Original Message - 
From: Ed J via RT bug-inl...@rt.cpan.org

 FYI, the code to show the correct operation of BUILD_NOISY can be 
 one-linered like so:

 perl -MInline=C,Config,BUILD_NOISY,1,FORCE_BUILD,1 -e use Inline C = 
 q[void inline_warner() { int *x = 2; }]

Yes, for a test  I'm thinking just have the test script run something like 
that as a system command with output redirected to a file - and then check 
that file (to an extent that allows us to be confident that BUILD_NOISY is 
behaving as expected).

 My reading of the patch in question is that it turns off BUILD_NOISY when 
 it's Windows and the shell is cmd.

That's about the extent of it. But I'm damned if I can think of any reason 
that ought to be done.

 If BUILD_NOISY does the right thing with Win32 and CMD, let's undo that 
 change?

BUILD_NOISY has always done the right thing for me on Win32 in the cmd.exe 
shell - that is, until 0.55 ;-)
So yes - we definitely need to revert to pre-0.55 behaviour.

(This Windows laptop I'm using while I'm not at home doesn't have a git 
client, and I can't be bothered installing one on it. I'll be back home 
tomorrow night and will attend to this BUILD_NOISY issue then, if no-one 
else has.)

Cheers,
Rob

Re: [rt.cpan.org #85336] Fails often when tested in parallel

2014-04-13 Thread sisyph...@optusnet.com.au via RT 
Sun Apr 13 07:17:59 2014: Request 85336 was acted upon.
Transaction: Correspondence added by sisyph...@optusnet.com.au
   Queue: Inline
 Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
   Broken in: 0.53
Severity: (no value)
   Owner: Nobody
  Requestors: a...@cpan.org, ken...@cpan.org
  Status: open
 Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 


-Original Message- 
From: Shawn Laffan via RT

 The local assignment to $ENV{MAKEFLAGS} won't apply outside the if block, 
 will it?

Duh !!

 This should, though:

 local $ENV{MAKEFLAGS} = $ENV{MAKEFLAGS} =~ s/(--jobserver-fds=[\d,]+)//
  if $ENV{MAKEFLAGS};

Thanks - fixed in git.

Cheers,
Rob

Re: [rt.cpan.org #85336] Fails often when tested in parallel

2014-04-13 Thread sisyphus1 
-Original Message- 
From: Shawn Laffan via RT


The local assignment to $ENV{MAKEFLAGS} won't apply outside the if block, 
will it?


Duh !!


This should, though:

local $ENV{MAKEFLAGS} = $ENV{MAKEFLAGS} =~ s/(--jobserver-fds=[\d,]+)//
 if $ENV{MAKEFLAGS};


Thanks - fixed in git.

Cheers,
Rob

Re: [rt.cpan.org #85336] Fails often when tested in parallel

2013-05-22 Thread Andreas Koenig 
Sisyphus via RT bug-inl...@rt.cpan.org writes:

 Is that worth trying ?

This, or maybe apply some locking? Depends on how much work it is, and
on how relevant for later real world behaviour it is.

Except for this, I'd leave the judgement to the implementor;)

-- 
andreas

Re: [rt.cpan.org #85336] Fails often when tested in parallel

2013-05-18 Thread (Andreas J. Koenig) via RT 
Sat May 18 10:40:47 2013: Request 85336 was acted upon.
Transaction: Correspondence added by andreas.koenig.7os6v...@franz.ak.mind.de
   Queue: Inline
 Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
   Broken in: 0.53
Severity: (no value)
   Owner: Nobody
  Requestors: a...@cpan.org
  Status: open
 Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 


Sisyphus via RT bug-inl...@rt.cpan.org writes:

 Is that worth trying ?

This, or maybe apply some locking? Depends on how much work it is, and
on how relevant for later real world behaviour it is.

Except for this, I'd leave the judgement to the implementor;)

-- 
andreas

Re: [rt.cpan.org #85336] Fails often when tested in parallel

2013-05-18 Thread David Oswald via RT 
Sat May 18 11:23:47 2013: Request 85336 was acted upon.
Transaction: Correspondence added by daoswald
   Queue: Inline
 Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
   Broken in: 0.53
Severity: (no value)
   Owner: Nobody
  Requestors: a...@cpan.org
  Status: open
 Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 


I get test failures in Inline::CPP when running tests in parallel.
I've gone through Inline::CPP and implemented file locking to
eliminate race conditions, but the issue persists.  That leads me to
believe that there needs to be a similar fix in Inline.  Changing
Inline's tests to use separate build directories wouldn't fix the
underlying issue of Inline not supporting concurrency.  Proper file
locking probably would resolve the issue, not only for Inline, but
also for plugins such as Inline::CPP.


On Sat, May 18, 2013 at 8:40 AM, (Andreas J. Koenig) via RT
bug-inl...@rt.cpan.org wrote:
 Sat May 18 10:40:47 2013: Request 85336 was acted upon.
 Transaction: Correspondence added by andreas.koenig.7os6v...@franz.ak.mind.de
Queue: Inline
  Subject: Re: [rt.cpan.org #85336] Fails often when tested in parallel
Broken in: 0.53
 Severity: (no value)
Owner: Nobody
   Requestors: a...@cpan.org
   Status: open
  Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=85336 


 Sisyphus via RT bug-inl...@rt.cpan.org writes:

 Is that worth trying ?

 This, or maybe apply some locking? Depends on how much work it is, and
 on how relevant for later real world behaviour it is.

 Except for this, I'd leave the judgement to the implementor;)

 --
 andreas




-- 

David Oswald
daosw...@gmail.com