Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-24 06:10]:
> The "5.even as devel" period is very short. CPAN authors should
> be made aware of how their code works with release candidates.
> That's a period when problems are likely to be for real.

Agreed: it’s very unlikely there’ll be huge changes in bleadperl
once its minor version bumps up to an even number.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Proc::Fork on Windows

[A. Pagaltzis]

* Christopher H. Laco <[EMAIL PROTECTED]> [2007-12-21 18:40]:
> All tests pass: Strawberry Perl 5.8.8/XP

Thanks Chris. On its way.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Proc::Fork on Windows

[A. Pagaltzis]

* David Golden <[EMAIL PROTECTED]> [2007-12-19 17:30]:
> It looks like it does (as long as you remove the "-T" from the
> shebang in 01.real.t.

Anyone with Windows who cares to, please bang on
http://plasmasturm.org/attic/Proc-Fork-0.5.tar.gz
before I send it to the CPAN.

Thanks again for tracking this down, David.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Proc::Fork on Windows

[A. Pagaltzis]

Hi David,

thanks for taking a gander!

* David Golden <[EMAIL PROTECTED]> [2007-12-19 16:35]:
> As I've reported elsewhere, Perl on windows has what I call the
> "taint-fork bug" -- forking while under taint just segfaults.

Ugh.

> With a little more poking around, the problem lies in your
> modification of @_ and use of goto &_do_fork.

That was a desperate guess; the previous version just returned
the $config hash and used DESTROY to trigger the fork when it
went out of scope. I blindly guessed that object destruction
across threads might be causing the problem, so I tried to get
rid of the hash before the fork.

> Changing the relevent lines to
> 
>   my @args = @{ $config}{ qw( parent child error retry ) };
>   undef $config;
>   _do_fork(@args);
> 
> passes all tests. You lose the nice callstack, but it doesn't
> segfault. I'm guessing that's really an issue with goto and
> pseudoforks or threads on Windows.

Does it continue to pass if you replace the first line with

my ( $p, $c, $e, $r ) = @{ $config }{ qw( parent child error retry ) };

and then inline the body of `_do_fork`?

(Logically, it should, but this utterly undebuggable problem has
made me a bit superstitious…)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-12-19 13:40]:
> I'll have a look :)

Whoa. I guess Ovid is right, after all!

> Is the version on CPAN the one to try?

Yeah. It segfaults on the “fork for real” test (in both AS and
Strawberry; both 5.8).

Regards,
-- 
Aristotle Pagaltzis // 

Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

[A. Pagaltzis]

* Elliot Shank <[EMAIL PROTECTED]> [2007-12-19 08:10]:
> In particular, I've been using them to test my attempts at
> fixing Perl::Critic on perl 5.6, which I've never been able to
> compile/pass tests on my Macs.

I wish someone would help me fix Proc::Fork on Windows. I got
two tickets about it and a bunch of Testers failures, but several
attempts to make it work have failed and my repeated pleas have
fallen on deaf ears.  :-(

I’ve closed the tickets as stalled and am tempted to say “it don’
work on Windows” (using the now existing Devel::CheckOS I guess),
and leave it at that.

Regards,
-- 
Aristotle Pagaltzis // 

Re: What's the point of a SIGNATURE test?

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2007-12-15 19:10]:
> thus every tarball of every distribution should contain
> everything necessary to take over maintainership of a module.

It is a reasonable position, really, so long as you don’t stretch
it to absurd lengths. If there is something *unusual* involved in
the construction of a release of the module, then the code that
performs that task absolutely should be part of the distribution.

> I say that people who want to know what the silly POD-checking
> tests look like should be able to find a thousand verbatim
> instances on the CPAN

My first act in office as new maintainer (be it ownership change
or fork) is often to throw out its toolchain plumbing and install
the infrastructure I prefer.

Regards,
-- 
Aristotle Pagaltzis // 

Impotent disclaimers (was: Milton Keynes PM coding collaboration)

[A. Pagaltzis]

Hi Tony,

* Edwardson, Tony <[EMAIL PROTECTED]> [2007-12-14 08:55]:
> And are willing to let us improve coverage ?
> 
> ** 
> This is a commercial communication from Commerzbank AG.
> 
> [20 lines snipped]
> 
> **

is there any chance you could subscribe this list using an
address whose outgoing mail server does not feel the need to
append 25 lines of legally ineffectual lawyeristic mumbojumbo
to a one-line mail?

Free mail accounts are easy to come by in this day and age…

Regards,
-- 
Aristotle Pagaltzis // 

Re: package Outer::Space; use Test::More tests => 9;

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-06 06:35]:
> Right now you have to write this:
> 
>   use Test::More;
> 
>   if( $^O eq 'SomeOS' ) {
>   plan skip_all => "Tests don't apply to SomeOS":
>   }
>   else {
>   plan tests => 3;
>   }
> 
> It's ugly and verbose and the decision to skip all has to come
> before you do any testing at all.

Btw, I always do that like this:

use Test::More;
  
plan $^O eq 'SomeOS'
? skip_all => "Tests don't apply to SomeOS"
: tests => 3;

This is still a little more complex than the `skip_rest` version,
but much less ugly than what you showed, and if this is a test in
Regexp::Common and about to skip 14,291 assertions, it’s probably
preferrable to use `skip_all` even if `skip_rest` is slightly
simpler…

That’s my only comment. Your plans are good (pun intended).

Regards,
-- 
Aristotle Pagaltzis // 

Re: Why not run a test without a plan?

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-06 05:05]:
> no_plan already has all these issues and the sky remains firmly
> fixed in the heavens. Header-at-end TAP is still streamable.
> You don't have to read the whole document before you can get
> information.

Sure. You just have less information during on-the-fly processing
that might be important or even just handy in some situations.

> It doesn't close off any testing situations, and it makes quite
> a few more much simpler.

It absolutely makes some things simpler. It also makes others
harder. It’s a tradeoff. I was just calling to allow test authors
to weigh the sides for themselves when they run into a case that
exposes the issue.

> A. Pagaltzis wrote:
> > But streamability isn’t important in that most common use
> > case, so it probably shouldn’t be the default, which is why I
> > opined that maybe Test::More should be strict on request but
> > not by default.
> 
> Sorry, I must have missed that. Your example code up to this
> point looked like it required the user to declare up front that
> they were going to put a plan later.

Well that *is* what I was referring to.

> Having the author declare in the test that they'd like
> Test::More to be strict with the plan seems near useless. If
> you're going to declare that you have to declare a plan, why
> not just declare the plan?

Whenever you have a reason to call `plan` instead of
declaring the plan on the `use` line, you need to ensure that
some inadvertently placed BEGIN block doesn’t mess things up.
Your suggested Test::Builder->must_have_plan flag would work
just fine for that. Whoever needs it can make sure to flip it
at the appropriate time, via Test::MustHavePlan or however.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Why not run a test without a plan?

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2007-12-05 18:20]:
> but maybe a Test::MustPlan (complete with syntactic-sugar for
> the annoying BEGIN thing.)

That would be a good option. That way Test::More wouldn’t
be loaded down with ever more bloat, and whoever has a need to
ensure plan-first TAP streams can implement it without arguing
with anyone else about whether it makes sense to have that.

Ponies and sunshine for everyone.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Why not run a test without a plan?

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 15:00]:
> I'm going to keep drilling through the BS until I either hit
> bottom or punch through.

Yeah, we’re all spouting bullshit. Gee, some tone you’re setting.

> About all that's different when the plan is at the end is the
> TAP reader doesn't know how many tests are coming until the end
> of the test. Then it can't display the expected number of tests
> while the test is running.

Not only can’t it do anything display-wise, but the harness also
can’t do anything else that requires knowing the projected plan
up front. It can’t abort the test as soon as the first extra test
runs. If the test dies, the harness doesn’t know how many tests
were pending. A system whose job is to continuously run lots of
tests in parallel can’t do nearly as much useful asynchronous
reporting.

> Unfortunate, but hardly a showstopper.

Whether or not it’s a showstopper is for the harness author
to judge and not for you. It’s not hard to imagine cases where
better streamability is important, even if they’re not garden-
variety `./Build test` scenarios. We’re championing TAP as a
solution for a wide variety of scenarios, right?

But streamability isn’t important in that most common use case,
so it probably shouldn’t be the default, which is why I opined
that maybe Test::More should be strict on request but not by
default.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Why not run a test without a plan?

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 04:30]:
> Why do they care if the plan is output at the beginning or end?
> How does this stricture improve the quality of the test?

It improves the resulting TAP stream, if not the test itself.

But maybe it’s not necessary to impose this stricture by default,
and instead of asking to be allowed to supply a plan later, as I
proposed, people should instead have to ask for the stricture:

# works:
use Test::More;
pass();
plan tests => 2;
pass();

# throws error:
use Test::More 'ensure_plan_first';
pass();
plan tests => 2;
pass();

> Honestly all that's really holding that up is a good name for
> the plan style and "I'm done testing" terminator.  Nothing has
> really lept out at me yet. Maybe something as straight forward
> as...
> 
>   plan 'until_done';
> 
>   
> 
>   done_testing;

plan 'until_completion';
# ...
plan 'completed';

Regards,
-- 
Aristotle Pagaltzis // 

Fixing Test::Class (was: Why not run a test without a plan?)

[A. Pagaltzis]

* Adrian Howard <[EMAIL PROTECTED]> [2007-12-05 10:45]:
> There are design mistakes that I regret. Only some of them can
> be fixed without breaking backwards compatibility.

Maybe time to put Test::Class on ice and fork an incompatible
successor?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Why not run a test without a plan?

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-04 11:05]:
> A. Pagaltzis wrote:
> >* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-04 03:35]:
> >> It also makes it technically possible to allow the test to
> >> change it's plan mid-stream
> > 
> > Without some hypothetical future version of TAP this is only
> > possible if you have run tests before declaring a plan at
> > all, because otherwise the plan will already have been output
> > as the first line of the TAP stream.
> 
> Just needs a way to declare that you're going to add to the
> plan up front.

That would work. Of course once you have that, you don’t need to
allow assertions to run without a plan, since one can always say

use Test::More tests => variable => 0;
pass();
plan add_tests => 2;
pass();

instead of

use Test::More;
pass();
plan tests => 2;
pass();

which would still be an error. That way a mistake in a test
script won’t lead to Test::More silently converting an up-front
plan declarations into trailing ones.


* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-04 11:10]:
> Smylers wrote:
> > Wasn't there general agreement only a week or so ago to now
> > allow plans to be specified at the end rather than the start?
> > I was presuming that Schwern's suggestions were in the light
> > of this other change.
> 
> No, that was a much more involved thing which involves nested
> plans and multiple plans and such.

