blogs.perl.org

Of course we already knew it, but now we've got proof!

Tablet 2 was ready, i just completed and moved the trends section, because there not really language design priciples, mere consequences from that and a great introduction into the Perldelta.

Most work gone into the third - Variable Tablet which now start to get substance. the basic structure and lot of content i took from the german version even some lines from the wikibook programming perl, but most of this is written several times over. some parts are also removed because they will inserted on some later point.

i really hope that i didn't wrote too much in the first lines but its ment to be dense. The tablets are not about teaching you to programm nor teaching you to program perl 6 (take the open source book for that). The tablets are about finding a specific information as fast as possible. its an encyclopaedia, but written in a way you could actually learn the language from it, given you have the discipline only read what you need for the moment and ignore the rest you don't understand.

Nevertheless i plan another apendix, a cookbook section, to get a taste of real world perl 6 code.

I'm not terribly happy with the state of Perl/CPAN support for the INI file format.

I have this requirement of modifying php.ini files programmatically from Perl like: set register_globals to On/Off, add/remove some extension (via the extension=foo lines), adding/removing some functions from the disabled_functions list, etc. So I would like to find a CPAN module that can just set/unset a parameter and leave formatting/comments alone as much as possible.

Turns out that among a dozen or so of INI modules on CPAN, a few of them do not do writes at all (e.g. Config::INI::Access or Config::Format::INI). And a few that do, write a la dump. That is, they just rewrite the whole INI file with the in-memory structure. All comments and formatting (even ordering, in some cases) are lost. Example: Config::INI::Writer and Tie::Cfg. And, last time I tried, I couldn't even install Config::IniHash from the CPAN client. Not good.

In october a fellow Monger, Wolfgang Kinkeldei, made a talk about "Couch-DB" for the ERLUG, the Erlangen Linux User Group. One of our Perl-Mongers organized a room for the at the computing center of the university Erlangen-Nuremberg. Therefore the Erlangen Perl-Mongers recognized this talk and could attend as well.

CouchDB is a famous NoSQL database system that got quite some attention lately. It is a project hostet at apache foundation and follows a document oriented approach. CouchDB uses REST and JSON as a powerful but easy interface. Furthermore, it provides a web-based administration interface out of the box. And with its ability to use Javascript as its internal procedural language you can easily create simple web applications on top of CouchDB without other technologies. Wolfgang told us about these features and showed us some of those things live.

Wolfgang did the talk only as an exercice, he will do the talk in front of mor people at the anual KNF-Kongress in Nuremberg.

Besides the talk the people of ERLUG and the Perl-Mongers Erlangen got the opportunity to meet each other, to share thoughts and to learn about the other group. So maybe the one ore the other meeting we will get new attendies at our meetings.

After some kind member(s) of Vienna.pm brought the server back to life, and some anonymous coward sent me an email via an anon remail asking for fresh data, I got my lazy ass off my chair .. wait, no, actually I stayed seated in my office chair .. so I got my lazy mind off other things and started a complete CPANTS reindex yesterday morning. It took all day, but since of yesterday evening there should be new and up-to-date data available on cpants.perl.org.

Of course the code that's generating the data is rather out of date, especially with regard to stuff like Moose, Devel::Declare and even newer Perls (i.e. > 5.10). The code is on github...

I don't expect to spend any time on fixing / improving the code in the next few months. And the best thing to do would be to rewrite/refactor the whole beast to make use of the metabase and to also store the generated data into the metabase.

I'm converting Marpa to XS and have started to use Cweb. Cweb is the C version of the "literate programming" system pioneered by Don Knuth. I'm pleasantly surprised by it. Cweb adds fun to the programming experience and is helping in more ways than the phrase "literate programming" would suggest.

One very important feature of Cweb is something that would seem to be a nuisance, or at best an implementation detail. The .w file which contains the Cweb is now the "source". The .c and .h files are now "built files". I am no longer working with the C language "translation units". ("Translation unit" is standards-committee-speak for the text which is directly input into the C compiler. The term is used in attempt to distance the standard from file conventions.)

