fix(SimplePagination): styling now uses correct vars

Closes #477
Summary

Migrated styling to scss #370
Changed colors to use correct Carbon vars

Acceptance Test (how to verify the PR)

Check SimplePagination story to see that colors are correct

:tada: This PR is included in version 2.38.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Kops multiple node instance groups and auto-scaling

Idea:

Need to have regular light nodes for day to day activities
Separate node group with heavy shape for model training that starts nodes only on demand once training pod scheduled

We should be able to choose resources (RAM and CPU) instead of name of shape in Jenkinsfile.

[ ] Start new heavy instance on demand with resources -> ram/cpu
[ ] Add tolerations to a instance groups to prevent non training containers not to prevent scale-down
[ ] Add tolerations at jenkins plugin to allow jenkins slave to use heavy nodes


perf: fix encode_varint{32,64}

The previous code was full of jumps that aren't easily predictable. This version is less code, generates less code, and should perform better (well, on x86_64 anyway, I am not an aarch64 expert). All while using safe Rust.
You can compare assembly on godbolt. The current version of encode_varint64 is 99 lines long and has ~10 labels, the new version is 27 lines long with only 3 labels.
I haven't included benchmarking numbers because I wasn't sure what characteristics you'd be looking for. Based on the x86_64 assembly, it should definitely out-perform. Anything in particular you are looking for there?
Edit: I also simplified encoded_varint64_len while I was at it. It gets nicer assembly as a result as well but obviously matters less.

Interestingly, the miri failure is in std:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=92348df8e81c457c63c78c0845bf9e3b.
fn main() {
    match 2u64.checked_pow(64) {
        Some(n) => println!("2^64: {n}"),
        None => {}
    };
}

Given this is a checked_* operation, I would not expect an overflow.
   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 0.33s
     Running `/playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/playground`
error: Undefined Behavior: overflowing shift by 64 in `unchecked_shl`
    --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:1181:5
     |
1181 | /     uint_impl! {
1182 | |         Self = u64,
1183 | |         ActualT = u64,
1184 | |         SignedT = i64,
...    |
1198 | |         bound_condition = "",
1199 | |     }
     | |_____^ overflowing shift by 64 in `unchecked_shl`
     |
     = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
     = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
     = note: BACKTRACE:
     = note: inside `core::num::<impl u64>::checked_pow` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:1382:31: 1385:18
note: inside `main`
    --> src/main.rs:2:11
     |
2    |     match 2u64.checked_pow(64) {
     |           ^^^^^^^^^^^^^^^^^^^^
     = note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info)

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

I opened an issue: https://github.com/rust-lang/rust/issues/120537.

I rebased, and Miri looks good for me 👍🏻

OK, if this is still an issue, some benchmark is needed. Smaller machine code does not mean code is faster.
(Project is not very well maintained now, so long responses, sorry.)

Re-analyzing this, I made a mistake previously: the jumps are actually quite predictable. With this in mind, I would expect this PR to be a slight regression (since it isn't unrolled), but it gave me some ideas to improve it...
...but then I realized that someone already beat me to these ideas: https://github.com/as-com/varint-simd. I think it's worth considering using their implementation on x86_64, but there's no point in doing it in this PR.
So for now, we'll just count the encoded_varint64_len as a win and not merge the rest.


avoid duplicated const in several packages

currently we have same const IngressPodName = "ingress-controller"
in both ingress-analyzer (internal to Connlist) and diff packages

to avoid this duplication by exporting  (TBD: where to export it)

additional duplication to consider: interfaces ConnListError and DiffEror are the same

[ ] resolve const IngressPodName = "ingress-controller" duplication
[ ]  avoid hard-coded/duplicated error messages for testing. Ideally, we should have a pkg with defined error strings as const values , that will be used both for error generation and for testing errors strings cross-packages. (see example)


Gracefully shutting down a TLS server sometimes leads to the client not receiving a response

hyper = { version = "=1.5.1", features = ["client", "http1"] }
hyper-util = { version = "=0.1.10", features = ["http1", "tokio", "server"] }

MacBook Pro 16-inch, 2019
2.4 GHz 8-Core Intel Core i9

I'm observing errors while testing graceful shutdown of a hyper server.
When gracefully shutting down a TLS connection the client will sometimes get an IncompleteMessage error.
This only happens for TLS connections. The graceful shutdown process is always successful for non-TLS connections.
reqwest::Error { kind: Request, url: "https://<IP_ADDRESS>:62103/", source: hyper_util::client::legacy::Error(SendRequest, hyper::Error(IncompleteMessage)) }

Given the following testing steps:

Start the server.
Send many concurrent requests to the server
Wait for any of the requests to receive a response.
(Since the request handler has a random sleep between 5-10ms we can be reasonably confident
that when we receive a response there are still some other requests that are in-progress.)
Tell the server to shut down. We expect that there are still some in-progress requests.
Assert that we receive a 200 OK response for each request.

When the hyper server is not using TLS, the test pass.
When the hyper server is using TLS, the test fails with an IncompleteMessage error.
I've created a repository that reproduces the issue https://github.com/chinedufn/hyper-tls-graceful-shutdown-issue
git clone https://github.com/chinedufn/hyper-tls-graceful-shutdown-issue
cd hyper-tls-graceful-shutdown-issue

# This always passes
cargo test -- graceful_shutdown_without_tls

# This always fails
cargo test -- graceful_shutdown_with_tls

Here's a quick snippet of the graceful shutdown code:
    let conn = builder.serve_connection(stream, hyper_service);
    pin_mut!(conn);

    tokio::select! {
        result = conn.as_mut() => {
            if let Err(err) = result {
                dbg!(err);
            }
        }
        _ = should_shut_down_connection => {
            conn.as_mut().graceful_shutdown();
            let result = conn.as_mut().await;
            if let Err(err) = result {
                dbg!(err);
            }
        }
    };

Here is the full source code for convenience (also available in the linked repository)

Cargo.toml (click to expand)
[package]
name = "hyper-graceful-shutdown-issue"
version = "0.1.0"
edition = "2021"
publish = false

# We specify exact versions of the dependencies to ensure that the issue is reproducible.
[dependencies]
hyper = { version = "=1.5.1", features = ["client", "http1"] }
hyper-util = { version = "=0.1.10", features = ["http1", "tokio", "server"] }
http-body-util = "=0.1.2"
futures-util = "=0.3.31"
rand = "=0.8.5"
reqwest = { version = "=0.12.9" }
rustls-pemfile = "2"
tokio = { version = "=1.41.1", features = ["macros", "net", "rt-multi-thread", "sync", "time"] }
tokio-rustls = "0.26"

Rust code (click to expand)
use futures_util::pin_mut;
use http_body_util::Empty;
use hyper::body::Bytes;
use hyper::body::Incoming;
use hyper::{Request, Response, StatusCode};
use hyper_util::rt::{TokioExecutor, TokioIo};
use rand::Rng;
use rustls_pemfile::{certs, pkcs8_private_keys};
use std::io::{BufReader, Cursor};
use std::net::SocketAddr;
use std::sync::Arc;
use std::time::Duration;
use tokio::io::{AsyncRead, AsyncWrite};
use tokio::net::{TcpListener, TcpStream};
use tokio::sync::watch::Sender;
use tokio::sync::{oneshot, watch};
use tokio_rustls::rustls::pki_types::PrivateKeyDer;
use tokio_rustls::rustls::server::Acceptor;
use tokio_rustls::rustls::ServerConfig;
use tokio_rustls::LazyConfigAcceptor;

#[derive(Copy, Clone)]
enum TlsConfig {
    Disabled,
    Enabled,
}

async fn run_server(
    tcp_listener: TcpListener,
    mut shutdown_receiver: oneshot::Receiver<()>,
    tls_config: TlsConfig,
) {
    let enable_graceful_shutdown = true;

    let (wait_for_requests_to_complete_tx, wait_for_request_to_complete_rx) =
        watch::channel::<()>(());
    let (shut_down_connections_tx, shut_down_connections_rx) = watch::channel::<()>(());

    loop {
        tokio::select! {
            _ = &mut shutdown_receiver => {
                drop(shut_down_connections_rx);
                break;
            }
            conn = tcp_listener.accept() => {
                tokio::spawn(
                    handle_tcp_conn(
                        conn,
                        wait_for_request_to_complete_rx.clone(),
                        shut_down_connections_tx.clone(),
                        tls_config
                    )
                );
            }
        }
    }

    drop(wait_for_request_to_complete_rx);

    if enable_graceful_shutdown {
        wait_for_requests_to_complete_tx.closed().await;
    }
}

async fn handle_tcp_conn(
    conn: tokio::io::Result<(TcpStream, SocketAddr)>,
    indicate_connection_has_closed: watch::Receiver<()>,
    should_shut_down_connection: watch::Sender<()>,
    tls_config: TlsConfig,
) {
    let tcp_stream = conn.unwrap().0;

    let builder = hyper_util::server::conn::auto::Builder::new(TokioExecutor::new());

    match tls_config {
        TlsConfig::Disabled => {
            let stream = TokioIo::new(tcp_stream);

            handle_tokio_io_conn(builder, stream, should_shut_down_connection).await
        }
        TlsConfig::Enabled => {
            let acceptor = LazyConfigAcceptor::new(Acceptor::default(), tcp_stream);
            tokio::pin!(acceptor);

            let start = acceptor.as_mut().await.unwrap();

            let config = rustls_server_config();
            let stream = start.into_stream(config).await.unwrap();
            let stream = TokioIo::new(stream);

            handle_tokio_io_conn(builder, stream, should_shut_down_connection).await
        }
    };

    drop(indicate_connection_has_closed);
}

fn rustls_server_config() -> Arc<tokio_rustls::rustls::ServerConfig> {
    let mut cert_reader = BufReader::new(Cursor::new(ssl_cert::TLS_CERTIFICATE_SELF_SIGNED));
    let mut key_reader = BufReader::new(Cursor::new(ssl_cert::TLS_PRIVATE_KEY_SELF_SIGNED));

    let key = pkcs8_private_keys(&mut key_reader)
        .into_iter()
        .map(|key| key.unwrap())
        .next()
        .unwrap();

    let certs = certs(&mut cert_reader)
        .into_iter()
        .map(|cert| cert.unwrap())
        .collect();

    let config = ServerConfig::builder()
        .with_no_client_auth()
        .with_single_cert(certs, PrivateKeyDer::Pkcs8(key))
        .unwrap();

    Arc::new(config)
}

async fn handle_tokio_io_conn<T: AsyncRead + AsyncWrite + Unpin + 'static>(
    builder: hyper_util::server::conn::auto::Builder<TokioExecutor>,
    stream: TokioIo<T>,
    should_shut_down_connection: Sender<()>,
) {
    let should_shut_down_connection = should_shut_down_connection.closed();
    pin_mut!(should_shut_down_connection);

    let hyper_service = hyper::service::service_fn(move |_request: Request<Incoming>| async {
        let jitter_milliseconds = rand::thread_rng().gen_range(0..5);
        let sleep_time = Duration::from_millis(5) + Duration::from_millis(jitter_milliseconds);

        tokio::time::sleep(sleep_time).await;

        let response = Response::builder()
            .status(StatusCode::OK)
            .body(Empty::<Bytes>::new())
            .unwrap();
        Ok::<_, &'static str>(response)
    });

    let conn = builder.serve_connection(stream, hyper_service);
    pin_mut!(conn);

    tokio::select! {
        result = conn.as_mut() => {
            if let Err(err) = result {
                dbg!(err);
            }
        }
        _ = should_shut_down_connection => {
            conn.as_mut().graceful_shutdown();
            let result = conn.as_mut().await;
            if let Err(err) = result {
                dbg!(err);
            }
        }
    };
}

