[swift-corelibs-dev] Language or XCTest improvements to allow testing assert/precondition failures

[David Hart via swift-corelibs-dev]

Currently, it is impossible for XCTest to unit test assert and precondition 
failures because they kill the process. And those are important to unit test: 
how would you test NSArray's objectAtIndex bound conditions? Currently, the 
standard library tests those with StdlibUnittest, a small piece of code which 
runs those tests in a forked process.

I want to start a proposal but I'm not sure if it should come as a XCTest 
improvement which spawns a process or if the language should implement assert 
and precondition as a special kind of throw?

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

[swift-corelibs-dev] KVC dependent classes

[David Hart via swift-corelibs-dev]

I was looking through Foundation for stuff to do and saw NSProgress, 
NSExpression and NSSortDescriptor. They seem to be most reliant on KVC, and as 
KVC is not available without the Objective-C runtime, I’m not sure what those 
classes are doing here. Are those classes doomed to be dropped? Or is there 
another way to implement them?

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

Re: [swift-corelibs-dev] KVC dependent classes

[David Hart via swift-corelibs-dev]

Sorry, I said NSProgress but I meant NSPredicate. I personally can't even 
imagine what a alternative API for NSPredicate would look like 🤔

> On 15 Mar 2016, at 00:21, Tony Parker  wrote:
> 
> Hi David,
> 
> It’s likely that we’ll have to come up with some alternative API in these 
> cases. For example, in NSProgress I could imagine a callback for progress 
> updates instead of observing the properties. It’s not ideal but I don’t think 
> we want to undertake a reinvention of KVO when we do not have the Objective-C 
> runtime present (so much of it relies on that dynamic behavior).
> 
> - Tony
> 
>> On Mar 14, 2016, at 4:14 PM, David Hart via swift-corelibs-dev 
>>  wrote:
>> 
>> I was looking through Foundation for stuff to do and saw NSProgress, 
>> NSExpression and NSSortDescriptor. They seem to be most reliant on KVC, and 
>> as KVC is not available without the Objective-C runtime, I’m not sure what 
>> those classes are doing here. Are those classes doomed to be dropped? Or is 
>> there another way to implement them?
>> 
>> 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] Looking at corelibs-foundation

[David Hart via swift-corelibs-dev]

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.___
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 > <mailto:anthony.par...@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

___
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 > <mailto:da...@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 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> 
>>>> On 13 May 2016, at 21:50, Tony Parker >>> <mailto:anthony.par...@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 
>>> <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]

Thanks for all the answers :) 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  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.


___
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 14 May 2016, at 01:39, Tony Parker  wrote:
> 
> No. Only on Linux or other non-Darwin platforms.

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? 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Compilation Error - Which Toolchain?

[David Hart via swift-corelibs-dev]

Hi people,

Found some time to continue contributing to corelibs, but I’m getting a 
compilation error with master:

NSGeometry.swift (line 39):
35 private var hash: Int {
36 #if arch(i386) || arch(arm)
37 return Int(Float(self.native).bitPattern)
38 #else
39 return Int(self.native.bitPattern) // Value of type 'NativeType' 
(aka 'Double') has no member 'bitPattern’
40 #endif
41 }

I’m using the latest development toolchain. Is that correct? What’s the rule on 
which toolchain to use? I tried building a fresh master toolchain instead but 
got a failing test.

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

Re: [swift-corelibs-dev] Compilation Error - Which Toolchain?

[David Hart via swift-corelibs-dev]

Glad to know I’m not the only one. What do you mean by:

> So, pulled everything again and re-compiling from scratch, not just 
> corelibs-foundation.

Do you mean rebuilding a swift toolchain? Did you succeed? If yes, what branch?

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

[swift-corelibs-dev] Compilation Error - Which Toolchain

[David Hart via swift-corelibs-dev]

Hi people,

Found some time to continue contributing to corelibs, but I’m getting a 
compilation error with master:

NSGeometry.swift (line 39):
35 private var hash: Int {
36 #if arch(i386) || arch(arm)
37 return Int(Float(self.native).bitPattern)
38 #else
39 return Int(self.native.bitPattern) // Value of type 'NativeType' 
(aka 'Double') has no member 'bitPattern’
40 #endif
41 }

