Compiler errors not being reported (unless they are syntax errors)

Steps to Reproduce

Clone https://github.com/conwayste/conwayste
Checkout commit e07f87b
Open up conwayste/src/client.rs with neovim running LanguageClient-neovim
Go to line 283, and insert the line let () = net_worker; (such that this is the new line 283)
Click Save

Expected Result
An error about type mismatches showing the type of net_worker
Actual Result
No errors shown.
Version Info
rustc 1.45.2
rust-analyzer 0b2b9a5
Log
rust-analyzer-bug.log

Not sure this would be exactly the same root cause. This happens to me as well, but only when I point to anything external in one of the Cargo.toml in the workspace, like:
[dependencies.a2]
 path="../../a2"

It works for some time. And then it stops running cargo check at some moment. Restarting vscode would not help. Re-installing rust-analyzer helps for some minutes of work again.

Interesting observation. If you check our repo you'll see we are also doing this: https://github.com/conwayste/conwayste/blob/master/conwayste/Cargo.toml

Triage: I can't reproduce this because cargo check fails with a weird linker error:
    Checking winit v0.19.5
error: linking with `clang` failed: exit code: 1
  |
  = note: "clang" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-Wl,--eh-frame-hdr" "-L" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.13kedvlsesdmyrn2.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.1rw7am10i2xacag9.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.2ewpp7u4fdo2z7wf.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.2vnu8arzaqsrtel5.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.37kmzq0s29y0nl0q.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.3idybq3wwguixdxw.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.3vh6267wmiaw9ch4.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.3vhq4d6fwjy6jli0.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.3z0mroztar7xr6cd.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4045bdam7x43jejm.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.42065utw7d4u9uj7.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.42y9f61z54omk4re.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4dpt4r2s8bs3clsl.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4est0yji334iwbzy.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4fjiughrlry6zl6q.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4fsmg21blreue2wh.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4rr82ong81ga4kdx.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4vht20nuw1pp3atg.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.52hl0bkkx1c7ahf5.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.54vuwkwl9kc4y44z.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.59wpmmih8y73u4ql.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.9itj0p9987njnuq.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.aemw3ids50rt9g9.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.lvcdl0ealcimlen.rcgu.o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.qo5jxi90t7htuya.rcgu.o" "-o" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b" "/home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.4b1xz45v40985vnp.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/me/conwayste/target/debug/deps" "-L" "/home/me/conwayste/target/debug/build/libloading-8807affcfcf64941/out" "-L" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/me/conwayste/target/debug/deps/libpkg_config-e6be48dfd8446a62.rlib" "/home/me/conwayste/target/debug/deps/libbindgen-1db9183bc6de7cb7.rlib" "/home/me/conwayste/target/debug/deps/liblog-4bf1047162af990b.rlib" "/home/me/conwayste/target/debug/deps/libwhich-3f0cf2a884436b94.rlib" "/home/me/conwayste/target/debug/deps/libshlex-4a4c2f8255e6015b.rlib" "/home/me/conwayste/target/debug/deps/libregex-9fca807dbf6037c4.rlib" "/home/me/conwayste/target/debug/deps/libthread_local-b1b857567b38aff1.rlib" "/home/me/conwayste/target/debug/deps/libregex_syntax-f58e76f38029c5ae.rlib" "/home/me/conwayste/target/debug/deps/libaho_corasick-795ec644f577bef4.rlib" "/home/me/conwayste/target/debug/deps/libquote-21d96aae44871e50.rlib" "/home/me/conwayste/target/debug/deps/libproc_macro2-6ca644c400011813.rlib" "/home/me/conwayste/target/debug/deps/libunicode_xid-083414e3434d8e82.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-eba4ba6c63f96a02.rlib" "/home/me/conwayste/target/debug/deps/libpeeking_take_while-209dce6f2d242089.rlib" "/home/me/conwayste/target/debug/deps/liblazy_static-cd2401a06b1676f6.rlib" "/home/me/conwayste/target/debug/deps/librustc_hash-d8014d7e08dbd39d.rlib" "/home/me/conwayste/target/debug/deps/liblazycell-13e71b09752696d8.rlib" "/home/me/conwayste/target/debug/deps/libclang_sys-9958a00734c6b066.rlib" "/home/me/conwayste/target/debug/deps/liblibloading-11977ad0b39072b1.rlib" "/home/me/conwayste/target/debug/deps/liblibc-6ba8b754d6fb20a6.rlib" "/home/me/conwayste/target/debug/deps/libglob-c57da5286c7fae6e.rlib" "/home/me/conwayste/target/debug/deps/libcfg_if-4c6be1962c556cf0.rlib" "/home/me/conwayste/target/debug/deps/libcexpr-498c25af64543d0e.rlib" "/home/me/conwayste/target/debug/deps/libnom-ad1c863c910eb478.rlib" "/home/me/conwayste/target/debug/deps/libmemchr-bb23920ec89494b5.rlib" "/home/me/conwayste/target/debug/deps/libbitflags-df474a8ca45884a8.rlib" "-Wl,--start-group" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-25c6acf8063a3802.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-539f13c9442f1597.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-37db28e905edb56b.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-9ef2480568df55af.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1e0f0992cdbecd66.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-6c8e02b8fedc1e5f.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-807e5ad203594490.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-083fce1bea11612a.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-1af568081add9042.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-1395b54a3b3f45bf.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-caba820045f178d5.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-512eb53291f6de7e.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-5efacc5025f9f3d8.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-9c4002b5f79ba0e1.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-90996f4879673567.rlib" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-9ea09a899c3eda46.rlib" "-Wl,--end-group" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-ef2408da76957905.rlib" "-Wl,-Bdynamic" "-ldl" "-lutil" "-ldl" "-lutil" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc"
  = note: /usr/bin/ld: /home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.3z0mroztar7xr6cd.rcgu.o: in function `build_script_build::main':
          /home/me/conwayste/dissect-netwayste/build.rs:28: undefined reference to `bindgen::Builder::generate'
          /usr/bin/ld: /home/me/conwayste/dissect-netwayste/build.rs:31: undefined reference to `core::result::Result<T,E>::expect'
          /usr/bin/ld: /home/me/conwayste/dissect-netwayste/build.rs:34: undefined reference to `core::ptr::drop_in_place'
          /usr/bin/ld: /home/me/conwayste/dissect-netwayste/build.rs:34: undefined reference to `core::ptr::drop_in_place'
          /usr/bin/ld: /home/me/conwayste/dissect-netwayste/build.rs:34: undefined reference to `core::ptr::drop_in_place'
          /usr/bin/ld: /home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.42065utw7d4u9uj7.rcgu.o: in function `<bindgen::Builder as core::default::Default>::default':
          /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:204: undefined reference to `<bindgen::BindgenOptions as core::default::Default>::default'
          /usr/bin/ld: /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:202: undefined reference to `core::ptr::drop_in_place'
          /usr/bin/ld: /home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.59wpmmih8y73u4ql.rcgu.o: in function `bindgen::Builder::header':
          /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:683: undefined reference to `core::ptr::drop_in_place'
          /usr/bin/ld: /home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.59wpmmih8y73u4ql.rcgu.o: in function `bindgen::Builder::clang_arg':
          /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:1059: undefined reference to `core::ptr::drop_in_place'
          /usr/bin/ld: /home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.59wpmmih8y73u4ql.rcgu.o: in function `bindgen::Builder::clang_arg':
          /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:1059: undefined reference to `core::ptr::drop_in_place'
          /usr/bin/ld: /home/me/conwayste/target/debug/build/dissect-netwayste-648cfd707c4b060b/build_script_build-648cfd707c4b060b.59wpmmih8y73u4ql.rcgu.o: in function `bindgen::Bindings::write_to_file':
          /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:2134: undefined reference to `<core::result::Result<T,E> as core::ops::try::Try>::from_error'
          /usr/bin/ld: /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:2139: undefined reference to `bindgen::Bindings::write'
          /usr/bin/ld: /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.53.1/src/lib.rs:2139: undefined reference to `<core::result::Result<T,E> as core::ops::try::Try>::from_error'
          /usr/bin/ld: /home/me/conwayste/target/debug/deps/libbindgen-1db9183bc6de7cb7.rlib(bindgen-1db9183bc6de7cb7.bindgen.3307kqji-cgu.11.rcgu.o): in function `core::slice::index::<impl core::ops::index::IndexMut<I> for [T]>::index_mut':
          /home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:26: undefined reference to `<core::ops::range::RangeFrom<usize> as core::slice::index::SliceIndex<[T]>>::index_mut'
          clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

@lnicola I don't know what the problem is, but dissect-netwayste uses bindgen to create a wireshark plugin. It isn't core functionality of this project, so if you can find a way to exclude it from cargo check you should be able to reproduce the bug.

@AaronM04 haha, nice, I removed it from Cargo.toml. Unfortunately, it's working for me:

Could the linker error you saw @lnicola be the reason that no errors are reported for @AaronM04?

Maybe, but it seems unlikely.

Is this with the latest rust-analyzer or the version I mentioned?
On December 21, 2020 8:05:27 AM PST, "Laurențiu Nicola"<EMAIL_ADDRESS>wrote:

@AaronM04 haha, nice, I removed it from Cargo.toml. Unfortunately,
it's working for me:

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/rust-analyzer/rust-analyzer/issues/5918#issuecomment-749050593

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

It also works for me on your version (and nvim/LanguageClient-neovim):

@AaronM04 are you still seeing this?
(Marking S-actionable, if you look at this in the future and the OP hasn't answered, ping me so we can close it.)

@AaronM04 are you still seeing this?
(Marking S-actionable, if you look at this in the future and the OP hasn't answered, ping me so we can close it.)

@lnicola yes, I am still seeing this.
$ rustc --version
rustc 1.48.0
$ uname -a
OpenBSD <redacted hostname> 6.8 GENERIC.MP#243 amd64

Rust-analyzer commit ac30710 from 2020-11-29
Tested with both coc.nvim on vim and with languageClient-neovim on nvim.

@lnicola yes, I am still seeing this.
$ rustc --version
rustc 1.48.0
$ uname -a
OpenBSD <redacted hostname> 6.8 GENERIC.MP#243 amd64

Rust-analyzer commit ac30710 from 2020-11-29
Tested with both coc.nvim on vim and with languageClient-neovim on nvim.

I upgraded rust-analyzer and it is still happening (tested with coc.nvim on vim):
$ rust-analyzer --version
rust-analyzer 3ab8d7a

This commit is from 2021-01-24

I upgraded rust-analyzer and it is still happening (tested with coc.nvim on vim):
$ rust-analyzer --version
rust-analyzer 3ab8d7a

This commit is from 2021-01-24

Hmm, is there an OpenBSD live image? I have absolutely no experience with it. I wonder if it might be something platform-specific.

Hmm, is there an OpenBSD live image? I have absolutely no experience with it. I wonder if it might be something platform-specific.

I don't believe so, but it is pretty quick to install in VirtualBox. sysupgrade -s as root installs the latest snapshot, which will then allow you to install a recent Rust version with pkg_add rust.
I can assist with editor setup if/when you need assistance.
On January 28, 2021 8:41:32 AM PST, "Laurențiu Nicola"<EMAIL_ADDRESS>wrote:

Hmm, is there an OpenBSD live image? I have absolutely no experience
with it. I wonder if it might be something platform-specific.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/rust-analyzer/rust-analyzer/issues/5918#issuecomment-769214242

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

I don't believe so, but it is pretty quick to install in VirtualBox. sysupgrade -s as root installs the latest snapshot, which will then allow you to install a recent Rust version with pkg_add rust.
I can assist with editor setup if/when you need assistance.
On January 28, 2021 8:41:32 AM PST, "Laurențiu Nicola"<EMAIL_ADDRESS>wrote:

Hmm, is there an OpenBSD live image? I have absolutely no experience
with it. I wonder if it might be something platform-specific.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/rust-analyzer/rust-analyzer/issues/5918#issuecomment-769214242

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Now I get an error building alsa-sys (via cpal) -- I don't think ALSA is available on OpenBSD?

Now I get an error building alsa-sys (via cpal) -- I don't think ALSA is available on OpenBSD?

Correct. If you switch to the aaron/openbsd_ggez branch, you should be able to test this, since it uses sndio rather than ALSA. Note that this branch has submodules.
Sorry this is more complex than you probably anticipated. I think you're almost there :)
On January 31, 2021 2:17:24 AM PST, "Laurențiu Nicola"<EMAIL_ADDRESS>wrote:

Now I get an error building alsa-sys (via cpal) -- I don't think
ALSA is available on OpenBSD?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/rust-analyzer/rust-analyzer/issues/5918#issuecomment-770358769

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Correct. If you switch to the aaron/openbsd_ggez branch, you should be able to test this, since it uses sndio rather than ALSA. Note that this branch has submodules.
Sorry this is more complex than you probably anticipated. I think you're almost there :)
On January 31, 2021 2:17:24 AM PST, "Laurențiu Nicola"<EMAIL_ADDRESS>wrote:

Now I get an error building alsa-sys (via cpal) -- I don't think
ALSA is available on OpenBSD?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/rust-analyzer/rust-analyzer/issues/5918#issuecomment-770358769

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Looks like it also needs:
# pkg_add clang-tools-extra wireshark
$ export LIBCLANG_PATH=/usr/local/lib/

But dissect-netwayste still doesn't build:
  wrapper.h:2:10: fatal error: 'config.h' file not found
  wrapper.h:2:10: fatal error: 'config.h' file not found, err: true
  thread 'main' panicked at 'Unable to generate bindings: ()', dissect-netwayste/build.rs:28:48

So I excluded it again from the workspace. I then installed rust-analyzer at 1a59f75 and ran:
$ export PATH=~/.cargo/bin:$PATH

I set up nvim using https://github.com/lnicola/dotfiles/blob/master/.config/nvim/init.vim, but disabled deoplete:
"Pack 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }

And built LanguageClient-neovim using:
$ cd ~/.config/nvim/pack/minpac/start/LanguageClient-neovim
$ ./install.sh

Then tried to load the project. However, OpenBSD doesn't seem to package rust-src. so I copied over my installation from my Linux box and ran:
$ export RUST_SRC_PATH=~/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library

Opened conwayste/src/client.rs, added that line and got:

One issue is that indeed, the error seems to be reported as a warning. It's an error in the beginning (there's an x in the left`), but it disappears after a couple of seconds. It does, however, say error in the status bar:

