« March 2005 | Main | May 2005 »

April 2005 Archives

April 6, 2005

One more reason to hate Xcode

Piko Piko
... notice the clever use of the icon feature.

April 11, 2005

Another reason to hate Xcode

Xcode

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.

April 20, 2005

My Lombard died and "buying a G5 iMac might not be such a good idea"

There are some Apple machines which work fairly well, like my G5s for example and then there are machines that just are trouble (like my Cube and my Lombard Powerbook). It seems that when Apple attempts to push the boundaries, in terms of getting hot gear to run well in small boundaries, chances are that there will be problems.

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.

April 26, 2005

Resurrected code - mullePreviousInstanceMethodForSelector

A mail exchange on the Cocoa Developers mailing list made me dig out some old code I had lying around here from a company long deceased and by an unspecified author, who I suspect might have been him. I fixed it up a little and here it is. Don't complain if it's slowing down your code :P
#import <Foundation/Foundation.h>


@interface NSObject ( MullePreviousIMP)

+ (IMP) mullePreviousInstanceMethodForSelector:(SEL) sel;

@end
and 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

April 27, 2005

Obj-C changes

As this was posted to GnuSTEP I don't see, why I can't put it here :
>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
The compiler assumes that a copy of objc_msgSend() is at a fixed memory address, and jumps directly to it. This is most useful in the context of PowerPC and Mac OS X's dynamic linker: the dynamic linker overhead for cross-library calls is significant, and the fast objc_msgSend() can be placed in a memory range that is reachable by single absolute branch instruction. I don't know how interesting this change is for GNUstep, given GNUstep's portability goals.

* GC
Apple is working on a garbage collection system for Objective-C. It is still under development, but does not use the Boehm GC available in GNUstep. These compiler changes mostly add a write barrier when assigning Objective-C instance pointers to ivars and a few other places. The write barrier is a runtime function, and is similar to the fast dispatching above. This is likely to evolve further, and probably isn't interesting for GNUstep yet.

* 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.

--
Greg Parker xxxxx@apple.com Runtime Wrangler

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..

About April 2005

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.

Powered by
Movable Type 3.34