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.
Secure pairing, as yo
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 /
> 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 o
> 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 for this to be visible using
> heap generations in Instrume
> 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 RAM
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 ne
>> 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
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 a
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 commands
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 tha
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 pa
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 thread
> 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 whole 100+
> fields to
> 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 everything.
>
> However, I am
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 v
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 li
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 meta
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 b
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
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 stimula
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 te
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 Require
22 matches
Mail list logo
