date:20160921

Re: Stupid objective-c question

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 21:47 , Jeff Evans  wrote:
> 
> Of course, so [[NSArray alloc]init] is actually useless; I hadn't thought of 
> that. No one would ever declare an array that way.

Just continuing my nitpicking tour of this thread:

It isn’t useless. Sometimes you really want an empty array. For example, there 
are Cocoa APIs that have a parameter that’s an array of (say) options. In some 
cases, an API might accept nil as meaning “no options”, but in others it might 
throw an exception. It’s safer to pass [[NSArray alloc] init], or [NSArray 
array], or @[].

Another example where it might be needed is if you’re using 
“arrayByAddingObject:” or “arrayByAddingObjectsFromArray:” to construct an 
array, and you might want to start, conditionally, from an existing array or an 
empty array.

So it’s degenerate perhaps, but not exactly useless.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Jens Alfke

> On Sep 21, 2016, at 9:47 PM, Jeff Evans  wrote:
> 
> One would have to init it with objects to be useful at all, and then it 
> presumably would point to different data than another NSArray (even 
> nonmutable) inited with objects.

Yup. Another fun fact is that the non-mutable classes all implement -copy as 
simply “return self”, since copying an immutable object is a no-op*. 
Again, the mutable subclasses override -copy to make an actual copy.

—Jens

* aside from bumping the retain count, but I’m ignoring that because with ARC 
we no longer care about such things, right?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Doug Hill


> On Sep 21, 2016, at 10:07 PM, Quincey Morris 
>  wrote:
> 
> On Sep 21, 2016, at 21:10 , Doug Hill  > wrote:
>> 
>> I believe the original question was why you can compare a string literal to 
>> another object pointer using the == operator and it somehow works.
> 
> Actually, we’re more or less on the same page here, but for posterity…
> 
> There’s no “somehow” with the == operator. It’s a C thing, not an Obj-C 
> thing, so putting it between two pointers is well-defined, even if either of 
> them happens to be an object reference. Indeed, constructs like "(void*)3" 
> are also a C thing 

Just as an example of how this “somehow worked”, but just as easily couldn't:

@“xyz123” == @“xyz123”

isn’t guaranteed to resolve to YES.

Crazy stuff. :)

But I appreciate everyone jumping in on this topic, another thread for the ages.

Doug Hill
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 21:10 , Doug Hill  wrote:
> 
> I believe the original question was why you can compare a string literal to 
> another object pointer using the == operator and it somehow works.

Actually, we’re more or less on the same page here, but for posterity…

There’s no “somehow” with the == operator. It’s a C thing, not an Obj-C thing, 
so putting it between two pointers is well-defined, even if either of them 
happens to be an object reference. Indeed, constructs like "(void*)3" are also 
a C thing (any int can be cast to a pointer, provided the pointer size is at 
least as big as the int size on the architecture being compiled for).

The original solution rested on a matter of *uniqueness* of pointers to string 
literals. The point was that the characters making up the string were never 
intended to be compared, only the pointers themselves, relying on the 
uniqueness of pointers to different string values. It’s an extremely delicate 
(that is, nerdy) distinction, but it’s clearer when you consider that a pointer 
comparison can always be assumed to be really, really cheap (1 machine 
instruction, almost always), whereas a string comparison can be quite 
expensive, quite apart from the question of whether objects or dynamism are 
involved.

Another way of saying it is that the original solution leveraged the difference 
between literal string values without actually comparing them. That’s why it 
was clever (if only it wasn’t fatally flawed for a different reason).

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Jeff Evans

Ah - yes, thank you.  Of course, so [[NSArray alloc]init] is actually useless; 
I hadn't thought of that. No one would ever declare an array that way.
One would have to init it with objects to be useful at all, and then it 
presumably would point to different data than another NSArray (even nonmutable) 
inited with objects.

Jeff

On Sep 21, 2016, at 9:33 PM, Jens Alfke wrote:

> On Sep 21, 2016, at 9:19 PM, Jeff Evans  wrote:
> 
>   Is it really true what Jens says,  that [[NSArray alloc]init] always 
> returns the same pointer?
>   If that is the case, how can one declare two separate arrays?

NSArray is immutable, so any two empty NSArrays are equal/identical.
Now, _mutable_ arrays are different — every call to [[NSMutableArray alloc] 
init] returns a new instance.

The same thing is true of other immutable Foundation classes like NSDictionary, 
NSString and NSNumber, so you’ll see the same optimization for e.g. short 
strings and small integers. (In fact, the latter two are now implemented using 
magic tagged pointers that don’t allocate memory at all!)

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Jens Alfke

> On Sep 21, 2016, at 9:19 PM, Jeff Evans  wrote:
> 
>   Is it really true what Jens says,  that [[NSArray alloc]init] always 
> returns the same pointer?
>   If that is the case, how can one declare two separate arrays?

NSArray is immutable, so any two empty NSArrays are equal/identical.
Now, _mutable_ arrays are different — every call to [[NSMutableArray alloc] 
init] returns a new instance.

The same thing is true of other immutable Foundation classes like NSDictionary, 
NSString and NSNumber, so you’ll see the same optimization for e.g. short 
strings and small integers. (In fact, the latter two are now implemented using 
magic tagged pointers that don’t allocate memory at all!)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Doug Hill

I think it’s because an NSArray is immutable such that an empty array is 
guaranteed to never change. This gives the compiler opportunities for 
optimization based on this knowledge.

It starts to get interesting when you do things like:

NSArray *emptyArray   = [[NSArray alloc] init];
NSArray *anotherArray = [emptyArray arrayByAddingObject:anObject];

But this creates a new array. Consequently, any meaningful array won’t be the 
one created with [[NSArray alloc] init].

Doug Hill


> On Sep 21, 2016, at 9:19 PM, Jeff Evans  wrote:
> 
> Whoa - maybe I've had too much wine with dinner, but:
> 
>   Is it really true what Jens says,  that [[NSArray alloc]init] always 
> returns the same pointer?
>   If that is the case, how can one declare two separate arrays?
> 
> Jeff
> 
> On Sep 21, 2016, at 8:50 PM, Jens Alfke wrote:
> 
> 
>> On Sep 21, 2016, at 6:36 PM, Graham Cox  wrote:
>> 
>> Which is yet another reason why void* is such a shitty concept. Apple could 
>> easily have insisted that parameter was id without any real 
>> problems, so void*… sheesh.
> 
> It’s not an object! It’s just an opaque ‘cookie’ that you can use to 
> recognize which observer is being invoked, and specify which one to remove.
> 
> The point of using a void* is that it’s easy to generate guaranteed-unique 
> values by taking the address of a static variable. If the context were an 
> object, people would be likely to assume they should use -isEqual: to compare 
> them (as half the people on this thread seem to be doing), but that’s not a 
> good idea because it can result in false positives comparing 
> equal-but-different objects.
> 
> Moreover, it can be hard to be sure whether you’re getting distinct objects 
> in Obj-C, since initializers will often return unique singletons for common 
> cases. For instance, [[NSArray alloc] init] will always return the same 
> pointer every time it’s called, making it a terrible choice for a context.
> 
> —Jens


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Jeff Evans

Whoa - maybe I've had too much wine with dinner, but:

Is it really true what Jens says,  that [[NSArray alloc]init] always 
returns the same pointer?
If that is the case, how can one declare two separate arrays?

Jeff

On Sep 21, 2016, at 8:50 PM, Jens Alfke wrote:

> On Sep 21, 2016, at 6:36 PM, Graham Cox  wrote:
> 
> Which is yet another reason why void* is such a shitty concept. Apple could 
> easily have insisted that parameter was id without any real 
> problems, so void*… sheesh.

It’s not an object! It’s just an opaque ‘cookie’ that you can use to recognize 
which observer is being invoked, and specify which one to remove.

The point of using a void* is that it’s easy to generate guaranteed-unique 
values by taking the address of a static variable. If the context were an 
object, people would be likely to assume they should use -isEqual: to compare 
them (as half the people on this thread seem to be doing), but that’s not a 
good idea because it can result in false positives comparing 
equal-but-different objects.

Moreover, it can be hard to be sure whether you’re getting distinct objects in 
Obj-C, since initializers will often return unique singletons for common cases. 
For instance, [[NSArray alloc] init] will always return the same pointer every 
time it’s called, making it a terrible choice for a context.

—Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Doug Hill

> On Sep 21, 2016, at 8:33 PM, Quincey Morris 
>  wrote:
> 
> On Sep 21, 2016, at 19:00 , Doug Hill  > wrote:
>> 
>> Just to be clear, the original question was specifically about comparing an 
>> Objective-C string literal. For this case, you definitely want to use 
>> -[NSString isEqualToString:]
> 
> Actually, no. A couple of similar comments in this thread have slightly 
> missed the point about the original question.
> 
> The “cleverness” of that original approach was that the contents of the 
> string really had nothing to do with anything. As long as the string being 
> used for the current observer scenario was different from strings being used 
> by other scenarios, the pointers to the string would be different, and every 
> context would be different.
> 
> You could as easily have used (void*)1, (void*)2, (void*)3, etc in the 
> various places in your app, but using meaningful strings instead is a fairly 
> easy way of not mixing the pointers up.
> 
> Thus, there was never any intent to compare string values, just pointers, and 
> that’s what made the ‘==‘ comparison crash-proof.
> 
> It wouldn’t be *illogical* to use string value comparisons instead, except 
> that then, yes, you’d have to code around the cases where the context is not 
> a pointer to a NSString object.

I believe the original question was why you can compare a string literal to 
another object pointer using the == operator and it somehow works. The contents 
of the string in this case would be very important because the compiler does 
some magic to make duplicates of strings all have the same address. As was 
mentioned, this is a quirk of string pooling/merging by the compiler and that 
it might happen in some cases but maybe not in others. For example, I think you 
can control this behavior in GCC and LLVM with a compiler setting. Just to make 
it clear, CLang calls this undefined behavior:

NSString *foo = @"xyz123";
if( foo == @"xyz123" )
NSLog(@"YES");

warning: direct comparison of a string literal has undefined behavior 
[-Wobjc-string-compare]

Again, in general (i.e. not just for observing scenarios) you probably 
shouldn’t rely on identical strings, especially literals.

But as we’ve now verified from Apple documentation, comparing to a static 
variable address is the way to handle the context parameter in key path 
observation, so we shouldn’t be involving literals.

>> As to the context type, I would be interested to know of cases where the 
>> observer doesn't have control over the context. My understanding is that the 
>> context is something that the observer sets itself when calling addObserver, 
>> and it is passed back to itself in the above method call. So the observer 
>> should know what kind of entity the context is, and can determine the best 
>> way to compare this value.
> 
> 
> If you were the sole author of all observations in your app, you wouldn’t 
> absolutely need a context parameter at all, since you can identify the 
> observation** from the object and keypath. But you’re not.
> 
> The observer doesn’t have control over the context when the superclass or a 
> subclass also does observations, and those other classes aren’t written as 
> part of the project. For example, a view controller is a class that’s often 
> going to want to observe things, but NSViewController may itself be observing 
> things too, possible some of the same things. That’s one reason why the 
> observer method must always call super for notifications that it cannot 
> recognize *specifically* as resulting from observations it *specifically* 
> added.
> 
> ** Except in the case where observations from various sources are funneled 
> through a common observer method, which doesn’t happen a lot, but does happen.

This makes sense. I’m glad I’m getting this figured out after all these years. 
:)

Doug Hill

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Jens Alfke


> On Sep 21, 2016, at 7:00 PM, Doug Hill  wrote:
> 
> As to the context type, I would be interested to know of cases where the 
> observer doesn't have control over the context. My understanding is that the 
> context is something that the observer sets itself when calling addObserver, 
> and it is passed back to itself in the above method call. So the observer 
> should know what kind of entity the context is, and can determine the best 
> way to compare this value.

Subclasses or superclasses can register observers, so it’s possible for your 
observer method to get called for observations that you didn’t create.

