Looking at corelibs-foundation


(David Hart) #1

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?

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.

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?

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?

A well meaning developer,
David.


(Tony Parker) #2

Hi David,

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

···

On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

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


(James Lee) #3

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 <swift-corelibs-dev@swift.org> wrote:

Hi David,

On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev <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.
_______________________________________________
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


(Rob Allen) #4

Hi all,

Hi David,

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...

···

On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:


(Tony Parker) #5

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 <https://github.com/apple/swift-corelibs-foundation/pulls?utf8=✓&q=is:pr+is:closed+is:unmerged>

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 <james@jelee.co.uk> 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 <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hi David,

On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev <swift-corelibs-dev@swift.org <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.
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Tony Parker) #6

Hi all,

Hi David,

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

···

On May 13, 2016, at 10:33 AM, Rob Allen <rob@akrabat.com> wrote:

On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Regards,

Rob...


(David Hart) #7

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.

···

On 13 May 2016, at 21:50, Tony Parker <anthony.parker@apple.com> 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.


(David Hart) #8

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 <swift-corelibs-dev@swift.org> wrote:

On 13 May 2016, at 21:50, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> 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


(Tony Parker) #9

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 <david@hartbit.com> 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 <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

On 13 May 2016, at 21:50, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> 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 <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(David Hart) #10

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 <anthony.parker@apple.com> 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 <david@hartbit.com <mailto:david@hartbit.com>> 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 <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

On 13 May 2016, at 21:50, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> 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 <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Tony Parker) #11

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 May 13, 2016, at 4:13 PM, David Hart <david@hartbit.com> wrote:

On 14 May 2016, at 00:44, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> 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 <david@hartbit.com <mailto:david@hartbit.com>> 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 <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

On 13 May 2016, at 21:50, Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> 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 <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(David Hart) #12

Thanks for all the answers :slight_smile: These questions are dear to my heart because I plan on using corelibs-foundation on Darwin as soon as possible to share code between our iOS apps and web services.

···

On 14 May 2016, at 01:39, Tony Parker <anthony.parker@apple.com> wrote:

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.

I have a hard time seeing how they can evolve together seeing as we are already making improvements to corelibs-foundation with the value-type and NS-dropping proposals which will not reflect back to Darwin's system framework.


(David Hart) #13

Ok, I understand that corelibs won't be the official "Foundation" framework on Darwin, but it will still be available under SwiftFoundation without having to compile it ourselves right?

···

On 14 May 2016, at 01:39, Tony Parker <anthony.parker@apple.com> wrote:

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


(Tony Parker) #14

Hi David,

Thanks for all the answers :slight_smile: These questions are dear to my heart because I plan on using corelibs-foundation on Darwin as soon as possible to share code between our iOS apps and web services.

Yup, that is exactly the use case we want to enable. In fact...

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.

I have a hard time seeing how they can evolve together seeing as we are already making improvements to corelibs-foundation with the value-type and NS-dropping proposals which will not reflect back to Darwin's system framework.

Quite the contrary! Everything in those proposals applies equally to both Darwin and corelibs Foundation.

- Tony

···

On May 14, 2016, at 1:04 AM, David Hart <david@hartbit.com> wrote:

On 14 May 2016, at 01:39, Tony Parker <anthony.parker@apple.com> wrote: