Not much got done in yesterday's
post-ette
and today just a little more me thinks. Well the first thing I had to get done to-day was start work on the Driver::DBI code a little and I started by importing the constants from Database::Accessor so here is what the Driver::DBI looks like;
Alien::Base was first released in alpha form five years ago this month!
The good things that Alien::Base (runtime) and Alien::Base::ModuleBuild (its installer ABMB) did
when it was unleashed on the world are many, but chiefly:
It suggested a standard way of providing the compiler and linker
flags needed to use an already installed alien. The
original manifesto
was pretty flip in terms of standards or best practices.
It made it dead simple to create an Alien distribution that
“alienized” a package that used
autoconf and
pkg-config, which probably covers a majority of open source libraries
that you would be likely to want to “alienize”.
(For those who are unfamiliar, autoconf provides a similar
functionality to ExtUtils::MakeMaker in the C world
and pkg-config is used to deal with dependencies in the C
world).
It made it possible with some work to create an Alien distribution
that wrapped around a package that used vanilla Makefile's,
CMake, and in some cases crazy custom installers.
This motivated me to explore that module further, and implement the methods that were missing from Sergey's patch. So I asked JACQUESG to implement a few features that I needed. He was amazingly fast at responding, and I found myself asking for more and more features. And he just kept adding them!
There are in fact more Git backends on CPAN... Anyone interested in adding support for Git::Class must have understood by now that patches are welcome. :-)
Like all subjective decisions in technology, which log level to use is the cause of much angry debate. Worse, different logging systems use different levels: Log4j has 6 severity levels, and Syslog has 8 severity levels. While both lists of log levels come with guidance as to which level to use when, there's still enough ambiguity to cause confusion.
When choosing a log level, it's important to know how visible you want the message to be, how big of a problem it is, and what you want the user to do about it. With that in mind, this is the decision tree I follow when choosing a log level:
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
I wrote about using the Perl debugger with Moose. In that post, I showed how to use DB::Skip to make it easier to use the Perl debugger with Moose and other modules whose guts you don't want to wade through.
Today's debugger hack will make using the debugger with DBIx::Class much easier.
The more I
think about the “single-quote as alternate package separator” thing I mentioned
in my last post,
the more it bothers me. The problem I ran into, trying to print "$user's crontab is
missing!\n", generated an “uninitialized
value” warning. It did NOT get picked up by strict mode—which was on—because packaged-qualified variables
are always OK.
This strikes
me as a source of hard-to-find and relatively easy-to-generate bugs. Given all
the other stuff that has been deprecated out of Perl over the years, I am
surprised this hasn’t been tagged for deprecation. Especially given that,
according to
a comment from preaction, the single-quote as a package separator was
considered archaic as of Perl 5.6.
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
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.
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.
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.
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.
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
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.
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?)
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".