Re: NSFileWrapper serializedRepresentation bloat?

2011-01-10 Thread Matt Gough 
Not sure its related, but I have noticed that using Finder nowadays to create 
an alias of a plain folder results in a 1MB alias file. Seems its also stashing 
away a copy of the plain folder icon. (Actually it is stashing two copies, one 
in the resource fork for compatibility and one in the data fork.)
It doesn't do this when creating aliases of files.


On 10 Jan 2011, at 07:40:05, mlist0...@gmail.com wrote:

> Problem ID: 8840391
> 
> _murat
> 
> On Jan 8, 2011, at 7:55 PM, Ken Ferry wrote:
> 
>> Hi,
>> 
>> That's what I see too.  From inspecting the serialized rep, it looks like 
>> it's icon data.
>> 
>> Since at least in my test case the folders did not have custom icons, it 
>> seems like one could do better.  Could you file a bug please?
>> 
>> -Ken
>> Cocoa Frameworks
>> 
>> On Sat, Jan 8, 2011 at 5:16 PM, mlist0...@gmail.com  
>> wrote:
>> I create an NSFileWrapper for a directory hierarchy like this (all items are 
>> directories, no files):
>> 
>> test-dir/
>> test-dir/inner-dir-a
>> test-dir/inner-dir-b
>> test-dir/inner-dir-c
>> 
>> The wrapper's serialized representation weighs in at around an astounding 
>> 1mB (1,022,234 bytes)!
>> 
>> Seems that the overhead per folder is around 300kB. Can that be right?
>> 
>> Code:
>> 
>> NSURL* url = [NSURL fileURLWithPath:@"/User/foo/Desktop/test-dir"];
>> NSFileWrapper w = [[NSFileWrapper alloc] initWithURL:url options:0  
>> error:nil];
>> 
>> NSData* data = [w serializedRepresentation];
>> 
>> NSLog(@"%d", [data length]);
>> 
>> 
>> _murat
> 
> ___
> 
> 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/mgough%40humyo.com
> 
> This email sent to mgo...@humyo.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

Initializing a view controller...

2011-01-10 Thread Phil Hystad 
Is there a proper way to initialize a view controller.  So far, I have been 
doing this in the application delegate by calling calling an initialize method 
( i.e. [viewController initialize]) in 
application:didFinishLaunchingWithOptions: method (prior to the view being 
added to the window and the window made visible).

However, I am not sure if this is the Cocoa canonical way of doing things.  By 
the way, this example comes from UIKit but the same question would apply to any 
OS X Cocoa application too.

phil
phys...@mac.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: Initializing a view controller...

2011-01-10 Thread Fritz Anderson 
On 10 Jan 2011, at 9:17 AM, Phil Hystad wrote:

> Is there a proper way to initialize a view controller.  So far, I have been 
> doing this in the application delegate by calling calling an initialize 
> method ( i.e. [viewController initialize]) in 
> application:didFinishLaunchingWithOptions: method (prior to the view being 
> added to the window and the window made visible).

I first wrote a brief essay on what to do, where, depending on whether you 
instantiate programmatically or in a NIB. But why not refer you to a better 
explanation than I can piece together in five minutes?

View Controller Programming Guide for iOS.


Particularly: Understanding the View Management Cycle


— F

___

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: Initializing a view controller...

2011-01-10 Thread Andreas Grosam 

On Jan 10, 2011, at 4:17 PM, Phil Hystad wrote:

> Is there a proper way to initialize a view controller.  So far, I have been 
> doing this in the application delegate by calling calling an initialize 
> method ( i.e. [viewController initialize]) in 
> application:didFinishLaunchingWithOptions: method (prior to the view being 
> added to the window and the window made visible).


*** Important ***
+(void)initialize is a class method which the runtime sends to the class 
exactly once just before any of this class' method is invoked, and any of its 
super class if +initialized has not yet been invoked.
You rarely need to override +initialize -- and you never call it yourself!



But yes, there is a proper way to do initialization of a view controller object 
:)  There are lots of examples of how you should do this within the iOS or Mac 
OS X documentation.

Basically, when you load your view from a nib you will override these methods 
in order to initialize a view controller:

-viewDidLoad
This method is called regardless of whether the views were stored in a 
nib file or created 
programmatically. You usually override it to do additional setup after 
the view has been 
loaded from a nib.
If you override -viewDidLoad you may want to override -viewDidUnload 
accordingly, which is the  "counterpart" of -viewDidLoad.
  

-awakeFormNib 
To do additional setup after the view has been loaded from a nib. You 
often can do all your setup
in viewDidLoad, but sometimes this seems a better place. At the time 
the method is invoked,
outlet and action connections are already established.


In the cases where you want to create the controller's view yourself 
programmatically, you have to use
-loadView. If you do so, you need to create the view hierarchy and assign the 
root view to the view property of the controller.


You must not call any of these methods yourself! The framework will do this for 
you when it is appropriate.


An example might be useful:

