I'm interested in getting Convert::Binary::C into a properly maintained state once again. It has a pod test that is failing (which should be an author or release test) and a regex deprecation warning in 5.22 that will likely render it uninstallable without patching in a future version of Perl. It's a really great module, and doesn't need a lot of changes just a few simple fixes. I've attempted to contact the author via rt, email and twitter. I'd be happy to adopt the module and resolve non-contentious bugs this module has collected. I believe I have a pretty good record on past adoptions, but I'd also be happy for someone else to do it, my goal is only to get a couple of pretty simple bug fixes into the module. If I don't hear from anyone I will try to adopt via the modules list.
edit: The original author has uploaded a new version with these (and a number of other) issues resolved!
From last night's Sydney PM, my talk on Log4perl. In retrospect I should have named it "Logging: Not the fun kind with chainsaws and axes, but the boring kind with grep and less". Check it out:
Also worth sharing, from much discussion about the recent fad for "dashboards", is the perl Dancer based towncrier from the nice people at FastMail.fm. See their live usage of it here.
Last week I promised (or threatened depending on your outlook) to talk about Alien::Base in the context of system integration and distribution packagers.
Philosophy:
The philosophy for Alien::Base has always been that the system library should be used when it is available, and if not, the source code for that library can be downloaded and installed for you. My own Alien::FFI (isa Alien::Base) which provides libffi, and FFI::Platypus which uses it is a good example of the success of this approach as you can see from their respective testingmatrices.
Alien::Base is of course trying to keep everyone happy all of the time, and everyone knows that is impossible. System vendors complain that Alien::Base has too many dependencies. Module authors fear that using the system library will make it too hard to support their XS modules since they could end up linking against almost anything. These perspectives frequently clash and it can be a challenge to maintain empathy for other parties when they do.
I can not think of anything qualifying as doesn't have to be a huge Perl project* However, I have an idea which unquestionably will benefit the Perl community immensely, yet has a remarkably low barrier to entry (mainly one thing - patience). I propose that someone applies for a grant in the role of DBIx::Class re-documentation project lead.
I have had inklings of "there got to be a better way to do things", but it wasn't until I read this meditation by BrowserUK that it dawned at me: Fixing up the better-than-most-but-still-terrible documentation of DBIC is a ~200 person-hour undertaking, which on top of that requires someones fresh eye. Given that DBIx::Class is a "staple-module" in the contemporary Perl ecosystem, I believe it is reasonable to expect for the TPF to "pick up the tab" if someone with the right qualifications steps up.
So what is wrong with DBIC's documentation anyway?
The compiler now has a small test suite. The main additions in the last 10 days were implementing global variables, better support for references, data structures, string interpolation, and a few new subroutines in the CORE namespace and operators.
We (the Perl community) currently do not have a CPAN module that handles OData (cf. odata.org).
There seems tob e an attempt to do it here: OData::Client
But it's not finished yet, and i fit doesn't get a care taker, it will never be done.
Also, there is client and server parts. Let's get both :)
Side node:
Eventually, I'm too dumb to see that we don't need one because Perl can do it out oft he box.
But if this ist he case, eventuelly, it would be a good idea to put up a grant to create a document describing how to use OData with Perl (like this one)
We are accepting presentations in a wide range of topics, for example Dancer, Modern Perl, DBIx::Class, Perl "products" and security. Of course, we are open for any idea and submission.
The submission deadline is August 31th, midnight CET. Talks are reviewed and possibly accepted as we receive them.
Please use the online form for submitting your talk.
Questions? Feel free to ask! Either put a comment here or send an email to
Ever given any thought as to what the expense of catching exceptions with Try::Tiny or even eval might be?
Recently a colleague was having some issues with a legacy codebase that was having requests exceed their nginx proxy timeouts. We discussed increasing those timeouts, but considered that a last resort.
One block of code being executed was along the lines of
This week we rolled out the latest version of Alien::Base which includes a new feature and a bug fix. The most important change in this version are the two new avenues of communication that we have adopted, so I will discuss that first.
The first is that we have established the #native channel on irc.perl.org to discuss interactions with native interfaces. This includes Alien in general, Alien::Base specifically, and we also intend it to be a place to discuss FFI (Foreign Function Interface or NativeCall), as there is a degree of overlap for the people involved. You can now click on a big red button from the metacpan page for the project that will log you into IRC and allow you to start asking questions (or complain at us if that is what needs doing).
Every distribution should have a LICENSE file, that corresponds to the licensing information contained in your Makefile.PL.
You can create this file from the command line by installing App::Software::License - e.g. cpanm App::Software::License. Then, just invoke the software-license command.
Also there is still time to get a cheap plane ticket to come :).
The system that we are using to make the payment only works on Brazil but you can just drop an email to the organization and we will arrange everything to you.
I have to share with you that just changing the layout of the website the visits grow three times. Kind of obvious but the ugly site works ok with us from the community but not for "outsiders". Even to reach perl programmers that usually does not participate of the groups the "beautiful site" works way better.
When you work on larger projects, you'll often find that database changes are hard. Multiple developers, working on the same project, changing the same tables, can be difficult. Database migration tools often (but not always), come with one or more standard flaws:
Reliance on migration numbers (in other words, two or more developers commit migration number 6 and get a conflict)
Reliance on an ORM, such as DBIx::Class (sucks for the Python devs)
Reliance on something other than the Data Definition Language, or DDL (sucks when your custom tool can't represent the stored procedure you want to define)
There are plenty of other ways database migration tools fail, but the best standard tool I've worked with so far is sqitch. Its documentation needs some work, including more explanations of how to deal with common failure modes, but it avoids the above problems and provides you with a rich set of tools to make database migrations easier for large teams.
Is the Foundation mainly interested in grants to help fund work on Perl's own infrastructure -- the language itself, key modules, and other community projects -- or would it also be open to considering funding open-source applications created with Perl, but which don't primarily exist to support Perl itself? (And which, perhaps, might help further Perl's reputation, and provide the world with more high-quality example code?)
Our grants program does not specify such scope. So our official answer is: "just send a proposal for review". I also went through the historical grants, both approved and rejected, and found no grant proposals in this area.
Anyway, even without specific grant proposals, I thought it would be interesting to ask this question to the public. Should we fund application development Perl?
