Rafael Garcia-Suarez wrote:
2. you gave me an idea for a Grand Plan.
Heres a 'working' version of my earlier proposal, patched against [EMAIL PROTECTED]
I hope you find it useful for regression testing of the optimizer, and the opcode generation phases.
1st some changes to existing files:
1. test.pl addition.
I added unlike(). Comment there obviously means that this has come up before, and I submit w/o researching, but heres my case.
Currently, one cannot expect a failure. like() does a positive match only
( ie =~ only, not !~). Since like has side effects of $tests++, and reporting failure,
one cannot expect a mismatch.
While there, I took out a chunk that runs: $text =~ $rex; a quick benchmark showed it ~ same as: $text =~ /$rex/;
when $rex is Regex, and more general.
2. Concise.pm changes;
1. juggle var declarations to gather 'rendering state', and comments
3. added +=head2 structure and content (Stickiness) into OPTIONS pod
4. introduced new terms: 'renderings', 'rendering-state', 'line-style'
5. added -banner option
6. refined compile() pod - maybe muddled it with details.
7. added tests to concise.t
2. juggled options to prioritize by visual effect, and grouped with =head2
according to mutual exclusivity w others. This makes patch look bigger.
3. to explain stickiness simply, it seemd approprate to add some grouping structure, rather than trying to enumerate in prose. I left 'stickiness' somewhat general, in order to avoid forward refs to functions, ie compile..
4. suggests a glossary
I introduce new terminology: rendering, stickiness, rendering-state, line-style
tried abortively to formalize current terms : style vs line-style, 'format', 'mode', etc..
I didnt finish - it felt too editorial.
5. my addition of a "B::Concise::compile($coderef)" banner was
something of a mistake - one additional subtlety that it exacerbates
(not mentioned in pod) is that it is printed only when compile itself
is called, not when the coderef it builds is called. This may surprise folks.
The option helps solve user probs that could result.
New files:
ext/B/t/OptreeCheck.pm. contains apparattus for use in optree_*.t
optree_check.t tests the apparatus itself. optree_concise.t tests various Concise options and output. optree_sort.t tests Dave Mitchell's recent INPLACE optimization. optree_varinit.t tests Rafael's recent my $var=undef optimiations. optree_samples.t various looks at simple code constructs.
assumptions:
moving common code to ext/B/t/OptreeCheck is 'allowed' (no grumbles so far!)
torture testing, test-dev support, QA are the reasons to get GRAND,
cmd-line argument handling is a GOOD WAY to invoke torture tests, support test-dev.
would require Getopt::Std be acceptable in a CORE test ?
I can well imagine that this should be on CPAN, not in CORE, but im unsure how (or whether) add-on tests can/should attempt to use outside facilities. For the time-being at least, it might be core-able, as a means to further ends (more optimizations ?)
btw, heres a trivial test-script, should you wish to play with the patch.
[EMAIL PROTECTED] bc5]$ more toptree.sh
function runset {
echo $*
./perl -w -Ilib ext/B/t/optree_check.t $*
./perl -w -Ilib ext/B/t/optree_samples.t $*
./perl -w -Ilib ext/B/t/optree_concise.t $*
./perl -w -Ilib ext/B/t/optree_sort.t $*
./perl -w -Ilib ext/B/t/optree_varinit.t $*
echo $*
}# try these too. #runset selftest # has errs #runset testmode=cross # use wrong t,nt purposely - has errors #runset testmode=cross selftest
runset $*
./perl -w -Ilib ext/B/t/optree_samples.t help
I welcome your comments, MACRO and MICRO.
jimc
concise-tests.patch.gz
Description: application/gzip