/// The key and certificate were generated using the following command:
/// ```sh
/// # via https://letsencrypt.org/docs/certificates-for-localhost/#making-and-trusting-your-own-certificates
/// openssl req -x509 -out local_testing.crt -keyout local_testing.key \
///   -newkey rsa:2048 -nodes -sha256 \
///   -subj '/CN=localhost' -extensions EXT -config <( \
///    printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
/// ```
mod ssl_cert {
    pub(super) const TLS_CERTIFICATE_SELF_SIGNED: &'static str = r#"-----BEGIN CERTIFICATE-----
MIIDDzCCAfegAwIBAgIUaQDe0cAZUax+1IpET1vF8UFm3jswDQYJKoZIhvcNAQEL
BQAwFDESMBAGA1UEAwwJbG9jYWxob3N0MB4XDTI0MTAyMjExMjYyMFoXDTI0MTEy
MTExMjYyMFowFDESMBAGA1UEAwwJbG9jYWxob3N0MIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAsJGiYaWK0k6NT6J4uFyzPiTFGkjQ5K77dKBXrcwjz4LT
vsxUFAAyrV8GYIWJaaEKKD5WqF/B8WN1Di3+Ut8dxR7buDWgNN3R7qsp43IaTNsV
ORaN72DogMd94NzNVbAiqh+rjBNMyU/7AXwSifBbMzx/FL9KmGU5XejJtSx0EAd1
yV+cL+s/lWgDd0A82DdpZYNSfk5bQ6rcQis803VIqoVDM+4u85y/4wCR1QCQeGhr
YIeqwfGwf4o3pXB/spE2dB4ZU/QikYcTrUWVZ9Fup4UomUlggV9J0CuphjADdQxW
Nv3yH7HqgjmHl6h5Ei91ELjMH6TA2vwb3kv4bLoX/wIDAQABo1kwVzAUBgNVHREE
DTALgglsb2NhbGhvc3QwCwYDVR0PBAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMB
MB0GA1UdDgQWBBTHjwqKi5dOeMSjlhhahDEEMPQBQjANBgkqhkiG9w0BAQsFAAOC
AQEACJo+lYhAtZgGkIZRYzJUSafVUsv2+5aFwDXtrNPWQxM6rCmVOHmZZlHUyrK/
dTGQbtO1/IkBAutBclVBa+lteXFqiOGWiYF+fESioBx7DEXQWgQJY4Q5bYSHUkNu
u7vKXPt+8aAaaKQA8kR5tEO/+4atlD619kor4SwajOMWX2johgNku5n6mZ+fldQj
5Bv7PhPWZjpBJoqaXkHWJiT449efJQsiHAXY73eLmUf4kuJjQLuPXwZ/TY3KeH8a
tuWXtYQp1pU60yRzrO8JJ/4gj1ly/bzs9CTaD/u6hmpbdMdgZRR5ZZqvK3KYyI82
3TfEIvddnICP7SnH+BUzCQJhXg==
-----END CERTIFICATE-----"#;

    pub(super) const TLS_PRIVATE_KEY_SELF_SIGNED: &'static str = r#"-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCwkaJhpYrSTo1P
oni4XLM+JMUaSNDkrvt0oFetzCPPgtO+zFQUADKtXwZghYlpoQooPlaoX8HxY3UO
Lf5S3x3FHtu4NaA03dHuqynjchpM2xU5Fo3vYOiAx33g3M1VsCKqH6uME0zJT/sB
fBKJ8FszPH8Uv0qYZTld6Mm1LHQQB3XJX5wv6z+VaAN3QDzYN2llg1J+TltDqtxC
KzzTdUiqhUMz7i7znL/jAJHVAJB4aGtgh6rB8bB/ijelcH+ykTZ0HhlT9CKRhxOt
RZVn0W6nhSiZSWCBX0nQK6mGMAN1DFY2/fIfseqCOYeXqHkSL3UQuMwfpMDa/Bve
S/hsuhf/AgMBAAECggEANKEsPBvaXaZxY4fDoPxspvzRzWxf65ImvJQgnlrHX86Y
q/n+o7mNYXT+Ex4qn9QTEXzHWse0KO3i0beu42fC2WNBzc4aMzfdH91gDn4PzdHN
qScKZoxFsUEFSdW21LA8HOZ0vTtxe13+LOqdIgWFQafqHzaHlxYw+8dr/DdEXxRC
xh2U9xlrgplz2VJW+NhvIUJoBpsvRJ0XK58Cs0L7+CHrdaUmtL6gLehp49wPy810
l2r168CcHw/HdYN2SKtA3l2EldyZ0BdgHnblq9ozY8isTCn1ccQE8sr1Id1rCj26
BlyVoZurukB1tYTtf9LvQnC6MPdcC7hbHkpYGvFcKQKBgQDrZmLhNNL8aj5iCwXg
BnqTFBSvkADPE7inI/iPy69Q3k87LHM27uUQy0wzJow4HrfQNSE3HN0gHo7K8/KB
n+vR0QCmYu5x7Uk994RBzub+8QfEPVP3yJP5MgbaT68L7BwiaWkVTU+sLIXVCxAl
OsYGtXrsvBdEVKLKiCCxVQR32QKBgQDABUTBKFCtlMNrK8MM9h/9ddMHv2QH6hd3
x8mijKEsLvjRDYUzAWd2a2Rabo4Wf9kv7R/dGR/3jWp+84rgmr9s/XS6pABoCYjJ
RNQ6kD+b+apSTybToTFJ78hhdfAeT4IzrxdbHMOOlZl86R8IpDzTubJAAMrnJxpX
+prSi8E/lwKBgGhX+BiPi75rcb+P10jYVlj/m7O+hz1DJqSf4zwKM2oLQN+f8mo1
NsBc/SfnPFxb8WqPQmvllXb5VJ5Nx/8BXkyg8kLOs5c4cTDQmIV7KxVyzdiEvsWk
2UKqlDMNAzCrtkTiqLvSizBsg95NixiVltW+eACb10xon8ha0vMIFnTxAoGBAIL/
lSZJgLDK+n6Uvl6LUsuxpCR296FGnHgE/pQ8aIAiE3FbTfG8FX9+SFpBbgH/eoXt
uX029M4H1g2BzM7qA4oxZ38k/3n6dy0IHdlOK3cXXpEEmrJqF5wfT47dzNCA4Yys
+LwZ5XfSq4HB8IAOu8iduPNdFw+XZ6t5tkHJQi9FAoGAU+39yLcc1c1gWQw4UCuU
D2vlTSSR7U0ji23goHYFGyIxmJNa1lpx/jxOlHSu99PNhx87FTDyW5HuoaayyUyw
dK+3pvS6KhSQMCrcpdAND5sRV3KsGGdYpy/ICmVFeK9f26VMOTN3jdCqLR+gnAaY
fuCBU0U/o2qoHC7VjsfzQZw=
-----END PRIVATE KEY-----"#;
}

#[cfg(test)]
mod tests {
    use super::*;
    use std::future::Future;

    use hyper::StatusCode;
    use tokio::sync::mpsc;

    /// This always passes.
    #[tokio::test]
    async fn graceful_shutdown_without_tls() {
        test_graceful_shutdown(TlsConfig::Disabled).await
    }

    /// This always fails.
    #[tokio::test]
    async fn graceful_shutdown_with_tls() {
        test_graceful_shutdown(TlsConfig::Enabled).await
    }

    /// ## Steps
    /// - Start the server.
    /// - Send many concurrent requests to the server
    /// - Wait for any of the requests to receive a response.
    ///   Since the request handler takes a random amount of time we can be reasonably confident
    ///   that when we receive a response there are still some other requests that are in-progress.
    /// - Tell the server to shut down. We expect that there are still some in-progress requests.
    /// - Assert that we receive a 200 OK response for each request.
    ///   This means that the graceful shutdown process was successful.
    async fn test_graceful_shutdown(tls_config: TlsConfig) {
        // We repeat the test multiple times since the error does not always occur.
        const TEST_REPETITION_COUNT: usize = 100;

        for _ in 0..TEST_REPETITION_COUNT {
            let tcp_listener = TcpListener::bind(SocketAddr::from(([127, 0, 0, 1], 0)))
                .await
                .unwrap();
            let addr = tcp_listener.local_addr().unwrap();

            let (shutdown_sender, shutdown_receiver) = oneshot::channel();
            let (successful_shutdown_tx, successful_shutdown_rx) = oneshot::channel();

            // Spawn the server in a separate async runtime so that once the server stops the
            // runtime will stop.
            // This ensures that when the server stops the runtime will stop and all other tasks
            // will be immediately dropped.
            // This way if we receive responses from the server we know that the server did not
            // shut down until after the request tasks finished running.
            std::thread::spawn(move || {
                tokio::runtime::Runtime::new()
                    .unwrap()
                    .block_on(async move {
                        run_server(tcp_listener, shutdown_receiver, tls_config).await;
                        successful_shutdown_tx.send(()).unwrap();
                    })
            });

            let mut request_handles = vec![];

            let (response_received_tx, mut response_received_rx) = mpsc::unbounded_channel();

            // An arbitrarily chosen number of requests to send concurrently.
            const CONCURRENT_REQUEST_COUNT: usize = 10;
            for _ in 0..CONCURRENT_REQUEST_COUNT {
                let response_received_tx = response_received_tx.clone();
                let handle = tokio::spawn(async move {
                    let result = send_get_request(addr, tls_config).await;
                    response_received_tx.send(()).unwrap();
                    result
                });
                request_handles.push(handle);
            }

            // Wait to receive the first response, and then shut down the server.
            // Since we sent many requests to the server we are confident that some of them have not
            // yet completed.
            // This means that if all requests get a 200 OK response then the graceful shutdown
            // process was successful.
            let _wait_for_first_response = response_received_rx.recv().await.unwrap();
            shutdown_sender.send(()).unwrap();

            // Check that every request received a 200 response.
            // We panic if a request ended with an error.
            for handle in request_handles {
                let result = handle.await.unwrap();
                match result {
                    Ok(status_code) => {
                        assert_eq!(status_code, StatusCode::OK);
                    }
                    Err(err) => {
                        panic!(
                            r#"
Error during the request/response cycle:
{err}
{err:?}
"#
                        )
                    }
                }
            }

            // Make sure that the server gets shut down.
            // If it was shut down and every request succeeded then we ca be confident that the
            // graceful shutdown process worked.
            let _did_shutdown = wait_max_3_seconds(successful_shutdown_rx).await;
        }
    }

