On 2013-09-12 17:52, Graham Cox wrote:
I believe it does. I think your reading of the getter convention may
be incorrect. If you can point to explicit documentation that states
that the returned object must belong to an autorelease pool, I'll
stand corrected, but that would be the first time I've
On 12/09/2013, at 6:07 PM, Kyle Sluder wrote:
> Personally, I would avoid doing this, as it could cause reentrancy among
> KVO observers of eventTypes. Instead, I'd assign to mEventTypes directly
> from your lazy initializer. Or perhaps I would factor out the common
> setter code to a private he
On Sep 11, 2013, at 10:38 , John McCall wrote:
>> [reduced need for Café Macs dinner tickets]
>
> Fortunately. :)
But you do know where to get them anyway…? ;-)
>> [inline reference counts]
>
>
> Right. ARC doesn’t replace the benefit of having an inline reference count.
> I think if we c
I have a helper tool (started via SMJobBless from the main app).
Its launchd.plist contains (no idea why, probably I copied this from some
sample code):
LaunchOnlyOnce = YES
RunAtLoad = YES
OnDemand = NO
The problem: it runs even when the the main app has never asked it to run.
Obviously it
On Sep 13, 2013, at 8:47 AM, "Gerriet M. Denkmann" wrote:
> I have a helper tool (started via SMJobBless from the main app).
>
> Its launchd.plist contains (no idea why, probably I copied this from some
> sample code):
> LaunchOnlyOnce = YES
> RunAtLoad = YES
> OnDemand = NO
>
> The proble
The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t
notice, the flat profiles, are in some ways more insidious, as they drag
everything down just a bit. Along with all the other things that drag
everything down a bit, and soon enough you have something that’s 10%
On Sep 13, 2013, at 3:04 AM, Marcel Weiher wrote:
> On Sep 11, 2013, at 10:38 , John McCall wrote:
>>> [inline reference counts]
>>
>>
>> Right. ARC doesn’t replace the benefit of having an inline reference count.
>> I think if we could magically bless all objects with an inline reference
>
This must be an incredibly basic question, but I haven't found an answer I'm
convinced by (apologies if I have missed something on the list). My question
relates to window controllers, and how ownership, retain/release etc should be
managed in order to (a) be correct and (b) satisfy the static a
We have a scroll view whose horizontal scroller needs to work in a different
mode sometimes (same mode that my previous scroll view problem is in). We set
the scroller's target and action so we can control the size and position of the
thumb via "[scroller setKnobProportion:proportion]" and "scro
On 13 Sep 2013, at 22:10, Charles Srstka wrote:
> On Sep 13, 2013, at 10:09 AM, Charles Srstka wrote:
>
>> On Sep 13, 2013, at 8:47 AM, "Gerriet M. Denkmann"
>> wrote:
>>
>>> I have a helper tool (started via SMJobBless from the main app).
>>>
>>> Its launchd.plist contains (no idea why, p
On Fri, Sep 13, 2013, at 11:14 AM, Steve Mills wrote:
> What's up here? It sure smells like a bug.
It does, but it might be one you can work around by changing how you're
implementing scrolling.
If I understand correctly, you need to pin a pane of controls to the
edge of the viewport, and scroll
I'm getting prepped for writing few of those...any good sample code out there?
I was having some issues compiling Apple sample code from a version of Xcode
that shall not be named...throwing bizarre errors. Figured I'd start with some
sane, validated goodness.
Thanks,
j
On Fri, Sep 13, 2013, at 09:12 AM, Jonathan Taylor wrote:
> I want to allocate a window + controller, and I want it to live until the
> user closes the GUI window, at which point I want it to disappear and
> clean up after itself. I believe that the following code does not leak
> memory and behaves
On 13 Sep 2013, at 17:12, Jonathan Taylor wrote:
>
>
> However the static analyzer complains that there is a "potential leak" of
> myWindowController, because it recognises that it has a retain count of 2
> when it returns from the init method. (The same applies if I don't retain in
> init a
On 13 Sep 2013, at 17:15, Gerriet M. Denkmann wrote:
>>
>> I should add that if you want to see what all the available options are for
>> launchd.plist, you can get a nice description of them by typing "man
>> launchd.plist" in the Terminal.
>
> This I have done already (but thanks for the hi
On Sep 13, 2013, at 11:51 AM, Paul Scott wrote:
>>> The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you
>>> don’t notice, the flat profiles, are in some ways more insidious, as they
>>> drag everything down just a bit. Along with all the other things that
>>> drag everyt
On Sep 13, 2013, at 10:09 AM, Charles Srstka wrote:
> On Sep 13, 2013, at 8:47 AM, "Gerriet M. Denkmann"
> wrote:
>
>> I have a helper tool (started via SMJobBless from the main app).
>>
>> Its launchd.plist contains (no idea why, probably I copied this from some
>> sample code):
>> LaunchOn
On Sep 13, 2013, at 6:47 AM, Gerriet M. Denkmann wrote:
> I have a helper tool (started via SMJobBless from the main app).
>
> Its launchd.plist contains (no idea why, probably I copied this from some
> sample code):
> LaunchOnlyOnce = YES
> RunAtLoad = YES
> OnDemand = NO
>
> The problem:
I have an NSDictionary that contains objects that support NSCopying. I can
use writeToFile:atomically: and it saves a nice plist file that I can read
cleanly.
If I use NSFileWrapper however (for my document-based app), I need to use a
keyed archiver to conver the NSDictionary to NSData. After NSFi
On Sep 13, 2013, at 6:46 PM, Trygve Inda wrote:
> I have an NSDictionary that contains objects that support NSCopying. I can
> use writeToFile:atomically: and it saves a nice plist file that I can read
> cleanly.
>
> If I use NSFileWrapper however (for my document-based app), I need to use a
> ke
20 matches
Mail list logo
