Kent, (or anyone really)
Can you point to any documentation that covers these env vars, and the best
practices you layed out? I have never even heard of the NO_NETWORK_TESTING
var, and considering what modules I maibtain that is worrysome.
I am not asking out of doubt, I want to educate myself, a
I personally would make it an author test that requires the AUTHOR_TESTING
env var.
I have apent too much time debugging network tests that fail because a file
moved, a domain was down/expired, or the connection was not sufficient, but
present. There are also corperate/school blacklists/whitelists
AM, David Golden wrote:
> On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum wrote:
>
>> I have a small objection to putting an alt module in a namespace other
>> than alt: It is less obvious. If I see Alt::Thing I will simply know it
>> will replace Thing.
>>
>
>
>
I think alt modules are fine.
I am fine with an env-var solution, BUT I am now ok with a single env var
that allows any alt module in. I would recommend either a standard such as
PERL_ALLOW_ALT_[MODULE_NAME], or PERL_ALLOW_ALT="Alt::One,Alt::2". I doubd
anyone wants to allow arbitrary alt modules
*bump*
This thread has produced very little chatter. Bumping the thread again
after talking to rjbs. Next week he and I are going to talk about next
steps. (Please do not read that as we will talk next week and release, that
is not intended, implied, or expected).
-Chad
will
not be taken as a seal of approval. That said, indefinite silence will also
not be considered a blocker past a point, but no time limits have been set
either way.
-Chad
On Feb 6, 2016 2:13 AM, "Kent Fredric" wrote:
> On 6 February 2016 at 08:14, Chad Granum wrote:
> > I
On October 29th, 2015, I released Test-Stream as stable. I did this because
I felt it was ready, and because I was no longer receiving any feedback from
perl-qa asking me to change things. Since that release, the feedback picked
up substantially. It seems that declaring something done is the best w
Been talking about this in #p5p, so far it seems the problem is the test is
fragile, and patching the test is fine.
On Mon, Jan 18, 2016 at 1:13 PM, Chad Granum wrote:
> So, new problem I have found based on the change to restoring $@, $!, and
> $?.
>
> perl-bleads ext/XS-APItest/t/
lling it
good, or is this actually a scary thing? If it is scary, then I would love
pointers on how I can actually preserve the internal state of the variables
as well as their value, but I would really prefer not to do that if I do
not have to.
-Chad
On Mon, Jan 18, 2016 at 12:39 AM, Aristotle P
typically desired behavior.
On Sun, Jan 17, 2016 at 9:53 PM, Chad Granum wrote:
> I can add a complex mechanism, or someone can just do this:
>
> sub modifies_err {
>> my $ctx = context();
>> ...
>> my $err = $@;
>> $ctx->releas
like the one above and
his response was:
->release; $@ = $err;
> oh, of course
> Ha, right. I'm dumb.
> Thanks!
-Chad
On Sun, Jan 17, 2016 at 9:41 PM, Aristotle Pagaltzis
wrote:
> * Chad Granum [2016-01-12 04:20]:
> > That said, it just occured to me that this can p
ble
> cost, but I would profile it.
>
>
> On Wed, Jan 13, 2016 at 7:50 PM, Kent Fredric
> wrote:
>
>> On 14 January 2016 at 07:39, Chad Granum wrote:
>> > Right now the version I have up on cpan just stores them on creation,
>> and
>> > restores
k on it. This should at least be in the
> commit messages so it could be tracked down.)
>
> S.
>
>
>
> On Tue, Jan 12, 2016 at 11:26 PM, Chad Granum wrote:
> > Yes, your understanding appears correct. And I can make it more clear.
> >
> > This is a very sim
Yes, your understanding appears correct. And I can make it more clear.
This is a very simple test tool in Test::Builder (the chrome):
my $TB = Test::Builder->new; # Call to internals/guts (singleton)
sub ok($;$) {
> my ($bool, $name) = @_;
> $TB->ok($bool, $name);# Call to internals
nd it will do it in a better way. New tools will not
need to start concerning themselves with this. Old tools never had to worry
as I was not going to break backcompat.
-Chad
On Tue, Jan 12, 2016 at 11:41 AM, Michael G Schwern
wrote:
> On 1/11/16 4:53 PM, Chad Granum wrote:
> > Test::More
The magic is already there, but it is there by localizing the vars in a ton
of non obvious places. Between that and having it done in one obvious and
documented place seems like a Much better option.
On Jan 11, 2016 7:21 PM, "Kent Fredric" wrote:
> On 12 January 2016 at 16:14, Chad
https://github.com/Test-More/Test2/issues/9
Issue created to do this the easy/efficient way.
On Jan 11, 2016 7:14 PM, "Chad Granum" wrote:
> Some things I forgot to mention:
>
> Test2, the dist, is just internals. It provides no tools. It does not have
> ok(), is(), etc. W
, "Chad Granum" wrote:
> Test::More/Test::Builder work VERY hard to ensure nothing inside them
> alters $! or $@. This is for thing like this:
>
> ok(do_something_scary());
>> is($!, 0, "expected $! val");
>> is($@, undef, '$@ not changed&
Test::More/Test::Builder work VERY hard to ensure nothing inside them
alters $! or $@. This is for thing like this:
ok(do_something_scary());
> is($!, 0, "expected $! val");
> is($@, undef, '$@ not changed');
Without Test::More/Builder being careful to support this, the second 2
asse
Created https://github.com/Test-More/test-more/issues/616 to track this
where more people can see it.
On Mon, Dec 21, 2015 at 8:58 PM, Chad Granum wrote:
>
>
> On Mon, Dec 21, 2015 at 5:10 PM, Karen Etheridge wrote:
>
>> > The problem is that parent_todo is not consid
On Mon, Dec 21, 2015 at 5:10 PM, Karen Etheridge wrote:
> > The problem is that parent_todo is not considered when setting the OK's
> in the details in subtests. That means if a subtest ok fails, and the
> parent is in todo, the 'ok' and 'actual_ok' are both set to false.
>
> Why is this a bug? A
Test::Builder appends all Ok's to a structure it can return via
$tb->details. These Ok's have the fields 'ok' and 'actual_ok'. 'actual_ok'
is the true/false value passed to $tb->ok, 'ok' is adjusted to be true if
the test was run under TODO.
https://metacpan.org/source/EXODIST/Test-Simple-1.001014
+2 And further, when we have that notification thing that lets people know
they have people using their stuff, when their module reaches a critical
number of things depending on it, we should recommend they link to it in
their POD, assuming they want to follow it.
On Tue, May 5, 2015 at 11:03 PM,
I don't think anyone ever regretted taking some extra time to test and
verify something critical before deploying it.
Thanks to the QA Hackathon I have gotten a lot of extra eyes and review to
look at what I have been working on. Many of you have probably noticed a
recent upswing in code churn and
Test::Stream will still have a no non-core dep policy, so depending on both
Test-Stream and Test-Builder effectively adds 1 dep, that is not burdensome.
On Sat, May 2, 2015 at 3:34 PM, Aristotle Pagaltzis
wrote:
> * Sawyer X [2015-05-02 23:05]:
> > Effectively what happened/happens is that, whi
Right now I am working on a branch that removes the legacy/backcompat stuff
that permeates Test-Stream. This is no small task, expect it sometime in
the next week or so. I am sticking with the Test::Stream namespace for now,
no reason to switch it at this point.
Once this branch is done we can sta
Looks like Test2 is already taken, which is odd considering a permission
check on pasue did not show it, but when I tried to upload something it
failed.
On Sat, May 2, 2015 at 1:28 PM, Kent Fredric wrote:
>
> On 3 May 2015 at 08:24, Chad Granum wrote:
>
>> I like the Test2
I like the Test2 Idea, mind if I upload a module real quick to first-come
the namespace? or are you going to claim it?
On Sat, May 2, 2015 at 1:22 PM, Aristotle Pagaltzis
wrote:
> * David Golden [2015-05-02 19:35]:
> > On Sat, May 2, 2015 at 11:11 AM, Kent Fredric
> wrote:
> > > That is, conce
Here is what I want to do.
I want to release a Test-Stream dist on cpan. It will say in its POD that
it is still experimental, largely because of this debate right now. This
release will not be tied to Test::Builder, Test::More, etc. There will be a
limited compatibility module people can choose t
I decided to start a new thread for this as the original one seems to have
forked multiple times.
This thread is related to https://github.com/Test-More/test-more/issues/589
alone.
David and I have both put some time into reproducing this, and I want to
put out a summary of my findings (I will le
Actually, try this one first:
On Thu, Apr 30, 2015 at 7:52 AM, Chad Granum wrote:
> I have attached 5 patches, can you try each one individually and see if
> any of them make your problem go away?
>
> Some of these patches will break Test-Simples test suite, Best option is
>
something I would put into the repo, they are
just to see if we can narrow down the problem.
On Thu, Apr 30, 2015 at 7:45 AM, Chad Granum wrote:
> I have no problem blocking on #589, so long as it remains actionable. We
> need to try to narrow down on the problem, and if possible reprod
I realize that it's hard to replicate and we may need to see if the
> problem crops up elsewhere for confirmation, but sporadic global
> destruction memory errors isn't something I want released to the world.
>
> David
>
>
> On Thu, Apr 30, 2015 at 1:27 AM, Chad Granum wr
_110 uploaded as expected, documentation changes only. Unless someone else
reports something that NEEDS to be fixed, nothing will be touched until
stable.
On Wed, Apr 29, 2015 at 9:52 AM, Chad Granum wrote:
> I do not consider Test-Stream to be experimental. I am also unhappy with
> the
I do not consider Test-Stream to be experimental. I am also unhappy with
the churn that has occurred, and recognize that it makes things hard for
people who are spot-checking me, specially since it means starting over.
- Changes up to and including _105 were directly a result of the
punchlis
I need some feedback on some concurrency related items regarding
Test-Stream.
*What you need to know:*
- Test-Simple legacy supported threads, but not forking
- Test::SharedFork adds for support, backcompat will be preserved
- Test-Stream supports threads and forking
- Test-Stream
36 matches
Mail list logo
