Yes, I write a lot of scripts having to do with parsing FASTA. I want to put lots of example code out into the wild so people have things to read and copy. In this example, a student needed to take a subset of reads from a set of FASTA files as her assembly was failing due to excessive memory requirements. This script will process a list of FASTA files to take the first "n" (default 100,000) reads from each, placing the output file into "out-dir" (or the same directory as the input file). So as not to accidentally overwrite the original data, I append an integer (1, 2, ...) if the output file already exists.
Today in the Dist-Pen I am going to try and get all my version numbers in a row.
Doing some more investigation on how Dist::Zilla will solve another of my distro pains and that is Versioning of my package. I did learn a lesson on version some years again when I though I was doing someone a favor I did a quickie release of DBD::Oracle where the release tar ball didn't match up with the release name.
Go a whole bunch of heat over that breaking a few things that other people where doing. I guess going from 1.23 to 1.24a can really spoil some peoples day, who new? So since that time I have always been very weary about visioning my code.
There is a nice little plugin for Dist::Zilla called '
AutoVersion
' which is suppose to fix this sort of thing for you. Up till now I just had
In a GitHub issue discussion by my former colleagues, I noticed weird errors being reported. I was curious about the cause, but not enough to dig deeper, and as nothing happened, I forgot about it.
But then they asked me for a favour, and I agreed to help them with a project. But, to my surprise, I wasn’t able to install the tools I originally helped to create, getting the same error as the poor GitHub guy. Quick check of the CPAN Testers showed problems in Treex::PML, one of the underlying libraries, all the way down to 5.20.0. A typical report would look like this:
Hi! This is small post concerning sparrow plugin to monitor minion workers. I had some post on this recently, but now I have made some improvements at existed plugin, so I am writing a new one ...
On my production server I use Minion to send emails to my clients. For some reasons there are faults on executing minion tasks or even minion workers get stopped sometimes for reasons unknown. As sending emails is a vital part of the service registration system I need to know if everything goes bad with my email system. Here is minon-check sparrow plugin to risqué.
Install sparrow
$ cpanm Sparrow
Install sparrow plugin
$ sparrow index update # get latest plugins index from Sparrowhub
$ sparrow plg install minion-check # install plugin
DBD::mysql is the perl DBI driver for MySQL and the primary way Perl
applications and scripts access MySQL and MariaDB databases. The source
repository is at https://github.com/perl5-dbi/DBD-mysql.
A vulnerability was discovered that can lead to a buffer overflow, possibly
triggered by user supplied data. This vulnerability is present in all releases
at least back to versions 3.0 of the driver, which were released in 2005.
The CVE identifier for this vulnerability is CVE-2016-1246.
Users of DBD::mysql are advised to patch their installations as soon as
possible.
We have already made a pre-announcement for this security release at
the distros security mailing list. People using DBD::mysql installed from their
(linux) distributions can expect to receive an updated version soon.
Many thanks to Pali Rohár for discovering and fixing the vulnerability.
The DBD::mysql maintainers,
Patrick Galbraith
Michiel Beijen
One thing that has been pointed out to me in the past it that I neglected to includ a license file on some of my CPAN distros. I have even forgotten to include a copyright notice, not a mistake one should really be making.
Dist::Zilla already has a rule that compels me to add in a license, as we saw that in this post and I think with only a few quick changes to my '.ini' file I will be able to get the license file in there as well.
In my '.ini' I just enure I have the correct license set up, right now I have
You've been pulled into an impromptu meeting where the client now wants a web calendar tacked onto their application. Grimace. Walk out worried. But most important ...
Don't re-invent the wheel.
FullCalendar.js has most of what's required by default, is extensible and will take a json web feed. Given a list of hash refs, Mojolicious will spit out json. I'll show you a short template for displaying the calendar. Creating all your calendar appointments in json is left as an exercise for the reader.
Hacktoberfest is nearly upon us again. If you sign up and then do 4 pull requests in October, you'll get a free t-shirt. Sadly the list of Featured Projects doesn't include any Perl ones, but last year I created a list of featured Perl projects.
If you've got some issues you'd like to offer as fodder for the fest, all you need to do is add a Hacktoberfest label to the issues
So today in the Dist-pen I am going to add in a few more plugins into my Dist::Zilla just to see how bad my Kwalitee is.
One of the things that has always caused me problems when creating a perl module distribution are the 'required' modules that sometimes may be unknowingly buried in the code or just forgotten when the distro was created. My Database::Accessor package has a large number of required mods so I will have to be careful when creating my Dirstro
Just of the top of my head I have some ten or eleven in the Data::Accessor class and then there are my test cases where there are some more. Now with Dist::Zilla I can add a simple plugin and get most of them automajickaly so I added in
Git::Database is yet another module I wrote to interact with Git. It wraps an OO-layer around Git objects (blobs, trees, commits, tags), in a way that's very similar to what Git::PurePerl does. It has no opinion on the actual means to get the data from the Git object database: that bit is done with the Perl Git wrapper of your choice.
At the moment, there's only one supported wrapper for fetching data from Git: my own Git::Repository. I already have branches with working code (i.e. passing all the relevant tests) for Git::Wrapper, Git::Sub, Git::PurePerl and even the venerable Git.pm, which I'll publish when they are more feature-complete. Git::Class is missing some critical feature I need to get the data from Git, and I couldn't figure out how to get the data using Git::Raw. Patches welcome!
The release is a version 0.001, as I expect the interface to have some rough edges that need some polishing. Depending on the feedback I receive, a version 1.000 should appear in a few months.
When ramiroencinas added FileSystem::Capacity::VolumesInfo to Perl 6 ecosystem I've spotted that it has no macOS support. And while trying to contribute to this module I've discovered how less known Perl 6 features can save the day. What FileSystem::Capacity::VolumesInfo module does is parsing output from df command, which looks like this:
Update: OSCON have supplied us with a discount code for unlimited free Pavillon Plus passes to members of Perl related organisations and the broader community. Just use the code: FREEORG. Use this code when registering for the Pavillion Plus pass and it will zero out the balance. You can register at: http://conferences.oreilly.com/oscon/open-source-eu/public/content/pavilion-pass - thanks to OSCON and O'Reilly for providing this.
This year OSCON, Europe, will be held in London between the 17th-18th October (with a training day on the 19th), the Perl Foundation will once again have a table in the not-for-profit pavilion. As at previous events volunteers will be manning the Perl stand throughout the day on the Monday and Tuesday and they will also be available in the early evening.
So the dilemma today is to decide what to call my next series I guess Dist-Pen would be an apt name and now to come up with some catchy titles and imags.
I spent a good little while looking at the fancy new (at least to me) distribution helpers out there and I have made a decision on which one I am going to use with accessor.
Well I have already abused 'ExtUtils::MakeMaker ' over the years so I will not lear much from playing with that one.
As for Module::Build I did play with that for a bit because it is Pure Perl and I have a Windows box but it did not play out the way I wanted. It will not get ne around the fact that I need an 'nmake' installed on my windows box. So I left this one in the dust.
Almost a year ago, I wrote CPAN tutorials. It isn't an original work, it's a derivative of RubyGems Guides, only "translated" to Perl world. I failed to publish it anywhere until now. I'll be happy if anyone finds it useful in any way which the license allows. And I'll be even happier if I get any feedback.
