Wednesday, November 29, 2006
Friday, November 17, 2006
Yesterday I had a little problem with the iBook, which was saved by some age-old knowledge from before the OS X release. Almost.
When I use an external USB mouse, I disable the internal trackpad. Now I wanted to take the computer into a different room in order to watch some TV (on the EyeTV), so unplugged all the USB stuff, plugged the EyeTV in....and the trackpad was still disabled. Now, a lesser person would have gone back into the original room, plugged the USB mouse in, and used it (or taken it with them). An equally lesser, but richer, person would own a Bluetooth mouse. But not I! I remembered a trick from the NeXT days, and returned my computer to trackpad-workingness in but a jiffy. Three jiffies.
The first thing to do is to log out - "as any fule kno" this is done from the keyboard by Command-Option-Shift-Q. At the loginwindow there still wasn't any trackpad activity, so I thought restarting the WindowServer might fix that. This is done by entering ">exit" as the username in loginwindow. Sadly, no joy. My next thought was to drop to a text console, unload the trackpad's driver kext, reload it and see what difference that made. Doing so requires entering ">console" as the username. However I decided not to pursue this as >console has been sadly broken throughout 10.4, and on some systems was broken in 10.3 too. It's annoying as occasional glitches where the graphical environment is FUBARed could probably be fixed in console mode. But this left one course of action. Enter ">restart" in the loginwindow and wait...
I should probably point out that I waited for the reboot longer than it would have taken to retrieve the mouse. But at least I wasn't defeated.
Wednesday, November 08, 2006
So I'm reviewing a book, and it happens to cover the way method lookups are performed in a particular language's object model. I'm not going to say what the book is because it's not relevant, and nothing discussed here has anything to do with that publication. But reading it made me realise just why even when the language allows it, my internal pain aversion system will always skip multiple inheritance as an option. Consider this Python code (with built-in python shell promptness):
>>> class One(object):
... def doStuff(self):
... print "One.doStuff()"
>>> class Two(One):
>>> class Three(One):
... def doStuff(self,x):
... print "Three.doStuff(%d)" % x
>>> class Four(Two,Three):
>>> class Five(Three,Two):
so, what is the method signature of a.doStuff() and b.doStuff()? Well, it depends entirely on the order in which the class hierarchy gets inspected, Python does things by leftright-bottomtop so both a and b inherit Three.doStuff(self,x). In the case of a, Four doesn't have doStuff() so it looks at Two, which doesn't so it looks at Three and finds it. However, Python also has another lookup mechanism (which was the only one available pre-2.3 or possibly 2.4, and can still be triggered by omitting the "object" superclass from One) which is left-bottomtop-right, so a inherits One's doStuff() and b inherits Three's. In the words of Peter Cook, that could confuse a stupid person...
So luckily Objective-C avoids this problem by only having an inheritance tree, and we can't add method implementations via protocols either. And my specific example is moot, because -doStuff and -doStuff: are different selectors.