Create HOST is failing in v0.7.0 release using CLI

Is this a BUG REPORT or FEATURE REQUEST?:
Creation of host is failing as not able to pass initiators.
osdsctl host create host1 --ip="<IP_ADDRESS>" --osType="linux" --accessMode="agentless" --availabilityZones=["default"]
ERROR: Request body has an error: doesn't match the schema: Error at "/initiators":Value is not nullable
There is no help, how to add initiators:
osdsctl host create -h
create a host in the cluster
Usage:
osdsctl host create  [flags]
Flags:
--accessMode string           the access mode of host, including: agentless, agent (default "agentless")
--availabilityZones strings   the array of availability zones which host belongs to (default [default])
-h, --help                        help for create
--ip string                   the IP address for access the host
--osType string               the os type of host, includding: linux, windows (default "linux")
Global Flags:
--debug   shows debugging output.

Uncomment only one, leave it on its own line:
/kind bug
/kind feature

What happened:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

Hotpot(release/branch) version:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

Closing!!. Its fixed now


Support for a “virtual bulb”

The dashboard colorpicker node accepts RGB values (or hex etc.) but it doesn’t accept color temperature, which we may prefer to use, to set the light colour in Node-RED (e.g. from a scene).
I understand the Huemagic bulb node will output the RGB value regardless of how you set it, so you could just connect the output of the Hugemagic bulb node to the dashboard colorpicker (through a change node to split the RGB values into separate objects). But there are some disadvantages to doing it this way:

it is slower than using an internal value from e.g. MQTT. Presumably Hue hub needs to communicate to the bulb, and the bulb needs to return information. If you are setting e.g. 5 lights at the same time, there can be delays. Either way, I have tested reading the JSON value from MQTT, and this feels much more responsive.

I presume if the bulb is not connected, the value will not come back? I may be wrong...

Suggestion
Could you provide the code to convert between colortemp and RGB?
Alternatively could you provide a “virtual” bulb node that you could send a colortemp message to, and receive the RGB value?

You may want to take a look here: https://github.com/Foddy/node-red-contrib-huemagic/blob/master/huemagic/utils/color.js


Is hooking to a specific instance of an application possible?

@gmamaladze,
I'm using the globalmousekeyhook to detect mouse/key events from MS Word and it works great. However, it seems to hook into MS Word, and I want it to only hook into a particular instance of MS Word (so if I have a few document open, I want to only detect changes specific to that document). I am using the apphook.
Is it possible/supported by this library to only hook to one instance of an application?

Starting with a certain version of Word (maybe 2012?) there is only a single instance handling all open documents. Same with Excel.


Update dotnet 3.1 (needed to support Apple Silicon M1)

This PR updates dotnet from 2.1 to 3.1 to fix an issue that was raised on Apple M1 mentioned in Docker Community Slack:

Hi, I was trying to run this docker sample on my Macbook Air M1 but I get the following errors. Any thoughts on how I could fix this?
Sample - https://github.com/dockersamples/example-voting-app

It turns out that the dotnet 2.1 multi-arch image only supports linux/amd64 and linux/arm/v7, the newer dotnet 3.1 also has linux/arm64 in the manifest list.
I hope that doesn't break anything in the sample app. I could build and run it with a simple docker-compose up.

Hi @BretFisher
I've updated this PR and now the example-voting-app also runs on Apple silicon machines, I've tested it on macOS 11.3.1 with Docker Desktop 3.3.2 and new docker compose up 🎉
Are you able to merge this PR? 😅

🎉


MuSig

Aligned MuSig with the new code structure; extended it to the 3-of-3 case.

Pull Request Test Coverage Report for Build 165

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 93.553%

Totals

Change from base Build 164:
0.2%

Covered Lines:
1248

Relevant Lines:
1334

💛  - Coveralls

Pull Request Test Coverage Report for Build 165

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 93.553%

Totals

Change from base Build 164:
0.2%

Covered Lines:
1248

Relevant Lines:
1334

💛  - Coveralls


[WIP] Parse consuming and borrowing modifiers from SE-0377

And treat them, along with the existing modifiers such as __shared and friends, as contextual keywords, since we should never have really reserved them as argument names.
This is the companion PR for https://github.com/apple/swift/pull/63073

https://github.com/apple/swift/pull/63073
@swift-ci Please test

https://github.com/apple/swift/pull/63073
@swift-ci Please test

https://github.com/apple/swift/pull/63073
@swift-ci Please test


Using Reqwest combined with Tide

I'm trying to combine Tide with a current implementation we have that uses the Reqwest HTTP client. The problem comes when using a reqwest client inside a tide endpoint, as in that moment the reqwest client panics with the error no current reactor. As far as I know, reqwest uses the Tokio reactor, and Tide uses Hyper, which also uses the Tokio reactor.
I've set up a minimal example of what I want to achieve
// main.rs

async fn make_request(cx: tide::Context<()>) -> String {
    let resp: std::collections::HashMap<String, String> = reqwest::get("https://httpbin.org/ip")
        .await.expect("Error in reqwest")
        .json()
        .await.expect("Error parsing JSON");

    resp.get("origin").expect("Origin Key not present in response").to_string()
}

fn main() -> Result<(), std::io::Error> {
    let mut app = tide::App::new();
    app.at("/").get(make_request);
    Ok(app.serve("<IP_ADDRESS>:8000")?)
}

# Cargo.toml

[package]
name = "tide-reqwest-example"
version = "0.1.0"
authors = ["Whatever<EMAIL_ADDRESS>edition = "2018"

[dependencies]
tide = "0.3.0"
reqwest = { version = "0.10.0-alpha.2", features = ["default-tls", "json"] }

I've even tried adding #[tokio::main] in the main function (and making it async), but the result is the same.
Is there any way to solve this problem or making Tide use the Tokio reactor?

@cquintana-verbio between differen tokio versions, reqwest and the alphas, I'm unsure where the error is exactly originating. I think asking the authors of those libraries might help pinpoint it faster.
However if you want to make HTTP requests within tide, consider using surf -- we'll be ensuring that both tide and surf work well together on top of the async-std runtime, so perhaps that might pose a suitable alternative:
use std::collections::HashMap;

async fn make_request(cx: tide::Context<()>) -> Result<String, Surf::Exception> {
    let resp: HashMap<String, String> = surf::get("https://httpbin.org/ip")
        .recv_json()
        .await?;

    resp.get("origin").expect("Origin Key not present in response").to_string()
}

fn main() -> Result<(), std::io::Error> {
    let mut app = tide::App::new();
    app.at("/").get(make_request);
    Ok(app.serve("<IP_ADDRESS>:8000")?)
}

It's probably because the underlying http-service is still using hyper 0.12 . Can http-service be updated to 0.13?

@acasajus hyper 0.13 is currently experimental (alpha 4, with impactful breaking changes planned), which doesn't match the stability guarantees we require for a library that underpins Tide.

Hyper 0.13 is out! :) with tokio 0.2 and quite some performance improvements.