I’m using the latest development toolchain. Is that correct? I tried building a 
master toolchain instead but got a failing test.

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

Re: [swift-corelibs-dev] Compilation Error - Which Toolchain

[David Hart via swift-corelibs-dev]

Great! Thanks :)

> On 20 May 2016, at 18:09, Philippe Hausler  wrote:
> 
> Just pushed the revert, I will revisit it when we have the next drop of the 
> toolchains for all platforms that include the required change for this 
> correction.
> 
>> On May 20, 2016, at 9:05 AM, Philippe Hausler via swift-corelibs-dev 
>>  wrote:
>> 
>> This was a change in the standard library. I presumed that change had been 
>> in for a full build cycle. However since that looks like it is not the case 
>> I am going to revert the offending commit for now and revisit it when the 
>> binaries are rev'd
>> 
>>> On May 19, 2016, at 3:48 PM, David Hart via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Hi people,
>>> 
>>> Found some time to continue contributing to corelibs, but I’m getting a 
>>> compilation error with master:
>>> 
>>> NSGeometry.swift (line 39):
>>> 35 private var hash: Int {
>>> 36 #if arch(i386) || arch(arm)
>>> 37 return Int(Float(self.native).bitPattern)
>>> 38 #else
>>> 39 return Int(self.native.bitPattern) // Value of type 'NativeType' 
>>> (aka 'Double') has no member 'bitPattern’
>>> 40 #endif
>>> 41 }
>>> 
>>> I’m using the latest development toolchain. Is that correct? I tried 
>>> building a master toolchain instead but got a failing test.
>>> 
>>> Any ideas?
>>> 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

[swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

[David Hart via swift-corelibs-dev]

Hello,

The discussion we had previously on this mailing list made it quite clear that:

- Objective-C Foundation is the framework that is supposed to be used on all 
Darwin platforms,
- swift-corelibs-foundation will be the Foundation framework for all other 
platforms,
- Both frameworks will evolve slowly together.

Therefore, it makes sense that for code written against Foundation to be 
portable, the swift-corelibs-foundation APIs and behavior needs to be identical 
to Darwin Foundation. Hence the following questions?

- Shouldn't we be writing tests in a way so that they can be run against Darwin 
Foundation and have the CI Server run them? For example: while working on 
NSProgress, I write a bunch of tests against Darwin Foundation, make sure they 
pass, then copy-paste them in the CoreLibs project, and fix the implementation 
until they pass. This makes sure that both APIs are consistent with each other. 
I was thinking that we ought to automate this and have the CI server test them.

- How are we planning to reconcile the API differences between both frameworks? 
For examples, one of my tests will run against CoreLibs but not against Darwin 
because NSThread.init takes a closure as argument in CoreLibs but a 
target+selector in Darwin. This is just one example, but I guess they are other 
inconsistencies elsewhere. This seems to be particularly the case with APIs 
that rely on the Objective-C runtime.

In general, I'm starting to worry about the state of Foundation from a 
portability point of view. Once Swift 3 is released, I want to start writing 
portable swift code that relies on Foundation. And it seems like this will 
require a huge amount of #if os() everywhere to cope with the differences.

David


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

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

[David Hart via swift-corelibs-dev]

Brian Gesiak started started one for foundation. It seems it's only missing 
some trimming and labeling of issues:

> David,
> 
> I actually started on one! http://tinyurl.com/foundation-dashboard :)
> 
> Like you mentioned, I don't have a ton of context on the project, so I'm a 
> little hesitant to decide what should be tagged with "swift-3.0".
> 
> Still, one thing that stands out: swift-corelibs-foundation has only one task 
> with the StarterBug label! I wonder if some tasks can be cleaned up, given 
> clearer instructions, and labeled as a starter task...
> 
> - Brian Gesi


> On 23 May 2016, at 22:41, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> This is slick!
> 
> I would love to have one for Foundation too (although my understanding of 
> JIRA is limited at best).
> 
> - Tony
> 
>> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello all!
>> 
>> If you're like me, you might be curious how Core Libraries like 
>> swift-corelibs-xctest are doing with regards to the looming Swift 3.0 
>> release. Well, wonder no more -- this handy JIRA dashboard has the 
>> information you need: 
>> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408
>> 
>> The dashboard not only lists tasks that need to be resolved by Swift 3.0, 
>> but also open starter tasks for new contributors.
>> 
>> Let me know if you find it useful! I personally think it'd be neat to have 
>> one of these for all the swift-corelibs-* projects, what do you all think? :)
>> 
>> PS: For those interested, the dashboard is implemented using custom task 
>> filters:
>> 
>> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469
>> - corelibs-xctest Open 3.0 Tasks: https://bugs.swift.org/issues/?filter=10471
>> - corelibs-xctest Open Starter Tasks: 
>> https://bugs.swift.org/issues/?filter=10470
>> 
>> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in 
>> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels 
>> on JIRA before.)
>> 
>> - Brian Gesiak
>> 
>> ___
>> 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] Objective-C Foundation vs CoreLibs Foundation

