blogs.perl.org

Well its almost programming day here in the Moose-Pen

In my last post I at least got the first test to pass. Tough it really wasn't a test of much as Driver::DBI is basically empty. I did have some time today to have a snoop about and read trhough the DBD::DBM POD and see what is what.

I discovered that by default DBD::DBM uses something called DBI::SQL::Nano which is really just a sub sub set of SQL

If you saw my FOSDEM talk about Building a Universe in Perl, I show some examples of the code we use to model behaviors in our universe. I start talking about out test suite at one point and that's probably the most exciting part. You see, we've been fixing our leaderboard system in part because I can do this:

That's a truncated version of our test failure report for tests failing on master. Leaderboard tests show up twice in there.

Ever have an failing test and trying to remember if it failed before? Is it fragile code? Is it fragile tests? Has it ever failed on your master branch? What percentage of your tests fail? Well, now you can find out.

Just now, while attempting to do

print "$user's crontab is missing!\n"

I got the error “Use of uninitialized value in concatenation (.) or string…”, and after a bit of testing, I discovered that “$package'varname” is apparently an alias of “$package::varname” (in my case, Perl was trying—and failing—to print $user::s).

Did everyone else know this? This is literally the first time I have run across this in almost 20 years of Perl programming

(Of course a quick Google search turns this up in the opening paragraphs of the perlmod docs—I wonder if it’s time to read all of that stuff cover-to-cover?)

I have been working on the next generation of Alien::Base installer which is called Alien::Build. It is already quite usable, and I encourage it's use for anyone who is considering building a new Alien modules. It may also be useful to migrate existing Aliens, if they have requirements that can utilize its unique features. The main idea is to concentrate the recipe for discovery and building of a library into an alienfile which is separate from the Perl installer (usually ExtUtils::MakeMaker or Module::Build). Over the next few weeks I intend on writing a little about some of the new features of Alien::Build. In the meantime, if you are interested, Alien::Build::Manual::AlienAuthor may help you get started.

Well it is still fix that test day here in the Moose-pen

Not sure why I am calling today's post a Moose-Pen as there is very little Moose if any in it. Yesterday I left of with a little script that was suppose to init a table using 'DBD::DBM' and add a few records, next get a DBI handle to that database then pass it to the 'Test::DB::User' accessor class while doing a 'create' call.

Well on my first try on running this I got

DBD::DBM::db do failed: Couldn't parse at /usr/local/lib/perl/5.18.2/DBI/DBD/SqlEngine.pm line 339.
 [for Statement "DROP"] at test_dbi.pl line 14.

and after a few mins of head scratching I saw that in my little script I forgot to properly format my array of SQL commands. I had

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week.

Enjoy!

On Monday 27th March, the Thames Valley Perl Mongers (TVPM) are having a mini tech talks session in Reading. Talks are going to be about 15 minutes each. Speakers and topics are given below, along with details of the venue.

Any and all are welcome to join us.

Again...I guess this trope is something Perl developers just have to accept as we keep coding our Perl modules and scripts.

The eigenvector of "Why we moved from language X to language Y"

So back to test case day here in the Moose-Pen

So in my last post I was successfully passing my first test case 00_load.t now before I move on to my next test case I have to do a little planning.

I have to keep in mind my end goal, pass in a $dbh (a DBI Database Handle) to one of the CRUD functions on an instantiated Database::Accessor calss, parse the various Accessor, attributes convert that to the appropriate SQL, the with DBI, prepare the query to the a $sth (DBI Statement Handle), bind any variables to the $sth, execute the query and return the results.

Now the DBD I am going to work with is "ExampleP" now I am not sure what will happen if I try any of the above DBI actions will have. So I have to do a little experimenting with DBI before I go any further.

What I need to do is mimic the process I would normally do like this;

This tutorial shows how to wrap a C shared library using XS and Perl (including creating a trivial test shared library).

The first 3/4 is the actual wrapping itself. The second part includes the C code and build commands to create the trivial shared library used in this tutorial.

Relatively, I am still very new to all of this, as it's a pretty complex world. Before I started, I didn't have any real C experience, so I've been dealing with that learning curve at the same time, so I know there are better and more efficient ways of doing what I do, and would appreciate any feedback.

I'll get right to it. Here's an overview:

DBIx::Custom 0.38 is released. I have deleted DEPRECATED featreus before 5 years.
If you use DBIx::Custom before 5 years, Please take care of updating.

This release performance is up.

