error: failed to extract archive (Write failed)

Sorry if this isn't the right place to ask for help with this issue.
I have a wheel I've built with the following command: pip wheel --wheel-dir=/tmp/wheelhouse quickfix
And a shell.nix that looks like this:

shell.nix
let
  pkgs = import <nixpkgs> {};
  mach-nix = import (builtins.fetchGit {
    url = "https://github.com/DavHau/mach-nix";
    ref = "refs/tags/3.4.0";
  }) {
    python = "python39";
  };

  # HACK: See https://github.com/DavHau/mach-nix/issues/454
  fake_reqs = "loguru";
in
with pkgs;

mach-nix.mkPythonShell {
    requirements = ''
        loguru
    '';

    packagesExtra = [
        (mach-nix.buildPythonPackage {
          pname = "quickfix";
          version = "1.15.1";
          format = "wheel";
          src = ./quickfix-1.15.1-cp39-cp39-linux_x86_64.whl;
          buildInputs = [gcc];
          requirements = fake_reqs;
        })
    ];
}

This used to work fine, but now I'm getting an error. Here's the trace:

nix-shell --show-trace
error: failed to extract archive (Write failed)

   … while evaluating the attribute 'buildCommand' of the derivation 'pypi-deps-db'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/stdenv/generic/make-derivation.nix:205:7:

      204|     // (lib.optionalAttrs (attrs ? name || (attrs ? pname && attrs ? version)) {
      205|       name =
         |       ^
      206|         let

   … while evaluating the attribute 'buildInputs' of the derivation 'mach_nix_file'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/stdenv/generic/make-derivation.nix:205:7:

      204|     // (lib.optionalAttrs (attrs ? name || (attrs ? pname && attrs ? version)) {
      205|       name =
         |       ^
      206|         let

   … while evaluating the attribute 'overrides'

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/lib.nix:187:7:

      186|     in {
      187|       overrides = result.overrides manylinux autoPatchelfHook;
         |       ^
      188|       select_pkgs = result.select_pkgs;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:76:22:

       75|     f: g: final: prev:
       76|       let fApplied = f final prev;
         |                      ^
       77|           prev' = prev // fApplied;

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:78:22:

       77|           prev' = prev // fApplied;
       78|       in fApplied // g final prev';
         |                      ^
       79|

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:69:67:

       68|   #
       69|   extends = f: rattrs: self: let super = rattrs self; in super // f self super;
         |                                                                   ^
       70|

   … while evaluating 'extends'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:69:24:

       68|   #
       69|   extends = f: rattrs: self: let super = rattrs self; in super // f self super;
         |                        ^
       70|

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:233:14:

      232|       spliced = extra spliced0 // spliced0 // keep self;
      233|       self = f self // {
         |              ^
      234|         newScope = scope: newScope (spliced // scope);

   … while evaluating 'makeScopeWithSplicing'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:222:80:

      221|      hopefully it helps a little bit. */
      222|   makeScopeWithSplicing = splicePackages: newScope: otherSplices: keep: extra: f:
         |                                                                                ^
      223|     let

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/development/interpreters/python/default.nix:79:12:

       78|           aliases = self: super: lib.optionalAttrs (config.allowAliases or true) (import ../../../top-level/python-aliases.nix lib self super);
       79|         in lib.makeScopeWithSplicing
         |            ^
       80|           pkgs.splicePackages

   … while evaluating anonymous lambda

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/development/interpreters/python/default.nix:25:10:

       24|       pythonPackages = callPackage
       25|         ({ pkgs, stdenv, python, overrides }: let
         |          ^
       26|           pythonPackagesFun = import ../../../top-level/python-packages.nix {

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:69:16:

       68|     let
       69|       result = f origArgs;
         |                ^
       70|

   … while evaluating 'makeOverridable'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:67:24:

       66|   */
       67|   makeOverridable = f: origArgs:
         |                        ^
       68|     let

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:121:8:

      120|       auto = builtins.intersectAttrs (lib.functionArgs f) autoArgs;
      121|     in makeOverridable f (auto // args);
         |        ^
      122|

   … while evaluating 'callPackageWith'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:117:35:

      116|   */
      117|   callPackageWith = autoArgs: fn: args:
         |                                   ^
      118|     let

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/development/interpreters/python/default.nix:24:24:

       23|     }: let
       24|       pythonPackages = callPackage
         |                        ^
       25|         ({ pkgs, stdenv, python, overrides }: let

   … while evaluating the attribute 'pkgs.buildPythonPackage'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/development/interpreters/python/default.nix:106:9:

      105|         withPackages = import ./with-packages.nix { inherit buildEnv pythonPackages;};
      106|         pkgs = pythonPackages;
         |         ^
      107|         interpreter = "${self}/bin/${executable}";

   … while evaluating 'buildPythonPackageBase'

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/buildPythonPackage.nix:9:5:

        8|   buildPythonPackageBase = pythonGlobal: func:
        9|     args@{
         |     ^
       10|       cudaVersion ? pkgs.cudatoolkit.version,  # max allowed cuda version for conda packages

   … from call site

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/buildPythonPackage.nix:82:21:

       81|
       82| python: func: args: buildPythonPackageBase python func (l.translateDeprecatedArgs args)
         |                     ^

   … while evaluating anonymous lambda

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/buildPythonPackage.nix:82:15:

       81|
       82| python: func: args: buildPythonPackageBase python func (l.translateDeprecatedArgs args)
         |               ^

   … from call site

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/default.nix:60:9:

       59|       else
       60|         (import ./mach_nix/nix/buildPythonPackage.nix machnixArgs) python func (l.throwOnDeprecatedArgs func args);
         |         ^
       61|

   … while evaluating '_buildPython'

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/default.nix:51:24:

       50|
       51|   _buildPython = func: args:
         |                        ^
       52|     let

   … from call site

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/default.nix:49:31:

       48|
       49|   __buildPython = func: args: _buildPython func (throwOnOutdatedData args);
         |                               ^
       50|

   … while evaluating '__buildPython'

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/default.nix:49:25:

       48|
       49|   __buildPython = func: args: _buildPython func (throwOnOutdatedData args);
         |                         ^
       50|

   … from call site

   at /home/myuser/proj/autotradazord/shell.nix:41:10:

       40|
       41|         (mach-nix.buildPythonPackage {
         |          ^
       42|           pname = "quickfix";

   … while evaluating 'is_src'

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/lib.nix:235:12:

      234|
      235|   is_src = input: ! input ? passthru;
         |            ^
      236|

   … from call site

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/mkPython.nix:59:21:

       58|           }
       59|       ) (filter (p: l.is_src p || p ? pythonModule) packagesExtra);
         |                     ^
       60|       extra_pkgs_r = filter (p: p ? rCommand) packagesExtra;

   … while evaluating anonymous lambda

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/mkPython.nix:59:18:

       58|           }
       59|       ) (filter (p: l.is_src p || p ? pythonModule) packagesExtra);
         |                  ^
       60|       extra_pkgs_r = filter (p: p ? rCommand) packagesExtra;

   … from call site

   … while evaluating 'flatten'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/lists.nix:137:13:

      136|   */
      137|   flatten = x:
         |             ^
      138|     if isList x

   … from call site

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/mkPython.nix:92:29:

       91|       );
       92|       overrides_pre_extra = flatten (map (p: p.passthru.overridesPre) extra_pkgs_python);
         |                             ^
       93|       overrides_post_extra = flatten (map (p: p.passthru.overridesPost) extra_pkgs_python);

   … while evaluating 'foldl''

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/lists.nix:82:16:

       81|     let
       82|       foldl' = n:
         |                ^
       83|         if n == -1

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/lists.nix:86:8:

       85|         else op (foldl' (n - 1)) (elemAt list n);
       86|     in foldl' (length list - 1);
         |        ^
       87|

   … while evaluating 'foldl'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/lists.nix:80:20:

       79|   */
       80|   foldl = op: nul: list:
         |                    ^
       81|     let

   … from call site

   at /nix/store/h88mkfsmnchwn89a3mbgh7d6ixy1di5l-source/mach_nix/nix/mkPython.nix:111:23:

      110|
      111|       all_overrides = l.mergeOverrides (
         |                       ^
      112|         overridesPre ++ overrides_pre_extra

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:78:22:

       77|           prev' = prev // fApplied;
       78|       in fApplied // g final prev';
         |                      ^
       79|

   … while evaluating 'composeExtensions'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:75:18:

       74|   composeExtensions =
       75|     f: g: final: prev:
         |                  ^
       76|       let fApplied = f final prev;

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:69:67:

       68|   #
       69|   extends = f: rattrs: self: let super = rattrs self; in super // f self super;
         |                                                                   ^
       70|

   … while evaluating 'extends'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/fixed-points.nix:69:24:

       68|   #
       69|   extends = f: rattrs: self: let super = rattrs self; in super // f self super;
         |                        ^
       70|

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:233:14:

      232|       spliced = extra spliced0 // spliced0 // keep self;
      233|       self = f self // {
         |              ^
      234|         newScope = scope: newScope (spliced // scope);

   … while evaluating 'makeScopeWithSplicing'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:222:80:

      221|      hopefully it helps a little bit. */
      222|   makeScopeWithSplicing = splicePackages: newScope: otherSplices: keep: extra: f:
         |                                                                                ^
      223|     let

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/development/interpreters/python/default.nix:79:12:

       78|           aliases = self: super: lib.optionalAttrs (config.allowAliases or true) (import ../../../top-level/python-aliases.nix lib self super);
       79|         in lib.makeScopeWithSplicing
         |            ^
       80|           pkgs.splicePackages

   … while evaluating anonymous lambda

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/development/interpreters/python/default.nix:25:10:

       24|       pythonPackages = callPackage
       25|         ({ pkgs, stdenv, python, overrides }: let
         |          ^
       26|           pythonPackagesFun = import ../../../top-level/python-packages.nix {

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:69:16:

       68|     let
       69|       result = f origArgs;
         |                ^
       70|

   … while evaluating 'makeOverridable'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:67:24:

       66|   */
       67|   makeOverridable = f: origArgs:
         |                        ^
       68|     let

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:121:8:

      120|       auto = builtins.intersectAttrs (lib.functionArgs f) autoArgs;
      121|     in makeOverridable f (auto // args);
         |        ^
      122|

   … while evaluating 'callPackageWith'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/lib/customisation.nix:117:35:

      116|   */
      117|   callPackageWith = autoArgs: fn: args:
         |                                   ^
      118|     let

   … from call site

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/development/interpreters/python/default.nix:24:24:

       23|     }: let
       24|       pythonPackages = callPackage
         |                        ^
       25|         ({ pkgs, stdenv, python, overrides }: let

   … while evaluating the attribute 'passAsFile'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/build-support/buildenv/default.nix:77:5:

       76|     # XXX: The size is somewhat arbitrary
       77|     passAsFile = if builtins.stringLength pkgs >= 128*1024 then [ "pkgs" ] else [ ];
         |     ^
       78|   }

   … while evaluating the attribute 'passAsFile' of the derivation 'python3-3.9.9-env'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/stdenv/generic/make-derivation.nix:205:7:

      204|     // (lib.optionalAttrs (attrs ? name || (attrs ? pname && attrs ? version)) {
      205|       name =
         |       ^
      206|         let

   … while evaluating the attribute 'nativeBuildInputs' of the derivation 'interactive-python3-3.9.9-environment'

   at /nix/store/5n402azp0s9vza4rziv4z5y88v2cv1mq-nixpkgs/pkgs/stdenv/generic/make-derivation.nix:205:7:

      204|     // (lib.optionalAttrs (attrs ? name || (attrs ? pname && attrs ? version)) {
      205|       name =
         |       ^
      206|         let

Just encountered the same issue. Turns out my /tmp drive was full; freeing up some space there resolved the issue.


Fix stride in 1D and  2D convolution example

The stride in the 2D convolution example was not implemented correctly. The for loops did not consider the stride which lead to issues when changing to another example including a stride different from (1,1).

Now, it is fixed. There was a multiplication with the stride itself missing as the loops give the indices in the corresponding padded matrices. In the very simple, stride=1 case, it worked correctly.
Likely also wrong in the 1D case. Have to check that more carefully as well.

Now, it should be fixed. Sorry for taking a bit longer with this in the pull request.

Thanks so much for the kind update. This is awesome! I added a note & acknowledgement to the errata so I don't forget updating this in the book, too!


Write Documentation for Gatsby Site

This is one of three issues related to refactoring this project to Gatsby (see #12 ).
Issue Summary
This issue will track the creation and editing process for the Gatsby-based documentation.
This documentation should be easy to read for people new to Github and Open-Source. Since  members of the CSA range widely in experience, having a solid, and easy to follow README in the repo will hopefully encourage new contributors to make their first PR!
Beyond a general README, it's also important that we document the basic structure of the repository and link off to more information explaining the more advanced portions of the codebase.
Action Items

[x] Create a beginner friendly README (how to develop locally, basic explanation of concepts, required libraries (like prettier for code formatting),  links to further reading, etc) 📚
[x] Update contribution docs to reflect the gatsby setup 🔧
[x] Create specific docs for different parts of the repository :memo:

[x] Pages Directory
[x] Components Directory

Note: I'm starting work on this right now, but changes wont appear in the repo until #16 is merged in!

This issue was resolved with #17


no longer default to webrick

Rack respects $RACK_HANDLER when no args are supplied
Rack will default to thin, then puma, then webrick by default (need to
recommend doing puma first).

LGTM


dpbench crashing with numba-dpex 0.19.0

Dpbench is reporting errors when using the latest version of numba dpex 0.19.0, after setting sycl device to gpu:
Using black scholes as an example:
On Gen9:
> ================ Benchmark black_scholes ========================
>
> /localdisk/work/mingjie2/miniconda3/envs/dpex_825/lib/python3.9/site-packages/llvmlite/llvmpy/__init__.py:3: UserWarning: The module `llvmlite.llvmpy` is deprecated and will be removed in the future.
>   warnings.warn(
> /localdisk/work/mingjie2/miniconda3/envs/dpex_825/lib/python3.9/site-packages/llvmlite/llvmpy/core.py:8: UserWarning: The module `llvmlite.llvmpy.core` is deprecated and will be removed in the future. Equivalent functionality is provided by `llvmlite.ir`.
>   warnings.warn(
> ERROR:root:Benchmark execution failed at the warmup step.
> Traceback (most recent call last):
>   File "/localdisk/work/mingjie2/sandbox/numba_dpex_825/dpbench/dpbench/infrastructure/benchmark.py", line 93, in _exec
>     warmup(impl_fn, inputs)
>   File "/localdisk/work/mingjie2/sandbox/numba_dpex_825/dpbench/dpbench/infrastructure/benchmark.py", line 89, in warmup
>     fmwrk.execute(impl_fn, inputs)
>   File "/localdisk/work/mingjie2/sandbox/numba_dpex_825/dpbench/dpbench/infrastructure/framework.py", line 123, in execute
>     return impl_fn(**input_args)
>   File "/localdisk/work/mingjie2/sandbox/numba_dpex_825/dpbench/dpbench/benchmarks/black_scholes/black_scholes_dpnp.py", line 19, in black_scholes
>     b = T * mr
>   File "dpctl/tensor/_usmarray.pyx", line 907, in dpctl.tensor._usmarray.usm_ndarray.__mul__
>   File "dpctl/tensor/_usmarray.pyx", line 68, in dpctl.tensor._usmarray._dispatch_binary_elementwise
>   File "/localdisk/work/mingjie2/miniconda3/envs/dpex_825/lib/python3.9/site-packages/dpnp/dpnp_iface_mathematical.py", line 1125, in multiply
>     return call_origin(numpy.multiply, x1, x2, dtype=dtype, out=out, where=where, **kwargs)
>   File "dpnp/dpnp_utils/dpnp_algo_utils.pyx", line 120, in dpnp.dpnp_utils.dpnp_algo_utils.call_origin
> NotImplementedError: Requested funtion=multiply with args=(<dpctl.tensor._usmarray.usm_ndarray object at 0x7f79be5744a0>, -0.1) and kwargs={'dtype': None, 'out': None, 'where': True} isn't currently supported and would fall back on NumPy implementation. Define enviroment variable `DPNP_RAISE_EXCEPION_ON_NUMPY_FALLBACK` to `0` if the fall back is required to be supported without rasing an exception.
> ERROR:root:Benchmark execution failed at the warmup step.
> Traceback (most recent call last):
>   File "/localdisk/work/mingjie2/sandbox/numba_dpex_825/dpbench/dpbench/infrastructure/benchmark.py", line 93, in _exec
>     warmup(impl_fn, inputs)
>   File "/localdisk/work/mingjie2/sandbox/numba_dpex_825/dpbench/dpbench/infrastructure/benchmark.py", line 89, in warmup
>     fmwrk.execute(impl_fn, inputs)
>   File "/localdisk/work/mingjie2/sandbox/numba_dpex_825/dpbench/dpbench/infrastructure/framework.py", line 123, in execute
>     return impl_fn(**input_args)
> RuntimeError: Native API failed. Native API returns: -997 (Command failed to enqueue/execute) -997 (Command failed to enqueue/execute)
> ================ implementation dpnp ========================
> implementation: dpnp
> error states: ErrorCodes.FAILED_EXECUTION
> error msg: Execution failed
> ================ implementation numba_dpex_k ========================
> implementation: numba_dpex_k
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation numba_dpex_n ========================
> implementation: numba_dpex_n
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation numba_dpex_p ========================
> implementation: numba_dpex_p
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation numba_n ========================
> implementation: numba_n
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation numba_np ========================
> implementation: numba_np
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation numba_npr ========================
> implementation: numba_npr
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation numpy ========================
> implementation: numpy
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation python ========================
> implementation: python
> error states: ErrorCodes.SUCCESS
> error msg:
> ================ implementation sycl ========================
> implementation: sycl
> error states: ErrorCodes.FAILED_EXECUTION
> error msg: Execution failed

On newer than Gen9, it crashed out:
================ Benchmark black_scholes ========================

/home/mingjie2/.conda/envs/dpben_test/lib/python3.9/site-packages/llvmlite/llvmpy/__init__.py:3: UserWarning: The module `llvmlite.llvmpy` is deprecated and will be removed in the future.
  warnings.warn(
/home/mingjie2/.conda/envs/dpben_test/lib/python3.9/site-packages/llvmlite/llvmpy/core.py:8: UserWarning: The module `llvmlite.llvmpy.core` is deprecated and will be removed in the future. Equivalent functionality is provided by `llvmlite.ir`.
  warnings.warn(
ERROR:root:Benchmark execution failed at the warmup step.
Traceback (most recent call last):
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/infrastructure/benchmark.py", line 93, in _exec
    warmup(impl_fn, inputs)
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/infrastructure/benchmark.py", line 89, in warmup
    fmwrk.execute(impl_fn, inputs)
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/infrastructure/framework.py", line 123, in execute
    return impl_fn(**input_args)
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/benchmarks/black_scholes/black_scholes_dpnp.py", line 19, in black_scholes
    b = T * mr
  File "dpctl/tensor/_usmarray.pyx", line 907, in dpctl.tensor._usmarray.usm_ndarray.__mul__
  File "dpctl/tensor/_usmarray.pyx", line 68, in dpctl.tensor._usmarray._dispatch_binary_elementwise
  File "/home/mingjie2/.conda/envs/dpben_test/lib/python3.9/site-packages/dpnp/dpnp_iface_mathematical.py", line 1125, in multiply
    return call_origin(numpy.multiply, x1, x2, dtype=dtype, out=out, where=where, **kwargs)
  File "dpnp/dpnp_utils/dpnp_algo_utils.pyx", line 120, in dpnp.dpnp_utils.dpnp_algo_utils.call_origin
NotImplementedError: Requested funtion=multiply with args=(<dpctl.tensor._usmarray.usm_ndarray object at 0x1481423cd3c0>, -0.1) and kwargs={'dtype': None, 'out': None, 'where': True} isn't currently supported and would fall back on NumPy implementation. Define enviroment variable `DPNP_RAISE_EXCEPION_ON_NUMPY_FALLBACK` to `0` if the fall back is required to be supported without rasing an exception.
ERROR:root:Benchmark execution failed due to the following error:
Traceback (most recent call last):
  File "dpctl/tensor/_usmarray.pyx", line 971, in dpctl.tensor._usmarray.usm_ndarray.__setitem__
  File "/home/mingjie2/.conda/envs/dpben_test/lib/python3.9/site-packages/dpctl/tensor/_copy_utils.py", line 95, in _copy_from_numpy_into
    ti._copy_numpy_ndarray_into_usm_ndarray(
RuntimeError: Native API failed. Native API returns: -5 (CL_OUT_OF_RESOURCES) -5 (CL_OUT_OF_RESOURCES)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/runner.py", line 101, in run_benchmark
    results = bench.run(
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/infrastructure/benchmark.py", line 907, in run
    runner = BenchmarkRunner(
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/infrastructure/benchmark.py", line 453, in __init__
    self._setup()
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/infrastructure/benchmark.py", line 514, in _setup
    {arg: self.fmwrk.copy_to_func()(npdata)}
  File "/home/mingjie2/dpbench_test/dpbench/dpbench/infrastructure/numba_dpex_kernel_framework.py", line 43, in _copy_to_func_impl
    return dpt.asarray(
  File "/home/mingjie2/.conda/envs/dpben_test/lib/python3.9/site-packages/dpctl/tensor/_ctors.py", line 390, in asarray
    return _asarray_from_numpy_ndarray(
  File "/home/mingjie2/.conda/envs/dpben_test/lib/python3.9/site-packages/dpctl/tensor/_ctors.py", line 271, in _asarray_from_numpy_ndarray
    res[...] = ary
  File "dpctl/tensor/_usmarray.pyx", line 973, in dpctl.tensor._usmarray.usm_ndarray.__setitem__
ValueError: Input of type <class 'numpy.ndarray'> could not be converted to usm_ndarray

It seems related to the way to launch the benchmarks. On newer than Gen 9 devices, the dpbench can be executed by running:
python -c "import dpbench; dpbench.run_benchmarks()"

Crashing out happens when running:
 python -c "import dpbench; dpbench.run_benchmark(\"black_scholes\")"

This issue does not seem to occur now with 0.19.0. See here - https://github.com/IntelPython/dpbench/actions/runs/4128863355/jobs/7133823921.
Closing issue since it no longer occurs. Re-open if necessary.


No such module 'Material' in Xcode 8.1

~/Downloads/Samples-master/Material/Programmatic/Card/Card/ViewController.swift:32:8: No such module 'Material' in Xcode 8.1

Step1: ./install_all_pods.sh
Step2: import the Card project in Xcode 8.1 only. e.x: File-open-Samples/Material/Programmatic/Card/Card.xcworkspace
Step3: Run and Enjoy.

Going to look into this today.

Did you have the CosmicMind workspace opened when you tried opening the sample project directly ?

Make sure you are opening the project workspace itself, not the CosmicMind one, that is for manual addition of frameworks :) If you continue to have issues, please reopen or create a new issue. Thank you!

Hey @danieldahan when you say

that is for manual addition of frameworks
How do you accomplish that? I was able to do it once where I used the Sample.workspace and remember having to add something to get project to build there but I cannot for the life of me remember how to do it.

@MacMeDan GitHub is for manual addition of the frameworks. I thought you are using Carthage? Here are the 3 installation methods. You can also drag the project into the Samples workspace and then add the frameworks into the projects you are wanting to use.

Yes I am using Carthage I was trying to get the Samples app up and running so I could look at how things work there. I think I figured out what I was mission. I needed to download the Material project and build the Motion and Material targets. Take those frameworks and add them manually to each project in the Samples project.

@MacMeDan yes that is exactly correct.

I update my pod to latest version that solve my problem!

Awesome! @Beyond-Chao


renamed Azure AD to Entra ID

Why:
Azure AD has been renamed to Entra ID and it haven't been updated in GitHub doc
Closes:

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[ ] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[ ] For content changes, I have completed the self-review checklist.

@speter04 Thanks so much for opening a PR! I'll get this triaged for review ✨

Thanks @speter04, but we're tracking this update internally.


Github Discussions

Could you go to the settings tab and find Discussions, and click enable. THis will turn on Github Discussions for your project which allows communication without opening an issue

Thanks for the suggestion! I have the Discord channel for that purpose, but I'm willing to give GitHub discussions a try.


deploy-local override entrypoint with sleep

Requires https://github.com/epics-containers/ec-helm-charts/pull/15

Does this PR require a change to the helm chart?
All looks good.

Yes, the proposed change is linked. Although I think its fair to say the default values (entry point in this case) have not been done the same as the rest of our parameters - where we have set the defaults in the chart values.yaml - and not the template like I have done here.
I feel like the required entrys in the beamline shared values.yaml should be the things that are beamline specific. Perhaps key-values pairs like iocFolder: /epics/ioc should have defaults set in the ioc-instance template. In this way they are still override-able but its not required per beamline

Does this PR require a change to the helm chart?
All looks good.

Yes, the proposed change is linked. Although I think its fair to say the default values (entry point in this case) have not been done the same as the rest of our parameters - where we have set the defaults in the chart values.yaml - and not the template like I have done here.
I feel like the required entrys in the beamline shared values.yaml should be the things that are beamline specific. Perhaps key-values pairs like iocFolder: /epics/ioc should have defaults set in the ioc-instance template. In this way they are still override-able but its not required per beamline

Does this PR require a change to the helm chart?
All looks good.

Yes, the proposed change is linked. Although I think its fair to say the default values (entry point in this case) have not been done the same as the rest of our parameters - where we have set the defaults in the chart values.yaml - and not the template like I have done here.
I feel like the required entrys in the beamline shared values.yaml should be the things that are beamline specific. Perhaps key-values pairs like iocFolder: /epics/ioc should have defaults set in the ioc-instance template. In this way they are still override-able but its not required per beamline

There might be something strange happening. When I read the Helm documentation, it seems that the subchart values.yaml should be the default - however - when I tried this then these values were ignored. This is why I ended up putting it in the template because they seemed to be ignored

We have decided to fix the issue by allowing override through exposing of the entry point in the sub chart


The getter 'element' isn't defined for the class 'InterfaceType'.

Looks like https://github.com/SunnyDayDev/autoequal/commit/1f4cd66138326d45c2837b3445a21d64841960c5 broke the generator when used with analyzer: ^5.0.0.
DartType.element has been deprecated in v4.4.0 and removed in v5.0.0. It will have to be migrated to DartType.element2.
I'll submit a PR later.

@mrgnnnt96 FYI
If I remember correctly, @techouse has already fixed this issue before. Неre #8.

Oops, sorry about that. element2 has a deprecated annotation. Didn't realize that this was an intentional change. I'll create the PR really quick with the change 👍

Hey, @techouse !
I checked the source code of analyzer and found that element2 was deprecated in 5.2.0.
element was deprecated in 4.7.0, removed in 5.0.0 and restored in 5.2.0. So sometime element2 will be removed. In this case, do we need to support it? What do you think?
  @Deprecated('Use element instead')
  @override
  InterfaceElement get element2;

Yeah, it's a mess 🙈, however, I doubt that they will remove element2 before v6.0.0.

@techouse could you provide us with a minimal code example? I would like to add this to our tests to avoid breaking this in future versions

It's kinda hard to test for a function that got removed. I tried to make something similar. It's just not a thing in Dart as it is in JS.

All good, in your project you're using analyzer: ^5.0.0 and that is what broke your builder?
It might be worth it to update our analyzer dependency to latest. In the meantime, we will fix this in the next version with the current versioning.

Correct.


How to limit post value length？

like this
parser.add_argument('username', type=str, required=True,length=(1,64))

Keep in mind the type parameter is a callable that takes one parameter.  Use a function that checks whatever it needs to and raises ValueError with an appropriate message when the value isn't suitable.


Visual instance layers are regarded during shadow culling

This PR deals with #43827 and #54613 by simply passing the visible layers to update_shadow of the VisualServer. This seems to work for both directional and non-directional lights. After changing the layers of a GeometryInstance, affected shadows are updated.
What is not yet done are updated shadows after changing the Camera cull_mask. I am not sure how to get the affected lights.

This looks on the surface good. There is something I need to refresh my memory on though, it came up for me when looking at some shadow optimizations in 2019. The problem is that for non-directional lights (spot and omnis) Godot doesn't render the shadow map continuously, it only renders when it is dirty, i.e. when the light moves, or one of the instances move.
I was kind of surprised by this, as I didn't expect this situation to happen that often in real games, as opposed to tech demos. But this prevented me using a tighter cull on the shadow casters to the view frustum intersection, because this optimization assumed that they were re-rendered each frame.
So the potential problem I can see is that this may not play well with camera cull masks. If you have two cameras with different cull masks, you essentially have to keep rendering the shadow map for each camera for each frame, and this dirty must be disabled? Unless you have a shadow map per camera (which I don't think is the case currently).
So although this works for a single camera, have you tried it with multiple cameras with multiple cull masks?

@lawnjelly, thanks for the background info. As far as I understood, shadows for non-directionals are rendered into the viewports shadow atlases which are usually unique to different cameras. I created a demo project which shows a scene from two cameras. The position and visual layer of the shadow caster are animated. It seems to show correct behavior.

Ah that's good, that may not be a problem then if that is the case. :grin: (sorry I'm not super familiar with this area, but would rather try to point out anything that could be affected and be wildly wrong, as there aren't many that work in this area at the moment.)

Does this PR have a 4.0 counter part? Asking as it is relevant there too.

Does this PR have a 4.0 counter part? Asking as it is relevant there too.

No, this PR doesn't.

If you are interested, could you take a stab at making the same changes in 4.0?

Yes, I will look into it soon.

Thanks! And congrats for your first merged Godot contribution :tada:


[BUG] Most machines remove items with 'Unbreakable' Tag

Description:

Have only tested with Fisher and Mining Rig, however using any item with the 'Unbreakable' Tag still breaks / gets removed after some time on a server.

Steps to Reproduce:

Place & Power a fisher or mining rig.
Using either commands or using the 'Hardening Catalyst' from the Things mod, make the required tool 'Unbreakable'
Not really sure if you have to unload and reload the area or whatever, but after some time the item will just disappear

Technical Information:

Minecraft: 1.16.5
Fabric API: 0.40.6
Industrial Revolution: 1.9.18
Modpack: n/a

Logs:

Use a paste service, do not paste the logs directly here.
Have no applicable logs

Details:
Extra information that might be helpful like screenshots or technical information about your computer.
I have no clue what actually causes it to use items with the unbreakable tag. It sometimes does remove, sometimes doesn't.

just ran into this today actually, Unloading is not needed, it just ignores the unbreakable tag entirely.


PKIX module changes certificate DNs.

https://github.com/golang/go/blob/0b2ad1d815ea8967c49b32d848b2992d0c588d88/src/crypto/x509/pkix/pkix.go#L226
If I create an X509 certificate, and then pull out the subject DN, it looks like this:
C = XX, ST = Confusion, L = Somewhere, OU = first, OU = a002, OU = third, OU = b004, O = example, CN = chunkbox
Note that there are multiple values for OrganizationalUnit, but they are separate RDNs.
When I print what is returned from Caddy, which uses the go PKIX module, it looks like this:
CN=chunkbox,OU=first+OU=a002+OU=third+OU=b004,O=example,L=Somewhere,ST=Confusion,C=XX
The subject DN from the certificate is not equivalent to the subject DN that I get back from the PKIX module.

Duplicate of #27401

@seankhliao I realized that after filing this one.  That ticket is from back in 2018.  Are there plans to implement some kind of fix?


Translate concepts/scheduling-eviction/kube-scheduler.md in Korean.

This is a Feature Request
What would you like to be added
Translate concepts/scheduling-eviction/kube-scheduler.md in Korean.
Why is this needed
The following files are not translated into Korean.

[ ] /en/docs/concepts/scheduling-eviction/kube-scheduler.md

Comments
Page to update: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
I am translating this document.
The translated document will be submitted to dev-1.18-ko.3 branch.
/language ko

/assign

/close


[Policy]: Do not allow deletion of resource types

Policy Definition or Initiative
Definition
Built-in/Custom
Built-in
Built-in policy definition or initiative ID
78460a36-508a-49a4-b2b2-2f5ec564f4bb
Custom policy definition or initiative description
A policy that is an alternative to Resource Locks for critical infrastructure components.
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/management-platform#inventory-and-visibility-recommendations
"Use resource locks to prevent accidental deletion of critical shared services."
There are many known (and unknown) limitations to the use of resource locks; some are mentioned here:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json#considerations-before-applying-your-locks
For example, resource locks break Azure Backup of VMs Managed Disks, it will break Sentinel, etc.
Many of the resources are critical, e.g., Backups or Sentinel, and you do not want these resources to be deleted - purposely or accidentially.
Therefore, there should be a recommendation to use the DenyAction-effect instead of resource locks.
The policy should be on different scopes.
E.g. Sentinel and Backups in the Management MG.
E.g. Landing Zones to ensure that resource locks are not inherited for RGs.
Can for instance be combined with tags for more granularity, etc.
It would be great if Microsoft could sum up more use-cases where resource lock (CanNotDelete or read-only) cannot be used. Then DenyAction is an alternative.
Built-in policy:
https://www.azadvertizer.net/azpolicyadvertizer/78460a36-508a-49a4-b2b2-2f5ec564f4bb.html
Scope
Multiple / Other
Default Assignment

[x] Yes

Comments/thoughts
No response

@vegazbabz many thanks for submitting this suggestion using our shiny new Policy Suggestion form! ;)
This is a great suggestion, and we're looking into how to reasonably implement this for ALZ. Most likely we will look at assigning this to the Platform management group for the resources we deploy as part of ALZ only, as you have a valid point around protecting critical infrastructure. Of course, it's still not perfect as policy team can create an exemption and you can still delete the resource (just like you can work around the resource locks). The intention of resource locks is to prevent accidental deletion using the "DoNotDelete" lock, but to your point "ReadOnly" can be troublesome.
We do provide a couple of policies in ALZ to "demo" the concept of DenyAction, specifically for ActivityLogs and DiagnosticLogs, but we don't assign those by default.
This isn't necessarily the right solution for all Azure services though. For example, for Backup/Recovery Vaults a much better solution is to use Multi-User Authentication (MUA) or Immutability, so we would use this mechanism to protect those resources. Likewise, a number of critical infra resources have their own protection mechanisms that at least allow easy recovery from accidental deletion - Key Vault, APIM, etc. so it's not necessarily the right solution for all services.
That said, we're looking at applying this to our core infra as part of ALZ.
Many thanks again for your submission!

Another use case that I also wrote to DfS PG is to include a DenyAction policy for the malware protection capabilities, which is deployed as a Logic App or Event Grid.

Hi @vegazbabz. We've circled back to review this issue and are using this to protect the user assigned identity created for AMA. We currently won't be using the DenyAction policy for other resources due to the many assignment scopes/resources and associated complexity, as you highlight in your original post, which also provides great guidance on where using this policy is desirable.
You have a great request for more information on scenarios where resource locks interfere with the proper functioning of resources. For this, may I ask that you submit feedback at https://feedback.azure.com for better guidance on this topic?

Closing as no further action on ALZ team.


[Fix #7099] Fix an error in Layout/RescueEnsureAlignment cop

Fixes #7099.
When running rubocop against the below code where the block was assigned to a variable, it was expected that Layout/RescueEnsureAlignment cop would register an offense, but an error occurred in the cop.
result = [1, 2, 3].map do |el|
  rescue StandardError => _exception
end

This change fixes that.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

@koic
Thank you for your review!
I've removed unnecessary \.

Rebased to resolve the conflict.

Thanks!


Refactor place method

This PR aims to clean the API concerning pole placement, and add fallback strategy in case scipy or slycot are not installed.
There is also a little bit of style refactor and unit test of test_statefbk.py do not require np.matrix anymore, as it will soon be deprecated.
This PR is linked to this issue https://github.com/python-control/python-control/issues/255

Coverage decreased (-1.4%) to 76.967% when pulling 2551111bb6ed16180ef076bb11b7d5ed319b5fe7 on don4get:refactor/statefbk into 31e694441dbb101f7e601dce2b8dfa3e97ec2a1a on python-control:master.

This PR has several changes, some of which seem fine but other that I have questions about.  See review comments.

This may just be personal preference, but I don't particularly like the idea of placing the poles with a method other than what the user specified (i.e., the fallback strategies). In my view, there are several drawbacks to this:

The code to achieve this is rather complex. This makes it more difficult to reason about what the function will actually do and also makes testing all the possible code paths harder. For instance, the path "varga" -> "YT" -> "acker" is, as far as I can tell, not  exercised in the updated test suite.

The second problem is that the methods are not really equivalent. For example, if the user specified "varga", and that fails for some reason, now we call place with "YT". But unless alpha is None, the result will not be what the user wanted. Similarly for devolving to acker when "YT" fails, because "YT" is numerically stable but acker is not. This can matter a great deal for some systems.

It is possible that this PR will break users code. It is not too far fetched to imagine a scenario (e.g., a parameter sweep) that relies on place producing an error when two desired pole locations become too close. This PR would break (or at least change the behavior of) such a script.

In short, if the only way to get the poles placed is by calling place with "acker" or whatever, I don't see the downside to just letting the user decide that.
One final concern is that, as it stands, the docstring is not really accurate any more, because it describes (in the "algorithms" and "limitations" sections) the YT algorithm, not Ackermann's method or Varga's method or KNV0.

@don4get There are some good changes in this PR, but needs to address the comment in this this thread.  Specifically:

We need to rethink the "automatic" use of a backup strategy, as pointed out by @rabraker.  One possibility would be to allow method to be a list, where you try the next method in the list if the first fails.  Another would be to add a keyword fallback that would default to False (to preserve existing behavior) but that could be used to enable the use of fallback strategies.

@repagh's comments on the the ControlSlycot exception should be addressed.  Note also that PR #305 makes the ControlSlycot exception derive from ImportError instead of Exception.

Please revert test_statefbk.py back tot statefbk_test.py to be consistent with the predominant naming convention for test files in tests/ (I understand this is different than numpy),

Other small comments raised in the reviews should be resolved.

Need to resolve conflicts against the current master branch.

PR has been idle for > 6  months => stale.  @don4get I will close this PR in a few days unless you will have time to work on it soon.  No worries if not; just re-open when you have responded to the comments above.


Question: Is it possible to create new members of AGOL org with ArcREST / REST API?

I cannot find an operation that would let administrator to invite users to join ArcGIS Online organization in the REST API, so I am not sure if it's in the ArcREST either.
You can add a new user in the AGOL admin page and then choosing one of the options how you want a user to be created (for example, Add members automatically without sending an email).
Is there any way to add new users to AGOL organization via REST?

resolved.

Thank you, Andrew. I am still confused though because I am not sure what is the right way to add a user to AGOL organization (not Portal). I don't want to send emails to users with invitations; I want to add users directly into the AGOL organization. Could you really quickly just name the sequence of class/methods I should work with?

Sure thing, you still have to send an email, but you can create the account for a user's email.  The email that is sent by AGOL it basically tells the person you have an account, here is how to get into that account.  There is no method to not send an email that I am aware of.
Here is an example:
proxy_port = None
proxy_url = None
securityHandler = AGOLTokenSecurityHandler(username, password,
                                           proxy_url=proxy_url,
                                           proxy_port=proxy_port)
#   Connect to the site
#
sh = arcrest.AGOLTokenSecurityHandler(username, password)
admin = arcrest.manageorg.Administration(securityHandler=sh,
                                         initialize=False)
portals = admin.portals
portal = portals.portalSelf
il = arcrest.manageorg.InvitationList()
il.addUser(username="dancingbears", password="dame1sdft", firstname="bear", lastname="griswald"<EMAIL_ADDRESS>role="account_user")
print il.value()
html = """
John Doe has invited you to join an ArcGIS Online Organization, Solutions Dev.

Please click this link to finish setting up your account and establish your password: https://www.arcgis.com/home/newuser.html?invitation=@@invitation.id@@

Note that your account has already been created for you with the username, @@touser.username@@.

If you have difficulty signing in, please contact John Doe (john.doe@someplace.com). Be sure to include a description of the problem, the error message, and a screenshot.

For your reference, you can access the home page of the organization here:
http://www.arcgis.com/home/

This link will expire in two weeks.

This is an automated email, please do not reply.
"""
print portal.addUser(invitationList=il, subject="Added to arcgis.com site, DO NOT REPLY", html=html)

Ah, I couldn't believe that I should invoke addUser from the Portal because I am working with AGOL organization. I think that it might be a bit confusing for users... Shall we create a copy of this method inside the community part of AGOL? It's up to you of course to decide.
PS. The sample you posted works great, the user was added in the AGOL organization; the email was not sent though (not critical, but good for you to know).

The ArcREST layout of the functions and classes follow the REST API/URL structure that is why it is in the Portal class.
I hope that helps you understand the function/class structure.

Ah, I see now. Should have checked Portal part of the REST API Help, thought it is applicable only to Portal for ArcGIS installations.


TypeScript docs has invalid ESM usage

The doc example here:
import * as moment from 'moment';

let now = moment().format('LLLL');

Is performing a namespace object import but expecting the moment default export function. This is causing bundlers like parcel grief as they try to support this invalid ESM syntax.
Related to:
https://github.com/parcel-bundler/parcel/pull/530
Update:
With TypeScript 2.7 you can now flag to throw on this incorrect use and also support
import d from "cjs" with --esModuleInterop.

Moment is still TS 1.x-compatible. We're open to suggestions, provided you don't break existing functionality.
I dont know much about Parcel, but maybe others around here do.


UK Date Format

Saw that UK Date format is not yet supported.
Is there a way to change the date format from US to UK date format (dd-mm-yyyy).

Saw that there is a en-GB which is a UK format. my bad


Taking too much time to scan + setAutoFocus true/false using IntentIntegrator

Description of the problem:
I am getting two problems as follow:

I am scanning QR codes using the following code but it's taking too much time to scan. Is there anything to change?
I am thinking to change Auto Focus true/false to check maybe it's happening because of autofocus.

Which library version are you using? E.g. 3.2.0.
implementation('com.journeyapps:zxing-android-embedded:4.2.0') { transitive = false }
implementation 'com.google.zxing:core:3.4.1'

Which phone/tablet are you using, and which Android version does it run? (e.g. Samsung Galaxy S5,
Android 5.0)
Samsung Galaxy J8
Does the same happen on other devices or an emulator?
Not checked
Can you reproduce the issue in the sample project included with the library? If not, can you provide your own sample project or sample code that produces this error?
IntentIntegrator intentIntegrator = new IntentIntegrator(MainActivity.this);
intentIntegrator.setDesiredBarcodeFormats(IntentIntegrator.QR_CODE);
intentIntegrator.setOrientationLocked(true);
intentIntegrator.setPrompt("Scan a QR code");
intentIntegrator.setBeepEnabled(true);
intentIntegrator.setCameraId(0);
intentIntegrator.setBarcodeImageEnabled(true);
intentIntegrator.initiateScan();

In the case of an error do you have a stack trace or ADB logs?

Same here scan is delayed because of auto focus


Testcontainer does not detect custom docker sock location

I have docker environment configured using Lima.
limactl start docker.yaml
Followed by docker run hello-world
works good and sample docker container is working good.
To make Testcontainer to point to new docker location, I added the following config to testcontainer.properties
docker.client.strategy=org.testcontainers.dockerclient.EnvironmentAndSystemPropertyClientProviderStrategy
docker.host=unix:///Users/user/.lima/docker/sock/docker.sock

I also added the above config to /Users/user/.testcontainer.properties as well.
Once I start the container, I get the below logs
09:46:56.354 [main] DEBUG org.testcontainers.utility.TestcontainersConfiguration - Testcontainers configuration overrides will be loaded from file:[/Users/venkavis/Desktop/new_github/nimble-notification-service/target/test-classes/testcontainers.properties]()
09:46:56.357 [main] INFO org.testcontainers.dockerclient.DockerClientProviderStrategy - Loaded org.testcontainers.dockerclient.EnvironmentAndSystemPropertyClientProviderStrategy from [~/.testcontainers.properties](), will try it first
09:46:56.656 [ducttape-0] DEBUG org.testcontainers.dockerclient.DockerClientProviderStrategy - Pinging docker daemon...
09:46:56.678 [ducttape-0] DEBUG org.testcontainers.shaded.com.github.dockerjava.core.command.AbstrDockerCmd - Cmd:

The log says it successfully loaded configuration from testcontainer.properties file but actually its running  org.testcontainers.dockerclient.DockerClientProviderStrategy instead of org.testcontainers.dockerclient.EnvironmentAndSystemPropertyClientProviderStrategy.
Can someone help me what config I am missing here? Or the logs are shown wrongly?

From the logs:

Loaded org.testcontainers.dockerclient.EnvironmentAndSystemPropertyClientProviderStrategy from ~/.testcontainers.properties, will try it first

DockerClientProviderStrategy is the log category. Also, what you experience with limactl start is Docker Context - this is Docker CLI's feature that Testcontainers knowns nothing about because it does not use Docker CLI.
See more info here:
https://github.com/testcontainers/testcontainers-java/pull/5039#issuecomment-1039041020


Set the default region size to 1GB to improve stability when dealing with massive regions

Development Task
Set the default region size to 1GB to improve the performance and stability of TiKV when dealing with massive regions

[ ] Test if there is performance regression in following scenarios

[ ] benchmark (including tpcc, sysbench)
[ ] scale-in/out

[ ] change the default region size

/assign @cosven

benchmark result screenshots

summary: The cluster with 1G sized region has slightly better performance.
tpcc

sysbench

scale-in

summary: The cluster with 1G sized region scales 1.3x faster, at the same time, the performance jitter is also greater.
1G

96m

scale-out

summary: The cluster with 1G sized region scales 1x faster, at the same time, the performance jitter is also greater.
Note  the qps has a spike during scaling out due to flow control, and it can be auto recovered
1g

96m


fuzz test: Add header validation to api.

Commit Message: fuzz test: Add header validation to api.
Additional Description:
Make sure a config option is a valid header name.
Signed-off-by: Andre Vehreschild<EMAIL_ADDRESS>Risk Level: low
Testing: n/a
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a
API Considerations: just added validation expression

/retest

/retest

Do I get this right: The coverage step is taking too long? What can I do about it?


More descriptive assert messages when collectionView is nil

A lot of our IGAssert message strings are copy/pasted. Would be great to have more descriptive asserts about what is happening instead of just "Reloading collection view" etc, etc.
Example

If this one is still free/ not assigned, could I take a look at it?

@romankl all yours!


Barely visible texts in terminal running solorized-dark color scheme

Describe the bug
Some texts are barely visible in terminal which is using solarized-dark color scheme.
See attachment.
Screenshots

Desktop (please complete the following information):

macos 10.14.5
iTerm 3.2.6

lazydocker version
Version: commit=cf31c23fadcc717467318689fc073ecf1bed8031, build date=2019-07-02T00:10:43Z, build source=binaryRelease, version=0.3, os=darwin, arch=amd64

Additional context
similar issues with more screenshots if that helps
https://github.com/derailed/k9s/issues/132
https://github.com/derailed/k9s/issues/197#issuecomment-496809205

Totally agree,

Yeah I've also seen this on a colleagues computer. It's such a shame because it looks fine on my terminal, but I'm not sure what replacement color I could use. Luckily we already have color-customisable panel borders but as for things like these 'none's:
![image](https://user-images.githubusercontent.com/8456633/60505381-f5294d00-9d06-11e9-9651-3a80e12f2c01.png)

What might be a better option than black? I want them to look kind of out-of-the-way

blue doesn't look too bad:

Blue is usually the darkest of the colors so I think it suits. Just means now we'll need a different color for the container state of 'exited (0)' (I made it blue to distinguish a good exit from a bad exit). Maybe Yellow?

here's exited(0) in yellow:

I think it looks appropriate

PR is up https://github.com/jesseduffield/lazydocker/pull/65


Accounts page should be visible only to billers

Originally created by Tom Smyth at 2015-11-16 14:41, migrated from redmine-#3639

Status changed from New to Closed

By Tom Smyth at 2015-11-24 09:08


Change to EnergySaverStatus

PowerSaverMode is the phone-specific version of the API. Update to the common UWP API.

@cc-cortes,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


feat: All-day panel toggle view (resolves: #Dooray-캘린더/760)

Please check if the PR fulfills these requirements

[ ] It's submitted to right branch according to our branching model
[ ] It's right issue type on title
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] It does not introduce a breaking change or has description for the breaking change

Description

Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

test this please

Please translate the subject in english.

It is merged to master branch via commit 450f3591f1dd152f0c3fa45a328ccfc6d03f9a5b


nixos: Mount binds after the persistent storage path

This sets the depends (introduced in https://github.com/NixOS/nixpkgs/pull/86967) of each bind mount so that it will only be mounted after the persistent storage path has been mounted, as suggested in https://github.com/nix-community/impermanence/issues/22#issuecomment-847879359.
An obvious issue with this is that this will break older NixOS where the option does not exist yet. Any suggestions on how to work around that?

If GitHub's tags are to be believed, that PR is present in both 21.05 and 21.11, and support for any version of NixOS older than those have expired. IME, this is fine; however, I'd want to document this new version bound. Something like "as of PR #66 (with a link), NixOS 21.05 or later is required for proper functionality", or however you'd care to word it with a similar effect.
Though, this is also just my opinion. cc @talyz @lovesegfault @etu

Ah I did not know that the patch was backported to all supported versions of NixOS. I agree that the change in version requirements should be documented as @cole-h suggests. I'll try to find some time in the weekend to make the changes.

Fixed in #115

Oh hey I totally forgot about this one. Thanks for picking it up again @Kranzes!


New submission: SignalDelay

Please add my new mod Signal Delay to CKAN.

Nevermind the multiple commits; they are old and affect my other mods. The only real one if 2159cce.

No problem, we squash the commits into 1 commit.
Merging with my thanks


Get rid of confusing "Voter" name

I'd much rather have something more descriptive of what it does, or even something closer to the "blocks" concept already in the code. This needs to be worked out.

fixed in https://github.com/svenluijten/artisan-view/commit/ca5d4975571df552a1ef4ee4c6d10eed1e9ec3ef


Type error in create-svelte typescript default template

Describe the bug
Created default todos app using typescript and got this error without making any code changes, I'll submit a PR.

Reproduction
Run, npm init svelte@next svelte-todo
Choose Sveltekit Demo App, typescript, eslint, prettier and playwright.
Open svelte-todo code in vscode and goto src/routes/todos/index.ts and observe the error on line 2.
Logs
No response
System Info
System:
    OS: macOS 12.3.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 1.02 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    npm: 8.5.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 100.0.4896.127
    Safari: 15.4

Severity
annoyance
Additional Information
No response

Pending fix for this in #4705 already, although we're not sure if we will merge as is or rethink where the types are imported from first.

@dummdidumm alright, sounds like there is no need for this issue. I'll close it then. Thanks.


When I use multiple X-axes, I find that it doesn't bind

Before submitting bug reports

Check if your bug is already addressed in the FAQ: https://scottplot.net/faq
Search the issues to see if the bug has already been addressed: https://github.com/ScottPlot/ScottPlot/issues

This header can be deleted before posting

Bug Report
When I use multiple X-axes, I find that I can't bind lines to my newly added x-axis.However, it is possible to bind using multiple y-axis.
System Details

ScottPlot Version: 4.1.123
Operating System: (Windows 10.)
Application Type: (WinForms)
.NET Version: (NET Framework 4.6.1)

Hello, it would help if you could include some sample code and a screenshot of the result?

Thank you for your reply.I've put my code and screenshots of the run below and look forward to your response.
`var x3 = fPlot_Position.Plot.AddAxis(Edge.Top, axisIndex: 2);
x3.Label("RPM");
x3.Ticks(true);
x3.Grid(true);
x3.SetSizeLimit(0, 300);
        fPlot_Position.Plot.XAxis.Ticks(false);
        fPlot_Position.Plot.XAxis.Grid(false);
        fPlot_Position.Plot.XAxis2.Ticks(true);
        fPlot_Position.Plot.XAxis2.Grid(true);

        fPlot_Position.Plot.YAxis.SetSizeLimit(-2,2);
        fPlot_Position.Refresh();`

fPlot_Position.Plot.Clear();             fPlot_Position.Plot.AddScatter(ROParray, iarray, lineWidth: 2f, markerShape: ScottPlot.MarkerShape.none).XAxisIndex = 1;             fPlot_Position.Plot.AddScatter(RPMarray, iarray, lineWidth: 2f, markerShape: ScottPlot.MarkerShape.none).XAxisIndex =2;             fPlot_Position.Refresh();

This occurred because of a bug in how we handle multiple axes, I opened a PR to fix it: #1861


Create isFeatureVisible for named features

Created a new isFeatureVisible function that requires features to be named. This helps identify multiple code segments belonging to any given feature.
https://issues.redhat.com/browse/COST-2359

Codecov Report

Merging #2343 (2abad73) into master (1582464) will increase coverage by 0.02%.
The diff coverage is 80.95%.

:exclamation: Current head 2abad73 differs from pull request most recent head 0d041a4. Consider uploading reports for the commit 0d041a4 to get more accurate results

@@            Coverage Diff             @@
##           master    #2343      +/-   ##
==========================================
+ Coverage   68.82%   68.84%   +0.02%
==========================================
  Files         412      412
  Lines        7865     7880      +15
  Branches     1863     1746     -117
==========================================
+ Hits         5413     5425      +12
- Misses       2448     2451       +3
  Partials        4        4

Impacted Files
Coverage Δ

...odels/createCostModelWizard/generalInformation.tsx
55.55% <50.00%> (ø)

src/utils/feature.ts
83.33% <81.25%> (-16.67%)
:arrow_down:

src/store/export/exportActions.tsx
90.47% <100.00%> (ø)

Continue to review full report at Codecov.

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


Final logo regular in svg

I closed the PR https://github.com/OpenBioML/chemnlp/pull/164 in favor of this one.

@phalem The logos look great!
Just two minor things I would like to change:

Please remove the cap from the bottles. Then it looks a little bit cleaner. I already tried that and it looks a little bit better, see our slides where I already added it without cap: https://docs.google.com/presentation/d/1JkAKJveYsNGtAWoaksU8ykTdrC0aX3FshiFJ13SU6o8/edit#slide=id.g229d2eeb44b_2_0
Can you make the "ChemNLP" text only one line for the ChemNLP logo?

Thank you again for the great logo! I really like the book + liquid for the dataset and then the condensed block for the model. rocket

I will proceed in, sorry for being busy and far from the internet. I will PR it, I am sorry if this will take a while. I hope everyone like it.


Highlight the alerting value as WebUI does

See also: https://feedback.ruuvi.com/posts/99/sensor-settings-page-for-alerting-sensor-should-highlight-offending-alert

I think we already implemented this one. With new collapsable design it's hard to scroll to alarms but we got a blinkiung bell for "offending" alert. @laurijamsa what do you think?

Yeah, no need for actions right now. We're aiming to add a highlight color on the the upcoming dashboard new layout too. Closing this one.


Do not close search form on enter

Fix #275

Works like a charm, thank you for the patch. Can you rebase please?

Thank you!


ISSUE-2040-favor-401-over-429

Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

A short explanation of the proposed change:

This is a proposal for issue #2040
This PR changes the behaviour of the "SecurityContextSetter" middleware. This will now check which return code it got back from the next middleware in the call chain. If it gets back a 429 from the "RateLimiter" middleware, it will check if the token is expired, but in general valid. If so, the response is changed from 429 to 401.
The information, whether the token is expired, but in general valid, is retrieved from the SecurityContext.
The SecurityContext was extended by a function which returns true, if the context contains ":expired_token".
The "UaaTokenDecoder" was also changed. It now calls a newly implemented function in the cf_uaa_lib "decode_at_reference_time_exp_warn_only". This function will return the decoded token within the "TokenExpired" exception, if the token is expired, but passed all other checks.
This enables us to execute the remaining checks like the uaa issuer validation.
If all checks in the UaaTokenDecoder passed as well, we throw the catched "TokenExpired" exception again, which will be catched in the "SecurityContextConfigurer", which will store ":expired_token" in the context.
The token is still considered invalid, but the different value in the context enables the "SecurityContextSetter" to distinguish between a bad token (all other cases except expired tokens) and an expired token.

An explanation of the use cases your change solves

As above mentioned issue describes, the change basically favors 401 over 429 for expired tokens.

Links to any other associated PRs

This PR depends on the following PR: https://github.com/cloudfoundry/cf-uaa-lib/pull/70

[x] I have reviewed the contributing guide

[x] I have viewed, signed, and submitted the Contributor License Agreement

[x] I have made this pull request to the main branch

[ ] I have run all the unit tests using bundle exec rake

[ ] I have run CF Acceptance Tests

I think this approach is reasonable and I would be OK with you all moving forward with this solution.
When writing tests, can you include one that ensures that when calling an Unauthenticated request with an Expired but Otherwise Valid token, that rate limiting is still being applied?

I think this approach is reasonable and I would be OK with you all moving forward with this solution.
When writing tests, can you include one that ensures that when calling an Unauthenticated request with an Expired but Otherwise Valid token, that rate limiting is still being applied?

Hi @sethboyles,
great! Regarding your specific test case. We saw in the meantime that the current solution unfortunately also changes the response from 429 to 401 for requests to unauthenticated endpoints, which don't skip the rate limit check in case the token is expired but otherwise valid.
This is not a 100% clean solution, but the cases where an unauthenticated endpoint returns a 401 are very rare. This is because most of the endpoints which don't require authentication, skip the rate limiting. Examples for that are the info endpoints. Endpoints which do not require authentication and would return a 401 in case the token is expired, but valid otherwise are marketplace calls. In this case we think it can be even positive to send a 401 because the CF cli will refresh the token and the returned service offering will be the same and not shortened because the user isn't authenticated anymore. The benefit of the current solution is that the rate limiting itself works just as before and only the response, which will be send to the client is changed.
The following table summarises the changes for the different endpoints and requests:

Endpoint   Type
Token   sent?
Token   valid?
Reason
Skip   rate limiting?
Rate   limit exceeded?
Before
Current   solution

Unauthenticated
No
-
-
No
No
200
200

Unauthenticated
No
-
-
No
Yes
429
429

Unauthenticated
No
-
-
Yes

200
200

Unauthenticated
Yes
No
Bad   token
No
No
200
200

Unauthenticated
Yes
No
Token   expired
No
No
200
200

Unauthenticated
Yes
No
Bad   token
No
Yes
429
429

Unauthenticated
Yes
No
Bad   token
Yes
-
200
200

Unauthenticated
Yes
No
Token expired
No
Yes
429
401 (unwanted)

Unauthenticated
Yes
No
Token   expired
Yes

200
200

Unauthenticated
Yes
Yes
-
No
No
200
200

Unauthenticated
Yes
Yes
-
No
Yes
429
429

Unauthenticated
Yes
Yes
-
Yes

200
200

Authenticated
No
-
-
No
No
401
401

Authenticated
No
-
-
No
Yes
429
429

Authenticated
Yes
No
Bad   token
No
No
401
401

Authenticated
Yes
No
Token   expired
No
No
401
401

Authenticated
Yes
No
Bad   token
No
Yes
429
429

Authenticated
Yes
No
Token expired
No
Yes
429
401 (wanted)

Authenticated
Yes
Yes
-
No
No
200
200

Authenticated
Yes
Yes
-
No
Yes
429
429

We don't see any chance to distinguish between endpoints which require authentication and which don't in the middlewares, as this decision is made in the super class of the endpoints (ApplicationController) and the basis for this decision is the corresponding action e.g. "index", which is derived by the router after all middlewares were executed. We could hardcode all endpoints which don't require authentication into an array, but that's kinda hacky.
We'll go forward for now with implementing some tests. Let us know if you have other ideas or any concerns.

Hi @sethboyles,
great! Regarding your specific test case. We saw in the meantime that the current solution unfortunately also changes the response from 429 to 401 for requests to unauthenticated endpoints, which don't skip the rate limit check in case the token is expired but otherwise valid.
This is not a 100% clean solution, but the cases where an unauthenticated endpoint returns a 401 are very rare. This is because most of the endpoints which don't require authentication, skip the rate limiting. Examples for that are the info endpoints. Endpoints which do not require authentication and would return a 401 in case the token is expired, but valid otherwise are marketplace calls. In this case we think it can be even positive to send a 401 because the CF cli will refresh the token and the returned service offering will be the same and not shortened because the user isn't authenticated anymore. The benefit of the current solution is that the rate limiting itself works just as before and only the response, which will be send to the client is changed.
The following table summarises the changes for the different endpoints and requests:

Endpoint   Type
Token   sent?
Token   valid?
Reason
Skip   rate limiting?
Rate   limit exceeded?
Before
Current   solution

Unauthenticated
No
-
-
No
No
200
200

Unauthenticated
No
-
-
No
Yes
429
429

Unauthenticated
No
-
-
Yes

200
200

Unauthenticated
Yes
No
Bad   token
No
No
200
200

Unauthenticated
Yes
No
Token   expired
No
No
200
200

Unauthenticated
Yes
No
Bad   token
No
Yes
429
429

Unauthenticated
Yes
No
Bad   token
Yes
-
200
200

Unauthenticated
Yes
No
Token expired
No
Yes
429
401 (unwanted)

Unauthenticated
Yes
No
Token   expired
Yes

200
200

Unauthenticated
Yes
Yes
-
No
No
200
200

Unauthenticated
Yes
Yes
-
No
Yes
429
429

Unauthenticated
Yes
Yes
-
Yes

200
200

Authenticated
No
-
-
No
No
401
401

Authenticated
No
-
-
No
Yes
429
429

Authenticated
Yes
No
Bad   token
No
No
401
401

Authenticated
Yes
No
Token   expired
No
No
401
401

Authenticated
Yes
No
Bad   token
No
Yes
429
429

Authenticated
Yes
No
Token expired
No
Yes
429
401 (wanted)

Authenticated
Yes
Yes
-
No
No
200
200

Authenticated
Yes
Yes
-
No
Yes
429
429

We don't see any chance to distinguish between endpoints which require authentication and which don't in the middlewares, as this decision is made in the super class of the endpoints (ApplicationController) and the basis for this decision is the corresponding action e.g. "index", which is derived by the router after all middlewares were executed. We could hardcode all endpoints which don't require authentication into an array, but that's kinda hacky.
We'll go forward for now with implementing some tests. Let us know if you have other ideas or any concerns.

@svkrieger thank you for that chart!  It really helps when trying to think about all the different cases here.
Considering we by default have a higher rate limit for authenticated requests (defined here), in the 'unwanted' case, that is probably a good change.  Letting a user know their token is expired would let them refresh their token and potentially get access to a higher rate limit.
In general, it does seem a little odd to accept invalid tokens (expired or bad or otherwise) for unauthenticated requests. I wonder if it is just simpler to return 401 for invalid tokens wholesale, or at least when rate limiting is exceeded.  So for example, for this case:

Endpoint   Type
Token   sent?
Token   valid?
Reason
Skip   rate limiting?
Rate   limit exceeded?
Before
Current   solution

Unauthenticated
Yes
No
Bad   token
No
Yes
429
429

I think there would be value in returning a 401 here as well because it could also give a user a higher rate limit.

@svkrieger thank you for that chart!  It really helps when trying to think about all the different cases here.
Considering we by default have a higher rate limit for authenticated requests (defined here), in the 'unwanted' case, that is probably a good change.  Letting a user know their token is expired would let them refresh their token and potentially get access to a higher rate limit.
In general, it does seem a little odd to accept invalid tokens (expired or bad or otherwise) for unauthenticated requests. I wonder if it is just simpler to return 401 for invalid tokens wholesale, or at least when rate limiting is exceeded.  So for example, for this case:

Endpoint   Type
Token   sent?
Token   valid?
Reason
Skip   rate limiting?
Rate   limit exceeded?
Before
Current   solution

Unauthenticated
Yes
No
Bad   token
No
Yes
429
429

I think there would be value in returning a 401 here as well because it could also give a user a higher rate limit.

@sethboyles we discussed internally whether it would make sense to return a 401 generally in case the request was sent with an invalid token to an endpoint which does not require authentication. We don't think that this is a good idea as in general a 401 should be only returned when the requested resource requires authentication.
We also think that returning a 429 in case the rate limiting is exceeded and the token is a bad token (can't be decoded, wrong UAA issuer, not an access token) is preferable. We think we should only return the beneficial 401 to users which at least sent a valid, but expired token. If the token is a bad token, it is likely that the client won't be able to refresh it anyways (because obviously the client does not know which is the correct UAA or tries to construct an access token by itself).
Please let us know if that makes sense to you as well. In the meanwhile we added tests for the new logic. The checks here won't pass successfully though, until the PR in the cf_uaa_lib was merged and made available in a new release and we change the corresponding version in the Gemfile here. We are also open for feedback on the change in the cf_uaa_lib.

@svkrieger I'm not sure it's worth it to check if a token is otherwise valid.  We might as well just return 401 for all expired tokens.  This would also simplify the solution and allow us to avoid the requirement of updating the uaa lib.

Okay then I'd suggest we remove the check, whether it is expired as well, as we can't make sure it would be otherwise valid. In this case we can return a 401 for all bad tokens, including expired ones, right?
Then we can just check in the security_context_setter, if we get a 429, whether the token is invalid, valid or nil. If the token is invalid (including expired) we return a 401. If the token is nil or valid we return the 429.
That would result in the following response changes:

Endpoint   Type
Token   sent?
Token   valid?
Reason
Skip   rate limiting?
Rate   limit exceeded?
Before
Current   solution

Unauthenticated
Yes
No
Bad   token
No
Yes
429
401   (new)

Authenticated
Yes
No
Bad   token
No
Yes
429
401   (new)

For the first case it could be a bit confusing though. First the client would receive 200s until the rate limit got exceeded and then it will get 401s. Maybe in this case we should also return the rate limit headers with the 401, to make visible, that the rate limit got exceeded? Again the endpoints which will fall into this case are very rare. We can only think of marketplace calls. Other endpoints which do not require authentication, are skipping the rate limit check.
Let us know if we should go for this solution. Then we will change the implementation accordingly.

I am in favor of this solution.  You could make the argument for returning a 401 even if the rate limit is not exceeded, the endpoint is unauthenticated, but the token is invalid.  I checked a few other APIs and saw this behavior.
We don't have to go that far, but I think this solution is fine.

@sethboyles the PR is ready for review. We implemented it as discussed above. The tests reflect the behaviour, we wanted to achieve. We also think that always returning a 401 is a bit out of scope here, as it would require code changes in the endpoints too. Let us know if you have any questions about the current implementation.

Hi, Bruce from UAA here.
I would like to talk about this line:

Endpoint Type
Token sent?
Token valid?
Reason
Skip rate limiting?
Rate limit exceeded?
Before
Current solution

Authenticated
Yes
Yes
-
No
Yes
429
429

IMHO there is a larger problem here. Why are we validating the token when we know that the user is being rate limited?
IMHO the first line of the controller should be something like
if is_rate_limited() then
  return 429

This seems to completely defeat the purpose of rate limiting, if we still do work and maybe let the UAA be DDOSed because we keep validating the tokens, when we know that we are going to return 429 anyways.
Please share your thoughts.

@bruce-ricard let me answer your questions:

First of all, this PR only changes the response of the CC from 429 to 401 in case the token is invalid. I'm pretty confident that this can't open any backdoors or enable DoS attacks.
The token is and always was decoded before the rate limiting middleware. As to what I saw in the CC coding, the CC fetches the public keys from the UAA once and then uses these to decode the tokens locally, by using the cf-uaa-lib and without calling the UAA for every token. The information, whether the token is valid or not, is needed to distinguish between unauthenticated and authenticated rate limits.
As long as a valid token comes with the request, the rate limiting applies to the specific user and not to the IP. Even if the IP's rate limit got exceeded, the authenticated request coming from the same IP, won't be rejected.

Hi @bruce-ricard
As @svkrieger noted above, we check validity of tokens (if present) for rate limiting as users or clients may have a higher rate limit than unauthenticated clients.
See related configs here: https://github.com/cloudfoundry/capi-release/blob/develop/jobs/cloud_controller_ng/spec#L1013
Does that make sense or do you think there are possible issues with this ?  (this logic is already present in CCNG and not introduced by this PR, by the way)

Merging.  Thanks for submitting this PR!


Control flow

This PR will replaces NgIf, NgFor and NgSwitch with the new Angular Control Flow Syntax.
Also the code is formatted with Prettier.

What would be the improvement?

Angulars control flow introduced a lot of performance improvements. Especially @for offers better results than NgFor.

Man, performance already improved by being v17.
I won't introduce unstable syntaxes, because it might improve a bit more.
Let's wait till it's stable at least.
Then I'll do the change.

Just for everybody's reference, as for now, from here:


[DO NOT MERGE] DBZ-6399 Test with TZ=Europe/Vienna

https://issues.redhat.com/browse/DBZ-6399
This PR will run the test suite with TZ=Europe/Vienna for both source/sink databases.

Closing, this is no longer needed.


can anyone show how to load a .dem file with cesium?

thanks:)

Hey @addriumruss ! For general questions like this, please use the forum. If you search there often times you'll find it's already answered before. Here's a thread about how to work with .dem files in CesiumJS:
https://groups.google.com/d/msg/cesium-dev/bjXTc6p1h_M/rs5uq4ZMBgAJ

Congratulations on closing the issue! I found these Cesium forum links in the comments above:
https://groups.google.com/d/msg/cesium-dev/bjXTc6p1h_M/rs5uq4ZMBgAJ
If this issue affects any of these threads, please post a comment like the following:

The issue at https://github.com/AnalyticalGraphicsInc/cesium/issues/7179 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.
:earth_africa: :earth_americas: :earth_asia:


Allow MousePress to be combined with modifiers

Description of the problem or steps to reproduce
When I set my keybindings.json to
{
 "Ctrl-MouseLeft": "MousePress&command:definition",
}

I get error message:
Error in bindings: action MousePress does not exist

I expected it to work with https://github.com/AndCake/micro-plugin-lsp.
Specifications

Commit hash: c2cebaa3
OS: Fedora Linux 37
Terminal: GNOME Terminal Version 3.46.8 for GNOME 43

It is implemented in #2605.

Fixed by #2605.


Script doesn't work on 11.3 (20E232)

HI,
Just installed Big Sur and trying to adjust the clock to my liking. By running the script at first I was able to see the new format flash for a while just to revert back to default a moment later. Any ideas what might be wrong?

Have just tested the script with Big Sur 11.2.3 (20D91) and 11.3 (20E232) using all valid date formats and I can't reproduce the issue you're experiencing.

Deleting the file seemed to help. Thank you!


Added docs to expiry time

unsure if I should add a type alias, probably the best way to show what to expect

Should be good for the moment :)


Add oberon proof size assertions

Are we forcing the full 256 bytes of proof to be sent? Some languages only send the first 64.

Which ones?

Are we forcing the full 256 bytes of proof to be sent? Some languages only send the first 64.

Which ones?

off the top of my head, I don't remember. Some of the language-specific blake3 bindings are different. Now that we have blake3 exposed via okapi, it won't be an issue. I'll track this verification work here: https://github.com/trinsic-id/sdk/issues/456

This is related to proof size of oberon. It wouldn't work with any other partial size. It used to be 96 bytes, now it's 256.

This is related to proof size of oberon. It wouldn't work with any other partial size. It used to be 96 bytes, now it's 256.

ah okay. I was referring to the blake3 hashed nonce in sdk. Still something to change, but less related than I thought.

@fundthmcalculus This can't be merged without your approval. Mind giving it thumbs up?


Python Metaclasses for Metaprogramming

Formatting and structure checks

[x] Have you used the correct folder and file structure? - see Contribution Guidelines

[x] Is your article properly formatted in Markdown? - see Github Markdown guide

[x] Have you used our preferred heading structure? - H3 (###) and up

[x] Does your article follow any of the suggested structure formats? - see example formats

[x] Is your article over 750 words? - Tool: Wordcounter.net

[x] Is the article you are submitting an in-depth and unique article? Does it go beyond what is in the official docs and what is covered in other blog sites. See these articles as examples.

[x] Does your article provide enough value and detail about your topic? - Articles should be clear, accurate, and fully explained.

[x] Can your article be understood by beginners? - Assume the audience is smart but has no prior exposure to the common terminology in your article.

[x] Have you included a hero image that is 600x400 pixels and have the copyright to use it? - Tools: Pixlr Image Editor for resizing and Unsplash for Creative Commons images

Grammar & plagiarism checks

[x] Have you spellchecked and grammar checked your article? - Tools: Write&Improve - ProWritingAid - Grammarly
[x] Please place your article through a 3rd party plagiarism checker. We suggest using Quetext, this tool is free and has a daily limit. We typically accept articles with 10% or less.
[x] Have you checked your article for readability? - Tool: Hemmingway
[ ] Have you added sources for quotes and images that aren't yours?

Technical checks

[x] Are your code snippets properly formatted for syntax highlighting - see Syntax guide
[x] Have you checked your code runs correctly and you've highlighted all necessary dependencies for installation?
[x] Are the software programs and packages you're highlighting in your article up to date, using current versions and not deprecated?

Topic suggestion this closes
`This closes #4692

Hello @Dick7603,
Upon running your article through our 3rd party plagiarism checker it seemed to raise a few flags and the % was higher than we typically accept.
Please see attached PDF - and revisit the article to ensure we are contributing wholly unique and original content.
Be sure to see our resources page to see more info on plagiarism and what is considered as such.
Python Metaclasses for Metaprogramming #5345 Copyleaks Report.pdf

Hello @Dick7603
Please work on all the changes so that I can proceed with the review. The commit did not take in all the suggested changes.

hello @WanjaMIKE, I have implemented the changes your requested please check

I am closing this PR because it seems it wasn't publish-ready. You can make the changes outside the queue and create a new duplicate PR.


jsmn_test C89 forbids mixed declarations and code

mscv fails to build jsmn_test.c.  C89 support declarations only at the beginning of blocks (and msvc is still only C89 plus whatever MS choose to add).
gcc -std=c89 -pedantic ... will also highlight this issue.

Bitbucket: https://bitbucket.org/zserge/jsmn/issue/45
Originally reported by: Gerald Willett
Originally created at: 2015-03-13T19:00:47.687

Patch

Original comment by: Gerald Willett


[lunasvg] Add new port

closes #15432

@JonLiu1993 We probably should accept accept as it is and update the port in other PR. This bugfix doesn't seem essential. And the last released version of the lib is still 2.3.1

@JonLiu1993 Or I can use latest commit and call version 2.3.1-1 in the vcpkg.json file. Is it an option?

@JonLiu1993 Or I can use latest commit and call version 2.3.1-1 in the vcpkg.json file. Is it an option?

If Upstream doesn't explicitly state that uwp is not supported, we can't arbitrarily add the supports field unless there is favorable evidence

@JonLiu1993 Sorry? I guess it was another my PR with supports field changed 😄

Oops. I see. It's a typo actually.

@JonLiu1993 🥺  🙏

Thanks!

Thank you for your work!