Now I call DBD::SQLite 1.43_08 a release candidate of the next stable DBD::SQLite. Please test it with your modules/applications and let me know if you find anything. Due to some change(s) in the upstream SQLite library (since SQLite 3.8.5), this release candidate is known to break older versions of DBIx::Class (prior to 0.082800 released on 2014-09-25). If you use older versions of DBIx::Class, you might also want to upgrade it, or keep DBD::SQLite 1.42 (bundled with older SQLite 3.8.4.1 library) for now. Other major O/R mappers seem not affected by this upgrade. If there's no blocker nor request to wait, I'll release 1.44 in late October, hopefully on 26th.
Other notable changes since the last stable release follow:
This release candidate contains new modules to support custom virtual tables written in Perl (by DAMI).
If you set sqlite_unicode to true, SQL statements will be upgraded to avoid inconsistency between embedded params and bind params (RT #96877) (by DAMI)
See Changes file in the distribution for other fixes and improvements.
Just in case you're curious, I'm still hacking on Veure, though the last month has kept me busy on a bunch of other things (our daughter just started school, so that's a big one!)
I've been building so much of the infrastructure that you might be surprised to realize that I've only just gotten around to being able to equip weapons and armor:
The other developer has been working on the cockpit view. If you travel from system to system in your own ship, the experience should be different than if you take public shuttles. I haven't actually seen his work yet, so no screenshot on that one.
Update: OK, I have some of the initial screenshots for the cockpit work. They look great, but not sharing until some things are settled.
As you may be aware, I'm writing a book which will eventually become a free e-book. (Oh how I'm beginning to hate the e- prefix on everything vaguely related to computers. Or should I call them e-machines?) This is my initial report on how I'm getting along.
Firstly. @preaction CPANTS != CPAN Testers. They are two very different projects.
Secondly, this is a conversation that has cropped up before, and I'm still in two minds about it. Short answer: I tend to side with brian. The tester platform shouldn't be doing any testing with the trial/development releases of pre-requisities, unless the tester is going to manually filter the results and send to the pre-requisite author if appropriate. I do understand Ether's perspective too, and there is merit in having these reports, but they more often target the wrong author.
Last month, I mentioned that I was rewriting Pod::Readme.
Basically, this is a module that allows you to generate a useful README file from a module's POD, besides a simple "pod2text lib/MyModule.pm > README". You can add sections of POD that are only included in the README, like installation prerequisites, and exclude bits that don't belong in the README, like the details of every method.
A pre-release has just been uploaded to CPAN. A short summary of the changes:
It requires Perl v5.10 or newer, and uses Moose. (This will be rewritten to use Moo in a later release.)
Instead of using a full POD parser, it implements a simple POD filter and passes that POD to other modules to convert it to text or other formats.
It supports plugins. This version has plugins to include the module version, a requirements section, and the latest changes.
Support for generating README files as markdown, POD or other formats has been added.
Feedback would be appreciated, as are patches in the git repository.
I still wish we had a way to remove reports from CPAN Testers. The case of a broken Test::More is a really good reason for this.
I received many fail reports for Business::ISBN, which I've been working on lately. However, it's from a test I hadn't touched for things I wasn't working on.
The failure looked odd. I've never heard of Test::More::DeepCheck:
Modification of non-creatable array value attempted, subscript -1 at .../Test/More/DeepCheck.pm line 82.
Then I noticed that all of the fail reports reported the same development version of Test::More:
Event::Lib is a binding to a libevent library. Its development stalled for about 7 years. Module doesn't build with new Perls (at least >= 5.16), and has a lot of open tickets in a RT CPAN queue. Looks like maintainer of module Tassilo von Parseval is not available via email. I have module Net::IEC104 which rely on Event::Lib, so I'd like to make new release of Event::Lib with fixes for any currently known issues to keep my module installable and functional. I'm making this post asking for permission.
I ran into a situation today where I was trying to see whether any exceptions were thrown when evaluating a list of objects. In this particular case I didn’t want the exceptions to short circuit the loop, I just needed to know if any were thrown as we iterated over the list. So I wrote this benchmark to see which of two approaches would be faster.
Yesterday we looked at an example of how to both index and search using elasticsearch. Today, we'll talk a little about what takes place during indexing, particularly tokenization. For example, what happens when we tokenize the phrase:
porros amb basàlmic
To find out we can pass the phrase to the elasticsearch analyzer API like so:
curl -XGET 'localhost:9200/_analyze?tokenizer=standard' -d 'porros amb balsàmic'
Here we are using the standard (default) tokenizer which results in the following output:
I think I'm on the verge of drinking the Cucumber flavored Kool-Aid, which is odd because I've never done Behavior Driven Development (BDD) before. If you've followed my blogs over the years, you know that I am happy to investigate new trends, but at the same time I'm deeply, deeply suspicious of them. BDD has been one of those "fads" that I've been suspicious of, but I think I've changed my mind. What follows is why.
If you have been browsing MetaCPAN lately, you may have noticed a new shiny red ball ribbon on the left side of somedistibutionpages. What you may not have realized is that this is a generic feature, and you can add one to your distribution just as easily.
TL;DR: All you need to do is add an IRC resource to your metadata:
Elasticsearch és un motor de cerca. Fem un petit exemple com es pot utilitzar-ho. Necessitem unes dades per cercar, per tant agafem unes receptes d'internet, gràcies a http://receptes.cat. Un cop tenim les receptes, llavors les podem indexar en elasticsearch, després del qual podem cercar-les.
I've been rather quiet lately because I'm busy, busy, busy. Part of this is contract work for a company (amongst other things, I've been doing building sqitch setup for them), and part of this is new research into Agile. Today I wrote a quick blog post explaining one of my pet peeves about Agile: people say it's not a silver bullet, but they don't say why. I briefly explain when you should and should not use Agile.
I've recently released a new module called Object::Util to CPAN. This is a set of handy methods for working with classes and objects in Perl. It is inspired by Safe::Isa, a module which takes advantage of the fact that coderefs may be called as methods on Perl objects:
my$method=sub{...};$object->$method(@args);
Object::Util gives you a set of coderef utility methods that are applicable to a wide range of classes and objects.
