Downloading pretrained Efficient Det in google colab using TensorFlow Object Detection Api gives a series of unknown warnings?

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

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
OS Platform and Distribution (e.g., 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):
TensorFlow version (use command below):
Python version:
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with:

TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the current behavior
I have created a notebook that downloads pretrained model from tf2 detection model zoo and performs prediction using saved model . The notebook is working fine on other models such as centernet, faster rcnn etc. But whenever I download efficient det using the download function below it issues a series of warnings.
MY DOWNLOAD FUNCTION
def download_model(model_name):

  download_url = 'http://download.tensorflow.org/models/object_detection/tf2/20200711/'

  pretrained_model = model_name

  model_file = pretrained_model + '.tar.gz'

  !wget {download_url + model_file}
  tar = tarfile.open(model_file)
  tar.extractall()
  tar.close

  model_dir= os.getcwd() + '/' + pretrained_model        # determine the path to saved model
  model_dir=pathlib.Path(model_dir)/'saved_model'
  model= tf.saved_model.load(str(model_dir))

  return model

The warnings I encounter:
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_119744) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_132687) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference___call___37213) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.
WARNING:tensorflow:Importing a function (__inference_EfficientDet-D1_layer_call_and_return_conditional_losses_124597) with ops with custom gradients. Will likely fail if a gradient is requested.

Describe the expected behavior
Eventhough my Efficient Det Model runs ok, I don't understand why is this warning being issued and how to get rid of it. I am making a notebook tutorial for others to understand TFOD but these warnings make my notebook look messy. Is there anyway I can get rid of those?
Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.
The warnings occur while using this code:
model_name= 'efficientdet_d1_coco17_tpu-32'
model= download_model(model_name)

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.

I have tried in colab with TF nightly version(2.4.0-dev20201019 ) and was able to reproduce the issue.Please, find the gist here.Thanks!

I think is a dup of https://github.com/tensorflow/tensorflow/issues/40166 /cc @andresp

#40166 has an error issue. My notebook is not having any error. I am only asking how to suppress those warnings.

@AshTech25 Are you training/fine-tuning the model?

As mentioned before, we don't support custom gradients - but there are too many warnings there, we'll work on making them less verbose.

@AshTech25 Are you training/fine-tuning the model?

No I'm just using the model for my inferences

@AshTech25 Are you training/fine-tuning the model?

No I'm just using the model for my inferences

So without the training you will not got the error but the warning has the same origin

As mentioned before, we don't support custom gradients - but there are too many warnings there, we'll work on making them less verbose.

I observe the same with EfficientNetBX from tf.keras.applications. Still, I do not get an error when finetuning the model. Is the gradient computation failing silently?

@AshTech25 I think this was resolved in tf-nightly. I cannot see all those warning except few WARNING:absl:Importing a function . Please check the gist for the warnings. Please check the gist here.
Please note that these updates didn't propagate to TF2.4rc4 so the updates will be available in tf-nightly and future stable TF2.5 but not in stable TF2.4. Thanks!
Please verify once and close the issue if this was resolved for you. Thanks!


Add support for textmagic

Description
Added support for TextMagic service
Fixes # (issue)
https://github.com/kha7iq/pingme/issues/44
Type of change

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?

[x] Running existing tests
[ ] Created new tests

Checklist:

[x] My code has been linted (make lint)
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have rebased my branch to include the latest changes from master

Thank you @charconstpointer


Add support for FileWrapper to OLEFile

Hello, @MaxDesiatov ! Your library is giving me a lot of support for developing HWP File parsing library!
By the way, a problem occurred when I started developing SwiftUI document-based app.
It should get file information from FileWrapper in Foudation Framework.
It's critical because we can't get file path from it.
So, I created OLEFile2, which have fileWrapper property instead of fileHandle. And appended some support code.
Also, I checked it parse same result between OLEFile and OLEFile2.
However, You are core maintainer and I'm just freshmen in univ, so I need your kind advice. 😃
Would it be good to add another class like this?
Thanks!

Hmmm, we can't support Linux if the library uses FileWrapper.......
CI / xcode-11_0 (pull_request) and CI / xcode-11_1 (pull_request) failed because it removed from macos github-hosted runner, I think. macos github-hosted runner

Hmmm, we can't support Linux if the library uses FileWrapper.......
CI / xcode-11_0 (pull_request) and CI / xcode-11_1 (pull_request) failed because it removed from macos github-hosted runner, I think. macos github-hosted runner

I added some preprocessors that checks Linux.

I added some preprocessors that checks Linux.

I've removed Xcode 11.0 and 11.1 jobs from the workflow in the main branch, so if you merge main into your branch, those checks should no longer run.

I've removed Xcode 11.0 and 11.1 jobs from the workflow in the main branch, so if you merge main into your branch, those checks should no longer run.

Thank @MaxDesiatov for your kind advice! Maybe the code was messy at first because I worked at 4 am lol.
As your suggestion, I integrated OLEFile2 with var reader: Reader.
Yes, it works fine, but there is some weird part in extension FileWrapper because it should conform to Reader.
Its Permalink

Thank @MaxDesiatov for your kind advice! Maybe the code was messy at first because I worked at 4 am lol.
As your suggestion, I integrated OLEFile2 with var reader: Reader.
Yes, it works fine, but there is some weird part in extension FileWrapper because it should conform to Reader.
Its Permalink

@sboh1214 I've invited you as a collaborator to the project, feel free to merge the PR when CI passes 👏

@sboh1214 I've invited you as a collaborator to the project, feel free to merge the PR when CI passes 👏

Thank you so much @MaxDesiatov !
Is it good to tag 0.3.0 and publish the release if merge this PR?

Thank you so much @MaxDesiatov !
Is it good to tag 0.3.0 and publish the release if merge this PR?

Sure, but please update CHANGELOG.md first with GitBuddy before tagging the release. You'd launch it like this:
GITBUDDY_ACCESS_TOKEN='sboh1214:REPLACE_WITH_YOUR_GITHUB_TOKEN' gitbuddy changelog --sections -b main

Then add a section for the new version with the current date to CHANGELOG.md and paste the output of the gitbuddy changelog command. You'd create a PR with the changelog update then, which is just a release formality 🙂
Also, this changelog snippet can be added to the release on GitHub itself.

Sure, but please update CHANGELOG.md first with GitBuddy before tagging the release. You'd launch it like this:
GITBUDDY_ACCESS_TOKEN='sboh1214:REPLACE_WITH_YOUR_GITHUB_TOKEN' gitbuddy changelog --sections -b main

Then add a section for the new version with the current date to CHANGELOG.md and paste the output of the gitbuddy changelog command. You'd create a PR with the changelog update then, which is just a release formality 🙂
Also, this changelog snippet can be added to the release on GitHub itself.

If you have any problems with the changelog update, please let me know. Or I can do this myself in the next couple of days, I'm sorry I'm a bit busy right now. Thank you!

If you have any problems with the changelog update, please let me know. Or I can do this myself in the next couple of days, I'm sorry I'm a bit busy right now. Thank you!

Ah, sorry, you've explicitly asked to me to tag and release. I'll do it, sorry about the confusion 🤦♂

Ah, sorry, you've explicitly asked to me to tag and release. I'll do it, sorry about the confusion 🤦♂

No, it's okay! 😃 I edited it to request to you because I don't know about the release process. But also thank you for letting me know how to release it. Please release OLEKit in your spare time, not hurry.

No, it's okay! 😃 I edited it to request to you because I don't know about the release process. But also thank you for letting me know how to release it. Please release OLEKit in your spare time, not hurry.


Feature request

I would like to add a DL/ML model of cancer detection.
Could you please assign this issue to me under hacktoberfest and gssoc extd

@Nethmi11 sorry it's already done you can work on different one


Envoy: add NACK processing

Since the last update on the cilium agent envoy API code, the behavior
had changed to keep sending the same resource version over and over if
Envoy rejects the resource. Fix this by properly differentiating
between ACKs and NACKs. A NACK now causes a watcher to wait until the
resource is updated before sending it over again.
This was found due to the new policy resources failing protobuf
content validation that Envoy checks for.
Signed-off-by: Jarno Rajahalme<EMAIL_ADDRESS>

test-me-please


Use a chain of coin pairs to derive USD/HBAR rate

if an exchange does not directly offer an hbar/usd pair, we can chain other pairs to derive an hbar/usd pair. For example, if the exchange offered a usd/btc pair and a hbar/btc, then dividing the second by the first would generate an equivalent usd/hbar pair.
Requirements for the chaining are here
https://hederatest.sharepoint.com/:w:/s/HederaHome/EfiCGVQQdX9PsRCdYupHIggBujOZqkyeX2L35k4vzRiJSg?e=DdCU2L
And during debugging, the answer from each chain can be compared to the numbers on this web page:
https://coinmarketcap.com/currencies/hedera-hashgraph/markets/

@lbaird if we relax the requirement that both pairs come from the same exchange, our options increase.
For instance, pull HBAR/BTC from Binance, and BTC/USD from Coinbase we can calculate HBAR/USD .
Once we have that BTC/USD price, we can use it for multiple other exchanges in the same manner and significantly expand our coverage

@lbaird if we relax the requirement that both pairs come from the same exchange, our options increase.
For instance, pull HBAR/BTC from Binance, and BTC/USD from Coinbase we can calculate HBAR/USD .
Once we have that BTC/USD price, we can use it for multiple other exchanges in the same manner and significantly expand our coverage

That’s true. Or maybe USDT or other stable coins.

From: paulmadsenhed<EMAIL_ADDRESS>Sent: Saturday, January 9, 2021 5:39:17 AM
To: hashgraph/hedera-exchange-rate-tool<EMAIL_ADDRESS>Cc: Leemon Baird<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [hashgraph/hedera-exchange-rate-tool] Use a chain of coin pairs to derive USD/HBAR rate (#91)
@lbairdhttps://github.com/lbaird if we relax the requirement that both pairs come from the same exchange, our options increase.
For instance, pull HBAR/BTC from Binance, and BTC/USD from Coinbase we can calculate HBAR/USD .
Once we have that BTC/USD price, we can use it for multiple other exchanges in the same manner and significantly expand our coverage
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/hashgraph/hedera-exchange-rate-tool/issues/91#issuecomment-757136799, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABDBYWY6VBARRUEYCFK5Y23SZA56LANCNFSM4KDNP4IA.

That’s true. Or maybe USDT or other stable coins.

From: paulmadsenhed<EMAIL_ADDRESS>Sent: Saturday, January 9, 2021 5:39:17 AM
To: hashgraph/hedera-exchange-rate-tool<EMAIL_ADDRESS>Cc: Leemon Baird<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [hashgraph/hedera-exchange-rate-tool] Use a chain of coin pairs to derive USD/HBAR rate (#91)
@lbairdhttps://github.com/lbaird if we relax the requirement that both pairs come from the same exchange, our options increase.
For instance, pull HBAR/BTC from Binance, and BTC/USD from Coinbase we can calculate HBAR/USD .
Once we have that BTC/USD price, we can use it for multiple other exchanges in the same manner and significantly expand our coverage
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/hashgraph/hedera-exchange-rate-tool/issues/91#issuecomment-757136799, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABDBYWY6VBARRUEYCFK5Y23SZA56LANCNFSM4KDNP4IA.


Optional UI rendering

Objective
Make UI rendering optional.
Quite a few people have been experimenting with using Bevy UI for layout and interaction but replacing the rendering with bevy_prototype_lyon or whatever. It's awkward to do though as there is no way to disable the existing UI rendering requiring users to create their own custom node bundles and components. Also, you can't replace the UI's shader and a number of other things.
This PR makes the setup and initialization of UI rendering for the RenderApp optional. Then you can do whatever you want by replacing build_ui_render with your own function. For instance, one that loads a custom shader.
The UI layout and interaction components are still updated as normal.
Solution
Add a field disable_ui_rendering to UiPlugin.
Only call build_ui_render and initialize the UiPipeline if disable_ui_rendering is false.
I thought about implementing a "bevy_ui_render" feature but suspect everything is too tightly coupled atm and it would be very fragile. Similar to the struggles with the "bevy_text" feature but worse.

Changelog
UiPlugin

Added a bool field disable_ui_rendering.
Only calls build_ui_render and initializes the UiPipeline if disable_ui_rendering is false.

Migration Guide
UiPlugin has a new field disable_ui_rendering. If set to true, UI rendering won't be added to the RenderApp and the UI will not be shown.

I thought about implementing a "bevy_ui_render" feature but suspect everything is too tightly coupled atm and it would be very fragile. Similar to the struggles with the "bevy_text" feature but worse.

I would prefer this solution, especially in the long run, but the struggles are entirely plausible. We should work towards decoupling things here though.

Definitely agree. My preference I think would be to move the UI renderer into its own crate.

Similar to the struggles with the "bevy_text" feature but worse.

This could be fixed by running tests without the bevy_text feature on CI (which can be done by running cargo test in the bevy_ui crate dir rather than just from the root).

@ickshonpe just waiting on merge conflicts now :)


Plugin Testing Patterns

I've been working with Kong and custom plugins for about a month now; powerful stuff!
As my plugin collection is growing, and complexity is increasing, I was wondering what kind of testing schemes you would recommend for python specifically? I'm not able to find very much in the docs for this particular side of non-lua plugin development.
Currently, we achieve integration tests through Kong deployed in kind with an echo server.
Validation there, and recommendations for unit tests and "mock kong"s would be great!
Thanks!

Hi @wjziv , we haven't implemented "mock kong" test yet, but that's on our roadmap. Please stay tuned for this issue!

Super glad to hear it's on the roadmap!
Are there suggested testing patterns put forth by Kong generally for plugin development?
If integration tests over a cluster which services echo servers alone are the end-all, be-all of tests, that's fine.
Checking to see if there's anything I've missed in this regard.

@wjziv usually you will need both for good coverage. The "mock kong" suite is more for a semi-e2e test, it will help you catch typos, type mismatches regarding your RPC calls, and also helps you do unit test on your plugin's functionality. And I recommand to also have an additional (real) e2e test setup.

Hi guys, any updates about mock kong?


Could not parse hex range

When I try to view an event or a profile with the cli tool "noscl" (noscl profile npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m), I get the following error on nostr-rs-relay side:
INFO nostr_rs_relay::repo::sqlite: Could not parse hex range from author "npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m"
Any idea what I'm doing wrong?

replace your nbpub with this: 82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2

how did you achieve this? isnt it from ascii to hex conversion?

thank you very much


test-branch/execute-job/quoted-authorization/54bd01a6-14c4-4f59-882f-c06b9987358e

PR for testing 2e8fbb6d779ae06f5ea9f593b9f29cc3bc7fc1c6

/canonical/self-hosted-runners/run-workflows 2e8fbb6d779ae06f5ea9f593b9f29cc3bc7fc1c6


Tweepy Authentication Error

Tweepy Authentication Error
It appears as if tweepy encounters an authentication error based on the present credentials; revisit this concerna and update the credentials accordingly.

On the other hand, the Discord bot is working without any struggles.


Support creating a Plan from a previously-saved plan file

Allow Deployster to calculate a deployment plan and just save it to a file. That file can later be fed back to Deployster.
Notes:

When receiving a previously-saved plan file, Deployster should probably re-calculate the plan anyway, and just verify that it still gets the same plan, something like a fingerprinting or an etag mechanism to ensure reproducability.

Irrelevant since v18.


Lower vectors into VMVX.

There's a few approaches we can take and we should experiment to see what we can get the IR to do.
The goal here is to end up with two types of work: big vectors and small vectors. I'm not sure how the current tiling infra does this.
Today we can (roughly) go to scalar level:
scf.for %arg14 = %arg12p12 to %arg12p10p12x4 step %c4 {
  %16 = vmvx.buffer.load<%0 : !vmvx.buffer>[%arg14] : i32
  %17 = vmvx.buffer.load<%1 : !vmvx.buffer>[%arg14] : i32
  %18 = muli %16, %17 : i32
  vmvx.buffer.store<%2 : !vmvx.buffer>[%arg14], %18 : i32
}

Of course, that's a pretty bad way of doing this: we need 3 calls to one arithmetic op. One approach is to use smallish vectors here to amortize the call overhead:
scf.for %arg14 = %arg12p12 to %arg12p10p12x4 step %c128 {
  %16 = vmvx.buffer.load<%0 : !vmvx.buffer>[%arg14] : vector<32xi32>
  %17 = vmvx.buffer.load<%1 : !vmvx.buffer>[%arg14] : vector<32xi32>
  %18 = muli %16, %17 : vector<32xi32>
  vmvx.buffer.store<%2 : !vmvx.buffer>[%arg14], %18 : vector<32xi32>
}

which we then can expand out to VM scalar registers:
scf.for %arg14 = %arg12p12 to %arg12p10p12x4 step %c128 {
  %16#32 = vmvx.buffer.load.32<%0 : !vmvx.buffer>[%arg14] : i32
  %17#32 = vmvx.buffer.load.32<%1 : !vmvx.buffer>[%arg14] : i32
  %18 = muli %16#0, %17#0 : i32
  %19 = muli %16#1, %17#1 : i32
  %20 = muli %16#2, %17#2 : i32
  %21 = muli %16#3, %17#3 : i32
  %22 = muli %16#4, %17#4 : i32
  ...
  vmvx.buffer.store.32<%2 : !vmvx.buffer>[%arg14], %18, %19, .... : i32
}

We can vary the vector sizes here with tiling parameters to balance the ratio. The advantage of this approach is that it'll always work - there's no special vmvx ops required beyond the loads and we can add a strided variant if needed.
The other class of operations are ones we want to treat as external operations. These would operate directly on the !vmvx.buffers without needing to load the values locally. Think of things like common elementwise ops and any of the larger vector/matrix operations modeled on the LLVM vector/matrix intrinsics. These are useful when we know that we'll have a high number of loads/stores relative to the work being performed and where we want to be able to have optimized implementations. These would look very similar to cooperative matrix in SPIR-V.
The above could be rewritten:
scf.for %arg14 = %arg12p12 to %arg12p10p12x4 step %c4096 {
  vmvx.mul.si32 lhs(%0 : !vmvx.buffer>)[%arg14] rhs(%1 : !vmvx.buffer>)[%arg14] dst(%2: !vmvx.buffer>)[%arg14] length(%c1024)
}

This dramatically improves the code-size, runtime overhead, and lets us write a little SIMD implementation.
Since the tiling parameters differ between these two approaches while we need both we may have to perform the tiling multiple times - once to get to the coarse-level that we then match to the supported operations and then once again to get to the scalar-style small vectors and then once again to take care of anything remaining as simple scalar loops.

April feels so far away now! Things changed with VMVX to simplify the approach and make it more reusable (it's possible to lower VMVX to non-IREE-VM backends like webassembly, etc). With respect to vectors this changed the problem from "how do we support vector in the IREE VM" (really involved) to "how do we turn vector into a 1D memref (or maybe some other !vmvx.vector type)" (something we may be able to lean on upstream bufferization support for, or at least write code that is nice and self-contained in a single pass vs touching a whole slice of the system) - or something like that.
The anchor requirement for the approach we choose is that we want to pass buffers and offsets to the library calls we have. For example:
vmvx.some_library_call_op %lhs_buffer, %lhs_offset, %rhs_buffer, %rhs_offset, %out_buffer, %out_offset, %length) :
    (!vm.buffer, index, !vm.buffer, index, !vm.buffer, index, index)

It could be in-place/etc too, whatever works for the op. The important thing is that we are passing in buffer references and offsets into them. This is in contrast to something like memref that would take a subview and such, as here we don't want to be creating additional buffer references or do any reference counting work in our inner loops.
So working backwards from there: if values are already in memrefs then this is relatively easy as we support converting memref -> !vm.buffer. For a lot of things that just do a memref.subview + scalar load/store this path is what's used today. The magic that enables this is FlattenMemRefSubspanPass which makes all memrefs 1D (so memref<4x8xf32> -> memref<32xf32>) giving us a foundation for memref+offset we need above.
When it comes to vectors we need to do something to get them into a form that we can lower to a !vm.buffer + offset. One approach would be to bufferize the vectors into memrefs and use the same FlattenMemRefSubspanPass to make them 1D and get the linear offsets. If the VMVX dialect ops took memrefs then this may slot in nicely - convert to vector ops, convert vector ops to VMVX ops on vectors, bufferize the vectors into memrefs, and then let the flattening happen for free with the existing tail of the pipeline. When lowering into the VM dialect then the 1D memref + linear offset become the !vm.buffer + offset we need.
This approach effectively treats vectors post-tiling (where they are all reasonably sized) as if they were machine registers in some register file, performs register allocation (similar to what the VM RegisterAllocation does) to pack all the various vectors into the register file, and then allocas the register file. This would work well as each VMVX function already gets a scratchpad/workgroup-local buffer passed in it can use as the register file. If whatever we did packed vectors into into a 1D memref that was alloca'd this would be really easy to wire up. Rough example:
// load a 4x4 vector from %src_buffer at %linearized_offset (or whatever)
%13 = memref.subview %src_buffer[%linearized_offset] ... : memref<16xi8>
%16 = vector.transfer_read %13[%c0], %cst_0 : memref<16xi8, ...>, vector<4x4xi8>
// perform some vmvx op on the vector
vmvx.foo %16, ...

-> (bufferize vectors)

// allocate the virtual register file where all transient vectors are stored once (will be the local memory passed into the func)
%register_file = memref.alloca %total_size ... : memref<16384xi8>
...
// the vector became just a subview of the source of the read, with the read being turned into a copy from the source
%13 = memref.subview %src_buffer[%linearized_offset] ... : memref<16xi8>
%16 = memref.subview %register_file[%register_offset], ... : memref<4x4xi8, ...>
memref.copy %13, %16 : memref<4x4xi8>
vmvx.foo %16, ...

-> (flattening)

%register_file = memref.alloca %total_size ... : memref<16384xi8>
...
%13 = memref.subview %src_buffer[%linearized_offset] ... : memref<16xi8>
// flattening again to get 1D memrefs
%16 = memref.subview %register_file[%register_offset], ... : memref<16xi8, ...>
memref.copy %13, %16 : memref<16xi8>
vmvx.foo %16, ...

-> (memref optimizations)

// really hoping that memref optimizations could elide that unneeded copy :)
%13 = memref.subview %src_buffer[%linearized_offset] ... : memref<16xi8>
vmvx.foo %13, ...

-> (vm conversion)

// lowering to VM already handles taking the memref into a reference to the buffer + offset
%13 = %linearized_offset : index
vm.call @vmvx.foo(%src_buffer, %13, ...)

There are other approaches that may work too. For example, we could convert vector into a !vmvx.vector and a suite of load/store ops from memrefs (ala vector.transfer_read). The VMVX ops would then be specified to work on !vmvx.vector only and we can bufferize those. That's more boilerplate and more likely to drift as upstream changes to the vector dialect happen which is why I've shied away from it so far and tried to stick to 1D memrefs.
I'm sure there are more ideas too! I think the next step is probably taking the IR you have in #5819 and running the FlattenMemRefSubspanPass on it to see what that looks like as that would at allow focus on just the vectors and how they are represented. From that we could sketch up some example lowerings from 1D memref + vector operations to pure 1D memrefs or 1D memrefs + some custom type etc.
My instinct is that this will end up with not too much code and most of the time spent on fun IR design iteration to find something that is easy to work with and relatively stable in the face of codegen/linalg/vector/tiling/etc changes.
--
This was just a brain dump because what was in the issue was out of date - would love to chat more about approaches or experiment on discord :)

