Re: [swift-corelibs-dev] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

Hi David,

> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Hello people,
> 
> I wanted to start giving a hand on corelibs-foundation but hit two obstacles 
> I’d like to discuss:
> 
> It feels difficult to know where help is needed because the ReleaseNotes, 
> Status and Know Issues docs have not been updated in a very long time, as if 
> abandoned. Hopefully we can update hem, but perhaps a rule should be put in 
> place so that no pull request is merged without the corresponding update in 
> the documentation?
> 

Sounds good to me. I don't want to start rejecting PRs because they miss a bit 
of documentation but hopefully we can encourage it or update it after we merge.

> I tried downloading the master branch of corelibs-foundation and running the 
> tests before starting any work, but several of them crashed or failed. I am 
> on OS X, Xcode 7.3.1, up to date on the master branches of 
> corelibs-foundation and corelibs-xctest and am using the latest development 
> snapshot. For reference, the failing tests are:
> 
> TestNSString.test_initializeWithFormat3
> TestNSTask.test_pipe_stderr
> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
> TestNSTask.test_passthrough_environment
> TestNSTask.test_no_environment
> TestNSTask.test_custom_environment
> TestNSUserDefaults.test_createUserDefaults
> TestNSUserDefaults.test_getRegisteredDefaultItem
> TestNSXMLDocument.test_xpath
> 
> Any ideas? Perhaps I’m doing something wrong.

Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
some regressions have snuck in on OS X only (which is interesting if true).

NSTask in particular has been under a lot of changes for Linux recently.

> 
> I was surprised to see fairly little tests for certain classes NSIndexPath, 
> NSUserDefaults, NSScanner. Is that because the code was written before the 
> Open Source project started? What are the rules on test quality and how are 
> they applied?
> 

We’d like to see tests with all new code, for sure. Some of this was written 
fairly quickly in the run up to the launch, so we probably don’t have as many 
tests as we would like there. I do have a task on my plate somewhere to figure 
out how we can integrate more of our internal unit tests into the open source 
project to help with compatibility.

> More generally, I feel worried at how much work is still left, especially 
> with the 3.0 beta branches starting. Am I imagining things or does it not 
> look very good? What can we do to rally the troops?
> 

I totally understand. The Foundation team itself has been focused on the value 
type changes, naming changes, etc that are coming as part of Swift 3. We 
haven’t had nearly as much time as I would have liked to dedicate to bringing 
this project up to parity with Swift 2.2 functionality. We are still hoping to 
accept as many contributions as possible. That is why I went through and 
accepted a bunch of PRs last week.

We have had a few contributions that felt like one-offs; when changes were 
requested we received no response and so I had to close them, which makes me 
pretty sad. I haven’t really seen any true ownership of a particular area. I 
understand it’s asking a lot for someone to come in and help us implement a 
pre-set API, but I believe in a bright future for this project if we can pick 
up the pace a bit.

- Tony

> A well meaning developer,
> David.
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[James Lee via swift-corelibs-dev]

Wanted to chirp up and say I am in the same position as David, with that said, 
if PR's have been rejected due to a lack of response, are there any that have 
not been covered elsewhere and can be picked up?

James

Sent from my iPhone

