Re: Custom extensions to META.yml
A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-02 22:55]: A. Pagaltzis writes: * Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: ... 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. Unless the mistake somebody makes is it forget whether a field is in the 'officially sanctioned' category or is an extension. 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. ... 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? Exactly my point! If any 'hints: foo' field gets widespread use then the spec would avoid defining a clashing 'foo' field, because that would be far too confusing. So in practice a given field is only going to exist either at the top level or in 'hints'. And from a user's point of view that distinction can look quite arbitrary -- it's basically an artefact of which process somebody went through to get the field added. That doesn't seem like a useful distinction to inflict on users. 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. There are other ways of achieving this, possibly even going further and specifying which extension fields being used. For example there could be a field 'extension-fields' which lists them (with their types?). Smylers
Re: Module proposal: Test::Timer
Hi Paul,
Thanks for you feedback, but you have to explain your thoughts to me
a bit more explicitly.
I am standing at the Copenhagen Perl Mongers booth at LinuxForum in
Copenhagen and yes I am a bit slow too.
As I see your two suggestions for methods, time_atmost is what would
be another name for the sub I have already implemented (time_ok and
its evil twin time_nok).
As for time_atmost, this one troubles me a bit, as I see it would be
fun to include, but it's use is somewhat vague to me :)
Your suggestion for a use of $SIG{ALRM} is very good and will be
implemented prior to the first release, since it seems very essential
and addresses a problem I did not see coming, good thing we have this
list.
jonasbn
On 02/03/2007, at 20.19, Paul LeoNerd Evans wrote:
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: Module proposal: Test::Timer
On Sat, 3 Mar 2007 16:17:59 +0100
Jonas B. Nielsen [EMAIL PROTECTED] wrote:
Thanks for you feedback, but you have to explain your thoughts to me
a bit more explicitly.
I am standing at the Copenhagen Perl Mongers booth at LinuxForum in
Copenhagen and yes I am a bit slow too.
As I see your two suggestions for methods, time_atmost is what would
be another name for the sub I have already implemented (time_ok and
its evil twin time_nok).
As for time_atmost, this one troubles me a bit, as I see it would be
fun to include, but it's use is somewhat vague to me :)
You mention time_atmost there twice - I think one of those is a typo, but
I can't see which one :)
I've had a bit more of a thought, and it now looks like this in my head:
time_between( $code, $atleast, $atmost, $message );
# Check that $code-() takes at least $atleast seconds, and no more
# than $atmost. Optionally install an alarm handler at, say,
# $atmost + 2 seconds (perhaps that 2 is configurable).
Then the other primitives fall out almost trivially:
time_atleast( $code, $atleast, $message ) ==
time_between( $code, $atleast, undef, $message );
time_atmost( $code, $atmost, $message ) ==
time_between( $code, 0, $atmost, $message );
time_ok( $code, $time, $message ) ==
time_between( $code, $time - $delta, $time + $delta, $message );
where $delta is some other configurable. Perhaps detect if Time::HiRes is
loaded, and use $delta = 0.1 if it is, and 1 if it isn't..? Random
thoughts..
Be careful of subtle races - remember what e.g. sleep guarantees.
sleep(5) for example, waits at least 4 seconds and no more than 5.
Your suggestion for a use of $SIG{ALRM} is very good and will be
implemented prior to the first release, since it seems very essential
and addresses a problem I did not see coming, good thing we have this
list.
It also occurs to me, that if we can't use SIGALRM, then maybe the
following might be better:
my $pid = $$;
my $kid;
if( ( $kid = fork() ) == 0 ) {
# child
sleep( $timeout );
kill SIGTERM, $pid;
exit( 0 );
}
$code-();
kill SIGKILL, $kid;
This way, $code-() isn't affected by SIGALRM.
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
