Re: Release mode bindings crash and release pools

> On Jun 17, 2017, at 3:11 PM, Jonathan Mitchell wrote: > >> On 17 Jun 2017, at 16:36, Charles Srstka > > wrote: >> >>> On Jun 17, 2017, at 8:36 AM, Jonathan Mitchell >> > wrote: >> >> >> Just tested it on 10.9; it works :-) >> >>

Re: Release mode bindings crash and release pools

> On 17 Jun 2017, at 16:36, Charles Srstka wrote: > >> On Jun 17, 2017, at 8:36 AM, Jonathan Mitchell > > wrote: > > > Just tested it on 10.9; it works :-) > > import Foundation > > class C: NSObject { > @objc dynamic var foo = "Foo" > } > > let c = C() > >

Re: Release mode bindings crash and release pools

> On Jun 17, 2017, at 8:36 AM, Jonathan Mitchell wrote: > >> On 17 Jun 2017, at 14:21, Charles Srstka > > wrote: >> >>> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell >> >>

Re: Release mode bindings crash and release pools

> On 17 Jun 2017, at 14:21, Charles Srstka wrote: > >> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell > > wrote: >> >>> On 16 Jun 2017, at 23:18, Quincey Morris >>> >> > wrote: >>> >>> On Jun 16, 2017, at 14:41 , Jonatha

Re: Release mode bindings crash and release pools

> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell wrote: > >> On 16 Jun 2017, at 23:18, Quincey Morris >> > > wrote: >> >> On Jun 16, 2017, at 14:41 , Jonathan Mitchell > > wrote: >>> >>> I sometimes use the default NSObje

Re: Release mode bindings crash and release pools

> On 17 Jun 2017, at 01:54, Charles Srstka wrote: > >> it’s preferred that bindings go either through an NSObjectController, an >> NSViewController, or something else that implements NSEditorRegistration. I think that is a crucial aspect in all this. I while back I configured bindings in cont

Re: Release mode bindings crash and release pools

> On 16 Jun 2017, at 23:18, Quincey Morris > wrote: > > On Jun 16, 2017, at 14:41 , Jonathan Mitchell wrote: >> >> I sometimes use the default NSObject bind: to set up a simple one way >> operation as you describe as opposed to a discrete observation. > > With macOS 10.13, the new block/clo

Re: Release mode bindings crash and release pools

> On Jun 16, 2017, at 4:32 PM, Quincey Morris > wrote: > > On Jun 16, 2017, at 13:48 , Charles Srstka > wrote: >> >> This is incorrect. > > It’s incorrect as a 2-way binding, but it works as a pair of so-called 1-way > bindings, with the proviso that they may

Re: Release mode bindings crash and release pools

On Jun 16, 2017, at 14:41 , Jonathan Mitchell wrote: > > I sometimes use the default NSObject bind: to set up a simple one way > operation as you describe as opposed to a discrete observation. With macOS 10.13, the new block/closure-based KVO “addObserver” method is probably an easier way, alt

Re: Release mode bindings crash and release pools

> On 16 Jun 2017, at 22:32, Quincey Morris > wrote: > > On Jun 16, 2017, at 13:48 , Charles Srstka wrote: >> >> This is incorrect. > > It’s incorrect as a 2-way binding, but it works as a pair of so-called 1-way > bindings, with the proviso that they may need to be unbound manually, to > p

Re: Release mode bindings crash and release pools

On Jun 16, 2017, at 13:48 , Charles Srstka wrote: > > This is incorrect. It’s incorrect as a 2-way binding, but it works as a pair of so-called 1-way bindings, with the proviso that they may need to be unbound manually, to prevent reference cycles, which it sounds like is what Jerry is doing.

Re: Release mode bindings crash and release pools

> On Jun 16, 2017, at 3:48 PM, Charles Srstka wrote: > >> On Jun 16, 2017, at 3:27 PM, Jerome Krinock wrote: >> >>> On 2017 Jun 16, at 10:35, Quincey Morris >>> >> > wrote: >>> >>> it takes additional custom code (like in the joystick example) to im

Re: Release mode bindings crash and release pools

> On Jun 16, 2017, at 3:27 PM, Jerome Krinock wrote: > >> On 2017 Jun 16, at 10:35, Quincey Morris >> > > wrote: >> >> it takes additional custom code (like in the joystick example) to implement >> the other direction. At least, that’s what I’ve been

Re: Release mode bindings crash and release pools

> On 2017 Jun 16, at 10:35, Quincey Morris > wrote: > > it takes additional custom code (like in the joystick example) to implement > the other direction. At least, that’s what I’ve been saying for years, though > I don’t think I’ve ever found a developer who believes me. I believe you. I t

Re: Release mode bindings crash and release pools

On Jun 16, 2017, at 08:15 , Jerome Krinock wrote: > > Typically the only reason you would explicitly unbind an object is if you > modify the user interface programatically and want to remove a binding. If > you change an objects binding’s values it should first clear any preexisting > values.

Re: Release mode bindings crash and release pools

Quincey is correct that closing of windows in macOS is a complicated, tricky process which may have edge case bugs. Also, although you mentioned invoking -bind: (also known as “manual” binding), you have not mentioned -unbind:. In complicated window controllers, I implement a -tearDownOnce meth

Re: Release mode bindings crash and release pools

On Jun 15, 2017, at 12:55 , Jonathan Mitchell wrote: > > The NSViewController is calling its internal implementation that removes > itself from the responder chain - _removeFromResponderChain > This method calls [NSWindow nextResponder] and the crash occurs there as the > NSWindow is a zombie.

Re: Release mode bindings crash and release pools

> On 15 Jun 2017, at 20:03, Quincey Morris > wrote: > > On Jun 15, 2017, at 04:46 , Jonathan Mitchell wrote: >> >> The crash occurs when the pool gets drained. > >> Wrapping my -bind: calls in a release pool solves the issue too. > > The information you’ve provided doesn’t make a lot of sen

Re: Release mode bindings crash and release pools

On Jun 15, 2017, at 04:46 , Jonathan Mitchell wrote: > > The crash occurs when the pool gets drained. > Wrapping my -bind: calls in a release pool solves the issue too. The information you’ve provided doesn’t make a lot of sense by itself. If draining an autorelease pool is leading to a crash

Release mode bindings crash and release pools

My macOS 10.12 ARC app has a gazillion bindings. Many are made in the NIBS but a lot are dynamically applied in code. In release mode I see the odd crash that can be traced back to NSAutoUnbinder getting dealloc'd in a release pool. With build optimisations set to 0 there is no issue. With build