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.
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 ($@) {
$result->is_error(1);
$result->error($@);
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 );
++ }
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:
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
$self->da_warn("SQL=$sql")
if $self->da_warning();
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 freenode.net.
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';
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.
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:
By tinita
on
May 11, 2018 9:35 PM
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 YAML.pm, and then I felt like digging a bit deeper
into other bugs.
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;
Test::Database::Accessor::Utils::deep_predicate(
$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/Utils.pm line 94.
By Dean
on
May 10, 2018 9:51 PM
For $work reasons I have had to do a lot of work with DBD::Oracle.
Master in github has a lot of floating changes (https://github.com/pythian/DBD-Oracle/commits/master) since the latest release (v1.74 see https://github.com/pythian/DBD-Oracle/commits/v1.74)
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 https://github.com/pythian/DBD-Oracle/pull/62)
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 oracle.com account) and insert them
Still stuck in the Accessor.pm 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 Accessor.pm 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
package
Database::Accessor::Roles::Driver;
use Moose::Role;
with qw(Database::Accessor::Types
Database::Accessor::Roles::Common);
use namespace::autoclean;
requires 'DB_Class';
requires 'execute';
The first problem I had to fix after I moved all the common elements between Accessor.pm and a Driver was this;
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/Accessor.pm 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.
http://prepan.org/module/nYhnPU5b9ce
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.
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: http://act.yapc.eu/lpw2018/
We hope to see you there,
Pete, Rick, Lee and Katherine (the organising team)
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 Accessor.pm. It was suggested that I explain a little more on my reasons for doing most of the validation on the Accessor.pm 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 Accessor.pm 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.
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 Accessor.pm.
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;
Well its Accessor.pm 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 [
qw(da_compose_only
da_no_effect
da_warning
++ all_elements_present
...
By tinita
on
May 6, 2018 4:04 PM
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.
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 Accessor.pm I have some rethinking to do with Driver::DBI
I will now have to
- work with a results class
- capture any errors into the appropriate attribute of that class
- set the appropriate class attributes on success
- set the appropriate class meta attributes and
- 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.