jplindstrom's Friends' Journals http://use.perl.org/~jplindstrom/journal/friends/ jplindstrom'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:06:37+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 jplindstrom's Friends' Journals http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~jplindstrom/journal/friends/ 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 use Perl; Shutting Down Indefinitely http://use.perl.org/~pudge/journal/40525?from=rss <p>See <a href="http://use.perl.org/article.pl?sid=10/09/08/2053239">here</a>.</p> pudge 2010-09-08T22:07:47+00:00 useperl 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 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 Cute caps http://use.perl.org/~jdavidb/journal/40507?from=rss <p>I'm doing some quick code generation (the output is Java), and I found myself writing the below routine. I like it because of the names I picked for the variables. Not exactly self-documenting (although it is when you think about it), but this is throwaway. You can probably tell what the code is doing and why I named the variables as I did, and you might be entertained.</p><blockquote><div><p> <tt>sub uc_prop<br>{<br>&nbsp; my($prop) = @_;<br>&nbsp; my $p = substr($prop, 0, 1);<br>&nbsp; my $P = uc($p);<br>&nbsp; my $rop = substr($prop, 1);<br>&nbsp; return "$P$rop";<br>}</tt></p></div> </blockquote> jdavidb 2010-08-19T21:55:41+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 use Perl; http://use.perl.org/~pudge/journal/40493?from=rss <p>I am no longer working for Slashdot/Geeknet as of September 30. I am actively seeking new employment. Unless you want to hire me, you don't need to care, unless you also care about <a href="http://use.perl.org/">use Perl;</a>, because it has been generously hosted by Geeknet since I started the site over 10 years ago, shortly after I was hired by Andover.Net to work on Slashdot.</p><p>Long story short, I have not done much with the site in recent years, so my options at this point are to do nothing; migrate the site to a new server and keep it running as-is; or take the data and do something with it on a new site. Or something I haven't thought of.</p><p>I am hereby accepting proposals for what to do with use Perl;. In short, I would like to donate it to someone who will give it a good home. If you're interested, give me your best pitch.</p><p>Cross-posted on <a href="http://pudge.net/glob/2010/08/use-perl.html">&lt;pudge/*&gt;</a>.</p> pudge 2010-08-11T23:34:11+00:00 journal Matt Trout, aka mst, is insane http://use.perl.org/~pudge/journal/40492?from=rss <p>Wow. I occasionally, but not too often, go into #perl. Very busy with family and life. So I go in today, and for no reason, <a href="http://www.trout.me.uk/">mst</a> bans me and tells me to not come back.</p><p>What's up with him being such an irrational dick?</p> pudge 2010-08-11T16:41:54+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 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 Help? http://use.perl.org/~Alias/journal/40470?from=rss <p>(Before I begin, I should clarify I did not write this code, I'm just trying to maintain it)</p><p>The following error is the first thing spat out by make test for the Padre sync server, located at <a href="http://svn.perlide.org/padre/trunk/Madre-Sync">http://svn.perlide.org/padre/trunk/Madre-Sync</a>.</p><p>Wasn't the move of Catalyst to Moose going to make things easier?</p><p>Can someone explain how you debug this?</p><p>I get the basics, I can see the "Can't locate Madre/Sync/Schema.pm". But that file should be, I think, automatically generated. And I don't really get how to dig down the 75 caller levels from the start to the end to work out where the actual functionality is failing...</p><blockquote><div><p> <tt>not ok 1 - use Catalyst::Test;<br> &nbsp; <br>#&nbsp; &nbsp;Failed test 'use Catalyst::Test;'<br>#&nbsp; &nbsp;at t\01app.t line 7.<br>#&nbsp; &nbsp; &nbsp;Tried to use 'Catalyst::Test'.<br>#&nbsp; &nbsp; &nbsp;Error:&nbsp; Couldn't load class (Madre::Sync) because: Couldn't instantiate component "Madre::Sync::Model::padreDB", "Can't locate Madre/Sync/Schema.pm i<br>n @INC (@INC contains: blib\lib blib\arch C:/strawberry/perl/lib C:/strawberry/perl/site/lib C:\strawberry\perl\vendor\lib<nobr> <wbr></nobr>.). at C:\strawberry\perl\vendor<br>\lib/Class/MOP.pm line 132<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_first_existing_class('Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_class('Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/Catalyst/Model/DBIC/Schema/Types.pm line 21<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Model::DBIC::Schema::Types::__ANON__[C:\strawberry\perl\vendor\lib/C<nobr>a<wbr></nobr> talyst/Model/DBIC/Schema/Types.pm:21]('Madre::Sync::Schema') called<br>at C:\strawberry\perl\vendor\lib/Moose/Meta/TypeCoercion.pm line 63<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::TypeCoercion::__ANON__[C:\strawberry\perl\vendor\lib/Moose/Meta/T<nobr>y<wbr></nobr> peCoercion.pm:67]('Madre::Sync::Schema') called at C:\strawberry\per<br>l\vendor\lib/Moose/Meta/TypeCoercion.pm line 97<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::TypeCoercion::coerce('Moose::Meta::TypeCoercion=HASH(0x4a2b444)', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/Moose<br>/Meta/TypeConstraint.pm line 90<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::TypeConstraint::coerce('Moose::Meta::TypeConstraint=HASH(0x4a2985<nobr>4<wbr></nobr> )', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\lib/M<br>ooseX/Types/TypeDecorator.pm line 206<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at C:\strawberry\perl\vendor\lib/MooseX/Types/TypeDecorator.pm line 205<br>#&nbsp; &nbsp; &nbsp; &nbsp;MooseX::Types::TypeDecorator::AUTOLOAD('MooseX::Types::TypeDecorator=HASH(0x4a<nobr>3<wbr></nobr> 1424)', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\l<br>ib/Moose/Meta/Attribute.pm line 743<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::Attribute::_coerce_and_verify('Moose::Meta::Attribute=HASH(0x4b46<nobr>7<wbr></nobr> fc)', 'Madre::Sync::Schema', 'Madre::Sync::Model::padreDB=HASH(0x4db<br>7c64)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Attribute.pm line 398<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::Attribute::initialize_instance_slot('Moose::Meta::Attribute=HASH(<nobr>0<wbr></nobr> x4b467fc)', 'Moose::Meta::Instance=HASH(0x4db7ed4)', 'Madre::Sync::M<br>odel::padreDB=HASH(0x4db7c64)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Class.pm line 567<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Class::_construct_instance('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/C<br>lass.pm line 540<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Class.pm<br>line 256<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Object.pm lin<br>e 25<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Object::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at generated method (unknown origin) line 4<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Model::DBIC::Schema::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at C:\strawberry\perl\vendor\lib/MooseX/<br>Traits/Pluggable.pm line 131<br>#&nbsp; &nbsp; &nbsp; &nbsp;MooseX::Traits::Pluggable::new_with_traits('Madre::Sync::Model::padreDB', 'Madre::Sync') called at C:\strawberry\perl\vendor\lib/CatalystX/Componen<br>t/Traits.pm line 146<br>#&nbsp; &nbsp; &nbsp; &nbsp;CatalystX::Component::Traits::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Cl<br>ass/MOP/Method/Wrapped.pm line 48<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/<nobr>M<wbr></nobr> ethod/Wrapped.pm:49]('Madre::Sync::Model::padreDB', 'Madre::Sync', '<br>HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 89<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Model::DBIC::Schema::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/C<br>atalyst.pm line 2502<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2502<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::setup_component('Madre::Sync', 'Madre::Sync::Model::padreDB') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2416<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 54<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/<nobr>M<wbr></nobr> ethod/Wrapped.pm:64]('Madre::Sync') called at C:\strawberry\perl\ven<br>dor\lib/Class/MOP/Method/Wrapped.pm line 89<br>#&nbsp; &nbsp; &nbsp; &nbsp;Madre::Sync::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 1142<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::setup('Madre::Sync') called at blib\lib/Madre/Sync.pm line 62<br>#&nbsp; &nbsp; &nbsp; &nbsp;require Madre/Sync.pm called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 114<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP.pm:118]() called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 74<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 67<br>#&nbsp; &nbsp; &nbsp; &nbsp;Try::Tiny::try('CODE(0x36d759c)', 'Try::Tiny::Catch=REF(0x33a9584)') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 125<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_first_existing_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 24<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Test::__ANON__[C:\strawberry\perl\vendor\lib/Catalyst/Test.pm:93]('C<nobr>a<wbr></nobr> talyst::Test', 'all', 'HASH(0x36d768c)', 'HASH(0x25de3a4)') called a<br>t C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 493<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::_expand_group('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d4994)', 'HASH(0x25de3a4)', 'HASH(0x36d755c)', 'HASH(0x25de334)') call<br>ed at C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 424<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::_expand_groups('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d723c)', 'HASH(0x25de3a4)') called at C:\strawberry\perl\vendor\lib/S<br>ub/Exporter.pm line 742<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::__ANON__[C:\strawberry\perl\vendor\lib/Sub/Exporter.pm:756]('Ca<nobr>t<wbr></nobr> alyst::Test', '-all', 'HASH(0x36cc8d4)') called at C:\strawberry\per<br>l\vendor\lib/Catalyst/Test.pm line 112<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Test::import('Catalyst::Test', 'Madre::Sync') called at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2<br>#&nbsp; &nbsp; &nbsp; &nbsp;main::BEGIN() called at blib\lib/Madre/Sync.pm line 0<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at blib\lib/Madre/Sync.pm line 0<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval 'package main;<br># use Catalyst::Test @{$args[0]};<br># 1;<br>#<br>#<nobr> <wbr></nobr>;' called at C:/strawberry/perl/lib/Test/More.pm line 858<br>#&nbsp; &nbsp; &nbsp; &nbsp;Test::More::_eval('package main;\x{a}use Catalyst::Test @{$args[0]};\x{a}1;\x{a}', 'ARRAY(0x2308474)') called at C:/strawberry/perl/lib/Test/More.p<br>m line 833<br>#&nbsp; &nbsp; &nbsp; &nbsp;Test::More::use_ok('Catalyst::Test', 'Madre::Sync') called at t\01app.t line 7<br>#&nbsp; at C:\strawberry\perl\vendor\lib/MooseX/Types/TypeDecorator.pm line 208<br>#&nbsp; &nbsp; &nbsp; &nbsp;MooseX::Types::TypeDecorator::AUTOLOAD('MooseX::Types::TypeDecorator=HASH(0x4a<nobr>3<wbr></nobr> 1424)', 'Madre::Sync::Schema') called at C:\strawberry\perl\vendor\l<br>ib/Moose/Meta/Attribute.pm line 743<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::Attribute::_coerce_and_verify('Moose::Meta::Attribute=HASH(0x4b46<nobr>7<wbr></nobr> fc)', 'Madre::Sync::Schema', 'Madre::Sync::Model::padreDB=HASH(0x4db<br>7c64)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Attribute.pm line 398<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::Attribute::initialize_instance_slot('Moose::Meta::Attribute=HASH(<nobr>0<wbr></nobr> x4b467fc)', 'Moose::Meta::Instance=HASH(0x4db7ed4)', 'Madre::Sync::M<br>odel::padreDB=HASH(0x4db7c64)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Class.pm line 567<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Class::_construct_instance('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Class/MOP/C<br>lass.pm line 540<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Meta/Class.pm<br>line 256<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Meta::Class::new_object('Moose::Meta::Class=HASH(0x4942ffc)', 'HASH(0x4db53ac)') called at C:\strawberry\perl\vendor\lib/Moose/Object.pm lin<br>e 25<br>#&nbsp; &nbsp; &nbsp; &nbsp;Moose::Object::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at generated method (unknown origin) line 4<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Model::DBIC::Schema::new('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4b404ec)') called at C:\strawberry\perl\vendor\lib/MooseX/<br>Traits/Pluggable.pm line 131<br>#&nbsp; &nbsp; &nbsp; &nbsp;MooseX::Traits::Pluggable::new_with_traits('Madre::Sync::Model::padreDB', 'Madre::Sync') called at C:\strawberry\perl\vendor\lib/CatalystX/Componen<br>t/Traits.pm line 146<br>#&nbsp; &nbsp; &nbsp; &nbsp;CatalystX::Component::Traits::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Cl<br>ass/MOP/Method/Wrapped.pm line 48<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/<nobr>M<wbr></nobr> ethod/Wrapped.pm:49]('Madre::Sync::Model::padreDB', 'Madre::Sync', '<br>HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 89<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Model::DBIC::Schema::COMPONENT('Madre::Sync::Model::padreDB', 'Madre::Sync', 'HASH(0x4c6b93c)') called at C:\strawberry\perl\vendor\lib/C<br>atalyst.pm line 2502<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2502<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::setup_component('Madre::Sync', 'Madre::Sync::Model::padreDB') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 2416<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP/Method/Wrapped.pm line 54<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::Method::Wrapped::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP/<nobr>M<wbr></nobr> ethod/Wrapped.pm:64]('Madre::Sync') called at C:\strawberry\perl\ven<br>dor\lib/Class/MOP/Method/Wrapped.pm line 89<br>#&nbsp; &nbsp; &nbsp; &nbsp;Madre::Sync::setup_components('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst.pm line 1142<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::setup('Madre::Sync') called at blib\lib/Madre/Sync.pm line 62<br>#&nbsp; &nbsp; &nbsp; &nbsp;require Madre/Sync.pm called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 114<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP.pm:118]() called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 74<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 67<br>#&nbsp; &nbsp; &nbsp; &nbsp;Try::Tiny::try('CODE(0x36d759c)', 'Try::Tiny::Catch=REF(0x33a9584)') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 125<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_first_existing_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 24<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Test::__ANON__[C:\strawberry\perl\vendor\lib/Catalyst/Test.pm:93]('C<nobr>a<wbr></nobr> talyst::Test', 'all', 'HASH(0x36d768c)', 'HASH(0x25de3a4)') called a<br>t C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 493<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::_expand_group('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d4994)', 'HASH(0x25de3a4)', 'HASH(0x36d755c)', 'HASH(0x25de334)') call<br>ed at C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 424<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::_expand_groups('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d723c)', 'HASH(0x25de3a4)') called at C:\strawberry\perl\vendor\lib/S<br>ub/Exporter.pm line 742<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::__ANON__[C:\strawberry\perl\vendor\lib/Sub/Exporter.pm:756]('Ca<nobr>t<wbr></nobr> alyst::Test', '-all', 'HASH(0x36cc8d4)') called at C:\strawberry\per<br>l\vendor\lib/Catalyst/Test.pm line 112<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Test::import('Catalyst::Test', 'Madre::Sync') called at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2<br>#&nbsp; &nbsp; &nbsp; &nbsp;main::BEGIN() called at blib\lib/Madre/Sync.pm line 0<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at blib\lib/Madre/Sync.pm line 0<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval 'package main;<br># use Catalyst::Test @{$args[0]};<br># 1;<br>#<br>#<nobr> <wbr></nobr>;' called at C:/strawberry/perl/lib/Test/More.pm line 858<br>#&nbsp; &nbsp; &nbsp; &nbsp;Test::More::_eval('package main;\x{a}use Catalyst::Test @{$args[0]};\x{a}1;\x{a}', 'ARRAY(0x2308474)') called at C:/strawberry/perl/lib/Test/More.p<br>m line 833<br>#&nbsp; &nbsp; &nbsp; &nbsp;Test::More::use_ok('Catalyst::Test', 'Madre::Sync') called at t\01app.t line 7"Compilation failed in require at C:\strawberry\perl\vendor\lib/Class<br>/MOP.pm line 114.<br>#&nbsp; at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 121<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::__ANON__[C:\strawberry\perl\vendor\lib/Class/MOP.pm:125]('Couldn\'<nobr>t<wbr></nobr> instantiate component "Madre::Sync::Model::padreDB"...') called at<br>C:\strawberry\perl\vendor\lib/Try/Tiny.pm line 98<br>#&nbsp; &nbsp; &nbsp; &nbsp;Try::Tiny::try('CODE(0x36d759c)', 'Try::Tiny::Catch=REF(0x33a9584)') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 125<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_first_existing_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Class/MOP.pm line 137<br>#&nbsp; &nbsp; &nbsp; &nbsp;Class::MOP::load_class('Madre::Sync') called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 24<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Test::__ANON__[C:\strawberry\perl\vendor\lib/Catalyst/Test.pm:93]('C<nobr>a<wbr></nobr> talyst::Test', 'all', 'HASH(0x36d768c)', 'HASH(0x25de3a4)') called a<br>t C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 493<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::_expand_group('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d4994)', 'HASH(0x25de3a4)', 'HASH(0x36d755c)', 'HASH(0x25de334)') call<br>ed at C:\strawberry\perl\vendor\lib/Sub/Exporter.pm line 424<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::_expand_groups('Catalyst::Test', 'HASH(0x36d4ce4)', 'ARRAY(0x36d723c)', 'HASH(0x25de3a4)') called at C:\strawberry\perl\vendor\lib/S<br>ub/Exporter.pm line 742<br>#&nbsp; &nbsp; &nbsp; &nbsp;Sub::Exporter::__ANON__[C:\strawberry\perl\vendor\lib/Sub/Exporter.pm:756]('Ca<nobr>t<wbr></nobr> alyst::Test', '-all', 'HASH(0x36cc8d4)') called at C:\strawberry\per<br>l\vendor\lib/Catalyst/Test.pm line 112<br>#&nbsp; &nbsp; &nbsp; &nbsp;Catalyst::Test::import('Catalyst::Test', 'Madre::Sync') called at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2<br>#&nbsp; &nbsp; &nbsp; &nbsp;main::BEGIN() called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 2<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval {...} called at C:\strawberry\perl\vendor\lib/Catalyst/Test.pm line 2<br>#&nbsp; &nbsp; &nbsp; &nbsp;eval 'package main;<br># use Catalyst::Test @{$args[0]};<br># 1;<br>#<br>#<nobr> <wbr></nobr>;' called at C:/strawberry/perl/lib/Test/More.pm line 858<br>#&nbsp; &nbsp; &nbsp; &nbsp;Test::More::_eval('package main;\x{a}use Catalyst::Test @{$args[0]};\x{a}1;\x{a}', 'ARRAY(0x2308474)') called at C:/strawberry/perl/lib/Test/More.p<br>m line 833<br>#&nbsp; &nbsp; &nbsp; &nbsp;Test::More::use_ok('Catalyst::Test', 'Madre::Sync') called at t\01app.t line 7<br># BEGIN failed--compilation aborted at (eval 11)[C:/strawberry/perl/lib/Test/More.pm:858] line 2.</tt></p></div> </blockquote> Alias 2010-07-29T13:23:44+00:00 journal Strawberry Perl install rolled back http://use.perl.org/~jdavidb/journal/40462?from=rss <p>Strawberry Perl 5.12.0 was almost completely installed when suddenly it flashed some message I didn't see into the install wizard and the progress bars started moving backward! I have never seen anything like it. I realized the progress bar caption had been changed to simply "Rolling Back Action" and watched as at least three anonymous "actions" were rolled back, progress bar by progress bar. Then the install wizard simply told me "Strawberry Perl Setup Wizard ended prematurely Strawberry Perl Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard."</p><p>I wish it would tell me what the error was so I might have some hope of correcting it.</p> jdavidb 2010-07-26T20:34:33+00:00 journal For people running Perl conferences http://use.perl.org/~Alias/journal/40461?from=rss <p>Leo Lapworth comments in <a href="http://blogs.perl.org/users/leo_lapworth/2010/07/for-speakers-at-perl-conferences.html">"For speakers at Perl conferences"</a> that you should record your own talks at conferences, because organisers cannot be trusted to release the videos they take of you.</p><p>I wholeheartedly agree. I've spoken at numerous conferences, including several large ones, and only in about 10-20% of cases have the videos of me EVER appeared.</p><p>I'm amazed that conference organisers can put in so much effort into recording (dozens of tapes, multiple cameras, multiple operators) and then never produce anything as a result.</p><p>The only time I'm aware of that a full talk of mine has appeared online was at a Linux.conf.au, who had a dedicated video team of eight people.</p><p>Where is all this footage, and why does it never get processed? Why even bother recording it? If you don't have time, send me the raw tape of my own talk and I will do it myself if needed.</p><p>YAPC::NA? You listening?</p> Alias 2010-07-25T12:55:04+00:00 journal A reminder - Padre Second Birthday Hackathon this weekend http://use.perl.org/~Alias/journal/40460?from=rss <p>This is just a quick reminder that this weekend is the Padre's second birthday party and hackathon.</p><p>If you are a Padre user, please drop in and say hello to the team. We'd love to hear how you are using Padre and where your main needs are for the next year.</p><p>If you are interested in trying out Padre for the first time, or trying your hand at improving it for the first time, it's a great time to get started because we'll have plenty of people around to provide guidance and advice.</p><p>Some of the plans for this weekend are to bring all the plugins up to date with the latest versions of the plugin API, to start the merge of the ConfigSync branch, and if we can, to start on the Madre server that will serve as the ConfigSync and Telemetry server for Padre.</p><p>I look forward to seeing you there!</p> Alias 2010-07-23T03:53:28+00:00 journal Profiling your website while live on a production cluster http://use.perl.org/~Alias/journal/40457?from=rss <p>As I mentioned in my last post, by day I wrangle a large web application that occasionally verges on being too complex to for mere humans to understand.</p><p>Curiously, because it is private and the income rate is high (we probably average something like $5 in gross turnover per page view) we don't have to deal with a lot of servers to deliver it, by internet standards anyway.</p><p>But the application is still way too big to profile easily by normal methods, and certainly on production it's way too heavy, even if we applied targeted profiling using something like <a href="http://search.cpan.org/perldoc?Aspect::Library::NYTProf">Aspect::Library::NYTProf</a>.</p><p>Between the web servers, transaction server, database, search engine and cache server, we are probably only dealing with 12 servers and 30 CPUs. Of course, these servers are all horribly expensive, because they are all server-virtualised, network-virtualised, doubly redundant (high-availability + disaster-recovery) and heavily monitored with high end support contracts.</p><p>One of our most sensitive issues is database load.</p><p>We have a ton of database tables (about 200) and lots of medium sized queries running across them. One of our main failure modes is that some deep change to code boosts the quantity of some significant query, which stresses the database enough to cause contention and lock-storms, leading to site failure.</p><p>Complicating things, big parts of some pages are embedded in other pages. So attributing load and lag to one part of the website, or to Oracle, is tricky and hard to benchmark in advance (although we do load test the main load paths to catch the worst cases).</p><p>For a long time, we've had a mechanism for zoned profiling the production site, so we can allocate wallclock costs to different general areas of the site.</p><p>But it is fragile and unreliable, requiring perfect maintenance and every developer to remember to write this kind of thing everywhere.</p><blockquote><div><p> <tt># Embed a foo widget in the current page<br>$perf-&gt;push_timing('foo');<br>foo($bar);<br>$perf-&gt;pop_timing;</tt></p></div> </blockquote><p>Since you don't know this profiling system exists unless you've seen it somewhere else in the code before, and it's hard to care about something that is orthogonal to the problem you are actuall solving, this mechanism has degraded over time. While we still get some pretty cacti graphs showing load breakdown, they are highly unreliable and you can never be entirely sure if the load attribution is correct.</p><p>This kind of performance monitoring as a "cross-cutting concern" is a textbook use case for Aspect-Oriented Programming, and so in our Christmas 2009 code freeze window I set about trying to rewrite the push/pop_timing profiler using <a href="http://search.cpan.org/perldoc?Aspect">Aspect.pm</a>.</p><p>Unfortunately, Aspect.pm turned out to be a bit too slow and naive for my needs. But after a 6 month delay to do a 90% rewrite of Aspect.pm, I now finally have something sophisticated enough (and fast enough) to meet my needs.</p><p>So today I'm releasing the shiny new <a href="http://search.cpan.org/perldoc?Aspect::Library::ZoneTimer">Aspect::Library::ZoneTimer</a>, which will serve as the main plank of our new production profiling system.</p><p>The idea behind ZoneTimer is to define each performance zone as a pointcut. The aspect will track the movement of your code across each zone boundaries and build a running total of the exclusive time spent in each performance zone.</p><p>When your program exits the top-most performance zone, the totals will be sent to a handler function.</p><p>A typical use of the ZoneTimer aspect looks something like this</p><blockquote><div><p> <tt>use Aspect;<br> &nbsp; <br>aspect ZoneTimer =&gt; (<br>&nbsp; &nbsp; zones =&gt; {<br>&nbsp; &nbsp; &nbsp; &nbsp; main&nbsp; &nbsp; &nbsp; =&gt; call 'MyProgram::main' &amp; highest,<br>&nbsp; &nbsp; &nbsp; &nbsp; search&nbsp; &nbsp; =&gt; call 'MyProgram::search',<br>&nbsp; &nbsp; &nbsp; &nbsp; widgets&nbsp; &nbsp;=&gt; call qr/^MyProgram::widget_.*/,<br>&nbsp; &nbsp; &nbsp; &nbsp; templates =&gt; call 'MyProgram::render',<br>&nbsp; &nbsp; &nbsp; &nbsp; dbi&nbsp; &nbsp; &nbsp; &nbsp;=&gt; call qr/^DB[DI]::.*?\b(?:prepare|execute|fetch.*)$/,<br>&nbsp; &nbsp; &nbsp; &nbsp; system&nbsp; &nbsp; =&gt; (<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; call qr/^IPC::System::Simple::(?:run|runx|capture)/<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; call 'IPC::Run3::run3'<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; call qr/^Capture::Tiny::(?:capture|tee).*/<br>&nbsp; &nbsp; &nbsp; &nbsp; )<br>&nbsp; &nbsp; },<br>&nbsp; &nbsp; handler =&gt; sub {<br>&nbsp; &nbsp; &nbsp; &nbsp; my $top&nbsp; &nbsp; &nbsp; &nbsp;= shift; # "main"<br>&nbsp; &nbsp; &nbsp; &nbsp; my $start&nbsp; &nbsp; &nbsp;= shift; # [ 1279763446, 796875 ]<br>&nbsp; &nbsp; &nbsp; &nbsp; my $stop&nbsp; &nbsp; &nbsp; = shift; # [ 1279763473, 163153 ]<br>&nbsp; &nbsp; &nbsp; &nbsp; my $exclusive = shift; # { main =&gt; 23123412, dbi =&gt; 3231231 }<br> &nbsp; <br>&nbsp; &nbsp; &nbsp; &nbsp; print "Profiling from zone $top\n";<br>&nbsp; &nbsp; &nbsp; &nbsp; print "Started recording at " . scalar(localtime $start) . "\n";<br>&nbsp; &nbsp; &nbsp; &nbsp; print "Stopped recording at " . scalar(localtime $stop)&nbsp; . "\n";<br>&nbsp; &nbsp; &nbsp; &nbsp; foreach my $zone ( sort keys %$exclusive ) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; print "Spent $exclusive-&gt;{$zone} microseconds in zone $zone\n";<br>&nbsp; &nbsp; &nbsp; &nbsp; }<br>&nbsp; &nbsp; },<br>);</tt></p></div> </blockquote><p>This example breaks out the cost of a typical small web application into a general zone, a special zone for the search page, and then splits the costs of generating widgets, rendering the HTML template, waiting for the database, and making calls to the underlying system.</p><p>Start and stop times are returned as a two element array exactly as returned by C, and the exclusive zone totals are returned as integer microseconds (all math is done in these integer microseconds to prevent floating point corruption).</p><p>The use of Aspect allows us to easily mix special cases via the pointcuts, such as the use of "highest" which makes sure that "main" only matches the first time it is seen, and any widget which that does a re-entry into main still has that cost attributed to the widget. We've also hooked into multiple system call modules to measure system call cost, because we know different modules our program consumes will use different methods for interacting with the system.</p><p>While the handler I've shown here will just print out a summary of the call, in our environment at work the profile report handler will format the exclusive times into a special log message and then send it via the super-quick and non-blocking <a href="http://search.cpan.org/perldoc?Log::Syslog::Fast">Log::Syslog::Fast</a> module to the UDP localhost syslog service, where it is mirrored to disk for debugging use, and then forwarded on to our main company-wide syslog server.</p><p>On our setup, we can then use an excellent commercial log analysis product called <a href="http://www.splunk.com/">Splunk</a> (limited free version also available if you want to try it out) to do our tracking and trending of the performance for the entire application across the entire cluster.</p><p>The nicest thing about the Aspect system is that it scales the performance cost and complexity risk directly to the complexity of the use case you are using it for.</p><p>If it turns out that the Aspect hooks are too intrusive and causing a performance drain, or accidentally causing some weird edge case behaviour, you can simply turn off that the Aspect and restart the servers and the performance penalty just vanishes.</p><p>Maintenance of the profiler zones is really easy, because they are all listed clearly in one place.</p><p>Depending on your use case, you could even define the performance zones in your website configuration, and then adjust the profiler zone boundaries directly on production (although I'm not sure I'd want to do that in our specific case, since we're fairly paranoid about untested code going into production).</p><p>This ZoneTimer is just the first of several Aspect-based tools I plan to release over the next few months. If you get a chance to try out any of these new toys, I'd love to hear feedback on how well they work for you.</p><p>In addition to the value of the ZoneTimer aspect itself, one other thing that some people might find of interest is just how little code it took to get this all working.</p><p>The entire Aspect::Library::ZoneTimer was implemented in about 80 lines of code, which you can see at <a href="http://cpansearch.perl.org/src/ADAMK/Aspect-Library-Timer-0.04/lib/Aspect/Library/ZoneTimer.pm">http://cpansearch.perl.org/src/ADAMK/Aspect-Library-Timer-0.04/lib/Aspect/Libra<nobr>r<wbr></nobr> y/ZoneTimer.pm</a></p><p>This is small enough that you could just clone the module and tweak it for your own use case, if you wanted to creat a new and tricky customised profiler.</p> Alias 2010-07-22T02:27:33+00:00 journal How we deploy massive Perl applications at work http://use.perl.org/~Alias/journal/40453?from=rss <p>Every now and then, we hear people talking about mechanisms for doing Perl in a commercial environment and how they deal with packaging and dependencies.</p><p>This is mine.</p><p>At Corporate Express, our main Perl application is a 250,000 line non-public monster of a website that has over 100,000 physical users and turns over about a billion dollars. It implements huge amounts of complex business functionality, and has layer upon layer of security and reliability functions in it because we supply to multinationals, governments and the military (only the stuff that doesn't blow up of course). Our<nobr> <wbr></nobr>.pm file count is around 750, and our test suite runs for about 4 hours (and is only around one third complete).</p><p>Lest you suspect that 200,000 lines is wasted in re-implementing stuff, the main Build.PL script has around 110 DIRECT dependencies, and somewhere in the 300-500 range of recursive dependencies. Loading the main codebase into memory takes around 150-200meg of RAM.</p><p>When I joined the team, the build system was horribly out of date. The application was stuck on an old version of RedHat due to go out of support, and as a Tier 1 application we are absolutely forbidden from using unsupported platform.</p><p>So I took on the task of upgrading both the operating system and the build system for the project. And it's a build system with a history.</p><p>Once upon a time, long ago, the project went through a period where the development team was exceptionally strong and high skilled. And so of course, they created a roll-your-own build system called "VBuild".</p><p>They built their own Perl, and along with it they also built their own Apache, mod_perl, and half a dozen other things needed by the project. This is similar to many suggestions I hear from high-skilled people today, that at a certain point it's better just to build your own Perl. VBuild this created in the pre-commercial Linux era, so it's not an entirely unreasonable decision for that time period.</p><p>Unfortunately, a few years later the quality of the team dropped off and VBuild turned into a maintenance nightmare because it required a high-skill person to maintain it.</p><p>At the time, the Tier 1 "Must be supported" policy was coming into effect, and after the problems with custom-compiling they decided to go with the completely opposite approach of using only vendor provided packages, in a system called "UnVBuild".</p><p>Since their platform of choice was RedHat, this had become troublesome even before I arrived. Worse, in the change from RHEL 4 to RHEL 5, some of the vendor packages for things like XSLT support were dropped entirely leaving us in a bind.</p><p>My first instinct was to return to the build everything approach, but the stories (and commit commentary) from that time period reinforced the idea that complete custom build was a bad idea. Office supplies is hardly a sexy industry, and the ability to entice good developers into it is a quite legitimate risk.</p><p>So in the end, I went with an approach we ended up nicknaming "HalfBuild". The concept behind it is "Vendor where possible, build where needed".</p><p>We use a fairly reasonable chunk of vendor packages under this model. Perl itself, the Oracle client, XML::LibXML and a variety of other things where our version needs are modest and RHEL5 contains it. We also use a ton of C libraries from RHEL5 that are consumed by the CPAN modules, like all the image libraries needed by Imager, some PDF and Postscript libraries, and so on.</p><p>One RPM "platform-deps" meta-package defines the full list of these system dependencies, and that RPM is maintained exclusively by server operations so that we as developers are cryptographically unable to add major non-Perl dependencies without consulting them first.</p><p>On top of this is one enormous "platform-cpan" RPM package built by the dev team that contains every single CPAN dependency needed by all of our Perl projects.</p><p>This package lives in its own home at<nobr> <wbr></nobr>/opt/cpan and is built using a process rather similar to the core parts of Strawberry Perl. With PREFIX pointing into<nobr> <wbr></nobr>/opt/cpan, we first build a hand-crafted list of distribution tarballs to upgrade RHEL5 to a modern install of CPAN.pm (without overwriting any normal system files).</p><p>We then boot up the CPAN client from<nobr> <wbr></nobr>/opt/cpan, and tell it to install all the rest of the dependencies from a private internal CPAN mirror which is rsynced by hand specifically for each new CPAN build. This ensures that the build process is deterministic, and that we can fix bugs in the build process if we need to without being forced to upgrade the modules themselves).</p><p>The CPAN client grinds away installing for an hour, and then we're left with our "CPAN Layer", which we can include in our application with some simple changes to @INC at the beginning of our bootstrapping module.</p><p>The<nobr> <wbr></nobr>/opt/cpan directory for our project currently weighs in at about 110meg and contains 2,335<nobr> <wbr></nobr>.pm files.</p><p>Updating<nobr> <wbr></nobr>/opt/cpan is still something of an exercise even under this model because of potential upgrade problems (Moose forbidding +attributes in roles hit us on our most recent upgrade) but the whole process is fully automated from end to end, and can be maintained by a medium-skill Perl hacker, rather than needing an uberhacker.</p><p>Over the last 2 years, we've upgraded it around once every 6 months and usually because we needed to add five or ten more dependencies. We tend to add these new dependencies as early as we can, when work that needs them is confirmed but unscheduled.</p><p>We also resort to the occasional hand-copied or inlined pure-Perl<nobr> <wbr></nobr>.pm file in emergencies, but this is temporary and we only do so about once a year when caught unprepared (most recently Text::Unidecode for some "emergency ascii'fication" of data where Unicode had accidentally slipped in).</p><p>While not ideal, we've been quite happy with the<nobr> <wbr></nobr>/opt/cpan approach so far.</p><p>It means we only have to maintain 5 RPM packages rather than 500, and updating it takes one or two man-days per 6 months, if there aren't any API changes in the upgrade.</p><p>And most importantly it provides us with much better bus sensitivity, which is hugely important in applications with working lives measured in decades.</p> Alias 2010-07-20T02:25:21+00:00 journal Hiveminder: personal RT, for free http://use.perl.org/~jdavidb/journal/40452?from=rss <p>You mean someone will provide RT for me to use for free on the web? And they've built an awesome AJAX-y frontend for it? And they allow me to tag tasks and they encourage me to keep my work todo list and as many personal todo lists as I want in here? And they give me awesome search utilities for figuring this out and keeping it organized?</p><p>It's almost like <a href="http://hiveminder.com/">a dream come true</a>.</p> jdavidb 2010-07-19T16:58:36+00:00 journal Padre Second Birthday Party 24th-25th of July http://use.perl.org/~Alias/journal/40441?from=rss <p>2 years ago this month, Gabor did the first Padre release.</p><p>The last 12 months has seen Padre mature from a high-end text editor to a low-end refactoring IDE. We've stolen a number of features from Ultraedit, Komodo and EPIC, and we've invented new features all of our own, making Padre a very fluid and natural place to write Perl in.</p><p>We've added support for Perl 6, Template Toolkit, remote file support, more languages, syntax checking, an interactive debugger, a regex editor, and our first half a dozen refactoring tools.</p><p>We've also greatly solidified the code. Window integration is now totally solid, we've added a resource locking API, a new filesystem API, a new search API, a new display API, rewritten the threading and background Task subsystem, heavily overhauled the Plugin Manager API and GUI, and added Advanced Preferences and the ability for advanced users to selective disable various Padre bloat/features.</p><p>The last couple of months have also seen great improvements in Padre's hackability as well. The new Task 2.0 API lets people write background logic and consume multiple cores of CPU without having to know how threading works, and the new wxFormBuilder plugin lets you build GUI code without having to know Wx (one of the biggest barriers to contributing to Padre).</p><p>On the weekend of the 24th-25th of July we would like to invite all Padre developers, users, friends and well-wishers to join us for Padre's Second Birthday Party and Hackathon in the Padre IRC channel at <a href="irc:ircperlorgpadre">irc://irc.perl.org/#padre</a> or via the <a href="http://widget.mibbit.com/?server=irc.perl.org&amp;channel=%23padre">Mibbit Web Client</a>.</p><p>If you've always been curious about, or interested in hacking on, Padre we'll have a number of developers in channel to help you out.</p><p>Personally, I plan to debut the first public release of Padre::Plugin::FormBuilder, and to start ripping out all Padre's older fixed-size dialogs and replacing them with new shiny model-generated sizer-based dialogs that will work much better across all three operating systems.</p><p>If you'd like to help out in this effort, I'll be in channel most of the day on both days (Sydney timezone).</p><p>I look forward to seeing you all there.</p> Alias 2010-07-10T16:50:21+00:00 journal Yahoo provides (awesome) alternative Geocoder to Google's http://use.perl.org/~Alias/journal/40436?from=rss <p>As far as I'm concerned, there are three critical things you need in a Geocoder service.</p><p>1. Global Coverage</p><p>Because when it doesn't have global coverage, it's basically means "America-only" and thus pointless for most of the world.</p><p>2. Multiple Matching</p><p>For ordinary humans, there's massive power in being able to just search for "1 Oxford Street" without listing any more details. From there, if it is a country-specific application you just change it to "1 Oxford Street, Australia" behind the scenes.</p><p>That results in a list of possible locations.</p><p>You show the results for the first result, and then a list of "Did you mean:" links for the other results. This lets the application do what people mean most of the time, while making it trivial to recover if it isn't accurate enough.</p><p>You can see the effect I'm talking about by running the example query here...</p><p><a href="http://geo2gov.com.au/">http://geo2gov.com.au/</a></p><p>3. No usage limitations</p><p>Google Maps Geocoder can only be used with Google Maps. Fail.</p><p>I'm willing to accept a volume limitation like "You have to pay after the first 50,000 requests" but I can't accept a usage limitation.</p><p>I'm happy to report that Yahoo's new PlaceFinder service is the first free Geocoder that meets all these primary criteria.</p><p>It's global in scope, lets you control the list of results with paging, and doesn't limit the usage to any particular domain.</p><p>Now all we need is an Geo::Coder plugin for it.</p><p>Please write one for me Lazyweb<nobr> <wbr></nobr>:)</p> Alias 2010-07-06T04:10:06+00:00 journal Announcing CPAN Testers 2.0 http://use.perl.org/~barbie/journal/40435?from=rss <p>After 6 months of development work, following 2 years worth of design and preparation, CPAN Testers 2.0 is finally live.</p><p>With the rapid growth in CPAN Testers environments and testers over the past few years, the previous method of posting reports to a mailing list had reached a point where the scalability was no longer viable. This was recognised several years ago and discussions for a new system had already begun, with the view that reports should be submitted via HTTP.</p><p>At the Oslo QA Hackathon in 2008, David Golden and Ricardo Signes devised the Metabase, with the design work continuing at the Birmingham QA Hackathon in 2009, where David and Ricardo were able to bring others into the thought process to work through potential issues and begin initial coding. A number of releases to CPAN and Github followed, with more people taking an interest in the project.</p><p>The Metabase itself is a database framework and web API to store and search opinions from anyone about anything. In the terminology of Metabase, Users store Facts about Resources. In the Metabase world, each CPAN tester is a User. The Resource is a CPAN distribution. The Fact is the test report. Today that&#8217;s just the text of the email message, but in the future it will be structured data. The Metabase specifies data storage capabilities, but the actual database storage is pluggable, from flat files to relational databases to cloud services, which gives CPAN Testers more flexibility to evolve or scale over time.</p><p>Meanwhile the CPAN Testers community was also attracting more and more interest from people wanting to be testers themselves. As a consequence the volume of reports submitted increased each month, to the point that the perl.org mail server was struggling to deal with all the mailing lists it hosted. The cpan-testers mailing list was submitting more posts in one day than any other list submitted in a month (in a year in some cases). Robert and Ask, very reasonably, asked if the testers could throttle their submissions down to 5k report posts a day, and set a deadline of 1st March 2010 to switch off the mailing list.</p><p>David Golden quickly took on the task to envisage a project plan, and work began in earnest in December 2009. With less than 3 months to the cut-off date, there was a lot of work to do. David concentrated on the Metabase, with Barbie working on ensuring that the current cpanstats database and related websites could move to the Metabase style of reports. Despite a lot of hard work from a lot of people, we unfortunately missed the 1st March deadline. Having throttled report submissions to a more manageable level, and although not complete, the target for HTTP submissions was in sight, Robert and Ask were very understanding and agreed to keep us going a little while longer.</p><p>Throughout March and April a small group of beta testers were asked to fire their submissions at the new system. It ironed out many wrinkles and resulted in a better understanding of what we wanted to achieve. The first attempts at retrieving the reports from the Metabase into the cpanstats database began in April, and again highlighted further wrinkles that needed to be addressed. After a month of hard testing and refinement, we finally had working code that went from report submission by a tester, storage into the Metabase, retrieval into the cpanstats database and finally presentation on the CPAN Testers family of websites.</p><p>During June the process was silently switched from testing to live, allowing reports to be fed through into the live websites. Due to the ease with which the new style reporting fit into the existing system, the switch largely went unnoticed by the CPAN testers community as well as the Perl community. A considerable success.</p><p>The CPAN Testers eco-system is now considerably larger than those early days of simply submitting handwritten reports by email to a mailing list, and the work to get here has featured a cast of thousands. Specifically for CPAN Testers 2.0, the following people have contributed code, ideas and effort to the project over the past six months:</p><ul> <li>Andreas K&ouml;nig</li><li>Apocalypse</li><li>Ask Bj&oslash;rn Hansen</li><li>Barbie</li><li>Chris Williams</li><li>Dan Collins</li><li>David Cantrell</li><li>David Golden</li><li>Florian Ragwitz</li><li>H.Merijn Brand</li><li>Jon Allen</li><li>Lars D&#618;&#7431;&#7428;&#7435;&#7439;&#7457; &#36842;&#25289;&#26031;</li><li>L&eacute;on Brocard</li><li>MW487</li><li>Nigel Horne</li><li>Ricardo Signes</li><li>Richard Dawe</li><li>Robert Spier</li><li>Serguei Trouchelle</li><li>Shlomi Fish</li><li>Slaven Rezi&#263;</li></ul><p>Barbie and David would like to thank everyone for their involvement. Without these guys CPAN Testers 2.0 would not have been possible. Thanks to everyone, we can now look forward to another 10 years and more of CPAN Testers.</p><p> <a href="http://www.cpantesters.org/">CPAN Testers</a> now holds over 7.5 million test reports covering nearly 11 years worth of testing Perl distributions. There have been over 1,000 testers in that time, and every single one has helped the CPAN Testers project to be the largest single community supported testing system of any programming language. For a full list of everyone who has contributed, visit the <a href="http://stats.cpantesters.org/testers.html">CPAN Testers Leaderboard</a>. A huge thank you to everyone.</p><p>With the Metabase now online and live, we can now announce an absolute deadline to close the mailing list. This is currently set as 31st August 2010. After this date all submissions via email will be rejected, and testers will be encouraged to upgrade their testing tools to take advantage of the new HTTP submission system. Many of the high volume testers have already moved to the new system, and we expect nearly everyone else to move in the next month. We will be tailing the SMTP submissions to catch those who haven't switched, such as some of the more infrequent testers, and warn them of the deadline.</p><p>More work is planned for CPAN Testers, from further validation and administration of reports, to providing more functionality for alternative analysis and search capabilities. Please check the <a href="http://blog.cpantesters.org/">CPAN Testers Blog</a> for our regular updates.</p><p>If you'd like to become a CPAN Tester, please check the <a href="http://wiki.cpantesters.org/">CPAN Testers Wiki</a> for details about setting up a smoke testing environment, and join the <a href="http://lists.perl.org/list/cpan-testers-discuss.html">cpan-testers-discuss mailing list</a> where many of the key members of the project can offer help and advice.</p><p>You can find out more about CPAN Testers at two forthcoming conferences. David Golden will be presenting <a href="http://www.oscon.com/oscon2010/public/schedule/detail/13759">"Free QA! What FOSS can Learn from CPAN Testers"</a> at OSCON and Barbie will be presenting <a href="http://conferences.yapceurope.org/ye2010/talk/2891">"CPAN Testers 2.0 : I love it when a plan comes together"</a> at YAPC::Europe.</p><p>CPAN Testers is sponsored by Birmingham Perl Mongers, and supported by the Perl community.</p><p>You can now <a href="http://blog.cpantesters.org/press-release-ct20-20100705.pdf">download the full and complete Press Release</a> from the CPAN Testers Blog. If you have access to further IT news reporting services, please feel free to submit the Press Release to them. Please let us know if you are successful it getting it published.</p><p>Cross-posted from the <a href="http://blog.cpantesters.org/diary/83">CPAN Testers Blog</a> </p> barbie 2010-07-05T09:50:22+00:00 journal Perl 6 Design Minutes for 30 June 2010 http://use.perl.org/~chromatic/journal/40433?from=rss <p>The Perl 6 design team met by phone on 30 June 2010. Allison, Patrick, and chromatic attended.</p><p> <strong>Allison:</strong> </p><ul> <li>working on Parrot packages for Debian experimental</li><li>seems like a good idea to do that before the 2.6 supported release</li><li>there was also a request for Rakudo packages</li><li>not sure if I'm the best person to do it</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>I'm sure we should package Rakudo Star</li></ul><p> <strong>Allison:</strong> </p><ul> <li>Debian had a packager for those, but I haven't looked at the packages</li><li>this'd be an early run of what we'll do with Rakudo Star</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>we're not quite ready for packaging that yet</li><li>maybe a couple of weeks</li><li>finished the <code>List</code> and <code>Iterator</code> types for the #30 release</li><li>adjusted Rakudo's <code>Associative</code> and <code>Positional</code> roles</li><li>much cleaner implementation now</li><li>that'll require a few small spec changes</li><li>redid Rakudo's container types</li><li>more robust</li><li>preparing for autovivification of hashes and arrays</li><li>expect to finish those in the next couple of days</li><li>there was no container model previously; the code was consequently crufty</li><li>lots of cleanup of incorrect assumptions</li><li>Rakudo lists are now properly lazy</li><li>comment syntax fixed</li><li>ROADMAP updated</li><li>fixed the meaning of <code>Nil</code>; it's defined, not undefined</li><li>added the sink prefix (?)</li><li>fixed setting of <code>$!</code> </li><li>started fixing bugs and closing tickets on Monday, did 15 or 20</li><li>mostly already fixed in the previous couple of weeks</li><li>looking at the implementation of the series operator</li><li>spec is self-contradictory or ambiguous or both</li><li>waiting for Larry's clarification</li><li>fixed a bug in <code>$*ARGFILES</code> </li><li>had a nice contribution of that implementation last week</li><li>that behavior works on any set of files, not just those on the command line</li><li>working on autoviv</li><li>have some regex backtracking bugs to fix</li><li>will work on closures after that</li><li>put together three new YAPC presentations</li><li>the Rakudo Star presentation will become a video cast or a blog post or both</li></ul><p> <strong>c:</strong> </p><ul> <li>worked on a slew of Parrot optimizations for Rakudo</li><li>have a few more to go</li><li>might have to create a Rakudo branch temporarily</li><li>will try to help merge the new GC</li><li>working on a metamodel for Parrot objects, informed by Perl 6 and Moose</li></ul> chromatic 2010-07-03T08:13:30+00:00 journal The next challenge for Perl on Windows (et al) http://use.perl.org/~Alias/journal/40424?from=rss <p>Even at this early stage, before any actual installers have appeared, things are looking pretty good for Strawberry Professional Alpha 2.</p><p>Padre is starting to firm up as a usable editor, Frozen Bubble works quite well and is completely playable, and I think my wxFormBuilder work is coming along nicely (which bodes well for quickly and easily creating GUI apps in some Alpha 3...)</p><p>My biggest remaining concern at the moment though, is also one of the smallest and seemingly trivial issues.</p><p>Although we can much more easily build and install large, rich and good looking desktop applications there is still no way to launch these applications without resorting to the command line.</p><p>Any iconography that are filled into the start menu in Strawberry Professional will do so because Curtis has put them there himself.</p><p>A Perl installation, via the %Config information, lets an installer know where to put libraries, binaries, documentation etc. Shared files in the File::ShareDir model are really just a hack, putting them in an agreed location within lib.</p><p>File::HomeDir isn't any use to us either for this. It is designed to let programs deal with user-owned data at run-time, NOT with system integration at install time.</p><p>Without the ability to install programs in a way that desktop users can easily launch, our little nascent desktop revolution will never really be able to get up to speed.</p><p>Having a post-install step where you need to launch a Windows command line, and then run "padre --desktop" just to install a desktop icon is simply not good enough.</p><p>Likewise, having to run Frozen Bubble from the command line is silly as well.</p><p>So consider this a challenge to anyone out there that likes tackling tricky puzzles, to try and build a File::Launcher (or whatever you want to call it) that can locate install paths, and be integrated into module installers, so we can make proper use of the Start Menu, Desktop, Quick Launcher, and all the equivalent features on all three major desktop platforms (Windows, Mac, and FreeDesktop.org).</p><p>If you build it, Padre will use it.</p> Alias 2010-07-01T03:32:16+00:00 journal Modern Perl: The (Draft) Book http://use.perl.org/~chromatic/journal/40423?from=rss <p>This took longer than I expected, but <a href="http://www.modernperlbooks.com/mt/2010/06/modern-perl-the-book-the-draft.html">the draft of the Modern Perl book is available for review</a>. I'm especially interested in hearing from people who don't consider themselves expert Perl 5 programmers. The goal of the book is to explain how Perl 5 works (and how to write Perl 5 effectively) to help novices become adepts.</p> chromatic 2010-06-28T23:43:33+00:00 journal Perl 6 Design Minutes for 16 June 2010 http://use.perl.org/~chromatic/journal/40419?from=rss <p>The Perl 6 design team met by phone on 16 June 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>documented <code>TOP</code> (again), and explained how parsing is initiated and how it actually works</li><li>series operator (<code>...</code>) now picks a monotonic function when using single characters as endpoints</li><li>STD can now catch duplicates involving <code>proto</code>s as well as <code>only</code>s</li><li>STD no longer advises removal of parens on spaceless <code>sub()</code> declaration</li><li>mostly advised sorear and pmichaud</li><li>Stefan is finishing the boostrap of the STD parser</li><li>also working on adding a parallel NFA and DFA engine</li><li>no, he doesn't want to generate all the states in advance</li><li>it works faster lazily</li></ul><p> <strong>Allison:</strong> </p><ul> <li>working on chroot environments with something more secure than chroot</li><li>relevant to building Parrot packages</li><li>looking at some bugs for Will</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>Rakudo developers decided not to make extra special effort to make a June release of Rakudo Star</li><li>the calendar works against us</li><li>the new date for the release is July 29</li><li>we're I comfortable with hitting that target</li><li>we won't be happy with the results of moving heaven and earth to release in June</li><li>there are lots of advantages</li><li>one disadvantage is not having Rakudo Star at YAPC::NA</li><li>one big advantage is using the supported Parrot 2.6 release as the basis</li><li>I'll write a post outlining the plan in the next couple of days</li><li>otherwise working on lists and interators in Perl 6 and Rakudo</li><li>after deciding to make iterators immutable, Larry and I realized that solves many problems</li><li>everything works out as plain as day after that</li><li>very happy with that design</li><li>the incorrect assumptions of the old model were pervasive</li><li>replacing the old pieces is taking a while, which is no surprise</li><li>this approach feels right though</li><li>the new branch does things no previous version could do</li><li>slices work much better, for example</li><li>metaoperators work properly</li><li>map is lazy</li><li>slurpy arguments in lists are lazy by default</li><li>no weird binding or action at a distance problems</li><li>plenty of changes to <code>Associative</code> and <code>Positional</code> roles</li><li>those are now super clean and may be lazy</li><li>more features work</li><li>~30 failing tests (not test files, just tests) now, ~500 last night</li><li>most of the current failures are minor</li><li>will try to merge the branch before the release</li><li>replacing lots of ugly code with fewer lines of elegant code</li><li>Jonathan and others have worked on lots of other pieces</li><li>adding plenty of new features</li><li>looking forward to tomorrow's release</li></ul><p> <strong>c:</strong> </p><ul> <li>editing the Rakudo book</li><li>moving the Rakudo release date may let us have a printed book available about the same time</li><li>depends on how much there is left to write</li></ul> chromatic 2010-06-26T17:07:30+00:00 journal Perl 6 Design Minutes for 09 June 2010 http://use.perl.org/~chromatic/journal/40415?from=rss <p>The Perl 6 design team met by phone on 09 June 2010. Larry, Allison, Patrick, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>not much spec change this week</li><li>figured out a syntax for a regex block to return more than one cursor</li><li>based on <code>gather</code>/<code>take</code> </li><li>in STD hacking, continued to assist Stefan O'Rear in getting STD bootstrapped via viv</li><li>now that it's bootstrapped, we're refactoring things that make sense now</li><li>we're now starting to move bits of Cursor code from Perl 5 into Perl 6</li><li>refactoring the grammar for sanity of design</li><li>started upgrading STD to normal Perl 6 syntax where it previously catered to <code>gimme5</code>'s limitations</li><li>for example, switched STD's old<nobr> <wbr></nobr><code>.&lt;_from&gt;</code> and<nobr> <wbr></nobr><code>.&lt;_pos&gt;</code> hash lookups to using<nobr> <wbr></nobr><code>.from</code> and<nobr> <wbr></nobr><code>.pos</code> accessors</li><li>started the prep work for moving <code>EXPR</code> out of <code>STD</code> to make it generally available to any grammar wanting operator precedence</li><li>in STD parsing, made Perl 5 <code>$&lt;</code> detection have a longer token to avoid confusion with match variables</li><li>STD no longer attempts two-terms detection on <code>infix_circumfix_meta_operator</code> </li><li>STD now parses <code>&gt;&gt;R~&lt;&lt;</code> correctly, or at least dwimmily</li><li>STD doesn't complain about P5isms in <code>printf</code> formats like <code>"%{$count}s"</code> </li><li>STD was parsing<nobr> <wbr></nobr><code>/m</code> and<nobr> <wbr></nobr><code>/s</code> with the opposite semantics</li><li> <code>termish</code> now localizes <code>$*MULTINESS</code> in its scope so that inner declarations aren't accidentally multified</li><li>STD now carps about <code>package Foo;</code> as a Perl 5 construct</li></ul><p> <strong>Allison:</strong> </p><ul> <li>talked to Chris Shiflett, a PHP developer, on someone from the PHP community to sit on the Parrot board</li><li>will be in the US for a few weeks</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>working on list simplification</li><li>had a couple of breakthrough ideas on Monday</li><li>working on the implementation now</li><li>worked out inversion lists for character class matching in regexes</li><li>will make them faster, especially with long ranges of character classes</li><li>fixed a half-dozen tickets in RT</li><li>fixed Rakudo hash constructors</li><li>fixed an intermittent bug with colon-pair signatures</li><li>two possible parses exist in STD, but we removed an unneeded one in Rakudo</li><li>fixed a bug with Parrot's <code>exit</code> opcode</li><li>NQP and PAST needed an update not to cheat with PASM constants</li><li>I fixed that too</li><li>Vasily added multisub and multimethod support to NQP, that was a big plus</li><li>fixed the <code>**</code> quantifier in regexes to understand surrounding whitespace</li><li>regex engine tried to match beyond the end of a string, so I added guards for that</li><li>will work on lists furiously before the next release</li><li>I don't think it'll take long</li><li>closures are next, hope to have those in place by the weekend</li></ul><p> <strong>c:</strong> </p><ul> <li>released a new version of Pod::PseudoPod::LaTeX to support the various books in progress</li></ul> chromatic 2010-06-24T12:24:33+00:00 journal Perl 6 Design Minutes for 02 June 2010 http://use.perl.org/~chromatic/journal/40410?from=rss <p>The Perl 6 design team met by phone on 02 June 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li>mostly, I supported sorear in bootstrapping STD to use <code>viv</code> instead of <code>gimme5</code> </li><li>his stage 2 and stage 3 now output identical Perl 5 versions of STD</li><li>produces a huge amount of warnings</li><li>appears to require Perl 5.12 at the moment</li><li>working on both of those</li><li>S03 refines hyper dwimminess to be more like APL, with modular semantics</li><li>S02 refines <code>Blob</code>s to simply be immutable <code>Buf</code>s, with similar generic characteristics</li><li>S02 now describes native <code>blob</code> types</li><li>implemented post-declaration checks for <code>BEGIN</code> and <code>use</code>, since those can't wait for end of file</li><li>STD no longer loses existing bindings when we go to a sublanguage</li><li>STD now uses <code>$*GOAL</code> variable only as informative, never as a "stopper"</li><li>instead, we create a <code>&lt;stopper&gt;</code> rule for <code>$*GOAL</code> if necessary</li><li>can check for that only, instead of that or <code>$*GOAL</code> </li><li>answering lots of questions on how STD and <code>viv</code> work besides that</li></ul><p> <strong>Allison:</strong> </p><ul> <li>did a lot of research on graph color algorithms for register usage algorithms</li><li>will finish my finals on Monday</li></ul><p> <strong>Will:</strong> </p><ul> <li>trying to herd the discussion of dynop libraries</li><li>a recent branch to close an old ticket broke a lot of assumptions</li><li>some bugs have become more visible because of these changes</li><li>hope to get that cleaned up this week</li></ul><p> <strong>Allison:</strong> </p><ul> <li>I liked your suggestion of bringing back the <code>getstderr</code> and related opcodes</li></ul><p> <strong>Will:</strong> </p><ul> <li>trying to resurrect Partcl</li><li>stuck on a TT #389 closing issue</li><li>not sure how to fix that, the way things are now</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>working on the iterator and list design</li><li>brainstorming the implementation</li><li>will implement somethine one way or another this week</li><li>people keep implementing workarounds for the current system</li><li>they'll bite us eventually</li><li>Moritz and I worked on making the regex engine returning real Perl 6 objects</li><li>that mostly works</li><li>exposes some places where lists don't work exactly right</li><li>the workarounds there made me replan the list and iterator implementation</li><li>answered some questions online</li><li>Jonathan added a better backtrace algorithm for Rakudo</li><li>reports Perl 6 source lines instead of PIR lines</li><li>I'll review his code</li><li>think I can borrow it for NQP for all HLLs</li><li>Jonathan reports that it was a lot easier in NQP than PIR</li></ul><p> <strong>c:</strong> </p><ul> <li>trying to answer a few Parrot design questions</li><li>looking at the continuation of design from Perl 1 - 4 to Perl 5 and Perl 6</li><li>hope to have coding time soon</li></ul> chromatic 2010-06-22T01:12:29+00:00 journal Perl 6 Design Minutes for 26 May 2010 http://use.perl.org/~chromatic/journal/40408?from=rss <p>The Perl 6 design team met by phone on 26 May 2010. Larry, Allison, Patrick, Will, and chromatic attended.</p><p> <strong>Larry:</strong> </p><ul> <li><nobr> <wbr></nobr><code>:()</code> syntax is now always signature</li><li>we now use <code>foofix:[...]</code> as the general op form instead of <code>foofix:(...)</code> </li><li>refactored the sematics of<nobr> <wbr></nobr><code>:nth</code> and<nobr> <wbr></nobr><code>:x</code> </li><li><nobr> <wbr></nobr><code>:nth()</code> now only ever takes a monotonically increasing list</li><li>S03 now explains how "not-raising" works on <code>!=</code> and <code>ne</code> </li><li>it now basically matches the intuitions of an English speaker via HOP definition of negate metaop</li><li>STD sometimes didn't require semi between statements</li><li>statement modifiers are expression terminators but not valid statement terminators</li><li>an unexpected statement modifier word like <code>if</code> could terminate one statement and start another</li><li>fixed up backslashes in character classes to allow <code>\s</code> etc and reject <code>\u</code> etc</li><li>STD was accidentally using the same lexpad for different multis</li><li>Cursor now treats<nobr> <wbr></nobr><code>:()</code> on name extension as a signature always, never as a categorical</li><li>we shouldn't introduce the stopper for circumfix until we're in the circumfix, or we can't use the same char on both ends</li><li>placeholder messages error messages are now much more informative and correct</li><li>we now disallow use of placeholder after same variable has been used as a non-placeholder, even for an outer reference</li><li>renamed add_macro (which it doesn't) to add_categorical (which it does)</li><li>participating frequently in discussions on semantics both on irc and p6l</li><li>working closely with sorear++ as he brings viv closer to bootstrapping, yay!</li><li>soon can bootstrap past gimme5</li></ul><p> <strong>Allison:</strong> </p><ul> <li>worked on Pynie this week in my limited spare time</li><li>one goal is to generate the parser directly from the Python grammar</li><li>wrote a small, lightweight PEG parser which generates a match tree from the Python 3 grammar</li><li>can generate a lexer directly</li><li>right now it creates a parse tree</li><li>looks similar to the match nodes of NQP-rx</li><li>dumps out a tree to the PIR parser</li><li>working on PaFo elections for next year, but trying to delegate those</li><li>will have more time after June 7</li></ul><p> <strong>Will:</strong> </p><ul> <li>working on Perl 6 advent tests</li><li>many more people are doing more work than me</li><li>liasing with Rakudo folks for any important Parrot bugs before the Rakudo Star release</li><li>my current direction there is "don't break anything"</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>sorear added hash flattening to NQP</li><li>lots of work on closures in PAST and NQP</li><li>they properly clone</li><li>fixes some lexical problems</li><li>need to get that to work in Rakudo</li><li>that's tougher; Rakudo has to wrap Parrot subs</li><li>wrapper object needs cloning as well, along with its attributes</li><li>we'll add a new PAST node type to help</li><li>that node understands contexts</li><li>essentially a way to add void context optimizations to your AST</li><li>that solves many problems in Rakudo beyond closures</li><li>added a setting into NQP along with its test suite</li><li>not automatically loaded, but available</li><li>contains standard hash and array methods</li><li>Parrot's ops2c project uses those</li><li>other people can update and enhance that setting as necessary</li><li>NQP also has the ability to parse type names</li><li>NQP doesn't do anything with them yet</li><li>eventually they'll allow the use of multis</li><li>cleaning up some NQP bugs regarding lexicals and package storage of subs</li><li>Bruce Keeler enabled variable interpolations in regexes</li><li>working on some refactorings to simplify that approach</li><li>works in NQP and Rakudo now</li><li>that's a feature we've never had before</li><li>Rakudo's REPL now works better, thanks to sorear</li><li>HLLCompiler now written more in NQP as part of that</li><li>NQP now can do <code>eval</code> </li><li>NQP remembers lexicals in interactive mode now</li><li>adding that to Rakudo is more complex</li><li>working on that</li><li>pleased with the progress on #perl6</li></ul><p> <strong>c:</strong> </p><ul> <li>reviewing long term plans for GC and Lorito</li><li>should have more time free soon</li></ul> chromatic 2010-06-20T19:40:02+00:00 journal Perl 6 Design Minutes for 19 May 2010 http://use.perl.org/~chromatic/journal/40401?from=rss <p>The Perl 6 design team met by phone on 19 May 2010. Larry, Will, and chromatic attended. Patrick added his notes later.</p><p> <strong>Larry:</strong> </p><ul> <li>S03 makes more explicit that doctrine that <code>~~</code> topicalizes, and removes smartmatch table fossils that automatically fall out from that</li><li>S05 renames 'accent' to 'mark' for better Unicode conformance</li><li><nobr> <wbr></nobr><code>:a</code> and<nobr> <wbr></nobr><code>:aa</code> changed to<nobr> <wbr></nobr><code>:m</code> and<nobr> <wbr></nobr><code>:mm</code> </li><li>S05 disrequires retroactive semantics on<nobr> <wbr></nobr><code>:samecase</code> and<nobr> <wbr></nobr><code>:samemark</code> </li><li>the method form must now explicitly add case or mark modifiers to the pattern</li><li>regularized <code>mm//</code> to <code>ms//</code> to avoid confusion with new<nobr> <wbr></nobr><code>:m</code> ignoremark option</li><li>STD now does a bit better at diagnosing bogus <code>??!!</code> constructs of various sorts</li><li>STD now correctly adds operators to symbol tables as subs</li><li> <code>CORE.setting</code> now has protos of all the operators so they can be recognized as subs too</li><li>Cursor now canonicalize operator names in the symbol table</li><li>btw, not quite like specced</li><li>STD now reads user's mind on '<code>Str $toto</code>' to intuit missing declarator</li><li>STD now properly diagnoses a typename between routine declarator and sub name</li></ul><p> <strong>Will:</strong> </p><ul> <li>working on code for Carl Masak, trying to get his poker code example running on Rakudo</li><li>both fun and frustrating</li><li>some stuff doesn't quite work yet</li><li>going through the Advent examples</li><li>adding them to spectests</li><li>make sure we won't regress on such public examples</li><li>other people are helping with that now</li></ul><p> <strong>c:</strong> </p><ul> <li>will get back to editing the Rakudo book soon</li><li>hope to have it in print by YAPC, but no guarantee</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>fixed closures in NQP, as a precursor for fixing them in Rakudo</li><li>worked with sorear on REPL in Rakudo and PCT in general</li><li>ported the NQP "standard library" done by japhb++, bacek++, and many others into the nqp-rx repository and made it part of the standard build sequence for nqp and Parrot</li><li>decided we need a new "context sensitive" node type in PAST, will be used to create proper closures and to handle sink context</li><li>worked with bacek on adding better multimethod support to PAST and nqp-rx</li><li>discovered a problem with lexical subs in NQP being automatically entered into the package namespace (and some existing code relying on this behavior)</li><li>did some initial fixes to at least get things entered properly, but a complete fix may require a deprecation cycle</li><li>plan to review others' patches this week</li><li>plan to fix REPL, closures, and sink context in Rakudo (since those are currently large pain points)</li><li>plan to work on loops and iterators after that</li></ul> chromatic 2010-06-16T21:38:09+00:00 journal Perl 6 Design Minutes for 12 May 2010 http://use.perl.org/~chromatic/journal/40400?from=rss <p>The Perl 6 design team met by phone on 12 May 2010. Larry, Allison, Patrick, and Will attended.</p><p> <strong>Larry:</strong> </p><ul> <li>clarified usage of brackets around infixes</li><li>added various 128-bit types to the spec; we might make them arbitrarily extensible via role</li><li>at least LLVM could support this, even to non-powers-of-two sizes</li><li>modernized the paleolithic grammatical category description in S02</li><li>STD now uses double-quote rules for interpolating <code>@foo[]</code> into regex</li><li>STD now gives better message on <code>1__3</code> </li><li>added the specced 128-bit types to CORE.setting</li><li>added <code>minmax</code> function to CORE.setting</li><li>implemented <code>circumfix:&#171;X Y&#187;</code> as grammar derivation</li><li>currently only allows a <code> &gt;&gt; inside</code></li><li>now also recognizes <code>foofix:("\x[face]")</code> and <code>foofix:("\c[YOUR CHARACTER HERE]")</code> without actually evaluating</li><li>playing with factoring <code>yaml</code> out of <code>gimme5</code>, since <code>viv</code> is not likely to go that route.</li><li>mostly just answered a lot of questions on irc</li><li>egged people on about concurrency issues</li></ul><p> <strong>Patrick:</strong> </p><ul> <li>thought on handling closures properly</li><li>have a solution, just need some time to implement</li><li>discussion on changes to CodeString</li><li>work on compiler toolkit to avoid CodeString, using StringBuilder instead where possible, in PCT, NQP, and rakudo. Pretty easy, no downstream projects block on a deprecation issue</li><li>after that, lists</li><li>also been answering questions on interactive mode (REPL) for rakudo et al. (the issue with losing lexicals)</li></ul><p> <strong>Allison:</strong> </p><ul> <li>resolved the git conversation pretty well (for Parrot's repo migration)</li><li>worked on a pure PEG parser (following the paper), straight PIR, single day; now self-parsing. Interesting project, is lightweight. currently has memoization, but that might not be right for us because of backtracking. With some more effort, could probably handle EBNF form (useful for python)</li><li>could be setup for developer status for Debian which will improve our packaging status for Debian and Ubuntu</li></ul><p> <strong>Will:</strong> </p><ul> <li>Parrot CodeString performance improvements</li><li>we're definitely faster in branch, but some feedback from pmichaud should help us clean up the API a bit as well, look for those to hit trunk in the next few days</li><li>Parrot makefile deps cleanup</li></ul> chromatic 2010-06-16T01:47:02+00:00 journal