Re: Another Xcode update, another failure to build.

[sqwarqDev]

> On 13 Aug 2015, at 11:37, Graham Cox  wrote:
> But the linker fails to find the framework:
> 
> ld: warning: directory not found for option 
> '-F"/Users/grahamcox/Projects/Mapdiva 
> Projects/Artboard/../../Library/Developer/Xcode/DerivedData/Drawkit-gzweppsofrkdiyasaleyeleblyor/Build/Products/Debug”'

This may be voodoo magic or just good luck, but…

I was having the same problem a couple of weeks back after reverting to an 
earlier version of the Sparkle framework to one I’d previously embedded. I 
cleaned out the original, embedded the regression and thought I’d be away. 
Alas, Xcode kept looking for it. Cleaning out the DerivedData’s didn’t help. 
Something kept telling it to go looking in that DerivedData folder on every 
clean build. 

I eventually hit on the theory that there must be a property list somewhere 
telling Xcode where to look. Perhaps deleting my app’s plist and restarting 
would have worked, but I eventually did all the clean outs in Xcode, including 
deleting the framework, linker paths, clean builds etc,  and then in Terminal 
did

defaults delete -app AppName

(note: AppName is case-sensitive, but is not the bundle identifier. e.g.. 
defaults delete -app TextEdit will do it.)

After that I re-added the framework and the linker path etc and the problem was 
solved. 

Note of caution: also check in the Finder that your framework is not lurking 
about in more than one place in your project’s root or anywhere else. After I 
did the above, I started having similar problems to those Alex was reporting 
last week with Xcode and source control (i.e. Xcode wouldn’t let me commit, but 
kept telling me there were commits to be had), which were down to a forgotten 
copy of the Sparkle framework that didn’t show up in Xcode’s project navigator, 
but was still stuck in my project’s root folder.


Best


Phil


BatteryAlert - keep track of your Magic Mouse, Keyboard and Trackpad. More info 
on sqwarq.com/batteryalert
OSXClock - big, beautiful alarm clock and timer for your mac. More info on 
sqwarq.com/osxclock

http://applehelpwriter.com
http://sqwarq.com - apps for OS X & iOS












___

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: Mavericks vs Yosemite line spacing

[Mike Abdullah]

Control of vertical alignment is something Cocoa devs have wanted for years. 
Usually what you end up doing is subclassing NSTextFieldCell to customise the 
layout/drawing, such that text appears at the desired point.

> On 13 Aug 2015, at 00:56, Trygve Inda  wrote:
> 
> I have an NSTextField that is static and has multiple lines. Because of the
> different font used in Yosemite, the line spacing is thicker and when
> running on Yosemite, it requires more vertical space.
> 
> Is there a way to align the text to the bottom of the content box, rather
> than the top? Horizontal justification is easy, but I don't see a way to
> force it to be bottom-aligned.
> 
> Thanks,
> 
> Trygve
> 
> 
> 
> ___
> 
> 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/mabdullah%40karelia.com
> 
> This email sent to mabdul...@karelia.com


___

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

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

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

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

What version of OpenGL bundled in El Capitan?

[Laurent Daudelin]

I've been googling all over the place. The only references I find are the
ones that say Metal is going to replace OpenGL. But I know that OpenGL is
still bundled. I haven't got around to install El Capitan on my system (I
only have one and I use it for production, having been burnt in the past, I
prefer to wait a bit).

So, anybody running El Capitan can check to see which OpenGL version is
bundled at this time?

Thanks in advance!

-Laurent.
-- 
Laurent Daudelin laur...@nemesys-soft.com
AIM/iChat/Skype:*LaurentDaudelin*  http://www.nemesys-soft.com/
Logiciels Nemesys Software
___

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: Initialisation pattern

[Seth Willits]

> On Aug 12, 2015, at 8:07 PM, André Francisco  
> wrote:
> 
> Hi all,
> I've been reading about object initialisation in Objective-c, as well as the 
> recent additions of NS_UNAVAILABLE and NS_DESIGNATED_INITIALIZER. It's been 
> confusing what the correct approach would be, mostly due to limitations 
> imposed by the compiler. My main goal is obviously to ensure proper object 
> initialisation, both when an object is directly instantiated and when a 
> constructor call is propagated by a child subclass.
> It's noticeable that my background comes mostly from C++ and Java, both 
> languages in which constructors are not inherited by child classes, unlike 
> Objective-c. I can't make sense out of constructor inheritance, to be honest. 
> The fact that a constructor makes sense in a given class does not mean it 
> will to its children. -init is a great example of this if a given class has 
> mandatory parameters with no default values.
> Lets analyse some approaches:
> Override the parent constructor and make up some defaults - this is, IMO, the 
> worts approach. It'll force you to come up with defaults even if they are 
> senseless. Callers will have to rely on documentation in order to understand 
> what the defaults are doing, if anything at all. I've read about "set all to 
> zero" approaches but in this case enums come to mind. Obviously not only 
> enums will suffer from this, but setting an enum to zero does not mean that 
> it's an invalid state, quite the contrary. Even so, the instance would still 
> be useful so I really don't see a point.


