_brian_d_foy wrote:
In article <[EMAIL PROTECTED]>, Randy W. Sims
<[EMAIL PROTECTED]> wrote:
Probe::OS - Gather info on the operating system
Probe::Libs
Probe::Progs
Probe::FileSys - maybe incorporate ideas Schwern posted on p5p recently,
Perhaps we can put this under a namespace like Config::
Same here.
On 08/04/2005 20:02 Ken Williams wrote:
On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote:
die "NA: $reason";
Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author
figure it
out. Its simple and m
Robert Rothenberg wrote:
I'm all for something like this, though I prefer "requires_libraries"
instead. (Listing libraries distinct from applications is a grey area,
so best to put them under one term.)
Come to think of it, why not "recommends_libraries" too?
What is needed is some standard set
On Apr 8, 2005, at 12:32 PM, Michael G Schwern wrote:
die "NA: $reason";
Since, at the moment, we're having trouble putting together a system to
cover the possible reasons for an NA report let the module author
figure it
out. Its simple and minimal.
I like it.
-Ken
On Apr 8, 2005, at 10:28 AM, Michael G Schwern wrote:
Nahh, I'll start slamming now. :) The eq_* salad was a mistake and
I've
been planning on deprecating them for a while now. No sense in
parroting
mistakes forward.
By the way, I've just removed those from my svn repository, and changed
eqSet
I'm all for something like this, though I prefer "requires_libraries"
instead. (Listing libraries distinct from applications is a grey area,
so best to put them under one term.)
Come to think of it, why not "recommends_libraries" too?
What is needed is some standard set of library and applicatio
On Thu, Apr 07, 2005 at 07:49:40AM -0500, Chris Dolan wrote:
> >Is there a way tests to determine that a module cannot be installed on
> >a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not
> >Applicable) report?
The only way I know of to do this currently is for Makefile.PL to
On Fri, Apr 08, 2005 at 12:36:16PM -0400, Geoffrey Young wrote:
> as someone familiar with T::M and not javascript, were I to try to use this
> it's an additional barrier to call it "Test::More in JavaScript" but not
> provide _the exact same functions_ as Test::More. now before everyone
> starts
Another good reason to ship all of your development tests with code is
that it makes it easer for users to submit patches with tests. Or to
fork your code and retain all your development tools and methods.
Since most Perl modules go up on CPAN and nowhere else, I think that the
CPAN distribution
On Apr 8, 2005, at 9:36 AM, Geoffrey Young wrote:
as someone familiar with T::M and not javascript, were I to try to use
this
it's an additional barrier to call it "Test::More in JavaScript" but
not
provide _the exact same functions_ as Test::More. now before everyone
starts slamming this let me
On Apr 8, 2005, at 8:23 AM, Adrian Howard wrote:
I did once hack JSUnit to output TAP - so you never know :-)
You are a very sick man. :-)
D
On Apr 7, 2005, at 2:41 PM, Ovid wrote:
It's my understanding that the Ecmascript standard leaves garbage
collection up to the implementation. I suspect this means we can't be
sure exactly when an object is destroyed, though whether or not this
has any bearing on David's problem is not clear to me
David Cantrell wrote:
> Let's take my module File::Find::Rule::Permissions as an example. I
> know it doesn't work on Windows, but not having access to a Windows
> machine, I have *no idea* what $^O should be on that platform,
> especially for any odd Windows environments like Cygwin or WinCE. I
David Wheeler wrote:
> On Apr 7, 2005, at 5:55 PM, Michael G Schwern wrote:
>
>> If you have isDeeply() there's little point to the eq* salad.
>
>
> Hrm, fair enough. I'll comment them out, then...
well, a few thoughts here...
as someone familiar with T::M and not javascript, were I to try t
On 7 Apr 2005, at 20:27, David Wheeler wrote:
[snip]
Besides, I'm sure that Adrian will soon take my code to port
Test::Class to JavaScript, and then we can have both approaches! ;-)
I did once hack JSUnit to output TAP - so you never know :-)
Adrian
On 7 Apr 2005, at 19:23, David Wheeler wrote:
Greetings fellow Perlers,
I'm pleased to announce the first alpha release of my port of
TestSimple/More/Builder to JavaScript. You can download it from:
http://www.justatheory.com/downloads/TestBuilder-0.01.tar.gz
[snip]
You rock! Excellent stuff. O
Chris Dolan wrote:
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
Is there a way tests to determine that a module cannot be installed on
a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not
Applicable) report?
CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") b
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> This
> > is because there is no END block to grab on to in JavaScript.
>
> Could object destruction be used somehow?
It's my understanding that the Ecmascript standard leaves garbage
collection up to the implementation. I suspect this means
On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
Is there a way tests to determine that a module cannot be installed on
a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA" (Not
Applicable) report?
CPANPLUS relies on module names (e.g. "Solaris::" or "Win32::") but
that is not al
On 07 April 2005 19:34 David Golden wrote:
> Let's step back a moment.
>
> Does anyone object that CPANTS Kwalitee looks for tests?
I think you're missing the point of Tony's argument. I don't think anyone would
dispute that shipping tests with a distribution is a Good Thing (tm). What is at
i
On 07 April 2005 23:02 Ken Williams wrote:
> On Apr 6, 2005, at 7:13 AM, Robert Rothenberg wrote:
>
>> Is there a way tests to determine that a module cannot be installed
>> on a platform so that CPANPLUS or CPAN::YACSmoke can issue an "NA"
>> (Not Applicable) report?
>>
>> CPANPLUS relies on m
On Thu, Apr 07, 2005 at 02:34:21PM -0400, David Golden wrote:
> * Shipping tests is a hint that a developer at least thought about
> testing. Counter: It's no guarantee of the quality of testing and can
> be easily spoofed to raise quality.
This is certainly not why I ship tests, and I've never
22 matches
Mail list logo
