Shared and Published icons have unnecessary background if to navigate thru context menu; in Select conversation drop down list

Need to fix the follwing issues:

If to open Select conversation drop down list and hover over the mouse like on the screenshot (below chat name) the background is incorrect

If to navigate thru chat context menu

Verified on staging successfully


[Question] How can you guys find out about these APIs

I'm just a newbie and i want to learn how to capture these information. Where should i start?
I'm sorry this is not an issue at all

Since I've not done this for valorant ever, but generally there're 2 ways.
Either you reverse engineer the valorant client or capture packets using tools like wireshark.
According to this repo's document, the payload is not supposed to be encrypted so I guess either way will work.
but for X-Riot-ClientVersion header and stuff you may need to reverse engineer the client to see where it extracts data from.


Extended social links list with Stack Overflow

Added yet another (optional) link to social portal: Stack Overflow. Redirects right to the profile page.

Feel free to add this to your own site but I'm leaving the current links for the theme as is. Thanks!

@joshgerdes I did and thought it may be useful, but ok :)


[Swift 4.2] Update Quad Tree

Checklist

[x] I've looked at the contribution guidelines.
[x] This pull request is complete and ready for review.

Description
No migration needed for Quad Tree.
PR related to #748

Thanks for the update!


TI sensor tag doesn't work

Nice project! I love it! But if I use your example flow with the TI sensortag, I get the following output.

16.11.2017, 09:25:21
msg : string[59]
"[GenericBLE] <247189cc6684> Characteristic(2a19) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa0104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa2104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa4104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa8104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa7104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[59]
"[GenericBLE] <247189cc6684> Characteristic(ffe1) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ccc104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ffc104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ffc204514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ffc404514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[59]
"[GenericBLE] <247189cc6684> Characteristic(2a19) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa0104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa2104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa4104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa8104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000aa7104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[59]
"[GenericBLE] <247189cc6684> Characteristic(ffe1) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ccc104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ffc104514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ffc204514000b000000000000000) is missing"
16.11.2017, 09:25:21
msg : string[87]
"[GenericBLE] <247189cc6684> Characteristic(f000ffc404514000b000000000000000) is missing"

I find the tag in the Generic BLE input and I get all GATT Characteristics. All custom type looks like this:

<Unnamed> (f000aa8104514000b000000000000000)ReadNotify
(Custom Type)

But I think it is okay.
Under the Generic BLE Input the state switches every 3 - 5 seconds from connected to disconnected and again to connected.
I have "Selected from scan result" used to add the sensortag.
The tag works fine with the node-red-node-sensortag package, but I need custom functionalities, where I need your package.
Thank you.

This is an additional error:

16.11.2017, 09:50:31
msg : string[73]
string[73]
/__bledev/54:6c:0e:53:16:13 <546c0e531613> Connection Timeout
=>undefined

Thanks for the report. Unfortunately, I don't have a TI Sensor Tag device so I need to purchase one to look into the issue. Which model do you have?

CC2650STK
CC2541 SensorTag(seems to be obsolete)

Thank you. I use the CC2650STK. I'm new with node red, but perhaps I can help you!? I'm confirm with BLE and some programming languages, Javascript as well.

Good to hear that! I'll ask you some help.
I purchased the device but it takes a couple of days to ship it, just moment for further progress.

@SeanStayn can you please try develop.zip? Unzip it and you can get node-red-contrib-generic-ble-1.0.3.tgz.
cd ~/.node-red
npm uninstall node-red-contrib-generic-ble
npm cache clean
npm install path/to/node-red-contrib-generic-ble-1.0.3.tgz

Replace path/to/ with a path to the unzipped file.
I tested this version with CC2650STK. Fixed some issues and add new features. Let me know if it works.

@SeanStayn I published a new release including the above fix and some improvements. Try v2.0.0 rather than the attached zip file. File a new ticket if you get stuck with the latest version.


Feature/auth

Codecov Report

Merging #15 into develop will decrease coverage by 1.53%.
The diff coverage is 91.3%.

@@             Coverage Diff             @@
##           develop      #15      +/-   ##
===========================================
- Coverage       93%   91.46%   -1.54%
===========================================
  Files            4        6       +2
  Lines          143      211      +68
  Branches        50       70      +20
===========================================
+ Hits           133      193      +60
- Misses          10       15       +5
- Partials         0        3       +3

Impacted Files
Coverage Δ

src/Storage.js
100% <100%> (ø)

src/Credentials.js
87.71% <100%> (-2.85%)
:arrow_down:

src/AuthCredentials.js
83.78% <83.78%> (ø)

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 75010fe...f977370. Read the comment docs.

thanks for the review @pelle. Going to add additional details/simplify the storage layer, change functionality to assume the response is passed to the browser, change minor things to align with mobile (challenge -> chl, etc), and confirm the examples work with mobile

@pelle this is not the same response storage as before, earlier I had wrapped up the developer's server responses into some of the other functionality, which now has been removed (this is definitely better now). The response storage is just for our response from mobile, they are now separated from other functionality and are in  there own functions which you can choose to use or not. They simply serve the same purpose as the messaging server and were added to simplify having to explain that, so they are just light, completely optional functions to wrap some of that up. We already added this storage layer for challenges, it would be nice to use that to also provide the simply wrappers to set of the same functionality as the messaging server. It also helps to align with the implementation in uport-connect. In both libraries they are just one way to handle this flow which we provide by default, but in both libs they are entirely optional and we added the base parts that allow developers to implement  it how ever they please instead of using this default functionality.


[PE-D] Medical History truncated to "..." when involvement is long

The "..." is not useful and could be potentially misleading if teachers assume the student does not have medical history. If the purple tag is not meant to display the history perhaps it can be replaced with an icon or an exclamation mark and users will have to open the medical window to access the history.

Labels: type.FeatureFlaw severity.Low
original: neojxuan/ped#3

Done and fixed


update figma diagram

Update execution flow diagram
Signed-off-by: Smriti S<EMAIL_ADDRESS>

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


Everytime I exit a world the game infinitely tries to save

It stays like that forever, I've changed the priority to 5 but didn't work either. My computer screams alot when it's in this saving mode too, my air coolers go crazy.
 from the client.
