Jonathan Rockway wrote:
> SQLite handles concurrent users. Some people dislike the fact that row
> writes lock the entire table, though. This starts being a problem when
> you are getting around 10-100 million writes a day, according to the
> SQLite docs.
It does support that? I thought that as
Aristotle Pagaltzis wrote:
> * Geoffrey Young <[EMAIL PROTECTED]> [2008-01-14 17:05]:
>> it's useful to me because I say it is. personally I don't feel
>> the need to defend something many people would like to see this
>> like we're being forced to here.
>
> Yeah, agreed. Why is everyone so dogmat
Geoffrey Young wrote:
> schwern has a valid point in not wanting to lose
> diagnostics upon implementing this feature, but outside of that it
> wastes too many cycles going back and forth like this over what is a
> pretty minimal feature.
Stop wasting cycles arguing, and start posting patches
Matisse Enzer wrote:
Ok, why do you want to stop it as fast as possible when a failure
occurs?
>>> So I can more quickly focus on fixing that first test failure.
>> I use
>> make test 2>&1 | less
>> Works for individual tests too
>> make && perl -Mblib t/testname.t 2>&1 | less
> I don't
Matisse Enzer wrote:
>> Ok, why do you want to stop it as fast as possible when a failure
>> occurs?
> So I can more quickly focus on fixing that first test failure.
I use
make test 2>&1 | less
Works for individual tests too
make && perl -Mblib t/testname.t 2>&1 | less
Sam.
Michael G Schwern wrote:
> Paul Johnson wrote:
>> This is something that I too have asked for in the past. I've even
>> hacked up my own stuff to do it, though obviously not as elegantly as
>> you or Geoff. Here's my use case.
>>
>> I have a bunch of tests that generally pass. I hack something
>
Ovid wrote:
>> Why not just load Perl once and fork for the execution of each test
>> script. You can pre-load modules before you fork.
>
> Forking is also more likely to be used for parallelization. Often code
> requires sweeping changes before it can be run in parallel. So this
> means we're
Andy Lester wrote:
>>> If you have slow test suites, you might want to give it a spin and
>>> see
>>> if it helps. Essentially, it concatenates tests together and runs
>>> them
>>> in one process. Thus, you load Perl only once and load all modules
>>> only once.
>> Yuck.
>
>
> I think this
Ovid wrote:
> If you have slow test suites, you might want to give it a spin and see
> if it helps. Essentially, it concatenates tests together and runs them
> in one process. Thus, you load Perl only once and load all modules
> only once.
Yuck.
Why not just load Perl once and fork for the exec
Sam Vilain wrote:
> I just gave the cg- commands initially because I didn't want to write
> this git-core equivalent in public:
> mkdir perl
> cd perl
> git-init
> git-remote add catalyst git://git.catalyst.net.nz/perl.git
> git-config remote.catalyst.f
Michael G Schwern wrote:
>> cg-branch-add p4-perl git://git.catalyst.net.nz/perl.git#p4-perl
>> cg-fetch p4-perl
>> cg-switch p4-perl
>>
> cg-switch: refusing to switch to a remote branch - see README for lengthy
> explanation; use cg-seek to just quickly inspect it
>
Oops, yea
Sam Vilain wrote:
> You can add them all as branches with that cg-branch-add command then
> suck them all down with a big cg-fetch command. Another option is to
> just grab the lot with "git-clone".
Forgot to say, that's almost a 200MB download at the moment.
> Act
Michael G Schwern wrote:
> Sam Vilain wrote:
>
>> Try this (after installing cogito):
>>
>> cg-clone git://git.catalyst.net.nz/perl.git#restorical
>> git-log -p t/TEST
>>
>
> Thanks, but that only gets me up to August of 1996. Where's th
Michael G Schwern wrote:
> We're in the process of adding a version number to TAP (ya know, ok 1, not
> ok 2) and I'm trying to figure out what version number we're actually at.
> I've been tracing back through the features added since Perl 1 but things
> are a bit jumbled.
>
> I'd like to pick bra
14 matches
Mail list logo