This is great information, and definitely helps me wrap my head around what we need to do a bit more. Let me dump what I currently have, then I can come back to your points above. I think I accidentally followed the memref + offset that takes advantage of the current pipline, where VMVX IR operates on memref directly :).
--
Here is a rough sketch of a lowering that I have now (constants elided):
// Starting
func @elem_add(%arg0 : tensor<8192xi32>, %arg1 : tensor<8192xi32>) -> tensor<8192xi32> attributes { iree.module.export } {
  %0 = "mhlo.add"(%arg0, %arg1) : (tensor<8192xi32>, tensor<8192xi32>) -> tensor<8192xi32>
  return %0 : tensor<8192xi32>
}

// After tiling for vmvx (which does almost nothing at the moment) and a FlattenMemRefSubspan
func @elem_add_dispatch_0() {
  %0 = hal.interface.binding.subspan @io::@s0b0_ro_external[%c0] : memref<8192xi32>
  %1 = hal.interface.binding.subspan @io::@s0b1_ro_external[%c0] : memref<8192xi32>
  %2 = hal.interface.binding.subspan @io::@s0b2_xw_external[%c0] : memref<8192xi32>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  %3 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_id_x]
  %4 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%workgroup_count_x]
  scf.for %arg0 = %3 to %c8192 step %4 {
    %5 = vector.transfer_read %0[%arg0], %c0_i32 {in_bounds = [true]} : memref<8192xi32>, vector<128xi32>
    %6 = vector.transfer_read %1[%arg0], %c0_i32 {in_bounds = [true]} : memref<8192xi32>, vector<128xi32>
    %7 = addi %5, %6 : vector<128xi32>
    vector.transfer_write %7, %2[%arg0] {in_bounds = [true]} : vector<128xi32>, memref<8192xi32>
  }
  return
}

// After VectorToVMVX
func @elem_add_dispatch_0(%arg0: memref<?xi8>, %arg1: memref<?xi32>, %arg2: !iree.list<memref<?xi8>>, %arg3: index, %arg4: index, %arg5: index, %arg6: index, %arg7: index, %arg8: index, %arg9: index, %arg10: index, %arg11: index) {
  %0 = iree.list.get %arg2[%c0_0] : !iree.list<memref<?xi8>>
  %1 = unrealized_conversion_cast %0 : memref<?xi8> to memref<8192xi32>
  %2 = iree.list.get %arg2[%c1] : !iree.list<memref<?xi8>>
  %3 = unrealized_conversion_cast %2 : memref<?xi8> to memref<8192xi32>
  %4 = iree.list.get %arg2[%c2] : !iree.list<memref<?xi8>>
  %5 = unrealized_conversion_cast %4 : memref<?xi8> to memref<8192xi32>
  %6 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%arg3]
  %7 = affine.apply affine_map<()[s0] -> (s0 * 128)>()[%arg9]
  scf.for %arg12 = %6 to %c8192 step %7 {
    %c128 = constant 128 : index
    vmvx.add.si32 lhs(%1 : memref<8192xi32>) [%arg12] rhs(%3 : memref<8192xi32>) [%arg12] dst(%5 : memref<8192xi32>) [%arg12] length(%c128)
  }
  return
}

// After VMVX to VM
vm.import @vmvx.addsi32(%lhs_buffer : !vm.buffer, %lhs_offset : i32, %rhs_buffer : !vm.buffer, %rhs_offset : i32, %dst_buffer : !vm.buffer, %dst_offset : i32, %length : i32) attributes {sym_visibility = "private"}
vm.func @elem_add_dispatch_0(%arg0: !vm.buffer, %arg1: !vm.buffer, %arg2: !vm.list<!vm.buffer>, %arg3: i32, %arg4: i32, %arg5: i32, %arg6: i32, %arg7: i32, %arg8: i32, %arg9: i32, %arg10: i32, %arg11: i32) {
  %buffer = vm.list.get.ref %arg2, %zero : (!vm.list<!vm.buffer>, i32) -> !vm.buffer
  %buffer_0 = vm.list.get.ref %arg2, %c1 : (!vm.list<!vm.buffer>, i32) -> !vm.buffer
  %buffer_1 = vm.list.get.ref %arg2, %c2 : (!vm.list<!vm.buffer>, i32) -> !vm.buffer
  %0 = vm.mul.i32 %arg3, %c128 : i32
  %1 = vm.mul.i32 %arg9, %c128 : i32
  vm.br ^bb1(%0 : i32)
^bb1(%2: i32):  // 2 preds: ^bb0, ^bb2
  %slt = vm.cmp.lt.i32.s %2, %c8192 : i32
  vm.cond_br %slt, ^bb2, ^bb3
^bb2:  // pred: ^bb1
  vm.call @vmvx.addsi32(%buffer, %2, %buffer_0, %2, %buffer_1, %2, %c128) : (!vm.buffer, i32, !vm.buffer, i32, !vm.buffer, i32, i32) -> ()
  %3 = vm.add.i32 %2, %1 : i32
  vm.br ^bb1(%3 : i32)
^bb3:  // pred: ^bb1
  vm.return
}

So for the easy 1-d case above, FlattenMemRefSubspan gets the vector.transfer_read/write ops to an easy enough shape at which point I really just inline the memref and offset into vmvx.addsi32. After that, the rest of the pipeline seems to lower it to some usable !vm.buffers and offset. As it currently stands, I have a vmvx.addsi32 intrinsic that grabs the vm.buffer and uses AVX2 to do some vectorized adds (tiny experiments showing about a 10x speedup).
After reading your writeup, I can see the step that I am skipping here is the bufferization of the vectors. Sure, I can inline the transfer read/write above, but I see that it will break very quickly (two addi ops in a row wont work etc). I'd say based on what I have now, taking the "vmvx on memref" approach looks like the way to go, with obvious work to be done on the bufferization part of it.
--
I experimented with a slightly more complex mhlo add (tensor<128x128xi32>) that I knew would vectorize in the above pipeline:
%7 = memref.subview %0[%arg0, %arg1] [128, 128] [1, 1] : memref<128x128xi32> to memref<128x128xi32, affine_map<(d0, d1)[s0] -> (d0 * 128 + s0 + d1)>>
%8 = memref.subview %1[%arg0, %arg1] [128, 128] [1, 1] : memref<128x128xi32> to memref<128x128xi32, affine_map<(d0, d1)[s0] -> (d0 * 128 + s0 + d1)>>
%9 = memref.subview %2[%arg0, %arg1] [128, 128] [1, 1] : memref<128x128xi32> to memref<128x128xi32, affine_map<(d0, d1)[s0] -> (d0 * 128 + s0 + d1)>>
%10 = vector.transfer_read %7[%c0, %c0], %c0_i32 {in_bounds = [true, true]} : memref<128x128xi32, affine_map<(d0, d1)[s0] -> (d0 * 128 + s0 + d1)>>, vector<128x128xi32>
%11 = vector.transfer_read %8[%c0, %c0], %c0_i32 {in_bounds = [true, true]} : memref<128x128xi32, affine_map<(d0, d1)[s0] -> (d0 * 128 + s0 + d1)>>, vector<128x128xi32>
%12 = addi %10, %11 : vector<128x128xi32>
vector.transfer_write %12, %9[%c0, %c0] {in_bounds = [true, true]} : vector<128x128xi32>, memref<128x128xi32, affine_map<(d0, d1)[s0] -> (d0 * 128 + s0 + d1)>>

// After FlattenMemRefSubspan with Error (interesting op)
// small_examples/elem_add2d.mlir:2:8: error: 'vector.transfer_read' op requires a permutation_map with result dims of the same rank as the vector type
%15 = "affine.apply"(%arg0, %2, %1) {map = affine_map<()[s0, s1, s2] -> (s0 * s1 + s2)>} : (index, index, index) -> index
%16 = "affine.apply"(%arg1, %3, %15) {map = affine_map<()[s0, s1, s2] -> (s0 * s1 + s2)>} : (index, index, index) -> index
%17 = "vector.transfer_read"(%4, %16, %0) {in_bounds = [true, true], operand_segment_sizes = dense<[1, 1, 1, 0]> : vector<4xi32>, permutation_map = affine_map<(d0) -> (d0)>} : (memref<?xi32>, index, i32) -> vector<128x128xi32>

So looks like FlattenMemRefSubspan has to be extended to also flatten out the vector (or maybe it's as simple as converting the vector type in this case).
Will try to catch you on discord today.

Awesome - it's great that the inlining of the reads works well enough to prototype and it's a really good starting point for experimenting with what kind of ops/library calls would be useful while in parallel working toward the more interesting cases with multiple operations!

// After tiling for vmvx (which does almost nothing at the moment) and a FlattenMemRefSubspan
Can you expand a bit more on this. Most of the pipeline that is used for the VMVX lowering is same as what is used for CPU lowering. On CPU lowering you will get vectorization (at least for this case). It is explicitly disabled for VMVX because the VMVX backend cannot handle vectors.

This would be great!

Thanks @MaheshRavishankar for pointing that out. I assume you are referring to the LLVMCPUVectorization pass? I completely missed that first time around, and instead grabbed a little code from the SPIRVTileAndVectorizeOneWorkgroup pass to get some tiling to happen. If so, I'm excited to plug into that instead.

This (https://github.com/google/iree/blob/10460ea350a0677820e0c15a51092b31192af0c8/iree/compiler/Dialect/Modules/VMVX/Transforms/Passes.cpp#L32) is the current VMVX lowering pipeline. It is already calling the same pipeline as the CPU to vectorize. You see there that it is explicitly setting lowerToVectors to false.  You should be able to get the vector code if you set it to true (which is the default value of that argument anyway).

So I tried that previously, (set lowerToVectors to true), and didn't see any vectorization on my machine. Tried again just now, and still nothing. Still have the linalg.generic op that performs the add. Perhaps I am missing something?

interesting. Ok, I'll take a look early next week.

So I tried that previously, (set lowerToVectors to true), and didn't see any vectorization on my machine. Tried again just now, and still nothing. Still have the linalg.generic op that performs the add. Perhaps I am missing something?

The current CPU lowering only vectorizes matmul and with a little modification to LLVMCPUVectorization pass we can enable vectorization for linalg.generic, but that will only work for cases where tile sizes are multiple of vector sizes.
However we are planning to deprecate this sometime in Q3 and enable the vector -> tensor LLVMCPUVectorization pass which will be the natural place to enable this.

Thanks Ahmed, had forgotten about the fact that for generic we still rely on LLVM vectorization. (didt actually get a chance to look at this on Friday)

I've been trying to pick that back up and have a little bit in place to experiment with the lowering discussed above and some ops. (Pretty sure the placeholder VMVX ops do not have enough information to do anything useful, but sketching it out for now)
func @elem_mul(%arg0 : tensor<512x512xi32>, %arg1 : tensor<512x512xi32>) -> tensor<512x512xi32> attributes { iree.module.export } {
  %0 = "mhlo.dot"(%arg0, %arg1) : (tensor<512x512xi32>, tensor<512x512xi32>) -> tensor<512x512xi32>
  return %0 : tensor<512x512xi32>
}

// --> After LLVMCPUTileAndVectorizePass and FoldSubviewOps

scf.for %arg4 = %c0 to %c512 step %c64 {
  scf.for %arg5 = %c0 to %c64 step %c16 {
    %7 = affine.apply affine_map<(d0, d1) -> (d0 + d1)>(%arg5, %arg4)
    %8 = affine.apply affine_map<(d0)[s0] -> (d0 + s0)>(%arg2)[%arg0]
    %9 = vector.transfer_read %0[%8, %7], %c0_i32 {in_bounds = [true, true]} : memref<512x512xi32>, vector<16x16xi32>
    %10 = affine.apply affine_map<(d0)[s0] -> (d0 + s0)>(%arg3)[%arg1]
    %11 = vector.transfer_read %1[%7, %10], %c0_i32 {in_bounds = [true, true]} : memref<512x512xi32>, vector<16x4xi32>
    %12 = vector.transfer_read %2[%8, %10], %c0_i32 {in_bounds = [true, true]} : memref<512x512xi32>, vector<16x4xi32>
    %13 = vector.contract {indexing_maps = [affine_map<(d0, d1, d2) -> (d0, d2)>, affine_map<(d0, d1, d2) -> (d2, d1)>, affine_map<(d0, d1, d2) -> (d0, d1)>], iterator_types = ["parallel", "parallel", "reduction"], kind = #vector.kind<add>} %9, %11, %12 : vector<16x16xi32>, vector<16x4xi32> into vector<16x4xi32>                                                                                vector.transfer_write %13, %2[%8, %10] {in_bounds = [true, true]} : vector<16x4xi32>, memref<512x512xi32>
  }
}

// --> After conversion to some VMVX ops

scf.for %arg4 = %c0 to %c512 step %c64 {
  scf.for %arg5 = %c0 to %c64 step %c16 {
    %7 = affine.apply affine_map<(d0, d1) -> (d0 + d1)>(%arg5, %arg4)
    %8 = affine.apply affine_map<(d0)[s0] -> (d0 + s0)>(%arg2)[%arg0]
    %9 = memref.alloca() : memref<256xi32>
    vmvx.load_reg %0[%8, %7] %9 : memref<512x512xi32>, memref<256xi32>
    %10 = affine.apply affine_map<(d0)[s0] -> (d0 + s0)>(%arg3)[%arg1]
    %11 = memref.alloca() : memref<64xi32>
    vmvx.load_reg %1[%7, %10] %11 : memref<512x512xi32>, memref<64xi32>
    %12 = memref.alloca() : memref<64xi32>
    vmvx.load_reg %2[%8, %10] %12 : memref<512x512xi32>, memref<64xi32>
    %13 = vmvx.matmul lhs(%9 : memref<256xi32>) rhs(%11 : memref<64xi32>) fadd(%12 : memref<64xi32>) : memref<64xi32>
     vmvx.store %13, %2[%8, %10] : memref<512x512xi32>, memref<64xi32>
  }
}

// --> After FlatenMemrefSubspan

scf.for %arg4 = %c0 to %c512 step %c64 {
  scf.for %arg5 = %c0 to %c64 step %c16 {
    %7 = memref.alloca() : memref<256xi32>
    %8 = affine.apply affine_map<(d0, d1, d2)[s0] -> (d0 * 512 + d1 + d2 + s0 * 512)>(%arg2, %arg5, %arg4)[%arg0]
    vmvx.load_reg %0[%8] %7 : memref<?xi32>, memref<256xi32>
    %9 = memref.alloca() : memref<64xi32>
    %10 = affine.apply affine_map<(d0, d1, d2)[s0] -> (d0 * 512 + d1 * 512 + d2 + s0)>(%arg5, %arg4, %arg3)[%arg1]
    vmvx.load_reg %1[%10] %9 : memref<?xi32>, memref<64xi32>
    %11 = memref.alloca() : memref<64xi32>
    %12 = affine.apply affine_map<(d0, d1)[s0, s1] -> (d0 * 512 + d1 + s0 * 512 + s1)>(%arg2, %arg3)[%arg0, %arg1]
    vmvx.load_reg %2[%12] %11 : memref<?xi32>, memref<64xi32>
    %13 = vmvx.matmul lhs(%7 : memref<256xi32>) rhs(%9 : memref<64xi32>) fadd(%11 : memref<64xi32>) : memref<64xi32>
    %14 = affine.apply affine_map<(d0, d1)[s0, s1] -> (d0 * 512 + d1 + s0 * 512 + s1)>(%arg2, %arg3)[%arg0, %arg1]
    vmvx.store %13, %2[%14] : memref<?xi32>, memref<64xi32>
  }
}

Here is what I ran into so far and will need some help with / discuss:

I am using vmvx.load_reg as a kind of temporary op to let me play around with memref flattening and replace a transfer_read which produces a vector with a load to a temporary membuf instead. From what I understand, FlattenMemrefSubspan cannot flatten a transfer_read/transfer_write if the result vector is a N-d vector.

From the previous point, the vector contraction would also need to be transformed because of the flattening. Perhaps this is where a temporary vmvx mapping op that acts as a place holder from the N-d vector ops to 1-d vmvx ops can get inserted.

I have to these vector -> vmvx conversions in the middle of the buildVectorVMVXTransformPassPipeline as opposed to the VMVX ConversionPass because of FlattenMemrefSubspan point above.

I believe just allocating the memrefs like I am doing here won't lift them up into scratch space. That would have to happen as part of a bufferization that creates hal interface subspan buffers?

So, to continue on with the lowering above, which tries to go from N-d memref/vector, to VMVX ops that operate on 1-d memref, I think will have to more clearly flesh out how a bufferization / flattening would work here. Will try and chat on discord about it.

VMVX has gone the microkernel route instead so this is no longer required.


Added postgresdb resources and Created kubernetes page

#197
What type of PR is this? (check all applicable)

[x] Added new link to category
[x] New category added
[ ] Fixed broken link
[ ] Typo fix
[ ] Readme update
[ ] Optimization
[ ] Documentation update
[ ] Frontend update

Description

Resources for postgresdb has been added. Also has been created kubernetes page in documentation section.

#14

Bir kedim bile yok. Anlıyor musun.


Show Footer Categories

Adds an option to show the footer categories (without showing the content itself), as follows:

This shouldn't affect anything else about the theme, and was a small tweak I wanted because I wanted to know A) How many friends I had on and B) The home felt a bit empty to me without it.
Thank ya for the main theme itself :)

Would it be possible to get this looked into? It's been almost two months...

LGTM, need to make one change (theme version) and I'll merge soon or tomorrow


Bug scroll bar

When the request body is too long fastapi does not implement a scroll bar. This causes the UX to be quite degraded.
Here is a screenshot.

I think that is not a bug of FastAPI. It is related to Swagger UI.


Add project directory

Closes # .

Changes proposed in this pull request: Add project directory from Taiwan Hub, BHS2023

This project was not properly reviewed, but it does look great so I'm merging anyway.


ENH: cpython.time to expose stdlib time.localtime etc

There is a libc.time available from which I think I can patch together something equivalent to https://github.com/python/cpython/blob/master/Modules/timemodule.c#L490, but itd be nice to have a canonical version exposed directly.

Probably not a complete replacement, given that CPython's time module provides different timer sources. But a simple look-alike seems like a nice idea.

I'll see if that patching-together approach works out.  Are the libc cimports reliable cross-platform?

Are the libc cimports reliable cross-platform?

Most, but not all of them. We have more in the Cython declarations than are strictly portable, because it doesn't hurt to have them there. They only appear in C code when users make actual use of them, so it's their choice. It may be obvious for some of the declared functionality, but in the end, you better look it up.

Apparently, some struct fields are platform specific. I get this on Windows:
time_pxd.c(5597): error C2039: 'tm_zone': is not a member of 'tm'
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt\corecrt_wtime.h(23): note: see declaration of 'tm'
time_pxd.c(5600): error C2039: 'tm_gmtoff': is not a member of 'tm'
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt\corecrt_wtime.h(23): note: see declaration of 'tm'

This comes from the struct-to-dict conversion of tm, which tries to copy all fields. There isn't currently a mechanism to say "copy this field only if it exists on this platform".

It looks like they tm_zone and tm_gmtoff probably just shouldn't be in https://github.com/cython/cython/blob/master/Cython/Includes/libc/time.pxd since they aren't part of the C standard

Maybe the thing to do is define tm in the .pxd file with only the standard fields, and gnu_tm (or some similar name) with a c-name of tm with the extended list of fields? It might break some existing code, but not in a way that's too hard to fix?

Yeah, apparently, it's a GNU specific extension. The usual way we deal with those is to add them to the struct if it's reasonable, because it doesn't normally hurt to let Cython think they are there as long as users don't write time into their code. But struct-dict conversion makes this … annoying.
In this case, I would remove the fields. We can add them in some other .pxd file if someone wants them. Does that sound reasonable?

Closing again with 1a6bba9.

There isn't currently a mechanism to say "copy this field only if it exists on this platform".

It would be possible to implement this mechanism in the struct-to-dict converter functions in C++11. I'm not really convinced it's a good idea to have the behaviour vary so much depending on the compiler, but it could be done if there was a real use for it.


The new feature to use https in outgoing webhook fails in some occasions

Unclear why this happens. Should be better error handling at least?
2024-04-12T05:27:30.941Z error: WEBHOOKOUT 1 message: unable to verify the first certificate
2024-04-12T05:27:30.941Z error: WEBHOOKOUT 1 stack: Error: unable to verify the first certificate
    at AxiosError.from (file:///home/goran/code/butler/node_modules/axios/lib/core/AxiosError.js:89:14)
    at RedirectableRequest.handleRequestError (file:///home/goran/code/butler/node_modules/axios/lib/adapters/http.js:610:25)
    at RedirectableRequest.emit (node:events:530:35)
    at eventHandlers.<computed> (/home/goran/code/butler/node_modules/follow-redirects/index.js:38:24)
    at ClientRequest.emit (node:events:518:28)
    at TLSSocket.socketErrorListener (node:_http_client:495:9)
    at TLSSocket.emit (node:events:518:28)
    at emitErrorNT (node:internal/streams/destroy:169:8)
    at emitErrorCloseNT (node:internal/streams/destroy:128:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
    at Axios.request (file:///home/goran/code/butler/node_modules/axios/lib/core/Axios.js:45:41)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async sendOutgoingWebhook (file:///home/goran/code/butler/src/lib/webhook_notification.js:262:34)

Added better and more informative error logging when outbound webhook calls fail.


Fix setter value, no write in volatile hash in case of default values are present

attributes() can return a volatile hash when default_attributes, and then set into this has are lost
https://github.com/zilkey/active_hash/blob/master/lib/active_hash/base.rb#L432

In active record, I thought setting into attributes[] we're lost because it is cloned

With this I aim to change the behaviour of object[:foo]= not object.attributes[:foo]=, but the storage is in @attributes hash.

LGTM. lets see if we can get master green and then merge

close & reopen for rebuild to CI


Update UG (9 of ?)

Codecov Report

Merging #310 (016d8be) into master (5bfa141) will increase coverage by 0.22%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #310      +/-   ##
============================================
+ Coverage     84.35%   84.58%   +0.22%
- Complexity     1643     1677      +34
============================================
  Files           143      143
  Lines          4322     4437     +115
  Branches        538      572      +34
============================================
+ Hits           3646     3753     +107
- Misses          555      564       +9
+ Partials        121      120       -1

Impacted Files
Coverage Δ
Complexity Δ

.../main/java/chopchop/model/util/SampleDataUtil.java
100.00% <100.00%> (ø)
7.00 <0.00> (ø)

...pchop/logic/parser/commands/EditCommandParser.java
97.00% <0.00%> (+1.47%)
59.00% <0.00%> (+3.00%)

src/main/java/chopchop/model/UsageList.java
86.51% <0.00%> (+2.24%)
31.00% <0.00%> (+2.00%)

src/main/java/chopchop/model/ModelManager.java
73.91% <0.00%> (+2.48%)
67.00% <0.00%> (+29.00%)

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 5bfa141...016d8be. Read the comment docs.


Perform Keras layer interception in project's __init__.py

Perform call to importer.hook_keras_layer near top of __init__.py
Currently called before any other imports

See examples.keras_example.py for current usage - This will need to be removed

Verify hook_keras_layer does not raise any exceptions if Keras has not been installed

Hi, @HunterMcGushion. I'm working on this now. Just need to test it without the Keras installation

Awesome! Thanks, @HunterMcGushion. I'll assign you to the issue.


Wiki Links and other Stuff

Added Wiki Links
Fixed Frozen Blaze and Blaze Armor
Added Recipe Command to AOTS
Added new coming soon item

Branch Name sponsored by UnconsciousSelf
Commit Name sponsored by TomEngMaster

smh sell out

imagine offering sponsorships


Use C++20 on clang-newest Jenkins CI configuration

Tentatively just changed the C++ standard on the clang-newest builder. Boost might need a separate build, although I think this configuration is free of compiled Boost.

This is hopefully good to go now if CI agrees.


click on tabname goto line instead of goto tab

with neovim 0.7.0 and v0.8.0-dev+448-g7b2b44bce
with multiple tabs, when I click on one, I expect switching to it, but it go to line number corresponding to the tab number in the current buffer.
I fixed it locally :
this line execute ":tab " . a:tabnr replaced by : execute a:tabnr . "tabnext"
I would be happy to do a PR to contribute this project :)

After some checks, the first fix causes a regression (unable to rename tabs)
Ithe good fix is :
function! TablineSwitchTab(tabnr, mouseclicks, mousebutton, modifiers)
    execute a:tabnr . "tab"
    execute a:tabnr . "tabnext"
endfunction

Works well, many thanks!


Select first item on enter

Hello.
How can I set the first item in the result-list, when the user press enter, without selecting it?
inp.addEventListener('autoComplete', (e) => {
    let detail = e.detail;

    if (detail.event.key == 'Enter'
        && detail.matches == 1) {
        // ???
        // onSelection should be triggered with the first item
    }

});

Hello @zippy84,
I hope the below snippet achieves what you're after
document.querySelector("#autoComplete").addEventListener("autoComplete", function(event) {
  const key = event.detail.event.which || event.detail.event.keyCode;
  if (key === 13) {
    console.log(event.detail.results[0]);
  }
});

Please try it and let me know how it went.
Have a good day, cheers! :)

No, the event-handler is not my problem. I want to simulate the click on the first item in the result list. The onSelect-function should be fired. Something like $(...).children().first.trigger('mousedown') doen't work.

I found the problem. This is my code:
inp.addEventListener('autoComplete', (e) => {
    let detail = e.originalEvent.detail;
    if (detail.event.key == 'Enter'
        && detail.matches > 0) {
        let f = this.a.resultsList.view.children.item(0);
        let ev = new Event('mousedown');
        f.dispatchEvent(ev);
    }
});

The mousedown doesn't work, because there is no event-listener on any item in the result-list. The autoComplete-event is fired on line https://github.com/TarekRaafat/autoComplete.js/blob/e27a6b83fc2f8285b52b35c906ec723cb13a5ef8/dist/js/autoComplete.js#L336
A few lines later getSelection will be called...
I think eventEmitter(event, list);should be followed after the if {...} else {...}-block.

Here is a solution:
inp.addEventListener('autoComplete', (e) => {
    let detail = e.originalEvent.detail;
    if (detail.event.key == 'Enter'
        && detail.matches > 0) {
        this.a.listMatchedResults(this.a.dataSrc).then(() => {
            let f = this.a.resultsList.view.children.item(0);
            let ev = new Event('mousedown');
            f.dispatchEvent(ev);
        });
    }
});

this.a is the autoComplete-instance.

I'm glad you came up with a suitable solution and thanks for sharing it.
I really like your approach, and I have another approach as well in case you want to capture the original event type.
document.querySelector("#autoComplete").addEventListener("autoComplete", (event) => {
  const detail = event.detail;
  if (detail.event.key === "Enter" && detail.matches > 0) {
    detail.selection = detail.results[0];
    autoCompletejs.onSelection(detail);
    autoCompletejs.resultsList.view.innerHTML = "";
  }
});

2020 solution:
document.querySelector("#autoComplete").addEventListener("keydown", event => {
	if(event.key === 'Enter') {
		    ac.listMatchedResults(ac.dataStream).then(() => {
            let f = ac.resultsList.view.children.item(0);
            let ev = new Event('mousedown');
            f.dispatchEvent(ev);
        });
	}
});

Hello @maximilian,
That's great!
Is it tested?
Cheers! :)

Newer versions doesn't trigger the event autoComplete when pressing Enter.

I want to migrate my script towards the new version. This does not work, because there is no listMatchedResults, dataStream and view anymore:
ac.listMatchedResults(ac.dataStream).then(l => {
    const f = ac.resultsList.view.children.item(0),
        ev = new Event('mousedown');
    f.dispatchEvent(ev);
});

How can I achieve the same with the new version?

Hello @zippy84,
You can use the rendered event instead as per the demo file which fires after fetching data and rendering the resultsList.
Try it let me know how it goes.
Cheers! :)


feat: Add gRPC Metrics

AFAICT these metrics are not specifically spring related, so they could be used by other bindings as well.
I think we could add it to the OpenTelemetry bindings repo directly that way other libraries would benefit from it as well and we don't risk having a different implementation from the rest.
We could still have the required autoconfiguration for the metrics in this library.
Or are there some already here: https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/grpc-1.6/library ?

@ST-DDT We are trying to implement the gRPC A66 metrics spec, with micrometer. We won't introduce any OTel dependency at this moment, and the instrumentation + exporting are fully implemented in micrometer. And later on, based on the micrometer instrumentation, OpenTelemetry may provide an end to end user experience in a non-invasive way, such as using a shim, etc.
I see you are the contributor of the gRPC metrics in micrometer as well, could you help to review and maybe accelerate the approval process there (we can implement in micrometer directly)?

We are trying to implement the gRPC A66 metrics spec, with micrometer. We won't introduce any OTel dependency at this moment, and the instrumentation + exporting are fully implemented in micrometer.

Oh, I for some reason I have mistaken this for OT.

I see you are the contributor of the gRPC metrics in micrometer as well, could you help to review and maybe accelerate the approval process there (we can implement in micrometer directly)?

Sure. Just ping me there and I'll have a look.

Closing this draft PR, as the changes have been merged in #1021.


Error: Failed to load the model.

I keep getting this error while I am trying to get transcribeRealtime. I am using React Native 0.71. I have followed all the steps mentioned for the installation. Below is an example of my code.
I am using this model:- https://huggingface.co/ggerganov/whisper.cpp/blob/main/ggml-base.en.bin
  const modelPath = 'file://../assets/ggml-base.en.bin';

   const wisperTranscripts = async () => {
    const options = {language: 'en'};
    const whisperContext = await initWhisper({modelPath});
    const {stop, subscribe} = await whisperContext.transcribeRealtime(options);
    subscribe(evt => {
      const {isCapturing, data, processTime, recordingTime} = evt;
      console.log(
        `Realtime transcribing: ${isCapturing ? 'ON' : 'OFF'}\n` +
          // The inference text result from audio record:
          `Result: ${data.result}\n\n` +
          `Process time: ${processTime}ms\n` +
          `Recording time: ${recordingTime}ms`,
      );
      if (!isCapturing) console.log('Finished realtime transcribing');
    });
  };

Let me know is there is any update regarding the same. Or am I doing something wrong?

const whisperContext = await initWhisper({modelPath});

The model path property is named filePath, and the documentation and example already make this clear.


[Bug]Fix of duplicated RM init on demo was missed by MR

[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description
Fix of duplicated RM init on demo was missed by MR
Ⅱ. Describe what happened
If there is an exception, please attach the exception trace:
Just paste your stack trace here!

Ⅲ. Describe what you expected to happen
Ⅳ. How to reproduce it (as minimally and precisely as possible)

xxx
xxx
xxx

Ⅴ. Anything else we need to know?
Ⅵ. Environment:

JDK version :
OS :
Others:

does this issue has been fixed?


Make a link to sample.env on README

Maybe have a link direct to the sample.env is a good idea

Perfect, thanks!


Financial aid minority students resource

Fixes #421
Added financial aid for minority students resource per

✅ By submitting this PR, I have verified the following

[ ✅] Checked to see if a similar PR has already been opened 🤔
[✅ ] Reviewed the contributing guidelines 🔍
[ ✅] Added my name to the bottom of the list under the Contributors section in the README.md with a link to my personal website or GitHub profile 👥 (Optional)

lgtm


Error 500 happens when logging into freshly cleaned base

This error happens because the template user_login_success.html calls the undefined function icon() to render a "check mark" icon. I think this issue belongs to a function that was planned to become part of the server but was not merged yet.

Login via http://localhost:8080/user/auth_userpassword/login

fixed in #5


Some inconsistencies between code and paper

I have been digging into your paper and code, and noticed some potential discrepancies between the paper and the code. I would appreciate it very much if you could clarify.

in training.py line 84

                for i in range(batch_mol.shape[0]):

                    # If molecule was modified
                    if not np.all(org_mols[i] == batch_mol[i]):

                        fr = evaluate_mol(batch_mol[i], e, decodings)
                        frs.append(fr)
                        rewards[i] += np.sum(fr * dist)

isn't the reward updated by rewards[i] += np.sum(fr * 1/(1+dist)) according to the paper(Eq. 12)?

In models.py Actor and Critic have different learning rates (0.0005 and 0.0001), but the paper mentions that they both have the same learning rate (page 19). I would like to know the reason for different learning rates, and if there are any more parameter changes, would appreciate it if you could tell me.

in training.py  line 112

            for i in range(BATCH_SIZE):

                a = int(actions[i])
                loss = -np.log(probs[i,a]) * td_error[i]
                target_actor[i,a] = td_error[i]

The variable loss is not used anywhere. From https://www.freecodecamp.org/news/an-intro-to-advantage-actor-critic-methods-lets-play-sonic-the-hedgehog-86d6240171d/ I see that the policy update should include the logarithm. So should the target_actor[i,a] = loss be the correct update?

Thank you for noticing this. This is an error in the code and I will fix it quickly. The variable dist is currently implementing as a weighted moving average of 1/(1+d) where d is the frequency of a given property. The difference to the paper is that in the paper, the weighted moving average is calculated over the d variable instead. As long as the beta parameter is large and that the frequencies don't varies a lot in every time step this difference would not be noticeable.

The learning rate 0.0001 was used to produce the result in the paper. When continuing to work with the code, we noticed that the same result could be achieved, but with a more stable optimization process if the critics learning rate was increased to 0.0005.

The loss variable was only used for debugging and was printed in an early implementation of the algorithm. The log probability is used to find the optimal policy and is implemented in the same way as in the blog you referee to (see line 22 in models.py).


Dutch translation fixes

Added AppCode related files to the gitignore file.
Fixed an issue in the Dutch translation that resulted in an underflow.

@Remyoman Thanks. I have manually merged the translations fix.

No problem, thank you for the fast handling.
One question: Why not add the appCode related gitignore lines?

@Remyoman I managed to put your PR in v3.1.0 update and not quite sure about what appCode actually is. I would be grateful if you could direct me more about it. Thanks.

AppCode is an Xcode compatible environment which can be used to develop iOS apps. It makes use of the Xcode command line tools and other internal Xcode features to make it work.
It is part of the Jetbrains IDE's which are all based on the same core which is open source if I recall correctly. You can find more information on their website. https://www.jetbrains.com/objc/
I will leave it at this before I go on a rant, I hope this satisfies your request.

@Remyoman thanks for your supplements, will merge it in next update. Thanks.


Reorganize the main branch

This PR reverts untested changes that were made to main along with adding the contents of 4.11.x and 4.14.x branches, as we need them to be on a new release.
This PR will leave main at the 4.15.0-SNAPSHOT version, meaning that the release process can be followed normally after it's merged.
This PR is the combination of the changes necessary for the Conscious Language Initiative and the WildFly 23 upgrade.
cc @jesuino

@mareknovotny Done.

Jenkins retest this


fix: Added semantic release git

:tada: This PR is included in version 1.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Reuse VF2 scoring views for all scoring

Summary
As part of the VF2Layout and VF2PostLayout passes when there are a large
number of matches found we're spending an inordinate amount of time in
scoring rebuilding the same views over and over again of the interaction
graph for each scoring call. For example, in one test cProfile showed
that with #11112 when running transpile() on a 65 qubit Bernstein Vazirani
circuit with a secret of all 1s for FakeSherbrooke with
optimization_level=3 we were calling vf2_utils.score_layout() 161,761
times which took a cumulative time of 14.33 secs. Of that time though
we spent 5.865 secs building the edge list view.
These views are fixed for a given interaction graph which doesn't change
during the duration of the run() method on these passes. To remove this
inefficiency this commit moves the construction of the views to the
beginning of the passes and just reuses them by reference for each
scoring call, avoiding the reconstruction overhead.
Details and comments
~This PR is based on top of #11112 and will need to rebased after #11112 merges. To see just what changes in this PR you can look at:~
~https://github.com/Qiskit/qiskit/commit/8cdc4eb036601e8422fd8816fdd6a8a6f28c3571~ This has been rebased.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

16 of 18 (88.89%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 86.883%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/transpiler/passes/layout/vf2_utils.py
12
14
85.71%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
73948

Relevant Lines:
85112

💛  - Coveralls

Now that #11112 has merged I've rebased this so it should be ready for review

I think that's a good idea. In the interest of minimizing the interface changes between 0.45.0rc1 and 0.45.0 I think we should just go with this for now (for backport). But I'll open an issue to track refactoring the scoring to be a pyclass that tracks everything like you're proposing.


SPL errors from hashes

This PR adds unique, custom error codes to every error in SPL libraries - including the two interfaces transfer-hook and token-metadata.
The ability to derive unique u32 error codes from hash inputs is powered by these changes to the spl-program-error crate, which simply hashes the following combination of inputs and takes bytes 13 through 16 as the little-endian u32:
"spl_program_error:" + <enum name> + ":" + <variant name>

This creates unique error codes for each error, as requested in this comment
Closes #5042
Solves discussions in #5168

On the topic of collisions, I felt like it was probably also overkill, but I have one particular concern about a hash randomly resulting in, say [1, 0, 0, 0] and colliding with (literally any) program errors. For this reason I suggest we lean toward a fixed 9 on the MSB and take only bytes 13, 14, and 15 from the hash. wdyt?

Ah right, that's a good point. Rather than remove a whole byte from the randomness, how about we just make sure that the number is >= 256 to be totally safe? and if it happens to be 0 <= x < 256, just shift over 1 byte until you get to a valid set of bytes.

It smells a bit like a macro anti-pattern to me

If you have a better way of surfacing that number easily for people looking at the source, I'm game! But I couldn't come up with anything else

On the topic of collisions, I felt like it was probably also overkill, but I have one particular concern about a hash randomly resulting in, say [1, 0, 0, 0] and colliding with (literally any) program errors. For this reason I suggest we lean toward a fixed 9 on the MSB and take only bytes 13, 14, and 15 from the hash. wdyt?

smh, I meant 256 not 9

Ah right, that's a good point. Rather than remove a whole byte from the randomness, how about we just make sure that the number is >= 256 to be totally safe? and if it happens to be 0 <= x < 256, just shift over 1 byte until you get to a valid set of bytes.

Which number are you referring to? The entire u32 integer itself? In my opinion we want to clear at least 5000 for Anchor errors, and likely even go a little further just to be safe for people who like to categorize with leading digits. Say, 10_000 or 100_000?

It smells a bit like a macro anti-pattern to me

If you have a better way of surfacing that number easily for people looking at the source, I'm game! But I couldn't come up with anything else

Nah I think it's okay. Unless I find some Rustaceans barking about it online, it's going in

Which number are you referring to? The entire u32 integer itself? In my opinion we want to clear at least 5_000 for Anchor errors, and likely even go a little further just to be safe for people who like to categorize with leading digits. Say, 10_000 or 100_000?

Sorry, yeah I mean the whole 4 bytes interpreted as a little-endian u32. Does Anchor start at 5000 for all programs? That seems very odd. If that's the case, we can just do 6000 or something, right? And that's already being plenty generous I'd say. If people use their own start, that's similar to just grinding a bunch of error names until you get something you like.

Which number are you referring to? The entire u32 integer itself? In my opinion we want to clear at least 5_000 for Anchor errors, and likely even go a little further just to be safe for people who like to categorize with leading digits. Say, 10_000 or 100_000?

Sorry, yeah I mean the whole 4 bytes interpreted as a little-endian u32. Does Anchor start at 5000 for all programs? That seems very odd. If that's the case, we can just do 6000 or something, right? And that's already being plenty generous I'd say. If people use their own start, that's similar to just grinding a bunch of error names until you get something you like.

They use the first digit as a category https://docs.rs/anchor-lang/latest/anchor_lang/error/enum.ErrorCode.html
and then users start at 6000 https://docs.rs/anchor-lang/latest/anchor_lang/error/constant.ERROR_CODE_OFFSET.html
I have 10,000 in my latest commit, I guess we could get away with 7,000 ?

Comments resolved!
This is a breaking change for anything using these libraries downstream. I'm thinking:

spl-program-error: 1.0.0 or 0.3.0 if we want to keep it in development
Any downstream crates: Bump minor version

wdyt?

This is a breaking change for anything using these libraries downstream

Sorry, maybe I'm missing something, but how is this change breaking? It passes CI without any changes to other libraries that are using it currently

This is a breaking change for anything using these libraries downstream

Sorry, maybe I'm missing something, but how is this change breaking? It passes CI without any changes to other libraries that are using it currently

Is it not technically breaking since the underlying error codes are changing?
CI is passing because I included changes to the tests where the expected error changed.
For example, anyone expecting TransferHookError::IncorrectAccount is now getting AccountResolutionError::IncorrectAccount, and furthermore anyone expecting some u32 like 1 is now getting 13498579 or something wild.

Is it not technically breaking since the underlying error codes are changing?

But that's only if you use hash_error_code_start, right?

Is it not technically breaking since the underlying error codes are changing?

But that's only if you use hash_error_code_start, right?

I'm thinking about if I'm working with spl_token_2022 and I'm expecting certain codes from, say transfer hook helpers. Also spl_token_client for that matter

Lmao Lennon would approve


Uncaught exception 'Slim\Exception\Stop'

Hey, thanks for your tidy little API.  I just installed it into my app, but I am receiving this error when using the JsonApi middleware + view...
PHP Fatal error:  Uncaught exception 'Slim\Exception\Stop' in /.../vendor/slim/slim/Slim/Slim.php:1017
Stack trace:
#0 /.../vendor/entomb/slim-json-api/jsonAPI/JsonApiView.php(86): Slim\Slim->stop()

I am calling the view render from another middleware's call() function as:
$this->app->render(401, array(
        		'error' => TRUE,
        		'message' => 'Access denied.'
        		));

Wondering why this happens and where would be the proper place to catch the exception?

hey!
this was suposed to be catched by the Slim core (on the Slim\call() method) so that Slim echos the body immediately and stops any further transformations or callbacks (like trying to find a template or re-setting the content type)
I need to test if anything changed or if any server config might be doing this, meanwhile can you try using $app->response()->write(); instead of app->stop() ?

Sorry for not updating earlier.  It seems to be happening when I echo/print anything before calling $app->render(), which I guess would interfere with the headers and would be my fault not Slim's or JsonApi ;)

Yeah, that might ruin the header assignment and output buffers too,
well, ok! thanks for the feedback!


(maint) fix link to fact_contents page

Prior to this release, the link to the fact_contents documentation
pointed to fact_contents.html while the file is fact-contents.html.
This commit fixes the incorrect href.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-enterprise.delivery.puppetlabs.net/job/enterprise_puppetdb_init-multijob_githubpr-master/660/
Test PASSed.

merged manually against stable


Feature request: Specify/define definition or word

There are times I'd like to literally make a joke entry with my own word and specify the pronunciation, word type, and definition. Any way you could add the ability to put those in when doing "Write your own"?

@stacksjb so one of these is possible: you can specify the definition of a word and then it will make up the word. It isn't as robust as the other method, so I didn't expose it via the website. Instead you can either look at the code or use this twitter bot: https://twitter.com/robo_define. If you tweet "@robo_define the feeling of sadness" it should reply with something it made up.
When you get into controlling pronunciation or word type, those are tasks I haven't trained on so it won't work yet!

Not sure you understand. I literally want to write my own word and definition (and/or type and pronunciation) entirely on my own. All I want the website to do is to render it into the pretty format and display.

Oh got it! For now, I'd probably recommend using the chrome developer tools to hack up the website html. As an alternative, the site source code is in https://github.com/turtlesoupy/this-word-does-not-exist/tree/master/website