> ,.. Instead of this approach I'd rather:Always return nil.

If the parent's initializer cannot create a child object correctly, then having 
the child implement it and throw an exception is the right approach. It's a 
programmer error and should be treated as such.

@implementation Child
- (instancetype)initMethodFromParent
{
[self doesNotRecognizeSelector:_cmd];
return nil;
}
@end

And now with NS_UNAVAILABLE, you would mark it as such in the @interface so the 
compiler will enforce it not being called.

@interface Child : Parent
- (instancetype)initMethodFromParent NS_UNAVAILABLE;
@end



> Use NS_UNAVAILABLE on constructors that do not provide required parameters 
> (ie., parameters without defaults). This would be my favourite approach as it 
> is enforced by the compiler if the method is called directly, except that you 
> cannot redefine the method on a subclass. Lets say a given class is 
> implemented and flags -init as NS_UNAVAILABLE, while implementing a second 
> initialiser -initWithParameter:. This is a base class and it doesn't make 
> sense not to provide the given parameter, whatever the reason may be. Some 
> other class, a child of the first, is not implemented which does provide a 
> default parameter - too late, -init is already unavailable.

No, it's fine. Just declare the -init method as NS_DESIGNATED_INITIALIZER in 
the @interface of the child class, and implement it to call -initWithParameter: 
of the parent class.




--
Seth Willits




___

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

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

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

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

Xcode 7b5 Swift Strings

[Rick Mann]

Between b4 and b5, Apple has changed some NSString methods in Swift. I used to 
be able to do this:

let s : String = ...
let s2 = s.stringByExpandingTildeInPath.stringByAppendingPathComponent("foo")

Now I have to write:

let s2 = ((s as NSString).stringByExpandingTildeInPath as 
NSString).stringByAppendingPathComponent("foo")

How is this better? Am I overlooking something else that makes this 
straightforward again (e.g. native String methods that do the same as the 
NSString methods)?

TIA,


-- 
Rick Mann
rm...@latencyzero.com



___

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

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

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

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

Re: Xcode 7b5 Swift Strings

[Quincey Morris]

On Aug 13, 2015, at 12:56 , Rick Mann  wrote:
> 
> Now I have to write:
> 
> let s2 = ((s as NSString).stringByExpandingTildeInPath as 
> NSString).stringByAppendingPathComponent("foo")
> 
> How is this better?

What happened is that the methods in NSPathUtilities.h are no longer available 
to the String type. It’s unknown whether this was an oversight, or if there’s a 
philosophical reason for the change. I guess we’ll find out in the next beta.

In the meantime, casting to NSString is a slight inconvenience, or you can use 
NSURL (though Charles Strska has pointed out that you need to be careful when 
appending a path extension to a NSURL).

___

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

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

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

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

Re: Xcode 7b5 Swift Strings

[Rick Mann]

> On Aug 13, 2015, at 13:08 , Quincey Morris 
>  wrote:
> 
> On Aug 13, 2015, at 12:56 , Rick Mann  wrote:
>> 
>> Now I have to write:
>> 
>> let s2 = ((s as NSString).stringByExpandingTildeInPath as 
>> NSString).stringByAppendingPathComponent("foo")
>> 
>> How is this better?
> 
> What happened is that the methods in NSPathUtilities.h are no longer 
> available to the String type. It’s unknown whether this was an oversight, or 
> if there’s a philosophical reason for the change. I guess we’ll find out in 
> the next beta.
> 
> In the meantime, casting to NSString is a slight inconvenience, or you can 
> use NSURL (though Charles Strska has pointed out that you need to be careful 
> when appending a path extension to a NSURL).

I guess what I was getting at was, perhaps it makes more sense for the NSString 
extension methods to return NSString, rather than String.

-- 
Rick Mann
rm...@latencyzero.com



___

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

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

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

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

RE: Initialisation pattern

[André Francisco]

