Currently I’m working on my third web based project that uses PostgreSQL as its backend. Two of these projects were/are being developed under OS X. Installing PostgreSQL under OS X is a breeze when one uses MacPorts. However I have seen more than one developer being confused about the steps that should follow the installation and the post installation instructions as printed out by the PostgreSQL port.

The installation instructions can be compressed into three steps:

1. Install/update MacPorts
2. Execute: sudo port install postgresql83 postgresql83-server
3. Follow post-install instructions as printed out by above command

Trying to connect to PostgreSQL

Now that the PostgreSQL is installed you might be tempted to connect to it by starting the PostgreSQL interactive terminal. This is what will happen (gkoller is the user I’m currently logged in as under OS X):

gkoller@Kinchenna $ psql
psql: FATAL: database "gkoller" does not exist


So by default it looks for a database named identically to the currently logged in user. Should we want to connect to a different database we should specify the database’s name after the ‘psql’ command.
E.g.:

psql hgh


I have chosen the name ‘hgh’ as it is the (abbreviated) name of my latest project. The above command will fail with a similar message as the first command. So let’s create the ‘hgh’ database:

gkoller@Kinchenna $ createdb hgh
createdb: database creation failed: ERROR: role "gkoller" does not exist


Again the error message is clear. The currently logged in user does not have access to (does not have a role with the same name defined in) PostgreSQL. Simply executing a ‘createuser gkoller’ will not help as we don’t have enough privileges to do that. More importantly nor does root. So a ’sudo createuser gkoller’ does not work either. And this is what stumps most developers that try to get PostgreSQL up and running for web development on OS X

Granting privileges to the currently logged in user

When PostgreSQL was installed it was configured with one superuser, namely ‘postgres’. Hence adding new users with superuser privileges should be done as user ‘postgres’.

sudo su postgres -c 'createuser -P --superuser gkoller'


Now the currently logged in user has PostgreSQL superuser privileges. This means we don’t have to use ’sudo’ and ’su’ to executed PostgreSQL commands to create databases, roles, and other users.

Creating a database and user for project HGH

Now that I am a super user it is easy to create additional users and databases. For my HGH project I want a separate database and user. I’ll name them both ‘hgh’.

This is how:

gkoller@Kinchenna $ createuser hgh -P
Enter password for new role: <password>
Enter it again: <password>
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) n

gkoller@Kinchenna $ createdb -E utf8 -O hgh -W -U hgh hgh
Password: <password>


Conclusion

After PostgreSQL installation and post-installation you should create a new superuser named after your OS X login account. This allows for access to PostgreSQL commands without the need to use ’sudo’ and ’su’.

This is achieved by executing the following command:

sudo su postgres -c 'createuser -P --superuser <your_username>'


Where <your_username> should be replaced with the username of your
OS X account (short) name.

Last December Apple introduced the OS X 10.5.6 update. With it a serious regression for users of the Dvorak Simplified keyboard layout. This regression broke many keyboard shortcuts under Carbon based applications. A number of bug reports by different users were raised with Apple and an active thread on Apple’s forum started.

Despite the impact for affected users Apple (typically) never communicated anything else then that they were aware of the issue and working on a fix. They did not bother giving these users, their customers, a timeline in which to expect a fix. Nor did they bother releasing a hot fix to remedy the issue. No these customers had to wait five months till the release of OS X 10.5.7 for the regression to be supposedly fixed.

I say supposedly as I won’t be upgrading to OS X 10.5.7 immediately. I have learned my lesson. I know Apple’s disregard for its customers. I know the time I have spent on finding a workaround and I don’t want to be pulled through something like that again. I depend on my Apple computers to get my work done and I have learned that that dependancy is an unreliable one. I have learned that Apple doesn’t take regressions seriously. Because that’s what this was; a regression. Not some bug introduced in a newly released feature. No they broke something that used to be working and that I was depending on for my day-to-day work and they didn’t take it seriously.

So I leave it up to other Apple users to try out OS X 10.5.7 and to report any regressions they might find. I leave it up to Apple to not take these users seriously. In the mean time I’ll stay on OS X 10.5.6 with my workaround and keep wondering what I’m given Apple my money for.

I think I have found a solution to the serious regression with regards to Dvorak keyboard shortcuts in Carbon based applications that Apple introduced with the OS X 10.5.6 update. This weekend I might follow up with a more thorough write up. For now just the solution will have to do as I am short on time.

