Solipsism Gradient

Uli Kusterer, Blake Seely and Andy Finnell have posted follow-ups to Brent Simmons‘ comments on the topic. Worth a read, too.

Uli started his comment with:

Rainer Brockerhoff, the man without version control, has posted…

OK, I guess I should seize the opportunity to confess that in the past I have looked a few times into using Subversion (aka svn) for version control. Xcode currently supports cvs, svn and Perforce. cvs, by all accounts, is old, clunky and obsolescent technology, Perforce is commercial and expensive ($800 per user), so svn is the generally used solution.

Turns out that svn was written by Unix geeks who were unsatisfied with cvs and wanted more capabilities while keeping many cvs concepts and terms. (cvs itself was similarly evolved from the even earlier and clunkier RCS.) Unsurprisingly the whole family tree is exclusively command-line oriented and requires significant neuron grease to adapt to. As I’ve said before, I became sick and tired of command-line stuff in my early career and was extremely glad when, in 1984, I could migrate to the Mac where there was no such thing. Now that Mac OS X is Unix-based I do use the Terminal when there’s no alternative, but in general I try to avoid it. So I had a fast look at svn and its documentation, decided it wasn’t worth the trouble, and went on doing other stuff.

But over the last few days, with the generous help of several people – among them Matt Gemmell, Daniel Jalkut, Tom Harrington, Jeff Johnson and several others on the #macsb channel – I at least figured out enough to be able to set up a repository on DreamHost and tinker around with it. The first byproduct is now online: you can now check out RBSplitView from its own svn repository. Enjoy.

Does this mean that Subversion has now subverted me into doing all my future work under its benevolent dictatorship? No. Xcode 2.4.1 crashes seriously when I try to turn on the version control checkbox, at least for my most-important project. I have deduced that this happens because of some sort of data incompatibility between Xcode and the contents of the dozens of bothersome .svn folders that it insists in maintaining inside of the folders it controls. For simpler projects or older projects it works; for my XRay II project it doesn’t. Bah. For what it’s worth, Leopard’s Xcode 3.0 seems to have fixed this problem and supports many more svn features than the current version; so I’ll probably try this again in a few months (Leopard is still not stable enough to allow me to use it for actual work).

I was going to list a long series of stumbling points and oddball nomenclature that led to my spending several days (instead of hours) on doing these things that should be easy and “just work”, but I don’t think I’ll have the energy for that. Significantly, there’s no complete Subversion GUI client available for the Mac – or for any other platform, I believe. Apparently any hypothetical geek with the necessary masterful understanding of the subversion client and server will by definition also be convinced that a GUI interface will be wimpy and superfluous. (He will probably also believe the same of Xcode.) Also, the server side is seriously lacking in functionality; you can’t do things as simple as wipe a repository or exclude files committed by mistake.

To explain my feelings about svn at this point, I’ll try to reproduce from memory one of Isaac Asimov’s favorite jokes, “Levine the tailor”. I think it’s in his autobiography. You may substitute any other name you find hilarious. (I also wish I’d somehow filmed Háj Ross when he first retold me this joke.)

Morris went to Levine the tailor to have his first suit made. Levine took the necessary measurements and told him to come back in a couple of weeks. Back at the tailor’s shop, Morris tried the suit on and found that it was a little roomy around the shoulderblades. He called attention to that, and Levine replied:

“No problem. Simply hunch your shoulders out a little and look down, and the problem will go away.”

Morris did so, but upon looking down, noticed “Hey, the left arm is crooked!”

“No problem, just hold your left hand like this [demonstrates] and twist your elbow out a little. You see? It’s gone!”

Morris again did so, but then looked further down and said, “And this trouser seam isn’t straight either!”

“Still no problem, just swing your heel on that side out just so and all fits perfectly!”

So Morris pays and leaves the store wearing his new suit, feeling slightly duped by the tailor. An elderly couple watches him lurch by [you should demonstrate this while telling the joke]. The woman says “Isn’t that young Morris? He must have been in some serious accident. He’s all bent and twisted!”

And the man replies: “He must have been, but his tailor is certainly a genius, to make such a perfectly fitting suit!”

