Re: Users default alert sound

[Britt Durbrow]

Also, not everyone *has* a sound that plays… if the volume is turned all the 
way down, or if they have a hearing issue, for example, they will often have 
the screen flash turned on; calling NSBeep() triggers this correctly.



> On Dec 14, 2016, at 10:51 AM, Sandor Szatmari  
> wrote:
> 
> I didn't know that automatically played the configured sound.  That's great 
> thanks!  I knew I was missing something straightforward.
> 
> Sandor
> 
>> On Dec 14, 2016, at 12:58, Quincey Morris 
>>  wrote:
>> 
>>> On Dec 14, 2016, at 09:45 , Sandor Szatmari  
>>> wrote:
>>> 
>>> I am currently using [NSSound soundNamed:] to play any arbitrary sound.  
>>> But I want to play the one configured in System Preferences.
>> 
>> You can use the NSBeep () global function to play the configured alert 
>> sound. I don’t know if there’s an API to get its file name — it’s not 
>> obvious that it is even a separate file, always.
>> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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

[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: Stupid objective-c question

[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

[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

Re: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Britt Durbrow]

> On Aug 24, 2016, at 12:59 PM, Jeff Szuhay  wrote:
> 
> I draw my images (clocks) into a “reference” sized rectangle—for simplified 
> position calculations—and then have CoreGraphics scale into the destination 
> view rect.

Don’t do that with bitmap scaling. It’s wasteful, and will look bad.

Instead, create the bitmap at the correct size for it’s destination; and use 
the drawing matrix transform functions (scale, translate, rotate, etc) to set 
up your drawing environment.
___

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: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)

[Britt Durbrow]

> On Aug 11, 2016, at 3:32 PM, Sandor Szatmari  
> wrote:
> 
> 1. If at all possible, and within reason, avoid mutable objects in 
> collections (your swift points address this).
> 

It depends on the collection, and how the mutable objects are handling -hash 
and -isEqual:

It’s OK, for example, to use mutable objects as the values in an NSDictionary; 
but can be hazardous when used as the keys.

NSArrays have no problem with mutable objects for most of their methods, 
because they are based on index positions.

NSSets can hiccup quite badly if something mutates unexpectedly.

NSObject, by itself, implements pointer hashing (i.e, -hash is derived from the 
value of self); and pointer comparison (a basic NSObject is only equal to 
itself); so if you don’t override -hash and -isEqual: than any mutability your 
objects might have won’t be visible to the collection objects.

> 2. You really need to be overtly aware of these details when designing 
> classes and implementing -hash and -isEqual:

And when using them in collections, even if you are just using the stock Cocoa 
value classes!

:-)
___

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: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)

[Britt Durbrow]

> I didn’t realize that I was saying anything controversial.


Oh, it’s usually the most innocuous seeming of things that ignite the biggest 
firestorms… :-)


> On Aug 11, 2016, at 11:11 AM, Quincey Morris 
>  wrote:
> 
> “Stored in” is incorrect. What’s stored is an implementation detail. It’s 
> only the outward-facing values that matter. I believe your extension is also 
> technically false. See below.

Hmm… at the risk of being accused of splitting hairs here… *how* it’s stored in 
the object is the implementation detail, that it *is* stored in it is what 
matters (where by the definition of “stored in it” means that you can access it 
via an accessor or instance variable; I am deliberately not considering stuff 
like associated metadata that physically resides in an otherwise unattached 
location to be "stored in it", because doing so makes the underlying 
assumptions of object identity and boundaries start to break down).

> AFAIK, the only constraint is the one documented in the NSCopying protocol, 
> which was already quoted in this thread:

If your object conforms to the NSObject protocol, then that does impose 
additional restrictions. If it doesn’t, then all bets are off; as it’s totally 
outside of the scope of the Cocoa frameworks (i.e, it descends from some other 
non-NSObject root object).

>> Are there any real world examples of this in the Cocoa flora of objects?
> 
> 
> My example of an object that carries around its own creation date for 
> debugging purposes isn’t exactly an unreal world example.
> 


I generally don’t consider things done for debugging purposes in these sorts of 
discussions, because there’s lots of nasty hacks that are done to elucidate why 
the system is not behaving as expected (for example, I happen to have open in 
Xcode at the moment a snippet that cracks NSUndoManager wide open, so I can see 
just what I did wrong - TOTALLY a no-no for production code!). Also, if you did 
do something like that, you’d probably make sure that hash and isEqual ignored 
it, so as not to upset the rest of the frameworks.


Ignoring the above caveat about debug stuff; in the specific example of the 
creation date; I don’t consider creating an object (for whatever reason) that 
has some property different than the original to be compliant with NSCopying’s 
requirement of "with values identical to the original at the time the copy was 
made”.



> If you copied a NSNumber or NSString instance that happened not to be a 
> tagged pointer, but could be, it might be desirable for the ‘copy’ method to 
> detect the situation and return a tagged pointer.
> 

Desirable, but not mandatory: I say it’s still legal to return [self retain]. 
However, FWIW, I will mention that tagged pointers are reserved for the 
exclusive implementation by Apple; and involve some serious Dark Magic (tm) 
deep in the runtime (i.e, it required the co-opting and co-operation of 
objc_msgSend).



> Finally, the point of copy-by-incrementing-the-reference-count behavior is 
> *not* to make copying of objects practically free. The point is to make *a 
> copy of a copy* practically free. We often don’t know what object we’re 
> copying in the first place (we might be passed a NSString* parameter, but it 
> might actually be a NSMutableString instance), so the original copy might be 
> expensive.

And considering how often things get copied in the Cocoa frameworks, that’s 
kinda’ a big deal optimization. :-)


And from the next posting:


> 2. Since there is no *formal* distinction between mutable and immutable 
> objects, there is no formal constraint on either of:

Yeah, Cocoa specification itself is kinda’ wishy-washy about that (probably for 
reasons of expediency and flexibility). However, if we accept the common 
definition of immutable as "that which cannot change”; then in combination with 
several other factors, it becomes evident that for all immutable objects you 
can just return [self retain]… here’s my logic:

Given that:

"a copy must be a functionally independent object with values identical 
to the original at the time the copy was made”;

by definition, an object is equal to itself;

"functionally independent” means that no matter what you do to the 
original, there will be no effects on the copy;

immutable objects by definition can’t change (otherwise they would be 
mutable objects);

objects that can’t change can’t have any effects put upon them, because 
any effect is by definition a change;

it follows that the original object, due to it’s immutability, is functionally 
independent to itself… and as a consequence of that, an immutable object is a 
valid copy of itself.

Therefore:

@implementation myImmutableClass 

- (id)copyWithZone:(NSZone *)zone
{
return [self retain]; // non-ARC, 

Re: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)

[Britt Durbrow]

> On Aug 11, 2016, at 12:04 AM, Quincey Morris 
>  wrote:
> 
> 2. The fact than an object is immutable does not (in general) mean that a 
> copy can be represented by the same object reference. For example, an object 
> that contained its own date of creation might be immutable, but a copy might 
> have a different date, and therefore be a different object. Putting this 
> another way, the immutability does not make NSCopying conformance irrelevant.

Hmm… I’m not so sure that this is *quite* right… what if I want a copy of the 
original object, with the same creation date? Not doing so could lead to some 
strange pitfalls, depending on what is then done with the alleged “copy”, and 
how it reacts to other methods (like -hash and -isEqual, or any sort of 
serialization methods it implements).

From the documentation:

"The exact meaning of “copy” can vary from class to class, but a copy must be a 
functionally independent object with values ___identical___ to the original at 
the time the copy was made.” (emphasis mine)

Which, IMHO, means that *all* the values stored in the object must be the same.

By extension; [anObject hash] and [[anObject copy] hash] must return the same 
value; and [anObject isEqual:[anObject copy]] must return YES.

For the case of an immutable object, those conditions are indeed fulfilled by 
simply returning self; because by definition an immutable object and a copy of 
an immutable object at a different memory address would behave the same, 
forever. Returning self is, in this case, just an implementation detail (an 
optimization, specifically).

It is, however, perfectly valid (if not encouraged for performance and memory 
use reasons) to actually create a new object, with all the same values as the 
original.


At a higher level, instead of having -copy return an object that was *almost* a 
copy; I think I would (if possible) refactor the problem to put that 
information somewhere else… or better yet, don’t do that at all (and given that 
copies come and go; I don’t think that non-invariant metadata like that is 
going to do what is usually desired, in the broader sense of solving the 
problem at hand; whatever problem it may be).
___

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: Core Data or not

[Britt Durbrow]

In general, I agree with what’s been said so far.

About performance:

For the size of the object collection being described, I would tend to think 
that the overhead of keeping track of it shouldn’t be a major factor, no matter 
how you go… modern Mac’s and iOS devices have more than enough CPU power to 
make it disappear in the noise. What you do with it will dominate the 
performance of the resultant app - using a screaming fast record management 
system, collating high-resolution medical images and doing feature recognition 
on them is going to run a lot slower than a recipe list app that uses a dog 
slow record management system, for example.

However, in absolute terms, a custom-tuned solution will outperform a 
runtime-flexible general purpose solution like Core Data (and SQLite, which 
it’s usually running on top of). Assembling fetch requests takes resources 
(CPU, memory, and battery), and because they are interpreted they are slower 
than pre-compiled fetch operations.

For example, suppose that I have a bunch of interestingObjects and I want to 
fetch them from file storage by UUID; and I want to do this as fast as possible 
(all other concerns being secondary). The strategy that I think I would take is 
to create two files, one with a hash table of the UUIDs and offsets into the 
second file, which contains the serialized storage of the interestingObjects 
(and for maximum speed, I would forgo portability in favor of just keeping a 
binary image of the interestingObjects if possible: i.e, write raw structs to 
disk). I would also think about mmap-ing the files into my address space to 
eliminate read() and write() calls.

This would yield the bare minimum overhead to accomplish the goal; at the cost 
of flexibility and portability (and potentially development time, depending on 
how much difficulty one encounters adapting a general purpose solution to the 
specific problem, and how adept one is at doing this sort of raw data structure 
manipulation).

For Core Data to do the same thing, it must parse the data model, construct 
search predicates, translate them into SQL, and hand that off to SQLite; which 
must in turn parse the database structure and “compile” the SQL into an 
actionable set of search operations, interpret that to perform the search, 
assemble the results into it’s buffers, and hand that back off to Core Data; 
which must then translate the SQLite buffers into managed objects (again, 
parsing the data model), and only then can it return the result. Oh, and it’s 
got error checking at every step also.

The direct approach requires calculating a hash (for a UUID, that might be as 
simple as xor-ing the bytes up as 32-bit ints, and doing a modulo operation to 
fit the result to the size of the hash table - but, I have not profiled that 
myself, so I can’t necessarily recommend it - it’s just an example), performing 
some small number of comparisons (ideally, only 1, in the case of a hit on the 
first hash table bucket), and a bit of pointer arithmetic to get the location 
of the storage of the desired object; and doing whatever minimal construction 
is required to turn that stored struct into an actual live interestingObject - 
much less complexity than what Core Data (or any general-purpose system) goes 
through.

Before making any commitments, I would profile all of the choices available to 
you - the above discourse is just a general overview of things; and details 
(and optimizations) matter. Sometimes, the profiler turns up the darnedest of 
results… :-)
___

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: debugging AirDrop (update)

[Britt Durbrow]

FWIW, I have that experience just using Apple’s own apps... It works most of 
the time, but sometimes, it just… doesn’t.

So, it might well not be anything you are doing (or not doing, as the case may 
be).

> On May 27, 2016, at 1:10 PM, Gerriet M. Denkmann  wrote:
> 
> 
>> On 28 May 2016, at 02:06, Jens Alfke  wrote:
>> 
>> File a bug report with Apple!
> 
> Just done.
> 
>> 
>> —Jens (who has intermittent troubles with AirDrop too)
>> 
>>> On May 27, 2016, at 10:47 AM, Gerriet M. Denkmann  
>>> wrote:
>>> 
>>> 
 On 27 May 2016, at 23:18, Steve Christensen  wrote:
 
 I haven't worked with AirDrop, but I just looked at the docs and one of 
 the delegate methods is -sharingService:didFailToShareItems:error:. Maybe 
 if you implement that you can at least see what the specific error is?
 