Unfortunately the solution requires you to have access to an OS X 10.5.5 installation which not everyone might have at their disposal. It basically boils down to replacing the 10.5.6 installation’s /System/Library/Frameworks/Carbon.framework with that of the 10.5.5 version. I haven’t tested it extensively. In fact I have only confirmed that cmd-c and cmd-v finally work again in Eclipse.

The 10.5.6 installation lives in:

/System/Library/Frameworks/Carbon.framework


The 10.5.5 installation is mounted from an external hard drive at:

/Volumes/Bak MacBook/System/Library/Frameworks/Carbon.framework


These are the steps I performed:

$ cd /System/Library/Frameworks
$ sudo cp -Rpv Carbon.framework ~/Temp/
$ sudo rm -rf Carbon.framework
$ sudo cp -Rpv /Volumes/Bak MacBook/System/Library/
Frameworks/Carbon.framework .


BTW the 10.5.6 installation is a PPC one and the 10.5.5 is an Intel one. That doesn’t seem to matter as, as far as I can tell, all the files in the Carbon.framework directory are resource files which are platform independent.

Be careful though. I have barely tested this and hence it might have serious unwanted side effects.

Update:  As it turns out some things do break when reverting to  the 10.5.5 version of the Carbon.framework. For instance pressing ENTER in Finder does not allow you to rename a file or directory anymore. And according to Apple forum user LEgregius it also breaks something in iPhoto. To work around these issues LEgregius has a short shell script that switches between the two versions of Carbon.framework when starting Eclipse. I have adjusted this script slightly to make the switch conditional:


#!/bin/sh
FRMW_DIR=/System/Library/Frameworks
CARBON_FRMW=${FRMW_DIR}/Carbon.framework

if [ -e $CARBON_FRMW -a -e ${CARBON_FRMW}.1055 ]
then
    sudo mv $CARBON_FRMW ${CARBON_FRMW}.1056 &&
    sudo mv ${CARBON_FRMW}.1055 $CARBON_FRMW &&
    echo "Switched Carbon.framework 10.5.6 -> 10.5.5"
fi
open -W /Applications/eclipse/Eclipse.app 
if [ -e $CARBON_FRMW -a -e ${CARBON_FRMW}.1056 ]
then
    sudo mv $CARBON_FRMW ${CARBON_FRMW}.1055 &&
    sudo mv ${CARBON_FRMW}.1056 $CARBON_FRMW &&
    echo "Switched Carbon.framework 10.5.5 -> 10.5.6"
fi


Finally got a response from Apple in response to my bug report. According to Apple:

This is a known issue, which is currently being investigated by engineering.

No hint as to when we can expect a fix though.

Almost two weeks after the release of the OS X 10.5.6 update Apple still hasn’t provided a fix for the serious regression with regards to Dvorak keyboard shortcuts in Carbon based applications. Worse they haven’t even indicated that they’re working on it or provided a timeline for a fix or temporary workaround. I did open a bug report with Apple on https://bugreport.apple.com. However as these bug reports are not public it is impossible for others that have been affected by this bug to subscribe to it. Furthermore it arguably makes it difficult for Apple to track how many people have been affected by this issue. Although the thread 10.5.6 breaks Dvorak keyboard shortcuts in Eclipse on the Apple Support Forums makes it clear this issue is causing problems for many people using just as many different applications.

With Apple not taking their responsibilities I figured I’d give it another try to find a workaround. Problem is that I am no OS X developer and though I do know the basic difference between Carbon and Cocoa applications I know next to nothing on OS X application development. So all I have to go on is my intuition and hints I find on the Web.

With some of the keyboard  shortcuts working (cmd-s) and others not (cmd-c, cmd-v) I still suspect the culprit to be with an incorrect keyboard mapping instead of some logic error in a piece framework code. I my previous post I created a new Dvorak  mapping and installed it. This didn’t solve the problem as it didn’t change any of the mappings specified in the Carbon Framework. At least that’s what I suspect the reason to be.

So is there a way to adjust the mappings in the Carbon Framework? It seems there is. Hinted by references to HIToolbox in the Eclipse bug report on this issue, and a path to this part of the Carbon Framework mentioned on http://wordherd.com/keyboards/ I figured I had to replace the Dvorak mapping in:

/System/Library/Frameworks/Carbon.framework/Frameworks\
/HIToolbox.framework/Resources/English.lproj/Localized.rsrc


Using ResKnife, an open source resource editor, I had a look in Localized.rsrc and did indeed found a Dvorak KCHR resource (with ID 16300). With the form on http://wordherd.com/keyboards/ I created a layout.r using the following settings:

