If there are any votes, it would be on meaningful topics, like documentation. "Do you think this crate is well documented ?", where it would go from "No / poor documentation" to "Covers every edge case perfectly" and with "Just enough to get started" in-between. The average of these would get you a rough idea of how the package's documented.
Of course, people could still vote for a crate they've never used, but I don't think people are that ill-willed in a package management website. If you're voting for documentation, it's implicit that you must have tested the crate before. To avoid the old projects crushing the new ones, a simple system of "only the votes that are 3/6/9/12 months old are valid" could be used.
You're talking about apps on the appstore, but these are different: they get paid for almost every download (and that's why they're asking for a better rating), but a crate has little to no interest in doing that ( maybe gaining more contributors ?).

But what about crates that don't have statistically-significant number of votes/surveys filled?  I don't think Rust community is large enough yet to have non-noisy amount of votes for every crate.
I worry that new crates and niche topics will be left out cold.
I prefer quality-based metrics over popularity-based ones, because quality measurement works for the long tail of packages and its reliability doesn't depend on amount of visitors to its crates.io page.

I do prefer quality-based instead of popularity metrics as well, and by sorting by rating instead of number of votes, I think the ranking will indeed be quality-based instead of popularity-based.
As for crates without enough votes to have a significant rating, use a very simple-but-dumb default placeholder, either based on a constant (same across every crate), or based on the number of comments or anything. It can be dead simple if it's meant to be overridden by human votes later. In such as system the placeholder isn't significant, while the votes are very important.
Your problem of niche crates being left out makes me think of the Ant Optimization Algorithm. You might say it's unrelated but I don't really think the principle it that far from our problem. The idea is that to get to the best and closest food source, most ants will follow the path that everyone follows (and it applies for us rustaceans as well on crates.io), but sometimes, a single ant will choose another path which might lead him to a better or equivalent food source. Ants will have a low probability of following the new path, but if those who follow it find that the new path is better, they will keep using it, and thus more ants will use it as well, resulting in a nice balance in the long run.
It's kind of the same with us rustaceans as humans, sometimes some of us will try new paths, and other users might notice it and try the new crate; if they notice it's better than what they used before, then more users will join as well. As long as we have a system of "only keeping the votes of the last X months", this will happen naturally (it's actually one of key principles for the ant optimization as well, it's based on the fact that pheromone only lasts so long, allowing paths to "reset" over time and always find a balance).
We have to keep in mind we are not ranking the crates directly. I don't think there will be a top 10 or top 20 of the ratings, or anything like JavaScripting might be doing for instance. The goal here is to be able to rank crates against each other, and letting the community decide as a "swarm intelligence" is what will give the best results in the long run in my opinion.
The idea of automatically rating crates sounds nice, but the problem is mainly the fact that an implementation of such an algorithm will be very difficult to do, and I'm sure we won't be able to cover all edge cases so that every crate gets a fair rating according to the algorithm.

The idea of automatically rating crates sounds nice, but the problem is mainly the fact that an implementation of such an algorithm will be very difficult to do, and I'm sure we won't be able to cover all edge cases

Ranking by votes is a form of algorithm, too. It depends on methods of aggregation, weighing, filtering, as well as human factors like presentation of the questions and how users interpret them.
And it does not cover all corner cases either! We can't expect to find a flawless algorithm, but I hope to devise one that is better than merely sorting by number of downloads.
Statistically, I'd consider downloads and voting to be highly correlated (they're both proxy of popularity), so adding voting to downloads is unlikely to fix aspects of ranking that downloads are bad at.
I don't think discoverability can be purely modelled like the ants. It not only matters that the algorithm asymptotically works, but also how quickly it settles in the optimal state. Downloads and votes aren't quick to adapt, because sorting by popularity creates a very strong self-reinforcement. Top packages are displayed first, because they're popular, and they're popular, because they're displayed first. Also users aren't purely random, they follow trends and fashions.
So I think adding an objective quality metric, which is statistically uncorrelated to number of humans looking at it, will improve the algorithm overall, as it'll work for cases where popularity doesn't — long tail, and immediate reaction to changes in package's quality.

Top packages are displayed first, because they're popular, and they're popular, because they're displayed first.

That's a main reason, but there are some elements missing: it's only a part of the big picture. If only the "displayed first means most popular" rule would apply, jQuery would still be the most javascript library as of now. Users tend to use the most popular one, but sometimes users will choose another path, which they might find better, and other people will tend to join in the trend of the "better path" as well.
I do agree that most people follow trends, but some people won't care at all and just try to discover new things. If they manage to draw other people just by the fact that they're using another path, people will have a proportional tendency to test the new path. You'd be surprised at the rate which people adapt, too, libraries like React went from unknown to very popular to must-not-miss in a few months only. Of course, it's not instant like an algorithm like you described would be, but having a totally different crate ranking from the day before would definitely bother me personally, so I do prefer slower changes on that part.
In the end I think we both made our point, in which our proposals have both their flaws and their advantages, and we won't advance anymore by butting heads now.
I guess the best here would be to do a community-wide survey about "how should the crates be ranked in a potentially new crates.io ?" (with multiple choices like "keep the number of downloads", "using an algorithm automatically detecting a good documentation", "with user votes", etc, and with other possibilities being the most interesting ideas in this thread).
I personally feel like the thread is going stale and we're turning in circles now.

@pornel Do you have a concrete example of an objective quality metric?

As a minimum, I've suggested looking for any sort of documentation in package's metadata, and decreasing ranking if there is none found.
BTW: I've used "objective metric" here in a mathematical sense that it is a pure function ranking_factor = metric(package) as opposed to ranking_factor = metric(something other than the package itself), and absolutely not in any philosophical sense.

@sgrif

@pornel Do you have a concrete example of an objective quality metric?

IMO the following are objectively better than a crate without:

#[deny(missing_docs)]
A readme
A license
Onlilne documentation
Either # Examples in docs
examples/ in repo
tests/ in repo
utilizes unit tests
actual coverage data (coveralls.io or the like...admittedly this one is hard)

Should any of those be weighted higher than others? No idea.
Again, the key point for everyone to remember is we're comparing like crates. If it doesn't make sense for a particular crate to have some of those items, chances are good none of the crates in that category will have them, and therefore any penalty in the score is effectively negated. We're not ranking libc against nom, but nom against peg (for example).

@kbknapp
nom vs. peg 😉
I think it's safe to say that a hundred users speak to the usability of the crate and its documentation. And the 76 contributors speak to the interest in the crate itself.

Ok everyone! We've made another big revision to this RFC. The TL;DR of what we're now proposing is:

By default, order crates within keywords and categories by the number of downloads in the last 90 days, which should get crates that the community thinks are good on the first page
Add more badges/indicators on crate list pages that anyone can use to evaluate crates according to what is most important to them; badges do not influence ordering

We're returning to the LOC ratio of docs to code and crates in the top 20% get a badge, while coarse, we think it's still useful and it'll be very obvious if people game it.
Maintainers have a field for self reporting maintenance intentions, we can bikeshed over the available values in a crates.io issue
We'll enable maintainers to add a badge from isitmaintained.com to show github issue activity
We'll enable maintainers to add a badge from coveralls.io to show test coverage
We'll enable users to have a list of favorite owners whose work they trust that will highlight other crates by those owners

Render the README on a crate's page
We'll ask in the community survey if people are satisfied with the ordering and badges and finding them value, and if not, how they could be improved. Major changes will get a new RFC.

@carols10cents
There are points I like much better in this proposal (using coveralls.io, favorite authors, etc), but I'm still pretty adamantly against the following points:

Using the LOC metrict for docs
Using ismaintained badges

I'll elaborate with some suggestions :wink:

returning to the LOC ratio of docs to code

This still doesn't give any metric of quality, really it doesn't tell me much of anything.
This also doesn't account for block doc comments using /** */
It doesn't account for blank lines, regular comments vs code (in the proposed metric regular comments, blank lines, non-public items, they all count towards lowering your score relative to doc comments.)
What about using doc comments on non-public items or instead of regular comments?
How does this account for wrapping at different column widths?

crates in the top 20% get a badge

Ranking peg against libc in documentation isn't helpful. This should be something like "top 10/20% of relevant crates (i.e. within the same category)." IMO

it'll be very obvious if people game it.

I very highly doubt you'll see lots of /// lol comments. Yes that would be easy to catch. Is this gaming though?
/// Spindles sporks rapidly
fn spork_spindler() {
    // snip
}

Could be ignorance of the author thinking that's adequate. I've been guilty of not fully explaining items because I'm super familiar with them and have a hard time knowing...well, what you don't know. 😜
What about wrapping at say 79 column width vs other numbers? Could be gaming, as Rust uses 100 column width. Could also be personal preference.
What about using doc comments on non-public items? Could be gaming. Could be a change in visibility. Could be just good documentation practice if something may become public. Could be someone misunderstanding doc comments (I did this at first). Could be just habit. It's also harder to catch because it won't show up in documentation.
Documentation suggestion
It's been said several times in these conversations, instead of automating, just use a simple checklist

#[deny(missing_docs)]
A readme
A license
Online documentation
# Examples in doc comments
examples/ in repo
tests/ in repo
Unit tests mods in repo

With a simple 6/8 Good Documentation Practices type badge/indicator. I haven't heard any problems with this over the currently proposed system.

We'll enable maintainers to add a badge from isitmaintained.com to show github issue activity

I'm just not a fan of this particular metric because it will incentivize closing issues quickly. I have issues up in my repos from inception as tracking issues, or simply ideas for the next major version bump. I also encourage people to ask questions in issues, which I'll leave open for a week or so in case others have the same question. I don't think closing issues quickly necessarily means maintained.
Since using this badge isn't mandatory it's obviously not too big a deal since I simply wouldn't have to use it. I just wanted to voice my concern with "closing issues quickly == maintained"

I love all the extra info about how other ranking systems or code repositories work too, I hadn't seen that for some reason before. Awesome!

It's been said several times in these conversations, instead of automating, just use a simple checklist
...
With a simple 6/8 Good Documentation Practices type badge/indicator. I haven't heard any problems with this over the currently proposed system.

How is this less gameable?

How is this less gameable?

