PropTypes.array and PropTypes.arrayOf handling with null

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
When filtering an item that does not exist in the list (options), it is returning null and the .filter method is broken

Expected Behavior 🤔
The ideal would be to check if there are options and if it is an array if it is not going to return an empty array.
Steps to Reproduce 🕹
if you want to reproduce it directly, just go to https://carhoo.com.br/comprar and look for an item when filling out automatic or simple reproduction ... See https://codesandbox.io/s/tender-breeze-gj3zr
Your Environment 🌎

Tech
Version

Material-UI
v4.9.2

React
v16.10.2

Browser
Chrome

Please provide a full reproduction test case. This would help a lot 👷 .
A live example would be perfect. This codesandbox.io template may be a good starting point. Thank you!

@oliviertassinari Thanks for the feedback, I'll try to create this reproduction in the codeandbox, however, I provide the link to my production application where the error is occurring.

The problem is when the list return is null in my suggestion and the agent just does this little check, maybe I can handle the side of my application however, it would be nice if we could avoid this behavior.
See https://codesandbox.io/s/tender-breeze-gj3zr

@alexandesigner Thanks. I could reproduce the same issue with react-select: https://codesandbox.io/s/react-codesandboxer-example-y2rwr
However, I'm surprised they are no prop-types warnings. null is compatible with PropTypes.array and PropTypes.arrayOf. I see two good options:

We patch prop-types to report a warning.
We accept null. I have looked at the codebase, we have very few cases like this one.
Autocomplete.options, TreeView.expanded, TablePagination.rowsPerPageOptions,

In any case, the tradeoff is close to #17480. I think that I would be in favor of not crashing here (.2) nor in #17480. A crash force the developer to solve the issue immediately, while he might prefer to work solve another issue first, and later come back to the warning.

prop-types handling of is required is not ideal but the way the eco-system is set up. With TypeScript you'd already wouldn't pass the type checker. I'd stick with the current behavior to not cause too much confusion. Leveraging default assignments with undefined is a lot easier than having custom default handlers for nullish values.

@eps1lon So we give the same answer than #17480 (we close + waiting for upvotes)?

Yeah. Since this is the lab I would honestly reconsider making it optional. It doesn't make sense to not set it anyway. If the list is empty (because you're loading) your can default to an empty array.
Makes the type-checker, prop-types and the implementation happy.
Unless there is an actual use case for <Autocomplete /> that never receives options.

@alexandesigner What about we make the options required?

I have updated the pull request to make the options required, I think that @eps1lon had an excellent point, people won't go far without the options.

@oliviertassinari I believe sounds good. I fully agree with the @eps1lon point.
Thanks! Not only for your attention but for the care with this fantastic stack.

Breaking changes as minor version? This was unexpected for me :)

The Autocomplete is in an alpha stage, see https://material-ui.com/components/about-the-lab/.


TOWER OF HANOI USING STACK in C++ (GSSOC'21)

🚀 Feature
Have you read the Contributing Guidelines on Pull Requests?
Yes !
AIM :: TOWER OF HANOI USING STACK in C++
Motivation
As i didn't found TOWER OF HANOI USING STACK in C++, So i am willing to contribute it...
Pitch
Hi I am GSSoC'21 participant,
"I am looking to work on the TOWER OF HANOI USING STACK in C++"
I will write the clean and optimized code , by keeping best case time and space complexity in mind and
with  brief commenting and algorithm.
I will use C++ language.

/assign


Convert Token to an interface

There is no reason why Token shouldn't be an interface now that interfaces are supported in jsii

@eladb Ha! ;)

This was done, I feel :)


LayerNorm Gain and Bias Multipliers

Hi,
I'm wondering how to correctly implement the LayerNorm gain and bias multipliers.
In section F.3 it is detailed that a hyperparameter search on LayerNorm gain multiplier and bias multiplier is done in addition to the normal output multiplier and attention logits multiplier. However, I cannot find any example of this being done in the examples/Transformers/models.py module. I also checked the mutransformers repo and checked the BERT example and could also find no evidence of how to correctly implement a layer norm gain multiplier and bias multiplier. Sorry if I somehow managed to miss this.
In the 3rd paragraph in Appendix A you note that any parameter tensor in a neural network can be multiplied by a constant c where c is defined as a parameter multiplier. Therefore, I think it is reasonable to deduce that the correct implementation of a LayerNorm gain multiplier is simply:
layernorm_gain_multiplier * torch.nn.LayerNorm(x)
Is this correct?
For the bias multiplier it is not so clear to me how this is correctly implemented. Of course one can just say it would be:
torch.nn.Linear(x, bias=False) + bias * bias_multiplier
but if this is the correct implementation it's not clear to me why:

Why is the bias multiplier only being applied to the bias and not the entire linear transformation?
Should this same bias multiplier be applied to all linear transformations? From Table 8 it seems to suggest there's nothing stopping you from doing this.
Should this bias multiplier be applied to output weights that have an output multiplier being applied to it already? Should the bias multiplier in this case effectively be bias_multiplier * output_multiplier ?
Should this bias multiplier be applied to other terms that have a bias-like term? For example, batch and layer normalization.

Thank you for this wonderful paper and excellent repo detailing the correct implementation and cross-checking via coord checking!
-AJ

Hi AJ,
Thanks for your interest!
If you look at Lemma J.1 of the paper, you’ll see that: for every parameter tensor, out of the 3 hyperparameters [learning rate, initialization, and multiplier], there is a 1-dimensional redundancy. So the choice we made in these repos in general is to absorb the multipliers into the pair [learning rate, initialization]. This is because, from a user interface perspective, practitioners tend to be more comfortable with modifying learning rate and initialization of a fixed model than to modify the model itself by inserting multipliers.
Now, in these examples, we did not explicitly implement separate learning rate and initialization hyperparameters for gain and bias parameters either (other than a more global learning rate and initialization). This is just because we want the code to be as simple as possible as a readable example, as a way of illustrating the general principle at place.
In any case, it is easy to insert learning rate and initialization hyperparameters via the usual ways (parameter groups in optimizers and module.apply function for initialization (you can look at the muTransformer repo for examples of the latter)). If you aren’t familiar with these, feel free to follow up with questions.

Therefore, I think it is reasonable to deduce that the correct implementation of a LayerNorm gain multiplier is simply:
layernorm_gain_multiplier * torch.nn.LayerNorm(x)
Is this correct?

Because LayerNorm applies both gain and bias, this multiplier would simultaneously be applied to both gain and bias as well. In principle, you should have separate multipliers for gain and for bias,
torch.nn.LayerNorm(x, affine=False) * gain_mult * learnable_gain + bias_mult * learnable_bias
for the purpose of accurate hyperparameter transfer, but probably tying them together isn’t much worse.

Why is the bias multiplier only being applied to the bias and not the entire linear transformation?

You can have an additional weight multiplier:
torch.nn.Linear(x, bias=False) * weight_mult + bias * bias_mult

If you tie weight_mult and bias_mult together, you’ll have what you are suggesting.
One way to think about this and all of your related questions is as follows:
The true hyperparameter space here is the very high dimensional space containing [learning rate, initialization] (we can insert multipliers here as well, but like I said, it is redundant) for every parameter tensor (weights, biases, gains, etc). If you were to tune all these hyperparameters and obtain the optimal combination, then this combination is guaranteed to be stable in some sense as you vary width (in muP). However, in practice, we may not want to tune that many hyperparameters because of resource constraints. So we combine hyperparameters (by e.g., tying learning rate for many weights together) until we have only a small number to tune. This essentially means that we are now focusing on a low dimensional slice of the true hyperparameter space --- that we guess should contain all the really good hyperparameters. The choices of hyperparameters we tuned in our paper exemplify the “low dimensional slice” we chose. These choices are based on our empirical experience tuning hyperparameters, but over time people may find better choices.

Should this same bias multiplier be applied to all linear transformations? From Table 8 it seems to suggest there's nothing stopping you from doing this.

Following the explanation above, if you believe the optimal hyperparameter combination will have all the bias multipliers tied, then this is a reasonable guess. In general, from my experience, as a starting point, I would separate the hyperparameters of the hidden layers from those of the input and output layers.

Should this bias multiplier be applied to output weights that have an output multiplier being applied to it already? Should the bias multiplier in this case effectively be bias_multiplier * output_multiplier ?

As above, I would separate the output layer from other layers. You can implement it like you suggested.

Should this bias multiplier be applied to other terms that have a bias-like term? For example, batch and layer normalization.

You can. I don’t have a huge preference here. If you have more resources for tuning you can separate out the bias for BN and LN from the layer biases.

Seems like this is solved for now. Feel free to re-open if you have further problems.


[TRAC-891] Add cost and purchasing option to EC2 usage report

This update add the purchasing option and the cost on the endpoint /ec2
An update for the FrontEnd will follow this PR.
I will have to do an update on this PR to be in compliance with https://github.com/trackit/trackit-server/pull/97

Please rebase your PR to use the new account sharing feature


chore: Make header lookup in runtime expressions case-insensitive

Closes #605

Codecov Report

Merging #607 into master will decrease coverage by 0.17%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #607      +/-   ##
==========================================
- Coverage   99.75%   99.58%   -0.18%
==========================================
  Files          51       51
  Lines        3332     3334       +2
  Branches      574      575       +1
==========================================
- Hits         3324     3320       -4
- Misses          3        7       +4
- Partials        5        7       +2

Flag
Coverage Δ

#unittests
99.58% <100.00%> (-0.18%)
:arrow_down:

Impacted Files
Coverage Δ

...rc/schemathesis/specs/openapi/expressions/nodes.py
100.00% <100.00%> (ø)

src/schemathesis/_compat.py
50.00% <0.00%> (-50.00%)
:arrow_down:

src/schemathesis/extra/pytest_plugin.py
97.53% <0.00%> (-2.47%)
:arrow_down:

src/schemathesis/cli/cassettes.py
98.23% <0.00%> (-1.77%)
: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 f6eca48...a982015. Read the comment docs.


Paper List looks too long, maybe folding part of the paper list ?

Currently the paper list looks too long, maybe we can fold some related but not important paper to make the repo look cleaner?

good point, we shall design better ways to make the paper list look cleaner.

I suggest we just list a few important papers and make the rest folded in README.


glfwSetJoystickCallback doesn't work as intended

The function doesn't set the callback, instead, it just creates it.
To use it, you need to use
 glfwSetJoystickCallback((joy, id) -> { /* stuff here */ }).set();

But that is supposed to be how glfwCreateJoystickCallback works.
Actual code is :
public static GLFWJoystickCallback glfwSetJoystickCallback(GLFWJoystickCallbackI cbfun) {
        return GLFWJoystickCallback.create(nglfwSetJoystickCallback(MemoryUtil.memAddressSafe(cbfun)));
    }