(The subclass case is less likely, because the subclass’s observer method 
should be handling that call and not calling super, but it’s good defensive 
coding practice to not rely 100% on that.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Jens Alfke

> On Sep 21, 2016, at 6:36 PM, Graham Cox  wrote:
> 
> Which is yet another reason why void* is such a shitty concept. Apple could 
> easily have insisted that parameter was id without any real 
> problems, so void*… sheesh.

It’s not an object! It’s just an opaque ‘cookie’ that you can use to recognize 
which observer is being invoked, and specify which one to remove.

The point of using a void* is that it’s easy to generate guaranteed-unique 
values by taking the address of a static variable. If the context were an 
object, people would be likely to assume they should use -isEqual: to compare 
them (as half the people on this thread seem to be doing), but that’s not a 
good idea because it can result in false positives comparing 
equal-but-different objects.

Moreover, it can be hard to be sure whether you’re getting distinct objects in 
Obj-C, since initializers will often return unique singletons for common cases. 
For instance, [[NSArray alloc] init] will always return the same pointer every 
time it’s called, making it a terrible choice for a context.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 19:00 , Doug Hill  wrote:
> 
> Just to be clear, the original question was specifically about comparing an 
> Objective-C string literal. For this case, you definitely want to use 
> -[NSString isEqualToString:]

Actually, no. A couple of similar comments in this thread have slightly missed 
the point about the original question.

The “cleverness” of that original approach was that the contents of the string 
really had nothing to do with anything. As long as the string being used for 
the current observer scenario was different from strings being used by other 
scenarios, the pointers to the string would be different, and every context 
would be different.

You could as easily have used (void*)1, (void*)2, (void*)3, etc in the various 
places in your app, but using meaningful strings instead is a fairly easy way 
of not mixing the pointers up.

Thus, there was never any intent to compare string values, just pointers, and 
that’s what made the ‘==‘ comparison crash-proof.

It wouldn’t be *illogical* to use string value comparisons instead, except that 
then, yes, you’d have to code around the cases where the context is not a 
pointer to a NSString object.

> As to the context type, I would be interested to know of cases where the 
> observer doesn't have control over the context. My understanding is that the 
> context is something that the observer sets itself when calling addObserver, 
> and it is passed back to itself in the above method call. So the observer 
> should know what kind of entity the context is, and can determine the best 
> way to compare this value.

If you were the sole author of all observations in your app, you wouldn’t 
absolutely need a context parameter at all, since you can identify the 
observation** from the object and keypath. But you’re not.

The observer doesn’t have control over the context when the superclass or a 
subclass also does observations, and those other classes aren’t written as part 
of the project. For example, a view controller is a class that’s often going to 
want to observe things, but NSViewController may itself be observing things 
too, possible some of the same things. That’s one reason why the observer 
method must always call super for notifications that it cannot recognize 
*specifically* as resulting from observations it *specifically* added.

** Except in the case where observations from various sources are funneled 
through a common observer method, which doesn’t happen a lot, but does happen.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Wim Lewis

On Sep 21, 2016, at 7:00 PM, Doug Hill  wrote:
> As to the context type, I would be interested to know of cases where the 
> observer doesn't have control over the context. My understanding is that the 
> context is something that the observer sets itself when calling addObserver, 
> and it is passed back to itself in the above method call. So the observer 
> should know what kind of entity the context is, and can determine the best 
> way to compare this value.

The main use of the context parameter, I think, is to to keep your 
*de*registrations from clobbering the wrong registration. It's also useful to 
make sure you're looking at the observation you think you are. If a superclass 
or subclass also observes some things, then your -observeValueForKeyPath can be 
called for all sorts of things other than the things you requested. The 
'context' parameter supplies an opaque value that supports comparison but 
nothing else- that's why it's a (void *).

Unlike other context pointers in the API, you don't usually need to pass data 
in to your observation method, because it has access to self.

I usually use either the "address of a static variable" technique that Quincey 
Morris described, or [TheClassThatMyCodeIsIn class]. The latter will, like the 
static variable, be a pointer value that is unique to the set of observations 
you've registered (superclasses and subclasses will have to register using 
their own class, of course), and sometimes it's easier to examine in the 
debugger. I think the static-variable approach is better in general though.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Doug Hill

> On Sep 21, 2016, at 6:36 PM, Graham Cox  wrote:
> 
> 
>> On 22 Sep 2016, at 10:40 AM, Quincey Morris 
>>  wrote:
>> 
>> On Sep 21, 2016, at 17:01 , Graham Cox  wrote:
>>> 
>>> This should be: if([(NSString*)context 
>>> isEqualToString:@“mediaLibraryLoaded”])…
>> 
>> Actually, this is not a good idea either, because *other* observations — 
>> ones you don’t control — might use a value that’s not an object, or not even 
>> a valid pointer.
> 
> 
> Fair point.
> 
> Which is yet another reason why void* is such a shitty concept. Apple could 
> easily have insisted that parameter was id without any real 
> problems, so void*… sheesh.
> 
> So Gabriel’s alternative is basically to use a global address, as you 
> otherwise suggested.
> 
> void* tsk… *goes away muttering*
> 
> —Graham

Just to be clear, the original question was specifically about comparing an 
Objective-C string literal. For this case, you definitely want to use 
-[NSString isEqualToString:]

As to the context type, I would be interested to know of cases where the 
observer doesn't have control over the context. My understanding is that the 
context is something that the observer sets itself when calling addObserver, 
and it is passed back to itself in the above method call. So the observer 
should know what kind of entity the context is, and can determine the best way 
to compare this value.

But hey, always check the documentation first. Here's a nice little tidbit from

https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOBasics.html

"The address of a uniquely named static variable within your class makes a good 
context. Contexts chosen in a similar manner in the super- or subclass will be 
unlikely to overlap. You may choose a single context for the entire class and 
rely on the key path string in the notification message to determine what 
changed. Alternatively, you may create a distinct context for each observed key 
path, which bypasses the need for string comparisons entirely, resulting in 
more efficient notification parsing."

So, instead of using a string literal, create a static object and do pointer 
comparisons is what Apple recommends.

Hope this helps.

Doug Hill
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Graham Cox

> On 22 Sep 2016, at 10:40 AM, Quincey Morris 
>  wrote:
> 
> On Sep 21, 2016, at 17:01 , Graham Cox  wrote:
>> 
>> This should be: if([(NSString*)context 
>> isEqualToString:@“mediaLibraryLoaded”])…
> 
> Actually, this is not a good idea either, because *other* observations — ones 
> you don’t control — might use a value that’s not an object, or not even a 
> valid pointer.

Fair point.

Which is yet another reason why void* is such a shitty concept. Apple could 
easily have insisted that parameter was id without any real problems, 
so void*… sheesh.

So Gabriel’s alternative is basically to use a global address, as you otherwise 
suggested.

void* tsk… *goes away muttering*

—Graham

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 18:00 , Slipp Douglas Thompson 
 wrote:
> 
> isEqualToString: could cause issues here so isEqual: is the most sure-fire 
> solution

Er, no. If the context is not an object, [context isEqual: … anything …] is 
going to crash in objc_msgSend before execution gets to the ‘isEqual’ method.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Slipp Douglas Thompson

> On Sep 21, 2016, at 8:00 PM, Slipp Douglas Thompson 
>  wrote:
> 
>> On Sep 21, 2016, at 17:01 , Graham Cox  wrote:
>>> 
>>> This should be: if([(NSString*)context 
>>> isEqualToString:@“mediaLibraryLoaded”])…
>> 
>> Actually, this is not a good idea either, because *other* observations — 
>> ones you don’t control — might use a value that’s not an object, or not even 
>> a valid pointer.
> 

