laying with another seven sisters here is the Dist-Pen today
Well the good news for today seems Dist::Zilla::Plugin::Test::Legal is finally pointing to the correct version at meta::cpan I guess if finally got indexed. Now on with today’s review of seven more Test case Plug-ins.
An 'Author' level test case that implements Test::Pod::No404s this is one for me as I can't tell you how annoying it is to have links that point to nowhere in your POD. So after the usual five minutes or so of installing from cpan I added
I started gathering requirements for the next version of Asciio which will probably be written in Perl6 (Go is a strong contender albeit not as much fun)
Help by adding your requirements as an issue at https://github.com/nkh/Asciio-2.0
Integration with Ditaa is on the list since someone made most of the work, without even contacting me once. http://wiki.cornempire.net/_media/asciiart/diagram2.png
SVG output will be via a2s, https://github.com/dhobsd/asciitosvg, as the author is already an asciio user and some of his users are too.
As of the 7th November 2016 Karen Pauley has officially stepped down as President of the Perl Foundation. Replacing Karen at this present time will be long standing Perl Foundation member Jim Brandt
So that is how it is officially announced and let’s quickly move away from such formal tones for the rest of this article.
It is with a great sense of melancholy, and probably an even profounder sense of respect and gratitude that I am writing this piece so please bear with me if the style seems somewhat stilted or unusual. I know that some people will feel regret at the loss of Karen, I want to stop you all now, don’t think about what we may be losing, think of the changes that have been made.
Passing in objects to formatted log methods now handles objects that overload stringify correctly. Previously, these objects would be given to Data::Dumper, which violates object encapsulation. Thanks Philipp Gortan (@mephinet)!
The imported Log::Any object (use Log::Any '$log') can now be named anything (like $LOG or $foo).
After getting my Legal test to work in yesterday's post, funny thin is metacpan still show ver 0.02 as the latest not 0.03 for some reason, I am going to plink away at seven more sisters today;
This one is a 'Release' test case for those out there that will do not automatically increment their version in some way. At this point I want to try, once I get all my testing in order, to use the Dist::Zilla::plug-in::Git::NextVersion plug-in so I will leave this one out for now, but will keep is in the tool bin just in case I can't play nice with my GitHub account.
The shader is a modification of a shader by Inigo Quilez, hacked up by Weyland.
After the initial rush of success, I spent this week working more on the UI side
of the app, putting off adding support for geometry generation for later.
Prima proves to be a solid UI toolkit and to me it feels closer to using Delphi or Visual Basic, API wise.
There's no question that DBIx::Class is the dominant ORM in Perl. That's because it's fast, it's flexible, and sane. Well, mostly sane, until you need some introspection (if anyone knows a better way to do this, I'm all ears!):
But what's terribly frustrating to many devs is getting DBIx::Class to show the queries it's executing, along with the bind parameters (one without the other is often useless).
And suddenly I remembered that I promised myself, at YAPC::EU, that I would write a tmux plugin to implement a yakuake like pane handling.
With some time and energy on my hands I created a directory, initialize a repo and was on my way to write some perl. I took one hour to draw a few ideas and that's when GranPa Bash knocked at the door.
I know, you know, everyone knows that Perl build a lot on bash, at least its syntax, and in this very case it seemed to me that writing this in Bash would be better. It's mainly command calling, there is no complicated process to map, it should be quite easy in bash.
And I was in the mood!
Every second year I beat myself up because I always refuse to learn more sed or awk. It's not that I don't use them, it's just that every time I do, I get so frustrated that I end up writing some Perl.
This post was originally going to be an exhortation to potential speakers, to take the plunge and submit a proposal to the London Perl Workshop. I thought I could list some generic types of talks.
Then I realised I'm not entirely sure what kind of talks everyone is going to want to attend. So instead, I'm asking you, particularly if you're going to be at the LPW:
What talks would you be interested in attending?
Lessons learned developing modules? Comparisons of similar modules? How to use specific modules (which ones?)? Do's and Don'ts when developing with Perl (frameworks)? Experiences transitioning from Perl 5 to Perl 6, or vice versa?
Please add comments with the kind of talks you're interested in, as that might encourage people to submit talk proposals.
I have been granted co-maintainership of DateTime-Calendar-Christian, and version 0.04_01 went out October 30. Because this module is new to me, and because this is the first release in 13 years, I would like to encourage anyone with an interest in it to try out the new release and let me know of any problems.
The current release migrates the module to the DateTimelocale interface, replacing the long-deprecated and recently removed language interface, and adds a today() instantiator. I hope to see enough CPAN testers results by the weekend to give me the confidence that I can do a production release
The plan is for subsequent releases to clean up the code, upgrade the metadata, and implement the DateTime interface more fully.
For a long time, I've wanted to actually make use of the modern hardware I have at home. The graphics card is capable of OpenGL and OpenGL now has a fancy little language to actually bring images to life. For example [https://www.shadertoy.com] has great so-called "shaders" that show off what can be done with them.
Because I also want to toy around with programming some shaders, I want to get a live environment running. So during the weekend, I took the Glew library, wrote a small Perl script to convert the header files to XS, and then fought with OpenGL until I had a driver that could run shaders from Shadertoy.com:
CPAN::Changes
A 'Release' test case that will run 'Test::CPAN::Changes' so in-effect does the same thing as 'Dist::Zilla::Plugin::Test::CheckChanges' not one I am going to use.https://www.cpan.org/modules/04pause.html#before
CPAN::Meta::JSON
A 'Release' test case that will run '
Test::CPAN::Meta::JSON
'. Now in my distribution I am using the MetaJSON plug-in which generates my Meta.Json so I see no need for this one either.
In bioinformatics, we get data from the sequencing centers usually in BAM or FASTQ format. One of the first steps is to QC the data to remove any reads that have very low quality or which are too short to use. Some sequencing technologies read from both the beginning and the end of the sequence in opposite directions, and so you need to put the reads together. Quite often one of the directional reads (forward or "R1", backward or "R2") are lost to QC, and so those are considered "singletons" that can't be paired with their read mate.
The boss wanted me to write a read pairer in Perl 6 for our class. Challenge accepted! Below is a decent working version, but it's dog slow ("dog" being Mississippi for "very"). Comments welcome!
Rakudo.js managed to parse (including running BEGIN blocks) all of the setting with an exception of one line that requires figuring out/measuring how to support uncached methods efficiently. (uncached methods are ones where we let the HOW handle the method call by running arbitrary code rather then installing a bunch of methods at once).
Generating the js code for the setting uncovered some performance issues like overflowing the stack by recursing too much (fixed) and running out of memory (not yet fixed).
I'm now focusing on getting a small prefix of the setting to fully compile and load so that I can use it measure and optimize the memory usage.
Playing with testing and Dist::Zilla over the last few posts has not only introduced me to a the newer 'Perlish' way to ogranize your test cases but I have seen a good number of plug-ins that might be interesting for me to add into my '.ini' file. Now besides the two I really wanted and have added in '[Test::Kwalitee]' and '[Test::Perl::Critic]' I know very little about the others so I am just going to plow though them alphabetically.
As Perl 5 module authors, we were able to allow selective exporting easily by use of the @EXPORT_OK array where we listed all the objects that the user of our module could import by name, thereby giving the user full control over possible namespace clashes. However, in spite of all the new goodies provided by Perl 6, that feature is not yet available to us Perl 6 module authors. (For more information see issue #127305 on https://rt.perl.org.)
But the good news is there is a way to get the same effect, albeit with a bit more effort. The trick is in using the full power of tags with the export trait available with every object in a module.
One might get a little glassy-eyed when reading the Perl 6 docs concerning module import and export, of which a portion of code is shown here:
I've been working on some slightly complicated code with a myriad of
bad design decisions over the course of a decade, and a total absence
of test suite. I knew I needed some code reusability in my tests but
I had no idea of exactly how much without making a quick start.
Meanwhile my brain was filled with ancient code from which I was
expurgating zombies, and had issues understanding multi-vendor
interactions, so I wanted some bare minimum reusability to make
engineering failure conditions easier.