Proposed fix:
public static void glfwSetJoystickCallback(GLFWJoystickCallbackI cbfun) {
        GLFWJoystickCallback.create(nglfwSetJoystickCallback(MemoryUtil.memAddressSafe(cbfun))).set();
    }

It also seems that the functional interface is wrong
@FunctionalInterface
public interface GLFWJoystickCallbackI extends V {
    String SIGNATURE = "(ii)v";

    default String getSignature() {
        return "(ii)v";
    }

    default void callback(long args) {
        this.invoke(DynCallback.dcbArgInt(args), DynCallback.dcbArgInt(args));
    }

    void invoke(int var1, int var2);
}

invoke should look like that:
void invoke(int id, FloatBuffer joy);

The glfwSetJoystickCallback function, like all GLFW callback functions, registers a new callback and at the same time returns the previously set callback. The GLFWJoystickCallback.create call creates a GLFWJoystickCallback instance from the native handle returned by glfwSetJoystickCallback, i.e. the previous callback (or null if there was none set).
The .set() method simply calls glfwSetJoystickCallback, it's a shortcut. So your suggestion would either throw an NPE on the first call or would recurse and fail with a stack overflow.


Develop merge optimized migration

Along comes some other changes to berkeley from the past week.

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me


Use new @inquirer/prompt package.

Description
Inquire underwent a rewrite from the ground up to reduce the package size and improve performance. The previous version of the package is still maintained but not actively developed. I've changed the build script to use the new package. I've also updated the dependencies.
Related Issue