[09:25:19] [Render thread/INFO]: Stopping worker threads
[09:25:19] [Render thread/ERROR]: Signature is missing from Property textures
[09:25:19] [Server thread/INFO]: o_oo___ooo_ lost connection: Desconectado
[09:25:19] [Server thread/INFO]: o_oo___ooo_ saiu da partida
[09:25:19] [Server thread/INFO]: [voicechat] Disconnecting client o_oo___ooo_
[09:25:19] [Server thread/INFO]: Stopping singleplayer server as player logged out
[09:25:19] [Server thread/INFO]: [voicechat] Disconnecting client zetrakore
[09:25:20] [Server thread/INFO]: Stopping server
[09:25:20] [Server thread/INFO]: Saving players
[09:25:20] [Server thread/INFO]: Saving worlds
[09:25:20] [Render thread/INFO]: Stopping!
[09:25:20] [Render thread/INFO]: [FastQuit] Exiting FastQuit.
[09:25:20] [Render thread/INFO]: [FastQuit] Waiting for "???" to finish saving...
[09:25:20] [CullThread/INFO]: [STDOUT]: Shutting down culling task!
[09:25:50] [netty<-quic (b7aed8f5-b435-4592-b2d0-6d1c9ef8a164)/INFO]: Closing.
[09:25:50] [Netty Server IO ICE #2/INFO]: b7aed8f5-b435-4592-b2d0-6d1c9ef8a164 channel inactive, closing.
[09:25:50] [netty->quic (b7aed8f5-b435-4592-b2d0-6d1c9ef8a164)/INFO]: Closing.
[09:25:50] [Netty Server IO ICE #2/INFO]: b7aed8f5-b435-4592-b2d0-6d1c9ef8a164 closing QUIC.
[09:25:50] [Netty Server IO ICE #2/INFO]: b7aed8f5-b435-4592-b2d0-6d1c9ef8a164 closed.
[09:25:55] [Essential Thread 2/INFO]: Closing.
The process ended with code 1.

I found the problem!
Concurrent Chunk Management Engine (or know as C2ME) is causing it.

i tried to reproduce it with just

c2me 0.2.0+alpha.10.100
cloth-config 11.0.99
fabric-api 0.84.0+1.20.1
fastquit 3.0.0+1.20+
modmenu 7.1.0

but its working just fine for me, could you maybe send your config file for c2me?
also just looking at the lines of log you sent it seems like the server simply never finishes saving chunks (which on the other hand makes fastquit wait infinitely for the server to be done saving after the client crashes)


Azure Front Door (Premium tier) Private Link support

In this page it is indicated that the premium tier of Azure Front Door supports Private Link. This is bit confusing. It would be good to clarify that this is applicable only for connections to backend/origin. Azure Front Door service itself is internet-facing regardless of the tiers.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: ac400994-c165-34e4-7050-04ab6ed90b1e
Version Independent ID: 796aa577-8a6b-096b-3c6c-77fef7518219
Content: Azure Front Door tier comparison
Content Source: articles/frontdoor/standard-premium/tier-comparison.md
Service: frontdoor
GitHub Login: @duongau
Microsoft Alias: duau

@nelsonpv
Thank you for your feedback! We will review and update as appropriate.

@nelsonpv
Thank you for your feedback. I have made a PR to address this issue and it is currently under doc author's review. We will work with the author in order to merge the PR.

Thanks for the update !


Port divide-by-constant magic number optimizations from simple_preopt to ISLE mid-end

This is the old simple preopt stuff for some number divided/remaindered by a non-power-of-two constant:

https://github.com/bytecodealliance/wasmtime/blob/main/cranelift/codegen/src/divconst_magic_numbers.rs#L41-L217

https://github.com/bytecodealliance/wasmtime/blob/main/cranelift/codegen/src/simple_preopt.rs#L206-L243

The ISLE + e-graphs mid-end work replaced simple_preopt, but never ported these magic constants over. We should port them over.
HOWEVER, right now we can't replace potentially-trapping instructions in ISLE, and we need that ability to do this.

Specifically, this depends on #5908.


Loading binary image sementation mask as prior: MethodError: no method matching sparse

Hi,
First of all, thanks for making Baysor, its amazing! Baysor works for me without prior segmentation, but when I add a binary image with a segmentation mask (Black background, cell segmentation = red) as a prior (in tif. format), I get the following error:
Info: Excluding genes:
Info: Loaded 8329256 transcripts
Info: Loading segmentation mask...
ERROR: LoadError: MethodError: no method matching sparse(::MappedArrays.MappedArray{UInt8, 3, Base.ReinterpretArray{FixedPointNumbers.N0f8, 3, ColorTypes.RGBA{FixedPointNumbers.N0f8}, Matrix{ColorTypes.RGBA{FixedPointNumbers.N0f8}}, true}, typeof(reinterpret), ImageCore.var"#39#40"{FixedPointNumbers.N0f8}})
Closest candidates are:
sparse(::Any, !Matched::Any, !Matched::Number, !Matched::Any, !Matched::Any, !Matched::Function)
@ SparseArrays ~/.julia/juliaup/julia-1.10.2+0.x64.linux.gnu/share/julia/stdlib/v1.10/SparseArrays/src/sparsematrix.jl:1322
sparse(::Any, !Matched::Any, !Matched::AbstractVector{Bool}, !Matched::Any, !Matched::Any)
@ SparseArrays ~/.julia/juliaup/julia-1.10.2+0.x64.linux.gnu/share/julia/stdlib/v1.10/SparseArrays/src/sparsematrix.jl:1320
sparse(::Any, !Matched::Any, !Matched::AbstractVector, !Matched::Any, !Matched::Any)
@ SparseArrays ~/.julia/juliaup/julia-1.10.2+0.x64.linux.gnu/share/julia/stdlib/v1.10/SparseArrays/src/sparsematrix.jl:1318`
It seems like there is no method matching sparse. Did u encounter this issue before?
Many thanks :)

I'm having the same issue when I add a tif file as my prior segmentation. Were you able to find a workaround?

Apologies for the late reply.  Would the error persist if you flatten the image to a single binary channel?


Cargo panic in ResolvedFeatures::activated_features_int with unstable bindeps feature

Problem
While experimenting with using the unstable bindeps feature, I stumbled upon a panic. Here's a repo with a minimized failing case: https://github.com/phlip9/cargo-bindep-panic. Simply clone it and run a cargo command like cargo build or cargo tree to see the panic.
In plain english, we have a crate, will-get-bindeped, that's targetting some other arch like wasm or x86_64-fortanix-unknown-sgx in our case. At the root is a crate, top-level-that-depends-on-bindep, that wants to depend on the built binary of will-get-bindeped (hence the bindeps feature).
This binary, will-get-bindeped, depends on dep-that-depends-on-build-only-dep that has a build-time dependency. This build-only-dep represents something like protoc-rust that needs to run on the host and compile some .proto's or w/e.
build-only-dep has a cfg(unix) (this seems important!) on some-leaf-dep. If some-leaf-dep is just an unconditional dependency or even a cfg(windows), the panic no longer triggers.
Visually, the crate graph looks like:
top-level-that-depends-on-bindep
  |
  | [dependencies] artifact = "bin", target = "x86_64-fortanix-unknown-sgx"
  |     - or -
  | [build-dependencies] artifact = "bin", target = "x86_64-fortanix-unknown-sgx"
  V
will-get-bindeped
  |
  | [dependencies]
  V
dep-that-depends-on-build-only-dep
  |
  | [build-dependencies]
  V
build-only-dep
  |
  | [target.'cfg(unix)'.dependencies]
  V
some-leaf-dep

Steps
$ git clone https://github.com/phlip9/cargo-bindep-panic
$ cd cargo-bindep-panic
$ RUST_BACKTRACE=1 cargo check

thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "some-leaf-dep", version: "0.1.0", source: "/Users/phlip9/dev/cargo-bindep-panic/some-leaf-dep" } ArtifactDep(CompileTarget { name: "x86_64-fortanix-unknown-sgx" })

Stack backtrace:
   0: std::backtrace::Backtrace::create
   1: <anyhow::Error>::msg::<alloc::string::String>
   2: <cargo::core::resolver::features::ResolvedFeatures>::activated_features_int
   3: cargo::core::compiler::unit_dependencies::new_unit_dep_with_profile
   4: cargo::core::compiler::unit_dependencies::compute_deps
   5: cargo::core::compiler::unit_dependencies::deps_of
   6: cargo::core::compiler::unit_dependencies::deps_of
   7: cargo::core::compiler::unit_dependencies::deps_of
   8: cargo::core::compiler::unit_dependencies::deps_of
   9: cargo::core::compiler::unit_dependencies::deps_of
  10: cargo::core::compiler::unit_dependencies::deps_of
  11: cargo::core::compiler::unit_dependencies::deps_of
  12: cargo::core::compiler::unit_dependencies::deps_of_roots
  13: cargo::core::compiler::unit_dependencies::build_unit_dependencies
  14: cargo::ops::cargo_compile::create_bcx
  15: cargo::ops::cargo_compile::compile_ws
  16: cargo::ops::cargo_compile::compile
  17: cargo::commands::check::exec
  18: cargo::cli::main
  19: cargo::main
  20: std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
  21: std::rt::lang_start::<()>::{closure#0}
  22: std::rt::lang_start_internal
  23: _main', src/cargo/core/resolver/features.rs:322:14

Other cargo commands also fail immediately:
$ RUST_BACKTRACE=1 cargo tree
thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "will-get-bindeped", version: "0.1.0", source: "/Users/phlip9/dev/cargo-bindep-panic/will-get-bindeped" } HostDep

Stack backtrace:
   0: std::backtrace::Backtrace::create
   1: <anyhow::Error>::msg::<alloc::string::String>
   2: <cargo::core::resolver::features::ResolvedFeatures>::activated_features_int
   3: cargo::ops::tree::graph::add_pkg
   4: cargo::ops::tree::graph::add_pkg
   5: cargo::ops::tree::graph::build
   6: cargo::ops::tree::build_and_print
   7: cargo::commands::tree::exec
   8: cargo::cli::main
   9: cargo::main
  10: std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
  11: std::rt::lang_start::<()>::{closure#0}
  12: std::rt::lang_start_internal
  13: _main', src/cargo/core/resolver/features.rs:322:14

Possible Solution(s)
No response
Notes
No response
Version
$ cargo version --verbose

cargo 1.73.0-nightly (45782b6b8 2023-07-05)
release: 1.73.0-nightly
commit-hash: 45782b6b8afd1da042d45c2daeec9c0744f72cc7
commit-date: 2023-07-05
host: aarch64-apple-darwin
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 7.88.1 (sys:0.4.63+curl-8.1.2 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Mac OS 13.4.1 [64-bit]

Thanks for the report! Does it share the same root cause with https://github.com/rust-lang/cargo/issues/10593? Looks a bit similar.

Definitely looks similar... One weird thing I'm also noticing:
If we make some-leaf-dep unconditional
[package]
name = "build-only-dep"
version = "0.1.0"
edition = "2021"

# [target.'cfg(unix)'.dependencies] # << turn this off

[dependencies] # << make this a normal dependency
some-leaf-dep = { path = "../some-leaf-dep" }

Then something like cargo check will work (!) but cargo tree will still panic (?!):
$ cargo check
   Compiling some-leaf-dep v0.1.0
    Checking build-only-dep v0.1.0
   Compiling dep-that-depends-on-build-only-dep v0.1.0
    Checking will-get-bindeped v0.1.0
   Compiling top-level-that-depends-on-bindep v0.1.0
    Finished dev [unoptimized + debuginfo] target(s) in 0.48s

$ cargo tree

thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "will-get-bindeped", version: "0.1.0", source: "/Users/phlip9/dev/cargo-bindep-panic/will-get-bindeped" } HostDep', src/cargo/core/resolver/features.rs:322:14

The feature resolution path is slightly different between cargo tree and cargo check. That could be the reason. I'll keep this open for cargo check, and #10593 for cargo tree.

In case its helpful for anyone, I turned this excellent reproduction into two integration tests:

Expand...
The first test reproduces the cargo tree issue, its quite easy to hit.
The second test reproduces the cargo check issue, its quite specific to hit.
#[cargo_test]
fn resolver2_bindep_crosscompile() {
    if cross_compile::disabled() {
        return;
    }
    // At least on linux the i686-unknown-linux-gnu target triggered a panic.
    let target = cross_compile::alternate();

    let p = project()
        .file(
            "Cargo.toml",
            &r#"
                [package]
                name = "foo"
                version = "0.0.0"
                authors = []
                resolver = "2"

                [dependencies]
                bindep = { path = "bindep", artifact = "bin", target = "$TARGET" }
            "#
            .replace("$TARGET", target),
        )
        .file("src/lib.rs", "")
        .file("bindep/Cargo.toml", &basic_manifest("bindep", "0.0.0"))
        .file("bindep/src/main.rs", "fn main() {}")
        .build();

    p.cargo("check -Z bindeps")
        .masquerade_as_nightly_cargo(&["bindeps"])
        .with_stderr_contains(
            r#"[COMPILING] bindep v0.0.0 ([CWD]/bindep)
[CHECKING] foo v0.0.0 ([CWD])
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]"#,
        )
        .with_status(0)
        .run();

    p.cargo("tree -Z bindeps")
        .masquerade_as_nightly_cargo(&["bindeps"])
        .with_stdout(
            "\
foo v0.0.0 ([CWD])
└── bindep v0.0.0 ([CWD]/bindep)",
        )
        .with_status(0)
        .run();
}

#[cargo_test]
fn check_bindep_depending_on_build_only_dep_with_optional_dep() {
    if cross_compile::disabled() {
        return;
    }
    // i686-unknown-linux-gnu did not trigger a panic so we need to manually specify wasm32-unknown-unknown instead of relying on cross_compile::alternate()
    // This is possibly because the `cfg(unix)` later on needs to evaluate to false on the cross compile but true on the host.
    let target = "wasm32-unknown-unknown";

    let p = project()
        .file(
            "Cargo.toml",
            &r#"
                [package]
                name = "foo"
                version = "0.0.0"
                authors = []
                resolver = "2"

                [dependencies]
                bindep = { path = "bindep", artifact = "bin", target = "$TARGET" }
            "#
            .replace("$TARGET", target),
        )
        .file("src/lib.rs", "")
        .file(
            "bindep/Cargo.toml",
            &r#"
                [package]
                name = "bindep"
                version = "0.0.0"
                authors = []

                [dependencies]
                depends-on-build-only-dep = { path = "../depends-on-build-only-dep" }
            "#,
        )
        .file("bindep/src/main.rs", "fn main() {}")
        .file(
            "depends-on-build-only-dep/Cargo.toml",
            &r#"
                [package]
                name = "depends-on-build-only-dep"
                version = "0.0.0"
                authors = []

                [build-dependencies]
                build-only-dep = { path = "../build-only-dep" }
            "#,
        )
        .file("depends-on-build-only-dep/src/lib.rs", "")
        .file("depends-on-build-only-dep/build.rs", "fn main() {}")
        .file(
            "build-only-dep/Cargo.toml",
            &r#"
                [package]
                name = "build-only-dep"
                version = "0.0.0"
                authors = []

                [target.'cfg(unix)'.dependencies]
                some-leaf-dep = { path = "../some-leaf-dep" }
            "#,
        )
        .file("build-only-dep/src/lib.rs", "")
        .file(
            "some-leaf-dep/Cargo.toml",
            &basic_manifest("some-leaf-dep", "0.0.1"),
        )
        .file("some-leaf-dep/src/lib.rs", "")
        .build();
    p.cargo("check -Z bindeps")
        .masquerade_as_nightly_cargo(&["bindeps"])
        .with_stderr_contains(
            r#"[COMPILING] bindep v0.0.0 ([CWD]/bindep)
[CHECKING] foo v0.0.0 ([CWD])
[FINISHED] dev [unoptimized + debuginfo] target(s) in [..]"#,
        )
        .with_status(0)
        .run();
}

Managed to trigger this in rust-analyzer by accident as well (without any special targets set afaik), so if it helps, just putting a reproducer here as well: https://github.com/Veykril/rust-analyzer/tree/cargo-panic
❯ cargo check -p proc-macro-test
thread 'main' panicked at src/cargo\core\resolver\features.rs:323:14:
activated_features for invalid package: features did not find PackageId { name: "proc-macro-test", version: "0.0.0", source: "C:\\workspace\\rust\\rust-analyzer\\crates\\proc-macro-
srv\\proc-macro-test" } NormalOrDev
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I have bumped into this problem too, trying to compile a wasm32-unknown-unknown target (Leptos frontend) for embedding into an, e.g. aarch64-apple-darwin binary that serves it up and have had to fall back to calling cargo inside build.rs which is suboptimal for lots of reasons. I'd love to help fixing it but this is way over my head, if there is anything I can do to test or help please let me know.

If we make some-leaf-dep unconditional
[package]
name = "build-only-dep"
version = "0.1.0"
edition = "2021"
# [target.'cfg(unix)'.dependencies] # << turn this off
[dependencies] # << make this a normal dependency
some-leaf-dep = { path = "../some-leaf-dep" }
Then something like cargo check will work (!) but cargo tree will still panic (?!):
$ cargo check
Compiling some-leaf-dep v0.1.0
Checking build-only-dep v0.1.0
Compiling dep-that-depends-on-build-only-dep v0.1.0
Checking will-get-bindeped v0.1.0
Compiling top-level-that-depends-on-bindep v0.1.0
Finished dev [unoptimized + debuginfo] target(s) in 0.48s
$ cargo tree
thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "will-get-bindeped", version: "0.1.0", source: "/Users/phlip9/dev/cargo-bindep-panic/will-get-bindeped" } HostDep', src/cargo/core/resolver/features.rs:322:14

Update on this: Since rustup nightly release 2024-10-17, doing this now causes cargo tree to output:

cargo tree output:
build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/build-only-dep)
└── some-leaf-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/some-leaf-dep)

build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/build-only-dep)
└── some-leaf-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/some-leaf-dep)

dep-that-depends-on-build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/dep-that-depends-on-build-only-dep)
[build-dependencies]
└── build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/build-only-dep) (*)

dep-that-depends-on-build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/dep-that-depends-on-build-only-dep)
[build-dependencies]
└── build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/build-only-dep) (*)

some-leaf-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/some-leaf-dep)

some-leaf-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/some-leaf-dep)

top-level-that-depends-on-bindep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/top-level-that-depends-on-bindep)
[build-dependencies]
└── will-get-bindeped v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/will-get-bindeped)
    └── dep-that-depends-on-build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/dep-that-depends-on-build-only-dep) (*)

will-get-bindeped v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/will-get-bindeped)
└── dep-that-depends-on-build-only-dep v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/dep-that-depends-on-build-only-dep) (*)

will-get-bindeped v0.1.0 (/home/ditto/personal-projects/repros/cargo-bindep-panic/will-get-bindeped) (*)

And if [target.'cfg(unix)'.dependencies] is left as-is, cargo tree works but cargo check throws the same error. It only happens with exactly 'cfg(unix)' —I tried literally every other value in the target_os list.


[Bug][Frontend][ONNX] Failure of test_forward.test_aten unit test after upgrade to PyTorch 1.12.0

As described in the discussion forum thread the test below fails after the upgrade to the PyTorch 1.12.0:
https://github.com/apache/tvm/blob/458ca81c01bd85d04ea6428e7cb4bfa021a1d37a/tests/python/frontend/onnx/test_forward.py#L5471-L5507
The test fails in the line:
https://github.com/apache/tvm/blob/458ca81c01bd85d04ea6428e7cb4bfa021a1d37a/tests/python/frontend/onnx/test_forward.py#L5488
The problem lies due to improper model conversion from PyTorch to ONNX with PyTorch 1.12.0. It looks like that argument below is ignored:
https://github.com/apache/tvm/blob/458ca81c01bd85d04ea6428e7cb4bfa021a1d37a/tests/python/frontend/onnx/test_forward.py#L5485
and ATen PyTorch operators are substituted with native ONNX operators (instead of being exported as ATen ops in ONNX). This behaviour fail an assert above.
I have created an appropriate bug report in the PyTorch repo: https://github.com/pytorch/pytorch/issues/87313
One possible quick solution will be to remove an assert above in _convert_to_onnx function (since the test produces correct results and satisfies all other asserts). However, it will reduce coverage of the test because onnx_model (in the code below) will not contain ATen operators, and the possibility to consume ONNX graph with such operators by TVM will not be tested.
https://github.com/apache/tvm/blob/458ca81c01bd85d04ea6428e7cb4bfa021a1d37a/tests/python/frontend/onnx/test_forward.py#L5497-L5503
Environment

TVM version: v0.10.0rc0 (https://github.com/apache/tvm/commit/82c4addf2f5cdf7ec142cf0378632deb6b9474e1)
OS: macOS 12.6 (arm64)
torch 1.12.0+cpu
torchvision 0.13.0+cpu

Steps to reproduce
With Torch 1.12.0 and Torchvision 0.13.0 environment, run:
python -m pytest tests/python/frontend/onnx/test_forward.py
Triage

frontend:onnx

@masahi FYI

Since "ATen" op in an ONNX graph is never meant to be an official thing, I think it is fine to remove the broken assert. Or disable the test entirely for PT 1.12 and newer.


mergify: Allow merging trivial changes with 1 approval

Update mergify config to allow merges of trivial changes with a single
approval. A trivial change is indicated by a label on the PR -
trivial-change.
Signed-off-by: Russell Bryant<EMAIL_ADDRESS>

So... what exactly constitutes a "trivial change"? :wink:

So... what exactly constitutes a "trivial change"? 😉

Yeah, I know.
I don't remember what the change was where writing this was therapeutic, but the moment has passed. I can just close this now. 😀

So... what exactly constitutes a "trivial change"? 😉

Yeah, I know.
I don't remember what the change was where writing this was therapeutic, but the moment has passed. I can just close this now. 😀

... but this one is another good example! https://github.com/instructlab/instructlab/pull/1177/files


update twigjs to version 1.10.4

@stefanullinger can you merge this PR, please?

The build is failing.

ok I will have a look, sry for the disturbance!

Maybe it will work, when we update the nodejs environment version in the travis.yml file?!

maybe, go with node >= 4 seems to be a good turn

Published in v1.8.1 – thank you!

thank you too ;)


Adding namespace to dynamic args

Closes #90

Adding namespace to mos: closes #91
Adding namespace to qtcs: closes #92
Namespace qtcs is valid for all QTCs but can be overridden for a specific variant: qtcbs,qtccs, or qtcbcs
Adding namespace to argd: closes #93

The example ros client now uses the new namespace format and the correct qsr key, i.e. argd instead of arg_distance, qtcbs instead of qtcb, qtccs instead of qtcc, and qtcbcs instead of qtcbc
The use of no namespace still works but prints a deprecated warning on the server.

QTCS series gives warning even if new correct (with namespace) dynamic_args are used.
I will merge and file a new issue as it is confusing but not a bug.


Add Figure 5 code

Fig. 5. Bright and dark spots of the global range-size rarity-weighted Red List Index of sharks, rays, and chimaeras values across in 2020 at four biogeographic scales
Defintion of Done

[x] Rmarkdown added with code for generating RLI values for each biogeographic scales (hex, EEZ, LME, FAO)
[ ] Adding final figure outputs

New task:

[ ] Organize figure generation code (currently a mess), preferably as a package for replicability


eris-go: 20230914 -> 20231119

Description of changes
Update for async offline transfers.
https://codeberg.org/eris/eris-go/compare/ac7860d...20231119
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Priorities
Add a :+1: reaction to pull requests you find important.

@ofborg build eris-go


CL_MEM_USE_HOST_PTR can result in undefined behaviour

CL_MEM_USE_HOST_PTR is useful for performance but has additional requirements that need to be upheld by the program for it to be used safely. Looking at the example in https://github.com/kenba/opencl3/blob/main/examples/basic.rs, switching x to CL_MEM_USE_HOST_PTR like this will result in an error from OpenCL, which is the best case.
    let mut x = Buffer::<cl_float>::create(
        &context,
        CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR,
        ARRAY_SIZE,
        ptr::null_mut(),
    )?;

The allocation pointed to by the host pointer may be too small, unaligned, or of the wrong type, or just not live long enough. There are also a set of alignment rules that need to be checked for this to be safe. See https://registry.khronos.org/OpenCL/sdk/2.0/docs/man/xhtml/dataTypes.html
    let img = image::open("test.png").unwrap().into_rgba8();
    let format = cl_image_format {
        image_channel_order: CL_RGBA,
        image_channel_data_type: CL_UNSIGNED_INT8,
    };
    let desc = cl_image_desc {
        image_type: CL_MEM_OBJECT_IMAGE2D,
        image_width: img.width() as _,
        image_height: img.height() as _,
        image_depth: 1,
        image_array_size: 1,
        image_row_pitch: 0,
        image_slice_pitch: 0,
        num_mip_levels: 0,
        num_samples: 0,
        buffer: ptr::null_mut(),
    };
    let mut img = img.into_vec();
    let unaligned_image = Image::create(
        &context,
        CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR,
        &format,
        &desc,
        // This does not have the proper alignment and may cause undefined behaviour or not work.
        ptr::addr_of_mut!(img[1]) as _,
    )?;
    // Can drop img and still use _unaligned_image
    drop(img);
    let _still_alive = unaligned_image;

This is an OpenCL issue, it is not a bug that has been introduced by tis library.
Please read and understand the OpenCL manual before trying to use advanced features like CL_MEM_USE_HOST_PTR.

I do understand the OpenCL documentation around CL_MEM_USE_HOST_PTR which is why I was so surprised that this code didn't require unsafe anywhere on my part. I know the bug hasn't been introduced, per se, by this library, but I would expect it to require a use of unsafe somewhere.

@awused is right. Any OpenCL functions that can lead to undefined behaviour in Rust should be declared unsafe in this library.
Note: they should also be declared unsafe in the cl3 library.

Changes published to crates.io.


Make WebRICE.js a webpack library

Now that's is a library, each demo page can have its own theme color without re-building the library from scratch each time.
Also, the modules are accessible outside of WebRICE.js.

Added usage instructions on the README. Is that sufficient until we have developer docs?


[WIP][TerminalClock] Adding fast loading

Not to merge right now cause it currently have a big memory leak.

Does it still have a memory leak? If so and there's not work on this then maybe we should close it

Yep still a memory leak. I am quite busy lately but I think I will take another look in two weeks. If I don't find where it's come from I will ask some help from the community


[Closed Book QA w/ T5] Report performance of other checkpoints ?

Thanks for all the great works on Closed Book QA w/ T5  !!
As the paper illustrated only performances of XXL-SSM models,
I have two questions on other checkpoints:

Could you please report the test performances on all datasets of other released checkpoints ??
In particular,
T5.1.1-small + SSM + Natural Questions (train)
T5.1.1-XL + SSM + Natural Questions (train)

Since T5-XL & XXL are too big to train in Colab-pro (high-ram mode), so
is it possible to release T5.1.1-large + SSM + Natural Questions (train) checkpoint ?

(EDIT : I humbly tag @adarob as the topic author)

I will try to get to it today!

Thanks Adam @adarob !
Aside from that, I would also love to try loading these T5.1.1 checkpoints into huggingface library, but it's not possible without knowing exact different between original T5 and T5.1.1 .  I could not find any source code of T5.1.1 , is it possible to provide the link to the source?

Sorry for the delay, but I will make sure to do it early next week. @craffel will be your best resource for T5.1.1 over in https://github.com/huggingface/transformers/issues/6285#issuecomment-714838398


Trying to get https working with dockerfile

Hi there,
Trying to get https working using the dockerfile to no avail:
warn --- invalid address - "https://my-url.com:4873/", we expect a port (e.g. "4873"), host:port (e.g. "localhost:4873") or full url (e.g. "http://localhost:4873/")

The container then dies. I had to override the dockerfile command and edited it to remove the --listen argument so that it used the config to do it. If I change it at all from <IP_ADDRESS>:4873 it fails to start.

 Seems like you'd likely want something in front of it terminating the SSL but maybe that's just my approach. If you do that then this operates off non-ssl and should be alright.

Seems like you'd likely want something in front of it terminating the SSL
Not quite sure what you mean by that. It supports SSL from the looks of it, but it won't actually let me serve out the certs.

@mattoni Can you describe your set up? How Can I reproduce it?

It's been awhile since I've messed with this, but I've got certificates being installed into a /tls directory with the following config:
#
# This is the default config file. It allows all users to do anything,
# so don't use it on production systems.
#
# Look here for more config file examples:
# https://github.com/verdaccio/verdaccio/tree/master/conf
#

# path to a directory with all packages
storage: /verdaccio/storage

listen:
  - https://npm-registry.cycle.io:4873

https:
  cert: /tls/current.chain
  key: /tls/current.key

auth:
  htpasswd:
    file: /verdaccio/conf/htpasswd
    # Maximum amount of users allowed to register, defaults to "+inf".
    # You can set this to -1 to disable registration.
    max_users: 10

# a list of other known repositories we can talk to
uplinks:
  npmjs:
    url: https://registry.npmjs.org/

packages:
  '@*/*':
    # scoped packages
    access: $all
    publish: $all
    proxy: npmjs

  '@platform/*':
    # allow all users (including non-authenticated users) to read and
    # publish all packages
    #
    # you can specify usernames/groupnames (depending on your auth plugin)
    # and three keywords: "$all", "$anonymous", "$authenticated"
    access: $authenticated

    # allow all known users to publish packages
    # (anyone can register by default, remember?)
    publish: $authenticated

    # if package is not available locally, proxy requests to 'npmjs' registry
    proxy: npmjs

# log settings
logs:
  - {type: stdout, format: pretty, level: http}
  #- {type: file, path: verdaccio.log, level: info}

and running it with the following args:
/usr/src/app/bin/verdaccio --config /verdaccio/conf/config.yaml --listen <IP_ADDRESS>:4873
If i change listen at all, the container will crash so I can't get it to run https.

@mattoni sorry the delay. Only 2 maintainers not enough to reply soon. Anyway, I'm curious if you are using the official Dockerfile or you have your own? Also I noticed /tls folder seems to be a volumen, I'm right ?

Using the default Dockerfile. I run a CaaS platform, (Cycle)[https://cycle.io] that automatically manages the TLS certs by installing them into that directory.

http://www.verdaccio.org/docs/en/docker.html#using-https-with-docker


Fixes #1225 - Created a single ZooNode that tracks changes for all table configs

@ivakegg  has reviewed this code and has recommended this pull request.  It is nearly an exact implementation of what @ctubbsii  has specified at the top of the Issue #1225. The solution has been tested in Fluo-uno and Fluo-muchos on EC-2.  It has been tested in the accumulo shell by using the 'config' command to change table properties and see the changes made effective. Other commands like 'createtable' and 'deletetable' and 'clonetable' have been tested to check that the system works as expected.  Accumulo-Testing 'cingest createtables' and 'cingest ingest' both run well.  It passes the  'mvn clean verify -Psunny' build.  Additionally @keith-turner performed a verification of a table configuration being set and then used by the system in the Accumulo shell.
The non-existence of the watchers has been verified using the ZooKeeper 'wchp' four letter word command.   These four letter commands need to be whitelisted in your zoo.cfg file by adding this line:
4lw.commands.whitelist=*
You need to stop and start Zookeeper to see the whitelisted commands come into effect.
You run the 'wchp' four letter command from the shell like so:
echo wchp | nc localhost 2181 | grep 'conf/table.
The only watchers remaining for table configuration are the ones  under /accumulo/{InstanceID}/namespaces.  We no longer see accumulation of table configuration item watchers as tables are created and deleted.
This pull request should fix some system issues we have seen over the years in large systems.

Seems like ZooCache.getChildren may still set watchers.

This could be follow on work and I think these would go hand in hand.  Instead of just watching a single node, we could watch 10 or 20 nodes and hash properties between them in some way.  My thinking is that this may handle high frequency changes more gracefully.  I also think it would be better to pull this code out of ZooCache into its own class.  Something like TablePropertyCache.  Having it in its own class would make it easier to make changes like the hashing thing.  Also I think it would be easier to understand ZooCache and TablePropertyCache if separate.  Again this can be follow on work.

I agree with your comment above.  The high frequency changes concern me also.  When you see in the logs that the code is actually processing the changes in the proper consecutive order it is pretty amazing.  In a large network with a little latency the watch events might not inform all the tservers as perfectly as they do on a 5 node cluster in EC2.

Seems like ZooCache.getChildren may still set watchers.

My last commit deals with this in TableManager.removeTable by performing this call:
 zoo.getZooKeeper().getChildren(tableConfigPath, false);

I have another branch on my fork that solves the "Unremoved watcher problem".  It is much less risky than this one and simpler to understand.  It is called accumulo-1220.  The main way it works is with the that call to getChildren(tableConfigPath, false).  It removes all of the watches for Table config Items in the conf directory.  The other part is in the ZooCache.  @ivakegg  is looking at it now so you don't have to if you don't want to.

Currently the watched node has a single prop name in its value.  It could have a list in its value and that could be very beneficial for create, clone, and import table. The list could help avoid missing updates.  It may also be useful for deletetable.  It would also better support a future API call that allows setting multiple props at once.
The create table operation knows of all of the props its going to set in zookeeper.  It could set all of those props (without updating the watched node for each prop) and then after setting all, it could set the value of the watched node to the list of props it updated.

Currently the watched node has a single prop name in its value. It could have a list in its value and that could be very beneficial for create, clone, and import table. The list could help avoid missing updates. It may also be useful for deletetable. It would also better support a future API call that allows setting multiple props at once.
The create table operation knows of all of the props its going to set in zookeeper. It could set all of those props (without updating the watched node for each prop) and then after setting all, it could set the value of the watched node to the list of props it updated.

That's a great idea.  Do you want me to start implementing that?  The data being stored in the table-config-version znode can't be allowed to get to large and the name should be changed to something more in line with what it is doing.
In the short term, like I mentioned, I have another branch that is lower risk than this one.

That's a great idea. Do you want me to start implementing that?

It could be done in this PR, if not I can open follow up issues.

That's a great idea. Do you want me to start implementing that?

It could be done in this PR, if not I can open follow up issues.

I will start working on it now then.

Currently the watched node has a single prop name in its value. It could have a list in its value and that could be very beneficial for create, clone, and import table. The list could help avoid missing updates. It may also be useful for deletetable. It would also better support a future API call that allows setting multiple props at once.

@keith-turner ,  when I started to implement this I took another hard look at what actions actually call TablePropUtil.setTableProperty and whether it is really necessary for all of them to send notification to all the ZCacheWatchers to notify of a them of creating, cloning and importing.  The reality is that the ZCacheWatchers don't need to get all these messages on the table-version-config znode.  The ZCache never got those messages for the table configuration items until after Zcache.get was first called on the table configuraton zNodes.
Lets look at cloning for example.  A table exists, call it sourceTable.  Its configs are in Zookeeper.  You want to clone it into destinationTable.  sourceTable has it's table configuration items in all the ZooCaches across the cluster.  TableManager.cloneTable(sourceTable, destinationTable , ..... ) gets called.  cloneTable iterates through sourceTable's config values and sets identical ones for destinationTable in Zookeeper via TablePropUtil.setTableProperty.  At this time none of the ZooCache's anywhere have these zPaths for the destinationTable inside of their internal cache objects.  destinationTable is a new table and no  Tserver or anything has ever called the function ZooCache.get for any of destinationTables zooNode data. It could not have happened.  destinationTable just came into existence.  None of destinationTable's table configs will be in any ZooCache during the execution of cloneTable.    During the cloneTable table operation if we tell the ZooCaches to remove these new configuation items from their cache it is pointless since the configuration items can not be in the ZooCache's anywhere.  That means we don't have to modify the 'table-config-version' znode during cloning because it is pointless.  It really does nothing and is not required when you think about it. Look at what the NodeDataChanged event does now regarding the 'table-config-version' node. It just deletes from the cache the table config item pulled from the data of 'table-config-version' znode.  If you have a big list of items they will just be a big list that aren't in the cache yet.
The call paths that I have identified that require the update of the 'table-config-version' node are ones that start from MasterClientServiceHandler.removeTableProperty and MasterClientServiceHandler.setTableProperty.  They work individually.  They can't be "batched".
I will implement "batching" when I can find a suitable entry point to do it.
Anytime you use the mechanism of changing the data in 'table-version-config' to trigger watch events in the caches to remove items that are not even there yet, you are wasting network resources and taxing the ZooKeeper server.
@keith-turner,  you motivated me to realize a very good optimization for this process.  Thank you.
I will check in some a new commit for you to look at.  It doesn't implement batching but it is an improvement to the last commit.

@jzgithub1 that may be good idea to not trigger on table creation and clone. I would want to do some investigation of a few things.
Tserver execute random operations for clients.  Wondering if the following is possible?  I think there may be some things that would prevent this, but I am not sure.

Client process P1 initiates create table op for table TAB1
Client process P2 request request table props for TAB1, this dispatches to tserver TS1
The master process has written some props to ZK for table TAB1
Tserver TS1 reads a partial list of props for TAB1 into its zoocache
The master process completes writing props to ZK for table TAB1
If this could happen the partial props in ZooCache may not update

Need to investigate the order of information put into ZK, like if the table ID to name map is put into ZK before the props that would make it visible to clients. Also do clients ignore tables in the NEW state?  I think they may, but not sure.

@keith-turner I am rolling back the last commit.   We need the version of the table-config-version updated whenever a table config item  is added by creation or cloning in order to keep it updated in the 'lastTableConfigVersion' member of the ZooCache class.   The act of trying to remove items from the ZooCache that we know can't be in the ZooCache yet is not costly computationally and will be fixed later on.  The reasoning I lay out above regarding about being able to rely on ZooCache.get to actually return up-to-date config items when they are actually needed still applies.

@keith-turner.  Something that I found out about cloneTable ( at least with the 'ci' table in accumulo-testing) is that when line 241 in TableManager.cloneTable gets executed there aren't any table properties to set:
log.info(
        "TableManager.cloneTable has  " + propertiesToSet.keySet().size() + " table props to set");

for (Entry<String,String> entry : propertiesToSet.entrySet())
      TablePropUtil.setTableProperty(context, tableId, entry.getKey(), entry.getValue());

My logs:
install/logs/accumulo/master_dragonfly.log:2019-11-18 12:18:38,494 [tables.TableManager] INFO : TableManager.cloneTable has  0 table props to set

@keith-turner,  notifying the ZooCache of in a single notification about all of the added properties has been implemented.  As mentioned above, the only thing that really gets accomplished is that the ZooCaches find out there is a table-config-version they need to update their cache.   We are getting close to resolving issues of concern in this pull request.
I am continuing to look into the other concerns you have bulleted above.

@jzgithub1 that may be good idea to not trigger on table creation and clone. I would want to do some investigation of a few things.
Tserver execute random operations for clients. Wondering if the following is possible? I think there may be some things that would prevent this, but I am not sure.
* Client process P1 initiates create table op for table TAB1

* Client process P2 request request table props for TAB1, this dispatches to tserver TS1

* The master process has written some props to ZK for table TAB1

* Tserver TS1 reads a partial list of props for TAB1 into its zoocache

* The master process completes writing props to ZK for table TAB1

* If this could happen the partial props in ZooCache may not update

Need to investigate the order of information put into ZK, like if the table ID to name map is put into ZK before the props that would make it visible to clients. Also do clients ignore tables in the NEW state? I think they may, but not sure.

@keith-turner,  where we are now in this PR is it that we trigger updates of the cache on create table and clone table.  I implemented the sending of all the configs at cloning like you requested (with a caveat I will explain later) .  Delete table is going to modify the ZooCache the way it used to.  Just removing every item from ZooCache with a key that is prefixed with /accumulo/{instance_id}/tables/{table-id}.
The sequence of steps that you are talking about is something that you probably observed and I believe @ivakegg  has seen also.  It may actually be fixed by this pull request already.  This is because when a table configuration item is modified by a client process now it will definitely trigger an watch event in the ZCacheWatcher (for the table-config-version node) where it might not have been triggered before .   Only non-existent znodes that had a watcher put on them by a call to ZooCache.get(zPath) would trigger a NodeCreated event catchable in the ZCacheWatcher.  So what people may have been observing is that when they set table configurations in the accumulo shell (during clonetable or createtable), the defaults already in the ZooCache were never wiped and refreshed because there was no proper mechanism for it.  This is my initial hypothesis to explain the phenomenon of non durable table configuration modifications.
I will continue to come up with actual steps and scenarios I can go through to address the concerns you have made in the bulleted comments above.
Please take a look at my last couple of commits to see that I am going in the right direction towards addressing other requests you have made.

I observed that when a NodeChildrenChanged event occurred on a table configuration znodes (ones that ends in conf) the watcher was not being reset on that zpath and the children of the conf zpath where not being removed from the cache.  I now perform those actions.  It may fix some issues people have see with config changes not being applied because old or default configs have not been removed from the cache.

@jzgithub1 that may be good idea to not trigger on table creation and clone. I would want to do some investigation of a few things.
Tserver execute random operations for clients. Wondering if the following is possible? I think there may be some things that would prevent this, but I am not sure.
* Client process P1 initiates create table op for table TAB1

* Client process P2 request request table props for TAB1, this dispatches to tserver TS1

* The master process has written some props to ZK for table TAB1

* Tserver TS1 reads a partial list of props for TAB1 into its zoocache

* The master process completes writing props to ZK for table TAB1

* If this could happen the partial props in ZooCache may not update

Need to investigate the order of information put into ZK, like if the table ID to name map is put into ZK before the props that would make it visible to clients. Also do clients ignore tables in the NEW state? I think they may, but not sure.

@keith-turner . my last commit assures that once the master process completes writing props to ZK for TAB1 you won't see a partial props update.  This because a NodeChildrenChanges event will occur for the specific table's 'conf' znode and all the table props will now be cleared from the cache and restored for just that table.  That didn't happen before.  All that happened before was that the value in the cache for the 'conf' directory was removed from the cache.  No other attempt was even made to put a the watcher back on that znode.  In the scenario you describe we are more solid now than we have been in the past in regards to CAP considerations. JMHO.  I have traced the logging as I created, cloned and added and modified props to tables.  I was surprised to see us handling the NodeChildrenChanged event on the 'conf' znodes the way we were.

Seems like ZooCache.getChildren may still set watchers.

From the ZooKeeper documentation:
A watch object, or function/context pair, will only be triggered once for a given notification. For example, if the same watch object is registered for an exists and a getData call for the same file and that file is then deleted, the watch object would only be invoked once with the deletion notification for the file.
http://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#sc_WatchRemoval

I think this change should be postponed until after #1454 , which should make implementing this a bit simpler.

This PR is outdated and is overridden by https://github.com/apache/accumulo/pull/2569


vls: init at 0.7.2

Motivation for this change
vue-language-server is now deprecated and should be replaced by vls.
See: https://www.npmjs.com/package/vue-language-server
Things done

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

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

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

Result of nixpkgs-review pr 120599 at 1690fff4 run on aarch64-linux 1

2 packages skipped due to time constraints:

iosevka
lumo

2 packages built successfully:

vscode-extensions.matklad.rust-analyzer
vscode-extensions.vadimcn.vscode-lldb


Missing in new Teams-admin interface?

Is this missing in the new interface (Preview) per 2022-06-15? Can not find App policies anymore. Or is my admin roles spooking around?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6f91604a-35b0-dfbb-55b2-b601cb0841b0
Version Independent ID: 84bcd0d7-b4ed-f13e-c84b-2ec6a7661ae9
Content: Manage app setup policies in Microsoft Teams - Microsoft Teams
Content Source: Teams/teams-app-setup-policies.md
Service: msteams
GitHub Login: @guptaashish
Microsoft Alias: guptaashish

Hi @ulflunqvist, thank you for your feedback.
I can see setup policies in the Teams Admin Center:

I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome, let me know if it can be called out in the docs.
Please follow this link to contact support for business products: https://docs.microsoft.com/office365/admin/contact-support-for-business-products.
Please keep us posted here on the resolution to feed whatever information you discover into the content.

Hello @dariomws and @scanum , do we need to keep the doc issue open and wait for further issues to be reported by @ulflunqvist or can we close it for now and rely that @ulflunqvist  will re-open as required?

@ashishguptaiitb, we can close it and he'll be able to re-open it if needed.
@scanum, could you close it?
Thanks!


Ability to jump back to previous entry

Users will sometimes fat-finger entering an account, or prematurely press enter to accept the suggestion when categorizing bigger amounts of transactions. This experience is quite painful — remember which transaction was wrongly categorized and fix it in the output file as soon as it’s written.
This could be alleviated and be more user-friendly if there would be a way to [b]ack to last transaction input.
As I find this project immensely useful — thanks to all collaborators! — I’d really love to see this improvement.

This is a good idea, I've done this several times myself and have gone the
route of manually editing my ledger file after the fact.
But being able to do it in reckon directly makes more sense.
I'll start looking at this.
Thanks
On Sat, Aug 14, 2021, 1:40 PM Dario Ernst @.***> wrote:

Users will sometimes fat-finger entering an account, or prematurely press
enter to accept the suggestion when categorizing bigger amounts of
transactions. This experience is quite painful — remember which transaction
was wrongly categorized and fix it in the output file as soon as it’s
written.
This could be alleviated and be more user-friendly if there would be a way
to [b]ack to last transaction input.
As I find this project immensely useful — thanks to all collaborators! —
I’d really love to see this improvement.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cantino/reckon/issues/115, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAJHV6VZ77C7PF7MHFAK5DT43IERANCNFSM5CFNWDYA
.


WIP: Fixing a bad test

Fixes #2018

According to #1673, this may have never worked... or at least not for several years.

The current set of changes fail identically (due to timeout) in all versions of Mocha.

#1673 and/or #1847 might be relevant here.


Add outgoing SPNEGO middleware

What does this PR do?

Add outgoing spnego middleware to talk to SPNEGO protected sites

This will resolve #6583
Motivation

We'd like to configure Traefik to talk to SPNEGO protected websites as below.
client --(plain http/s)--> Traefik --> SPNEGO protected site1, 2, 3, ...

To support it, added an spnego middleware.
http:
  routers:
    test_router_http_lb:
      rule: "PathPrefix(`/`)"
      entryPoints:
        - http
      service: lb_spnego
      middlewares:
        - spnego-middleware
  middlewares:
    spnego-middleware:
      spnego:
        host: lab1.lab.sokoide.com:20080
        # either keyTabPath or ccachePath must be specified
        keyTabPath: "/path/to/scott.keytab"
        # ccachePath: /tmp/krb5cc_1000
  services:
    lb_spnego:
      loadBalancer:
        servers:
          - url: "http://lab1.lab.sokoide.com:20080/"

More

[ ] Added/updated tests
[ ] Added/updated documentation

Additional Notes

user defaults to $USER if not specified.
realm defaults to the default realm in your krb5.conf
krbConfPath defaults to /etc/krb5.conf
If there is no matching domainName in spnOverides (optional), spn defaults to HTTP/$domainname
Either keyTabPath or ccachePath must be specified. If both are specified, the keytab takes precedence.
Tested with MIT Kerberos KDC using https://github.com/sokoide/kerberos with Traefik on Ubuntu 20.04 and MacOS Monterey.

Sample optional configs.
  middlewares:
    spnego-middleware:
      spnego:
        host: lab1.lab.sokoide.com:20080
        user: scott
        realm: REALM.SOKOIDE.COM
        krbConfPath: "/path/to/krb5.conf"
        keyTabPath: "/path/to/scott.keytab"
        spnOverrides:
           - spn: "HTTP/another.service.name"
             domainName: "lab1.lab.sokoide.com:20080"

#6583

This will resolve Issue 6583

Hello @sokoide,
Thanks for your contribution,
Did you try to implement this SPNEGO middleware as a plugin?
Did you encounter some limitations?

Hi @sokoide, as @kevinpollet suggested I believe that this authentication middleware can be implemented via the plugin system and if you find any limitation because of it please open an issue for yaegi, or here if it's related to Traefik itself.
Authentication middleware are often times very complex and specific and as a small team we would struggle to maintain every authentication mechanism out there, for that reason we assume this stance to keep only the ForwardAuth middleware if possible while allowing contributors to add more specialized methods with plugins when necessary. A similar situation occurred very recently here.
For those reasons I'm closing this PR, thank you again for the time and effort!


preserving the existing appbuilder properties and conventions inside the middleware

fixes #58. See the implementation of New method here: https://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin/Builder/AppBuilder.cs

Hi @tugberkugurlu, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

could you do that on the dev branch?


Load scene by default for mj models and allow variants

Hi @stephane-caron ,
thanks for this nice library to load a bunch of robot models with different frameworks. Lately I was trying some mujoco models and I had a quick fix locally to load the scene.xml (which was more useful in my case).
I saw #74 and also #62 and thought that a minimal adaptation allowing for both could be the change proposed in this PR.
This adds a variant keyword, that I set the scene by default. If a robot has no scene.xml, it will still just load the pure robot model as define in each specific file per robot. With this solution, we do not have to modify every single file but I am very open to changes and happy to integrate your remarks.

Just chiming in that I disagree that scene should be the default.

Just chiming in that I disagree that scene should be the default.

Yes, this was the original proposal but we have changed it in https://github.com/robot-descriptions/robot_descriptions.py/pull/76/commits/f6096953e3f3aef3bf3124f2133656b063c9a9cb. Now the PR is backward compatible and one should pass variant="scene" explicitly to load the scene.

Thank you for this contribution @fabinsch 😃

Thank you @fabinsch and @stephane-caron!


The chat looses context and also display empty spaces and not work as intended

It's sad to see after just 10 12 queries the chat stop working and gives weird erors and have to restart the VSCODE and even after daily updates this main issues not being solved why?

What are the weird errors?

Startts explaining code instead of answering

So you're asking it to write some code and it starts explaining it instead? You're not getting any actual exceptions

I select a code, and ask some questions... instead of following it gives
what the code does and stops
On Fri, May 31, 2024, 12:00 AM Logan Ramos @.***> wrote:

So you're asking it to write some code and it starts explaining it
instead? You're not getting any actual exceptions
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-copilot-release/issues/1176#issuecomment-2140690205,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIRXJSEQH6SS6TRQZMIE3I3ZE5ZORAVCNFSM6AAAAABHHYWEFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQGY4TAMRQGU
.
You are receiving this because you authored the thread.Message ID:
@.***>


I need to know the other input's value at the same level

Hey guys, I created a query builder. I need to know the other input's value at the same level, but I couldn't find a function for it. For example; I have city and district fields at the same level. I will send a request to the backend and create the district field according to the selected city. Is there any way to do this?

The easiest way to do this is probably to pass the query down through the context prop to your custom value editor (something like <QueryBuilder context={{ query }} />).
Your value editor can then use findPath and getParentPath to get the sibling rules, find the "district" rule, and use that in the "city" rule.
Example CodeSandbox here: https://codesandbox.io/s/cool-lehmann-hm7no8?file=/src/App.tsx
Relevant code:
// custom value editor
const VE = (props: ValueEditorProps) => {
  const district = findPath(
    getParentPath(props.path),
    props.context.query
  ).rules.find((r: RuleType) => r.field === 'district').value;

  if (props.field === 'city') {
    return (
      <>
        <ValueEditor {...props} />
        {district}
      </>
    );
  }
  return <ValueEditor {...props} />;
};

Thank you so much, Jake, you saved my day. I am thankful to you 🎉


Integrated forum search into search dropdown menu

Per issue #307 I have added the forum search option to the dropdown in the nav on the home page and have ensured that it actually searches.

All of the suggestions have been added, the forum search can now be found in the dropdown, and the PR has been successfully merged and closed. Thanks to @joshuamonroe  for reviewing the PR.


Update ni-sidebandaudio-ioctl_sbaud_get_mute_status_update.md

@barrygolden - This is ready to go.

@barrygolden - This is ready to go.


Respect no interaction flag when asking for confirmation

When someone uses the --no-interaction flag, they are still asked for confirmation using an interactive prompt.
This fixes that explicitly.

@martinshaw-wawdbd Do you still run into this issue? If yes, can you provide instructions on how to reproduce this error? (See comment above)

Closing this PR, as I'm unable to reproduce this issue.


soem: 1.3.0-0 in 'lunar/distribution.yaml' [bloom]

This seems to be a duplicate of #15414?

I've released in two steps, apparently both releases got into the same PR. I'll close this one.


Rewrite to use \copy command

https://stackoverflow.com/questions/1517635/save-pl-pgsql-output-from-postgresql-to-a-csv-file
Should be much faster

This was completed a long time ago


Pass ProxyConfig.Concurrency to pilot-agent.

Signed-off-by: Piotr Sikora<EMAIL_ADDRESS>

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: ijsnellf
If they are not already assigned, you can assign the PR to them by writing /assign @ijsnellf in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS
pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

#8196 cherry-picked to master.

@PiotrSikora: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
b42dec131e0c47a753388585af0521d0d03fd9e5
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-unit-tests

/assign @ijsnellf


Update JWTAuth.php

Not sure but I think this string will also need to be changed in the i18n lang file(s).


Setting repository fails because zeroc-ice3.6.repo is unavailable

Here's the output of the failed task at molecule converge -s ice36all.
TASK [ansible-role-ice : zeroc ice | setup repository] **************************************************************************************************************************************
fatal: [ice36all]: FAILED! => {"changed": false, "dest": "/etc/yum.repos.d/zeroc-ice-el7.repo", "elapsed": 0, "msg": "Request failed: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)>", "url": "https://zeroc.com/download/Ice/3.6/el7/zeroc-ice3.6.repo"}

PLAY RECAP **********************************************************************************************************************************************************************************
ice36all                   : ok=5    changed=4    unreachable=0    failed=1    skipped=21   rescued=0    ignored=0

I can workaround this problem by adding validate_certs: no to the task. However, the next task "zeroc ice | install runtime packages" fails then(see below).
TASK [ansible-role-ice : zeroc ice | setup repository] **************************************************************************************************************************************
changed: [ice36all]

TASK [ansible-role-ice : zeroc ice | install runtime packages] ******************************************************************************************************************************
fatal: [ice36all]: FAILED! => {"changed": false, "msg": "Failure talking to yum: failure: repodata/repomd.xml from zeroc-ice3.6: [Errno 256] No more mirrors to try.\nhttps://zeroc.com/download/Ice/3.6/el7/x86_64/repodata/repomd.xml: [Errno 14] curl#60 - \"Peer's Certificate has expired.\""}

PLAY RECAP **********************************************************************************************************************************************************************************
ice36all                   : ok=6    changed=1    unreachable=0    failed=1    skipped=21   rescued=0    ignored=0

Although it is clear that the root cause is at https://zeroc.com, could you somehow possibly fix/workaround this problem?
Thank you in advance!

Hi @kojiwell. I don't have an idea offhand on how we could workaround this (other than co-hosting the files). It looks though like the problem has been corrected:

local curls are passing and
https://github.com/ome/ansible-role-ice/pull/18 which I just opened is green.

Can you give it another try and let us know?

Thank you, @joshmoore, for checking. My local test finished without a problem now.


Mid-Fi Wireframe for Locking Facility (by refinement for 4.4)

Create mid-fi wireframe for locking Facility by a logged in user.
This wireframe will support #1345.
Please see low-fi mockup (PD Board Scenario 2B):

Included in #1437


(PUP-5889) add a strict flag

This adds a --strict flag that can be set to warning, error or ignore. In this PR this new setting is made to play nicely with the --strict_variables such that, if --strict_variables is true then it always errors (this is what users expect). If it is not set, the behavior is controlled by the --strict setting.
The default for --strict is warn. This is also what is expected for --strict_variables (by default). Users can opt out by setting --strict=ignore.
It is expected that the --strict flag will be used in different ways for new kinds of validations. In this PR one tricky thing is to maintain the API for those that call directly into scope (not being prepared to catch the symbol :undefined_variable. This is now done by always throwing :undefined_variable, and catching the resulting exception if there were no catcher. Earlier the trowing was conditional which led to other problems.
Now the API is - if a caller wants to handle the error/warning aspect of an undefined variable it should catch the thrown symbol. If it does not the --strict_variables/--strict flags control the behavior (like before).

Blocked while waiting for master to free up - this is for Puppet 4.5.0

Rebased to latest master

Found a couple of typos that I fixed and amended last commit.


Lacking namespace field in aks-hello-world configurations

Hi,
I just took the suggested ingress setup for a spin in an AKS cluster. Doing so I found that namespace fields were missing in the aks-hello-world-{one/two} Deployment and Service configurations. I.e. adding the following to aks-hello-world-one.yaml and aks-hello-world-two.yaml remedied my 503 error met when opening my web browser on the external IP of the ingress controller:
...
kind: Deployment
metadata:
  ...
  namespace: ingress-basic
...
kind: Service
metadata:
  ...
  namespace: ingress-basic
...

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fd0e7d5a-37e9-07dc-f395-9cb5bb580e45
Version Independent ID: 7e4faf70-9724-7e7b-832b-1cd99a974920
Content: Create an ingress controller - Azure Kubernetes Service
Content Source: articles/aks/ingress-basic.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

Or, alternatively you should remove namespace: ingress-basic from hello-world-ingress.yaml. I reckon that is more in line with a normal setup where ingress, service(s) and deployment(s) are in a separate namespace than the ingress controller.

@jijordre Thanks for the Feedback. I will update the document.

Doc update, changes will go live soon.


Change edit Route Server to be linkable

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (db278fd) 75.72% compared to head (2f794ef) 75.91%.
Report is 2 commits behind head on prep-release.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@               Coverage Diff                @@
##           prep-release     #124      +/-   ##
================================================
+ Coverage         75.72%   75.91%   +0.19%
================================================
  Files                46       46
  Lines              1557     1557
================================================
+ Hits               1179     1182       +3
+ Misses              378      375       -3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


crate::Options is not Sync

The Options struct is not Sync. This is an issue in web servers because it means we must reallocate an Options struct every time we parse something.
I will work on this problem later.
Full compiler diagnostic:
error[E0277]: `(dyn for<'a, 'b> Fn(&'a str, &'b MdxExpressionKind) -> MdxSignal + 'static)` cannot be shared between threads safely
    --> src/templates/markdown.rs:3:20
     |
3    | static MD_OPTIONS: markdown::Options = markdown::Options::default();
     |                    ^^^^^^^^^^^^^^^^^ `(dyn for<'a, 'b> Fn(&'a str, &'b MdxExpressionKind) -> MdxSignal + 'static)` cannot be shared between threads safely
     |
     = help: the trait `Sync` is not implemented for `(dyn for<'a, 'b> Fn(&'a str, &'b MdxExpressionKind) -> MdxSignal + 'static)`
     = note: required for `Unique<(dyn for<'a, 'b> Fn(&'a str, &'b MdxExpressionKind) -> MdxSignal + 'static)>` to implement `Sync`
note: required because it appears within the type `Box<dyn Fn(&str, &MdxExpressionKind) -> MdxSignal>`
    --> ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:195:12
     |
195  | pub struct Box<
     |            ^^^
note: required because it appears within the type `Option<Box<dyn Fn(&str, &MdxExpressionKind) -> MdxSignal>>`
    --> ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:569:10
     |
569  | pub enum Option<T> {
     |          ^^^^^^
note: required because it appears within the type `ParseOptions`
    --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/markdown-1.0.0-alpha.16/src/configuration.rs:965:12
     |
965  | pub struct ParseOptions {
     |            ^^^^^^^^^^^^
note: required because it appears within the type `Options`
    --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/markdown-1.0.0-alpha.16/src/configuration.rs:1243:12
     |
1243 | pub struct Options {
     |            ^^^^^^^
     = note: shared static variables must have a type that implements `Sync`

Current workaround I'm using. I'll write this up in a pull request later.
/// A markdown::Options wrapper that can be safely passed between threads.
/// Note that this struct cannot wrap Options with MDX parser functions
/// specified. In other words, `options.parse.mdx_ems_parse` and
/// `options.parse.mdx_expression_parse` must both be `None`.
///
/// # Examples
///
/// ```rust
/// use docgen::state::ThreadsafeOptions;
///
/// // Equivalent to `let options = ThreadsafeOptions::new(markdown::Options::default());`
/// let options = ThreadsafeOptions::default();
/// let app_state = Arc::new(options);
/// // `app_state` may now be used in a multi-threaded web server.
/// ```
#[derive(Debug, Default)]
pub struct ThreadsafeOptions(Options);

unsafe impl Send for ThreadsafeOptions {}
unsafe impl Sync for ThreadsafeOptions {}

impl ThreadsafeOptions {
    /// Create a new `ThreadsafeOptions` wrapper around the provided `Options`
    /// object.
    ///
    /// **PANICS**: This function will panic if you attempt to instantiate a
    /// new object with an MDX parser specified. In other words,
    /// `options.parse.mdx_ems_parse` and `options.parse.mdx_expression_parse`
    /// must both be `None`.
    pub fn new(options: Options) -> Self {
        if options.parse.mdx_esm_parse.is_some() || options.parse.mdx_expression_parse.is_some() {
            panic!("Cannot instantiate markdown::Options with MDX parsers specified")
        }
        Self(options)
    }
}

impl From<Options> for ThreadsafeOptions {
    fn from(value: Options) -> Self {
        Self::new(value)
    }
}

impl Borrow<Options> for ThreadsafeOptions {
    fn borrow(&self) -> &Options {
        &self.0
    }
}

Welcome @stephenlf! 👋

The Options struct is not Sync.

This is an XY Problem.

This is an issue in web servers because it means we must reallocate an Options struct every time we parse something.

Memory is allocated all over the place to do parsing and create a syntax tree.
Allocation feels like a non issue here.
This library aims is 100% pure safe rust, sync is unsafe https://doc.rust-lang.org/nomicon/send-and-sync.html
Marking a core part of the safe API unsafe is a non-starter here.
Reading between the lines a bit you seem to be trying to reuse options across multiple threads in Rust? Is that accurate?
If so why is allocating Options an issue for you?

I am incorporating a Markdown parser into an Axum web server I am writing. Rather than reallocate an markdown::Options object every time the parser endpoint is called, I had hoped to save on memory by instantiating a single, immutable markdown::Options object, wrapping it in Arc, and passing it in to the router's axum::State. To do this, the markdown::Options object would have to be Send/Sync, since application state may be passed between threads.
I understand not wanting any unsafe blocks in the codebase. "100% safe Rust" is a remarkable claim. My workaround is sufficient for my use case. And it sounds like the amount of allocation going into an Options struct is trivial compared to the work being done by the parser, so there's probably no need for me to worry about it. However, if you do want to create a thread-safe, "100% safe Rust" Options implementation, I believe there are ways to do it without unsafe code blocks.
I realize now it was presumptuous of me to say that I'd "set up a pull request later." I forgot this wasn't one of my projects! Let me know if you'd like me to explore this issue more.

Other than safe, this project is also no_std + alloc. It’s incredibly basic, Box and Vec but that’s it. Send/Sync/Arc etc is all much higher level.
And indeed, the bottle neck here is parsing documents. I’d assume all energy is better spent there.
I’d also guess that Rust could figure this out itself if there were no mdx functions? Not sure if a thread safe version should just omit those?

I’d also guess that Rust could figure this out itself if there were no mdx functions? Not sure if a thread safe version should just omit those?

That's the approach I took in my codebase. However, I suspect that annotating the MDX functions something like 'static + Sync + Send would also solve the problem without limiting the MDX functionality too much. I haven't explored it very much, but something like this might work:
// markdown-rs/src/util/mdx.rs
// ...
pub type EsmParse = dyn Fn(&str) -> Signal + 'static + Sync + Send;
// ...
pub type ExpressionParse = dyn Fn(&str, &ExpressionKind) -> Signal + 'static + Sync + Send;
// ...

This would of course mean that users couldn't dynamically create their MDX parsers, though I can't see this being a practical issue for most use cases. I'm not sure what other downstream effects something like this might have.


Does Let's Encrypt Daemon require any registration?

I need to find out and document this.

I realized this occurs in docker-compose.yml. Closing.


Android 6.0.1 Use OkHhttp  with Retrofit  cause:  java.lang.InternalError:  Invoking getAttribute with bad arg 0

Use OkHttp with Retrofit   Crash only on  Android 6.0.1 Devices， Maybe an ART Bug?
Versions:
Okhttp:   3.10.0
Retrofit:  2.4.0
Rxjava:  2.0.8
Android Gradle Plugin: 3.2.1
Crash log：
 java.lang.InternalError:Invoking getAttribute with bad arg 0, type 'Lcom/example/user/model/RegisterModel;' not instance of 'Ljava/lang/String;'

2  at com.example.user.UserHelper$Companion.io.reactivex.Observable register(com.example.user.model.RegisterModel)(SourceFile:77)
3  at com.example.user.login.LoginPresenter.io.reactivex.Observable

My Code：

interface ApiService {

    @POST(AppConfig.API_PATH + "/register")
    fun register(@Body registerModel: RegisterModel): Observable<LoginRespResult>

}

@Keep
class RegisterModel {
    @SerializedName("email")
    @JvmField
    var emailAddress: String? = null
    @SerializedName("password")
    @JvmField
    var password: String? = null

}

@Keep
class LoginRespResult {
    @SerializedName("auth")
    @JvmField
    var userAuth: UserAuth? = null
}

// call api

fun test() {
       HttpClient.API.register(registerModel)
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe()
}

Someone other  asked：
Redmi note 3 ,Android 6.0.1 crash
java.lang.InternalError: Invoking with bad arg 0, type 'Lokhttp3/RequestBody$2;' not instance of '[Ljava/lang/Object;' 2    at com.sfpush.pushsdk.PushManager.getRegistrationId(PushManager.java:152) 3    at com.sfpush.pushsdk.PushManager.start(PushManager.java:63) 4    at com.sferp.employe.ui.MainActivity.onCreate(MainActivity.java:174) 5    at android.app.Activity.performCreate(Activity.java:6278) 6    at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1107) 7    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2396) 8    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2503) 9    at android.app.ActivityThread.-wrap11(ActivityThread.java) 10    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1353) 11    at android.os.Handler.dispatchMessage(Handler.java:102) 12    at android.os.Looper.loop(Looper.java:148) 13    at android.app.ActivityThread.main(ActivityThread.java:5529) 14    at java.lang.reflect.Method.invoke(Native Method) 15    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:745) 16    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:635)
Related stackoverflow question:
Why does Facebook and Messenger set the vmSafeMode option as false to the manifest file?

Related issue  #2836

Executable test case? As is this is not actionable.

Executable test case? As is this is not actionable.

It's sample code

Got the same error:
Fatal Exception: java.lang.InternalError: Invoking get with bad arg 0, type 'Ljava/lang/String;' not instance of 'Lcom/****;'
okhttp version: 4.3.1

Got the same error:
Fatal Exception: java.lang.InternalError: Invoking get with bad arg 0, type 'Ljava/lang/String;' not instance of 'Lcom/****;'
okhttp version: 4.3.1
Device:

hello ，got the same error，so how to solve it

got the same error，so how to solve it

got the same error，so how to solve it

Provide steps to reliably reproduce. A sample app or project to build. Does it happen with emulator?

Provide steps to reliably reproduce. A sample app or project to build. Does it happen with emulator?

The crash happened online，we can not reproduce.the code is correct,use apktool to check smali

We can't help.  Consider raising with the device manufacturers, although if the devices are rooted like above then it's a wild west and unlikely they will support. These types of issues are somewhat common with the huge variety of older devices and we can't fix or debug for you.

We can't help. Consider raising with the device manufacturers, although if the devices are rooted like above then it's a wild west and unlikely they will support. These types of issues are somewhat common with the huge variety of older devices and we can't fix or debug for you.

thanks,we will follow up this issue.

Got same error. Maybe art 6.0 bug.

@nicai1900 how to sovle it finally?

still get the same error, how to solve it?


Incorrect handling of the idle timeout parameter in v0.46.0

According to RFC 9000, the max_idle_timeout parameter of transport parameters is used to negotiate the idle timeout mechanism's duration. However, when it is set to 0, it indicates that idle timeout is not enabled.

max_idle_timeout (0x01):  The maximum idle timeout is a value in milliseconds that is encoded as an integer; see (Section 10.1).       Idle timeout is disabled when both endpoints omit this transport parameter or specify a value of 0.

However, in version v0.46.0, if max_idle_timeout is set to 0 by client, it actually sets the idle timer time to 0, causing the connection to be immediately deemed idle and closed after the first stream is closed.

This is not correct. The idle timeout is always set to at least the value of the local idle timeout:
https://github.com/quic-go/quic-go/blob/920bfb46af9db2ab23a94e54701b7a310ecc4928/connection.go#L1768-L1771
This satisfies the requirement to take the minimum of both peers' advertised idle timeout values.
The only case where this logic would fail is when the local idle timeout is set to 0, which is not possible by definition of Config.MaxIdleTimeout:
https://github.com/quic-go/quic-go/blob/920bfb46af9db2ab23a94e54701b7a310ecc4928/interface.go#L279-L280

When s.config.MaxIdleTimeout is set to 30 (non-zero) and params.MaxIdleTimeout is 0, s.idleTimeout will be set to 0 according to the code.

Oops, you’re right.

Sorry. There are some errors in my previous comment. The RFC states that the mechanism should be closed only when both parties specify max_idle_timeout as 0. If only one party specifies it as 0, idle timeout should still be enabled and based on the value specified by the other party.

Fix in https://github.com/quic-go/quic-go/pull/4666. Would appreciate a quick code review 🙏


Add npm start to iOS steps

Hey there! Thanks for PR but I don't think this step really applies here.
Clicking Run as mentioned in step 3 will automatically start the packager as will building the app using react-native run-ios


Dispatcher interface

Hello,
your lib seems to be interesting for simple interfaces.
What du you think about a virtual dispatcher class providing a (protected) access to the filedescriptor (for external polling of the dbus connection) and virtual methods for the timer handling?
With this feature, the library can be integrated with frameworks like boost::asio::io_service, ecore, Qt, glib(mm), ...
dbus-cplusplus provides such an interface.

Hi Sandro,
you're right, we have started to use the API in our own commercial project
and boost::asio support is what I want to have, too. For now, the generator
side of the API was in my focus. I already have a much more simplified DSL
in a separate branch which defines in and out parameters instead of
Requests and Responses.
The dispatcher currently is a comglomeration of multiple tasks and should
probably be redesigned, maybe also using correct DBus naming. But for now,
you can retrieve the DBusConnection from the Dispatcher and set up your own
asio integration by implementing the C DBus callouts. I did this for other
eventloop integration. The project dbus-cpp on Launchpad which is driven by
the Ubuntu tablet team has such an integration: see
http://bazaar.launchpad.net/~phablet-team/dbus-cpp/trunk/view/head:/src/core/dbus/asio/executor.cpp
.
Hope that helps.
Regards,
Martin
2016-09-26 14:58 GMT+02:00 Sandro Stiller<EMAIL_ADDRESS>
Hello,
your lib seems to be interesting for simple interfaces.
What du you think about a virtual dispatcher class providing a (protected)
access to the filedescriptor (for external polling of the dbus connection)
and virtual methods for the timer handling?
With this feature, the library can be integrated with frameworks like
boost::asio::io_service, ecore, Qt, glib(mm), ...
dbus-cplusplus provides such an interface.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/martinhaefner/simppl/issues/5, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABM5jHGfzbp_sh25tMMcK5BI5RDZLw3Sks5qt8GTgaJpZM4KGfho
.


Make relative abundance stacked bar chart centered in SVG

Marty is unable to use CSS to make this figure centered on the page. Please use SVG magic to make it centered.

Centered but still have everything peel out to the right?

@jread-usgs  I dont know... Marty and I discussed this morning how to make this figure a little more appealing on the page- Marty wanted to try centering it. If you have other ideas, lets hear them.

Here is what centered looks like:

Can it be centered on the expanded image?

Like, in that picture, I'd eyeball the center at about the 2nd "n" in "Fibers and Lines"

original:

Mine doesn't look that nice, but still prefer what I see now to the centered version above:

oh, I changed the main.css in mine to use 100% instead of the 760px value that was in there. That is one difference

OK, then that's my vote.

kind of splitting the difference here: adding a small left margin buffer:
Either way, if you want to mod it @mwernimont the relativeAbundance.mustache is the file to do it in.

see #153


Stop testing PHP 7.4, 8.0 and Drupal 9

Managing this project would be much easier if PHP 7.4 and PHP 8.0 were dropped. This would also stop Drupal 9 testing; or a Drupal 9 job could be created with PHP 8.1.
webflo/drupal-finder was raised to PHP 8.1 in its 1.3 release. I'm afraid it'll get more complicated with D11, PHPUnit 10/11.
Proposal:

bump minimum PHP version to PHP 8.1
drop testing D9
drop lower versions of Drush, etc, which allowed D9 testing

this would trigger the 1.3.0 release

This makes sense to me. 👍🏻

PHP 8.1 is only supported next 1.5 years
D9 surely needs phase out

PHP bumped to 8.1. Technically D9 can be supported, if it was removed the following tests/rules could be dropped:

AccessDeprecatedConstantTest, and probably \mglaman\PHPStanDrupal\Rules\Deprecations\AccessDeprecatedConstant
\mglaman\PHPStanDrupal\Tests\Rules\ClassExtendsInternalClassRuleTest::testRule ContentEntityDeleteForm test case
ConditionManagerCreateInstanceContextConfigurationRuleTest (and probably its rule)
\mglaman\PHPStanDrupal\Tests\Rules\DeprecatedHookImplementationTest::testRule test for deprecated_field_widget_hooks_field_widget_form_alter
\mglaman\PHPStanDrupal\Tests\Rules\GetDeprecatedServiceRuleTest::testRuleDrupal8
\mglaman\PHPStanDrupal\Tests\Rules\GetDeprecatedServiceRuleTest::testRuleDrupal9
\mglaman\PHPStanDrupal\Tests\Rules\RequestStackGetMainRequestRuleTest::testRule and the rule
\mglaman\PHPStanDrupal\Tests\Rules\SymfonyCmfRouteObjectInterfaceConstantsRuleTest::testRule and the rule
\mglaman\PHPStanDrupal\Tests\Rules\SymfonyCmfRoutingInClassMethodSignatureRuleTest::testRule and the rule

Personally, I have no need for Drupal 9 support. Generally, favoring accelerated + efficient development over legacy maintenance seems like a good idea.

PHP 7.4/ 8.0 support has been dropped already, D9 is the only one still standing.

A new branch might be a nice clean cut-off point to drop D9 support?

We can say 2.x drops Drupal 9 support, as a follow up to his PR.
https://github.com/mglaman/phpstan-drupal/pull/805#issuecomment-2470920650


add ability to download neurovault datasets

This feature is now added with #79.  Can now download collections from neurovault including pain and emotion datasets.


Adds new command and arriving search

Codecov Report

Merging #83 into master will decrease coverage by 0.29%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #83      +/-   ##
==========================================
- Coverage   99.85%   99.56%   -0.30%
==========================================
  Files           1        1
  Lines         710      688      -22
  Branches      137      133       -4
==========================================
- Hits          709      685      -24
- Misses          0        1       +1
- Partials        1        2       +1

Impacted Files
Coverage Δ

turbot/__init__.py
99.56% <100.00%> (-0.30%)
:arrow_down:

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 9286d37...35eed1d. Read the comment docs.


csv files are not able to downlod

hi,
Cloning your repository is not downloading the data files(csv files).
How to download csv files from your repo.

This is a really bad issue with Git LFS I think. Give me a couple of days I will fix this and update on this thread

I am expecting to hear good news

I will be working on this today and this week, since I need to restructure this repository for the upcoming new version of this book (in Python 3.x). Expect an update soon for this and a fix too.

This is fixed for now, let me know in case any further issues arise. Git LFS has been more of a hindrance than a help so I removed it. Will be working on the revised version of this book in the next few months.