The following code assumes you have a nib where you load the view:

@interface MyViewController : UIViewController {
  IBOutlet UIView* mySpecialSubView;
  NSArray* myArray;
}

@property (retain) UIView* mySpecialSubView;
@property (retain) NSArray* myArray;

@end

@implementation
@synthesize mySpecialSubView;
@synthesize myArray;

- (void) viewDidLoad
{
[super viewDidLoad];  // always invoke super!

// In debug mode, you might check here whether you have established the 
links for your outlets in IB:
NSAssert(mySpecialSubView, @"IBOutlet 'mySpecialSubView' is nil"); // 
forgot to setup the link in IB?

// configure my view unless this is already done in IB:
self.view.backgroundColor = [UIColor blackColor];

// do other setup, for instance setting up a navigation bar, navigation item
...

// if your view controller needs to initialize other ivars, you might 
initialize them here, 
// or do "lazy initialization" (see below)
...

// Note, that viewDidLoad will be called *everytime* the view gets reloaded 
from
// the resource!
// Sometimes, you explicitly DON'T want to perform certain initialization 
steps again 
// after the view will be reloaded. In this case, use a flag as an ivar 
which determines 
// whether you have done these initialization steps:
if (!isInitialized) {
[self setupOnce];
isInitialized = YES;  // this is an ivar
} 
}


You have to override -viewDidUnload in certain cases, e.g.:

- (void) viewDidUnload {
self.mySpecialSubView = nil;// Outlets shall be set to nil!

// optionally, you might want to release myArray - just in order to safe 
memory. But
// this depends on your needs, and often you explicitly don't want the 
array to be
// recreated after a reload of the view. 
self.myArray = nil; // optionally
}



// lazy initialization - this overrides the getter method which was otherwise 
defined
// by the @synthesize directive:
- (NSArray*) myArray {
if (myArray == nil) {
myArray = [NSArray alloc] init... ];
}
return myArray;
}


// don't forget to release ivars if required:
-(void) dealloc {
[mySpecialSubView release], mySpecialSubView = nil;
[myArray release], myArray = nil;
[super dealloc];  // always invoke super (at the last statement)
}



One thing you should care of:
-viewDidLoad and -awakeFormNib, as well as -loadView may be called more than 
once for the lifetime of the view controller. So, be carefully not to 
initialize ivars in such a way that you get a memory leak. The following code 
snippet would be the wrong way:

- (void) viewDidLoad {
[super viewDidLoad];
myArray = [[NSArray alloc] init...];// possibly memory leak!
}

