SR-122 / CollectionsMoveIndices.swift Prototype

Austin · February 22, 2016, 6:34pm

I copy-pasted the prototype code into Collections.swift (commenting
out the old code),

Request: don't comment out old code; it just makes a mess and makes
changesets harder to analyze. The old code is still available; that's
what Git is for.

Of course, you mentioned this before. I'll make sure it goes away.

renamed the types that conflicted with the naming guidelines, and am
going through the errors one at a time to get the project into a
buildable state. This might take a few more days. Let me know if there
are any objections to this approach.

None whatsoever. If you can push your WIP to some publicly-visible
repository, maybe you could find a way to share the effort of fixing
errors with Shawn...?

I'll push what I have to my local repo, but it's a very brute-force approach. Like Shawn, I don't know if this is the *best* way; if necessary we can go with his more methodical approach.

Austin

···

On Feb 22, 2016, at 7:54 AM, Dave Abrahams <dabrahams@apple.com> wrote:
on Sun Feb 21 2016, Austin Zheng <austinzheng-AT-gmail.com <http://austinzheng-at-gmail.com/>> wrote:

Austin

On Feb 21, 2016, at 6:21 PM, Dave Abrahams <dabrahams@apple.com> wrote:

Until we open commit access, they still need one or more repos to
push to and create PRs from. Seems better for them to have an org
repo for that so other collaborators have a centralized place to go
for the latest non-integrated work.

Sent from my moss-covered three-handled family gradunza

On Feb 21, 2016, at 5:34 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Hi Dmitri (et al),

I have no personal objection to pull requests. If PRs directly to
the Swift project are the best way to do things, let's keep it that
way.

Austin

On Feb 21, 2016, at 5:24 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Sun, Feb 21, 2016 at 12:13 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Agreed. I created a GitHub organization
('swift-stdlib-opensource-collaborators'), and will try to invite the
non-Apple ('outsider') folks to join. Once that's happened, maybe Shawn can
move his fork under the organization, or one of us can fork the repo again.

Hi Austin, Shawn,

We're still working out the general policy for commit access for
non-Apple contributors.

I'm trying to understand the situation better -- could you explain why
pull requests present too much overhead for this project? Many Apple
engineers who have commit access find that the pull request approach
works better for their day-to-day work.

My concern is that doing this work in a parallel organization hides
this project from other contributors who might be interested. Also,
you would only get CI coverage in the primary Swift organization. In
general, creating a parallel organization sends an ambiguous message
to other people working on the project.

Furthermore, even Shawn started his work on this project with a pull
request against his fork (https://github.com/shawnce/swift/pull/1\).

Could we start with pull requests against the swift-3-indexing-model
branch in the primary repository, and possibly move to direct commits
later?

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
-Dave

gribozavr · March 11, 2016, 6:48am

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and addressing
TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

Dmitri

···

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Austin · February 22, 2016, 6:42pm

What I have can be found here. All the TODOs will eventually be removed: https://github.com/austinzheng/swift/commit/950e49268b37ca9b0a9643834e8d877b90759971

I must leave for work now, but welcome any comments etc.

Austin

···

On Feb 22, 2016, at 10:34 AM, Austin Zheng <austinzheng@gmail.com> wrote:

On Feb 22, 2016, at 7:54 AM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

on Sun Feb 21 2016, Austin Zheng <austinzheng-AT-gmail.com <http://austinzheng-at-gmail.com/>> wrote:

I copy-pasted the prototype code into Collections.swift (commenting
out the old code),

Request: don't comment out old code; it just makes a mess and makes
changesets harder to analyze. The old code is still available; that's
what Git is for.

Of course, you mentioned this before. I'll make sure it goes away.

renamed the types that conflicted with the naming guidelines, and am
going through the errors one at a time to get the project into a
buildable state. This might take a few more days. Let me know if there
are any objections to this approach.

None whatsoever. If you can push your WIP to some publicly-visible
repository, maybe you could find a way to share the effort of fixing
errors with Shawn...?

I'll push what I have to my local repo, but it's a very brute-force approach. Like Shawn, I don't know if this is the *best* way; if necessary we can go with his more methodical approach.

Austin

Austin

On Feb 21, 2016, at 6:21 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

Until we open commit access, they still need one or more repos to
push to and create PRs from. Seems better for them to have an org
repo for that so other collaborators have a centralized place to go
for the latest non-integrated work.

Sent from my moss-covered three-handled family gradunza

On Feb 21, 2016, at 5:34 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

Hi Dmitri (et al),

I have no personal objection to pull requests. If PRs directly to
the Swift project are the best way to do things, let's keep it that
way.

Austin

On Feb 21, 2016, at 5:24 PM, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:

On Sun, Feb 21, 2016 at 12:13 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

Agreed. I created a GitHub organization
('swift-stdlib-opensource-collaborators'), and will try to invite the
non-Apple ('outsider') folks to join. Once that's happened, maybe Shawn can
move his fork under the organization, or one of us can fork the repo again.

Hi Austin, Shawn,

We're still working out the general policy for commit access for
non-Apple contributors.

I'm trying to understand the situation better -- could you explain why
pull requests present too much overhead for this project? Many Apple
engineers who have commit access find that the pull request approach
works better for their day-to-day work.

My concern is that doing this work in a parallel organization hides
this project from other contributors who might be interested. Also,
you would only get CI coverage in the primary Swift organization. In
general, creating a parallel organization sends an ambiguous message
to other people working on the project.

Furthermore, even Shawn started his work on this project with a pull
request against his fork (https://github.com/shawnce/swift/pull/1\).

Could we start with pull requests against the swift-3-indexing-model
branch in the primary repository, and possibly move to direct commits
later?

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/

--
-Dave

Austin · March 11, 2016, 6:50am

Great work! I'll take a closer look this weekend. Sorry for not being involved at all this past week(s).

Austin

···

On Mar 10, 2016, at 10:48 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and addressing
TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Shawn_Erickson · March 14, 2016, 6:57pm

Is their a reason we are suppressing sort in place for MutableCollections?

benchmark/single-source/StaticArray.swift:86:17: error: 'sort()' has been
renamed to 'sorted'
    staticArray.sort()
                ^~~~
                sorted
Swift.MutableCollection:3:17: note: 'sort()' has been explicitly marked
unavailable here
    public func sort() -> [Self.Iterator.Element]
                ^

In CollectionAlgorithms we have `sortInPlace` marked as unavailable renamed
to `sort` and `sort -> [Iterator.Element]` marked as unavailable renamed
`sorted`.

I believe we want `sort()` to be the mutating one (in place) and `sorted()`
to return a sorted version, right? I poke around more on this. It could be
we have an overzealous unavailable?

···

On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and addressing
TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

----------
extension MutableCollection
  where
  Self : RandomAccessCollection,
  Self.Iterator.Element : Comparable {

  @available(*, unavailable, renamed="sort")
  public mutating func sortInPlace() {
    fatalError("unavailable function can't be called")
  }
}

extension MutableCollection where Self.Iterator.Element : Comparable {
  @available(*, unavailable, renamed="sorted")
  public func sort() -> [Iterator.Element] {
    fatalError("unavailable function can't be called")
  }

  @available(*, unavailable, renamed="sorted(isOrderedBefore:)")
  public func sort(
    @noescape isOrderedBefore: (Iterator.Element, Iterator.Element) -> Bool
  ) -> [Iterator.Element] {
    fatalError("unavailable function can't be called")
  }
}
-----------

Shawn_Erickson · March 15, 2016, 2:59am

FYI

I am working on the following:

FAIL: Swift :: 1_stdlib/StringDiagnostics.swift
FAIL: Swift :: 1_stdlib/StringDiagnostics_without_Foundation.swift
...and looking at converting String.XxxxIndexes to the new index style
while maintaining existing public API.

-Shawn

···

On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and addressing
TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

Shawn_Erickson · February 23, 2016, 1:08am

Austin I made some progress on bring together our efforts. The following
pull request outlines the changes so far. I will keep at it so the PR may
change some before I finally deliver it into my
fork's swift-3-indexing-model branch.

https://github.com/shawnce/swift/pull/3

-Shawn

···

On Mon, Feb 22, 2016 at 1:31 PM Austin Zheng <austinzheng@gmail.com> wrote:

Sounds good, thanks for adding me to the repo. If you have more time than
me and are itching to get moving, I'm also happy to let you take the lead -
LMK what you prefer. In any case I'm going to spend some time reading code
and understanding the specifics of the new collections system better.

Austin

On Mon, Feb 22, 2016 at 1:18 PM, Shawn Erickson <shawnce@gmail.com> wrote:

OK I am made the command decision to proceed on merging what Austin has
done and what I have done so far. I decided to pull Austin's work onto the "swift-3-indexing-model-az1"
branch in my fork https://github.com/shawnce/swift/\. I will work this
afternoon on bringing my branch and his branch closer together.

I added Austin as a collaborator in my fork for now and I will add the
known Apple folks just incase you want to work in our temporary sandbox.

I will keep branches in my fork synced with the upstream branches from
apple/swift as we progress. At some point when things are less broken a PR
can be used to move WIP up to apple/swift.

Let me know if you have an concerns.

-Shawn

On Mon, Feb 22, 2016 at 10:42 AM Austin Zheng <austinzheng@gmail.com> >> wrote:

What I have can be found here. All the TODOs will eventually be removed:
https://github.com/austinzheng/swift/commit/950e49268b37ca9b0a9643834e8d877b90759971

I must leave for work now, but welcome any comments etc.

Austin

On Feb 22, 2016, at 10:34 AM, Austin Zheng <austinzheng@gmail.com> >>> wrote:

On Feb 22, 2016, at 7:54 AM, Dave Abrahams <dabrahams@apple.com> wrote:

on Sun Feb 21 2016, Austin Zheng <austinzheng-AT-gmail.com >>> <http://austinzheng-at-gmail.com/>> wrote:

I copy-pasted the prototype code into Collections.swift (commenting
out the old code),

Request: don't comment out old code; it just makes a mess and makes
changesets harder to analyze. The old code is still available; that's
what Git is for.

Of course, you mentioned this before. I'll make sure it goes away.

renamed the types that conflicted with the naming guidelines, and am
going through the errors one at a time to get the project into a
buildable state. This might take a few more days. Let me know if there
are any objections to this approach.

None whatsoever. If you can push your WIP to some publicly-visible
repository, maybe you could find a way to share the effort of fixing
errors with Shawn...?

I'll push what I have to my local repo, but it's a very brute-force
approach. Like Shawn, I don't know if this is the *best* way; if necessary
we can go with his more methodical approach.

Austin

Austin

On Feb 21, 2016, at 6:21 PM, Dave Abrahams <dabrahams@apple.com> wrote:

Until we open commit access, they still need one or more repos to
push to and create PRs from. Seems better for them to have an org
repo for that so other collaborators have a centralized place to go
for the latest non-integrated work.

Sent from my moss-covered three-handled family gradunza

On Feb 21, 2016, at 5:34 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Hi Dmitri (et al),

I have no personal objection to pull requests. If PRs directly to
the Swift project are the best way to do things, let's keep it that
way.

Austin

On Feb 21, 2016, at 5:24 PM, Dmitri Gribenko <gribozavr@gmail.com> >>> wrote:

On Sun, Feb 21, 2016 at 12:13 PM, Austin Zheng <austinzheng@gmail.com> >>> wrote:

Agreed. I created a GitHub organization
('swift-stdlib-opensource-collaborators'), and will try to invite the
non-Apple ('outsider') folks to join. Once that's happened, maybe Shawn
can
move his fork under the organization, or one of us can fork the repo
again.

Hi Austin, Shawn,

We're still working out the general policy for commit access for
non-Apple contributors.

I'm trying to understand the situation better -- could you explain why
pull requests present too much overhead for this project? Many Apple
engineers who have commit access find that the pull request approach
works better for their day-to-day work.

My concern is that doing this work in a parallel organization hides
this project from other contributors who might be interested. Also,
you would only get CI coverage in the primary Swift organization. In
general, creating a parallel organization sends an ambiguous message
to other people working on the project.

Furthermore, even Shawn started his work on this project with a pull
request against his fork (https://github.com/shawnce/swift/pull/1\).

Could we start with pull requests against the swift-3-indexing-model
branch in the primary repository, and possibly move to direct commits
later?

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
-Dave

jrose · March 11, 2016, 7:16pm

Nice work Shawn, Austin, Dmitri!

Jordan

···

On Mar 10, 2016, at 22:50 , Austin Zheng via swift-dev <swift-dev@swift.org> wrote:

Great work! I'll take a closer look this weekend. Sorry for not being involved at all this past week(s).

Austin

On Mar 10, 2016, at 10:48 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and addressing
TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

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

gribozavr · March 14, 2016, 7:50pm

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and addressing
TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

Is their a reason we are suppressing sort in place for MutableCollections?

No, that wasn't intentional.

benchmark/single-source/StaticArray.swift:86:17: error: 'sort()' has been
renamed to 'sorted'
    staticArray.sort()
                ^~~~
                sorted
Swift.MutableCollection:3:17: note: 'sort()' has been explicitly marked
unavailable here
    public func sort() -> [Self.Iterator.Element]
                ^

In CollectionAlgorithms we have `sortInPlace` marked as unavailable renamed
to `sort` and `sort -> [Iterator.Element]` marked as unavailable renamed
`sorted`.

I believe we want `sort()` to be the mutating one (in place) and `sorted()`
to return a sorted version, right? I poke around more on this. It could be
we have an overzealous unavailable?

I think that's right. There is a mutating implementation already in
CollectionAlgorithms.swift.gyb, which is followed by an unavailable
one with a renamed clause. I think we should remove the unavailable
one.

Dmitri

···

On Mon, Mar 14, 2016 at 11:57 AM, Shawn Erickson <shawnce@gmail.com> wrote:

On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> > wrote:

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

gribozavr · March 15, 2016, 8:38am

There doesn't seem to be many tests actively failing in the primary
testsuite, so I'll be working on making StdlibCollectionUnittest
compile, which will allow us to run the validation testsuite.

Dmitri

···

On Mon, Mar 14, 2016 at 7:59 PM, Shawn Erickson <shawnce@gmail.com> wrote:

On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> > wrote:

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and addressing
TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

FYI

I am working on the following:

FAIL: Swift :: 1_stdlib/StringDiagnostics.swift
FAIL: Swift :: 1_stdlib/StringDiagnostics_without_Foundation.swift
...and looking at converting String.XxxxIndexes to the new index style while
maintaining existing public API.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Shawn_Erickson · March 21, 2016, 6:39pm

Anything I can help with on this effort? It looks like things are moving
along among the Apple folks. Not sure how to jump in without stepping on in
flight work, etc.

···

On Tue, Mar 15, 2016 at 1:39 AM Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Mar 14, 2016 at 7:59 PM, Shawn Erickson <shawnce@gmail.com> wrote:
>
>
> On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> > > wrote:
>>
>> Hi everyone,
>>
>> I just wanted to announce that we have sufficient change on the
>> swift-3-indexing-model branch so that we can build the core standard
>> library and StdlibUnittest. We achieved this by putting the protocol
>> new structure into place, and stubbing out with fatalError() or just
>> commenting out parts that didn't compile. Now we have a baseline that
>> we won't regress, and we are starting to work towards improving it,
>> making existing tests pass, and then writing new tests, and addressing
>> TODOs and FIXMEs that we left in the code as we were doing the first
>> pass.
>>
>> Here's the most recent pull request from Shawn where he starts to fix
>> the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub
>>
>> Now we are in the "massively-parallel" stage of this project and we,
>> as always, welcome contributions to this branch!
>
>
> FYI
>
> I am working on the following:
>
> FAIL: Swift :: 1_stdlib/StringDiagnostics.swift
> FAIL: Swift :: 1_stdlib/StringDiagnostics_without_Foundation.swift
> ...and looking at converting String.XxxxIndexes to the new index style
while
> maintaining existing public API.

There doesn't seem to be many tests actively failing in the primary
testsuite, so I'll be working on making StdlibCollectionUnittest
compile, which will allow us to run the validation testsuite.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Shawn_Erickson · February 25, 2016, 2:51am

So I have made some progress on things.

The first PR has been pulled in Apple's branch...
https://github.com/apple/swift/pull/1413

The second PR is a work in progress...
https://github.com/apple/swift/pull/1418

Things compile but many tests are failing because of purposely added
fatalError markers in the code.

I am at a point that it is becoming more difficult to keep things compiling
(I can still make some more progress however). Soon it looks like more of
the prototype needs to be integrated into / replace existing code. Also a
few classes likely need to be rethought given these changes. I not fully
sure of these aspects at this time.

I also see a good amount of change taking place related to API naming that
will/is conflict with change I need to make. It may make sense to pause for
a bit while more of that gets worked out (at least in some areas).

Anyway I need to head out of town for a couple of days and likely won't
have much time to make progress on this as a result.

-Shawn

Austin · April 11, 2016, 5:04am

I'm really sorry for dropping the ball and disappearing off the list. I'd
like to help out if I can. I'll check out the current branch tomorrow and
see what the status of the work is, but let me know if everything is done
already/there's something in particular that should be worked on.

Austin

···

On Mon, Mar 21, 2016 at 11:39 AM, Shawn Erickson <shawnce@gmail.com> wrote:

Anything I can help with on this effort? It looks like things are moving
along among the Apple folks. Not sure how to jump in without stepping on in
flight work, etc.

On Tue, Mar 15, 2016 at 1:39 AM Dmitri Gribenko <gribozavr@gmail.com> > wrote:

On Mon, Mar 14, 2016 at 7:59 PM, Shawn Erickson <shawnce@gmail.com> >> wrote:
>
>
> On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> >> > wrote:
>>
>> Hi everyone,
>>
>> I just wanted to announce that we have sufficient change on the
>> swift-3-indexing-model branch so that we can build the core standard
>> library and StdlibUnittest. We achieved this by putting the protocol
>> new structure into place, and stubbing out with fatalError() or just
>> commenting out parts that didn't compile. Now we have a baseline that
>> we won't regress, and we are starting to work towards improving it,
>> making existing tests pass, and then writing new tests, and addressing
>> TODOs and FIXMEs that we left in the code as we were doing the first
>> pass.
>>
>> Here's the most recent pull request from Shawn where he starts to fix
>> the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub
>>
>> Now we are in the "massively-parallel" stage of this project and we,
>> as always, welcome contributions to this branch!
>
>
> FYI
>
> I am working on the following:
>
> FAIL: Swift :: 1_stdlib/StringDiagnostics.swift
> FAIL: Swift :: 1_stdlib/StringDiagnostics_without_Foundation.swift
> ...and looking at converting String.XxxxIndexes to the new index style
while
> maintaining existing public API.

There doesn't seem to be many tests actively failing in the primary
testsuite, so I'll be working on making StdlibCollectionUnittest
compile, which will allow us to run the validation testsuite.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

dabrahams · February 25, 2016, 8:54pm

So I have made some progress on things.

The first PR has been pulled in Apple's branch...
[stdlib] - overlaying new index model on existing Collection by shawnce · Pull Request #1413 · apple/swift · GitHub

The second PR is a work in progress...
[stdlib] - WIP replacing aspects of ForwardIndex with those from Collection by shawnce · Pull Request #1418 · apple/swift · GitHub

Things compile but many tests are failing because of purposely added
fatalError markers in the code.

I am at a point that it is becoming more difficult to keep things compiling
(I can still make some more progress however). Soon it looks like more of
the prototype needs to be integrated into / replace existing code. Also a
few classes likely need to be rethought given these changes. I not fully
sure of these aspects at this time.

I also see a good amount of change taking place related to API naming that
will/is conflict with change I need to make. It may make sense to pause for
a bit while more of that gets worked out (at least in some areas).

That should be settling down in the next day.

Anyway I need to head out of town for a couple of days and likely won't
have much time to make progress on this as a result.

Thanks for all your work to date!

···

on Wed Feb 24 2016, Shawn Erickson <shawnce-AT-gmail.com> wrote:

--
-Dave

dabrahams · April 11, 2016, 6:07pm

I'm really sorry for dropping the ball and disappearing off the list. I'd like
to help out if I can. I'll check out the current branch tomorrow and see what
the status of the work is, but let me know if everything is done already/there's
something in particular that should be worked on.

Dmitri may have other ideas, but one thing we haven't done is to take
advantage of the new model by removing references from indices. I'd
like to prove that the new model does what it's supposed to. You might
try simplifying the indices for Set and Dictionary. It should be
possible to represent them as a wrapper around an Int.

···

on Sun Apr 10 2016, Austin Zheng <austinzheng-AT-gmail.com> wrote:

Austin

On Mon, Mar 21, 2016 at 11:39 AM, Shawn Erickson <shawnce@gmail.com> wrote:

    Anything I can help with on this effort? It looks like things are moving
    along among the Apple folks. Not sure how to jump in without stepping on in
    flight work, etc.

    On Tue, Mar 15, 2016 at 1:39 AM Dmitri Gribenko <gribozavr@gmail.com> wrote:

    On Mon, Mar 14, 2016 at 7:59 PM, Shawn Erickson <shawnce@gmail.com> wrote:
        >
        >
        > On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> > > wrote:
        >>
        >> Hi everyone,
        >>
        >> I just wanted to announce that we have sufficient change on the
        >> swift-3-indexing-model branch so that we can build the core standard
        >> library and StdlibUnittest. We achieved this by putting the protocol
        >> new structure into place, and stubbing out with fatalError() or just
        >> commenting out parts that didn't compile. Now we have a baseline that
        >> we won't regress, and we are starting to work towards improving it,
        >> making existing tests pass, and then writing new tests, and
        addressing
        >> TODOs and FIXMEs that we left in the code as we were doing the first
        >> pass.
        >>
        >> Here's the most recent pull request from Shawn where he starts to fix
        >> the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub
        >>
        >> Now we are in the "massively-parallel" stage of this project and we,
        >> as always, welcome contributions to this branch!
        >
        >
        > FYI
        >
        > I am working on the following:
        >
        > FAIL: Swift :: 1_stdlib/StringDiagnostics.swift
        > FAIL: Swift :: 1_stdlib/StringDiagnostics_without_Foundation.swift
        > ...and looking at converting String.XxxxIndexes to the new index style
        while
        > maintaining existing public API.

        There doesn't seem to be many tests actively failing in the primary
        testsuite, so I'll be working on making StdlibCollectionUnittest
        compile, which will allow us to run the validation testsuite.

        Dmitri

        --
        main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
        (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
Dave

Austin · February 25, 2016, 9:48pm

This is great stuff. Shawn, do you have any objections to me picking up
your stuff and continuing while you're out of town?

Austin

···

On Thu, Feb 25, 2016 at 12:54 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed Feb 24 2016, Shawn Erickson <shawnce-AT-gmail.com> wrote:

> So I have made some progress on things.
>
> The first PR has been pulled in Apple's branch...
> [stdlib] - overlaying new index model on existing Collection by shawnce · Pull Request #1413 · apple/swift · GitHub
>
> The second PR is a work in progress...
> [stdlib] - WIP replacing aspects of ForwardIndex with those from Collection by shawnce · Pull Request #1418 · apple/swift · GitHub
>
> Things compile but many tests are failing because of purposely added
> fatalError markers in the code.
>
> I am at a point that it is becoming more difficult to keep things
compiling
> (I can still make some more progress however). Soon it looks like more of
> the prototype needs to be integrated into / replace existing code. Also a
> few classes likely need to be rethought given these changes. I not fully
> sure of these aspects at this time.
>
> I also see a good amount of change taking place related to API naming
that
> will/is conflict with change I need to make. It may make sense to pause
for
> a bit while more of that gets worked out (at least in some areas).

That should be settling down in the next day.

> Anyway I need to head out of town for a couple of days and likely won't
> have much time to make progress on this as a result.

Thanks for all your work to date!

--
-Dave

Shawn_Erickson · March 1, 2016, 11:33pm

I am back and starting to work on this effort again.

I think it may be time to get swift/swift-3-indexing-model branch in
Apple's repo updated to the latest stable from swift-3-api-guidelines. I
can then merge the latest into my changes.

Also it may be time to see if the following two branches of llvm and clang
that I have been using are still up-to-date enough. Things appear to be
working but just wondering if I am missing out on some improvements, etc.

--- Updating '/Users/shawnce/Documents/Development/apple_swift/llvm' ---
Current branch swift-3-indexing-model is up to date.
--- Updating '/Users/shawnce/Documents/Development/apple_swift/clang' ---
Current branch swift-3-indexing-model is up to date.

I will need help of Apple folks to get these branches moved forward (likely
cleaner then me doing that in forks of my own).

Austin · April 11, 2016, 6:11pm

Excellent! I'll begin working on this today.

Austin

···

On Apr 11, 2016, at 11:07 AM, Dave Abrahams <dabrahams@apple.com> wrote:

on Sun Apr 10 2016, Austin Zheng <austinzheng-AT-gmail.com <http://austinzheng-at-gmail.com/>> wrote:

I'm really sorry for dropping the ball and disappearing off the list. I'd like
to help out if I can. I'll check out the current branch tomorrow and see what
the status of the work is, but let me know if everything is done already/there's
something in particular that should be worked on.

Dmitri may have other ideas, but one thing we haven't done is to take
advantage of the new model by removing references from indices. I'd
like to prove that the new model does what it's supposed to. You might
try simplifying the indices for Set and Dictionary. It should be
possible to represent them as a wrapper around an Int.

Austin

On Mon, Mar 21, 2016 at 11:39 AM, Shawn Erickson <shawnce@gmail.com> wrote:

   Anything I can help with on this effort? It looks like things are moving
   along among the Apple folks. Not sure how to jump in without stepping on in
   flight work, etc.

   On Tue, Mar 15, 2016 at 1:39 AM Dmitri Gribenko <gribozavr@gmail.com> wrote:

   On Mon, Mar 14, 2016 at 7:59 PM, Shawn Erickson <shawnce@gmail.com> wrote:

On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko <gribozavr@gmail.com> >>> wrote:

Hi everyone,

I just wanted to announce that we have sufficient change on the
swift-3-indexing-model branch so that we can build the core standard
library and StdlibUnittest. We achieved this by putting the protocol
new structure into place, and stubbing out with fatalError() or just
commenting out parts that didn't compile. Now we have a baseline that
we won't regress, and we are starting to work towards improving it,
making existing tests pass, and then writing new tests, and

       addressing

TODOs and FIXMEs that we left in the code as we were doing the first
pass.

Here's the most recent pull request from Shawn where he starts to fix
the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub

Now we are in the "massively-parallel" stage of this project and we,
as always, welcome contributions to this branch!

FYI

I am working on the following:

FAIL: Swift :: 1_stdlib/StringDiagnostics.swift
FAIL: Swift :: 1_stdlib/StringDiagnostics_without_Foundation.swift
...and looking at converting String.XxxxIndexes to the new index style

       while

maintaining existing public API.

       There doesn't seem to be many tests actively failing in the primary
       testsuite, so I'll be working on making StdlibCollectionUnittest
       compile, which will allow us to run the validation testsuite.

       Dmitri

       --
       main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
       (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

--
Dave

gribozavr · April 11, 2016, 6:15pm

String could also make use of such simplification.

Another important task is writing tests for new APIs, such as range
APIs and collection APIs.

Dmitri

···

On Mon, Apr 11, 2016 at 11:07 AM, Dave Abrahams <dabrahams@apple.com> wrote:

on Sun Apr 10 2016, Austin Zheng <austinzheng-AT-gmail.com> wrote:

I'm really sorry for dropping the ball and disappearing off the list. I'd like
to help out if I can. I'll check out the current branch tomorrow and see what
the status of the work is, but let me know if everything is done already/there's
something in particular that should be worked on.

Dmitri may have other ideas, but one thing we haven't done is to take
advantage of the new model by removing references from indices. I'd
like to prove that the new model does what it's supposed to. You might
try simplifying the indices for Set and Dictionary. It should be
possible to represent them as a wrapper around an Int.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Shawn_Erickson · April 11, 2016, 6:15pm

Anything to attempt on strings? I see you are considering consolidating
down to a single index type for those, etc. Of course you also imply a
large string rework that may happen in the future.

-Shawn

···

On Mon, Apr 11, 2016 at 11:07 AM Dave Abrahams <dabrahams@apple.com> wrote:

on Sun Apr 10 2016, Austin Zheng <austinzheng-AT-gmail.com> wrote:

> I'm really sorry for dropping the ball and disappearing off the list.
I'd like
> to help out if I can. I'll check out the current branch tomorrow and see
what
> the status of the work is, but let me know if everything is done
already/there's
> something in particular that should be worked on.

Dmitri may have other ideas, but one thing we haven't done is to take
advantage of the new model by removing references from indices. I'd
like to prove that the new model does what it's supposed to. You might
try simplifying the indices for Set and Dictionary. It should be
possible to represent them as a wrapper around an Int.

>
>
> Austin
>
> On Mon, Mar 21, 2016 at 11:39 AM, Shawn Erickson <shawnce@gmail.com> > wrote:
>
> Anything I can help with on this effort? It looks like things are
moving
> along among the Apple folks. Not sure how to jump in without
stepping on in
> flight work, etc.
>
> On Tue, Mar 15, 2016 at 1:39 AM Dmitri Gribenko <gribozavr@gmail.com> > wrote:
>
> On Mon, Mar 14, 2016 at 7:59 PM, Shawn Erickson <shawnce@gmail.com> > wrote:
> >
> >
> > On Thu, Mar 10, 2016 at 10:49 PM Dmitri Gribenko < > gribozavr@gmail.com> > > > wrote:
> >>
> >> Hi everyone,
> >>
> >> I just wanted to announce that we have sufficient change on
the
> >> swift-3-indexing-model branch so that we can build the core
standard
> >> library and StdlibUnittest. We achieved this by putting the
protocol
> >> new structure into place, and stubbing out with fatalError()
or just
> >> commenting out parts that didn't compile. Now we have a
baseline that
> >> we won't regress, and we are starting to work towards
improving it,
> >> making existing tests pass, and then writing new tests, and
> addressing
> >> TODOs and FIXMEs that we left in the code as we were doing
the first
> >> pass.
> >>
> >> Here's the most recent pull request from Shawn where he
starts to fix
> >> the tests: WIP - New indexing model: fixed compile issues in various stdlib tests, mor… by shawnce · Pull Request #1632 · apple/swift · GitHub
> >>
> >> Now we are in the "massively-parallel" stage of this project
and we,
> >> as always, welcome contributions to this branch!
> >
> >
> > FYI
> >
> > I am working on the following:
> >
> > FAIL: Swift :: 1_stdlib/StringDiagnostics.swift
> > FAIL: Swift ::
1_stdlib/StringDiagnostics_without_Foundation.swift
> > ...and looking at converting String.XxxxIndexes to the new
index style
> while
> > maintaining existing public API.
>
> There doesn't seem to be many tests actively failing in the
primary
> testsuite, so I'll be working on making StdlibCollectionUnittest
> compile, which will allow us to run the validation testsuite.
>
> Dmitri
>
> --
>
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com
>*/
>

--
Dave