APT Key Expired and Unable to Update / Install

Background Info

windows version 1803
kali was previously installed
WSL was fully uninstalled after the first segmentation fault

Possible Cause

Kali docker image (if I'm getting this right) is outdated
APT cache and Kali GPG keys are outdated

Potential Fix

Update Kali docker image with

Newer Kali GPG keys imported
APT cache updated

Please tell me if I got anything wrong or if this issue doesn't belong here.
When attempting to update, APT throws the following error:
root@AVLWS:/mnt/c/Users/K4YT3X# apt update
Get:1 http://kali.mirror.globo.tech/kali kali-rolling InRelease [30.5 kB]
Err:1 http://kali.mirror.globo.tech/kali kali-rolling InRelease
  The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository<EMAIL_ADDRESS>Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: http: aptMethod::Configuration: could not load seccomp policy: Invalid argument
W: http: aptMethod::Configuration: could not load seccomp policy: Invalid argument
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://kali.mirror.globo.tech/kali kali-rolling InRelease: The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository<EMAIL_ADDRESS>W: Failed to fetch http://http.kali.org/kali/dists/kali-rolling/InRelease  The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository<EMAIL_ADDRESS>W: Some index files failed to download. They have been ignored, or old ones used instead.
root@AVLWS:/mnt/c/Users/K4YT3X#

If we try to install new key
root@AVLWS:/mnt/c/Users/K4YT3X# apt-key adv --keyserver hkp://keys.gnupg.net --recv ED444FF07D8D0BF6
E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation
root@AVLWS:/mnt/c/Users/K4YT3X#

If we try to install gnupg2 using APT
root@AVLWS:/mnt/c/Users/K4YT3X# apt install gnupg2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dirmngr gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libassuan0
  libksba8 libldap-2.4-2 libldap-common libnpth0 libsasl2-2 libsasl2-modules libsasl2-modules-db libsqlite3-0
  pinentry-curses
Suggested packages:
  dbus-user-session libpam-systemd pinentry-gnome3 tor parcimonie xloadimage scdaemon libsasl2-modules-gssapi-mit
  | libsasl2-modules-gssapi-heimdal libsasl2-modules-ldap libsasl2-modules-otp libsasl2-modules-sql pinentry-doc
The following NEW packages will be installed:
  dirmngr gnupg gnupg-l10n gnupg-utils gnupg2 gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libassuan0
  libksba8 libldap-2.4-2 libldap-common libnpth0 libsasl2-2 libsasl2-modules libsasl2-modules-db libsqlite3-0
  pinentry-curses
0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 7260 kB/7962 kB of archives.
After this operation, 16.0 MB of additional disk space will be used.
Do you want to continue?
(Reading database ... 9041 files and directories currently installed.)
Preparing to unpack dirmngr_2.2.8-3_amd64.deb ...
Unpacking dirmngr (2.2.8-3) ...
Selecting previously unselected package gnupg-l10n.
Preparing to unpack gnupg-l10n_2.2.8-3_all.deb ...
Unpacking gnupg-l10n (2.2.8-3) ...
Selecting previously unselected package gnupg-utils.
Preparing to unpack gnupg-utils_2.2.8-3_amd64.deb ...
Unpacking gnupg-utils (2.2.8-3) ...
Selecting previously unselected package gnupg2.
Preparing to unpack gnupg2_2.2.8-3_all.deb ...
Unpacking gnupg2 (2.2.8-3) ...
Selecting previously unselected package gnupg.
Preparing to unpack gnupg_2.2.8-3_all.deb ...
Unpacking gnupg (2.2.8-3) ...
Selecting previously unselected package gpg-agent.
Preparing to unpack gpg-agent_2.2.8-3_amd64.deb ...
Unpacking gpg-agent (2.2.8-3) ...
Selecting previously unselected package gpg-wks-client.
Preparing to unpack gpg-wks-client_2.2.8-3_amd64.deb ...
Unpacking gpg-wks-client (2.2.8-3) ...
Selecting previously unselected package gpg-wks-server.
Preparing to unpack gpg-wks-server_2.2.8-3_amd64.deb ...
Unpacking gpg-wks-server (2.2.8-3) ...
Selecting previously unselected package gpg.
Preparing to unpack gpg_2.2.8-3_amd64.deb ...
Unpacking gpg (2.2.8-3) ...
Selecting previously unselected package gpgconf.
Preparing to unpack gpgconf_2.2.8-3_amd64.deb ...
Unpacking gpgconf (2.2.8-3) ...
Selecting previously unselected package gpgsm.
Preparing to unpack gpgsm_2.2.8-3_amd64.deb ...
Unpacking gpgsm (2.2.8-3) ...
Selecting previously unselected package libassuan0:amd64.
Preparing to unpack libassuan0_2.5.1-2_amd64.deb ...
Unpacking libassuan0:amd64 (2.5.1-2) ...
Selecting previously unselected package libksba8:amd64.
Preparing to unpack libksba8_1.3.5-2_amd64.deb ...
Unpacking libksba8:amd64 (1.3.5-2) ...
Selecting previously unselected package libldap-2.4-2:amd64.
Preparing to unpack libldap-2.4-2_2.4.46+dfsg-5_amd64.deb ...
Unpacking libldap-2.4-2:amd64 (2.4.46+dfsg-5) ...
Selecting previously unselected package libldap-common.
Preparing to unpack libldap-common_2.4.46+dfsg-5_all.deb ...
Unpacking libldap-common (2.4.46+dfsg-5) ...
Selecting previously unselected package libnpth0:amd64.
Preparing to unpack libnpth0_1.5-4_amd64.deb ...
Unpacking libnpth0:amd64 (1.5-4) ...
Selecting previously unselected package libsasl2-2:amd64.
Preparing to unpack libsasl2-2_2.1.27~101-g0780600+dfsg-3.1_amd64.deb ...
Unpacking libsasl2-2:amd64 (2.1.27~101-g0780600+dfsg-3.1) ...
Selecting previously unselected package libsasl2-modules-db:amd64.
Preparing to unpack libsasl2-modules-db_2.1.27~101-g0780600+dfsg-3.1_amd64.deb ...
Unpacking libsasl2-modules-db:amd64 (2.1.27~101-g0780600+dfsg-3.1) ...
Selecting previously unselected package libsasl2-modules:amd64.
Preparing to unpack libsasl2-modules_2.1.27~101-g0780600+dfsg-3.1_amd64.deb ...
Unpacking libsasl2-modules:amd64 (2.1.27~101-g0780600+dfsg-3.1) ...
Selecting previously unselected package libsqlite3-0:amd64.
Preparing to unpack libsqlite3-0_3.24.0-1_amd64.deb ...
Unpacking libsqlite3-0:amd64 (3.24.0-1) ...
Selecting previously unselected package pinentry-curses.
Preparing to unpack pinentry-curses_1.1.0-1+b1_amd64.deb ...
Unpacking pinentry-curses (1.1.0-1+b1) ...
Setting up gnupg-l10n (2.2.8-3) ...
dpkg: dependency problems prevent configuration of gnupg:
 gnupg depends on gpgv (>= 2.2.8-3); however:
  Version of gpgv on system is 2.2.4-1.

dpkg: error processing package gnupg (--install):
 dependency problems - leaving unconfigured
Setting up libassuan0:amd64 (2.5.1-2) ...
Setting up libksba8:amd64 (1.3.5-2) ...
Setting up libldap-common (2.4.46+dfsg-5) ...
Setting up libnpth0:amd64 (1.5-4) ...
Setting up libsasl2-modules-db:amd64 (2.1.27~101-g0780600+dfsg-3.1) ...
Setting up libsasl2-modules:amd64 (2.1.27~101-g0780600+dfsg-3.1) ...
Setting up libsqlite3-0:amd64 (3.24.0-1) ...
dpkg: dependency problems prevent configuration of pinentry-curses:
 pinentry-curses depends on libncursesw6 (>= 6); however:
  Package libncursesw6 is not installed.
 pinentry-curses depends on libtinfo6 (>= 6); however:
  Package libtinfo6 is not installed.

dpkg: error processing package pinentry-curses (--install):
 dependency problems - leaving unconfigured
Setting up gnupg-utils (2.2.8-3) ...
dpkg: dependency problems prevent configuration of gnupg2:
 gnupg2 depends on gnupg (>= 2.2.8-3); however:
  Package gnupg is not configured yet.

dpkg: error processing package gnupg2 (--install):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gpg-agent:
 gpg-agent depends on pinentry-curses | pinentry; however:
  Package pinentry-curses is not configured yet.
  Package pinentry is not installed.
  Package pinentry-curses which provides pinentry is not configured yet.

dpkg: error processing package gpg-agent (--install):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gpg-wks-client:
 gpg-wks-client depends on gpg-agent (= 2.2.8-3); however:
  Package gpg-agent is not configured yet.

dpkg: error processing package gpg-wks-client (--install):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gpg-wks-server:
 gpg-wks-server depends on gpg-agent (= 2.2.8-3); however:
  Package gpg-agent is not configured yet.

dpkg: error processing package gpg-wks-server (--install):
 dependency problems - leaving unconfigured
Setting up gpgconf (2.2.8-3) ...
Setting up gpgsm (2.2.8-3) ...
Setting up libsasl2-2:amd64 (2.1.27~101-g0780600+dfsg-3.1) ...
Setting up gpg (2.2.8-3) ...
Setting up libldap-2.4-2:amd64 (2.4.46+dfsg-5) ...
Setting up dirmngr (2.2.8-3) ...
Processing triggers for libc-bin (2.25-5) ...
Errors were encountered while processing:
 gnupg
 pinentry-curses
 gnupg2
 gpg-agent
 gpg-wks-client
 gpg-wks-server

On the second try, a dynamic link issue occured.
root@AVLWS:/mnt/c/Users/K4YT3X/Desktop/gnupg2# ls
ls: relocation error: /lib/x86_64-linux-gnu/libc.so.6: symbol __tunable_get_val, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

I have the exact same problem!

Found a solution here :
https://askubuntu.com/questions/74345/how-do-i-bypass-ignore-the-gpg-signature-checks-of-apt
rm /var/lib/apt/lists/http.kali.org_kali_dists_kali-rolling_*
The following command is very dangerous, please know what you are doing.
sudo apt -o Acquire::AllowInsecureRepositories=true -o Acquire::AllowDowngradeToInsecureRepositories=true update
sudo apt-get install gnupg2
apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6

I'm surprised someone's still having this problem three years later.

I found this post while googling, so I tought I might help.
I don't even use WSL-Distribution-Switcher but my issue was very similar.


Check if connected to SQL Azure and warn user that platform is not supported.

Checking if the connected instance is SQL Azure via the following code, which returns 1 if the instance is Azure SQL Database, should exit the module with advice that SQL Azure is not supported:
SELECT CASE WHEN CONVERT(nvarchar(128), SERVERPROPERTY(N'Edition')) LIKE N'%Azure%' THEN 1 ELSE 0 END

:thinking: do you have any ideas on adding this support? I do not use Azure so I am not sure what kinds of differences might prevent sqltop from working.

Since Azure updates quietly pretty often, I think the only real way to handle support is to automate testing against it consistently (on PRs or even more often than that). I use appveyor for a project to test on Azure + lots of versions but the Azure piece is a constant PITA and if you don't already have something setup, I'd say it may not be worth it just for that.
A "your mileage may vary" approach might be the easiest, or block it altogether like Hannah suggested.


Add strcpy, strlen, strncpy, strcat, strncat

Depends on #364

I've messed that up a little, will rebase on main after merge of #364.


Slow performance: normal?

I use binary releases of w64devkit (i.e. I don't build it myself) and I've noticed that many of the executables are substantially slower than on windows. Grep -r can take a very long time. Find does as well. Even opening vim generally takes a couple of seconds, though I think that's only after a reboot (maybe windows defender needs to appease itself?).

Is that normal?
Is there something that I'm doing wrong, or that could do to speed it up? Or is this just windows being slow?

Thanks

Your description is neither the intended nor typical behavior. Vim should
start practically instantly. On all of my systems:
$ time vim -Nu NONE +:q
This indicates about 100–150ms to start and exit a "compatible" Vim. If
it's taking much longer, your local system configuration is probably the
cause (virus scanner, etc.). Simple shell commands (ls, cat, etc.) should
feel as fast as they do elsewhere.
If "slower than on windows" you mean Linux, that is expected, though the
differences should be minor. BusyBox prioritizes small and simple over
fast, and so performance will never compare to GNU Coreutils. It makes no
difference for ls, but you'll notice heavy-duty commands like recursive
grep are slower on the same inputs. Windows is also generally slower at
dealing with paths (e.g. opening files/directories), which particularly
affects "find" and "grep -r". Console window performance is also poor,
bottlenecking command that display lots of output (though many terminal
emulators on Linux aren't much better).
I also compile with -Os, tipping optimization towards small and away from
fast, though you'd have a hard time measuring a speed difference from -O2.
A warning for anyone benchmarking: Do not redirect to the NUL device in
benchmarks, including the virtual /dev/null in busybox-w32. Due to an old
msvcrt.dll bug (and still in UCRT!), the CRT treats NUL as a line-oriented
device, like a console, which is probably not what you wanted to measure.


Enable documentation autobuild (for PRs) on Readthedocs

Now that Readthedocs provides automatic build of documentation for pull requests: https://docs.readthedocs.io/en/stable/guides/autobuild-docs-for-pull-requests.html, it would nice to enable this feature for this repo.
Ccing @lesteve, @guillaumeeb who may have administrative access to the dask-jobqueue on Readthedocs.

I am far from a ReadTheDoc expert, I don't believe ever connecting to it, and this looks confirmed by the fact it did'nt know my email...
Maybe @mrocklin can help us here?
And I think @andersy005 you should have every rights on everything related to dask-jobqueue!

I am far from a ReadTheDoc expert, I don't believe ever connecting to it, and this looks confirmed by the fact it did'nt know my email...
Maybe @mrocklin can help us here?
And I think @andersy005 you should have every rights on everything related to dask-jobqueue!

I don't have the rights on readthedocs either.
According to https://readthedocs.org/projects/dask-jobqueue/ maintainers are @mrocklin @jhamman @TomAugspurger @jrbourbeau. If one of you could add me to the dask-jobqueue maintainers on ReadTheDocs that would be great!
Then I can add @guillaumeeb and @andersy005!

I don't have the rights on readthedocs either.
According to https://readthedocs.org/projects/dask-jobqueue/ maintainers are @mrocklin @jhamman @TomAugspurger @jrbourbeau. If one of you could add me to the dask-jobqueue maintainers on ReadTheDocs that would be great!
Then I can add @guillaumeeb and @andersy005!

@lesteve I added you on readthedocs.

@lesteve I added you on readthedocs.

Great thanks! I added @andersy005 @guillaumeeb and @willirath as maintainer on ReadTheDocs and enabled building the doc on PRs.
Closing this one, any issues let me know!

Great thanks! I added @andersy005 @guillaumeeb and @willirath as maintainer on ReadTheDocs and enabled building the doc on PRs.
Closing this one, any issues let me know!


Undefined symbols for architecture x86_64: "DUK_VARARGS"

Hello there, I'm trying the following code:
use ducc::{Ducc};

fn main() {
    let ducc = Ducc::new();

    let func = ducc.create_function(|inv| {
        let (a, b): (usize, usize) = inv.args.into(inv.ducc).uwrap();
        Ok(a + b)
    });

    ducc.globals().set("add", func).unwrap();
}

But the following error occurs:
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-m64" "-L" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/alanhoff/Projects/ductest/target/debug/deps/$uctest-4ed857ff77ff2a19.15uc7ccwcv2sggoy.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.1h2mhh1lezhmpl1b.rcgu.o" "/Users/alanhoff/Projects/duc$est/target/debug/deps/ductest-4ed857ff77ff2a19.1o9sak0djwp0cu9n.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.1tl0jw7in6toutg7.rcgu.o" "/User$/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.204he97yf1e9g301.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.2d212p7h$3vspiqx.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.2kvknh1drs918t6p.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4e$857ff77ff2a19.2tbbw9d7852eyw12.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.35ntzgf66nbpfb7o.rcgu.o" "/Users/alanhoff/Projects/ductest/targe$/debug/deps/ductest-4ed857ff77ff2a19.36x511b9a354ayv.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.3ewclrwmtpeldov8.rcgu.o" "/Users/alanhoff/$rojects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.3fut51dpensxzkbn.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.3xts6afcmj37ti5j.rc$u.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.4f7hnqpd7k57m48q.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2$19.4ha6rjmfou7z0ced.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.4muhw3oestqi42wo.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/dep$/ductest-4ed857ff77ff2a19.59fpeycpfwwwbhlm.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.5c9u4ogk35o2haqn.rcgu.o" "/Users/alanhoff/Projects/d$ctest/target/debug/deps/ductest-4ed857ff77ff2a19.dplgs6d9c1051ds.rcgu.o" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.x4ygs4r5khhuakb.rcgu.o" "-o" "$Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19" "/Users/alanhoff/Projects/ductest/target/debug/deps/ductest-4ed857ff77ff2a19.15n3gzqcp366zbjw.rcgu.o" "-$l,-dead_strip" "-nodefaultlibs" "-L" "/Users/alanhoff/Projects/ductest/target/debug/deps" "-L" "/Users/alanhoff/Projects/ductest/target/debug/build/ducc-sys-56fed41fa3b28b30/out" "$L" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/alanhoff/Projects/ductest/target/debug/deps/libducc-41fdc7277bd506d2$rlib" "/Users/alanhoff/Projects/ductest/target/debug/deps/libducc_sys-6a7f687dcd36b241.rlib" "/Users/alanhoff/Projects/ductest/target/debug/deps/libcesu8-6b61ba793b4c8e70.rlib" "/U$ers/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-d8e5437473efc55d.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-app$e-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-978f8f77602b2ff8.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/$ib/libbacktrace_sys-a67ac3e54cec1633.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_demangle-95f0e5e52206fff4.rl$b" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libhashbrown-9d60b8ff6d472505.rlib" "/Users/alanhoff/.rustup/toolchains/night$y-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_alloc-b50df887d56819fa.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/ru$
tlib/x86_64-apple-darwin/lib/libunwind-b1a59c9cbbe22ae5.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-534a39ff35$
41e78.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-c8c18cd805f8cabb.rlib" "/Users/alanhoff/.rustup/toolchains/$
ightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_core-624ba95ad15c67c4.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/li$
/rustlib/x86_64-apple-darwin/lib/libcore-4d41bd37e688d569.rlib" "/Users/alanhoff/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_buil$
ins-df33d2651a37ff5a.rlib" "-lSystem" "-lresolv" "-lc" "-lm"
  = note: Undefined symbols for architecture x86_64:
            "DUK_VARARGS", referenced from:
                ducc::function::create_callback::he06e3bfbb8a50d3c in libducc-41fdc7277bd506d2.rlib(ducc-41fdc7277bd506d2.ducc.u323l1gq-cgu.15.rcgu.o)
               (maybe you meant: _DUK_VARARGS)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

This is my Cargo.toml
[package]
name = "ductest"
version = "0.1.0"
authors = ["Alan Hoffmeister"]
edition = "2018"

[dependencies]
ducc = { git = "https://github.com/SkylerLipthay/ducc.git" }

And my machine's info:
cargo 1.36.0-nightly (c4fcfb725 2019-05-15)
rustc 1.36.0-nightly (6afcb5628 2019-05-19)
Darwin Alans-MacBook-Pro.local 16.7.0 Darwin Kernel Version 16.7.0: Wed Feb 27 00:29:57 PST 2019; root:xnu-3789.73.43~1/RELEASE_X86_64 x86_64

Hey! I can't reproduce this myself, but I've run into similar problems in the past on macOS. The existence of an alternative toolchain (Xcode) can lead to toolchain mismatches. So I believe the problem is a configuration issue on your machine.
Here's someone who seems to have recently experienced this problem, and who is using the same sort of machine as you are: https://users.rust-lang.org/t/link-failure-when-trying-to-use-cc-bindgen-to-link-c-code/27156
The resolution post in that thread points to this StackOverflow post for more info: https://stackoverflow.com/a/43452124. Perhaps running brew unlink binutils is all you need?
I hope this helps. Let me know if you run into more trouble.

I found the "problem" but I'm not sure how to properly solve it.
Basically clang prepends an underscore on every link while compiling duktape, in fact if you run cargo run --bin ffi-gen --features="build-ffi-gen" inside the ducc-sys crate while on a Mac, you'll notice that bindgen expects that behavior and automatically adds the [#link_name] attribute into all bindings. For example:
extern "C" {
    #[link_name = "\u{1}_DUK_VARARGS"]
    pub static mut DUK_VARARGS: duk_int_t;
}

These are all the steps I performed to fix the issue in my machine:

Cloned https://github.com/SkylerLipthay/ducc.git
Run cargo run --bin ffi-gen --features="build-ffi-gen inside ducc/ducc-sys
Went back to my project and changed the location of ducc inside my Cargo.toml

[dependencies]
ducc = { path = "../ducc/ducc" }

I would submit a PR for ducc-sys but I'm not sure how to correctly deal with this situation. Do you think build.rs should generate the bindings on the fly for non-Linux OS instead of relying on the shipped bindings.rs?
I also created a gist with the bindings.rs generated by my machine in case someone is curious: https://gist.github.com/alanhoff/6e02532ca93f3c9b2ca0296e3da17b6f
Thanks for your time.

Out of curiosity, what happens if you remove the (two) #[link_name = ...] attributes in the original bindings.rs? Seeing that DUK_VARARGS was the only binding that failed to link, I wonder if the linker has no trouble with the bindings without a link_name explicitly marked.

Removing #[link_name] from the original bindings.rs did the trick :-)

Perfect! To systematically prevent #[link_name]s it looks like we can just specify .trust_clang_mangling(false) in ffi_gen.rs. I'll go ahead and make these changes, including merging your PR to whitelist the ducc_* functions. (I'm starting to remember what a pain all of this was for me. I must have added the ducc_* functions to bindings.rs manually so I wouldn't be forced to run ffi_gen again.)
Thanks for troubleshooting!

🙌


The root path

The user technically has the option to specify root_dir when starting up the Registrar object. Which is if they wanted to use their own space on their laptop etc, or somewhere not in the DEFAULT_ROOT.
Does this then create problems as we don't know where the data necessarily is? We only store relative paths in the database.

We definitely need better control of root path.  To start (not exactly addressing the question you've asked) I think we should institute a scheme similar to GCRCatalogs.  That is

dataregistry package includes a configuration file with default values for DEFAULT_ROOT by site.  So far, we only have one site: NERSC.
by default site will be NERSC, but we write code to look for an environment variable, say DATAREGISTRY_SITE, which can override that default.
if site is not NERSC (or any other well-known site with an entry in the configuration file), user must supply a value for root_dir

To take care of the case you mentioned, we could  insist that, for writers, if your connection parameters are referring to the standard postgres db at NERSC, you must use the NERSC DEFAULT_ROOT.   But we have to think about how this might interact with remote users. Is it adding additional restrictions on them?   So far, I haven't been able to imagine a procedure for them to register new datasets, other than through some server at NERSC.  (We could perhaps first transfer their local dataset to NERSC via globus, then have some process running at NERSC to do the actual registration.  But then that process would be following all the rules.)
One way or another, I think we need to enforce, at least for writers, that one uses the standard postgres db if and only if you're also using the NERSC DEFAULT_ROOT.
I'm not

Also we need to provide a way for people to retrieve root_dir so they can form the full path if they want to read a dataset they or someone else has registered.  Assuming some day we might want to mirror some or all datasets at another site, we need a concept of per-site default.   Registrar could have a method which returns the default for the current site - which for now is always NERSC.

We have addressed the "sites" for the root dir and that is now in the main branch.
In #87 I have added the root_dir to the dataset table, so we can keep track of where the dataset was originally registered.
We still don't force a root_dir based on the database you connect to, which is the last open question for this issue.


Is there way to skip over doc links in comments?

In my project I'm making heavy use of links to other types in doc strings.  Because of the capitalization of rust type names, it can cause a lot of false positives.  For example:
error: spellcheck(Hunspell)
   --> /home/stusmall/Workspace/bowbend/bowbend_core/src/service_detection/framework/rule_results.rs:12
    |
 12 |  Returns the [RuleId] of the Rule this result belongs to.  This isn't
    |               ^^^^^^
    | - Rule Id, Ruled, or Rule-id
    |
    |   Possible spelling mistake found.

Does cargo spellcheck have a way to skip over these links?  Or is this better handled by a rule in the dictionary file?
Once again, huge thank you for this project. It's helped keep my documentation much cleaner.

Right after posting this I saw that this is mentioned in the FAQ

It's always good to know people read the FAQ and it actually contains useful info :+1:


Update web-app.md

Description
Add web-app content to web pages which moved from Microsoft tutorial with https://github.com/microsoft/ML-For-Beginners/tree/main/3-Web-App.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

How has this been tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

local build the book
review the artifacts from local build
local build the slides if appliable
[ ] Unit test if appliable

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation
My changes generate no new warnings
I have applied tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

add assignments


Bump runner web

:scroll: Description
#skip-changelog
:bulb: Motivation and Context
Getting warnings from https://github.com/getsentry/sentry-dart/runs/5050190241?check_suite_focus=true
Warning:  build_web_compilers:entrypoint on web/main.dart: Your current analyzer version may not fully support your current SDK version.
Analyzer language version: 2.14.0
SDK language version: 2.15.0
Please update to the latest analyzer version (3.2.0) by running
pub upgrade.
If you are not getting the latest version by running the above command, you
can try adding a constraint like the following to your pubspec to start
diagnosing why you can't get the latest version:
dev_dependencies:
analyzer: ^3.2.0
:green_heart: How did you test it?
:pencil: Checklist

[ ] I reviewed submitted code
[ ] I added tests to verify changes
[ ] I updated the docs if needed
[ ] All tests passing
[ ] No breaking changes

:crystal_ball: Next steps

Codecov Report

Merging #740 (627d1fa) into main (33b07f6) will increase coverage by 5.09%.
The diff coverage is n/a.

:exclamation: Current head 627d1fa differs from pull request most recent head 738c74c. Consider uploading reports for the commit 738c74c to get more accurate results

@@            Coverage Diff             @@
##             main     #740      +/-   ##
==========================================
+ Coverage   90.55%   95.65%   +5.09%
==========================================
  Files         104        2     -102
  Lines        3357       46    -3311
==========================================
- Hits         3040       44    -2996
+ Misses        317        2     -315

Impacted Files
Coverage Δ

dart/lib/src/protocol/sentry_user.dart

flutter/lib/src/flutter_sentry_attachment.dart

dart/lib/src/sentry.dart

...tter/lib/src/flutter_enricher_event_processor.dart

dart/lib/src/protocol/mechanism.dart

...ib/src/sentry_attachment/io_sentry_attachment.dart

dart/lib/src/protocol/sentry_culture.dart

...lib/src/environment/_io_environment_variables.dart

dart/lib/src/transport/rate_limit_parser.dart

flutter/lib/src/sentry_flutter_options.dart

... and 92 more

Continue to review full report at Codecov.

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


docs: remove redundant badges

removed the badges due those are redundant with the information already visible in GitHub

I agree


Improved versioning.

Signed-off-by: Vikram Vaswani<EMAIL_ADDRESS>

Note: This change is internal, end-users should continue to have exactly the same docs experience after merging, with the addition of "contribution guidelines" in the 0.1 docs as stated in https://github.com/dagger/dagger/pull/3319#discussion_r992809297

Note: The files in the unspecified directories are not linked in any of the sidebars.

I'm picking this one up now.

As I was looking at the three commits, all that I was thinking was https://cbea.ms/git-commit/. That article is so good that we reference it in our Contributing to Dagger - Commits too. We add a few extra details about commits which would have been helpful.
Closes #3318 commit summary could have been:
docs: Move files in version-specific dirs

Before this change, it was difficult to know which version of Dagger a
doc file was for. We had to look at the displayed_sidebar value inside
the doc file to know whether it was for Dagger v0.1.x or v0.2.x.

Each doc file is now in either v0.1 or v0.2 dir.

Doc files which are not version specific are stored currently in one of
the following dirs:
- common
- unspecified
- use-cases

For more context, see
https://github.com/dagger/dagger/issues/3318

Closes #3318

Merge branch 'main' into 3318-versioning commit could have been a rebase, as we mention in Contributing to Dagger - GitHub Workflow - 3. Update your pull request...
I have 20 mins left from this time-box.

I was wondering why we moved docs/README.md to docs/_README.md. We now don't see the README by default on the e.g. https://github.com/vikram-dagger/dagger/tree/3318-versioning/docs page.

I was wondering why we moved docs/README.md to docs/_README.md. We now don't see the README by default on the e.g. https://github.com/vikram-dagger/dagger/tree/3318-versioning/docs page.

Good catch. I'm not entirely sure about this but after some testing, I assumed that Docusaurus considers a README.md file as one of the possible index files in a directory. Therefore, when there is a file called README.md and another document with slug: /, the client generates an error about duplicate route at /. Modifying the README.md file name removes this error.

I was wondering why we moved docs/README.md to docs/_README.md. We now don't see the README by default on the e.g. https://github.com/vikram-dagger/dagger/tree/3318-versioning/docs page.

Good catch. I'm not entirely sure about this but after some testing, I assumed that Docusaurus considers a README.md file as one of the possible index files in a directory. Therefore, when there is a file called README.md and another document with slug: /, the client generates an error about duplicate route at /. Modifying the README.md file name removes this error.

I tried to remove this warning and never could understand why it always showed in the CLI, good one @vikram-dagger !
Everything looks good to me. :rocket:

Thanks for promoting this to https://docs.dagger.io @crjm!
The sidebar fix for 0.1 docs tells me that this went through fine:


Define StockFlow equality ignoring position?

eg, foot((:A, :B), (), ()) == foot((:B, :A), (), ()) currently evaluates to false, because the stocks are in a different order, even though it represents the same information

They're not equal, but they're isomorphic; does julia have some sense of isomorphism?

They're not equal, but they're isomorphic; does julia have some sense of
isomorphism?

AlgebraicJulia should, because it's founded on category theory.  However,
in category theory, when composing structured or decorated cospans, or
indeed morphisms of any kind, we only allow ourselves to compose them if
the source of the second is EQUAL TO the target of the first.  Anything
else causes havoc when objects can be isomorphic to themselves in multiple
ways, as they often can.
On Wed, Aug 9, 2023 at 3:12 AM Thomas Purdy @.***>
wrote:

They're not equal, but they're isomorphic; does julia have some sense of
isomorphism?
—
Reply to this email directly, view it on GitHub
https://github.com/AlgebraicJulia/StockFlow.jl/issues/45#issuecomment-1670552934,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7SZZ7JFOCNDWSP7XMTF6TXULWYJANCNFSM6AAAAAA2ZQA33Y
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


EnsureConnected method in TcpPipe is not thread safe.

A SocketException is thrown when multiple listeners use the TcpPipe to report metrics.
The exception seems to be thrown when the tcpClient.Connect is called inside EnsureConnected method by multiple listeners at the same time.
Possible solutions could be

Calling tcpClient.Connect inside the TcpPipe  constructor
Lock around tcpClient.Connect

Thanks for reporting the issue.
The TcpClient class is not thread safe, therefore the write operation would yield an error, too.
I created a pull request that should fix this problem: #26
I will need to do some more testing before I merge it into the main branch, but you can test the changes already by using the threadsafe-tcp branch.
I'd recommend to use udp for multi-threading applications, though.


navigator: don't set the MC cruise speed

Instead, let the multirotor position controller take care of respecting
the cruise velocity. If it is set in the navigator, there is the
drawback that the param value is only respected on a waypoint change
instead of immediately.
I have not looked into the fixedwing implementation and therefore left
it as is.
Tested in SITL.

I'm not sure this is the right approach to fix this.

@LorenzMeier ok, suggest a better approach then.

The position controller is already checking the cruise speed it gets from the navigator:
https://github.com/PX4/Firmware/blob/master/src/modules/mc_pos_control/mc_pos_control_main.cpp#L1154-L1155

I have a better suggestion :)
https://github.com/PX4/Firmware/pull/5614
You can pick these parts out of there.. It splits cruise speed for FW/MC and also takes care of updating them whenever a change speed command arrives. It moves the command handling into the navigator (out of mission block)

@AndreasAntener thanks, that's helpful, I'll have a look!

Why have navigator handle it at all? Just push CMD_DO_CHANGE_SPEED handeling into the position controllers and it'll also work for loiter, follow, etc. We'd also be able to strip the MC and FW cruise params out of navigator.

@dagar Because we can only work towards flying proper trajectories if the time (= speed) handling is centralised in the navigator. Therefore any attempt at simplifying it in the controller are detrimetal to the trajectory tracking we're currently implementing.

I'll use this branch locally until #5614 is in, thanks @AndreasAntener


chore: migrate to Plop v3

https://coveord.atlassian.net/browse/CDX-716

Node 16

That's a harsh requirement, I wasn't on it until recently

Node 16

That's a harsh requirement, I wasn't on it until recently

True, it is more stringent, however, because overall NodeJS and ECMA as a whole is turning its back on CJS and moving toward ESM modules, I think that I would prefer to limit support on Node 16 on the command, and not have to rework it next year
Overall, my two cents:

For existing and released features, we should maintain support on the latest Active and Maintenance LTS version of Node.js (so, for example, I'll drop support for Node 14 in 11 months, or just about 6 months before its official EoL)
For new features, we should support the Active LTS version of Node.js. Support of the Maintenance LTS is encouraged but is not mandatory.

This position is motivated by the rising number of packages that we cannot use because we're stuck with CJS module and engine. I prefer for us to be a step in advance than having to do the work twice.


Unit tests failing (also on Trevis)

Hi all,
I've just noticed that several unit tests fail when running 'make test' for version 2.22.1.
It looks like they also fail on Trevis (e.g. https://travis-ci.org/arq5x/bedtools2/jobs/47671284), although the build is successful.
I guess that Trevis doesn't fail because the test scripts don't return 1 in case any test fails... A solution could be 'set -e' in the test scripts?
thanks for looking into this!
tom

Thanks so much for pointing this out.  It looks like some of the files we use for unit testing have not been added to the github repo.  @nkindlon and I will work on this, as well as fixing the "return 1" issue as soon as possible.


verify video cues play within unity app

CHSession should emit events for video cue start/stop
different aspect ratios should work without handholding
portrait/landscape should work without handholding

to test:

broadcast from Postman
mediaDomain: 1
cueNumber: 1
verify cueActions 0-3 (play, pause, restart, stop)
verify portrait & landscape both work


Style settings can not be applied

Steps to reproduce

Install app-debug.apk
Style -> Choose Color -> Select any color
Popup appears:

Failed to install file:

Application package com.termux not found

Install termux from Google Play (should I?)
Style -> Choose Color -> Select any color
Popup appears:

Failed to install file:

Cannot create termux dir=/data/user/0/com.termux/files/home/.termux

Actually should be filed against https://github.com/t184256/nix-on-droid-app.

Install termux from Google Play (should I?)

No.
I don't have my device at hand, but I have a fairly good idea where it fails, so you can try a 'blind fix' at the moment. May fail on some subsequent stuff though.
https://nix-on-droid.unboiled.info/apk-debug-blind-styling-fix.apk

It works, thank you!


Aware of node.js support in chrome canary?

Hey, I stumbled upon this talk:
https://www.youtube.com/watch?v=x8u0n4dT-WI
And it seems node.js support is coming to chome (at the end of the talk)
I guess you guys are aware of this?

Yep — Chromium DevTools is coming to node.js. :smile:
Once it lands in Node stable, devtool will be mostly obsolete for debugging purposes. I'll update the readmes accordingly.
But devtool will still be useful in other cases, such as blending Node.js and browser APIs (i.e. rendering WebGL canvas to a high quality print).


feat: add env var for ssh private key

Closes https://github.com/coder/envbuilder/issues/333
Allow passing a base64 encoded ssh private key to ENVBUILDER_GIT_SSH_PRIVATE_KEY_BASE64 and using this for git authentication.

I think we should also have an integration test to confirm that this works as expected. Perhaps also validating the behavior when both file and base64 is given.

There's a test SSH server implementation you can probably re-use here: https://github.com/coder/terraform-provider-envbuilder/blob/main/internal/provider/git_test.go#L85

There's a test SSH server implementation you can probably re-use here<EMAIL_ADDRESS>
Yep, that should work. I believe only the PublicKeyHandler implementation needs to be updated to reject/accept the key.

I've added an integration test. It works similar to the existing tests in git_test.go. Rather than checking it has worked without error (as the current git ssh server impl doesn't appear to work properly), it instead checks that the error is one that comes after auth has ran. https://github.com/coder/envbuilder/blob/58ac15f45d3d3ee8479d769cc7c3dfcc7ca64f87/git/git_test.go#L266-L268


BGP not configured but running

I installed calico according to the documentation but i guess that BGP shouldn't be running.
Expected Behavior

If i see the logs, i see some bgp activity and try to peer with other devices
Review bgp configuration during install
Current Behavior

If i see the logs, i see this:
I0119 12:42:42.455673   19086 prober.go:112] Readiness probe for "calico-node-rszfd_kube-system(5cf624de-523b-43cd-8557-d2bbe6458f3e):calico-node" failed (failure): calico/node is not ready: BIRD is not ready: BGP not established with <IP_ADDRESS>021-01-19 12:42:42.412 [INFO][1303] health.go 156: Number of node(s) with BGP peering established = 0

Possible Solution

No bgp activity

First, don't start BGP and second, fix the log line.

... BGP not established with <IP_ADDRESS>021-01-19 ...
Steps to Reproduce (for bugs)

Just install kubernetes, rancher and use as CNI, Calico
You'll see in logs, bgp activities

Context

Not affected by this issue
Try to improve logs and communication/services

Your Environment

Calico version: Calico-node/calicoctl version: container{Container{Name:calico-kube-controllers,Image:rancher/calico-kube-controllers:v3.13.4
Orchestrator version (e.g. kubernetes, rkt, swarm, mesos): Kubernetes
Operating System and version:

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

This issue was originally opened at calico-bgp-daemon project: link of previous issue: https://github.com/projectcalico/calico-bgp-daemon/issues/51

Exactly how did you install Calico?  i.e. which URL did you follow?  Some installation methods need BGP to be working.
This error often occurs when the host that its running on has >1 network interface and calico has picked the wrong one to use.  That can be fixed by setting the IP_AUTODETECTION_METHOD - see https://docs.projectcalico.org/reference/node/configuration#ip-autodetection-methods

Exactly how did you install Calico?  i.e. which URL did you follow?  Some installation methods need BGP to be working.
This error often occurs when the host that its running on has >1 network interface and calico has picked the wrong one to use.  That can be fixed by setting the IP_AUTODETECTION_METHOD - see https://docs.projectcalico.org/reference/node/configuration#ip-autodetection-methods

Thanks for your reply @lwr20, i installed using kubectl:
kubectl apply -f https://docs.projectcalico.org/manifests/flannel-migration/migration-job.yaml

Thanks for your reply @lwr20, i installed using kubectl:
kubectl apply -f https://docs.projectcalico.org/manifests/flannel-migration/migration-job.yaml

Do you see that log line about BGP peers repeatedly? Or is it a transient thing?
Are your cross-host pod to pod connections actually working?
The manifests in the document that you linked already disable BGP by deafult, as evidenced by the readiness probe, which would have a --bird-ready if BGP was being checked:
          readinessProbe:
            exec:
              command:
              - /bin/calico-node
              - -felix-ready

As well as the networking backend, which would be "bird" if BGP was in use:
  # Configure the backend to use.
  calico_backend: "vxlan"

So, given that, I'm actually suprised you're seeing the above warning at all, since the readiness check shouldn't be checking BIRD status. Can you confirm that the DaemonSet on your cluster has config that matches the above?

Thanks for your reply @caseydavenport, nowadays i only see this:
kubectl logs -n kube-system calico-node-rszfd | grep -i BIRD
bird: Unable to open configuration file /etc/calico/confd/config/bird6.cfg: No such file or directory
bird: Unable to open configuration file /etc/calico/confd/config/bird.cfg: No such file or directory
2021-01-26 13:16:26.718 [INFO][48] resource.go 220: Target config /etc/calico/confd/config/bird6_ipam.cfg out of sync
2021-01-26 13:16:26.719 [INFO][48] resource.go 220: Target config /etc/calico/confd/config/bird6_aggr.cfg out of sync
2021-01-26 13:16:26.724 [INFO][48] resource.go 220: Target config /etc/calico/confd/config/bird_ipam.cfg out of sync
2021-01-26 13:16:26.725 [INFO][48] resource.go 220: Target config /etc/calico/confd/config/bird6.cfg out of sync
2021-01-26 13:16:26.725 [INFO][48] resource.go 220: Target config /etc/calico/confd/config/bird.cfg out of sync
2021-01-26 13:16:26.726 [INFO][48] resource.go 220: Target config /etc/calico/confd/config/bird_aggr.cfg out of sync
2021-01-26 13:16:26.945 [INFO][48] resource.go 260: Target config /etc/calico/confd/config/bird.cfg has been updated
2021-01-26 13:16:26.949 [INFO][48] resource.go 260: Target config /etc/calico/confd/config/bird_ipam.cfg has been updated
2021-01-26 13:16:26.950 [INFO][48] resource.go 260: Target config /etc/calico/confd/config/bird6_aggr.cfg has been updated
2021-01-26 13:16:26.951 [INFO][48] resource.go 260: Target config /etc/calico/confd/config/bird_aggr.cfg has been updated
2021-01-26 13:16:26.954 [INFO][48] resource.go 260: Target config /etc/calico/confd/config/bird6.cfg has been updated
2021-01-26 13:16:26.956 [INFO][48] resource.go 260: Target config /etc/calico/confd/config/bird6_ipam.cfg has been updated
bird: device1: Initializing
bird: direct1: Initializing
bird: device1: Starting
bird: device1: Connected to table master
bird: device1: State changed to feed
bird: direct1: Starting
bird: direct1: Connected to table master
bird: direct1: State changed to feed
bird: Graceful restart started
bird: Graceful restart done
bird: Started
bird: device1: State changed to up
bird: direct1: State changed to up
bird: device1: Initializing
bird: direct1: Initializing
bird: Mesh_192_168_31_99: Initializing
bird: Mesh_192_168_31_6: Initializing
bird: device1: Starting
bird: device1: Connected to table master
bird: device1: State changed to feed
bird: direct1: Starting
bird: direct1: Connected to table master
bird: direct1: State changed to feed
bird: Mesh_192_168_31_99: Starting
bird: Mesh_192_168_31_99: State changed to start
bird: Mesh_192_168_31_6: Starting
bird: Mesh_192_168_31_6: State changed to start
bird: Graceful restart started
bird: Started
bird: device1: State changed to up
bird: direct1: State changed to up
bird: Mesh_192_168_31_6: Connected to table master
bird: Mesh_192_168_31_6: State changed to wait
bird: Mesh_192_168_31_99: Connected to table master
bird: Mesh_192_168_31_99: State changed to wait
bird: Next hop address <IP_ADDRESS> resolvable through recursive route for <IP_ADDRESS>/24
bird: Next hop address <IP_ADDRESS> resolvable through recursive route for <IP_ADDRESS>/24
bird: Next hop address <IP_ADDRESS> resolvable through recursive route for <IP_ADDRESS>/24
bird: Graceful restart done
bird: Mesh_192_168_31_99: State changed to feed
bird: Mesh_192_168_31_6: State changed to feed
bird: Next hop address <IP_ADDRESS> resolvable through recursive route for <IP_ADDRESS>/24
bird: Next hop address <IP_ADDRESS> resolvable through recursive route for <IP_ADDRESS>/24
bird: Next hop address <IP_ADDRESS> resolvable through recursive route for <IP_ADDRESS>/24
bird: Mesh_192_168_31_99: State changed to up
bird: Mesh_192_168_31_6: State changed to up
bird: KIF: Received address message for unknown interface 189
bird: KIF: Received address message for unknown interface 193

Related to BIRD ... related to BGP (as BGP and not bgp) i don't have logs (TBH i don't use the cluster in this last 2 weeks) there are some things, related to BIRD that i cannot give you more information 'cause i don't know "when" the things happen, as you see from the previous output. BUT i can tell you that even i haven't log, BGP is UP and RUNNING:

So i guess that the behaviour can be replicated (the log output). Are you have more information:
sh-4.4# netstat -pontelu | grep 179
tcp        0      0 <IP_ADDRESS>:179             <IP_ADDRESS>:*               LISTEN      0          32864741   130/bird             off (0.00/0/0)

sh-4.4# ps aux | grep 130
root       130  0.0  0.0    844   412 ?        S    Jan26   3:04 bird -R -s /var/run/calico/bird.ctl -d -c /etc/calico/confd/config/bird.cfg
root     21694  0.0  0.0   9168   704 pts/1    S+   13:16   0:00 grep 130

sh-4.4# cat /etc/calico/confd/config/bird.cfg | grep -v '#' | grep -v '^$'
include "bird_aggr.cfg";
include "bird_ipam.cfg";
router id <IP_ADDRESS>;
protocol kernel {
  import all;
}
protocol device {
  debug { states };
}
protocol direct {
  debug { states };
}
template bgp bgp_template {
  debug { states };
  description "Connection to BGP peer";
  local as 64512;
  multihop;
  add paths on;
  connect delay time 2;
  connect retry time 5;
  error wait time 5,30;
}
protocol bgp Mesh_192_168_31_99 from bgp_template {
  neighbor <IP_ADDRESS> as 64512;
}
protocol bgp Mesh_192_168_31_6 from bgp_template {
  neighbor <IP_ADDRESS> as 64512;
}
sh-4.4#

I am afraid I still don't understand what the problem is here, if any.

Can you confirm that the DaemonSet on your cluster has config that matches the above?

The fact that BGP is running is only a problem if your DaemonSet is configured to disable BGP. If the DS has BGP enabled, then it is expected. Could you please share the DaemonSet that is running on your cluster so we can confirm that BGP is actually disabled?

The only DaemonSet that i have is "calico-node" which content is (on topic):
        name: calico-node
        readinessProbe:
          exec:
            command:
            - /bin/calico-node
            - -felix-ready
            - -bird-ready

I guess that is necessary to say that i just migrate from flannel to calico with the
So i didn't "tuned in" the services or make something different from the comment that i pasted again.

@telekomancer from that snippet of your calico-node daemonset, bird is enabled since with -bird-ready flag indicates that calico-node won't get to a ready state unless bird is also running.
If you started with a Flannel cluster, and ran our Flannel migration tool, we bring up a VXLAN cluster I believe. I wonder if we disable BGP as part of the migration - @song-jiang would you happen to know?

I downloaded latest calico.yaml from Calico doc.
curl -LO https://docs.projectcalico.org/manifests/flannel-migration/calico.yaml There is no -bird-ready flag on calico-node daemonset.
         livenessProbe:
            exec:
              command:
              - /bin/calico-node
              - -felix-live
            periodSeconds: 10
            initialDelaySeconds: 10
            failureThreshold: 6
          readinessProbe:
            exec:
              command:
              - /bin/calico-node
              - -felix-ready

I'm closing this for now since I think we've identified the issue here - please reopen if you have any questions or open a new issue if you're still having problems, thanks!


Upsert of big JSON throws the error "P1017 Server has closed the connection"

Bug description
Upsert of big JSON throws the error "P1017 Server has closed the connection"
How to reproduce
Run the code snippet described below
Expected behavior
Upsert should be finished successfully
Prisma information
index.js
const {PrismaClient} = require('@prisma/client');

function generateData() {
    const result = {};
    for (let i = 0; i < 10; i++) {
        const l1 = {};
        for (let j = 0; j < 100; j++) {
            const l2 = {};
            for (let k = 0; k < 1000; k++) {
                l2[`key${k}`] = { value: k };
            }
            l1[`key${j}`] = l2;
        }
        result[`key${i}`] = l1;
    }
    return result;
}

// This method throws the error described below
//
// PrismaClientKnownRequestError2 [PrismaClientKnownRequestError]:
// Invalid `prisma.dictionary.upsert()` invocation:
//
//
//   Server has closed the connection.
//     at cb (/save_json_err/node_modules/@prisma/client/runtime/index.js:35098:17)
//     at processTicksAndRejections (internal/process/task_queues.js:93:5)
//     at async main (/save_json_err/index.js:26:9) {
//   code: 'P1017',
//   clientVersion: '2.22.1',
//   meta: null
// }
async function main() {
    const name = 'data';
    const data = generateData();
    const updated = new Date();
    const client = new PrismaClient();
    await client.$connect();
    try {
        await client.dictionary.upsert({
            where: {name},
            create: {
                name,
                data,
                updated,
            },
            update: {
                data,
                updated,
            },
        });
        console.log('Success!');
    } catch (err) {
        console.error(err);
    } finally {
        client.$disconnect();
    }
}

main();

prisma.schema
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model Dictionary {
  name    String   @id
  data    Json
  updated DateTime

  @@map("dictionaries")
}

Environment & setup

OS: macOS Big Sur v11.3.1, Ubuntu 20
Database: PostgreSQL
Node.js version: 14.16.0
Prisma version:

prisma               : 2.22.1
@prisma/client       : 2.22.1
Current platform     : darwin
Query Engine         : query-engine 60cc71d884972ab4e897f0277c4b84383dddaf6c (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli 60cc71d884972ab4e897f0277c4b84383dddaf6c (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core 60cc71d884972ab4e897f0277c4b84383dddaf6c (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt 60cc71d884972ab4e897f0277c4b84383dddaf6c (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : 60cc71d884972ab4e897f0277c4b84383dddaf6c
Studio               : 0.379.0

I am unable to reproduce this, can you please try again with the latest version:
code/reproductions/issue-7074 is 📦 v1.0.0 via  v14.17.0
❯ yarn start
yarn run v1.22.5
$ ts-node main.ts
Success!
Done in 11.58s.

code/reproductions/issue-7074 is 📦 v1.0.0 via  v14.17.0
❯ npx prisma -v
Environment variables loaded from prisma\.env
prisma               : 2.24.0-dev.23
@prisma/client       : 2.24.0-dev.23
Current platform     : windows
Query Engine         : query-engine 5e7f7c52a0792622c1f7f0698634b86ce6aa7fe8 (at<EMAIL_ADDRESS>Migration Engine     : migration-engine-cli 5e7f7c52a0792622c1f7f0698634b86ce6aa7fe8 (at<EMAIL_ADDRESS>Introspection Engine : introspection-core 5e7f7c52a0792622c1f7f0698634b86ce6aa7fe8 (at<EMAIL_ADDRESS>Format Binary        : prisma-fmt 5e7f7c52a0792622c1f7f0698634b86ce6aa7fe8 (at<EMAIL_ADDRESS>Default Engines Hash : 5e7f7c52a0792622c1f7f0698634b86ce6aa7fe8
Studio               : 0.397.0

code/reproductions/issue-7074 is 📦 v1.0.0 via  v14.17.0
❯

Increasing of memory in k8s specs solved this problem.
resources:
    limits:
        memory: 512Mi -> 1024Mi


not found in settings：python.autoComplete.addBrackets

Discussed in https://github.com/microsoft/vscode-python/discussions/18438

Originally posted by mdks2010 February  4, 2022
vscode:  1.64.0
python:  v2022.0.1786462952
Pylance : v2022.2.0
not found in settings：python.autoComplete.addBrackets

Closing so this can be discussed in a single place in Discussions


Prompt does not work for iOS

Hey Martin! I love what you built :) I forked and used your code as kind of like a business card website.
Anyways, I'm having trouble figuring out why I'm not able to type into the prompt on iOS. It works perfect on chrome on mac osx and android. Any ideas on where to start?

Hey @garfbargle - thanks for your kind words and opening up this issue!
Cool website you're building there - so let's try to fix this issue, so you can finally show off!
Alright. I'm not having any iOS devices available, so I'll have to do some guessing, sorry for that in advance...

Which iOS version are you running?
Which browser on iOS have you tried?
Can you do remote debugging and see, if there's any error displayed?
When you say "I'm not able to type into the prompt" - do you mean there's just no input field (or no way to get an input cursor) available or is the text input itself somewhat problematic (but you get an editing cursor) or something else?

I will try to find somebody with an iPhone to test this with - but that can take a while...

Hey @AVGP , haha thank you.

ios 8.1.2 (i think this is probably irrelevant)
i've tried safari and chrome
I'll look into remote debugging now
I'm not able to even place a cursor or tap anywhere that would cause the keyboard to display. It's as if there is no input field.

Hey, thanks for the lightning-fast answers!
The iOS version may matter, as you're hitting the template polyfill as well, so one more potential source of the issue.
The fact that it behaves like there's no input field reminds me of something similar I've seen, I'll see if I can somehow reproduce!
We'll squash this bug together!

@AVGP I didn't think to until now but this problem exists in safari on mac aswell, if you're using windows maybe you could try safari on there?

Here's one difference I'm seeing, the content tags are missing from safari
safari

chrome

That's because Safari is using the Polyfill.
There's two things that may be happening:
1.) The z-index order is wrong in Safari, meaning that the "contenteditable" span (class="input") is covered up by the promt span or
2.) Safari does not support contenteditable="true" (seems implausible, given http://caniuse.com/#feat=contenteditable)

Okay, I'm quite noob when it comes to web. Does that mean you think it can be solved with css?

Perhaps, yes...
Try editing terminal.css like this:
fake-terminal::shadow #terminal .input {
    height:         1em;
    min-width:      1em;
    outline-color:  transparent;
    border:         none;
    display:        inline-block;
}

and add this line
z-index: 10;

like this:
fake-terminal::shadow #terminal .input {
    height:         1em;
    min-width:      1em;
    outline-color:  transparent;
    border:         none;
    display:        inline-block;
    z-index: 10;
}

Thanks for suggestion but it doesn't appear to solve it. :(

Aww shucks.
Is there anything on the error console by chance?
If not, I'll try to find a Safari to test with next week
2015-04-25 21:10 GMT+02:00 garfbargle<EMAIL_ADDRESS>
Thanks for suggestion but it doesn't appear to solve it. :(
—
Reply to this email directly or view it on GitHub
https://github.com/AVGP/fake-terminal/issues/1#issuecomment-96264153.

Nothing in the console. I really appreciate you looking into it! Thanks Martin.

Shucks, would've been lovely if it would log something.
Well, I'm very grateful for you taking the time to debug this with me. I
want this thing to be useful for people... with this it isn't, so I need to
fix it! We'll crush that bug ;-)
2015-04-25 21:22 GMT+02:00 garfbargle<EMAIL_ADDRESS>
Nothing in the console. I really appreciate you looking into it! Thanks
Martin.
—
Reply to this email directly or view it on GitHub
https://github.com/AVGP/fake-terminal/issues/1#issuecomment-96266533.

Still haven't been able to solve this :(

Right, let's see if I can carve out some time soon to give this another go.
It's hard for me, as I'm not having any iOS devices available, so testing is a bit of a nightmare

Nevermind! I figured if I get a browser that doesn't support Shadow DOM natively (such as Firefox) I'm running in the same problem - that's bad (as it's a problem with using the polyfill) and good (as I can test & fix this bummer)

I have tested it and found some issues with CSS and async upgrades when the polyfill is used.
It works in Firefox now, so it should work in Safari as well.
Nota bene: The .input span doesn't get focused in Firefox and so it's a little hard to use the terminal right now, as the width of that element is 1em. Not sure what to do about that right now, tho

Hey AVGP, thanks for looking into it again! I'm really unsure of the issue but it felt as if I just wasn't able to tap the area to begin typing when using iOS. Maybe that is the case and caused by the small width? Was there any code changes?

Ah okay, http://avgp.github.io/fake-terminal/index.html now works on safari on desktop and mobile to type. Unfortunately, the commands don't work on mobile! I couldn't do anything to figure out how to enable input! haha, but this is good I can dig into it and see if I can figure this part out.

 :(

Hey I see this is like a year old thread, but I've been messing with this and encountered the same issue in safair on osx 10.10.5. I'll be sure to post if I come up with a fix.


Bump QEMU to 8.0.3

Have you tested this change?

No, I haven't

Thanks.

Available now in https://github.com/cross-platform-actions/action/releases/tag/v0.17.0.


[redis] Add inital pod to configure system

Is this a request for help?:
no
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
feature request

Version of Helm and Kubernetes:
2.6 & 1.7
Which chart:
redis
What happened:
After install this is in logs:
WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled

What you expected to happen:
Redis chart should have an InitContainer to prepare system for deploy
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:

I would like to reopen this bug.
@prydonius @tompizmor @sameersbn @carrodher @juan131 would you consider merging a PR with an initContainer in privileged mode that does this? If so it can easily be done.

/reopen

@prydonius @tompizmor @sameersbn @carrodher @juan131 can you take a look to this issue ? i just installed the chart and it's still hapenning


Add breezy-hr map for ListJobs use case

Description

This PR adds breezy-hr map for ListJobs use case.
Motivation and Context

The PR is based on feature/add-ats-list-jobs-use-case-with-mock-map but will be merged into feature/add-ats-job-board-demo-use-cases once the base branch is merged.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have read the CONTRIBUTING document.
[x] I haven't repeated the code. (DRY)
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

@janhalama is base branch main intentionally?

@janhalama is base branch main intentionally?

No sorry, I am going to fix it.

@janhalama is base branch main intentionally?

No sorry, I am going to fix it.

@martinalbert  Done. You can review the code.


Making cluster delete exit flow similar to other XPK commands.

Fixes / Features

Making cluster delete exit flow similar to other XPK commands, to use in Pathways integration tests.

Testing / Documentation
Testing details.

[ y/n ] Tests pass
[ y/n ] Appropriate changes to documentation are included in the PR

Thanks for the change!
I agree we should make the major functions ( subcommand functions like xpk cluster [create / delete / list], xpk workload [xxx, yyy, zzz]) remove the return value from them do you want to do that in this PR as well?

Sure, done!


Gurobi does not report any solver time with a simple LP in 1.0.28

Describe the bug
Gurobi does not report any timing when solving LPs with cvxpy>1.0.28. This is because cvxpy defaults to its conic interface which does not save any SOLVER_TIME.
To Reproduce
import cvxpy as cp
import numpy as np

# Problem data.
m = 30
n = 20
np.random.seed(1)
A = np.random.randn(m, n)
b = np.random.randn(m)

# Construct the problem.
x = cp.Variable(n)
objective = cp.Minimize(cp.norm(A*x - b, 1))
constraints = [0 <= x, x <= 1]
prob = cp.Problem(objective, constraints)
prob.solve(solver=cp.GUROBI)
prob.solver_stats.solve_time

Expected behavior
It should print the solver time
Version

OS: Mac OSX
CVXPY Version: 1.0.28

I met the same problem. May I know if it has been solved? Thanks.

Fixed on master.

Fixed on master.

Thanks~


proposed changes

Description
[ What changed? Feel free to be brief. ]
Checklist

[ ] The base branch of this PR is preview, rather than main

@guilhermecgs you should make branches off of preview branch implement changes then open a pr into preview.


Cleanup BitVector640 and remove incorrect comments

Performance improvements:

Method
Job
Runtime
Mean
Error
StdDev

Write Before
.NET 6.0
.NET 6.0
1,119.6 ns
13.44 ns
12.57 ns

Write After
.NET 6.0
.NET 6.0
899.3 ns
6.61 ns
6.18 ns

If you are interested in working in this space, it would be good to get alignment across this type and Azure.Core's StatusCodeClassifier

Which comments were incorrect?

Which comments were incorrect?

// Keeping ulongs as fields puts them on the stack.


[BUG] failed to calculate node topology

What happened:
#kubectl describe pod XXX
Events:
Type     Reason            Age   From             Message
Warning  FailedScheduling  23s   koord-scheduler  0/5 nodes are available: 2 node(s) invalid CPU Topology, 3 node(s) had taint {dedicated: master}, that the pod didn't tolerate.
#kubectl logs koordlet-2zx2f -nkoordinator-system
I0410 14:25:26.458142   11700 states_noderesourcetopology.go:295] start to report node topology
E0410 14:25:26.463152   11700 states_noderesourcetopology.go:306] failed to calculate node topology, err: failed to GetKubeletConfiguration, err: request http://xx.xx.xx.xx:10255/configz failed, code 404
How to solve 404？
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

App version: v1.1.1
Kubernetes version (use kubectl version): v1.21.3
Install details (e.g. helm install args):  - --kubelet-insecure-tls=true
Node environment (for koordlet/runtime-proxy issue):

Containerd/Docker version:
OS version:
Kernal version:
Cgroup driver: cgroupfs/systemd

Others:

It seems the kubelet config is not exported at :10255/configz. However, it is not required. Please try to add the -disable-query-kubelet-config=true in the args of the koordlet DaemonSet.

Thanks, I have got it.


Sync from master

Codecov Report

Merging #188 (9910bce) into dev (8d99470) will increase coverage by 0.25%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev     #188      +/-   ##
============================================
+ Coverage     24.83%   25.09%   +0.25%
  Complexity      233      233
============================================
  Files            65       65
  Lines          4413     4360      -53
  Branches        335      330       -5
============================================
- Hits           1096     1094       -2
+ Misses         3214     3163      -51
  Partials        103      103

Impacted Files
Coverage Δ

...nk/wecross/stub/bcos/contract/FunctionUtility.java
64.56% <0.00%> (-0.55%)
:arrow_down:

...ank/wecross/stub/bcos/preparation/HubContract.java
0.00% <0.00%> (ø)

...k/wecross/stub/bcos/preparation/ProxyContract.java
0.00% <0.00%> (ø)

...ub/bcos/performance/hellowecross/HelloWeCross.java
0.00% <0.00%> (ø)

...bcos/performance/hellowecross/PerformanceTest.java
0.00% <0.00%> (ø)

...s/performance/hellowecross/proxy/WeCrossProxy.java
0.00% <0.00%> (ø)

...erformance/hellowecross/proxy/PerformanceTest.java
0.00% <0.00%> (ø)

.../java/com/webank/wecross/stub/bcos/BCOSDriver.java
21.87% <0.00%> (+0.06%)
:arrow_up:

...k/wecross/stub/bcos/web3j/Web3jWrapperFactory.java
6.89% <0.00%> (+0.22%)
:arrow_up:

.../webank/wecross/stub/bcos/BCOSBaseStubFactory.java
27.77% <0.00%> (+0.43%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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


Animas bug fix: Some uploads stalling at 40%

During alpha testing some uploads are stalling at 40%. This is caused by an uncaught error where we are trying to parse a duplicate (empty) packet. This PR:

makes sure we catch these errors and return them in the UI
checks for duplicate packets across different requests, not only in each request

Self-merging, as it's not going into master yet.


Data Category Visualization endpoint isn't working

Bug Description
going to something like http://localhost:8080/data_category/visualize/graphs returns a 500, and the textual representation is also incorrect
Steps to Reproduce

Start the webserver
Go to http://localhost:8080/data_category/visualize/graphs

Expected behavior
Showing the graphs without a 500
Screenshots
If applicable, add screenshots to help explain your problem.
Environment

Version:
OS:
Python Version:
Docker Version:

Additional context
This seems to be caused by the parser incorrectly parsing things, as in the textual representation one can see that the top-level fields are not all correct.
update
after some more investigation, it appears that resetting the db fixes the issue. It seems to be related to repeatedly upserting the resources into the database. That being said the primary bug is still most likely in the visualize parsing logic that is expecting things to be in a certain order or something of that nature

this might actually get fixed by #350 , as it changes how the upsert behaviour works

this endpoint no longer exists


Oracle Database support in Rubrik SDK for PowerShell

Description
@DamaniN requested support for Oracle DBs in the Rubrik PowerShell Module
Related Issue
#255
Motivation and Context
It add additional functionality
How Has This Been Tested?
Ran this against the TME Lab Cluster 5.0.0
Screenshots (if appropriate):
Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:
Go over all the following points, and put an x in all the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTION document.
[x] I have updated the CHANGELOG file accordingly for the version that this merge modifies.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

No review required as of yet, I put the PR up so @DamaniN can review the code and report his findings. Additional tests will be added as well


CI for SYCL (2)

Continued from PR #74, which made source code updates to support Intel's oneAPI SYCL compiler.

Adds necessary compiler flags to Makefile and CMake script for SYCL and OpenMP offload, and suppresses some extraneous warnings that Intel's compiler generates.
Add SYCL to CI scripts. OpenMP offload compiles but will not run on our Intel GPU, so it checks only compilation; all the tests are disabled.

Compiling on sunspot, I see a number of warning messages for each Fortran files.
Removing ALL 3 warning flags "-Wno-unused-command-line-argument -Wno-c99-extensions -Wno-pass-failed" cleans up these messages.  Just removing one of the flags is not sufficient.
[ 77%] Building Fortran object CMakeFiles/slate.dir/src/zsteqr2.f.o
soft/restricted/CNDA/updates/2<IP_ADDRESS>/oneapi/compiler/eng-20230512/compiler/linux/bin/ifx -DSLATE_ID=\"21ac470e\"   ....-Dslate_EXPORTS -I/home/yarkhan/ic\
l/slate/include -I/home/yarkhan/icl/slate/src -I/home/yarkhan/icl/slate/build/blaspp/include -I/home/yarkhan/icl/slate/blaspp/include -I/home/yarkhan/icl/s\
late/build/lapackpp/include -I/home/yarkhan/icl/slate/lapackpp/include -isystem /soft/restricted/CNDA/updates/mpich/51.2/mpich-ofi-all-icc-default-pmix-gpu\
-drop51/include -fPIC -fp-model=precise -Wno-unused-command-line-argument -Wno-c99-extensions -Wno-pass-failed -fopenmp-targets=spir64 -fsycl -c /home/yark\
han/icl/slate/src/zsteqr2.f -o CMakeFiles/slate.dir/src/zsteqr2.f.o
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type
ifx: command line warning #10157: ignoring option '-W'; argument is of wrong type

On sunspot, some unit_tests have errors.
Details in the SLATE meeting notes.
gh pr checkout 86
( cd ./unit_test/; env ZE_AFFINITY_MASK=0.0 OMP_NUM_THREADS=8 ./run_tests.py )
3 unit tests FAILED: test_Memory, test_Tile_kernels, test_geset

The gemm, potrf routines work in a 4 process execution (gpu/process).
env OMP_NUM_THREADS=7 mpiexec -np 4 -ppn 12 -d 16 --cpu-bind depth -envall ./wrapper.sh  ./tester  --origin d --target d --check y --ref y --type d --lookahead 1 --nb 1024 --dim 8000:20000:1000  gemm
LU and QR fail with numerical errors.

The code changes look fine.
Just waiting to see if there are any changes to reduce the warning from Fortran compilation.

Using a CMake generator expression fixes Fortran -W issue.

PR 86 builds without warnings on sunspot.


[2024-01-22_11:53:11:664][INFO] [MQTT] [core_mqtt.c:1563] Received MQTT CONNACK successfully from broker.
[2024-01-22_11:53:11:664][INFO] [MQTT] [core_mqtt.c:1829] MQTT connection established with the broker.
[2024-01-22_11:53:11:686]An MQTT connection is established with nimazureiothub.azure-devices.net
[2024-01-22_11:53:11:686]Attempting to subscribe to the MQTT topic: $iothub/methods/POST/#
[2024-01-22_11:53:11:686][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 27 is 1 bytes.
[2024-01-22_11:53:11:709][DEBUG] [MQTT] [core_mqtt_serializer.c:1073] Subscription packet remaining length=27 and packet size=29.
[2024-01-22_11:53:11:709][DEBUG] [MQTT] [core_mqtt.c:1868] SUBSCRIBE packet size is 29 and remaining length is 27.
[2024-01-22_11:53:11:709][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 27 is 1 bytes.
[2024-01-22_11:53:11:727][DEBUG] [MQTT] [core_mqtt_serializer.c:1742] Length of serialized SUBSCRIBE packet is 29.
[2024-01-22_11:53:11:727]    ATParser:*** SEND (size=15) ***
[2024-01-22_11:53:11:727]AT+QISEND=1,85
[2024-01-22_11:53:11:745]
[2024-01-22_11:53:11:745]
[2024-01-22_11:53:11:745]    >
[2024-01-22_11:53:11:745]BG96: SOCKET PROMPT RECEIVED
[2024-01-22_11:53:11:745]        ATParser:*** SEND (size=85) ***
[2024-01-22_11:53:11:745]ATParser: Big frame (display deactivated)
[2024-01-22_11:53:11:774]
[2024-01-22_11:53:11:774]
[2024-01-22_11:53:11:774]    SEND OK
[2024-01-22_11:53:11:774]ComLib: snd data ok
[2024-01-22_11:53:11:774][DEBUG] [MQTT] [core_mqtt.c:643] BytesSent=29, BytesRemaining=0
[2024-01-22_11:53:11:774][DEBUG] [MQTT] [core_mqtt.c:665] Successfully sent packet at time 18289.
[2024-01-22_11:53:11:774][DEBUG] [MQTT] [core_mqtt.c:1897] Sent 29 bytes of SUBSCRIBE packet.
[2024-01-22_11:53:11:801]Waiting for sub ack id: 1
[2024-01-22_11:53:11:801]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:11:801]AT+QIRD=1,0
[2024-01-22_11:53:11:801]
[2024-01-22_11:53:11:801]    +QIRD: 3684,3684,0
[2024-01-22_11:53:11:801]BG96:+QIRD: total_receive_length = 3684
[2024-01-22_11:53:11:801]BG96:+QIRD: have_read_length = 3684
[2024-01-22_11:53:11:801]BG96:+QIRD: unread_length = 0
[2024-01-22_11:53:11:801]
[2024-01-22_11:53:11:821]    OK
[2024-01-22_11:53:11:821]    CS:Size of data received on the socket= 0 bytes
[2024-01-22_11:53:11:855]
[2024-01-22_11:53:11:855]
[2024-01-22_11:53:11:855]    +QIURC: "recv",1
[2024-01-22_11:53:11:855]ComLib: cb socket 0 data ready called: waiting
[2024-01-22_11:53:11:855]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:11:855]AT+QIRD=1,0
[2024-01-22_11:53:11:880]
[2024-01-22_11:53:11:880]
[2024-01-22_11:53:11:880]    +QIRD: 3753,3684,69
[2024-01-22_11:53:11:880]BG96:+QIRD: total_receive_length = 3753
[2024-01-22_11:53:11:880]BG96:+QIRD: have_read_length = 3684
[2024-01-22_11:53:11:880]BG96:+QIRD: unread_length = 69
[2024-01-22_11:53:11:880]BG96:Limit request to maximum buffer size (5) whereas more data are available (69)
[2024-01-22_11:53:11:880]
[2024-01-22_11:53:11:880]    OK
[2024-01-22_11:53:11:908]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:11:908]AT+QIRD=1,5
[2024-01-22_11:53:11:908]
[2024-01-22_11:53:11:908]    +QIRD: 5
[2024-01-22_11:53:11:908]BG96:+QIRD: received data size = 5
[2024-01-22_11:53:11:908]    @
[2024-01-22_11:53:11:908]
[2024-01-22_11:53:11:908]    OK
[2024-01-22_11:53:11:908]CS:Size of data received on the socket= 5 bytes
[2024-01-22_11:53:11:935]ComLib: rcv data exit with data
[2024-01-22_11:53:11:935]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:11:935]AT+QIRD=1,0
[2024-01-22_11:53:11:935]
[2024-01-22_11:53:11:935]    +QIRD: 3753,3689,64
[2024-01-22_11:53:11:935]BG96:+QIRD: total_receive_length = 3753
[2024-01-22_11:53:11:935]BG96:+QIRD: have_read_length = 3689
[2024-01-22_11:53:11:935]BG96:+QIRD: unread_length = 64
[2024-01-22_11:53:11:935]
[2024-01-22_11:53:11:962]    OK
[2024-01-22_11:53:11:962]    ATParser:*** SEND (size=13) ***
[2024-01-22_11:53:11:962]AT+QIRD=1,64
[2024-01-22_11:53:11:962]
[2024-01-22_11:53:11:962]    +QIRD: 64
[2024-01-22_11:53:11:962]BG96:+QIRD: received data size = 64
[2024-01-22_11:53:11:962]    U34K/54-&eKef]TW/:!69jce=Wl6
[2024-01-22_11:53:11:985]
[2024-01-22_11:53:11:985]    OK
[2024-01-22_11:53:11:985]CS:Size of data received on the socket= 64 bytes
[2024-01-22_11:53:11:985]ComLib: rcv data exit data available or err low level
[2024-01-22_11:53:12:008]
[2024-01-22_11:53:12:008][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 3 is 1 bytes.
[2024-01-22_11:53:12:008][DEBUG] [MQTT] [core_mqtt.c:767] BytesReceived=3, BytesRemaining=0, TotalBytesReceived=3.
[2024-01-22_11:53:12:008][INFO] [MQTT] [core_mqtt.c:885] Packet received. ReceivedBytes=3.
[2024-01-22_11:53:12:008][DEBUG] [MQTT] [core_mqtt.c:1230] Received packet of type 90.
[2024-01-22_11:53:12:031][DEBUG] [MQTT] [core_mqtt_serializer.c:1164] Packet identifier 1.
[2024-01-22_11:53:12:031][DEBUG] [MQTT] [core_mqtt_serializer.c:1104] Topic filter 0 accepted, max QoS 0.
[2024-01-22_11:53:12:031]Suback receive context found: 0x00000001
[2024-01-22_11:53:12:031]Done waiting for sub ack id: 1, result: 0x00000000
[2024-01-22_11:53:12:054]Attempting to subscribe to the MQTT topics: $iothub/twin/res/# and $iothub/twin/PATCH/properties/desired/#
[2024-01-22_11:53:12:054][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 65 is 1 bytes.
[2024-01-22_11:53:12:054][DEBUG] [MQTT] [core_mqtt_serializer.c:1073] Subscription packet remaining length=65 and packet size=67.
[2024-01-22_11:53:12:076][DEBUG] [MQTT] [core_mqtt.c:1868] SUBSCRIBE packet size is 67 and remaining length is 65.
[2024-01-22_11:53:12:076][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 65 is 1 bytes.
[2024-01-22_11:53:12:076][DEBUG] [MQTT] [core_mqtt_serializer.c:1742] Length of serialized SUBSCRIBE packet is 67.
[2024-01-22_11:53:12:094]    ATParser:*** SEND (size=16) ***
[2024-01-22_11:53:12:094]AT+QISEND=1,133
[2024-01-22_11:53:12:109]
[2024-01-22_11:53:12:109]
[2024-01-22_11:53:12:109]    >
[2024-01-22_11:53:12:109]BG96: SOCKET PROMPT RECEIVED
[2024-01-22_11:53:12:109]        ATParser:*** SEND (size=133) ***
[2024-01-22_11:53:12:109]ATParser: Big frame (display deactivated)
[2024-01-22_11:53:12:143]
[2024-01-22_11:53:12:143]
[2024-01-22_11:53:12:143]    SEND OK
[2024-01-22_11:53:12:143]ComLib: snd data ok
[2024-01-22_11:53:12:143][DEBUG] [MQTT] [core_mqtt.c:643] BytesSent=67, BytesRemaining=0
[2024-01-22_11:53:12:143][DEBUG] [MQTT] [core_mqtt.c:665] Successfully sent packet at time 18661.
[2024-01-22_11:53:12:143][DEBUG] [MQTT] [core_mqtt.c:1897] Sent 67 bytes of SUBSCRIBE packet.
[2024-01-22_11:53:12:170]Waiting for sub ack id: 2
[2024-01-22_11:53:12:170]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:12:170]AT+QIRD=1,0
[2024-01-22_11:53:12:170]
[2024-01-22_11:53:12:170]    +QIRD: 3753,3753,0
[2024-01-22_11:53:12:170]BG96:+QIRD: total_receive_length = 3753
[2024-01-22_11:53:12:170]BG96:+QIRD: have_read_length = 3753
[2024-01-22_11:53:12:170]BG96:+QIRD: unread_length = 0
[2024-01-22_11:53:12:170]
[2024-01-22_11:53:12:190]    OK
[2024-01-22_11:53:12:190]    CS:Size of data received on the socket= 0 bytes
[2024-01-22_11:53:12:246]
[2024-01-22_11:53:12:246]
[2024-01-22_11:53:12:246]    +QIURC: "recv",1
[2024-01-22_11:53:12:246]ComLib: cb socket 0 data ready called: waiting
[2024-01-22_11:53:12:246]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:12:246]AT+QIRD=1,0
[2024-01-22_11:53:12:246]
[2024-01-22_11:53:12:246]    +QIRD: 3822,3753,69
[2024-01-22_11:53:12:246]BG96:+QIRD: total_receive_length = 3822
[2024-01-22_11:53:12:246]BG96:+QIRD: have_read_length = 3753
[2024-01-22_11:53:12:266]BG96:+QIRD: unread_length = 69
[2024-01-22_11:53:12:266]BG96:Limit request to maximum buffer size (5) whereas more data are available (69)
[2024-01-22_11:53:12:266]
[2024-01-22_11:53:12:266]    OK
[2024-01-22_11:53:12:266]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:12:291]AT+QIRD=1,5
[2024-01-22_11:53:12:291]
[2024-01-22_11:53:12:291]    +QIRD: 5
[2024-01-22_11:53:12:291]BG96:+QIRD: received data size = 5
[2024-01-22_11:53:12:291]    @
[2024-01-22_11:53:12:291]
[2024-01-22_11:53:12:291]    OK
[2024-01-22_11:53:12:291]CS:Size of data received on the socket= 5 bytes
[2024-01-22_11:53:12:291]ComLib: rcv data exit with data
[2024-01-22_11:53:12:291]    ATParser:*** SEND (size=12) ***
[2024-01-22_11:53:12:319]AT+QIRD=1,0
[2024-01-22_11:53:12:319]
[2024-01-22_11:53:12:319]    +QIRD: 3822,3758,64
[2024-01-22_11:53:12:319]BG96:+QIRD: total_receive_length = 3822
[2024-01-22_11:53:12:319]BG96:+QIRD: have_read_length = 3758
[2024-01-22_11:53:12:319]BG96:+QIRD: unread_length = 64
[2024-01-22_11:53:12:319]
[2024-01-22_11:53:12:319]    OK
[2024-01-22_11:53:12:319]    ATParser:*** SEND (size=13) ***
[2024-01-22_11:53:12:346]AT+QIRD=1,64
[2024-01-22_11:53:12:346]
[2024-01-22_11:53:12:346]    +QIRD: 64
[2024-01-22_11:53:12:346]BG96:+QIRD: received data size = 64
[2024-01-22_11:53:12:346]    4SD%q5f!%t&qD4'u^L`
[2024-01-22_11:53:12:367]
[2024-01-22_11:53:12:367]    OK
[2024-01-22_11:53:12:367]CS:Size of data received on the socket= 64 bytes
[2024-01-22_11:53:12:367]ComLib: rcv data exit data available or err low level
[2024-01-22_11:53:12:390]
[2024-01-22_11:53:12:390][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 4 is 1 bytes.
[2024-01-22_11:53:12:390][DEBUG] [MQTT] [core_mqtt.c:767] BytesReceived=4, BytesRemaining=0, TotalBytesReceived=4.
[2024-01-22_11:53:12:390][INFO] [MQTT] [core_mqtt.c:885] Packet received. ReceivedBytes=4.
[2024-01-22_11:53:12:390][DEBUG] [MQTT] [core_mqtt.c:1230] Received packet of type 90.
[2024-01-22_11:53:12:413][DEBUG] [MQTT] [core_mqtt_serializer.c:1164] Packet identifier 2.
[2024-01-22_11:53:12:413][DEBUG] [MQTT] [core_mqtt_serializer.c:1104] Topic filter 0 accepted, max QoS 0.
[2024-01-22_11:53:12:413][DEBUG] [MQTT] [core_mqtt_serializer.c:1104] Topic filter 1 accepted, max QoS 0.
[2024-01-22_11:53:12:436]Suback receive context found: 0x00000002
[2024-01-22_11:53:12:436]Done waiting for sub ack id: 2, result: 0x00000000
[2024-01-22_11:53:12:436][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 395 is 2 bytes.
[2024-01-22_11:53:12:436][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 395 is 2 bytes.
[2024-01-22_11:53:12:459][DEBUG] [MQTT] [core_mqtt_serializer.c:606] PUBLISH packet remaining length=395 and packet size=398.
[2024-01-22_11:53:12:459][DEBUG] [MQTT] [core_mqtt.c:1632] PUBLISH packet size is 398 and remaining length is 395.
[2024-01-22_11:53:12:459][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 395 is 2 bytes.
[2024-01-22_11:53:12:478][DEBUG] [MQTT] [core_mqtt.c:1643] Serialized PUBLISH header size is 51.
[2024-01-22_11:53:12:478]    ATParser:*** SEND (size=16) ***
[2024-01-22_11:53:12:478]AT+QISEND=1,117
[2024-01-22_11:53:12:495]
[2024-01-22_11:53:12:495]
[2024-01-22_11:53:12:495]    >
[2024-01-22_11:53:12:495]BG96: SOCKET PROMPT RECEIVED
[2024-01-22_11:53:12:495]        ATParser:*** SEND (size=117) ***
[2024-01-22_11:53:12:495]ATParser: Big frame (display deactivated)
[2024-01-22_11:53:12:526]
[2024-01-22_11:53:12:526]
[2024-01-22_11:53:12:526]    SEND OK
[2024-01-22_11:53:12:526]ComLib: snd data ok
[2024-01-22_11:53:12:526][DEBUG] [MQTT] [core_mqtt.c:643] BytesSent=51, BytesRemaining=0
[2024-01-22_11:53:12:526][DEBUG] [MQTT] [core_mqtt.c:665] Successfully sent packet at time 19048.
[2024-01-22_11:53:12:526][DEBUG] [MQTT] [core_mqtt.c:1419] Sent 51 bytes of PUBLISH header.
[2024-01-22_11:53:12:553]    ATParser:*** SEND (size=16) ***
[2024-01-22_11:53:12:553]AT+QISEND=1,405
[2024-01-22_11:53:12:553]
[2024-01-22_11:53:12:553]    >
[2024-01-22_11:53:12:553]BG96: SOCKET PROMPT RECEIVED
[2024-01-22_11:53:12:553]        ATParser:*** SEND (size=405) ***
[2024-01-22_11:53:12:553]ATParser: Big frame (display deactivated)
[2024-01-22_11:53:12:611]
[2024-01-22_11:53:12:611]
[2024-01-22_11:53:12:611]    SEND OK
[2024-01-22_11:53:12:611]ComLib: snd data ok
[2024-01-22_11:53:12:611][DEBUG] [MQTT] [core_mqtt.c:643] BytesSent=347, BytesRemaining=0
[2024-01-22_11:53:12:611][DEBUG] [MQTT] [core_mqtt.c:665] Successfully sent packet at time 19132.
[2024-01-22_11:53:12:611][DEBUG] [MQTT] [core_mqtt.c:1437] Sent 347 bytes of PUBLISH payload.
[2024-01-22_11:53:19:937][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 26 is 1 bytes.
[2024-01-22_11:53:19:937][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 26 is 1 bytes.
[2024-01-22_11:53:19:937][DEBUG] [MQTT] [core_mqtt_serializer.c:606] PUBLISH packet remaining length=26 and packet size=28.
[2024-01-22_11:53:19:960][DEBUG] [MQTT] [core_mqtt.c:1632] PUBLISH packet size is 28 and remaining length is 26.
[2024-01-22_11:53:19:960][DEBUG] [MQTT] [core_mqtt_serializer.c:457] Encoded size for length 26 is 1 bytes.
[2024-01-22_11:53:19:960][DEBUG] [MQTT] [core_mqtt.c:1643] Serialized PUBLISH header size is 28.
[2024-01-22_11:53:19:969]    ATParser:*** SEND (size=15) ***
[2024-01-22_11:53:19:969]AT+QISEND=1,85
[2024-01-22_11:53:19:986]
[2024-01-22_11:53:19:986]
[2024-01-22_11:53:19:986]    >
[2024-01-22_11:53:19:986]BG96: SOCKET PROMPT RECEIVED
[2024-01-22_11:53:19:986]        ATParser:*** SEND (size=85) ***
[2024-01-22_11:53:19:986]ATParser: Big frame (display deactivated)
[2024-01-22_11:53:20:016]
[2024-01-22_11:53:20:016]
[2024-01-22_11:53:20:016]    SEND OK
[2024-01-22_11:53:20:016]ComLib: snd data ok
[2024-01-22_11:53:20:016][DEBUG] [MQTT] [core_mqtt.c:643] BytesSent=28, BytesRemaining=0
[2024-01-22_11:53:20:016][DEBUG] [MQTT] [core_mqtt.c:665] Successfully sent packet at time 19236.
[2024-01-22_11:53:20:016][DEBUG] [MQTT] [core_mqtt.c:1419] Sent 28 bytes of PUBLISH header.
[2024-01-22_11:53:22:164][DEBUG] [MQTT] [core_mqtt.c:1443] PUBLISH payload was not sent. Payload length was zero.
_

Why I am not receiving the device twin notification, because of "AzureIoTHubClient_ProcessLoop" function.
If there is an update notification present from Azure IoT hub then the  "AzureIoTHubClient_ProcessLoop"  function  gives device twin notification, when there is no notification from Azure IoT Hub then it will throw below error

and another error is

because of above two error I have removed the  "AzureIoTHubClient_ProcessLoop"  function from my code.
these two errors are reproduce constantly.


Mule

Mule module and updated sample

Tony, if you look at https://github.com/swagger-api/swagger-core/pull/973/files#diff-6b04f0da967ddc159fc20e0c415942bfR47 and let me know if you'd like me to cut one of the config types, or add some code to prefer one over the other but try both, ill add that to the PR


Typo on Homepage: https://immerjs.github.io/immer/docs/introduction#quick-example

There's a typo on https://immerjs.github.io/immer/docs/introduction#quick-example

**but the nextState will a new immutable tree **
will what a new immutable tree?

@adebiyial, I assume there should be:
but the nextState will **be** a new immutable tree

Don't be afraid to PR folks, it's just an edit button away and looks good on your profile :)

I was just about doing that, but it's been fixed. 😟

The best result😅
Op wo 25 sep. 2019 08:57 schreef Adebiyi Adedotun<EMAIL_ADDRESS>
:

Closed #427 https://github.com/immerjs/immer/issues/427.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/issues/427?email_source=notifications&email_token=AAN4NBDPHZ3LAIZQLJXXZDLQLMKVVA5CNFSM4IXJSXMKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOT2LJVKY#event-2660670123,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBCO3RQONW4VRWMJB5TQLMKVVANCNFSM4IXJSXMA
.


Update to work with hmatrix <IP_ADDRESS> and ghc 8.2.1

Would you mind looking this over? I know you don't maintain this any more but I'm specifically not sure I always used the right transpose function. I used tr' everywhere you used trans, I think that should be right. There's only one place I used tr instead of tr', and that's when we're checking that a matrix is Hermitian to use eigSH'.
Do you think the tests would catch out issues like these? Are they reasonably complete? I refactored them but I have not looked at what they actually do. Thanks.

I think the changes look good. I would prefer to just use tr (not tr') everywhere, even though the library assumes only real-valued matrices. In some sense, the non-conjugate transpose is the much more specialized operation, and the conjugate transpose is more general.

As for the tests, if they build and pass, that's good enough for me. Did you try running the demo? I would expect that to produce the same results as before. I'll try out the changes sometime this week.

Thanks for contributing this, by the way!

The tests pass. I haven't tried the demo yet. I'll try it soon.
It seems tr' does less work than tr (correct me if I'm wrong) so if we assume real matrices we should probably be using that, right?
YW about the PR :) I'm also an uploader on hackage, is it ok if i upload hvx at some point?
When trying this make sure to use hmatrix from git. You'll have to add hmatrix/packages/base as a source to your cabal sandbox.

(the version of hmatrix on hackage does not compile with ghc 8.2.1)

Re: tr vs tr', for real matrices they should do exactly the same amount of work. By real matrices I mean that the element representation is literally only a Double, not a complex type, so it's not possible for there to be more work done. If/when complex numbers get involved, it will be more correct to have tr, so no reason not to do it now.

Feel free to upload to hackage if you like. If you do though, shouldn't you constrain the GHC version to one where the hmatrix version on hackage will work?

not sure how that works, i think this situation is in the hmatrix maintainer's hands

I have refactored the demo code and made it executable via cabal run.

I haven't fixed compiler warnings on the executables. I am not sure it's worth it, i guess the main concern is for the code to be readable.

Looks good except for using tr' still. When writing this originally I think I assumed trans was the conjugate transpose, because that's what you learn is the more natural way to think about Hermitian matrices, etc.

Just changed this

sorry, missed that one, changed it now

Thanks!


Merge BlockBodyTxExt trait into BlockBody

Describe the feature
this extension trait is required because it makes use of rayon functions
https://github.com/paradigmxyz/reth/blob/c0a8a7b218f8388efd1f04318dbe933343dd42bc/crates/primitives/src/traits.rs#L92-L92
ref #13552
instead of the approach in #13552 we should feature gate this rayon usage and move to reth-primitives-traits
TODO

move BlockBodyTxExt functions into BlockBody
feature gate rayon for https://github.com/paradigmxyz/reth/blob/c0a8a7b218f8388efd1f04318dbe933343dd42bc/crates/primitives/src/transaction/mod.rs#L1899-L1915

Additional context
No response

hi, i can do it

cool, we def need a rayon feature in reth-primitives-traits
also relevant:
https://github.com/paradigmxyz/reth/pull/13552#discussion_r1897180486
because we want feature gated functions


Fixes Pbs issues #175 and #177

#175 eliminates duplicated trailing ts segments from video.pbs.org
#177 Adds high definition video download from pbs.org

Thanks for the update.


OTEL plugin: http_export_request only accepts 200 responses

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
Kong <IP_ADDRESS>
Current Behavior
http_export_request only accepts 200 as a valid response status. When working with external services, some OTLP data receivers return other >200 status codes as OK (e.g 202). Is there any reason not to accept this? https://github.com/Kong/kong/blob/4c772c6bf83dead3255d18e4d03b32d71aea64f7/kong/plugins/opentelemetry/utils.lua#L28-L29
Expected Behavior
When an external service responds with a valid (>200 && <300) error when receiving OTLP data, no error log should appear.
Steps To Reproduce
No response
Anything else?
No response

I think this is the behavior defined in the OTLP HTTP Protocol:

On success, the server MUST respond with HTTP 200 OK.

If the request is only partially accepted (i.e. when the server accepts only parts of the data and rejects the rest), the server MUST respond with HTTP 200 OK. The response body MUST be the same ExportServiceResponse message as in the Full Success case.


migration to mkstemp and TMP env var

@aphelionz I have tested this in my local environment, however, when creating resources, the temp file is still created in /tmp directory other than /hs_tmp directory. I did try to get 'tempfile.gettempdir()" python command and it does output /hs_tmp, so the TMP environment variable you put in seems to take effect. Does Django upload file module have its own tmp directory setting for specifying temp directory for holding uploaded files temporarily? @pkdash Can you also test it just to make sure you observe same behavior as me?

@aphelionz @pkdash Also, just noticed there are a lot of test failures due to the changes introduced.

@pkdash @hyi Yes, I missed a commit - FILE_UPLOAD_TEMP_DIR in the settings.py. Let's see if that fixes the tests.

I will then wait until Jenkin tests pass before doing some manual testing.

@aphelionz I tested it out with this additional setting and verified now the uploaded temp file goes to hs_tmp rather than /tmp, so yay! However, files coming from a non-federated zone when creating a resource still goes to /tmp folder, which used NamedTemporaryFile() to hold files retrieved from iRODS. It appears NamedTemporaryFile() still uses /tmp. I will look into it a bit. but let me know if you have any ideas on this.

@aphelionz @pkdash Tests still fails even though upload temp files did get created under /hs_tmp directory according to my local testing. However, for some reason, NamedTemporaryFile() path is always /tmp in my local environment. I did tried to go into docker container, run a python console, and checked NamedTemporaryFile() object path which does output /hs_tmp, but somehow in Django environment it is always /tmp. I ran out of ideas and hope this resolves itself in a VM testing environment. However, the test failures do need to be resolved.

Tests are fixed and this PR is much much smaller now

Have tested in playground test VM and everything works as expected, so a +1 from me to merge.