>>> 
>>> Well, it does not tell anything. Never gets called. The problem: if there 
>>> is no-one found to share things with, then there can be no sharing, and 
>>> thus no errors while sharing.
>>> 
>>> “Invoked when the sharing service encountered an error when sharing items.”
>>> 
>>> But thanks for the suggestion. It is better to have this delegate method 
>>> implemented.
>>> 
>>> Kind regards,
>>> 
>>> Gerriet.
>>> 
>>> 
 
 
> On May 26, 2016, at 10:23 PM, Gerriet M. Denkmann  
> wrote:
> 
> I have an OS X app (10.11.5) which has a button called AirDrop, which 
> does:
> 
> - (IBAction)airDrop: (NSButton *)sender   
> {
>   NSArray *shareItems = list of one or more urls of pdf files
>   NSSharingService *service = [ NSSharingService sharingServiceNamed: 
> NSSharingServiceNameSendViaAirDrop];
>   service.delegate = self;//  probably not needed
>   [service performWithItems:shareItems];
> }
> 
> Usually this just works:
> I click the AirDrop button, a Panel slides down with a picture of the pdf 
> (or a symbol for multiple files if more than one).
> I grab my iPad (which has “AirDrop: Contacts Only" set) and unlock it.
> The AirDrop panel on the Mac shows (after a few seconds) my Mac Login 
> picture, I click it, and all is well.
> 
> Sometimes it does not work correctly:
> In this case I have to set the iPad to “AirDrop: Everyone". A generic 
> user picture will appear on the Mac and it will still work.
> 
> But sometimes it does not work at all: 
> I can do whatever (like restarting the iPad; restarting the Mac) but 
> still no picture of a recipient will appear in the Mac AirDrop Panel. 
> 
> How can I debug this?
> 
> Gerriet.
> 
> Found some log messages, which seem to be related:
> 
> Clicking my AirDrop button:
> 
> 27/05/2016 12:17:41.630 sharingd[17313]: 12:17:41.629 : Bonjour discovery 
> started
> 27/05/2016 12:17:41.662 sharingd[17313]: 12:17:41.662 : BTLE advertiser 
> Powered On
> 27/05/2016 12:17:41.664 sharingd[17313]: 12:17:41.663 : BTLE advertising 
> hashes <01ca38ce b5742b51 4900>
> 27/05/2016 12:17:41.667 sharingd[17313]: 12:17:41.666 : 
> SDBonjourBrowser::failedToStartAdvertisingWithError Error 
> Domain=NSMachErrorDomain Code=8 "(os/kern) no access" 
> UserInfo={NSLocalizedDescription=wirelessproxd can't start advertising at 
> this time.}
> 27/05/2016 12:17:43.720 sharingd[17313]: 12:17:43.719 : 
> SDBonjourBrowser::failedToStartAdvertisingWithError Error 
> Domain=NSMachErrorDomain Code=8 "(os/kern) no access" 
> UserInfo={NSLocalizedDescription=wirelessproxd can't start advertising at 
> this time.}
> 
> Clicking “Cancel" in the AirDrop Panel:
> 
> 27/05/2016 12:19:46.595 AirDrop[17426]: Error in 
> CoreDragRemoveTrackingHandler: -1856
> 27/05/2016 12:19:46.595 AirDrop[17426]: Error in 
> CoreDragRemoveReceiveHandler: -1856
> 27/05/2016 12:19:46.658 sharingd[17313]: 12:19:46.657 : Bonjour discovery 
> stopped
> 27/05/2016 12:19:46.671 sharingd[17313]: 12:19:46.671 : BTLE advertising 
> stopped
> 
> But still don’t know what to do.
> 
> Gerriet.
 
>>> 
>>> 
>>> ___
>>> 
>>> 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/jens%40mooseyard.com
>>> 
>>> This email sent to j...@mooseyard.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 

Re: ARC [was Protecting against "app nap"]

[Britt Durbrow]

If that wasn’t called out clearly in that non-ARC class’s documentation/header, 
then that non-ARC class was Doing It Wrong(tm).


> On May 13, 2016, at 2:55 AM, Dave  wrote:
> 
> Hi,
> 
> The other thing to watch out for is if you have non ARC Classes in your 
> project, you can forget that they are using assign rather than weak for 
> properties (so the reference doesn’t get zeroed) that can lead to sending 
> message to objects that have been destroyed if you are not careful. You have 
> the same problem with Non-ARC of course, but once you have used ARC for a 
> while you tend to forger about the non ARC classes and expect it to work like 
> the rest of your App. I only say this, because I had a nasty bug that took 
> quite a while to find because I was assuming everything was ARC.
> 
> Also I’ve found when converting from Non-ARC to ARC that in doing so can 
> reveal code smells and often you can simplify things…..
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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 keep things alive in Arc?

[Britt Durbrow]

Off of the top of my head, have a look at:

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#precise-lifetime-semantics
 


and

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#interior-pointers 



> On May 8, 2016, at 7:11 PM, Gerriet M. Denkmann  wrote:
> 
> Thing *aThing = [ Thing new ];
> 
> void *thingData = [ aThing data ];//  pointer to a buffer owned by 
> aThing
> 
> … never use aThing after this point → Arc might release aThing right now
> … but do lots of things with thingData
> 
> … no more need for thingData
> [ aThing release];
> 
> How to prevent Arc to release aThing before I have done with thingData?
> 
> Gerriet.
> 
> 
> 
> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: migrating from 32bit to 64 bit can not run project

[Britt Durbrow]

> 
> As for the naming of the NSDocument subclass.  I pretty much rely on online 
> tutorials.  Not sure what ARC is.
> 

Why, it’s’ the answer to the American Dream! It’s the Greatest Thing Since 
Sliced Bread! It’s the Solution To All Your Retain-Release Nightmares! It’s….

Automatic Reference Counting!

And, um, seriously… you gotta’ check it out! There’s lots of documentation on 
developer.apple.com  about it, but I’d start here:

https://developer.apple.com/videos/play/wwdc2011/323/ 





> The project is open source (and open hardware) it has been around for over a 
> decade on some obscure websites that deal with converting paper piano rolls 
> to playable music (MIDI)  I suppose I should upload it to my github account. 
> (sheepdoll) I mostly have some quicklook (coverflow) plugins there as well as 
> some embedded stuff.  The hardware side of things is on iammp.org and 
> mmdigest.comGallery/Tech under "USB Controller for CIS Optical Roll Reader"  
> It is sort of an early Arduino (AVR 8bit) but with a parallel FIFO rather 
> than a serial one.  Currently I use a different OS to read the data to a SD 
> card.  Then do the postscript stuff under X11.  It has been like hitting a 
> moving target, to get all of this to work under OSX.  I literally wasted 
> years as some of the code was written as far back as OS7 (remember Quicktime 
> MIDI architecture?)
> 
> -julie
> 

Er… you mean System 7, running on a 8Mhz 68000, with 1MB of RAM? Yes, I do… 
somewhere around here in a closet I’ve got an original 128K Mac, with a Levco 
MonsterMac 2MB upgrade in it (IIRC, they desoldered the 68000, stuck it on a 
daughter card, and stuck that card back in-between the CPU and logic board, and 
fitted a hacked ROM to make it work - it was kinda’ cute, as they modified the 
boot sequence to show two fangs on the smiling mac icon), and an SE with 8MB in 
it (IIRC, I haven’t fired the SE up in a while… probably ought to, though…). 
I’ve also had my hands on just about every other Mac ever made… even if I 
didn’t actually own it myself (friends, work, etc).

Anyway… if you post a link to your updated code, I’ll check it out.

For anybody else interested (and google’s spiders) — direct links:

http://iammp.org/designfiles.php
http://www.mmdigest.com/Gallery/Tech/index.html




>> 
>> 
>> But to answer your question… I’ve had all sorts of odd issues with migrating 
>> Xcode projects forwards over the years; so the first thing I would do is 
>> extract your source code files (including any xib/nib or other resource 
>> files) and rebuild the project, starting from a blank Cocoa Application 
>> template in Xcode.
>> 
>> Remove any default-generated files like MyDocument.m, etc.
>> 
>> Then, add back your source files and do a compile. Fix any warnings or 
>> errors; especially 64-bit warnings.
>> 
>> Also, if you aren’t doing it already, don’t name your NSDocument subclass 
>> MyDocument - it will just lead to confusion should the Xcode template’s 
>> version somehow get included along with your code (which is my guess as to 
>> what is going on here).
>> 
>> Oh, and was there a conversion to ARC involved?
>> 
>> Is this an open-source project; or otherwise is there some way we could get 
>> a look at the project folder? Not having it in front of me makes 
>> troubleshooting it kinda hard…
>> 
>> :-)
>> 
>> 
> 
> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: migrating from 32bit to 64 bit can not run project

[Britt Durbrow]

/jporter
hardcore_programmer
def
showpage


__

Aaaand that’s probably horribly mangled postscript; but you’ll have to forgive 
me, as I haven’t had to read it in years, and have never had to write it in 
earnest…



But to answer your question… I’ve had all sorts of odd issues with migrating 
Xcode projects forwards over the years; so the first thing I would do is 
extract your source code files (including any xib/nib or other resource files) 
and rebuild the project, starting from a blank Cocoa Application template in 
Xcode.

Remove any default-generated files like MyDocument.m, etc.

Then, add back your source files and do a compile. Fix any warnings or errors; 
especially 64-bit warnings.

Also, if you aren’t doing it already, don’t name your NSDocument subclass 
MyDocument - it will just lead to confusion should the Xcode template’s version 
somehow get included along with your code (which is my guess as to what is 
going on here).

Oh, and was there a conversion to ARC involved?

Is this an open-source project; or otherwise is there some way we could get a 
look at the project folder? Not having it in front of me makes troubleshooting 
it kinda hard…

:-)


> On Mar 2, 2016, at 11:40 PM, Julie Porter  wrote:
> 
> I mostly program in postscript, which I use for a general purpose language 
> and MIDI parsing.  From time to time I make a little coca app when I need to 
> do interactive views or real world interaction.
> 
> I have a working app that I wrote under 10.5 that makes a little framework, 
> where I can parse and display the data in a scalable scrollable window.  This 
> app seems to run under 10.7 and Yosemite. Recently I discovered a bug that I 
> wanted to look at and possibly fix.
> 
> The parseable file is binary and has a type of .cis.
> 
> When I went to run the app in X code on my 10.7 machine  It defaulted to a 64 
> bit scheme which I did not create.  When I attempt to run a blank window 
> appears. When I open one of my .cis files I get an exception in documents.m 
> in the function "(BOOL)readFromData:(NSData *)data ofType:(NSString 
> *)typeName error:(NSError **)outError"
> 
> The program should be reading from the MyDocument class using the function 
> "(BOOL)readFromURL:(NSURL *)absoluteURL ofType:(NSString *)pTypeName 
> error:(NSError **)outError"
> 
> I switched to the 10.5 32 bit scheme and the code runs, but all my .cis files 
> are grayed out and I can not open them.
> 
> In clicking the little triangles on the folder views I see there are now 
> duplicates of things like main.m and there are more than one info-plist 
> files.  Where did these come from?  There are also duplicate xib files that 
> are the ones that seem stubs.  The blank window that appears in 64bit mode 
> seems to be coming from one of these stubs.
> 
> how do I get my little viewer program to open the files again?  Do I need to 
> copy my old settings into the new XIB files?
> 
> -julie
> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: ARC code in a non ARC app. iOS

[Britt Durbrow]

Tangentially related: 

I have a bug ( rdar://10894595 ) open on the Developer Tools (Xcode/clang) to 
add a #pragma to turn on/off ARC in the source code, for dealing with just such 
situations.

I dunno’ how much work it would be to implement… I imagine not all that much 
for somebody familiar with the internals of clang, but I could be wrong…


:-)
___

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: Full-text indexing on iOS

[Britt Durbrow]

> On Feb 12, 2016, at 8:04 PM, Britt Durbrow 
> <bdurb...@rattlesnakehillsoftworks.com> wrote:
> 
> I thought SQLIte had an extension to do this also (I’ve never played with it 
> myself, so YMMV)… I don’t know if the built in version has it enabled; to get 
> it you might need to do a custom build for your app?
> 
> 
>> On Feb 12, 2016, at 3:28 PM, Jens Alfke <j...@mooseyard.com> wrote:
>> 
>> 
>>> On Feb 11, 2016, at 2:48 PM, Alex Zavatone <z...@mac.com> wrote:
>>> 
>>> Project from second link that claims iOS Full Text Search
>>> https://github.com/Blue-Rocket/BRFullTextSearch 
>>> <https://github.com/Blue-Rocket/BRFullTextSearch>
>> 
>> That’s an Obj-C wrapper around the open-source CLucene library. If possible 
>> I’d like to use existing iOS functionality rather than drag in a large 
>> amount of 3rd party code. Thus my question.
>> 
>> —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/bdurbrow%40rattlesnakehillsoftworks.com
>> 
>> This email sent to bdurb...@rattlesnakehillsoftworks.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: LGPL code in the Mac App Store?

[Britt Durbrow]

> Another approach is to make a vanilla non-AppStore copy of the app available 
> to customers on request, if they want to replace the LGPL library. You’d just 
> need to find some way for the requestor to prove to you that they bought it 
> from the App Store.
> 
> —Jens

There have been developers who, upon removing their apps from the Mac App 
Store; had the replacement (non-MAS) version accept the MAS version’s receipt 
as valid licensing credentials; I suppose you could just post such a copy 
alongside the sources to the LGPL libraries, and that would allow for the 
LGPL’s requirements…

(again, I’m not a lawyer)...
___

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: LGPL code in the Mac App Store?

[Britt Durbrow]

IIRC, for Mac App Store apps, your app has to perform copy-protection checking 
itself (i.e, receipt checking); Apple specifically didn’t want to do that 
themselves so that when the inevitable crack appears in the wild, it doesn’t 
take out the whole app store - just the apps that the particular crack applies 
to.

iOS, I believe, is different.

(it’s been a while since I watched the relevant WWDC videos, though; and I 
haven’t had to implement such receipt checking myself yet, so take that with 
appropriate quantities of NaCl).

**

I am not a lawyer, nor do I play one on TV, but… I **think** that this section 
(taken from v3.0 of the LGPL):

