Re: NSData from dispatch_data_t?
> On Oct 30, 2018, at 7:48 PM, Carl Hoefs > wrote: > > It's ugly, but it compiles: > >[NSData dataWithBytes:(__bridge const void * _Nullable)(data_t) > length:dispatch_data_get_size(data_t)]; This is incorrect: it creates an NSData object whose contents are the dispatch_data_t object header. That is not going to match the dispatch_data_t's actual contents. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: NSData from dispatch_data_t?
> On Tue, Oct 30, 2018 at 7:26 PM Carl Hoefs > wrote: > > Is it possible to create an NSData object from a dispatch_data_t? > > I'm interfacing to a 3rd party library that returns only a dispatch_data_t > object. Once upon a time you could simply cast that to (NSData *) and work > with it that way, but Xcode now flags it as an error: > >dispatch_data_t data_t = BGRequestSidebandDL(channel); >NSData *nsdata = data_t; // Incompatible pointer types initializing > 'NSData *' with an > expression >of type 'dispatch_data_t' (aka 'NSObject *') You may use a dispatch_data_t as if it were an NSData (assuming you're on iOS 7 or macOS 10.9 or later). But you do need to cast it explicitly: NSData *nsdata = (NSData *)data_t; > On Oct 30, 2018, at 7:37 PM, Ryan Dignard > wrote: > > To get the size of the dispatch data you can call > dispatch_data_get_size(dispatch_data_t) on it which would let you create an > NSData object. This may be inefficient. dispatch_data_t often uses a discontiguous representation. Allocating an NSData this way is would need to copy the data. (Of course, if the code using it as an NSData goes on to call -bytes instead of -enumerateByteRangesUsingBlock: then it would be forced to copy into a contiguous representation anyway.) -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Dealing with an @available warning
> On Oct 23, 2018, at 3:01 PM, James Walker wrote:
>
> I had some code like this
>
> pInfo.orientation = NSPaperOrientationPortrait;
>
> where pInfo is of type NSPrintInfo*. When compiling with
> -Wunguarded-availability, I got a warning saying that
> NSPaperOrientationPortrait is only available on macOS 10.9 and later. So I
> wanted to change it to:
>
> if (@available( macOS 10.9, * ))
> {
> pInfo.orientation = NSPaperOrientationPortrait;
> }
> else
> {
> pInfo.orientation = NSPortraitOrientation
> }
>
> But then I get an error, "assigning to NSPaperOrientation from incompatible
> type NSPrintingOrientation". If I fix the error by adding a typecast to
> NSPaperOrientation, then I get a warning that NSPaperOrientation is only
> available on 10.9 and later. Is there any way out of this roundabout, other
> than using a later deployment target?
Dumb answer: use #pragma clang diagnostic to disable the guarded availability
check on that line. Something like this:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunguarded-availability"
pInfo.orientation = (NSPaperOrientation)NSPortraitOrientation;
#pragma clang diagnostic pop
You should file a bug report against AppKit. I'm not sure there is any benefit
to marking a plain C enum as unavailable. Use of a new enum would work fine
when running on an old OS version.
--
Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime
Wrangler
___
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: C++ pointer to Cocoa object
> On Sep 7, 2018, at 3:48 PM, Jens Alfke wrote: > >> On Sep 7, 2018, at 10:46 AM, Casey McDermott wrote: >> >> Problem is, with ARC turned on, the pointer is never nil, so it crashes. >> The void pointer somehow becomes an NSAtom instead of 0. > > Something wrote to that pointer, then. If you initialize it to nullptr, it > will stay that way. NSAtom is a red herring — probably the mCocoaPopupPtr was > pointing to a valid object, but it got freed, and there is now (by chance) an > NSAtom instance residing at that address. NSAtom is one of the tagged pointer object classes. On 64-bit macOS, if you have an address whose lowest four bits are 0x…1, and you use it as if it were an Objective-C object, then it will be an NSAtom. (Same for 64-bit iOS, except with an address that starts with 0x8….) Nothing in the OS actually uses class NSAtom. (We're trying to get rid of it but there are some binary compatibility problems.) Instead of "pointer variable somehow becomes an NSAtom" you should be looking for "pointer variable somehow has a random or uninitialized value". For example, if the object that contains this mCocoaPopupPtr field were itself deallocated then a use-after-free could cause this symptom. >> Is there some other way to test for an invalid void pointer? There is no way to programmatically distinguish all valid Objective-C object pointers from all invalid ones. It's just like C and C++ in that respect. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: NSString equivalent of CFSTR macro?
> On Dec 4, 2017, at 3:22 PM, Rick Mann wrote: > > Ugh...been doing too much Swift (j/k). The right answer to this question is: > > @(kSomeCStringConstant) > > This works whether it's a #define or a static const char* const. The downsides are: 1. If the library requires that you use the actual address stored in string variable kSomeCStringConstant then it may fail because @(kSomeCStringConstant) may create a second object at a different address. 2. The compiler is not currently smart enough to optimize @(kSomeCStringConstant) into a constant string object, so it may allocate a new autoreleased string object every time it runs that line. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: NSString equivalent of CFSTR macro?
> On Dec 4, 2017, at 2:56 PM, Rick Mann wrote: > >> On Dec 4, 2017, at 14:55 , Greg Parker wrote: >> >>> On Dec 4, 2017, at 2:51 PM, Ben Kennedy wrote: >>> >>>> On Dec 4, 2017, at 2:47 PM, Rick Mann wrote: >>>> >>>> #define NSSTR(s) (@ ## s) <-- magic; this >>>> doesn't work >>>> #define kSomeCStringConstant "foo" >>>> ... >>>> NSSTR(kSomeCStringConstant) >>> >>> You're close. The preprocessor is removing the quotation marks, breaking >>> the syntax. You don't need to token paste; simply remove the '##' from the >>> NSSTR() def. >>> >>> #define NSSTR(s) (@ s) >> >> You can also skip the middleman and use `@kSomeCStringConstant`. After the >> preprocessor runs it will be `@"foo"` which the ObjC compiler is perfectly >> happy with. > > Tried that, too. Same error: > > MCP.m:262:54: Unexpected '@' in program What compiler version are you using? Is this file compiled as Objective-C? Is the #define spelled differently than you wrote? Does anything look wrong with that line in the output of Product > Perform Action > Preprocess ? -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: NSString equivalent of CFSTR macro?
> On Dec 4, 2017, at 2:51 PM, Ben Kennedy wrote: > >> On Dec 4, 2017, at 2:47 PM, Rick Mann wrote: >> >> #define NSSTR(s) (@ ## s) <-- magic; this >> doesn't work >> #define kSomeCStringConstant "foo" >> ... >> NSSTR(kSomeCStringConstant) > > You're close. The preprocessor is removing the quotation marks, breaking the > syntax. You don't need to token paste; simply remove the '##' from the > NSSTR() def. > > #define NSSTR(s) (@ s) You can also skip the middleman and use `@kSomeCStringConstant`. After the preprocessor runs it will be `@"foo"` which the ObjC compiler is perfectly happy with. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Is "-init" really needed?
> On Aug 7, 2017, at 5:02 PM, David Hoerl wrote: > > I recently saw some code where an object was alloced but there was no init: > > Foo *foo = [Foo alloc]; > foo.bar = ... > > My blood pressure soared! My pulse quickened! I started breathing rapidly! > > But then I though - heck, if Foo has NSObject as its super class, gee, maybe > -init isn't really need. I mean, if all of Foo's ivars and properties are > initialized, its a shortcut, right. Pro: * -[NSObject init] is in fact guaranteed to do nothing. Con: * As you noticed, independent of its correctness, the code above *looks* wrong. That alone is bad. It ought either to call -init or to have a big scary comment describing why it is safe not to. * If Foo is ever changed to have a superclass other than NSObject, the code above is likely to be wrong. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Who owns a child view controller?
> On Jul 14, 2017, at 10:59 AM, Quincey Morris > wrote: > >> On Jul 14, 2017, at 03:50 , Jeremy Hughes >> wrote: >> >> I’m still not entirely clear on when autorelease pools are used in Swift. > > I think about it this way: > > Autorelease is the run-time feature that provides an atomic return. > > There is no such thing as an “atomic” return naturally built into in any of > the run-time environments using ARC (or MRC). That is, if a function result > is a reference-counted object, there is nothing that naturally prevents the > reference count from changing during the short window of mis-opportunity from > when a release occurs just before a callee returns, and the caller gets an > opportunity to retain the reference. That’s the price of multi-threading. This description applies even in the absence of threads. There is always a "window of mis-opportunity" between the callee's last release and the caller's first retain. If this is the only reference to the object then it would be deallocated after the callee relinquishes ownership and before the caller can retake ownership. Some convention is necessary to keep the object alive across the return, whether or not there is a threat of thread interference. > Therefore there are two practical solutions: > > 1. Retain the object over the window of mis-opportunity. This works fine if > the calling site is aware that the callee did it, and this is what happens > when both the caller and callee are using ARC conventions. In fact, with ARC, > the object is *already* retained in the callee, so this scenario doesn’t > *add* a retain, it *removes* a release (that would normally occur at the end > of the callee’s scope). And the caller doesn’t have to retain the result, > just keep the the release at the end of *its* scope. Win-win-win. Otherwise… > > 2. Retain and autorelease the object prior to returning. This works fine > always, because autorelease pools are per-thread, so there’s no change of it > being drained during the return process. But it typically adds a net return > and release. > > Choosing a strategy is up to the callee, and is based on information about > the caller at run-time, not compile or link time. That means it’s not > source-language-specific. (The only exception would be if the Swift compiler > knew that a function was private and final, so it controlled both ends of the > call.) The Swift compiler can avoid autorelease more often than that. Swift can use a simple callee-retain caller-release convention any time it knows that the function is not visible to Objective-C. That happens often. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Who owns a child view controller?
> On Jul 14, 2017, at 6:51 AM, Alex Zavatone wrote: > >> On Jul 14, 2017, at 5:50 AM, Jeremy Hughes >> wrote: >> >>> On 12 Jul 2017, at 17:41, Jens Alfke wrote: >>> >>>> On Jul 12, 2017, at 9:34 AM, Jeremy Hughes >>>> wrote: >>>> >>>> // Prints "Why is childReference not nil?” >>> >>> There may still be a reference in the autorelease pool. Check >>> childReference again ‘later’, i.e. on the next user event or after a >>> timer/delayed-perform. >> >> Jens is correct. Here’s a modified version of the playground code that adds >> an autorelease pool: > > In the interest of getting more of a clue in regards to these items, is it > possible to examine the autorelease pools? Xcode's memory graph tool can tell you if an object is pointed to by some autorelease pool. You can call _objc_autoreleasePoolPrint() in the debugger to dump the contents of the current thread's autorelease pool stack. You can set environment variable OBJC_PRINT_POOL_HIGHWATER=YES to record stack traces when a large autorelease pool is drained. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Who owns a child view controller?
> On Jul 12, 2017, at 4:15 PM, Quincey Morris > wrote: > >> On Jul 12, 2017, at 14:57 , Jeremy Hughes >> wrote: >> >> I’m trying to understand memory management so I can avoid retain cycles and >> other issues. > > There’s nothing wrong with trying to understand. The bet you will (almost > always) lose is one involving reasoning about *when* retain counts reach > particular values (such as 1 or 0). > > I may be overlooking something important, but I see basically three tasks you > need to handle to avoid memory management bugs: > > 1. Strong references. > > In terms of object lifetimes, these are the easiest, because an object A that > depends on an object B’s existence and keeps a strong reference to B is doing > the right thing. There’s nothing here to worry about, assuming the reference > to B is released normally (and *automatically* usually) when A deallocates. > What you do have to worry about are reference cycles. You must either use > something like Instruments to find any, and either avoid creating them, or > ensure that you break them manually at a suitable time. > > 2. Weak references. > > This means zeroing weak references. (All weak references are zeroing since, > IIRC, macOS 10.6.8.) Again, there’s nothing to do here, except to ensure that > nothing crashes because a reference suddenly changes to nil. > > 3. Unowned/unsafe references. > > These are the killers. Typically, these are delegate references, but it’s > hard to keep track of all the possibilities. For example, NSWindow’s > “delegate” is still AFAIK unsafe. It’s usually set to the window controller, > but I’m not aware of any typical bugs arising from this reference becoming > invalid. The most common problem I know of is from table and outline view > delegate and data source references. In many cases, it’s wise to nil these > out manually when (say) your window closes. We prefer to use "unretained" or "unsafe unretained" to describe this kind of reference. "Unowned" means something else in Swift. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Who owns a child view controller?
> On Jul 12, 2017, at 11:24 AM, Jens Alfke wrote: > >> On Jul 12, 2017, at 10:38 AM, Charles Srstka >> wrote: >> >> While that’s true, the main reason, as I understand it, that ARC doesn’t >> know enough about the object’s lifetime is that non-ARC code may be calling >> the method. In an all-ARC world, a method could always just return objects >> with a +1 retain count, and the consumer could just assume that and always >> balance the retain. > > It could, but that results in _enormous_ numbers of retain/release calls. (I > speak from some experience, having once worked on performance optimization of > a project that did ref-counting this way.) > > It’s generally cheaper overall to use autorelease, and that was one of the > reasons NeXT invented it* (besides the obvious benefit of simplifying MRR > code.) Autoreleasing return values by itself has no net effect on the number of retain/release operations compared to a scheme where return values are returned retained. In both cases there is a retain/release pair bracketing the return. In both cases an optimized function that is merely passing a returned value along can do so with no additional cost. The benefit of the autoreleasing convention comes when you can return an unretained value without a retain/autorelease pair, because you "know" that the object will live long enough for the callee to use it. This does in fact avoid lots of retain/release pairs in carefully written code. One cost of the autoreleasing convention is the autorelease pools themselves. Sometimes large numbers of otherwise-dead objects are kept alive by an autorelease pool. Another cost of the autoreleasing convention is the bugs introduced when you "know" that an object can be safely returned unretained but you are wrong. The traditional example is -[NSMutableArray objectAtIndex:]. It returns the array value unretained with no retain/autorelease. This is fine while the array continues to hold the value, but can fail if the array is destroyed or the object is removed from the array. ARC always retains and autoreleases when returning, for compatibility with non-ARC code. For safety reasons ARC never returns a bare unretained value and it always retains values that are returned to it. ARC does add an optimization where a cooperating caller and callee can safely avoid the retain/release pair around the return operation, effectively transforming that call into the return-retained convention. > * I’m not actually sure they did; there’s an earlier technique called > “deferred reference counting” that might be equivalent. Deferred reference counting is not much like autorelease. The goal of deferred RC is to accumulate many retain and release operations from a single thread and apply them all at once, in the hopes of reducing the cost of repeated refcount operations on a single object. It can be used with any parameter passing convention. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Context leak detected, msgtracer returned -1 ?
> On May 22, 2017, at 8:52 AM, Jonathan Mitchell wrote: > > Hi > > On occasion I see the following in the Xcode console when running my Obj-C > app: > > Context leak detected, msgtracer returned -1 > > I have tried setting symbolic breakpoints on NSLog etc but to no avail. > > Is the context in question a CGContext? The context is an IOAccelContext, which itself is deep in the graphics machinery. The log complains once for every 512 objects allocated. Try setting a breakpoint on IOAccelLogContextLeak or fprintf. You should also file a bug report that this log is too vague. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Binary floating point format
> On Mar 30, 2017, at 9:03 PM, Carl Hoefs > wrote: > >> On Mar 30, 2017, at 8:10 PM, Greg Parker > <mailto:gpar...@apple.com>> wrote: >> >>> On Mar 30, 2017, at 7:09 PM, Carl Hoefs >> <mailto:newsli...@autonomy.caltech.edu>> wrote: >>> >>> 26 C3 E9 E2 6C 6A 38 0C 46 C3 E9 E2 6C 6A 40 0B 46 C3 E9 E2 83 6A DC 0A 66 >>> C3 E9 E2 83 6A 0E 0B >>> A5 C3 EF E2 AF 6A 40 0B A5 C3 EF E2 C6 6A 40 0B C5 C3 F5 E2 C6 6A 16 0A C5 >>> C3 F5 E2 DC 6A 0E 0B >>> 26 C3 3C E3 9E 62 B2 09 26 C3 3C E3 9E 62 B2 09 26 C3 36 E3 B4 62 BA 08 06 >>> C3 36 E3 CB 62 C2 07 >>> 45 C4 76 E3 44 6C 38 0C 25 C4 76 E3 5A 6C 06 0C 25 C4 76 E3 5A 6C DC 0A 05 >>> C4 7D E3 70 6C DC 0A >> >> >> Byte-swapped VAX type D might be right, but it's so easy to be off by a >> factor of 2 here that it's hard to trust any guess. >> >> Using CFSwapInt64() from CoreFoundation/CFByteOrder.h and from_vax_d8() from >> https://pubs.usgs.gov/of/2005/1424/ <https://pubs.usgs.gov/of/2005/1424/>, >> your bytes above are: >> -41.7215935353 >> -49.7215935353 >> -49.7215935353 >> -49.7215935366 >> -49.7215935366 >> -57.7215935366 >> -57.7215935366 >> -82.9432328547 >> -82.9432328547 >> -82.9432328574 >> -82.9432328574 >> -98.9432786338 >> -98.9432786338 >> -98.9432786363 >> -98.9432786363 >> -41.7219100388 >> > > Enticing results! When I use CFSwapInt64(), it does this to the bytes: > > - raw bytes: 69BF5DE3 9F530306 > - swp bytes: 0603539F E35DBF69 > * [04] time_base: > 2400969845129752384725738662412037010364031309686872696685853017835577483033453697155629104443247189829603912142488904070729903714756009814926441089319983058422454699494905107871645497808138444180815872.00 > > > The 'time_base' value is what I get when I printf the swapped-bytes value > with a %f formatter. > Not sure why you're getting good results... CFSwapInt64() is not sufficient. I used CFSwapInt64() followed by from_vax_d8() from the USGS URL above. The latter is what performs the real floating-point format transformation from VAX to IEEE. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Binary floating point format
> On Mar 30, 2017, at 7:09 PM, Carl Hoefs > wrote: > > >> On Mar 30, 2017, at 6:40 PM, Steve Bird wrote: >> >> >>> On Mar 30, 2017, at 8:25 PM, Carl Hoefs >>> wrote: >>> >>> I have megabytes of raw legacy science datasets that I'm trying to read >>> into my app and ingest into an array of doubles. The data is supposed to be >>> organized as a stream of 8-byte doubles. I do not know how these datasets >>> were generated, so I don't know what format (big/little endian, byte >>> swapped, etc) they are in. >>> Here is a hex dump of 4 binary doubles: >>> >>> 49BF7DE372533C05 A8C02FE3135B4F09 86C22FE37E630B05 27C2C4E3E258BA08 >> >> A few minutes of LabVIEW work shows some semi-reasonable values if you swap >> bytes: >> BF49E37D5372053C = -0.000790058 >> C0A8E32F5B13094F = -3185.59 >> >> Do you know that those values are wrong? > > Hmm, the -3185.59 doesn't look right. The data is _supposed_ to be: > > 1st double: Time value, monotonically increasing, usually starting near > 0.0 > 2nd double: Sensor value, oscillating waveform, centered about some arbitrary > value > > So I'm expecting data like: > > 0.011 0.57525634765625 > 0.012 0.45166015625000 > 0.013 0.29907226562500 > 0.014 0.13275146484375 > 0.015 -0.03173828125000 > 0.016 -0.18218994140625 > 0.017 -0.29602050781250 > 0.018 -0.38055419921875 > ...etc. > > or even: > > 0.0182089.66467285156250 > 0.0202087.57525634765625 > 0.0222085.45166015625000 > 0.0242083.29907226562500 > 0.0262082.13275146484375 > 0.0282081.03173828125000 > 0.0302080.18218994140625 > 0.0322080.29602050781250 > 0.0342079.38055419921875 > 0.0362079.43060302734375 > 0.0382078.44738769531250 > 0.0402076.43640136718750 > ...etc > > When I manually swap the bytes in my program, I still end up with invalid > values. > -Carl > > 26 C3 E9 E2 6C 6A 38 0C 46 C3 E9 E2 6C 6A 40 0B 46 C3 E9 E2 83 6A DC 0A 66 C3 > E9 E2 83 6A 0E 0B > A5 C3 EF E2 AF 6A 40 0B A5 C3 EF E2 C6 6A 40 0B C5 C3 F5 E2 C6 6A 16 0A C5 C3 > F5 E2 DC 6A 0E 0B > 26 C3 3C E3 9E 62 B2 09 26 C3 3C E3 9E 62 B2 09 26 C3 36 E3 B4 62 BA 08 06 C3 > 36 E3 CB 62 C2 07 > 45 C4 76 E3 44 6C 38 0C 25 C4 76 E3 5A 6C 06 0C 25 C4 76 E3 5A 6C DC 0A 05 C4 > 7D E3 70 6C DC 0A Byte-swapped VAX type D might be right, but it's so easy to be off by a factor of 2 here that it's hard to trust any guess. Using CFSwapInt64() from CoreFoundation/CFByteOrder.h and from_vax_d8() from https://pubs.usgs.gov/of/2005/1424/ <https://pubs.usgs.gov/of/2005/1424/>, your bytes above are: -41.7215935353 -49.7215935353 -49.7215935353 -49.7215935366 -49.7215935366 -57.7215935366 -57.7215935366 -82.9432328547 -82.9432328547 -82.9432328574 -82.9432328574 -98.9432786338 -98.9432786338 -98.9432786363 -98.9432786363 -41.7219100388 -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Binary floating point format
> On Mar 30, 2017, at 6:40 PM, Steve Bird wrote: > >> On Mar 30, 2017, at 8:25 PM, Carl Hoefs >> wrote: >> >> I have megabytes of raw legacy science datasets that I'm trying to read into >> my app and ingest into an array of doubles. The data is supposed to be >> organized as a stream of 8-byte doubles. I do not know how these datasets >> were generated, so I don't know what format (big/little endian, byte >> swapped, etc) they are in. >> Here is a hex dump of 4 binary doubles: >> >> 49BF7DE372533C05 A8C02FE3135B4F09 86C22FE37E630B05 27C2C4E3E258BA08 > > A few minutes of LabVIEW work shows some semi-reasonable values if you swap > bytes: > BF49E37D5372053C = -0.000790058 > C0A8E32F5B13094F = -3185.59 > > Do you know that those values are wrong? Alternating byte-swapping is a good hint that you're looking at a PDP-11 / VAX format. There are two different 64-bit VAX formats, though, and neither is identical to IEEE even after correcting for the byte order. Simply shuffling VAX bytes and interpreting as an IEEE double would be misleadingly close but still wrong. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Binary floating point format
> On Mar 30, 2017, at 5:25 PM, Carl Hoefs > wrote: > > I have megabytes of raw legacy science datasets that I'm trying to read into > my app and ingest into an array of doubles. The data is supposed to be > organized as a stream of 8-byte doubles. I do not know how these datasets > were generated, so I don't know what format (big/little endian, byte swapped, > etc) they are in. > > If I read the data directly into double variables, they evaluate as very > small (E-92, etc). > > I've tried all of these functions: > > NSSwapDouble() > NSSwapBigDoubleToHost() > NSSwapLittleDoubleToHost() > NSConvertSwappedDoubleToHost() > CFConvertDoubleSwappedToHost() > > The above functions generally return invalidly large values (E+87, etc). > > Here is a hex dump of 4 binary doubles: > > 49BF7DE372533C05 A8C02FE3135B4F09 86C22FE37E630B05 27C2C4E3E258BA08 > > It seems there's some structure to them, as the last byte is always in the > range of 03 to A0, so maybe they somehow correspond to IEEE 754 > double-precision binary floating point format? > > Is there yet another function I could use to parse this binary data? There are lots of pre-IEEE floating-point formats. Here is a list of a few dozen of them: Floating-Point Formats http://www.quadibloc.com/comp/cp0201.htm <http://www.quadibloc.com/comp/cp0201.htm> I doubt you will be able to guess your floating-point format unless you have a collection of known values in both IEEE format and your format. Many of the historical formats are similar enough that misinterpretation could give incorrect values that look reasonable by eye. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Can't use +initialize, now what?
> On Mar 29, 2017, at 10:52 AM, Quincey Morris > wrote: > > Incidentally, there have always been other problems with using +initialize. > You don’t know how many times it will be called, since it’s called once for > each class, and it may be inherited from class to subclass. You have to code > defensively against multiple initializations. Also, I don’t think there are > any thread safety guarantees, so that’s more defensive coding. Swift’s lazy > static initializations are guaranteed to happen once, and to be thread-safe. +initialize has strong thread-safety guarantees. All superclass +initialize are guaranteed to complete before any subclass +initialize begins. While one thread is running some class's +initialize, all other threads that attempt to send a message to that class will block until +initialize completes. These guarantees can lead to deadlocks. For example, if two classes each have a +initialize method that tries to use the other class then you might get stuck with each one waiting for the other to complete. Beware of +initialize methods that do too much work. In recent OS versions the runtime puts specially-named stack frames into your backtrace which can help identify when +initialize deadlock occurs: `_WAITING_FOR_ANOTHER_THREAD_TO_FINISH_CALLING_+initialize` and `_CALLING_SOME_+initialize_METHOD`. Environment variable OBJC_PRINT_INITIALIZE_METHODS=YES logs some details of +initialize processing that can also help. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Can't use +initialize, now what?
> On Mar 29, 2017, at 9:02 AM, Charles Srstka wrote: > >> On Mar 29, 2017, at 10:51 AM, Jens Alfke wrote: >> >>> On Mar 29, 2017, at 6:57 AM, Daryle Walker >> <mailto:dary...@mac.com>> wrote: >>> >>> Now the new Xcode release notes say that “• Swift now warns when an >>> NSObject subclass attempts to override the initialize class method, because >>> Swift can't guarantee that the Objective-C method will be called. >>> (28954946)” >> >> Huh, I haven’t heard of that. And I’m confused by “the Objective-C method” — >> what’s that? Not the +initialize method being compiled, because that’s in >> Swift. The superclass method? >> >> Guess I’ll follow that Radar link and read the bug report myself. Oh, wait. >> :( > > You actually can this time, since Swift’s bug reporter is actually open to > the public. https://bugs.swift.org/browse/SR-3114 > <https://bugs.swift.org/browse/SR-3114> > > Basically, with Whole Module Optimization turned on, +initialize wasn’t > getting called. Their solution was to just get rid of +initialize. You don't even need WMO. Many arrangements of Swift code can bypass ObjC +initialize. Invocation of +initialize is a feature of objc_msgSend(). Swift code does not always use objc_msgSend() when calling methods: some methods are inlined, some are called via virtual table, some are called directly. None of these paths will provoke +initialize. Changing Swift's generated code to guarantee +initialize would be prohibitively expensive. Imagine an is-initialized check in front of every inlined call. It would be more expensive than +initialize in ObjC because +initialize checking is free once you pay the cost of objc_msgSend(). (The ObjC runtime checks +initialize on uncached dispatch, and never caches anything until +initialize completes. Most dispatches are cached so they pay nothing for +initialize support.) +initialize in Swift isn't safe and is too expensive to make safe, so we're taking it away instead. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: NSMutableData +dataWithLength: sets errno?
> On Mar 14, 2017, at 4:08 PM, John McCall wrote: > >> On Mar 14, 2017, at 7:00 PM, Carl Hoefs >> wrote: >> macOS 10.12.3, Xcode 8.2.1, ObjC >> >> I'm finding the following line to be problematic: >> >> NSMutableData *myData = [NSMutableData dataWithLength:80]; >> >> I assume this ends up calling calloc(3) to allocate and zero out the data. >> But for some reason, it's always setting errno to a seemingly random nonzero >> value, generally either errno=2 (ENOENT) or errno=22 (EINVAL). >> >> Now that I know it does this, I can make accommodations for it, but is this >> expected behavior? > > I don't know why it's happening here, but unless you're calling a function > that specifically documents its errno behavior, you should assume that every > call you make might randomly overwrite errno with gibberish. The POSIX standard specifically states that errno's value is undefined almost everywhere and can be arbitrarily changed by almost anything. http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html <http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html> -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: -forceCancel an NSOperation
> On Mar 1, 2017, at 3:10 PM, Carl Hoefs wrote: > > This is a multi-tasking server of sorts that runs different analysis > algorithms on demand depending on what's requested. But much of the > algorithmic code is "hostile" (i.e., student code) so it's unreliable at > best. I can firewall against the accvio's with NS_HANDLER et al, but not the > hangs and infinite loops. I was just fishing for a nicer solution than kill > -9... The most reliable thing to do is to run the student code as a separate process. You may be able to make use of alarm(3) or setitimer(2). These functions will send SIGALRM to your process after a specified timeout. That will in turn kill your process if you don't have a handler for that signal. Once the alarm is set there is no need for further interaction from your process, so the timeout will be reliably enforced even if the student code is stuck in a hang or a loop. I can't argue with the classification of student code as "hostile" and "malicious". -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: macOS 10.13 suggestion for init() throws
> On Feb 28, 2017, at 4:56 AM, Daryle Walker wrote: > > Could we have a NSDocument.init() that throws in the next macOS? That would > translate to a "initWithError" in Objective C (I think). It would be the new > primary initializer, with the current one calling it and dropping any error > to oblivion. It is not possible to retroactively change the designated initializers for a class. The designated initializer pattern requires subclasses to cooperate by overriding and calling particular initializers. Changing the designated initializers for a class like NSDocument would break all of its existing subclasses. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: What generates NSURLErrorUnsupportedURL?
> On Feb 8, 2017, at 2:44 PM, Jens Alfke wrote: > >> On Feb 8, 2017, at 10:38 AM, Steve Christensen wrote: >> >> The time between when the request is made and when it completes with an >> error might be a minute or so, so the framework is immediately bailing on >> the request. I'm wondering what part of the process generates the error. >> Does the server return a non-200 status code or what? > > The server is probably returning a redirect (301, 302 or 303) to a bogus URL. NSURLErrorUnsupportedURL in a background session is specifically a complaint that the URL is neither http nor https. Perhaps the server redirected to something else? > There’s a delegate method you can implement to see the redirected URL, which > could help you troubleshoot this. But it sounds like it’s the server’s fault. The bad URL is also recorded in the NSError's userInfo dictionary as NSURLErrorFailingURLStringErrorKey. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Overriding the release mehod
What Are You Trying To Do™ is in fact precisely the correct response to your question. Some overrides of -release need to call [super release]. Others do not. It depends on … what they are trying to do. Overriding release to unregister an observer is almost certainly a bad idea, but yes, such an override ought to call [super release] if the object is expected to be retained and released and deallocated normally. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler > On Jan 25, 2017, at 8:23 AM, Dave wrote: > > I hate it when people as that question! There are some memory leaks in a 3rd > party package. It overrides release to unregister an observer but doesn’t > call super. If I call super the leaks go away and all is well. I just want to > know where is it documented really, I can’t find it searching the docs. > > Cheers > Dave > >> On 25 Jan 2017, at 15:55, Mike Abdullah wrote: >> >> You’re inevitably going to get asked this: >> Why on earth are you overriding release? It’s an incredibly niche thing to >> do, and the answer probably depends a lot on why you’re overriding it. >> >>> On 25 Jan 2017, at 16:52, Dave wrote: >>> >>> Hi, >>> >>> Does [suoer release] need to be called if you override this method? I’m >>> 99.9% sure it does, but I can’t find it anywhere it actually says it in >>> black and white. >>> >>> All the Best >>> Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Using floating point instructions
> On Dec 6, 2016, at 7:27 AM, G 3 wrote:
>
> I'm working on a program that calls PowerPC assembly floating point
> instructions from C. It would have calls like this:
>
> double inputA, inputB, answer;
> asm volatile("fadd %0, %1, %2" : "=f" (answer) : "f" (inputA), "f" (inputB));
> // answer = inputA + inputB
>
> The odd thing is it only works in the debug configuration in XCode. In
> Release configuration, I see this error:
> error: output constraint 0 must specify a single register
> error: output operand 0 must use '&' constraint
>
> Is there a way to fix this problem?
You'll get better answers from a clang list such as cfe-us...@lists.llvm.org.
Most of the audience here probably does not have a copy of clang that can
compile PowerPC code.
Why are you using constraint "f" here? I would expect you to use "d" with
variables of type double.
--
Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime
Wrangler
___
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: iOS: Preventing a singleton from being deallocated when the app is in the background.
> On Oct 19, 2016, at 8:41 PM, Alex Zavatone wrote: > > In that case we would find out really quickly, because this is one of the > classes that starts up as soon as the app makes several server calls. When > our error happens that appears like a dealloc, the app has been running and > using this class for a while and is sitting around on iOS while it is in the > background. > > Yet we are seeing log output indicating the init method getting executed > twice. Verify that you are seeing two init logs from one process rather than one init log each from two processes. (Adding the PID to the log should resolve that, if you don't have it already.) Verify that your singleton enforcement is thread-safe. Thread-unsafe singleton enforcement can create a second singleton if there is a race. Log the stack trace of each init call. Perhaps one caller is bypassing your singleton enforcement somehow. (For example, you wrote singleton enforcement in +alloc but some call sites are using +allocWithZone:.) Log the address of the object being returned by init. Perhaps there is only one object but init is being called a second time on it. Log or crash in dealloc, if your singleton enforcement might allow the object to be deallocated and then a new one to be created. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: iOS: Preventing a singleton from being deallocated when the app is in the background.
> On Oct 19, 2016, at 2:29 PM, Steve Christensen wrote: > > The only difference between your code and mine is that you haven't > initialized onceToken = 0 so it has a random value. > > I looked around to see if that makes a difference and didn't get much > confirmation one way or another. One by Mike Ash > (https://www.mikeash.com/pyblog/friday-qa-2014-06-06-secrets-of-dispatch_once.html) > mentions, "Note that dispatch_once_t is just a typedef for long, initialized > to zero, and with the meaning of other values left up to the implementation." No difference. C static storage with no initializer is always initialized to zero. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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 count Atoms
> On Oct 7, 2016, at 9:06 PM, Gerriet M. Denkmann wrote: > > My preferred way to count (not deprecated and fast, but, as you said, > probably not available in Swift) is: > > #import > atomic_uint_fast64_t counter; > atomic_fetch_add_explicit( &counter, 1, memory_order_relaxed ); > > I have no idea, whether atomic_uint_fast64_t is correct (there also is > atomic_uint_least64_t — what is the difference ?) > > I looked at <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf> (as > kindly mentioned by Alastair). > In “7.17.6 Atomic integer types” it says: “The semantics of the operations on > these types are defined in 7.17.7”. > But 7.17.7 does not mention any difference between atomic_uint_fast64_t and > atomic_uint_least64_t. These types are the atomic versions of uint_fast64_t and uint_least64_t. uint_least64_t is the smallest type that is at least 64 bits. uint_fast64_t is the fastest type that is at least 64 bits. uint64_t is exactly 64 bits. On all current architectures, uint_least64_t and uint_fast64_t and uint64_t are the same type. The differences generally appear for smaller types on older architectures. For example, uint_least8_t and uint_fast8_t might differ on a classic Cray architecture that used word-addressable memory instead of byte-addressable memory. uint_least8_t would be 8 bits but require bit-shuffling operations; uint_fast8_t would not need bit shuffling but would be a full word in size. > and what memory_order_relaxed means (Xcode suggested this to me while warning > about deprecation of OSAtomicIncrement64). Memory ordering determines how different operations are ordered with respect to each other. For example, if you were using atomic operations to implement a mutex then you would use an appropriate memory order to guarantee that all of the code protected by the lock runs inside the lock. Without memory ordering the compiler or CPU could move the protected code before the atomic lock-acquire operation completes or after the atomic lock-release operation begins, which would defeat the lock. memory_order_relaxed says that there is no additional ordering of this atomic operation with respect to anything else. This ordering is the fastest because it doesn't add any expensive memory barriers. It's fine for a simple debugging counter, but could be thread-unsafe if you had other code that did something based on the counter's value. If you are familiar with the deprecated OSAtomic functions, the difference between OSAtomicIncrement64 and OSAtomicIncrement64Barrier is memory ordering. The deprecation warning told you to use memory_order_relaxed because that is the memory ordering used by OSAtomicIncrement64. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Success with NSTableView weak delegates?
> On Sep 20, 2016, at 2:47 PM, Sean McBride wrote: > > On Tue, 20 Sep 2016 14:26:27 -0700, David Duncan said: > >>> On Sep 20, 2016, at 1:21 PM, Sean McBride wrote: >>> >>> Hi all, >>> >>> WWDC 2016 Session 203 "What's New in Cocoa" at around 43:37 in the >>> video, says that if you link against the 10.11 SDK that NSTableView's >>> delegate is weak. So I went and wrapped my delegate nil-ing in: >>> >>> #if MAC_OS_X_VERSION_MAX_ALLOWED < 101100 >>> [tableView setDelegate:nil]; >>> [tableView setDataSource:nil]; >>> #endif >>> >>> yet (with NSZombie especially), I easily reproduce message-to-zombie >>> crashes with builds that are made against the Xcode 7.3.1 10.11 SDK. >> >> On which OS version? > > At runtime: 10.9.5, 10.10.5, and 10.11.6. > >> The macro above only says “do this if I link against an SDK prior to >> 10.11” – that doesn’t handle what happens at runtime when you are on >> 10.10 or below. In particular, if you plan to deploy back to prior to >> 10.11, then you would want to either do a runtime check, or for trivial >> code like this always run the code until your MIN_ALLOWED (deployment >> target) is >= 10.11. > > Yes, I'm aware of these differences. I'm also aware, as you surely are, that > sometimes behaviour depends (only) on what SDK you link against. > > If you scrub to around 43:37 here: > <https://developer.apple.com/videos/play/wwdc2016/203/> > > you'll see they specifically refer to "linked on 10.11". > > Besides, I both build and run on 10.11.6 and yet I see these > message-to-zombie crashes after removing the setDelegate:nil code. Those crashes are expected. NSTableView's delegate is zeroing-weak when both of the following are true: * Your app was built with the 10.11 SDK or newer. * Your app is running on 10.12 or newer. The delegate is unsafe-unretained when running on 10.11 and earlier, no matter what SDK you built with. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Why doesn't this crash?
> On Sep 10, 2016, at 4:39 AM, Andreas Falkenhahn
> wrote:
>
> I want my app to run on 10.6 but use 10.7 features where available. Thus I'm
> compiling on 10.11 using -mmacosx-version-min=10.6. In particular, I want to
> use AVFoundation to play videos on 10.7 and better.
>
> To open a video, I do the following:
>
>AVPlayer *p = [[AVPlayer alloc] initWithURL:url];
>
> I'd expect this code to crash on 10.6 because 10.6 doesn't have AVPlayer.
> To my surprise, however, the code doesn't crash and it just returns NULL.
> This is fine because then my app will just show a message box informing
> the user that the file couldn't be opened and no other AVFoundation APIs
> will be accessed.
>
> However, I'm wondering whether it is ok to execute this code on 10.6 without
> any safeguard. I thought I'd have to do something like this instead:
>
>if(floor(NSAppKitVersionNumber) >= NSAppKitVersionNumber10_7) {
>
>AVPlayer *p = [[AVPlayer alloc] initWithURL:url];
>...
>
>} else {
>
>return NULL;
>}
>
> Do I have to do this or can I just rely on alloc/init returning NULL for
> classes unknown on 10.6?
If your deployment target is OS X 10.7 or iOS 3.1 or later
and class SomeClass is declared weak-import (for example, it has an
availability attribute that is newer than your deployment target)
then all of the following are true:
* [SomeClass anyMessage] returns nil.
* [MySubclassOfSomeClass anyMessage] returns nil.
* Subclasses of SomeClass are ignored by the runtime; it acts as if they do
not exist.
* Categories attached to SomeClass or a subclass thereof are ignored by the
runtime.
If your deployment target is OS X 10.7 or iOS 3.0 or earlier
or SomeClass is not declared weak-import (for example, it has no availability
attribute or you didn't set your deployment target correctly)
then it is unsafe to use SomeClass or subclass SomeClass directly. You must not
call [SomeClass anyMessage]. You must use the result of objc_getClass() instead.
Some "unavailable" classes were in fact present as SPI on older OS versions.
That will confuse tests like `if ([SomeClass class]) { … }`. Test your code on
your old deployment targets.
--
Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime
Wrangler
___
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 do isKindOfClass in Swift
> On Sep 12, 2016, at 10:14 AM, Quincey Morris > wrote: > >> On Sep 12, 2016, at 03:17 , Gerriet M. Denkmann wrote: >> >> The I got back to the real project: and could also not reproduce it there. >> >> One explanation: working with Swift, I quite often (a few times per day) see >> strange (runtime) errors. Cleaning the project, then building again >> invariable fixes these. >> Maybe this was one of those. > > What version of Xcode are you using? FWIW, it’s pretty clear that the version > of Swift in the Xcode 8 GM is generating incorrect code or incorrect debug > information or corrupting its own indexes. I’ve seen it in my own projects, > and problems have been reported in the developer forums that sound similar. > Typically, it appears, cleaning the build folder fixes the problem. Did you file a bug report? -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Linking against AVKit breaks app on 10.6
> On Sep 12, 2016, at 12:40 AM, Alastair Houghton > wrote: > >> On 10 Sep 2016, at 12:47, Andreas Falkenhahn wrote: >> >> When I link my app against AVKit using >> >> -framework AVKit >> >> it fails to load on 10.6 claiming >> >> dyld: Library not loaded: >> /System/Library/Frameworks/AVKit.framework/Versions/A/AVKit >> Referenced from: ... >> Reason: image not found >> Trace/BPT trap > > This is probably happening because AVKit doesn’t declare its symbols as > weakly imported, while the other frameworks do. You can force weak linking > for that particular framework using > > -weak_framework AVKit > > instead of just using the normal “-framework”. Please file a bug report. A missing availability attribute somewhere would be a bug in AVFoundation. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Init in Swift
> On Sep 6, 2016, at 5:17 PM, Gerriet M. Denkmann wrote: > >> On 5 Sep 2016, at 13:29, Quincey Morris >> wrote: >> >> More globally, this sort of thing is not terribly idiomatic for Swift, >> because you’re trying to hide things that could get exposed other ways, for >> example, by “hostile” subclassing. The Swift-ier way would be to use a >> protocol instead of (or in addition to, but preferably instead of) the >> superclass. The protocol would “force” the subclass to define its own >> “onlyKnownBySubclass” locally. > > I do not think this would work for me. There are several subclasses and the > superclass contains lots of functions (some of which are overwritten by > subclasses). > If the superclass becomes a protocol then all this code had to be duplicated > in each subclass. Swift protocol extensions can solve some of those problems. The protocol extension provides a default implementation to every class that conforms to the protocol. Each class may provide its own implementation that overrides the protocol extension's default implementation. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: Mysterious crash with NSTableView
> On Aug 26, 2016, at 10:46 PM, Doug Hill wrote: > >> On Aug 26, 2016, at 9:20 PM, Jeff Szuhay wrote: >> >>>> On Aug 26, 2016, at 8:44 PM, Sandor Szatmari >>>> wrote: >>>> >>>> However, in your case I wonder what the static analyzer in Xcode tells you >>>> about the bug you see? >>> >>> I believe Andreas mentioned he does not use Xcode as his product is cross >>> platform, but this is a good suggestion. >> >> Any why not? >> >> Sure, build it without Xcode, but couldn’t you create a shell project where >> the product doesn’t really matter, then build and use the tools in Xcode? > > I believe you can also invoke the analyzer via the command-line tools. If your build system runs from the command line and honors the CC and CXX environment variables then you may be able to use the scan-build tool to run the clang static analyzer. http://clang-analyzer.llvm.org/scan-build.html -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Codesign assumes folder structure, fails.
> On Jul 25, 2016, at 6:15 PM, Graham Cox wrote: > > Hi all, > > I’m getting an error from codesign when it tries to sign a third-party > embedded framework. > > The error is: > > /Users/grahamcox/Library/Developer/Xcode/DerivedData/Drawkit-hlbdxcwqkoiqzlesbkfsrobctzke/Build/Products/Debug/Ortelius > 2.app/Contents/Frameworks/GEOS.framework/Versions/A: No such file or > directory > Command /usr/bin/codesign failed with exit code 1 > > The problem is that GEOS.framework/Versions/A doesn’t exist. That’s true - > the alias ‘Current’ points to a folder called ‘3’ within Versions which > contains the executable. ‘A’ doesn’t exist. (i.e. the path is > GEOS.framework/Versions/3, and this is where GEOS.framework/Versions/Current > points to) > > Isn’t this a serious bad assumtion on the part of codesign? Surely the bundle > folder structure for executables has always allowed the ‘current’ version to > be changed, and ‘A’ is merely the conventional name for version 1, followed > by ‘B’, etc? In this case it seems to be using ‘3’ in a sequence which may > once have held ‘1’, ‘2’… > > This is a 3rd party framework, I have not built it myself, and I’d rather not > have to if I can help it. Renaming the folders is easy enough, but > nevertheless I would expect codesign to understand the long-standing > versioning schema within a bundle. > > Bug or reasonable assumption? My understanding is that this is a limitation of the Xcode build system. codesign doesn't care about the framework's structure, but Xcode does and it is telling codesign to look at the wrong path. You should mention rdar://17814234 when you file your bug report. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Property synthesis trouble - 32 vs 64 bit builds
> On Jul 5, 2016, at 9:27 AM, Jens Alfke wrote: > >> On Jul 5, 2016, at 4:36 AM, Jonathan Taylor >> wrote: >> >> It surprises me that I have to write different synthesis code for 32- or >> 64-bit builds > > It’s because they use different Obj-C runtimes. For compatibility reasons, > 32-bit Mac apps still use the old runtime, while 64-bit apps (and all iOS > apps) get to use the new improved runtime. > > One of the differences between the runtimes is how instance variables are > accessed, and I think your particular situation — trying to synthesize a > property backed by an _inherited_ ivar — is an edge case. A synthesized property must use one of the following types of storage: 1. An ivar in that class that @synthesize creates. 2. An ivar in that class that you defined yourself. @synthesize on 32-bit macOS doesn't support #1. The problem is that 32-bit macOS doesn't support non-fragile ivars. Allowing @synthesize to create ivars would make it too easy to accidentally change ivar layout and break compatibility. No platform allows @synthesize to bind to a superclass ivar. That would make it too easy to accidentally bind to an unrelated superclass ivar when you really wanted to create a new ivar. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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)
> On Jun 1, 2016, at 4:52 AM, Gerriet M. Denkmann wrote: > > Some Apple engineer asked me to do 3 to 5 reboots. > This sounded like voodoo to me, but I duly did 3 reboots. > Now my iPad gets discovered again (was undiscovered for a week, a reboot did > not change anything). > > Can anybody explain why 3 reboots ≠ 1 reboot? One possibility: some systems will reset caches or other state if the previous uptime was too short. This gets you out of reboot loops when a cache gets corrupted, for example. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: BOOL parameter passed as nil object
> On Apr 19, 2016, at 12:07 PM, Jens Alfke wrote: > >> On Apr 19, 2016, at 10:22 AM, Alex Zavatone wrote: >> >> I believe that a BOOL can only be YES or NO. A nil value on a BOOL would be >> NO if I am correct. > > At the language level, yes. Not even there. On some platforms BOOL is defined as signed char. It may have any of 254 values other than YES or NO. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: BOOL parameter passed as nil object
> On Apr 18, 2016, at 6:56 PM, Carl Hoefs > wrote: > > Suppose I have an object with a declared method signature: > -(void)myMethod:(BOOL)a_bool; > > Q1: If I invoke it like this: > [self performSelector:@selector(myMethod:) withObject:nil]; // nil obj > Will argument a_bool end up with a 0 value assigned to it? Don't do that. The behavior is undefined. It probably happens to work on all current architectures. > Q2: But if I invoke it like this: > [self performSelector:@selector(myMethod:) withObject:someObj]; // valid obj > Will argument a_bool end up with a 1 value assigned to it? Don't do that. The behavior is undefined. It will certainly fail on some current architectures at least some of the time. You should not use -performSelector:withObject: to call methods that use non-object parameters. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?
> On Mar 4, 2016, at 2:24 PM, Jonathan Mitchell wrote: > > Hi Alex > > Not sure if this will help at all as I am not 100% sure what you are doing. > In my case, using Mono, I needed to track events being raised in the Mono C > runtime back into Obj-C space. > You need some method of defining a call back function in the target C Api - > without that thinks would look rather bleak. > > Basically the C Mono runtime is configured to a call static C function in an > Obj C .m file in response to a C# managed event firing. > The static then calls a static method on an Obj-C class. > This Obj-C static uses collections to track registered events and invokes > performSelector: on a registered Obj-C target. > See here: > https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/Representations/DBManagedEvent.m > > One of the arguments based in as part of the event callback is a pointer that > is used as a a key to retrieve the target NSObject. > This is complicated by the fact that the incoming pointer represents a > moveable memory location so there is some extra indirection too. > https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/Representations/DBPrimaryInstanceCache.m > > This can get a bit complex but its all doable. Block objects can help. clang supports block objects in plain C code (-fblocks, I think). Your Objective-C code can create a block object that performs the callback and pass it to the C code to store and call. The block object would capture the target NSObject so you don't need the dictionary of callback targets. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
> On Feb 24, 2016, at 2:31 AM, Dave wrote: > > Also, beware subclassing a Non-ARC Class in an ARC Project - you have to have > the subclass Non-ARC too. This is not true. For example, NSView is not ARC but you can write ARC subclasses of it. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
> On Feb 23, 2016, at 3:46 PM, Alex Zavatone wrote: > > Aha! > > Awesome. That will work nicely. > > Now my concern is the compiled c lib that my code links to. Do I also have > to rebuild that with non ARC flags too? The ARC flags only affect the Objective-C and Objective-C++ compilers. Plain C code is unaffected. Note that you may need code changes if your C code uses CoreFoundation types and you want to call it from ARC code. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
> On Feb 23, 2016, at 3:25 PM, Alex Zavatone wrote:
>
> Would it be recommended to package my ARC code with ARC turned off and
> package that in a framework and then link to that from the non ARC app that
> will need to load it?
Building a separate dylib or static archive is not necessary, but it might be
the simplest way to get the project settings correct. Writing custom build
flags for each of your source files is likely to be error-prone.
You can add a check to your ARC source files that will cause a compiler error
if ARC is mistakenly off:
#if !__has_feature(objc_arc)
# error This file must be compiled with ARC enabled.
#endif
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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
> On Feb 23, 2016, at 1:30 PM, Alex Zavatone wrote: > > Hi all. I'm in the middle of looking at an interesting problem on the iOS > side. > > We have our code that is ARC and uses external compiled C libs that I'm being > asked to plug into another iOS project that's significantly larger than ours. > > The intent is to run as a little service that can be launched within the > other iOS project. > > The other project that we must fit within is not ARC. Converting it to ARC is > not feasible, nor our responsibility. > > I am successfully building the iOS app that doesn't use ARC with Xcode 7.1 > and running on iOS 9.1. > > Now, I'm familiar with the -fno-objc-arc build flags to disable compiling one > file at a time, but is there any possibility to include iOS code that does > use ARC within an app that doesn't? Yes, -fno-objc-arc works on iOS too. Was that your question? -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: calendar & repeating events api
> On Feb 16, 2016, at 6:34 PM, Eric Gorr wrote: > > When setting up a repeating event in Apple’s Calendar application, there is a > lot of flexibility. For example, I can specify that an event repeats every > month on the 5th Saturday. Of course, not every month has a fifth saturday, > so for that month there is no event. > > What I am wondering is if there is direct api support for doing these date > calculations…can I supply a set of parameters to a function and ask what the > next 5th saturday of the month is? You can use NSDateComponents and NSCalendar to perform this sort of calculation. For example, assuming a Gregorian calendar, you can use an NSDateComponents object with weekday=7 and weekdayOrdinal=5 to represent "fifth Saturday", and use NSCalendar enumerateDatesStartingAfterDate:matchingComponents:options:usingBlock: to find "fifth Saturdays" after some starting date. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Obj-C - your thoughts on hiding data members?
> On Jan 24, 2016, at 3:55 PM, Graham Cox wrote: > > In Objective-C 2, data members can be moved into a @interface MyClass () > section which lives in the .m file, rather than in the header file as in the > classic case. This makes sense - those data members are typically part of the > private implementation details of a class and not part of the public > interface. Even better, you can move them to @implementation itself. No need for the extra class extension if everything is used inside a single file. > But is it worth updating older code to follow this convention? I’ve updated a > lot of older code to declare @properties instead of classic getters and > setters, and that definitely improves readability. This is a further step I’m > contemplating but the benefits are less clear. Do you generally think this is > worth doing? A performance gain. @public and @protected ivars each create an exported symbol; @private and @package ivars do not. Reducing symbol exports can improve launch time and stripped executable size. Ivars declared in @implementation or a class extension @interface are @private by default. Ivars in the primary @interface are @protected by default. Therefore you should either move your ivars out of the primary @interface, or leave them in @interface but explicitly declare them @private or @package. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Adding minutes to display time
> On Dec 8, 2015, at 2:04 PM, Eric E. Dolecki wrote:
>
> I tried an extension I found. It's off by 5 hours...
>
> extension NSDate
> {
>convenience
>init(dateString:String) {
>let dateStringFormatter = NSDateFormatter()
>dateStringFormatter.calendar = NSCalendar(calendarIdentifier:
> NSCalendarIdentifierGregorian)
>dateStringFormatter.dateFormat = "-MM-dd HH:mm"
>dateStringFormatter.locale = NSLocale(localeIdentifier:
> "en_US_POSIX")
>dateStringFormatter.timeZone = NSTimeZone.localTimeZone()
>let d = dateStringFormatter.dateFromString(dateString)!
>self.init(timeInterval:0, sinceDate:d)
>}
> }
>
> ...
>
> let calendar = NSCalendar.currentCalendar()
>calendar.timeZone = NSTimeZone.localTimeZone()
>calendar.locale = NSLocale(localeIdentifier: "en_US_POSIX")
>let startDate = NSDate(dateString:"2015-12-08 7:30")
>let date = calendar.dateByAddingUnit(.Minute, value: 5, toDate:
> startDate, options: [])
> *print (date!) //This is way off. How to fix this?*
What is the value of print(startDate) ?
What do you get if you display `date` and `startDate` using an NSDateFormatter
instead of print() ?
I bet `date` and `startDate` are in fact five minutes apart, but either your
date construction or your date display are not using the time zone you expect.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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 screensavers in Ubuntu?
> On Dec 4, 2015, at 3:17 PM, Juanjo Conti wrote: > > Now that Swift is open source and runs on Ubuntu, do you think a Swift Mac > OS X screensaver could run as a screensaver in Ubuntu? What about a GUI > used to config the screensaver? Not without a lot of work. Open-source Swift is available for Linux but the Swift/ObjC/Cocoa bridge is not. That would break your OS X screensaver assuming that it draws anything. Somebody would have to do something like port the Swift-ObjC bridging machinery to the GNU Objective-C runtime and update the GNUstep SDK to work with the Swift-ObjC importer. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: The joys of people using valueForKey to get objects out of a dictionary.
> On Nov 10, 2015, at 8:32 AM, Alex Zavatone wrote:
>
> It's been about 4 or 5 years since I made this mistake but I've just seen a
> massive swath of code where every access of a dictionary object is using
> valueForKey instead of objectForKey.
>
> I've got a few examples of why this is a "really bad idea"™, and certainly
> might explain why lots of that code is wrapped in try/catch blocks.
>
> Am I correct that using valueForKey will raise an exception if the key is
> missing?
>
> Looking for reasons why I can explain "yeah, I know it works, but here's why
> it's a terrible idea to use to access a dictionary's objects".
-valueForKey: interprets keys whose name starts with '@' specially. Examples:
[dict valueForKey:@"@allKeys"] returns an array of all keys in the dictionary.
valueForKey: throws an exception if the key name starts with '@' and the name
isn't recognized by KVC as special.
% cat test.m
#import
int main(int argc, char *argv[]) {
NSDictionary *dict = @{ @"ordinary" : @"ordinary value",
@"@allKeys" : @"@allKeys value",
@"something" : @"something value",
@"@something" : @"@something value" };
// -objectForKey does the usual thing
NSLog(@"-- objectForKey --");
NSLog(@"%@", [dict objectForKey:@"ordinary"]);
NSLog(@"%@", [dict objectForKey:@"@allKeys"]);
NSLog(@"%@", [dict objectForKey:@"@something"]);
// -valueForKey does not
NSLog(@"-- valueForKey --");
NSLog(@"%@", [dict valueForKey:@"ordinary"]);
NSLog(@"%@", [dict valueForKey:@"@allKeys"]);
NSLog(@"%@", [dict valueForKey:@"@something"]);
}
% clang test.m -framework Foundation && ./a.out
2015-11-10 10:00:55.295 a.out[38293:4747164] -- objectForKey --
2015-11-10 10:00:55.296 a.out[38293:4747164] ordinary value
2015-11-10 10:00:55.296 a.out[38293:4747164] @allKeys value
2015-11-10 10:00:55.296 a.out[38293:4747164] @something value
2015-11-10 10:00:55.296 a.out[38293:4747164] -- valueForKey --
2015-11-10 10:00:55.296 a.out[38293:4747164] ordinary value
2015-11-10 10:00:55.297 a.out[38293:4747164] (
something,
ordinary,
"@allKeys",
"@something"
)
2015-11-10 10:00:55.298 a.out[38293:4747164] *** Terminating app due to
uncaught exception 'NSUnknownKeyException', reason: '[<__NSDictionaryI
0x7fc0b850ead0> valueForUndefinedKey:]: this class is not key value
coding-compliant for the key something.'
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: NSFileWrapper - is this really so bad?
> On Oct 27, 2015, at 4:24 PM, Graham Cox wrote: > > In XCode 7, I’m getting a new warning when compiling some code that uses > NSFileWrapper, due to the addition of the NON_NULL qualifier: > > Null passed to a callee that requires a non-null argument > > The code is: > > NSFileWrapper* fw = [[NSFileWrapper alloc] > initDirectoryWithFileWrappers:nil]; //<— Null passed to a callee > that requires a non-null argument > [fw setPreferredFilename:[self name]]; > [fw addRegularFileWithContents:content > preferredFilename:kDKOLibraryItemDataFileName]; > > I’ve been doing this forever without any issue - create the directory file > wrapper, then add regular files to it. The API design appears to condone this > approach, even if it’s not spelt out anywhere. Now it seems we have to turn > this all around and precreate the dictionary then create the enclosing > directory wrapper. > > While this change isn’t too hard, it seems like extra work and means going > through old code that’s working fine, with the possiblity of creating bugs. > > Has this approach always been bad, or is it a new thing? I’m all for > tightening up sloppy coding, but could it be that in this case the non-null > qualifier is in error? Please file a bug report if you think a nullability annotation may be incorrect or that a nullability annotation and the documentation don't match. It is unlikely that all of the new annotations and all of the documentation are correct. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: New warning in Xcode 7
> On Oct 13, 2015, at 3:24 PM, Graham Cox wrote: > > In a piece of code I haven’t worked on in a while, I’m suddenly getting a new > warning which I’ve never seen before: > > “Multiple unsequenced modifications to ‘ix’” > > Code is: > > ix = ++ix % guess.count; > > where ix is a NSUInteger. > > Is this telling me that the order of the preincrement and the mod operation > is undefined? Surely a preincrement is defined to happen first, that’s why > it’s called a PREincrement? Or does the warning refer to something else? I’ve > used this form of expression for years without any issues, why is it suddenly > one? The mod operator uses the value after the increment. That part is well-defined. The compiler is complaining about the two stores to `ix`, one from the preincrement and one from operator =. Storing to the same location twice in the same statement is undefined in many cases: the language does not specify which one wins. Look up "sequence point" for more details (although the current language standards no longer use the "sequence point" terminology). I thought that this particular form was allowed, but I'm not enough of a language lawyer to know for sure. You might get better answers from a compiler mailing list. You can avoid confusion (human and compiler) by writing the statement without the preincrement's side effect: ix = (ix+1) % guess.count; -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: More Swift issues, NSURLComponents
> On Oct 5, 2015, at 7:57 PM, Rick Mann wrote: > > Especially when a struct can be an AnyObject. `AnyObject` is an instance of any class type. It is never a struct. `Any` encompasses both classes and structs. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Mac OSX 10.11 and XCode
> On Oct 1, 2015, at 9:20 AM, Dave wrote: > > Hi All, > > I’m running on a Mac Pro 3.1. > > I’ve installed 10.11 and XCode 7.0.1, now every now and then for no apparent > reason while in XCode, suddenly all 4 of my monitors go black and the machine > hangs for maybe 30 seconds then suddenly I get presented with the Log In > Screen. Is this new behaviour in 10.11? It used to crash and then you’d get a > message and it would restart. Sounds like the crash hit something that took down your login session but wasn't bad enough to take down the entire machine. For example a WindowServer crash will drop you back to the login window without a restart. Only kernel panics and a handful of other very low-level crashes will cause a restart. If you see this crash repeatedly, please check Console.app for log messages and crashes at the time of the logout and file a bug report with them. > Annoyingly when I log back in it restarts all the App’s that were running > before the crash to Log In window. I seem to remember there was a System > Default to switch this off, but I can’t seem to find it again now - was I > imaging things? If I recall correctly, you can choose whether or not to relaunch apps when you deliberately log out or restart, but relaunch is automatic for involuntary crashes. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: -[NSThread start] blocks ?!?
> On Sep 26, 2015, at 3:33 PM, Jerry Krinock wrote: > > In a OS X app, predating Grand Central Dispatch, in the main thread, I create > and start a new thread > > NSThread* worker ; > worker = [[NSThread alloc] initWithTarget:instance > selector:@selector(beginWithInfo:) > object:info] ; > [worker setName:@“My Worker thread"] ; > [worker start] ; > > usually this works OK, but sometimes, possibly when the above code executes a > second or third time in rapid succession, [worker start] will block forever: > > Thread 1 Queue : com.apple.main-thread (serial) > #00x7fff93c50cd2 in semaphore_wait_trap () > #10x0001007614b4 in _dispatch_semaphore_wait_slow () > #20x7fff9134fae2 in -[NSThread start] () > > Looking at the other threads, I see that “My Worker thread” (see Thread 455, > below) has been created, and seems to be stuck while trying to *exit*, which > I think is weird because if -[NSThread start] blocked until the new thread > exitted, that would defeat the purpose of multithreading. Same thing if, > say, My Worker thread executed some kind of “do this on the main thread” call. > > Should not -[NSThread start] always return before running any of my code in > the new thread? So how could this happen? I’m running OS X 10.11. The threads listed are all waiting for a spinlock used by the debugging tools. (Specifically, it's the machinery that records stack traces of queue operations.) If you see this again, please capture a spindump and file a bug report. After you file the bug report, you might be able to work around it like this: defaults write com.apple.dt.Xcode DBGSkipRecordedFrames -bool YES then quit and relaunch Xcode. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: OpenGL Vertical Syncing effect on run loops
> On Sep 22, 2015, at 6:56 PM, Jerry Krinock wrote: > > In Apple document QA1385, in Listing 2, describing how to drive OpenGL > Rendering Loops 10 years ago, an NSTimer, repeating every 1 millisecond, is > added to an app’s run loop [1]. Just to be clear: don't do that. Use CVDisplayLink. > Referring to this timer, the text says that: > > "When vertical synchronization is enabled in your OpenGL application, during > each retrace period, when the timer fires, …” > > H, a timer with time interval of 1 millisecond is now going to fire > during each retrace period, 16.7 milliseconds or so! This implies that when > vertical synchronization is enabled in an OpenGL application, the > application’s run loop, in all modes, is synchronized to the video frame and > can go no faster. Is this correct? It is not. The timer would fire multiple times per retrace if it were unhindered. But at some point the timer callback will provoke an OpenGL buffer swap, and that will block until the next retrace when vertical synchronization is enabled. The gated buffer swap inside the timer callback is the rate-limiting factor, not anything in the runloop or NSTimer itself. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Error unwrapping an optional which isn't an optional
> On Sep 21, 2015, at 11:01 AM, Alex Hall wrote:
>
> Hi list,
> I'm setting up a binding using an NSController, which I want to connect the
> currently selected row in a table to the values of some UI controls. Put
> another way, whenever the table's selected row changes, the binding should
> cause some controls to display new information pulled from the row.
>
> It's not working, but the error I'm seeing makes no sense. I've switched to
> using tableViewSelectionDidChange in a delegate, and that works perfectly.
> I'm not desperate to solve this problem since my delegate does what I want;
> I'm more curious about why it might be happening.
>
> The key for the binding is my view controller .currentTweet. That property is
> computed, and I've marked it as dynamic and implemented keyPathsForValues.
> Yet, when I run it with the binding in place: "fatal error: unexpectedly got
> nil while unwrapping an optional value." The weird part: nowhere on the line
> in question do I use an optional. Here are two declarations. The first is
> where the second gets its value; the second is what my controller is bound
> to. Both of these happen in my ViewController subclass, outside of any
> methods.
>
> dynamic var currentTweet:Tweet? {
> get {
> return currentTab.tweetsList[tweetsTable.selectedRow]
> //Xcode points to this line as the problem
> }
> }
>
> dynamic var currentTweetID:String? {
> get {
> if let tempTweet=currentTweet, tempID =
> tempTweet.idAsString {
> return tempID
> }
> return nil
> }
> }
>
> Yes, both properties are optional, but the line Xcode is complaining about
> has no optionals at all.
How are currentTab and tweetsList and tweetsTable declared? Those are the
obvious candidates for an optional access.
What is the stack trace of the error? Perhaps one of those references is itself
a complex accessor that accesses an optional internally.
> I thought about putting the tweetsTable.selectedRow bit in an 'if let', but
> that won't work because it's not optional so Swift won't let it in an 'if
> let'.
selectedRow's "row index or -1" behavior is an obvious candidate for a Swift
optional, but we don't currently have a good way to bridge such API with
Objective-C.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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 down source of [_NSControllerObjectProxy copyWithZone:]… error
> On Sep 19, 2015, at 8:09 PM, Alex Hall wrote: > > Hey list, > A binding is driving my app (my actual one, not the test one) and has been > for days now--awesome! Amid more refactoring of my code, and adding a second > binding which didn't take because of uninitialized properties, I've now > started seeing this error in my debug log: > > [_NSControllerObjectProxy copyWithZone:]: unrecognized selector sent to > instance 0x60800ae0 > > failed to set (contentViewController) user defined inspected property on > (NSWindow): -[_NSControllerObjectProxy copyWithZone:]: unrecognized selector > sent to instance 0x60800ae0 > > From what I've been reading, this is due to something trying to copy an > object that doesn't conform to the NSCopy protocol. Most likely, I have a > proxy object somewhere Cocoa expects an instance, and since the proxy can't > be copied, this is happening. The problem is, I can't see *where* this is > going on. My debug log is showing me this, but my debug navigator is empty. > There's no runtime error showing in a source file like there is when the line > causing the problem is clear, and since I only have an address for the > instance and not a name, I'm at a bit of a loss. What is a good strategy for > discovering the source of this problem so I can fix it? This is probably failing to crash because "unrecognized selector" throws an exception and the exception is being caught and ignored somewhere. If you can reproduce this yourself, try running with an Exceptions breakpoint set. That should stop in the debugger with the call site in the stack trace. (Breakpoints navigator > "+" button at the bottom > Add Exception Breakpoint) Another dumb alternative: implement -[_NSControllerObjectProxy copyWithZone:] to call abort() or otherwise halt the process. Then it will stop in the debugger or generate a crash log with a stack trace pointing to the call site. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: combining Obj-C enums
> On Sep 9, 2015, at 6:28 PM, Rick Mann wrote: > > I've not found a succinct way to do this. Is there one? > >let files = try fm.contentsOfDirectoryAtURL(inFile, > includingPropertiesForKeys: nil, > options: > .SkipsSubdirectoryDescendants | .SkipsPackageDescendants | .SkipsHiddenFiles) In Swift 2 this is an OptionSetType. An option set literal looks like this: [.SkipsSubdirectoryDescendants, .SkipsPackageDescendants, .SkipsHiddenFiles] -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: String.join()?
> On Sep 4, 2015, at 2:29 PM, Quincey Morris > wrote: > >> On Sep 4, 2015, at 14:04 , Rick Mann wrote: >> >> According to the docs in Xcode 7b6, join(_:) is a method on String. But if I >> try to call it: >> >> Of course, I can't command-click on join() to get to its declaration, and >> option-clicking on it doesn't link to its documentation. > > Sorry, I forgot to start with the basic point, which is that there is no > ‘join’ method anywhere any more (except in the ghostly form that lets the > compiler tell you it doesn’t exist any more), so you can’t call it or > command-click to it. You should file a bug report. It might be possible to make unavailable identifiers command-clickable, which would reveal their OS availability range or their suggested replacements. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: should computed properties be able to throw exceptions?
> On Aug 21, 2015, at 9:00 PM, Rick Mann wrote:
>
>> On Aug 21, 2015, at 20:58 , Greg Parker wrote:
>>
>>> Rick Mann wrote:
>>>
>>> Also, if the method of the call site is marked as "throws," does that mean
>>> the error will propagate out?
>>
>> Nothing you write in Swift will have any effect on C++/ObjC exception
>> unwinding.
>
> Sorry, I meant within Swift's error handling, if the call site does nothing
> other than be a function marked with throws, that's legal right?
>
> func
> one() throws
> {
>two()
> }
>
>
> func
> two() throws
> {
>throw something
> }
It is not legal. All call sites to methods that may throw must use `try`. The
call site must explicitly acknowledge the possibility of an error.
test.swift:4:4: error: call can throw but is not marked with 'try'
two()
^
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: should computed properties be able to throw exceptions?
> On Aug 21, 2015, at 8:18 PM, Rick Mann wrote: > >> On Aug 21, 2015, at 20:06 , Greg Parker wrote: >> >>> On Aug 21, 2015, at 6:15 PM, Rick Mann wrote: >>> >>>> On Aug 21, 2015, at 18:13 , Quincey Morris >>>> wrote: >>>> >>>> I’d recommend you try to avoid calling the Swift side “exceptions”. It’s >>>> error handling, and although it’s not completely unlike exception handling >>>> in other (non-Obj-C) languages, it’s treacherous to confuse the two when >>>> dealing with Obj-C. >>> >>> Really? It sure seems to be precisely an exception, in that it's an >>> exception to the "normal" flow of control (e.g. return). Just because the >>> type of what's thrown is called "Error" doesn't change the fact that >>> they're conceptually exceptions (as opposed to, say, returning a boolean >>> true/false to indicate an error). >> >> We avoid the word "exception" for Swift's error handling. >> >> The fundamental feature of exception systems is that the call site need not >> do anything. If the call site does nothing, the exception automatically >> unwinds past it. There is no syntactic difference between a call site that >> may throw and a call site that will never throw. >> >> Swift's error handling is different: the possibility of error is explicit at >> the call site. Some people think this is better (no invisible execution >> paths) and some people think it is worse (too noisy). Either way the model >> is different enough that we don't call it exception handling. >> >> The fact that Swift's errors map to Objective-C NSError instead of >> Objective-C exceptions is another reason to avoid "exception". > > Okay, so an Objective-C method that throws an exception...what happens? Swift makes no attempt to interact with C++/ObjC exceptions, so it will not be caught by Swift. Swift's generated code is not exception-safe, but I don't know precisely how unsafe it is. The process might halt in std::terminate() if exception unwinding reaches a Swift frame. Or the unwinding might continue past the Swift frame with no Swift cleanup run (no `defer` execution, no ARC releases, etc). The behavior might be architecture-dependent because different architectures use different exception machinery on Apple's platforms. > Also, if the method of the call site is marked as "throws," does that mean > the error will propagate out? Nothing you write in Swift will have any effect on C++/ObjC exception unwinding. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: should computed properties be able to throw exceptions?
> On Aug 21, 2015, at 6:15 PM, Rick Mann wrote: > >> On Aug 21, 2015, at 18:13 , Quincey Morris >> wrote: >> >> I’d recommend you try to avoid calling the Swift side “exceptions”. It’s >> error handling, and although it’s not completely unlike exception handling >> in other (non-Obj-C) languages, it’s treacherous to confuse the two when >> dealing with Obj-C. > > Really? It sure seems to be precisely an exception, in that it's an exception > to the "normal" flow of control (e.g. return). Just because the type of > what's thrown is called "Error" doesn't change the fact that they're > conceptually exceptions (as opposed to, say, returning a boolean true/false > to indicate an error). We avoid the word "exception" for Swift's error handling. The fundamental feature of exception systems is that the call site need not do anything. If the call site does nothing, the exception automatically unwinds past it. There is no syntactic difference between a call site that may throw and a call site that will never throw. Swift's error handling is different: the possibility of error is explicit at the call site. Some people think this is better (no invisible execution paths) and some people think it is worse (too noisy). Either way the model is different enough that we don't call it exception handling. The fact that Swift's errors map to Objective-C NSError instead of Objective-C exceptions is another reason to avoid "exception". -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Thread-safe singleton with lazy initialisation
> On Aug 18, 2015, at 9:29 AM, Maxthon Chan wrote: > > Two questions: > > 1) How good will a Mac hold up as a server? I can serve static content from > the CDN I rented but CGIKit code is dynamic stuff. If a Mac and OS X holds > well, I can throw Linux compatibility out of the window and use GCD as I will. > 2) If a Mac does not fare well as a server, I will have to make sure my code > is compatible with GNUstep which is the best Cocoa clone for Linux I have > encountered so far - complete with ARC and Blocks but GCD support on GNUstep > is poor (and CoreFoundation support is spotty) so I have to avoid using GCD > completely and use CoreFoundation only sparsely. Apple's Objective-C runtime provides thread-safety guarantees for +initialize. If you are on some other platform then you should check if that platform provides similar guarantees. dispatch_once() is the best solution on Apple's platforms. If you don't like dispatch_once() then you could use pthread_once(). If you don't like dispatch_once() nor pthread_once() then you can use PTHREAD_MUTEX_INITIALIZER instead of pthread_mutex_init(). That avoids any questions of +initialize thread-safety. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Why is overriding unavailable designated initializer of super required?
> On Aug 10, 2015, at 3:50 PM, Seth Willits wrote: > > Say that I am taking this approach because it'd be impossible for a > YourSubclass instance to call initWithValue: on itself with an acceptable > "default" value; One is required by the client. > > Even though -init is unavailable, it's still actually possible to call > -convenienceInitializer, which will end up calling -[YourSubclass init] and > hitting the abort. That's bad. > > We can reason that by definition, convenienceInitializer must call > SomeSuperclass's designated initializer -init. Since we know that -init > cannot possibly setup a YourSubclass instance correctly, then we shouldn't > allow convenienceInitializer to be called either. So now we'd have to mark > convenienceInitializer as NS_UNAVAILABLE in YourSubclass's interface. > > By declaring: > > @interface YourSubclass > -(id) init NS_UNAVAILABLE; > -(id) convenienceInitializer NS_UNAVAILABLE; > @end > > … this now leaves us correctly unable to call [[YourSubclass alloc] init] or > [[YourSubclass alloc] convenienceInitializer]. > > Which brings me right back to my original question. If neither of those can > be called, then implementations of them in YourSubclass could never be > called. Right? If not, then why does YourSubclass need to provide > implementations? Writing a halting cover for the superclass's designated initializers is a defensive measure. If you miss one of the convenience initializers then getting an immediate crash with a crash log pointing to the initializer is much better than quietly calling the wrong initializers and mysteriously crashing somewhere else later. The compiler's enforcement is for designated initializers because they should be a bottleneck that the compiler can see. Enforcing covers of every superclass convenience initializer would be difficult because it's likely that the compiler can't see them all when compiling your subclass, and would be cumbersome because there are often many more convenience initializers. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Why is overriding unavailable designated initializer of super required?
> On Aug 10, 2015, at 1:27 PM, Seth Willits wrote:
>
>
> I've yet to understand this:
> https://gist.github.com/swillits/3133e114f770947b3cf6
>
>
> If a subclass says that its superclass's designated initializer is
> unavailable (IOW, the subclass's designated initializer must be used), why
> does the compiler produce a warning that the superclass's designated
> initializer must be overridden in the subclass?
>
> If the subclass is going to call super's designated initializer via [super
> init] then this subclass override would never get called anyway...
>
> What am I missing?
Convenience initializers.
Consider: a superclass that implements a designated initializer and a
convenience initializer, and your subclass that introduces a new designated
initializer.
@implementation SomeSuperclass
-(id) init; // designated initializer
-(id) convenienceInitializer {
return [self init];
}
@end
@implementation YourSubclass : SomeSuperclass
-(id) initWithValue:(id)value { // designated initializer
return [super init];
}
@end
Now somebody writes this:
id obj = [YourSubclass convenienceInitializer];
This object will not be correctly initialized. It will never call
-initWithValue which is required to initialize YourSubclass properly.
The solution is for the subclass to cover all of its superclass's designated
initializers. You can implement it to call your designated initializer with
appropriate default values:
@implementation YourSubclass
...
-(id) init { // cover of superclass's designated initializer
// delegate to our designated initializer
return [self initWithValue:nil];
}
@end
or you can implement it to fail at runtime:
@interface YourSubclass
-(id) init NS_UNAVAILABLE;
@end
@implementation YourSubclass
...
-(id) init {
abort(); // or throw or whatever
}
@end
Either approach will pacify the compiler.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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 Manual Memory Management
> On Aug 10, 2015, at 12:12 PM, Dave wrote: > >> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: >> >>> On 10 Aug 2015, at 13:59, Dave wrote: >>> >>> Has anyone come up with a way of having the source code support both ARC >>> and Manual Memory Management without using #IFDEF or #IF ? >>> >>> I’ve never understood why the compiler doesn’t just ignore code like: >>> >>> [super dealloc]; >>> >>> [MyObj release]; >>> >>> If it’s being compiled for ARC, that way both could be compiled with the >>> same source code or is there more to it? >> >> Because then there'd be no point in using ARC. ARC is supposed to take the >> hassle of manual memory management off your hands, and automate it to avoid >> mistakes. It is also less misleading if the retain/release lines aren't in >> your code, compared to having them in there but being no-ops. It also >> inter-operates seamlessly with non-ARC code (as it generates the retains and >> releases for you, it is equivalent to manually managed code to any non-ARC >> caller). > > If it just ignored those constructs, it was be much less confusing, simply > because there would only one set of source code. release or dealloc are not > guaranteed to do what is says on the tin anyway, I mean you can override them > and do whatever you want. I can’t see that ignoring or just having empty > methods under ARC would make it more confusing, especially if the compiler > emitted a warning. One problem is that it is very easy for either the ARC version or the non-ARC version to go unused and become incorrect after subsequent changes. For example, the code might look like it supports non-ARC but the retain/release calls are in fact in the wrong places because the only version that is actually tested is the ARC version. GC tried the approach of ignoring retain/release calls in framework code that need to support both modes. It turned out that keeping a single codebase working both with and without GC was hard. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Can I show different content in different screens? (screensaver)
> On Jul 24, 2015, at 7:19 PM, Roland King wrote:
>
> if let screen = window?.screen
> {
> find(…)
> }
> else
> {
> // handle the lack of a screen gracefully
> }
>
> it’s longer, but it’s clearer and it says I’ve considered what semantically
> it means to have a nil screen.
You may prefer the new `guard let` construct for this pattern.
> PS does anyone know (in swift 2.0) of a way to use the ternery operator with
> let/case so you can initialise a variable without curly braces everywhere, I
> want to write
>
> let myVar = ( let ifNotOptional = something?.something else ) ?
> ifNotOptional.stringName : “No Name”
>
> but can’t find any syntax to do something like that
You can separate the let declaration from the initialization, as long as the
compiler can see that it is assigned exactly once before it is used along all
code paths. The compiler recently became smarter at this analysis so it works
in more cases. (Downside: you must specify the variable's type.)
let myVar: String
if let value = something?.somethingElse {
myVar = value.stringName
} else {
myVar = "No Name"
}
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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 description
> On Jul 11, 2015, at 6:29 PM, Roland King wrote:
>
>>
>> However, Roland got it slightly wrong, according to the documentation. This:
>>
>> print (“\(myObj)”)
>>
>> never uses debugDescription, only description. To use debugDescription (if
>> it exists, or description instead):
>>
>> debugPrint (“\(myObj)”)
>
> Dunno about the documentation - I’m remembering a WWDC video which said one
> falls back to the other. So I tested it in a playground. \(variable) appears
> to do as suggested, uses description if that exists, falls back to
> debugDescription if it doesn’t and prints the class name if neither do.
>
> Surprisingly all debugPrint() does is not, as you might expect, use the
> debugDescription in preference, but just puts quotes around the whole thing
> and still uses description if it exists. That feels wrong.
>
> class IHaveNothing{}
>
> class OnlyDebugPrintable : IHaveNothing, CustomDebugStringConvertible
> {
> var debugDescription : String { return "I am
> CustomDebugStringConvertible" }
> }
>
> class HasTheLot : OnlyDebugPrintable, CustomStringConvertible
> {
> var description : String { return "I have the lot" }
> }
>
>
> let a = IHaveNothing()
> let b = OnlyDebugPrintable()
> let c = HasTheLot()
>
> print( "\(a)” ) // IHaveNothing
> print( "\(b)” ) // I am
> CustomDebugStringConvertible
> print( "\(c)” ) // I have the lot
> debugPrint( "\(a)” ) // “IHaveNothing"
> debugPrint( "\(b)” ) // “I am CustomDebugStringConvertible"
> debugPrint( "\(c)” ) // “I have the lot"
Note that there is a distinction between "print an object" and "perform string
interpolation on an object and print that string".
print(c)// I have the lot
print("\(c)") // I have the lot
debugPrint(c) // I am CustomDebugStringConvertible
debugPrint("\(c)") // "I have the lot"
Note that (1) string interpolation prefers the non-debug description when
available, and (2) debugPrint() of a String prints the quotes but print() of a
String does not.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: Any way to combine for and if-let?
> On Jul 7, 2015, at 5:30 PM, Rick Mann wrote: > > Thanks. I was looking at the Swift reference. The docs seem to be incorrect: > > https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/pattern > > "There are two type-casting patterns, the is pattern and the as pattern. Both > type-casting patterns appear only in switch statement case labels." The power of `case` outside `switch` was increased at some point. It's likely that the documentation has not caught up. You should file a bug report. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Any way to combine for and if-let?
> On Jul 7, 2015, at 4:58 PM, Rick Mann wrote:
>
>> On Jul 7, 2015, at 16:52 , Quincey Morris
>> wrote:
>>
>>> On Jul 7, 2015, at 16:42 , Rick Mann wrote:
>>>
>>> for item in enumerator!
>>
>> Like this:
>>
>>> for case let item? in enumerator!
>>
>> (Yes, it’s stupid.)
>
> Hmm. It doesn't seem to like that: '?' pattern cannot match values of type
> 'Element'. It puts the carat on the '?' of item.
>
> Also, the enumerator is a NSDirectoryEnumerator. It returns AnyObject type,
> so wouldn't there have to be an NSURL cast in there somewhere?
`for case` uses Swift's pattern matching system, as seen in `switch`. Something
like this should work:
for case let item as NSURL in enumerator! {
…
}
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: Loading .dylib problem
> On Jul 1, 2015, at 7:55 PM, Graham Cox wrote: > > Hi all, > > I’m developing an app that includes a .dylib within its own resources. For > convenience I’m locating this in the /Frameworks subdirectory. I added a File > Copy to the Build Phases to copy the library there, and I confirm it’s being > done in both debug and release builds. I also added the > @executable_path/../Frameworks search path in the Runpath Search Paths build > setting. > > This was working fine until just now. Suddenly, it’s throwing a runtime error: > > dyld: Library not loaded: /usr/local/lib/MyLib.dylib > Referenced from: > /Users/grahamcox/Library/Developer/Xcode/DerivedData/Graphplot-bmgxcdcnhapazbfdwmjklsckwjon/Build/Products/Debug/Graphplot.app/Contents/MacOS/Graphplot > Reason: image not found > > This suggests it’s searching in /usr/local/lib/ for the library, not the > /Frameworks relative path. Check the install name of the copy of MyLib.dylib that you are linking against. The location to search for a library is chosen at build time. The linked-to library contains an "install name" which is the location where the library will be found at runtime. The built executable records the install name of everything it links to. The install name of the library is in turn specified when the library itself is built. Run `otool -lv MyLib.dylib` and look for the LC_ID_DYLIB load command to see the library's install name. My guess is that MyLib.dylib has a default install name of /usr/local/lib/MyLib.dylib. If you want to load MyLib.dylib relative to a Runpath Search Path then MyLib.dylib should be built with an install name of "@rpath/MyLib.dylib". Xcode now has built-in support for building and packaging embedded dylibs. You may want to reconfigure your project to use it. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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 2 throws from init()
> On Jul 1, 2015, at 5:39 PM, Rick Mann wrote:
>
>> On Jul 1, 2015, at 17:04 , Greg Parker wrote:
>>
>> Implicitly unwrapped optional is a good solution for this. The source code
>> is no more complicated outside init, and if you get something wrong then you
>> will get a runtime error with a useful message.
>
> All that makes sense, although Jens's answer confuses things a bit
> ("According to Chris Lattner (on the swift-language mailing list) this is a
> known problem in the current compiler and will be fixed.").
I described the current model. We would like to improve that model, but (as
Chris said) we have a lot of competing demands for compiler engineer-hours.
> What's the run-time penalty of using implicitly- or force-unwrapped
> Optionals? Does it do a check for null at each invocation, or does it crash?
A forced unwrap generates code of the form `if x == nil { halt with error
"value is unexpectedly nil" }`. The CPU's branch predictor will make it run
fast, so the biggest cost is the increased code size. (And sometimes an
increased object instance size, in the cases where Optional is bigger than T
alone. For pointer types and some other types the compiler is smart enough to
compact Optional into the same size storage as T.)
An implicitly-unwrapped optional works as if every access were force-unwrapped.
I don't know how well the optimizer can fold redundant nil checks together;
it's likely that there are cases that would be a little bit faster when written
by hand with a single unwrap.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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 2 throws from init()
> On Jul 1, 2015, at 4:49 PM, Rick Mann wrote: > > I'm trying to define a Swift wrapper around CGContext. I want to assert that > a Context object, if successfully initialized, will always have a valid > CGContextRef property. Since at least one of my initializers can fail, I set > it up as "throws". > > After getting the actual init code to compile, I've run into this: "error: > all stored properties of a class instance must be initialized before throwing > from an initializer" > > I would have thought that if init() throws, there are no guarantees about the > state of the object, and thus I would not have to find a way let the > CGContext property be optional. If init() fails, the new object needs to be destroyed cleanly. Swift's strategy for doing this is (1) require the failing initializer to finish initializing all of the fields, then (2) run the ordinary deinit code from that class and any other classes whose init methods have already run. Objective-C's strategy is to (1) run all -dealloc methods, including those from classes whose init methods have not yet run or only partially run, and then (2) cross your fingers really hard. > It seems the only way to handle this is with an Optional (or implicitly > unwrapped Optional) type? Implicitly unwrapped optional is a good solution for this. The source code is no more complicated outside init, and if you get something wrong then you will get a runtime error with a useful message. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
> On Jul 1, 2015, at 8:58 AM, Charles Srstka wrote:
>
>> On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas wrote:
>>
>> Only because you are used to CGRect. QuickDraw used to defined a rect using
>> left, top, right, bottom values.
>
> Actually, it was top, left, bottom, right.
Classic Mac OS was inconsistent. For example, the C struct initializer for Rect
was { top, left, bottom, right }, but the initializer function was
SetRect(&rect, left, top, right, bottom).
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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
> On Jun 29, 2015, at 3:42 PM, Rick Mann wrote: > > Here's an example (and this is what I frequently encounter) where requiring > parameter names adds nothing but clutter: > >let config = WKWebViewConfiguration() >self.webView = WKWebView(frame: self.webViewContainer.frame, > configuration: config); > > Moreover, when you're skimming the code, it looks a bit like the WKWebView > constructor takes four arguments, not two. If you work the way I do, which is > to skim pages of code for shapes (e.g., I know the constructor takes two > parameters, so I can quickly zero in on a thing that looks like a call with a > couple of parameters, delimited by white space, and then look more closely to > see if it's the one I wanted. The extra islands of text from parameter names > throws that off). Perhaps you would prefer a different whitespace convention, one with no spaces around the colon in actual parameters. That's a popular convention in Objective-C. Otherwise there is no difference between Objective-C and Swift here. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Simple Swift question
> On Jun 29, 2015, at 3:18 PM, Rick Mann wrote:
>
> How are you supposed to do simple things like this, succinctly?
>
>let url = NSURL(string: "")
>let req = NSURLRequest(URL: url)
>self.webView.loadRequest(req)
>
> This, obviously, doesn't work, since the results are optionals, and so need
> to be unwrapped. But it gets rapidly ridiculous with a bunch of nested
> if-lets (imagine you had more than just two operations to get from here to
> there). What's the right way to do this?
If you "know" that the call cannot actually fail (for example, NSURL(string:)
with a valid hardcoded URL) then you can simply force-unwrap. If you are wrong
then the program will halt at runtime.
let url = NSURL(string: "")!
If you are using Swift 2.0, you can use the new `guard let` to get optional
checking without the cascade of indentation.
guard let url = NSURL(string: "")
else { /* handle failure and either halt or return */ }
// URL is now in scope and non-optional.
let req = NSURLRequest(URL: url)
> Oh, I think I figured it out. NSURL(string:) is optional, but
> NSURLRequest(URL:) can't. Very unexpected, and the error message I was
> getting did not clue me in.
You can often improve diagnostics by adding the explicit types that you expect
each variable to have. That can help pinpoint the place where your
understanding of the code and the compiler's understanding of the code don't
match.
For example, in your code above, writing `let url: NSURL = …` moves the error
message from the NSURLRequest line to the NSURL line.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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
> On Jun 24, 2015, at 2:09 PM, Rick Mann wrote: > > I'm really liking Swift 2, and after watching some of the WWDC2015 videos on > the subject, I can't wait to use it in a real project. > > But one area where it REALLY bugs me is that external parameter names are > required. I can see their utility, particularly with regard to a set of > default values and being able to specify just the ones you care about (I'm > pretty sure this worked in a quick test I did). > > I'm less convinced that using external parameter names in function calls > improves readability or clarity. > > But I don't understand the need to require the use of external names at the > call site. If there's enough information available to the compiler at the > call site to unambiguously choose a function or method to call, why must I > supply the parameter names? Why not let the caller choose which external > names to specify, and only emit an error when the result is ambiguous? > > It's all complicated by the fact that the first parameter doesn't need to > have an external name, but the rest default to having one, and it's the > function definer who decides if they're required. > > I'm going to write a bug about this, but it seems Swift 2 is more strict than > than Swift 1.2 (as evidenced by the examples in the Language Guide), so I > don't see Apple reversing course on this (even though I think it can be done > with zero impact on existing Swift 2 code). Swift 2 established a single default naming rule for all methods and global functions. Swift 1 had two different rules which was confusing. The naming rule (first parameter un-named, additional parameters named) was chosen because it is the best fit with Cocoa methods and most one-argument functions. Swift's design is that the API author gets to choose what the call site looks like. Allowing the caller to choose whether to specify names or not hurts readability because of the inconsistency. It's bad for different calls to the same method to look too different. If you as the author of a function think that the names are not useful, or conversely think that the first parameter should also be named, then you can write your function that way. Conversely, if you think the caller should be allowed to specify names or not then you can write two overloads, one of which simply calls the other. (I did something like this at one point for CGRect's initializers, allowing any of CGRect(1, 2, 3, 4) or CGRect(x:1, y:2, w:3, h:4) or CGRect(x:1, y:2, width:3, height:4). I don't remember if that arrangement survived.) -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: C Assert in BSD Static Library
> On Jun 23, 2015, at 10:14 AM, Raglan T. Tiger wrote: > > My cocoa app links to a number of C++ BSD Static libraries. These libraries > are built in Release configuration. They have Asset Macros in them. > > The Asserts are fired in the release builds. My Windows programmer tele that > Asserts do not get compiled into release code on windows. > > What are my options / setting for not compiling asserts into release builds? First question: how are the asserts spelled? Different assert calls have different configuration. For example, the switch to disable assert() has no effect on NSAssert(). > Are these set in the Library project or the App project that links to them? Assert behavior is usually set when the library is compiled. Sometimes the library will have a runtime variable that affects assert behavior. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Trouble With NSURLSession...
> On Jun 16, 2015, at 7:45 PM, Peters, Brandon wrote:
>
> Here is the exact compiler message:
>
> swift:20:26: Cannot find an initializer for type 'NSURLSession' that accepts
> an argument list of type '(configuration: NSURLSessionConfiguration,
> delegate: HSNDataManager.Type, delegateQueue: nil)'
>
> Hello,
>
> I am creating a class to handle downloading my app’s data. I am using Xcode
> with iOS 8.4 SDK and I keep getting from the compiler that there is no
> initializer for NSURLSession that accepts the list of arguments I am using:
>
>
> import UIKit
>
> class HSNDataManager: NSObject, NSURLSessionDelegate,
> NSURLSessionTaskDelegate,
> NSURLSessionDownloadDelegate {
>
> static let dataManager = HSNDataManager()
>
> class func getRemoteData() {
> // url session configuration
> let urlSessionConfiguration =
> NSURLSessionConfiguration.defaultSessionConfiguration()
> // create url session for downloading our sites database file
> var urlSession = NSURLSession(configuration: urlSessionConfiguration,
> delegate: self, delegateQueue: nil)
You're inside a class func. `self` is the class object for class
HSNDataManager. That class object is not a valid delegate. Presumably you need
to pass an instance of HSNDataManager as the delegate object.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: Wanted: Elegant way to manage this task
> On Jun 8, 2015, at 11:47 PM, Roland King wrote: > > Without answering 98.7% of your question, or more. Are you wedded to NSData > for this? I have a stream processor, it takes randomly chunked up data from a > bluetooth dongle and .. processes it. I used dispatch_data_t for it. That was > introduced back with GCD a few years ago. It’s proved very good for this kind > of data manipulation. You can append them to each other, split them into > pieces, iterate over them but under the hood all the while it keeps the > original chunks of data and avoids a lot of copying around. Only if you at > some point want N contiguous bytes out of the thing to process as a byte > array will it do a copy if necessary into one single memory chunk, if the > piece you want is already in one chunk, it just returns it to you. I’ve found > it a good way to deal with buffers of bytes very efficiently and quite > intuitively. Note that a dispatch_data_t can be used as an NSData object (but not vice versa) as of iOS 7 and OS X 10.9. That means you can use dispatch_data_t to collect chunks as they arrive, then pass the result to a consumer that wants NSData. If all goes well you'll get NSData compatibility with zero or one extra copies. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: why is this Swift initializer legal
> On Jun 6, 2015, at 2:43 AM, Roland King wrote:
>
>
>
> public class RDKBLEService : NSObject
> {
> let peripheral : CBPeripheral
>
> public init( peripheral: CBPeripheral )
> {
> self.peripheral = peripheral
> }
> }
>
> It’s a designated initialiser, there’s a superclass (NSObject) but the
> initialiser doesn’t call a designated initialiser of the superclass.
> According to the rules I was just re-re-re-reading about Swift
> initialisation, it’s required to call a superclass designated initialiser
> from your derived class. I was looking to see if I could find an exception to
> the rule which this fell under but can’t.
There is an exception in the designated initializer rule: if your superclass is
NSObject then you may omit the call to -[NSObject init]. The compiler knows
that -[NSObject init] does nothing, so it allows this as a performance
optimization.
NSObject Class Reference:
"The init method defined in the NSObject class does no initialization; it
simply returns self."
There is lots of existing code that would break if we changed that, so we can't
even if we wanted to.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: What is overwriting 'isa' with 0xbaddc0dedeadbead ?
On May 23, 2015, at 4:54 PM, Ken Thomases wrote: > > On May 23, 2015, at 12:54 PM, Jens Alfke wrote: > >> On May 23, 2015, at 9:20 AM, Greg Parker wrote: >>> >>> free() does that sometimes. If zombies doesn't find anything then try guard >>> malloc. >> >> Good suggestion! I’d forgotten about guard malloc. This changes the crash; >> now the parameter to objc_release points to unmapped memory, implying that >> the object has been dealloced: >> >> (lldb) p/x $rdi >> (unsigned long) $2 = 0x61000d5a3fd0 >> (lldb) x $rdi >> error: memory read failed for 0x61000d5a3e00 >> >> Still no clue what object this is/was, though. And it seems weird that it >> got freed instead of turned into a zombie, since I still have zombies >> enabled too. > > Set the environment variable MallocStackLoggingNoCompact=1 before running the > app. When it crashes, use the malloc_history tool to see the allocation > history of the object address. (gdb had an "info malloc-history" command. > According to <http://lldb.llvm.org/lldb-gdb.html>, the equivalent for lldb is > "command script import lldb.macosx.heap" once to introduce the command and > then "malloc_info --stack-history ".) You can also use the Allocations instrument to record and display allocation and retain/release history of individual objects. It should work fine alongside Guard Malloc. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: What is overwriting 'isa' with 0xbaddc0dedeadbead ?
> On May 23, 2015, at 6:26 PM, Jens Alfke wrote: > >> On May 23, 2015, at 3:31 PM, Jens Alfke > <mailto:j...@mooseyard.com>> wrote: >> >> I’m not sure I can simplify this into a test case, but I’ll try. > > FYI, I’ve boiled it down into a small test case and submitted it as > rdar://21090194 . I’ve also found some workarounds, so I can > get on with my life now… Thanks for the bug report. If your workarounds look relevant to the bug then please describe them there. If the behavior differs or does not differ in debug vs release builds please mention that too. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler ___ 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: What is overwriting 'isa' with 0xbaddc0dedeadbead ?
> On May 22, 2015, at 6:42 PM, Jens Alfke wrote: > > I’m trying to debug a mysterious crash in a Swift init method. At the end of > the method there are some calls to objc_release generated by the compiler, > and it’s the first of these that crashes: the object being released has has > its ‘isa’ pointer replaced by the value 0xbaddc0dedeadbead. This is obviously > a magic value that someone put there to indicate the pointer isn’t valid, but > I’ve never seen that particular value before. I’m guessing that it’s > something to do with the Swift runtime. > > I’ve turned on NSZombieEnabled but it doesn’t make a difference. And the > object address doesn’t correspond to any parameter of the init method, nor is > it the receiver (the class inherits from NSObject.) The crash is also not > consistent; sometimes it doesn’t happen. I’m drawing a blank. Does anyone > know what this means? > > (Oh, and this is in a 64-bit Mac OS X process. It’s a small all-Swift app I > just started writing this week, which used to work until an hour ago, so I > don’t think there’s any mysterious memory corruption involved.) free() does that sometimes. If zombies doesn't find anything then try guard malloc. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: static analyzers says I'm leaking, I _think_ I'm not
> On May 6, 2015, at 2:17 PM, Michael David Crawford > wrote: > > This is 6.2. I speculated a different diagnostic was a bug; were it > correct, I would have seen that same diagnostic on some other code. > > I'll file a radar with a minimal test case if you'd like me to. > > I'll download 6.3.1 right now. Try Xcode 6.3.1 first. If that still fails then please file a bug report with a sample project that demonstrates the failure. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: static analyzers says I'm leaking, I _think_ I'm not
> On May 6, 2015, at 1:57 PM, Michael David Crawford > wrote: > > // LifeGrid.h > @property (assign, nonatomic) GridCycler *cycler; > > // Lifegrid.m - init > self.cycler = [[GridCycler alloc] initWithGrid: self]; // Potential > leak of an object > if ( nil == self.cycler ) goto cycler_failed; > > // dealloc > [self.cycler release]; > > Expanding the "potential leak" message yields: > > 1. assuming 'self' is not nil > > 2. method returns Objective-C object with +1 retain count > > 3. Object leaked: allocated object is not references later in this > execution path and has a retain count of +1. > > Isn't that what I want? I should be taking ownership of it with > "alloc/initWithGrid". > > (initWithGrid doesn't do a cyclic retain.) Which version of Xcode are you using? The static analyzer in Xcode 6.3 has several bugs in retain count analysis and not all of them are fixed in Xcode 6.3.1. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Making an array property without a backing store. How?
> On Apr 6, 2015, at 7:01 PM, Daryle Walker wrote: > > I have an object like: > > @interface MyClass : NSObject > @property (readonly) NSArray * myDatumList; > @property NSArray * myDataList; > @end > > The second member is meant to be an actual data member, an array of mutable > dictionaries. The first member isn’t supposed to have a backing store; > accessing a member of the first array references the corresponding member of > the second, then access a dictionary attribute with a custom key. > > I have a custom array count and array element read methods for the first > member. > > The program does nothing now. I checked with my limited debugging skills that > the second member has one element, but the first member is looped though as > if it has no elements. I see that BOTH “_myDatumList” and “_myDataList” > internal members exist, with the former set as NIL. I’ve heard that we used > to need to use the “@synthesize” command to create internal members, then a > later version of the Objective-C compiler did it automatically. Now I have > the reverse problem; the first member gets a backing store automatically, but > I do NOT want that; I always want to use the custom array accessor methods to > simulate “myDatumList” with pieces of “myDataList.” > > So, how can I turn off auto-@synthesize? Using “@dynamic” doesn’t work; it > causes a crash due to a missing [MyClass myDatumList] method. @dynamic turns off automatic property synthesis. The compiler will not create ivar storage nor accessor methods for an @dynamic property. Did you implement the method -[MyClass myDatumList] ? If you don't synthesize the property then you need to write its accessor methods yourself. > I also saw a random page saying that “self.myDatumList” causes this, but > “myDatumList” wouldn’t (like the “self.” gives the unwanted backing store > have priority over the array accessor methods). Is that accurate? `self.property` reads or writes the property via its accessor methods. `ivar` or `self->ivar` accesses an instance variable's storage directly, bypassing any property accessor methods (synthesized or not) that use that storage. If you have a property and an ivar with the same name then `self.property` and `property` will both be legal and will behave differently. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Where is my bicycle?
> On Apr 6, 2015, at 2:20 PM, pscott wrote: > >> On 4/6/2015 12:29 PM, Greg Parker wrote: >> I'm not an expert here, but my understanding is that when Cocoa says >> "character" it usually means "UTF-16 code unit". @"🚲".length == 2, for >> example. Cocoa's string API designed when Unicode was still a true 16-bit >> character set. > > That would be UCS-2 encoding. If the full Unicode character set of 1,112,064 > characters isn't supported it should not be documented as supporting UTF-16. No, it's not UCS-2. The API generally works as if it were manipulating an array of UTF-16 code units. @"🚲" displays correctly; it would not if the system were truly UCS-2. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Where is my bicycle?
> On Apr 6, 2015, at 11:15 AM, Gerriet M. Denkmann wrote: > > 2. characterSetWithCharactersInString seems to take only the lower 16 bits of > the code points in the string. Bug. > Works ok though, if all chars in the string have code points ≥ 0x1 (e.g. > "𝄞🚲") The implementation of +characterSetWithCharactersInString: does attempt to handle arbitrary code points. It tries to optimize strings that have no "large" code points; my guess is that it has a bug when the string has a mix of both. Please file a bug report. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Where is my bicycle?
> On Apr 6, 2015, at 10:15 AM, Quincey Morris > wrote: > >> On Apr 6, 2015, at 09:19 , Gerriet M. Denkmann wrote: >> >> Where is my bicycle gone? What am I doing wrong? > > The problem is that it’s unclear whether the “characters” in NSCharacterSet > are internally UTF-16 code units, UTF-32 code units, Unicode code points, or > something else. According to the NSCharacterSet documentation: I'm not an expert here, but my understanding is that when Cocoa says "character" it usually means "UTF-16 code unit". @"🚲".length == 2, for example. Cocoa's string API designed when Unicode was still a true 16-bit character set. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Why is NSString.UTF8String unavailable in Swift?
On Mar 21, 2015, at 8:59 PM, Quincey Morris wrote: > On Mar 21, 2015, at 20:43 , Charles Srstka wrote: >> I’m pretty sure that “real” Swift strings are different from NSStrings at >> runtime. It’s not like NSString/CFString; it has to do an actual conversion, >> and is not toll-free bridged. If you convert between String and NSString a >> lot, it’ll have performance implications (which is why bridging to NSString >> just to get -UTF8String isn’t really a good idea). > > What’s interesting about that is (assuming my playground test is correct) the > native Swift String type only “acquires” cStringUsingEncoding when Cocoa is > imported. > > That means either: > > a. The native class actually has that method, but doesn’t expose it to the > world without “import Cocoa”, OR > > b. The native class must implement some kind of selector forwarding that > translates that method into a message to a real NSString conversion of the > String instance, or some such roundabout thing. > > Option (a) seems strange, but option (b) seems even stranger. c. None of the above. When you `import Cocoa` in Swift code you get some Swift additions as well as Cocoa's Objective-C declarations. Most of NSString's methods are re-implemented in a Swift extension on class String. You get this extension when you `import Cocoa`. UTF8String was deliberately omitted from the extension on class String because String already has a `utf8` property. If you think String.UTF8String should be supported then you should file a bug report. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Official or correct explanation of numbers on the 1st column for every method/function call in process sample?
> On Mar 17, 2015, at 1:52 PM, JongAm Park wrote: > > Hello, > > I know that questions on tools are not relevant for this cocoa-dev, but I > couldn’t find any relevant mailing list for tools like ‘sample’ or sampling > using Activity Monitor GUI tool. > So, let me ask it here, because all Cocoa programmers use such tools whenever > needed. > > I have a process sample like this. > > Call graph: >1379 Thread_839846: Main Thread DispatchQueue_ >+ 1379 start (in Wirecast) + 52 [0x100a31074] >+ 1379 main (in Wirecast) + 1070 [0x100b3e16a] >+ 1379 eApp::Run(bool, zRecord*) (in libeva.dylib) + 779 > [0x101033225] >+ 1379 eWindowManager_cocoa::MessageLoop() (in libeva.dylib) + 70 > [0x101037932] >+ 1379 -[NSApplication run] (in AppKit) + 594 [0x7fff88cd2593] > > I can guess the number on the 1st (2nd?) on every row after + sign. It should > be number of samples or how long a method/function take. > > According to MAN page for ‘sample’, it samples at every 1 msec. > And > http://stackoverflow.com/questions/10709577/spindump-analysis-instructions > <http://stackoverflow.com/questions/10709577/spindump-analysis-instructions> > says, it’s the number of samples. > > By looking at the numbers on children nodes, I guess so too. But is it > really so? > > If there is a better mailing list for this kind of inquiry, please let me > know. In the trace above, "1379" is the number of samples at that location. The total number of samples and the sampling rate should be listed at the top of the report: Duration:10.01s Steps: 1001 (10ms sampling interval) Everything else is a description of the instruction's location. (in ) + []. A symbolicated trace may add source file and line numbers. If multiple samples hit the same symbol at different offsets (i.e. they were at different places in the same function) then they may be aggregated into a single line with multiple offsets listed. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Finding the use of a private API
> On Mar 16, 2015, at 7:33 PM, Rick Mann wrote: > > Sure would be nice if Xcode would just tell me where that symbol is > referenced when app validation fails. ;-) You should file a feature request (a.k.a. bug report). That sounds like a fairly straightforward thing for Xcode to do to improve the store deployment experience. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Finding the use of a private API
> On Mar 16, 2015, at 4:47 PM, Rick Mann wrote: > >> otool -t -V APP > /tmp/longFileOfDisassembly >> >> vi the file and look for _dsyrk_ instances, they should be in comments like >> ## symbol stub for _dsyrk_ >> >> scan backwards to find what routine you’re in, should be a couple of >> screenfuls up at most. >> >> Obviously better using a debug version of the code :) > > I tried that. I get this: > > $ otool -tV MyApp | edit > otool(49911,0x7fff7f1cd300) malloc: *** error for object 0x6b2db0: pointer > being freed was not allocated > *** set a breakpoint in malloc_error_break to debug Are your command-line tools out of date with respect to your installed Xcode? Try using `xcrun otool` and similar for the other command-line tools you run. > But it does generate a couple million lines of output before crashing. I can > find only one reference: > > 00175308 f3c4e972blx 0x5395f0 @ symbol stub for: _dsyrk_ > > But nothing more. There doesn't seem to be any debug info (despite this being > a debug build; the dSYM is separate, dunno how to incorporate that). That is a call site. Look upwards in the disassembly for the nearest preceding symbol. If you are lucky then that symbol will be a useful one. If you are unlucky then that symbol will be a red herring because the real symbol was stripped. otool will not read the matching dSYM file, but lldb will. Try this: 1. Place your app and your dSYM in the same directory 2. `xcrun dwarfdump -u /path/to/YourApp.app/YourApp` and `xcrun dwarfdump -u /path/to/YourApp.app.dSYM`. This will print UUIDs. Make sure the app and the dSYM match. 3. `xcrun lldb -arch arm64 /path/to/YourApp.app`. If your app is 32-bit then use `-arch armv7s` instead. 4. In lldb, `image list YourApp`. That should print YourApp's executable and its dSYM file. 5. In lldb, `x/i 0x00175308`. That should print the branch instruction that you found using otool. 6. In lldb, `image lookup -v -a 0x00175308`. That will print everything lldb knows about that address and the function it is in. If all has gone well then that will include function names, file names and line numbers, and any inlining involved. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Finding the use of a private API
> On Mar 16, 2015, at 3:26 PM, Rick Mann wrote: > > After eight or nine successful submissions of our app, we're now getting > rejected for using the "private" API "dsyrk_" (which is part of the > publicly-avialable BLAS). Our app uses Ceres and some other numerical > libraries. We've identified every potential use of this symbol and adjusted > the build to exclude it, but my binary still seems to reference it. If you think the function is mis-labeled as private then you should push back. False positives do exist. (I don't know whether that is done through the review process or through DTS.) -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: iOS App trust on first launch
> On Mar 2, 2015, at 12:34 AM, Rick Mann wrote: > > Xcode should handle this for me, in some way. I should be able to bless my > phone to accept apps from my Xcode. Did you file a bug report? -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: Converting from scalar to NSNumber*
> On Feb 27, 2015, at 4:46 PM, Rick Mann wrote:
>
>
>> On Feb 27, 2015, at 16:45 , Greg Parker wrote:
>>
>>
>>> On Feb 27, 2015, at 4:28 PM, Rick Mann wrote:
>>>
>>> I'm updating some older Core Data code in which I made liberal use of
>>> transient properties to map NSNumber* types to scalar types like uint32_t.
>>> In practice, this doesn't gain much, especially with boxing syntax, and it
>>> makes the Core Data classes messier (shadow attributes, etc.).
>>>
>>> The problem is, if I change an attribute's type to NSNumber*, and fail to
>>> modify every reference to that attribute, I often end up comparing
>>> pointers, not values:
>>>
>>> @property (strong) NSNumber* someAttribute;
>>>
>>> if (obj.someAttribute > 42)
>>>
>>> which needs to become:
>>>
>>> if (obj.someAttribute.integerValue > 42)
>>>
>>> I'd love an explicit warning for misuse of NSNumber*, but a pointer-integer
>>> comparison warning would be helpful. However, I don't see that among the
>>> available warnings in Xcode.
>>
>> Here's how to answer "is there a warning for X".
>> 1. Write a test file with the line of code that you want to be warned about.
>> 2. Compile that file with -Weverything which enables literally every warning
>> supported by the compiler.
>> 3. If the compiler warns about the code then the diagnostic message will
>> print the name of the warning flag, if any. Example:
>> test.m:13:1: warning: control reaches end of non-void function
>> [-Wreturn-type]
>> If it doesn't print a warning name then that warning is on all the time, I
>> think.
>>
>> When I run a test of your code, I get a warning unconditionally. It's
>> possible that my compiler is newer than yours; in your compiler there might
>> be no warning, or there might be a warning behind some warning flag. Try it
>> yourself.
>>
>> test.m:12:13: warning: ordered comparison between pointer and integer
>> ('NSNumber *' and 'int')
>> if (t.x > 42) printf("bigger");
>> ~~~ ^ ~~
>
> Great suggestion. Some versions of GCC will also tell you the command-line
> option that controls the warning it's emitting. I wish clang did that.
Er, that's exactly what Clang does, when there is a command-line option.
Example:
test.m:13:1: warning: control reaches end of non-void function [-Wreturn-type]
Some of clang's warnings have no command-line option. Ordered comparison
between pointer and integer appears to be one of them, at least in my version
of the compiler.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: Converting from scalar to NSNumber*
> On Feb 27, 2015, at 4:28 PM, Rick Mann wrote:
>
> I'm updating some older Core Data code in which I made liberal use of
> transient properties to map NSNumber* types to scalar types like uint32_t. In
> practice, this doesn't gain much, especially with boxing syntax, and it makes
> the Core Data classes messier (shadow attributes, etc.).
>
> The problem is, if I change an attribute's type to NSNumber*, and fail to
> modify every reference to that attribute, I often end up comparing pointers,
> not values:
>
>@property (strong) NSNumber* someAttribute;
>
>if (obj.someAttribute > 42)
>
> which needs to become:
>
>if (obj.someAttribute.integerValue > 42)
>
> I'd love an explicit warning for misuse of NSNumber*, but a pointer-integer
> comparison warning would be helpful. However, I don't see that among the
> available warnings in Xcode.
Here's how to answer "is there a warning for X".
1. Write a test file with the line of code that you want to be warned about.
2. Compile that file with -Weverything which enables literally every warning
supported by the compiler.
3. If the compiler warns about the code then the diagnostic message will print
the name of the warning flag, if any. Example:
test.m:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
If it doesn't print a warning name then that warning is on all the time, I
think.
When I run a test of your code, I get a warning unconditionally. It's possible
that my compiler is newer than yours; in your compiler there might be no
warning, or there might be a warning behind some warning flag. Try it yourself.
test.m:12:13: warning: ordered comparison between pointer and integer
('NSNumber *' and 'int')
if (t.x > 42) printf("bigger");
~~~ ^ ~~
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
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: CGFloat and NS_BUILD_32_LIKE_64
> On Feb 27, 2015, at 4:14 PM, Rick Mann wrote: > > I thought setting NS_BUILD_32_LIKE_64 = 1 would make CGFloat be double, but > CGFloat seems to be conditionalized on __LP64__ (at least, on iOS. > > I'm building iOS for both 32 and 64 bit devices. What should I do here? I'm > trying to get rid of a bunch of implicit conversion warnings. Thanks. NS_BUILD_32_LIKE_64 can't do that. `float` and `double` have different sizes on all architectures. If NS_BUILD_32_LIKE_64 redefined CGFloat then it would break things like struct CGRect. NS_BUILD_32_LIKE_64 does only one thing: it changes NSInteger from `long` to `int` and NSUInteger from `unsigned long` to `unsigned int`. That has no effect on storage size on 32-bit; it only changes things like C++ overloading and Objective-C @encode strings that most code won't notice. https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Cocoa64BitGuide/64BitChangesCocoa/64BitChangesCocoa.html#//apple_ref/doc/uid/TP40004247-CH4-SW2 -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: BOOL attribute types.
> On Feb 16, 2015, at 1:06 PM, Alex Zavatone wrote: > > Xcode 5.1.1 > IOS 7.x > > I'm messing with an auto description category for NSObjects with the interest > of dumping out a class's properties in the format of property name, property > class and string equivalent of property value. > > I'm also considering supporting scalar primitive types that are not > NSObjects, such as CGRects, BOOLs and so on. > > In doing this, I'm checking the property's attributes with > property_getAttributes(). > > What is confusing here is that for properties that are declared as a non > atomic BOOL, the attributes are Tc,N,V, where c codes for a char, according > to the docs, according to the Runtime Property Attribute Description Examples. > > A char declared as a property returns exactly the same attributes as a BOOL > with property_getAttributes(). > > But for an NSString, property_getAttributes()returns "T@"NSString",&,N > > It's easy to detect the NSString properties, but why isn't BOOL included in a > BOOL's property attributes? Is a BOOL just a char (that's what this is > telling me)? What is going on under the hood here. How can I properly > identify a BOOL and tell the difference between a BOOL and a char if they are > represented the same way? You can't. 64-bit iOS: typedef bool BOOL; Everything else: typedef signed char BOOL; If you have sufficient control over the property names, you might be able to assume that a property typed "c" named "foo" with a getter named "isFoo" is a BOOL property. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
