Re: XCode snapshot function?
> On May 9, 2016, at 6:48 PM, Graham Cox wrote: > > So what’s the best way to mothball and archive my project in its current > state so I can then fork it for the next version, and so on? Git. The Snapshot feature was basically made redundant once Xcode added support for Git, so it makes sense that they removed it. (That said, Xcode’s Git support isn’t the greatest. I strongly recommend getting the free SourceTree app.) —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: XCode snapshot function?
D > On 2016 May 09, at 18:48, Graham Cox wrote: > > So what’s the best way to mothball and archive my project in its current > state so I can then fork it for the next version, and so on? Either make a git branch, or if you don’t trust git, copy project folder(s). Projects that involve multiple project folders or git repos are always going to be problematic. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: XCode snapshot function?
> On 2016 May 09, at 18:48, Graham Cox wrote: > > So what’s the best way to mothball and archive my project in its current > state so I can then fork it for the next version, and so on? Either make a git branch, or if you don’t trust git, copy project folder(s). Projects that involve multiple project folders or git repos are always going to be problematic. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: XCode snapshot function?
> On 10 May 2016, at 09:48, Graham Cox wrote: > > > > oookaaayyy… > > So what’s the best way to mothball and archive my project in its current > state so I can then fork it for the next version, and so on? > > —Graham > > archive the project in xcode (Product .. Archive), add the archive to your repository, git commit and tag the lot and push it somewhere remote so when your mac goes on fire you have a copy. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: XCode snapshot function?
> On 10 May 2016, at 11:28 AM, Roland King wrote: > > >> On 10 May 2016, at 09:21, Graham Cox wrote: >> >> Hi, >> >> Where is the snapshot function in XCode these days (XCode 7.3)? >> >> I see in the “Projects” window there is a way to export snapshots, but I >> can’t see anywhere to make a snapshot in the first place. >> >> —Graham >> > > It isn’t - it was removed with Xcode 7 and never came back. You can restore > old snapshots from Xcode 6 and prior but not make new ones. oookaaayyy… So what’s the best way to mothball and archive my project in its current state so I can then fork it for the next version, and so on? —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: XCode snapshot function?
> On 10 May 2016, at 09:21, Graham Cox wrote: > > Hi, > > Where is the snapshot function in XCode these days (XCode 7.3)? > > I see in the “Projects” window there is a way to export snapshots, but I > can’t see anywhere to make a snapshot in the first place. > > —Graham > It isn’t - it was removed with Xcode 7 and never came back. You can restore old snapshots from Xcode 6 and prior but not make new ones. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: XCode snapshot function?
On 10 May 2016, at 11:21 AM, Graham Cox wrote: > > Where is the snapshot function in XCode these days (XCode 7.3)? Disappeared a few versions back, I believe. -- Shane Stanley ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
XCode snapshot function?
Hi, Where is the snapshot function in XCode these days (XCode 7.3)? I see in the “Projects” window there is a way to export snapshots, but I can’t see anywhere to make a snapshot in the first place. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Receiver type for instance message is a forward declaration
On May 9, 2016, at 11:26 , Carl Hoefs wrote: > > Alas, there appear to be no GCD dispatch queue introspection functions, > specifically to find out what is executing (if anything) and what's waiting > in the queue. Or did I overlook something? Also, no, I don’t think so. There is dispatch_get/set_context, but the documentation is unclear as to whether these work on queued blocks. Cancelling GCD operations is also a bit more primitive than you would like. The other thing that NSOperationQueue can do that I don’t think GCD can do is limit the “width” of a concurrent queue (AFAIK). If you need to manipulate the queue operations themselves, this does seem like something of a code smell in regard to GCD. In that case, NSOperationQueue is probably a better choice. Perhaps it’s worth going back to that, in the hope that your crashes get more frequent, and you can investigate what really causes them. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
RE: NSTableView is messaging zombie delegate
On May 8, 2016, at 13:19, Quincey Morris wrote: If you look at your backtrace again, you’ll see that it crashed doing something with rows. It’s as likely trying to message your data source as your delegate. You should nil that as well. Note that it’s not necessarily that any particular object has or hasn't been deallocated, but there’s a whole network of objects that may have now-invalid references somewhere. (In this case, it looks like the reference to a table cell view that’s crashing.) Also consider delegate (and similar) references to view controllers and window controllers. IIRC, the window itself may not be deallocated immediately after being closed, because it’s kept alive until the window server (a difference process) gets around to cleaning up after it, and so it might take a few iterations of your run loop before the window object goes away. That in turn might keep alive other controller/delegate objects that your app has otherwise finished with. The trick to solving this is to find just the right weak reference to nil. Spot on. The NSViewController is both the delegate and the dataSource of the table view, and nil-ing both of them (rather than just the delegate) in -windowWillClose: seems to have done the trick. Good to know we need to keep an eye out for non-zeroing delegate references in other areas as well -- we just assumed they had all been converted to zeroing references post-ARC, but it appears the old saying about assumptions continues to hold... Thanks for the help! Matt ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Receiver type for instance message is a forward declaration
> On May 6, 2016, at 3:45 PM, Carl Hoefs wrote: > >> These days, if I had any doubts about NSOperationQueue, I’d switch to using >> GCD directly. There’s very little that NSOperationQueue does that GCD doesn’t Alas, there appear to be no GCD dispatch queue introspection functions, specifically to find out what is executing (if anything) and what's waiting in the queue. Or did I overlook something? -Carl ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: discontiguous bounds ?
> On May 8, 2016, at 10:32 PM, Miller Dale wrote: > > I wish to provide a facility with a NSTableView wherein the leftmost > (specifiable) columns remain statically on the left of the display (subject > to vertical scrolling) while the remaining columns scroll normally > constrained to the right of the static columns. You’re going to need additional views to do this. For example, NSTableView already displays the table headers using a separate view that floats on top of the enclosing NSScrollView and doesn’t scroll along with it. I agree with Quincey that something like Apple’s SynchroScroll example is the way to go. Even if the example itself is out of date, the functionality works; for example, Xcode’s diff view and the FileMerge app both have text views that scroll in sync with one scroller. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: discontiguous bounds ?
> On 9 May 2016, at 08:59, Graham Cox wrote: > > I’ve done this, based on that code. Yes, it was a bit buggy, but I got it to > work. The app it’s a part of still works when compiled with the latest tools > and SDK. But yes, you need two separate table views to do this. > I have done something similar - using a separate table view to create a non scrolling total row at the bottom of a table view. NSStackView makes a suitable container for sticking this sort of thing together. In this case I can bind the table column widths together. I load the table view form a nib but put the view hierarchy together in code. In particular I clone the initial NSTableView using NSKeyedArchiver/NSKeyedUnarchiver so that I don’t have to try and maintain two duplicate NSTableViews in the nib. J ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to keep things alive in Arc?
This was recommended to me by folks "in the know": Thing *aThing = [ Thing new ]; ... (void)aThing; Gerd > On May 8, 2016, at 21:11, Gerriet M. Denkmann wrote: > > Thing *aThing = [ Thing new ]; > > void *thingData = [ aThing data ];// pointer to a buffer owned by > aThing > > … never use aThing after this point → Arc might release aThing right now > … but do lots of things with thingData > > … no more need for thingData > [ aThing release]; > > How to prevent Arc to release aThing before I have done with thingData? > > Gerriet. > > > > > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/gerti-cocoadev%40bitart.com > > This email sent to gerti-cocoa...@bitart.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView is messaging zombie delegate
On Fri, 6 May 2016 13:28:10 -0700, Jens Alfke said: >> On May 6, 2016, at 1:03 PM, Matthew LeRoy wrote: >> >> My understanding is that NSTableView's delegate is a zeroing weak reference > >Are you sure? Historically it’s been unsafe_unretained — in the old days >before weak references or ARC, the view never retained nor released the >delegate. The type of crash you’re having was a not-uncommon bug. > >Apple may have upgraded the property to a proper zeroing weak reference, >but I can’t tell from the docs. I was going to say "no", because my bug's still open, but in fact I never filed one. :( The following are still "open" (including their duped-to originals) though: 24046976 / 21380125 NSSplitView's delegate should be weak not assign 21366070 / 18987740 NSAnimation delegate should be 'weak' not 'assign' 17553217 NSSpeechRecognizer delegate should be 'weak' not 'assign' 17540574 NSToolbar's delegate should be 'weak' not 'assign' 17540533 NSWindow's delegate should be 'weak' not 'assign' 15301393 / 10520557 Support zeroing weak references (under ARC) with NSTextView As for NSMenu, it came back: "Although the delegate is declared “assign” in NSMenu.h, it’s actually been weak (for weak-compatible objects) since 10.9." When switching from GC to ARC, all this was a PITA. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to keep things alive in Arc?
> On 9 May 2016, at 19:17, Dave wrote: > > Hi, > > Well if “thing” is used only within the method you don’t have to do anything > - ARC will keep it alive until the local you have assigned it to goes out of > scope. No that’s not true, which is the whole point of the original question. ARC *may* keep it alive until the local goes out of scope, but it is also free to determine when the variable is last used and free at at any point after that, it doesn’t have to wait until the end of the scope. And in release mode, it fairly often doesn’t. Which is why you do have to do something. And the two options are the ‘precise lifetime’ which tells ARC explicitly to keep the variable alive through the entire scope whether it thinks it’s used or not, or the ‘returns inner pointer’ which tells ARC that the result of an earlier call returns something which requires the original receiver object to stay alive whilst it’s being used. In that case ARC is free to remove both objects after it determines the inner pointer one is no-longer used (which again may be before either of them go out of scope). The usual example of the latter is [ NSData bytes ], you need the NSData object to stay alive whilst its bytes are being used, so [ NSData bytes ] is annotated to return an inner pointer. This is all covered in the clang discussion/documentation which highlights the rationale for allowing objects to be destroyed when it determines they are no-longer used, but before the end of the scope, and the keywords which suppress that behaviour in cases like 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to keep things alive in Arc?
Hi, Well if “thing” is used only within the method you don’t have to do anything - ARC will keep it alive until the local you have assigned it to goes out of scope. If you want to use use it beyond the scope of the local method/object but not return it from the method, then assign it to a “strong” property, which keeps it alive until the object that owns the property is dealloc’ed. ARC will automatically take care of the case where that returns an object too, but of course the same rules apply for the local scope of the method that calls the method that returns the object. Hope this helps. Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: discontiguous bounds ?
> I wish to provide a facility with a NSTableView wherein the leftmost > (specifiable) columns remain statically on the left of the display > (subject to vertical scrolling) while the remaining columns scroll > normally constrained to the right of the static columns. I've done > this successfully (and easily) on mainframe (ISPF) applications, but > I'm not able to come up with a Cocoa implementation short of using two > separate NSTableView's with attendant bag-of-worms complexity. > If I were wishing, I could wish for the ability to specify multiple > discontiguous areas for the bounds of a view. So just to clarify, you're looking for the typical spreadsheet option (such as Numbers offers) to specify an arbitrary number of header columns? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: discontiguous bounds ?
> On 9 May 2016, at 3:50 PM, Quincey Morris > wrote: > > AFAIK there’s nothing in Cocoa that will implement this for you. I’m not sure > that using two table views is really very complex — they could potentially > use the same data source and delegate — but the trick is to get the vertical > scrolling in sync. I believe this is doable, though awkward. There’s even > documentation: > > > https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NSScrollViewGuide/Articles/SynchroScroll.html > > but I warn you that this document was last updated in 2010, and the last time > I tried to make sense of it I was pretty sure its sample code was confused > and buggy. I’ve done this, based on that code. Yes, it was a bit buggy, but I got it to work. The app it’s a part of still works when compiled with the latest tools and SDK. But yes, you need two separate table views to do this. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
