Another Post-ette here in the dist-pen today.
As we have seen in my last post Dist::Zilla is really good at doing all those boring yet important chores for you distribution, today I am going to look at another the Changes file. All distributions should have a changes file though I would guess there are quite a few without. I do not think there is any standard format out there but usually it is just something akin to
Revision history for xxxx
Changes in xxx.xxx
Dancer2 0.204001 is on its way to a CPAN mirror near you. There are several important updates in this release that are worth noting:
Support for Perl 5.8 support has been restored. We used a named capture in a regex in resolving an issue in Dancer2 0.204000 and in the process, made Dancer2 unusable on Perl 5.8. This has been fixed. Thanks veryrusty!
Dancer2 0.204000 unintentionally required that Test::Perl::Critic be installed, and that we pass Perl::Critic tests to install properly. This has been reverted. We apologize for the inconvenience.
The full changelog is here:
A quick search at github on something like Perl/Bash scripts gives me a lot of results.
As developers we more think about modules and libraries when talk about software reuse. But in our day-to-day life scripts still take a vital part. Scripts like little, but useful commands to get our job done. This is why people from many programming languages/environments tend to create a places for such a tools called repositories, so other could easily find, install and run scripts or utilities. To list a few:
Well. A SparrowHub is a attempt to make a such effort in Perl communities to create a repository of useful automation scripts. Sparrow is Perl friendly in many ways:
Well let me now turn to the essential point of my post.
Less than two months after the release of version 0.2, I can announce the release of version 0.3 of Perl Executing Browser (PEB) - our minimalistic HTML GUI for Perl desktop applications similar to Electron and NW.js.
The new version introduces strict separation between trusted and untrusted content, which can not be mixed together in one browser window. Local content and scripts, as well as all Perl-related functionality stay separated from untrusted web content in different browser windows for enhanced security of all PEB-based Perl applications.
Version 0.3 is also capable of starting Linux superuser scripts using 'gksudo'.
As usual, any feedback and suggestions are quite welcome!
Just a post-ette today on the Dist:-Pen
A few more little plug-ins to add to my '.ini' today and again these are largely house-keeping chores and like all chores they are never fun to do and easy to ignore or bugger up.
What I am talking about are the Meta files that should be released with each distribution to be put on CPAN. The first files I am going to look at are Meta.yml and Meta.json which should both contain the same data but only differ in format. Sometimes I have made a mistake and forgotten to update one or the other or forgotten some important information in the file. Judging from this page so do many many others so automating their creation with Dist::Zilla will take one more thing off my plate.
All I have to do is add in the two plug-ins into may '.ini' MetaYAML and MetaJSONDBD::SQLite 1.51_06 (with SQLite 3.15.0) is a release candidate of the next stable DBD::SQLite. As always, please test it with your modules/applications and let me know if you find anything, especially if you're using FTS because DBD::SQLite has disabled two-arg fts3_tokenizer() for security concern from the upstream. If there's no blocker nor request to wait, I'll release 1.52 in the mid November.
See Changes file in the distribution for other fixes and improvements, and see also https://www.sqlite.org/changes.html for the changes in SQLite library.
I've recently read a promo article about a static C/C++ analyzer called PVS-Studio by viva64.com, where the readers were urged to use the product, and I did just that. Evgeniy Ryzhkov, the creator of the program kindly sent me a one-week key, and I immediately started testing some of my C/XS code.
I'm also using valgrind and was rather sure that all major problems were long gone, but how wrong I was. There were also a couple nasties, in cases not covered by tests, and thus valgrind had no chance to detect them. There were also a couple of WTFs, such as
void * x = result(); x-> something++; if (!x) return;
where the logic was clearly there, but somehow on wrong lines. A shame really.
Current State
rakudo.js (Rakudo compiled to JavaScript) compiles 70% of the core setting.
I'm working on getting it to compile the whole setting.
The setting executes a bunch of code at compile time (it has BEGIN blocks, constant declarators etc.) so the code the compiler is generated is validated to some degree (the test suit will exercise it much more).
I'm mostly fixing bugs, and implementing missing features in the backend (most are small some required bigger changes to the way we handle things, like nqp::attrinited).
While doing that I'm also expanding the nqp test suite so that new backend implementers have an easier job.
What's left?
Fixing bugs and missing features found while running the test suit.
Writing a tutorial and making rakudo.js more usable (making sure the source maps are correct, it installs easily, the error messages it produces are usable etc.).
When it will be done?
A large part of the work remaining is bug fixing so I find it hard to provide a reliable estimate.
I hope to wrap things up by the end of the year.
Today in the Dist-Pen I am going to have another crack at a different Versioning technique.
In my last post I had a look at using Dist::Zilla::Plugin::PkgVersion and I found it very useful but in the end I ran into a problem with putting all my Database::Accessor classes into my Accessor.pm file.
I wanted to see if I could have differing versions within the same file and the short answer was 'No' but the long answer was 'Yes'. I did play about with 'Dist::Zilla::Role::PPI' to see if I could adjust it to what I wanted it to do.
Well after a little while of poking about I did manage to get it to work the way I wanted but it was a hard-coded Kludge which I think could evolve into a patch. Now before I started to go down that rabbit hole I noticed there was an IRC for Dist::Zilla so I asked a quick question there before I created the patch.
It’s by no means complete, but it’s available for trial from your friendly neighborhood Panda installer. This tool uses Perl 6’s own internal parser in order to generate a parse tree for Perl 6 code, and has enough information to reconstruct the original Perl 6 source, complete with whitespace and comments.
perl6-Perl6-Parser is available in the ecosystem for trial. It’s very much rough around the edges, and can so far handle only a relatively narrow range of Perl 6 code, but that will quickly change, I’m sure. Once it’s further along you should be able to integrate this into things such as pretty-printers, editors, syntax highlighting and other tools. It takes compilable Perl 6 source and generates a tree of Perl 6 objects, which themselves have a .perl6 method to return the original Perl 6 source. Or feel free to override the .perl6 method and format your Perl 6 code how you want it.
Hey everyone,
Following is the p5p (Perl 5 Porters) mailing list summary for the past two weeks. Enjoy!
So I'll confess that I've had a big crush on Haskell for a couple of years now. I've tried and failed many times to really get beyond trivial code, but I'm utterly fascinated by the code one can write with strong, static typing. It can feel contrived at times and very constraining, but I can definitely see the benefits, which is why I'm so excited that Perl 6 has (gradual) types!
In the Dist-Pen today I am looking at another plugin to help with my many versioning woes.
In my last post I had a look at a Dist::Zilla plugin that helped me out with versioning my distributions. Today I am going to see if there is a plugin that will help me out with my Module versions as well. So a quick look about and I see we have a few options so I will start with the most likely candidate 'Dist::Zilla::Plugin::PkgVersion'
Like all the Dist::Zilla plugins I have used so for this one is quite simple; Just add
[PkgVersion]
Fresh off of Perl.Dance 2016 is Dancer2 0.204000. The latest version of Dancer2 is on its way to a CPAN mirror near you.
This version brings some compelling enhancements and features:
You can now create a local version of your configuration files which you then do not need to commit to any repository. If you create a file called config_local.yml, you will have a local config.yml. You can do the same with any configuration file, just change the filename to end with _local.
You can now set the DANCER_CONFIG_EXT environment variable in order to only load configuration files of a particular type (such as JSON). For example: DANCER_CONFIG_EXT=json plackup bin/app.psgi
You can now get some diagnostics information about loaded conifguration files by setting the DANCER_CONFIG_VERBOSE environment variable to a true value.
Last weekend I completed an article about deploying my personal Perl projects using Dokku - it might be interesting if you have similar needs!
A labmate got a FASTA file of sequences that had a mix of amino acids and nucleotides that she wanted separated into separate files. Here's a little script to do that. Again, I wish there was an easier way to get the basename for a file that does not have the extension.
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 hadDue to a dispute on the exact nature of the future of DBIx-Class development after Peter Rabbitson's pending departure, a conversaton has been opened on the DBIx-Class mailing list to feel out what the users of DBIx-Class think.
If you have an interest in the module and its future, please have a read of the current sitation, and maybe leave a note on your position:
In order to leave a comment of your own, you can subscribe to the mailing list here:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
With David Golden's permission, i reproduce a copy of his email below:
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:
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.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
