A few years ago I created a system where a test would disclose all of
the files on which it depended. This allowed for continuous monitoring
of those files and immediate re-execution of the test when it or its
dependencies changed. When combined with real-time generation of an
HTML dashboard, it re
Right now Test::Builder::_ending() is executed only if the
current process id is the one it had when it started. This
prevents a child process from completing the test with the
"1..N" header.
I introduced a new method, reporting_pid(), that allows the
On Mon, 15 Mar 2004 10:30:30 +, Tim Bunce wrote:
>
> > ...
> >
> > The problem is reading some types of response messages.
> > When using sockets, the server closes the socket after a
> > sending a response without a Content-Length field. The
> > resulting EOF allows the c
it rocks!
On Sun, 22 Feb 2004 19:05:02 -0600, Scott Bolte wrote:
> On Sun, 22 Feb 2004 16:13:01 +, Tim Bunce wrote:
> > >
> > > Now I do agree the HTTP protocol is worth using for managing
> > > the flow of data. I run HTTP over ssh myself. (I modified
> &g
On Sun, 22 Feb 2004 16:13:01 +, Tim Bunce wrote:
> >
> > Now I do agree the HTTP protocol is worth using for managing
> > the flow of data. I run HTTP over ssh myself. (I modified
> > HTTP::Daemon to use two unidirectional pipes instead of a
> > single, bidirectional socket.)
>
On Sun, 22 Feb 2004 01:07:38 -0500, Michael G Schwern wrote:
>
> See above. Yes, ssh is not portable enough.
Where is the gap? I have OpenSSH on every Unix platform I
use and, with cygwin's help, all the windows based systems
too. I can even log *into* a w98 host with ssh
On Thu, 19 Feb 2004 08:35:28 +, Nick Ing-Simmons wrote:
>
> How about layering it on ssh then?
> That has done all authentication stuff already.
I agree. With empty passphrases and/or ssh-agent it is very
easy to set up automated commands. Add forced commands (an
under
On Sun, 8 Feb 2004 17:27:02 -0600, Andy Lester wrote:
> On Sun, Feb 08, 2004 at 08:41:59AM -0600, Scott Bolte ([EMAIL PROTECTED]
> ) wrote:
> > I agree, but I still believe it would be good if Test::Harness
> > laid out syntax rules for extensions.
>
> There are no
On Fri, 6 Feb 2004 13:34:01 -0800, Michael G Schwern wrote:
>
> Test::Harness parses 'ok' and 'not ok' and 'Bail out'... Test::*
> modules produce the output Test::Harness parses. So your extra logic
> to parse "depends on" would go into your Test::Harness extension, but
> the depends_on() funct
On Fri, 6 Feb 2004 12:22:24 -0800, Michael G Schwern wrote:
>
> It wouldn't be Test::Harness, it would be a seperate Test::Depends or
> something.
I could live with that, but why do you think it needs to
be separate?
The T::H documentation makes it quite clear that there
I'd like to propose an addition to the Test::Harness parsing
rules to support dependency analysis. That, in turn, allows
monitoring for file changes and selective, immediate
re-execution of test files. Is this the right forum for
that discussion?
Bui
11 matches
Mail list logo
