feat: charm relation interfaces tests running on a schedule

Run charm relation interface tests on a schedule.
Changes

add back the --include and --keep-cache flags （originally they were in the comments) to the run_matrix script, which are useful for testing, especially running only one interface test.
a PR for pytest-interface-tester is done to read from interface.yaml instead of charms.yaml: https://github.com/canonical/pytest-interface-tester/pull/18
run tests on a schedule (temporarily weekly)
add two more flags --repo and --branch (with default values to this repo and the main branch) so that developers can test their changes before it's merged into the main branch. This approach mentioned in the doc here does not work because that test file is not used, but rather generated here.
tox -e fmt

Investigation
Interfaces with interface_tests

cos_agent
ingress
openfga
prometheus_scrape
saml
sdcore_config
smtp
tracing

Charms with Conftests

prometheus-k8s-operator
saml-integrator-operator
smtp-integrator-operator
tempo-k8s-operator
traefik-k8s-operator

Interfaces Use Charms with Conftests

forward_auth
ingress_per_unit
ingress
prometheus_scrape
saml
smtp
tracing

Interfaces Both Have interface_tests and Use Charms with Conftests
So, as a summary, currently, only tests for the following interfaces could run theoretically:

ingress
prometheus_scrape
saml
smtp
tracing

Manual Tests Result

ingress: pass.
prometheus_scrape: tests on: ['prometheus-k8s', 'loki-k8s', 'grafana-k8s', 'prometheus-scrape-config-k8s', 'prometheus-scrape-target-k8s', 'alertmanager-k8s', 'zinc-k8s']. All fail except prometheus-k8s (expected, which is the only charm with conftest). Note that prometheus-k8s also fails on mac because of an FileNotFoundError: [Errno 2] No such file or directory: 'update-ca-certificates'. It seems this mock didn't work.
saml: pass
smtp: fail, because of "ValueError: Multiple endpoints found for provider/smtp: ['smtp', 'smtp-legacy']: cannot guess which one it is we're supposed to be testing". I think because of this.
tracing: fail, it seems v0 doesn't exist, v1/v2 fail because of "RuntimeError('400 Bad Request: service "tempo-ready" does not exist')", thrown by here.

TODO

fix documentation errors
an example or at least a note on how to add tests for interfaces
figure out a way to send notifications for failed test cases

Thanks!
Where will the errors/output of this end up? Will we or someone be notified when there are failures?
Could you run this on your branch and show us an example of the output? I see the last run was over a year ago, and GitHub has pruned the logs.

Sample output for one interface, pass:
$ python3 run_matrix.py --include ingress
Failed to load module test_requirer: No module named 'test_requirer'
Failed to load module test_requirer: No module named 'test_requirer'
INFO:root:Running tests for interface: ingress
INFO:root:Running tests for version: v1
INFO:root:Running tests for role: provider
INFO:root:Running 4 ingress interface tests on: ['traefik-k8s']...
INFO:root:Running tests for ingress
INFO:root:Running tests for charm: traefik-k8s
INFO:root:Preparing testing environment for: traefik-k8s
INFO:root:Cloning: traefik-k8s from (https://github.com/canonical/traefik-k8s-operator@main)
INFO:root:Preparing venv for /tmp/charm-relation-interfaces-tests/traefik-k8s
INFO:root:Installing dependencies in venv for /tmp/charm-relation-interfaces-tests/traefik-k8s
INFO:root:Installed # Cryptographic primitives and recipes
# Code: https://github.com/pyca/cryptography
# Docs: https://cryptography.io/
# Deps: tls-certificates-interface
cryptography

# Handle merging of nested data structures in python.
# Code: https://github.com/toumorokoshi/deepmerge
# Docs: https://deepmerge.readthedocs.io/en/latest/
# Deps: charm
deepmerge

# An implementation of the JSON Schema specification
# Code: https://github.com/python-jsonschema/jsonschema
# Docs: https://python-jsonschema.readthedocs.io/
# Deps: traefik_k8s libs, tls-certificates-interface
jsonschema

# Lightweight k8s module
# Code: https://github.com/gtsystem/lightkube
# Docs: https://lightkube.readthedocs.io/
# Deps: charm, observability_libs
lightkube >= 0.8.1
lightkube-models >= <IP_ADDRESS>

# Operator Framework
# Code: https://github.com/canonical/operator/
# Docs: https://ops.rtfd.io/
# Deps: charm
ops >= 2.10.0

# the deps below are from PYDEPS and are needed here for the tox test envs
# Keep them in sync with pydeps!
importlib-metadata==6.0.0
opentelemetry-exporter-otlp-proto-http==1.21.0
pydantic>=2

cosl

INFO:root:Generating test file for ingress at /tmp/charm-relation-interfaces-tests/traefik-k8s/tests/interface
INFO:root:Running tests for /tmp/charm-relation-interfaces-tests/traefik-k8s
===================================================================== test session starts ======================================================================
platform darwin -- Python 3.11.8, pytest-8.2.2, pluggy-1.5.0
rootdir: /tmp/charm-relation-interfaces-tests/traefik-k8s
configfile: pyproject.toml
plugins: anyio-4.4.0, interface-tester-2.0.1
collected 1 item

../../../../tmp/charm-relation-interfaces-tests/traefik-k8s/tests/interface/interface_test_ingress.py .                                                  [100%]

======================================================================= warnings summary =======================================================================
lib/charms/traefik_k8s/v2/ingress.py:255
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:255: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("scheme", pre=True)

lib/charms/traefik_k8s/v2/ingress.py:262
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:262: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("port", pre=True)

lib/charms/traefik_k8s/v2/ingress.py:280
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:280: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("host", pre=True)

lib/charms/traefik_k8s/v2/ingress.py:286
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:286: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("ip", pre=True)

.interface-venv/lib/python3.11/site-packages/_pytest/config/__init__.py:1448
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/.interface-venv/lib/python3.11/site-packages/_pytest/config/__init__.py:1448: PytestConfigWarning: Unknown config option: asyncio_mode

    self._warn_or_fail_if_strict(f"Unknown config option: {key}\n")

tests/interface/interface_test_ingress.py::test_ingress_interface
  /var/folders/2j/5hwf_xns24z3hc6bmf268x340000gn/T/tmpkvddgiuz/charm-relation-interfaces/interfaces/ingress/v1/schema.py:37: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/

tests/interface/interface_test_ingress.py: 31 warnings
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/.interface-venv/lib/python3.11/site-packages/pydantic/_internal/_model_construction.py:273: PydanticDeprecatedSince20: The `__fields__` attribute is deprecated, use `model_fields` instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    warnings.warn(

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
================================================================ 1 passed, 37 warnings in 1.99s ================================================================
INFO:root:Result: PASSED
INFO:root:Running tests for role: requirer
INFO:root:No tests specified for ingress/requirer; skipping...
INFO:root:Running tests for version: v2
INFO:root:Running tests for role: provider
INFO:root:Running 5 ingress interface tests on: ['traefik-k8s']...
INFO:root:Running tests for ingress
INFO:root:Running tests for charm: traefik-k8s
INFO:root:Preparing testing environment for: traefik-k8s
INFO:root:Generating test file for ingress at /tmp/charm-relation-interfaces-tests/traefik-k8s/tests/interface
INFO:root:Running tests for /tmp/charm-relation-interfaces-tests/traefik-k8s
===================================================================== test session starts ======================================================================
platform darwin -- Python 3.11.8, pytest-8.2.2, pluggy-1.5.0
rootdir: /tmp/charm-relation-interfaces-tests/traefik-k8s
configfile: pyproject.toml
plugins: anyio-4.4.0, interface-tester-2.0.1
collected 1 item

../../../../tmp/charm-relation-interfaces-tests/traefik-k8s/tests/interface/interface_test_ingress.py .                                                  [100%]

======================================================================= warnings summary =======================================================================
lib/charms/traefik_k8s/v2/ingress.py:255
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:255: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("scheme", pre=True)

lib/charms/traefik_k8s/v2/ingress.py:262
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:262: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("port", pre=True)

lib/charms/traefik_k8s/v2/ingress.py:280
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:280: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("host", pre=True)

lib/charms/traefik_k8s/v2/ingress.py:286
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/lib/charms/traefik_k8s/v2/ingress.py:286: PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    @validator("ip", pre=True)

.interface-venv/lib/python3.11/site-packages/_pytest/config/__init__.py:1448
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/.interface-venv/lib/python3.11/site-packages/_pytest/config/__init__.py:1448: PytestConfigWarning: Unknown config option: asyncio_mode

    self._warn_or_fail_if_strict(f"Unknown config option: {key}\n")

tests/interface/interface_test_ingress.py: 49 warnings
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/.interface-venv/lib/python3.11/site-packages/pydantic/_internal/_model_construction.py:273: PydanticDeprecatedSince20: The `__fields__` attribute is deprecated, use `model_fields` instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    warnings.warn(

tests/interface/interface_test_ingress.py::test_ingress_interface
tests/interface/interface_test_ingress.py::test_ingress_interface
tests/interface/interface_test_ingress.py::test_ingress_interface
tests/interface/interface_test_ingress.py::test_ingress_interface
  /private/tmp/charm-relation-interfaces-tests/traefik-k8s/.interface-venv/lib/python3.11/site-packages/pydantic/main.py:1070: PydanticDeprecatedSince20: The `dict` method is deprecated; use `model_dump` instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.7/migration/
    warnings.warn('The `dict` method is deprecated; use `model_dump` instead.', category=PydanticDeprecatedSince20)

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
================================================================ 1 passed, 58 warnings in 1.72s ================================================================
INFO:root:Result: PASSED
INFO:root:Running tests for role: requirer
INFO:root:No tests specified for ingress/requirer; skipping...
+++ Results +++
{
  "ingress": {
    "v1": {
      "provider": {
        "traefik-k8s": true
      },
      "requirer": {}
    },
    "v2": {
      "provider": {
        "traefik-k8s": true
      },
      "requirer": {}
    }
  }
}

renaming interface.yaml to charms.yaml according to pytest-interface-tester, also see here.

This was done for better charmhub support. I couldn't easily see why the rename was important for that, but I assume it is for some reason. So probably we actually need to update pytest-interface-tester instead and not rename (there's a comment along those lines on that PR too).

After discussion, we decide to create issues for failed interface tests and assign them to owners. (Previously we wanted to use email notification; after discussion, we decided GitHub issues fit better.)
To create issues and assign them to owners, a map between interfaces to owners is required. This PR adds support to it, and see the discussion here for the rationale.
The changes in the current PR are tested in a separate repo. See the succeeded GitHub Actions workflow run here. This issue is created automatically by the GitHub Actions workflow and assigned to the owner of the interface. Issues won't be created for failed interfaces without owners in their interface.yaml definition.

All comments were resolved, and I also added the feature to use labels when searching for and creating issues.

Waiting for https://github.com/canonical/pytest-interface-tester/pull/19 to be merged first so that we can use pytest-interface-tester v3.1.0 directly instead of using a fork.

Updated lib version to pytest-interface-tester>=3.1.0 in pyproject.toml, test passed: https://github.com/IronCore864/charm-relation-interfaces/actions/runs/10348534960/job/28640972468, issues can be created and labeled: https://github.com/IronCore864/charm-relation-interfaces/issues/6.
Merging now.


zinit doesn't load completions until 'zinit creinstall' is run

Describe the bug
I have the setup below to call creinstall when zsh starts. But this takes a while (~12s).
zinit ice blockf atload'zinit creinstall -q .'
zinit light zsh-users/zsh-completions

If I just have the following block, the auto-completions for zi <tab> doesn't suggest desired options. I don't get the options cd, ls, status, report etc. Also, zi cd <tab> doesn't give the list of plugins installed.
zinit ice blockf atload'zinit creinstall -q .'
zinit light zsh-users/zsh-completions

zi times prints below:

6 ms - zsh-users/zsh-completions (with creinstall)
13299 ms - zsh-users/zsh-completions (without creinstall)

Calling creinstall seems to resolve the issue but it's too slow.
I'm loading zsh-completions after all the plugins.
Am I missing anything?
To Reproduce
Steps to reproduce the behavior.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
The print on the screen when the app loads with creinstall.

Versions:

$ZSH_VERSION == 5,8
Operating system name and version (uname -a): Linux 4.4.0-19613-Microsoft #1000-Microsoft Thu Apr 17 15:57:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux

Additional context
I'm running this on Ubuntu 20.x WSL.

For me completion does do work at all if I does not launch append atload'zinit creinstall -q .' (thanks for the tip by the way).

It seems to be much faster after I upgraded to wsl2.

I think that it should been atclone'zinit creinstall -q' atpull'%atclone', then it'll be fast.

If I do that, echo $INSTALLED_COMPS returns empty string.

You do not need to run zinit creinstall every time the plugin loads using atload. This installs the completions from fresh every time your plugin loads which can be slow. Once completions are installed they are stored to a cache and initialized in your current session via some sort of compinit call usually found at the end of your zshrc. More info on how to set that up can be found here: https://github.com/zdharma/zinit#calling-compinit-without-turbo-mode. The ices psprint is suggesting force the plugin to have its completions installed on clone and atpull(when the plugin updates), which are the only times it should be necessary to do so. $INSTALLED_COMPS is just a variable used to identify recently installed completions to my knowledge.

As per the doco, I've added the code below to .zshrc near the bottom after loading all the plugins.
autoload -Uz compinit
compinit

zinit cdreplay -q

Output of echo $INSTALLED_COMPS is still empty.

The issue with the $INSTALLED_COMPSbeing empty on plugin update has been resolved.

I tried it but still no good.


SVGScaler and SVGScaledRuler

introduced svgscaler, svgscaledruler, re-introduced svglib in requirements.txt and setup.py, old svglib folder renamed to _svglib until we're alright to delete. modifications to report_xml.py have been made to find out if svgscaler needs to be used or if a ruler tag is used

@elanfranconi Thank you 🥇


Time on Sign out page does not match actual time

Description
Time discrepancy between interface and system. Time is four hours in the future?
Steps to reproduce

Go to GC Forms
Sign in
Sign out
See time on page

Details

Browser: Edge
Operating system: Mac / Windows
Environment: Staging
Language: French
Viewport: Desktop / Tablet

Expected behaviour
Accurate time stamp?
Screenshots or videos

The time reflects correctly in Prod - this is a new bug introduced in Staging

Perhaps we can simply add timezone = UTC if this is a heavier lift?


Add tests for model.

Relevant classes have >95% coverage now

Codecov Report

Merging #201 (400b460) into master (903b703) will increase coverage by 3.31%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #201      +/-   ##
============================================
+ Coverage     74.00%   77.32%   +3.31%
- Complexity      770      808      +38
============================================
  Files            99       99
  Lines          2185     2187       +2
  Branches        311      311
============================================
+ Hits           1617     1691      +74
+ Misses          437      382      -55
+ Partials        131      114      -17

Impacted Files
Coverage Δ

...rc/main/java/seedu/address/model/ModelManager.java
91.48% <100.00%> (+8.03%)
:arrow_up:

...main/java/seedu/address/model/TransactionList.java
100.00% <100.00%> (+38.70%)
:arrow_up:

.../java/seedu/address/model/item/UniqueItemList.java
96.42% <0.00%> (+1.78%)
:arrow_up:

...n/java/seedu/address/commons/core/GuiSettings.java
73.07% <0.00%> (+3.84%)
:arrow_up:

src/main/java/seedu/address/model/BookKeeping.java
84.84% <0.00%> (+6.06%)
:arrow_up:

src/main/java/seedu/address/model/Inventory.java
98.43% <0.00%> (+7.81%)
:arrow_up:

src/main/java/seedu/address/model/item/Name.java
100.00% <0.00%> (+9.09%)
:arrow_up:

...a/seedu/address/model/order/TransactionRecord.java
91.66% <0.00%> (+13.88%)
:arrow_up:

src/main/java/seedu/address/model/UserPrefs.java
97.43% <0.00%> (+15.38%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

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


Editor Scene Tree Sprites Not Updated After Type Change

Godot version
v4.1.stable.official [970459615]
System information
Godot v4.1.stable - Windows 10.0.22000 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 SUPER (NVIDIA; <IP_ADDRESS>13) - Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 Threads)
Issue description
Unfortunately I can't find a way to get this to reproduce consistently, but sometimes when changing the type of an object, the editor sprite displayed for the object type will remain the same as the previous type. The type itself is properly updated. A video shows this problem. The object starts as a CharacterBody2D, with the properly displayed CharacterBody2D sprite. Then I change its type to be of Node2D. The editor sprite remains the CharacterBody2D one, though when we hover over the object, it correctly identifies its type as Node2D. Closing and re-opening the scene does not fix the editor sprite.
https://github.com/godotengine/godot/assets/4305699/583b4c1d-21c4-4be4-ad24-cf91b9e3746f
Steps to reproduce
I'm not entirely sure how to consistently reproduce this issue unfortunately. I've tried creating brand new scenes and changing their types and it seems to work fine when I do that. I've ran into this about 3-4 times in the past couple weeks now (all on 4.1) however.
Minimal reproduction project
None

Duplicate of #80733

Ah, sorry. I looked a bit for an existing issue but didn't see that one.

The images for the nodes are called "icons" that's probably what made the search confusing for you


SetJsonSerializerSettingsModifier method in ConnectionSettings class not working.

Branch 2.0.
The problem occurs when you don't provide your own IElasticsearchSerializer instance to ConnectionSettings constructor (which I never do).
The default serializer is getting created at base class (ConnectionConfiguration) here which creates new NestSerializer(this) here
After this point there is no way of changing json settings because they are used in NestSerializerconstructor only (which was already called).
Hope it will make sense to someone :smile:

It's almost like a circular dependency.
NestSerializer depends on settings (constructor requires it).
ConnectionSettings contains serializer (injected trough constructor or creates default new NestSerializer(this)).
Can't change the serializer after creating settings.
Can't change settings after creating serializer, because they are used only in constructor.

Closed via https://github.com/elastic/elasticsearch-net/pull/1703


Error TS6133: '$props' | '$setup' | '$options' is declared but its value is never read when building Vue SFC

Laravel Mix Version: 6.0.31
Node Version: 16.6.2
NPM Version: 7.20.3
Webpack Version: 5.53.0
OS: 5.10.63-1-MANJARO (Arch Linux)

Description:
In a fresh Laravel installation I have installed typescript
npm i -D typescript ts-loader

My tsconfig file is the following
{
  "compilerOptions": {
    // Project options
    "lib": ["esnext", "dom"],
    "removeComments": true,
    "target": "esnext",
    "jsx": "preserve",

    // Strict checks
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,

    // Linter checks
    "noImplicitReturns": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,

    // Module resolution
    "baseUrl": ".",
    "esModuleInterop": true,
    "moduleResolution": "node",
    "module": "esnext",
    "paths": {
      "@/*": ["resources/js/*"]
    },
  },
  "include": [
    "resources/js/**/*.ts",
    "resources/js/**/*.tsx",
    "resources/js/**/*.vue"
  ],
  "exclude": [
    "node_modules"
  ],
}

My webpack.mix.js file is the following:
const mix = require('laravel-mix');
const path = require('path');

mix.alias({
    '@': path.join(__dirname, 'resources/js')
});

mix.ts('resources/js/app.ts', 'public/js').vue({ runtimeOnly: true }

My entrypoint (renamed to app.ts):
import { createApp } from 'vue';

import Hello from<EMAIL_ADDRESS>const app = createApp({});

app.component('Hello', Hello);

app.mount('#app');

I have created the following Vue SFC
<script lang=ts>
import { ref, defineComponent } from 'vue'

export default defineComponent({
  name: "Foo",
  props: {
    myProp: {
      type: String,
      default: 'Hello'
    }
  },
  setup(props) {
    const msg = ref(props.myProp);

    return { msg }
  }
})
</script>

<template>
  <h1>{{ msg }}</h1>
  <input v-model="msg">
</template>

When I try to build my app I am getting the following errors
ERROR in /home/node/app/resources/js/components/ApplicationCreateForm.vue.ts(10,46)
      TS6133: '$props' is declared but its value is never read.
ERROR in /home/node/app/resources/js/components/ApplicationCreateForm.vue.ts(10,46)
      TS6133: '$setup' is declared but its value is never read.

Before upgrading the node_modules to vue 3.2.16 and ts-loader 9.2 I was able to build my app without problems using this tsconfig but after upgrading these errors came up.
I can suppress the errors by setting the noUnusedParameters option to false but I don't feel that this should be the solution
Steps to reproduce

Clone this repo https://github.com/iraklisg/vue-typescript
Run npm run dev

As stated in https://github.com/vuejs/vue-next/issues/4668#issuecomment-926687181 the following behavior also occurs

The error happens when I run npm run dev,
but doesn't happen when I run yarn dev, even though that runs the same script.
but when I directly run yarn mix (which yarn dev runs as well), the errors show up and the build fails.

It is very unlikely this is related to mix but I'll poke around to see what I can figure out

This consistently happens regardless of package manager used to install or run the scripts. It also happens when invoking mix directly using ./node_modules/.bin/mix. There was one case I saw where it did not happen. I cannot reliably reproduce the situation however which leads me to believe it's possibly a race condition in ts-loader causing it to not report errors in some instances.
In any case this has nothing to do with Mix.
The errors happen because of two things:

You have your project configured to error on unused function parameters: https://github.com/iraklisg/vue-typescript/blob/4496628ba4aeb44d42b720c5c0a9deddde232cab/tsconfig.json#L18

Vue SFCs in certain formats result in compiled code with unused arguments intended to be stripped by a production build process: https://sfc.vuejs.org/#eyJBcHAudnVlIjoiPHRlbXBsYXRlPlxuICA8aDE+dGVzdDwvaDE+XG48L3RlbXBsYXRlPlxuPHNjcmlwdD5cbi8vIHN0dWZmXG48L3NjcmlwdD5cbiIsImltcG9ydC1tYXAuanNvbiI6IntcbiAgXCJpbXBvcnRzXCI6IHtcbiAgICBcInZ1ZVwiOiBcImh0dHBzOi8vc2ZjLnZ1ZWpzLm9yZy92dWUucnVudGltZS5lc20tYnJvd3Nlci5qc1wiXG4gIH1cbn0ifQ==

In this case the inclusion of a non-empty <script> tag results in the unused parameters being added to the render function while a <script setup> block does not appear to produce the same results.


Will the supervised learning for predicting win/loss from Deepmind be posted?

Hi,
I was reading over the paper on StarCraft II: A New Challenge in Reinforcement Learning and I was wondering if the work from section 5 is/or is planned to be published?

We will publish another paper at some point, though I can't promise anything about when or what.


Can't run msc project. Finishes with error

dotnet run --project src/msc/msc.csproj samples/hello/hello.ms

The required type 'any' ('System.Object') cannot be resolved among the given references.
The required type 'bool' ('System.Boolean') cannot be resolved among the given references.
The required type 'int' ('System.Int32') cannot be resolved among the given references.
The required type 'string' ('System.String') cannot be resolved among the given references.
The required type 'void' ('System.Void') cannot be resolved among the given references.
The required type 'System.Object' cannot be resolved among the given references.
The required type 'System.Console' cannot be resolved among the given references.
The required type 'System.Console' cannot be resolved among the given references.
The required type 'System.String' cannot be resolved among the given references.
The required type 'System.String' cannot be resolved among the given references.
The required type 'System.String' cannot be resolved among the given references.
The required type 'System.String' cannot be resolved among the given references.
The required type 'System.Convert' cannot be resolved among the given references.
The required type 'System.Convert' cannot be resolved among the given references.
The required type 'System.Convert' cannot be resolved among the given references.
The required type 'System.Random' cannot be resolved among the given references.
The required type 'System.Random' cannot be resolved among the given references.
The required type 'System.Random' cannot be resolved among the given references.

I also ran into a problem and I managed to find a solution (simple, but not too beautiful). You should download netstandard.dll (2.0) and when compiling with msc.exe, explicitly specify a reference to the assembly (/r=netstandard.dll). The fact is that when importing types, msc searches for metadata among assemblies explicitly specified in the compiler parameters.
Minsk\CodeAnalysis\Emit\Emitter.cs:
var assemblies = new List<AssemblyDefinition>();

foreach (var reference in references)
{
    try
    {
        var assembly = AssemblyDefinition.ReadAssembly(reference);
        assemblies.Add(assembly);
    }
    catch (BadImageFormatException)
    {
        _diagnostics.ReportInvalidReference(reference);
    }
}

and then
var foundTypes = assemblies.SelectMany(a => a.Modules)
                           .SelectMany(m => m.Types)
                           .Where(t => t.FullName == metadataName)
                           .ToArray();
if (foundTypes.Length == 1)
{
    var typeReference = _assemblyDefinition.MainModule.ImportReference(foundTypes[0]);
    return typeReference;
}
else if (foundTypes.Length == 0)
{
    _diagnostics.ReportRequiredTypeNotFound(minskName, metadataName);
}
else
{
    _diagnostics.ReportRequiredTypeAmbiguous(minskName, metadataName, foundTypes);
}

In msc\Program.cs:
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using Minsk.CodeAnalysis;
using Minsk.CodeAnalysis.Syntax;
using Minsk.IO;
using Mono.Options;

namespace Minsk
{
    internal static class Program
    {
        private static int Main(string[] args)
        {
            var outputPath = (string?) null;
            var moduleName = (string?) null;
            var referencePaths = new List<string>();
            var sourcePaths = new List<string>();
            var helpRequested = false;

            var options = new OptionSet
            {
                "usage: msc <source-paths> [options]",
                { "r=", "The {path} of an assembly to reference", v => referencePaths.Add(v) },
                { "o=", "The output {path} of the assembly to create", v => outputPath = v },
                { "m=", "The {name} of the module", v => moduleName = v },
                { "?|h|help", "Prints help", v => helpRequested = true },
                { "<>", v => sourcePaths.Add(v) }
            };

            options.Parse(args);

            if (helpRequested)
            {
                options.WriteOptionDescriptions(Console.Out);
                return 0;
            }

            if (sourcePaths.Count == 0)
            {
                Console.Error.WriteLine("error: need at least one source file");
                return 1;
            }

            if (outputPath == null)
                outputPath = Path.ChangeExtension(sourcePaths[0], ".exe");

            if (moduleName == null)
                moduleName = Path.GetFileNameWithoutExtension(outputPath);

            var syntaxTrees = new List<SyntaxTree>();
            var hasErrors = false;

            foreach (var path in sourcePaths)
            {
                if (!File.Exists(path))
                {
                    Console.Error.WriteLine($"error: file '{path}' doesn't exist");
                    hasErrors = true;
                    continue;
                }

                var syntaxTree = SyntaxTree.Load(path);
                syntaxTrees.Add(syntaxTree);
            }

            foreach (var path in referencePaths)
            {
                if (!File.Exists(path))
                {
                    Console.Error.WriteLine($"error: file '{path}' doesn't exist");
                    hasErrors = true;
                    continue;
                }
            }

            if (hasErrors)
                return 1;

            var compilation = Compilation.Create(syntaxTrees.ToArray());
            var diagnostics = compilation.Emit(moduleName, referencePaths.ToArray(), outputPath);

            if (diagnostics.Any())
            {
                Console.Error.WriteDiagnostics(diagnostics);
                return 1;
            }

            return 0;
        }
    }
}

As you can see, there are no any automatic link for mscorlib.dll (or netstandard.dll in our case) as in csc.exe, so you should define reference manually. And also msc have no access to GAC, so you can't simply reference preinstalled assembly, you should specify the path to it.
The nice solution is referencing basic types in compiler via typeof(object) typeof(int) etc. and not via type name.


Remove calls to keys() for Joi schemas

Closes #249

Awesome! Thanks. If you're feeling up to it, we could use the same patch in Frame.

Done
jedireza/frame#183


Introduce !jinja data type in YAML

Proposal: jinja-data-type
Author: Dag Wieers <@dagwieers> IRC: dag
Date: 2018-03-23

Status: New
Proposal type: core design
Targeted Release: 2.7
Associated PR: ansible/ansible#49801
Estimated time to implement: 1 day

Motivation
Make it easier to use Jinja2 in YAML by avoiding quotes and curly brackets.
Problems
What problems exist that this proposal will solve?

YAML and Jinja2 are sometimes stepping on each other's toes

YAML parses values starting with curly brackets as a dictionary, so quotes are mandatory
Mandatory quotes introduce complexity, especially if the payload requires both single and double quotes
Avoid the confusion where people think a Jinja expression automatically turns into a string because it is quoted
The existing _when and until directives already introduce some ambiguity, expecting a Jinja expression. This ambiguity we could fix by endorsing the use of the !jinja tag.

Solution proposal

The introduction of a user-defined (local) data type in YAML using tag !jinja

Using !jinja is the shortest descriptive name, using !jinja2  or !j2 is not an option
This tag will flag a value as a Jinja expression
As such it does not require quotes (avoids triple quoting), or Jinja's standard {{ and }} delimiters (moustache overload)

The implementation would turn such data into a Jinja delimited string (lazy evaluation)
This proposal improves how users interact with Ansible:

It simplifies most Jinja2 usage in playbooks, inventories and vars-files (assignments and data manipulation)
It uses YAML the way it was designed to be without compromising on Jinja's functionality
A standard like this could become a wider standard endorsed by the Jinja project and others
It allows alternative template engines to be used concurrently
It enables syntax highlighters to highlight expressions from template engines

Current syntax
    host: '{{ inventory_hostname }}'
    cookie: "{{ result | regex_replace('^.*cookie=\"([^\"]+)\".*$', '\\1') }}"

New syntax (GitHub YAML syntax highlighter doesn't properly highlight tags)
    host: !jinja inventory_hostname
    cookie: !jinja result | regex_replace('^.*cookie="([^"]+)".*$', '\\1')

Dependencies (optional)

For clarity it helps if YAML syntax highlighters would indicate data-type tags clearer

Github YAML highlighter and Sphinx pygments fail here clearly
VIM, VSCode, Gedit all do this well

This proposal has no intention to deprecate any existing functionality related to Jinja2
This could be introduced together with Jinja's native environment in Ansible v2.7

Testing (optional)
Undoubtedly.
Documentation (optional)
No, documentation is not optional.
Anything else?
Let the bike-shedding begin.

I love this proposal! :tada:
Though I'd call it smth like !j2_expr to clearly indicate that it's an expression, not template string.
Just !jinja (or !jinja2, or !j2) would confuse me, since I'd think it expects a template. I think, it might be a good idea to introduce it, but make accept template string. This would improve readability as well.
Concerns:
Introducing multiple ways of doing the same might be harmful.

I recently suggested something like that, but IMHO !expr might be better, since it's independent from the templating language used. Like @webknjaz said, !jinja suggests a template.

I like how this proposal makes variable definitions / use look clear and uncluttered, and I like the idea of naming it !jinja (without a 2 and without underscores) because the name doesn't distract. While saying !expr is at least equally clear, the word "expr" may be a too general term.

I could even imagine just !e (or !j). That would make it significantly faster to type compared to "{{ }}"
Additionally I should mention @ingydotnet's PR to allow {{ ... }} to be unquoted: https://github.com/ansible/ansible/pull/36331
It's a kind of a hack, because {{ foo }} will be processed equal to this structure { { foo: null }: null } and then the constructor takes care that it will be loaded as the string "{{ foo }}". And foo now is a plain YAML scalar and is subject its syntax rules now.
But still an interesting suggestion that shows what you can do with PyYAML.

I think this is a very sound idea, altough I doubt the !jinja keyword a bit. It makes a non Pythionista a bit weary about Ansible . Of course you have to know Jinja2, but something like !expr with a !e shortcut seems better as far as I'm concerned.

Here are a couple thoughts:
From a YAML perspective, tags are meant to represent types, not transformations. This is:
- !age 42  # valid use of a tag to load an integer as an age object
- !upper foo  # invalid use of a tag to transform a value to an upper case string

One way to tell the difference... a value created from a loaded YAML tagged node, would be serialized (dumped) using the same tag. ie A foo object in memory is serialized using !foo, and !foo deserializes back into a foo object. A transform on the other hand, turns one value into another. For instance !join [a, b, c] might load as the string "abc", but the reverse would never be true.
YAML (as of 1.2) is a data serialization only language. There was never any intention to provide transforms. In 1.3 we are discussing adding annotations (similar to Python decorators) that are solely intended as transformations. They would look like @join('-') [a, b, c], which would load as "a-b-c"; or possibly @jinja foo | bar.
That said, 1.3 does not exist yet, and so it might be compelling to abuse tags for all sorts of transforms.
There is another solution besides explicit tags. Every unquoted scalar can be made to be implicitly typed. Ansible could be made to run any scalar that began with some certain char, to go through a transformation. For instance, every string that begins with \ (or any other valid character that would never appear in a normal value) could be considered Jinja. ie this \ foo | bar could be the same as "{{ foo | bar }}".
Here is some actual python code to make that work:
import re, yaml, json

yaml_text = r'''
key1: foo
key2: \bar  # instead of "{{bar}}"
'''

def jinja_eval(loader, node):
    # instead of jinja eval, just return upper for this demo:
    return node.value[1:].upper()

yaml.add_implicit_resolver(u'!jinja', re.compile(r'^\\'))
yaml.add_constructor('!jinja', jinja_eval)

print json.dumps(yaml.load(yaml_text), indent=2)

Which outputs this:
{
  "key2": "BAR",
  "key1": "foo"
}

You might even want to use something like << foo | bar >>.  In the jinja_eval, you would then just replace the <<>>with{{}}` )before jinja eval). This uses no quotes. As was already pointed out, quotes indicate the value will be a string, but the jinja evaluation might return a non string.
Food for thought.

@ingydotnet I disagree with "invalid use of a tag to transform". IMHO the distinction if something is a transform or simply a data type is not that easy, and "invalid" is a bit too strict.
It depends on the implementation if the tag survives a roundtrip.
To implement it strictly, one could load !e scalars as JinjaExpression objects.
Only when the expression is applied, it would retrieve the string saved in this object.
That way it would conform to what a tag is supposed to be.
If you look at it that way, there are already implicit !e tags tht are derived from the schema. For example, when and var in the following example already expect an expression and not a template. They will warn if you include {{ }} around it:
- debug:
    var: output.stderr   # implicit expression
  when: output.rc != 0   # implicit expression

If the implementation does a transformation in the custom constructor, then IMHO this would still be ok. In case of a roumdtrip (load and dump) the following playbook would end up like this:
# before
- set_fact:
    path: !e some_register.stdout

# after roundtrip
- set_fact:
    path: "{{ some_register.stdout }}"

Since we do not need roundtrips in ansible, and since the goal of this proposal is to make editing easier, I think this is not a reason to reject the proposal.

@ingydotnet Personally I'd prefer alternate delimiters too. The question is if it will break existing files.
I'm sure there are cases where plain scalars start with a backslash. I can't think of a use case where you'd have a scalar that starts with backslash+space, but probably somewhere there exists such a use case. Same question with << >>.

Ok, so let me chime in here.
@webknjaz @perlpunk Using !e or !expr, while shorter, is not helpful because it does not allow for other template engines or syntax highlighting. We really want to build something that can be reused by other projects and not do something that only makes sense in Ansible's context.
That rules out using alternate delimiters as well. And that's why a specific tag was proposed.
The remark that it doesn't explicitly state what follows is an expression was never a problem for _when or until directives, you simply have to know and the documentation has plenty examples (and even warns when improperly used). This would behave identically with !jinja. Anything more complicated will be hard to get people use it.
@ingydotnet I do not agree with the statement that this is an improper use of tags. We are not using !jinja for doing transformations. The tag is used to indicate that what follows is not just a string, it's a Jinja expression. (Pretty much the same as saying: it's not an integer, it's someone's birth-year), there's no transformation performed, and matches the YAML spec:

The tag property identifies the type of the native data structure presented by the node. A tag is denoted by the “!” indicator.

In that sense, Ansible uses the Jinja expression, like another program would use birth-year to calculate back the person's age.

@dagwieers @perlpunk I wasn't rejecting the proposal. I think an explicit tag of !jinja is probably a decent way to accomplish the goals.
I get what you are saying that the tag turns the string (conceptually) into a Jinja object, but jinja is a transformation construct here. I guess it depends on when the transformation is applied. If the Jinja object was preserved as such in memory, then sure, it could be roundtripped. Since Ansible probably doesn't want to reserialize the loaded object, the concern is moot.
Tags can also be (ab)used to do things like !include, !merge, !interpolate. I hope you would agree that (without bending the obvious intention) that these are transforms.
We are hoping to get support for transforms via "annotations" into YAML 1.3. So in that case, using tags for that purpose might be actually useful in the interim. This is what I was trying to get across.
re implicit tagging, unless there are plans to support alternate things like Jinja in the future (!mustache maybe), having some unique pattern imply the tag !jinja (which would also be allowed explicitly) might be nicer for the users.

@ingydotnet I got what you were saying. Claryfying:
Since ansible just loads the whole data structure and applies templating and expressions later, there are two basic ways of implementing it.
If you load it as a JinjaExpression object, then it will be able to survive a roundtrip, and as such, looks like a "valid" usage of a tag. But you have more work to implement this in the code where you apply the expression.
If you transform it to the string "{{ foo }}" during constructing, the information will get lost. That's not what tags were invented for, I agree.
The advantage is that implementation would be really easy.
Ansible is not used for serializing, and even if you have a use case where you want to load and dump an ansible playbook, it doesn't hurt that much to lose that information, since it will be turned into something which is functionally equal. (You would have to use the Ansible PyYAML loader, of course).
If the goal is a more general solution, it might be worth to use the first solution, though. Since Ansible already makes a distinction between strings that follow keys like var or when, there is already a kind of schema in use, just not at the constructor level.
So my point was that I wouldn't go as far as calling such usage "invalid" or "abusing tags".

Since Ansible probably doesn't want to reserialize the loaded object, the concern is moot.

@ingydotnet That was exactly my point ! But I appreciate your clarification.

i would make this function more like vault and 'tempalte on demand' when looking at a value of the object created by YAML.

@bcoca could you explain a bit more, or link to some examples? I'm not familiar with those things...

examples would look the same, basically anything !vault gets put into a 'ansible vault object' (AnsibleVaultEncryptedUnicode) which is then decrypted 'on access' but not on YAML parsing.

@dagwieers I'd insist on !j2_expr or !jinja_expr then.
To me, jinja is a template, not an expression inside of it's control flow syntax.
The point about documentation doesn't sound strong to me: yes, docs must exist, but I'm talking about the public interface being intuitive when read even w/o docs.
Abstract example/thoughts:
Imagine you can make your app rely on some weird useless env var FOO=bar and document that it won't run w/o it, but you still give user a proper error message, so that it's obvious what's wrong w/o going to docs. Also, you don't normally make your app to rely on unobvious things: you think about design first. Public API (naming of this tag in our case) is important here: you want it to be clearly understood by users regardless of whether they read docs.
Back to naming: everyone who've heard about jinja most likely knows that it's about templating. I'd rather not break this impression in their brains by misusing this name. That's why I want to be clear by communicating it to them via expr somewhere in tag name: dude, don't put a template here, it's explicitly an expression (while still processed by jinja).

@webknjaz I don't see your point. Same is true for _when and until directives. You need to know it requires a Jinja expression to use it. Examples make this clear, and if you do it wrong, Ansible will tell you. Naming is always a balance between descriptiveness and convenience.
Naming this !jinja_expr is a good way to kill this from a usability perspective. Just like fine people killed https://github.com/ansible/proposals/issues/74 Effectively killed by bikeshed. (this was too much like a programming language, result was already used too much, everything has to be prefixed with ansible_ so you end up with the proposal to use ansible_task_result.

Oh.. You speak about user writing that expression, but I take into account also one reading it. From the writer's perspective it's less useful than from point of view of the person who tries to understand what's going on in the playbook which already exists.
Also, YAML tags are also meant to represent some concepts from the tool it configures. They say it's a human-readable format, which is important here. Otherwise we'd end up writing configs in some kind of weird JSON, right?
I cannot agree that it's acceptable to rename expressions into templates, it's not: you confuse the reader this way, because it's unnatural to call things with words, which mean completely different.
I can see why you dislike !jinja_expr being long, but I don't insist on such prefix. I just want it to reflect it's purpose. That's all I want.

This was implemented in PR above, but in the end rejected by core team, as such, closing this discussion.


[9.x] Add "addRestoreOrCreate" extension to SoftDeletingScope

I would like to suggest adding addRestoreOrCreate extenstion to the IlluminateDatabaseEloquentSoftDeletingScope.
Following exampels are assumed that User model use SofteDelete trait.
before this PR

We need to check if user exists or not and do restore() or create().

$user = User::withTrashed()
    ->where(['email' =><EMAIL_ADDRESS>    ->first();

if($user) {
    $user->restore();
} else {
    $user = User::create([
        'email' =><EMAIL_ADDRESS>        'name' => 'user name',
    ]);
}

after this PR

We don't have to worry about if user exist or not.

$user = User::restoreOrCretae(
    ['email' =><EMAIL_ADDRESS>    ['name' => 'user name'],
);

Just a thought, shouldn't this be searched with onlyTrashed instead of withTrashed? Because otherwise the restore function is applied even to a record that hasn't really been deleted.


Jeb's Junkyard

Port of the JNSQ Cargo flights missions.  These will be from one or more airstrips to Jeb's recovering new junk to add to the yard.

[ ] Intro to the Junk business
[ ] Cargo flights 1 dst + 2 dst flights. cargo abstracted
[ ] Surface Salvage (need stock ships) - recover physical parts (small/med/large)


Returns reference not copy

For instance fetching some seldom changing data from the db caching it, then applying i18n to the result, pollutes subsequent cache fetches for the plain english result to be translated into another language.

See version 2.2.0  for the solution

After the issue #30 i revoked the version 2.2.0 due to the breaking change and made a major release 3.0.0 that will do the clone by default, but with an option to disable it.

Thanks ^_^


Human genome

I used HG002 Illumina data to evaluate the genome size and the repeat rate by using your method. I got the unexpectant result. the estimation genom size is<PHONE_NUMBER>,which lower than the expect genome size(expect  genome size 310000000).in addition,the repeat rate is up to 29%，I don't think it's possible. when i caculate repeat rate by Genome Repeat Length /Genome Haploid Length ,i dont know if this done is right? can you help me?

@jvhaarst @mschatz @fritzsedlazeck @hanfang

@jvhaarst @mschatz @fritzsedlazeck @hanfang

Thanks for your interest. HG002 is a male sample, so the estimated haploid
genome size will be the average of the maternal (1-22+X=3.031Gb) and
paternal (1-22+Y=2.932) contributions which is ~2.981Gb. So the estimate
here is quite accurate and is within 2% of expectation. While this is an
excellent estimate, a common issue is to not input the full kmer spectrum,
especially since jellyfish often truncates the distribution at 10000x
coverage. I would recommend rerunning with a very large limit (1,000,000)
so that every kmer is considered
Good luck
Mike
On Fri, Jan 15, 2021 at 6:38 AM zhoudreames<EMAIL_ADDRESS>wrote:

@jvhaarst https://github.com/jvhaarst @mschatz
https://github.com/mschatz @fritzsedlazeck
https://github.com/fritzsedlazeck @hanfang https://github.com/hanfang
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/51#issuecomment-760891750,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP347HC4W34WB5XGNEG6TS2ASMVANCNFSM4WD5V64A
.

Thanks for your interest. HG002 is a male sample, so the estimated haploid
genome size will be the average of the maternal (1-22+X=3.031Gb) and
paternal (1-22+Y=2.932) contributions which is ~2.981Gb. So the estimate
here is quite accurate and is within 2% of expectation. While this is an
excellent estimate, a common issue is to not input the full kmer spectrum,
especially since jellyfish often truncates the distribution at 10000x
coverage. I would recommend rerunning with a very large limit (1,000,000)
so that every kmer is considered
Good luck
Mike
On Fri, Jan 15, 2021 at 6:38 AM zhoudreames<EMAIL_ADDRESS>wrote:

@jvhaarst https://github.com/jvhaarst @mschatz
https://github.com/mschatz @fritzsedlazeck
https://github.com/fritzsedlazeck @hanfang https://github.com/hanfang
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/51#issuecomment-760891750,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP347HC4W34WB5XGNEG6TS2ASMVANCNFSM4WD5V64A
.

Thanks for your interest. HG002 is a male sample, so the estimated haploid genome size will be the average of the maternal (1-22+X=3.031Gb) and paternal (1-22+Y=2.932) contributions which is ~2.981Gb. So the estimate here is quite accurate and is within 2% of expectation. While this is an excellent estimate, a common issue is to not input the full kmer spectrum, especially since jellyfish often truncates the distribution at 10000x coverage. I would recommend rerunning with a very large limit (1,000,000) so that every kmer is considered Good luck Mike
…
On Fri, Jan 15, 2021 at 6:38 AM zhoudreames @.***> wrote: @jvhaarst https://github.com/jvhaarst @mschatz https://github.com/mschatz @fritzsedlazeck https://github.com/fritzsedlazeck @hanfang https://github.com/hanfang — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABP347HC4W34WB5XGNEG6TS2ASMVANCNFSM4WD5V64A .

thank you for your reply! i again runned the genomecsope combined with meryl software by using your recommend methond .the most important ,when I set k-values is 21,i got the Repeat rate is 29 %.but when i change the k-value=31,the repeat rate is 13%.so i dont know which is correct ,i want to know what the human repeat rate approximates,could you help me ?

Thanks for your interest. HG002 is a male sample, so the estimated haploid genome size will be the average of the maternal (1-22+X=3.031Gb) and paternal (1-22+Y=2.932) contributions which is ~2.981Gb. So the estimate here is quite accurate and is within 2% of expectation. While this is an excellent estimate, a common issue is to not input the full kmer spectrum, especially since jellyfish often truncates the distribution at 10000x coverage. I would recommend rerunning with a very large limit (1,000,000) so that every kmer is considered Good luck Mike
…
On Fri, Jan 15, 2021 at 6:38 AM zhoudreames @.***> wrote: @jvhaarst https://github.com/jvhaarst @mschatz https://github.com/mschatz @fritzsedlazeck https://github.com/fritzsedlazeck @hanfang https://github.com/hanfang — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABP347HC4W34WB5XGNEG6TS2ASMVANCNFSM4WD5V64A .

thank you for your reply! i again runned the genomecsope combined with meryl software by using your recommend methond .the most important ,when I set k-values is 21,i got the Repeat rate is 29 %.but when i change the k-value=31,the repeat rate is 13%.so i dont know which is correct ,i want to know what the human repeat rate approximates,could you help me ?

@mschatz

@mschatz

The repeat rate measures the fraction of kmers that are repetitive, so it
is entirely expected that the fraction would decrease as k gets longer: for
very short kmers, everything will be repetitive and for very long kmers
everything is unique. Here is a plot I made years ago on this rate for
several different genomes:
https://genome.cshlp.org/content/20/9/1165/F1.expansion.html
Good luck
Mike
On Mon, Jan 18, 2021 at 7:59 PM zhoudreames<EMAIL_ADDRESS>wrote:

@mschatz https://github.com/mschatz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/51#issuecomment-762536607,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP3472S5SH4BNFMNBYRO3S2TKQDANCNFSM4WD5V64A
.

The repeat rate measures the fraction of kmers that are repetitive, so it
is entirely expected that the fraction would decrease as k gets longer: for
very short kmers, everything will be repetitive and for very long kmers
everything is unique. Here is a plot I made years ago on this rate for
several different genomes:
https://genome.cshlp.org/content/20/9/1165/F1.expansion.html
Good luck
Mike
On Mon, Jan 18, 2021 at 7:59 PM zhoudreames<EMAIL_ADDRESS>wrote:

@mschatz https://github.com/mschatz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/51#issuecomment-762536607,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP3472S5SH4BNFMNBYRO3S2TKQDANCNFSM4WD5V64A
.


script tag 'kana' is listed twice

The OpenType script list has two entries for the script tag 'kana'.  The first entry is for "Hiragana", the second for "Katakana".  If this is correct, maybe these two lines should be merged into one?  Or should the script tag for "Hiragana" be 'hira'?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 49c1efc4-e864-0727-9663-7cec0ec4d9f1
Version Independent ID: 36ec4396-b9cb-cba9-1582-d8400296d249
Content: Script tags (OpenType 1.9 delta) - Typography
Content Source: typographydocs/opentype/spec/scripttags.md
Product: typography
GitHub Login: @PeterCon
Microsoft Alias: alib

Early in OpenType Layout history, the Unicode Hiragana and Katakana script properties were unified under the kana script tag. Given how long this has been the case, and the core functionality of the script tags in determining shaping engine paths, this is something that is unlikely to be changed now. The term kana is used collectively to refer to Hiragana and Katakana, so I think it is probably fine as is: there’s nothing wrong with having a tag that maps to more than one Unicode script (so long as there isn’t a situation in which one would want to implement script-level OTL differences).

Thanks for the clarification.  I wonder whether it would make sense to make this clear in the documentation, by replacing the current two kana lines with one combined line, e.g. saying "Japanese scripts (Hiragana+Katakana) - 'kana'"?

The OTL script tag registry is basically a mapping of tags to Unicode script property names, in which respect the current set up is correct. It has the benefit of allowing quick reverse lookups, i.e. finding the tag from the script name as well as the script name from the tag.

Great, thank you for your patient explanations.


[Bug] multiplying elements on XRC Export [sf#227]

Reported by hraban on 2017-12-18 15:34 UTC
If I export to XRC, at the first save everything’s ok, but every further save adds to the structure, e.g. each panel ends up "number of save" times in the output file.
wxGlade 0.8.0a9, Python 3.6.0, wxPython 4.0.0b2 on OSX.

Updated by dschwertberger on 2017-12-18 17:57 UTC

status: open --> pending
assigned_to: Dietmar Schwertberger

Commented by dschwertberger on 2017-12-18 17:57 UTC
Hi Henning,
thanks for reporting. This is also part of bug #224.A fix for this is in the repository.
As soon as the problem with the XRC parameters is fixed and also the Mac OS specific bugs, I will upload a new revision.

Updated by dschwertberger on 2017-12-18 19:15 UTC

status: pending --> closed

Commented by dschwertberger on 2017-12-18 19:15 UTC
Fixes are in 0.8.0a13, which is online now.


Using 4.0.0-b1 can't get access from my local IP.

I access my server via 192.168.x.x using 3.x.x .
But after upgraded to the 4.0.0-b1, it can't access anymore, double checked the firewall is open related port. Thanks.

Can you check which socket has the server bound.
What happens exactly? Do you get response when you make a request? Does the sever log anything?

Solved by launching the server using aqueduct serve -a <IP_ADDRESS>


Create volume from snapshot

What this PR does / why we need it:
**BP Create_Volume_From_Snapshot.
Special notes for your reviewer:
This is to implement volume creation from snapshots.
Release note:

Users can create volumes from snapshots.

@leonwanghui Rebased on development branch.

It seems that the unit test is not right, please take a look

Hi @lixiaoy1  The API document should be updated which is located in opensds/openapi-spec/swagger.yaml.

Coverage increased (+0.06%) to 43.71% when pulling c15f09b73da56f0412fb7ea6a12143102a042621 on lixiaoy1:snapshot into c524172e8ca036bd948ba1b0a126126bc741db44 on opensds:development.


Disable geolocation for iOS

Hi,
We're using flutter_inappwebview in one of our apps and would like to ask if this plugin automatically accesses geolocation api on iOS?
I found a way to disable geolocation on android but there are no details about iOS.

Facing the same issue. I use the HeadlessInAppWebView and the user gets the location prompt in my IOS app. I need to deactivate this. Did you found a solution?

ITMS-90683: Missing purpose string in Info.plist - Your app’s code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the “Runner.app” bundle should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. If you’re using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. For details, visit: https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources.
I don't use any location services in my app but currently I get this issue. the only place where the location permission is defined is in this library
so is it possible that this issue is because of this library?

I have the same problem App Store is reporting me about the permission NSLocationWhenInUseUsageDescription  but I´m not using it, there is a way to except that permission or lock it like android permissions?

@balaji101010  Did you fix it?


Update pr template

Added the requirement to include CS in review of content changes, other small updates.
QA: markdown formatting checked in editor.
No associated issue, small change.
Readiness

[x] Merge (pending reviews)
[ ] Merge after date or event
[ ] Draft

Overview
Why merge this PR? What does it solve?
Checklist
Optional. Add a 'x' to steps taken.
You can fill this out after opening the PR. "Did I..."

[x] Run spelling and grammar check, preferably with linter.
[ ] Avoid changing any header associated with a link/reference.
[ ] Step through instructions (or ask someone to do so).
[ ] Review for wordiness
[x] Match tone and style of page/section.
[ ] Run make linkcheck.
[ ] View HTML in a browser to check rendering.
[x] Use semantic newlines.
[x] follow best practices for commits.

[x] Descriptive title written in the imperative.
[x] Include brief overview of QA steps taken.
[x] Mention any related issues numbers.
[x] End message with sign off/DCO line (-s, --signoff).
[x] Sign commit with your gpg key (-S, --gpg-sign).
[x] Squash commits if needed.

[x] Request PR review by a technical writer and at least one peer.

Comments
Any thing else that a maintainer/reviewer should know.
This could include potential issues, rational for approach, etc.

Docs for c5995055b1561b12e84f3d8455f2c42c59289fd0 are browsable at: https://ci.foundries.io/projects/fio-docs/builds/2590/docs/artifacts/html/index.html


Support for Spring Boot gradle plugin configured in plugins DSL

When the liberty gradle plugin is currently added to a new Spring Boot Application initialized by the Spring Initializr, the libertyDeploy task fails with the following error:
Caused by: java.lang.NullPointerException: Cannot invoke method getArchiveBaseName() on null object 	at io.openliberty.tools.gradle.tasks.DeployTask.installProjectArchive(DeployTask.groovy:128)
I had a look into the source code and came to the following conclusion:
springBootTask initialized in the DeployTask.groovy by findSpringBootTask(project, springBootVersion) is initializes with null. Looking at the findSpringBootTask method in AbstractLibertyTask.groovy this can happen if the provided springBootVersion is null. Looking at the find findSpringBootVersion method defined in AbstractLibertyTask.groovy, which initializes the springBootVersion in DeployTask.groovy, the method relies on finding the dependency with name "spring-boot-gradle-plugin".
Analyzing project.buildscript.configurations.classpath.getAllDependencies() with the configuration generated by the Spring Initializr reveals that the name of the dependency is in fact org.springframework.boot.gradle.plugin:
DefaultExternalModuleDependency{group='org.springframework.boot', name='org.springframework.boot.gradle.plugin', version='3.3.1', configuration='default'}
To enable an error free task one has to replace the "org.springframework.boot" plugin defined in the plugins block with the plugin application apply plugin: "org.springframework.boot" as described on the org.springframework.boot plugin page.
As defining the plugin in the plugins block seems to be the more modern way of adding plugins to a gradle build, they at least call the plugin application legacy on the org.springframework.boot plugin page, and as the Spring Initializr sets up new Spring Boot projects with the org.springframework.boot plugin inside the plugins block, I would like to see the liberty plugin adding support for this. In addition there is documentation for the liberty plugin in the README to also be added inside of the plugins block, so the plugins block way seems to be supported by the liberty plugin too.
I would like to contribute by simply accepting org.springframework.boot.gradle.plugin as a valid name in addition to spring-boot-gradle-plugin. Let me know if this would be ok as a contribution.

@PatrickWalter214 Thank you for reporting this and for your thorough investigation. We welcome contributions to improve our plugins. The contribution would just need a new or modified test that proves the fix works, and you would need to provide the CLA as described in the CONTRIBUTING doc.

Fixed via #909


implement General Batch GEMM in Tensile

Tensile only support stride batch GEMM before this changes.
Our user request this feature to accept array of buffer pointer as input to do batched GEMM.
In order to do that and simply how rocblas call Tensile,
we also modify Tensile to accept offset argument and to support ldc!=ldd for all kernel.
We also need change in rocblas due to Tensile API is changed.

Update performance comparison between after change stride GEMM and original stride GEMM.
Update performance comparison between after change batch GEMM and after change stride GEMM.

compare.xlsx

@TonyYHsieh Please look into HostLibraryTests DataInitializationTest failures.  Thanks!

@TonyYHsieh Please look into HostLibraryTests DataInitializationTest failures. Thanks!

Hi Alex,
Thanks for reminder.
I have fixed it.


Version of CUDA (nvcc) must be 11.x

Thank you for your work.
After tests, some keywords only exist in the version 11.x of CUDA. For example, CUSPARSE_MV_ALG_DEFAULT in matrixCUSPARSE.cu.
So I hope the author can modify the Requirements in README for "CUDA (nvcc) v11". Thanks! :)

Hey @Housz , thanks for bringing this to my attention! I will look into it and open a pull request

Hey @Housz , instead, I updated the code to support both nvcc v11 and v12, such that the README should now be correct, let me know if you still have issues!


Make README.md consistent with changes in eaee308

eaee308
:) took me a moment to figure this out what was going on when I was seeing output looking like

[0x49f6a0 0x49f6a0]

 haha

Whoops, thanks!


Brainstorming replacing QA-Tiles

I need to rework my https://github.com/jremillard/images-to-osm project to use Mapbox tiles. The problem that label-maker is attempting to solve is right at the center of the planned rework. I just wanted to communicate what label-maker would look like if it was a perfect fit for my needs.
The input data (training ) to label-maker should be a set of geojson files. There is a rich and mature existing infrastructure of generating them from OSM and other data sources. They are easy to write code against in any language. Let other tools deal with it.
Label maker config would be

output zoom level OR a metric output (.5 m/pixel).
output image size for the training network (say 800x800), not an even tile boundary.
data augmentation options (center object, randomly slide object around, up/down, left/right flips, % scale change, edge buffer zone, allow clipped features, etc).
How many sample images to make.
training/validation split %.
Sat image TMS URL (someday support Bing when they can change the license).
Max sat image cache size, directory, also need max ago of sat image cache (mapbox is 30 days).
% of images to create that are negative samples (no objects in them).

The final output would be intermediate files (training, and validating), not the training images.
When the network is training, the intermediate files can be opened up, and single images can be generated on the fly from a python module. The python module would handle either fetching and forming the training images or getting them from the sat image cache. It would stitch the sat images together, crop them correctly, and output bounding boxes, segmentation masks, and instance masks. The one image at a time would allow data sets that don't fit into memory to be used, keep performance good, and not violate sat image caching licensing restrictions.
If you want to be really nice to people, have an option to write out MS COCO files, since basically everyone is using that data set right now for benchmarking.

training/validation split %.

I think when working with satellite imagery, it's important to have separate training and validation regions. If you just make a bunch of chips from some region and then randomly partition them, the validation chips may spatially overlap with some of training chips which will be "cheating".


Expression tree

This is the code to create and evaluate an expression tree. We can also arrange the tree in preorder, postorder and inorder

I think this code doesn't belong to this repo. Closing it.


Set the catch_exceptions value for the whole runner

I always pass catch_exceptions=True for all my test suites.
It would be convenient to configure this value once for all in CLIRunner for example.
For example, we could add a CLIRunner.catch_exceptions parameter, and make invoke use that value if not directly passed in parameter of invoke. Then I would just have to put the runner in a pytest fixture and that would do the thing for me.
If that is OK, I can open a PR for this.
What do you think?

Look like catch_exceptions=True is the default option, so you should not need to pass it in.

My bad, I meant the other way. I edit the OP.

Might make more sense to add the param to __init__, and default to None in invoke. If it's None, it will use whatever was set in __init__.


wrong unit conversion in QubitProperties

Information

qiskit-ibm-provider version: master
Python version:
Operating system:

What is the current behavior?
The units are converted incorrectly when inspecting backend properties.
Steps to reproduce the problem
> be = provider.backend.ibm_cairo
> print(be.qubit_properties(1))

IBMQubitProperties(t1=1.218373066365156e-10, t2=1.4429509238674746e-10, frequency=5.03578646292093e+18, anharmonicity=-3.441091441553652e+17)

This is all off. If you look at the raw json data you see that the correct values should be as follows.
IBMQubitProperties(t1=1.218373066365156e-4, t2=1.4429509238674746e-4, frequency=5.03578646292093e+9, anharmonicity=-3.441091441553652e+8)

Note that be.properties().frequency(1) is correct -- it's just be.qubit_properties() that is wrong.
I suspect that the conversion (multiplication by 1e9 for Gigahertz and by 1e-6 for microseconds) has been done twice somewhere.
The raw json data:
> be.properties().to_dict()['qubits'][1]

[{'date': datetime.datetime(2022, 7, 18, 0, 46, 48, tzinfo=tzlocal()),
  'name': 'T1',
  'unit': 'us',
  'value':<PHONE_NUMBER>365156},
 {'date': datetime.datetime(2022, 7, 19, 0, 30, 25, tzinfo=tzlocal()),
  'name': 'T2',
  'unit': 'us',
  'value':<PHONE_NUMBER>8674746},
 {'date': datetime.datetime(2022, 7, 19, 13, 1, 48, tzinfo=tzlocal()),
  'name': 'frequency',
  'unit': 'GHz',
  'value': 5.03578646292093},
 {'date': datetime.datetime(2022, 7, 19, 13, 1, 48, tzinfo=tzlocal()),
  'name': 'anharmonicity',
  'unit': 'GHz',
  'value': -0.3441091441553652},
 {'date': datetime.datetime(2022, 7, 19, 0, 26, 7, tzinfo=tzlocal()),
  'name': 'readout_error',
  'unit': '',
  'value': 0.006199999999999983},
 {'date': datetime.datetime(2022, 7, 19, 0, 26, 7, tzinfo=tzlocal()),
  'name': 'prob_meas0_prep1',
  'unit': '',
  'value': 0.007800000000000029},
 {'date': datetime.datetime(2022, 7, 19, 0, 26, 7, tzinfo=tzlocal()),
  'name': 'prob_meas1_prep0',
  'unit': '',
  'value': 0.0046},
 {'date': datetime.datetime(2022, 7, 19, 0, 26, 7, tzinfo=tzlocal()),
  'name': 'readout_length',
  'unit': 'ns',
  'value':<PHONE_NUMBER>444445}]

The instruction durations are converted correctly. e.g Measurement on qubit 1 is correctly reported as 732.44 nanoseconds when I look at
be.instruction_durations

I believe that's intended here we are converting to seconds and Hz.
To be consistent, we could get rid of these conversions
cc @rathishcholarajan

My understanding is that the base class recommends reporting in seconds and Hz https://qiskit.org/documentation/stubs/qiskit.providers.QubitProperties.html, do we want to override this in the subclass IBMQubitProperties ? @ajavadia @mtreinish

Yeah so the BackendProperties is already converting to seconds and Hz. So the conversions that @kt474 linked to are unnecessary, since they begin by getting info from backend.properties(), and are causing this double-conversion.


E0001 Error transforming template: Provided SourceAccessConfigurations cannot be parsed into a list.

CloudFormation Lint Version
0.65.1
What operating system are you using?
Mac
Describe the bug
I want to create a rabbitmq trigger lambda function with AWS SAM.
I wrote a list in SourceAccessConfigurations like this and I succeeded to deploy with cloudformation.
      Events:
        HelloWorld:
          Type: MQ
          Properties:
            Broker: !GetAtt HelloWorldBroker.Arn
            Queues:
              - HelloWorld
            SourceAccessConfigurations:
              - Type: BASIC_AUTH
                URI: !Ref HelloWorldSecret
            Enabled: true

But cfn-lint reported it's invalid.
The error message below is shown.
E0001 Error transforming template: Resource with id [HelloWorldFunction] is invalid. Event with id [HelloWorld] is invalid. Provided SourceAccessConfigurations cannot be parsed into a list.
template.yaml:1:1

Expected behavior
the error message shall not be shown.
Reproduction template
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: MQ + Lambda

Resources:
  HelloWorldSecret:
    Type: AWS::SecretsManager::Secret
    Properties:
      GenerateSecretString:
        GenerateStringKey: password
        PasswordLength: 32
        SecretStringTemplate: '{"username": "admin"}'

  HelloWorldBroker:
    Type: AWS::AmazonMQ::Broker
    Properties:
      AutoMinorVersionUpgrade: false
      BrokerName: !Sub "${AWS::StackName}-HelloWorldBroker"
      DeploymentMode: SINGLE_INSTANCE
      EngineType: RabbitMQ
      EngineVersion: '3.9.16'
      HostInstanceType: mq.t3.micro
      PubliclyAccessible: true
      Users:
        - Password: !Sub '{{resolve:secretsmanager:${HelloWorldSecret}:SecretString:password}}'
          Username: !Sub '{{resolve:secretsmanager:${HelloWorldSecret}:SecretString:username}}'

  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs16.x
      Architectures:
        - x86_64
      InlineCode: >
        exports.handler = async (event, context) => {
          console.log(JSON.stringify(event))
        }
      Events:
        HelloWorld:
          Type: MQ
          Properties:
            Broker: !GetAtt HelloWorldBroker.Arn
            Queues:
              - HelloWorld
            SourceAccessConfigurations:
              - Type: BASIC_AUTH
                URI: !Ref HelloWorldSecret
            Enabled: true

Outputs:
  HelloWorldEndpoint:
    Value: !Select [0, !GetAtt HelloWorldBroker.AmqpEndpoints]
  HelloWorldSecret:
    Value: !Ref HelloWorldSecret

reproduced with last few cfn-lint/aws-sam-translator versions:
https://github.com/aws/serverless-application-model/blob/a25933379e1cad3d0df4b35729ee2ec335402fdf/samtranslator/model/eventsources/pull.py#L279

SAM translator has been released and is updated with recent versions of cfn-lint


Fix gather_facts ignoring inventory variables

Small fix for gather_facts instruction. It now follows the conditions to trigger fact gathering.

Can you also add assisted installer looks like it was missed when adding the original flags.

@cdonatom Could you squash your commits into one here :)


Correct TLV type sent in xcCmdProcStaBlockICMPResponse()

Signed-off-by: Cedric Baudelet<EMAIL_ADDRESS>

Code review complete. Compilation OK


Bug: Remove get_lambda function from API Gateway proxy event

Expected Behaviour
The API Gateway v2 payload  doesn´t have any field called lambda and we should not have this in our Data Class.
Current Behaviour
Unecessary get_lambda function.
Code snippet
No code snippet

Possible Solution
Remove this and adjust tests/payload
@property
def get_lambda(self) -> Optional[Dict[str, Any]]:
    """Lambda authorization context details"""
    return self.get("lambda")

Steps to Reproduce
No necessary
Powertools for AWS Lambda (Python) version
latest
AWS Lambda function runtime
3.10
Packaging format used
PyPi
Debugging logs
No response

Adding update as it turned out docs were wrong, lambda key is always present; we only didn't do a good job in providing a consistent UX in getting Authorizer Context keys injected by Lambda Authorizers.

Potential solution discussed in today's sync:
from aws_lambda_powertools.utilities.data_classes.api_gateway_proxy_event import APIGatewayProxyEvent, APIGatewayProxyEventV2

a = APIGatewayProxyEvent({})
b = APIGatewayProxyEventV2({})

ctx: dict = a.request_context.authorizer.get_context()  # or get_lambda_context
ctx_two: dict = b.request_context.authorizer.get_context()  # or get_lambda_context

ctx.get("tenant_id")
ctx_two.get("tenant_id")


Make fullscreen go to the primary monitor under X11

This fixes #1408.
Prior to this change, fullscreen would always open on my second monitor (Ubuntu 14.10, dual head, nvidia driver). It looks like DefaultRootWindow(x11_display) is returning bad information and the XGetWindowAttributes() call should be using the x11_window variable like all of the other calls. But I've never done any X11 programming so I don't fully understand what's going on here.

Your guess is as good as mine on that one. Did you test your fix under LXDE or OpenBox? I put that code there for those desktop/wms.
BTW, someone on the devel mailing list wrote robust screen and window management for X11, but I don't see a pull request yet. https://github.com/hurikhan/godot/tree/x11-window-management

Yeah, this doesn't work. Ignore this pull.
The fact that it worked on my desktop at all was just luck. With a dual monitor setup, XGetWindowAttributes returns a huge width and height. Two 1920 monitors is reported as a single 3840x1080 display. In my case with one monitor rotated, the attributes come back with width and height of 3000x1920. When those are sent to XMoveResizeWindow, it tries its best to fit the window and fails (in my case by putting it on the 1080x1920 monitor).
I did end up trying it in LXDE and OpenBox and they have a related problem. In those desktops, the fullscreen Godot app stretches across both monitors instead of being isolated to the primary. That happens in 1.0 stable and the current dev without this patch.
I did some poking around and found some information about how SDL handles this. They test if the Xinerama extension is active and then query that to get the resolutions of the actual monitors:
/src/video/x11/SDL_x11modes.c
This looks like the path @hurikhan is going down. Unfortunately, integrating this into Godot is beyond my C++ skills. Hope this helps.


ENH: show TypeError when inheriting from a decorated class or repeate…

…d decorating

@GavinHuttley
Please review and merge these changes. If there is a merge conflict after merging your recent PR, I will fix it.
I don't know why I cannot select reviewer in the right hand side of the window.


Implement SOCKS5 proxy for remote DNS resolving.

Hi,
I like yo to merge this patch that enables remote DNS resolution through a SOCKS5 proxy. One use case is to support .onion name resolution through the TOR SOCKS5 proxy. The patch includes a minimal implementation and a test case.
Thank you,
Richard

Doesn't the JDK’s built-in socks proxy do this for us already? I'm uncomfortable shipping a complete socks proxy client in OkHttp without a substantial number of new tests

I'm going to close this for now because I'm not prepared to take on the maintenance cost of including our own socks proxy client. You can get this behavior by configuring OkHttp to use a custom SocketFactory.

Hi Jesse,
I definitely see your point. The JDK  includes a nice SOCKS-client implementation that is should be sufficient for most use cases (I checked with java-1.7.0-openjdk-amd64/jre/lib/rt.jar!/java/net/SocksSocketImpl.class). But when using okHttp on Android, somehow only a very limited SOCKS client (SOCKS4 only, no remote DNS) is available. So maybe I can rework this patch to use the Platform mechanism to make this SOCKS implementation Android-only.
Bolting on Socks5 support through a custom SocketFactory would mean that each Android app has to duplicate the effort of a custom implementation for a very common task (e.g. connecting through Tor). I do not think that is desirable...
So maybe I reduce the scope of this patch (Android only) and up the testing (what test cases do you like to see?) and so the overall impact of this patch should be very limited. What do you say?
See you,
Richard

Interested in creating a standalone GitHub project, like SocksSocketFactory or TorSocketFactory?
I actually would like to embed such a thing in OkHttp, but only after it gets some real-world exercise: which features do proxies expect? Is version negotiation necessary? Which versions?
And also, perhaps Android itself wants a Socks client. With ProxySelector you could automatically use the Proxy for all .onion URLs.

Interested in creating a standalone GitHub project, like SocksSocketFactory or TorSocketFactory?
I actually would like to embed such a thing in OkHttp, but only after it gets some real-world exercise: which features do proxies expect? Is version negotiation necessary? Which versions?

Well, I could spawn a new project for this. But I think I would limit the scope to SOCKS5 only, no authentication for now.
But if you want a proven, full-fledged implementation, maybe you could add a dependency to https://github.com/ravn/jsocks . It supports SOCKS4+5, authentication and so on...
Both would be fine with me.

And also, perhaps Android itself wants a Socks client. With ProxySelector you could automatically use the Proxy for all .onion URLs.

Well my usecase involves exactly that:
I liked a calendar app (https://gitlab.com/bitfireAT/davdroid) to support my self hosted owncloud server ( on a tor hidden service because of the easy setup without domain name registration, dyndns, etc.). So I added a CustProxySelector to this app, that automatically routes the tld .onion through tor:
public class CustProxySelector extends ProxySelector {
    //...
    @Override
    public List<Proxy> select(URI uri) {
        //.onion host, use Orbot socks proxy
            if (uri.getHost().endsWith(".onion")) {
                List<Proxy> proxyList = new ArrayList<>();
                Proxy proxy = new Proxy(Proxy.Type.SOCKS, new InetSocketAddress("<IP_ADDRESS>", 9050));
                proxyList.add(proxy);
                return proxyList;
            }
//...

public class HttpClient extends OkHttpClient {
//...
    protected HttpClient(Logger log, Context context) {
//...
      setProxySelector( new CustProxySelector(this.log,ProxySelector.getDefault()));
//...

But this required patching okHttp (that DavDroid uses) because:

okHttp resolves the hostname locally and that will not work with .onion
( see okhttp/src/main/java/com/squareup/okhttp/internal/http/RouteSelector.java:183 )
the Android socket implementation does not provide SOCKS5 support
which can be fixed by either

adding a handcrafted SOCKS5 socket implementation (that is what the first path includes)
adding a dependency on something like jsocks
fixing the socket implementation in Android directly (which seems quite unrealistic)

I'm thinking the easiest thing is for you to make a custom SocketFactory that calls through the minimal socks5 code in this PR. OkHttp will happily use that, and it can do Socks however it prefers.

Ok, I am fine with that, so the broken SOCKS implementation of Android needs to be fixed elsewhere. And for the remaining piece of the puzzle (deferring to resolve the hostname in RouteSelector.java:183), I created a separate PR: #2034
See you,
Richard


etcd restore fails after powering OFF all 3 nodes in a cluster and adding new nodes

Version: Master
Steps:

Create a 3 node custom cluster with all 3 roles in each with S3 backup configuration
Create few workloads/ingress
Create few backups B1/B2/B3 and check these backups are in S3
Power off all 3 nodes, wait for the cluster to become "Unavailable"
Add 3 new nodes with all 3 roles to the cluster
Perform a restore to B2

Restore does not complete and cluster is stuck in "Updating" state:

Rancher server logs below:
2019/03/08 02:22:55 [INFO] [addons] Successfully saved ConfigMap for addon rke-ingress-controller to Kubernetes
2019/03/08 02:22:55 [INFO] [addons] Executing deploy job rke-ingress-controller
2019/03/08 02:22:55 [INFO] [ingress] ingress controller nginx deployed successfully
2019/03/08 02:22:55 [INFO] [addons] Setting up user addons
2019/03/08 02:22:55 [INFO] [addons] no user addons defined
2019/03/08 02:22:55 [WARNING] Provisioning incomplete, host(s) [abcd,defg,hijk] skipped because they could not be contacted
2019/03/08 02:22:55 [INFO] Restarting network, ingress, and metrics pods
2019/03/08 02:22:57 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-9hc5l:m-482c89a768ce","addresses":["a.b.c.d"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-t7lrr","allNodes":false},{"nodeName":"c-9hc5l:m-482c89a768ce","addresses":["a.b.c.d"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-t7lrr","allNodes":false},{"nodeName":"c-9hc5l:m-0677f0fbcf56","addresses":["a.b.c.d"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-qgj47","allNodes":false},{"nodeName":"c-9hc5l:m-0677f0fbcf56","addresses":["1d.fg"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-qgj47","allNodes":false}]]
2019/03/08 02:22:58 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-9hc5l:m-482c89a768ce","addresses":["hijk"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-t7lrr","allNodes":false},{"nodeName":"c-9hc5l:m-482c89a768ce","addresses":["hijk"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-t7lrr","allNodes":false}]]
2019/03/08 02:22:58 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [null]
2019/03/08 02:22:58 [INFO] Finished restoring snapshot [c-9hc5l-bn7bk] on all etcd hosts
2019-03-08 02:23:00.916069 I | http: TLS handshake error from <IP_ADDRESS>:41248: EOF
2019/03/08 02:23:12 [INFO] kontainerdriver rancherkubernetesengine stopped
2019/03/08 02:23:12 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-9hc5l:m-e7648ce1fbb3","addresses":["1bcd"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-724bb","allNodes":false},{"nodeName":"c-9hc5l:m-e7648ce1fbb3","addresses":["1bcd"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-724bb","allNodes":false}]]
2019/03/08 02:23:12 [ERROR] ClusterController c-9hc5l [cluster-provisioner-controller] failed with : failed to get Kubernetes server version: Get https://11bcd:6443/version?timeout=32s: dial tcp <IP_ADDRESS>:6443: connect: no route to host
2019/03/08 02:23:12 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-9hc5l:m-a62724e491af","addresses":["xyza"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-96rld","allNodes":false},{"nodeName":"c-9hc5l:m-a62724e491af","addresses":["xyza"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-96rld","allNodes":false},{"nodeName":"c-9hc5l:m-e7648ce1fbb3","addresses":["1bcd"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-724bb","allNodes":false},{"nodeName":"c-9hc5l:m-e7648ce1fbb3","addresses":["1bcd"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-724bb","allNodes":false}]]

Also tried the below use case on master and the same behavior was observed as above:
Steps:
1.Create a 3 node custom cluster with all 3 roles in each with S3 backup configuration
2. Create few workloads/ingress
3. Create few backups B1/B2/B3 and check these backups are in S3
4. Power off all 3 nodes, wait for the cluster to become "Unavailable"
5. Add 3 new nodes with all 3 roles to the cluster
6. Delete the nodes powered OFF
7. Perform a restore to B2
Cluster is stuck in Updating state .
Rancher server logs below:
2019/03/08 05:41:48 [INFO] [addons] Successfully saved ConfigMap for addon rke-kube-dns-addon to Kubernetes
2019/03/08 05:41:48 [INFO] [addons] Executing deploy job rke-kube-dns-addon
2019/03/08 05:41:49 [INFO] [addons] kube-dns deployed successfully
2019/03/08 05:41:49 [INFO] [dns] DNS provider kube-dns deployed successfully
2019/03/08 05:41:49 [INFO] [addons] Setting up Metrics Server
2019/03/08 05:41:49 [INFO] [addons] Saving ConfigMap for addon rke-metrics-addon to Kubernetes
2019/03/08 05:41:49 [INFO] [addons] Successfully saved ConfigMap for addon rke-metrics-addon to Kubernetes
2019/03/08 05:41:49 [INFO] [addons] Executing deploy job rke-metrics-addon
2019/03/08 05:41:49 [INFO] [addons] Metrics Server deployed successfully
2019/03/08 05:41:49 [INFO] [ingress] Setting up nginx ingress controller
2019/03/08 05:41:49 [INFO] [addons] Saving ConfigMap for addon rke-ingress-controller to Kubernetes
2019/03/08 05:41:49 [INFO] [addons] Successfully saved ConfigMap for addon rke-ingress-controller to Kubernetes
2019/03/08 05:41:49 [INFO] [addons] Executing deploy job rke-ingress-controller
2019/03/08 05:41:49 [INFO] [ingress] ingress controller nginx deployed successfully
2019/03/08 05:41:49 [INFO] [addons] Setting up user addons
2019/03/08 05:41:49 [INFO] [addons] no user addons defined
2019/03/08 05:41:49 [INFO] Finished building Kubernetes cluster successfully
2019/03/08 05:41:49 [INFO] Restarting network, ingress, and metrics pods
2019/03/08 05:41:53 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [null]
2019/03/08 05:41:53 [INFO] Finished restoring snapshot [c-j7mx8-xk65x] on all etcd hosts
2019/03/08 05:41:53 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [null]
2019/03/08 05:42:02 [INFO] Handling backend connection request [c-j7mx8]
2019/03/08 05:42:06 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false},{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false}]]
2019/03/08 05:42:06 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false},{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false},{"nodeName":"c-j7mx8:m-6936a55dbc2c","addresses":["z.x.y.z"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-2pcqd","allNodes":false},{"nodeName":"c-j7mx8:m-6936a55dbc2c","addresses":["z.x.y.z"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-2pcqd","allNodes":false}]]
2019/03/08 05:42:06 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false},{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false},{"nodeName":"c-j7mx8:m-6936a55dbc2c","addresses":["z.x.y.z"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-2pcqd","allNodes":false},{"nodeName":"c-j7mx8:m-6936a55dbc2c","addresses":["z.x.y.z"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-2pcqd","allNodes":false},{"nodeName":"c-j7mx8:m-85020dcbd1fe","addresses":["d.e.f.g"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-7cz76","allNodes":false},{"nodeName":"c-j7mx8:m-85020dcbd1fe","addresses":["d.e.f.g"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-7cz76","allNodes":false}]]
2019/03/08 05:42:06 [INFO] Updating workload [ingress-nginx/nginx-ingress-controller] with public endpoints [[{"nodeName":"c-j7mx8:m-85020dcbd1fe","addresses":["d.e.f.g"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-7cz76","allNodes":false},{"nodeName":"c-j7mx8:m-85020dcbd1fe","addresses":["d.e.f.g"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-7cz76","allNodes":false},{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false},{"nodeName":"c-j7mx8:m-31afe56209de","addresses":["a.b.c.d"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-dg2wc","allNodes":false},{"nodeName":"c-j7mx8:m-6936a55dbc2c","addresses":["z.x.y.z"],"port":80,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-2pcqd","allNodes":false},{"nodeName":"c-j7mx8:m-6936a55dbc2c","addresses":["z.x.y.z"],"port":443,"protocol":"TCP","podName":"ingress-nginx:nginx-ingress-controller-2pcqd","allNodes":false}]]
2019/03/08 05:42:29 [INFO] kontainerdriver rancherkubernetesengine stopped
2019/03/08 05:42:29 [ERROR] ClusterController c-j7mx8 [cluster-provisioner-controller] failed with : failed to get Kubernetes server version: Get https://IPofthedeletednode:6443/version?timeout=32s: net/http: TLS handshake timeout

Its still looking for one of the powered off nodes .

Tested with master build from March 10th.
Steps:
1.Create a 3 node custom cluster with all 3 roles in each with S3 backup configuration
2. Create few workloads/ingress
3. Create few backups B1/B2/B3 and check these backups are in S3
4. Power off all 3 nodes, wait for the cluster to become "Unavailable"
5. Add 3 new nodes with all 3 roles to the cluster
6. Delete the nodes powered OFF
7. Perform a restore to B2
Restore was successful. Cluster was functional, also created new workload/ingress.
@moelsayed: After new nodes were added, we had a message in the UI suggesting users to perform restore to bring the cluster to active state. I don't see that message after the recent fix. Can we add that message? That would be helpful.  Right now the cluster is in "Updating" state with a message like this:
Failed to get Kubernetes server version: Get https://a.b.c.d:6443/version?timeout=32s: can not build dialer to c-xxzhx:m-01487410bee1

Closing this as the main issue is fixed. The related issue is tracked here https://github.com/rancher/rancher/issues/18791