Brent Simmons has a long and thoughtful post about his way of doing large Cocoa projects. By all means read the original post and the comments. (Good reactions from Michael Tsai, Daniel Jalkut, Wolf Rentzsch, Blake Seely, I must have missed several others.)

Brent highlights some points: don’t overuse notifications, don’t overuse Key-Value Observing, bindings may be overkill for tables and outlines, C functions for global interfaces, flat source folder organization, learn tricks for fast project navigation. I agree with most. My own largest project is nowhere near’s Brent size of 345 .m files – perhaps also because I don’t mind larger files – but it’s not much simpler than NetNewsWire either. Anyway, bear in mind that my comments below just detail what works for me. YYMV and so forth.

Notifications. Everybody seems to agree they’re not a panacea. I listen to some Cocoa notifications and practically never generate my own. Notifications are great for posting notice of some application-wide event in the hope that some other parts of the application will want to know about it. That’s usually the case when some parts don’t know about other parts, or when one of the parts is a generic framework.

Like Brent, I prefer to use delegates for fast and specific notifications. Say a custom view is resized and someone needs to know when that happens; the logical pattern is to implement a delegate for that view and call it directly. Simple, fast, and easy to trace through. “Easy to trace through” is in fact my main debugging mantra. The bad thing about notifications is they’re difficult to step through in the debugger; you need to place a breakpoint at every listener. The obvious advantage over delegates is that you can have more than one listener – not that I ever needed more than one.

KVO and bindings: I haven’t had occasion yet to use those, although I’ll probably do so for preferences in XRay II. I tried using them in my first plug-in there but backed off fast; they’re certainly not suited to handling nested views that may be loaded and unloaded; the retain cycles get unmanageable. They’re also impossible to properly visualize in the current Interface Builder (though it seems that will change in Leopard?) and even harder than notifications to step through in the debugger. So I’d rather wait for a suitable application to present itself.

I suppose I also should point out that the upcoming Objective-C 2.0 properties look, so far, like another brilliant idea well-suited to specific purposes but not useable elsewhere. The property declaration syntax looks terrible, and the dot notation looks like Java. I can’t see myself using this any time soon – also, notice that the compiler will generate accessor code for them, meaning, you can’t step through.

High-level interface: in my first programs I noticed that I was jamming lots of methods into the application delegate. The app delegate is a singleton, so my other classes were full of lines like [[MyAppDelegate sharedInstance] checkSomethingWith:someStuff]. Later on I changed those to class methods like [MyAppDelegate checkSomethingWith:someStuff], and nowadays they’re just global C functions. I agree they may make it more difficult to refactor the design under certain circumstances, but after a while you learn to look ahead when deciding which functions to use. The only singleton object I have these days is the application delegate.

By the way, I use C functions a lot. Anywhere I see an instance method which doesn’t use “self” or any instance variable, it’s better to convert it into a C function. Same for most class methods. A bonus of C functions is that they’re harder to hack, of course.

Project Navigation: like Brent, I use the function popup a lot. I rarely have so many methods that sorting them into groups with #pragma mark is necessary. I use command-doubleclick and option-doubleclick a lot, and I keep AppKiDo open all the time. I noticed only recently that Xcode has a scripts menu with useful scripts and shortcuts, but the only one I use much is command-/ to comment and uncomment.

By the way, many people rave about using TextMate instead of Xcode for code editing. Apparently nearly all of those people are emacs fans who hate grabbing the mouse and prefer to do everything with memorized key shortcuts. Of course I’m an old fossil who still remembers the WordStar shortcuts and my shortcut neurons seem to be unable to learn new ones; I use the keyboard for cut, copy, paste and save, type short changes with my left hand, and for everything else I resent anything that forces me to take my right hand off the mouse. After all, that’s why we use Macs, right? </slight exaggeration for effect>

But then I suppose most of those people also like compiling their projects in the Terminal… Brent says, “Every time you touch the mouse, God kills a kitten”, but I’d say that for the command key instead

Flat folders: Yes, I too have a huge flat folder organization and 1 or 2 levels of grouping in the Xcode project. I never look at most of those files outside of Xcode anyway. I also include my readme and documentation files into the project, and edit them there (I create them in TextEdit however). Some people say this makes reusing code and source repositories harder. I prefer duplicating files or swatches of code when reusing; with some exceptions like RBSplitView, which I include as a subproject.