The way to do proper initialization would leverage properties:
- (void) viewDidLoad {
[super viewDidLoad];
NSArray* tmp = [[NSArray alloc] init...];
self.myArray = tmp;  // property

UIDatePicker displays incorrect day in UIDatePickerDateAndTime mode for zones 12+ hours ahead of defaultZone

2011-01-10 Thread Steve Mykytyn 
UIDatePicker (4.2.1) shows differing dates for the modes 

  UIDatePickerDate (correct),  and

  UIDatePickerDateAndTime (incorrect) 

when the timezone you assign to the UIDatePicker is 

  - more than 12 hours ahead (east) of the systemTimeZone of the iPhone.

For example, 

  device system time zone = America/Los Angeles = GMT - 8

  Honolulu date: Dec 7, 1941 7:48am

  Tokyo date: Dec 8, 1941 3:18am

UIDatePicker will show the Tokyo date for mode

  UIDatePickerDate (correct): Dec 8, 1941

  UIDatePickerDateAndTime: Dec 7, 1941

In fact, UIDatePicker will show incorrect dates in this case for any time zone 
east of GMT + 4 (always one day before correct day)


A work-around in viewDidLoad is:

self.datePicker.datePickerMode = UIDatePickerModeDateAndTime;   

self.datePicker.minuteInterval = 1;

self.datePicker.timeZone = timeZone;

[NSTimeZone setDefaultTimeZone:timeZone];  //  *** add this line to 
force date picker to show correct date in all modes

[self.datePicker setDate:tzDate animated:YES];  

and in viewWillDisappear add:

[NSTimeZone resetSystemTimeZone];

[NSTimeZone setDefaultTimeZone:[NSTimeZone systemTimeZone]];

Not super happy about the work-around, but it should be fairly robust even if 
this bug is fixed in future.

If anyone can shed some light on this behavior, please advise.  No amount of 
fooling around with calendars, locales, etc. fixed this until i reset the 
default zone.
  

___

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: UIDatePicker displays incorrect day in UIDatePickerDateAndTime mode for zones 12+ hours ahead of defaultZone

2011-01-10 Thread Matt Neuburg 
On Mon, 10 Jan 2011 10:12:15 -0800, Steve Mykytyn  
said:
>UIDatePicker (4.2.1) shows differing dates for the modes 
>
>  UIDatePickerDate (correct),  and
>
>  UIDatePickerDateAndTime (incorrect) 
>
>when the timezone you assign to the UIDatePicker is 
>
>  - more than 12 hours ahead (east) of the systemTimeZone of the iPhone.

I've nothing very useful to say about this particular bug, but in general 
UIDatePicker is a groaner. The docs imply you should be able to change the 
locale, but when you do, nothing changes except the language, and even that 
only in UIDatePickerDateAndTime mode. So you can't get 24-hour time, for 
example, by setting the locale to the UK, and you can't get French months in 
UIDatePickerDate mode. Playing with the timezone in a countdown timer gets you 
nonsense, and playing with the max and min dates in a countdown timer can cause 
a crash. I'd say submit a bug, though I don't see how that's likely to help 
(all my bugs are either open or archived as duplicates, but closed - i.e. fixed 
- seems to be an unknown concept). m. 

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.apeth.net/matt/default.html#applescriptthings___

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: UIDatePicker displays incorrect day in UIDatePickerDateAndTime mode for zones 12+ hours ahead of defaultZone

2011-01-10 Thread Laurent Daudelin 
On Jan 10, 2011, at 12:13, Matt Neuburg wrote:

> On Mon, 10 Jan 2011 10:12:15 -0800, Steve Mykytyn  
> said:
>> UIDatePicker (4.2.1) shows differing dates for the modes 
>> 
>> UIDatePickerDate (correct),  and
>> 
>> UIDatePickerDateAndTime (incorrect) 
>> 
>> when the timezone you assign to the UIDatePicker is 
>> 
>> - more than 12 hours ahead (east) of the systemTimeZone of the iPhone.
> 
> I've nothing very useful to say about this particular bug, but in general 
> UIDatePicker is a groaner. The docs imply you should be able to change the 
> locale, but when you do, nothing changes except the language, and even that 
> only in UIDatePickerDateAndTime mode. So you can't get 24-hour time, for 
> example, by setting the locale to the UK, and you can't get French months in 
> UIDatePickerDate mode. Playing with the timezone in a countdown timer gets 
> you nonsense, and playing with the max and min dates in a countdown timer can 
> cause a crash. I'd say submit a bug, though I don't see how that's likely to 
> help (all my bugs are either open or archived as duplicates, but closed - 
> i.e. fixed - seems to be an unknown concept). m. 

I've been wondering the same myself also. Lots of bugs that are all open or 
duplicates. Now that I think about it, I don't remember ever seeing one of the 
bug I reported as being closed as resolved...

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.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: Custom path animation for CAShapeLayer

2011-01-10 Thread Matt Neuburg 
On Sat, 08 Jan 2011 00:07:17 + (GMT), Kenneth Baxter  
said:
>
>Hi, I'm trying to use a CAShapeLayer for some paths in my application. For the 
>most part this works fine, but in some circumstances the animation from one 
>path to another looks really strange during the animation.
>
>I would be able to tell it what the path should be at any intermediate point 
>in the animation, but I'm not sure how to get access to it to provide those 
>paths.
>

A path is not a concept that has a natural and obvious interpolation, so I 
presume you'd need to do the whole animation explicitly e.g. as a keyframe 
animation. Or maybe you could sort of cheat and animate some other property; 
you can create your own animatable property such that when you set it, your 
drawInContext: is called over and over as the value changes, so you could take 
that opportunity to redraw the path appropriately. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.apeth.net/matt/default.html#applescriptthings___

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: UIDatePicker displays incorrect day in UIDatePickerDateAndTime mode for zones 12+ hours ahead of defaultZone

2011-01-10 Thread Nick Zitzmann 

On Jan 10, 2011, at 1:21 PM, Laurent Daudelin wrote:

> On Jan 10, 2011, at 12:13, Matt Neuburg wrote:
> 
>> I'd say submit a bug, though I don't see how that's likely to help (all my 
>> bugs are either open or archived as duplicates, but closed - i.e. fixed - 
>> seems to be an unknown concept). m. 
> 
> I've been wondering the same myself also. Lots of bugs that are all open or 
> duplicates. Now that I think about it, I don't remember ever seeing one of 
> the bug I reported as being closed as resolved...

I have, and they were bugs that were resolved in product updates. In each case, 
I was notified that the bug was fixed shortly after the update was published, 
and I was asked to verify the fix. The system does work, even though it is 
opaque to outsiders.

Nick Zitzmann


___

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

GCD cancel handler invocation

2011-01-10 Thread Jonathon Kuo 
I set up a source handler on a TCP socket like this:
dispatch_source_t newsrc = 
dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,sockfd,0,globalQueue); 

It works well, and when a client process closes his socket my cancel_handler 
gets called, I clean up, and life is good. But if I do a close(sockfd) from my 
side, my cancel_handler doesn't get invoked. I have to explicitly do a 
dispatch_source_cancel(). Shouldn't closing the socket be enough to cause my 
cancel_handler to be run?

___

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: GCD cancel handler invocation

2011-01-10 Thread Dave Zarzycki 
On Jan 10, 2011, at 2:06 PM, Jonathon Kuo wrote:

> I set up a source handler on a TCP socket like this:
>dispatch_source_t newsrc = 
> dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,sockfd,0,globalQueue); 
> 
> It works well, and when a client process closes his socket my cancel_handler 
> gets called, I clean up, and life is good. But if I do a close(sockfd) from 
> my side, my cancel_handler doesn't get invoked. I have to explicitly do a 
> dispatch_source_cancel(). Shouldn't closing the socket be enough to cause my 
> cancel_handler to be run?

Jonathon,

No. This is covered in the dispatch_source_create() man page under the section 
on cancelation:

Important: a cancellation handler is required for file descriptor and mach port 
based sources in order to safely close the descriptor or destroy the port. 
Closing the descriptor or port before the cancellation handler has run may 
result in a race condition: if a new descriptor is allocated with the same 
value as the recently closed descriptor while the source's event handler is 
still running, the event handler may read/write data to the wrong descriptor.

davez___

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: GCD cancel handler invocation

2011-01-10 Thread Ken Thomases 
On Jan 10, 2011, at 4:20 PM, Dave Zarzycki wrote:

> On Jan 10, 2011, at 2:06 PM, Jonathon Kuo wrote:
> 
>> I set up a source handler on a TCP socket like this:
>>   dispatch_source_t newsrc = 
>> dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,sockfd,0,globalQueue); 
>> 
>> It works well, and when a client process closes his socket my cancel_handler 
>> gets called, I clean up, and life is good. But if I do a close(sockfd) from 
>> my side, my cancel_handler doesn't get invoked. I have to explicitly do a 
>> dispatch_source_cancel(). Shouldn't closing the socket be enough to cause my 
>> cancel_handler to be run?
> 
> Jonathon,
> 
> No. This is covered in the dispatch_source_create() man page under the 
> section on cancelation:
> 
> Important: a cancellation handler is required for file descriptor and mach 
> port based sources in order to safely close the descriptor or destroy the 
> port. Closing the descriptor or port before the cancellation handler has run 
> may result in a race condition: if a new descriptor is allocated with the 
> same value as the recently closed descriptor while the source's event handler 
> is still running, the event handler may read/write data to the wrong 
> descriptor.

And, likewise, it is not safe to close a file descriptor in one thread while it 
is the subject of a read(), select(), kevent(), or similar in another thread.  
In other words, in no system API is it safe to do what you're trying to do.

Regards,
Ken

___

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: GCD cancel handler invocation

2011-01-10 Thread Jonathon Kuo 

On Jan 10, 2011, at 2:58 PM, Ken Thomases wrote:

> On Jan 10, 2011, at 4:20 PM, Dave Zarzycki wrote:
> 
>> On Jan 10, 2011, at 2:06 PM, Jonathon Kuo wrote:
>> 
>>> I set up a source handler on a TCP socket like this:
>>>  dispatch_source_t newsrc = 
>>> dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,sockfd,0,globalQueue); 
>>> 
>>> It works well, and when a client process closes his socket my 
>>> cancel_handler gets called, I clean up, and life is good. But if I do a 
>>> close(sockfd) from my side, my cancel_handler doesn't get invoked. I have 
>>> to explicitly do a dispatch_source_cancel(). Shouldn't closing the socket 
>>> be enough to cause my cancel_handler to be run?
>> 
>> Jonathon,
>> 
>> No. This is covered in the dispatch_source_create() man page under the 
>> section on cancelation:
>> 
>> Important: a cancellation handler is required for file descriptor and mach 
>> port based sources in order to safely close the descriptor or destroy the 
>> port. Closing the descriptor or port before the cancellation handler has run 
>> may result in a race condition: if a new descriptor is allocated with the 
>> same value as the recently closed descriptor while the source's event 
>> handler is still running, the event handler may read/write data to the wrong 
>> descriptor.
> 
> And, likewise, it is not safe to close a file descriptor in one thread while 
> it is the subject of a read(), select(), kevent(), or similar in another 
> thread.  In other words, in no system API is it safe to do what you're trying 
> to do.

Okay... then is the only place I should ever call the close() is from within 
the cancel_handler for that file descriptor?


___

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: GCD cancel handler invocation

2011-01-10 Thread Dave Zarzycki 

On Jan 10, 2011, at 3:04 PM, Jonathon Kuo wrote:

> 
> On Jan 10, 2011, at 2:58 PM, Ken Thomases wrote:
> 
>> On Jan 10, 2011, at 4:20 PM, Dave Zarzycki wrote:
>> 
>>> On Jan 10, 2011, at 2:06 PM, Jonathon Kuo wrote:
>>> 
 I set up a source handler on a TCP socket like this:
 dispatch_source_t newsrc = 
 dispatch_source_create(DISPATCH_SOURCE_TYPE_READ,sockfd,0,globalQueue); 
 
 It works well, and when a client process closes his socket my 
 cancel_handler gets called, I clean up, and life is good. But if I do a 
 close(sockfd) from my side, my cancel_handler doesn't get invoked. I have 
 to explicitly do a dispatch_source_cancel(). Shouldn't closing the socket 
 be enough to cause my cancel_handler to be run?
>>> 
>>> Jonathon,
>>> 
>>> No. This is covered in the dispatch_source_create() man page under the 
>>> section on cancelation:
>>> 
>>> Important: a cancellation handler is required for file descriptor and mach 
>>> port based sources in order to safely close the descriptor or destroy the 
>>> port. Closing the descriptor or port before the cancellation handler has 
>>> run may result in a race condition: if a new descriptor is allocated with 
>>> the same value as the recently closed descriptor while the source's event 
>>> handler is still running, the event handler may read/write data to the 
>>> wrong descriptor.
>> 
>> And, likewise, it is not safe to close a file descriptor in one thread while 
>> it is the subject of a read(), select(), kevent(), or similar in another 
>> thread.  In other words, in no system API is it safe to do what you're 
>> trying to do.
> 
> Okay... then is the only place I should ever call the close() is from within 
> the cancel_handler for that file descriptor?

Yes – your code can close() the descriptor then or thereafter. The important 
goal is that your code must know when libraries (such as GCD) are done 
borrowing the descriptor to do asynchronous work on behalf of your code. GCD 
solves this problem with cancelation callbacks.

davez___

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: Custom path animation for CAShapeLayer

2011-01-10 Thread David Duncan 
On Jan 7, 2011, at 4:07 PM, Kenneth Baxter wrote:

> Hi, I'm trying to use a CAShapeLayer for some paths in my application. For 
> the most part this works fine, but in some circumstances the animation from 
> one path to another looks really strange during the animation.

Core Animation's path animation requires the source and destination paths to be 
of the same structure – that is you can animate between two lines, or two 
beziers but not from a line to a bezier (as such – you can generate degenerate 
bezier curves that look like lines to emulate this).

If your source & destination paths do not meet this requirement, you may get 
unexpected results.

> I would be able to tell it what the path should be at any intermediate point 
> in the animation, but I'm not sure how to get access to it to provide those 
> paths.

The closest thing you could do here is use a Keyframe animation, but I'm not 
certain this could be done cleanly or without using lots of intermediate paths 
for even short sequences. It is something to explore.
--
David Duncan

___

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: Execute a pre-starting script first, when the App bundle is launched, then the main executable

2011-01-10 Thread Scott Ribe 
On Jan 8, 2011, at 4:46 PM, eveningnick eveningnick wrote:

> As far as i understand, this "drag to dock" issue is basically sending
> "odoc" apple event as well?
> Are there any possible pitfalls?

Maybe, I don't know. I haven't done this, just thought about it, so I don't 
know what other issues there might be besides what I mentioned. As others 
pointed out, if there's any way you could the checking from your app early in 
its launch, that would avoid all such problems.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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: Initializing a view controller...

2011-01-10 Thread Phil Hystad 
Andreas:

Thanks for the information.  Now, I should kick myself for picking the name 
initialize but then maybe I should complain about Apple picking all the best 
names for methods.

I think I have used the -viewDidLoad method before.

phil


On Jan 10, 2011, at 9:58 AM, Andreas Grosam wrote:

