Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts in Software

Since yesterday, we’re safely ensconced at a nice hotel in downtown San Francisco, where we’ll stay for 4 weeks – leaving just after WWDC.

The trip up to Corvallis (OR) was marvellous, especially the visit to Crater Lake. It’s the prettiest lake I’ve ever seen, and I’ve seen quite a lot. All this took a little more time and energy than we’d budgeted for, and after visiting with some friends we passed up a chance to see the famous DaVinci Days Festival. Instead, we opted to just walk around the beautiful Oregon State University campus, which was well worth the visit.

Going south the next day we opted for the more scenic 101 route (instead of the 5, which we’d driven up on), and it also was great. The Pacific shore is always beautiful and we also had an opportunity to revisit Ferndale, where we’d been on a previous Los Angeles-Vancouver trip.

So, everything’s settling down and for the next 3 weeks I’ll try to do some extra work on XRay II. Hopefully I’ll have a working alpha to show off at WWDC. Or at least a T-Shirt… icon_wink.gif

I’ve finally solved a vexing problem that has been affecting version checks for my software.

Basically, checking for updates inside of XRay and Zingg! asks my webserver for a .plist file which contains the latest versions of everything, along with a brief message. On the server, however, this is actually a PHP script which also stores the user’s system version – which is appended to the URL – into a small database.

Since I changed over to DreamHost, my server has been set to gzip everything it sends if the receiver is capable of decoding gzipped files. However, for some time – not sure when that changed – this has messed up my version checking, and users would get a “website was unreachable” error. I did get some reports about this every couple of months, but always had attributed it to a network glitch somewhere… until I tried it myself and got consistent errors.

I read the .plist file directly using +[NSDictionary dictionaryWithContentsOfURL:]. Some combination of Cocoa, php and server parameters now causes the result to be gzipped, and NSDictionary doesn’t understand that format. Anyway, once I figured it out, I had to find a way to turn gzipping off for this particular file only, as I can’t change all the old software versions that are out there.

So, for now, adding this statement at the front of the php part of the file solved it:

header('Content-Encoding: UTF-8');

Strangely enough, rfc2616 says:

The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens:

gzip…

compress…

deflate…

identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header.

…and that’s it. No “UTF-8” is mentioned, so why is it working now? I tried “identity” (before seeing the SHOULD NOT comment) and it had no effect at all. I suppose I should try to debug this on my local server adn see where the problem lies, but time is short…

I don’t plan to use this method in XRay II, so it’s not urgent. I’ll probably use Andy Matuschak‘s Sparkle, of which I’ve had good references.

Re: Progress!

No comments

Now that XRay II’s file browser is working reasonably – some edge cases excepted – it’s time to refactor the GUI, and to worry about how this will affect the internal architecture.

I had an excellent discussion yesterday on #macsb about the possibility of adding AppleScript support. My interest about this was renewed by Daniel Jalkut’s discussion of adding minimal scriptability to a Cocoa application. Seems that the AppKit already has such support built-in, and you get it for free by turning on one option in the app’s .plist file. Daniel gave me some very good suggestions on #macsb, and I’m seriously investigating the possibilities at this time…

My previous experiences with AppleScript were not very good. The syntax itself is confusingly English-like: it sorta kinda looks like English – and verbs and whatever are chosen to make it even more so – but there’s no flexibility at all. The few times I had to write (or change) a portion of AppleScript took me hours with the manual opened in one window and the editor in another.

When I wrote the Aurélio Eletrônico – a Portuguese dictionary app – waay back in the Mac OS 8 days, at one point someone convinced me to build in AppleScript support. At the time, this was done by CodeWarrior’s PowerPlant classes and I seem to remember that most of it actually worked. However, I never got around to documenting what exactly had been implemented, and to the best of my knowledge, no user ever needed it for anything.