It's less prone to the wrapping game, or using doc comments on non-public items. It doesn't increase incentives for an arbitrary metric (lines of docs) but instead encourages things we should be encouraging like deny_missing_docs, use of examples and tests, using a license and readme (with readme rendered on the crates.io page as you proposed). It also makes the concerns about block doc comments and other oddities moot.
Finally it's not necessarily ranking two crates docs as better or worse, simply saying "this crate follows more of our best practices than another." Which is more useful to me than ratio of docs to code.

It's less prone to the wrapping game, or

I could still create a blank README, blank examples, empty test modules and functions, add deny_missing_docs but add /// lol everywhere, etc. Also license is already required to even publish on crates.io so I don't think that should be part of this list.

Yes, but just like /// lol comments that's very easy to spot and report as abuse. The points I listed above when counting doc lines are less easy to spot or determine to be malicious.
To be clear, I'm not saying the list is perfect, there are issues with it as well. The license could be pulled out, it was just an example list. I just think there are fewer issues using a list like that and it's a better way to rate crates, IMO.
Also, please don't think I'm being short. I'm on mobile and GitHub comments don't convey emotion well. I'm still very, very greatful that you're working this hard issue! :smile:

To be clear, I'm not saying the list is perfect, there are issues with it as well.

I just found this comment to be a bit disingenuous:

I haven't heard any problems with this over the currently proposed system.

Also, please don't think I'm being short. I'm on mobile and GitHub comments don't convey emotion well. I'm still very, very greatful that you're working this hard issue! 😄

You're welcome. I'm sorry I'm being short, this has just been a long slog and seeing nuance and tradeoffs represented as not having any problems is frustrating.

The proposed way of judging docs has obvious shortcommings, but I think even that is already much better than doing nothing!
I presume nothing here is set in stone and we can tune it, e.g. use rustfmt and rustdoc to normalize and filter comments, add fudge factors and weights to better judge small vs large packages, and maybe even come up with text filtering and analysis to discount obviously useless content.

In my opinion having a low doc ratio in winapi is actually a benefit because it reduces the file size of the crate that you download!

I've noticed CocoaPods (ObjC/Swift package manager) has a concept of quality metrics: https://guides.cocoapods.org/making/quality-indexes (and trying to estimate readme complexity: https://github.com/clayallsopp/readme-score/blob/master/lib/readme-score/document/score.rb)
For each package you can see how it scores:
https://cocoapods.org/pods/CargoBay/quality

Whew! Thanks all, and especially @carols10cents, for the thoroughgoing discussion here. We've covered an enormous amount of ground, and while I've read the entire thread, it would be very difficult to summarize everything here.
This is clearly a very "bikesheddy" topic for which there are no easy or obviously "right" answers. But I think a key point, which @carols10cents has emphasized, is that there's not a deep commitment here; we can and should revisit whatever metric we choose on a regular basis, perhaps via the survey.
An important implication of the ability to iterate here is that we can mitigate concerns around "gaming the system" while taking a "wait and see" approach. That is, rather than arguing hypothetically about whether crate authors are likely to juke their stats by writing /// dox everywhere, we can see whether it happens much in practice, and take action accordingly.
More broadly, there have been many arguments about how accurate various metrics are as a proxy measure of quality, but in the end, (1) perfection here is impossible and (2) iteration and experience is key.
With all that said, and given the large number of design iterations we've already gone through, I want to propose moving forward with the current design. It is relatively straightforward to implement, provides reasonable objective measures, and does not introduce complications like voting systems. The initial goal here should be to get the "right" crate near the top of the list, so that someone shopping for a crate is likely to include it in their evaluation.
For the sake of the core team, some of whom I imagine haven't been following closely, let me summarize the current proposal:

Crate listings for keywords and categories are ordered by downloads in the past 90 days.

Gives some indication of popularity without overly favoring old/established crates.

Crate search remains ordered by relevance, though the "recent download count" will be added as a sort option.

We probably want to improve on this in the long run, but it's more complex.

Render the README on the crates.io homepage
Badge a crate as "well documented" if it's in the top 20% of crates measured by documentation level (a metric given in detail in the RFC).
Add self-reported "maintenance status" information, so that authors can clearly communicate expectations, e.g. "actively maintained" or "experimental".
Add badges from http://isitmaintained.com/ to give quantitative information about maintenance level.
Add badges from https://coveralls.io/ to measure test coverage.

The idea is to focus first on getting the most popular crates to show early in the results, and then to use badges to quickly convey a lot of basic information about the crate that can help guide you to a few to evaluate more deeply.
While I'm proposing to merge, I do want to mention that we should consider tweaking the listing order with search sooner rather than later; lots of people will begin by searching rather than looking at keywords or categories. (Relatedly, we should list categories and keywords that seem relevant to a search term at the top, to help guide people toward those listings).
@rfcbot fcp merge

One thing regarding documentation: I think another idea (forgive me if it's been covered) might be to check for #![deny(missing_docs)] and have that influence the score somehow. But regardless it makes sense to start somewhere and then tune as we see fit; it seems to me that the suggested metric is a reasonable place for such a start.

About the idea to sort the search results by some non relevance based metric: I'm not really sure this is a good idea. You can e.g. be searching for a "pure rust image decoder" and it might put winapi to the top, because it has most downloads and somewhere in its documentation it mentions "rust".
About the suggestion to show categories in search results, I personally find categories not very useful and don't want them to be shoved upon me when wanting to do a search. After all, search is not shoved upon you when you prefer to browse via categories!

@est31 Indeed, if we were to incorporate other metrics we'd need to carefully balance. That's part of why it seems wisest to start with the RFC as proposed, gain some experience with the new metrics and badges, and then see how best to further integrate the data.
Regarding showing categories, I think we can do so in an unobtrusive way. But again, that's something we can tackle later on.

Since we're starting with the proposed metrics, what are the thoughts/possibility of making this slight change?
To count docs use: $ tokei src/ | rg 'Rust' | awk '{print $5}'
To count code use: `$ tokei src/ | rg 'Rust' | awk '{print $4}'
This gives some big benefits but still retains the proposed metrics. The biggest two gains are:

This correctly includes /*!    */ style comments which several very prominent crates use, whereas the system as proposed would exclude them, hurting the docs score.
This only counts lines of Rust code (not blank lines, integration tests, benches, etc) giving a more accurate count

With this method, here's how the scores would look:

combine:

1,475 lines of documentation
105 lines in README.md
3565 lines of Rust
(1475 + 105) / 3565 = 1580/3565 = .44

nom:

2,930 lines of documentation
374 lines in README.md
9,870 lines of Rust
(2930 + 374) / 9870 = 3354 / 9870 = .34

peresil:

180 lines of documentation
20 lines in README.md
808 lines of Rust
(180 + 20) / 808 = 200/808 = .25

lalrpop:

12,627 lines of documentation
116 lines in ../README.md
45,073 lines of Rust
(12627 + 116) / 45073 = 12743/45073 = .28

peg:

3 lines of documentation
214 lines in README.md
820 lines of Rust
(3 + 214) / 820 = 217/820 = .27

Downsides

Counts regular comments (although this should be a very small number in comparison), but I believe it's still far more accurate
Still counts unit tests, but the proposal as it stands does this also
Doesn't count `examples/, but should these be counted towards code (negatively affecting score), or docs (positively affecting score)? This could be added though.

tokei is a Rust tool for counting lines of code and comments very fast.

I've downloaded every crate on crates.io (latest verion of the crate) and run them through the above two methods.
The raw results as well as the top 20% for each method can be seen here.

The results have been fixed, and sorted by name to make things easier to find. I've also added a diff. I'd recommend using xsv (an amazing CSV tool) to play with the data.

README.rst scores zero :-1:

There is a lot of things going on in this thread, and I doubt we can agree on a manually designed algorithm, so I propose using machine learning.
Here's the approach I'm thinking of:
When a person uploads their first crate, cargo will prompt them for being a survey respondent. If a crate lacks of some number of survey responses and the user depends on it, the user will be prompted prompted with a simple scale (say 1-100) of how good a crate is in total (considering documentation, API, etc. etc.).
This scale is trained against the data points of the crate in a neural network (or maybe just basic regression). Following points are considered:

Time it takes to close issues.
Number of tests.
% comments
% documentation
Number of unique downloads (tracked through a bloom filter to improve anonymity).
Number of reverse dependencies.
Average rating of reverse dependencies.
Number of dependencies.
Average rating of dependencies.

and so on.
The crate's rating is then produced based on the NN trained on this data set (data points → survey) and the score is represented as a number, maybe or maybe not expoosed to the user, but certainly used in search ordering.

Trying to solve this with machine learning with training based on the rating sounds like a good idea, although I do think we should take different points for consideration. For example, test coverage is a far better (still not perfect) metric for number of tests, as I prefer to do large tests with multiple test cases inside, and about the time it takes to close issues, its a bad metric as well, as most projects track their feature requests as open issues (htop I think does not, they close every feature request immediately). Also, evil maintainers can just stick the NOTABUG label onto valid issues and they would be rewarded. % comments and % documentation sounds some good metric, but obviously sometimes code is self explaining, and I prefer that to code that puts all explanation into the comments.
Number of downloads is skewed towards already working crates.
I'm not familiar with ML, but can we feed the entire source code of the crate to the network somehow and then let it predict the rating?

@est31
The whole point of ML is that you don't have to worry about ANYTHING of that. Etablishing the correlation between say lines of test and survey response is entirely automatic. Same goes for number of downloads: It shouldn't be biased as it is all about rating.
For sorting properly, you could use unique downloads times the rating or something like that.

I am opposed to adding machine learning; it's way too complex to implement and maintain. Furthermore, the results will be hard to understand.

@ticki What if we simply used the user's survey results directly instead of passing it through a machine learning filter?

@retep998 That would mean that it's imossible to score new or small crates, as they have no or few users.

Yeah, survey is going to be a sparse dataset, so it's not usable directly. However, it still could be useful for evaluation and tuning of ranking metrics. It's probably a separate research project, outside scope of this rfc.

I think we should at least provide a way for users to provide input on the ranking of crates. Even if we don't display that information, we can aggregate it and analyze it and decide what to do in the future.

Like @carols10cents I'm strongly opposed to using ML. It's difficult to get right, it's difficult to maintain, and for the amount of resources the Rust community has, it's not worth the time nor do we have a decent data set for it. It's not some magic bullet that a lot of people think it is and it's not as easy as dumping data into a neural net to learn.

@mgattozzi I'm not claiming it's a magic bullet in any way. I agree it's hard, but I believe it's easier than the manual approach.

Please open a new RFC if you'd like to propose adding machine learning to recommend crates; I won't be changing this RFC to add it.
@retep998:

I think we should at least provide a way for users to provide input on the quality of specific crates. Even if we don't display that information, we can aggregate it and analyze it and decide what to do in the future.

I'm not going to spend time implementing and maintaining a data collection mechanism if we don't have a specific use for that data :-/

To echo what others have said, machine learning would constitute an entirely separate proposal, with a lot of its own complexities and downsides. As I emphasized in the motion to FCP, we can and should take an iterative approach here, and the RFC as it currently stands is something relatively straightforward to implement, that we can land within the constraints of this year's roadmap. I think it's also a clear improvement over the status quo, and has been through a number of rounds of iteration in this discussion.
The RFC includes extensive research, both in terms of prior art, and in terms of what the Rust community specifically values. It also lays out several assumptions/design constraints at the outset. After these many rounds of discussion, I personally think it's reached a quite reasonable point in the design space balancing between the goals suggested by the research, technical feasibility for a first-cut implementation, and various concerns about gaming and proxy measures.
In the interest of trying to drive things toward some kind of conclusion here, I think it's best to keep discussion to any final concerns about (1) the takeaways from the research or (2) the proposed design, in terms of its balance between the research-derived goals and what makes sense to try in a first-round effort here.

Thanks @carols10cents for the great (and much needed) RFC!
This is a really long thread, so I just wanted to post a few links to the summary posts scattered therein for those just reading the thread now (like me)...
@ruuda's comments here and here summarize the majority of the thread pretty well, I think.
@aturon's FCP summary of the RFC is here.
I was also intrigued by scattered proposals to take influence from ranking systems already in common use, such as Amazon, StackOverflow, and GitHub stars/trending. I won't bikeshed here, but I think these are worth considering for inspiration as this goes through iterations...

If the goal is that "Rust should provide easy access to high quality crates" then badges and ranking are really just bells and whistles. The guts of the problem is to find a way to present information about all relevent crates so that a potential user can evaluate them easily. If the front page of crates.io had a keyword search that produced a list, ranked by the last 90 days downloads, with a a five line explanation drawn from the top of README.md, this would be ideal for me. The keyword search might give me 10 or 20 options, and at 5 lines each it would be much trouble at all to scan through. The first 5 lines would probably give a good general indication of quality of the documentation.

The rendered RFC only talks about Coveralls. I personally have had a lot of issues with Coveralls configuration and recently have moved to Codecov in all my projects. They even provide Rust templates, and of course, badges.

@Razican

The rendered RFC only talks about Coveralls. I personally have had a lot of issues with Coveralls configuration and recently have moved to Codecov in all my projects. They even provide Rust templates, and of course, badges.

Interesting! I didn't know about Codecov. The implementation will definitely be extensible-- for example, someone sent in a PR to add a badge for GitLab CI status to go along with the Travis and Appveyor badges, and it was a pretty straightforward change.

Huzzah! This RFC has been merged, and is tracked here. As has been emphasized throughout, this design is a starting point, and we'll expect to do follow-up evaluation and iteration.
Thanks everyone who participated in this in-depth discussion, and especially @carols10cents for writing such a thoughtful RFC and sticking it out through 258 comments :-)