Actually, what I remember was about Ovid asking about adding a
way to say “I don’t want to decide on a plan yet but I’ll supply
one later.” AndyA brought up the nested test stuff in the course
of that thread but that issue was not central to Ovid’s RFC.

Essentially it was the same discussion as this one.


Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Why not run a test without a plan?

[A. Pagaltzis]

Hi Michael,

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-04 03:35]:
>   use Test::More;
>   pass();
>   plan tests => 2;
>   pass();
> 
> Why shouldn't this work? Currently you get a "You tried to run
> a test without a plan" error, but what is it really protecting
> the test author from?
> 
> Historically, there was a clear technical reason. It used to be
> that the plan had to come first in the TAP output, so a plan
> had to come before any tests were run. Simple.
> 
> But that technical restriction no longer holds true. The plan
> can come at the end, primarily used for "no_plan". If a test is
> run before the plan is declared, simply delay the plan output
> until the end.

Yes, so this should be allowed:

pass();
plan 'no_plan';
pass();

Whereas this should not:

pass();
plan tests => 2;
pass();

So the error would be deferred from the first assertion run to
the `plan` invocation.

Consider also:

pass();
plan skip_all => 'Surprise!';
pass();

> It also makes it technically possible to allow the test to
> change it's plan mid-stream

Without some hypothetical future version of TAP this is only
possible if you have run tests before declaring a plan at all,
because otherwise the plan will already have been output as the
first line of the TAP stream.

> Since the technical restriction is gone, and I see no
> particular benefit to it being there, and it eliminates some
> tricky plan counting situations, I don't see why it shouldn't
> be removed.

Because declaring a plan after running tests is effectively a
no_plan and the programmer should be aware that that’s what they
did. It’s fine if that’s their conscious choice; just make sure
it was.

Regards,
-- 
Aristotle Pagaltzis // 

Re: shouldn't "UNEXPECTEDLY SUCCEEDED" mean failure?

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-04 03:00]:
> So I read two primary statements here.
> 
> 1) Anything unexpected is suspicious. This includes unexpected
>success.
> 
> 2) Anything unexpected should be reported back to the author.
> 
> The first is controversial, and leads to the conclusion that
> TODO passes should fail.

The first doesn’t seem controversial to me; everyone agrees, I
think, that passing TODOs merit investigation in some sense or
other.

> The second is not controversial, but it erroneously leads to
> the conclusion that TODO passes should fail.

The second one wasn’t primarily proposed that I could see at all.
Some people brought it up, but it was not a particularly central
part of the discussion.

Eric mentioned asking the author, as part of investigating TODO
passes (which as I mentioned I think we all agree about). That
seems like a reasonable position to me; how it implies that TODO
passes should count as failures, I don’t understand.

> So what we need is a "pass with caveats" or, as Eric pointed
> out, some way for the harness to communicate it's results in
> a machine parsable way.

I thought that was already the overall thrust of the discussion.

I agree completely, in any case.

> Maybe "Result: TODO_PASS" is enough.

WFM.

Regards,
-- 
Aristotle Pagaltzis // 

Re: shouldn't "UNEXPECTEDLY SUCCEEDED" mean failure?

[A. Pagaltzis]

* Ovid <[EMAIL PROTECTED]> [2007-12-02 16:50]:
> Breaking the toolchain is bad.

You can almost imagine Curtis murmuring those words even in
his sleep…

Regards,
-- 
Aristotle Pagaltzis // 

Re: Providing command-line arguments to tests run via 'prove'

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-11-30 02:35]:
> Let's use ++ instead of '--color' because its syntactically
> clean and visually distinct.  Or ;; for --merge.

Except there’s no good precedent for sentinel values whereas
there are clear precedents for switches. find(1) uses `;` and
`+`. Other tools use other stuff (I know that I know at least
one more example that I can’t remember right now).

> :: doesn't even suggest "pass through the following to the
> test" even after its been explained.

I was originally going to suggest a single colon. That certainly
seemed inherently suggestive to me:

prove -rb foo/ bar/ : http://localhost:2342

Now remember that a colon (single or double) can’t possibly be a
file name on a large portion of the systems that Perl runs on.
That would seem to me like an instant clue that something else is
going on.

So I don’t think it’s quite as devoid of any suggestiveness
outside of context as you make it out to be.

The reason I proposed a double colon instead is that the single
colon is rather visually demure and gets lost in the shindig of
a long command line. The “can’t be a filename” clue still holds
for that case, although it’s less obvious what the symbol might
be expressing.

> Because of this, :: is among a class of poorly designed
> controls you have to learn by rote.

So how are you going to pass switch-like test file names to
`prove`, which is the customary meaning of `--`? Are you going
teach people they should learn a *different* sentinel that “acts
like what `--` would act like if we weren’t using `--` for this
other tool-specific functionality”? Is rote *un*learning better
than rote learning?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Providing command-line arguments to tests run via 'prove'

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2007-11-30 01:35]:
> This means buzzword#42 (simplethingssimple-hardthingspossible)
> where the complicated (aliases, wrappers, etc) case is like:

YAGNI.

We already have other ways to make hard things possible. “Hard
things possible” does not imply “using exactly the same mechanism
as for simple things.” Passing information to tests via `%ENV`
has always been possible f.ex., and now we have `--exec` for the
heavy duty stuff. I see this proposal as a way to cover the
majority of ultraminimal parametrisation needs *only*.

Ie. I’d switch to `%ENV` at the point where I started thinking of
putting `use Getopt::Long;` in my `.t` files. Or I might use a
combination of `%ENV` and [EMAIL PROTECTED] (because putting lists of
things in env variables suffers from quoting issues).

In any case, given a mechanism to do the hard things, I think it
perfectly fine to have another simpler mechanism that refuses
to be all things to all people if that is the price for staying
simple.

* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-30 01:45]:
> If you want to be able to flip flop in and out of test args and
> prove args modes just repeat it and say that tests can't use
> '::' as an arg.
>
> $ prove -rb :: gargoyle :: --state=hot,save,all :: splendour :: t/spog.t

Please no. That’s unreadable. Let’s just do the simplest thing
that could possibly work and then leave well enough alone; see
above argumentation.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Stateful prove

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-29 23:25]:
> On 29 Nov 2007, at 22:09, A. Pagaltzis wrote:
>> Why this mental overhead? Do they really have to be ordered?
>> Is there any way that any other order would do anything
>> remotely useful? Would `save,fail,all` be useful? Or
>> `all,save,fail`? Every order I can think of besides the one
>> you gave is pretty useless in an order-sensitive scheme.
>
> Sure - in that case. But
>
>  failed,todo,all
>
> would do something sensible and distinct from
>
>  todo,failed,all

Aha. I see; those were examples that hadn’t come up before. So
ordering is useful to avoid an explosion of options. At the same
time, there is a bunch of aspects where order sensitivity clearly
does not make sense: does save,todo,failed do something useful?
Or todo,save,failed? Or all,failed,todo or all,todo,failed?

There is also Eric’s inquiry about how composed commands line,
eg. from aliases, would be handled.

Hm. I think this needs more thought…

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Stateful prove

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-29 16:10]:
> $ prove --state=fail,all,save
>
> ?
>
> (option order matters, 'fail' adds the failed tests to the run
> queue, 'all' adds everything, list is de-duped so the failures
> run first, saved for next time)

Why this mental overhead? Do they really have to be ordered? Is
there any way that any other order would do anything remotely
useful? Would `save,fail,all` be useful? Or `all,save,fail`?
Every order I can think of besides the one you gave is pretty
useless in an order-sensitive scheme.

So I think the order of actions should be predetermined, in which
case I’m with Eric – I think these should be regular options.
Plus, I don’t think it’s very descriptive to use `state` in the
names of the options at all. So that would be something like:

--save-fails
--only-fails
--fails-first

For grouping purposes, just give them single-letter aliases, eg.
`-S`, `-O`, and `-F`.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Providing command-line arguments to tests run via 'prove'

[A. Pagaltzis]

* Philippe Bruhat (BooK) <[EMAIL PROTECTED]> [2007-11-29 15:30]:
> Mmm, maybe I like ++ over ::. And -- should be kept meaning
> what it already means.

I think `++` is a legal filename on Windows, as opposed to `::`.
(But I haven’t a Windows box here to check, so if someone else
can confirm…)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Providing command-line arguments to tests run via 'prove'

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-29 04:02]:
> I agree re the semantics of '--' - but I'd rather have a
> sentinel than a quoted string. Having to get nested quoting
> right is a bit of cognitive load we can spare people from.
>
> So:
>
> * Andy's --testargs has the disadvantage of being visually
>   indistinct from regular args
> * '--' has another meaning by convention
>
> How about some other short, not arg like, shell safe punctuation sequence?
>
> $ prove -v t/sprocket.t -+ --teeth 12

How about a double colon?

$ prove -v t/sprocket.t :: --teeth 12

It’s quite unlikely that anyone would name a test file `::`. In
fact no one who has to care about Windows at all (which would be
everyone who isn’t writing (Linux|Mac|BSD)::* modules) would want
to do that because on Windows you *can’t* name a file `::`.

(A single colon would do just as well, but might get visually lost
in a long `prove` invocation.)

Regards,
-- 
Aristotle Pagaltzis // 

Re: BackPAN mirror owners: please delete Finance::FuturesQuote

[A. Pagaltzis]

* Jan Dubois <[EMAIL PROTECTED]> [2007-11-28 02:50]:
> This has come up before (e.g. the WWW::EuroTV removal request
> in 2003). I still have the same opinion I had back then:
> 
> | I think this discussion is missing the point. It should not
> | be: "What can we legally get away with?", but "Do we have the
> | courtesy to respect the wishes of publishers of
> | information?", even if their wishes might not be legally
> | enforceable.
> |
> | Since this is about Perl advocacy, I would like to quote a
> | bit of Perl culture: "It [Perl] would prefer that you stayed
> | out of its living room because you weren't invited, not
> | because it has a shotgun."
> |
> | I think the same rules should apply for screenscrapers too:
> | If website owners don't want their pages to be scraped, then
> | people shouldn't do it and get their information elsewhere.
> | It is like honoring a robots.txt file. It is probably not
> | enforceable, but it is the right thing to do.

Mostly, I agree. However, there are a number of courtesies in
play here beyond the one you mention. Note that we are talking
about many more parties than just the site owners and the author
of the module. We are also talking about CPAN administrators and
the CPAN mirror adminstrators. It is more than courteous of all
of them not to take action against the interests of a module
author on behalf of a third party without verifying the third
party’s demands as legitimate and reasonable.

“My freedom ends where yours begins” goes both ways.

Also, your quote about the shotgun very much applies: the
site owners sent a Cease and Desist. If they escalate to legal
weapons, I am inclined to respond by examining their demand on
legal grounds. If instead they *asked* the module author to
please remove the module, and the module author himself in turn
*asked* the CPAN administrators and CPAN mirror administrators to
respect his wish to comply with the wish of the site owners, that
would make for a very different situation and I would be readily
willing to forgo formalities.

