Lifecycle for custom NSURLProtocol properties

2016-09-26 Thread Allan Odgaard 
I am making use of NSURLProtocol’s `setProperty:forKey:inRequest:` but 
it seems that my custom properties outlive the URL request, and even if 
I explicitly call `removePropertyForKey:inRequest:` after my request is 
done, it would appear that my properties are still being retained by 
something.


I guess this is a bit of a black box, but does anyone have any 
info/experience with this?

___

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-26 Thread Britt Durbrow 
FWIW, it’s currently an implementation detail that SELs do map into the global 
address space in a way that doesn’t collide with anything else; but 
technically, they are in their own address space and the system could map them 
otherwise in a manner that does have collisions with other stuff.

In practice, I don’t think that will ever happen, because a) too much existing 
code makes the assumption that a SEL is de-referenceable or otherwise depends 
on this implementation detail; and b) we have 64-bit addressing, so we’re not 
going to run out of address space such that making that change would be 
advantageous.


> On Sep 26, 2016, at 6:17 PM, Slipp Douglas Thompson 
>  wrote:
> 
> I'm just going to throw this out there as a solution, not because I recommend 
> this approach (it's API misuse after all) but because it would work.
> 
> Instead of using an `NSString *` you could use a `SEL` (AKA `struct 
> objc_selector *`) since SELs are guaranteed to be unique for each given 
> string they represent (within a process; AFAIR).
> 
> So your code would become:
> 
>   if (context == @selector(mediaLibraryLoaded))
>   {
>   // …
> 
> Or in Swift:
> 
>   if context == Selector("mediaLibraryLoaded")
>   {
>   // …
> (Swift's `Selector.init(_ str:String)` implementation 
>   
> >
>  just calls `sel_registerName` and (curiously) treats the returned pointer as 
> a C-string.)
> 
> Again, this is a blatant mis-use of the Objective-C API… but it is also a 
> built-in compiler-optimized guaranteed-interned string, it won't cause issues 
> when comparing to other arbitrary `void *`s, and the usage in Swift is almost 
> identical to Objective-C.
> 
> 
> 
> 
> 
> My 2¢: I'm still in favor of making all usages of `context` in your app 
> `NSObject *`s or `nil` because sometimes you do want to store an 
> `NSDictionary *` or other data in `context` that's meant to be read later.  
> But if you're stuck with using other libs that don't use `NSObject *`s or 
> `nil`, or if you really want to ensure your code won't crash because its 
> making assumptions about what's in the  `context` your code registered, then 
> I acknowledge your case.  Key point: I personally wouldn't use the `SEL` 
> approach, but still.
> 
> — 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: XCode documentation browser

2016-09-26 Thread Graham Cox 

> On 27 Sep 2016, at 11:01 AM, Graham Cox  wrote:
> 
> the browser has started to open everything in Safari


Never mind; re-downloading the doc sets has fixed it.

—G.
___

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-26 Thread Slipp Douglas Thompson 
I'm just going to throw this out there as a solution, not because I recommend 
this approach (it's API misuse after all) but because it would work.

Instead of using an `NSString *` you could use a `SEL` (AKA `struct 
objc_selector *`) since SELs are guaranteed to be unique for each given string 
they represent (within a process; AFAIR).

So your code would become:

if (context == @selector(mediaLibraryLoaded))
{
// …

Or in Swift:

if context == Selector("mediaLibraryLoaded")
{
// …
(Swift's `Selector.init(_ str:String)` implementation 

 just calls `sel_registerName` and (curiously) treats the returned pointer as a 
C-string.)

Again, this is a blatant mis-use of the Objective-C API… but it is also a 
built-in compiler-optimized guaranteed-interned string, it won't cause issues 
when comparing to other arbitrary `void *`s, and the usage in Swift is almost 
identical to Objective-C.





My 2¢: I'm still in favor of making all usages of `context` in your app 
`NSObject *`s or `nil` because sometimes you do want to store an `NSDictionary 
*` or other data in `context` that's meant to be read later.  But if you're 
stuck with using other libs that don't use `NSObject *`s or `nil`, or if you 
really want to ensure your code won't crash because its making assumptions 
about what's in the  `context` your code registered, then I acknowledge your 
case.  Key point: I personally wouldn't use the `SEL` approach, but still.

— Slipp



> On Sep 24, 2016, at 12:34 AM, Graham Cox  wrote:
> 
> 
>> On 24 Sep 2016, at 12:13 PM, Uli Kusterer  
>> wrote:
>> 
>>> 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.
>> 
>> No, Graham, don't do that!
>> 
>> There is no guarantee that the context is a valid object. It is just 
>> supposed to be a unique pointer value so your class can tell a KVO 
>> notification from notifications for other observers on the same object (e.g. 
>> if a subclass observes the same value as a base class).
> 
> 
> Yep, I’ve realised (from this discussion) that that’s an invalid assumption 
> of another kind.
> 
> I’ve been revising code that does this as a result.
> 
> Always something to learn :)
> 
> —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/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

XCode documentation browser

2016-09-26 Thread Graham Cox 
Forgive this non-Cocoa question, but I’m sure the learned folks on this list 
will be much quicker at pinpointing the issue….

I’m using XCode 7.3.1 on OSX 10.11.6. The built-in documentation browser has 
always worked fine, and I usually download the doc sets locally so that it’s 
reasonably fast and not relying on the network.

Just this last week, the browser has started to open everything in Safari, 
directly referencing online documentation. Why? How can I put it back to 
working the way I want it to? AFAIK, I didn’t do anything to change any 
settings.

—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-26 Thread Britt Durbrow 

> On Sep 26, 2016, at 3:31 AM, Slipp Douglas Thompson 
>  wrote:
> 
> I'm sorry if I'm not up to snuff on compiler architecture, but how would a 
> pointer to the memory address of that same pointer ever collide with any 
> other pointer?

When ***Somebody*** is Doing It Wrong.

Having been bitten before by this phenomenon (i.e, others doing bizarre, 
illogical things; often in oddball close-source code libraries and/or drivers); 
I felt compelled to point out that non-collision wasn’t an *absolute* 
guarantee, but rather just a reasonable assumption *almost* always.

In other words, just when you think you’ve got it Idiot Proof, somebody goes 
and invents a better Idiot…

:-)

>  Only one thing may exist at at time at a given memory address, so— yes, if 
> you're assigning arbitrary values into a pointer instead of an actual valid 
> memory address you could have a problem, but that usage in itself is the 
> smell.

It’s not *you* - the good, sane programmer - who’s doing that. It’s the other 
guy who’s Doing It Wrong… but it shows up as misbehavior in *your* code, 
leading *you* to tear your hair out.

And yes, the malodorousness of that code is positively wretched… 8-p


Alternatively, a memory scribbler or leakage via an improperly initialized 
variable may induce similar misbehavior (so, one should not assume that just 
because it *shouldn’t* happen under sane circumstances, that it *can’t* when 
facing a bug). 

:-)
___

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-26 Thread Fritz Anderson 
On 23 Sep 2016, at 9:49 PM, Uli Kusterer  wrote:
> 
> Are you sure? I only learned Cocoa when it came to OS X, but my impression 
> was that, while KVC came from NeXT, KVO arrived with bindings … that would 
> have been 10.3 or 10.4-ish?

As I remember, when KVO was introduced, it was framed as a bottleneck for 
implementing bindings. Foundation exposed it as a courtesy to developers who 
would find it useful in itself.

Cocoa practice has changed since then, but that’s what I gathered at the time.

You’re right, KVC was NeXTStep. The patent on it was one of NS/Apple’s crown 
jewels.

— F

___

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: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-26 Thread Markus Spoettl 
It is an OSX Cocoa GUI application. I have always started it from the command 
line by executing the executable inside the bundle. While this always worked, it 
no longer seems to.


That said, it didn't occur to me that there's a proper way, by using the "open" 
command. Thanks for the tip, this works nicely for my purposes!


Regards
Markus

On 26/09/16 19:18, Gary L. Wade wrote:

In what way did you start your app from the Terminal?  Is this
WindowServer-based or a command line app?  Not sure your purpose in starting
from the command line if WindowServer-based, but have you tried launching it
with the open command where the argument is the .app bundle vs possibly another
way like the actual executable?
--
Gary L. Wade
http://www.garywade.com/


On Sep 26, 2016, at 2:44 AM, Markus Spoettl > wrote:

I'm using SecStaticCodeCheckValidity() to self check the signature of my own
app when it is launched. This works fine and always has.

All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only
if the application) is started from the Terminal. When I start the very same
app from the Dock or from the Finder the check succeeds (iow. the call returns
noErr).

I don't know exactly when it started failing. I only know it definitely worked
before on previous versions of El Capitan but now it no longer does (v 10.11.6).

Any ideas?

Regards
Markus
--
__
Markus Spoettl
___

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/garywade%40desisoftsystems.com

This email sent to garyw...@desisoftsystems.com





--
__
Markus Spoettl
___

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-26 Thread Quincey Morris 
On Sep 26, 2016, at 02:45 , Britt Durbrow 
 wrote:
> 
>>  void *kMyContext = 
>> 
>> is *guaranteed* to give you a unique address that nobody else's object may 
>> occupy?
>> 
> 
> Splitting hairs, but that’s not ***guaranteed*** - just super highly unlikely 
> to have a collision.

If you’re going to split hairs, you shouldn’t leave out half the words (“ that 
nobody else's object may occupy”). Regardless of whether you take “object” in 
the Obj-C sense or the C spec sense, no other object is going to have the same 
address. The weaker condition of a unique *pointer* can’t be guaranteed, since 
C allows any bit pattern to be cast to a pointer (as in your example).

> Also, FWIW, even declaring a single pointer variable in the global space that 
> isn’t used as an actual variable strikes me as a bit of a code smell

But if I use the above construct, then I use “kMyContext” as my context, not 
“”:

>   if (context != kMyContext) { [super observeValueForKeyPath: …]; return; 
> }


In that case, I really am using the value of the variable.

___

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: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-26 Thread Gary L. Wade 
In what way did you start your app from the Terminal?  Is this 
WindowServer-based or a command line app?  Not sure your purpose in starting 
from the command line if WindowServer-based, but have you tried launching it 
with the open command where the argument is the .app bundle vs possibly another 
way like the actual executable?
--
Gary L. Wade
http://www.garywade.com/ 
> On Sep 26, 2016, at 2:44 AM, Markus Spoettl  wrote:
> 
> I'm using SecStaticCodeCheckValidity() to self check the signature of my own 
> app when it is launched. This works fine and always has.
> 
> All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only 
> if the application) is started from the Terminal. When I start the very same 
> app from the Dock or from the Finder the check succeeds (iow. the call 
> returns noErr).
> 
> I don't know exactly when it started failing. I only know it definitely 
> worked before on previous versions of El Capitan but now it no longer does (v 
> 10.11.6).
> 
> Any ideas?
> 
> Regards
> Markus
> -- 
> __
> Markus Spoettl
> ___
> 
> 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/garywade%40desisoftsystems.com
> 
> This email sent to garyw...@desisoftsystems.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: Question about Swift 3 and AWS

2016-09-26 Thread Quincey Morris 
On Sep 26, 2016, at 09:44 , Jim Adams  wrote:
> 
> Not sure if this is the right list but I thought I would try. I was thinking 
> of using Swift 3 for some server side work.

The best place to ask is probably over at swift.org :

https://swift.org/community/#mailing-lists 


___

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: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-26 Thread Markus Spoettl 

On 26/09/16 15:16, Steve Christensen wrote:

What is the error code when it fails?


OSStatus is -67054, which is errSecCSBadResource. Only happens when launched 
from the command line.


Markus

--
__
Markus Spoettl
___

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

Question about Swift 3 and AWS

2016-09-26 Thread Jim Adams 
Not sure if this is the right list but I thought I would try. I was thinking of 
using Swift 3 for some server side work. I know that BlueMix is out there for 
the IBM Cloud but I live in the Amazon cloud. I was wondering if anyone had 
thought about porting the aws-sdk from Java to Swift?


Jim Adams
SAS Customer Intelligence 360



___

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: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-26 Thread Steve Christensen 
What is the error code when it fails?


> On Sep 26, 2016, at 2:44 AM, Markus Spoettl  wrote:
> 
> I'm using SecStaticCodeCheckValidity() to self check the signature of my own 
> app when it is launched. This works fine and always has.
> 
> All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only 
> if the application) is started from the Terminal. When I start the very same 
> app from the Dock or from the Finder the check succeeds (iow. the call 
> returns noErr).
> 
> I don't know exactly when it started failing. I only know it definitely 
> worked before on previous versions of El Capitan but now it no longer does (v 
> 10.11.6).
> 
> Any ideas?
> 
> Regards
> Markus


___

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-26 Thread Britt Durbrow 
> 
>   void *kMyContext = 
> 
> is *guaranteed* to give you a unique address that nobody else's object may 
> occupy?
> 

Splitting hairs, but that’s not ***guaranteed*** - just super highly unlikely 
to have a collision.

There’s never any guarantee that somebody else isn’t Doing It Wrong (TM).

Some yahoo sticking something like this in their framework or plugin could well 
create havoc, should you get unlucky…

void *thisWillNeverCollideWithAnything = 0x00010003b568LL; // Yeah, right! 
And I gotta bridge to sell you!







Also, FWIW, even declaring a single pointer variable in the global space that 
isn’t used as an actual variable strikes me as a bit of a code smell…. perhaps 
this is something that there should be a compiler extension for… something like 
this, maybe:

NS_UNIQUE_TOKEN(myContext);

which would resolve to:

static const void *myContext __attribute__((uniqueToken));

and that attribute would cause the pointer to be given a unique address by the 
linker (i.e, no hazard of coalescing), without the physical RAM actually being 
allocated for it (or, alternatively, perhaps all unique tokens could just be 
lumped together in a separate page, so that if the OS is doing lazy RAM 
allocation, that page - because it should never be de-referenced - never gets 
physically allocated).

or Swiftly,

uniqueToken myContext; // no ‘let’ here because I think it would be unnecessary 
and awkward; as there is no initializer half to the statement.

:-)
___

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

SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-26 Thread Markus Spoettl 
I'm using SecStaticCodeCheckValidity() to self check the signature of my own app 
when it is launched. This works fine and always has.


All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only if 
the application) is started from the Terminal. When I start the very same app 
from the Dock or from the Finder the check succeeds (iow. the call returns noErr).


I don't know exactly when it started failing. I only know it definitely worked 
before on previous versions of El Capitan but now it no longer does (v 10.11.6).


Any ideas?

Regards
Markus
--
__
Markus Spoettl
___

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