Well seven more sisters to have a look at in today Dist-Pen
# FIXME – Replace this with a fractal algorithm
A new trial of Log::Any (1.044) has been released. This release has a couple changes that make Log::Any a bit more predictable:
use Log::Any '$log') can now be named anything (like $LOG or $foo).Since CPAN Testers is still catching up from its little bit of downtime a few weeks ago, I won't be releasing this as stable until I get some success reports in. So, you've got some time to test this against your own codebase if you need to. Please report any issues to the Log-Any Github repository.
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!):
sub _get_json_columns ( $self, $schema_class ) {
state $json_columns_for = {};
unless ( exists $json_columns_for->{$schema_class} ) {
my $columns = $self->schema->resultset($schema_class)
->result_source->columns_info;
$json_columns_for->{$schema_class}
= [ grep { 'json' eq $columns->{$_}{data_type} } keys %$columns ];
}
return $json_columns_for->{$schema_class};
}
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).
Its plow though some more test plug-ins day again here in the Dist-Pen.
So in my last post had found one plug-in that was useful, today I hope to find another from this list of Dist::Zilla::Test plug-in
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 DateTime locale 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.
Yeah another test play-date here in the Dist-Pen.
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.
So my first batch of test plug-ins for today are
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:
Hey everyone,
Following is the p5p (Perl 5 Porters) mailing list summary for the past two weeks.
Enjoy!
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!
“The covers of this book are too far apart.” ― Ambrose Biercehmm criticism, of a fashion, but not much good to us in the Perl world, I much prefer;
“Criticism may not be agreeable, but it is necessary. It fulfills the same function as pain in the human body; it calls attention to the development of an unhealthy state of things. If it is heeded in time, danger may be averted; if it is suppressed, a fatal distemper may develop."― Winston S. Churchill
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.
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.
Playing with tests in the Dist-Pen today.
On part of Dist::Zilla that I do find intriguing is the way it does its testing. As I discovered in my last post some things only work at release time and that is true of testing as well. Dist:Zilla take the newer extended testing model as a default. In the old days we would call these optional tests and usually hide them in a folder someplace, but the more common usage today is to put them in an '\xt' directory on their own.
One can see the logic behind this as I remember a few times having to do a force install of a CPAN mod as the author had some sort of non-functional test in '\t' that would not pass on my perl.
Dist::Zilla this concept a little further and splits it into four types;
I love the new "pick" method of lists in Perl 6. Here's a handy Shakespearean insult generator (cf https://kyclark.gitbooks.io/metagenomics/content/arrays.html):
This week marks 2 years since TOBYINK seemingly dropped off the perl map, in terms of viewable open source contributions that is. Since then the author's modules have gone unmaintained, consequently they are no longer compatible with recent versions of perl. This is going to cause problems eventually.
I, and several others, have sent e-mails to TONYINK but have not received any response. So TOBYINK, where are you? Are you OK? You seem to be active in at least one place? Can you give co-maint on some of your modules that are used or recommended in more widely deployed distributions? Some of your modules are too important to leave to abandonware, and forking them is a path i (and almost certainly others) don't want to take.
Edit: Some non-essential information removed as i don't want to give people bad ideas about compatibility between Moo/Mouse/Moose due to the use in our stack.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