> 4. Combined Works.
> You may convey a Combined Work under terms of your choice that, taken 
> together, effectively do not restrict modification of the portions of the 
> Library contained in the Combined Work and reverse engineering for debugging 
> such modifications, if you also do each of the following:
> 
>   • a) Give prominent notice with each copy of the Combined Work that the 
> Library is used in it and that the Library and its use are covered by this 
> License.
>   • b) Accompany the Combined Work with a copy of the GNU GPL and this 
> license document.
>   • c) For a Combined Work that displays copyright notices during 
> execution, include the copyright notice for the Library among these notices, 
> as well as a reference directing the user to the copies of the GNU GPL and 
> this license document.
>   • d) Do one of the following:
>   • 0) Convey the Minimal Corresponding Source under the terms of 
> this License, and the Corresponding Application Code in a form suitable for, 
> and under terms that permit, the user to recombine or relink the Application 
> with a modified version of the Linked Version to produce a modified Combined 
> Work, in the manner specified by section 6 of the GNU GPL for conveying 
> Corresponding Source.
>   • 1) Use a suitable shared library mechanism for linking with 
> the Library. A suitable mechanism is one that (a) uses at run time a copy of 
> the Library already present on the user's computer system, and (b) will 
> operate properly with a modified version of the Library that is 
> interface-compatible with the Linked Version.
> 

...means that the user must be able to modify and re-compile the library, and 
re-link the executable in toto, and (assuming that no errors were made during 
the modification phase) have the combined product run. Any code-signing or DRM 
system that prevented this, would to my eye, seem to violate the LGPL.

**

The current version of the Apple Developer Program Agreement states in section 
3.3.2 that MAS apps can run plugins, so I would presume that a sandboxed, 
code-signed MAS app can, in fact, load them. I haven’t actually tried it though 
(my apps that have a plug-in system, although code-signed, aren’t sandboxed MAS 
apps).

Also, now that I think about it… FWIW, wasn’t there a linker flag that told the 
system where to look for .dylibs?



___

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: LGPL code in the Mac App Store?

[Britt Durbrow]

Mac App Store, not iOS.

I would consider a: packaging a version of the library in your resources; and 
loading that if there is not one in the app’s Application Support folder; and 
b: providing the library on github. If the user wishes to modify the library 
for whatever reason, they download it; modify it; and stick it in the app’s 
container’s Application Support folder in the appropriate location; and the app 
loads that version instead of the version packaged from the app store.

Disclaimer: I haven’t actually tried it; so YMMV...


> On Jan 26, 2016, at 1:06 PM, Pascal J. Bourguignon  
> wrote:
> 
> 
> 
> On 26/01/16 20:23, thatsanicehatyouh...@me.com wrote:
>> Hi,
>> 
>> I’m working on a program that I will be submitting to the Mac App Store that 
>> uses LGPL code. I have recently learned that the license requires the 
>> capability for the end user to create their own version of the LGPL library 
>> to link against the application (I have been compiling the source directly 
>> into the library). This means at run time I need to either load the library 
>> from what I provide in the application bundle (default, obviously), or, if 
>> present, load one that the user provides. I can imagine wrapping the library 
>> in a framework could be an answer. It would be up to the user to build a 
>> framework in the correct format (I could easily make an Xcode project to do 
>> so available on GitHub).
>> 
>> Is this possible/allowed for an App Store application?
> I'm not sure it's allowed, you would have to check the App Store EULA and 
> license, and your Apple Developer Program agreement, etc.
> 
>> If so, is this the best approach? How would I load the library at runtime 
>> given that I normally link against it when I build the application?
> You cannot use dynamically loaded libraries on iOS.
> 
> Also, I think you won't be able to load a library yourself (as data) and jump 
> into it (as code), since I'd expect the iOS kernel and MMU to restrict 
> execution of data in iOS.
> 
> No, the only way to use a library in iOS, is to link it statically.
> 
> However, you can still respect the terms of the LGPL with statically linked 
> programs. All you have to do, is to provide the binaries of your program as 
> object files (or a library of them), with a Makefile or a script to link your 
> object files with the LGPL static libraries into a new final executable.
> 
> Now, given the complexity of the the Xcode/iOS build process, it may not be 
> simple to collect the required object files, and to write a Makefile or 
> script to do this final link, but you copy-and-paste the output of the 
> compilation/link in Xcode, and extract the commands used, that would be a 
> good start to write your linking script. (You would also have to provide the 
> resource bundles, if your application has such).
> 
> 
> Now of course, the question is what will a user (even a programmer!) do with 
> a set of object files and a linking script?  I mean, he could always link a 
> new executable with his modified LGPL libraries, but he would still have to 
> be a registered developer to be able to sign the application and install it 
> on his iDevice.  He couldn't push it on the AppStore, since it would be 
> basically a duplicate of your application in the AppStore, and Apple forbids 
> duplicates (theorically; there are still tons of implementations of the same 
> game or utility in general).  As an registered Apple Developer, he could use 
> Xcode to install his copy of the program only on a limited number of test 
> iDevices, and he could certainly not _distribute_ it in any term.
> 
> 
> This, AFAIK.  A closer reading of Apple licenses and legal agreements would 
> have to be performed to refine this question.
> 
> -- 
> __Pascal J. Bourguignon__
> http://www.informatimago.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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: Panes vs. Separate Windows

[Britt Durbrow]

My preference would be multiple windows (one primary document window and 
several utility panel windows) that can be snapped into place against each 
other. This gives the freedom to use multiple monitors while also having the 
screen-real-estate efficiency that a single-window approach would. (FWIW, I’m 
typing this on a 27” 2560x1440 Acer LCD connected to a 13” Retina MBP; both 
displays are active at the moment).

I find that as the problem space that the app is trying to solve becomes more 
complex, the all-in-one approach that is being pushed by the 
“full-screen-window” model gets too inflexible.

As for the single-instance vs. multiple-instance auxiliary windows issue; to a 
certain extent it depends on the work-flow of the app. If there are common use 
cases where seeing data from two documents at once is useful, then they should 
be per-document; otherwise I generally prefer a shared inspector palette model.


Background: I’m currently working on two CAD applications, and a GIS system.

> On Jan 9, 2016, at 2:19 PM, Rick Mann  wrote:
> 
> In complex apps (e.g. CAD apps, IDEs) a given document has many auxiliary 
> windows. The trend in UI at Apple has been to consolidate these into panes in 
> a single window. I've always preferred separate windows (e.g. separate 
> toolbar window).
> 
> One more concrete example is in a CAD program: the objects in the document 
> are often related to each other hierarchically. There's usually a view of 
> this hierarchy using something like an outline table. I can see this 
> naturally fitting as either a pane in a split view, or as a separate window. 
> Best of both worlds, I suppose, would be a dockable window (a window that can 
> be separate, or live as a pane in a split view), but that might be a lot of 
> additional coding (is there a nice library that offers this?).
> 
> Complicating matters is whether or not each open document shares a single 
> instance of these auxiliary windows or has its own. I think something like a 
> tool palette is clearly shared (it's more app-global then per-document), but 
> the model object hierarchy window is probably per-document.f
> 
> Separate windows have tremendous advantages, but I think panes are considered 
> more "simple." Simplicity has advantages, but we're talking about complex 
> apps that by their nature demand more of their users than something like 
> iPhoto.
> 
> Thoughts?
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: iPad Pro apps given more memory?

[Britt Durbrow]

Well, FWIW I happen to have an iPad Pro sitting next to me, so I just whipped 
up the following test and was able to allocate and write to almost 3GB of RAM 
before it started crashing on me.

#define allocationSize  (1024ULL*1024ULL*3050ULL)
#define stride  (4096)

- (BOOL)application:(UIApplication *)application 
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{

printf("Starting memory test...\n");

printf("Allocating memory...\n");

uint8_t *buffer=malloc(allocationSize);

printf("Writing to buffer...\n");

for(uint64_t cursor=0; cursor On Dec 9, 2015, at 5:56 PM, Rick Mann  wrote:
> 
> 
>> On Dec 9, 2015, at 17:37 , Jens Alfke  wrote:
>> 
>> 
>>> On Dec 9, 2015, at 5:17 PM, Rick Mann  wrote:
>>> 
>>> - By "virtual memory," I'm sure you don't mean it's swapping to disk 
>>> (flash). Or do you? If not, how is it virtual?
>> 
>> All memory is virtual in any modern OS — the only thing that sees ‘real’ 
>> memory addresses is the kernel’s VM subsystem. ‘Virtual’ just means there’s 
>> a layer of indirection between address space and RAM.
>> 
>> On iOS it’s just that the address space normally allocated to apps (by 
>> malloc, etc.) isn’t backed by a swap file. So it doesn’t get paged out, but 
>> it’s also limited by the amount of physical RAM.
> 
> Ah, yes, of course. Just the address translation is happening. Yeah, I need 
> to know if the dirty limit has increased.
> 
> Alternatively, if mmap-ed memory would actually live in RAM, but get around 
> the dirty limit (assuming for the sake of argument that the user isn't 
> running other apps), then we really could get more memory without a speed 
> penalty via mmap().
> 
>> 
>> By “how much virtual memory you can use” I believe Rick means how much 
>> _address space_.
> 
> No, I need to know how much I can actually allocate and dirty.
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: ARC and IBOutlet - strong vs weak......

[Britt Durbrow]

Your reference is weak, old man… oh, wait, that’s kung-fu…. um….


Seriously - I always make my references strong unless I have a good reason not 
to (avoiding retain cycles is one such good reason). Weak references, while 
nice for what they do, do have some overhead and other drawbacks (like the lack 
of KVO compliance Gerd Knops mentioned).


> On Dec 6, 2015, at 7:15 AM, Dave  wrote:
> 
> 
>> On 5 Dec 2015, at 17:31, Alex Zavatone  wrote:
>> 
>> Weak.
>> 
>> There is only one reference to it, right?
>> 
> 
> It seems that the actual answer is “it depends”……. But making them strong 
> unless you specifically need to do otherwise seems like the best practise 
> approach…..
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: Display USB Video Camera output : AVFoundation?

[Britt Durbrow]

One of my projects (still on the back burner at the moment, but slowly 
progressing nonetheless) is a DIY pick-and-place machine for doing small-run 
electronics. It uses standard VGA-quality  USB webcams (such as the type that 
you can get off of eBay for under $10 each… often under $4) to do the 
component-detection machine vision; and I do have the video input section of 
the project seeing the webcams with AVFoundation.

So if that’s the kind of camera in question… yeah, it works.

:-)

> On Sep 9, 2015, at 9:22 PM, Jerry Krinock  wrote:
> 
> In a Mac app, I need to display real-time video (as in “movies”) from a USB 
> camera on the screen.  Can someone please confirm that AVFoundation the way 
> to go?
> 
> I’ve read that QTKit is deprecated but, oddly, I cannot find any mention of 
> deprecation here in the QTKit Programming Guide:
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/QTKitApplicationProgrammingGuide/
> 
> Thank you,
> 
> Jerry
> 
> 
> ___
> 
> 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/bdurbrow%40rattlesnakehillsoftworks.com
> 
> This email sent to bdurb...@rattlesnakehillsoftworks.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: copiesOnScroll behavior of NSClipView in OSX 10.10

[Britt Durbrow]

Dunno yet… I found a bug related to scrolling and zooming with NSScrollView; 
DTS said that turning off responsive scrolling was a workaround; so I figure 
that that subsystem may be in flux right now?

If you can reduce it to a sample project; I’d say file a bug explaining what 
you need and/or contact DTS to make sure that this issue is kept in mind while 
they are working on it?

 On Aug 11, 2015, at 6:39 AM, Arun Bharti abha...@quark.com wrote:
 
 We think copiesOnScroll behavior of NSClipView has changed in OSX 10.10?. 
 Because while scrolling it is not asking for redraw of newly exposed area!!! 
 Instead is asking for entire visible area to be redrawn every time. My 
 application is not compatible with responsive scrolling, so I cannot use it 
 and have turned it off. But I still need to keep that copiesOnScroll 
 behavior. Any help is appreciated
 
 Is there a way to redraw only the newly exposed portions of its document 
 while scrolling in OXS10.10? Please help me.
 
 Thanks for any guidance.
 Regards
 Arun Bharti
 
 ___
 
 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/bdurbrow%40rattlesnakehillsoftworks.com
 
 This email sent to bdurb...@rattlesnakehillsoftworks.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: Window Update Problem

[Britt Durbrow]

I’m not an AppleScript expert (well, not anymore - I used to know quite a bit, 
but that was ages ago) so I can’t really tell you if you’re going wrong, but… 
can I ask a kinda’ basic question?

It appears that you are trying to send an email… can you talk to the server 
directly, instead of going thru Outlook?

Would something like http://libmailcore.com help? (I’ve never used that myself, 
it’s just the first result that popped up in Google).
___

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: Swift and parameter names

[Britt Durbrow]

IMHO, named parameters at call sites are one of the things that makes 
Objective-C great; and I am VERY happy that Swift-2 enforces this.

It is not any additional burden in any modern IDE to have this; as the IDE’s 
autocomplete fills in the parameter names for you.

Also, consider a body of code that has inferred parameters in it… and now you 
need to add a new function; which makes the inferred call sites ambiguous.  At 
best this will require some complicated regex replacement operations across the 
whole code base before it will compile again; at worst it will be unfixable (if 
you don’t have the source code and the binary that you are trying to link 
against doesn’t have enough information for the linker to resolve the ambiguity 
(I don’t know enough about Swift’s intermediate format to say if it does or 
not); or for some reason you do have the source code but are forbidden from 
modifying it).
___

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: Scary Stuff!

[Britt Durbrow]

I’ve skimmed the paper; and it seems to me that there is no API/system-level 
solution possible.

I’m not familiar with the Keychain API; owing to not having needed to use it, 
but it seems to me that a best practices approach can solve that issue: check 
that the keychain item’s properties (ACL most importantly) are what you expect 
before using it. However, the OS can’t know ahead-of-time what those ACLs 
should be; consequently it must fall to the app to provide that logic.

Likewise, some containers are supposed to be shared; and others aren’t. The OS 
can’t know what that is; it must fall upon the App Store to validate that. An 
automated heuristics approach backed up by actual human validation of edge 
cases is probably the way to go for this:

1) Bundle identifiers that belong to the developer submitting the app 
automatically get passed.
2) Bundle identifiers that are known to be shared automatically get 
passed.
3) All others get human review.

