Nat!'s Web Journal

Look at the threads details is details, not punctuation and the way forward.The further the threads get, the better they become.

I had to do something about it. The first thing I've done is to use the Google rel="nofollow" tags on my comments. Hopefully that makes my sites less interesting.

I also changed the comments URL a little to fool some of the dumber bots.

Lets see how far this carries.

API Deprecations (Section added since WWDC)

The NSArchiver and NSUnarchiver classes and other APIs in NSArchiver.h are not deprecated in this release, but may be in the next release.

The NSCalendarDate class, NSDate categories, and other APIs in NSCalendarDate.h are not deprecated in this release, but may be in the next release.

The NSDecimalNumber and NSDecimalNumberHandler classes, the NSDecimalNumberBehaviors protocol, and other APIs in NSDecimalNumber.h are not deprecated in this release, but may be in the next release. The NSDecimal struct and functions in NSDecimal.h are not deprecated in this release, but may be in the next release. Native long double support in NSNumber in the next release will replace most of the need for NSDecimal and NSDecimalNumber (and be much much faster).

Yes that's exactly the reason I always used NSDecimal. I couldn't fit those big numbers quite into double....

You use it when you implement forward:(SEL):(marg_list) on a root class and want to create an NSInvocation out of the forwarded marg_list parameter. Then one pulls out the parameters from the marg_list and stuffs them into an NSInvocation. Using forwarding makes your code way fast obviously...

To pull a parameter from marg_list you use directly or indirectly marg_getRef. This is marg_getRef:

#define marg_getRef(margs, offset, type) \
        ( (type *)((char *)margs + marg_adjustedOffset(method,offset) ) )

#if defined(__ppc__) || defined(ppc)
#define marg_prearg_size        128
#else
#define marg_prearg_size        0
#endif

#define marg_adjustedOffset(method, offset) \
        (marg_prearg_size + offset)

This doesn't inspire a whole lot of confidence. Rightfully so, because it doesn't work.

One would assume you use marg_getRef to sequentially access the marg_list by adding the size of the previously retrieved data to the offset parameter. But that fails when it should pick up the floating point parameters. These are located at offset 0 regardless.

OK it's debatable if that means "does not work" because basically, it's just a peek and poke and it does just that. But I fail to see in what regard this macro is helping me with anything. It's an interface to a type that is opaque but that you can't use, when you don't know how it is made up internally.

The problem is that NSMethodSignature sometimes doesn't calculate the offsets for the parameters of the marg_list properly (see previous entry).

NSMethodSignature <0x3040d0> types(@@:idqf@diiiiiliiid) nargs(18) frameSize(232) retType(@) retSize(4)
{0 : type(@:idqf@diiiiiliiid) size(4) offset(128)}
{1 : type(:idqf@diiiiiliiid) size(4) offset(132)}
{2 : type(idqf@diiiiiliiid) size(4) offset(136)}
{3 : type(dqf@diiiiiliiid) size(8) offset(0)}
{4 : type(qf@diiiiiliiid) size(8) offset(148)}
{5 : type(f@diiiiiliiid) size(8) offset(8)}
{6 : type(@diiiiiliiid) size(4) offset(160)}
{7 : type(diiiiiliiid) size(8) offset(16)}
{8 : type(iiiiiliiid) size(4) offset(180)}
{9 : type(iiiiliiid) size(4) offset(184)}
{10 : type(iiiliiid) size(4) offset(188)}
{11 : type(iiliiid) size(4) offset(192)}
{12 : type(iliiid) size(4) offset(196)}
{13 : type(liiid) size(4) offset(200)}
{14 : type(iiid) size(4) offset(204)}
{15 : type(iid) size(4) offset(208)}
{16 : type(id) size(4) offset(212)}
{17 : type(d) size(8) offset(24)}

Therefore the NSInvocation runs into trouble. NSInvocation obviously uses the same code to compute the argument size and offset as NSMethodSignature or uses a private API of NSMethodSignature. It's curious, why there is no public functionality in Foundation to compute the size of a value given it's @encode ing. Or is there ?

Here's a little test project that shows the lossage. ZNeK portested it onto GNUStep and it runs OK there.

InvocationTest .zip

Output on Mac OS X Tiger 10.4.2

FAILURE
Got      : abcd=1 2.0 3 4.0  efgh=5 6.0 0 0 ijkl=7 8 9 10  mnop=11 12 13 16.0
Expected : abcd=1 2.0 3 4.0  efgh=5 6.0 7 8 ijkl=9 10 11 12  mnop=13 14 15 16.0

Output in GNUStep

SUCCESS
Got      : abcd=1 2.0 3 4.0 efgh=5 6.0 7 8 ijkl=9 10 11 12 mnop=13 14 15 16.0
Expected : abcd=1 2.0 3 4.0 efgh=5 6.0 7 8 ijkl=9 10 11 12 mnop=13 14 15 16.0

There is another new version of Grow available. It's harder than Grow RPG and I solved it :)

I doctored up the screenshot, so it doesn't spoil the final screen.

I like the logo with the flying titmouse. But I think the rest won't survice the next website revision.

Anyway sometimes I update the progress report and I want to eventually create a flyer each for the various frameworks. So there is a little action on the site. There is also a little article in the works tentatively called The Story of MulleEOF which introduces EOF from a more technical standpoint, than what you usually read in the WebObjects documentation

Yup it's all pretty much just a tease at the point.

You enter the magical shrine of serenity. 
Your intelligence went up by 20.
"Excellent!"
...
You leave the magical shrine of serentiy. 
Your intelligence went down by 20.
"Duh!"

Anyway...

In writing EOF classes I try to use a bit of IMP caching for some often used Objective-C calls. Even with the advent of fast Objective-C message calls in 10.4 this can be still a time saver. But a niggling problem is that in a dynamic system the IMP can get stale overtime. Stale IMPs can happen f.e. when a new category is loaded. I used to ignore this, but now I had this idea If instances listen for the NSBundleDidLoadNotification notification then they could recache the IMPs and things would be more robust.

But what I don't want is to register every object I fetch. Oh wait...