I never like taking out code but that is the first thing I had to do today. So all the code changes from yesterday have been rolled back and I still have the same problem;
Attribute (predicates) does not pass the type constraint because: Validation failed for 'Predicate' with value undef (not isa Database::Accessor::Predicate) at D:\GitHub\database-accessor\lib/Database/Accessor/Types.pm line 349#
Namely an error message that tells me nothing of where my mistake;
$da->add_condition( undef);
happened.
I take a good number of 'warn' statements throughout my 'Types' class finally find a spot where I can intercept and create a better error message.
I eventually tracked it down to the '_predicate_array_or_object' sub in the 'Types' class;
Do you want to post an article in this year’s #mojolicious #AdventCalendar? I’ve just posted a call for articles in the mailing list. You do and know things that other people want to learn about, I promise!
DBD::SQLite 1.59_03 (with SQLite 3.25.2) is a release candidate of the next stable DBD::SQLite. Notable new features by the upstream are PostgreSQL-style UPSERT (3.24.0), ALTER TABLE table RENAME COLUMN oldname TO newname (3.25.0), and window functions (3.25.0), among others.
It also contains a fix that changes how to store values in a PerlData virtual table. If you use PerlData virtual table, this may affect your applications.
I'll wait for about a month as always, and release 1.60 at the end of November if there's no blocker nor request to wait more. Thank you for patience.
Well was all ready to move onto the final documentation and distzila stage of Database::Accessor and then I ran into a few little tings when I reran the full test suite.
First there was this annoying warning;
Use of uninitialized value $error_package in string eq at \GitHub\database-accessor\lib/Database/Accessor/Roles/AllErrors.pm line 59.
a simple fix really just this;
my $on ="";
-- if ($error_package eq "Database::Accessor::Element"){
++ if (($error_package) and ($error_package eq "Database::Accessor::Element")){
$on = " Possible missing/invalid key in or near:\n"
. Dumper($Database::Accessor::Types::LAST);
}
Every year since 2009, the Perl 6 community publishes a Perl 6
advent calendar, in the form of blog posts on perl6advent.wordpress.com.
To keep up this great tradition, we need 24 blog posts, and volunteers who
write them. If you want to contribute a blog post about anything related to
Perl 6, please add your name (and potentially also a topic already) to
the schedule, and if you don't yet have a login on the advent blog, please
tell Zoffix or someone on
#perl6 IRC chat your email
address so that they can send you an invitation to Wordpress for the site.
Perl 6 advent blog posts should be finished the day before they are due, and published on midnight (UTC) of the due date as publishing date.
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
If you write any software package, you have to document it. This simple truth drives more than few developers into despair. But there is also a way to craft good documentation and make the writing of it a useful part of the development. This is the closing part about authoring a Perl 6 module and Math::Matrix in particular (part: one, two, three, and four).
Its never stop improving day here in the Moose-Pen
As I was cleaning things up today I found yet another little improvement I can do to my error messages. Right now when I have deeply buried bad item such as the 'names' in this $in_hash
After a long, long time, Dancer::Plugin::reCAPTCHA has been updated. Most important in this release is that it now supports reCAPTCHA v2. Earlier versions only supported the v1 API, which is no longer usable. This required some minor changes to the module's API. Please see the POD for details.
Thanks to Shawn Sorichetti and Mohammad S Anwar for their contributions, without which this release would not have been.
These days, I have been using other means for fooling bots (which in part explains why this has taken so long to update). I will try to cover this in a future blog post.
Dist::Zilla is a great tool... but its main weakness is nearly its main advantage...
In My Opinion, Dist::Zilla Plugins are what makes my dzil workflow so great....
but on the other side, installing all the plugins and their dependencies is painful and can be very slow...
It's acceptable to install all these packages that are going to let you save time while developing and releasing your distro.... but contributors and Travis CI should not be slowed down by requiring the installation of these extra packages...
By tweaking the dist.ini of my distro by using a combo of GatherDir + Run::AfterBuild plugins, I could reduced the travis build time for a single Perl version from more than 4 minutes to about 30 seconds...
When smoking with Perl versions from 5.14 to 5.28 the total build time was reduced from 32 min to 5 min.
Here's another update about the grant for revitalizing blogs.perl.org. I'll start with an overview of what I wanted to achieve in the beginning, and where we got from there.
When I started this process, I looked at the "mainstream" PearlBee version as a basis for the new blogs.perl.org, and also the previous grant work that had be done. They each had different issues, in my view. The former was pretty much unfinished and barely usable, and the latter was way too big in number of features and requirements. I aimed for something small and stable, with just what was needed.
Just a few quick things here in the Moose-Pen today. I want to make sure that my '_one_error' sub will return the same style of results no matter from where it is called and I want to make sure the 'DA_ALL_ERRORS' $ENV var is respected.
I did the $ENV first at that was a little tickly; I made this change in Accessor.pm
I have just completed the marathon of submitting Pull Request as a part of Hacktoberfest Challenge 2018. For those, who don't know what I am talking about. Hacktoberfest Challenge is an annual event organised by Digital Ocean where you are encouraged to submit at least 5 PR to any distributions hosted on GitHub. In return you get specially designed T-shirt deliver to you anywhere in the world for FREE. It was first started in the year 2014. How did I get started? I was introduced to the challenge first by one of the blogs by Neil Bowers in the year 2015. Ever since, I haven't missed once. I am really addicted to it, to say the least.
I wanted to share with you a new experimental project which could allow you to mock file tests also known as -X.
All started while we initiate a larger discussion about testing, and decided to give a size to our unit tests. Using sizes like the ones used for t-shirt: Small, Medium, Large...
The definition for each size might differ and evolve.
But at one point we were considering that a small test should not have any interactions with the file system....
So how could you test such a function, without any interactions of the filesystem...