[David Hart via swift-corelibs-dev]

Would you agree that the first step should be to have the project as a SwiftPM 
package so that we have a more consistent way to run tests on all platforms? Do 
you know if SwiftPM is far enough to support swift-corelibs-foundation? I might 
have a go at it once I finish implementing NSProgress (about half way through I 
think).

> On 23 May 2016, at 17:59, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi David,
> 
>> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello,
>> 
>> The discussion we had previously on this mailing list made it quite clear 
>> that:
>> 
>> - Objective-C Foundation is the framework that is supposed to be used on all 
>> Darwin platforms,
>> - swift-corelibs-foundation will be the Foundation framework for all other 
>> platforms,
>> - Both frameworks will evolve slowly together.
> 
> Yup.
> 
>> 
>> Therefore, it makes sense that for code written against Foundation to be 
>> portable, the swift-corelibs-foundation APIs and behavior needs to be 
>> identical to Darwin Foundation. Hence the following questions?
>> 
>> - Shouldn't we be writing tests in a way so that they can be run against 
>> Darwin Foundation and have the CI Server run them? For example: while 
>> working on NSProgress, I write a bunch of tests against Darwin Foundation, 
>> make sure they pass, then copy-paste them in the CoreLibs project, and fix 
>> the implementation until they pass. This makes sure that both APIs are 
>> consistent with each other. I was thinking that we ought to automate this 
>> and have the CI server test them.
> 
> That would be a great step. This is part of the reason we tried to set up the 
> dependencies of Foundation on XCTest the way we did, and provide the Xcode 
> project file; so we could share tests. I would welcome any help we can get on 
> improving our automation story here.
> 
>> 
>> - How are we planning to reconcile the API differences between both 
>> frameworks? For examples, one of my tests will run against CoreLibs but not 
>> against Darwin because NSThread.init takes a closure as argument in CoreLibs 
>> but a target+selector in Darwin. This is just one example, but I guess they 
>> are other inconsistencies elsewhere. This seems to be particularly the case 
>> with APIs that rely on the Objective-C runtime.
> 
> These should be marked as “experimental” in the documentation comments. If 
> not, we should do that.
> 
> There are some areas where we just don’t know what to do yet, because of the 
> lack of the ObjC runtime and implicit bridging on Linux. In some of those 
> places we’ve tried to provide a replacement API and mark it as experimental 
> until we can figure out the larger story.
> 
>> In general, I'm starting to worry about the state of Foundation from a 
>> portability point of view. Once Swift 3 is released, I want to start writing 
>> portable swift code that relies on Foundation. And it seems like this will 
>> require a huge amount of #if os() everywhere to cope with the differences.
>> 
>> David
> 
> Our long term goal is to enable developers to do this. I acknowledge that we 
> have a ways to go to get there. I’ve seen an uptick in contributions 
> recently, which gives me hope that we can get closer before the release of 
> Swift 3.
> 
> - Tony
> 
> ___
> 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] WWDC Meetup

[David Hart via swift-corelibs-dev]

I imagine that during WWDC a non-negligible proportion of the Swift Open Source 
contributors will be in or around San-Francisco. I’d very much like to profit 
from that opportunity to meet-up, get to know each other, talk Swift over some 
beers! Is anybody interested? If yes, any ideas for location? I can setup a 
Doodle once I see enough interest.

Looking forward to meet you!___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-evolution] [swift-users] WWDC Meetup

