Re: Identifying a specific Mac model

I just tried it on the golden MacBook (in IB) and I got a golden icon. > On 15 Sep 2015, at 15:59, John Daniel wrote: > > Thanks! That did the trick. It took a couple of tries to get it working. I > forgot that the namedImage method returns a scaled down image.

Re: Identifying a specific Mac model

Many thanks. What I have discovered is that they track model version as well: Exported UTI com.apple.macbook-retina-silver com.apple.device-model-code MacBook8,1@ECOLOR=225,225,223 com.apple.macbook-retina-gold com.apple.device-model-code MacBook8,1@ECOLOR=235,215,191

RE: NSSplitViewController : not in Interface Builder library?

What OS are you running Xcode in? I had some interesting fun when NSVisualEffectView showed up in Xcode 6.1 on 10.10 and built just fine with ibtool (we do it with scons) but didn't exist with the same Xcode and ibtool on 10.9. So I made it an NSView and set custom class NSVisualEffectView -

Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

Dear All, I have an app that uses Cocoa and dispatch sources leaking a lot (ca. 5GB / 17h). The origin seems to come from a combination of dispatch sources, Bindings & Core Animation. Below is a brief description of the app, what issues I encounter and the related code. DESCRIPTION OF THE

Re: NSSplitViewController : not in Interface Builder library?

Thank y’all for the replies. The omission is in both Xcode 6.4 and 7.1. The answer is: > On 2015 Sep 15, at 23:26, dangerwillrobinsondan...@gmail.com wrote: > > those are only available in storyboards in IB. I got the opposite impression from here: http://asciiwwdc.com/2014/sessions/411

Re: NSSplitViewController : not in Interface Builder library?

I recently spent two weeks trying to get NSSplitViewController to work programmatically in an application with nibs, without success. I got close, and I concluded that it probably can be done, but I gave up because it was taking too much time. I'm also having a lot of trouble getting it to work

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

On Sep 16, 2015, at 04:00 , Jean Suisse wrote: > > Does anyone know what to try / measure / observe to get more clues? It seems you’re “losing” free memory fast enough for this to be visible using heap generations in Instruments’ Allocations. The difficulty with marking

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 4:00 AM, Jean Suisse wrote: > > Additionally, I was unable to find any leaks with Instruments (but I barely > know how to use it) Probably the next step would be to learn more about Instruments. > and the amount of memory reported by Instruments is

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

Hi Jean, A wild guess that might or might not have any relevance to your problem: I see that you are wrapping your blocks with an autorelease pool, and that reminded me of a problem I dealt with a while back. As I understand it (and as discussed on this list some while back I think) pools

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