> On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi David,
> 
>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello people,
>> 
>> I wanted to start giving a hand on corelibs-foundation but hit two obstacles 
>> I’d like to discuss:
>> 
>> It feels difficult to know where help is needed because the ReleaseNotes, 
>> Status and Know Issues docs have not been updated in a very long time, as if 
>> abandoned. Hopefully we can update hem, but perhaps a rule should be put in 
>> place so that no pull request is merged without the corresponding update in 
>> the documentation?
> 
> Sounds good to me. I don't want to start rejecting PRs because they miss a 
> bit of documentation but hopefully we can encourage it or update it after we 
> merge.
> 
>> I tried downloading the master branch of corelibs-foundation and running the 
>> tests before starting any work, but several of them crashed or failed. I am 
>> on OS X, Xcode 7.3.1, up to date on the master branches of 
>> corelibs-foundation and corelibs-xctest and am using the latest development 
>> snapshot. For reference, the failing tests are:
>> 
>> TestNSString.test_initializeWithFormat3
>> TestNSTask.test_pipe_stderr
>> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
>> TestNSTask.test_passthrough_environment
>> TestNSTask.test_no_environment
>> TestNSTask.test_custom_environment
>> TestNSUserDefaults.test_createUserDefaults
>> TestNSUserDefaults.test_getRegisteredDefaultItem
>> TestNSXMLDocument.test_xpath
>> 
>> Any ideas? Perhaps I’m doing something wrong.
> 
> Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
> some regressions have snuck in on OS X only (which is interesting if true).
> 
> NSTask in particular has been under a lot of changes for Linux recently.
> 
>> 
>> I was surprised to see fairly little tests for certain classes NSIndexPath, 
>> NSUserDefaults, NSScanner. Is that because the code was written before the 
>> Open Source project started? What are the rules on test quality and how are 
>> they applied?
> 
> We’d like to see tests with all new code, for sure. Some of this was written 
> fairly quickly in the run up to the launch, so we probably don’t have as many 
> tests as we would like there. I do have a task on my plate somewhere to 
> figure out how we can integrate more of our internal unit tests into the open 
> source project to help with compatibility.
> 
>> More generally, I feel worried at how much work is still left, especially 
>> with the 3.0 beta branches starting. Am I imagining things or does it not 
>> look very good? What can we do to rally the troops?
> 
> I totally understand. The Foundation team itself has been focused on the 
> value type changes, naming changes, etc that are coming as part of Swift 3. 
> We haven’t had nearly as much time as I would have liked to dedicate to 
> bringing this project up to parity with Swift 2.2 functionality. We are still 
> hoping to accept as many contributions as possible. That is why I went 
> through and accepted a bunch of PRs last week.
> 
> We have had a few contributions that felt like one-offs; when changes were 
> requested we received no response and so I had to close them, which makes me 
> pretty sad. I haven’t really seen any true ownership of a particular area. I 
> understand it’s asking a lot for someone to come in and help us implement a 
> pre-set API, but I believe in a bright future for this project if we can pick 
> up the pace a bit.
> 
> - Tony
> 
>> A well meaning developer,
>> David.
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

I did this search to try and find some:

https://github.com/apple/swift-corelibs-foundation/pulls?utf8=✓&q=is%3Apr+is%3Aclosed+is%3Aunmerged
 


Here’s one:

https://github.com/apple/swift-corelibs-foundation/pull/226 


Here was another that we had difficulty getting through review on:

https://github.com/apple/swift-corelibs-foundation/pull/248 


Here is an old one that had some hard to figure out merge conflicts:

https://github.com/apple/swift-corelibs-foundation/pull/225 


There are probably more… 

Some of the root cause has been our own failure in getting these merged 
quickly, which I’m trying to improve on.

- Tony

> On May 13, 2016, at 10:26 AM, James Lee  wrote:
> 
> Wanted to chirp up and say I am in the same position as David, with that 
> said, if PR's have been rejected due to a lack of response, are there any 
> that have not been covered elsewhere and can be picked up?
> 
> James
> 
> Sent from my iPhone
> 
> On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> 
>> Hi David,
>> 
>>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hello people,
>>> 
>>> I wanted to start giving a hand on corelibs-foundation but hit two 
>>> obstacles I’d like to discuss:
>>> 
>>> It feels difficult to know where help is needed because the ReleaseNotes, 
>>> Status and Know Issues docs have not been updated in a very long time, as 
>>> if abandoned. Hopefully we can update hem, but perhaps a rule should be put 
>>> in place so that no pull request is merged without the corresponding update 
>>> in the documentation?
>>> 
>> 
>> Sounds good to me. I don't want to start rejecting PRs because they miss a 
>> bit of documentation but hopefully we can encourage it or update it after we 
>> merge.
>> 
>>> I tried downloading the master branch of corelibs-foundation and running 
>>> the tests before starting any work, but several of them crashed or failed. 
>>> I am on OS X, Xcode 7.3.1, up to date on the master branches of 
>>> corelibs-foundation and corelibs-xctest and am using the latest development 
>>> snapshot. For reference, the failing tests are:
>>> 
>>> TestNSString.test_initializeWithFormat3
>>> TestNSTask.test_pipe_stderr
>>> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
>>> TestNSTask.test_passthrough_environment
>>> TestNSTask.test_no_environment
>>> TestNSTask.test_custom_environment
>>> TestNSUserDefaults.test_createUserDefaults
>>> TestNSUserDefaults.test_getRegisteredDefaultItem
>>> TestNSXMLDocument.test_xpath
>>> 
>>> Any ideas? Perhaps I’m doing something wrong.
>> 
>> Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
>> some regressions have snuck in on OS X only (which is interesting if true).
>> 
>> NSTask in particular has been under a lot of changes for Linux recently.
>> 
>>> 
>>> I was surprised to see fairly little tests for certain classes NSIndexPath, 
>>> NSUserDefaults, NSScanner. Is that because the code was written before the 
>>> Open Source project started? What are the rules on test quality and how are 
>>> they applied?
>>> 
>> 
>> We’d like to see tests with all new code, for sure. Some of this was written 
>> fairly quickly in the run up to the launch, so we probably don’t have as 
>> many tests as we would like there. I do have a task on my plate somewhere to 
>> figure out how we can integrate more of our internal unit tests into the 
>> open source project to help with compatibility.
>> 
>>> More generally, I feel worried at how much work is still left, especially 
>>> with the 3.0 beta branches starting. Am I imagining things or does it not 
>>> look very good? What can we do to rally the troops?
>>> 
>> 
>> I totally understand. The Foundation team itself has been focused on the 
>> value type changes, naming changes, etc that are coming as part of Swift 3. 
>> We haven’t had nearly as much time as I would have liked to dedicate to 
>> bringing this project up to parity with Swift 2.2 functionality. We are 
>> still hoping to accept as many contributions as possible. That is why I went 
>> through and accepted a bunch of PRs last week.
>> 
>> We have had a few contributions that felt like one-offs; when changes were 
>> requested we received no response and so I had to close them, which makes me 
>> pretty sad. I haven’t really seen any true ownership of a particular area. I 
>> understand it’s asking a lot for someone to come in and help us implement a 
>> pre-set API, but I believe in a bright future for this project if we can 
>> pick up the pace a bit.
>> 
>> - Tony
>> 
>>> A well meaning developer,
>>> David.
>>> ___

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[Rob Allen via swift-corelibs-dev]

Hi all,

> On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi David,
> 
>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hello people,
>> 
>> I wanted to start giving a hand on corelibs-foundation but hit two obstacles 
>> I’d like to discuss:

This is good timing as I'm planning on seeing if I can contribute to 
corelibs-foundation on the grounds that it may be at my ability level! 


>> I tried downloading the master branch of corelibs-foundation and running the 
>> tests before starting any work, but several of them crashed or failed. I am 
>> on OS X, Xcode 7.3.1, up to date on the master branches of 
>> corelibs-foundation and corelibs-xctest and am using the latest development 
>> snapshot. For reference, the failing tests are:
>> 
>> TestNSString.test_initializeWithFormat3
>> TestNSTask.test_pipe_stderr
>> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
>> TestNSTask.test_passthrough_environment
>> TestNSTask.test_no_environment
>> TestNSTask.test_custom_environment
>> TestNSUserDefaults.test_createUserDefaults
>> TestNSUserDefaults.test_getRegisteredDefaultItem
>> TestNSXMLDocument.test_xpath
>> 
>> Any ideas? Perhaps I’m doing something wrong.
> 
> Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
> some regressions have snuck in on OS X only (which is interesting if true).
> 
> NSTask in particular has been under a lot of changes for Linux recently.

I've hit this too - I'll try and raise issues over the weekend for them if I 
can. 

My plan is to start by writing unit tests if only get a feel for how all the 
project fits together. Building and testing on Linux is so slow due to the lack 
of incremental builds that starting with OS X seemed logical.  I thought it was 
a problem at my end though when the tests failed on OS X.
 
Is there a reason why corelibs-foundation isn't build for OS X by the CI system?


Regards,

Rob...

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] NSTask and try!

[James Lee via swift-corelibs-dev]

Following on from a previous discussion with Tests failing on OSX. I 
have been looking into the failures. It seems that one of the earliest 
failures is due to an error from a try! within NSTask.launch(). This 
came in with this commit: 
https://github.com/apple/swift-corelibs-foundation/commit/4c6f04cfcad3d4b06688558021595d06751fc66a


Going by the docs for Foundation - The launch function apparently 
"Raises an NSInvalidArgumentException if the launch path has not been 
set or is invalid or if it fails to create a process."


https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTask_Class/#//apple_ref/occ/instm/NSTask/launch