But Paul Grinberg has yet to surface to say anything for himself,
and while it may well be that the site owners tried asking him
first, I can only go by the fraction of the story that I know
about.

Regards,
-- 
Aristotle Pagaltzis // 

Re: BackPAN mirror owners: please delete Finance::FuturesQuote

[A. Pagaltzis]

* David Landgren <[EMAIL PROTECTED]> [2007-11-27 17:45]:
> PLEASE TRIM FOLLOW-UPS TO PERL-QA ONLY.

How on Earth is this topical on perl-qa? I’m replying to perl-qa
despite Michael’s request because that’s where the thread now is,
but sensible this ain’t.

> The author of this module has received a cease-and-desist
> letter from the owner of the web site, since the module is in
> violation of the Terms of Use.

Does the module violate their ToS or its use? In all possible
case?

> All publicly accessible BackPAN mirrors must pull this
> distribution manually, given that rsync-without-delete
> won't do it for you.

Why? Assuming the answer to first question is that the module
itself violates the ToS, do all publicly accessible BackPAN
mirrors reside on jurisdictions where the ToS is valid and the
legal repercussions of its violation applicable?

> I don't know of any better way of reaching potential backpan
> admins, if anyone has a good suggestion I'm all ears.

Maybe you should have done that *before* spamming unrelated
lists?

The sky is not falling. Slow down and gather your wits. If the
site owners’ demand is in fact legitimate, this should be handled
through applicable venues and procedures. Breathless panic and
suspension of due diligence is inappropriate.


* Dominique Quatravaux <[EMAIL PROTECTED]> [2007-11-27 18:00]:
> http://kilimandjaro.dyndns.org/~dom/FuturesQuote-0.01.pm
> 
> Come on now. I have no idea whether that thing is any good,
> but these scare tactics from The Man are just silly.

* Jonathan Rockway <[EMAIL PROTECTED]> [2007-11-27 18:10]:
> I recommend we delete the AUTHOR information and distribute
> this module on thepiratebay. I will definitely seed the
> torrent.

Gee, you’re some rebels. Haven’t you people grown out of puberty
yet?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Speeding up long-running test suites

[A. Pagaltzis]

* Ovid <[EMAIL PROTECTED]> [2007-11-23 18:30]:
> Test::Class can speed up your your tests by ensuring that perl
> and related modules are loaded only once. I was thinking about
> how this could be done with normal .t files

http://search.cpan.org/dist/PPerl/ ?

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // 

Re: Dropping 5.5 support from my modules.

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-11-20 20:50]:
> If there is some hidden, silent cache of dedicated 5.5 users
> out there, maybe this announcement will flush them out.

Question is only, “flush them out” in what sense… :-)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Deferred Plans

[A. Pagaltzis]

* Adrian Howard <[EMAIL PROTECTED]> [2007-11-20 16:25]:
> I don't get this. Why is saying "I know this test script
> outputs 8 test results" at the start better than saying it
> at the end?

I assume that if you knew up front how many tests you are going
to run, then you’d just say it.

So you’d defer the plan in cases where the number of tests is
predetermined but maybe hard to precompute, or where it’s
variable. So in both cases you are calculating the number at run
time, which is immediately subject to more bugs than providing a
constant.

Additionally, it’s more likely for a bug in the calculation to
line up with a bug in the corresponding test code, so that you
end up with a plan that matches the number of tests run even
though you *intended* to run fewer/more tests.

And lastly, even a runtime-calculated predeclared plan separates
the test code and calculation code at least in time (while
running) and probably also in space (in the source code).
Therefore it seems to me that bugs are somewhat less likely
to line up.

So a deferred plan should be used only if you really can’t
determine the number of tests ahead of time or it is *very*
hard to do so.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Deferred Plans

[A. Pagaltzis]

* Andy Lester <[EMAIL PROTECTED]> [2007-11-20 00:10]:
> But what if something blows up before getting to the deferred
> plan? Then you don't know.

How could you *not* know? The TAP stream says “I’m gonna supply
a plan at the end, I just don’t know how many tests I’m going to
run yet.” How would the harness miss the fact that the promised
plan never materialised?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Deferred Plans

[A. Pagaltzis]

* Andy Lester <[EMAIL PROTECTED]> [2007-11-19 23:17]:
> I guess I'm not seeing why a deferred plan is better than no
> plan at all.  

At a minimum, because the harness expects a plan. If you exit
prematurely, it can at least detect that no plan was given,
whereas if you test without a plan, it knows nothing at all.

And beyond that, you still declare intent and the harness can
compare with actual behaviour. A buggy set of tests is more
likely to align with the count than it might with an up-front
plan, but not with complete certainty – whereas if you test
without a plan, the harness, once again, knows nothing at all.

A deferred plan is clearly not as good as a predeclared plan,
but is definitely much safer than no plan at all.

Regards,
-- 
Aristotle Pagaltzis // 

Re: New proposed CPANTS metric: prereq_matches_use

[A. Pagaltzis]

* brian d foy <[EMAIL PROTECTED]> [2007-11-15 22:40]:
> If Straps is the only thing that you use, then that's the only
> thing you should list. If Straps has dependencies, it lists
> those.
> 
> Test::Prereq would see what the Straps distro provides and only
> remove those from the prereq list. If Straps doesn't provide
> anything else, it doesn't remove anything else.
> 
> I'm not sure why you think it's some other way.

I don’t know what exactly Test::Prereq does. I checked the docs
but they don’t say precisely how it behaves.

Anyway, irrespective of what ::Prereq does, here’s what I mean:

# found in Something.pm
use Test::Harness;

# found in Other.pm in the same distro
use Test::Harness::Straps;

This distro should list Test::Harness *and* Test::Harness::Straps
as dependencies, even though (at the time of writing) they are
both in the same distro.

Another example:

use Params::Validate;
use Scalar::Util;

This distro should, again, list both Params::Validate *and*
Scalar::Util as prereqs – even though Params::Validate also
depends on Scalar::Util. At some point in the future, P::V
might cease to depend on S::U, but *this* distro will still
depend on it.

So in order to make everything work robustly, distros should
explicitly list every single module they explicitly use – no
shortcuts, no implications.

Regards,
-- 
Aristotle Pagaltzis // 

Re: New proposed CPANTS metric: prereq_matches_use

[A. Pagaltzis]

* brian d foy <[EMAIL PROTECTED]> [2007-11-13 21:10]:
> In article <[EMAIL PROTECTED]>, David
> Cantrell <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 12, 2007 at 10:53:42PM +0100, A. Pagaltzis wrote:
> 
> > and:
> > 
> > " Foo::Bar is in distribution AUTHOR/Foo-Bar which also
> >   contains Foo::Bar::Baz, so I only need to declare one of
> >   them to get both. "
> > 
> > This is also an error, as Foo::Bar::Baz might be moved into a
> > seperate distribution at some point in the future
> 
> Well, that's why you check the current distribution to see what
> it provides. I do this in Test::Prereq.

Consider Test::Harness::Straps getting released as a separate
distro recently. Any modules that only use ::Straps but list
Test::Harness as a prereq will now fail to install. If ::Straps
were listed as a dependency, installation would continue to Just
Work. So if you use any module from the CPAN, you should list it
explicitly, not imply it via the main module of its containing
distro.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: New proposed CPANTS metric: prereq_matches_use

[A. Pagaltzis]

Hi Thomas,

* Thomas Klausner <[EMAIL PROTECTED]> [2007-11-12 21:10]:
> The metric will be called prereq_matches_use and shall check if
> all the modules used in a dist are also listed as a prereq.
> (prereq is either gatherd directly from Meta.YMLs 'requires',
> by parsing Build.PL or Makefile.PL)

sounds great to me.

> This results in: Of 12039 dists, 5419 have missing deps

If a sizable fraction of these are in fact valid hits and not
just false negatives due to the trickiness of the problem, then
I would say the metric is direly needed!

> Adiitionally, there is a lot of potential finetuning possible:
> 
> - do not award the kwalitee point if there are too many listed
>   prereqs (i.e. the dist requires another dist, without
>   actually using it.) This might be controversial, because
>   authors could lists dists as a prereq which are a prereq of a
>   prereq (etc) - for various valid (?) reasons...

-1. At most this should be an optional metric, but even then it’s
likely as not to be harmful.

> - also check build_requires (I'm not sure if other buildtools
>   than Module::Build support this), with this twist: If dists
>   are only used in tests, but are listed in 'requires', do not
>   award a kwalitee point.

+1

Regards,
-- 
Aristotle Pagaltzis // 

Re: Mad TAP proposal

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-01 15:50]:
> The config needs to be dynamic at test time - so it might as
> well be a script that runs and outputs a description of which
> tests to run, right?

But it only needs to be dynamic in a minority of cases. So it
seems to me it should be the other way around – rather than run
a script to emit the config, have a config that has a directive
to run a script and include its output as part of the config.

That makes it easier for other tools to analyse the test configs.

> So isn't that nearly TSP? :)

In some ways. I just don’t think the harness should look at the
output of tests to check if it’s TSP rather than TAP. The list of
tests to run should be determined up front, and the test scripts
should only ever output TAP.

Mixing them with scripts that output TSP feels like a confusion
of concerns to me.

For the configs there are also a number of issues like dealing
well with multiple possible configurations and resolution of
relative paths (esp. in compound configs).

I think this needs a little bit more design. And since YAML is
making its way into TAP anyway, maybe it should be YAML-based
rather than a completely ad-hoc TAPish format?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Mad TAP proposal

[A. Pagaltzis]

* Michael Peters <[EMAIL PROTECTED]> [2007-11-01 15:15]:
> Sounds to me like it should just be a custom test harness. If
> the user needs to dynamically figure out which tests to run,
> then why not create a custom harness which will do what they
> need.

I was going to say the same. Then it occured to me that if you
want to make such a harness reusable and you want to make the
test plans introspectable, then such a harness needs to parse
some sort of config. Which is very nearly what TSP is.

I just don’t see the “protocol” part. I’d rather think of it in
terms of the Test Plan Configuration format, and that this be
something specific to TAP::Harness rather than documented widely
as something common to TAP implementations. It veers into
operational questions that I don’t think are applicable to every
scenario where TAP is in use. Because…

