Great, thanks a lot for answers. I will have to setup
myself a test environment for Perl 6. I will report
later my findings about this project.
The goal would be to stay and test as much as I can
Perl 6 under Solaris 10 and Express. I have AMD64
systems running Solaris so this would be the main
The next release will be rolled out this weekend. The usual terms apply:
* no feature changes to Parrot core incl. build
* bug and docu fixes welcome
leo
There are a number of ways to do this. The most simple is:
use strict;
use warnings;
use File::HomeDir;
my $conf_dir = File::Spec-catdir( File::HomeDir-my_home, '.Foo' );
Not that I wish to be a pedant about this, but only so people keep it in
mind...
This installer will crash with a
The one thing I don't really like very much about TDD is that in a
loosely typed language I suspect if suffers.
Specifically...
- It can test the things you know that work.
- It is good when testing the things you know that don't work (its
strong point)
- It is not good for testing the
Well, the author of Test::More seems to differ on that:
http://rt.cpan.org/Public/Bug/Display.html?id=8391
Although personally I'd think I'd read into that, that forking shouldn't
cause problems, with and you should be able to emit test output on both
sides as a bonus extended DWIM
I'd also add a small warning in that Apache::Test does seem to want to
dominate the entire test suite (run everything from TEST) and so may not
be as suitable in cases where you have 50-500 test scripts already, and
you just want a few to work with Apache::Test and a normal Makefile.PL
built
Adam Kennedy wrote:
I'd also add a small warning in that Apache::Test does seem to want to
dominate the entire test suite (run everything from TEST) and so may not
be as suitable in cases where you have 50-500 test scripts already, and
you just want a few to work with Apache::Test and a
Moin,
On Thursday 30 March 2006 17:32, Adam Kennedy wrote:
[snip]
Calling -method( \ ) or -method( \undef ) or -method ( sub { die
foo } ) and a dozen other things like that is intentionally provoking
that code into blowing up.
This are good things, but checking every param on every call to
Moin,
On Wednesday 29 March 2006 22:44, Andrew Savige wrote:
--- Tels wrote:
although I still can only guess what TDD stands for :)
Tolkien Driven Development?
Googling around for examples of real world large systems developed
using TDD, I found http://www.agiledata.org/essays/tdd.html
Adam Kennedy wrote:
- It can test the things you know that work.
- It is good when testing the things you know that don't work (its
strong point)
- It is not good for testing the things you don't know that don't work.
This implies that TDD is about code quality. For me, I find that a big
Thanks, I've applied the patch in SVN revision 12077.
Thanks too.
I only replaced the package variables with lexical ones.
I copy and paste from os.t
Could you check whether this works now under MinGW?
Seems ok. See smoke results, i386-MSWin32-gcc Parrot 0.4.2 r12077 30 Mar
2006 00:16 Thu.
On Thursday 30 March 2006 07:32, Adam Kennedy wrote:
In contrast, as I hear chromatic express it, TDD largely involves
writing tests in advance, running the tests, then writing the code.
Not quite. It means writing just enough tests for the next testable piece of
the particular feature
Adam Kennedy wrote:
There are a number of ways to do this. The most simple is:
use strict;
use warnings;
use File::HomeDir;
my $conf_dir = File::Spec-catdir( File::HomeDir-my_home, '.Foo' );
Not that I wish to be a pedant about this, but only so people keep it in
mind...
This
demerphq == demerphq [EMAIL PROTECTED] writes:
demerphq While apparently some on this list apparently dont favour this
demerphq approach, im pretty much at a loss to come with a better way to test
demerphq the module.
Did you also look at Devel::Cover, to see if your tests tickle the
code
On Tue, 28 Mar 2006, Randy W. Sims wrote:
There are a number of ways to do this. The most simple is:
use strict;
use warnings;
use File::HomeDir;
my $conf_dir = File::Spec-catdir( File::HomeDir-my_home, '.Foo' );
use Module::Build;
my $builder = Module::Build-new(
module_name
Matisse Enzer wrote:
On Tue, 28 Mar 2006, Randy W. Sims wrote:
There are a number of ways to do this. The most simple is:
use strict;
use warnings;
use File::HomeDir;
my $conf_dir = File::Spec-catdir( File::HomeDir-my_home, '.Foo' );
use Module::Build;
my $builder = Module::Build-new(
On Thu, 30 Mar 2006, Randy W. Sims wrote:
Note that the entries in install_path must have the same name as
supplied to add_build_element() (not with the '_files' appendage).
OK - thanks again, that is my problem... the naming of the entries...
I was too dense to appreciate your note about the
Well, the weakness I speak of is not so much that that it will never get
to the point of being stable, but that it introduces a temptation to
release early without taking the time to critically look at what might
go wrong, based on your knowledge of how it is implemented.
So more of a timing
Tels wrote:
Moin,
On Thursday 30 March 2006 17:32, Adam Kennedy wrote:
[snip]
Calling -method( \ ) or -method( \undef ) or -method ( sub { die
foo } ) and a dozen other things like that is intentionally provoking
that code into blowing up.
This are good things, but checking every param on
I would classify what Adam does as robustness testing.
Often the first release can be classified as working, in a perfect world.
Adam lives in a World of Evil.
Let me expand. For most of us (this means Not Adam), we work during the Day
and rest at Night. We don't call it Day and Not Day,
Randy W. Sims wrote:
Adam Kennedy wrote:
There are a number of ways to do this. The most simple is:
use strict;
use warnings;
use File::HomeDir;
my $conf_dir = File::Spec-catdir( File::HomeDir-my_home, '.Foo' );
Not that I wish to be a pedant about this, but only so people
we should keep this on list :)
Adam Kennedy wrote:
Geoffrey Young wrote:
Adam Kennedy wrote:
I'd also add a small warning in that Apache::Test does seem to want to
dominate the entire test suite (run everything from TEST) and so may not
be as suitable in cases where you have 50-500
Oops, didn't reply to all...
A-T is nothing if not flexible.
That the _option_ to trade off speed for flexibility isn't as easy as I
personally would like it to be, rather than that it doesn't address any
given known scenario.
really, I don't know what you're saying, but it sounds vaguely
ugh, sorry, WAY too early in the morning.
If the installer needs a module in order to run, it has nothing to fall
back on to supply that module for it. Any surrounding client doing a
recursive installation can't fix it, unless what it can do when the
installer runs and says that the
On 30 Mar 2006 07:02:21 -0800, Randal L. Schwartz merlyn@stonehenge.com wrote:
demerphq == demerphq [EMAIL PROTECTED] writes:
demerphq While apparently some on this list apparently dont favour this
demerphq approach, im pretty much at a loss to come with a better way to test
demerphq the
25 matches
Mail list logo
