Sad day here at the Dist-pen.
Today I awoke still having nagging doubts about putting a copy of 'Database::Accessor::DAD::Test' directly into 'Test::Database::Accessor::Utils'. It did get all my tests to run correctly but it still was a cheat or a kludge at best.
So today I did build and then installed ' Database::Accessor ' on my Ubuntu box as I wanted to see if I could get this little script;Perl and Elasticsearch - The talk I gave this week and Sydney PM.
Note: All typos and mistakes are intended as tests for the reader.
This is informal response to David Farrell's article How to upload a script to CPAN.
Preamble: CPAN is great. This post in no way should be treated as Sparrow VS CPAN attempt. Sparrow is just an alternative method to distribute your scripts. Ok, let's go.
So let’s say I’ve got this Perl script:
This week a small group of dedicated Perl developers are gathering in Chicago for meta::hack, the first MetaCPAN hackathon. The primary goal is to complete the transition to Elasticsearch v2, a major undertaking that was started more than a year ago.
Because all the participants are volunteers, this was only possible with sponsorship. Over the next few days we'll be sharing information about MetaCPAN and the work going on, and acknowledging some of the key sponsors.
This post is brought to you by FastMail, a gold sponsor for meta::hack. FastMail is a stalwart supporter of the Perl community — they also sponsored the QA Hackathon this year.
Its a good day for a party here in the Dist-pen.
A milestone here today in the Dist-pen. I finally got;
t/56_retrieve.t ............. ok
t/test.t .................... ok
All tests successful.
Files=26, Tests=319, 34 wallclock secs ( 0.21 usr 0.11 sys + 31.23 cusr 1.99 csys = 33.54 CPU)
Result: PASS
[DZ] all's well; removing .build/usLuCs7LTk
Once I got though that problem I had with my last post, I quickly went through the last set of tests updating mostly the includes and the lib call and finally got the result above.
I did notice one thing I kept getting thisLast night I finally got to see The Martian. It was a fun movie, and it seems much of the science was solid. One thing that filmmakers still like to do is have computers spit out messages one-character-at-a-time as if they were arriving like telegrams. If you would like to read a file like this, I present the movie-file-reader. First, my very long-hand version:
In Perl 5.26, it will no longer be a safe assumption to assume . is in @INC. This is a good move towards a more secure Perl, but will break the installation of many CPAN modules. For those of you wondering why this was done, see this post for more information.
Many CPAN modules try to do things like: use inc::Module::Install; This depends on . being in @INC. If you invoke Makefile.PL without it, the script will not even run.
We have come up with several ways to mitigate and ultimately fix the problem:
Here's an article by New York City-based Perl hacker Jim Keenan on Medium.com about an unusual place where Perl has been put to good use:
Only an indirect dist-pen post today.
You ever have one of those days. Your code just does not want to come together and gives you know end of grief. Well today was one of those days for me.
I left off yesterday with what I though was a solution for my problems with 't/30_view.t', by moving my 'Database::Accessor::Roles::DAD' out of Accessor.pm and into its own file. Seem I still had a problem as in the 'Database::Accessor::DAD::Test' I still had a 'use Database::Accessor;' present.
Now that was setting up a circular call to Accessor.pm, as well it was never my intention for some-one to use a DAD directly only as a call from Database::Accessor. In the next test case 't/31_elements.t' I got
RETRIEVE No Database::Accessor::Driver loaded for Data::Test Maybe you have to install a Database::Accessor::DAD::?? for it? at...
# Looks like your test exited with 2 just after 1.
So Barcelona Perl Workshop 2016 happened this 5th of November. This is my report in three movements.
I've been listening for quite a few time that we should blog about the events we attend and love. I know it's good for multiple reasons, and I think it's a good advice. I've helped organize, attended and talked at the workshop and I knew I wanted to write about it, but it took me a few days before even thinking on actually do it.
While putting off working on my Perl Advent Calendar submission, I was instead active in resolving bugs in App::ShaderToy and adding some interesting features. The three major features I added this week are, in order of implementation, loading of bitmap images, hot reloading of code and the feature to make the window stay always on top.
It is incredible how much joy quicker iterations bring me while toying around with shaders, tweaking the parameters to see if I can find new visuals.
berrybrew is the equivalent of Unix's perlbrew for Windows platforms, which uses Strawberry Perl portable instances.
With David's permission and blessing, I've merged the numerous updates and features I wrote into my berrybrew fork into his.
If you want or need his previous version, do a checkout of this commit (6bc28ae).
Many thanks go out to David for originally providing this software, and being polite and easy to deal with. I don't use Windows as my every-day platform, but when I do, this made it much more enjoyable.
Just when you think Dist-Pen is gone its back again.
Now that I have my Dist::Zilla mostly worked out with all sorts of test goodies it is time that I buckle down and finish off and or clean up all my 'Automated' level test. As an side note, the term 'Automated' tests was a little confusing for me. I eventually figured out that by automated they (however they may be?) mean test that CPANTS will run. Normally these are the test in your 't' dir.
Myself I guess I must just be old school as I always called these module tests and it wasn't until I embarked on my Dist::Zilla trip that I have come to see the advantage of splitting your tests that really have noting to do with the function or you module, POD, spelling, Kwalitee etc, into the hand 'xt' dir.
This semester I'm teaching Perl 6 to beginners. On a recent homework, student A came to see me for help, so I pretty much wrote the script (if you come for help, you get help!). With every assignment, I provide a "test.pl6" script that lets the students know if they will pass. I stress that they don't need to code for edge cases -- just look to pass the test suite. Well, two students, B and C, copied student A, changed a variable name, and submitted.
If I had only checked for passing tests, I wouldn't have noticed, but I like to see how different students try to solve the problems. I'm often pleasantly surprised as a couple of students have some programming background and try to really use the language's strengths. On this occasion, I was disappointed to find that student's B and C (who have little prior coding experience) had turned in my own code.
Scott Wiersdorf's presentation on Kubernetes and how to use it to deploy your Perl applications.
Perlmodules.net, the site that notifies you about new releases of your favorite modules, just got better for groups, with Multi-User feeds.
If you're part of a project team, and wish to have your team members be able to view and/or modify your feed(s), as of today you can.
The owner of the feed grants read or write access rights to any users they want. If one of these guest users modify the owner's feed (i.e. adds or removes some modules which are tracked by this feed), the owner will get notified by email about all modifications at the end of the day (only if such modifications have occurred).
The last round of test case review here at the Dist-Pen today.
Down to the final few today;
TidyAll
This is the mother of all 'Author' test cases. This little chap wraps the 'Test::Code::TidyAll' case for you which will both tidy test and a validation test on you r code. Like TidyAll you can configure it to a very high degree. For my Database::Accessor project it is a nice to have so I will give it a good try. First you have to spend a half hour or so installing all the little parts of TidyAll, there are about twenty seven plug-ins plus other little bits. The plug-in requires that a config file is present, I just copied this one from CPAN . After getting that file all you need to do is add this to you '.ini' fileIn Perl, module loads have always attempted to look for the module you refer to in the current working directory (not necessarily the script location). It has always been this way in Perl. This goes back to the keyword "do" which precedes "require". When this was originally coded, it was also common to include . in your PATH.
Convention changed somewhere in the 90's. It is now considered a bad practice to include . in your PATH. Most languages also do not attempt to look for . in @INC. During my research earlier this year, I found that of all of the scripted languages, only Ruby used to have . in @INC and it was since removed.
I've never written games before, but I previously posted a Hangman that I thought was fun. I love the examples of forest fire and Game of Life and wanted to create something like those. I originally wanted to create Pong but decided to try a simple ball that bounces off the walls of a container.
I showed this to my daughter, and she asked if there could be more than one ball, so I added that. They don't, however, bounce off each other, and this gets at the same problem I was mulling with regard to adding obstacles in the field that should deflect the balls. I have a feeling that two-dimensional arrays would help me add this feature. Support for that is coming. Anyway, on to the script!
Hey everyone,
Following is the p5p (Perl 5 Porters) mailing list summary for the past week.
Enjoy!
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