> 
> On Jan 10, 2011, at 4:17 PM, Phil Hystad wrote:
> 
>> Is there a proper way to initialize a view controller.  So far, I have been 
>> doing this in the application delegate by calling calling an initialize 
>> method ( i.e. [viewController initialize]) in 
>> application:didFinishLaunchingWithOptions: method (prior to the view being 
>> added to the window and the window made visible).
> 
> 
> *** Important ***
> +(void)initialize is a class method which the runtime sends to the class 
> exactly once just before any of this class' method is invoked, and any of its 
> super class if +initialized has not yet been invoked.
> You rarely need to override +initialize -- and you never call it yourself!
> 
> 
> 
> But yes, there is a proper way to do initialization of a view controller 
> object :)  There are lots of examples of how you should do this within the 
> iOS or Mac OS X documentation.
> 
> Basically, when you load your view from a nib you will override these methods 
> in order to initialize a view controller:
> 
> -viewDidLoad
>   This method is called regardless of whether the views were stored in a 
> nib file or created 
>   programmatically. You usually override it to do additional setup after 
> the view has been 
>   loaded from a nib.
>   If you override -viewDidLoad you may want to override -viewDidUnload 
> accordingly, which is the  "counterpart" of -viewDidLoad.
> 
> 
> -awakeFormNib 
>   To do additional setup after the view has been loaded from a nib. You 
> often can do all your setup
>   in viewDidLoad, but sometimes this seems a better place. At the time 
> the method is invoked,
>   outlet and action connections are already established.
> 
> 
> In the cases where you want to create the controller's view yourself 
> programmatically, you have to use
> -loadView. If you do so, you need to create the view hierarchy and assign the 
> root view to the view property of the controller.
> 
> 
> You must not call any of these methods yourself! The framework will do this 
> for you when it is appropriate.
> 
> 
> An example might be useful:
> 
> The following code assumes you have a nib where you load the view:
> 
> @interface MyViewController : UIViewController {
>  IBOutlet UIView* mySpecialSubView;
>  NSArray* myArray;
> }
> 
> @property (retain) UIView* mySpecialSubView;
> @property (retain) NSArray* myArray;
> 
> @end
> 
> @implementation
> @synthesize mySpecialSubView;
> @synthesize myArray;
> 
> - (void) viewDidLoad
> {
>[super viewDidLoad];  // always invoke super!
> 
>// In debug mode, you might check here whether you have established the 
> links for your outlets in IB:
>NSAssert(mySpecialSubView, @"IBOutlet 'mySpecialSubView' is nil"); // 
> forgot to setup the link in IB?
> 
>// configure my view unless this is already done in IB:
>self.view.backgroundColor = [UIColor blackColor];
> 
>// do other setup, for instance setting up a navigation bar, navigation 
> item
>...
> 
>// if your view controller needs to initialize other ivars, you might 
> initialize them here, 
>// or do "lazy initialization" (see below)
>...
> 
>// Note, that viewDidLoad will be called *everytime* the view gets 
> reloaded from
>// the resource!
>// Sometimes, you explicitly DON'T want to perform certain initialization 
> steps again 
>// after the view will be reloaded. In this case, use a flag as an ivar 
> which determines 
>// whether you have done these initialization steps:
>if (!isInitialized) {
>   [self setupOnce];
>isInitialized = YES;  // this is an ivar
>} 
> }
> 
> 
> You have to override -viewDidUnload in certain cases, e.g.:
> 
> - (void) viewDidUnload {
>self.mySpecialSubView = nil;// Outlets shall be set to nil!
> 
>// optionally, you might want to release myArray - just in order to safe 
> memory. But
>// this depends on your needs, and often you explicitly don't want the 
> array to be
>// recreated after a reload of the view. 
>self.myArray = nil; // optionally
> }
> 
> 
> 
> // lazy initialization - this overrides the getter method which was otherwise 
> defined
> // by the @synthesize directive:
> - (NSArray*) myArray {
>if (myArray == nil) {
>myArray = [NSArray alloc] init... ];
>}
>return myArray;
> }
> 
> 
> // don't forget to release ivars if required:
> -(void) dealloc {
>[mySpecialSubView release], mySpecialSubView = nil;
>[myArray release], myArray = nil;
>[super dealloc];  // always invoke super (at the last statement)
> }
> 
> 
> 
> One thing you should care of:
> -viewDidLoad and -awakeFormNib, as well as -loadView

Re: Initializing a view controller...

2011-01-10 Thread Phil Hystad 
Fritz...

Thanks for the pointers to the documentation.  I was going to get to reading it 
if I struck out here.  I am really not lazy, just old.

phil

On Jan 10, 2011, at 8:42 AM, Fritz Anderson wrote:

> On 10 Jan 2011, at 9:17 AM, Phil Hystad wrote:
> 
>> Is there a proper way to initialize a view controller.  So far, I have been 
>> doing this in the application delegate by calling calling an initialize 
>> method ( i.e. [viewController initialize]) in 
>> application:didFinishLaunchingWithOptions: method (prior to the view being 
>> added to the window and the window made visible).
> 
> I first wrote a brief essay on what to do, where, depending on whether you 
> instantiate programmatically or in a NIB. But why not refer you to a better 
> explanation than I can piece together in five minutes?
> 
> View Controller Programming Guide for iOS.
> 
> 
> Particularly: Understanding the View Management Cycle
> 
> 
>   — F
> 

___

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

document architecture question

2011-01-10 Thread Shane 
Hi all,

I have an application that I initially built based on the document
architecture (sort of the default setup from XCode). And now that I
have my application working, when I open up several documents and run
operations from the main menu or the toolbar in say … the second
document, I find that only the first documents views are being
updated. My main app controller inherits from NSWindowController.

Anyone offer suggestions on how to fix this?
___

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: document architecture question

2011-01-10 Thread Jerry Krinock 
I don't think there is any common mistake in using the document architecture 
that would cause the weird problem you describe.  Therefore…

On 2011 Jan 10, at 19:01, Shane wrote:

> when I … run operations from the main menu or the toolbar

To debug complicated problems, it is usually best, if you can, to ignore the 
forest and focus on a tree; that is, focus yourself on *one* simple, 
reproducible test case.  If you find the beetle that is eating this one tree, 
the other trees probably have the same pest.

In this case, that means to forget about "operations" and pick *one* operation, 
preferably the simplest one, which is misbehaving.  Study what should happen, 
step by step, and debug to see what is actually happening.

If you can't find the problem after doing that, re-post here, explaining what 
you found in studying this *one* "operation".

___

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: NSUndoManager retain/release of arguments - ad infinitum