After doing this post on comparison of Perl serialization modules, I intended to continue with other comparisons, and even thought on setting up a wiki or creating/maintaining a section on the Official Perl 5 Wiki, which already has a Recommended Modules section, although there is not much comparison being written for each recommendation. (Btw, I just noticed a change of domain for the Wiki, from perlfoundation.org to socialtext.net).

But of course other tasks soon took precedence, so until the Wiki idea is realized, I thought I'll just continue posting on the blog as usual.

There are **seriously** too many Perl logging frameworks out there. As the Log4perl FAQ mentions, "Writing a logging module is like a rite of passage for every Perl programmer, just like writing your own templating system."

So I'm not going to pretend like I've evaluated even half of logging modules that are on CPAN. Instead I'm just going to include a few worth mentioning.

Another client launch: ActivityMD.com.

The front content was WYSIWYG'd by their previous ISP. Prolific position:absolute CSS makes that content painful to edit. But links to the shiny new backend are all Catalyst, Template Toolkit, and lots of jQuery.

It's an alpha release. Feedback welcome. :)

http://www.soundofdrowning.com/library.html

So Moose was a title by Richard Brautigan. This guy was a childhood hero of mine: "Trout Fishing in America"

Moose is referenced as one of the titles Brautigan used in
"Revenge of the lawn: The abortion ; So the wind won't blow it all away", one of the first books he continues to write and store away in a public library, which nobody ever visits to use, only to store away.

Richard Brautigan, (1935-1984) RIP

After about a week of waiting for an official review, iCPAN was reviewed, approved and published to Apple's App store earlier today. There are no code changes in this release, but the modules are up to date as of Nov 8, 2010. This release also includes manuals and cookbook POD like Moose::Manual.

I had hoped to get this release out in September, but real life got in the way. In the meantime, I've streamlined the way the POD is processed and future releases will be easier and hopefully much more regular.

Very happy that f00li5h tweeted to me about the Vi::QuickFix module. In vim, my leader is the comma and when I type ',c', I now execute perl -MVi::QuickFix -c % and that creates an error.err file which vi's quickfix mode can read. :cf will take me to the first error in the fix and :cn will take me to the next error. It will even jump to the correct file, as needed. See vim's :help quickfix for more information.

However, I've done more than that. See a bunch of problems in your files? Try running this:

find lib/ -type f -name '*.pm' -exec perl -c {} 2>&1 \; | grep -v 'syntax OK' \
    | tee errors.err

On our code base, that takes around 25 minutes to run. Then I have this in my .vimrc:

" quickfix for Perl error formats
set errorformat+=%m\ at\ %f\ line\ %l\.
set errorformat+=%m\ at\ %f\ line\ %l

Those two formats match the Perl errors I'm getting (note how one ends with a dot). With those, I can now jump to all errors and warnings that compiling our code generates.

Update: Fixed the find invocation.

Hi Folks

I have just finished a re-write of CGI::Session, called Data::Session, and started wondering how best to test it.

I've always disliked setting all the env vars to make its tests work for MySQL, PG, etc, so I hit CPAN looking for A Better Way.

I found Test::Database, which seemed to be a good idea. But examining the code was discouraging, so I decided to re-write that too.

I soon realized that one thing (among many - see below) which bugged me about Test::Database was its handing of DSNs.

So I decided to split that out into a separate distro, using an INI-style file, so I could add extra attributes to the DSN, such as active and use_for_testing. I might add use_for_production too.

That's why I've just released to CPAN DBIx::Admin::DSNManager V 1.00.

Now I'll use that in the re-write of Test::Database, which I'm going to call Test::Admin::Database.

Padre 0.74 has been uploaded to pause and is in the queue for indexing and replication to your favourite CPAN mirror.

So while all that happens, lets take a look at what has been happening since 0.72.