URL schemes should require registration with Apple; collisions should cause a 
store submission to fail.

And lastly, if you have malware on your system; you are pretty much toast: 
despite all that we do to try to prevent it, no system of this level of 
complexity is perfect, and the good guys have to be right 100% of the time, 
while the bad guys only have to be right once in order for it to worm it’s way 
into the machine.

 On Jun 17, 2015, at 2:07 PM, Jens Alfke j...@mooseyard.com wrote:
 
 
 (“I know! I’ll write the passwords to a plist and XOR the bytes with a 32-bit 
 secret number I hardcode in my app!”)

WHAT?!?! No! You gotta use ROT13! ;-P
___

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: Language options: Objective-C, Swift, C or C++?

[Britt Durbrow]

 On Jun 13, 2015, at 1:41 PM, Michael David Crawford mdcrawf...@gmail.com 
 wrote:

 I'm not
 completely clear as to why, but among the reasons I enjoy C, C++,
 Objective-C and Assembly Code is that I can do tweaky little
 optimizations like reordering data accesses so as to reduce cache
 misses.


I also like the ability to get low-level access… but data access reordering is 
a bad example; as that only works in Assembler: for the other languages, the 
compiler is free to reorder any accesses as it sees fit as long as they are 
semantically the same.



___

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: Language options: Objective-C, Swift, C or C++?

[Britt Durbrow]

My $0.02:

Swift is too immature to warrant doing anything serious with it yet… it just 
hasn’t been around long enough to be exercised the way that Objective-C has. 
This will, however, change with time. And yes, there is something of a 
chicken-and-egg problem there: if nobody does anything serious with it, it’ll 
never achieve the level of maturity to warrant doing serious projects in it. I 
believe however that given time, enough people will pick it up and bang on it 
to overcome this issue.

Personally, if I had the time to dedicate to it, I’d come up with some 
non-critical project (i.e, something not “serious”, but big enough to qualify 
as “non-trivial) to do in Swift for the purpose of developing that skill set. 
(Perhaps when I get done with this project that I’m up to my eyeballs in right 
now… sigh).

I don’t see Objective-C going away anytime soon; just as I don’t see C going 
away anytime soon; or for that matter, C++ or Assembler. They all have their 
place, and there is a *massive* body of existing code written in those 
languages (admittedly, Assembler accounts for a tiny fraction of the codebase, 
but it is an absolutely essential fraction: the machine wouldn’t even boot 
without it; objc_msgSend is in it, etc).

And I trust the media approximately as far as I can throw them (seriously… have 
you *seen* what passes for reporting these days?!?!?).
___

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: Understanding the declaration of instance variables in the interface is deprecated warning.

[Britt Durbrow]

 On Jun 4, 2015, at 9:16 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote:
 
 
 On 04 Jun 2015, at 02:36, Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 
 On Jun 3, 2015, at 11:30 AM, Mark Wright blue.bucon...@virgin.net wrote:
 
 For what it’s worth, I’ve never had that problem either.  Most of the time 
 self.whatever is used for property access, _whatever is used for ivar 
 access and that’s about it.
 
 Yup. This is what I meant about properties vs ivars being obvious from 
 context: the only way to do a property access is by causing a message send; 
 and there are only three direct ways to do that in Objective-C: 
 somePointer.accessor (i.e, dot notation); [somePointer accessor] and 
 [somePointer setAccessor:aNewValueGoesHere]; and a direct call to 
 objc_msgSend(). 
 
 There’s also key-value coding, i.e. [obj valueForKey: @“accessor”] and [obj 
 setValue: @1 forKey: @“accessor”], and the implicit occurrences thereof in 
 e.g. XIB loading.
 

I would classify that as an indirect way, as it’s not actually built into the 
language (it comes from NSObject)… and FWIW, there’s also NSInvocation, and any 
number of third-party invocation or KVC wrappers.



___

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: Understanding the declaration of instance variables in the interface is deprecated warning.

[Britt Durbrow]

 On Jun 3, 2015, at 11:30 AM, Mark Wright blue.bucon...@virgin.net wrote:
 
 For what it’s worth, I’ve never had that problem either.  Most of the time 
 self.whatever is used for property access, _whatever is used for ivar access 
 and that’s about it.

Yup. This is what I meant about properties vs ivars being obvious from context: 
the only way to do a property access is by causing a message send; and there 
are only three direct ways to do that in Objective-C: somePointer.accessor 
(i.e, dot notation); [somePointer accessor] and [somePointer 
setAccessor:aNewValueGoesHere]; and a direct call to objc_msgSend(). 

All other forms are direct variable access: either globals, locals, or instance 
variables.

In other words:

@inteface foo : NSObject
@property(nonatomic) int bar;
-(void)doSomething;
@end

@implementation foo
{
int bar;
};

-(int)bar
{
return bar;
};

-(void)setBar:(int)new_BarValue
{
bar=new_BarValue;
};

-(void)doSomething
{
bar=12345;  // Direct access to bar

self.bar=12345  // Going thru the property’s setter
[self setBar:6789];
if([self bar]==6789)
puts(“Yay, it’s still what I set it to!\n”);

int baz;// Obviously a local

baz=123 // Direct access

self.baz=456;   // Compile error here; because baz is a local, 
not a property. Other obvious error patterns left as an exercise for the 
reader. :-)
};

@end

// Note: thoroughly compiled and tested in Mail.app ;-) 
___

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: Looking at self = [super init].

[Britt Durbrow]

 On Jun 1, 2015, at 9:53 PM, Scott Ribe scott_r...@elevated-dev.com wrote:
 
 On Jun 1, 2015, at 10:43 PM, Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 So…. it looks like clang at least is doing the right thing and calling the 
 destructor when the variable goes out of scope.
 
 Yep. But I believe with goto you can skip over a constructor--but at least 
 you get a warning.

I just tried… I get an error, not a warning: “Goto into protected scope”.
___

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: Looking at self = [super init].

[Britt Durbrow]

 On Jun 2, 2015, at 12:13 PM, Charles Srstka cocoa...@charlessoft.com wrote:
 
 
 Variables declared in an @interface section trigger a compiler warning:
 
 warning: declaration of instance variables in the interface is deprecated 
 [-Wobjc-interface-ivars]

Hmm… I’ve never seen that warning actually be emitted by clang… so, thinking 
something was amiss, I just created a brand new project file (Cocoa app; 
Objective-C; not document based) with Xcode Version 6.3.2 (6D2105); and went 
looking for where to turn that on/off in the target build settings…  and I 
can’t find it. So, I then proceeded to add an int foo; declaration to the 
@interface of the app delegate — no warning emitted. In order to get it to show 
up I had to add it to the “Other C Flags” line under “Apple LLVM 6.1 - Custom 
Compiler Flags”.

 
 Oh, and there’s a nifty warning that’s thrown as soon as you try to declare 
 a local variable of the same name as an instance variable.
 
 That doesn’t help if I’m looking at some code that someone else wrote, or 
 code that I wrote 5 years ago, noticing a variable name being used somewhere, 
 and having to hunt around for the declaration to figure out whether it’s a 
 local variable, an instance variable, or something stupid like a global or 
 something.
 

Um… why does it matter? If you go to add a variable declaration and you 
immediately get a warning… just pick a different name? Or use the symbol 
navigator to find it (it’s got a search box) ? Or remove the type from the 
declaration (so that it’s now just a symbol reference) and command-click it?

 On Jun 1, 2015, at 3:14 PM, Charles Srstka cocoa...@charlessoft.com wrote:
 
 
 Non-underscored ivars vs. local variables, however, are not obvious at all, 
 especially if the method is large.
 
 In modern versions of Xcode at least, if I don’t know exactly what I’m 
 looking at, the answer is just a command-click away… :-)
 
 That can be handy, when it works. Sometimes it doesn’t (particularly when 
 you’re using Swift, in which command-click usually just brings up an endless 
 circular progress indicator).
 

I’m not using Swift; and probably won’t be any time soon; so I can’t speak to 
Xcode’s current stability with Swift code. However, in Objective-C I rarely 
have a problem; and when I do performing a clean-and-build cycle has made it go 
away.
___

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: Looking at self = [super init].

[Britt Durbrow]

My take on it is that this is somewhat a style issue; and as such is 
quasi-religious in nature; with adherents on all sides of the issue with valid 
points to make.

But FWIW, my, er, “sect” (to take a metaphor slightly beyond the breaking 
point) adheres to something that looks like this (er, coded in Mail.app - take 
with appropriate grains of salt):

#define RSHOddBall_randomDictionaryCapacity (100)

@implementation RSHOddBall

-(instancetype)init
{
if(!(self=[super init])) return nil;

someIvar=12345;
someRandomDictionary=[NSMutableDictionary 
initWithCapacity:RSHOddBall_randomDictionaryCapacity];

return self;
};


Notes:

I code with the full capabilities of modern IDEs in mind; for example, I don’t 
worry about setting off macros in all caps as syntax highlighting takes care 
that; and if I see a macro that I don’t immediately know exactly what it does, 
well it’s definition is only a command-click away.

I do believe that for readability, braces should be lined up vertically. Yes, 
it makes the source code longer - but ‘comeon, we’ve got *very* high resolution 
monitors these days, we can fit a *lot* of text on them!

I happen to like an extra semicolon after a closing brace when it’s the end of 
the logical block. It’s just the way I like it to look (it feels ‘funny’ to me 
to have a statement end without one); the compiler ignores it. YMMV.

Within a class I’ll often use direct ivar access; but outside of it I’ll almost 
always use accessors (there are some oddball performance related exceptions to 
this, but they are always heavily documented on the variable declarations, and 
used in a tightly integrated class-cluster like situation, hence the *almost* 
always - but it’s the exception, definitely not the rule). Yes, I know that 
there are valid reasons to use accessors within the class, but for most of my 
code it’s not warranted. Transforming direct ivar access to use accessors is a 
simple regex search and replacement should I need to refactor it. Again, YMMV.

I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary -- 
it doesn’t help with namespacing (if a subclass and a superclass both declare 
_someVariable with the underscore they will collide just as badly as if they 
declare someVariable without one) and ivars vs accessors are obvious by 
context: [self obviouslyAnAccessor] or self.obviouslyAnAccessor vs 
obviouslyAnIvar (or very rarely, someObject-obviouslyAnIvar). I do, however, 
use them for doing pseudo-namespacing at levels below the project prefix (as 
evidenced by RSHOddBall_randomDictionaryCapacity).

I personally find early returns to be very useful, and also make use of 
forward-jumping goto statements sometimes (i.e, goto bail;).


However, when working on somebody else’s code (like, say, an open-source 
library); I’ll adopt their coding style, even if some of the things they do 
make my eyes itch. ;-)
___

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: Looking at self = [super init].

[Britt Durbrow]

In no particular order:

 On Jun 1, 2015, at 7:27 PM, Michael David Crawford mdcrawf...@gmail.com 
 wrote:
 
 I quite commonly fix bugs by refactoring all the lengthy routines into
 several shorter ones.
 


I have the same rule of thumb - if it’s not obvious what’s going on, I should 
probably think about refactoring it into smaller chunks.

—

 
 
 On Jun 1, 2015, at 6:09 PM, Graham Cox graham@bigpond.com wrote:
 
 If you have a complex method whose function can’t be determined at a glance 
 (and that in itself could be a good argument for a refactoring) with multiple 
 exit points rather than one clear exit point at the end, it can often be hard 
 to follow the flow of control.

Um… don’t do that? :-)

Yes, early returns  gotos are power tools that can be misused. YMMV, wear 
proper personal protective equipment, void where prohibited and/or 
uninitialized, not for sale to miners, etc...

…and no, I have no idea why people who dig ore out of the ground shouldn’t be 
allowed to buy it (I suppose that’s what I get for asking a muppet for legal 
advice, eh? :-) 

