Docs or guidance on writing additional third party fan out integrations

You mention Third Party integration fan out in the docs. I'm wondering if there are any documentation, or even just examples, of how to write additional integrations to send that information to other backends?

Hi @garethr!
The short answer is no :( we don't have documentation yet and in fact there is probably some work to do first to make sure the abstractions are properly set or to create an actual plugins architecture.
I can try to in the meantime explain what I believe would be the steps involved
1 - Implement the actual integration code
An integration need to implement this interface.
https://github.com/chainloop-dev/chainloop/blob/e770faeeed854cfcff45a06100f9a2eef57d779a/app/controlplane/internal/integrations/integration.go#L20-L29
and you can see the only integration we have right now (Dependency-Track for SBOMs) that implements this interface here

NOTE: OCI registries although they are depicted in our diagrams as fan-out integrations, it's implementation doesn't follow this approach for historical reasons, but it will fix with this https://github.com/chainloop-dev/chainloop/issues/28

2 - Registration logic
2.1 - Add use-case business logic
This means that an user can register their instance of the integration in their control-plane org. Basically this step
To do that you'd need to add an useCase to register the new integration in the biz layer. Similar to https://github.com/chainloop-dev/chainloop/blob/e770faeeed854cfcff45a06100f9a2eef57d779a/app/controlplane/internal/biz/integration.go#L94
that code will validate and store any credentials in the secrets storage, i.e dependency-track API key, and store an entry in the DB.
2.2 - Add API endpoint
Next, you'll need to add an API endpoint to add your new integration.
Similar to this one
https://github.com/chainloop-dev/chainloop/blob/e770faeeed854cfcff45a06100f9a2eef57d779a/app/controlplane/api/controlplane/v1/integrations.proto#L25-L27
3 - Enable attachment to workflows
At this point you'll have a mechanism for your users to add this new integration to their organization, so they'll be able to get smth like
$ chainloop integration ls
┌──────────────────────────────────────┬──────────────────┬──────────────────────────────────────────────┬─────────────────────┐
│ ID                                   │ KIND             │ CONFIG                                       │ CREATED AT          │
├──────────────────────────────────────┼──────────────────┼──────────────────────────────────────────────┼─────────────────────┤
│ c48f3041-5745-4773-aed9-ccf2f288b2e4 │ Dependency-Track │ host: https://dependency-track.chainloop.dev │ 21 Dec 22 16:29 UTC │
│                                      │                  │ allowAutoCreate: true                        │                     │
└──────────────────────────────────────┴──────────────────┴──────────────────────────────────────────────┴─────────────────────┘

Next, you'll need to implement how to allow your users to attach this new integration to their workflow, so they get fired once an attestation is received.
to do that
3.1 - Extend API with custom configuration
If the attachment command requires additional, specific configurations, you'll need to extend this oneof and it's handling
https://github.com/chainloop-dev/chainloop/blob/e770faeeed854cfcff45a06100f9a2eef57d779a/app/controlplane/api/controlplane/v1/integrations.proto#L96-L99
3.2 - Handle attach to workflow logic
https://github.com/chainloop-dev/chainloop/blob/e770faeeed854cfcff45a06100f9a2eef57d779a/app/controlplane/internal/biz/integration.go#L269
4 - Implement the actual firing mechanism
Now our new integration is ready to 1) be registered by any organization and 2) be attached to as many workflows as needed.
Next, we need to implement the actual actuation of the integration code you implemented in step 1.
And this is by far the part that needs more work. I have pending adding an issue about adding an event bus (nats.io or similar) to handle persistence, retries, etc.
but for now the code is executed in the service implementation when the attestation is received, like for example
https://github.com/chainloop-dev/chainloop/blob/e770faeeed854cfcff45a06100f9a2eef57d779a/app/controlplane/internal/service/attestation.go#L223
I know that this is a lot to digest and it's current architecture is not great. As I mentioned before, it might make sense to try to extrapolate most of these changes as part of a new registration/attachment interface, so adding adding a new integration code will be mostly encapsulated in the first step.
I am going to take a look at that as part of https://github.com/chainloop-dev/chainloop/issues/28 but if you have any thoughts, want to chat or help please let me know!!
Thank you!

I love "The short answer is no" and then the longer answer being all the details that would be needed, along with all of the context 🥇
I'll definitely take a look if/when I have time, and will track the issue mentioned.
Thanks for the detailed response.

Sounds good! and yes, I error on the verbosity side as long as a TLDR is in place haha :)
For the record, and to elaborate on my previous statement...

... there is probably some work to do first to make sure the abstractions are properly set or to create an actual plugins architecture.

These are some of the additional work streams around third-party integrations that I have on top of my priority list.

https://github.com/chainloop-dev/chainloop/issues/38
https://github.com/chainloop-dev/chainloop/issues/39

In any case @garethr, if you have in mind any specific integration you'd like to explore or have added to Chainloop, feel free to let us know.
Having an integration candidate will also help with the effort on defining the right abstractions and documentation.
Thank you!

Hi @garethr. We just wanted to let you know that we've put in place a new plugins sdk and documentation. This allows anybody to add a fan-out integration in an encapsulated manner. Note: plugins are not fully decoupled from there core yet, we will get there :) https://github.com/chainloop-dev/chainloop/issues/195
We also expect to have a build a plugin example published sometime in the future, but in the meantime, is there any integration endpoint/use-case that you could think it would be interesting to implement? We'd happy to give it a crack.


Rename THREADS_PER_COMMAND to QBATCH_THREADS_PER_COMMAND and also export OMP_THREAD_LIMIT

We should use the QBATCH prefix everywhere.
Also it seems nproc will honour OMP_THREAD_LIMIT which means that many apps which rely on openmp will use proper number of threads even if script writers didn't do anything with QBATCH_THREADS_PER_COMMAND

https://www.gnu.org/software/coreutils/manual/html_node/nproc-invocation.html

https://www.openmp.org/spec-html/5.0/openmpse58.html


Mainv

Zero To Mastery - Webblocks 2022 📦📦
👉 Please remove the below and replace with your own values, leaving the headers where they are. 👈
PR contains:

INFO ABOUT YOUR PULL REQUEST GOES HERE (Please be as descriptive as possible) 🤜

Breaking changes

IF ANYTHING YOU'RE COMMITTING WOULD BREAK SOMETHING, INCLUDE HERE WHAT WOULD BREAK
IF YOU HAVE NO BREAKING CHANGES, ENTER 'None'

Screenshots

IF YOU HAVE ANY SCREENSHOTS, INCLUDE THEM HERE.
IF YOU HAVE NO SCREENSHOTS, ENTER 'None'

Please fill out the pull request template.
Please provide the license/proof of rights to the images and the music you used. These are normally under copyright. We cannot accept this PR unless we can be sure that you legally have the right to this content.

Closing due to unresolved change request. Feel free to resolve and reopen.


Add links to issues in new contributors documentation.

This fixes issue #6561 in the pymc repo.
Added two links: one for issues with the beginner friendly tag, and another for all issues.
@jessegrabowski this seemed like a good first issue, per your suggestion.

:books: Documentation preview en :books:: https://pymc-data-umbrella--228.org.readthedocs.build/en/228/

:books: Documentation preview es :books:: https://pymc-data-umbrella-es--228.org.readthedocs.build/es/228/

:books: Documentation preview pt :books:: https://pymc-data-umbrella-pt--228.org.readthedocs.build/pt/228/

@alex-rand Thank you for taking the time to submit this PR.
We are closing this for a few reasons.
Recommend watching this video on best practices.
(Ex 1: Do not submit a PR with so many files because it is difficult to review:  https://youtu.be/dyxS9KKCNzA).
(Ex 2: ask maintainers if they want the whitespace removed first before submitting changes to 100+ files.)
You can submit a pull request with edits to this one file:
contributing/tutorials/environment_setup.md

Yikes, thanks for reviewing. Not sure what happened here, I'll try again in a new PR.


linking libcuda.so.1 in a Docker image at build time

System information

Host system Ubuntu 18.04
TensorFlow r1.13 branch
Installing from nvidia/cuda:10.0-cudnn7-devel-ubuntu16.04 base docker image
Bazel 0.21.0
GCC/Compiler version (if compiling from source):
Cuda 10.0, cuDNN 7.4
RTX 2080 Ti

Describe the problem
When building //tensorflow/libtensorflow.so in a RUN step of my Dockerfile, I get this error:
ERROR: /tensorflow/tensorflow/cc/BUILD:477:1: Linking of rule '//tensorflow/cc:ops/data_flow_ops_gen_cc' failed (Exit 1)
/usr/bin/ld: warning: libcuda.so.1, needed by bazel-out/host/bin/_solib_local/_U_S_Stensorflow_Scc_Cops_Sdata_Uflow_Uops_Ugen_Ucc___Utensorflow/libtensorflow_framework.so, not found (try using -rpath or -rpath-link)
<snip>
Target //tensorflow:libtensorflow.so failed to build
ERROR: /tensorflow/tensorflow/cc/BUILD:477:1 Linking of rule '//tensorflow/cc:ops/nn_ops_gen_cc' failed (Exit 1): crosstool_wrapper_driver_is_not_gcc failed: error executing command
  (cd /root/.cache/bazel/_bazel_root/68a62076e91007a7908bc42a32e4cff9/execroot/org_tensorflow && \
  exec env - \
    PATH=/bin:/usr/bin \
    PWD=/proc/self/cwd \
  external/local_config_cuda/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -o bazel-out/host/bin/tensorflow/cc/ops/nn_ops_gen_cc '-Wl,-rpath,$ORIGIN/../../../_solib_local/_U_S_Stensorflow_Scc_Cops_Snn_Uops_Ugen_Ucc___Utensorflow' '-Wl,-rpath,$ORIGIN/../../../_solib_local/_U@local_Uconfig_Ucuda_S_Scuda_Ccudart___Uexternal_Slocal_Uconfig_Ucuda_Scuda_Scuda_Slib' -Lbazel-out/host/bin/_solib_local/_U_S_Stensorflow_Scc_Cops_Snn_Uops_Ugen_Ucc___Utensorflow -Lbazel-out/host/bin/_solib_local/_U@local_Uconfig_Ucuda_S_Scuda_Ccudart___Uexternal_Slocal_Uconfig_Ucuda_Scuda_Scuda_Slib -Wl,-ldl '-Wl,-rpath,$ORIGIN/,-rpath,$ORIGIN/..,-rpath,$ORIGIN/../..' -pthread -Wl,-rpath,../local_config_cuda/cuda/lib64 -Wl,-rpath,../local_config_cuda/cuda/extras/CUPTI/lib64 -Wl,-S -Wl,-no-as-needed -pie -Wl,-z,relro,-z,now '-Wl,--build-id=md5' '-Wl,--hash-style=gnu' -no-canonical-prefixes -fno-canonical-system-headers -B/usr/bin -Wl,--gc-sections<EMAIL_ADDRESS>Execution platform: @bazel_tools//platforms:host_platform
INFO: Elapsed time: 229.527s, Critical Path: 139.75s
INFO: 2250 processes: 2250 local.

This only occurs when trying to build in a RUN step. If skip buliding and shell into the container, it builds to completion. There are several similar issues on github, two of the most similar are:
https://github.com/tensorflow/tensorflow/issues/16184
https://github.com/tensorflow/tensorflow/issues/14573
Particularly https://github.com/tensorflow/tensorflow/issues/14573#issuecomment-362424509
I have tried every variation of the advice given in that thread, as well as cribbed lines from this Dockerfile that is doing a similar thing:
https://github.com/gunan/tensorflow-docker/blob/master/gpu-devel/Dockerfile.ubuntu#L64
Yet, I'm still getting this message.
I don't know what exactly nvidia is doing with its cuda libraries, but I think they are not in all the same places at buildtime and runtime. I discovered this discrepancy accidentally with RUN find / | grep libcuda.so.1 in my Dockerfile:
/usr/local/cuda-10.0/compat/libcuda.so.1

This is the only place that libcuda.so.1 exists at build time. However, even if I symlink from /usr/local/cuda-10.0/compat/libcuda.so.1  to  a place that is definitely in LD_LIBRARY_PATH, and make sure to pass action_env=LD_LIBRARY_PATH=${LD_LIBRARY_PATH}, I still get this error.
I'm completely stumped at this point.
To reproduce this you can use the dockerfile attached at the bottom of this post.
Build in the container - works:
docker build -f test.dockerfile -t masontest . && docker run --vm=nvidia --rm masontest
cd /tensorflow
RUN bazel build \
 --verbose_failures \
 --spawn_strategy=standalone \
    --genrule_strategy=standalone \
    --action_env=LD_LIBRARY_PATH=${LD_LIBRARY_PATH} \
    //tensorflow:libtensorflow.so

Uncomment the bazel command - the image fails to build with the linker error above.
FROM nvidia/cuda:10.0-cudnn7-devel-ubuntu16.04
# TF docker (https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/dockerfiles/dockerfiles/devel-gpu.Dockerfile)
# uses cuda:10.0-base-ubuntu16.04, but we need full sources
# because later in this docker we are going to compile Tensorflow from scratch
# using bazel.

# so we aren't prompted to set up the keyboard and other nonsense
ENV DEBIAN_FRONTEND noninteractive

RUN set -eux; \
    apt-get update && apt-get install -y --no-install-recommends \
    autoconf \
    automake \
    build-essential \
    ca-certificates \
    g++ \
    gcc \
    git \
    # these were needed by the mnistCUDNN demo
    libfreeimage3 \
    libfreeimage-dev \
    make \
    # bazel needs python2 https://github.com/tensorflow/tensorflow/issues/15618
    python \
    # tf needs swig
    swig \
    unzip \
    wget \
    zlib1g-dev; \
    apt-get clean; \
    rm -rf /var/lib/apt/lists/*

# Tensorflow pukes when you try this with 0.22.0
ENV BAZEL_VERSION 0.21.0
WORKDIR /
RUN mkdir /bazel && \
    cd /bazel && \
    wget https://github.com/bazelbuild/bazel/releases/download/$BAZEL_VERSION/bazel-$BAZEL_VERSION-installer-linux-x86_64.sh && \
    # curl -fSsL -o /bazel/LICENSE.txt https://raw.githubusercontent.com/bazelbuild/bazel/master/LICENSE.txt && \
    chmod +x bazel-*.sh && \
    ./bazel-$BAZEL_VERSION-installer-linux-x86_64.sh && \
    cd / && \
    rm -f /bazel/bazel-$BAZEL_VERSION-installer-linux-x86_64.sh

RUN echo $(g++ --version)
RUN echo $(bazel version)

### TENSORFLOW
ENV TENSORFLOW_VERSION r1.13
RUN git clone https://github.com/tensorflow/tensorflow.git && \
    cd tensorflow && \
    git checkout ${TENSORFLOW_VERSION}

ENV PYTHON_LIB_PATH /usr/local/lib/python2.7/dist-packages
ENV PYTHONPATH /tensorflow/lib
ENV PYTHON_ARG /tensorflow/lib

ENV GCC_HOST_COMPILER_PATH /usr/bin/gcc
ENV CC_OPT_FLAGS="-march=native"
ENV CUDA_TOOLKIT_PATH /usr/local/cuda
ENV CUDNN_INSTALL_PATH /usr/lib/x86_64-linux-gnu
ENV TF_CUDA_COMPUTE_CAPABILITIES 7.0
ENV TF_CUDNN_VERSION 7
ENV TF_CUDA_VERSION 10.0
ENV TF_NEED_GCP 0
ENV TF_ENABLE_XLA 0
ENV TF_NEED_OPENCL 0
ENV TF_NEED_CUDA 1
ENV TF_CUDA_VERSION 10.0.0
ENV TF_NEED_HDFS 0
ENV TF_NEED_TENSORRT 0
ENV TF_NCCL_VERSION 2
ENV TF_BUILD_BRANCH r1.13
ENV TF_NEED_ROCM 0
ENV TF_NEED_OPENCL_SYCL 0
ENV TMP /tmp/tensorflow
RUN echo "startup --batch" >>/etc/bazel.bazelrc

ENV LD_LIBRARY_PATH="/usr/local/lib:/usr/local/cuda/lib64:/usr/local/cuda/lib64/stubs:${LD_LIBRARY_PATH}"

RUN find / | grep  libcuda.so.1
WORKDIR /tensorflow
RUN yes '' | ./configure
# https://github.com/gunan/tensorflow-docker/blob/master/gpu-devel/Dockerfile.ubuntu#L64
# Is this ln -s is necessary when building? Doesn't seem to help, and the actual libcuda ... https://github.com/tensorflow/tensorflow/issues/14573#issuecomment-362424509
# Similarly, we need to workaround sandboxing issues: https://github.com/bazelbuild/bazel/issues/418
RUN ln -s /usr/local/cuda/lib64/stubs/libcuda.so /usr/local/cuda/lib64/stubs/libcuda.so.1
# RUN bazel build \
#  --verbose_failures \
#  --spawn_strategy=standalone \
#     --genrule_strategy=standalone \
#     --action_env=LD_LIBRARY_PATH=${LD_LIBRARY_PATH} \
#     //tensorflow:libtensorflow.so

Building this at head succeded, presumably because https://github.com/tensorflow/tensorflow/issues/16184 switched to dynamic loading of libcuda. It sure would be nice to have a working development Docker with the latest stable release but I understand that there are a lot of things that would be nice to have. I can't imagine that this is only broken for me - I'm just not doing anything special.

Related issue - original incidence of this issue and the originally proposed fix. Will try it tonight.
https://github.com/tensorflow/tensorflow/pull/13399

Also https://github.com/NVIDIA/nvidia-docker/issues/775

I've marked this as "Community Support" because the TF team doesn't officially support building inside a Docker build process.
@masonk, do the official Docker images not meet your use case? We provide images with the latest stable releases and with the nightly packages pre-installed with Nvidia GPU support.

@angersson
I don't think that the official images meet my use-case, because I am building a Rust app that uses the rust-tensorflow (bindings to the C API), and it needs to link against libtensorflow, which I did not find in the official images.
I was able to build GPU-enabled libtensorflow v1.12.0 from scratch using a customer Dockerfile, which I will reproduce here for posterity.
FROM nvidia/cuda:9.0-cudnn7-devel-ubuntu16.04
# TF docker (https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/dockerfiles/dockerfiles/devel-gpu.Dockerfile)
# uses cuda:10.0-base-ubuntu16.04, but we need full sources
# because later in this docker we are going to compile Tensorflow from scratch
# using bazel.
# so we aren't prompted to set up the keyboard and other nonsense
ENV DEBIAN_FRONTEND noninteractive

RUN set -eux; \
    apt-get update && apt-get install -y --no-install-recommends \
    autoconf \
    automake \
    build-essential \
    ca-certificates \
    g++ \
    gcc \
    git \
    less \
    # these were needed by the mnistCUDNN demo
    libfreeimage3 \
    libfreeimage-dev \
    # These two packages allow a TF to be built that run on multiple GPUs
    # libnccl2 libnccl-dev \
    # Seraphim depends on libssl via the openssl-sys crate (which I think is a transitive dep of ctrlc)
    libssl-dev \
    lldb-7 \
    gdbserver \
    make \
    # Rust libssl crate uses pkg-config to find the openssl system headers
    pkg-config \
    # bazel needs python2 https://github.com/tensorflow/tensorflow/issues/15618
    python \
    # tf needs swig
    swig \
    #just for my own convenience, I like this package
    tree \
    unzip \
    wget \
    zlib1g-dev; \
    apt-get clean; \
    rm -rf /var/lib/apt/lists/*

# This version has to correspond to the appropriate bazel version
# r1.12 can't be built with bazel 0.19 https://github.com/tensorflow/tensorflow/issues/23401#issuecomment-434681778
# It also can't be built with any higher version of bazel that I tried
# Note to self for the future: r1.13 can be built with bazel 0.21, but not 0.22
ENV BAZEL_VERSION 0.18.0
WORKDIR /
RUN mkdir /bazel && \
    cd /bazel && \
    wget https://github.com/bazelbuild/bazel/releases/download/$BAZEL_VERSION/bazel-$BAZEL_VERSION-installer-linux-x86_64.sh && \
    # curl -fSsL -o /bazel/LICENSE.txt https://raw.githubusercontent.com/bazelbuild/bazel/master/LICENSE.txt && \
    chmod +x bazel-*.sh && \
    ./bazel-$BAZEL_VERSION-installer-linux-x86_64.sh && \
    cd / && \
    rm -f /bazel/bazel-$BAZEL_VERSION-installer-linux-x86_64.sh

RUN echo $(g++ --version)
RUN echo $(bazel version)

### TENSORFLOW
# rust-tensorflow works with r1.12
# https://github.com/tensorflow/tensorflow/issues/25865
ENV TENSORFLOW_VERSION r1.12
RUN git clone https://github.com/tensorflow/tensorflow.git && \
    cd tensorflow && \
    git checkout ${TENSORFLOW_VERSION}

ENV TF_NEED_CUDA 1

WORKDIR /tensorflow
RUN yes '' | ./configure
# https://github.com/gunan/tensorflow-docker/blob/master/gpu-devel/Dockerfile.ubuntu#L64
# This ln-s is necessary when building ... https://github.com/tensorflow/tensorflow/issues/14573#issuecomment-362424509
# Similarly, we need to workaround sandboxing issues:
#   https://github.com/bazelbuild/bazel/issues/418

# Context for this elaborate bazel invocation is here https://github.com/tensorflow/tensorflow/issues/25865
# TLDR: tf <=1.13 links to libcuda.so.1 at build time, but those headers aren't available in the nvidia docker
# at build time. (They are mounted in the running container, but not at build time). So we link to
# stubs to satisfy the build-time linker.


How to disable vendor prefix generation?

display: -webkit-box;
display: -webkit-flex;
display: -ms-flexbox;
display: flex;

This generates extra data and very big styles tag in browser for large applications!

Hi again @moghaddam01,
Yes it can be disabled by customising the cache with the speedy option, assuming you are using TSS alongside mui it will look something like:
import createCache from "@emotion/cache";
import { TssCacheProvider } from "tss-react";
import { CacheProvider } from "@emotion/react";

const muiCache = createCache({
    "key": "my-custom-prefix-for-mui",
    "prepend": true,
    "speedy": true
});

const tssCache = createCache({
    "key": "my-custom-prefix-for-tss",
    "speedy": true
});

<CacheProvider value={muiCache}>
    <TssCacheProvider value={tssCache}>
        {/* ... */}
    </TssCacheProvider>
</CacheProvider>;

Many thanks @garronej !

Hi @moghaddam01,
You are welcome :)

I think, not bad to keep the same (default) behavior like MUI package

Disabling vendor prefix isn't the default behavior, as you can see here, is you do not explicitly provide
an emotion cache to MUI with <CacheProvider />, MUI is using a cache in which the speedy option isn't enabled.
You can take any MUIv5 example and see for yourself, vendor prefixes are generated.

Besides, the generation of those multiple instructions are ensuring cross browser consistency.  Maybe your apps are running in a very controlled environment (like Electron for example) and you don't need those alternatives rules generated but the default should remain unchanged.

and it's not good idea to add CacheProvider and TssCacheProvider to elements trees for them

Are you aware that, if you are using TSS, it si mandatory to provide at least  a <CacheProvider /> explicitly.
I assume the codemod doesn’t do it automatically but you have to. See ref.
Best,


Corrected the URL

Microsoft Trademark and Brand Guidelines - URL updated with "en-us" (line no. 29).

Docs Build status updates of commit 21e59dc:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/concepts/deploy-and-publish/appsource/prepare/detail-page-checklist.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Fix: unbreak master

Summary
Fix a test from #5658 (cc @orta) and adjust circle config a bit
Test plan

please run prettier.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@b789dca). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #5672   +/-   ##
=========================================
  Coverage          ?   63.16%
=========================================
  Files             ?      216
  Lines             ?     7913
  Branches          ?        4
=========================================
  Hits              ?     4998
  Misses            ?     2914
  Partials          ?        1

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 b789dca...a49df4d. Read the comment docs.

Thank @thymikee


Swarming bot fails to report error on task

It appears that the bot takes about an hour to complete the task, and then at the end, the task fails, and it tries to report that it failed the task. It does
337 2017-01-26 19:00:36.154 D: "POST /swarming/api/v1/bot/event HTTP/1.1" 401 28
And retries a couple times, and then gives up. This causes the task to show up as BOT_FAILED, when it really just failed the test.
I can add more logs in a bit.

Based on server logs, this is an issue with particular bots, not Swarming server. Let's discuss it elsewhere.


Debugger doesn't work when some thread enters an infinite loop

I have c# extension 1.21.9 with dotnet core version 3.1, running on linux.
I tried to debug a program that in Main method runs an infinite loop, for t
esting purposes. The problem was that after I started debugging, even though it was shown that program has started, I didn't see any info about it incl. list of threads in call stack view.
Actually, when I have tried to pause the program to inspect stack traces it didn't really work. After a try to pause, even the stop command stopped working. It was also impossible to kill the dotnet process unless doing it forcibly.
The example program is:
using System;

class Program
{
    static void Main()
    {
        while (true) { }
    }
}

Closing this as resolved external since this is a CoreCLR bug.


spellcheck

The first PR experience was so nice so that I thought I'd open one more ;)
I just ran codespell .

Great work, thanks again!


Add version information to Default Taxonomy models

Closes #129
Description Of Changes
The idea here is to add fields to the default taxonomy that enable us to programmatically version each record.
This is useful for doing things like data migrations over in Fides as well as signaling to users when something gets deprecated without removing it in a totally destructive manner.
Code Changes

[x] add the new fields to the taxonomy models
[x] Refactor default taxonomy to use a factory for default items, as well as store the new fields in a separate class for inheritance
[x] add validators and tests for the new functionality

Steps to Confirm

[ ] new tests should cover everything

Pre-Merge Checklist

[x] All CI Pipelines Succeeded
[x] Documentation Updated
[x] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[x] Update CHANGELOG.md

holding off on merge until the upstream gets merged in to keep the PRs cleaner


gps: Use refspec on git fetch to ensure tags prune

What does this do / why do we need it?
git fetch --tags --prune does not, annoyingly, actually prune tags.
For tags to actually be pruned, an explicit refspec has to be passed.
The only reason this hasn't affected us is because we always rely on git
ls-remote for enumerating versions, never what we happen to have on
local.
Needs tests - we should verify correct local pruning of both branches and tags. (this is one of those state change things that'd be waaaaay easier to test with a local repo framework)

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!


Add a command-line flag to override the major/minor/patch release detection logic

Here's an idea: Add a command-line flag to say "assume that the next release is a minor release". Then we can just pass that in CI rather than messing around with the Cargo.toml.
We don't need the patch-release checks, and if we ever want to make a major release of anything again, we can turn off the semver check for that crate temporarily.

Originally posted by @Darksonn in https://github.com/tokio-rs/tokio/issues/5437#issuecomment-1424325701
Possible workaround for users until we can come up with a more full-fledged solution for https://github.com/obi1kenobi/cargo-semver-checks/issues/58

Possible names:

--assume-release

Would probably take the form of an option, like --some-option-name minor or --some-option-name major.
Let's bikeshed some names for --some-option-name. Proposals so far:

--assume-release
--assume-change
--assume-version
--release-type
--lint-level

Any others? Any strong feelings toward or away any of these?
@tonowak @epage would love your thoughts in particular. This addition would make cargo-semver-checks easier to use in tokio, and probably in other crates that don't want #[must_use] lints before #58 is implemented as well.

Although my opinion probably doesn't count much :)
I like --lint-level, although it kind of suggests that it only enables lints of that level and above instead of forcing the change version increment type to that level. Maybe --force-lint-level?

We appreciate your opinion!
I had the same thought process with --lint-level, it implies >= instead of > which seems problematic. And if we're getting into 3-word territory then I think I like --assume-release-type better than --force-lint-level.

There are two angles to lint levels, compatibility level and reporting level.

Would an example of reporting level be "for our crate, MSRV changes are patch, regardless of what cargo-semver-checks thinks"?
What's an example of the compat level of the project?

rustc has the concept of "cap lints", meaning you can limit what lint levels get reported.  This is currently used when building dependencies to prevent their warnings from being shown.  Using similar terminology might help?  So --cap-semver?

I do like --assume-release-type.

Would an example of reporting level be "for our crate, MSRV changes are patch, regardless of what cargo-semver-checks thinks"?

In #58 I talked about compat level (major, minor, patch) in the same breath as reporting level (forbid, deny, warn, allow) but they are separate concepts in discussion, regardless of how we present them in UI

Re: --cap-semver, I'm worried that the "mental image" it gives is wrong, sort of like with --lint-level. "Cap" to me sounds like "don't report above this level" not "only report above this level" -- like capping a bottle of water. --cup-semver would be a funny joke but more visually appropriate :)

I lean towards something like do --compat <level> or --semver <level>.

Would you be opposed to --assume-semver <level>? The bare --semver seems not immediately obvious, and the "assume" really does the trick for me for some reason.

An interesting angle to this is "major", "minor", and "patch" will likely be relative (0.x.y has "x" as major in relative terms and minor in absolute terms). cargo release (not on the table for merging into cargo) and cargo set-version (possible but no one has requested it yet) both treat the terms as absolute as you need to be able to bump from "0.x" to "y.0" though relative terms would also be useful. I've not yet figured out how to solve the naming discrepancy between relative and absolute.

Yes, I think the semver levels have to be relative here, but I agree that it makes sense for cargo release and cargo set-version to use absolute naming instead, with an option to switch to relative. No ideas on the naming there, naming is hard!

@obi1kenobi Here a first draft. Review appreciated

For CLI features so far we've been using CI jobs over real-world crates. I can add that in a separate PR if you'd prefer, it's not hard for me to do.

There is something about --assume-semver that isn't clicking with me. Really, what we are doing is saying is "override the inferred (or assumed) semver level".  In a lot of cases when overriding an explicit value, you make the flag name corrspond to what you are overriding.  So I still see --semver making sense but could also seem something like something like "check this semver is compatible".
That spelled out idea is making me think this is a jumbled ball as it ties into #86

what ideas are conveyed in the command vs needing to be explicit
Should we be telling the checks what the state of the project is (--semver patch reports everything above patch) or what we want checked.  Neither feels quite right for me.

For CLI features so far we've been using CI jobs over real-world crates. I can add that in a separate PR if you'd prefer, it's not hard for me to do.

Alternatively, an integration test in the tests/ directory can run the CLI just like an user would run. Here's an example: https://github.com/obi1kenobi/cargo-semver-checks/blob/main/tests/verify_binary_contains_lints.rs

I think it's much harder to understand the meaning of a flag checking > semver issues, compared to >= semver issues. My first thought behind the meaning of --lint-level flag was indeed "those issues and more serious issues are checked" and not "only more serious issues than the specified type are checked". That's how error levels are defined and defining it otherwise might be really misleading.

Should we be telling the checks what the state of the project is (--semver patch reports everything above patch) or what we want checked. Neither feels quite right for me.

If I was a first-time user of the tool, I would try to first run the tool and then limit the output to only those lints I care about -- I would prefer to specify what needs to be checked and experiment with it, and not specifying what the state of the project is (especially that "state of the project" is clear in the sense of PRs, but not necessarily for people experimenting with the CLI in their project).
Also, >= is less restrictive than >, so if someone would wrongly understand what the flag does, one would just get more lints than wanted and would probably notice it, which is not the case with >, where some lints would not run.
The meaning of the --assume-semver flag for me is not clear at all.

That's pretty compelling. I have changed my mind, I support --lint-level with >= semantics.
@epage how do you feel about --lint-level? Would you rather we set aside some time soon and hash out #86 more thoroughly, or is going forward with --lint-level worth it for now?

Reading those comments I think it's important to highlight it again: You are talking about two different mechanisms here.

filtering: Meaning, hiding checks that are irrelevant for the given versions
overriding: Ignoring the given versions and assuming that they are a certain type to each other, for example minor.

Which one do we want to implement now?

Here's my mental model. There are two level of lints:

Patch-lints. Lints that are only relevant to patch releases.
Minor-lints. Lints that are relevant to both minor and patch releases.

And then, depending on the kind of release you're making, you either get both lint types, or only the minor lints. Both --release-type and --lint-level make sense to me as an option for configuring which set of lints you get.
I don't really understand the idea behind the --assume-semver name.

@Darksonn So the question is, if the new version number in Cargo.toml is a minor change, and we set --lint-level to minor, What lints should run?

Only major checks, because that's all that's required if our version increment is minor?
major and minor checks, because the --lint-level is set to minor?

FWIW, to me it seems like it would be the latter: --lint-level X includes level X and above. --lint-level major means major-only. To disable even major lints, just don't run the tool because there's nothing it can run then.

@obi1kenobi That's how I implemented it.
@obi1kenobi, @Darksonn, @tonowak, @epage: Next review request, now with --lint-level :)
Is that what you had in mind now?

@obi1kenobi I now implemented it so that two things have to be given for a lint to run:

The version of the Cargo.toml and the currently published version must make the lint relevant; if the version in Cargo.toml is a major version change, nothing should run because everything is allowed
The --lint-level flag must not hide the lint; if --lint-level is major, checks for minor lints are hidden

I think a lot of confusion in this entire discussion comes from the fact that there is a brainf*ck mismatch between version increments and filter levels.
A minor version change means that only major lints have to run, and if we do >= filtering with --lint-level (which I am strongly in favor of), that means that a minor version change corresponds to a --lint-level major. Which does make sense, but takes a while to realize why, in my opinion.

For me, the problem is there are two different kinds of lint levels, the semver level and the reporting level.  Granted, rustc's version of "lint level" for reporting has a different name (cap lint) so we would unlikely use --lint-level for reporting.  The only question is how much we confuse users over this.
I will say, runtime experience is one way to learn so we can go forward with a name but we should call out re-evaluating it in the stablization / cargo merge Issue.

(also I disagree with the "override" framing as instead the flag is saying what is happening but the tool is inferring a default, same effect different mental model).

@epage No override is happening. It's an additional filtering. There is no override framing any more, that was in the previous change that was rejected for that reason.
As there still seems to be a lot of confusion, let me propose a new solution:
Reasoning
There are only two lint levels:

major (which check if a major version increment is required)
minor (which check if a minor version increment is required)

So having a --lint-level [major/minor] would simply mean:

--lint-level minor: run all lints
--lint-level major: skip minor lints

Proposal
As this is quite unintuitive, why not introduce a flag --skip-minor-lints?
Without the flag, it simply runs all lints, and with the flag, it skips minor lints.
Skipping major lints makes no sense, because this is equal to simply not running the tool.
Skipping patch lints makes no sense, because there are no patch lints. (Every version increment is at least a patch increment, so there's not point in checking whether a patch increment is required)
So from a filter point of view, enabling or disabling minor lints is really all the lint level sensitivity filtering that can every be performed. And the name --skip-minor-lints would be trivially to understand for everyone.
Thoughts, @obi1kenobi?

@Finomnis regardless of the name, I've always seen this as --lint-level being defaulted by the version change, not that they are separate checks.  Is there a part of the discussion I glossed over where that changed?

@epage I think different people are talking about different things here.
I'm pretty sure @Darksonn is talking about filtering/separate check:

Here's my mental model. There are two level of lints:

Patch-lints. Lints that are only relevant to patch releases.
Minor-lints. Lints that are relevant to both minor and patch releases.

And then, depending on the kind of release you're making, you either get both lint types, or only the minor lints. Both --release-type and --lint-level make sense to me as an option for configuring which set of lints you get.
I don't really understand the idea behind the --assume-semver name.

Apart of the fact that she's calling it patch and minor lints, based on what what version increments they are relevant for, and the code calls them minor and major lints, based on what version increment those changes would require.
I assumed you were talking about the same thing, I think I misread this message of yours:

There is something about --assume-semver that isn't clicking with me. Really, what we are doing is saying is "override the inferred (or assumed) semver level".

I think I read that as "you don't want an override".
It might make sense to have an actual override, but after talking about it, I think what we really need in tokio is a --skip-minor-lints type flag. (correct me if I'm wrong, @Darksonn) This flag would then only run checks that would require a major version increment, or as @Darksonn puts it, that are relevant if you want to publish a new minor version.

New attempt to implement what we need in tokio. Feedback appreciated.

@epage I just read through #58 and your point of view makes a little more sense to me now. With that, let me talk about this post of yours again, because I think it's very relevant to which direction to go into:

Correction, there are three angles to all of this

the compat level of a lint
the reporting level of a lint
the compat level of the project

We need to be able to change the compat level of a lint (#58) and declare the compat level of the project (this project). We should decide on names in tandem between this and #58 to make sure they are aligned.

I'm not 100% sure what you mean with that.
The "compat level of a lint" makes sense to me, this is what type of version increment is required if the lint fails.
The "compat level of the project" kind of confuses me, why would a project be of a specific compat level? Shouldn't it depend on the specific PR, and which version the project wants to publish next?
I don't completely understand the "reporting level of a lint". Is this at what level to report, but without making the check fail?

The level that I'm interested in is the "filter level of the project", meaning, downgrade lints that are less than a specific lint level to "informal", meaning they don't break the CI check. Although I agree that this might be a very specific usecase and might not be generic enough to fit into your model.
I understand that you have more complex plans with lint levels, so I am open to what you suggest. I'm confused, to be honest, about all the different types of levels we are talking about now.

I apologize if I am too opinionated here. I'll take a step back and let you guys talk it out. Make of my pull requests what you want :)

The "compat level of the project" kind of confuses me, why would a project be of a specific compat level? Shouldn't it depend on the specific PR, and which version the project wants to publish next?

I'm meaning "the current state of the project" or "what compat level someone is interested in"

I don't completely understand the "reporting level of a lint". Is this at what level to report, but without making the check fail?

rustc lints can be allow, warn, deny, and forbid.  This is a separate axis from the compat level. You might have compat checks that you only want to to warn and not deny as whether they require a version bump requires enough context that the caller should decide.  For example, I would ant -Ddeprecation but -Wadd for clap as I require all deprecations to be in a minor release but I don't strictly enforce that new API items require a minor release.

Maybe the discussion shouldn't be about the lints in the first place? You have a feature that detects what kind of release we're going to make next (patch, minor, major) by looking at the toml, and the flag overrides what release type that logic detects.
The release type affects which lints trigger and which don't, but fundamentally what I wanted to override is the release type detection.

The release type affects which lints trigger and which don't, but fundamentally what I wanted to override is the release type detection.

OK by now I think I completely misunderstood what the goals were :D so my first PR was what we needed, except that the name confused everyone?

This is a tricky issue. Thank you @Finomnis and @Darksonn for thinking through it with @epage and me — I think our solution will be that much better for it.
I want to summarize my understanding so far, make a concrete proposal to move us forward, and offer justification for it with my opinions.
To summarize, I believe there are three separate-but-interconnected things in play:

when a check should run (minor / major / always) — proposed term "compat level"
if it finds anything, what to do about it (deny / warn / etc.) — proposed term "reporting level"
what kind of version change the tool should believe it's look at, for the purpose of 1. — proposed term "version detection"

There's overlap between 1. and 2., in that setting a check to a hypothetical "patch" compat level (if one existed) would be equivalent to setting it to "allow" reporting level. This is why there's no "patch" compat level — it's redundant.
It's in principle possible to express 3. as just a more concise way to set a group of 1. and/or 2. settings. For example: --release-type major is equivalent to "set all minor lints to allow reporting level." If a "patch" compat level had existed, setting all minor lints to that would have been equivalent as well — as mentioned above.
(Aside: here's a plausible example of a compat-always, reporting-warn lint, which is not something we have today: "added a new exhaustive pub enum, are you sure you don't want to make it #[non_exhaustive]?")

My opinion: I think we want all three of these.
It's reasonable for a project to change the compat level: "for us, MSRV bumps are minor-deny", if the default had for example been set to "major-allow". (Setting completely aside whether this is a good default or not.)
It's also reasonable for a project to change the reporting level: "API additions are minor-deny" changing from a presumed default of "minor-allow".
It's also reasonable for either a project or for a human using the CLI to want to set a group of settings more quickly than typing in a dozen individual overrides, even if there are lint groups that allow setting compat/reporting across a group like -Wadd. While the tokio use case would use this flag in CI, I think it's very likely that a human at a keyboard would use this much more often. cargo has similar "convenience CLI flags," for example --all-features and --exclude which are both technically just re-expressions of what the other flags can do.

My proposal:

--release-type patch/minor/major for version detection, purely as an convenience CLI flag
-W/-A/-D/-F + their corresponding long forms for reporting levels — the same as rustc/clippy
TBD flags for compat level (punt to #58)

In terms of merging into cargo:

The reporting level flags are a clear fit.
The version detection is "syntax sugar" so regardless of whether cargo adopts it or goes for something different, it won't be a loss of functionality in the merge — in the absolute worst case it would be a loss of convenience.

Thoughts?

@obi1kenobi one nit pick on my side:

what kind of version change the tool should believe it's look at, for the purpose of 1. — proposed term "version detection"

For me, I feel like the "version detection" framing focuses on the wrong part, on the mechanism for how we get the default value (that we are now wanting to explicitly set) rather than how its used.
With that said, my earlier comment stands that I am mostly fine with us merging whatever to collect real-world feedback and marking this as an open question for the cargo merge.  I appreciate that we've talked this through and I think its productive all around for understanding use cases, designs, etc but as we still have the power to change things, we should time-box the conversation and move on.

For me, I feel like the "version detection" framing focuses on the wrong part, on the mechanism for how we get the default value (that we are now wanting to explicitly set) rather than how its used.

I understand. Perhaps we can find a better name for it.
In my head it continues to be just a shorthand for setting a bunch of compat and reporting levels at once, with explicit overrides of either of those dominating. The underlying implementation isn't that important to me.
Let's move forward! I'll merge the --release-type PR.

I like --release-type. Makes sense to you as well, @Darksonn?

The name --release-type was my favorite from the beginning, so I'm happy.

Re-opened and updated #361. Review required :)

Awesome, merging! Thanks again for both the patience and the contributions!
Tentatively planning to release on Monday morning US/Eastern time, so afternoon in Europe.

Thanks everyone for the heated but fruitful discussion :)

Passionate collaborative problem-solving!


Add patternlab-build-pattern-end event

Closes #
Summary of changes:

Such pull request
very description
much approved
(also I just saw i was auto-subscribed to this repo)


How do I handle property transformations before/after storing?

Document D holds a complex object O, which should not get stored directly in the database, but only the identifier I (which is a property of object O) of object O should get stored in the database.
How would I transform the identifier I to object O when reading from the database, and transform object O to it's identifier I when storing the document D?
Also, how would this work with the auto-update feature? In the best case I just want to assign the object O and have only it's identifier I persisted,
const document = {
  object: new ComplexObject('unique-identifier-123')
};

collection.insert(document); // Does not store the ComplexObject object, but only it's identifier.

Is there a simple way to make LokiJS transform the property on insert/update/find, etc.?
Thanks a lot!

This is not a specific use case lokijs is designed to make simple, but there are features in lokijs and native javascript that you might be able to employ to accomplish what you are looking to do.
I guess you would need to decide if you want the 'in-memory' representation storing full object with persisted storing only identifier.... or both representations storing identifier.
Collections emit a 'pre-insert' event which you could write a handler for to fix-up your object into an identifier if you want the 'in-memory' representation (as well as persisted representation) to use the identifier.
Attaching a 'toJson' method at any level within your object should also allow you to control how the object will be serialized if you don't mind the 'in-memory' representation containing full object.
You can also utilize collection 'proto' options to define a custom javascript class to inflate from (which incidentally may also contain a toJson method, thus closing the deflate/inflate rountrip).  Collection proto's are slightly less documented but are rather easy and you can probably figure out its usage by looking at our unit tests here.


Motion sensor not always turn off

Description
When I turn on my camera, the binary_sensor for motion does not always go off.
When the camera is switched on and detects movement, it is also not always the case that the sensor goes off again when there is no movement.
Reproduction Steps
none
Expected behavior
The sensor must go off when there is no more movement.
It would be nice if it goes off when the camera is switched on or you can turn it off via an automation
If applicable, add error logs.
No response
Device Firmware
1.3.5
Using stream component
Yes
Does camera work via official integrations?
No
Camera has all attributes filled out in developer tools
Yes
HASS Environment
rasberry pi 4
Search for similar issues
Yes
Additional information
dont know if i use
Using stream component
it does not have an official integration

Verify through official Onvif integration. If it works there and not here we can reopen this. This integration uses the functionality of official Onvif integration.

it works through Onvif integration

Please provide a screenshot where it is visible that the motion sensor went to off state in onvif integration and did not in this integration at the same time. This integration reuses most of the code inside onvif so I am not sure how that could happen.
Cameras are also buggy with onvif reporting, so I am making sure there is an actual bug before we reopen.

This screenshot shows that the tapo integration also does not always register that there is movement, which onvif did

What camera is experiencing this issue?

these two screenshots were taken very few seconds apart, so it clearly shows that the tapo integration has not detected movement at  14.36.08 just like onvif did.  if not, you must tell where you want the screenshot from.  but the two I have sent here are taken directly from the history of home assistant.

Are you using HTTPS to access ha / do you have webhooks enabled?

i have nabu casa, so yes i think i use https, but not local in my home
dont know what webjooks is, so i would say i not use them :-)

Webhooks are explained in FAQ. Please check the configuration to see if the option is turned on or off. Also enable debug logs and post the full log please that will tell me what I need to know about webhooks.

Dont know what is happende, but now it works perfekt again. sorry for this post :-)


fix: whitespace before punctuation

div >:deep(h3) {
    color: orange;
}

error render:
div.test .test>h3{color: orange;}

should be:
div.test>h3{color: orange;}

is this problem happening when we use style_sheet! macro? because for me this is working in styel! macro in style_sheet! case IDE auto eliminates this space.

ok


Loop "tod project remove"

When running "tod project remove", I have to repeat for each one I want to remove.
If I want to remove a single one, I can already do so by running "tod project remove -p " (or --project)
So when running "tod project remove" I would like the workflow to loop (then the first option can be "exit" or similar to close)

Does tod project remove --auto cover your use case @stacksjb ?
I assume that you are clearing out projects that are not longer in use on Todoist?

In my case, I am not, though --auto is helpful.

Add --loop flag to tod project remove

Loop is a protected word, using repeat instead in #709

Ran into this recently, took awhile to find the syntax - noting so I can add to docs


Add OME sample data to tests, and mark with xfail for now

This PR adds all of the sample xml files from https://github.com/ome/ome-model/tree/master/specification/samples/2016-06 to the testing suite, and explicitly marks the files that are not known to pass with pytest.mark.xfail.  As such, you can now run pytest and it will build the model, and test all of the samples, and if you fix a problem the test will actually fail with:
[XPASS(strict)] Unexpected success. You fixed it!
Then, add the name of the file(s) that your changes have fixed to the SHOULD_PASS set in test_autogen.py.  Currently this only includes:
SHOULD_PASS = {"example.ome", "small.ome"}
SHOULD_RAISE = {"bad.ome"}  # this xml is actually invalid and should raise validation error.

Codecov Report

Merging #10 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
+ Coverage   95.37%   95.40%   +0.03%
==========================================
  Files           1        1
  Lines         389      392       +3
==========================================
+ Hits          371      374       +3
  Misses         18       18

Impacted Files
Coverage Δ

src/ome_autogen.py
95.40% <100.00%> (+0.03%)
:arrow_up:

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 0c0c2fd...6e36135. Read the comment docs.

@jmuhlich, this should help iterate quicker locally on #9


[ 🚧 WIP ] Add convert binary to decimal javascript

Why:
Closes #1949
What's being changed:
Add a function in Javascript that converts a number from binary to decimal

@Jordan6794
Please link language-specific issue.
Thank you!

@victoriacheng15 Yes sorry my commits for the typescript issue got added as well.
How can I remove them and only have my Javascript commit ? Should I just make a new branch and a new pull request ?

@victoriacheng15 Yes sorry my commits for the typescript issue got added as well.
How can I remove them and only have my Javascript commit ? Should I just make a new branch and a new pull request ?

Look at revert command


Can I use special paths like HOME when specifying the path of a script?

Can I use special paths like HOME when specifying the path of a script?

All depends on the flags you pass to your shell. You can also manually source the shell config file.

In the GUI or the command line tool?

No, this is not currently possible.


App crashes everytime when trying to display lottie animation

Hi,
I am facing a strange issue. My application crashes everytime when I try to display lottie animation. It works fine on iOS but on Android it fails. I've had some troubles before I could even compile it correctly because I was using compilesdk 23 and it turns out it has to be at least 24. Idk if it applies to buld tools or support library (I've testes with compilesdk 24, build tools 24.0.1 and support library also 24 - still no luck).
When I try to display lottie my app force crashes. Below is the stack trace when it does. It looks like a problem with null reference to Json file, but I've tried with local json (via require) wchich works fine on iOS and also with remote source { uri: 'http://blahblahblah'}.  I've tested it also with my custom animation and those from examples - still crashes.
My sample .json file is available on example.json (works fine on iOS)
Any ideas?
Fatal Exception: java.lang.RuntimeException: An error occured while executing doInBackground()
       at android.os.AsyncTask$3.done(AsyncTask.java:304)
       at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355)
       at java.util.concurrent.FutureTask.setException(FutureTask.java:222)
       at java.util.concurrent.FutureTask.run(FutureTask.java:242)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
       at java.lang.Thread.run(Thread.java:818)
Caused by java.lang.NullPointerException: Attempt to invoke virtual method 'int org.json.JSONArray.length()' on a null object reference
       at com.airbnb.lottie.LottieComposition$Factory.parseLayers(LottieComposition.java:200)
       at com.airbnb.lottie.LottieComposition$Factory.fromJsonSync(LottieComposition.java:194)
       at com.airbnb.lottie.JsonCompositionLoader.doInBackground(JsonCompositionLoader.java:17)
       at com.airbnb.lottie.JsonCompositionLoader.doInBackground(JsonCompositionLoader.java:7)
       at android.os.AsyncTask$2.call(AsyncTask.java:292)
       at java.util.concurrent.FutureTask.run(FutureTask.java:237)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
       at java.lang.Thread.run(Thread.java:818)

uh... um well...
It was totally all my fault. I've misunderstood whole thing and i've installed both lottie for android/ios and then lottie-react-native (as it supposed to be only the wrapper). This was cause of my problems. When I reverted changes and installed only lottie-react-native it started to work just fine :)


Simplify ICU package resolution not to require PkgConfig and to be more user configurable.

If you don't have PkgConfig, you'll need to pass the following to CMake:
 -DICU_UC_INCLUDE_DIRS="%swift_source_dir%/icu/include"^
 -DICU_UC_LIBRARY_DIRS="%swift_source_dir%/icu/lib64"^
 -DICU_I18N_INCLUDE_DIRS="%swift_source_dir%/icu/include"^
 -DICU_I18N_LIBRARY_DIRS="%swift_source_dir%/icu/lib64"^
 -DICU_UC_LIB_NAME="icuuc"^
 -DICU_I18N_LIB_NAME="icuin"

I moved the find_package logic to CMakeLists.txt. This is because I get linker errors for no such ICU functions when linking on Windows, because a library needs ICU, but ICU has not been resolved yet until stdlib/public/core/CMakeLists.txt
Extracted from #5904

@swift-ci please test

CC: @llvm-beanz

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 1ea9850a7178319e76397eb37cdc9b0c179cf5b3
Test requested by - @compnerd

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 1ea9850a7178319e76397eb37cdc9b0c179cf5b3
Test requested by - @compnerd

@swift-ci please test

@swift-ci Please smoke test

@compnerd @erg Does this look good to merge?

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - c66b72c5fa4572824724dd377750f58ad4b611e7
Test requested by - @slavapestov

@slavapestov could you retrigger Swift Test OSX Platform, seems like it failed any tests failing!

@swift-ci please test OS X platform

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - c66b72c5fa4572824724dd377750f58ad4b611e7
Test requested by - @CodaFi

Hmm, im no expert at the cross-compilation stuff. I'm fairly sure the FreeBSD port that got merged yesterday solved a similar case.
Either we could merge this in then use the technique the FreeBSD port did in a future PR that's dedicated to making cross compilation work?

Also, not sure if I'm breaking the OSX tests or they just keep failing - it says 0 failures but something seems to be going wrong?

I think @aschwaighofer reverted the change that caused this (it's failing in some Playground Logger tests)
@swift-ci please test OS X platform.

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - c66b72c5fa4572824724dd377750f58ad4b611e7
Test requested by - @CodaFi

@CodaFi Unfortunately reverting that change did not fix the playground test failure, it looks like it was unrelated. The test has been disabled in master so I'm kicking off another PR test run.

Actually, the smoke test passed so we can just merge.


[Runtime][Logger] Added a LoggerInterface in order to decouplate Monolog...

... and Propel

What? No!
Please reread #23. We said that we didn't want to do that.
The introduction of a LoggerInterface forbids the use of a simple Monolog logger (think one already configured in a DIC outside of Propel).

@fzaninotto maybe better, at least for the future.

Oh that's right.. :(


Error when using DataTableRowActions component in a DataTable

I see the following in the console when the action dropdown is Clicked.
Warning: Failed prop type: Invalid prop `aria-disabled` of type `string` supplied to `SLDSListItem`, expected `boolean`.
    in SLDSListItem (created by SLDSList)
    in SLDSList (created by SLDSMenuDropdown)
    in div (created by SLDSDialog)
    in SLDSDialog (created by SLDSMenuDropdown)
    in div (created by SLDSMenuDropdownTrigger)
    in SLDSMenuDropdownTrigger (created by SLDSMenuDropdown)
    in SLDSMenuDropdown (created by OnClickOutside(SLDSMenuDropdown))
    in OnClickOutside(SLDSMenuDropdown) (created by SLDSDataTableRowActions)
    in td (created by SLDSDataTableRowActions)
    in SLDSDataTableRowActions (created by JobsTable)
    in tr (created by SLDSDataTableRow)
    in SLDSDataTableRow (created by SLDSDataTable)
    in tbody (created by SLDSDataTable)
    in table (created by SLDSDataTable)
    in SLDSDataTable (created by JobsTable)
    in SLDSIconSettings (created by JobsTable)
    in div (created by JobsTable)
    in JobsTable (created by JobsListView)
    in SLDSIconSettings (created by JobsListView)
    in div (created by JobsListView)
    in JobsListView (created by ZincJobs)
    in ZincJobs (created by UserIsAuthenticated(ZincJobs))
    in UserIsAuthenticated(ZincJobs) (created by Connect(UserIsAuthenticated(ZincJobs)))
    in Connect(UserIsAuthenticated(ZincJobs)) (created by withSaga(Connect(UserIsAuthenticated(ZincJobs))))
    in withSaga(Connect(UserIsAuthenticated(ZincJobs))) (created by withReducer(withSaga(Connect(UserIsAuthenticated(ZincJobs)))))
    in withReducer(withSaga(Connect(UserIsAuthenticated(ZincJobs)))) (created by Connect(withReducer(withSaga(Connect(UserIsAuthenticated(ZincJobs))))))
    in Connect(withReducer(withSaga(Connect(UserIsAuthenticated(ZincJobs))))) (created by Route)
    in Route (created by RouteWithLayout)
    in div (created by PageBase)
    in div (created by PageBase)
    in div (created by PageBase)
    in div (created by PageBase)
    in PageBase (created by RouteWithLayout)
    in CSSTransitionGroupChild (created by TransitionGroup)
    in span (created by TransitionGroup)
    in TransitionGroup (created by CSSTransitionGroup)
    in CSSTransitionGroup (created by Layout)
    in div (created by Layout)
    in div (created by Layout)
    in MuiThemeProvider (created by Layout)
    in Layout (created by WithWidth)
    in EventListener (created by WithWidth)
    in WithWidth (created by Route)
    in Route (created by withRouter(WithWidth))
    in withRouter(WithWidth) (created by Connect(withRouter(WithWidth)))
    in Connect(withRouter(WithWidth)) (created by RouteWithLayout)
    in RouteWithLayout (created by App)
    in Switch (created by App)
    in div (created by App)
    in Router (created by App)
    in App (created by Route)
    in Route (created by withRouter(App))
    in withRouter(App) (created by Connect(withRouter(App)))
    in Connect(withRouter(App))
    in Router (created by ConnectedRouter)
    in ConnectedRouter
    in Provider

I think this is the line to change to string. https://github.com/salesforce/design-system-react/blob/master/components/utilities/menu-list/item.jsx#L37
Re-open if you want to take it on.


Update Lerna to Remove Bootstrap Command

https://lerna.js.org/docs/concepts/alternate-bootstrapping-methods says that lerna boostrap is deprecated

This is seemingly not an immediate-term blocker as the automated builds are now fixed to the prior version that still uses bootstrap. However, this would be very helpful to have!


Support error and params

Telegram returns error Bad Request: group chat was upgraded to a supergroup chat with new chat id but bot cuts this info and I can't get a new chat id
{
    "ok": false,
    "error_code": 400,
    "description": "Bad Request: group chat was upgraded to a supergroup chat",
    "parameters": {
        "migrate_to_chat_id": -1001432162429
    }
}

I'm having the same issue too. I'm working on a pull request for a workaround.
@tucnak I think that the error checking function is fundamentally broken. The Go JSON parser can be used to detect whether the JSON contains an error or not

We can catch it similarly to the flood error like here: https://github.com/tucnak/telebot/commit/315d880be7eac113df384902ee6cfda3606146be. But it's getting too cumbersome to handle using regexes, so it'll be great to move to the JSON unmarshaling. PRs are welcome.

I wrote the #335 for this. However I think that the code needs some major refactoring in that section

#335 9805b1f622d8161ed5615d0738c8071066ed7dea


Modify rpm-ostree options for new parameter

rpm-ostree behavior has been modified, and implemented an assume yes param ie -y, implementing here as in later releases this will be required for invoking non interactive

Let's try this with the latest test coverage which we now have and see if it breaks anything.


Upgrade Scala minor version

Using this starter in Metals gives the warning

You are using legacy Scala version 2.13.3, which might not be supported in future versions of Metals. Please upgrade to Scala version 2.13.8.

Thank you!


Auto-switch default payment method to google pay when power menu is open

If you need to use multiple NFC apps where it automatically changes your "default payment method", as in the case of Card Emulator, switch the "default payment method" back to Google Pay when the power menu is opened so that the quick wallet can be used

Few things:

This should probably be an option, or check if the user's Quick Access Wallet is set to Google Wallet. I have no idea if any OEM made their own, but they may not be using Google Wallet as a result.
The user can disable the Quick Access Wallet, in which case this shouldn't be run when they open the power menu.
Please wrap the use of Settings.Secure.putString in a try/catch since there's a possibility either the permission granting in the root service may either fail, or the permission may have been revoked while the app is running. This is not a fatal error, so it shouldn't crash the app.

Once these are resolved, I'll merge this 👍

Alright, sounds good, will work these points

My ideas to fix these few things was to add an option in the Quick Access Wallet settings to if open set the default to an app the user can select from a list. I have tried to look into how to get this list of payment supported apps; however I can only manage to get the list of that use the HOST_APDU_SERVICE, and this includes both CATEGORY_PAYMENT and CATEGORY_OTHER. The only ones available for default payment method is CATEGORY_PAYMENT, but the function the android settings app uses is not available when I write the code. It uses getServices from CardEmulation, this function is defined but I can't use it!? Sadly I can't find a method to filter what services uses CATEGORY_PAYMENT and CATEGORY_OTHER. Currently I get the services with HOST_APDU_SERVICE
val intent = Intent("android.nfc.cardemulation.action.HOST_APDU_SERVICE").addCategory(Intent.CATEGORY_DEFAULT)
val resolveInfoList = packageManager!!.queryIntentServices(intent, PackageManager.MATCH_DEFAULT_ONLY)

Any tought on this, would it be ok to have a list with applications that may not work? There is very little information on this topic sadly..

Added these options, by default its turned off:

What icons should it have?
When you open the select service view: (if there is any matching services, selected one is highlighted, by default none is)

If there is not any matching services: (simulated by passing an empty list)

It says my phone has 4 services for this, two are for payment (Card Emulator and Google Pay), the other two is "CATEGORY_OTHER". I didn't find a way to sort these out sadly, but if you would select it and then run the command, the android settings default contactless payment looks like this:

All good except that included redundant class - once that's gone I'll merge it :)

Sorry, redundant class, what do you mean?

Merged, I'll run a build with the changes shortly

Perfect! Thank you for merging, will try to see if there is anything else I can work on, as I really like this project and want to develop more for android!

Included in 1.8, build took a while since the codebase is ancient and needed some serious refactoring to work with predictive back


UVR opencl link gives you error 404

The link to UVR OpenCL gives an error 404
https://github.com/Anjok07/ultimatevocalremovergui/releases/download/v5.6/UVR_v5.6.0_setup_opencl.exe

It looks like the file was renamed to:
https://github.com/Anjok07/ultimatevocalremovergui/releases/download/v5.6/UVR_v5.6.0_setup_directml_old.exe
It simply used DirectML from the beginning, and not OpenCL, and Anjok changed all the names in newer Roformer patches, and only renamed the old installation package name.


opt_merge: hashing performance and correctness

This is a direct remake of #4175 sans the 64-bit hash value. I'm making use of the interface in #4524 and requiring that PR (and containing its commits at the moment).
Additionally, I discovered opt_merge behaves incorrectly in the case of hash collisions. This suggests that this PR might in rare cases bring improvements in quality of results for flows that use opt_merge, since prior to it, hash collisions would inhibit merging. I modified the sharemap from a dict<hash_t, Cell*> to an equivalent std::unordered_multimap so that multiple cells can be associated with the same hash. This can't be a separate change since this bug actually broke the build just by changing how the hashes are constructed.
Sorry for the spam to code owners due to being based on the above mentioned wide-reaching PR #4524, I don't have a way of removing you from the reviewer list. The diff for this PR is not going to be very readable on github either until that's merged

The current implementation regresses opt_merge runtime many times over. I'll see if std::unordered_multimap.
Currently, std::unordered_multimap, as I use it

maps from hash_t to Cell*
hashes hash_t with std::hash (unnecessary)
compares Cell*s with pointer equality

Instead it should:

map from Cell* to Cell*
hash with hash_cell_function
compare with compare_cell_parameters_and_connections

pool fails to bring a clear advantage over std::unordered_set:
ibex pool
Elapsed time: 0:42.16[h:]min:sec. CPU time: user 41.87 sys 0.17 (99%). Peak memory: 164800KB.

ibex std::unordered_set
Elapsed time: 0:42.85[h:]min:sec. CPU time: user 42.56 sys 0.16 (99%). Peak memory: 164076KB.

ibex pool
Elapsed time: 0:49.41[h:]min:sec. CPU time: user 48.76 sys 0.49 (99%). Peak memory: 634672KB.

ibex std::unordered_set
Elapsed time: 0:47.62[h:]min:sec. CPU time: user 46.95 sys 0.51 (99%). Peak memory: 629852KB.

@widlarizer nice work!


Add isGlobal to pdf renderer configuration

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@044731c). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #25   +/-   ##
=======================================
  Coverage        ?   96.66%
=======================================
  Files           ?        2
  Lines           ?       30
  Branches        ?        5
=======================================
  Hits            ?       29
  Misses          ?        1
  Partials        ?        0

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 044731c...156dd0f. Read the comment docs.


Fix issues #168 (vasprun-hessian)

Codecov Report

Merging #169 (932605c) into develop (8b82734) will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@           Coverage Diff            @@
##           develop     #169   +/-   ##
========================================
  Coverage    47.92%   47.92%
========================================
  Files          111      111
  Lines        17441    17438    -3
========================================
- Hits          8359     8358    -1
+ Misses        9082     9080    -2

Impacted Files
Coverage Δ

phonopy/interface/vasp.py
53.51% <0.00%> (+0.06%)
:arrow_up:

phonopy/interface/turbomole.py
43.85% <0.00%> (-0.88%)
:arrow_down:

phonopy/interface/elk.py
0.00% <0.00%> (ø)

phonopy/interface/fleur.py
0.00% <0.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 8b82734...932605c. Read the comment docs.


Git: Support an ignored repository list setting

Issue Type: Bug
I keep all my dotfiles and settings in a repo, and my settings.json is symlinked into that repo. Whenever I open Preferences > Settings, my repo is added to the source control sidebar.
Steps to reproduce on Mac:

Quit VSCode
mv "$HOME/Library/Application Support/Code/User" "$HOME/mysyncedusersettings"
cd mysyncedusersettings; git init
ln -ns "../../../mysyncedusersettings" "$HOME/Library/Application Support/Code/User"
Open VSCode. The app can be in any state (a project may or may not be open).
Cmd-,

The settings UI opens -- I would expect opening my settings panel to do only that. What actually happens is that in mysyncedusersettings gets added to the source code panel in the sidebar. Sometimes it doesn't appear immediately, but it will always appear after a window reload.
I understand that this can be desirable behavior (and it sometimes is for me actually), but I feel like there should be an option to turn it off, or to open Preferences in a new window so that it doesn't affect the state of the existing window's Git sidebar.
VS Code version: Code 1.21.1 (79b44aa704ce542d8ca4a3cc44cfca566e7720f1, 2018-03-14T14:39:09.335Z)
OS version: Darwin x64 17.4.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (8 x 2800)

Load (avg)
3, 3, 4

Memory (System)
16.00GB (2.07GB free)

Process Argv
/Applications/Visual Studio Code.app/Contents/MacOS/Electron -psn_0_50491428

Screen Reader
no

VM
0%

Extensions: none
Reproduces without extensions

Maybe we need an ignored repositories list setting?

That sounds like a good option to me that can be extensible for other use cases as well.
Also, since there is already a way to manually remove repos from the source control tab (Right click -> "Close repo"), it would be great if there could be:

an option to turn off the auto-populating of repos altogether
an option to manually add repos, or to specify which repos to open in the workspace settings.

Hi! I'm new to the code and would like to give this a shot, assuming no one is currently working on it?
If I'm understanding the requirements correctly, you would like for there to be:

a setting in the Git section of Default Settings containing a list of repositories to ignore
an option in User Settings to prevent the application from automatically populating the Source Control tab with repos
an option in the Source Control tab to manually add new repos
an option in Workspace Settings containing a list of repos to open.

Is my understanding of this correct? Also, if you could please give some pointers so I know where to start, that would be a big help! Thanks in advance!

A potential alternate solution to my original problem that a bit extensible is to prevent "guest" files (files outside the root directory in the Explorer pane) from adding any VCS paths to the list.
I think we still might want to an option to prevent adding certain repos as VCS paths, but the use case might be more for workspace-specific settings.


Segmentation Fault in amd64 executables

In the Linuxulator I see:
[nico@triton ~/src/bm]$ uname -ap
FreeBSD triton.herrhotzenplotz.geek 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #2 main-c111-g6eebda3bb: Thu Jan 14 21:17:40 CET 2021     nico@triton.herrhotzenplotz.geek:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64 amd64
[nico@triton ~/src/bm]$
[nico@triton ~/src/bm]$ ./build-x86_64.sh
...
[nico@triton ~/src/bm]$ brandelf -t Linux ./build/examples/fib.exe
[nico@triton ~/src/bm]$ ./build/examples/fib.exe
[5] + Segmentation fault - core dumped ./build/examples/fib.exe
[nico@triton ~/src/bm]$ file ./build/examples/fib.exe
./build/examples/fib.exe: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, with debug_info, not stripped
[nico@triton ~/src/bm]$ gdb ./build/examples/fib.exe fib.exe.core
Reading symbols from ./build/examples/fib.exe...

warning: core file may not match specified executable file.
[New LWP 100639]
Core was generated by `./build/examples/fib.exe'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000020177c in inst_49 ()
(gdb) where
#0  0x000000000020177c in inst_49 ()
#1  0x0000000000000001 in ?? ()
#2  0x00007fffffffd7d0 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) x/i $pc
=> 0x20177c <inst_49+8>:    movq   $0xa,(%rsi)
(gdb) p/x $rsi
$1 = 0x2a2000
(gdb)

Same applies to 123i.exe.
No idea whether that is expected or not. If you need the corefile or the gdb trace of 123i.exe for debugging purposes, please let me know :-)

@herrhotzenplotz sorry for bothering you in such an old issue. This was due to not all instructions being implemented. Recently we got all of the implemented #344 and I was wondering is this still an issue?

This was due to not all instructions being implemented. Recently we
got all of them implemented #344 and I was wondering is this still
an issue?

I've tested this against a few test cases and cannot observe any
segmentation faults anymore.
However, none of the examples print anything to stdout/stderr. I will
dig into this a bit when I have a bit time for it, although I can
already feel, that it's just a matter of the syscall ID's being
assumed to be Linux.
See: https://paste.debian.net/plainh/bf52509e
Maybe this is worth another issue?

Quick note, yes, that is indeed the issue:
[nico@hades ~/src/bm]$  brandelf -t Linux /tmp/hello
[nico@hades ~/src/bm]$ /tmp/hello
Hello, World
Hello, World
Hello, World
Hello, World
Hello, World
[nico@hades ~/src/bm]$

@herrhotzenplotz Thank you so much for checking it out!
I don't think it makes sense to create a separate issue for that, but PRs that add support for a new code generation target are welcome.
I renamed the target nasm to nasm-linux-x86-64 #367 to emphasize that it only works on Linux x86-64. Any PRs that add nasm-freebsd-x86-64 target are welcome ;)


add rate-limiting and knobs for info and dbg traces in the kernel driver

resolve #1

should you use printk_ratelimited instead of printk_ratelimit?


Docs: Updated callbacks/index.mdx

The callbacks get started demo code was updated , replacing the chain.run()  command ( which is now depricated) ,with the updated chain.invoke() command.
Solving the following issue : #16379
Twitter/X : @Hazxhx

Thank you @HazSyl1


transaction output now includes some additional log data

We're still missing the following columns:
        "args.operator": "operator",# missing
        "args.from": "from", # missing
        "args.to": "to", # missing
        "args.id": "id", # missing
        "args.value": "value", # missing
        "prefix": "prefix", # missing

And you'll notice that the new code does not replicate all of the functions of the old code (which did not run).

Codecov Report
Patch and project coverage have no change.

Comparison is base (183f293) 75.24% compared to head (52e4b5d) 75.24%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #540   +/-   ##
=======================================
  Coverage   75.24%   75.24%
=======================================
  Files          55       55
  Lines        3353     3353
=======================================
  Hits         2523     2523
  Misses        830      830

Flag
Coverage Δ

unittests
75.24% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Schema Evaluation fails with "Cannot resolve schema at {uri}"

Nuget Package
JsonSchema.Net
Package Version
4.1.5
How can I help?  Please provide as much context as possible.
Given the following OpenApiDocument,
openapi: 3.0.0
info:
  title: Sample API
  description: Lorem Ipsum
  version: 1.0.0
servers:
  - url: http://api.example.com/v1
    description: Lorem Ipsum
paths:
  /issues:
    get:
      summary: Returns a list of issues.
      description: Lorem Ipsum
      responses:
        "200":
          description: Lorem Ipsum
          content:
            application/json:
              schema:
                type: object
                required:
                  - data
                properties:
                  data:
                    type: array
                    items:
                      $ref: "#/components/schemas/issueData"
              example:
                data:
                  - issuedAt: "2023-10-12"
components:
  schemas:
    issueData:
      type: object
      title: Issue Data
      description: Information about the issue.
      properties:
        issuedAt:
          type: string
          format: date
          description: Lorem Ipsum
          example: "2023-10-12"

I'm trying to evaluate the example object here:
example:
  data:
    - issuedAt: "2023-10-12"

Against the schema within the application/json content-type by calling schema.Evaluate(example).
However, evaluation fails with the following error:
Json.Schema.JsonSchemaException: 'Cannot resolve schema `https://json-everything.net/bd1ea2d485#/components/schemas/issueData`'

Examining the stack trace says the exception is originally thrown by the RefKeyword's Evaluate() method
at Json.Schema.RefKeyword.Evaluate(EvaluationContext context)
   at Json.Schema.EvaluationContext.Evaluate()
   at Json.Schema.ItemsKeyword.Evaluate(EvaluationContext context)
   at Json.Schema.EvaluationContext.Evaluate()
   at Json.Schema.PropertiesKeyword.Evaluate(EvaluationContext context)
   at Json.Schema.EvaluationContext.Evaluate()
   at Json.Schema.JsonSchema.Evaluate(JsonNode root, EvaluationOptions options)

When I inspect the codebase, I see the error is thrown on this line https://github.com/gregsdennis/json-everything/blob/7d516fb3307a4fc90179b7a8a2575797bb509f17/JsonSchema/RefKeyword.cs#L90-L91
which I assume is as a result of this https://github.com/gregsdennis/json-everything/blob/7d516fb3307a4fc90179b7a8a2575797bb509f17/JsonSchema/RefKeyword.cs#L76
I've tried registering the schema in the components section with the local schema registry and passing it through the Evaluation options object but it isn't working either.
I've also made sure that the baseUri's for the items schema and that of the registered schema are the same.
Why isn't the embedded items $ref being resolved? What could I be doing wrong?
Code of Conduct

[X] I agree to follow this project's Code of Conduct

I can only speculate here as you didn't show how your code is using the schema to evaluate instances. I assume your code extracts/isolates the schema from the OpenApiDocument either without extracting the schema components like "issueData" or your extraction attempt of the "issueData" (sub-)schema somehow leaves it at a (relative) path different from the original
"#/components/schemas/issueData" path. Hard to tell without knowing how you precisely process the OpenApiDocument, though...
(As a side note, JsonSchema.NET is already at version 6.1.2)

For what it's worth, here is an illustrative example code, modifying the schema by adding the component schemas to it. This is done because the schema reference in your example schema has an #, which indicates an embedded schema, so by making the "components" object a part of the schema object the path of the reference will resolve successfully.
var yaml = new YamlStream();
yaml.Load(... the OpenApiDocument as shown in your report ...);

var joSchema = (JsonObject) joOpenAPIDoc["paths"]["/issues"]["get"]["responses"]["200"]["content"]["application/json"]["schema"];
var joComponentSchemas = (JsonObject)joOpenAPIDoc["components"];
joOpenAPIDoc.Remove("components");
joSchema.Add("components", joComponentSchemas);

var schema = joSchema.Deserialize<JsonSchema>();
var result = schema.Evaluate(... the example instance ...);

(Note that the example instance you have given will not validate successfully, because it is a root object with only an "example" property. However, your schema attempts to validate a root object with a mandatory "data" property.)

How exactly is your code utilizing the schema(s) inside the OpenApiDocument?
(As a side note, JsonSchema.NET is already at version 6.1.2)

We're simply loading up the document in memory, then performing validation using a set of rules for every component within the document here https://github.com/microsoft/OpenAPI.NET/blob/f069dc154ab2c6c0c7e89cc6587f2f61b356d846/src/Microsoft.OpenApi/Reader/OpenApiJsonReader.cs#L108
When it gets to the media type object and finds an example node, it tries to validate it against the schema to see if the data type matches here: https://github.com/microsoft/OpenAPI.NET/blob/e76101a582b59d94a98f6103fe05c3d908ef79ef/src/Microsoft.OpenApi/Validations/Rules/OpenApiMediaTypeRules.cs#L35
https://github.com/microsoft/OpenAPI.NET/blob/e76101a582b59d94a98f6103fe05c3d908ef79ef/src/Microsoft.OpenApi/Validations/Rules/RuleHelpers.cs#L68

For what it's worth, here is an illustrative example code, modifying the schema by adding the component schemas to it. This is done because the schema reference in your example schema has an #, which indicates an embedded schema, so by making the "components" object a part of the schema object the path of the reference will resolve successfully.
var yaml = new YamlStream();
yaml.Load(... the OpenApiDocument as shown in your report ...);
var joOpenAPIDoc = (JsonObject) yaml.ToJsonNode().First();

var joSchema = (JsonObject) joOpenAPIDoc["paths"]["/issues"]["get"]["responses"]["200"]["content"]["application/json"]["schema"];
var joComponentSchemas = (JsonObject)joOpenAPIDoc["components"];

joSchema.Add("components", joComponentSchemas.DeepClone());

var schema = joSchema.Deserialize<JsonSchema>();
var result = schema.Evaluate(... the example instance ...);

(Note that the example instance you have given will not validate successfully, because it is a root object with only an "example" property. However, your schema attempts to validate a root object with a mandatory "data" property.)

Does this mean I should try dereference the schema first before performing evaluation?
I see you're replacing the embedded $ref with the component schema here before calling schema.Evaluate()?

@MaggieKimani1 you need to register the entire OpenAPI document under a URI identifier.  Then, when you create a new schema, set its .BaseUri to the same identifier.
See this test:
https://github.com/gregsdennis/json-everything/blob/d30e70760fd5797e6d831a4b950bdadf6071904f/JsonSchema.Tests/BaseDocumentTests.cs#L163-L207
This is why I suggested to you that you need to make your OpenAPIDocument type implement IBaseDocument.  I created IBaseDocument explicitly to support this use case.  You can see it working in my Graeae project.
What I recommend:

Make OpenApiDocument implement IBaseDocument.
When you initialize OpenApiDocument scan for schemas and set their .BaseUris.
Register the OpenApiDocument with the schema registry.  (You can use either the global registry or the one in EvaluationOptions.  If you use the options one, you'll need to always use those options or remember to re-register the schema with the new options.)

Then you should be able to grab any nested schema and validate with it.


Random seed in tf.keras.initializers.RandomNormal does not work in Tensorflow 2.7.0

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): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Google Colab
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N/A
TensorFlow installed from (source or binary):
TensorFlow version (use command below): 2.7.0
Python version: 3.7.12
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A

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
Setting the seed in tf.keras.initializers.RandomNormal(seed = [some integer]) does not guarantee that the same sequence is generated when constructed with the same seed value.
Describe the expected behavior
Setting the seed in tf.keras.initializers.RandomNormal(seed = [some integer]) should guarantee that the same sequence is generated when two initializers are constructed with the same seed value.
Contributing

Do you want to contribute a PR? (yes/no): no
Briefly describe your candidate solution(if contributing): n/a

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.
Using tensorflow version 2.7.0:
https://colab.research.google.com/drive/1paNe8kBRzwkrZHBi7QF0yhEX8pXO0f1w?usp=sharing
However, using tensorflow 2.6.0, this issue does not occur (note one has to restart the notebook after the pip install in the first cell before running the second cell):
https://colab.research.google.com/drive/10KrXpJtxiaAmnI2vKa61hDNheqjiJyu9?usp=sharing
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.

Hi @lubin-liu! As this document suggests ,They are meant to give random weight values to input layer. So This is working as expected. Attaching Gist for reference.

Ok @lubin-liu ! Thanks for reporting this bug .
Please post this issue on keras-team/keras repo too.
To know more see;
https://discuss.tensorflow.org/t/keras-project-moved-to-new-repository-in-https-github-com-keras-team-keras/1999 . Thanks!

Thanks! I have done so here:
https://github.com/keras-team/keras/issues/15755

Ok @lubin-liu ! Please close this issue here as it will be tracked in #15755. Thanks!


This doesn't work anymore, right?

Using Skype Versión <IP_ADDRESS>

You're right, it looks like it doesn't work any more.
I don't like the direction that Skype have taken their product in, so I'm no longer an active user. I'm not even sure it's possible to copy+paste "quotes" in the new versions.

Yeah. You can't even do that.. I just try to format the  text to look like  that with " ``` "


[Follow-up #16223] Switch to scoped enum

@xedin
https://github.com/apple/swift/pull/16223

@AnthonyLatsis Since we have already merged original changes can you please create a PR only with the last [gardening] commit for enum?

If only we could change the source branch of the PR...


Add support for environment variables

Expanded docker-start.sh with support for environment variables.
Available variables:

STAYTUS_THEME
STAYTUS_DEMO
STAYTUS_SMTP_ENABLED
STAYTUS_SMTP_HOSTNAME
STAYTUS_SMTP_USERNAME
STAYTUS_SMTP_PASSWORD

@adamcooke is this project still active?

Ping @adamcooke


Question about real training data

Hi Jonas,
Thank you for your awesome work on this project and for making the code and training data available!
I had a question regarding the real train dataset - as a sanity check, I've been visually ensuring that the virtual 3D bounding boxes align well with the drill object. From your paper, I gathered that you used ICP for estimation of the ground truth drill pose. I would expect that this could introduce some error in the ground truth pose relative to the "actual" drill pose and wanted to ensure that the error that I'm experiencing is similar to what's expected. I've included a few sample images below with their respective bounding boxes drawn, do you think that the accuracy of ground truth placement looks reasonable in these examples?
Good alignment

Poor alignment - looks like mostly rotational error introduced, more visible at instrument tip

Sample from the virtual dataset

Thanks for your help!

Hi Mitchell,
yes, there are some errors in the ground truth for some of the real samples. Besides the errors that could have been introduced by ICP (as you expected), another problem was the Kinects' unstable detection of the drill surface (e.g. due to reflections). This problem can be mitigated by using more cameras in the recording setup, however we only had two Kinects available at the time.
As a result, parts of the drill were missing in the reconstructed point cloud for some frames, which also degraded the pose computed via ICP. We considered removing these inaccurate samples from the dataset, but in the end decided against this step as it would further reduce its size.

Awesome! Thanks for clearing that up, Jonas.


Update dependencies

Tested these changes with v1beta tag in https://github.com/elisa-content-delivery/viihde-cdn-inspector/pull/845


Animation to fade in and fade out for terra components.

Feature Request
Description

I'm currently working on displaying terra-alerts for a user and was wondering if there is a possible way to add animation to fade in and fade out for the alerts.

Additional Context / Screenshots

@ Mentions

@jeremyfuksa

Terra currently does not employ transitions or animations except for some reserved cases like loading icons, primarily for two reasons:
(1) because a large percentage of our software runs behind instances of Citrix and other similar virtualization software, with configuration settings that keeps visual resources limited and low, effectively killing a suitable animation-frame-rates and noticeable transitions
(2) usually, when one ui element has an animation in/out, there are implied secondary byproducts of that animation. One example is delaying the execution of any action/onclick until after the animation has completed (otherwise the UI may repaint and you don't end up seeing the "out" animation). A second example is additional chained UI animations, using your banner as an example - before and after it animates in/out -- since the page content also will reflow (down when banners are added in, up when banners are removed), most likely a transition for the page content to fluidly fade/slide up/down would also need to be added (which could potentially trigger then another chained animated effect). Keeping track of all these animation frame and execution of the event loop becomes challenging, something that we'd like to grow into as Terra matures.

Closing as a enhancement to be explored again in the future, but not at the current time.


Use XdebugHandler to avoid perormance penalty

closes https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/3286

Hi, thanks for PR @AJenbo , I'm happy we could finally use this package and you decided to help!
Please, could you change target branch for 2.2 LTS ?

Opened a new PR for 2.2 here https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/3590


Using pose: pose_free: false

I did not get good results when I use "pose_free: false".
was the model trained on this case?

Thank you for the reply.
I meant whether the pretained model was trained or not in this case.
For example, if I run this command. The PSNR is around 16 while pose_free=tree case shows 24-25.
python -m src.main +experiment=re10k mode=test wandb.name=re10k<EMAIL_ADDRESS>dataset.re10k.view_sampler.index_path=assets/evaluation_index_re10k.json checkpointing.load=./checkpoints/re10k.ckpt test.save_image=true model.encoder.pose_free=false
All Pairs:
Method      psnr    lpips    ssim
--------  ------  -------  ------
ours      15.954     0.48   0.428
Overlap: medium
Method      psnr    lpips    ssim
--------  ------  -------  ------
ours      15.954     0.48   0.428

The pretained models are not trained for this case, you should set pose_free=true

thanks!