Adding scripting to XRay II would have advantages and disadvantages. My original plan was to pitch it as an exploratory sort of utility… a way to look closer into the innards of files and bundles, and to find out their structure. And, eventually, to edit some small part here and there. However, it seems that there’s serious demand to do batch processing; people want to add filetypes to all .mov files inside a certain folder, etc. Or, once a certain tweak to a file has been done, this tweak must be repeated periodically – from inside an Xcode build phase, for instance.

Allowing such functionality would of course expand XRay II’s uses enormously, but it also would make the responsibility much greater. It’s easy to completely bork up the system by running a buggy script, much more so if the scripted app can run with privileges. The internal structure would also be changed. I’d have to be more canonical in implementing the Model-View-Controller pattern and be careful to separate the user interface from actions on data; something I’ve been known to sacrifice, sometimes, for efficiency and code compactness.

At any rate, this offers an opportunity to learn something new, and to make XRay II even more powerful. Stay tuned for more news about this.

Re: Progress!

No comments

We had a nice short vacation visiting friends in Campanha, in the interior of Minas Gerais, Brazil. This is a small town, almost equidistant from Rio de Janeiro, São Paulo and Belo Horizonte, and the main focus is coffee and tangerine plantations. I’ve posted 10 selected photos and maybe later I’ll post some more.

Meanwhile, I’m glad to report that XRay II is slowly getting back up to speed. I lost over 2 months doing premature optimization… yes, I should have known better, but it snuck up on me in the form of caching.

The file system browser in XRay 1.x was an afterthought, tacked on because I needed to check out many files to test. I used Apple’s SimpleBrowser sample code nearly as-is and only cached each item’s 16×16 icon. It worked amazingly well, but it didn’t react properly to events like volume mounting/unmounting and folders changing.

One of the first things I did for XRay II was to make a better browser. I also decided to use the same backend data structures for the browser and for the object that represented the file item being XRayed. Of course this meant that the icon had to be cached in each object, as well as the name, the FSRef, the pointer to the parent folder… then I thought, I’d also better cache catalog info results, metadata, etc. etc., as all this would be needed later. Soon this object grew like topsy, adding all sorts of interesting information about the file item, each added lazily whenever requested…

…but it turns out that it became increasingly complex to keep this back-end cache synchronized with the actual file system. In fact, everything I did to optimize the cache internally made it more difficult to do external synchronization.

So, over the last month I basically started out from scratch with the back-end and, as soon as possible, implemented mount/unmount modifications, and folder change notifications (using M. Uli Kusterer‘s excellent UKKQueue). It turns out that it’s basically unproductive to cache anything but the name and icon… except, of course, while an item is being XRayed.

More as it happens…

OK, so here are the details on remote debugging; I’ve finished this phase of XRay 2 development and will in the next few weeks be fully available for pressing on with it.

The basic idea is that I have only PowerPC Macs, and since nobody I know in Brazil has received an Intel Mac (except for a couple of DTKs, which I didn’t want to use), the solution was to use Xcode‘s remote debugging capabilites, running my executable at a machine in the ADC Compatibility Labs. These are open at no extra charge to paying developers, but most of what I’ll detail would apply to any other machine.

Most of it is explained in the Xcode User Guide. Note that I used Xcode 2.2.1, but I think this facility has been available at least since 2.0. Click on the “Remote Debugging in Xcode” section in the left frame. First, however, send e-mail to adc.labs(at)mail.apple.com and ask for machine time, explaining for how long you need the machine; I asked for 3 days (thanks, Joe Holmes!). Basically, they’ll set up a newly formatted Mac with everything standard installed, including the latest developer tools. You should check that you have the same version, I suppose. They’ll have ssh and Apple Remote Desktop activated, and will send you the IP address, usercode and password. For illustration, let’s say the IP number is 10.1.1.1 (NOT an actual IP!), the usercode is “adclabs” and the password is “stevejobs”; substitute the actual values as appropriate.