—


 
 On Jun 1, 2015, at 4:39 PM, Quincey Morris 
 quinceymor...@rivergatesoftware.com wrote:
 
 On Jun 1, 2015, at 14:52 , Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 I happen to like an extra semicolon after a closing brace when it’s the end 
 of the logical block. It’s just the way I like it to look (it feels ‘funny’ 
 to me to have a statement end without one); the compiler ignores it. YMMV.
 
 The issue here is that you may find it comforting to see ‘;’ at the “end” of 
 a statement, but it skates right over the ambiguity of when a “{ … }” 
 construct is to be regard as a “logical block”. The compiler does *not* 
 ignore the “;” after “}”. The following does *not* compile:
 
   if (…) {…}; else {…};
 
 You can argue that the intermediate ‘;’ not the end of a logical block, but 
 if a “}” isn’t the end of a logical block, you’ve just changed a stylistic 
 rule into a syntax rule.
 

The entire if statement is what I consider a logical block: the else {...} does 
not, and indeed cannot, stand alone.

if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
};

[anotherObject doesSomethingElseEntirely];

is the same to the compiler as:

if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
}

[anotherObject doesSomethingElseEntirely];

or even:

someCondition?[someObject doSomething]:[someObject 
doSomeOtherThing],[anotherObject doesSomethingElseEntirely];

although I will say that the readability on the third example does suffer 
somewhat. :-)

—

 I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary 
 -- it doesn’t help with namespacing (if a subclass and a superclass both 
 declare _someVariable with the underscore they will collide just as badly as 
 if they declare someVariable without one)
 
 The real reason for this convention is something else. In the bad old days 
 (meaning, more or less, pre-Leopard), there were multiple conflicting 
 conventions about using “_” for naming. Perhaps it was when the clang 
 compiler was introduced, I can’t remember exactly, but Apple decreed the 
 current convention, to work around the inherent unsafety of Obj-C namespacing:
 
 — Private 3rd party instance variables *should* use the underscore.
 
 — Private 3rd party methods *must not* use the underscore.
 
 It’s not really a question of good or bad. It’s more a question of what we 
 were required to do to avoid future Cocoa frameworks releases from 
 retroactively breaking our apps.
 

There were multiple arguments for and against underscores; the namespace issue 
is one of them; readability was another. FWIW, once upon a time, Apple claimed 
the entire namespace prefixed with an underscore as reserved (for both instance 
variables and methods). I believe that the modern runtime does indeed get 
around the issue with ivars (I don’t have a documentation reference to point 
to, but a quick check in Xcode indicates this; as does Charles Srstka’s posted 
code).

—

 On Jun 1, 2015, at 7:11 PM, Charles Srstka cocoa...@charlessoft.com wrote:
 
 On Jun 1, 2015, at 6:39 PM, Quincey Morris 
 quinceymor...@rivergatesoftware.com wrote:
 
 On Jun 1, 2015, at 15:14 , Charles Srstka cocoa...@charlessoft.com wrote:
 
 Which is not at all, actually:
 
 The answer is “not at all” only with the modern ABI. 32-bit Mac compilations 
 will conflict.
 
 That’s true. Also, code written for the Mac Plus using THINK C 3.0

Re: NSMutableDictionary Look Up

[Britt Durbrow]

I don’t think that it would have a significant effect; and I also don’t think 
that any changes would be worth the trouble…

I did a little more benchmarking on the dictionary primitives 
(NSMutableDictionary and NSString’s -hash implementation); and got pretty much 
the results I expected; although the timings were a bit noisy it’s showing 
typical performance of ~ O(1)… what I’d expect for a hashtable.

I put my results on pastebin here:
http://pastebin.com/9jSTqBNQ

And the source code for the test here:
http://pastebin.com/TXyHjTTu
___

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: NSMutableDictionary Look Up

[Britt Durbrow]

NSDictionary, AFAIK, is based on a hash table internally; and it uses the -hash 
method of the key objects to store the keys in the table.

What kind of key are you using for the dictionary? As long as that object’s 
-hash method and -isEqual methods are efficient, you should be OK...



___

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: Tracking the retain count

[Britt Durbrow]

In no particular order:


 On May 19, 2015, at 8:37 PM, Graham Cox graham@bigpond.com wrote:
 
 I think what the OP says he wants is that the cache can only release when it 
 knows nobody else has a reference to an object as well, hence the temptation 
 to peek at the retain count. In other words it must be the “last owner”, for 
 some reason.

Yes, exactly: the reason being that of maintaining graph coherency.

Suppose we have these objects in play:

The object pool controller, call it OPC.
A view controller, call it VC1.
Another view controller, call it VC2.
A document model object in the pool controlled by OPC, call it DMO1 (and lets 
say it’s got a UUID of 12345, cuz’ ya know, that’s the combination on my 
luggage ;-)

The view controller VC1 has a strong reference to DMO1

A memory pressure event occurs, and OPC decides to evict DMO1, but it doesn’t 
immediately go away, because VC1 is holding on to it.

VC2 comes along and wants to get at the object with UUID 12345 (in order to 
execute [someObject stealAllTheAir], lets say).
Sooo… OPC loads the data for UUID 12345 from file storage, alloc’s a new object 
(call it DMO2), sets it’s parameters (including assigning the UUID to it), puts 
it in the in-RAM object pool, and returns the new object as being the object 
for UUID12345. Note that this can often happen as a result of a fault firing, 
so VC2 didn’t even know it was asking for UUID 12345, just that it was 
messaging a pointer to some object.

So, at this point, in RAM there is: OPC (who knows DMO2 as UUID 12345), VC1 
(who knows DMO1 as 12345), VC2 (who knows DMO2 as 12345), DMO1 (who thinks it 
is UUID 12345), and DMO2 (who also thinks it is UUID 12345).

And now VC1 is writing to DMO1, thinking it’s updating UUID 12345, at the same 
time as VC2 is doing the same thing to DMO2, also thinking it’s talking to UUID 
12345.

BOOM, loss of graph coherency.


Now, if OPC knows that there is somebody out there with a strong link to DMO1, 
it won’t evict that object (instead, it’ll pick some other object to get rid of 
that only it has a strong link to), and when VC2 comes along an tries to access 
something that’s supposed to be UUID 12345, it gets the same object that 
everybody else thinks is UUID 12345, because there was only ever one in RAM at 
any given time that had UUID 12345.

And that’s just one scenario… the possible permutations of not maintaining 
UUID-identity are vast (I speak from experience on this one - the early 
development versions of the engine had all sorts of hiccups)...

 On May 19, 2015, at 3:50 PM, Graham Cox graham@bigpond.com wrote:

 Instead, if objects that access the cached objects are forced to use 
 ‘beginContentAccess’ and ‘endContentAccess’ then you have a very definite way 
 to find out when nobody is accessing the objects that cannot be interfered 
 with by memory management in any way.
 
 I may have misunderstood the problem such that this is a poor ot for other 
 reasons, but I’m not seeing it. I’m also not sure why there seems to be a 
 tacit resistance to it - seems logical to me.
 
 —Graham.

I don’t think that NSDiscardableContent was intended to be used in *quite* that 
way; but even not using NSDiscardableContent and coming up with my own protocol 
to do that has a problem: there is an existing body of code that I really don’t 
want to have to try to retrofit that onto, as I would have to track down each 
and every access and bracket it; and I’m basically back to all the pitfalls of 
project-wide manual retain counting. Instead, I’m trying to have the object 
pool controller do all the work in a centralized location.


 I think the problem is that Britt is conflating two semantically distinct 
 things: whether the object exists, and whether the object is “in use”. S/he 
 is attempting to determine that the object is not “in use” while it still 
 exists by peeking at retainCount to see if it’s 1.


I’m deliberately conflating that, because if it exists in the object pool 
controller’s strong container with a retain count of anything greater than 1, 
it *could* be in use, and therefore is not safe to evict from the in RAM object 
pool. Yes, this reasoning (which I’m *not* wedded to, as it were) does make 
some assumptions, but I do believe that they are backed up by the runtime 
documentation: that there is only one retain count, and that that retain count 
is accessed thru -retainCount, and that attempting to access an object that you 
don’t have a retain on is illegal. 

Note that this is *exclusionary* logic, not *inclusionary* logic: nothing else 
can be inferred from the retain count; only that *something* has it.

That said, I’ve done some testing, and although NSMutableDictionary was 
performing substantially worse than I expected in terms of memory footprint, 
NSMapTable with weak links was not performing as badly as I expected either in 
terms of memory or CPU time… but I *think* I can make it work well enough to 
solve the problem using a 

Re: Tracking the retain count

[Britt Durbrow]

 
 On May 20, 2015, at 10:32 AM, Quincey Morris 
 quinceymor...@rivergatesoftware.com wrote:
 
 Turns out they weren’t so much off track as you need a smack upside the head. 
 [Er, wait, you’re a big dude with a beard, so perhaps kittens instead? You 
 like kittens? I don’t want to get hurt.]
 

Um… no; that was an example of what *NOT* to do. It was supposed to show what 
*won’t* work, and what I mean by “loss of graph coherency.

Sorry if that wasn’t clear… We are, in fact, on the same page at this point! :-)

 ** In practice there may be a little something more in the way of 
 housekeeping. If you’re selectively releasing things from the cache, you 
 might need to keep track of what you did, so that you re-retain the correct 
 subset of OPC references later. If you don’t need to be selective, it’s 
 easier because you just release everything in OPC at the start of the memory 
 event, and re-retain everything in OPC [that still has a non-nil pointer in 
 OPC] at the end.

The document objects in question happen to have a flags field in their base 
class with some unused bits that I’m going to dedicate to tracking that state.


***

 
 On May 20, 2015, at 9:09 AM, Charles Srstka cocoa...@charlessoft.com wrote:

 The flaw in this example is that VC1 continuing to use DMO1 even after it has 
 told OPC that it’s done with it is a programmer error.

It would be if the system was using something akin to NSDiscardableContent… but 
remember, there is a body of legacy code that I am trying to disturb as little 
as possible by making the memory management as automatic as possible.

Also, generally speaking, I don’t want to have to go back to a manual 
retain/release model for the whole app (which is basically what using 
NSDiscardableContent entails; even though it isn’t literal -retain and -release 
calls; the pitfalls are similar).

***

 On May 20, 2015, at 5:45 AM, Roland King r...@rols.org wrote:


 
 No that’s not what he wants to achieve. He wants
 
 1) When he needs an object pertaining to a given UUID he wants
 1.1) if it doesn’t exist - to create it and keep it mapped to the UUID in 
 some manner such that
 1.2) if it does exist he just returns the same object as before. 
 
 There can never be two objects living  which represent the same thing (ie 
 UUID)
 

snip

Basically, yes. There’s some implementation details involved, but that’s a 
pretty good summary of the problem… and after doing some more testing, I 
*think* I have an approach now that will work well enough (some of my initial 
intuitive concerns didn’t pan out - figures, premature optimization being the 
hazard that it is; and other things are worse than I thought they were such 
that the additional overhead of implementing weak links isn’t as high as I 
thought it would be; and then there’s the explicit retain/release step that 
Quincey suggested that cuts out having to have two separate containers for the 
object pool).
___

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: Tracking the retain count

[Britt Durbrow]

 On May 18, 2015, at 8:59 PM, Quincey Morris 
 quinceymor...@rivergatesoftware.com wrote:
 
 Let me try and summarize where we are, in response to the several recent 
 suggestions:
 


Close, but not quite:

I have several apps which are built on an existing, fully functional data 
management layer that was originally built for a full desktop virtual-memory 
environment (FWIW, it pre-dates the existence of Core Data). I now need to move 
some of this to run under iOS. I also don’t want to make changes to this data 
management layer that would require widespread changes to my other apps that 
rely on it.

The objects in question are document model objects; and retrieving them from 
file storage is indeed non-trivial; and so should be minimized when possible. 
It is not, however, the end of the world if some of them gets evicted from RAM, 
and then has to be later reloaded (such is life on iOS).

Because these are document model objects, they must be unique in RAM and in 
file storage; and maintain their identity across RAM/file-storage transitions. 
If an object is evicted from RAM, it’s contents are written to it’s file 
storage first, and then later when it is recreated in RAM those contents are 
reloaded from the file. I am using the UUID of each object to establish the 
object’s identity across these transitions. However, the object graph while in 
RAM references other in-memory objects by pointer, not UUID (changing this 
basic fact of the system would require wide-spread rewrites of all the 
applications that use this data management system; and I thusly consider it 
infeasible).

 In addition, because of the overhead of managing the uniqueness of the UUIDs, 
 it’s too expensive to create new objects regularly on demand. The purpose of 
 the cache is to extend the lifetime of otherwise unreferenced objects so that 
 they can be reused rather than reincarnated. It does this by taking ownership 
 of (retaining, keeping a strong reference to, however you want to think of 
 it) every object in the cache.


It’s not maintaining the UUIDs as unique that makes for the expense, it’s the 
loading and unloading of the document model objects that does so; and to a 
lesser extent, keeping the object graph coherent. The objects in the system are 
not interchangeable or reusable; each one must maintain it’s identity even if 
it’s in-memory pointer address changes over time. The file storage system also 
enforces this identity by storing and retrieving objects by UUID.

 This means that objects can exist in memory in one of these states:


The way I see it, any given object can be in one of these states:

* Not in RAM at all; only in file storage (and stored under it’s UUID)

* In RAM as a fault object. Faults are (like as in Core-Data) proxys for 
objects in file storage, that reserve RAM for the object, but don’t have any of 
the object’s contents loaded yet. Because they don’t have any contents, they 
also don’t store any links to other objects in RAM. When any message is sent to 
a fault object, it causes the object’s contents to be loaded from file storage, 
and the class to be swizzled back to it’s actual class (this may in turn cause 
the creation of other fault objects in RAM for objects that are not in RAM but 
referenced by the fault’s contents).

