On Sun, 2 Mar 2008, James Keenan via RT wrote:
On Sun Mar 02 17:00:59 2008, [EMAIL PROTECTED] wrote:
do a checkout of the 'tcif' branch and call 'perl Configure.pl
--test=configure' with whatever command-line options you customarily use
in building Parrot in trunk, you will get a good
On Mon Feb 25 18:56:44 2008, doughera wrote:
At the
moment, it has the same problem as the previous design -- it's failing
to honor my command line arguments.
I believe I've spotted the problem. In
Parrot::Configure::Parallel::Trace::store_this_step(), the call to
process_options() is
On Sun Mar 02 17:00:59 2008, [EMAIL PROTECTED] wrote:
I believe I've spotted the problem. In
Parrot::Configure::Parallel::Trace::store_this_step(), the call to
process_options() is throwing away the command-line options. I'll try
to fix that.
This was fixed in r26183 in the 'tcif'
I've spotted a flaw in the way I revised each of the t/steps/*.t files.
Trying to match an exact (true) return value in the 2nd test is too
strict; will generate a failure if, after successfully completing
configuration, you go back and call 'prove' or 'perl -d' on an
individual test.
Am working
On Sun Feb 24 19:44:02 2008, coke wrote:
SNIP
All tests successful.
Files=261, Tests=3095, 84 wallclock secs ( 1.27 usr 1.69 sys + 25.98
cusr 13.99 csys =
42.93 CPU)
Result: PASS
normal config output
All tests successful.
Files=42, Tests=1149, 31 wallclock secs ( 0.31 usr 0.22 sys +
On Sat, 23 Feb 2008, James Keenan via RT wrote:
The patch attached, diff.trunk.tcif.txt, addresses both RT 47391
(t/configure/1*.t tests incorrectly rely on init::defaults_ and RT 47503
(Remove config::init::defaults From configure tests). It accomplishes
the following:
Thanks for working
On Mon Feb 25 13:09:04 2008, doughera wrote:
This sounds to me as if it assumes all the tests will be running in
order
every time.
For the most part, this is true. However, once we work out the kinks,
this will not be cause for alarm.
We want our tests to simulate the development of the
On Mon, 25 Feb 2008, James Keenan via RT wrote:
On Mon Feb 25 13:09:04 2008, doughera wrote:
This sounds to me as if it assumes all the tests will be running in
order
every time.
For the most part, this is true. However, once we work out the kinks,
this will not be cause for
On Mon Feb 25 18:56:44 2008, doughera wrote:
Yes. Exactly. I have been arguing that point for years. Every step
can involve triggers, or callbacks, which can invoke arbitrary code
and even change the results of preceeding steps. It is very much
history-dependent. I think the best disk
On Sat Feb 23 15:29:22 2008, [EMAIL PROTECTED] wrote:
The patch attached, diff.trunk.tcif.txt, addresses both RT 47391
(t/configure/1*.t tests incorrectly rely on init::defaults_ and RT 47503
(Remove config::init::defaults From configure tests). It accomplishes
the following:
* In the
On Thursday 15 November 2007 16:36:31 chromatic wrote:
Parrot::Config::Generated is a much more reliable source of information,
and if the tests truly need information about the local system for
compiling and linking purposes, they should fetch the information from
there, not from the Perl 5
chromatic wrote:
# New Ticket Created by chromatic
# Please include the string: [perl #47503]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47503
I've seen a lot of test failures under t/configure/*.t lately where
On Friday 16 November 2007 04:29:48 James E Keenan wrote:
chromatic wrote:
# New Ticket Created by chromatic
# Please include the string: [perl #47503]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47503
On Fri Nov 16 11:56:27 2007, [EMAIL PROTECTED] wrote:
I accept that. Until the point where these four tests are as reliable
as the
rest of the tests of the configuration system, can we mark them as
TODO? We
know they won't pass everywhere, and they're not giving us valuable
information
On Thu, 15 Nov 2007, chromatic wrote:
config::init::defaults pulls the libs setting out of the Perl 5 configuration
and various tests of the Parrot configuration process use
config::init::defaults to set up the environment for testing.
[it also pulls many other settings -- the compiler
Three tests cited as failing by adougherty have been placed in TODO blocks.
Apart from the *general* problem of relying too heavily on Perl 5'c
Config.pm (via init::defaults) for values during testing of the
configuration step tests, does the following accurately summarize the
reasons why *specific* tests are failing on your systems?
chromatic:
Is using a vendor-supplied
On Friday 16 November 2007 17:51:52 James Keenan via RT wrote:
Apart from the *general* problem of relying too heavily on Perl 5'c
Config.pm (via init::defaults) for values during testing of the
configuration step tests, does the following accurately summarize the
reasons why *specific* tests
# New Ticket Created by chromatic
# Please include the string: [perl #47503]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47503
I've seen a lot of test failures under t/configure/*.t lately where linking
failed
19 matches
Mail list logo