I see your point about context plausibly not being neither an NSObject nor nil. 
 While you could check if context is an NSObject beforehand (is there even a 
reliable way to do this?  CocoaWithLove 

 couldn't find a great approach ;-/)— I think coding consistently against all 
other addObserver: calls in your app is a good-enough solution.  I.E. If you 
implement observeValueForKeyPath: with [context isEqual: …] checks, make sure 
all the other addObserver: calls (for those same keys, at least) are using nil 
or NSObjects.

Thoughts?

— Slipp
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Slipp Douglas Thompson

> On Sep 21, 2016, at 17:01 , Graham Cox  wrote:
>> 
>> This should be: if([(NSString*)context 
>> isEqualToString:@“mediaLibraryLoaded”])…
> 
> Actually, this is not a good idea either, because *other* observations — ones 
> you don’t control — might use a value that’s not an object, or not even a 
> valid pointer.

Looking over a couple of open-source implementations of Foundation (cocotron 
, 
PureFoundation 
), the 
first check done in both isEqual: & isEqualToString: is a pointer == check.  

So yes, isEqualToString: could cause issues here so isEqual: is the most 
sure-fire solution (IMHO)— it shouldn't be any less performant than 
isEqualToString: and only marginally less performant than a == (due to 
objc_msgSend overhead).

— Slipp
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 17:01 , Graham Cox  wrote:
> 
> This should be: if([(NSString*)context 
> isEqualToString:@“mediaLibraryLoaded”])…

Actually, this is not a good idea either, because *other* observations — ones 
you don’t control — might use a value that’s not an object, or not even a valid 
pointer.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Slipp Douglas Thompson

> Whenever I have two string literals @"XYZ" at different places in the same 
> compilation unit,
> and the XYZ are identical, then the compiler (or the Objective-C standard) 
> make sure that
> the pointers to those literals are identical?
> 
> In other words, the compiler unifies the two occurrences of the two literals, 
> thus effectively storing only one literal?

Yes that's why it works in your test, but as Graham Cox said, you “are taking 
advantage of undocumented implementation details”.  This behavior is not a 
standard at all.


> So what would be the proper way to do it?  Should I just define my own string 
> constant?

As others have suggested, always use isEqual: or isEqualToString: when doing 
NSString comparisons, never ==.  The Obj-C implementation does a pointer 
comparison first, so isEqual:/isEqualToString: do not incur a significant 
performance cost in this situation.

— Slipp



> On Sep 21, 2016, at 7:05 PM, Gabriel Zachmann  wrote:
> 
> 
>>> 
>>> how can the compiler know that '==' in this case is a NSString comparison?
>> 
>> It can’t because it isn't. What’s being compared are raw pointers. The 
>> string value is irrelevant.
> 
> Let me try to paraphrase, in order to check whether I am understanding 
> correctly.
> 
> Whenever I have two string literals @"XYZ" at different places in the same 
> compilation unit,
> and the XYZ are identical, then the compiler (or the Objective-C standard) 
> make sure that
> the pointers to those literals are identical?
> In other words, the compiler unifies the two occurrences of the two literals, 
> thus effectively storing only one literal?
> 
> 
>> So, this technique is generally Not A Good Idea™.
> 
> 
> If my understanding is correct, then I wholeheartedly agree.
> 
> That brings me to another question.  I've got this piece of code from an 
> example on MLMediaLibrary.
> 
> This is how I start the whole thing:
> 
>  [mediaLibrary_ addObserver: self
>  forKeyPath: @"mediaSources"
> options: 0
> context: (__bridge void *) @"mediaLibraryLoaded"];
> 
> And this is the beginning of the corresponding KVO:
> 
> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>   change: (NSDictionary *) change context: (void *) 
> context
> {
>  MLMediaSource * mediaSource = [mediaLibrary_.mediaSources objectForKey: 
> MLMediaSourcePhotosIdentifier];
>  if ( context == (__bridge void *) @"mediaLibraryLoaded" )
>  {
> 
> 
> So what would be the proper way to do it?  Should I just define my own string 
> constant?
> 
> 
> 
> Best regards, 
> Gabriel.
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/apple%2Bcocoa-dev%40slippyd.com
> 
> This email sent to apple+cocoa-...@slippyd.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 17:05 , Gabriel Zachmann  wrote:
> 
> In other words, the compiler unifies the two occurrences of the two literals, 
> thus effectively storing only one literal?

Correct.

> So what would be the proper way to do it?

A global variable has a fixed, unique memory address, so you can do this:

static int MyContext; 
// does not need to be extern, just defined at the top level scope of 
some file, usually the relevant class implementation .m file
// type doesn’t matter, because the value is never used

But you can take advantage of a C quirk and actually write this:

static void* MyContext = &MyContext;

This has the interesting property that MyContext == &MyContext, which means you 
don’t have to worry about remembering the “&" operator when passing or testing 
the “context” parameter.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Jens Alfke

> On Sep 21, 2016, at 4:44 PM, Gabriel Zachmann  wrote:
> 
> My question is: how can the compiler know that '==' in this case is a 
> NSString comparison?

It doesn’t. In Obj-C, “==“ is always a pointer comparison even if it’s applied 
to objects. It is NOT the same as -isEqual:.

This idiom with the `context` parameter of -observeValueForKeyPath: works 
because the context is just an opaque pointer. You register the context when 
you start observing, and the same exact pointer gets passed back to you when 
you’re called. So you can use the context to identify which observation this 
is, and since it’s just an opaque pointer value, you compare it using ‘==‘.

I’ve also seen people use C strings for this, i.e.
if (context == “mediaLibraryLoaded”) …
or just integers cast to void*:
if (context = (void*)1) …

The only danger when using string constants (NSString or char*) is that it’s 
only safe to do this if all the code is being linked into the same binary. The 
linker ensures that all references to “foo” refer to the same string constant 
in memory. (Same with @“foo”.) If you have some code in the app and some other 
code in a plugin library, though, they will almost certainly have different 
pointer values for “foo” or @“foo”.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Gabriel Zachmann


>> 
>> how can the compiler know that '==' in this case is a NSString comparison?
> 
> It can’t because it isn't. What’s being compared are raw pointers. The string 
> value is irrelevant.

Let me try to paraphrase, in order to check whether I am understanding 
correctly.

Whenever I have two string literals @"XYZ" at different places in the same 
compilation unit,
and the XYZ are identical, then the compiler (or the Objective-C standard) make 
sure that
the pointers to those literals are identical?
In other words, the compiler unifies the two occurrences of the two literals, 
thus effectively storing only one literal?


> So, this technique is generally Not A Good Idea™.


If my understanding is correct, then I wholeheartedly agree.

That brings me to another question.  I've got this piece of code from an 
example on MLMediaLibrary.

This is how I start the whole thing:

  [mediaLibrary_ addObserver: self
  forKeyPath: @"mediaSources"
 options: 0
 context: (__bridge void *) @"mediaLibraryLoaded"];

And this is the beginning of the corresponding KVO:

- (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
   change: (NSDictionary *) change context: (void *) context
{
  MLMediaSource * mediaSource = [mediaLibrary_.mediaSources objectForKey: 
MLMediaSourcePhotosIdentifier];
  if ( context == (__bridge void *) @"mediaLibraryLoaded" )
  {


So what would be the proper way to do it?  Should I just define my own string 
constant?



Best regards, 
Gabriel.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Doug Hill


> On Sep 21, 2016, at 4:52 PM, Steve Mills  wrote:
> 
>> On Sep 21, 2016, at 18:44, Gabriel Zachmann  wrote:
>> 
>> I've got a stupid, curious question regarding a code snippet that I have 
>> found on the net (I tried it, it works).
>> 
>> Here is the code snippet:
>> 
>> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>>   change: (NSDictionary *) change context: (void *) 
>> context
>> {
>>  if ( context == (__bridge void *) @"mediaLibraryLoaded" )
>>  {
>>// ...
>> 
>> 
>> My question is: how can the compiler know that '==' in this case is a 
>> NSString comparison?
>> Or is some other magic going on here? if so, which?
>> Does the compiler know it should perform some kind of dynamic method 
>> dispatch?
> 
> My guess, without seeing the code that set up the observer, is that it was 
> also set up with @"mediaLibraryLoaded", and the compiler collects and reuses 
> string constants, so the address is the same. I'd guess that if you ensure 
> that the string is a unique variable, it won't work.
> 
> NSString* s = [NSString stringWithFormat:@"%@%@%@", @"media", @"Library", 
> @"Loaded"];
> if(context == (__bridge void*)s)
> 
> Steve via iPad

For the above test, you could also try turning off the LLVM code-gen setting 
"gcc_reuse_strings".
(Which parenthetically, you probably wouldn't want to do in shipping code, 
particularly if you have a lot of strings.)

But yeah, as everyone says, it's generally not a good thing to rely upon this 
behavior, and just use -[NSString isEqual:]

Doug Hill
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Graham Cox

> On 22 Sep 2016, at 9:44 AM, Gabriel Zachmann  wrote:
> 
> I have found on the net 

That isn’t always a recommendation ;)

>   if ( context == (__bridge void *) @"mediaLibraryLoaded" )

Don’t do this, even if it appears to work. You got lucky, or are taking 
advantage of undocumented implementation details.

This should be: if([(NSString*)context isEqualToString:@“mediaLibraryLoaded”])…

I expect the first thing -isEqualToString: does is a pointer comparison, so 
it’s unlikely to be significantly less performant for the case of when the 
pointers are literally identical.

—Graham

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Daniel Stenmark

It’s doing a pointer comparison while making poor assumptions about how the 
compiler will optimize the storage of string constants.  This is bad; DO NOT DO 
THIS.

Dan

> On Sep 21, 2016, at 4:44 PM, Gabriel Zachmann  wrote:
> 
> I've got a stupid, curious question regarding a code snippet that I have 
> found on the net (I tried it, it works).
> 
> Here is the code snippet:
> 
> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>change: (NSDictionary *) change context: (void *) 
> context
> {
>   if ( context == (__bridge void *) @"mediaLibraryLoaded" )
>   {
> // ...
> 
> 
> My question is: how can the compiler know that '==' in this case is a 
> NSString comparison?
> Or is some other magic going on here? if so, which?
> Does the compiler know it should perform some kind of dynamic method dispatch?
> 
> 
> Thanks a million for all kinds of enlightenment.
> 
> Best regards, 
> Gabriel.
> 
> 
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dstenmark%40opentable.com
> 
> This email sent to dstenm...@opentable.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Steve Mills

> On Sep 21, 2016, at 18:44, Gabriel Zachmann  wrote:
> 
> I've got a stupid, curious question regarding a code snippet that I have 
> found on the net (I tried it, it works).
> 
> Here is the code snippet:
> 
> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>change: (NSDictionary *) change context: (void *) 
> context
> {
>   if ( context == (__bridge void *) @"mediaLibraryLoaded" )
>   {
> // ...
> 
> 
> My question is: how can the compiler know that '==' in this case is a 
> NSString comparison?
> Or is some other magic going on here? if so, which?
> Does the compiler know it should perform some kind of dynamic method dispatch?

My guess, without seeing the code that set up the observer, is that it was also 
set up with @"mediaLibraryLoaded", and the compiler collects and reuses string 
constants, so the address is the same. I'd guess that if you ensure that the 
string is a unique variable, it won't work.

NSString* s = [NSString stringWithFormat:@"%@%@%@", @"media", @"Library", 
@"Loaded"];
if(context == (__bridge void*)s)

Steve via iPad


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 16:44 , Gabriel Zachmann  wrote:
> 
> how can the compiler know that '==' in this case is a NSString comparison?

It can’t because it isn't. What’s being compared are raw pointers. The string 
value is irrelevant.

> Or is some other magic going on here? if so, which?

No magic, but a (not very good) assumption, that literal strings are unique at 
run time, so a pointer to a particular literal string is a globally unique 
identifier.

Incidentally, this assumption is true only within a target. Literal strings in 
different targets may have different pointers.

So, this technique is generally Not A Good Idea™.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Stupid objective-c question

2016-09-21 Thread Gabriel Zachmann

I've got a stupid, curious question regarding a code snippet that I have found 
on the net (I tried it, it works).

Here is the code snippet:

- (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
change: (NSDictionary *) change context: (void *) 
context
{
   if ( context == (__bridge void *) @"mediaLibraryLoaded" )
   {
 // ...


My question is: how can the compiler know that '==' in this case is a NSString 
comparison?
Or is some other magic going on here? if so, which?
Does the compiler know it should perform some kind of dynamic method dispatch?


Thanks a million for all kinds of enlightenment.

Best regards, 
Gabriel.






___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: MLMediaLibrary sometimes does not call my KVO

2016-09-21 Thread Graham Cox

> On 22 Sep 2016, at 8:59 AM, Gabriel Zachmann  wrote:
> 
> I am a bit at a loss about the MLMediaLibrary API.
> Maybe, I haven't quite understood it yet, maybe something else is wrong.
> 
> I am writing a screen saver that accesses Photos' albums and the images 
> referenced by them.
> (Code excerpts follow at the end of this email.)
> 
> I create an array of the top level albums at startup time of the screensaver 
> , using the KVO.
> At runtime, I occasionally extract the images referenced by one of those 
> albums.
> Most of the time it works fine, except sometimes, my KVO never gets invoked, 
> at which point my screensaver hangs,
> because I had to stop the animation during that phase.
> 
> I have not found a pattern as to when this happens.
> (it is not a deterministic album, nor a deterministic n-th time.)
> 
> Any suggestions, hints, insights, and pointers will be highly appreciated.

I’ve run into some unreliability in MLMediaLibrary. It appears to be a bug 
because it sometimes can be seen in places that use MLMediaLibrary within 
general standard components, such as NSOpenPanel (this adds a media browsing 
section if it is set up to allow image types, for example). Sometimes it only 
shows the top level of the library, and all of the subgroups are simply 
missing, and never show up no matter how long you wait. Opening the panel a 
second time will finally deliver the subgroups.

My guess is that as it’s an asynchronous API, on the first pass the system has 
to build a lot of internal cached state, and it may fail for any reason. On the 
second pass, it has already primed much of that cache and the failure doesn’t 
occur. While this happens quite often, it’s not every time, so I haven’t 
spotted an absolute pattern.

But I think your code needs to be designed in such a way that if the KVO it is 
expecting (for the contents of a given group, say) is never delivered, it 
doesn’t fail. I’m not sure that is really possible for a photos screensaver (in 
that case you have no photos to display), but there’s no reason it needs to 
hang.

Hopefully 10.12 will fix the issue, but I haven’t had a chance to look into 
that yet.

—Graham

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

MLMediaLibrary sometimes does not call my KVO

2016-09-21 Thread Gabriel Zachmann

I am a bit at a loss about the MLMediaLibrary API.
Maybe, I haven't quite understood it yet, maybe something else is wrong.

I am writing a screen saver that accesses Photos' albums and the images 
referenced by them.
(Code excerpts follow at the end of this email.)

I create an array of the top level albums at startup time of the screensaver , 
using the KVO.
At runtime, I occasionally extract the images referenced by one of those albums.
Most of the time it works fine, except sometimes, my KVO never gets invoked, at 
which point my screensaver hangs,
because I had to stop the animation during that phase.

I have not found a pattern as to when this happens.
(it is not a deterministic album, nor a deterministic n-th time.)

Any suggestions, hints, insights, and pointers will be highly appreciated.

Best regards, 
Gabriel.


The code snippets.  (variables ending with underscore are instance variables.)


This is what I do at startup time (in -initwithFrame:isPreview:)


   albums_ = [[NSMutableArray alloc] init];
   NSDictionary *options = @{
 MLMediaLoadSourceTypesKey: 
@(MLMediaSourceTypeImage),
 MLMediaLoadIncludeSourcesKey: 
@[MLMediaSourcePhotosIdentifier]
 };
   mediaLibrary_ = [[MLMediaLibrary alloc] initWithOptions: options];
   [mediaLibrary_ addObserver: self
   forKeyPath: @"mediaSources"
  options: 0
  context: (__bridge void *) @"mediaLibraryLoaded"];
   [mediaLibrary_.mediaSources objectForKey: MLMediaSourcePhotosIdentifier ];  
// starts asynchronous loading


During runtime, this gets executed occasionally:


   album_ = albums_[album_id];
   [album_ addObserver: self
forKeyPath: @"mediaObjects"
   options: 0
   context: @"mediaObjects"];
   [album_ mediaObjects];


I have checked using log message that addObserver: does actually get executed.


And this is my key value observer:


- (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
change: (NSDictionary *) change context: (void *) 
context
{
   MLMediaSource * mediaSource = [mediaLibrary_.mediaSources objectForKey: 
MLMediaSourcePhotosIdentifier];
   if ( context == (__bridge void *) @"mediaLibraryLoaded" )
   {
   [mediaSource addObserver: self
 forKeyPath: @"rootMediaGroup"
options: 0
context: (__bridge void *) @"rootMediaGroupLoaded"];
   [mediaSource rootMediaGroup];   
// start next phase: load groups
   }
   else if ( context == (__bridge void *) @"rootMediaGroupLoaded" )
   {
   MLMediaGroup *albums = [mediaSource mediaGroupForIdentifier: 
@"TopLevelAlbums"];
   for ( MLMediaGroup * album in albums.childGroups )
   {
   NSString * albumName = [album.attributes objectForKey: @"name"];
   [self logMessage: [NSString stringWithFormat: @"album name = %@", 
albumName] asError: NO];
   if ( albumName )
   [albums_ addObject: album ];
   }
   }
   else if ( context == (__bridge void *) @"mediaObjects" )
   {
   NSArray * mediaObjects = album_.mediaObjects;   
   for ( MLMediaObject * mediaObject in mediaObjects )
   {
   if ( mediaObject.mediaType != MLMediaTypeImage )
   // we still get movies as mediaObjects, which might be contained 
in a Photos album
   continue;

   NSURL * url  = mediaObject.URL;
   [photoPaths_ addObject: url.path];
   }
   }
}


Again, I checked with a log message that the KVO never gets invoked in the case 
when the screen saver hangs
(i.e., I am positive the hanging is not caused by an infinite loop or similar 
in the KVO.)




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: CALayer kCAGravityResizeAspectFill and kCAGravityTop

2016-09-21 Thread David Duncan

> On Sep 21, 2016, at 11:44 AM, Torsten Curdt  wrote:
> 
> There isn’t an option to fill width and align top. The more general 
> recommendation in this space however would be to use a UIImageView, which has 
> all the same options but participates in higher level layout (including the 
> content of autoResizingMasks, and also auto layout).
> 
> I am using the layer as a mask - so the UIImageView isn't really an option.

Its still an option, especially if you are otherwise using UIViews – 
UIView.maskView would do the trick.

> BUT I just found that adjusting the contentsRect to the right ratio does the 
> trick.

If you are going to do that, you might as well just calculate the aspect ratio 
as well.

Keep in mind that if the image you are using as a mask is not fully under your 
control, you will also have to adapt for the image orientation – if the image 
is not oriented up, then you need to rotate as well.

> 
> cheers,
> Torsten

--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: CALayer kCAGravityResizeAspectFill and kCAGravityTop

2016-09-21 Thread Torsten Curdt

>
> There isn’t an option to fill width and align top. The more general
> recommendation in this space however would be to use a UIImageView, which
> has all the same options but participates in higher level layout (including
> the content of autoResizingMasks, and also auto layout).
>

I am using the layer as a mask - so the UIImageView isn't really an option.
BUT I just found that adjusting the contentsRect to the right ratio does
the trick.

cheers,
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: CALayer kCAGravityResizeAspectFill and kCAGravityTop

2016-09-21 Thread David Duncan


> On Sep 21, 2016, at 11:18 AM, Torsten Curdt  wrote:
> 
> On iOS I want to fill a layer with an image.
> The width should be filled and the image should retain its aspect ratio.
> This
> 
>layer.contents = image.cgImage
>layer.contentsGravity = kCAGravityResizeAspectFill
> 
> almost does the right thing - but it positions the image at the centers.
> I would like to have it positioned at the top.

There isn’t an option to fill width and align top. The more general 
recommendation in this space however would be to use a UIImageView, which has 
all the same options but participates in higher level layout (including the 
content of autoResizingMasks, and also auto layout).

> 
> While looking at the docs for CALayer I found "autoresizingMask" but that
> seems to be macOS only.
> 
> Any pointers?
> 
> cheers,
> Torsten
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

CALayer kCAGravityResizeAspectFill and kCAGravityTop

2016-09-21 Thread Torsten Curdt

On iOS I want to fill a layer with an image.
The width should be filled and the image should retain its aspect ratio.
This

layer.contents = image.cgImage
layer.contentsGravity = kCAGravityResizeAspectFill

almost does the right thing - but it positions the image at the centers.
I would like to have it positioned at the top.

While looking at the docs for CALayer I found "autoresizingMask" but that
seems to be macOS only.

Any pointers?

cheers,
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to update UI from a background thread

2016-09-21 Thread Jens Alfke

> On Sep 21, 2016, at 10:13 AM, Doug Hill  wrote:
> 
> The symptoms you mention sound like a classic deadlock problem. That is, a 
> code block running on the main queue schedules another code block on the main 
> queue, but the original block never completes thus causing the app to hang or 
> the new task never runs.

Worth noting that this can only occur if both of the cross-thread dispatches 
are synchronous. As long as one of them is async, there will be no deadlock. 
This is a very good reason for preferring async dispatches! If you need to 
return a value back to the original thread, or just perform something after the 
UI update finishes, the idiom is to issue another (nested) dispatch_async at 
the end of the first block, dispatching back to the background thread. That 
nested block can then perform the response/cleanup actions.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to update UI from a background thread

2016-09-21 Thread David Hoerl


> How can I update my UI from a background thread?
>
> I have a method that does a LOT of intense processing, it calls a 
delegate method in my Window Controller which appends it to a Logging 
Scroll View, however nothing shows up in the Scroll View although it 
NSLog’s the string ok.


---

There are two components to your "updating the UI". One is creating a 
tree of views and subviews, the second actually showing them in the UI.


What's p-reviously worked for me is doing the creation in a background 
thread, and when all is done adding these views as subviews of a visible 
view. Not that I've ever seen this as a sanctioned technique by Apple, 
its just worked for me in shipping apps.


David
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to update UI from a background thread

2016-09-21 Thread Doug Hill

> On Sep 21, 2016, at 10:00 AM, Quincey Morris 
>  wrote:
> 
> On Sep 21, 2016, at 09:20 , Dave  wrote:
>> 
>> The time consuming method I am calling is in a third party library and it 
>> must be called in the main thread. 
> 
> You cannot update UI on a background thread, so if the library method is 
> blocking the main thread you’re out of luck. The only solution is to get the 
> library author to write proper code.
> 
> If the library method is running on the main thread and calling back to a 
> block of your code (which sounds like the case), then it’s safe execute code 
> that issues UI updates, but you likely won’t see the results until later, 
> after your app returns to the main event loop.
> 
> If a time-consuming operation *is* running on a background thread, it can 
> dispatch_async a block to the main thread to update the UI, but then you must 
> consider thread safety, if the update is referencing data that’s still being 
> modified as the background thread continues to run.

As Quincy accurately describes, it is well documented you can’t do any UI 
updates on anything other than the main queue/thread. 

https://developer.apple.com/reference/uikit

Which is why your 3rd-party library has this requirement and why CALayer is 
complaining. So, your UI update needs to be called on the main queue as well.

Sandor’s suggestion to put your UI update code on a block that’s executed 
sometime later on the main queue SHOULD work as it just delays your code until 
the queue finishes it’s currently executing tasks. The symptoms you mention 
sound like a classic deadlock problem. That is, a code block running on the 
main queue schedules another code block on the main queue, but the original 
block never completes thus causing the app to hang or the new task never runs. 
It could well be that there is a bug in the library you’re using that causes it 
to block the main queue. But it’s probably good to make sure your code is doing 
the right thing. Perhaps there’s another issue that’s causing the problems you 
see. Maybe you could provide some code for the case where you use the 
dispatch_async technique below to accomplish your task and when you don’t and, 
what happens in each case.

Doug Hill
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to update UI from a background thread

2016-09-21 Thread Jens Alfke

> On Sep 21, 2016, at 8:40 AM, Dave  wrote:
> 
> How can I update my UI from a background thread?

You can’t literally do that. But you can schedule code to run on the main 
thread, and update the UI in that code. Use dispatch_async to schedule the 
UI-related code on the main thread/queue. Or if you’re feeling old-school, use 
-performSelectorOnMainThread:.

Even so, it’s a better design to decouple the UI-related code from the worker 
code. For instance you could have the worker code post a notification that the 
UI code can observe. Since the notification will get delivered on the worker 
thread, the UI code’s observer method should use the techniques above to tell 
itself to do the work on the main thread.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to update UI from a background thread

2016-09-21 Thread Quincey Morris

On Sep 21, 2016, at 09:20 , Dave  wrote:
> 
> The time consuming method I am calling is in a third party library and it 
> must be called in the main thread. 

You cannot update UI on a background thread, so if the library method is 
blocking the main thread you’re out of luck. The only solution is to get the 
library author to write proper code.

If the library method is running on the main thread and calling back to a block 
of your code (which sounds like the case), then it’s safe execute code that 
issues UI updates, but you likely won’t see the results until later, after your 
app returns to the main event loop.

If a time-consuming operation *is* running on a background thread, it can 
dispatch_async a block to the main thread to update the UI, but then you must 
consider thread safety, if the update is referencing data that’s still being 
modified as the background thread continues to run.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to update UI from a background thread

2016-09-21 Thread Dave

Hi,

This doesn’t work probably because the Class is that is calling back the 
delegate method that updates the Scroll View is also being run on the main 
thread. Sorry I should have said this earlier. I tried updating the UI on a 
background thread and it seemed to work BUT I got warning message from CALayer 
or maybe CATransaction and I think it caused the App to hang.

The time consuming method I am calling is in a third party library and it must 
be called in the main thread. 

All the Best
Dave

> On 21 Sep 2016, at 17:01, Sandor Szatmari  
> wrote:
> 
> In general, one simple form is:
> 
> dispatch_async( dispatch_get_main_queue(), ^{
> // do UI updates on the main thread.
> });
> 
> This can also be done with NSOperationQueue:
> 
> [[NSOperationQueue mainQueue] addOperationWithBlock:^{
> // do UI updates on main thread.
> }];
> 
> Sandor Szatmari
> 
> On Sep 21, 2016, at 11:40, Dave  > wrote:
> 
>> Hi All,
>> 
>> How can I update my UI from a background thread?
>> 
>> I have a method that does a LOT of intense processing, it calls a delegate 
>> method in my Window Controller which appends it to a Logging Scroll View, 
>> however nothing shows up in the Scroll View although it NSLog’s the string 
>> ok.
>> 
>> Firstly is it ok to do this? When I tried it I got a CALayer error reported 
>> in the NSLog output.
>> 
>> All the Best
>> Dave
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
>> )
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
>> 
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
>>  
>> 
>> 
>> This email sent to admin.szatmari@gmail.com 
>> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to update UI from a background thread

2016-09-21 Thread Sandor Szatmari

In general, one simple form is:

dispatch_async( dispatch_get_main_queue(), ^{
// do UI updates on the main thread.
});

This can also be done with NSOperationQueue:

[[NSOperationQueue mainQueue] addOperationWithBlock:^{
// do UI updates on main thread.
}];

Sandor Szatmari

> On Sep 21, 2016, at 11:40, Dave  wrote:
> 
> Hi All,
> 
> How can I update my UI from a background thread?
> 
> I have a method that does a LOT of intense processing, it calls a delegate 
> method in my Window Controller which appends it to a Logging Scroll View, 
> however nothing shows up in the Scroll View although it NSLog’s the string ok.
> 
> Firstly is it ok to do this? When I tried it I got a CALayer error reported 
> in the NSLog output.
> 
> All the Best
> Dave
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

How to update UI from a background thread

2016-09-21 Thread Dave

Hi All,

How can I update my UI from a background thread?

I have a method that does a LOT of intense processing, it calls a delegate 
method in my Window Controller which appends it to a Logging Scroll View, 
however nothing shows up in the Scroll View although it NSLog’s the string ok.

Firstly is it ok to do this? When I tried it I got a CALayer error reported in 
the NSLog output.

All the Best
Dave


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Conditionally declaring a BOOL in a .m file to be accessed in a .c function

2016-09-21 Thread Alex Zavatone

Please ignore those last two messages.   An offline device just came on and 
those were sent last night.

Thanks.

On Sep 20, 2016, at 11:04 PM, Alex Zavatone wrote:

> Unknown type.  But bool works.
> 
> Thanks, Ryan.  

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Conditionally declaring a BOOL in a .m file to be accessed in a .c function

2016-09-21 Thread Alex Zavatone

Unknown type.  But bool works.

Thanks, Ryan.  

Sent from my iPad. Please pardon typos.

On Sep 20, 2016, at 11:58 AM, Ryan Dignard  wrote:

> This doesn't work?
> in the .m file at file scope
> BOOL condition = NO;
> 
> in the .c file at file scope
> extern BOOL condition;
> 
> On Tue, Sep 20, 2016 at 8:14 AM, Alex Zavatone  wrote:
>> I've been beating my head against the wall on this one.
>> 
>> I'm trying to evaluate a condition and declare or conditionally #define a 
>> macro within an Objective-C method function that can be checked within a c 
>> function.
>> 
>> Ideally, I'd just like a #define, but this
>>  like it to be a BOOL or, since this is going to be checked in c, a bool.
>> 
>> I've tried all sorts of combinations of #define and extern and checking with 
>> #if and #ifdef if I can even get this to compile.
>> 
>> The C file can't import the header of the Obj-C file or else I've got a few 
>> hundred errors on my hands.
>> 
>> I can't even get the #define to be recognized in the C file.
>> 
>> Any pointers here on how to proceed?
>> 
>> Goal:
>> I'm looking to declare or define a "thing" from a .m method that is scoped 
>> so that it can be checked within a c file that can not import the .h file 
>> for that .m file.
>> 
>> Will I need an intermediate file and class for this?
>> 
>> Thanks.
>> Alex Zavatone
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/conceptuallyflawed%40gmail.com
>> 
>> This email sent to conceptuallyfla...@gmail.com
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Conditionally declaring a BOOL in a .m file to be accessed in a .c function

2016-09-21 Thread Alex Zavatone

OK.  So how do I change that bool within a method in that .m file as the result 
of a condition?

Thanks.

Sent from my iPad. Please pardon typos.

On Sep 20, 2016, at 11:58 AM, Ryan Dignard  wrote:

> This doesn't work?
> in the .m file at file scope
> BOOL condition = NO;
> 
> in the .c file at file scope
> extern BOOL condition;
> 
> On Tue, Sep 20, 2016 at 8:14 AM, Alex Zavatone  wrote:
>> I've been beating my head against the wall on this one.
>> 
>> I'm trying to evaluate a condition and declare or conditionally #define a 
>> macro within an Objective-C method function that can be checked within a c 
>> function.
>> 
>> Ideally, I'd just like a #define, but this
>>  like it to be a BOOL or, since this is going to be checked in c, a bool.
>> 
>> I've tried all sorts of combinations of #define and extern and checking with 
>> #if and #ifdef if I can even get this to compile.
>> 
>> The C file can't import the header of the Obj-C file or else I've got a few 
>> hundred errors on my hands.
>> 
>> I can't even get the #define to be recognized in the C file.
>> 
>> Any pointers here on how to proceed?
>> 
>> Goal:
>> I'm looking to declare or define a "thing" from a .m method that is scoped 
>> so that it can be checked within a c file that can not import the .h file 
>> for that .m file.
>> 
>> Will I need an intermediate file and class for this?
>> 
>> Thanks.
>> Alex Zavatone
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/conceptuallyflawed%40gmail.com
>> 
>> This email sent to conceptuallyfla...@gmail.com
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Passing param by reference then using within block throws exception

2016-09-21 Thread Steve Mills


On Sep 21, 2016, at 08:53 AM, Alex Zavatone  wrote:

Stab in the dark here, but I'm stabbing blank. Is there an Instruments tool or debugging option to detect this? 


Thanks for getting stabby. Fourvel appreciates it (only relevant if you're a 
CBB fan). It doesn't appear that anything will detect this. When zombies is on, 
it says an address is attempting to be retained but was previously released. 
That's a bit of a red herring, since the only 2 variables being uses have just 
been declared and initialized right before the call to the method. If anything, 
the process of converting to ARC or the static analyzer should've flagged this 
as a problem.

Sent from iCloud's ridiculous UI, so, sorry about the formatting

 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Passing param by reference then using within block throws exception

2016-09-21 Thread Alex Zavatone

Stab in the dark here, but I'm stabbing blank.  Is there an Instruments tool or 
debugging option to detect this?  

On Sep 21, 2016, at 7:53 AM, Steve Mills wrote:

> On Sep 21, 2016, at 01:29:37, Jens Alfke  wrote:
>> 
>> I think the real problem is that the -enumerateObjectsUsingBlock: method has 
>> an autorelease pool. If your real code is assigning something other than a 
>> string constant to *fillMeIn, that string will probably get dealloced when 
>> the autorelease pool drains. Your workaround is correct, since assigning the 
>> string to noFillMeIn causes it to be retained.
> 
> Perhaps, but that couldn't be the cause of the crash. I might not have been 
> totally clear, but the crash happens while setting up to call the method, not 
> inside the method or after it returns.
> 
> --
> Steve Mills
> Drummer, Mac geek
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Passing param by reference then using within block throws exception

2016-09-21 Thread Steve Mills

On Sep 21, 2016, at 01:29:37, Jens Alfke  wrote:
> 
> I think the real problem is that the -enumerateObjectsUsingBlock: method has 
> an autorelease pool. If your real code is assigning something other than a 
> string constant to *fillMeIn, that string will probably get dealloced when 
> the autorelease pool drains. Your workaround is correct, since assigning the 
> string to noFillMeIn causes it to be retained.

Perhaps, but that couldn't be the cause of the crash. I might not have been 
totally clear, but the crash happens while setting up to call the method, not 
inside the method or after it returns.

--
Steve Mills
Drummer, Mac geek

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to Launch an App using the Bundle ID?

2016-09-21 Thread Dave

Hi,

Thanks a lot! I was surprised that NSWorkspace doesn’t include this seemingly 
useful method.

All the Best
Dave



> On 20 Sep 2016, at 16:16, Charles Srstka  wrote:
> 
>> On Sep 20, 2016, at 5:48 AM, Dave > > wrote:
>> 
>> Hi All,
>> 
>> 
>> I’m using launchApplication method from Shared Workspace, however, it accept 
>> an Application Name and all I have is the Bundle ID. How can I launch an App 
>> using the Bundle ID?
>> 
>> All the Best
>> Dave
> 
> Get the URL of the application by using -[NSWorkspace 
> URLForApplicationWithBundleIdentifier:], then launch the application by the 
> URL.
> 
> Charles
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

50 matches

Mail list logo