dragffy.com

Bazaar has come on a long way over the last six months with the latest release being somewhere around the 1.4 mark. Today, with the upgrade to Hardy which brought with it version 1.3 I started noticing incompatibilities between my local version (1.3) and the server version (0.9). Further investigation revealed some major changes across those revisions, including a completely revised storage format for branches or repositories. So, once you get Bazaar up to the latest version, you need to go about upgrading the storage formats of you branches like so:

To find out what storage format you are currently using, just go the the branch’s folder and type in:
bzr info -v | grep 'repository'

That should give you an output similar to this (an example of an obsolete format):
repository: Knit repository format 1

If it’s anything other than “Packs containing knits” then you’re still using the old storage format. How to upgrade is documented in the bzr documentation, including preparation and upgrading, but the gist of it is:

Make sure you backup the whole directory first, then run:
bzr upgrade

(if you’re using shared repositories, make sure you specify where the root repository is with bzr upgrade root-repo-dir)

Once that’s done, you should reconcile:

bzr reconcile

If the operation doesn’t report any problems, run a quick bzr info to make sure the repository has been updated correctly and you should be able to delete the backup of the old storage format dir which is named .bzr.backup/. Only do that after you’re sure everything is OK!

Today I upgraded a server that was running Gutsy AMD64 arch. I wanted to note in this blog that the update went well, and the result is what seems to be a perfectly good Hardy Heron system. This is what I did from the command line:
sudo aptitude install update-manager-core

followed by:
sudo do-release-upgrade

Went through it all. Sometimes got prompted about config files - whether to keep my version or install package maintainers version. I chose to install the maintainers in case there were some important new config options (I had backups of my config files). These were mostly related to Apache and PHP. Having gone through the config files I can say that it is safe to choose to keep your config files (if upgrading from Gutsy). If you’re going from Dapper you probably should check.

Profiling an application is a great way to see how it is performing. CodeIgniter comes with a profiling class, which you can make calls to from your controllers. However, during development I find profiling so helpful that I want it on all my pages, without having to specifically call it each time. I also want to be able to deploy my development site to a production server - making calls to the profiler throughout the controllers means I would need to edit each and every controller to make sure the profiler wasn’t active on the live server.

After much searching I discovered a better solution. This allows you to add profiling to the bottom of every page (along with its debug info and SQL query info). When you copy the dev site live you just exclude 1 file, and profiling will be removed totally. All you need to do is create a file called MY_Output.php in system/application/libraries that extends the Output core class, with the following contents:

< ?php
# /system/application/libraries/MY_Output.php
if (!defined('BASEPATH')) exit('No direct script access allowed');
class MY_Output extends CI_Output {
function __construct() {
parent::__construct();
$this->enable_profiler( TRUE );
}
}
?>


This will enable profiling output on all your pages for development and debug purposes. When you copy your site to a production server just make sure you don’t copy MY_Output.php file. I normally use rsync for copying live and just add: --exclude="MY_Output.php" to the rsync command.

The condition to using the name MY_Output.php is that you left the variable $config['subclass_prefix'] in config.php as default. This defaults to $config['subclass_prefix'] = ‘MY_’;, so if you change it you will need to alter the filename of your new class.

I recently found that sending emails via my server was painfully slow. After further invesitigation in to this issue I discovered that the server was performing reverse-DNS checks on client IPs. These were slow because they often didn’t work and had to wait for a timeout. The solution is to turn of reverse-DNS checking on the server by editing a config file as follows…

The modification must be made to the /etc/inetd.conf file:

smtp stream tcp nowait root /path/to/qmail/bin/tcp-env tcp-env -Rt0 ...

smtps stream tcp nowait root /path/to/qmail/bin/tcp-env tcp-env -Rt0 ...

It is necessary to restart inetd in order for the changes to take effect:

# kill -HUP `cat /var/run/inetd.pid`

Note, /etc/inetd.conf may be overwritten and the options you added will be removed if you make certain changes through Plesk CP, for example add MAPS server.

There was a time when I would recursively grep the contents of literally thousands of files at a time to search for particular occurances of characters. The usual starting place was something using grep, which we can time for crude benchmarking:

user@localhost$ time grep -rn 'hello' *
templates/temp.tpl:1:hello

real 1m56.190s
user 0m1.400s
sys 0m0.940s


Using Ruby to write a script, which I named Grope, I made the search process 450 times faster, reducing an operation that took more than a minute to taking a blink of an eye…

user@localhost$ time grope 'hello'
templates/festival/06/temp.tpl: 1
hello...

real 0m0.181s
user 0m0.100s
sys 0m0.070s


dscacheutil -flushcache

In the “about:config” section of Thunderbird (Tools > Options > Advanced > Config Editor) look for the “mail.imap.fetch_by_chunks” and ” mail.server.default.fetch_by_chunks” values and set them to “False”.

Mozillazine gives some more information about what this value actually does here

find . -iname "*.jpg" -print0|xargs -0 -I {} convert -quality 60 -resize 461x317 {} {}

A trivial Ruby script for replacing any number of tabs in input.csv with a single comma and then writing it as output.csv.

The first version works from the command line and makes use of concatenating a file and piping it to a ruby command which then diverts the output in to a file, a one liner:
cat input.csv | ruby -pe 'gsub( /\t+/, "," )' > output.csv

This can be further enhanced by using the in-place-edit switch of the Ruby interpreter, editing the input.csv file and leaving a pristine copy with .bak extension.
ruby -i.bak -pe 'gsub( /\t+/, "," )' input.csv


The final version is what you might put in to a Ruby file. Although the input and output files are hard-coded, it would be trivial to allow them to be specified on the command line.

#!/usr/bin/env ruby

# Initialise a new file object that is writable
file = File.new( "output.csv", "w" )

# Open the existing tab delimited file and read each line
File.open( "input.csv", "r" ).each do |line|
  # Perform a global substitution of tabs with commas and
  # put that in the new file
  file.puts line.gsub( /\t+/, "," )
end

# Tidy up by closing the newly written output file.
file.close