This was suggested previously in 2008
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-06/msg00912.html
On Mon, Nov 14, 2011 at 04:59:57PM -0800, Michael G Schwern wrote:
> Having a parallel and featureful testing system is very useful. I use it to
> test Test::More (in the Test-Builder1.5 branch). Others might find it useful
> to do the same.
Other than people writing test modules, who would find it useful?
> t/test.pl is very important to the Perl core tests, but it is largely
> undocumented and untested. Going through the p5p process to patch it makes
> working on it difficult and open to bike shedding. If it were dual-lived it
> could be worked on as its own thing with its own commits and tests.
test.pl is a script, not a package. Our machinery for dealing with dual
life things is really only set up to deal with modules. So doing this is not
going to just drop in to what we have.
> By having a dedicated feed of issues and commits, careful attention could be
> paid to what code and features are going in. Close attention and discussion
> can happen about whether the code is simple enough and the features apt for
> the needs of the core.
Surely the needs of the core *are* better determined by the core developers,
not some third party group?
Also, having upstream be anywhere other than the core actively gets in the
way of t/test.pl actually being useful to core developers (or at least to
me, as a core developer who has added things to it).
Even having it being upstream blead gets in the way of it being useful.
Right now, as all users of the core's t/test.pl are in the core, it's
possible to
a: add things to it without stopping to think "is this a decent, supportable
API that can last forever", because if the API turns out to be wrong,
it's entirely possible to have a "flag day" commit that changes it and
all its users
b: remove things from it, because nothing is using them any more
c: not worry about what versions of perl it supports, or working round
problems in them
(Although to be fair, if a particular piece of perl syntax had been
buggy before, it's possibly something fragile that should be avoided in
case it breaks again for a different reason)
Nothing in the above stops anyone taking a copy of test.pl and using it.
Doing this also doesn't add a layer of process into working on the core.
> If folks are cool with that, I can set up a Github repository for it. We'll
> worry about whether CPAN release is appropriate later.
I'm distinctly uncool about doing it that way.
I'm unconvinced about doing it with blead upstream.
This feels like a lot of work for little benefit, with the work outweighing
the benefit.
We did start work on trying to extract runperl() as Test::Builder module.
There's a branch from blead where I attempted to convert module tests to
use it and found which features were necessary for them:
http://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/runperl
Beware that IPC::Cmd can't capture output on Win32 with core-only modules,
and IPC::Run can't reliably capture output on Win32, thanks to Microsoft's
socketpair implementation following advice from Klortho:
#11912 Evidently it's important to you to get the wrong answer as
quickly as possible.
(The default for closing a socket on Win32 is to drop all unsent buffered
data on the floor. No, I'm not kidding.
Note To assure that all data is sent and received on a connection, an
application should call shutdown before calling closesocket (see
Graceful shutdown, linger options, and socket closure for more
information). Also note, an FD_CLOSE network event is not posted after
closesocket is called.
http://msdn.microsoft.com/en-us/library/ms737582%28v=vs.85%29.aspx
I've also found
http://msdn.microsoft.com/en-us/library/ms738547%28v=vs.85%29.aspx
Whereas the BSD socket() implementation works in such a way that a socket FD
can be substituted for a file FD, pipe FD or tty FD, and the program
continues to work just as it did before, without needing any special case
code. Doesn't even need recompiling.)
Nicholas Clark