> This way they can have control over not only which files to
> run, but which routines (if they're using Test::Class), etc,
> etc.

… TAP encompasses scenarios where the notion of files and test
routines doesn’t even compute.

> Writing your own harness is trivial now. I'd say writing
> something to emit a new protocol is no easier than writing a
> script that picks the test files/subs to run.

Agree. Putting this sort of functionality in the default harness
*is* a good idea so people don’t need to reinvent a common wheel,
and so you can use a declarative language to define this sort of
thing. But just make this a config for TAP::Harness.

Regards,
-- 
Aristotle Pagaltzis // 

Re: how to get archname

[A. Pagaltzis]

* Mark Stosberg <[EMAIL PROTECTED]> [2007-10-31 02:20]:
> Michael Peters wrote:
> > use Config;
> > $Config{archname}
> 
> If you just need to see it and don't need to use it directly in
> Perl, you can also just:
> 
> perl -V  | grep archname

You mean

perl -V:archname

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle

Re: Overriding CORE::GLOBAL::print

[A. Pagaltzis]

* Matisse Enzer <[EMAIL PROTECTED]> [2007-10-27 21:20]:
> I suppose we need to bite the bullet and just find and replace
> all the calls to 'print' with something else.

Select a tied filehandle? Not efficient… but quick to add.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Devel::CheckLib: Please try to break our code!

[A. Pagaltzis]

* David Cantrell <[EMAIL PROTECTED]> [2007-10-22 13:40]:
> I hope, however, that the CP6AN will make it obsolete by
> having:

And as an aside, 6PAN will hopefully have a `configure_requires`
mechanism right out of the gate; its hitherto absence from the
Perl 5 toolchain is a critical hole.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Devel::CheckLib: Please try to break our code!

[A. Pagaltzis]

* demerphq <[EMAIL PROTECTED]> [2007-10-21 16:50]:
> A) The contents of META.yml is not well or widely documented.
> That META-spec-blead in the Module::Build source code
> repository does mention it does not make it well publicized nor
> documented. About the only people who would know about it are
> META.yml wonks and active developers on the MB project.

Support has been in CPAN.pm for no more than three or so months,
if memory serves, and the toolchain is not (as you found out)
ubiquitously aware of this option yet. So the fact that this
feature is barely documented by anyone is less than surprising.
Give it a bit of time so everyone can catch up.

> B) Absent a documented way to set this in MakeMaker, suggesting
> that it is the appropriate solution to the problem intended to
> be solved by Devel::CheckLib seems out of place at best, and
> presumptive at worst.

Huh? As I understood Eric’s mail, he suggested configure_requires
solves the bootstrapping problem where a Makefile.PL itself has a
dependency on Devel::CheckLib that it can’t communicate before it
runs. And that’s precisely the scenario that configure_requires
was invented to solve.

> As an aside, it seems to me that both Devel::CheckLib and
> configure_requires suffer from a fatal flaw in that they do not
> solve the problem for existing modules. The solution to this
> problem lies in better logic in CPAN Testers.

Well, sure. Makefile.PL/Build.PL can do anything whatsoever, of
course. But once we solve the halting problem, CPAN Testers will
be trivial to fix… ahem. Devel::CheckLib and configure_requires
make things more declarative, so in combination with a better
protocol for CPAN Testers, would allow to fix *some* problems
going forward. It does not seem realistic or even possible to me
to fix them *all*.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Devel::CheckLib: Please try to break our code!

[A. Pagaltzis]

* demerphq <[EMAIL PROTECTED]> [2007-10-19 23:10]:
> On 10/19/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> > * demerphq <[EMAIL PROTECTED]> [2007-10-19 18:50]:
> > > How does one use this then? Where is it documented?
> >
> > http://module-build.sourceforge.net/META-spec-blead.html#configure_requires
> 
> So how do i use this with MakeMaker?

Doesn’t seem like you can do that from within MakeMaker so far.

However you can certainly hand-edit your META.yml to add it. Once
created the meta file is not regenerated if you don’t ask for it,
I think.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Devel::CheckLib: Please try to break our code!

[A. Pagaltzis]

* demerphq <[EMAIL PROTECTED]> [2007-10-19 18:50]:
> How does one use this then? Where is it documented?

http://module-build.sourceforge.net/META-spec-blead.html#configure_requires

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle

Re: Running CPAN as a regular user, installing as root

[A. Pagaltzis]

* Matisse Enzer <[EMAIL PROTECTED]> [2007-10-18 19:35]:
> From your shell prompt:
>
>   sudo cpan

No, if you used to use CPAN.pm as root, then instead say this:

sudo tar cf - .cpan -C ~root | tar xvf - -C ~
sudo rm -r ~root/.cpan

The first line simply produces a copy of .cpan from ~root in your
own home directory, but owned by yourself. (Basically a more
transactional way to do `cp -R && chown`.)

After that, replace all references to ~root in
.cpan/CPAN/MyConfig.pm with references to your own home, eg.

perl -pi~ -e'BEGIN{$root=shift} s/\Q$root/$ENV{HOME}/' ~root 
.cpan/CPAN/MyConfig.pm

Then you can invoke `cpan` as a regular user right away in order
to make your config changes.

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle

Re: Q: Build.PL/Makefile.PL, and CPAN testers...

[A. Pagaltzis]

* David Golden <[EMAIL PROTECTED]> [2007-10-01 18:30]:
> So if CPAN.pm 1.92XX goes into 5.10, then there *will* be
> a CPAN client in core that knows when to upgrade itself. We
> don't need CPANPLUS for that.

Yeah, OK. Still, it would be nice if both of them had feature
parity here, because people will tend to use one or the other,
not really both.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Q: Build.PL/Makefile.PL, and CPAN testers...

[A. Pagaltzis]

* Jos I. Boumans <[EMAIL PROTECTED]> [2007-10-01 00:00]:
> Currently, we're doing VMS portability fixes and last bits to
> prepare it for 5.10, after that, i'm happy to look into this
> with the interested parties.

Is this really something we want to push *another* X months/years
out? In the near future 5.10.0 would be the best chance to gain
an installed base quickly. Having the CPAN client in the core
capable of upgrading itself is something we’ve needed for the
better part of a decade. (Anyone remember CPAN::MakeMaker?)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Bug fix in Test::More 0.71 may reveal failures tests

[A. Pagaltzis]

Hi Adrian,

* Adrian Howard <[EMAIL PROTECTED]> [2007-09-17 17:50]:
> Just in case... you do know about CPAN::Mini::Extract yes?

wow, no, I didn’t know about that. Very cool, I’m glad I couldn’t
be bothered to do the job manually before I went to sleep. Now
I don’t need to do much of any work at all. :-)  Especially so
because where ::Extract puts things is almost exactly where
I would have put them too.

Alias++

Regards,
-- 
Aristotle Pagaltzis // 

Re: Bug fix in Test::More 0.71 may reveal failures tests

[A. Pagaltzis]

* David E. Wheeler <[EMAIL PROTECTED]> [2007-09-17 19:25]:
> On Sep 17, 2007, at 03:55, A. Pagaltzis wrote:
> 
> >• SVN::Notify (html.t)
> 
> use_ok() is not in a BEGIN block in that file, so it should be
> fine, yes?

Oh yeah, sorry. I confirmed the Google Codesearch hits by looking
up the current versions on CPAN and checking if the problem still
exists, but mainly looked for where the `plan` call is, and
rarely checked whether `use_ok` had been taken out of BEGIN in
the meantime.

You are fine.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Bug fix in Test::More 0.71 may reveal failures tests

[A. Pagaltzis]

* Thomas Klausner <[EMAIL PROTECTED]> [2007-09-17 14:30]:
> cpants takes ~ three hours to unpack each dist and run
> cpants_lint on it.

Hmm, that sounds eminently doable. If no one else pipes up,
I’ll probably do a run tonight.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Bug fix in Test::More 0.71 may reveal failures tests

[A. Pagaltzis]

* Jonathan Rockway <[EMAIL PROTECTED]> [2007-09-17 13:20]:
> Your method was much better than my "try installing stuff I
> need and see what fails" technique :)

If anyone has a CPAN grepper script they could do an even better
job with less effort than it took me. (It was incredibly
tedious.)

I am wondering how long it would take to unpack just over 700MB
of tarballs (my minicpan archive) and run `ack` over the lot…

Regards,
-- 
Aristotle Pagaltzis // 

Re: Bug fix in Test::More 0.71 may reveal failures tests

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-15 16:05]:
> Test::More 0.71 fixed a subtle bug where a call to use_ok()
> inside a BEGIN block without a plan would be silently ignored.
> That is...
> 
>   use Test::More;
> 
>   BEGIN { use_ok('Exporter') }  # for example
> 
>   plan tests => 1;
>   pass();
> 
> would pass when it should have failed.  This commonly takes the
> form...
> 
>   use Test::More;
> 
>   if( ...something we need isn't there... ) {
>   plan skip_all => "Missing something";
>   }
>   else {
>   plan tests => 2;
>   }
> 
>   BEGIN { use_ok('Some::Module') }
> 
> Even though the use_ok() comes after the plan() in the code, it
> gets run before because of the BEGIN block.  If your code does
> the above, it won't work anymore.
> 
> This has already effected two modules, and one of them is DBI.

Let’s see…

http://www.google.com/codesearch?q=lang%3Aperl+%22use+Test%3A%3AMore%3B%22+%22BEGIN+%7B+use_ok%22

About 170 hits after dupes; most of the hits are bogus, but about
40 are bullseyes. Confirmed kills:

• AIX::Perfstat (disk.t)
• Business::BR::Ids (002_cpf_test.t 015_pis_test.t)
• Cache::FastMmap (6.t)
• CGI::Application::Plugin::LogDispatch (singleton.t)
• CGI::Application::Plugin::TT (04_singleton.t)
• CGI::Uploader (up_table_map.t)
• Data::FormValidator::FromDBI (01-generator.t)
• Date::Span (from_unit.t)
• DBD::Sybase (place.t)
• DBIx::AsForm (basic.t)
• DBIx::LazyMethod (MySQL.t)
• DBIx::Simple (sqlite.t)
• DTS (AssignmentTypes.t)
• Gaim::Log::Parser (002DateTime.t)
• HTML::DBTable (02__DBSchemaPatched.t)
• HTML::TableParser (contents.t)
• Image::MetaData::JPEG (JPEG_0_records.t JPEG_1_segments.t JPEG_2_JPEG_class.t)
• jsFind (04words.t)
• Mail::Audit (shorthand.t)
• Mail::SpamAssassin::SimpleClient (result-spam.t)
• Mail::Toaster (maillogs.t)
• Net::FTPSSL (10-complex.t)
• Oracle::Debug (oradb.t)
• POE::Component::SNMP (20_snmp_getnext.t 60_errors.t)
• Purple (api.t)
• RDF::Sesame (98-debug.t)
• sapnwrfc (06test_data_z.t 08deep_z.t)
• Search::Estraier (5_Node.t)
• Solaris::Disk::Mnttab (05half-calls.t)
• Solaris::Disk::VTOC (15size2.t)
• SVN::Notify (html.t)
• Test::MinimumVersion (pod-coverage.t)
• Text::Aspell (05-core.t)
• Text::Capitalize (003-captitle-preserve_whitespace.t)
• Tuxedo::Admin (1.t)
• WWW::Ofoto (14-upload_lots.t)

