New Management Library for Security Insights (Sentinel)

@markcowl  the mgmt.yml file has securityinsights.

I added the securityinsights_resource_manager.txt

@dicolanl There is a reported error in project references - restarted in case this is transient

@dicolanl  A few too many changes to the management yml, otherwise, this is ready to merge.


fields.py

I think in fields.py you want it to say
self._crypter = keyczar.Crypter.Read(keyname)

otherwise this does not make sense
def crypter(self):
    return self._crypter

return self._crypter really refers to self._crypter = self._crypter_klass(self.keydir) which then refers to self._crypter_klass = kwargs.pop('crypter_klass', KeyczarWrapper) which is what is referring to self.crypter = keyczar.Crypter.Read(keyname)
Going to try and explain that more clearly: return self._crypter is returning a crypter class that could be either a custom class given as a kwarg or defaulting to KeyczarWrapper. KeyczarWrapper specifically defines its crypter as Google's keyczar but a custom class could define its own crypter.
The EncryptedFieldMixin takes whichever crypter it's given, whether custom or default, and assigns it as a "private" instance variable, specifically self._crypter_klass.
self._crypter is another private class variable that instantiates the assigned self._crypter_klass with a filesystem location (self.keydir) for the encryption key.
def crypter(self) simply returns the assigned self._crypter, seemingly to explicitly define the crypter syntatically with parentheses, reflecting that self._crypter is an instantiated object belonging to the mixin with its own methods, hence self.crypter().decrypt(value)
All in all, this makes sense to me because self.crypter in KeyczarWrapper is not a "private" class variable and therefore should not have an underscore. self._crypter in EncryptedFieldMixin should have an underscore because it's only used within that class and is not intended to be used as an public attribute of the mixin.

Note: I did not write any of the code under discussion. I have been job hunting and trying to explain helps keep me sharp for whatever might come up. Apologies for the verbosity. Happy to hear why I'm wrong, also.


Make failing to check return value emit a warning

Non-void return values that go unused should produce a hard error, forcing the programmer to check either use or explicitly discard the values. This is an easy way to make sure that operations that could fail, such as std::file::close are properly checked.

Added in ecfcf53d81ad7e0cdd2400a772ed52b9ec422943.

Re-opening since this was reverted in 652fa56c9e1a3a3d70cf515134eb0c6e8038e03d. Look into making a tool such as sunder-lint to do this sort of check.


Add examples of web safe fonts

[ x] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[x ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@ALucatero03  Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Semver scheme

I would really reconsider the decision about converting options to pointers. It's not a common way.
But please, follow the Semver scheme. This was backward-incompatible change, but only minor part of the version number changed. My glide update just broke the CI pipeline :D
I meant this commit: 4f1f8d2b5b095a5e718e3658602598890f4ec746.

As to #29: we can still use non-pointer types for options, but provide pre-filled structs to json.Marshal to fill default values. That's a much better option than converting all the options to pointers.
See this example.

@dobegor I'm very sorry this update broke your CI pipeline! I know SemVer and we are actually using it as advertised. Please consider the following: http://semver.org/#spec-item-4
So until we release version 1.0.0, any minor update can represent potentially breaking changes or otherwise big improvements/additions. While any patch updates represent either bug fixes or small new features. Both of which should be 100% backwards compatible.
Since you changed the title of this issue, may I assume you find the correct way to work with the various constants in the package?
And lastly about your suggestion for using pre-filled structs... I'm afraid that would not fix all use cases and would even introduce some new issues. For example say you would like to update the description or a project. In that case the API would accept these options:
Parameters:

id (required) - The ID of a project
name (optional) - project name
path (optional) - repository name for project
description (optional) - short project description
default_branch (optional)
issues_enabled (optional)
merge_requests_enabled (optional)
builds_enabled (optional)
wiki_enabled (optional)
snippets_enabled (optional)
container_registry_enabled (optional)
shared_runners_enabled (optional)
public (optional) - if true same as setting visibility_level = 20
visibility_level (optional)
public_builds (optional)

For this update call you would only like to set the required field and the description field, as you do not want to change anything else. In this case there is no way to know what all the other defaults should be, as in this case the defaults should be the currently configured values for that particular project.
I understand this design is a little more verbose and in a way doesn't feel right. But I believe this is the best way to make sure we can support all use cases to the best of our abilities. And I know for a fact there are more packages out there following this approach and that some blog posts are written on this topic as well.
Long story short, I'm not going to revert this change... Sorry!
Please let me know is your issue with using the constants is fixed as that is of course something that should work.

Yeah, sorry, I was too quick to file the issue about constants - I've found a correct way using the gitlab.VisibilityLevel helper function.
Sorry, I didn't notice the major zero... more coffee needed indeed.
And yeah, filling the defaults of update calls may cause pain. Perhaps getting previous values first and filling the default struct with them would solve the problem, but that will do 2 API requests instead of one and may mislead user.
I am closing this now and sorry for bothering you before applying enough coffee :)

@dobegor no worries :wink:


Fixed benchevm.py

Changed every regex and line parse found inside the do_geth_bench function to tne new go-ethereum evm output and parse correctly.

@cdetrio @hugo-dc @jwasinger can you please review?


The decimal place of USDC is wrong.

The decimal place of USDC is wrong.

Originally posted by @cby3149 in https://github.com/omgnetwork/optimism/issues/367#issuecomment-915633009

https://github.com/omgnetwork/optimism/pull/391
changes has been available in above PR

Fixed


Find in Files's shortcut is broken

Environment data
Visual studio code Version: 1.54.3
Commit: 2b9aebd5354a3629c3aba0a5f5df49f43d6689f8
Date: 2021-03-15T10:55:24.277Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.8.0-48-generic snap
Pylance: v2021.3.3
Python: 3.7
Eclipse Keymap: v0.12.0
Ubuntu 20.20
Expected behaviour
ctrl+H should trigger the Find in Files functionality with anything highlighted prefilled in the search bar
Actual behaviour
ctrl+H now opens the Find in Files without prefilling anything and only selects the "panel" (does not focus on the search bar).
I believe this stopped working a couple of weeks ago. It seems like a recent release broke it.
I tested with the VSCode shortcuts:
it seems now that in Edit the Find in Files is set to ctrl+shift+F (that is what I see in the menu

)
if I use this set of keys for the shortcut after selecting some text: it tries to trigger formatting and I get Black does not support the "Format Selection" command
if I select some text and use the menu (Edit->Find in Files) then it works correctly
I also filed this issue with Eclipse Keybinding as I do not know where the issue comes from: https://github.com/alphabotsec/vscode-eclipse-keybindings/issues/38

Modifying the keybindings extension is the correct solution here, looks like the update is already out. A recent version changed workbench.view.search to open the search view, then workbench.action.findInFiles performs the whole set of opening the search view (or editor, depending on search.mode) and inserting text and running the query.

Hi @IllusionMH ,
The suggested changes are now live in the extension, thank you!
I do have 1 more quick question:
the focus now works but if I have a selection, it does not get prefilled into the search box (it does if I use the menu manually).
Would you know how to address that issue with the keybinding?
Thank you in advance for your help!

The change was documented here, https://code.visualstudio.com/updates/v1_54#_changes-to-workspace-search-actions based on the PR it looks like you're correctly using workbench.action.findInFiles. Trying out the eclipse keymap myself I see the correct behaviour that ctrl+h opens the search view, puts the active editor's selected text in it if it exists, and runs the search. What is happening in your case?

Hi Jackson, thank you for following up. I tested it again today and it does work.
The extension updated yesterday (so I saw it was up-to-date). But I might have forgotten to reload it.
Thank you and sorry for the confusion!!


Add global settings file

Settings such as Interval duration for cache check are shared across multiple files and would need to be updated in many places if they are changed. Make these settings global.

no longer needed- background_callbacks made this irrelevant.


change 2.0.2 to 2.1.1 BUILD FAILED

Could you give some steps to reproduce this issue? Is that your regular Android Studio project, or something else?

@pangli could it be because you are compiling with 23 and the library uses 25 as the target and as such it uses the v25 of the support library, while you are using the v23 of all the google things.

before we were using com.android.support:appcompat-v7:23.2.1 but now we use the version 25, since like 2 months ago.

@pangli nice that you got it working :)

@yombunker thank you

@pangli your welcome


KIC does not detect newly spawned Gateway Pods and prevents them from getting ready by not sending configuration

Problem statement
When Gateway deployment is being scaled, KIC can sometimes incorrectly not send the configuration to the newly spawned Gateway Pods thus preventing them from getting ready.
How to reproduce

Deploy using ingress chart, values:

gateway:
  env:
    admin_listen: "<IP_ADDRESS>:8444 http2 ssl"
    router_flavor: "expressions"
    tracing_instrumentations: "all"
    tracing_sampling_rate: "1.0"
  manager:
    enabled: false
  replicaCount: 1
  readinessProbe:
    initialDelaySeconds: 1
    timeoutSeconds: 1
    periodSeconds: 1
  admin:
    type: LoadBalancer
  image:
    repository: kong/kong-gateway
    tag: "3.7"

