The tool is set out in two phases, the first phase consists of the tones white, black, light gray, gray, and dark gray. These will let you spot the easy pixels, gray is nice as you’ll be able to see if the panel is evenly lit. The second phase is just an RGB test, cycles red, green, blue, yellow and magenta. This will show any pixels that are stuck in those main colours.

It’s pretty simple and a tiny download written in Java so you’ll need Java installed. Mac OS X users have the Java system by default, Windows users will need it, thats if you don’t have it already, most people do. There is a Read Me included in the download with full instructions.

Any problems / help, or if you have something to say let me know.

With this I mind I got the source code for the last of the standalone versions 1.62.3, it does everything, and doesn’t have a massive dependency problem like the recent versions. I made a small change to the source, compiled it and life is good again, much easier than compiling for 10.5 and all that bag of hurt of the older versions :)

The reason I have suddenly posted this is I have just re-compiled Streamripper for Snow Leopard using the new Clang and LLVM-GCC compilers. As all of Snow Leopards utils are in x86-64 I did Streamripper as x86-64, a few years back I never thought I’d be compiling Streamripper as 64-Bit just seems overkill, but why not :)

I won’t bother with all the building stuff like my last post on the subject as it’s not that hard really.

Enjoy!

XCode Colours (RGB)
Selection: 167, 201, 255
Comments: 0, 116, 0
Documentation Comments: 0, 116, 0
Documentation Comments Keywords: 2, 61, 16
Strings: 196, 26, 22
Characters: 28, 0, 207
Numbers: 28, 0, 207
Keywords: 170, 13, 145
Pre-Processor Statements: 100, 56, 32
URLs: 14, 14, 225
Attributes: 131, 108, 40
Project Class Names: 63, 110, 116
Project Functions and Method Names: 38, 71, 75
Project Constants: 38, 71, 75
Project Type Names: 63, 110, 116
Project Instance Variables and Globals: 63, 110, 116

Default font: Menlo 11

I really like the colours of the syntax highlighting in Apple’s XCode, I apply the colouring to all of the other code editing applications I use, these being Netbeans and BBEdit.

XCode Colours (RGB)
Selection: 173, 206, 253
Comments: 0, 116, 0
Documentation Comments: 0, 116, 0
Documentation Comments Keywords: 0, 116, 0
Strings: 196, 26, 22
Characters: 28, 0, 207
Numbers: 28, 0, 207
Keywords: 170, 13, 145
Pre-Processor Statements: 100, 56, 32
URLs: 14, 14, 225
Attributes: 131, 108, 40
Project Class Names: 63, 110, 116
Project Functions and Method Names: 38, 71, 75

The main tools are located in /usr/bin. In this folder you will find both gcc 4.0 and 4.2 along with g++ 4.0 and 4.2. The commands gcc, g++, cc, and gcov are all symbolic links to the default 4.0 versions. To make 4.2 the default we just need to modify the symbolic links.

To do this we need to go in to the Terminal and issue the following commands:

Now you should have a complete working gcc 4.2.1 tool chain. If there is a problem you can verify the symbolic links are pointing at the correct targets by typing ls -l Hope this helps someone else.

Anyway this afternoon I noticed that Safari kept using 100% CPU and becoming un responsive. I kept force quitting it but the problem kept coming back after about 10 mins. I tried the usual repair permissions, delete preferences and caches etc to no avail. I then thought I would try the Safari 4 Developer Preview, I downloaded it and installed it. It was perfectly stable and very fast, can’t wait for the finial release of that badboy! At this point I was still stumped as to why 3.2.1 was holding the CPU hostage but Safari 4 was fine. I uninstalled Safari 4 and reinstalled 3.2.1.. On restarting everything seemed fine but yet again it took all the CPU, back where I started. Just launching Safari and then closing the window and waiting would cause the CPU to be held hostage again.

I ran a filesystem trace to see what files Safari was touching, I basically sat and waited until the high CPU condition happened then took a look to see what files were accessed. After an hour of watching and timing the problem it seemed that Safari was continuously reading from the filesystem which is what was causing the massive CPU load. It was triggered by an unusual cache file hit, I did a check to see what network connections were established and saw some odd looking google server addresses, it then dawned on me that Safari 3.2 features anti-phishing protection that uses a blacklist provided by google.

This also explained why the the Safari 4 Developer Preview worked correctly as it doesn’t yet have the anti-phishing stuff. I turned off the anti-phishing stuff in Safari 3.2.1 and sure enough everything went back to normal. Me being me I was still bothered because why would it suddenly cause problems, it’s been working fine until today. I went back and took a look at the cache files it was using for the blacklists, I thought that corruption of some kind was most likely so I deleted them. I then re-enabled the anti-phishing mode in Safari 3.2.1, now been three hours and all is well again.

Relaunch Safari and all should be well. I couldn’t find any references to this problem online so I though I would post something.

I thought I would check my old email account and got a nice total of 4124 messages! Every single one was junk. Apple Mail’s Junk mail filter caught 4122 of them so thats an accuracy of 99.95% very impressive! I thought I would dig a little deeper and ran a virus check on the emails, 37 were infected with various trojans, viruses, and general nasty spyware. Pretty interesting, I haven’t actively been using that account since about 2003 / early 2004, since then I haven’t sent anything from the account and have been looking now and then at what comes in, and from who. I think it’s time to forget that mailbox.

To use the bookmarklet just right click and bookmark This link

Any questions or praise let me know!

I then decided to test the performance of them, I wasn’t very scientific I just used the stopwatch on my iPod to time the encode of a song. I encoded the same song using the –best option three times with each just to make sure that no caching was happening and the result was as accurate as I could get it. The outcome was pretty interesting.

PPC/x86 Universal Binary
28 Seconds

PowerPC G4 Optimzed
10 Seconds

Thats quite a difference!

I then found something pretty odd, if I encoded the track with the G4 version and tried to decode it using the Universal version I would get the error “ERROR, MD5 signature mismatch” and vice versa when encoding the other way round, very odd. I tried decoding both encodes with a third party app and that decoded both fine. I’ll encode a song and see if someone else has a problem decoding it.

If anyone wants a copy of my binaries let me know and I’ll package them up for you to play with.

Whats New:

• Completely new Javascript.
• Links checked and fixed, some removed and new ones added.
• More Update options.
• Updated looks and Phasenoise logos.
• Smaller Download

Merry Christmas!