I don’t think my random musings have much influence on the design of the language, but if I don’t write it down nobody’s going to know how nuts I am, so here’s a semi-concrete proposal for contextual types and generics for Objective-C. Since anyone even mentioning generics in the vicinity of Objective-C will inevitably be flamed for trying to turn it into C++, this is followed by an aside entitled Why This is Not the Baby-eating Spawn of Bjarne Stroustrup. (Nothing personal, Bjarne.)

Types in Objective-C

A fundamental characteristic of Objective-C is that it has two separate type systems: the dynamic type system, which applies to objects, and the static type system, which applies to variables (which may or may not refer to objects).

As far as objects are concerned, the static type system is optional — you can refer to any object with the type id, except when calling a method whose type may be ambiguous. The static type system is also advisory — it suggests to programmers, the compiler and other tools such as the IDE and analyzer what the class of an object may be at runtime, but doesn’t constrain the object. A variable of type NSString * may actually refer to an NSArray at runtime, and method calls will dynamically go to NSArray’s implementation.

My proposal deals only with the static type system. The idea is to provide information that helps the compiler and analyzer check your logic, and the IDE to provide better suggestions. This is done by replacing id with more specific static types in most of the situations it’s used in. The generated code is not affected in any way. The proposal does not introduce bondage and discipline on the language; the new types can always be cast away.

Contextual Types

By far the most common use of id is as the return type for methods that may return an instance of “this” class, or of the subclass it’s called on. The obvious examples are +alloc and -init.

The IDE and, I believe, the analyzer already use heuristics to determine the return type of +alloc and -init, but I propose formalizing this in code. It would look something like this:

@interface NSObject <NSObject>
{
    Class   isa;
}

+ (void)load;

+ (void) initialize;
- ([:Self]) init;

+ ([:Self]) new;
+ ([:Self]) allocWithZone:(NSZone *)zone;
+ ([:Self]) alloc;

// ...

+ ([:Superclass]) superclass;
+ ([:Class]) class;
- ([:Superclass]) superclass;
- ([:Class]) class;

@end

When calling a class method, [:Class] resolves to the receiver (or, type-equivalently, a pointer to an instance the receiver’s metaclass), and [:Self] resolves to a pointer to an instance of the receiver. [:Superclass] resolves to the superclass of the receiver. For instances, they resolve as for class methods on the class of the instance.

I’m sure some people will object to the conceptual purity of this design, and possibly the names and syntax. The colon is a bit odd — it’s there to avoid ambiguity with generics (see below). All of these are minor quibbles; the syntax would need to be reviewed if actually implementing it.

So what’s the point? Consider the following code:

NSString *s = [[NSArray alloc] init];

As it stands, this is perfectly valid and doesn’t generate a compiler diagnostic. With the addition of contextual types it would, because:

• The type of +[NSArray alloc] (inherited from NSObject) is [:Self], which resolves to NSArray *.
• The receiver of the -init is thus known to be an NSArray.
• The type of -[NSArray init] (inherited from NSObject) is [:Self], which again resolves to NSArray *.
• Therefore, the right hand side of the assignment is of type NSArray *, and the assignment is invalid.

If, for some reason, you really wanted to do that, you could use an explicit cast to get rid of the diagnostic.

Generics

The other major use of id is for polymorphic collections. True polymorphic collections are great! But some of the time, you only want to put one kind of object in your collection, and would appreciate the computer doing the drudge work of checking that you didn’t put the wrong stuff in the wrong place.

From the perspective of the previous section, generics are a simple extension to contextual types. Instead of restricting you to [:Self] and the highly specialized [:Class] and [:Superclass], you can provide one or more class names as a parameter to a type declaration. Example time again:

@interface MyThingHolder[ThingType = id] : NSObject
{
    [ThingType]     thing;
}

- ([:Self]) initWithThing:([ThingType])thing;

- (void) setThing:([ThingType])thing;
- ([ThingType]) thing;

// Or, for modernists:
@property (readonly, nonatomic) [ThingType] thing;

@end

// ...
MyThingHolder[NSString] *holder = [[MyThingHolder[NSString] alloc] initWithThing:@"foo"];
holder.thing = [NSNumber numberWithBool:MAYBE];      // Warning: type mismatch
holder.thing = (id)[NSNumber numberWithBool:MAYBE];  // OK. (an issue here would be inconsistent with general Objective-C behaviour.)

// Or, equivalently:
typedef MyThingHolder[NSString] MyStringHolder;
MyStringHolder *holder = [[MyStringHolder alloc] initWithThing:@"foo"];

Some notes: the type parameter can only be a class, since specialized code is not generated for each type. (See Why This is Not the Baby-eating Spawn of Bjarne Stroustrup below.) Since the type parameter is always a class, I have made the * implicit. This is cleaner, but could well lead to confusion and is quite likely a bad idea. (If only I had a time machine…)