[David Hart via swift-corelibs-dev]

Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
proposing dinner somewhere.

I’ve setup a Google Forms to help organise it:

http://goo.gl/forms/Oq6dK9fPNSCAVfL72 

> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>  wrote:
> 
> +1 to both points :)
> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> I would love to join as well!!
> 
> I'd like to propose perhaps to plan something alternative to beers to keep it 
> inclusive to members who may not be 21 or like to drink alcohol :)
> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
> mailto:swift-evolut...@swift.org>> wrote:
> +1  I'd love to put some faces to some names  :)  sounds fun!
> 
> Shane
> 
> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users  > wrote:
> 
>> I'd be interested in catching up. Was curious if there was going to be a 
>> meet up, either formal or informal. Sounds good.
>> 
>> -Rod
>> 
>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>> mailto:swift-evolut...@swift.org>> wrote:
>> 
>>> I imagine that during WWDC a non-negligible proportion of the Swift Open 
>>> Source contributors will be in or around San-Francisco. I’d very much like 
>>> to profit from that opportunity to meet-up, get to know each other, talk 
>>> Swift over some beers! Is anybody interested? If yes, any ideas for 
>>> location? I can setup a Doodle once I see enough interest.
>>> 
>>> Looking forward to meet you!
>>> ___
>>> swift-evolution mailing list
>>> swift-evolut...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> 
>> ___
> 
>> 
>> swift-users mailing list
>> swift-us...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> -- 
> Javier Soto
> ___
> 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] [swift-evolution] [swift-users] WWDC Meetup

[David Hart via swift-corelibs-dev]

Hi everybody,

After receiving a private question, I'd like to clarify something: I’m hoping 
that anybody interested in the Swift Open Source project, contributor or not, 
WWDC ticket holder or not, should feel free to come! This is definitely not 
something I meant to be restricted in any way. My original wording wasn’t 
entirely clear.

So, if you like Swift, if you have an interest in discussing about the Open 
Source project, please feel welcome to subscribe!

David.

> On 07 Jun 2016, at 08:46, David Hart via swift-evolution 
>  wrote:
> 
> Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
> proposing dinner somewhere.
> 
> I’ve setup a Google Forms to help organise it:
> 
> http://goo.gl/forms/Oq6dK9fPNSCAVfL72 
> 
>> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> +1 to both points :)
>> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> I would love to join as well!!
>> 
>> I'd like to propose perhaps to plan something alternative to beers to keep 
>> it inclusive to members who may not be 21 or like to drink alcohol :)
>> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
>> mailto:swift-evolut...@swift.org>> wrote:
>> +1  I'd love to put some faces to some names  :)  sounds fun!
>> 
>> Shane
>> 
>> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users > > wrote:
>> 
>>> I'd be interested in catching up. Was curious if there was going to be a 
>>> meet up, either formal or informal. Sounds good.
>>> 
>>> -Rod
>>> 
>>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>>> mailto:swift-evolut...@swift.org>> wrote:
>>> 
 I imagine that during WWDC a non-negligible proportion of the Swift Open 
 Source contributors will be in or around San-Francisco. I’d very much like 
 to profit from that opportunity to meet-up, get to know each other, talk 
 Swift over some beers! Is anybody interested? If yes, any ideas for 
 location? I can setup a Doodle once I see enough interest.
 
 Looking forward to meet you!
 ___
 swift-evolution mailing list
 swift-evolut...@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>> 
>>> ___
>> 
>>> 
>>> swift-users mailing list
>>> swift-us...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> -- 
>> Javier Soto
>> ___
>> 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-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-corelibs-dev] [swift-evolution] [swift-users] WWDC Meetup

[David Hart via swift-corelibs-dev]

Thanks for everybody that took the time to fill the form! There were many more 
responses than I expected, so dinner becomes difficult to organise. But thanks 
to a hand from another community member, we should have a venue confirmed soon.

We are currently shooting for Tuesday evening.

More details coming ASAP.