    async fn send_get_request(
        addr: SocketAddr,
        tls_config: TlsConfig,
    ) -> Result<StatusCode, reqwest::Error> {
        let uri = match tls_config {
            TlsConfig::Disabled => {
                format!("http://{addr}")
            }
            TlsConfig::Enabled => {
                format!("https://{addr}")
            }
        };

        let client = reqwest::Client::builder()
            // We use a self-signed cert for localhost. Here we're trusting that self-signed cert.
            .danger_accept_invalid_certs(true)
            .build()?;
        let response = client.get(uri).send().await.map(|r| r.status());
        response
    }

    /// Used to prevent the test from running indefinitely.
    async fn wait_max_3_seconds<T>(fut: impl Future<Output = T>) {
        tokio::time::timeout(std::time::Duration::from_secs(3), fut)
            .await
            .unwrap();
    }
}

Have you been able to trace what is happening? One thing that sort of sounds like is that the TLS stream perhaps hasn't flushed the response before closing?

But do you know for sure all the requests have indeed started? Or could the shutdown be triggered just before hyper has been able to see the request bytes?

Or could the shutdown be triggered just before hyper has been able to see the request bytes?

Seems to be the problem. Most of this comment is how I arrived at that. Skip to the end for a potential solution.

Did a bit of hyper=trace,hyper_util=trace tracing before opening the issue but nothing jumped out at me.
Hmm, so if I sleep for 1ms before dropping the watch::Receiver that serves as the shut down signal then the test passes.
As in, a sleep before this line: https://github.com/chinedufn/hyper-tls-graceful-shutdown-issue/blob/7c3d52f54e839096022a3e9b7b478ad0a635293a/src/lib.rs#L42
Inlining the snippet code here for convenience:
    loop {
        tokio::select! {
            _ = &mut shutdown_receiver => {
                // ADDING THIS SLEEP MAKES THE TEST PASS
                tokio::time::sleep(std::time::Duration::from_millis(1)).await;
                drop(shut_down_connections_rx);
                break;
            }
            conn = tcp_listener.accept() => {
                tokio::spawn(
                    handle_tcp_conn(
                        conn,
                        wait_for_request_to_complete_rx.clone(),
                        shut_down_connections_tx.clone(),
                        tls_config
                    )
                );
            }
        }
    }

The drop(shut_down_connections_rx) shut down signal causes this Connection::gracful_shutdown tokio::select! branch to be selected.
https://github.com/chinedufn/hyper-tls-graceful-shutdown-issue/blob/7c3d52f54e839096022a3e9b7b478ad0a635293a/src/lib.rs#L145-L159
Inlining the snippet here for convenience:
    tokio::select! {
        result = conn.as_mut() => {
            if let Err(err) = result {
                dbg!(err);
            }
        }
        _ = should_shut_down_connection => {
            conn.as_mut().graceful_shutdown();
            let result = conn.as_mut().await;
            if let Err(err) = result {
                dbg!(err);
            }
        }
    };

Key Points
The test passes if we sleep for a millisecond before sending on the channel that leads to conn.as_mut().graceful_shutdown(); getting called for all open connections.
i.e. if we sleep for one millisecond right before this line: https://github.com/chinedufn/hyper-tls-graceful-shutdown-issue/blob/7c3d52f54e839096022a3e9b7b478ad0a635293a/src/lib.rs#L42
If I instead move the sleep to just before the conn.as_mut().graceful_shutdown(); line, the test fails, even if we sleep for 1, 5 seconds, 50milliseconds or seemingly any other amount of time.
( i.e. if we sleep for five seconds right before this line the test will fail -> https://github.com/chinedufn/hyper-tls-graceful-shutdown-issue/blob/7c3d52f54e839096022a3e9b7b478ad0a635293a/src/lib.rs#L152 )
( I also confirmed that sleeping for 50 milliseconds leads the test to fail.)
This suggests that the problem occurs when we call Connection::graceful_shutdown before we've started polling the connection and receiving bytes.
It looks like graceful_shutdown calls disable_keepalive, and disable_keepalive closes the connection if no bytes have been received.
https://github.com/hyperium/hyper/blob/master/src/proto/h1/dispatch.rs#L90-L100

Or could the shutdown be triggered just before hyper has been able to see the request bytes?

Yeah seems like this is the problem.
Problem
Currently, if a user opens a TCP connection to a server and the server calls Connection::graceful_shutdown before any bytes have been received, the TCP connection will be closed.
This means that if the client has just begun transmitting packets, but the server has not received them, the client will get an error.
This is not a graceful shutdown since the client was not made aware that the connection was going to be closed.
Potential Solutions
One way to avoid such an error would be to something like:

Server somehow indicates to client that the connection will close
Client receives indication that server is planning to close the connection
If the client has not yet sent any data, server waits for Duration "W" (configurable) to see if the client sends any packets
If the client DOES NOT send any packets after the wait Duration "W", close the connection
If the client DOES send packets before the wait Duration "W", receive the bytes and then close the connection

I'm unfamiliar with the TCP spec, but from some quick searching it the FIN segment might be useful here?
I can do more research if the above steps seem like a good path forward.
Is this a viable path forward?

Are you aware that an HTTP keep alive is different from a TCP keep alive? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive
If the server disables HTTP Keep-Alive it is indicating to the client that at most one more HTTP request will be processed.
I ask because I'm not seeing how the steady stream of packets concept is relevant here.
If a single request takes more than some amount of time the hyper user can just close the connection and shut down their server.
And disabling HTTP keep-alive means that no new requests will be accepted.
So at the time of shut down we only care about whether to finish handling the current/next request.

The idea is that if a connection has been opened and 0 requests have been received by the server, either:

the client is well-behaved and is about to send the request bytes to the server
OR the client is well-behaved but their connection closed and the bytes will never reach the server
OR the client is an attacker and wants to hold the connection open indefinitely

I'm suggesting that it should be possible to accept one more request from a well-behaved client whose bytes we are, say, milliseconds away from beginning to process.
Whereas right now if we would have received final request's the bytes in 5 milliseconds hyper doesn't care and will close the connection. (or at least that's my current understanding. not familiar enough with TCP / HTTP to be sure that that's the case here).

Are you aware that an HTTP keep alive is different from a TCP keep alive?

Not familiar with the details, just read up on it, doesn't seem like anything about the argument I put forward should change in light of this (maybe I'm missing something!). The argument was intended to be robust regardless of any other details, and I think it still is.
If this keepalive stuff implies that the server is actually doing something against the standards by sending a RST without warning, then ignore everything I've said. Let's keep hyper conformant. But I'm under the impression that hyper's current behavior is fine, at least on the TCP layer. If there's something wrong on the HTTP layer, I'm missing it.

I ask because I'm not seeing how the steady stream of packets concept is relevant here.

I'll re-word my argument above. It's a bit more sloppy, but a bit more concrete:

Let's say we get a packet every 10ms, indefinitely.
Let's say graceful shutdown is called.
Should we wait for 10ms to handle the next packet? I claim there's no point in any practical situation. If we think it's important to handle the next packet, why? Let's suppose there's a good reason. We handle it. Now there's another packet in 10ms. Surely the reason from before applies again. So we handle the next packet. etc. etc. etc. My point is that there's no good reason to wait 10ms.

Similarly, again making the steady-stream assumption:

Server receives a connection. In 10ms the server received a request from the connection, for each connection. A connection comes in every 10ms. Each connection is closed soon afterward.
Should we wait 10ms to handle the next request on the already-alive connection? No. If there's any good argument to do so, then we handle it, but then the next connection opens before the previous one is done. And the same ad-infinitum reasoning goes.

