Re: Using Test::More to make sense of documentation

Jeez! You do like to do things the hard way. Get yourself a REPL.

c:\test>p1
[0] Perl> $a = 'abcdeee';;
[0] Perl> $a =~ /(..)/ and print $1;;
ab
[0] Perl> $a =~ /(.)\1/ and print $1;;
e
[0] Perl> $a =~ /((.)\1)/ and print $2;;
[0] Perl> $a =~ /((.)\1)/ and print $1;;
[0] Perl> $a =~ /(.)(\1+)/ and print "$1$2";;
eee
[0] Perl> $a = 'abcdeeef';;
[0] Perl> $a =~ /(.)(\1+)/ and print "$1$2";;
eee
[0] Perl> $a = 'abbb;eeef';;
[0] Perl> $a =~ /(.)(\1+)/ and print "$1$2";;
bbb
[download]

Most of that just requires a cursor up and a couple of characters edits.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re: Using Test::More to make sense of documentation Download Code

Replies are listed 'Best First'.
Re^2: Using Test::More to make sense of documentation by ELISHEVA (Prior) on May 01, 2009 at 14:12 UTC
I only like to do things the hard way when it makes things easier. :-) The only limitation of command line testing addressed by a REPL (read-eval-print loop) is the quoting problem. Both command lines and REPLs are excellent tools for quick clarifications. They are less helpful when one wants to really explore what subroutine `X::foo` really does with its parameters, especially if you only use that language feature or `X::foo` every few months. Command lines also have up-cursors and history. However, the history of command lines and REPLs is basically a session transcript and goes away after N lines of input. You can't go back to last week or last month's tests (unless you use it very rarely). You could increase N so that a longer history can be kept, but the history isn't categorized by topic the way a named file can be. Best, beth	[reply] [d/l] [select]
Re^3: Using Test::More to make sense of documentation by BrowserUk (Patriarch) on May 01, 2009 at 18:19 UTC
However, the history of command lines and REPLs is basically a session transcript and goes away after N lines of input. Hm. I do a lot of experiments with my REPL. There is almost always a copy running in my system somewhere. With a command line history of 500 lines and and a 1000 line console.That's usually more than enough to record the experiments for as long as I need them. On the rare occasions that I wish to keep something, I have a habit of C&Ping the relevant bits of the console log into the script as a comment or after and __END__ tag. But mostly I'm not interested in the things I tried that failed, only that which worked. And that ends up in whatever script I was doing my experiments for. So if I want to find it again, I just grep *.pl for it. If I used your method, I would still end up grepping for it as I would find it onerous--if not impossible--to come up with enough meaningful names to accurately catalog all the experiments I do with my REPL. Still, we all have our own ways of working, and if yours works for you, that's all that matters. It does seem awfully laborious though. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]