barbie's Friends' Journals http://use.perl.org/~barbie/journal/friends/ barbie's Friends' use Perl Journals en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:00:32+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 barbie's Friends' Journals http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~barbie/journal/friends/ Finally, some Test::Builder2 examples! http://use.perl.org/~schwern/journal/40528?from=rss <p>For my PDX.pm presentation tonight on <a href="http://github.com/schwern/test-more/tree/Test-Builder2">Test::Builder2</a> I threw together some quick examples of some of its killer features, in particular demonstrating changing how Test::Builder2 behaves using method modifiers and applying object roles.</p><p>First, demonstrating end-of-assert actions, there's <a href="http://github.com/schwern/test-more/blob/Test-Builder2/examples/TB2/lib/TB2/DieOnFail.pm">die on fail</a> but even cooler is <a href="http://github.com/schwern/test-more/blob/Test-Builder2/examples/TB2/lib/TB2/DebugOnFail.pm">DEBUG on fail</a>! That's right, run your test in the debugger and have it automatically set a breakpoint on a failure. How cool is that?</p><p>I'm sure somebody with better debugger foo than I can make it even cooler and stop at the top of the assert stack rather than inside DebugOnFail.</p><p>The second is reimplementing <a href="http://search.cpan.org/perldoc?Test::NoWarnings">Test::NoWarnings</a> safely. <a href="http://github.com/schwern/test-more/blob/Test-Builder2/examples/TB2/lib/TB2/NoWarnings.pm">TB2::NoWarnings</a> demonstrates hooking into the start and end of the test as well as safely altering the number of tests planned by trapping the call to set_plan.</p><p>You can safely use them all together, though its a crap shoot if DebugOnFail or DieOnFail will trigger first.</p><p>While roles and method modifiers are relatively new to the Perl community, using them in lieu of designing my own event system for TB2 has two great advantages. First, I didn't have to design and debug my own event system.<nobr> <wbr></nobr>:) Second, rather than having to learn the quirks of a one-off system, you learn the quirks of Mo[uo]se and then can apply that knowledge all over the place.</p><p>There's <a href="http://github.com/schwern/test-more/issues/labels/Test-Builder2">a pile of stuff to be done in TB2</a>, a lot of them are fairly small and self contained. Have a look. Patches welcome.</p> schwern 2010-09-09T08:33:42+00:00 journal Test::Builder2 at 10k Feet http://use.perl.org/~schwern/journal/40527?from=rss <p>Here's a diagram of the "flow" of assert results through Test::Builder version 1.</p><blockquote><div><p> <tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.-------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| foo.t |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'-------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp;.-------------.&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp;.----------------.<br>&nbsp; &nbsp; &nbsp;| Test::More&nbsp; |&lt;---------&gt;| Test::Whatever |<br>&nbsp; &nbsp; &nbsp;'-------------'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'----------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp;.---------------.&nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '----&gt;| Test::Builder |&lt;----'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '---------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.-----.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| TAP |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'-----'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.---------------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Test::Harness |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '---------------'</tt></p></div> </blockquote><p>You write foo.t using Test::More and Test::Whatever. These both<br>use the same Test::Builder object. It spits out TAP which<br>Test::Harness converts into something human readable.</p><p>The big problem there is Test::Builder is monolithic. There's no<br>further breakdown of responsibilities. It only spits out TAP, and<br>only one version of TAP.</p><p>Here's what Test::Builder2 looks like:</p><blockquote><div><p> <tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.-------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.----------------| foo.t |-------------------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '-------'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.------------.&nbsp; &nbsp; &nbsp;.----------------.&nbsp; &nbsp; &nbsp;.------------------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Test::More |&nbsp; &nbsp; &nbsp;| Test::Whatever |&nbsp; &nbsp; &nbsp;| Test::NotUpdated |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '------------'&nbsp; &nbsp; &nbsp;'----------------'&nbsp; &nbsp; &nbsp;'------------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.----------------.&nbsp; &nbsp; &nbsp; &nbsp;.---------------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'----------&gt;| Test::Builder2 |&lt;------| Test::Builder |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'----------------'&nbsp; &nbsp; &nbsp; &nbsp;'---------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.--------------.&nbsp; &nbsp;<nobr> <wbr></nobr>.-------------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| TB2::History |&lt;---| TB2::Result |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'--------------'&nbsp; &nbsp; '-------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp;<nobr> <wbr></nobr>.--------------------------.&nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp;.---------------------.<br>&nbsp; &nbsp; | TB2::Formatter::TAP::v13 |&lt;-----'------&gt;| TB2::Formatter::GUI |<br>&nbsp; &nbsp; '--------------------------'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '---------------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp;<nobr> <wbr></nobr>.-------------------------------.&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; | TB2::Formatter::Streamer::TAP |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; '-------------------------------'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.-----.&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| TAP |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'-----'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.---------------.&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.-----------------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Test::Harness |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| Pretty Pictures |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '---------------'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'-----------------'</tt></p></div> </blockquote><p>It starts out the same, foo.t uses a bunch of test modules<br>including Test::More and Test::Whatever using the same Test::Builder2<br>object, but it also uses Test::NotUpdated which is still using<br>Test::Builder. That's ok because Test::Builder has been rewritten in<br>terms of Test::Builder2 (more on that below).</p><p>Test::Builder2, rather than being a monolith, produces a<br>Test::Builder2::Result object for each assert run. This gets stored<br>in a Test::Builder2::History object for possible later use. It also<br>gets handed to a Test::Builder2::Formatter object, the default is<br>Test::Builder2::TAP::v13 which produces TAP version 13. This is fed<br>to a Streamer that prints it to STDOUT and STDERR which is read by<br>Test::Harness and made human readable.</p><p>Because Test::Builder2 is not monolithic, you can swap out parts. For<br>example, instead of outputting TAP it could instead hand results to a<br>formatter that produced a simple GUI representation, maybe a green<br>bar, or something that hooks into a larger GUI. Or maybe one that<br>produces JUnit XML.</p><p>Here's how Test::Builder and Test::Builder2 Relate.</p><blockquote><div><p> <tt>&nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.-----.&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.-----.<br>&nbsp; &nbsp; &nbsp; &nbsp; | TB2 |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| TB1 |<br>&nbsp; &nbsp; &nbsp; &nbsp; '-----'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'-----'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v<br>&nbsp; &nbsp;<nobr> <wbr></nobr>.-------------.&nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.--------------.&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;.-------------.<br>&nbsp; &nbsp; | TB2::Result |-------&gt;| TB2::History |&lt;--------| TB2::Result |<br>&nbsp; &nbsp; '-------------'&nbsp; &nbsp; &nbsp; &nbsp; '--------------'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'-------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.----------------.&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;'-------------&gt;| TB2::Formatter |&lt;--------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '----------------'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<nobr> <wbr></nobr>.--------.<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Output |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '--------'</tt></p></div> </blockquote><p>Test::Builder and Test::Builder2 coordinate their actions by sharing<br>the same History and Formatter objects. If you call TB1-&gt;ok() it<br>produces a Result object which it hands to the History singleton and<br>the Formatter singleton. If you call TB2-&gt;ok() it produces a Result<br>object which it hands to the same History and Formatter objects.</p><p>This allows most of the Test::Builder code to remain the same while<br>still coordinating with Test::Builder2. It also allows radically<br>different builders to be made without Test::Builder2 dictating how<br>they're to work.</p><p>The downside is that roles applied to Test::Builder2 will not effect<br>Test::Builder. Because of this, Test::Builder may become more closely<br>coupled with Test::Builder2 in the future.</p><p>Diagrams by <a href="http://search.cpan.org/dist/App-Asciio">App::Asciio</a>.</p> schwern 2010-09-09T08:15:22+00:00 journal DBD::SQLite 1.31 releasing next week and may break your code http://use.perl.org/~Alias/journal/40526?from=rss <p>After 6 or 7 months (mainly waiting around for the next "recommended upgrade instruction" from the SQLite project) the latest DBD::SQLite release should occur next week.</p><p>You can get the 1.30_06 release candidate from the CPAN, or from the following URL if your mirror hasn't synced yet.</p><p><a href="http://svn.ali.as/cpan/releases/DBD-SQLite-1.30_06.tar.gz">http://svn.ali.as/cpan/releases/DBD-SQLite-1.30_06.tar.gz</a></p><p>Apart from the normal batch of SQLite upgrades (from 3.6.22 to 3.7.2), bug fixes, and minor enhancements, this release has two changes that may break your code.</p><p>These changes have been in the dev releases for some time, but you may want to take the opportunity to test more intensively if you use either of the following features.</p><p>1. BLOB columns with UTF8 content</p><blockquote><div><p> <tt>- Resolved #54271: Inserting a string with utf-8 flag on<br>&nbsp; corrupts BLOB data; now BLOB data is always stored as bytes<br> &nbsp; (without the utf-8 flag) even if it has the flag set (ISHIGAKI)</tt></p></div> </blockquote><p>2. FTS3 queries</p><blockquote><div><p> <tt>- Added support for FTS3 tokenizers written in Perl. Added tests<br>&nbsp; and documentation on how to use FTS3. Changed compilation flag<br>&nbsp; to use the recommanded -DSQLITE_ENABLE_FTS3_PARENTHESIS<br>&nbsp; *** MAY POSSIBLY BREAK OLD APPLICATIONS THAT ALREADY USED FTS3 ***<br>&nbsp; (DAMI)</tt></p></div> </blockquote><p>If you are currently using FTS3, please see <a href="http://search.cpan.org/perldoc?DBD::SQLite::FTS3Transitional">DBD::SQLite::FTS3Transitional</a> which contains a helper function for automatically upgrading old FTS3 queries to the new syntax.</p> Alias 2010-09-09T02:11:54+00:00 journal Should Module::Install move to explicit plugin declaration? http://use.perl.org/~Alias/journal/40523?from=rss <p>Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.</p><p>With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.</p><p>For example, some random author that is trying to checkout a Catalyst project needs:</p><p>1. To have Module::Install installed.<br>2. To have Module::Install::Catalyst installed.</p><p>In the case of the former, you get the semi-cryptic but at least standard "Can't find inc/Module/Install.pm in @INC" message, so the error is resolvable.</p><p>But in the latter case, you're likely to get something like "Unknown command 'catalyst_ignore'", with no real obvious resolution mechanism.</p><p>I think this idea of automatic plugin discovery is starting to hit it's limits in terms of clarity.</p><p>And so I'd like to do something counter to my natural instincts here, and make M:I more verbose.</p><p>I'm thinking of something like the following for explicitly declaring the use of a non-core Module::Install extension.</p><blockquote><div><p> <tt>use inc::Module::Install qw{ Catalyst XSUtil };</tt></p></div> </blockquote><p>This would both allow M:I to error with a much more meaningful error when you don't have a plugin, and also prevent the loading of unused plugins which should prevent accidental plugin collisions (some of which I've seen occurring in the CPAN Testers machines).</p><p>Thoughts?</p> Alias 2010-09-06T02:26:06+00:00 journal Pittsburgh Perl Workshop CFP ends Monday Sept 6 http://use.perl.org/~rblackwe/journal/40520?from=rss The Pittsburgh Perl Workshop 2010 will be Saturday October 9 and Sunday 10 at the Gates Center at CMU. <br> <br> Don't miss your chance to speak at this years Workshop. The Call For Papers ends Monday Sept 6. <br> <br> <a href="http://pghpw.org/ppw2010/newtalk">Submit your talk.</a> rblackwe 2010-09-02T15:22:01+00:00 events Rakudo Star 2010.08 released http://use.perl.org/~pmichaud/journal/40518?from=rss <p>[This announcement was made last week on rakudo.org -- I'm reposting to use.perl.org so it will show up in the various Perl aggregators. --Pm]</p><p>On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the August 2010 release of "Rakudo Star", a useful and usable distribution of Perl 6. The tarball for the August 2010 release is available from <a href="http://github.com/rakudo/star/downloads">http://github.com/rakudo/star/downloads</a>.</p><p>Rakudo Star is aimed at "early adopters" of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These "Star" releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it.</p><p>In the Perl 6 world, we make a distinction between the language ("Perl 6") and specific implementations of the language such as "Rakudo Perl". The August 2010 Star release includes release #32 of the Rakudo Perl 6 compiler [1], version 2.7.0 of the Parrot Virtual Machine [2], and various modules, documentation, and other resources collected from the Perl 6 community.</p><p>This release of Rakudo Star adds the following features over the previous Star release:<br>* Nil is now undefined<br>* Many regex modifiers are now recognized on the outside of regexes<br>* Mathematic and range operations are now faster (they're still slow, but they're significantly faster than they were in the previous release)<br>* Initial implementations of<nobr> <wbr></nobr>.pack and<nobr> <wbr></nobr>.unpack<br>* MAIN can parse short arguments<br>* Removed a significant memory leak for loops and other repeated blocks</p><p>This release (temporarily?) omits the Config::INI module that was included in the 2010.07 release, as it no longer builds with the shipped version of Rakudo. We hope to see Config::INI return soon.</p><p>There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Thus, we do not consider Rakudo Star to be a "Perl 6.0.0" or "1.0" release. Some of the not-quite-there features include:<br>* nested package definitions<br>* binary objects, native types, pack and unpack<br>* typed arrays<br>* macros<br>* state variables<br>* threads and concurrency<br>* Unicode strings at levels other than codepoints<br>* pre and post constraints, and some other phasers<br>* interactive readline that understands Unicode<br>* backslash escapes in regex character classes<br>* non-blocking I/O<br>* most of Synopsis 9<br>* perl6doc or pod manipulation tools</p><p>In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed.</p><p>See <a href="http://perl6.org/">http://perl6.org/</a> for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. An updated draft of a Perl 6 book is available as in the release tarball.</p><p>The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see <a href="http://rakudo.org/how-to-help">http://rakudo.org/how-to-help</a>, ask on the perl6-compiler@perl.org mailing list, or join us on IRC channel #perl6 on freenode.</p><p>Rakudo Star releases are created on a monthly cycle or as needed in response to important bug fixes or improvements. The next planned release of Rakudo Star will be on September 28, 2010.</p><p>[1] <a href="http://github.com/rakudo/rakudo">http://github.com/rakudo/rakudo</a><br>[2] <a href="http://parrot.org/">http://parrot.org/</a></p> pmichaud 2010-09-01T12:36:56+00:00 perl6 A month of Test::Builder2 http://use.perl.org/~schwern/journal/40517?from=rss <p>I've had <a href="http://www.perlfoundation.org/test_builder_2">a grant open for Test::Builder2</a> for, oh god over two years now. Since I started it, Perl 6 has had a release! I think its the second oldest running dev grant.</p><p>I've cleared the decks of other responsibilities and can dedicate September to, if not finishing, then at least releasing something people can poke at. First alpha release was supposed to be "two weeks after the start" ha ha ha! oh god. The design has evolved and simplified greatly in the intervening two years, but its time to get something the hell out the door. At least a <a href="http://github.com/schwern/test-more/tree/Test-Builder2">Test::Builder2</a> Star if you will.</p><p>There's critical components missing. There's no diagnostics, YAML or otherwise. The issues with nested asserts are still congealing. Plans are not enforced. Result objects are in the middle of being remodeled... again. But Test::Builder is using what parts of Test::Builder2 are usable. Multiple output formats and streams work. Asserts can be nested in the common, simple cases without having to fiddle with $Level. And you can hook into various events.</p><p>Step one is I'm going to seal up what's there, write docs where they're missing, and release something.</p><p>A release before October or the grant dies.</p> schwern 2010-08-28T04:08:39+00:00 journal Amiga Ethernet http://use.perl.org/~scrottie/journal/40515?from=rss <p>Yesterday, I got my X-Surf 3cc Ethernet card I broke down and ordered for my Amiga 3000. There's some backstory about serial consoles, Sparcs, and the cluster, but it's not important. The 3000 was also packaged as a Unix machine, running a pretty standard port of SysV. It was the first Amiga standard with an MMU and SCSI. It'll also kick out 1280x resolution graphics at 2bpp. Commodore sold an Ethernet board for it along with Unix on tape.</p><p>The X-Surf is really an ISA card, probably NE2000, mounted in a little carrier. There are confusingly few pins attached and the logic on the carrier amounts to a few small 7400 series chips and one slightly larger chip that also couldn't possibly have enough logic on it to do what it does. And then just to convince you that your nuts, it adds an IDE port that alone has more lines than the one little adapter chip does. The Amiga really is a machine for psychopaths, by psychopaths. Everyone sits around all of the time trying to out psycho everyone else. Just take a look at the demo scene for the thing. Amiga virtually defined the demo scene.</p><p>I have/had Amiga OS 3.9 on the thing. 3.9 is post-Commodore death. Someone bought the rights and sold them and someone bought them and sold them and so on until a sue happy band of self righteous ruffians managed to convince the remaining user base buying the rights at garage sale prices entitled them to be king of the squalid kingdom so that they could go around lynching anyone else trying to do anything for the Amiga. Anyway, OS 3.9 is pretty recent as far as Amiga stuff goes, even though it's ten years old. Most people stopped at 3.1. 3.9 only came out on CD-ROM. The 3000 doesn't have a bay but it does have SCSI, so the CD-ROM, when needed, gets hung off the side with the case open. I could also set up an enclosure and plug it into the back. I could also probably buy one of those.</p><p>X-Surf's stuff did not want to install.</p><p>X-Surf actually had an installer, which is impressive. AmigaOS 3.x has a scripting language for installers and an interpreter for that. This installer gave you the choice of two TCP stacks. AmigaOS 3.9 comes with a TCP stack but you can still swap it out. It's a bit Windows 3.1-like in that regard. The options are GENESiS/AmiTCP and Miami. GENESiS, the AmiTCP configurerer and dialer that cames with AmiTCP, was shipped in a version requiring libraries not included in AmigaOS3.9 so it wouldn't run. AmiTCP would, and AmiTCP was on the HD, though buried a bit. Miami is shareware/crippleware. It required the same library, MagicUI, that I didn't have.</p><p>I spent hours sorting out what required what and what I did and didn't have and how these various packages worked and fit together. That's ignoring the device driver for the ethernet card which is straight forward. The Amiga has a directory for libraries (which end in<nobr> <wbr></nobr>.library; the Unix terseness is missing from AmigaOS even though a lot of the feel is there). AmigaOS3.9 also won't read iso9660 filesystem CDs. Perhaps some BoingBag update fixes that but the BoingBag updates themselves are large<nobr> <wbr></nobr>.lha archives. I'm avoiding plugging the serial line into a Unix machine and speaking kermit or zmodem or something to transfer stuff. I've been down that road. Eventually I burned AmigaSYS4, a version of AmigaOS3.9 with lots of add-ons and the various BoingBag updates on it, stick it in the Amiga, and was able to steal MUI off of it and get both TCP stacks running.</p><p>Amiga programmers love to do ports of Unix software and add GUIs. They've been doing this for ages. They've had gcc since the early ages of gcc, and I ran the Amylaar MUD driver on AmigaOS 1.3 to do development locally, also in the dark ages. Kicking around on aminet.net from the Amiga, I see PHP, MySQL, Apache, bittorrent, Python, bind9, samba, VNC, and all sorts of stuff. No one ports just the client. If they port the client, they port the server, too. In the case of AmiTCP, the suite of utilities you'd expect are there, such as host, finger, traceroute, and so on, but to configure TCP/IP, you run a little GUI program and it asks you questions. It took Linux ages to get to this point and Amiga was doing it long before. One of the extras on the Extras disc, even as far back as 1.3, was a version of emacs with drop down menus.</p><p>Completely unsurprisingly, the 16mhz 68030 processor running AWeb (which does some JavaScript) is vastly faster than firefox on my 1.2ghz Centrino Linux machine. Amiga programmers do not write slow software. It's entirely against their nature. Threading is fantastic. It'll do downloads, render several jpgs in the page, update the page layout as HTML comes across, and never lose snappy UI responsiveness. On firefox, I yank on the scrollbar only to have it ignore me and snap back, or else the scroll bar doesn't move at all, or the whole thing just goes away for a few heart sinking seconds, making me wonder if it just crashed.</p><p>My ambition is to get a desk in a shared office space going and stick this baby there with an updated video card that does high res, high bit depth graphics. If I'm willing to start replacing and upgrading chips on the motherboard, I can take the thing up to a gig of RAM, too, and NetBSD supports it if I ever decide I want to see how firefox runs on a 16mhz processor. What I'm really hoping for is someone to take the latest Coldfire chips from Motorola's spin off, Freescale, and do an 800mhz accelerator card for the Amiga 2000/3000/4000. That would RULE.</p><p>-scott</p> scrottie 2010-08-25T20:09:48+00:00 journal Austrian Perl Workshop 2010 - Call for papers http://use.perl.org/~daxim/journal/40514?from=rss <p>English below </p><p>&#8213;&#8213;&#8213;&#8213; </p><p>Wir rufen zum Einreichen von Vortr&#228;gen und Workshops f&#252;r den &#246;sterreichischen Perlworkshop 2010 auf, der am 5.&#8211;6. November in Wien stattfinden wird. Wir m&#246;chten gerne eure Themen &#252;ber die Sprachfamilie Perl und damit verbundenes erfahren. Der Stichtag dazu ist der 8. Oktober. </p><p>Um einen Vorschlag einzureichen und f&#252;r weitere Details, siehe <a href="http://2010.useperl.at/">unsere Website</a>. Bitte <a href="http://2010.useperl.at/apw2010/atom/de.xml">abonniert den Feed</a> f&#252;r zuk&#252;nftige Benachrichtigung. </p><p>Die Orgas </p><p>&#8213;&#8213;&#8213;&#8213; </p><p>We are announcing the call for papers for talks and workshops for the Austrian Perl Workshop 2010 which will be held on November 5th&#8211;6th in Vienna. We would like to hear about your ideas concerning the Perl family of languages and related topics. The deadline for submissions is October 8th. </p><p>To submit a talk abstract and for further details visit <a href="http://2010.useperl.at/">our web site</a>. Please <a href="http://2010.useperl.at/apw2010/atom/de.xml">subscribe to the newsfeed</a> to stay updated. </p><p>The organisers</p> daxim 2010-08-25T09:34:44+00:00 events Flore Louise Apolline Bruhat-Souche http://use.perl.org/~BooK/journal/40510?from=rss <p>On Thursday, August 19, 2010 at 9:30, Flore Louise Apolline Bruhat-Souche was born. She weighs 3.02 kg and measures 48 cm. </p><p> Word already spread through IRC (#perlfr and #yapc mostly) and via email and telephone. </p><p> The mother is fine, the father is slightly tired and the <a href="http://use.perl.org/~BooK/journal/33509">big sister</a> is happy. </p><p> There is <a href="http://flore.bruhat-souche.net/">one photo online</a>. </p> BooK 2010-08-20T22:17:07+00:00 journal Will parrot be the last one standing? http://use.perl.org/~nicholas/journal/40509?from=rss <p>I'm a bit behind the times here, but I read today that one of the two remaining developers of IronRuby has left Microsoft:</p><blockquote><div><p>Overall, I see a serious lack of commitment to IronRuby, and dynamic language on<nobr> <wbr></nobr>.NET in general. At the time of my leaving Tomas and myself were the only Microsoft employees working on IronRuby.</p></div></blockquote><p> <a href="http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html">http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.ht<nobr>m<wbr></nobr> l</a>*</p><p>So if Microsoft's interest in dynamic languages is wilting, and Oracle's litigation scares everyone away from Java, will that leave <a href="http://parrot.org/">Parrot</a> as the last one standing?</p><p> <small>* yep, that's a formatting bug. I assume that it's not worth reporting while the site's future is unclear.</small> </p> nicholas 2010-08-20T09:37:19+00:00 journal Speaking at Microsoft TechEd - Any issues you want raised? http://use.perl.org/~Alias/journal/40508?from=rss <p>Next week I will at Microsoft's TechEd Australia event, courtesy of Microsoft Australia and Microsoft Open Source Labs.</p><p>More specifically, I'll be attending the Open Source mini-conf and discussion day on Tuesday, and presenting in the Community Presentations to Microsoft session on the current state of Perl and Windows on Wednesday.</p><p>Likely topics will include a review of the first year of the CPAN Testing Lab and a second-generation based on their Cloud Services, free code signing certificates for open source developers, and what issues are slowing us down or blocking progress.</p><p>So consider this your opportunity to raise any outstanding issues you have with Microsoft and Perl. What problems are you still seeing, what would like fixed or changed, and what is on your want-to-have list?</p><p>I'll try to address as many of your issues as possible in the time I have available with them (which is actually pretty substantial).</p> Alias 2010-08-20T03:20:46+00:00 journal Consistent GUIs; Or, Using WPF for Good and Not Evil http://use.perl.org/~Mark+Leighton+Fisher/journal/40505?from=rss <p> <a href="http://www.rollthunder.com/SoftwareThatDoesntSuck/WpfForGoodAndNotEvil.htm">Using WPF for Good and Not Evil</a> is a nice little write-up on how we, as developers, need to consider why and how we might change the user interface of programs developed in WPF. My take on it is that "Just because you can do something does not mean you SHOULD do something."</p><p> <i>(Ob.Perl: Perlesque should let you program directly in WPF by using the<nobr> <wbr></nobr>.NET libraries.)</i> </p> Mark Leighton Fisher 2010-08-19T16:43:59+00:00 others Alien::SVN - new release, new management http://use.perl.org/~schwern/journal/40503?from=rss <p>Those of you still stuck using Subversion will be happy to find <a href="http://search.cpan.org/~mlanier/Alien-SVN-1.6.12.0/">a new release of Alien::SVN</a>. It drags it forward to 1.6.12, doesn't do much else.</p><p>Also, Alien::SVN has finally found a new manager! From out of the blue comes <a href="http://search.cpan.org/~mlanier/">Matthew Lanier</a> with a patch and the will and a PAUSE ID. He'll be taking care of things from now on. Its his first CPAN module, be gentle. Godspeed, Matthew.</p> schwern 2010-08-18T22:33:29+00:00 journal How I spent my day today (or, slowass.net pops a hole) http://use.perl.org/~scrottie/journal/40501?from=rss <p>1. Ran backups<br>2. Verified integrity of ssh on my local system versus last backup; changed local passwords<br>3. Verified integrity of my linode chpass with md5sum versus previous backup<br>4. Locked accounts; fixed changes to shell for system programs, removed additional accounts, changed passwords<br>5. Killed root processes and shells; accounted for all of the shells and processes in ps<br>6. Compared md5sums of everything in ps, login shells, rsync, inetd, su, vmlinuz, ps and various things between previous backup and current<br>7. compared nmap to netstat -lnp; accounted for netstat -lnp entries<br>8. Ran find to find setuid/setgid programs; verified no additional ones exist; ran md5sum against existing ones<br>9. Replace sshd, ssh and their config files and host keys; restarted sshd; relogged and changed passwords<br>10. Upgrade sshd<br>11. Killed<nobr> <wbr></nobr>.ssh directories<br>12. Temporarily took some services down until I can decide if I trust/replace them (squid, cron, sendmail)<br>13. diff -r'd between the two backups; read through the output to account for all changes to the system (new files and changed files) (several notable)<br>14. Ran find to find world writable files; ran find to find device files in the wilds of the filesystem</p> scrottie 2010-08-17T05:30:44+00:00 journal TPF News website redesign http://use.perl.org/~jj/journal/40500?from=rss <p> I've just uploaded a new design for <a href="http://news.perlfoundation.org/">http://news.perlfoundation.org</a>. Based on the <a href="http://perldoc.perl.org/">perldoc.perl.org</a> style, it implements Phil Smith's idea for the "Explore Perl" toolbar. I'll blog in more detail about this later, but essentially we've now got a single list of links that appear on multiple sites but are maintained in <a href="http://github.com/jonallen/perldoc.perl.org/blob/master/static/exploreperl.js">a single place</a>. </p><p> Many thanks to Ask, Squeaky, Phil Smith, and Karen for their help and ideas. </p><p> P.S. As with any redesign there may be the odd browser issue or bug, so if anything looks amiss please email me at <a href="mailto:jj@jonallen.info">jj@jonallen.info</a> and I'll look into it. </p> jj 2010-08-16T19:57:22+00:00 journal Eek! I wrote some Perl! http://use.perl.org/~Kake/journal/40498?from=rss I haven't written any Perl in a long time, but some fell out yesterday so I thought I'd mention it here. It's to do with Chinese text, specifically ways to grep in a traditional-simplified-insensitive way. More details <a href="http://kake.dreamwidth.org/45318.html">on my regular blog</a>. (Comments are enabled here, but preferred there &#8212; you can use OpenID or just sign your name so I know who you are.) Kake 2010-08-16T09:54:56+00:00 journal Class::XSAccessor now even faster'er http://use.perl.org/~Alias/journal/40497?from=rss <p>The new 1.07 release of <a href="http://search.cpan.org/perldoc?Class::XSAccessor">Class::XSAccessor</a> mentions the use a new somewhat-evil technique for making the code even faster than it was previously.</p><p>But how much faster is it?</p><p>The following are being run on a fairly typical corporate Windows XP machine, with Strawberry Perl 5.10.1 and thread support.</p><p>First, some benchmarks using the previous 1.05 release (two runs)</p><blockquote><div><p> <tt>Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true...<br>accessor_get:&nbsp; 1 wallclock secs ( 2.51 usr +&nbsp; 0.00 sys =&nbsp; 2.51 CPU) @ 3976143.14/s (n=10000000)<br>accessor_set:&nbsp; 2 wallclock secs ( 3.09 usr +&nbsp; 0.00 sys =&nbsp; 3.09 CPU) @ 3233107.02/s (n=10000000)<br>constructor: 16 wallclock secs (15.67 usr +&nbsp; 0.00 sys = 15.67 CPU) @ 638080.65/s (n=10000000)<br>&nbsp; &nbsp; &nbsp;false:&nbsp; 2 wallclock secs ( 1.91 usr +&nbsp; 0.00 sys =&nbsp; 1.91 CPU) @ 5243838.49/s (n=10000000)<br>&nbsp; &nbsp; getter:&nbsp; 1 wallclock secs ( 2.34 usr +&nbsp; 0.00 sys =&nbsp; 2.34 CPU) @ 4266211.60/s (n=10000000)<br> &nbsp; predicate:&nbsp; 1 wallclock secs ( 2.38 usr +&nbsp; 0.00 sys =&nbsp; 2.38 CPU) @ 4210526.32/s (n=10000000)<br>&nbsp; &nbsp; setter:&nbsp; 2 wallclock secs ( 3.27 usr +&nbsp; 0.00 sys =&nbsp; 3.27 CPU) @ 3061849.36/s (n=10000000)<br>&nbsp; &nbsp; &nbsp; true:&nbsp; 1 wallclock secs ( 1.80 usr +&nbsp; 0.00 sys =&nbsp; 1.80 CPU) @ 5564830.27/s (n=10000000)<br> &nbsp; <br>Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true...<br>accessor_get:&nbsp; 3 wallclock secs ( 2.51 usr +&nbsp; 0.00 sys =&nbsp; 2.51 CPU) @ 3976143.14/s (n=10000000)<br>accessor_set:&nbsp; 3 wallclock secs ( 3.14 usr +&nbsp; 0.00 sys =&nbsp; 3.14 CPU) @ 3183699.46/s (n=10000000)<br>constructor: 15 wallclock secs (15.73 usr +&nbsp; 0.00 sys = 15.73 CPU) @ 635566.29/s (n=10000000)<br>&nbsp; &nbsp; &nbsp;false:&nbsp; 2 wallclock secs ( 1.86 usr +&nbsp; 0.00 sys =&nbsp; 1.86 CPU) @ 5379236.15/s (n=10000000)<br>&nbsp; &nbsp; getter:&nbsp; 3 wallclock secs ( 2.50 usr +&nbsp; 0.00 sys =&nbsp; 2.50 CPU) @ 4000000.00/s (n=10000000)<br> &nbsp; predicate:&nbsp; 3 wallclock secs ( 2.47 usr +&nbsp; 0.00 sys =&nbsp; 2.47 CPU) @ 4050222.76/s (n=10000000)<br>&nbsp; &nbsp; setter:&nbsp; 4 wallclock secs ( 3.13 usr +&nbsp; 0.00 sys =&nbsp; 3.13 CPU) @ 3200000.00/s (n=10000000)<br>&nbsp; &nbsp; &nbsp; true:&nbsp; 2 wallclock secs ( 1.98 usr +&nbsp; 0.00 sys =&nbsp; 1.98 CPU) @ 5037783.38/s (n=10000000)</tt></p></div> </blockquote><p>And now again with the new 1.07 release.</p><blockquote><div><p> <tt>Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true...<br>accessor_get:&nbsp; 2 wallclock secs ( 1.75 usr +&nbsp; 0.00 sys =&nbsp; 1.75 CPU) @ 5711022.27/s (n=10000000)<br>accessor_set:&nbsp; 1 wallclock secs ( 2.69 usr +&nbsp; 0.00 sys =&nbsp; 2.69 CPU) @ 3721622.63/s (n=10000000)<br>constructor: 15 wallclock secs (15.62 usr +&nbsp; 0.00 sys = 15.62 CPU) @ 640000.00/s (n=10000000)<br>&nbsp; &nbsp; &nbsp;false:&nbsp; 1 wallclock secs ( 1.28 usr +&nbsp; 0.00 sys =&nbsp; 1.28 CPU) @ 7806401.25/s (n=10000000)<br>&nbsp; &nbsp; getter:&nbsp; 1 wallclock secs ( 1.56 usr +&nbsp; 0.00 sys =&nbsp; 1.56 CPU) @ 6397952.66/s (n=10000000)<br> &nbsp; predicate:&nbsp; 2 wallclock secs ( 1.92 usr +&nbsp; 0.00 sys =&nbsp; 1.92 CPU) @ 5205622.07/s (n=10000000)<br>&nbsp; &nbsp; setter:&nbsp; 3 wallclock secs ( 2.50 usr +&nbsp; 0.00 sys =&nbsp; 2.50 CPU) @ 4000000.00/s (n=10000000)<br>&nbsp; &nbsp; &nbsp; true:&nbsp; 2 wallclock secs ( 1.55 usr +&nbsp; 0.00 sys =&nbsp; 1.55 CPU) @ 6464124.11/s (n=10000000)<br> &nbsp; <br>Benchmark: timing 10000000 iterations of accessor_get, accessor_set, constructor, false, getter, predicate, setter, true...<br>accessor_get:&nbsp; 2 wallclock secs ( 1.78 usr +&nbsp; 0.00 sys =&nbsp; 1.78 CPU) @ 5614823.13/s (n=10000000)<br>accessor_set:&nbsp; 3 wallclock secs ( 2.63 usr +&nbsp; 0.00 sys =&nbsp; 2.63 CPU) @ 3809523.81/s (n=10000000)<br>constructor: 16 wallclock secs (15.69 usr +&nbsp; 0.00 sys = 15.69 CPU) @ 637429.88/s (n=10000000)<br>&nbsp; &nbsp; &nbsp;false:&nbsp; 2 wallclock secs ( 1.22 usr +&nbsp; 0.00 sys =&nbsp; 1.22 CPU) @ 8203445.45/s (n=10000000)<br>&nbsp; &nbsp; getter:&nbsp; 2 wallclock secs ( 1.53 usr +&nbsp; 0.00 sys =&nbsp; 1.53 CPU) @ 6535947.71/s (n=10000000)<br> &nbsp; predicate:&nbsp; 2 wallclock secs ( 1.78 usr +&nbsp; 0.00 sys =&nbsp; 1.78 CPU) @ 5614823.13/s (n=10000000)<br>&nbsp; &nbsp; setter:&nbsp; 2 wallclock secs ( 2.56 usr +&nbsp; 0.00 sys =&nbsp; 2.56 CPU) @ 3903200.62/s (n=10000000)<br>&nbsp; &nbsp; &nbsp; true:&nbsp; 2 wallclock secs ( 1.48 usr +&nbsp; 0.00 sys =&nbsp; 1.48 CPU) @ 6738544.47/s (n=10000000)</tt></p></div> </blockquote><p>The numbers are pretty impressive.</p><p>The 'accessor', 'setter', 'predicate' and 'true' methods are about 25% faster, while 'getter' is a whopping 60% faster and (curiously) 'false' is about 50% faster as well.</p><p>Constructors are really the only thing that hasn't changed.</p><p>Impressive work, even if the code is a bit risky.</p> Alias 2010-08-16T03:04:05+00:00 journal Why does Object::Tiny only support getters http://use.perl.org/~Alias/journal/40496?from=rss <p><a href="http://perlalchemy.blogspot.com/2010/08/objecttinyrw-and-moosexnonmoose.html">http://perlalchemy.blogspot.com/2010/08/objecttinyrw-and-moosexnonmoose.html</a></p><p>Zbigniew Lukasiak tries out <a href="http://search.cpan.org/peldoc?Object::Tiny">Object::Tiny</a> and wonders why it is that I didn't allow for the creation of setters when it is only a one line change.</p><p>Like most<nobr> <wbr></nobr>::Tiny modules the reason is a bit complex and the result of compromises.</p><p>Object::Tiny began as an attempt to create a lighter, faster, version of Class::Accessor. A way to bulk-generate the accessor code I had to type over and over again.</p><p>However, where I differ is a strong preference for light and elegant API design.</p><p>And so I decided to implement mine with as little implementation code as possible, and as little API code as possible.</p><p>Once you have decided to go down the simplicity path, there's a couple of standard techniques you often end up using.</p><p>The first and most important is state reduction.</p><p>In their introduction to Erlang, the founders of that language describe state as one of the main sources of failures in programs. And so anything that removes state, at the very least unnecessary state, is a positive. Especially if the state reduction also results in code reduction, and a reduction in computation.</p><p>So take the following example, where we create an object with some attributes and then run some code that will use those object attributes..</p><blockquote><div><p> <tt>my $object = Class-&gt;new;<br>$object-&gt;foo(1);<br>$object-&gt;bar(2);<br>$object-&gt;do_something;</tt></p></div> </blockquote><p>This is a use case that we see fairly often, but it's really quite horrible code. It is really only the object-oriented equivalent of something like the following.</p><blockquote><div><p> <tt>our $Object::foo = 1;<br>our $Object::bar = 2;<br>do_something('Object');</tt></p></div> </blockquote><p>It is especially bad code if the following code would throw an exception.</p><blockquote><div><p> <tt>my $object = Class-&gt;new;<br>$object-&gt;do_something;</tt></p></div> </blockquote><p>If this blows up, then you are REALLY doing something wrong, because you have allowed the creation of completely invalid objects. Now anybody taking one of these objects as a parameters needs to do with following.</p><blockquote><div><p> <tt>sub foo {<br>&nbsp; &nbsp; my $object = shift;<br>&nbsp; &nbsp; unless (<br>&nbsp; &nbsp; &nbsp; &nbsp; $object-&gt;isa('Class')<br>&nbsp; &nbsp; &nbsp; &nbsp; and<br>&nbsp; &nbsp; &nbsp; &nbsp; defined $object-&gt;foo<br>&nbsp; &nbsp; &nbsp; &nbsp; and<br>&nbsp; &nbsp; &nbsp; &nbsp; $object-&gt;foo &gt; 0<br>&nbsp; &nbsp; &nbsp; &nbsp; and<br>&nbsp; &nbsp; &nbsp; &nbsp; defined $object-&gt;bar<br>&nbsp; &nbsp; &nbsp; &nbsp; and<br>&nbsp; &nbsp; &nbsp; &nbsp; $object-&gt;bar &gt; 2<br>&nbsp; &nbsp; ) {<br>&nbsp; &nbsp; &nbsp; &nbsp; die "Invalid object";<br>&nbsp; &nbsp; }<br>}</tt></p></div> </blockquote><p>If you are going to create an object for something, you HAVE to be sure that the objects are trustworthy.</p><p>And so you should never allow objects to exist that are invalid. EVERY object should be a valid object.</p><p>At the absolute minimum objects should be able to default every attribute to something reasonable and unlikely to cause problems.</p><p>But this still results in excess and wasteful work, because the object has to transition through two or more states.</p><p>You start with an object with parameters and defaults, and you validate them. And then you change on of the attributes immediately, validating it AGAIN. In the mean time, your object exists in a state that it will never actually be used in.</p><p>And so everywhere you possibly can, you should be setting attributes in the constructor rather than afterwards.</p><blockquote><div><p> <tt>my $object = Class-&gt;new(<br>&nbsp; &nbsp; foo =&gt; 1,<br>&nbsp; &nbsp; bar =&gt; 2,<br>);<br>$object-&gt;do_something;</tt></p></div> </blockquote><p>Less state, less complexity, less CPU, and less bugs.</p><p>If we accept this model of pushing all the configuration into the object up front to reduce state, then why change the object arbitrarily?</p><p>In fact, anything that you ARE going to change should be done under very controlled conditions.</p><p>It should require a dedicated method to apply the change, it should require validation, and work. It shouldn't be trivial, and it shouldn't be automatic.</p><p>If I had my way, Moose would set is =&gt; 'ro' by default, to make people think before they go about simply allowing stuff to change.</p><p>It also happens to let you shrink down the API markedly.</p><p>There are three potential use cases available when implementing accessors. Everything readonly, everything readwrite, or mixed.</p><p>With Object::Tiny, I was aiming for the smallest possible code.</p><p>Implementing either all-readonly or all-readwrite can be done with the following.</p><blockquote><div><p> <tt>use Class qw{<br>&nbsp; &nbsp; foo<br>&nbsp; &nbsp; bar<br>};</tt></p></div> </blockquote><p>By contrast, if we want to allow mixed readonly and readwrite, we would need some way of distinguishing. Something like the following.</p><blockquote><div><p> <tt>use Class {<br>&nbsp; &nbsp; readonly =&gt; [ 'foo' ],<br>&nbsp; &nbsp; readwrite =&gt; [ 'bar' ],<br>};<br> &nbsp; <br>use Class [ qw{<br>&nbsp; &nbsp; foo<br>} ], [ {<br>&nbsp; &nbsp; bar<br>} ];<br> &nbsp; <br>use Class {<br>&nbsp; &nbsp; foo =&gt; 'ro',<br>&nbsp; &nbsp; bar =&gt; 'rw',<br>};</tt></p></div> </blockquote><p>No matter how you try, there's always an inherent additional element of complexity that results from the split between them.</p><p>And so the decision to go with all-readonly in Object::Tiny is a combination of these two issues.</p><p>If went with all-readwrite, I'm practically encouraging bad behaviour and more bugs. If I went with mixed accessors, the API would remain relative complex.</p><p>In the end, the best way to achieve both API simplicity and code safety is to only provide read-only accessors, and anything more complex should require both though and effort.</p> Alias 2010-08-15T01:39:50+00:00 journal Comments re The Modern Perl book http://use.perl.org/~Ron+Savage/journal/40495?from=rss <p>Hi Folks</p><p>OK, so modernperlbooks.com and Moveable Type have disabled my password for the 3rd time. I get the hint. I won't be back (there).</p><p>And no, I didn't forget it. I keep it in an encrypted file along with all the other passwords I've collected...</p><p>For the record, in the past I pretended I'd lost my password, and re-registered, but I'm sick of doing that.</p><p>As for the book, I have some comments, hoping chromatic stumbles across them<nobr> <wbr></nobr>:-):</p><p>1) Chapter 7: 'grovel': I don't think that's the correct usage of that word. Try 'fossick'.</p><p>2) Chapter 9: 'Alternately, use Moose and don't worry about the details' - under DOES(). Hmmmm.</p><p>This statement is far too brief. I think it should spell out exactly what a programmer needs to do in this situation when using Moose.</p><p>Cheers</p> Ron Savage 2010-08-14T00:58:29+00:00 journal Upcoming Events with Perl content http://use.perl.org/~gabor/journal/40489?from=rss I have not posted here for ages but according to the recent Perl Survey it seems there are still a lot of people who prefer reading use.perl.org than <a href="http://blogs.perl.org/">blogs.perl.org</a> or <a href="http://ironman.enlightenedperl.org/">Iron Man</a> <p> So just to let these readers to know, there are going to be a number of <a href="http://szabgab.com/blog/2010/08/upcoming-events-for-promoting-perl.html">tech-events with Perl content</a> where you could help out.</p> gabor 2010-08-10T17:46:55+00:00 journal Test::Builder2::Design http://use.perl.org/~schwern/journal/40487?from=rss <p>In an effort to shed some light on what Test::Builder2 is about, I took a few hours and performed a brain dump about its goals and design. You can see the result in the new <a href="http://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Design.pod">Test::Builder2::Design</a> document.</p><p>The key design goals are 1) that it has to work, 2) that it has to work everywhere and 3) that it has to test everything. This throws out a lot of 98% solutions.</p> schwern 2010-08-10T02:31:05+00:00 journal Some after-thoughts from YAPC::Europe in Pisa #yapceu2010 http://use.perl.org/~andy.sh/journal/40486?from=rss <p>Yesterday evening I was so happy to return home from Italy. No, Italy is great, my fear was my palm tree I bought last month which was standing at the door of my house without water. I am so happy to say it survived well.</p><p>The weather in Italy was amazing &#8212; nothing to do with neither Amsterdam with its moderate climate nor Moscow's fires and smog my friends suffer from.</p><p>Although Italians may be very unpleasant when they do have their critical days having to serve foreigners in bars, the general impression is definitely positive. And I was happy as a child when (yeah, after some drinks) was able to use my Italian (which is obviously much much better than my Dutch or Latvian<nobr> <wbr></nobr>:-) for short communications asking for directions or at cafes/airport/taxi/hotel. Really, I did not expect it from myself as I have only passed basic Italian course living in Moscow more than a half year ago, and had no experience after that.</p><p>OK, being a crazy one (in a terminology of Cog), conferences for me is not only talks or travel fun, but also a keep-my-eye-on behaviour how all is going on from the point of view of the organizers.</p><p>Have to say that the conference was organized pretty well. There were a couple of things I'd like to improve, but that was not too important for the conference itself as well for most of the attendees.</p><p>First, there were no printed schedule in the morning of the first day. Even if everyone seems to bring their laptop, online schedule is not the one I prefer personally. Like with books, paper is preferable for human.</p><p>The second thing was lack of information of what and where goes on beyond the conference. Namely, I missed Night Pisa tour, and lots of us had difficulties with figuring out where the post-conference meeting takes place (and later, finding the way to it). Not to say that the bar selected for that was awful even if the personnel spoke English (I'd prefer much more entertaining Italian speaker than the one speaking English and hating foreigners).</p><p>As for talks, I can't say I fully enjoyed the programme, as being a person driven by ideas I can't attend talks with lots of Moose/Catalyst/internals/DB boring stuff<nobr> <wbr></nobr>:-) Opposite, every Perl 6 talk I attended was amazing (although I missed two and a half of them due to some collisions in my personal schedule). Hope one day to see talk recordings online (and would like to update yapc.tv as well). My personal grand prix goes to the talk on NQP by Patrick. It was a good introduction into a sublanguage I never considered worth to explore.</p><p>And I'like to say that I am looking forward to Perl 6 hackathon we would like to organize in Moscow on the day before YAPC::Russia, namely on 13th of May 2011. I'll find the venue for that.</p><p>And not to forget, we won the contest and (ha-ha, have to) are hosting the next YAPC::Europe in Riga, 15-17 August of 2011.</p><p>Cheers.</p> andy.sh 2010-08-09T11:29:13+00:00 journal My reply to Removing database abstraction http://use.perl.org/~scrottie/journal/40482?from=rss <p>My longwinded response to http://blogs.perl.org/users/carey_tilden/2010/08/removing-database-abstraction.<nobr>h<wbr></nobr> tml :</p><p>Don't get trapped in the mindset of "I have to use X because if I don't, I'm doing it wrong". Quite often, if you don't use X, it's entirely too easy to do it wrong if you don't know what you're doing. You probably don't want to re-implement CGI parameter parsing, for example. But that's not the same thing as saying that you should always use CGI because it's a solved problem so never do anything else. Nothing is a solved problem. mod_perl is a valid contender to CGI and now Plack is a valid contender to mod_perl. FastCGI was and is a valid contender to mod_perl and servers like nginx do awesome thing. Yet, tirelessly, the fans of one explain that the competing ideas are somehow not valid.</p><p>Sorry, I'm trying to do proof by analogy here. It isn't valid except to the degree that it is. I'll get to databases in a minute.</p><p>Quick recap: there are lots of valid approaches; using an alternative is not the same as re-inventing the wheel.</p><p>Furthermore, the heaviest technology is seldom the long term winner. Witness the return to lighter HTTP pipelines. For ages, Apache boasted being a bit faster than IIS, in response to which I could only wonder why Apache was so slow.</p><p>Okay, back to databases. DBIx::Class to a relational database is a valid option. It's also very heavy. It alo doesn't really let you scale your web app out unless the database in question is DB2, Oracle, or one of a few of those that runs on a cluster with a lot of processors rather than just one computer. Otherwise you've just added a new bottleneck. DBIx::Class makes it harder to do real relational work -- subqueries, having, or anything hairy. At the very least, you have to create a class file with a lot of boilerplate, reference that file from other files that you made or generated, and stuff the same SQL into there. Abstracting the querying away in simple cases makes it easier to query the database without thinking about it. This leads you to query the database without thinking about it. That's a double edged sword. In some cases, that's fantastic.</p><p>Lego blocks make it easy to build things but you seldom buy home appliances built out of Legos. Even more so for Duplo blocks. Some times easy tools are in order; some times, low level engineering with an RPN HP calculator is absolutely in order.</p><p>Okay, I'll get back to databases in a minute here, but I want to talk about something outrageous for a moment -- not using a relational database at all.</p><p>I wrote and use Acme::State for simple command line and daemonized Web apps. It works well with Continuity and should work with the various Coro based Plack servers for the reason that the application stays entirely in one process. All it does is restore state of variables on startup and save them on exit or when explicitly requested. It kind of goes overboard on restoring state and does a good enough job that it breaks lots of modules if not confined to your own namespace, hence the Acme:: designation.</p><p>Similarly, people have used Data::Dumper or Storable directly (Acme::State uses Storable under the hood) to serialize datastructures on startup and exit. In AnyEvent frameworks, it's easy to set a timer that, on expiration, saves a snapshot. Marc Lehmann, the man who created the excellent Coro module, has patches to Storable to make it reenterant and incremental, so that the process (which might also be servicing network requests for some protocol) doesn't get starved for CPU while a large dump is made. His Perl/Coro based multiplayer RPG is based on this idea. With hundreds of users issuing commands a few times a second, this is the only realistic option. If you tried to create this level of performance with a database, you'd find that you had to have the entire working set in RAM not once but several times over in copies in parallel database slaves. That's silly.</p><p>You can be very high tech and not use a database. If you're not actually using the relational capabilities (normalized tables, joining tables, filtering and aggregating, etc), then a relational database is a slow and verbose to use (even with DBIx::Class) replacement for dbmopen() (perldoc -f dbmopen, but use the module instead). You're not gaining performance, elegance or scalability, in most cases. People use databases automatically and mindlessly now days to the point where they feel they have to, and by virtue of having to use a database, they have to ease the pain with an ORM.</p><p>Anytime someone says "always", be skeptical. You're probably talking to someone who doesn't understand or doesn't care about the tradeoffs involved.</p><p>Okay, back to databases. Right now, it's trendy to create domain specific languages. The Ruby guys are doing it and the Perl guys have been doing it for ages. Forth was created around the idea -- the Forth parser is written in Forth and is extensible. Perl 5.12 lets you hijack syntax parsing with Perl in a very Forth-ish style. Devel::Declare was used to create proper argument lists for functions inside of Perl. There's a MooseX for it and a standalone one, Method::Signatures. That idea got moved into core. XS::APItest::KeywordRPN is a demo. Besides that, regular expressions and POD are two other entire syntaxes that exist in<nobr> <wbr></nobr>.pl and<nobr> <wbr></nobr>.pm files. It's hypocritical to say that it's somehow "bad" to mix languages. It's true that you don't want your front end graphic designer editing your<nobr> <wbr></nobr>.pl files if he/she doesn't know Perl. If your designer does know Perl, and the code is small and doesn't need to be factored apart yet, what's the harm? It's possible to write extremely expressive code mixing SQL and Perl. Lots of people have written a lot of little wrappers. Here's one I sometimes use:</p><p>http://slowass.net/~scott/tmp/query.pm.txt</p><p>Finally, part of Ruby's appeal -- or any new language's appeal -- is lightness. It's easy to keep adding cruft, indirection, and abstraction and not realize that you're slowly boiling yourself to death in it until you go to a new language and get away from it for a while. The Ruby guys, like the Python guys before them, have done a good job of building up simple but versatile APIs that combine well with each other and keep the language in charge rather than any monolithic "framework". Well, except for Rails, but maybe that was a counter example that motivated better behavior. Look at Scrapi (and Web::Scraper in Perl) for an example.</p><p>Too much abstraction not only makes your code slow but it makes it hard to change development direction in the future when something cooler, faster, lighter and more flexible comes out. Just as the whole Perl universe spent ten years mired down in and entrenched in mod_perl, so is there a danger that DBIx::Class and Moose will outlive their welcome. POE, which was once a golden child, has already outlived its welcome as Coro and AnyEvent stuff has taken off. Now there are a lot of Perl programs broken up into tiny non-blocking chunks that are five times as long as they could be, and the effort to move them away from POE is just too great. The utility of a package should be weighed against the commitment you have to make to it. The commitment you have to make to it is simply how much you have to alter your programming style. With Moose as with POE, this degree is huge. DBIx::Class is more reasonable. Still, it's a cost, and things have costs.</p><p>Thank you for your article.</p><p>Regards,<br>-scott</p> scrottie 2010-08-06T21:53:04+00:00 journal Trailer Theory - Reinvented for Ignite Sydney as Economics http://use.perl.org/~Alias/journal/40480?from=rss <p>Back in 2005 in <a href="http://use.perl.org/~Alias/journal/23820">only my fifth use.perl post ever</a>, I outlined an idea I had been developing for a couple of years that I called "Trailer Theory".</p><p>A few years ago on my Portable Perl world hack'a'tour, I took with me a lightning talk version of the concept. It was a pretty crude talk but was received, it seemed, fairly well by the development community.</p><p>Since that trip, and inspired by the unexpected conversion of my "Perl is unparsable" claims in the PPI docs into a formal mathematical proof (complete with "Kennedy's Lemma") I've been wondering if this "Trailer Theory" idea could really be developed as a proper scientific proof, and if so what would that look like.</p><p>A couple of months ago I presented a new version of the talk at Ignite Sydney, speaking to an mixed audience of Twitterati, social media, advertising and journalist types.</p><p>I've rebuilt the talk from scratch and tried to outline the same idea, but in the form of a kind of layman's Economics Proof.</p><p>I hope you enjoy the result.</p><p><a href="http://igniteshow.com/videos/using-economics-make-movies-suck-less">Adam Kennedy - Using Economics to make movies suck less</a></p><p><i><br>Notes for other speakers:</i></p><p><i>1. Ignite advances slides every 15 seconds, no clickers allowed. This turns out to take a shitload of practice to get right.</i></p><p><i>2. When someone says to you "Here's your mark, you need to stay on this line to be in the fixed spot" it helps to pay attention. FAIL<nobr> <wbr></nobr>:)<br></i></p> Alias 2010-08-04T05:40:53+00:00 journal App::Office::CMS - A Canny, Microlight and Simple CMS http://use.perl.org/~Ron+Savage/journal/40478?from=rss <p>Hi Folks</p><p>It's slow work, but I <i>am</i> making progress on App::Office::CMS.</p><p>It's based on CGI::Application and friends, to help sustain the microlight claim.</p><p>Which Javascript library, I hear you all cry!</p><p>YUI. You should have guessed.</p><p>Only a few weeks now...</p><p>Cheers<br>Ron</p> Ron Savage 2010-08-03T08:15:12+00:00 journal Protesting the Moose with sugary alternatives http://use.perl.org/~Alias/journal/40477?from=rss <p>At work, we've been experimenting with Moose because in our enormous and complex codebase we think we can probably benefit a lot from the extra rigour that it brings.</p><p>Before I continue, let me note that ours is a typical mod_perl enterprise setup with 6gig of memory per machine, so any memory consumed before the Apache fork is essentially free.</p><p>So none of the issues people (including me) have with startup code and memory consumption apply in this case, and I won't be addressing performance issues in this post.</p><p>The consensus of the half-dozen people at work is how Moose tries to look like a declarative extension, but doesn't actually act like it.</p><p>The following is what Moose seems to have been aiming for.</p><blockquote><div><p> <tt>package Foo;<br> &nbsp; <br>use Moose;<br> &nbsp; <br>extends 'Bar';<br>with&nbsp; &nbsp; 'Role1';<br>with&nbsp; &nbsp; 'Role2';<br> &nbsp; <br>has this =&gt; (<br>&nbsp; &nbsp; is&nbsp; =&gt; 'ro',<br>&nbsp; &nbsp; isa =&gt; 'Str',<br>);<br> &nbsp; <br>has that =&gt; (<br>&nbsp; &nbsp; is&nbsp; =&gt; 'ro',<br>&nbsp; &nbsp; isa =&gt; 'Str',<br>);<br> &nbsp; <br>1;</tt></p></div> </blockquote><p>Unfortunately, this is what we've had to do instead.</p><blockquote><div><p> <tt>package Foo;<br> &nbsp; <br>use Moose;<br> &nbsp; <br>BEGIN { # When we use Catalyst<br>&nbsp; &nbsp; extends 'Bar';<br>}<br> &nbsp; <br>has this =&gt; (<br>&nbsp; &nbsp; is&nbsp; =&gt; 'ro',<br>&nbsp; &nbsp; isa =&gt; 'Str',<br>);<br> &nbsp; <br>has that =&gt; (<br>&nbsp; &nbsp; is&nbsp; =&gt; 'ro',<br>&nbsp; &nbsp; isa =&gt; 'Str',<br>);<br> &nbsp; <br>with&nbsp; &nbsp; 'Role1';<br>with&nbsp; &nbsp; 'Role2';<br>no Moose;<br>__PACKAGE-&gt;meta-&gt;make_immutable;</tt></p></div> </blockquote><p>This "real Moose" code totally spoils the dream of what we felt like we were going to get when we started to play with it.</p><p>Most of our current options for fixing this amount to either.</p><p>a) Add this extra dependency that will unscrew one of the other of the problems (namespace::autoclean)</p><p>b) Use this SECOND heavy sugar layer on top of the FIRST sugar layer, on top of Class::MOP.</p><p>Is fixing the syntax or writing light weight sugar really so hard?</p><p>As a kind of protest, I tried it for myself and managed to create <a href="http://search.cpan.org/perldoc?MooseX::Atom">MooseX::Atom</a>.</p><p>This still has some flaws, but the current equivalent of the above would just be this.</p><blockquote><div><p> <tt>package Foo;<br> &nbsp; <br>use MooseX::Atom [<br>&nbsp; &nbsp; extends =&gt; 'Bar',<br>&nbsp; &nbsp; with&nbsp; &nbsp; =&gt; 'Role1',<br>&nbsp; &nbsp; with&nbsp; &nbsp; =&gt; 'Role2',<br>&nbsp; &nbsp; has&nbsp; &nbsp; &nbsp;=&gt; [<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;this =&gt; (<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;is&nbsp; =&gt; 'ro',<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;isa =&gt; 'Str',<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;),<br>&nbsp; &nbsp; ],<br>&nbsp; &nbsp; has&nbsp; &nbsp; &nbsp;=&gt; [<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;that =&gt; (<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;is&nbsp; =&gt; 'ro',<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;isa =&gt; 'Str',<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;),<br>&nbsp; &nbsp; ]<br>];<br> &nbsp; <br>1;</tt></p></div> </blockquote><p>You can do the same thing for roles with <a href="http://search.cpan.org/perldoc?MooseX::Role::Atom">MooseX::Role::Atom</a>.</p><p>Now clearly, this might have some issues. It's the work of an hour and not a whole lot of thought.</p><p>But it's still light and clean, with all the class spec in one place up the top where people are used to seeing the declarative stuff in Perl modules.</p><p>Perhaps something like this might be a little better...</p><blockquote><div><p> <tt>package Foo;<br> &nbsp; <br>use MooseX::Hash {<br>&nbsp; &nbsp; extends =&gt; 'Bar',<br>&nbsp; &nbsp; with&nbsp; &nbsp; =&gt; [ 'Role1', 'Role2' ],<br>&nbsp; &nbsp; default =&gt; { is =&gt; 'ro' },<br>&nbsp; &nbsp; has&nbsp; &nbsp; &nbsp;=&gt; {<br>&nbsp; &nbsp; &nbsp; &nbsp; this =&gt; { isa =&gt; 'Str' },<br>&nbsp; &nbsp; &nbsp; &nbsp; that =&gt; { isa =&gt; 'Str' },<br>&nbsp; &nbsp; },<br>);<br> &nbsp; <br>1;</tt></p></div> </blockquote> Alias 2010-08-03T05:09:02+00:00 journal Method::Signatures returns! 5.12, func() and fast! http://use.perl.org/~schwern/journal/40474?from=rss <p>Chip submitted a minor performance patch to Method::Signatures today. That drove me to push out <a href="http://github.com/schwern/method-signatures/blob/v20100730/Changes">a new release</a> making it friendly to 5.12 and adding func() for non methods!</p><p> &nbsp; &nbsp; &nbsp; &nbsp; func hello(:$greeting = "Hello",<nobr> <wbr></nobr>:$place = "World") {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; print "$greeting, $place!\n";<br> &nbsp; &nbsp; &nbsp; &nbsp; }</p><p> &nbsp; &nbsp; &nbsp; &nbsp; hello( place =&gt; "Earth" );</p><p>For those who don't know, one of the neato features of <a href="http://search.cpan.org/perldoc?Method::Signatures">Method::Signatures</a> is that it can <a href="http://search.cpan.org/~mschwern/Method-Signatures-20090620/lib/Method/Signatures.pm#Aliased_references">alias references</a> to make working with references less of a trial:</p><p> &nbsp; &nbsp; &nbsp; &nbsp; func popn(\@array, $howmany) {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return splice @array, -$howmany;<br> &nbsp; &nbsp; &nbsp; &nbsp; }</p><p> &nbsp; &nbsp; &nbsp; &nbsp; my @stuff = (1,2,3,4,5);<br> &nbsp; &nbsp; &nbsp; &nbsp; my @last_three = popn(\@stuff, 3); # 3,4,5<br> &nbsp; &nbsp; &nbsp; &nbsp; print @last_three;</p><p>It does this with the amazing <a href="http://search.cpan.org/perldoc?Data::Alias">Data::Alias</a> module. Unfortunately, 5.12 broke its black magic and its non-trivial to fix. Method::Signatures now makes Devel::Alias an optional dependency. If its available, it'll use it. Otherwise, no aliasing for you.</p><p>But that's ok, because perl5i makes working with references enjoyable. And while perl5i is adding its own simple signatures, they're forward compatible with Method::Signatures! They play together, so if you want perl5i and the full power of Method::Signatures you can have them.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; use perl5i::2;<br> &nbsp; &nbsp; &nbsp; &nbsp; use Method::Signatures;</p><p> &nbsp; &nbsp; &nbsp; &nbsp; func echo($message is ro) {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; say $message;<br> &nbsp; &nbsp; &nbsp; &nbsp; }</p><p>Just make sure you load MS after perl5i. The last one loaded wins.</p><p>Finally, I was comparing Method::Signatures with MooseX::Method::Signatures and made a disturbing discovery. I always new MooseX::Method::Signatures would have a performance penalty, it does more checks than Method::Signatures, I just didn't realize how bad it was.</p><p>Here's comparing an empty signature: <code>method foo() {}</code>.</p><blockquote><div><p> <tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Rate&nbsp; &nbsp; MMS&nbsp; &nbsp; &nbsp;MS&nbsp; &nbsp; Std<br>MMS&nbsp; &nbsp; 3207/s&nbsp; &nbsp; &nbsp;--&nbsp; -100%&nbsp; -100%<br>MS&nbsp; 1498875/s 46644%&nbsp; &nbsp; &nbsp;--&nbsp; &nbsp; -1%<br>Std 1508351/s 46940%&nbsp; &nbsp; &nbsp;1%&nbsp; &nbsp; &nbsp;--</tt></p></div> </blockquote><p>That's showing MooseX::Method::Signatures is 450x slower than either Method::Signatures or a normal method call creaking out a mere 3500 method calls per second as compared to the 1.5 million it should be doing. And that's for a method with an empty signature!</p><p>To be clear, that's the speed of calling a method, not compiling them.</p><p>Here's one comparing a simple signature that requires a check, so MS can't optimize it away: <code>method foo($arg!) { return $arg + 1 }</code> That's a required positional argument.</p><blockquote><div><p> <tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Rate&nbsp; &nbsp; MMS&nbsp; &nbsp; &nbsp;MS&nbsp; &nbsp; Std<br>MMS&nbsp; &nbsp; 2928/s&nbsp; &nbsp; &nbsp;--&nbsp; -100%&nbsp; -100%<br>MS&nbsp; &nbsp;983127/s 33481%&nbsp; &nbsp; &nbsp;--&nbsp; &nbsp; -2%<br>Std 1005357/s 34240%&nbsp; &nbsp; &nbsp;2%&nbsp; &nbsp; &nbsp;--</tt></p></div> </blockquote><p>3000 method calls instead of a million.</p><p>Now I'm the first to counter arguments bemoaning method call overhead. Usually it doesn't matter. Usually the extra cost of calling a method and checking arguments is insignificant compared to what that method actually does. And MooseX::Method::Signatures has features Method::Signatures does not, most significantly type checking. But my god! Three orders of magnitude of performance lost! And its not even using the extra MMS features. That's just too much.</p> schwern 2010-07-31T00:49:55+00:00 journal DEFCON, day 1 http://use.perl.org/~scrottie/journal/40473?from=rss <p>Basically no mischief or craziness. Having DEFCON at a casino did to it exactly what I would have expected. No money pots to eat the cockroach, no naked fire jugglers, no getting thrown in the pool, no parties by the pool.</p><p>Bros outnumber the blackshirts now. They're talking loudly and proudly about how little they know and care.</p><p>Kilts are representing, too. The freaks are here. There's a Japanese gang dressed in kimonos. Some other Japanese guys walked by talking vigorously amonst themselves, laughing and pointing. Punks with combs, raisers and hairspray are in the contest area/lounge dispensing mohawks. They have their own official area. Strange hats abound. One kid has a fez. There are BDUs and lab coats. Lots of colored hair.</p><p>Aha! Finally spotted someone I knew -- Kevin, a friend of Ernie's, who also worked in the gaming industry, but on a different side of it.</p><p>People are sitting next to me reading long hex strings from the "background" of the talks description book.</p><p>They ran out of badges as usual. My flight got delayed two hours which seriously cut into my time here.</p><p>"My only crime is that of outsmarting you"... shirts have slogans.</p><p>There's a lot less interesting in WiFi and a lot more in smartphones. The common area is woefully inadequate.</p><p>UnixSurplus is here again and people are packing in to see old Unix hardware. Some people are going to be coming home with O2s.</p><p>More later, perhaps.</p><p>-scott</p> scrottie 2010-07-30T19:43:53+00:00 journal Perl 6 Is The Language Your Language Could Smell Like http://use.perl.org/~schwern/journal/40472?from=rss <p><a href="http://www.youtube.com/watch?v=owGykVbfgUE">Hello programmers</a>. Look at your code, now at Perl 6, now back at your code, now back at Perl 6! Sadly, your code is not written in Perl 6. But if you use <a href="http://rakudo.org/announce/rakudo-star/2010.07">Rakudo Star</a> then Perl 6 is the language your code could be written in!</p><p><a href="http://github.com/rakudo/star/downloads">Now Microsoft scented!</a></p> schwern 2010-07-29T19:24:09+00:00 journal