If this reasoning seems rather abstract, that's fair and I wish I could do better (in a pragmatic sense), but the argument nonetheless implies that there's no real case where this should matter, and this is just a very abstract way of making that point (recursive induction, then a reducto-ad-absurdum). [Then why do it this way? So that it's robust.]
If you've got a real use case in mind where this change in behavior makes a crucial difference, then I must have made a mistake somewhere.

I'm suggesting that it should be possible to accept one more request from a well-behaved client whose bytes we are, say, milliseconds away from beginning to process.

I agree, this will usually be the case. I don't think it would be bad to do this, assuming the cost is zero (increased complexity in the hyper API, for example). But it won't help with any real use case.

This issue is about figuring out the best way to get those bytes (be it via hyper or userland)

This is assuming that there's a good reason to get those bytes. I've made the case that there isn't one.

If that holds it's reasonable for a maintainer of a hyper based server to want to disable HTTP Keep-Alive and then wait a couple seconds before terminating the connection.

Only if it makes a difference to clients or the server in general. But it does not by the above.

What I fear is that we're inventing a use-case that doesn't exist outside of our one test, and expecting hyper to support that.

Should we wait for 10ms to handle the next packet?

This line of reasoning misunderstands what an HTTP graceful shutdown is.
An HTTP graceful shutdown is basically "if there is a request that is already in progress, finish responding and then close the connection".
So, yes you should continue receiving those packets every 10ms until so timeout is reached. In a production system that timeout might be in the neighborhood of 30 seconds.

Should we wait for 10ms to handle the next packet?

Today, if Connection::graceful_shutdown is callef after hyper has already begun receiving packets it will continue to until the request is complete. It will close the connection after the response has been sent.
https://github.com/hyperium/hyper/blob/4ffaad53c78572c500584e0cb5d76ae6ffc6adb6/src/proto/h1/dispatch.rs#L90-L100
So, hyper already exhibits this "continue reading packets" behavior under some circumstances.

A connection is established every 10ms.

This does not apply. During a graceful shutdown you would stop accepting new TCP connections.
Here is an example from this issue's linked repository: https://github.com/chinedufn/hyper-tls-graceful-shutdown-issue/blob/7c3d52f54e839096022a3e9b7b478ad0a635293a/src/lib.rs#L39-L56

If you've got a real use case in mind where this change in behavior makes a crucial difference, then I must have made a mistake somewhere.

It's hard for me to try to provide new use cases when your argument is already arguing against how hyper currently works. That leaves me thinking that there's a misunderstanding.
hyper already does everything that you're claiming is bad (continuing to accept packets after Connection::graceful_shutdown is called).
It does this because that is was a graceful shutdown is. Continuing to process a request before closing the connection.

I'm coming back to this having caught up some sleep and with some further discussion. My main concerns were that the benefit was negligible and the only cases it mattered were artificial. I disagree with these two conclusions now.
Here's my current take of why I think this should be fixed:

Because this only happens with TLS configured, this appears to be an inconsistency that's probably better off being fixed. (Better documentation about graceful_shutdown's intended behavior in general would be valuable, even if it's noncommital about what may change in the future, though that would be useful too.)
Assuming the server is shut down and clients will fail to make requests from there, onwards is an assumption I implicitly made that doesn't necessarily hold. For example, shutting down a main server in favor of a backup, or vice-versa. In which case, changing the graceful_shutdown as pushed for by @chinedufn would help avoid any error conditions as far as the client is concerned. This will likely be useful to us in the future.
Furthermore, while in other cases, being aggressive about shutting down connections without a request received yet isn't better in a make-or-break sense than being more lenient on recently opened connections, it would be marginally better.
I was also assuming that we always controlled the client. This is not the case, and it would be better to reduce the potential error conditions we could be exposing clients to.

Therefore, I think this issue is worth solving. Sorry about all the noise I've added to the issue, feel free to hide my comments to keep things organized.

I do agree with some of the points brought up:

A client does need to handle that the connection could die, or that the server could close it on a timeout.
If we add a timeout, it only helps in this specific case. No matter how long the timeout is, there will always be a case where if we had waited just a little longer, we'd be able to read the request.

It seems likely that in this case, the time it takes to write/encrypt/read/decrypt is just enough that the tiny timeout used can beat it.

Definitely agree that a timeout wouldn't solve 100% of cases.
My thinking is that if a client opens a connection they're either:

An attacker that would love to hold the connection open forever
A non-malicious user whose bytes we're about to receive in some small amount of time
A non-malicious user whose bytes might take a long time to reach us, or might never reach us

I'm not concerned about making things easier for the attacker (1).
I'd love to make things (slightly) easier for the non-malicious user who was about to give me bytes (2). I can save them a retry by handling the request.
But, yes, for case (3) if it takes to long to see your bytes we'll need to close the connection. Can't wait forever.
So, case (2) is what I'm interested in handling.
I am operating under the assumption (no data on this currently) that with a timeout of, say, 1-2 seconds, I could handle the overwhelming majority of "I was about to give you bytes but you closed the connection on me!" scenarios.
This means that my users see fewer errors, at nearly no expense to my server (I'm already comfortable taking up to 30 seconds to handle any in-progress requests before closing all connections. This 1-2 seconds would just come from that 30 second budget.)
Only trade-off I can imagine is hyper becoming more complex in the name of solving an edge case that a client should probably already be prepared for.
I'd say that saving the extra retry request for the client is worth it if the cost to hyper's API surface area is negligible (or maybe it's already possible/easy for a user to disable keep alive on the HTTP connection?).
The use case that I imagine is a server that sees heavy consistent traffic and is gracefully shut down often (say, every hour when the maintainers redeploy a new version of it).
Solving this means the server's client's will see fewer errors than they otherwise would have.

Are you open to solving this "problem" (I recognize that one might argue that it isn't a problem and the client should just be expected to retry) in hyper, assuming there was a good way to do so?
Do any of the potential solutions that I've left in my previous comment seem reasonable?
I'm happy to do the work required to land a solution to the "decrease the number of connections that get closed when we could have reasonably waited for a bit to get the data" problem (to repeat, yup I know we can't wait forever. I just want to reduce errors that users experience and recognize that I cannot fully eliminate them).

Alright I took a look at the hyper source and I think I have a reasonable solution.
To recap, the main problem is that hyper's graceful shutdown implementation currently leads to more errors than necessary.
This means that changing the graceful shutdown implementation will lead to a better experience for end clients, meaning that developers using hyper to write web servers will be able to build (slightly) more reliable systems.

Some background / related issues:
In Jan 1 2022 an issue called Connection::graceful_shutdown always waits for the first request was opened. https://github.com/hyperium/hyper/issues/2730
At the time, if you called Connection::graceful_shutdown, but the client never transmitted any bytes, the connection would remain open forever.
In July 2023 fix(http1): http1 server graceful shutdown fix https://github.com/hyperium/hyper/pull/3261 addressed that issue by making Connection::graceful_shutdown immediately close the connection if no bytes have been received.

Currently, calling Connection::graceful_shutdown will cause some clients to receive an error despite the server being perfectly willing and able to handle the request.
hyper should give server authors control over the grace period for graceful shutdowns so that they can decide what the best experience is for their end clients.
Similar to how hyper currently allows the server author to control the header read timeout using set_http1_header_read_timeout.
The same level of control should exist for graceful shutdowns.

Proposed Changes to Hyper
Here is how we can solve this graceful shutdown problem (clients unnecessarily getting errors when waiting a second or two before terminating an unwritten connection would have given nearly every connection a chance of being gracefully handled).
Currently, Connection::graceful_shutdown will immediately close the connection if no bytes have been written.
Solution -> Connection::graceful_shutdown will immediately disable keepalive, but then schedule a future for closing the connection, similar to how the h1_header_read_timeout_fut works: https://github.com/hyperium/hyper/blob/c86a6bcb4acb0f92e731ea2e4c1e4a839248a600/src/proto/h1/conn.rs#L238-L272
So, something like a set_http1_graceful_shutdown_read_timeout (that's a made up messy name).
By default the http1_graceful_shutdown_read_timeout duration is 0 seconds. This preserves the current behavior, meaning that hyper users experience zero changes in behavior.
Hyper users can use set_http1_graceful_shutdown_read_timeout to increase that timeout (i.e. to 2 seconds, if they like), which should let them reduce the number of errors that they experience.
This allows us to make this change now since we can fully preserve the current behavior entirely.
Then we can take as much time as we like to decide whether the default should be changed from 0 seconds to something else. (I haven't thought much about this ... but 0 seems wrong since it guarantees that a high traffic server's clients will get errors whenever the server is taken down ... something like 1-5 seconds would eliminate nearly all of those errors... so that's probably a better default..)
To summarize the benefits of this solution:

non-breaking API change

preserves the current behavior (albeit flawed behavior since I'd expect most people running production web servers to prefer a default of, say, 2 seconds over 0 seconds)

Next Steps
I'm planning to work on implemeneting this this week. Planning to use some of the tests in tests/server.rs as a guide for how to introduce new tests. i.e. https://github.com/hyperium/hyper/blob/c86a6bcb4acb0f92e731ea2e4c1e4a839248a600/tests/server.rs#L1542-L1561
Please let me know if you see any issues with this proposed solution.

Looks like the HTTP/2 spec has support for preventing the problem that this issue is about.

A client that is unable to retry requests loses all requests that are
in flight when the server closes the connection.  This is especially
true for intermediaries that might not be serving clients using
HTTP/2.  A server that is attempting to gracefully shut down a
connection SHOULD send an initial GOAWAY frame with the last stream
identifier set to 2^31-1 and a NO_ERROR code.  This signals to the
client that a shutdown is imminent and that initiating further
requests is prohibited.  After allowing time for any in-flight stream
creation (at least one round-trip time), the server can send another
GOAWAY frame with an updated last stream identifier.  This ensures
that a connection can be cleanly shut down without losing requests.

via: https://datatracker.ietf.org/doc/html/rfc7540#section-6.8
hyper's HTTP/2 graceful shutdowns are implemented properly.
So, looks like only HTTP/1 connections are experience this unnecessarily-dropping-requests-from-well-behaved-clients issue.
https://github.com/hyperium/h2/blob/3bce93e9b0dad742ffbf62d25f9607ef7651a70c/src/proto/connection.rs#L582-L605
hyper's HTTP/2 implementation follows the spec's recommendations of waiting for at least one round-trip time before ceasing to accept new request streams.

Note that since HTTP/1's disable keepalive means that only one more request will be processed, we can't mimic this HTTP/2 behavior of allowing many not-yet-received requests
to get processed.
As in, if the client sent 10 requests that did not yet reach the server when .graceful_shutdown() was called, in HTTP/2 we can still process all ten, whereas in HTTP/1 we'll only
process whichever one we receive first.

Current progress: I wrote some tests and got them passing. Still need to clean up the code. Planning to submit a PR this week.
The change to the public API is a Connection::graceful_shutdown_with_config method that lets you configure a Duration for HTTP/1 connections to wait before closing the inactive connection.
The existing Connection::graceful_shutdown method sets the wait period to 0 seconds.
No timer is required when the Duration is 0 (making this a fully non-breaking change).

I've confirmed that HTTP/2 hyper servers do not suffer from this issue.
I confirmed this by enabling the rust-tls feature on reqwest and then using ClientBuilder::use_rustls_tls to make reqwest use HTTP/2.
When I use use_rustls_tls this issue cannot be reproduced. When I comment out use_rustls_tls this issue happens again.


variables undefined after task.sleep

This issue is dependent on ... something else ... that I can't quite figure out. It doesn't happen every time, so a simplified test doesn't show the issue immediately.
In a Class Method:
        start_sleep = time.monotonic()
        task.sleep(self.timeout)
        elapsed_sleep = time.monotonic() - start_sleep

Error:
2020-10-11 06:14:12 ERROR (MainThread) [custom_components.pyscript.apps.occupancy_manager.inner_occupied_states] Exception in <apps.occupancy_manager.inner_occupied_states> line 224:
            elapsed_sleep = time.monotonic() - start_sleep
                                               ^
NameError: name 'start_sleep' is not defined

This appears to be happening outside of a class as well.

So far I'm not able to replicate this.  Could this case be connected to reload?

Perhaps? I just restarted Home Assistant (to add full traceback). I will need to restart pyscript once when it starts (because for some reason my YAML defined apps don't load without a restart, I've yet to debug that and report). But, aside from that one restart, I'll leave it be for a bit and see if it happens again.

It looks like the new config flow check breaks the initial config settings, which requires a reload.

Ah, glad you found that. I still hadn't gotten around to writing a proper, concise test case for it. Thanks!

The original issue (variables undefined after task.sleep) seems to have been resolved. I will open a new issue if it presents again.
Leaving this open for now in case you're using it to track "failure to load initial config values".

The config loading is being addressed in #39.


Which part of the state is updated

Something is still not clear to me. How reducer exactly knows which part of the Store to change.
If Store keeps instance of the following interface:
export interface AppStore {   items: Item[];   selectedItem: Item;   widgets: Widget[];   selectedWidget: Widget;   };
How items reducer exactly knows which part of the Store he has to change?
In my example, there is a reducer for items:
export const items = (state: any = [], {type, payload}) => {   switch (type) {     case 'ADD_ITEMS':       return payload;     case 'CREATE_ITEM':       return [...state, payload];     case 'UPDATE_ITEM':       return state.map(item => {         return item.id === payload.id ? Object.assign({}, item, payload) : item;       });     case 'DELETE_ITEM':       return state.filter(item => {         return item.id !== payload.id;       });     default:       return state;   } };
How exactly this reducer knows that he has to change items attribute of the AppStore object?
I'm working using this example:
https://github.com/onehungrymind/fem-ng2-ngrx-app
Thx for helping

I believe this happens when you bootstrap the provider.
StoreModule.provideStore({items, selectedItem, selectedWidget})
"items" represents your items reducer in your app store.

Yes yes, that is correct, but when reducer is executed, how reducer knows which part of the store to change?

@amirduran it doesn't. each reducer is called with each action, for every action. its up to the developer to either handle that action or simply ignore it.

each reducer can only update its own part of the state. So your items reducer can only update items. It does not even have access to a different part of the state.

@littleStudent Exactly what I was looking for. Thank you for answering.
The last question 😃  where do I tell reducer for which part of the state is reducer responsible? Does library implicitly recognise that by having same names for store elements and reducer names?

take a look at the example in the readme.
StoreModule.provideStore({ counter: counterReducer })

counterReducer handles one part of the state -> counter

@littleStudent That is what I thought 😄  Thank you mate


Added void cloak hood

About the PR

A hood for void cloak
Why / Balance

Void cloak has something like hood on back, but don't have it for real. So, why not to add it?
Technical details

yaml
Media

Requirements

[x] I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl: Dezzzix

add: Now you can wear a hood in void cloak

I'd add that void typing indicator as well!

The shading doesn't really match up with the cloak.

k, i'll resprite it

k, i'll resprite it

Are you coming back to this PR?

Are you coming back to this PR?

Yep, reshaded

can you make it so the sprite for the hood on the actual cloak is removed when the hood is up?

can you make it so the sprite for the hood on the actual cloak is removed when the hood is up?

wyci

can you make it so the sprite for the hood on the actual cloak is removed when the hood is up?

gigawyci


.vscode: fix tasks file

What
Format the VSCode tasks file.
Why
When I open the stellar/go repo locally in the latest version of VSCode it displays a warning saying the file is "dirty". It appears the file is not formatted to how VSCode prefers it to be formatted. I don't really know what this file does or is for, but supposedly it was added because somebody uses it. This change resolves the warning.
Known limitations
N/A

@bartekn I agree, we should keep ide specific files out of the repo. I think VSCode is probably the exception since GitHub has VSCode built into it's UI and it's the IDE for GitHub Codespaces.


Fix micro-agents schema bug

Some of the micro-agents' agent.yaml have schema definition errors, e.g.  RepoExplorerAgent. This PR fixes these bugs. ManagerAgent, however, is not added to integration tests as I can barely get it working with the task in the test: Write a shell script 'hello.sh' that prints 'hello'. Looks like micro-agents are not ready yet and may need more prompt tuning.
You can verify this fix locally by running any task that might trigger RepoExplorerAgent.
Fixes #1423

I don't think micro-agents are ready for integration testing yet, so I didn't add them to CI testing.

I've been debating whether to add the Agent suffix to everything

Aha, I had a guess you intentionally did so. But it looks a bit inconsistent as in there's no criteria which shall be an agent and which shall not be. To keep the consistency I added "Agent" as a suffix to each micro-agent.


Add label toggle on display card page.

Just a small accessibility option that may improve usability. On the display card page, besides just showing icons for account labels, it may be nice to have a toggle switch that allows a viewer to toggle the actual account labels, so they can see 'Instagram: @paytonshaltis' or 'Twitter: @paytonshaltis' instead of just 'icon @paytonshaltis'.

Where would the toggle go on the page?
I personally would opt for the label to be there so that it's explicitly obvious what each icon is, as some people will not be familiar with all of them.

Where would the toggle go on the page?

We could discuss this, but maybe at the top of the page somewhere. If the user has a lot of accounts, it may not be practical to put this at the bottom.

I personally would opt for the label to be there so that it's explicitly obvious what each icon is, as some people will not be familiar with all of them.

I'm OK with either one, I think we should see what everyone else thinks too @lelekaz @matyis1 @thadakn1. I figured that having this functionality gives us one more accessibility and shortcut feature: expert users can take advantage of icons only, eliminating redundant information, but newbie users can have both to learn.

I figured that having this functionality gives us one more accessibility and shortcut feature: expert users can take advantage of icons only, eliminating redundant information, but newbie users can have both to learn.

Gotcha. I think my main motive for pushing for the latter is that in the case of custom accounts where they don't have an obvious icon, it can become very confusing:

Like if they had 4 different icons like the bottom one but they weren't all as obvious as a url, then it would be hard to discern which platforms the handles belong to. If you just provide a label for everything from the beginning, then you won't encounter that issue. I am open to hearing what you guys think though.

i was thinking about this issue for a while, obviously it would look cleaner and consistent with the icon as opposed to text that explicitly indicates the platform. i was wondering what if when the user clicks on the icon, it temporarily shows the platform's name. so it's on the screen, but only if you aren't sure what that icon is representing. i think with the toggle feature, the screen would be overcrowded because it would display all of the platform names - when the highlight should be the account/user handles. lmk what you think @sderacy @paytonshaltis @lelekaz @matyis1

i was wondering what if when the user clicks on the icon, it temporarily shows the platform's name

I like it but the only issue is that there's currently no way for the user to know that they'd have to click on the icon.
I agree that there needs to be a better way to show the label, but it looks like there'd be space for the label to exist with the content:

It looks like the text will just wrap if the value is too long, so I would personally just make sure that the label text and icon stay on one line, and the value can do whatever else.
Keeping this in mind, I still think just showing the label all the time would be a better idea but we can also try to add some sort of text that's like "click me!" by an icon so that it shows the label next to it. The downside to this obviously is that it can still be confusing as the user would have to click an icon whenever they don't understand the meaning of a certain icon.

I think it'd be better to just look at the two options:

I agree that the second would look less sleek since there's more text that can be redundant, but this is more straightforward than having to click on every icon.
I don't mind the tooltip idea (after all, we're already using one in the footer), but there should be something explicitly telling the users to click the icon if they don't know what the icon represents.
If you want to add tool tips, just reuse some of the code in the footer since it's already being used there.

Yeah I'm down for any of these options. @paytonshaltis @thadakn1 @matyis1 Let us know what your thoughts are on this.

Are we adding the fix for this issue to PR #158 or is this going in a separate PR?

tooltips can be hard for screen-readers to capture and this poses an accessibility issue sometimes. looking at the designs that sterly posted, I actually like the idea of having the logo, the platform name, and then the account handle. it looks pretty clean!


Updating helix geometry classes

Starting to introduce myself with the code base, and helping out the TypeScript conversion effort!

Thank you!

Needed to tweak it, see above commit

Awesome, thank you! I was curious about the correct types of those variables, forgot to actually investigate further!


respect the license

@DarkStarSword already noticed to you, theres only one condition in the MIT license, to keep the copyright!
so please respect that and change the copyright back within the next seven days from now. otherwise i have to file a DMCA takedown to this fork.

OMG! Yes i am sorry. (New to github! many thinks to learn!). I change the license file. If you need anything else just say.

I delete all tags & releases with wrong license.
*Is there anything else to do?
(Thank you for your understanding. GitHub Newbie here;-))

If your issue has solved, please close it.
Thank you very much.

Now it's solved with 523ae89.


Nitro 2 - Keys command

Description
I was looking for the keys command for Nitro 2. I could not find thus function in Nitro 2.
After reading the thread #141, keys command seems to be a feature in Nitro 3, is it correct?
However, in Nitro 2, the command doesn't seem to exist. What command should I use to replicate the same function from Nitro 1 thekeys command?

The keys command copied you local SSH keys into the (v1) virtual machine. It does not exist in v2 as the system moved to a container based environment and the container home directory is not persistent, so you would have to run that command on a regular basis.
Can you provide some context on what exactly you are trying to achieve and there might be a better method here.

Hey @jasonmccallister, thank you for looking into this.
Wanted to mention Nitro 2 made such an  ease to start a project.
I'm trying to copy my local id_rsa to authenticate git account within the container. I'm trying to install private plugin via composer.json pointing to a private git repo which requires ssh auth to pull the file.
Thank you,
Antonio

Hi, we are closing this issue as we have decided to retire Nitro, so no additional work will occur on this project. You can read the official blog post here https://craftcms.com/blog/retiring-craft-nitro. We appreciate everyones feedback and involvement and we look forward to refocusing our efforts on Cloud!
If you're looking for a new local development environment, we recommend DDEV and have a knowledge base article to help you with the transition: https://craftcms.com/knowledge-base/migrating-from-craft-nitro-to-ddev.


kapacitor: 1.0.0 -> 1.4.0

Semi-automatic update. These checks were performed:

built on NixOS
ran /nix/store/zc5x872jh6g02y47rfa2giw7wjypnq12-kapacitor-1.4.0-bin/bin/kapacitord -h got 0 exit code
ran /nix/store/zc5x872jh6g02y47rfa2giw7wjypnq12-kapacitor-1.4.0-bin/bin/kapacitord help got 0 exit code
ran /nix/store/zc5x872jh6g02y47rfa2giw7wjypnq12-kapacitor-1.4.0-bin/bin/tickfmt help got 0 exit code
found 1.4.0 with grep in /nix/store/zc5x872jh6g02y47rfa2giw7wjypnq12-kapacitor-1.4.0-bin
found 1.4.0 in filename of file in /nix/store/zc5x872jh6g02y47rfa2giw7wjypnq12-kapacitor-1.4.0-bin

cc "@offline @ehmry @lethalman"

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘kapacitor-1.4.0’ in /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/servers/monitoring/kapacitor/default.nix:17 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Partial log (click to expand)
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/scripts/init.sh: interpreter directive changed from " /usr/bin/env bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/gobuild.sh: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/examples/error_percent/load.sh: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/examples/scores/scores.sh: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/build.sh: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/list-deps: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/circle-test.sh: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/test.sh: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
checking for references to /tmp/nix-build-kapacitor-1.4.0.drv-0 in /nix/store/arjrs7mg3rrbb7ipnbhsd3prjb4g5532-kapacitor-1.4.0...
/nix/store/zc5x872jh6g02y47rfa2giw7wjypnq12-kapacitor-1.4.0-bin

Success on aarch64-linux (full log)
Partial log (click to expand)
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/github.com/influxdata/influxdb/package.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/github.com/influxdata/influxdb/test.sh: interpreter directive changed from "/bin/bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/k8s.io/client-go/copy.sh: interpreter directive changed from "/bin/bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/golang.org/x/sys/unix/mkall.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/golang.org/x/sys/unix/mkerrors.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/google.golang.org/appengine/internal/regen.sh: interpreter directive changed from "/bin/bash -e" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash -e"
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/google.golang.org/grpc/codegen.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
/nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0/share/go/src/github.com/influxdata/kapacitor/vendor/google.golang.org/grpc/coverage.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/lnws52qanbi5vz8qg24v4ym57nznfndg-bash-4.4-p12/bin/bash"
checking for references to /build in /nix/store/lpm7hcz731zndas8bpk9gi09gdryy5ma-kapacitor-1.4.0...
/nix/store/yvgxgzdmsc970cym4nx1xl4kc7xdiiia-kapacitor-1.4.0-bin


Is this package supporting multi tenancy for clients connecting with Stripe?

Hi, sorry for the late anwser! COuld your please elaborate your question?

This package is deprecated, looking for a competitor. See this reddit post.


added prompts templates.

It's very convenient for people to use prompt templates. I've added prompt templates from awesome-chatgpt-prompts. I hope this can help the final user to use the LLM model.

@BobCN2017 thanks for the contribution! That is great work and will review it later.

Thanks for merging the PR.


Eval #2 Build

The next master build to include

Use Daylight White Balance for image acquisition   (mPreviewRequestBuilder)
Save and Display unenhanced cropped image but use enhancedResultWindow for peak detection and measurement.

Changes above will be merged  into the jwshires branch


Fix/tagging typeahead

Goal
Updating tagging to leverage open source libraries
Tagging now uses:

downshift
match-sorter
react-input-autosize

Todos:

[x] Add Downshift for typeahead
[x] Add Match-sorter for fuzzy matching
[x] Refactor tagging to leverage these tools

Implementation Decisions
Building a custom typeahead that was robust enough felt like wasted effort when so many excellent implementations exist.  Match Sorter added another layer of value.
All Submissions:

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Thanks Anthony!


Same internet connection event status is emitted multiple times consecutively for every change in the connection status

We use InternetConnectionChecker to listen for the network status change(i.e., connected or disconnected) in one of our mobile app. And for every connection status change(from connected to disconnected or disconnected to connected), same status events are fired multiple times.
For example if the status changes from disconnected to connected in the mobile phone, connected status is emitted multiple times consecutively in the listener.
Kindly request to help fix this issue.
InternetConnectionChecker().onStatusChange.listen((status){
switch (status) {
case InternetConnectionStatus.connected:
log('network connected');
break;
case InternetConnectionStatus.disconnected:
log(' network disconnected');
break;
}
}
});

@pratheshsanth This has been taken into consideration and the fix is available in the latest release of the package.


confused about the WORLD_SIZE setting on multi-GPU training.

@AngainorDev i wonder why the issue #332  and #182 has different world_size setting.
one is
WORLD_SIZE=1 CUDA_VISIBLE_DEVICES=0,1,2,3 python finetune.py --base_model /datas/alpaca_lora_4bit/text-generation-webui/models/llama-30b-hf --data_path /datas/GPT-4-LLM/data --output_dir ./lora-30B
the world_size is set to 1
and another is
OMP_NUM_THREADS=4 WORLD_SIZE=2 CUDA_VISIBLE_DEVICES=0,1 torchrun --nproc_per_node=2 --master_port=1234 finetune.py
the world_size is set to the num of GPUs.
is this the torchrun's feature or someone is wrong? thx

I think everyone is right, these are 2 different cases.
One is dataparallelism (full model on several gpus) while the other is model paralelism (one model split onto several gpus).
I did not tried the later myself so can't tell more.

Thanks for your fast response. I've got that.


Memory leak or OutOfMemoryError: Physical memory usage is too high - when using ZGC

I have asked about it here https://github.com/bytedeco/javacpp/issues/474 but I feel it's probably just better to mention at this repo again just incase others are facing the same issue.
We have a Java backend service that uses TF to host a model to do predictions. We just upgraded to TF2.x and javacpp got updated at the same time, then the service is crashing with out of memory because we were using ZGC. Turn off ZGC and use the default GC policy resolves the issue for us.
This happens on Mac OS or Linux (in docker container), OpenJDK 11 or 16.
Detailed issue description please see issue on javacpp
If we are sure it is not related to javacpp but to this tf java repo then I can close down the other one and copy the issue description here. Thanks.

Like I keep telling you, if the only issue that you are facing is a memory leak, this means that you forgot to call close() somewhere. You'll need to make sure that you are calling close() everywhere that we need to.

No, this is because the RSS is miscounting the memory usage on Linux under ZGC. See my comment on the issue on JavaCPP - https://github.com/bytedeco/javacpp/issues/474#issuecomment-832232242.

@Craigacp No, as per https://github.com/bytedeco/javacpp/issues/474#issuecomment-831993598, the same exact thing happens when "org.bytedeco.javacpp.nopointergc" is set so this is not related to JavaCPP. Like I told you many many times already, and I'll keep bringing this up until you start acknowledging that maybe there is something wrong in TF Java, the way you're using WeakReference is incorrect. Maybe that's the cause, maybe it's something else, but there is something wrong with TF Java and/or users forgetting to call close() when they should.

That doesn't account for the fact that when using G1GC the issue doesn't appear. Both this report and the other one in the gitter are specific to ZGC, and don't seem to have the issue when using G1GC. There are obviously many differences between the two, but one that impacts JavaCPP is that monitoring the process memory usage using RSS doesn't work properly with ZGC as the Linux kernel triple counts the JVM's memory in the RSS.

Thank you @Craigacp
Closing this as this is not TF related and we have a solution and explanation for it. See https://github.com/bytedeco/javacpp/issues/474#issuecomment-832232242 and
https://github.com/bytedeco/javacpp/issues/474#issuecomment-832236769


indentation rule requires multi-line values with variables to be indented more than the previous line

Related to #1190, I've found that using multi-line property values with variables seems to require each line be indented more than the last one from the indentation rule!
I am running Sass Lint version 1.12.1 from the command line, and from the VSCode IDE extension.
Given this code, I lint violations on the last 3 lines - I've written the output in the comment on each line
@keyframes shine {
  to {
    background-position:
    100% 0,                                                 //No violation
    $skeleton-content-left ($skeleton-content-spacing * 1), //No violation
    $skeleton-content-left ($skeleton-content-spacing * 2), //Expected indentation of 6 spaces but found 4.
    $skeleton-content-left ($skeleton-content-spacing * 3), //Expected indentation of 8 spaces but found 4.
    $skeleton-content-left ($skeleton-content-spacing * 4); //Expected indentation of 10 spaces but found 4.
  }
}

So apparently it expects my code to be written like this, which seems completely ridiculous.  The following code produces no violations from the indentation rule.
@keyframes shine {
  to {
    background-position:
    100% 0,
    $skeleton-content-left ($skeleton-content-spacing * 1),
      $skeleton-content-left ($skeleton-content-spacing * 2),
        $skeleton-content-left ($skeleton-content-spacing * 3),
          $skeleton-content-left ($skeleton-content-spacing * 4);
  }
}

I assume this has been dealt with by this point - it's been several years now so I'm closing this issue to get it out of my list


Improved Morphology

This PR demonstrates some proposed improvements to the Morphology class in Morphology.h. To avoid a complicated diff, I've pushed this up as a draft PR which contains all changes in a new Header and an example binary with timings which can be built with the old and new methods. Note that there are a few areas that still need investigating, mainly:

How to handle active tiles for erosion and dilation. In most cases (but not all), performing the dilation/erosion over a voxelized mask grid is more efficient.
Erosion 18/26 neighbours, using "inverse dilation" can be faster than erosion 6 in some cases.
Temporary support for an erosion/dilation mask, aimed to improve performance but I may remove.

Important changes:

dialteVoxels/erodeVoxel both only operate over leaf level values and ignore active tiles. Topology should be voxelized before creating this class.
The LeafCache scatter/methods have entirely been copied, but the class has been renamed to NodeMaskOp and can perform dilation/erosion on a single leaf node (expected to exist within the given tree).
Both erosion and dilate are able to consolidate dense/empty nodes on the fly to speed up subsequent iterations. This is primarily effective for larger dilation iterations.
Various unused subclasses removed

Timings here:
https://docs.google.com/spreadsheets/d/1hlgC5NPPWybjJjZ5F1GyWHxePXnhJVdWuUiwcNiXYTI/edit?usp=sharing
Signed-off-by: Nick Avramoussis<EMAIL_ADDRESS>

Declining this - I will be up-streaming a new version next week


drivers: clock_control: smartbond low power clock calibration

This updates Smartbond clock control in the following way:

low power oscillators now have separate bindings (fixed-clock was used before), now calibration interval and settle time are introduced
Preferred power domain configuration for DA1469x is introduced (required by Renesas hal). This configuration was proposed by Renesas Engineers and is taken verbatim from Mynewt project.
RCX and RC32K calibration functionality added to periodically measure oscillator frequency.
XTAL32 settle time (defined in DT) can later be used to notify CMAC.

For now notification about frequency changes and/or XTAL32K settle time are not propagated.

rebased with conflicts resolved

Last force push is just a rebase incorporating hal_renesas pull request with RC32K trimming during calibration


Sometimes Health Check is Very Slow, or Throw Exception

Halo!
Before reroute request to real service, Ocelot will request Consul's Health Check Api. Sometimes it is very slow, or throw exception like below.
When I can't recieve response, I request the realy health check url(http://localhost:8500/v1/health/service/WebApiServer?passing=1
), and it is work. I guess there is something wrong with the Health Check in Ocelot(ver 11.0.3, ver 12.0.1).
2018-11-01 12:59:25,163 [47] INFO  Com.XX.WebApi.ServiceGateway.Startup Request starting HTTP/1.1 POST http://MyIP:MyPort/WebApiServer/Robot/Receive application/json;charset=UTF-8 746
2018-11-01 12:59:25,164 [47] INFO  Com.XX.WebApi.ServiceGateway.Startup 请求:http://MyIP:MyPort/WebApiServer/Robot/Receive
2018-11-01 12:59:25,164 [47] INFO  Com.XX.WebApi.ServiceGateway.Startup requestId: 0HLHVLGEHVMN7:00000001, previousRequestId: no previous request id, message: EndpointRateLimiting is not enabled for /api/{url}
2018-11-01 12:59:25,165 [47] INFO  Com.XX.WebApi.ServiceGateway.Startup requestId: 0HLHVLGEHVMN7:00000001, previousRequestId: no previous request id, message: No authentication needed for /WebApiServer/Robot/Receive
2018-11-01 12:59:25,165 [47] INFO  Com.XX.WebApi.ServiceGateway.Startup requestId: 0HLHVLGEHVMN7:00000001, previousRequestId: no previous request id, message: /api/{url} route does not require user to be authorised
2018-11-01 13:01:13,113 [55] INFO  Com.XX.WebApi.ServiceGateway.Startup Request finished in<PHONE_NUMBER>ms 200 application/json; charset=utf-8
2018-11-01 13:01:13,128 [52] INFO  Com.XX.WebApi.ServiceGateway.Startup requestId: 0HLHVLGEHVMN6:00000001, previousRequestId: no previous request id, message: Error making http request, exception: System.Threading.Tasks.TaskCanceledException: A task was canceled.
at System.Threading.Tasks.ValueTask1.get_Result()    at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)    at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)    at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Ocelot.Requester.HttpClientHttpRequester.GetResponse(DownstreamContext context)
2018-11-01 13:01:13,130 [52] INFO  Com.XX.WebApi.ServiceGateway.Startup requestId: 0HLHVLGEHVMN6:00000001, previousRequestId: no previous request id, message: Error Code: UnableToCompleteRequestError Message: Error making http request, exception: System.Threading.Tasks.TaskCanceledException: A task was canceled.
at System.Threading.Tasks.ValueTask1.get_Result()    at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)    at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)    at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Ocelot.Requester.HttpClientHttpRequester.GetResponse(DownstreamContext context) errors found in ResponderMiddleware. Setting error response for request path:/WebApiServer/Robot/Receive, request method: POST
2018-11-01 13:01:13,133 [52] INFO  Com.XX.WebApi.ServiceGateway.Startup Request finished in<PHONE_NUMBER>ms 0