I seem to be notorious for not using version control systems; currently I keep my source on both my desktop and my laptop, and backup the entire project folder to a new disk image now and then. I very rarely need to refer to older versions anyway – I tend to comment out code instead of deleting it. I may try out Xcode 3’s subversion support, hopefully it won’t make me use the Terminal for anything. Of course, I’ve never worked in a programming team or had to share code with somebody else; blame it on history.

WWDC 2006 had two main topics: the new Mac Pros and Leopard. Regarding the Mac Pros, they seem quite competitive and well-built. I’m very content with my current iMac G5 (which I bought at last year’s WWDC), so I haven’t looked at them closely; desk space is important to me. By the way, it seems that Apple Brazil has just released the local price of the standard configuration, and it comes out to US$5400. Ouch.

Regarding Leopard, there’s a nice write-up at Wikipedia, so I won’t try to enumerate everything here.

All in all, I can say this was one of my best WWDCs yet. As I’ve said before, the timing was excellent. Apple has obviously made the most of the (unusual) June-to-August delay and from the developer standpoint all important stuff was in place. Most of the Leopard APIs seem to be well-defined, reasonably stable, and of course the tools are all in place. Xcode 3.0 and the new developer tools “just work”. In one Q&A session Chris Espinosa, was asked about the stability of the tools – whether developers should rely on them for new products, or should wait for the GM release – answered “we all use them daily for building Leopard, so they have to work well!”

So, this is important news for developers. Before, existing tools were used to build a new system and the next generation of tools came out with (or after) the GM release. Now, Apple has obviously been working on the new stuff iteratively; first versions of the new frameworks were used to build first versions of the new tools, then those were in turn re-used to work on the new frameworks. Certainly this has always happened to some extent, but I believe that this synergy between tools and frameworks has now hit an important inflection point.

Apple has clearly been working towards this for years. Mac OS X ‘s frameworks are now 4-way universal, containing binaries for PowerPC 32, PowerPC 64, Intel 32 and Intel 64 bits. Therefore, applications can now be built for all 4 environments, and all are fully supported by the new developer tools. This is a well-known capability of the Mach-O executable format by the way, not a new thing; NeXT applications were also distributed for several architectures, and the Virtual PC 7 executable has binaries optimized for 5 (!) different PowerPC variants.

Framework synergy is a marvelous thing. Apple has just released a short movie showing off CoreAnimation. The “city towers” effect in the second half can be now rendered in realtime on a MacPro – something that even two years ago would have been impossible. Looking very closely you can see that some of those squares are actually playing movies! But only a developer can fully appreciate the other important aspect: the code to generate this movie has shrunk down to less than 10% of what would have been necessary in Tiger.

Let’s talk somewhat vaguely (NDA mumble mumble) about how synergy might have made this happen in the CoreAnimation case. The MacPro has a faster, 64-bit CPU architecture, as well as faster video cards. 64-bit processes can use extra CPU registers and the new vector operations which seem to, finally, have equivalent power to the PowerPC G5’s AltiVec. The LLVM compiler is now used in the OpenGL stack to add a significant speedup (and this even for low-end machines!). Add in Quartz optimizations. Add in easy Cocoa support for all of these. Add in runtime efficiences introduced by Objective C 2.0. Add in new debugging and optimization made possible by implementing DTrace. Add in the ease of programming all this with less and more reliable code. Add in some extra stuff I can’t talk about… it adds up! And comparable gains are visible all through the new system.

At the risk of repeating myself, all this ho-hum talk about Leopard just being Spaces, Time Machine and some UI tweaks to iChat and Mail is so wrong. Granted that Steve Jobs had to show some non-developer news at the keynote, given the wildly unrealistic expectations. But, it really was a Developer Preview. It was released at the right time and to the right people in order to make sure that, whenever the Leopard GM comes out (my guess would be in January at MacWorld Expo), some hundred cool new applications will be available on the same day. And they’ll necessarily be Leopard-only; expect Leopard to be adopted by a significant portion of the user base in a very short timeframe.