controller:
  replicaCount: 1
  ingressController:
    image:
      tag: "3.2"

    env:
      dump_config: "true"
      dump_sensitive_config: "true"
      log_level: debug
      anonymous_reports: "false"
      kong_admin_tls_skip_verify: "true"
      enable_controller_kong_vault: "false"
      feature_gates: "GatewayAlpha=true,FallbackConfiguration=true"

    admissionWebhook:
      enabled: false

Scale Gateway's deployment in and out. The reproduction rate is fairly low so this step might need to be repeated:

k scale deployment -n kong --replicas 1 kong-gateway; k scale deployment -n kong --replicas 5 kong-gateway

Anything else
Logs:
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:01Z debug   No change in config status, not notifying       {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:01Z debug   Triggering report for configured Kubernetes objects     {"v": 1, "count": 0}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:01Z debug   events  successfully applied Kong configuration to https://<IP_ADDRESS>:8444     {"v": 1, "type": "Normal", "object": {"kind":"Pod","namespace":"kong","name":"kong-controller-76fcbdfbd-kjcsm","apiVersion":"v1"}, "reason": "KongConfigurationSucceeded"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:04Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:04Z debug   No configuration change; pushing config to gateway is not necessary, skipping   {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:07Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:07Z debug   No configuration change; pushing config to gateway is not necessary, skipping   {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:08Z debug   Reconciling readiness of gateway clients        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:08Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.KongAdminAPIService Notifying about newly detected Admin APIs       {"v": 1, "admin_apis": ["https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444"]}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Received notification about Admin API addresses change  {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of pending client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Notifying subscribers about gateway clients change      {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.KongAdminAPIService Notifying about newly detected Admin APIs       {"v": 1, "admin_apis": ["https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444"]}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Received notification about Admin API addresses change  {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of pending client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Already created client is not ready, moving to pending  {"v": 1, "address": "https://<IP_ADDRESS>:8444", "reason": "making HTTP request: Get \"https://<IP_ADDRESS>:8444/status\": dial tcp <IP_ADDRESS>:8444: connect: connection refused"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": false}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Notifying subscribers about gateway clients change      {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.KongAdminAPIService Notifying about newly detected Admin APIs       {"v": 1, "admin_apis": ["https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444"]}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Received notification about Admin API addresses change  {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of pending client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of pending client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Already created client is not ready, moving to pending  {"v": 1, "address": "https://<IP_ADDRESS>:8444", "reason": "making HTTP request: Get \"https://<IP_ADDRESS>:8444/status\": dial tcp <IP_ADDRESS>:8444: connect: connection refused"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": false}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Notifying subscribers about gateway clients change      {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.KongAdminAPIService Notifying about newly detected Admin APIs       {"v": 1, "admin_apis": ["https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444"]}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Received notification about Admin API addresses change  {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of pending client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of pending client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": true}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Already created client is not ready, moving to pending  {"v": 1, "address": "https://<IP_ADDRESS>:8444", "reason": "making HTTP request: Get \"https://<IP_ADDRESS>:8444/status\": dial tcp <IP_ADDRESS>:8444: connect: connection refused"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": false}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Already created client is not ready, moving to pending  {"v": 1, "address": "https://<IP_ADDRESS>:8444", "reason": "making HTTP request: Get \"https://<IP_ADDRESS>:8444/status\": dial tcp <IP_ADDRESS>:8444: connect: connection refused"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   setup.readiness-checker Checking readiness of already created client for "https://<IP_ADDRESS>:8444"     {"v": 1, "ok": false}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Notifying subscribers about gateway clients change      {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Parsing kubernetes objects into data-plane configuration        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Successfully built data-plane configuration     {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Sending configuration to gateway clients        {"v": 1, "urls": ["https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444"]}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Shipping config to diagnostic server    {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Shipping config to diagnostic server    {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   events  failed to apply Kong configuration to https://<IP_ADDRESS>:8444: failed posting new config to /config: making HTTP request: Post "https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1": dial tcp <IP_ADDRESS>:8444: connect: connection refused     {"v": 1, "type": "Warning", "object": {"kind":"Pod","namespace":"kong","name":"kong-controller-76fcbdfbd-kjcsm","apiVersion":"v1"}, "reason": "KongConfigurationApplyFailed"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   events  failed to apply Kong configuration to https://<IP_ADDRESS>:8444: failed posting new config to /config: making HTTP request: Post "https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1": dial tcp <IP_ADDRESS>:8444: connect: connection refused     {"v": 1, "type": "Warning", "object": {"kind":"Pod","namespace":"kong","name":"kong-controller-76fcbdfbd-kjcsm","apiVersion":"v1"}, "reason": "KongConfigurationApplyFailed"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   No configuration change, skipping sync to Kong  {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Shipping config to diagnostic server    {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Config status changed, notifying        {"v": 1, "configStatus": "ApplyFailed"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z error   Failed to recover from configuration rejection with fallback configuration      {"error": "failed to extract broken objects from update error: no broken objects found in UpdateError"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Sending configuration to gateway clients        {"v": 1, "urls": ["https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444"]}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   events  successfully applied Kong configuration to https://<IP_ADDRESS>:8444     {"v": 1, "type": "Normal", "object": {"kind":"Pod","namespace":"kong","name":"kong-controller-76fcbdfbd-kjcsm","apiVersion":"v1"}, "reason": "KongConfigurationSucceeded"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Shipping config to diagnostic server    {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   events  failed to apply fallback Kong configuration to https://<IP_ADDRESS>:8444: failed posting new config to /config: making HTTP request: Post "https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1": dial tcp <IP_ADDRESS>:8444: connect: connection refused    {"v": 1, "type": "Warning", "object": {"kind":"Pod","namespace":"kong","name":"kong-controller-76fcbdfbd-kjcsm","apiVersion":"v1"}, "reason": "FallbackKongConfigurationApplyFailed"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Shipping config to diagnostic server    {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   events  failed to apply fallback Kong configuration to https://<IP_ADDRESS>:8444: failed posting new config to /config: making HTTP request: Post "https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1": dial tcp <IP_ADDRESS>:8444: connect: connection refused    {"v": 1, "type": "Warning", "object": {"kind":"Pod","namespace":"kong","name":"kong-controller-76fcbdfbd-kjcsm","apiVersion":"v1"}, "reason": "FallbackKongConfigurationApplyFailed"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   No configuration change, skipping sync to Kong  {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   Shipping config to diagnostic server    {"url": "https://<IP_ADDRESS>:8444", "v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z error   dataplane-synchronizer  Could not update kong admin     {"error": "failed to recover from gateways sync error: performing update for https://<IP_ADDRESS>:8444 failed: failed posting new config to /config: making HTTP request: Post \"https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1\": dial tcp <IP_ADDRESS>:8444: connect: connection refused\nperforming update for https://<IP_ADDRESS>:8444 failed: failed posting new config to /config: making HTTP request: Post \"https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1\": dial tcp <IP_ADDRESS>:8444: connect: connection refused\nperforming update for https://<IP_ADDRESS>:8444 failed: failed posting new config to /config: making HTTP request: Post \"https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1\": dial tcp <IP_ADDRESS>:8444: connect: connection refused\nperforming update for https://<IP_ADDRESS>:8444 failed: failed posting new config to /config: making HTTP request: Post \"https://<IP_ADDRESS>:8444/config?check_hash=1&flatten_errors=1\": dial tcp <IP_ADDRESS>:8444: connect: connection refused"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:10Z debug   events  successfully applied fallback Kong configuration to https://<IP_ADDRESS>:8444    {"v": 1, "type": "Normal", "object": {"kind":"Pod","namespace":"kong","name":"kong-controller-76fcbdfbd-kjcsm","apiVersion":"v1"}, "reason": "FallbackKongConfigurationSucceeded"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:13Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:13Z debug   No configuration change; pushing config to gateway is not necessary, skipping   {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-admin-2kvk9","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z info    controllers.KongAdminAPIService Reconciling Admin API EndpointSlice     {"v": 0, "namespace": "kong", "name": "kong-gateway-admin-2kvk9"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:15Z debug   controllers.EndpointSlice       Reconciling resource    {"DiscoveryV1EndpointSlice": {"name":"kong-gateway-proxy-ncb8k","namespace":"kong"}, "v": 1, "namespace": "kong", "name": "kong-gateway-proxy-ncb8k"}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:16Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:16Z debug   Parsing kubernetes objects into data-plane configuration        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:16Z debug   controllers.KongLicense No KongLicense available        {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:16Z debug   Successfully built data-plane configuration     {"v": 1}
kong-controller-76fcbdfbd-kjcsm ingress-controller 2024-06-18T12:27:16Z debug   Sending configuration to gateway clients        {"v": 1, "urls": ["https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444", "https://<IP_ADDRESS>:8444"]}

Recently, while working on FTI, I also tested similar scenarios, but my main focus was on the memory consumption of KIC.

I have created an issue to track memory usage https://github.com/Kong/kubernetes-ingress-controller/issues/6219

@tao12345666333 #6129 is this issue here 😅

@pmalek sorry, #6235


Windows, config.js, E212: Can't open file for writing: no such file or directory

Oni Version 0.2.16
Winodws 10

1 - "File -> Preferences -> Edit Oni Config"
2 - add a configuration line
3- Enter :w, get the following error:  `E212: Can't open file for writing: no such file or directory:

When I execute pwd, I get the following: C:\Program Files (x86)\Oni

I hit this on my Linux system because the .oni directory was missing.  After I manually created .oni in my home directory it could save config.js.  You could give that a try as a workaround.  If it works, we definitely need to fix this defect so .oni is always created first before attempting to save that file.

OK, so the ~ directory is in C:\Users\"your user name\"  this is confusing in Windows.  Once .oni` directory is created under the home folder, it works fine.  Furthermore, in windows, you cannot create a dotfile in the explorer.

I'm glad you found a workaround but I still think this issue is worth fixing.  Re-opening.

Just to re-enforce what @sittim said, creating a directory named .oni is difficult to do in Windows.  I believe the current Windows convention would be to create an oni directory in AppData/Roaming.  I'm pretty sure there's some %AppData% type variable we should be using but I'm not a Windows guy so everything I say on the subject should be validated. 😄

By default on Windows, I think it should go in %APPDATA%/oni, as @keforbes has said.
To my knowledge its where this style of files goes, at least for both VS Code and Notepad++.

Changing this is easy enough and I've got it in a branch, but I was wondering about what the Oni stance is on things like this, in what is basically a breaking(for lack of a better word) change.
The way I've done it means any other Windows Oni user would now need to move their config over from C:\Users\CrossR\.oni\config.js to %APPDATA%\oni\config.js.
Should we accept both or what?

Awesome, thanks @keforbes and @CrossR for thinking about.
Yes, you're right, it seems like the standard on Windows is to be in %APPDATA%.
I put some thoughts about versioning + backwards compatibility here: #938
We do have in our README that Oni is currently unstable and essentially that things may break, but we are also getting more users and I'd like to start looking at how we can have a better story for upgrade. This is one thing that's holding me from turning on auto-updates - it'd be incredibly annoying if we released updates all the time that just broke everyone 😄
I think the config-location move would be a good test case / use case for #938 , so I'd like to use that as our first 'upgrader'. Let me know your thoughts, though.
The other change, to make the directory if it doesn't exist, would be great to have - I don't see any blocker for that. It's a major pain for the first-run experience - feels really broken.


[Screen reader - FancyZones]: Name and role is not defined for the 'Name' edit box on "Choose layout dialog".

Microsoft PowerToys version
0.49.1
Running as admin

[ ] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
Test Environment:
OS: Windows 11 Version Dev (22494.1000)
App version: 0.49.1
App name: Power Toys
Screen Reader: Narrator
Repro Steps:

Launch 'Power Toys' application.
Navigate to 'Fancy zones' tab and activate it.
Navigate to 'Launch layout editor' button and activate it.
Navigate to 'Create new layout' button and activate it.
Navigate to Name edit box and observe the announcement.

User Impact:
Screen reader dependent users are facing the issue as name and role is not announced by the screen reader.
Attachment:

Video Link:
https://user-images.githubusercontent.com/79564581/142581368-9d818fe2-a24d-4b05-aefb-8ee121e17dfb.mp4
✔ Expected Behavior
For better screen reader users experience, Name and role should be announced when focus lands on the edit box of the "Choose layout dialog".
For Ex: Narrator should announces as
❌ Actual Behavior
Currently screen reader is not announcing the name and role on the name edit box of the "Choose layout dialog".
For Ex: Narrator announces as "no item in view".
Other Software
No response

Hi @HasnuddinMohammed and @Priyanshu073 ,
I've given this a test on 0.51.1 and it seems that Narrator is properly announcing the name in the edit box.
It must've been fixed as part of other UI fixes.
I'm closing this for now.
Please re-open if it pans out I'm wrong.
Thank you.


Flatten inside a struct variant produces broken Serialize code

#[derive(Serialize)]
enum Mitsuhiko {
    A {
        #[serde(flatten)]
        fields: HashMap<String, String>,
    }
}

error[E0277]: the trait bound `<__S as _IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::Serializer>::SerializeStructVariant: _IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::ser::SerializeMap` is not satisfied
 --> src/main.rs:6:10
  |
6 | #[derive(Serialize)]
  |          ^^^^^^^^^ the trait `_IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::ser::SerializeMap` is not implemented for `<__S as _IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::Serializer>::SerializeStructVariant`
  |
  = help: consider adding a `where <__S as _IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::Serializer>::SerializeStructVariant: _IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::ser::SerializeMap` bound
  = note: required because of the requirements on the impl of `_IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::Serializer` for `_IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::private::ser::FlatMapSerializer<'_, <__S as _IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::Serializer>::SerializeStructVariant>`
  = note: required by `_IMPL_SERIALIZE_FOR_Mitsuhiko::_serde::Serialize::serialize`

cc @mitsuhiko

For now I pushed a PR (#1204) that produces an error message here. I think this case can be supported but that is a bigger change.


Add note about vendoring dependencies

[x] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Makes sense. Particularly appreciate the links elsewhere.


[json] Markdown in hovers (descriptions from schema)

I have generated JSON schema which has lots of long markdown descriptions. Currently VS Code displays descriptions from schema as plain text. It would great if schema could somehow indicate that descriptions use markdown and VS Code would render it properly.

We would need a new property for that, other than 'description'. It would be VSCode specific, something like 'makedDescription'.
Although it's not explicitly stated in the JSON spec on description, but I believe the idea is that title and descriptions are plain text in order to be used by a variety of tools.

New property (markedDescription) would be great.
I generate the schema so it doesn't matter if the property is description or something else.
Thanks for considering this feature.

Thanks 👍

To verify:
Create foo.schema.json and foo.json next to each other. In foo.json, hover over 'bar' and verify that it's markdown.
{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "properties": {
        "bar": {
            "markdownDescription": "**Hello** _world_"
        }
    }
}

foo.json
{
	"$schema": "./foo.schema.json",
	"bar":  ""
}

It works for me in insider build, I tried it with my schema.
It also worked when I modified your example schema:
{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "properties": {
        "bar": {
            "markdownDescription": "**Hello** _world_"
        },
        "baz": {
            "enum": [
                "Foo"
            ],
            "markdownEnumDescriptions": [
                "It can only be **Foo**"
            ]
        }
    }
}

Thanks.


No more travis build

when i look at https://travis-ci.org/chrisbanes/PhotoView/branches the last travis build is more than 9 months old. Is disabling travis-ci build on purpose?
The current developbranch has a version mismatch travis <-> gradle which should be fixed with https://github.com/chrisbanes/PhotoView/pull/373/commits/be9cd50ffd9035ec3277993190a874db7b0da62f

Since I do not own this project on GitHub, I cannot really do anything about this


ci: Add initial workflow

Create initial CI workflow to run flake8, yapf, and pytest, and test the (un)installation of the package.

Ditching YAPF because it's too flaky.  Will replace with black in a future PR.


Don't work on Vivaldi !

Hi
Installed the extension and configured it for my seedbox but when I click on a torrent file download on a website nothing happens, browser just download file as any regular file :(
Thanks
Vincèn

Sorry. This extension is only supported for Google Chrome.


Filters aren't mean-insensitive if low-passed

Original report by Joseph Fowler (Bitbucket: joe_fowler, ).

@{557058:6b1a4860-1eb7-4caa-9340-5e3c97a89faf} and @{557058:9524f6a0-ef9f-4466-b913-d04e51ff9093} discovered that using f_3db as a low-pass filter (or presumably also fmax) creates a problem: filters filtered in this way stop being DC-insentive. They apparently introduce a DC term into the filter. It should be removed. Paul is about to add a note/example code about this.

Original comment by Paul Szypryt (Bitbucket: pszypryt, GitHub: pszypryt).

Here is a minimal argument example that shows the mean of the filter becoming non-zero when a f_3db cutoff is used.

import mass
import numpy as np, pylab as plt
import sys
import os

nSamples = 100
nPresamples = 50

fake_pulse_like = np.append(np.zeros(nPresamples), np.random.randn(nSamples-nPresamples)+1)
fake_deriv_like = np.append(np.zeros(nPresamples), np.random.randn(nSamples-nPresamples)+1)

fake_model = np.column_stack((fake_pulse_like, fake_deriv_like))

fakeNoise=np.random.randn(nSamples)
whitener=None
sample_time= 6.72e-6

fake_f_ATSF = mass.ArrivalTimeSafeFilter(fake_model, nPresamples, fakeNoise, whitener, sample_time, np.max(fake_pulse_like))

fake_f_ATSF.compute()
print("Mean computed without f_3dB cutoff: {}".format(np.mean(fake_f_ATSF.filt_noconst)))

fake_f_ATSF.compute(f_3db=1e4)
print("Mean computed with 1e4 f_3dB cutoff: {}".format(np.mean(fake_f_ATSF.filt_noconst)))

Original comment by Joseph Fowler (Bitbucket: joe_fowler, ).

Handle band limits on ArrivalTimeSafeFilters differently
This will ensure that a DC-insensitive ATS Filter will remain so even if a band limit is imposed. Fixes issue #176. HOWEVER, beware that it actually changes how filters are computed and might well yield different results, for better or for worse.

Original comment by Joseph Fowler (Bitbucket: joe_fowler, ).

Removing milestone: v0.7 (automated comment)


QI "validation error" only on Ubuntu 19.04

Bug report

Make sure you are using the latest stable version.

Well, actually, I'm not, I'm cloning master.
What did you try to do?
I have QI (master branch) running on x86_64 Ubuntu 18.04 and Power9 CentOS 7.
I've added support for QI to my open source project Qis Job and Qis Job works fine in conjunction with QI on those two platforms. All the jobs for my account on Quantum Inspire have been run that way.
I've just installed QI on Ubuntu 19.04 and when I try to run the Qis Job program to send QI one or more qasm jobs (which works fine on the other two platforms) I get a traceback.
What did you expect to happen?
I expected my jobs to run as they do on my other two installed platforms.
What actually happened?
$ python qasm_job.py --api_provider=QI  qasm_examples/yiqing.qasm
Traceback (most recent call last):
  File "qasm_job.py", line 390, in <module>
    BACKEND_NAME, SIM, QUBITS)
  File "qasm_job.py", line 150, in choose_backend
    provider = account_fu(token, url)
  File "qasm_job.py", line 118, in account_fu
    provider = qi_account_fu(token)
  File "qasm_job.py", line 104, in qi_account_fu
    from quantuminspire.qiskit import QI
  File "/home/jwoehr/work/Qiskit/quantuminspire/src/quantuminspire/qiskit/__init__.py", line 1, in <module>
    from quantuminspire.qiskit.quantum_inspire_provider import QuantumInspireProvider
  File "/home/jwoehr/work/Qiskit/quantuminspire/src/quantuminspire/qiskit/quantum_inspire_provider.py", line 8, in <module>
    from quantuminspire.qiskit.backend_qx import QuantumInspireBackend
  File "/home/jwoehr/work/Qiskit/quantuminspire/src/quantuminspire/qiskit/backend_qx.py", line 41, in <module>
    class QuantumInspireBackend(BaseBackend):  # type: ignore
  File "/home/jwoehr/work/Qiskit/quantuminspire/src/quantuminspire/qiskit/backend_qx.py", line 55, in QuantumInspireBackend
    max_experiments=1
  File "/home/jwoehr/work/Qiskit/DEV/qiskit-terra/qiskit/validation/base.py", line 253, in _decorated
    ex.messages, ex.field_names, ex.fields, ex.data, **ex.kwargs) from None
qiskit.validation.exceptions.ModelValidationError: {'coupling_map': ['Missing data for required field.']}

Environment
Please specify:

operating system, version and distribution:

Linux Leno 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ more /etc/os-release
NAME="Ubuntu"
VERSION="19.04 (Disco Dingo)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 19.04"
VERSION_ID="19.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=disco
UBUNTU_CODENAME=disco

python version (python --version) and distribution:

$ python --version
Python 3.7.3

from apt:
python3/disco,now 3.7.3-1 amd64 [installed]

list of installed packages (pip list or equivalent):

$ pip list
Package                Version     Location
---------------------- ----------- ---------------------------------------------------
apturl                 0.5.2
asn1crypto             0.24.0
atomicwrites           1.3.0
attrs                  19.1.0
backcall               0.1.0
bleach                 3.1.0
blinker                1.4
Brlapi                 0.6.7
certifi                2018.8.24
chardet                3.0.4
command-not-found      0.3
coreapi                2.3.3
coreschema             0.0.4
coverage               4.5.4
cryptography           2.3
cupshelpers            1.0
cvxopt                 1.2.3
cycler                 0.10.0
Cython                 0.29.12
decorator              4.4.0
defer                  1.0.6
defusedxml             0.6.0
distro                 1.3.0
distro-info            0.21ubuntu2
dlx                    1.0.4
docloud                1.0.375
docplex                2.10.154
EditorConfig           0.12.1
entrypoints            0.3
fastdtw                0.3.2
h5py                   2.9.0
httplib2               0.11.3
idna                   2.6
importlib-metadata     0.19
inflection             0.3.1
ipykernel              5.1.1
ipython                7.6.1
ipython-genutils       0.2.0
ipywidgets             7.5.0
itypes                 1.1.0
jedi                   0.14.1
Jinja2                 2.10.1
joblib                 0.13.2
jsbeautifier           1.6.4
jsonschema             2.6.0
jupyter                1.0.0
jupyter-client         5.3.1
jupyter-console        6.0.0
jupyter-core           4.5.0
keyring                17.1.1
keyrings.alt           3.1.1
kiwisolver             1.1.0
language-selector      0.1
launchpadlib           1.10.6
lazr.restfulclient     0.14.2
lazr.uri               1.0.3
louis                  3.8.0
macaroonbakery         1.2.1
Mako                   1.0.7
MarkupSafe             1.1.0
marshmallow            2.19.5
marshmallow-polyfield  3.2
matplotlib             3.1.1
mistune                0.8.4
more-itertools         5.0.0
mpmath                 1.1.0
nbconvert              5.5.0
nbformat               4.4.0
nbimporter             0.3.1
ndg-httpsclient        0.5.1
nest-asyncio           1.0.0
netifaces              0.10.4
networkx               2.3
ninja                  1.9.0.post1
notebook               6.0.0
ntlm-auth              1.3.0
numpy                  1.16.4
oauthlib               2.1.0
olefile                0.46
packaging              19.1
pandas                 0.25.0
pandocfilters          1.4.2
parso                  0.5.1
pexpect                4.6.0
pickleshare            0.7.5
Pillow                 5.4.1
pip                    18.1
pkg-resources          0.0.0
pluggy                 0.12.0
ply                    3.11
prometheus-client      0.7.1
prompt-toolkit         2.0.9
protobuf               3.6.1
psutil                 5.6.3
ptyprocess             0.6.0
py                     1.8.0
pyasn1                 0.4.6
pycairo                1.16.2
pycrypto               2.6.1
pycups                 1.9.73
Pygments               2.4.2
PyGObject              3.32.0
PyJWT                  1.7.0
pylatexenc             1.5
pymacaroons            0.13.0
PyNaCl                 1.3.0
pyOpenSSL              19.0.0
pyparsing              2.4.2
pyRFC3339              1.1
pyscf                  1.6.3
pytest                 5.1.1
python-apt             1.8.4
python-dateutil        2.7.3
python-debian          0.1.34
pytz                   2018.9
pyxdg                  0.25
PyYAML                 3.13
pyzmq                  18.0.2
qiskit-aer             0.3.0       /home/jwoehr/work/Qiskit/DEV/qiskit-aer
qiskit-aqua            0.5.6       /home/jwoehr/work/Qiskit/DEV/qiskit-aqua
qiskit-aqua-interfaces 0.1.1       /home/jwoehr/work/Qiskit/DEV/qiskit-aqua-interfaces
qiskit-ibmq-provider   0.3.2rc1    /home/jwoehr/work/Qiskit/DEV/qiskit-ibmq-provider
qiskit-ignis           0.2.0       /home/jwoehr/work/Qiskit/DEV/qiskit-ignis
qiskit-terra           0.10.0      /home/jwoehr/work/Qiskit/DEV/qiskit-terra
qtconsole              4.5.2
Quandl                 3.4.8
quantuminspire         1.0.0       /home/jwoehr/work/Qiskit/quantuminspire/src
reportlab              3.5.18
requests               2.21.0
requests-ntlm          1.1.0
requests-unixsocket    0.1.5
scikit-learn           0.21.3
scipy                  1.3.0
SecretStorage          2.3.1
Send2Trash             1.5.0
setuptools             40.8.0
simplejson             3.16.0
six                    1.12.0
sklearn                0.0
ssh-import-id          5.7
sympy                  1.4
system-service         0.3
systemd-python         234
terminado              0.8.2
testpath               0.4.2
tornado                6.0.3
traitlets              4.3.2
ubuntu-advantage-tools 19.2
ubuntu-drivers-common  0.0.0
ufw                    0.36
unattended-upgrades    0.1
uritemplate            3.0.0
urllib3                1.24.1
usb-creator            0.3.3
wadllib                1.3.3
wcwidth                0.1.7
webencodings           0.5.1
websockets             7.0
wheel                  0.32.3
widgetsnbextension     3.5.0
xkit                   0.0.0
zipp                   0.6.0

anything else that might be relevant

There was a change in the latest qiskit-terra version that introduced this issue. We released quantuminspire version 1.1.0 with a fix for it. After upgrading your version of quantuminspire to 1.1.0 this issue should be solved.


Mongo pipelines

Is there any feature for mongo pipelines?

Hello @lucasltv,
Not supported for now. I am not sure of the API yet. I would love to have something flexible and clean at the same time, not easy for Mongo pipeline.


Validator: Malformed JSON in request body

I get the error message "Malformed JSON in request body" when using zValidator as middleware.
src/validator/validator.ts is using c.req.raw.clone().json() to parse the json.
c.req.raw.clone().json() always returns SyntaxError: Unexpected end of JSON input (with bun v0.6.13).
c.req.raw.json() or c.req.json() is working.

its a bun in bun.
https://github.com/honojs/middleware/issues/81#issuecomment-1509457656


chore(chrome): split chrome calls

Too many features making the split a challenge. Things need to be split in smaller chunks.


Add row or column scaling option to matrixplot

Especially when we visualize raw counts, sometimes it's hard to see the differences between the expression of one gene across cell types in the heatmap since one value can simply dominate the dynamic range of expression. I think we can add a scaling option to matrixplot, which squashes expression values between 0 and 1 to make markers more pronounced.
Heatmap of the raw values:

Heatmap of the logarithmized values (which also helps a bit but not for all genes):

Heatmap of the col-normalized values:

PS: The option is actually borrowed from Seaborn (https://seaborn.pydata.org/generated/seaborn.clustermap.html).
PPS: There is an edge case such as division by zero. Also, swap_axes option makes 'row'/'col' naming a bit confusing. Let me know if you have suggestions about these or the standardization idea in general.

Happy to merge this if @fidelram is happy with it, too! :)

This is very useful! Thanks a lot.
Would you mind adding a test in scanpy/tests/test_plotting.py?

I was looking at the tests, and something made me think. If use_raw=False is given, we use a diverging colormap on purpose, right? Like this:

Now with the new standardization option, values are squashed between 0 and 1 but the color scale is still diverging:

@fidelram Do you think that's ok, or should we switch back to viridis when standard_scale is given, regardless of use_raw state?

Added tests, too. (Tests fail in my setup, though. RMS is usually around 50-60, rather than 15.)

@gokceneraslan Tests with images are always problematic. I will take a look later. With respect to use_raw=False, what happens is that usually, adata.X  is scaled and centered around zero. Thus, a default diverging scale was used with parameters vmin=-3, vmax=3, cmap='bwr'. This has been useful to me, but if data is being processed differently, this could be confusing.  I will take a look later. With respect to use_raw=False, what happens is that usually, adata.X is scaled and centered around zero. Thus, a default diverging scale was used with parameters vmin=-3, vmax=3, cmap='bwr'. This has been useful to me, but if data is being processed differently, this could be confusing. What is your opinion?

Default values of vmin/vmax looks ok for most datasets, but when we squash everything between 0 and 1, for negative scale doesn't make sense any more and even for max values (i.e. 1.0) colors will look dimmer than the color representing the max value. For example:
sc.pl.rank_genes_groups_matrixplot(adata, n_genes=1, standard_scale='var', use_raw=False)

generates

Color scale might be a bit confusing for some, IMHO. I think it makes more sense to switch back to default sequential colormap if standard_scale in ('var', 'group'), but it's totally up to you :)
We can merge this and play around with different datasets etc, too.

Any thoughts @fidelram?

I think we should remove the that uses the divergent colormap and keep things simpler.

@fidelram Shall I do it in this PR or shall we merge this and address it in another PR?

Let me see if I can make changes on top of your changes. But I think I need to make a new PR.


Add auth association

Implementation for issue #8
TODO:

[ ] Add user instructions
[x] Add request.user checking to auth token association
[ ] Test coverage

NOTES:

login.user view was refactored. It's now a generic redirecting return endpoint for SAML responses, which saves the HTTP headers AUTHNID and AUTHENTICATOR to the session

Merged master and ui-restyling branches to this PR branch.


How does webcontainer send a message to main thread to get data

WebContainer uses MessagePort to communicate with the main thread internally, but none of this is exposed in the public API.
To communicate with the main thread from WebContainer, you can use spawn() to create a new process that will transfer the required data, and use WebContainerProcess.output to read this information in the main thread as a ReadableStream<string>
Feel free to open another issue if you need any more info!
Originally posted by @kirjavascript in https://github.com/stackblitz/webcontainer-core/issues/1129#issuecomment-1642179919

Here are the details of my question：

Is there a demo for reference？

Is there a way to synchronize the communication with the master? For example, webworker can synchronize the communication with the master through synchronization request and serviceworker interception request and forward to the master

Hi! Thanks for the question.

1. Is there a demo for reference？

There are some examples of handling input and output in WebContainer in there links: https://webcontainers.io/tutorial/6-connect-a-terminal https://webcontainers.io/tutorial/7-add-interactivity

2. Is there a way to synchronize the communication with the master? For example, webworker can synchronize the communication with the master through synchronization request and serviceworker interception request and forward to the master

Could you elaborate a little on what you mean exactly? I'm not familiar with what you're referring to.
I'm afraid currently the only way to communicate with WebContainer is with stdin and output.

Use the spawn() way is through for interacting with the master, in the main thread by invoking webcontainerInstance.spawn() perform logic  and return the results?
What I want is for webcontainer to communicate with the master thread while executing the logic

The service worker intercepts http requests and forwards the intercepted requests to the master for data
The service worker intercepts the master's data by synchronizing requests in the worker.


Fixed DECLARE_DYNAMIC_ATTRIBUTE to support CLIENT role as well.

The DECLARE_DYNAMIC_ATTRIBUTE has SERVER role hardcoded, which means it is not possible to declare dynamic endpoint using a CLIENT role.
The fix allows to pass role, as an argument and use both ZAP_CLUSTER_MASK(SERVER) and ZAP_CLUSTER_MASK(CLIENT) on cluster creation.
Fixes: #30872

LGTM. Any reason why it was hardcoded?

Unfortunately, I have no clue.

Or is it just the PR title (and presumably commit message) that's wrong?

Yes, of course you are right, I meant client role for a cluster, not attribute. The commit message and PR title were fixed.


Add method picker to signal connect dialog

Thought I'd take a stab at resolving #9644 / #239.
As this is my first real PR to the engine, I am particularly interested in constructive feedback and any discussion on the changes, the UX choices made, and any mistakes in code style that don't line up with the expectations of the project.
I am also interested in what process there is for backporting such a change to the stable branch, as there shouldn't be anything in this PR to my limited knowledge that depends on 4.0.
The change is rather simple and leverages the existing setup of the connect dialog (selecting a method in the tree simply inputs that method name into the receiver method text field).
Changes:

A new method tree is added to the signal connect dialog

Appears in basic and advanced mode
Tree is broken down by class in the hierarchy of the selected node
If a script is attached, those methods appear at the top of the tree
Search input updates the tree removing all entries that do not contain the searched string
Classes with no methods after search has been applied are de-emphasized

Removal of the attached script check in basic mode (and the error when no nodes have attached scripts)

As the new method list appears in basic mode, it didn't make sense for this behavior to remain

Move basic/advanced toggle to top alongside signal name

Originally did this as I wasn't certain about whether I would show the receiver method input when the tree was visible (was considering putting the tree in advanced). It doesn't have to stay up there and can be reverted.

Updated screenshot:

Advanced mode:

Could you attach a screenshot?

Edited with screenshot

One or two more things worth mentioning:

The "class name" tree items are unselectable, only the method tree items are
If you start typing a new method name in the receiver method input, it clears the selection in the tree

Trying to run clang-format to fix the failed check, for some reason it's complaining about errors in the .clang-format config file (for example AlignAfterOpenBracket: DontAlign not being set using a boolean). Is there a specific version of clang used?

@sampengilly Yes, we're using clang-format 9 on CI. Make sure to use the same version (or a more recent version).

Yep, turns out my installer was a super old version. It's always a pain to install some of these things on windows 😩.
Fixed

Would be nice if the tree showed icons for the nodes. And hiding the "Methods" root item would be good too, as it really doesn't do anything.

@YeldhamDev yep, I was thinking about doing that. didn't include it in here to begin with and I'd have to look into how to do it but it's definitely something I'd like to add. Possibly also adding a switch to filter methods by signal signature?

Remember to not add too much complexity to the dialog. There was another PR that added to much and ended up closed because of it.

Also the root "methods" object is there just to serve as the root of the tree. I don't think it's possible to have multiple top-level tree items. But if it is possible then I agree.

More like this:
https://docs.godotengine.org/en/latest/classes/class_tree.html#class-tree-property-hide-root

Added icons. Looks like the array for type icons is copied around in a few places so I've just done the same, is it worth putting that somewhere static? Or is that intentional?

is it worth putting that somewhere static?

Maybe, but not on this PR, out of scope.
Could you give a screenshot with the dialog in advanced mode? Also, don't forget to squash your commits: https://docs.godotengine.org/en/stable/community/contributing/pr_workflow.html#mastering-the-pr-workflow-the-rebase

Maybe, but not on this PR, out of scope.

Yep, I agree. Just wanted to bring it up

A quick thought about the consequences of removing the script check. It is now possible to hit "Ok" with the pre-entered method on a node that doesn't have a script. This obviously fails (and shows an error message, so it's not catastrophic). It's probably worth making the input non-editable unless a node with an attached script is selected. Thoughts?

It's probably worth making the input non-editable unless a node with an attached script is selected

Most likely.

We discussed this a lot already, and the general consensus was that this UI should be as simple as possible, specially for the most common use case, which is creating callbacks into a script. More advanced users are discouraged, which is why the advanced toggle exists.
A common suggestion that was never implemented was adding something like this:

So you have a small button on the right that if you press, a PopupMenu appears and shows you a list of script methods only, and which are compatible with the callback. Connecting to non-script methods is entirely undesired on this dialog because its a very rare corner case that you should either write the method yourself or connect via code.

Is there a link to the discussion? I'd like to have a read through it if possible. I agree that keeping it the flow simple for the simplest use case is beneficial, and can adapt the change to use the ... UX treatment in your screenshot or to only show the tree in advanced mode.
I am curious though as to the rationale behind discouraging more advanced usage of this dialog. To me it already seems like a really useful bit of tooling that can be used to drive various gameplay behaviors in a declarative and loosely coupled way. But it feels only about 95% of the way to where it could be as an extensible tool with emergent properties (for example a dev making various signals/methods available and a gameplay designed using them to create something that hadn't originally been considered).
Maybe that simple method select from an existing script is all it needs to take it the remaining 5%. I can definitely see the issue with non-matching signatures and was already thinking about ways to eliminate those methods from the equation (but what if the user is intending to supply their own argument in the extra call args?).
Making non-script methods available is something I can roll-back, I thought it was useful for certain simple tasks for which creating a script would be unnecessary/overkill (such as hiding a node, or calling queue_free() or even for some simple declarative debug logging).

IMO showing non-script methods wouldn't hurt if they were below the script methods and folded by default.

I agree with reduz that have a three-dots button is better than having the methods tab be always present.
At least for 99% of the time I usually stick with the default callback name, so it wouldn't make sense to clutter the main view because of it.

The view that I'm coming from when it comes to showing existing methods is one that is less focused on the first connection, where you create a method to receive the signal, and more focused on the subsequent cases, and the cases where you have designed different nodes with outputs (signals) and inputs (functions) that can be wired up easily from the editor.
As an example you could have a "LockPanel" node that emits a signal unlocked when a code is entered correctly, then you could have a "Door" node that doesn't need to know anything about the panel, but it has a method open(). A connection dialog that shows existing methods like open() would make wiring this event up a breeze. It also opens the door (pun not intended) to being used in other ways such as wiring up a signal for some game event (like picking up a certain item) to the open() method. Whether you're a solo dev or part of a team, these emergent properties that come about from architecting your nodes/scenes with decoupled inputs and outputs are pretty powerful/useful.
Obviously this can all be done currently, but it's a bit clunky, with the tooling catering more for the first time, single-use connection. My thoughts are that this tool should also cater to simple re-use with more generic methods vs specific _on_SomeNode_SomeSignal() methods, and that doing so would add a lot more clarity, and extensibility to an already useful system.
It may be a bit of a semantics thing, but semantics can mean the world of difference in showing the ways that a system can or should be used.

@sampengilly I agree it would be nice to have more control over the name of the generated callbacks, we can possibly work on that instead.
I can see some potential alternatives that would be nice to have as project settings:

(current) _on_SomeNode_SomeSignal()
_on_NodeClass_SomeSignal()
_on_SomeSignal()

I personally only use the first one when the name of the node happens to match the node class.

I feel like simply boiling it down to a change in the generated name misses most of the point of my previous comment. The current name generation is fine as-is for quickly connecting a node to itself or to a parent within a small, coupled and self contained scene for a single-use purpose (for example a bit of UI).
But when it comes to using emitted signals to trigger decoupled and re-usable bits of functionality, there needs to be good support for selecting existing methods on that node.

@sampengilly I don't doubt you have your use case but I can't imagine it, since the naming schemes I follow are what I follow for all my projects.
Either way if the method tree is added it'll definitely have to be in a three-dots popup.

I'm tweaking the behavior to be more in-line with the screenshot from @reduz, though I still wonder if there's a better UX that caters for both cases.
Regarding the change, does anyone happen to know an existing means of getting all the built-in callback methods? I'm grabbing the list of methods from a ScriptInstance object, and it makes sense to strip out all the callbacks leaving just the script methods (maybe filter out all methods with a return type as well, arguments would have to be based upon what is entered in the advanced side of things).
For filtering out the methods, it doesn't make a huge amount of sense to hardcode in all the callbacks in case they change. But if there isn't already a provision to doing it smarter and putting that in is difficult, maybe YAGNI comes into play and hardcoding them is the best solution for now. Thought I'd ask first.

Regarding the change, does anyone happen to know an existing means of getting all the built-in callback methods?

If you get all built-in methods, the callbacks all start with _, while normal methods don't.

I initially thought that too, but so do methods that the user names as such though :P (but there is an argument to be made over whether these "private" underscore-prefixed methods should be selectable this way)

I initially thought that too, but so do methods that the user names as such though :P

Yeah, but they are not built in, they come from the script. If there's a way to differentiate between the two, getting callbacks should be easy.

If the script defines a _process method, it appears in the list from ScriptInstance::get_method_list(), along with any other method that the user defines, underscore or not. I had the thought to filter out all methods that appear on the base class of the node, but that could get thrown off if the user declares a class_name in their script right?

that could get thrown off if the user declares a class_name in their script right?

Not sure, it's possible that methods from class_name are not treated like "built-in", but you'd have to check.

Ok, re-implemented it as a simple drop-down picker, I wrangled a bit with filtering the methods as well as adding in some functionality to show an error label when there was a mismatch between the arguments of the signal and the arguments of the selected method. Unfortunately I couldn't get ClassDB::get_signal() to play nicely to achieve that. Not sure why.
So this is now the bare minimum implementation.

Once again, the screenshots need to be updated.

Apologies.

The "..." button is enabled only when a node with an attached script is selected.
When there are no methods to display, the popup menu displays a disabled item stating as such.
When a method is clicked, it replaces whatever is in the receiver method text input.
The Ok button enabled logic has been modified to disable when the method input is empty.
Currently all methods in the script are shown in the popup menu and no argument details are taken into account.

One last request from me: Could you also add icons to the dropdown menu? Also, it would be better to make the button non-flat.

Why the dropdown shows only script methods .-.

@KoBeWi Yep, thinking again that's kinda pointless. That button should still be non-flat, however. As to make it more prominent, and to make its disabled state more noticeable.

Got the icons in, trying to get the MenuButton to draw non-flat though is proving to be difficult. set_flat(false) had no effect when I called it in the ConnectionDialog constructor. Logging showed that the base class was setting it to true multiple times after the constructor was called. I moved the set_flat(false) call to _update_method_picker() so that it would be set to non-flat last. Still no effect.
Example of set_flat(false) being called in the constructor:

Decided to log some more stuff and saw this happening:
Inside button.cpp:

Method icons:

Regarding the flat MenuButton, I might need a hand on that, not even replacing set_flat(true) with set_flat(false) in the `MenuButton constructor has any effect. Is there an issue with this component? It seems a bit silly to reimplement the behavior of it using a normal Button just to make it non-flat.

@sampengilly I think I've run into that problem some time ago as well, no idea why it happens. For now, just set it to false and once it's fixed it will work properly.

Done

Awesome work, I've been watching these PRs/issues for a while hoping one will make it :)
One question: When you select an existing method, is it smart enough to not open the text editor?
One of my current frustrations is my (external) editor constantly popping up when I connect to methods that already exist, as I usually write receivers before wiring connections. I can open a separate issue but I figured this might solve it.

Sorry for the late review. The feature looks good to me, but the PR needs a rebase.

Additionally, if you are going to pick the methods from a list, it should only show the methods that are compatible with the signal signature, so connecting to something that will later fail needs to be avoided at design time.

Additionally, if you are going to pick the methods from a list, it should only show the methods that are compatible with the signal signature, so connecting to something that will later fail needs to be avoided at design time.

More or less though. I thing methods with less arguments could work too, as it would simply need to unbind some arguments to work.

Methods with more arguments can be connected too, by using additional binds.
The only case that would always fail is when the types mismatch.

From memory I was rebasing this as I went with the comments received in this PR so the original implementation is probably only around in my local reflog if anything?

If you didn't make a copy, then yeah, it can be only in reflog. But it's been a long time, so it's probably not available anymore (still worth checking).

@KoBeWi I dug this out of the reflog... seems to be the commit before I changed it to the dropdown https://github.com/godotengine/godot/compare/master...sampengilly:godot:old-connect-tree

Also I completely disagree with not including non-script methods. I connect to show()/hide()/queue_free() etc. very often.

I'll second this. As a matter of fact, I almost exclusively use the connect dialog to connect builtin signals on nodes without scripts, i.e. "show() X when button Y is pressed()". If I've already got scripts, then I usually just connect in the scripts. The dialog is useful when you want to wire up simple stuff where adding scripts would be overkill.

Superseded by #66313.


Removing Timeline and tooltip mobile fix

@eread-usgs Removed the timeline and adjusted the content to be a bit bigger since we can afford the space now

Need to learn to branch... @jiwalker-usgs if you look at the mobile tooltip solution, I just added a document on click to hide the tool tip, their JS is chalk full of e.preventDefaults when you click one of the bars, so no worries about it never showing up. It just hides the last tooltip and then pops up the next one as one would expect.


Sticker picker broken

With the 1.6 RC it says: postMessage request timed out. Sent object: {"api":"toWidget","action":

Cause by disabled Third-party cookies in Firefox.


allow port file specification in config

Looks good. I wonder, though, are we immediately going to run into the same problem with the .gorilla-port file that is also written out, indicating to tools the port on which gorilla's web interface is running. Maybe it makes sense to make that configurable here as well?

You got it!

Thanks :-)
I made a small change, which was to take file paths rather than File objects in the configuration, as it seems more naturally clojure-y. Let me know if this causes problems for your application and we can change it back if so. See https://github.com/JonyEpsilon/gorilla-repl/commit/5e5e8a359a696b7f5445ed6e09bf0a892db60336


terraform for nextstrain

Description
terraform build for nextstrain pipeline port over
Issue
ch119790
Test plan
make deploy-tf
nextstrain build --aws-batch zika-tutorial/

Can you update the test plan for posterity?

@ttung do you think that the overall organization is ok? Looking at this now i was thinking of making a new directory for policies (instead of adding the policies to templates since they're not really templates). Does it also seem ok to you that i have the three seperate files for nextstrain related things (nextstrain_batch.tf, nextstrain_s3.tf, and nextstrain.tf) or do you think i should move all the resources into a nextstrain.tf file? I'm having a hard time deciding

yeah, i think this is okay.  we can always rearrange as needed.


Support for 2nd Price Auctions

https://discord.com/channels/990821777875800094/1003014897791160461/1003685277551833149

Not going to happen. =P


test: Use --wait flag in helm deployments for e2e tests

ADO pipelines appear to have issues with the helm deployments unless
--wait is supplied.
Signed-off-by: Peter Engelbert

@sozercan Two of the tests are consistently failing. These appear to be related to #284, which has a newly added test that flickers:
https://github.com/Azure/eraser/runs/7199712235?check_suite_focus=true
https://github.com/Azure/eraser/runs/7199483489?check_suite_focus=true


No componentId on blockLiquidContainerComponent page

[Enter feedback here]
No componentid on blockLiquidContainerComponent page，so I don't know how to get the filllevel of cauldron
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 041d0d31-c1ac-806f-8e6f-d4ed61ac3def
Version Independent ID: 041d0d31-c1ac-806f-8e6f-d4ed61ac3def
Content: minecraft/server.BlockLiquidContainerComponent Class
Content Source: creator/ScriptAPI/minecraft/server/BlockLiquidContainerComponent.md
Product: gaming
GitHub Login: @JakeShirley
Microsoft Alias: jashir

There's currently no way to get a base class component. You'll have to instead grab one of the 4 derived classes, depending on the type of block.
e.g. getComponent("minecraft:lavaContainer")


Sequence.compactMapByKeyPath

🚀 Added a new version of Sequence.compactMap that uses KeyPath to map elements (proposed by @guykogus in https://github.com/SwifterSwift/SwifterSwift/pull/763#discussion_r348835443).
Checklist

[x] I checked the Contributing Guidelines before creating this request.
[x] New extensions are written in Swift 5.0.
[x] New extensions support iOS 8.0+ / tvOS 9.0+ / macOS 10.10+ / watchOS 2.0+, or use @available if not.
[x] I have added tests for new extensions, and they passed.
[x] All extensions have a clear comments explaining their functionality, all parameters and return type in English.
[x] All extensions are declared as public.
[x] I have added a changelog entry describing my changes.

          4 Messages

:book:
Thank you for submitting a pull request to SwifterSwift. The team will review your submission as soon as possible.

:book:
iOS: Executed 617 tests, with 0 failures (0 unexpected) in 15.604 (17.513) seconds

:book:
tvOS: Executed 591 tests, with 0 failures (0 unexpected) in 5.757 (7.398) seconds

:book:
macOS: Executed 442 tests, with 0 failures (0 unexpected) in 1.399 (1.763) seconds

  Generated by :no_entry_sign: Danger


Added support for custom kms keys and policies

@wr0ngway I reworked the kms decrypt/encrypt functionality and docs for enhanced clarity.  Please review when you get a free moment.


Proper Arrangement of files + Responsive Web Page

🎮 feature Request
Currently the files of the Web Page are not properly arranged and managed, I'll arrange it properly for better understanding and easy management of files. Also the Web Page is not Responsive enough which is making it look ugly. So will also make it responsive for better UX.
Point down the features
The Web Page will be responsive.
Select program in which you are contributing
GSSoC24
Code of Conduct

[x] I follow CONTRIBUTING GUIDELINE of this project.
[ ] Proper Folder Structure.
[ ] Fixed Responsiveness for better UX.

Please assign it to me! I'll solve this issues.

Could you please explain more what you want to do, I have already assigned some tasks. if possible you can also add screenshot.
If you have any doubt you can directly send message on our discord (https://discord.gg/rZb46cCMmK), we have created seprate chennals for all projects...
Thank you :)

Hi @Aditya01229 , I would like to work on this issue, Could you assign it to me under GSSOC'24?

https://github.com/GameSphere-MultiPlayer/Community-Page/assets/114353434/b6d86e4e-09de-4005-af3c-7618777ef63b

@Durgesh4993 As in the video we can see the Website is not visually appealing at different size. So I will make it responsive to adapt all sizes.
Also the folder structure, name of files is not that systematic. So I'll just do the basic task of giving proper name, making css, scripts, images folder and transferring files to their respective place and also make the necessary changes in index.html i.e. correct all the paths accordingly.


Update build status badge

Due to having been moved from /zalando-incubator to /zalando the build status badge was broken

@duergner thanks for contribution! I did a bit more in #617

👍

Well than never mind :-)

:+1:

Let's merge it

Codecov Report

Merging #616 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #616   +/-   ##
=========================================
  Coverage     84.15%   84.15%
  Complexity      883      883
=========================================
  Files           145      145
  Lines          2279     2279
  Branches        307      307
=========================================
  Hits           1918     1918
  Misses          223      223
  Partials        138      138

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 17efddf...76f1a1c. Read the comment docs.


Add service (and thank you!)

Is it possible to add service #121593?
I'm trying to book an appointment there for weeks
Thanks!!

Yes, you just need to edit the first few lines of the script.
It cannot be added to the tool on All About Berlin without permission from the city of Berlin. So far, my emails went unanswered. This could be because they are marked as spam (like earlier last year).


Preview of Umbraco.MultipleTextstring

Not sure if this is related to package or Umbraco's internal BlockEditorConverter.
Value is passed as [{value: "A"}, {value: "B"}, {value: "C"}] to PreviewMarkup call.
Same value for the GetById call in the backoffice.
Also previewed as that value, so the conversion located in MultipleTextStringPropertyValueEditor is not happening.

fyi working around this with specific code for preview:
@if (Context.Request.IsBlockPreviewRequest())
{
var headers = string.Join("", Model.Tableheaders);
var array = JArray.Parse(headers);
Model.Tableheaders = array.OfType()
.Where(x => x["value"] != null)
.Select(x => x["value"]!.Value())
.ToList();
}

@kows I've tried running the latest version of BlockPreview against Umbraco source, and it appears to be a problem with the MultipleTextStringValueConverter at https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Core/PropertyEditors/ValueConverters/MultipleTextStringValueConverter.cs. The converter is expecting either a string with NewLine or XML, but the rendered front end value is a JSON array.


Add support for "sub apps"

When creating a large slack application it would be nice to be able to reuse components in a more pythonic way than what is possible right now.
A workaround is described in issue #236, but it requires passing the app object around and manually wiring up things by registering and calling decorators as functions directly.
I suggest adding a feature much like include_router in FastAPI or add_typer in Typer.
This feature will let us create sub-apps in separate files or even separate packages, like plugins that can be published on pypi.org separately.
Here is a small example illustrating what I mean:
main.py
Here is our main app, where we add a plugin from a separate package
import os
from slack_bolt import App

from my_plugin import my_plugin

# Initializes your app with your bot token and signing secret
app = App(
    token=os.environ.get("SLACK_BOT_TOKEN"),
    signing_secret=os.environ.get("SLACK_SIGNING_SECRET")
)
app.add_app(my_plugin)

my_plugin.py
A simple plugin that just creates a slack_bolt app, but without any config
from slack_bolt import App

my_plugin = App()

@my_plugin.message("hello")
def message_hello(message, say):
    say("Hello world")

Category

[x] slack_bolt.App and/or its core components
[x] slack_bolt.async_app.AsyncApp and/or its core components
[ ] Adapters in slack_bolt.adapter
[ ] Others

Hi @davidolrik, thanks for writing in!
I also like the reusable component concepts like Blueprints in Flask and APIRouter in FastAPI. However, I'm afraid that reusing App in the way you illustrated in my_plugin.py does not match the Bolt framework concept across the three support languages/runtimes (Node.js / Python / Java). App requires a complete initialization of a Slack app. Thus, a subset of listeners or incomplete initialization won't be compatible with the concept.
If we name the pluggable components differently, it can be reasonable to have such in the Bolt design (or only for Python). With being that said, please do not expect such enhancement happens in the short term. We are not planning to work on this so far.
Anyone's inputs and feedback related to this topic are greatly appreciated, but we don't guarantee the Bolt framework will support this kind of abstraction in future versions. Let me keep this issue in a discussion phase.

My main goal was to facilitate better code reuse, but most importantly better organization of large complex slack apps while still being able to use the @app.* decorators.
Maybe a kind of proxy sub app object would make sense then, and app.add_sub_app(my_plugin) could then transfer what ever was defined on the sub app to the main app.
from slack_bolt import SubApp

my_plugin = SubApp()

@my_plugin.message("hello")
def message_hello(message, say):
    say("Hello world")

The important part is that the SubApp should be able to use all the decorators from App.

Hi!
I totally agree that it would be awesome to have some kind of modularity built-in. If that's already possible, maybe you could add more examples to documentation?
I was struggling to separate my Bolt instance from the webserver (I use Starlette adapter for Bolt) and ended up creating a function which creates a Bolt app AND declares event listeners inside it, which feels a bit like a dirty approach.
I would appreciate any resources on making Bolt apps modular.
Thanks for your work!

Marked as "auto-triage-skip" -- we are still interested in exploring recommended ways for modularity in the future.

Here's what I came up with:
class SubApp:
    def __init__(self) -> None:
        self.actions = []
        self.views = []

    def action(self, *args, **kwargs):
        def __call__(func):
            self.actions.append((args, kwargs, func))
            return func

        return __call__

    def view(self, *args, **kwargs):
        def __call__(func):
            self.views.append((args, kwargs, func))
            return func

        return __call__

    def register_to(self, app: App):
        for args, kwargs, func in self.actions:
            app.action(*args, **kwargs)(func)

        for args, kwargs, func in self.views:
            app.view(*args, **kwargs)(func)

Usage:
sub_app = SubApp()

@sub_app.event("app_mention")
def handle_app_mentions(logger, event, say):
    logger.info(event)
    say(f"Hi there, <@{event['user']}>")

# Then...

app = App(...)
sub_app.register_to(app)

I agree that this framework needs a built in way to create sub apps. The decorator syntax that bolt allows is extremely useful but's it's almost completely nullified because of the lack of modularity.

Hey all! Bolt is an excellent framework with many good ideas, but I too was looking for a way to build bigger, modular Slack bots in Python. For this purpose, I built Slack Machine. I started building it a couple of years before Bolt was created and I have been working on it off and on since then.
Recently, I pushed a major new release that converted the whole framework to use the Events API, SocketMode and Python's asyncio features. I feel that Slack Machine is now modern and robust enough to be used by others.
Slack Machine is built around the idea of plugins, where plugins can be external Python packages, or live alongside your Slack Machine configuration. It also makes heavy use of decorators just like Bolt, to make it easy to respond to various events from Slack.
This should give you an idea of what a plugin could look like:
from machine.plugins.base import MachineBasePlugin, Message
from machine.plugins.decorators import respond_to

class DeploymentPlugin(MachineBasePlugin):
    """Deployments"""
    @respond_to(r"deploy (?P<application>\w+) to (?P<environment>\w+)")
    async def deploy(self, msg: Message, application, environment):
        """deploy <application> <environment>: deploy application to target environment"""
        await msg.say(f"Deploying {application} to {environment}")

Let me know if you have any questions!


Remove TestUnmarshalRecursivePointer

In v1, a special-case check was added for when an interface value contained a pointer to itself, which would lead to an infinite cycle trying to following the sequence until it found a non-interface or non-pointer value.
In particular, it would detect this pattern:
var v any
v = &v
json.Unmarshal(..., v)

However, this does not detect the general problem. Thus, v1 would still run into an infinite cycle with:
var v any
v1 := &v
v = &v1
json.Unmarshal(..., v)

where there are 2 layers of pointers, still leading to a cycle.
We should either detect the general case or
not try to detect cycles at all.
Fundamentally, it is difficult to detect the general case without either O(N) memory or doing something clever like Floyd's cycle finding algorithm. Both approaches are expensive for the questionable value that this check brings.
It is also questionable why infinite cycles through pointers and interfaces should be specially handled when the "json" package does not detect other forms of infinite cycles such as infinite recursion through an UnmarshalJSON method.
These situations are all indicative of a programmer mistake. While presenting an error would be ideal,
we lack an efficient way to detect this.
Updates golang/go#31740

I assume you will do a set of v1 patches or a proposal/issue upstream for this too.

I'm thinking of running this through Google's fleet of tests first and if nothing breaks because of this, I'll formally pursue the removal of this feature.


Would making GlobToken smaller help?

The GlobToken struct currently has three int-sized properties, meaning that on a 64-bit system, alignment rules mean it will typically be the size of 4 ints, i.e. 16 bytes.
This is not massive, of course, but in tight loops that execute while churning through large quantities of data, byte shaving can start to have a measurable effect. There are a couple of reasons for this. One is simply that the number of cache lines required to maintain the working state of the inner loop goes down, meaning that if cache evictions of important state occur (CPUs don't necessarily maintain a MRU list for cache lines, so badly-chosen discards do happen) the amount of work it takes to recover goes down. Another is that if data structures get smaller, the JIT compiler can sometimes get more clever using registers, or even with SIMD code generation.
There are currently only 9 distinct values for GlobTokenType, making the 32 bits of space it currently gets in this structure seem like overengineering. And the use of int properties means that we support glob pattern lengths of up to 2 billion characters, with individual segments also able to be 2 billion characters long.
One relatively simple change we could try would be to flip the source of truth for Length and End. Currently End is the source of truth, and Length is calculated, but we could reverse this, and then make Length a ushort. This would limit individual segments to 65535 characters, while still allowing the whole pattern to be as long as strings can get. Combining this with a change to make GlobTokenType use ushort as its backing type would mean that GlobToken would now be only 64 bits in size. This would enable it to fit inside a single CPU register, which might open up more optimization options to the JIT, and would in any event half the size of the tokenized pattern.
I have no idea whether this would make the slightest difference to anything. It might even make things worse, by forcing the use of 16-bit arithmetic. But it would be worth an experiment to see if it does have any impact
Note to benchmark this effectively, it might be necessary to run some tests with much larger volumes of input than we are currently using. We want to know what happens when ploughing through enough data to start causing cache evictions.

Just to bring this alive again - are we happy that the 8-byte glob token is the way to go? And if so, do you want to apply your changes and maybe discuss the issues in a blog post?

Having read through my comment and measurements, I'm now definitely uncertain.
My concern is that this adds complication for an extremely small gain. The risks of that complication include:

more likely to contain subtle bugs
harder to maintain
time spent doing this work (as compared with not doing it)

The upside is so small that I'm not convinced it offsets the downside. It wasn't even possible to say for certain that there was an upside until we got to relatively large numbers of repeat applications of the same glob pattern. (It's definitely possible that the additional complexity increases the cost for simpler cases.)
I can't remember the specific use cases for this. Do we have reason to believe that this is featuring in critical loops somewhere?

I'm looking at what it looks like if we reduce the max string length to 12bits (i.e. 4095 characters) which is fine for URIs as the max usable length is 2,048 characters, along with validation in the GlobToken constructor (which just checks the bits).
This allows us to put a packed value in a uint with 2x12 bits for the start and end, and 8 bits for the token type, along with unchecked unpacking (because we know we are safe from the constructor validation).
A couple of tweaks to the implementation to pull ensure the unpacking of those values occurs at a minimum, gives us measurable performance improvements.

(I failed to answer this question earlier: I can't remember the specific use cases for this. Do we have reason to believe that this is featuring in critical loops somewhere?)
The most important use case for us is in permissions validation. We use glob matching of URIs to determine Allow/Deny permission in permission sets.
This is then used both in determining access to those resources, and in e.g. stripping linked/embedded resources from HAL documents based on those permissions.
This is another example where every request will do many such checks, and shaving cost out of this operation is another of those "cumulative savings" - especially under load.