Re: Suggestions for cpantesters

On 9/29/06, Alexandr Ciornii <[EMAIL PROTECTED]> wrote: Hello! For a long time I'm using Test::Reporter. Now I participate in Vanilla Perl project (http://win32.perl.org). I've started CPAN smoke. I've come to several ideas regarding cpantesters. I want your opinion on them. 1. YAML files on h

Re: Suggestions for cpantesters

On 10/3/06, David Golden <[EMAIL PROTECTED]> wrote: On 10/3/06, Alexandr Ciornii <[EMAIL PROTECTED]> wrote: > > > IMHO, including whole %ENV whould be unsafe. We can create list of > variables to be included. PERL5OPT. Any others? Also maybe > user-configurable list, where user himself decides wh

Re: testing module loading output and testing under the debugger

On 12/17/06, Nadim Khemir <[EMAIL PROTECTED]> wrote: I will also have a bunch of tests that need to be run under the debugger. I will use Devel::ebug as it is the only way to control the debugger. There are tests in the ebug distribution that I might be able to copy but I would also like to try t

Re: testing module loading output and testing under the debugger

On 12/19/06, demerphq <[EMAIL PROTECTED]> wrote: On 12/19/06, Nadim Khemir <[EMAIL PROTECTED]> wrote: > >Personally I wouldn't get /too/ hung up about 100% test coverage - it > >can be taken too seriously. See Brian Marick's "How to Misuse Code > >Coverage"

Re: Comment about BAIL_OUT

On 1/4/07, jerry gay <[EMAIL PROTECTED]> wrote: On 1/4/07, Andy Lester <[EMAIL PROTECTED]> wrote: > > On Jan 4, 2007, at 11:21 PM, Eric Wilhelm wrote: > > >> No. You either have tests that are ordered, or you don't. > > > > Stated as if it were some sort of immutable law of the universe! > > It

Re: Using pip to get testing done better and faster...

On 1/9/07, David E. Wheeler <[EMAIL PROTECTED]> wrote: On Jan 9, 2007, at 3:05 AM, Adam Kennedy wrote: > Just some tips I thought I'd pimp... ewr... I mean pass on. Obviously, you should call it `pimp` rather than `pip`. Probably isn't used by any other program in the universe, either. ;-) I

Re: Test::More and Fatal

On 1/24/07, Nik Clayton <[EMAIL PROTECTED]> wrote: Has anyone ever used Test::More and Fatal together? I have a test script, where each test builds upon the work of the previous step (it's part of the Subversion Perl bindings test suite, and it checks out files, makes changes to them, commits th

Re: Bad test functions in Test::Exception

On 1/30/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * Pete Krawczyk <[EMAIL PROTECTED]> [2007-01-30 19:00]: > How about code that dies with an object? dies_ok lets you > inspect the object in $@, whereas throws_ok only lets you see > if it's part of a class. What if you want to see if $@ meets >

Re: Bad test functions in Test::Exception

On 1/30/07, Nadim Khemir <[EMAIL PROTECTED]> wrote: I believe the example in Test::Exception is not as good as it could be. # Check that something did not die lives_ok { $foo->method2 } 'expecting to live'; Doesn't explain much about when to use it. You'd use (lives|dies|throws)_ok when

Re: Bad test functions in Test::Exception

On 1/30/07, David Golden <[EMAIL PROTECTED]> wrote: On 1/30/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote: > Interestingly, this has caused me to wonder how well Test::Exception > handles the corner cases where $@ is clobbered during the scope ending > of eval{} and relat

Re: Bad test functions in Test::Exception

On 1/31/07, Adrian Howard <[EMAIL PROTECTED]> wrote: On 30 Jan 2007, at 20:11, Joshua ben Jore wrote: > Interestingly, this has caused me to wonder how well Test::Exception > handles the corner cases where $@ is clobbered during the scope ending > of eval{} and related. It doe

Re: Bad test functions in Test::Exception

On 2/1/07, Adrian Howard <[EMAIL PROTECTED]> wrote: On 31 Jan 2007, at 16:42, Joshua ben Jore wrote: [snip] >>dies_ok { $o->annoying_corner_case } 'exception thrown'; >> >> do the SIG{__DIE__} dance make the tester write >> >>dies_ok

Re: Bad test functions in Test::Exception

On 2/1/07, Adrian Howard <[EMAIL PROTECTED]> wrote: On 1 Feb 2007, at 16:28, Joshua ben Jore wrote: [snip] > There's is nothing special about what T::E is doing to detect errors - > it just turns out the popular practice of looking at $@ is flawed. > That's a probl

UNIVERSAL::ref might make ref( $mocked_obj ) sane

I've hated it how ref() does the wrong thing so frequently so I wrote a fix for it. I like to use mock objects to feed fake or proxy objects to other things but this breaks when things not under my control use ref() to examine the class of an object. No longer. Under most circumstances ref() beha

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote: Is there a function that is to this as overload::StrVal is to stringification? No. blessed() doesn't lie to you and I don't change that. I didn't provide any ref-alike that provide the complete old behavior. If you read t/basic.t file, you'll

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote: On Sun, Feb 25, 2007 at 22:51:43 -0800, Joshua ben Jore wrote: > On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote: > >Is there a function that is to this as overload::StrVal is to > >stringification? > > No. b

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On 2/26/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: Joshua ben Jore wrote: > On 2/25/07, Yuval Kogman <[EMAIL PROTECTED]> wrote: >> Is there a function that is to this as overload::StrVal is to >> stringification? Wouldn't that just be CORE::ref $obj ? No

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On 2/26/07, Yuval Kogman <[EMAIL PROTECTED]> wrote: On Sun, Feb 25, 2007 at 23:22:13 -0800, Joshua ben Jore wrote: > Ick Neither ref nor blessed have never been a booleans before and > even this doesn't change that. Ref couldn't even used to decide if you > had

Re: using $SIG{__DIE__} correctly (if you must)

On 2/27/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: Owh goodness aragh *twitch* Together with the contortions required to safely examine $@ after an eval I'm getting tempted to put Unbreak::Eval on the CPAN. Please do. Did David Golden ever send his $@ examining snippet to you? It did

Re: using $SIG{__DIE__} correctly (if you must)

On 2/27/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote: On 2/27/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: > Owh goodness aragh *twitch* > > Together with the contortions required to safely examine $@ after > an eval I'm getting tempted to put Unbreak::Eval

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On 2/25/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote: I've hated it how ref() does the wrong thing so frequently so I wrote a fix for it. I like to use mock objects to feed fake or proxy objects to other things but this breaks when things not under my control use ref() to examine t

Re: UNIVERSAL::ref might make ref( $mocked_obj ) sane

On 3/2/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: Eirik Berg Hanssen wrote: > Michael G Schwern <[EMAIL PROTECTED]> writes: > >> chromatic wrote: >>> On Thursday 01 March 2007 17:46, Adam Kennedy wrote: >>> Actually, isn't UNIVERSAL::can($x, 'can') still valid? I seem to remember

Re: New CPANTS metrics

On 4/1/07, Graham Barr <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 31, 2007, at 5:32 PM, Yuval Kogman wrote: > On Sat, Mar 31, 2007 at 18:26:26 -0400, Yuval Kogman wrote: >> uses_version_control sounds more like lacks_manifest_skip_file which >> should deduct

Re: Automocked objects

On 4/17/07, Ovid <[EMAIL PROTECTED]> wrote: Posted at http://www.perlmonks.org/?node_id=610484 So I have some code I'm testing which relies on a class with a whole bunch of niggling, annoying little methods getting called hither and yon. For the purposes of my tests, however, I really only care

Re: Pod at __END__

On 6/7/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote: I've never seen the benefit of pod after __END__. IMO, your code and docs should follow the same order/groupings. That, and you have to It has two benefits. Separating code from pod prevents it from being wholely unreadable without syntax hig

Re: Pod at __END__

On 6/7/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote: # from Joshua ben Jore # on Thursday 07 June 2007 05:14 pm: >On 6/7/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote: >> I've never seen the benefit of pod after __END__. IMO, your code >> and docs should follow the

Re: Inline POD does not increase load time.

On 6/11/07, Michael G Schwern <[EMAIL PROTECTED]> wrote: Joshua ben Jore wrote: > It has two benefits. Separating code from pod prevents it from being > wholely unreadable without syntax highlighting. > The other benefit is you don't spend the CPU parsing that additio

Code coverage awesomeness

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. Check this badness out. The punchline is the lists of equivalent inputs. Roughly. Ops can return different things and I'm not paying attention to the inputs

Re: Code coverage awesomeness

On 6/16/07, Chris Dolan <[EMAIL PROTECTED]> wrote: Josh, Josh, can you explain to us in a little more depth what this means? Are you showing that certain input values follow the same path through the code? Yes. It looks like the full path through the code is the key to your hash of runs. If

Re: Code coverage awesomeness

On 6/16/07, Chris Dolan <[EMAIL PROTECTED]> wrote: On Jun 17, 2007, at 12:56 AM, Joshua ben Jore wrote: > On 6/16/07, Chris Dolan <[EMAIL PROTECTED]> wrote: >> Josh, >> >> Josh, can you explain to us in a little more depth what this means? >> Are you showi

Re: Code coverage awesomeness

On 6/17/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * 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&#

Re: Code coverage awesomeness

On 6/16/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote: 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. Check this badness out. The punchline is the lists of equivalent inputs. Roughly. Ops

Re: Code coverage awesomeness

On 6/19/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote: On 6/16/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote: > 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. > Ok, so now

Re: Code coverage awesomeness

On 6/19/07, chromatic <[EMAIL PROTECTED]> wrote: On Tuesday 19 June 2007 14:06:05 Joshua ben Jore wrote: > It's on CPAN with the original name. I just stole the namespace. I > don't think chromatic will mind. > > It can even support the API described in Perl Hacks i

Re: faking time() across processes for testing

On 6/28/07, David Golden <[EMAIL PROTECTED]> wrote: On 6/28/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > I was thinking there needs to be a shared filehandle with a stream of > time on it similar to the below, but with various time() and sleep() > methods overridden. Calls to time() or sleep()

Re: faking time() across processes for testing

On 6/29/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * 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… That's it exactly. "I've got thi

Re: Summarizing the pod tests thread

On 7/31/07, David Golden <[EMAIL PROTECTED]> wrote: > On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote: > > Please explain to me, in detail sufficient for a three year old, precisely > > how: > > > > 1) POD can possibly behave any differently on my machine versus anyone > > else's > > machine, bein

Re: Planning talk on Devel::Cover

On 9/12/07, James E Keenan <[EMAIL PROTECTED]> wrote: > I have had a proposal accepted to do a presentation at the Pittsburgh > Perl Workshop (Oct 13-14) on "Better Code via Coverage Analysis during > Testing" (http://pghpw.org/ppw2007/talk/725). > > During this presentation I hope to: > > 1. Chan

Re: Planning talk on Devel::Cover

On 9/14/07, Paul Johnson <[EMAIL PROTECTED]> wrote: > I've started on a sort report to provide an optimal test ordering, so > that you can do the majority of your testing as soon as possible, or > identify tests which don't add to your coverage, but this isn't finished > yet. That's interesting. H

Re: So bewilderingly. about closure

On 9/20/07, demerphq <[EMAIL PROTECTED]> wrote: > The solution is to add a dummy line to f() to make sure that it mentions $x. > > { > my $x = 'A'; > sub f { my $y=$x; sub { print \$x; $x++ } } > sub g { sub { print \$x; $x++ } if $x } > } My experience was just a void

What's up with "No targets specified and no makefile found"?

The CPAN smokers regularly spit back UNKNOWN results where the text of the error is: Output from '/usr/bin/make': make: *** No targets specified and no makefile found. Stop. One example is http://www.nntp.perl.org/group/perl.cpan.testers/2009/07/msg4616138.html but there are many, many

Re: What's up with "No targets specified and no makefile found"?

On Mon, Dec 21, 2009 at 11:19 PM, Chris 'BinGOs' Williams wrote: > On Mon, Dec 21, 2009 at 04:15:22PM -0500, David Golden wrote: >> You need to be asking on cpan-testers-discuss.  Copying that list now. >> >> -- David >> >> On Mon, Dec 21, 2009 at 4:0

Re: What's up with "No targets specified and no makefile found"?

On Tue, Dec 22, 2009 at 2:23 PM, Michael G Schwern wrote: > Joshua ben Jore wrote: >> >> The just-released EU::MM 6.56 repeats this pattern frequently: >> >>    open my($fh), '>', ... >>        or croak("Can't open ... for writing: $!&q

Re: What's up with "No targets specified and no makefile found"?

On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern wrote: > A little experimentation with a small disk image shows that close() will > error if there's no disk left.  No need to check every print.  And a close() You have to check every print. Most prints will just extend the buffer but some print

Re: What's up with "No targets specified and no makefile found"?

On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern wrote: > A little experimentation with a small disk image shows that close() will > error if there's no disk left.  No need to check every print.  And a close() > wrapper is trivial.  It does mean there needs to be a close() for every > open() whi

Re: What's up with "No targets specified and no makefile found"?

On Tue, Dec 22, 2009 at 9:29 PM, Marvin Humphrey wrote: > On Tue, Dec 22, 2009 at 09:03:42PM -0800, Joshua ben Jore wrote: >> On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern wrote: >> > A little experimentation with a small disk image shows that close() will >> > er

Depend on Imager w/ PNG feature?

Hi, My Runops-Movie depends on Imager with it's png feature. I'm not sure exactly how to accomplish this as a dependency. My module can depend on Imager but I have no way to communicate to the running CPAN harness that the Imager that's been delivered isn't sufficient. Right now the only "abort" m