Now to my own projects. I’d really love to have the upcoming XRay II to be Leopard-only, but that would delay release too much, and it doesn’t really need 64-bit capabilities. However, I’ll really need some fixes introduced in the last Tiger updates, so 10.4.7 will be the minimum supported version, which should be no hardship, as I can’t imagine anyone voluntarily staying with older Tiger versions. However, some of the stuff I’ve seen at WWDC has completely changed my plans regarding certain features and capabilities, so I’ll opt for implementing things in a way that might be a little constrained under Tiger but will really be much better under Leopard.

RBSplitView has been a marvelous experience for me. It’s been very widely adopted and even the Cocoa team has promised to take a look at it (no promises, of course). And it was very gratifying to be instantly recognized by many famous developers – of course my XRay II/RBSplitView t-shirt was intended to make this very easy! I’ve received lots of positive feedback and I’m working hard on implementing my own fixes and all suggestions. Hopefully I’ll have version 1.1.4 out in a very short time. This should be universal and fully compatible with Xcode 2.4. A 64-bit version compatible with the new Interface Builder will, unfortunately, have to wait until a more widely available Leopard beta comes out – I’m waiting for word from Apple about when it’ll be kosher, as I’ll necessarily have to include some new Leopard headers and APIs.

I have updated Nudge to be universal, and it seems to still be useful on Tiger for mounted network volumes. Expect the update to be available in a few days – I’m still doing some last-minute checking. Zingg! is, unfortunately, much harder to update at the moment. I haven’t touched it since 1.4.1 came out over 2 years ago, and the source code has been pushed out to some CDR backups – and the two I’ve found are, sadly, unreadable. I still have some hope of finding a copy someday (there’s a ton of stuff stashed away from my move), but don’t count on it. Recoding it from the ground up will have to wait for Leopard, where it’ll be much easier to do – there were some awful undocumented things I had to do at the time. Sorry about that. The USInternational keyboard layout will soon be repackaged in a way that (hopefully) will work around the “custom keyboard layout is randomly deselected” bug in Tiger. I’ll need to wait for a Leopard beta to come out to check if it’ll be upwardly compatible, though. I’m trying (again) to go through Apple channels to have it included with the standard system, perhaps this time it’ll work out?

Rainer Brockerhoff wrote:

Still, Steve Jobs said many features were still “top secret”. I suppose most of them will be revealed later under NDA.

And so they were. Well, at the least most of them that developers should be concerned about. I’ll talk about some fundamental issues here, but of course I can’t talk about details not released elsewhere.

Rainer Brockerhoff wrote:

Xcode 3.0 features a cool new debugging feature called… “Xray”. So. Good thing I’m at XRay II already. Where’s my lawyer…?

Well, I’ve had the opportunity to talk to Apple – informally, I hasten to add – and we’ve agreed there’s no conflict. A good thing too, as they have more lawyers than I do, hehe. Unofficially, I’ve heard that it was called PowerSomethingOrOther until nearly the last day before the show and then someone (marketing?) decided on the name change without doing a Google search. (Probably because PowerSomethings are on their way out, anyway.)

I’ve been floating ideas of possible name changes with other developers – GammaRay? CAT? PET? PowerSameThing? Nothing has quite the same zing, and I’d have to change the icon – and so I’ve decided keeping XRay II will be OK for me. It’s a full version ahead!

Anyway, I’ve been not-too-surprised about the mostly ho-hum reactions the keynote got among journalists, analysts and non-developer entities. And of course the stock is down. Well, no new iPod was revealed, right? And some people to this day think that Tiger was only Dashboard, Spotlight and some small cosmetic changes in the iApps…

…and from that point of view, the Leopard preview was only Time Machine, 64-bit support on some machines, and… HTML Mail templates? To-do in Mail. And erh, more effects in iChat and PhotoBooth, right? Personally, I was disappointed to see Steve Jobs waste so much detail on such trivia. And of course, HTML e-mail should be stamped out, not fomented!! Death to Mail templates!!! Argh. Sorry. Hm.

Well, it’s a developer conference and this was a preview for non-developers. The timing of this conference was very interesting. I’ve been to conferences where the timing was unfortunate. Way back when they showed the Copland preview absolutely nothing worked and most of the sessions were pure hand-waving. Last year, Tiger had already been out for a time and that conference was interesting more for its historical value (and for testing on the Intel kits, of course).