Do the other rust-analyzer features work for you? How did you acquire the standard library source code?

@AaronM04 are you still having this issue on code that compiles? I guess I can send you my OpenBSD VM image if you want to give it a try.

Hi @lnicola, sorry for the late reply.
Yes, I am still having this issue, now reproduced with:
$ rust-analyzer --version
rust-analyzer 3ab8d7a
$ rustc --version
rustc 1.49.0
$ cd conwayste/
$ git rev-parse --short HEAD  # this commit compiles
b45f848

I am able to use other rust-analyzer features, such as going to a definition. Clearly the analyzer has some understanding of the semantics of the code. For some reason, though, it doesn't report this error.
If it's not too much trouble, can you send me your VM image?

I was able to reproduce this with a more recent rust-analyzer commit:
rust-analyzer 14de9e5

For the first time, I was not able to reproduce this, a few days ago. I don't know why.

@AaronM04 sorry for the late answer, I realized I probably had to make another VM and it got on the back burner. Is it working for you now?

Glad to hear it worked out in the end. I'll close this, but feel free to reopen if you run into this again.

I've had this problem occur for me today. The analyzer can syntax highlight and find syntax errors, but cargo check output is ignored. I narrowed it down starting when I wrote a .cargo/config.toml file in my project root.
Having things in the project's .cargo/config.toml does not cause problems in general. And by changing the config.toml and forcing cargo check to run again, it seems to have cleared up whatever was broken. Reisntalling/upgrading/downgrading the analyzer did not.
So, in the end it's working for me again, and I don't know what broke it. Perhaps cargo check failed mid-way through for some reason and left things in a bad state that could not be recovered from without dirtying everything (changing profile.dev.codegen-units for example).


A little more documentation please

Greetings,
I'm really interested in your work and supporting your efforts if I can.
I'm a little confused on some of the changes you've implemented since 0.10. Can you provide some comments in the source code or more in the ReadMe?
For instance..

What are the different methods doing in the worker builder? I get AddHandler, but what are the others doing?
What is the impact of the worker count?
What's the proper use of the [HandlerVariables] attribute?
How can I get all of the variables?
How should I deal with External task topics that I don't have a specific handler for? Can I have some kind of catch all?
What's the proper use of the CompleteTask object?
What configuration do I need if I'm running multiple instances of my client code? Unique worker names?

Again.. really thankful for your work. When do you think you'll get to version 1.0? And when will the breaking changes slow down?

I will be glad of your help, but first I have to make a backlog so that your work is not in vain. As for your questions, some questions relate to things that I plan to change in the next version and I can only outline a general vision. Here are the answers for some of questions. I will prepare answers to the rest later.

What is the impact of the worker count?

This is the number of parallel workers with same configuration. Every worker performs "fetch and lock -> process" routine in infinite loop (see RunAsync). The hosted service is responsible for starting the workers.
In the sample app, the number of parallel workers is 1. This means that only one worker performs "fetch and lock -> process" routine.

What's the proper use of the CompleteTask object?

Did you mean CompleteResult? If so, then this is an analogue of OkObjectResult from ASP.NET Core. Instances of this class represent successful processing of an external task. As you can see here, processing such instances internally causes camunda to complete the task.

What configuration do I need if I'm running multiple instances of my client code? Unique worker names?

Unfortunately, I don't have an answer to this question. Since this applies in general to interaction with comuna, I think you can find the answer in their forum. (https://forum.camunda.org/)

What's the proper use of the [HandlerVariables] attribute?

This attribute is used to tell camunda which variables the handler needs. Sometimes it might be a local variables. You can just use it to "declare API" of your handler.

How can I get all of the variables?

The documentation of "fetch and" lock" says "If not provided - all variables will be fetched." So if you don't use the [HandlerVariables] attribute, you will get all the variables.

How should I deal with External task topics that I don't have a specific handler for? Can I have some kind of catch all?

Set of topic names is required to perform "fetch and lock". Your program doesn't receive external task with topic name that your program doesn't request.

What are the different methods doing in the worker builder? I get AddHandler, but what are the others doing?

At the moment there are 4 methods that can be used to modify the work of the worker:

