mac m1 使用pypi安装Secretflow时，编译onnx时报错

Issue Type
Build/Install
Source
binary
Secretflow Version
secretflow-1.4.0.dev20240123
OS Platform and Distribution
mac os m1
Python version
3.8.19
Bazel version
bazel 7.1.1-homebrew
GCC/Compiler version
Apple clang version 14.0.0 (clang-14<IP_ADDRESS>)
What happend and What you expected to happen.
我按照教程执行：
conda create -n sf python=3.8
conda activate sf
pip install -U secretflow

当执行到Building wheel for onnx (setup.py)时发生报错
error: subprocess-exited-with-error

  × python setup.py bdist_wheel did not run successfully.
  │ exit code: 1
  ╰─> [759 lines of output]
      fatal: not a git repository (or any of the parent directories): .git
      /Users/admin/soft/miniconda3/envs/sf/lib/python3.8/site-packages/setuptools/__init__.py:80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated.
      !!

              ********************************************************************************
              Requirements should be satisfied by a PEP 517 installer.
              If you are using pip, you can try `pip install --use-pep517`.
              ********************************************************************************

      !!
        dist.fetch_build_eggs(dist.setup_requires)
      running bdist_wheel
      running build
      running build_py
      running create_version
      running cmake_build
      Using cmake args: ['/opt/homebrew/bin/cmake', '-DPYTHON_INCLUDE_DIR=/Users/admin/soft/miniconda3/envs/sf/include/python3.8', '-DPYTHON_EXECUTABLE=/Users/admin/soft/miniconda3/envs/sf/bin/python', '-DBUILD_ONNX_PYTHON=ON', '-DCMAKE_EXPORT_COMPILE_COMMANDS=ON', '-DONNX_NAMESPACE=onnx', '-DPY_EXT_SUFFIX=.cpython-38-darwin.so', '-DCMAKE_BUILD_TYPE=Release', '-DONNX_ML=1', '/private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8']
      CMake Deprecation Warning at CMakeLists.txt:2 (cmake_minimum_required):
        Compatibility with CMake < 3.5 will be removed from a future version of
        CMake.

        Update the VERSION argument <min> value or use a ...<max> suffix to tell
        CMake that the project does not need compatibility with older versions.

      -- The C compiler identification is AppleClang <IP_ADDRESS>00029
      -- The CXX compiler identification is AppleClang <IP_ADDRESS>00029
      -- Detecting C compiler ABI info
      -- Detecting C compiler ABI info - done
      -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
      -- Detecting C compile features
      -- Detecting C compile features - done
      -- Detecting CXX compiler ABI info
      -- Detecting CXX compiler ABI info - done
      -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
      -- Detecting CXX compile features
      -- Detecting CXX compile features - done
      CMake Warning (dev) at CMakeLists.txt:117 (find_package):
        Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
        are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
        the cmake_policy command to set the policy and suppress this warning.

      This warning is for project developers.  Use -Wno-dev to suppress it.

      -- Found PythonInterp: /Users/admin/soft/miniconda3/envs/sf/bin/python (found version "3.8.19")
      CMake Warning (dev) at CMakeLists.txt:118 (find_package):
        Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
        are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
        the cmake_policy command to set the policy and suppress this warning.

      This warning is for project developers.  Use -Wno-dev to suppress it.

      -- Found PythonLibs: /Users/admin/soft/miniconda3/envs/sf/lib/libpython3.8.dylib (found version "3.8.19")
      -- Found Protobuf: /opt/homebrew/lib/libprotobuf.dylib (found version "4.25.3")
      Generated: /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-ml.proto
      Generated: /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.proto
      Generated: /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-data.proto
      -- Could NOT find pybind11 (missing: pybind11_DIR)
      CMake Deprecation Warning at third_party/pybind11/CMakeLists.txt:8 (cmake_minimum_required):
        Compatibility with CMake < 3.5 will be removed from a future version of
        CMake.

        Update the VERSION argument <min> value or use a ...<max> suffix to tell
        CMake that the project does not need compatibility with older versions.

      -- pybind11 v2.9.1
      CMake Warning (dev) at third_party/pybind11/tools/FindPythonLibsNew.cmake:98 (find_package):
        Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
        are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
        the cmake_policy command to set the policy and suppress this warning.

      Call Stack (most recent call first):
        third_party/pybind11/tools/pybind11Tools.cmake:50 (find_package)
        third_party/pybind11/tools/pybind11Common.cmake:206 (include)
        third_party/pybind11/CMakeLists.txt:200 (include)
      This warning is for project developers.  Use -Wno-dev to suppress it.

      -- Found PythonLibs: /Users/admin/soft/miniconda3/envs/sf/lib/libpython3.8.dylib
      -- Performing Test HAS_FLTO
      -- Performing Test HAS_FLTO - Success
      -- Performing Test HAS_FLTO_THIN
      -- Performing Test HAS_FLTO_THIN - Success
      --
      -- ******** Summary ********
      --   CMake version             : 3.28.1
      --   CMake command             : /opt/homebrew/Cellar/cmake/3.28.1/bin/cmake
      --   System                    : Darwin
      --   C++ compiler              : /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
      --   C++ compiler version      : <IP_ADDRESS>00029
      --   CXX flags                 :  -Wnon-virtual-dtor
      --   Build type                : Release
      --   Compile definitions       : __STDC_FORMAT_MACROS
      --   CMAKE_PREFIX_PATH         :
      --   CMAKE_INSTALL_PREFIX      : /usr/local
      --   CMAKE_MODULE_PATH         :
      --
      --   ONNX version              : 1.12.0
      --   ONNX NAMESPACE            : onnx
      --   ONNX_USE_LITE_PROTO       : OFF
      --   USE_PROTOBUF_SHARED_LIBS  : OFF
      --   Protobuf_USE_STATIC_LIBS  : ON
      --   ONNX_DISABLE_EXCEPTIONS   : OFF
      --   ONNX_WERROR               : OFF
      --   ONNX_BUILD_TESTS          : OFF
      --   ONNX_BUILD_BENCHMARKS     : OFF
      --   ONNXIFI_DUMMY_BACKEND     : OFF
      --   ONNXIFI_ENABLE_EXT        : OFF
      --
      --   Protobuf compiler         : /opt/homebrew/bin/protoc
      --   Protobuf includes         : /opt/homebrew/include
      --   Protobuf libraries        : /opt/homebrew/lib/libprotobuf.dylib
      --   BUILD_ONNX_PYTHON         : ON
      --     Python version        :
      --     Python executable     : /Users/admin/soft/miniconda3/envs/sf/bin/python
      --     Python includes       : /Users/admin/soft/miniconda3/envs/sf/include/python3.8
      -- Configuring done (0.9s)
      -- Generating done (0.0s)
      -- Build files have been written to: /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build
      [  4%] Building C object CMakeFiles/onnxifi_loader.dir/onnx/onnxifi_loader.c.o
      [  4%] Building C object CMakeFiles/onnxifi_dummy.dir/onnx/onnxifi_dummy.c.o
      [  4%] Running gen_proto.py on onnx/onnx.in.proto
      Processing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/onnx/onnx.in.proto
      Writing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-ml.proto
      Writing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-ml.proto3
      generating /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx_pb.py
      [  5%] Running C++ protocol buffer compiler on /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-ml.proto
      [  7%] Linking C static library libonnxifi_loader.a
      [  8%] Linking C shared library libonnxifi_dummy.dylib
      [  8%] Built target onnxifi_loader
      [  9%] Building C object CMakeFiles/onnxifi_wrapper.dir/onnx/onnxifi_wrapper.c.o
      [  9%] Built target onnxifi_dummy
      Writing mypy to onnx/onnx_ml_pb2.pyi
      [  9%] Built target gen_onnx_proto
      [ 11%] Linking C shared module libonnxifi.dylib
      [ 14%] Running gen_proto.py on onnx/onnx-data.in.proto
      [ 14%] Running gen_proto.py on onnx/onnx-operators.in.proto
      Processing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/onnx/onnx-data.in.proto
      Writing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-data.proto
      Writing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-data.proto3
      generating /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx_data_pb.py
      Processing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/onnx/onnx-operators.in.proto
      Writing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.proto
      Writing /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.proto3
      generating /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx_operators_pb.py
      [ 14%] Built target onnxifi_wrapper
      [ 16%] Running C++ protocol buffer compiler on /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-data.proto
      [ 16%] Running C++ protocol buffer compiler on /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.proto
      Writing mypy to onnx/onnx_operators_ml_pb2.pyi
      Writing mypy to onnx/onnx_data_pb2.pyi
      [ 16%] Built target gen_onnx_operators_proto
      [ 16%] Built target gen_onnx_data_proto
      [ 21%] Building CXX object CMakeFiles/onnx_proto.dir/onnx/onnx-operators-ml.pb.cc.o
      [ 21%] Building CXX object CMakeFiles/onnx_proto.dir/onnx/onnx-data.pb.cc.o
      [ 21%] Building CXX object CMakeFiles/onnx_proto.dir/onnx/onnx-ml.pb.cc.o
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.pb.cc:4:
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.pb.h:13:
      In file included from /opt/homebrew/include/google/protobuf/port_def.inc:33:
      In file included from /opt/homebrew/include/absl/base/attributes.h:37:
      In file included from /opt/homebrew/include/absl/base/config.h:92:
      /opt/homebrew/include/absl/base/policy_checks.h:79:2: error: "C++ versions less than C++14 are not supported."
      #error "C++ versions less than C++14 are not supported."
       ^
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-data.pb.cc:4:
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-data.pb.h:13:
      In file included from /opt/homebrew/include/google/protobuf/port_def.inc:33:
      In file included from /opt/homebrew/include/absl/base/attributes.h:37:
      In file included from /opt/homebrew/include/absl/base/config.h:92:
      /opt/homebrew/include/absl/base/policy_checks.h:79:2: error: "C++ versions less than C++14 are not supported."
      #error "C++ versions less than C++14 are not supported."
       ^
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-ml.pb.cc:4:
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-ml.pb.h:13:
      In file included from /opt/homebrew/include/google/protobuf/port_def.inc:33:
      In file included from /opt/homebrew/include/absl/base/attributes.h:37:
      In file included from /opt/homebrew/include/absl/base/config.h:92:
      /opt/homebrew/include/absl/base/policy_checks.h:79:2: error: "C++ versions less than C++14 are not supported."
      #error "C++ versions less than C++14 are not supported."
       ^
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.pb.cc:4:
      In file included from /private/var/folders/_4/gt37q6v92mqfg9zxm6w63fc00000gn/T/pip-install-6ihnisp4/onnx_141a25e9e4d146f9b24c9ad0937a59a8/.setuptools-cmake-build/onnx/onnx-operators-ml.pb.h:13:
      /opt/homebrew/include/google/protobuf/port_def.inc:159:1: error: static_assert failed due to requirement '201103L >= 201402L' "Protobuf only supports C++14 and newer."
      static_assert(PROTOBUF_CPLUSPLUS_MIN(201402L), "Protobuf only supports C++14 and newer.");
      ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