This time, the Leopard preview is at the right stage. Most of the new APIs and things are either working or in the final stages. There’s documentation! There are machines running the new system! The new system kernel panic a few times a day under hard use, but that’s normal. There’s the usual list of deprecated APIs we should avoid in the future, and the usual list of cool new APIs I’ll have to wait a year or more to really use. What is mostly not there is what those guys were looking for: a new kernel, a new Finder, the death of metal, new applications, radically improved applications (and I’ll explain below why they shouldn’t be here now).

More importantly, there’s a clear sense of direction. I’ve changed several ideas I had about XRay II’s implementation and most of them will make my life easier, mostly through having to write less code. Or, in the future, of being able to take code away, or to do cool new stuff on Leopard in the “just-works” mode.

So, what the non-developers don’t get is that Leopard is all about infrastructure – as was Tiger too, come to think of it. As someone (Lincoln?) is reputed to have said, “if I have 8 hours to fell a tree, I prefer to spend 6 hours sharpening my ax”. And that’s what’s going on. They’re sharpening the infrastructure. Then, a very short time (comparatively) before release, all the new infrastructure will make doing those cosmetic and application changes much easier, and they’ll be faster as a side-effect too. And they’ll be doing things not possible today. Some folks are catching this hint. For instance, Time Machine’s cool new UI is possible thanks to the new CoreAnimation framework, which itself rests on other stuff I can’t mention… and all this new infrastructure is interacting synergistically, so the rate of change of innovation is increasing without Apple having to add more engineers, or developers like me having to write more code. The new boring Mail features are based on new frameworks available to other apps, and so on.

More later…

So, I’m just back from getting my WWDC badge. I’ve seen the famous banner and all icons on it are known – the only one I had doubts on (above the SpotLight icon) is supposedly from a Mac OS X Server utility. Even the 64-Bit icon was previously used when the G5 came out. Ah right, we now know what the Leopard “Big X” looks like – black with a white border. Drat, I need to change the XRay II icon to reflect that…

The relative sizes and positions give no hints. There are a few hardware icons. One iPod Nano. 3 iMacs, 2 laptops and one desktop – the latter one from the side, so the front may be different. Or the banner might just be there as a misdirection and may be changed on Thursday… the Xcode icon is very large – so large that one can read the small print on it, but then it’s a developer’s conference. On the other hand, people “in the know” did tell me to make sure not to miss the developer tools sessions.

Certainly a major release of Xcode is in the works. 2.5 or 3.0, it doesn’t matter, but my personal hunch is that the superannuated Interface Builder application will be phased out and integrated into Xcode. Let’s hope that connections like outlets and bindings will be easier to visualize and debug, and that the IBPalette interface is finally officialized so that we can write non-trivial palettes.

I’ll be under NDA for details – things announced at the keynote excepted – so these will be my final pre-WWDC speculations. On the hardware front, 64-Bits is of course guaranteed, with one of the new “Core 2 Duo” chips. A Mac Pro will certainly be out, although the name may not be exact, and the casing will probably be a minor variation on the current one. There’s a good Ars Technica writeup about the new Intel CPUs, and expectations are that the whole new range will fit nicely into the spectrum from MacBook Pros to the Mac Pros – possibly with a dual-core, dual-CPU at the top, although it might also be that Intel has been reserving their quad-core chip for Apple to announce. Intel Xserves might also appear.

I don’t expect a new iPod to be announced in a big way, except as a footnote to the usual summing-up of past sales; at a developer’s conference, it’ll be big news only if it had an official API for developers to extend its functionality, which might actually be a neat way for Apple start a new iPod generation in a privileged position; stranger things have happened.

I’m reasonably certain that we’ll each get a Leopard preview DVD. I’ve seen rumors of changes to applications, which I consider less interesting as they’re not really a part of the OS itself, at least from my developer’s standpoint. I use relatively few of the iApps every day – Safari and iChat are the ones I leave open, and my wishlist for those is small.

Real Leopard features I expect to see:

– RBSplitView adopted! Well, not likely, but it’d be nice… I’ve told Apple I’d gladly give them the code, anyway.

