|
| View previous topic :: View next topic |
 |
| Author |
Message |
|
|
# 12 Jun 2009 15:27:42 Re: WWDC 2009 |
 |
|
Ted Landau of MacFixit fame interviewed me last Wednesday and the interview is up now on the Mac Observer. Many thanks to Ted for this opportunity to get word out about the upcoming Quay plug-in SDK.
A few small corrections: | Quote: | | ...I also had a job working with the Macs installed at a medical equipment company... |
what I said was that, at that company, I designed medical equipment based on a Mac-like architecture (68K processor and all) and used a Mac as a development workstation. | Quote: | | ...The staff here at the WWDC have always been helpful, although probably a bit more so back in the 1990's than now... |
I actually was referring to the people at developer relations, not at WWDC, and the situation is reversed; they're a bit more helpful now, since in the 1990's they hadn't quite gotten their international act together, and I depended more on personal acquaintance with some of the Apple folks. |
|
|
|
|
|
| # 12 Jun 2009 02:14:35 Re: WWDC 2009 |
|
|
The conference will be over tomorrow and I'm quite satisfied with the outcome. Now for some comments about the announcements and (NDA permitting) about what I learned.
I had some vague idea of going to some iPhone sessions and letting presenters (or friends developing for the iPhone) convince me that I should start developing for it. No such thing happened; session overlap was so severe, and there were so many labs to go to, and people to talk to, that I skipped any non-Mac session or discussion. What little I heard in the corridors confirmed my notion that the current state of iPhone development and the AppStore deviates too far from my preferred position as a utility developer - a niche Apple still keeps closed on the iPhone. Maybe when the tablet comes out... 
Speaking of tablets, while everybody agrees that one is in the works, it seems to be a year or so away from announcement. (Ditto for the new CPUs I hinted at, in my last post.)
Snow Leopard is the small new thing. Small for the user in a sense; it's just refinements and greater speed. For developers, though, it's the BIG new thing. And, as variously described as early as a year ago (can't find URLs right now), much of the new stuff is driven behind the scenes by open-source projects Apple is driving: the Clang compiler, the LLVM back end, and the technologies made possible by Grand Central Dispatch, blocks and OpenCL. So, most of the sessions either expanded on this directly or offhandedly mentioned "there's an API for that now - and it's fully XYZ-enabled" (insert one of the technologies above).
These things have become possible because CPU chips had run into a clock frequency "sound barrier"; 3GHz is about the maximum current silicon can do without extensive and expensive cooling or exotic technology. So multicore has become the solution du jour: all Apple computers now have at least 2 core, and the top machine has 8 (16 virtual). Expect that number to double every 2 years, at least.
But for years multi-processor machines were hard to program. About 14 years ago, at another WWDC I bought a Genesis MP 528: this Mac clone had 4 PowerPC 604 processors running at a blistering 132MHz. It didn't have much caching on those chips, and only Photoshop and a few other specialized apps could see more than one CPU, and that only for image filters. In two years the first PowerPC G3 CPU card, with a single processor but caching, running at 300MHz, had about the same Photoshop performance - and that performance was then available to all apps. So why didn't more apps take advantage of the 4 CPUs? The classic Mac System 7 (to 9) had no easy way to allow for this; there was a very primitive multiprocessing API but the system was pretty much locked out of it.
As said in the keynote, Snow Leopard will support only Intel Macs; PowerPC Macs are, therefore, stuck in the Leopard era, and only some few bug fixes will appear on 10.5, then it's over. I couldn't find hard figures comparing the installed base; I've seen percentages quoted of between 10 and 35% of Macs Macs still in use being PowerPCs. I personally didn't think this would dip below 25% before 2011; then again, as a stockholder, I'm glad Apple sold so many new Macs recently... 
Some people question why PowerPC users will be left out of the Snow Leopard advantages, and I think I know why. While the top 4-CPU PowerPC machines still can hold their own with more modern machines under certain circumstances, the vast majority of PowerPC Macs have only 1 CPU; only a few big desktops have 2, and even fewer have 4. Most advantages of Snow Leopard come into play when you have at least 2 CPU cores, and there's serious testing and bug fixing to be done for supporting an entire architecture. Apple probably just weighed those factors (with better numbers than I have available) and decided it wouldn't work out.
Positives of the new Clang/LLVM combo: better compiler speed, better code optimization - both still starting out but they've more power in reserve, while the current gcc compiler and backends are pretty much maxed out; way better error messages, the Clang static analyzer is just awesome (a word I usually hesitate to use, but this really is!); lots of goodies to come from tighter integration with Xcode. Negatives: may still generate wrong/inefficient code in some circumstances; no C++ support yet (I don't care myself about this one).
A sleeper advantage is, also, that the intermediate (LLVM) bytecode generated by Clang could possibly be stored as such inside executables, and be just-in-time compiled for execution on any target CPU. In other words, the same executable could run on a new machine Apple puts out, even if it has a new CPU chip/architecture, as long as the JIT compiler is in place for that; application developers wouldn't have know (or care).
Regarding blocks (or "closures", as they're known in other places), they're a syntactic convenience for programmers to pass executable code as data. As such, they make programs more readable. What makes them inordinately powerful in Snow Leopard is that they're also the basic executable units for all of the cool new multiprocessing stuff in Grand Central Dispatch. Therefore, with a little discipline, it becomes easy for developers to chop up tasks into little slices than can be executed in parallel by however many CPU cores (or, with OpenCL, GPU units) are available to do them; and for the first time anywhere I know of, this facility is available throughout the system, even at a quite low level.
So, am I running off to convert all of my code to the new technologies? Well, yes and no. Many things still have to be done in a serial manner, and the system will do others in parallel behind my back. Also, it seems that writing a generic application that runs on both 10.5 and 10.6 (using the new stuff) is tricky; I'm still investigating how to best do it. Stay tuned for developments... |
|
|
|
|
|
| # 08 Jun 2009 10:42:24 Re: WWDC 2009 |
|
|
So much for regular posting; either no connection, or too much to do when I have one.
Still, everything else's been good so far. The weather's been quite good for San Francisco, though a little windy at times. I met a lot of old and new friends already and took some more nice pictures of downtown San Francisco.
In a couple of hours I'll be in the WWDC keynote queue. Most speculation I've read so far has been about iPhone hardware/software, which I'm not too interested in. However, one nice rumor I've heard is that they may unveil a highly scalable CPU from the PA Semi group Apple acquired a year or so ago; one or two such chips could power the iPhone, with (say) 32 in a laptop, 128 in a desktop, and 8 or 16 in a hypothetical tablet. Will a tablet be announced? No idea, though I hope so.
Regarding Snow Leopard, I think the most likely announcement is going to be about price and availability; my tip would be between $39 and $59, and September/October. The rumored "Marble" interface theme sounds unlikely to me.
That said, I'm very excited about the things in Snow Leopard's underlying technologies, but those are visible only to developers, anyway. (Also: NDA...) |
|
|
|
|
|
| # 04 Jun 2009 16:29:24 WWDC 2009 |
|
|
| Just arrived at the hotel in San Francisco, trip was OK and uneventful, though of course tiring. The Internet connection is very flaky, but I'll try to post regularly from here on. Stay tuned. |
|
|
|
|
|
|
|
|
|
|
| # 25 May 2009 21:24:31 Hold on |
|
|
Well, since I last wrote, a reasonably definite version of Klicko has been published (1.1.1 build 207) and I deemed the supporting code to be mature enough to serve as basis for the next version of Quay. So, since then, I've been busy on that.
On June 4th I'll be arriving in San Francisco - WWDC starts on June 8 - and hopefully by then I'll have an early alpha version of Quay 1.2 (or maybe 2? II?), and of the Quay Plugin Developer Kit as well. Stay tuned. |
|
|
|
|
|
| # 07 May 2009 13:55:58 Re: Cocoa musings pt.6 |
|
|
| Rainer Brockerhoff wrote: | | Code: | [task launch];
[NSApp terminate:nil];
|
No need to pass the calling program's process identifier, and it works from Tiger (10.4) on up. |
Although unlikely, the task may be faster to execute than [NSApp terminate:] and the relaunch process would thus fail. By listening to the termination of the calling process, you are guaranteed to always relaunch.
Edit: I'm wrong, Rainer just pointed to me that the task can't terminate since its first line is a read on the input pipe and it will block there. |
|
|
|
|
|
| # 06 May 2009 17:43:49 Re: Cocoa musings pt.6 |
|
|
Cédric Luthi has posted another take on the mechanics of reopening a System Preferences pane (or is it panel?). Worth a read; however, I would propose a shorter piece of code for his relaunch snippet, combining two of my recent posts: | Code: | int main(int argc, char **argv) {
char dummy;
read(STDIN_FILENO, &dummy, 1);
CFURLRef url = CFURLCreateFromFileSystemRepresentation(kCFAllocatorDefault, (UInt8*)argv[1], strlen(argv[1]), FALSE);
CFArrayRef aurl = CFArrayCreate(kCFAllocatorDefault, (const void**)&url, 1, NULL);
FSRef ref;
if (LSFindApplicationForInfo(0, CFSTR("com.apple.systempreferences"), NULL, &ref, NULL)==noErr) {
LSApplicationParameters parms = {0,kLSLaunchDefaults,&ref,NULL,NULL,NULL,NULL};
LSOpenURLsWithRole(aurl, kLSRolesAll, NULL, &parms, NULL, 0);
}
}
} |
and the code to launch this tool (from within the preference panel itself) is: | Code: | NSTask* task = [[NSTask alloc] init];
[task setLaunchPath:@"/path/to/tool"];
[task setArguments:[NSArray arrayWithObject:[[NSBundle bundleForClass:[self class]] bundlePath]]];
[task setStandardInput:[NSPipe pipe]];
[task launch];
[NSApp terminate:nil]; |
No need to pass the calling program's process identifier, and it works from Tiger (10.4) on up. |
|
|
|
|
|
| # 29 Apr 2009 22:42:23 Cocoa musings pt.6 |
|
|
Also, yikes. 26 days without posting! I plead temporary insanity brought on by tax filing time, and Twitter - the latter being a more convenient outlet for short links and thoughts.
Anyway, taxes are filed and we're now having a short working vacation in the hills of Petrópolis, an old town north of Rio de Janeiro. Dorinha is taking a short English immersion course (excellent BTW), and I'm coding again, yay!
I'm patching up some loose ends in Klicko in preparation to cloning its preference panel for the next version of Quay, as I've mentioned before. While doing that, I'm also trying to refactor my code into a tighter and more readable form. Some of that might be interesting...
For instance, the automatic update checker has a dialog button to "Open System Preferences" and this should go to the Klicko preference panel. Now, System Preferences may already be running but with another panel selected; in any event, the Klicko panel should be opened and ready for the user to see update details. There are several ways to accomplish this.
Most people probably will consider, at first, writing an AppleScript to open System Preferences and then select the Klicko preferences panel. This is unnecessarily complex, and I've looked at several solutions. The simplest one-liner to do so from Cocoa would be: | Code: | | [[NSWorkspace sharedWorkspace] openFile:@"/full/path/to/my.prefPane"]; |
There's a non-obvious down-side to that: NSPreferencePane is generic and may be implemented by other apps for their preference plug-ins. Someone's application might use it and declare .prefPane in its Info.plist. This would in my opinion be a mistake, in that double-clicking or running the code above might (or not) open that other app instead of System Preferences!
The solution I finally hit upon uses Launch Services to open the correct application with the preference panel, like this: | Code: | FSRef ref;
if (LSFindApplicationForInfo(0, CFSTR("com.apple.systempreferences"), NULL, &ref, NULL)==noErr) {
LSApplicationParameters parms = {0,kLSLaunchDefaults,&ref,NULL,NULL,NULL,NULL};
NSArray* args = [NSArray arrayWithObject:[NSURL fileURLWithPath:@"/full/path/to/my.prefPane"]];
if (LSOpenURLsWithRole((CFArrayRef)args, kLSRolesAll, NULL, &parms, NULL, 0)==noErr) {
// success!
}
} |
This code first finds the System Preferences app by its bundle ID, and makes a FSRef for it. The FSRef is then pointed to from the LSApplicationParameters structure, and passed to LSOpenURLsWithRole; this will run System Preferences if it's not already running, and tell it to open the panel.
It's tempting to pass the panel's path as an argument inside of LSApplicationParameters. This does indeed work if System Preferences is not already running, but unfortunately it's ignored if it is. |
|
|
|
|
|
| # 03 Apr 2009 09:42:41 WWDC 2009 |
|
|
At first I thought I wouldn't make it, but now I'm very happy to announce that I'm going to WWDC 2009.
I'll arrive in San Francisco around noon on June 4th (Thursday), and will leave, also around noon, on June 16th (Tuesday). I'll be glad to meet with anyone who's interested...
More as it happens! |
|
|
|
|
|
|
|
You cannot post new topics
You cannot reply to topics
You cannot edit your posts
You cannot delete your posts
You cannot vote in polls
|
|
(RSS 2.0)
