Now that I have my constructor single error working the way I like I figure I better go back and clean up my test cases and create a new test case just to check the error on 'new' construction.
I am going to start with '30_view.t' as that is the one I have been mucking with most over the past little while.
The first thing I did was strip out the new 'validation' tests and suck them in a new tests case '42_new_validation.t' and after a few adjustments it presently looks like this;
I'm planning to remove the module Unicode::Properties from CPAN. The reason to remove the module is that it is outdated (the code is from 2008), the module uses a faulty methodology to get the properties, and it is unreasonable to maintain in its current form. Currently the module has no stars on metacpan, has no reviews or reverse dependencies, and the only user feedback I have received, from Tom Christiansen was to tell me that the module wasn't good enough for his purposes (see module doc), so I assume it is unused.
If you are a user of this module, please let me know. If you want to adopt the module (strongly not recommended) let me know.
For the October 9 gathering of Boston Perl Mongers we'll be hosted by MaxMind in Waltham, instead of our usual MIT location. Our speaker will be Mark Fowler.
(Boston.PM is happy to accept this offer of hosting from MaxMind, and would welcome hosting offers from other organizations in Eastern MA. It gives those who live further West or otherwise are unable/unwilling to travel to the city a chance to attend.
We're also looking for presenters. You don't have to travel to Boston. Remote presenters welcome. Have a module you want to promote, or a conference talk you'd like to "beta test" or give again, see our presenter's guide.)
About the talk:
A resource for beginners and advanced Perl users alike, the Perl Advent calendar features humorous stories featuring Santa's Elves and the fun they have with Perl. This talk will talk about all the exciting things that occurred in last year's calendar. Somewhat akin to twenty four two minute lighting talks, it'll expose you to a wide range of topics.
I had only one little goal today and that is come up with a really nice single construction error message. After a good hour or so of mucking about I finally came up with;
While reflecting on how to write a good Perl 6 module, I thought a lot about how to properly name my methods. In this text I want to summarize what served me, which is a direct continuation of the last part, where I wrote about when it is helpful that methods share one name.
The Hacktoberfest Challenge 2018 is on and it is my fourth attempt. As always, I am very excited about the event.
September 2018 has been very special month so far for me. Why? In this very month, I submitted my 1000th Pull Request. Also as of today 1st Oct 2018, I have completed 407th days of daily upload to CPAN. My next target is reach 500 days mark, which I am hoping to reach by new year. I also submitted my talk proposal to London Perl Workshop 2018. The title of my proposed talk is "The power of mentoring". For a change, I have also submitted proposal for lightning talk "What after the Pull Request Challenge?". If you haven't submitted your talk proposal yet, then please do so now. I would like to
share one sweet moment with everyone. After submitting my 1000th PR, the first PR that got merged after that had the following message for me.
Today I am going to add in another attribute called 'all_errors' a simple Boolean flag so my end user can either get a single error message of all the errors found or the 'MooseX::Constructor::AllErrors' object with all the errors when using the 'new'. Simple enough I can just add it here
Here’s a pattern which took me a while to figure out this past week, and therefore seemed worthy of sharing with you guys.
First, let’s set the situation. (These are certainly not the only conditions under which you could use this pattern, but it’ll probably be easier to grasp it with a concrete example.) Let’s say you have a script which you’re going to use to launch your other Perl scripts. This script (in my example, it’s a bash script, but it could also be a super-minimal Perl script) has exactly one job: set up the Perl environment for all your personal or company modules. That may even include pointing your $PATH at a different Perl (e.g. one installed via perlbrew or plenv) so you’re not reliant on the system Perl. Here’s a typical example of what such a (bash) script might look like:
I have been asked this question many times since I submitted over 1000 PR. Before I answer this question, I would like to share a secret with you all.
It all started in the month of Jan 2015 with Pull Request Challenge (PRC) pioneered by Neil Bowers. Although I was already submitting PR before that but without any target. With PRC, I got direction where to go. I must admit taking on PRC wasn't easy one. I didn't want to make a fool of myself by joining PRC and not submitting PR regularly. I still remember first couple of months, so many Perl hackers joining the PRC but not every one actually submit PR regularly. Some even dropped after a while. But I kept it going as I was enjoying it. Although I was hardly getting any acknowledgement from the distribution author. It can be discouraging for the beginners.
It's not super usable and this moment and will likely explode if you try to have too much fun.
Hopefully this example will be replaced by something much more awesome soon.
Parcel.js is a web application bundler so it will take care of combining the JavaScript code Rakudo.js spits out with everything else your app needs to run.
Why Parcel.js instead of Webpack?
Mostly because Parcel while seemingly more buggy doesn't insist that hard on re-parsing the generated code.
I had a webpack plugin working for NQP at some point so it definitely is doable so webpack afficionados are welcome to contribute a plugin or entice me to write one.
Currently I'm using some cutting edge JS features (like BigInt) so I'm focusing on supporting Chrome.
I plan to spend some time on supporting other common browsers when Rakudo.js is more mature but luckily the evergreen browsers are constantly updating themselves and implementing new stuff so hopefully the problem will solve itself.
I've just released revision 3 of the @Starter plugin bundle for the Dist::Zilla CPAN distribution authoring tool. There's no changes to the base configuration from revision 2, but there are now additional options to help manage common authoring tasks using modern best practices. You must set your revision to 3 to enable these new options, as a safety measure to make sure you have a new enough version of the bundle to support them.
I my last post I figured out how to set up Database:Accessor to get the 'MooseX::Constructor::AllErrors' object in the 'around BUILDARGS' and then play with it, without breaking my existing code.
Today I want to see if I can change my error messages. I started by poking about in guts of ' MooseX::Constructor::AllErrors' and I discovered the the error messages are rather had coded;
sub message {
my $self = shift;
return sprintf 'Attribute (%s) is required',
$self->attribute->name;
}
Now that does not do me much good as I can't just do this in my 'around' sub
package Point;
sub new {
my $class = shift;
my $self = {
x => 0,
y => 0,
@_,
};
bless $self, $class;
return $self;
}
sub x { shift->{x} }
sub y { shift->{y} }
my $point = Point->new(x => 1, y => 2);
my $x = $point->x;
my $y = $point->y;
In order to quickly install a set of Perl modules for a given task, it is nice to have some kind of meta-package serving no other purpose than pulling in a set of other more specific packages. Traditional ways of doing this with CPAN can be found in the Bundle:: and Task:: namespaces. Recent developments, however, seem to have put meta-package maintainers in a predicament. Technologies are shifting once more. In this article, I explain how I rescued my meta-packages with minimal changes.
In this guide about what to consider when writing a Perl 6 module, we (after part I and part II) will reach Perl 6's great power of signatures. They enable a feature, that is very often used in Perl 6 (internally and externally). Here are my arguments when the usage of MMD makes the most sense.