This year the ongoing support of sponsors such as CV-Library have meant we’ve been able to add conference t-shirts for attendees. Thank you CV-Library for your continued support of the workshop and local Perl community.
and so to get "coverage" of all the SvTRUEs here I'd need to send a string, an integer, a floating-point number, and so on and so on. But would that actually tell anything about Gzip::Faster? In fact it wouldn't. It would just be testing whether SvTRUE from Perl's core was working correctly or not.
Not a good way to start another year of blogging as I was reviewing my tests and when I got into '47_dynamic_gathers.t' I was getting a duplication on the number of conditions on a gather which is not a good thing.
Somewhere in the last few days I really buggered something up.
Well after much hair pulling and debugging I finally stumbled into it. It seems I have added so many warns and comment out code over the past few days I was playing with subs that look like this;
If you're a Perl developer in the Charlotte, NC area, come to the first social event for the Charlotte Perl Mongers! For more details, or to RSVP, check us out on Meetup.
Sponsors make it possible for us to run LPW without charging for tickets, and as an organiser last year Pete Sergeant knows just how important this is! Thank you Perl Careers for your ongoing support.
Final final final clean up day here in the Moose-Pen
Just a quick postette today cleaning up the last of my messages on my error retruns. Starting with this one;
'Database::Accessor Database::Accessor::add_condition Error:
The following Attribute is required: (conditions->left)
With constructor hash:
{
'predicates' => {
'operator' => undef,
so two thing to get rid of here, get rid of that 'Database::Accessor::' in front of 'add_condition' and change that constructor has so it dose not show that hidden 'predicates' key
the first fix is easy enough;
With the workshop just over a week away we have created the schedule. You'll notice we still have room for a few talks, so if you have something you would like to talk about then don't hesitate to submit a talk
We have tweaked the schedule a bit from previous years to start a little later than normal and allow a little more time for lunch. You'll also notice we have a dedicated Perl 6 track and a dedicated "mentoring / beginners" track.
We also have room for more lightning talks and will favour those that are submit early. Note we may tweak the schedule slightly to make room for more talks and/or depending on other factors.
After this weeks discussions about naming a shovel a spade, and how that would increase sales in the hardware store. I hope to start a substantive discussion around promoting Perl.
Dear Reader, please don't let the above metaphor become a stumbling block. Your ingenuity is desperately needed.
The first hypothetical question I would pose is:
If you had $10,000 to promote Perl - what would you do with it?
Please don't get lost on the dollar figure. This is intended to be an exercise in stretching the imagination.
Another question pair is:
What meaningful metrics could be used to measure Perls growth? (github stars? ithub commits? cpan releases? others?)
What activities could be co-ordinated and performed, that would increase these key metrics?
A quick Google search (or, DDG) provides many peoples thoughts about growing open source projects:
After fixing some strangling bugs and implementing some unimportant but fickly to implement
features rakudo.js now passes our targeted test subset. Some of the fickly features where
things like basic support storing fetching and ++'ing int64/uint64 variables etc. (rakudo.js is 32bit because that's what fits into basic JavaScript numbers).
Focus has now moved to running the roast tests in the browser itself.
For this I'm first precompiling the test files (which has it's own share of problems that I'm working around as rakudo doesn't yet fully support precompling scripts only modules).
For example all the compile time deps are recorded with a custom CompUnit::Repository
Then I'm bundling them together with parcel into a single .js file.
I'm running it with a Karma runner and Headless Chrome.
When running under karma the nqp runtime intercepts the TAP on STDOUT and reports the results to the karma harness.
After a brief break (and local hosting of The Perl Conference 2017), we are again hosting the DC-Baltimore Perl Workshop in Silver Spring, Maryland on Saturday April 6, 2019! The day will be dedicated to two tracks of Perl-related technology talks, targeting all levels of programming experience.
Is may be the end of the errors Day here in the Moose-Pen.
I spen quite a bit of time mulling over the various options and possible solutions to the rater large mess I made yesterday with my recursive call to a eval.
I did manage to do a very long coded version where de-factored my code back to what it was when I starter earlier this week. A block of code for each 'undef' sistuation.
I wasn’t really satisfied with that as it was ugly, unmaintainable and I think very fragile once I got into more that two levels of recursion on my evals.
What to do?
Well I had a peek at the guts of 'AllErrors' MooseX and from the I could see that it was warping anything I was doing a new with its own 'around BUILDARGS' so that explain why I was getting three errors rather than just one. I also means that I have to do another shameful act;
I've like to propose adding a ROADMAP section to module documentation.
It would be a *short* summary of planned changes for future versions, noting what features would be removed or changed, or upcoming new features that will be added.
More detailed roadmaps should be put in a separate file (e.g. `ROADMAP` or `ROADMAP.md`) that should be referred to in the section. Or link to the roadmap if it's online.
On behalf of the development team, it brings me great pleasure to
announce the 6.d ‘Diwali’ major version release of the Official Specification of
the Raku Perl 6 programming language.
Compiler releases with 6.d as their default language version will follow their standard release scheduling (for Rakudo compiler, release process will start on 2018-11-17)
As I finally got the 'add_condition' to work I still needed to add in a few more tests for the other three 'dynamic' attributes, gather, link and sort.
Well I started with the easiest first 'sort' and on the 'undef' I am getting the now very familiar;
Attribute (name) is required at D:\GitHub\database-accessor\lib/Database/Accessor/Types.pm line 348
It did not take me very long to back track this one to the '_element_coerce' sub in my 'Types' class;
As this had the same sort of fall though 'if' case like '_predicate_array_or_object' I at first added my check for undef code in the final 'if' of that statement;
I have been making a lot of changes to Graphics::ColorNames lately. The module has gone too long without any maintenance, and suffered from feature bloat.
Some notable changes that are already on CPAN:
A switch to semantic versioning, e.g. v3.3.3.
Some color schemes (Netscape, HTML, Windows) have been moved to separate modules.
The Netscape and HTML schemes have been deprecated in favor of the WWW scheme.
The X scheme has been updated to the latest X-Windows colors (which includes the CSS/WWW colors).
Roadmap for the future
I am planning on making the following changes:
Removing autoloaded method names for colors.
Removing the (deprecated) tied interface, but putting that in a separate module
Moving the color schemes into the Graphics::ColorNames::Schemes namespace, but provide an option to use the old namespace.