FailoverClient is not handling MOVED response properly

I have a sentinel instance running on localhost:5000 and a master/slave pair instances running on localhost:7000 & localhost:7002.
Test 1: FailoverClient connects only to localhost:5000
Executing a Redis command results in error "MOVED 12539 <IP_ADDRESS>:7002"
Test 2: FailoverClient connects only to localhost:7000 & localhost:7002
Executing a Redis command results in error "redis: all sentinels specified in configuration are unreachable"
Test 3: FailoverClient connects to all instances localhost:5000, localhost:7000 & localhost:7002
Executing a Redis command results in error "MOVED 12539 <IP_ADDRESS>:7002"
I am expecting the MOVED response to be handled silently by the client but it turns out not the case. Or am I missing something here?

Forgot to mention I am using v8.11.5.


wac_types::Package::from_bytes fails with "should have owner" after #74

With https://github.com/bytecodealliance/wac/tree/66c067254ecf9ad862a195e49d3465b656f4e517, I was able to transition my project from wac-parser to wac-graph and run my component composition successfully.
However, with #74 (tested on https://github.com/bytecodealliance/wac/tree/d3f6be29f2629d866be4b1e476b373d7feaf77b5), wac_types::Package::from_bytes fails with the following panic:
thread 'main' panicked at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:770:26:
should have owner
stack backtrace:
   0: rust_begin_unwind
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:647:5
   1: core::panicking::panic_fmt
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_display
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/panicking.rs:196:5
   3: core::panicking::panic_str
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/panicking.rs:171:5
   4: core::option::expect_failed
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/option.rs:1988:5
   5: core::option::Option<T>::expect
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/option.rs:894:21
   6: wac_types::package::TypeConverter::resource
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:768:34
   7: wac_types::package::TypeConverter::ty
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:502:73
   8: wac_types::package::TypeConverter::entity
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:562:35
   9: wac_types::package::TypeConverter::component_instance_type
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:537:26
  10: wac_types::package::TypeConverter::entity
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:568:17
  11: wac_types::package::TypeConverter::export
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:415:9
  12: wac_types::package::Package::from_bytes::{{closure}}
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:239:65
  13: core::iter::adapters::map::map_try_fold::{{closure}}
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/adapters/map.rs:96:28
  14: core::iter::traits::iterator::Iterator::try_fold
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/traits/iterator.rs:2462:21
  15: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/adapters/map.rs:122:9
  16: <core::iter::adapters::GenericShunt<I,R> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/adapters/mod.rs:201:9
  17: <core::iter::adapters::GenericShunt<I,R> as core::iter::traits::iterator::Iterator>::fold
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/mod.rs:378:13
  18: core::iter::traits::iterator::Iterator::for_each
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/traits/iterator.rs:858:9
  19: <indexmap::map::IndexMap<K,V,S> as core::iter::traits::collect::Extend<(K,V)>>::extend
             at /workspace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/indexmap-2.2.6/src/map.rs:1364:9
  20: <indexmap::map::IndexMap<K,V,S> as core::iter::traits::collect::FromIterator<(K,V)>>::from_iter
             at /workspace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/indexmap-2.2.6/src/map.rs:1312:9
  21: core::iter::traits::iterator::Iterator::collect
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/traits/iterator.rs:2054:9
  22: <core::result::Result<V,E> as core::iter::traits::collect::FromIterator<core::result::Result<A,E>>>::from_iter::{{closure}}
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/result.rs:1930:51
  23: core::iter::adapters::try_process
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/adapters/mod.rs:170:17
  24: <core::result::Result<V,E> as core::iter::traits::collect::FromIterator<core::result::Result<A,E>>>::from_iter
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/result.rs:1930:9
  25: core::iter::traits::iterator::Iterator::collect
             at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/iter/traits/iterator.rs:2054:9
  26: wac_types::package::Package::from_bytes
             at /workspace/.cargo/git/checkouts/wac-6a66731467f4795b/d3f6be2/crates/wac-types/src/package.rs:237:75
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I have attached one of my components which now fails to load:
virtual_wasi_cli.component.wasm