Couple of thoughts. A crate should receive a higher score based on the number of other crates on crates.io that depend upon it. A create should receive a lower score based on the number of other crates it depends upon. Depending on lower-ranked vs higher-ranked crates should have a larger negative impact on a crate's rating. Having higher-ranked crates vs. lower-ranked crates depending upon a crate should have a larger positive impact on the ranking of the crate.

That would be really biased in favor of libraries and against binaries.
On Jun 4, 2017 12:52 AM, "Gerald E Butler"<EMAIL_ADDRESS>wrote:

Couple of thoughts. A crate should receive a higher score based on the
number of other crates on crates.io that depend upon it. A create should
receive a lower score based on the number of other crates it depends upon.
Depending on lower-ranked vs higher-ranked crates should have a larger
negative impact on a crate's rating. Having higher-ranked crates vs.
lower-ranked crates depending upon a crate should have a larger positive
impact on the ranking of the crate.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1824#issuecomment-306018241, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIazwF43X093pjJTaOz6w2Bjfi7f36b-ks5sAjgkgaJpZM4LRJMT
.

Those two categories should be separate anyway. Unless you are searching the database just for fun, you either want specifically a library, or specifically an application.

But the score interaction would have to be broken up by individual influences, or otherwise stratified. Naive implementation could lead to nasty feedback cycles.

@gbutler69
Note that this RFC has already been merged. And it's not clear where re-evaluation and iteration discussions are going to take place (probably not here in this PR).

A crate should receive a higher score based on the number of other crates on crates.io that depend upon it.

Agreed.

A create should receive a lower score based on the number of other crates it depends upon.

This will encourage bad practices:

Copying code from other crates instead of depending on them.
Re-implementing functionality available in other crates poorly.

In other words, this will encourage people to work against the crate ecosystem, not work with it.

Depending on lower-ranked vs higher-ranked crates should have a larger negative impact on a crate's rating.

Again. This will encourage bad practices. For example, this will discourage people from releasing modular crates. Fearing the lower-level crates will have a low-score which will reflect poorly on the higher-level ones.

Having higher-ranked crates vs. lower-ranked crates depending upon a crate should have a larger positive impact on the ranking of the crate.

Could be useful. But this might have complex interactions with other factors. And the implementation details are not clear. For example:

Should the average score of all dependants be considered?

Or just the top 5?
Or just the one with the highest score?

Should there be a minimum number of dependants for this factor to be considered?

What is that number?

How much weight should be given to this factor?
Should a high-ranking dependant stop depending on foo, how much of a negative impact should foo suffer based on that event alone?

I think the straight forward factors I took into consideration in cargo-esr are enough to paint a rough picture of how much a crate is relevantly depended on.

Note that this RFC has already been merged. And it's not clear where re-evaluation and iteration discussions are going to take place (probably not here in this PR).

Yes, since this RFC has been merged, large changes proposed to this should get a new RFC. Small changes can be proposed in an issue on crates.io's repo, and the re-evaluation and iteration discussions will probably take place on crates.io's repo as well.
I'm unsubscribing from this thread, thank you all for your discussion!


CI commit message check

Is your feature request related to a problem? Please describe.
Try to add commit message check for each pr.
Describe the solution you'd like
https://www.kubernetes.dev/docs/guide/pull-requests/#commit-message-guidelines

Try to keep the subject line to 50 characters or less; do not exceed 72 characters
Providing additional context if I am right means formatting in topic: something
The first word in the commit message subject should be capitalized unless it starts with a lowercase symbol or other identifier
Do not end the commit message subject with a period
Add a single blank line before the commit message body

Describe alternatives you've considered
n/A
Additional context
@SamYuan1990, could you try following the Kubernetes commit message guideline?
https://www.kubernetes.dev/docs/guide/pull-requests/#commit-message-guidelines
It's good to provide meaningful messages with context!
Originally posted by @marceloamaral in https://github.com/sustainable-computing-io/kepler/issues/215#issuecomment-1253419614

https://github.com/GsActions/commit-message-checker


Fix a spelling error in ssl.h

"certifiate" should be "certificate".
This change fixes linking when the deprecated SSL_get_per_certificate() is in use.

https://github.com/openssl/openssl/pull/12468 :-)

I will close this as a duplicate.. (Only because it has a higher number than #12468.
Thank you for trying to fix it though.


Fixed a bug that caused the read thread to exit prematurely.

In the function TMQTTReadThread.SocketWrite, the data is passed to the socket instance immediately, the socket is sometimes not ready for this, particularly when the thread first starts and the client is trying to send the CONNECT command. The socket doesn't write any bytes and so the FPSocket^.SendBuffer function returns 0. This is then checked against the number of bytes going in and found to be different and so the worst is assumed and the thread stops as it thinks there is an error.
My quick solution is to have the SocketWrite function wait for the socket to be capable of writing before sending anything. The code I have added checks to see if the socket is writable every 100ms until it is. (It will execute immediately if the socket is already ready as it is a 'while' loop and not a 'repeat until'.)
I don't know if this will cause problems such as hanging if a socket is genuinely permanently unwritable. A timeout may need to be implemented if this is the case.
Commit message: "Added code to wait for the connection to be usable before sending any data (This stopped my read thread from exiting without doing anything all the time)"
DanielJABailey.

A big  thank you  for this  pull request. Sorry to be so long in dealing with it.
Somehow the problem of sending data to the socket when it is not properly connected was not an issue when we tested this originally. Certainly became a problem on my Debian Jessie amd64 system. Since   then we have only used this code between multiple services running on the same machine as mosquitto where it  never failed to start correctly.
Also recently the issue of receiving from a disconnected socket started to bite us for the first time.
We will be ding more testing on this.
Thanks again.

Thanks for merging!
I had forgotten about this, it's nice to see pull requests accepted, even if it's three years later. :-)
Glad I could help.

Looking at it now it seems your fix for the send to a partially open socket makes my fix for the connect startup problem redundant!

waitFor is effectively a blocking version of Terminate.
But "waitFor" does not set the "Terminated" flag.
"WaitFor" waits until the thread ends for internal reason.


Card display issue + Lock Not Responding

Please check existing (open or closed) issues before creating a new one. (https://github.com/fuatakgun/eufy_security/issues?q=is%3Aissue+)
If this is not an issue, you can use Discussions (https://github.com/fuatakgun/eufy_security/discussions) section.
Did not see any related issues.
Describe the bug
When clicking on a "camera card" in any of my dashboards, no stream is started, and thus I can't stop it and receive a thumbnail.
To reproduce
Steps to reproduce the behavior:
Using the "camera card" setup we discussed previously on a dashboard, click the grey camera image (in this case Doorbell, showing a state of Idle). In the past, this would then start the stream, which after what seems like 5-10 seconds, you could stop and then receive a thumbnail to replace that grey camera image.
Expected behavior
Clicking the grey camera image to start the stream.
Additional information
Go to Settings -> System -> Repairs -> Click on 3 dots (...) -> System Information and get Version and Installation Type to below fields;

Home Assistant Installation Type (OS - Supvervised - Core):  Supervisor 2022.12.1
Home Assistant Core Version:  Home Assistant 2023.1.5 // Operating System 9.4
Eufy Security Add-on Version:  1.3.0
Eufy Security Integration Version:  6.2.0

Hardware Information;

Camera Model:
It's applicable to both my T8200 and my T8422

Live Streaming Protocol (RTSP/P2P):
I believe P2P?

Debug Logs from Home Assistant (https://github.com/fuatakgun/eufy_security/discussions/624)
None created.

Logs from Eufy Security Add-on (either from Add-ons page of Home Assistant or Docker output):

2023-01-19 17:09:16.130  INFO  Eufy Security server listening on host <IP_ADDRESS>, port 3000
2023-01-19 17:09:21.247  ERROR MQTT Error
 Error  Connection refused: Not authorized
details:
{
  code: 5
}
error stack:
• client.js:1388 MqttClient._handleConnack
    node_modules/mqtt/lib/client.js:1388:17
• client.js:549 MqttClient._handlePacket
    node_modules/mqtt/lib/client.js:549:12
• client.js:438 work
    node_modules/mqtt/lib/client.js:438:12
• client.js:452 writable._write
    node_modules/mqtt/lib/client.js:452:5
• _stream_writable.js:409 doWrite
    node_modules/readable-stream/lib/_stream_writable.js:409:139
• _stream_writable.js:398 writeOrBuffer
    node_modules/readable-stream/lib/_stream_writable.js:398:5
• _stream_writable.js:307 Writable.write
    node_modules/readable-stream/lib/_stream_writable.js:307:11
• readable:754 ondata
    node:internal/streams/readable:754:22
• node:events:513 emit
    node:events:513:28
• readable:315 addChunk
    node:internal/streams/readable:315:12
2023-01-19 17:09:21.263  INFO  MQTT connection closed
2023-01-19 17:09:26.621  INFO  Connected to station T8422N1021151309 on host <IP_ADDRESS> and port 25359
2023-01-19 17:09:26.636  INFO  Connected to station T8200N00210315E4 on host <IP_ADDRESS> and port 13929
2023-01-19 17:09:28.626  INFO  Connected to station T8520Q202213029F on host <IP_ADDRESS> and port 10654
2023-01-19 17:09:36.366  INFO  Push notification connection successfully established
2023-01-19 17:09:58.859  INFO  Initiated closing of connection to station T8520Q202213029F for saving battery.
2023-01-19 17:09:58.865  INFO  Disconnected from station T8520Q202213029F
2023-01-19 17:14:30.946  INFO  Client disconnected with ip: <IP_ADDRESS> port: 59132 code: 1006 reason: Abnormal Closure

Would you share your device with me in case further debugging required? (Yes/No):
Yep - it's still shared to you, actually.

Additional context
  - type: custom:layout-card
    layout_type: custom:grid-layout
    layout:
      - height: 350 px
    cards:
      - type: conditional
        conditions:
          - entity: camera.doorbell
            state: idle
        card:
          show_state: true
          show_name: true
          type: picture-entity
          entity: camera.doorbell
          camera_image: camera.doorbell
          tap_action:
            action: call-service
            service: camera.turn_on
            data: {}
            target:
              entity_id: camera.doorbell
      - type: conditional
        conditions:
          - entity: camera.doorbell
            state: streaming
        card:
          type: vertical-stack
          cards:
            - show_name: true
              show_icon: false
              type: button
              tap_action:
                action: call-service
                service: camera.turn_off
                data: {}
                target:
                  entity_id: camera.doorbell
              entity: camera.doorbell
              name: Stop
            - type: custom:webrtc-camera
              entity: camera.doorbell

That's how the cards appear on my dash.  They were working as expected when we initially set them up...2-3 weeks ago.

Updating this (and changed the title) because I'm now having an issue with Keyless Entry (T8520). Pressing the lock (or unlock) button from either a card or the integration itself is not doing anything (read: the door is not locking or unlocking). That being said, it is seeing when the door is manually locked or unlocked (or I do so through the Eufy app) and in the case where I have automations tied to it being locked, are running those accordingly.
Given that this is the one element that has been working all along, this is a bit distressing, because I've come to rely on it so heavily.

which version of webrtc you are using? v3 does not seem to play well, so use 2.3.1
moreover, add-on is generating not authorized error, please reach out to @bropat over eufy-securit-ws , he can help

I had v3 (I was on the beta), but downgraded to 2.3.1 and it did not make a difference. Perhaps I need to delete the addon entirely, then reinstall at 2.3.1 and see if that helps?
Will reach out to @bropat ...but any thoughts on why my lock is no longer working?

@fuatakgun ... just saw the following error in my logs tonight:
This error originated from a custom integration.
Logger: custom_components.eufy_security.eufy_security_api
Source: custom_components/eufy_security/eufy_security_api/p2p_stream_handler.py:107
Integration: Eufy Security (documentation, issues)
First occurred: 10:49:30 PM (2 occurrences)
Last logged: 10:49:46 PM

Exception [Errno 104] Connection reset by peer - traceback: Traceback (most recent call last): File "/config/custom_components/eufy_security/eufy_security_api/p2p_stream_handler.py", line 103, in setup client_socket.sendall(bytearray(self.camera.video_queue.get())) ConnectionResetError: [Errno 104] Connection reset by peer

So, my card issue is resolved - believe it or not, it wasn't resolved by WebRTC, but the RTSP Simple Server Add-on.  Somehow, start on boot had gotten turned off. I fixed that and the cards have been behaving since.  The locks also appear to be working.
So I guess I can close this at this point.


Test coq-menhir

Closing as it is subsumed by https://github.com/coq-community/coq-nix-toolbox/pull/249


SakulFlee/issue109

Closes #109

try to understand the changes.

removed
<PackageReference Include="SIPSorceryMedia" Version="3.0.2" />
<PackageReference Include="SIPSorceryMedia.Encoders" Version="0.0.12-pre" />


Table with 2 unique fields cant be created.

Description
Hello. If i create table with 2 fields with unique constrant, DBeaver makes 2 constraints with same names - [tablename]_un. Names duplicate break a table creation process. I must go to editor, fix SQL (_un, _un1) and run in manually.
DBeaver Version
Community Edition 23.2.5
Operating System
Win 10
Database and driver
MariaDB  11.1.3
Steps to reproduce

Create new database
Create new table
Add two any fields
Go to constraints and create 2 unique keys.
Click "Save", view SQL (duplicate un names), run, see error.

Additional context
No response

Hello @hvprvtr
Thanks for the report.
Probably we can improve this behavior.


Bug fixes

Please check if the PR fulfills these requirements:

[X] After these changes, the app was run and still works as expected
[X] Tests for these changes were added (if applicable)
[X] All existing unit tests were run and still pass

Please specify the type of change this PR introduces (Bug fix, feature addition, content update, chore, etc.):
Covers tickets CLMWEBDE 114-119 and 121
--adds required/optional to the end of fields as needed, code now checks if route is CSR to determine this
--forces Diagnostic Code to only accept uppercase input
--name validators made specifically optional to prevent errors on blur/field clear
--submission page now only shows next steps if public page (not on CSR)
--coveragePreAuthNumber now only runs minimum length validator if it's a public page (not CSR)
--updated tests to match new requirements
Additional Notes:

Yes, Dor asked that it be there. It seemed easier to mark the first field as required on the CSR page than to go mark every single other field on the page as optional. So the "optional" for those other fields only displays on the public page and not on the CSR page


Display torrent ETA in list item

Adds the estimated time to download completion of the torrent (Hours Minutes Seconds) in the torrent's status.

Otherwise LGTM! Thanks for doing this


The script can remove needed dependencys

From the uninstall code:
if [[ "$OS" = 'debian' ]]; then
	apt-get remove --purge -y openvpn
else
	yum remove openvpn -y
fi

And this happens no matter if openvpn was installed before using openvpn-install.sh. And thus could possible be a dependency of any other vpn provider or similar.

If user selects the option Remove OpenVPN, then the script will assume that the user really wants to remove OpenVPN. I don't think that is unexpected.


Using the builder

Hi guys,
I looked at the builder last month, but is it still working with the latest release?
It looks like it fails on building?
i can share a console dump if you like.
Regards,
Stefan

Fixed :) still working but needed to install ant on my mac


Can't install Zabbix-Grafana plugin because of expired certificate

Describe the bug
grafana-cli plugins install alexanderzobnin-zabbix-app
installing alexanderzobnin-zabbix-app @ 3.10.4
Error: ✗ Get https://codeload.github.com/alexanderzobnin/grafana-zabbix/legacy.zip/29a98f555ae4f0ad5dab6388b23929e32f0b47aa:
x509: certificate has expired or is not yet valid

From curl's output:
< Expires: Mon, 09 Sep 2019 03:31:33 GMT

Please update certificate.
P.S.: and use Zabbix to monitor it. :)

$ curl -v https://codeload.github.com/alexanderzobnin/grafana-zabbix/legacy.zip/29a98f555ae4f0ad5dab6388b23929e32f0b47aa
*   Trying <IP_ADDRESS>:443...
* TCP_NODELAY set
* Connected to codeload.github.com (<IP_ADDRESS>) port 443 (#0)
[..]
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.com
*  start date: Jul  8 00:00:00 2019 GMT
*  expire date: Jul 16 12:00:00 2020 GMT
*  subjectAltName: host "codeload.github.com" matched cert's "*.github.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.

Perhaps your endpoint for codeload.github.com served the wrong certificate. It helps debugging your issue when supplying all information from the curl request you did, not just the expiry date.
Either way, this does not seem to be an issue the maintainer can solve for you.

I don't own github.com unfortunately, so can't update cert, so I think it makes little sense to monitor it with Zabbix.


Consider merging "Usage" and "Scripts" into a single documentation entry

Motivation for the feature
Currently, the CLI script "ivadomed" is under "Usage", while the other CLI scripts are under "Scripts". I find this distinction is confusing and suggest to simply merge all CLI scripts under a section called "Command-Line Tools" or simply "Usage".

Further suggestions on this are here and here.


Split general contractions into blocks whenever possible

This pull request makes the BSE split general contractions into blocks whenever possible.
For example, if the contraction pattern looks like
x x x x 0 0
x x x x 0 0
x x x x 0 0
x x x x 0 0
0 0 0 0 y y
0 0 0 0 y y

this will be identified by the code, and the general contraction will be split into two shells, consisting of the x and y entries, respectively.
A special case of the procedure concerns completely free primitives
x x x x 0 0
x x x x 0 0
x x x x 0 0
0 0 0 0 y 0
0 0 0 0 0 z

which will from now on not be included in the generally contracted shell; instead, they will be contained in their own shells.
The PR doesn't have any functional changes, since the output formats will still act exactly the same: formats that employ general contractions will show the blocked contractions, whereas formats employing segmented contractions are already omitting any zero entries.
The main reason for the PR is to improve curation tools: identical basis sets are now detected as identical, since the placing of e.g. free primitives as a dummy part of the contraction pattern vs as one-function shells does not affect how the BSE treats the functions internally. The new convention may also slightly reduce storage costs, since zero entries don't need to be stored.

Codecov Report

Merging #199 (7bb517b) into master (32721c8) will increase coverage by 0.10%.
The diff coverage is 96.66%.


[SpecHelper] Reset settings

Probably closes https://github.com/bundler/bundler/issues/3607.

Ping @indirect ?


chore: handle file URLs in dynamic imports

Summary
Not sure if a startsWith is the best, but it works 🤷

Test plan
Test added

"Best" is probably trying to parse as URL and looking at .protocol ^^

Node doesn't support any other protocol than file for now, but we probably should be more future proof yeah - I just don't know a good way to separate between relative paths, absolute paths (both unix style and windows) and URLs


Games not working

When I play a game, this happens:

The page needs to be reloaded. Also make sure to wait a few seconds before closing the app store or installing another app, because it takes time to download.


[tests-only] [full-ci] Bump core commit id

There are a lot of trashbin tests that are now failing. I need to look at what I did with the trashbin PROPFIND test code in core, and see if it is a problem with the test code, or if the test code is now more strict and something does not work...


Can not retry，when broker is busy

BUG REPORT

Please describe the issue you observed:

What did you do (The steps to reproduce)?
In production enc, Because of disk IO trggers broker flow control

What did you expect to see?
I think when a broker is busy, producer can retry send message to another broker

What did you see instead?
org.apache.rocketmq.client.exception.MQBrokerException: CODE: 2  DESC: [TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in queue: 204ms, size of queue: 0 For more information, please visit the url, http://rocketmq.apache.org/docs/faq/ .....

Please tell us about your environment:
RocketMQ 4.5.2
Centos 6

Other information:
I fix it:
class:   org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl
method: sendDefaultImpl
code snippet is below: bold text is my code
catch (MQBrokerException e) {
endTimestamp = System.currentTimeMillis();
this.updateFaultItem(mq.getBrokerName(), endTimestamp - beginTimestampPrev, true);
log.warn(String.format("sendKernelImpl exception, resend at once, InvokeID: %s, RT: %sms, Broker: %s", invokeID, endTimestamp - beginTimestampPrev, mq), e);
log.warn(msg.toString());
exception = e;
switch (e.getResponseCode()) {
case ResponseCode.TOPIC_NOT_EXIST:
case ResponseCode.SERVICE_NOT_AVAILABLE:
case ResponseCode.SYSTEM_ERROR:
case ResponseCode.NO_PERMISSION:
case ResponseCode.NO_BUYER_ID:
case ResponseCode.NOT_IN_CURRENT_UNIT:
case ResponseCode.SYSTEM_BUSY:	//Retry is required when the flow is triggered
continue;
default:
if (sendResult != null) {
return sendResult;
}
                         throw e;
                 }
             }

Hi  you can try this parameter
  /**
     * Indicate whether to retry another broker on sending failure internally.
     */
    private boolean retryAnotherBrokerWhenNotStoreOK = false;

Hi you can try this parameter
  /**
     * Indicate whether to retry another broker on sending failure internally.
     */
    private boolean retryAnotherBrokerWhenNotStoreOK = false;

When return System busy, It means to trigger broker flow control, the sended message is abandoned.
Client side will throw MQBrokerException, it can not retry.

IMO, SYSTEM_BUSY indicate broker is busy, retry send would weight broker load. Customer can select waiting a moment, then resend message. I think it will be a better choice.

IMO, SYSTEM_BUSY indicate broker is busy, retry send would weight broker load. Customer can select waiting a moment, then resend message. I think it will be a better choice.

when the problem happens, there is no press at all. I fix it with retry。and try to find internal reason


Add logging

Consider adding logging to ObservableStore. Expose as configuration flag during initialization.
Motivation: One of the key values of ObservableStore is ease-of-debugging. Since state is a deterministic function of actions, logging actions can provide deep insight into what is happening within the system.
What to log:

actions
state (maybe)

Requirements:

We want to be able to distinguish between logs from multiple stores

Possible approaches:

Supply logger in init. If there, it gets used.
Have logger, but allow customization of subsystem and category

Notes:

Use String(describing:) to get a CustomStringConvertible

Fixed in #43


Screensaver utilizing too much CPU

Find an alternative for the existing one. Only use a black background for now

Fixed in https://github.com/K2InformaticsGmbH/dderl/commit/4a4384781a808d3ec7d8ffcc4dde636fc506b8ed


Handle host function calls the same as other instructions in the Wasmi executor

Currently the Wasmi executor treats host function calls different to any other Wasmi bytecode instruction execution. The reason for that is simple: In order to invoke host functions the executor needs to know about the generic host state type T of the Store<T>.
One design principle of the current Wasmi executor is to make it non-generic and thus we introduced the non-generic StoreInner and made the Wasmi executor work on it instead of Store<T>. The obvious downside is that we need special treatment for host function calls which is ugly. Also it necessitates returning a large struct from the Wasmi executor which is not perfect for the optimizer to handle well and might be the performance issue we see on some platforms.
As an aside this refactoring will also greatly help if we are ever going to use tail call dispatch for the Wasmi executor once explicit tail calls become a thing in Rust.

I performed some local benchmarks with an experimental branch that simply removes host function calls and all their related handlers in the Wasmi executor to emulate what would happen if we were to implement this PR naively. The benchmarks showed no significant change indicating that either the experiment is flawed or that the optimizer can do a good enough job to reduce both cases to roughly the same assembly via aggressive inlining etc.
Further investigation needed.
The experimental branch can be found here: https://github.com/wasmi-labs/wasmi/tree/rf-experiment-host-fn-calls-nop


clarify build/test instructions

I think the readme could use some extra words on what packages are needed for compiling as well as running the tests. For example; even though I already had a basic toolchain I still had to apt-install libgtest-dev.
While having that installed I still couldn't run the tests. I navigate to the /tests/ directory and run make test but still get greeted by error's due to libgtest_main.a, libgtest.a and libgmock.a not being found.
I eventually to navigated to the individual folders /tests/libgtest/googlemock/, /tests/libgtest/googletest/ and ran cmake . && make and then update the Makefile to point to the right build location (as I don't have a /build/) folder. I'm probably doing something wrong here, but it's not obvious what the correct steps are to building this project.

Thats right,I'll create a 'make vendor' script,to configure tests library. And remember user regarding lgmp

👍

Created a Build Instructions settings @ixje including a make vendor command.
You can do: make vendor and make test, directly on root folder now.


Use AsyncReadExt::read_exact, not just read

Using read_exact will return an error if the EOF happens before the expected handshake length, and is therefore more... exact.

bot merge


raftstore: Integer overflow problems on memory metrics

Bug Report

What version of TiKV are you using?

$./tikv-server --version
TiKV
Release Version:   6.0.0-alpha
Edition:           Community
Git Commit Hash:   ce39ef6b52a050c594b2b01e8d60a6e11853faec
Git Commit Branch: fix-log-entry-oom-t
UTC Build Time:    2022-03-14 11:39:21
Rust Version:      rustc 1.60.0-nightly (1e12aef3f 2022-02-13)
Enable Features:   jemalloc mem-profiling portable sse test-engines-rocksdb cloud-aws cloud-gcp cloud-azure
Profile:           release
What operating system and CPU are you using?

Steps to reproduce

sysbench insert

What did you expect?

no overflow.

What did happened?

The metrics on raft messages overflow.
master of 0314 + trace log

/type bug
/severity critical
/assign @tier-cap


Update MailerLite Stats extension - cache through useFetch (remove node-fetch)

Description

Cache Responses through useFetch
Show EmptyView when no "Campaigns"
Add extension "Categories"

Screencast
N/A as it's from a travel platform I manage so has campaigns that are in progress.
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Thanks @xmok for contributing to the extension!


Fixed RTL navigations

This is due to #774

Changes Unknown when pulling eb7dbf7730e2b2bfe1e01f98443af6f183b79f64 on sag1v:patch-1 into ** on airbnb:master**.

Hi @sag1v, I think we'll have to update the phrases that get read out by the screen reader as well. Do the keyboard shortcuts still make sense with this update?

Hi @majapw, what do you mean by keyboard shortcuts? Iv'e only updated the logic inside the switch statement of the key press for right and left arrows, if we on RTL then the next focused day is calculated in reversed

Coverage remained the same at 86.784% when pulling 126ab2d8e6f98f65d3bc5e809e575f6c5a755a14 on sag1v:patch-1 into a448352014d51f35110f1abd0924e8fe330a7840 on airbnb:master.

@majapw Any further thoughts about this PR?

Also, please rebase on the command line so as to remove any merge commits :-)

@majapw

Can you also update the Home and End shortcuts?
What kind of update? Home & End  are not affected by RTL as far as i know

Coverage decreased (-0.1%) to 86.681% when pulling 5e1c9b0cb77e7421613d439bd4aae84d95d877b5 on sag1v:patch-1 into a448352014d51f35110f1abd0924e8fe330a7840 on airbnb:master.

Ah, you’d have to clone your fork and rebase your branch there. No worries tho, we can do it for you prior to merging.

@sag1v While on keyboards that have a home and end button, i agree that it's not as much of an issue, but on keyboards where the functionality is forced by fn + left or fn + right, it feels like it might make sense to switch them?
It might be a minority of keyboards for those accessing the RTL version of the datepicker, so maybe it doesn't make sense and home pointing to beginning of the week/end pointing to the end of the week is fine.

@majapw Thanks, i see your point. If there is anyway to determine if a Home or End buttons aren't available then we can write the condition for that. Otherwise i think we should merge this PR to at least support the Arrow keys on RTL until  we can find a way to support fn + Arrows.

I believe on a Mac, fn + left/right is indistinguishable from "home"/"end"?

@ljharb

I believe on a Mac, fn + left/right is indistinguishable from "home"/"end"?

It seems it's not that different than other brands:

Coverage decreased (-0.1%) to 86.718% when pulling eb8fef65620461dabe921c0ab1f0adc4abf82a04 on sag1v:patch-1 into 145f33aa4ec2da79e4f4010cd3a1b5dcb0203c27 on airbnb:master.


Validate Oracle Linux 7.9 and 8.2

Validate Oracle Linux 7.9 and 8.2
Docker 19.03.x

Deploy downstream clusters using Oracle Linux 7.9 and Docker versions: 19.03.x
Deploy downstream clusters using Oracle Linux 8.2 and Docker versions: 19.03.x
Deploy HA setup ; local cluster running on Oracle Linux 7.9 and Docker version: 19.03.x
Deploy HA setup ; local cluster running on Oracle Linux 8.2 and Docker version: 19.03.x

Validated Oracle Linux 7.9 on rancher\rancher:v2.5-head version cc777eb
Docker versions: 19.03, 19.03.11

Validated Oracle Linux 8.2 on rancher\rancher:v2.5-head version cc777eb
Docker versions: 19.03, 19.03.11
Installed docker with:
 curl -L https://releases.rancher.com/install-docker/19.03.sh | sh
 curl -L https://releases.rancher.com/install-docker/19.03.11.sh | sh


Unable to install mystbin.py via git

Summary
when I try to install mystbin.py via git, it fails with a error
Reproduction Steps

run pip install -U git+https://github.com/PythonistaGuild/mystbin-py.git
observe the error

Minimal Reproducible Code
C:Users<my name>>pip install -U git+https://github.com/PythonistaGuild/mystbin-py.git

Collecting git+https://github.com/PythonistaGuild/mystbin-py.git
Cloning https://github.com/PythonistaGuild/mystbin-py.git to c:users<my name>appdatalocaltemppip-req-build-jhnvnus7
Running command git clone --filter=blob:none --quiet https://github.com/PythonistaGuild/mystbin-py.git 'C:Users<my name>AppDataLocalTemppip-req-build-jhnvnus7'
remote: Repository not found.
fatal: repository 'https://github.com/PythonistaGuild/mystbin-py.git/' not found
error: subprocess-exited-with-error

× git clone --filter=blob:none --quiet https://github.com/PythonistaGuild/mystbin-py.git 'C:Users<my name>AppDataLocalTemppip-req-build-jhnvnus7' did not run successfully.
│ exit code: 128
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× git clone --filter=blob:none --quiet https://github.com/PythonistaGuild/mystbin-py.git 'C:Users<my name>AppDataLocalTemppip-req-build-jhnvnus7' did not run successfully.
│ exit code: 128
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.
WARNING: You are using pip version 22.0.4; however, version 22.2.2 is available.
You should consider upgrading via the 'C:Users<my name>AppDataLocalMicrosoftWindowsAppsPythonSoftwareFoundation.Python.3.9qbz5n2kfra8p0python.exe -m pip install --upgrade pip' command.

Expected Results
for mystbin.py to install correctly
Actual Results
it failed to install
Related item UUIDs
No response
Checklist

[X] I have searched the open issues for duplicates.
[X] I have shown the entire traceback, if possible.
[x] I have included debug logging (with my latest token remove), if applicable.

Additional Context
No response

You should use the Clone button on the main page of the repo.
I will update the README to reflect this too.
pip install -U git+https://github.com/PythonistaGuild/mystbin.py.git


XCTAssertNotNil may not work in all cases in Swift

Originally reported in #3600, although I haven't reproduced this. The following needs to be done:

[ ] make a minimized repro case confirming this is actually an XCTest bug
[ ] file a radar
[ ] write our own RLMAssertNotNil function that works

It no longer reproduced in my environment. I'll close this issue after a little more investigation. @jpsim

We can't reproduce this, so closing.


shutdown in specified order

I want to specify the order of the shutdown with numbers

fixed in shutdown/v1.3.0 with the After func


Rails 6 and rc1, uninitialized constant ActionDispatch::Routing::ACTIVE_SCAFFOLD_CORE_ROUTING (NameError)

I wanted to try this gem.  My Rails application has the following gem versions:
gem 'active_scaffold', '~> 3.6.0.rc1'
gem 'jquery-rails'
gem 'jquery-ui-rails'
gem 'active_scaffold_export'
gem 'axlsx_rails'
gem 'rails', '~> 6.0'
gem 'mysql2'

When I try to start the server, I get
Traceback (most recent call last):
	33: from bin/rails:3:in `<main>'
	32: from bin/rails:3:in `load'
	31: from /Users/dbulgatz/AMA/t3-mis/bin/spring:15:in `<top (required)>'
	30: from /Users/dbulgatz/AMA/t3-mis/bin/spring:15:in `require'
	29: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `<top (required)>'
	28: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/spring-2.1.0/lib/spring/binstub.rb:11:in `load'
	27: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/spring-2.1.0/bin/spring:49:in `<top (required)>'
	26: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/spring-2.1.0/lib/spring/client.rb:30:in `run'
	25: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/spring-2.1.0/lib/spring/client/command.rb:7:in `call'
	24: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `call'
	23: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/spring-2.1.0/lib/spring/client/rails.rb:28:in `load'
	22: from /Users/dbulgatz/AMA/t3-mis/bin/rails:9:in `<top (required)>'
	21: from /Users/dbulgatz/AMA/t3-mis/bin/rails:9:in `require'
	20: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/railties-<IP_ADDRESS>/lib/rails/commands.rb:18:in `<top (required)>'
	19: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/railties-<IP_ADDRESS>/lib/rails/command.rb:46:in `invoke'
	18: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/railties-<IP_ADDRESS>/lib/rails/command/base.rb:69:in `perform'
	17: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
	16: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
	15: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
	14: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/railties-<IP_ADDRESS>/lib/rails/commands/server/server_command.rb:138:in `perform'
	13: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/railties-<IP_ADDRESS>/lib/rails/commands/server/server_command.rb:138:in `tap'
	12: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/railties-<IP_ADDRESS>/lib/rails/commands/server/server_command.rb:141:in `block in perform'
	11: from /Users/dbulgatz/AMA/t3-mis/config/application.rb:8:in `<top (required)>'
	10: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/bundler-2.1.4/lib/bundler.rb:174:in `require'
	 9: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:58:in `require'
	 8: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:58:in `each'
	 7: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:69:in `block in require'
	 6: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:69:in `each'
	 5: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:74:in `block (2 levels) in require'
	 4: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/bundler-2.1.4/lib/bundler/runtime.rb:74:in `require'
	 3: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/active_scaffold_export-3.3.2/lib/active_scaffold_export.rb:8:in `<top (required)>'
	 2: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/active_scaffold_export-3.3.2/lib/active_scaffold_export/config/core.rb:2:in `<top (required)>'
	 1: from /Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/active_scaffold_export-3.3.2/lib/active_scaffold_export/config/core.rb:2:in `class_eval'
/Users/dbulgatz/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/active_scaffold_export-3.3.2/lib/active_scaffold_export/config/core.rb:18:in `block in <top (required)>': uninitialized constant ActionDispatch::Routing::ACTIVE_SCAFFOLD_CORE_ROUTING (NameError)

Fixed in master branch


Type error when running tweakreg related code

When running section 4a of the align_mosaics notebook, the type error below is appearing:

leading to some other issues:

Thanks for reporting this! cc @samanthalh

This is a known issue with the new numpy version 1.18.1, more info can be found here: https://github.com/spacetelescope/drizzlepac/issues/582
A bug fix has already been coded, but not yet released (see: https://github.com/spacetelescope/drizzlepac/pull/587), so downgrading the numpy version or downloading the (unverified) developmental version of DrizzlePac from github should resolve this.
cc @catherine-martlin

@samanthalh what version of numpy would we need to downgrade to for this? I'm seeing something similar for the align_muliple_visits notebook. Looks like my astroconda is pulling in v3.1.6 of DrizzlePac, even with updating the package.


Whether tauri-2.0.0-alpha can be supported

@mrzhjyw I'll wait until version 2.0.0 is officially released.

I'll wait until version 2.0.0 is officially released.

Perhaps a message from Simon will incentivize you to do v2 support)

Haha, okay, I'll start the upgrade.

@ahkohd
Tauri 2.0-beta has also been released, really looking forward to supporting it.

Sure, this weekend, I will write and release support for version 2.

@ahkohd That's fantastic, really looking forward to it!

@ahkohd That's fantastic, really looking forward to it!

What errors are you getting that require this plugin to be adapted to v.2?

I haven't tried using this plugin because I looked at Cargo.toml and it still depends on tauri 1.0.

Hello gents,
It's ready, please help test it out and give me feedbacks.
https://github.com/ahkohd/tauri-nspanel/tree/v2

That's so cool! I'll find some time to test it out!

Okay then, I'll close this issue and mark it as done. If you face any problems, please don't hesitate to create a new issue.


storage: media downloads

Currently, reading uses the object URL directly (ordinary GET). Instead specify alt=media to get resumable, chunked downloads.
Expose a field in Reader to specify the chunk size.
Provide intelligent generation-pinning for downloads (i.e., doesn't start downloading generation 1234, stop for whatever reason and resume, but accidentally get generation 2345 for the remainder).
Validate CRC32c of chunks.

What do you mean by resumable, chunked downloads? You don't need alt=media to do a Range request.

I was confused.


Add binding example

Adds node for switching species
Update output dtyping dynamically on the array slicer/indexer
Debug "source code" representation for nodes defined in-notebook
Add an example for calculating solute-GB binding

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

11 of 23 (47.83%)  changed or added relevant lines in 3 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.09%) to 50.828%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

ironflow/nodes/pyiron_atomistics.py
4
7
57.14%

ironflow/model/node.py
0
4
0.0%

ironflow/nodes/array.py
7
12
58.33%

Files with Coverage Reduction
New Missed Lines
%

ironflow/model/node.py
1
68.84%

ironflow/nodes/array.py
4
71.67%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
1873

Relevant Lines:
3685

💛  - Coveralls


Implement Expandable::into_id

Is unfortunate to have to add another method to the Object trait to achieve this. But not sure of another way to implement a generic way to pull an owned T::Id out of Expandable<T> without cloning (ran into needing this when using this next branch, but think it's probably relatively common since most requests won't set expand, so users will probably only want the id in Expandable<T>.

Looks OK to me.


chore: Promote rc to stable

Promote rc to stable, created by dt release promote
DO NOT MERGE

@artemchernyak-outreach stale? :D

Breaking rc releases ATM, closing


NFT Description is not visible in Light mode

What happened?
I am using light mode on KodaDot and I can't see description in bold because it's white
Please reproduce in steps

Open NFT
Switch to light mode
90% of desc is not visible

Expected Behavior
Description should be visible in light mode
What browsers are you seeing the problem on?
Desktop Chrome
At which address did you encounter bug?
beta.kodadot.xyz, kodadot.xyz
Are you logged in?
Yes
Which wallet you are using?
PolkadotJS
At which chain did you encounter bug?
No response
Screenshots

Relevant log output
No response
Payment link for reward
https://kodadot.xyz/transfer/?target=<My_Kusama_Address_check_https://github.com/kodadot/nft-gallery/blob/main/CONTRIBUTING.md#creating-your-ksm-address>
Code of Conduct

[X] I agree to follow this project's Code of Conduct

👋


add calico case in nightly e2e

Signed-off-by: bell.guo<EMAIL_ADDRESS>What type of PR is this?
/kind feature
What this PR does / why we need it:
add calico case

run log:
https://github.com/kubean-io/kubean/actions/runs/3798673063/jobs/6460606710


resetting device stats on X552

Hi,
running the following script:
local device	= require "device"
local lm	= require "libmoon"
local log	= require "log"
local memory	= require "memory"
local stats	= require "stats"
local timer	= require "timer"

local DST_MAC	= "01:23:45:67:89:AB"
local SRC_IP	= "<IP_ADDRESS>"
local DST_IP	= "<IP_ADDRESS>"
local SRC_PORT	= 1234
local DST_PORT	= 319

function configure(parser)
	parser:description("Generates UDP traffic.")
	parser:argument("txDev", "Device to transmit from."):convert(tonumber)
	parser:argument("rxDev", "Device to receive from."):convert(tonumber)
end

function master(args)
	txDev = device.config{port = args.txDev, rxQueues = 3, txQueues = 3}
	rxDev = device.config{port = args.rxDev, rxQueues = 3, txQueues = 3}
	device.waitForLinks()
	local rate, size = 100, 100
	txDev:getTxQueue(0):setRate(rate - (size + 4) * 8 / 1000)
	lm.startTask("loadSlave", txDev:getTxQueue(0), rxDev, size)
	lm.waitForTasks()
end

local function fillUdpPacket(buf, len)
	buf:getUdpPacket():fill{
		ethSrc = queue,
		ethDst = DST_MAC,
		ip4Src = SRC_IP,
		ip4Dst = DST_IP,
		udpSrc = SRC_PORT,
		udpDst = DST_PORT,
		pktLength = len
	}
end

function loadSlave(queue, rxDev, size)
	local mempool = memory.createMemPool(function(buf)
		fillUdpPacket(buf, size)
	end)
	local bufs = mempool:bufArray()
	local txCtr = stats:newDevTxCounter(queue, "plain")
	log:info('finalize immediately')
	txCtr:finalize()
	log:info('new txDev counter (1)')
	txCtr = stats:newDevTxCounter(queue, "plain")
	local time = timer:new(1)
	while lm.running() and not time:expired() do
		bufs:alloc(size)
		bufs:offloadUdpChecksums()
		queue:send(bufs)
		txCtr:update()
	end
	log:info('finalize after while')
	txCtr:finalize()
	lm.sleepMillis(5000)
	log:info('new txDev counter (2)')
	txCtr = stats:newDevTxCounter(queue, "plain")
	log:info('update & finalize')
	txCtr:update()
	txCtr:finalize()
end

produces as output:
$ ./build/MoonGen test.lua 0 1
# <snip>
[INFO]  Found 2 usable devices:
   Device 0: E0:DF:84:9B:C2:50 (Intel Corporation Ethernet Connection X552 10 GbE SFP+)
   Device 1: 9B:90:24:EC:46:42 (Intel Corporation Ethernet Connection X552 10 GbE SFP+)
# <snip>
[INFO]  finalize immediately
[Device: id=0] TX: nan (StdDev 0.00) Mpps, nan (StdDev 0) Mbit/s (nan Mbit/s with framing), total 0 packets with 0 bytes (incl. CRC)
[INFO]  new txDev counter (1)
[Device: id=0] TX: 0.12 Mpps, 99 Mbit/s (118 Mbit/s with framing)
[INFO]  finalize after while
[Device: id=0] TX: nan (StdDev 0.00) Mpps, nan (StdDev 0) Mbit/s (nan Mbit/s with framing), total 120078 packets with 12488112 bytes (incl. CRC)
[INFO]  new txDev counter (2)
[INFO]  update & finalize
[Device: id=0] TX: nan (StdDev 0.00) Mpps, nan (StdDev 0) Mbit/s (nan Mbit/s with framing), total 120078 packets with 12488112 bytes (incl. CRC)

which is, in my opinion, unexpected.
I'd expect the last line to report 0 packets/bytes, since stats:newDevTxCounter
https://github.com/libmoon/libmoon/blob/db11ff1972448389562588100149730e2654876c/lua/stats.lua#L456
promises to reset stats.
Am I missing something?
Thanks!
Regards,
Sharlene

@emmericp ?

getThroughput() no longer resets the stats, this was changed because we moved to using the DPDK stats functions on some NICs to support more NICs; so the comment is wrong.
What would be needed is an explizit reset for the device counters; current the device counters are just that: count everything the device has seen.


Add specification

Signed-off-by: Bogdan Vaneev<EMAIL_ADDRESS>

I will merge without reviews, if you don't mind.


[CI] Enable verbose dub output for preGenerateCommands

Will try to recreate #864

You could probably modify the Github workflow to just run dub build. Even do it in loops until it fails.

I couldn't reproduce the issue. @Geod24, Should we merge this and wait for the next time we see it in the wild?

I think that it's a race condition, and so using verbose (and writing to stdout) is enough to delay things enough for it not to happen. Can you reproduce without verbose output ?

Can you reproduce without verbose output ?

Sadly, no.


Add content security policy middleware

Use helmet csp to implement a content security policy that whitelists origins we deem to be safe for loading assets.
Our templates inherit from https://github.com/alphagov/govuk_template/blob/master/source/views/layouts/govuk_template.html.erb which includes two script tags. As such our CSP will need to include a directive that lets inline scripts be included...
E.g. Using Helmet csp: scriptSrc: ["'self'", "'unsafe-inline'"]
This issue https://github.com/alphagov/govuk_template/issues/258 identifies a solution to the issue.
This PR should avoid the need to add the unsafe-inline directive: https://github.com/alphagov/govuk_template/pull/268

Hi @JoeChapman it's great to see you contributing to improve govuk_template's CSP support.
When we deployed CSP on Verify we used hashes as recommended by @robinwhittleton as these rarely change. It would be good to hear why this wouldn't work for you?
CSP is moving quite quickly, on one side the spec and Google seem to be suggesting nonce-based policies are best as they allow for easier adoption of CSP (which I generally agree with) but at the same time people are finding many ways of bypassing nonce-based policies.
Again I'm not opposed to adding nonce support but would like to know why the hashes wouldn't work for you before we do that.
Thanks!


Paint info?

@yoavweiss reminded me today that we had discussed (at TPAC) the idea of including "was painted" information to the IO records.
Perhaps he can provide more information about the use-cases he had in mind.

Apologies for not filing this earlier...
The use case I have in mind is the ability to tell when was a certain element painted on screen, in order to measure the visual impact on the user, so that it can be taken into account when talking about visual performance metrics. I'm not sure if there's a significant lag between layout and painting there, and I realize that painting info will not represent the exact time when things are actually on screen, but the more accurate the data we can have on that front, the better.
One area where things might get complicated is in scenarios where painting is done without layout. The example that comes to mind is when an image is progressively downloaded and painted, after its initial intrinsic dimensions are known and (potentially) trigger layout. Still, it would be great to tackle that scenario as well, as it would be extremely useful for visual RUM metrics.
At the same time, we need to be careful regarding privacy related attacks. In particular, I think we would need to modify the way :visited behaves in order to make it useful for scenarios where it is needed while making sure that the general attack vector (visited painting link people went to in a separate browsing session) is disabled. I'll take that up with the CSSWG.

Anything here would definitely be a v2 feature.


"this.StackingBehavior" returning null?

Not quite sure what is going on here. Maybe you could take a look for me? Mentions DataAttributes.
Crash Report:
crash-2022-02-03_22.07.00-server.txt
Log:
latest.log

Also version if needed is 3.1.3 - 1.18.1 (latest)

Tried updating Cardinal Components API to the latest as well, ended up with the same crash mentioned here: #48

Thanks for the crash report, I'll try to fix asap. Also thanks for the info on CCA.


#29: Move initialisers to a dedicated folder

Closes #29

Codecov Report

Merging #31 (c8b0cbe) into main (4e8597a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #31   +/-   ##
=======================================
  Coverage   96.74%   96.74%
=======================================
  Files          40       40
  Lines         338      338
  Branches       65       65
=======================================
  Hits          327      327
  Misses         11       11

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 4e8597a...c8b0cbe. Read the comment docs.

Codecov Report

Merging #31 (c8b0cbe) into main (4e8597a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #31   +/-   ##
=======================================
  Coverage   96.74%   96.74%
=======================================
  Files          40       40
  Lines         338      338
  Branches       65       65
=======================================
  Hits          327      327
  Misses         11       11

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 4e8597a...c8b0cbe. Read the comment docs.


ADD HACKTOBERFEST AND GSSOC BANNER ON THE README

📋 Description (ADD HACKTOBERFEST AND GSSOC BANNER ON THE README)
This PR adds the official Hacktoberfest and GSSOC banners to the top of the README file to showcase the project’s participation in these open-source events. The purpose is to attract more contributors and increase engagement in the project.
🔨 Changes Made

Added Hacktoberfest banner at the top of the README.
Added GSSOC banner below the Hacktoberfest banner.
Adjusted README formatting to align the banners properly.

✅ Checklist
Before submitting the PR, please make sure you have completed the following:

[x] I have followed all the guidelines mentioned in CONTRIBUTING.md.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation (if applicable).
[x] I have tested it locally and it works fine.
[x] Any dependent changes have been merged and published in downstream modules.

🏷 Types of Changes
What type of changes does your code introduce? (Check all that apply)

[ ] Bug fix (non-breaking change which fixes an issue) 🐛

[x] New feature (non-breaking change which adds functionality) ✨

[ ] UI enhancement (non-breaking change which enhances UI) 🎨

[x] Documentation update 📚

Fixes #168

📸 Screenshots (if applicable)
N/A
Thank you for contributing to Research Nexus! We look forward to reviewing your PR and getting it merged!

@Harshdev098 the task has been Completed.


Added custom iterator function to allow iteration over SF Libraries and Types

Otherwise there is no other way to get field names and values from libraries or types since their type definitions use a proxy table.

Reasons for inclusion?
Libraries and Types should be documented, so I'm sort of on the fence regarding their need to be iterated. Especially when the iteration method requires custom invokation and not the standard - Users would have to learn a specific way for table iteration for Libraries and Types. Is this better than not including any at all?

The Libraries and Types are documented yes, but if a user wants to wrap functions or anything else then there is no other way to get them automatically. Users would not have to learn anything if they don't want to. It wouldn't be much to learn anyway as the custom iterator function is used exactly the same as the pairs function.
Another method would be to have a function return a list of all the keys in a given type.
I don't see how having this functionality could be worse than not having it. There is no downside to being able to iterate over them.

I was going to argue, why not just modify pairs or ipairs to do conditional parsing depending on if we give it a library or not. BUT. That would be horribly inefficient, as there is probably a 99% use-case for standard Lua use rather than our tables. So adding a special function makes sense I guess, and it DOES have incredible functionality for users within game. Having had to checkout your branch myself for that purpose, I kind of realised it's needed. Good Job. Merged.


Add custom submodule directory functionality

Did you want to make any changes before having this merged?

Yeah didnt get time to do it, will improve in a few days

I ended up adding this myself to the main branch based mostly on your PR. Thanks for your time!


CS1061	'HttpClient' does not contain a definition for 'PostAsJsonAsync' For asp.net core project

Not sure if the is the right place to post this issue.
When try to following the Doc for  "Integration Testing" example https://github.com/aspnet/Docs/tree/master/aspnetcore/mvc/controllers/testing/sample, for a pure asp.net core project, I got the following error.
CS1061	'HttpClient' does not contain a definition for 'PostAsJsonAsync'
Here are the nudge package  was including.
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
  <PackageReference Include="Microsoft.AspNetCore.TestHost" Version="1.1.2" />
  <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
  <PackageReference Include="System.Net.Http" Version="4.3.2" />
  <PackageReference Include="xunit" Version="2.2.0" />
  <PackageReference Include="xunit.runner.visualstudio" Version="2.2.0" />

I have to add the package below to make it to work.
 <PackageReference Include="WinInsider.System.Net.Http.Formatting" Version="1.0.5" />
But this does not seem right because the    "TestingControllersSample" does not need to include it.
Is this a packing versioning problem?  The "TestingControllersSample" is using "System.Net.Http  Version"4.1.1"
Thanks

I'm guessing the sample is missing a using statement.
WinInsider.System.Net.Http.Formatting is not an ASP.NET Core assembly.
We'll investigate, thanks for the report.

@Rick-Anderson I am not sure if it is because of  a missing using statement.  I believe it is something else, below are the using statements
using Newtonsoft.Json;
using System.Linq;
using System.Collections.Generic;
using System.Net.Http;
using System.Threading.Tasks;
using Xunit;
using System.Net;

@Rick-Anderson I just read this Where is PostAsJsonAsync method in ASP.NET Core?
 on stackoverflow, and realized PostAsJsonAsync is not part of the aspnet.core.
So, I call end up unreference WinInsider.System.Net.Http.Formatting, but calling JsonConvert.SerializeObject(); first then call PostAsync instead.
But I still don't understand how the example https://github.com/aspnet/Docs/blob/master/aspnetcore/mvc/controllers/testing/sample/TestingControllersSample/tests/TestingControllersSample.Tests/IntegrationTests/ApiIdeasControllerTests.cs works by calling PostAsJsonAsync
My problem is solved, but I am not sure if I should close this issue, so please close it if you see fit.
Thanks

@danroth27

I still don't understand how the example https://github.com/aspnet/Docs/blob/master/aspnetcore/mvc/controllers/testing/sample/TestingControllersSample/tests/TestingControllersSample.Tests/IntegrationTests/ApiIdeasControllerTests.cs works by calling PostAsJsonAsync

In this case the sample includes its own implementation of PostAsJsonAsync:
https://github.com/aspnet/Docs/blob/master/aspnetcore/mvc/controllers/testing/sample/TestingControllersSample/tests/TestingControllersSample.Tests/IntegrationTests/HttpClientExtensions.cs

I'm new here, I was pretty confused following that tutorial (Call a Web API From a .NET Client (C#))
I wrote this solution based on @Rick-Anderson  comments, I hope this help.
using System.Web.Script.Serialization;
.
.
.
static async Task CreateProductAsync(Product product)
{
JavaScriptSerializer jss = new JavaScriptSerializer();
var myContent = jss.Serialize(product);
var httpContent = new StringContent(myContent, Encoding.UTF8, "application/json");
HttpResponseMessage response = await client.PostAsync("api/products", httpContent);
response.EnsureSuccessStatusCode();
        //return URI of the create resource.
        return response.Headers.Location;
    }

Hi!
Just install Microsoft.AspNet.WebApi.Client nuget package

Hi!
Just install Microsoft.AspNet.WebApi.Client nuget package

correct answer.thanks


[WIP] Implement matchers in individual classes

@chrisalley this is an experiment, there are many other things to do
In this refactor, all matchers inherit from "ActionsMatchers", and they are all variant of the same matcher.

All expectation messages are small customizations of a single message
permit_action/forbid_action are variants of permit_actions/forbid_actions with a single parameter
permit_all_actions, forbid_all_actions, permit_only_actions, forbid_all_actions  use the policy info to make their expectation, they are very simple array comparisons

Also:

Remove compatibility with Pundit 1.x
Remove the ability to use negated matchers
Drop policy with arguments

ToDo:

[ ] Proper inclusion (check how shoulda matchers does)
[ ] Mass assignment
[ ] Proper specs (shared contexts, "behaves like", unit tests, integration tests)
[ ] Documentation
[ ] Understand how chaining works

Before
$ git ls-files lib | xargs cloc
      14 text files.
      14 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 1.96  T=0.01 s (1861.2 files/s, 107283.8 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Ruby                            14            132             47            628
-------------------------------------------------------------------------------
SUM:                            14            132             47            628
-------------------------------------------------------------------------------

After
git ls-files lib | xargs cloc
      11 text files.
      11 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 1.96  T=0.01 s (1707.5 files/s, 88325.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Ruby                            11            121             14            434
-------------------------------------------------------------------------------
SUM:                            11            121             14            434
-------------------------------------------------------------------------------

As an experiment this looks promising. If we could break this down into smaller PRs that would be more manageable and easier to track any regressions.
At the least, keeping the refactoring (non breaking changes) and dropping support (breaking changes) as separate PRs.

Hi,
I think I've found a better approach that will also allow to properly use negated matchers
It should be enough to provide forbid_matcher and a permit_matcher methods and alias them as does_not_match? and matches?

It should be enough to provide forbid_matcher and a permit_matcher methods and alias them as does_not_match? and matches? according to the specific matcher

That sounds good; provided we’ve got full test coverage, and you’re happy to make the changes, I think we can support negated matchers.

Action Matchers can be implemented by defining only permit_action*, with both matches? and does_not_match? methods.
Then, forbid_action* can be defined as the negated matcher of permit_action*.
With this approach:

negated matches will work as expected
no code duplication
no aliases

Ref:
https://github.com/tagliala/pundit-matchers/commit/5635499eb12527ca720a1319969cb790efc2b6fa#diff-a3affd6d629b9ffd752de7759d979d2c0e62d5fd9a4b33a10dad7b70cd8660e7
https://github.com/tagliala/pundit-matchers/commit/5635499eb12527ca720a1319969cb790efc2b6fa#diff-a3fa020c066bb5e51ed11027cf18a65ce7bd673fe955ae75d6481fcfae1c4bf7


Can't have Regular and Italics in the same file

I have a font that has the Regular and Italic masters in the same file. No interpolation will be done between them, and no variable font will be generated. When I try to use the gftools builder it only generates the italics and I get this message:
WARNING:glyphsLib.builder.axes:Instance user-space location (400) redefined by 'Italic'
Is there a way to configure the gftools builder so it doesn't do that?

Also is there a way to disable generating variable fonts?

Ok I figured out that I needed to change the axis name to "Italic" and it worked as expected.

If you're using the builder, you can disable variable font generation by including buildVariable: false in your yaml file.


[FEATURE] contact import fixes

Tasks:

[x] done
[ ] todo
[ ] got feedback

Informations:

Q
A

Bug fix?
no

New feature?
yes

Tests pass?
yes

Fixed tickets
none

Doc
none

nice, ack


creation of Address errored: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":-32000,"message":"transaction underpriced"}}}'

I don't know to to fix

You need to edit gas fees in MetaMask, Set Limit to 3M and Gwei pre to 100 and max to 101.

It works!! Thanks a lot


base4 for SpecialKey is too bright / too similar to the comments

As a result, it's a bit confusing: non-printed symbols are mixed with comments since comments too use base4 colour. Even base3 may be a bit too bright, but is still much better.
diff --git a/colors/gotham.vim b/colors/gotham.vim
index 82ba3de..5c5167e 100644
--- a/colors/gotham.vim
+++ b/colors/gotham.vim
@@ -151,7 +151,7 @@ call s:Col('StatusLineNC', 'base4', 'base2')
 call s:Col('MatchParen', 'base1', 'orange')

 " Special keys, e.g. some of the chars in 'listchars'. See ':h listchars'.
-call s:Col('SpecialKey', 'base4')
+call s:Col('SpecialKey', 'base3')

 " Folds.
 call s:Col('Folded', 'base6', 'blue')

Could you send a PR with before/after screenshot? I'd love that :heart:

Left to right: base4, base3, base2. Tabs displayed as >------