thread 'async-std/executor' panicked at 'not currently running on the Tokio runtime.', /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.13/src/runtime/handle.rs:63:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1427
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:511
  11: rust_begin_unwind
             at src/libstd/panicking.rs:419
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:111
  13: core::option::expect_failed
             at src/libcore/option.rs:1203
  14: core::option::Option<T>::expect
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/option.rs:347
  15: tokio::runtime::handle::Handle::current
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.13/src/runtime/handle.rs:63
  16: tokio::runtime::blocking::pool::spawn_blocking
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.13/src/runtime/blocking/pool.rs:65
  17: tokio::task::blocking::spawn_blocking
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.13/src/task/blocking.rs:69
  18: <hyper::client::connect::dns::GaiResolver as tower_service::Service<hyper::client::connect::dns::Name>>::call
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/connect/dns.rs:120
  19: <S as hyper::client::connect::dns::sealed::Resolve>::resolve
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/connect/dns.rs:332
  20: hyper::client::connect::dns::resolve::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/connect/dns.rs:342
  21: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  22: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  23: hyper::client::connect::http::HttpConnector<R>::call_async::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/connect/http.rs:307
  24: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  25: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  26: <hyper::client::connect::http::HttpConnector<R> as tower_service::Service<http::uri::Uri>>::call::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/connect/http.rs:248
  27: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  28: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  29: <hyper::client::connect::http::HttpConnecting<R> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/connect/http.rs:388
  30: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/either.rs:62
  31: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  32: <hyper_rustls::connector::HttpsConnector<T> as tower_service::Service<http::uri::Uri>>::call::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-rustls-0.20.0/src/connector.rs:126
  33: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  34: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  35: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  36: reqwest::connect::Connector::connect_with_maybe_proxy::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.10.4/src/connect.rs:371
  37: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  38: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  39: reqwest::connect::with_timeout::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.10.4/src/connect.rs:500
  40: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  41: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  42: <hyper::service::oneshot::Oneshot<S,Req> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/service/oneshot.rs:58
  43: <F as futures_core::future::TryFuture>::try_poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.4/src/future.rs:83
  44: <futures_util::future::try_future::map_err::MapErr<Fut,F> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/try_future/map_err.rs:43
  45: <F as futures_core::future::TryFuture>::try_poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.4/src/future.rs:83
  46: futures_util::future::try_future::try_chain::TryChain<Fut1,Fut2,Data>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/try_future/try_chain.rs:53
  47: <futures_util::future::try_future::and_then::AndThen<Fut1,Fut2,F> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/try_future/and_then.rs:46
  48: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/either.rs:62
  49: <hyper::common::lazy::Lazy<F,R> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/common/lazy.rs:59
  50: futures_util::future::future::FutureExt::poll_unpin
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/future/mod.rs:507
  51: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/select.rs:64
  52: futures_util::future::future::chain::Chain<Fut1,Fut2,Data>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/future/chain.rs:44
  53: <futures_util::future::future::then::Then<Fut1,Fut2,F> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/future/then.rs:44
  54: <F as futures_core::future::TryFuture>::try_poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.4/src/future.rs:83
  55: futures_util::future::try_future::try_chain::TryChain<Fut1,Fut2,Data>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/try_future/try_chain.rs:53
  56: <futures_util::future::try_future::and_then::AndThen<Fut1,Fut2,F> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/try_future/and_then.rs:46
  57: hyper::client::Client<C,B>::retryably_send_request::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/mod.rs:253
  58: <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/poll_fn.rs:54
  59: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  60: <hyper::client::ResponseFuture as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.4/src/client/mod.rs:604
  61: <reqwest::async_impl::client::PendingRequest as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.10.4/src/async_impl/client.rs:1276
  62: <reqwest::async_impl::client::Pending as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.10.4/src/async_impl/client.rs:1255
  63: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  64: tgbot::api::Api::execute::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tgbot-0.7.1/src/api.rs:158
  65: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  66: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  67: admin::telegram::Telegram::publish::{{closure}}
             at src/telegram.rs:74
  68: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  69: <futures_util::future::maybe_done::MaybeDone<Fut> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/maybe_done.rs:96
  70: admin::Application::publish::{{closure}}::{{closure}}
             at src/main.rs:86
  71: <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/poll_fn.rs:54
  72: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  73: admin::Application::publish::{{closure}}
             at src/main.rs:86
  74: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  75: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  76: admin::Application::try_posts::{{closure}}
             at src/main.rs:79
  77: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  78: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  79: admin::main::{{closure}}::{{closure}}::{{closure}}
             at src/main.rs:34
  80: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  81: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  82: <F as tide::endpoint::Endpoint<State>>::call::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tide-0.6.0/src/endpoint.rs:68
  83: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  84: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  85: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  86: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  87: <tide::middleware::cookies::CookiesMiddleware as tide::middleware::Middleware<State>>::handle::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tide-0.6.0/src/middleware/cookies.rs:54
  88: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  89: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  90: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  91: <tide::server::Service<InnerState> as tide::endpoint::Endpoint<State>>::call::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tide-0.6.0/src/server/mod.rs:386
  92: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  93: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  94: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
  95: <tide::server::Service<State> as http_service::HttpService>::respond::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/tide-0.6.0/src/server/mod.rs:355
  96: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
  97: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
  98: <F as futures_core::future::TryFuture>::try_poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.4/src/future.rs:83
  99: <futures_util::future::try_future::into_future::IntoFuture<Fut> as core::future::future::Future>::poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/future/try_future/into_future.rs:34
 100: std::future::poll_with_tls_context
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:99
 101: <http_service_hyper::WrapConnection<H> as hyper::service::service::Service>::call::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/http-service-hyper-0.4.1/src/lib.rs:87
 102: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libstd/future.rs:44
 103: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f509b26a7730d721ef87423a72b3fdf8724b4afa/src/libcore/future/future.rs:118
 104: <F as futures_core::future::TryFuture>::try_poll
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-core-0.3.4/src/future.rs:83
 105: <futures_util::compat::compat03as01::Compat<Fut> as futures::future::Future>::poll::{{closure}}
             at /home/humb1t/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.4/src/compat/compat03as01.rs:121

Looks like any Tokio based library may end up with this issue, even if main will be #[tokio:main].

async-std starting with v1.6.0 now ships with a tokio-02 feature flag that initializes tokio's TLS context whenever it starts a thread. This should fix most of the Tokio compat errors. It can be enabled by configuring it Cargo.toml as follows:
[dependencies.async-std]
version = "1.6.2"
features = ["tokio02"]


[BUG] Unbalanced forces for continuous member connections in version 21.1.3 ?

The member force results for a continuous member in a connection seem to be calculated differently between version 21.1 and 20.1
When we use 20.1 we get balanced forces, now when using 21.1 we get a different set of forces for the continuous member and hence unbalanced forces. The other connected member forces are correct.
We cannot determine whether this is a bug or if you are now recalculating member forces for continuous members in a different way with the newer version.
This is the member forces that are created in version <IP_ADDRESS>8, unbalanced

This is the member forces that are created in version 20.1.5544.1, all forces balanced

We use the ConnHiddenClientFactory to specify the install version of the program
I have attached the xml and xmlr result file that we use and the two connection files that are created in each version.
Are you able to provide the new method of specifying the results for a continuous connection member if it has been changed from the older version.
IdeaCon and xml.zip

Hello, there was indeed a slight change in how the load effects and their values are set to a connection project from continuous members. The reason is that since version 21, we are dealing with models of the whole structure in the Checkbot app, and we need to ensure data consistency between both workflows (generating a single connection project & importing a whole structure to Checkbot and generating multiple connections based on that).
When specifying the results in the .xmlr file, you are basically describing internal force diagrams for all load components along a given beam. You are currently specifying internal force values in the relative positions 0 and 1. However, the connection point is in the middle of the continuous Member 79 in your case (relative position 0.5). To get to the values needed, we currently:
a) read it directly (if available), or
b) interpolate between the two closest defined values (relative positions 0 and 1 in your case)
Please refer to the image below, where I've outlined your geometry and internal force diagrams for the normal and shear force - explaining the values that you see after import in version 21.1.3 on Member 79.

Now, there are two ways of dealing with this. Internally, we use both of them, depending on the API of the 3rd party software:
A) In order to read the "before" and "after" values in a connection point, we look for sections 1e-6 away from the connection point (relatively). So in your case, you can add those relative sections (0.499999 and 0.500001) and get equilibrium (example attached).
B) Define multiple Elements1D for continuous members and define the results for those Elements1D; rather than the whole Member. So in your case, you would define two Elements1D to construct the Member 79 (from point 85 to 99 and from point 99 to 86). When creating the connection, we'd then take the results directly from the endpoint of the first Element1D (rel. pos. 1), and the start point (rel. pos. 0) of the second Element1D. I can create that example too, if required
XML.zip

Thanks for your very prompt reply and clear explaination.
We have now implemented you’re a) method and it now works correctly and the issue is now resolved.
Regards
Mark Watson
From: vojtech-chalupa @.>
Sent: Wednesday, 19 January 2022 11:17 PM
To: idea-statica/ideastatica-public @.>
Cc: Mark Watson @.>; Author @.>
Subject: Re: [idea-statica/ideastatica-public] [BUG] Unbalanced forces for continuous member connections in version 21.1.3 ? (Issue #105)
Hello, there was indeed a slight change in how the load effects and their values are set to a connection project from continuous members. The reason is that since version 21, we are dealing with models of the whole structure in the Checkbot app, and we need to ensure data consistency between both workflows (generating a single connection project & importing a whole structure to Checkbot and generating multiple connections based on that).
When specifying the results in the .xmlr file, you are basically describing internal force diagrams for all load components along a given beam. You are currently specifying internal force values in the relative positions 0 and 1. However, the connection point is in the middle of the continuous Member 79 in your case (relative position 0.5). To get to the values needed, we currently:
a) read it directly (if available), or
b) interpolate between the two closest defined values (relative positions 0 and 1 in your case)
Please refer to the image below, where I've outlined your geometry and internal force diagrams for the normal and shear force - explaining the values that you see after import in version 21.1.3 on Member 79.
[image]https://user-images.githubusercontent.com/73105487/150117752-f5dbee3d-c248-4574-8c46-1ef136c57063.png
Now, there are two ways of dealing with this. Internally, we use both of them, depending on the API of the 3rd party software:
A) In order to read the "before" and "after" values in a connection point, we look for sections 1e-6 away from the connection point (relatively). So in your case, you can add those relative sections (0.499999 and 0.500001) and get equilibrium (example attached).
B) Define multiple Elements1D for continuous members and define the results for those Elements1D; rather than the whole Member. So in your case, you would define two Elements1D to construct the Member 79 (from point 85 to 99 and from point 99 to 86). When creating the connection, we'd then take the results directly from the endpoint of the first Element1D (rel. pos. 1), and the start point (rel. pos. 0) of the second Element1D. I can create that example too, if required
XML.ziphttps://github.com/idea-statica/ideastatica-public/files/7896956/XML.zip
—
Reply to this email directly, view it on GitHubhttps://github.com/idea-statica/ideastatica-public/issues/105#issuecomment-1016411683, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AS3VSVM3JVQBTN4TP2NBGI3UW2TVFANCNFSM5MIXKOLA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

Sorry, just reopening this issue. We are trying your Method B as this would be our preferred method, but have been unsuccessful in getting it to work. There seems to be some internal adjustment of forces that is happening that we cannot work out.
I have attached the xml files we have created based on your method but you will see that the forces are unbalanced and the 79and 83  end values are not what it is in the xmlr file, they seem to have been adjusted in some way?

I have attached the xml and xmlr and connection file for your perusal.
If you could provide some guidance it would be appreciated.
Portal_Frame method B.zip

No problem, the IOM seems to be correct at first glance. Will investigate and follow up.

I've simplified your results file to one load case just to make it easier to read, but more importantly, I've added one more section on every element. It seems that having the results defined in a single point was causing issues (since we are actually drawing a force diagram in the background, it is safer to use a minimum of two sections along each element). Should work for you now.
Portal_Frame.method.B_edited.zip


Is there a timeout for SubscribeAsync?

Hi Tomas, I am currently creating a long running service that subscribe to the Stream, but after idling for a period of time (around 30-60 min) without having any new data insert into the stream, the new data that comes afterward will not be receive by the subscriber.
Question:

Is there any ways for me to know if the subscriber is still running or already timeout?

Code
var query = context.CreateQueryStream<MyClass>()
    .WithOffsetResetPolicy(AutoOffsetReset.Earliest)
    .SubscribeAsync(c => {
        Console.WriteLine($"{nameof(MyClass)}: {c.UserId} - {c.Weather} - {c.DeviceId}");       //not receiving any new data after idling for a period of time
    },
    onError: ex => { Console.WriteLine($"Exception: {ex.Message}"); },
    onCompleted: () => { Console.WriteLine("Completed"); });

