For information on how to enable the root user in Mac OS X Mavericks, see this tech note from Apple:
And for doing the same with OS X Mountain Lion, see this tech note:
Now that I have bugzilla set up, my clients are starting to use it. It’s a very useful tool for logging bugs, feature requests and test results. The clients get kept up to date on what I’m doing, and I don’t have to remember every thing as it is all kept in the database.
That means that the database has to be protected from loss or damage by taking regular backups.
Finally I have gotten round to finishing the install of BugZilla on OS X Mavericks (OS X 10.9)
and I’m pleased to say it is working well.
There were several hurdles along the way, but the main one which kept bugzilla from running was that the MySql library, required by perl to access MySql was installed in a different place than the _www user group expected to find it.
After installing Perl, MySql and BugZilla the main bugzilla install script kept failing with errors trying to connect to the MySql database.
I designed a digital audio dock for a major client. The dock accepts both 30-Pin apple devices and Lightning-connector apple devices, in other words almost all iPods, iPhones and iPads. The dock has a network interface so that it can connect to, and be controlled by, other devices, such as another iOS device. The device can get track metadata, playlists and track lists from the dock.
During testing we noticed that on occasion the track name, artist name or album name would not display correctly. For example, the soundtrack album from the film “Les Misérables” would show as “Les Mis√©tables”.
This is because the device providing the meta data is using the UTF-8 encoding mechanism to encode special characters, i.e. those outside of the usual 8-bit ascii character set.
In our code we had were receiving the 8-bit string and encoding it to an NSString like this:
_strDockAlbum = [NSString stringWithFormat:@"%s",pContents];
where pContents was a pointer to the 8-bit data buffer.
To resolve the issue was simple, thanks to the stringWithUTF8String method of the NSString class.
The code now looks like this:
_strDockAlbum = [NSString stringWithUTF8String:pContents];
Microchip have released an update to their IDE, MPLAB X.
MPLAB X IDE v1.95 is available now for download from here
This seems to be a minor point release with the following main updates since v1.90
On windows MPLAB X now uses the latest Java JRE (v1.7) but on Mac OS X we are still stuck at JRE 1.6 which is a bit of an issue, because OS X will try to push the latest Jave Update to users and many of them will accept it, pushing the system up to JRE 1.7, which breaks various things in MPLAB X. Of particular concern is that one of Microchip’s flagship programmer/debuggers the ICD 3 doesn’t work when JRE 1.7 is present. If a user updates their Mac to JRE 1.7, then it’s not an easy job to revert back to 1.6.
I believe the underlying issue is that MPLAB X is built on NetBeans, and Microchip is using an older fork of NetBeans with some out of date JRE dependencies.
Let’s hope we can convince Microchip to move to being JRE 1.7 compatible pretty soon.
Recently Cypress Semiconductor released the long awaited version 3.0 of it’s PSoC Creator development tool suite.
This is an update I’ve been waiting for, it finally brings to Creator some features which other, older, IDEs have had for many years, including: Auto-complete; go to definition; a code explorer window; inline diagnostics; disabled code identification and automatic indenting. These are all things that every other IDE I use has had for 6+ Years, including Visual Studio, NetBeans and Eclipse.
So I was truly pleased when this update arrived, as it promised to be a great aide to productivity.
As it happens, however, it turns out to be one of the biggest disappointments from Cypress yet.
Well, despite my earlier success I have to declare that, for me at least, The Microchip ICD-3 In Circuit Debugger is not compatible with OS X Mavericks.
I have opened a ticket with Microchip tech Support, so we’ll see what transpires.
I’ve been tracking down an elusive bug which was causing one of my devices to occasionally start mis-behaving. The device would respond slowly (if at all) to some commands, and respond normally to others.
It was pretty obvious what the issue was when I attached the debugger and started single-stepping through the code while it was misbehaving.
I landed on the ‘return’ in this code:
prevLen = sizeof(LIST_ITEM)+32; pWorkItem = malloc(prevLen);
if(pWorkItem == 0) return 0;
so it was obvious I was getting a malloc fail, which meant I had ran out of memory somewhere along the line. The ‘return 0’ meant that the command silently failed, without any feedback to the user.
Guess who is not going to Apple’s Tech Talk in London this year?
Yip – I just got an email saying I wasn’t successful at getting a place this year. Places on these seminars are like hens teeth!