In other words, all you’ll do there will be inside the default home folder “adclabs”. This user is also an administrator, so you’ll be able to use the password whenever needed for that. If you have a second Mac handy, you could rehearse first with that, of course; it’s what I did, as I’m normally not that handy with the Terminal. (Thanks, by the way, to John C. Randolph, Mike Ash and several others for helping me with details.)

First step is to generate a public and private key pair; you can skip this if you already have done so in the past. Open Terminal and type:

ls ~/.ssh/

If it lists a few files, among them one called “id_rsa.pub”, you already have a key pair. If not, type:

ssh-keygen -b 2048 -t dsa

This will take about a minute and then prompt you for a file path; type <return> to use the default path. It will then prompt you for a passphrase, twice. Don’t leave this empty and don’t use too short a phrase. You now should have the id_rsa.pub file in the ~/.ssh directory.

Second step is to open Terminal and type:

ssh adclabs@10.1.1.1

wait for the Password: prompt and type in “stevejobs”, or whatever password they sent you. You should see the normal Terminal prompt now, with a name like “CE-Lab-ADC-Compatibility-Labs-Intel-iMac” at the start of the line.

Now you’d better change the password to the same passphrase you used for the RSA key – yes, usually it’s recommended to use different passwords here, but that way you won’t have to remember which one to use where; it’s just for a couple of days, anyway. Type

passwd

and you’ll be prompted for the original password, then twice for the new password. Create a .ssh directory with

mkdir ~/.ssh

and log out by typing

exit

Next step is to transfer the public key to the remote Mac. To do this, at your local prompt, type

scp ~/.ssh/id_rsa.pub adclabs@10.1.1.1:~/.ssh/authorized_keys

it will ask for your password again, and transfer the file over. Now log in again with:

ssh adclabs@10.1.1.1

and if all is well, it won’t ask for your passphrase or password again, but just log in. Now restrict permissions on your key by typing

chmod go-rwx ~/.ssh/authorized_keys

Now you need to set up a local build folder. The trick here is that both machines should see your build folder at the same absolute path. There are several ways to achieve that; on a local network, you could have one of the machines serve the entire folder to the other, then use symbolic links to map the same path. However, I found that over a long distance it’s most efficient to have mirrored folders at both machines, and copy the contents over with an extra build phase. Here’s what I did.

At the remote machine, type

mkdir ~/build

which will create an empty build folder in the Home folder. Log out and close Terminal.

Now, on your local machine, you need to prep Xcode for what you’ll do. Double-click on your main project group and go to the “General” tab. Click “Place Build Products In: Custom location” and type in “/Users/adclabs/build” as the location. (Supposing, of course, that you don’t have a user called “adclabs”…)

Also check “Place Intermediate Build Ïiles In: Default intermediates location”, which probably will already be checked. Now click on your target and, from the Project menu, select “New Run Script Build Phase”. Make sure the new build phase is the last one, and enter this line as the script:

rsync -rz /Users/adclabs/build adclabs@10.1.1.1:/Users/adclabs

Finally, double-click on your executable in Xcode, and in the “Debugging” tab, select “Use Pipe for standard input/output”, check “Debug executable remotely via SSH”, and in the “Connect to:” field, type

adclabs@10.1.1.1

Now you’re ready. You’ll notice a delay of a few minutes while the last build phase transfers the files over, and on the start of a debugging run there’ll be several errors logged to the debug console, but eventually you’ll be debugging and single-stepping as usual, albeit more slowly. For GUI debugging, of course, you’ll have to use Apple Remote Desktop; I wish Apple would include a 1-user license for this in the Select package, as it’s rather expensive…

Have fun! I’ve tried to double-check most of this as I typed it in, please tell me if something didn’t work.

Update: fixed a typing error.

Rainer Brockerhoff wrote:

Hm, I really must find some time to update the page with recent users of RBSplitView… I think about a dozen or so…