* In RAM as a fully “inflated” object. This is a regular Objective-C object, 
with ivars, pointers, methods, and all the associated stuff.

Additionally, the objects in RAM (fault or inflated) can be in one of these 
states:

* Referenced. This is as you stated - something has a strong link to it (be it 
in the graph of document objects, or some other object in the system, or some 
variable on the stack someplace).

* Unreferenced. Also as you stated… except:

I’m not drawing a distinction between Referenced and Inaccessible. If there is 
a link to it somewhere in the system, my reasoning goes, that the object pool 
controller shouldn’t let it go yet.

Obviously, if a given object is not in RAM, it falls in the Unreferenced 
category, as there can’t be any links to it, strong or weak. :-) 

 I don’t have any other plausible housekeeping reasons, but I do know that “No 
 one else should be using this object right now” is a common prelude to a 
 self-inflicted injury.

I am aware of the fact that if I do use a retainCount based system, I’m aiming 
a ray-gun at my foot and trying to shoot between my toes, without vaporizing 
them… :-)

 The easiest solution to conceptualize is to give the cache both a strong 
 (owning) and a weak reference to each object. Then, to purge the cache of 
 unreferenced objects, all that’s necessary is to nil the strong references. 
 Thereafter the unreferenced objects will, we hope, become deallocated, though 
 some may remain merely inaccessible. In particular, any objects referred to 
 by an autorelease pool won’t get deallocated until the pool is drained. Once 
 that’s done, as far as the app’s concerned there should be no 

Re: Tracking the retain count

[Britt Durbrow]

 On May 19, 2015, at 7:20 AM, Steve Christensen puns...@mac.com wrote:
 
 I just finished catching up on the discussion and keep coming back to the 
 fragile nature of relying on retainCount. For now you do, indeed, have the 
 option to vaporize your toes; later you may not have access to a ray gun if 
 Apple decides that it's in the best interests of all concerned that they 
 retain their toes, not their objects.
 

Restating a previous concern of mine:

 However, it’s not actually something that’s likely to get deprecated; and by 
 paying very careful attention to the rules, it should be OK to use in this 
 very narrow circumstance?
 
 If this is wrong - please (hopefully someone from Apple) correct me!


Yes, I am a bit concerned that it could become deprecated. I suppose that I 
could just override retain and release in that case; and track the retain count 
myself; although I seriously doubt that that functionality will be 
deprecated/removed as there’s too much oddball stuff that depends on it… but 
uggg… that’s nasty. To borrow a phrase from a lolcat, “DO! NOT! WANT!” :-)


 I don't know what your app architecture looks like, but was wondering if you 
 could build in a supportable method of managing what's in the cache without 
 having to do other than a few localized changes.
 
 One thought I had was to base all your cacheable objects on a class whose 
 sole function is to notify the cache when the last reference goes away, i.e., 
 when dealloc is called. If the cache kept track of all cached objects using a 
 NSMapTable with weak references then the cache itself wouldn't affect the 
 retain count, so you'd never have to be looking at that. Reads from and 
 writes to the NSMapTable would need to be protected for consistency.
 
 Does this sound like it could work?

Um… that’s just a weak link? And the only way for an instance to know that it’s 
got a reference to it outstanding is to override retain and release?

***

 On May 19, 2015, at 2:07 AM, dangerwillrobinsondan...@gmail.com wrote:

 But I'm curious if Instruments tells you anything about where to optimize. 

Yeah, I’m gonna have to do some profiling to see if my intuitive suspicions are 
anywhere near accurate… (premature optimization being the hazard that it is)

 A model that's 12 years old should surely have had memory issues on 12 year 
 old computers as much as on a modern iOS device. 

Document sizes were smaller then… and the engine has been adapted to new 
projects since it started out in life.

 
 If there's some kind of relationship to a virtual machine there must be a way 
 to give it virtual limits. 

It’s not a virtual machine that I was referring to (like the Java virtual 
machine, or like VirtualBox) but the operating system’s virtual memory support, 
aka swapping-to-disk. The engine was originally designed to just keep all the 
objects in RAM, and if physical RAM ran out, the OS would page out less used 
objects to swap space.

iOS does not do that; which is why I need to manage the memory myself.



___

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: Tracking the retain count

[Britt Durbrow]

 On May 18, 2015, at 1:11 AM, Quincey Morris 
 quinceymor...@rivergatesoftware.com wrote:
 
 On May 17, 2015, at 23:59 , Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 My understanding of retainCount is that it’s basically considered “taboo” 
 because trying to use it without knowing exactly what you are doing tends to 
 lead to pitfalls, and most people looking at it tend to think it means 
 something that it doesn't.
 
 You’re right to be cautious, but you’ve come to the wrong conclusion. From OS 
 X 10.0 to 10.5 (and beyond for numerous apps), memory was managed manually 
 with ‘retain’ and ‘release’, and that certainly is “using” the retain count.

Yup. I started this whole cocoa-flavored adventure with the Currency Converter 
tutorial way back on 10.0 running on a G4 with the rounded plastic case. I’ve 
done it the manual way, taken out the trash (er, run under Garbage Collection), 
and transitioned my codebase to ARC too… :-)

 
 What was frowned upon was reckless *reasoning* about retain counts: “If the 
 retain count is such and such, and I do so and so, then XYZ will happen”. 
 Those sorts of arguments tended to blow up in peoples’ faces**.
 
 It is, however, valid to increment the retain count of a valid (that is, 
 live) object, and to reason that the object will stay alive at least until 
 you decrement the retain count. This is sufficient for your scenario.
 
 
 ** For example: If the retain count is 1, and I decrement it, the object 
 will be deallocated.” This is incorrect reasoning, because any code that 
 checks and decrements the retain count is subject to side effects that affect 
 the outcome.
 



In order to maintain graph coherency the object pool controller must ensure 
that there is only ever one object in memory with a particular UUID. 
Consequently, I can’t just have the object pool controller release the objects 
without assurance that nothing else is going to keep it around (and potentially 
use it after the object pool controller has replaced it with another object 
with the same UUID, reloaded from disk).

Holding a weak link to the objects as well as a strong link does satisfy that 
constraint… but it’s a definite code smell” (somewhat related to “don’t repeat 
yourself”) and it eats more memory, etc. I’ll do it if I have to, but…

Is the reasoning that:

1: Not under ARC;
2: There is one known strong link to an object;
3: retainCount returned 1

Therefore, the only strong link to the object is the known strong link 
specified in item 2.

… is that not valid? If not, why not?

Note that I am *not* asserting that it will be deallocated, just that nothing 
else has a strong link to it that could use it in a detrimental way (most 
importantly, mutate it).

:-)
___

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: Tracking the retain count

[Britt Durbrow]

 
 On May 18, 2015, at 11:38 AM, Quincey Morris 
 quinceymor...@rivergatesoftware.com wrote:
 
 On May 18, 2015, at 10:52 , Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 Is the reasoning that:
 
 1: Not under ARC;
 2: There is one known strong link to an object;
 3: retainCount returned 1
 
 Therefore, the only strong link to the object is the known strong link 
 specified in item 2.
 
 … is that not valid? If not, why not?
 
 No, I think not. There are at least 2 dimensions of variability that can 
 break this reasoning: time and threads. Furthermore, the assumption that your 
 peek at the object state will reliably (or ever) return a retain count of 1 
 as opposed to (say) 2 is flawed. For example, if the object is in the 
 autorelease pool, you’ll see a count of at least 2, but you won’t be able to 
 deduce why.
 

The object graph is not thread-safe; so I don’t think that applies?

If some objects are in autorelease pools, that means that there is a strong 
link to them out there somewhere (presumably on the stack or in a register 
where it’s going to go away once the stack frames get popped) and the object 
pool controller shouldn’t let go of the object yet. Hopefully there will be 
enough else that can be released that the memory pressure gets satisfied. Also, 
I can set a flag to cause the object pool controller to re-scan the pool for 
objects to release after the main autorelease pool is drained in the main event 
loop.

 Note that I am *not* asserting that it will be deallocated, just that 
 nothing else has a strong link to it that could use it in a detrimental way 
 (most importantly, mutate it).
 
 Just so, so I think you need to disentangle the following things:
 
 1. Whether an object is in your data model’s object graph. Note that there is 
 an implicit extended object graph beyond the references between the objects 
 themselves. For example, if an object is (say) set as the delegate of some 
 service, but is no longer in your actual object graph, it may get a delegate 
 message that causes it to intrude unexpectedly. In that case, it’s 
 effectively still in your object graph.
 

Right, which is why I can’t have the object pool controller just drop an object 
unless the pool controller is the only one with a strong link to the object.

 2. Whether an object is alive (has or has not reached dealloc). You actually 
 don’t care about this, though we haven’t convinced you of that yet. ;)
 

Actually what I care about is if anybody can access the object. I don’t care if 
it has reached dealloc yet or not. If the object is reachable, it has to keep 
it’s singular identity.

 3. Whether an object is discardable from memory in case of (for example) 
 memory pressure.
 
 Currently, you’re trying to achieve #1 and #3 by thinking in terms of #2. 
 However, #2 is the one thing you can’t actually control — in any very direct 
 and deterministic way.

I don’t think I need to control it per se, just catch a very specific case: 
that nothing has a strong link besides the one held by the object pool 
controller.

 
 You currently have an app that controls #1 directly. You’ve also been offered 
 several ways of controlling #3 directly, one of which is to forcibly 
 increment or decrement the retain count in deterministic ways. Your unease is 
 making you think of this as an attempt at #2, but it’s not. It’s really #3.
 
 


I haven’t fully rejected the double pointer weak-link strategy… I’m just, as 
you said, uncomfortable with it, and don’t (as of yet) see it as *necessarily* 
less ugly than looking at retainCount in this very specific case...






***

 On May 18, 2015, at 11:25 AM, Ken Thomases k...@codeweavers.com wrote:
 
 On May 18, 2015, at 12:52 PM, Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 In order to maintain graph coherency the object pool controller must ensure 
 that there is only ever one object in memory with a particular UUID. 
 Consequently, I can’t just have the object pool controller release the 
 objects without assurance that nothing else is going to keep it around (and 
 potentially use it after the object pool controller has replaced it with 
 another object with the same UUID, reloaded from disk).
 
 Can you have some sort of -invalidate method on the objects that puts them 
 into a state where they can't be used or confused with a subsequently-loaded 
 object?  If necessary, it could clear the UUID or whatever.
 
 Regards,
 Ken
 

There is a large body of pre-existing code that relies on this system; in order 
to do that I would have to retrofit checks for validity onto every point where 
the object graph is accessed. At the very least, that’s a *major* project, 
time-wise, and is also probably a good way to introduce lots of bugs into two 
other large projects…

Also, just clearing the UUID doesn’t

Re: Tracking the retain count

[Britt Durbrow]

Unfortunately I don’t think NSCache will work for me in this situation.

The objects in the pool have a UUID that is used to maintain the graph 
structure’s coherency when it’s partially or entirely on disk. In RAM, there 
can be only one object per UUID; but if something points to an object that the 
cache is trying to evict, that object won’t get deallocated from RAM (because 
it’s retain count isn’t zero post eviction) but the object pool controller 
won’t know about it still being in RAM (as it’s no longer in the cache), and 
when the controller attempts to reload it from disk; there would be multiple 
in-memory objects purporting to have the same UUID. As is oft claimed about 
these sorts of situations, hilarity would ensue…

Keeping multiple pointers to the same object strikes be as ugly also… perhaps 
more ugly than just looking at retainCount: it does more or less the same 
thing, but with a greater footprint (memory, CPU, and battery).

My understanding of retainCount is that it’s basically considered “taboo” 
because trying to use it without knowing exactly what you are doing tends to 
lead to pitfalls, and most people looking at it tend to think it means 
something that it doesn't. However, it’s not actually something that’s likely 
to get deprecated; and by paying very careful attention to the rules, it should 
be OK to use in this very narrow circumstance?

If this is wrong - please (hopefully someone from Apple) correct me!

:-)
___

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

Tracking the retain count

[Britt Durbrow]

Ughh… I find myself in a bit of a quandary:

I have a pool of disk-backed (well, flash-backed on iOS) objects that have an 
arbitrary graph structure. These are managed by a central object pool. The 
object pool is supposed to cache these in memory (creating them is somewhat 
non-trivial), and hold onto ones that it’s been told to even if there are no 
other objects that currently have an active pointer to them outside of the 
pool’s object graph (consequently, just using weak links won’t work for my 
problem).

In order to respond to iOS memory pressure warnings, I need to have the object 
pool de-construct and release any graph segments that are not currently being 
used outside of the object pool. However, this needs to happen only during a 
memory pressure event, and not otherwise.

The only thing I’ve been able to come up with so far is somehow tracking the 
retain count state of the objects in the object pool, and when a memory 
pressure event occurs having the object pool find all the objects that are only 
in use in the graph and held by itself, and release them. Once all the 
otherwise unused objects have been converted via an isa swizzle to faults (and 
thusly no longer contain retain cycles), the faulted objects that are 
candidates for release should have a retain count of 1… at which point I can 
have the pool remove them from it’s main NSMutableDictionary (which will now 
cause them to be deallocated).

