Thanks to RapidWeaver for deleting my custom template again during an update I did not have time to post during June, sorry for that. In fact, I’m not sure which one is at fault here: MacOSX or RapidWeaver. During the initial creation of this blog, I made a custom template from an existing template called Interslice to add support for Google Adsense and to clean it up a bit to my personal taste.
The pain here is that RapidWeaver stores the templates inside its own application bundle, rather than in a separate folder. (For those not in the know, application bundles are just folders with a very specific structure, an “.app” extension and a custom icon).

Furthermore, when updating RapidWeaver, it downloads a new application bundle as a dmg file, automounts it and opens the folder, just like when you want to install a new program. Many apps update the existing bundle in the Applications folder instead and let the application automatically restart.
So when you update, you perform the same procedure as during normal installation. This would be fine if MacOSX didn’t completely replace the original application bundle, removing my templates in an unrecoverable fashion; The original bundle is not put in the trashcan, but is unconditionally erased from the harddisk!

This is an old design flaw in MacOS Finder that goes all the way back to MacOS1.0, but Apple has decided to keep this functionality of having the move operation being unrecoverable and atomic. This is the single-most stupid part of MacOSX!
If you are a pure mac user, not having used other platforms much, you will find the behavior quite logical. For the rest of us, it’s highly annoying and a dangerous operation to have in an operating system that normally shines on security and usability, because move means folder merging to us. It also makes it a complete nightmare to merge nested folders, something I do often, so I have to resort to the Terminal or muCommander to do that.

But still, even if a folder is replaced, why doesn’t MacOSX Finder just move the older folder to the trashcan instead of completely deleting it?

Wordpress

I was briefly looking at Wordpress to see if a web based blogging solution would fit me. Indeed Wordpress has a lot of momentum, a lot of plugins, themes and users. There are even applications like MarsEdit that plug in to Wordpress, so you can write posts offline and have them posted when you go online.

But after looking through about a hundred different themes I came to a simple conclusion: They suck. They are pretty to look at, but none of them are practical and the simple ones are too simple (i.e. no plugins allowed). So I went back to RapidWeaver.

The color and blitting bugs in the Intel version of REBOL 2 for MacOSX have finally been fixed, but it has a price to pay in that R2 for MacOSX Intel is slower at displaying graphics than the first Intel version. As we already know, Apple are in the process of kicking QuickDraw out the door, so Quartz can have full reign in the world of MacOSX and that means REBOL must follow suit, so the new version is based on Quartz. It's only one page of C code to change, but it's problematic as it is, giving us two problems:

- The colors are wrong. They always were, but moving to Quartz did not initially solve the color problem.
- The coordinates for what regions to blit in a View window are wrong, which gives misplaced and stretched graphics elements.

The first problem is partly due to the move to Intel, which uses a different bit ordering for blitting and not being able to feed Quartz with the correct color format. The first version did not use Quartz and therefore did not show the blitting problem:

Original Intel version with incorrect colors

After consulting an Apple developer, the color bug was fixed after moving to Quartz, but the second problem then occurred. It has been worked on for some time, but has proven to being troublesome because Carl has had trouble figuring out the correct coordinate system to use. Incorrect blitting looks like this:

Well, that just doesn't work, does it?

Due to time constraints and a strong desire to continue the development of REBOL 3, the blitting routine was changed to blit the whole window instead. This causes a minor slowdown, but it certainly looks far better:

Back to normal

Fonts are still a problem in MacOSX Leopard, though.

Release date is currently unknown.

First some status updates on REBOL/View for MacOSX:

REBOL/View now works on MacOSX Leopard. There are at least two font problems under MacOSX Leopard. One font problem is what causes REBOL/View 1.3 to crash under Leopard. The other is what causes fonts not to be read under Leopard.

Read More...

A new release of REBOL/Core for intel mac was published today. You can read more about it here.

Here are some cheap benchmarks on MacOSX Leopard on a 2 Ghz Santa Rosa Macbook with 4 GB RAM and Leopard on a 1.25 Ghz G4 PPC Mac Mini with 1 GB RAM:

>> t: now/precise repeat i 10000000 [set 'a true] difference now/precise t  

== 0:00:13.598378 ; PPC G4

== 0:00:06.310057 ; Rosetta

== 0:00:02.427662 ; Intel

Inserting 1 into a block 100000 times (because you know, we do that all the time):

>> a: make block! []

>> t: now/precise repeat i 100000 [insert a 1] difference now/precise t   

== 0:05:57.933257 ; PPC G4 (wow!)

== 0:00:22.498992 ; Rosetta

== 0:00:06.623004 ; Intel

Looks like I struck a nerve with the G4 here. I ran the test twice to make sure it wasn't erratic or that the machine was swapping, causing the test to slow down, but I got 0:06:11.605227 on the second run. Interesting. If you get anything else with a similarly specced machine, sound off in the comments.

The console benchmark test from rebol.org:

PPC G4:

>> do http://www.rebol.com/speed.r

connecting to: www.rebol.com

Script: "REBOL Quick and Dirty Speed Test" (none)

Running...

........................................................................



Console:   0:00:04.612143 - 109 KC/S

Processor: 0:00:01.722944 - 501 RHz (REBOL-Hertz)

Memory:    0:00:03.01248 - 15 MB/S

Disk/File: 0:00:02.041244 - 14 MB/S

I knew the terminal under MacOSX Leopard was never going to be a speed demon with a G4 mini, but 14 times slower console output than Intel native?

Rosetta:

>> do http://www.rebol.com/speed.r

connecting to: www.rebol.com

Script: "REBOL Quick and Dirty Speed Test" (none)

Running...

........................................................................



Console:   0:00:00.665528 - 760 KC/S

Processor: 0:00:00.872422 - 990 RHz (REBOL-Hertz)

Memory:    0:00:02.083128 - 22 MB/S

Disk/File: 0:00:00.62334 - 48 MB/S

Now the console might be off here, since it's Intel native, which makes it gets an automatic speed boost here, so the comparison in that respect might not be fair.

Intel:

>> do http://www.rebol.com/speed.r

connecting to: www.rebol.com

Script: "REBOL Quick and Dirty Speed Test" (none)

Running...

........................................................................



Console:   0:00:00.355696 - 1423 KC/S

Processor: 0:00:00.30406 - 2841 RHz (REBOL-Hertz)

Memory:    0:00:00.567992 - 83 MB/S

Disk/File: 0:00:00.42605 - 71 MB/S

That's more like it!

I'm impressed, both that the Intel version is much faster, but Rosetta, the PPC emulation is not too bad either, as it easily outruns my trusty old G4, sometimes by up to 50 times. Looks like Steve Jobs made the right choice when switching to Intel, or there are some things left to optimize for the PPC version.

Unfortunately we can't do any graphics tests, as this only is a port of REBOL/Core. REBOL/View does not yet work on clean installs of OSX Leopard due to font problems which causes a crash and REBOL/View never starts. As some time has been scheduled for working on a REBOL 2.7.6 release this week, REBOL Technologies will be working to fix this problem.

Happy New Year!

And now for something more serious: As it turned out, turning off the spinning terminal indicator is not only important in the console. It's also important, if you are launching your process as a service using Launchd, the standard way to handle background services under MacOSX, because Launchd logs all output from a process in /var/log/system.log. Read More...