> On 07 Jun 2016, at 08:46, David Hart  wrote:
> 
> Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
> proposing dinner somewhere.
> 
> I’ve setup a Google Forms to help organise it:
> 
> http://goo.gl/forms/Oq6dK9fPNSCAVfL72 
> 
>> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> +1 to both points :)
>> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> I would love to join as well!!
>> 
>> I'd like to propose perhaps to plan something alternative to beers to keep 
>> it inclusive to members who may not be 21 or like to drink alcohol :)
>> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
>> mailto:swift-evolut...@swift.org>> wrote:
>> +1  I'd love to put some faces to some names  :)  sounds fun!
>> 
>> Shane
>> 
>> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users > > wrote:
>> 
>>> I'd be interested in catching up. Was curious if there was going to be a 
>>> meet up, either formal or informal. Sounds good.
>>> 
>>> -Rod
>>> 
>>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>>> mailto:swift-evolut...@swift.org>> wrote:
>>> 
 I imagine that during WWDC a non-negligible proportion of the Swift Open 
 Source contributors will be in or around San-Francisco. I’d very much like 
 to profit from that opportunity to meet-up, get to know each other, talk 
 Swift over some beers! Is anybody interested? If yes, any ideas for 
 location? I can setup a Doodle once I see enough interest.
 
 Looking forward to meet you!
 ___
 swift-evolution mailing list
 swift-evolut...@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>> 
>>> ___
>> 
>>> 
>>> swift-users mailing list
>>> swift-us...@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> -- 
>> Javier Soto
>> ___
>> 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] [swift-evolution] [swift-users] WWDC Meetup

[David Hart via swift-corelibs-dev]

Hi all,
 
I have some news on the WWDC meet-up that was announced earlier this week. 
Thanks to the help of a friendly community member, Bert Belder, we have been 
able to secure a very cool venue!

The meetup will take place on Tuesday, June 14th at 7pm, in the IBM Bluemix 
Garage, which is at about 5 minutes walking distance from the Moscone Center. 
So WWDC visitors should have no problem getting there.
The full address is: 543 Howard st, San Francisco. 
https://goo.gl/maps/2EqAN4eNEu72 <https://goo.gl/maps/2EqAN4eNEu72>
We’ll make sure there are some bites and drinks so you don’t have to worry 
about your  basic human needs.
 
Our goal is to create a small and social event where people involved in the 
Swift open source community can meet each other face-to-face. Some folks from 
IBM that work on Swift for Linux and the package catalog will be there. If you 
know of others involved in the swift open-source ecosystem, feel free to invite 
them.
 
Please RSVP at https://ti.to/swift-oss/wwdc-2016 
<https://ti.to/swift-oss/wwdc-2016>. It’s free, we just need to know how many 
people are coming. We currently have a limit of 50 people.

Although we want to make this mostly a social event, there will be some room 
for short presentations. If you can talk for 5 minutes about your Swift pet 
project, we’d love to hear it.

That’s all for now - hope to see you next week!

David & Bert

> On 08 Jun 2016, at 08:10, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Thanks for everybody that took the time to fill the form! There were many 
> more responses than I expected, so dinner becomes difficult to organise. But 
> thanks to a hand from another community member, we should have a venue 
> confirmed soon.
> 
> We are currently shooting for Tuesday evening.
> 
> More details coming ASAP.
> 
>> On 07 Jun 2016, at 08:46, David Hart > <mailto:da...@hartbit.com>> wrote:
>> 
>> Of course, I wouldn’t want to exclude anybody by default! In that case, I’m 
>> proposing dinner somewhere.
>> 
>> I’ve setup a Google Forms to help organise it:
>> 
>> http://goo.gl/forms/Oq6dK9fPNSCAVfL72 <http://goo.gl/forms/Oq6dK9fPNSCAVfL72>
>> 
>>> On 07 Jun 2016, at 08:43, Jacob Bandes-Storch via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> +1 to both points :)
>>> On Mon, Jun 6, 2016 at 11:11 PM Javier Soto via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> I would love to join as well!!
>>> 
>>> I'd like to propose perhaps to plan something alternative to beers to keep 
>>> it inclusive to members who may not be 21 or like to drink alcohol :)
>>> On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution 
>>> mailto:swift-evolut...@swift.org>> wrote:
>>> +1  I'd love to put some faces to some names  :)  sounds fun!
>>> 
>>> Shane
>>> 
>>> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users 
>>> mailto:swift-us...@swift.org>> wrote:
>>> 
>>>> I'd be interested in catching up. Was curious if there was going to be a 
>>>> meet up, either formal or informal. Sounds good.
>>>> 
>>>> -Rod
>>>> 
>>>> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution 
>>>> mailto:swift-evolut...@swift.org>> wrote:
>>>> 
>>>>> I imagine that during WWDC a non-negligible proportion of the Swift Open 
>>>>> Source contributors will be in or around San-Francisco. I’d very much 
>>>>> like to profit from that opportunity to meet-up, get to know each other, 
>>>>> talk Swift over some beers! Is anybody interested? If yes, any ideas for 
>>>>> location? I can setup a Doodle once I see enough interest.
>>>>> 
>>>>> Looking forward to meet you!
>>>>> ___
>>>>> swift-evolution mailing list
>>>>> swift-evolut...@swift.org <mailto:swift-evolut...@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>>> ___
>>> 
>>>> 
>>>> swift-users mailing list
>>>> swift-us...@swift.org <mailto:swift-us...@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>> ___
>>> swift-e

Re: [swift-corelibs-dev] Suggested DateInterval API improvement

[David Hart via swift-corelibs-dev]

I vote for (2). Thats what I would have expected. `start` changing from under 
you is weird.

> On 21 Jun 2016, at 18:44, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi Greg,
> 
>> On Jun 20, 2016, at 9:04 PM, Greg Titus > > wrote:
>> 
>> One domain where this happens is project planning back from a fixed end 
>> date. The most well-known of these would be rocket launches: “T minus 10 
>> seconds” is exactly a negative time interval from an end date.
>> 
> 
> That makes sense.
> 
> Let’s say we added negative interval support to the type. I could see it 
> working in two ways:
> 
> 1. You initialize with a start and negative duration. After this, the ‘end’ 
> property becomes what you used for ‘start’ and ‘start’ is adjusted according 
> to the interval.
> 2. We keep the start date to always be what you passed in but allow a 
> negative value for timeInterval and allow for end to be < start.
> 
> Which of these would be the least confusing?
> 
> - Tony
> 
>> That being said, it’s a fairly uncommon use case and I wouldn’t change the 
>> API to support it on an equivalent basis with normal forward date intervals. 
>> A separate specific initializer for it might be useful, though.
>> 
>>  - Greg
>> 
>>> On Jun 20, 2016, at 4:12 PM, Tony Parker via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hi Dave,
>>> 
>>> We had some extensive discussion about this ourselves, but we couldn’t come 
>>> up with a compelling use case for a negative time interval. Can you 
>>> describe how you wanted to use it?
>>> 
>>> - Tony
>>> 
 On Jun 17, 2016, at 2:01 PM, Dave Lyon via swift-corelibs-dev 
 mailto:swift-corelibs-dev@swift.org>> wrote:
 
 In attempting to use the new DateInterval value type to improve some 
 existing code, I ran in to an issue where DateIntervals cannot be 
 "reverse" intervals, which is contrary to how TimeInterval works, and 
 somewhat confusing.
 
 I would propose that the DateInterval value type should be able to be 
 properly initialized with any TimeInterval, as a reference date and time 
 interval are all that is actually required in order to construct a 
 DateInterval properly.
 
 The simplest solution might be to change the `startDate:interval:` 
 initializer to one allows for negative time intervals, such as:
 
 public init(withInterval: TimeInterval, fromDate: Date) { 
 self.start = Date(timeInterval: interval, since: fromDate)
 self.duration = abs(interval)
 }
 
 I believe in general it is preferable to avoid preconditions that require 
 a subset of a given input type (in this case, that TimeInterval be 
 positive or 0), and would prefer to see an API where invalid values are 
 properly converted from the given input to the documented output. E.g. the 
 old “Be generous with input, strict with output” idea.
 
 I hope this is the right place to bring this up, but if not I’m happy to 
 move the conversation to Radar or elsewhere.
 
 Thanks!
 
 ___
 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

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

[swift-corelibs-dev] Fix API disparities between Darwin and Corelibs Foundation

[David Hart via swift-corelibs-dev]

If the goal is to have Darwin and Corelibs Foundation as API compatible as 
possible, I think the Foundation team at Apple should start introducing some of 
the rare API changes back into Darwin Foundation before the final release of 
iOS 10 and macOS Sierra.

