August 2009 Archives

This is an older one. I’ve only verified it with Grails v1.1, but it may still exist. It’s frustrating enough that it warrants a post, though.

Is your app slowing to a crawl due to an amazing Permgen leak? I mean big like 400+ MB of Permgen usage and 50k loaded classes. Well if you happen to be abusing ConfigSlurper, I may have a solution for you.

Are you doing something like this?

for (int i = 0; i < 50000; i++) { 
    ConfigObject config = new ConfigSlurper().parse("foo = bar"); 
    print " ${i}" 
} 

Well stop doing it. You’re leaking classes. Anything that you need to update at runtime that often should not be in the configuration file. Use JMX MBeans or a rest web service to allow updates instead.

Thanks to everyone on this email chain for resolving this issue.

If you’re lazy, like me, you commit your changes using svn commit -m "my awesome bug free code is done". This is easy and fast, but does not work if your software project has a machine specific configuration file, or something else that when committed causes other people pain.

SVN has no direct solution to this problem, but you can abuse the changelist feature to solve the problem. Simply create a changelist for these files and never commit it.

svn changelist donotcommit configurationfile1.xml configurationfile2.xml

You can confirm that this has worked with svn stat. Once the changeset is crated, it should look something like this:

bobdole@/svn/foo_project$  svn stat
M       changedcode.c
?       project.log

--- Changelist 'donotcommit':
        configurationfile1.xml
        configurationfile2.xml

Now you can go ahead and use svn commit -m "i fixed everything" again without living in fear of terrible office pranks being committed against you.

CVSDude, you suck.

CVSDude, the hosting provider that I’m currently using for Subversion, has been down all day. Since we’re an active development team, this has caused some very serious problems.

The worst part of the problem is that I cannot get a word from them. Their status blog entry seems to downplay it as a minor issue, but it’s far from that. They haven’t replied to my support requests that I sent in early this morning making it very hard for me to mitigate the damage. If they can’t take the time even to send a bulk reply, I really question their reliability as a whole. I do not feel that my source code is safe any longer.

If they haven’t replied to my email by the time I go home, I’ll have to stop by their office in Palo Alto to see what’s up.

A common database task is a custom report from the console. This usually invovles a CSV file since it’s human readable and imports into Microsoft Excel. It’s very easy to do this in PostgreSql 8. Just use the copy directive like this:

COPY (select * from table_name) 
TO '/tmp/table_name.csv' WITH CSV HEADER;

For example, if I want to dump select * from yoda where state='jedi' to CSV, my SQL may look something like this:

COPY (select * from yoda where state='jedi') 
TO '/tmp/jedi.csv' WITH CSV HEADER;