DBIx::Custom 0.38

I will add SQL creating feature, database async query support, much faster DBIx::Custom Fast.

Changes

The list of DEPRECATED featreus.

Reading the description of the new book, Think Perl 6, I see one line "how to program and think like a computer scientist" and in the same week I hear from a friend of mine trying to get into the gig economy and the only jobs he can bid on turn out to be someone's CS assignment. Me starts to think that one way for profs trying to curb students' tendency to False Laziness would be to set assignments in Perl 6, provided they are willing to pick up the language themselves.

There are other approaches. My sibling's prof taught them C in the time it took to say "Your assignments will be submitted in C".

Just a thought.

So it is write a little code day here at the Moose-Pen.

I now have my first test case checked in thanks to yesterdays post and a few min setting up a new GitHub repo.

I also found my first bug as I used the code from this post as a template for my first crack at 'Database::Accessor::Driver::DBI'. After hanging out the name-space from SQL to DBI I ran my test and got

first argument should be a role at C:/Dwimperl/perl/site/lib/MooseX/Test/Role.pm line 41
	MooseX::Test::Role::consuming_class('Database::Accessor::Driver::DBI') called at 00_load.t line 16
# Looks like your test exited with 255 just after 2.
ok 1 - require Database::Accessor;
ok 2 - require DBI;

seem in my haste the other day to get post up I did this mistake

I find it such a pity that after so many years of work on MetaCPAN by so many contributors it still accounts to 27.3% only of the total CPAN traffic.

Maybe if more people were linking to pages of MetaCPAN from their own blogs in the relevant context.

For example if you write about databases and Perl you could link to the Perl DBI for Database Access. When you talk about AJAX and JSON, you could mention JSON and Perl. If you are talking about Dates or Timestamps, you could mention DateTime in Perl.


Or any other module that is relevant to your blog post.

I've been playing with Amazon's CodeBuild for Bedrock's CI/CD pipeline.

Some gotchas but CodeBuild is cool.

http://openbedrock.blogspot.com/2017/03/aws-codebuild-howto.html

If you've been following our progress with Tau Station, you know we're creating a science fiction universe in Perl for people to enjoy. As of this writing, the time in Tau Station is 194.10/51:647 GCT.

"GCT" stands for "Galactic Coordinated Time" and that's a variant of metric time. As a software developer, I wish we had that in the real world, but alas, we don't.

The GCT time listed above is roughly 194 years and 10 days after the "Catastrophe" (an apocalyptic event that effectively serves as our "epoch"). There are 100 days in a year, 100 "segments" in a day (14.4 minutes each) and 1000 units in a segment (.864 seconds each).

I love the fact that figuring out the display time for GCT is this simple:

my $days = sprintf "%9.5f" => $seconds_since_catastrophe / $second_in_a_day;
$days =~ m{^(?<year>\d+)(?<day>\d\d)\.(?<segment>\d\d)(?<unit>\d\d\d)}a;
my $gct = "$+{year}.$+{day}/$+{segment}:$+{unit} GCT";

It is almost programing day here in the Moose-Pen

I left off form my last post with a name-space change from 'SQL' to 'DBI' and the first think I have to do today is come up with an initial test case to work against. The usual first test is you simple does it load test like 00_load.t

#!perl
use Test::More tests => 1;
BEGIN {
    use_ok('Database::Accessor') || print "Bail out!";
}
1;

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week.

Enjoy!

Perl6::Tidy has been released to GitHub, not on the ecosystem yet. The driver program is 3 lines, mostly passing options to the tidier. Which is 6 lines, doing the real grunt work.

It doesn't do much yet, but it's pure Perl 6.

The last half-year or so, I've been hacking on different Integrated Circuits, various small hardware, learning how to wrap specific C software (while ensuring the code remains within the Perl license) in order to bring the Raspberry Pi toward the realm of reasonable Perl programming.

I have written numerous pieces of software to allow this. The first was WiringPi::API. This is the core wrapper that allows you to use the wiringPi library right from your Perl scripts.

I pushed this further with RPi::WiringPi, which is an object oriented wrapper for WiringPi::API, but performs important benefits; it registers pins so you can't re-use them by 'accident', and it does an auto-cleanup (ie. it resets everything back to non-dangerous state) on failure. It also allows you to pull in other RPi-type objects and use them directly.

With the different ICs, hardware, etc that the RPI:: scope encompasses, I've finally run into a situation where I can't effectively ensure the quality of it all.