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.
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.
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. :)
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.
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.
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.
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.
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.
I've been waiting for this blog post for a few good months now.
We've finally released Dancer 1.3050 (codename "The Captain Hook Adventure", named after Franck Cuny, who will forever be known as Captain Hook!) which carries our new hook system, written by Franck. Special credit goes to JT Smith who pushed the design and implementation of this system (and had great input and feedback) until it saw sunlight.
So what's the new hook system? Basically Dancer (and Sinatra, and Flask, and others) have a before and after modifiers (or sometimes called "filters"), which are basically hooks for running code before and/or after your request has been handled. This is a good place for running checks, auth-related stuff and special logging or whatnot.
While these hooks were very useful for people, they weren't enough. People needed more. For example you might want to override the error handler, or perhaps to add special data before a auto-serialization process. Hell, maybe you want to even create your own hooks! :)
We're currently working with the resort to resolve the issue of booking rooms. We've made contact with them and their advice is to call 800-733-3211 to reach in-house reservations or to leave voicemail messages, or email reservation inquiries to reservations@hulsinghotels.com. Further, waiting until next Tuesday when the resort can reassess the inventory might be the best course of action.