The type parameter has a default value, previously unheard of in Objective-C, so that you can ignore generics and create a “vanilla” MyThingHolder that works just like in traditional Objective-C. This provides an upgrade path for existing classes:

@interface NSArray[Item <NSObject> = id <NSObject>] : NSObject <NSCopying, NSMutableCopying, NSCoding, NSFastEnumeration>

- (NSUInteger) count;
- ([Item]) objectAtIndex:(NSUInteger)index;

@end

@interface NSArray[Item] (NSExtendedArray)

- (NSArray[Item] *) arrayByAddingObject:([Item])anObject;
- (NSArray[Item] *) arrayByAddingObjectsFromArray:(NSArray[Item] *)otherArray;
// ...
- (BOOL)containsObject:([Item])anObject;
// ...
+ ([:Self[Item]]) arrayWithObject:([Item])anObject;
// ...


@interface NSDictionary[Key <NSCopying, NSObject> = id <NSCopying, NSObject>, Value <NSObject> = id <NSObject>] : NSObject <NSCopying, NSMutableCopying, NSCoding, NSFastEnumeration>

- (NSUInteger) count;
- ([Value]) objectForKey:([Key])aKey;
- (NSEnumerator[Key] *)keyEnumerator;

@end

@interface NSDictionary[Key, Value] (NSExtendedDictionary)

- (NSArray[Key] *) allKeys;
- (NSArray[Key] *) allKeysForObject:([Value])anObject;
- (NSArray[Value] *) allValues;
// ...
- (BOOL) isEqualToDictionary:(NSDictionary[Key, Value] *)otherDictionary;
- (NSEnumerator[Value] *) objectEnumerator;
- (NSArray[Value] *) objectsForKeys:(NSArray[Key] *)keys notFoundMarker:([Value])marker;
// ...
- (void) getObjects:([Value] *)objects andKeys:([Key] *)keys;
// ...

These examples introduce an additional concept: restrictions on type parameters, in this case protocol requirements. The other obvious type of restriction would be a superclass requirement, such as [Type: NSString = NSString].

Using these genericized versions in the same manner as the existing versions would require no code changes – as long as you’re using them with objects that fulfil the protocol requirements, which already exist but aren’t explicit in code.

Type Conformance

A fundamental question for static type systems with inheritance is when implicit casts are allowed. There are subtleties here, some of which I probably haven’t considered, and I have a feeling I’ve considered some and then forgotten about them. The most obvious case is when the base type and each type parameter could be validly cast:

NSMutableArray[NSMutableString] *a = whatever;
NSMutableArray *b = a;            // OK, b is NSMutableArray[id <NSObject>]
NSMutableArray[NSString] *c = a;  // OK
a = b;                            // Not OK, implicit cast from NSMutableArray[NSString] to NSMutableArray[NSMutableString]
NSArray[NSMutableString] *d = a;  // OK
NSArray[NSString] *e = a;         // OK
id f = a;                         // OK

As indicated above, passing an id when a parameter type is expected is necessary for consistency with Objective-C in general:

NSMutableArray[NSString] *a = whatever;
[a addObject:[NSNumber numberWithInt:42]];      // Type mismatch, assuming +numberWithInt: is declared to return [:Self]
[a addObject:(id)[NSNumber numberWithInt:42]];  // OK

How about the case where a method returns an unadorned type?

@interface LegacyThing: NSObject
- (NSArray *) legacyListOfStrings;
@end

LegacyThing *l = whatever;
NSArray[NSString] *list = [l legacyListOfStrings];

In order to minimize the burden of adopting generic syntax, I’d suggest explicitly permitting this, with an optional warning. (The non-generic equivalent, assigning an id <NSObject> to an NSString *, generates the somewhat unexpected warning “type ‘id <NSObject>’ does not conform to the ‘NSCopying’ protocol” in GCC and nothing in Clang. Assigning an NSObject * to an NSString * generates warnings in both. My proposal is that assigning a T to a T[P] should work without warning by default, even if the default type parameter is a class rather than id with or without protocols.)

Why This is Not the Baby-eating Spawn of Bjarne Stroustrup

Many Objective-C programmers are refugees from the blasted wasteland of C++, and will reflexively cringe at the similarity with templates:

std::vector<Duck> ducks;
Chicken chicken;
ducks.push_back(chicken);             // Error
ducks.push_back(*(Duck *)chicken);    // Horrible crash here or some time in the future, maybe.

NSArray[Duck] *ducks = [NSArray new];
Chicken *chicken = [Chicken new];
[ducks addObject:chicken];            // Warning: type mismatch
[ducks addObject:(Duck *)chicken];    // No problem, unless you call -quack on it.