Did a bit of research on the issue here. I may have find the issue.
The panic is happening when we're processing the following exported instance:
  (component (;7;)
    (import "import-type-terminal-input" (type (;0;) (sub resource))) ;; The problem export uses the type imported here
    (import "import-type-terminal-input0" (type (;1;) (eq 0)))
    (type (;2;) (own 1))
    (type (;3;) (option 2))
    (type (;4;) (func (result 3)))
    (import "import-func-get-terminal-stdin" (func (;0;) (type 4)))
    (export (;5;) "terminal-input" (type 0)) ;; Issue happens here
    (type (;6;) (own 5))
    (type (;7;) (option 6))
    (type (;8;) (func (result 7)))
    (export (;1;) "get-terminal-stdin" (func 0) (func (type 8)))
  )
  (instance (;16;) (instantiate 7
      (with "import-func-get-terminal-stdin" (func 9))
      (with "import-type-terminal-input" (type 27))
      (with "import-type-terminal-input0" (type 27))
    )
  )
  (export (;17<EMAIL_ADDRESS>(instance 16))

The issue happens inside of the component type definition with the line (export (;5;) "terminal-input" (type 0)) which exports a resource which we've seen to have seen before two exports previous:
  (component (;5;)
    (import "import-type-terminal-input" (type (;0;) (sub resource))) ;; This type has the same `ResourceId`
    (export (;1;) "terminal-input" (type 0))
  )
  (instance (;12;) (instantiate 5
      (with "import-type-terminal-input" (type 6))
    )
  )
  (export (;13<EMAIL_ADDRESS>(instance 12))

The ResourceId of resource import in component 5 is the same ResourceId as the resource import in component 7.

I think the expectation is wrong, as in this case it's an alias that isn't owned by an interface, and that's okay.
A think a failing test case in the graph tests would look having the graph load a dummy component created from:
world w {
  resource x;
  type x = y;
  import f: func(x: x) -> y;
}

I suspect we can just relax the expectation in the type converter and allow the alias owner to be None when find_owner returns None.


Cleanup composer.json

The main composer.json should only contain the internal packages and dev dependencies.

@jaapio test are still failing, please resolve


Add Lifecycle options to Task Template to drive dynamically

Change

Update controller to not hard code working for the Shell task and set in the Task Template.

Add

Add an Enable Lifecycle option to the Task Template. This in turn will add Init Container and Sidecar Container for the lifecycle worker.

Remove

Added lifecycle boolean to task config


The TextEdit component failed to recognize consecutive '\r\n' characters correctly

The TextEdit component failed to recognize consecutive '\r\n' characters correctly
Describe the bug
I found that when I give a string with '\r\n\r\n' to make TextEdit display, there is something wrong with the display. For example it looks like there is one line missing.When I press Key::Down, I can't reach the last '\r\n', but whether I get a new line can be displayed.
To Reproduce
Steps to reproduce the behavior:

Go to the CodeEditor,modify the code value to end with '\r\n\r\n'
Click on the keyboard down button

Expected behavior

Screenshots

Desktop (please complete the following information):

OS: Windows11
Browser :chrome
Version 22

Additional context
Modified value:
code: "// A very simple example\n
fn main() {\n
\tprintln!("Hello world!");\n
}\r\n\r\n"
.into(),

I suggest stripping \r from your strings


Some simulation models not built

Hello,
I initially filed an issue against openlane for this (https://github.com/efabless/openlane/issues/91), and @agorararmard suggested an issue should be filed here as well.
I'm building open_pdk using the rc4 release of openlane. Here are the relevant commits for Skywater and OpenPDK:
SKYWATER_COMMIT: 5cd70ed19fee8ea37c4e8dbd5c5c3eaa9886dd23
OPEN_PDKS_COMMIT: 48db3e1a428ae16f5d4c86e0b7679656cf8afe3d
The build basically appears to work, and I can successfully run the 'test' step from openlane. However, quite a few of the simulation models used by efabless/caravel are not present.
I see the following error when I  build pdk_root:
Writing all magic database files^M
Writing 'sky130_fd_pr__cap_vpp_08p6x07p8_m1m2_lishield'^M
Writing 'sky130_fd_pr__cap_vpp_11p5x11p7_m1m2m3m4_shieldl1m5'^M
Writing 'sky130_fd_pr__cap_vpp_11p5x11p7_m1m2_noshield'^M
Writing 'sky130_fd_pr__rf_test_coil1'^M
Writing 'sky130_fd_pr__rf_test_coil2'^M
Writing 'sky130_fd_pr__rf_npn_05v5_W1p00L2p00'^M
Writing 'sky130_fd_pr__rf_test_coil3'^M
Writing 'sky130_fd_pr__cap_vpp_04p4x04p6_m1m2_lishield'^M
Writing 'sky130_fd_pr__pnp_05v5_W3p40L3p40'^M
Writing 'sky130_fd_pr__rf_npn_05v5_W1p00L1p00'^M
Writing '(UNNAMED)'^M
Must specify name for cell (UNNAMED).^M
Done.^M
Error message output from magic:^M
File sky130_fd_pr__rf_npn_05v5_W1p00L1p00.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_npn_05v5_W1p00L2p00.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__pnp_05v5_W3p40L3p40.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_test_coil1.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_test_coil2.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_test_coil3.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_11p5x11p7_m1m2m3m4_shieldl1m5.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_11p5x11p7_m1m2_noshield.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_08p6x07p8_m1m2_lishield.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_04p4x04p6_m1m2_lishield.mag couldn't be read^M
No such file or directory^M
Can't write file named '(UNNAMED)'^M
Migrating LEF files to layout.^M
Warning:  No LEF files found in /project/fun/openlane/pdk_root/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr/lef^M

I did a quick check on a few of the files reported missing, and they do exist. I've attached the full log for completeness. Any help is much appreciated!
Best Regards,
Matthew
log.docker.txt

@mballance: I'll copy the first part of my response here as well for Tim's convenience.

So, here you're using a version of skywater pdk that doesn't have the IOs, with a version of open_pdks that cannot compile them properly (even if they were there).

You should be using the HEAD of open_pdks and the HEAD of skywater-pdk.

Appreciate the help, @agorararmard. I'm closing this issue.
Best Regards,
Matthew


Reasoning behind unsafe packages

Why exactly is it that some packages are considered unsafe in a requirements file?
I first noticed the comment after using pip-compile and then found this set in piptools/utils.py:
UNSAFE_PACKAGES = {'setuptools', 'distribute', 'pip'}

I tried googling for an answer but no luck.
Environment Versions

OS Type
Python version: $ python -V — 2.7.13
pip version:  $ pip --version — 9.0.1
pip-tools version: $ pip-compile --version — 1.9.0

Steps to replicate
❯ pip-compile --dry-run <(echo "pip")
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile --output-file /dev/fd/11.txt /dev/fd/11
#

# The following packages are considered to be unsafe in a requirements file:
pip==9.0.1
Dry-run, so nothing updated.

This is clearly not an actual issue but just a question :)

The change was brought by this commit:
https://github.com/jazzband/pip-tools/commit/50f06cbc588cfc099105b6a0b62abff027f3ad21
And I'll admit I'd really like to have @nvie input on this.
The only reasons I could think of would be one or many of those:

Some packages, like pip, can be installed with a package manager on linux, and could cause some conflict, but I never tested (I'm mostly on Windows these days).
Those are setup/installation packages, and most app (not all though) don't need to pin them.
When doing pip freeze, some of the installed packages are not listed, unless --all is specified. Maybe the original intent was to follow that.

I'm interested in this too. I've got two guesses:

upgrading pip/etc at the same time as upgrading other packages might cause issues (though I haven't actually tested this)
this has something to do with pip usually being globally installed by a system package manager, and is a band-aid for the conflict described in https://github.com/jazzband/pip-tools/issues/328

Am I on the right track?

Coming back on this:
pip, setuptools and distribute and responsible for building/installing packages. Generally speaking, one shouldn't have to pin these as they should have little impact on an application. (I've actually met quite a few exceptions to this assumption in my daily work, but I'll go ahead and hope that I just happen to be an unlucky fellow doing some funky things.)
For, PACKAGES_TO_IGNORE, it seems to be to cover some edged cases with global packages. for pip, setuptools and wheel, I would say it's to avoid issues while pip-sync is running. For pip-tools, that's just to be keep the tool installed. For pip-review, I think its a simple exclusion for this tool that is used to track packages upgrade and might be interesting to use alongside pip-tools`.
I'll close this issue, as it seems there's not much else we can add other than guessing. If this cause any other issue in the future, we can spend the time to figure out the exact needs and impact.


jellyfin-ffmpeg fails to build: Unknown option "--enable-libaribcaption".

Describe the bug
Jellyfin-ffmpeg overrides ffmpeg_6-full in a way that passes one version value (6.1) to the outer scope and a different value to the derivation scope (6.0.1). As a result withAribcaption = true is set and the build fails with Unknown option "--enable-libaribcaption"..
A rough fix looks like:
diff --git a/pkgs/development/libraries/jellyfin-ffmpeg/default.nix b/pkgs/development/libraries/jellyfin-ffmpeg/default.nix
index 7109a5d6dfd1..0b398b41f73a 100644
--- a/pkgs/development/libraries/jellyfin-ffmpeg/default.nix
+++ b/pkgs/development/libraries/jellyfin-ffmpeg/default.nix
@@ -4,7 +4,9 @@
 , lib
 }:

-ffmpeg_6-full.overrideAttrs (old: rec {
+(ffmpeg_6-full.override{
+  withAribcaption = false; # ffmpeg_6-full sets this to true based on a meta version value of '6.1' not the '6.0.1' used below
+}).overrideAttrs (old: rec {
   pname = "jellyfin-ffmpeg";
   version = "6.0.1-1";

Looks like https://github.com/NixOS/nixpkgs/issues/271863 also may change things in this area.
Steps To Reproduce
Steps to reproduce the behavior:

nix build -f <localnixpkgscheckout> jellyfin-ffmpeg
build fails with Unknown option "--enable-libaribcaption".

Expected behavior
Jellyfin-ffmpeg builds
Additional context
https://github.com/NixOS/nixpkgs/pull/271905 bumped ffmpeg in several places. It uses the existing pattern for guarding against version inconsistencies: https://github.com/NixOS/nixpkgs/blob/8bb443b2b8d6bf55a6d65402435dc81f6369ebfd/pkgs/development/libraries/ffmpeg/generic.nix#L30 This doesn't work as the version value referenced is from the outer function scope passed in when creating ffmpeg_6-full = ffmpeg_6.override{ ... https://github.com/NixOS/nixpkgs/blob/8bb443b2b8d6bf55a6d65402435dc81f6369ebfd/pkgs/development/libraries/ffmpeg/6.nix#L1-L4 not the library version value set later in https://github.com/NixOS/nixpkgs/blob/8bb443b2b8d6bf55a6d65402435dc81f6369ebfd/pkgs/development/libraries/jellyfin-ffmpeg/default.nix#L7-L9.
Notify maintainers
@arthsmn @justinas @Atemu
Metadata
Building from current master

Add a :+1: reaction to issues you find important.

diff --git a/pkgs/development/libraries/ffmpeg/generic.nix b/pkgs/development/libraries/ffmpeg/generic.nix
index 8b810120b80b..8bce3b57a493 100644
--- a/pkgs/development/libraries/ffmpeg/generic.nix
+++ b/pkgs/development/libraries/ffmpeg/generic.nix
@@ -447,7 +447,7 @@ stdenv.mkDerivation (finalAttrs: {
      */
     (enableFeature withAlsa "alsa")
     # FIXME: see if jellyfin-ffmpeg is already on a version >= 6.1 to use enableFeature
-    (optionalString withAribcaption "--enable-libaribcaption")
+    (optionalString (versionAtLeast version "6.1" && withAribcaption) "--enable-libaribcaption")
     (enableFeature withBzlib "bzlib")
     (enableFeature withCelt "libcelt")
     (enableFeature withCuda "cuda")

Wouldn't something like this fix it?

@arthsmn that should do it. Should also be possible to send that to master as it should mean no rebuild for most other things.

@arthsmn that should do it. Should also be possible to send that to master as it should mean no rebuild for most other things.

Yeah I think it's better than having more stuff on the jellyfin-ffmpeg side.

Also, shouldn't that have broken ffmpeg <6 too?

Also, shouldn't that have broken ffmpeg <6 too?

I don't think so, if jellyfin-ffmpeg would override ffmpeg-5 or -4 it would pass the version of the ffmpeg package, which is lower than 6.1.

@Atemu sadly my fix doesn't seem to work. I'm not sure why but I think we'll need to override withAribcaption in jellyfin-ffmpeg.

diff --git a/pkgs/development/libraries/ffmpeg/generic.nix b/pkgs/development/libraries/ffmpeg/generic.nix
index 8b810120b80b..c8a167840500 100644
--- a/pkgs/development/libraries/ffmpeg/generic.nix
+++ b/pkgs/development/libraries/ffmpeg/generic.nix
@@ -27,7 +27,7 @@
   # Feature flags
 , withAlsa ? withHeadlessDeps && stdenv.isLinux # Alsa in/output supporT
 , withAom ? withFullDeps # AV1 reference encoder
-, withAribcaption ? withFullDeps && lib.versionAtLeast version "6.1" # ARIB STD-B24 Caption Decoder/Renderer
+, withAribcaption ? withFullDeps && lib.versionAtLeast version "6.1.0" # ARIB STD-B24 Caption Decoder/Renderer
 , withAss ? withHeadlessDeps && stdenv.hostPlatform == stdenv.buildPlatform # (Advanced) SubStation Alpha subtitle rendering
 , withBluray ? withFullDeps # BluRay reading
 , withBs2b ? withFullDeps # bs2b DSP library

@anund can you test this? I think the problem is because a 3-parts is being used with a 2-parts one.

The version in that part of the code comes from ffmpeg_6-full. It's also not the issue:
nix-repl> lib.versionAtLeast "6.0-7" "6.1"
false

So the only option is to add the override to jellyfin-ffmpeg.


fix appveyor install yarn error

Yarn is pre-installed with appveyor.
https://www.appveyor.com/updates/

https://github.com/SimulatedGREG/electron-vue/pull/575


Components on the control node APPEAR to be flapping (but aren't?)

Working with kube-aws built from master, I've stood up a few clusters now and see this behavior on all of them.  Below, you see three executions of kubectl get pods --namespace=kube-system over the space of less than a minute.  If you look at the pods running on the control node (ip-10-0-0-50.us-west-2.compute.internal), you will notice that they come up, appear to run for a short time and then appear to restart.  (I'm basing this on readiness and age, as the restart count never increases.)  So there's an appearance of flapping here.  I have looked at the logs of the individual components and there is nothing out of the ordinary and according to docker ps, the age of all the corresponding docker containers is 2 hours.
Part of me thought initially that this might be a Kubernetes bug, but I can't seem to replicate this on clusters provisioned through other methods.
[kent@mbp ~]$ kubectl get pods --namespace=kube-system
NAME                                                              READY     STATUS    RESTARTS   AGE
heapster-v10-190a8                                                1/1       Running   0          2h
kube-apiserver-ip-10-0-0-50.us-west-2.compute.internal            0/1       Pending   0          1s
kube-controller-manager-ip-10-0-0-50.us-west-2.compute.internal   0/1       Pending   0          2s
kube-dns-v9-qqbxb                                                 4/4       Running   0          2h
kube-podmaster-ip-10-0-0-50.us-west-2.compute.internal            0/2       Pending   0          2s
kube-proxy-ip-10-0-0-237.us-west-2.compute.internal               1/1       Running   0          2h
kube-proxy-ip-10-0-0-238.us-west-2.compute.internal               1/1       Running   0          2h
kube-proxy-ip-10-0-0-50.us-west-2.compute.internal                0/1       Pending   0          1s
kube-scheduler-ip-10-0-0-50.us-west-2.compute.internal            0/1       Pending   0          1s
monitoring-influxdb-v2-apoue                                      1/1       Running   0          2h
[kent@mbp ~]$ kubectl get pods --namespace=kube-system
NAME                                                              READY     STATUS    RESTARTS   AGE
heapster-v10-190a8                                                1/1       Running   0          2h
kube-apiserver-ip-10-0-0-50.us-west-2.compute.internal            1/1       Running   0          11s
kube-controller-manager-ip-10-0-0-50.us-west-2.compute.internal   1/1       Running   0          12s
kube-dns-v9-qqbxb                                                 4/4       Running   0          2h
kube-podmaster-ip-10-0-0-50.us-west-2.compute.internal            2/2       Running   0          12s
kube-proxy-ip-10-0-0-237.us-west-2.compute.internal               1/1       Running   0          2h
kube-proxy-ip-10-0-0-238.us-west-2.compute.internal               1/1       Running   0          2h
kube-proxy-ip-10-0-0-50.us-west-2.compute.internal                1/1       Running   0          11s
kube-scheduler-ip-10-0-0-50.us-west-2.compute.internal            1/1       Running   0          11s
monitoring-influxdb-v2-apoue                                      1/1       Running   0          2h
[kent@mbp ~]$ kubectl get pods --namespace=kube-system
NAME                                                              READY     STATUS    RESTARTS   AGE
heapster-v10-190a8                                                1/1       Running   0          2h
kube-controller-manager-ip-10-0-0-50.us-west-2.compute.internal   0/1       Pending   0          1s
kube-dns-v9-qqbxb                                                 4/4       Running   0          2h
kube-proxy-ip-10-0-0-237.us-west-2.compute.internal               1/1       Running   0          2h
kube-proxy-ip-10-0-0-238.us-west-2.compute.internal               1/1       Running   0          2h
kube-proxy-ip-10-0-0-50.us-west-2.compute.internal                0/1       Pending   0          1s
kube-scheduler-ip-10-0-0-50.us-west-2.compute.internal            0/1       Pending   0          1s
monitoring-influxdb-v2-apoue                                      1/1       Running   0          2h

@krancour Looks like all the control plane pods are flapping? Would you post the output of kubectl describe for the pods in question while this is happening? I'm looking for the events log to see what the reason for the status change is.
The output will be quite long, so feel free to throw in a pastebin/gist.

Maybe unrelated, but @krancour are you trying to run kubernetes v1.2.0? I ask because this sounds like a change in behavior with static pods (most of control plane) + unregistered nodes (master) on v1.2.0.

@colhom Sorry I didn't get around to getting the output of kubectl describe for the pods in question yet.  I will just as soon as I've got a chance.
@aaronlevy yes... I'm running k8s 1.2.0.  Can you link me to somewhere that describes the changed behavior?  I've looked, but keep coming up empty handed.

The fix is to replace --register-node=false with --register-schedulable=false on the master node.

@aaronlevy I'll try that.   I only grabbed it for the API server.  Let me know if you need more.  Note that I did date && kubectl describe... so that you can see the difference in time between when the container started and now-- ~ 14 mins. with no restarts showing.
https://gist.github.com/krancour/dec3950222c74bae30bddd84efccdc6b

@krancour no events are showing for the apiserver, so I can't really tell much.
Maybe wait until #355 lands, which includes a number of changes to the control plane pods in order to properly support v1.2 kubernetes.

Closing due to inactivity, but please re-open if this is still an ongoing issue


import errors

If I run
import mds
mds.providers`

currently raises a AttributeError.
However,
from mds import providers works fine. I suspect this is some __init__.py fu that I need to fix.

Hoping that #36 can at least rule out the possibility of some weird version mismatch or pip caching or something.

I think since __init__.py doesn't import mds.providers, then providers doesn't exist as a name under mds.
But mds.providers exists as a name itself -- confusing.
Solution might be to import the rest of the package in mds/__init__.py?
import mds.api
import mds.db
import mds.fake
import mds.json
import mds.providers
import mds.schema

@hunterowens this should all be fixed once #71 is merged via #40.
Check out this commit, which cleaned up all of the imports.


[M1] Contributing File

Update contributing file.

updated contributing file, PR done and merged. closing.


Replace hardcoded status codes with http constants

Description
Replace hard-coded http status codes with with http package constants.
case 401: -> case http.StatusUnauthorized
Continuation to this thread.

@craicoverflow I noticed a weird behavior with this one. After replacing the hard-coded values, lint throws an error Response body must be closed.

This is probably because the linter looks for a http.StatusCode constatn being used to detect an HTTP response, and because we were using untyped values before the linter was not picking it up.
In any case, we should be closing the body afterwards as the linter suggests - though it is not as important to do in a CLI which exits once the command finishes executing.


nixos/systemd-resolved: fix incorrect user

Motivation for this change
I don't know the reason for assiging the group systemd-resolved to the
systemd-resolved user in the first place, but in any case, what we are
doing now is wrong as it leads to a normal interactive user being
created called resolved instead of actually assiging the group to
systemd-resolved.
Considering this never worked, I'm thinking we can also just drop this
completely but maybe @willybutz has some details concerning the reason
for the original change?
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

I meant @WilliButz , sorry for the typo.


nuxt 3

Hi guys,
any chance this module works with nuxt3?
In dev mode everything seems to work, but if i build the project (ssr) it stops working (getting timeouts).

bump 👋 whats the status? Anyone Here?

Vite proxy is available in nuxt 3, much better, i guess https://vitejs.dev/config/#server-proxy

So I have Vite proxy setup in nuxt 3, and its pretty much the same issue with this module in dev it works fine but in build it does not it doesn't even seem that it attempts to hit any routes

Same issue: proxy is working fine with $ npm run dev but not with $ npm run start
Well, at least the dev command is showing something regarding the proxy in cli (see screenshots) while the start command isn't

I'm also experiencing this issue. in "dev" works fine but production wasn't .

For a workaround until this module is updated for Nuxt 3 I am able to have proxies by creating the following file in this folder
server/middleware
import httpProxy from 'http-proxy';

const testProxy = httpProxy.createProxyServer({
  target: 'https://example.com/',
  changeOrigin: true,
  headers: { 'item': process.env.Whatever },
  ssl: false,
  secure: false,
  ws: false,
});

export default function (req, res, next) {
  if (req.url.startsWith('/__test')) {
    const extraOptions = {};
    try {
      rssProxy.web(req, res, extraOptions);
    } catch (err) {
      // error handling
    }
  } else {
    next();
  }
}

For a workaround until this module is updated for Nuxt 3 I am able to have proxies by creating the following file in this folder server/middleware
import httpProxy from 'http-proxy';

const testProxy = httpProxy.createProxyServer({
  target: 'https://example.com/',
  changeOrigin: true,
  headers: { 'item': process.env.Whatever },
  ssl: false,
  secure: false,
  ws: false,
});

export default function (req, res, next) {
  if (req.url.startsWith('/__test')) {
    const extraOptions = {};
    try {
      rssProxy.web(req, res, extraOptions);
    } catch (err) {
      // error handling
    }
  } else {
    next();
  }
}

Does this still work? Nowadays the server routes use the defineEventHandler function. Anway, I could not get this to work, and I assumed that rssProxy.web() was a typo for testProxy.web()(?)

Does this still work? Nowadays the server routes use the defineEventHandler function. Anway, I could not get this to work, and I assumed that rssProxy.web() was a typo for testProxy.web()(?)

Try this (change the options hostname and port to your proxy)

import http from 'http';

export default function (client_req, client_res) {
    const options = {
        hostname: 'localhost',
        port: 4743,
        path: client_req.url,
        method: client_req.method,
        headers: client_req.headers
    };

    const proxy = http.request(options, function (res) {
        client_res.writeHead(res.statusCode, res.headers)
        res.pipe(client_res, {
            end: true
        });
    });

    client_req.pipe(proxy, {
        end: true
    });
}

I think there are no planned nuxt 3 support, because see on last commit — there are no activity. only if new contributors will appear

@femanso Thanks for the example.
I came up with this to proxy in a sitemap.xml using defineEventHandler (@ahku).
Used a switch as I will be adding some more proxy urls later, but it can of course be done without :)

export default defineEventHandler((e) => {
  const options = {
    hostname: 'localhost',
    port: 3002,
    path: e.req.url,
    method: e.req.method,
    headers: e.req.headers
};
  switch(e.req.url) {
    case '/sitemap.xml':
    const proxy = http.request(options, function (res) {
      e.res.writeHead(res.statusCode, res.headers)
              res.pipe(e.res, {
                  end: true
              });
          });
    e.req.pipe(proxy, {
        end: true
    });
    break
  }
});```

I tested nuxt-proxy today, and it works like a charm.

@z3cka How did you get this to work with nuxt 3's nuxt.config.ts defineConfig object? I see errors thrown with the rewrite option after defining a target.

@z3cka How did you get this to work with nuxt 3's nuxt.config.ts defineConfig object? I see errors thrown with the rewrite option after defining a target.

I didn't. I used the project found at https://github.com/wobsoriano/nuxt-proxy#usage
IIRC it did work at the time, but we've since gone with a more robust reverse proxy implemented with nginx as per our requirements. Also, the above linked project recommends looking into h3's proxyRequest -> https://www.jsdocs.io/package/h3#proxyRequest as h3 is what Nuxt3 uses under the hood.
Good luck!

The proxy can also be configured through nitro docs in the nuxt.config.ts:
export default defineNuxtConfig({
  nitro: {
    devProxy: {
      "/proxy/test": "http://localhost:3001",
    },
  },
});


SO-5443: Add support for new refset type; simple map to SNOMEDCT

Codecov Report

Merging #1029 (f2cd236) into 7.x (d91ecb1) will decrease coverage by 0.00%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##                7.x    #1029      +/-   ##
============================================
- Coverage     62.59%   62.59%   -0.01%
+ Complexity    11444    11443       -1
============================================
  Files          1608     1608
  Lines         54985    54993       +8
  Branches       5413     5414       +1
============================================
+ Hits          34419    34424       +5
  Misses        18384    18384
- Partials       2182     2185       +3

Impacted Files
Coverage Δ

...ational/snowowl/snomed/common/SnomedConstants.java
100.00% <ø> (ø)

...nal/snowowl/snomed/datastore/SnomedRefSetUtil.java
77.55% <50.00%> (-1.18%)
:arrow_down:

...wl/snomed/core/domain/refset/SnomedRefSetType.java
66.66% <80.00%> (+0.32%)
:arrow_up:

...national/snowowl/core/locks/OperationLockInfo.java
43.33% <0.00%> (-3.34%)
:arrow_down:

...x/src/com/b2international/index/util/JsonDiff.java
75.29% <0.00%> (-2.36%)
:arrow_down:

...national/snowowl/snomed/cis/SnomedIdentifiers.java
76.92% <0.00%> (-1.54%)
:arrow_down:

...ternal/eventbus/netty/AddressBookNettyHandler.java
78.37% <0.00%> (+5.40%)
:arrow_up:

Continue to review full report at Codecov.

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

@AAAlinaaa Make sure you port this to 8.x as well? Thanks!

The 8.x counterpart PR is https://github.com/b2ihealthcare/snow-owl/pull/1043 which introduces broader support for the new reference set type (including read/write capability). I'm leaving the port-to-8.x label up as the constant for the original "from SNOMED CT"-type concept was not renamed on 8.x – we might want to harmonize the constants across the two branches.


[Feature]: Workflow for closing old issues

Description
This feature aims to automate the process of managing old issues, ensuring that the repository remains organized and focused on relevant tasks. By automatically closing old issues, it reduces manual overhead for repository maintainers and helps keep the issue tracker tidy and up-to-date.
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)

@pooranjoyb please assign me this issue under gssoc'24

Well, this can't be worked upon right now ig. @Asymtode712
Try with pinned issues!
Happy coding :)


Feat: display threshold in the Safe header

What it solves
Part of #3504
This PR only adds the policy indicator w/o touching any other design aspects of the sidebar.

Why now
This PR also removes the DevTools component, and this was the main motivation. It occupies a lot of space in the sidebar.
Making the nav menu unusable, especially with browser devtools opened.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 8 (25.0%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.2%) to 35.424%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/components/AppLayout/Sidebar/index.tsx
0
1
0.0%

src/components/AppLayout/Sidebar/Threshold/index.tsx
0
5
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/components/AppLayout/Sidebar/index.tsx
1
0%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
3407

Relevant Lines:
8680

💛  - Coveralls


Open source client project

Please review my open source project
https://github.com/eddiejaoude/stargate

love the issues with emojis maybe I will rob this idea :)
maybe add a contributing.md to the project (but think this is on the way https://github.com/eddiejaoude/stargate/pull/28)
I think the installation instructions should be more at the top of the readme

Thanks for the feedback!

love the issues with emojis maybe I will rob this idea :)

I stole this from @nhcarrigan 😂

I think the installation instructions should be more at the top of the readme

Good idea 👍

@schmelto I migrated the issue labels from the Creative Commons standard.

Thanks @schmelto . I am going to close this


EXCEPTION: TypeError: dragula is not a function

Trying to import library from angular 2 RC1, and I am getting this error, any clue why?

Please refer to our Slack channel for support requests. You can join our Slack channel through this link.
Thanks! :tada:


operator project-quay (3.9.0-nightly.20230402)

Add 3.9.0-nightly.20230402 to community operators

/merge possible

/merge possible


Builder transition: build.zig to build.d

The use of zig + ldc2 is functional and exciting. However, for some users, it may not be interesting to be limited to such choices.
Unlike build.zig, the build.d will be a manual process using std features and will also be DIY (e.g. download, extract and run emsdk). Likewise, zig (toolchain) can optionally be downloaded and extracted, or the system toolchain can be used to build the sokol library (C code).
Dub will be a front-end interface and build.d will be a back-end for building project and samples.
This transition will give users a choice of compilers (D and C) and targets.

[!NOTE]
Low priority

Currently POC, get emsdk & zig (cross-platforms) - https://github.com/kassane/sokol-d/actions/runs/11262941946

Currently POC, get emsdk & zig (cross-platforms) - https://github.com/kassane/sokol-d/actions/runs/11262941946

Updated - get:

zig
emsdk
cimgui & imgui
sokol-tools-bin

https://github.com/kassane/sokol-d/actions/runs/11581063939
src: https://github.com/kassane/sokol-d/blob/builder/build.d


[SPARK-6082] [SQL] Provides better error message for malformed rows when caching tables

Constructs like Hive TRANSFORM may generate malformed rows (via badly authored external scripts for example). I'm a bit hesitant to have this feature, since it introduces per-tuple cost when caching tables. However, considering caching tables is usually a one-time cost, this is probably worth having.

Test build #28144 has started for   PR 4842 at commit b05dbff.

This patch merges cleanly.

Test build #28144 has finished for   PR 4842 at commit b05dbff.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28144/
Test PASSed.

Seems reasonable to me.  Integer comparison should not be very expensive.


Mod View cursors, modHistory

Describe your changes
Add modHistory database entries on all relevant moderation actions.
Add types & IQs for reports & modHistory.
Issue ticket number and link
closes all main reporting functionality under le epic #105

I think we should consider doing some simple grouping based on the day, for mod actions. Cuz like, there could be a lot of actions happening in a day, and this collection could get quite chunky. So like instead, make the documents called like
day_month_year and then it has a list called reports to which you can arrayUnion with a new string or object or whatever. What do you think?

Yeah that could be good especially if an employee wants to scroll back to a mod action that happened months ago, we could display a dropdown of each day action was taken. They'd be able to scroll down faster and we wouldn't have to do as many reads to get there

Status on this PR?

@JakeSteinebronn it's in progress, having some trouble with this part though:
The collection modHistory is gonna have docs in the format MM_DD_YYYY and those docs have a list of modActions taken on that day. I have all the logic around making a doc for the day and updating modActions, but I'm struggling with making an IQ.
I'm trying to set up the IQ so that it only fetches the dates actions took place (to save on reads), then from there employees can click on a date to get the rest of the data for that doc (the list of actions taken that day).
It seems like the right way to set it up is to make the modActions list a sub-collection of each doc. An IQ on modHistory won't read any sub-collections, then we could have an IQ or a .getAll() for the modActions.

the last commit does the following:

lots of linting, sorry it's hard to read
fix IQ keys
rename type ModHistory -> ModAction
refactor ModHistory entries using User.addModAction()

db looks like this

Big commit there, here's everything done:

updated modAction to account for cases where the users in the action log have been deleted. ModAction stores a ref to the user, if they get deleted we should still have some way of knowing who that user was. We used to store their email for this, but now we're storing their username. With this, web would check if the user no longer exists, then fill in the UI with their stored username if necessary.
removed unnecessary 2nd param on IQ queryKeys
added comments to type fields describing data presence
changed all instances of 'mod' to 'moderator'
changed User.addModAction() to use setDoc {merge: true}
fixed initWithDocumentData() for Report & ModAction


SPIKE: Make interface COM visible?

Not sure if i have to make the interface com visible or not. Find out.

No. The only thing that needs to be Com visble or have a GUID is the actual class that you are making


Dockerfile needs to updated

The Dockerfile needs to be updated to account for the changes to the build system
TODO:

Update the npm script that bootstraps the UI
Remove unnecessary dependencies from here

Currently testing the updated Dockerfile

Updated https://github.com/rishighan/threetwo-docker-compose


Group stratification

For fairness metrics, we might want to have an additional vector and stratify to compute fairness.
I believe we can start with simple group difference (when the given vector only contains two unique values) and all pair-wise group differences (when more than 2 groups).

I think this is a great idea, I was thinking more concretely this could be realized with 2 parquet files, one with model predictions/outputs and one with the patient subgroup assignments at different prediction times:

Model outputs: The meds-evaluation label schema parquet file which has the predictions.
Subgroup assignments: A meds label schema parquet file (specifically which is output by aces) which has the categorical_value field filled out indicating the subgroup a patient is in.

Nice part:
The nice thing about having a separate file for subgroup assignments is that you can generate many different subgroup assignments and run your evaluation script only changing the path to the subgroup assignment file. This allows evaluating many different subgroups.
Complex not so nice part:
The Model outputs have a subject_id and prediction_time, and you want the subgroup assignments parquet (which also has subject_id and prediction_time) to align with this, so you can just do a join operation on those two columns between the model outputs and subgroup assignments. This may be challenging to deal with if they don't align. Do you want to do a polars join_asof operation (instead of a join) so for each row in the model_outputs parquet, you take the most recent prior row in the subgroup assignments parquet, and if there is no prior row for the subject, you just enter a null subgroup assignment?
Thoughts @Jeanselme @kamilest @mmcdermott @abinithago

Instead of using join_asof, we could also modify the aces task yaml file that generated the task labels and define a subgroup predicate within the aces task yaml file such that you get both task labels in the boolean_value field and subgroup identities in the categorical_value field. From both these fields, we can use join operation to calculate the task metrics for subgroup of interest.

I would support having separate files because when we extend the benchmark to support multi-class classification tasks we would need to reimplement a lot of the logic to deal with the overloaded categorical_value field.

I don't think we should put subgroup identities in the categorical values field @abinithago -- for one, it sort of violates the assumptions of the schema, and for another, that data is actually independent of the task prediction step, and can be stored once per dataset rather than on every extracted task. I think the idea of taking the single model output (predictions on all samples for a given task) and splitting it into separate files per subgroup via some kind of join operation, potentially as @Oufattole proposed, is likely the right way to go here. @kamilest, is that what you were suggesting as well, or did I misunderstand your comment?

I believe we were more thinking about saving the different subgroup identities in separate file as you are suggesting. Then this will be an input to the evaluation function to compute the different metrics. I don’t think we should split the prediction files as the computation of some metrics might need access to the different subgroups.


Initializing multiple blocks

Fixed the bug in which block labels where not initialized when adding multiple blocks at once.

Looks good, glad you fixed the bug!

Looks fine, other member can merge.


Updated recipe/meta.yaml to version 5.0.9

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Use in headless server

Hi @zvovov, first of all thank you for sharing this and awesome work.
Can I check if this script is meant to be used from command line on a local machine? I wonder if actually I can use this in a remote headless server. Thanks.

Hi,
Thanks for using the project.
You can use this project to run WhatsApp through the terminal on a remote
machine provided that machine has a GUI and has Chrome installed on it.
On Thu, Sep 12, 2019, 03:26 harisum<EMAIL_ADDRESS>wrote:

Hi @zvovov https://github.com/zvovov, first of all thank you for
sharing this and awesome work.
Can I check if this script is meant to be used from command line on a
local machine? I wonder if actually I can use this in a remote headless
server. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zvovov/whatsapp-web/issues/32?email_source=notifications&email_token=ACB2XWXJRNF526DMB7KA2KLQJFSQ7A5CNFSM4IVZJK22YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HK2X3UQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACB2XWVX6VK5DI5LTQJYJ73QJFSQ7ANCNFSM4IVZJK2Q
.

I use it on a remote headless server using X virtual framebuffer (xvfb).
It works fine...

Great
On Tue, Sep 17, 2019, 01:29 Emilio Francesquini<EMAIL_ADDRESS>wrote:

I use it on a remote headless server using X virtual framebuffer (xvfb).
It works fine...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zvovov/whatsapp-web/issues/32?email_source=notifications&email_token=ACB2XWTDSDN7OUIESG7D7UTQJ7QSZA5CNFSM4IVZJK22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62KXOQ#issuecomment-531934138,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACB2XWRGTWHZW4FEEBMBXWDQJ7QSZANCNFSM4IVZJK2Q
.


[Issue]: Windows hip error 'no ROCm-capable device is detected'

Problem Description
After installing all HIP SDK with all its options successfully and setting up the system environment variables,
I get hipErrorNoDevice when running the hipinfo command or when trying to use hip:
:4:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\rocclr\platform\runtime.cpp:83  :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] init
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_context.cpp:48  :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] Direct Dispatch: 0
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:546 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0]  hipGetDeviceCount (<PHONE_NUMBER>EFFA3C )
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:548 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] hipGetDeviceCount: Returned hipErrorNoDevice :
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:546 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0]  hipGetDeviceCount (<PHONE_NUMBER>EFFA3C )
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:548 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] hipGetDeviceCount: Returned hipErrorNoDevice :
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:546 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0]  hipGetDeviceCount (<PHONE_NUMBER>EFFA3C )
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:548 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] hipGetDeviceCount: Returned hipErrorNoDevice :
error: 'no ROCm-capable device is detected'(100) at C:\constructicon\builds\gfx\two\23.30\drivers\compute\hip-tests\samples\1_Utils\hipInfo\hipInfo.cpp:205
error: API returned error code.
error: TEST FAILED

The GPU is recognized by the system and usually works.
Operating System
Windows 11 Pro 10.0.22621 (22H2)
CPU
Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz
GPU
AMD Radeon RX 7900 XT
ROCm Version
ROCm 5.7.1
ROCm Component
HIP
Steps to Reproduce
I uninstalled all existing HIP and AMD drivers and downgraded from windows 23H2 to 22H2 (attempting to fix this).
Downloaded HIP SDK 5.7.1 for Windows 10 & 11 and installed it.
Then I set up the system environment variables to be HIP_PATH=C:\Program Files\AMD\ROCm\5.7\, HIP_PATH_57=C:\Program Files\AMD\ROCm\5.7\, HIP_VISIBLE_DEVICES=1 and in the Path variable I added C:\Program Files\AMD\ROCm\5.7\bin and %HIP_PATH%bin.
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response

Hi @EmotionIce, are you still experiencing this issue with HIP SDK 5.7.1?

I

Problem Description
After installing all HIP SDK with all its options successfully and setting up the system environment variables, I get hipErrorNoDevice when running the hipinfo command or when trying to use hip:
:4:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\rocclr\platform\runtime.cpp:83  :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] init
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_context.cpp:48  :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] Direct Dispatch: 0
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:546 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0]  hipGetDeviceCount (<PHONE_NUMBER>EFFA3C )
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:548 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] hipGetDeviceCount: Returned hipErrorNoDevice :
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:546 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0]  hipGetDeviceCount (<PHONE_NUMBER>EFFA3C )
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:548 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] hipGetDeviceCount: Returned hipErrorNoDevice :
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:546 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0]  hipGetDeviceCount (<PHONE_NUMBER>EFFA3C )
:3:C:\constructicon\builds\gfx\two\23.30\drivers\compute\clr\hipamd\src\hip_device_runtime.cpp:548 :<PHONE_NUMBER> us: [pid:20784 tid:0x9b0] hipGetDeviceCount: Returned hipErrorNoDevice :
error: 'no ROCm-capable device is detected'(100) at C:\constructicon\builds\gfx\two\23.30\drivers\compute\hip-tests\samples\1_Utils\hipInfo\hipInfo.cpp:205
error: API returned error code.
error: TEST FAILED

The GPU is recognized by the system and usually works.
Operating System
Windows 11 Pro 10.0.22621 (22H2)
CPU
Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz
GPU
AMD Radeon RX 7900 XT
ROCm Version
ROCm 5.7.1
ROCm Component
HIP
Steps to Reproduce
I uninstalled all existing HIP and AMD drivers and downgraded from windows 23H2 to 22H2 (attempting to fix this). Downloaded HIP SDK 5.7.1 for Windows 10 & 11 and installed it. Then I set up the system environment variables to be HIP_PATH=C:\Program Files\AMD\ROCm\5.7\, HIP_PATH_57=C:\Program Files\AMD\ROCm\5.7\, HIP_VISIBLE_DEVICES=1 and in the Path variable I added C:\Program Files\AMD\ROCm\5.7\bin and %HIP_PATH%bin.
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response

Your issue will persist. This problem had bugged me for some time now. Trying to get WSL to work on my gfx1031 card, I made the same mistake as you.
If I hadn't seen that you also set "HIP_VISIBLE_DEVICES" > 1 as a variable then I wouldn't have known. By removing HIP_VISIBLE_DEVICES from the system variables hipInfo works again.

I'll add this here for future reference if someone stumbles across this issue. The "HIP_VISIBLE_DEVICES" environment variable specifies which devices are exposed to HIP applications, in this case hipInfo.
The variable should be set in the form of comma separated list, for example HIP_VISIBLE_DEVICES="0,2"
This variable is not set by default during the installation. Manually setting the value to "1" hid your GPU from hipInfo.exe causing the error no ROCm-capable device is detected. You can find more information on HIP_VISIBLE_DEVICES and other GPU isolation techniques here.


Background Events followed by another are ignored

The problem
Describe the bug
I had a background with a specific texture from which I wanted to transition in the beginning. However, running my scene, only the second background was shown.
To Reproduce

Expected behavior
Display the first background, then transition to the next.
System (please complete the following information):

Godot Version: 4.2
Dialogic Version: 2.0, Alpha 13 WIP

Still broken on Alpha 13.


[collector] Add support for KEDA autoscaling

I would like to propose KEDA support to the OpenTelemetry Collector helm chart so that the Collector is able to autoscale based on metrics other than CPU and Memory.
https://github.com/kedacore/keda
"KEDA allows for fine-grained autoscaling for event-driven Kubernetes workloads."
Similarly to HPA, KEDA would apply to Kind: Deployment only.
Use Case:
We have a Collector with a KafkaReceiver receiving logs from a Kafka topic. We would like to be able to scale automatically based on metrics such as Kafka lag, for example.

I am not familiar with this project, but in general, we don't like when installing the helm chart depends on other Operators being installed.  We currently have 2 exceptions: the operator chart's default install expects the cert-manager, and the collector chart allows installing some objects that depend on the Prometheus operator.
Is using the Collector chart with keda possible today if you managed the keda objects outside the collector chart?

I totally understand that. Only suggested it because Keda is becoming the de facto standard for Kubernetes-based Event Driven Autoscaling.
Yes, it is possible to use outside the collector chart. Will be more complicated to manage and maintain but it is possible.


Add ingest source to openai events

Since we are moving back to using custom events and instrumentation.provider is an ml event attribute, add an ingest_source attribute to the events in prep for that move.

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop-openai-instrumentation@8e5d18d). Click here to learn what that means.
The diff coverage is n/a.

@@                        Coverage Diff                        @@
##             develop-openai-instrumentation     #961   +/-   ##
=================================================================
  Coverage                                  ?   81.42%
=================================================================
  Files                                     ?      191
  Lines                                     ?    19808
  Branches                                  ?     3436
=================================================================
  Hits                                      ?    16129
  Misses                                    ?     2669
  Partials                                  ?     1010

:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!


Spikein_scale

Hi,
I have a question about spikein_scale. I have a cut_and_tag data that do not have spike-in genome. Also, for spike_in_align and spike_in_norm, I chose false. I see that the spikein_scale equation is spikein_scale/spikein_reads. How is the data normalized, if I don't have any spike_in reads?
Thanks,
Shikan

Do not worry about it as it will not run the spike-in norm if you set false to spike_in_norm. For the resulting bigwig files, we will perform CPM normalization if you do not have spike-in reads for normalization.


Improve the software's scalability

After making the modification, we can summarize a batch of variants stored in a file (e.g., the file "example_input_file_for_llm_summary.txt") by running "bash batch_summary.sh example_input_file_for_llm_summary.txt". This improves the scalability of the tool.


Realpath fix

Check if given file is a string (sometimes it's bolean) before adding it to array; also add intelliJ ignore folder

Coverage decreased (-1.2%) to 85.714% when pulling 15e5ab8b468b136ca690854b54a67b723fc77c39 on saschanos:realpath-fix into 22b64b19ba1656b50e13ad68d4977ae4c743a50c on phpgearbox:master.

Coverage decreased (-1.2%) to 85.714% when pulling 15e5ab8b468b136ca690854b54a67b723fc77c39 on saschanos:realpath-fix into 22b64b19ba1656b50e13ad68d4977ae4c743a50c on phpgearbox:master.


Seeder file updates for governors and some house reps

Also removed out-of-date city-level seeder data so we don't intentionally share incorrect information. See
https://github.com/CivilServiceUSA/us-house/pull/25 and
https://github.com/CivilServiceUSA/us-governors/pull/9 for more details on changes

Closing this out due to age.  We've completed a number of API changes since then that makes merging this near impossible.


azd up publishes Debug builds instead of Release builds (.NET Aspire)

Since .NET 8, the default build configuration with dotnet publish is a Release build.
I think this should also be the default for azd up as well. Instead, using azd up creates a Debug build.
Using the --debug option of azd (which I think is the equivalent of -d (--diagnostics) with the dotnet CLI, I can see this command where the -c option is explicitly set to Debug:
dotnet publish D:\codebreaker\ch12b\Pragmatic-Microservices-with-CSharp-and-Azure\ch12\Codebreaker.GameAPIs\Codebreaker.GameAPIs.csproj -r linux-x64 -c Debug -p:PublishProfile=DefaultContainer -p:ContainerImageName=azd-deploy-gameapis-1708853612 -p:ContainerRegistry=<redacted>

Also, without the --debug option, the debug builds are built and published.
Versions:
azd version 1.6.1 (commit eba2c978b5443fdb002c95add4011d9e63c2e76f)
aspire 8.0.0-preview.3.24105.21/8.0.100

We highly recommend publishing in release mode for all deployment tools, azd included! While Release is the default for .NET 8, since azd may support more than the .NET 8 SDK I'd probably go with making it explicit and specifying -c Release in your publish command. It looks like a user can supply a configuration already, but I'd lean into a safer default of Release if the user doesn't explicitly specify.


influxdb metrics weird

As seen below, it reports http data as 0.X. Is that intentional?

I'm not sure what you are referring to 0.X.

In the image attached, it shows HTTP queries as 0.05 ops or 0.30 ops.
That seems inaccurate to me. Unless I don't understand it right?

I see what you are referring to.  I don't currently have those dashboards running so I can't validate the data, but that does look odd.

closing as the old dashboards are not kept up to date.


update Project.toml

Updates compats to suit newest GeoParams.jl release

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Additional details and impacted files

:loudspeaker: Thoughts on this report? Let us know!


Add paginator for acm.list_certificates

Current coverage is 97.30% (diff: 100%)

Merging #1000 into develop will not change coverage

@@            develop      #1000   diff @@
==========================================
  Files            43         43
  Lines          7091       7091
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           6900       6900
  Misses          191        191
  Partials          0          0

Powered by Codecov. Last update 5b41b6e...8792e3e

Looks good :ship:.
cc for review as well: @jamesls @JordonPhillips

:shipit:


change Path specifications for Linux and solve syntax error

Changed the path specification for Linux in line 20 of pyARSS.py from cmd = moddir + "\\bin_linux\\arss" to cmd = moddir + "/bin_linux/arss"
Line 76 throws syntax error which was solved by moving the comment down.
Tested on Ubuntu 20.04.1

Thanks!


realtime update https://merge.goant.xyz/?diff=6000

support set the diff by your self
the result only cache 60s

cool, thanks!


TypeError: Cannot read property '__reactFiber$3rntq2todqi' of null

Hey, I encounter an issue when using chakra-ui with this library. Here is a reproduction:
https://stackblitz.com/edit/node-mqa7dt?devtoolsheight=33&file=Component.test.js
You can run yarn test in order to reproduce

Looks like it's related to latest @emotion version https://stackblitz.com/edit/node-p2rm9t

Closing the issue as it has to do with @emotion package


Improve ockam tcp-inlet delete --help text (clap command)

Current behavior
The current ALIAS for ockam tcp-inlet delete --help says Name assigned to that will be deleted. An issue was raised to change this.
Proposed changes
I change the ALIAS to Delete the inlet with this alias name base on the instruction
Checks

[x] All commits in this Pull Request are signed and Verified by Github.
[x] All commits in this Pull Request follow the Ockam commit message convention.
[x] There are no Merge commits in this Pull Request. Ockam repo maintains a linear commit history. We merge Pull Requests by rebasing them onto the develop branch. Rebasing to the latest develop branch and force pushing to your Pull Request branch is okay.
[x] I have read and accept the Ockam Community Code of Conduct.
[x] I have read and accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam repository. The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a separate Pull Request, this will mark the commit as verified.

@Michaelin007 Thank you for spending time on this, before we can merge please

[ ] Accept the Ockam Contributor License Agreement by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate new pull request to the build-trust/ockam repository.

The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a PR, this will mark the commit as verified.

@Michaelin007 Thank you for spending time on this, before we can merge please

[ ]  Accept the Ockam Contributor License Agreement by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate new pull request to the build-trust/ockam repository.

The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a PR, this will mark the commit as verified.

Hi @mrinalwadhwa, I have created a separate PR to add my details to the CONTRIBUTORS.csv. Thanks a lot


Some https related things and Echo Dialog directives

Better errors, print the error due to which stuff failed on server
Fallback to insecureSkipVerify for cert errors
EchoDirectives, Dialog, ConfirmationStatus of Intent

If this ends up getting merged then we should probably close this pull request that I opened a little while ago: https://github.com/mikeflynn/go-alexa/pull/21

I just looked at #21, it definitely has more features, do all of them work the way pull request is at the moment?

#21 has conflicts now anyway, so we lets just make sure this has both features in it and I can merge.
(Also, feel free to ping me on Twitter [@thatmikeflynn] when I fall behind on my insane list of GitHub notifications.)

Okay, I have added things from #21 and some of my own interpretation of what alexa had to offer..
Kindly review!
Thanks,
RohitG

What's the consensus here? @rking788 @harrisonhjones? I don't have time to fully vet this, so I'll merge on your advisement.
Thanks for the PR, @rohitggarg!

Hey Mike,
Please wait for a little while, I will drop in a change for the insecure flag and let you know.

I will try to look at this later tonight.

This should be good now.
Thanks,
RohitG

Looks good to me. Thanks @rohitggarg for the contribution!


Backport: Synchronize console (#227) and FileLogger (#378) writes

Back port
Cherry-picked #227 and #378
Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

LGTM. I think it would be better to rebase-merge this to keep the commits separate though. Merging without rebasing is only useful for forward-ports.

Ah, okay. Good to know.


Update dbt source to use SchemaFieldPath versions 2

Description
This will fix the issue of duplicated columns for dbt/Athena datasets. The change also removed adding any column tags as tags in DataHub as this would overcomplicate the solution and is not something we're using anyway. We can still have tags in dbt models but we need to use metamapping to make sure they get ingested.
This also improves the visualisation of fields with more complex schemas like shown below.
Before:

After:

Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

@danielcmessias regarding this
(for some reason is not giving me the option to reply to the comment)
The constructor is actually being called with cls() here, so that's probably why you couldn't find it.


use window as background for -ms-high-contrast

This PR fixes #109402

We'd love to get some attention on this as it's causing an accessibility compliance issue on a Microsoft site right now.

I could not reproduce the original issue when running in our test page or in our website, so there might be something about the CSS on that specific page. See https://github.com/microsoft/vscode/issues/109402#issuecomment-729512357


Doesn't work in MS Edge or IE11

Load up https://etcdevteam.github.io/hashicon/examples/ in Edge or IE and you will see it doesnt load the icons. Ive implemented it using React and get a few js errors in the console.
Both the hashicon demo site and my localhost get this:

Will support for Edge and IE be added?

Yes.  The current code is written in modern javascript (ES6), we need to transpile for older browsers (I'm surprised IE Edge doesn't handle it..).
TODO: Babel (as rollup plugin) will solve this.

@oori, I see that babel is commented out in the rollup config file. Is this intentional? Will uncommenting the plugin fix?

Nope..  Using "rollup-plugin-babel" is the start, but requires more.
Lack of time and need pushes this down on my TODO list, but I'll try to do it soon.
PR welcome.


Issue #720: Add ulimit -c unlimited -S to CI

Trying to fix issue #720 and follow example here.

Codecov Report

Merging #721 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #721      +/-   ##
==========================================
+ Coverage   66.52%   66.54%   +0.01%
==========================================
  Files          50       50
  Lines        6232     6232
==========================================
+ Hits         4146     4147       +1
+ Misses       2086     2085       -1

Impacted Files
Coverage Δ

include/pistache/async.h
88.12% <0%> (+0.31%)
:arrow_up:

Continue to review full report at Codecov.

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


Adding BigQuery to the list of supported DBs.

Since BQ is a popular data source, I figure it's good to list it in the README.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #6848   +/-   ##
=======================================
  Coverage   56.32%   56.32%
=======================================
  Files         527      527
  Lines       23528    23528
  Branches     2781     2781
=======================================
  Hits        13251    13251
  Misses       9866     9866
  Partials      411      411

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 0b1fbf8...bdc484d. Read the comment docs.


Different output with same input

Hi Erik,
we updated from freebayes 1.2.0 to 1.3.1 and noticed changing output in out nightly tests without any changes to that data.
When I tried to create a minimal test case, I noitced that the variant calls vary when I copy the data to different folders.
Here the output of the attached example data:
example.zip

Call on NA12878 data:

rm -rf subdir *.vcf
/mnt/share/opt/freebayes-1.3.1/bin/freebayes -t roi.bed --min-alternate-fraction 0.1 --min-mapping-quality 1 --min-base-quality 15 --min-alternate-qsum 90 -f /tmp/local_ngs_data/GRCh37.fa -b NA12878_03.bam -v vc1.vcf

Copy the data to 'subdir' and call again:

mkdir subdir
cp NA12878_03.bam NA12878_03.bam.bai roi.bed subdir/
/mnt/share/opt/freebayes-1.3.1/bin/freebayes -t subdir/roi.bed --min-alternate-fraction 0.1 --min-mapping-quality 1 --min-base-quality 15 --min-alternate-qsum 90 -f /tmp/local_ngs_data/GRCh37.fa -b subdir/NA12878_03.bam -v vc2.vcf

now there are differences in the calls:

diff vc1.vcf vc2.vcf
> chr11 94189450        .       C       A       4.60471e-14     .       AB=0;ABP=0;AC=0;AF=0;AN=2;AO=73;CIGAR=1X;DP=580;DPB=580;DPRA=0;EPP=161.528;EPPR=618.222;GTI=0;LEN=1;MEANALT=1;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=455.681;PAIRED=1;PAIREDR=1;PAO=0;PQA=0;PQR=0;PRO=0;QA=1389;QR=15889;RO=507;RPL=73;RPP=161.528;RPPR=489.424;RPR=0;RUN=1;SAF=0;SAP=161.528;SAR=73;SRF=49;SRP=719.472;SRR=458;TYPE=snp;technology.ILLUMINA=1     GT:DP:AD:RO:QR:AO:QA:GL 0/0:580:507,73:507:15889:73:1389:0,-49.4014,-1304.64
< chr11 94189450        .       C       A       4.6288e-14      .       AB=0;ABP=0;AC=0;AF=0;AN=2;AO=73;CIGAR=1X;DP=580;DPB=580;DPRA=0;EPP=161.528;EPPR=618.222;GTI=0;LEN=1;MEANALT=1;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=455.681;PAIRED=1;PAIREDR=1;PAO=0;PQA=0;PQR=0;PRO=0;QA=1389;QR=15889;RO=507;RPL=73;RPP=161.528;RPPR=489.424;RPR=0;RUN=1;SAF=0;SAP=161.528;SAR=73;SRF=49;SRP=719.472;SRR=458;TYPE=snp;technology.ILLUMINA=1     GT:DP:AD:RO:QR:AO:QA:GL 0/0:580:507,73:507:15889:73:1389:0,-49.4014,-1304.64
159c159
> chr11 108119615       .       CAAAAAAAAAAAAAAGAAAAAAGTGGATT   CAAAAAAAAAAAAAGAAAAAAGTGGATT    0.166228        .       AB=0.157895;ABP=22.325;AC=1;AF=0.5;AN=2;AO=3;CIGAR=1M1D27M;DP=19;DPB=18.4828;DPRA=0;EPP=9.52472;EPPR=19.0002;GTI=0;LEN=1;MEANALT=4;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=3.24375;PAIRED=1;PAIREDR=1;PAO=1;PQA=37.5;PQR=37.5;PRO=1;QA=102;QR=414;RO=11;RPL=3;RPP=9.52472;RPPR=19.0002;RPR=0;RUN=1;SAF=0;SAP=9.52472;SAR=3;SRF=0;SRP=26.8965;SRR=11;TYPE=del;technology.ILLUMINA=1     GT:DP:AD:RO:QR:AO:QA:GL 0/1:19:11,3:11:414:3:102:-4.95384,0,-33.0304
< chr11 108119615       .       CAAAAAAAAAAAAAAGAAAAAA  CAAAAAAAAAAAAAGAAAAAA   11.1671 .       AB=0.15625;ABP=35.8538;AC=1;AF=0.5;AN=2;AO=5;CIGAR=1M1D20M;DP=32;DPB=30.9545;DPRA=0;EPP=3.44459;EPPR=3.0103;GTI=0;LEN=1;MEANALT=5;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=2.49181;PAIRED=1;PAIREDR=1;PAO=0;PQA=0;PQR=0;PRO=0;QA=177;QR=737;RO=20;RPL=5;RPP=13.8677;RPPR=38.1882;RPR=0;RUN=1;SAF=2;SAP=3.44459;SAR=3;SRF=9;SRP=3.44459;SRR=11;TYPE=del;technology.ILLUMINA=1 GT:DP:AD:RO:QR:AO:QA:GL    0/1:32:20,5:20:737:5:177:-8.39804,0,-58.779

I hope you can find the bug quickly with the information I providid.
Best,
Marc
P.S.: I also noticed a significant speedup of multi-sample calling (~70% less run time). Is that intended? It's not in the release notes, so I was wondering...

The speedup is intended. The change in behavior is a little strange, but
I'm not sure that it's actually a bug. It looks like the range of the
haplotype call is changed.
On Wed, Aug 14, 2019, 08:52 Marc Sturm<EMAIL_ADDRESS>wrote:

Hi Erik,
we updated from freebayes 1.2.0 to 1.3.1 and noticed changing output in
out test cases.
When I tried to create a minimal test case, I noitced that the variant
calls vary when I copy the data to different folders.
Here the output of the attached example data:
example.zip https://github.com/ekg/freebayes/files/3500120/example.zip

Call on NA12878 data:
rm -rf subdir *.vcf

/mnt/share/opt/freebayes-1.3.1/bin/freebayes -t roi.bed
--min-alternate-fraction 0.1 --min-mapping-quality 1 --min-base-quality 15
--min-alternate-qsum 90 -f /tmp/local_ngs_data/GRCh37.fa -b
NA12878_03.bam -v vc1.vcf

Copy the data to 'subdir' and call again:

mkdir subdir
cp NA12878_03.bam NA12878_03.bam.bai roi.bed subdir/
/mnt/share/opt/freebayes-1.3.1/bin/freebayes -t subdir/roi.bed
--min-alternate-fraction 0.1 --min-mapping-quality 1 --min-base-quality 15
--min-alternate-qsum 90 -f /tmp/local_ngs_data/GRCh37.fa -b
subdir/NA12878_03.bam -v vc2.vcf

now there are differences in the calls:

diff vc1.vcf vc2.vcf

chr11 94189450 . C A 4.60471e-14 .
AB=0;ABP=0;AC=0;AF=0;AN=2;AO=73;CIGAR=1X;DP=580;DPB=580;DPRA=0;EPP=161.528;EPPR=618.222;GTI=0;LEN=1;MEANALT=1;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=455.681;PAIRED=1;PAIREDR=1;PAO=0;PQA=0;PQR=0;PRO=0;QA=1389;QR=15889;RO=507;RPL=73;RPP=161.528;RPPR=489.424;RPR=0;RUN=1;SAF=0;SAP=161.528;SAR=73;SRF=49;SRP=719.472;SRR=458;TYPE=snp;technology.ILLUMINA=1
GT:DP:AD:RO:QR:AO:QA:GL 0/0:580:507,73:507:15889:73:1389:0,-49.4014,-1304.64
< chr11 94189450 . C A 4.6288e-14 .
AB=0;ABP=0;AC=0;AF=0;AN=2;AO=73;CIGAR=1X;DP=580;DPB=580;DPRA=0;EPP=161.528;EPPR=618.222;GTI=0;LEN=1;MEANALT=1;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=455.681;PAIRED=1;PAIREDR=1;PAO=0;PQA=0;PQR=0;PRO=0;QA=1389;QR=15889;RO=507;RPL=73;RPP=161.528;RPPR=489.424;RPR=0;RUN=1;SAF=0;SAP=161.528;SAR=73;SRF=49;SRP=719.472;SRR=458;TYPE=snp;technology.ILLUMINA=1
GT:DP:AD:RO:QR:AO:QA:GL 0/0:580:507,73:507:15889:73:1389:0,-49.4014,-1304.64
159c159
chr11 108119615 . CAAAAAAAAAAAAAAGAAAAAAGTGGATT
CAAAAAAAAAAAAAGAAAAAAGTGGATT 0.166228 .
AB=0.157895;ABP=22.325;AC=1;AF=0.5;AN=2;AO=3;CIGAR=1M1D27M;DP=19;DPB=18.4828;DPRA=0;EPP=9.52472;EPPR=19.0002;GTI=0;LEN=1;MEANALT=4;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=3.24375;PAIRED=1;PAIREDR=1;PAO=1;PQA=37.5;PQR=37.5;PRO=1;QA=102;QR=414;RO=11;RPL=3;RPP=9.52472;RPPR=19.0002;RPR=0;RUN=1;SAF=0;SAP=9.52472;SAR=3;SRF=0;SRP=26.8965;SRR=11;TYPE=del;technology.ILLUMINA=1
GT:DP:AD:RO:QR:AO:QA:GL 0/1:19:11,3:11:414:3:102:-4.95384,0,-33.0304
< chr11 108119615 . CAAAAAAAAAAAAAAGAAAAAA CAAAAAAAAAAAAAGAAAAAA 11.1671 .
AB=0.15625;ABP=35.8538;AC=1;AF=0.5;AN=2;AO=5;CIGAR=1M1D20M;DP=32;DPB=30.9545;DPRA=0;EPP=3.44459;EPPR=3.0103;GTI=0;LEN=1;MEANALT=5;MQM=60;MQMR=60;NS=1;NUMALT=1;ODDS=2.49181;PAIRED=1;PAIREDR=1;PAO=0;PQA=0;PQR=0;PRO=0;QA=177;QR=737;RO=20;RPL=5;RPP=13.8677;RPPR=38.1882;RPR=0;RUN=1;SAF=2;SAP=3.44459;SAR=3;SRF=9;SRP=3.44459;SRR=11;TYPE=del;technology.ILLUMINA=1
GT:DP:AD:RO:QR:AO:QA:GL 0/1:32:20,5:20:737:5:177:-8.39804,0,-58.779

I hope you can find the bug quickly with the information I providid.
Best,
Marc
P.S.: I also noticed a significant speedup of multi-sample calling (~70%
less run time). Is that intended? It's not in the release notes, so I was
wondering...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ekg/freebayes/issues/560?email_source=notifications&email_token=AABDQEOPLINWVIQWBCVBL5DQEOTTRA5CNFSM4ILRT7L2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HFEARIQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDQEKNZZX7VKVM4AJFVPLQEOTTRANCNFSM4ILRT7LQ
.

It might not be a severe bug, but for us it's not really acceptable to get different results for exactly the same data. We need the results to be reproducible.
Most of the time the differences are low-quality variants, but once an additional quality 200 variant popped up in our test cases. That's not really acceptable in diagnostics...
Best,
Marc

It is important that we fix errors. It will be the case that some erroneous
calls are removed through the process of improvement. That this will change
your pipelines is natural. It is good you are trying to understand the
change.
However, the issue is slightly different here. The calls that you have
shared are not semantically different. They assert the same alleles over a
different range of the reference. This is not a problem. Apply
normalization routines in vt, samtools, bcftools, vcflib, or vcf-tools to
remove the additional reference matching sequence when doing your
comparison. If you find significant differences that you can validate to be
incorrect in the new version then I will be happy to look into it.
On Wed, Aug 14, 2019, 10:22 Marc Sturm<EMAIL_ADDRESS>wrote:

It might not be a severe bug, but for us it's not really acceptable to get
different results for exactly the same data. We need the results to be
reproducible.
Most of the time the differences are low-quality variants, but once an
additional quality 200 variant popped up in our test cases. That's not
really acceptable in diagnostics...
Best,
Marc
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ekg/freebayes/issues/560?email_source=notifications&email_token=AABDQEJVNICUIRJKSUBSYLDQEO6CZA5CNFSM4ILRT7L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ICDPA#issuecomment-521150908,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDQEIAQU4JYXYOM2QWTSLQEO6CZANCNFSM4ILRT7LQ
.

Hi Erik,
the extra bases are not the problem in the case of the variant at chr11:108119615.
As you say, they are taken care of by variant normalization.
We use VcfLeftNormalize for normalization.
However that quality is very different as well. One time it is 0.16 and one time 11.16.
This leads to variants that randomly appear and disappear when we apply quality filters (e.g. min quality 10).
Best,
Marc

Ok, I understand your concern. Would you be able to show some cases where
this is introducing an error that you validate with another method?
In this case, I am somewhat skeptical of the call because it's in a
homopolymer. On the other hand, if the reads don't have systematic indel
errors then it isn't unreasonable to see 5 alternate and 20 reference
observations.
The change in quality is because more alignments fully overlap the shorter
window, and are thus considered together.
The window size has changed because I resolved a bug in the entropy
dependent haplotype window determination.
On Wed, Aug 14, 2019, 11:07 Marc Sturm<EMAIL_ADDRESS>wrote:

Hi Erik,
the extra bases are not the problem in the case of the variant at
chr11:108119615.
As you say, they are taken care of by variant normalization.
We use VcfLeftNormalize
https://github.com/imgag/ngs-bits/blob/master/doc/tools/VcfLeftNormalize.md
for normalization.
However that quality is very different as well. One time it is 0.16 and
one time 11.16.
This leads to variants that randomly appear and disappear when we apply
quality filters (e.g. min quality 10).
Best,
Marc
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ekg/freebayes/issues/560?email_source=notifications&email_token=AABDQEJOBXM5MR7YOERNNZDQEPDLLA5CNFSM4ILRT7L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IFYPY#issuecomment-521165887,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDQEJYIZVTN3ZP26VR4LDQEPDLLANCNFSM4ILRT7LQ
.

Hi Erik,
no, we did not validate the variants and I agree that they are mostly in in bad quality regions.
However, both calls were performed with the same version of freebayes (1.3.1), so the same results should be reported. The only difference was the location of the BAM/BED files, so the variant calls are not deterministic with version 1.3.1. We did not see this kind of behavior with version 1.2.0.
Best,
Marc

Ok now I understand. Sorry to be confused.
This is incredibly strange. The file location should be irrelevant. I
didn't touch anything related to it, and I've never seen a problem like
this before.
On Wed, Aug 14, 2019, 12:34 Marc Sturm<EMAIL_ADDRESS>wrote:

Hi Erik,
no, we did not validate the variants and I agree that they are mostly in
in bad quality regions.
However, both calls were performed with the same version of freebayes
(1.3.1), so the same results should be reported. The only difference was
the location of the BAM/BED files, so the variant calls are not
deterministic with version 1.3.1. We did not see this kind of behavior with
version 1.2.0.
Best,
Marc
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ekg/freebayes/issues/560?email_source=notifications&email_token=AABDQEKHREIWZPVSRWV5KJ3QEPNR5A5CNFSM4ILRT7L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IMN2A#issuecomment-521193192,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDQEIF36WY2URYCVNND4DQEPNR5ANCNFSM4ILRT7LQ
.

I'll need this file to reproduce your tests:
tmp/local_ngs_data/GRCh37.fa
On Wed, Aug 14, 2019, 13:59 Erik Garrison<EMAIL_ADDRESS>wrote:

Ok now I understand. Sorry to be confused.
This is incredibly strange. The file location should be irrelevant. I
didn't touch anything related to it, and I've never seen a problem like
this before.
On Wed, Aug 14, 2019, 12:34 Marc Sturm<EMAIL_ADDRESS>wrote:

Hi Erik,
no, we did not validate the variants and I agree that they are mostly in
in bad quality regions.
However, both calls were performed with the same version of freebayes
(1.3.1), so the same results should be reported. The only difference was
the location of the BAM/BED files, so the variant calls are not
deterministic with version 1.3.1. We did not see this kind of behavior with
version 1.2.0.
Best,
Marc
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ekg/freebayes/issues/560?email_source=notifications&email_token=AABDQEKHREIWZPVSRWV5KJ3QEPNR5A5CNFSM4ILRT7L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IMN2A#issuecomment-521193192,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDQEIF36WY2URYCVNND4DQEPNR5ANCNFSM4ILRT7LQ
.

Sorry, I was not really clear either.
I should have made my point of the last comment clearly in the initial issue :)
You can download the genome from:
https://download.imgag.de/ahsturm1/GRCh37.fa
https://download.imgag.de/ahsturm1/GRCh37.fa.fai
Here some additional info about OS, compiler, etc:


Setup release-it

Including generating Changelog. ~This also means getting rid of our historical gulp setup, see #952~

We can use rwjblue's setup script as a starting point: https://github.com/rwjblue/create-rwjblue-release-it-setup

This also means getting rid of our historical gulp setup, see #952

The gulp script currently provides two tasks:

Generate the changelog.
Build and publish the docs app.

The first one could be replaced by release-it-lerna-changelog. This is done in #410
The seconds one should not be done as part of release-it in my opinion. It's better handled by CI in my opinion. It does not only speed up the release cause maintainer does not need to wait until the app is build and uploaded. It could also be used to publish on each merge into master as soon as we have versioned docs app. One example addon that uses this strategy is ember-file-upload: https://github.com/adopted-ember-addons/ember-file-upload/blob/4469a3e36f64167940bac65978b57d1bbd936d1c/.travis.yml#L53-L56

I agree with all you said. Let's keep the docs publishing a separate thing.

Closed by #1040


[tokenizer] Adds more pooling mode form TextEmbedding

Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report
Base: 72.08% // Head: 71.56% // Decreases project coverage by -0.52% :warning:

Coverage data is based on head (025adb8) compared to base (bb5073f).
Patch coverage: 73.77% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2261      +/-   ##
============================================
- Coverage     72.08%   71.56%   -0.53%
- Complexity     5126     6364    +1238
============================================
  Files           473      631     +158
  Lines         21970    28147    +6177
  Branches       2351     2994     +643
============================================
+ Hits          15838    20142    +4304
- Misses         4925     6539    +1614
- Partials       1207     1466     +259

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...main/java/ai/djl/modality/cv/output/Rectangle.java
72.41% <0.00%> (ø)

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <0.00%> (-5.24%)
:arrow_down:

.../modality/cv/translator/ImageFeatureExtractor.java
0.00% <0.00%> (ø)

.../ai/djl/modality/cv/translator/YoloTranslator.java
27.77% <0.00%> (+18.95%)
:arrow_up:

...ain/java/ai/djl/modality/cv/util/NDImageUtils.java
59.21% <0.00%> (ø)

api/src/main/java/ai/djl/modality/nlp/Decoder.java
63.63% <ø> (ø)

... and 564 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Upgrade Hugo geekdoc theme

Theme is old, and use of deprecated functions is causing doc builds to fail. Update hugo-geekdocs to latest, to fix.

Merging with override since it's my PR.


Enhanced key bindings in .tmux.conf for improved navigation and clipboard management, enabling paste functionality in non-tmux terminals and text editors

These configurations enhance tmux usability by integrating mouse support and vi-style key bindings, making navigation more intuitive and efficient. The addition of clipboard management allows you to seamlessly copy text from tmux panes to be pasted into non-tmux terminals and text editors. This setup optimizes workflow within tmux,facilitating a smoother experience when managing multiple terminal sessions.

This should go in your own .local customization file


segfault in sgemm_kernel_direct on x86_64: Illegal instruction

Over in NumPy, we are getting a segfault using commit ddcbed66. xref numpy/numpy#15796. I can reliably trigger this in numpy on my x86_64 laptop via
git checkout master
bash tools/pypy_test.sh

It does require sudo to install some helper packages, then downloads a pre-built OpenBLAS, and runs NumPy tests. I don't think this is a threading problem, since I don't see the [New Thread 0x7fffee89b700 (LWP 14552)] message around this call like I do when threads are active. Could there be a buffer overrun somewhere?
I am not sure it is a OpenBLAS error, since it only happens on PyPy. Any hints to debug would be welcome.

Don't think any non-Haswell instructions could have crept up in that file recently, could it be an alignment issue ?

Maybe this is caused by a DYNAMIC_ARCH=1 compilation on a SKX CPU and then run on a HSW CPU. The /interface/gemm.c was compiled with USE_SGEMM_DIRECT=1 thus linked to sgemm_kernel_direct() function which can only run on CPUs supporting avx512.

Ah yes you are right - then this must have been lurking for a while... technically the interface codes should not be assuming anything about the cpu I think. Now how to resolve this, apart from disabling this in the DYNAMIC_ARCH case as a stopgap measure ? Perhaps that sgemm_direct_performant function can be lifted out of the skylakex kernel and/or overridden in driver/others/dynamic.c

I guess that the simplest way is to compare "gotoblas" struct pointer with the address of gotoblas_SKYLAKEX before calling sgemm_kernel_direct(), when DYNAMIC_ARCH is enabled.

Going with that theory: this would explain why the azure CI is showing these failures while the travis CI is not: the original OpenBLAS libraries are compiled on travis machines, which I think have avx512 CPUs.

@wjc404 thanks for your suggestion, glad this is what I arrived at just a little later (now hope I did it correctly)

Hmm. Wouldn't that fail only if the DYNAMIC_ARCH build was done on an AVX512 host without setting TARGET to something less powerful ? (In which case the build would be hosed anyway as the compliler could have generated AVX512 instructions anywhere in the common code).

I guess this is consistent with the following from the README.

The TARGET option can be used in conjunction with DYNAMIC_ARCH=1 to specify which cpu model should be assumed for all the common code in the library, usually you will want to set this to the oldest model you expect to encounter.

Maybe TARGET should be PRESCOTT or something like that if not specified in a DYNAMIC_ARCH x86 build?

There probably will be "legitimate" cases where the default TARGET can be the build host. (And eventually there will be something newer than SKYLAKEX, so even defaulting to something non-AVX512 when building on SKX may not be a good idea in the future)

The theory that is it is due to running on Azure machines when OpenBLAS is compiled on Travis-ci was debunked in numpy/numpy#15809. Forcing the buffers to be misaligned does not seem to trigger a "illegal instruction. It may be some kind of race condition. Are there environment variables I can use to help debug this from a release build of OpenBLAS?

Not sure how that was debunked, but the sgemm_kernel_direct function should only ever get called when the build was done on an AVX512-capable machine without TARGET being explicitly set to some older cpu.

To actually answer your question (sorry), you can set OPENBLAS_CORETYPE at runtime to override automatic cpu detection (e.g. export OPENBLAS_CORETYPE=NEHALEM), and OPENBLAS_NUM_THREADS (or OMP_NUM_THREADS if using OpenMP) to limit the number of threads to less than the available (semi)cores in the system. As noted above I believe neither is likely to have any influence on this issue.

Merged #1527 now

Assumed fixed by #2533 (though it is probably still not a good idea to build DYNAMIC_ARCH on SKX without specifying a lower-capability TARGET for the common codes)

Maybe TARGET should be PRESCOTT or something like that if not specified in a DYNAMIC_ARCH x86 build

@isuruf this makes sense. Is PRESCOTT going to be the lowest current CPU NumPy is likely to encounter?

Is PRESCOTT going to be the lowest current CPU NumPy is likely to encounter?

On x86_64, yes.


Repology no longer tracks repository winget

https://repology.org/repository/winget -> 404

Sorry, but Repology no longer tracks repository winget.
Last time Repology has processed this repository was 2024-05-31 17:20 (4 months ago).
Some of the reasons which may have caused this:

The repository has reached its end of life, is no longer updated or supported, should no longer be used, and has probably disappeared from the mirrors. There may be a newer version of this repository available though, check the list.
Repository has stopped publishing information about its packages in format usable to Repology, so it's can't be processed any more. You may try contacting repository owners and ask them to fix this.

https://github.com/repology/repology-updater/issues/1392#issuecomment-2144956402

Related to https://github.com/microsoft/winget-pkgs/issues/156468

When this is fixed https://github.com/microsoft/winget-pkgs/commit/59836656277d6844b6300f9273a61d3076a6f117 can be reverted.

It's fixed, you can do the revert and close this issue. (https://github.com/repology/repology-updater/issues/1392)