Well looks like clean up day again on the old Moose-Pen. Well I hate to say it but 90% of today's post is on types again as my cleanup found a little problem with my 33_conditions.t test case. I know it was running fine yesterday but that changed when I discovered that I had commented out a good hunk of my tests before I though I was finished.
So looking back I did say I no longer needed the from hash-ref on my coerce of ArrayRefofConditions it seems I did not notice that I had commented out the test for a single hash coercion so I added that back in and my test failed. So I had to add in the 'from 'HashRef', via' for my various collection attributes.
Now I also forgot that that I will want users to be able to enter an Array Ref of values on my various dynamic attributes so looking at conditions I would like to do this;
I've just released a new Log::Any trial release. This release improves performance immensely when there are no log output adapters configured. This release also now returns the formatted log string from logging methods, allowing the log message to be used by a die or warn call.
Because of these changes, there is a very small chance of an incompatibility: Log::Any logging methods used to return whatever the configured adapter returned (this was undocumented and was not a feature). Now they always return the formatted log message.
Earlier this year I added some commands to the ntheory module, inspired by Pari/GP and Mathematica, to split numbers into digits and put them together again. Of course this isn't terribly exciting by itself since Perl has split and join, but with optional bases it gets more interesting.
I recently took a look at the various modules that do base conversion (at least 9 modules, plus various standalone subroutines). Each has slightly different features and interfaces, and the performance at the extremes differs by over 10,000x. I've made some internal changes to ntheory based on my tests, which should show up in the next release.
Add: This is for Perl 5. Perl6 has native support for base conversions for bases 2-36 and seamless Bigint support. It Just Works. For larger bases or alternate encodings, bbkr's TinyID module can be used.
Today in the Moose-Pen I am going to have a quick look at some very Moosish behavior when playing with types. I known you must be getting tired for Moose Types, but I think today you will see something that may save you time if you ever go deeply into Moose Types and coercion.
So to set this up say I have a look a new test I added to the 33_condtions.t test case
I was going to hold off on announcing my new WiringPi::API distribution until my larger project that depends on it is done, but since it's CPAN day, well...
The module wraps the majority of documented and undocumented functions in wiringPi.
wiringPi is a set of C libraries that allow you to muck with a Raspberry Pi, it's GPIO pins and other things.
You can import the C functions directly keeping their original names as is:
Scott McWhirter helped a ton with the transitions (as well as with some general cleanup).
Most of the modern browsers now support ECMAScript 6 so I feel it makes sense to target it.
When targeting old ones that don't we can use polyfills and compilers from ECMAScript 6 to 5.
After doing most of the obvious and promising nqp-js optimizations I'm focusing again on getting rakudo.js to work.
Before that I'm cleaning up the nqp-js code base to remove hacks that might shoot us in the back while working on rakudo.js
I uploaded my 20th distribution to CPAN yesterday, a little bit premature of CPAN day but that doesn't matter. It will require an update since odd things are happening in the tests, so there will be a release today. The module is Net::AMQP::RabbitMQ::PP, a pure perl version of Net::AMQP::RabbitMQ.
I didn't write the module but when updating various libs and our version of perl here i noticed it had found its way into our stack and when cpanm didn't find the distribution i had to go hunting. It turned out the module existed on github but never made it to CPAN, so how it got into our stack i don't know.
So carrying on from where I was yesterday in the Moose-Pen I played with a few ideas today on how to solve my problem of not being able to get dynamic attributes down to the DAD from my DA.
In my last post I had the example of a canned 'client' that I wanted to do this to
my $client_da = Data::Tier::Clients->new();
$client_da->add_conditions(...
$client_da->retieve($mongo,$into);
$client_da->retieve($dbh,$into);
I did play about with loading All the DADs at once so and I could accomplish this by do this by storing all the DADs in a new attribute, then I creates a 'add_conditions' sub where I passed these conditions down into the underlying DADs.
Finally I decided not to use Test::More and Perl Test-Harness in Outthentic anymore.
These are the great tools proven in many many testing projects. But Outthentic tends to be more general purpose framework to run ANY scripts, rather than being a test framework only. Some testing facilitates are still here, but they poorly use a Test::More/Test-Harness entities, so I decided to rewrite story runner to get an asserts execution results in free style - so no TAP indeed is required.
If you're following tech stuff, you probably know by now about the folks
at Rust land working on some totally awesome error reporting
capabilities. Since
Perl 6 is also known for its Awesome Errors,
mst inquired for some examples to show
off to the rustaceans, and unfortunately I drew a blank...
Errors are something I try to avoid and rarely read in full. So I figured I'll
hunt down some cool examples of Awesome Errors and write about them. While
I could just bash my head on the keyboard and paste the output, that'd be quite
boring to read, so I'll talk about some of the tricky errors that might not
be obvious to beginners, and how to fix them.
For my Moose-pen today I am going to have to put my thinking moose and get out of my class, type, attribute and coercion rut that I have been and and look at how my Accessor will be used by other programmers.
Fortunetly I have not done a good deal of work in this area. So far I have only the retrieve and my 'BUILD' sub that I use to load in the DAD that might be out test. Now this is where I am getting into problems as the way it stands not thing will work fine with static Accessor but I will have problems with adding in dynamic attributes.
To illustrate this lets start with a simple example of two joined tables.
Dancer2 0.202000 is on its way to a CPAN mirror near you, and brings several important bug fixes and enhancements.
Plugins may now easily call the application’s DSL using $self->dsl. For example, logging a debugging message is as easy as $self->dsl->debug( “I’m in your plugin!” ); Plugins can now also call the syntax of plugins that they have loaded. Consider this example:
Your Dancer2 application (MyApp) uses plugin Foo. Plugin Foo uses plugin Bar. Plugin Bar adds baz() to the DSL. Plugin Foo can now access baz() (just like the DSL in Dancer2 works), however, baz() is only accessible to the Foo plugin, notMyApp.
Please keep in mind that if plugin Bar adds any hooks, those hooks are added to MyApp, but Bar’s DSL is not available to MyApp.
The parameter methods in Dancer2 (body_parameters(), etc.) were not decoding Unicode values passed to them. All parameter methods are now decoding Unicode characters.
Disclaimer: I'm sure this functionality exists elsewhere, but this was a fun little thing for me to work on. Also, you'll need a minimum of git 2.7 for this to work.
Often, when I'm working locally I like to bounce right over to a GitHub repository url to check something. I ended up writing a bit of code to make this easier. While I was at it, I decided it would be nice to have the same thing for Travis URLs. So, I've released this as part of Git::Helpers.
When you're inside a Git repository, you can use
gh-open
to open a browser window with the GitHub URL of your repository.
gh-open
also accepts an origin name as an argument, so
gh-open upstream
would open a tab in your default browser containing your upstream's URL, assuming you have an origin by that name. Don't specify a remote name and it will assume
origin
:
gh-open
It doesn't currently care which branch you're on, but patches welcome (in the kindest sense of the expression).
If you want to check your Travis page for the repository then
travis-open
will do the same kind of thing. It also accepts an origin name, just as
gh-open
does:
I am a subscriber to module-authors@perl.org and thought I’d repost something written there for the wider community.
Chris Bogart, a postdoc at Carnegie Mellon, is interested in studying how different language-level package managers and repositories handle breaking changes. He has observed that different package management systems have made “very different design choices from each other,” and he would “like to know what the impact of [CPAN’s] design choices are on how you negotiate breaking changes among CPAN module developers when the packages depend on each other.”
If you have released modules on CPAN, and especially if you have thought about making breaking changes to your module, or have made breaking changes to your module, I’m sure you’re ideas would be helpful. If you have had to deal with an upstream author’s breaking changes, I’m sure that would be helpful, too.
Just a short note for the Moose-Pen toady, I am going to clean finish off my Moose droppings by looking at the Expression.
Well all I really have to do is do a search and replace on the word function in my last post and and then past is here but that would be cheating. If I did do that I would at least see if anyone is reading these apart from Gabor.
So I will be working the
14_predicate.t
and adding in the following;
CPAN Day marks the day when the first distribution was recorded as being uploaded to CPAN. That was 16th August 1995, so we've been uploading modules for 21 years now!
On CPAN Day you could release something to CPAN, send a pull request on someone else's distribution, blog about Perl, or just head to the pub with fellow Perl hackers.