– A new UI theme, or at least a migration of the default windows theme to the new “cool gradient/smooth metal” look.

– Some new Cocoa widgets, especially the more successful ones from the Tiger iApps. I hope to see them do Brent Simmon’s “big time tabs control”; I need it badly for XRay II.

– A new Finder. I’ve mostly gotten used to the old one, but still…

– Resolution independence. We need to get away from the pre-rendered bitmap widgets. People are already starting to use object-based PDF files for that, but they’re a pain to make and don’t look good at all resolutions. My ideal solution here would be a new NSImageRep and corresponding file format that would do for images what the TrueType format did for fonts: resolution-independence with special hinting for small sizes.

– More extensions to Objective-C. Garbage collection should be a given. Unloading NSBundles is supposed to be in the works. Frameworks included inside applications can’t be easily updated and versioning is pretty much useless for practical purposes.

– Hopefully we’ll see expanded metadata capabilities and a more useable SpotLight. I hardly use it in Tiger because it’s so slow and limited. The ability to have additional named forks should go hand-in-hand with full NTFS support. Other file systems would also be nice (ZFS, anyone?).

– Virtualization. I’ve written about this several times. My personal opinion is that Apple should write a fully trusted hypervisor into the EFI (using the TPM) and run everything inside virtual machines, including Mac OS X for Intel itself. Booting some version of Windows into a second VM would be easy, then, and there wouldn’t be a full version of Mac OS X for Intel for people to run on standard PCs either. I don’t think dual-booting is a good solution, I believe Apple was just testing the waters with BootCamp. No idea what would happen to Parallels in this scenario; they might be bought out by Apple, or by Microsoft, I suppose. Here are more thoughts on virtualization from Daniel Jalkut and Paul Kafasis.

– 64-bit “cleanness”. Meaning, Carbon and Cocoa and everything else running in 64-bit apps. And very probably, also, on the G5s. However, I’m not sure (and no time to research at this moment) how mixing 32 and 64 bits works on the Intel CPUs. I remember reading somewhere that it’s not as easy as it is on the G5, where you can have 32-bit processes co-existing with 64-bit processes.

Unlikely or even impossible:

– A new kernel.

– iPhone, iPDA, iGame, iTablet. iAnything in fact. There are rumors about VoIP support and there might be some sort of hardware for that, but I can’t see Apple doing a me-too cellphone.

– Some goodie under the seat (like when the iSight was introduced, which I missed out on, argh!).

In the meantime, I’d better get back to my coding… more after the keynote!

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.

Mac Xcode Debugging

Now and then I read complaints about Xcode on blogs and mailing lists. It’s come a long way but some parts are still slow and cumbersome, granted. One of the complaints – which usually comes from Java or Windows C++ migrants – is that Xcode has no refactoring aids. Some people even publish workarounds.

So what is this refactoring thing anyway? According to Wikipedia:

Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly keeping its meaning or behavior…

Refactoring does not fix bugs or add new functionality. Rather it is designed to improve the understandability of the code or change its structure and design, and remove dead code, to make it easier for human maintenance in the future. In particular, adding new behavior to a program might be difficult with the program’s given structure, so a developer might refactor it first to make it easy, and then add the new behavior.

I’d tend to agree with that, up to a point. I usually refactor when I reach a dead end in the software’s structure, that is, when the current structure won’t allow me to proceed implementing what I want to implement. Or – probably the same thing, essentially – when I find myself implementing things I don’t want to implement anymore.

But my tendency (see fractal programming) is to do it in the reverse order; I write some code that does new stuff in a new way. Then I migrate lots of old code into the new scheme, often rewriting it radically if necessary, or throwing entire blocks away. (Well, not literally at first; I prefer to comment such blocks out or move them into a “dead code” file for later reference.)

Now, the aforementioned migrants usually don’t see it that way. Rather, they want some automation to make the process easier:

An automated tool such as a SCIDs to help you do might work like this:

– I have a method which has some code that I would like to pull out into its own method.

– I highlight the offending code.

– I select Extract Method from a popup menu

– The RefactoringBrowser asks me to name the method and automatically creates it and inserts the highlighted code.

