A recent clpmisc post (link @ GG) resulted in a largely obnoxious and long thread in which amongst other things people talked about the already oft discussed question re whether Perl should be standardized or not.
The argument about the "marketing value" of a standard has some merit. But a standard is neither necessary nor sufficient for success, even in corporate and governmental environments.
There is no Windows ISO standard, no Java ISO standard, and yet these are used very widely. OTOH there is an ISO (or at least ANSI) CPU standard (for a subset of the SPARC ABI, IIRC) which nobody cares about and I think the Pascal or BASIC ISO standards are similarily inconsequential.
Successful standards (like C90 or POSIX) are developed after there have been multiple implementations and when the implementors actually want to converge on a single standard. In the case of an open source interpreted language like perl5 there is little value in a standard. There is only one implementation, a second implementation is unlikely to happen (porting is almost always easier than rewriting from scratch) if it happens compatibility is probably only a minor goal.
Test::Distribution is probably the most widely used of all the Perl modules that I've developed. It's certainly the only one that I know of that has been mentioned in an O'Reilly book.
Over the last couple of years (mainly ever since my wife and I moved out of the parents and gained the responsibility of maintaining our own household) I haven't been able to give it the attention it needed. I'm hoping that will change over the next few years, but I've hoped that several times in the past too...
I'm interested in people's views on what I should do with T::D. Some ideas:
It'd be really good to hear from people that still use Test::Distribution and would appreciate me coming out from hibernation.
After a lot of neglect on my part, http://cpants.perl.org/ is now working again. Sort of...
There are still a few problems (mostly with Meta.YML stuff), and I have to start the analysis manually on my laptop (which means there won't be automatic updates in the next few weeks, but only when I have some hours of CPU to waste)
The Perl search pulls results from 72 assorted Perl related sites including CPAN and perldoc.perl.org. It tends to work for those questions that you're not even sure where to ask.
Perhaps more useful is the CPAN search which I find often outperforms search.cpan.org. In particular it finds 'one word' module names like CGI or FCGI both of which search.cpan.org currently overlooks.
If you have any suggestions for sites I've missed or other improvements give me a shout.
David Golden on Devel::CheckLib. It's similar to Devel::CheckOS, in that it will let module authors specify dependencies which aren't just other perl modules - if they need, eg, libjpeg, then they can use this module in Makefile.PL / Build.PL to make it a pre-req, and if it's missing then the CPAN testers will SHUT UP ABOUT IT and not annoy the author.
I've been a bit quiet for the past month or so, mostly because projects both at work and home have taken up a lot of my time. One of the home projects has involved creating some report documents in PDF. When first thinking about this, I was looking at PDF::API2, and various other PDF modules, but was struck at how much layout work is put into the code. I don't like having to mix the two, as if I have to change anything in the layout it means changing the code. Reading a recent article on perl.com only reaffirms that. If you're creating a special document, this might work for you, but it doesn't for me.
So djberg96 changed that to use an unsigned int by attaching the U to the end of the number. I think I used to know that.0xff << 24
Additionally, I cast some return values from the XS stuff to (UINT *) to ensure that everything treated them as unsigned ints.0xffU << 24
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.17 "Two for Finching." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages.
Parrot 0.4.17 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code.