blogs.perl.org

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;

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.

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:

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.

Still in mop up mode here in the Moose-Pen

I finally found a way (well not a good one) to generate an even better error message to my end users. You are of course quite familiar with this type of message;

Database::Accessor add_condition Error:
The following Attribute is required: (Element->name)

With constructor hash: { 'operator' => '=', 'left' => { 'view' => 'People', 'name' => 'last_name' }, 'right' => { 'left' => { 'name' => 'salary' }, 'right' => { 'expressionx' => '*' }, 'function' => 'LEFT' }, 'close_parentheses' => 0, 'condition' => 'AND', 'open_parentheses' => 1 } Very hard to find out that it is the 'expressionx' that is giving us grief. With the changes I have just completed I now get

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.

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

Sponsors make it possible for us to run LPW without charging for tickets, and as an organiser last year Pete Sergeant knows just how important this is! Thank you Perl Careers for your ongoing support.

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 {

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?

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!

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.

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;

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

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:

• Finding Users for Your Project
• How to self-promote your open source project/li>
• How to promote your Github project
• How to promote your open source project
• many many more

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.

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;

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.

Here is the coverage of Faster.xs in the module Gzip::Faster:

http://cpancover.com/latest/Gzip-Faster-0.21/Faster-xs--branch.html

It suggests that most of these statements aren't tested. But actually they are, more or less.

What seems to be happening is that SvTRUE is a macro with about five or six different tests:

https://github.com/Perl/perl5/blob/blead/sv.h#L1761

and so to get "coverage" of all the SvTRUEs here I'd need to send a string, an integer, a floating-point number, and so on and so on. But would that actually tell anything about Gzip::Faster? In fact it wouldn't. It would just be testing whether SvTRUE from Perl's core was working correctly or not.