Hi Jonny, I also have a feeling the issue lies somewhere between the dispatch mechanism and Core Animation. I have seen some funny things too. For instance, I can’t run a serial queue for months. Some objects escape the autorelease pool created in the block (and seemingly encompassing

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

On Sep 16, 2015, at 12:56 PM, Charles Srstka wrote: > - (void)setFoo:(MyObject *)foo { > dispatch_async(dispatch_get_main_queue(), ^{ > [self willChangeValueForKey:@“foo”]; > }); > > self.privateFoo = foo; > >

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 1:45 PM, Ken Thomases wrote: > > This is not legitimate. The -willChangeValueForKey: must occur before the > property, as seen via its getter, has changed. This is necessary for > observers who ask for the old value, which can include KVO itself

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 2:49 PM, Charles Srstka wrote: > > - (instancetype)init { >self = [super init]; > >if (self == nil) { >return nil; >} > >return self; > } Oops, please disregard the empty init method in here; it’s an artifact from some I

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

> But I agree that this all (meaning the contortions to get updates onto the > main thread) seems like too much flash and not enough bang. The easiest way > would be to dispatch the original update code in blocks onto the main thread > asynchronously, thus serializing them and generating KVO

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

I can't help but think that there should be a way to use xpc services as a nice solution to this problem. Unfortunately xpc services are mostly designed around the idea that if the service dies the app can restart it when it needs. Whereas you need the service running your experiment and

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

On Sep 16, 2015, at 14:28 , Jean Suisse wrote: > > I thought of that at first, to solve the uncommitted CA transactions issues. > But the syntax is ugly. Sure, but in modern Cocoa programming it’s a standard pattern, so it’s not unreasonable to grin and bear it. (It’s

Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface

On Sep 16, 2015, at 11:45 , Ken Thomases wrote: > > This is not legitimate. The -willChangeValueForKey: must occur before the > property, as seen via its getter, has changed. This is necessary for > observers who ask for the old value, which can include KVO itself for

Re: Is it possible to transfer data by using light

This is how fibre optics work, so it is possible. In this case, you have to be careful not to give people seizures by blinking at the wrong frequency. The big question would be why you want to do it. It is most likely easier to transfer via wifi (also traveling at the speed of light, and

Re: Puzzling memory creep

> On 5 Sep 2015, at 02:48, Quincey Morris > wrote: > > On Sep 4, 2015, at 06:25 , Richard Kennaway wrote: >> >> If anyone wants to take a look at the whole project, I've put a zip file at > > FWIW, I don’t see any leaks when I

Re: Puzzling memory creep

> On 4 Sep 2015, at 01:21, Quincey Morris > wrote: > > Two thoughts about this. > > 1. Are you sure that ‘updateTime’ is running on the main thread? It needs to > be, since you’re updating the UI directly from this code. Yes, according to calling

Re: Puzzling memory creep

> On 4 Sep 2015, at 01:11, Scott Ribe wrote: > > On Aug 14, 2015, at 2:29 PM, Richard Kennaway wrote: >> >> the Responsible Caller is _dispatch_continuation_alloc_from_heap > > Sure sounds like something that *might* underly the

Is it possible to transfer data by using light

First of all, please take a look at this video: https://www.youtube.com/watch?v=LPyLHhiGTHM This toy can connect to the iphone's network by detecting the blinking screen of an iPhone. I wonder if it is possible that using this technique to transfer data. For instance, 1. you have some data, and

Re: Puzzling memory creep

> On 4 Sep 2015, at 01:38, Cosmo wrote: > > Is there any chance you have Zombie checking turned on in your scheme > settings? In my experience that might account for what you’ve described. No, that's turned off. Turning it on records large numbers of deallocated

Re: Puzzling memory creep

On Thu, September 17, 2015 3:32 am, Roland King wrote: > Do you have this problem on an actual device or just in the simulator? > I’m on a later iOS than you, perhaps that makes a difference I see the moderation system has suddenly disgorged all my posts from a week or three ago, just when I'm

Re: Puzzling memory creep

> On 4 Sep 2015, at 16:55, Scott Ribe wrote: > I would not be surprised if that callback to an observer is something > triggered by your updates--some part of the window event/update/redraw > handling deep in the framework. I don't have any advice to offer as to

Re: Puzzling memory creep

> > If anyone wants to take a look at the whole project, I've put a zip file at > https://www.dropbox.com/s/relxku0iw44o237/TestUILabelLeak.zip ok I downloaded it and it’s running on my iPhone right now, and instruments is up and it’s not leaking and it’s not growing. Reducing the timer

Re: Is it possible to transfer data by using light

> On Sep 16, 2015, at 9:06 PM, Jonathan Hull wrote: > > The big question would be why you want to do it. It is most likely easier to > transfer via wifi (also traveling at the speed of light, and optimized for > data transfer) or bluetooth. Secure pairing, as you said, is

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

> On Sep 16, 2015, at 11:58 AM, Quincey Morris > wrote: > > On Sep 16, 2015, at 04:00 , Jean Suisse > wrote: >> >> Does anyone know what to try / measure / observe to get more clues? > > It seems you’re

Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface

I don't see why you're using a strong reference from the weak reference inside your timer. You may be confusing ARC with that and your etc code. Change your code to just use weakself rather than strongself when calling updateUI. If there's a strong reference needed, try using self only. Also,