Re: lexical aliases in 5.10?
* Ricardo SIGNES <[EMAIL PROTECTED]> [2007-05-26T08:38:15] > perl591delta lists this todo for 5.10: > > Allow lexical aliases (maybe via the syntax "my \$alias = \$foo". I have no idea why "p5p" in my aliases file was an alias for p6l. Clearly I have my own problem with aliases. Sorry for the noise. -- rjbs
lexical aliases in 5.10?
perl591delta lists this todo for 5.10: Allow lexical aliases (maybe via the syntax "my \$alias = \$foo". I seem to recall some discussion of this, but not any specifics, and lazy Googling wants me to think it was all in 2002. It doesn't seem to be implemented. Was this put off until a future version? -- rjbs
Re: Proposal Suggestion - Test::Run [was Re: [Israel.pm] Fwd: Call for proposals -- Perl Foundation Grants]
* Shlomi Fish <[EMAIL PROTECTED]> [2006-07-05T15:28:28] > The grant is about Test::Run, which is a fork of Test::Harness that aims to > greatly refactor and modularise it. I've already revamped and re-written a > lot of code for it, but there's still a lot that needs to be done. [...] > Some of the code in Test::Run is derived from the code of Test::Harness, > which is GPL+[Artistic 1.0]. Thus, it should be kept this way. However, some > code was written from scratch and due to my personal preferences, it was > licensed under the MIT X11 Licence[1]. I prefer that all new code will be > also MIT X11 licence, and that existing code will retain its original > licensing terms. [...] > TAP::Harness is a rewrite of Test::Harness by Michael G. Schwern and others. So, you want to have someone (other than you) work on a project that largely seems to duplicate the functionality of existing code. Among the existing code whose functionality is being duplicate is code still under development. The other project is being done with no TPF funding and will be capable of becoming part of the core in future Perls, largely superseding the existing test framework. You want funding for a parallel project that will be not be license-compatible with the core. I don't see how this would be worth TPF's money. It might be a very useful project for people who use the code or for people who want to steal ideas, but I don't see how it fills a really critical void in the language or its toolset. -- rjbs signature.asc Description: Digital signature
Re: Running individual unit tests with Test::Class???
* Adrian Howard <[EMAIL PROTECTED]> [2006-05-31T10:55:20]
> In short
> * Yes running one test method at a time is a sensible things to do.
> * No - there currently isn't a simple way of doing this
> * Good news - Ovid has submitted a patch to make it easy
> * Bad news - I've been too bone idle to apply it
Potentially too clever idea:
# In your test unit class:
sub import {
my ($class, @tests) = @_;
# startup;
$test->$_ for @tests;
# teardown;
}
Because then:
perl -I lib -I t/lib -MTest::Your::Code=basics,extra,weird -e0
This might end up being too clever and too much typing, anyway.
--
rjbs
signature.asc
Description: Digital signature
Re: Unintended consequences
* Adam Kennedy <[EMAIL PROTECTED]> [2006-05-27T23:48:43] > The questions that are being asked are for the user's benefit. That is > NOT being a freeloader. Freeloading is taken something from the user and > providing nothing in return. She's providing her free code in return. -- rjbs signature.asc Description: Digital signature
Re: CPANTS is not a game.
* Michael G Schwern <[EMAIL PROTECTED]> [2006-05-23T12:46:13] > So I guess its down to this: pick a goal. Either drop the gaming aspects or > drop any remaining pretense that its a measurement of module quality. Since > the whole kwalitee thing is pretty flimsy to begin with, I'd go with just > making it a distribution improvement game. That's what it seems to do best, > what people like to use it for and games are fun! I've always seen it as a distribution quality tool; I just don't think it can really measure module quality in any useful way. I'd vote, were I the voting type, for continued work in that direction. -- rjbs signature.asc Description: Digital signature
Re: Non-Perl TAP implementations (and diag() problems)
* Fergal Daly <[EMAIL PROTECTED]> [2006-04-19T15:24:51] > On 4/19/06, Ricardo SIGNES <[EMAIL PROTECTED]> wrote: > > > > There are other things that test test output, like Test::Tester. Will they > > break? To find out, I downloaded a pristene copy of the latest Test-Simple > > and Test-Tester and changed Test::Builder to use STDOUT for failure_output. > > The only test that failed in the whole set was one that checked whether > > failure_output defaulted to STDERR. > ... > I'm not sure what test you are referring to, as far as I can tell, > Test-Tester doesn't check anything about failure_output. What .t file > is it in? When I said "the whole set" I meant "the whole set [of tests from Test-Simple and Test-Tester." That particular test was part of Test-Simple, t/reset.t, which checks that on reset failure_output is again TESTERR. -- rjbs signature.asc Description: Digital signature
Re: Non-Perl TAP implementations (and diag() problems)
* Ovid <[EMAIL PROTECTED]> [2006-04-19T04:02:31] > From a parser standpoint, there's no clean way of distinguishing that > from what the test functions are going to output. As a result, I > really think that "diag" and normal test failure information should be > marked differently (instead of the /^# / that we see). I strongly agree. This came up when TAP was being named, and also during a previous Harness upgrade. Unfortunately, Harness and Straps discard comments and, as mentioned before, the STDOUT/STDERR makes it hard to associate diagonstic output with tests. How many things rely on which stream the various output methods in Test::Builder use? I know there was trouble last time that things changed, but wasn't that entirely because of the disconnect between Test::Builder and Test::Builder::Tester? Since they're now together, isn't that particular issue solved? There are other things that test test output, like Test::Tester. Will they break? To find out, I downloaded a pristene copy of the latest Test-Simple and Test-Tester and changed Test::Builder to use STDOUT for failure_output. The only test that failed in the whole set was one that checked whether failure_output defaulted to STDERR. I think that a real investigation into the impact of using one stream by default is in order. -- rjbs signature.asc Description: Digital signature
Re: Non-Perl TAP implementations
* Ricardo SIGNES <[EMAIL PROTECTED]> [2006-04-16T23:33:19]
> It's not really ready to be publicized, and I haven't touched it in a little
> while, but I'll mention PyTap: http://svn.codesimply.com/projects/pytap
I got a request, off-list, for more info, so here is some:
PyTap will, when it's done, provide a simple, assertive
(Test::Builder/More-like) interface for writing tests in Python. It will
output TAP and will include the functionality found in Test::Builder and
Test::More. It will try to make it easy to add more test code (so you can
write your own TAP.StringDiff, for example.
Right now, it's got a fair bit of the basics needed to emulate Test::More, and
I think it's easy to add more stuff -- just like Test::Builder, there's a
singleton that you can get at easily.
I need to better identify and finish implementing the most basic tests. I am
not a Python guru, I just use it from time to time, so my aim may not be true.
I need to write tests for it, which means either relying on Perl for the tester
tester, or writing one in Python.
Here's a sample test, as found in my Subversion:
from TAP.Simple import *
plan(15)
ok(1)
ok(1, "everything is OK!")
ok(0, "always fails")
is_ok(10, 10, "is ten ten?")
is_ok(ok, ok, "even ok is ok!")
ok(id(ok),"ok is not the null pointer")
ok(True, "the Truth will set you ok")
ok(not False, "and nothing but the truth")
ok(False, "and we'll know if you lie to us")
isa_ok(10, int, "10")
isa_ok('ok', str, "some string")
ok(0,"zero is true", todo="be more like Ruby!")
ok(None, "none is true", skip="not possible in this universe")
eq_ok("not", "equal", "two strings are not equal");
--
rjbs
signature.asc
Description: Digital signature
Re: Non-Perl TAP implementations
* Andy Lester <[EMAIL PROTECTED]> [2006-04-16T23:08:26] > I'm adding a section to Test::Harness::TAP on non-Perl TAP. > > http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod > > If you know of one, please send me some text to add. It's not really ready to be publicized, and I haven't touched it in a little while, but I'll mention PyTap: http://svn.codesimply.com/projects/pytap I'll get it in a useful state soon. Comments from more regular producers of Python code are welcome. -- rjbs signature.asc Description: Digital signature
Re: Module requirements
* demerphq <[EMAIL PROTECTED]> [2006-04-07T08:32:35]
> Actually afaik there is no good way to find out what dereferencing
> operators an object supports. The best that I know of is reftype(),
> but that only tells you the objects underlying intrinsic type, it
> doesnt tell you if you can dereference the type other ways.
I actually just ranted about this recently in my journal:
http://use.perl.org/~rjbs/journal/29229
This code should be relatively demonstrative:
sub _CALLABLE {
(Scalar::Util::reftype($_[0])||'') eq 'CODE'
or
Scalar::Util::blessed($_[0]) and overload::Method($_[0],'&{}')
? $_[0]
: undef;
}
--
rjbs
signature.asc
Description: Digital signature
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
* demerphq <[EMAIL PROTECTED]> [2006-04-05T10:23:45] > On 4/5/06, Ricardo SIGNES <[EMAIL PROTECTED]> wrote: > > That said, I don't dispute the point that it can be wildly obnoxious when > > "Something::Trivial" requires DBD::MySQL and Data::Dump::Streamer when it > > could use neither -- or at least rely on AnyDBM and Data::Dumper. It will > > just meant that fewer people want to use that trivial module because it > > takes longer to install and is less well-tested by virtue of its > > dependencies. > > Interesting example. What module do you mean? I wasnt aware that there > were very many modules that have dependencies on DDS. OTOH, if it has > to do with proper serilization (of closures, or cyclic data > structures) then Data::Dumper just wont cut it. I was making a random example of something that used something it probably didn't need, and that used something that might be emulable by core modules. -- rjbs
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-05T02:39:20] > I'll just mention two things, both very different > > A. CORE modules are tested on all supported architectures, while CPAN modules >do not give that guarantee. The smoke system still causes all possible >combinations to be tested on various architectures in various >configurations. Absolutely; this, I cede. > B. Let's just name YAML. Up until 0.38 it was not to difficult to install a >module that is very useful, but now in 0.58, it uses a different test >suite, that needs Spiffy, that needs .. Ugh, yeah, but you're picking a very specific and specifically troubled distribution. You also didn't mention (maybe you've been spared learning) that YAML used to export :all but now doesn't. That said, I don't dispute the point that it can be wildly obnoxious when "Something::Trivial" requires DBD::MySQL and Data::Dump::Streamer when it could use neither -- or at least rely on AnyDBM and Data::Dumper. It will just meant that fewer people want to use that trivial module because it takes longer to install and is less well-tested by virtue of its dependencies. >My opinion only. I don't think your opinion, as stated, is insane. I think it's better to vote with your installer, though, and avoid using those modules that have more dependencies than you think is right. I think that Kwalitee is an over-rated concept, but not useless -- but weirder things keep getting proposed to make it even less useful. I think "too many non-core deps" would be a nail in its coffin as a global metric. -- rjbs
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2006-04-04T10:40:39] > And then still people make more of the same. Take Getopt::Long. A perfect and > very functional module. Full of features, matured, and actively maintained. > Now go look at CPAN, and see how many people either do not like it or find > other reasons to write their own. > > The problems arise when authors of big modules start prefering non-core > versions of good core modules. IMHO something like that should give you a > (very) negative score on CPANTS. Could you elaborate on this? As stated, it seems pretty ludicrous to me. It reads like this: You should not use module B that is like module A, if A is in the core distribution. This is true regardless of the fact that B may be better optimized for your current needs, planned needs, programming style. This can be further distilled to: There's more than one way to do it, but most of them will get you dirty looks. -- rjbs
Re: TODO test paradox: better TODO test management?
* demerphq <[EMAIL PROTECTED]> [2006-02-01T03:26:55]
> And I think you've conveniently sidestepped my main point which is
> that TODO tests passing are errors. Consider you have two TODO tests,
> both of which depend on a common set of functionality. Both should
> pass or both should fail.
I just don't agree. I prefer the current model.
I defend your right to disagree, however, and support it with this idea:
strict_todo {
frobulate_ok("someone implemented frobulate()!!");
};
sub strict_todo(&) {
local $Test::Builder::OPPOSITE_WORLD = 1;
$_[0]->();
}
...where OPPOSITE_WORLD causes ok to be not ok, not ok to be ok, and cucumbers
to taste better pickled.
(I wouldn't exactly implement it that way, but you get the idea, and I bet that
a patch to provide test result reversal would not be unwelcome.)
--
rjbs
pgpSnXAlqhJnS.pgp
Description: PGP signature
Re: CPANTS: has_signature, has_pod_index
* Tels <[EMAIL PROTECTED]> [2005-11-06T09:44:14] > * has_signature: a SIGNATURE file exists, and is a valid signatur. That seems reasonable, even though I dread signing all my dists. I feel like it will be a big hassle, but maybe I'm just afraid of change. > * has_pod_index: The POD contains at least one X<> keyword that helps POD > indexers. Whether only one is usefull is open for debate, because at > least the license (X), your CPAN ID under authors (x), and > some generic keyword what your module (X) is about can probably > added even for the most minimal module. Can you give an example of how this has any practical impact on anything? -- rjbs pgptCl41nccsq.pgp Description: PGP signature
Re: Test::More behavior issue with Devel::Cover + patch
* Pete Krawczyk <[EMAIL PROTECTED]> [2005-11-03T12:46:48] > > The solution I see is to make sure the object can() isa(), thus avoiding > the die in the process: > It was using ->isa instead of UNIVERSAL::isa because isa might be overridden. Surely the same could apply to ->can. -- rjbs pgpe2GjbXn9Q1.pgp Description: PGP signature
Re: New kwalitee test, has_changes
* "Christopher H. Laco" <[EMAIL PROTECTED]> [2005-09-15T08:23:57] > > Would this look for Change OR ChangeLog? > Both seem to be popular on CPAN. ...and some modules have a HISTORY or CHANGES section of POD, and DBI has DBI::Changes. -- rjbs pgpcBJzXHBJhG.pgp Description: PGP signature
Re: Test::Code
* David Golden <[EMAIL PROTECTED]> [2005-08-12T09:10:21] > Won't "&is_code" get called that way? Should this be: > > ok defined \&is_code; No. C will do the right thing, here. Taking a reference to an undefined sub, however, will always return a defined value: a coderef that, when called, will throw an exception. -- rjbs pgpVEpN9BcRQj.pgp Description: PGP signature
Re: Self-testing kwalitee
* Adam Kennedy <[EMAIL PROTECTED]> [2005-07-11T10:10:31] > >Note: The last kwalitee test, the one related to Devel::Cover, is > >considered dangerous by a non-trivial percentage of the community, > >and there's been a lot of debate on whether it should be removed. > > Sorry, I should have said Pod::Test::Coverage. > > Regardless, it executes code. I wonder how it deals with testing > Acme::BadExample. Remind me to put in a hard infinite loop. I don't think you understand the test. CPANTS did not check for POD coverage, it checked that you seemed to have a pod coverage test. You could create one that did nothing, and that caused the test to pass. CPANTS does not evaluate your code, it just looks at it. The objection was that some people don't want to distribute that kind of test, because its results are for the developer's benefit, not the user's. -- rjbs pgp76Z9L9ZWcd.pgp Description: PGP signature
Devel::Cover and HTTP::Server::Simple
Yesterday, hide gave me some sweet example code to use HTTP::Server::Simple and Test::WWW::Mechanize to test Rubric's CGI bits. I've started working with them, and they make me happy. I've realized that the server, which is forked from the test script, doesn't have its usage show up in Devel::Cover. I can see why that would happen but... I'm so addicted to the awesome utility of coverage reports that I am loathe to have to cope with half my code being so hard to cover. Does anyone have a good idea on how to make this work? -- rjbs pgpH0taOVxrvY.pgp Description: PGP signature
Re: Test::Expect
* Adrian Howard <[EMAIL PROTECTED]> [2005-04-14T15:37:07] > On 14 Apr 2005, at 11:36, Leon Brocard wrote: > >Oh, I forgot to mention to perl-qa that I wrote Test::Expect: > > http://search.cpan.org/dist/Test-Expect/ > > It's nice. Already used it :-) Does anyone who has used both Test::Expect and Test::Output feel like giving a simple comparison? -- rjbs pgpqdwYiXXJrd.pgp Description: PGP signature
Re: Why a scoreboard?
* Adam Kennedy <[EMAIL PROTECTED]> [2005-04-06T23:29:40] > >Finally, the scoreboard does have a purpose. Part of the original idea of > >CPANTS was to provide an automated checklist for a good distribution. > > > >Has a README... check > >Declares a $VERSION... check > >Well behaved tarball... no > > And as far as I can tell, got sidetracked along the way with "scores". > People have to actually fiddle to work out what there scores are... > > Where's the per-module page on CPANTS that lists these simple check/fail? > > Where's the per-author page that has the great big table with module > name down the side, and test names across the top and green/red boxes > indicating pass/fail? http://rjbs.manxome.org/cpants/cpants.ql source: http://rjbs.manxome.org/cpants/cpants.ql.txt -- rjbs pgpPA6R7omDmc.pgp Description: PGP signature
Re: Why a scoreboard?
* "David A. Golden" <[EMAIL PROTECTED]> [2005-04-02T05:27:18] > Andy Lester wrote: > >Why is there a scoreboard? Why do we care about rankings? Why is it > >necessary to compare one measure to another? What purpose is being > >served? > > Why is there XP on perlmonks? Or Karma on Slashdot? Or for that > matter, why do we grade students' exams (particularly, why do we often > grade them on a curve)? This is not a good analogy to Kwalitee, because XP and Karma are primarily awarded by humans who can make judgements based on reason. Kwalitee is a judgement based on statistical analysis. What if XP on perlmonks was awarded by automated grammar analysis, use of "strict" in code snippets, and the finding of dictionary words in acrostic interpretation of paragraphs? That wouldn't be so good. > I think the advantage of a scoreboard system is that metrics like this > are a motivator. Absolutely! Do we want to motivate people to go back and add pod-coverate.t when they already use Devel::Cover? Or would we rather they improve clarify of documentation? Et cetera. I think the scoreboard is fun and cute, but I think that there is an extent to which people are going to let it distract them from actual improvements. -- rjbs pgpEP9LybWthq.pgp Description: PGP signature
Re: Uncle Bob on Coding Standards
* "H.Merijn Brand" <[EMAIL PROTECTED]> [2004-12-14T11:28:19] > About spaces, another thing springs to mind, for which I would gladly kill the > responsible people to allow it (I bet M$ was the first to push it): Spaces in > database table and field names. DON'T! NEVER! Once you start it, you will > never be able to escape the quicksands of (incompatible) quotation and > unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql SELECT rsUniqueId FROM [SQL-ABCdatabase2K]..tblsTABLE as t JOIN [SQL-ABCdatabase2K]..tblwPRODUCT p ON p."ABC P/N" = t.rsProductCode WHERE p.id IN (SELECT ItemIdentifier FROM tblSomeIds) Yup. -- rjbs pgpTjX4YpMvlh.pgp Description: PGP signature
Re: [Devel::Cover] @INC at Runtime?
* David Wheeler <[EMAIL PROTECTED]> [2004-09-17T00:51:22] > So, what's to be lost by having the inc directories default to the > contents of @INC when you load Devel::Cover rather than at install > time? Presumably the problem is that by runtime, lib and blib directories are already in @INC, so the things in your ./distro/lib/ won't be covered, defeating the point. As to whether there is a simple way to resolve this, I haven't thought about it. -- rjbs pgpWQxoAayAHH.pgp Description: PGP signature
Re: Test::Harness/prove: printing the test name when a test fails
* Andrew Savige <[EMAIL PROTECTED]> [2004-08-31T04:24:55] > Is there a way to make Test::Harness do this? If nothing else, in the given case, it would have made more sense to use is() is(0, 1, "Zero shouldn't equal one."); That will print got/expected values on error, even when not verbose. -- rjbs pgpfXsk2xiVJ3.pgp Description: PGP signature
Re: Test-Regex-0.01.tar.gz
* Rafael Garcia-Suarez <[EMAIL PROTECTED]> [2004-08-02T10:12:22] > What kind of useful diagnostics could this module emit in case of > failure? IMO they have to be precisely detailed. # failed comparisons follow: # expected $1: (610) # got $1: 691 # expected $4: x258 # got $4: 258 That's just off the cuff, but I think that's probably as reasonable as it gets, unless you want to (ugh!) diag nothing. -- rjbs pgpkKwfD61N4c.pgp Description: PGP signature
is_deeply and overloaded obejcts
I was going nuts recently, trying to figure out why I couldn't use is_deeply to compare objects. I've finally determined that it's only an issue (as far as I see) when comparing objects that overload dereferencing to their implementation type. The attached code should fail all three tests; at no point are the two structures identical. Instead, the third test -- when the structures are blessed into an implementation-type overloaded class -- passes. This should be simple-ish to fix, I'd think. 1. two objects are different if their implementation types differ 2. two objects are different if their blessed-into-temp-class structures differ 3. otherwise two objects are the same So, given two Garbage::Overloaded=HASH objects, we'd bless them into Test::More::TempClass and then compare those. Thoughts? -- rjbs obj_deep.t Description: Troff document pgp2XZlddHnb0.pgp Description: PGP signature
Re: Phalanx: What if full coverage isn't possible?
* Pete Krawczyk <[EMAIL PROTECTED]> [2004-07-09T13:10:52] > > Devel::Cover will always see that as a partial test, and never a full > test: > [ ... ] > Is that a bug, then? Or is it something else? And how should I notate > that, keeping in mind the goals of Phalanx, so that it's clearly visible > that no test of that condition's failure can truly take place in a regular > "make test" run? This came up just a few weeks ago, and I think the general feeling was something like: cover everything, if possible; make everything coverable, if practical; don't write stupid code to avoid "uncoverable" situations. So, if you know that branch isn't covered, but can't (really) be taken, it's up to you whether that's a problem or not. Deming, Who Knows Quality, would tell us to avoid arbitrary goals of 100% coverage... -- rjbs pgpGMa7TGPCVo.pgp Description: PGP signature
Re: empty tests, Test::Harness, and Test::Inline
* Andy Lester <[EMAIL PROTECTED]> [2004-06-11T15:44:27] > On Fri, Jun 11, 2004 at 03:33:44PM -0400, Andrew Pimlott ([EMAIL PROTECTED]) wrote: > > I prefer to eliminate extra noise. The situation I'm in is, I just > > started using T::I, so only a few modules have any tests, and I would > > see dozens of spurious "ok" lines for untested modules. > > I agree about skipping noise, but then you'd have T::H ignoring empty > files, which might, in another case, indicate something gravely wrong. Does T::H still complain for a plan of zero tests? That is, use Test::More tests => 0; I think that would be reasonable. Or even a special case 'no_tests' to match 'no_plan' Of course, there still might be too much output, there, for Andrew to be happy, but I think it makes sense. -- rjbs pgpMB2MMrmfJ9.pgp Description: PGP signature
Re: Adding analysis to Devel::Cover reports
* Michael Carman <[EMAIL PROTECTED]> [2004-06-07T23:13:02] > On 6/7/2004 9:20 PM, Andy Lester wrote: > > > > The "ALT attribute as tooltip" thing isn't portable, though. > > I don't use ALT, I use TITLE. That's the "right way" according to the W3C and > supported by at least IE and Mozilla-based browsers. Or did you mean something > else by "isn't portable?" Also by KHTML browsers, like Safari. -- rjbs pgp8SezJbKwZ4.pgp Description: PGP signature
Re: Style question
* "Francisco Olarte Sanz." <[EMAIL PROTECTED]> [2004-05-25T13:58:21] > ? Which aproach is better, have a single independent huge test file or > several interdependent smaller ones ( w/ notes in the readme stating > test dependence ) ? The better approach is the one that makes it most likely for you to write enough tests, use them, and maintain them. ;) Given the situation you're describing, I'd use a number of smaller files that need to work together. Look at Test::Manifest for a way to run scripts in order. -- rjbs pgpS8o9gWIMKo.pgp Description: PGP signature
Re: rt.cpan.org
* Michael G Schwern <[EMAIL PROTECTED]> [2003-12-06T20:04:24] > On Sat, Dec 06, 2003 at 07:46:24PM -0500, Ricardo SIGNES wrote: > > Alright, I know this is tangential to QA, but I'm trying to access > > rt.cpan.org to update a bug on a module I'm working on. I can't log > > into rt.cpan.org using my PAUSE credentials. > > Stupid question: can you log into PAUSE using your PAUSE credentials? > https://pause.perl.org/pause/authenquery?ACTION=add_uri Yup. I can also log into books.perl.org -- I don't use any other PAUSE-authing sites. > If you're feeling your oats you can hop onto irc.perl.org #perl and track > down obra (aka Jesse). I went on joined #rt, but it was asleep. I'll try #perl. Thanks. -- rjbs pgp0.pgp Description: PGP signature
rt.cpan.org
Alright, I know this is tangential to QA, but I'm trying to access rt.cpan.org to update a bug on a module I'm working on. I can't log into rt.cpan.org using my PAUSE credentials. I emailed [EMAIL PROTECTED] a month ago, and again this week, and received only an automated reply. I was assigned request numbers 4655 and 4288, but I can't find these on fsck.com anywhere. Can someone tell me: (a) what I'm doing wrong (b) where to find information on these reports (c) whether there's a much more appropriate list for these questions Thanks. -- rjbs pgp0.pgp Description: PGP signature
Re: Test::Benchmark ??
* Michael G Schwern <[EMAIL PROTECTED]> [2003-12-04T16:51:03] > On Thu, Dec 04, 2003 at 05:26:07AM -0500, [EMAIL PROTECTED] wrote: > > I'd say a lot of the trouble comes from the fact that you're using the > > automated test framework for something that isn't an automated test. > > But it could be. It would be nice to have a test like "make sure the > hand optimized version is faster than the unoptimized version" or "make sure > the XS version is faster than the Perl version". If this isn't what he meant, it's what I thought he meant. A T::B that allowed these kinds of tests would be really sweet for a number of applications. Even without the perlmip (which seems cool but further off), this would be great. -- rjbs pgp0.pgp Description: PGP signature
