Is there any particular reason for the manual error checks on each step rather than setting the RaiseError flag? (this modified version of 02_busy.t seems to indicate that it throws an error as expected, on first read of your post I thought you were talking about an "invisible" data loss situation)
Also, switching to mysql (or other DBs) won't help much here, there's still the chance of deadlocks - see http://stackoverflow.com/questions/2596005/working-around-mysql-error-deadlock-found-when-trying-to-get-lock-try-restarti for example. Robust code would have to assume that pretty much any query can fail - and know when it's worth retrying, and when it's just not going to work. I don't use DBI myself, but would be surprised if there weren't a few options in DBIx::* for this?
]]>SET foo = 1 IF 0;
Without that, a new value will be stashed in foo regardless of the expression - last I checked it'll compile to something like ->set(foo => sub { my $rslt = ''; $rslt = 1 if 0; $rslt });, so you'll end up with the starting value of the temporary (an empty string) rather than the original value. Not sure offhand why this is the case, but I find it's usually safer to use the block syntax for conditional assignment - 'IF something; x = y; END' or to use the explicit SET version.
Details are probably buried deep in Template::Parser or Template::Directive...
]]>Toby - thanks for the link, I’d not tried HTML::HTML5::Parser before. Always useful to have an alternative parser that can handle “real-world” data.
]]>my $dom = HTML::TreeBuilder->new_from_content( $content ); $_->delete for $dom->look_down(_tag => 'style'); print $dom->as_HTML;
or the second example:
$_->delete for $dom->look_down(_tag => 'style'), $dom->look_down(_tag => 'link', rel => 'stylesheet');
Not quite as compact as the Mojolicious approach - as has been mentioned before, sometimes reinventing the wheel provides a smoother ride. Seeing HTML parsing regex code in the wild and suggesting Mojo::DOM / TreeBuilder equivalents seems like a worthwhile effort to me, whichever module you choose, so keep up those stackoverflow replies.
Mojo::DOM performance also seems pretty good - even with some filler content in the page it seems to be consistently about 25-30% faster than the HTML::TreeBuilder equivalent, not bad considering it’s up against XS for at least part of the HTML::Tree stack:
https://gist.github.com/3837205
One slight downside to the regex reimplementation in Mojo::DOM::HTML is that it doesn’t seem to cover all the edge cases that HTML::TreeBuilder can handle - https://gist.github.com/3837258 for example, which I believe is a valid HTML4 comment although it seems this comment syntax has been disallowed in html5, which presumably is what Mojo::DOM is aimed at.
]]>I don't use PAR::Packer much myself so there may be a better way of handling that, and perhaps it's out of scope for what this module should be doing anyway.
]]>Not sure how that SL replacement would work, though: that assignment will happen after the BEGIN block so any special-cased value you put in would be overwritten?
Maybe this would do the trick:
my $SEPARATOR;
BEGIN {
if ($^O =~ /^(MSWin|dos|os2)/i) {
$SEPARATOR = '\\';
} elsif ($^O =~ /^MacOS/i) {
$SEPARATOR = ':';
} else {
$SEPARATOR = '/';
}
}
perl -MLWP::Simple=get -MXML::TreeBuilder -E'my $xml = XML::TreeBuilder->new; $xml->parse(get "http://w1.weather.gov/xml/current_obs/KBUR.xml"); say "Temperature is " . $_->as_text . "°C" for $xml->look_down(_tag => "temp_c")'
]]>Thus you need to go along the data more than once if you rely on aggregation functions in SQL.
I'd agree with the concept that the right tool for the job is the one which gets the results you need (in the timeframe you need them by), just curious about this though:
Why would it need to process the data more than once? Data aggregation is something that SQL excels at. Presumably there are some missing details, but surely:
select month, week, count(value), sum(value) from table group by month, week
Only a single pass required, no marshalling of raw data and transmitting it outside the database - would expect this to be quicker to implement + run than either a Perl or C++ approach. Add rollup/cube operators as required - maybe the issue here is that there isn't enough documentation around for using Perl in OLAP situations like this?
For completeness, it'd be good to see some of the event-based modules in there - personally I use Net::Async::HTTP these days, but a quick search shows these as well:
perl -e'use strict; use warnings; package UndefHandler; our $AUTOLOAD; sub AUTOLOAD { (my $method = $AUTOLOAD) =~ s/^.*:://; warn "->$method called on undef value"; () } use autobox UNDEF => q{UndefHandler}; my $x; $x->something->like->this;'
Not something I'd usually leave on in production but have occasionally found it useful when there are a lot of cases and I want to go through and fix them all rather than a find/fix/repeat iteration process.
]]>First (top-level) comment: "Don't use a specific version unless it's genuinely version-dependent". Seems like reasonable advice, and the followup from the same poster: "No need to say sorry. We're all learning"
Second comment: "Otherwise looks good to me ;) Good work on strict/warnings!"
Third comment: tongue-in-cheek alternative, "If you haven't noticed, i'm joking. Seriously, good job so far :P", still seems polite enough.
Fourth comment: one-liner version. Neutral enough, surely?
It's only when you get to the fifth comment, which again is a reasonable-enough reminder that $a and $b being globals, that some of the replies start to descend into an argument, and I have no idea whether the assertion that the script was changed after the fact is true.
"everybody just trashed him and went off in every possible stupid direction" seems like unnecessary hyperbole. I'd suggest just calling out the behaviour in the same forum (if you disagree with it), or even avoiding reddit.com entirely - no idea if this is representative of Perl or other language threads there, but doesn't seem like much to get worked up over. Can't see a single example in the last few blogs.perl.org postings where anyone has been less than complimentary towards each other, with the exception perhaps of the posting about using Yahoo Pipes to block certain postings. (not that I know how to view older postings on this site without trailing through search engines or wayback archives...)
I'm really not familiar with perl6 but split ' ' in perl5 also splits on any amount of whitespace characters (and strips preceeding/trailing whitespace as well), so I think those two are probably equivalent?
]]>Anyway, since I don't read reddit, I wasn't sure what you were talking about here - from the headline I guessed it was going to be a tutorial on debugging code ("If Perl tells you something and you can't see how that could possibly be the case, start by assuming that you're wrong and Perl is right"), for example. After reading it, I was somewhat nonplussed - then I read your previous article ("Putting the ideas together") and saw this:
Unless you're a noob Perl developer you cannot possibly refute my claim
which seems to be a textbook example of what you're talking about, surely?
Given that the description of the workshop mentions "Moose, autodie, DBIx::Class, Try::Tiny, Method::Signatures, autobox, NYTProf, Perl::Critic, test driven development and the funky regular expressions changes Perl 5.10 brought in", it really doesn't seem like the target was the "noob Perl developer", more like an intermediate level. I'd be surprised if someone at that level was fazed by a few chained function calls with no parentheses in sight - and if they were, I'd think it'd do them good to see some alternative ways of writing Perl expressions.
I've only taught about a dozen people Perl, which is clearly not enough data to be statistically significant, but out of that group only two former C coders had trouble with the parenthesis-free version. Took them about a week to get to the point where they could parse either version equally quickly, but I think it was worth learning early. Those with no former coding experience seemed to prefer the version without the extraneous () syntax.
Comments don't always devolve, at least here - seems to be the exception rather than the norm. Writing an article claiming that they do seems counterproductive, particularly if you have no examples to give and no suggestions for alternatives. I appreciate everyone has a need to vent frustrations once in a while, but IMHO you'd have better results if you just called out the behaviour you disagree with in a followup comment, rather than declaring "omg everyone on the internet is rude". Imagine how this article would look to a newcomer to the Perl world - particularly when taken out of context.
Personally I like responses based on Vulcan-like analytical skills - if someone comprehensively demolishes one of my statements or assertions, even if they don't hold back any punches, typically I will have learned a few things by the end of the comment... and I'd far rather have that feedback. Better to correct misconceptions as early as possible than to allow someone to build on inaccurate foundations.
Of course, if this article was in response to something completely different, then feel free to point and laugh and move on =)
]]>Namanya "perl.org", jadi ini tempat untuk orang yang ngebahas perl, atau mau ikut berita tentang perl, atau... wah, apapun, yang penting ada campuran dengan Perl lah! Kalau hanya mau blog yang gratis, lebih baik coba blogger.com atau yang lain?
Saya juga takut tidak ada banyak orang membaca website ini yang mengerti bahasa Indonesia atau Malaysia - ada 4 saja daftar search.cpan.org/perldoc?Acme::CPANAuthors::Indonesian