> On 20 May 2015, at 2:17 pm, Quincey Morris
> wrote:
>
> My answer on this to Britt is that this is unknowable in general. *That* (or
> so I claim) is why it’s not safe to reason about retain counts. If Britt
> could be said to be wrong about anything, I’d say it’s this, the idea that
> “no
> On May 19, 2015, at 8:04 PM, Quincey Morris
> wrote:
>
> Solution B: We retain each object as it enters the cache. That allows us to
> selectively mark objects purgeable by releasing them again. Drawbacks: None.
You still have to be really careful about threading here. How do I know which
On May 19, 2015, at 9:26 PM, Graham Cox wrote:
> Just to be clear: it crashes when there is no involvement of my code at all -
> this is the stack trace without the override, but with zombies enabled:
>
> Crashed Thread:0 Dispatch queue: com.apple.main-thread
>
> Exception Type:
I've got a simple iOS project consisting of 2 collection view controllers
and a navigation controller.
Tapping any item in the first collection view simply pushes the second
collection view on the stack.
Problem is, when I tap "< Back" and then manually scroll up ... the app
crashes with a EXC_BA
On May 19, 2015, at 20:37 , Graham Cox wrote:
>
> I think what the OP says he wants is that the cache can only release when it
> knows nobody else has a reference to an object as well
My answer on this to Britt is that this is unknowable in general. *That* (or so
I claim) is why it’s not safe
> On 20 May 2015, at 1:04 pm, Quincey Morris
> wrote:
>
> I don’t think you’ve misunderstood anything at all.
Kind of you to say so - I’m not so sure :)
>
> So, we look at two possible solutions. [Spoiler: Both solutions are 100%
> correct, because both solutions are 100% identical, as far
On May 19, 2015, at 15:50 , Graham Cox wrote:
>
> I may have misunderstood the problem such that this is a poor ot for other
> reasons, but I’m not seeing it. I’m also not sure why there seems to be a
> tacit resistance to it - seems logical to me.
I don’t think you’ve misunderstood anything a
> On 20 May 2015, at 12:15 pm, Graham Cox wrote:
>
>> 'd start by looking at frame #4.
>
>
>> The only code of mine involved is at line 4 which is where I overrode
>> targetForAction:to:from to see what was being called from where, and then
>> calls super.
>
Just to be clear: it crashes
> On 20 May 2015, at 12:09 pm, Kyle Sluder wrote:
>
> On Tue, May 19, 2015, at 07:22 PM, Graham Cox wrote:
>> 3 com.apple.AppKit0x7fff8fb2fe3e
>> -[NSApplication targetForAction:to:from:] + 329
>> 4 com.mapdiva.as.artboard 0x000105a3103a 0x1059ba000 +
On Tue, May 19, 2015, at 07:22 PM, Graham Cox wrote:
> 3 com.apple.AppKit0x7fff8fb2fe3e
> -[NSApplication targetForAction:to:from:] + 329
> 4 com.mapdiva.as.artboard 0x000105a3103a 0x1059ba000 +
> 487482
> 5 com.apple.AppKit0x7ff
> On 20 May 2015, at 10:22 am, Graham Cox wrote:
>
> *this is the theory I’m working on, though it’s hard to be sure. Note that
> turning on NSZombies doesn’t show what the original target of the call was -
> it still crashes in the same way.
This is wrong - NSZombies does make it crash diff
I’m noticing something odd. When NSFontPanel is visible, it calls
-[NSApplication targetForAction:to:from:] excessively often - in fact on every
movement of the mouse. The action is -validModesForFontPanel: and the target is
nil, so this is being pushed up the responder chain all of the time.
T
> On 20 May 2015, at 12:20 am, Steve Christensen wrote:
>
> One thought I had was to base all your cacheable objects on a class whose
> sole function is to notify the cache when the last reference goes away, i.e.,
> when dealloc is called
This is what NSDiscardableContent is able to do, thou
On May 19, 2015, at 8:52 AM, Britt Durbrow
wrote:
>
>> On May 19, 2015, at 7:20 AM, Steve Christensen wrote:
>>
>> I just finished catching up on the discussion and keep coming back to the
>> fragile nature of relying on retainCount. For now you do, indeed, have the
>> option to vaporize you
> On May 19, 2015, at 7:20 AM, Steve Christensen wrote:
>
> I just finished catching up on the discussion and keep coming back to the
> fragile nature of relying on retainCount. For now you do, indeed, have the
> option to vaporize your toes; later you may not have access to a ray gun if
> App
I just finished catching up on the discussion and keep coming back to the
fragile nature of relying on retainCount. For now you do, indeed, have the
option to vaporize your toes; later you may not have access to a ray gun if
Apple decides that it's in the best interests of all concerned that the
If you can find a way to get the plugin plugged into your code then it is
doable. JS can be considered as resources and some custom Info.plist keys can
be introduced to index the required files.
> On May 19, 2015, at 20:21, Georg Seifert wrote:
>
> Hi,
>
> I hope this it the right place to as
Hi,
I hope this it the right place to ask, if not can you point me the right
direction.
Is it possible to build plugin bundles using Javascript? I know how to to that
with ObjectiveC and python (with py2app) but could’n find anything about
Javascript.
Georg
_
> On May 18, 2015, at 8:59 PM, Quincey Morris
> wrote:
>
> Let me try and summarize where we are, in response to the several recent
> suggestions:
>
Close, but not quite:
I have several apps which are built on an existing, fully functional data
management layer that was originally built fo
Greetings!
We are observing unusual behaviour with respect to Keyboard willshow & will
hide notification on iOS 8.3.
The viewcontroler (listenig to keyboard notifications) has a textfiled and
upon clicking and upon tapping the submit button, the method first resigns
the first responder from textf
20 matches
Mail list logo