Motivation and Context

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Improvement (non-breaking change which does not add functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA or I'm an Adobe employee.
[x] I have made any necessary test changes and all tests pass.
[x] I have run the Sandbox successfully.

@dompuiu Can you fix the conflicts and merge this?


Turn off Natricons by default

The current Natricon icons are disliked by just about everyone and makes the standard nano explorer look highly unprofessional. Please consider removing the feature, or making it an opt-in feature.
Update: Apparently not just about everyone. I only have public data available for assessment, reddit and discord. Apparently yekta's and bbedward's inboxes are filled with praise.

The claim that is included in your first sentence is factually false. The impression you have is potentially caused by same people responding multiple times to the same Reddit post, and down voting anyone with a positive comment. Goes without saying that a single post on Reddit doesn't represent everyone's opinion.
There are people that like it, and there are people that dislike it (based on the two Reddit posts, feedback we got from Reddit and the DMs we got). Proportion is far from being "just about everyone".
That being said, we left it off in our PR default. And communicated both the positive and the negative feedback to Meltingice. So, the decision to turn it on by default or not belongs to him.

Your rebuttal is factually false.
https://www.reddit.com/r/nanocurrency/comments/gvusgs/meet_natricon_a_friendly_familiar_face_for_your/
Dislike-comments and their upvotes:
dontlikecomputers 42 points
XRBeast 20 points
nano_trader 25 points
IzetBirdie 25 points
ls_kode 20 points
keeri_ 20 points
shanecorry 17 points
derpmanchu 17 points
jeykwon 17 points
Vermacian55 11 points
OddSavings2 10 points
leavingoldhabits 10 points
HarryHazel Rep: Finland.247node.com 9 points
goldenbzzz 8 point
bortkasta 8 points
13o7 8 points
Podcastsandpot 8 points
RickiDangerous 7 points (like the idea, not the style)
Foppo12 6 points (like the idea, not the style)
Very few outright likes.
I only picked the first comment by each users. Some of these users are long time nano fans and their opinion matters.

I'm very well aware of the comments (in that post and other parts of Reddit and Discord), I'm the creator of the post. If you read my reply above properly, maybe you can understand why your claim is false. Claiming something as "just about everyone" requires a bit more research than you did, collecting dislikes on that particular post doesn't justify your claim. Counting repeating upvotes doesn't mean much either because of the reasons I explained.
So, as I said multiple times before, we take everyone's suggestions into account. But seeing some people that dislike it trying to make similar claims is just not helping to anyone. There is no need to try to skew this one way, you can just give your feedback like everybody else, without making vast generalisations about everyone else's opinions. That doesn't make your suggestion any less reputable.

Count number of commenters then. Point stands.

Again, the problem is summing it up as "just about everybody" based on that Reddit post. Because you're basing this on a single post on Reddit, I'm guessing you didn't get messages or emails about the system like we did, didn't see the positive comments on Discord or on Reddit. Didn't have creators asking you how they can implement Natricon etc.
My claim is simple, your way of reducing everyone's opinion into something is simply wrong. That's it.
We made the PR with the Natricon turned off by default on Nanocrawler, so it is pretty easy to guess our stance on it.
And it's completely normal for everyone to give feedback and make suggestions like yourself. Problem I wanted to point here was the claim of "pretty much everyone", that's all.

Even if it's not just about everybody:
As people have said a few times, even if many people do like it, it's controversial and polarizing at best. That cannot possibly be in Nano's best interest. Something like abstract block icons would be boring but acceptable to everyone (except maybe the poor designer, you?)

You can try to attack me personally, or accept the fact that you made a false claim.
We take feedback(negative or positive) and act on it, would recommend you do the same.
Take care and have a nice day.

Not a false claim, I can count. Also not a personal attack, but truth hurts I guess. Have a nice day.

💯

@akutheman
Pointing to a single reddit thread is nothing more than a confirmation bias that backs your personal opinion. Maybe you could actually try gathering data next time so you can draw an educated conclusion. From our data, "everybody hates them" is simply not accurate - that was the point Yekta was making. Not as many people are happy with them as we would like and we're responding to that - but it's also far from "everybody hates them" and it seems the trend varies by people's background (non-crypto person, crypto investor,developer, artist, age group, etc.). It would be far more interesting and useful to gather data like this instead of making uneducated conclusions like "pretty much everybody hates them" and "Something like abstract block icons would be boring but acceptable to everyone"
Insulting one of the most talented contributors in the Nano ecosystem because you don't like something he made is an absolute disgrace. People like you are far more likely to be detrimental to Nano's future than some icons.

From our data, "everybody hates them" is simply not accurate

I can only comment on public information, and the community seem to dislike them pretty strongly. Happy to see other data.

 I'm not saying most people like them, because I can't draw that conclusion based on the data I have either.
I don't know why you're not able to grasp such a simple concept, but it's disgraceful that instead of recognizing your mistake you turn to petty insults.

Thanks for the insults. You're calling me dumb, disgraceful and insulting in one sentence when all I did was present the data I had.

I did not call you any of those things, except disgraceful, because in my opinion insulting yekta instead of correcting your mistake is exactly that. You're free to share your opinion, but saying "just about everybody" is a lie - and is the thing you were corrected on.
You can say "a lot of people don't seem to like them", or "a lot of people seem to be ok with abstract icons" - you're saying "everyone" in both cases which is misrepresenting the truth.

It's sad that you choose to conduct yourself like this, I don't have anything else to say to you. Maybe you can re-read what was said and come back with a cooler head in the future.

I think you need to re-read what was said with a cooler head.

"Update: Apparently not just about everyone. I only have public data available for assessment, reddit and discord. Apparently yekta's and bbedward's inboxes are filled with praise."
Not sure what you call people that misrepresent people's sentences intentionally and put words in their mouth to suit their own narrative. You seem to have some experience in this.
I've never said our inboxes are filled with praise. I said:
"I can show you positive feedback from big creators in Nano community as well, or other people from the community, but then again that is not really necessary because we're not trying to skew the situation in one way. Everyone can see for themselves without generalisations."
Not sure which part implies that our inboxes are "filled with praise". I simply said I can show positive feedback examples from big creators in Nano, and other people from the community.

I'm ready to see it, a the more information I have the better. I can only act on publicly available information.


MenuItem Wrapped in an array component doesn't provide onChange value to select

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

when the onChange callback is fired, the event.target signature should be:
{     name: string,     value: value of MenuItem }
Current Behavior 😯

event.target.value = undefined, but retains the name of the selected element
Steps to Reproduce 🕹

Link:https://codesandbox.io/s/o785w2pzw9
Context 🔦

Menuitem is wrapped in a different component that just maps over values and generates the element dynamically.

The options of Select that hold the values must be immediate children.
Rather than <Select><Options /></Select> you have to use <Select><OptionA /><OptionB /></Select> etc. You could just use the import from option.js as a function e.g. <Select>{Options()}</Select>.
We should probably add a warning of none of the children of Select have a value prop  and add to the docs that the options need to be immediate children.

Should we close a duplicate of #14943?

That one is about Select. This issue originates in SelectInput.


Complete Event?

hello,
is there animation complete event? or we have to use onUpdate  along with isPlaying?
thanks
Nehal

Of course, check out the tween options.

Probably that answered the question.


Debug why GalSim stars are predicted to be galaxies

On stripe 82, we misclassify about 20% of stars as galaxies but only about 5% of galaxies as stars. I suspect that's because we don't have priors on the galaxy shape parameters, so galaxies have more degrees of freedom to fit the data, and they aren't being penalized by prior distributions for having that freedom. We'll address this problem in #348.
What you're seeing may or may not be due to the same issue. For a sufficiently bright star, with normal star colors, your should find that it's a star with very high probability. If you that works, I'd say your code is fine and that we could close this issue and handle the underlying problem in #348.

I have not managed to make a case that gets classified as a star. The uploaded test cases include an 80 nMgy star. I tried making it 200 nMgy with no change. Here's the full vp:
32×2 DataFrames.DataFrame
│ Row │ id_name   │ vp          │
├─────┼───────────┼─────────────┤
│ 1   │ "u_1"     │ 18.0        │
│ 2   │ "u_2"     │ 18.0        │
│ 3   │ "e_dev"   │ 0.0100007   │
│ 4   │ "e_axis"  │ 0.989996    │
│ 5   │ "e_angle" │ 10.0        │
│ 6   │ "e_scale" │ 0.275842    │
│ 7   │ "r1_1"    │ 5.29207     │
│ 8   │ "r1_2"    │ 5.29829     │
│ 9   │ "r2_1"    │ 0.000100023 │
│ 10  │ "r2_2"    │ 0.0001      │
│ 11  │ "c1_1_1"  │ 1.60823     │
│ 12  │ "c1_2_1"  │ 0.717688    │
│ 13  │ "c1_3_1"  │ 0.300146    │
│ 14  │ "c1_4_1"  │ 0.16889     │
│ 15  │ "c1_1_2"  │ 1.60654     │
│ 16  │ "c1_2_2"  │ 0.717319    │
│ 17  │ "c1_3_2"  │ 0.300134    │
│ 18  │ "c1_4_2"  │ 0.168844    │
│ 19  │ "c2_1_1"  │ 0.000101229 │
│ 20  │ "c2_2_1"  │ 0.000100223 │
│ 21  │ "c2_3_1"  │ 0.000100087 │
│ 22  │ "c2_4_1"  │ 0.000100119 │
│ 23  │ "c2_1_2"  │ 0.000100021 │
│ 24  │ "c2_2_2"  │ 0.000100003 │
│ 25  │ "c2_3_2"  │ 0.000100001 │
│ 26  │ "c2_4_2"  │ 0.000100002 │
│ 27  │ "a_1_1"   │ 0.00500007  │
│ 28  │ "a_2_1"   │ 0.995       │
│ 29  │ "k_1_1"   │ 0.00500357  │
│ 30  │ "k_2_1"   │ 0.994996    │
│ 31  │ "k_1_2"   │ 0.00500611  │
│ 32  │ "k_2_2"   │ 0.994994    │

Here's the test case output:
11×4 DataFrames.DataFrame
│ Row │ label              │ field                        │ expected │ actual   │
├─────┼────────────────────┼──────────────────────────────┼──────────┼──────────┤
│ 1   │ "very bright star" │ "X center (world coords)"    │ 18.0     │ 18.0     │
│ 2   │ "very bright star" │ "Y center (world coords)"    │ 18.0     │ 18.0     │
│ 3   │ "very bright star" │ "Minor/major axis ratio"     │ NA       │ 0.989996 │
│ 4   │ "very bright star" │ "Angle (degrees)"            │ NA       │ 32.9578  │
│ 5   │ "very bright star" │ "Half-light radius (arcsec)" │ NA       │ 0.275842 │
│ 6   │ "very bright star" │ "Brightness (nMgy)"          │ 200.0    │ 198.754  │
│ 7   │ "very bright star" │ "Color band 1-2 ratio"       │ NA       │ 4.99397  │
│ 8   │ "very bright star" │ "Color band 2-3 ratio"       │ NA       │ 2.04969  │
│ 9   │ "very bright star" │ "Color band 3-4 ratio"       │ NA       │ 1.35006  │
│ 10  │ "very bright star" │ "Color band 4-5 ratio"       │ NA       │ 1.18399  │
│ 11  │ "very bright star" │ "Probability of galaxy"      │ 0        │ 0.995    │

I think the colors are typical for the (second component of the) star color prior but maybe I'm misinterpreting that. Is there a good example of an image that is actually inferred to be (most likely) a star in the test cases? I looked briefly but didn't find one.

That unit test is the place to star, the test_that_truth_is_most_likely()
one. Also test_optimization.jl has examples of correctly classified stars.
On Tue, Nov 1, 2016, 2:29 PM gostevehoward<EMAIL_ADDRESS>wrote:

I have not managed to make a case that gets classified as a star. The
uploaded test cases include an 80 nMgy star. I tried making it 200 nMgy
with no change. Here's the full vp:
32×2 DataFrames.DataFrame
│ Row │ id_name   │ vp          │
├─────┼───────────┼─────────────┤
│ 1   │ "u_1"     │ 18.0        │
│ 2   │ "u_2"     │ 18.0        │
│ 3   │ "e_dev"   │ 0.0100007   │
│ 4   │ "e_axis"  │ 0.989996    │
│ 5   │ "e_angle" │ 10.0        │
│ 6   │ "e_scale" │ 0.275842    │
│ 7   │ "r1_1"    │ 5.29207     │
│ 8   │ "r1_2"    │ 5.29829     │
│ 9   │ "r2_1"    │ 0.000100023 │
│ 10  │ "r2_2"    │ 0.0001      │
│ 11  │ "c1_1_1"  │ 1.60823     │
│ 12  │ "c1_2_1"  │ 0.717688    │
│ 13  │ "c1_3_1"  │ 0.300146    │
│ 14  │ "c1_4_1"  │ 0.16889     │
│ 15  │ "c1_1_2"  │ 1.60654     │
│ 16  │ "c1_2_2"  │ 0.717319    │
│ 17  │ "c1_3_2"  │ 0.300134    │
│ 18  │ "c1_4_2"  │ 0.168844    │
│ 19  │ "c2_1_1"  │ 0.000101229 │
│ 20  │ "c2_2_1"  │ 0.000100223 │
│ 21  │ "c2_3_1"  │ 0.000100087 │
│ 22  │ "c2_4_1"  │ 0.000100119 │
│ 23  │ "c2_1_2"  │ 0.000100021 │
│ 24  │ "c2_2_2"  │ 0.000100003 │
│ 25  │ "c2_3_2"  │ 0.000100001 │
│ 26  │ "c2_4_2"  │ 0.000100002 │
│ 27  │ "a_1_1"   │ 0.00500007  │
│ 28  │ "a_2_1"   │ 0.995       │
│ 29  │ "k_1_1"   │ 0.00500357  │
│ 30  │ "k_2_1"   │ 0.994996    │
│ 31  │ "k_1_2"   │ 0.00500611  │
│ 32  │ "k_2_2"   │ 0.994994    │
Here's the test case output:
11×4 DataFrames.DataFrame
│ Row │ label              │ field                        │ expected │ actual   │
├─────┼────────────────────┼──────────────────────────────┼──────────┼──────────┤
│ 1   │ "very bright star" │ "X center (world coords)"    │ 18.0     │ 18.0     │
│ 2   │ "very bright star" │ "Y center (world coords)"    │ 18.0     │ 18.0     │
│ 3   │ "very bright star" │ "Minor/major axis ratio"     │ NA       │ 0.989996 │
│ 4   │ "very bright star" │ "Angle (degrees)"            │ NA       │ 32.9578  │
│ 5   │ "very bright star" │ "Half-light radius (arcsec)" │ NA       │ 0.275842 │
│ 6   │ "very bright star" │ "Brightness (nMgy)"          │ 200.0    │ 198.754  │
│ 7   │ "very bright star" │ "Color band 1-2 ratio"       │ NA       │ 4.99397  │
│ 8   │ "very bright star" │ "Color band 2-3 ratio"       │ NA       │ 2.04969  │
│ 9   │ "very bright star" │ "Color band 3-4 ratio"       │ NA       │ 1.35006  │
│ 10  │ "very bright star" │ "Color band 4-5 ratio"       │ NA       │ 1.18399  │
│ 11  │ "very bright star" │ "Probability of galaxy"      │ 0        │ 0.995    │
I think the colors are typical for the (second component of the) star
color prior but maybe I'm misinterpreting that. Is there a good example of
an image that is actually inferred to be (most likely) a star in the test
cases? I looked briefly but didn't find one.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jeff-regier/Celeste.jl/issues/369#issuecomment-257703966,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIieCxxERjpD7-t9E-OfJnwZVlrhcrZDks5q568lgaJpZM4KhnDe
.

OK. I don't think test_that_*_is_most_likely is helpful here because it
just looks at the likelihood, it doesn't run inference, so the fact that
the image happens to fit the preset star parameters makes the star
likelihood higher, but that doesn't reflect what happens in inference. In
inference the color parameters for both star and galaxy get very well
fitted to the data. Like you said in the other thread, it seems like the KL
term should be penalizing the galaxy fit more; I guess it's not, but
test_that_*_is_most_likely doesn't help us with that.
I'll look at test_optimization.jl
On Tue, Nov 1, 2016 at 2:44 PM Jeffrey Regier<EMAIL_ADDRESS>wrote:

That unit test is the place to star, the
test_that_truth_is_most_likely()
one. Also test_optimization.jl has examples of correctly classified stars.
On Tue, Nov 1, 2016, 2:29 PM gostevehoward<EMAIL_ADDRESS>wrote:

I have not managed to make a case that gets classified as a star. The
uploaded test cases include an 80 nMgy star. I tried making it 200 nMgy
with no change. Here's the full vp:
32×2 DataFrames.DataFrame
│ Row │ id_name │ vp │
├─────┼───────────┼─────────────┤
│ 1 │ "u_1" │ 18.0 │
│ 2 │ "u_2" │ 18.0 │
│ 3 │ "e_dev" │ 0.0100007 │
│ 4 │ "e_axis" │ 0.989996 │
│ 5 │ "e_angle" │ 10.0 │
│ 6 │ "e_scale" │ 0.275842 │
│ 7 │ "r1_1" │ 5.29207 │
│ 8 │ "r1_2" │ 5.29829 │
│ 9 │ "r2_1" │ 0.000100023 │
│ 10 │ "r2_2" │ 0.0001 │
│ 11 │ "c1_1_1" │ 1.60823 │
│ 12 │ "c1_2_1" │ 0.717688 │
│ 13 │ "c1_3_1" │ 0.300146 │
│ 14 │ "c1_4_1" │ 0.16889 │
│ 15 │ "c1_1_2" │ 1.60654 │
│ 16 │ "c1_2_2" │ 0.717319 │
│ 17 │ "c1_3_2" │ 0.300134 │
│ 18 │ "c1_4_2" │ 0.168844 │
│ 19 │ "c2_1_1" │ 0.000101229 │
│ 20 │ "c2_2_1" │ 0.000100223 │
│ 21 │ "c2_3_1" │ 0.000100087 │
│ 22 │ "c2_4_1" │ 0.000100119 │
│ 23 │ "c2_1_2" │ 0.000100021 │
│ 24 │ "c2_2_2" │ 0.000100003 │
│ 25 │ "c2_3_2" │ 0.000100001 │
│ 26 │ "c2_4_2" │ 0.000100002 │
│ 27 │ "a_1_1" │ 0.00500007 │
│ 28 │ "a_2_1" │ 0.995 │
│ 29 │ "k_1_1" │ 0.00500357 │
│ 30 │ "k_2_1" │ 0.994996 │
│ 31 │ "k_1_2" │ 0.00500611 │
│ 32 │ "k_2_2" │ 0.994994 │
Here's the test case output:
11×4 DataFrames.DataFrame
│ Row │ label │ field │ expected │ actual │

├─────┼────────────────────┼──────────────────────────────┼──────────┼──────────┤

│ 1 │ "very bright star" │ "X center (world coords)" │ 18.0 │ 18.0 │
│ 2 │ "very bright star" │ "Y center (world coords)" │ 18.0 │ 18.0 │
│ 3 │ "very bright star" │ "Minor/major axis ratio" │ NA │ 0.989996 │
│ 4 │ "very bright star" │ "Angle (degrees)" │ NA │ 32.9578 │
│ 5 │ "very bright star" │ "Half-light radius (arcsec)" │ NA │ 0.275842
│
│ 6 │ "very bright star" │ "Brightness (nMgy)" │ 200.0 │ 198.754 │
│ 7 │ "very bright star" │ "Color band 1-2 ratio" │ NA │ 4.99397 │
│ 8 │ "very bright star" │ "Color band 2-3 ratio" │ NA │ 2.04969 │
│ 9 │ "very bright star" │ "Color band 3-4 ratio" │ NA │ 1.35006 │
│ 10 │ "very bright star" │ "Color band 4-5 ratio" │ NA │ 1.18399 │
│ 11 │ "very bright star" │ "Probability of galaxy" │ 0 │ 0.995 │
I think the colors are typical for the (second component of the) star
color prior but maybe I'm misinterpreting that. Is there a good example
of
an image that is actually inferred to be (most likely) a star in the
test
cases? I looked briefly but didn't find one.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/jeff-regier/Celeste.jl/issues/369#issuecomment-257703966>,

or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AIieCxxERjpD7-t9E-OfJnwZVlrhcrZDks5q568lgaJpZM4KhnDe>

.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/jeff-regier/Celeste.jl/issues/369#issuecomment-257708081,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABC_kMXKcBXECWKj35AYe0RQ6iBEK72vks5q57KcgaJpZM4KhnDe
.

Update: @rgiordan suggested I look at residual images for the star predictions. The star residuals were positive in the center and negative towards the edges, suggesting the Celeste PSF was too narrow. Hence the galaxy scale parameter could be used to make the galaxy fit the image better. Making the Celeste PSF slightly wider reduced the star residuals and caused Celeste to predict the star test cases as stars rather than galaxies, finally. Those pesky PSFs. I'll try to figure out exactly why they're not matching up the way I thought they should, tomorrow. Perhaps that will shed some light on the scale issue to. (FWIW my hack of just guessing a slightly larger PSF width did not fix the scale issue for galaxies.)

Interesting finding!

For the record, my best explanation for what's causing this is that the GalSim test images are using a very small PSF (sigma = 1.33 pixels), so there can be a substantial difference between (a) the density value at the center of this pixel (times the area of the pixel) and (b) the integral of the density over the pixel area. Jeff's feeling is that realistic PSFs will always be larger than one pixel by enough of a margin to make this issue safe to ignore.
Here's a bright star image from a GalSim test:

Here's the predicted image assuming the object is a star:

Here are the residuals:

The predicted image is too high in the center and too low towards the edges. This first made me think the Celeste PSF was small. But it's also consistent with the above point sample vs. integration issue. We can confirm this is actually happening. The star has 200,000 counts total flux and the PSF has sigma = 1 pixel. The middle pixel from the Celeste predicted image has ~31,600 counts, approximately equal to 1/2pi * 200,000 (Celeste estimates a brightness slightly lower than 200k counts to achieve best possible fit). The GalSim middle pixel has value ~29,300; the integral of the standard bivariate normal over [-.5,.5]^2 is ~.147 which is approx. 29,300 / 200,000.
I tried a little hack to test the idea. I changed eval_bvn_pdf!() to compute the pdf at the center (a) and the four corners (b, c, d, e), then return (2a + b + c + d + e) / 6 as the evaluated mass (in bvn_derivs.f_pre[1]; I didn't touch the derivatives). This is a sort of trapezoidal rule in 2D using triangles, I'm sure there's a nicer way but this was simple. This did cause the star residuals to get much smaller and caused Celeste to predict the stars as stars (and to predict brightness more accurately).
However, it should be noted that as I mentioned in the previous comment, just making the Celeste PSF slightly larger made it predict stars as stars too. So this fact alone doesn't confirm that we found the "real" problem.

Minor update: changing the PSF sigma from 1 to 3 pixels caused some, but not all, stars to be predicted as galaxies. Changing it to 4 pixels made it reliable.

Do you mean changing the PSF from 1 to 3 pixels caused some, but not all, stars to be predicted as stars? It gets better when you increase the PSF variance, right?

That is some really thorough analysis Steve, in your previous post. The explanation seems very plausible to me.

Sorry, yes, changing PSF sigma 1 to 3 pixels caused some but not all stars to be correctly predicted as stars. Setting PSF sigma = 4 pixels caused all stars to be correctly predicted as stars. Higher PSF sigma = more accurate results, presumably because the center point density more closely matches the integrated density over the pixel.


Report error for policy when ancestor status slice is full

Status on policies contains a slice of Ancestors, which has a max size of 16. If the slice is full, we consider the policy unimplementable but we do not signal this to the user in any way. We effectively ignore the policy.
The spec says

If this slice is full, implementations MUST NOT add further entries.
Instead they MUST consider the policy unimplementable and signal that
on any related resources such as the ancestor that would be referenced
here. For example, if this list was full on BackendTLSPolicy, no
additional Gateways would be able to reference the Service targeted by
the BackendTLSPolicy.

We need to figure out a way to signal this on the ancestor resource. One way to do this would be to add a condition to the ancestor. But this may overflow the ancestor's conditions.

See this thread for more info: https://github.com/nginxinc/nginx-gateway-fabric/pull/1940#discussion_r1591749902


Going to another page using the numbers or <  > symbols changes pages but does not return you to the top of the page.

Going to another page using the numbers or <  > symbols changes pages but does not return you to the top of the page.
Google Chrome:
Start on Page 1, scroll down to see all the ships. Click the number 2 or the > symbol and it goes to the next page, but the page displayed is at the bottom of the list of ships.
I would think this would return you to the top of the page, so you can continue scrolling down, then go to the next page.
Bug or Feature Request? I can move this if it's not a bug.

Yeah, this is more of a bug but I will fix this soontm


Finished telegram

I have finished the telegram in extreme folder.
In order to run the application
change directory to the project in telegram project
command:
cd /04_extreme/01_telegram_web_clone/frontend/telegram-clone
then run :
npm run install
then run :
npm run dev

Please login with your GitHub account here https://associazionetodo.unicam.it/ otherwise we cannot add the points to your account

Thank you so much
Il mer 25 ott 2023, 11:02 Lorenzo Lapucci @.***> ha
scritto:

Merged #122
https://github.com/hacktoberfest-unicam/awesome-hacktoberfest-beryllium-bear/pull/122
into hackathon.
—
Reply to this email directly, view it on GitHub
https://github.com/hacktoberfest-unicam/awesome-hacktoberfest-beryllium-bear/pull/122#event-10764390705,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATOMJ5OI6NNF45RS3TB5RG3YBDIS7AVCNFSM6AAAAAA6N6ESP6VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJQG43DIMZZGA3TANI
.
You are receiving this because you authored the thread.Message ID:
<hacktoberfest-unicam/awesome-hacktoberfest-beryllium-bear/pull/122/issue_event/10764390705
@github.com>


ci: Validate config-controller artifacts are generated

Similar to the ACS operator, the config controller has code generation tasks that need to be run and the results checked in when making certain changes.  This adds a CI validation job using the established pattern to ensure these code generation task results are checked in as needed.
I've initially pushed a change to this branch that will intentionally cause the CI job to fail.  I'll then push the results of the code generation tasks and expect CI to pass.  Then of course I'll remove the dummy changes altogether and expect CI to still pass.
One difference from the ACS operator CI check is that I added a make target to the parent makefile instead of calling the config-controller makefile directly.  This is because I have a follow-up PR queued up that will copy a generated artifact to the Central Helm chart (ROX-25493), and that command will go in the make target added in this PR.

Pasting test output here after the last commit:
Checking for diffs after making config-controller-gen...
diff --git a/config-controller/api/v1alpha1/zz_generated.deepcopy.go b/config-controller/api/v1alpha1/zz_generated.deepcopy.go
index 2f6d00c426..ca9eb44ba5 100644
--- a/config-controller/api/v1alpha1/zz_generated.deepcopy.go
+++ b/config-controller/api/v1alpha1/zz_generated.deepcopy.go
@@ -40,6 +40,21 @@ func (in *Deployment) DeepCopy() *Deployment {
 	return out
 }

+// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
+func (in *DummyStruct) DeepCopyInto(out *DummyStruct) {
+	*out = *in
+}
+
+// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new DummyStruct.
+func (in *DummyStruct) DeepCopy() *DummyStruct {
+	if in == nil {
+		return nil
+	}
+	out := new(DummyStruct)
+	in.DeepCopyInto(out)
+	return out
+}
+
 // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
 func (in *Exclusion) DeepCopyInto(out *Exclusion) {
 	*out = *in
@@ -286,6 +301,7 @@ func (in *SecurityPolicySpec) DeepCopyInto(out *SecurityPolicySpec) {
 			(*in)[i].DeepCopyInto(&(*out)[i])
 		}
 	}
+	out.DummyField = in.DummyField
 }

 // DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new SecurityPolicySpec.
diff --git a/config-controller/config/crd/bases/config.stackrox.io_securitypolicies.yaml b/config-controller/config/crd/bases/config.stackrox.io_securitypolicies.yaml
index c4ee7b032e..0dec8d6eb3 100644
--- a/config-controller/config/crd/bases/config.stackrox.io_securitypolicies.yaml
+++ b/config-controller/config/crd/bases/config.stackrox.io_securitypolicies.yaml
@@ -49,6 +49,11 @@ spec:
                 type: string
               disabled:
                 type: boolean
+              dummyField:
+                properties:
+                  something:
+                    type: string
+                type: object
               enforcementActions:
                 items:
                   enum:

This is what I expected.  The test correctly identified the artifact changes and that they were not applied in the branch.

check-generated-files now passes :tada:


Suggestion: [Option to] write to cache, then move to storage when stream ends

hey, I've been running this application for a few weeks now and it's served my purposes pretty well.
I'm running this via docker on my unraid box and when a stream is live my CPU usage looks like this:

docker mounts are as such;

/mnt/user/Twitch VODs/ is cache: yes and /mnt/user/appdata/ is of course cache: prefer
glances shows that my CPU has very high IOWAIT:

for a minute I thought this was writes but while watching the dashboard I see disk reads going up for my array. IMO there is no reason why the array needs to be read from to archive a live stream if the share is set to cache: yes.
in unraid's share browser the interface shows that the directory for this streamer is on the array, including the JSON for the currently recording stream:

my knowledge of how unraid's file system works is not 100% but it seems that writing a file to a directory still triggers a read of the array disk if that directory is on the array, even if the share is set to cache: yes.
so I believe that the IOWAIT CPU spikes are occurring because LiveStreamDVR is writing the currently live stream's .ts and .json files to the storage volume, when IMO it could be writing to the cache volume for the duration of the stream to avoid unnecessary array access.

hmm, i guess that's a viable idea

hey, I've been running this application for a few weeks now and it's served my purposes pretty well.
I'm running this via docker on my unraid box and when a stream is live my CPU usage looks like this:

docker mounts are as such;

/mnt/user/Twitch VODs/ is cache: yes and /mnt/user/appdata/ is of course cache: prefer
glances shows that my CPU has very high IOWAIT:

for a minute I thought this was writes but while watching the dashboard I see disk reads going up for my array. IMO there is no reason why the array needs to be read from to archive a live stream if the share is set to cache: yes.
in unraid's share browser the interface shows that the directory for this streamer is on the array, including the JSON for the currently recording stream:

my knowledge of how unraid's file system works is not 100% but it seems that writing a file to a directory still triggers a read of the array disk if that directory is on the array, even if the share is set to cache: yes.
so I believe that the IOWAIT CPU spikes are occurring because LiveStreamDVR is writing the currently live stream's .ts and .json files to the storage volume, when IMO it could be writing to the cache volume for the duration of the stream to avoid unnecessary array access.

That's way to high CPU usage for the recording task. Are you sure that this is only recording and not remuxing? Because for me my CPU sits at 5-6% while recording. Btw if correctly setup your mount it should write only to cache and move the file to your array when the file is finished. As far as I know is the iowait  a form of idle time when nothing could be scheduled. So it could mean that your CPU is either idle or underpowered

ts and mp4 files have always been stored in the same folder, so it's pushing data constantly to the storage

Yeah what I meant is unRAID specific you can setup that if to a path new files are written those files are firstly written to a "cache" pool which most of the time is a SSD and later moved to a spinning drive.

looks like this has solved my issue, thanks!


Angular + DatePicker - can't change font color for the input value

[x] bug
[ ] feature request
[ ] enhancement

Expected behavior
I'm using clarity in a angular project and currently I am struggling with the date picker.
When using the date picker without injecting the LOCALE in a simple <input type='date' clrDate> I can change the font-color by simply adding a css-rule color: red to it.
Actual behavior
When I inject the current LOCALE ('de-DE')  to my my angular component, the date will be parsed to the correct format (dd.mm.yyyy)  but I can't change the font color of that input.
Reproduction of behavior

https://clarity-light-theme-v11-fm8fyv.stackblitz.io/
Environment details

Angular version: 5.2.10

Clarity version:
v0.11.1

Browser: [all]

There appears to be some issue with the stackblitz, adding:
<style type="text/css">
input[type="text"] {
  color: red;
}
</style>```

to the bottom of `index.html` changes the color to red.

See this working example on stackblitz based on your code


[Bug] < Wit anime>: <couldn't find any video links (for some anime) although when I go to the website , I find a lot of servers >

Device information

aniyomi version: <IP_ADDRESS>-4506
Android version: 11

Source information

Name: witanime
Extension version: 12.10
-language:Arabic

What anime you are searching for


[Package Issue]: Discord.Discord doesn't update DisplayVersion -> remove Discord.Discord

Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Installation issue.
Brief description of your issue
Unfortunately, the Discord uses Squirrel.Windows for its installer, which in its current version doesn't update the DisplayVersion information in the registry: https://github.com/Squirrel/Squirrel.Windows/issues/1187
Therefor, until this is resolved, I suggest to remove Discord from the winget repository in the meantime. It doesn't make sense to me to keep a non-working package in the repository.
Steps to reproduce

install older version of Discord
update Discord via winget
DisplayVersion under ARP is not updated

Actual behavior
DisplayVersion information in the registry is not updated by the package's installer.
Expected behavior
DisplayVersion information should be updated by the installer.
Environment
Windows Package Manager v1.8.1911
Windows: Windows.Desktop v10.0.19045.4842
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.23.1911.0

Screenshots and Logs
No response

I don't think removing is the right call. Keeping the manifest still adds value for install/uninstall scenarios. There may be users that rely on winget install Discord.Discord (a command that works correctly) on a fresh machine.

update Discord via winget

Curious, how are you able to do this right now? You shouldn't be able to as we added UpgradeBehavior: deny in the manifest to block upgrades for this package.
 ~ winget upgrade Discord.Discord
The package cannot be upgraded using winget. Please use the method provided by the publisher for upgrading this package.

While it is unfortunate that package does not work well for upgrade scenarios, removing it altogether seems a bit excessive and more importantly a breaking move

@stevenlele please don't push new versions of Discord.Discord until Squirrel removes the bug in their installer script.

You shouldn't be able to as we added UpgradeBehavior: deny in the manifest to block upgrades for this package.

In that case it shouldn't be listed in the upgrade list, right? I do understand that this would be an issue for winget-cli.
I don't see how this is a breaking move, Discord can still be installed using the traditional methods. It's also not a given that and when the most recent version will land in winget's repo.
Furthermore, removing ShiningLight's OpenSSL also finally made their owner aware of the gravity of the issue and to change the installer script to reflect the correct version information. If we just leave it the way it is, Squirrel will never implement that urgently needed fix. So yeah, I think it's important to go this way. It's change, but change for the better!

I don't see how this is a breaking move

Breaking move for anyone that uses winget install Discord.Discord or winget uninstall Discord.Discord (as an example, think of someone using this command to install / uninstall the application on a fleet of devices). These commands won't work after the manifests are gone

Discord can still be installed using the traditional methods.

WinGet exists because developers want a one-command solution instead of traditional methods. Why take that ability?

Furthermore, removing ShiningLight's OpenSSL also finally made their owner aware of the gravity of the issue and to change the installer script to reflect the correct version information.

That's subjective, there's no guaranteeing that there will be any movement on the issue even if the package is removed. We should not break things for existing WinGet users for something that may not have an effect

The update itself works, but just the version number is not updated.

that "update" also has another user consent problem: the Discord installer ignores user preferences and forcefully enables mandatory start with Windows on next logon even if this is autostart is disabled in the Disscord app settings itself and in the windows registry / start menu.
The installer ignores all that and forcefully sets Discord to start at logon.
This behavior and the version number not being updated in registry are also in https://github.com/microsoft/winget-pkgs/issues/90642  from December 2022

that "update" also has another user consent problem: when launched by WinGet the Discord installer ignores user preferences and forcefully enables autostart with Windows on next logon even if this is autostart is disabled in the Discord app settings itself and in the windows registry / start menu.

But that's common with other apps as well? E.g. Opera if updated through winget will set itself as the default browser. Or Spotify always overwrites its shortcut in the start menu when updated through winget compared to updating from inside the app.

But that's common with other apps as well?

then if updating those apps causes forced changes of already-expressed user consent refusal then probably those apps should also have UpgradeBehavior: deny RequireExplicitUpgrade: true
i think i could probably add AnyDesk and TeamViewer to that list of badly behaving apps - each update of these forcefully enables a service that runs with SYSTEM level permissions even if the user has manually disabled that service and any start-with-OS setting in the app.
Also, PowerShell 7.4 forcefully enables telemetry on each update, in violation of the GDPR, even if the user has epressly denied consent for telemetry - the PowerShell installer wipes that environment variable preference and thus enables telemetry.
(i have long since disabled any sort of auto-start and also pinned Discord/AnyDesk/Teamviewer/PowerShell v7 in WinGet settings to tell it to stop trying to auto-update them - it is still notifying me but no longer tries to update them)

In that case it shouldn't be listed in the upgrade list, right? I do understand that this would be an issue for winget-cli.

https://github.com/microsoft/winget-pkgs/blob/9c1d6a3688aa5088ff6460bf5e80af96717459e4/manifests/d/Discord/Discord/1.0.9162/Discord.Discord.installer.yaml#L15
It used to be listed separately because of RequireExplicitUpgrade: true, but somehow the combination with the new UpgradeBehavior: deny (or just a new version of WinGet) broke that behavior - Discord goes back to the main list. I'm not sure if it's a bug.

The UpgradeBehavior has no effect on if it is listed or not. RequreExplicitUpgrade only works if Discord was initially installed through WinGet. If Discord was installed outside of WinGet, then it will show in the list for all upgrades and not require explocit targetting

After reading through the rest of this thread, I agree with @R-Adrian that removing this application could break several user workflows and that it should remain in the repo for that reason.

There are many applications who's self-upgrade doesn’t update the display version, but where using the installer does. WinGet handles this just fine by downloading and re-installing using the installer to ensure everything is up to date. The reason Discord is specifically marked the way it is was due to #90642.
Regarding wherher other applications should be marked as requiring explicit upgrade or denying upgrade entirely - that should be taken on a case by case basis with the behavior of each application that is thought to be badly behaving verified not only by the PR submitter but also by others in the community.

It is also important to remember that you can exclude applications from being updated on your own systems without removing them from the community repo. Just run winget pin add <package>.
If you don’t like the way WinGet handles updates for an application, you can pin it and then WinGet won’t try to upgrade it when you use winget upgrade --all.
Close with reason: Known issue; Package should remain in repo

WinGet exists because developers want a one-command solution instead of traditional methods. Why take that ability?

@mdanish-kh for what it's worth, the value of winget diminishes if there is a bunch of clutter from apps that don't conform to standards.  If apps can't populate a simple version string in the right place it's not outlandish to consider whether they should be allowed to participate in the ecosystem.  At the very least there should be some real pressure to get an app as popular as Discord to fix an issue on their end (which in turn might end up fixing the issue for other Squirrel-based apps).

winget upgrade Discord.Discord
Cannot update package with winget. Use the method provided by the publisher to update this package.

@tute123456
We are talking about winget.


Fix #29: Change default format for decimals

I changed default format with #29
Plz, check this one. If you have some feedback, feel free to let you know me :)

thank you

I will try and release a new version tonight


Cannot create ingress when aws-load-balancer-controller is deployed.

Cannot create ingress when aws-load-balancer-controller is deployed.
$ kubectl apply -f my-ingress.yaml

Error from server (InternalError): error when creating "my-ingress.yaml": Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1beta1-ingress?timeout=10s": context deadline exceeded

my-ingress.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: echoserver
---
apiVersion: v1
kind: Service
metadata:
  name: echoserver
  namespace: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: echoserver
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver
  namespace: echoserver
spec:
  selector:
    matchLabels:
      app: echoserver
  replicas: 1
  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
      - image: gcr.io/google_containers/echoserver:1.4
        imagePullPolicy: Always
        name: echoserver
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserver
  namespace: echoserver
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/backend-protocol: HTTP
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
spec:
  defaultBackend:
    service:
      name: echoserver
      port:
        number: 80

aws-load-balancer-controller will not work properly if you do not allow TCP ingress of 9443 in node_groups.
I will try to add a sample.
Reference: https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/2208

This looks like a Kubernetes question and not a module question - and by the last statement aws-load-balancer-controller will not work properly if you do not allow TCP ingress of 9443 in node_groups., it looks like you already solved your issue

Loosen the security group rules to allow the cluster to communicate with the nodes. Below is a loose (but still secure from the outside) configuration of security groups.
  cluster_security_group_additional_rules = {
    egress_nodes_ephemeral_ports_tcp = {
      description                = "To node 1025-65535"
      protocol                   = "tcp"
      from_port                  = 1025
      to_port                    = 65535
      type                       = "egress"
      source_node_security_group = true
    }
  }
  node_security_group_additional_rules = {
    ingress_self_all = {
      description = "Node to node all ports/protocols"
      protocol    = "-1"
      from_port   = 0
      to_port     = 0
      type        = "ingress"
      self        = true
    }
    ingress_cluster_all = {
      description                   = "Cluster to node all ports/protocols"
      protocol                      = "-1"
      from_port                     = 0
      to_port                       = 0
      type                          = "ingress"
      source_cluster_security_group = true
    }
    egress_all = {
      description      = "Node all egress"
      protocol         = "-1"
      from_port        = 0
      to_port          = 0
      type             = "egress"
      cidr_blocks      = ["<IP_ADDRESS>/0"]
      ipv6_cidr_blocks = ["::/0"]
    }
  }

I had timeout issue while accessing to sealed-secrets with kubeseal
https://EKS-URL/api/v1/namespaces/kube-system/services/http:sealed-secrets-controller:http/proxy/v1/cert.pem 503 Service Unavailable in 130043 milliseconds

I0227 23:08:32.578705   21012 request.go:1181] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"error trying to reach service: dial tcp podIP:8080:
connect: connection timed out","reason":"ServiceUnavailable","code":503}
error: cannot fetch certificate: error trying to reach service: dial tcp podIP:8080: connect: connection timed out

The problem was  default worker node security groups. It only allows from API  to nodes on 443 and 10250 ports.
But sealed-secret service is running on port 8080.
Fixed this by allowing access from API to nodes over port 8080 with the following rule in node_security_group_additional_rules
 ingress_cluster_all = {
      description                   = "Cluster to node all ports/protocols"
      protocol                      = "-1"
      from_port                     = 0
      to_port                       = 0
      type                          = "ingress"
      source_cluster_security_group = true
    }
    ```


black passes for loss without thinking

https://imgur.com/a/jhOhvKs
final score requires my/brian's patch of gtp

this is probably related to merging in https://github.com/tensorflow/minigo/blob/master/gtp_wrapper.py#L121 and screwing up the default parameters for creating our Player obj.

I think the root issue here is that you can't run from master (see backfill).


user.image

I'm not sure what it is an issue. but i need help.
in my user.rb i try save a link to avatar:
 def self.from_omniauth(auth)
    where(provider: auth.provider, uid: auth.uid).first_or_create do |user|
      user.provider = auth.provider
user.uid = auth.uid
user.email = auth.info.email
user.password = Devise.friendly_token[0,20]
  **user.image = auth.info.image**
 end
it works with omniauth-google-oauth2 but with discord I get only half of image src. for example: https://cdn.discordapp.com/avatars/714396517990037405/

sorry, my carelessness.


Compute loss on validation

Hi!
Thx for this amazing work!
I'm not very experienced yet, can you tell me how can i compute loss (only) on validation?
Set torch.no_grad() enough for this? Cause model.eval() changes output of DetBenchTrain.
if not self.training:
            # if eval mode, output detections for evaluation

I'm little confused.

No grad has no effect on that  Remove the block you are pointing at, or add an extra check like 'if not self.training and not self.loss_only_on_eval'

Thanks for the answer! Already remove it. Just wanted to make sure I'm not missing something :)

Thanks for the answer! Already remove it. Just wanted to make sure I'm not missing something :)


ImportError: cannot import name 'convert_namespace_to_omegaconf' from 'fairseq.dataclass.utils'

I am trying to run the translation code in my IDE.  The python code is placed under indicTrans folder.
The statement
from inference.engine import Model
throws an error :
  File "Run.py", line 1, in <module>
    from inference.engine import Model
  File "/home/sneha/Documents/indic/indicTrans/inference/engine.py", line 15, in <module>
    from inference.custom_interactive import Translator
  File "/home/sneha/Documents/indic/indicTrans/inference/custom_interactive.py", line 17, in <module>
    from fairseq.dataclass.utils import convert_namespace_to_omegaconf
ImportError: cannot import name 'convert_namespace_to_omegaconf' from 'fairseq.dataclass.utils' (/home/sneha/.local/lib/python3.8/site-packages/fairseq/dataclass/utils.py)

May I know how this can be solved ?
Thank you

@snehampatil ,
Which documentation are you following? Did you git clone fairseq?

Import Statement : from inference.engine import Model
I followed the installation steps mentioned in the Colab Notebook. And I have cloned the fairseq
git clone https://github.com/pytorch/fairseq.git

Sorry for the late reply.
I just tested our tutorial colab notebook with the latest fairseq and didn't face this error.

You can double-check the fairseq installation in your local(see if you have another old fairseq that your python is using as default, etc) or help us with a reproducible colab script.

The issue has come back. Tested on the tutorial nb too. Can anyone help resolve it?


Add selected to option

Checklist:

[x] Documentation
[ ] Tests
[ ] Ready to be merged

Deploy preview for affectionate-nobel-f3a8ec processing.
Built with commit c54146de349d0170beb8987014fc41dc1f99b120
https://app.netlify.com/sites/affectionate-nobel-f3a8ec/deploys/5bf2d524dc431f7d022522d8

@anishamalde please can you take another look at these changes and review my previous comment?
It looks as though the only thing that has changed here is you've added prop type, which shouldn't result in any functional change.
Please run yarn build && yarn test on your branch before opening a PR and ensure tests pass.


fix workload help message

https://bugzilla.redhat.com/show_bug.cgi?id=1669411

Pull Request Test Coverage Report for Build 671

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 87.124%

Totals

Change from base Build 665:
0.0%

Covered Lines:
2074

Relevant Lines:
2276

💛  - Coveralls

@jelkosz do we really want to change it to workload ?  Doc https://docs.google.com/document/d/1ks4H-ImD-r0s5eV4FsP_73kRdAP6sKJTRbj8nClpyp0/edit#heading=h.o4npgyz4fz5s still says work. Bugzilla says the word "work" should be "workload" . I wonder what is that based on ?


The url of the Referit is invalidate.

Hello,  the url in download_data.sh is invalid. Could you please send the data to me? Here is my email address<EMAIL_ADDRESS>.Thank you very much.

Could you please send the data to me? Here is my email address<EMAIL_ADDRESS>.Thank you very much.

Hi, Could you please send the data to me? My email address<EMAIL_ADDRESS>.Thank you very much.

Hello, the url in download_data.sh is invalid. Could you please send the data to me? Here is my email address<EMAIL_ADDRESS>.Thank you very much.

have you solved this problem? @Zhongxyyyy @2021wangkai

Hello, I am trying to reproduce this paper, but I can not access these two links: REFERIT_SPLITS_URL="https://s3-sa-east-1.amazonaws.com/query-objseg/referit_splits.tar.bz2" REFERIT_DATA_URL="http://www.eecs.berkeley.edu/~ronghang/projects/cvpr16_text_obj_retrieval/referitdata.tar.gz" Could you please sent me the dataset? My mail address is<EMAIL_ADDRESS>Thank you very much!

Dear Author, I am trying to reproduce this paper, but I can not access these two links: REFERIT_SPLITS_URL="https://s3-sa-east-1.amazonaws.com/query-objseg/referit_splits.tar.bz2" REFERIT_DATA_URL="http://www.eecs.berkeley.edu/~ronghang/projects/cvpr16_text_obj_retrieval/referitdata.tar.gz" Could you please sent me the dataset? My mail address is<EMAIL_ADDRESS>Thank you very much!

Dear Author, I am trying to reproduce this paper, but I can not access these two links: REFERIT_SPLITS_URL="https://s3-sa-east-1.amazonaws.com/query-objseg/referit_splits.tar.bz2" REFERIT_DATA_URL="http://www.eecs.berkeley.edu/~ronghang/projects/cvpr16_text_obj_retrieval/referitdata.tar.gz" Could you please sent me the dataset? My mail address is<EMAIL_ADDRESS>Thank you very much!


Update many docs with recent rendering changes

I started out by just trying to update the things that have been added since the last run of --doctool ., but ended up documenting many of the rendering features added in 4.0. I still haven't finished everything, but this PR was getting so big I decided to cut it off here for the sake of reviewers.

@Calinou Thanks! I made the requested changes. :)

@akien-mga If @Calinou doesn't have any more requested changes, this should be good to merge.

Thanks!


Accessible workspace table includes groups that the user is not in

See line:
https://github.com/UW-GAC/django-anvil-consortium-manager/blob/main/anvil_consortium_manager/views.py#L280
This includes WorkspaceGroupSharing objects for groups that the user is not in.
Right now I think the best way to solve this is:

Add an Account.get_all_parent_groups() method. It should return the set of groups (and parents of those groups) for an Account. This can use the code from the first part of Account.get_accessible_workspaces().
Modify the Account.get_accessible_workspaces() method to use the output of Account.get_all_parent_groups().
In the AccountDetail view, filter WorkspaceGroupSharing to the workspaces returned by Account.get_accessible_workspaces() and Account.get_all_parent_groups().

Account.get_all_groups() is probably a better name than Account.get_all_parent_groups() since it should also include groups that the Account is directly part of.

Closed by #286


sampling doesn't stop after words in stop_words_list are generated

It seems that during sampling from GPT, even after a word in stop_words_list is generated, the generation still wouldn't stop early until it reach the defined sequence length. Looking at the code, it seems currently stop_words_list is only used to update output_tensors->at("finished"), which in turns is used during beam search. Am I understanding it correctly? Could it support early stopping for sampling as well?

This is a know issue, please refer this issue https://github.com/NVIDIA/FasterTransformer/pull/487.

The issue is fixed in the MR https://github.com/NVIDIA/FasterTransformer/pull/584 and merge in main branch. Sorry for the late fixing.


Show weeknumber

Is there a possibility to insert the weeknumber in the first column?

I'd like that also

Me three!


Make bullet shells and other low-utility entities eventually despawn

If left to lie around, they can really gum up the gears of the server as far as I can tell. Either this, or mark them "special" in some way that prevents the server from doing any extra calculations on them.
As per CakeQ this should be a config option, as, for example, servers like CM could care less about keeping bullet casings all over the floor (imo), while heavily RP oriented servers would want to keep them around for detective work.

In the grand scheme of things you want this to be tied under a configuration as things like bullet casings will be used to collect evidence and solve crimes by detectives in a typical ss13/14 game.

I don't think having bullet casings should be an issue as long as netcode is optimized for it

Casings can often be collected for metal by shoving them into an autolathe.

This is really only going to be a problem if the game mode includes a lot of guns. Most SS13 rounds don't have many rounds fired from what I can tell, so I'd keep it as non-despawning or as CakeQ said it should be a config setting.

Agree with the configuration options for removing bullet casings after a certain amount of time.
While they are extremely handy for a typical SS13 game and kinda add to the complexity that comes with the game itself, the times that casings are used that are warranted to keep them forever with whatever code time they might bring can be less beneficial then outright making them temporary even with a long timer. However, if optimized properly, they should stick around completely by default.
We can go a bit further and add temporary flags to any entity which would get cleaned up on a similar config timer if they aren't interacted with in a while. In general, this could be an option for games/servers that truly need less of the clutter around.


Whim should try to create its homedir if it doesn't exist

It should also try to create the subdirectories it expects:

log/
public/author_photos
public/images
templates/
data/


Adding SAP Sample

https://github.com/MartinPankraz/AzCosmosDB-OData-Shim

Microsoft authors of articles need to make updates through the private repository so the updates can be staged and validated by the current validation rules. After you review staging and fix all validation issues, you can add the sign-off comment to let the PR reviewers know the updates are ready to be merged.It's easy to access the private repo version of your articles in GitHub. Just add -pr to the URL, as follows:
Public repo URL: https://github.com/MicrosoftDocs/azure-docs
Private repo URL: https://github.com/MicrosoftDocs/azure-docs-pr
We have closed this pull request. Please resubmit the updates through the private repo. For more information, [see the contributor guide].(https://docs.microsoft.com/en-us/contribute/)


First span for received http request now gets new span id (since sleuth 3.0.0) - Is this by purpose?

While updating a few spring boot services to 2.4.2 including Sleuth 3.0.0 we saw that the first span for a received http request (that is in our case reported to zipkin / jaeger) gets a new span id and the parent id is set to the received value of x-b3-spanid http header.
With the previous major version of sleuth (2.x.x) the first span created for a received http request contained the value of the x-b3-spanid http header as the span id, so basically, the span was continued.
Was this an intended change? And if so, why was this done? I tried to understand the B3 specification to see, what the desired behaviour should be but without much success. From what I read in the sleuth documentation here https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/htmlsingle/#getting-started-terminology I would have expected that the first span for the received http request gets the span id contained in the incoming http request.
I got aware of that because we have one node.js service participating in the trace and the traces now were broken because of that changed behaviour. The node application created the first span with a span id set to the value of the x-b3-spanid of the received http request (the same as sleuth did with version 2.x.x.).
UPDATE: The more I investigate this, the more I think this is a bug. Previously, a sending (requesting) spring boot application was sending a span of type "client", and the span id of this span was also sent in the http headers. The receiving spring boot application (and also our node js application) was creating a span of type "server" with the same span id (the one from the incoming http request). This for me seems to be the desired behaviour.
Can you please comment on this? Much appreciated! Thanks a lot!

x-b3-spanid is no longer supported. Can you elaborate exactly on what happens in which service?

I found this explanation (https://github.com/openzipkin/b3-propagation)
Some propagation formats look similar to B3, but don't propagate a field named parent. Instead, they propagate a span ID field which serves the same purpose as ParentSpanId. Unlike B3, these systems use a different span ID for the client and server side of an RPC. When a server reads headers like this, it is expected to provision a new span ID for itself, and use the one it extracted as its parent.
Here's an example of an alternate library composing a trace context with incoming http request headers and an ID generator:
< picture not copied >
In both B3 and the above example, incoming headers contain the parent's span ID, and three IDs (trace, parent, span) end up in the trace context. The difference is that B3 uses the same span ID for the client and server side of an RPC, where the latter does not.
—-
I have a feeling that sleuth since version 3.0.0 now behaves as mentioned above in the second example and not like the B3 specification anymore. That is at least what we see.

Sure, but can you write exactly what kind of apps do you have, what they are doing, what is put in the headers, what do you see that happens and what do you think that should happen. Creating samples that replicate this issue would be best of course.

HI @marcingrzejszczak would you be available for a remote call today in order to discuss this? That would be faster than just writing back and forth. I am happy to provide some examples, would even prefer to do this in a remote call.

It can be tricky ATM cause I'm a little bit overwhelmed with work. How about you try to create the samples that replicate this? It will be much easier to reason about the issue.

Hi @marcingrzejszczak  I have found a way now to get our solution working even with the changed behaviour on the most recent sleuth version. So I would not like to spent more time with it. I tested another tracer / instrumentation (the one from the jaeger ecosystem) and saw this one does exactly the same as sleuth 3.0.0 so that client and server side of an RPC call (in this case the HTTP request) have different span ID's. Therefore, from my perspective we can close this isssue here.
If you have a chance, I would much appreciate if you could rather have a look into #1840 since this seems to really be a bug that now produces garbage in the trace collector (zipkin or jaeger). Thanks a lot!


Cloud to Prod Auth Interop Tests are Failing

The cloud_to_prod_auth tests have been failing for a few days now. See https://grpc-testing.appspot.com/job/gRPC_interop_master/10220/#showFailuresLink.

This was an issue that was happening on grpc-canary-interop2 and was caused by me recreating the VM on Friday to resolve some other interop flake. It should be fixed now, but I'll leave this issue open so others can see why their interop pull request test was failing.


docs: comment middleware

What's the purpose of this pull request?
Add Price With Taxes documentation
How it works?
This PR adds news token and Props comming from Price wIth Taxes feature.
How to test it?
Access the Doc Portal
Order Summary
Props

Tokens

Product Card
Tokens

Props

Starters Deploy Preview
https://vercel.live/open-feedback/faststore-site-git-docs-add-price-wit-taxes-docs-faststore.vercel.app?via=pr-comment-visit-preview-link&passThrough=1

Hey @ArthurTriis1 , we are not using the docs from this repo anymore. We are using the docs from the developers' portal. @Mariana-Caetano can help you with the current process if you need it.


MM-24128: Remove extra space from 'React to last message' shortcut help text

Summary
Report by @uhlhosting at https://community.mattermost.com/core/pl/ack1rznakb8ttngj5q81qwx7gc
Ticket Link
https://mattermost.atlassian.net/browse/MM-24128
Related Pull Requests
N/A
Screenshots

/update-branch


Then I try install mmocr and do mim install mmdet I receive mistake with pycocotools in Windows 10

Hi all !
Then I try install mmocr and do mim install mmdet I receive mistake with pycocotools in Windows 10.
I try use two ways of install mmocr:
mim install mmocr
git clone https://github.com/open-mmlab/mmocr.git
cd mmocr
pip install -v -e .
Also I try that:
mim install mmdet
By all the ways I receive next mistale:
Building wheels for collected packages: pycocotools
Building wheel for pycocotools (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for pycocotools (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [16 lines of output]
running bdist_wheel
running build
running build_py
creating build
creating build\lib.win-amd64-cpython-38
creating build\lib.win-amd64-cpython-38\pycocotools
copying pycocotools\coco.py -> build\lib.win-amd64-cpython-38\pycocotools
copying pycocotools\cocoeval.py -> build\lib.win-amd64-cpython-38\pycocotools
copying pycocotools\mask.py -> build\lib.win-amd64-cpython-38\pycocotools
copying pycocotools_init_.py -> build\lib.win-amd64-cpython-38\pycocotools
running build_ext
cythoning pycocotools/_mask.pyx to pycocotools_mask.c
building 'pycocotools._mask' extension
C:\Users\igorb\AppData\Local\Temp\pip-build-env-rjyj771z\overlay\Lib\site-packages\Cython\Compiler\Main.py:369: FutureWarning: Cython directive 'language_level' not set, using 2 for now (Py2). This will change in a later release! File: C:\Users\igorb\AppData\Local\Temp\pip-install-kw0d6pi7\pycocotools_53dc49e9c1f54228986bb075233c5b1c\pycocotools_mask.pyx
tree = Parsing.p_module(s, pxd, full_module_name)
error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for pycocotools
Failed to build pycocotools
ERROR: Could not build wheels for pycocotools, which is required to install pyproject.toml-based projects

I got the same error，it seem that the pycocotools cannot be installed in WINDOWS. You can downgrade your python version to 3.8 or older. Then run "pip install git+https://github.com/philferriere/cocoapi.git#subdirectory=PythonAPI". Just try it, maybe it will work.


Pretty print options

Summary
Details and comments
Fixes #1490

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

4 of 12 (33.33%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.09%) to 83.387%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_ibm_runtime/options/options.py
2
10
20.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.09%

Covered Lines:
6164

Relevant Lines:
7392

💛  - Coveralls


100% Java?

Thoughts about adopting Kotlin for mobius? I understand Kotlin can be used with mobius. It'd be nice if mobius was written in Kotlin.

There might be a point of a pure kotlin implementation to allow compiling to javascript or native, but it's not something we've discussed at this point.
There are however kotlin extension planned, most likely including coroutine support. We don't really have a timeline for when those will be out, but for the time being you can find some snippets that might end up being included by looking in the kotlin branch of the sample app repository

@togi
Would you be interested in a PR containing mobius core converted to pure Kotlin impl without java dependencies? I've done conversion already, every test except logger-related pass. If you're interested I'll fix remaining tests and make a separate package for mobius kotlin core, and another for tests to allow them to be used from jvm to avoid converting tests too.
There are, of course, some places where it can potentially break on other platforms, so it's a work in progress.

@ATizik I've done similar work here if you want to leverage any of it.  Note the internal Mobius design will only work on a single thread with K/N, I have a Worker based implementation that I'm experimenting with but much of the core-common code needs to be reworked to support it.

@DrewCarlson
That could certainly be helpful, thanks!
I wonder if you experimented with coroutines on K/N instead of threads? I feel like K/N threads are so foreign to traditional JVM threads that it might need a lot of work to get it up and running.

I'd certainly be interested in seeing a kotlin branch if you have it, but I think a PR converting everything would be a bit hard to review properly. The main issue isn't really to just convert everything to kotlin, the main concern would rather be maintaining API stability towards previous versions, as well as creating an API that makes sense for kotlin (including kotlin-specific extensions), and supporting kotlin native. Basically, we'd like to make sure we get it right, and I believe the best approach would be to do it iteratively (eg. each pull request focusing on just one part of the public API) and using tools like japicmp to make sure we stay binary-compatible.
I've been meaning to add japicmp-gradle-plugin to the project but just haven't had time lately, maybe someone in the community would be interested in taking that on?
@DrewCarlson We used WorkRunners internally specifically to make mobius agnostic of threading models. So if there are limitations from how we've implemented it, we'd definitely be interested
if you can explain a bit more in detail what the problem is (preferably reported as a serparate issue).

@ATizik I did consider coroutines, currently they are not a practical solution here.
Kotlin Native does not provide Thread-like APIs, which does introduce some issues but binary compatibility in a core-jvm module can be maintained.  As it exists now, the current design could certainly be supported by K/N by adding the necessary threading primitives.  This would require wrapping native target platform APIs which to me feels like a hack and requires more work to support all native targets.
I felt the best solution for K/N was to restructure around Workers.  WorkRunner's cannot simply pass a Runnable to a Worker and execute it, extra effort is required to ensure that any data passed to the Worker cannot be mutated by another Worker.  Happy to explore possible solutions in a separate issue.
On topic:  My port has some breaking changes that are almost all because of sealing off the API, which is a good change IMO (except for any cases I overlooked).  Outside of the few remaining issues, compatibility on the Java side is good though existing Kotlin projects require a few changes (as expected).

@DrewCarlson ah, I see. If you look at mobius internals you'll see that the only thing the WorkRunners are used for is to create MessageDispatchers, and those are just a building block for something that works a bit like actors in kotlin coroutines. Maybe we should change so that instead of just configuring WorkRunners in the loop factory, you'd be able to configure MessageDispatchers directly? It'd require some changes internally in mobius but it wouldn't require the public API to change. I'll try prototyping the idea a bit and see what it looks like.

Coroutine version of WorkRunner. Because there are no actors in common module I did this primitive solution. Tests pass with this worker, but I'm not sure if they are extensive enough to test corner cases
@togi
So, to make it clear, if I made iterative PR with kotlin conversion it would be helpful? Would you like to eventually convert mobius-core completely to kotlin, or have a separate artifact, at least until conversion is complete?


Spelling Issue

https://github.com/evolutionleo/Warp/blob/afe69a72a7bd0c82885501863e3c41644b722e1e/TypescriptServer/tsconfig.json#L25
Not sure how much this matters but should be "node_modules/*".

wow no idea how I haven't noticed this, thanks. fixed in the latest commit
it shouldn't be that relevant if the thing works with the typo i guess haha
still, thanks for noticing though!


Update network-policies docs

Correctly reference "source port" instead of "IP address".

Hi there. We don't normally use the terminology source port in Cloudflare content. Closing this ticket for now.

The documentation page in question was already using the term "source port",  it's already live at
https://developers.cloudflare.com/cloudflare-one/policies/filtering/network-policies/#source-port
this PR was just trying to correct what looks like a probable copy-paste error from the header above, so that the header and sentence match


chore: pin version

I just don't want to be surprised by some random breaking change tomorrow

LGTM, this will be used for people that are using groth16-solana from light-protocol.

just to clarify, we're the ones using the this groth16 patch
"patch" might be a bit misleading here -- there's no precompile stuff going on. This fork just uses a version of solana-program that can be build in the same repo as sp1-sdk. So we need to use this patch to create an e2e sp1 solana verifier.

I just patched bn254 in sp1-solana instead of patching this crate


UI style glitch

Rancher Version:
1.1.0
When upgrading, the alternating background for service status column is lost...

After the upgrade completes, it gets ok again.

This is actually a browser rendering bug caused by using GPU acceleration for the spinner, but is worked around already in 1.2.


SSR register unpacking wrong size

According to the documentation for immediate SSR config instructions, this should rather be [6:0]. The unpacking currently assigns the wrong register.
https://github.com/pulp-platform/snitch/blob/e878671dc4fc498b35fd89431a3ab28eee30ca2d/hw/ip/snitch_cluster/src/snitch_cc.sv#L594

This is addressed in #70


driver: watchdog: Incorrect expression in wdt_wwdg_stm32.c

This patch changes wwdg_stm32_get_timeout function to calculate f_wwdg to a float variable
It fixes the issue Incorrect expression in /drivers/watchdog/wdt_wwdg_stm32.c #20504
[Coverity CID :205661]
Signed-off-by: Francois Ramu<EMAIL_ADDRESS>

Fixes #20504


[Snyk] Upgrade org.flywaydb:flyway-core from 9.17.0 to 9.18.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade org.flywaydb:flyway-core from 9.17.0 to 9.18.0.
As this is a private repository, Snyk-bot does not have access. Therefore, this PR has been created automatically, but appears to have been created by a real user.
:sparkles: Snyk has automatically assigned this pull request, set who gets assigned.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 22 days ago, on 2023-05-15.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
👩💻 Set who automatically gets assigned
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

https://github.com/navikt/permitteringsskjema-api/pull/248


Please test with the NumPy release candidate

Not sure if you already put it on the list of things to do (or maybe it is now always done)?  But it would be great if you could test numba against the NumPy pre-release wheels now (they are available on PyPI).
In case NumPy has things to work out, it would be cool to be able to work them out before the actual release!

@seberg thank you for raising this. Testing against NumPy pre-releases has been on our list for a long time, but we have not yet gotten around to it. xref: https://github.com/numba/numba-integration-testing/pull/76 <-- this is one potential avenue we could explore. I think for this to be meaningful, it will need to be integrated into a nightly run of some sort that tests Numba's main against the NumPy pre-releases, which will require some CI/CD/infrastructure work.

Sorry, I just wanted to give a heads up that very concretely the NumPy 1.23rc1 is now available.  Don't hesitate to close again!

Sorry, I just wanted to give a heads up that very concretely the NumPy 1.23rc1 is now available. Don't hesitate to close again!

Oh yes, that makes sense, we can probably easily re-purpose some config we have to give this a spin!

Thanks for coordinating on this @seberg. I've opened: https://github.com/numba/numba/pull/8121 which will give a reasonable indication of problems (if any) from the standard Numba public CI run using NumPy 1.23rc2 everywhere.


JRuby support

Add support for RBTree on JRuby.

Please let me know when your patch is ready. Since this is a very large code addition, I would like to ask the author and maintainer, OZAWA Takuma, to make a decision. I am just helping him, and this public mirror repository is just for minor fixes and to make it easier for me to do the release work.
BTW, is there an option to distribute it as a separate gem, such as rbtree-java gem? (I am not familiar with JRuby's gems)


Reduce Unit Test Memory

Pull Request Description
Fixes #1438
Only 10 gb on circle-ci! This is half of what it was before when we had n 8 in the pytest config and about 4 gb less than the current footprint with n 4
This is also faster I think. I recall seeing times around 270-300 seconds before making this change.

After creating the pull request: in order to pass the release_notes_updated check you will need to update the "Future Release" section of docs/source/release_notes.rst to include this pull request by adding :pr:123.

@dsherry I couldn't find any unit tests that explicitly check that the right value of n_jobs is passed to the pipelines so I added one for AutoMLSearch and IterativeAlgorithm. Good call! We have coverage with n_jobs set to -1 and 1 for all estimators that accept n_jobs so I'm confident about that.
I think the idea you and @christopherbunn have about defining a separate testing job for parallelism is great! I think we need to be careful about having parallelism across and within tests at the same time.


Unable to extract media URL on supported site xhamster

I found youtube-dl wasn't working for xhamster.  I then checked that the first test URL in xhamster.py is a working page, then tested it.
$ youtube-dl --verbose http://xhamster.com/movies/1509445/femaleagent_shy_beauty_takes_the_bait.html
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', 'http://xhamster.com/movies/1509445/femaleagent_shy_beauty_takes_the_bait.html']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.07.28
[debug] Python version 3.4.3 - Linux-4.1.3-1-ARCH-x86_64-with-arch
[debug] exe versions: ffmpeg 2.7.2, ffprobe 2.7.2, rtmpdump 2.4
[debug] Proxy map: {}
[XHamster] 1509445: Downloading webpage
WARNING: unable to extract thumbnail; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
ERROR: Unable to extract media URL; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/youtube_dl/YoutubeDL.py", line 656, in extract_info
    ie_result = ie.extract(url)
  File "/usr/lib/python3.4/site-packages/youtube_dl/extractor/common.py", line 279, in extract
    return self._real_extract(url)
  File "/usr/lib/python3.4/site-packages/youtube_dl/extractor/xhamster.py", line 100, in _real_extract
    video_url = extract_video_url(webpage)
  File "/usr/lib/python3.4/site-packages/youtube_dl/extractor/xhamster.py", line 52, in extract_video_url
    raise ExtractorError('Unable to extract media URL')
youtube_dl.utils.ExtractorError: Unable to extract media URL; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

This issue is already fixed and will be available in the next version of youtube-dl.

Sorry for the repost of the issue, dstftw.  I tried searching issues before posting and didn't find it.  I see I mistakenly left "is:open" in my query.


Fix reviews for configurable products and remove unnecessary store ac…

New pull request for: https://github.com/DivanteLtd/vue-storefront/pull/2552

@patzick I update the changelog


tests: try to stabilize test_server_auto_adjust_replica

Signed-off-by: 5kbpers<EMAIL_ADDRESS>
What problem does this PR solve?
Issue Number: close #3162
Problem Summary:
test_server_auto_adjust_replica is not stable because of the replica count check.
What is changed and how it works?
What's Changed:
Relax the check condition.
Related changes

Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test

Release note

N/A

It could also fix https://github.com/tikv/tikv/issues/8358

/merge


fix type error in swagger.yaml

fix #3310

Coverage increased (+0.05%) to 54.749% when pulling 3569d62b83f88543cd113884d723e9fce2173734 on huzhengchuan:patch-1 into e79334a445255dce9d4266751c82ccfb65f5ec73 on vmware:master.

/assign @reasonerjt
help me review it, thanks


Generate compiler jar with dependencies

Fix for https://github.com/protostuff/protostuff/issues/138
Generate compiler jar with dependencies by default, previously it was in a separate profile.
$ java -jar protostuff-compiler/target/protostuff-compiler-1.3.7-SNAPSHOT-jar-with-dependencies.jar

To generate code for multiple modules:
  java -cp -jar protostuff-compiler.jar modules.properties

The properties file would look like:

modules = foo,bar
foo.source = path/to/your/proto/file/or/dir
foo.output = java_bean
foo.outputDir = src/main/java
foo.encoding = UTF-8
foo.options = key1:value1,key2:value2
bar.source = path/to/your/proto/file/or/dir
bar.output = java_bean
bar.outputDir = target/generated
bar.encoding = UTF-8
bar.options = separate_schema,generate_field_map

===================================================

To generate code for a single module, execute the jar without args and specify:
  -Dsource=path/to/your/proto/file/or/dir
  -Doutput=java_bean
  -DoutputDir=src/main/java
  -Dencoding=UTF-8
  -Doptions=key1:value1,key2:value2

Looks good.  Being default means the jar-with-dependencies will also be uploaded in maven central.

Being default means the jar-with-dependencies will also be uploaded in maven central.

That's the point.