I only got Seth's email on the digest, not really sure why. Anyway, I copy 
pasted his response below.@Seth, thank for your answer. That's exactly what 
I've been doing all along, I didn't mention it because that's precisely what 
I'm trying to change. The problem is that it's not fine, I just tested 
it:@interface Parent- (instancetype)init NS_UNAVAILABLE;@end@interface Child- 
(instancetype)init NS_DESIGNATED_INITIALIZER;@endThis results in "init is 
unavailable" being issued by the compiler when instantiating Child. I'm using 
xcode 6.3.2, does your version differ?
> On Aug 12, 2015, at 8:07 PM, André Francisco  
> wrote:
> 
> Hi all,
> I've been reading about object initialisation in Objective-c, as well as the 
> recent additions of NS_UNAVAILABLE and NS_DESIGNATED_INITIALIZER. It's been 
> confusing what the correct approach would be, mostly due to limitations 
> imposed by the compiler. My main goal is obviously to ensure proper object 
> initialisation, both when an object is directly instantiated and when a 
> constructor call is propagated by a child subclass.
> It's noticeable that my background comes mostly from C++ and Java, both 
> languages in which constructors are not inherited by child classes, unlike 
> Objective-c. I can't make sense out of constructor inheritance, to be honest. 
> The fact that a constructor makes sense in a given class does not mean it 
> will to its children. -init is a great example of this if a given class has 
> mandatory parameters with no default values.
> Lets analyse some approaches:
> Override the parent constructor and make up some defaults - this is, IMO, the 
> worts approach. It'll force you to come up with defaults even if they are 
> senseless. Callers will have to rely on documentation in order to understand 
> what the defaults are doing, if anything at all. I've read about "set all to 
> zero" approaches but in this case enums come to mind. Obviously not only 
> enums will suffer from this, but setting an enum to zero does not mean that 
> it's an invalid state, quite the contrary. Even so, the instance would still 
> be useful so I really don't see a point.


> ,.. Instead of this approach I'd rather:Always return nil.

If the parent's initializer cannot create a child object correctly, then having 
the child implement it and throw an exception is the right approach. It's a 
programmer error and should be treated as such.

@implementation Child
- (instancetype)initMethodFromParent
{
[self doesNotRecognizeSelector:_cmd];
return nil;
}
@end

And now with NS_UNAVAILABLE, you would mark it as such in the @interface so the 
compiler will enforce it not being called.

@interface Child : Parent
- (instancetype)initMethodFromParent NS_UNAVAILABLE;
@end



> Use NS_UNAVAILABLE on constructors that do not provide required parameters 
> (ie., parameters without defaults). This would be my favourite approach as it 
> is enforced by the compiler if the method is called directly, except that you 
> cannot redefine the method on a subclass. Lets say a given class is 
> implemented and flags -init as NS_UNAVAILABLE, while implementing a second 
> initialiser -initWithParameter:. This is a base class and it doesn't make 
> sense not to provide the given parameter, whatever the reason may be. Some 
> other class, a child of the first, is not implemented which does provide a 
> default parameter - too late, -init is already unavailable.

No, it's fine. Just declare the -init method as NS_DESIGNATED_INITIALIZER in 
the @interface of the child class, and implement it to call -initWithParameter: 
of the parent class.




--
Seth Willits


From: andre.frate...@hotmail.com
To: cocoa-dev@lists.apple.com
Subject: RE: Initialisation pattern
Date: Thu, 13 Aug 2015 03:48:17 +




I've read that too :) still, the problem sticks. I'm writing a framework, not 
an app, so it's important that callers initialise objects properly. And I wish 
I was using swift, honestly.

Subject: Re: Initialisation pattern
From: j...@mooseyard.com
Date: Wed, 12 Aug 2015 20:22:36 -0700
CC: cocoa-dev@lists.apple.com
To: andre.frate...@hotmail.com


On Aug 12, 2015, at 8:07 PM, André Francisco  
wrote:I've been reading about object initialisation in Objective-c, as well as 
the recent additions of NS_UNAVAILABLE and NS_DESIGNATED_INITIALIZER. It's been 
confusing what the correct approach would be, mostly due to limitations imposed 
by the compiler. My main goal is obviously to ensure proper object 
initialisation, both when an object is directly instantiated and when a 
constructor call is propagated by a child subclass.
Don’t sweat it — you may be overthinking this. In practice it’s not a big 
problem (I’ve only run into issues related to this a few times), and in the 
long run it’s fixed by Swift.
—Jens   
  
___

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

Please do not pos

Swift differences between projects?

[Rick Mann]

I have two projects open in Xcode 7b5. One is mine, which chokes on the latest 
changes around NSString path methods. The file that chokes is from the Swifter 
HTTP server Github project.

The other project is the one that comes with the Swifter project itself. Here's 
the thing: it compiles just fine. It is able to use the NSString path extension 
on String without casting. The same file in my project gets an error.

I can't find any obvious differences.

I'm very confused…

-- 
Rick Mann
rm...@latencyzero.com



___

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

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

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

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