I've solved it.

{
"ReRoutes": [
{
"DownstreamPathTemplate": "/api/{url}",
"DownstreamScheme": "http",
"UpstreamPathTemplate": "/WebApiServer/{url}",
"UpstreamHttpMethod": [ "Get", "Post" ],
"ServiceName": "WebApiServer",
"UseServiceDiscovery": true,
"HttpHandlerOptions": {
"UseTracing": false,
"UseProxy": false
},
"Timeout": 20
}
]
}

I have encountered this problem too,see https://bbs.rupeng.com/Post/Index/4100
I would try to solve it after I start to work in the team.

@yangzhongke commented on Dec 5, 2018

What does it mean to start work in the team?
Seems you didn't understand our dev process.

you fork Ocelot repo
you assign , select an issue to work on
you create feature branch from develop one in your fork
after finishing development you create a PR to develop branch in head repo, ThreeMammals

It is pretty easy to start working! We value and support all talented contributors.
But 5+ years have been passed since your last message...

@cwbcheng commented on Nov 8, 2018

I see you've found the solution by your own.
Going to close this ticket....


[Bug]: App icon are not displayed in homepage

Is there an existing issue for this?

[X] I have searched the existing issues

Description
On homepage we are not able to see app icons.

Expected: App icons for all apps should be visible.
Actual: App icons are not visible.
Public Sample App
No response
Environment
Release
Severity
Low (Cosmetic UI issues)
Issue video log
No response
Version
Cloud

Issue is fixed. Verified on release


Someone has working on CentOS 7?

Hi guys
Is someone has pdns 4.1 and powerdns admin working on centos 7 and can help me with the installation steps?
Than you so much guys

Following is the guide to install PDA on Centos 7.
https://github.com/ngoduykhanh/PowerDNS-Admin/wiki/Running-PowerDNS-Admin-on-Centos-7
For pdns 4.1 service, please take a look at their official website. Basically you will need to use their repository and install pdns + db backend package.

selinux and firewall disabled

I did a step by step guide for Centos 7, pdns + recursor + DNS-admin, if interesting i can send to you


docs/dasharo-tools-suite: Split DTS documentation

Split the content of documentation.md file into the following structure:
documentation/
building.md
features.md
running.md
supported-hardware.md

I forget about installing pre-commit all the time 😵

@m-iwanicki Fixed headers, pre-commit and mkdocs issues. All checks pass. Also merged master branch for compatibility.


Add rd.xml for .NET Native compilation

@mattwhilden I tried adding an rd.xml for the library per the discussion in #168, but when I add a UWP test project and try to compile it, it still fails with the ILC error. Am I doing something wrong when doing it in a library?

Which version of Microsoft.NETCore.UniversalWindowsPlaftorm are you on?

 But then I'm not sure I understand what you're doing here.