AddTopicsProvider is designed to convert information about registered handlers into topics that will be used in "fetch and lock" requests. There is a task (#43) to change this abstraction.
AddEndpointProvider is designed to change the mechanism for selecting a handler based on information about an external task. I plan to change the signature of this abstraction.
ConfigurePipeline #2
ConfigureEvents #4


feat: milliseconds support

This is an initial draft PR for the millisecond feature #1361. Would love to get your feedback on this up to this point.

@Aditya-ds-1806 as discussed in https://github.com/flatpickr/flatpickr/issues/1361#issuecomment-1059975568 and https://github.com/flatpickr/flatpickr/issues/2520#issuecomment-983721887 at least nanosecond resolution should be supported, this PR should aim to provide general "fractional seconds" support

Got it, so you want me to increase the precision to 9 and preferably users should be able to configure it. Will try to push the changes in a few hours!

are the input elements configured to display a maximum of 4 digits somewhere? input.value.length doesnt go beyond 4 at all for some reason @mvorisek

4 digits? If you can get beyond 3 digits it should be not because of Date having only 3 digits/milli resolution - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date.
Please add tests and push the changes.

@mvorisek In that case should we leave it to the users to figure out how they want to format the millisecond input via the formatDate field? I have pushed the changes, please let me know

Looking forward for this pull request to be merged.

This PR should be closed in favor of #2910 which added generic fractional seconds support.


Consider tooltip graph from current state + data

Given:

year as time column
column name as layer column
data on client side (standalone npm case)

Generate: tooltip graph.
Our other showcases rely on custom code to pull data on tooltip hover. Is it possible to detect at least year + current column used to generate say an area thematic map.

This could be part implemted already for point/line data.

Reopen with better description


[Fx] Fix folder permission issue in NFS setting

Issue #92, if available:
Description of changes:

Use rank 0 to makedirs and chmod to 777;
Make directories and chmod before save sparse embeddings.
Apply the same method for saving node representations, node/edge predictions.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Please take security considerations in mind when setting directory structure permissions to 777: https://superuser.com/questions/1034079/is-it-safe-to-chmod-777-everything and https://linuxize.com/post/what-does-chmod-777-mean/
I would suggest coming up with a less invasive solution that sets permissions according to least privilege principles.

No, 777 is not safe. And the least privilege that can let current code works is 767.
The reason for the last 7, rwx, is that the GSF use ssh to login to other containers and start GSF processes, whose umask is nobody:nogroup. This umask has the least privilege. To let these processes to save learnable embeddings, node representations, and predictions, the folder has to be 7*7.
Below is the outputs of the saved learnable embeddings:
-rw-r--r-- 1 root   root    10838778 Apr 18 05:04 sparse_emb_0.pt
-rw-r--r-- 1 root   root    10838778 Apr 18 05:04 sparse_emb_1.pt
-rw-r--r-- 1 root   root    10838778 Apr 18 05:04 sparse_emb_2.pt
-rw-r--r-- 1 root   root    10838778 Apr 18 05:04 sparse_emb_3.pt
-rw-r--r-- 1 nobody nogroup 10838778 Apr 18 05:04 sparse_emb_4.pt
-rw-r--r-- 1 nobody nogroup 10838778 Apr 18 05:04 sparse_emb_5.pt
-rw-r--r-- 1 nobody nogroup 10838778 Apr 18 05:04 sparse_emb_6.pt
-rw-r--r-- 1 nobody nogroup 10838266 Apr 18 05:04 sparse_emb_7.pt

The 4 to 7 sparse_emb_*.pt files were saved by the 2nd GSF container who mount an NFS shared by the 1st GSF container. These files' user and group is nobody and nogroup.
Because this issue is caused by the mechanism used by DistDGL's ssh method, I cannot figure out a better way to solve it.
I tried other permission settings, like chmod to 766 or 763. None works.

Hmm, yeah does sound tricky to overcome. Have we tried passing root as the username for our call to DGL's launch.py? With the --ssh_username argument, since root maps to userid 0 on all systems we might be able to get the same owner and group in the resulting files?

Hmm, yeah does sound tricky to overcome. Have we tried passing root as the username for our call to DGL's launch.py? With the --ssh_username argument, since root maps to userid 0 on all systems we might be able to get the same owner and group in the resulting files?

Actually, the graphstorm launch script use "ssh -p 2222 root@ip" to login as a root user.


Multiroot Workspace setups for different product release combinations

We are using the IBM Z OPEN EDITOR alongside with ZOWE EXPLORER, ZOWE PLUGINS and powershell tasks (+helper extensions for easier triggering of the powershell scripts, but these don't matter for this request).
VSCODIUM is setup with a multiroot workspace:
local filestructure in VSCODIUM:
[PRODUCT/RELEASE] Folder
> Subfolder with copybooks of user
> subfolder with pli sources of user
.....
Editor settings:
....
"zopeneditor.propertygroups":  [
{
"name":  "mvs-members",
"type":  "mvs",
"syslib":  [
"[USER].AAA.BBB",
"XXX.YYY.ZZZ.COPYBOOK",
"XXX.[PRODUCT].T[RELEASE].COPYBOOK",
"XXX.[PRODUCT].B[RELEASE].COPYBOOK",
"XXX.[PRODUCT].R[RELEASE].COPYBOOK"
]
},
....
Description of the enhancement requested

I would like to see..

The possibility to map host datasets to different product/release folders (+ subfolders).
example:
When browsing copybooks on local Subfolder A1 the SYSLIB of A1 should be "connected" to it.
When browsing copybook on local Subfolder B2 the SYSLIB of B2 should be "connected" to it.
Where A means [PRODUCT] and 1 [RELEASE],etc...
For now we could not manage to get this working with the current possibilities, if there is a way please provide an Example.

Thanks!

Thanks for submitting this idea. If we implement such a feature we would do it with ZAPP files as the scope of settings is controlled by the editor. With ZAPP files we can control this ourselves and define it to meet our user's needs.


Develop

Tests moved for pytest testing, more functional tests added, some aspects were refactored, and some bugs (known) were fixed.

Looks good


Automated cherry pick of #2477: fix: use policy match weight to override less specific policy

Cherry pick of #2477 on release/2.11.
#2477: fix: use policy match weight to override less specific policy

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.11@cf78767). Click here to learn what that means.
The diff coverage is 70.87%.

@@              Coverage Diff               @@
##             release/2.11   #2533   +/-   ##
==============================================
  Coverage                ?   7.17%
==============================================
  Files                   ?     456
  Lines                   ?   72223
  Branches                ?       0
==============================================
  Hits                    ?    5182
  Misses                  ?   66610
  Partials                ?     431

Flag
Coverage Δ

#aFlag
7.17% <70.87%> (?)

Impacted Files
Coverage Δ

pkg/util/stringutils2/sortedstrings.go
52.52% <0%> (ø)

pkg/cloudcommon/policy/policy.go
1.54% <0%> (ø)

pkg/util/rbacutils/rbac.go
53.15% <81.57%> (ø)

pkg/util/rbacutils/reduce.go
86.36% <86.36%> (ø)

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 cf78767...9694523. Read the comment docs.

/lgtm

/approve


please release and publish 0.3.0 (or 0.2.1) to sonatype

published and released 0.2.1 and ran the sona type sync process so it should be queued up for maven central resolution soon
the jar should be up on bintray now https://bintray.com/softprops/maven/retry/0.2.1/view#files/me/lessis/retry_2.11/0.2.1
when it does sync up it should show up here

thanks @softprops !


Avoid trace files to be outdated from simulation time

Hi !
We found out recently that trace files are not flushed at the end of a time cycle. The consequence is that some traces can be held back in stdlib buffers. It is not a problem when using trace files in post-mortem analysis. But if we want to use these files during the simulation it is problematic.
The included file shows the case. Using tail -f on the output trace.vcd file while simulation is ongoing shows that traces are coming big chunk by big chunk every few seconds even though traces are generated every 100ms.
case.cc.gz
One simple (the attached one) solution is to just add an fflush every time we've generated some traces. This patch just do that on both vcd and wif trace file. This guarantees that trace files are always up-to-date with current simulation time.
Of course the drawback is that it may slow down the simulation speed (especially if there is only a few changing traced signals). Other solutions exist such as adding API to created un-buffered trace files allowing to keep the previous-behavior.
Here's an example commit for adding an optional argument to the sc_create_{vcd,wif}_trace_file.
Damien

Thanks for your contribution, Damien!
For your contribution to be applicable for consideration by the Accellera working groups, you need to  sign-off the Accellera Developer's Certificate of Origin as described in the CONTRIBUTING file.

Hi Philipp,
I rebased on top of master and added the signed-off line
Sorry for the delay.
Damien

This looks fine.


craco build doesn't return exit code

I have this configuration for CRA5
"scripts": {
    "start": "craco start",
    "build": "echo cos & craco build & echo ktos",
    "test": "craco test"
  },

when I run yarn build I'm getting:
yarn run v1.22.17
$ echo cos & craco build & echo ktos
cos
Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

  892 B (-2 B)  build\static\js\main.eb1bc54e.js

The project was built assuming it is hosted at /.
You can control this with the homepage field in your package.json.

The build folder is ready to be deployed.
You may serve it with a static server:

  yarn global add serve
  serve -s build

Find out more about deployment here:

  https://cra.link/deployment

"ktos" is never shown on the output. This stops my pipeline build because proces never exits.

temporary workaround:
var child = require('child_process').exec('yarn run craco build')
child.stdout.pipe(process.stdout)
child.on('exit', function() {
  process.exit()
})

child.stdout.on('data', (d) => {
  if (d && d.includes("Find out more about deployment here")) {
    process.exit()
  }
})

It was issue in our code


BatchNorm layer not working in keras3

Repro Colab using Keras3:
https://colab.research.google.com/drive/1ZBE4jA_Wl0XkFqJrAvKRsXGDPkLAAoGw#scrollTo=-z2e9X78wAOu
In the notebook, MNIS training converges when not using BatchNorm, but does not converge withBatchNorm.
Repro Colab using Keras2:
https://colab.research.google.com/drive/12tv_Nfqf9G62Kbx0n7GJEIGDjnQT5AsX#scrollTo=8Hzctgy0HTmv
In this notebook, both BatchNorm and non-BatchNorm runs are successsful.
I have also tested this using the Jax backend, with identical results.
Possibly related: https://github.com/keras-team/keras/issues/18594

This is now fixed. Root cause was an XLA numerical instability.


[master] train 224

This is train 224. It is comprised of the following pull requests:

#1858
#1902
#1910
#1913
#1944

@mesosphere-mergebot bump-ee

CI tests are passing, now waiting on the other checks.

@mesosphere-mergebot bump-ee

The latest commits/push removes #1858.

The latest commits/push removes #1858.

Sorry that I did not review sooner and missed the specifics. There are two conflicting motivations here.

Following the process.
Getting things done.

If we followed 1. what @colin-msphere  did was right. However, we could have done 2. too - the delta was easy to review, could have applied ship-it on the PR and got them here. There was nothing technical missing in #1858
We could land #1858 in a next train.

Update:
Removing #1858 was the correct thing to do. Ref: comment. /cc @colin-msphere .

@mesosphere-mergebot bump-ee


Scientific notation colorbar

Description
Current version supports axs.pcolormesh(data, norm='log') to set the colorbar ticks to logscale.
However, the ticks can't be changed to scientific notation.
Steps to reproduce
import numpy as np
import proplot as plot
import matplotlib.ticker as ticker

# Sample data
N = 20
state = np.random.RandomState(51423)
data = 11 ** (0.25 * np.cumsum(state.rand(N, N), axis=0))

# Figure
fig, axs = plot.subplots()

# Plot with colormaps and normalizers
m = axs.pcolormesh(data, norm='log', cmap='viridis')
axs.colorbar([m])

Expected behavior:
Use 10^0, 10^1, 10^2, 10^3... as the colorbar ticks.
Actual behavior:
Even if I follow the matplotlib tutorial here:
def fmt(x, pos):
    a, b = '{:.1e}'.format(x).split('e')
    b = int(b)
    return r'${} \times 10^{{{}}}$'.format(a, b)

axs.colorbar([m], format=ticker.FuncFormatter(fmt))

The colorbar ticks aren't changed:

Similiar steps in matplotlib
import numpy as np
import matplotlib.ticker as ticker
import matplotlib.pyplot as plt

# Sample data
N = 20
state = np.random.RandomState(51423)
data = 11 ** (0.25 * np.cumsum(state.rand(N, N), axis=0))

# Figure
fig, axs = plt.subplots()

# Plot with colormaps and normalizers
m = axs.pcolormesh(data, cmap='viridis')

def fmt(x, pos):
    a, b = '{:.1e}'.format(x).split('e')
    b = int(b)
    return r'${} \times 10^{{{}}}$'.format(a, b)

plt.colorbar(m, format=ticker.FuncFormatter(fmt))

Proplot version
0.7.0

Hi, this is a (somewhat hidden) proplot feature (see this page). I make AutoFormatter the default tick label formatter everywhere, even in log-plots. This is because proplot's axis formatter trims trailing zeros so even in log-plots, the default formatter looks nice.
To change the colorbar formatter just pass formatter='sci' or formatter='log' to colorbar (this page) from the docs shows all the available formatters).
However I wasn't aware that matplotlib's colorbar functions already had a format keyword. I'll add that as an alias for formatter in the next version.

Just added that last note -- now colorbar will interpret the format keyword.

Thanks for the improvements👍


More-Thuente Linesearch Algorithm Bug: "Search direction must be a descent direction"

Discussed in https://github.com/argmin-rs/argmin/discussions/358

Originally posted by itrumper May 24, 2023
I have been using the More-Thuente linesearch with a L-BFGS solver on an optimization problem. The convergence is typically very efficient (in my opinion), however I often encounter the error, MoreThuenteLineSearch: Search direction must be a descent direction. I have looked at the code for L-BFGS, and it initializes the search direction on this line.
The code in MoreThuenteLineSearch then evaluates whether the search direction is within 90 degrees of the descent direction on this line.
I'm curious if anyone can help me understand why the L-BFGS algorithm may be providing a search direction that violates this condition? Looking at the optimization state prior to this error being thrown I don't see anything in the gradient or cost functions that stand out to me, it seems like everything is progressing along smoothly.
I have also attempted to adjust the bounds and Wolfe condition parameters, but those do not seem to ever completely remove this behavior, although I am not very experienced with this realm of mathematics, so my investigation has been purely experimental.
It also seems that the check in MoreThuenteLineSesarch could be improved so that if the search direction is more anti-parallel to the descent direction, we could flip the search direction's sign to align. In the case of perpendicular, I agree, an error should be thrown.
Thank you in advance for any help and suggestions!

Here's a snippet of the logs that I am getting from running an optimization problem with the following parameters:
// Backtracking is a more stable line search, but slow
// let linesearch = BacktrackingLineSearch::new(ArmijoCondition::new(1e-3_f64)?);

// More Thuente is efficient and converges quickly, but hits a condition where
// the search direction is not a descent direction and throws an error often.
let linesearch = MoreThuenteLineSearch::new().with_bounds(1e-10, 0.01)?;

// Hager Zhang is chaotic and doesn't make a lot of sense... I haven't gotten
// it to converge nicely
// let linesearch = HagerZhangLineSearch::new().with_bounds(f64::EPSILON, 0.1)?;

// let solver = SteepestDescent::new(linesearch);
let solver = LBFGS::new(linesearch, 11);

2024-01-23T03:24:10.211Z Cost fn evaluated to 0.6676890118219991
2024-01-23T03:24:10.211Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:24:10.212Z Computed grad vector: [0, 3.0997862054960024, 0]
2024-01-23T03:24:10.213Z Cost fn evaluated to 0.5715882697034778
2024-01-23T03:24:10.213Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:24:10.213Z Computed grad vector: [0, 3.1006950340639605, 0]
2024-01-23T03:24:10.213Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:24:10.214Z Computed grad vector: [0, 3.1006950340639605, 0]

As a bit more explanation, I have found that increasing the bounds of the MoreThuenteLineSearch will cause the error to occur more quickly.
I also have another problem that I run the same optimization setup on, but it converges and produces the following logs. I don't see a difference in the size of the gradient vector, but the sign does flip.
2024-01-23T03:34:06.187Z Cost fn evaluated to 0.6254349428238886
2024-01-23T03:34:06.187Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.188Z Computed grad vector: [0, 2.731187720428352, 0]
2024-01-23T03:34:06.188Z Cost fn evaluated to 0.550844902068393
2024-01-23T03:34:06.188Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.189Z Computed grad vector: [0, 2.7309070560477267, 0]
2024-01-23T03:34:06.189Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.189Z Computed grad vector: [0, 2.7309070560477267, 0]
2024-01-23T03:34:06.189Z Cost fn evaluated to 6.73861376817015
2024-01-23T03:34:06.189Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.190Z Computed grad vector: [0, -2.781852970201726, 0]
2024-01-23T03:34:06.190Z Cost fn evaluated to 0.6058695233908544
2024-01-23T03:34:06.190Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.191Z Computed grad vector: [0, -2.7292159643366176, 0]
2024-01-23T03:34:06.191Z Cost fn evaluated to 0.01359682405543694
2024-01-23T03:34:06.191Z  Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.191Z Computed grad vector: [0, 2.72974176596108, 0]
2024-01-23T03:34:06.192Z Cost fn evaluated to 0.3952637805807324
2024-01-23T03:34:06.192Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.192Z Computed grad vector: [0, -2.7293296511743392, 0]
2024-01-23T03:34:06.192Z Cost fn evaluated to 0.04676583741164109
2024-01-23T03:34:06.192Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.193Z Computed grad vector: [0, -2.729674264401183, 0]
2024-01-23T03:34:06.193Z Cost fn evaluated to 0.00040722710198970447
2024-01-23T03:34:06.193Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.194Z Computed grad vector: [0, 2.729736436890562, 0]
2024-01-23T03:34:06.194Z Cost fn evaluated to 0.030727132356380693
2024-01-23T03:34:06.194Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.194Z Computed grad vector: [0, -2.7297399896042407, 0]
2024-01-23T03:34:06.195Z Cost fn evaluated to 0.004034584578308298
2024-01-23T03:34:06.195Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.195ZComputed grad vector: [0, -2.7297311078200437, 0]
2024-01-23T03:34:06.195Z Cost fn evaluated to 0.0003214060094389737
2024-01-23T03:34:06.195Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.196Z  Computed grad vector: [0, -2.7297293314632043, 0]
2024-01-23T03:34:06.196Z Cost fn evaluated to 0.000042910034318666135
2024-01-23T03:34:06.196Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.197Z Computed grad vector: [0, 2.7297737403841893, 0]
2024-01-23T03:34:06.197Z Cost fn evaluated to 0.00013924947868737547
2024-01-23T03:34:06.197Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.197Z Computed grad vector: [0, -2.7296955806832557, 0]
2024-01-23T03:34:06.197Z Cost fn evaluated to 0.0000020864238905460297
2024-01-23T03:34:06.198Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.198Z Computed grad vector: [0, 2.729763082243153, 0]
2024-01-23T03:34:06.198Z Cost fn evaluated to 0.00009119527311440834
2024-01-23T03:34:06.198Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.199Z Computed grad vector: [0, -2.729768411313671, 0]
2024-01-23T03:34:06.199Z Cost fn evaluated to 0.000011430631751352394
2024-01-23T03:34:06.199Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.200Z Computed grad vector: [0, -2.7297577531726347, 0]
2024-01-23T03:34:06.200Z Cost fn evaluated to 0.00000042779802988945903
2024-01-23T03:34:06.200Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.200Z Computed grad vector: [0, -2.729780845811547, 0]
2024-01-23T03:34:06.200Z Cost fn evaluated to 0.0000008293170008499828
2024-01-23T03:34:06.200Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.201Z Computed grad vector: [0, 2.729807491164138, 0]
2024-01-23T03:34:06.201Z Cost fn evaluated to 0.00000005176851836097285
2024-01-23T03:34:06.201Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.202Z Computed grad vector: [0, -2.7297435423179195, 0]
2024-01-23T03:34:06.202Z Cost fn evaluated to 0.0000005297479344079647
2024-01-23T03:34:06.202Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.203Z Computed grad vector: [0, 2.72977196402735, 0]
2024-01-23T03:34:06.203Z Cost fn evaluated to 0.000000043145425010493454
2024-01-23T03:34:06.203Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.203Z Computed grad vector: [0, 2.7297524241021165, 0]
2024-01-23T03:34:06.203Z Cost fn evaluated to 0.0000000043116337167248275
2024-01-23T03:34:06.203Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.204Z Computed grad vector: [0, -2.7297524241021165, 0]
2024-01-23T03:34:06.204Z Cost fn evaluated to 0.000000019416900087776412
2024-01-23T03:34:06.204Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.205Z Computed grad vector: [0, 2.729732884176883, 0]
2024-01-23T03:34:06.205Z Cost fn evaluated to 0.00000000042531311805760197
2024-01-23T03:34:06.205Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.205Z Computed grad vector: [0, 1.8791581624100215, 0]
2024-01-23T03:34:06.206Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-23T03:34:06.206Z Computed grad vector: [0, 1.8791581624100215, 0]

I investigated this and I was able to reproduce the problem with L-BFGS, MoreThuenteLineSearch and the multidimensional Rosenbrock function. First I thought the problem was a untrustworthy gradient, and to some extent this seems to be true. Once the gradient gets small and numerical noise starts to dominate, the gradient points in random directions which causes this problem. By actually computing the gradient instead of using finite differences, the code does not panic anymore, but still does not converge to the correct solution. The actual problem seems to be a too small minimum step size of MoreThuenteLineSearch (sqrt(EPS)). By increasing this, the run does not panic and converges to the desired result. Below is an example of what I have done.  Via the case variable, you can switch through the different things I've tried. I tried to add all my insights as comments to the match statement in the code.
Note that you will need to use the current main branch, because I added the rosenbrock implementations today.
use argmin::{
    core::{observers::ObserverMode, CostFunction, Error, Executor, Gradient},
    solver::{linesearch::MoreThuenteLineSearch, quasinewton::LBFGS},
};
use argmin_observer_slog::SlogLogger;
use argmin_testfunctions::{rosenbrock, rosenbrock_derivative};
use finitediff::FiniteDiff;
use ndarray::{array, Array1};

struct Rosenbrock {
    a: f64,
    b: f64,
    finitediff: bool,
}

impl CostFunction for Rosenbrock {
    type Param = Array1<f64>;
    type Output = f64;

    fn cost(&self, p: &Self::Param) -> Result<Self::Output, Error> {
        Ok(rosenbrock(&p.to_vec(), self.a, self.b))
    }
}
impl Gradient for Rosenbrock {
    type Param = Array1<f64>;
    type Gradient = Array1<f64>;

    fn gradient(&self, p: &Self::Param) -> Result<Self::Gradient, Error> {
        if self.finitediff {
            Ok((*p).forward_diff(&|x| rosenbrock(&x.to_vec(), self.a, self.b)))
        } else {
            Ok(Array1::from(rosenbrock_derivative(
                &p.to_vec(),
                self.a,
                self.b,
            )))
        }
    }
}

fn run() -> Result<(), Error> {
    let case = 1;

    let (finite_diff, step_min, init_param) = match case {
        // This case uses finitediff to compute the gradient and sets the lower bound in
        // MoreThuenteLineSearch to the default value sqrt(EPS).
        // In this case, the individual elements of the gradient are around ~ 1e-7 and the
        // run panics with "Search direction must be a descent direction".
        // My guess is that numerical errors due to using finitediff cause the gradient to point
        // in random directions.
        1 => (
            // finite_diff
            true,
            // step_min
            std::f64::EPSILON.sqrt(),
            // init_param
            array![-1.2, 1.0, -10.0, 2.0, 3.0, 2.0, 4.0, 9.0],
        ),
        // This case uses the numerically computed gradient of the Rosenbrock function instead
        // of finitediff. No more panics, but it still fails to converge to the result. In
        // particular the first dimension "gets stuck".
        // Gradient elements are agin around 1e-7, but here it doesn't cause panics, probably
        // because the numerical errors don't dominate.
        2 => (
            // finite_diff off, direct computation of gradient
            false,
            // step_min
            std::f64::EPSILON.sqrt(),
            // init_param
            array![-1.2, 1.0, -10.0, 2.0, 3.0, 2.0, 4.0, 9.0],
        ),
        // Funnily, when we add another dimension to the problem, and changing the second to last
        // value of the initial parameter from 9 to 10, it does converge.
        // This is just a side note and probably not really relevant.
        3 => (
            // finite_diff off, direct computation of gradient
            false,
            // step_min
            std::f64::EPSILON.sqrt(),
            // init_param
            array![-1.2, 1.0, -10.0, 2.0, 3.0, 2.0, 4.0, 10.0, 4.0],
        ),
        // Building upon test case _2_, by increasing the minimum step size of MoreThuenteLineSearch
        // it does converge again.
        4 => (
            // finite_diff off, direct computation of gradient
            false,
            // step_min increased to 1e-4
            1e-4,
            // init_param
            array![-1.2, 1.0, -10.0, 2.0, 3.0, 2.0, 4.0, 9.0],
        ),
        // With the increased step with, even finitediff works.
        // This is a very convoluted way to say that increasing `step_min` probably solves the
        // issue.
        5 => (
            // finite_diff ON again!
            true,
            // step_min increased to 1e-4
            1e-4,
            // init_param
            array![-1.2, 1.0, -10.0, 2.0, 3.0, 2.0, 4.0, 9.0],
        ),
        _ => panic!("Non existing case"),
    };

    // Define cost function
    let cost = Rosenbrock {
        a: 1.0,
        b: 100.0,
        finitediff: finite_diff,
    };

    // set up a line search
    let linesearch = MoreThuenteLineSearch::new()
        .with_c(1e-4, 0.9)?
        .with_bounds(step_min, std::f64::INFINITY)?;

    // Set up solver
    let solver = LBFGS::new(linesearch, 7);

    // Run solver
    let res = Executor::new(cost, solver)
        .configure(|state| state.param(init_param).max_iters(200))
        .add_observer(SlogLogger::term(), ObserverMode::Always)
        .run()?;

    // Print result
    println!("{res}");
    Ok(())
}

fn main() {
    if let Err(ref e) = run() {
        println!("{e}");
        std::process::exit(1);
    }
}

How does adapting the lower bound of the stepsize affect your problem?

Thank you for the suggestion to tweak the minimum step size on the line search. I have modified it to be 1e-3, and adjusted the maximum step up to f64::INFINITY as shown in your example. The optimization problem that converged previously still converges. The problem that threw an error last time also still throws an error, but more steps are taken. However, looking at my logs, I can see that the cost function is in general higher, and hits points where the cost function is undefined. The second problem is harder, and likely less smooth than the first problem, which is why we are seeing these jumps. It appears that increasing the minimum step size does not work well for problems that have rapidly varying cost functions, or narrow solution spaces.
I then adjusted the minimum step size back down to my original value of 1e-10 and I did not see any change in the logs. The routine still yielded a larger number of steps, but they were chaotic. This makes me think that the upper bound is also important for mitigating this scenario.
Taking a step back, I thought that the line search was meant to determine its optimal step size as well? Having to constrain the bounds of the line search seems like overfitting the problem, and I am worried that by just changing the problem definition slightly, it will fail to converge and be stable. What do you think?

I must apologize, I did not read your first post carefully enough and did not notice that you had already changed the bounds. :man_facepalming: I though you had changed the c parameters with with_c.  Sorry for wasting your time!

It appears that increasing the minimum step size does not work well for problems that have rapidly varying cost functions, or narrow solution spaces.

Yes, it seems reasonable that in that case smaller steps are desirable. However, I'd expect that rapidly varying cost functions don't exhibit this problem at all.

I then adjusted the minimum step size back down to my original value of 1e-10 and I did not see any change in the logs. The routine still yielded a larger number of steps, but they were chaotic. This makes me think that the upper bound is also important for mitigating this scenario.

I believe that the effect of these parameters is difficult to judge from a few example settings, because it is likely that the entire trajectory changes and it is unclear when it will end up in an area of the cost function which causes these issues.

Taking a step back, I thought that the line search was meant to determine its optimal step size as well?

As far as I understand it, this is its sole purpose.

Having to constrain the bounds of the line search seems like overfitting the problem, and I am worried that by just changing the problem definition slightly, it will fail to converge and be stable. What do you think?

I guess it is not uncommon to adjust these settings to a problem, but I have the same concerns as you. It is difficult to trust the algorithm in production when it is so sensitive to changes of parameters.
It is out of question that the algorithm should not panic in that case. An open question is what should happen instead. Does the algorithm get stuck at a stationary point and we simply have to terminate, or is it a bug?

I must apologize, I did not read your first post carefully enough and did not notice that you had already changed the bounds. 🤦♂ I though you had changed the c parameters with with_c. Sorry for wasting your time!

Not a waste at all! Thank you for taking the time to suggest something for me to try and diagnose the problem.
What I also find very interesting about the configuration parameters, is that with the following min/max very close to each other, the first iteration is much closer to a solution, but then it will only go through a single iteration before hitting the error condition:
let linesearch = MoreThuenteLineSearch::new()
        .with_c(1e-4, 0.9)?
        .with_bounds(1e-4, 1e-3)?;

2024-01-24T14:48:52.712Z Cost fn evaluated to 0.6676890118219991
2024-01-24T14:48:52.712Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-24T14:48:52.713Z Computed grad vector: [0, 3.0997862054960024, 0]
2024-01-24T14:48:52.713Z Cost fn evaluated to 0.65808025556374
2024-01-24T14:48:52.713Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-24T14:48:52.714Z Computed grad vector: [0, 3.0998505984314306, 0]
2024-01-24T14:48:52.714Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-24T14:48:52.715Z Computed grad vector: [0, 3.0998505984314306, 0]

I guess it is not uncommon to adjust these settings to a problem, but I have the same concerns as you. It is difficult to trust the algorithm in production when it is so sensitive to changes of parameters.
It is out of question that the algorithm should not panic in that case. An open question is what should happen instead. Does the algorithm get stuck at a stationary point and we simply have to terminate, or is it a bug?

I think the algorithm should return that it "converged" but also in the return data we have access to the cost function value, and the termination condition, which should be set to StationaryPoint or something equivalent. I think that would give a caller sufficient information to determine how they want to handle the behavior. Right now, throwing an error either means I need to look for this special error case, or have my code error when a value was "found" it just may not be the optimal solution.
So is the conclusion that the algorithm is not able to optimize this problem and I need to switch algorithms?

What I also find very interesting about the configuration parameters, is that with the following min/max very close to each other, the first iteration is much closer to a solution, but then it will only go through a single iteration before hitting the error condition:
2024-01-24T14:48:52.712Z Cost fn evaluated to 0.6676890118219991
2024-01-24T14:48:52.712Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-24T14:48:52.713Z Computed grad vector: [0, 3.0997862054960024, 0]
2024-01-24T14:48:52.713Z Cost fn evaluated to 0.65808025556374
2024-01-24T14:48:52.713Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-24T14:48:52.714Z Computed grad vector: [0, 3.0998505984314306, 0]
2024-01-24T14:48:52.714Z Using a delta value of 0.000000001 to compute the local gradient
2024-01-24T14:48:52.715Z Computed grad vector: [0, 3.0998505984314306, 0]

I'm not sure if I interpret the output correctly, but to me it looks as if it is not really progressing at all.

I think the algorithm should return that it "converged" but also in the return data we have access to the cost function value, and the termination condition, which should be set to StationaryPoint or something equivalent.

You do have access to the final cost function value (if it doesn't crash of course ;)). But it will be difficult to judge whether something is a stationary point or an (local) optimum.

I think that would give a caller sufficient information to determine how they want to handle the behavior. Right now, throwing an error either means I need to look for this special error case, or have my code error when a value was "found" it just may not be the optimal solution.

I will think about how I can incorporate this in a reasonable way. I think my first approach would be to handle the error inside L-BFGS and terminate with TerminationReason::SolverExit(reason). That way you'd at least get the "final" result.

So is the conclusion that the algorithm is not able to optimize this problem and I need to switch algorithms?

Maybe, at least I think it would be worth a try. Is this a common problem that is usually solved with L-BFGS?

With #416, the error is now handled slightly better. L-BFGS terminates with SolverExit(reason) where reason is the textual representation of the line search error. This isn't great, because you'll want to be able to properly match on the error. I will have to think about how to better handle errors.


[Question]: Configuring Spark Executor for GC Logging in the Same Directory as Standard Output

Contact Details
No response
What would you like to ask or discuss?
I have a question regarding memory waste diagnosis, which relies on the executor's GC logs. However, by default, Spark's executor logs do not include this. How should I add the parameter "spark.executor.extraJavaOptions=-verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log"? How can I specify that the gc.log should be in the same directory as the standard output? This is necessary so that the YARN history server can collect the logs.

We can add this parameter -Xloggc:<LOG_DIR>/gc.log.

Thank you for the suggestion. This approach is indeed viable.


Git isn't ignoring temporary dirs and files created by Eclipse IDE

Git isn't ignoring temporary dirs and files created by Eclipse IDE. So, I suggest added some entries to .gitignore file.

(I had actually done this on branch 58 but it didn't get merged onto master somehow. Oh well.)


Pooling settings per fork

Some forks, for example, Hddcoin do not support pooling while farming with NFT plots therefore it would be useful to have an option for choosing self pool or joining a pool for each fork.

Now available in :test images, for Chives as only fork that currently supports "official" pools.

Available in v0.6.8, released.


Fix BC issue in functions trigger function submitted by old CLI

Motivation
A BC issue was introduced by #2501. If a function is submitted by old CLI, which only containers topics to serde map.
The new function worker will fail trigger request because it can't find input specs.
17:28:32.105 [function-web-7-9] ERROR org.apache.pulsar.functions.worker.rest.api.FunctionsImpl - Function in trigger function has more than 1 input topics @ /public/default/ex

Changes
The functions worker should handle BC.
Tests
No tests are added here. Since it requires a BC testing framework to be able to submit a function to a new functions worker by old CLI.
Created #2569 for adding a BC testing framework to cover such BC issues.

--customSerdeMap was a map from topicName -> Serde and not topicPattern -> Serde. The way we specify topicPattern was by a different input-parameter

@srkukarni :
 @Parameter(names = "--topicsPattern", description = "TopicsPattern to consume from list of topics under a namespace that match the pattern. [--input] and [--topic-pattern] are mutually exclusive. Add SerDe class name for a pattern in --custom-serde-inputs (supported for java fun only)", hidden = true)
        protected String DEPRECATED_topicsPattern;
        @Parameter(names = "--topics-pattern", description = "The topic pattern to consume from list of topics under a namespace that match the pattern. [--input] and [--topic-pattern] are mutually exclusive. Add SerDe class name for a pattern in --custom-serde-inputs (supported for java fun only)")
        protected String topicsPattern;

unless I missing understand the comment here ...
and here
https://github.com/apache/incubator-pulsar/blob/59df98bd5675fa17cc858fa2a0c5cac45475a5f4/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdFunctions.java#L628

--inputs = List of input topics(not patterns) with default schema as input
--custom-serde-input = Map of topic -> serde
--topic-pattern = Input Topic Pattern with default schema

--topic-pattern = Input Topic Pattern with default schema

hmm, I don't believe so. Let me find the original pull request.

https://github.com/apache/incubator-pulsar/pull/1903/files#diff-cae1c6ad6356263a1292cfcb9fddc015R110
if --topic-pattern is specified, it will look up the --custom-serde-inputs, if no serde is used, it will be using default serde.

looking into the refactor. I believe the refactor mess up this - https://github.com/apache/incubator-pulsar/blob/59df98bd5675fa17cc858fa2a0c5cac45475a5f4/pulsar-client-tools/src/main/java/org/apache/pulsar/admin/cli/CmdFunctions.java#L628

@rdhabalia @srkukarni any thoughts here about my last comment?

doesn't seem to be needed any more.


fix: add space between the profile image & username

Before, if the OSM profile image is very tall, it was very close to the username.
This adds a small gap between the username and the picture.
Before/after image:

Thanks George!
I guess this screen needs to be redesigned, but idk how.


Implement the basic Liar's Dice game

The general rules of the game should follow the first variant present on wikipedia. AdB -> (A+1)dB | Ad(B+1) | (A+1)d(B+1)
Implement the betting choices the player can do every turn as clickable buttons.
Make a nice animation for shaking the dice inside a cup.

Closing due to rebasing everything


why TADW needs label_file?

Hi~
When I review TADW's code, I'm in puzzle about that why TADW needs label_file?
The following code is in main.py , about line 98.
elif args.method == 'tadw':
     assert args.label_file != ''
     assert args.feature_file != ''
     g.read_node_label(args.label_file)
     g.read_node_features(args.feature_file)
     model = tadw.TADW(graph=g, dim=args.representation_size, lamb=args.lamb)

Yeah. There is no need for label_file in TADW. I will fix it soon.


Version number in download file

Hi! Cool utility! I wanna put this in the Homebrew repo but first it would be nice if you could put the version number in the download file. Also, using Github tags and releases would be great. You can upload the release files for each release for free with Github Actions.

Agree. Working on packaging this for Arch Linux but we really need a tagged releases. I'll probably reverse-engineer from the crates.io release for 0.2.0, but please do add Git tags for all release points.

Fantastic! I don't have this set up yet but will do soon.

$ git tag v0.1.0 6f6284b
$ git tag v0.2.0 bd81c86
$ git push --tags

Please, have patience, we will do it soon. I have set up automated release processes in the past but it takes time to set up correctly. And v0.1.0 is not an official release.


⚠ Processors has degraded performance

In 0a4b0c1, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 47 ms

Resolved: Processors performance has improved in b34417e.


Lorem Ipsum live server problem

When text on

live server its show XHR load failed

You are trying to access external resources without setting the cors policy header... It tells you the problem in the output in the console (look at your screenshot).
Set the correct header and you will not have this issue...

ok should what i do please help
On Sat, 13 Jun 2020 at 19:22, Undefined-Variables<EMAIL_ADDRESS>wrote:

You are trying to access external resources without setting the cors
policy header... It tells you the problem in the output in the console
(look at your screenshot).
Set the correct header and you will not have this issue...
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/pH7Software/pH7-Social-Dating-CMS/issues/785#issuecomment-643626749,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMXK5O2ZSUCW4VLUVJBTMRLRWOABDANCNFSM4N47BTKA
.

--

   Krishna Maurya*

Software Developer *

      Technology*

*        Krishna Maurya*
     *    Software Developer *

*           Technology*

You really need help on what's CORS ?
Maybe you shall remove your footnote then ;-)

@krishnamaurya-96 Go back and read the error message on your console. It says exactly what to do.

@Undefined-Variables It's getting worst and worst

@polynamaude I'm lost for words, how can you classify yourself as a PHP Dev if you don't know what Cors is??? Development 101!

@polynamaude I'm lost for words, how can you classify yourself as a PHP Dev if you don't know what Cors is??? Development 101!

Thansk for support its fix now thanks

I am pleased to hear it and you have learned something :)


Small UI nitpick: Button is not the same width as the rest

Submitted By: flamewave000, flamewave#6766
Feedback Type: Enhancement
Core: 0.7.9
System: dnd5e v1.2.4
Module Version: bug-reporter v1.0.0
Description:
The button is just slightly larger than the rest of the buttons on the settings page. The others are in containers with an 8px left-right margin.
.bug-report {
    margin: 0 8px;
}

When ever you make your next update, it'd be cool if you added the same margin to your button 👍

Your module is great, and I'm really happy to see a well-done way for users to submit issues in a nice and easy way. Many don't even know about GitHub or how to report things. Good job 🙂

@flamewave000 did you use ``` in your description on the module and did it "just work"? 😍

Same as #55

@akrigline that is exactly what I did :+1: I knew it was coming to GitHub and that GitHub stores all original Markdown, so I thought I'd try it 😋 I also used ```css to start the code block so it would syntax highlight.
@Ethck Sorry for the duplicate issue

No worries @flamewave000 it's more for my sanity to know that they are duplicates. If anything, your code sample is very nice :)


System.UnauthorizedAccessException using New-PnPSite

I followed this process to generate and register a client ID and client secret
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs
Then I used it to connect

I can get information

But I cannot create a site

I believe a certificate needs to be created
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azuread


CClaimTrieCache should be renamed

The naming of CClaimTrieCache in claimtrie.h/.cpp has caused a lot of confusion.
It is not a Cache for CClaimTrie, it is a cache of pending changes to CClaimTrie upon block increment/decrement.

CClaimTrieUpdateBuffer might be a good name

You can merge safety, it has only rename and separate.

Now that the new one acts like a cache, we decided that renaming it was not necessary.


fix: Use getSortedRoutes from next/next-server

What kind of change does this PR introduce?
Fixes https://github.com/toomuchdesign/next-page-tester/issues/153
Use next own route sorting solution. Found here.
This PR simply imports the sorting function, getSortedRoutes, and wraps the return value of getPagePaths with it.
What is the current behaviour?
The library uses its own sorting algorithm.
What is the new behaviour?
Use next routing solution. What you get with next, you get with this library.
Does this PR introduce a breaking change?
No.
What changes might users need to make in their application due to this PR?
Nada.
Other information:
Some tests used this pattern some/route/[slug]/index.js, which is not accepted by next. I've updated these to be some/route/[slug].js
Please check if the PR fulfills these requirements:

[ x ] Added tests for a situation where a top level catch all is present. If a route matches a nested catch all, then that route should render, otherwise the top level catch all is used.

Coverage remained the same at 100.0% when pulling 19e3f38dbb3e241e2425e6e02a155cedccaa5f27 on icyJoseph:fix-catch-all-route-priority into db4045d9cb5f120b660d6da5588fc3e663443600 on toomuchdesign:master.

Thanks for this @icyJoseph 👍
Q: Was there a problem with adding a simple test fixture for the case you've also described in your issue? We can ignore custom _document, _app,... but I guess we would still like to have that covered.

Thanks for this @icyJoseph
Q: Was there a problem with adding a simple test fixture for the case you've also described in your issue? We can ignore custom _document, _app edge cases, and just focus the test on making sure it takes the correct page.

Not really. I just wanted to confirm that we could ignore _document, _app and 404 for instance, and just focus on this particular case.
I'll get on it!

I have implemented a couple of tests. I wonder if some documentation needs to be updated?

Hi @icyJoseph, hi @Meemaw,
thanks for the blazing job here! I'm totally up for reusing getSortedRoutes from Next.js
I have 2 points I'd like to hear your feedback about
Refactoring route matching
I understand that getSortedRoutes sorts routes matching order even before knowing which route we're actually using. If so I guess we might refactor a few lines in getRouteInfo. Would  it make sense?
Instead of processing every existing route, generating a routeInfo object for every matching route, filtering and sorting, we might loop over pagePath and return with a routeInfo object as soon as we have a matching path. (since I understand getSortedRoutes should ensure that the first matching path is the route to match, right).
If this makes sense, we might also get rid of paramsNumber prop evaluation and type definition.
Tests
I see that routing-top-catch-all tests replicate quite a lot of test cases already declared in existing routing tests (in their own file pointing to their). I'm definitely missing a lot of context, but I was wondering whether we could be able to shrink down these tests to the minimum necessary. The amount of tests supporting this library is quite extensive, and I think we should thrive to keep them down to a manageable number.
Shall we move routing-top-catch-all tests into routing tests folder? Since they need their own pages folder is it maybe better not to move them?

Hi @icyJoseph, hi @Meemaw,
thanks for the blazing job here! I'm totally up for reusing getSortedRoutes from Next.js
I have 2 points I'd like to hear your feedback about
Refactoring route matching
I understand that getSortedRoutes sorts routes matching order even before knowing which route we're actually using. If so I guess we might refactor a few lines in getRouteInfo. Would it make sense?
Instead of processing every existing route, generating a routeInfo object for every matching route, filtering and sorting, we might loop over pagePath array and return with a routeInfo object as soon as we have a matching path. (since I understand getSortedRoutes should ensure that the first matching path is the right match, right?)
If this makes sense, we might also get rid of paramsNumber prop evaluation and type definition.

This is actually a good take. I was thinking of introducing getSortedRoutes with minimal impact on the code base, but I reckon that getSortedRoutes renders the paramsNumber approach unnecessary. I could take this one.

Tests
I see that routing-top-catch-all tests replicate quite a lot of test cases already declared in existing routing tests (in their own file pointing to their). I'm definitely missing a lot of context, but I was wondering whether we could be able to shrink down these tests to the minimum necessary. The amount of tests supporting this library is quite extensive, and I think we should thrive to keep them down to a manageable number.
Shall we move routing-top-catch-all tests into routing tests folder? Since they need their own pages folder is it maybe better not to move them?

I would argue that you already have good enough tests as it is.
The root issue was a situation where a top catch all is chosen over a sub catch all. This is rather an edge case, which ends up catching other routes as well. I added the tests on a separate directory to avoid polluting the rest of tests.
I will go through it once again, and try to narrow down the edge case furthermore, to basically two entries, one where the sub catch all is rendered, and one where the catch all kicks in.

Thanks @icyJoseph! Feel free to ping me if you need any support/advice 👍


[apache#1151] | [Enhancement] Extraction of constants to runtime module http processor directory

Motivation
[Enhancement] Extraction of constants to runtime module http processor directory .
Documentation
Does this pull request introduce a new feature? (yes / no) No

@Saranpjs727 It would be better to submit less code per PR, you can submit several PRs for this.

@Saranpjs727 and each PR links to a new issue that you might need to create

@Saranpjs727 and each PR links to a new issue that you might need to create

sure @qqeasonchen will do that

@Saranpjs727 do you need any help?

@qqeasonchen removed some codes that are not covered under this issue. Can u check and give comments.


[REEF-348] Job localization error caused by incorrect timestamp on HDInsight

This addressed the issue by:
* Always updating to the latest version of the global JAR LocalResource.
* Logging a warning when the LocalResource timestamp has changed.
JIRA: REEF-348

This looks good. I will merge it.


[Merge] Don't retry block execution on SYNCING/ACCEPTED response

Description
We should retry if the EL is unavailable or returns an error, but not if it returns SYNCING or ACCEPTED.  With #5370 we know we'll always send another request so we will find out if the EL has finished syncing.

Current code is fine - we only retry import one syncing if the block wasn't safe to import optimistically which is what we want.


ToTestTests.cs:274-276: Make TheSameObjectDetection test...

The puzzle 60m-ac170357 from #60m has to be resolved:
https://github.com/DenisZhukovski/ObjectToTest/blob/213e07f0bb93b65c457a042f5fb2b9f73d032413/tests/ObjectToTest.UnitTests/ToTestTests.cs#L274-L276
The puzzle was created by @DenisZhukovski on 26-Aug-22.
role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

@0pdd 2 puzzles #18, #19 are still not solved.

@0pdd 4 puzzles #18, #21, #22, #23 are still not solved; solved: #19.

@0pdd 3 puzzles #18, #21, #25 are still not solved; solved: #19, #22, #23.

@0pdd 2 puzzles #21, #25 are still not solved; solved: #18, #19, #22, #23.

@0pdd the puzzle #21 is still not solved; solved: #18, #19, #22, #23, #25.

@0pdd all 6 puzzles are solved here: #18, #19, #21, #22, #23, #25.


SPFX graph api error

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
None
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[ ] 💥 Microsoft Edge
[ ] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[X] mobile (iOS/iPadOS)
[X] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details

browser version
SPFx version
Node.js version
etc

Describe the bug / error
Hi,
We get this error again now AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password.
and sometimes missing refresh token
This usually occurs when we use aadTokenProviderFactory
const provider = await context.aadTokenProviderFactory.getTokenProvider();
const accessTokenValue: string = await provider.getToken(
"api://" + appid
);
const body: string = JSON.stringify({
id_token: accessTokenValue,
});
Steps to reproduce
Open teams, viva connections, sharepoint page and then we get this error when we open a webpart with this code
Expected behavior
it should make silent request for token

Hi @harshdamaniahd .  What are you using to access SharePoint?  Are you using the mobile apps when receiving this error?  Or are you using the a browser and accessing SharePoint via URL?

Thanks for the response.  Unfortunately, I have one more question.  Is this a 3rd party app or are you actually using Viva Connections?

And when I say 3rd party app, I mean a custom teams app that somebody other than Microsoft built

No its not a third party app. I have created a normal spfx solution . This
solution is added to sharepoint page. From the resources tab next to
dashboard and feed, I access that sharepoint page which has the web part.
It works when I login in browser  to https://test.sharepoint.col and then
come back to teams. But IT security has created a conditional access policy
that prevents users from opening in browser  https://test.sharepoint.com. I
know this issue has been there for a while. Do I need to upgrade to
something else?
On Mon, 8 May 2023 at 5:04 PM, Graham McMynn @.***>
wrote:

Thanks for the response. Unfortunately, I have one more question. Is this
a 3rd party app or are you actually using Viva Connections?
—
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/sp-dev-docs/issues/8951#issuecomment-1538510178,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACZ4C6ISI7LKWZED72L2HNTXFEDODANCNFSM6AAAAAAXZVTKUI
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Thanks,
Harsh Damania

By any chance could you send me your teams app manifest?

Yes sending now
On Mon, 8 May 2023 at 5:16 PM, Graham McMynn @.***>
wrote:

By any chance could you send me your teams app manifest?
—
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/sp-dev-docs/issues/8951#issuecomment-1538543801,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACZ4C6INSZK5DBMEO753YOLXFEE43ANCNFSM6AAAAAAXZVTKUI
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Thanks,
Harsh Damania

By any chance could you send me your teams app manifest?

{
    "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.16/MicrosoftTeams.schema.json",
    "version": "2.0.0",
    "manifestVersion": "1.16",
    "id": "63a6d548-b833-42ee-9b09-b2496fef7b5c",
    "packageName": "com.package.PIChat",
    "name": {
        "short": "PI",
        "full": "officetest "
    },
    "developer": {
        "name": "officetest Norge AS",
        "mpnId": "",
        "websiteUrl": "https://officetestnorge.sharepoint.com/",
        "privacyUrl": "https://officetestnorge.sharepoint.com/",
        "termsOfUseUrl": "https://officetestnorge.sharepoint.com/"
    },
    "description": {
        "short": "officetest Internal Chatbot",
        "full": "officetest Internal Chatbot"
    },
    "icons": {
        "outline": "outline.png",
        "color": "color.png"
    },
    "accentColor": "#FFFFFF",
    "staticTabs": [
        {
            "entityId": "b9e4ce8e-d43d-4e30-8d74-47aebd28b859",
            "name": "Chatbot",

            "contentUrl": "https://{teamSiteDomain}/_layouts/15/TeamsLogon.aspx?SPFX=true&dest=/_layouts/15/teamshostedapp.aspx%3Fteams%26personal%26componentId=888dcf7c-44f0-4928-b357-e9be31490172%26forceLocale={locale}",
            "websiteUrl": "https://officetestnorge.sharepoint.com/",
            "scopes": [
                "personal"
            ]
        },
        {
            "entityId": "about",
            "scopes": [
                "personal"
            ]
        }
    ],
    "validDomains": [
        "{teamsitedomain}",

            "*.login.microsoftonline.com",
            "*.sharepoint.com",
            "*.sharepoint-df.com",
            "spoppe-a.akamaihd.net",
            "spoprod-a.akamaihd.net",
            "resourceseng.blob.core.windows.net",
            "msft.spoppe.com"

    ],
    "webApplicationInfo": {
        "resource": "https://{teamSiteDomain}",
    "id": "00000003-0000-0ff1-ce00-000000000000"
    },
    "authorization": {
        "permissions": {
            "orgWide": [],
            "resourceSpecific": []
        }
    }
}

Thanks for sending that.  Everything actually looks correct and this should be working.  I'll see if I can pull any useful logs on that tenant.

Thanks for sending that.  Everything actually looks correct and this should be working.  I'll see if I can pull any useful logs on that tenant.

My tenant?

I just reached out on email.


worldCoors & headSize link failed

Hello, i want to reproduce your code. But worldCoors.mat & headSize.mat link failed.

same issue

Hi, sorry I am no longer maintaining this repo and will be soon disabling it


Edited Deploy Doc

Updated deploy doc

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 38.367%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
344

Relevant Lines:
688

💛  - Coveralls


⚠ Quirk Club Argentina (API endpoint) has degraded performance

In ee88125, Quirk Club Argentina (API endpoint) (https://us-central1-quirkclub-dev.cloudfunctions.net/api/check/api) experienced degraded performance:

HTTP code: 200
Response time: 8795 ms

Resolved: Quirk Club Argentina (API endpoint) performance has improved in aaa92a0.


Mobile only slidebars with bootstrap below 992px

I would like to have my normal bootstrap navbar (streched) and a offcanvas slidebar below 992 pixels Can anyone help me out here

You would probably have to create your own CSS and JS for this. Slidebars only handles the animation and basic positioning.


Walled template causes overhead tiles to appear under tokens

I am not sure what is causing this issue, but when I turn off the Walled Template module, the problem disappears. While Walled Templates is active in my world, overhead tiles are rendered underneath tokens.

Testing this on a fresh world, with no other modules active, I see that this issue isn't caused by Walled Templates (alone). The issue shows itself when I activate both the "Walled Templates" and the "Better Roofs" module (and nothing else).
Perhaps you can fix the problem or include an incompatibility warning in the readme.

Correction to my previous comment: There are no other modules (or module-interactions) causing this issue, it is solely caused by Walled Templates. You just need to refresh the page before it becomes visible with tiles you added/edited during the current browser session.

How to test:

Start a fresh world
Enable Walled Templates (and libWrapper)
Edit a tile to be overhead (or add a new tile and make it overhead)
Add a token and put it "under" this overhead tile
Refresh the page
See that the token is now standing on top of the overhead tile

Tested with:

FoundryVTT v11.307
Walled Templates v0.6.6, v0.6.7, and v0.6.8

Thanks for the careful writeup! Fixed in v0.6.9.
(The issue is related to some weirdness in how Foundry v11 treats tile elevation—it is a document property but not really. Walled Templates doesn't need to mess with tile elevation, but for compatibility with Elevated Vision it shares some code that I tweaked to hopefully fix the issue.)


Update queues status to no longer in beta

Existing documentation URL(s)

https://developers.cloudflare.com/workers/wrangler/commands/#queues

What changes are you suggesting?
queues is now in GA (https://github.com/cloudflare/workers-sdk/pull/6840). the beta indication should be removed.
Additional information
No response

Done in https://github.com/cloudflare/cloudflare-docs/pull/17180


[Bug]: mambaforge doesn't actually install

Prerequisites

[X] I have written a descriptive issue title.
[X] I have searched all issues/PRs to ensure it has not already been reported or fixed.
[X] I have verified that I am using the latest version of Scoop and corresponding bucket.

Package Name
mambaforge
Expected/Current Behaviour
I was trying to install mambaforge using scoop. Although the installation was "successful", it didn't actually install anything. I checked the installation directory and there was only install.json, manifest.json and the linked envs folder. The installation proceeded very quickly leading me to wonder if the installer wasn't executed properly.
Steps to Reproduce
~ ❯ scoop install mambaforge
Installing 'mambaforge' (22.11.1-4) [64bit] from extras bucket
Loading Mambaforge-22.11.1-4-Windows-x86_64.exe from cache.
Checking hash of Mambaforge-22.11.1-4-Windows-x86_64.exe ... ok.
Running installer script...
Linking ~\scoop\apps\mambaforge\current => ~\scoop\apps\mambaforge\22.11.1-4
Creating shim for 'python'.
Creating shim for 'pythonw'.
Creating shim for 'python3'.
Persisting envs
'mambaforge' (22.11.1-4) was installed successfully!
Notes
-----
From 4.6.0, conda has built the support for Cmd, Powershell or other shells.
Use "conda init powershell" or "conda init __your_favorite_shell__"
~ ❯ conda
&: The term 'C:\Users\Kazuma\scoop\apps\miniconda3\current\Scripts\conda.exe' is not recognized as a name of a cmdlet,
function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that
the path is correct and try again.

Possible Solution
No clue, but maybe the installer commands needs to be changed
Scoop and Buckets Version
Current Scoop version:
v0.3.1 - Released at 2022-11-15

'extras' bucket:
43a355fe1 (HEAD -> master, origin/master, origin/HEAD) jadx: Update to version 1.4.6

'games' bucket:
2b97d5ad (HEAD -> master, origin/master, origin/HEAD) yuzu: Update to version 0-1346

'java' bucket:
f968267c (HEAD -> master, origin/master, origin/HEAD) temurin19-nightly-jdk: Update to version 19.0.2-7.0.202302180839

'main' bucket:
6c3b434cb (HEAD -> master, origin/master, origin/HEAD) wasmtime: Update to version 6.0.0

'nirsoft' bucket:
28db834 (HEAD -> master, origin/master, origin/HEAD) Excluded two pad files that require a password. They need to be updated manually.

'nonportable' bucket:
076de59 (HEAD -> master, origin/master, origin/HEAD) mullvadvpn-np: Update to version 2023.1

'versions' bucket:
1ea34dd7f (HEAD -> master, origin/master, origin/HEAD) ipfilter-nightly: Update to version<PHONE_NUMBER>

Scoop Config
last_update                     : 2/20/2023 10:38:43 AM
aria2-warning-enabled           : False
aria2-split                     : 10
aria2-max-connection-per-server : 10
scoop_repo                      : https://github.com/ScoopInstaller/Scoop
scoop_branch                    : master

PowerShell Version
Name                           Value
----                           -----
PSVersion                      7.3.2
PSEdition                      Core
GitCommitId                    7.3.2
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Additional Softwares
At the time of installation there was miniconda3 installed (also using Scoop). I tried again after uninstalling miniconda3 but nothing changed.

I ran the installer script manually and it installed conda without issues. The only thing stopping it would be the target directory must be empty prior to installation, which I assume was the case

#10498 #10420


[C++] Improve FlattenRecursively by making it materialize fewer intermediate array values

Describe the enhancement requested
Improve FlattenRecursively by making it materialize fewer intermediate array values
This function is used to flatten a multi-level nested logical list Arrays.
There are multiple ways to batch the copying of data of deeply-nested lists without allocating a new Array per level.
For instance, if you are flattening a fixed_size_list<fixed_size_list<int32>, 2>, 3> without bitmaps on the internal arrays of values, you can gather blocks containing 2 * 3 32-bit integers from the innermost values array to a pre-allocated destination ArrayData.
Comes from : https://github.com/apache/arrow/pull/41092#discussion_r1558121668
Component(s)
C++

In this task, we can also add a micro-benchmark to ensure that our subsequent optimization is effective.


Longtail out of TC swaps

feature flag specifically just for this segment of longtail (vs long tail in)
Native TC supported asset to long tail erc20
custom memo to send into uniswap pool
lots of testing
make sure we have slippage controls going into thorchain and uniswap
confirm mixpanel tracking working for these trades

Notes for the implementor
In src/lib/swapper/swappers/ThorchainSwapper/getThorTradeQuote/getTradeQuote.ts we have a switch on tradeType.
We have logic to determine the trade type of the requested quote (LongTailToLongTail etc), though have so far only implemented logic for the L1ToL1 (basic THORChain to THORChain assets) and LongTailToL1 (non THORChain L1 to THORChain L1).
switch (tradeType) {
  case TradeType.L1ToL1:
    return getL1quote(input, streamingInterval, tradeType)
  case TradeType.LongTailToL1:
    return getLongtailToL1Quote(input, streamingInterval, assetsById)
  case TradeType.LongTailToLongTail:
  case TradeType.L1ToLongTail:
    return Err(makeSwapErrorRight({ message: 'Not implemented yet' }))
  default:
    assertUnreachable(tradeType)
}

We've implemented the the logic for the swapIn side, next we want to do the swapOut call to allow trades from an L1 to a longtail asset: https://dev.thorchain.org/aggregators/aggregator-overview.html#swapout
To do this we'll want to add a new getL1ToLongtailQuote function that is called in the switch statement above.
Useful reading

Marketing: https://docs.thorswap.finance/thorswap/thorswap/cross-chain-dex-aggregation
Dev docs: https://dev.thorchain.org/aggregators/aggregator-overview.html
Memo logic: https://gitlab.com/thorchain/thornode/-/merge_requests/2218


Container: component updates

Acceptance Criteria:

Undocument the following types: (deprecate these types [console log message])

Info
Error
Success
Important

Undocument the following "accent": (deprecate this type [console log message])

Filled

Add the following "accent"

none (default accent option) - removes the accent bar, fills in the background colour for non-interactive only (background color is only for non-interactive, interactive remains white)

Visual treatments of other non-interactive containers will remain the same

@Spark450 @twjeffery Need to discuss how to handle the default option. If we're deprecating "filled" and making the new default "none" for accent type, that would be a breaking change.


[build_dashboard] fetchCommitStatuses takes in a range

Right now, it loads the latest 100 commits. The backend will have to be updated to allow for this.

Removing myself as commented in: https://github.com/flutter/cocoon/pull/622#discussion_r366558647

https://github.com/flutter/cocoon/pull/617 updates the retrieval code for Tasks to be configurable for how many tasks we want to load as different actions require different amounts of endpoints.


Database schema design

Create relationships

User
Post
Categories
Tags
Comments

Here is the link  to our database schema diagram  @otsembo

Here is the figmalink to our blog site @otsembo


even simpler PatternMatcher gc test

This is because the gc doesn't cleanup pdict after rewrite.
When DEFINE_GLBOAL arg is Buffer, it'll hold on to that Buffer forever.

Why delete the others? Merge this?

meh, I like the old one, it's more comprehensive.


sdk: updated web3-js.md

Proposed changes

Fixed minor typos and codes to run web3-js tutorial

Types of changes
Please put an x in the boxes related to your change.

[x] Minor Issues and Typos
[ ] Major Content Contribution
[ ] Others

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to reach out. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING GUIDELINES
[x] I have signed the CLA
[x] I have added necessary documentation (if appropriate)
[x] Any dependent changes have been merged and published in downstream modules

Related issues

Please leave the issue numbers or links related to this PR here.

Further comments
If this is a relatively large content contribution, kick off the discussion by explaining why you would suggest the content contribution, etc...

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

recheck

@ayo-klaytn Please take a look.