2011-01-10 Thread John Bartleson 
Thanks for your replies. I'm hoping that the conclusion will help  
others who are confused by the existing

documentation of MM in NSUndoManager. So here's what I'm doing:

My reference-counted, document-based app uses a table view. The table  
view supports sorting by clicking in
the header. The app supports undo. Undoing the sort is where things  
got complicated. Here's the code I call when
the tableView:sortDescriptorsDidChange: dataSource method determines  
that no old sortDescriptors exist for

the data array, meaning the array is initially unsorted:

//  Part 1 
- (void)sortUsingNewDescriptors:(NSArray *)theNewDescriptors
 tableView:(NSTableView  
*)theTableView

{
NSMutableArray *theArrayToSort = [/*index into database*/  
itemArray];
// Snapshot with a shallow copy so the user gets the original  
unsorted array on Undo
NSMutableArray *unsortedArray = [theArrayToSort  
mutableCopyWithZone:nil];
[[[self undoManager] prepareWithInvocationTarget:self]  
replaceArrayWithArray:unsortedArray


 andDescriptors:nil
   tableView:theTableView 
];

[theArrayToSort sortUsingDescriptors:theNewDescriptors];
[theTableView reloadData];
}

//  Part 2 
- (void)replaceArrayWithArray:(NSMutableArray *)newArray
  andDescriptors:(NSArray *)newDescriptors
tableView:(NSTableView  
*)theTableView

{
// Save pointer to current array
NSMutableArray *currentArray = [/*index into database*/ itemArray];
NSArray *currentDescriptors = [theTableView sortDescriptors];
[[[self undoManager] prepareWithInvocationTarget:self]  
replaceArrayWithArray:currentArray


 andDescriptors:currentDescriptors
   tableView:theTableView 
];

// Move pointer to new array into the data
[/*index into database*/ setItemArray:newArray]; // @property  
(readwrite, assign) NSMutableArray *itemArray;
signalDescriptorChange = NO; // Temporarily turn off  
tableView:sortDescriptorsDidChange: dataSource
[theTableView setSortDescriptors: newDescriptors]; //- method  
call so we don't get re-entered

signalDescriptorChange = YES;
[theTableView reloadData];
}

In Part 1, I make a shallow copy of the unsorted array for later  
possible use by Undo, then set up the Undo
with the prepareWithInvocationTarget: call, then finally sort the  
original array.


Part 2 will get called if Undo (or Redo) is selected by the user. I  
save pointers to the current data and its
descriptors, set up for a Redo using prepareWithInvocationTarget:,  
then replace the data array and its descriptors

with the ones in the previous prepareWithInvocationTarget: call.

The general effect of all this is that the unsorted and sorted data  
arrays are swapped as the user selects Undo and Redo.


