Add Minershards Token

为确保 Token Profile 的顺利通过，务必逐一确保以下检查项并补充项目资料：
.json 及 .png 文件检查项

[x ] logo 尺寸：120*120 px
[x ] logo 背景：透明
[x ] 代币有至少一笔成功的转账记录
[ x] 此项对于 ERC-20 项目方：合约地址有大小写（做 checksum）
[x ] .json 和 .png 文件名一致（包括大小写）

项目资料：
官方公告：
团队背景：
项目基本情况：
媒体报道：https://www.facebook.com/Minershards
收录的交易所：
转账所需 Gas Limit（对 ERC-20 项目方）：（默认为 60000）

Please check the following to ensure a successful verification of Token Profile
.json and .png document checklists

[x ] logo dimensions: 120*120 px
[x ] logo background: Transparent
[x ] At least one transaction on the token contract
[x ] For ERC-20 project teams: Upper and lower capitalized alphabets in token address (For checksum purposes)
[x ] Same document name for both .json and .png (Including capitalization)

Project background:
Official announcement:
Project team background:
Project basic information:
Media publications: https://www.facebook.com/Minershards
Tradeable exchanges:
Recommended Gas Limit (For ERC-20 project teams) for transaction: (Default is 60,000)

请修改state字段的值

sorry what do you mean?

Updated the gas limit. Hope that is what you meant.
Sent from ProtonMail mobile
-------- Original Message --------
On Dec 7, 2020, 5:58 PM, sfsy520 wrote:

请修改state字段的值
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

state should be NORMAL or LOCKED

updated thanks

pls add website and official announcement

website and official announcement added
Sent from ProtonMail mobile
-------- Original Message --------
On Dec 17, 2020, 9:04 PM, sfsy520 wrote:

pls add website and official announcement
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

In order to ensure the authenticity of the information submitted, please publish an announcement on your website or official social media channels and attach the corresponding link in “Official announcement”. We recommended a format similar to the following:
#imToken #1636 We are providing XXX token’s information on imToken. After completion, you can see the logo and full information inside imToken’s Token Manager.
Note:

1636 is the PR number, as in: https://github.com/consenlabs/token-profile/pull/1636 This number is the key to verify yourself as the rightful editor of the information to imToken.
The token information can only be changed after the official verification

Already done that on december 6, 2020
https://m.facebook.com/story.php?story_fbid=106834447953515&id=106785967958363&sfnsn=mo
Sent from ProtonMail mobile
-------- Original Message --------
On Dec 21, 2020, 5:17 PM, sfsy520 wrote:

In order to ensure the authenticity of the information submitted, please publish an announcement on your website or official social media channels and attach the corresponding link in “Official announcement”. We recommended a format similar to the following:
#imToken #1636 We are providing XXX token’s information on imToken. After completion, you can see the logo and full information inside imToken’s Token Manager.
Note:

1636 is the PR number, as in: https://github.com/consenlabs/token-profile/pull/1636 This number is the key to verify yourself as the rightful editor of the information to imToken.
The token information can only be changed after the official verification

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

“Official announcement” json updated

该官方公告Facebook账户与官网不一致，无法合并。


MRG: Fix movement compensation IO

Fixes a bug with channel writing for movement-compensated Raw instances.
Closes #2900.

LGTM
merge when travis is happy

Thanks for the quick look. Now I'm sure you have time to make sense of #2868 :)

ahah nice try :)


Using Sqlite as metadata fails

Using
db = superduper(connection_uri,
                metadata_store="sqlite://.superduperdb/test.db",
                )

fails with:
ArgumentError: Invalid SQLite URL: sqlite://.superduperdb/test.db
Valid SQLite URL forms are:
 sqlite:///:memory: (or, sqlite://)
 sqlite:///relative/path/to/file.db
 sqlite:////absolute/path/to/file.db

Addded as remark on #1492


Could not load dynamic library 'libnvinfer_plugin.so.6'

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template
System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 16.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): wheel
TensorFlow version: 2.1.0
Python version: 3.7
Installed using virtualenv? pip? conda?: pip in virtualenv
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version: 10.1
GPU model and memory: Titan XP

Describe the problem
2020-01-16 20:21:32.912603: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libnvinfer.so.6

2020-01-16 20:21:32.912768: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libnvinfer_plugin.so.6'; dlerror: libnvinfer_plugin.so.6:  cannot open shared object file: No such file or directory

2020-01-16 20:21:32.912782: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:30] Cannot dlopen some TensorRT libraries. If you would like to use Nvidia GPU with TensorRT, please make sure the missing libraries mentioned above are installed properly.

Provide the exact sequence of commands / steps that you executed before running into the problem
import tensorflow

Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.
cuda-10-1/unknown,now 10.1.243-1 amd64 [installed]
cuda-command-line-tools-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-compiler-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cudart-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cudart-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cufft-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cufft-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cuobjdump-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cupti-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-curand-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-curand-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cusolver-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cusolver-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cusparse-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-cusparse-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-demo-suite-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-documentation-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-driver-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-drivers/unknown,now 440.33.01-1 amd64 [installed,automatic]
cuda-gdb-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-gpu-library-advisor-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-libraries-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-libraries-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-license-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-license-10-2/unknown,now 10.2.89-1 amd64 [installed,automatic]
cuda-memcheck-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-misc-headers-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-npp-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-npp-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nsight-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nsight-compute-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nsight-systems-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvcc-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvdisasm-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvgraph-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvgraph-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvjpeg-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvjpeg-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvml-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvprof-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvprune-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvrtc-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvrtc-dev-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvtx-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-nvvp-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-repo-ubuntu1604/unknown,now 10.1.243-1 amd64 [installed,upgradable to: 10.2.89-1]
cuda-runtime-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-samples-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-sanitizer-api-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-toolkit-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-tools-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
cuda-visual-tools-10-1/unknown,now 10.1.243-1 amd64 [installed,automatic]
libcuda1-440/unknown,now 440.33.01-0ubuntu1 amd64 [installed,automatic]
libcudnn7/unknown,now <IP_ADDRESS>-1+cuda10.1 amd64 [installed,upgradable to: <IP_ADDRESS>-1+cuda10.2]
libcudnn7-dev/unknown,now <IP_ADDRESS>-1+cuda10.1 amd64 [installed,upgradable to: <IP_ADDRESS>-1+cuda10.2]
libnvinfer-dev/unknown,now 6.0.1-1+cuda10.1 amd64 [installed,upgradable to: 7.0.0-1+cuda10.2]
libnvinfer6/unknown,now 6.0.1-1+cuda10.1 amd64 [installed,upgradable to: 6.0.1-1+cuda10.2]

Note this doesn't occur on nightly

The solution isn't to downgrade tensorflow (there is no problem with tensorflow 2.1, just the install docs). Install the missing library:
apt install libnvinfer-plugin6=6.0.1-1+cuda10.1

There is a PR to fix the docs.

It leads to another error

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libnvinfer-plugin6

I don't know the specifics of your OS/package manager, but it is likely there is a conflicting package or you did not enable the right repos. This works on Ubuntu 16.04/18.04
Is is supposed to work on a system without NVidia card and hence without CUDA? And why would an NVidia-specific package be required in the first place? I am getting precisely the same error just importing tensorflow 2.1 from Ubuntu shell under Windows WSL. It goes away if I downgrade to tensorflow 2.0.

@Black-Behemoth Tensorflow 2.1 is no longer split into a gpu and non-gpu package

@Black-Behemoth Tensorflow 2.1 is no longer split into a gpu and non-gpu package

Does not explain why "import tensorflow" works in tensrflow 2.0 but attempts to invoke  a cuda library in tensorflow 2.1. On a laptop with an AMD card no less.

Had the same issue, agree with @gunan that tensorRT is not needed.
Installing conda install -c anaconda cudatoolkit=10.1 solved the issue.
I have cudnn 7.6.5

@Black-Behemoth Tensorflow 2.1 is no longer split into a gpu and non-gpu package

Does not explain why "import tensorflow" works in tensrflow 2.0 but attempts to invoke a cuda library in tensorflow 2.1. On a laptop with an AMD card no less.

Quoting myself :D  to ad further that I have booted into MacOS, installed Homebrew and then tesnsorflow 2.1. "import tf" does not call for any libraries with cuda in their names there, so I see no reason why they should be needed in the first place on a machine without an NVidia card.

That is correct.
if you install tensorrt, the problem should go away.
But otherwise, TF should continue running.

@Black-Behemoth Tensorflow 2.1 is no longer split into a gpu and non-gpu package

And therefore it should give the user three Warnings whenever you use it on any computer without a Nvidia GPU? Feels odd to me indeed -- but then again -- what do I know.
Getting the same warnings here. (Intel gpu machine)

I couldn't get this to work on Ubuntu 18.04 either - specifically the first part which is supposed to add the repo's didn't work (i.e. nothing added to /etc/apt/sources.list *) so everything else will clearly then fail.
What I ended up doing was to download the deb files directly from http://developer.download.nvidia.com/compute/machine-learning/repos/ubuntu1804/x86_64/
i.e. I located the version of libcudnn7, libcudnn7-dev, libnvinfer6, libnvinfer-dev, libnvinfer-plugin6 for my cuda version (which is 10.2 not 10.1 and I have driver 440 not 418 but it seems to be working) and installed them using sudo apt install

I'm not a linux expert, I checked with grep -r --include '*.list' '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ and the gnome gui tools.