This, however, is kinda ugly… and known to be prone to pitfalls... but is there 
any better way?

Note that I don’t want to just use CoreData. Also, I did think of having the 
objects in the graph that are supposed to be held on to be held in a strong 
container, and the objects not currently being held on to in a weak container, 
but that doesn’t work because then the objects in the weak container will get 
purged when immediately, not just under a memory pressure event.


So what I’m looking at now is creating an intermediate base class for all of 
these objects, that is compiled with ARC turned off, and provides access to 
retainCount. Yes, I know that it doesn’t reflect any autoreleases that have 
occurred on the object. This is OK as far as I know - for this specific use, if 
something has an outstanding autorelease on an object, it’s probably OK to keep 
it around, as long as enough of the cached objects get purged to satisfy the 
memory pressure event. Also, this object pool is not guaranteed to be 
thread-safe so I don’t think that the potential race conditions of 
retain/release/autorelease/retainCount interaction will come into play.


Any ideas? Comments? Rotten tomatoes? :-)
___

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

MKMapView maximum zoom?

[Britt Durbrow]

I’m trying to write an app (on both OS X and iOS) that uses MapKit to display 
and edit data on a map; including in-building maps (i.e, floor plans). However, 
the maximum zoom level of MKMapView is insufficient for this; and my attempts 
to zoom it in further seem to be getting clipped. The documentation for 
MKMapView does not seem to have any property where I can set the maximum zoom 
level - or at least; I can’t seem to find it.

Am I just missing something, or is this in fact a limitation of MapKit?
___

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: WTF is happening?

[Britt Durbrow]

 In this case you have found that the implementation of +[_NSObjectAnimator 
 resolveInstanceMethod:] crashes. 

IMHO, this is a nasty little bug… and a simple test case should be added to the 
frameworks to check that basic runtime functionality works on all classes - 
private or publicly declared. Even if nothing else is guaranteed, if a thing 
says it’s a class, then it really kinda’ should act like one.

 In general it is not safe to look up arbitrary classes and then send messages 
 to them.

True. However, he called a C runtime function… it happens that that function 
invokes the forwarding mechanism, but it’s still a basic runtime C function, 
below the level of the NSObject abstractions… so it really *should* work...

 Checking for conformance (using the C function, not the NSObject method) to a 
 protocol you defined and then only sending messages from that protocol is the 
 safest way to go.

I would (and in my own code, do) combine that with the suggestions to 
interrogate the bundle being loaded for classes to be examined, as well as do 
registration of classes in +load… I also post some notifications of my own at 
various key points in my app startup cycle that various interested classes can 
hook to.

 On Dec 15, 2014, at 3:36 PM, Maxthon Chan m...@maxchan.info wrote:
 
 I ended up written my own runtime-level equivalent of +[NSObject 
 isSubclassOfClass:] using only class_getSuperclass and object_getClass. This 
 class scanning code, currently used for plugin scanning, will also be used in 
 jailbreak detecting, defeating Cydia Substrate-based iAP crackers.

You need to be very careful of how you implement that so that a future OS 
update doesn’t break your app…


___

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: Checking security settings?

[Britt Durbrow]

If I can’t find an officially supported way to do this, then yeah - that’s what 
I figure I’ll have to do. I was trying to avoid it due to user experience 
issues; requiring a  second login, etc is cumbersome every time somebody wants 
to record something in the app… sigh Oh well...


On Sep 5, 2014, at 8:59 AM, Jens Alfke j...@mooseyard.com wrote:

 It might be better to make your app itself enforce the HIPAA requirements — 
 for example, blank the application's windows after a period of no activity, 
 and require a passcode to un-blank them. That won't involve any sandboxing 
 issues.
 
 —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: Checking security settings?

[Britt Durbrow]

Heh… fortunately I’m *very* early in the design of this, so yeah… nothing is 
set in stone yet. :-)
 
On Sep 5, 2014, at 11:20 AM, SevenBits sevenbitst...@gmail.com wrote:

 On Friday, September 5, 2014, Quincey Morris 
 quinceymor...@rivergatesoftware.com wrote:
 
 On Sep 5, 2014, at 10:15 , Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com javascript:; wrote:
 
 If I can’t find an officially supported way to do this, then yeah -
 that’s what I figure I’ll have to do. I was trying to avoid it due to user
 experience issues; requiring a  second login, etc is cumbersome every time
 somebody wants to record something in the app… sigh Oh well...
 
 It was never a workable idea, though. It’d be just as bad for a user to
 set a password of ‘123456’ as having no password, for example, and there’d
 never be an API that *told* you what the password was so you could check if
 it was good enough. Similarly, you’d never have a way of checking that the
 current screensaver actually *obscured* the screen contents.
 
 
 That's very true - my current screensaver for example applies visual
 effects to my screen - it distorts, but does not obscure, my screen
 contents. Under HIPAA your idea was never workable due to practical
 limitations.
 

Perhaps… most of the time there’s no data displayed onscreen; but there is an 
NSStatusItem that I need to keep “unauthorized” persons from interacting with… 
Also, there are distributed notifications that I can trap to lock any data 
display windows that do happen to be up when the screen locks.

IANAL, but my understanding was that the quality of a user’s password was not a 
HIPAA requirement, just that there needed to be some method of user 
authentication (not that accepting ‘123456’, ‘monkey’, etc. is a good idea; 
just that it’s not **legally** required).


 
 
 Given the rumors floating around about next week’s grand revelation event,
 you might also want to hold off making any decisions until you see what
 Apple will have to offer. With Health Kit, Home Kit, wearables and payments
 being bruited, there might turn out to be something secure that would ease
 the second-login problem.
 
 
 Second.
 

I doubt that there will be any new APIs announced at that event… but even so, 
um, yeah… :-)


I wonder if we’ll ever get TouchID on the desktop?
___

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

Checking security settings?

[Britt Durbrow]

I need to verify that the user has a login password set; and to verify that 
they have a screensaver turned on with a password requirement (I’m trying to 
make sure that the workstation is HIPAA compliant before launching my app). I 
don’t need to actually fetch the password or change the system settings; just 
make sure that they exist. Is there an API for this? (I’d much rather not try 
to go spelunking around in prefs files myself… and I’d like to keep my app 
sandbox friendly as well)



___

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: copy and mutableCopy

[Britt Durbrow]

Oh, and if you are implementing something like this, don’t forget to trap 
writes to both the copy *and* the original object:

myMutableClass *a=[myMutableClass makeAnObjectWithSomeBuffer:aBuffer];
myMutableClass *b=[a mutableCopy];

[a mutateTheBuffer];

doing [a isEqual:b] should return NO; but if you didn’t trap the write to the 
original object and cause the COW copies to actually do the copy then it will 
erroniously return YES (and all sorts of other havoc will likely ensue…)


On Apr 27, 2014, at 4:06 AM, Maxthon Chan xcvi...@me.com wrote:

 Immutables copied are just retained and returned, and mutableCopied are COW.
 
 Mutables copied generates COW.
 
 That would be the fastest way implementing that.
 
 * COW = copy on write
 
 On Apr 27, 2014, at 17:06, John McCall rjmcc...@apple.com wrote:
 
 On Apr 27, 2014, at 2:00 AM, Dave d...@looktowindward.com wrote:
 A long time back, I remember reading something about the way in which copy 
 and mutableCopy are implemented. I think basically it said that:
 
 someObject = [someOtherObject copy];
 
 or 
 
 someObject = [someOtherObject mutableCopy];
 
 Wouldn’t necessarily allocate any extra data storage. I’ve been searching 
 for it to refresh my memory, but I can’t see to find it anywhere. Does 
 anyone know if this document or something like it exists somewhere?
 
 I don’t know if there’s a document, and like a lot of things with ObjC the 
 actual guarantees are pretty weak, but implementations of these methods on 
 immutable types have been turning into essentially “return [self retain]; 
 for quite some time.  But that’s when the actual dynamic type is 
 guaranteed-immutable, e.g. something constructed as an NSArray, not just 
 something that’s immutable by convention, e.g. an NSMutableArray that you’re 
 passing around as an NSArray.
 
 John.
 ___
 
 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/xcvista%40me.com
 
 This email sent to xcvi...@me.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/bdurbrow%40rattlesnakehillsoftworks.com
 
 This email sent to bdurb...@rattlesnakehillsoftworks.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: Sandboxing die.die.die

[Britt Durbrow]

I don't think that it's physically possible to resolve this issue - basically, 
we're trying to have our cake (er, have our security) and eat it too (er, use 
the functionality of the app).

Consider a 'shoebox' app that doesn't deal with run-of-the-mill media (photos, 
movies, etc)... let's say it manages CAD/CAM files - something that Apple won't 
have an API for. And it integrates into your CAD/CAM programs via plugins, and 
an intranet/internet/cloud document sharing system. By definition, the only 
behavioral difference between this app and a cyber-espionage-enabled app is 
where the data gets sent: the good app sends it to 
MyAwesomeCloudCollaborationSite.com, the bad app also sends it to 
EvilHaxorsGonnaSpyOnYou.com... and there's no programatic way to tell the 
difference between the two.

Or perhaps a more widespread target: an app that manages receipts and credit 
card data, no matter where in the file system they end up (email, PDFs, MS 
Office documents, whatnot), and integrates with a cloud system for 
collaborating with accountants, banks, the IRS, etc... again, the only way a 
good app differs from a bad one is who is on the other end of the network 
socket.

Security is always at odds with ease-of-use and functionality; and while an 
insecure system can be useless due to the inability to trust it, an overly 
secure system will be also useless because the security measures prevent it 
from doing it's job... so by demanding total security (all MAS apps must be 
sandboxed); Apple has also rendered an entire class of apps nonfunctional. Part 
of the rationale that I've heard for the current set of sandboxing requirements 
is that it protects unsophisticated users... who, unfortunately, are the very 
users who would need a cross-app shoebox system the most.

(note: due to that 90% sales figure, for the purposes of this discussion, I am 
considering not selling thru the MAS to be a non-option for economic reasons; 
even though technically speaking, as of today an unsandboxed-but-signed app 
works OK on a default install of Mountain Lion)
___

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: Sandboxing die.die.die

[Britt Durbrow]

On Aug 22, 2012, at 7:16 PM, Graham Cox graham@bigpond.com wrote:

 
 On 23/08/2012, at 11:33 AM, Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 there's no programatic way to tell the difference between the two
 
 
 Indeed, which is why you need to encourage the use of human intelligence 
 instead, which very often can tell when something is fishy.
 
 When a computer needs to do something truly intelligent, it's usually a good 
 idea to defer to the user.
 
 --Graham

Which, unfortunately, leads us to the Dancing Pigs problem... sigh

http://en.wikipedia.org/wiki/Dancing_pigs
___

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: Classes incompatible with weak references

[Britt Durbrow]

On Aug 16, 2012, at 4:37 AM, Vincent Habchi vi...@macports.org wrote:

 On 16 août 2012, at 03:11, Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 objects must be 16-byte aligned - and that alignment requirement isn't 
 likely to go down, but rather up in the future; using the low bits doesn't 
 really cause the same issue that using the high bits did.
 
 Well, I partly disagree. There is no real difference in using MSB or LSB. At 
 some point in the future, Intel can decide to use low bits to serve some 
 specific hardware purpose, like signaling uncachable addresses on a fine 
 granularity, indicating what core had fetched the pointer, or deciding at 
 fetch time what kind of info is being accessed and route the incoming data 
 accordingly, and so on.
 

Well, they *could*, but I don't think they *will*. Doing that would cause so 
many problems that I think it's totally unfeasible:

1) At the hardware level, pointers are just unsigned integers. The same 
instruction used to fetch an integer is used to fetch a pointer.
2) Pointer arithmetic would be totally messed up. Code that did pointer 
arithmetic as unsigned integers would break (yes, I know it's outside of the 
spec for many languages, C included, but a lot of software already out there 
does this, even though it's not really supposed to. It isn't outside the spec 
for assembler though, and there's a lot of assembler out there too).
3) Due to 1 and 2, they would have to introduce a set of new instructions that 
just do pointer handling on large objects.
4) You wouldn't be able to use the same kind of pointer to reference small 
objects (char, short, etc) as large objects (i.e, stuff with the 16-byte 
alignment requirement). Also, conversion from one type to the other would be 
impossible without loosing data.
5) Backwards compatibility - both binary and source level - would be totally 
broken... a *major* consideration for Intel.
6) The runtime would have to mask off the low bits of the address anyway in 
order to follow the isa pointer - if Intel did as you suggest they might; the 
runtime could handle this by treating the pointer as a purely computed address; 
not a fetched one.
7) And other stuff that I'm sure I'm missing at the moment.

The same considerations also apply to any existing architecture (i.e, ARM, etc) 
that would do that; and most of them would apply to any potential new 
architecture.


 Oh, and it bit the Mac too - anybody remember the Mode32 extension from the 
 System 7 era?
 
 At that time I wasn’t developing on Mac, which was far too expensive for the 
 means of a poor student. But I clearly remember having written the equivalent 
 for the Atari TT/Falcon, MMUPATCH.BIN, a short TSR assembly code that would 
 tinker with the MMU of the 68030 to redirect all logical addresses XXYY 
 towards physical addresses 00YY. That was a clear kludge, but it 
 prevented some occasional bombing ;)
 
 Vincent
 
 