Hi @DoubleE1,
I would expect that in case of timeout you should receive an error notification. Could you please help me to investigate this issue further please? I assume that it is not easy to reproduce this issue.
Could you try to use Subscribe instead of SubsribeAsync and also try to change the TargetFramework from netcoreapp3.1 to .NET 6?
Regards Tomas.

Hi @DoubleE1.
In case that you (or someone else) would like to help me out with this issue please clone the repository for debugging purposes and reference the ksqlDB.RestApi.Client project in your solution instead of the Nuget package.
I would suggest you to examine the behavior in this class KsqlDbProvider. PR is welcome.
Thank you Tomas

Hi @tomasfabian
I have tried with .NET 5.0 & 3.1 Core to subscribe to the stream using both 'Subscribe' / 'SubscribeAsync', but still not getting the timeout exception after reproducing the same step as mentioned above.
I will try to examine on the Class mentioned. Will get back to you if I notice any possible issue.
Thank you.

Hi @tomasfabian.
After debugging and searching for some time, I notice that with the use of HttpClient, the StreamReader will stop reading from the network stream after idling for some time (Suspect 15min and above). But I can't tell for sure whether this is the main root cause for the issue mentioned above.
I have created a sample project to stimulate the timeout issue. Feel free to take have a look. Here's a similar issue found on stackoverflow.
Could we extend the timeout of the request, by any chance?
Or maybe we could use HttpWebRequest, as demonstrated in the sample project under the #region WebRequest.

@DoubleE1 did you also try the suggested solution from Stackoverflow, to set the timeouts to infinite?
httpClient.Timeout = TimeSpan.FromMilliseconds(Timeout.Infinite);

and
stream.ReadTimeout = Timeout.Infinite;

Hi @tomasfabian, yep I did tried the suggested solution, but I got the exception mentioning that the 'Timeouts are not supported on this stream', as shown in the image below and I haven't got into this just yet. Would appreciate if there's any recomended solution for this.

Hi @tomasfabian
Unfortunately, I couldn't find any solution to extend the stream timeout nor return the timeout exception from the stream.
Have tried the following method:

adding stream.ReadTimeout = Timeout.Infinite;
try catch the timeout exceptions from ConsumeAsync()

private async IAsyncEnumerable<T> TryConsumeAsync<T>(StreamReader streamReader, [EnumeratorCancellation] CancellationToken cancellationToken)
{
    var enumerable = ConsumeAsync<T>(streamReader, cancellationToken);
    await using var enumerator = enumerable.GetAsyncEnumerator(cancellationToken);
    for (var more = true; more;)
    {
        try
        {
            more = await enumerator.MoveNextAsync();
        }
        catch (Exception ex)
        {
            logger?.LogError(ex.Message, ex);
            throw;
        }
        yield return enumerator.Current;
    }
}

changing HttpClient to HttpWebResponse, but the streamreader returning different format of the rawdata, so it required a few more changes to be handle on several files, such as KSqlDbQueryStreamProvider.cs (am trying not to make too much changes).

