Without saying you shouldn't be sending them here, but as an aside...
Who told you to send patches to the list?
Is there a reason that the rt.cpan.org queue is no longer useful?
Adam K
Tassilo von Parseval wrote:
Hi,
I was told that Test::More patches should now go to this list so here we
go
Hi,
Any experiments with Perl6/Parrot and Solaris Express
or Solaris 10 ? Im curious how much the language has
changed and how well the new VM would work in Solaris
...
Is there any Solaris x86 or sparc package of the new
Parrot VM ?
thanks,
A far simpler solution (that I've posted before recently) is to
output test "numbers" like
.1.1
.1.2
.1.3
.2.1
.2.2
.1.4
etc where the first number signifies the thread/process and the second
is just an increasing sequence within that thread. The . is there at
the start so that Test::Harness doe
On Tue, Mar 28, 2006 at 06:29:43PM +1000 Adam Kennedy wrote:
> Without saying you shouldn't be sending them here, but as an aside...
>
> Who told you to send patches to the list?
Andy Lester told Stas Bekman who told me.
> Is there a reason that the rt.cpan.org queue is no longer useful?
I don'
On Tue, Mar 28, 2006 at 09:47:54AM +0100 Fergal Daly wrote:
> A far simpler solution (that I've posted before recently) is to
> output test "numbers" like
>
> .1.1
> .1.2
> .1.3
> .2.1
> .2.2
> .1.4
>
> etc where the first number signifies the thread/process and the second
> is just an increasin
Tassilo von Parseval wrote:
On Tue, Mar 28, 2006 at 09:47:54AM +0100 Fergal Daly wrote:
A far simpler solution (that I've posted before recently) is to
output test "numbers" like
.1.1
.1.2
.1.3
.2.1
.2.2
.1.4
etc where the first number signifies the thread/process and the second
is just an i
On 3/28/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> Tassilo von Parseval wrote:
> > On Tue, Mar 28, 2006 at 09:47:54AM +0100 Fergal Daly wrote:
> >
> >>A far simpler solution (that I've posted before recently) is to
> >>output test "numbers" like
> >>
> >>.1.1
> >>.1.2
> >>.1.3
> >>.2.1
> >>.2.2
What's changing the protocol?
As I understand it from
http://search.cpan.org/~petdance/Test-Harness-2.56/lib/Test/Harness/TAP.pod
the test number must be a number.
It does refer specifically to it having to start with a digit, but I'm
assuming that by number it means [1-9]\d*
.1.2 would
Tassilo von Parseval wrote:
Hi,
I was told that Test::More patches should now go to this list so here we
go.
The attached patch serves as a draft for enabling test-scripts that fork
without the test-counter getting confused. It does so by using a
Storable imaged shared between the processes. Th
That's why I said you prefix with a ".".
This has the effect of making it not a number as far as TAP is
concernted, instead it becomes part of the name.
Of course it would be better to allow "."s in the number, that way you
can check that they are increasing properly and allows you to have
sub-pl
On Tue, Mar 28, 2006 at 11:27:15AM +0100 Fergal Daly wrote:
> That's why I said you prefix with a ".".
>
> This has the effect of making it not a number as far as TAP is
> concernted, instead it becomes part of the name.
>
> Of course it would be better to allow "."s in the number, that way you
>
On Tue, Mar 28, 2006 at 08:22:25PM +1000 Adam Kennedy wrote:
> Tassilo von Parseval wrote:
> >Hi,
> >
> >I was told that Test::More patches should now go to this list so here we
> >go.
> >
> >The attached patch serves as a draft for enabling test-scripts that fork
> >without the test-counter gettin
On 3/28/06, Tassilo von Parseval <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 28, 2006 at 11:27:15AM +0100 Fergal Daly wrote:
> > That's why I said you prefix with a ".".
> >
> > This has the effect of making it not a number as far as TAP is
> > concernted, instead it becomes part of the name.
> >
> >
On Mar 28, 2006, at 4:55 AM, Tassilo von Parseval wrote:
Do you think this might work better, or could be implemented as, a
seperate Test::Fork type module?
It certainly could be done. But it would essentially share 90% of its
code with Test::Builder.
Umm, subclassing? :-)
It's simple rea
hi all :)
for those interested in both php and perl, it seems that php's native .phpt
testing feature will soon produce TAP compliant output - see greg beaver's
comments here
http://shiflett.org/archive/218#comments
so, TAP is slowly dominating the world... but we all knew that already :)
wha
I don't know of examples off-hand but I think in a way they're
correct. If you write lots of code first and then try to test it, you
will look and say "it's not possible to test this so I could not
possibly have written my tests beforehand - those TDD guys are fools".
If you write the tests beforeh
On Mar 26, 2006, at 16:26, Patrick R. Michaud wrote:
I agree it looks like a GC bug, and not anything x86_64 specific.
It was definitely a GC bug (COW copies of constant strings did move
string buffers).
Fixed r12062.
leo
David Cantrell wrote:
> Geoffrey Young wrote:
>
>>> "Only the simplest of designs benefits from pre-coded tests, unless
>>> you have
>>> unlimited developer time."
>>
>> needless to say I just don't believe this.
>
>
> Try writing a test suite ahead of time for a graphing library. It's
> poss
Geoffrey Young wrote:
"Only the simplest of designs benefits from pre-coded tests, unless you have
unlimited developer time."
needless to say I just don't believe this.
Try writing a test suite ahead of time for a graphing library. It's
possible (indeed, it's trivial - just check the md5 ha
On Tue, Mar 28, 2006 at 05:47:29PM +0100, David Cantrell wrote:
> Geoffrey Young wrote:
>
> >> "Only the simplest of designs benefits from pre-coded tests, unless you
> >> have
> >> unlimited developer time."
> > needless to say I just don't believe this.
>
> Try writing a test suite ahead of ti
Moin,
On Tuesday 28 March 2006 16:11, Geoffrey Young wrote:
> hi all :)
>
> for those interested in both php and perl, it seems that php's native
> .phpt testing feature will soon produce TAP compliant output - see greg
> beaver's comments here
>
> http://shiflett.org/archive/218#comments
>
> so
On Tue, Mar 28, 2006 at 06:49:15AM -0600 Chris Dolan wrote:
> On Mar 28, 2006, at 4:55 AM, Tassilo von Parseval wrote:
>
> >>Do you think this might work better, or could be implemented as, a
> >>seperate Test::Fork type module?
> >
> >It certainly could be done. But it would essentially share 90%
Geoffrey Young wrote:
David Cantrell wrote:
Try writing a test suite ahead of time for a graphing library. It's
possible (indeed, it's trivial - just check the md5 hashes of the images
that are spat out against images that you have prepared ahead of time in
some other way) but it would be damna
Moin,
On Tuesday 28 March 2006 17:14, Fergal Daly wrote:
> I don't know of examples off-hand but I think in a way they're
[snipabit]
> Also, the problem with php (assuming you use it as a webpage
> generator) is that it encourages you to embed code in your HTML and so
> yes, it is naturally diffic
Ben Evans wrote:
Strawman.
Ad hominem.
A graphing library is an obvious example where functional testing should be
used prior to automated regression testing.
Yes. It is one of many such examples. It just happens to be the one I
am working on as we speak.
--
David Cantrell
Geoffrey Young wrote:
> "Only the simplest of designs benefits from pre-coded tests, unless
you have
unlimited developer time."
needless to say I just don't believe this. but as I try to broach the
test-driven development topic with folks I hear this lots - not just that
they don't have the t
On Tue, 28 Mar 2006, Stefan Parvu wrote:
> Any experiments with Perl6/Parrot and Solaris Express
> or Solaris 10 ? Im curious how much the language has
> changed and how well the new VM would work in Solaris
> ...
>
> Is there any Solaris x86 or sparc package of the new
> Parrot VM ?
I'm not awa
On 3/28/06, Tels <[EMAIL PROTECTED]> wrote:
> Moin,
>
> On Tuesday 28 March 2006 17:14, Fergal Daly wrote:
> > I don't know of examples off-hand but I think in a way they're
> [snipabit]
> > Also, the problem with php (assuming you use it as a webpage
> > generator) is that it encourages you to emb
On 3/28/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> Geoffrey Young wrote:
> > David Cantrell wrote:
> >>Try writing a test suite ahead of time for a graphing library. It's
> >>possible (indeed, it's trivial - just check the md5 hashes of the images
> >>that are spat out against images that you
On Tuesday 28 March 2006 06:11, Geoffrey Young wrote:
> "Only the simplest of designs benefits from pre-coded tests, unless you
> have unlimited developer time."
"If you think TDD is expensive, try debugging."
Greg's comments give me the impression that he thinks TDD means writing a
whole pile
On Monday 20 March 2006 11:16, Bernhard Schmalhofer wrote:
> I have put the calls to example_output_like() and example_output_is() as
> comments into t/benchmarks/benchmarks.t.
>
> # XXX use example_output_is() and example_output_like()
> # This does not work yet WRT to TODO
>
What's the standard (if any) for how to configure a build script to
install specific files (e.g. httpd.conf) in someplace other than the
standard Perl library/script/man locations?
For example, if my distro contains a bunch of .pm files and .pl files,
which go in the "normal" place, and my dis
Matisse Enzer wrote:
What's the standard (if any) for how to configure a build script to
install specific files (e.g. httpd.conf) in someplace other than the
standard Perl library/script/man locations?
For example, if my distro contains a bunch of .pm files and .pl files,
which go in the "nor
On Tue, 28 Mar 2006, Randy W. Sims wrote:
> The add_build_element() method is the key to the process.
Ah-Ha and thank you Very Nice!
I did read the perldoc - but just didn't get that
add_build_element('foo_files')
would make M::B look for a foo_fiels element - and I thought i would have
to
34 matches
Mail list logo