As I recall (heh, it's been a while! :-) the Mac Toolbox ROM's Memory Manager 
used to stuff metadata about handles (relocatable pointers-to-pointers) in the 
high bits of an address; and what Mode32 did was to patch the trap table to use 
the newer 32-bit clean Memory Manager routines on machines that had the older 
ROM installed (I don't *think* it patched out the whole ROM, but I could be 
mistaken... as I said, it's been a while).

 
 ___
 
 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/bdurbrow%40rattlesnakehillsoftworks.com
 
 This email sent to bdurb...@rattlesnakehillsoftworks.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: __weak pointer collection firing prematurely???

[Britt Durbrow]

OK, I think I've isolated the issue... basically, __weak, @public, and 
-fno-objc-arc don't like to play nice together. If you set a @public __weak 
instance variable (may also apply to stack variables, I haven't tested that 
yet) in a file compiled with -fno-objc-arc, and then access it in a file 
compiled with ARC turned on, the variable gets zeroed out.

I have reduced it to a simple test project, and I'm going to file a RADAR.
___

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: __weak pointer collection firing prematurely???

[Britt Durbrow]

(Um... looks like the list server ate my previous attempt to send this... so if 
you're getting this twice, sorry!)

OK, I think I've isolated the issue... basically, __weak, @public, and 
-fno-objc-arc don't like to play nice together. If you set a @public __weak 
instance variable (may also apply to stack variables, I haven't tested that 
yet) in a file compiled with -fno-objc-arc, and then access it in a file 
compiled with ARC turned on, the variable gets zeroed out.

I have reduced it to a simple test project, and I'm going to file a RADAR.
___

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: __weak pointer collection firing prematurely???

[Britt Durbrow]

On Aug 15, 2012, at 4:46 PM, John McCall rjmcc...@apple.com wrote:

 On Aug 13, 2012, at 11:38 PM, Britt Durbrow wrote:
 OK, I think I've isolated the issue... basically, __weak, @public, and 
 -fno-objc-arc don't like to play nice together. If you set a @public __weak 
 instance variable (may also apply to stack variables, I haven't tested that 
 yet) in a file compiled with -fno-objc-arc, and then access it in a file 
 compiled with ARC turned on, the variable gets zeroed out.
 
 I have reduced it to a simple test project, and I'm going to file a RADAR.
 
 Please do;  maybe we can find a way to warn about the assignment to a __weak 
 object in non-ARC.  That said, your code is buggy;  we do *not* guarantee 
 anything about the representation  of a weak object, and it is not legal to 
 access one in non-ARC code except by explicitly calling one of the specified 
 runtime functions (and we don't encourage you to do that).
 
 John.

Done. rdar://12101247

The ARC documentation does not seem to indicate that the appropriate runtime 
function is not emitted by the compiler when -fno-objc-arc is in effect... and 
given that it's automatic *retain counting* that I thought I was turning off; 
and not other parts of the runtime system, it's kinda counterintuitive (well, 
it is to me at least :-) to have the compiler silently generate erroneous code 
- especially when the result is a value changing on a *read* operation!

I would expect either: a) the compiler would always emit the correct runtime 
call for a __weak assignment no matter if ARC is on or off; or b) the compiler 
would throw an error when an attempt to access a __weak variable is made 
without ARC turned on (I don't think a warning is sufficient; given that it 
really does mess things up). If the runtime functions that implement the __weak 
access system are written in C and need to be able to emit a low-level 
primitive pointer access to avoid recursion, perhaps adding a compiler flag to 
disable the error (and cause the existing direct access to be emitted) or 
having it emit a direct access when the variable is explicitly cast to a non 
__weak type would handle that issue - in other words

__weak id someVar;
((void *)someVar)=aNewValue;

could be setup to only generate mov opcodes; and not a call into the runtime. 
(Obviously, if it's in fact written in assembler, then recursive call emission 
won't be an issue :-)



___

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: Classes incompatible with weak references

[Britt Durbrow]

That exists already in Lion with NSNumber objects: some types of pointers to 
NSNumbers actually use the low bits of the pointer to indicate the type and the 
rest of the pointer to pack the value; resulting in not needing to actually 
allocate an object off the heap (which is why direct isa access was 
depreciated). Given that objects must be 16-byte aligned - and that alignment 
requirement isn't likely to go down, but rather up in the future; using the low 
bits doesn't really cause the same issue that using the high bits did.

Oh, and it bit the Mac too - anybody remember the Mode32 extension from the 
System 7 era?

More info can be found here:
http://objectivistc.tumblr.com/post/7872364181/tagged-pointers-and-fast-pathed-cfnumber-integers-in


On Aug 14, 2012, at 12:09 AM, Vincent Habchi vi...@macports.org wrote:

 Le 13 août 2012, à 23:47, Mike Abdullah cocoa...@mikeabdullah.net scripsit:
 
 An idea I've vaguely wondered about would be turning the isa variable into a 
 tagged pointer. If you know nothing is accessing it directly (to do so was 
 deprecated with the modern runtime), then, say, the last 4 bits of the 
 pointer could be used to record the retain count. Once they're used up (for 
 those rare, highly retained 
 
 Using part of pointer to do something else than record an address is 
 perilous. I remember, once again in the old days of the 68000 on the Atari 
 ST, which had a 24-bit external address bus (and not 20 as I wrote before on 
 some other thread), and 32-bit internal address registers, some developers 
 had figured out to use the MSB (unused) of these address registers (pointers) 
 to store extra information. Now, two years later the 68020 with full 32-bit 
 external address bus was released, and suddenly all the code relying on that 
 trick broke on the TT and later machines…
 
 Vincent
 
 
 ___
 
 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/bdurbrow%40rattlesnakehillsoftworks.com
 
 This email sent to bdurb...@rattlesnakehillsoftworks.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

__weak pointer collection firing prematurely???

[Britt Durbrow]

I am looking at something very strange. I have a document object, that has an 
object that it owns; which has a __weak pointer back to the document object. 
Another object also has an indirect pointer to the document object. So, 
something like this:

@interface MyDoc : NSDocument
{
MySubObj *subObj;
}
@end

@interface MySubObj : NSDocument
{
@public
__weak MyDoc *doc;
}
@end

@interface SomeOtherObject : NSObject
{
MySubObj *subObj;
}
@end

During the execution of MyDoc's init method, an instance of MySubObj is 
created, and stored in the document's ivar. During MySubObj's init method, the 
__weak pointer back to the document object is set. This seems to work OK - I've 
traced it thru in the debugger. Then, an instance of SomeOtherObject is 
created, and it's subObj ivar is set. Again, works OK. The next thing 
SomeOtherObject does is to load a local variable with a reference to the 
document object, by copying it out of MySubObj's public __weak doc pointer.

OK, now the strange part: performing that copy causes the __weak doc ivar to 
get zeroed. I''ve watched it in the debugger; before executing that line of 
code, it's got the right value; after, it's nil. Changing __weak to 
__unsafe_unretained makes the problem go away.

This is the exact line of code in question:

TrDocument *document=(TrDocument *)__RPCPersistentInfo__pool-document;

The document object in question is, when this happens, still in the middle of 
it's init method when that __weak __RPCPersistentInfo__pool-document variable 
gets zeroed out.

Has anyone ever seen anything remotely like this? How and why is it happening 
on a *read*, of all places (I would have expected it to occur on a scope 
transition, where ARC would have possibly fired to do a release)? And do I need 
to worry about other places where I'm using __weak?

Oh, and this is on 10.8, with Xcode 4.4.1.

ANY insight would be much appreciated!
___

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: __weak pointer collection firing prematurely???

[Britt Durbrow]

On Aug 13, 2012, at 1:00 AM, Quincey Morris 
quinceymor...@rivergatesoftware.com wrote:

 On Aug 13, 2012, at 00:04 , Britt Durbrow 
 bdurb...@rattlesnakehillsoftworks.com wrote:
 
 This is the exact line of code in question:
 
 TrDocument *document=(TrDocument *)__RPCPersistentInfo__pool-document;
 
 The document object in question is, when this happens, still in the middle 
 of it's init method when that __weak __RPCPersistentInfo__pool-document 
 variable gets zeroed out.
 
 There's nothing about the fact that the document is executing a method that 
 prevents it from being deallocated before the method ends. It's really only a 
 question of whether there's a strong reference being maintained at the 'init' 
 call site for the duration of the 'init' call (assuming that, since the 
 document is in the process of being created, there can't be any strong 
 reference anywhere else yet).
 
 So, before focusing too much on the the load of the weak reference, I'd 
 suggest you implement a 'dealloc' override in the document class, set a 
 breakpoint there, and see what's actually triggering deallocation.
 
 

Did that - no go. The dealloc method is not being called. Also, there's a 
printf statement in the dealloc method as well, so it's not just that the 
debugger is missing the breakpoint; the document object is in fact not being 
deallocated.



___

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

Anybody know why instantiateNibWithOwner:topLevelObjects: was deprecated?

[Britt Durbrow]

Well... the subject line kinda says it all... before I file a bug... does 
anybody know why NSNib's instantiateNibWithOwner:topLevelObjects: was 
deprecated?
___

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: Anybody know why instantiateNibWithOwner:topLevelObjects: was deprecated?

[Britt Durbrow]

On Aug 2, 2012, at 6:10 PM, Kyle Sluder k...@ksluder.com wrote:

 On Thu, Aug 2, 2012, at 05:52 PM, Britt Durbrow wrote:
 Well... the subject line kinda says it all... before I file a bug... does
 anybody know why NSNib's instantiateNibWithOwner:topLevelObjects: was
 deprecated?
 
 Because there's better API now: -[NSNib
 instantiateWithOwner:topLevelObjects:] adopts the much saner memory
 management that -[UINib instantiateWithOwner:options:] has.
 
 Alas, the new method's name is extremely similar to the deprecated
 method. I lobbied for a better name during the beta, but to no avail.
 
 Also, distressingly, -[NSNib initWithContentsOfURL:], -[NSNib
 instantiateNibWithExternalNameTable:], and all the NSBundle nib-loading
 additions are only soft-deprecated in the 10.8 SDK; thankfully, at least
 the old NSNib designated initializer is hard-deprecated.
 
 --Kyle Sluder

Which is, (very conveniently :-) missing from the class documentation.

Thanks for the heads-up!
___

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

Adding sublayer causes dropped frames?

[Britt Durbrow]

Hi -

I'm having a weird problem with Core Animation. What I've got is a  
small particle system, with one layer per particle. There are only  
10-20 particles in the system at any given time. The system updates  
the layers at 60 Hz from an NSTimer, and disables automatic animations  
during the update.


What seems to be happening is that every time a new particle is added,  
a few frames get dropped from the display (but, not the calculations).  
Logging the time delta's between timer firings shows that the timer is  
not missing firings. Turning off layer additions for new particles  
prevents the problem (i.e, the particles - with all the associated  
infrastructure, collision handling, etc - are instantiated, and added  
to the system, only the addSublayer call is skipped). It's like adding  
the layer suppresses the redraw of the view for a few cycles... ?!?


Anybody have any ideas?


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Did I find a NSScanner bug, or am I doing this all wrong?

[Britt Durbrow]

Hi --

I'm getting some really odd behavior out of NSScanner; it seems to be  
choking on character sets that only have whitespace in them.


This doesn't work:

#import Foundation/Foundation.h

int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSString *test=@   ooxxdk;
		NSCharacterSet *whiteSpaceCharSet=[NSCharacterSet  
characterSetWithCharactersInString:@\t\r\n ];


NSScanner *scanner=[NSScanner scannerWithString:test];


NSLog(@location before: %d, [scanner scanLocation]);
		BOOL result=[scanner scanCharactersFromSet:whiteSpaceCharSet  
intoString:nil];

NSLog(@location after: %d, [scanner scanLocation]);
NSLog(@result returned: %d,result);

[pool drain];
return 0;
}

... it logs this:
2008-09-21 22:58:28.399 foo[804:10b] location before: 0
2008-09-21 22:58:28.401 foo[804:10b] location after: 0
2008-09-21 22:58:28.401 foo[804:10b] result returned: 0

I expected it to log something like this:
2008-09-21 23:01:31.357 foo[844:10b] location before: 0
2008-09-21 23:01:31.359 foo[844:10b] location after: 3
2008-09-21 23:01:31.360 foo[844:10b] result returned: 1


But, changing it like so:

NSString *test=@   aooxxdk;
		NSCharacterSet *whiteSpaceCharSet=[[NSCharacterSet  
characterSetWithCharactersInString:@\t\r\n a] retain];


does work... logging this:

2008-09-21 23:01:31.357 foo[844:10b] location before: 0
2008-09-21 23:01:31.359 foo[844:10b] location after: 4
2008-09-21 23:01:31.360 foo[844:10b] result returned: 1

I get similar results swapping tabs and/or cr's for the leading spaces  
on the test string; as well as using the standard [NSCharacterSet  
whitespaceAndNewlineCharacterSet].


Anybody have any ideas why this isn't working?


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

[SOLVED] Did I find a NSScanner bug, or am I doing this all wrong?

[Britt Durbrow]

Your problem is that you need to set the characters to be skipped to
something other than what you are trying to scan.



Bingo! It's working now. Thanks. :-)
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]