My question is, should this be built into the Swift Foundation API? The 
documentation for Swift doesn't state that the launch function throws.


With the test that is failing expecting an error, it feels more Swift-y 
to have any errors throw explicitly, rather than looking at what the 
lower level fills the data with.


But before jumping into doing this, I would rather put it out there and 
see what the community feels about this?


Cheers

James
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSTask and try!

[Tony Parker via swift-corelibs-dev]

Hi James,

> On May 13, 2016, at 12:25 PM, James Lee via swift-corelibs-dev 
>  wrote:
> 
> Following on from a previous discussion with Tests failing on OSX. I have 
> been looking into the failures. It seems that one of the earliest failures is 
> due to an error from a try! within NSTask.launch(). This came in with this 
> commit: 
> https://github.com/apple/swift-corelibs-foundation/commit/4c6f04cfcad3d4b06688558021595d06751fc66a
> 
> Going by the docs for Foundation - The launch function apparently "Raises an 
> NSInvalidArgumentException if the launch path has not been set or is invalid 
> or if it fails to create a process."
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTask_Class/#//apple_ref/occ/instm/NSTask/launch
> 
> My question is, should this be built into the Swift Foundation API? The 
> documentation for Swift doesn't state that the launch function throws.
> 
> With the test that is failing expecting an error, it feels more Swift-y to 
> have any errors throw explicitly, rather than looking at what the lower level 
> fills the data with.
> 
> But before jumping into doing this, I would rather put it out there and see 
> what the community feels about this?
> 

Unfortunately the ‘throws’ syntax in Swift often causes a mixup between two 
different things, because it flipped the terminology from what all of our 
documentation and header comments use.

1. Cocoa uses exceptions (@throw in ObjC) to indicate programmer errors and 
they are generally not intended to be recoverable.  Example: passing nil where 
not expected, passing an invalid argument, failing to meet a precondition of an 
API.
2. Cocoa uses NSError ** to indicate runtime errors that are recoverable or at 
least presentable to user. Example: out of disk space, name of file already 
exists.

The ‘throws’ syntax in Swift is actually for case #2, not #1. In Swift, #1 is 
fatalError or preconditionFailure. #2 is ‘throw Error’.

