Is there a way to only retain istio_requests_total metrics and drop all the metrics?

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
We get a lot of metrics from stats/prometheus endpoint, is there a way to reduce the amount of metrics from source as envoy gives us a lot of metrics and have only istio_requests_total.
I see there is a way by providing inclusion_list for envoy configuration, Can someone help how to configure this?
We have used helm to setup istio
Version
using istio 1.17

Additional Information
No response
Affected product area

[ ] Ambient
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Control Plane Revisions

you can try https://istio.io/latest/docs/tasks/observability/telemetry/

you can try https://istio.io/latest/docs/tasks/observability/telemetry/

metrics:
    - providers:
         - name: prometheus
      overrides:
        - disabled: true
          match:
            mode: CLIENT
            metric: REQUEST_COUNT

should use something like this to disable all the metrics ? is there a way to keep only one metrics called istio_requests_total ? instead of having the list grow to exclude all the metrics that is not required?

metrics like these needs to be ignored
envoy_cluster_upstream_cx_connect_ms_bucket
envoy_cluster_upstream_cx_length_ms_bucket
envoy_listener_manager_lds_update_duration_bucket
etc...

you can change envoy's stats configuration with  custom bootstrap https://github.com/istio/istio/blob/master/samples/custom-bootstrap/README.md

Created a configmap

used annotation sidecar.istio.io/bootstrapOverride: istio-custom-bootstrap-config
However i still see the endpoint stats/prometheus giving a lot of metrics

can you verify the output of istioctl pc b <pod_name> -n <pod_namespace>

FYI, istio rely on some stats metrics, you can find details here.
If you realy don't want those metrics, you can drop it when scraping.

Proxy logs,

Also do we need to disable envoy filter ? as the telemetry approach also didn't reduce envoy metrics and this as well


Add test case for iot-qcow2-image

This pull request includes:

[ ] adequate testing for the new functionality or fixed issue
[ ] adequate documentation informing people about the change such as

[ ] submit a PR for the guides repository if this PR changed any behavior described there: https://www.osbuild.org/guides/

Tested iot-qcow2-image on fedora 38, works as expected.


fix: prevent checkbox icon from shrinking on small width

When the width for the Checkbox component is less than the label width Checkbox will shrink.
In this PR I just fix the problem with flex-shrink:0
before:

after:

@Ridvanovskyy @Flavien-Pensato Could you please tell me why this pull request hasn't been merged yet?


opae-v: fix issue found by static analysis

Signed-off-by: Tim Whisonant<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 4 (0.0%)  changed or added relevant lines in 1 file are covered.
7 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.04%) to 65.953%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

libraries/plugins/vfio/opae_vfio.c
0
4
0.0%

Files with Coverage Reduction
New Missed Lines
%

libraries/plugins/xfpga/open.c
1
74.68%

libraries/plugins/xfpga/mmio.c
6
82.87%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
13132

Relevant Lines:
19911

💛  - Coveralls


does not  update or install packages on versions 1.23.1 - 1.24.0b2

upgrade to version 1.23.1 and when I install a package does not leave me, I return to the previous version and everything is fine, install and update normally but return to the update and the same thing happens to me, update to aversion 1.24.0b2 and the result is the same, and the ip of the server changes constantly and still nothing happens, I leave a photo of what was described, thanks in advance

This issue is close, fix on relaease 1.25.0b3


[Feature] P2 Staking Tracker

This is the second of a series of PRs aimed at reviving https://github.com/paritytech/substrate/pull/11013
Work on: https://github.com/paritytech/substrate/issues/12719

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2065597

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2065596

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2065595

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2070493

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2070494

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2070683

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2070684

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2070685

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2076476

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2076558

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2077065

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2077261

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2077260

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2078325

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2078318

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2078319

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2078320

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2094463

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2095742

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2095746

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2095785

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2095773

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2134258

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2134265

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2134263

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2134264

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2134611

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2134618

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2134616

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2141958

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2141964

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2142053

@kianenigma Writing this down for posterity and discussion, it looks like we'll need the NominatorsHelper + UnboundedNominations at least for the initial staking-tracker migration, so we can introduce it there. Why?
Because before the un-decodable nominator is chilled his stake should be accounted for.
We will also need to have UnboundedNominations in pallet-staking, because we can't chill nominators the way we do now anymore: ignoring their nominations when un-decodable. Why?
Again, because we need to subtract their stake from all the validators present in ApprovalStake map.
our current approach is this
	pub fn do_remove_nominator(who: &T::AccountId) -> bool {
		let outcome = if let Some(nominations) = Self::nominations(who) {
			Nominators::<T>::remove(who);
			let _ = T::VoterList::on_remove(who).defensive();
			let _ = T::EventListener::on_nominator_remove(who, nominations);
			true
		} else {
			true
		};

		debug_assert_eq!(
			Nominators::<T>::count() + Validators::<T>::count(),
			T::VoterList::count()
		);

		outcome
	}

but it needs to use something like
		pub(crate) fn get_any(who: &T::AccountId) -> Option<UnboundedNominations<T>> {
			frame_support::storage::unhashed::get::<UnboundedNominations<T>>(
				&Nominators::<T>::hashed_key_for(who),
			)
		}

to get the nominations.

Because before the un-decodable nominator is chilled his stake should be accounted for.

But am un-decodable nominator should never be crated as long as MaxNominations does not change.

Because before the un-decodable nominator is chilled his stake should be accounted for.

But am un-decodable nominator should never be crated as long as MaxNominations does not change.

Disregard the previous comment, it is outdated. The consensus is that we don’t cater for un-decodables in our code, if MaxNomination ever decreases - it should be accompanied by a migration that fixes the storage.

Because before the un-decodable nominator is chilled his stake should be accounted for.

But am un-decodable nominator should never be crated as long as MaxNominations does not change.

Disregard the previous comment, it is outdated. The consensus is that we don’t cater for un-decodables in our code, if MaxNomination ever decreases - it should be accompanied by a migration that fixes the storage.

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2183889

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2183883

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2183882

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2183947

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2183941

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2183940

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2184858

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2184853

The CI pipeline was cancelled due to failure one of the required jobs.
 You also have to dry-run the migration in WASM to make sure it is fine memory-wise.

Do it over multiple blocks, during which we should freeze any transactions going to staking. Otherwise we need to deal with: what if someone updates their nomination while the initial migration is happening? lots of edge cases here. Perhaps solvable, but I think now allowing staking operations for e.g. 10 blocks is probably fine.

I am inclined to vouch for doing option 1, but as of recently, we lifted the Polkadot max nomination intention limit, so someone can attack this migration. We should, unfortunately, but maturely, opt for option 2.
Perhaps the concurrency issues are not too hard and we can do it in a easy-going manner on-idle.

 You also have to dry-run the migration in WASM to make sure it is fine memory-wise.
Do it over multiple blocks, during which we should freeze any transactions going to staking. Otherwise we need to deal with: what if someone updates their nomination while the initial migration is happening? lots of edge cases here. Perhaps solvable, but I think now allowing staking operations for e.g. 10 blocks is probably fine.

I am inclined to vouch for doing option 1, but as of recently, we lifted the Polkadot max nomination intention limit, so someone can attack this migration. We should, unfortunately, but maturely, opt for option 2.
Perhaps the concurrency issues are not too hard and we can do it in a easy-going manner on-idle.

I'd probably do this on_initialize then to prevent any transactions from happening until this is finished.

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192095

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192088

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192090

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192099

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192164

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192174

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192163

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192178

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192168

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192169

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192223

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192237

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192226

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192222

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192228

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192227

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192286

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192279

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192290

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192415

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192425

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192418

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192420

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192414

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192419

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192429

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192513

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192508

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192507

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192506

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192517

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192502

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192503

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate-macos
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192935

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192932

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192922

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192933

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192928

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2192918

bot rebase

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate-macos
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221229

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221227

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221215

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221222

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221212

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-each-crate
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221226

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221916

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221917

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221915

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2221922

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222277

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222278

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222321

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222326

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222327

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222322

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222620

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2222619

closing as it will be replaced by smaller pieces to keep the projects and PR lists tidy.


We don't see the content of the article!!!

Please, I am in Chrome, I don't see anything there but the "We recommend the Razor Pages tutorial over the MVC version." where is the content? The article content is not visible to readers !

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

ID: 15e2038b-fa1b-897c-32ee-7173c7d1d909
Version Independent ID: 000c5a97-c1b2-9a48-289d-83ec4f0c0c98
Content: ASP.NET Core MVC with EF Core - Sort, Filter, Paging - 3 of 10
Content Source: aspnetcore/data/ef-mvc/sort-filter-page.md
Product: aspnet-core
GitHub Login: @Rick-Anderson
Microsoft Alias: tdykstra

Per the article
This tutorial has not been upgraded to ASP.NET Core 2.1. The ASP.NET Core 2.0 version of this tutorial is available by selecting ASP.NET Core 2.0 above the table of contents or at the top of the page:

Per the article
This tutorial has not been upgraded to ASP.NET Core 2.1. The ASP.NET Core 2.0 version of this tutorial is available by selecting ASP.NET Core 2.0 above the table of contents or at the top of the page:

why then there is an "ASP.NET Core 2.1" available in the combo box for that article to confuse people?


warning ... YAMLLoadWarning ... deprecated

first time user here. I get this RED warning message:
~/env/.../python3.5/site-packages/searchtweets/credentials.py:34:
YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated,
as the default Loader is unsafe.
Please read https://msg.pyyaml.org/load for full details.
  search_creds = yaml.load(f)[yaml_key]

when executing this code:
    premium_search_args = searchtweets.load_credentials("twitter_credentials.yaml",
                                       yaml_key="tweets_search_fullarchive",
                                       env_overwrite=False)

This was fixed in #68 - It's worth updating to the latest version on github, eg with pip:
pip install --upgrade git+https://github.com/twitterdev/search-tweets-python.git

Great, thanks. Why not / When deploy that to pypi ?
Also, I might leave you again - because now actually tweepy is trying out ways to support the premium search, hooray. And I have plenty of tweepy code already so that might make it easier for me then.

Oh, and now that I have your attention as someone at twitter ... what about these 2 suggestions:

a public repo for feature requests; see what I wrote about it above here:
a new API endpoint API.retweeted_with_comment(original_tweet_id) which returns "quoted retweets", i.e. "retweet with comment" tweets (which do NOT show up in the standard retweets API results), which would otherwise cause THOUSANDS of calls to your API as a workaround?

For requests for new features this is the place to post them: https://twitterdevfeedback.uservoice.com/ (this is for API features, not UI)
Or there's always https://twittercommunity.com/
For searching for retweets with comment, you need to use the Search API: https://github.com/tweepy/tweepy/issues/1291#issuecomment-552561035

Thanks a lot for your suggestions, very helpful.

searching for retweets with comment, you need to use the Search API

yes, I am aware of that - and I am looking into Premium search ... exactly for that.
However, are you aware that I will be causing >3000 API calls instead of 1 ?
And each repeat, again ... several thousand calls.
I suggest you discuss how that can be avoided. Probably with a new API endpoint, no?

That's a lot of calls to make, it will get very expensive with Premium - 5000 calls on 30day endpoint is $1300 for example. Remember that Premium supports longer queries, so it's more efficient to batch calls together - so instead of searching for quotes of a single tweets, you'd search for quotes of multiple ones with OR, eg: url:1194044665164640257 OR url:1193958590689796104 OR url:1193906225366405120 This is a better question for https://twittercommunity.com/c/premium instead of github issues

Thanks a lot @igorbrigadir

you'd search for quotes of multiple ones with OR

Yes, I had though of that already.
Then just taking care to stay below the max length of the query, and run it in chunked batches until this workaround has collected all tweet_ids of all quoted retweets.
And THEN check for retweets of THOSE tweet_ids, because that is what I am really interested in.
I don't quite understand the problem why I have to come up with such complicated (and expensive, as I learn now) workaround. Why not just give us an appropriate endpoint?
Is there perhaps a political reason that I do not understand, to just not to provide one of these endpoints:

quoted_retweets_of_tweet(tweet_id) or
quoted_retweets_of_all_tweets_of_user(user_id) or even
retweets_of_quoted_retweets_of_user(user_id).

Especially the last one would save a LOT of queries, coding time, and money.
Can you help me to understand WHAT exactly is the problem here?  The twitter API is super amazing, and fun to work with - but this lack of functionality is almost a "bug-like flaw". Perhaps it's intended? But then ... why?

This would be the perfect place for these ideas: https://twitterdevfeedback.uservoice.com/forums/921790-twitter-developer-labs

This would be the perfect place for these ideas: ... twitterdevfeedback.uservoice ...

VERY good idea, thanks for pointing that out to me.
It's there now: https://twitterdevfeedback.uservoice.com/forums/921790-twitter-developer-labs/suggestions/38617114-add-endpoint-to-get-retweet-with-comment-aka-quot
Let's see what happens.


Stuck in Password Reset Loop

I'm trying to use instaloader -l USERNAME to save a session that I can then use with my own python script. But every single time I get checkpoint required and it requires me to make a new password.
I'm connecting from the same machine and same wifi and click "It was me" every time but it still warns that someone might have access to my password and forces the password change.
I'm tentative to try anymore times incase I get blocked completely.
Is there a step i'm missing?
All i've done so far is instaloader -l USERNAME and it worked the first time and then never again since.
Running this python script from the guide: https://instaloader.github.io/codesnippets.html#likes-of-a-profile-ghost-followers fails with the following error which is why I was trying to do the session again:
Traceback (most recent call last):
  File "app.py", line 9, in <module>
    L.load_session_from_file(USER)
  File "/Users/rob/Library/Python/3.8/lib/python/site-packages/instaloader/instaloader.py", line 618, in load_session_from_file
    with open(filename, 'rb') as sessionfile:
FileNotFoundError: [Errno 2] No such file or directory: '/var/folders/kg/ggvcmr3j6f743btcvrjl_0yr0000gn/t/.instaloader-myname/session-myname'

I am facing the same problem right now

Same here.. They force you to change it everytime

I'm having a similar issue, and no session is saved:

Fatal error: Login: Checkpoint required. Point your browser to https://www.instagram.com/challenge/action/[redacted] - follow the instructions, then retry.

I then attempt to access that page, which is unusable and redirects me to instagram.com.
I attempt to login via web and succeed but receive this, which then requires a password reset:

Tried the same python script on the troubleshooting page. Mine also isn't being saved nothing in "\AppData\Local\Instaloader".

Tried the same python script on the troubleshooting page. Mine also isn't being saved nothing in "\AppData\Local\Instaloader".

Did you try to run the script in cmd-window and admin rights? worked for me

Yeah just retried. It says it's being saved in that directory, but nothing is there. Ran with admin rights.

Tried the same python script on the troubleshooting page. Mine also isn't being saved nothing in "\AppData\Local\Instaloader".

Did you try to run the script in cmd-window and admin rights? worked for me

Yeah just retried. It says it's being saved in that directory, but nothing is there. Ran with admin rights.

you surley use firefox? the script only works with firefox

Tried the same python script on the troubleshooting page. Mine also isn't being saved nothing in "\AppData\Local\Instaloader".

Did you try to run the script in cmd-window and admin rights? worked for me

Yeah just retried. It says it's being saved in that directory, but nothing is there. Ran with admin rights.

you surley use firefox? the script only works with firefox

Yeah I used firefox. I think my python installation might be a mess. It was saving the session files in "C:\Users\USER\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\Local\Instaloader" I then created the directory "C:\Users\USER\AppData\Local\Instaloader" and moved the session file there. It worked. 👍

Same issue here. Cannot continue, telling Instagram that it's me trying to login instantly sends me to a password change screen regardless. Using Firefox to generate an entirely random and cryptographically safe password only lands me on the same page my next attempt...

Tried activating 2FA to work around this problem and get

Wow they've really botched their "suspicious login" handling system..

I'm having this same issue.  This script is essentially useless at this point.

Yeah I don't think it should be ignored or auto-closed by a bot. The script can't be used in this state.


Comparison with the other Jest extension for VS Code

Hi, I'm new to Jest in VS Code. How is this extension different from https://github.com/jest-community/vscode-jest ?
I see the README has "The Aim", which looks like tribute to the other extension, so it would be good to explain how this one is different, so devs can make an informed choice between the two.
Maybe that will get it more popularity as well (only 51 repo stars vs. ~1900 for @jest-community's extension).

hey @dandv
my extension is about running or debugging a sepcific test, while vscode-jest is more like a integrated workflow. it runs your test-suite everytime you change it. (e.g. its not possible to run a specific test)
i will add this to readme.
about popularity, vscode-jest is a more mature extension then this one.
It would be better to compare installs from marketplace not stars from github. because i think most people are rather installing the extensions then starring the project on github. 70k vs 400k
also i'm contributingto the jest compiler of jest-community.

improved the Readme with your feedback:
https://github.com/firsttris/vscode-jest-runner/commit/472e86f31d8df2d401fc04c3166dc7c3fd6db441


Video/audio guidance

Add any relevant info from Andrew's blog post https://docs.google.com/document/d/1_m4e_TISTBNrMlSjDeHe10B6GyvVxD33N_QxcEgPKUE/edit?ts=597a9987

Unable to find anything not already dealt with.

JF agreed okay to close


Upgrade pion/ice to v2.0.0-rc.9

This adds support for enabling ICE TCP by providing ice.TCPMux to settingEngine. The global state in pion/ice was removed and users can now specify their own net.Listener when creating a ice.TCPMux. A convenience function NewICETCPMux was added that returns a new instance of ice.TCPMuxDefault.
See https://github.com/pion/ice/pull/254 for more details.

Thanks both!


Merge pull request #1 from madcowswe/master

Merge new updates from Original master 20190813

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


Setting default openmp settings for MKL kernels

Requesting feedback on ways to set default openmp parameters
Currently, we recommend users set these through environment variables but are looking at ways to set reasonable values automatically from within tensorflow. A few questions that I would appreciate your feedback on -

Is it ok to use 'setenv' to set values for KMP_BLOCKTIME and OMP_PROC_BIND? There are no openmp standard APIs to programmatically set them.
For 'setenv' to correctly set Openmp settings, the code has to execute before the openmp library is loaded i.e before any call to openmp in the program. Since MKL optimizations are the only users of openmp, we have ensured that this is the case for now. Is there a better place for this code?
We would like to avoid placing computations on hyperthreads that compete for resources on the same CPU physical core. Looking for suggestions on getting the number of hyperthreads per core in a portable manner. https://www.open-mpi.org/projects/hwloc/ looks like a good option. Are you OK with bringing it into tensorflow?
Is it ok to ignore the intra_op config parameter while setting number of openmp threads? Ideally, we would like to use that parameter to guide MKL kernel parallelism as well but there seem to be cases (e.g., tf_cnn_benchmarks) where intra_op is set to a very low number by default.

@jbobba I don't see any precedence for using setenv in TensorFlow, but I think what you are doing is reasonable. @martinwicke any thoughts?

There is warning here about using setenv: https://github.com/tensorflow/tensorflow/blob/70da85b727c960f62af141770827367f9c5c0117/tensorflow/core/platform/posix/subprocess.cc#L59

@jbobba The warning you found is not necessarily a blocker, IMHO.

setenv: If you are always going to set the same values (KMP_BLOCKTIME=1 and OMP_PROC_BIND=true) and nobody else is using the variables, I don't think race conditions matter.

@penpornk addressed your PR comments. please take a look.

Something like hwloc would probably be useful.  So far we've been adding a bit of device topology data in an ad hoc fashion, mostly addressing accelerators.  Tensorflow does not do a very good job of managing thread/core affinity, nor of reducing interference between threads in the application.    We've neglected to deal with this issue up to now because other problems have been more urgent and also the Google datacenter environment makes it difficult to optimize.   If you're serious about wanting to add hwloc I suppose we should initiate a broader discussion about costs/benefits.

setenv: If you are always going to set the same values (KMP_BLOCKTIME=1 and OMP_PROC_BIND=true) and nobody else is using the variables, I don't think race conditions matter.

Unfortunately this is not true. setenv() is inherently thread-hostile and can't really be fixed. The only safe way to do any changing of the environment is to make sure no other thread is live when you call setenv(), ideally by doing it so early that no other thread could even have been started.
(setenv() modifies the global char** environ, possibly reallocating it; getenv() iterates over environ, which is also a globally-visible symbol that anyone else can iterate over directly. POSIX doesn't specify any locking on setenv or getenv, and at least glibc has a lock around the former but not the latter, so concurrent calls to setenv() and either getenv() or direct iteration over environ will cause segfaults.)

@poxvoculi @rmlarsen created a feature request issue for adding hwloc into TF.

@penpornk @rmlarsen addressed feedback.

penporn, i believe i have addressed all your comments. please let me know if i've missed any.

A quick note on the test failures. They seem to be unrelated to this PR. #19364 and a few other PRs fail these tests.

@jbobba Thanks! I believe the failing tests are unrelated. Merging.

@jbobba this PR appears to have broken the Windows build, as commented above. Would you mind taking a look?

Will do. @goydex @ganeshn85 can you share more info on the failure and your config. since the windows CI build passed on the PR, i'm wondering whats different in your setup.

Does the CI test build with CUDA/NV GPU support enabled?

i doubt but @gunan  would know best.

@jbobba thanks. As far as config, I'm building using the CMake build on Windows with CUDA/NVIDIA GPU enabled.
CMake command (obviously adjust with your personalized environment settings)
cmake .. -A x64 -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015" ^
-DSWIG_EXECUTABLE=Drive:/Path/to/swigwin-3.0.12/swig.exe ^
-DPYTHON_EXECUTABLE=Drive:/Path/to/anaconda3/python.exe ^
-DPYTHON_LIBRARIES=Drive:/Path/to/anaconda3/libs/python36.lib ^
-Dtensorflow_ENABLE_GPU=ON ^
-DCUDNN_HOME="Drive:/Path/to/cudnn-9.0-windows10-x64-v7.1/cuda" ^
-Dtensorflow_ENABLE_MKL_SUPPORT=ON ^
-DMKL_HOME="C:/Program Files (x86)/IntelSWTools/compilers_and_libraries" ^
-Dtensorflow_WIN_CPU_SIMD_OPTIONS=/arch:AVX2 ^
-Dtensorflow_BUILD_PYTHON_TESTS=OFF ^
-Dtensorflow_BUILD_CC_TESTS=OFF ^
-Dtensorflow_TF_NIGHTLY=OFF

Can then open Tensorflow.sln or build the example with
MSBuild /p:Configuration=Release tf_tutorials_example_trainer.vcxproj
Release\tf_tutorials_example_trainer.exe

Depending on your environment, you might need to run this script first
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"

We have separate builds with and without CUDA.
On its presubmits, this PR seems to have passed the non-CUDA build.
But it looks like also our CUDA builds were passing sometime yesterday, with this PR.


Feature/poetry

Resolves #156

Adds pyproject.toml with poetry config.
Adds poetry.lock — all dependencies are here.
Updates requirements.txt and dev.requirements.txt — exported from poetry, so no conflicting package versions are installed.
Updates contributing.md with info about poetry.
Changes psycopg2 to psycopg2-binary to avoid building psycopg2.

Whoops, did not run the tests — my bad. There seems to be some issues with the resolved pydantic version. Working on it.

Hi @dclimber, thanks for this! This is a solid improvement. My main concern here is dropping support for python 3.6. As fastapi supports python 3.6 so should this library.
The one caveat here is that the tortoise-orm CRUDRouter is not available to those using python 3.6.
Curious on your thoughts. Thanks again for thsi!

@awtkns phew everything works finally.

@dclimber I think the github workflows may need to be changed so that they support poetry

@awtkns hmm yeah it seems. I have python 3.8 on my system, so things work smoothly, but other versions need testing.
I'll look into either workflow improvement with poetry or fixing things, so existing workflows pass.

@awtkns pipelines finally pass! https://github.com/dclimber/fastapi-crudrouter/pull/3

Thanks for the great work @dclimber. I've seen that you have been active on some other issues. Let me know if there is any way I can support 🚀


model resources cannot be downloaded

It seems that model files on rostlab.org cannot be accessed recently by all links below:
https://rostlab.org/~deepppi/seqvec.zip
https://rostlab.org/~deepppi/seqvec_checkpoint.tar.gz
http://rostlab.org/~deepppi/embedding_repo/embedding_models/seqvec/options.json
http://rostlab.org/~deepppi/embedding_repo/embedding_models/seqvec/weights.hdf5
Thus, both automatic and manual downloads are ineffective. Could you fix it or provide another available download links? : )

sorry for the delayed response; will try to look into this but the source of the problem is the ongoing problem with our internal FTP server. I am trying to recover the files but can you in the meantime maybe try this approach for installing SeqVec? : https://github.com/Rostlab/SeqVec/issues/26#issuecomment-2267991933

Thank you for your concern about this issue and thank you for maintaining this project. I have no problem on installing SeqVec python package, but when using SeqVec to get embeddings, it will download pre-trained SeqVec model files on rostlab.org server (the code is below).
Luckily, I found these files from my co-worker. But I still suggest storing files as backups on other free and stable cloud drives, such as Google Drive.
def get_elmo_model(model_dir: Path, cpu: bool) -> ElmoEmbedder:
    weights_path = model_dir / "weights.hdf5"
    options_path = model_dir / "options.json"

    # if no pre-trained model is available, yet --> download it
    if not (weights_path.exists() and options_path.exists()):
        logger.info(
            "No existing model found. Start downloading pre-trained SeqVec (~360MB)..."
        )

        Path.mkdir(model_dir, exist_ok=True)
        repo_link = "http://rostlab.org/~deepppi/embedding_repo/embedding_models/seqvec"
        options_link = repo_link + "/options.json"
        weights_link = repo_link + "/weights.hdf5"
        urllib.request.urlretrieve(options_link, str(options_path))
        urllib.request.urlretrieve(weights_link, str(weights_path))

Oh well, I am so sorry, I misread your issue.
We keep experiencing issues with our FTP server and the problem is so bad that I can not even access those weights at the moment by myself ...
Lesson learned: always put those things on Zenodo or sth alike.
In case you feel like sharing the weights, I can upload them somewhere else. Otherwise, I do so once our server is back up again.

I uploaded those weights onto a temporary file sharing platform. They will be removed after 7 days.
The url is here, https://filebin.net/l553d2tiek3r8wzq
You can check these files MD5 values.

file name
MD5

SeqVec.zip
f9664ab720a7d7cd5ea48a7d8b0574e2

options.json
05637bed5b38e68ee17e107648a5f597

weights.hdf5
5f9d3f5fcac5e6bfadc88aebf147ac02

@fuyw-aisw, I uploaded them again, will be kept for 7 days.
https://filebin.net/dsofhelf2o1a2fyp

I apologize for my delayed response. The files are sourced from @Jmpax404, and you can download them at the following link: https://filebin.net/ja9f1z6xbza53482. I hope you find this helpful!

@sugarlib I apologize for my delayed response. The files are sourced from @Jmpax404, and you can download them at the following link: https://filebin.net/ja9f1z6xbza53482. I hope you find this helpful!

I would like to express my sincere gratitude for sharing the files. The files are sourced from @Jmpax404 and can be downloaded from the following links:
https://drive.google.com/file/d/1MxcjvsbyMUTxBs688revSUAVGD-jhd2N/view?usp=sharing
https://pan.baidu.com/s/1Ol17nWNbigNnNGA87ZA1BQ?pwd=8888 (Password: 8888)


plugins.cloudfoundry.org shouldn't be available via plain http

As I understand the plugin install process (and I'm pretty new to it), the fact that plugins.cloudfoundry.org is available via plain HTTP (and that the CLI defaults to the non-HTTPS version) introduces a vulnerability that an attacker can cause the cli to install a malicious binary when a user attempts to install a plugin.
Assuming the above is true, in order to protect users, the repo shouldn't be available via plain HTTP when run on the internet (having it as an option for intranet deployments may be reasonable).

Thanks for paying attention about the security concerns of plugins repo. We are already redirect all http traffic to https and have updated most of the links on our side of things to use the https.
We also added validations in our repo-index.yml to require all download links to be done over SSL, otherwise our tests will fail, preventing people from adding non-secure download links.

@davidillsley and apologies for the late feedback.
We acted on your issue report immediately as you may have noticed, but failed to update this issue. (We get so few issue reports on this repo I haven't been in the habit of regularly revisiting it).
If you find any other security issues, do please contact us directly first or follow the following process to give us a chance to evaluate and address it before you share it with the rest of the world?
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Reporting-Security-Vulnerabilities
Cheers,
Dies Koper
CF CLI PM

Will do. I did look for something like that, but couldn't find it. Would be good if there was a link from cloudfoundry.org somewhere, so that a google for 'site:cloudfoundry.org security' did the right thing.


Clearing Up Usage File

Current state
Usage files (--usage-file) generated by running --sync-usage-file have bunch of comments that by some teams may be seen as messy. Removing these comments is not respected and running --sync-usage-file reintroduces them again.
Modifying some comments is respected and the change is kept. However new comments added by a programmer are deleted when running --sync-usage-file.
Some teams may want to write helpful comments for the rest of the team why some usage param was chosen how it was chosen. E.g.
  azurerm_monitor_action_group.default:
    # 1 notification per every day per every environment
    monthly_notifications: 90

The current setup doesn't support that.
Possible options for improvement
Not having "unnecessary comments"
I would argue that absolute majority of comments currently generated are not really useful as they just rephrase what is already visible and understandable from the name of the parameter. E.g.
azurerm_storage_account.application_storage:
  data_at_rest_storage_gb: 0.0 # Total size of Data at Rest in GB (File storage).
  early_deletion_gb: 0.0 # Total size of Early deletion data in GB.
  snapshots_storage_gb: 0.0 # Total size of Snapshots in GB (File storage).
  metadata_at_rest_storage_gb: 0.0 # Total size of Metadata in GB (File storage).
  storage_gb: 0.0 # Total size of storage in GB.
  ...

I think that having such comments lowers visiblity of useful comments and is actually against clean code standards.
Respecting newly added comments
Examples of comments being currently deleted:
version: 0.1
resource_type_default_usage:
  # We set storage account usage globally as it's really cheap and we don't mind slight differences
  azurerm_storage_account:
    ...

version: 0.1
resource_type_default_usage:
  azurerm_storage_account: # We set storage account usage globally as it's really cheap and we don't mind slight differences
    ...

I'd be great if adding such comments would be respected and they wouldn't be deleted.
Any of the features above can be enabled only by using a special flag, however I'd personally consider them to be good practise enough to be enabled by default.

@dulakm thank you for the awesome level of details. As you say, I think this is a good default behavior.


add memory filesystem for making tests faster, more hermetic, and more robust

Currently real files are used for file i/o during tests. An alternative I've used in the past is to have an in-memory representation of a file-system: https://github.com/apache/incubator-pagespeed-mod/blob/master/pagespeed/kernel/base/mem_file_system.h
This has these advantages:

completely hermetic, with a clean slate between tests
very fast (no I/O), speeding up the running of massive numbers of tests
you can inject notifiers etc, so you can for example get a callback or condvar wakeup or similar when a file is written

Envoy already has a filesystem abstraction (yay!) and a way to squirrel that into code that needs to read/write files (Api::Api) just no in-memory impl for it.
I think this would be a good intern project. The example I gave above would not exactly meet Envoy's needs but it could be a reference point.

@alyssawilk FYI

cc @junr03. This would help a ton with Envoy Mobile as we would be able to run more existing tests. I think there is an open issue on this in that repo.

This would be awesome! I have https://github.com/lyft/envoy-mobile/issues/124

@jmarantz I am interested in taking on this! It seems that the task is to author an in-memory implementation for the Envoy::Filesystem::File interface :slightly_smiling_face:
I am wondering if you could point me to one of these unit tests, that currently uses real files for File I/O and could potentially benefit from this in-memory implementation of the interface. So that I could use it as a reference to come up with the implementation.
Thanks so much!

Thanks for being up for tackling this!
It came up in the context of waitForAccessLog, which (without simtime) has to poll disk to see when a log entry has been added.  If we had memfiles, the test memfile could explicitly notify condition variables when a file was tweaked, so we'd have far less looping and sleeping.   I think if we had it we'd also swap all of the writeStringToFileForTest and friends over, so that for example all of the integration tests could load from memory rather than writing out and reading in.  It'll be a really nice speed improvement, especially on mobile!

Was this ever completed?

Ehhh please remove me from the assignment. I never got a chance to look
into it 😅
On Sat, Mar 20, 2021 at 6:09 PM Demitri Swan @.***>
wrote:

Was this ever completed?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/issues/11121#issuecomment-803494227,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC4LZF4SV3A7RPY2GQDMZM3TEVBMFANCNFSM4M4PAM6Q
.

I'd be happy to give this a shot if no one else is interested.

@alyssawilk 's #15521 partially addresses this, though I don't think it tackles a file-system watcher or access log watcher yet. I'll let her comment on how we should take that forward.


Docs: i18n and localization with Zod

How do you do internationalization for the error messages?
Let's say you have a schema:
const schema = z.object({
  name: z
    .string()
    .min(3, 'A name is required and needs to be at least 3 characters long.'),
});

The leading library for i18n for Remix is currently remix-i18next. It requires the use of a t function, which is available through the useTranslation hook.
However, that t value is in a component. The schema needs to be defined outside of the component, so it can be used in the action function. How would you solve this?

We don't use remix-i18next or react-i18next and TBH I wouldn't use it unless I had a really good reason.
Translating strings requires only a pure function:
declare function t(i: string): string

It is not something that should depend on a component, there'll be plenty of strings coming from the server that should not depend on being in a hook... flash messages, for instance, well need to be set on the server and they'll need translation.
What you can do is using the i18next library though. Or any other library / custom function that conforms (i: string): string IMHO

What I'm really looking after is:
const schema = z.object({
  name: z.string().min(3, t('forms.name')),
});

My workaround ended up being:
const schema = z.object({
  name: z.string().min(3, 'user-profile:name-required-and-constraints'),
});

where the component then grabs the value like this:
const Error = ({ children, ...props }: JSX.IntrinsicElements['div']) => {
  const { t } = useTranslation();

  return (
    <p className="mt-2 text-sm text-red-600" {...props}>
      {typeof children === 'string' ? t(children, children) : children}
    </p>
  );
};

I'm glad you were able to solve it somehow.. I'm not familiar with those libraries.
Looking forward to having top level await ASAP in Node =)

hey, I've used this:
labels={Object.fromEntries(
Object.keys(schema.shape).map((key) => [key, t(key)])
)}
to localize the labels in case its helpful to others or worth documenting (I believe i18n is worth documenting!)
localizing errors is still on my todo list


Error while bringing up project: address already in use

Hey there! I am having an issue while setting up the project with the default database as either MongoDB is installed or isn't. I just want to make sure I have the error understanding correctly or if there is another fix before I do anything that may or may not mess up something on my system.
Here are the error logs:
make: [Makefile:16: build] Error 1 (ignored)
docker-compose -f ./docker-compose.yml run --service-ports --rm --name ots-share-run-app --entrypoint "npm run start" ots-share-run
Starting ots-share-mongo-local ...
Starting ots-share-mongo-local ... error

ERROR: for ots-share-mongo-local  Cannot start service ots-share-mongo-local: driver failed programming external connectivity on endpoint ots-share-mongo-local (a52a7fa2ec0c1ca125cd030da00b47f8ec502990e88413f3bd32e1005e77e124): Error starting userland proxy: listen tcp4 <IP_ADDRESS>:27017: bind: address already in use

ERROR: for ots-share-mongo-local  Cannot start service ots-share-mongo-local: driver failed programming external connectivity on endpoint ots-share-mongo-local (a52a7fa2ec0c1ca125cd030da00b47f8ec502990e88413f3bd32e1005e77e124): Error starting userland proxy: listen tcp4 <IP_ADDRESS>:27017: bind: address already in use
ERROR: Encountered errors while bringing up the project.
make: *** [Makefile:45: execute] Error 1

Thank you in advance.

@TwoBrake
Sorry for the late reply. I'll look into this and provide a fix ASAP.

@TwoBrake ,
I think it causes by this line.
https://github.com/rpgeeganage/ots-share-app/blob/main/docker-compose.yml#L56
In that I expose the mongo port to the host machine.
Can u comment it out and retry.

Do you want me to just comment out line 56? Also, I am running from the source, not with docker.

And try
make clean.
It will close the running docker containers.
Then try commenting.
Because that line expose 27017 port to the host. So if another instance is using it, docker will fail.
My apologies for mess of a docker files, compose files and make file.
I'm planning to clean them up soon


Day Picker directive not get value

If you don't set [(ngModel)] for Input directive , the Input will not get value as you click in date in calender
you can see the bug here :
https://plnkr.co/edit/L98tnVPWDXkBBRQGd5X4

Hi
It is right just in directive mode because input is not a part of it
so we need ngmodel to bind them together.


[bug]: File Not Found

Is there an existing issue for this?

[X] I have searched the existing issues

OS
Windows
GPU
cuda
VRAM
12gb
What happened?
Upgraded to 2.3.2, when selecting option 2, start the browser based UI I get the following error and I am unable to start InvokeAI:
FileNotFoundError: [WinError 3] The system cannot find the path specified:
'C:\\Tools\\InvokeAI\\.venv\\lib\\site-packages\\invokeai\\configs\\stable-diffusion'

Screenshots show traceback.
Screenshots

Additional context
I tried option 7 to fix a broken install, then a fresh install, which gave the same error.
Contact Details
<EMAIL_ADDRESS>

Have same error to on MacOS Ventura

Same issue here on Win11

Same issue here on Win11, but creating the foder and adding models.yaml and INITIAL_MODELS seems to fix this

This fix also worked on Mac.
Now to find out why I can't even generate with defaults after upgrading...

Mine is showing a path of C:\\Tools\\InvokeAI\\.venv\\lib\\site-packages\\invokeai\\configs\\stable-diffusion
EDIT: I see you copied them from C:\\Tools\\InvokeAI\\.venv\\lib\\site-packages\\invokeai\\configs ?

That's right. I copied from there

Same issue here on Win11, but creating the foder and adding models.yaml and INITIAL_MODELS seems to fix this

This fix also worked on Mac. Now to find out why I can't even generate with defaults after upgrading...

I don't have any issue to generate on Win11, so it could be another issue

Sorry this happened to you all. Could you describe the exact series of steps that led to this issue? Did you:

Use the installer to install 2.3.2 on a fresh system?
Use the "update" option in invoke.sh ?
Something else?

Thanks

I've reproduced the problem and will issue a fix ASAP.

@ebr Could you have a look at this? It seems that pyproject.toml is not installing the invokeai/configs/stable-diffusion directory when doing a network install, and yet it works fine from the wheel or a local pip install.
I started a bug branch fix referenced above, but it isn't right.

Sorry this happened to you all. Could you describe the exact series of steps that led to this issue? Did you:

Use the installer to install 2.3.2 on a fresh system?
Use the "update" option in invoke.sh ?
Something else?

Thanks

Hello!, thanks for your help. I updated using "update" option in invoke.sh


Reimplemented parse_anything.py to handle SBOMs with incorrect file extensions.

I tried parsing the SBOMs in the SPDX DocFest 20220127 and more than two thirds of the documents could not be parsed due to their file extensions. This was because most files had the extension .spdx and the parse_anything function assumed that every .spdx file should be parsed as a .tag file. However, there were many .spdx files that were not tag files and an error was thrown before they were parsed. Furthermore, there were examples of files with incorrect file extensions which prevented them from being parsed at all. I discussed with @licquia during the summer and he suggested that I try all the parsers for each file until the correct parser matches the type of the file. Below is piece of code where most .spdx documents fail on.

The main branch has been replaced with the refactored version of the tools-python. The version this PR refers to can be found in the version/v0.7 branch. Please reopen this PR against that branch while addressing the requested changes from here.


Enable SSL for Azure extension #1269

PR for https://github.com/apache/camel-quarkus/issues/1269. Replaces https://github.com/apache/camel-quarkus/pull/1272.

Shall I send a PR to quarkus in parallel to add Camel Azure to the list here?

Shall I send a PR to quarkus in parallel to add Camel Azure to the list here?

@ppalaga WDYT? There's actually a few other camel extensions that enable SSL support. Not sure if we should document that over on the Quarkus side or whether it'd be better to do it exclusively in our own documentation (probably the better option IMO).

Shall I send a PR to quarkus in parallel to add Camel Azure to the list here?

@ppalaga WDYT? There's actually a few other camel extensions that enable SSL support. Not sure if we should document that over on the Quarkus side or whether it'd be better to do it exclusively in our own documentation (probably the better option IMO).

Yeah, I think syncing to Quarkus docs is not sustainable. The question is how detailed we should document it on our side. I have created https://github.com/apache/camel-quarkus/issues/1300 Let's discuss there so that we do not block this PR.

Thanks all!


⚠ Mobitopup has degraded performance

In ae53e5a, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 9275 ms

Resolved: Mobitopup performance has improved in 2efe29b.


chore: bump to controller runtime 0.14.1

Signed-off-by: Sertac Ozercan<EMAIL_ADDRESS>What this PR does / why we need it:
Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #
Special notes for your reviewer:

Codecov Report

Merging #558 (93f0a90) into main (d113baf) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 93f0a90 differs from pull request most recent head 820f3b0. Consider uploading reports for the commit 820f3b0 to get more accurate results

@@           Coverage Diff           @@
##             main     #558   +/-   ##
=======================================
  Coverage   14.81%   14.81%
=======================================
  Files          13       13
  Lines        1512     1512
=======================================
  Hits          224      224
  Misses       1260     1260
  Partials       28       28

Flag
Coverage Δ

unittests
14.81% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


add cmake_cuda

Codecov Report

Merging #7 (61ff6ed) into master (edd18f2) will decrease coverage by 2.05%.
The diff coverage is 6.89%.

@@            Coverage Diff             @@
##           master       #7      +/-   ##
==========================================
- Coverage   47.41%   45.35%   -2.06%
==========================================
  Files           6        6
  Lines         542      571      +29
==========================================
+ Hits          257      259       +2
- Misses        285      312      +27

Impacted Files
Coverage Δ

niftypet/ninst/cudasetup.py
39.13% <6.89%> (-8.58%)
:arrow_down:

Continue to review full report at Codecov.

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

/tag v0.5.0 commit 481d43f

/tag v0.5.0 2ae08d7

/tag v0.5.0 234bfbe

/tag v0.5.0 234bfbe

/tag v0.5.0 234bfbe


Update tapir-akka-http-server, ... to 1.0.2

Updates

com.softwaremill.sttp.tapir:tapir-akka-http-server
com.softwaremill.sttp.tapir:tapir-asyncapi-docs
com.softwaremill.sttp.tapir:tapir-core
com.softwaremill.sttp.tapir:tapir-json-circe
com.softwaremill.sttp.tapir:tapir-openapi-docs
com.softwaremill.sttp.tapir:tapir-swagger-ui-bundle

from 0.20.2 to 1.0.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.tapir" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.softwaremill.sttp.tapir" }
}]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #172.


feat(console) resources UI

This introduces another view that shows all the current resources.

Signed-off-by: Zahari Dichev<EMAIL_ADDRESS>

@zaharidichev thanks so much for working on this! this is a rather large change --- in particular, it looks like there was some refactoring to set up for actually adding the new code, by renaming the Tasks type and tasks module to State --- which I think was a good decision. However, it makes the diff a bit harder to review, since all code in that module now appears to have been added in this branch. It would be much easier to review that branch if just the new code for actually implementing the resources UI was part of the diff.
Would you be willing to extract the module and type renaming changes to a separate branch, and rebase this branch on top of that branch? That way, this branch can contain only the diff for actually adding the resources UI, which should make the code much easier to review. We could land the renaming change very easily, and then this could be rebased back onto main. Thanks!

If you like, I'd be happy to make that change myself.

Would you be willing to extract the module and type renaming changes to a separate branch, and rebase this branch on top of that branch? That way, this branch can contain only the diff for actually adding the resources UI, which should make the code much easier to review. We could land the renaming change very easily, and then this could be rebased back onto main. Thanks!

@hawkw That sounds like a good idea. Will do that. And thanks a lot for looking at this. I know its a pretty large diff

:tada:


Userspace Panic After Few Resprings

After just a few resprings, my userspace panics. This has been a reoccurring issue for me.

I’ve tried increasing my Jetsam multiplier.
I’ve tried resetting my entire JB
I assume this issue is caused either by a tweak I’ve continued to use after the reset, or this is an issue with Dopamine.
I’ve attached the error image, but I have no idea what the “Preferences app” is otherwise, I would also attach the logs from found there.

this is most likely a hardware issue.
preferences app = settings app

It seems like battery is missing (TG0V sensor and some more)

It seems like battery is missing (TG0V sensor and some more)

Yo what the heck lol. My dad did say he was having battery issues on this phone a couple years back tho I’ve never experienced those issues. Might I add, the 0.5 camera’s Gladis also totally cracked / not there.

It seems like battery is missing (TG0V sensor and some more)

Any way I could verify if I do have a missing sensor?

In panic logs there is string: missing sensors:...

I have "kinda" this issue on iph 7. It does not charging over 5% and reboots every 3 minutes. It is better to bring it to service centre.


Add acceptable failure rate option to prevent constant execution failure

From @andrew041 on July 17, 2018 20:26
Currently, whenever there is a failure in any test, the execution will fail. When conducting UI testing, it is common to have some level of failure that is considered acceptable.
It would be great if an optional flag could be added to set an acceptable failure rate so that if the percentage of scenarios that failed was higher, the build/execution would be marked as a failure, but if it was higher, than it would be marked as passed.
I believe this change would need to be made in the "GaugeExecutionMojo.java" file around line 118.
Copied from original issue: getgauge/gauge-maven-plugin#33

This isn't something that would be difficult to implement,  but I would say that this could mask potential issue(s).
Some initial thoughts:

what is the right percentage (could be configurable, but that would be like code coverage and I don't think we would like gauge to be like that)
what if the same scenario keeps failing?
how does one determine that scenario A is a must-pass (crucial flow) whereas scenario B is tolerable?

I mentioned this in another comment. If I am testing an app, the principle I'd look at is:

if I am a user of the app being tested, would I be ok to retry X times for the feature to work? Most likely not. If that is true for an actual user, I think the same (if not stricter norms) should be expected from the test as well.

Thoughts?

Those are some good points. I think this change would help give a better indicator if there is a critical/system wide issue vs a small portion of the tests failing. The results would always need to be checked to verify any failures, but at least a build would be able to complete and/or Jenkins wouldn't be constantly failing (as we all know how inconsistent Selenium/Appium tests can be) when running a larger test suite.
I think it should be left to the user to determine the percentage when executing via command line. As long as it is labeled clearly, I don't think people would see it as a code coverage number.
If a scenario keeps failing, I think it would be fine. Maybe at some point there could be a 'test health' report that could be generated to more easily identify frequently failing tests. (And honestly, I think a test that has passed forever and suddenly fails is more concerning than a test that has been failing forever.)
I don't think Gauge should get into marking tests as more important. That could be taken care of by running tests without the suggested percentage passed flag and run their smoke test scenarios.

From Gitter chat at https://gitter.im/getgauge/chat?at=5b5846c95301255724c3debe

My opinion on this is that the tests need to be able to tell you with certainty if the feature works (or not). Masking failures does not solve anything. If I were you, I'd look at fixing the application (and/or tests). Because if your tests can break the feature, it may also be broken for your real users. If fixing is not feasible, quarantine the tests (ex. filter using a tag), run only the tests that will give you guaranteed results, then perhaps manually verify that the feature is OK.

From Gitter chat at https://gitter.im/getgauge/chat?at=5b58a6a9c0fa8016e7381480

There definitely is a point to saying that all the tests should pass, but I think that way of thought is really only applicable to unit tests. In all the teams I have worked with, there has been an acceptable level of UI and API test failures and QA always reviews a full report before saying a build is acceptable. For DevOps people, I can imagine it would get really annoying seeing a build constantly fail and needing to always look at the run to see if it was just a test that failed, or if there is a system issue. Even if it isn’t ideal, many organizations check the reports regardless and it would be helpful for the devops team to have the feature. Another reason for adding that feature is that it is common to continue running bugged tests for teams using agile and/or continuous integration as an issue can be found in the morning and in the afternoon it may be fixed (plus managers like to see increasing percentages of passing tests and it helps give an idea of how healthy an app is and when a release can happen).
As for quarantining tests, in my opinion, that is a very bad practice as then valid tests are not being run all the time. Plus, the whole point of autmation is to reduce the human interaction with the application and if tests are quarantined, then they would have to be run separately by a person, meaning an app can’t be released automatically.
I have seen some companies with custom dashboards to track all of their tests, keep a history on how they perform, and where they go to see if a build is ready for release. They want a jenkins job to only fail when there is some type of server error or a sudden drop in the pass rate for their tests so a devops person can be notified and investigate immediately.

The common theme maybe allowing the user to handle the result of the run. However implementing something like an "acceptable failure rate" is tough.
How about adding something like
$ gauge run specs --report-only

To generate a report (without failures). A tester can parse the report(html, xml, json etc) and decide what to do.

We treat the gauge results as "raw data".  We want ALL possible data to be collected and available. Then we can process/analyze the results as you see fit.
For example, we have one project where we run 2000+ spec files nightly (multiply that by a number of different browsers/OS versions). After each execution, we parse the xml report file and save the results into a DB.  We then have reports auto-generated from the DB results emailed to the appropriate teams for further analysis.  We generally don't look at whether the build failed or not unless the DB is missing results from the previous night.
I don't mean to sound harsh, but it appears that you want the Gauge team to do some of the "post-processing of data" for you.

Closing in favor of https://github.com/getgauge/gauge/issues/1126


Question about new transform feedback support: Metro LL still gets "Rasterized stream not supported"..

Hi,
with a quick test on 0.9.0+ new NV drivers I see Unity Adam demo is rendering correctly finally!!
and Metro LL launches now without:
d3d11.fakeStreamOutSupport = True
but in MetroLL_d3d11.log
errors before were:
err:   D3D11: CreateGeometryShaderWithStreamOutput:
  Transform feedback not supoorted by device

now are:

err:   D3D11: CreateGeometryShaderWithStreamOutput: Rasterized stream not supported

so question "Rasterized stream not supported" is because VK ext. limitations or DXVK limitation?
thanks..

Are you using patched Wine? Wine upstream didn't catch up to it yet.

Simultaneous stream output and rasterization is currently not supported in DXVK. The Vulkan extension allows it, but it's somewhat painful to implement, and I wasn't aware of any game that needs it.
Given that both versions of Last Light have native Linux support I'm not sure if I really care though. Was this with the original version of the game or with the Redux version?

@shmerl using patched Wine..
@doitsujin original version.. not really a problem, as you say Redux versions have native Linux binaries..
any way good to know Vulkan ext. supports simultaneous stream output and rasterization anyway..
Closing..

Toukiden Kiwami show this:
err:   D3D11: CreateGeometryShaderWithStreamOutput: Rasterized stream not supported

Nioh shows this as well.

They might show it, but I haven't seen a single game which actually requires the rasterization so far (it's not very useful anyway since it only supports points, not triangles). Apps can specify a rasterized stream but then choose not bind any render targets.

Ah, thank you for clarifying. That's rather odd behavior from the games' side, then. I'll keep my hopes up for Nioh one day :)

afaik Nioh is being held back by wine issues.

I had the same error while playing Dead or Alive 6.
https://github.com/ValveSoftware/Proton/issues/2420
It seems that is this error that prevent me to play, other people can (except the story mode).
err:   D3D11: CreateGeometryShaderWithStreamOutput: Rasterized stream not supported

It seems that is this error that prevent me to play, other people can (except the story mode).

No, it isn't.

Why can't I play then?

Don't know?

@doitsujin now that nioh semi-works I noticed weird issues with transparency effects and was wondering if it's related to stream rasterization? Mostly happens when things fade in/out, for example for the guardian spirit in the main menu when you press "Continue". I tried to capture it but it's not extremely obvious:

Basically transparent objects have a strange dot pattern on them. I don't have access to windows so I scanned through youtube videos and didn't notice it in this video:

Sorry if it's not the right place to post, please let me know if it will be better to track this as a separate issue.

No it's not related. If you think this is a bug, please record an apitrace and then open a new issue.

@ap4y The effect is also there on Windows. There is a similar one when e.g. a door or other solid object is between your character and the camera, the closer it is the more it dissolves into dots.

@psy-q ok, thanks for confirming that. it's not a big deal, just looks weird.


Bring Back accounts!!!

I miss acounts! PLease bring them back!

But why?

Why not start a patereon and try to raise some money?


ACKS Sheet Encumberence

More Encumbrance Adjustments.
GP for Treasure now calculates stone weights
Item Counts operate as multipliers.

I've just been corrected on the gp weight mechanic (there's some conflicting rules on that) so I'll be removing it and resubmitting later when I get back to my computer.


Configure basic auth security for Data Flow client configuration

The composed task runner's taskOperations bean is initialized with the secured (with basic auth) REST template, the Data Flow client (as the CTR itself is a Data Flow client) also needs to be configured the same.
Child of #41

Applied the changes into 1.3.x as 7fa550224bcb4742c4d113b5f8b22dbb0f471f86


Running dragon lo results in a crash

Traceback (most recent call last):   File "<frozen runpy>", line 198, in _run_module_as_main   File "<frozen runpy>", line 88, in _run_code   File "/home/rugmj/.local/lib/python3.11/site-packages/dragon/lo.py", line 6, in <module>     from dragon.util import dprintline, OutputColors, OutputWeight ImportError: cannot import name 'dprintline' from 'dragon.util' (/home/rugmj/.local/lib/python3.11/site-packages/dragon/util.py)
After looking at the source code it seems the imports dont exist in the utils module at all not really sure whats meant to be happening here

seems the shared package has the correct util, changing dragon.util to shared.util would resolve this unless theres something im missing

Thanks for catching this. Will fix in an upcoming release.
If you'd like to fix it locally, you can make the edits necessary to this repo and run the dev install script.


Create surefire-report.html

This outputs the standalone raw surefire-report.html without any CSS or the like.
We use this task to include a (basic & unstyled) test report as a part of github-release

could be replaced with https://github.com/Pivotal-Field-Engineering/pipeline-tasks/pull/15

We'll replace this specific task by leveraging #15


documentation menu links are broken for v0.17 and v0.15 scaladoc

Documentation dropdown links to:

http://http4s.org/v0.17/
http://http4s.org/v0.17/api/org/http4s/
http://http4s.org/v0.15/api/org/http4s/
and all 3 are broken.  The v0.15 scaladoc is currently at:
http://http4s.org/v0.15/api/#org.http4s.package

Even the best baseball player goes 0 for 3 some days.

Closed via #1062 and #1063.


Elaborated installation instruction

Hi,
I had the relatively tough time trying to get SCIP.jl working. This attempt is to make installing SCIP.jl easier for people who don't understand how to set ENV variables and including missing steps during installation. Also I got SCIP.jl working without copying the patched file, I think this step is no longer required.

Thanks for the effort, I'll have a look later.

The failing test is most likely not caused by your changes, I think it has to do with changes in the JuMP tests that we use.
I'd be surprised if the patch for SCIP is no longer needed, since they didn't do a release for it. I guess it's not strictly necessary for SCIP.jl to work at all, but it was necessary for something in particular, maybe linking to a libscipopt.so that expects IPOPT.

@leethargo this attempt is inspired from instructions given in Travis Build file. Tried to state the steps in ordered list with explanation of what each step does.


[CHAD-9167] Re-port multi-metering switch to parent/child

Looking at the DTH, the way the number of child endpoints is calculated is:
		if (isZoozZenStripV2()) {
			addChildSwitches(5)
		} else if (isZoozDoublePlug()) {
			addChildSwitches(2)
		} else {
			addChildSwitches(cmd.endPoints)
		}
	}

I'd prefer to keep that implementation rather than adding additional hard-coding.

@greens Do You men to avoid using multi_metering_switch_configurations.lua ?
This file keeps not only the number of child switches but also device profile names and this sub-driver calls:

MULTI_METERING_SWITCH_CONFIGURATION_MAP.get_child_amount(device)
MULTI_METERING_SWITCH_CONFIGURATION_MAP.get_child_switch_device_profile(device)

@KKlimczukS I mean to use that field for the devices that have a defined value in the DTH, but use the number of endpoints for the devices where the DTH does not. So if it's not a ZoozZenStripV2 or a ZoozDoublePlug, then use the number of endpoints to determine the number of child devices, like the DTH does.

@KKlimczukS I mean to use that field for the devices that have a defined value in the DTH, but use the number of endpoints for the devices where the DTH does not. So if it's not a ZoozZenStripV2 or a ZoozDoublePlug, then use the number of endpoints to determine the number of child devices, like the DTH does.

@greens
and to use this table ? device.zwave_endpoints[]

@KKlimczukS right, the number of entries should be the same


[Do not merge] Test batch zkapp txns

Includes the following PRs on top of develop (https://github.com/MinaProtocol/mina/commit/237c610ae775c58ed6f5c0a2e36f7b4719b8624d)

https://github.com/MinaProtocol/mina/pull/11289
https://github.com/MinaProtocol/mina/pull/11320
https://github.com/MinaProtocol/mina/pull/11403

Checklist:

[ ] Modified the current draft of release notes with details on what is completed or incomplete within this project
[ ] Document code purpose, how to use it

Mention expected invariants, implicit constraints

[ ] Tests were added for the new behavior

Document test purpose, significance of failures
Test names should reflect their purpose

[ ] All tests pass (CI will check this if you didn't)
[ ] Serialized types are in stable-versioned modules
[ ] Does this close issues? List them

Closes #0000

Old, stale testing branch. Closing.


2FA PASSWORD_HASH_INVALID

So i followed issue #33 and #73 , but it keeps telling me
Error: 400 PASSWORD_HASH_INVALID CODE#400 PASSWORD_HASH_INVALID
Anyone able to get this through? @leonerd

ok, i figured it out myself, I have to convert to buffer and then concat. Let me try to do a pull request


feat: Make use of new "Async" RPC

Q
A

Bugfix?
❌

Breaks BC?
❌

New feature?
✔ TODO: please update "Other Features" section in CHANGELOG.md file

Issues
https://github.com/roadrunner-php/goridge/pull/22

Docs PR
spiral/docs#...

This is a follow-up PR for https://github.com/roadrunner-php/goridge/pull/22 implementing the new "async" RPC calls in the Metrics class.
~It may be an option to instead modify the MetricsFactory to return an AsyncMetrics class instead if it detects an async RPC interface, or something like that. Please lmk if you'd like me to change that. Once the implementation is good to go I'll add tests for it as well.~
EDIT: I've switched to the MetricsFactory because implementing it into our service was kinda weird otherwise. I've also added a few tests and fixed the Psalm complaint.
For further info please read the linked PR in the goridge repo.
Same PR in the KV repo: https://github.com/roadrunner-php/kv/pull/36

Summary by CodeRabbit

New Features

Introduced AbstractMetrics class for structured metrics functionality.
Added MetricsIgnoreResponse class to handle metrics operations while ignoring RPC responses.
Enhanced MetricsOptions for improved configurability during metric collection.

Improvements

Updated Metrics class to streamline method calls and enhance error handling.
Modified MetricsFactory to support flexible metrics creation with new options.

Tests

Expanded test coverage for MetricsFactory and MetricsIgnoreResponse classes to ensure robust functionality.

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (8878661) 80.15% compared to head (53bb962) 80.00%.

:exclamation: Current head 53bb962 differs from pull request most recent head c64ee74. Consider uploading reports for the commit c64ee74 to get more accurate results

Files
Patch %
Lines

src/Metrics.php
90.90%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##                3.x      #13      +/-   ##
============================================
- Coverage     80.15%   80.00%   -0.16%
- Complexity       52       54       +2
============================================
  Files             6        6
  Lines           126      130       +4
============================================
+ Hits            101      104       +3
- Misses           25       26       +1

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

@L3tum Could you please fix the test here as well?

Hey @rustatian , so sorry for the late update, I didn't expect there to be an issue here and even forgot it wasn't merged yet^^
@msmakouz I've updated it so far, however the static analysis complains about a missing type for a constant. Class constant types have only been supported since PHP8.3, while this library (rightfully) doesn't require it and thus doesn't support it. I don't want to mess with these settings without your confirmation, so please let me know how you'd like to resolve that.

@L3tum Thanks for the work you've done!


more stricter required labels checking,

name and component needs to have explicit value,
version, release may be using env variable

OSBS-7697

Signed-off-by: Robert Cerven<EMAIL_ADDRESS>

Looks good!
Could we rephrase the commit message to something like "Enforce explicit labels" ?

commit message changed

rn updated: - Enforce explicit required labels, name and component needs to have explicit value, version, release may be using env variable


cmd/go: build -v outputs nothing while changing the resulting binary

What version of Go are you using (go version)?
go version go1.10 linux/amd64
Does this issue reproduce with the latest release?
Yes (1.10 is latest, to my knowledge)
What operating system and processor architecture are you using (go env)?
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOARCH="amd64"
GOOS="linux"
What did you do?

Instead, go build -v outputs nothing, but the resulting binary did actually change.
root@3f5a7744d3ef:/home/test# go version
go version go1.10 linux/amd64
root@3f5a7744d3ef:/home/test# ./test
test
root@3f5a7744d3ef:/home/test# rm ./test.go
root@3f5a7744d3ef:/home/test# go build -v
root@3f5a7744d3ef:/home/test# ./test
root@3f5a7744d3ef:/home/test#

I created this test case after go get -v showed this behavior for me, so I expect build, install and get to all be affected by this.

/cc @ianlancetaylor

@rsc

The -v option is documented as printing the package when it is compiled.  In your case, the package is cached.  It is not being recompiled.  The go tool updates the modification time to partially hide the detail that the package was cached.  But  since the package was not recompiled, it is not printed by -v.


Release v3.2.0

Summary:
changelog and version bump
Submitter checklist:

[ ] CHANGELOG updated or N/A
[ ] Documentation updated or N/A

Merger checklist:

[ ] ALL tests have passed
[ ] Code Review is done
[ ] Dependencies satisfied

Dependencies:

[ ]

seems I sent


The tree example for the grid is confusing due to use of Req

The example shown in the documentation for tree-grid is confusing because it uses the same word multiple times in different contexts: request, Requests and 'Request' for data source, Column title and column value respectively. It also uses the key word "Kind" as a variable name, which is technically allowed because it uses upper case, but is not great for human comprehension when learning a new language.
requests
| summarize Requests = count() by ParentId = appName, Id = name
| extend Kind = 'Request', Name = strcat('🌐 ', Id)
| union (requests
| summarize Requests = count() by Id = appName
| extend Kind = 'Request', ParentId = '', Name = strcat('📱 ', Id))
| project Name, Kind, Requests, Id, ParentId
| order by Requests desc

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

ID: 9f185ac2-8d79-1964-154f-d4f79993f070
Version Independent ID: e2acea61-6979-d701-9ca1-a6e3cc289c2d
Content: Azure Monitor workbook visualizations - Azure Monitor
Content Source: articles/azure-monitor/platform/workbooks-visualizations.md
Service: azure-monitor
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@centiqbob Thanks for the feedback!
Assigning @mrbullwinkle for visibility, review and document enhancement consideration as appropriate.

Sorry for the delay and thank you for the feedback, I created an internal [work item](https://dev.azure.com/mseng/677da0fb-b067-4f77-b89b-f32c12bb8617/_workitems/edit/1831616 to review the query and it is currently on our backlog. We'll close out this issue for now, but I will @mention you when the update is complete.
#please-close


[BUG]: API Change info should include pybind11::buffer -> nanobind::tensor information

Problem description
The README goes into some detail on various API changes, but the (large) apparent change from buffer -> tensor (not just in name but also in usage) appears to be undocumented. Some detail on this would be greatly appreciated.
Reproducible example code
No response

Decided this made more sense under "Discussions", moved it there.


upgrade to Ruby 3.2.2

requires Rails 7 #1584

coverage: 94.53%. remained the same
when pulling 50a5fd8e80a7be6b89e3f72ee5815bdb20eb30b8 on nimmo-ruby-3-2-2
into 6901a60129588bd19aa4a5ba49346cc2489798c4 on nimmo-rails-7.0.7.


cant run the app on windows

hey,
im trying to run this app on windows 7 64bit, i have go installed all good, i even tried building this app and go did the job
but i cant seem to run the app, how do i do that? just double click local-ehentai.exe? it just disappear right away
just to make things clear, i didnt download the json file. cant i run the app without it? i cant download 600mb since i have limited internet and my collection is not that big so i can manage it adding tags manually
sorry if it's a newibe question

You can't run the app without the json file. But you can create the json file yourself if you want.
See: API - EHWiki
Example:
[
  {
    "gid":1494936,
    "token":"3e2f098c3f",
    "archiver_key":"439552--d8ebe550a5c638b0ae8bd67191662176a60dc7b3",
    "title":"[Pixiv] Moyahara (13501)",
    "title_jpn":"[Pixiv] もやはら (13501)",
    "category":"Image Set",
    "thumb":"https://ehgt.org/bf/9d/bf9d9f564de0d7dbf34c46ea690b179327ee9031-1575365-1027-1426-jpg_l.jpg",
    "uploader":"saltcutlet",
    "posted":"1570354806",
    "filecount":"44",
    "filesize":63194890,
    "expunged":false,
    "rating":"4.59",
    "torrentcount":"1",
    "torrents":[
      {
        "hash":"48b5a24c2cac748787cd0d9b702730bd93f510de",
        "added":"1567932647",
        "name":"[Pixiv] Moyahara (13501).zip",
        "tsize":"19233",
        "fsize":"61935273"
      }
    ],
    "tags":[
      "artist:moyamoya",
      "female:garter belt",
      "female:kimono",
      "female:lingerie",
      "female:small breasts",
      "female:stockings"
    ]
  }
]


⚠ Bofrost.be has degraded performance

In 58db31f, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1796 ms

Resolved: Bofrost.be performance has improved in 9584a58 after 8 minutes.


"502 Bad Gateway" after running meltano-upgrade playbook

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/1836
Originally created by @DouweM on 2020-03-02 22:02:28

Slack thread for context: https://gitlab.slack.com/archives/C7HD6Q0RE/p1583176259040300?thread_ts=1583175563.038600&cid=C7HD6Q0RE
Running systemctl restart meltano across all *.meltanodata.com nodes using ansible '*.meltanodata.com' -a "systemctl restart meltano" fixed it, but it's unclear at this point why the meltano service got into a bad state, and why a restart fixed it.

View 14 previous comments from the original issue on GitLab


Add base64 to gemspec

When using this Gem in Ruby 3.3.4 i'm getting this warning:
/builds/gitlab-community/meta/vendor/ruby/3.3.0/gems/gitlab-5.0.0/lib/gitlab/cli_helpers.rb:5: warning: base64 was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add base64 to your Gemfile or gemspec. Also contact author of gitlab-5.0.0 to add base64 into its gemspec.

Hopefully this should fix it.

@NARKOZ would you mind taking a look at this PR please?

Thank you ❤


[Feature Request] Processing raw emerald ore (similar to how diamond ore works)

Currently, we can send raw diamond ore through the enrichment chamber to get 2x returns. Emerald ore, however, can't be processed this way, and there's no way to get the emeralds out without taking the blocks, placing them in the world, and manually breaking them with a pickaxe. This can be extremely tedious when you have 4 full stacks of emerald ore from a trip with the digital miner (2 stacks of nether emerald ore through the smelter returns 4 stacks of plain emerald ore).

if it wont smelt then send to block breaker.

I was able to find a temporary solution of using the Sag Mill from EnderIO (it's the ONLY thing that will convert emerald ore to emerald.)

There is an API/IMC message to do this, you could see if BoP(?) would want to add it, or if Mine/CraftTweaker supports it.

One slight problem. It's a vanilla ore.

Somehow I got confused with Ruby or something! whoops lol

Done!


Fix outbound links in presence of adblocker

If Google Analytics callback hasn't occurred one second after clicking a link, go ahead and run the callback ourselves because an adblocker has thwarted it. This techniques comes from the Google Analytics section about the hitCallback.
The particular timeout could perhaps be shortened because it feels like a long time for the link to activate. The danger with shortening it is interrupting analytics if GA is laggy.
Fixes #63

@begriffs This looks correct from a Javascript side of things.

Think I should cut the timeout down to half a second?

@begriffs Good question - can you test this locally with adblocker enabled and see what makes sense?
Given that GA uses 1 second in their example, I'd be inclined to keep that, unless we see it being noticeably slow.


The large osm files to geojson?

Hello!
is that possible to convert a large osm file i.e netherland(900mb) to geojson through osm-and-geojson? I'm using a windows7 machine with i3 cpu\8mem\not-ssd

Probably not. I recommend minjur for this usecase: https://github.com/mapbox/minjur


Serialize gates

What is the expected behavior?
Experiments with custom gate instances in the options cannot be serialized. For example,
    def test_x_roundtrip_serializable(self):
        """Test round trip JSON serialization"""
        exp = FineXAmplitude(0)
        exp.set_experiment_options(gate=Gate("my_gate", 1, params=[]))
        self.assertRoundTripSerializable(exp, self.json_equiv)

and
    def test_x_roundtrip_serializable(self):
        """Test round trip JSON serialization"""
        exp = FineXAmplitude(0)
        exp.set_experiment_options(gate=RZXGate(0.56))
        self.assertRoundTripSerializable(exp, self.json_equiv)

do not work. Note that SXGate(), for example, does serialize properly.

Closed by #684


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v3.3 to before v5.4.125",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7c18d2205ea76eef9674e59e1ecae4f332a53e9e",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c97cdb70b72d0eb81ad43c8722a78522c4a9b5be"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "7c18d2205ea76eef9674e59e1ecae4f332a53e9e",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "c97cdb70b72d0eb81ad43c8722a78522c4a9b5be",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "net: caif: add proper error handling\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.4.125 by commit c97cdb70b72d0eb81ad43c8722a78522c4a9b5be, it was introduced in version v3.3 by commit 7c18d2205ea76eef9674e59e1ecae4f332a53e9e. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1000748