blogs.perl.org

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 (';')
• fix t/file_spec.t

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 really enjoy this (4th or 5th) rewrite.

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:

perl -w bin/random-poissondisc.pl -r 10 | ffeedflotr.pl --type=scatter

For our June 2011 meeting, Samantha Kosko will be talking about MongoDB.

MongoDB is a new document-oriented database. It provides a new paradigm for storing and accessing data, one that works very naturally with Perl.

We'll cover the basics of
- What is it?
- Why do I care?
- How do I get it working?
- What about ORMs? (time permitting)

For those interested in hands-on, please bring your laptop.
Instructions for getting started will be posted and we can do some interactive demos.

MongoDB - http://mongodb.org

10gen - http://10gen.com

RSVP at Meetup - http://www.meetup.com/San-Francisco-Perl-Mongers/events/20864421/

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.

Nice bunch of people, nice location and decent salary.. full details at http://jobs.perl.org/job/13932

[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 :)

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.

Hi Folks

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.

Dear Perl people,

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. :)

Hi Folks

Interested parties can peruse STT for details.

Cheers

Back in February I did a presentation for the Birmingham Perl Mongers, regarding a chunk of code I had been using to test websites. The code was originally based on simple XHTML validation, using the DTD headers found on each page. I then expanded the code to include pattern matching so I could verify key phrases existed in the pages being tested. After the presentation I received several hints and suggestions, which I've now implemented and have set up a GitHub repository.

Registration for the Intro to Moose training session on Thursday is now available. This is an excellent class if you are just starting out with Moose. It covers the fundamentals well and the exercises are brilliant. It is highly recommended.

The class description is available in the schedule.

I recently posted about Failing your way to success with A/B testing and I was pleasantly surprised about the very active feedback.

One issue which was raised was by Steffan Mueller (one of my colleagues at booking.com and a brilliant guy) is a common concern:

What I am most afraid of in the kind of A/B testing I've seen is that it seems very prone to getting stuck in local minima. In that image, imagine you're in the place marked with the red arrow. Taking small steps and adjusting for the test result each time, you're never going to reach the optimal place (blue arrow) since once you're in the local minimum, all small steps you can take actually produce a worse result.

Aristotle raised a similar concern and I think it's important enough to address up front.

I came across a recently written module by a very smart person who I am friends with, and the module neglected to 'use strict;'

Do you do this? If so, why? Please add your reason in the comments. I'm somewhat flabbergasted that anyone wouldn't use strict in this day and age.

I'm happy to report that version 1.00 of Aspect.pm has been uploaded to CPAN, and so Perl's Aspect-Oriented Programming toolkit is now officially done.

http://svn.ali.as/cpan/releases/Aspect-1.00.tar.gz

The API should remain stable for some time (until the notional 2.00 with it's major rewrite into opcode manipulating XS). Most future changes in the 1.00 series should comprise additions of keywords or features, and code written now should be forward compatible.

But what is Aspect-Oriented Programming, and what it is good for? The standard documentation in AspectJ is full of jargon and most of the code samples are notional at best, and make it hard to connect to any real world situations.

The simplest way to describe the Perl Aspect.pm is that it provides a way of hijacking functions or methods with very little code, and in a very precise and controlled manner.

Hi Folks

OK. I've released Set::FA V 1.00 to CPAN. The code passes the same tests as the previous version, V 0.101.

The docs have been re-written from scratch, for both Set::FA and Set::FA::Element.

There have been many changes due to the fact the code no longer does direct access to an internal hash, but uses getters and setters. I have not changed any of Mark Rogaski's code which implements the logic of the modules, I've only made it work in a new OO environment.

Also, I've dropped support for Log::Agent, and provided a parameter to new() called logger, so you can supply any type of logger, and have the code call
$logger -> log($level => $message)
at various points. All this is documented extensively.

Another new parameter to new() is die_on_loop, so otherwise run-away programs can be self-limiting.

OK - time to put it to work...