Document intended process for tracking upstream changes

[Shawn Morel]

Sorry if this question has been asked before, I couldn't find any obvious answer.

This is a multi-part question around the development process as swift TF matures.

1) It would be really helpful to know which branch the swift tensor flow is currently rebased on and general development process surrounding that. I wouldn't expect anything as strong as a promise that it will always be this way, just the current state of the world.

1.1) Additionally, it would be great if this information could be programmatically queried either via `swift --version` and `#if swift(>5.0) #elsif` style flags. The flags don't currently work in colab. When running locally, the version string doesn't include enough info e.g. is the build derived from the swift 5.0 release branch or somewhere prior in the development where the version string just happens to be 5.0?

2) Is there any intent to separate out usable libraries that don't depend directly on the compiler changes. The main one I have in mind is the Python interop which I'd love to use on its own once any required compiler and language changes are available.

3) What are the general thoughts on upstreaming language and compiler changes? I know this is way too early to think about how this process would work overall. The main thing I care about would be the ability to start building libraries (especially math and stats libraries) that could be shared across swift versions separate from if autodiff or call graph tracing is available. My secondary concern would be around managing the complexity of jumping between the mainline swift language and this variant as features diverge. Is there a path where some of the more proved out approaches in swift TF can be pulled into mainline swift through piecemeal evolution pitches?

thanks,

shawn

[Parker Schuh]

1) We try and be based on the most recent development snapshot. These appear to be cut regularly by swift. We're currently on: swift-DEVELOPMENT-SNAPSHOT-2018-11-16-a.

1.1) That is an interesting proposal. We make quite a few breaking compiler changes sometimes, so the numbers might be quite fine-grained. I think the real strategy is to handle this via upstreaming whatever we can.

2) See: https://github.com/pvieito/PythonKit. The compiler support is already available.

3) We certainly intend to upstream the features when they become stable. Dynamic callable has already been pushed upstream. I suspect an attempt will be made this year to start upstreaming differentiation.

--
You received this message because you are subscribed to the Google Groups "Swift for TensorFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swift+un...@tensorflow.org.

[Richard Wei]

Hi Shawn,

On Tue, Apr 2, 2019 at 10:39 AM Shawn Morel <shawn...@gmail.com> wrote:

Sorry if this question has been asked before, I couldn't find any obvious answer.

This is a multi-part question around the development process as swift TF matures.

1) It would be really helpful to know which branch the swift tensor flow is currently rebased on and general development process surrounding that. I wouldn't expect anything as strong as a promise that it will always be this way, just the current state of the world.

Our current toolchain is based off of DEVELOPMENT-SNAPSHOT-2018-11-26-a. Normally, we work on merging new changes into the tensorflow branch every week, but the amount of work varies. It's been a while since the last merge, and we are working to merge the latest master as soon as possible.

 

1.1) Additionally, it would be great if this information could be programmatically queried either via `swift --version` and `#if swift(>5.0) #elsif` style flags. The flags don't currently work in colab. When running locally, the version string doesn't include enough info e.g. is the build derived from the swift 5.0 release branch or somewhere prior in the development where the version string just happens to be 5.0?

That's a good suggestion. We can start to tag our toolchains with the tag of their base from master. Adding some information to `swift --version` also sounds reasonable to me.

 

2) Is there any intent to separate out usable libraries that don't depend directly on the compiler changes. The main one I have in mind is the Python interop which I'd love to use on its own once any required compiler and language changes are available.

Python interop is independent from TensorFlow support. There's an open source Swift package called PythonKit that provides all functionality of the Python module in Swift for TensorFlow. PythonKit and the Python module in Swift for TensorFlow are kept in sync by the maintainers.

 

3) What are the general thoughts on upstreaming language and compiler changes? I know this is way too early to think about how this process would work overall. The main thing I care about would be the ability to start building libraries (especially math and stats libraries) that could be shared across swift versions separate from if autodiff or call graph tracing is available. My secondary concern would be around managing the complexity of jumping between the mainline swift language and this variant as features diverge. Is there a path where some of the more proved out approaches in swift TF can be pulled into mainline swift through piecemeal evolution pitches?

I understand your concerns. We don't yet promise source compatibility in language extensions or APIs. This means that many numeric library extensions like `VectorNumeric`, `ShapedArray`, and `Differentiable` can change before they get propose and merged through Swift Evolution. As for the core language syntax/semantics, we don't have obvious extensions other than `@differentiable` functions and `@convetion(tensorflow)` functions (#tfop is an internal hack that doesn't really count), so I don't see a problem there.

Differentiable programming is closest feature to being ready for Swift Evolution and upstreaming, and we are actively working towards that. Just because of the complexity in both the conceptual model and the implementation, we've been carefully sorting out all the details for a successful Swift Evolution pitch.

What might make sense in the future is to base Swift for TensorFlow release packages off of a release version of Swift, so library builders can have a clear idea what features are available according to Swift's official release notes. However, it is not super practical right now, because we need to follow the master branch closely in engineering.

We will have a better answer to all of this later this year, once the AD proposal is out and TensorFlow APIs get moved from stdlib/public/TensorFlow to tensorflow/swift-apis.

-Richard

[Chris Lattner]

On Apr 2, 2019, at 11:51 AM, 'Richard Wei' via Swift for TensorFlow <sw...@tensorflow.org> wrote:

2) Is there any intent to separate out usable libraries that don't depend directly on the compiler changes. The main one I have in mind is the Python interop which I'd love to use on its own once any required compiler and language changes are available.

Python interop is independent from TensorFlow support. There's an open source Swift package called PythonKit that provides all functionality of the Python module in Swift for TensorFlow. PythonKit and the Python module in Swift for TensorFlow are kept in sync by the maintainers.

FWIW, I’d love to see this upstreamed to the main Swift.org repo.  The issue there is mostly procedural - I’m not sure if there is a framework for accepting this kind of project.  If someone has time to drive the discussion, I think this should just be brought up on the evolution forum as a question - what is the right thing to do here.

There isn’t clear precedent for this, but it is somewhat humorous that it was possible to get the language features to support Python interop in, but unclear how to get the 1KLOC library that uses it in :-)

-Chris

[Richard Wei]

Done. Started a discussion thread on the evolution forum, asking a few questions:

https://forums.swift.org/t/upstreaming-the-python-module/22577

-Richard