Some additional info I've discovered, the reason it failed for me (Ubuntu 18.04) is the step to install the key

sudo apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/7fa2af80.pub

errors with

gpg: WARNING: unable to fetch URI http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/7fa2af80.pub: Address family not supported by protocol

I'm not sure why, google suggest using http rather than https but that also fails. So I installed the key manually, i.e.

wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/7fa2af80.pub
sudo apt-key add 7fa2af80.pub

Also not sure if it's an error or warning but this probably should be done as the first step, installing cuda-repo-ubuntu1604_10.1.243-1_amd64.deb first generates a missing key message.

@sharonwoo
I solved exactly the same problem by upgrading to CUDA 10.1 (both toolkit and CUDNN). I had CUDA 10.0 on Ubuntu 18.04.

I have the same problem. How to slove it?  Too many answers confuse me .Can someone summarize the solution to this problem?

@ai-starter basically you need to upgrade to cuda 10.1 and install the correct version CUDNN and TensorRT libraries
You should be able to follow https://github.com/tensorflow/tensorflow/issues/35968#issuecomment-577329399
If it doesn't work this is what worked for me - I suspect what works may depend on what you currently have installed / how you installed it.
# install nvidia key
wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/7fa2af80.pub
sudo apt-key add 7fa2af80.pub

# add repo's
sudo bash -c 'echo "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/ /" > /etc/apt/sources.list.d/cuda.list'
sudo bash -c 'echo "deb https://developer.download.nvidia.com/compute/machine-learning/repos/ubuntu1804/x86_64 /" > /etc/apt/sources.list.d/machine-learning.list'

sudo apt-get update

# Install development and runtime libraries (~4GB)
sudo apt-get install --no-install-recommends \
    cuda-10-1 \
    libcudnn7=<IP_ADDRESS>-1+cuda10.1  \
    libcudnn7-dev=<IP_ADDRESS>-1+cuda10.1

# Install TensorRT. Requires that libcudnn7 is installed above.
sudo apt-get install -y --no-install-recommends libnvinfer6=6.0.1-1+cuda10.1 \
    libnvinfer-dev=6.0.1-1+cuda10.1 \
    libnvinfer-plugin6=6.0.1-1+cuda10.1

I am experiencing the same issue with 'libnvinfer_plugin.so.6', even with cuda 10.1 and TensorRT 6.0.
However, 'tf.test.is_gpu_available()' yields True.
Might it be that the plugin doesn't come with the TensorRT installation?

2 hours into troubleshooting this error.    Seems like more trouble than it's worth to me.

Ok, figured mine out.  Here's an outline of what i did.  I was running multiple TF versions, so I wanted to go the manual route.  I've had bad experiences with NVIDIA and Ubuntu nixing each others packages.
Checked https://www.tensorflow.org/install/source#tested_build_configurations for the versions required.
Downloaded local version of CUDA 10.1 from NVIDIA and ran the installer.  Carefully navigated the menus so that it only copied the files to /usr/local/cuda-10.1 directory  (ie: if it wanted to "help" me, i told it "no thanks").
Downloaded  cuDNN <IP_ADDRESS>.tar.gz and tar xvf'd it to my download directory, it created a "cuda" directory
backed up /usr/local/cuda-10.1 by copying it
Copied the cuda/include/cudnn.h to /usr/local/cuda-10.1/include
Copied the contents of cuda/lib to /usr/local/cuda-10.1
Downloaded TensorRT 6 tarball
Extracted TensorRT 6 to my download directory.
Opened my .venv/bin/activate script
Added /usr/local/cuda-10.1 and TensorRT 6 to the LD_LIBRARY_PATH and EXPORT
LD_LIBRARY_PATH="/usr/local/cuda-10.1/lib64:/home/duane/Downloads/TensorRT-<IP_ADDRESS>/lib"
export LD_LIBRARY_PATH

then sourced the environment and ran
python
import tensorflow as tf
tf.test.is_gpu_available()
Wah lah...
2020-02-28 19:39:35.895538: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1241] Created TensorFlow device (/device:GPU:0 with 7386 MB memory) -> physical GPU (device: 0, name: GeForce RTX 2080 SUPER, pci bus id: 0000:08:00.0, compute capability: 7.5)
Then I went into my living room, sat on the lounge, drank a bottle of vodka, and passed out.
Now I feel much better :)

I had to add --allow-downgrade flag to apt-get to install Tensorflow RT libnvinfer6. I.e.:
sudo apt-get install --no-install-recommends
cuda-10-1
libcudnn7=<IP_ADDRESS>-1+cuda10.1
libcudnn7-dev=<IP_ADDRESS>-1+cuda10.1
sudo apt-get install -y --allow-downgrades --no-install-recommends
libnvinfer6=6.0.1-1+cuda10.1
libnvinfer-dev=6.0.1-1+cuda10.1
libnvinfer-plugin6=6.0.1-1+cuda10.1
The problem went away.

I am using anaconda with Ububtu, as mentioned above

pip install tensorflow-gpu==2.0.0
pip install tensorflow==2.0.0

worked for me too

Just to clarify, the install instructions for Ubuntu 16.04 should be updated; there are several errors, one being that cuda-10-1 is the appropriate cuda package, the other is that libnvinfer-plugin6=6.0.1-1+cuda10.1 is missing.
# Add NVIDIA package repositories
# Add HTTPS support for apt-key
sudo apt-get install gnupg-curl
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_10.1.243-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu1604_10.1.243-1_amd64.deb
sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
sudo apt-get update
wget http://developer.download.nvidia.com/compute/machine-learning/repos/ubuntu1604/x86_64/nvidia-machine-learning-repo-ubuntu1604_1.0.0-1_amd64.deb
sudo apt install ./nvidia-machine-learning-repo-ubuntu1604_1.0.0-1_amd64.deb
sudo apt-get update

# Install NVIDIA driver
# Issue with driver install requires creating /usr/lib/nvidia
sudo mkdir /usr/lib/nvidia
sudo apt-get install --no-install-recommends nvidia-418
# Reboot. Check that GPUs are visible using the command: nvidia-smi

# Install development and runtime libraries (~4GB)
sudo apt-get install --no-install-recommends \
    cuda-10-1 \
    libcudnn7=<IP_ADDRESS>-1+cuda10.1  \
    libcudnn7-dev=<IP_ADDRESS>-1+cuda10.1

# Install TensorRT. Requires that libcudnn7 is installed above.
sudo apt-get install -y --no-install-recommends libnvinfer6=6.0.1-1+cuda10.1 \
    libnvinfer-dev=6.0.1-1+cuda10.1 \
    libnvinfer-plugin6=6.0.1-1+cuda10.1

Thanks so much - This worked perfectly on Ubuntu 19.10 for tensorflow 2.1.0 substituting Ubuntu 18.04 libs for the 16.04 ones above

@gunan:  @behdadforghani-cbre's solution to add --allow-downgrades to the last batch of installs solved the issue on two Ubuntu 18.04 machines, it might be good to add it to the install page?
# Install TensorRT. Requires that libcudnn7 is installed above.
sudo apt-get install -y --allow-downgrades --no-install-recommends \
        libnvinfer6=6.0.1-1+cuda10.1 \
        libnvinfer-dev=6.0.1-1+cuda10.1 \
        libnvinfer-plugin6=6.0.1-1+cuda10.1

I had the same issue and I solve it by adding cudatoolkit and cudnnin my environment. if you install tnsorflow with "pip install " the cudatoolkit and cudnn are not added automaticly, not like installing tensoflow with conda that add this libraries automaticlly.
so you need just to install cudatoolkit and cudnnin in your environement by the following command:
conda install -c anaconda cudatoolkit=10.1 cudnn=7.6.4

I had the same issue and I solve it by adding cudatoolkit and cudnnin my environment. if you install tnsorflow with "pip install " the cudatoolkit and cudnn are not added automatically, not like installing tensoflow with conda that add this libraries automatically.
so you need just to install cudatoolkit and cudnnin in your environment using the following command:
conda install -c anaconda cudatoolkit=10.1 cudnn=7.6.4

@lamberta PTAL. Looks like we may need to add tensorrt installation to our docs.
@reedwm I thought tensorrt was optional. Looks like our users are seeing problems if it is not installed?

cc: @bixia1

Just to clarify: following the steps to install TF2 on Ubuntu 18.04 I could make it work (GPU recognised), I just had the same error message as the original poster. TensorRT is indeed optional, but as the --allow-downgrades completed the install I thought it might be a nice addition.
@rmdk just to confirm, you say that you've done everything thru conda, sth like this:
conda install -c conda-forge tensorflow
conda install -c anaconda cudatoolkit=10.1 cudnn=7.6.4

And it worked? If so it might be worth adding it to the instructions.

@jchwenger I installed all my invormnement using pip install, and when i tried to execute my program i had the same issue, so i added cudatoolkit=10.1 and cudnn=7.6.4 to my env using
conda install -c anaconda cudatoolkit=10.1 cudnn=7.6.4, and it work for me.

@rimdk, grand, thank you!

@behdadforghani-cbre's  solution to add --allow-downgrades , solved my issue in ubuntu 18.04

I think this thread summarizes very well what it's like working with cuda/tensorflow

An additional problem I continuously encounter is the repo's mentioned in the installation guide will get updated with the newer version at some point but tensorflow requires a specific version. Hence once you get it working, in order to keep it working you really need to hold the installed packages (I'm specifically talking about apt on Linux). Otherwise next time you update packages it'll roll the cuda packages forward and break everything