@tomjebo good catch, but not the error here :(

@MattWhilden I played around with this again tonight and it seems to be found. However, I'm getting Out of Memory errors:
2>  App1 -> C:\Users\twsou\Projects\Software\Open-XML-SDK\App1\bin\x64\Release\App1.exe
2>GENERATEPROJECTPRIFILE : warning PRI257: 0xdef00522 - Resources found for language(s) 'en' but no resources found for default language(s): 'en-US'. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899
2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2015,5): warning APPX0104: Certificate file 'App1_TemporaryKey.pfx' not found.
2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2015,5): warning APPX0107: The certificate specified is not valid for signing. For more information about valid certificates, see http://go.microsoft.com/fwlink/?LinkID=241478.
2>  Starting .NET Native compilation
2>  Processing application code
2>C:\Users\twsou\Projects\Software\Open-XML-SDK\App1\Resources.System.Linq.Expressions.rd.xml(35): warning : ILTransform_0027: Method 'CreateLambda' within 'System.Linq.Expressions.Expression' could not be found.
2>C:\Users\twsou\Projects\Software\Open-XML-SDK\App1\Resources.System.Linq.Expressions.rd.xml(91): warning : ILTransform_0027: Method 'ParameterIsAssignable' within 'System.Linq.Expressions.Expression' could not be found.
2>  Computing application closure and generating interop code
2>  Generating serialization code
2>  Compiling interop code
2>  Cleaning up unreferenced code
2>  Generating native code
2>STARTPROCESSTASK : error : Out of Memory
2>STARTPROCESSTASK : error : Out of Memory
2>STARTPROCESSTASK : error : Out of Memory
2>C:\Program Files (x86)\MSBuild\15.0\.Net\.NetNative\15.0.24211\x64\ilc\IlcInternals.targets(1192,5): error : ILT0005: 'C:\Program Files (x86)\MSBuild\15.0\.Net\.NetNative\15.0.24211\x64\ilc\Tools\nutc_driver.exe @"C:\Users\twsou\Projects\Software\Open-XML-SDK\App1\obj\x64\Release\ilc\intermediate\MDIL\App1.rsp"' returned exit code 1
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Deploy: 0 succeeded, 0 failed, 0 skipped ==========

Any thoughts? It was working earlier in the evening, but is failing now. I tried it with v6.0.1 of the tooling as well as 5.4.1 - fails on both. Using VS 15.4.2

@twsouthwick is this still pending resolution of the errors you were seeing?

Yes, it is. Hoping to hear from someone from the .NET Native team on how to proceed.

@tomjebo Once #301 is merged, this is unblocked.


Azure AD B2C: User can't login after login-page was open for  some time

Core Library
MSAL.js v2 (@azure/msal-browser)
Core Library Version
2.22.1
Wrapper Library
MSAL React (@azure/msal-react)
Wrapper Library Version
1.3.1
Description
If a user leaves the login-page open for a few hours (or over night) they can't log in due to a 400 Bad Request Error.
If you click on "Sign In", a loading indicator is shown for a short amount of time, but nothing else happens afterwards.
This behaviour can be fixed by refreshing the whole login-page, but not every user will do that, without an indication on what went wrong.

Network Tab:

Error Message
400 Bad Request
Msal Logs
No response
MSAL Configuration
"msalConfig": {
    "auth": {
      "clientId": "clientId",
      "authority": "https://tenant.b2clogin.com/tfp/tenant.onmicrosoft.com/B2C_1_login",
      "knownAuthorities": ["https://tenant.b2clogin.com"],
      "scopes": [
        "https://tenant.onmicrosoft.com/tenant.api/user_impersonate"
      ],
      "redirectUri": "http://localhost:3000"
    },
    "cache": {
      "cacheLocation": "localStorage",
      "storeAuthStateInCookie": false
    }
  },

Relevant Code Snippets
Error happens on the B2C Login Page, which is not part of the source code of the application

Reproduction Steps

Leave B2C Login Page open for a few hours
Enter credentials
Click on "Sign In"
400 - Bad Request

Expected Behavior
There should be an indication what went wrong (like session expired, if thats the case)
An error message should be shown to the user, that is trying to log in
Identity Provider
Azure B2C Basic Policy
Browsers Affected (Select all that apply)
Chrome
Regression
No response
Source
External (Customer)

This was identified as an issue with the B2C service. Please file a support ticket with the B2C team by following the instructions here: https://docs.microsoft.com/azure/active-directory-b2c/support-options
They can help you out further, they may ask for a public repro link or additional data. You can also link this Github issue in the support request.


mock-code: Allow paths to be relative to the config file

See #51
This PR allows paths in the .aiida-testing-config.yml file to be relative. These are interpreted to be relative to the config file location, since the location of the test execution can vary.
I followed the suggestion in the issue above and added the file path as a special key to the config, which is excluded when writing the config out. Another possibility would be to add the filepath as an attribute/property to the Config class. I don't have a preference for either way

Another possibility would be to add the filepath as an attribute/property to the Config class.

That seems like the cleaner solution to me, since it doesn't have the "usual" properties of a config entry (e.g., cannot be missing, or changed via the usual means).

Hey guys, so am I understanding correctly that you are proposing to specify the filepath of the .aiida-testing-config.yaml inside the .aiida-testing-config.yaml file?

No, AFAIU the goal is to provide the path at runtime in the Config, not hard-code it in the .yaml.

Hey guys, so am I understanding correctly that you are proposing to specify the filepath of the .aiida-testing-config.yaml inside the .aiida-testing-config.yaml file?

The filepath is never written out to the config file. In the current implementation it is added as a special key to the instance of the Config class in from_file and excluded again in to_file.
I will switch the file path to be a property of the Config class instead of a special key to make this distinction clearer.

I will switch the file path to be a property of the Config class instead of a special key to make this distinction clearer.

Thanks, I guess that's what confused me (besides being a bit tired ;-) ).
Sounds all fine; happy to merge once it's done

