I spent the day trying to get a little deeper into
POD::Weaver
to understand how it works rather than just aping the three lines I have seen in the odd tutorial or should I say tuturial-ette;
[@Default]
[-Transformer / List]
transformer = List
The fist thing to know about POD::Weaver is if you want to use it any deeper than the above then don't bother going to its home-page on CPAN there is not much there to get started on.
Not faulting the documentation at all it is quite comprehensive and perfect if you are going to create a project like podweaver.
I'll state right off the bat that I have re-invented the wheel here. However, I did not know that until I asked on Perlmonks and was pointed to the resources that I couldn't find on Google. It was suggested on Perlmonks that a blog post, even for a re-invented wheel might be good, just for the purpose of getting the information out there. So, here it goes.
If you use the Devel::ptkdb debugger, then you know that one of its features is the ability to save breakpoints (and other info) in a *.ptkdb file that is reloaded the next time you run that debugger.
It's a feature I missed on those occasions where I needed to use the default debugger, not Devel::ptkdb. However, after scrounging around what docs there are on the default debugger, I was able to cobble together the following process:
1 - Create a file .perldb in your home directory and add this code
to it.
MetaCPAN is the community developed and maintained website and api for finding and learning about Perl modules.
This year, we dedicated a long weekend to improving it and oh what a weekend it was!
This is the C::Blocks Advent Calendar, in which I release a new treat each day about the C::Blocks library. Yesterday I showed how to get information across the boundary between Perl and C. Today I show how to do that for a number of types, including packed arrays, with minimal boiler-plate.
Just a quick post-ette today to resolve the problem I was having in my last post, where I was trying to get [PodWeaver] to work with 'Pod::Elemental::Transformer'.
to work for my POD but it just did not want to play ball with me. I know this should work as I have seen it used in all sorts of other places and in the two tutorials I ran across.
When managing code quality for bigger projects, SonarQube is the de-facto standard for many programming languages. Not for perl, as there has not been any perl integration into SonarQube yet.
We have Perl::Critic, a fantastic linting tool, but what if we could track our Perl::Critic issues in our projects over time? What if we had a webinterface where we could extract statistics about certain issue types? What if we could combine this with code coverage information? All this is about to come...
In the tradition of the Perl Advent Calendar, I have decided to write an Advent Calendar for C::Blocks, which is in pre-Beta. My plan is to release a new treat each day about the C::Blocks library. Today we will begin with the basics: what it is and how it works.
Just when you think the Dist::Zilla is gone, I am going to go back to the Dist-Pen for the next few posts.
I could just spend the next thirty posts or so writing up a new POD each day and posting the results here. I wouldn't learn anything though, I alreay know how to write POD, and I am sure I would loose any readers I might of gained over the last few weeks. So I think I will spare us that and instead re-visit Dist-Zilla today.
I am going to re-vist how I am using [PodWeaver] plugin, as I am facing some thirty POD files that will have a good deal of boiler plate in them and I would like to have some things just done for me.
To investigate how
Pod::Weaver
works I created only a single POD today 'Manual.pod' with just this in it
- Errors are represented as typed, queryable exceptions. (The framework includes its own exception class hierarchy.)
- It’s “global clean”: no careless overwriting of variables like $@, $!, $?, etc.
The object hierarchy also closely mirrors ACME’s own object hierarchy: separate classes exist to represent ACME registrations, authorizations, challenges, and certificates.
The distribution includes example scripts that demonstrate usage of the module and should also give a good feel for the protocol itself.
The third POD post in as many days and really noting to do with Dist::Zilla so I guess I will have to find some other pictures to post.
After yesterday's post I took some time and had a look at a large number of different CPAN modules to get some ideas on the contents and style of my Accessor POD.
One thing that I have seem many modules do is break their documentation into separate PODs, under the names-pace and I will do that with Accessor as well.
I am going to keep some things in the Accessor.pm proper as it is good to have some basic info present, most of the other items I have been working on over the past few days I think I will break into separate POD.
So here is the first draft (outline) of my documentation in all its glory by Names-pace
Perl was created for systems administration, and Perl 6 has all the chops you've come to expect from the brand. Here I needed to use MD5 checksums from my collaborator to verify that I downloaded all their data without errors. Each data "$file" has an accompanying "$file.md5" that looks like this:
So I need to read the contents of this file, get just the first field, then execute my local "md5" (or "md5sum") program on the file without the ".md5" extension and determine if they are the same. All standard stuff, and I think Perl 6 gives us elegant ways to accomplish all of these, including a dead-simple testing framework. Here's my solution:
DBD::mysql is the perl DBI driver for MySQL and the primary way Perl
applications and scripts access MySQL and MariaDB databases. The source
repository is at https://github.com/perl5-dbi/DBD-mysql.
A vulnerability was discovered that can lead to a use after free when using prepared statements. This vulnerability is present in all releases
at least back to versions 3.0 of the driver, which were released in 2005.
The CVE identifier for this vulnerability is CVE-2016-1251.
The last two weeks, I didn't do much programming with OpenGL and GLSL. I used the weekend to catch up with some of the bug reports on Github and made the application more robust against missing input data or broken shaders. The net result is that it now can also cycle through a set of shaders:
I am getting sick of writing up PO of well necessary evil I guess at least my post will be sort for the next few days.
Today I managed to get my methods and attributes all written up but that left me with a layout dilemma that I have to solve. Should I go with the very traditional POD alphabetical grouping like this
Methods
add_condition
add_element
add_filter
add_gather
add_link
add_sort
create
delete
new
retrieve
update
Attributes
available_drivers
conditions
delete_requires_condition
dynamic_conditions
dynamic_elements
dynamic_filters
dynamic_gathers
available_drivers
dynamic_links
dynamic_sorts
elements
...
No need to put up all the attributes up there as the list goes on a bit.
At first glance it looks ok but if I was interested in the 'elements' attribute I would have to look in at least three different places to gather all the info I may need.
My present 'Elements' entry looks something like this
elements (RO) ARRAY-REF
An array ref of Element, Param, Function or Expression classes that are passed to the underlying DAD. ...
This is the C::Blocks Advent Calendar, in which I release a new treat each day about the C::Blocks library. Yesterday I showed how to get information across the boundary between Perl and C with minimal boiler plate. Today I explain how to declare and use C functions. I also explain the killer feature of C::Blocks: declaring C functions and other things within a module that can be used throughout your code.
This is the third in a series of articles about MetaCPAN. The first article described the two main parts that make up the MetaCPAN project, the API and the search interface. The second article gave a high level summary of how the API uses Elasticsearch to hold and search information about CPAN distributions and authors.
In this post we'll look at how MetaCPAN links to other parts of the CPAN ecosystem, how the physical setup has changed with MetaCPAN v1, and another service that v1 has made available.
This post is brought to you by Booking.com,
our second platinum sponsor.
Booking.com is one of the largest Perl shops in the world,
and have done a lot to support our community over the years.
Thank you to Booking.com for supporting meta::hack.