Folks, I'm trying to run tensorflow from Google Colab, which can be found here
I get as far as "Training", but when I start running the code I get the following:
2021-02-02 16:40:50.077388: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libnvinfer.so.6'; dlerror: libnvinfer.so.6: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib64-nvidia 2021-02-02 16:40:50.077542: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libnvinfer_plugin.so.6'; dlerror: libnvinfer_plugin.so.6: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/lib64-nvidia 2021-02-02 16:40:50.077562: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:30] Cannot dlopen some TensorRT libraries. If you would like to use Nvidia GPU with TensorRT, please make sure the missing libraries mentioned above are installed properly.
Any recommendations for solving this in this particular situation?

Make sure you have installed TensorRT and Cuda appropriately. This fixed my problem.
I was trying to run on a conda environment where no TensorRT was installed. Later ran the same code on Jetson where everything was configured. Ran flawlessly!

In my case is weird. I create a virtualenv, and I installed the requirements of my project. And my project worked for days. Then suddenly (with the same project). I'm getting this error, I've removed the env/ folder and create it again, installed everything, and it worked. So, it seems something with a lib, not only a problem of install what it is requested on the terminal.


Fight API breakage in zeroconf, fix #7

The first parameter to ServiceInfo.__init__() was renamed to type_ a month ago

thank you!


Activating dsmr sensor stops DSMR from receiving data

Home Assistant release with the issue:
 0.80.3
**Last working Home Assistant release (if known): ?
Operating environment (Hass.io/Docker/Windows/etc.):
 hassbian
Component/platform:
 https://www.home-assistant.io/components/sensor.dsmr/
Description of problem:
I have dsmr reader running on my Pi that also runs HA. Recently, someone showed me DSMRreader info within HA (so like a normal sensor, not an iframe). He send me to https://www.home-assistant.io/components/sensor.dsmr/ . So i added that to my config, and everything seemed to work. But than i noticed DSMR-reader not receiving new data, and the dsmr reader sensor stating it had no data. First i thought the problem was with DSMR reader. I did find the Pi still received telegrams. After trying to pinpoint the problem, i wondered whether me adding the dsmr sensor to the HA yaml was causing the problem, so i deactivated that code, rebooted, and voila: new data was shown in the DSMR-reader graphs again.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:
For now, i just don't use https://www.home-assistant.io/components/sensor.dsmr/ ../ but i thought i would report it for when others have a problem. Or when someone knows a solution.

Learned USB port can only be read by one prog at a time, so need to try something like ser2net.


Error when updating user's default date range

Version
1.26.0
Steps to reproduce
Updating the default date range from Last 24 hours to This month (for example) throws the following message Application error: a client-side exception has occurred (see the browser console for more information).
Current fix
Clear the localStorage (via web inspector) and delete the value umami.date-range (undefined)

I have the same issue.
Clearing the localStorage removed the client side error but I was still unable to set the date range afterwards via the UI.
As a workaround I've set the date range manually ibn the localStorage: "30day", "1month", ... instead of "24hour"


JBDS (DevStudio) and CDK terminology fixes

Changes:

'JBDS' to 'Developer Studio'
'the CDK' to 'CDK'
minor related fixes

See https://mojo.redhat.com/docs/DOC-1088906 for reference.

Some places use just "Developer Studio", which is a bit too generic. Should maybe use a macro to expand to the full form?

@Ladicek, I believe it's enough to use the full form in the beginning of a section (so the context is established) and then continue with "Developer Studio". Using the full form everywhere would be a mouthful...

@rkratky I'd agree, but I don't think this is what this PR achieves. It looks like "JBDS" was just replaced by "Developer Studio", so there will be places where "Developer Studio" will occur without context (though I'd have to check the rendered form to be sure about this). Also I think we're just using full forms of everything everywhere in these docs.

You're right. I'll update the PR.

LGTM:) Please let me know when you update and I'll merge.

@rkratky @inoxx03 are you all still working on this?

@rhoads-zach, I was out for a week. Still in my TODO.

@rkratky do you think you'll get a chance to work on this again in the near term?

@rkratky If you're busy right now, I can take care of this PR, if that's OK.

@inoxx03, that would be most kind of you. Apologies for stalling on this.

@Ladicek @rkratky I've changed the name to full form in the title. Admittedly, it does seem a bit longish now, but IMHO this way the following instances of the short form 'Developer Studio' don't appear out of context.

I'll merge the changes from a parallel branch on my own fork...

merged: 32def8cc9fdd4607a28790ddc520d518a91c566b

@inoxx03, thanks!


[WIP]add jellyroll for block migration

@Xiaohua-Shen
this's the ursula part of adding jellyroll for block migration

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

ok to test

retest


V2.3 improvements

Various updates & bug fixes to the code

