Perl 6 CaR TPF Grant: Monthly Report (May, 2018)

This document is the May, 2018 progress report for The Perl Foundation's Perl 6 Constant and Rationals Grant.

Tangibles Produced

This month I was working in docs and roast repos, in separate car-grant-midrat branches. So far, they contain 29 documentation commits and 11 spec commits adding about 5,824 words of documentation and 152 tests.

The tests specced the MidRat type. The documentation, along with documenting MidRat/MidRatStr types, centered largely around new Language/Numerics page that describes all of the available Perl 6 numeric types—including native and atomic numerics—their purpose, properties, and hierarchy. This guide was not on the list of deliverables of the Grant and has been produced as a bonus item.

General Info

I started the grant by working on adding the proposed MidRat/MidRatStr type pair. This was the most contentious part of the Rationals Work Proposal that before the grant underwent three revisions, settling on solving the problem by adding the MidRat type.

Baby Moose About to Stand

Its actually do something day here in the Moose-Pen

So yesterday I left off with my Driver::DBI generating this SQL code;

INSERT INTO user (address,username) VALUES(?,?) 
now I actually have to get that to run against a DB. I have the first DBI part done the prepare and it works

    my $sth;
    eval {
        $sth = $dbh->prepare($sql);
    if ($@) {
       return 0;
as I get this result

ok 1 - Create function
from 10_crud_basic.t So what I have to do next is bind and then execute that SQL statement so using that handy 'params' attribute I added a few days ago I can a simple iteration like this;

eval {
        $sth = $dbh->prepare($sql);
 ++       foreach my $index (1..$self->param_count()){
 ++        $sth->bind_param( $index,$self->params->[$index-1]->value );
 ++       }

Swiss Perl Workshop - Announcing Ovid + Call For Papers

We are very happy to announce Curtis "Ovid" Poe as Keynote Speaker for the Swiss Perl Workshop this September in Bern. Join us and learn from his experience as a developer, and maybe also on his journey as a space traveler; take off to Tau Station with Perl!

We encourage you to submit talks and we welcome a broad range of subjects, your talk does not have to be specifically Perl related. Share your experience with others, be it your daily messing around with bugs or rocket science!

We look forward to seeing you in Bern this September.

Great thanks go to our sponsors, who have already commited to the event:

Baby Gets Going

Finanlly a DBI codeing day here in the Moose-Pen

So after yesterday's little review I finally got to do some coding on Driver::DBI and the first thing I got working was my '00_load.t' test case. All I needed to do with the present sate of the code is add in;

my $in_hash = { 
++                           da_compose_only=>1,
                view => { name  => 'name' }};
to that test case and the error I was getting from DBI;

BD::ExampleP::db prepare failed: Syntax error in select statement ("1") at 
went away. Now the error was caused by this sub in Driver::DBI

sub _select {
    my $self = shift;
    return 1;
which is just a stub in for now until I get more code written. Really all this test was suppose to prove was that DBI, and Database::Accessor where loaded and the Accessor could find and load in the Database::Accesor::Driver::DBI code. Now before I started on the next tests case I noticed from yesterday this call

      if $self->da_warning();

Parsers and their useful power

I have posted a new entry on the Ocean of Awareness blog: "Parsers and useful power". I look at what parser users want and what makes a parser successful, in light of the 1960s contest between the Irons parser, the first ever published, and recursive descent. One of those is very much with us today, and one survives only in the literature.

For more about Marpa, my own parsing project, there is the semi-official web site, maintained by Ron Savage. The official, but more limited, Marpa website is my personal one. Comments on this post can be made in Marpa's Google group, or on our IRC channel: #marpa at

Moose Tall Tale

Just another quire review here at the Moose-Pen

Yesterday I summed up what I was up to over the past month or so since I left the Dist-Pen, So tadoy as I am rather sort on time I will just do a quick post-ette on the state of Database::Accessor::Driver::DBI.

Well just for kicks before I revisited any of the Driver::DBI code I re-ran the the very limited test suite of two test case and got a full fail, so I guess every thing is broken.

Looking at the code the first think I noticed was that I have this sub

sub _warn {
my $self = shift;
my ($message) = @_;
warn("Database::Accessor::Driver::DBI: $message ");

Which I was using to key of this DA flag 'da_warning' now what I think I will do is hop back to 'Database::Accessor::Roles::Driver' and add this in

      requires 'DB_Class';
      requires 'execute';
++    requires 'da_warn'; 

Baby Moose Starts Out Aagain

It is cheap clip show day here in the Moose-Pen

Now that I am finally finished with Database::Accessor for the moment as since my last post all my tests are passing, I think it is time for a quick recap of what when on since this post when I left the Dist-Pen and started up the Moose-Pen.

The first few post I set out on writing my first Driver::DAD, I worked out some name-space issues and finally came up with Database::Accessor::Driver::DBI rather than SQL as most DBI drivers run on SQL is just seemed locgial.

The second set of posts I started to write up my Driver::DBI and ran into the problem very quickly that I needed some sort of DBI DB present on the current box to do any testing. I solved this as 'DBD::DBM::db' comes with DBI so I decided to use that for my testing. I even got one or two test cases written and a little code done.

CPAN Testers at the Perl Toolchain Summit 2018

I made a lot of progress on CPAN Testers at this year's Perl Toolchain Summit (PTS). The PTS is an annual event devoted to maintaining and improving the Perl toolchain. The Perl toolchain includes things like: 1.25 Changelog

This release contains a lot of little bug fixes, so I thought I'd blog about it. I hope I didn't break anything but you should be aware that chances are a bit higher than usual. Please test!

At the Perl Toolchain Summit I decided to work on trailing comments for, and then I felt like digging a bit deeper into other bugs.

Baby Moose Move Out

Just cleaning up the Moose-Pen today.

I left off from yesterdays post with few more tests to clean up and a new one or two to write up. Might as well get the low hanging fruit first and that is this error;

Can't locate object method "dynamic_conditions" via package "Database::Accessor::Driver::Test" at 43_dynamic_conditions.t line 54.
and the change was a very easy removal of that 'dynamic_' from the test;

    $in_hash->{conditions},     $da->dynamic_conditions(),
--    $dad->dynamic)conditions(), 'dynamic conditions'
++    $dad->conditions(), 'dynamic conditions'
and to carry on with this one I had a look at the other test cases that used 'deep_predicate' and got '47_dynamic_gathers.t' all fixed up in one go as well. The little nasty was this one

Can't locate object method "dynamic_links" via package "Database::Accessor::Driver::Test" at D:\GitHub\database-accessor\t\lib/Test/Database/Accessor/ line 94.

What's happening with DBD::Oracle?

For $work reasons I have had to do a lot of work with DBD::Oracle.

Master in github has a lot of floating changes ( since the latest release (v1.74 see

There are also a number of PR's aged by several years, of which I found many helpful and have curated into a new PR which applies cleanly against master (see

Whilst I have no interest in adoption DBD::Oracle, I am interested in a new "official release" so am curious who's out there using it?

FWIW In the wonderful world of travis and docker, it would be neat to spin up all sorts of testing. I investigated for a few moments but the Oracle docker images still require you to download the SDK zip files (requires account) and insert them

Baby Moose in a Pen

Still stuck in the in the Moose-pen today.

Since I decided in yesterday's post to make one more round of changes I am a little closeer to getting back to Driver::DBI but not much.

For today's changes I decided to go full out and re-factor a good chunk of the common code between and any DAD that I might write. Not to bore you with reamls of code pasting you will never read I will give you the over-view.

First action was to strip out the attributes from Database::Accessor::Roles::Driver and Database::Accessor that where the same and put them into a new role 'Database::Accessor::Roles::Common'. My Driver Role is now just a few lines


        use Moose::Role;
        with qw(Database::Accessor::Types
        use namespace::autoclean;
        requires 'DB_Class';
        requires 'execute';
The first problem I had to fix after I moved all the common elements between and a Driver was this;

Baby Moose almost ready

Test case clean up day today in the Moose-Pen

All those changes I introduced in my last post did quite a job in mucking up my test suite as the latest run results show;

Files=27, Tests=328, 39 wallclock secs ( 0.24 usr  0.06 sys + 36.90 cusr  1.92 csys = 39.12 CPU)
Result: FAIL
Failed 9/27 test programs. 37/328 subtests failed.
The first thing I noticed was not a fail in a test but this warning;

Use of uninitialized value in string eq at …/lib/Database/ line 37.
coming up all over the place, I should of caught earlier but that is why we run tests. A little change in my 'around BUILDARGS' sub;

            $element->{view} = $view_name
              if (!exists($element->{expression}) 
                 and !exists($element->{function})
                 and !exists($element->{value})
--                 and $element->{view} eq undef );
++                 or ( !exists($element->{view})
++                 or $element->{view} eq undef ) );


I recently decided to try to create a CPAN module I thought might be of interest to the community.

Having gone through the steps necessary to create an account and having read the admonition to seek input before adding needless modules to CPAN by posting on PrePan I was a bit disappointed to find that PrePan is not very active.

Is PrePan still a viable channel for vetting ideas or is there a different path? If so, the CPAN instructions might want to suggest the alternatives for bouncing ideas off the Perl community and embracing new folks to contribute to CPAN.

As an aside, I also volunteered too adopt a module by sending the requisite email to the author but never heard back. It's these kinds of experiences that tend to make me wonder why I don't heed the advice of everyone around me and switch to Python where the community is much more vibrant and less disorganized in general.

Having said that, I respect all of the people in the Perl world that have given so much of their time and energy to creating a useful ecosystem for application development. To those who are active in the Perl community and volunteer their time to create working tools without any pay or recognition I commend you.

Announcing The London Perl Workshop 2018

The London Perl Workshop (LPW) takes place this year on Saturday 3rd Nov at the usual place of The University of Westminster's Cavendish Campus. You are encouraged to submit your talk proposals now, or if you have already feel free to submit another.

Talks may be long (45-60 mins) short (15-20 mins) or very short (lightning talks, 5 mins); however given the feedback after last year's LPW we would prefer, and will probably favour, shorter talks. We would also be pleased to accept proposals for workshops, tutorials and discussions. The deadline for submissions is Sunday 16th Oct.

We would really like to have more rookie speakers this year. If you’d like help with a talk proposal, and/or the talk itself, let us know - we’ve got people happy to be your talk buddy!

Register (it's free!) and submit your talk at:

We hope to see you there,

Pete, Rick, Lee and Katherine (the organising team)

Baby Moose Promise

It is keeping promises day here in the Moose-pen

Keeping in step with yesterday's post I am continuing with my code-review of It was suggested that I explain a little more on my reasons for doing most of the validation on the side rater than the DAD side so here we go.

As today’s title suggests I want to make a promise to the DAD from the that all the attributes that I have passed down to it are ready to go into a the requested CRUD query, so only a minimal amount of extra Database::Accessor::Driver logic is required.

What this mean is that I will have to carefully explain to potential users that the Update and Create methods only work with the initial set of 'Elements' and only with elements that have the same View. I have already did this one in yesterday's post.

Backtracking Baby Moose

Well no progress day here in the Moose-Pen

After yesterday's post where I decided to much more validation on the Accessor side of things I had a chance to takke a deep and close look at

A code review is always a good thing and I found a few problems right from the start, in mose of my CRUD functions I was still doing this

return $container; 
which is dead wrong and funny thing I did not have a check for this. So today I added that in with a simple change to 20_dad_load.t

ok($da_new->$type(Data::Test->new(),$container),"$type Query ran");
--ok($da_new->$type(Data::Test->new(),$container) == 1,"$type Query ran");
now I will get a fail if anything other than '1' is returned and as I am using canned data I know this will be the case. The good thing as this ran I got this fail

not ok 4 - Role DAD can all_elements_present
so I had to make this change;

Baby Moose Back Again?

Well its post-ette day today here in the Moose-Pen

Yesterday's post I managed to make a very small start on my Driver::DBI before I figured it would be a good idea to do more of the param validation on the Accessor side rather than the driver side. That way I know I will not run into the situation where one Accessor/Driver combination works differently than another.

The validation rule for today is on the $container param for both the Create and Update and is as follows;

'Each element in the elements array that has the same view as the DA class must be present as a key in a Hash-ref or as an attribute in Class container. This rule is not on by default but is to be turned on only when the all_elements_present flag is true.

So to get the above in place I will need to add in that new flag here;

   has [
 ++       all_elements_present

My report of the Perl Toolchain Summit 2018 in Oslo

This year, to my surprise, I was again invited to the summit, on short notice.

Again, I was able to visit a city I have never been before and hack four days on YAML and other stuff.

No Baby Moose Steps

Almost some code day here in the Moose-Pen.

Not much code today unlike yesterday's post where I changed eighteen files and checked in one new one.. Today I had a look at how I am going to proceed with Driver::DBI, With all the changes I made to I have some rethinking to do with Driver::DBI

I will now have to

  1. work with a results class
  2. capture any errors into the appropriate attribute of that class
  3. set the appropriate class attributes on success
  4. set the appropriate class meta attributes and
  5. check for any flags that may be set for special processing

Not a big deal really I thing this will really work out well. As for testing I think I will keep 10_crud_basic.t for now and just get that one all passing before I move onto more complicated queries and proccessing.

About 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.