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
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: [ 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: 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: [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: [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 Ca and made Cb an empty list. See
+everything in Ca and made Cb 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.
LPass by Reference 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