Re: Initialisation pattern

[Seth Willits]

> On Aug 13, 2015, at 1:32 PM, André Francisco  
> wrote:
> 
> I only got Seth's email on the digest, not really sure why. Anyway, I copy 
> pasted his response below.@Seth, thank for your answer. That's exactly what 
> I've been doing all along, I didn't mention it because that's precisely what 
> I'm trying to change. The problem is that it's not fine, I just tested 
> it:@interface Parent- (instancetype)init NS_UNAVAILABLE;@end@interface Child- 
> (instancetype)init NS_DESIGNATED_INITIALIZER;@endThis results in "init is 
> unavailable" being issued by the compiler when instantiating Child. I'm using 
> xcode 6.3.2, does your version differ?


I'm using Xcode 7 (beta 5) which has a newer version of clang in it than you 
have, so it appears this has changed.


--
Seth Willits
___

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

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

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

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

Re: Xcode 7b5 Swift Strings

[Charles Srstka]

> On Aug 13, 2015, at 3:08 PM, Quincey Morris 
>  wrote:
> 
> On Aug 13, 2015, at 12:56 , Rick Mann  > wrote:
>> 
>> Now I have to write:
>> 
>> let s2 = ((s as NSString).stringByExpandingTildeInPath as 
>> NSString).stringByAppendingPathComponent("foo")
>> 
>> How is this better?
> 
> What happened is that the methods in NSPathUtilities.h are no longer 
> available to the String type. It’s unknown whether this was an oversight, or 
> if there’s a philosophical reason for the change. I guess we’ll find out in 
> the next beta.

I think there’s pretty good odds for it being philosophical, since they added a 
whole new warning for it telling you to cast it to NSString.

> In the meantime, casting to NSString is a slight inconvenience, or you can 
> use NSURL (though Charles Strska has pointed out that you need to be careful 
> when appending a path extension to a NSURL).

Hey, I’m famous! But yeah, my guess is that this is intended to coax people who 
are still using string paths to refer to files to quit doing that (although 
there are some times when you’re just dealing with a filename and not a whole 
path, and NSURL won’t do the job, and then there’s really no alternative but 
the ugly cast).

Charles

___

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

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

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

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

Tech update avoiding legacy code

[Appa Rao Mulpuri]

Hi List,

My Mac application starts running from 10.5 onwards. We are planning to adopt 
new technologies like GCD, Storyboards, ARC, Auto Layout and Swift. We have 
benefits to start using like  App performance improvements, reducing memory 
leaks, reduce number of files and code size reduction...etc.

Problem is, we are loosing supported OS stack for each technology if we adopt.

CGD - 10.5 support lost if we start using it.
Auto Layout and Storyboards - We will lost Mac 10.5 and 10.6 support
Swift - App will work from Mac 10.9 onwards. Will lost most of the OS support 
10.5 - 10.8
ARC - We lost Mac 10.5 support. And chance of loosing 10.6 as Weak references 
are not supported in OS X v10.6.

Do we have any way/support to adopt these technologies without loosing my app 
supported OS list?

- Apparao
___

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: Tech update avoiding legacy code

[Jens Alfke]

Do you have a definite business need to keep supporting 10.5? I can’t believe 
you have many customers still running it — it came out in 2007 (the last 
release I worked on at Apple!)

In terms of priorities, I think ARC is the biggest win, followed by GCD. Some 
people might rate auto-layout higher; I might if I did more GUI stuff.

FYI, there’s a 3rd party library that patches in ARC weak-reference support for 
10.6. (I don’t remember what it’s called or where it is, but I’m sure someone 
here does.)

—Jens
___

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

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

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

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

Re: Tech update avoiding legacy code

[Appa Rao Mulpuri]

We have limited people on 10.5, but revenue prospective we couldn¹t ignore
them.

Thanks for the priority order. In GDC Vs ARC, GCD is the first one to opt
unless if you are app has more memory leaks. Correct me If I am wrong.

Not sure, different code base will workout in this case. Implementation
wise can handle better, but App distribution is the problem.

- Apparao

On 8/14/15, 11:31 AM, "Jens Alfke"  wrote:

>Do you have a definite business need to keep supporting 10.5? I can¹t
>believe you have many customers still running it ‹ it came out in 2007
>(the last release I worked on at Apple!)
>
>In terms of priorities, I think ARC is the biggest win, followed by GCD.
>Some people might rate auto-layout higher; I might if I did more GUI
>stuff.
>
>FYI, there¹s a 3rd party library that patches in ARC weak-reference
>support for 10.6. (I don¹t remember what it¹s called or where it is, but
>I¹m sure someone here does.)
>
>‹Jens


___

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

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

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

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