。。。
 line 364, in check_call
          raise CalledProcessError(retcode, cmd)
      subprocess.CalledProcessError: Command '['/opt/homebrew/bin/cmake', '--build', '.', '--', '-j', '8']' returned non-zero exit status 2.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for onnx
  Running setup.py clean for onnx
Failed to build onnx
ERROR: Could not build wheels for onnx, which is required to install pyproject.toml-based projects

Reproduction code to reproduce the issue.
貌似是C++版本问题，但是我当前的 clang version 14.0.0应该是支持c++14的

将python版本更新到Python：3.10尝试下

Building wheel for onnx (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [759 lines of output]
fatal: not a git repository (or any of the parent directories): .git
/Users/admin/soft/miniconda3/envs/sf/lib/python3.10/site-packages/setuptools/init.py:80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated.
问题仍然存在

好的 辛苦参考这个文档中的版本要求对应下自己的哪里不符合
https://github.com/secretflow/spu/blob/main/CONTRIBUTING.md#linux

好的 辛苦参考这个文档中的版本要求对应下自己的哪里不符合 https://github.com/secretflow/spu/blob/main/CONTRIBUTING.md#linux

对照了是一致的，我之前pip install spu没有问题。但是pip install不能直接安装的原因还是没找到。目前我基于源码的方式已经成功安装了secretflow。

可能是因为1.4的secretflow支持3.8，但其中的spu不支持3.8，需要3.10以上的python
如果你使用的是1.5版本的secretflow，python为3.10应该是没问题的

secretflow上面的requirements中写的spu==0.9.0.dev20240321 ，但是我看源码中最版本的分支才0.8.x

1、适配范围较大，建议都是用最新版本
2、由于安全审查，发布会有一定延时。


Pass xarray to napari-gui for autolabeling sliders

xarray is a library for N-D labeled arrays and datasets in Python http://xarray.pydata.org. If we allow xarrays to be passed to napari-gui then we could autopopulate labels of sliders etc. based on the names of the dimensions in the xarray object

Just to clarify, I think xarray support would be brilliant, but I just want to make sure that we don't become dependent on it. Bare NumPy arrays should be first-class citizens.

@jni can you share why you think in that way? Just curious.

This sounds like a nice convenience functionality. I'll keep it in mind.
Also, I'd like to note that you can already use DataArrays and other numpy.ndarray-like objects since we never explicitly call any NumPy functions on them (which would autoconvert them to strict ndarrays).

@AhmetCanSolak the entire SciPy ecosystem has thrived by using NumPy arrays as a lingua franca between packages. We are currently seeing some fragmentation as people test the boundaries of what can be done with arrays. I don't want to contribute to this fragmentation, and NumPy itself is taking steps to address it (see NEP18). There is a good chance that supporting NumPy arrays will eventually let us support any array in the future "for free". The converse is not true.

Thank you @jni !
It is nice to see people are considering this in NEP18.
For our use, I dont think we will have issues with either labeled or unlabeled arrays, as soon as we document it well and be strict on our implementations.

Hi,
I would also like to see support for labeled dimensions and automatically detecting xarray's given labels. I'll be happy to write the PR for this feature, but I will need a bit of mentoring. I'm assuming we'd want to add a label attribute to the range sliders defined here? And if a label is not None, rescale the drawn slider to accommodate for the given label?

Hi @HagaiHargil, great that you're excited about this.
I think it will be best to split this into two PRs, the first PR will just add support for labeled axes if someone passes in a list of string labels, and the second PR will add support for autodetecting xarrays labels and generating that string list. How does that sound?
The reason for this is that we'll always want to support people with just numpy arrays, but want to provide them access to this functionality without having to make an xarray.
For the first PR - here's some initial guidance on how I'm thinking about it, happy to provide more as you go:
Let's leave the QLabel off of the range slider explicitly and instead we'll add it to the layout in qt_dims.py, around the same place as we add the dimensions slider https://github.com/napari/napari/blob/b8b02a4642acad973e67228acc55e7cabef85346/napari/_qt/qt_dims.py#L229 (which is actually a QScrollBar).
We'll also want to add the labels as a list of strings to our dimensions model in dims.py, similar to say the points property here https://github.com/napari/napari/blob/4499372a6256fc6d2cd4b3051a55297e258368ff/napari/components/dims.py#L95., with the appropriate setters and events like those other properties. It can default to be a list of empty strings.
The dimensions model constructor should also take an optional keyword argument axis_labels=None that if provided is a list the same length as init_ndim.
The qt_dims view should then be updated with events when the labels change to update the display of the label in the bottom left next to the qscrollbar area. We're probably also going to be adding a play button there when #607 is done, which might make this PR a bit easier on the qt layout side.
I think probably best then to also expose the axis_labels at the Viewer level, at which point you'd need to add it to Viewer.py, ViewerModel.py and all our view_* methods. Inside the ViewerModel you might need to add some checks around the ndim calculation and then pass it to the Dims model - here https://github.com/napari/napari/blob/4499372a6256fc6d2cd4b3051a55297e258368ff/napari/components/viewer_model.py#L65. Looking at that code we should also add ndisplay=2 and order=None to the Dims model keywords args while we're at it too.
Once we get this PR merged we can then work on the best way to autodetect the xarray labels and propagate them from the layers to the viewer.
Let me know how this all sounds.

Hey, and thanks for this detailed reply.
Splitting up the PRs seems very logical. I will start working on the first soon, and I might create a semi-complete PR for you to review, and then update it with your comments.

Hi,
Whats the current status of this? I see that named sliders are now supported, so I think we would now need to the second PR.
I'd like to help with this, but it's not clear to me if this would need to wait until after issues such as https://github.com/napari/napari/issues/906 are resolved.

Also, it would awesome to also label the slider readouts in addition to the slider names.  @jrussell25 implemented this for ipywidgets/matplotlib sliders into hyperslicer which autopopulates sliders with names based on the dims and if there are coords it uses that to fill out slider label. So
%matplotlib ipympl
import matplotlib.pyplot as plt
import numpy as np
import xarray as xr
from mpl_interactions import hyperslicer

rng = np.random.default_rng()
data = xr.DataArray(
    rng.random((3, 5, 512, 512)),
    dims=("channel","z", "x", "y"),
    coords={"z":np.linspace(-1.5, 1.5, 5), "channel": ["BF", "GFP", "mCherry"]},
)

plt.figure()
ctrls = hyperslicer(data)

gives this (note the slider readouts):

fwiw we accomplish this without ever importing xarray:
https://github.com/ianhi/mpl-interactions/blob/5d6f063a5a1e2a357991bd98e77bd9e80ea5dc81/mpl_interactions/generic.py#L569-L570
https://github.com/ianhi/mpl-interactions/blob/5d6f063a5a1e2a357991bd98e77bd9e80ea5dc81/mpl_interactions/xarray_helpers.py
I'm not sure if napari supports this, but the key step for this is to allow sliders to have a displayed value but also keep track of their index in the array. For ipywidgets we accomplished this by squashing a label and slider together and then linking them with a function that transforms the slider value (an integer index) to the value of the coords.
https://github.com/ianhi/mpl-interactions/blob/5d6f063a5a1e2a357991bd98e77bd9e80ea5dc81/mpl_interactions/helpers.py#L363-L369 which maybe would be possible with qt as well?

Whats the current status of this? I see that named sliders are now supported, so I think we would now need to the second PR.
I'd like to help with this, but it's not clear to me if this would need to wait until after issues such as #906 are resolved.

I think if we can resolve first #906 then implement this will be easier. Maybe we continue a discussion on #906 now, there's nothing blocking that - I think we just need to think about exactly how we want everything to work. If you were willing to drive this @ianhi I'm sure we'd all be supportive.

Also, it would awesome to also label the slider readouts in addition to the slider names. @jrussell25 implemented this for ipywidgets/matplotlib sliders into hyperslicer which autopopulates sliders with names based on the dims and if there are coords it uses that to fill out slider label.

We have some ability to do that for things like our contrast_limits slider (if you right click then you get a pop-up that can be edited further) and our dims sliders thanks to @tlambert03 (see the little edit boxes with numbers you can type into next to the sliders) but it is not standard for all our sliders (like opacity say)

We have #879 that wants to bring this too all sliders (though I was recently discussing with @goanpeca and @ppwadhwa that we might not want to rely on pop-ups, but instead just have the value always displayed. I wonder also @tlambert03 if this "slider with value" might one day be a special magicgui widget type.

We have some ability to do that for things like our contrast_limits slider (if you right click then you get a pop-up that can be edited further) and our dims sliders thanks to @tlambert03 (see the little edit boxes with numbers you can type into next to the sliders) but it is not standard for all our sliders (like opacity say)

I may be wrong but I think that that is a little bit different than what I am proposing. I'd like to be able to do something like this:
viewer.add_image(3d_array, axis_labels=["time", "y", "x"], axis_values = {"time": np.arange(0, 60, 15)})
So that the value of the slider used in callbacks to update the display will still be an integer used for indexing, but the value displayed to the user is taken from axis_values.
What I'm proposing would look like the third slider in this GIF:

I think that is a bit different than the pop-up you're talking about, but I could definitely be misinterpreting. If it is different then I don't think that this will be totally covered by #906

yeah, we don't have that sort of transform from "slider space" to "user-defined-unit-space" yet.

I think that is a bit different than the pop-up you're talking about, but I could definitely be misinterpreting.

Yup sorry, I totally missed the coords={"z":np.linspace(-1.5, 1.5, 5)} part. We don't have anything like that yet and it's not really captured well in any of the current issues. Maybe @ianhi you want to make a dedicated issue to discuss just that functionality

not really captured well in any of the current issues. Maybe @ianhi you want to make a dedicated issue to discuss just that functionality

Would this be better housed on napari or on magicgui?

I think napari is still the better place for this.  We don't use magicgui for our dims sliders, so we'd need to change a lot before that saw the light of day.

Yup sorry, I totally missed the coords={"z":np.linspace(-1.5, 1.5, 5)} part. We don't have anything like that yet.

I would love something like this. I have a handful of heatmaps that overlay a WSI, and the UI isn't great to toggle each of these as independent 2-D layers. The other option is to stack the heatmaps as single arrayshape=(n_heatmaps, h, w) and use the axis slider to flip between heatmaps. The only issue is that I lose the ability to communicate the labels for each heatmap in the UI.

Maybe @ianhi you want to make a dedicated issue to discuss just that functionality

https://github.com/napari/napari/issues/2246
@manzt if all you need to is view the layers you should try out hyperslicer. The downside is that it's based in matplotlib so it's lower performance, and you can't do any of the fancy things napari does. But for quick viewing it is still helpful (not obvious from the docs but it will work both in and out of jupyter notebooks)

Thanks for the suggestion! I'll check it out. I think the main issue is that heatmaps are scaled and translated to overlay a multiscale RGB image (which is important for interpretation), so I'm pretty dependent on napari features.

Chiming in 4 years after the original opening to give the current situation (from an xarray dev's biased perspective). :sweat_smile: (@tlambert03 sent me here from here)

There is a good chance that supporting NumPy arrays will eventually let us support any array in the future "for free". The converse is not true.

This used to be the case, but now Xarray explicitly aims to wrap any array type that exposes NumPy's API. To this end we have pushed hard for standardisation in the wider array community  - see for example all (1) the (2) NEP's (3) co-authored by @shoyer.
Xarray can currently wrap numpy, dask, pint, sparse, cupy arrays (and probably more that we haven't tried). Thanks to standardisation efforts in the wider community, we should very soon be able to wrap any array that conforms to the new python array API standard.

Xarray can currently wrap numpy, dask, pint, sparse, cupy arrays (and probably more that we haven't tried). Thanks to standardisation efforts in the wider community, we should https://github.com/pydata/xarray/pull/6804 be able to wrap any array that conforms to the new python array API standard.

This is very exciting! As the OP 4-years ago, I'm very happy to hear things are moving in this direction!! Maybe @andy-sweet wants to look into the above and your comment here https://github.com/napari/napari/pull/3715#issuecomment-1189208297 and think about any of this in the context of the work to make slicing async in napari. Thanks!!

Another good reason to consider better xarray support might be ndpyramid (h/t @GenevieveBuckley who pointed it out in https://github.com/dask/dask-blog/issues/141#issuecomment-1197547317

Yes Kevin and I also discussed support for multi-resolution data in Napari.
Ndpyramid wraps xarray-DataTree, a prototype feature addition to xarray. I
am the main person developing xarray-DataTree, so feel free to ping me with
questions about that too!
https://github.com/xarray-contrib/datatree
On Wed, 27 Jul 2022, 19:14 Nicholas Sofroniew, @.***>
wrote:

Another good reason to consider better xarray support might be ndpyramid
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_carbonplan_ndpyramid&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=qdISi9HqjazmE0DcySuXts3OlnplnLfKjH4hpzAV0xo&m=zdluJw3ejPx8UnZKMsRo07Yr8qGrMGWGvjF_Bd1_mUpzw_FGdHDQTSdfEypXsdiL&s=35zHNT1CMtq30Q-pu7FCUqQmKUXxL-xlznekndlqAB0&e=
(h/t @GenevieveBuckley
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_GenevieveBuckley&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=qdISi9HqjazmE0DcySuXts3OlnplnLfKjH4hpzAV0xo&m=zdluJw3ejPx8UnZKMsRo07Yr8qGrMGWGvjF_Bd1_mUpzw_FGdHDQTSdfEypXsdiL&s=X5SKVdlg-QQVCYHVx614anApfAq82FiGtvh43eOaRYo&e=
who pointed it out in dask/dask-blog#141 (comment)
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dask_dask-2Dblog_issues_141-23issuecomment-2D1197547317&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=qdISi9HqjazmE0DcySuXts3OlnplnLfKjH4hpzAV0xo&m=zdluJw3ejPx8UnZKMsRo07Yr8qGrMGWGvjF_Bd1_mUpzw_FGdHDQTSdfEypXsdiL&s=2u5mzF1aIWOY8T4-_28Jb3LOPu38nbCmQYdrvcKDqhg&e=
—
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_napari_napari_issues_14-23issuecomment-2D1197572169&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=qdISi9HqjazmE0DcySuXts3OlnplnLfKjH4hpzAV0xo&m=zdluJw3ejPx8UnZKMsRo07Yr8qGrMGWGvjF_Bd1_mUpzw_FGdHDQTSdfEypXsdiL&s=AEOaVJHX8Th0h2gf1QTLDYgY6o_P2d97OI0RoOLcKz8&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AISNPI3RWONBAL5AQ25WGPDVWHUJ5ANCNFSM4F55VUGQ&d=DwMCaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=qdISi9HqjazmE0DcySuXts3OlnplnLfKjH4hpzAV0xo&m=zdluJw3ejPx8UnZKMsRo07Yr8qGrMGWGvjF_Bd1_mUpzw_FGdHDQTSdfEypXsdiL&s=TmvLOdG6UyPYcW_OGoLtjTAdS8Ru2ylDP3Vef-rb6jo&e=
.
You are receiving this because you were mentioned.Message ID:
@.***>

Here is another strong reason for supporting this as a feature: https://twitter.com/jnuneziglesias/status/1564858125772935169

I'm going to bump this.
At SciPy 2024 I saw a number of talks showcasing xarray and spoke with @TomNicholas
Across coordinates, units, various data reductions, lazy loading, and DataTree, xarray has a lot to offer and would not in any way box out or diminish using numpy arrays
I've used xarray via aicsimageio and it's a joy to work with, especially if you dont exactly remember what was what in your data, because it's year(s) after you did the imaging 👀 🤣

Thanks @psobolewskiPhD !

Across coordinates, units, various data reductions, lazy loading, and DataTree, xarray has a lot to offer and would not in any way box out or diminish using numpy arrays

I agree 😛
FOr anyone interested to work on this Earthmover won some funding to hire someone to work on exactly this kind of thing (better integrating xarray with biomedical projects). cc @dcherian


Support Transformers 4.43

What does this PR do?
Adds support of transfromers 4.43 as in https://github.com/huggingface/optimum/pull/1971, mainly:

whisper introducing a new forward input argument cache_position.
_reorder_cache removed from some causal models to use Cache.reorder_cache instead.
missing model.dtype used by transfromers pipelines to cast some features (pixels, audio samples, etc)

The rest is changes in the testing suite to adapt to the modeling changes in the library.
Also fixes the failing OV training tests on main.
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

I think it's ready.
ITREX still needs to fix qbits modeling for WOQ. OV looks good to me (compared to CI on main).

There's a qwen test that fails with transfromers 4.37 even tho I did add the transformers_stream_generator package
https://github.com/huggingface/optimum-intel/actions/runs/10213421527/job/28258759384?pr=856#step:5:2163

need to resolve conflicts from merged PRs

ready to merge

looks good, the failing tests in windows are mostly os errors, I can try fixing them in another PR


Re-execution of 'main.py'

The code of "main.py" of a Taipy project is being re-runned by default on the Gui side with "use_reloader=True" (when a change is done to the code). It is also re-runned when a worker is created on the Core side. These behaviors could be changed or documented.
Because of this, it is also important to explain how to initialize the variables for the Gui in a good manner in order to get the desired result when the 'main.py' is being re-executed.
Version of Taipy:
taipy-core 1.1.1
taipy-gui 1.1.1

@FabienLelaquais I have a spark of an idea related to this. We can discuss it.

But be my guest.

Open a new API to let the user provide a custom function (or list of functions) to be executed once before the application starts. The function must be passed as an optional parameter to the taipy.run method.

Add documentation in the user manual to clearly states that it is not recommended to have scripted code (outside any function) in the main.py script.


It seems like the last stormous victims were not detected

dismogas.com and everplast.com.br

Thanks.
Found a bug. now corrected.


Add raw streams tests. Also turn off travis osx tests.

Closing. Just wanted to see if travis changes worked.


[DDPB-3948] reporting checklist admin behat tests

Fixes DDPB-3948

So I'm open to being convinced otherwise on this but there's a variable we pass into the template called submittedEstimateCosts that only applies to profs with costs that are not fixed. This shows an extra section of the checklist that sums up the costs.
I guess its not really a feature as such but is a variation. The argument could be made that if we do it for this we should also test other conditional sections of the checklist but yeah, looking to see what you/anyone else reviewing this PR has to say ( cc: @Gugandeep @jamesrwarren)

I think variations of the checklist should be tested since part of the checklists core functionality is having the right questions appearing. Although doesn't necessarily have to be done through behat tests.
If it's easier (and possible) to do in unit tests by testing submittedEstimateCosts  then I'd be happy that would give us enough validity that the code is working fine.

I feel like I agree an oversight on my part about the the checklist form being different depending on the type of client it is. I feel like a single negative test may also be plausible around client health welfare has section Y but Pfa high assets does not have section Y just to make sure we are not seeing an incorrect checklist for certain clients.


error from: pip install -r requirements

environment: GCC=8.3.0, python=3.7.4
Error:
(venv_athena) (base) root@12e6d012d4d5:~/luxy/athena# pip install -r requirements.txt
Looking in indexes: https://pypi.tuna.tsinghua.edu.cn/simple
Requirement already satisfied: tensorflow-gpu==2.0.1 in /root/luxy/venv_athena/lib/python3.7/site-packages (from -r requirements.txt (line 1)) (2.0.1)
Requirement already satisfied: sox in /root/luxy/venv_athena/lib/python3.7/site-packages (from -r requirements.txt (line 2)) (1.3.7)
Requirement already satisfied: absl-py in /root/luxy/venv_athena/lib/python3.7/site-packages (from -r requirements.txt (line 3)) (0.9.0)
Requirement already satisfied: yapf in /root/luxy/venv_athena/lib/python3.7/site-packages (from -r requirements.txt (line 4)) (0.29.0)
Requirement already satisfied: pylint in /root/luxy/venv_athena/lib/python3.7/site-packages (from -r requirements.txt (line 5)) (2.4.4)
Requirement already satisfied: flake8 in /root/luxy/venv_athena/lib/python3.7/site-packages (from -r requirements.txt (line 6)) (3.7.9)
Collecting horovod
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/c0/31/dae1f224a284ccaf0fd700565a53658bfba9c3d5964719305953e72a11e0/horovod-0.19.1.tar.gz (2.9 MB)
Collecting tqdm
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/4a/1c/6359be64e8301b84160f6f6f7936bbfaaa5e9a4eab6cbc681db07600b949/tqdm-4.45.0-py2.py3-none-any.whl (60 kB)
Collecting sentencepiece
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/11/e0/1264990c559fb945cfb6664742001608e1ed8359eeec6722830ae085062b/sentencepiece-0.1.85-cp37-cp37m-manylinux1_x86_64.whl (1.0 MB)
Processing /root/.cache/pip/wheels/6e/d3/47/7582e7e63ee9127f4773adeb8dcd8490771c063e2607354ba0/librosa-0.7.2-py3-none-any.whl
Collecting kenlm
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/57/54/0cc492b8d7aceb17a9164c6e6b9c9afc2c73706bb39324e8f6fa02f7134a/kenlm-0.tar.gz (1.4 MB)
Processing /root/.cache/pip/wheels/95/1a/6d/75355e7a5c76ed48e2d6cde3b95c4828e83274b93f5392ac96/jieba-0.42.1-py3-none-any.whl
Collecting pandas
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/4a/6a/94b219b8ea0f2d580169e85ed1edc0163743f55aaeca8a44c2e8fc1e344e/pandas-1.0.3-cp37-cp37m-manylinux1_x86_64.whl (10.0 MB)
Requirement already satisfied: keras-applications>=1.0.8 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.0.8)
Requirement already satisfied: protobuf>=3.6.1 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (3.11.3)
Requirement already satisfied: tensorflow-estimator<2.1.0,>=2.0.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (2.0.1)
Requirement already satisfied: termcolor>=1.1.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.1.0)
Requirement already satisfied: tensorboard<2.1.0,>=2.0.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (2.0.2)
Requirement already satisfied: google-pasta>=0.1.6 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (0.2.0)
Requirement already satisfied: wrapt>=1.11.1 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.12.1)
Requirement already satisfied: grpcio>=1.8.6 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.28.1)
Requirement already satisfied: gast==0.2.2 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (0.2.2)
Requirement already satisfied: numpy<2.0,>=1.16.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.18.2)
Requirement already satisfied: six>=1.10.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.14.0)
Requirement already satisfied: opt-einsum>=2.3.2 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (3.2.0)
Requirement already satisfied: astor>=0.6.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (0.8.1)
Requirement already satisfied: wheel>=0.26; python_version >= "3" in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (0.34.2)
Requirement already satisfied: keras-preprocessing>=1.0.5 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.1.0)
Requirement already satisfied: mccabe<0.7,>=0.6 in /root/luxy/venv_athena/lib/python3.7/site-packages (from pylint->-r requirements.txt (line 5)) (0.6.1)
Requirement already satisfied: isort<5,>=4.2.5 in /root/luxy/venv_athena/lib/python3.7/site-packages (from pylint->-r requirements.txt (line 5)) (4.3.21)
Requirement already satisfied: astroid<2.4,>=2.3.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from pylint->-r requirements.txt (line 5)) (2.3.3)
Requirement already satisfied: pycodestyle<2.6.0,>=2.5.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from flake8->-r requirements.txt (line 6)) (2.5.0)
Requirement already satisfied: pyflakes<2.2.0,>=2.1.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from flake8->-r requirements.txt (line 6)) (2.1.1)
Requirement already satisfied: entrypoints<0.4.0,>=0.3.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from flake8->-r requirements.txt (line 6)) (0.3)
Requirement already satisfied: cloudpickle in /root/luxy/venv_athena/lib/python3.7/site-packages (from horovod->-r requirements.txt (line 7)) (1.3.0)
Requirement already satisfied: psutil in /root/luxy/venv_athena/lib/python3.7/site-packages (from horovod->-r requirements.txt (line 7)) (5.7.0)
Requirement already satisfied: pyyaml in /root/luxy/venv_athena/lib/python3.7/site-packages (from horovod->-r requirements.txt (line 7)) (5.3.1)
Requirement already satisfied: cffi>=1.4.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from horovod->-r requirements.txt (line 7)) (1.14.0)
Processing /root/.cache/pip/wheels/ad/c3/72/f5733d5e4abc9a637c9f6834a1a29429b4cd57b30a4585f91a/resampy-0.2.2-py3-none-any.whl
Processing /root/.cache/pip/wheels/0a/af/f6/aa7eefaad4a35a4f78adbfa0c2a99c53fda489e48132b037e4/audioread-2.1.8-py3-none-any.whl
Collecting decorator>=3.0.0
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/ed/1b/72a1821152d07cf1d8b6fce298aeb06a7eb90f4d6d41acec9861e7cc6df0/decorator-4.4.2-py2.py3-none-any.whl (9.2 kB)
Collecting numba>=0.43.0
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/a6/91/3af4fcbe6f9c05f5d04d08b955f635fc9e3388b751a7f0af18e71809e10a/numba-0.48.0-cp37-cp37m-manylinux1_x86_64.whl (2.5 MB)
Collecting soundfile>=0.9.0
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/eb/f2/3cbbbf3b96fb9fa91582c438b574cff3f45b29c772f94c400e2c99ef5db9/SoundFile-0.10.3.post1-py2.py3-none-any.whl (21 kB)
Collecting scikit-learn!=0.19.0,>=0.14.0
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/41/b6/126263db075fbcc79107749f906ec1c7639f69d2d017807c6574792e517e/scikit_learn-0.22.2.post1-cp37-cp37m-manylinux1_x86_64.whl (7.1 MB)
Collecting scipy>=1.0.0
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/dd/82/c1fe128f3526b128cfd185580ba40d01371c5d299fcf7f77968e22dfcc2e/scipy-1.4.1-cp37-cp37m-manylinux1_x86_64.whl (26.1 MB)
Collecting joblib>=0.12
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/28/5c/cf6a2b65a321c4a209efcdf64c2689efae2cb62661f8f6f4bb28547cf1bf/joblib-0.14.1-py2.py3-none-any.whl (294 kB)
Collecting pytz>=2017.2
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/e7/f9/f0b53f88060247251bf481fa6ea62cd0d25bf1b11a87888e53ce5b7c8ad2/pytz-2019.3-py2.py3-none-any.whl (509 kB)
Collecting python-dateutil>=2.6.1
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/d4/70/d60450c3dd48ef87586924207ae8907090de0b306af2bce5d134d78615cb/python_dateutil-2.8.1-py2.py3-none-any.whl (227 kB)
Requirement already satisfied: h5py in /root/luxy/venv_athena/lib/python3.7/site-packages (from keras-applications>=1.0.8->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (2.10.0)
Requirement already satisfied: setuptools in /root/luxy/venv_athena/lib/python3.7/site-packages (from protobuf>=3.6.1->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (40.8.0)
Requirement already satisfied: requests<3,>=2.21.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (2.23.0)
Requirement already satisfied: google-auth<2,>=1.6.3 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.13.1)
Requirement already satisfied: markdown>=2.6.8 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (3.2.1)
Requirement already satisfied: werkzeug>=0.11.15 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.0.1)
Requirement already satisfied: google-auth-oauthlib<0.5,>=0.4.1 in /root/luxy/venv_athena/lib/python3.7/site-packages (from tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (0.4.1)
Requirement already satisfied: lazy-object-proxy==1.4.* in /root/luxy/venv_athena/lib/python3.7/site-packages (from astroid<2.4,>=2.3.0->pylint->-r requirements.txt (line 5)) (1.4.3)
Requirement already satisfied: typed-ast<1.5,>=1.4.0; implementation_name == "cpython" and python_version < "3.8" in /root/luxy/venv_athena/lib/python3.7/site-packages (from astroid<2.4,>=2.3.0->pylint->-r requirements.txt (line 5)) (1.4.1)
Requirement already satisfied: pycparser in /root/luxy/venv_athena/lib/python3.7/site-packages (from cffi>=1.4.0->horovod->-r requirements.txt (line 7)) (2.20)
Collecting llvmlite<0.32.0,>=0.31.0dev0
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/a0/10/d02c0ac683fc47ecda3426249509cf771d748b6a2c0e9d5ebbee76a7b80a/llvmlite-0.31.0-cp37-cp37m-manylinux1_x86_64.whl (20.2 MB)
Requirement already satisfied: urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 in /root/luxy/venv_athena/lib/python3.7/site-packages (from requests<3,>=2.21.0->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.25.8)
Requirement already satisfied: idna<3,>=2.5 in /root/luxy/venv_athena/lib/python3.7/site-packages (from requests<3,>=2.21.0->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (2.9)
Requirement already satisfied: certifi>=2017.4.17 in /root/luxy/venv_athena/lib/python3.7/site-packages (from requests<3,>=2.21.0->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (2<IP_ADDRESS>)
Requirement already satisfied: chardet<4,>=3.0.2 in /root/luxy/venv_athena/lib/python3.7/site-packages (from requests<3,>=2.21.0->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (3.0.4)
Requirement already satisfied: pyasn1-modules>=0.2.1 in /root/luxy/venv_athena/lib/python3.7/site-packages (from google-auth<2,>=1.6.3->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (0.2.8)
Requirement already satisfied: rsa<4.1,>=3.1.4 in /root/luxy/venv_athena/lib/python3.7/site-packages (from google-auth<2,>=1.6.3->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (4.0)
Requirement already satisfied: cachetools<5.0,>=2.0.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from google-auth<2,>=1.6.3->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (4.0.0)
Requirement already satisfied: requests-oauthlib>=0.7.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from google-auth-oauthlib<0.5,>=0.4.1->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (1.3.0)
Requirement already satisfied: pyasn1<0.5.0,>=0.4.6 in /root/luxy/venv_athena/lib/python3.7/site-packages (from pyasn1-modules>=0.2.1->google-auth<2,>=1.6.3->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (0.4.8)
Requirement already satisfied: oauthlib>=3.0.0 in /root/luxy/venv_athena/lib/python3.7/site-packages (from requests-oauthlib>=0.7.0->google-auth-oauthlib<0.5,>=0.4.1->tensorboard<2.1.0,>=2.0.0->tensorflow-gpu==2.0.1->-r requirements.txt (line 1)) (3.1.0)
Building wheels for collected packages: horovod, kenlm
Building wheel for horovod (setup.py) ... error
ERROR: Command errored out with exit status 1:
command: /root/luxy/venv_athena/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-j394y9lx/horovod/setup.py'"'"'; file='"'"'/tmp/pip-install-j394y9lx/horovod/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-f6z4f15k
cwd: /tmp/pip-install-j394y9lx/horovod/
Complete output (190 lines):
running bdist_wheel
running build
running build_py
creating build
creating build/lib.linux-x86_64-3.7
creating build/lib.linux-x86_64-3.7/horovod
copying horovod/init.py -> build/lib.linux-x86_64-3.7/horovod
creating build/lib.linux-x86_64-3.7/horovod/mxnet
copying horovod/mxnet/mpi_ops.py -> build/lib.linux-x86_64-3.7/horovod/mxnet
copying horovod/mxnet/init.py -> build/lib.linux-x86_64-3.7/horovod/mxnet
creating build/lib.linux-x86_64-3.7/horovod/tensorflow
copying horovod/tensorflow/compression.py -> build/lib.linux-x86_64-3.7/horovod/tensorflow
copying horovod/tensorflow/util.py -> build/lib.linux-x86_64-3.7/horovod/tensorflow
copying horovod/tensorflow/mpi_ops.py -> build/lib.linux-x86_64-3.7/horovod/tensorflow
copying horovod/tensorflow/init.py -> build/lib.linux-x86_64-3.7/horovod/tensorflow
creating build/lib.linux-x86_64-3.7/horovod/common
copying horovod/common/util.py -> build/lib.linux-x86_64-3.7/horovod/common
copying horovod/common/basics.py -> build/lib.linux-x86_64-3.7/horovod/common
copying horovod/common/init.py -> build/lib.linux-x86_64-3.7/horovod/common
creating build/lib.linux-x86_64-3.7/horovod/run
copying horovod/run/task_fn.py -> build/lib.linux-x86_64-3.7/horovod/run
copying horovod/run/run.py -> build/lib.linux-x86_64-3.7/horovod/run
copying horovod/run/gloo_run.py -> build/lib.linux-x86_64-3.7/horovod/run
copying horovod/run/mpi_run.py -> build/lib.linux-x86_64-3.7/horovod/run
copying horovod/run/run_task.py -> build/lib.linux-x86_64-3.7/horovod/run
copying horovod/run/init.py -> build/lib.linux-x86_64-3.7/horovod/run
creating build/lib.linux-x86_64-3.7/horovod/spark
copying horovod/spark/init.py -> build/lib.linux-x86_64-3.7/horovod/spark
creating build/lib.linux-x86_64-3.7/horovod/_keras
copying horovod/_keras/callbacks.py -> build/lib.linux-x86_64-3.7/horovod/_keras
copying horovod/_keras/init.py -> build/lib.linux-x86_64-3.7/horovod/_keras
creating build/lib.linux-x86_64-3.7/horovod/keras
copying horovod/keras/callbacks.py -> build/lib.linux-x86_64-3.7/horovod/keras
copying horovod/keras/init.py -> build/lib.linux-x86_64-3.7/horovod/keras
creating build/lib.linux-x86_64-3.7/horovod/torch
copying horovod/torch/compression.py -> build/lib.linux-x86_64-3.7/horovod/torch
copying horovod/torch/mpi_ops.py -> build/lib.linux-x86_64-3.7/horovod/torch
copying horovod/torch/init.py -> build/lib.linux-x86_64-3.7/horovod/torch
creating build/lib.linux-x86_64-3.7/horovod/tensorflow/keras
copying horovod/tensorflow/keras/callbacks.py -> build/lib.linux-x86_64-3.7/horovod/tensorflow/keras
copying horovod/tensorflow/keras/init.py -> build/lib.linux-x86_64-3.7/horovod/tensorflow/keras
creating build/lib.linux-x86_64-3.7/horovod/run/task
copying horovod/run/task/task_service.py -> build/lib.linux-x86_64-3.7/horovod/run/task
copying horovod/run/task/init.py -> build/lib.linux-x86_64-3.7/horovod/run/task
creating build/lib.linux-x86_64-3.7/horovod/run/util
copying horovod/run/util/cache.py -> build/lib.linux-x86_64-3.7/horovod/run/util
copying horovod/run/util/network.py -> build/lib.linux-x86_64-3.7/horovod/run/util
copying horovod/run/util/threads.py -> build/lib.linux-x86_64-3.7/horovod/run/util
copying horovod/run/util/init.py -> build/lib.linux-x86_64-3.7/horovod/run/util
creating build/lib.linux-x86_64-3.7/horovod/run/common
copying horovod/run/common/init.py -> build/lib.linux-x86_64-3.7/horovod/run/common
creating build/lib.linux-x86_64-3.7/horovod/run/http
copying horovod/run/http/http_server.py -> build/lib.linux-x86_64-3.7/horovod/run/http
copying horovod/run/http/init.py -> build/lib.linux-x86_64-3.7/horovod/run/http
copying horovod/run/http/http_client.py -> build/lib.linux-x86_64-3.7/horovod/run/http
creating build/lib.linux-x86_64-3.7/horovod/run/driver
copying horovod/run/driver/driver_service.py -> build/lib.linux-x86_64-3.7/horovod/run/driver
copying horovod/run/driver/init.py -> build/lib.linux-x86_64-3.7/horovod/run/driver
creating build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/network.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/timeout.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/config_parser.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/codec.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/safe_shell_exec.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/host_hash.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/env.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/secret.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/settings.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
copying horovod/run/common/util/init.py -> build/lib.linux-x86_64-3.7/horovod/run/common/util
creating build/lib.linux-x86_64-3.7/horovod/run/common/service
copying horovod/run/common/service/task_service.py -> build/lib.linux-x86_64-3.7/horovod/run/common/service
copying horovod/run/common/service/driver_service.py -> build/lib.linux-x86_64-3.7/horovod/run/common/service
copying horovod/run/common/service/init.py -> build/lib.linux-x86_64-3.7/horovod/run/common/service
creating build/lib.linux-x86_64-3.7/horovod/spark/task
copying horovod/spark/task/task_service.py -> build/lib.linux-x86_64-3.7/horovod/spark/task
copying horovod/spark/task/mpirun_exec_fn.py -> build/lib.linux-x86_64-3.7/horovod/spark/task
copying horovod/spark/task/task_info.py -> build/lib.linux-x86_64-3.7/horovod/spark/task
copying horovod/spark/task/init.py -> build/lib.linux-x86_64-3.7/horovod/spark/task
creating build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/params.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/serialization.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/cache.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/util.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/constants.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/store.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/backend.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/_namedtuple_fix.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/estimator.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
copying horovod/spark/common/init.py -> build/lib.linux-x86_64-3.7/horovod/spark/common
creating build/lib.linux-x86_64-3.7/horovod/spark/keras
copying horovod/spark/keras/optimizer.py -> build/lib.linux-x86_64-3.7/horovod/spark/keras
copying horovod/spark/keras/tensorflow.py -> build/lib.linux-x86_64-3.7/horovod/spark/keras
copying horovod/spark/keras/util.py -> build/lib.linux-x86_64-3.7/horovod/spark/keras
copying horovod/spark/keras/remote.py -> build/lib.linux-x86_64-3.7/horovod/spark/keras
copying horovod/spark/keras/bare.py -> build/lib.linux-x86_64-3.7/horovod/spark/keras
copying horovod/spark/keras/estimator.py -> build/lib.linux-x86_64-3.7/horovod/spark/keras
copying horovod/spark/keras/init.py -> build/lib.linux-x86_64-3.7/horovod/spark/keras
creating build/lib.linux-x86_64-3.7/horovod/spark/torch
copying horovod/spark/torch/util.py -> build/lib.linux-x86_64-3.7/horovod/spark/torch
copying horovod/spark/torch/remote.py -> build/lib.linux-x86_64-3.7/horovod/spark/torch
copying horovod/spark/torch/estimator.py -> build/lib.linux-x86_64-3.7/horovod/spark/torch
copying horovod/spark/torch/init.py -> build/lib.linux-x86_64-3.7/horovod/spark/torch
creating build/lib.linux-x86_64-3.7/horovod/spark/driver
copying horovod/spark/driver/job_id.py -> build/lib.linux-x86_64-3.7/horovod/spark/driver
copying horovod/spark/driver/driver_service.py -> build/lib.linux-x86_64-3.7/horovod/spark/driver
copying horovod/spark/driver/mpirun_rsh.py -> build/lib.linux-x86_64-3.7/horovod/spark/driver
copying horovod/spark/driver/init.py -> build/lib.linux-x86_64-3.7/horovod/spark/driver
creating build/lib.linux-x86_64-3.7/horovod/torch/mpi_lib_impl
copying horovod/torch/mpi_lib_impl/init.py -> build/lib.linux-x86_64-3.7/horovod/torch/mpi_lib_impl
creating build/lib.linux-x86_64-3.7/horovod/torch/mpi_lib
copying horovod/torch/mpi_lib/init.py -> build/lib.linux-x86_64-3.7/horovod/torch/mpi_lib
running build_ext
gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/include -fPIC -std=c++11 -fPIC -O2 -Wall -fassociative-math -ffast-math -ftree-vectorize -funsafe-math-optimizations -mf16c -mavx -mfma -I/root/luxy/venv_athena/include -I/root/anaconda3/include/python3.7m -c build/temp.linux-x86_64-3.7/test_compile/test_cpp_flags.cc -o build/temp.linux-x86_64-3.7/test_compile/test_cpp_flags.o
cc1plus: 警告：command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
gcc -pthread -shared -B /root/anaconda3/compiler_compat -L/root/anaconda3/lib -Wl,-rpath=/root/anaconda3/lib -Wl,--no-as-needed -Wl,--sysroot=/ -Wl,-rpath,/lib -L/lib -fPIC -I/include build/temp.linux-x86_64-3.7/test_compile/test_cpp_flags.o -o build/temp.linux-x86_64-3.7/test_compile/test_cpp_flags.so
gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/include -fPIC -I/root/luxy/venv_athena/include -I/root/anaconda3/include/python3.7m -c build/temp.linux-x86_64-3.7/test_compile/test_link_flags.cc -o build/temp.linux-x86_64-3.7/test_compile/test_link_flags.o
cc1plus: 警告：command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
gcc -pthread -shared -B /root/anaconda3/compiler_compat -L/root/anaconda3/lib -Wl,-rpath=/root/anaconda3/lib -Wl,--no-as-needed -Wl,--sysroot=/ -Wl,-rpath,/lib -L/lib -fPIC -I/include -Wl,--version-script=horovod.lds build/temp.linux-x86_64-3.7/test_compile/test_link_flags.o -o build/temp.linux-x86_64-3.7/test_compile/test_link_flags.so
INFO: Cannot find CMake, will skip compiling Horovod with Gloo.
Traceback (most recent call last):
File "/tmp/pip-install-j394y9lx/horovod/setup.py", line 341, in get_mpi_flags
shlex.split(show_command), universal_newlines=True).strip()
File "/root/anaconda3/lib/python3.7/subprocess.py", line 395, in check_output
**kwargs).stdout
File "/root/anaconda3/lib/python3.7/subprocess.py", line 472, in run
with Popen(*popenargs, **kwargs) as process:
File "/root/anaconda3/lib/python3.7/subprocess.py", line 775, in init
restore_signals, start_new_session)
File "/root/anaconda3/lib/python3.7/subprocess.py", line 1522, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'mpicxx': 'mpicxx'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/pip-install-j394y9lx/horovod/setup.py", line 622, in get_common_options
mpi_flags = get_mpi_flags()
File "/tmp/pip-install-j394y9lx/horovod/setup.py", line 354, in get_mpi_flags
'%s' % (show_command, traceback.format_exc()))
distutils.errors.DistutilsPlatformError: mpicxx -show failed (see error below), is MPI in $PATH?
Note: If your version of MPI has a custom command to show compilation flags, please specify it with the HOROVOD_MPICXX_SHOW environment variable.
Traceback (most recent call last):
File "/tmp/pip-install-j394y9lx/horovod/setup.py", line 341, in get_mpi_flags
shlex.split(show_command), universal_newlines=True).strip()
File "/root/anaconda3/lib/python3.7/subprocess.py", line 395, in check_output
**kwargs).stdout
File "/root/anaconda3/lib/python3.7/subprocess.py", line 472, in run
with Popen(*popenargs, **kwargs) as process:
File "/root/anaconda3/lib/python3.7/subprocess.py", line 775, in init
restore_signals, start_new_session)
File "/root/anaconda3/lib/python3.7/subprocess.py", line 1522, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'mpicxx': 'mpicxx'
INFO: Cannot find MPI compilation flags, will skip compiling with MPI.
Traceback (most recent call last):
File "", line 1, in
File "/tmp/pip-install-j394y9lx/horovod/setup.py", line 1566, in
scripts=['bin/horovodrun'])
File "/root/luxy/venv_athena/lib/python3.7/site-packages/setuptools/init.py", line 145, in setup
return distutils.core.setup(**attrs)
File "/root/anaconda3/lib/python3.7/distutils/core.py", line 148, in setup
dist.run_commands()
File "/root/anaconda3/lib/python3.7/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/root/anaconda3/lib/python3.7/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/root/luxy/venv_athena/lib/python3.7/site-packages/wheel/bdist_wheel.py", line 223, in run
self.run_command('build')
File "/root/anaconda3/lib/python3.7/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/root/anaconda3/lib/python3.7/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/root/anaconda3/lib/python3.7/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
File "/root/anaconda3/lib/python3.7/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/root/anaconda3/lib/python3.7/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/root/luxy/venv_athena/lib/python3.7/site-packages/setuptools/command/build_ext.py", line 78, in run
_build_ext.run(self)
File "/root/anaconda3/lib/python3.7/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "/tmp/pip-install-j394y9lx/horovod/setup.py", line 1457, in build_extensions
options = get_common_options(self)
File "/tmp/pip-install-j394y9lx/horovod/setup.py", line 635, in get_common_options
raise RuntimeError('One of Gloo or MPI are required for Horovod to run. Check the logs above for more info.')
RuntimeError: One of Gloo or MPI are required for Horovod to run. Check the logs above for more info.
ERROR: Failed building wheel for horovod
Running setup.py clean for horovod
Building wheel for kenlm (setup.py) ... \
How to solove it?