It looks like this wasn't fixed: I installed 2.3 today and ran it on a dir that also had different duplicate finder running, but it looks like it's still crashing, rather than just skipping over, files that get deleted during the run:
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Traceback (most recent call last):][9%]
  File "d:\temp\test.py", line 3, in <module>
    search = dif("_reviewed", show_progress=True)
  File "C:\Program Files\Python39\lib\site-packages\difPy\dif.py", line 53, in __init__
    result, lower_quality = dif._search_one_dir(directory_A,
  File "C:\Program Files\Python39\lib\site-packages\difPy\dif.py", line 117, in _search_one_dir
    high, low = dif._check_img_quality(directory_A, directory_A, filenames_A[count_A], filenames_A[count_B])
  File "C:\Program Files\Python39\lib\site-packages\difPy\dif.py", line 282, in _check_img_quality
    size_imgB = os.stat(dirB + imageB).st_size
FileNotFoundError: [WinError 2] The system cannot find the file specified: '_reviewed\\kc08jt06vv691.jpg'

Hi @Pomax,
Thank you for noticing! Indeed, the bug was only fixed for the search between 2 directories, not for the one-dir search. The issue has now been fixed!
All the best
Elise


no implicits found for parameter S: [F_]

I'm trying to use the Resolve() and Fetch() examples from the 1.1.0-M13 API docs, but I'm missing something. Whether I use Resolve() or Fetch(), after each I see (...) in gray and the tooltip says: no implicits found for parameter S: [F_] I don't know how to fix this or how to figure that out.

Never mind.  It must be a problem with my IDE (Intellij/IDEA).  Despite the message I still see above, the code compiles and runs OK.


Fix Windows Service Management / Upgrade Story

As it stands, the Windows service can be installed in several ways, only one of which flags the MSI to know the service exists (to properly upgrade/uninstall).
We need to handle:

One

Install chef-client
Use chef-client cookbook to create the service
Uninstall chef-client (service should be removed)

Two

Install chef-client
Use chef-client cookbook to create the service
Upgrade chef-client  (service should use most recent client)

Three

Install chef-client with service
Uninstall chef-client (service should be uninstalled)

We should look at moving the upgrade/install process to use chef-ingredient.

Having a solid in-place upgrade process for chef-client (on windows and in general) would be a massive win!

It's 2018 and Chef Client installs as a scheduled task OR as a service and the chef_client_updater can upgrade both of those things.  I'm closing this for now - feel free to reopen if there's something else we should be doing here.


fix: sorting on "Modified By" in chart table

SUMMARY
This pr fixes sorting problem for last_saved_by in the chartlist view. The accessor was set to the wrong key.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
before
https://user-images.githubusercontent.com/17326228/129097514-0cdb53d5-27ca-4a86-914e-45cd147d19d3.mov
after
https://user-images.githubusercontent.com/17326228/129101047-c289eb56-6587-4764-b827-014e670e5851.mov
TESTING INSTRUCTIONS
Go to the chart listview page and clicked the modified by sorting button to test out proper sorting.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

/testenv up

🏷 2021.31


Graph enhancement ideas

Couple of minor graph/plot suggestions:

The black on red labels are hard to see
For both plots, it would be nice to have the option to aggregate the bar plots by quarter, and also by year
For the Regional Metrics, plot the met and wave messages independently (lower priority)

I'm not too familiar with Plotly to know what's possible.
Great work so far!

https://ioos.github.io/ioos_metrics/gts_regional.html


Update test to assertGreaterEqual

Description

changed from assertGreater to assertGreaterEqual

Affected Issues

#199

Hi @ramvikrams, thanks for the prompt reply to the ticket! However, I ended up having to address this issue within a different branch so I will be closing this PR.

Sure sir


Delete all empty parent directories if they are empty

This saves a lot of memory since each directory takes at least one block We are starting to see this as an issue because the filesystems are now much deeper due to the SE050

Upstream version: https://github.com/trussed-dev/trussed/pull/181

Replaced by #47


Refactoring

@KateMoreva regarding the refactoring I mentioned above: I think it's best if we don't do this now and go ahead and merge this first and see that we get it working with MoBIE. I will create an issue about the further refactoring ideas so we can keep track of this.
So please go ahead and merge this whenever you think this is ready (note that there are still some merge conflicts to be fixed.)

@KateMoreva regarding the refactoring I mentioned above: I think it's best if we don't do this now and go ahead and merge this first and see that we get it working with MoBIE. I will create an issue about the further refactoring ideas so we can keep track of this.
So please go ahead and merge this whenever you think this is ready (note that there are still some merge conflicts to be fixed.)

@constantinpape, before merging this variant we need to merge MoBIE with the dependency on this repo (https://github.com/mobie/mobie-viewer-fiji/pull/405).

@constantinpape, before merging this variant we need to merge MoBIE with the dependency on this repo (mobie/mobie-viewer-fiji#405).

Ah ok, now I understand.

@constantinpape, before merging this variant we need to merge MoBIE with the dependency on this repo (mobie/mobie-viewer-fiji#405).

Ah ok, now I understand.

Sorry for the uncertainty that I made :)

@KateMoreva I tried to glance over it but it is just too much. I trust you that it is better than what we had before ❤ . I would suggest to just merge it and than further improve it on the main branch. => From me side: please merge.

@KateMoreva I tried to glance over it but it is just too much. I trust you that it is better than what we had before  . I would suggest to just merge it and than further improve it on the main branch. => From me side: please merge.

Ok, thank you! Sorry for the lots of files, should have split them into separate PRs.


fix: safari layout glitch using a CSS property

Details

Use the CSS property willChange: "transform" property to fix border glitch in Safari
Fixed Issues

$ https://github.com/Expensify/App/issues/22861
PROPOSAL: https://github.com/Expensify/App/issues/22861#issuecomment-1636677075
Tests

Launch Safari. Then, log in to the app with your credentials.
Navigate to the settings menu and select the Payments option.
My PayPal payment method exists, so i clicked on it to view the details.
Click on the Delete button to remove the PayPal.me payment method from the app.
A confirmation modal will appear, asking you to confirm your action.
Verified that line breaks on the left and right borders of the modal string have been fixed

[x] Verify that no errors appear in the JS console

Offline tests

Same as above.
QA Steps

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Safari:
https://github.com/Expensify/App/assets/32131367/4b9530bc-a8d6-4176-937f-1118a15fbc9d
Chrome:
https://github.com/Expensify/App/assets/32131367/6210960c-8491-44a4-a741-31ac2e7bdb28

Mobile Web - Chrome

https://github.com/Expensify/App/assets/32131367/e7bed86d-8643-407b-bdb1-d49e42dd3c13

Mobile Web - Safari

https://github.com/Expensify/App/assets/32131367/d1f97cdd-8096-4c74-af52-bb86cfc3a66f

Desktop

https://github.com/Expensify/App/assets/32131367/cd546d75-3703-41ec-889b-f6d2978b2447

iOS

https://github.com/Expensify/App/assets/32131367/ad22d2b3-ef43-4759-b8dd-3dabb3922dda

Android

https://github.com/Expensify/App/assets/32131367/eba50e3e-7fe3-485a-9631-8d81c93105ac

recheck

I have read the CLA Document and I hereby sign the CLA

@fedirjh Updated, I apologize for not adding it earlier, I just thought it was not so important since this glitch is only visible in Safari

recheck

@zaitsev1 Hmm, we can't merge the PR, you need to verify the commits. Can you please follow steps in this link? You might need to generate a gpg key first if you don't have one: https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key

@pecanoro @fedirjh Thank you very much and I apologize for not signing the commit

@pecanoro  I see an error with lint, but locally I don't have any errors with lint :(

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.45-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Soul Sacrifice™ Delta [PCSF00532]

App summary

App name: Soul Sacrifice™ Delta
App serial: PCSF00532
App version: 1.00

Vita3K summary

Version: v0.1.8
Build number: 3248
Commit hash: https://github.com/vita3k/vita3k/commit/5c3754e3
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: CAPCOM
OS: Windows 10/macOS/Linux Distro, Kernel Version?
CPU: AMD/Intel?
GPU: AMD/NVIDIA/Intel?
RAM: 8 GB

Issues

Minor Graphical blocks around fire / effects elements.
No Lock-on UI and Minds-eye does not highlight some objects, Main creatures' points highlighted.
Soul Shards can be very difficult to locate with this bug.
Minor glitches noted but majority of game playable.
One glitch experienced was using beast weapon on Minotaur and upon initiating long attack the game glitched, my Character disappeared, screen blanked and health could be seen dropping from invisible attacks.
But have not experienced this again, once restarted quest it did not happen again.
Game is in a Highly playable state. Additional notes: Avoid Network features, this can make game hang and load for long times.
Local Multiplayer is functionaly to do pacts etc alone.
Screenshots

Log
Recommended labels

A?
B?
C?

please include screenshots and a log

Hi there,
Ill try get that,the glitch was difficult to replicate. But i can try load
logs.
On Sun, 02 Jul 2023, 17:31 othmanead, @.***> wrote:

please include screenshots and a log
—
Reply to this email directly, view it on GitHub
https://github.com/Vita3K/compatibility/issues/1911#issuecomment-1616703662,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5NV3GMH53NXMOP7K2PMWDXOGH6XANCNFSM6AAAAAAZ3PVYAY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Vita3K summary

Version: v0.1.8
Build number: 3259
Commit hash: https://github.com/vita3k/vita3k/commit/be74f383
CPU backend: Dynarmic
GPU backend: Vulkan

This is an example image of a working UI and indicators that work under the games feature "Mind's-eye" there are shaders missing, I.e those that highlight the Monsters/Bosses. and important interactions on screen. in current game see 2nd screen shot.
I have noticed the recent shader update to fix the defects/black boxing around fire and certain effects has been resolved, I am so impressed with the support on this emulation platform you guys are doing such awesome work.
How to I export a log for you guys to take a look at? This game runs phenominally well and it's not even on your compatibility list yet, I don't think, however I would say that besides that 1 time glitch with the "Minotaur" creature that blank screen/char delete/hide and then slow health drain, it has run super stable.
I want to provide as much help to improve stability across the board.
1st screenshot(How the shaders should work)

2nd screenshot (How they are currently working);

Hello i have the same issue, did you fin a solution ?

So where is the game vpk or zip ?

Hopefully you can manage to fix this soon!
IT's quite furstraiting not being able to see bosses health and those special missions where you need to find the invisible things, without the special vision things It's literally impossible to find htem

I am facing the exact same issue, the mind's eye function (down input on d-pad) ain't working properly. My game file is vpk format.

where is  the file i wanna download this

Have same issue. Using latest Vita3K 3573. It was working well in first act i think (with Sortiara). Besides not showing boss hp, mission when you have to use mind eye to find hidden souls are imposible to finish. On the screen from @DartonStaker we can see the hidden soul (left side small light-blue blob/pixels).

Has this been fixed yet?

Hello, I got graphical glitches, especially one that makes he game looks like this all the time:

Well seems like this issue will never be fixed ;/

@sheil1488, you seem to be using opengl as the backend renderer, all you got to do is change from opengl to vulkan under gpu configurations.

@sheil1488, you seem to be using opengl as the backend renderer, all you got to do is change from opengl to vulkan under gpu configurations.

Oh and that fixes the issue of the colors not appearing?

No, it only fixes the issue @sheil1488 showed in that image sadly.


Improve <Tabs> component keyboard interactions

What kind of changes does this PR include?

Changes to Starlight code

Description

Closes #233

As discussed in #233, this pull request stops intercepting the down arrow key in the <Tabs> component to follow the ARIA Authoring Practices Guide for the Tabs pattern:

If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.

Altho, this is not the entire story as the guide also states that when the tabpanel does not contain any focusable elements or the first element with content is not focusable, the tabpanel should set tabindex="0" to include it in the tab sequence of the page. The current implementation is always setting a tabindex of -1 through the rehype tabs processor.
This PR also introduces a change to follow this behavior. For example, with the following <Tabs> component:
<Tabs>
<TabItem label="tab 1">

basic text

</TabItem>
</Tabs>

Tabbing through the page will first focus the tab list and then the tab panel (which does not contain any focusable element).

Altho, with the following code:
<Tabs>
<TabItem label="tab 1">

<input type="text" placeholder="email" />

</TabItem>
</Tabs>

Tabbing from the tab list will focus the input element immediately.

Finally, this PR adds support for the Home and End keys to navigate to the first and last tab respectively.
Accessibility-wise, I tested the changes with VoiceOver on macOS and the behavior seems to be correct and match the one from the ARIA Authoring Practices Guide and the React Aria implementation altho I do not have a machine with Windows to test with NVDA or JAWS.
Notes:

The rules to detect if a tabpanel contains a focusable element are borrowed from React Aria which follows this pattern as described in their documentation.
The rules are CSS selectors and used through the hast-util-select package. They could all be converted to JS conditions (e.g. node.tagName === 'input' && node.attributes.type !== 'hidden' && // etc.) but I think the CSS selectors are way more readable in this case. Any thoughts?
The changeset I added is fairly generic, should it contain a list of all the exact changes instead?

Thanks @HiDeoo, this looks great!
All the patterns seem to work in NVDA, the only issue is that with this change, using the shortcut to read the next line (↓) doesn't work, since we aren't capturing the down arrow and moving it to the tab panel.
I did some research, and most tabbed interface implementations don't do this as well, I know this is a recommendation from the Inclusive Components book but it might as well be an oversight for not considering the need to scroll the page.
Letting Chris know that this tradeoff is worth taking, considering the down arrow works again the moment the user focus (Tab) inside the tab panel.

All the patterns seem to work in NVDA

Thanks for taking the time to check this out, really appreciate it.

I did some research, and most tabbed interface implementations don't do this as well

Yeah, this is pretty much the conclusion I came to as well, although I guess it does not 100% mean that it's the right thing to do considering it is such a complex topic with lots of considerations.


Jacoco support

Gradle now supports Jacoco. You can enable it with buildTypes.debug.testCoverageEnabled true and then run ./gradlew connectedAndroidTest.
This works in Java projects, but in my Scala project, the report is not generated.


Recreate silence loses matchers

What did you do?

Create a silence with some dummy matchers
Wait for it to expire
Navigate to expired silence list
Click recreate

NOTE: The URL does not contain any parameters, it's just http://localhost:9093/#/silences/new?filter=
What did you expect to see?
A form prefilled with the matchers from the previous silence
What did you see instead? Under which circumstances?
An empty form with no matchers.
Environment
Raspberry PI, Alertmanager 0.14.0
Mac OS X, Current HEAD of Github

System information:

$ uname -srm
Darwin 15.6.0 x86_64

Alertmanager version:

0.14.0 as well as HEAD

Alertmanager configuration file: Sample from README

The bug seems to be here: https://github.com/prometheus/alertmanager/blob/master/ui/app/src/Views/SilenceList/SilenceView.elm#L107
I tried fixing it myself, but my Elm is severly lacking :D

fixed by https://github.com/prometheus/alertmanager/pull/1270


Refactored Stream.flatMap internal iterator to a static class

Stream.flatMap uses an inner class for iteration, with the effect of the result stream holding an unnecessary indirect reference to the head of the source stream, resulting in a "temporary" memory leak.
In my project which uses vavr I wrote a unit test to verify that memory is in fact cleaned up correctly during iteration of lazy streams, but it failed because of this bug.
I did a quick search for unit tests in vavr related to memory usage/leaks, but found nothing of relevance. So no test has been written for this change; it does not alter the behaviour of any functions as such.

Codecov Report

Merging #2229 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #2229      +/-   ##
============================================
+ Coverage     97.14%   97.14%   +<.01%
  Complexity     5282     5282
============================================
  Files            94       94
  Lines         12177    12180       +3
  Branches       1595     1595
============================================
+ Hits          11829    11832       +3
  Misses          194      194
  Partials        154      154

Impacted Files
Coverage Δ
Complexity Δ

vavr/src/main/java/io/vavr/collection/Stream.java
99.02% <100%> (ø)
268 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 63d77ac...77efbff. Read the comment docs.

This is great, many thanks!
I was aware of the fact that (method local, anonymous) inner classes bind the implicit this (within a non-static context) and thought we only use inner classes in static methods. I will seize the opportunity to double-check the whole code-base.
Thanks again! 👍🏼

Glad to be of help 👍

Update: There are 6 occurrences of new Iterator()... left in the codebase. All of them look ok to me (they produce no memory leaks). Especially Stream.cycle, which needs to hold a pointer to this.

The others looked ok, yes.
Especially for Stream, I think it's important to not have unneeded references, because I figure it is commonly used to process large amounts of data, like in my case. When I think about it, the leak observed here would lead to the entire source stream being unable to become garbage collected during an ongoing consumption, because of the memoized elements, and the first Stream node indirectly referencing all items after it.

I will prepare a bugfix release 0.9.3 the next days.


account git

Users can no more save the time that their git credential should be cache?
Can we add this here ?

this value is store in vault with the secret : gitCredentialCacheDuration

We removed this field because we assumed 0 (infinity) would always be the preferred default.
Was there user complaints about it?
Anyway, sure, I can add it back in if you think it's relevant.

0 is not working.
There is no cache at the moment.
But anyway I prefer that users can control this security feature

What's the correct value for infinity then?

i don't know

but infinity is very bad for security so I really don't like that

Considering we have IP protection enabled by default  and a services password I though the the git password was protected enough already...
What do you see as default? 2 hours?

The last default was no cache (0)
I think it's a good default because it's the standard configuration of git.

Ok that's a good thing. To change a default I have to write a migration script...


Manage remotes

add dialog page to the conan options to manage remotes:

list remotes
add remotes
remove remotes
allow to specify remote for conan install

I was tempted by this idea several times also.  However, I came to believe these are actually the kinds of features that we should leave out of the extension for a long time, and possibly forever. I think they will become very time-consuming and difficult to support long-term, especially given the limited resources we have.  I think we should leave GUI menus for any non-essential Conan operations out of scope. (I mean essential for visual studio project integration).  I would like to build a systray-based application someday for that, but that's another topic.

I'd just like to be able to specify a -r option to the conan command via the extension. Otherwise in some cases I'm better off running conan install manually first to save time if I have binaries in my own remote that aren't in conan-center.

Hi! This issue has raised also for the CLion plugin (private messages). I'm wondering if these plugins/extensions should add some kind of proxy to Conan configuration (remotes, some typical config vars,...). And it always arises the alternative of having a different window to configure Conan (systray, exec, server,...) so it can we the same for VS, CLion, cmd,... but it wouldn't have a native UX. I'm on the fence with this, IMHO I think it is easy enough 😕

@jdee, for your request, there are two approaches I can think about:

adding an "install args" to configuration, like the CLion plugin does, but it is something that would apply to every project.

Using something like this approach (https://github.com/conan-io/conan-vs-extension/issues/171) to override the install command


LLVM 3.9 improvements

Splits outputs in clang like we do in 3.8 and 4.0 to avoid runtime dependency on Python in the main derivation output.
I also disable TSAN on Darwin to maintain consistency with 4.0, which disables it because it forces an unfree dependency in the stdenv.
Motivation for this change
Closure size and consistency with 4.0
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Err, I should've based this off staging.

Would it be appropriate/neater to use moveToOutput here? Creates directories and is benign when pattern doesn't exist, so might be a bit neater.  Haven't used it much myself though so whatever you think is best :).

Oh, I didn't even know about that!

Note that it supports wildcards (but you have to quote them so they're not destroyed by bash immediately).

Going to merge this for now and then switch all the LLVM expressions to use moveToOutput separately.


Generated helpers in v3.9.5 decrease code coverage

TypeScript Version:  3.9.5
Search Terms: typescript coverage barrel
Code
"use strict";
var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    Object.defineProperty(o, k2, { enumerable: true, get: function() { return m[k]; } });
}) : (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    o[k2] = m[k];
}));
var __exportStar = (this && this.__exportStar) || function(m, exports) {
    for (var p in m) if (p !== "default" && !exports.hasOwnProperty(p)) __createBinding(exports, m, p);
};
Object.defineProperty(exports, "__esModule", { value: true });
__exportStar(require("./file1"), exports);
__exportStar(require("./file2"), exports);
//# sourceMappingURL=index.js.map

Expected behavior:
Coverage 100%
Actual behavior:

The autogenerated code is not covered. If full coverage of the generated code is not possible, could you please consider adding a coverage ignore comment?
Playground Link: https://github.com/waldekmastykarz/c8-ts395-repro
Related Issues: n/a

Out of curiosity: Is there a reason you choose to generate coverage for the transpiled code and not for the TypeScript sources?

Yes, because if you look at coverage of the .ts file, you see the decreased coverage but don't get any information about what's wrong. All lines seem to be hit, yet the coverage is less than 100%

Our helper functions aren't built with code coverage in mind, so I don't think we'll be changing it. One solution might be to switch to tslib to see if that helps. Alternatively, I believe Istanbul seems to be able to deal with this problem by giving itsourcemaps. It sounds like this is a feature request in C8.

@DanielRosenwasser I understand that the helpers are not built with coverage in mind and it makes perfect sense. With that being said, would it be possible to include comments in them that would exclude them from the coverage reports? That would allow you to retain flexibility with regards to the helper code without negatively affecting developers who use code coverage tools in their projects.

We produce sourcemaps, which are the canonical way to represent "where this code came from"

Correct, but somehow the coverage doesn't cover all paths. Not sure if that's limitation of the coverage tools or the consequence how the helpers are built. Following to what @DanielRosenwasser mentioned, if the helpers are not built with coverage in mind, then it would be fair to exclude the from coverage.


Solarized Light Code Block Selection not working

Dark mode

vs
Solarized Light Code Block Selection

It's a bit tricky because the Solarized spec does not provide a color for this context. So the options would be to either invent a new Solarized color, or make code blocks use the main background color, possibly with an outline.
In the meantime you can set a different text selection color using Style Settings.

This is fixed as of 5.1.5


Added View extension to make it easier to implement it in any view

Description
Added View extension to make it easier to implement it in any view
Checklist

[*] Have you added tests where necessary? Do all the test pass?
[*] Have you added descriptive comments to your code?
[*] Have you updated the documentation related to this propo

import SwiftUI

struct ContentView: View {

    @State private var counter: Int = 0

    var body: some View {
        Button("🎉") {
            counter += 1
        }
        .confettiCannon(counter: $counter)
    }
}


fix: stop useNetworkConnectivity from causing hydration errors.

Description:
We encountered hydration errors like:
Error: Hydration failed because the initial UI does not match what was rendered on the server.

Solution:
The issue was resolved by rewriting the hook to use useSyncExternalStorage, ensuring consistency between server and client rendering.
Request for Review:
The change has been tested and eliminates the hydration errors. Looking forward to your feedback and hoping for a quick merge.

@ShafSpecs are you able to have a look at this?

Sorry, just doing so. For some reason, I don't get emails about actions in this organization 🥲. I need to fix that, my bad

After the merge, you can check out your fix by installing the dev version, either via: npm i @remix-pwa/sw@dev or npx remix-pwa upgrade -D -p sw.
Sorry, I'm not with my PC this week and can't check it out fully. Once I'm able to, I would push to latest. And thx for the PR ❤!

I mean client, just remembered the hook isn't in sw but the client package


Automatically escape resource argument in constructor

This PR modifies the constructor so that it automatically escapes the resource argument to the constructor in order to handle special characters like "{}" properly.
Helps solve https://bugzilla.redhat.com/show_bug.cgi?id=1346034

@bzwei Please review.


Schedule list not updating correctly

Describe the bug
Schedules list not updatin when other person adds a schedule while schedule page has already been opened.
To Reproduce
Steps to reproduce the behavior:

Person1: open Schedules page
Person2: add Schedule

Expected behavior
After Schedule has been added it should appear in list after refresh

Fix for this is in the pipeline.
Actually reworked the overall behaviour of how pages are loaded and refreshed.
It's not yet the way I want it to be but ut will do for now.


version mismatch means cargo update can't work

And depending on someone else's branch from ours is dangerous.

Proven out here: https://github.com/libra/libra/pull/5044

This is simply an instance of https://github.com/dalek-cryptography/ed25519-dalek/issues/126, which has two solutions:

reusing the present fork, which bastardizes its role as an auditable, thin layer of formally-verified crypto over ed25519,
patching the merlin dependency, in exactly the way done here:
https://github.com/novifinancial/fastpay/blob/0269f7a8379826b9bb15ae8017ccd6a7676b6e3b/Cargo.toml#L13-L22

I much prefer that second approach, since this is a transient problem: https://github.com/dalek-cryptography/ed25519-dalek/pull/127 has been merged and will be in the next ed25519-dalek release, no need to resort to polluting this fork for that.

@huitseeker the reason to for this is it's currently blocking the ability to run "cargo update", which I'd like to do to ensure we're up to date before we lock master for the release branch later this week.

Also trying to patch merlin from 1 to 2.0.0 wont work for us (it's a new major version):
https://github.com/rust-lang/cargo/issues/5640
Since you might want fiat2 to exist for a merge or some such, I've created a fiat3 branch in novifinancial to reference from libra.
Seems these are the to paths forward other than waiting and having broken tooling, unless I'm missing something.

Made obsolete by https://github.com/libra/libra/pull/5061


Behaviour of sendMessage

There's some discussion that has arisen as to what the behaviour of sendMessage should be (see #83, #183).  The function currently works by passing an object with certain properties set on it ('attachment', 'url', 'sticker'...).  This object is then fed through a chain of else-ifs which check these properties in a secret order ('attachment' > 'url' > 'sticker'...).  For reference, this is roughly the relevant block of code.
I'd like to propose removing the 'else's from this control flow and simply try to handle all types of message at once (this is even supported by the client in some cases, as seen in #83).  Furthermore I want to take the behaviour of setOptions and throw an error if the passed-in object has any unsupported properties, or in the case that we cannot support the combination of two properties.  I find this prevents mysterious errors due to silly typos and stops values getting lost for no reason.

I like the idea of allowing some unknown usecases by default, but I'm scared that we'll have to prevent a lot of edge cases. Also how would we describe the edge cases of cannot support the combination of two properties other than a bunch of ifs?

I'm mostly hoping that there wouldn't be too many of those cases, I guess.  If the need arose, we could technically write some logic that would allow us to define an array of unsupported combinations or properties...
var input = {body: "Test"};
// Fake unsupported combinations
var unsupported = [
    ['body', 'sticker'],
    ['attachment', 'url']
];

if (unsupported.some(c => c.every(v => input.hasOwnProperty(v))))
    throw new Error('Unsupported');


Implementation of std::scanner::Error for ScanError

Hello
I noticed the ScanError struct did not implement the Error trait, so I've implemented it.

Thanks! The error path is not throughly tested, I think we should add some unit tests for failure cases.


VPN DNS route clashes with Docker Bridge IP (Ubuntu Xenial)

When setting up a VPN on Ubuntu 16.04 (Xenial), it seems that the routes of the default Docker bridge IP (<IP_ADDRESS>) clashed with the DNS IP of the VPN service (<IP_ADDRESS>). This caused DNS lookups to fail on registry.(grid_name).kontena.local, as it was querying the local Docker daemon's DNS instead of the VPN. This was found on a Master node, attempting to push images via VPN to an Image Registry on a grid.
This should be resolved by either printing an error message on VPN creation if the DNS IP conflicts with Docker bridge, or using a different IP address for the VPN's DNS. This issue was not experienced on CoreOS, as the default Docker bridge IP is <IP_ADDRESS>.

Also noting, this issue was resolved by adding "bip": "<IP_ADDRESS>/16" to /etc/docker/daemon.json, deleting the docker bridge network (sudo ip link del docker0), and restarting the docker daemon.

+1 for "or using a different IP address for the VPN's DNS" - Ideally shouldn't have to mess with changing docker config and recreating links on one of the most popular linux distros..

Unfortunately weave-dns does not really seem to offer any option to listen on any address other than the local docker0 bridge:
https://github.com/weaveworks/weave/blob/v1.7.2/weave#L1560
https://github.com/weaveworks/weave/blob/v1.7.2/prog/weaver/main.go#L466
Using a different address for DNS across the VPN would require something like iptables DNAT rules on the nodes.

It appears that even when "fixing" this with the bip method, the containers then aren't able to query domain names from the master (with VPN connection open to grid). Once the VPN connection is closed, all is well and containers with calls to the outside world (e.g. apt-get) can build again, but not push to the registry.

So will this issue always come up any time you connect to VPN on a node from a client with docker installed with the same bridge IP as the node's bridge IP?

Yes, unfortunately it will. :(
I was thinking that it might be possible to do some routing magic on the VPN container. I mean that the VPN would advertise itself as DNS server (to the VPN clients) and just route the DNS traffic to the docker bridge. Kind of DNS proxy :) This might do the trick: https://github.com/janeczku/go-dnsmasq .

Referencing the second issue that you will encounter if trying to use the kontena-vpn on an Ubuntu 16.04 / xenial client: the kontena.local pseudo-TLD clashes with the use of avahi/mDNS for the .local TLD: #264
Workaround is to disable the use of mdns for the libc DNS resolver: https://github.com/kontena/kontena/issues/264#issuecomment-257504308


Support any Forge (not just github or gitlab)

This can be done nicely using:
https://github.com/packit-service/ogr

What do you exactly mean by "support any forge"? Is tmt somehow tied to github? I didn't think so.

I am slo confused :) @pvalena can you share more thoughts?

Ok, so imagine you want comments/pull-requests/forks.... We were discussing git commands, what is cloned etc.. I just thought that bringing this early in could help us avoid duplication/supportability of various cases. Maybe it even can fetch/clone etc. In a 'better way' (tm), which could (maybe) save us some iterations.
All in all it was just something  to keep in mind(it's also under cover of packit, so sharing codebase would be 2x benefitial).


Resolve unknown/undefined types for tracepoints

If a type is defined by a typedef located in a non-included header, clang parser will fail. This change analyses error messages from the clang parser and retrieves the missing typedefs from BTF (if it is used). If all types cannot be resolved, it provides the user a hint: either to include BTF (running with --btf) or to include relevant headers.
Resolves #1154, resolves #730. It should also help with iovisor/kubectl-trace#109.
I was also wondering, if it would make sense to get rid of the --btf option completely. AFAIU, it is used for tracepoints only. Using BTF automatically whenever it is available would make most of the "unknown type name" errors disappear in default bpftrace setup.
Checklist

[ ] Language changes are updated in docs/reference_guide.md
[x] User-visible and non-trivial changes updated in CHANGELOG.md
[x] The new behaviour is covered by tests

I found that if a struct has a member whose type is not in the BTF, then bpftrace hangs (though probably this does not happen in most cases.)
% ./src/bpftrace -e 'struct foo {aaa a;};  BEGIN { @ = ((struct foo*)0)->a}' -b
// hang

I was also wondering, if it would make sense to get rid of the --btf option completely.

I also think using BTF whenever it is available is reasonable. Is there any downside? possible slowdown?

I found that if a struct has a member whose type is not in the BTF, then bpftrace hangs (though probably this does not happen in most cases.)

Correct, thanks for noticing. Even though this shouldn't happen for tracepoints, hanging is not good. I fixed it, now it terminates and shows the corresponding error message.

I also think using BTF whenever it is available is reasonable. Is there any downside? possible slowdown?

I didn't notice any slowdown, in my local setup, the run-times are almost equal with and without BTF. Also, we're using BTF for all other probe categories, where a larger number of probes can be attached at a time (thus more BTF lookups), so I don't see any reason not to use it for tracepoints, too.

I was also wondering, if it would make sense to get rid of the --btf option completely. AFAIU, it is used for tracepoints only. Using BTF automatically whenever it is available would make most of the "unknown type name" errors disappear in default bpftrace setup.

Tentative +1. I remember I tried doing this a couple times but I always hit some kind of realization that it would cause an issue. Can't seem to remember right now. It's possible that I've chipped away at reducing internal usage of --btf that there's no issue anymore.

my only concern is the string parsing of error messages. Not sure if error strings are part of clang API but I'd be worried if it wasn't. I didn't look around too hard in clang for alternative solutions so I'll take it on faith this is the best way.

I don't like this either. I tried to find an API for this, but it seems that there is none. Clang parser replaces all unknown types by int and it seems that it looses the information about the original type name. The only option could be extracting the information from Clang diagnostics (which is what we're doing here, anyway), but it doesn't seem that other parts of the diagnostics are more stable than the message itself.

Tentative +1. I remember I tried doing this a couple times but I always hit some kind of realization that it would cause an issue. Can't seem to remember right now. It's possible that I've chipped away at reducing internal usage of --btf that there's no issue anymore.

The problem will come if the user tries to define a type that is also parsed from BTF. For example this program:
# bpftrace -e 'struct task_struct {int x;} i:ms:1 { printf("%d\n", curtask->x); }'

won't work because using curtask will force parsing struct task_struct from BTF and it will be then defined twice. I don't see a reason for doing this, but I may be missing something.
Anyway, I have a proposal implementation ready. Once this PR is merged, I'll open a new PR where we can discuss further.


Package documents as basemodels also

pydantic.create_model works in generating BaseModel from the existing typed dicts (though it will require some hacking to let additional elements through where they are allowed). Though the resulting BaseModel doesn't have type hints.
It was suggested we package the BaseModel in event_model.documents.pydantic_models and fool type checking with if TYPE_CHECKING into assuming that the BaseModel have the same type as the corresponding TypedDict.

After briefly playing around both alternatives were lacking:
1. Making the model with create_model and TypedDict __annotations__
While this would allow for the args to be type hinted, it would lead to type checking errors whenever BaseModel methods were accessed.
2. Defining the documents twice
Defining separate documents for BaseModels (with the intention of a test to check all annotations match the TypedDict definitions) doesn't work since NotRequired isn't permitted in a BaseModel. This would require swapping out all NotRequired for Optional leading to a lot of unnecessary key: None pairs across the documents.


Will there be an adaptation for Xinference?

Will there be an adaptation for Xinference?

[Xinference] is a powerful and versatile library designed to serve LLMs, speech recognition models, and multimodal models.
at components  models  add   Xorbits Inference (Xinference) .
from langchain_community.llms import Xinference


How do I resume training off a checkpoint?

After training the model to 46 percent there was a power outage. What command do I use to resume training? I'm on checkpoint 26.
Thanks in Advance

I figured it out
python config.py --mode train model_26000
Issue solved therefore closing


There is a vulnerability in Spring Batch 4.2.4.RELEASE,upgrade recommended

https://github.com/pinpoint-apm/pinpoint/blob/4732e4e62abfdb1165cc05d175fdf9f4a00b3342/pom.xml#L147
CVE-2018-1270 CVE-2018-1275 CVE-2018-1272 CVE-2018-15756 CVE-2016-5007
Recommended upgrade version：4.3.3

Thank you for the report.
I'll fix it at 2.4.0.
P.S:
The batch module is not disclosed to the outside, so I think the risk is low.

Pinpoint is not using STOMP over WebSocket in Batch Module


Update build.gradle

fixes #25145

Summary
Adding android Gradle plugin version and react-native version to ext. By that, the library developers can automatically read and use the root project's setting in the library's gradle and so, the whole project has been built with the same android gradle plugin and its dependency libraries rely on the same version of react-native. Also, putting these properties can cause a naming convention among library developers to avoid using an arbitrary name for reading these properties from the root project. (I currently using two libraries that use different names for getting android gradle plugin version just because of the lack of convention)
Note for library developers:
change your android build.gradle like this:
buildscript {
   +ext.safeExtGet = {prop, fallback ->
   +    rootProject.ext.has(prop) ? rootProject.ext.get(prop) : fallback
   +}
    repositories {
        jcenter()
        google()
    }

    dependencies {
        -classpath 'com.android.tools.build:gradle:3.4.1'
        +classpath("com.android.tools.build:gradle:${safeExtGet('gradlePluginVersion', '3.4.1')}")
    }
}

android {
    dependencies {
       -implementation 'com.facebook.react:react-native:+'
       +implementation "com.facebook.react:react-native:${safeExtGet('reactnativeVersion', '+')}"
    }
}

Changelog

[Android] [Added] - root project's android gradle plugin version and react-native version is now accessible for use in libraries' build.gradle files.
Test Plan

Usually it's not recommended to re-import Android Gradle Plugin to submodule, because it's already imported into root project, or RN app. So, I think it's not a prober solution to your problem. I would like to recommend you to change a native module to not use Android Gradle Plugin directly, but from root project.

@dulmandakh
It seems there is a misunderstanding here.
I don't want to re-import the tool in sub module. actually I want to prevent to import and using multiple Android Gradle plugin version in one project. If you take a look at some RN libraries, you'll see some of them strictly using Android Gradle tool version lower than 3.4.1 (some of them using 2.x!!!) because it is not actively maintained by its maintainer. with multiple Gradle tool version, CI servers have to build project with multiple tools that I think it's not proper way.
(As a workaround I already wrote a script to replace the Gradle tool versions of project dependencies with project's Gradle tool version in my current project).
By this PR we can solve the problem in long term and users don't need to handle such cases.

I understand the purpose of this PR, but you still need to make changes to libraries to make use of above changes. Instead, I would like to recommend to fix build.gradle to not use Android Gradle Plugin.

About a year ago, I created a PR to RN to export Android SDK tools version configurations to be used in other libraries, and it helped a lot. I strongly believe that sub-projects or modules shouldn't be using Android Gradle Plugin.

@dulmandakh
sorry but your statements couldn't convince me, please re-open this PR to having more discussion about it.

could you please list of modules you use and having problem?

I created a PR to react-native-keychain https://github.com/oblador/react-native-keychain/pull/227

could you please list modules you use and having problem?

react-native-restart
react-native-svg
react-native-keychain
react-native-community/async-storage
react-native-firebase
react-native-gesture-handler

Also, create-react-native-module by @brodybits and react-native-create-library are library template boilerplates, we can apply your suggestion in there too for fixing the problem for future RN libraries.

What's the status of this PR?

IMHO, Android Gradle Plugin should be loaded only once. Please correct me
if wrong.
This change will allow load AGP many times easily, or hide it. So I don't
like the approach. It's best to fix third-party modules instead.

This change will allow load AGP many times easily

Are you sure about that?!
I don't know how exactly the Gradle system works, but I think it's reasonable to consider AGP loaded once and in next refers, it uses the first cached loaded one.
However, are you have any other idea to solve the problem (prevent sub-modules from using different versions of AGP) your PR on react-native-keychain does not seem to solve this issue. (at least I didn't understand it)

IIRC, an issue that you are trying to solve is AGP version mismatch between
a project and its modules, and you want to share it between them with the
change. Therefore, it means AGP can be loaded multiple times.
What I'm trying to say is that your proposed change might seem fix the
issue, but IMHO it's not a proper fix. So it's better be fixed in modules
instead, or remove AGP usage in modules.

Therefore, it means AGP can be loaded multiple times.

just for clarification, you said "can be loaded" not "will be loaded", does it means you're not sure about that? this is all I'm asking. have you a reference (to AGP documentation) that confirms using same AGP version causes the AGP loaded multiple times? because it does not make sense to me why it has not been cached in the first place and used multiple times. maybe it's a problem with Gradle system.

I don't want to argue with you. But what you are trying to do is share AGP
version and load multiple copies of it without conflict. I don't need to
prove it, because we all experienced it.
IMHO, a PR creator should make sure that he/she is doing right thing and
not causing issues, but mistakes happen.

I don't want either. I just wanted to make sure.
However, my purpose is to prevent from loading different AGP version that causes some conflicts, not to prevent from loading multiple AGP, it is another problem I think (that already exists with current gradle configs) that and my change is not the reason for it. I'm not expert in Gradle system and don't know how exactly it works and this is all I could to do to solve the problem, but, with respect, you continue to oppose me without having a better solution.

I don't want either. I just wanted to make sure.
However, my purpose is to prevent from loading different AGP version that causes some conflicts, not to prevent from loading same AGP multiple times, it is another problem I think (that already exists with current gradle configs) that and my change is not the reason for it. I'm not expert in Gradle system and don't know how exactly it works and this is all I could to do to solve the problem, but, with respect, you continue to oppose me without having a better solution.

I propose that modules shouldn’t include AGP in it, so please help them and create PRs to remove it.

As I said, I don't know how I should do what you proposed. I've read your PR on react-native-keychain and couldn't find any clue. not just me, even @mikehardy has left a comment for you there and we wainting for your response.

Sorry, I didn’t see the comment. I commented on the PR to keychain.

Created a PR to async-storage https://github.com/react-native-community/async-storage/pull/207

another PR https://github.com/FormidableLabs/react-native-app-auth/pull/381

I looked through the linked react-native-keychain issue and reviewed one of the other PRs. I could see this working. I've never made a gradle project using kotlin definitions so I didn't think of it as an option. My only remaining question is if it's possible in the future for react-native to adopt kotlin for gradle, and would that then collide with this new style? I think with the project defined in the root directory of the module (instead of in android/) the answer is no, but I'm checking

@mikehardy some RN Gradle scripts are already converted to use Kotlin DSL, which makes editing easy and has better IDE support. You can have and mix gradle scripts no matter which language is used.

@SaeedZhiany - Could you please provide a link to an app project that has problems when including a dependency with an outdated Android Gradle plugin? It is my understanding that the buildscripts section is not used when a Gradle project is in a subfolder and included as a module. That way, the version that the dependency specifies should not matter at all. I could be wrong though. I'm sure you did plenty of tests, and I want to see it for myself.

@friederbluemle
I've faced the problem in a real project in the company I'm working, so, unfortunately, I can't share the project. but I can explain what was wrong in our project.
we using CI for our project and every time a workflow has been started, the CI server downloads multiple AGP versions, so the first problem is it downloads lots of stuff and causes taking more time to finish the builing process (even we don't consider that it wastes our internet bandwidth), the second and main problem was that it seems the CI server built each module with the module's AGP and sometimes it causes the build failed unexpectedly, the behavior is nondeterministic in our project and it builds successfully in next try. so I had to write a script that reads the main project AGP version and re-write all sub-modules used in the project.
Recently I've thought maybe we can automate this procedure and this is the motivate I raise this issue #25145 and this PR and this discussion.
Although I didn't figure out @dulmandakh's approach yet, but it seems his solution is better than mine and it's enough for me (I just want the problem solved), so if you and @cpojer prefer his solution, we can close this PR.

@friederbluemle
I've faced the problem in a real project in the company I'm working, so, unfortunately, I can't share the project. but I can explain what was wrong in our project.
we using CI for our project. when a workflow starts, the CI server downloads multiple AGP versions, so the first problem is it downloads lots of stuff and causes taking more time to finish the building process (even we don't consider that it wastes our internet bandwidth), the second and main problem was that it seems the CI server built each module with the module's AGP and sometimes it causes the build failed unexpectedly, the behavior is nondeterministic in our project and it may builds successfully in next try. so I had to write a script that reads the main project AGP version and re-write all sub-modules used in the project.
Recently I've thought maybe we can automate this procedure and this is the motivate I raise this issue #25145 and this PR and this discussion.
Although I didn't figure out @dulmandakh's approach yet, it seems his solution is better than mine and it's enough for me (I just want the problem solved), so if you and @cpojer prefer his solution, we can close this PR.
Just it may worth If someone that has experiences in Gradle system (and also free time) writes a blog in react-native blogs to motive maintainers to change their library using @dulmandakh's solution and show them how they should do it. I think @dulmandakh is the best one who can do it. :)

Actually, I want it fixed as much as you do :)
From my experience, there is not that much wrong with the prevailing current setup of most projects (although there is certainly a LOT to simplify and consolidate). I definitely agree with you that it would be great to have some kind of "best practices" guide for RN module creation.
What would be a super strong point for your approach is if you could create an open source sample project that showcases the issues you mention in reproducible way.

Additional to mentioned issues:
according to @dulmandakh's comment

Therefore, it means AGP can be loaded multiple times.

If it means that there may be a situation where multiple AGPs loaded at the same time into RAM, so it means CI server waste more resources for building too. then his approach has another advantage to improve building process performance.

Additional to mentioned issues:
according to @dulmandakh's comment

Therefore, it means AGP can be loaded multiple times.

If it means that there may be a situation where multiple AGPs loaded at the same time into RAM, so it means CI server waste more resources for building too (which it should not). then his approach has another advantage to improve building process performance.

What would be a super strong point for your approach is if you could create an open source sample project that showcases the issues you mention in reproducible way.

As I mentioned before, it's happened nondeterministically, so I'm not sure how can I reproduce it, and because it needs to have CI server too it will take more time from me to make such repository and I haven't much free time these days to work on it, sorry about that. but from all discussion we have in few issues and PRs, I concluded, it seems it is a bad practice that almost all module maintainers put gradle files into android directory from the beginning. even the nondeterminism is only my project's problem and any other one hadn't such problem before, but we have some other good reasons why it's necessary to removing gradle configs from submodules' android directory.

For me, simply having multiple gradle distributions download is a major pain point. If you haven't experienced what it's like to be a multi-platform developer in a developing country with low bandwidth and small hard drives, much less run a crew with independent copies of dev environments, it's incredibly painful, and the gradle distributions weigh in at 100+MB. For me, that is at the level of "bug" on it's own.
I believe the proposed solution from @dulmandakh solves that neatly by making sure your project only ever downloads one version for the project, while still having one specified (in Kotlin) for maintenance on the module itself.
The issue of multiple AGPs loading at the same time seems legit but I've not seen problems, I'm interested in single-point version control of the gradle + plugin's in use, and ability to have a single copy at a time.

For me, simply having multiple gradle distributions download is a major pain point. If you haven't experienced what it's like to be a multi-platform developer in a developing country with low bandwidth and small hard drives, much less run a crew with independent copies of dev environments, it's incredibly painful, and the gradle distributions weigh in at 100+MB. For me, that is at the level of "bug" on it's own.

Yeah, this is exactly what I'm said and I'm experiencing it every day :D

The issue of multiple AGPs loading at the same time seems legit but I've not seen problems

it is a problem too I think, just like small hard drives it may users have limited resources (including RAM) for local CI servers, avoid loading multiple AGP can reduce RAM usage, correct me if I'm wrong.

@mikehardy @SaeedZhiany - I fully agree with you, the download of multiple Android Gradle plugin distributions is a major pain point, even with a slightly faster internet connection.
I actually found an alternate solution, without moving any Gradle related files into the root of a project.
Essentially, it's just two lines, wrapping the Android Gradle plugin dependency in the buildscripts section:
if (project == rootProject) {
    // ... (dependency here)
}

With this, the dependency is only evaluated (and possibly downloaded) when the project is opened stand-alone (opening the android folder in Android Studio).
When a library project is included as a dependency, then rootProject will be the main application project. -> the statement will evaluate to false, skipping the potentially outdated Android Gradle plugin download.
I opened a bunch of PRs:
https://github.com/react-native-community/react-native-localize/pull/69
https://github.com/react-native-community/react-native-share/pull/588
https://github.com/react-native-community/async-storage/pull/209
https://github.com/FormidableLabs/react-native-app-auth/pull/384
It would be great if you could test this and let me know if it works/what you think. Thanks you 🙏

@friederbluemle
That's so interesting and much easier to understand for me.
just one question:
in @dulmandakh's approach the file gradle-wrapper.properties moved to root directory, so it will not be downloaded in the main project too (in case of versions mismatch between the main project's gradle-wrapper.properties and the module's gradle-wrapper.properties) and this is so good.
does your approach consider it too?

Hi @SaeedZhiany - Good question! As the name implies, the file gradle-wrapper.properties is part of the Gradle wrapper (together with the three other files gradle-wrapper.jar, gradlew, and gradlew.bat). For an application, the only wrapper that will be used is the one that is distributed with the application project itself (in the android folder). Any other Gradle wrappers that might be contained in node_modules will not be used. In fact, these files should not be distributed by library projects in the first place, since it would only result in an increased artifact file size.
By not moving anything into the root directory, it will keep everything related to Android contained in the android folder, and everything related to iOS in the ios folder (just like in a regular RN application project).
What is distributed in the end is controlled by other means. Have a look at the files section of package.json, and npmignore.

In fact, these files should not be distributed by library projects in the first place, since it would only result in an increased artifact file size.

Yeah, you're right. the only RN module that has such problem is react-native-keychain, the gradle folder has been distributed within the android folder. the other dependencies I'm using in my project has no such problem. Although with @dulmandakh's PR the gradle file currently moved to root directory. if your approach comes to as an agreement, maybe we need to revert the PR's change and apply your approach and then simply add the gradle directory path of react-native-keychain in .gitignore file.

I like your suggestion because it's simple and can easily apply. even we can write a simple script that automatically wraps the repositories and  dependencies with the if (project == rootProject) statement.
@mikehardy and @dulmandakh what do you think?

There are definitely many other library projects that incorrectly distribute the Gradle wrapper (an others) files. Even with the updated react-native-keychain project, the wrapper is still distributed - It's just outside the android folder. In either case, it should not result in any conflicts (just increased download size).
Regarding a quick script that locally fixes up build.gradle files from library projects that have not been updated yet: Great idea! It does not even have to be as complex as wrapping something. Simply removing the whole buildscripts {} block should be fine too. As explained, it's only needed when building/opening the project stand-alone, and can safely be removed from dependencies inside of node_modules (to avoid the extra downloads).

Simply removing the whole buildscripts {} block should be fine too.

Yeah, it would be great too. even we can add it to CLI Autolink procedure that simply remove the block in postinstall procedure, so it's not necessary to module consumers deal with that.

@SaeedZhiany - Quick update to npmignore and files in package.json over at react-native-keychain: https://github.com/oblador/react-native-keychain/pull/248

The (if project == rootProject) idea seems much more "android-native" to me, and conceptually simpler, while apparently meeting the same goals.  The first few idea iterations of jetifier were similarly nowhere near the final, sometimes it just takes a few people a few attempts before you hit on the right thing. Cool

Yes, thanks a lot for the input and suggestions everyone (especially @SaeedZhiany @dulmandakh @mikehardy) 👍

I'm closing this PR in favor of @friederbluemle solution.
Thank you all you guys for contributing.


Removed the logs functionality

In regards to #90
I have removed the log functionality from the app.
Is this correct?

@Dement0 hey dude! thank you!
And yeh the project is really nice id love to assist more on it if you need me 😄
Also i have chucked you a star good sir!
What are your future plans for the project by the way?

Hey @Kardelio, thanks for the :star:
If you want you can join the Discord channel that I've created for further discussion: https://discord.gg/U4dYsfY
Have a nice day!