One more reason to hate Xcode

... notice the clever use of the icon feature.
« March 2005 | Main | May 2005 »

This happens to me on daily basis, sometimes even more often. Some magical keyboard mispress on the german keyboard, produces these characters that Xcode can't show. Editing out characters, that you don't see is pretty hard. And "Show Control Characters" doesn't show them either. So does Xcode let them entered in the first place ?
Solution ? Reveal in Finder, use emacs to edit them out. Then I ponder over the reasons, why I am not using emacs and make in the first place.
It appears the latest iMacs are also plagued with problems as I have learned from a close acquaintance :) and this pretty telling article: New iMac a Rotten Apple. I experienced all this shit with Apple as well, but not with one machine in one year, but with three Apples over the course of many years.
My Lombard was misdelivered with less MHz and it took some time to get it changed to the proper model. I remember shipping time was in terms of months also, but we didn't have tracking then. It never ran Mac OS X Server 1.2 properly, and until the last repair fix, also was prone to crashing in Mac OS X. My first G5 also took months from purchase to delivery. My cube fairly soon developed the problem of "just shutting down", when it wanted to, so I had to sent it back. Now it just turns off, when I hit the desk fairly hard...
But the Lombard Powerbook really was just always a source of trouble throughout its lifetime. It now has decided to cease functioning again, promptly six months after I spent what I remembered to be about € 400 for fixing it up. During the first fixup, the indicated repair wasn't even done and just the keyboard replaced and it took lenghty discussions with Gravis headquarters and Apple to get it right, although Gravis Bochum lied to me and even tried to cheat me.
As long as it works, the Apple is a good deal, but when it breaks down, you may get to know the ugly side of Apple.
Apple's business plan for you the customer is this, if you buy an Apple you should buy Apple Care to insure it's lifetime of three years. After that the repair costs and hassles are just so high, that you buy a new machine. If you luck out and your Mac runs for longer than that, Apple ensures your purchase of a new machine after an estimated five or six years, by dropping support from the operating system. Tiger wouldn't run anyway on the Lombard, because this Powerbook doesn't have "Firewire" support, so critically necessary for operation.
#import <Foundation/Foundation.h> @interface NSObject ( MullePreviousIMP) + (IMP) mullePreviousInstanceMethodForSelector:(SEL) sel; @endand the implementation
#import "NSObject+MullePreviousIMP.h"
#import <objc/objc-class.h>
@implementation NSObject ( MullePreviousIMP)
+ (IMP) mullePreviousInstanceMethodForSelector:(SEL) sel
{
struct objc_method_list *mlist;
struct objc_method *p;
void *rover;
int i;
BOOL flag;
IMP imp;
Class curClass;
flag = NO;
rover = 0;
imp = [self instanceMethodForSelector:sel];
for( curClass = self; curClass; curClass = [curClass superclass])
{
while( (mlist = class_nextMethodList( curClass, &rover)) != NULL)
{
for( i = mlist->method_count - 1; i >= 0 ; i--)
{
p = &mlist->method_list[ i];
if( p->method_name == sel)
{
if( p->method_imp == imp)
{
flag = YES;
break;
}
if( flag)
return( p->method_imp);
break;
}
}
}
}
return( NULL);
}
Here is an archive with some test code: MullePreviousIMP.tgz
>On Apr 26, 2005, at 3:13 PM, Mike Stump wrote: >I'm pushing the Objective-C++ frontend into the FSF source tree on mainline. >In doing this, I'm also pushing various >updates to the Objective-C language; fast dispatching, >GC, a new warning or two, a way to get at C++ ctors/dtors from a >ObjC method. Most of these would require library work to be complete. Some details:
* fast dispatching
* GC * C++ ctors / dtors In Objective-C++, an Objective-C class may have ivars that are C++ objects with constructors and destructors. This compiler change emits -.cxx_construct and -.cxx_destruct methods containing the C++ default constructors and destructors for these classes. The runtime calls these methods during instance allocation and deallocation. The ctors/dtors are probably interesting for GNUstep, because it makes Objective-C++ much easier for the programmer. Apple's runtime support is new in Tiger, so you'll be able to see it in the upcoming Darwin release. Adding support to GNU libobjc should be straightforward.
--
|
The immediate call to zero page memory (as we old timers like to call it fondly) will be a big win and the advantage of using IMPs will diminish greatly (although not completely).
I hope there will be a possibility to turn the GC mechanism off and still use Foundation and Appkit, otherwise I am most likely to become very unhappy with future Mac OS versions..
This page contains all entries posted to Nat!'s Web Journal in April 2005. They are listed from oldest to newest.
March 2005 is the previous archive.
May 2005 is the next archive.
Many more can be found on the main index page or by looking through the archives.