profile
viewpoint

tensorflow/models 61775

Models and examples built with TensorFlow

tensorflow/benchmarks 762

A benchmark framework for Tensorflow

annarev/benchmarks 0

Benchmark code

annarev/community 0

Stores documents used by the TensorFlow developer community

annarev/convnet-benchmarks 0

Easy benchmarking of all publicly accessible implementations of convnets

annarev/models 0

Models built with TensorFlow

annarev/tensorboard 0

TensorFlow's Visualization Toolkit

annarev/tensorflow 0

Computation using data flow graphs for scalable machine learning

push eventannarev/community

Anna Revinskaya

commit sha 6c8eb85efc547f04656639df85f3dc4eb844ebf3

Update rfcs/20191127-pip-structure.md Co-Authored-By: Gabriel de Marmiesse <gabrieldemarmiesse@gmail.com>

view details

push time in 10 days

Pull request review commenttensorflow/community

RFC: Standalone Keras Repository

+# Standalone Keras Repository++| Status        | Proposed |+:-------------- |:---------------------------------------------------- |+| **RFC #**     | [202](https://github.com/tensorflow/community/pull/202) |+| **Author(s)** | Qianli Zhu (scottzhu@google.com), Francois Chollet (fchollet@google.com) |+| **Sponsor**   | Karmel Allison (karmel@google.com) |+| **Updated**   | 2020-02-05                         |++## Objective++Move the Keras code from the TensorFlow main GitHub repository to its own+repository, with TensorFlow as a dependency.++## Motivation++### Build times++Building the open-source TensorFlow project end-to-end is an extensive exercise. +With a standard GCP instance, it might take more than one hour to finish the whole+build process (it might take longer with a Mac laptop). Although the local build +cache might help speed up the follow-up builds, the initial time cost is too +high for regular software development workflows. Internally, Google has a+distributed build and caching service, which Googlers heavily rely on,+that can build TensorFlow and run all Keras tests within 5 mins. Sadly,+we can't expose this to external contributors.++Currently, any contribution to Keras code will require building all of+TensorFlow, which is quite expensive to do for average users.+Having a separate repository will allow the Keras package to be built+without building TensorFlow. This should greatly improve the +velocity of open-source developers when they contribute to Keras code.++### Community Benefit++The difficulty of building TensorFlow from scratch in order to make a PR+to Keras code has been a significant source of issues:++* It discouraged contributions, since many external developers couldn't test+their changes and make sure they were correct.+* External developers would send unverified PRs, and Google reviewers spend time back +and forth, fixing the PR. Sometimes PR is just not moving forward because of the+lengthy feedback loop.++With the new standalone Keras repository, external contributors+should experience much shorter turn-around time when +building/testing Keras, since they don't need to build TensorFlow anymore.+This should  have a positive impact on building a vibrant open-source+developer community.++In addition, by getting the Keras team at Google to start developing Keras+using the same public tools and infrastructure as third-party developers,+we make the development process more transparent and more community-oriented.++### TensorFlow API modularity++There are other side-benefits if we split the repository. Currently, Keras+has to rely on a number of private TensorFlow APIs. However, a litmus test+of the quality of the public TensorFlow low-level APIs is that they should+be strictly sufficient to a higher-level API like Keras.+After splitting the repository, Keras will have to import TensorFlow and +rely exclusively on public APIs. If Keras still ends up using TensorFlow+private features, it  might be an indication of tight coupling of+implementation details. If certain private features are extensively used,+we might want to consider exposing them  as public low level API.++This design is also aligned with thee design for+[Modular TensorFlow](https://github.com/tensorflow/community/blob/master/rfcs/20190305-modular-tensorflow.md), +which splits the TensorFlow project into smaller components that are not+tightly coupled together.+++## Design Proposal++### New location of the code++GitHub: the code will live at [keras-team/keras](https://github.com/keras-team/keras), +joining the other Keras SIG projects and replacing the current external Keras +codebase. `tf.Keras` will also replace Keras on PyPI.++Also considered: `tensorflow/keras`.++| keras-team/keras   | tensorflow/keras |+:------------------- |:------------------------------------------- |+|Under the umbrella of Keras SIG, which hosts all other Keras related projects like keras-application, KerasTuner etc.|Under the umbrella of tensorflow, which also hosts other TF related projects.|+|Lots of existing followers on keras-team, who may not be easily migrated to TF project.|No cross org repo management cost on GitHub. Could rely on a lot of existing setup in TensorFlow.|+|Can't easily delete keras project, which already have tons of stars and incoming reference links. Continued existence of external Keras code will create confusion ("why is there tensorflow/keras AND keras-team/keras?")|Issue/PR under the same org can be transferred easily, but not cross the different org. See here|++### Source of Truth++TensorFlow uses a Google-internal code repository as its source of truth. Every PR+submitted though GitHub is converted to a Google-internal change first,+submitted through the internal system, and then copied to GitHub as commits.+At the same time, PR is marked as merged with the corresponding commit hash.++Likewise, issue tracking and code review takes place through Google-internal tools.++For Keras, since we are trying to promote community engagement, we hope to use +GitHub as source of truth. This will have the following implications:++* We expect the majority of the code development/contribution from GitHub+and the dev tools / tests / scripts should focus on the GitHub development use+case. See below for more details.+* Keras CI/presubmit build for the GitHub repo should target the `tf-nightly` pip+package as dependency. This means any change to TF will take at most 24+hours to be reflected on the Keras side.+* The Keras code will be mirrored to a Google-internal code repository via Google-internal +tools within a very short time window after each change.+The Google-internal CI tests will run on HEAD for both Keras and TF code.+* The CI build for the repository on GitHub might break when it sees a+new version of `tf-nightly`, if  certain behavior has been changed and wasn't+caught by unit tests. We have  observed a few similar cases with+[tf/addons](https://github.com/tensorflow/addons).+We hope this can be reduced by stronger+unit test coverage by Google internel systems, when both TF and Keras code are +tested at HEAD.+* pip package management. Keras will now follow the `tf-estimator` approach. +"pip install tensorflow" should also install Keras (from PyPI) as well.+There are more details for the pip package in the+[Improved pip package structure](https://github.com/tensorflow/community/pull/182) RFC.++### Dependency Cleanup++As the high-level API of TensorFlow, Keras should have a direct dependency on+TF low-level APIs, but not the other way around. Unfortunately, there is some existing reverse +logic in the TF code that relies on Keras, which we should update/remove +when we split the repository.++The current usage of Keras from TensorFlow are:+* Unit tests, which should be converted to integration tests, or port the tests+to Keras repository.+* `feature_column`.+* Legacy `tf.layers` in v1 API.+* legacy RNN cells.+* TPU support code for `optimizer_v2`.+* SavedModel.+* TF Lite.++All Keras imports in integration tests can be changed to use dynamic import like below:++```python+try:+   from tensorflow.python.keras.engine import base_layer+except ImportError:+   tf.logging.error('keras is not installed, please pip install keras')+   base_layer = None+```++### Update Keras to only use public TF APIs++The current Keras code will still work if we do e.g.:+```python+from tensorflow.python.ops import array_ops++ones = array_ops.ones([2, 3])+```++However, since Keras is a separate repository, having it only use TF +public APIs will heavily reduce the chance of breakage caused by relying+on private methods or implementation details. We think this point is+critial to the health of the project. This also allows TF to change internal +implementation details without worrying about breaking Keras.++The converted code should look like e.g.:++```python+import tensorflow as tf++ones = tf.ones([2, 3])+```++During this conversion, we might notice that certain TF features used in Keras are+not public. A decision should be made on a case-by-case basis:++* Copy the functionality from TF to Keras.+* Replace the usage with another alternative TF public API.+* Make the functionality a new TF public API.++**Note that the open-source community is encouraged to contribute to this effort.**++### Two-stage change process++For any change that is affecting both TensorFlow and Keras, the change+will need to be split into two, one as a PR to the TF repo,+and the other as a PR to the Keras repo. Here are some common scenarios:++1. Adding a new feature to TensorFlow, and having Keras rely on it. Note that the +TF change needs to be submitted first, and the Keras PR needs to wait for the new TF+nightly to become available on PyPI.++Also note that any rollback of the TF PR will cause Keras to break, the+rollback sequence should be PR 33333 and then PR 22222 (see example below).+The Google-internal test for TF should catch the error if the rollback sequence+is not correct.++```python+# Existing scenario.+# PR 11111 (2 files updated)+# +++ tensorflow/python/ops/array_ops.py+def some_new_function(inputs):+   ...++# +++ tensorflow/python/keras/layers/core.py++class new_layer(Layer):++  def call(inputs):+     array_ops.some_new_function(inputs)+     ...+```++```python+# New scenario.+# PR 22222 (1 file updated)+# +++ tensorflow/python/ops/array_ops.py+@tf.export('some_new_function')+def some_new_function(inputs):+   ...++==================================+# PR 33333 (1 file updated)+# +++ tensorflow/python/keras/layers/core.py++class new_layer(Layer):++  def call(inputs):+     tf.some_new_function(inputs)+     ...+```++2. Changing the behavior of an existing TF API.++Note that the PR 22222 needs to be submitted with both the new and old+function since Google internal CI is still testing from HEAD.+The previous function can be +deleted after PR 33333 is submitted. Also note that this issue is caused by +Keras not using exclusively public TF API, but relying on TF implementation details.+Moving towards only using public APIs should reduce the likelihood of this kind of issue.++```python+# Existing scenario.+# PR 11111 (2 files updated)+# tensorflow/python/ops/array_ops.py+<<<+def existing_function(inputs):+    ...+>>>+def new_function(inputs, knob1=False, knob2=1):+    ...+# tensorflow/python/keras/layers/core.py++class existing_layer(Layer):++  def call(inputs):+<<<+    array_ops.existing_function(inputs)+>>>+    array_ops.new_function(+        inputs, +        knob1=True,+        knob2=3)+```++```python+# New scenario.+# PR 22222 (1 file updated)+# tensorflow/python/ops/array_ops.py+<<<+def existing_function(inputs):+   ...+>>>+def existing_function(inputs):+  return new_function(+    inputs, +    knob1=False,+    knob2=1)++def new_function(inputs, knob1, knob2=1):+    ...++==================================+# PR 33333 (1 file updated)+# tensorflow/python/keras/layers/core.py+class existing_layer(Layer):++  def call(inputs):+<<<+    array_ops.existing_function(inputs)+     ...+>>>+    array_ops.new_function(+        inputs, +        knob1=True,+        knob2=3)+```+++### Performance Implications++There may be some performance implications as we move towards only using+public TF APIs. We need to maintain a benchmark to ensure that there+is no performance regression.++### Dependencies+

what @qlzh727 is right, I didn't mean to imply tensorflow_keras as the package name to use in my doc, just used it similarly with tensorflow_estimator.

qlzh727

comment created time in 10 days

pull request commenttensorflow/community

RFC: Improved pip package structure

Note that from tensorflow import keras issues have been fixed by this PR: https://github.com/tensorflow/tensorflow/pull/34629 from @lgeiger.

annarev

comment created time in 16 days

PullRequestEvent

PR closed tensorflow/community

Reviewers
RFC: Improved pip package structure RFC: Proposed cla: yes

Comment period is open until 2019-11-13

Improved pip package structure

Status Proposed
RFC # 182
Author(s) Anna Revinskaya (annarev@google.com)
Sponsor Alex Passos (apassos@tensorflow.org)
Updated 2019-11-27

Objective

We propose to simplify TensorFlow pip package structure to enable IDE features such as autocomplete, jump-to-definition and quick-documentation.

+204 -0

6 comments

5 changed files

annarev

pr closed time in 16 days

pull request commenttensorflow/community

RFC: Improved pip package structure

Ideally it should be a tree except the lazy-loaded edges. I see some from tensorflow_estimator references in python/tpu and python/estimator directories. My guess is these should be going away and were probably left from before estimator migration.

annarev

comment created time in 16 days

pull request commenttensorflow/community

RFC: Improved pip package structure

I think lazy loading is a good option. It is complicated by our current practice of testing which mixes cross-package integration tests with the rest. Otherwise it would not be unclean enough to bother me.

@martinwicke Do you have an example in mind when an integration test would fail because we use lazy-loading as opposed to adding tensorflow_core package?

Would these cases be resolved once estimator just depends on public APIs? I am guessing we can split up the tests if they still cause an issue then.

annarev

comment created time in 16 days

Pull request review commenttensorflow/community

RFC: Improved pip package structure

+# Title of RFC++| Status        | (Proposed / Accepted / Implemented / Obsolete)       |+:-------------- |:---------------------------------------------------- |+| **RFC #**     | [NNN](https://github.com/tensorflow/community/pull/NNN) (update when you have community PR #)|+| **Author(s)** | Anna Revinskaya (annarev@google.com)                 |+| **Sponsor**   | Alex Passos (apassos@tensorflow.org)                 |+| **Updated**   | 2019-11-27                                           |++## Objective++We propose to simplify TensorFlow pip package structure to enable IDE features such as autocomplete, jump-to-definition and quick-documentation.++## Motivation++### Current package structure+TensorFlow package structure has grown quite complex over time as we started to support multiple versions (1.x and 2.x) and import external sub-packages (such as tensorflow\_estimator and tensorboard). This complexity is expected to grow if we split out more components into separate pip packages.++Sources of complexity:++* Versioning: tensorflow\_core API lives under *_api/v1* or *_api/v2* directory depending on the version.+* Virtual pip package: Installing TensorFlow actually installs 2 directories: *tensorflow/* and *tensorflow\_core/* under *site-packages/*. TensorFlow code lives under *tensorflow\_core/*. TensorFlow uses lazy loading to import everything from *tensorflow\_core/* to *tensorflow/*. Two-directory structure helps work-around circular imports caused by tensorflow\_estimator.++Outline of the current structure:+```+tensorflow+    __init__.py (contains "from tensorflow_core import *")++tensorflow_core+    python/...+    lite/...+    _api/v2+        __init__.py+        audio/__init__.py+        autograph/__init__.py+        ...+```++### Rationale behind current package structure+#### Multiple version support+To prepare for TensorFlow 2.0 launch, we added a way to build two versions: 1.x and 2.x. Each version has its own respective genrule that outputs file for 1.x or 2.x since API modules are different (for e.g. *tensorflow/manip/\_\_init\_\_.py* only exists in 1.x and not 2.x API). Now, bazel does not allow two genrules to output files to the same directory. Therefore, we have *_api/v1/* and *_api/v2/* subdirectories.++Note that we could still place the API directly under *tensorflow/* in the pip package since a pip package contains a single version of TensorFlow. This option became out of reach when *tensorflow/contrib/lite/* was migrated to *tensorflow/lite/*. Now *tensorflow/lite/* API directory would conflict with *tensorflow/lite/* source directory if the API was under *tensorflow/* instead of *_api/vN/*.++#### Circular dependencies+Estimator depends on TensorFlow. At the same time, TensorFlow includes estimator as a part of its API. This creates a cycle.++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/circular_dependency.png "Circular dependency+between TensorFlow and Estimator.")++#### Metapackage vs base package plans+[Modular TensorFlow+RFC](https://github.com/tensorflow/community/blob/master/rfcs/20190305-modular-tensorflow.md) proposes to keep two pip packages:+tensorflow-base would only contain core TensorFlow (for e.g. no estimator).+TensorFlow Metapackage would be a thin package defining composition of TensorFlow which includes base, estimator, keras and tensorboard.+Note that this 2-package approach is not implemented yet. However, its proposal demonstrates how keeping a virtual pip package could be beneficial in the future.++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/modular_structure.png "Proposed modular TensorFlow structure.")++Current structure looks more like this (except *tensorflow/* and *tensorflow\_core/* are directories as opposed to separate pip packages) and meant to be the first step towards structure above:++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/current_structure.png "Current TensorFlow structure.")++### Current state of IDE code features++#### PyCharm 2019.1.1++* Autocomplete:+  * Works in most cases after switching to use relative imports.+  * Doesn’t work for tf.compat.v1.keras and tf.compat.v2.keras.+  * Doesn’t work for keras if importing it using from import (i.e. `from tensorflow import keras`).+* Jump-to-definition doesn’t work.+* Quick documentation doesn’t work.++#### PyCharms with 2019.3 EAP build 193.3793.14+Latest version of PyCharms added [custom handling for tensorflow](https://github.com/JetBrains/intellij-community/blob/0a08f8212351ee84d602cdc5547f038ce0df79fd/python/src/com/jetbrains/tensorFlow/PyTensorFlow.kt)+* Autocomplete works in most cases.+* Doesn’t work for keras if importing it using from import (i.e. `from tensorflow import keras`).+* Jump-to-definition works.+* Quick documentation works.++#### VS Code 1.40 (October 2019 release)+* Autocomplete:+  * Works in most cases.+  * Doesn’t work for `tf.estimator` or `tf.keras`.+  * Doesn’t work for `tf.compat.v1.keras` and `tf.compat.v2.keras`.+  * Doesn’t work for keras if importing it using from import (i.e. `from tensorflow import keras`).+* Jump-to-definition doesn’t work.+* Quick documentation doesn’t work.+++## User Benefit++TensorFlow package structure creates difficulties for those who use IDEs.+Autocomplete, quick documentation and jump-to-definition features often rely on+module structure matching directory structure. For example, TensorFlow code uses+`from tensorflow.foo` imports but lives under tensorflow\_core package. Simplifying+package structure would improve productivity for TensorFlow users.++## Design Proposal++The best way I can think of to fix the autocomplete issues is to make our package structure as clean as possible. In this case, autocomplete will work out of the box.++### Short term: Remove virtual pip package++Primary purpose of keeping the virtual pip package is to workaround circular+estimator imports. Alternatively, we can resolve this issue by lazy loading+estimator.++Lazy loading by itself would mean that we no longer have autocomplete for estimator. As a workaround, we can import estimator in the stub *.pyi* file.++Estimator import in root *\_\_init\_\_.py* file:+```python+from tensorflow.python.util.lazy_loader import LazyLoader as _LazyLoader+estimator = _LazyLoader(+    "estimator", globals(),+    "tensorflow_estimator.python.estimator.api._v2.estimator")+setattr(_current_module, "estimator", estimator)+```++Estimator import in root *\_\_init\_\_.pyi* file:+```python+from tensorflow_estimator.python.estimator.api._v2 import estimator as estimator+```+In Python 3, we don't even need the *.pyi* file and instead can import estimator+without lazy loading if `typing.TYPE_CHECKING` is `True`.++After building a pip package with this change all of the following work in PyCharms (both released and EAP) and VS Code:++* jump-to-definition+* quick documentation+* autocomplete for `compat.v1.keras`, `compat.v2.keras`+* autocomplete for keras when using from tensorflow import keras+* ...basically any import I tested works with autocompletion++To support the TensorFlow Metapackage plans we could add a new pip package that specifies dependencies on tensorflow, tensorflow\_estimator, tensorboard, etc.. Its sole purpose would be to get all dependencies installed.++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/new_modular_structure.png "New proposed modular TensorFlow structure.")++### Long term: Import from external package directly+Short term would fix IDE issues, but the package structure is still not as clean as it could be. We resolve cycles with lazy loading but it would be even better not to have this circular structure at all.++Therefore, I propose that we don’t import external packages into TensorFlow 3.0. Users who want to use estimator, tensorboard summaries or keras could import them separately:++Current code that looks like:+```python+import tensorflow as tf++tf.estimator+tf.keras+tf.summary+```++Would be changed to:+```python+import tensorflow as tf+import tensorflow_estimator as estimator+import tensorflow_keras as keras+from tenosorboard import summaries+```++Rationale for this change:++* One way dependencies (estimator depends on tensorflow and not vise-versa).+* Minimal overhead for users. Adding an extra import is easy.

The current plan is to make it possible to import from stand alone packages (for e.g. tensorflow_estimator and tensorflow_keras) but at the same time keep tf.estimator and tf.keras available through lazy loading.

annarev

comment created time in 16 days

Pull request review commenttensorflow/community

RFC: Improved pip package structure

+# Title of RFC++| Status        | (Proposed / Accepted / Implemented / Obsolete)       |+:-------------- |:---------------------------------------------------- |+| **RFC #**     | [NNN](https://github.com/tensorflow/community/pull/NNN) (update when you have community PR #)|+| **Author(s)** | Anna Revinskaya (annarev@google.com)                 |+| **Sponsor**   | Alex Passos (apassos@tensorflow.org)                 |+| **Updated**   | 2019-11-27                                           |++## Objective++We propose to simplify TensorFlow pip package structure to enable IDE features such as autocomplete, jump-to-definition and quick-documentation.

Sorry for not addressing this comment sooner. I just tried it out today. New version of PyCharms would give abstract class warning out of the box. The old version that I tested while writing this doc (2019.1.1) would not give the warning and the change proposed in this RFC would fix it.

I tried in VS Code where some autocomplete does not work (tf.compat.v1.keras.) but could not find abstractclass warning even if I define a sample repro example.

annarev

comment created time in 16 days

push eventannarev/community

Anna R

commit sha 55ed96bc92b17cb4647b4c1a440f47d0590ff8ed

Mark long term plan as optional, minor changes

view details

push time in 17 days

pull request commenttensorflow/tensorflow

Change TrtConversionParams to class from NamedTuple and export it

@annarev we have a case where ApiCompatibilityTest.testAPIBackwardsCompatibilityV2 is failing in google3 after the import but passing in open source. Any idea what's going on?

Sorry just saw the comment. Is this still an issue?

pooyadavoodi

comment created time in a month

push eventannarev/upb

Anna R

commit sha a27429f2652763ef957b50f30eb5a34ddfc38e88

Add port_def.inc and port_undef.inc to generated code hdrs

view details

push time in a month

push eventannarev/upb

Anna R

commit sha 3797ad2217740d82e9fb967f5f255f40cc16c351

port should not be public

view details

push time in a month

PR opened protocolbuffers/upb

Add port dependencies

Add :port dependencies to libraries that include it.

Also, I had to set port visibility to public, otherwise I see errors such as: target '//:port' is not visible from target '@com_google_protobuf//:field_mask_proto'

+18 -1

0 comment

3 changed files

pr created time in a month

push eventannarev/upb

Anna R

commit sha 578dc32208ec3a914b0cbe7e46eb2d71a43b3baa

Set port visibility to public.

view details

push time in a month

create barnchannarev/upb

branch : add_port_dependencies

created branch time in a month

pull request commenttensorflow/community

RFC: Improved pip package structure

Yes, it is ready for design review. There are still some things I wanted to test out following comments (unfortunately haven't gotten around to it). But it should be ok to have design review at this point.

annarev

comment created time in a month

push eventannarev/upb

Alan Wu

commit sha a73fd86c133b081709cb5311e70bbe47bb0e0d56

Use memcpy to perform unaligned reads Creating and reading from unaligned pointers is UB and I'm trying to run upb on a platform (GraalVM) that is sensitive to that unfortunately. Recent compilers are smart enough to fold the memcpy down to a simple memory load on platforms that support it, so this should mostly be a aesthetic change.

view details

Lizan Zhou

commit sha bcdfe6b1b01cd41ec2125d937f14e85c0a1b53d3

bazel: use canonical repository name for absl Signed-off-by: Lizan Zhou <lizan@tetrate.io>

view details

Anna R

commit sha 0b63c7516489f5562b055a07b62004c159595b2b

Do not strip :descriptor_upbreflection and make some headers public that are used outside of the their module

view details

Joshua Haberman

commit sha 47ab661706b10de6d4c2f45a575d4af81aac7eab

Merge pull request #227 from lizan/absl_workspace_name bazel: use canonical repository name for absl

view details

Joshua Haberman

commit sha abdf14937d5c5732fecabe4d4a92acb9c6eb7c92

Merge pull request #216 from XrXr/use-memcpy-to-do-unaligned-read Use memcpy to perform unaligned reads

view details

Anna R

commit sha de1bc11663702b04d068ea7fe0dabead2dc23959

Split port into its own target, add msg.h to :legacy_msg_reflection

view details

Anna R

commit sha d2389ba261e7e49a14f405be97c3ee0b689ce567

Add correctness asserts to upb_addmsg

view details

Joshua Haberman

commit sha 1b131ca5446da3b4c27071d85ee961797ee3daf8

Merge pull request #231 from annarev/fix_build_for_sync A few build fixes

view details

Joshua Haberman

commit sha 7d1abedbddc2ec5a393d1a32622f230265306a9a

Merge pull request #232 from annarev/forward_assert_changes Add correctness asserts to upb_addmsg

view details

push time in a month

delete branch annarev/upb

delete branch : forward_changes

delete time in a month

PR opened protocolbuffers/upb

Add correctness asserts to upb_addmsg

Forwarding @haberman 's change to add correctness asserts to upb_addmsg function in upb/decode.c.

+4 -0

0 comment

1 changed file

pr created time in a month

create barnchannarev/upb

branch : forward_assert_changes

created branch time in a month

create barnchannarev/upb

branch : forward_changes

created branch time in a month

push eventannarev/upb

Anna R

commit sha de1bc11663702b04d068ea7fe0dabead2dc23959

Split port into its own target, add msg.h to :legacy_msg_reflection

view details

push time in a month

PR opened protocolbuffers/upb

A few build fixes
  1. Do not strip upb:descriptor_upbreflection since it is used by upb:benchmark target.
  2. Move upb/msg.h, upb/port_def.inc, upb/port_undef.inc to hdrs since they are used outside of the :upb target (msg.h is used by third_party/upb/upb/msgfactory.h, port_def.inc and port_undef.inc are used by third_party/upb/upb/legacy_msg_reflection.h)
+8 -8

0 comment

1 changed file

pr created time in a month

create barnchannarev/upb

branch : fix_build_for_sync

created branch time in a month

fork annarev/upb

a small protobuf implementation in C

fork in a month

issue commenttensorflow/tensorflow

importing tensorflow inside a function/object causes a memory leak

It appears to be due to saving error when importing portpicker here: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/framework/test_util.py#L44

We can probably save the error text instead or import portpicker inside the function that creates a cluster.

rggjan

comment created time in 2 months

Pull request review commenttensorflow/community

RFC: Improved pip package structure

+# Title of RFC

Thank you for catching this, updated.

annarev

comment created time in 3 months

Pull request review commenttensorflow/community

RFC: Improved pip package structure

+# Title of RFC++| Status        | (Proposed / Accepted / Implemented / Obsolete)       |+:-------------- |:---------------------------------------------------- |+| **RFC #**     | [NNN](https://github.com/tensorflow/community/pull/NNN) (update when you have community PR #)|+| **Author(s)** | Anna Revinskaya (annarev@google.com)                 |+| **Sponsor**   | Alex Passos (apassos@tensorflow.org)                 |+| **Updated**   | 2019-11-27                                           |++## Objective++We propose to simplify TensorFlow pip package structure to enable IDE features such as autocomplete, jump-to-definition and quick-documentation.++## Motivation++### Current package structure+TensorFlow package structure has grown quite complex over time as we started to support multiple versions (1.x and 2.x) and import external sub-packages (such as tensorflow\_estimator and tensorboard). This complexity is expected to grow if we split out more components into separate pip packages.++Sources of complexity:++* Versioning: tensorflow\_core API lives under *_api/v1* or *_api/v2* directory depending on the version.+* Virtual pip package: Installing TensorFlow actually installs 2 directories: *tensorflow/* and *tensorflow\_core/* under *site-packages/*. TensorFlow code lives under *tensorflow\_core/*. TensorFlow uses lazy loading to import everything from *tensorflow\_core/* to *tensorflow/*. Two-directory structure helps work-around circular imports caused by tensorflow\_estimator.++Outline of the current structure:+```+tensorflow+    __init__.py (contains "from tensorflow_core import *")++tensorflow_core+    python/...+    lite/...+    _api/v2+        __init__.py+        audio/__init__.py+        autograph/__init__.py+        ...+```++### Rationale behind current package structure+#### Multiple version support+To prepare for TensorFlow 2.0 launch, we added a way to build two versions: 1.x and 2.x. Each version has its own respective genrule that outputs file for 1.x or 2.x since API modules are different (for e.g. *tensorflow/manip/\_\_init\_\_.py* only exists in 1.x and not 2.x API). Now, bazel does not allow two genrules to output files to the same directory. Therefore, we have *_api/v1/* and *_api/v2/* subdirectories.++Note that we could still place the API directly under *tensorflow/* in the pip package since a pip package contains a single version of TensorFlow. This option became out of reach when *tensorflow/contrib/lite/* was migrated to *tensorflow/lite/*. Now *tensorflow/lite/* API directory would conflict with *tensorflow/lite/* source directory if the API was under *tensorflow/* instead of *_api/vN/*.++#### Circular dependencies+Estimator depends on TensorFlow. At the same time, TensorFlow includes estimator as a part of its API. This creates a cycle.++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/circular_dependency.png "Circular dependency+between TensorFlow and Estimator.")++#### Metapackage vs base package plans+[Modular TensorFlow+RFC](https://github.com/tensorflow/community/blob/master/rfcs/20190305-modular-tensorflow.md) proposes to keep two pip packages:+tensorflow-base would only contain core TensorFlow (for e.g. no estimator).+TensorFlow Metapackage would be a thin package defining composition of TensorFlow which includes base, estimator, keras and tensorboard.+Note that this 2-package approach is not implemented yet. However, its proposal demonstrates how keeping a virtual pip package could be beneficial in the future.++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/modular_structure.png "Proposed modular TensorFlow structure.")++Current structure looks more like this (except *tensorflow/* and *tensorflow\_core/* are directories as opposed to separate pip packages) and meant to be the first step towards structure above:++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/current_structure.png "Current TensorFlow structure.")++### Current state of IDE code features++#### PyCharm 2019.1.1++* Autocomplete:+  * Works in most cases after switching to use relative imports.+  * Doesn’t work for tf.compat.v1.keras and tf.compat.v2.keras.+  * Doesn’t work for keras if importing it using from import (i.e. `from tensorflow import keras`).+* Jump-to-definition doesn’t work.+* Quick documentation doesn’t work.++#### PyCharms with 2019.3 EAP build 193.3793.14+Latest version of PyCharms added [custom handling for tensorflow](https://github.com/JetBrains/intellij-community/blob/0a08f8212351ee84d602cdc5547f038ce0df79fd/python/src/com/jetbrains/tensorFlow/PyTensorFlow.kt)+* Autocomplete works in most cases.+* Doesn’t work for keras if importing it using from import (i.e. `from tensorflow import keras`).+* Jump-to-definition works.+* Quick documentation works.++#### VS Code 1.40 (October 2019 release)+* Autocomplete:+  * Works in most cases.+  * Doesn’t work for `tf.estimator` or `tf.keras`.+  * Doesn’t work for `tf.compat.v1.keras` and `tf.compat.v2.keras`.+  * Doesn’t work for keras if importing it using from import (i.e. `from tensorflow import keras`).+* Jump-to-definition doesn’t work.+* Quick documentation doesn’t work.+++## User Benefit++TensorFlow package structure creates difficulties for those who use IDEs.+Autocomplete, quick documentation and jump-to-definition features often rely on+module structure matching directory structure. For example, TensorFlow code uses+`from tensorflow.foo` imports but lives under tensorflow\_core package. Simplifying+package structure would improve productivity for TensorFlow users.++## Design Proposal++The best way I can think of to fix the autocomplete issues is to make our package structure as clean as possible. In this case, autocomplete will work out of the box.++### Short term: Remove virtual pip package++Primary purpose of keeping the virtual pip package is to workaround circular+estimator imports. Alternatively, we can resolve this issue by lazy loading+estimator.++Lazy loading by itself would mean that we no longer have autocomplete for estimator. As a workaround, we can import estimator in the stub *.pyi* file.++Estimator import in root *\_\_init\_\_.py* file:+```python+from tensorflow.python.util.lazy_loader import LazyLoader as _LazyLoader+estimator = _LazyLoader(+    "estimator", globals(),+    "tensorflow_estimator.python.estimator.api._v2.estimator")+setattr(_current_module, "estimator", estimator)+```++Estimator import in root *\_\_init\_\_.pyi* file:+```python+from tensorflow_estimator.python.estimator.api._v2 import estimator as estimator+```+In Python 3, we don't even need the *.pyi* file and instead can import estimator+without lazy loading if `typing.TYPE_CHECKING` is `True`.++After building a pip package with this change all of the following work in PyCharms (both released and EAP) and VS Code:++* jump-to-definition+* quick documentation+* autocomplete for `compat.v1.keras`, `compat.v2.keras`+* autocomplete for keras when using from tensorflow import keras+* ...basically any import I tested works with autocompletion++To support the TensorFlow Metapackage plans we could add a new pip package that specifies dependencies on tensorflow, tensorflow\_estimator, tensorboard, etc.. Its sole purpose would be to get all dependencies installed.++![alt_text](https://github.com/annarev/community/blob/pip_structure_rfc/rfcs/20191127-pip-structure/new_modular_structure.png "New proposed modular TensorFlow structure.")++### Long term: Import from external package directly+Short term would fix IDE issues, but the package structure is still not as clean as it could be. We resolve cycles with lazy loading but it would be even better not to have this circular structure at all.++Therefore, I propose that we don’t import external packages into TensorFlow 3.0. Users who want to use estimator, tensorboard summaries or keras could import them separately:++Current code that looks like:+```python+import tensorflow as tf++tf.estimator+tf.keras+tf.summary+```++Would be changed to:+```python+import tensorflow as tf+import tensorflow_estimator as estimator+import tensorflow_keras as keras+from tenosorboard import summaries+```++Rationale for this change:++* One way dependencies (estimator depends on tensorflow and not vise-versa).+* Minimal overhead for users. Adding an extra import is easy.

Primary reason for this is to avoid circular structure. keras, estimator and tensorboard currently all depend on tensorflow pip package (they would use import tensorflow.*). If we make tf.estimator, tf.keras and tf.summary available (which is the case now), then we have a reverse dependency as well. This is a cycle.

That being said, I am definitely interested in hearing opinions about having these separate imports! If tf.keras and tf.estimator are very useful, we could consider ways to deal with circular imports.

There are two ways I can think of to deal with circular imports now:

  1. Lazy loading.
  2. There is another option in Alternatives Considered right below. Basically, instead of having these separate imports, we can rename tensorflow package to tensorflow_core. estimator, keras and tensorboard would then use "from tensorflow_core.". Then we have another package on top called tensorflow that will combine tensorflow_core, estimator, keras and tensorboard into one package.

Both of these options seem less clean to me than just having the extra imports, but I am open to other options based on feedback.

annarev

comment created time in 3 months

push eventannarev/community

Anna R

commit sha 586f10285686d5b1f7e3fcad3cbbfb9712b2fcbd

Fixed some nits in the pip package structure doc

view details

push time in 3 months

issue commenttensorflow/tensorflow

(more) spurious deprecation warnings

@rohan100jain Rohan, can you take a look how FeatureColumn APIs can be updated so that they don't print out deprecation warnings?

adammichaelwood

comment created time in 3 months

push eventannarev/community

Anna R

commit sha eaa9ed6c5703eed2303482d72aa11e72a5a0e432

Update image links to point to my github fork

view details

push time in 3 months

pull request commenttensorflow/tensorflow

Fix pip package API generation

That's great to hear! Do you have an ETA for this?

I put up a proposal here: https://github.com/tensorflow/community/pull/182/files?short_path=5c4ad87#diff-5c4ad8728e4355930b6444d235b602d0 The change itself should be relatively quick. However, I need to get some feedback first to see if this is the right way to proceed.

lgeiger

comment created time in 3 months

PR opened tensorflow/community

Reviewers
Package structure RFC

Title of RFC

Status (Proposed / Accepted / Implemented / Obsolete)
RFC # NNN (update when you have community PR #)
Author(s) Anna Revinskaya (annarev@google.com)
Sponsor Alex Passos (apassos@tensorflow.org)
Updated 2019-11-27

Objective

We propose to simplify TensorFlow pip package structure to enable IDE features such as autocomplete, jump-to-definition and quick-documentation.

+212 -0

0 comment

5 changed files

pr created time in 3 months

push eventannarev/community

Anna R

commit sha 889335808e7f674813f495d8cd10fc4c7f773e20

Cropping images

view details

push time in 3 months

push eventannarev/community

Anna R

commit sha 4c2871e85afd513b8edf6303da354be5f330dcfb

Fix underscores and a few other formatting issues

view details

push time in 3 months

create barnchannarev/community

branch : pip_structure_rfc

created branch time in 3 months

push eventannarev/community

Gunhan Gulsoy

commit sha 3f3c18f7750aa389fa3b2332d96078ae2756cce6

Modular tensorflow public design review.

view details

Gunhan Gulsoy

commit sha 6526e3059de1062cfe435a687898f9707df2dac8

Update the proposal status.

view details

Edd Wilder-James

commit sha 709c3a43c2ae9a13e4a08a04e975463eb9be31c9

Update 20190305-modular-tensorflow.md Here are my proposed changes, to streamline the introduction and correct a few typos.

view details

Gunhan Gulsoy

commit sha 809fb92464a7d25c8e8b867501dc8ed01bb4db89

Merge pull request #1 from ewilderj/patch-1 Update 20190305-modular-tensorflow.md

view details

Gunhan Gulsoy

commit sha b42798f11d59dc9818bce4bd2cf6a276b4889518

Fix markdown typos.

view details

Kevin Haas

commit sha 9c9e40ba96f1490f2ced842619650683a8c1b5d8

Add files via upload Adding the original TFX OSS design docs.

view details

Kevin Haas

commit sha a8e8532a6dbd95da06583c30ce03e9172e0c4d8f

Merge pull request #1 from krazyhaas/krazyhaas-tfx-rfc

view details

Kevin Haas

commit sha 2b7c5a57e6c2eae801c5da9ea1c0405c06089e5c

Update 20190718-tfx-orchestration.md

view details

Edd Wilder-James

commit sha 1423772aae3e85dfc95363464d9b023cf633c60f

Update CHARTER.md Add in Gitter channel URL

view details

Edd Wilder-James

commit sha dafb2e24f20f68b8d92ee1104bb6baeec950a039

Update CHARTER.md Add link to meeting notes

view details

Shanqing Cai

commit sha 07b989e6b52d0790818207ff7c0dba7cd30aba39

RFC: TensorFlow Debugger v2 -- Callbacks for Eager Execution and tf.function (#127) * Add RFC: tfdbg v2: Callbacks for Eager Execution and `tf.function`s * Graphics and grammar tweaks * Be precise about what ops are created * Fix some typos and arithemtic errors * Correct status * Fix typo * Update 20190815-tfdbg-v2-callbacks.md * Update rfcs/20190815-tfdbg-v2-callbacks.md Co-Authored-By: Sergii Khomenko <x-sam@brainscode.com> * Add mention of tf.data objects * Addressing some comments * Address more comments * Fix comment * Update timestamp * Clarify what to do in a callback function * Update timestamp and status

view details

Kevin Haas

commit sha 19efacccb503708496d262602487ae5896800c92

Merge pull request #2 from tensorflow/master sync

view details

Kevin Haas

commit sha 0fefe407b6dd9ce15421cfc8abc07892ac18a269

Added TFX notebook design doc

view details

Edd Wilder-James

commit sha 5524b044267d8bce33331334b2a2908cf3c45fb4

Create 20190816-tf-project-versioning.md

view details

Edd Wilder-James

commit sha 5c5439251a715574938231af4a41dddfb0cef711

Update 20190816-tf-project-versioning.md Change "libraries" to the more general "projects."

view details

Kevin Haas

commit sha 24da43aab341488e8889bdb5b7c3ba5f6e2ee13e

Final updates

view details

Kevin Haas

commit sha 00c4402b650f36888fbed2888c0cf6e378ba7c7e

Last 'final changes'

view details

Mark Sandler

commit sha a3315fb9a154a632b796a885df6ae1ace5190516

RFC: Standardizing Composite Operations In TensorFlow (#113) * RFC proposal on standartizing composite operations in tensorflow. * RFC: Standardizing Composite Operations In TensorFlow * typo fix * Update 20190610-standartizing-composite_ops.md typo fixes * Update rfcs/20190610-standartizing-composite_ops.md Co-Authored-By: Mehdi Amini <joker.eph@gmail.com> * Update 20190610-standartizing-composite_ops.md * Update 20190610-standartizing-composite_ops.md * Update 20190610-standartizing-composite_ops.md * Fixes type in file name

view details

Edd Wilder-James

commit sha 8bca45dcf6849a7e38645ee4c30c34184326e714

Add way to allocate numbers to RFCs Start allocating each RFC a number, for ease of future reference, based on the pull request. This enables tracing the RFC back to its discussion in the GitHub PR.

view details

Neil Tenenholtz

commit sha 5f70f12e1b4e6d45b4153e0c1dfa672ac3911d6a

Correcting URLs in 20190718-tfx-orchestration.md (#141)

view details

push time in 3 months

pull request commenttensorflow/tensorflow

Fix pip package API generation

@lgeiger Thank you for the change! You can verify if this helps without building TensorFlow but instead copying the changes into pip package files. For e.g.

python3 -m venv venv
source venv/bin/activate
pip install tensorflow
~$ python
>>> import tensorflow as tf
>>> tf
<module 'tensorflow' from '/path/to/python3.7/site-packages/tensorflow/__init__.py'>

Open /path/to/venv/lib/python3.7/site-packages/tensorflow_core/init.py Move __all__ to the end of the file. Now you can check if this installation of TensorFlow fixes the issue you see. (I can also help out with building TensorFlow if you have specific questions).

That being said, I am actually looking right now at fixing the autocomplete issues by removing the virtual package and changing tensorflow_core/ to tensorflow/. Specifically, there are other issues as well, not just __all__ location.

lgeiger

comment created time in 3 months

issue commenttensorflow/tensorflow

import packages of tf2.0.0rc in pycharm

You are right that 2.0.0rc0 had autocomplete issues. You can try 2.0.0rc1, which had some of the autocomplete issues fixed.

Xie-Fangyuan

comment created time in 5 months

issue commenttensorflow/tensorflow

[TF 2.0.0-rc0] Cannot find any 2.0.0 RC0 API references.

Autocomplete has been fixed for import tensorflow as tf and from tensorflow import keras in rc1. However, from tensorflow.keras import layers won't be fixed even in 2.0 final. It requires major changes to TensorFlow (renaming lite/ directory) to get it working. These changes are too big for this release since it only accepts critical cherrypicks.

Also, recommended way to import TensorFlow is import tensorflow as tf.

makercob

comment created time in 5 months

issue closedtensorflow/tensorflow

import packages of tf2.0.0rc in pycharm

i'm using tf2.0.0rc, win10.

when i write the below code in pycharm, Dataset is underlined with a red line, and shows a message cannot find reference 'Dataset' in '__init__.py', and pycharm can't auto-complete Dataset's functions, but the script can run well.

from tensorflow_core.python.data import Dataset

dataset = Dataset.from_tensors([2])

when i write the below code, there is no red line, and pycharm can auto-complete Dataset's functions, but the script has error:KeyError: "Registering two gradient with name 'ReduceDataset'! (Previous registration was in register /home/xiefangyuan/anaconda3/lib/python3.7/site-packages/tensorflow_core/python/framework/registry.py:66)"

from tensorflow_core.python.data.ops.dataset_ops import Dataset

dataset = Dataset.from_tensors([2])

closed time in 5 months

Xie-Fangyuan

issue commenttensorflow/tensorflow

import packages of tf2.0.0rc in pycharm

Closing, since this question is about unsupported usecase for TensorFlow.

Xie-Fangyuan

comment created time in 5 months

issue commenttensorflow/tensorflow

import packages of tf2.0.0rc in pycharm

The supported way to use tensorflow is with the following import: import tensorflow as tf In this case, you would use tf.data.Dataset instead. If you want to use V1 dataset, then you can reference it using tf.compat.v1.data.Dataset.

Code under tensorflow_core.python or tensorflow.python is not a part of our public API and has no guarantees.

Xie-Fangyuan

comment created time in 5 months

PR opened tensorflow/tensorflow

2.0.0-rc2 cherry-pick request: Use relative imports only in TensorFlow.

Estimator's autocomplete works without relative imports and relative imports cause some issue.

PiperOrigin-RevId: 268940330

+24 -8

0 comment

2 changed files

pr created time in 5 months

create barnchannarev/tensorflow

branch : cherrypicks_T5PFH

created branch time in 5 months

pull request commenttensorflow/community

RFC: Kernel and Op Implementation and Registration API

Good point. We definitely need a way to register an ApiDef for an op.

sjamesr

comment created time in 5 months

delete branch annarev/tensorflow

delete branch : cherrypicks_JN7Y8

delete time in 5 months

pull request commenttensorflow/community

RFC: Kernel and Op Implementation and Registration API

@karllessard sorry I missed your question earlier. See replies inline.

I don't know if this is in the scope of this RFC but how will be registered ops be exposed through the C API? Right now, both Ops defs and API defs are returned as proto buffers, will that remain the same?

Yes, the way Op defs and API defs are returned will remain the same. These accessors are already a part of our C API. But let us know if you think some part of the API won't work well for some languages.

Since at some points we want to move out the different language bindings out of the core repository (e.g. Java), for me it does not make sense to keep the per-language API defs in there. What would be the best strategy then?

I think language bindings can already be removed with current API. You can keep ApiDef files with the language bindings (they are just read when generating language APIs and aren't used anywhere else). For example, Go API is generated based on a set of directories that contain ApiDef files: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/go/genop/main.go#L39 that are added using calls to TF_ApiDefMapPut (https://github.com/tensorflow/tensorflow/blob/master/tensorflow/go/genop/internal/api_def_map.go#L91). So, I would think we can move language API designed in this way to a separate repo. However, I haven't checked how Java APIs are generated.

sjamesr

comment created time in 5 months

pull request commenttensorflow/tensorflow

2.0.0-rc1 cherry-pick request: Import submodules using relative imports.

TensorBoard is harder to install for Linux CPU build. So, for now I just disabled the test (added by this change) if tensorboard pip is not available.

annarev

comment created time in 5 months

push eventannarev/tensorflow

Anna R

commit sha 77f56172494a3f50ea09271453edb0d9c8111238

Disable tf.summary test if tensorboard is not installed

view details

push time in 5 months

create barnchannarev/tensorflow

branch : cherrypicks_8035R

created branch time in 5 months

pull request commenttensorflow/tensorflow

2.0.0-rc1 cherry-pick request: Import submodules using relative imports.

So, the issue here is that tensorboard pip package is not installed. This change adds a test that tf.summary.image is available. This symbol is available in V1 without installing tensorboard, but would fail for r2.0 branch without the pip.

Now, I got the package installed for the MacOS build but Ubuntu CPU still doesn't have it.

annarev

comment created time in 5 months

pull request commenttensorflow/tensorflow

2.0.0-rc1 cherry-pick request: Import submodules using relative imports.

I think MacOS build might be failing because tensorboard it picks up doesn't have this change: https://github.com/tensorflow/tensorboard/pull/2593

I will verify it though.

annarev

comment created time in 5 months

pull request commenttensorflow/tensorflow

2.0.0-rc1 cherry-pick request: Import submodules using relative imports.

Seems like MacOS build failed. I will take a look.

annarev

comment created time in 5 months

PR opened tensorflow/tensorflow

Reviewers
2.0.0-rc1 cherry-pick request: Import submodules using relative imports.

Import submodules using relative imports. This fixed a lot of the autocomplete (although not everything).

+53 -10

0 comment

5 changed files

pr created time in 5 months

create barnchannarev/tensorflow

branch : cherrypicks_JN7Y8

created branch time in 5 months

pull request commenttensorflow/tensorflow

2.0.0-rc0 cherry-pick request: Only add ModuleWrapper when lazy loading is requested or when using TF 1.x (to print deprecation warnings).

I included changes from these other commits to get it to build: https://github.com/tensorflow/tensorflow/commit/d82a2bbf8a0ead6d7298e652f7d4e057ca8fd83d#diff-62ec18ff8bdd93adaff55160f27a7e09 https://github.com/tensorflow/tensorflow/commit/b7db3f4ae43f5228952f3a1bb480a3e52a2006ed#diff-15bdff9a63024759f88313469be4b11f https://github.com/tensorflow/tensorflow/commit/18c2cf989a2263ee212fbd5ac0b3085d9450b80a#diff-15bdff9a63024759f88313469be4b11f

Please take another look.

annarev

comment created time in 5 months

push eventannarev/tensorflow

Anna R

commit sha 0733efc7700df551429a6877f589b686bb9da88d

Fixing builds after removing module wrapper in 2.0.

view details

push time in 5 months

issue commenttensorflow/tensorflow

`tf.estimator` missing in 2019-09-05 nightlies (and broken in 2019-09-04)

Sorry for the breakage! Tomorrow the issue should be fixed (thanks to Mihai).

Also today's pip packages have been removed today morning.

wchargin

comment created time in 6 months

pull request commenttensorflow/tensorflow

2.0.0-rc0 cherry-pick request: Only add ModuleWrapper when lazy loading is requested or when using TF 1.x (to print deprecation warnings).

Windows build is breaking with this change. I will update this PR with a few more changes before merging.

annarev

comment created time in 6 months

more