Re: Custom extensions to META.yml
On 3/1/07, Steve Pitchford [EMAIL PROTECTED] wrote: This seems a very pragmatic solution to a problem, however given recent posts, it seems to be a solution in search of approval - is there a meta.yml owner / committee / interest group - at least a mailing list? Well, Ken Williams maintains the spec [1] so I consider him the ultimate approver for all practical purposes. I wanted to get community reactions/suggestions/improvement and with any luck, some degree of consensus. Then I was going to send Ken a patch to the blead spec and a summary of the discussion (though he's on all these lists, too, so I assume he's following it.) In response to other questions about X-foo, I was mirroring the RFC 822 email spec, where the spec promises that X- will never conflict with any future extensions to the spec. (No promise is made about these user fields conflicting with each other, of course) The corollary is that X- entries shouldn't be flagged as being in violation of a spec, either. (E.g. by CPANTS) I wasn't recommending it, just putting it out there for consideration. I prefer the hints approach, as that makes the purpose of the additional information slightly clearer. David [1] http://module-build.sourceforge.net/META-spec-blead.html
Re: Module proposal: Test::Timer
On Thu, 1 Mar 2007 14:53:50 +0100
Jonas B. Nielsen [EMAIL PROTECTED] wrote:
time_ok( sub { sleep(1); }, 5, 'Passing test' );
time_ok( sub { sleep(10); }, 5, 'Non-passing test' );
...
So my question is: is this module already on CPAN, or something
similar (better), or should I put mine there?
That looks almost exactly like something I wanted, and ended up hacking
up using Time::HiRes:
$now = time;
$set-loop_once( 2 );
$took = time - $now;
cmp_ok( $took, '', 1.9, 'loop_once(2) while waiting takes at least 1.9
seconds' );
cmp_ok( $took, '', 2.1, 'loop_once(2) while waiting takes no more than 2.1
seconds' );
It would be nice to have a native Test:: primitive for that.
Consider also
time_atleast( sub { sleep(5); }, 3, 'sleep(5) takes at least 3
seconds' );
time_atmost( sub { sleep(5); }, 6, 'sleep(5) takes no more than
6 seconds' );
Consider also whether to handle $SIG{ALRM} and call alarm( $timeout +
2 ), say... so you could throw a wobbly if the test times out
completely. Though beware that sleep() might be implemented using
alarm() on some platforms. Perhaps make it a tunable variable:
$Test::Time::ALRM = 1;
time_ok( sub { while(1) { } }, 1, 'while loops stop' );
I would hope that will complain after 2 seconds or so.
Be slightly careful of timing imprecision though - I decided to pull in
Time::HiRes for my specific test, but I don't know whether a generic
Test::Time module could justify that.
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
Re: Custom extensions to META.yml
* David Golden [EMAIL PROTECTED] [2007-02-28T22:39:01] Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. Why not: extensions: CPAN::Reporter: cc_author: 0 (PLEASE let's avoid 'yes' and 'no' as booleans.) If all the extensions are under the module (or, hey, dist) that uses them, then the X-nonsense is avoided. -- rjbs
Re: Custom extensions to META.yml
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Then how do you tell whether `bastract` is a typo or extension field? You can't. But equally you can't tell if hints: test-reporter: cc_arthur is a typo or not. (Admittedly if it's a typo for abstract then it's a particularly _bad_ typo ...) I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. The extra name-spaces avoid clashes. But I still think that the 'hints' level is unnecessary: for any key in 'hints', can you imagine a situation where it's _also_ a key top-level key? Think how confusing it would be to have both 'test-reporter' and 'hints: test-reporter'. Smylers
Re: Custom extensions to META.yml
David Golden writes: In response to other questions about X-foo, I was mirroring the RFC 822 email spec Yeah; that's why I'm so hostile to the idea! Mail headers have X-Mailer: but User-Agent: without the X-; and X-Mailing-List: but Posted-To: and List-Id: -- from a user's point of view it's arbitrary which headers have X- and which don't, and very hard to remember. Smylers
Re: Custom extensions to META.yml
# from David Golden # on Friday 02 March 2007 02:45 pm: For the META.yml spec, should anything not expressly allowed be forbidden? If so, then any extension like this has to be explicitly added to the spec. On the positive side, it doesn't leave ambiguity for tools that work with META.yml. What about having an extensions field as part of the spec declaration, where anything listed in it is allowed? This would mean that tools which are extending the spec would not have to change the attribute name if it gets adopted as-is, and would still allow strict validation if you're into that sort of thing. --- thbbt: foo meta-spec: url: http://module-build.sourceforge.net/META-spec-v1.4.html version: 1.4 extensions: - thbbt Later, say thbbt becomes an official part of 1.5: --- thbbt: foo meta-spec: url: http://module-build.sourceforge.net/META-spec-v1.5.html version: 1.5 At that point (v1.5), thbbt is probably not allowed in 'extensions' (because as an extension, it would conflict with a now-official part of the spec.) Wait, let's make 'extensions' a hash, thus allowing you to say which (possibly competing) version of the thbbt extension you're using. meta-spec: ... extensions: thbbt: http://welikethbbt.com/a_new_meta_attribute.html So, ad-hoc extensibility which is ready-for-adoption without changing the tools, all without namespace clashes? (Concurrent usage of competing thbbt's is discouraged, but will be handled via flame-war between the thbbt'ers as needed.) --Eric -- Consumers want choice, consumers want openness. --Rob Glaser --- http://scratchcomputing.com ---
Re: Custom extensions to META.yml
* Smylers [EMAIL PROTECTED] [2007-03-02 22:55]: A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Then how do you tell whether `bastract` is a typo or extension field? You can't. But equally you can't tell if hints: test-reporter: cc_arthur is a typo or not. (Admittedly if it's a typo for abstract then it's a particularly _bad_ typo ...) Yes, you can’t know anything about extension elements. That’s a given. But if you contain them in an extension hook and disallow arbitrary placement of extension elements, then you can at least validate the rest of the document with strict rules. I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. The extra name-spaces avoid clashes. But I still think that the 'hints' level is unnecessary: for any key in 'hints', can you imagine a situation where it's _also_ a key top-level key? Think how confusing it would be to have both 'test-reporter' and 'hints: test-reporter'. I’m not sure this would be particularly common problem? The point of `hints` is simply to contain extensions such that every part of the document other than what’s under `hints` is precisely specified. If you hoist the extension namespaces up one level, that is no longer the case: you don’t know if `bastract` is a namespace or a typo. (Same problem as with simply putting extension elements anyplace.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