Well, plenty of fixes, and a fair amount of work done with the Plugins and converting them to Dist::Zilla by Ahmad Zawawi. The changes file doesn't really show the work that goes into the Plugins, but keeping one eye on the irc logs shows plenty of commits from Ahmad between releases.

Many of the plugins for Padre reside in the same SVN repository as Padre itself, so if you find an itch that needs scratching, you don't have far to look to start scratching.

Zeno Gantner is finding time to work on bits of Padre even with a rather hectic sounding life at the moment.

I'm about to start writing about a bunch of stuff that will definitely show my lack of a computer science background. Unlike many of my posts, this is your chance to correct me rather than me explain things to you. This has been on my desktop for awhile, so I'm cutting bait and posting what I have instead of working on it more.

I've been reading Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages, which is an enjoyable book except for the parts where he starts to talk about types and, ahem, types of programming languages. It's mostly distracting, not very useful, probably misguided, it not outright wrong.

He ist lead dev of Scintilla the edit component, Kephra, Padre and Kommodo are using. And I was very happy to read that he will open up the internal API. So Perl editors will be able to do even more.

Exciting.

After a bug report from a user, I've uploaded a new Data::Google::Visualization::DataTable.

You can do some fun stuff with this module - it allows easy preparation of data for use with the Google Visualization API - ie: any data source you can access in Perl, you can easily spit out as one of a number of awesome and often interactive graphs and charts.

If you make something pretty with it, let me know!

Yesterday we had some troubles setting up a client that should post some utf8 JSON to a web API. The problem was, that the data kept showing up as latin-1. After lots of "fun" with hexdump, wireshark, the debugger and Devel::Peek we verified that we were in fact passing a properly utf8 encoded JSON to LWP::UserAgent like so:

    my $response = $ua->post(
        $self->api_base_url . '/' . $args->{action},
        'Content-type'   => 'application/json;charset=utf-8',
        Content          => $args->{data},
    );

Still we didn't receive utf8 on the server.

After adding encode_utf8 in random places, it worked. So I dug into google and found this posting containing this advice:

If you want the string UTF8 encoded, then say so explicitly:

 $req = HTTP::Request->new(POST => $endpoint);
 $req->content_type("text/plain; charset='utf8'");
 $req->content(Encode::encode_utf8($utf8));

It seems that HTTP::Request, when stitching together the actual text representation of the request, will downgrade the content to latin1, no matter what you say in Content-Type, unless one explicitly calls encode_utf8 on the content.

Top 10 Mistakes When Building and Maintaining a Database is a good overview of what not to do when creating a database.

The only caveats I offer about this article:

• The article is SQL Server-centric; and
• Mistake #4, "Use of Adhoc Queries", seems to be true only when you have a large, heterogenous development staff (like 10+ developers). Smaller development groups don't seem to suffer from allowing ad hoc queries by developers. (Perhaps it is mainly a communications problem, rather than just an allowing ad hoc queries problem?)

I've always been an avid hater of uninitialized variables. I'll hunt them down, catch them and beat them to a bloody pulp and then shoot the remains.

Too much, you say? No need for the bat AND the gun, you say? Oh, quite the contrary.

Here is an example of a recently discovered Linux kernel issue. An uninitialized memory segment. The fix is really simple: to initialize it with zeros. This was done in a patch that only adds the following command:


+ memset(mem, 0, sizeof(mem));


Oh, but I can hear you snicker behind your monitor "this won't happen in Perl because Perl protects you from such stuff!"

You're right, this won't happen in Perl. But here's a Perl example:

At $work I've written a program that runs checks on servers (rest assured, it's not a Nagios replacement) and creates an array of the results of each server that was tested. The array contains timing and whenever there's a timeout, it contains an "undef" to indicate a penalty.

Has Lacuna Expanse been created solely to cripple Perl developers' productivity?

Are tiobe.com the real developers of Lacuna Expanse, in a fiendish plot to further lower perl's ranking?

Who cares?!
The Saben Semesne are attacking!
Where are my spies?!