namespace::clean compile problem solved

I couldn’t get namespace::clean to compile and install properly on one of my servers. It was a clean Perl 5.10.1 install, so I couldn’t really see what the problem was. But just to be safe I really really cleaned out perl, reinstalled, and then ran Gentoo’s perl cleaner utility, ran a revdep-rebuild, etc etc. Then I found this bug, installed Term::ReadLine::Gnu, and all was well. So simple, and yet not something I’d ever figure out on my own. It would be pretty cool if the CPAN testers who failed on this test and those who passed could compare notes automatically and generate a list of possible dependencies that are missing.

But anyway, I really hate it when CPAN installs fail and I can’t figure out why right away. Maybe Google will pick up this blog and index it. Here Google, index this: Compilation failed in require at /usr/lib64/perl5/site_perl/5.10.1/Term/ReadLine/ line 63. at /usr/lib64/perl5/site_perl/5.10.1/Term/ReadLine/ line 63 Term::ReadLine::Perl::new(‘Term::ReadLine’, ‘perldb’, ‘GLOB(0x1caace8)’, ‘GLOB(0x1b9a150)

A simple “show me” program to understand what lazy_build, etc does

I’m beginning to use MooseX::Declare more and more, but this morning I realized I didn’t quite understand when the builder was getting called, and under what circumstances, so I wrote the following program to testing things out. Not so much a test of the code for some notion of correctness as a literal test of what is going on so I can be more informed.
Continue reading

I used perl today, and I can’t figure out how to get my paper man icon.

I used perl today. Moose. I ran into a problem. It was annoying. I am way too stressed and tired to blog more. But I will anyway, secure in the knowledge that no one reads this blog but google’s spiders.

Okay anyway I used MooseX::Declare, and couldn’t get the method signature stuff to work. I did something like

method weekend_or_vacation (DateTime $dt){
  # check if weekend or vacation
  # with vacation being the tricky bit
  if($vacation || $weekend){
   return 1;
    return 0;

But MooseX::Declare kept complaining that it didn’t know what DateTime was. I scanned the tests in t and sure enough, they all test simple things like Str and ArrayRef and so on, but none of the more magical parts of type checking.

I eventually solved it the old fashioned way by puking if the argument wasn’t a DateTime, but I’d rather do it the method signature way.

PUT problem solved

I had a problem linking up dojo/xhrPut and Catalyst::Controller::REST. As always, the answer was in the documentation, but I didn’t see it.

Catalyst::Controller::REST docs say that:

The HTTP POST, PUT, and OPTIONS methods will all automatically deserialize the contents of $c->request->body based on the requests content-type header. A list of understood serialization formats is below.

And the docs for dojo/xhrPut point to those for dojo/xhrGet for parameters, which include:


A JavaScript object of name/string value pairs. These are the headers to send as part of the request. For example, you can use the headers option to set the Content-Type, X-Method-Override, or Content-Encoding headers of the HTTP request.

This parameter is optional

So all I had to do in my javascript code is

	    var xhrArgs = {
		url: ajaxurls.sort + '/' +,
		putData: dojo.toJson(data),
		handleAs: "json",
		headers: {'Content-Type':'application/json'},
		load: function(data){
		    // don't really need to do anything here
		    // uncomment for testing
                    // console.log("new sort order put to server");
		error: function(error){
		    alert('warning, edits were not saved properly.  Proceed with caution');
	    //Call the asynchronous xhrPost
	    var deferred = dojo.xhrPut(xhrArgs);

And the controller magically started to work as expected. Hooray, git commit and all that, but it is time to go to sleep and actually get things working some other day.