Re: NSDecimal chokes on very small numbers
My work with NSDecimal values has turned up several bugs and a documentation
error. Most of these bugs are extant under Mac OS X 10.5.7, and are FIXED
under Mac OS X 10.6 (10A380).
For the record:
All bugs are extant under Mac OS X 10.5.7
Extant under Mac OS X 10.6 (10A380):
NSDecimalPower() chokes on small numbers
NSDecimalIsNotANumber() incorrect documentation
FIXED under Mac OS X 10.6 (10A380):
NSDecimalAdd() bug
NSDecimalSubtract() bug
NSDecimalCompare() bug
NSDecimalNormalize() drops very small fraction
NSDecimalAdd() and NSDecimalSubtract() return incorrect results when adding
or subtracting a very small number to or from a larger number.
NSDecimalCompare() incorrectly compared NSDecimal one with NSDecimal
1+1e-34, returning NSOrderedSame when NSOrderedAscending was expected.
NSDecimalNormalize() normalized 1+1e-34 to 1.0 .
These issues are extant under Mac OS X 10.5.7 and FIXED under Mac OS X 10.6
(10A380)
Not fixed is the NSDecimalPower() bug already noted. Also, the documentation
for NSDecimalIsNotANumber() has the return values YES and NO reversed.
Bug reports:
NSDecimalPower(): 7452166
NSDecimalIsNotANumber() documentation: 7452179
Tom Bernard
tombern...@bersearch.com
on 11/21/09 7:41 AM, Tom Bernard wrote:
> Before reporting this as a bug to Apple's Bug Reporter, I would like
> feedback from the community. I am working in Leopard. Has this been fixed in
> Snow Leopard? Is there something else I am overlooking?
>
> NSDecimalPower returns an unexpected result when I raise 1e-35 to the 4th
> power. I understand that the result is too small to be supported by
> NSDecimal. The returned result:
>
> 100\
> 00 and err = NSCalculationNoError
>
> does not make sense to me. I was expecting a return of 0 and an err =
> NSCalculationLossOfPrecision.
>
>
> To reproduce:
>
> 1) create a new Foundation Tool and implement the following code:
>
> #import
>
> #define NSDStr(x) NSDecimalString(&x, nil)
>
>
> int main (int argc, const char * argv[]) {
> NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
>
> NSCalculationErrorerr;
>
> // NSDecimalPower bug
> // pow(0.1, 4);
> // result is less than minimum NSDecimal; NSDecimalPower should return 0
> with err = NSCalculationLossOfPrecision
> // (NSCalculationOverflow, NSCalculationUnderflow also understandable)
> //
> // instead returns
> 1000
> 0
> // with err = NSCalculationNoError
>
> NSDecimaloneEminusThirtyFive, oneEminusThirtyFiveToFourthPower;
> NSString*oneEminusThirtyFiveStr,
> *oneEminusThirtyFiveToFourthPowerStr;
> NSUIntegern;
>
> n = 4;
> oneEminusThirtyFive =[[NSDecimalNumber decimalNumberWithMantissa:1
> exponent:-35 isNegative:NO] decimalValue];
> err =
> NSDecimalPower(&oneEminusThirtyFiveToFourthPower, &oneEminusThirtyFive, n,
> NSRoundPlain);
>
> oneEminusThirtyFiveStr =NSDStr(oneEminusThirtyFive);
> oneEminusThirtyFiveToFourthPowerStr =
> NSDStr(oneEminusThirtyFiveToFourthPower);
>
> printf("oneEminusThirtyFive = %s\n",
> [oneEminusThirtyFiveStr UTF8String]);
> printf("oneEminusThirtyFiveToFourthPower = %s\n",
> [oneEminusThirtyFiveToFourthPowerStr UTF8String]);
> printf("err = %u\n",err);
> printf("\n");
>
>
> [pool drain];
> return 0;
> }
>
>
> The above code outputs:
>
> oneEminusThirtyFive = 0.001
> oneEminusThirtyFiveToFourthPower =
> 1000
> 0
> err = 0
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: extracting the mantissa for a NSDecimal
So to avoid the endian quagmire, I should create an NSDecimalNumber from my NSDecimal and add that to my dictionary. NSDecimal pi = ... // 3.1415927... NSDecimalNumber *piNSD = [NSDecimalNumber decimalNumberWithDecimal:pi]; I plan to write a pair of apps that saves NSDecimal values to a file and retrieves them. I plan to test these apps on modern and legacy hardware to verify the endian question. But for now, that is a side-track for me. Has anyone already done such a test? ++ Tom Tom Bernard tombern...@bersearch.com on 11/20/09 1:02 PM, Greg Guerin wrote: > Message: 6 > Date: Fri, 20 Nov 2009 10:53:35 -0700 > From: Greg Guerin > Subject: Re: extracting the mantissa for a NSDecimal > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Tom Bernard wrote: > >> NSData *anNSDecimalAsData = [NSData dataWithBytes:&anNSDecimal >> length:sizeof(NSDecimal)]; >> >> gives you an NSData object suitable for an NSDictionary without >> having to >> muck around with NSDecimal's private fields. > > > The representation stored in the NSData may be endian-sensitive. If > the NSDictionary contents might cross architectures, that could be > problematic. on 11/20/09 1:02 PM, Jens Alfke wrote: > Message: 8 > Date: Fri, 20 Nov 2009 10:49:27 -0800 > From: Jens Alfke > Subject: Re: extracting the mantissa for a NSDecimal > To: Greg Guerin > Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; > delsp=yes > > > On Nov 20, 2009, at 9:53 AM, Greg Guerin wrote: > >> The representation stored in the NSData may be endian-sensitive. If >> the NSDictionary contents might cross architectures, that could be >> problematic. > > s/may be/is/ > s/could be/will be/ > > NSDecimal is a struct containing multi-byte integers. It is definitely > endian-sensitive. on 11/20/09 1:02 PM, Gary L. Wade wrote: > Message: 11 > Date: Fri, 20 Nov 2009 11:33:30 -0800 > From: "Gary L. Wade" > Subject: Re: extracting the mantissa for a NSDecimal > To: Jens Alfke, Greg Guerin > Content-Type: text/plain;charset="US-ASCII" > > On 11/20/2009 10:49 AM, "Jens Alfke" wrote: > >> >> On Nov 20, 2009, at 9:53 AM, Greg Guerin wrote: >> >>> The representation stored in the NSData may be endian-sensitive. If >>> the NSDictionary contents might cross architectures, that could be >>> problematic. >> >> s/may be/is/ >> s/could be/will be/ >> >> NSDecimal is a struct containing multi-byte integers. It is definitely >> endian-sensitive. >> > > I haven't been following this closely, but NSDecimalNumber both takes an > NSDecimal and conforms to the NSCoding Protocol on 11/20/09 10:14 AM, Roland King wrote: > Message: 5 > Date: Fri, 20 Nov 2009 20:32:05 +0800 > From: Roland King > Subject: Re: extracting the mantissa for a NSDecimal > To: Tom Bernard > Content-Type: text/plain; charset=us-ascii > > I don't know if he ever did get an answer however your method of putting it in > an NSData is a much better idea and the original question sort of missed the > point. > > Yes there is a constructor for NSDecimalNumber which allows you to give a > mantissa and an exponent, but that doesn't mean the number is stored in a way > which lets you get those out again. For instance mantissa 123 with exponent 3 > is the same number as 123000 with exponent 0. It's true that it would be > possible for NSDecimalNumber to have an instance method which returned one > possible combination of mantissa, exponent and sign which represented the > number, but it doesn't, and you really shouldn't need it. > > it's a little like using [ stringWithFormat:@"%...@%@" string1, string2, nil ] > > to make a string and then expecting there's a method you can call later which > gets you string1 and string2 back, but of course by then you just have the > resulting string, you can't go backwards. > > There is -(NSDecimal)decimal method which returns a structure with > mantissa/exponent etc however the fields in that are explicitly declared to be > private, so you really shouldn't use it. > > You really need to treat it as a black box if you wish to save and restore it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSDecimal chokes on very small numbers
Before reporting this as a bug to Apple's Bug Reporter, I would like
feedback from the community. I am working in Leopard. Has this been fixed in
Snow Leopard? Is there something else I am overlooking?
NSDecimalPower returns an unexpected result when I raise 1e-35 to the 4th
power. I understand that the result is too small to be supported by
NSDecimal. The returned result:
100\
00 and err = NSCalculationNoError
does not make sense to me. I was expecting a return of 0 and an err =
NSCalculationLossOfPrecision.
To reproduce:
1) create a new Foundation Tool and implement the following code:
#import
#define NSDStr(x) NSDecimalString(&x, nil)
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSCalculationErrorerr;
// NSDecimalPower bug
// pow(0.1, 4);
// result is less than minimum NSDecimal; NSDecimalPower should return 0
with err = NSCalculationLossOfPrecision
// (NSCalculationOverflow, NSCalculationUnderflow also understandable)
//
// instead returns
1000
0
// with err = NSCalculationNoError
NSDecimaloneEminusThirtyFive, oneEminusThirtyFiveToFourthPower;
NSString*oneEminusThirtyFiveStr,
*oneEminusThirtyFiveToFourthPowerStr;
NSUIntegern;
n = 4;
oneEminusThirtyFive =[[NSDecimalNumber decimalNumberWithMantissa:1
exponent:-35 isNegative:NO] decimalValue];
err =
NSDecimalPower(&oneEminusThirtyFiveToFourthPower, &oneEminusThirtyFive, n,
NSRoundPlain);
oneEminusThirtyFiveStr =NSDStr(oneEminusThirtyFive);
oneEminusThirtyFiveToFourthPowerStr =
NSDStr(oneEminusThirtyFiveToFourthPower);
printf("oneEminusThirtyFive = %s\n",
[oneEminusThirtyFiveStr UTF8String]);
printf("oneEminusThirtyFiveToFourthPower = %s\n",
[oneEminusThirtyFiveToFourthPowerStr UTF8String]);
printf("err = %u\n",err);
printf("\n");
[pool drain];
return 0;
}
The above code outputs:
oneEminusThirtyFive = 0.001
oneEminusThirtyFiveToFourthPower =
10000000
00000
err = 0
Tom Bernard
tombern...@bersearch.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: extracting the mantissa for a NSDecimal
Hello Olivier,
I am working with NSDecimals and ran across your 7 year old post in
Cocoa-dev. Did you ever get an answer to your mantissa question? The
archives do not show a response to the thread.
Btw, did you consider NSData's
+dataWithBytes:length:
method?
NSData *anNSDecimalAsData = [NSData dataWithBytes:&anNSDecimal
length:sizeof(NSDecimal)];
gives you an NSData object suitable for an NSDictionary without having to
muck around with NSDecimal's private fields.
++ Tom
Tom Bernard
tombern...@bersearch.com
> --__--__--
>
> Message: 11
> Date: Tue, 29 Oct 2002 12:37:35 -0600
> Subject: extracting the mantissa for a NSDecimal
> From: Olivier <...>
> To: cocoa apple <...>
>
> i'm trying to save an NSDecimal in a dictionary.
>
> I study the NSDecimal structure and decided that all i really need to
> save are:
> _exponent, _isNegative and _mantissa field
>
> i'm trying to get the mantissa field, i want to store it as a NSNumber
> in my dictionary.
>
> the length field of the NSDecimal tells how many short of the mantissa
> are relevant
>
> so i'm building my data this way:
>
> NSMutableData *theNumberData = [NSMutableData
> dataWithLength:16];
> for (i = 0; i < valueOfObject._length; i++)
> {
> [theNumberData replaceBytesInRange: NSMakeRange(16 -
> (i+1) * 2, 2)
> withBytes:
> &valueOfObject._mantissa[i]];
>
> }
>
> so that the relevant field are put in the data object starting from the
> end of the object (most significant bytes first)
>
> then start the problem, converting it to an NSNumber i tried:
>
> const char *theNumberPtr = [theNumberData bytes];
> [NSNumber numberWithUnsignedLongLong: *theNumberPtr]
> [NSNumber numberWithUnsignedLongLong: theNumberPtr[0]]
> [NSNumber numberWithUnsignedLongLong: &theNumberPtr]
>
> without any success.
>
> Any idea of how to get that mantissa in a NSNumber?
>
> Olivier
>
> --__--__--
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSNumberFormatter unsigned long long bug?
NSNumberFormatter returns negative numbers for unsigned long long n such
that (LLONG_MAX + 1) <= n <= ULLONG_MAX. Am I doing something incorrect, or
should I report this as a bug?
- (void)awakeFromNib
{
NSNumberFormatter *formatter = [[NSNumberFormatter alloc] init];
[formatter setFormatterBehavior:NSNumberFormatterBehavior10_4];
[formatter setFormat:@"#,##0; -#,##0"];
unsigned long long uLLongMax = ULLONG_MAX; // debugger shows
18446744073709551615
NSNumber *uLLongMaxNumber = [NSNumber
numberWithUnsignedLongLong:uLLongMax];// debugger shows
18446744073709551615
NSString *uLLongMaxString = [formatter
stringFromNumber:uLLongMaxNumber]; // debugger shows -1
[unsignedLongLongTextField setStringValue:uLLongMaxString];
unsigned long long lLongMax = (unsigned long long)LLONG_MAX;//
debugger shows 9223372036854775807
NSNumber *lLongMaxNumber = [NSNumber
numberWithUnsignedLongLong:lLongMax]; // debugger shows
9223372036854775807
NSString *lLongMaxString = [formatter stringFromNumber:lLongMaxNumber];
// debugger shows 9,223,372,036,854,775,807
[unsignedLongLongTextField2 setStringValue:lLongMaxString];
unsigned long long lLongMaxPlusOne = (unsigned long long)LLONG_MAX + 1;
// debugger shows 9223372036854775808
NSNumber *lLongMaxPlusOneNumber = [NSNumber
numberWithUnsignedLongLong:lLongMaxPlusOne];// debugger shows
9223372036854775808
NSString *lLongMaxPlusOneString = [formatter
stringFromNumber:lLongMaxPlusOneNumber]; // debugger shows
-9,223,372,036,854,775,808
[unsignedLongLongTextField3 setStringValue:lLongMaxPlusOneString];
}
Thanks in advance.
++ Tom
Tom Bernard
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: NSCalendarDate to be deprecated
Please do jump in late, especially with a 20 microsecond suggestion. Full details are at http://bersearch.com/PrivateTechSupport/NSCalendarBenchmark/NSCalendarBench mark1.0.zip I have filed a bug report titled Planned NSCalendarDate deprecation yields slower performance Bug ID# 6179834 Thanks again to you and to Eliza Block for your suggestions. ++ Tom Tom Bernard [EMAIL PROTECTED] on 8/22/08 12:00 AM, Ryan McGann at [EMAIL PROTECTED] wrote: >> As written, 70 microseconds. When I set the calendar's time zone to >> GMT, the >> time drops to 43 microseconds. Since my app will only work with >> dates in >> GMT, this is a plus. Even so, 40 microseconds is far slower than the >> 7 - 8 >> microseconds offered by -[NSCalendarDate dayOfYear]. Unless someone >> has >> another offering, I plan to file a bug report on this issue. This >> calculation is part of an animation loop, so the performance hit is >> important. > Sorry to jump in late, but I am just now getting around to reading > about 5 days worth of email. Did you try caching the NSCalendar > creation call? I believe we had a similar performance issue with > CFCalendar (which no doubt shares its implementation with NSCalendar), > and I found out with Shark and fs_usage that each CFCalendarCreate > call results in many (very large) region data files being read into > memory. Turns out reading several megabytes from the > filesystem is expensive, so caching the CFCalendarCreate > resulted in a big performance gain. Not sure if NSCalendar implements > any caching on its own, but you might give it a shot. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSCalendarDate to be deprecated
As written, 70 microseconds. When I set the calendar's time zone to GMT, the
time drops to 43 microseconds. Since my app will only work with dates in
GMT, this is a plus. Even so, 40 microseconds is far slower than the 7 - 8
microseconds offered by -[NSCalendarDate dayOfYear]. Unless someone has
another offering, I plan to file a bug report on this issue. This
calculation is part of an animation loop, so the performance hit is
important.
Btw, my two offerings return an incorrect 367 for the date 2008-12-31
23:59:59 +; 2008 being a leap year, the correct return is 366. Your
offering and NSCalendarDate get it right.
int dayOfYearForDate4(NSDate *_date)
{
NSTimeZone *gmtTimeZone = [NSTimeZone timeZoneForSecondsFromGMT:0];
NSCalendar *calendar = [[NSCalendar alloc]
initWithCalendarIdentifier:NSGregorianCalendar];
[calendar setTimeZone:gmtTimeZone];
int day = [calendar ordinalityOfUnit:NSDayCalendarUnit
inUnit:NSYearCalendarUnit forDate:_date];
return day;
}
on 8/18/08 7:34 AM, Eliza Block at [EMAIL PROTECTED] wrote:
> You could do this:
>
> int dayOfYearForDate(NSDate *_date)
> {
> NSCalendar *calendar = [[NSCalendar alloc]
> initWithCalendarIndentifier:NSGregorianCalendar]];
> int day = [calendar ordinalityOfUnit:NSDayCalendarUnit
> inUnit:NSYearCalendarUnit forDate:_date];
> return day;
> }
>
> I've never benchmarked this, but it's certainly a lot less code.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
NSCalendarDate to be deprecated
My application needs to obtain the day of year for a given date. In the
past, this was easily done with an NSCalendarDate.
// NSCalendarDate faces deprecation
int dayOfYearForDate1(NSDate *_date)
{
NSTimeZone *gmtTimeZone = [NSTimeZone timeZoneForSecondsFromGMT:0];
NSCalendarDate *calendarDate = [_date dateWithCalendarFormat:nil
timeZone:gmtTimeZone];
int day = [calendarDate dayOfYear];
return day;
}
NSCalendarDate faces deprecation: "Use of NSCalendarDate strongly
discouraged. It is not deprecated yet, however it may be in the next major
OS release after Mac OS X v10.5. For calendrical calculations, you should
use suitable combinations of NSCalendar, NSDate, and NSDateComponents, as
described in Calendars in Dates and Times Programming Topics for Cocoa."
The above advice led to two alternate functions:
int dayOfYearForDate2(NSDate *_date)
{
NSTimeZone *gmtTimeZone = [NSTimeZone timeZoneForSecondsFromGMT:0];
NSCalendar *calendar = [[NSCalendar alloc]
initWithCalendarIdentifier:NSGregorianCalendar];
[calendar setTimeZone:gmtTimeZone];
NSDateComponents *components = [calendar components:NSYearCalendarUnit
fromDate:_date];
int year = [components year];
components = [[NSDateComponents alloc] init];
[components setYear:year -1];
[components setMonth:12];
[components setDay:30];
[components setHour:23];
[components setMinute:59];
[components setSecond:59];
NSDate *lastYear1230 = [calendar dateFromComponents:components];
[components release];
components = [calendar components:NSDayCalendarUnit
fromDate:lastYear1230 toDate:_date options:0];
int day = [components day];
[calendar release];
return day;
}
int dayOfYearForDate3(NSDate *_date)
{
NSTimeZone *gmtTimeZone = [NSTimeZone timeZoneForSecondsFromGMT:0];
NSCalendar *calendar = [[NSCalendar alloc]
initWithCalendarIdentifier:NSGregorianCalendar];
[calendar setTimeZone:gmtTimeZone];
NSDateComponents *components = [calendar components:NSYearCalendarUnit
fromDate:_date];
int year = [components year];
NSString *dateString = [NSString stringWithFormat:@"%d-12-30 23:59:59
-", year - 1];
NSDate *lastYear1230 = [NSDate dateWithString:dateString];
components = [calendar components:NSDayCalendarUnit
fromDate:lastYear1230 toDate:_date options:0];
int day = [components day];
[calendar release];
return day;
}
To decide whether to use dayOfYearForDate2() or dayOfYearForDate3() in my
application, I benchmarked all three functions:
dayOfYearForDate1(): 8.76544 microseconds
dayOfYearForDate2(): 46.9595 microseconds
dayOfYearForDate3(): 74.5191 microseconds
(The above times include 0.4 microseconds attributable to the testing
overhead.)
Since Apple's engineers would not throw away a perfectly good object without
providing something better, I must be doing things the hard way. What is the
easy way?
Thanks in advance.
++ Tom
Tom Bernard
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
File types opened by NSDocument architecture
/*
+ (NSArray *)readableTypes
{
return [NSArray arrayWithObjects:@"TIFF", @"tiff", @"TIF", @"tif",
@"GIF", @"gif", @"JPEG", @"jpeg", @"JPG", @"jpg", @"png", nil];
}
*/
My application needs to open the above listed file types. When I am in
Finder and I drag and drop one one of these files to my application, the
file opens. When I choose 'Open...' from my application's 'File' menu, only
.tif and .psd files are selectable in the open dialog.
Note that +readableTypes is commented out above. When I uncomment the method
in my NSDocument implementation, no files are selectable in the open dialog.
Here is an excerpt from my info.plist:
CFBundleDocumentTypes
CFBundleTypeExtensions
psd
CFBundleTypeName
Adobe Photoshop file
CFBundleTypeOSTypes
psd
CFBundleTypeRole
Editor
LSTypeIsPackage
NSDocumentClass
LIVDocument
NSPersistentStoreTypeKey
Binary
CFBundleTypeExtensions
gif
CFBundleTypeIconFile
CFBundleTypeName
Large Image Viewer GIF Document
CFBundleTypeOSTypes
gif
CFBundleTypeRole
Editor
LSTypeIsPackage
NSDocumentClass
LIVDocument
...
The info.plist includes a dictionary for each of the above listed types.
Thanks in advance.
Tom Bernard
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
