Its get nowhere day here in the Moose-Pen
So I was all set to for today's post to move from playing with Database::Accessor and start playing with Driver::DBI again but just as I was finishing off the tests which I did not want to bore you with I got this:
...
ok 7 - Balanced parentheses
no ok 8 - AND not added to first gather condition predicate
ok 9 - AND added to last gather condition predicate
…
ok 26 - AND not present on first link predicate
not ok 27 - AND not present on first link predicate
not ok 28 - AND not present on second link predicate
ok 29 - AND added to second link predicate
...
Better get that fixed before I move along.
In all the fails above, I am dealing with the situation where the 'conditions' that are being checked will come into the check function as an 'Array-Ref' as both Gather and Link use a 'conditions' key like
this;
It is go back again day here in the Moose-pen
In my last bunch of posts I though I had finally got all my element view, parentheses and 'AND' ; checking coming out all OK so I started today by going back to here I left off in Driver::DBI. The first thing I did was re-run the test suite and I ran into this
# Failed test 'Where with function and 1 param SQL correct'
# at D:\GitHub\database-accessor-driver-dbi\t\lib/Test/Utils.pm line 56.
# Expected SQL--> SELECT people.first_name, people.last_name, people.user_id
FROM people WHERE length(people.last_name) = ?
# Generated SQL-> SELECT people.first_name, people.last_name, people.user_id
FROM people WHERE AND length(people.last_name) = ?
in the '20_where_basic.t' case and similar one all over the rest of the test cases. I guess I am adding an 'AND' in there when there is only one condition. Back to Database::Accessor I go.
Hello Perl community,
I realized that it's more than one year since I last announced an
Amusewiki release on blogs.perl.org, so here we are again. Yesterday I
released Amusewiki 2.222.
Unofficial Debian packages can be found, as usual, at
packages.amusewiki.org (together with installation
instructions).
The codebase is pretty stable by now, but over the past year it saw a
couple of interesting improvements.
The Xapian-powered search now is a full-fledged and fast faceted
search. See for example https://amusewiki.org/search
As a side-product of this improvement, I contributed to the Xapian documentation,
which can now produce Perl examples as well:
(to the extent permitted by the Search::Xapian module).
git clone https://github.com/xapian/xapian-docsprint
cd xapian-docsprint
make html LANGUAGE=perl
Read this article on Rakudo.Party
Today, I came across a reddit post from a couple months
back, from a rather irate person claiming themselves to be possibly
the only person to never receive any credit for their work on Perl 6.
I was aware that person committed at least one commit and knowing the
contributors list is generated automagically with a script, I thought to myself
"Well, that's clear and provable bullshit." And I went to prove it.
Moar No More
I looked up the commit I knew about, looked at the release announcement for
the release it went into and… that person was indeed missing! It was the
2017.02 release, which I released. So what was going on? Did I have an alter-ego
that shamelessly erased random people from the contrib list without my
having any memory of it?!
It test review day again here in the Moose-Pen
Today I was having a look at coverage that the '58_parenthes.t' test case gives and with only seven tests it is rather sparse, time to add a few more in.
What I want to first improve is the coverage for 'functions' and 'expressions' to make sure the nested nature or the left and right attributes are correct. I started with this formula 'element' make up of a number of 'expressions','functions', 'params' and 'elements' that use parentheses;
(abs((People.salary + .05) * 1.5))*People.overtime+(abs(People.salary+.05) *2)*People.doubletime)
The above would be expressed as the following hash;
A summary of the last five years of workshops, in anticipation of this year's event: https://leejo.github.io/2018/07/04/five_years_of_spw/
It is fix a bracket and AND day in the Moose-pen
I did a little more checking of my tests in '58_parenthes.t' and it would appear that my changes from
yesterday's
post did not actually do the trick as the second test is failing and the 'Condition' part of the has is in error;
conditions => [
{
left => {
name => 'First_1',
view => 'People'
},
right => { value => 'test->3' },
operator => '=',
open_parentheses => 1,
close_parentheses => 0,
condition => 'AND',
},
{
condition => 'AND',
left => {
name => 'First_2',
view => 'People'
},
right => { value => 'test->4' },
operator => '=',
}
]
as there is no ' close_parentheses' on the second condition in the array so into the code I go as obviously I am skipping over something to do with conditions.
After adding in a little warn here and there I determined that the bug is in the '_check_element' sub at this point;
}
elsif (ref($element) eq 'Database::Accessor::Condition'){
$self->_check_element($element->predicates->right);
$self->_check_element($element->predicates->left);
}
else {
return
unless(does_role($element,"Database::Accessor::Roles::Comparators"));
$self->_inc_parens()
if ( $element->open_parentheses() );
$self->_dec_parens()
if ( $element->close_parentheses() );
It condiment day again here in the Moose-Pen
Time to do some more catch-up coding as my most recent round of changes to fix all my 'element->view' woes I ended up removing any checks for 'parentheses' I had in place. To recap on the original idea of the parentheses check was to make sure that there was at least one closing bracket for each opening bracket in the 'conditions' being send down to the DAD.
As it stands now I am using the '_parentheses_check' sub to check all the attributes that that may contains not just an 'element' but any class that can use a 'predicate' so 'Elelemets','Functions','Expressions' and 'Conditions' quite an expended set.
Unfortunately I can not really test to see that the positioning of the brackets are syntactically correct as this;
ORDER BY (left(test,12)+12)*12
Recent Perl 6 survey results that the top two most wanted features are better performance and JVM support. Luckily the Truffle backend promises to kill two birds with one stone. ;)
With help from Daniel Green (MasterDuke on #perl6) we got the Truffle backend from passing the first NQP test last to passing 9 this week.
Once proper closure supports lands later this week we can start working on passing more complex ones.
One positive observation is that due to high level Truffle operates (as opposed to say a machine code generating written in C++ V8) other Truffle implementations can be a lot more easily pillaged for ideas how to implement thing in Truffle efficiently.
By kd
on
July 2, 2018 12:36 PM
Following our initial trial
release,
here's another one.
We've attended to the changes suggested from the last release (better
changelog and CI integration) and we've also attracted some positive attention
from the relevant authorities.
We're still looking for sponsorship to have DBD::Oracle work continue beyond
this driveby. If you are interested, or know someone who's interested in
chucking some cash into the pot, the best route is probably to contact me (kd)
on irc.perl.org or via my cpan email address, zarquon [at] cpan.org
By BooK
on
July 2, 2018 12:16 PM
Wallflower is my static website generator. Well, not really: it's actually generating a static version of any Plack application, provided it behaves reasonably when seen as a static site.
(Read on, I'm asking for help towards the end!)
Another quick fix postette today in the Moose-Pen
Yesterday I had my gather test fail with;
ok 46 - Second Gather element does not inherit view
not ok 47 - Third Gather element inherits view
and a
Can't call method "predicates" on an undefined value at 57_dad_elements.t line 486.
# Looks like your test exited with 255 just after 49.
A quick check of the test and the input and found a 'condtions' where I should have had a 'conditions' so that fixed that and all the links and sorts passed but I did get this for the gather
In my previous monthly report for May 2018, I mentioned that it was the best month ever since I started contributing. So the obvious comparison, did I do any better this month?
In short, it was not as good as it was last month. However, under the given circumstances, it was satisfactory. You might ask how do I rate my own performance. Some of the criteria are as below:
- Pull Request
- Git Commits
- Pull Request Challenge
- Perl Blog
- PerlWeekly Newsletter
- Adopt CPAN Module
Lets do the comparison.
Pull Request
Last month, June 2018, I submitted 46 PR as compared to 60 PR in the month of May 2018.
Overall so far, I have submitted 900 PR. The target is to reach the milestone of 1000 PR before the next London Perl Workshop in Nov 2018 looks promising with current speed.
Git Commits
Last month, June 2018, there were 412 commits as compared to 536 commits in the month of May 2018.
Its another quick test postette today in the Moose-Pne
So things are moving along now I just just going to finish off '57_dad_elements.t so it will be a short one today. Nothing much to Add I just have to add in dynamic link, gather, and sort.
Well sort should by the most easy one so I will do that one first; All I did was copy out the last (5th) item in the main hash and added it in like this;
$da->add_sort({
expression => '+',
left => { name => 'salary', },
right => {
expression => '*',
left => { name => 'bonus', },
right => {
function => 'abs',
left => {
expression => '*',
left => {
name => 'bonus',
view => 'Other'
},
right => { name => 'bonus', }
}
}
}
});
Next a little re-factoring of the last four sort tests into a little loop
A few months ago, John D. Cook wrote about the viability of unpopular programming languages.
His story starts with a comment about Perl 6, to which someone replied, "Does anyone actually use Perl 6?" (or words to that effect).
"My first thought," he writes, "was, I bet more people use Perl 6 than Haskell, and it's well known that people use Haskell."
What is the relationship between popularity and viability?
Its back to view day here in the Moose-Pen
Today I am going to carry on with getting full coverage for test case '57_dad_elements.t' and fixing the bug I found in yesterays post.
First the bug. I am missing the view in the last left of this nested element;
...
bless( {
'predicates' => bless( {
'operator' => '=',
'left' => bless( {
'left' => bless( {
'name' => 'bonus'
},
'Database::Accessor::Element' ),
…
and the test for it is
ok(
$elements->[3]->predicates->left->left->view() eq 'People',
'Fourth condition left->left inherits view'
);
now I have checked the call with the underlying code for any typos and miss calls and I have confirmed that I most not be drilling down into this second nested 'left'. The problem must be in '_parentheses_check' sub and a quick read of that sub I see that in the where code I do the parentheses_check and I also drill down on the 'left' and 'right' only if they are an Element;
It the great test round up here in the Moose-Pen today
Since I have done at least two major changes in the design of Database::Accessor over the past few post I figure I better give the whole test suite the once over to see what breaks. Here are the results of the first run;
Its condiment day here in the Moose-Pen
Now it is time to play catch-up with my Database::Accessor and make the same changes for 'links' that I did for 'conditions'.
First off I could create a new Role as both share the same basic attribute again but I think I will not do that and instead do this;
package
Database::Accessor::Link;
use Moose;
extends 'Database::Accessor::Base';
++ has predicates => (
++ is => 'rw',
++ isa => 'Predicate',
++ coerce => 1,
-- alias => 'conditions',
++ );
without the alias there.
Like yesterday's post I will start with an existing test case '35_links.t' and one my first run I had some expected coercion problems
Attribute (predicates) does not pass the type constraint because:
Validation failed for 'Predicate' with value ARRAY(0x41b967c) (not isa
Database::Accessor::Predicate) at
Its test round up day here in the Moose-Pen
Now that my baby Moose is almost all grown up it is time to go back and look at some of the missing bits in my test suits. In my last post I fixed up the default 'view' for all the 'element' attributes that my be present on a Database::Accessor.
I have checked my test suite and I at least test the elements attribute to a few levels of recursion in '31_elements.t'. Looking at that test suit I think I will pull the eight 'view' tests out of there and and create a new test case '57_dad_elements.t' that will cover those eight and all the other 'view' tests for the DAD.
Recently GraalVM 1.0 been released which can run Ruby, JavaScript and other dynamic and static languages on top at super fast speeds.
I have decided to see how Perl 6 will run on top of it.
If successful that should allow us to run Perl 6 hopefully very fast and use Java, Ruby and JavaScript libraries without paying a interoperability price.
Truffle which is what we are using is a language implementation frameworks that creates an efficient JIT from a (sufficiently annotated) AST interpreter written in Java.
The implementation lives in the 'truffle' (https://github.com/perl6/nqp/tree/truffle) branch of the nqp repo.
nqp-truffle run the first NQP test today and I expect to get many more to pass in the coming days.