In the resulting layout.r file I changed the type “uchr” to “KCHR” and its ID to 16300. Then I made a backup copy of Localized.rsrc and executed:


gkoller@Kardamom (593) $ /Developer/Tools/Rez -append -useDF -o \
/System/Library/Frameworks/Carbon.framework/Frameworks\
/HIToolbox.framework/Resources/English.lproj/Localized.rsrc \
layout.r


Another look with RezKnife revealed that the old Dvorak mapping had indeed been replaced with the new one. I restarted my computer, fired up Eclipse, and …. *damn* it still did not work.

For all I know my attempts to find a workaround are completely misdirected and naive, but I just had to try as this issue is driving me nuts. Maybe this post might give others a few hints and put them on the right track to find a solution, or more likely prevent them from wasting time on similar futile attempt. However it would be much better for Apple to step in and take their responsibility in fixing this regression!

Tried to find a workaround for the nasty Dvorak keyboard mapping bug introduced by Apple with their 10.5.6 update of OS X. I had the idea that if I could create a keyboard mapping for Dvorak myself, this might ‘trick’ OS X accepting the proper keyboard shortcuts for Carbon based apps. Looking for a tool to create such a mapping I came across the following website:

http://wordherd.com/keyboards/

Using the standard settings it was easy to create a new Dvorak layout, save it as “Dvorak Workaround.keylayout” in my Library/Keyboard Layouts directory, and select it from the Input Menu in the International System Preferences menu. Alas, this did not resolve the problem.

This might have worked if problem was in the Apple default Dvorak keyboard layout itself. However if that was the case keyboard shortcuts would have been messed up in Cocoa based applications as well. It was a long shot to begin with, but I had to try something as it is really impacting my ability to do any programming in Eclipse on my Mac.

It might be due to the holidays or the relatively low number of users impacted by this bug (who uses Dvorak?), but I find Apple slow to respond to this serious regression.

This evening I installed the PyDev plugin for Eclipse to write a little Python code. Seemed to go well until I noticed that some of my keyboard shortcuts didn’t work anymore in Eclipse. Most notably copy and paste (CMD-C and CMD-V). As this was working before I figured the PyDev plugin to be the culprit. However, in a version of Eclipse without the PyDev plugin the issue was still present. 

Some Googling turned up a post on StackOverflow titled Eclipse keyboard shortcuts broken in OSX 10.5.6. Turns out that the OS X update to 10.5.6 I did a couple of days ago broke the keyboard short cuts for Eclipse. But only if you’re using Dvorak keyboard layout. Guess what I am using? Right, Dvorak!

I knew I should have waited a little longer with the update. I normally do. Not sure why I didn’t this time. Sincerely hope Apple comes out with a fix quickly.

Being a contractor I have to sent my customers an invoice every month. With regards to payment terms I generally settle on a pretty standard 30 day credit period. However sometimes the customer and I settle on a slightly different credit period. Regardless of the credit period I always have to think carefully what the final due date will be. It’s nothing complicated, the calculation being a simple modulo operation, but I always have to determine the number of days in a given month in order to use the correct divisor.

Eg. given today’s date, October 8th, 2008, a credit date of 45 days results in a due date of:

(8 + 45) % 31 = 22

November 22nd, 2008. The 31 being the number of days in October.

However I recently found out that the date command under OS X can do this even more easily:

$ date -v +45d
Sat Nov 22 21:11:56 CET 2008


The parameter -v is the adjust parameter. It not only handles days as in the example above, but all the other units of time as well. Simple and convenient.

More people unhappy with Leopard’s quality. The announcement of Snow Leopard is encouraging were it not for its requirement of an Intel processor. I guess Leopard 10.5, in all its lack of quality, will be the last major release for my iMac G5.

This happens when I archive an IMAP mailbox from Apple Mail as an mbox and then reimport it again under a new account:

Process: Mail [318]
Path: /Applications/Mail.app/Contents/MacOS/Mail
Identifier: com.apple.mail
Version: 3.3 (924)
Build Info: Mail-9240000~1
Code Type: PPC (Native)
Parent Process: launchd [79]

Date/Time: 2008-06-11 21:06:57.158 +0200
OS Version: Mac OS X 10.5.3 (9D34)
Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000010
Crashed Thread: 14

Apple Mail can’t even import what it archived. Madness!

Many years ago I was able to force an incorrectly formatted mbox into a correctly formatted one using ‘formail’. Not sure if the mbox created by Apple Mail was incorrectly formatted, but I gave it a try anyway:

formail -ds <archived.mbox >>fixed_archived.mbox

No luck; Apple Mail still keeps crashing.