Here's the problem: in Part 1, the mutableCopyWithZone: call allocates  
a new unsortedArray. In a reference-counted
environment, it (or the original theArrayToSort, depending on the  
user's selection of Undo/Redo) won't be released

as currently coded and there'll be an ugly memory leak.

Since I allocated unsortedArray it's my responsibility to release it.  
But if I release it after the prepareWithInvocationTarget:
call (in Part 1) it causes a crash on Redo. I also thought of doing a  
retain/release when swapping the arrays in Part 2, but
that can't be a complete solution because unsortedData will still  
never be released if the user never does Undo.


(As Aaron Hillegass says in his book, "Sometimes when I think about  
undo, my head starts to swim a bit." By the way, kudos to Aaron for
devoting a chapter to undo in his book. I can't find any other  
reference besides Apple's rather limited "Undo Architecture".)


As a possible solution, I can imagine writing a new class, let's call  
it 'UndoMemory', that maintains a pool of pointers that need
to be released when the document is deallocated. In Part 1 (above), I  
would call an UndoMemory method that adds
the unsortedArray pointer to the pool. In Part 2, I would call another  
UndoMemory method that removes newArray
from the pool and adds the currentArray pointer. At document  
deallocation time I would call a third method that releases

any pointers remaining in the pool.

UndoMemory would probably work but seems too complicated. I'd be  
writing a new layer of memory management, with potential gotchas.


Note that this isn't just a sort-specific problem. Any Undo of a  
memory-allocated vari

Re: document architecture question

2011-01-10 Thread Graham Cox 

On 11/01/2011, at 2:01 PM, Shane wrote:

> My main app controller inherits from NSWindowController


What does this mean? This sounds all sorts of wrong.

First off, most apps don't have an 'app controller', though they do very often 
have an app delegate. Typically that's just an object, not an 
NSWindowController.

If you have the standard document architecture, you should have a nib that 
represents a document, containing its window(s), their controllers and the 
NSDocument subclass that your document is based on. (In the default doc-based 
project, this is called 'MyDocument').

Menu commands should target nil, so that they find their way to the frontmost 
document. If you have connected them directly to some controller (perhaps this 
mysterious 'app controller'), then they will only operate on that object.

--Graham


___

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: NSUndoManager retain/release of arguments - ad infinitum

2011-01-10 Thread Graham Cox 
My first thought, before I go further, is that to undo a sort, you are doing 
things way too complicated. You only need to pass the sort descriptors to the 
undo manager, not a copy of the data. Presumably adding and removing items in 
the data itself is also undoable, so at any time the data on which undo will 
operate is consistent with the data you have - there is no reason to make a 
copy of it. That alone could significantly simplify your code, and simpler is 
less buggy.

(As an aside, the way I usually handle sorting is to have a property in my data 
model called -sortedData, which takes the raw data and applies the current sort 
descriptors to it. The resulting sorted array can be cached to avoid having to 
perform the sort repeatedly as long as the sort descriptors don't change. When 
they do change, I simply invalidate the cache (i.e. release it). The actual 
sort only takes place when a piece of sorted data is later requested, at which 
point the sorted data is cached again. The table view stores the sort 
descriptors for you, so you don't even need to store that as a property 
yourself. As suggested, to undo a sort, pass the old descriptors to the undo 
manager and when undo is invoked, it restores the old descriptors and once 
again invalidates the cache. This approach is super easy and efficient - you 
certainly don't need to pass the previously sorted copy of the data as an undo 
parameter).

On 11/01/2011, at 3:37 PM, John Bartleson wrote:

>[/*index into database*/ setItemArray:newArray]; // @property (readwrite, 
> assign) NSMutableArray *itemArray;


Specifying 'assign' here is probably wrong. It is not retaining the assigned 
array, so you are stating you don't own it. Yet I suspect that you do want to 
own it. You're relying on the undo manager retaining it because you have 
neglected to do so. That's probably why when you do the expected and correct 
release, it crashes, because once the undo manager performs the undo, it will 
release the invocation that is retaining the array, which will dealloc it. 
Since you're not retaining it, it crashes because you have a stale reference.

That is entirely your fault, not something peculiar to the undo manager.

I recommend not using synthesised properties until you get the hang of writing 
your own manual getters and setters, which help you to develop the 
understanding of how these things should be written. Having said that, changing 
this from assign to retain will probably fix your issue.

I wonder if you have repeated the same error for other object properties which 
are not being retained? That would explain why you are having to rely on undo 
manager retaining your objects for you.



One other thing with regard to MM and Undo. Recall that targets are not 
retained, so the undo manager correctly does not retain the target. Thus, as 
with all such code (e.g. the very similar NSNotificationCenter situation) when 
your target is deallocated, it should purge itself from the undo manager using 
-removeAllActionsWithTarget: failure to do that will also crash later when 
someone tries to perform an undo on a no longer existing target.

--Graham


___

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: NSUndoManager retain/release of arguments - ad infinitum

2011-01-10 Thread Jerry Krinock 

On 2011 Jan 10, at 21:39, Graham Cox wrote:

> As suggested, to undo a sort, pass the old descriptors to the undo manager 
> and when undo is invoked, it restores the old descriptors and once again 
> invalidates the cache.

But that assumes that the data was sorted with some old descriptors to begin 
with.  It seems like this would not work if the objects had been manually 
arranged into some arbitrary order by the user.

--

Aside: Reading this thread really makes one appreciate Core Data.

I've written a Core Data app which can Undo Sort.  The sortable objects are the 
'many' members of to-many relationships.  Each one has an 'index' parameter, 
which is re-set during sorting.  When you 'Undo Sort', all of the 'index' 
parameters get set back to their original values.  There is no code to 'Undo 
Sort' or 'Redo Sort'.  It really is "for free" (well, after you've tamed Core 
Data's Undo Groupings).

I should not discourage John from doing it the hard way first, though.  The 
usual warning against Cocoa beginners diving into Core Data applies :)

___

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: Custom path animation for CAShapeLayer

2011-01-10 Thread Kenneth Baxter 

Thanks for the feedback David. I'll try the keyframe approach.

On 11 Jan, 2011,at 09:24 AM, David Duncan  wrote:


The closest thing you could do here is use a Keyframe animation, but I'm not 
certain this could be done cleanly or without using lots of intermediate paths 
for even short sequences. It is something to explore.
--
David Duncan

___

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

Base SDK 10.6 deployment target 10.5 - symbol not found

2011-01-10 Thread Kenneth Baxter 

Hi, I have a project I'm working on which needs to run on 10.5 and 10.6. I have 
various things enabled or disabled using:

if (floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_5) ...

but I also have some places in my code where I want to use a CAShapeLayer 
subclass in 10.6 and an alternate version based on NSViews in 10.5. My logic 
says it is not going to call the CAShapeLayer, but it appears that it has been 
linked in to the application anyway, so when I try to run the program on 10.5, 
it gives me the error:

dyld: Symbol not found: _OBJC_CLASS_$_CAShapeLayer 

What is the proper way to handle situations where a whole class is missing in 
the earlier SDK like this? The documentation doesn't seem to address this 
scenario as far as I can see.

Thanks

Ken___

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