Moose Can't get a break

Its start the long releases cycle here at the Moose-Pen

Today I am going to examine some of the results I got from my 'Devel::Cover' run.

ffile                     stmt bran cond sub  pod time total
lib/Database/Accessor.pm 94.4 80.0 88.8 93.7 0.0 23.5 91.7
To start I can basically ignore the 'stmt' section as it is very rare to get 100% in there as I am running at '94.4' I will move onto something else. The next col branch has 80% and following that link I get

London Perl Workshop 2018 - Report

LPW2018 Gold Sponsor - Eligo

meta::hack 3 wrap report

We had a blast at the latest meta::hack and we got a lot of work done. Our "greatest hits" have been documented here.

Moose Take a Bow

Another test day here in the Moose-Pen

Today I am going to go though all the tests in my Driver::DBI and see what explodes

Not really expecting a good run I was plesenlty surprised when I got;

\t\20_fields.t         (Wstat: 512 Tests: 88 Failed: 2)
  Failed tests:  86, 88
  Non-zero exit status: 2
\t\90_extened.t        (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 11 tests but ran 0.
only the above two. The first one was simple enough I just had the wrong value in a regex on the test and a quick change;

The Exception That Rather Proves the Rule

I had really wanted to stay out of the recent commentary on CGI. I really did. I was going to be able to until a recent article was published in which the authors try to step in on the side of CGI. I believe the authors to be talented perl developers posting in good faith, but the result really pushed me to reply. The application developed as a case for CGI and preventing “overkill” is a perfect example of why a framework is needed.

Don't use something or another

Seems like a lot of people are keen on telling us not to use CGI.pm, but rather use something else. These discussions seem to verge on religious fervour, with each side finding small problems with CGI.pm or its alternatives, and then telling us that these small problems are actually the end of the world.

I don't use CGI.pm, I haven't used it for at least ten years, and I'm not about to defend it, but since we're all telling people not to use something, I thought I would chip in with something which I don't think you should use.

Since about 2006 I've been running a web site which offers to convert Japanese numbers into other kinds of numbers, and vice-versa. For most of those years until relatively recently I was using Lingua::JA::Numbers by Dan Kogai. Dan Kogai's module uses a methodology of converting the numbers by changing Japanese numbers into digits then sending the digits into an "eval" statement to compute the numeral value of the numbers:

London Perl Workshop 2018 - happening this weekend

There is less than a week left until the 2018 edition of the London Perl Workshop on Saturday the 24th of November.

If you have not signed up but want to come, there is still time to register for your free conference ticket. If you have already signed up, please make sure you have confirmed your attendance and selected a t-shirt size. We can only get a conference t-shirt for you if you've done this by tomorrow (Tuesday) at 12:30 GMT.

Are you already in town on Friday evening? Come to the social event and meet your fellow Perl Mongers. We will meet at The Hope in 15 Tottenham St, W1T 2AJ from 6:30pm in the upstairs room. Drinks at the event are sponsored by Oleeo.

Full Monty Moose

Its big change check-in day here in the Moose-pen

I think there will be very little new code today but I did incorporate a large volume of changes. First I dropped 'Database::Accessor::Roles::AllErrors' as I no longer see any DAD writer ever having any user for it not that it does not throw an error;

The code from that I added into the 'Database::Accessor::Types' and I did not even have to make a single change to the code. I also took out all the commenting out junk code and waring from that class for good measure.

I then went into Accessor.pm and made the following change;

– sub _loadDADClassesFromDir {

++ private_method _loadDADClassesFromDir => sub {

Modern Perl CGI

The contemporarily unique strengths of CGI as a deployment strategy are that CGI scripts ⓐ can just be dumped in the filesystem to deploy them and ⓑ do not have any of the issues of long-running processes: they tie up no resources when not in use and are extremely reliable because of the execution model, in which global state always starts from a blank slate when serving a request and there is no process that outlives the request and could wedge itself. Anyone who consciously chooses CGI over alternative deployment strategies nowadays probably has a fire-and-forget use case where the script will be seeing too little traffic to be worth any effort to tend to it regularly.

Modern Perl CGI

This is a CGI script, let's call it uppercase.cgi:

I'm fully covered

There seems to be a new feature of showing the coverage in metacpan. Fortunately I have already achieved 100% coverage here:

https://metacpan.org/release/Acme-Include-Data

Some other places are not so fortunate.

http://cpancover.com/latest/JSON-Repair-0.07/blib-lib-JSON-Repair-pm--subroutine.html

I only have 33% coverage in my POD.

The thing is though that I deliberately didn't document these private routines.

I looked in vain through what documentation I could find for this coverage system

https://metacpan.org/pod/Pod::Coverage

to find out how to tell it that these routines were never meant to be documented, but couldn't find anything except for a regular expression which ignores routines with a leading underscore.

Can anyone tell me how to tell the coverage meter to not measure these routines?

Every Moose has a bad day.

Another sad day in the Moose-Pen

Not a good way to start another year of blogging as I was reviewing my tests and when I got into '47_dynamic_gathers.t' I was getting a duplication on the number of conditions on a gather which is not a good thing.

Somewhere in the last few days I really buggered something up.

Well after much hair pulling and debugging I finally stumbled into it. It seems I have added so many warns and comment out code over the past few days I was playing with subs that look like this;

Charlotte Perl Mongers meet-and-greet

If you're a Perl developer in the Charlotte, NC area, come to the first social event for the Charlotte Perl Mongers! For more details, or to RSVP, check us out on Meetup.

Hope to see you there!

curl2lwp - convert Curl command line arguments to LWP / Mechanize Perl code

After inspiration by a comment on Perlmonks.org and some slight hacking, I'm very proud to announce HTTP::Request::FromCurl, together with its companion online site at https://corion.net/curl2lwp.psgi. The module and included curl2lwp program allow you to easily convert curl command lines to Perl code that uses LWP::UserAgent resp. WWW::Mechanize.

London Perl Workshop Schedule

With the workshop just over a week away we have created the schedule. You'll notice we still have room for a few talks, so if you have something you would like to talk about then don't hesitate to submit a talk

We have tweaked the schedule a bit from previous years to start a little later than normal and allow a little more time for lunch. You'll also notice we have a dedicated Perl 6 track and a dedicated "mentoring / beginners" track.

We also have room for more lightning talks and will favour those that are submit early. Note we may tweak the schedule slightly to make room for more talks and/or depending on other factors.

As always, thanks to our sponsors:

- Eligo
- Perl Careers
- CV Library
- Oleeo
- The Perl 6 Community
- Adzuna

Yearling Moose

Final final final clean up day here in the Moose-Pen

Just a quick postette today cleaning up the last of my messages on my error retruns. Starting with this one;

 'Database::Accessor Database::Accessor::add_condition Error:
 The following Attribute is required: (conditions->left)
 With constructor hash:
 {
   'predicates' => {
                     'operator' => undef,
so two thing to get rid of here, get rid of that 'Database::Accessor::' in front of 'add_condition' and change that constructor has so it dose not show that hidden 'predicates' key the first fix is easy enough;

Promoting Perl

After this weeks discussions about naming a shovel a spade, and how that would increase sales in the hardware store. I hope to start a substantive discussion around promoting Perl.

Dear Reader, please don't let the above metaphor become a stumbling block. Your ingenuity is desperately needed.

The first hypothetical question I would pose is:
  • If you had $10,000 to promote Perl - what would you do with it?
Please don't get lost on the dollar figure. This is intended to be an exercise in stretching the imagination. Another question pair is:
  • What meaningful metrics could be used to measure Perls growth? (github stars? ithub commits? cpan releases? others?)
  • What activities could be co-ordinated and performed, that would increase these key metrics?
A quick Google search (or, DDG) provides many peoples thoughts about growing open source projects:

Rakudo.js update - running tests in the browser using Karma

After fixing some strangling bugs and implementing some unimportant but fickly to implement
features rakudo.js now passes our targeted test subset. Some of the fickly features where
things like basic support storing fetching and ++'ing int64/uint64 variables etc. (rakudo.js is 32bit because that's what fits into basic JavaScript numbers).

Focus has now moved to running the roast tests in the browser itself.
For this I'm first precompiling the test files (which has it's own share of problems that I'm working around as rakudo doesn't yet fully support precompling scripts only modules).
For example all the compile time deps are recorded with a custom CompUnit::Repository
Then I'm bundling them together with parcel into a single .js file.
I'm running it with a Karma runner and Headless Chrome.
When running under karma the nqp runtime intercepts the TAP on STDOUT and reports the results to the karma harness.

LPW2018 Gold Sponsor - CV-Library

This year the ongoing support of sponsors such as CV-Library have meant we’ve been able to add conference t-shirts for attendees. Thank you CV-Library for your continued support of the workshop and local Perl community.

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.