Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts tagged XRay

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.

Well, here I’m plugging away at XRay II and making reasonably good, if at times uneven, progress.

People ask now and then how I work. Just now I was reflecting on how, sometimes, reams of code get turned out on one day and then almost nothing on another day. Or how, sometimes, many parts are changed or refactored, while at other times updates are confined to a single routine or source file…

It may just be true for my style of programming, but I now see the process resembles very much the way a Mandelbrot Set is plotted. I start out with an empty project and iterate over everything repeatedly, adding a handful of code at a time, zooming in on as much details as is needed, then zooming out again to recheck the broad outlines, then zooming in again elsewhere.

I never manage to plan ahead how it will work, except for having a broad idea of what I want to do, and often I need to change direction radically at some point, either in fine or broad detail. Sometimes I need to take off for hours or days (or even months, as was the case for RBSplitView) to investigate a possible solution. I spent a couple of months learning about WebKit to format my information, only to run into trouble on some details and abandoning it again.

Then, of course, there are phases where it seems necessary to refactor some stuff that’s already done, either to make it smaller, more elegant, or just nice to look at – even if nobody else ever sees this code. It makes for slow progress sometimes, but the results are usually very satisfactory.

Re: Packing

No comments

Posted by Rainer Brockerhoff (away):
We’re back in Buenos Aires, on the way home. All’s fine and I’ve lots of pictures to post later.

I’ve also made excellent progress working on XRay 2. Most of the infrastructure is now in place and part of the plug-in architecture too. More on that next weekend when I get back.

Progress, whew!

No comments

A couple of days ago I managed to finish off most of my remaining offline problems and, since I’d seen news that the ADC Compatibility Labs now had the new iMacs for testing, applied for a couple of days at one of them.

No, I’m not going to Cupertino, but rather wanted to try out Xcode’s Remote Debugging.

As a result, I now can confidently say that XRay 2 will be fully compatible with the new Intel Macs. I’ll also be licensing the new Universal logo.

It’s rather late in the day, but tomorrow I’ll post technical details…

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.