Pheasant is pleasant, of course,
And terrapin, too, is tasty,
Lobster I freely endorse,
In pate or patty or pasty.
But there's nothing the matter with butter,
And nothing the matter with jam,
And the warmest greetings I utter
To the ham and the yam and the clam.
For they're food,
All food,
And I think very fondly of food.
Through I'm broody at times
When bothered by rhymes,
I brood
On food.
-- Ogden Nash, "The Clean Plater"
I've just uploaded the first release candidate for Perl 5.12.4 to
PAUSE. You should be able to find it at:
It's very important that you test this release with any software written
in Perl which you use or maintain. If no "showstopper" class bugs are
found in the next few days, we will release a virtually identical
tarball as Perl 5.12.4.
I'm testing some software at work by replaying pcap files at the application. I want to make sure the results in the database match what's in the original packet dump. There are hundreds of packet producers. I want to focus on the top ten to make better use of my time.
I've written a utility to dump interesting packet data as streams of JSON objects, one per packet. Each object includes the source and destination IP and port, among other things.
May has been a bit of a quiet month, although a few things have been happening in the background. The continuing work of packaging the websites is ongoing, and the plans for the Admin site are coming together. Having said that we did pass the 12 million reports mark in the middle of May too :)
We had a few reports that the testers themselves acknowledged were inaccurate. Although the new Admin site will eventually allow testers and authors to tag reports, the site isn't quite ready for release yet. As such, I now have a script, which uses the guts of the forthcoming Admin site, to hide broken reports. The reports are not deleted, as they may be of use in the future, but hidden from the statistics calculations. If your smoker does send a selection of bad reports, please let me know, and I'll see if I can hide them. As mentioned, the Admin site will eventually take on this role more officially.
While I’m delivering the news, here’s something for you ignorant American backwoods motherfuckers. Some people’s names have “special characters” in them. Like François Rabelais or Björk Guðmundsdóttir or 艾未未. It’s 2011; the only software that can’t handle Unicode properly is Perl. (As if you needed another reason not to use Perl.)
please quit being an ignorant backwoods motherfucker and stop talking shit about crap you don’t know anything about.
To the Perl folk reading this — the problem we’re dealing with in terms of perception nowadays is confirmation bias. Nelson hates Perl, sees one question on StackOverflow that is making the rounds because Tom answered with one of his obsessively detailed (and therefore huge) missives, generalises wildly from a shallow read of the QA, and then – surprise – finds his opinion further confirmed.
IO:All 0.41 can be installed successfully on Win32 (no Cygwin), if the test fails and spews something like this:
# Failed test at t/file_spec.t line 28.
# got: '33'
# expected: '34'
# Looks like you failed 1 test of 27.
t/file_spec.t ........
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/27 subtests
The alternatives:
fix your %PATH% of more than one partition character (';')
Frankly I never got it until recently. Sure, I had some informal contacts with plan 9, the OS that is entirely designed around that concept. First when Linus talked about the features he borrowed for Linux, later I borrowed myself features from Plan 9's editor acme for Kephra. But yesterday I saw a talk from the author of MacFuse and I really got a hang of it.
And suddenly I realized the implications for a better Kephra that I currently design. When it read and writes FIles it should have hooks to do whatever (aka *). Not only be able to write files on remote machines via ftp/sftp/*. But also use it to literally edit *. I mean, why do I have to use the clunky Wiki editors, when I can have Kephra, where I'm twice as fast and can store the relevant parts of everything i write in the right places for later reuse? Even that box i currently typing in sucks compared to any decent editor. And please with the right module (Mechanize and friends) its a handful lines to do that.
I read this nice article on map generation and naturally want to write something like it, but in Perl. For the first step, I want to distribute points nicely across the plane, by using the Poisson Disk Sampling method outlined in the article. Implementing the algorithm was straightforward, but how would I know that the output data was correct in the sense of reaching my goal of uniform but randomly distributed points across the plane?
The test program of Random::PoissonDisc conveniently outputs the generated points to STDOUT. For visually inspecting the data, I can then pipe it into App::ffeedflotr which displays a nice point cloud. The first output of Random::PoissonDisc looked like this:
I really know a lot of Perl people, and whatever is going on in my Gmail account is reminding me of that. For some reason, someone wants the world to think that I want all of you to buy Viagra and watch a stupid YouTube video. I think the YouTube thing is just a red herring for the spam filters. If you don't want to buy fake Viagra, don't follow the stupid links.
Thanks for everyone who responded to the spam to let me know something was going on. I won't respond to the hundreds of messages I got telling me that. At least it's nice to know that people read my mail, even when it is spam. :) Many of you may have missed out on the fun because perl/cpan.org caught it as spam.
At the moment I don't know what's going on, but the messages are in my Sent Mail. This wasn't someone just masking their crap with my email address. Also, some messages went out after I changed my password. As such, I have other suspicions and I'm shutting my machines down for a couple of days, after which I'll slowly bring things up again to see if something (say, a web browser) is acting under someone else's control.
I just started a huge and deep rewrite of what I believe is the most useful editor overall. So why throw it away? (most imortant point is at EOF)
First it will still be maintained, a new version just came out today and i still will fix some remaining issues and even add some features. I will do so, till it can be fully replaced.
On the other side some issues are not that easy to fix, in modules with hairy dependencies, you know what I'm writing about. In fact, I have to write some test app eather way to toy with some solutions. So this rewrite comes with not much overhead over things was planing to do for some time.
We're looking for a senior perl developer to join our team at headforwards, based in the Pool Innovation Centre in Cornwall - we're an agile team using scrum, shiny mac workstations with big screens in a nice new office and an experienced scrum master working on a project with a MASSIVE Telco.
[edit] oh yeah and we're interviewing now, and can move quickly to get the right person in and started soon.. no waiting around for sluggish HR or closing dates :)
Leon Brocard has kindly given me co-maint of GraphViz.
The aim will be to provide essentially the same features, but to support all the latest graphviz attributes.
The distro will contain some graphviz manual pages, with the scripts which downloaded them, and the output of those scripts. They use HTML::Treebuilder's amazing look_down() method to extract lists of valid attributes in various contexts. So, the attributes themselves are stored in data/*.dat within the distro.
That means they can be used to validate user options, because the code loads these lists when new() is called.
Moose is not used. My policy is to use Hash::FieldHash for speed in stand-alone modules, and Moose only for apps.
Here's how you can help:
o There's a module which allows multiple 'files' to be shipped in the __DATA__ section of a script. I've forgotten its name.
If you know interesting things about how you can work with IPv6 in Perl nowadays, you are more than welcome to submit a talk to YAPC::Europe.
I believe there're lots of pieces to talk about in that field. The talk can be as detailed as the recent answer about using UTF-8 on stackoverflow, or it can be a five-minute lightning talk. Please share your experience!
Given the large amount of commentary on my first A/B testing post, I was surprised that there was none for my "A/B testing and local maxima" post. That's when I discovered that when you start a post and publish it several days later, if you don't update the date, it keeps the start date and thus gets buried in the queue. So, if you haven't subscribed to my atom feed, you may not have seen it on the front page. This is just a heads up that I took the time to answer some questions people had.
Bundlefly is a hack I've written to build a graph of a bundle's distributions and install them in optimal order. It accelerates the installation of entire library suites for new Perl builds and perlbrew instances. As with App::PipeFilter, it may end up on CPAN if there's interest.
Autobundle snapshots are comprehensive by design. They list all installed modules at a particular point in time. We should rarely be asked to confirm "unsatisfied dependencies" while installing them. The dependencies are almost always somewhere in there.
To compound the suck, we're often asked to install the same fundamental dependencies repeatedly. ExtUtils::MakeMaker and Test::More immediately come to mind. We shouldn't be asked once, yet we're asked several times by the end of the day.
One problem is that autobundle snapshots list distributions alphabetically, and CPAN's shell installs them in that order. Test::More, a distribution used to test a large portion of CPAN, is installed relatively late—after it's already been prepended to the install queue as a dependency of several other distributions.
Bundlefly's dependency graph allows it to install dependencies before dependents. The only "unsatisfied dependencies" one should ever see are those introduced since the last CPANDB build and which aren't listed in the autobundle snapshot.
its a small idea and a module. in fact I wrote the core code in a minute on a slide of my talk I held 2 weeks ago in Berlin. Now it becomes "real" :). from the "doc":
use Tie::Wx::Widget;
tie $tiedwidget, Tie::Wx::Widget, $widgetref;
# instead of say $widgetref->GetValue;
say $tiedwidget;
# instead of $widgetref->SetValue('7');
$tiedwidget = 7;
untie $tiedwidget;
Its just the simple idea to reduce visible syntax, but will become more usefull in combination with the next planned module that takes you XRC-produced widgettree and gives you a similar tied hash, so you have not only a simple API for your basic IO but also all locked in the namesmace of a hash variable which you can much easier pass around when creating event driven subroutines. if the widgets dont have name attributs i will have to be more tricky.
Please post your thoughts on that. I plane some even bigger surprises.
A few months ago there was a rumor of Richard Stallman coming to Palestine, and I contacted him to suggest giving a few talks in Israel as well. He inclined and there were 4 lectures/speeches booked:
One at Shenkar College in Ramat Gan, Tel Aviv (which is where TelAviv.pm meets)
One at Tel Aviv University
One at a DIY venue for political activists
One at Haifa University
I booked the Shenkar College one (for the Tel Aviv Perl Mongers and anyone who wanted to attend) and the one for political activists. I've slowly been collecting a group of people to help me organize the first meetup (which should have been in front of 300 people) since I did not want any organization or company (except for TA.pm) to be behind it. I wanted complete freedom, excuse the pun. :)
