[swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on Linux

[Joseph Bell via swift-corelibs-dev]

Howdy all,

While working to convert some NSThread code over to GCD on Linux I noticed
that (to my dismay) GCD wasn't included in the Swift 3.0 preview build, nor
is it apart of the buildbot for Linux.  Scouring through the repository and
mailing lists I can see where it is possible to build, but there are no
downstream instructions on how to make a line like this:

let queue = DispatchQueue(label: "com.app.queue")

work with the swiftc compiler on Linux.

A couple of questions:

* are there any timelines that the principals of GCD with Swift 3 on Linux
can share; i.e., is the plan to have it included in time for the Swift 3 GA
release later this year?
* are there any follow-up instructions past getting it built on how to use
it (or will make install DESTDIR place it in the right spots in the Swift 3
toolchain hierarchy?)

Any useful tips or pointers would be helpful!

Cheers,
Joe

-- 
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on Linux

[David P Grove via swift-corelibs-dev]

Hi Joe,

TL;DR: right now the Swift 3.0 overlay for libdispatch is not
available on Linux.

But, a variety of activities are kicking off to get it there.  There
should be visible progress (and opportunities to help if you are so
inclined) over the next few weeks.

>
> While working to convert some NSThread code over to GCD on Linux I
> noticed that (to my dismay) GCD wasn't included in the Swift 3.0
> preview build, nor is it apart of the buildbot for Linux.  Scouring
> through the repository and mailing lists I can see where it is
> possible to build, but there are no downstream instructions on how
> to make a line like this:
>
> let queue = DispatchQueue(label: "com.app.queue")
>
> work with the swiftc compiler on Linux.
>
> A couple of questions:
>
> * are there any timelines that the principals of GCD with Swift 3 on
> Linux can share; i.e., is the plan to have it included in time for
> the Swift 3 GA release later this year?

I certainly hope so; but cannot speak for official plans.

> * are there any follow-up instructions past getting it built on how
> to use it (or will make install DESTDIR place it in the right spots
> in the Swift 3 toolchain hierarchy?)
>

I expect when things are done, it will be similar to how building the
current Swift-2 dispatch overlay works on Linux.  To build from source you
use swift/utils/build-script with --libdispatch and it takes care of all
the details (ie, it just works...).

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

Re: [swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on Linux

[Joseph Bell via swift-corelibs-dev]

Dave,

Thanks for the details, I appreciate it.  I have seen the term "Swift
overlay" used, particularly in the context of libdispatch.  What does that
mean exactly in this regard (searching for it returns tutorials on overlay
UIViews which I doubt is appropriate here).

I certainly hope GCD is included in Swift 3.0 on Linux too!

Joe


On Tue, Jun 21, 2016 at 7:59 AM, David P Grove  wrote:

> Hi Joe,
>
> TL;DR: right now the Swift 3.0 overlay for libdispatch is not available on
> Linux.
>
> But, a variety of activities are kicking off to get it there.  There
> should be visible progress (and opportunities to help if you are so
> inclined) over the next few weeks.
>
> >
> > While working to convert some NSThread code over to GCD on Linux I
> > noticed that (to my dismay) GCD wasn't included in the Swift 3.0
> > preview build, nor is it apart of the buildbot for Linux.  Scouring
> > through the repository and mailing lists I can see where it is
> > possible to build, but there are no downstream instructions on how
> > to make a line like this:
> >
> > let queue = DispatchQueue(label: "com.app.queue")
> >
> > work with the swiftc compiler on Linux.
> >
> > A couple of questions:
> >
> > * are there any timelines that the principals of GCD with Swift 3 on
> > Linux can share; i.e., is the plan to have it included in time for
> > the Swift 3 GA release later this year?
>
> I certainly hope so; but cannot speak for official plans.
>
> > * are there any follow-up instructions past getting it built on how
> > to use it (or will make install DESTDIR place it in the right spots
> > in the Swift 3 toolchain hierarchy?)
> >
>
> I expect when things are done, it will be similar to how building the
> current Swift-2 dispatch overlay works on Linux.  To build from source you
> use swift/utils/build-script with --libdispatch and it takes care of all
> the details (ie, it just works...).
>
> --dave
>
>


-- 
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on Linux

[Chris Bailey via swift-corelibs-dev]

Joe:

FYI, if you want to be able to use the Swift 2.2 APIs for Dispatch, 
there's some instructions on how to build a toolchain with Dispatch 
included here:
https://gist.github.com/seabaylea/cad7808615c52cfd2fc9d1debcad832f

The third step uses a fork of Foundation from (based on master from a 
couple of weeks ago) that enables the use of Dispatch by Foundation 
itself, and adds NSURLSession support. If you just want to use Dispatch 
directly, you can ignore that step.

As Dave says, we're working on adding Dispatch into the toolchain on 
Linux, and uplifting it to the new Swift 3.0 APIs - if you want to get 
involved, your definitely welcome!

Chris




From:   David P Grove via swift-corelibs-dev 

To: swift-corelibs-dev@swift.org
Date:   21/06/2016 14:02
Subject:Re: [swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on 
Linux
Sent by:swift-corelibs-dev-boun...@swift.org



Hi Joe,

TL;DR: right now the Swift 3.0 overlay for libdispatch is not available on 
Linux. 

But, a variety of activities are kicking off to get it there.  There 
should be visible progress (and opportunities to help if you are so 
inclined) over the next few weeks.

> 
> While working to convert some NSThread code over to GCD on Linux I 
> noticed that (to my dismay) GCD wasn't included in the Swift 3.0 
> preview build, nor is it apart of the buildbot for Linux.  Scouring 
> through the repository and mailing lists I can see where it is 
> possible to build, but there are no downstream instructions on how 
> to make a line like this:
> 
> let queue = DispatchQueue(label: "com.app.queue") 
> 
> work with the swiftc compiler on Linux.
> 
> A couple of questions:
> 
> * are there any timelines that the principals of GCD with Swift 3 on
> Linux can share; i.e., is the plan to have it included in time for 
> the Swift 3 GA release later this year?

I certainly hope so; but cannot speak for official plans.

> * are there any follow-up instructions past getting it built on how 
> to use it (or will make install DESTDIR place it in the right spots 
> in the Swift 3 toolchain hierarchy?)
> 

I expect when things are done, it will be similar to how building the 
current Swift-2 dispatch overlay works on Linux.  To build from source you 
use swift/utils/build-script with --libdispatch and it takes care of all 
the details (ie, it just works...). 

--dave
___
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] libdispatch/GCD for Swift 3.0 on Linux

[David P Grove via swift-corelibs-dev]

Joseph Bell  wrote on 06/21/2016 09:15:00 AM:

>
> Thanks for the details, I appreciate it.  I have seen the term
> "Swift overlay" used, particularly in the context of libdispatch.
> What does that mean exactly in this regard (searching for it returns
> tutorials on overlay UIViews which I doubt is appropriate here).
>

Hi,

There's a layer of Swift code that sits on top of the non-Swift
implementation of libdispatch to provide the Swift-level API for the
library.  This is called the overlay.

In Swift 2, the overlay for libdispatch was relatively thin.  In
Swift 3 it became thicker and on Darwin platforms more reliant on compiler
support for importing Objective-C API declarations in a "Swifty" way.  The
main work item for getting the libdispatch Swift 3 APIs on Linux is to
compensate for the lack of Objective-C by manually writing a layer (in
Swift) that sits between the basic C-level APIs libdispatch provides on
Linux and the desired user-visible Swift-3 APIs.

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

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

[Tony Parker via swift-corelibs-dev]

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

Re: [swift-corelibs-dev] Xcode 8 beta 1 and swift-corelibs-foundation

[Tony Parker via swift-corelibs-dev]

Hi everyone,

We’ve merged the swift-3 branch into master. Please let us know if you 
encounter any issues.

I’m going to keep going through pull requests, but some may be out of date and 
need rebasing now.

Thanks,
- Tony

> On Jun 14, 2016, at 10:24 AM, Tony Parker  wrote:
> 
> Hello everyone,
> 
> If you’ve downloaded Xcode 8 beta 1, you’ve seen some of the great changes 
> we’ve got coming up for Swift 3 on Darwin. We have been working in parallel 
> on those improvements and the changes that we need to bring 
> swift-corelibs-foundation up-to-date, including:
> 
>  * new value types (SE-0069)
>  * new names for API and NS-dropping changes (SE-0086)
>  * new tests (mostly part of the overlay, not all merged to corelibs yet)
> 
> We plan to post later today a branch (name forthcoming) to the 
> swift-corelibs-foundation repository that contains the first version of all 
> of these changes. We’ve also been merging all of the other changes from 
> master branch.
> 
> It’s not quite ready to merge back to master yet, so we would appreciate your 
> help! Check out the branch, look for errors or omissions, and submit some PRs 
> or send mail to this list.
> 
> Our hope is to merge this branch very quickly, in the span of a week or two 
> at most. We will likely need to get some parallel PRs up for XCTest and 
> swiftpm to help them adapt to the new name and type changes. 
> 
> Thanks!
> - Tony
> 

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

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

[Greg Titus via swift-corelibs-dev]

> On Jun 21, 2016, at 9:44 AM, Tony Parker  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?

I think option #1 is the way to go. Subverting the English meaning of ‘start’ 
and ‘end’ would cause a lot of confusion. In actual use I think it would be 
fairly common to also need to keep track of which date was the ‘fixed’ date 
passed into the initializer, but that can always be done by the user of the 
framework by wrapping the DateInterval. e.g.:

enum FixedDirection {
case FromStart
case FromEnd
}
struct MyDateInterval {
let interval: DateInterval
let direction: FixedDirection
}

The additional info beyond the DateInterval itself likely varies by the use 
case, so it probably isn’t necessary to add this to DateInterval itself.

Thanks!
- Greg

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

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

Re: [swift-corelibs-dev] Xcode 8 beta 1 and swift-corelibs-foundation

[Luke Howard via swift-corelibs-dev]

Hi Tony,

Just on the change to NSUUID’s decoder, it changes the existing behaviour (note 
comment "failure to decode the entire uuid_t results in a new uuid”). I don’t 
have time to test whether this comment is accurate but perhaps you can 
cross-check with Darwin.

Having said that, the new behaviour (returning nil on decode failure) does make 
a lot more sense so perhaps it’s better to keep that.

Cheers,
Luke

> On 22 Jun 2016, at 2:46 AM, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi everyone,
> 
> We’ve merged the swift-3 branch into master. Please let us know if you 
> encounter any issues.
> 
> I’m going to keep going through pull requests, but some may be out of date 
> and need rebasing now.
> 
> Thanks,
> - Tony
> 
>> On Jun 14, 2016, at 10:24 AM, Tony Parker > > wrote:
>> 
>> Hello everyone,
>> 
>> If you’ve downloaded Xcode 8 beta 1, you’ve seen some of the great changes 
>> we’ve got coming up for Swift 3 on Darwin. We have been working in parallel 
>> on those improvements and the changes that we need to bring 
>> swift-corelibs-foundation up-to-date, including:
>> 
>>  * new value types (SE-0069)
>>  * new names for API and NS-dropping changes (SE-0086)
>>  * new tests (mostly part of the overlay, not all merged to corelibs yet)
>> 
>> We plan to post later today a branch (name forthcoming) to the 
>> swift-corelibs-foundation repository that contains the first version of all 
>> of these changes. We’ve also been merging all of the other changes from 
>> master branch.
>> 
>> It’s not quite ready to merge back to master yet, so we would appreciate 
>> your help! Check out the branch, look for errors or omissions, and submit 
>> some PRs or send mail to this list.
>> 
>> Our hope is to merge this branch very quickly, in the span of a week or two 
>> at most. We will likely need to get some parallel PRs up for XCTest and 
>> swiftpm to help them adapt to the new name and type changes. 
>> 
>> Thanks!
>> - Tony
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

--
www.lukehoward.com
soundcloud.com/lukehoward

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

Re: [swift-corelibs-dev] Xcode 8 beta 1 and swift-corelibs-foundation

[Tony Parker via swift-corelibs-dev]

Hi Luke,

> On Jun 21, 2016, at 3:50 PM, Luke Howard via swift-corelibs-dev 
>  wrote:
> 
> Hi Tony,
> 
> Just on the change to NSUUID’s decoder, it changes the existing behaviour 
> (note comment "failure to decode the entire uuid_t results in a new uuid”). I 
> don’t have time to test whether this comment is accurate but perhaps you can 
> cross-check with Darwin.
> 
> Having said that, the new behaviour (returning nil on decode failure) does 
> make a lot more sense so perhaps it’s better to keep that.
> 
> Cheers,
> Luke
> 

Yup, I checked on this and you’re right that it returns a random UUID if 
decoding fails. This is a truly strange idea, so I’ve filed a bug for us to fix 
that there too (26930786).

- Tony


>> On 22 Jun 2016, at 2:46 AM, Tony Parker via swift-corelibs-dev 
>> mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>> Hi everyone,
>> 
>> We’ve merged the swift-3 branch into master. Please let us know if you 
>> encounter any issues.
>> 
>> I’m going to keep going through pull requests, but some may be out of date 
>> and need rebasing now.
>> 
>> Thanks,
>> - Tony
>> 
>>> On Jun 14, 2016, at 10:24 AM, Tony Parker >> > wrote:
>>> 
>>> Hello everyone,
>>> 
>>> If you’ve downloaded Xcode 8 beta 1, you’ve seen some of the great changes 
>>> we’ve got coming up for Swift 3 on Darwin. We have been working in parallel 
>>> on those improvements and the changes that we need to bring 
>>> swift-corelibs-foundation up-to-date, including:
>>> 
>>>  * new value types (SE-0069)
>>>  * new names for API and NS-dropping changes (SE-0086)
>>>  * new tests (mostly part of the overlay, not all merged to corelibs yet)
>>> 
>>> We plan to post later today a branch (name forthcoming) to the 
>>> swift-corelibs-foundation repository that contains the first version of all 
>>> of these changes. We’ve also been merging all of the other changes from 
>>> master branch.
>>> 
>>> It’s not quite ready to merge back to master yet, so we would appreciate 
>>> your help! Check out the branch, look for errors or omissions, and submit 
>>> some PRs or send mail to this list.
>>> 
>>> Our hope is to merge this branch very quickly, in the span of a week or two 
>>> at most. We will likely need to get some parallel PRs up for XCTest and 
>>> swiftpm to help them adapt to the new name and type changes. 
>>> 
>>> Thanks!
>>> - Tony
>>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> --
> www.lukehoward.com 
> soundcloud.com/lukehoward
> 
> ___
> 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