Re: Meta testing
On Mon, Mar 03, 2003 at 12:14:57AM +, Fergal Daly wrote: > Any comments or suggestions? No, sorry. I don't know much of the details of the innards, and it's a complex problem. But I don't think anyone has replied, so I thought that I should avoid you suffering Warnock's Dilemma any longer. Nicholas Clark
Re: [RFC] Module::Husbandry
On Fri, Dec 20, 2002 at 08:17:16AM -0500, darren chamberlain wrote: > This is great. I keep meaning to do something like this myself, get > about halfway there, and then end up doing something else. Good work. > > - Using Template.{t,pm} is a little counter-intuitive -- this looks > like it's a ragular Perl module, instead of a template (despite the > name). I'd use something like _skeleton.pm and _skeleton.t for > these files. Aargh. A bad pun has landed in my head and demands that I share it: tePMlate.pm Hopefully it's clear that something with that name is not intended for production. Nicholas Clark
Re: callbacks at the end of Test::More ?
On Wed, Nov 06, 2002 at 07:18:14PM -0500, Michael G Schwern wrote: > On Sat, Oct 26, 2002 at 04:22:49PM +0100, Nicholas Clark wrote: > > However, I'd like to be able to cleanly print out my random number seed to > > STDERR (or whatever Test::Builder's correct name for this is) if it believes > > that any tests have failed, and I can't see a clean way to do this. > > In an END block, grab the T::B object and check the summary(). > > #!/usr/bin/perl -w > > use Test::More tests => 1; > > pass('foo'); > > END { > my $failed = grep!$_, Test::More->builder->summary; > diag $failed ? "Failed\n" : "Passed\n"; > } > > The only trouble there is if the test as a whole fails during the ending, > like because the wrong number of tests were run or the exit code was odd, > the above logic is too simple to know that. You have to go through the > sort of logic _ending() does. I think that will do fine for what I need. I'm only reporting extra diagnostics if all tests failed. I now have this wierd thought that I may have asked you this question in Munich and you told me this answer before. If so, oops. > > Not sure to add in an ending callback or an is_passing() method. Or both. > > > BTW How does one get the current srand if you use the one set by Perl? I don't think it's possible. I think I'm going to have to overload rand and do the srand thing by hand. (and probably overload srand in case anyone else is attempting to go behind my back) Nicholas Clark
callbacks at the end of Test::More ?
I'm intending to write a module to work with Test::More to provide repeatable "random" tests (ie take advantage of the pseudo random nature of rand). I discussed it with Schwern at YAPC::EU and he thinks it will work. However, I'd like to be able to cleanly print out my random number seed to STDERR (or whatever Test::Builder's correct name for this is) if it believes that any tests have failed, and I can't see a clean way to do this. When I was experimenting with this idea at work I hacked things by having an END block that checked $?, and if it was non-zero printing out the seed. However, this doesn' seem to be a good idea for production code. Is there a way to achieve such a callback from Test::Builder? It looks like there isn't, as the logical place would be in Test::Builder::_ending after it has worked out the number of passing and failing tests. If so, could I make a feature request for some way to register such a callback. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [ANNOUNCE] tv (Test::Verbose 0.001)
On Thu, Oct 24, 2002 at 09:57:48AM -0400, Barrie Slaymaker wrote: > New! Improved! As Seen On TV!! > > ahem. > > tv is a command bundled with Test::Verbose that puts an easier, smarter > interface around the ExtUtils testing system. But does it come complete with a free Schwern to write your tests for you? That's what I want. :-) [To be honest, I don't care if it's a Schwern (closure) who merely puts it onto his (captured lexical) $TODO, as long as there's also a reference to Chromatic to actually get a round tuit. That still gets my tests written for me with maximal laziness] Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Test::Class - comments wanted
On Sun, Oct 13, 2002 at 04:01:10PM -0700, David Wheeler wrote: > On Sunday, October 13, 2002, at 10:05 AM, Tony Bowden wrote: > > >> Makes it simpler for people who prefer the 'no_plan' style of > >> testing > > > >Maybe this is what I just don't get. I'm not one of those people, so I > >don't really understand why people might prefer it. Especially here > >where there's such a natural way to specify them, and you're only > >counting them per method, rather than over the entire test. > > I have to agree with Tony. I think it's important to explicitly > indicate the number of tests that a given method runs, and to be > explicit about saying when you're not sure how many tests there will > be. In that regard, I like the current design better, although I would > have no complaint if you decided to change the string "no_plan" to > something else. Me too. In that I'd not like "no plan" to be the default. I'd like it to be necessary to explicitly choose no plan. I'm not sure if it is helpful (or even a good interface) but it's possible to count the number of arguments in @_, and thereby distinguish between no arguments and 1 undef argument. It's just that saying "pass a literal undef for no plan" is about as clear as "no_plan". Empty string is probably clearer, and quite easy to test for (with length, after a defined || croak test) Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Some upcoming changes to Test::Builder
On Mon, Oct 14, 2002 at 09:00:42PM -0400, Michael G Schwern wrote: > 5.8.0's threads are giving me serious headaches. When 5.8.1 comes out I > might drop support for 5.8.0's threads just so I can remove a large volume > of work-around code. Leaving support for 5.005 threads in? I'm confused. Or do you mean dropping all automatic threading support? In which case, how does one test threaded code? [not that I've written any] Will there be an explicit thread testing module? Nicholas Clark
Re: [ Memory ] Re: Thought
On Sat, Oct 05, 2002 at 03:50:34PM +0200, Tels wrote: > Nevertheless, making your data structures smaller will help, even if in > some particulare case it doesn't reduce the heap usage directly. Yes, I found this to be true, but on my hitlist of things that make your perl script slow, it was number 3, with raw CPU usage as number 2, and Ops as number 1. [ie play Ops golf, even if you think you'll be using more CPU or more RAM with your way of doing it in less Ops. And unlike conventional perl golf, that's sum total Ops encountered at runtime, not total Ops used] I did a talk about optimising perl code at YAPC in Munich. I'm going to use this as an opportunity to blatantly plug the fact that I've put it online: http://www.ccl4.org/~nick/P/Fast_Enough/ because it might contain one or two ideas that people haven't thought of. People who saw it at YAPC may not want to read it *yet*, because I've not incorporated more bits based the several other good ideas *I* hadn't thought of that other people told me. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [ Memory ] Re: Thought
On Thu, Oct 03, 2002 at 02:35:14PM -0400, Benjamin Goldberg wrote: > If "what it does" is merely return the value of the C sbrk() function, > then IMHO, sbrk() is a perfectly good name. > > However, as to other possible names -- how about ProcessSize() ? I'm > not sure if this is really a valid description of what sbrk() returns, > though. I'm not certain it's as accurate as we might like to think. I am under the impression (quite possibly wrong, as I don't have the source code handy) that 1: Doug Lea's malloc will do anonymous mmap() to satisfy really big requests 2: glib malloc is a variant derived from Doug Lea's code Hence is it plausible that systems exist where the malloc that perl calls may normally get memory from the system with sbrk(), but occasionally use somewhere other than the system heap. So perl code might cause more memory to be used, but if we report back sbrk() as process size we're actually claiming a bit more for our "fact" than we can actually be sure of. If we call it sbrk() we can divorce ourselves from actually claiming that it is the one true source of memory :-) Not that this is helpful - I guess we want a direct sbrk() interface if sbrk() is on the system, and a process size interface that makes the best estimate it can. But I'm not writing this thing, and so far I guess I've not wanted it *that* much. [mm. maybe I have. number 3 on my hitlist of "what slows perl" is RAM. So seeing if a data structure change reduces RAM is interesting to me, the encode compiler, and everyone building perl from source] Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [ Memory ] Re: Thought
On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote: > On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote: > > > I realize that sbrk() is a familiar concept to deep C programmers on > > > BSD-style systems, but in order for this to be useful to Perl programmers, > > > or even users not familiar with BSD, you're going to have to name it > > > something more descriptive than sbrk() and explain better what it does. Is it going to be useful (see below) to people who don't know this sort of thing? > > That's why there /is/ an Internals.pm: to hide the gory details and > > implementation specifics to the user. > > But you're not. You're just exposing sbrk(), which is a gory detail. My > sbrk man page describes sbrk as being used to find "the current location of > the program break" which means nothing to me. Nor does "returns the current > memory top". > > It'll be even worse on an OS which doesn't have sbrk, which means no sbrk(2) > man page to look at. > > Does sbrk() just return the current number of bytes allocated to the > program? If it only returns the value from sbrk(), damn well call it sbrk. That's what it is; don't invent a new name. It will only cause confusion later for anyone who does migrate from perl to dealing with unix guts, or needs to talk to someone who does know what sbrk() is. (Oh. we're going to call this concept pels. You may hear other people call them pixels...) The reason I'm saying it might not be much use to people unfamiliar with the internals of unix is precisely because it does return a precisely defined but not directly useful value - the highest address on the heap. If you read it, call perl code that creates a known perl structure, and read it again, doesn't go up directly and exactly related to the amount of memory that structure needed. Depending on how much other memory there is free, it may not go up at all, or it may go up more if the allocation system grabs a big block of free space. However, the function returns something that may not be sbrk() on a system without sbrk(), don't call it sbrk, because it ain't. (And do document what it does return on each different system) Nicholas Clark
Re: [ Memory ] Re: Thought
On Wed, Oct 02, 2002 at 05:06:53PM +0200, Tels wrote: > On 02-Oct-02 H.Merijn Brand carved into stone: Going to be a bit hard to change, then :-) > > As a start for a `normal' interface to the interperters internals, this > > time no open hack, but a neat interface. > > Very open to additions. > > Useful? > > Is it accurate? > > > Feedback please > > > > > > NAME > > Devel-Internals - Perl extension for internal interpreter > > statistics > > > > SYNOPSIS > > use Devel::Internals; > > > > my $end = sbrk (); > > Can you please use a better name? sbrk() doesn't mean anything to me. Trouble is that it's entirely accurate. If you know what sbrk() is in Unix, then you know that this would return it. The value is not directly memory used or anything like that. It's the current sbrk() :-) Nicholas Clark
Re: Why not a smoke db ?
On Sat, Sep 21, 2002 at 05:50:45PM +0200, alian wrote: > After see a smoke report from Nicolas Clark using ccache, I took a look > at ccache web site. And find http://build.samba.org. Oooh, they've got a Cray in theirs. > So I've begin something like this, thing I would see on http://qa.perl.org: > http://www.alianwebserver.com/cgi-bin/smoke_db > > Comments are welcome. Part in English, part in French? :-) I suppose that I should be thankful that it's not part Finnish, part Tamil. On Mon, Sep 23, 2002 at 04:59:21PM +0200, Abe Timmerman wrote: > Op een mooie herfstdag (Monday 23 September 2002 16:14), schreef Alain Barbet: > > > Jarkko Hietaniemi wrote: > > http://www.alianwebserver.com/cgi-bin/smoke_db > > > > > Looks great! Some suggestions/questions: > > > - freebsd os version missing? > > > > Yes it's missing info from Nicolas Clark reports. > > That is due to the combination of 1.13 and changed Config.pm (should be solved > in 1.15). And as I seem to be running 1.06 (with tweaks) this would explain why you're not seeing it. I'll try to send a patch to merge the tweaks back in, plus then try to get around to making the changes mentioned at YAPC::EU (splitting the commands run for make regen_headers out into a script, calling that script instead of make regen_headers in the smoke harness, and the option of multiple build trees where copying (or hard link forestry) is faster than make distclean) But that's at least number 3 on my todo list (after sorting out the spoofathon, getting the script for my YAPC::EU talk written down and online) > > > - at least for the linuxes and bsds > > > it would be useful to have also > > > the CPU architecture in the > > > report (not all boxes are x86) Nor are all Solaris boxes sparc. (or x86 for that matter - it was internally ported to alpha to check 64 bit cleanliness before true 64 bit sparc chips were available) > > k, but this is a missing info from smoke report. > > I can add $Config{archname} to the smokereports if you all want that. That would be good. Nicholas Clark
Re: Eliminating the core-test BEGIN block (was Re: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting])
On Mon, Sep 02, 2002 at 03:56:14PM -0700, Michael G Schwern wrote: > While the result is still ugly, it means we can expand and alter the > requirements for running a core test. For example, the PERL_CORE > environment variable should be set (t/TestInit.pm currently doesn't). So > the full command is really something like this: > > cd t; > PERL_CORE=1 ./perl -I../lib path/to/test.t > > Which could be reduced somewhat to: > > ./perl -It -MTestInit t/path/to/test.t > > and perhaps reduced a little further by moving/linking TestInit.pm into the > top level directory. > > ./perl -MTestInit t/path/to/test.t I think that that would be a good idea. > but that will cause trouble when running tests with -T (because . is no > longer in the path). ../perl -MTestInit t/path/to/test.t Too late for "-T" option at t/path/to/test.t line 1. So you already have to change the command line to run a -T test by hand. So I don't see this as a problem: ../perl -TI. -MTestInit t/path/to/test.t 1..1 ok 1 Although writing it -T -I. is probably clearer Nicholas Clark
Re: Fwd: [ken@mathforum.org: Re: [Inline 0.43] insecure dependency when tainting]
On Thu, Aug 29, 2002 at 12:29:58AM -0700, Michael G Schwern wrote: > Also, Nick's example is a little odd. You usually don't want '.' (ie. t/) > in your @INC. It's more like this: > > BEGIN { > if($ENV{PERL_CORE}) { > chdir 't'; > @INC = '../lib'; > } > } > > but in some cases you need to include something more. For example, > MakeMaker does this: > > BEGIN { > if($ENV{PERL_CORE}) { > chdir 't'; > @INC = ('../lib', 'lib'); > } > else { > unshift @INC, 't/lib'; > } > } > > so it can see specialty helper modules in t/lib/. > On Thursday, August 29, 2002, at 06:51 AM, Nicholas Clark wrote: > >You'll often see regression tests in the core start like this: > > > >sub BEGIN { > >if ($ENV{PERL_CORE}){ > > chdir('t') if -d 't'; > > @INC = ('.', '../lib'); > >} else { > > unshift @INC, 't'; > >} For information, my example was from the top of t/integer.t in Storable It looks like the same bit of code was cargo-cult cut & pasted (er, by me I think) from the other Storable tests (such as freeze.t) where they have to require 'st-dump.pl'; to get a library of useful test routines. I'm not sure if Storable was actually the best (cleanest, simplest) thing to snag the example code from. Nicholas Clark
Re: Testing POSIX locale support
On Mon, Aug 26, 2002 at 04:05:26PM -0400, John Peacock wrote: > I have a module, Math::Currency, which tries to be very smart with regard > to POSIX locale settings when defining the default currency formatting. > However, since I can only test on _my_ systems, I am limited in my ability > to guess all of the strange locale settings that may be in use. > > Specifically, in order to test that the locale stuff is working, I need to > have two different locales installed to switch between. Currently, I am > using en_US and en_GB, but obviously that ignores most of the planet. This doesn't answer any of your questions (sorry) but IIRC on p5p it was found that fa_IR caused quite a lot of "fun", as it used a character for the decimal separator that was multibyte. (certainly for standard numerics, which is what core perl was concerned with. No idea about monetary values, and as I don't understand any Farsi or have any Farsi fonts installed, it's not going really to help if I have a look.) So you may wish to install fa_IR and test with that. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: RFC: Test::ManyParams
On Tue, Aug 06, 2002 at 06:42:14AM +0200, Janek Schleicher wrote: > I think the most fair way to handle it, > is to give a warning when Test::ManyParams is used twice with seeding setting > in the same package. Yes. This sounds like what I'm doing at work - if two attempts to call the seeding function are made, then a warning is issued. I can't think of a better way, and it does seem to work. The only problem I found was "unauthorised" use of rand() before the official call to srand() had been made. I'm not sure of the best way to stamp that out - possibly by overloading CORE::GLOBAL::rand at BEGIN time. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: RFC: Test::ManyParams
On Fri, Aug 02, 2002 at 08:16:17AM +0200, Janek Schleicher wrote: > Ilya Martynov wrote at Fri, 02 Aug 2002 07:42:44 +0200: > > >>>>>> On Wed, 31 Jul 2002 21:52:17 +0200, Janek Schleicher <[EMAIL PROTECTED]> >said: > > > > JS> [..snip..] > > > > JS> Thinking in general, > > JS> there could be also some other features included. > > JS> Let's think we'd like to test the creation of big pictures, > > JS> perhaps 5_000 x 5_000. > > JS> It could take a while to make a test for all pixels, > > JS> but we also would like to test some of them (randomly choosen), > > JS> to avoid systematic error. > > > > Test results should be easily reproducible. I don't think having > > randomly choosen tests is good idea. I think having randomly chosen repeatable tests is an excellent idea. Over the course of many people making many test runs explore far more of parameter space than any single systematic test permutation device could hope to achieve. > srand could be our friend. Which is how I'm doing it at work now. I call srand with a random number. (I'm getting mine from /dev/urandom, but I suspect that calling rand() and using that to prime srand will achieve sufficient randomness for these purposes. (ie you get to run one of 65536 sequences, which is better than running 1 of 1 sequence) My tests at work generate a seed this way before starting. They call srand with the seed, and store the seed. If the test fails, they print out what the seed was on STDERR. (as a hack in an END block that checks the exit code after Test::Builder has set it in its END block) If the test is run with no arguments it randomises (as above). Else it treats the argument as a chosen seed, and uses that to call srand() to repeat a previous run. This way I can make test a few times and it runs different random parameters each time. And if a test fails, it prints out the seed, and I can re-run repeatedly by hand until I work out why there is a bug. And fix it. I've found bugs this way that I wouldn't have spotted early by just running a fixed set of parameters in my tests each time. Mainly because I make test many times during the day as I make each incremental change (so each make test has to be fast) which immediately picks up on big bugs, but the incremental effect can find really obscure bugs that only crop up for a small proportion of possible input. > However, it's not important for me that the parameters are really randomly choosen - > > allthough I still would prefer to have some before I release a module - > but I'd like to write tests to avoid systematic mistakes, > while it would need too long to test all scenarios. This is the problem that I have, and I think I've found a solution that works for me. Nicholas Clark
Re: [perl #15479] perl 5.8.0 segfault
On Wed, Jul 31, 2002 at 01:20:25PM +0200, Rafael Garcia-Suarez wrote: > Wasn't there a .t file to run separate perl interpreters > and test for core dumps ? I keep forgetting that I need to remember to ask this. Is there a FAQ for regression test writing? Well, an guide to "so I want to write a regression test, explaining how to do it, how perl5's tests are structured to reduce interdependencies, use Test::More; when Test::More is not appropriate.." And where did the p5p FAQ get to? Nicholas Clark
Re: Test::Harness skip reason report change?
On Fri, Apr 26, 2002 at 11:39:26AM +0400, Ilya Martynov wrote: > Looks nice. But I'm curious if it will be possible to see skip reasons > with new formatting if one test had several different skip > reasons. Currently it just emits 'skipped: various reasons'. on the "looks nice". I hadn't thought of the better list of reasons, but I agree with what that too. However, if there are 50+ different skip reasons, would it be better to have some sort of cutoff on the amount of extra data per test to show. Something like 10, and then it a ... line and tells you to run the test to see the full output? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: How to test for the absence of an infinite loop?
On Mon, Mar 18, 2002 at 03:57:55AM -0500, Mark-Jason Dominus wrote: > > Michael The Schwern <[EMAIL PROTECTED]> says: > > Use alarm and skip the test if $Config{d_alarm} is false (see > > t/op/alarm.t for an example). If you think the infinite loop is due > > to a programming glitch, as opposed to a cross-platform issue, this > > will be enough. > > Thanks very much! > > > The only other thing I can think of is to set up a parent process > > which forks off a child > > ARRRGH. NO FORK. On Mon, Mar 18, 2002 at 04:33:48PM +, Nick Ing-Simmons wrote: > FWIW system() does create a new process on Win32, but fork() does not > (in only creates a new thread). I have no idea if flock-faking stuff > on Win32 allows recursive locks by different threads of the same process ... One of my TODOs (preferably sooner rather than later) was to see if this bit of ext/Socket/socketpair.t could be generalised enough to end up in test.pl and provide a portable self-destruct timer (for infinite loops and other infinite hangs): BEGIN { chdir 't' if -d 't'; @INC = '../lib'; require Config; import Config; $can_fork = $Config{'d_fork'} || ($^O eq 'MSWin32' && $Config{useithreads} && $Config{ccflags} =~ /-DPERL_IMPLICIT_SYS\b/); if ($^O eq "hpux" or $Config{'extensions'} !~ /\bSocket\b/ && !(($^O eq 'VMS') && $Config{d_socket})) { print "1..0\n"; exit 0; } # Too many things in this test will hang forever if something is wrong, # so we need a self destruct timer. And IO can hang despite an alarm. # This is convoluted, but we must fork before Test::More, else child's # Test::More thinks that it ran no tests, and prints a message to that # effect if( $can_fork) { my $parent = $$; $child = fork; die "Fork failed" unless defined $child; if (!$child) { $SIG{INT} = sub {exit 0}; # You have 60 seconds. Your time starts now. my $must_finish_by = time + 60; my $remaining; while ($remaining = time - $must_finish_by) { sleep $remaining; } warn "Something unexpectedly hung during testing"; kill "INT", $parent or die "Kill failed: $!"; exit 1; } } } The idea being that a test killing itself after elapsed time (and failing to return some results from that test) is better than a test hanging forever and causing a whole automatic test run to fail. [and in the case of a busy hang, rather than an idle hang, munching shared CPU] Also, did the Windows Gurus work out why the above didn't like Win95? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: [Patch docs] perlsub. Re: [ID 20020227.012], [ID 20020227.018]
On Thu, Mar 07, 2002 at 01:25:55AM +0300, Anton Tagunov wrote: > Hi! How about this? > > --- pod/perlsub.pod.origWed Feb 20 18:02:38 2002 > +++ pod/perlsub.pod Thu Mar 7 00:30:53 2002 > @@ -169,7 +169,7 @@ > > Like the flattened incoming parameter list, the return list is also > flattened on return. So all you have managed to do here is stored > -everything in C<@a> and made C<@b> an empty list. See > +everything in C<@a> and made C<@b> an empty array. See Not sure. I'd like to find a way to phrase that without describing @b as either "list" or array. It's set to an empty list, but it is an array. And finding a way of saying that without using either word feels best. > L for alternatives. > > A subroutine may be called using an explicit C<&> prefix. The > @@ -727,8 +727,8 @@ > > sub ioqueue { > local (*READER, *WRITER);# not my! > -pipe(READER, WRITER);or die "pipe: $!"; > -return (*READER, *WRITER); > +pipe(READER, WRITER) or die "pipe: $!"; > +return (*READER{IO}, *WRITER{IO}); > } > ($head, $tail) = ioqueue(); > > --end of patch-- > > > Have I been too bold with adding {IO}? To tell the truth I do > not understand what is happening completely, so it's again a > blindfolded strike. I guess that with my patch instead of > typeglobs this sample starts returning references to file handles. > > Is that okay? Is that smth to recommend to people? Not sure. I'm not sure what's going on with the IO, but it's late an I'm tired. However, I'm replying because I can see a syntax error that the patch removes, and as nothing has been applied, that syntax error remained. Was there ever a feasible plan on how to automate syntax checking of all the code examples in the pod snippets? [I remember this rant I had about perlipc once. (rant-and-patch, IIRC) I also remember another thing that fell off my to-do list - try to make some of the perlipc examples into regression tests. That was related to the SOCKS5-rant] Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: More Test::Builder::Test stuff
On Sun, Feb 17, 2002 at 02:00:06PM +, Mark Fowler wrote: > On Sun, 17 Feb 2002, Mark Fowler wrote: > > > I'd really like to see that it still works on a system that > > doesn't have Term::ANSIColor installed on it (it should turn colouring > > into a no-op and skip tests, but I can't test that.) > > D'Oh! No it shouldn't. As color should work (just without colouring) on > systems that don't have Term::ANSIColor installed then the tests shouldn't > be skipped at all, they should be carried out to explicitly check that > then still work without it. > > Code updated so that it should do just that. I think that if you have enough disk space you should be able to build yourself a second perl install that doesn't have Term::ANSIColor installed, by configuring perl to use a different prefix and ensuring it doesn't have any of the "standard" places to find libraries in INC. Alternatively, if your Term::ANSIColor is installed in 5.6.1's directories, just build yourself a 5.005_03 in the regular place :-) Nicholas Clark -- EMCFT http://www.ccl4.org/~nick/CV.html
Re: Untested modules update: The Magic Number is 27
On Thu, Dec 27, 2001 at 09:11:26AM -0800, Benjamin Stuhl wrote: > --- Michael G Schwern <[EMAIL PROTECTED]> wrote: > [... and the shears went snip, snip, ker-snip ...] > > #B::Bytecode[module broken, can't test] > > #B::C [ditto] > > #B::CC [ditto ditto] > > #B::Concise [[EMAIL PROTECTED]] > > #B::Disassembler[Wolfgang Laun] > > #B::Lint[[EMAIL PROTECTED]] > > #B::Stackobj[[EMAIL PROTECTED]] > > #B::Xref[[EMAIL PROTECTED]] > > Byteloader > > Byteloader is untestable without a working B::Bytecode (we > have no way of generating input files for it. Anyway, > Byteloader/B::Bytecode are actually speed _losses_, so IMHO > they should probably simply be killed - they're just wasted > space in the distribution. (IIRC, I was the last person to > seriously hack on them.) And if they get removed from the > core, they obviously don't need tests ;-). I think I agree on all of this. ("think" in that I've read it twice and can't see any obvious reason why I'm going to be able think of any counter arguments between now and perl6) > > Dynaloader > > What sort of test does Dynaloader need? If dynaloading > doesn't work, no dynamic extensions (Socket, Fcntl, IO, > POSIX, ...) will work, and the errors they'll spew are > pretty obviously loading problems. XSLoader::load 'POSIX', $VERSION; XSLoader::load 'Fcntl', $VERSION; XSLoader::load 'Socket', $VERSION; XSLoader::load 'IO', $VERSION; although that's a biased picture as it appears that many other core extensions are using its interface directly, rather than via the featherweight XSLoader. (including Encode.pm, I18N.pm, threads.pm threads/shared.pm) >From its pod: DynaLoader Interface Summary @dl_library_path @dl_resolve_using @dl_require_symbols $dl_debug @dl_librefs @dl_modules Implemented in: bootstrap($modulename) Perl @filepaths = dl_findfile(@names) Perl $flags = $modulename->dl_load_flags Perl $symref = dl_find_symbol_anywhere($symbol) Perl $libref = dl_load_file($filename, $flags) C $status = dl_unload_file($libref) C $symref = dl_find_symbol($libref, $symbol) C @symbols = dl_undef_symbols()C dl_install_xsub($name, $symref [, $filename])C $message = dl_error C so I guess that as much as that as possible, preferable all needs testing (in an ideal world. As I found with Benchmark.t, trying to test everything gets quite big. And it had less things than Dynaloader.) Nicholas Clark