Re: CGI Session management (was Re: the CGI.pm in Perl 6)
It sounds like the name of HTTP is more appropriate: HTTP::Request ...uri, pathinfo, params, method, headers, etc. HTTP::Request::Session ...adds to HTTP::Request to provide session() method HTTP::Response ...response code, content, headers, etc. HTTP::Response::JSON ...extends response.write() to encode JSON Maybe CGI.pm could adapt these to the CGI environment and ecapsulate their functionality. Maybe it's too servlety. On 9/17/06, Juerd [EMAIL PROTECTED] wrote: Mark Stosberg skribis 2006-09-16 22:04 (-0500): As far as I'm aware, no work on CGI::Session for Perl 6 has started yet. I'm happy about that, because this module must not have CGI in its name. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] -- Ian Langworth
Re: TAP diagnostic syntax proposal
Wheeling back over to the extra diagnostic output that Schwern originally proposed, I agree with Adam in that any additions we make to TAP must be completely backward-compatible. I hereby recant my burblings. After reading Adam's replies, I think I might have pushed the thread in the wrong direction. Let me try another angle... Say we want better debugging support in an editor. A programmer runs the test suite, a few tests fail. She selects the first failure and is whisked to a highlighted line in a file. Some other part of the UI points out what output the test expected and what it actually received. What information does the editor need to make this happen? Schwern has already answered this: the file, line, and description, plus the actual and expected output. How do we get this information to the editor? More information would need to be included in the TAP output. How do we put more information in the TAP output? That's the tougher question -- we either mark up directives or add new kinds of output lines. The difference in syntax between these two options appears to be an octothorpe, but I'm not sure about compatibility: Any output line that is not a plan, a test line or a diagnostic is incorrect. How a harness handles the incorrect line is undefined. Test::Harness silently ignores incorrect lines, but will become more stringent in the future. -- http://xrl.us/o3tq (You guys were right. I now think YAML, or any kind of general-purpose logical markup, is overkill; our requirements are very succinct.) How do we implement this? If the editor application developers didn't care, they could run the tests with custom Test::Builder and parser replacement, or they could follow standards that we decide. The former (proprietary replacement modules) wouldn't be a Good Thing. Sure, it would be the most backward compatible, as they would only be used by the editor. However, if we decide how it's done now, multiple editors can share modules for producing TAP and parsing the results. A final random thought: Not all TAP output contains merely one-line actual/expected value diagnostics. Consider Test::Differences, which outputs a side-by-side, linewise comparison of the values given to it. What then? On 7/11/06, Adam Kennedy [EMAIL PROTECTED] wrote: Geoffrey Young wrote: However, most perl tests don't care about TAP, they use Test::More and Test::Harness and happen to exchange data via TAP. If Test::More and Test::Harness decied to use YAP (YAML Anything Protocol? :), then most applications would probably never notice. most _perl_ applications would never notice. IMHO however this overhaul ends up playing out, TAPs current marvel is that it's wonderfully simple and very forgiving - if the new version isn't completely back compatible y'all should call it something else, lest you risk alienating all the non-perl folks who embraced the protocol because of it's simplicity. in other words, call it TAP but break current non-perl TAP implementations and I think you'll wipe out the userbase that some of us spent a lot of effort trying to win over (and succeeding :) Indeed, I think we were pretty much clear that under no circumstances whatsoever would we break full back-compatibility. The idea of the extra mime-like things was to be able to provide some relatively simple and cross-language enhancements, so that, for example, if running tests with a higher verbosity, there could be some feedback to, say, an editor or a tool about the location of the errors. This is part of why I dislike YAML for this. Regardless of what the marketing says, it isn't cross-language for anything more than trivial use cases, for example objects or !!perl-specific things. As others have mentioned, the beauty of TAP is it's simplicity and accessibility. It Just Works across languages with almost no effort at all, can be done in pure-$your_language easily, and is generally quite forgiving. In introducing some form of semi-standard enhancements (such as the failure diagnostics) I really don't want to lose this. In using YAML, we're already adding a lot of extra weight, adding dependencies on C libraries, and tempting people into using the more ehnanced, non-platform-neutral features. Lets at least let the YAML spec stop morphing and the language implementations become stable before we start thinking of making TAP inherit any baggage from other protocols by adding them as dependencies. Fair enough a Layer 1 TAP parser might not care, but why not make it as equally easy to implement a Layer 2 parser as well. Adam K -- Ian Langworth
Re: Time for a Revolution
On 7/13/06, chromatic [EMAIL PROTECTED] wrote: Why is there not a Bundle::PerlPlus (and yes, I've lathered up my yak with that name) that downloads and installs the modules that should have been in the box? Sure, a Bundle::PerlPlus would be fun. Installing it wouldn't be. Perl module installation is tough. There are a lot of modules that do a lot of different things. There are a handful of ways to install all of those modules. There are a number of module installation modules. These modules may be pure-Perl or require compiling. What there isn't is: $ curl go.cpan.org | sudo perl install Foo quit $ perl -MFoo ... Exploring and using CPAN modules isn't fun. CPAN asks way too many users for the casual explorer, plus try explaining to them how to install a module locally. I'm not saying that this is a trivial problem or that it's easy to solve. I'm saying that to rope people in it's got to be Dead Fricking Simple. -- Ian Langworth
Re: TAP diagnostic syntax proposal
On 7/11/06, Adam Kennedy [EMAIL PROTECTED] wrote: Fair enough a Layer 1 TAP parser might not care, but why not make it as equally easy to implement a Layer 2 parser as well. Bingo. -- Ian Langworth
Re: TAP diagnostic syntax proposal
I mentioned YAML with a pretense I failed to mention -- that we
wouldn't parse the YAML. That's already been done, and there are
plenty of parsers.
YAML has clear designations of where it starts and ends. A TAP parser
wouldn't have to look at the diagnostics and guess what it is.
If the data structure is limited to MIME-like key/value pairs, many
people will do their own marshalling anyway. Why not give them that
power from the start?
Maybe we don't care. Maybe we can simply add a callback for some
diagnostic_block_analyzer() and, in my own little happy world,
$parser-diagnostic_block_analyzer( sub {
my ($block) = @_;
if ($block =~ m{ \A --- }xs) {
do something with YAML::Load($block);
}
else {
do something else
}
});
On 7/11/06, Adam Kennedy [EMAIL PROTECTED] wrote:
Whoa whoa whoa slow down there folks...
Some people seemed to have misrecognised those keys as YAML.
It was NEVER meant to be YAML.
The idea was to use something more like MIME headers.
We all agreed that we DIDN'T want the format to be too heavy, and going
with MIME or MIME-alike seemed the sweet spot in terms of ease of
parsing and standardization vs extensibility.
Having YAML in the TAP spec would complicate things greatly, especially
as the YAML spec includes things like multi-line strings. And it would
mean that we'd have to deal with YAML error events, JSON-style parsing
and a bunch of other things that are problematic.
It's NOT ease to parse at all, not compared to the current relative
simplicity of TAP at the moment.
Adam K
Jonathan T. Rockway wrote:
not ok 2 - omg t3h sooper test!!1!
--- TAP diagnostics
file:foo.t
Why aren't we commenting the YAML block so that it's compatible with
current TAP parsers? I'm thinking something like this:
not ok 2 - ensure that foo is equal to bar
# --- !!tap/diagnostics
# file: foo.t
# line: 42
# got:
# - !!perl/foobar
# key: value
# expected:
# - !!perl/foobar
# key: ~
# etc: (and so on)
The commented section is raw YAML goodness, AND this format is
compatible with current TAP parsers. I'm liking this a lot, especially
since I can use it Right Now (tm) by doing diag(Dump($data)).
Any reason this shouldn't be the standard? It's easy to parse, it's easy
to read.
Would it be acecptable if I patched Test::More to start outputing it's
expected/got messages in YAML instead of a plain text format?
Regards,
Jonathan Rockway
--
Ian Langworth
Re: TAP diagnostic syntax proposal
These diagnostic keywords seem to blend too much into the rest of TAP. Consider: not ok 2 - omg t3h sooper test!!1! ! file:foo.t ! line:45 ! description: omg t3h sooper test!!1! ! got: this ! expected:that ! raw-test:is( this, that, omg t3h sooper test!!1! ); ! x-THAC0: 16 ...or some other delimiter. Or maybe we say that any inline YAML is interpreted as a comment data structure instead of a giant comment string, which can be used for diagnostics: not ok 2 - omg t3h sooper test!!1! --- TAP diagnostics file:foo.t line:45 description: omg t3h sooper test!!1! got: this expected:that raw-test:is( this, that, omg t3h sooper test!!1! ); x-THAC0: 16 ... On 7/10/06, Michael G Schwern [EMAIL PROTECTED] wrote: The PITA/TestBuilder2 BoF at YAPC::NA (which spent most of its time talking about TAP) sketched out a syntax for parsable TAP diagnostics. not ok 2 - omg t3h sooper test!!1! file:foo.t line:45 description: omg t3h sooper test!!1! got: this expected:that raw-test:is( this, that, omg t3h sooper test!!1! ); x-THAC0: 16 Details on the wiki. http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax -- Ian Langworth
Re: TAP diagnostic syntax proposal
prove --secret-ovid-mode ... On 7/10/06, Ovid [EMAIL PROTECTED] wrote: - Original Message From: chromatic [EMAIL PROTECTED] On Monday 10 July 2006 10:19, Michael G Schwern wrote: got: this expected:that got still sucks. Is there any chance to change it to received? I like pitched and caught. ... silence ... *cough* Cheers, Ovid (for Larry's sake, no I'm not serious!) -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ -- Ian Langworth
Re: TAP diagnostic syntax proposal
YAML documents [can] end with a I like Jonathan's suggestion of making the YAML comments, but my gut feels funny about that. If the lines are preceeded with hashes, then it's not true YAML; it has to be stripped of the leading characters. Also, I'd rather have a TAP directive to state, This is YAML, instead of a parser wondering if the data _is_ valid YAML. On 7/10/06, Michael G Schwern [EMAIL PROTECTED] wrote: On 7/10/06, Pete Krawczyk [EMAIL PROTECTED] wrote: I would be concerned about got or expected including embedded newlines, such as: is($mech-content,$expected_page,Web page content matches what's expected); even with a delimiter such as Ian suggested. How would this handle that? YAML has ways to deal with newlines in values, but it does press for some sort of this line is part of the failure diagnostics indicator as Ian suggests. Also, would the raw test be pre-expanded? That is, what would raw-test show for this? is($user,testuser$id,Test user name correctly generated); Ideally it would show exactly that. The idea is to show the literal source line (or lines) which generated the test, if possible, so the reader can have a better idea what happened beyond what the normal got/expected diagnostics show. To show them with interpolated strings would require somehow reconstructing the syntax of the function call from inside the function. This loses information. Besides, they already have the expanded thing which went in. got/expected shows that. -- Ian Langworth
Re: TAP Namespace Nonproliferation Treaty
Ovid: TAP::Parser::Pedantic Schwern: TAP::Parser::Heuristic I've always feared /^[A-Z]+x::/ namespaces because I never understood them. For the longest time, I thought Jesse was working on DBI eXtreme with SearchBuilder and whatnot. On 7/8/06, Ovid [EMAIL PROTECTED] wrote: I'm perfectly comfortable with this idea, but what I'm trying to figure out then, is the namespace for my parser. It's a TAP parser, after all. Any suggestions? I see that Adam has suggested a TAPx:: namespace, but there could still be competing TAPx::Parser modules. Don't know if that would bug folks, though. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ -- Ian Langworth
Re: Bail out! questions
When you say any message after these words, does that include words
on subsequent lines?
If it does, there isn't much parsing left to do -- the rest of the
tokens in the stream get treated as a big diagnostic blob.
If it doesn't, the easiest thing to do would be to stop the parser and
complain. It would be really cool, as well as more work, if the parser
parsed the rest of the TAP. The latter would allow your parser to find
more than one error in the TAP. (Imagine the parser finding _two_
Bail out! lines.)
On 7/8/06, Ovid [EMAIL PROTECTED] wrote:
From TAP.pm:
--
Bail out!
As an emergency measure a test script can decide that further tests are useless
(e.g. missing dependencies) and testing should stop immediately. In that case
the test script prints the magic words
Bail out!
to standard output. Any message after these words must be displayed by the
interpreter as the reason why testing must be stopped, as in
Bail out! MySQL is not running.
--
What should be the appropriate behavior for the TAPx::Parser? (Namespace suggestions
still wanted) Should it stop lexing/parsing the output? Should it check to see if
there's additional output and spit out a different warning? Should it just treat it as a
Bail out! line and continue parsing like normal and let the code using the
parser handle that?
if ( $test-is_bail_out ) { ... }
Cheers,
Ovid
-- If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
--
Ian Langworth
Re: Bail out! questions
When you say any message after these words, does that include words
on subsequent lines?
If it does, there isn't much parsing left to do -- the rest of the
tokens in the stream get treated as a big diagnostic blob.
If it doesn't, the easiest thing to do would be to stop the parser and
complain. It would be really cool, as well as more work, if the parser
parsed the rest of the TAP. The latter would allow your parser to find
more than one error in the TAP. (Imagine the parser finding _two_
Bail out! lines.)
On 7/8/06, Ovid [EMAIL PROTECTED] wrote:
From TAP.pm:
--
Bail out!
As an emergency measure a test script can decide that further tests are useless
(e.g. missing dependencies) and testing should stop immediately. In that case
the test script prints the magic words
Bail out!
to standard output. Any message after these words must be displayed by the
interpreter as the reason why testing must be stopped, as in
Bail out! MySQL is not running.
--
What should be the appropriate behavior for the TAPx::Parser? (Namespace suggestions
still wanted) Should it stop lexing/parsing the output? Should it check to see if
there's additional output and spit out a different warning? Should it just treat it as a
Bail out! line and continue parsing like normal and let the code using the
parser handle that?
if ( $test-is_bail_out ) { ... }
Cheers,
Ovid
-- If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
--
Ian Langworth
Re: TAPx::Parser 0.02
This is cool, Ovid! I think you're definitely on the right track.
Thoughts:
- I'd like an option to automatically s{ \A \s* - \s+ }{} all test
descriptions. I bet a lot of people would end up doing this
themselves, including myself.
- Speaking of that step, the underscore in your tokenizing method
(_lex) denotes it as private. What if I wanted to massage the tokens
after that phase? Specifying after_lexing hooks might be useful.
- I'm not sure how closely you're trying to follow a traditional,
multi-phase parser. If the lexer's job is to simply turn TAP output
into data structures, why does it die on the semantic error of a
forgotten plan? (10-lex.t line 183) Sounds like that's the job of the
parser.
- I mentioned this in another reply, but I'll phrase it differently
here: Having the lexer and parser die immediately on error is easy,
yes. But having the components recording _all_ errors for later
examination by the user would be very, very helpful.
Your tests are very descriptive well organized.
On 7/8/06, Ovid [EMAIL PROTECTED] wrote:
Hi all,
The next version of my TAP parser is at
http://users.easystreet.com/ovid/downloads/TAPx-Parser-0.02.tar.gz
It's still not complete, but it's a lot further along than it was. Some notes
from Changes:
0.028 June, 2006
- Moved some lexer responsibility to the parser. This will allow us
to eventually parse streams.
- Properly track passed/failed tests, even accounting for TODO.
- Added support for comments and unknown lines.
- Allow explicit and inferred test numbers to be mixed.
- Allow escaped hashe marks in the test description.
- Renamed to TAPx::Parser. Will probably rename it again.
Note that it does not yet handle streams, but that's kind of low on my list
right now (though it is on my list).
Just to give you an idea of what it can do, for this test:
ok 1 - input file opened
We get this:
my $test = shift @results;
isa_ok $test, $TEST;
ok $test-is_test, '... and it should identify itself as a test';
is $test-ok, 'ok', '... and it should have the correct ok()';
ok $test-is_ok, '... and the correct boolean version of ok()';
is $test-number, 1, '... and have the correct test number';
is $test-description, '- input file opened',
'... and the correct description';
ok !$test-directive, '... and not have a directive';
ok !$test-explanation, '... or a directive explanation';
ok !$test-is_skip, '... and it is not a SKIPped test';
ok !$test-is_todo, '... nor a TODO test';
is $test-as_string, 'ok 1 - input file opened',
'... and its string representation should be correct';
There are still some bugs, but it's definitely getting there.
Cheers,
Ovid
-- If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
--
Ian Langworth
Re: TAPx::Parser 0.02
Ways to tweak the TAP structure before handing it to the parser? The
removal of leading hyphens thing in the previous replies, sanitizing
sensitive information (maybe the non-employees shouldn't see IP
addresses in the output when they see the parsed result), who knows.
My opinion is that playing with the tokenizer output shouldn't be
discouraged. In someone breaks the structure, however, that's their
problem. You're the one with vetitive power in the end, though :-)
On 7/9/06, Ovid [EMAIL PROTECTED] wrote:
- Original Message
From: Ian Langworth [EMAIL PROTECTED]
This is cool, Ovid! I think you're definitely on the right track.
Thanks!
Thoughts:
- I'd like an option to automatically s{ \A \s* - \s+ }{} all test
descriptions. I bet a lot of people would end up doing this
themselves, including myself.
Hmm, I can probably add that in fairly easily.
- Speaking of that step, the underscore in your tokenizing method
(_lex) denotes it as private. What if I wanted to massage the tokens
after that phase? Specifying after_lexing hooks might be useful.
Can you show me some example syntax of what you'd want to do? The problem is,
the lexing and parsing are very tightly coupled. Allowing people to massage
the lexer output directly is asking for trouble.
- I'm not sure how closely you're trying to follow a traditional,
multi-phase parser. If the lexer's job is to simply turn TAP output
into data structures, why does it die on the semantic error of a
forgotten plan? (10-lex.t line 183) Sounds like that's the job of the
parser.
Originally I had a clearer distinction between lexing and parsing, but there
were three reasons I abandonded this:
1. TAP is line based and allows non-parseable junk.
2. Context is very important and much of that is easy to track while lexing.
3. Due to some lexing ambiguities raised by precedence issues, I found that
the lexer would need much finer-grained tokens then I was creating and that
made the grammar more complicated.
However, you are correct that the lexer should not be dying. In fact, neither
should the parser. I decided last night that all errors should be recorded, as
you were wanting.
Your tests are very descriptive well organized.
Really? I thought I was a bit sloppy with 'em :)
Cheers,
Ovid
--
Ian Langworth
Licenses, alligators
When the last giant thread happened, I felt guilty for not contributing. To absolve myself of any future guilt due to the lack of a contribution to recent conversations, here's some useful information about alligators, courtesy of Wikipedia: There are only two countries on earth that have alligators: the United States and China. The Chinese alligator is endangered and lives only in the Yangtze River valley. The American Alligator is found in the United States from the Carolinas to Florida and along the Gulf Coast. The majority of American Alligators inhabit Florida and Louisiana. In Florida alone there are an estimated more than 1 million alligators. The United States is the only nation on earth to have both alligators and crocodiles. American Alligators live in freshwater environments, such as ponds, marshes, wetlands, rivers, and swamps. In China, they live only along the fresh water of the Yangtze River. Alligators are opportunistic feeders, eating almost anything they can catch. When they are young they eat fish, insects, snails, and crustaceans. As they grow they take progressively larger prey items, including: larger fish such as gar, turtles, various mammals, birds, and other reptiles, including smaller alligators. They will even consume carrion if they are sufficiently hungry. As humans encroach onto to their habitat, attacks on humans are not unknown, but are few and far between. http://en.wikipedia.org/wiki/Alligator -- Ian Langworth
Re: Using Perl in QA departments
Looks a little familiar.. Great job! I'm glad your examples make use of lexically scoping temporary variables. That's a technique I picked up a little too late for PTDN, unfortunately. On 6/17/06, Gabor Szabo [EMAIL PROTECTED] wrote: If anybody is interested on this list, the slides and the examples of my 2 days course are available here: http://www.szabgab.com/perl_in_test_automation.html regards Gabor -- Ian Langworth
Re: Test::Harness spitting an error
No one else has replied, so here's a shot in the dark: Try setting the PERLIO environment variable to crlf (without quotes). -- Ian Langworth
CPANTS: released_while_burning_midnight_oil
I propose a new Kwalitee metric, released_while_burning_midnight_oil. Authors who released their modules between 8AM and 1AM the next day (local time) will be awarded one point. Authors who, despite their girlfriend's pleading, stay awake at stupid hours of the night to hack on and then release Perl modules, don't. There are certain distributions on the CPAN that have obvious errors, including: - Blatantly conflicting plans and skip_all's in testfiles because the module wasn't tested on systems without the optional build dependency - Deletion of the module using PAUSE immediately after the module was released because of an error that, upon further inspection, didn't really exist - Referring to the module as this JSAN module because there are plans for a parallel JSAN distribution --(there was _definitely_ something in the water that this guy was drinking) Since local time is relevant, all CPAN authors would have to provide their home time zone as an extra field in their PAUSE information. Making every author add this information shouldn't be too much of a hassle. If an author is collaborating in a different time zone then they are used to, such as when attending a conference, another author, or buddy, may log in to PAUSE and vouch that they were also present when the module was released and that the author was in a relatively good state of consciousness. -- Ian Langworth PS. If you feel that sarcasm and satire are not best reflected in email, I cordially suggest that you eat a helicopter.
HTTP::Recorder
I'd like to improve HTTP::Recorder. I've contacted Linda Julien (http://search.cpan.org/~leira/) via her CPAN email address, but I've received no response. The module hasn't been touched in over a year and every RT ticket seems to have gone unanswered (http://rt.cpan.org/NoAuth/Bugs.html?Dist=HTTP-Recorder). Suggestions? -- Ian Langworth
Test::Cmd -- Recommended?
On 7/8/05, James E Keenan [EMAIL PROTECTED] wrote: One other curiosum: As a result of my Phalanx work, I've gotten in the habit of using File::Temp to create 'anonymous' directories and files in which to conduct testing. This is one of the many features of Test::Cmd, which I a was about to recommend. However, I remember being discouraged from using it, but I'm not sure from where or whom. Does anyone use Test::Cmd? Are there features in it that you like? Is it overcomplicated? Should it be updated to use Test::Builder? Do these pants make my butt look big? -- Ian Langworth
Re: RFC - Class::Agreement
On 5/26/05, Adrian Howard [EMAIL PROTECTED] wrote:
-No class invariants?
Soon!
-You do mention that tweaking @_ in the pre/post blocks will
affect the @_ passed to the method. You don't say that having pre/
posts that have side effects is evil. You probably should :-)
Reflecting upon this, I'm not even sure why I'd want argument
modification as a feature. (Maybe I still had Hook::LexWrap on the
brain.) I might just take this out.
-It's not immediately obvious to me from reading the docs that
doing:
{ package SomeSubclass;
use base 'SomeClass'; # from your example
sub choose_word { return -1 };
}
would fail since choose_word should still be bound by the
SomeClass precondition. I'm assuming you're doing something clever
with INIT blocks or something so this does work.
INIT blocks? Nope, nothing clever. If you use a class' method before a
precondition statement, that method will simply not be bound to a
contract.
-On How can I type less?. I'm curious as to whether you
considered adding an automatic $self to match the $r/@r ?
When you say automatic, I think of source filtering. Do you simply
mean an alias for the first argument? If so, I think it's best to
leave that up to the programmer. You can always use shift.
-I'd want a global way of switching off contracts without having
to change the code. $ENV{ClassAgreementDisabled} = 1 or something.
Arg! This is a biggie. If used properly, you shouldn't need, let alone
*want*, to turn contracts off. Class::Agreement doesn't do any deep
cloning like Class::Contract. Class::Agreement's contracts should be
nearly as light as putting die unless in your methods.
I'll include that feature, but not without a big disclaimer such as the above.
-I had to read What do you mean, ``There's a problem with the
heirarchy?'' three times. More paragraphs and an example for the
slow of thinking like me please :-)
Definitely. More examples on the way.
Thanks, Adrian. This is much appreciated.
--
Ian Langworth
Re: RFC - Class::Agreement
On 5/27/05, Ovid [EMAIL PROTECTED] wrote: Class::Agreement's contracts should be nearly as light as putting die unless in your methods. What? I had no idea. Was that in the docs and I overlooked it? To me, this is probably one of the strongest features of Class::Agreement and should definitely be hyped. Many aren't going to use Class::Contract due to the performance hit. Argle -- I've forgotten to explain the whole joke! An agreement is lighter than a contract. Hence, Class::Agreement. Har, har. -- Ian Langworth
Re: Displaying the description in diagnostic output
On 5/13/05, David Landgren [EMAIL PROTECTED] wrote: So what I *really* think about Perl's test reporting is that the results are shown in the wrong order, and that it would also be better to use a less ambiguous word than 'got'. 'actual' would be nice. I like the word actual much better than got, but I agree that swapping the order would create inconsistency. -- Ian Langworth
Re: testing that processes terminate
On 5/18/05, Kevin Scaldeferri [EMAIL PROTECTED] wrote: Being a good coder, I wrote a unit test to reproduce the problem before I fixed it. Let gold ingots rain from the heavens and collect into your front yard! :) The test is happy when I run it normally, and even when I run it under Devel::Cover, but it consistently fails in our nightly test run (under Devel::Cover). As best I can figure, Devel::Cover is slowing things down so much that my test thinks the process doesn't exit. Your code looks fine. It appears that your two testing environments (running the test yourself and your automated nightly run) are different in some way. This nightly run -- is it, by any chance, running low-priority? -- Ian Langworth
RFC - Class::Agreement
I'm working on a new module, Class::Agreement, and I've started by writing the documentation. If anyone has a few minutes, I'd like some feedback as to whether my descriptions of the concepts make sense and if you like the syntax. HTML: http://reliant.langworth.com/~ian/Class-Agreement.html POD: http://reliant.langworth.com/~ian/Class-Agreement.pod -- Ian Langworth
Re: RFC - Class::Agreement
On 5/23/05, Ovid [EMAIL PROTECTED] wrote: In discussing the benefits, I didn't think you made a strong argument. However, in reading the page your docs points to, I think the argument can be improved with this: Precondition violations mean that the client is in error. Postcondition violations means that the supplier is incorrect. I've left out deeper discussion in hope that I'll be writing a larger article that dives further into the world of contracts. But, you're right -- I've probably skimmed to far above the surface. I also noticed you didn't make a comparison to Class::Contract. I think something explicit would be useful. Whoops! Definitely meant to include that. You did write Class::Agreement is also the only implementation in any language to blame failed contracts correctly, but I don't know what that means. I also note that the link you point us to after that comment is a citation, not something I can actually read. CiteSeer has a little box full of links under View or Download on the citation pages. -- Ian Langworth
Re: [RFC] Test::Plan
Rock!
First, just a nitpicky thing -- You could simplify Makefile.PL to not
need File::*:
WriteMakefile(
...
test = { TESTS = join ' ', map { glob } qw( t/*/*.t t/*/*/*.t ) },
...
);
Also, I agree that the use-Test-Plan-after-Test-More caveat is icky.
How about modifying Test::Plan::import() so that it (a) checks to see
if Test::More *has* already been loaded or (b) checks if a plan()
subroutine is already defined in the namespace that the method is
exporting to.
On Tue, 15 Mar 2005 09:17:22 -0500, Geoffrey Young
[EMAIL PROTECTED] wrote:
I'm still working up additional tests, but the documentation and
functionality is all there, so constructive feedback welcome.
--
Ian Langworth
Project Guerrilla
Northeastern University
College of Computer and Information Science
Module popularity
The CPAN Search FAQ at http://search.cpan.org/faq.html reads: Q: Do you keep statistics on which modules are most popular? A: Not right now. But there are plans to add some kind of popularity metrics. I think the answer should be updated to point to the Phalanx project. Whom do we contact? -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: Module popularity
Fair enough. On Tue, 15 Mar 2005 00:37:26 -0600, Andy Lester [EMAIL PROTECTED] wrote: I'd rather it didn't. What people think of as popularity is not what Phalanx measures. Let's not stir the mud. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: Test comments
On 14.Feb.2005 09:01PM -0800, chromatic wrote: Here's my list of suggestions for each: 1) label, description 2) directive, instruction 3) diagnostic I want to avoid the word comment altogether, making the optionalness of #1 and #3 evident in their words, the activeness of #2 evident in its word, and any comparison to Perl's comments in syntax or name go away. I think description, directive, and diagnostic fit those constraints. However, the distinction between #1 and #3 still seems unclear. For #3: anecdote? metalabel? optional postfix description informatron? scuttlebutt? tittle-tattle? To think outside the box, do we actually _need_ both #1 and #3 on the same line for reasons other than backwards compatibility? As for synonyms, try out the OneLook reverse dictionary: http://www.onelook.com/reverse-dictionary.shtml It usually provides. Other times, such as in the case of searching for optional note, it produces completely silly results such as linseed oil. Go figure. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: [RFC] adding skip option directly to plan()
On 30.Nov.2004 09:57AM -0600, Andy Lester wrote: plan tests = 14, have( Foo::Wango ), moon_phase eq waning, etc; Where does the reason fit into this syntax? -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: [RFC] adding skip option directly to plan()
On 12.Mar.2005 11:41PM -0500, Geoffrey Young wrote: nevertheless, what you are replying to was just a discussion about a feature that doesn't exist in the standard Test::More toolkit but was brought up because Apache-Test's plan() works a bit differently and there are enough people who like it that I thought it warranted a discussion here to see if T::M was interested. Yeah, I know, I was curious how the reason could fit into the _proposed_ Test::More additions. I'll do a better job at phrasing next time. :-) -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: TAP docs
Under TESTS AND PLANS: The plan, the first sentence of the third paragraph seems to fit better at the end of the previoius paragraph: This is a safeguard in case your test dies quietly in the middle of its run. It should be the first non-diagnostic line output by your test program. In certain instances, ... Under the test line, the emphasized concepts could reflect their necessity more easiliy: * ok or not ok (required) * Test number (recommended) * Description (recommended) * Directive (internal use or something) Thus ends any nitpicky things my brain clicked on. Andy Lester wrote: Get those comments in ASAP, please. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: Test names/comments/whatever?
Stevan Little wrote: I sent Schwern a patch to change 'names' to 'description', but then Andy brought up the idea of 'labels'. At the time, Schwern said it was 'in the pipeline', but I expect its actually been moved out since. Personally, I view them as 'descriptions' since thats what I usually write. But 'labels' makes sense too, if you use them that way. However, 'name' just never made since to me though, and initially was a source of confusion when I first read Test::Tutorial and co. Personally, I think the term 'comment' is most appropriate. Test 'names' or 'labels' seem analagous to IDs, leading me to think that every test has a unique name or label, such as graph_region_38. The term 'description' seems to imply a long explanation, such as This test makes sure that the graph can correctly identify the number of tiles that make up a region. 'comment', however, seems just right -- it implies a short, optional description. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: Test names/comments/whatever?
Stevan Little wrote: I sent Schwern a patch to change 'names' to 'description', but then Andy brought up the idea of 'labels'. At the time, Schwern said it was 'in the pipeline', but I expect its actually been moved out since. Personally, I view them as 'descriptions' since thats what I usually write. But 'labels' makes sense too, if you use them that way. However, 'name' just never made since to me though, and initially was a source of confusion when I first read Test::Tutorial and co. Personally, I think the term 'comment' is most appropriate. Test 'names' or 'labels' seem analagous to IDs, leading me to think that every test has a unique name or label, such as graph_region_38. The term 'description' seems to imply a long explanation, such as This test makes sure that the graph can correctly identify the number of tiles that make up a region. 'comment', however, seems just right -- it implies a short, optional description. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: introduction
Comrade Burnout wrote: I'm not sure where to start other than this. So hi and stuff. Hi, Brian. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Re: Test::Harness::HTML (was Test::Unit, ::Class, or ::Inline?)
On Jan 26, 2005, at 3:48p, [EMAIL PROTECTED] wrote: My main gripe is that the infrastructure for it is less OO friendly. The example with the HTML output was awesome..until i looked at how it was done. The inability to get a data structure back for the test results is very, very frustrating. Yeah, it's pretty damn ugly. If anybody wants to continue with this module, feel free to grab it, as I'm pretty short on time. I just started it as an experiment. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Proposed Test::Harness::Straps data
On Jan 26, 2005, at 5:12p, Andy Lester wrote:
I would love to hear your thoughts and ideas on structures of results.
Here's approximately what I'd like, which could easily be passed to a
template. This is just a brain dump, feel free to tear it apart. A few
of the values are provided for convenience.
@results = [
{
filename = 't/something.t',
time = 'Wed Jan 26 18:04:01 EST 2005',
duration = '12.438282', # seconds
total = {
ok = 5,
fail = 0,
seen = 5, # should be ok + fail
max = 5,
},
passed = 1, # max == seen == ok
events = [ # not necessarily tests
{
num = 1,
type = 'pass',
comment = object isa 'Foo',
},
{
num = 2,
type = 'fail',
stderr = uninitialized value at Foo.pm line
382,
comment = frobnicate,
},
{
num = 3,
type = 'diag',
comment = time for stuff,
},
{
num = 4,
type = 'skip',
comment = test AIX thingies,
reason = not running AIX,
},
...
]
}
...
];
--
Ian Langworth
Project Guerrilla
Northeastern University
College of Computer and Information Science
Test::Unit, ::Class, or ::Inline?
I'm taking a software development class this semester which will involve writing extensive object-oriented code. My partner and I are trying to decide whether to use Test::Unit, ::Class, or ::Inline for our test scripts. I can see the advantages of Test::Class in terms of object heirarchy, but I really like the idea of having my tests right along with the methods when using Test::Inline. (The latter would be great when presenting our code to the class.) Thoughts? -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
Test::Harness HTML output
I'm attempting to create fancy HTML output from running a test suite and thought others might find this interesting. I've tried using Test::Harness::Straps to create a feedback report inspired by Tinderbox and BuildBot. http://langworth.com/downloads/tmp/THHTML/output.html Click on the summaries to see the full (however lacking) output. T::H::Straps doesn't yet seem to handle grabbing stderr, among other things. If you want to try it out for other test suites, check out the directory: http://langworth.com/downloads/tmp/THHTML/ Work in progress. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