OK, the page‘s up-to-date now. A couple of other apps are still in beta. Please tell me if you’re using RBSplitView in a shipping application and I’ll include it in this list!

Since releasing RBSplitView 1.1.3 nearly a year ago, lots of people have sent in bug reports and suggestions. I’m using RBSplitView in XRay II, so as soon as I get back to the UI I’ll start working on the new and improved version.

NetNewsWire 2.1 is out, and works much better. I hadn’t read the changenotes yesterday, but today I found this inside:

The splitview is now one-pixel wide, like the kids like so much these days. There?’s a little grabber thing below the subscriptions list too. (Using RBSplitView, which rocks: /src/rbs.html)

Thanks for the kind words Brent! Hm, I really must find some time to update the page with recent users of RBSplitView… I think about a dozen or so…

Tempora Mutantur

No comments

Yes, the times sure are changing. Today I even found myself largely agreeing with a Paul Thurrott article:

Since the euphoria of PDC 2003, Microsoft’s handling of Windows Vista has been abysmal. Promises have been made and dismissed, again and again. Features have come and gone. Heck, the entire project was literally restarted from scratch after it became obvious that the initial code base was a teetering, technological house of cards. Windows Vista, in other words, has been an utter disaster. And it’s not even out yet.

Doesn’t that sound a lot like the ill-fated Copland project?

Sadly, Gates, too, is part of the Bad Microsoft, a vestige of the past who should have had the class to either formally step down from the company or at least play just an honorary role, not step up his involvement and get his hands dirty with the next Windows version. If blame is to be assessed, we must start with Gates. He has guided – or, through lack of leadership – failed to guide the development of Microsoft’s most prized asset.

Perhaps Microsoft’s most serious mistake, retrospectively, was that Gates and Ballmer were too compatible. Ballmer should have driven Gates out of the company in the 80s, then Gates should have matured elsewhere, only to return triumphantly in the 90s with new, cool technology, in the nick of time to save the company that was going broke after Ballmer in turn had been pushed out… sounds familiar, too? icon_smile.gif

Now here’s another interesting part:

Here’s what you have to go through to actually delete those files in Windows Vista. First, you get a File Access Denied dialog (Figure) explaining that you don’t, in fact, have permission to delete a … shortcut?? To an application you just installed??? Seriously?

…What if you’re doing something a bit more complicated? Well, lucky you, the dialogs stack right up, one after the other, in a seemingly never-ending display of stupidity. Indeed, sometimes you’ll find yourself unable to do certain things for no good reason, and you click Allow buttons until you’re blue in the face. It will never stop bothering you, unless you agree to stop your silliness and leave that file on the desktop where it belongs. Mark my words, this will happen to you. And you will hate it.

This is exactly what happened to me when I, a few months ago, had to install Windows XP for my wife’s business (to run a proprietary vertical app, if you must know). I tried to set up an admin account for myself and a normal user account for the receptionist. This being the first time I’d ever seen XP, I did them in the wrong order… and then tried to organize the desktop and taskbars. In the end I had to wipe and reinstall everything. It seems Vista won’t be any better, sadly.

Thurrott goes on to complain about glass windows and the Media Center UI, which I can’t comment on myself. But, here’s a thought:

    One of the “stealth” features of Apple products is that more and more people are being subconsciously educated as to what constitutes good design.

We certainly aren’t that used to columnists criticizing details of the Windows UI; specialists like Don Norman, sure, but not mainstream columnists. Personally, I’d about given up commenting on bad UI to Windows users… they either just emit a blank “huh?” or say somewhat ruefully “well, that’s what computers are like, you know”. Not that the Mac UI is itself perfect – it’s still a work in progress – but at least we developers, and many people inside Apple, deeply care about producing good UI. (Here’s one example among hundreds.) If that attitude is now leaking out to the general public, so much the better.

Thanks to John C. Randolph for pointing out that article.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2024 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.