Re: Is it possible to transfer data by using light

On 17/09/15 07:06, Jens Alfke wrote: 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.

Re: Is it possible to transfer data by using light

> 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. Absolutely. Such techniques have been used for 150 years, using lamps or reflected sunlight to send Morse-like codes to human

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

>> 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. I was a little to harsh when I said that. I know everything I got from the WWDC videos. But I need more practice. And more

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

> On 16 sept. 2015, at 18:58, 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 “losing” free memory fast enough

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

> What makes you think that: > > (a) this is a lot of activity? It is not a lot of activity. I am not trying to do performance optimization. Right now, the app is taking 3 % CPU on the latest 13” MBP Retina. I am trying to find why my app can’t run for two days without exhausting the 16 GB

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

Thanks for your reply. > > 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

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

I have been looking at this issue for several weeks now. I could easily do what you suggest, or I could design the app with the “resume on re-launch” functionality and have it quit periodically based on memory criteria. Both are last resort to me. I would rather like to figure out what in GCD

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

Based on that, where you’re losing memory is to bitmapped backed CALayers that aren’t being released. Depending on the size of the bitmap, they can be big - MBs each. They are being allocated in the Kernel, so aren’t showing in instruments. Why they aren’t being released, I couldn’t say. Maybe

Re: Is it possible to transfer data by using light

Strictly speaking, light is the most common way that data is transferred, in that the forces between electrically charged particles are moderated by virtual photons. Other than light we have the gravitational, strong nuclear and weak nuclear forces however it is impractical to transmit much data

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

Also, in case you're pulling multiple values per instrument object in your new timer (e.g., temperature, time, frequency, etc.), and these may be updating on background threads, a simple way to get these is to pull all the values needed into local variables in a synchronize block based on the

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

Thanks for your reply. If I understand you correctly, I am already doing all that by having one updateUI function per instrument, which does: self.myProperty = self->myStorageVariable on every variables. All updateUI selectors are sent to all instruments, at the same time, from the main

Re: Is it possible to transfer data by using light

Yes. How do you think TV remotes work? They use IR transmitters/receivers. They are, however, PAINFULLY SLOW. When we were making FiOS TV, we had to create an app called FiOS Mobile Remote for the iPhone that would control your FiOS set top box. EVEN THOUGH the iPhone had to pipe its

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

> On 17 sept. 2015, at 16:00, Jean Suisse wrote: > > Thanks. But I already have one single timer dispatch source that updates all > the UI only by transferring double / int values from instance variables to > bound properties. The timer fires every second and causes the

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

> On 17 sept. 2015, at 14:58, Jean Suisse wrote: > > Thank you for this advice! > > My app has tabbed views that are implemented through the toolbar. When I > switch view, some memory indeed gets released. Sometimes a little, sometimes > way much more, but never

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

Just as I thought. You're overloading the system by tightly coupling your model and your view. Let your instruments (models) do their work, and let your controller consult them when ready and update the view; don't use your controller to tell the models to update the views. Using an office

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

Okay, so what it appears you have is over 100 timers being fired whose only purpose is to transfer a single value from one variable to another so that bindings will hear that change and update your UI. A better approach is to remove bindings completely, make a single timer on the main queue

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

OK, I understand. That was an exemple. The 100+ variables are spread on four Instruments. So I call 4 updateUI functions sequentially. There is no difference with having everything in a single function. Since I chose to use bindings directly on the instruments properties for this project (not

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

Yes, I saw that code, but it only set a single variable and appeared to only be associated with a single instrument. If you have 100+ instruments, that would be 100+ separate updates. You know your code better than I and may be simplifying things for us, but I've seen cases sounding very much

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

From what you write, that’s already what I do. > Just as I thought. You're overloading the system by tightly coupling your > model and your view. Let your instruments (models) do their work, and let > your controller consult them when ready and update the view; don't use your > controller to

Re: Is it possible to transfer data by using light

Flashing the entire screen as I describe should not be done in product (App Store) code, rather one might use it as a very, very rough prototype. I expect production-quality software could modulate the screen is far-more subtle ways that both would transmit data far faster as well as avoid

Re: Is it possible to transfer data by using light

On 17/09/15 17:32, Michael David Crawford wrote: And what the man said: I myself experience seizures in which I lose consciousness for as long as three weeks. Before they were diagnosed I would experience seizures while driving my car then suddenly find myself in unfamiliar places without any

DockTile Plugin: Failed to set up extra plugin. file:///Applications/Informant.app/ Plugin in quarantine

So interestingly, the plugin works fine on my El Capitan install, but not my Yosemite install. On my Yosemite install, I checked the code-signing: codesign --verify --deep --verbose=2 Informant.app and the end result is: Informant.app: valid on disk Informant.app: satisfies its Designated