Maybe slightly unrelated, but have you guys considered adding some
extra (optional) meta info to the TAP spec? For instance at $work,
we group our individual assertions into higher level tests like this:
# TITLE: Some test case
ok 1
ok 2 - awesome
not ok 3
I believe we also have an ACTI
Luke Closs wrote:
> Maybe slightly unrelated, but have you guys considered adding some extra
> (optional) meta info to the TAP spec? For instance at $work, we group
> our individual assertions into higher level tests like this:
>
> # TITLE: Some test case
> ok 1
> ok 2 - awesome
> not ok 3
Andy Lester wrote:
Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on
Test::Harness.
Finalize Test::Harness::Straps.
Make it possible to programatically run tests and to capture output. Eg.
Module::Build has need to run tests, displaying output as normal, but to
also capture that
Andy Lester wrote:
> Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on
> Test::Harness.
>
> Any bugs that we especially need to work on?
Not a bug, but a feature request. Abstract out the TAP parsing into a separate
module so that it can be done by more than just Test::Harness::* m
On Thursday 29 June 2006 07:13, Andy Lester wrote:
> Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on
> Test::Harness.
>
> Any bugs that we especially need to work on?
>
Well, giving my angle as the Test::Run maintainer (which is a fork of
Test::Harness):
1. I may have eliminated s
On Thursday 29 June 2006 13:27, Michael Peters wrote:
> Andy Lester wrote:
> > Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on
> > Test::Harness.
> >
> > Any bugs that we especially need to work on?
>
> Not a bug, but a feature request. Abstract out the TAP parsing into a
> separate
On Jun 29, 2006, at 5:21 AM, Randy W. Sims wrote:
Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on
Test::Harness.
Finalize Test::Harness::Straps.
That is THE reason we're doing this. Everything else is gravy.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:pe
- Original Message
From: Michael Peters <[EMAIL PROTECTED]>
> Not a bug, but a feature request. Abstract out the TAP parsing into a separate
> module so that it can be done by more than just Test::Harness::* modules.
I started that, but I hit three snags.
1. It would be very useful to
If it's not too late, I would really love to see the TAP output disambiguate
between diag() output and test failure output. I think it was Adrian who
suggested something as simple as:
not ok 52 - forced failure
# Failed test 'forced failure'
# in t/db_version.t at line 225.
# got:
- Original Message
From: Luke Closs <[EMAIL PROTECTED]>
> Maybe slightly unrelated, but have you guys considered adding some
> extra (optional) meta info to the TAP spec? For instance at $work,
> we group our individual assertions into higher level tests like this:
>
> # TITLE: Some
On Wed, Jun 28, 2006 at 11:13:02PM -0500, Andy Lester wrote:
> Tomorrow, Adam Kennedy and I (and Schwern?) will be banging on
> Test::Harness.
>
> Any bugs that we especially need to work on?
They're not so much bugs as structural annoyances that it would be useful
to relax to make subclassing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ovid wrote:
> sub some_test_case : Test(3) { my $test = shift; # same as $self,
> actually ok some_func(); ok another_func(), 'awesome'; is $answer,
> 42; }
Also for those of us who are fed up with counting tests manually:
sub some_test_case : Tes
On Jun 28, 2006, at 21:13, Andy Lester wrote:
Any bugs that we especially need to work on?
This might be Test::Builder, but I've seen many times on my Mac where
STDERR and STDOUT output is out of sync. For example, info about why
a test failed can be miles from the line where the "no ok" a
David Wheeler wrote:
> On Jun 28, 2006, at 21:13, Andy Lester wrote:
>
>> Any bugs that we especially need to work on?
>
> This might be Test::Builder, but I've seen many times on my Mac where
> STDERR and STDOUT output is out of sync. For example, info about why a
> test failed can be miles fr
I noticed a lot of people weighed in with non-bug posts to Andy's bug
fix request.
I just wanted to note that Wednesday we had a PITA/Test::Builder/Testing
BOF at which a bunch of people had an hour long talk about the structure
of Test::et-al TAP and various other topics. I think we addressed
On Jun 29, 2006, at 07:26, Michael Peters wrote:
This is a general problem with the way some of the testing modules
work.
Only because they all use Test::Builder's output methods.
This doesn't resolve the problem of non-test modules emitting
things to STDERR
that could be useful when track
Hi Adam,
I definitely realize that some of the feature requests do not seem like bugs,
but if some are easy to implement then I would think they should be worthy of
consideration. David Wheeler's complaint about unsynchronized test output is
definitely a bug and it's one I've been bitten by ma
On Thursday 29 June 2006 07:26, Michael Peters wrote:
> This is a general problem with the way some of the testing modules work.
> They output their diagnostic messages as comments to STDERR. They should
> send them instead to STDOUT so that it can be synced. TAP does support
> comments, so I'm no
# New Ticket Created by Will Coleda
# Please include the string: [perl #39663]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39663 >
Need to:
1) Decide on perl coding standards (stealing from PBP)
2) implement a .perlcr
On Wed, Jun 28, 2006 at 08:12:42AM -0500, Jonathan Scott Duff wrote:
> On Wed, Jun 28, 2006 at 04:26:45AM -0500, João Cruz Morais wrote:
> > - Can I use PGE skipping TGE?
>
> I don't see why not. If you look at the bottom of grammar_rules.pg,
> you'll see this:
>
> token syntax_error { }
>
> wh
> The build process for the current (Tue May 2 07:15:06 2006 UTC)
> parrot snapshot dies when trying to run compilers/pge/pgc.pir:
Is this still the case with later versions of Parrot -- i.e., can I
close this ticket?
Pm
On Thu, 29 Jun 2006, Patrick R. Michaud via RT wrote:
> > The build process for the current (Tue May 2 07:15:06 2006 UTC)
> > parrot snapshot dies when trying to run compilers/pge/pgc.pir:
>
> Is this still the case with later versions of Parrot -- i.e., can I
> close this ticket?
The last time
Lately I've been wanting to cross-apply features of the Set type to
the Mapping type, as well as of the Hash type to both of those, as I
see all of these as being very similar to each other conceptually and
in some cases interchangeable.
1. Looking at the language in Synopsis 6 for data types,
Darren Duncan wrote:
> 1. Looking at the language in Synopsis 6 for data types, I see:
>
> Set Unordered Seqs that allow no duplicates
> JunctionSets with additional behaviours
> PairSeq of two elements that serves as an one-element Mapping
> Mapping Pair
Author: audreyt
Date: Thu Jun 29 19:34:45 2006
New Revision: 9724
Modified:
doc/trunk/design/syn/S02.pod
Log:
* S02: kolibrie++ noticed that a heredoc without a semicolon is confusing,
so we reasserted the Perl5 semantics by a TimToady++ ruling.
Modified: doc/trunk/design/syn/S02.pod
=
Hi Everyone,
Currently IMCC uses a Graph Coloring based Register allocation algorithm.
The implementation is a trimmed down version of Brigg's Allocator.
I came across this research paper that talks about the new register
allocation algorithm "Linear Scan Allocation"for dynamically compiled
lang
On Thursday 29 June 2006 20:20, Vishal Soni wrote:
> Let me know what your thoughts are and would it be worth implementing this
> algorithm to see how it performs compared to graph coloring algorithm.
>
> Please share your thoughts accordingly
It'd be very useful not only to have two implementati
27 matches
Mail list logo