Return result from:
HttpClient's StreamReader
{"queryId":"c6391e2c-67ec-4148-8bc5-a8db2e6a0d62","columnNames":["USERID","DEVICEID","WEATHER","DT","UNIXDT"],"columnTypes":["INTEGER","STRING","STRING","STRING","STRING"]}
HttpWebRequest's StreamReader
[{"header":{"queryId":"transient_MYCLASSSTREAM_507703769204576599","schema":"'USERID' INTEGER, 'DEVICEID' STRING, 'WEATHER' STRING, 'DT' STRING, 'UNIXDT' BIGINT"}}

Note: The stream itself has its own read and write timeout (15 minutes by default), so if 15 minutes go by without any data being uploaded. (Referring to this post)

Hi @DoubleE1, thank you for your observations. I will try to dig into this issue deeper.
But the solution is questionable for the following reasons. Even if we could return the timeout exception, AFAIK there is no way how to reconnect to the same push query in case of errors or lost connection.
I posted a question in  Stackoverflow few months ago and it wasn't answered, so it is probably not possible at all. This has to be implemented in ksqldb itself. My understanding is that in case of the Rest API we don't have any of the following processing guarantees:

at most once
at least once
exactly once

But I can be wrong because I didn't find any documentation about it. This is just my assumption.
Basically my approach is to use a lower level API and consume the messages from a persistent push query. See an example. In this way you can provide  a GroupId and scale your application, configure exactly once processing, etc. So at the end it is maybe even a better solution, rather than a workaround.
The downside is that you need access to the underlying topic and you have to provide BootstrapServers in the configuration and probably add yet another package such as Confluent.Kafka, if you haven't added it already.
Hopefully this will help you and enable you to proceed further.

This is the only documentation about processing guarantees in ksqldb I'm aware of, but I'm not sure how to interpret it, since I didn't find a way how to continue with the original processing (see my previous comment).
Let me know what you think, too.
Thank you.

Hi @DoubleE1,
I tried your sample project and alongside it I also ran a simple console application from Visual Studios. Both received a value after more than 3.5 hours.
Output from your project:
Configuration Result:
[Success] Name KafkaTest
[Success] ServiceName KafkaTest
Topshelf v<IP_ADDRESS>, .NET 5.0.13 (5.0.13)
The KafkaTest service is now running, press Control+C to exit.
CreateStreamAsync: False - BadRequest
04:19:25 - Raw data received: {"queryId":"8a20cf26-2959-4956-a203-c5b9445f961e","columnNames":["TITLE","ID","RELEASE_YEAR"],"columnTypes":["STRING","INTEGER","INTEGER"]}
04:19:25 - Raw data received: ["Aliens",1,1986]
04:19:25 - Raw data received: ["Die Hard",2,1998]
04:19:25 - Raw data received: ["3",3,1982]
08:05:54 - Raw data received: ["4",4,1982]
The bottom line is that I was not able to reproduce your issue.

Hi @tomasfabian,
Thank you for trying out the sample project, it seems like the issue wasn't caused by the code itself but may be either the configuration or the setting on the local machine/server (although I have tried with several different machines & servers).
I am currently using a Linux server to host the ksqldb server in Docker.
This is the docker-compose.yml file that I'm currently using.
version: '3'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_SERVER_ID: 1
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - 2181:2181
  kafka:
    image: confluentinc/cp-kafka:latest
    ports:
      - 9092:9092
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:29092,PLAINTEXT_HOST://localhost:9092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
    depends_on:
      - zookeeper
  ksqldb-server:
    image: confluentinc/ksqldb-server:latest
    hostname: ksqldb-server
    container_name: ksqldb-server
    ports:
      - 8088:8088
    environment:
     KSQL_CONFIG_DIR: "/etc/ksqldb"
     KSQL_LOG4J_OPTS: "-Dlog4j.configuration=file:/etc/ksqldb/log4j.properties"
     KSQL_BOOTSTRAP_SERVERS: "kafka:29092"
     KSQL_HOST_NAME: ksqldb-server
     KSQL_LISTENERS: "http://<IP_ADDRESS>:8088"
    depends_on:
     - kafka
  ksqldb-cli:
    image: confluentinc/ksqldb-cli:latest
    container_name: ksqldb-cli
    entrypoint: /bin/sh
    environment:
     KSQL_CONFIG_DIR: "/etc/ksqldb"
    tty: true
    depends_on:
     - ksqldb-server

Since the code is working just fine after the verification from your end, I think we're good to close this issue.
Really appreciate your time and effort to look into this issue, I'll try to see whether I'm able to find out what's the problem that causing this issue from my end. Hopefully, I'm able to share my solution over here.

Hi @DoubleE1,
have you found a solution for your timeout issue?
Here is a similar discussion with a solution for the Windows platform, maybe it will help someone: TCP Reset after 5mins from Azure Load Balancer

Hi @tomasfabian,
Unfortunately nop, I didn't manage to resolve the timeout issue, but instead I've changed from using HttpClient to HttpWebRequest to resolve the timeout issue. (Which is a slightly big changes that has been done outside of the package layer)
Regarding the WinHttpHandler which might not be supported on Linux/Linux container, not sure if this stackoverflow answer will help out. Will definitely spend sometime to look into this whenever I'm available.
Thank you very much, really appreciate your help!

In case that someone is facing issues with the HttpClient I redesigned the way how it is injected.. Hopefully it will provide a more stable implementation.
Thanks Tomas.


Port extract_filter to rust

#334

@pickfire I accidentally started working on this as well in #763 You may want to take a look at it as well and maybe cherry-pick https://github.com/newsboat/newsboat/pull/763/commits/4c009ebc4abc22fea9c4f97cc0515520fd96c70f which adds more unit tests on the C++ side.

@rnestler Sorry, I didn't notice your patch when I started working on it. Your patch did came in first.

@rnestler Sorry, I didn't notice your patch when I started working on it. Your patch did came in first.

No problem, I should have mentioned it in the issue that I'm working on it.

Coverage increased (+0.09%) to 53.119% when pulling ace3d9c7b10c27cc1c2ee46c888e83567e7e3dbf on pickfire:extract_filter into b8c7a2ee5ab73474a0f09b0ef239205b8785dcad on newsboat:master.

Thanks, @pickfire.


Integrate closure pass in CI

Add a closure compiler pass as a CI task to at make sure the codebase stays compatible for future changes.

Closing as "won't fix". The new https://github.com/googlecodelabs/codelab-elements repo builds everything using bazel and closure compiler by default.


Syntax error in menu screen

Micah go this on is iPhone 5.  I've never seen it on my iPhone 6

Can't replicate.  Micah : Perhaps try reloading the app by:

Opening Expo
Shaking your iPhone.  You should see the Expo menu appear.
Selecting "Refresh" link


Add info for installing kubectl via homebrew

There is a brew for installing kubectl via homebrew (https://github.com/Homebrew/homebrew-core/blob/master/Formula/kubernetes-cli.rb), it would seem sensible to reference it in this documentation (and I guess elsewhere)

@dgem I don't know that recommending a method for installing kubectl is in scope for this repo.
\cc @aaronlevy

Yeah, I'm going to lean toward just documenting curl. Mainly because it means we would need to continually vet that the brew install target was doing what we expect + it needs to target a specific kubectl version + if it doesn't support a version we want to ship our docs become partially incorrect.
This could just as easily spiral into apt-get/dnf/etc. curl (at least to me) seems like a reasonable common baseline.


fix: detect s390x arch and exclude noasm tag

Commit https://github.com/influxdata/influxdb/commit/074cd24a60ddd5aa2a851a7d04faaef5c126562a added a fix to compile with the go noasm build tag for all non-amd64 arch because arm64 tests panic without it. This also makes s390x compile with noasm even though the tests run fine on s390x without noasm.
This change adds s390x to the list of architectures that should not set noasm.

[ ] CHANGELOG.md updated with a link to the PR (not the Issue)
[x] Well-formatted commit messages
[x] Rebased/mergeable
[x] Tests pass
[ ] Documentation updated or issue created (provide link to issue/pr)
[x] Signed CLA (if not already signed)

Hi @jonathan-albrecht-ibm, thanks for the submission! I see in https://github.com/apache/arrow/commit/87194de72e9b09ea72ca96a218f3dc67ed5f9547 that you recently fixed a problem building s390x in Arrow. Do we need to wait until flux bumps its Arrow dependency before merging this change?

Hi @jonathan-albrecht-ibm, thanks for the submission! I see in https://github.com/apache/arrow/commit/87194de72e9b09ea72ca96a218f3dc67ed5f9547 that you recently fixed a problem building s390x in Arrow. Do we need to wait until flux bumps its Arrow dependency before merging this change?

Hi @jonathan-albrecht-ibm, thanks for the submission! I see in apache/arrow@87194de that you recently fixed a problem building s390x in Arrow. Do we need to wait until flux bumps its Arrow dependency before merging this change?

No, I actually ran into the Arrow problem (arrow not able to build with noasm) because Influx is building with noasm on s390x. So the arrow problem won't be hit after this change and no need to wait.

Hi @jonathan-albrecht-ibm, thanks for the submission! I see in apache/arrow@87194de that you recently fixed a problem building s390x in Arrow. Do we need to wait until flux bumps its Arrow dependency before merging this change?

No, I actually ran into the Arrow problem (arrow not able to build with noasm) because Influx is building with noasm on s390x. So the arrow problem won't be hit after this change and no need to wait.

gentle nudge: Just wondering about the status of this pr and if there is anything I can do?

Apologies for the delay @jonathan-albrecht-ibm, I was working through some CI issues to make it easier to test changes from forked repos. We should be set to proceed now.
I don't think we intend to "officially" support/release for s390x, but if this patch fixes a problem for you I'm ok merging it :+1: could you please rebase onto the latest master branch? There might also be an "allow edits from maintainers" button you could click that would let me update the branch via the UI as needed, so you don't have to keep pushing an update when others merge before you.

Thanks for looking at it @danxmoran, I've rebased the PR.

@danxmoran Thanks for reviewing and merging this PR


Replace Scarb.toml tool config with snfoundry.toml

https://github.com/foundry-rs/starknet-foundry/issues/1620
This PR is a part of stack, that aims to replace Scarb.toml tool configuration with snfoundry.toml:
-- Add mechanism for snfoundry.toml discovery (https://github.com/foundry-rs/starknet-foundry/pull/1643)
-> Replace Scarb.toml based configuration with snfoundry.toml based one
-- Use the same profile for sncast and scarb (https://github.com/foundry-rs/starknet-foundry/pull/1646)
-- Update docs (https://github.com/foundry-rs/starknet-foundry/pull/1647)
Introduced changes

use snfoundry.toml for tool configuration

Checklist

[X] Linked relevant issue
[X] Updated relevant documentation
[X] Added relevant tests
[X] Performed self-review of the code
[X] Added changes to CHANGELOG.md

We probably need to update the changelog & docs.

We probably need to update the changelog & docs. Not sure if here is the good place to do so.

https://github.com/foundry-rs/starknet-foundry/pull/1647 , decided to do it in one place in separate PR, but if you'd rather have it here I can merge the changes


Adds support for pre-commit

Adds support for pre-commit.
Would need this commit to be tagged too if possible so pre-commit can pick it up!

Hi @Grimlock257 . Thank you for the contribution. I'm not familiar with pre-commit. How can i test it and  how to tag this commit?

Hi @Grimlock257 . Thank you for the contribution. I'm not familiar with pre-commit. How can i test it and how to tag this commit?

You'll need to install pre-commit: pip install pre-commit and then run pre-commit install.

I'm not overly familiar with using git tags on a PR as I've never done it before; only to the master branch, for master branch it would be git tag 0.2.9 (or whatever version you want to give it) and then git push origin --tags. If you want I can add a tag to this branch with 0.2.9 as the release number (or a different version if you want) and  I'm pretty sure when merged it adds it to the releases.

Ah I see just version tag. I thought tere needs to some specific one. No worries I will add tag with new version release. Thanks.

Yeah, sorry - my bad for not being clear enough :)

We could also really use this if it can make it into a version. Thanks!


Change Info

Who Are We:
We are a group of KHS students dedicated to raise as much money as possible to fight pediatric cancer.
What We Do:
The KHSMini-THON raises money through fundraisers and our annual Mini-THON to benefit the Four Diamonds Fund (Link “Four Diamonds Fund” to http://fourdiamonds.org)
Why We Do It:
We do it for the fight. For the cure. For The Kids living with cancer.
Since When:
We have been fighting childhood cancer since 2015 with our first annual Mini-THON being held in February of 2016.

Cool, I'll make this change when I can

One more thing:
The title should be something like ( I am putting these in the order as they should appear, one under the other
Kennett High School Mini-THON
Come Join Us on February 26, 2016
For the Fight. For The Cure. For The Kids.
Then the signup link

Done

It hasnt been pushed to the website branch.


Fix duplicate rows and added scope for component name

[ ] All tests passed. If this feature is not already covered by the tests, I added new tests.
[ ] All static analysis checks passed.
[ ] This pull request is on the dev branch.
[ ] I used gofmt for formatting the code before submitting the pull request.

Curation Xray reports show for each direct dependencies all its blocked packages under curation. Under a direct dependency can be many packages which are similar under different paths, we want to present in the report only one occurrence for each package.
Also added scope for packge name, scope is also part of the component name uniqueness,
according to NPM official desperation of scope:
"All npm packages have a name. Some package names also have a scope. A scope follows the usual rules for package names (URL-safe characters, no leading dots or underscores). When used in package names, scopes are preceded by an @ symbol and followed by a slash, e.g."


[BUG]  7B int4 qlora 微调出现QWenTokenizer does not exist or is not currently imported.

是否已有关于该错误的issue或讨论？ | Is there an existing issue / discussion for this?

[X] 我已经搜索过已有的issues和讨论 | I have searched the existing issues / discussions

该问题是否在FAQ中有解答？ | Is there an existing answer for this in FAQ?

[X] 我已经搜索过FAQ | I have searched FAQ

当前行为 | Current Behavior
2023-11-28 08:00:28,648] [INFO] [real_accelerator.py:158:get_accelerator] Setting ds_accelerator to cuda (auto detect)
/opt/conda/lib/python3.10/site-packages/scipy/init.py:146: UserWarning: A NumPy version >=1.16.5 and <1.23.0 is required for this version of SciPy (detected version 1.23.5
warnings.warn(f"A NumPy version >={np_minversion} and <{np_maxversion}"
Loading checkpoint shards: 100%|██████████████████| 8/8 [01:04<00:00,  8.11s/it]
Traceback (most recent call last):
File "/opt/conda/lib/python3.10/site-packages/optimum/gptq/quantizer.py", line 298, in quantize_model
tokenizer = AutoTokenizer.from_pretrained(tokenizer)
File "/opt/conda/lib/python3.10/site-packages/transformers/models/auto/tokenization_auto.py", line 724, in from_pretrained
raise ValueError(
ValueError: Tokenizer class QWenTokenizer does not exist or is not currently imported.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/kaggle/working/Qwen/finetune.py", line 366, in
train()
File "/kaggle/working/Qwen/finetune.py", line 300, in train
model = transformers.AutoModelForCausalLM.from_pretrained(
File "/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py", line 511, in from_pretrained
return model_class.from_pretrained(
File "/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py", line 3157, in from_pretrained
quantizer.quantize_model(model, quantization_config.tokenizer)
File "/opt/conda/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
return func(*args, **kwargs)
File "/opt/conda/lib/python3.10/site-packages/optimum/gptq/quantizer.py", line 300, in quantize_model
raise ValueError(
ValueError: We were not able to get the tokenizer using AutoTokenizer.from_pretrained
with the string that you have passed Qwen/Qwen-7B-Chat. If you have a custom tokenizer, you can pass it as input.
For now, we only support quantization for text model. Support for vision, speech and multimodel will come later.
期望行为 | Expected Behavior
no
复现方法 | Steps To Reproduce
参考kaggle链接：https://www.kaggle.com/code/jackiewu/qwen-int4-finetune
运行环境 | Environment
- OS:
- Python:3.10.12
- Transformers:4.32.0
- PyTorch:2.0.1
- auto-gptq:0.4.2 ,optimum:0.13.2
- CUDA (`python -c 'import torch; print(torch.version.cuda)'`):

备注 | Anything else?
no

您好，我们无法打开您提供的kaggle链接。
根据报错，请检查模型目录下是否有tokenization_qwen.py、tokenization_config.jsony和qwen.tiktoken这个三个文件。如果您使用了自定义代码，请确保trust_remote_code设置为True。

代码链接可参考：https://www.kaggle.com/code/jackiewu/qwen-1-8b-finetune ，我使用git clone 下来里面也是有这3个文件的，但是运行时候依然出现上面问题

您好，请问最后解决了吗


Proposal: Move ElementAnimator out of preview and into release

Proposal: Move ElementAnimator out of preview and into release

Summary

ElementAnimator has been marked as a preview component for quite a while. Is it time to release it?
Rationale

Windows 10X shell would benefit from the ability to use ElementAnimator but can't take a dependency on prerelease WinUI packages.

Scope

Capability
Priority

Important Notes

Open Questions

@YuliKl @ranjeshj what's the status on ElementAnimator?

(For reference: ElementAnimator.h; I don't see any immediately-relevant specs)

(For reference: ElementAnimator.h; I don't see any immediately-relevant specs)


Error at exporting pmx file

Hello,
I have a problem when exporting pmx file in fresh blender v2.78. Here is the error message:

Traceback (most recent call last):
File  "C:\Program Files\Blender Foundation\Blender\2.78\scripts\addons\mmd_tools\operators\fileio.py", line 192, int execute
rig = mmd_model.Model(root)
File "C:\Program Files\Blender Foundation\Blender\2.78\scripts\addons\mmd_tools\core\model.py", line 60, in init
if root_obj.mmd != 'ROOT':
AttributeError: 'NoneType' object has no attribute 'mmd_type'
location: : -1

@powroupi is the current developer of mmd_tools.
You can find lots of great bug fixes and additional features in the version of mmd_tools by @powroupi:
https://github.com/powroupi/blender_mmd_tools/archive/dev_test.zip
https://github.com/powroupi/blender_mmd_tools
https://github.com/powroupi/blender_mmd_tools/issues

I'm having this same problem :(

The original version of mmd_tools by sugiany is no longer being developed by sugiany. You need to try the powroupi fork of mmd_tools, which has many bug fixes and additional features.


Fixed imports in screen_lock

After removing certain exports in #70, we need to add some /src exports to screen_lock

ah, you were too fast for me @naoki0719.
I noticed we should also re-export export 'src/layout/secrets.dart';, because you are using it in the example.
I will make another pull request.
I will also look into the retryDelay issue.

Thanks for the PR.
Yes, keypad does seem to require import, but I was wondering if there was a better way.
But this time it is in our best interest to add an import to handle it.


Explorer account info not loading consistently

Describe the bug (required)
The explorer has been acting erratic for me: my account information doesn't always load across various pages (transcoder, account overview, 'delegating' tab, etc).
Expected behavior (required)
Account information to load quickly and consistently.
To Reproduce (required)
Steps to reproduce the behavior:

Go to explorer.livepeer.org
Sometimes the "My Account" button doesn't show. I can't see the "Bond" button on the transcoders, my delegation dashboard is empty, etc. Sometimes they show up after awhile, but not always.

Device (required):
Chrome, OSX
Console logs (optional)
Note that it is difficult to capture the console logs; the page seems to reload frequently, which throws tons of exceptions, and the debugger blocks the rest of the UI. But I'm not a Chrome dev console guru.
main.251bc047.js:1 Error: Subscription field must return Async Iterable. Received: [object Object]
    at main.251bc047.js:1
(anonymous) @ main.251bc047.js:1
21:52:49.085 main.251bc047.js:1 Unhandled GraphQL subscription error Error: Subscription field must return Async Iterable. Received: [object Object]
    at main.251bc047.js:1
error @ main.251bc047.js:1
21:52:49.085 main.251bc047.js:1 Error: Subscription field must return Async Iterable. Received: [object Object]
    at main.251bc047.js:1
(anonymous) @ main.251bc047.js:1
21:52:49.086 main.251bc047.js:1 Error: Subscription field must return Async Iterable. Received: [object Object]
    at main.251bc047.js:1
(anonymous) @ main.251bc047.js:1
21:52:49.130 main.251bc047.js:1 Uncaught Error: Subscription field must return Async Iterable. Received: [object Object]
    at main.251bc047.js:1
21:52:49.131 main.251bc047.js:1 Uncaught Error: Subscription field must return Async Iterable. Received: [object Object]
    at main.251bc047.js:1
21:53:28.041 main.251bc047.js:1 Unhandled error GraphQL error: [ethjs-rpc]  error with payload {"id":287602123758,"jsonrpc":"2.0","params":[{"from":"0x867c90a7f48fb39b2f3ccbdd33e5002477b935ae","gas":"0x200b20","to":"0x","data":"0x70a08231000000000000000000000000867c90a7f48fb39b2f3ccbdd33e5002477b935ae"},"latest"],"method":"eth_call"} Error: JsonRpcEngine - response has no error or result for request:
{
  "id":<PHONE_NUMBER>,
  "jsonrpc": "2.0",
  "params": [
    {
      "from": "removed",
      "gas": "0x200b20",
      "to": "0x",
      "data": "0x70a08231000000000000000000000000867c90a7f48fb39b2f3ccbdd33e5002477b935ae"
    },
    "latest"
  ],
  "method": "eth_call"
} Error: GraphQL error: [ethjs-rpc]  error with payload {"id":287602123758,"jsonrpc":"2.0","params":[{"from":"0x867c90a7f48fb39b2f3ccbdd33e5002477b935ae","gas":"0x200b20","to":"0x","data":"0x70a08231000000000000000000000000867c90a7f48fb39b2f3ccbdd33e5002477b935ae"},"latest"],"method":"eth_call"} Error: JsonRpcEngine - response has no error or result for request:
{
  "id":<PHONE_NUMBER>,
  "jsonrpc": "2.0",
  "params": [
    {
      "from": "removed",
      "gas": "0x200b20",
      "to": "0x",
      "data": "0x70a08231000000000000000000000000867c90a7f48fb39b2f3ccbdd33e5002477b935ae"
    },
    "latest"
  ],
  "method": "eth_call"
}
    at new t (https://explorer.livepeer.org/static/js/main.251bc047.js:1:373298)
    at https://explorer.livepeer.org/static/js/main.251bc047.js:1:1077373
    at https://explorer.livepeer.org/static/js/main.251bc047.js:1:1084346
    at Array.forEach (<anonymous>)
    at https://explorer.livepeer.org/static/js/main.251bc047.js:1:1084326
    at Map.forEach (<anonymous>)
    at e.broadcastQueries (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1084233)
    at Object.next (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1085017)
    at v (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1031112)
    at m (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1031616)
e._subscription.e._subscription._observer.e._subscription._observer.error.e._subscription._observer.error @ main.251bc047.js:1
21:53:28.041 main.251bc047.js:1 Unhandled error GraphQL error: Cannot read property 'name' of undefined Error: GraphQL error: Cannot read property 'name' of undefined
    at new t (https://explorer.livepeer.org/static/js/main.251bc047.js:1:373298)
    at https://explorer.livepeer.org/static/js/main.251bc047.js:1:1077373
    at https://explorer.livepeer.org/static/js/main.251bc047.js:1:1084346
    at Array.forEach (<anonymous>)
    at https://explorer.livepeer.org/static/js/main.251bc047.js:1:1084326
    at Map.forEach (<anonymous>)
    at e.broadcastQueries (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1084233)
    at Object.next (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1085017)
    at v (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1031112)
    at m (https://explorer.livepeer.org/static/js/main.251bc047.js:1:1031616)
e._subscription.e._subscription._observer.e._subscription._observer.error.e._subscription._observer.error @ main.251bc047.js:1
21:53:46.406 delegating:1 Failed to load resource: the server responded with a status of 403 ()

@j0sh did you upgrade your MeteMask recently?

My MetaMask certainly isn't what it used to look like, but I'm not sure when it was updated. Within the last few months for sure. I haven't used the explorer in a little while, so that might be related.

@j0sh I think the security update that MetaMask put in effect this week is what is causing the explorer to react that way. I merged a PR from @ya7ya this week that I hope will fix this but I am still looking into other opportunity to get around it.

@j0sh the latest deployment have fixed some of the instability issues within the explorer, but not all. I am looking into what is causing the errors in the console. Can you please let me know if you find any other issue?

In Chrome I'm consistently seeing data fail to fetch/load. For example even the round indicator is grey, as if it can't tell what round we're in, if it's initialized or not. It is also failing to load any data on the transcoders page.


added sriov probe

responsibilites are:

take care of realtime changes in vf configuration
take care of realtime change for physical devices which provide sriov function
add all vfs currently configured on system
Partial-Bug: #SOFTID-200

Change-Id: I7736e052460ec83489c7360722d22e345f2d1960
Signed-off-by: Sergey Glazyrin<EMAIL_ADDRESS>skip skydive-cdd-overview-tests
skip skydive-go-fmt
skip skydive-scale-tests
skip skydive-unit-tests
skip skydive-compile-tests
skip skydive-functional-tests-backend-elasticsearch
skip skydive-ppc64le-tests

Later on I'll add tests.

run skydive-functional-tests-backend-orientdb

run all

hey @safchain
Btw, please don't merge it yet, I'll contribute it from account assigned to samsung.com email. I didn't know the exact procedure, that's why I made this pull request from my private account, but it seems like the proper way to contribute according to my company regulations is to contribute from private github account but assigned to my samsung.com email

@sergeyglazyrindev @lebauce ok, tell us when ready, thanks for addressing the comments :)


TF Binding NaN loss issue

When I switched from tf.nn.ctc_loss to warpctc_tensorflow.ctc I got NaN loss for the early moment of training even though tf.nn.ctc_loss could learn normally.

I wouldn't know how should I make this issue reproducible on minimal configuration.
I had experienced NaN loss issue frequently(not always) on torch binding, and at that time I thought this NaN issue comes from training set. But when I could switched between tf implementation of ctc loss and warp-ctc, I am now suspect this NaN loss issue originated from warp-ctc core.
In the experience from torch binding of warp-ctc, warp-ctc would return NaN, inf, or -inf loss often.

I'm using Python 3.5.2 with Tensorflow 0.12.0 compiled from source code.
I've tested ctc_op_kernel version, and I confirmed that it did work normally.

Are you accounting for the fact that the "reserved" symbol defaults to 0 for the warpctc_tensorflow.ctc op and the highest symbol value for the tf.nn.ctc_loss op?  To switch between the two ops you need to either make sure your labels don't use the reserved symbol or set the blank_label parameter in warpctc_tensorflow.ctc.
The inputs are of course in different formats as well... are you sure you are sending in the label lengths, etc. correctly?  Also check that when using tf.nn.ctc_loss that proprocess_collapse_repeated is False and ctc_merge_repeated is True (their default values).  warp_ctc does not support the other configurations that the TF ctc does.
The torch bindings use the exactly same kernels under the hood, the only difference is shuttling the inputs into the functions.  So if it's working better for you in Torch I would suggest looking closely at the inputs to the warp_ctc kernel in the TF version to make sure they are what you want them to be.  If you can get inputs that produce a NaN or +/-inf in the TF op but not in the Torch op that would indeed be interesting.


ciao-image: Add regex pattern for validating UUID

It implements a regex validator for UUIDs in ciao-image service HTTP requests. It will respond with a Not Found (404) HTTP Error for all those requests that contain a malformed UUID.
It also fixes an issue with images getting from meta datastore. Errors handling needs to return a valid error when we have diferent than Not Found errors.
Fixes #563 and #566

@kaccardi, sure, change applied.

Coverage decreased (-0.03%) to 64.709% when pulling 7a3c233e0592f416cbf74f8abe37875f411ec36f on obedmr:issue-563 into d940dcc3edf3b6a4ea99b69ea2afd30d9bb3da6f on 01org:master.

Coverage decreased (-0.04%) to 64.697% when pulling 473fce6bdd2c4ced0412affb9003b5425ec85204 on obedmr:issue-563 into d940dcc3edf3b6a4ea99b69ea2afd30d9bb3da6f on 01org:master.

Coverage increased (+0.03%) to 64.768% when pulling 23a5de0a560712c5ffa0a940a5c5527e51a56bf1 on obedmr:issue-563 into d940dcc3edf3b6a4ea99b69ea2afd30d9bb3da6f on 01org:master.

Agree with @tpepper Let's put the regexp in ssntp/uuid.go

@tpepper @markdryan @kaccardi  changes applied. Thanks for the feedback.

Coverage decreased (-0.004%) to 64.752% when pulling 218e660e3aa64e4652007a0715e64bdc8c8b14f4 on obedmr:issue-563 into 49b9b8242c3dd8bb25805fc21e681981a039e797 on 01org:master.


Txt/fob to AL converter

Hi,
Are there plans to create a tx/fob to Al converter so that they can be easily converted to 7 million series al files.
or do you have an advice for that how can we do this?
Thanks
Varun Reddy

We do plan on releasing a txt -> Al conversion tool. In the initial release it will not support object id renumbering but focus only on syntax conversion.

This tool https://blogs.msdn.microsoft.com/freddyk/2017/02/28/renumbering-nav-object-ids/ supports AL files as well as txt and delta files - might be able to help on the renumbering.

Hi,
Thanks for the answers this helps us
Also will the converter be able to convert from AL to .txt? (Both sides)
Thanks,
Varun Reddy

Hi,
The tool is only intended to do one way conversion from .txt to .al files. There is no plan to support the reverse since we are moving away from it. Why would you need to convert back?


Add hint about GraphQL Usage

solves https://github.com/zalando/restful-api-guidelines/issues/514

:+1:

:+1:

:+1:


Update openj9 images (java 8 one no longer exists)

docker pull adoptopenjdk:8u292-b10-jdk-openj9-0.24.0-focal
Error response from daemon: manifest for adoptopenjdk:8u292-b10-jdk-openj9-0.24.0-focal not found: manifest unknown: manifest unknown

➜  docker git:(master) ✗ docker pull adoptopenjdk:8u292-b10-jdk-openj9-0.26.0-focal
8u292-b10-jdk-openj9-0.26.0-focal: Pulling from library/adoptopenjdk

I see these images aren't published?
Should we just delete this then? There doesn't seem to be a lot of demand judging by no 👍 on the issue
ref https://github.com/jenkinsci/docker/issues/1091

I see these images aren't published?
Should we just delete this then? There doesn't seem to be a lot of demand judging by no 👍 on the issue
ref #1091

No objections from me if we delete the images.
I believe that one of the reasons they were originally included is that there is not JDK 8 hotspot for IBM s390x.  In order to have acceptable Java 8 performance on s390x, the user must run OpenJ9.  Thankfully, the JDK 11 implementation for IBM s390x includes hotspot, so OpenJ9 is not required for good performance.


opentelemetry-dart 0.17.0

Which problem is this PR solving?
This PR combines changes and updates from the following branch PRs:

#118
#123
#124
#125
#128
#129

How Has This Been Tested?

Confirm that unit tests pass following these changes.
Loaded these changes in a small testing application and confirmed that it can be used to properly emit traces.

Security Insights

Error scanning for image validation issues

Action Items

Review PR for security impact; comment "security review required" if needed or unsure
Verify aviary.yaml coverage of security relevant code

Questions or Comments? Reach out on Slack: #support-infosec.

@aviary-wf

Loaded these changes in a small testing application.  Confirmed that it can be used to properly emit traces.  Confirmed that context propagates appropriately.
QA +1

@aviary-wf Can you try running again?

Loaded these changes in a small testing application. Confirmed that it can be used to properly emit traces. Confirmed that context propagates appropriately.
QA +1

@Workiva/release-management-p

Loaded these changes in a small testing application. Confirmed that it can be used to properly emit traces. Confirmed that context propagates appropriately.
QA +1


Add validation Github workflow

Fourth of 4 PRs, as part of dataset configuration file validation. To be merged after #129

The output of the action should probably list the files that failed validation

The workflow outputs the log files as an archive, the previous run is here: https://github.com/chanzuckerberg/cryoet-data-portal-backend/actions/runs/9883555982?pr=130. Sorry if this is a bit confusing, but I decided to do it this way because sometimes the log files can get quite long.
Note that this is expected to fail right now, since we're still working through the validation and updating the schema / template / config files. Thanks!

Ok, the full JSON output can be super long but I think we can parse the errors down to something fairly reasonable (even if there are a lot of failures at the moment. Because eventually we expect to have very few failures (probably only the most recent dataset being added to the repo) and having to download and review artifacts is a pretty cumbersome workflow imop. Based on reviewing the JSON output, we should be able to print something along these lines:
FAIL: ../dataset_configs/10008.yaml"
    - Extra inputs are not permitted: tiltseries.0.metadata.alignment_binning_factor

FAIL: ../dataset_configs/10009.yaml"
    - Field required: tiltseries.0.metadata.tilt_axis
    - Field required: tiltseries.2.metadata.tilt_axis

Basically we can just print the "msg" string for each error, and the "loc" data separated by . characters. This should be a good enough hint at what needs fixing, even if the loc strings look a little funny.

Annnnd one more thing -- the filtered error files (dataset_config_validate_errors_filtered.txt and dataset_config_validate_errors_filtered_2.txt) in the build artifact are a little hard to understand + I think they only show errors for the last dataset that was processed? It seems like they're too short. Personally I'd consider doing away with the filtered output entirely and just having the utility script output errors in the format I suggested above ^^

Sounds good! I've gone ahead and made the changes, thanks! Note that the validation right now is still in progress and by no means comprehensive, so that's why there might be fewer errors than expected. Thanks!


Lint/IncompatibleIoSelectWithFiberScheduler suggestion omits require io/wait

The cop Lint/IncompatibleIoSelectWithFiberScheduler suggests switching to wait_readable / wait_writeable, but those methods aren't necessarily available without requiring io/wait.  In a small script, for example, this may not have been loaded by some other library, so the suggestion and auto-correction as given may be breaking.

RuboCop version
$ rubocop -V
1.22.3 (using Parser <IP_ADDRESS>, rubocop-ast 1.13.0, running on ruby 3.0.2 x86_64-darwin20)

Thank you for the feedback. I've confirmed it and open #10269.


suppress installation of Python dependencies

Fixes ros2/examples#41.
Connects to ros2/examples#41

This suppresses the auto installation of dependencies, and the builds pass since it's python and just copying files. And osrf_pycommon has a fallback mode so I can't easily test the results failing.
I've confirmed that building from source now works offline.
+1


feat: Show a modal on Companies page when user does not have access

Description ✏
Closes #314
Describe what this PR does.

When user does not have access to reviews page (checked by utilizing hasReviewsAccess from #313), then show a modal to specify why they don't have access to reviews yet

Type of Change 🐞

[x] Feature - A non-breaking change which adds functionality.
[ ] Fix - A non-breaking change which fixes an issue.
[ ] Refactor - A change that neither fixes a bug nor adds a feature.
[ ] Documentation - A change only to in-code or markdown documentation.
[ ] Tests - A change that adds missing unit/integration tests.
[ ] Chore - A change that is likely none of the above.

Checklist ✅

[x] I have done a self-review of my code.
[x] I have manually tested my code (if applicable).
[x] I have added/updated any relevant documentation (if applicable).

This looks great to me!

@ramiAbdou Ateeeeeee. Nice working with you on this feature @rafa1510!

Likewise @ciaracade! 🤝🫡


Option does not exists --plain

When the following command is ran php artisan make:controller TaskController --plain, the following error is displayed:
  [Symfony\Component\Console\Exception\RuntimeException]
  The "--plain" option does not exist.

hi,
it's means that, your version is 5.2,in 5.2 only one option to use is --resource, 5.1 's --plain is instead of no option or parameters.
so,you can do this:
php artisan make:controller TaskController
if you want the older versions controller,you can do this:
php artisan make:controller TaskController --resource

--plain has been removed from the tutorial.
Can this issue be closed?

@wedojava @petermichaux thank you .

@wedojava
Thank you man.

@wedojava Thank you .

https://laravel.com/docs/5.4/artisan
Reference to "--plain" still exists here.

Thanks

When the following command is ran >php artisan make:migration create_product_table --create-product
the following error is displayed: [Symfony\Component\Console \Exception\RuntimeException]
The "--create-product" option dose not exist.
Help me, please.

it is --create=product not --create-product

thanks

thanks, i use laravel 5.6

how is work in version 5.6

how is work in version 5.6

please help me


Don't set logger if "net.spy.log.LoggerImpl" property is already set

We would like to override the logger in our build, so we set "net.spy.log.LoggerImpl" before initializing Shade.

#7 was merged, so this can now be closed


Header Bar in iOS 8 gets displaced even if I disable status bar

I have disabled status bar in my app, but the header bar is still displaced in my app. I cannot figure how to manage this displacement or change it. It should automatically detect, if the status bar exist then only add the extra padding.
Even if I enable my status bar, the header bar starts below the status bar and complete alignment goes flawed.

You could try adding this line to your .run function, where you are hiding the status bar:
.run(function($ionicPlatform) {
    ionic.Platform.fullScreen();
})

It realigns all stuff after status bar has been hidden. I had the same issue just few days ago. Hope it helps.

@maciulaitis' s solution is the proper way to tell Ionic to go fullscreen (remove status bar padding).


Is that possible to change a specific column's html ?

For some columns, I need some custom behaviors, so I need to customize its html, can I do that ?

There are a number of specific ways to customise:

cellTemplate
headerCellTemplate
headerFilter
cellFilter
cellClass

If none of those meet your needs, then you can write a custom directive to extend it.

Thanks for the response, in my case, for a column, for each row of that column, I need a different html. But using cellTemplate, that is for the whole column. I am wondering if I can define cellTemplate when I define the data ?

There is no way to have a per-cell html.  Usually you'd do that by setting your cell template to a directive, and then burying your optionality inside that directive, or if your logic isn't too complex, just using an ng-if in the cell template.

Solution provided, and no new comments for over 3 weeks.  Assuming issue is resolved, closing.


<EMAIL_ADDRESS>

Iteration 1 for : Code for - Evaluation article : "Creating a deep vs shallow copy of an object in Java"

Code for - Evaluation article : "Creating a deep vs shallow copy of an object in Java"

updated with latest missing files

Closing PR


Add numpy<2.0 to requirements

The NumPy API may change in 2.0 (https://github.com/numpy/numpy/issues/24300), so ensure we are only using NumPy 1.x until we have properly tested NumPy 2.0.
Pull request checklist

[x] Add a clear description of the change
[ ] Add any new tests needed
[ ] Run spell check on new text visible to user (documentation, GUI etc.)
[x] Check any changes to requirements.txt are reflected in setup.py
[ ] Check code passes CI checks (run run_ci.sh or check GitHub Actions)

See CONTRIBUTING.md for more details.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2759

Relevant Lines:
2773

💛  - Coveralls


Congo theme error function "hasSuffix" not defined

Language
English
What's the issue?
Trying to start hugo with the theme congo fresh from a install and I get the error below.
Any idea how to fix ?
hugo server
go: no module dependencies to download
hugo: downloading modules …
go: downloading github.com/jpanther/congo/v2 v2.8.0
go: downloading github.com/jpanther/congo v1.6.4
go: added github.com/jpanther/congo/v2 v2.8.0
hugo: collected modules in 7839 ms
Error: add site dependencies: load resources: loading templates: "/tmp/hugo_cache/modules/filecache/modules/pkg/mod/github.com/jpanther/congo/v2@v2.8.0/layouts/_default/_markup/render-link.html:11:1": parse failed: template: _default/_markup/render-link.html:11: function "hasSuffix" not defined
Theme version
v2
Hugo version
v0.92.2+extended
Relevant Hugo log output
hugo server
go: no module dependencies to download
hugo: downloading modules …
go: downloading github.com/jpanther/congo/v2 v2.8.0
go: downloading github.com/jpanther/congo v1.6.4
go: added github.com/jpanther/congo/v2 v2.8.0
hugo: collected modules in 7839 ms
Error: add site dependencies: load resources: loading templates: "/tmp/hugo_cache/modules/filecache/modules/pkg/mod/github.com/jpanther/congo/v2@v2.8.0/layouts/_default/_markup/render-link.html:11:1": parse failed: template: _default/_markup/render-link.html:11: function "hasSuffix" not defined

please close i will open in the correct section not language.

The template tries to load and get an error
cat<EMAIL_ADDRESS>{{- $link := .Destination -}}
{{- $isRemote := strings.HasPrefix $link "http" -}}
{{- if not $isRemote }}
{{ $url := urls.Parse .Destination }}
{{- if $url.Path }}
{{ $fragment := "" }}
{{- with $url.Fragment }}{{ $fragment = printf "#%s" . }}{{ end -}}
{{- with .Page.GetPage $url.Path }}
{{ $link = printf "%s%s" .RelPermalink $fragment }}
{{ else }}
{{- if hasSuffix $url.Path ".md" }}
{{ warnf "[CONGO] Can't resolve: %s" .Destination }}
{{ end -}}
{{ end -}}
{{ end -}}
{{ end -}}

<a href="{{ $link | safeURL }}"{{ with .Title }} title="{{ . }}"{{ end }}{{ if $isRemote }} target="_blank" rel="noreferrer"{{ end }}>{{- .Text | safeHTML -}}

I found that many files the functions are missing the . in the beginning like .page or .continue etc..
Is that because of the version of Hugo or the files need to be corrected ?

After fixing the files, now I am getting the following errors
hugo server
Start building sites …
hugo v0.92.2+extended linux/amd64 BuildDate=2023-01-31T11:11:57Z VendorInfo=ubuntu:0.92.2-1ubuntu0.1
ERROR 2024/02/29 21:16:41 render of "taxonomy" failed: "/tmp/hugo_cache/modules/filecache/modules/pkg/mod/github.com/jpanther/congo/v2@v2.8.0/layouts/_default/baseof.html:5:12": execute of template failed: template: _default/taxonomy.html:5:12: executing "_default/taxonomy.html" at : can't evaluate field LanguageCode in type *langs.Language
ERROR 2024/02/29 21:16:41 render of "taxonomy" failed: "/tmp/hugo_cache/modules/filecache/modules/pkg/mod/github.com/jpanther/congo/v2@v2.8.0/layouts/_default/baseof.html:5:12": execute of template failed: template: _default/taxonomy.html:5:12: executing "_default/taxonomy.html" at : can't evaluate field LanguageCode in type *langs.Language
Error: Error building site: failed to render pages: render of "home" failed: "/tmp/hugo_cache/modules/filecache/modules/pkg/mod/github.com/jpanther/congo/v2@v2.8.0/layouts/_default/baseof.html:5:12": execute of template failed: template: index.html:5:12: executing "index.html" at : can't evaluate field LanguageCode in type *langs.Language
Built in 35 ms

I was able to fix by adding 2.6.1 version in the go.mod file, seems that any version >=2.7.0 doesn't work.

you’re running a pretty old version of hugo…
the latest is 0.123.7 as of yesterday… there’s a lot of changes; most of them good… but if you’re just starting out you’ll really be best served by starting there

I can't replicate this issue. As suggested above, have you tried upgrading your Hugo version?


rclcpp 0.4.0 changes

Complementary PR with: ros2_control PR
Maybe we should create branch ardent to have ros2_control versions trackable with rclcpp versions.
@Karsten1987
Current build error -
ros2_ws/src/ros2/ros2_controllers/ros_controllers/src/trajectory.cpp:38:5: error:
‘now’ is not a member of ‘rclcpp::Time’
     rclcpp::Time::now() :

PR builds successfully with current ros2 master: https://github.com/ros2/ros2/commit/7fd60b8325e455bbbaa19574a560f0119b400e94


Refactoring

I unified several aspects:

spaces around operators (A + B instead of A+B)
formatting of parentheses after if and for

if (statement) {
    a <- 1
} else {
    a <- 2
}

instead of
if (statement)
{
    a <- 1
} else
{
    a <- 2
}

I verified on one example that the code works, but I am not sure how to verify that I have not accidently broke something (I used a lot of find & replace).
Feel free to reject this if you don't like the style I tried to introduce, or if it's not easy to test that everything works (I did chance like 1500 lines).

Damn, this was unintentional. I thought I am creating a pull request to Rhyker's fork.


urlize does not check boundaries well enough if there's escaped HTML right before a URL

>>> print render_template_string('{{ "testfoohttp://www.google.com"|escape|urlize }}')
test<strong>foo</strong>http://www.google.com

Does it make sense to accept anything besides a-z chars (and maybe + for git+https://.. and similar URLs) at the start of a URL?

Part of the issue here is that when we extract the URL within the text, we only extract the leading/trailing punctuation instead of extracting additional items like words. Probably because it'd be pretty complicated to actually do, and it'd break more edge cases than it fixes.
I looked around at other urlize implementations and they also appeared to have similar issues.

With the changes in #1195, this doesn't get linked at all, it just outputs the (escaped) input string. The new parser only accepts http... if it's at the start of the word now. I think that behavior makes sense. If you need to urlize a string that already contains HTML, you probably want to be using a more complete parser like Markdown. Any objections to closing this?

With the changes in #1195, this doesn't get linked at all, it just outputs the (escaped) input string. The new parser only accepts http... if it's at the start of the word now. I think that behavior makes sense. If you need to urlize a string that already contains HTML, you probably want to be using a more complete parser like Markdown. Any objections to closing this?


full typings

keeping track of typings in this issue

most of the parameters given in the docs examples are of type number, but it only accepts string. suggestion: make both acceptable


chore: upgrade jenkins-x/jx3-versions to version 1.0.17

from: https://github.com/jenkins-x/lighthouse.git

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign rajdavies
You can assign the PR to them by writing /assign @rajdavies in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
b1b7a028721f2fdee104cc83983ba9e73ab8bb5b
link
/test gsm-kapp

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

/retest


Not permited instruction

face_recognition version: face-recognition-1.0.0
Python version: python2.7
Operating System: Kali-Linux

Description
I was tryng to start the program when I got "Instruction non permise" as an erro
What I Did
root@Kali-Linux:~# face_recognition
Instruction non permise

Please see https://github.com/ageitgey/face_recognition/issues/11#issuecomment-287398611


Display gzipped size in the status bar

It would be really useful to display the gzipped size of the current opened file in the status bar next to the uncompressed size, without having to click and open the panel.
I have in mind something like this: 20.65 KiB (5.17 KiB), where the first value is the actual uncompressed size, and inside the parentheses the gzipped value.

Hey @mkxml, are you planning on adding this? I saw a commit related to it but it wasn't in master, is this a performance concern?

@Masquerade-Circus PR was merged addressing this. I'll close this now.

It will be on the next release.


Download test wasm instead of recompiling it

Note that this change makes the script unusable with a custom canister name and thus we might as well integrate its functionality into deploy_test_canister.sh

Note that this change makes the script unusable with a custom canister name and thus we might as well integrate its functionality into deploy_test_canister.sh

Thanks for the tip, @mraszyk. I gave it another try.


Publisher stop processing Mqtt Rpc after one failed to connect to OPC server - always tries to reconnect forever

Describe the bug
If one Mqtt Rpc is sent with an inaccessible opc server as parameter (see endpointmodel), the OpcPublisher will forever try to connect to it anyway and ignore any subsequent Rpc.
To Reproduce
Steps to reproduce the behavior:

Go to Industrial-IoT\deploy\docker
Execute docker-compose -f .\docker-compose.yaml -f .\with-mosquitto.yaml up -d
This will start the demo with Mqtt
Go to Industrial-IoT\samples\Mqtt
Open MqttSamples.sln with visual studio
Right click on ReadCurrentTime project and click Set as target project
Press F5, the project will execute successfully and display current time.
Close it.
Open the file Industrial-IoT\samples\Mqtt\ReadCurrentTime\ReadCurrentTime.cs in the editor.
Modify line 34, replace the good url "opc.tcp://opcplc:50000" with a wrong one, for example "opc.tcp://opc-plc:50000"
Press F5 again, the project will not display the current time anymore because of course the url is wrong.
Revert back the changes with the good url, run the project again, it is not working anymore neither.
Look at the logs of the OpcPublisher, it is locked in an infinite loop of trying to connect to the wrong url, and ignore any subsequent Rpc.
You can also open the Mqtt Explorer at http://localhost:4000/ to see the Mqtt Rpc messages

Expected behavior
The retry and abandon policies should apply: OpcPublisher should abandon this Rpc to execute the subsequent ones.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Not related
Smartphone (please complete the following information):
Not related
Additional context
Add any other context about the problem here.

#2203

This is partially fixed in 2.9.8 as I just tested (thanks for the detailed repro steps).
Timing out a service request will come in 2.9.9, then the infinite connect loop will be handled.

Service calls will now automatically timeout after 3 minutes of not being able to connect or service call "hung".  Timeouts can be adjusted via -cto and -sct command line parameters, or via the request header fields.


V2 converter depends on javax not jakarta packages

If you try to use the converter in a modern Jakarta-packaged application you get problems with duplicate classes in swagger-core and swagger-annotations. The workaround is to exclude them and depend explicitly on the jakarta-based versions, e.g:
		<dependency>
			<groupId>io.swagger.core.v3</groupId>
			<artifactId>swagger-core-jakarta</artifactId>
			<version>2.2.9</version>
		</dependency>
		<dependency>
			<groupId>io.swagger.parser.v3</groupId>
			<artifactId>swagger-parser-v2-converter</artifactId>
			<version>2.1.16</version>
			<exclusions>
				<exclusion>
					<groupId>io.swagger.core.v3</groupId>
					<artifactId>swagger-core</artifactId>
				</exclusion>
				<exclusion>
					<groupId>io.swagger.core.v3</groupId>
					<artifactId>swagger-models</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

This is kind of annoying, even though it's a problem that is created by the core libraries. It seems we need to have a "-jakarta" version of the converter library too?

Yes we hit that too with Apache Camel. We have to so many exclusions as you say etc. And we can only do this for our own maven modules. But our end user of Camel may bring in their own set, such as jackson-databind that bring in old swagger JARs and whatelse.


Update log levels

Some of the logs that the SDK emits are either too verbose or have an incorrect log level.
The following log lines should really be changed from Info -> Debug, as they are internal messages about what the informer is doing:
pkg/sdk/informer-sync.go, line 65:
logrus.Infof("Object (%s) is deleted", key)

pkg/sdk/informer.go, line 79:
logrus.Infof("starting %s controller", i.resourcePluralName)

pkg/sdk/informer.go, line 91:
logrus.Infof("stopping %s controller", i.resourcePluralName)

The following log line should really be changed from Info -> Warn as it is something that should be brought to the attention of the user of the SDK:
pkg/sdk/informer-sync.go, line 113:
logrus.Infof("Dropping key (%v) out of the queue: %v", key, err)

The user can then modify the log level to use for the operator with the following:
logrus.SetLevel(logrus.DebugLevel)

I'm happy to submit a PR to change this, but thought I would open an issue first to start the discussion.

We would definitely welcome some logging cleanup:-) Feel free to submit the PR.


Date Picker does not work in FF 34.0.5

Hello,
Compliments for the project thus far. Looks already very good.
I tried to use the date picker. It works fine in Chrome and Safari but on FF when clicking inside the date field it doesn't do anything. Only when clicking on the label 'Pick a date', the date picker pops up.

This seems to be the same issue like in #104 (which is newer, but has some activity).

Found the same problem, also won't allow to delete the date and make the field empty/null.
Also kudos, to the project, awesome work.

Hi,
I am not sure if this problem is already resolved - I can still see it on the documentation page. I am looking for a datepicker for my project, and at the moment I am checking Yours. The problem with datepicker in Firefox is with disabled attribute on the input. HTML docs say that disabled element is unusable and unclickable(link). On the other hand, readonly attribute leaves input clickable - and the general functionality is similar to disabled.
I hope this helps You!

I'm going to take a look on this issue next week.
Sorry for the lack of support, we're going to release a major release of LumX with a brand new documentation at the end of the month :-)

In the last version, we've reworked and fixed a lot of things. If this issue is still happening, please re-open the issue. Thank you!


x1080—As ARA (Harriet), I want the "cDNA amplification" operation renamed "Amplification" and to record number of cycles.

Rename op "cDNA amplification" to "Amplification".
Can record "Cycles" (non-negative integer) for each slot in the labware.
Also, cq value should support 2 decimal places.
Rename view cDNA_amp_view to visium_amp_view and update with cycles.
"Cycles" is a mandatory field
Textfield to update "Cycles" values for all slots

@KatyTudor

Is "Cycles" a mandatory field for each slot?
Also, do we need a global value field in UI for "Cycles" as we have for "Cq value"?

@seenanair yes to both please that would be great

Ok, Thank you 👍

@khelwood has the view been updated?

@KatyTudor no probably not. I'll do that when I'm back.

@khelwood thanks

@KatyTudor I had a few minutes: I've updated the view on stan-uat.


I18n.localize changes the argument time zone

Description
Before upgrading to Rails7, everything was working as expected, but now it seems I18n.localize takes the browser time_zone instead of the one I pass to it:
How to reproduce
I18n.localize('date.formats.events_time_format',  "2022-04-24T15:00:00.000Z")

What do you expect
I expect to see 15:00:00 like I did with Rails 6 (currently on Rails 7)
What happened instead
I see 16:00:00, which I suspect is because we are in summer time (BST) and maybe this is what the Browser is passing?
Software:

Gem version: 3.3.11
Ruby version: [ruby 3.1.2p20

I have no idea why rails version would affect this project's code
I traced the method call to parseDate
I rarely used Date so I have no idea what it's doing inside

Ah, it's possible the rails version was unrelated and this was just the start of BST (British Summer Time) that coincided with this!

I don't even know what resource.starts_at.slice(0, -1) means D:

I see this issue is closed now, what is the solution to this please?


Issue 128: adds decode_authorization_messages support for Amazon EC2 resources

Issue
https://github.com/mayn/packerlicious/issues/128
List of Changes Proposed
adds decode_authorization_messages support for all Amazon EC2 Resources
Testing Evidence
https://www.packer.io/docs/builders/amazon-chroot.html#decode_authorization_messages
https://www.packer.io/docs/builders/amazon-ebs.html#decode_authorization_messages
https://www.packer.io/docs/builders/amazon-ebssurrogate.html#decode_authorization_messages
https://www.packer.io/docs/builders/amazon-ebsvolume.html#decode_authorization_messages
https://www.packer.io/docs/builders/amazon-instance.html#decode_authorization_messages

Coverage remained the same at 100.0% when pulling 3952bde7c55d56566f96952705e1d282273d3e7d on taoistmath:issue_128 into 739a415c1fd74252e7d00e3574532c01322b8f95 on mayn:master.


Remote SSH connections can take a long time to open a webview

The root cause of this issue is the index_bundle.js is 16MB.

See this issue here:
https://github.com/microsoft/vscode/issues/82190

SOlution ideas

Change our index bundle to be a zipfile loader with minimal UI, and send that zip across with a message
Create a UI extension that caches all the webview stuff on it

Current plan is to create an HTTP server on the same machine that the extension  is loaded from and use code splitting. Probably at the nteract level.


fix cache path for ubuntu builds

Critical Changes
Changes
Issues Closed

@jstvz I used this to fix the start_time tests that were hardcoded to yesterday's date -- weird coincidence that that happened right after we were working on that code.