In the case of NSTask, when the documentation says “raises an 
NSInvalidArgumentException” (#1) then in Swift, that should translate to 
fatalError or preconditionFailure.

Hope this helps,
- Tony

> Cheers
> 
> James
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

> On May 13, 2016, at 10:33 AM, Rob Allen  wrote:
> 
> Hi all,
> 
>> On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi David,
>> 
>>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hello people,
>>> 
>>> I wanted to start giving a hand on corelibs-foundation but hit two 
>>> obstacles I’d like to discuss:
> 
> This is good timing as I'm planning on seeing if I can contribute to 
> corelibs-foundation on the grounds that it may be at my ability level! 
> 
> 
>>> I tried downloading the master branch of corelibs-foundation and running 
>>> the tests before starting any work, but several of them crashed or failed. 
>>> I am on OS X, Xcode 7.3.1, up to date on the master branches of 
>>> corelibs-foundation and corelibs-xctest and am using the latest development 
>>> snapshot. For reference, the failing tests are:
>>> 
>>> TestNSString.test_initializeWithFormat3
>>> TestNSTask.test_pipe_stderr
>>> TestNSTask.test_pipe_stdout_and_stderr_same_pipe
>>> TestNSTask.test_passthrough_environment
>>> TestNSTask.test_no_environment
>>> TestNSTask.test_custom_environment
>>> TestNSUserDefaults.test_createUserDefaults
>>> TestNSUserDefaults.test_getRegisteredDefaultItem
>>> TestNSXMLDocument.test_xpath
>>> 
>>> Any ideas? Perhaps I’m doing something wrong.
>> 
>> Our CI system only builds and tests corelibs-foundation on Linux, so perhaps 
>> some regressions have snuck in on OS X only (which is interesting if true).
>> 
>> NSTask in particular has been under a lot of changes for Linux recently.
> 
> I've hit this too - I'll try and raise issues over the weekend for them if I 
> can. 
> 
> My plan is to start by writing unit tests if only get a feel for how all the 
> project fits together. Building and testing on Linux is so slow due to the 
> lack of incremental builds that starting with OS X seemed logical.  I thought 
> it was a problem at my end though when the tests failed on OS X.
>  
> Is there a reason why corelibs-foundation isn't build for OS X by the CI 
> system?
> 

Technically, swift-corelibs-foundation is only part of the distribution on 
Linux. On Darwin platforms, we use a combination of the overlay 
(stdlib/public/SDK/Foundation directory in the Swift project) and the 
Foundation.framework that ships on the OS.

However, we want to build and test it on OS X because that’s a much easier 
platform for most of us to deal with on a day-to-day basis.

I think we should consider having the CI build foundation and run its tests on 
OS X, but I’m not sure how to split out that concept from the final package 
that the CI generates. We don’t want to ship swift-corelibs-foundation on OS X 
because then we’d have two separate libraries with the same name and same API…

- Tony

> 
> Regards,
> 
> Rob...
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSTask and try!

[James Lee via swift-corelibs-dev]

Cheers for the clarification. I started assuming there may be a reason when 
changing the guard let on the launch args to use the InvalidArgumentException.

Could this be a position where we may need os checking to cover the regression 
for the moment. It seems odd that the test would pass in CI when an error is 
thrown with a try! but fail on OSX

Sent from my iPhone

> On 13 May 2016, at 20:48, Tony Parker  wrote:
> 
> Hi James,
> 
>> On May 13, 2016, at 12:25 PM, James Lee via swift-corelibs-dev 
>>  wrote:
>> 
>> Following on from a previous discussion with Tests failing on OSX. I have 
>> been looking into the failures. It seems that one of the earliest failures 
>> is due to an error from a try! within NSTask.launch(). This came in with 
>> this commit: 
>> https://github.com/apple/swift-corelibs-foundation/commit/4c6f04cfcad3d4b06688558021595d06751fc66a
>> 
>> Going by the docs for Foundation - The launch function apparently "Raises an 
>> NSInvalidArgumentException if the launch path has not been set or is invalid 
>> or if it fails to create a process."
>> 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTask_Class/#//apple_ref/occ/instm/NSTask/launch
>> 
>> My question is, should this be built into the Swift Foundation API? The 
>> documentation for Swift doesn't state that the launch function throws.
>> 
>> With the test that is failing expecting an error, it feels more Swift-y to 
>> have any errors throw explicitly, rather than looking at what the lower 
>> level fills the data with.
>> 
>> But before jumping into doing this, I would rather put it out there and see 
>> what the community feels about this?
> 
> Unfortunately the ‘throws’ syntax in Swift often causes a mixup between two 
> different things, because it flipped the terminology from what all of our 
> documentation and header comments use.
> 
> 1. Cocoa uses exceptions (@throw in ObjC) to indicate programmer errors and 
> they are generally not intended to be recoverable.  Example: passing nil 
> where not expected, passing an invalid argument, failing to meet a 
> precondition of an API.
> 2. Cocoa uses NSError ** to indicate runtime errors that are recoverable or 
> at least presentable to user. Example: out of disk space, name of file 
> already exists.
> 
> The ‘throws’ syntax in Swift is actually for case #2, not #1. In Swift, #1 is 
> fatalError or preconditionFailure. #2 is ‘throw Error’.
> 
> In the case of NSTask, when the documentation says “raises an 
> NSInvalidArgumentException” (#1) then in Swift, that should translate to 
> fatalError or preconditionFailure.
> 
> Hope this helps,
> - Tony
> 
>> Cheers
>> 
>> James
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSTask and try!

[Tony Parker via swift-corelibs-dev]

> On May 13, 2016, at 1:05 PM, James Lee  wrote:
> 
> Cheers for the clarification. I started assuming there may be a reason when 
> changing the guard let on the launch args to use the InvalidArgumentException.
> 
> Could this be a position where we may need os checking to cover the 
> regression for the moment. It seems odd that the test would pass in CI when 
> an error is thrown with a try! but fail on OSX
> 

Task is certainly one of the cases where the underlying stuff that we’re 
abstracting is significantly different, so I’m not too surprised.

We should try to get something in place so we’re not failing on OS X in the 
short term for sure.

- Tony

> Sent from my iPhone
> 
>> On 13 May 2016, at 20:48, Tony Parker  wrote:
>> 
>> Hi James,
>> 
>>> On May 13, 2016, at 12:25 PM, James Lee via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Following on from a previous discussion with Tests failing on OSX. I have 
>>> been looking into the failures. It seems that one of the earliest failures 
>>> is due to an error from a try! within NSTask.launch(). This came in with 
>>> this commit: 
>>> https://github.com/apple/swift-corelibs-foundation/commit/4c6f04cfcad3d4b06688558021595d06751fc66a
>>> 
>>> Going by the docs for Foundation - The launch function apparently "Raises 
>>> an NSInvalidArgumentException if the launch path has not been set or is 
>>> invalid or if it fails to create a process."
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTask_Class/#//apple_ref/occ/instm/NSTask/launch
>>> 
>>> My question is, should this be built into the Swift Foundation API? The 
>>> documentation for Swift doesn't state that the launch function throws.
>>> 
>>> With the test that is failing expecting an error, it feels more Swift-y to 
>>> have any errors throw explicitly, rather than looking at what the lower 
>>> level fills the data with.
>>> 
>>> But before jumping into doing this, I would rather put it out there and see 
>>> what the community feels about this?
>> 
>> Unfortunately the ‘throws’ syntax in Swift often causes a mixup between two 
>> different things, because it flipped the terminology from what all of our 
>> documentation and header comments use.
>> 
>> 1. Cocoa uses exceptions (@throw in ObjC) to indicate programmer errors and 
>> they are generally not intended to be recoverable.  Example: passing nil 
>> where not expected, passing an invalid argument, failing to meet a 
>> precondition of an API.
>> 2. Cocoa uses NSError ** to indicate runtime errors that are recoverable or 
>> at least presentable to user. Example: out of disk space, name of file 
>> already exists.
>> 
>> The ‘throws’ syntax in Swift is actually for case #2, not #1. In Swift, #1 
>> is fatalError or preconditionFailure. #2 is ‘throw Error’.
>> 
>> In the case of NSTask, when the documentation says “raises an 
>> NSInvalidArgumentException” (#1) then in Swift, that should translate to 
>> fatalError or preconditionFailure.
>> 
>> Hope this helps,
>> - Tony
>> 
>>> Cheers
>>> 
>>> James
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[David Hart via swift-corelibs-dev]

> On 13 May 2016, at 21:50, Tony Parker  wrote:
> 
> Technically, swift-corelibs-foundation is only part of the distribution on 
> Linux. On Darwin platforms, we use a combination of the overlay 
> (stdlib/public/SDK/Foundation directory in the Swift project) and the 
> Foundation.framework that ships on the OS.

I’m confused about swift-corelibs-foundation only being part of the Linux 
distribution. Are you saying that when Swift 3.0 ships, import Foundation on OS 
X and iOS will still import the Objective-C framework? If yes, I’m very 
surprised, and I think many people will be. One of the goals of 
swift-corelibs-foundation (README) says:

• Provide a level of OS independence, to enhance portability.

How can it be portable if different platforms don’t share the same underlying 
core libraries?

David.

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[David Hart via swift-corelibs-dev]

After looking into it, I guess it would be available, but under the 
SwiftFoundation module. Correct? I guess that decision was made so that Swift 
apps in production built on Foundation don’t break when recompiled under Swift 
3? Is it worth converging the names of the module so its the same on all 
platforms? Isn’t it bad if portable code was doomed to have #if os() for all 
Foundation imports? If we do rename it, do we rename it to SwiftFoundation on 
Linux or do we rename it to Foundation on OS X (which would require renaming 
the Objective-C Foundation to something else and write a migration)?

> On 14 May 2016, at 00:19, David Hart via swift-corelibs-dev 
>  wrote:
> 
> 
>> On 13 May 2016, at 21:50, Tony Parker > > wrote:
>> 
>> Technically, swift-corelibs-foundation is only part of the distribution on 
>> Linux. On Darwin platforms, we use a combination of the overlay 
>> (stdlib/public/SDK/Foundation directory in the Swift project) and the 
>> Foundation.framework that ships on the OS.
> 
> I’m confused about swift-corelibs-foundation only being part of the Linux 
> distribution. Are you saying that when Swift 3.0 ships, import Foundation on 
> OS X and iOS will still import the Objective-C framework? If yes, I’m very 
> surprised, and I think many people will be. One of the goals of 
> swift-corelibs-foundation (README) says:
> 
>   • Provide a level of OS independence, to enhance portability.
> 
> How can it be portable if different platforms don’t share the same underlying 
> core libraries?
> 
> David.
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

Hi David,

Much of the implementation is indeed shared (via the CoreFoundation C code, and 
the stuff it uses like ICU and libdispatch). Some of it is a reimplementation 
of the same API, but in Swift.

If you write code targeting the Foundation API, then you simply ‘import 
Foundation’. The idea here is that the implementation abstracts away the 
platform differences including the implementation itself.

- Tony

> On May 13, 2016, at 3:34 PM, David Hart  wrote:
> 
> After looking into it, I guess it would be available, but under the 
> SwiftFoundation module. Correct? I guess that decision was made so that Swift 
> apps in production built on Foundation don’t break when recompiled under 
> Swift 3? Is it worth converging the names of the module so its the same on 
> all platforms? Isn’t it bad if portable code was doomed to have #if os() for 
> all Foundation imports? If we do rename it, do we rename it to 
> SwiftFoundation on Linux or do we rename it to Foundation on OS X (which 
> would require renaming the Objective-C Foundation to something else and write 
> a migration)?
> 
>> On 14 May 2016, at 00:19, David Hart via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> 
>>> On 13 May 2016, at 21:50, Tony Parker >> > wrote:
>>> 
>>> Technically, swift-corelibs-foundation is only part of the distribution on 
>>> Linux. On Darwin platforms, we use a combination of the overlay 
>>> (stdlib/public/SDK/Foundation directory in the Swift project) and the 
>>> Foundation.framework that ships on the OS.
>> 
>> I’m confused about swift-corelibs-foundation only being part of the Linux 
>> distribution. Are you saying that when Swift 3.0 ships, import Foundation on 
>> OS X and iOS will still import the Objective-C framework? If yes, I’m very 
>> surprised, and I think many people will be. One of the goals of 
>> swift-corelibs-foundation (README) says:
>> 
>>  • Provide a level of OS independence, to enhance portability.
>> 
>> How can it be portable if different platforms don’t share the same 
>> underlying core libraries?
>> 
>> David.
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[David Hart via swift-corelibs-dev]

Hi Tony,

I’m a bit confused by your answer. I am aware that some Objective-C Foundation 
and swift-corelibs-foundation classes share a common implementation through CF. 
My questions were really about the place of swift-corelibs-foundation on OS X 
and iOS. Can you help me understand?

What did you mean by "Technically, swift-corelibs-foundation is only part of 
the distribution on Linux.”?
Will swift-corelibs-foundation be part of the canonical Swift distribution on 
OS X and iOS once Swift 3 is released?
What is the name of the swift-corelibs-foundation module on OS X and iOS? 
SwiftFoundation?
What is the name of the swift-corelibs-foundation module on Linux? Foundation?
If those are different, isn’t there an incentive for having the same moule name 
on all platforms?

David.

> On 14 May 2016, at 00:44, Tony Parker  wrote:
> 
> Hi David,
> 
> Much of the implementation is indeed shared (via the CoreFoundation C code, 
> and the stuff it uses like ICU and libdispatch). Some of it is a 
> reimplementation of the same API, but in Swift.
> 
> If you write code targeting the Foundation API, then you simply ‘import 
> Foundation’. The idea here is that the implementation abstracts away the 
> platform differences including the implementation itself.
> 
> - Tony
> 
>> On May 13, 2016, at 3:34 PM, David Hart > > wrote:
>> 
>> After looking into it, I guess it would be available, but under the 
>> SwiftFoundation module. Correct? I guess that decision was made so that 
>> Swift apps in production built on Foundation don’t break when recompiled 
>> under Swift 3? Is it worth converging the names of the module so its the 
>> same on all platforms? Isn’t it bad if portable code was doomed to have #if 
>> os() for all Foundation imports? If we do rename it, do we rename it to 
>> SwiftFoundation on Linux or do we rename it to Foundation on OS X (which 
>> would require renaming the Objective-C Foundation to something else and 
>> write a migration)?
>> 
>>> On 14 May 2016, at 00:19, David Hart via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> 
 On 13 May 2016, at 21:50, Tony Parker >>> > wrote:
 
 Technically, swift-corelibs-foundation is only part of the distribution on 
 Linux. On Darwin platforms, we use a combination of the overlay 
 (stdlib/public/SDK/Foundation directory in the Swift project) and the 
 Foundation.framework that ships on the OS.
>>> 
>>> I’m confused about swift-corelibs-foundation only being part of the Linux 
>>> distribution. Are you saying that when Swift 3.0 ships, import Foundation 
>>> on OS X and iOS will still import the Objective-C framework? If yes, I’m 
>>> very surprised, and I think many people will be. One of the goals of 
>>> swift-corelibs-foundation (README) says:
>>> 
>>> • Provide a level of OS independence, to enhance portability.
>>> 
>>> How can it be portable if different platforms don’t share the same 
>>> underlying core libraries?
>>> 
>>> David.
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> 
>> 
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Looking at corelibs-foundation

[Tony Parker via swift-corelibs-dev]

> On May 13, 2016, at 4:13 PM, David Hart  wrote:
> 
> Hi Tony,
> 
> I’m a bit confused by your answer. I am aware that some Objective-C 
> Foundation and swift-corelibs-foundation classes share a common 
> implementation through CF. My questions were really about the place of 
> swift-corelibs-foundation on OS X and iOS. Can you help me understand?
> 
> What did you mean by "Technically, swift-corelibs-foundation is only part of 
> the distribution on Linux.”?

On Darwin we will use the system framework. It is (clearly) far more mature 
than the swift-corelibs-foundation implementation.

Over time it’s not clear how the two will evolve, but we want them to evolve 
together from an API point of view at least.

> Will swift-corelibs-foundation be part of the canonical Swift distribution on 
> OS X and iOS once Swift 3 is released?

No. Only on Linux or other non-Darwin platforms.

> What is the name of the swift-corelibs-foundation module on OS X and iOS? 
> SwiftFoundation?

SwiftFoundation, and it is named this way specifically to avoid conflict with 
the system Foundation.

> What is the name of the swift-corelibs-foundation module on Linux? Foundation?

Foundation

> If those are different, isn’t there an incentive for having the same moule 
> name on all platforms?
> 
> David.
> 

The system Foundation.framework on Darwin and swift-corelibs-foundation on 
Linux are both called “Foundation”.

Hope that clears this up.

- Tony


>> On 14 May 2016, at 00:44, Tony Parker > > wrote:
>> 
>> Hi David,
>> 
>> Much of the implementation is indeed shared (via the CoreFoundation C code, 
>> and the stuff it uses like ICU and libdispatch). Some of it is a 
>> reimplementation of the same API, but in Swift.
>> 
>> If you write code targeting the Foundation API, then you simply ‘import 
>> Foundation’. The idea here is that the implementation abstracts away the 
>> platform differences including the implementation itself.
>> 
>> - Tony
>> 
>>> On May 13, 2016, at 3:34 PM, David Hart >> > wrote:
>>> 
>>> After looking into it, I guess it would be available, but under the 
>>> SwiftFoundation module. Correct? I guess that decision was made so that 
>>> Swift apps in production built on Foundation don’t break when recompiled 
>>> under Swift 3? Is it worth converging the names of the module so its the 
>>> same on all platforms? Isn’t it bad if portable code was doomed to have #if 
>>> os() for all Foundation imports? If we do rename it, do we rename it to 
>>> SwiftFoundation on Linux or do we rename it to Foundation on OS X (which 
>>> would require renaming the Objective-C Foundation to something else and 
>>> write a migration)?
>>> 
 On 14 May 2016, at 00:19, David Hart via swift-corelibs-dev 
 mailto:swift-corelibs-dev@swift.org>> wrote:
 
 
> On 13 May 2016, at 21:50, Tony Parker  > wrote:
> 
> Technically, swift-corelibs-foundation is only part of the distribution 
> on Linux. On Darwin platforms, we use a combination of the overlay 
> (stdlib/public/SDK/Foundation directory in the Swift project) and the 
> Foundation.framework that ships on the OS.
 
 I’m confused about swift-corelibs-foundation only being part of the Linux 
 distribution. Are you saying that when Swift 3.0 ships, import Foundation 
 on OS X and iOS will still import the Objective-C framework? If yes, I’m 
 very surprised, and I think many people will be. One of the goals of 
 swift-corelibs-foundation (README) says:
 
• Provide a level of OS independence, to enhance portability.
 
 How can it be portable if different platforms don’t share the same 
 underlying core libraries?
 
 David.
 
 ___
 swift-corelibs-dev mailing list
 swift-corelibs-dev@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
 
>>> 
>> 
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev