realtime

Just info regarding websocket so it's gathered somewhere.


Avoid duplicate entry when fzf-ing shell history

Category

[X] fzf binary
[ ] fzf-tmux script
[ ] Key bindings
[ ] Completion
[ ] Vim
[ ] Neovim
[ ] Etc.

Shell

[ ] bash
[X] zsh
[ ] fish

I would like to know if it's possible to limit the duplication in fzf specially in the shell history command? Or maybe I'm do it it wrong?

Hi, this is one of the recurring questions. Please see #49, #88, #492. Thanks.

Thanks @junegunn and sorry for the duplicate

For other people encoutering this issue, here is the changes I've made to remove duplicates :
__fzf_history__() {
  local line
  countskip="$(history | tail -n 1 | grep -E '^[0-9]+' -o | wc -c)"
  countskip="$(( countskip + 1 ))"
  echo "$countskip"
  line=$(
    HISTTIMEFORMAT= history |
    grep '.\{1,79\}' |
    sed 's/ *$//g' |
    tac |
    nauniq --skip-chars="$countskip" |
    tac |
    $(__fzfcmd) +s --tac +m -n2..,.. --tiebreak=index --toggle-sort=ctrl-r |
    \grep '^ *[0-9]') && sed 's/ *\([0-9]*\)\** .*/!\1/' <<< "$line"
}```

It requires nanuniq https://metacpan.org/pod/distribution/App-nauniq/bin/nauniq

perl -ne 'print if $seen{$_}++' should do.

perl -ne 'print if !$seen{$_}++' should do.

There are rare, desperate, cases, where I appreciate to browse through the history, in order to reconstruct something.
On ZSH one might use HIST_FIND_NO_DUPS to suppress duplicates in the search.  I'd appreciate comments and pull requests.


TS samples

Hello, John. I'm trying to find .TS samples with CC data, but I can't find any. Do you know where I can find one, or could you provide one?
Best regards,
Fernickk

Can't help you there. I'm sorry.

It's OK, thank you for your time ^_^.


Error highlighting not working when using termguicolors

Issue
Whenever ctermguicolor is set, garbage characteres appears around the error instead of the correct highlighting.
Steps to reproduce
To reproduce the problem consider the following vimrc content:
call plug#begin('~/.local/share/nvim/plugged')
Plug 'neomake/neomake'
call plug#end()

set termguicolors

and the following main.c file:
// asdfasdfasdf
int main(int argc, char *argv[])
{
  for (i = 0; i < j; ++i) {
    adf
  }
  return 0;
}

When openning the above code and running :Neomake the location list reports mainly 2 warnings and 3 errors:

Warning: unused parameter 'argc' [-Wunused-parameter]
Warning: unused parameter 'argv' [-Wunused-parameter]
Error: use of undeclared identifier 'i'
Error: use of undeclared identifier 'j'
Error: use of undeclared identifier 'adf'

Observed behavior
Garbage character 3m appears and the screen becomes buggy as seen bellow:

Expected behavior
The warnings and errors sources should be highlighted the same way it can be achieved when entering :set notermguicolors

System info
zsh 5.7.1
tmux 2.9a
NVIM v0.4.2 with python enabled
TERM = tmux-256color
Notes
The described issue is reproducible no matter the colorscheme used and no matter the source code language. So it's clearly not a colorscheme related bug nor a language specific problem.
This issue may be related to https://github.com/neomake/neomake/issues/2395

Playing around I realized it's actually a TERM problem. Changing it from tmux-256color to xterm-256color fixes the problem in exchanging of not having strikethought anymore (and hopefully doesn't break anything else in my terminal)


Create and Update the Implemented Tests Document ID5

A document specifying Implemented tests needs to be created AND updated for ID3.
This is just a document stating the tests that have been implemented explicitly, where to find them, and a simple description of what it tests.

Repurposed for ID5 because it was never closed


Allow tracking of https requests to storage account as ApplicationInsights dependencies

Package Name: @azure/storage-blob
Package Version: 12.4.0
Operating system: Windows
[x] nodejs

version: 14.15

[x] typescript

version: 4.13

Describe the bug
It seems that leveraging BlobClient doesn't (by default) allow interception of underlying https calls through the https://github.com/microsoft/applicationInsights-node.js library.
To Reproduce
Steps to reproduce the behavior:
Following piece of code demonstrates the issue. It makes 3 external https calls and logs to the console the intercepted dependencies

One to github (Leveraging node-fetch (same library azure-sdk-for js relies on)) => This call is properly intercepted
A download of a blob from a storage account => This call isn't intercepted
Another one to github (Also through node-fetch) => This call is properly intercepted

import { setup, defaultClient } from 'applicationinsights';
import { Contracts } from "applicationinsights";
import { Data, ExceptionData, RemoteDependencyData } from "applicationinsights/out/Declarations/Contracts";
import fetch from 'node-fetch';
import { BlobClient } from "@azure/storage-blob";

const telemetryConsoleLogger = (envelope: Contracts.Envelope, _contextObjects?: {
  [name: string]: unknown;
}): boolean => {
  switch (envelope.data.baseType) {
    case "RemoteDependencyData": {
      console.log("## DEPENDENCY ######################################################");
      const data = envelope.data as Data<RemoteDependencyData>;
      console.log(data.baseData.data);
      console.log("########################################################");
      break;
    }

    case "ExceptionData": {
      console.log("## EXCEPTION ######################################################");
      const data = envelope.data as Data<ExceptionData>;
      data.baseData.exceptions.forEach(e => { console.log(e.message); });
      console.log("########################################################");
      break;
    }

    default:
      break;
  }

  return true;
};

void (async function () {
  setup("_your_ikey_").start();

  defaultClient.addTelemetryProcessor(telemetryConsoleLogger);

  const depUrl1 = 'https://github.com/';
  const response1 = await fetch(depUrl1);
  const body1 = await response1.text();
  console.log(depUrl1, body1.length);

  const cn = "BlobEndpoint=https://...."; // Connection string

  const containerName = "yourContainerName";
  const blobPath = "yourBlobPath";

  const bc = new BlobClient(cn, containerName, blobPath);
  const buf = await bc.downloadToBuffer();
  console.log("Size of downloaded blob", buf.byteLength);

  const depUrl2 = 'https://github.com/Azure/azure-sdk-for-js';
  const response2 = await fetch(depUrl2);
  const body2 = await response2.text();
  console.log(depUrl2, body2.length);
})();

When run, this code generates the following output in the console.
## DEPENDENCY ######################################################
https://github.com/
########################################################
https://github.com/ 191001
Size of downloaded blob 15111288
## DEPENDENCY ######################################################
https://github.com/Azure/azure-sdk-for-js
########################################################
https://github.com/Azure/azure-sdk-for-js 212053

As one can see, direct calls through node-fetch are intercepted, and although the blob is properly downloaded (and its bytes length displayed in the console), it's not intercepted by ApplicationInsights library.
Expected behavior
Monitoring of dependencies is of great importance in production, in order to ensure the overall ecosystem is working as expected. We are currently relying on AWS S3 for storage and are transitioning to Azure storage accounts. Interception of calls made with the aws sdk work perfectly.
Not being to leverage Microsoft ApplicationInsights node library when working with Microsoft Azure sdk library is a bit of a showstopper from an ops standpoint for us.
It's possible that customizing the instantiation of the BlobClient may help, however going through the options, I've been unable to see one that would help me.
Any help helping us see those dependencies being tracked would be greatly appreciated.

@deyaaeldeen We need to first investigate this from a app insights perspectives and less from storage because whatever the underlying cause is would apply to other packages we support

@deyaaeldeen We need to first investigate this from a app insights perspectives and less from storage because whatever the underlying cause is would apply to other packages we support

I'm confused about the request here. I thought AppInsights was doing work to intercept requests made by any module, rather than every npm module that makes a request doing something special to allow AppInsights to work.

I'm confused about the request here. I thought AppInsights was doing work to intercept requests made by any module, rather than every npm module that makes a request doing something special to allow AppInsights to work.

/cc @hectorhdzg Hey Hector, do you have an idea of what could be going on here?

/cc @hectorhdzg Hey Hector, do you have an idea of what could be going on here?

@nulltoken Application Insights node.js SDK supports automatic tracking of Azure SDKs but you need to install @opentelemetry/tracing package to make it work, I will make sure to update documentation to reflect this.
https://github.com/microsoft/node-diagnostic-channel/tree/master/src/diagnostic-channel-publishers#040-jun-18-2020

@nulltoken Application Insights node.js SDK supports automatic tracking of Azure SDKs but you need to install @opentelemetry/tracing package to make it work, I will make sure to update documentation to reflect this.
https://github.com/microsoft/node-diagnostic-channel/tree/master/src/diagnostic-channel-publishers#040-jun-18-2020

@nulltoken actually on second thought I realized that approach is when using internal logging for Azure SDKs, we may have an issue in the node.js SDK that is preventing this to work I'm currently investigating and will let you know about my findings

@nulltoken actually on second thought I realized that approach is when using internal logging for Azure SDKs, we may have an issue in the node.js SDK that is preventing this to work I'm currently investigating and will let you know about my findings

I'm currently investigating and will let you know about my findings

@hectorhdzg Thanks a lot for this.

I'm currently investigating and will let you know about my findings

@hectorhdzg Thanks a lot for this.

Closing because issue is on

@hectorhdzg  - looks like that PR merged. When do the appinsights packages get published?

applicationisnsights latest version must have a fix for this
https://www.npmjs.com/package/applicationinsights

@hectorhdzg Thanks for that. However, my repro case seems to still not work even with upgraded dependencies. Help?
Output:
## DEPENDENCY ######################################################
https://github.com/
########################################################
https://github.com/ 197322
Size of downloaded blob 15499988
## DEPENDENCY ######################################################
https://github.com/Azure/azure-sdk-for-js
########################################################
https://github.com/Azure/azure-sdk-for-js 216119
Done in 21.45s.

dependencies:
  "dependencies": {
    "@azure/storage-blob": "^12.4.1",
    "@opentelemetry/tracing": "^0.16.0",
    "applicationinsights": "^1.8.10"
  }

yarn.lock:
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1

"<EMAIL_ADDRESS>  version "1.0.2"
  resolved<EMAIL_ADDRESS>  integrity sha512-XUyTo+bcyxHEf+jlN2MXA7YU9nxVehaubngHV1MIZZaqYmZqykkoeAz/JMMEeR7t3TcyDwbFa3Zw8BZywmIx4g==
  dependencies:
    tslib "^2.0.0"

"<EMAIL_ADDRESS>  version "1.0.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-kmv8CGrPfN9SwMwrkiBK9VTQYxdFQEGe0BmQk+M8io56P9KNzpAxcWE/1fxJj7uouwN4kXF0BHW8DNlgx+wtCg==

"<EMAIL_ADDRESS>  version "1.2.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-KUl+Nwn/Sm6Lw5d3U90m1jZfNSL087SPcqHLxwn2T6PupNKmcgsEbDjHB25gDvHO4h7pBsTlrdJAY7dz+Qk8GA==
  dependencies:
    "@azure/abort-controller" "^1.0.0"
    tslib "^2.0.0"

"<EMAIL_ADDRESS>  version "1.2.3"
  resolved<EMAIL_ADDRESS>  integrity sha512-g5C1zUJO5dehP2Riv+vy9iCYoS1UwKnZsBVCzanScz9A83LbnXKpZDa9wie26G9dfXUhQoFZoFT8LYWhPKmwcg==
  dependencies:
    "@azure/abort-controller" "^1.0.0"
    "@azure/core-auth" "^1.1.3"
    "@azure/core-tracing" "1.0.0-preview.9"
    "@azure/logger" "^1.0.0"
    "@opentelemetry/api" "^0.10.2"
    "@types/node-fetch" "^2.5.0"
    "@types/tunnel" "^0.0.1"
    form-data "^3.0.0"
    node-fetch "^2.6.0"
    process "^0.11.10"
    tough-cookie "^4.0.0"
    tslib "^2.0.0"
    tunnel "^0.0.6"
    uuid "^8.3.0"
    xml2js "^0.4.19"

"<EMAIL_ADDRESS>  version "1.0.3"
  resolved<EMAIL_ADDRESS>  integrity sha512-Py2crJ84qx1rXkzIwfKw5Ni4WJuzVU7KAF6i1yP3ce8fbynUeu8eEWS4JGtSQgU7xv02G55iPDROifmSDbxeHA==
  dependencies:
    "@azure/abort-controller" "^1.0.0"
    "@azure/core-http" "^1.2.0"
    events "^3.0.0"
    tslib "^2.0.0"

"<EMAIL_ADDRESS>  version "1.1.3"
  resolved<EMAIL_ADDRESS>  integrity sha512-his7Ah40ThEYORSpIAwuh6B8wkGwO/zG7gqVtmSE4WAJ46e36zUDXTKReUCLBDc6HmjjApQQxxcRFy5FruG79A==
  dependencies:
    "@azure/core-asynciterator-polyfill" "^1.0.0"

"<EMAIL_ADDRESS>  version "1.0.0-preview.9"
  resolved<EMAIL_ADDRESS>  integrity sha512-zczolCLJ5QG42AEPQ+Qg9SRYNUyB+yZ5dzof4YEc+dyWczO9G2sBqbAjLB7IqrsdHN2apkiB2oXeDKCsq48jug==
  dependencies:
    "@opencensus/web-types" "0.0.7"
    "@opentelemetry/api" "^0.10.2"
    tslib "^2.0.0"

"<EMAIL_ADDRESS>  version "1.0.1"
  resolved<EMAIL_ADDRESS>  integrity sha512-QYQeaJ+A5x6aMNu8BG5qdsVBnYBop9UMwgUvGihSjf1PdZZXB+c/oMdM2ajKwzobLBh9e9QuMQkN9iL+IxLBLA==
  dependencies:
    tslib "^2.0.0"

"<EMAIL_ADDRESS>  version "12.4.1"
  resolved<EMAIL_ADDRESS>  integrity sha512-RH6ru8LbnCC+m1rlVLon6mYUXdHsTcyUXFCJAWRQQM7p0XOwVKPS+UiVk2tZXfvMWd3q/qT/meOrEbHEcp/c4g==
  dependencies:
    "@azure/abort-controller" "^1.0.0"
    "@azure/core-http" "^1.2.0"
    "@azure/core-lro" "^1.0.2"
    "@azure/core-paging" "^1.1.1"
    "@azure/core-tracing" "1.0.0-preview.9"
    "@azure/logger" "^1.0.0"
    "@opentelemetry/api" "^0.10.2"
    events "^3.0.0"
    tslib "^2.0.0"

"<EMAIL_ADDRESS>  version "26.6.2"
  resolved<EMAIL_ADDRESS>  integrity sha512-fC6QCp7Sc5sX6g8Tvbmj4XUTbyrik0akgRy03yjXbQaBWWNWGE7SGtJk98m0N8nzegD/7SggrUlivxo5ax4KWQ==
  dependencies:
    "@types/istanbul-lib-coverage" "^2.0.0"
    "@types/istanbul-reports" "^3.0.0"
    "@types/node" "*"
    "@types/yargs" "^15.0.0"
    chalk "^4.0.0"

"<EMAIL_ADDRESS>  version "0.0.7"
  resolved<EMAIL_ADDRESS>  integrity sha512-xB+w7ZDAu3YBzqH44rCmG9/RlrOmFuDPt/bpf17eJr8eZSrLt7nc7LnWdxM9Mmoj/YKMHpxRg28txu3TcpiL+g==

"<EMAIL_ADDRESS>  version "0.10.2"
  resolved<EMAIL_ADDRESS>  integrity sha512-GtpMGd6vkzDMYcpu2t9LlhEgMy/SzBwRnz48EejlRArYqZzqSzAsKmegUK7zHgl+EOIaK9mKHhnRaQu3qw20cA==
  dependencies:
    "@opentelemetry/context-base" "^0.10.2"

"<EMAIL_ADDRESS>  version "0.16.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-y5mNFAiktm7Zyf0GrQ6kjsRqace/WCXk9gMo/sOOna4TtMW8NaZgJceKrsQZl3qiPY9Upu8O9VvdlETXDx4U5A==
  dependencies:
    "@opentelemetry/context-base" "^0.16.0"

"<EMAIL_ADDRESS>  version "0.10.2"
  resolved<EMAIL_ADDRESS>  integrity sha512-hZNKjKOYsckoOEgBziGMnBcX0M7EtstnCmwz5jZUOUYwlZ+/xxX6z3jPu1XVO2Jivk0eLfuP9GP+vFD49CMetw==

"<EMAIL_ADDRESS>  version "0.16.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-2h2s+3P40wIu8ZaJiqBF6E0rEJPeSVOErFlkx2MfRGPs9Vs9Th+i5YSpgvCW4s5LeYTFAf2BRwut39JivEyH9w==

"<EMAIL_ADDRESS>  version "0.16.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-NFZwEW5TeFIAUlNty9al0KU9AQzpEiBowem/33d3ftxYHZ7dG1JklFnyKLTVb+pAZFm/peTziVddfHoTsIY4Rg==
  dependencies:
    "@opentelemetry/api" "^0.16.0"
    "@opentelemetry/context-base" "^0.16.0"
    semver "^7.1.3"

"<EMAIL_ADDRESS>  version "0.16.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-HOAmcRnZGbEhcddsjqvz3Q/mEg75PyEoH/CZZ3YGqYmwTPimTiusm8iz5nXMxp1UpT8rkzlEGei/E21SQ/Zh9g==
  dependencies:
    "@opentelemetry/api" "^0.16.0"
    "@opentelemetry/core" "^0.16.0"

"<EMAIL_ADDRESS>  version "0.16.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-RDYLf6lUtikIDTr6yVDehsUAlNb1U680eOV1QuDN0w6FDGubTnjbADlgpF41ByOow1Jp/WGmynFfOh19Ix4NWw==

"<EMAIL_ADDRESS>  version "0.16.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-8UrNbzO56m8fe9ge+XR0Lruwld+W6SM6aWFQT32YCU8lS+Hzz2P6TbevmgT4DzeKszJxnHqzNnqx8HziNeUjTA==
  dependencies:
    "@opentelemetry/api" "^0.16.0"
    "@opentelemetry/context-base" "^0.16.0"
    "@opentelemetry/core" "^0.16.0"
    "@opentelemetry/resources" "^0.16.0"
    "@opentelemetry/semantic-conventions" "^0.16.0"
    lodash.merge "^4.6.2"

"@types/istanbul-lib-coverage@*", "<EMAIL_ADDRESS>  version "2.0.3"
  resolved<EMAIL_ADDRESS>  integrity sha512-sz7iLqvVUg1gIedBOvlkxPlc8/uVzyS5OwGz1cKjXzkl3FpL3al0crU8YGU1WoHkxn0Wxbw5tyi6hvzJKNzFsw==

"@types/istanbul-lib-report@*":
  version "3.0.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-plGgXAPfVKFoYfa9NpYDAkseG+g6Jr294RqeqcqDixSbU34MZVJRi/P+7Y8GDpzkEwLaGZZOpKIEmeVZNtKsrg==
  dependencies:
    "@types/istanbul-lib-coverage" "*"

"<EMAIL_ADDRESS>  version "3.0.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-nwKNbvnwJ2/mndE9ItP/zc2TCzw6uuodnF4EHYWD+gCQDVBuRQL5UzbZD0/ezy1iKsFU2ZQiDqg4M9dN4+wZgA==
  dependencies:
    "@types/istanbul-lib-report" "*"

"<EMAIL_ADDRESS>  version "26.0.20"
  resolved<EMAIL_ADDRESS>  integrity sha512-9zi2Y+5USJRxd0FsahERhBwlcvFh6D2GLQnY2FH2BzK8J9s9omvNHIbvABwIluXa0fD8XVKMLTO0aOEuUfACAA==
  dependencies:
    jest-diff "^26.0.0"
    pretty-format "^26.0.0"

"<EMAIL_ADDRESS>  version "2.5.8"
  resolved<EMAIL_ADDRESS>  integrity sha512-fbjI6ja0N5ZA8TV53RUqzsKNkl9fv8Oj3T7zxW7FGv1GSH7gwJaNF8dzCjrqKaxKeUpTz4yT1DaJFq/omNpGfw==
  dependencies:
    "@types/node" "*"
    form-data "^3.0.0"

"@types/node@*", "<EMAIL_ADDRESS>  version "14.14.26"
  resolved<EMAIL_ADDRESS>  integrity sha512-skWxepWOs+VArEBWd2S/VR3wUavioIIx9/HzW+UJiIjtwa6+kNXdsOeq7FfxDXf56hIcL0ieo2brwMgBJ1+lhw==

"<EMAIL_ADDRESS>  version "0.0.1"
  resolved<EMAIL_ADDRESS>  integrity sha512-AOqu6bQu5MSWwYvehMXLukFHnupHrpZ8nvgae5Ggie9UwzDR1CCwoXgSSWNZJuyOlCdfdsWMA5F2LlmvyoTv8A==
  dependencies:
    "@types/node" "*"

"@types/yargs-parser@*":
  version "20.2.0"
  resolved<EMAIL_ADDRESS>  integrity sha512-37RSHht+gzzgYeobbG+KWryeAW8J33Nhr69cjTqSYymXVZEN9NbRYWoYlRtDhHKPVT1FyNKwaTPC1NynKZpzRA==

"<EMAIL_ADDRESS>  version "15.0.13"
  resolved<EMAIL_ADDRESS>  integrity sha512-kQ5JNTrbDv3Rp5X2n/iUu37IJBDU2gsZ5R/g1/KHOOEc5IKfUFjXT6DENPGduh08I/pamwtEq4oul7gUqKTQDQ==
  dependencies:
    "@types/yargs-parser" "*"

<EMAIL_ADDRESS>  version "5.0.0"
  resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-5.0.0.tgz#388539f55179bf39339c81af30a654d69f87cb75"
  integrity sha512-bY6fj56OUQ0hU1KjFNDQuJFezqKdrAyFdIevADiqrWHwSlbmBNMHp5ak2f40Pm8JTFyM2mqxkG6ngkHO11f/lg==

<EMAIL_ADDRESS><EMAIL_ADDRESS>  version "4.3.0"
  resolved "https://registry.yarnpkg.com/ansi-styles/-/ansi-styles-4.3.0.tgz#edd803628ae71c04c85ae7a0906edad34b648937"
  integrity sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==
  dependencies:
    color-convert "^2.0.1"

<EMAIL_ADDRESS>  version "1.8.10"
  resolved "https://registry.yarnpkg.com/applicationinsights/-/applicationinsights-1.8.10.tgz#fffa482cd1519880fb888536a87081ac05130667"
  integrity sha512-ZLDA7mShh4mP2Z/HlFolmvhBPX1LfnbIWXrselyYVA7EKjHhri1fZzpu2EiWAmfbRxNBY6fRjoPJWbx5giKy4A==
  dependencies:
    cls-hooked "^4.2.2"
    continuation-local-storage "^3.2.1"
    diagnostic-channel "0.3.1"
    diagnostic-channel-publishers "0.4.4"

<EMAIL_ADDRESS>  version "4.1.3"
  resolved "https://registry.yarnpkg.com/arg/-/arg-4.1.3.tgz#269fc7ad5b8e42cb63c896d5666017261c144089"
  integrity sha512-58S9QDqG0Xx27YwPSt9fJxivjYl432YCwfDMfZ+71RAqUrZef7LrKQZ3LHLOwCS4FLNBplP533Zx895SeOCHvA==

<EMAIL_ADDRESS>  version "1.7.6"
  resolved "https://registry.yarnpkg.com/async-hook-jl/-/async-hook-jl-1.7.6.tgz#4fd25c2f864dbaf279c610d73bf97b1b28595e68"
  integrity sha512-gFaHkFfSxTjvoxDMYqDuGHlcRyUuamF8s+ZTtJdDzqjws4mCt7v0vuV79/E2Wr2/riMQgtG4/yUtXWs1gZ7JMg==
  dependencies:
    stack-chain "^1.3.7"

<EMAIL_ADDRESS>  version "0.6.10"
  resolved "https://registry.yarnpkg.com/async-listener/-/async-listener-0.6.10.tgz#a7c97abe570ba602d782273c0de60a51e3e17cbc"
  integrity sha512-gpuo6xOyF4D5DE5WvyqZdPA3NGhiT6Qf07l7DCB0wwDEsLvDIbCr6j9S5aj5Ch96dLace5tXVzWBZkxU/c5ohw==
  dependencies:
    semver "^5.3.0"
    shimmer "^1.1.0"

<EMAIL_ADDRESS>  version "0.4.0"
  resolved "https://registry.yarnpkg.com/asynckit/-/asynckit-0.4.0.tgz#c79ed97f7f34cb8f2ba1bc9790bcc366474b4b79"
  integrity sha1-x57Zf380y48robyXkLzDZkdLS3k=

<EMAIL_ADDRESS>  version "1.0.0"
  resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-1.0.0.tgz#89b4d199ab2bee49de164ea02b89ce462d71b767"
  integrity sha1-ibTRmasr7kneFk6gK4nORi1xt2c=

<EMAIL_ADDRESS>  version "1.1.11"
  resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.11.tgz#3c7fcbf529d87226f3d2f52b966ff5271eb441dd"
  integrity sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==
  dependencies:
    balanced-match "^1.0.0"
    concat-map "0.0.1"

<EMAIL_ADDRESS>  version "1.1.1"
  resolved "https://registry.yarnpkg.com/buffer-from/-/buffer-from-1.1.1.tgz#32713bc028f75c02fdb710d7c7bcec1f2c6070ef"
  integrity sha512-MQcXEUbCKtEo7bhqEs6560Hyd4XaovZlO/k9V3hjVUF/zwW7KBVdSK4gIt/bzwS9MbR5qob+F5jusZsb0YQK2A==

<EMAIL_ADDRESS>  version "4.1.0"
  resolved "https://registry.yarnpkg.com/chalk/-/chalk-4.1.0.tgz#4e14870a618d9e2edd97dd8345fd9d9dc315646a"
  integrity sha512-qwx12AxXe2Q5xQ43Ac//I6v5aXTipYrSESdOgzrN+9XjgEpyjpKuvSGaN4qE93f7TQTlerQQ8S+EQ0EyDoVL1A==
  dependencies:
    ansi-styles "^4.1.0"
    supports-color "^7.1.0"

<EMAIL_ADDRESS>  version "4.2.2"
  resolved "https://registry.yarnpkg.com/cls-hooked/-/cls-hooked-4.2.2.tgz#ad2e9a4092680cdaffeb2d3551da0e225eae1908"
  integrity sha512-J4Xj5f5wq/4jAvcdgoGsL3G103BtWpZrMo8NEinRltN+xpTZdI+M38pyQqhuFU/P792xkMFvnKSf+Lm81U1bxw==
  dependencies:
    async-hook-jl "^1.7.6"
    emitter-listener "^1.0.1"
    semver "^5.4.1"

<EMAIL_ADDRESS>  version "2.0.1"
  resolved "https://registry.yarnpkg.com/color-convert/-/color-convert-2.0.1.tgz#72d3a68d598c9bdb3af2ad1e84f21d896abd4de3"
  integrity sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==
  dependencies:
    color-name "~1.1.4"

<EMAIL_ADDRESS>  version "1.1.4"
  resolved "https://registry.yarnpkg.com/color-name/-/color-name-1.1.4.tgz#c2a09a87acbde69543de6f63fa3995c826c536a2"
  integrity sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==

<EMAIL_ADDRESS>  version "1.0.8"
  resolved "https://registry.yarnpkg.com/combined-stream/-/combined-stream-1.0.8.tgz#c3d45a8b34fd730631a110a8a2520682b31d5a7f"
  integrity sha512-FQN4MRfuJeHf7cBbBMJFXhKSDq+2kAArBlmRBvcvFE5BB1HZKXtSFASDhdlz9zOYwxh8lDdnvmMOe/+5cdoEdg==
  dependencies:
    delayed-stream "~1.0.0"

<EMAIL_ADDRESS>  version "0.0.1"
  resolved "https://registry.yarnpkg.com/concat-map/-/concat-map-0.0.1.tgz#d8a96bd77fd68df7793a73036a3ba0d5405d477b"
  integrity sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=

<EMAIL_ADDRESS>  version "3.2.1"
  resolved "https://registry.yarnpkg.com/continuation-local-storage/-/continuation-local-storage-3.2.1.tgz#11f613f74e914fe9b34c92ad2d28fe6ae1db7ffb"
  integrity sha512-jx44cconVqkCEEyLSKWwkvUXwO561jXMa3LPjTPsm5QR22PA0/mhe33FT4Xb5y74JDvt/Cq+5lm8S8rskLv9ZA==
  dependencies:
    async-listener "^0.6.0"
    emitter-listener "^1.1.1"

<EMAIL_ADDRESS>  version "1.1.1"
  resolved "https://registry.yarnpkg.com/create-require/-/create-require-1.1.1.tgz#c1d7e8f1e5f6cfc9ff65f9cd352d37348756c333"
  integrity sha512-dcKFX3jn0MpIaXjisoRvexIJVEKzaq7z2rZKxf+MSr9TkdmHmsU4m2lcLojrj/FHl8mk5VxMmYA+ftRkP/3oKQ==

<EMAIL_ADDRESS>  version "1.0.0"
  resolved "https://registry.yarnpkg.com/delayed-stream/-/delayed-stream-1.0.0.tgz#df3ae199acadfb7d440aaae0b29e2272b24ec619"
  integrity sha1-3zrhmayt+31ECqrgsp4icrJOxhk=

<EMAIL_ADDRESS>  version "0.4.4"
  resolved "https://registry.yarnpkg.com/diagnostic-channel-publishers/-/diagnostic-channel-publishers-0.4.4.tgz#57c3b80b7e7f576f95be3a257d5e94550f0082d6"
  integrity sha512-l126t01d2ZS9EreskvEtZPrcgstuvH3rbKy82oUhUrVmBaGx4hO9wECdl3cvZbKDYjMF3QJDB5z5dL9yWAjvZQ==

<EMAIL_ADDRESS>  version "0.3.1"
  resolved "https://registry.yarnpkg.com/diagnostic-channel/-/diagnostic-channel-0.3.1.tgz#7faa143e107f861be3046539eb4908faab3f53fd"
  integrity sha512-6eb9YRrimz8oTr5+JDzGmSYnXy5V7YnK5y/hd8AUDK1MssHjQKm9LlD6NSrHx4vMDF3+e/spI2hmWTviElgWZA==
  dependencies:
    semver "^5.3.0"

<EMAIL_ADDRESS>  version "26.6.2"
  resolved "https://registry.yarnpkg.com/diff-sequences/-/diff-sequences-26.6.2.tgz#48ba99157de1923412eed41db6b6d4aa9ca7c0b1"
  integrity sha512-Mv/TDa3nZ9sbc5soK+OoA74BsS3mL37yixCvUAQkiuA4Wz6YtwP/K47n2rv2ovzHZvoiQeA5FTQOschKkEwB0Q==

<EMAIL_ADDRESS>  version "4.0.2"
  resolved "https://registry.yarnpkg.com/diff/-/diff-4.0.2.tgz#60f3aecb89d5fae520c11aa19efc2bb982aade7d"
  integrity sha512-58lmxKSA4BNyLz+HHMUzlOEpg09FV+ev6ZMe3vJihgdxzgcwZ8VoEEPmALCZG9LmqfVoNMMKpttIYTVG6uDY7A==

<EMAIL_ADDRESS><EMAIL_ADDRESS>  version "1.1.2"
  resolved "https://registry.yarnpkg.com/emitter-listener/-/emitter-listener-1.1.2.tgz#56b140e8f6992375b3d7cb2cab1cc7432d9632e8"
  integrity sha512-Bt1sBAGFHY9DKY+4/2cV6izcKJUf5T7/gkdmkxzX/qv9CcGH8xSwVRW5mtX03SWJtRTWSOpzCuWN9rBFYZepZQ==
  dependencies:
    shimmer "^1.2.0"

<EMAIL_ADDRESS>  version "3.2.0"
  resolved "https://registry.yarnpkg.com/events/-/events-3.2.0.tgz#93b87c18f8efcd4202a461aec4dfc0556b639379"
  integrity sha512-/46HWwbfCX2xTawVfkKLGxMifJYQBWMwY1mjywRtb4c9x8l5NP3KoJtnIOiL1hfdRkIuYhETxQlo62IF8tcnlg==

<EMAIL_ADDRESS>  version "3.0.0"
  resolved "https://registry.yarnpkg.com/form-data/-/form-data-3.0.0.tgz#31b7e39c85f1355b7139ee0c647cf0de7f83c682"
  integrity sha512-CKMFDglpbMi6PyN+brwB9Q/GOw0eAnsrEZDgcsH5Krhz5Od/haKHAX0NmQfha2zPPz0JpWzA7GJHGSnvCRLWsg==
  dependencies:
    asynckit "^0.4.0"
    combined-stream "^1.0.8"
    mime-types "^2.1.12"

<EMAIL_ADDRESS>  version "1.0.0"
  resolved "https://registry.yarnpkg.com/fs.realpath/-/fs.realpath-1.0.0.tgz#1504ad2523158caa40db4a2787cb01411994ea4f"
  integrity sha1-FQStJSMVjKpA20onh8sBQRmU6k8=

<EMAIL_ADDRESS>  version "7.1.6"
  resolved "https://registry.yarnpkg.com/glob/-/glob-7.1.6.tgz#141f33b81a7c2492e125594307480c46679278a6"
  integrity sha512-LwaxwyZ72Lk7vZINtNNrywX0ZuLyStrdDtabefZKAY5ZGJhVtgdznluResxNmPitE0SAO+O26sWTHeKSI2wMBA==
  dependencies:
    fs.realpath "^1.0.0"
    inflight "^1.0.4"
    inherits "2"
    minimatch "^3.0.4"
    once "^1.3.0"
    path-is-absolute "^1.0.0"

<EMAIL_ADDRESS>  version "4.0.0"
  resolved "https://registry.yarnpkg.com/has-flag/-/has-flag-4.0.0.tgz#944771fd9c81c81265c4d6941860da06bb59479b"
  integrity sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==

<EMAIL_ADDRESS>  version "1.0.6"
  resolved "https://registry.yarnpkg.com/inflight/-/inflight-1.0.6.tgz#49bd6331d7d02d0c09bc910a1075ba8165b56df9"
  integrity sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=
  dependencies:
    once "^1.3.0"
    wrappy "1"

inherits@2:
  version "2.0.4"
  resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.4.tgz#0fa2c64f932917c3433a0ded55363aae37416b7c"
  integrity sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==

<EMAIL_ADDRESS>  version "26.6.2"
  resolved "https://registry.yarnpkg.com/jest-diff/-/jest-diff-26.6.2.tgz#1aa7468b52c3a68d7d5c5fdcdfcd5e49bd164394"
  integrity sha512-6m+9Z3Gv9wN0WFVasqjCL/06+EFCMTqDEUl/b87HYK2rAPTyfz4ZIuSlPhY51PIQRWx5TaxeF1qmXKe9gfN3sA==
  dependencies:
    chalk "^4.0.0"
    diff-sequences "^26.6.2"
    jest-get-type "^26.3.0"
    pretty-format "^26.6.2"

<EMAIL_ADDRESS>  version "26.3.0"
  resolved "https://registry.yarnpkg.com/jest-get-type/-/jest-get-type-26.3.0.tgz#e97dc3c3f53c2b406ca7afaed4493b1d099199e0"
  integrity sha512-TpfaviN1R2pQWkIihlfEanwOXK0zcxrKEE4MlU6Tn7keoXdN6/3gK/xl0yEh8DOunn5pOVGKf8hB4R9gVh04ig==

<EMAIL_ADDRESS>  version "4.6.2"
  resolved "https://registry.yarnpkg.com/lodash.merge/-/lodash.merge-4.6.2.tgz#558aa53b43b661e1925a0afdfa36a9a1085fe57a"
  integrity sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==

<EMAIL_ADDRESS>  version "6.0.0"
  resolved "https://registry.yarnpkg.com/lru-cache/-/lru-cache-6.0.0.tgz#6d6fe6570ebd96aaf90fcad1dafa3b2566db3a94"
  integrity sha512-Jo6dJ04CmSjuznwJSS3pUeWmd/H0ffTlkXXgwZi+eq1UCmqQwCh+eLsYOYCwY991i2Fah4h1BEMCx4qThGbsiA==
  dependencies:
    yallist "^4.0.0"

<EMAIL_ADDRESS>  version "1.3.6"
  resolved "https://registry.yarnpkg.com/make-error/-/make-error-1.3.6.tgz#2eb2e37ea9b67c4891f684a1394799af484cf7a2"
  integrity sha512-s8UhlNe7vPKomQhC1qFelMokr/Sc3AgNbso3n74mVPA5LTZwkB9NlXf4XPamLxJE8h0gh73rM94xvwRT2CVInw==

<EMAIL_ADDRESS>  version "1.45.0"
  resolved "https://registry.yarnpkg.com/mime-db/-/mime-db-1.45.0.tgz#cceeda21ccd7c3a745eba2decd55d4b73e7879ea"
  integrity sha512-CkqLUxUk15hofLoLyljJSrukZi8mAtgd+yE5uO4tqRZsdsAJKv0O+rFMhVDRJgozy+yG6md5KwuXhD4ocIoP+w==

<EMAIL_ADDRESS>  version "2.1.28"
  resolved "https://registry.yarnpkg.com/mime-types/-/mime-types-2.1.28.tgz#1160c4757eab2c5363888e005273ecf79d2a0ecd"
  integrity sha512-0TO2yJ5YHYr7M2zzT7gDU1tbwHxEUWBCLt0lscSNpcdAfFyJOVEpRYNS7EXVcTLNj/25QO8gulHC5JtTzSE2UQ==
  dependencies:
    mime-db "1.45.0"

<EMAIL_ADDRESS>  version "3.0.4"
  resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.0.4.tgz#5166e286457f03306064be5497e8dbb0c3d32083"
  integrity sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==
  dependencies:
    brace-expansion "^1.1.7"

<EMAIL_ADDRESS>  version "2.6.1"
  resolved "https://registry.yarnpkg.com/node-fetch/-/node-fetch-2.6.1.tgz#045bd323631f76ed2e2b55573394416b639a0052"
  integrity sha512-V4aYg89jEoVRxRb2fJdAg8FHvI7cEyYdVAh94HH0UIK8oJxUfkjlDQN9RbMx+bEjP7+ggMiFRprSti032Oipxw==

<EMAIL_ADDRESS>  version "1.4.0"
  resolved "https://registry.yarnpkg.com/once/-/once-1.4.0.tgz#583b1aa775961d4b113ac17d9c50baef9dd76bd1"
  integrity sha1-WDsap3WWHUsROsF9nFC6753Xa9E=
  dependencies:
    wrappy "1"

<EMAIL_ADDRESS>  version "1.0.1"
  resolved "https://registry.yarnpkg.com/path-is-absolute/-/path-is-absolute-1.0.1.tgz#174b9268735534ffbc7ace6bf53a5a9e1b5c5f5f"
  integrity sha1-F0uSaHNVNP+8es5r9TpanhtcX18=

<EMAIL_ADDRESS><EMAIL_ADDRESS>  version "26.6.2"
  resolved "https://registry.yarnpkg.com/pretty-format/-/pretty-format-26.6.2.tgz#e35c2705f14cb7fe2fe94fa078345b444120fc93"
  integrity sha512-7AeGuCYNGmycyQbCqd/3PWH4eOoX/OiCa0uphp57NVTeAGdJGaAliecxwBDHYQCIvrW7aDBZCYeNTP/WX69mkg==
  dependencies:
    "@jest/types" "^26.6.2"
    ansi-regex "^5.0.0"
    ansi-styles "^4.0.0"
    react-is "^17.0.1"

<EMAIL_ADDRESS>  version "0.11.10"
  resolved "https://registry.yarnpkg.com/process/-/process-0.11.10.tgz#7332300e840161bda3e69a1d1d91a7d4bc16f182"
  integrity sha1-czIwDoQBYb2j5podHZGn1LwW8YI=

<EMAIL_ADDRESS>  version "1.8.0"
  resolved "https://registry.yarnpkg.com/psl/-/psl-1.8.0.tgz#9326f8bcfb013adcc005fdff056acce020e51c24"
  integrity sha512-RIdOzyoavK+hA18OGGWDqUTsCLhtA7IcZ/6NCs4fFJaHBDab+pDDmDIByWFRQJq2Cd7r1OoQxBGKOaztq+hjIQ==

<EMAIL_ADDRESS>  version "2.1.1"
  resolved "https://registry.yarnpkg.com/punycode/-/punycode-2.1.1.tgz#b58b010ac40c22c5657616c8d2c2c02c7bf479ec"
  integrity sha512-XRsRjdf+j5ml+y/6GKHPZbrF/8p2Yga0JPtdqTIY2Xe5ohJPD9saDJJLPvp9+NSBprVvevdXZybnj2cv8OEd0A==

<EMAIL_ADDRESS>  version "17.0.1"
  resolved "https://registry.yarnpkg.com/react-is/-/react-is-17.0.1.tgz#5b3531bd76a645a4c9fb6e693ed36419e3301339"
  integrity sha512-NAnt2iGDXohE5LI7uBnLnqvLQMtzhkiAOLXTmv+qnF9Ky7xAPcX8Up/xWIhxvLVGJvuLiNc4xQLtuqDRzb4fSA==

<EMAIL_ADDRESS>  version "3.0.2"
  resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-3.0.2.tgz#f1a5402ba6220ad52cc1282bac1ae3aa49fd061a"
  integrity sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==
  dependencies:
    glob "^7.1.3"

<EMAIL_ADDRESS>  version "1.2.4"
  resolved "https://registry.yarnpkg.com/sax/-/sax-1.2.4.tgz#2816234e2378bddc4e5354fab5caa895df7100d9"
  integrity sha512-NqVDv9TpANUjFm0N8uM5GxL36UgKi9/atZw+x7YFnQ8ckwFGKrl4xX4yWtrey3UJm5nP1kUbnYgLopqWNSRhWw==

<EMAIL_ADDRESS><EMAIL_ADDRESS>  version "5.7.1"
  resolved "https://registry.yarnpkg.com/semver/-/semver-5.7.1.tgz#a954f931aeba508d307bbf069eff0c01c96116f7"
  integrity sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==

<EMAIL_ADDRESS>  version "7.3.4"
  resolved "https://registry.yarnpkg.com/semver/-/semver-7.3.4.tgz#27aaa7d2e4ca76452f98d3add093a72c943edc97"
  integrity sha512-tCfb2WLjqFAtXn4KEdxIhalnRtoKFN7nAwj0B3ZXCbQloV2tq5eDbcTmT68JJD3nRJq24/XgxtQKFIpQdtvmVw==
  dependencies:
    lru-cache "^6.0.0"

<EMAIL_ADDRESS><EMAIL_ADDRESS>  version "1.2.1"
  resolved "https://registry.yarnpkg.com/shimmer/-/shimmer-1.2.1.tgz#610859f7de327b587efebf501fb43117f9aff337"
  integrity sha512-sQTKC1Re/rM6XyFM6fIAGHRPVGvyXfgzIDvzoq608vM+jeyVD0Tu1E6Np0Kc2zAIFWIj963V2800iF/9LPieQw==

<EMAIL_ADDRESS>  version "0.5.19"
  resolved "https://registry.yarnpkg.com/source-map-support/-/source-map-support-0.5.19.tgz#a98b62f86dcaf4f67399648c085291ab9e8fed61"
  integrity sha512-Wonm7zOCIJzBGQdB+thsPar0kYuCIzYvxZwlBa87yi/Mdjv7Tip2cyVbLj5o0cFPN4EVkuTwb3GDDyUx2DGnGw==
  dependencies:
    buffer-from "^1.0.0"
    source-map "^0.6.0"

<EMAIL_ADDRESS>  version "0.6.1"
  resolved "https://registry.yarnpkg.com/source-map/-/source-map-0.6.1.tgz#74722af32e9614e9c287a8d0bbde48b5e2f1a263"
  integrity sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==

<EMAIL_ADDRESS>  version "1.3.7"
  resolved "https://registry.yarnpkg.com/stack-chain/-/stack-chain-1.3.7.tgz#d192c9ff4ea6a22c94c4dd459171e3f00cea1285"
  integrity sha1-0ZLJ/06moiyUxN1FkXHj8AzqEoU=

<EMAIL_ADDRESS>  version "7.2.0"
  resolved "https://registry.yarnpkg.com/supports-color/-/supports-color-7.2.0.tgz#1b7dcdcb32b8138801b3e478ba6a51caa89648da"
  integrity sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==
  dependencies:
    has-flag "^4.0.0"

<EMAIL_ADDRESS>  version "4.0.0"
  resolved "https://registry.yarnpkg.com/tough-cookie/-/tough-cookie-4.0.0.tgz#d822234eeca882f991f0f908824ad2622ddbece4"
  integrity sha512-tHdtEpQCMrc1YLrMaqXXcj6AxhYi/xgit6mZu1+EDWUn+qhUf8wMQoFIy9NXuq23zAwtcB0t/MjACGR18pcRbg==
  dependencies:
    psl "^1.1.33"
    punycode "^2.1.1"
    universalify "^0.1.2"

<EMAIL_ADDRESS>  version "9.1.1"
  resolved "https://registry.yarnpkg.com/ts-node/-/ts-node-9.1.1.tgz#51a9a450a3e959401bda5f004a72d54b936d376d"
  integrity sha512-hPlt7ZACERQGf03M253ytLY3dHbGNGrAq9qIHWUY9XHYl1z7wYngSr3OQ5xmui8o2AaxsONxIzjafLUiWBo1Fg==
  dependencies:
    arg "^4.1.0"
    create-require "^1.1.0"
    diff "^4.0.1"
    make-error "^1.1.1"
    source-map-support "^0.5.17"
    yn "3.1.1"

<EMAIL_ADDRESS>  version "2.1.0"
  resolved "https://registry.yarnpkg.com/tslib/-/tslib-2.1.0.tgz#da60860f1c2ecaa5703ab7d39bc05b6bf988b97a"
  integrity sha512-hcVC3wYEziELGGmEEXue7D75zbwIIVUMWAVbHItGPx0ziyXxrOMQx4rQEVEV45Ut/1IotuEvwqPopzIOkDMf0A==

<EMAIL_ADDRESS>  version "0.0.6"
  resolved "https://registry.yarnpkg.com/tunnel/-/tunnel-0.0.6.tgz#72f1314b34a5b192db012324df2cc587ca47f92c"
  integrity sha512-1h/Lnq9yajKY2PEbBadPXj3VxsDDu844OnaAo52UVmIzIvwwtBPIuNvkjuzBlTWpfJyUbG3ez0KSBibQkj4ojg==

<EMAIL_ADDRESS>  version "4.1.5"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.1.5.tgz#123a3b214aaff3be32926f0d8f1f6e704eb89a72"
  integrity sha512-6OSu9PTIzmn9TCDiovULTnET6BgXtDYL4Gg4szY+cGsc3JP1dQL8qvE8kShTRx1NIw4Q9IBHlwODjkjWEtMUyA==

<EMAIL_ADDRESS>  version "0.1.2"
  resolved "https://registry.yarnpkg.com/universalify/-/universalify-0.1.2.tgz#b646f69be3942dabcecc9d6639c80dc105efaa66"
  integrity sha512-rBJeI5CXAlmy1pV+617WB9J63U6XcazHHF2f2dbJix4XzpUF0RS3Zbj0FGIOCAva5P/d/GBOYaACQ1w+0azUkg==

<EMAIL_ADDRESS>  version "8.3.2"
  resolved "https://registry.yarnpkg.com/uuid/-/uuid-8.3.2.tgz#80d5b5ced271bb9af6c445f21a1a04c606cefbe2"
  integrity sha512-+NYs2QeMWy+GWFOEm9xnn6HCDp0l7QBD7ml8zLUmJ+93Q5NF0NocErnwkTkXVFNiX3/fpC6afS8Dhb/gz7R7eg==

wrappy@1:
  version "1.0.2"
  resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"
  integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=

<EMAIL_ADDRESS>  version "0.4.23"
  resolved "https://registry.yarnpkg.com/xml2js/-/xml2js-0.4.23.tgz#a0c69516752421eb2ac758ee4d4ccf58843eac66"
  integrity sha512-ySPiMjM0+pLDftHgXY4By0uswI3SPKLDw/i3UXbnO8M/p28zqexCUoPmQFrYD+/1BzhGJSs2i1ERWKJAtiLrug==
  dependencies:
    sax ">=0.6.0"
    xmlbuilder "~11.0.0"

<EMAIL_ADDRESS>  version "11.0.1"
  resolved "https://registry.yarnpkg.com/xmlbuilder/-/xmlbuilder-11.0.1.tgz#be9bae1c8a046e76b31127726347d0ad7002beb3"
  integrity sha512-fDlsI/kFEx7gLvbecc0/ohLG50fugQp8ryHzMTuW9vSa1GJ0XYWKnhsUx7oie3G98+r56aTQIUB4kht42R3JvA==

<EMAIL_ADDRESS>  version "4.0.0"
  resolved "https://registry.yarnpkg.com/yallist/-/yallist-4.0.0.tgz#9bb92790d9c0effec63be73519e11a35019a3a72"
  integrity sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==

<EMAIL_ADDRESS>  version "3.1.1"
  resolved "https://registry.yarnpkg.com/yn/-/yn-3.1.1.tgz#1e87401a09d767c1d5eab26a6e4c185182d2eb50"
  integrity sha512-Ux4ygGWsu2c7isFWe8Yu1YluJmqVhxqK2cLXNQA5AcC3QfbGNpM7fu0Y8b/z16pXLnFxZYvWhd3fhBY9DLmC6Q==

@nulltoken I'm using same dependencies versions and I'm getting several dependency calls with names like these
'Azure.Storage.Blob.BlobClient-getProperties'
'Azure.Storage.Blob.BlobClient-downloadToBuffer'
Is there a specific telemetry event you are expecting?

@hectorhdzg  Thanks for getting back to me.

Is there a specific telemetry event you are expecting?

Hmmm. The repro code doesn't filter much...
const telemetryConsoleLogger = (envelope: Contracts.Envelope, _contextObjects?: {
  [name: string]: unknown;
}): boolean => {
  switch (envelope.data.baseType) {
    case "RemoteDependencyData": {
      console.log("## DEPENDENCY ######################################################");
      const data = envelope.data as Data<RemoteDependencyData>;
      console.log(data.baseData.data);
      console.log("########################################################");
      break;
    }

    case "ExceptionData": {
      console.log("## EXCEPTION ######################################################");
      const data = envelope.data as Data<ExceptionData>;
      data.baseData.exceptions.forEach(e => { console.log(e.message); });
      console.log("########################################################");
      break;
    }

    default:
      break;
  }

  return true;
};

I'm going to create a dedicated repository to hold the repro case to make it easier to troubleshoot.

@hectorhdzg Here it is: https://github.com/nulltoken/azure-storage-blob-repro-case
Any chance you could fetch it, fill it with a connection string, a container name, a blob path and see what's being pushed in the console?

@nulltoken thanks for the repro case, I can see the issue is regarding OpenTelemetry API mismatch, @azure/storage-blob is referencing an older version of @opentelemetry/api causing the issue, please install api manually to workaround this issue for now.
npm i @opentelemetry/api@latest
@richardpark-msft is currently working on updating OpenTelemetry dependencies across Azure SDKs so this issue will be automatically fixed when SDKs are updated

@hectorhdzg Thanks a lot for the quick feedback. ❤

please install api manually to workaround this issue for now. npm i @opentelemetry/api@latest

I'll test that out tomorrow and will report back here with my results.

@hectorhdzg 👍
diff --git a/package.json b/package.json
index 5011fd4..1e9c369 100644
--- a/package.json
+++ b/package.json
@@ -20,6 +20,7 @@
   },
   "dependencies": {
     "@azure/storage-blob": "^12.4.1",
+    "@opentelemetry/api": "^0.16.0",
     "@opentelemetry/tracing": "^0.16.0",
     "applicationinsights": "^1.8.10"
   }

did the trick!

@hectorhdzg I think this issue may now be closed. However, digging deeper, I've hit #13798 that might be related to tracing.

Thanks @nulltoken
Closing as requested
@richardpark-msft, @hectorhdzg, lets follow up in https://github.com/Azure/azure-sdk-for-js/issues/13798

I ran npm install @opentelemetry/api@latest but the tracing still does not work. Still disconnected components in application map. Is there anything else you have to do?

@hectorhdzg 👍
diff --git a/package.json b/package.json
index 5011fd4..1e9c369 100644
--- a/package.json
+++ b/package.json
@@ -20,6 +20,7 @@
  },
  "dependencies": {
    "@azure/storage-blob": "^12.4.1",
+    "@opentelemetry/api": "^0.16.0",
    "@opentelemetry/tracing": "^0.16.0",
    "applicationinsights": "^1.8.10"
  }

did the trick!

@hectorhdzg Hrmpf. It looks like upgrading dependencies to latest versions makes the "trick" regress.
Applying this patch brings us back to the initial position where storage accounts related dependencies were not logged
diff --git a/package.json b/package.json
index 1e9c369..ebd81fb 100644
--- a/package.json
+++ b/package.json
@@ -19,9 +19,9 @@
     "repro": "yarn node -r ts-node/register --unhandled-rejections=strict ./src/repro.ts"
   },
   "dependencies": {
-    "@azure/storage-blob": "^12.4.1",
-    "@opentelemetry/api": "^0.16.0",
-    "@opentelemetry/tracing": "^0.16.0",
+    "@azure/storage-blob": "^12.5.0",
+    "@opentelemetry/api": "^1.0.0-rc.0",
+    "@opentelemetry/tracing": "^0.18.2",
     "applicationinsights": "^1.8.10"
   }
 }

Did I mess up the upgrade?
FWIW, I've upgraded the repro repository would you need it for troubleshooting at https://github.com/nulltoken/azure-storage-blob-repro-case

@nulltoken give a try using OpenTelemetry API latest before release candidate version (0.18.1), you can see here that API RC version is still not compatible with other packages, we are waiting for version 1.0.0 to be available in OpenTelemetry to update all packages we own and hopefully this issue will not happen anymore.

@hectorhdzg :+1: Switching back @opentelemetry/api to 0.18.1 worked. Huge thanks!

@nulltoken And you don't get the #13798 problem?

@nulltoken And you don't get the #13798 problem? What dependency versions are you using?

@hectorhdzg Thanks for following up. I haven't tried it yet since switching to 0.18.1. Will test and keep you updated.


HBO Max, can´t change profile in extension

Extension only loads history from 1st profile on HBO Max account, no option to switch manually in extension.
Tried switching profile on HBO Max, no change. Tried restarting Firefox browser, no change.
Haven't tried Chrome extension since I don´t use Chrome.

I think that may because you already had a profile set. I created a new build last night and hbomax doesn't work at all as it just says your always logged out. By running through the debugger I can see the profile is never being set even though I'm logged in with a profile set.

I have the same problem, I tried to change in the HBOMAX service and it keeps getting just the first profile of HBOMAX.

I think that may because you already had a profile set. I created a new build last night and hbomax doesn't work at all as it just says your always logged out. By running through the debugger I can see the profile is never being set even though I'm logged in with a profile set.

Is this something you can fix on your own or do you need to involve HBO in it?
Let me know if you need any assistance testing this , I´ll gladly help in any way I can!
There is currently no other option to access history from HBO website or in the the app, and they have no plans to implement such a feature yet (Source: Contact with HBO Max Support while suggesting the feature).


Include PyBaMM solution in OptimizationResult

Description
Saves the latest pybamm solution object into a Problem class, to add into an OptimisationResult.
Issue reference
Fixes #548
Review
Before you mark your PR as ready for review, please ensure that you've considered the following:

Updated the CHANGELOG.md in reverse chronological order (newest at the top) with a concise description of the changes, including the PR number.
Noted any breaking changes, including details on how it might impact existing functionality.

Type of change

[x] New Feature: A non-breaking change that adds new functionality.

Key checklist:

[ ] No style issues: $ pre-commit run (or $ nox -s pre-commit) (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)
[ ] All unit tests pass: $ nox -s tests
[ ] The documentation builds: $ nox -s doctest

You can run integration tests, unit tests, and doctests together at once, using $ nox -s quick.
Further checks:

[ ] Code is well-commented, especially in complex or unclear areas.
[ ] Added tests that prove my fix is effective or that my feature works.
[ ] Checked that coverage remains or improves, and added tests if necessary to maintain or increase coverage.

Thank you for contributing to our project! Your efforts help us to deliver great software.

This is looking great - thanks @pipliggins! To ensure the pybamm solution matches the optimal parameter values, I would consider updating the code to run the forward model with the "x_best" values. The final optimisation position "should" be close to the found optimal, but there are cases where this doesn't occur (e.g. poorly tuned gradient-based methods, or population based optimisers that are exploring the search space in batches).


[darjeeling,lint] Darjeeling Lint fixes

Still needed more, much more....

CHANGE AUTHORIZED: hw/ip/lc_ctrl/rtl/lc_ctrl.sv
CHANGE AUTHORIZED: hw/ip/tlul/rtl/tlul_sram_byte.sv
This change only ties off unused signals that are not relevant for Earlgrey.

CHANGE AUTHORIZED: hw/ip/lc_ctrl/rtl/lc_ctrl.sv
CHANGE AUTHORIZED: hw/ip/tlul/rtl/tlul_sram_byte.sv
This change only ties off unused signals that are not relevant for Earlgrey.


Remove "send enabled" on marker removal and in bulk on 1.9.1 upgrade

Description
Remove the "send enabled" bank denom metadata in cases where a marker is deleted. Also add an upgrade handler (lava) that iterates through the "send enabled" metadata and removes it for any that is not associated with a marker.
closes: #819

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (see CONTRIBUTING.md)
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

It looks like linting is failing. Think you just have to run make lint
Here is the full documentation on it...
Please make sure to run make format before every commit - the easiest way to do this is have your editor run it for you upon saving a file. Additionally please ensure that your code is lint compliant by running make lint. A convenience git pre-commit hook that runs the formatters automatically before each commit is available in the contrib/githooks/ directory.

Is it possible to have a test for this?  Or is that not needed?

This could stand to have a simple test added for the removeSendEnabled flow...

Agree with @iramiller could add the keeper test.  I don't think we have a test flow for the upgrade handlers.

Test should have a denom that is valid (hash?) which is not removed ... that would show both code paths ... otherwise looks good.


Feature/dstar

Implementing Dstar path planner that can update planning around dynamic obstacles. Currently tested with already validated MPC controller using simulation.
Currently works for most cases when planning. Time cost appears to be good but should be further validated, and edge cases for planning when the robot is currently on an obstacle / there is no way to get there without running into an obstacle (both caused by error in SLAM) .
The MPC controller also needs some tuning (likely reduce the weight for going to the goal and increase the weight for staying on the path to prevent it from cutting extreme corners).
To run in simulation:
roslaunch lunabot_bringup sim.launch
roslaunch lunabot_nav nav.launch
In Rviz, publish a nav_goal topic on the map to set a new goal for the robot to plan to, and a path should show up (with the robot trying to follow the path).

Merged in #43


[teva-2087]Block destroy.yml workflow until deploy_app.yml completes

When a PR is closed soon after it has been created, it leads to a race condition between destroy.yml and deploy_app.yml.
destroy.yml is likely to complete first, but runs against non-existent infrastructure because it is still being spun up.
By the time deploy_app.yml spins up the infrastructure, there is no automated way of destroying the infrastructure subsequently.
Jira ticket URL
https://dfedigital.atlassian.net/browse/TEVA-2087
Changes in this PR:

Is there anything specific you want feedback on?

Review app deployed to https://teaching-vacancies-review-pr-3237.london.cloudapps.digital

Closing; testing PR

closing - test


demo for sub tags in xml file

Before the merge we need to create a new release of bitexpert/etcetera and then update the dependency in this PR.

Would it be possible to use . as separator instead of / ?
Background:

Consitency: In relations you already may access properties of already processed entities via from.xyz and to.xyz
I think / implies a path but the configuration is for the Extractor and not the Reader.

Writing 2 I'm not sure if this kind of translation should better belong to a reader config, which translates nested properties to flat ones which would then be extracted the same way like before since nesting itself belongs to a source structure and would not be applicable exctracting an excel file.
If you already map it before and use the “path property“ as an identifier for an already flattened property, everything is fine :-)


Added a resource for cursor positions

Adds a cursor position to a global CursorPosition resource on
CursorMoved events. Identified by its window id.
They get cleared upon window close events, otherwise it saves the last
event

Looks awesome! +1 to this, I've already needed to impl something similar in everything I've made with bevy thus far.

Fixed things mentioned in comments :+1:

Looks good!
It would be great to have a doc example as it's not always obvious how you get the WindowId, but that can be done later

Implemented further fixes based on the comments.

This is a solid impl (gratz on your first contribution!), but I think it is probably worth pointing out that this is already possible!
fn print_cursor_position(windows: Res<Windows>) {
    let window = windows.get_primary().unwrap();
    println!("{:?}", window.cursor_position());
}

And I do think this belongs on the window itself because it is directly correlated to the window.

Closing this based on my preference for the current impl (and a related discussion on discord).

@speakk please respond in #2373 for the relicense to MIT/Apache 2.0. Thanks!
Side note: If we get windows as entities, this should be moved to a component.


Fall back to initials when image load fails

When the provided image fails to load (URL doesn't exist or is inaccessible), the avatar could display the default content (initials).
Vue exposes a convenient @error event on this, so we could do <img :src="source" @error="displayInitials" />
Would you accept a PR on this?

Sorry, I just discovered there's actually an open PR for this already - https://github.com/eliep/vue-avatar/pull/64


Improve error checking and make sure migration tasks run

Closes: https://github.com/galaxyproject/cloudlaunch-ui/issues/25

@afgane Thanks for catching the typo. The main reason for splitting the method was because we need different task timeouts for restarting and healthchecks, and therefore, it was easier to control if they were different tasks.


Get current time with milliseconds precision.

Could you add some tests?

Can't know the current time number, so no better to compare it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Improve Namespace Support

Please describe the problem you have

As a cluster admin, I need the ability to run multiple instances of Contour in the same namespace.
As a cluster admin, I need the ability to run Contour in a namespace other than "projectcontour".

See this Slack thread of additional background.

It's possible to deploy multiple contours in the same namespace, or multiple contours in a namespace each. The operator will need to configure leader election carefully to make both these options work. You also need to configure how the data plane choses a contour to connect to.

In addition to https://github.com/projectcontour/contour-operator/issues/18#issuecomment-686782485, https://github.com/projectcontour/contour/issues/2122 must be resolved to support multiple contours per namespace.

xref: https://kubernetes.slack.com/archives/C8XRH2R4J/p1607972656129200

Is there a planned milestone for this issue?

@xpepermint this issue is blocked by https://github.com/projectcontour/contour/issues/2122 (unprioritized too). If this feature is important to you, can you please describe your use case in 2122?


bugfix: use sass variable for background color

Thanks for the heads up! :blush:

thank you very much for the quick merge ;-)


conda-forge package

Hello, I have a project that I publish on conda-forge that has a dependency to this package.
Since eval-type-backport is not available on conda, we can't publish our package.
Are there plans to make this available in conda-forge? It is a simple process: https://conda-forge.org/docs/maintainer/adding_pkgs/
I can also put it up there if you like.

Please put it up there.

@alexmojaki I created the recipe for conda-forge team's review.
I also added you as a maintainer next to my name, if you can go there and say you are willing to be on the maintainers list that'd be great.
https://github.com/conda-forge/staged-recipes/pull/25689
Cheers

It's live 🥳
https://anaconda.org/conda-forge/eval_type_backport

Thanks for taking care of this!


Russian translation

Thanks for great article!
Do you mind if I translate it to Russian with all credits (and send PR)?

Any progress?


Add Timeout option when processing PDF page

Feature request
Good morning,
There are some PDF documents, where it takes around 10-12 seconds to get the output. The issue comes when the PDF is not searchable and editable and in fact it is a 'PDF Image'. And for example, the resulting XML contains analysis regarding curves and lines.
I cannot add the PDF because it contains sensitive data, but I  attach the XML output.
Do you consider adding a Timeout option when processing a PDF page? And if it exceeds a certain threshold, you skip the page or break?
In our work, what we want to achieve is that if the time processing of a page with PDFMiner takes more than 10 seconds for example, we fall back to another service where we convert PDF to image and we continue with other processes after.
Thank you in advance.
xml_output.zip

Hi @EucliTs0,
In this case I would like to improve speed rather that adding a timeout option. But for a proper analysis and fix we need an example of the PDF, and you indicated that's not possible.
If you need the timeout anyway, you can implement it yourself. A PDF is structured in pages, and pdfminer.six also runs analysis per page. So you can loop over the pages and quit processing if it takes to long. E.g. combine the code from this SO post with the code to loop over pages:
   from pdfminer.high_level import extract_pages
   for page_layout in extract_pages("test.pdf"):
       for element in page_layout:
           print(element)

Does this answer your question?

Hello @pietermarsman ,
Thank you for your answer :+1:


Change _fix_chat_template in case a template has both endif and endfor

Fixes #1284.
When running the following code with unsloth at the current commit (4cbebe151d9c8f813e4e69be1d86a5657a44ee60) I
from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="OpenMeditron/Meditron3-8B",
    max_seq_length=4096,
    load_in_4bit=True,
)

I get the following error:
RuntimeError: Unsloth: The tokenizer `OpenMeditron/Meditron3-8B`
does not have a {% if add_generation_prompt %} for generation purposes.
Please file a bug report immediately - thanks!

This used to work definitely until the Qwen commit.
The problem is that the template has both an endif and an endfor, so the current code finds the wrong spot in the template with .index(). This is the old_template:
{% set loop_messages = messages %}{% for message in loop_messages %}{% set content = '<|start_header_id|>' + message['role'] + '<|end_header_id|>
'+ message['content'] | trim + '<|eot_id|>' %}{% if loop.index0 == 0 %}{% set content = bos_token + content %}{% endif %}{{ content }}{% endfor %}{{ '<|start_header_id|>assistant<|end_header_id|>
' }}

The PR should fix this by always taking what comes last, either endif or endfor.

@giuliabaldini Thanks for the PR and apologies on the delay!
@Erland366 Could you review this thanks :)

Sorry for the delay
I tested the PR on all Unsloth + meta-llama + Qwen + Mistral (assuming non-Unsloth model by default is not fixed) 7B/8B/9B instruct model and there's no issue. Logic seems good too

Thanks @giuliabaldini - apologies for the delay again!!


"Description cannot be approved" for translation

I'm having trouble with approving a translation which I've made for my own kata.
I click "approve", then "I'm sure" in the confirmation dialog, then this error shows up:

Description cannot be approved, recent changes from related record must be merged first.

As far as I understand, this is a merge conflict in the description, caused by changes in the original kata that happened after I've started working on the translation. However, I've found no way around it.
Expected behavior
Successfull automatic merge of the translation OR a better message about how to fix the error.
What I've tried
I've searched this error message on Google and among existing issues on Github. Found #2262, but it has no info about fixing the error itself.
To avoid conflict, I've also tried submitting different versions of the description:

The current description of the kata + one new language-specific paragraph.
The current description of the kata as is.
An older version of the description (so that "Diff" tab disappears on the translation page).

I've also had an idea to back up the translation locally, delete it and then create a new one, based on the final version of the kata. But apparently there is no way to delete this translation from drafts and start from scratch.

Translation process is known for its deficiencies and description merge conflicts are a major PITA when approving translations. AFAIK improvements ot translation process are prioritized quite high, but I do not know any more details.
As for your specific problem, you can try following:

Grab the most recent version of the description, be it from kata editor, or from freshly started, new translation (which will be later discarded).
Fork the translation which you are not able to approve.
Replace forked translation with the translation  obtained in the first step. Add language-specific paragraphs if necessary.
Publish the translation. Try to approve it, but I am not 100% sure if kata authors can approve their own translations. If not, let someone know at #help-translate channel.

In case of any further problems you can come to Codewars Discord: https://discord.gg/mSwJWRvkHA for more direct help.

Thank you for quick response, this method with forking heped. Approving your own translations works indeed, I've done it before with my other kata.
I'm marking my issue as resolved, although it still would be nice to see some tip on the site itself, without having to go to Github.


lightwalletd should retry failed attempts to talk to zcashd forever

Recently, lightwalletd has become more robust in the event that it has trouble communicating with zcashd -- for example, if you start lightwalletd and then start zcashd, the former retries enough times that it will wait for the latter to go through its usual startup (which takes a minute or two). But lightwalletd should probably retry forever, or nearly forever (longer than the time it would take for a support human to be notified over a long weekend and restart zcashd for example).
As part of fixing this, lightwalletd should return a status to any wallet requests that it can't fulfill (due to this communication problem) indicating with an appropriate level of detail what the problem is (zcashd just doesn't exist, versus I'm connected but it's not responding, versus it's in initial block download (IBD), etc.).
This will make lightwalletd much more robust in a deploy situation.
We should also work with @benzcash to see how these changes should interact with Docker deployments.

I was about to create an issue to request exposing an health check endpoint but found this Issue when I searched for HealtCheck.
Having support for this will be really useful for prod instances.

I was about to create an issue to request exposing an health check endpoint but found this Issue when I searched for HealtCheck.
Having support for this will be really useful for prod instances.

But lightwalletd should probably retry forever, or nearly forever (longer than the time it would take for a support human to be notified over a long weekend and restart zcashd for example).

It would be good to use exponential backoff to a very large limit (multiple hours).
Otherwise, if a misconfigured lightwalletd is deployed to thousands or millions of devices, it could DoS whatever servers its trying to connect to.

But lightwalletd should probably retry forever, or nearly forever (longer than the time it would take for a support human to be notified over a long weekend and restart zcashd for example).

It would be good to use exponential backoff to a very large limit (multiple hours).
Otherwise, if a misconfigured lightwalletd is deployed to thousands or millions of devices, it could DoS whatever servers its trying to connect to.


Create Flames-game in python cmd

Type of change

[x] Added new project

Changes proposed in this pull request

Project name :

Flames Game

Short description :

A python program to play the flames game on cmd. Program uses data structures like lists to achieve it's functionality.
Checklist

[x] The code is Python 3 compatible
[x] I have added relevant comments in my file to make code understandable
[x] I have added my project in a folder which includes all the necessary files

Please label this as hacktoberfest-accepted

Add documentation with images

Any updates ?


Refetch triggered when an unrelated query is made

(Apollo 2.4.6)
Not sure if this is a bug or a question 🙂
Given the following schema:
type Query {
  foo: Foo!
  bar: Bar!
}

type Foo {
  fff: String!
}

type Bar {
  bbb: String!
}

and two unrelated queries:
query Foo {
  foo {
    fff
  }
}

query Bar {
  bar {
    bbb
  }
}

the following test (mock web server omitted, but it enqueues the responses and fails immediately when a response was not enqueued) will fail due API call for Foo query being made.
@Test
internal fun `disjoint query makes network request`(): Unit = runBlocking {
  val apollo = buildApollo()

  val channel = Channel<Response<FooQuery.Data>>(capacity = Channel.UNLIMITED)
  val job = launch {
    apollo.query(FooQuery()).toBuilder()
      .responseFetcher(ApolloResponseFetchers.CACHE_ONLY)
      .build()
      .watcher()
      .refetchResponseFetcher(ApolloResponseFetchers.CACHE_FIRST)
      .toFlow()
      .collect {
        channel.sendBlocking(it)
      }
  }

  channel.receive() // wait for the first, empty response

  mockWebServer.enqueue(
    """{
    "data": {
      "bar": {
        "__typename": "Bar",
        "bbb": "bbb"
      }
    }
  }"""
  )

  apollo.query(BarQuery()).toBuilder()
    .responseFetcher(ApolloResponseFetchers.NETWORK_ONLY)
    .build()
    .await()

  delay(500) // Allow some time for Apollo to trigger stuff, for some reason

  job.cancel()
}

private fun buildApollo() = ApolloClient
  .builder()
  .normalizedCache(LruNormalizedCacheFactory(EvictionPolicy.NO_EVICTION), object : CacheKeyResolver() {
    override fun fromFieldRecordSet(field: ResponseField, recordSet: Map<String, Any>): CacheKey =
      (recordSet["id"] as? String).asCacheKey()

    override fun fromFieldArguments(field: ResponseField, variables: Operation.Variables): CacheKey =
      (field.resolveArgument("id", variables) as? String).asCacheKey()

    private fun String?.asCacheKey(): CacheKey {
      if (this.isNullOrBlank()) return CacheKey.NO_KEY

      return CacheKey(this)
    }
  })
  .serverUrl(mockWebServer.mockWebServer.url("/"))
  .dispatcher(immediateExecutorService())
  .okHttpClient(OkHttpClient.Builder().dispatcher(Dispatcher(immediateExecutorService())).build())
  .build()

Key pieces:

first query is made with CACHE_ONLY fetcher and a CACHE_FIRST refetcher.
wait until the first watcher emits empty data
second query makes a network request
first query attempts to (re)fetch the data

I'm not sure if this is by design, but it's pretty surprising behavior. Why does a completely unrelated query cause FooQuery watcher to refetch the data? On one hand it does make some sense (there is a cache miss), but on the other the data that FooQuery would watch didn't change. This becomes a bigger problem when we start watching several queries using CACHE_ONLY fetcher and a refetcher that allows network - I assume all of them will trigger a network call as soon as the cache is populated?

I think this is all related to the fact that query Foo doesn't know its dependentKeys before a request is successfully executed. That's the whole if (dependentKeys.isEmpty() refetch thing.
Thinking about it, I think we should be able to compute a first version of the dependent keys from the query alone, to restrict the false positives? In that first query above, we would start with something like CacheKey("QUERY_ROOT/foo"). And then update the dependentKeys once we get the response. I think that might work?

That'd make sense, but would still sometimes trigger the refetch when not needed, right? E.g. when some other query fetches foo { somethingElse }. I'm wondering if this is something that even needs fixing, what we want to do is to keep queries cache_only and only populate the cache from prefetches/network_only queries. Perhaps it'd work better for us to have a custom refetch fetcher that doesn't allow network access until the watcher has emitted at least once (which would be when another instance of this query with network_only is made)?

E.g. when some other query fetches foo { somethingElse }

Correct

Perhaps it'd work better for us to have a custom refetch fetcher that doesn't allow network access until the watcher has emitted at least once (which would be when another instance of this query with network_only is made)?

Wouldn't that defeat the fact that you want your first query to be cache_only ? If you're open to changing that, what about making the query with cache_first and the refetcher cache_only ? That'll ensure the network is only reached once?

I realized the refetcher must be cache_first, because otherwise we'd end up either with stale data (or no data, if the query emits response with null data) or having to manually make a network request regardless (which is something to consider). The benefit of network_only is primarily to keep unidirectional data flow, and queries that have side effects violate that. Practically, this also helps us in UI tests, where we enqueue responses and fail if a response we didn't anticipate was made. Splitting the actions into strictly observing and fetching helps a lot it understanding the data flow in the app.
My current understanding is that network_only fetches and cache_only queries should cover most of the cases. Ideally the refetches wouldn't have to happen at all, but in an off chance the schema and queries are structured such that it's not practical, then we allow refetches as the only way to keep the data consistent.

I realized the refetcher must be cache_first, because otherwise we'd end up either with stale data (or no data, if the query emits response with null data)

I am confused. If the query1 watcher is cache_only (both query and refetcher) and query2 is network_only, ultimately the watcher should receive the correct data ? Even if there are intermediate cache misses with null data ?

The first emission, yes. But after some data was emitted already, then when subsequent cache misses happen we'd have to either:

ignore intermediate cache misses with null data -> we'd have stale information
lose the data briefly when intermediate cache miss comes -> poor UX, as we use Apollo as the single source of truth and the data we observe is propagated to the UI

So the cache_only refetch strategy only works when fetching the data for the first time, but later on the cache misses complicate things. Hope I'm clearing things up a bit 🙂

Thanks for the details!

ignore intermediate cache misses with null data -> we'd have stale information

Right! If some other query3 that partially overlaps changes an id or adds to a list, the query1 watcher will not see the changes.
Thinking out loud: since you seem to have a concept of initial network query + subsequent incremental updates, could you potentially wait until the network_only query is done before starting the watchers?

since you seem to have a concept of initial network query + subsequent incremental updates, could you potentially wait until the network_only query is done before starting the watchers?

Yes, you're right. My conclusion is that this a pretty specific requirement and we should be able to implement it using the existing APIs. I was thinking about a custom response fetcher (/wrapper) which would be a CACHE_ONLY until the first cache hit and CACHE_FIRST afterwards, for example.
As for computing the initial set of dependent keys from the query - it's reasonable to limit unexpected network calls. Since there's still a chance for false positives and I now see that we'll need some custom handling here anyway, it's not impacting us anymore so feel free to close the issue (unless you want to keep it open to track this specific improvement). Thanks!

I'm not sure computing the initial set of dependent keys from the query is a good idea ultimately. In this scenario that queries a list of messages:
{
  messages {
    id
    content
    subject
  }
}

Changing the content/subject of a message will not trigger the refetch despite this being part of the query so that can be surprising.
Also, I learned iOS has the opposite default behaviour: if the cache is initially empty, they do not refetch on cache updates, which has another set of advantages and drawbacks.
Maybe in the end, what we want is an API that lets the users decide whether they want to refetch or not. I'll close this issue for now and we can reopen a new one once we have identified a good use case.


The name field is missing in the shapefiles

Seems the name field has been forgotten in the shapefilesmade through the OSM scheme, both the generic and thematic ones, despite it is obviously a must-have field for any extract.

See http://hot.geoweb.io/en/exports/45ac35c7-25f0-4024-ba5f-d09b54f1d009/ for fix (HDM Model) or http://hot.geoweb.io/en/exports/85818a60-8f92-4df4-ad4b-aa263965a9d9/ OSm Model.

looks good, but I find another unexpected result (see next issue)

Oh, your dev instance has a very old database (like more than 2 months) but this is not the case for the production one, right?

it has been deployed


The logo/image of the teaser/listing of a project is not displayed correctly

The logo/image in teaser and listing is not looking nice (maybe if the title isssue (#345) is solved, this will also be solved).
https://landportal.info/projects/
https://landportal.info/search/all/Sudan Rural Land and Governance Project?f[0]=bundle%3Aproject

fixed in 6b2e669ae6b65b19ae76a883edab4ead7d961be2


validate kafkauser annotations before creating csr

Description

Validate KafkaUser annotations before creating CSRs in kafkauser controller
Update koperator API to v0.28.6
Use the CertManagerSignerNamePrefix constant from the API package everywhere

Type of Change

[x] New Feature

Checklist

[x] I have read the contributing guidelines
[x] Existing issues have been referenced (where applicable)
[x] I have verified this change is not present in other open pull requests
[x] All code style checks pass
[x] New code contribution is covered by automated tests
[x] All new and existing tests pass

It would be nice to have this validation in webhook also. We already has a draft PR regarding validating webhook for kafkaUser. It would be nice to add this validation into that one. I will write a comment into that ticket.


Capture all logs?

Currently you can add a specific logger like so:
def pytest_logger_config(logger_config):
    logger_config.add_loggers(['default'], stdout_level='debug')
    logger_config.set_log_option_default('default')

Is there a way to simply capture all logs? In our codebase logs are created with import logging; logging.info() or use their own defined loggers. I would like to just capture everything that is logged inside of a test (including also for instance logs from a libraries' logger).

Empty name indicates root logger, like mentioned here:
https://pytest-logger.readthedocs.io/en/latest/usage.html#low-level-hooks
In your example, you can use '' instead of 'default' to add handlers to root logger:
def pytest_logger_config(logger_config):
    logger_config.add_loggers([''], stdout_level='debug')
    logger_config.set_log_option_default('')

Thanks! This captures all logs in the tests themselves, but not logs from imported modules (which are pip installed with -e flag). Is there a way to capture those as well? I would like to simply capture all stdout/err if possible.

Can you be more specific? I'm not sure whether there is any difference in logging depending on the way in which given module/package is installed. Perhaps you mean logs issued when the module is being imported, i.e. module-level code?

Thanks for your help. I didn't mean logs issued when the module is being imported. It turns out the logger that wasn't being logged was initialized inside of a fixture. I suppose pytest-logger scans all loggers after import-time so it couldn't see it. I have been able to solve the issue by initializing the logger at import-level instead of in the fixture.


Icons disappear when changing node name

In a nested Tree, when changing name of node like below, +/- icons disappear.
// node is a NodeModel instance
node.set('name', name);
node.save_changes();

I do know this can be resolved by calling NodeView's setOpenCloseIcon(),
but I would really like to know why this occurs in the first place.

I found the answer:
jstree defines the prototype of its node in the init stage, and here the 'jstree-icon jstree-ocl' class is used.
This does not have any icon related class.
$.jstree.core.prototype = {
		...
		_create_prototype_node : function () {
			...
			_temp1.className = 'jstree-icon jstree-ocl';
		...
		init : function (el, options) {
			this._data.core.node = this._create_prototype_node();
		...

When the name of node is changed, rename_node() -> set_text() -> redraw_node() is called inside jstree.
redraw_node() removes the existing node and creates a new node from the prototype to replace the existing node.
		redraw_node : function (node, deep, is_callback, force_render) {
				...
				node.remove();
				//node = d.createElement('LI');
				//node = node[0];
			}
			node = this._data.core.node.cloneNode(true);
		...

When rename_node() is called, any pre-set icon-related class is gone as the node element is replaced.
Thus, the user(ipytree) has to set it - Which exactly is what NodeView's setOpenCloseIcon() does.
Below is a node icon element with open icon related class added:
<i class="jstree-icon jstree-ocl fa fa-plus ipytree-style-default" role="presentation"></i>

So it seems to me that this problem is a bug.
I'll work on a PR to address this.

Opened #84 .


[TAN-0014] Add screenshots to readMe files

Add screenshots accordingly to show examples of the implemented code.

Maybe add gifs too


Implement random greedy descent Ising solver

Randomized greedy descent means that spins are addressed at random. This could mean several different things:

[1] Spins are selected uniformly at random on each update. This means that in a single sweep of N updates, less than N spins are updated (typically exp(-1)N are left untouched), this will typically lead to inferior performance as an optimization heuristic, but allows certain theoretical guarantees on behaviour (in particular, some pathologies like oscillation at low temperature can be avoided). This is also the mode that best matches the 'Glauber dynamics' notion from physics, the mode we should use for emulation of classical physical dynamics.
Spins are selected uniformly at random without replacement (per sweep).I.e. on each sweep we update all spins in a permuted order. For practical purposes this is very close to the above process, and can be more performant in optimization, particularly for small numbers of sweep.
Per anneal process (i.e. per sample) the ordering is determined by a random permutation. I.e. we have a fixed ordering of update but determined randomly.

By contrast one might consider two non-random orderings of high interest:

[2]  'Sequential ordering'. I.e we update all spins in the order 1:N (or lexicographically - e.g. default bqm ordering). Assuming people order their variables in a sensible manner (so that local variables have local labels, i.e. this is often achieved thoughtlessly) this method can (perhaps surprisingly) often outperform randomized ordering, since variables can flip sequentially in a correlated manner. If people know something about how to systematically search the space, they can exploit such a mode (by manually permuting their Hamiltonian). Such a mode is also useful for analysis, debugging and proof of concept.
'Colored ordering'. When a graph coloring is provided (heuristic or optimal doesn't matter), variables of equal color allow for parallel updating. If parallelization is not exploited at the hardware level, then this is basically equivalent to a special case of sequential ordering. Understanding colored ordering is important since alternative hardware platforms (like GPU) can make use of the conditional independence to improve latency.

In summary, the two most important generalizations of steepest greedy are probably [1] and [2] IMO. But accommodating other cases might be useful.

Note that the above comments also apply to variations upon dwave-neal. This might be considered a seperate feature request. dwave-neal currently uses sequential ordering, but could be generalized to accept random ordering.

Thanks @jackraymond. I considered some of these (along with a few other), but it's great to have a specific use case in mind when thinking which one to implement first (and how).

It's not an exhaustive list. I could definitely make regular use of [1,2] though.

I believe we should aim for a highly  efficient implementation that doesn't completely trash the guarantees of randomness.   This would puts the kibosh on [1] (a call to the system RNG inside a tight innermost loop is out of the question, if that's what you really meant)  and [2]  (fixed iteration order is most vulnerable to worst-case instead of average-case performance that randomness is supposed to guarantee).   I would also rule out the colored -node version due to the overhead costs of computing the coloring: greedy if you want to spend time finding a good-quality coloring, don't waste it on an approach that is going to stop at the first local minimum it finds.

To my mind the option of generating a random permutation of nodes, during initialization, then stepping through it in the innermost loop, offers the best combination of efficiency and randomized robustness.   For variety, each new sample could start at a random location in the permutation, and/or could incorporate random step sizes each time.  This would provide the desired variation among samples, and choosing the ``next'' node in the greedy iteration would take a couple nanoseconds for an array access instead of, idk, hundreds of microseconds for a system call?

I would be delighted if dwave-neal incorporated this amount of minimal randomness as well.   Back in the day Jamie and I observed huge performance swings in Neal depending on how those Google weak-strong cell pairs were laid out in qubit number order.  If the strong cell is west or north of the weak cell SA convergence is fast; but if otherwise convergence is slow.  I had thought Jamie had fixed that issue of non-randomness but apparently not.

Re: random number generator speed -- we don't have to hard-code it to a slow(er) one. We can use something like dwave-neal:
https://github.com/dwavesystems/dwave-neal/blob/0457d05e32a9d6afef87a85ce0cb2a136b7fa766/neal/src/cpu_sa.cpp#L24

Fast RNG is ok with me if you prefer it.   But some type of randomization is needed (i.e. a different computation path for each solution) to average out these extremes -- never best case but never worst case.   I don't know if you are planning to make this code public, but I would be uneasy publishing something that is claimed to be random but has a known back-door vulnerability due to fixed node order.   It's false advertising.

it still might be faster to pre-compute a permutation using fast RNG, then simply draw it from the array in the inner loop, I dunno.    Might be interesting to check.

Sure fast RNG is fine with me, as long as there is decent variation from sample to sample.
It might be worth checking whether it really is faster than building single permutation array and re-using it with only the overhead cost of array access.
From: Radomir Stevanovic @.>
Date: Tuesday, June 21, 2022 at 4:01 PM
To: dwavesystems/dwave-greedy @.>
Cc: Catherine McGeoch @.>, Comment @.>
Subject: Re: [dwavesystems/dwave-greedy] Implement random greedy descent Ising solver (#1)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Re: random number generator speed -- we don't have to hard-code it to a slow(er) one. We can use something like dwave-neal:
https://github.com/dwavesystems/dwave-neal/blob/0457d05e32a9d6afef87a85ce0cb2a136b7fa766/neal/src/cpu_sa.cpp#L24
—
Reply to this email directly, view it on GitHubhttps://github.com/dwavesystems/dwave-greedy/issues/1#issuecomment-1162275950, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMZDZKPU3WUJA7K6S6BL333VQINP5ANCNFSM4ME4DFTA.
You are receiving this because you commented.Message ID: @.***>

I guess given Jack's preferences maybe this should be a user parameter?

I believe we should aim for a highly efficient implementation that doesn't completely trash the guarantees of randomness. This would puts the kibosh on [1] (a call to the system RNG inside a tight innermost loop is out of the question efficiency-wise, if that's what you really meant) and [2] (fixed iteration order is most vulnerable to worst-case instead of average-case performance that randomness is supposed to guarantee). I would also rule out the colored-node version due to the overhead costs of computing the coloring. If you want to spend time finding a good-quality coloring, don't waste it on a greedy approach that is going to stop at the first local minimum it finds.

I don't see why slower speed would be a killer objection to [1], but it could be an argument against it being defaulted or being implemented as a first priority, particularly for optimization use cases. I think that following best-practice, common and simple conventions for randomness is more important. Particularly for comparison of classical dynamics and quantum dynamics, or for evaluation of pathological cases (those where randomization matters most). Obtaining a heuristic coloring can be achieved in O(N) operations, and for some common special cases (like coloring bipartite graphs, e.g. Chimera, RBM) the colorings are optimal. So I don't see that as a killer objection either.

Fair enough.  I want to use this code for benchmarking against the QPU.  I want to claim truthfully that this is a state-of-the art implementation that runs as efficiently as we (i.e. Rad) could make go.  I want to defuse any suspicion that D-Wave deliberately made it run slower than it should.   In the larger field of  classical solvers, Greedy is not going to win prizes for best solution quality''  ---  all it has going for it is speed at banging out samples.  So that should be optimized as much as possible.     At the same time, code that is advertised as implementing randomized greedy should be recognizably random, and return an appropriately  diverse distribution of solutions.   The closer to theoretical'' randomness the better,  unless the code produces massive slowdowns violating the first goal.  Using a fixed node traversal order seems like false advertising to me.

In my experience, on lattices and bicliques for a variety of models, a colored ordering is typically worse for heuristic optimization than a random permutation (because correlated block moves are obstructed) when evaluated on a per sweep basis. Using a fixed ordering, I can achieve a colored ordering by relabeling my variables, if I wanted to. I am not particularly interested in that use case, unless it is exploited at hardware level.

We do one bit flip per sweep. At each step (sweep) the best direction/dimension/variable is picked (by energy contribution) and flipped.
Parallel updates based on coloring sound nice, but I doubt we would see a significant speedup on graphs of our typical scale (~10k nodes).

One other place we need to consider the role of randomness is the case of tied energies in SGD. How is a tie broken when steepness is tied, we should as a minima document how this is done given that we often study models with degenerate energy levels (the source of ties). Several possibilities exist, probably the most natural random and systematic choices are : broken uniformly at random, broken systematically towards the highest (numeric rank) variable.

@mhlr expressed an interest in the case of select uniformly at random amongst spin flips conditioned on them lowering energy.
In my enumeration above, I was implicitely assuming that a selected spin is only flipped if it lowers energy.
[1] is equal to this case.
This brings up a question of how we judge conversion in [1], and also whether we allow zero-energy change flips.
If only downward energy flips are performed, then once we have touched every spin without a change of energy we are converged. In case [1] we need to perform more than 1 sweep to meet this criteria - since some variables with potential to reduce energy may not be touched.
Allowing equal-energy flips is more consistent with the physical dynamics interpretation - (i.e. limit of zero temperature metropolis or gibbs sampling). However, in this case we have no guarantees of convergence, so we might need to thing about this more.

I was thinking of only on-zero flips since I would like the process to self terminate.

@jackraymond, our current SGD implementation is detached from any physical interpretation (as long as we consider the Hamiltonian to be nothing more than a function we're minimizing). At each step, we pick the first dimension (in BQM variable order) that improves objective the most. We stop when we reach a (local) minimum.
If you think we need something more physics-inspired, we can consider generalizing simulated annealing sampler as well.

My presentation of methods was more suitable for the sweep based methods (simulated annealing). greedy routines can be considered a 'quenching' limit of an SA routine, but it was pretty unhelpful to do it that way.
My preferred implementation matches that of @mhlr [and matches [1] under a particular interpretation]. Keep a list of downward energy flips and select from it uniformly at random (adjusting set after each update).

Whether systematic or random tie-breaking applies, most important thing is to document. If only randomized were available, it is possible in general to recover the rank ordering behaviour by adding a perturbation on the bqm linear terms of the form eps*range(num_var), (eps small compared to all gaps) so the randomized ordering is sufficient for me.

@CatherineCMcGeoch, I think I'd rather keep the current SGD deterministic, and implement a new random greedy descent solver (as this issue was originally about). Makes sense?

Sure, whatever you like.  Are you going to keep the loop that sweeps through all n nodes?  To my mind this is a weird coding quirk that physicists enjoy.   In CS (greedy, SA, whatever) there is one loop that samples nodes in random order, flipping and updating on the fly.  I assume that the extra loop makes it easier to simulate natural processes, but it doesn't seem like a good idea efficiency-wise.

And I think the concept of implementing separate solvers rather than one highly parameterized version that pleases everybody, is a good idea too.  A broad-ranging benchmark test would want to try them all, anyway.

Red black trees!  I used to teach them!  Or sometimes splay trees, just to mix things up!    Though  I did see a talk a several years ago suggesting that plain vanilla BSTs typically work just fine in most applications.


data.history number of returned candles can sometimes not match the bar_count

This was originally reported in #230 but may have been lost due to number of comments.
The following:
data.history(['close', 'volume'], freq='5T', bar_count=1)
Should return 1 candle but it can sometimes (1 in 5 times or so) return 2 candles.
data.history(['close', 'volume'], freq='5T', bar_count=2)
Can sometimes return 3 candles.
This was tested on bitfinex and poloniex.

Thanks @gatapia for opening a separate thread.
I was able to reproduce this phenomena as well, we will address this.
Thanks

added to catalyst 0.5.4


"You must specify a width and height for the image" always warns message if image is inside

Hello. I just found that react-native always warns about image (inside <Text>) sizing even if width and height are set.
Example markup:
      <View style={styles.container}>
        <Text>
        	<Image
            source={{uri: 'http://facebook.github.io/react/img/logo_og.png'}}
            style={{width: 123, height: 123}}
        	/>
        </Text>
      </View>

Here is the warning:

This reproduces only on iOS at the moment.
Please check my sandbox where it is reproduced: https://rnplay.org/apps/iDvmwQ

https://github.com/facebook/react-native/blob/f7bcb3e98d489bb40ee8fd7dd69918521344f657/Libraries/Image/Image.ios.js#L228
It appears the above snippet can be removed, judging by this commit: https://github.com/facebook/react-native/commit/2cbc9127560c5f0f89ae5aa6ff863b1818f1c7c3

Looks like that snippet is indeed removed in master


Converting keras models to Caffe models

Hi
Sorry if the question is a little irrelevant, but I'm really stuck. How did you convert the keras models to Caffe models? Can you guide me to the right piece of code or converter? Thank you.

Sorry for the keras converter, I can't find the code.
There is no trick for me to convert a model for any source to caffe. I load the weight from the source model and write to the target caffe model based on an accurate deploy.prototxt. It requires patience and caution.

Hi
Where can I find the pre-trained caffemodel for inception-v4? I found the input size of inception-v4 is 299299, but my image set data is 256256, I don't have the space on my computer to convert it again. So could you please help me?

@zhujiapeng
You can find the download urls here https://github.com/soeaver/caffe-model/tree/master/cls.
And the input size problem please check https://github.com/soeaver/caffe-model/issues/11

@soeaver
蟹蟹!


Fails to create directory from gui

I created a project called billing and attempted to create a directory inside of it, but web ui fails.
I can see this traceback:
<IP_ADDRESS> - - [02/Jan/2018 17:34:11] "POST /new_tree_element/ HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1997, in __call__
    return self.wsgi_app(environ, start_response)
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1985, in wsgi_app
    response = self.handle_exception(e)
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1540, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1982, in wsgi_app
    response = self.full_dispatch_request()
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1614, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1517, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1612, in full_dispatch_request
    rv = self.dispatch_request()
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/flask/app.py", line 1598, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/golem/gui/__init__.py", line 580, in new_tree_element
    element_name, dir_type='suites')
  File "/Users/ndefosse/.virtualenvs/golem/lib/python3.6/site-packages/golem/core/io_manager.py", line 34, in new_directory
    utils.create_new_directory(path=path, add_init=True)

Stale. Closing.


Merging multiple strategies in one ?

Hello 👋,
One of the thing to explore is to merge multiple strategies in one to maybe get a better end results ?
Any ideas are welcome.

Hi, it would be awesome to merge all available strategies. I'll probably try to take a look at a basic implementation of a merging feature.
Given that we managed to introduce a NodeSecure standard vulnerability format, we could try to fetch everything at once and aggregate the results of each strategy hydratation. Imo the biggest challenge is to keep a consistent version of all vulnerabilities without introducing duplicated dependencies. What are your thoughts about that?

Still not sure what to do if we have two times the same CVE but with different criticity etc.. What do we pick then ? Like i feel at some point we have to say that some strategy have a higher priority for example.
Also they are not always working the same way.. merging probably mean being capable to abstract enough (could become dangerous with time and the addition of new strategies).

Closing this issue, I think that idea is quite hard to execute and probably not briging much value


update org.activiti.cloud.common:activiti-cloud-service-common-dependencies to 7.0.49

UpdateBot pushed maven dependency: org.activiti.cloud.common:activiti-cloud-service-common-dependencies to: 7.0.48

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.common:activiti-cloud-service-common-dependencies 7.0.49

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: igdianov:white_check_mark: jx-activiti-cloud:x: mergify-botmergify-bot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Investigate policy denials for cilium-health traffic

Seen in monitor.log output from failure in #5588 description:
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 0 from-host: 74 bytes, state new, identity 1->0
[2018-09-17 14:47:26] Ethernet	{Contents=[..14..] Payload=[..62..] SrcMAC=d2:52:c0:41:d7:b4 DstMAC=d2:52:c0:41:d7:b4 EthernetType=IPv4 Length=0}
[2018-09-17 14:47:26] IPv4	{Contents=[..20..] Payload=[..40..] Version=4 IHL=5 TOS=0 Length=60 Id=13360 Flags=DF FragOffset=0 TTL=64 Protocol=TCP Checksum=1807 SrcIP=<IP_ADDRESS> DstIP=<IP_ADDRESS> Options=[] Padding=[]}
[2018-09-17 14:47:26] TCP	{Contents=[..40..] Payload=[] SrcPort=34090 DstPort=4240 Seq=110212391 Ack=0 DataOffset=10 FIN=false SYN=true RST=false PSH=false ACK=false URG=false ECE=false CWR=false NS=false Window=29200 Checksum=65451 Urgent=0 Options=[..5..] Padding=[]}
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 0 DEBUG: Successfully mapped daddr=<IP_ADDRESS> to identity=1
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 0 DEBUG: Reverse proxy lookup sport=4240 dport=34090 saddr=<IP_ADDRESS> nexthdr=6
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 0 DEBUG: Attempting local delivery for container id 35617 from seclabel 1
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 0 DEBUG: Local container found ifindex cilium_health seclabel 0
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 35617 DEBUG: Conntrack lookup 1/2: src=<IP_ADDRESS>:34090 dst=<IP_ADDRESS>:4240
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 35617 DEBUG: Conntrack lookup 2/2: nexthdr=6 flags=0
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 35617 DEBUG: CT verdict: New, revnat=0
[2018-09-17 14:47:26] CPU 01: MARK 0xa902d52e FROM 35617 DEBUG: Policy evaluation would deny packet from 1 to 4

This seems surprising at first glance as usually the cilium-health endpoints have no policy applied. This could plausibly be a regression in 1.3.

Could be related to / cause of #5361 .

I don't understand why there is any policy enforced on this endpoint:
Policy get
:
 [
  {
    "endpointSelector": {
      "matchLabels": {
        "any:id.app1": ""
      }
    },
    "egress": [
      {
        "toCIDR": [
          "<IP_ADDRESS>/0"
        ]
      }
    ]
  }
]
Revision: 61

Never mind, PolicyEnforcement is Always:
PolicyEnforcement        always

Closing "not-a-bug", we can revise whether cilium-health should have special policy behaviour but it's consistent for such traffic to be dropped in this case.