– In the current method, the highlighted code is replace by an invocation to the newly created method.

All very nice, but it presumes several things which I don’t see coming to Xcode (at least not to the Objective-C parts):

– You have a very regular, structured style of coding that conforms to standards the “RefactoringBrowser” understands.

– You always use the standard refactoring methods, such as expanding, collapsing, pulling out, pushing in, whatever.

– All source code in your project has been previously parsed and stored in the SCID (source code in database), so the browser and refactoring software have a perfect understanding of your code.

This is perfectly possible (or at least I’m told it is) in Java and perhaps in C++ – though I’m skeptical about the latter. I was astounded when a friend, who was qualifying to some Java certificate or other, asked me to have a look at his source code. A quite trivial program was expanded to several dozen source files, consisting of literally hundreds of small methods that differed from each other only by name and a few characters or line. No doubt everything was set up very logically and hierarchically and according to whatever standards a certified Java programmer must obey, but… it was completely illegible by my (admittedly eccentric) standards. It was code only a SCID could love.

So, suppose my friend decided to refactor his code. Just renaming a few classes must necessarily entail profound changes in all source and project files. Not only must the filenames themselves be changed, but all mentions of this class must also be changed. Wait, don’t we have global search & replace for that…?

But, of course, renaming classes or methods is trivial. Maybe it’s suddenly obvious that you need to push some methods off into a subclass, or pull them up into their superclass. Wouldn’t it be nice to have this done automatically?

Well, not really. First off, inheritance is much less used in Objective-C – or at least, I use it less than I used to do in my C++ days (I refuse to learn Java). Runtime binding, introspection and categories mean you usually don’t have to subclass more than one or two deep from the standard Cocoa classes. In fact, I believe I just today went to the third subclass level for the first time. So, automating such a superfluous process makes little sense.

Second, remember that Objective-C is just a small superset of C (unlike Java and C++ which are C-like languages). And that Mac OS X is Unix-based, with many headers pulled in from heterogenous sources. This means, of course, that all the old crufty things of the old C days are still there… pointers, pointer casting, weird #defines, other tricks – you name it. And all of this is liable to be #included into your poor unsuspecting code if you do any work at all with Carbon or BSD APIs, as most non-trivial applications need to.

In other words, I don’t believe it’s possible to feed all of this into a SCID and expect it to behave rationally; of course the gcc compiler has to make sense of all this eventually, but I seriously doubt it could be easily refactored to go back and forth from its internal representation to the source code while it’s being edited. It’s still, essentially, a batch processor.

Suppose someone pulled this transformation off. Suppose all the old C headers were tamed to make them compatible. Suppose we had everything in a hierarchical, intelligent, refactoring browser/editor. Now what?

It may be some congenital deficiency in my own neural wiring, but I can’t recall ever refactoring my code twice the same way (except for that trivial class/method renaming). So again, not much for an automated “RefactoringBrowser” to do.

Well. All this to, finally, say that I’ve been stuck refactoring some of my code – specifically, the XRay II file system browser back-end… and of course, no automation would have helped me. Nor would I have trusted it to do anything like what I want.

This is perhaps the third or fourth version of it, and it’s easily the most complex refactoring I’ve ever done. Unfortunately there are no intermediate steps. 20 days ago everything was compiling and running nicely (except, of course, for the problems that led me to this refactoring attempt). Then suddenly it’s like open-heart surgery. Nothing compiles and the number of error messages is so great that gcc throws its metaphorical hands up and goes off to sulk in a corner. I can’t close the patient up again until everything has been put back into place – even if it’s not the same place. And it’s a lot of information to hold in one’s head at the same time. I suppose I must get a second monitor, but that’s not practical at this moment.

And the availability of powerful time-sinks like the Internet means that it’s almost impossible to summon the necessary concentration to do the surgery in a single run. I’ve made serious progress over this weekend by the simple expedient of staying overnight with some friends who don’t have an Internet connection (or, even, a phone line). Still, sometimes it’s necessary to read and write e-mails, chat, even write long posts about refactoring…

Even so, I hope to get past this obstacle during the next few days and write a little about actual results. Turns out I learned a lot about in the process. More as soon as possible, then.

Cocoa

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…

Mac Debugging