@ltalirz The file path is now implemented as a property
The tests and docs build fail on my fork but I think this is related to aiida-core 2.0 (reentry is now not available)/and a newer sphinx version complaining about the configuration

I've fixed CI. Could you please update this branch? Somehow I don't have the rights to do so

Done 👍 It's probably because I used a fork in our Institute organization, where the rights are probably different

Thanks @janssenhenning !
Please note that one part of fixing CI was to make the limitation in the aiida-core version actually take effect, meaning it will force-install aiida<2 now.
However, I believe it works with aiida2 as well - if you need that, let me know (or open a PR that removes the requirement and removes the reentry calls in the CI tests).


Manage dynamic z-index for multiple open off-canvas

How to reproduce this bug:

Have two off-canvas panels; add triggers inside off-canvas contents to trigger each-other
Open first-off-canvas; with any trigger from the page
From off-canvas content trigger the second-off-canvas
Second-off-canvas is  open,  from it's content trigger back the first-off-canvas

What should happen:

Last triggered off-canvas should be on top by changing Z-index.

What happened instead:

Both off-canvas panels are open, last off-canvas on Dom is on top, as they have fixed z-index

Browser(s) and Device(s) tested on:
MBA/Chrome
Foundation Version(s) you are using:
6.4

Is this a real bug or feature request?

Hi @klihelp, can you provide a codepen or some more clear instructions how we can test and reproduce this?

Closing as we did not receive further feedback.


Indicate API-based errors for user

Design: https://www.figma.com/file/FlmF7ropcijOb7iVSDqNn0/🟧-Web-App-Explorations-2024-H1?type=design&node-id=2039-75582&mode=design&t=jbjoqCEhyQt6z8Gm-4

Curious how we detect when to show this error. It's not easy to get right, I think.
If we track error responses when we see a 429, or any error response, it will be displayed very regularly for users. Also a challenge to show it in a way that it won't flicker on/off.
Further, if a user encounters 1 429 error, I might not actually effect functionality that much, yet we will show the error anyway.
Maybe it should be isolated to only certain query types?

agree here. most critical requests are for blockstream api utxos and hiro api inscriptions? maybe start with them?
show callout in case there are more than 2 consecutive api error?

I'm moving this to the design backlog so we can firm up the UX specification before development. I'm also not sure using the toast is the right approach, for the above stated reasons. It seems more reliable to indicate errors within the components themselves that experience such errors (e.g. if the account total balance can't load, show an error there and retry option).
cc @fabric-8 @mica000 since this issue needs general consideration as we redesign components. I imagine we may resolve it gradually as we roll out new components


Removing CWD causes warnings in subsequent commands

Hi,
When removing /usr/src/python the current working directory is also the directory being removed. This causes subsequent commands to complain about not being able to locate the current working directory.
https://github.com/docker-library/python/blob/6e9789038db7717724bc89adaaf13a86882512db/3.8/buster/slim/Dockerfile#L75-L76
As a potential fix, changing the current working directory to / would prevent these warnings :
&& make install \
&& cd / \
&& rm -rf /usr/src/python \

I guess this is mostly a cosmetic change but I'm not sure if the warnings could cause  problems with the commands after.

Yeah, this would probably make sense (although I think it is mostly cosmetic -- we haven't seen any issues with the commands we run after that needing their working directory to exist).

Fixed as part of #687 :+1:


Fix for related items signal when migrating a model rename

Presently, if you apply a migration that renames a model using migrations.RenameModel, there will be a stale content type for the old model present in the django_content_types table. You will be prompted to delete this stale content type, which will cause the _related_items_changed() method to be called.
Since the content type has been deleted by Django by the time this method is called, an exception will be raised, as kwargs["instance"].content_type.model_class() will return None (as it expects the content type to have changed, not be deleted):
Traceback (most recent call last):
  [snip]
  File "mezzanine/generic/fields.py", line 117, in _related_items_changed
    if issubclass(for_model, self.model):
TypeError: issubclass() arg 1 must be a class

This change simply adds a check to ensure the method doesn't fail (there is nothing to be done on delete).

Thanks Sam.

:smile:


Miscellaneous user manual updates.

Description
Resolves #17323
Updated the descriptions of GetQueryOutputObject, GetQueryOutputString, GetQueryOutputValue and GetQueryOutputXML in the python scripting section of the manual.
Resolves #5308
Enhanced the section on running the test suite in the developers section of the manual.
Resolves #4944
Added documentation for OpenCLI and OpenGUI to the scripting section of the manual.
Type of change

[X] Documentation update

How Has This Been Tested?
I proofread the changes and looked at the changed output on read the docs.
Checklist:

[X] I have followed the style guidelines of this project.~~
[X] I have performed a self-review of my own code.~~
[ ] I have commented my code where applicable.
[ ] I have updated the release notes.
[X] I have made corresponding changes to the documentation.~~
[ ] I have added debugging support to my changes.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have confirmed new and existing unit tests pass locally with my changes.
[ ] I have added new baselines for any new tests to the repo.
[ ] I have NOT made any changes to protocol or public interfaces in an RC branch.
[X] I have assigned reviewers (see VisIt's PR procedures for more information).~~

@markcmiller86 can you review my changes in response to your feedback?


Bump to 0.17.1

@mwrock @btm @jkeiser @tyler-ball

:+1:

seems fine? curious that chef-config moved from the gem section to the git section. :+1:


[stable/rabbitmq] Rename *_PORT env vars to *_PORT_NUMBER

In order to avoid environment variable collision with k8s services, we can add a suffix to the *_PORT environment variables so we can be sure that any service name will work.

@k8s-bot ok to test

Marking as stale. Please update within the next week.

PR updated @unguiculus

Please bump chart version.
ping @sameersbn

lgtm!


stable/external-dns add roleArn missing

What this PR does / why we need it:
This fixes stable/external-dns which is missing a documented value from deployments.yaml file. This PR adds support for the deployments to use the roleArn value.
Which issue this PR fixes

fixes https://github.com/helm/charts/issues/10886

Signed-off-by: Christopher Stobie<EMAIL_ADDRESS>Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x ] DCO signed
[ x] Chart Version bumped
[x ] Variables are documented in the README.md
[x ] title of the PR contains starts with chart name e.g. [stable/chart]

/assign @lachie83

@lanmalkieri Unfortunately, a comment won't work for the DCO. It needs to be in the commit log. There's a command on the checks tab that can help you with that.

@mattfarina Fixed!
Thanks for the tip, very handy.

This is obsoleted by https://github.com/helm/charts/pull/12164


domain-specific Openstack installation (Liberty): Cannot list users nor assign "admin" role to "admin" user.

On domain-specific Openstack installation (Liberty), I can list all domains, projects, roles.
But cannot list users or assign a role "admin" to a user "admin" (during identity service installation)
openstack user list

The request you have made requires authentication. (HTTP 401) (Request-ID: req-2acfb267-db78-48cd-a660-5e8f5e618240)

openstack role add --project admin --user admin admin

The request you have made requires authentication. (HTTP 401) (Request-ID: req-b50dc3ae-1f58-4678-80c6-b23343b86dd2)

openstack role add --domain default --user admin admin

The request you have made requires authentication. (HTTP 401) (Request-ID: req-c435621a-3875-470a-9987-84309deaa11b)

It looks like there is some operations that can be performed without specifying the domain argument
--domain {domain}, for example:

list domains
list projects
list services
list endpoints
...

But not listing users or assigning a role to a user, these need to be done by indicating the corresponding domain:
openstack user list

The request you have made requires authentication. (HTTP 401) (Request-ID: req-0064e8ea-d53e-480c-b790-c02d5db3386f)

openstack user list --domain default

+----------------------------------+-------+
| ID                               | Name  |
+----------------------------------+-------+
| 7de845c81c414272ab91c1c033fdb2a7 | admin |
| 73381ac4501348afbaaa36d71815d8b4 | demo  |
+----------------------------------+-------+

Afterward, the log could provide a hint when talking about "Couldn't find the auth context."
 The request you have made requires authentication. from <IP_ADDRESS>


Ergonomiz: list-repo to show LAST COMMIT instead of CREATED

The time delta shown in list-repo currently shows CREATED time ago.
I'm more interested in knowing the current state of the pipeline, what ran, and when.. to do a quick checkup on the state of the pipeline. CREATED might be useful when you create it.. to confirm it's good.. but I'll be interested in the LAST COMMIT time more often.
Perhaps CREATED could be behind -o wide, following K8s conventions.

stale


Process hanged when :w in Win-Gvim for .sh file.

I use Windows Gvim.
I wrote linux shell script file, and when writing buffer to file, background process hanged.

After closing cmd window, I can use vim normally.

So far, issue occur only shell-script file.
When removing shebang, issue disappear.
(#!/bin/bash)

Syntastic doesn't run background processes.  It always runs linters in foreground.
You aren't supposed to run syntastic with the defaults.  Syntastic can't (and doesn't attempt to) check that what you're trying to do makes sense.  It's up to you to understand what you're doing and make it's actually useful.  In your case running bash under cmd isn't useful. shrug

Hi lcd047
Thanks for your reply.
I tested bash command on CMD.
And there was guide to installation of WSL-bash.
I removed WSL on my PC, and issue is clear!


jlpm run watch fails, yarn-run-all not found

Hi, I'm trying to set up a development environment as described in the readme, but the following command fails:
$ jlpm run watch
yarn run v1.21.1
$ yarn-run-all -p watch:*
/bin/sh: yarn-run-all: command not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

It seems there is no yarn-run-all command, which is hardcoded in package.json. I tried to find yarn-run-all, but the corresponding npm package is just an alias for npm-run-all. Is there anything else I have to install, or did some dependency change here?

I haven't tried running these commands myself recently but my guess is that something has changed in the latest version of JupyterLab. jlpm is one of their commands so perhaps take a look at their latest guidance on how to develop extensions - it's possible they don't even use jlpm anymore - it was really just a version of yarn (or maybe it was npm) bundled into JupyterLab. This was to avoid regular users having to install yarn/npm separately - behind the scenes JupyterLab had to build extensions regularly, every time a new one was installed, so they really needed yarn/npm to be an internal tool. However, they have improved things so that JupyterLab doesn't need to run this all the time any more.
If you find anything, please let us know!


Added missed "template" settings

Description
[Describe what this change achieves]
This change fixes below error when creating index template shown in step 2.
{
  "error" : {
    "root_cause" : [
      {
        "type" : "x_content_parse_exception",
        "reason" : "[3:3] [index_template] unknown field [settings]"
      }
    ],
    "type" : "x_content_parse_exception",
    "reason" : "[3:3] [index_template] unknown field [settings]"
  },
  "status" : 400
}

Issues Resolved
[List any issues this PR will resolve]
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Many thanks @omurbekjk!