I've started implementing namespace support in Tcl this week (yay!).
But I've run into a bit of trouble, so I have a couple questions:
The get_namespace opcode gets namespaces from the root namespace.
Should it get namespaces from the HLL namespace instead? The PDD isn't
explicit either way, but
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
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
I
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
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::*
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 some
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 module so
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 =
- 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 test
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 : Tests
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
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 from the
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
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
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
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 not
# New Ticket Created by Will Coleda
# Please include the string: [perl #39663]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39663
Need to:
1) Decide on perl coding standards (stealing from PBP)
2) implement a
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 { ?PGE::Util::die:
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 I
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
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 Pairs
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 Allocationfor dynamically compiled
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 implementations
28 matches
Mail list logo
