http://mungus.schwern.org/~schwern/src/Test-Simple-0.48_02.tar.gz
A new alpha release of Test::Simple/More/Builder. You can consider this
the 0.49 release candidate. Please let me know how it goes.
There's a new feature. When run under Test::Harness diagnostic output will
throw in a leading
On Sun, Jul 18, 2004 at 10:50:59AM +0100, Tony Bowden wrote:
The two best ideas we've had so far are to either run the SQL in the
code against a temporary database, and then compare both SHOW CREATE
TABLE outputs, or to use something like SQL::Translator to convert both
lots of SQL to a common
On Mon, Jul 19, 2004 at 03:22:05AM -0400, Michael G Schwern wrote:
The two best ideas we've had so far are to either run the SQL in the
code against a temporary database, and then compare both SHOW CREATE
TABLE outputs, or to use something like SQL::Translator to convert both
lots of SQL
On Mon, Jul 19, 2004 at 10:19:47AM +0100, Tony Bowden wrote:
On Mon, Jul 19, 2004 at 03:22:05AM -0400, Michael G Schwern wrote:
The two best ideas we've had so far are to either run the SQL in the
code against a temporary database, and then compare both SHOW CREATE
TABLE outputs, or to
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #30737]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=30737
in platform.c I see:
int
Parrot_signbit(double x)
{
union {
double
I was finding that t/pmc/objects.t tests 40-45 were failing with a SIGBUS.
Running t/pmc/objects_40.imc
The stack backtrace revealed that the cause was jumping to a garbage address
in the call node-function in Parrot_exit:
void Parrot_exit(int status) {
handler_node_t *node, *next_node;
On Mon, 19 Jul 2004, Nicholas Clark wrote:
int
Parrot_signbit(double x)
{
union {
double d;
int i[2];
} u;
u.d = x;
#if PARROT_BIGENDIAN
return u.i[0] 0;
#else
return u.i[1] 0;
#endif
}
This is buggy. Even on an IEEE platform (which this seems to be
Short version: I'm considering dropping the exit code feature from the
default behavior of Test::Builder and making it something you can turn on
instead. Does anyone find this feature useful or otherwise wish to
protest its removal in 0.50?
Long version:
Test::More (and, in fact, most any
On 19 Jul 2004, at 07:25, Michael G Schwern wrote:
[snip]
There's a new feature. When run under Test::Harness diagnostic output
will
throw in a leading newline for better readability.
[snip]
Which causes anything testing test diagnostic output with
Test::Builder::Tester to fall over.
On Mon, Jul 19, 2004 at 04:25:35PM +0100, Adrian Howard wrote:
On 19 Jul 2004, at 07:25, Michael G Schwern wrote:
[snip]
There's a new feature. When run under Test::Harness diagnostic output
will
throw in a leading newline for better readability.
[snip]
Which causes anything testing
On Mon, Jul 19, 2004 at 04:25:35PM +0100, Adrian Howard ([EMAIL PROTECTED]) wrote:
Which causes anything testing test diagnostic output with
Test::Builder::Tester to fall over. Test::Class, Test::Exception
Test::Block's test suites now all fail.
Ooof, good catch. I'd really hate to have my
Nicholas Clark [EMAIL PROTECTED] wrote:
in platform.c I see:
int
Parrot_signbit(double x)
This is buggy.
This is generated platform code and overridable in platform/*/math.c
Better code for _signbit is of course welcome.
Nicholas Clark
leo
On Mon, Jul 19, 2004 at 04:25:35PM +0100, Adrian Howard wrote:
Which causes anything testing test diagnostic output with
Test::Builder::Tester to fall over. Test::Class, Test::Exception
Test::Block's test suites now all fail.
Pooh sticks.
My temptation is to say the new behaviour is
On Thu, 2004-07-15 at 22:46, Dan Sugalski wrote:
And language builtin namespaces in general. We need a standard, and
now's as good a time as any, so...
All language-specific builtin functions go into the _core_Language
namespace. (So for Python it's _core_Python, Perl 5 is _core_Perl5,
Rod Adams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Case 1:
So I wanted to do a read/write scan, so I create my TextFile, start
reading in data, so the file is opened for reading. Then, I come to the
part where I want to update something, so I do a write command. Suddenly
the
Nicholas Clark [EMAIL PROTECTED] wrote:
#2 0x000cbd58 in Parrot_default_destroy (interpreter=0x1000200, pmc=0x1017bb8) at
classes/default.c:189
#3 0x001f92dc in Parrot_deleg_pmc_destroy (interpreter=0x1000200, pmc=0x1017bd0) at
classes/deleg_pmc.c:143
Should be fixed now. destroy() isn't
Its a busy day here at the Its About Bloody Time Dept.
Test::More's repository is now publicly available. That's the good news.
The bad news is its Aegis which most of you have probably never used.
The good news is it has a very good web interface.
http://mungus.schwern.org/cgi-bin/aeget
As is part of my daily (to be read work day) routine,
I do a make realclean, a fresh CVS checkout, rebuild
parrot.
This morning I was noticing 2 problems
1. object tests 40-45 were blowing up - thanks to
Nicholas for pointing it out and Leo for fixing it
2. Almost everything but the most
On Mon, 19 Jul 2004, Adrian Howard wrote:
My temptation is to say the new behaviour is the right one and patch
T::B::T and friends?
The version of TBT in my subversion repository[1] now twiddles the
HARNESS_ACTIVE ENV variable off when it's collecting output for testing.
I'll release it to
... I hope is (inline) attached below
leo
1) Indroduction
Below [1] is a small test program, which basically shows the speed of
calling generators aka coroutines. But *what* I want to discuss isn't
restricted to calling coroutines. Its the same (more or less) with
calling any subroutine-like
Dave Whipp wrote:
Under the hood, I don't really care, as long as it works (and is
sufficiently efficient). There are obvious implementations that might be a
bit inefficient on the first iteration (e.g. close and reopen). Quite
frankly, the number of times I open unstructured files in rd/wr mode
At 9:40 PM +0200 7/19/04, Leopold Toetsch wrote:
Below [1] is a small test program, which basically shows the speed of
calling generators aka coroutines. But *what* I want to discuss isn't
restricted to calling coroutines. Its the same (more or less) with
calling any subroutine-like thingy, being
--- Rod Adams [EMAIL PROTECTED] wrote:
Dave Whipp wrote:
Your case 2 is easy: my Str $passwds is File(/etc/passwd) is
const. With that, we might even catch your error at compile
time.
/file/open/ and we're back where we started.
Except that we've lost a layer of abstraction: the
On 19 Jul 2004, at 20:30, Mark Fowler wrote:
On Mon, 19 Jul 2004, Adrian Howard wrote:
My temptation is to say the new behaviour is the right one and patch
T::B::T and friends?
The version of TBT in my subversion repository[1] now twiddles the
HARNESS_ACTIVE ENV variable off when it's collecting
On Friday 16 July 2004 14:40, Leopold Toetsch wrote:
Dennis Rieks [EMAIL PROTECTED] wrote:
Hi,
on my win32 tinderbox there is an missing file pmc_default.h while
compiling src/py_func.c, maybe an wrong -I include path? This file is
located in parrot/classes
No missing dependency.
Austin Hastings wrote:
--- Rod Adams [EMAIL PROTECTED] wrote:
I think part of the mental jam (at least with me), is that the
read/write, exclusive, etc, are very critical to the act of opening
the file, not only an after the fact restriction on what I can do
later.
But why? I'd argue
On Mon, Jul 19, 2004 at 07:40:01PM -0500, Rod Adams wrote:
: TMTOWTDI can apply here, I believe. You give me my way, I'll give you
: yours. Leave me open with all my parameters, and you can have your list
: of file abstraction classes. I could see having those classes part of
: core, if there's
Ph. Marek [EMAIL PROTECTED] writes:
This is obviously some new definition of Inf of which I was not
previously aware.
Well, after reading my sentence one more, I see what may have caused
some troubles. Inf is not in N; but *in my understanding* it fits
naturally as an extension to N, that
Dennis Rieks [EMAIL PROTECTED] wrote:
On Friday 16 July 2004 14:40, Leopold Toetsch wrote:
Dennis Rieks [EMAIL PROTECTED] wrote:
Hi,
on my win32 tinderbox there is an missing file pmc_default.h while
compiling src/py_func.c, maybe an wrong -I include path? This file is
located in
Joshua Gatcomb [EMAIL PROTECTED] wrote:
2. Almost everything but the most trivial JITed code
was coredumping.
That's then caused by turning USE_CGP on. Strange. Cygwin gcc must
produce different code then somehow, which breaks things. If you are
using gcc 3.0 or above,
On Mon, Jul 19, 2004 at 09:55:14PM -0400, Jonadab the Unsightly One wrote:
: It is possible to construct a group that includes infinities, but NI
: isn't it, and for Perl purposes it doesn't seem necessary.
Though if someone wants to hack surreals into 6.1, that'd be cool. :-)
Larry
31 matches
Mail list logo