For example, it's currently impossible to initialize a Thread object with the 
same code on both platforms. Darwin has a target+action initializer and 
Corelibs has a closure initializer. As Corelibs can not have the target+action 
initializer, the only solution is to have Darwin implement the closure 
initializer.

This is just one example and I guess they are more out there.

Comments? How do we proceed?
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-dev] Swift Encoders on Linux

[David Hart via swift-corelibs-dev]

Hi Tony,

Looking forward to all this on Linux!

On the same topic, I looked at the Measurement Swift type and did a diff 
between the shims in the swift repo and the version in corelibs-foundation and 
saw quite a few differences. Is this something that can be improved or it is a 
consequence of the platform differences?

Thanks,
David.

> On 23 May 2017, at 17:14, Tony Parker via swift-dev  
> wrote:
> 
> Hi Ankit,
> 
> Our intention is to share as much of the implementation as possible. There 
> are some details that need to be worked out around bridging of types like 
> NSNumber (since bridging doesn't exist on Linux we may need to avoid using 
> 'as' in a few places), but in general it could be as easy as copying the 
> files from the Foundation overlay on Darwin into the other project.
> 
> We've been focused on getting the last details in place so haven't been able 
> to pursue the rest of this ourselves. If anyone wanted to step up and help us 
> out here, it would be awesome to ship the feature concurrently on Linux. 
> 
> - Tony
> 
>> On May 23, 2017, at 1:11 AM, Ankit Aggarwal via swift-corelibs-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> It looks like SE-0167 is implemented and can be used in the latest macOS 
>> snapshot (yay!). Will corelibs-foundation need a completely separate 
>> implementation? Is the corelibs-foundation implementation going to be 
>> community driven?
>> 
>> PS: I think these are awesome APIs and the Package Manager will really 
>> benefit from SE-0166, SE-0167.
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

[swift-corelibs-dev] Informal Chat Medium

[David Hart via swift-corelibs-dev]

Hello Corelibs dev,

A few months back, I wanted to start contributing more seriously to Swift Open 
Source. I ended up helping out on the Swift Package Manager project and had a 
very positive experience. It’s not easy to jump into a big project and it would 
not have been such a success for me without their official Slack channel where 
I was grateful to often find a helping hand when I had doubts, questions, or 
wanted to discuss and understand the process or direction of the project. That 
medium really helped me to ask the kind of questions I was afraid to ask on the 
mailing-list, which feels like a more formal medium.

Now that I’m looking into what I can do on corelibs-foundation, I really wish 
an equivalent channel existed. Is this an idea the corelibs team would be 
interested in entertaining?

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

Re: [swift-corelibs-dev] Informal Chat Medium

[David Hart via swift-corelibs-dev]

> On 3 Aug 2017, at 10:33, Alex Blewitt  wrote:
> 
>> On 2 Aug 2017, at 20:34, David Hart via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello Corelibs dev,
> 
> Hi David, welcome!
> 
>> A few months back, I wanted to start contributing more seriously to Swift 
>> Open Source. I ended up helping out on the Swift Package Manager project and 
>> had a very positive experience. It’s not easy to jump into a big project and 
>> it would not have been such a success for me without their official Slack 
>> channel where I was grateful to often find a helping hand when I had doubts, 
>> questions, or wanted to discuss and understand the process or direction of 
>> the project. That medium really helped me to ask the kind of questions I was 
>> afraid to ask on the mailing-list, which feels like a more formal medium.
>> 
>> Now that I’m looking into what I can do on corelibs-foundation, I really 
>> wish an equivalent channel existed. Is this an idea the corelibs team would 
>> be interested in entertaining?
> 
> Yes, and indeed something that's been discussed for a while now is the 
> possibility of moving the mailing lists to a forum:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038452.html
> 
> Although Ted initially started the discussion with 'for swift-evolution' he 
> later clarified he thought all should move:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038454.html
> 
> While it's not a Slack channel, I wonder if this would suit your needs if it 
> were to happen?

I’ve followed those discussions and am very excited about moving the mailing 
lists to Discourse, but I think it doesn’t fundamentally change the medium. I 
think a chat channel is really a different beast.

> Alex

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