While the difference should hopefully be clear by now, I’ll spell it out: in C++, std::vector<Duck> creates an entirely new class (with bits of Duck inlined into it). The Objective-C-with-generics version only provides hints to the compiler, so it can catch mistakes. It doesn’t stop you from putting chickens among your ducks, or make the duck array reject chickens at runtime, or generate a new array-of-chickens class.

In earlier discussions of generics, it has been stated that this type of mistake is rare in practice and should be caught with unit tests. If you feel that way, you’re welcome to stick to your current approach, and the introduction of generics, as described, will not affect you.

To avoid ballooning side effects of generics, I’ve deliberately avoided suggesting generic functions and methods (i.e., ones whose return type is dependent on one or more argument types, independent of their class in the case of methods).

One Last Thing

An effect of the above is that I want the language to contain types like NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] *. That doesn’t mean I want to spend my time typing NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] *, even with autocomplete. Fortunately, there exists a well-known solution to this problem: type inference.

If I access a member of an array of the aforementioned sesquipedalian type, I get an NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]] *. What’s more, the compiler knows this. The benefit of static typing lies primarily in checking what I do with my dictionary, rather than checking that the item I retrieved is what I thought it was, so I should be able to ask it to type a variable appropriately.

I quite like C++1x’s solution of recycling the auto keyword for this use, but that would conflict with Objective-C’s goal of being a strict superset of C. There are various other choices, such as var or any — or maybe ego. In any case, type inference would lead to code like:

typedef NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] MyHorribleNestedType;  // TODO: replace with sensible model classes.

MyHorribleNestedType *array = whatever;
var element = [array objectAtIndex:0];              // Type is inferred as NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]*
var subEntry = [NSArray arrayWithObject:@"bloop"];  // Type is inferred as NSArray[NSString]
[element setObject:subEntry forKey:@"moop"];        // Type mismatch: expected NSSet[NSMutableArray[NSNumber]], got NSArray[NSString]

A subtlety here: the return type of [NSArray arrayWithObject:@"bloop"] (declared previously) is [:Self[Item]], which is inferred from the receiver (the NSArray class object) and argument to resolve to NSArray[NSString]. Instead of typedefing MyHorribleNestedType, we could have constructed the type implicitly in the same way. like everything else in the proposal, this is optional; if you used id or explicit, unparameterized types in this example, the type mismatch would not be detected, but the generated code would be identical.

Summary

• The id type is very powerful and flexible. However, most of the time you don’t need this flexibility, and type checking is helpful — this is why Objective-C has optional static type checking in the first place, and almost all Objective-C code opts in to it.
• The proposal would not impose any new restrictions, or any new guarantees. It would only extend (optional) static type checking to cases which are currently not covered.
• It would not involve any implicit code generation, and no runtime overhead.
• Combined with type inference, it could catch errors without additional code.
• There would be no new collections, and no implementation changes to existing ones other than updated type declarations. (Updated headers would work with the existing implementations.)
• If you really don’t want static type checking, you can continue using id everywhere.
• I mean it about the “optional”. The proposed change would have no effect unless adopted both by a class and its clients. A parameterized collection pointer can be cast to plain one at any time with no cost.

JAMultiTypeSavePanelController is a class (abstracted from ImageIO Export for Acorn) to handle the case where you want to offer the user a choice of formats to save in.

It wraps an NSSavePanel and handles all the UTI and extension details. You can provide a customised NSSavePanel or let the controller create one. The only restriction is that the controller appropriates the accessory view. Usage is similar to NSSavePanel itself:

NSArray *types =
    [NSArray arrayWithObjects:@"com.apple.rtfd", @"public.rtf", @"public.plain-text", nil];
JAMultiTypeSavePanelController *controller =
    [JAMultiTypeSavePanelController controllerWithSupportedUTIs:types];
controller.autoSaveSelectedUTIKey = @"document format"; // Optional: preferences key for selected type.
controller.sortTypesByName = NO; // Optional: show in specified order instead of alphabetically by display name.
[controller beginSheetForDirectory:nil
                              file:@"untitled 42"
                    modalForWindow:docWindow
                     modalDelegate:self
                    didEndSelector:@selector(savePanelDidEnd:returnCode:contextInfo:)
                       contextInfo:nil];

-runModalForDirectory:file: is also supported.

Code (MIT/X11 license)

As an early Christmas present to fellow lovers of twisted, evil code that should never have seen the light of day under any circumstances whatsoever, I hereby present an implementation of the first half of that wish.

Caveat lector

Now, when I say it’s evil, I really, really mean it. We’re talking about building objects in the data section of your code by packing structs, thus depending on data layout (and as such, depending on the old 32-bit runtime). We’re talking about nested macros with lots of ?:s in them. We’re talking about gcc’s built-in parser pseudo-functions. Hearken to the words of Greg Parker, official Objective-C Runtime Wrangler at Apple:

@gparker: @ahruman JANumberLiteral would break in several exciting ways in 64-bit. Might almost be safe enough in 32-bit, though.
@ahruman: @gparker Yeah, I know. I’ll be pasting “If you do this in real life, I’ll have to track you down and shoot you” warnings all over it. :-)
@gparker: @ahruman Don't shoot 'em, just maim 'em a bit. I want my turn after you're done.
@ahruman: @gparker That’s what kneecaps were invented for.

Be told.

Overview

So, all that aside… what we’re looking at here is a macro $N(n) which takes a number and returns an NSNumber. (The convention of using dollar signs for macros implementing desired language features was introduced by the other Jens A.) If passed a compile-time constant, it will produce a constant object, i.e. a single, immortal instance based in the data section with no instantiation overhead, just like a string object constant. If passed a non-constant, it will give you a normal autoreleased NSNumber instead.

Constant NSStrings work by creating a struct with the following layout: { &__CFConstantStringClassReference, 1992, "foo", 3 }, where 1992 is a flag field and 3 is the length of the string. (Note that this is not the NSConstantString from the bottom of NSString.h. I believe this change was made in the OS X 10.2 SDK.) __CFConstantStringClassReference is a symbol exported from CoreFoundation.framework and implicitly declared in all Objective-C or Objective-C++ files by the compiler.¹ My task, once I chose to accept it, was to do something similar for NSNumber.

Trying to build actual NSCFNumbers would be an unnecessary extra evil. Instead, I subclassed the abstract NSNumber twice, once for long longs and once for doubles, giving me a known layout to target. The subclasses also override -retain, -release and -autorelease to do nothing, in the manner of a singleton. Then, building an instance is conceptually simple:

const static struct { Class isa; double value; } fakeObj =
{ [JAFloatNumber class], 42.0 };
NSNumber *number = (NSNumber *)&fakeObj;

The structure needs to be declared static so that it doesn’t evaporate at the end of the containing scope. This presents a dilemma, however: static initializers must be constant expressions, and a method call doesn’t qualify. Besides, we want the object to be constant data.

Luckily for us, classes are represented by global symbols like any other. Well, almost like any other. Unlike symbols based on C identifiers, their linker symbols don’t start with an underscore but with a dot, meaning you can’t reference them the usual way. Fortunately, gcc provides us with a solution in the form of asm labels:

extern const struct objc_class JAFloatLiteralClassObject
        __asm__(".objc_class_name_JAFloatNumber");

The basic implementation then becomes:

#define JANUMBERLITERAL_CONSTANT_FLOAT(n) \
        ({ static const struct { const struct objc_class *isa; double value; } \
        object = { &JAFloatLiteralClassObject, (n) }; \
        (NSNumber *)&object; })

A problem here is that, despite all those consts, a non-const value can be used in Objective-C++. (In plain Objective-C, you get a moderately helpful warning about non-const initializers.) If you write a function that returns JANUMBERLITERAL_CONSTANT_FLOAT(random());, each instance will return the same object but its value will change, which is rather bad. The fix is to wrap this up in a macro that uses __builtin_constant_p() to ensure constant objects are only created with constant values. For non-constant values, normal autoreleased NSNumbers are created instead.

Results

The above pieces, along with a bunch of extra preprocessor stuff to handle the distinctions between Objective-C and Objective-C++ and between integer and floating point values gives us a $N(n) macro which works as advertised: if given an integer constant it returns a JAIntegerNumber, for a floating point constant it returns a JAFloatNumber, and for a non-constant it returns an autoreleased NSCFNumber. But is it really working as intended? The following code:

static NSNumber *GetNumber(void)
{
    return $N(42.0);
}

disassembles to:

    .const_data
    .align 2
_object.67163:
    .long   .objc_class_name_JAFloatNumber  // isa
    .long   0           // low bytes of 42.0
    .long   1078263808  // high bytes of 42.0

…with the actual use of the object inlined (in an optimized build) to movl $_object.67163, (%esp). The values 0 and 1078263808 correspond to the little-endian hex value of 42.0: 00000000 00004540. In other words, this really is an object as constant data. For comparison, the NSString literal used in the sample code disassembles to:

    .cstring
LC0:
    .ascii "Hello, World! %@ = %li (%@)\0"
    .section __DATA, __cfstring
    .align 2
LC1:
    .long   ___CFConstantStringClassReference // isa
    .long   1992  // flags
    .long   LC0   // bytes pointer
    .long   27    // length

Conclusion

So there you have it: fully-functional, constant NSNumber objects, as long as you don’t use the 64-bit runtime. Now don’t go actually using it, or I’ll have to shoot your kneecaps off and leave you to Greg.

Oh yeah, the code is on Google Code. For a much simpler macro that just gives you an NSNumber, automatically choosing between integer and floating-point representations, try natevw’s.

^{^1} Its value, on my system, is 0xa00034a0. Traditionally (pre Leopard), a value above 0xFFF would mean it’s a real Objective-C class rather than a CF type tag, but that test is no longer in the CFLite source in Leopard, so it may have changed.

If you declare extern const Class __CFConstantStringClassReference; in an Objective-C++ file, you’ll get the error “'__CFConstantStringClassReference' has a previous declaration as 'int __CFConstantStringClassReference []'”. In Objective-C, you won’t be told a type, just that it was “previously declared here”, referring to the location “<built-in>:0”.

Easy Dictionary

This allows you to use arbitrary accessors on dictionaries, or arbitrary properties if you declare them first (no definition necessary). Example:

@interface NSDictionary (MyProperties)
@property (retain) NSString *fruit;
@end
...
NSMutableDictionary *myDict = [NSMutableDictionary dictionary];
dict.fruit = @"apple";  // -setFruit: method is generated dynamically.

Google Code, original lisppaste

Silly String

This defines a new string concatenation operator, :. Well, almost. It allows you to append any number of strings (or arbitrary object descriptions) to a string using the following syntax:

[@"string " : @"other string " : arbitraryObject : @" yet another string "]

Unfortunately, a header is required in this case to avoid unknown selector warnings.
Google Code, original lisppaste

Disclaimer

As noted in each of the files, I don’t recommend actually using these. They’re exercises in understanding the mechanics of the language rather than actually useful utilities. In particular, if you use Easy Dictionary you’re in for a world of hurt when you try to use a property that NSDictionary already has, like count, or description, or release.

Why would you want to do that? Ahh, well, that part is covered by the iPhone SDK NDA. Lawyers, eh? It must be a pretty good reason, though, given testimonials like this.

Executive summary for people who don’t like rambling anecdotes: property lists and user defaults should always be type-checked, and this makes it easy.

Oolite is highly moddable, with over 150 expansion packs. Most of them are interoperable, and typically many will be in use at once. Essentially all of these contain property lists, generally written by hand by non-programmers, often on systems without plutil or Property List Editor. As such, many contain parse errors or structural problems.

Previous versions of Oolite blithely ignored the imperfections of mere humans. Unparseable property lists were effectively ignored, leading to unexpected behaviour, often quite subtle. Structural errors, however, caused exceptions, most of them seemingly at random.

The current test releases address the syntax issues by dumping the error string from NSPropertyListSerialization and the path to the relevant file to the game’s run log. A certain amount of context-sensitive type checking is done in certain areas, such as scripting (yes, property lists are used for scripting, although that’ll be deprecated in the next stable release).

The most significant fix, however, has been to replace most uses of -objectForKey: and -objectAtIndex: with methods that check types and perform conversions where they make sense. In particular, strings are automatically converted to numbers and booleans where appropriate, which is needed to work with the more pleasant OpenStep plist syntax. When a plist value can’t be converted to the required type, or simply isn’t there, an appropriate default value is used. The game will no longer try to get keyed objects from an array, or find the first character of a dictionary. Instead of code like this:

// Hope plist has correct structure.
unsigned myMagicNumber = [[[plist objectForKey:@"someArray"] objectAtIndex:3] unsignedIntValue];

or more fault-tolerant code like this:

unsigned myMagicNumber = 0;
id array = [plist objectForKey:@"someArray"];
if ([array isKindOfClass:[NSArray class]] && [array count] > 3)
{
    id number = [array objectAtIndex:3];
    if ([number respondsToSelector:@selector(unsignedIntValue)])
    {
        myMagicNumber = [number unsignedIntValue];
    }
}

we now have code like this:

unsigned myMagicNumber = [[plist arrayForKey:@"someArray"] unsignedIntAtIndex:3];

which will not throw an exception if @"someArray" is not an array or if the array has less than four members, but will instead return 0. It’s also shorter than the broken version. Default values other than 0 can be provided in the form [array integerAtIndex:3 defaultValue:-1] or [dictionary unsignedShortForKey:@"value" defaultValue:14].

Oolite is obviously an extreme case, but many applications deal with property lists. Even more deal with NSUserDefaults, which of course is a wrapper around property lists. You may think that you know what you’re putting into user defaults and can therefore rely on it to be correctly structured, but if you’re thinking that you’re wrong. First, users will modify your preferences file, break it, and forget they did it. Second, your code is buggy. If you write any sort of collection to your prefs, there’s a chance that you’ll put an object of the wrong class there if the phase of the moon is unusual. If you don’t check it when you read it, this will cause an exception, and you’ll end up guiding a user through digging around in ~/Library to clean up your mess. Better to be fault-tolerant to start with.

So, here it is: JAPropertyListAccessors 1.0.2 (MIT/X11 license). It provides:

• A non-throwing variant of -[NSArray objectAtIndex:].
• Functions to convert objects (NSNumber or NSString) to all standard integer types, as well as float and double, clamping the results rather than overflowing, and returning a user-specified default value if no conversion can be performed.
• Convenience methods for accessing integers, floats, strings, arrays, dictionaries, sets, or objects of a specified class from NSArray, NSDictionary or NSUserDefaults. The following transparent conversions are performed when appropriate: NSString to numbers; NSNumber and NSDate to NSString; NSArray to NSSet.
• Convenience methods to set integers and floating-point values in NSMutableArray, NSMutableDictionary and NSUserDefaults.
• Unit tests for the primitive conversion functions.
• Compatible with 32-bit and 64-bit runtimes, and with garbage-collected and non-GC code.
• Very little in the way of comments.

Update (version 1.0.1): Default value (rather than nil) is now returned when conversion to string fails. String conversion now uses -stringValue if available.

]]> http://jens.ayton.se/blag/property-list-extractors/feed/ 1 http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/ http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/#comments Fri, 09 Nov 2007 18:51:42 +0000 Jens Ayton http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/ Continue reading →]]> Note: As of Snow Leopard, this functionality has been superseded by an official Dock tile plug-in mechanism.

---

One of the minor yet shiny new features of Mac OS X 10.5 is that iCal’s dock icon now shows the correct date even when iCal is not running. Some assumed this to be hard-coded functionality in the dock, but a few brave souls – well, one, being me – decided to find out.The following lines in iCal’s Info.plist are a bit of a hint:

<key>DockExtra</key>
<string>iCalDockExtra.bundle</string>

iCalDockExtra.bundle can be found in iCal’s Resources directory. 90 seconds with class-dump, otool, and class-dump again show that the bundle implements a subclass of DockExtra, which in turn is defined in the private SystemUIPlugin.framework.

Having retrieved the interface declaration for the DockExtra class from class-dump, it is a simple matter to implement a subclass which logs which methods are called and when. As it turns out, the only ones called are -_initWithController: and -dealloc, but through the power of my mighty brain I worked out that I could draw the dock icon whenever I wished, using -getContext: to get a drawing context and size, -setDockImageFromContext to update the image in the dock and -releaseContext to clean up afterwards.

And that’s pretty much it. Code is here. Read the Read Me first. (The most important caveat is that the bundle is never unloaded while SystemUIServer is running.) If someone actually uses this for something useful, please tell me about it.

Edit: I thought I’d said this earlier, but apparently not: as pointed out in the comments, Alacatia Labs published the same information a week before me, and did a slightly better job too. If I had used the power of the intergoogles, I would have known that, but then I’d have missed the fun of working it out.

]]> http://jens.ayton.se/blag/the-mysteries-of-ical-revealed/feed/ 23 http://jens.ayton.se/blag/a-corny-plug-in/ http://jens.ayton.se/blag/a-corny-plug-in/#comments Tue, 02 Oct 2007 17:00:30 +0000 Jens Ayton http://jens.ayton.se/blag/a-corny-plug-in/ Continue reading →]]> As soon as I saw Gus Mueller’s offer of a free license for anyone writing a decent plug-in for Acorn, I felt moved to exploit his generosity contribute to the nascent plug-in community. So I quickly slapped together a possibly-useful filter, which ended up being a simple wrapper for a Core Image kernel (my first). Obviously that should be repackaged as an Image Unit. However, it did crash in a confusing way for a while, which is good, because it inspired me to write (most of) a test rig: a command-line tool which loads a given Acorn plug-in and runs each action it registers.

Then I started on a new plug-in, which is UI-centric and therefore can’t usefully be tested on the command line.

As such, the test rig isn’t ready, but the new plug-in is. It adds an Export… menu item to Acorn’s File menu, allowing the export of any file format supported by ImageIO – currently BMP, GIF, JPEG, JPEG 2000, OpenEXR, PDF, Photoshop, PICT, PNG, SGI, TGA and TIFF. Some of these are already supported by Acorn. But hey, some aren’t.

Plug-in and source code (MIT/X11 license) available here.

]]> http://jens.ayton.se/blag/a-corny-plug-in/feed/ 2 http://jens.ayton.se/blag/priority-queue/ http://jens.ayton.se/blag/priority-queue/#comments Fri, 14 Sep 2007 16:01:10 +0000 Jens Ayton http://jens.ayton.se/blag/priority-queue/ Continue reading →]]> The Foundation framework: it has some collections. It doesn’t have others.

In particular, it doesn’t have a priority queue, which I need. CoreFoundation does, but this is for Oolite so it needs to work with GNUstep. Yes, I could bring in all of CFLite, but without the toll-free-bridging it’s not particularly attractive.

Mike Ash (who seems to be getting an indecent amount of exposure in this blog, to the extent that it counts as an exposed location) wrote about the issue last year. His solution was to use the C++ Standard Template Library, but I don’t like that solution much because a) GNUstep doesn’t play nice with Objective-C++ (its headers aren’t C++-clean) and b) it’s C++.

So, as you may have guessed, I’ve gone and written one. Here it is, with the small amount of Oolite dependency ripped out. MIT/X11 license.

Operations supported:

• Add object.
• Add all objects in a collection (anything that responds to -objectEnumerator or -nextObject).
• Retrieve highest-priority object. Priority is defined by a comparison method specified when creating the priority queue. Priority is defined such that the NSOrderedDescendingmost object has the highest priority; as such, using caseInsensitiveCompare: as the comparator will cause strings to be retrieved in lexicographic order.
• Delete highest-priority object.
• Delete specific object.
• Delete equal object (i.e., delete one object such that the comparator returns NSOrderedSame).
• Retrieve all objects in sorted order, emptying the queue.
• Equality testing and (low-quality) hashing.
• Copying of the entire queue.
]]> http://jens.ayton.se/blag/priority-queue/feed/ 3 http://jens.ayton.se/blag/performance-comparisons-of-common-operations-ppc-edition/ http://jens.ayton.se/blag/performance-comparisons-of-common-operations-ppc-edition/#comments Sun, 26 Aug 2007 15:13:45 +0000 Jens Ayton http://jens.ayton.se/blag/performance-comparisons-of-common-operations-ppc-edition/ Continue reading →]]> Mike Ash has written some microbenchmarks to test the speed of operations like Objective-C message dispatch and object creation, in response to people’s premature optimizations based on unfound assumptions. This is one of those issues that comes up rather often. The numbers are interesting – especially the Objective-C message send vs. floating point division – but I wanted some numbers for PowerPC, since ABI and hardware differences could be expected to reorder the list somewhat.


So here they are. There are two sets of numbers, with and without optimization (-O3 vs. -O0) because they have different weak points. The test system is a 1.6 Ghz iMac G5 with 1.5 GB of RAM and stock hard disk. First, the optimized numbers:

Name	Iterations	Total time (sec)	Time per (ns)
Floating-point division	100000000	-0.0	-0.0
Integer division	1000000000	-0.0	-0.0
Float division with int conversion	100000000	0.0	0.0
IMP-cached message send	1000000000	4.6	4.6
C++ virtual method call	1000000000	6.5	6.5
Objective-C message send (accelerated)	1000000000	13.9	13.9
16 byte memcpy	100000000	2.0	19.8
Objective-C message send (regular)	1000000000	20.5	20.5
16 byte malloc/free	100000000	18.2	182.3
NSInvocation message send	10000000	7.3	728.5
NSObject alloc/init/autorelease	10000000	7.6	761.1
NSAutoreleasePool alloc/init/autorelease	10000000	8.8	883.2
16MB malloc/free	100000	1.3	13261.6
NSButtonCell creation	1000000	15.5	15461.7
Read 16-byte file	100000	3.2	31881.5
Zero-second delayed perform	100000	5.3	53081.2
pthread create/join	10000	1.0	97580.2
NSButtonCell draw	100000	19.2	192317.0
Write 16-byte file	10000	5.0	498845.9
1MB memcpy	10000	10.3	1029161.4
Write 16-byte file (atomic)	10000	12.1	1208244.8
NSTask process spawn	1000	16.5	16538000.4
Read 16MB file	100	9.1	91019080.5
Write 16MB file	30	18.8	625328159.8
Write 16MB file (atomic)	30	19.1	635190321.8

The obvious problem here is that the division loops have been optimized away. Other than that, we can see that, er, my computer is slower than Mike’s, as expected. We can also see that the “accelerated Objective-C dispatch” (PowerPC only) provides a significant boost. I wanted to try “assume non-nil receivers”, too, but couldn’t get it to link. The 16-byte memcpy is actually faster on my system, which I suspect is due more to set-up overhead within memcpy than anything else. Anyone have numbers on L1 cache performance?

Unoptimized numbers:

Name	Iterations	Total time (sec)	Time per (ns)
Floating-point division	100000000	0.1	1.3
Integer division	1000000000	8.1	8.1
16 byte memcpy	100000000	1.6	15.9
Objective-C message send	1000000000	25.4	25.4
IMP-cached message send	1000000000	30.5	30.5
Float division with int conversion	100000000	3.4	33.9
C++ virtual method call	1000000000	45.2	45.2
16 byte malloc/free	100000000	18.6	185.6
NSObject alloc/init/autorelease	10000000	7.3	726.2
NSInvocation message send	10000000	7.9	791.3
NSAutoreleasePool alloc/init/autorelease	10000000	9.1	906.7
16MB malloc/free	100000	1.3	13073.2
NSButtonCell creation	1000000	15.8	15770.0
Read 16-byte file	100000	3.2	31810.6
Zero-second delayed perform	100000	5.5	54678.7
pthread create/join	10000	1.0	96391.2
NSButtonCell draw	100000	19.3	192928.8
Write 16-byte file	10000	5.0	501396.6
1MB memcpy	10000	10.2	1022297.1
Write 16-byte file (atomic)	10000	12.4	1240962.9
NSTask process spawn	1000	17.0	16983961.1
Read 16MB file	100	9.0	89896392.0
Write 16MB file	30	18.7	624687735.4
Write 16MB file (atomic)	30	19.0	634871834.7

This bit adds the division loops, and the various method dispatches are significantly slower. Everything else happens outside the program’s own code and is therefore much the same.

I expected the floating point divide to be higher on the list than in the x86 version, but I was a bit sceptical at this result. However, it really is looping over the fdiv instruction, rather inefficiently:

   +96  000047a0  3c400000  lis      r2,0x0         ; Get offset of constant 1e8, high word
  +100  000047a4  384269a8  addi     r2,r2,0x69a8   ; low word
  +104  000047a8  c9a20000  lfd      f13,0x0(r2)    ; f13 = 1e8 (literal)
  +108  000047ac  c81e0040  lfd      f0,0x40(r30)   ; f0 = 42.3 (y)
  +112  000047b0  fc0d0024  fdiv     f0,f13,f0      ; f0 = f13 / f0
  +116  000047b4  d81e0048  stfd     f0,0x48(r30)   ; store result (x)
  +120  000047b8  805e0038  lwz      r2,0x38(r30)   ; r2 = counter (i)
  +124  000047bc  38020001  addi     r0,r2,0x1      ; r0 = r2 + 1
  +128  000047c0  901e0038  stw      r0,0x38(r30)   ; store result (i)
  +132  000047c4  801e0038  lwz      r0,0x38(r30)   ; load counter (i)
  +136  000047c8  805e003c  lwz      r2,0x3c(r30)   ; load counter max (iters)
  +140  000047cc  7f801000  cmpw     cr7,r0,r2      ; if (r0 < r2)
  +144  000047d0  409dffd0  ble      cr7,0x47a0     ; goto top

For comparison, here is the integer division loop, with much the same structure:

   +80  000046dc  3c003b9a  lis      r0,0x3b9a
   +84  000046e0  6000ca00  ori      r0,r0,0xca00
   +88  000046e4  805e0038  lwz      r2,0x38(r30)
   +92  000046e8  7c0013d6  divw     r0,r0,r2
   +96  000046ec  901e0040  stw      r0,0x40(r30)
  +100  000046f0  805e0038  lwz      r2,0x38(r30)
  +104  000046f4  38020001  addi     r0,r2,0x1
  +108  000046f8  901e0038  stw      r0,0x38(r30)
  +112  000046fc  801e0038  lwz      r0,0x38(r30)
  +116  00004700  805e003c  lwz      r2,0x3c(r30)
  +120  00004704  7f801000  cmpw     cr7,r0,r2
  +124  00004708  409dffd4  ble      cr7,0x46dc

Even so, two cycles for a 13-instruction loop with loads and stores in it is a bit unbelievable, especially since Shark tells me there’s a 32-cycle latency between the divide and the immediately-following store. Part of the explanation is that the benchmark framework is subtracting the cost of a do-nothing loop which compiles to this:

   +80  00004160  805e0038  lwz      r2,0x38(r30)
   +84  00004164  38020001  addi     r0,r2,0x1
   +88  00004168  901e0038  stw      r0,0x38(r30)
   +92  0000416c  801e0038  lwz      r0,0x38(r30)
   +96  00004170  805e003c  lwz      r2,0x3c(r30)
  +100  00004174  7f801000  cmpw     cr7,r0,r2
  +104  00004178  409dffe8  ble      cr7,0x4160

(Corresponding instructions are greyed out in the previous listings.) This still doesn’t completely explain the performance being observed. The accuracy of the overhead calculation is probably a bit off, and it’s hard to get it exactly right. However, any bias in this calculation applies to all the benchmarks, not just this one. It’s in the right place on the chart even if the number is suspect.

In summary, when people say PowerPCs rule on floating point performance, we really mean it.

]]> http://jens.ayton.se/blag/performance-comparisons-of-common-operations-ppc-edition/feed/ 2