December 2009 - Cocoa-dev - lists.apple.com

Re: NSImage
by Quincey Morris 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rb2IoHW5oLlC4YD9iYFou/ZOzWz9tZAuv4U5Bohr40eKY4Lvt3uF3eRwSHgE+dzR; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; On Dec 31, 2009, at 15:21, David Blanton wrote: > Yeah, I was doing it with CGBitmapContextCreate followed by CGBitmapContextCreateImage but that ends up as a CGImageRef. > > I want NSImage so I can put an NSImageCell in an NSOutlineView and walk away ! I suggest you read the extensive comments on creating NSBitmapImageRep and NSImage objects in the Snow Leopard release notes, and choose a strategy accordingly (even if you're still on Leopard). The "best" technique for Snow Leopard isn't necessarily the "best" technique for Leopard, but you might want to plan ahead. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSImage
by David Blanton 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Happy New Year ! On Dec 31, 2009, at 3:54 PM, Henry McGilton (Boulevardier) wrote: On Dec 31, 2009, at 2:26 PM, David Blanton wrote: Cheers, . . . . . . . . Henry ================================================= iPhone App Development and Developer Education . . . Visit www.nonatomic-retain.com Mac OSX Application Development, Plus a Great Deal More . . . Visit www.trilithon.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… Yeah, I was doing it with CGBitmapContextCreate followed by CGBitmapContextCreateImage but that ends up as a CGImageRef. I want NSImage so I can put an NSImageCell in an NSOutlineView and walk away ! I have 15 year old scotch to crack with a 28 year Apple Employee this evening ! Given an array of color data (a generic bitmap) what is the best / fastest / recommended method to convert this to an NSImage? Load your data into memory, create an NSBitmapImageRep from that pile of data, then make an NSImage from the NSBitmapImageRep . . . This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSImage
by Henry McGilton (Boulevardier) 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com On Dec 31, 2009, at 2:26 PM, David Blanton wrote: > Given an array of color data (a generic bitmap) what is the best / fastest / recommended method to convert this to an NSImage? Load your data into memory, create an NSBitmapImageRep from that pile of data, then make an NSImage from the NSBitmapImageRep . . . Cheers, . . . . . . . . Henry ================================================= iPhone App Development and Developer Education . . . Visit www.nonatomic-retain.com Mac OSX Application Development, Plus a Great Deal More . . . Visit www.trilithon.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

NSImage
by David Blanton 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… Given an array of color data (a generic bitmap) what is the best / fastest / recommended method to convert this to an NSImage? This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash
by Quincey Morris 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MAjpviAYkeBCiDksicJrK+TmhRsNk6evDFnNJF+PvGXlCIa1waZzmZXPYE9KAJen; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; On Dec 31, 2009, at 10:36, Oftenwrong Soong wrote: > If it is true that the ONLY safe thing you can do in dealloc is release instance variables, then where else/how else are you supposed to implement a method that is guaranteed to be called upon an object's termination, so that you can do final cleanups, such as removing it as an observer or closing external resources such as files or network connections? Jerry isn't the only one who needs to do such cleanups, nor am I. It isn't *literally* true, but it's usually true that 'dealloc', in cleaning up the object's state, puts the object into an inconsistent state, so calling any method of the object (directly or indirectly) may be problematic. If you're sure the state isn't inconsistent, or if you're sure the inconsistency isn't harmful, then you can call other methods. But ... For releasing external resources, you should *probably* start using a different strategy, instead of relying on 'dealloc'. That's because if you ever switch to garbage collection, there's no 'dealloc' at all, and the equivalent ('finalize') isn't a suitable place to release resources that must be reclaimed as soon as possible. (Unlike 'dealloc', 'finalize' doesn't happen immediately after the last reference goes away, and you've no guarantee exactly how long you'll have to wait for it to be called.) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash
by Quincey Morris 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jSqpkVf7tQeKSHoj8cHH2g+p/cS24i49Hg9axGNu63RVO6IM82q5m97BM40/NJ1Y; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; On Dec 31, 2009, at 09:36, Jerry Krinock wrote: > So, to solve this problem, I implemented a lockout kludge, an ivar mIsCleaningStacks, in the undo manager. Its -removeAllActions locks it out while it is removing objects from its undo and redo stacks, and if removeAllActionsWithTarget: sees this it doesn't touch them. I believe this is otherwise harmless, since these stacks are in the process of having all their objects removed anyhow. > > Is this a good case study in why "the only safe thing to do in your dealloc method is to release instance variables", or have I misunderstood the problem? > > Does a better workaround pop into anyone's mind? The crash does not occur when using Apple's NSUndoManager, which I presume must also have some workaround built into it. Well, yes, this is the sort of thing that makes dealloc treacherous. In fact, there might be an argument that there's a glaring bug in GCUndoManager. It *appears* to be assuming that CFArrayRemoveAllValues is an "atomic" operation (with regard to undo actions) but your stack trace shows clearly that it's not. Similarly, copying the array in 'removeAllActionsWithTarget:' (presumably to make iteration over a mutating collection "safe") also seems flawed -- it looks like you could end up with multiple copies of the array in different states, with consequent hilarity. [However, at the source code level it might be provable that this is not an actual problem.] You might be able to avoid the instance variable hack by making 'removeAllActions' etc atomic wrt the undo manager. Specifically, construct a new state (of having no actions) in local variables, then swap the new state into the normal instance variables, then clean up the old state (now in local variables). Or something like that. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash
by Oftenwrong Soong 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1262284569; bh=Vcgo9Q3Xb42CXXp7/KrHuPNbtBk2Xl9yr41+6WfXom8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZZBOiU5UWVKcOFlYGbw9SbxMfX+yvq1ixYn0EHI+JvYce/Gyw0d4GvOS1oUIMXQtHX+Y/YeMRGhqYKiqiiZYC29queLVoQH+LJ+wAgcR7mC8POojSTiU1/1YA+aRRxJYMiqI8RKXYwrSinBxh4l+VvPuSp7cS7wI8KvP1/AJqRI= Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QKGiHRQwBHS6R52JLnAn+UQORwNuJQQKymI/u1rzbtelCRue7GusXWvuRlGjyahBAaC2amQxtv1v3piSz6FIiomv6XvrFgxZDfAsNX4N0wJvYdTNjsB4PtAZG9pXIfJgjlBBCzIpwqgaj1g/H35tYUMmBsYd+R4Npwpp+DPC5SQ=; Hi all, If it is true that the ONLY safe thing you can do in dealloc is release instance variables, then where else/how else are you supposed to implement a method that is guaranteed to be called upon an object's termination, so that you can do final cleanups, such as removing it as an observer or closing external resources such as files or network connections? Jerry isn't the only one who needs to do such cleanups, nor am I. Thanks, Soong ----- Original Message ---- From: Jerry Krinock <jerry(a)ieee.org> To: Cocoa Developers <cocoa-dev(a)lists.apple.com> Sent: Thu, December 31, 2009 9:36:47 AM Subject: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash <snip> Is this a good case study in why "the only safe thing to do in your dealloc method is to release instance variables", or have I misunderstood the problem? <snip> _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Setting the Line Height/ Line Spacing in an NSTextView.
by Andy Lee 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com On Dec 31, 2009, at 1:14 PM, Joshua Garnham wrote: > So would this work?… > > CGFloat spacing = 5.0f; > NSMutablePargagraphStyle *paragraphStyle; > [paragraphStyle setLineSpacing:spacing]; > [paragraphStyle setMinimumLineHeight:spacing]; > [paragraphStyle setMaximumLineHeight:spacing]; > [textView setDefaultParagraphStyle:paragraphStyle]; Why don't you tell us? --Andy _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Fw: Setting the Line Height/ Line Spacing in an NSTextView.
by Joshua Garnham 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1262283282; bh=lJ4PvHwsbaybGWPFAfvfH0k7i1EQ4f8RZjnwE85TcG0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=skbaXc3sdTRGOyaUkoTDW0wor3XZk7bhO/I4WrES2U9guERUrO1BVa0G+Ihz7lZwQvF5rwC8c16vTnXyv4ZPKMndV3LGq0D/IRoaWHVdTtWKBqmsiwSrCTb3Gk4yLg8O1IljrqOWtleeUHRl6yKMMpPh+tqDYSnYV6CfZlT8sTc= Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SdB+dRa8nFN0VMFrAfu3GpRPUItUVMFJocsB8btpRiWB739+wksiwk4aNv4Fw1mU5CPDkrnrBTx+KpU+mkFDtLaLEGhj9v8MhYDNI3kA4prajD7wP3YOYFB/SiGYUE0Zla/60oGtLOMjJ2DyGNoAUQNdXf9VTLUsenTcDhrDNiw=; Thanks, there is no immediate need to override so I will try calling it. So would this work?… CGFloat spacing = 5.0f; NSMutablePargagraphStyle *paragraphStyle; [paragraphStyle setLineSpacing:spacing]; [paragraphStyle setMinimumLineHeight:spacing]; [paragraphStyle setMaximumLineHeight:spacing]; [textView setDefaultParagraphStyle:paragraphStyle]; - Josh ________________________________ From: Fritz Anderson <fritza(a)manoverboard.org> To: Joshua Garnham <joshua.garnham(a)yahoo.co.uk> Cc: cocoa-dev List <cocoa-dev(a)lists.apple.com> Sent: Wed, 30 December, 2009 17:24:21 Subject: Re: Setting the Line Height/ Line Spacing in an NSTextView. On 30 Dec 2009, at 11:01 AM, Joshua Garnham wrote: > But the methodssetLineSpacing: and others are NSMutableParagraphStyle methods only. That's the point. You may _want_ to change the paragraph style's properties, but you can't. Casting the parameter doesn't turn an immutable object into a mutable one. If you really want to substitute a paragraph style of your own (and please comment on the suggestions that you may not want to), make a mutableCopy, set that up as you wish, and pass it up to super. You may be misconceiving the need to subclass in Cocoa. Subclassing is rare. Most modifications to object behaviors are done through delegates and property setters; Cocoa provides a lot of them. That's why you're getting told to _call_ setDefaultParagraphStyle:, not _override_ it. If you explained why you feel you must override, we might be better able to help you. — F _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash
by Paul Sanders 31 Dec '09

31 Dec '09

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com I can't comment on the specifics of this because I am not knowledgable in that area, but the fact the undo manager is getting it's knickers in a twist is surely unrelated to the fact _releaseUndoManager was called from [NSDocument dealloc]. I do all sorts of things in dealloc methods. I just try not to write buggy code! I have found that there is a more subtle problem that can arise though. You're never quite sure when a dealloc method might be called, especially with the way autorelease pools work, and that occasionally means that resources you would like to release *right now* hang around longer than you would like them to. I therefore sometimes have a destroy method that I can call any time I like. This releases (in the most general sense) anything the object owns that are regarded as critical and leaves the object in, effectively, a dormant state. Then, when dealloc is finally called, the object quietly goes away. I don't have to do this very often. Just for the occasional special case. Of course, there's nothing to stop you temporarily retaining an object in a dealloc method if you need it to stay around while you do whatever cleanup you need to do. Just releae it at the end of the method. Paul Sanders. ----- Original Message ----- From: "Jerry Krinock" <jerry(a)ieee.org> To: "Cocoa Developers" <cocoa-dev(a)lists.apple.com> Sent: Thursday, December 31, 2009 5:36 PM Subject: NSDocument, NSManagedObjectContext do Stuff in -dealloc, Cause Crash I remember reading that the only safe thing to do in your dealloc method is to release instance variables. If you look at lines #23 - #25 in the call stack below, it appears that NSDocument's -dealloc is doing more, sending -removeAllActions to its undo manager. Similarly, lines #7 and #8 say that NSManagedObjectContext's -dealloc is removing tasks which target itself from its undo manager. Now I must admit that I have often found it difficult to find a place other than -dealloc to remove observations and dependencies like this, and have gotten away with it on occasion. In this case, however, it seems to result in a crash upon closing a Core Data document with unsaved changes (whether saving or not), when using a custom undo manager. Here is how I see the steps in the crash: * During its -dealloc, NSDocument sends itself _releaseUndoManager, which sends -removeAllActions to the document's undo manager. * The undo manager sends -removeAllObjects to its undo stack. * The first group in the undo stack is deallocced. * The NSInvocation owned by the group is deallocced. * Now, here's where things start getting hairy. The NSInvocation has retained the NSManagedObjectContext because it is its target. And, as things happen, this is apparently the last retain on the NSManagedObjectContext, because at this point, it deallocs. * Within -dealloc, the managed object context sends several messages, finally resulting in -removeAllActionsWithTarget: being sent to the undo manager. * So that it can iterate through the stacks, the undo manager's -removeAllActionsWithTarget: starts out by attempting to make a copy of the undoStack, which is still in the process of having all of its objects removed. Crash. So, to solve this problem, I implemented a lockout kludge, an ivar mIsCleaningStacks, in the undo manager. Its -removeAllActions locks it out while it is removing objects from its undo and redo stacks, and if removeAllActionsWithTarget: sees this it doesn't touch them. I believe this is otherwise harmless, since these stacks are in the process of having all their objects removed anyhow. Is this a good case study in why "the only safe thing to do in your dealloc method is to release instance variables", or have I misunderstood the problem? Does a better workaround pop into anyone's mind? The crash does not occur when using Apple's NSUndoManager, which I presume must also have some workaround built into it. Thanks, Jerry Krinock #0 0x015f96ce in __CFTypeCollectionRetain #1 0x016490b0 in CFArrayCreateCopy #2 0x0028ee31 in -[NSCFArray copyWithZone:] #3 0x016587ea in -[NSObject(NSObject) copy] #4 0x0012f318 in -[GCUndoGroup removeTasksWithTarget:] at GCUndoManager.m:1107 #5 0x0012d89d in -[GCUndoManager removeAllActionsWithTarget:] at GCUndoManager.m:477 #6 0x01b4b3f1 in -[NSManagedObjectContext(_NSInternalNotificationHandling) _stopObservingUndoManagerNotifications] #7 0x01b7c78e in -[NSManagedObjectContext(_NSInternalNotificationHandling) _unregisterForNotifications] #8 0x01b7c5c1 in -[NSManagedObjectContext dealloc] #9 0x01b695ca in -[NSManagedObjectContext release] #10 0x015ff528 in CFRelease #11 0x016298b2 in __CFArrayReleaseValues #12 0x015ff6f1 in _CFRelease #13 0x0166d19a in -[NSInvocation dealloc] #14 0x0012f9cf in -[GCConcreteUndoTask dealloc] at GCUndoManager.m:1289 #15 0x015ff528 in CFRelease #16 0x016298b2 in __CFArrayReleaseValues #17 0x015ff6f1 in _CFRelease #18 0x0012f614 in -[GCUndoGroup dealloc] at GCUndoManager.m:1183 #19 0x015ff528 in CFRelease #20 0x016298b2 in __CFArrayReleaseValues #21 0x0165644e in CFArrayRemoveAllValues #22 0x0012d7e0 in -[GCUndoManager removeAllActions] at GCUndoManager.m:455 #23 0x00127c52 in -[SSYDooDooUndoManager removeAllActions] at SSYDooDooUndoManager.m:101 #24 0x009a63eb in -[NSDocument _releaseUndoManager] #25 0x009a6898 in -[NSDocument dealloc] #26 0x00b05b8c in -[NSPersistentDocument dealloc] #27 0x00115705 in -[Bkmslf dealloc] at Bkmslf.m:2024 #28 0x015ff528 in CFRelease #29 0x0162c0ed in _CFAutoreleasePoolPop #30 0x00288dd6 in NSPopAutoreleasePool #31 0x00288cfe in -[NSAutoreleasePool drain] #32 0x0060e55f in -[NSApplication run] #33 0x00606535 in NSApplicationMain #34 0x00001e67 in main at MainApp-Main.m:19 _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)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/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0