Well, to close this thread, for anyone curious...
I've tried on the same Mac, with the same Xcode version (13.2.1), on both macOS
11.6.6 vs 12.3.1, and it seems to be the OS that makes the difference. On 11,
TSan correctly gives no error; but on 12 it gives this incorrect error about
there bei
On 19 Apr 2022, at 19:35, Rob Petrovec wrote:
> The docs for NSEnumerationConcurrent state that it is a hint and may be
> ignored at run time.
Ah, so they do. I had only checked in the header file.
OK, one less mystery.
Sean
___
Cocoa-dev mailing l
visible to you but is silently changing things
>> under the hood.
>
> In case it wasn't clear, the code snippet in my email actually reproduces the
> issue. I created a fresh Xcode project and it's literally just:
>
> - (void)applicationDidFinishLau
created a fresh Xcode project and it's
literally just:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
NSArray* array = @[@5, @6, @7, @8, @9, @10, @11];
[array enumerateObjectsWithOptions:NSEnumerationConcurrent
usingBlock:^(NSNumber* num, NSUIn
a CoW
optimization, that is not visible to you but is silently changing things under
the hood. In any case, I would generally suggest using -[NSArray
enumerateObjectsAtIndexes:options:usingBlock:] with the NSEnumerationConcurrent
flag, which should rule out any issues with concurrent access on
Hi all,
If one wants to do something with every item in an NSArray in a concurrent way,
is the following safe/correct?
NSArray* array = @[@5, @6, @7, @8, @9, @10, @11];
dispatch_apply([array count], DISPATCH_APPLY_AUTO, ^(size_t idx) {
id unused = array[idx];
});
Here of
> On Aug 19, 2016, at 9:56 PM, Charles Srstka wrote:
>
>>> So for the foreseeable future, the
>>> difference is that +array returns an autoreleased object, meaning that in
>>> ARC code, +new is the better choice.
>>
>> I would not make that ass
> On Aug 19, 2016, at 8:25 PM, Kyle Sluder wrote:
>
>
>
> On Fri, Aug 19, 2016, at 06:08 PM, Charles Srstka wrote:
>>> On Aug 19, 2016, at 3:46 PM, Quincey Morris
>>> wrote:
>>>
>>> On Aug 19, 2016, at 10:53 , Charles Srstka >> <
On Fri, Aug 19, 2016, at 06:08 PM, Charles Srstka wrote:
> > On Aug 19, 2016, at 3:46 PM, Quincey Morris
> > wrote:
> >
> > On Aug 19, 2016, at 10:53 , Charles Srstka > <mailto:cocoa...@charlessoft.com>> wrote:
> >>
> >> [NSArray array
> On Aug 19, 2016, at 3:46 PM, Quincey Morris
> wrote:
>
> On Aug 19, 2016, at 10:53 , Charles Srstka <mailto:cocoa...@charlessoft.com>> wrote:
>>
>> [NSArray array] is a synonym for [[[NSArray alloc] init] autorelease].
>
> (along with other similar
> On Aug 19, 2016, at 1:46 PM, Quincey Morris
> wrote:
>
> My point is that Apple might revisit the implementation of NSArray at any
> time (in these Swiftian days, stranger things have happened), and choose to
> write it with full ARC compatibility, which means ther
Even though new has been a synonym for alloc] init] for decades.
I really just meant anxiety about one app using two different patterns for the
same thing. Same thing if the app used “new” in some places and “alloc/init” in
others.
On Aug 19, 2016, at 10:53 , Charles Srstka wrote:
>
>
> On Aug 20, 2016, at 2:50 AM, Quincey Morris
> wrote:
>
> AFAICT, the main reason *not* to use ‘new’ is to avoid generating anxiety for
> those who come back to read the code later, and who might worry that the
> inconsistency means something.
Even though new has been a synonym for alloc]
array = [NSArray new] and
array = [NSArray array]
-- Should be interchangeable under ARC.
Kirk Kerekes
(iPhone)
> On Aug 19, 2016, at 12:22 PM, cocoa-dev-requ...@lists.apple.com wrote:
>
> array = [NSArray new] or array = [NSAr
To all who replied, thank you. This is awesome.
Thanks for outlining the difference between the two. Now I know and can ignore
it. But if I didn't, I'd always be wondering.
This certainly puts my mind at ease. Well, at least with regards to [NSArray
new]. Other issues shall rema
s safe?
>
> I have seen this in some code in our codebase:
> array = [NSArray new];
>
> I'm familiar with using the public method from the NSArray header and what
> the docs say to use:
> or array = [NSArray array];
>
> Is there any risk to using [NSArray new] to init
t literals, but I have a different question here.
>
>
> Is this safe?
>
> I have seen this in some code in our codebase:
> array = [NSArray new];
>
> I'm familiar with using the public method from the NSArray header and what
> the docs say to use:
> or array
fe?
>
> I have seen this in some code in our codebase:
> array = [NSArray new];
>
> I'm familiar with using the public method from the NSArray header and what
> the docs say to use:
> or array = [NSArray array];
>
> Is there any risk to using [NSArray new] to in
On Aug 16, 2016, at 02:20 , Alex Zavatone wrote:
>
> Is there any risk to using [NSArray new] to init an array instead of [NSArray
> array]??
The only real difference between the two is the ownership semantics of the
returned object. For ‘new’ it’s +1 and for ‘array’ it’s +0. Howev
a resend. Sorry
> if it gets to some of you twice.
>
>
>
> Yes, I know about literals, but I have a different question here.
>
>
> Is this safe?
>
> I have seen this in some code in our codebase:
> array = [NSArray new];
>
> I'm familiar with using the publi
iterals, but I have a different question here.
>
> I have seen this in some code in our codebase:
> array = [NSArray new];
>
> I'm familiar with using the public method from the NSArray header and what
> the docs say to use:
> or array = [NSArray array];
>
> Is
I sent this out this morning but it got eaten, so this is a resend. Sorry if
it gets to some of you twice.
Yes, I know about literals, but I have a different question here.
Is this safe?
I have seen this in some code in our codebase:
array = [NSArray new];
I'm familiar with usin
Yes, I know about literals, but I have a different question here.
I have seen this in some code in our codebase:
array = [NSArray new];
I'm familiar with using the public method from the NSArray header and what the
docs say to use:
or array = [NSArray array];
Is there any risk to
On Feb 20, 2016, at 00:25 , Jean-Daniel Dupas wrote:
>
> Even if swift is planning to provide a Foundation framework, one of the
> strong requirement is that it must be source compatible with the Apple
> Foundation, as that is the one that will be used on Apple platforms. So if it
> does not b
> Le 20 févr. 2016 à 07:28, Quincey Morris
> a écrit :
>
> On Feb 19, 2016, at 22:14 , Gerriet M. Denkmann wrote:
>>
>> Is there (yet) a Swift version of ‘[NSString stringWithFormat: “%08lx”,
>> (someCast) someValue]’ ?
>
> No, and yes, and no, and yes.
>
> There is currently AFAIK no such
On Feb 19, 2016, at 22:14 , Gerriet M. Denkmann wrote:
>
> Is there (yet) a Swift version of ‘[NSString stringWithFormat: “%08lx”,
> (someCast) someValue]’ ?
No, and yes, and no, and yes.
There is currently AFAIK no such native formatting syntax in Swift print
statements, so “no”.
But you ca
> On 20 Feb 2016, at 14:14, Gerriet M. Denkmann wrote:
>
>
>> On 20 Feb 2016, at 13:02, Quincey Morris
>> wrote:
>>
>> On Feb 19, 2016, at 21:30 , Gerriet M. Denkmann wrote:
>>
>> Now that I code almost exclusively in Swift, the problem has largely
>> disappeared, because ‘“\(someValue)"'
> On 20 Feb 2016, at 13:02, Quincey Morris
> wrote:
>
> On Feb 19, 2016, at 21:30 , Gerriet M. Denkmann wrote:
>
> Now that I code almost exclusively in Swift, the problem has largely
> disappeared, because ‘“\(someValue)"' is a lot easier*** than ‘[NSString
> stringWithFormat: "%lu", (som
On Feb 19, 2016, at 21:30 , Gerriet M. Denkmann wrote:
>
> One can NOT force NSUInteger to be different sizes. It will always be 4 bytes
> on 32 bit systems, and 8 bytes on 64 bit ones.
>
> 32 bit without DNS_BUILD_32_LIKE_64
> NSUInteger = int;
> 32 bit with DNS_BUILD_32_LIKE_64
>
> On 20 Feb 2016, at 11:59, Quincey Morris
> wrote:
>
> On Feb 19, 2016, at 20:43 , Gerriet M. Denkmann wrote:
>>
>> This:
>> UIDevice *theDevice = [UIDevice currentDevice];
>> NSLog(@“%s NSUInteger %lu bytes on %@“,__FUNCTION__,
>> sizeof(NSUInteger), theDevice.localizedModel);
>
On Feb 19, 2016, at 20:43 , Gerriet M. Denkmann wrote:
>
> This:
> UIDevice *theDevice = [UIDevice currentDevice];
> NSLog(@“%s NSUInteger %lu bytes on %@“,__FUNCTION__,
> sizeof(NSUInteger), theDevice.localizedModel);
>
> prints:
> -[AppDelegate application:didFinishLaunchin
> On 20 Feb 2016, at 11:24, Quincey Morris
> wrote:
>
> On Feb 19, 2016, at 19:00 , Gerriet M. Denkmann wrote:
>>
>> I use Other C Flags: -DNS_BUILD_32_LIKE_64=1
>
> AFAIK this is a Mac-only thing. I don’t believe it works on a 32-bit iOS
> platform, in particular because I don’t believe th
On Feb 19, 2016, at 19:00 , Gerriet M. Denkmann wrote:
>
> I use Other C Flags: -DNS_BUILD_32_LIKE_64=1
AFAIK this is a Mac-only thing. I don’t believe it works on a 32-bit iOS
platform, in particular because I don’t believe there are any 64-bit system
frameworks on such a system. There’d be a
> On 20 Feb 2016, at 06:32,Charles Srstka wrote:
>
>
>
>> On Feb 19, 2016, at 4:29 PM, Jens Alfke wrote:
>>
>> NSInteger is a typedef of ‘long’ in 64-bit, and ‘int’ in 32-bit.
>> You’re correct that %d should be used for NSInteger in 32-bit.
>
> The recommended way to use an NSInteger, as p
>> On Feb 19, 2016, at 4:29 PM, Jens Alfke wrote:
>>
>> NSInteger is a typedef of ‘long’ in 64-bit, and ‘int’ in 32-bit.
>> You’re correct that %d should be used for NSInteger in 32-bit.
>
> The recommended way to use an NSInteger, as per Apple documentation, is to
> use %ld and explicitly cas
> On Feb 19, 2016, at 4:29 PM, Jens Alfke wrote:
>
> NSInteger is a typedef of ‘long’ in 64-bit, and ‘int’ in 32-bit.
> You’re correct that %d should be used for NSInteger in 32-bit.
The recommended way to use an NSInteger, as per Apple documentation, is to use
%ld and explicitly cast it to lon
On Fri, 19 Feb 2016 14:29:03 -0800, Jens Alfke said:
>(Here’s one reason NSInteger sucks: the difference in sizes doesn’t make
>sense for values that don’t refer to memory sizes. For example, is it OK
>use NSUInteger to store a file size? In a 64-bit process, sure! In a 32-
>bit one, you’ll be fin
> On Feb 19, 2016, at 1:44 PM, Jean-Daniel Dupas wrote:
>
> Not exactly. %d is for 32 bit signed integer,
Not exactly ;) %d is for “int”, whose size is unspecified. It does happen to be
32 bits on Apple platforms with current compilers. (I still remember the “fun”
period of the early ‘90s whe
It really was the wrong format specifier. Turns out the crash was on the next
line where I used %d and %@ together. The -1 was an indicator of the issue but
not the cause of my crash.
Thanks for the quick look. I will try that warning flag. I haven’t changed any
of those flags so it may very we
> Le 19 févr. 2016 à 22:29, Jens Alfke a écrit :
>
>
>> On Feb 19, 2016, at 1:17 PM, Jim Adams wrote:
>>
>> SLogInfo(@"Starting csi %ld count %d", csi, sortedEvents.count);
>>
>> In the console I see:
>> INFO: Starting csi -1 count -1
>> The very next line crashes when the sortedEv
Jim,
> On Feb 19, 2016, at 16:17, Jim Adams wrote:
>
> I have code that looks like the following:
>
> NSArray *sortedEvents = [events.eventSet sortedArrayUsingDescriptors:[NSArray
> arrayWithObject:[NSSortDescriptor sortDescriptorWithKey:@"date"
> ascending:Y
> On Feb 19, 2016, at 1:17 PM, Jim Adams wrote:
>
>SLogInfo(@"Starting csi %ld count %d", csi, sortedEvents.count);
>
> In the console I see:
> INFO: Starting csi -1 count -1
> The very next line crashes when the sortedEvents are accessed. What could
> cause the array to have a -1
I have code that looks like the following:
NSArray *sortedEvents = [events.eventSet sortedArrayUsingDescriptors:[NSArray
arrayWithObject:[NSSortDescriptor sortDescriptorWithKey:@"date"
ascending:YES]]];
int64_t csi = -1LL;
SLogInfo(@"Starting csi %ld
On Feb 15, 2016, at 09:44 , Quincey Morris
wrote:
>
>> [archiver encodeObject: model forKey: @"model"];
Oh, in the test project that I pasted this code from, I used “model” as my root
object key. In the real project, I’m using NSKeyedArchiveRootObjectKey, which
seems like a better choice
On Feb 15, 2016, at 03:43 , Dave wrote:
>
> Do you know if same thing applies to dictionaries as well as arrays?
In the project that got me started on this, I don’t yet have any dictionaries,
so I don’t know. But I would assume so.
On Feb 15, 2016, at 04:34 , Michael Starke
wrote:
>
> I am
Best
> Dave
>
>> On 14 Feb 2016, at 08:45, Quincey Morris
>> wrote:
>>
>> I might be late to this party, but since I just spent hours on it, I’ll
>> document this for anyone who hasn’t run into it yet.
>>
>> If you’re using NSSecureCoding, there
Feb 2016, at 08:45, Quincey Morris
> wrote:
>
> I might be late to this party, but since I just spent hours on it, I’ll
> document this for anyone who hasn’t run into it yet.
>
> If you’re using NSSecureCoding, there’s a problem decoding NSArray objects.
> You can’t use
I might be late to this party, but since I just spent hours on it, I’ll
document this for anyone who hasn’t run into it yet.
If you’re using NSSecureCoding, there’s a problem decoding NSArray objects. You
can’t use this:
myArray = [coder decodeObjectForKey: @“myArray”];
and you can’t
the top item on the stack
to see what is allowed.
NSArray (and other collections) use the second mechanism (not pushing on the
stack). This means that the set of allowed classes is whatever the decoder of
the NSArray instance set up when calling decodeObjectOfClasses:forKey:. This
usually means
threat is just crashing the app.
Cheers.
> Subject: Re: NSSecureCoding with containers (or, is NSArray lying?)
> From: graham@bigpond.com
> Date: Fri, 17 Jul 2015 09:52:33 +1000
> CC: r...@rols.org; cocoa-dev@lists.apple.com
> To: andre.frate...@hotmail.com
>
>
&g
> On 16 Jul 2015, at 12:17 pm, André Francisco
> wrote:
>
> This can easily crash an app if I get a type that I'm not expecting, even if
> it implements NSSecureCoding.
Actually, probably not. It will likely start throwing exceptions all over the
place, which *may* cause termination, but it
nice to know, though, as this could possibly
introduce security issues in an app.
Thanks a lot!
Subject: Re: NSSecureCoding with containers (or, is NSArray lying?)
From: r...@rols.org
Date: Thu, 16 Jul 2015 10:44:55 +0800
CC: cocoa-dev@lists.apple.com
To: andre.frate...@hotmail.com
The list of thing
The list of things which the collection classes decode automagically is pretty
small, limited I think to the primitives in XML/Binary document. But yes you
can craft a document with an NSArray in it and subtypes and that will be
decoded into strings and numbers. That means if you use NSArray
nyway, based on all my research, SO comments, and especially this
conversation, I have been becoming more and more convinced that there doesn't
exists a real solution. NSSecureCoding doesn't seem so secure anymore :\
> Subject: Re: NSSecureCoding with containers (or, is NSArray lying?)
that it will either.
> The problem is when implementing NSSecureCoding with a collection (or
> container) given that the type of contained objects is not known. I would
> assume that secure coding is not possible in this situation. However, classes
> such as NSArray do implement NSSecure
n (or
container) given that the type of contained objects is not known. I would
assume that secure coding is not possible in this situation. However, classes
such as NSArray do implement NSSecureCoding, so as I stated earlier, either
there's a work around or NSArray is lying.
I've been putt
(nonatomic,retain)NSArray*
pScriptBridgeGlobalWindowArray;
-(void) refreshGlobalWindowArray
{
NSArray*myGlobalWindowsArray;
CFArrayRef myGlobalWindowArrayRef;
myGlobalWindowArrayRef =
CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly
restricted list, I could do a file existence check for all entries in the
restricted set.
- I will be converting the NSSet to NSArray and save it in file. I read
the array as NSSet when the application starts.
Is there something else I am missing?
Regards,
Varun
On 16/04/2014 4:17 am, "Gary L.
On Apr 14, 2014, at 9:01 PM, Ken Thomases wrote:
> You should obtain the resource identifier object of each URL using
> -getResourceValue:forKey:error: with NSURLFileResourceIdentifierKey, then
> compare those two objects using -isEqual:.
One thing to watch out for, though: the object returned
Also, if your folder hierarchy, traversal code, and checks can deal well
with it, you¹ll get better performance by short-circuiting based on upper
directory checks.
For example, if you know you¹re in /Downloads, don¹t compare against
/Documents/AboutUs.pdf. Just use the /Documents set of file obje
On Apr 15, 2014, at 7:45 AM, Alex Zavatone wrote:
> A good approach here would be to make a test case for NSArray and NSSet, a
> known set of files and simply test now long each takes.
In general I agree that it’s a good idea to test before optimizing. It’s common
for people here to
Another wild thought, how about drop one layer lower to POSIX and use a little
bit of OpenCL? For every directory with content paths C[0..i] and the list of
restricted paths R[0..j] construct a matrix (using OpenCL) M[0..i, 0..j] where
M[i, j]=strcmp(C[i], R[j]) (strcmp() itself can be OpenCL co
ng this set to a file? I have used NSArray
> writeToFile before but I don¹t see that method for NSSet. Do I have to
> convert it to NSArray and store? Am I missing something?
>
> I figured if I put resource identifier object into the NSMutableSet then
> will I be able to write this
A good approach here would be to make a test case for NSArray and NSSet, a
known set of files and simply test now long each takes.
On Apr 14, 2014, at 8:59 PM, Graham Cox wrote:
>
> On 15 Apr 2014, at 10:02 am, Varun Chandramohan
> wrote:
>
>> Lets say I walkthrough 1000
On Tue Apr 15 2014 12:41:50 GMT+1000 (PGT) Graham Cox wrote:
On 15 Apr 2014, at 12:03 pm, John Brownie wrote:
think you're an order of magnitude out. Searching an array is linear with the
length of the array, O(n), whereas a set or hash should be close to constant,
O(1), if there's not a b
On Apr 14, 2014, at 21:10 , Varun Chandramohan
wrote:
> I was thinking what if I want to keep this persistent?
This doesn’t sound like such a good idea. There’s nothing to guarantee that
your saved data will actually match the state of the file system the next time
you read it back. In partic
Thanks Guys,
Yes I was not planning to use -[NSURL isEqual:]. Interestingly, Graham¹s
suggestion was to use NSSet, I was thinking what if I want to keep this
persistent? I would be writing this set to a file? I have used NSArray
writeToFile before but I don¹t see that method for NSSet. Do I have
On 15 Apr 2014, at 12:03 pm, John Brownie wrote:
> think you're an order of magnitude out. Searching an array is linear with
> the length of the array, O(n), whereas a set or hash should be close to
> constant, O(1), if there's not a big collision in the hashes. But the
> principle is correc
Graham Cox wrote:
As a general principle, if you have to check whether one of a list of things is
part of another list of things, an array is the wrong container for the job,
because it amounts to a worst-case O(n^2) search. Instead, use a set or hash
table for the set of things that must be d
On Apr 14, 2014, at 7:02 PM, Varun Chandramohan wrote:
> I have a question about efficiency when trying to compare NSURL. The
> requirement is quite simple. I try and iterate through a directory to all
> subdirectories and files. While doing this walk-through, I need to check
> against an array
On 15 Apr 2014, at 10:02 am, Varun Chandramohan
wrote:
> Lets say I walkthrough 1000 files and folders, for each file/folder I need to
> compare against this array list. This might be slow or inefficient. Is there
> a faster way to do something like this?
As a general principle, if you have
Hi All,
I have a question about efficiency when trying to compare NSURL. The
requirement is quite simple. I try and iterate through a directory to all
subdirectories and files. While doing this walk-through, I need to check
against an array of NSURLs which are restricted files and folders.
This
Say I have an array of Person object with a name property. Is there a
difference between :
namesArray = [personsArray valueForKeyPath:@"@unionOfObjects.name"];
and
namesArray = [personsArray valueForKeyPath:@"name"];
On a small test I can just see that the concrete NSArra
On Dec 23, 2013, at 7:02 AM, Gordon Apple wrote:
> FirstObject is a better choice and avoids having to pre-check for count != 0.
Yes, that’s exactly its purpose. It’s the counterpart of lastObject.
—Jens
___
Cocoa-dev mailing list (Cocoa-dev@lists.a
That¹s also a problem with re-declared methods not labeled as IBAction, such
as a few contained in NSTextView. (e.g., superscript, subscript.)
Another point with firstObject. I assumed this was the same as array[0] or
objectAtIndex:0, but apparently not so. If I remember correctly, these
result
@implementation NSArray
(YourCategoryName) … @end). It's perfectly legal to have interface-only
categories that merely declare methods.
Regards,
Ken
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moder
> Yes. This method is there since 10.6 so you can safely call it. using latest
> header or category on it.
On Dec 23, 2013, at 1:49, Seth Willits
> wrote:
> On Dec 22, 2013, at 9:31 AM, Trygve Inda
> wrote:
>
>> Available in OS X v10.6 and later.
>>
>
>> This seems to be an error in the docs
On 22 Dec 2013, at 19:01, Fritz Anderson wrote:
>
> On Dec 22, 2013, at 11:46 AM, Michael Starke
> wrote:
>
>> It's been a private API until 10.9 and iOS 7. Clearly a documentation error.
>
> That's not what NSArray.h says…
>
> - (id)firstObject NS_AVAILABLE(10_6, 4_0);
>
> … and that's clo
On Dec 22, 2013, at 11:31 AM, Trygve Inda wrote:
[Quotes the documentation that says -[NSArray firstObject] is available since
Mac OS 10.6.]
> This seems to be an error in the docs as the method does not seem to exist
> for me.
I didn't see the method at all in the docs until I
Yes. This method is there since 10.6 so you can safely call it. using latest
header or category on it.
On Dec 23, 2013, at 1:49, Seth Willits wrote:
> On Dec 22, 2013, at 9:31 AM, Trygve Inda wrote:
>
>> Available in OS X v10.6 and later.
>>
>> This seems to be an error in the docs as the me
On Dec 22, 2013, at 9:31 AM, Trygve Inda wrote:
> Available in OS X v10.6 and later.
>
> This seems to be an error in the docs as the method does not seem to exist
> for me.
What do you mean?
As I recall, when it was announced at WWDC the method become public only
recently, but they explicitl
It's been a private API until 10.9 and iOS 7. Clearly a documentation error.
On 22 Dec 2013, at 18:31, Trygve Inda wrote:
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Founda
> tion/Classes/NSArray_Class/NSArray.html#//apple_ref/doc/uid/2137-SW40
>
> firstObject
>
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Founda
tion/Classes/NSArray_Class/NSArray.html#//apple_ref/doc/uid/2137-SW40
firstObject
Returns the first object in the array.
- (id)firstObject
Return Value
The first object in the array. If the array is empty, returns ni
On 2013 Oct 24, at 09:18, Andy Lee wrote:
> Might be worth filing a Radar requesting that method be made official
> published API like it is for the other collection classes…
Well, I did a document feedback, but not on NSArray. Instead I suggested
adding text like the following
On Oct 24, 2013, at 9:19 AM, Jerry Krinock wrote:
> Starting somewhere after OS X 10.6, NSArray instances respond to the NSSet
> method -allObjects. I can’t find any documentation of this. Also, it is not
> declared in the header NSArray.h
>
> Although it does what you’d expe
On Oct 24, 2013, at 10:35 AM, Sean McBride wrote:
> You could also set OBJC_PRINT_REPLACED_METHODS=YES in the environment.
> That's how I originally discovered my firstObject NSArray category method was
> in conflict.
This is why I always put a namespace prefix on any cate
vironment. That's
how I originally discovered my firstObject NSArray category method was in
conflict.
Cheers,
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
On Oct 24, 2013, at 10:19 AM, Jerry Krinock wrote:
> Starting somewhere after OS X 10.6, NSArray instances respond to the NSSet
> method -allObjects. I can’t find any documentation of this. Also, it is not
> declared in the header NSArray.h
I see it's also documented fo
I agree, that method exists, not quite sure what your question is though.
Depends what you want to do with introspection. If you want to ensure a class
responds to allObjects and you expect if it does it returns an NSArray, that
still works in this case, if you are trying to work out what an
Starting somewhere after OS X 10.6, NSArray instances respond to the NSSet
method -allObjects. I can’t find any documentation of this. Also, it is not
declared in the header NSArray.h
Although it does what you’d expect, returning a copy of self, this can lead to
some interesting bugs
On Apr 16, 2013, at 11:41 , Quincey Morris
wrote:
> for every cell-based table view I've created
"every *view*-based table view", I meant.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comment
On Apr 16, 2013, at 10:26 , Chris Paveglio wrote:
> I've added an NSArrayController to the xib. Set it's contentArray binding to
> my array. Then I selected a text box in my table cell where one of the
> dictionary values would go. I set it's binding to BindTo:arrayController;
> controllerKey:
I'm having trouble with bindings. I have an mutable array which contains 2 or
more mutable dictionaries. I want to display the dictionary items in an
NSTableView using NSTableCellView (the one where I can do custom layout in the
cell with multiple text boxes/image boxes etc). And the dictionary
When making a copy of a Foundation object that was originally created from a
Core Foundation object (say CFArrayRef or CFDictionaryRef) which used a custom
allocator, which allocator is the Foundation object using afterward?
Thanks for insights!
Andreas
__
On Mar 26, 2013, at 1:12 AM, Diederik Meijer | Ten Horses wrote:
> But I'd like to know if there is a quicker or more efficient way to do this,
> with less code. If so, please let me know.
More efficient, yes. Better? Different way to look at it at least:
NSArray * orderedHits
know.
NSArray *resultArray = [[result objectForKey:@"hits"] objectForKey:@"hits"];
//1
NSMutableSet *dates = [[NSMutableSet alloc] init]; //2
for (NSDictionary *dict in resultArray) {
[dates addObject:[[dict objectForKey:@"_source"]
objectForK
On Feb 4, 2013, at 11:15 AM, Geoffrey Holden wrote:
> In the same way that it is possible to bind NSTableView to an NSDictionary,
> is it possible to bind NSMenu to an NSArray? I have an array of
> dictionaries. The dictionaries contain the menu name, and may contain a
> furt
In the same way that it is possible to bind NSTableView to an NSDictionary,
is it possible to bind NSMenu to an NSArray? I have an array of
dictionaries. The dictionaries contain the menu name, and may contain a
further array of dictionaries, to a potential level of eight deep.
I'd like
MIkkel,
I'm sorry, I didn't see your answer yet when I sent my previous message.
Willeke
___
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-ad
If "Auto Rearrange Content" is switched on, the array controller is observing
the objects in its content for the keypaths of the filterpredicate and
sortdescriptors. The value of key "personalNames" of keypath
"personalNames.value.gedcomString" is an array and can't be observed for key
"value".
1 - 100 of 453 matches
Mail list logo