You need to install MPI before installing Horovod.

The main problem is about the horovod:

about how to install horovod, you can checkout more information from this https://github.com/horovod/horovod#install
On the other hand, you can just skip horovod so you can use athena/main.py using just one gpu  or one cpu, since horovod is only useful when you are trying to perform multi-gpu/multi-cpu training

Thank you very much.
My system environment is:
Linux 4.15.0-43-generic
Python 3.7.4
GCC 8.3.0
Now i have modify the requirement.txt file, and delete horovod.

tensorflow-gpu==2.0.1
sox
absl-py
yapf
pylint
flake8
tqdm
sentencepiece
librosa
kenlm
jieba
pandas

But there still have some errors. For example,
Running setup.py install for kenlm ... error
error:command errored out with exit status 1:
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………

鲁小勇
工作单位：西北师范大学
所属部门：网络安全与信息化办公室
研究机构：语音实验室 & 自我与文化实验室
办公电话：0931-7971919
通信地址：甘肃兰州安宁东路967号西北师范大学
邮政编码：730070
Xiaoyong Lu
Speech Lab & Self and Culture Lab
Office of Cybercurity and Informatization
Northwest Normal University
LanZhou,GanSu,China

------------------ Original ------------------
From<EMAIL_ADDRESS>Date:  Thu, Apr 9, 2020 10:45 AM
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject:  Re: [athena-team/athena] error from: pip install -r requirements (#113)

The main problem is about the horovod:
about how to install horovod, you can checkout more information from this https://github.com/horovod/horovod#install
On the other hand, you can just skip horovod so you can use athena/main.py using just one gpu  or one cpu, since horovod is only useful when you are trying to perform multi-gpu/multi-cpu training
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


25g support: anaconda vlan support

This patch allows the user to optionally specify an anaconda interface
that has a .vlanid suffix.

Happy with this once @heydog15 verified this does not cause regression

Successfully deployed with Chris's change without the vlan id added to the interface for anaconda in the .properties file.  Merging.

Sorry, I don't have rights to merge.  Someone else will have to.

Just finished and the anaconda is up and running all good.


feat: add vibrancy sidebar for macos

Description
Add vibrancy sidebar for macOS
Checklist:

[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
[x] Have you linted your code locally prior to submission?
[x] Have you successfully ran app with your changes locally?

👍 It is a cool feature !


Release New Model

Release a new model trained on all images found in Google Images.

That would be pretty cool, but realistically won't happen.


Terminating Conditions and Interface

Conditions by which the game ends:

[ ] Endgame:

[ ] by checkmate,
[ ] by resignation.

[ ] Draw:

[ ] by stalemate,
[ ] by threefold round repetition,
[ ] by mutual agreement.
The game interface includes:

[x] Chess long algebraic move notation reading

[ ] Optionally FIDE short notation, which is hard to parse with lots of special cases.

[ ] Game loop:

[ ] Advancing turns:

[x] Read input from players.
[ ] Keep track of player stats.

[x] Player pieces.
[x] Captured pieces.
[ ] Display said stats on main screen

[x] Various visual improvements to the interface.

Interface stuff moved here because they are implemented in parallel to terminating conditions.

All done and tested. Game terminates on all but the three-fold condition. I address the two optional features I have not implemented, and why they are low priority:
Three-fold repetition
I consider the three-fold repetition draw condition a low priority, as players can simply mutually agree to a draw when that happens. While stalemate as a draw is important because it's a trap a player can fall into by miscalculation. Three-fold repetition on the other hand is always deliberate, and on the off-chance it happens by accident with neither player intending to draw the game, it would be a pity to lose the game.
Short notation
FIDE's short notation is the standard, however it involves checks beyond advanced regex-ing. Move long notation is abbreviated if there is no confusion with relation to the board state. Therefore, only piece type and target square are annotated unless, more than one pieces per player potentially target that square, so the move notation adds the source file the piece is moving from. If the file of the conflicting pieces is the same, use the source rank instead. In the rare occasion that both source file and rank conflict (this can happen when three pieces of the same type target the same square, with a pair having the same file and another pair having the same rank), use the full source square (this move's annotation will then in effect match the long notation used in the current implementation). These checks constitute cumbersome code that will require off-line method updating of Move objects and derivatives, the same way Piece objects are, because the short-handing depends on board context.
The bright-side is that context needed stops at the board level, however they still need to be set at a player's level, as their piece collection is perused.
From these two features, I'd say the latter takes precedence in implementation, even if a graphical interface is added to the game later (mouse and click), for reasons of documenting the move history with short notation.
I should comment that this PR has also fixed several bugs to the previous (merged) one, even though the previous one was operational at 90% of the cases it was to cover. I should note that the discovery of the few bugs in movement constraints was only possible with the work put on this PR, which means leaving the older PR would require putting a lot of work out of its scope to validate it fully. If, on the other hand, I would (as I did actually) only branch out from my work locally, I would be unable to send you updates. So please revise this super-working PR and consider merging it.


Add go load-balancing proxy

Add built-in load balancing proxy for failing over agents to
multiple masters in an HA environment.

Yep, thanks for taking a look @yamt! This is an alternative #674, there were some issues with using nginx: extra binary size, needs user to exist, cleaning up the process properly, etc.

Thanks for reviewing & comments @yamt!


workflow/pr/unstable -> unstable

test reopen

first line

second line

first line

second line
third:<PHONE_NUMBER>

Closed by CI build #1

tag  test  failed!

Closed by CI build #21

tag 0.-1-UNSTABLE test  failed!

Closed by CI build #22

tag 0.-1-UNSTABLE test  failed!


Add instrumentation to monitor the impact of schema updates on compression efficiency

This PR is the first in a series of two PRs with the ultimate goal of eliminating the observed degradation of the compression rate over time for Lightstep's span-type data.
This first PR focuses on the instrumentation of the code to better understand the impact of certain schema changes on the average compression rate (see the chart below).

The second PR will address this issue by identifying dictionary overflow that could be better handled as dictionary reset.

I apparently closed this by pushing

Opening again.


Home Assistant 2023.9 problems

Version of the custom_component
Version 1.9.0
Configuration
Using Home Assistant 2023.9
Describe the bug
There are several issues with testing of the integration for HA 2023.9
So far no issues with the integration itself has been identfied.
However, if someone suspect an issue with the integration due to HA 2023.9, please report it here.

Issue found to in the testing part only. No impact on the integration itself. Fixed in #213.


[DRAFT] rework of gl memory / buffer handling

Allocates native buffers to back memory as soon as allocate_memory is called,
hal buffers become logical sub-ranges of native buffers.
This is still WIP, there is a lot of room for improvement here.  Separate INDEX
memory could be reserved only for webgl, there could be separate upload /
download memory, and the end of buffer sub-ranges could be checked with asserts
in debug mode.
Fixes #2812
PR checklist:

[x] make succeeds (on *nix)
[x] make reftests succeeds
[x] tested examples with the following backends: gl
[ ] rustfmt run on changed code

This is still highly WIP, I just went ahead and created the PR to get feedback.
Notably, this doesn't fix wgpu-rs with rendy yet, rendy errors with NoSuitableMemory(0, CPU_VISIBLE).  I need to look into exactly why that is, and it might either need further gfx changes or potentially rendy changes as well.

Okay, so the cube example in wgpu-rs is still broken, and it has something to do with the fact that you can't call glTexSubImage2D with a buffer bound to  GL_PIXEL_UNPACK_BUFFER that is also currently memory mapped.
In the cube example, this is coming from uploading texture data to a new buffer and calling copy_buffer_to_texture on that buffer.  I believe this ends up being allocated on a rendy-memory "dynamic" heap, which actually does not unmap its buffers when DynamicBlock::unmap is called.  HOWEVER, even if you patch rendy's DynamicBlock::unmap to call device.unmap_memory, the cube example will still not work.
I don't know how opengl mapping of a buffer range really works, I guess you can't unmap a buffer range, you can only unmap all of the mapped buffer ranges at once?  Does opengl support mapping multiple different ranges of a single buffer simultaneously?
Curiously, if you patch rendy memory to call gfx unmap_memory on DynamicBlock::unmap as described above, the cube example errors with the exact same error!  AND, even more curiously, if you unmap the buffer AGAIN as a hack in gl/src/queue.rs handling of Command::CopyBufferToTexture, the call to glTexSubImage2D will not error.  I don't think I'm missing a call to glMapBufferRange anywhere, so my current theory is that glUnmapBuffer unmaps the most recent call to glMapBufferRange, but not all of them.
In any case, I think the best way forward might be not to use the rendy dynamic allocator with the opengl backend and instead substitute the dedicated one?  I'm not really super sure!

I think getting this to work on webgl will require mapping without COHERENT and relying on explicit flushing.  Currently working on it.

I'm very unsure about whether the non-coherent gl buffer mapping is correct...

Okay, I have tested this PR via wgpu-rs and can confirm the cube demo works again!
I have also tested this PR with several other required patches and can confirm this allows wgpu-rs to work on webgl again as it did before!  Only simple translucent quad is tested, and this requires several additional in-flight patches to wgpu-rs, wgpu-native, and gfx-* (start here if you're reading along and are interested).

Now the wgpu-rs shadow example works again (to the same extent it used to work, with some graphical errors).

I've added an implementation of invalidate_mapped_memory_ranges, added both incoherent and coherent memory types, and changed to use glBufferSubData for flushing buffer in my personal branch of gfx.  Waiting on glow to merge my PRs and I will update this PR with those changes.

I have probably added a lot of portability issues with this PR, I'm open to suggestions about what needs to be fixed right now, but I don't have a great way of testing everything I might do.
I know that with the changes I'm going to add as soon as the glow PRs are merged, the gl backend will be using glInvalidateBufferSubData which I guess is core only since 4.3.  A possible improvement here is to either ONLY provide incoherent memory if that function is available, or potentially provide incoherent memory for platforms with emulated buffer mapping and coherent memory only for platforms with native buffer mapping.
I'm open to suggestions here.  I don't mind doing more work on this, but I do feel like the PR has gotten a bit more complex than I was really intending from the outset (and I feel a smidge unqualified to be doing some of the things I'm doing).

Thank you for driving this forward! I think we've narrowed down most of rough spots, here is just a few left (noted below)

You're very very welcome, thanks for being patient with me and teaching me a lot about modern gfx APIs in the process :stuck_out_tongue:

Alright, I suppose there is only getting glow published and maybe reordering the memory types that's left to do here? Or do you think we should land this as is now and follow-up?

I guess it would be better to fix the memory types thing and the brokenness of !buffer_role_change before merging...

Okay, I have a new system for handling memory types that is dynamic based on capabilities rather than the old simplistic system.  I've also fixed what I think are several bugs that I caught in review, so there's kind of a lot of new changes.
This should fix handling the !buffer_role_change case, improve the backend on non-webgl, and order the memory types according to vulkan requirements.

Okay all of your new comments are addressed.  Based on the discussion in gitter (I think I have this right?) I added a new memory type that is cpu-visible, non-cached, and coherent, so there is now also a non-cached gl memory type available (non-cached implies coherent, right?).

Awesome!
Bors r+

On Jun 19, 2019, at 23:27, kyren<EMAIL_ADDRESS>wrote:
Okay all of your new comments are addressed. Based on the discussion in gitter (I think I have this right?) I added a new memory type that is cpu-visible, non-cached, and coherent, so there is now also a non-cached gl memory type available (non-cached implies coherent, right?).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


Cannot override tokenizer with TextBlock (tok_func does not exist as an argument anymore)

Please confirm you have the latest versions of fastai, fastcore, fastscript, and nbdev prior to reporting a bug (delete one): YES
fastai2 0.0.25
fastcore-0.1.30
sentencepiece-0.1.86

Describe the bug
The functionality to override tokenizer is missing now in 0.0.25.
Previously, it used to be tok_func like below:
dls_lm = DataBlock(
    blocks=TextBlock.from_folder(path, is_lm=True, tok_func=SentencePieceTokenizer),
    get_items=get_imdb, splitter=RandomSplitter(0.1)
).dataloaders(path, path=path, bs=128, seq_len=80)

To Reproduce
Colab examples provided below.
Example of how we used to override tokenizer and train in fastai2-0.0.20 (but it fails at inference same as https://github.com/fastai/fastai2/issues/424)
https://colab.research.google.com/drive/1Typ_xZWg5Jds-WDP8v2lEwPAoB2EKbn2?usp=sharing
Failing example with fastai2-0.0.25:
https://colab.research.google.com/drive/1m7eq3sC8pJBIi79j_hoe-8QOWOfGp1-9?usp=sharing
Expected behavior
Expected to be able to override tokenizer function and run inference
Error with full stack trace
--------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-5-cf7c257943cd> in <module>()
----> 1 imdb = DataBlock(blocks=(TextBlock.from_folder(path, tok_func=SentencePieceTokenizer), CategoryBlock),
      2                  get_items=get_text_files,
      3                  get_y=parent_label,
      4                  splitter=GrandparentSplitter(valid_name='test'))

2 frames
/usr/local/lib/python3.6/dist-packages/fastai2/text/data.py in from_folder(cls, path, vocab, is_lm, seq_len, backwards, min_freq, max_vocab, **kwargs)
    210     def from_folder(cls, path, vocab=None, is_lm=False, seq_len=72, backwards=False, min_freq=3, max_vocab=60000, **kwargs):
    211         "Build a `TextBlock` from a `path`"
--> 212         return cls(Tokenizer.from_folder(path, **kwargs), vocab=vocab, is_lm=is_lm, seq_len=seq_len,
    213                    backwards=backwards, min_freq=min_freq, max_vocab=max_vocab)
    214

/usr/local/lib/python3.6/dist-packages/fastai2/text/core.py in from_folder(cls, path, tok, rules, **kwargs)
    274         path = Path(path)
    275         if tok is None: tok = WordTokenizer()
--> 276         output_dir = tokenize_folder(path, tok=tok, rules=rules, **kwargs)
    277         res = cls(tok, counter=(output_dir/fn_counter_pkl).load(),
    278                   lengths=(output_dir/fn_lengths_pkl).load(), rules=rules, mode='folder')

/usr/local/lib/python3.6/dist-packages/fastai2/text/core.py in tokenize_folder(path, extensions, folders, output_dir, skip_if_exists, **kwargs)
    182     files = get_files(path, extensions=extensions, recurse=True, folders=folders)
    183     def _f(i,output_dir): return output_dir/files[i].relative_to(path)
--> 184     return _tokenize_files(_f, files, path, skip_if_exists=skip_if_exists, **kwargs)
    185
    186 # Cell

TypeError: _tokenize_files() got an unexpected keyword argument 'tok_func'

When using tok:
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-6-31c08ee3d74f> in <module>()
----> 1 imdb = DataBlock(blocks=(TextBlock.from_folder(path, tok=SentencePieceTokenizer), CategoryBlock),
      2                  get_items=get_text_files,
      3                  get_y=parent_label,
      4                  splitter=GrandparentSplitter(valid_name='test'))

5 frames
/usr/local/lib/python3.6/dist-packages/fastai2/text/core.py in setup(self, items, rules)
    355         from sentencepiece import SentencePieceProcessor
    356         if rules is None: rules = []
--> 357         if self.tok is not None: return {'sp_model': self.sp_model}
    358         raw_text_path = self.cache_dir/'texts.out'
    359         with open(raw_text_path, 'w') as f:

AttributeError: 'L' object has no attribute 'tok'

Additional context
https://github.com/fastai/fastai2/issues/424

Fixed in master. Note that it should be tok=SentencePieceTokenizer() (i.e with parens) now, since you pass a tok, not a tok_func.


[Feat request] distribute as an Appium driver

Hi there, I see you have this on your roadmap! Let me know if the Appium team can be of any assistance. Using the appium-windows-driver as a basis is probably not a bad start.

I managed to write a driver based on appium-windows-driver. Very early stages, core functionality works, but I will need some help. Here is the repo, currently there is no npm package: https://github.com/picakia/appium-flaui-driver

So is it done?

@pm90pl Unfortunately it's not done, but works good enough for basic testing in my opinion


[tool_crash] FileSystemException: Creation failed, OS Error: Le fichier spécifié est introuvable., errno = 2

Command
flutter create --template app --empty --overwrite .

Steps to Reproduce

...
...
...

Logs
FileSystemException: Creation failed, OS Error: Le fichier spécifié est introuvable.
, errno = 2
#0      _Directory.createSync (dart:io/directory_impl.dart:124:7)
#1      _File.createSync (dart:io/file_impl.dart:303:14)
#2      ForwardingFile.createSync (package:file/src/forwarding/forwarding_file.dart:26:16)
#3      ErrorHandlingFile.createSync.<anonymous closure> (package:flutter_tools/src/base/error_handling_io.dart:282:22)
#4      _runSync (package:flutter_tools/src/base/error_handling_io.dart:587:14)
#5      ErrorHandlingFile.createSync (package:flutter_tools/src/base/error_handling_io.dart:281:5)
#6      Template.render.<anonymous closure> (package:flutter_tools/src/template.dart:321:28)
#7      _LinkedHashMapMixin.forEach (dart:collection-patch/compact_hash.dart:633:13)
#8      Template.render (package:flutter_tools/src/template.dart:281:24)
#9      CreateBase.renderMerged (package:flutter_tools/src/commands/create_base.dart:483:21)
<asynchronous suspension>
#10     CreateBase.generateApp (package:flutter_tools/src/commands/create_base.dart:506:23)
<asynchronous suspension>
#11     CreateCommand.runCommand (package:flutter_tools/src/commands/create.dart:363:31)
<asynchronous suspension>
#12     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1394:27)
<asynchronous suspension>
#13     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:19)
<asynchronous suspension>
#14     CommandRunner.runCommand (package:args/command_runner.dart:212:13)
<asynchronous suspension>
#15     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:372:9)
<asynchronous suspension>
#16     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:19)
<asynchronous suspension>

[!] Flutter (Channel stable, 3.22.0, on Microsoft Windows [version 10.0.22631.3593], locale fr-FR)
    • Flutter version 3.22.0 on channel stable at C:\Development\flutter_3_22\flutter
    ! Warning: `dart` on your path resolves to C:\Development\dart\Dart\dart-sdk\bin\dart.exe, which is not inside your current Flutter SDK checkout at C:\Development\flutter_3_22\flutter. Consider adding C:\Development\flutter_3_22\flutter\bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 5dcb86f68f (7 days ago), 2024-05-09 07:39:20 -0500
    • Engine revision f6344b75dc
    • Dart version 3.4.0
    • DevTools version 2.34.3
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Windows Version (Installed version of Windows is version 10 or higher)

[✗] Android toolchain - develop for Android devices
    ✗ Unable to locate Android SDK.
      Install Android Studio from: https://developer.android.com/studio/index.html
      On first launch it will assist you in installing the Android SDK components.
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).
      If the Android SDK has been installed to a custom location, please use
      `flutter config --android-sdk` to update to that location.

[✗] Chrome - develop for the web (Cannot find Chrome executable at .\Google\Chrome\Application\chrome.exe)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✗] Visual Studio - develop Windows apps
    ✗ Visual Studio not installed; this is necessary to develop Windows apps.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

[✓] VS Code (version 1.89.1)
    • VS Code at C:\Users\Didier\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.84.0

[✓] Connected device (2 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [version 10.0.22631.3593]
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 124.0.2478.97

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 5 categories.

Flutter Application Metadata
No pubspec in working directory.

Closing this as a duplicate of https://github.com/flutter/flutter/issues/142537

the bug is an access right issue as this behaviour happens as well with other tools like eclipse and even with other framework as this happens as well with angular.
Microsoft says access rights come with user access rights but I got notifications saying cmd.exe is blocked for any security reason while both angular and flutter are installed throughout maven plugins.
I hope it helps.


Feature: Bots Api

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


[PHP7] Consider to deprecate yii\base\Object as object might become soft-reserved

PHP 7 will soft reserve object as a possible typehint for a 7.x release (or may never use it at all). Deprecating yii\base\Object in favor of yii\base\BaseObject (or a better name) early (in 2.1) might reduce some pain once installations are upgraded if php should decide to use the object name.
I'm not sure if the patch below is the best way to go forward as the deprecation notice is only triggered if parent::__construct() is called in all child classes. However triggering the deprecation message on autoload makes it harder to locate the class using the old inheritance chain.
The deprecation is based on the fact that php in the future might use object; causing the class declaration to cause a fatal error.
Possible patch (only targets the framework itself not extensions, no tests for the deprecation notice).:
https://github.com/yiisoft/yii2/compare/master...suralc:deprecate-php7
I did not create this as a pull-request as the vote is not yet formally closed. The vote on soft-reserving object sits at 38:10 in favor so it is likely going to pass.

Thanks for pointing this out, need to check it.

Will the name be case  sensitive or not?

I guess both will be reserved. We'll see when it will be accepted and someone will create a patch.

Class names are case insensitive so it would not matter in which case we write it.

@cebe

[...] the following typenames are now reserved:
Resource
Object
Mixed
Numeric

http://marc.info/?l=php-internals&m=142833998201071&w=2

Thanks for the info, have already seen it. This is causing much trouble. Yii 2.0.x will not run at all on php7 because of this... Not sure how to solve the issue yet. As far as I see, there is no way without breaking BC. Renaming the base class of all things is a huge thing...
ref: https://twitter.com/cebe_cc/status/585573046808879104

maybe something like this could work:
<?php

namespace yii\base;

class BaseObject { /* current implementation */ }

if (version_compare(PHP_VERSION, '7.0.0', '<')) {
    // ensure code works on php < 7.0.0 to not break BC
    class_alias('yii\base\BaseObject', 'yii\base\Object', false);
}

You don't need class_alias (could be nicer with deprecation notices, though). If the class isn't used it won't be autoloaded. You could just have Object extend BaseObject and trigger a deprecation notice in it's constructor

Also (thus the soft reserving in the initial post): (and yes, the rfc is ambigous in my oppinion)

To be clear, this RFC is about declaring these names as reserved, not
about actually /using/ them.  There's no language in the RFC about
actually throwing errors or other code-breaking behavior.  Therefore,
even should all of them pass, it does NOT mean that your code using
these names suddenly stops working on PHP7.  It means that you have
been warned that using the names of intrinsics is a bad idea, and that
the language reserves the /right/ to make doing so an error at some
point in the future.

http://marc.info/?l=php-internals&m=142654982915943&w=2

okay, thats weird, imo it should add some implementation that stops using the words as class names.
The RFC itself is very clear about this:

This breaks any and all cases where these new reserved words are used in class, interface or trait names. It does not break any usages as function or method names or as class constants.

You don't need class_alias (could be nicer with deprecation notices, though). If the class isn't used it won't be autoloaded. You could just have Object extend BaseObject and trigger a deprecation notice in it's constructor

tests like $var instanceof \yii\base\Object will fail if there is no alias. Also code in user applications extending from Object will break.

I initially thought about this (this should also give you the name of the class extending object, so you have a starting point in the error message): (as you cannot define an alias using a reserved name anyway).
https://github.com/yiisoft/yii2/compare/master...suralc:deprecate-php7#diff-159a544214ef8467c221cbd60a4b2205L77
You could introduce the BaseObject -> Object hirachy in 2.0.x without breaking BC. And have Objects ctor trigger or throw in 2.1.
However, while this approach might be better debuggable it requires the class to never be loaded on the 7.x release that may utilize Object (or 7.0 to how I'd understood the rfc initially) or it will fail horribly. I'm not convinced on either approach, so I'll leave that decision to others.

You won't be able to hint against yii\base\object anyway if it is handled like the scalar type names.
Some clarification on how the rfc will be handled might be required to determine the best way to move forward.
edit: I missed a point in the text that was located here earlier, so I removed it.

You won't be able to hint against yii\base\object once the name is used, if it is handled like the scalar type names.

thats clear, but we can do this to keep BC on PHP versions <7.0.0

This could be solve without BC break.
We need to rename yii\base\Object class to yii\base\BaseObject, adjusting any internal inheritance. So yii\base\Component extends yii\base\BaseObject.
Then we simply re-create yii\base\Object in following way:
namespace yii\base;

class Object extends BaseObject
{
    // empty
}

After that framework code will become compatibale with PHP 7, while any developer, which uses ealier   version and yii\base\Object will never notice anything.

Although, no.
This would not work for checks like:
if ($object instance of 'yii\base\Object')

If developer relies on such code anywhere it will break.

https://github.com/php/php-src/blob/PHP-7.0.0/UPGRADING
  Furthermore the following class, interface and trait names are now reserved
  for future use, but do not yet throw an error when used:

      resource
      object
      mixed
      numeric

So this one would not be a problem for PHP7 release.

Still it may become a problem at PHP 7.1 or other future releases.

Should consider taking a clean compatible version  php 7 or higher warning of possible incompatibilities changes in php code, and could apply all patches delayed for fear bc break, and maintain other yii2 version with less than 7 php for a while.

for now there is no need for action anymore as yii will still run on php7. we can consider a change in 2.1 to get rid of Object.

Why not define the class alias in 2.0.x, and add a notice to the documentation of Object that BaseObject should be used instead? That way we can start using BaseObject now, and we'll have less code that will be broken later.

... and mark Object class as deprecated

Maybe it's too crazy but I throw it anyway ...why not "duplicate" the yii\base\Object using a new name and start with the deprecation "ads" about the chance of PHP 7 ?

what do you mean with "and start with the deprecation "ads" about the chance of PHP 7" ?

Start informing there is already a new namespace/class available in case PHP 7 is adopting this restriction... I know it could sound crazy but you will guarantee not to break backward compatibility

PHP 7.0.x will not adopt this restriction, it may come in 7.1 or 7.2 or later if they find a need for it.

https://github.com/php/php-src/pull/2080

RFC for this was accepted and (probably) object keyword will be reserved in PHP 7.2.

https://github.com/php/php-src/pull/2080#issuecomment-310924120

its broken now:
$ php --version
PHP 7.2.0alpha3 (cli) (built: Jul 14 2017 14:17:25) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0-dev, Copyright (c) 1998-2017 Zend Technologies

$ php vendor/bin/phpunit

Fatal error: Cannot use 'Object' as class name as it is reserved in /home/cebe/dev/yiisoft/yii2/framework/base/Object.php on line 77

We need to rename Object class but as far as I see we have not really discussed a name yet.
Imo Object is a really weird name for class as it is not an instance but a class. BaseObject for that would have just the same issue.
How about naming it what it realy is: BaseClass ?

Should be ConfigurableObject or ConfigurableClass then, as it implements Configurable interface.

It implements two things: Configurable and Property feature.

@cebe Usually we deal with instances of this class, so IMO Object is more natural than Class.

Properties are not the matter of interface or meaning and are not bound to just setters and getters.
For example: if you parse XML document using SimpleXML lib you will receive SimpleXMLElement object with virtual properties matching the source doument tags, which are not declared anyhow at SimpleXMLElement class itself.
Also logic put into Object::__set(), Object::__get() can be easily changed in its decendants completly, while demands put via implemented interface are mandatory.

Imo Object is a really weird name for class as it is not an instance but a class.

Class names describe the instances of that class, so the Object name was just fine, since instances of Object were objects. I would expect an instance of class Class to be a class. In Java, it is.

Class keyword represents a set of objects, while object keyword represents a single object.
Over entire framework we follow convension which uses singular noun form instead of plural - same should be here.

How about just Configurable?

How about just Configurable?

It is already taken by an interface.

Then ConfigurableClass sounds fine.

I really don't like using "class" as part of name for... class. And I completely don't understand problems with using "object" in the same context. PHP already doing it, and this issue is the best example that "object" is more intuitive in this case - PHP 7.2 will introduce object typehint, not class.

Either object or class is fine to me. Let's vote. 👍 for class, 👎 for object.

Thanks for the comments, you are right, object makes more sense.

If we're going to have more in it than being configurable, lets rename it to BaseObject.


MsalInterceptor to aquire access token silently

Library

[x]<EMAIL_ADDRESS>(2.13.0)
[x]<EMAIL_ADDRESS>(2.0.0-beta.2)

Description
The documentation for acquiring an access token says:

It is best practice to attempt an acquireTokenSilent call before using the interactive APIs if you have already logged in. This allows you to prevent unnecessary user interactions.

I agree with that best practice, and I wonder why the MsalInterceptorConfiguration doesn't support setting InteractionType.Silent as interactionType
Every time a user needs access to a different protected resource, the MSAL interceptor gets the proper access token and adds it to the request, but why not do it silently? As a result of the current implementation (using InteractionType.Redirect) we get a bad user experience with unnecessary redirectons.
In my humble opinion this makes the MsalInterceptor unusable, it should retrieve the tokens silently when possible making the process transparent to the user.
Is it planned to have this behavior (silent by default) on the interceptor? (I guess I'll have to use a custom interceptor in the meantime)
Source

[ ] Internal (Microsoft)
[x] Customer request

My bad, after checking the source code it seems that is indeed the default behavior.