I’ve added the authors of those modules to To: on this mail.

Regards,
-- 
Aristotle Pagaltzis // 

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-07 14:40]:
> I'm down with changing it to MUST for TAP meta and MAY for
> diagnostics.

Works for me.

Regards,
-- 
Aristotle Pagaltzis // 

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-07 06:40]:
> We're not prohibiting other formats, just establishing a
> baseline.

I think we specifically want to prohibit other formats in TAP
metainformation. For app data, we could advise authors to use the
same format, but I don’t think 

> It's mostly to avoid the mess of...
> 
>   02-03-1997  Is it Feburary 3rd, 1997 or March 2nd, 1997?
> 
>   01-02-03Jan 2nd, 2003 or Feb 1st, 2003 or maybe Feb 3rd, 2001!
> 
>   3:023:02 am or pm?  In what time zone?
> 
>   Thu Sep  6 21:32:19 PDT 2007Oh great, I'm supposed to parse this?

If it’s app data, then the answers to these questions are all up
to the app author. We can’t protect people from themselves, and
we can certainly not tacitly tell them that they’re violating
best practice if they’re working with existing code or standards
that use awful datetime formats.

> The TAP datetime proposal is a *recommended* format. It says...
> 
> "TAP recommends that TAP output should follow the following
> standard for dates and times."
> 
> "should" and "recommend" are as RFC 2119.

Ouch. An RFC 2119 SHOULD is a *strong* exhortation to follow the
recommendation. Basically it says “stray from this requirement if
you insist, but if things break you have no one to blame but
yourself – don’t come crying to us.”

I *really* don’t think TAP should make dictates on that level on
app data formats.

> Which is to say, most people will just follow the TAP datetime
> standard when outputting dates. If you really need to use
> another datetime format, go ahead.

Seriously, I think we should be silent about which datetime
formats people use in app data. For TAP metainformation,
conversely, the format choice should be REQUIRED not just
RECOMMENDED.

SHOULD is costly and should be avoided in favour of MUST or MAY
wherever possible – we had this discussion we had frequently in
the Atom WG. Over time, given enough implementations, any given
SHOULD tends to be treated as either a MAY or a MUST anyway.

That reasoning leads me to conclude that we can reduce the cost
of this SHOULD over time by making it no formal requirement at
all for app data and a MUST for TAP metainformation right off the
bat.

Regards,
-- 
Aristotle Pagaltzis // 

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-06 23:40]:
> For example, let's say you're testing some Biblical software
> and want to make sure you got your dates right.
> 
> not ok 1 - age of the Earth
> 
>   found:  -050-02-12
> wanted: -4004-10-23
> 
> This is, admittedly, an edge case and I'm being overly
> conservative.

I don’t think you’re overly conservative when it comes to app
data, but I agree with Ovid that this is bad separation of
concerns. How dates in app data are handled should be up to the
app to define. I think we should restrict this proposal solely to
datetimes in TAP metainformation.

(The alternative would be to push the concern to the YAML layer
and define a datetime data type down there. That would work. But
TAP is the wrong layer for this.)

> If RFC3339 is forward compatible with ISO8601 then I'm happy.
> We can start simple and upgrade to ISO8601 if RFC3339 proves
> too restrictive.

I am not certain of this, but my understanding is that RFC 3339
datetimes are always valid ISO 8601 datetimes also; that RFC 3339
is a profile of ISO 8601. Certainly there’s nothing you can
express in RFC 3339 format that you can’t also express in
ISO 8601 format.

> Does RFC 3339 permit the following?
> 
>   2007(just the year)
>   2007-09 (just the year and month)
> 
> I'd like tests to be able to specify individual years and days
> without having to resort to a "2007-01-01" convention. It
> doesn't seem like its format allows year-date. I admit, a nit.
> 
> It also looks like we'll have to explicitly allow just
> full-date and just full-time.

RFC 3339 is explicitly about instant-in-time information, so no,
it does not allow shorthands like that.

Is there a use case in TAP for saying “this happened on day
so-and-so” or “it happened at time so-and-so”, but omitting the
time or date (respectively), rather than just providing a full
datetime in all cases? Or even say “it happened in 2007” with no
further qualification?

(Remember, the app’s date format should be up to the app; I’m
asking purely about metainformation in the TAP. Some apps will
quite obviously need this for their data, but that’s a different
kettle of fish.)

> > What RFC 3339 means by current era is that the year in the
> > date cannot exceed AD (nor go lower than AD). Do you
> > forsee any problems with that? Will generated TAP have to
> > denote events in 1AD or beyond, or events farther in the
> > past than AD?
> >
> > It should be noted that as far as I can tell from any ISO
> > 8601 docs I can find, it does not permit more than 4 digits
> > for the year anyway. So the two standards don’t in fact seem
> > to differ on this point.
> 
> ISO 8601:2004(E) 4.1.2.4 gives a way to expand the year
> representation both beyond  AD and before 0 AD
> 
>   -0100-04-20
> 
> That's April 20th, 1 million BC.
> 
> But that section has the caveat "by agreement".

Ah. But you don’t answer the question whether there’s need for
cases like that in the metainformation. (Again, not in the app
data; it’s clear that there will *sometimes* be a need for that
there.)

Regards,
-- 
Aristotle Pagaltzis // 

Re: TAP datetime (was Re: Current state of TAP::Diagnostics)

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-04 23:35]:
> A. Pagaltzis wrote:
> > Actually ISO 8601 gives many more options than RFC 3339,
> > which is why the latter was written in the first place. See
> > 5.3 (“Rarely Used Options”) in RFC 3339.
> 
> That's why I'm inclined to go with one based on ISO 8601 rather
> than just RFC 3339. More possibilities for expression.

Yes, and therefore more possibilities for confusion, because most
people write against sample data from a running system and never
look at specs. So minimising variability maximises
interoperability. That’s what RFC 3339 section 5.3 talks about.

> If they're really not useful and just complicate matters I'm
> quite open to being convinced otherwise.

OK; the goal here, I think, is to make TAP as simple as possible
to generate as well as consume, without limiting expressiveness
unnecessarily.

As far as I can see, there is no appreciable difference in the
complexity of generating datetimes in either format.

There is quite a bit of difference on the consumption end.

Timezone information in RFC 3339 is numeric only. This obviates
the need for a long mapping table in parser code, and makes a
coarse validation of the datetime very easy – even at a human
glance.

RFC 3339 also does not permit omitting the day-of-month. Only
seconds and fractions of a second are optional, and if the
fractions are included, seconds must also be, so the only
optional part is always at the end of the string, before the
timezone. Thus, datetimes with the same timezone can be sorted
correctly with just a string compare. And accounting for the
timezone prior to sorting isn’t hard since it’s just a numeric
offset anyway.

ISO 8601, conversely, has a number of ways to express a single
date. You can base dates off the week number instead of the
number, or write them with day-of-year with no middle component
at all. As far as I can tell, this mainly makes it easier to
generate dates when dealing with long-duration processes.
Comparing or sorting such datetimes *requires* date math.

The question is, do we need that flexibility? As far as I can
tell, datetimes in TAP would almost always denote instants in
time, not durations nor long-duration recurring events, and it
will always be easy to come up with the current month and
day-in-month. When timespans have to expressed, it seems to me
they will be such that expressing them as a starting instant in
time and an ending instant will be perfectly adequate.

So it seems to me we’ll do the world a favour if we don’t force
every future consumer of TAP to deal with the whole of ISO 8601,
when (I dare predict) almost everyone will use no more than an
RFC 3339-ish subset of the format anyway. 

RFC 3339 datetimes are so simple that you can write a regex off
the top of your head and it’ll parse them correctly on the first
try. Sorting is so easy you can write a few more lines of code
and it too will work correctly on the first try. In contrast,
ISO 8601 datetimes require a real parser and a date math library.

> What specifically turned me off to RFC 3339 is that all dates
> had to be in the current era. That works for a communications
> protocol where the date is describing current events (like "I
> sent this message at"), but not so much for a data interchange
> format.

How? What RFC 3339 means by current era is that the year in the
date cannot exceed AD (nor go lower than AD). Do you
forsee any problems with that? Will generated TAP have to denote
events in 1AD or beyond, or events farther in the past than
AD?

It should be noted that as far as I can tell from any ISO 8601
docs I can find, it does not permit more than 4 digits for the
year anyway. So the two standards don’t in fact seem to differ
on this point.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Current state of TAP::Diagnostics

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-02 09:31]:
> YAML has data types.
> http://en.wikipedia.org/wiki/YAML#Data_Types
> 
> Both implicit
> 
>   - 3 # integer
>   - "3"   # string
>   - 123.0 # float
> 
> And explicit
> 
>   - !!float 123   # float
>   - !!str   123   # string
> 
> It can even do binary and user defined data types.

Good. That issue is cleared up then.


* Ovid <[EMAIL PROTECTED]> [2007-09-01 21:17]:
> Can I really keep a straight face and tell a C programmer that
> the "Test Anything Protocol" deliberately chose a serialization
> language that ignores data types?

Well, you’re not writing an emitter for C, are you?

It’s important to be sure that the serialisation format supports
types for other languages, but we don’t have to use that support
in the Perl TAP emitter, because those distinctions are without a
difference in Perl anyway.


* demerphq <[EMAIL PROTECTED]> [2007-09-01 23:51]:
> On 9/1/07, Ovid <[EMAIL PROTECTED]> wrote:
> > Workarounds for this issue are listed, but that still puts us
> > in the position of needing a pure-perl, core method of
> > disambiguating integers, floats, and strings.
> 
> No. I thought I already said this, but apparently not.
> 
> There Is No Difference.

Not for Perl, but there is for other languages. Insofar I
understand Ovid’s concern, and I agree with him that it’s
important to keep in mind. Luckily, as Michael writes, YAML has
what we want, so we’re done. And I agree that for Perl we don’t
need to care, nor should we.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Current state of TAP::Diagnostics

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-02 09:32]:
> What you're thinking of is RFC3339 which is more describing a
> state of affairs on the Internet then anything else.

Actually RFC 3339 date and time formats are best practice at the
IETF/IESG.

> At best it can be *omitted* (not replaced with a space) if all
> parties agree, which we can do because we're specifying the TAP
> format. But it cannot be replaced with a space and still called
> an ISO 8601 datetime.

So specify an RFC 3339 datetime.

> Since RFC3339 isn't really a clear standard

Actually ISO 8601 gives many more options than RFC 3339, which is
why the latter was written in the first place. See 5.3 (“Rarely
Used Options”) in RFC 3339.

> it's simpler to just say that a TAP date is an
> [isodate " " isotime].  We can even say that it can also be an
> [isodatetime], but recommend the former for readability, and
> everybody wins.

You might want to look at what we did in RFC 4287:

3.3. Date Constructs

A Date construct is an element whose content MUST conform to
the "date-time" production in [RFC3339]. In addition, an
uppercase "T" character MUST be used to separate date and
time, and an uppercase "Z" character MUST be present in the
absence of a numeric time zone offset.

Such date values happen to be compatible with the following
specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827],
and [W3C.REC-xmlschema-2-20041028].

You could pretty much adopt the same language, except for
requiring a space in place of the `T`.

The resulting date format would require a `-MM-DD` date and a
`HH:MM:SS` time in 24-hour format plus timezone offset (no
parsing TZ name strings either, numeric offsets only or a `Z` for
UTC), with optional `.nn` fractional seconds part (any number of
digits permitted).

I happen to think that datetime format is just about perfect.

Regards,
-- 
Aristotle Pagaltzis // 

Re: TAP YAML diagnostics

[A. Pagaltzis]

* Ovid <[EMAIL PROTECTED]> [2007-09-03 21:20]:
> If string data was *always* quoted and numeric data never was
> (assuming it's really numeric),

Fine with me.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Win32:GuiTest

[A. Pagaltzis]

* Smylers <[EMAIL PROTECTED]> [2007-09-01 19:31]:
> James E Keenan writes:
> > Gergely Brautigam wrote:
> 
> > > Does anybody know why is that so that sometimes when trying
> > > to set a focuse to a window the window does not come into
> > > forground but it stays on the menubar and just blinks...?
> > > Is that a windows problem or a Win32 module problem?
> > 
> > Hi Gergely.  Glad to have you aboard.  But please let me
> > suggest that there are probably better lists on which to pose
> > this question. perl.qa is very focused on use of Perl in
> > testing and Quality Assurance.  So questions on Win32 are off
> > topic here.
> 
> The subject of this thread is Win32::GuiTest -- I know nothing
> about it, but given it's a module for use with testing it seems
> on-topic for this list.

Nevertheless I think James’ advice is good – the issue is not
off-topic here, but it’s a Windows focus issue, and answers are
much more likely to be forthcoming on Perl-Win32-Users than here.

Regards,
-- 
Aristotle Pagaltzis // 

Re: TAP YAML diagnostics

[A. Pagaltzis]

Hi Michael,

* Michael G Schwern <[EMAIL PROTECTED]> [2007-09-01 19:32]:
> On 9/1/07, Fergal Daly <[EMAIL PROTECTED]> wrote:
>> On a tangent, I think using quotes is important otherwise you
>> end up output like
>>
>>   wanted: elbow
>>   found: elbow
>>
>> when what you really needed was
>>
>>   wanted: 'elbow'
>>   found: 'elbow '
> 
> No need to quote everything, just when there's leading or
> trailing whitespace to clarify. YAML.pm does that
> automatically. In fact, I don't think you can express leading
> or trailing whitespace without quotes in YAML.

Is it possible to force this in tandem? Ie. when one of the keys
has to be quoted, the other is always quoted also? Because I’d
hate to see this:

  wanted: elbow
  found: 'elbow '

For simple cases like this one it’s livable, but if the data gets
more complex, then comparing a raw string with a quoted one will
unnecessarily sprain people’s brains.

Regards,
-- 
Aristotle Pagaltzis // 

Re: add points for registered namespaces

[A. Pagaltzis]

* Christopher H. Laco <[EMAIL PROTECTED]> [2007-08-20 14:50]:
> Do we even register namespaces any more?

I registered Sub::ArgShortcut just a few months ago. When I
release a 1.0 of XML::Atom::SimpleFeed I’ll register that too.

> If I'm wrong, then I'd like to register a few then, like Handel.

Go ahead.

Regards,
-- 
Aristotle Pagaltzis // 

Re: a "standard" place for extra tests

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2007-08-17 05:15]:
> As for the 'xt' name: it tends to sort pretty soon after 't',
> as in 'these come next'. I think anything starting with 't'
> would get annoying as far as tab-complete goes. Similarly, 't2'
> might conflict with primitive version-control habits.

Those arguments would indicate that it should be `tt`. That’s
equally short, sorts far closer to `t` than `xt`, precludes the
need for tab completion, and does not get in the way of primitive
version control.

Regards,
-- 
Aristotle Pagaltzis // 

Re: a "standard" place for extra tests

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2007-08-18 02:25]:
> Part of my original point is that it would be useful[1] to
> define a standardized mapping of what functionality or
> resources are required to run typical subsets:
> 
>   author: some pod testing, kwalitee, etc prereqs
>   network: network access
>   gui: a gui

What about author tests for the GUI? Or tests that need both the
network and a GUI?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Summarizing the pod tests thread

[A. Pagaltzis]

* A. Pagaltzis <[EMAIL PROTECTED]> [2007-08-03 09:08]:
> I’d suggest `aut_t`.

Err, `auth_t`.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Fixing the damage caused by has_test_pod

[A. Pagaltzis]

* Andy Lester <[EMAIL PROTECTED]> [2007-07-30 22:30]:
> On Jul 30, 2007, at 2:46 PM, A. Pagaltzis wrote:
> >
> >>Certainly, the intent is to have boilerplate.t NOT get
> >>shipped with  the module.
> >
> >Disagree. The tarball should contain the full source necessary
> >to recreate everything the author did. Stuff that’s not
> >relevant to end-user installation of the module should simply
> >be kept out of the way.
> 
> You can't disagree.  It's a statement of fact that RJBS and I
> did not  intend for boilerplate.t to actually get shipped with
> the module.

I can’t disagree with the fact that this is what you intended,
but I can and do disagree with what you intended.

If the original author feels the boilerplate test is no longer
necessary, then not shipping the file is an automatic consequence
of deleting the file from his own source tree. If the original
author feels the boilerplate test might be useful again in the
future, and hence does not delete it from his own source tree,
then it should ship with the distro as an author test.

There is no good reason to special-case the boilerplate test.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Summarizing the pod tests thread

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2007-08-01 05:25]:
> David Golden wrote:
> >* Alternatives -- Eric Wilhelm suggests putting these tests in
> >at/ and running them with prove.  Likewise, Module::Build and
> >ExtUtils::MakeMaker could have targets added that run tests in
> >an "at/" directory as another way to encourage the practice.
> >(Module authors who want such targets can upgrade without ever
> >affecting end-users)  Lobby Ken Williams and Schwern.
> 
> A small nit, if we end up converging around the use of a
> relatively standard directory name, can we at least use
> something relatively self-evident? For example "author/"?

I’d suggest `aut_t`. Shorter than any alternative and still more
self-explanatory than most.

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle

Re: Fixing the damage caused by has_test_pod

[A. Pagaltzis]

* David Golden <[EMAIL PROTECTED]> [2007-07-31 13:20]:
> On 7/31/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> > >* Test::Pod::Coverage
> >
> > Why does that matter?  Does it care where its .t file lives?
> 
> The synopsis suggests t/pod-coverage.t.

Wow, now that is *incredible* inertia right there.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Fixing the damage caused by has_test_pod

[A. Pagaltzis]

* David Cantrell <[EMAIL PROTECTED]> [2007-07-31 13:20]:
> A. Pagaltzis wrote:
> 
> >Disagree. The tarball should contain the full source necessary
> >to recreate everything the author did. Stuff that’s not
> >relevant to end-user installation of the module should simply
> >be kept out of the way.
> 
> I ever-so-respectfully disagree.  I am not going to include the
> original data that I downloaded from the UK telecoms regulator
> for a particular build of Number::Phone::UK::Data (although I
> do include a shell script that downloads the current version of
> that data), nor the list of exchanges for
> Number::Phone::UK::DetailedLocations.
> 
> Bear in mind that these two modules are already 2.5MB and 7.5MB
> *compressed*, 18 and 36MB uncompressed.

I said “the tarball should contain everything necessary to
recreate everything the author did”, to which you respond “I
include a shell script for downloading the un-munged data I used
to build the module.”

Can you explain to me where the disagreement is? :-)

(Yes, I know there’s technically a difference. But what I *meant*
is that someone else should be able to losslessly take over or
fork the module, and what you’re doing is perfectly in line with
that.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Fixing the damage caused by has_test_pod

[A. Pagaltzis]

* Andy Lester <[EMAIL PROTECTED]> [2007-07-30 21:41]:
> On Jul 30, 2007, at 1:58 PM, Eric Wilhelm wrote:
> 
> >Thus, I posit that the quality of the module is generally
> >lower if 'boilerplate.t', 'pod-coverage.t', and 'pod.t'
> >*exist*.
> 
> Certainly, the intent is to have boilerplate.t NOT get shipped
> with  the module.

Disagree. The tarball should contain the full source necessary to
recreate everything the author did. Stuff that’s not relevant to
end-user installation of the module should simply be kept out of
the way.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Fixing the damage caused by has_test_pod

[A. Pagaltzis]

* Christopher H. Laco <[EMAIL PROTECTED]> [2007-07-29 17:05]:
> A failing pod test is the first sign pod2* generation is
> broken. It's rare, but I've been in the situation where for
> some reason (mistmatching dist requirements, failed upgrades,
> bad dist packages, broken troff, etc) the creation of man
> pages/html from the dist pod fails outright. Pod tests assure
> the user that they will be able to perldoc/man the thing they
> are installing. That's doubly true if you're using pod2usage to
> expose help in scripts.

Is that actually true? Test::Pod uses Pod::Simple, but that’s far
from the only game in POD town. Even the perldoc utility included
with versions of perl that ship with Pod::Simple uses its own
formatter by default. And Pod::Simple has not always shipped with
perl. So if Pod::Test says you’re fine, that doesn’t necessarily
mean things will work for the user (though if it says you’re
broken then things are likely to break for the user as well,
since Pod::Simple is very solid).

Regards,
-- 
Aristotle Pagaltzis // 

Re: Fixing the damage caused by has_test_pod

[A. Pagaltzis]

* David Cantrell <[EMAIL PROTECTED]> [2007-07-30 12:04]:
> Eric Wilhelm wrote:
> ># from Adam Kennedy
> >>Thus, I would like to propose the following.
> >>1. That the running of POD-related tests by end users is
> >>considered harmful.
> >+20
> 
> -40
> 
> I don't see that it's harmful at all. It's not even
> particularly harmful (merely annoying) for an author to add
> Test::Pod etc as pre-requisites. And if you have a religious
> objection to installing them, you can always run the rest of
> the tests for a module, see that it passes all the functional
> tests, and force install it.

Sysadmins’ hairs grow grey over stuff like this.

Hapless users are completely overwhelmed with it.

Tests should NEVER EVER fail without a really good reason.

The only ones who can deal with it relatively well are the Perl
developers who themselves write modules and understand the
mechanics well enough to be able to make a sound call.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Fixing the damage caused by has_test_pod

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2007-07-28 19:10]:
> Let me also suggest #3: revise the appropriate CPANTS tests to
> add Kwalitee only if the static analysis tests do *not* run by
> default.

Maybe deduct points for depencies on obvious author-testing
distros?

(Although that could get tricky when rating such an author test
module itself.)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Reporting setup problems separately?

[A. Pagaltzis]

* Gabor Szabo <[EMAIL PROTECTED]> [2007-07-24 08:45]:
> That is, there is a phase where I setup the test environment
> and then there is the actual test. Obviously each phase can
> consists of several ok() functions.

Right. The setup phase is called the “fixture” in testing lingo
and it should not be a test. If the fixture setup fails, it makes
no sense to try to continue and execute any further tests, as
they’ll all break anyway. So you do the setup prior to any tests
and `die` if any of it fails.

> I would like to be able to display them in a different way.

If you `die`, the harness will report it differently.


* David Golden <[EMAIL PROTECTED]> [2007-07-25 04:40]:
> Or use a SKIP block.

Not in this case. SKIP will continue silently without registering
a failure, but this is an issue of setup failure for non-optional
tests, for which you want a loud complaint.

The right approach is `die`.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test::Class fixture problem

[A. Pagaltzis]

* Adrian Howard <[EMAIL PROTECTED]> [2007-07-02 20:20]:
> use something like chromatic's SUPER

My thought exactly.

Regards,
-- 
Aristotle Pagaltzis // 

Re: faking time() across processes for testing

[A. Pagaltzis]

* Joshua ben Jore <[EMAIL PROTECTED]> [2007-06-29 05:35]:
> I had a terrible and powerful idea just now. Use Runops::Trace

When all you have^W^W^W you newly discover the hammer…

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle

Re: .t files as specs

[A. Pagaltzis]

* Ricardo SIGNES <[EMAIL PROTECTED]> [2007-06-21 02:40]:
> I advocate another form of this: synopsis-driven development.
> 
> I write a five to ten line hypothetical use case (or longer,
> for modules whose most basic use would require it), and then
> say, "Wouldn't it be totally awesome if that /worked/?"

++

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle

Re: Code coverage awesomeness

[A. Pagaltzis]

* Joshua ben Jore <[EMAIL PROTECTED]> [2007-06-18 02:10]:
> Probably but I'd ask Avar or Yves about that and I'm sure the
> method would be entirely different. The 5.10 engine is
> pluggable so I'm sure it's wrappable and therefore traceable.

Cool. Because that’s a subject that the existing coverage tools
don’t deal very well with – just because I used a regex once
doesn’t mean I actually have any significant coverage of the
“code paths” in that regex. Yet all the tools operate on this
assumption so far.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Code coverage awesomeness

[A. Pagaltzis]

* Joshua ben Jore <[EMAIL PROTECTED]> [2007-06-17 06:45]:
> I took chromatic's Runops::Trace and hacked it up so I could do
> code coverage. I can now tell which code path is triggered by
> which inputs.

Wow, that’s bloody excellent.

Here’s the bonus question, though: can the same thing be done for
the regex engine?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Pod at end

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2007-06-08 07:40]:
> >Conversely, when I edit code, I occasionally want to shift big
> >swathes of stuff around; having to carry along all the POD
> >before I’m done would bog me down for no gain whatsoever,
> >particularly in light of the fact that such changes generally
> >result in a structucal revision to the docs.
> 
> =head1 Foo Stuff
> ...
> =head2 foo_this
> ...
> } # end sub
> =head2 foo_that
> ...
> } # end sub
> 
> =head1 Bar Stuff
> ...
> 
> Were you arguing against interspersed pod?  If you're moving
> code into the Foo section, the docs go with it.  If you're
> swapping =head1 sections, the code goes with them.  Pod at the
> end means finding your cut points twice instead of once.

I can’t remember the last time I gratuitously moved things around
without any structural changes. When I move big chunks around,
it’s because I’m instituting or abolishing an abstraction or
indirection by changing the call tree/class structure and
shifting parts of the code up or down the hierarchy. Fiddling
with the POD before I’m done is beyond pointless.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Pod::Critic?

[A. Pagaltzis]

* Andy Lester <[EMAIL PROTECTED]> [2007-06-08 00:15]:
> On Jun 7, 2007, at 5:04 PM, Matisse Enzer wrote:
> >I wonder how you all feel these days about the "put the pod at
> >the __END__" approach? I've been trying it for over a year now
> >and am not really sure its the best way to go (vs. having the
> >pod for each method right next to it.)
> 
> It's 100% wrong. Put the docs next to the code. It's easier to
> see than to think.

Whoa whoa whoa, them’s fighting words. *You* are 100% wrong.
Here’s a nickel, get a better editor.



Mine lets me split the window so when it’s time to write docs
I have a contiguous view of the POD in one half while referring
to the code in the other, which renders your “easier to see than
think” argument moot.

Documentation should form a coherent narrative. The myopic view
of inlined local POD sections is a hindrance to that. Conversely,
when I edit code, I occasionally want to shift big swathes of
stuff around; having to carry along all the POD before I’m done
would bog me down for no gain whatsoever, particularly in light
of the fact that such changes generally result in a structucal
revision to the docs.

Regards,
-- 
Aristotle Pagaltzis // 

Re: use_ok and %INC

[A. Pagaltzis]

* Smylers <[EMAIL PROTECTED]> [2007-06-06 13:25]:
> How about instead having use_ok simply removing the %INC entry
> if it's found, so that it can be used safely in exactly this
> situation?
> 
> Would doing that silently obscure any genuine bugs?

It would cause subroutine redefinition warnings and possibly
duplicate resource initialisation and other such badness if the
module really *was* loaded previously. Bad idea.

I think what we really want is to add `use_fails`, which *would*
be able to safely wipe the `%INC` entry after failure, because by
its very meaning, that test function can make an assumption that
is otherwise unsafe.

But both it and `use_ok` should warn if they find the key already
in `%INC`.

Although, as I wrote in comment at Ovid’s, it is `require` in
Perl itself that should really wipe the key whenever a) loading
fails and b) the key was not already there. Who knows if it’s
feasible to change that semantic at this late point, though.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-02 03:40]:
> I know it's not as cute as the current interface - but cute can
> be surprising and I don't think a surprising interface is
> necessarily a  good thing :)

Agreed. It just depended on what you preferred; in case of a
method per metric, generating methods + AUTOLOAD seemed to me to
be the simplest option, as it would involve the least amount of
conditional code.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-06-01 16:25]:
> I could
> 
> * generate the methods dynamically based on the Kwalitee
>   modules that are installed
> 
> * generate only the current methods and add a new method
>   test_against() (or whatever) that provides access to any
>   named Kwalitee test
> 
> * replace the generated methods with an AUTOLOAD handler
> 
> In the test_against() or AUTOLOAD scenarios I could then make
> Kwalitee tests for which the module is unavailable skip
> automatically.
> 
> Thoughts?

Remember you can also combine options #1 and #3: generate methods
at compile-time and use AUTOLOAD just for skipping. Would there
be any provision for catching typos in any of these cases,
though?

Regards,
-- 
Aristotle Pagaltzis // 

Re: CPANTS: suggestion for a new metric

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-05-26 19:50]:
> One of the very few reasons I maintain a Windows box here and
> endure the pain (for me - subjective I know) that goes with it
> is so I can test my modules against Win32.

So do I. And yeah, I find it painful too. But it’s not open for
debate.

Btw, if any people with strong Win32 skills can help me stop
Proc::Fork from “segfaulting” on Windows, I’d appreciate it.
I tried a whole bunch of things but ran out of ideas and it’s
still broken. I asked around but no one seemed to know any
better.


* demerphq <[EMAIL PROTECTED]> [2007-05-26 20:10]:
> Fine then. The fact that ExtUtils make dist automatically
> produces a .tar.gz and the fact that Archive::Tar does not do
> the right thing is not exactly my fault however.

No – *but* it does affect users that are interested in such
brokenly packaged modules, so deducting Kwalitee is the correct
thing to do IMO.

Even if MakeMaker or Archive::Tar or whatever it is that’s broken
were fixed,  not every author uses the same tools, and someone
might decide to use something different without knowing it’s
broken. Again then it’s the author who needs to fix his distro,
even though he couldn’t know that the tool he used was broken and
isn’t to blame for that. So again – having this check in the
metrics would serve a useful purpose.

I’m not singling out Win32 people, btw. If a similar error was
likely to be a Unix-based author’s gaffe, I’d still advocate a
check. The collective goal is to make things that work as
painlessly as possible for as many people as possible.

Regards,
-- 
Aristotle Pagaltzis // 

Re: testing on other platforms

[A. Pagaltzis]

* Gabor Szabo <[EMAIL PROTECTED]> [2007-05-26 20:10]:
> besides uploading to CPAN and waiting for the CPAN testers to
> test my modules on platforms I don't have? [*]
> 
> Is there some publicly available Solaris/HP-UX/etc
> (see full list on this page http://www.cpan.org/ports/index.html )
> set of servers where one could test his modules?

That’s what Alias’ PITA[1] project is supposed to achieve.

[1]: http://ali.as/pita/

Regards,
-- 
Aristotle Pagaltzis // 

Re: CPANTS: suggestion for a new metric

[A. Pagaltzis]

* demerphq <[EMAIL PROTECTED]> [2007-05-26 19:20]:
> BTW, id say that if this is an issue for Unix users then they
> should file a bug with the people that wrote their
> decompression software and/or installer software.

It’s the decompression software’s fault that it correctly
preserves the data in the archive when decompressing?! Are you
serious?

Sorry, but it is *the _compression_ software’s* bug.

> I dont see it as being my problem as a Win32 developer at all.
> Im sympathetic to the annoyance it causes but to me its like
> opening a book written in a language you dont read and
> complaining that it isnt written in one you do. I mean if Win32
> doesnt even support this concept how is it my problem what your
> software does when unpacking?

Tarballs are a Unix concept and use Unix permission semantics.
Win32 developers creating tarballs are writing books in a
language they don’t speak. Then they get annoyed that native
(or fluid) speakers of the language complain when their books
are full of mistakes.

(What a silly metaphor… but anyway.)

Sorry, you’re wrong. I’m sorry if the silly Unix people are
grating on your nerves, but they’re right.

Regards,
-- 
Aristotle Pagaltzis // 

Re: CPANTS: suggestion for a new metric

[A. Pagaltzis]

* demerphq <[EMAIL PROTECTED]> [2007-05-26 17:35]:
> Can you explain this please? Why would the lack of a set x bit
> on a directory prevent you from doing
> 
>  perl Makefile.PL
>  make
>  make test

Yes.

> Is this simply so you dont have to type 'perl'?

No.

The x bit on a directory determines whether you can resolve paths
that cross it.

~ $ cd Proc-Fork
~/Proc-Fork $ chmod -x lib
~/Proc-Fork $ perl Build.PL 
Can't find file lib/Proc/Fork.pm to determine version at \
/usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm line 937.

Regards,
-- 
Aristotle Pagaltzis // 

Re: CPANTS: suggestion for a new metric

[A. Pagaltzis]

* David Cantrell <[EMAIL PROTECTED]> [2007-05-26 16:45]:
> I think it would be a good idea for CPANTS to check that
> directories have the x bits set.

++

> This would either be a new metric

+=0

> or could be rolled into 'extracts_nicely'

++

> or could be combined with 'no_symlinks' and called
> 'uses_portable_filesystem_features' or something similar.

--

It doesn’t have to do with filesystem features, it has to do with
OS permission semantics. You can mount FAT32 and NTFS in unixoid
systems and likewise mount ext2/3 in Windows, and a sufficiently
abled tool could then correctly extract archives preserving non-
portable features, but the permission semantics don’t carry over
correctly anyway because the respective kernels are not able to
convey them.

The `extracts_nicely` metric is the right place for this, IMO.

Regards,
-- 
Aristotle Pagaltzis // 

Re: trying to setup Module::CPANTS::Analyse

[A. Pagaltzis]

Hi Ovid,

* Ovid <[EMAIL PROTECTED]> [2007-04-15 17:05]:
> --- Michael Stevens <[EMAIL PROTECTED]> wrote:
> > #!/home/mstevens/tools/perl-5.8.8/bin/perl
> > 
> > […]
> 
> You're not using strict and warnings. If you had, you might
> have seen that […] However, $a would not have thrown an error
> […] not being able to call a method on an undefined variable.
>
> […]
> 
> However, it's not recommend to use the special $a and $b
> variables in this way […]

I read “Michael Schwern” as the name of the original poster at
first and was really weirded out that you would lecture Schwern
like that. :-)

Regards,
-- 
Aristotle
“If you can’t laugh at yourself, you don’t take life seriously enough.”

Re: Alternate CPAN::Reporter delivery methods?

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2007-04-10 08:35]:
> As email continues to get locked down more-heavily, is it worth
> looking into an alternative delivery (possibly even as the
> default) path for CPAN::Reporter?

Isn’t the CPANTS driven off a newsgroup? It should be possible to
use Net::NNTP to dump reports directly into the server’s lap, no?

Regards,
-- 
Aristotle Pagaltzis // 

Re: multi-file TAP

[A. Pagaltzis]

* Michael Peters <[EMAIL PROTECTED]> [2007-04-06 23:15]:
> Maybe I'm missing something (and if so, please point out the
> obvious to me) but I can't find a way for a single TAP file to
> contain results from multiple test files.

There isn’t one. There was recently discussion about this, with
mixed opinions about whether it’s needed and what it might look
like. One of the suggestions was that it has overlap with the
grouping/nesting proposals that keep re-appearing.

Btw, for TAP stuff, see [EMAIL PROTECTED] – list info and
such at .

Regards,
-- 
Aristotle Pagaltzis // 

Re: Does this pattern have a name?

[A. Pagaltzis]

* Yuval Kogman <[EMAIL PROTECTED]> [2007-04-03 01:00]:
> On Mon, Apr 02, 2007 at 23:08:40 +0100, Andy Armstrong wrote:
> > So if the object was completely immutable, normal prototyping
> > would be semantically identical to what I'm describing. But
> > if I still want to be able to set properties and have the
> > underlying object update correctly I'd need to add some
> > magic. Is that right?
> 
> Then just proxy everything:
> 
>   sub AUTOLOAD {
>   my ( $self, @args ) = @_;
>   my $method = ( our $AUTOLOAD =~ /([^:]+)$/ )[0];
> 
>   if ( exists $self->{shadowing}{$method} ) {
>   # or maybe you mean if ( [EMAIL PROTECTED] and exists 
> $self->{shadowing}{$method} ) {
>   return $method; # expand lists for list ctx based on a 
> flag or something like that
>   } else {
>   # if you had [EMAIL PROTECTED] then don't forget delete 
> $self->{shadowing}{$method};
>   $self->{parent}->$method(@args);
>   }
>   }
> 
> For the proper distinction between a setter and a method that
> accepts arguments (and should still be shadowed) I guess you
> need some meta programming, but the value is dubious IMHO.
> 
> > With conventional prototyping if I do
> > 
> > $base= Thing->new;
> > $derived = $base->variant_or_clone_or_whatever( { modify => 'something' } );
> > 
> > and then
> > 
> > $derived->set_some_field( 'Aark!' );
> > 
> > by default I'd be assigning to a field within $derived rather
> > than within $base.
> 
> This can be done too, btw, even in a hybrid system as long as
> you have sufficient introspection data.
> 
> However, it gets tricky on the meta level -- you'd have to know
> the class quite well, and maybe create an anonymous clone of
> it.

I think Andy’s particular case can be handled very easily if the
constructors are all just factory methods. Basically you have a
WebForm class and a WebForm::View class, and any attempt to
construct a WebForm returns a WebForm::View with a WebForm
wrapped inside it.

Calling `variant` on the view returns a clone referring to the
same instance of WebForm. WebForm::View proxies every method it
doesn’t implement to the wrapped WebForm.

So far it’s all quite trivial; now comes the only non-ordinary
part: the `render` method (and anything other one that depends on
the view’s parametrisation) is implemented in *both* classes,
where the implementation in the WebForm::View class just passes
`$self` along to the same method in the wrapped WebForm. That
way, the “model” method can query the “view” for the parameters
it needs. (As you can see, the MVC terminology really breaks down
here; this isn’t MVC at all.)

You don’t need any fancy new OO paradigm to do this or even any
introspection, just a trivial bit of metaprogramming (AUTOLOAD).

Regards,
-- 
Aristotle Pagaltzis // 

Re: Does this pattern have a name?

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-04-03 13:10]:
> Having slept on it I think the name for what I'm trying to do
> might reasonably be 'object currying'.

That’s very close to what I first thought when I started to read
the thread. Bummer you beat me to it. :-)

Regards,
-- 
Aristotle Pagaltzis // 

Re: New CPANTS metrics

[A. Pagaltzis]

* Thomas Klausner <[EMAIL PROTECTED]> [2007-04-01 00:20]:
> Even though I was fighting mail servers today, I managed to put
> some time aside for long-needed CPANTS improvements.

Congrats on being _the_ _only_ _one_ to pull an online April
fool’s prank, all day, that actually managed to lead me astray
for even a *moment*. :-)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Tables in TAP

[A. Pagaltzis]

Hi Gabor,

* Gabor Szabo <[EMAIL PROTECTED]> [2007-03-28 17:35]:
> In line with the discussion of TAP I would like to show a use
> case I would like to be able to handle. I would like to be able
> to report certain information in table format in (or instead
> of) the diag call.

TAP is a protocol. You want a particular presentation for the
data. These things do not belong together.

Write a test module that collects records and dumps the lot using
the new YAML diagnostics format. Invent a way to include an
annotation saying “this array of hashes is a table.” (Or whatever
the data structure looks like.) Write a harness (or subclass of a
harness) that understands your annotation and renders a table
from the data when it sees the annotation hint.

Or if you want, write the test module to produce a representation
and include it in the TAP using the logging format for
human-readable stuff. (Note that this gives you less flexibility
in the long run.)

Regards,
-- 
Aristotle Pagaltzis // 

Re: YAML?

[A. Pagaltzis]

* Andy Lester <[EMAIL PROTECTED]> [2007-03-20 00:50]:
> Let's just forget that it was called "YAML-ish", and just think
> "key/ value pairs".

Works for me if you define a grammar. Though the JSON suggestion
is also good and if people agree to do it, I’d be in favour.
Certainly it would help implementors from other languages; YAML
has some coverage among dynamic languages, but it can’t match
JSON and probably never will. (Not the full format anyway.)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Eliminating STDERR without any disruption.

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-03-19 00:35]:
> On 18 Mar 2007, at 23:10, A. Pagaltzis wrote:
> >* Andy Armstrong <[EMAIL PROTECTED]> [2007-03-19 00:05]:
> >>  http://testanything.org/pipermail/tap-l/
> >
> >Subscribed!
> 
> Can't see you on the subscribers list. Did it not work?

Hmm, I never got a subscription confirmation request.

Check the pending subscriber list, I should be in there.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Eliminating STDERR without any disruption.

[A. Pagaltzis]

* Andy Armstrong <[EMAIL PROTECTED]> [2007-03-19 00:05]:
>   http://testanything.org/pipermail/tap-l/

Subscribed!

Regards,
-- 
Aristotle Pagaltzis // 

Re: Eliminating STDERR without any disruption.

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-18 23:55]:
> On the one hand we want a TAP list in which we can discuss the
> protocol independent of its implementation or Perl. Then its
> said to merge the discussion about the details of the
> TAP::Parser Perl implementation into the Perl and
> implementation independent TAP mailing list.
> 
> Does not compute.
> 
> What did you intend to gain by merging the TAP::Parser list
> into the TAP list?

Well, as long as the discussions about TAP remain firmly on the
TAP list, that might be OK. If the TAP::Parser list deals purely
with implementation details that are truly irrelevant to TAP per
se, maybe they shoud stay separate. But the volume of discussion
might not be high enough to sustain multiple lists, even if the
topical split is correct, and having discussions about details of
TAP implementation in several different language on the same TAP
list might be healthy for the protocol.

I see this mistake made in lots of messageboards on the web,
where people eagerly set up a hundred forums for specific topics,
and then none of them gets any traffic. It’s better to throw it
all together at first, and split the discussion only when the
volume necessitates it.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Eliminating STDERR without any disruption.

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-18 22:10]:
> Andy Armstrong wrote:
> > There's a lot of wisdom in Ghostbusters of which this is just
> > one example.
> 
> uhhh... oh.

ROTFL! Exactly my reaction.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Eliminating STDERR without any disruption.

[A. Pagaltzis]

* A. Pagaltzis <[EMAIL PROTECTED]> [2007-03-18 23:43]:
> * Andy Armstrong <[EMAIL PROTECTED]> [2007-03-18 22:45]:
> > I volunteer to host it if necessary.
> 
> That’s not a bad idea; a dedicated domain for TAP without any
> mention of Perl in the name is probably a good marketing move.
> I don’t mean that we need to ashamedly hide the fact that we’re
> Perlers, but I think it would be wise not to give people cues
> based on which they can quickly superficially dismiss TAP as
> irrelevant to their own work, if we want it to catch on.

Oh, and it would be nice if the TAP::Parser list (or whatever the
tapx list is about) would be rolled back into the TAP list; I
didn’t know that list even existed until the recent crossposts,
and I think this sort of fragmentation is unwise.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>