The past year has been work filled, but its about time to finish up work on the Perl 5 core IPv6 functions. The last bits of functions to work on are getaddrinfo() and getnameinfo(). I'll need to play with Inline::C a bit to try out a few things. At a minimum, it getaddrinfo will look at bit like...
my $kablam = POSIX::getaddrinfo('blogs.perl.org', 'www');
I've not decided whether to allow the additional hints in the addrinfo struct as a hashref or as additional parameters. Right now, I'm thinking as a hashref should be enough. I'm working what will get exactly returned from getaddrinfo() yet in what order. Decisions, decisions, decisions.
There does need to be a separate clean up of the content, I'm wondering what the advantage of this site is (now), over say, having more information on say http://learn.perl.org/ about how to do testing.
Anyway, I've got other projects to sort out first, but may come back to this at some point.
This is a script I've wanted to share for a while, but I haven't yet had the chance to figure out how to write App::Highlight (if anybody could give me some pointers in this direction it would be much appreciated!)
highlight.pl is designed to be piped into, like grep or ack, but instead of filtering out lines which don't match it just highlights words which do, similar to "ack --passthru" except that you get different coloured highlights for your different matches.
If you're a sysadmin or if you run a Perl software development environment, you might want to give your users or developers the possibility to install Perl modules from CPAN into their private user-space. This could be helpful for trying out new modules or playing around with modules that might be used in production at a later time. Or, if a developer wants to test a new version of a module without overwriting the system-wide installed version of that module.
Here is a step by step instruction how you could set-up user-space CPAN support.
Gitalist started out as an attempt to port gitweb to Catalyst but ended up as a new piece of software with gitweb URL compatiblity (and stuck with its original transitional name). This first developer release should see a fully functioning Catalyst app with full gitweb URL backwards compatibility and no major bugs, although there are plenty of rough edges.
As it stands the app itself is quite simple internally and externally thanks, in no small part, to Zac and Tom's marvellous work on the model. They stripped it down from a single monolithic Model class and transformed it into a sane and sensible set of domain objects. As for the external bits the frontend consists of HTML5 and CSS (with JavaScript knobs and whistles to come) which is all brought to you by Template Toolkit.
Developers and admins who are new to Perl might wonder how they can install one of the 18.000 available Perl Modules from http://search.cpan.org.
One of the many ways to do this is to call the CPAN shell from the Unix command line, like so:
cpan Modern::Perl
You could also go and give the cpan command a list of modules that you like to install:
cpan Modern::Perl DBI YAML JSON::XS
However, if you just type in "cpan" you start the interactive CPAN shell, where you can install a module by typing:
install Modern::Perl
If you just type in “i Modern::Perl” you get just some information about the module.
The CPAN shell downloads the archive into your ~/.cpan/build directory and extracts the content there. If the module can not be installed because tests are failing, you could go into that directory and do a
perl Makefile.PL
make
make test
make install
by hand and eventually fix the problem that caused the tests to fail - or just force to install the module and ignore the tests if you know what you’re doing.
A new version of xml_grep2, packaged as App::xml_grep2 is coming to a CPAN near you. This time with extra goodness: the --XL option, which uses XML::Liberal to parse even broken XML.
If you have ideas about other useful options, please let me know.
Note: I actually wrote this on my personal blog a couple weeks ago, but it’s perfect for blogs.perl.org!
The FFmpeg::Command Perl module is a convenient way to drive the ffmpeg command-line utility for converting multimedia files.
For work, I have developed some scripts that make heavy use of FFmpeg::Command. Yesterday, one of the other developers told me they need a conversion script to be able to merge separate video and audio streams into one file that contains both audio and video. The ffmpeg command-line utility can do this by accepting more than one input file. For example:
The FFmpeg::Command Perl module, however, assumed there can only be one input file. I made the necessary changes to the module code so that it would accept multiple input files, created a patch file, and sent it to the Module owner Gosuke Miyashita. This morning, I received e-mail from Gosuke thanking me for the patch and informing me that he has uploaded a new version (v0.12) of FFmpeg::Command to CPAN.
Just a quick note to let everyone know I have abandoned my use.perl.org journal. If I get ambitious, I will write some code to pull everything over there to over here.
I'm crawling out of the rock I've been hiding under for the last months to write my first post here and to (again) proclaim the huge grand-ness of git.
My use case today: A week ago I fixed a rather small bug in a branch that has not been merged into master. Today I stumbled over the same bug in another branch and of course remembered that I fixed the problem already.
so:
git co master
git log -Sinit_job # gives me a306cfc = the commit that fixed the bug
git co the-branch-I'm-currently-working-on
git cherry-pick a306cfc
done!
And now I have to go back to not spend time on the lovely Perl community...
You ever have days when you can't stop giggling? As an ex-COBOL programmer, I laughed out loud at the idea of object-oriented COBOL. Today I'm giggling at a paper entitled What does aspect-oriented programming mean to Cobol? (PDF). I can tell you want it means, but this should be a family-friendly blog. AOP was another way to get around the limitations of inheritance, but I think it's fundamentally broken. Applying a fundamentally broken technology to an obsolete (yet needed) technology just leaves me in a fit of giggles.
I have visions of COBOL programmers screaming "we're relevant, honestly", but no one hearing them. They're only relevant because there's so much legacy code out there written in COBOL. We've no choice but to keep this coal-fired programming language running.
