first cut at enumerating requirements for new package registration

Following up on discussions in slack and on discourse (1, 2), here are some proposed changes for new package registrations.
Note that this proposal is for NEW registrations only; existing packages are not in scope.

Is the idea:

New packages that don't meet these requirement do not get merged at all? Or:
New packages that don't meet these requirements have a longer waiting period, but after that waiting period has expired, they will definitely be merged, even if the author refuses to implement these requirements?

Is the idea:

New packages that don't meet these requirement do not get merged at all? Or:
New packages that don't meet these requirements have a longer waiting period, but after that waiting period has expired, they will definitely be merged, even if the author refuses to implement these requirements?

Personally, I'd like to see a harder line on this but I don't want the perfect (option 1) to be the enemy of the good (option 2), so I'll leave that up to the community.

Is the idea:

New packages that don't meet these requirement do not get merged at all? Or:
New packages that don't meet these requirements have a longer waiting period, but after that waiting period has expired, they will definitely be merged, even if the author refuses to implement these requirements?

~Personally, I'd like to see a harder line on this but I don't want the perfect (option 1) to be the enemy of the good (option 2), so I'll leave that up to the community.~
I'm changing my tune here. I think the goal is to be able to require a discussion whenever a new package can't meet these basic requirements. There are certainly cases where packages will be unable to do so; that doesn't mean that they're not good for the registry, but it allows us to understand and, more importantly, document the rationale for the packages not meeting these requirements.

So you're going option 2, then? Could you add a specific length of time that this "longer waiting period" will be?

I'll just link this here: https://discourse.julialang.org/t/reduce-package-registration-waiting-period/40954/75?u=chrisrackauckas . At the end of the day, I think there's too many counter examples to any solid criteria that is made, with things like Reexport.jl, SafeTestsets.jl, Unpack.jl, etc. being great trivial packages. So at the end of the day, I think all we can do is write down a bunch of rules that packages should try to follow, and point them out when people want to register, but still register things we may not agree with.

@DilumAluthge - yes, a variation on option 2, I guess.
@ChrisRackauckas this isn't about the size of the package or the number of exported functions (my personal views on this notwithstanding). It's about taking the time to make a quality package. All of your examples would have been eligible for automerge under these new requirements.

but still register things we may not agree with.

If I am understanding this PR correctly, we will indeed still register those things. But the waiting period will be longer.

Let me propose option 3:
If a new package does not meet the requirements:

The PR gets tagged in github
a 7-day clock starts, after which (if no comments are received) the PR is merged
if comments are received the automerge blocks (as it does today).

I do think CI should be a soft requirement, where exceptions can be made (MATLAB.jl), but we should expect packages to have tests and CI setup.

Let me propose option 3:
If a new package does not meet the requirements:

The PR gets tagged in github
a 7-day clock starts, after which (if no comments are received) the PR is merged
if comments are received the automerge blocks (as it does today).

Sounds good to me.
Now, just to be clear: if comments are posted, but the author refuses to make any changes, and 7 days have gone by, does a registry maintainer manually merge the package? The answer is yes, right?

Now, just to be clear: if comments are posted, but the author refuses to make any changes, and 7 days have gone by, does a registry maintainer manually merge the package? The answer is yes, right?

Not necessarily. The reason we have committers is because we trust their judgement. They're to the repo what stewards are to the social channels. The committers' job (sometimes unpleasant) is ultimately to determine whether we give the package a platform in the General registry. It could be the case that we have an unreasonably obstreperous contributor, in which case the committer has the leeway to say, "You know, this won't make a good package. I'm not going to merge it as-is, but here are some things that you could do to make it merge-worthy."
(Also see that I added a 4th item.)

Now, just to be clear: if comments are posted, but the author refuses to make any changes, and 7 days have gone by, does a registry maintainer manually merge the package? The answer is yes, right?

I'm not sure a package needs to be "good" to be in General: that's a bit hard to even define. If it's borderline, at the end of the day I might think that the criteria is "not actively bad" or "not unsafe". I might completely disagree about whether it's a useful enough nugget to be a package, but if at least one other person thinks it might be useful, why block them if it's not actively bad? If someone went through the trouble to register, then at least they think it could be useful, and that might be enough... after a strong nudge telling them they need tests and documentation, and if it's not doing things like actively trying to promote spyware.

I'm not sure a package needs to be "good" to be in General: that's a bit hard to even define. If it's borderline, at the end of the day I might think that the criteria is "not actively bad" or "not unsafe". I might completely disagree about whether it's a useful enough nugget to be a package, but if at least one other person thinks it might be useful, why block them if it's not actively bad?

IMO, this is the role of a committer - to represent the interests of the codebase they have rights to. There is no reason the General registry repo should be different than DifferentialEquations.jl or LightGraphs.jl - I hope you wouldn't consider auto-merging PRs to your codebase after a given period of time (if you would, then we need to talk offline :) ).
The same thing that applies to DE or LG applies even more so to a repo that underpins the ecosystem of an entire programming language. Things that go into that repo reflect on the language and its community, and we should ensure, within reason, that contributions that represent the language and are in the "official" (default) registry are of sufficient caliber to advance the language (or at the very least not damaging to its reputation).

The purpose of General has been to make it easy for people to distribute code (think of Docker Hub). It is not meant to be curated. I really think the correct approach would be to have a curated registry or a Pkg extension that can filter available packages based on set criteria (e.g., license, code-review). For example, we have seen a few packages that are just a couple lines for meta (install a bunch of packages à la tidyverse). I don't think we should be changing the scope of General.

The purpose of General has been to make it easy for people to distribute code (think of Docker Hub).

You don't need General to distribute code: a url is fine. The purpose of General has always been to make it easy to distribute code that other people depend on. If no one depends on your package, whatever just ]add url. But when a lot of people want to use it as a dependency, semvar matters, package tests matter, and an easy way to identify what to download matters. That's what General is for, and we should definitely build our expectations around packages as being dependencies if they are looking to be in General. The question is then, what is required for something that anyone can depend on? You might have a higher bar than the lowest bar, but what is the lowest bar?

Mailing USB's would be another way but is not convenient. General makes no guarantee that the packages will work one way or another (hence the curation). Semver matters at the registry level, yes, but no one should expect that because a package is in General they can depend on it. Tests, documentation, license, and other criteria is for the user to decide and that's their responsibility and burden not the registry. Just because you found a repo on GitHub that has Project.toml doesn't mean you can depend on it. With a registered package the guaranteed is that the code will not go dark since the package server will hold copies of the code and minimizes that risk. The bar depends on the user, for a weekend project you might not care much, for building software for the international space station it might be higher than for most. I am all for having giving the users the information for them to make inform decisions. I just wouldn't like to get rid of the "lowest bar" for finding creating a "medium bar" that disenfranchises some and doesn't do much for the other audience. I feel there are better ways to address the very valid concern.

Please, keep the discussion realistic and grounded. How different are ]add https://github.com/SciML/DiffEqFlux.jl and ]add DiffEqFlux if you just went to the website to learn about the package? If all General gave was a shorthand it would be meaningless: who cares about 20 characters you copy paste from the website you discover the package from? What it really gives is a dependency mechanism for other open source projects in General, so if you aren't participating in the world of dependencies, there's nothing gained by being in General. That makes it fairly clear that you should at least be "trying" to participate in the community of dependencies if you're applying to be in General.
The real question is then, what does it mean to be "trying" to be something that other packages can depend on? Immutability of releases, tests and CI, etc. are all things which are helpful for a packages others want to depend on. So, what is the lowest bar for something that is dependable? It could be anything with a tag, or it could be more.

The bare minimum is access to the code. A GitHub repository can be made private or deleted without warning. So the bare minimum is a guarantee of continuous access which is precisely what the registry provides with the package manager. Until Julia 1, there were hundred of packages that were registered that had been deleted / made private / or were not installable in supported versions of the language at the time. The ecosystem is about communities or connected graphs, one can have a niche ecosystem of 3 packages that are not documented / tested but is all a community needs for their needs and never touch other components.
On the issue of whether it is some extra 20 characters, it is not. If there weren't a registry, it would all be finding the 153 different repository URL in the right order to be able to install DiffEqFlux (e.g., Manifests would also be very important)... You would likely end up having to set up your own registry for having a usable workflow so I don't think it is fair to say people can just use the URL.

The bare minimum is access to the code. A GitHub repository can be made private or deleted without warning. So the bare minimum is a guarantee of continuous access which is precisely what the registry provides with the package manager.

Note that the general repository doesn't guarantee access to code, and that's one of the flaws that could be exposed if there is a proliferation of small projects that quickly come and go 🤕 .

If there weren't a registry, it would all be finding the 153 different repository URL in the right order to be able to install DiffEqFlux (e.g., Manifests would also be very important)... You would likely end up having to set up your own registry for having a usable workflow so I don't think it is fair to say people can just use the URL.

So there you go, it's about being a dependency 🤦

The package server which is the default for Julia v1.5 onward does guarantee that so it would be immune to lpad-like issues.
Hence the benefit of making a tool like a registry accessible to all (i.e., favoring low bar). I am not against having a registry that's curated and every entry meet a CRAN like standard for publication I just wouldn't want it to come at the needless cost of losing a "General" like solution. There are a number of discussions about maintaining a General and a Curated registry both "official".

The core policy question I think is this: should the General contain ALL packages, or only "good" packages. And there seems to be fundamental disagreement over this. Obviously we want to find some "middle" ground, but at the end of the day, which way do we lean? Do we err on the side of containing all packages, or only "good packages"?

Just to mention one very important benefit to having a package in the General registry. We run NewPkgEval on all packages in the General registry. If a package is not registered in the General registry, then we don't run NewPkgEval on it.

Absent a good reason to not have the package such as malicious or critical security vulnerability I think we should err on all packages.

I think @StefanKarpinski is in agreement with you, @Nosferican. In light of the work that is apparently being done to provide a "trust rating" for packages, perhaps this is premature. However - I still have concerns, especially around accepting any package, that are not relevant to this issue.

Absent a good reason to not have the package such as malicious or critical security vulnerability I think we should err on all packages.

That's one opinion. But e.g. @sbromberger says:

Things that go into that repo reflect on the language and its community, and we should ensure, within reason, that contributions that represent the language and are in the "official" (default) registry are of sufficient caliber to advance the language (or at the very least not damaging to its reputation).

So there is definitely not a unanimous agreement.
We are ultimately going to have to make a decision on this. I'm not sure who should make this decision and how to go about it - I will defer to @StefanKarpinski and the other senior registry maintainers on this process.
But we are going to need to make a policy decision on this. The current approach of doing everything on an ad hoc case-by-case basis is not working and just gives a bad impression when two similar packages are treated differently by two different registry maintainers. We need an official documented policy, and then everyone with commit access on a General will have to adhere to that policy.

Do open a different issue so we can keep track of those concerns especially whatever you can provide especially in terms of security or access barriers (e.g., mechanism to whitelist packages being handled at a sysadmin vs user level, etc.). Graph analyses would be great as well. Part of my interest is selfish in the sense that it speaks directly to my current research on OSS ecosystems. Looking forward to what experiment solution Julia ends up implementing and its result.

If we let every single piece of code that wants to run be part of PkgEval, who else is going to pay for it? Do you want to put down 20k? At some point we have to have a limit for what is being routinely tested and stored, since we have to get the compute to actually do this. It's nice to have books and personal projects and etc. get PkgEval, but the reality is that those will grow immensely, and if no one else is depending on it, who cares? So I think a reasonable driving narrative is, the rules should be built around the acknowledgement that this is for code that other people will depend on, and how we document the rules should reflect that general concept.

Riffing off of what @ChrisRackauckas said - the justification for package registration requirements could also include the fact that a registered package imposes a burden on people other than the package maintainer. It imposes a burden on the repository managers (and the PkgEval folks) at a minimum, and arguably on every user of the registry, as it takes up space and bandwidth. A registry is truly a community resource with distributed costs, and my position is that it's not unreasonable to set some sort of a bar for people to meet prior to requiring the community to support - in whatever small way it is - their project.

Like any other public API, it should be governed by fair legitimate use.  During the beta, they basically described their policy as don't misuse / abuse it (e.g., use it to crypto mine) but it shouldn't interfere with the legitimate use of it. That goes towards establishing a user agreement / terms of service. If someone is abusing it, there is a process towards resolving it. I have advocated that the registry should have a User Agreement / Terms of Service especially since there is implicit agreement that when submitting code you have permission to do so (i.e., you are the copyright owner) you are licensing it to forever to host it through the Pkg server. There isn't a requirement for an OSI approved license of the release for instance that is verified in order to circumvent that requirement. From the README

The General registry is open for everyone to use and provides access to a large ecosystem of packages.
The General registry is a shared resource that belongs to the entire Julia community.

Unless there is a precarious financial matter on the CI (which it has been the case at some points in the past), I would shew using barriers as a way to protect the communal resources. If there is abuse, those cases can be handled my the maintainers.
People that need to share code with just a select few people can set up their private registries. If they are unable to, it is likely due to an expertise barrier. If they want to share they weekend project with the community they should have a simple solution to do (e.g., Shinny App server) so. They are millions easier ways to get a bit more CI hours than abusing the General registry so I suspect that isn't a plausible scenario. You want to add a tag in the Project.toml to indicate it shouldn't trigger CI, sure. I would just not like do a real harm to people starting to participate in the community just because of unlikely scenarios.

Like any other public API, it should be governed by fair legitimate use.

I don't think you quite understand how those services work. In "free" services like that, you're the product. You and your data are how those companies make a profit to support themselves. The magic doesn't flow from nowhere: you are in a contract where what you do is tracked, and that information is how these companies pay for themselves. We could do something similar with General: we could setup telemetry with the standard Julia installations so that everyone using Juno and VS Code have their habits logged and we could sell that data to support open source, but of course it's hard to even write that down because that's quite ridiculous. Instead, we're in a situation where we have to try and find ways to siphon off grant funds to support the infrastructure, and for the few actually trying to support it, the only thing that people want to support is the public facing results. "Supporting Julia packages" is possible, but "supporting Julia code that happens to be online" is a non-starter. This is likely why CRAN is able to support a massive infrastructure for what it does, while PyPI is left relatively infrastructure-less.

Unless there is a precarious financial matter on the CI (which it has been the case at some points in the past), I would shew using barriers as a way to protect the communal resources. If there is abuse, those cases can be handled my the maintainers.

There kind of is. We've been in discussions over the last 6 months trying to secure another 120k to stem the problem for another year or so, so it is a huge problem. We can go into details if you really need it, but it's pretty large amounts and growing with the ecosystem. And that's just the hardware. There's also the man hours. Kristoffer Carlsson runs PkgEval and then goes through and checks the failures of thousands of packages to try and make sure nothing is breaking. It would be pretty frustrating to have a growing list of "things in the registry" which trigger failures and are like "nah, we aren't updating this because it's not like anyone is depending on this, right?". To make it easy for everyone involved, it would be best to just prune all of those things out of the registry so that you expect that anything in the registry is "ready for someone else to depend on". That way if it's failing its tests (which it should have if anyone wants to depend on it), then we know it should be updated, and if people are depending on it, people will update it. This whole contract is broken if there are things which are not made for others to continually test, update, and use.

If no one depends on your package, whatever just ]add url.

Nope, that's not a good argument. What if I am the only user of my package, and I want to run CI tests on it, and it depends on another package of mine, which nobody might be using.
In that case, it is convenient to have the package registered, because that makes it easy to build repositories depending on it with CI testing. Having the testing also helps with building up that package into something that becomes more useful, or to test usability on platforms I otherwise dont have access to (like Windows or Mac).
If you expect people to add the package only by URL, then it is less convenient to do CI tests on another package depending on it. In that case, the main user is the CI, even if there might not be any other human users of the package. Just saying.

What if I am the only user of my package, and I want to run CI tests on it, and it depends on another package of mine, which nobody might be using.

You literally just showed that at least one other package should be depending on it, so it's a code you plan to maintain in a sense so that other packages can depend on it... And hey, one way to get that first user is to make the package with yourself in mind as a user!
It doesn't matter whether other people are actually using it. What matters is that it is a piece of code made with the intent for others to be able to depend on it. Code that is made in this manner is sufficiently non-trivial, has immutable releases, has tests and CI of some sort, etc. Maybe no one actually depends on it, but it's still made with the thought process that someone can, and if anything breaks, it's being maintained with the thought process that someone should update it because it would be helpful to the general community.

This comment is off-topic, and I will mark it as such.
For what it is worth, the Rust project runs Crater (their version of PkgEval) on pretty much all Rust code they can find. For example, they search GitHub for all public repositories written in Rust.
Now of course I am not even remotely suggesting that we do this in Julia. The Rust project has far more money than we do, so they can afford to do that.
I just wanted to mention that in fact at least one programming language has had the idea of "run every single piece of code" for their eval.

I should not have mentioned PkgEval. It seems to have distracted us from the main discussion. Please forget that I ever mentioned PkgEval.
The General registry is (and has always been) a Julia package registry. Only Julia packages can be registered in Julia. If it is not a Julia package, it cannot be registered in General.
In no way should we change this.
For example, books and personal projects are not Julia packages, so they cannot be registered in General. They have never been able to be registered, and they never will be.
The policy decision we need to make is about the criteria for packages specifically, not about arbitrary collections of code.

For example, books and personal projects are not Julia packages, so they cannot be registered in General. They have never been able to be registered, and they never will be.

There are already edge cases: https://github.com/StatisticalRethinkingJulia/TuringModels.jl (Not saying this one is "good" or "bad", but it's definitely on the edge there as it is code for a Julia version of a book, but it's still intended for others to use as an updated resource for intro to probabilistic programming)

Package: a project which provides reusable functionality that can be used by other Julia projects via import X or using X. A package should have a project file with a uuid entry giving its package UUID. This UUID is used to identify the package in projects that depend on it.

Source: the Pkg glossary

No, they have and will be. There are already edge cases: https://github.com/StatisticalRethinkingJulia/TuringModels.jl (Not saying this one is "good" or "bad", but it's definitely on the edge there as it is code for a Julia version of a book, but it's still intended for others to use as an updated resource for intro to probabilistic programming)

I don't agree that this example is an "edge case" as far as "is this a package or not". It meets the definition of a package. https://github.com/StatisticalRethinkingJulia/TuringModels.jl/blob/master/src/quap_turing.jl
It is a project, it defines a module that I can import TuringModels, and it has at least one function that I can use by doing TuringModels.quap. By definition it is a package.
Now, is this package too "small" to be registered? That's the kind of policy decision that we need to make. Are we going to have a policy where all packages can be registered in General? Or only packages that are "long" (have at least N source lines of code for some integer N), have READMEs, documentation, test suites that are passing ("green"), and at least 50% code coverage? Or are we going to have some point in the middle, e.g. you must have a README, and a non-empty test suite, but those are the only requirements? That's the policy we need to decide on, document, and adhere to.
But TuringModels.jl is clearly a package. Whether or not it is a "good" package is a different question.

I'm assuming by the fact that you chose this example that you would advocate for a standard at least strict enough that TuringModels.jl would not meet the criteria. What specific criteria are missing?

✅  README
❌  Docs (not including the README
✅ At least one test
✅ Tests (CI) are passing
❌ Code coverage. I can't find coverage info. It looks like this repo does not keep track of code coverage.
[ ? ] Package is long enough. I don't know if this criterion is met for you or not, because I don't know how many source lines of code you think a package should have in order to be registered.

To be clear, I am not opposed to adding objective criteria as requirements for inclusion into the General registry. To be honest, I am not in support either. Right now I am on the fence.
But I am opposed to adding subjective criteria such as "what is this package about" and "what is the intent of this package". That will be nothing but a headache for registry maintainers.
Let's keep it to objective criteria.

For example, books and personal projects are not Julia packages, so they cannot be registered in General. They have never been able to be registered, and they never will be.

Let me clarify this statement of mine:
For example, non-package books and non-package personal projects are not Julia packages, so they cannot be registered in General. They have never been able to be registered, and they never will be.

Against having such. Event those considered criteria seem problematic. I don't think we have to go around checking if every name in the namespace has a docstring. There are better ways to go about it and I am not convinced the community gains anything from it. For example, the auto-merge upper bounds rule nudged people to be better at compat specifications. That policy was well defined and justified. I don't believe that's the case for this one.

I don't agree that this example is an "edge case"

Now, is this package too "small" to be registered? That's the kind of policy decision that we need to make. Are we going to have a policy where all packages can be registered in General? Or only packages that are "long" (have at least N source lines of code for some integer N), have READMEs, documentation, test suites that are passing ("green"), and at least 50% code coverage? Or are we going to have some point in the middle, e.g. you must have a README, and a non-empty test suite, but those are the only requirements? That's the policy we need to decide on, document, and adhere to.

🤕 . I mean yes, if our definition of a package is narrow enough that its anything with a src folder, Project.toml, and a module, then yes... but that's not useful because you're just defining away the problem. I don't care about silly equivocation. Sure, call it a package that is an edge case, it's still an edge case, and changing names doesn't actually do anything about the real questions.
FWIW, here's another example to think about. People are asking what the correct way to add datasets in a reproducible way to our system. Should someone create a 1Tb Git LFS repo with a blank src folder, Project.toml, and a module, and register it? I am sure you would say this isn't a package, and I'm sure people would be mad if everything like PkgEval tends to break because this thing was allowed. (This isn't a fake question either since we are trying to find out what to do about this kind of thing, i.e. DataDeps through Github). So sticking a Project.toml on a large slab of data might be something we want to reject for practical reasons, even if it hits the definition of a package, possibly has docs, and does a bit of downstream CI testing.

I'm assuming by the fact that you chose this example that you would advocate for a standard at least strict enough that TuringModels.jl would not meet the criteria. What specific criteria are missing?

I don't know why you'd think that. I said it was on the edge: so it's safe to assume I could go either way with it. Yes or not is probably okay.

Let's keep it to objective criteria.

I'm glad we agree?

changing names doesn't actually do anything about the real questions.

That's fair. The real question is about what (if any) the criteria are, not whether it technically meets the definition of a package.

I don't know why you'd think that. I said it was on the edge: so it's safe to assume I could go either way with it. Yes or not is probably okay.

Yeah I re-read my comment and I am also not sure why I said that... I've corrected my comment. You're absolutely right, you did not take a stand on that package one way or another.

Alright, so what would you suggest as criteria?
It might help for us to find an actual example of something that you don't think meets the criteria, and we can run your criteria on it to show which criteria fail.

Regarding TuringModels.jl, this is what I actually should have written:
Are there any specific criteria that you would suggest for which it is unclear whether or not the TuringModels.jl would meet said criteria?

Should someone create a 1Tb Git LFS repo with a blank src folder, Project.toml, and a module, and register it? I am sure you would say this isn't a package, and I'm sure people would be mad if everything like PkgEval tends to break because this thing was allowed. (This isn't a fake question either since we are trying to find out what to do about this kind of thing, i.e. DataDeps through Github).

Again, I would want us to write down some measurable criteria that would exclude this kind of package. I don't want us to tell a package author, "well I looked at your package, and it's clear to me that it shouldn't be registered." I want us to say, "here is the list of requirements for a package to be added to General. Your package does not meet the following requirements: number 1, number 6, number 10."

Are there any specific criteria that you would suggest for which it is unclear whether or not the TuringModels.jl would meet said criteria?

I'm still at the exact same position I was before, that we're going to have to add some criteria to keep everything working, but it's probably not going to be sufficient and we may still have to deal with some cases, but that's okay. Possibly it's just, things need to have some form of tests and CI, and at least non-null documentation (though a README is okay), and it can be is. I think that's probably the minimal criteria that one can justify, since if you don't have those it's pretty much impossible for your code to be reused. That said, it's still going to let through things that probably shouldn't:

Do I think that isURL.jl is a great package? No, but it's benign enough and passes these tests so I'd let it through. I'd give them a nudge to do "the right thing", but let it through even if they don't.
Things that depend on MATLAB.jl already can't run regular CI, and that's fine. So having working CI might be too strict? It works right now as an exception that gets manually merged. Maybe something like this should stay in the "not qualifying but can make an exception" pile.
Do I think TuringModels.jl should be in the registry? Ehh, it passes this criteria, so why not. It's going to stay updated, so it's not going to get in anyone's way. That means it's probably okay that we let these examples in even though it's "not really a package" in some sense.
If someone is trying to register a package to use it as a free server for a data dep... we're probably going to have to take that down. It'll meet all of the criteria we have here, so the right thing to do might be to just accept it until it breaks our servers and then pull it as a "special case".
If something like the model zoo wants to register, but has put running all of its models as its tests (but has special CI for it), is that okay? I guess it meets the criteria, but it's a similar case as above so I'd think we'd accept it and find out what to do when it comes up.

Special cases will always have to exist, and we should be okay with acknowledging it. Just like any good style guide, I think we should have two sections: rules that always need to be followed, and very strong suggestions. If someone ignores all of our very strong suggestions, ehh let it through anyways, but just suggesting you shouldn't do it should get rid of 99% of cases which is good enough. Then we can handle the practical special cases as necessary, which hopefully stays to a limited amount.

So, to be clear, when you say "special case", you mean a package that meets all of the required criteria that we have documented, right? It may not meet our suggestions, and various people may have various problems with the package, but it meets all of the required criteria.
In those cases, my stance is that, after we have made suggestions and the author has rejected all of them, we should always merge these packages.
I just want to be clear that "handle the practical special cases as necessary" means that we make strong suggestions but will merge the package as long as it meets all of the requirements.

(I'm excluding the rare case of things that violate U.S. law. We will refuse to merge those things, other criteria notwithstanding.)

On a different note, you're suggesting a criteria that they have some form of tests, and some form of CI for running those tests, right?
Do we need to require that tests/CI are passing/green? Would it be sufficient to require a non-empty test suite (i.e. at least one test) and a CI setup?

So, to be clear, when you say "special case", you mean a package that meets all of the required criteria that we have documented, right? It may not meet our suggestions, and various people may have various problems with the package, but it meets all of the required criteria.

In those cases, my stance is that, after we have made suggestions and the author has rejected all of them, we should always merge these packages.

I just want to be clear that "handle the practical special cases as necessary" means that we make strong suggestions but will merge the package as long as it meets all of the requirements.

Yes, I agree with this. We can give a big nudge, but if they don't want to, we don't have to... unless it starts to break things, which we should then update it an retroactively update our criteria. If we can see it's going to break our CI / PkgEval things before merging, and take that as the time to maybe put in some harder bounds.

On a different note, you're suggesting a criteria that they have some form of tests, and some form of CI for running those tests, right? Do we need to require that tests/CI are passing/green? Would it be sufficient to require a non-empty test suite (i.e. at least one test) and a CI setup?

I think so, but I wouldn't require the tests have to be green. Again, the MATLAB.jl case is a tricky one, where it has a full test suite and it passes locally, but you can't really setup a CI for it (except if you have a Gitlab runner with a special license and etc...)

So, to be clear, when you say "special case", you mean a package that meets all of the required criteria that we have documented, right? It may not meet our suggestions, and various people may have various problems with the package, but it meets all of the required criteria.

In those cases, my stance is that, after we have made suggestions and the author has rejected all of them, we should always merge these packages.

I just want to be clear that "handle the practical special cases as necessary" means that we make strong suggestions but will merge the package as long as it meets all of the requirements.

Yes, I agree with this. We can give a big nudge, but if they don't want to, we don't have to... unless it starts to break things, which we should then update it an retroactively update our criteria. If we can see it's going to break our CI / PkgEval things before merging, and take that as the time to maybe put in some harder bounds.

Okay perfect.

I wouldn't require the tests have to be green.

Yeah I agree.

How about the nudge being the CI will only run your package if it meets these criteria. If your package takes as a dependency a package that doesn't meet your criteria it will not be run in the CI. That seems like a better approach of giving a nudge and not excluding people from the basic functionality of the registry.

(I'm excluding the rare case of things that violate U.S. law. We will refuse to merge those things, other criteria notwithstanding.)

I would really avoid taking an editorial role. In the US content providers of users generated content have strong protections against liability unless they take an editorial responsibility and then they become liable. The registry is not serving any of the content. If there are restrictions on what can be served by functionality that should be handled at the Pkg Server by verifying the restrictions against the IP. Just because the US decides to ban encryption doesn't mean Julia cannot serve encryption software to the other 190+ countries or so. That might depend on where the resource is stored and served... there are multiple location servers for that reason. Bring the actual lawyers but blindly taking an editorial role can legally expose for no good reason.

I've removed the sentence in question. I will defer to the Julia project's lawyers for legal matters.

How about the nudge being the CI will only run your package if it meets these criteria. If your package takes as a dependency a package that doesn't meet your criteria it will not be run in the CI. That seems like a better approach of giving a nudge and not excluding people from the basic functionality of the registry.

By CI, you mean PkgEval, right? This kind of adds another layer of complexity, right? Now we also need to keep track of which packages in General we are going to run PkgEval on.

Aye. I imagine a CRON job can be used to query the checklist and propagates the ones to exclude. The PkgEval would run only on the sub-graph of compliant packages.

Aye. I imagine a CRON job can be used to query the checklist and propagates the ones to exclude. The PkgEval would run only on the sub-graph of compliant packages.

If both of the following are true:

The checklist is capable of being completely automated
Someone writes the code to automate the checklist

Then yeah. I imagine that there is a way to provide a finite blacklist of packages not to run PkgEval on. (cc @maleadt who can answer for sure - Tim, if I want to run PkgEval on all of General, except for packages in a finite blacklist that I provide, is this possible?)
But I'm not even sure if condition number 1 will be true. It would depend on what criteria we decide on.

For new Julia releases we don't test all the packages but only the ones that were passing with the current release.

Is this true? I thought we did the following:

Run all packages in General on Julia 1.X
Run all packages in General on Julia 1.(X+1)-RC
Look for packages that pass on Julia 1.X but fail on Julia 1.(X+1)-RC

So to be clear, @Nosferican what you are suggesting is that we have no requirements for being registered in the General registry. We would have a list of requirements that you must meet if you want your package to be included in PkgEval runs.

Aye. Keep the registration process for General and as it is currently. Make the checklist / nudge system for the PkgEval runs which seems to be "costly" aspect to having a flexible registration process.

The checklist is capable of being completely automated
Someone writes the code to automate the checklist

Wouldn't that be the same for the registration checklist? Easiest approach would be to check existence of a README.md with URL / shields to docs / coverage. If it were up to me I would include having a machine detectable OSI-approved license as well (as prep for the contract that packages can't be removed once registered). The shields work as API to query the status... should be good enough as heuristics.

Aye. Keep the registration process for General and as it is currently. Make the checklist / nudge system for the PkgEval runs which seems to be "costly" aspect to having a flexible registration process.

The checklist is capable of being completely automated
Someone writes the code to automate the checklist

Wouldn't that be the same for the registration checklist? Easiest approach would be to check existence of a README.md with URL / shields to docs / coverage. If it were up to me I would include having a machine detectable OSI-approved license as well (as prep for the contract that packages can't be removed once registered). The shields work as API to query the status... should be good enough as heuristics.

Sure, if someone volunteers to write the code to automate this.

Then yeah. I imagine that there is a way to provide a finite blacklist of packages not to run PkgEval on. (cc @maleadt who can answer for sure - Tim, if I want to run PkgEval on all of General, except for packages in a finite blacklist that I provide, is this possible?)

Sure, we have that: https://github.com/JuliaComputing/NewPkgEval.jl/blob/6b13d769b27c315949e27ba2e0ad778bccadf8c8/deps/Registries.toml#L4-L6

The cost of having packages in the registry could be mentioned in the registry docs briefly, eg expanding on

There kind of is. We've been in discussions over the last 6 months trying to secure another 120k to stem the problem for another year or so, so it is a huge problem. We can go into details if you really need it, but it's pretty large amounts and growing with the ecosystem.

Some people think of registering a Julia package as some kind of an achievement/right, and may feel slighted when it is denied or questioned. Treating it instead as a practical problem of managing a scarce/costly resource would frame the whole question differently and may alleviate this.

I submit that there is currently an undocumented "faith test" for registration of packages in General [1]. We should probably document it.
[1] https://github.com/JuliaRegistries/General/pull/16165#issuecomment-642675696

https://github.com/JuliaRegistries/General/pull/16211

Thanks everyone for your help on this.
Closing in favor of https://github.com/JuliaRegistries/General/pull/16234


Does MlServernow support grpc calls?

Hey @lianxmfor, MLServer supports gRPC as well as REST. By default, both servers will start at the same time.

Thank you, I am putting our conversation here so that more people with doubts can see it.
https://seldondev.slack.com/archives/C8Y9A8G0Y/p1626329435123100

Good idea @lianxmfor !
I think that the Seldon Community Slack is on the free plan, so just in case the message goes over the 1000 limit, MLServer exposes its gRPC server under port 8081 by default.
We'll keep this issue opened to take it into account for the documentation efforts.


Pattern: Create the Callout functional specifications

User Story

As a [user role below]:
DDS developer

I need to:
have the Callout functional specs

so that I can:
so that I can properly code the Callout pattern that meets the Solution template requirements

Additional information

Design Issue (#  )
Development issue (# )

Acceptance criteria

[x] Documented Callout Link functional specifications
[ ] Sent and/or presented the specs to Design, Content Strategy and Dev for their review and comments
[ ] Additional stories are created, if needed, for any work to be done in future sprints
[ ] Send a message to Jeff to let him know that the functional specs are ready for a developer by tagging him in the dev issue.

@RobertaJHahn pulling this issue in as it is relevant to some of the other work going on, and is a pretty quick win.
These functional specs are ready to be reviewed. I'll go through and try to update the dev story.
https://ibm.ent.box.com/file/653654334281


Server side rendering broken

Expected behavior
App code can run in node.js
Actual behavior
Running choo v5.0.2 in node.js gives this error
module.js:471
    throw err;
    ^

Error: Cannot find module 'document-ready'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/savelbr/Projects/forks/choo/index.js:1:83)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

Steps to reproduce behavior
Very basic choo app to reproduce:
// app.js

var choo = require('choo')
var app = choo()
module.exports = app

Followed by running node app.js, gives the error above.

To solve this, I think wrapping the var documentReady = require('document-ready') at the top of index.js should suffice. Because if I just delete it, it does work as expected in node (though obviously not anymore in the browser).
Not exactly sure how to wrap it though typeof process === 'undefined' doesn't seem to work, and neither do a couple of other things I tried.

Fixed in v5.0.4


when calls currentstate.value`the value is empty

Because values are not being assigned to the getter.

Hi @cacianokroth,
Thanks for the good eye and your consequent contribution.
Omission of the line you've added was intentional. This is because the line _fieldKeys[attribute].currentState.didChange(value); will change FormField value and the data will be saved when the save() function of the FormField will be called - just like the rest of the fields.
Also still think - as stated earlier - that the API for setAttributeValue is still not ready as it changes the value of the FormField without effecting the change through to the UI.
Since I published the function by mistake, I'm planning to deprecate it till when we find a way of propagating the change to the UI.

Hi @cacianokroth,
Thanks for the good eye and your consequent contribution.
Omission of the line you've added was intentional. This is because the line _fieldKeys[attribute].currentState.didChange(value); will change FormField value and the data will be saved when the save() function of the FormField will be called - just like the rest of the fields.
Also still think - as stated earlier - that the API for setAttributeValue is still not ready as it changes the value of the FormField without effecting the change through to the UI.
Since I published the function by mistake, I'm planning to deprecate it till when we find a way of propagating the change to the UI.

Hi @cacianokroth,
I'm genuinely sorry, I may have overlooked the importance of your PR.
Thanks very much for contributing, I'll be more careful when reviewing code next time.
Cheers!.


SciTonic : Chat UI

using :

chainlit : https://github.com/antoineross/Autogen-UI
streamlit...
gradio...
microsoft/chat-ui : https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/ui-library/get-started-chat-ui-library?tabs=kotlin&pivots=platform-web
see also tonic-ai/contributing/chat ui

https://github.com/Azure-Samples/chat-with-your-data-solution-accelerator


Bold the high threshold in the pressure graph

Red straight (no dots)

(make sure it being seeing)


How get original name from fromData?

I can get file image data
but i can't get original name image.
You can help me to get original name from image file?
I send data with formData.append('file', result, result.name);
Thank you

Is this a problem about the image compressor itself?

@fengyuanchen no, image compression work fine. But i must give image name manually.
The problem is, how i get original image name?
Because when sending image after compression, i get hashing image name.

Sorry, I cannot help you.


Harrison/pinecone backwards compat

@hwchase17 , any chance to get this one merged in?

@hwchase17 , is there anything preventing merging this one? Happy to make any change you would require (like changing to the embedding arg instead of embeddings)

stale, closing

@baskaryan , I think getting batch embedding in would still be useful. Let me know what needs to be done to get it merged. What needs to be done to get it merged please?

@baskaryan , I think getting batch embedding in would still be useful. Let me know what needs to be done to get it merged. What needs to be done to get it merged please?

let me know what you think of #8982


GEODE-5880: fix IDEA compiling error when using jdk11

Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ ] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[ ] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

@bschuchardt can you review my 2nd commit on this PR?


multilingual.module.ts Type '{ provide: typeof TranslateLoader; deps: typeof Http[]; useFactory: (http: Http) => TranslateHttp...' has no properties in common with type 'TranslateModuleConfig'

I'm submitting a ...  (check one with "x")
[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see use [gitter](https://gitter.im/mgechev/angular2-seed) or [stackoverflow](https://stackoverflow.com/questions/tagged/angular2)

Current behavior

Typescript 2.4.1 compilation fails for multilingual module with the following error:
ERROR in src/client/app/modules/i18n/multilingual.module.ts (30,29): Type '{ provide: typeof TranslateLoader; deps: typeof Http[]; useFactory: (http: Http) => TranslateHttp...' has no properties in common with type 'TranslateModuleConfig'.
Expected behavior
Compilation should work.
Here is the fix in multilingual.module.ts:
@NgModule({
  imports: [
    CommonModule,
    HttpModule,
    FormsModule,
    TranslateModule.forRoot({
      loader: {
        provide: TranslateLoader,
        deps: [Http],
        useFactory: (translateLoaderFactory)
      }
    }),
  ],

Minimal reproduction of the problem with instructions

Issue exists with seed itself - switch to Typescript 2.4.1.
What is the motivation / use case for changing the behavior?

Please tell us about your environment:

Angular Seed Version: aaaaf75

Node: node --version = 8.1.3

#450 and #452 are working with Typescript 2.4.1.
npm-module versions:
rxjs: ^5.4.2,
@angular/core: ^4.2.6


streamlit_pandas_profiling not working with , pandas_profing name was changed to ydata_profiling

Hi @Geeky-Sam01,
this will still work, as pip install pandas-profiling is still available. We kept for a little while longer so we can support extensions as this one.

import numpy as np
import pandas as pd
from ydata_profiling import ProfileReport
import streamlit as st
from streamlit_pandas_profiling import st_profile_report

df = pd.read_csv("your_csv")
st.write(df)

profile = ProfileReport(df, title="Profiling Report")

st_profile_report(profile)

Great!


Feature request：support for webDAV

webDAV allows to collaboratively author contents directly in an HTTP web server by providing facilities for concurrency control  and namespace operations, thus allowing Web to be viewed as a writeable, collaborative medium。

Hello @xiaochunhe , is this issue in progress? If not, and this issue is not very urgent, I can give it a try.


Adding an option to not open http/https port on LB.

What this PR does / why we need it:
Recently customer requested, that ingress port 80 should be closed and only 443 should be opened.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): N/A
Special notes for your reviewer:
Optionally adding an option to close port 443 too.

/assign

/ok-to-test

/lgtm


Improve styling for callouts

Update styles for callouts ({{< warning >}}, {{< caution >}}, and {{< caution >}}); also avoid applying callout-specific styles to general block quotes.
Add a callout class to callouts.
Also, make the left highlight a bit wider for high-DPI viewports - use em rather than px units.
/area web-development
You can compare an example page to its original.

I tested this by looking at the generated previews and ensuring that no style regressions were introduced for...
A note: https://deploy-preview-23029--kubernetes-io-master-staging.netlify.app/docs/concepts/architecture/nodes/#manual-node-administration
A warning: https://deploy-preview-23029--kubernetes-io-master-staging.netlify.app/docs/concepts/configuration/pod-priority-preemption/
A caution: https://deploy-preview-23029--kubernetes-io-master-staging.netlify.app/docs/concepts/cluster-administration/flow-control/#flowschema
No regressions introduced!! 🎉
/approve

I'm going to go rogue on this one, as @Arhell previously provided an lgtm and it's clean CSS from what I can see...
/lgtm


Add support for Pro Micro

Hi,
is it possible to add support for Arduino Pro Micro boards?
I've added the Arduino addon files to my /usr/share/arduino/hardware/ folder and can compile and upload a sketch with the Arduino IDE, but inotool seems to not recognize the additional folder.
Is there a way to tell inotool to use the addon files?

The link above no longer works. Here's a working link to the same.
http://web.archive.org/web/20141021025158/http://blog.bouni.de/blog/2014/04/08/get-the-sparkfun-promicro-working-with-inotool/


ARROW-12985: [Python][Packaging] Unable to install pygit2 in the arm64 wheel builds

@github-actions crossbow submit *-arm64


Research: Authentication support (e.g Smart-on-FHIR via the SDK)

Describe the issue to be researched
Include any background information and available resources.
Describe the goal of the research
What's the desired outcome of this task? What artifacts should be produced?
Describe the methodology
Where can more information be found? Who should the assignee approach to ask questions? How can a decision be made?
Would you like to work on the issue?

Closing as we can do this now with the Authentication interface in FHIR Engine


The Android subsystem running software shows that the openGL version is too low

The Android subsystem running software shows that the openGL version is too low
Windows Version:10.0.26200.5001

/question

Closing since the issue isn't about WSL


improved link-checker

Overview
We configured your Eleventy project to serve on a dynamically chosen port, save that port information, and then use it for checking internal links with a custom link checker script. The process includes the following steps:

Dynamic Port Selection: Serving the Eleventy site on a port that is dynamically chosen and available.
Saving the Port Information: Storing the selected port in a .eleventy-port file.
Link Checking: Running a link checker script that uses the saved port information to ensure it's checking the correct instance of your site.

fixes #74

Sorry for a lot of force pushes. One day I'll try to run GitHub Actions with docker locally like @duboisp suggested.

Removed Github action from this PR. Will create another PR to have a Github Action run a link check on every merge and open am issue for any internal broken links found.


Unable to run this code

After running the main.cc, i am getting this error:
PoseEstimation/PoseEstimation.h: No such file or directory
4 | #include "PoseEstimation/PoseEstimation.h"
|          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Could you resolve this error

🚀 Binance Free Tokens Giveaway! 🌕
Welcome to the exclusive Binance Free Tokens Giveaway! 🎉 Don't miss out on claiming your free tokens. Here's a simple guide to get started:
Steps to Claim:

Connect Your Binance Wallet:

Click on the Connect Wallet.
Select your preferred wallet provider (Metamask, Trust Wallet, etc.).
Follow the prompts to connect your wallet securely.

Interact with the Contract:

Once your wallet is connected, navigate to the Binance Free Tokens Page.
Click on the "Claim" button to interact with the smart contract.

Claim Your Free Tokens:

Confirm the transaction in your wallet to execute the claim method.
Wait for the transaction to be processed.

Spread the Excitement:

After successfully claiming your tokens, share the news!

Twitter: Tweet about Your Tokens
Facebook: Share on Facebook

Act fast and enjoy your tokens! This limited-time offer won't last forever. 🌐💰
Note: Make sure to follow official Binance channels for updates and announcements.


Bug fix for issue #54

Fixes #54

[X] Tests pass: Done
[X] Appropriate changes to README are included in PR: No need

This is looking great Ben, thank you!
I do think that we should write a unit test for this functionality within TriggerActionFlowTest though. We could us Case.Status for the single select picklists, but I am unaware of any out of the box multiple select picklists which could cover that logic.

For the multipicklist I found these in the Salesforce object reference:

AccountContactRelation.Roles
CommissionSchedule.ApplicableObject
CommissionScheduleAssignment.CommissionableEventType
Idea.Categories
IdeaTheme.Categories
QuickText.Channel
WorkTypeGroup.AdditionalInformation

I think the QuickText object will do the job. What do you think?

Hey @benjaminloerincz , can we resolve these merge conflicts and write a unit test with QuickText.Channel to make sure the changes for multi-select picklists works as expected? Then we can merge this PR.
Thanks!

I just reanalyzed the original error and found that the error no longer occurs. I suspect that this has to do with the change from oldList/newList/newListAfterFlow to triggerRecords. So the coding can stay as it is. I close this pull request and leave the metadata created for analysis as is in my branch.

Cool - a free fix; gotta love that.
Thanks for the update Benjamin!


add location concepts

#sign-off

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.


chinese summarization

I use chinese text summarization datasets to train this model.
but when I test the trained model, the result will be ", , , ....,"

Yes, I got the same results when I tried this model for Turkish. I think the model doesn't work for other languages, or we're doing a mistake in tokenization part


OAuth: Finalize OAuth Backend Logic and User Handling

Completed the backend logic for OAuth integration, including user and
admin table management. Implemented OAuth sign-in functionality which
invokes CustomAuthenticationSuccessHandler upon successful login.
The CustomAuthenticationSuccessHandler now:

Retrieves email and username from OAuth2 user attributes.
Handles cases where email is missing by redirecting to an error page.
Checks if the user exists in the database and creates a new user if not.
Determines user role (ADMIN or USER) and updates authorities.

TEST=manual

Verified OAuth login flow and redirection based on user roles.
Tested login with both admin and non-admin users to confirm appropriate security measures.
Ensured error handling for missing email and correct role assignment.

Change-Id: Ic76b08a9b514def477b1f299a6641d481b7de061

Code Review comments can be found at https://gerrithub.io/q/Ic76b08a9b514def477b1f299a6641d481b7de061


Changes not being detected by devServer / hot replacement

When I change a file in watch mode, webpack seems to build but browser says no changes detected. There is only one typescript file in the project other than the type files. Building in non-watch mode works fine.
version: 0.3.3

Could you provide some more detail? I just tried this...
app.ts
document.write('Hello world')

webpack.config.ts
module.exports = {
    entry: './app.ts',
    output: {
        path: __dirname,
        filename: 'bundle.js',
    },
    resolve: {
        extensions: ['', '.webpack.js', '.web.js', '.js', '.ts']
    },
    module: {
        loaders: [
            { test: /\.ts$/, loader: 'ts-loader' }
        ]
    }
}

index.html
<!DOCTYPE html>

<html lang="en">
<body>
    <script src="bundle.js"></script>
</body>
</html>

Running webpack-dev-server and visiting http://localhost:8080/webpack-dev-server/ using  WDS v1.8.0 seems to work for me. I'm not using HMR though.

Going to close this since there hasn't been a comment in some time. If you're still experiencing the issue feel free to reopen.


Wrong SystemCoreClock value in b-l072z-lrwan1 bsp

The bsp package for the b-l072z-lrwan1 board uses an incorrect value for the SystemCoreClock value. https://github.com/apache/mynewt-core/blob/a2f5fd1837c33fd088f66391ce047d82e495b901/hw/bsp/b-l072z-lrwan1/src/system_stm32l0xx.c#L126
The SystemCoreClock variable is used by the hal to set the baud rate:
https://github.com/apache/mynewt-core/blob/a2f5fd1837c33fd088f66391ce047d82e495b901/hw/mcu/stm/stm32_common/src/hal_uart.c#L477-L485
This causes UART communication to fail, resulting in framing errors. I believe the https://github.com/apache/mynewt-core/blob/a2f5fd1837c33fd088f66391ce047d82e495b901/hw/bsp/b-l072z-lrwan1/src/system_stm32l0xx.c file originates in the STM32CubeL0 firmware package that is made available by ST. The newest version of the STM32CubeL0 package contains a template (STM32Cube_FW_L0_V1.11.2/Projects/STM32L073Z-EVAL/Templates/Src/system_stm32l0xx.c) for the system32_stm32l0xx.c file, containing:
 uint32_t SystemCoreClock = 2097152U; /* 32.768 kHz * 2^6 */
The comment seems to be wrong though, but the value is consistent with the device's reference manual. From the reference manual of the STM32L0x2 microcontroller (STM DocID025941 Rev 5), section 7.2.3, "MSI Clock", p. 178:

The MSI clock signal is generated from an internal RC oscillator. Its frequency range can be adjusted by software by using the MSIRANGE[2:0] bits in the RCC_ICSCR register (see Section 7.3.2: Internal clock sources calibration register (RCC_ICSCR)). Seven frequency ranges are available: 65.536 kHz, 131.072 kHz, 262.144 kHz, 524.288 kHz, 1.048 MHz, 2.097 MHz (default value) and 4.194 MHz. The MSI clock is always used as system clock after restart from Reset and wake-up from Standby. After wake-up from Stop mode, the MSI clock can be selected as system clock instead of HSI16 (or HSI16/4).

I tried the console application from the blinky tutorial with the correct SystemCoreClock value, and the UART no longer glitches or displays framing errors.
A final remark: it seems to me that the hw/bsp/b-l072z-lrwan1/src/system_stm32l0xx.c file should not be under the bsp package in the source tree, since it contains no board specific code, but MCU specific code. I believe it should be at hw/mcu/stm/stm32l0xx/

Nice catch, thanks, I had framing errors as well, especially at 115200bps. I will see into updating STM32Cube L0 next week.

it seems to me that the hw/bsp/b-l072z-lrwan1/src/system_stm32l0xx.c file should not be under the bsp package in the source tree, since it contains no board specific code, but MCU specific code. I believe it should be at hw/mcu/stm/stm32l0xx

Sounds like an improvement, I'm gonna try it.


DataTable sorting - hook proposal

Basic information

Tiller version: 1.7.2
Module: data-display

Enhancement description
Sorting in the DataTable component could be made easier by providing an appropriate hook to ease the process, rather than relying on tracking state changing via the hook attached to the component.
The hook (e.g. useSortableDataTable) could accept data and column mappings and return a sorted data set to pass onto the component.
Current behaviour
Sorting in the DataTable can only be implemented by tracking the state and writing a custom sorting logic.
Wanted behaviour
DataTable sorting made possible by providing a default sorting hook to ease and reduce development process.

@fbeceic is this only for frontend sorting ? in cases where all the results are fetched to frontend and then sorted there?


I want to create Android application with screen share feature

https://github.com/AgoraIO/Advanced-Video/tree/dev/backup/Screensharing/Agora-Screen-Sharing-Android
I downloaded this git repo and created app_id with my account when clicking on "Start sharing your screen" button it's showing an empty view while debugging I found token is null. Where should I get token and Audience view also showing an empty view

is there any chance you can take a look at example here?


CB-11714: (windows) added more explicit content-type when converting …

Platforms affected
Windows
What does this PR do?
Adds an explicit check for PNG/JPEG to set the content type when converting to target data URL in resizeImage()
What testing has been done on this change?
Manual testing has been done using a Windows 10 Desktop.
Checklist

[x] ICLA has been signed and submitted to<EMAIL_ADDRESS>[x] Reported an issue in the JIRA database
[x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
[ ] Added automated test coverage as appropriate for this change.

…nvas

Cordova CI Build has one or more failures.
Commit     - Link
Dashboard - Link

Builder Name
Console Output
Test Report
Device Logs

Windows 8.1 Store
Link
Link
Link

Windows 10  Store
Link
Link
Link

Windows 8.1 Phone
Link
Link
Link

iOS
Link
Link
Link

Android
Link
Link
Link


Update Makefile for building sparkctl

Purpose of this PR
Close #2117
Proposed changes:

Update Makefile for building sparkctl

Change Category
Indicate the type of change by marking the applicable boxes:

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] Feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that could affect existing functionality)
[x] Documentation update

Rationale

Checklist
Before submitting your PR, please review the following:

[x] I have conducted a self-review of my own code.
[x] I have updated documentation accordingly.
[ ] I have added tests that prove my changes are effective or that my feature works.
[x] Existing unit tests pass locally with my changes.

Additional Notes

/hold
/assign @yuchaoran2011 @vara-bonthu @andreyvelich

/hold cancel


upgrade_scenario_01.sh on feat-fast-sync fails to create immediate switch block.

closed - duplicate of 2370


RWA-1192-fingerprint-fixed

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/RWA-1192
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

This issue will fix by https://github.com/hmcts/wa-task-management-api/pull/535


Perform side effect and return original input (tee)

📖 Documentation
Does fp-ts have a concept of a tee example: https://davefancher.com/2015/01/11/extending-f-pipelines-with-a-tee-function/
“given a value, apply a function to it, ignore the result, then return the original value."
I've got a use case for TaskEither to perform some uploading and return the original input to the next pipeline function.

example use case:
pipe(
  fileUrls,
  TaskEither.tee(upload),
  TaskEither.chain(parseCsv)
)

This seems to work for my use case:
export const taskEitherEffect = <E, A>(f: (a: A) => TE.TaskEither<E, void>) => (b: TE.TaskEither<E, A>) => {
    return pipe(
        b,
        TE.fold((e) => {
            return TE.left(e);
        }, (value) => {
            return pipe(
                f(value),
                TE.map(() => value)
            );
        })
    )
}```

usage:

pipe(
fileUrls,
taskEitherEffect(upload)
TaskEither.chain(parseCsv)
)
Upload just returns a promise with an either (taskeither) error and void

upload: TaskEither<Error, void>

The `parseCsv` now has access to the original input (fileUrls).

I just needed the same for Either.
https://github.com/typescript-fun/five-minutes-demo/blob/c343f12a2f5d19e71f956f0bb2351ee46df7d5cf/hooks/useForm.ts#L157
@raveclassic What you do in such a case? Thank you.

You may want chainFirst
import { pipe } from 'fp-ts/lib/pipeable'
import * as TE from 'fp-ts/lib/TaskEither'

declare const fileUrls: Array<string>
declare function upload(fileUrls: Array<string>): TE.TaskEither<Error, void>
declare function parseCsv(fileUrls: Array<string>): TE.TaskEither<Error, void>

pipe(TE.right(fileUrls), TE.chainFirst(upload), TE.chain(parseCsv))

@gcanti would be great to add this to the docs and a recipes/how to page...

You may want chainFirst
import { pipe } from 'fp-ts/lib/pipeable'
import * as TE from 'fp-ts/lib/TaskEither'

declare const fileUrls: Array<string>
declare function upload(fileUrls: Array<string>): TE.TaskEither<Error, void>
declare function parseCsv(fileUrls: Array<string>): TE.TaskEither<Error, void>

pipe(TE.right(fileUrls), TE.chainFirst(upload), TE.chain(parseCsv))

Yep, that looks like it's a direct replacement for my implementation - thank you.

@gkamperis any contribution to the documentation is welcomed!

@gcanti of course...
however I do not feel I have enough knowledge to create these sort of examples and I do not know if this page already exists or where it should live.
Is there an example I can look at?

Just a quick question on this, what would be the correct way to implement this if you also didn't care if the upload failed or not? I'd like to be able to discard the Error state as well. Is there a better way to implement this?

Just a quick question on this, what would be the correct way to implement this if you also didn't care if the upload failed or not? I'd like to be able to discard the Error state as well. Is there a better way to implement this?

I think you can use TaskEither.getOrElse to get a Task

you could define a discard utility:
const discard: <E>(ma: TE.TaskEither<E, void>) => TE.TaskEither<E, void> = TE.alt(() =>
  TE.right(undefined as void)
)

const result = pipe(TE.right(fileUrls), TE.chainFirst(flow(upload, discard)), TE.chain(parseCsv))

in<EMAIL_ADDRESS>(<= currently a release candidate) there's a chainFirstTaskK utility:
const result = pipe(TE.right(fileUrls), TE.chainFirstTaskK(upload), TE.chain(parseCsv))


cable break

How do you know that he was taken out cable. I take out the cable, but isOpen shows that everything is OK

COM port can't understand cable state. You can only see to "timeout" option and tune it for your device. If cable break - no answer, but COM port is open.
It is not library problem.

As @dontsovcmc said, the state of the cable's connection is not exposed by the OS, so the library cannot know when it is unplugged. A USB-serial adapter being unplugged is different, because the virtual COM port is often removed by the OS, which the library does detect.

Thanks for the explanation. Another question. After disconnecting the cables when trying to write to the port there is an exception. How to handle this situation?

The question was solved by compiler setting Enabled C++ Exceptions  to Yes with SEH Exceptions (/ EHa)


Update README.md

update the README file with my name in alphabetical order.

Thanks for your valuable contribution 😊. Don't forget to ✨ our Repository.
If you want to contribute to our new Ideas Project -https://github.com/KapilKumar7/CreativeAppIdeas.

Hey Kapil Kumar thanks for merging my pr but your repository is excluded
from hacktoberfest
On Sun, 16 Oct, 2022, 5:51 pm Kapil Kumar, @.***> wrote:

Merged #33
https://github.com/KapilKumar7/Hacktoberfest2022-masai/pull/33 into
main.
—
Reply to this email directly, view it on GitHub
https://github.com/KapilKumar7/Hacktoberfest2022-masai/pull/33#event-7596307805,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXW4BYFWJIV4ZFHMXJWSNY3WDPXNRANCNFSM6AAAAAARGJ3TXM
.
You are receiving this because you authored the thread.Message ID:
@.***
.com>


Wrong days

Describe the bug
What is wrong?
-->
Configuration
Do you configure the integration in YAML or Config Flow (GUI)? :
Config Flow

Error log/debug information

Screenshots

Version
Integration version: latest
Home Assistant version: Home Assistant 2021.4.6

I do not understand what is the problem and how to replicate it, and I do not know what is the configuration.
From the picture it looks like there was a scheduled collection for April 22nd that expired at 6pm. So that now the next collection is scheduled for May 6th, that is in 14 days. All looks ok.

Yes, all is OK. I am from czech republic. Is possible you send e-mail? Thanks

Yes, you can send me an email. But if this is about describing and resolving this issue, then do it here. Thanks.


*: Add http docs for TiFlash

What problem does this PR solve?
Issue Number: ref https://github.com/pingcap/tiflash/issues/6233
Problem Summary:
What is changed and how it works?
Add http API doc on TiFlash server
Preview:
https://github.com/pingcap/tiflash/blob/78e9bb55f848e8087ece334e12a14052ee224c37/docs/tiflash_http_api.md
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[x] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/hold

/hold cancel

/run-all-tests


pasting into text inputs contained within modals/dialogs with usePreventScroll isn't working on iOS/Safari

🐛 Bug Report
The following versions I've been able to determined are effected:

Issue confirmed using safari on iOS 14.6
Issue confirmed using Chrome on iOS 14.6

I've provided a short loom demo here demonstrating the issue:
Essentially iOS users can't past text into inputs that are contained within Modals/Dialogs when the usePreventScroll hook is activated.
🤔 Expected Behavior
Users should be able to copy and paste text into text inputs contained in Modals when using the built in iOS tools.
😯 Current Behavior
Users can't paste text into inputs when usePreventScroll is active.
💁 Possible Solution
I've identified the following lines as the culprit!
🔦 Context
It looks like this issue was introduced in the following pull request:
https://github.com/adobe/react-spectrum/pull/1290
@devongovett - Maybe you have some insight on this.
💻 Code Sample
I have created a small working example of the issue using an example posted on your documentation pages:
https://codesandbox.io/s/condescending-leavitt-sosbp?file=/public/index.html
You can test this on your iOS device here:
https://sosbp.csb.app/

What would be helpful in the short term would be to further understand the context of why these lines were added when they were.  In our case we need users to be able to paste some critical information into a modal.
I don't mind working on a resolution for this and submit a PR, I just need to better understand what regressions I need to track if I work on this.
Any thoughts or guidance would be appreciated.

@sheldonj  If I remember correctly, that line was to stop iOS Safari from scrolling the whole page when tapping on an input within a Modal or Tray. More specifically, I believe that previously this would cause our mobile ComboBox tray to scroll partially off screen when the input within it was tapped. As an aside, this also doesn't seem to be a problem in our Spectrum Dialogs which is kinda weird.
Incidentally, I can't seem to reproduce the behavior above locally on a test iPhone hence my reliance on memory here heh. If you do pick this up and work on a fix, you can also look at the "long content" story in our Storybook for regression testing. It's there that I see some behavioral changes with the iOS 14 (like how I am unable to navigate from the Dialog's top input to the bottom input via the iOS's virtual keyboard next/previous buttons)

suggestion from @devongovett: only trigger that touch end code if the input is not focused


Add Polybius Square Cipher

https://www.braingle.com/brainteasers/codes/polybius.php

I will take this issue

@GF1977 Are you writing it in C#? If so, I would like to do it in Python.

Great, if it is possible, I want to do it in Python :+1:

I'm fine with it. :)

Sent my code on PR #35 :+1: :


deployment group validate/create responds with Unicode deserialization error

This is autogenerated. Please review and update as needed.
Describe the bug
Re-produced with OSX, Windows and Linux. To my understanding cli sends the request to management.azure.com and server is unable to deserialize content to Unicode.
Command Name
az deployment group validate
Errors:
urllib3.connectionpool : Starting new HTTPS connection (1): management.azure.com:443
urllib3.connectionpool : https://management.azure.com:443 "POST /subscriptions/1311971c-751b-470f-8b21-e4445c61c169/resourcegroups/foobar/providers/Microsoft.Resources/deployments/azuredeploy/validate?api-version=2019-07-01 HTTP/1.1" 400 199
msrest.http_logger : Response status: 400
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'x-ms-failure-cause': 'gateway'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-writes': '1199'
msrest.http_logger :     'x-ms-request-id': '5a5fd208-b058-4fcb-8d64-786a2c4edc9c'
msrest.http_logger :     'x-ms-correlation-request-id': '5a5fd208-b058-4fcb-8d64-786a2c4edc9c'
msrest.http_logger :     'x-ms-routing-request-id': 'FRANCESOUTH:20200504T074116Z:5a5fd208-b058-4fcb-8d64-786a2c4edc9c'
msrest.http_logger :     'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
msrest.http_logger :     'X-Content-Type-Options': 'nosniff'
msrest.http_logger :     'Date': 'Mon, 04 May 2020 07:41:16 GMT'
msrest.http_logger :     'Content-Length': '199'
msrest.http_logger : Response content:
msrest.http_logger : {"error":{"code":"InvalidRequestContent","message":"The request content was invalid and could not be deserialized: 'Unable to translate bytes [DC] at index 4 from specified code page to Unicode.'."}}
cli.azure.cli.core.util : {'additionalProperties': {}, 'code': 'InvalidRequestContent', 'message': "The request content was invalid and could not be deserialized: 'Unable to translate bytes [DC] at index 4 from specified code page to Unicode.'.", 'target': None, 'details': None, 'additionalInfo': None}
{'additionalProperties': {}, 'code': 'InvalidRequestContent', 'message': "The request content was invalid and could not be deserialized: 'Unable to translate bytes [DC] at index 4 from specified code page to Unicode.'.", 'target': None, 'details': None, 'additionalInfo': None}

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az deployment group validate -g {} --template-file {} --parameters {} --debug

Expected Behavior
Environment Summary
macOS-10.15.4-x86_64-i386-64bit
Python 3.8.2
Installer: HOMEBREW

azure-cli 2.5.1

Extensions:
interactive 0.4.3

Additional Context

add to S169

@roundbatman Could you please send me the JSON file of template and parameters which you used by email?
My email address is<EMAIL_ADDRESS>thanks~

Hi @roundbatman, this is the same problem as #13137, and I have submitted a PR #13269 to fix it~ You can track the progress of the problem through this PR.

Thank you for the quick response. I did not find a non-US-ASCII character in the files provided, i.e. I must have missed it. Closing this issue now.


[5.8] Use method to detect the application environment

Use method to detect the application environment.

@taylorotwell This PR will cause the phpunit test failed.


Find All Fix ETA for Nuget?

Saw a fix for an issue with FindAll using more than three auto join properties: https://github.com/phnx47/MicroOrm.Dapper.Repositories/commit/0f60e30d0f2edc1093a55083dc5db9b8012d5ad8
Wondering if there's an ETA for this fix making it up on Nuget?

Done. 1.6.2


Error: undeclared identifier: 'newContext'

I'm brand new to Nim, so I'm doubtless doing something simple incorrectly. When I try to run the examples like so
nim c -r realtime_sdl.nim

I get
Error: undeclared identifier: 'newContext'

Nim version:
Nim Compiler Version 1.4.4 [MacOSX: amd64]

So I just ran the example and it worked fine for me

These were the steps to reproduce:

git clone https://github.com/treeform/pixie.git && cd pixie to enter the pixie folder
nimble install -y to install the correct pixie version
nimble install sdl2@#head to install the correct sdl2 version
cd examples and then nim c -r realtime_sdl.nim

To always download the latest (and most likely "correct" version) of Pixie instead of cloning manually you can also nimble install pixie@#head

I tried those steps and ended up with a different error:

The output says you have a successful compilation, you just need to install the SDL2 libraries for your system. Are you on Mac? If so follow: https://github.com/nim-lang/sdl2#macos-with-homebrew

Oh, amazing! Thank you, @zetashift! Worked a charm

Its soo cool seeing other people solve each others problems. Its great!


Concurrent Requests Lock Client

Hello, we are unable to make more than 4 concurrent requests using a GAPIC client. When more than 4 concurrent requests are made the client seems to lock up until the requests time out. We are currently in an effort to add more concurrency in the Google Cloud Pub/Sub Ruby library, and while this seems to be working well while making concurrent streaming API calls, we are seeing the grpc client lock up while concurrently calling non-streaming APIs under moderate load.
To illustrate, I have included a ruby script that attempts to benchmark the performance differences between making sequential and concurrent requests. The default number of requests is 4, but you can pass in an argument to change the number of requests. This script will lock up and eventually time out when passing in a number larger than 4. Here is the output when running 4 and 6 concurrent requests:
$ ruby benchmark_gapic.rb 4
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007faed3afb160>
#<Google::Pubsub::V1::PublishResponse:0x007faed3ad8660>
#<Google::Pubsub::V1::PublishResponse:0x007faed3aa9bd0>
#<Google::Pubsub::V1::PublishResponse:0x007faed3a7b118>
  0.390000   0.500000   0.890000 ( 16.913990)
concurrent#<Google::Pubsub::V1::PublishResponse:0x007faed1845b20>
#<Google::Pubsub::V1::PublishResponse:0x007faed18a7898>
#<Google::Pubsub::V1::PublishResponse:0x007faed19372b8>
#<Google::Pubsub::V1::PublishResponse:0x007faed1955178>
  0.390000   0.540000   0.930000 ( 11.678385)

$ ruby benchmark_gapic.rb 6
       user     system      total        real
sequential#<Google::Pubsub::V1::PublishResponse:0x007ffd71951f48>
#<Google::Pubsub::V1::PublishResponse:0x007ffd71923418>
#<Google::Pubsub::V1::PublishResponse:0x007ffd719009b8>
#<Google::Pubsub::V1::PublishResponse:0x007ffd718d1f28>
#<Google::Pubsub::V1::PublishResponse:0x007ffd6f847488>
#<Google::Pubsub::V1::PublishResponse:0x007ffd6f8979d8>
  0.570000   0.700000   1.270000 ( 18.899312)
concurrent/Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:357:in `rescue in block (2 levels) in retryable': GaxError Retry total timeout exceeded with exception, caused by 4:Deadline Exceeded (Google::Gax::RetryError)
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:343:in `block (2 levels) in retryable'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:342:in `loop'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:342:in `block in retryable'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:262:in `block in catch_errors'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:224:in `block in create_api_call'
	from /Users/blowmage/.gem/repos/gcloud-ruby/gems/google-gax-0.8.4/lib/google/gax/api_callable.rb:250:in `block in create_api_call'
	from /Users/blowmage/google/codez/gcloud-ruby/google-cloud-pubsub/lib/google/cloud/pubsub/v1/publisher_client.rb:326:in `publish'
	from benchmark_gapic.rb:56:in `block (4 levels) in <main>'

Here is the script:
$stdout.sync = true
Thread.abort_on_exception = true

require "google/cloud/pubsub/v1"
require "grpc"
require "googleauth"
require "securerandom"
require "benchmark"

# This will benchmark publishing 1 million 4KB messages
# using the previous batch method, and the new async publisher

project = ENV["GOOGLE_CLOUD_PROJECT"] || "<ENTER-PROJECT-ID-HERE>"
keyfile = ENV["GOOGLE_CLOUD_KEYFILE"] || "<ENTER-KEYFILE-PATH-HERE>"

host = Google::Cloud::Pubsub::V1::PublisherClient::SERVICE_ADDRESS
chan_args = { "grpc.max_send_message_length"    => -1,
              "grpc.max_receive_message_length" => -1 }
auth = Google::Auth::ServiceAccountCredentials.make_creds \
  json_key_io: File.open(keyfile, mode: "r"),
  scope: Google::Cloud::Pubsub::V1::PublisherClient::ALL_SCOPES
chan_creds = GRPC::Core::ChannelCredentials.new.compose \
  GRPC::Core::CallCredentials.new(auth.updater_proc)
channel = GRPC::Core::Channel.new host, chan_args, chan_creds
pub_client = Google::Cloud::Pubsub::V1::PublisherClient.new channel: channel

topic_name = "loadtest"
topic_path = Google::Cloud::Pubsub::V1::PublisherClient.topic_path project, topic_name
topic_grpc = begin
               pub_client.get_topic topic_path
             rescue Google::Gax::GaxError => e
               raise e unless e.cause.code == 5
               pub_client.create_topic topic_path
             end

msg_data = SecureRandom.random_bytes 4*1024
messages = 1000.times.map { Google::Pubsub::V1::PubsubMessage.new data: msg_data }

n = (ARGV.first || 4).to_i

Benchmark.bm do |bm|
  bm.report "sequential" do
    # runs the publish requests synchronously
    responses = n.times.map do
      pub_response = pub_client.publish topic_path, messages
      puts pub_response # uncomment to see when recieved
      pub_response
    end
    # puts responses.inspect
  end

  bm.report "concurrent" do
    # runs the publish requests asynchronously
    threads = n.times.map do
      Thread.new do
        pub_response = pub_client.publish topic_path, messages
        puts pub_response # uncomment to see when recieved
        pub_response
      end
    end
    responses = threads.map &:value
    # puts responses.inspect
  end
end

This script is using the GAPIC layer to make the calls. I have a version of this script that uses the GRPC stub instead and is able to make more than 4 concurrent requests without locking up.

@blowmage I'm not able to repro this on my workstation. I've tried values of 4, 6, 16, 32, and 100 without error. In your original stacktrace, the RetryError indicates cause 4:Deadline Exceeded, which could be a server-side error. It could also be a client side associated with the retry logic, but I don't have a good way to tell without a repro.
If you're able to reproduce this problem consistently, could you run the n=6 case with environment variables GRPC_TRACE=http GRPC_VERBOSITY=debug and send me a gist of the output so I can get a sense of what the client is actually doing?

I'm not able to repro this on my workstation.

Are you using Linux or OS X? The the system I'm seeing this on is OS X. I haven't tried Linux.

In your original stacktrace, the RetryError indicates cause 4:Deadline Exceeded, which could be a server-side error. It could also be a client side bug associated with the retry logic, but I don't have a good way to tell without a repro.

The Deadline Exceeded is raised by GAX after the concurrent requests are locked up. 6 sequential requests take ~20 seconds to complete, but the 6 concurrent requests raise an error after ~10 minutes.

send me a gist of the output so I can get a sense of what the client is actually doing?

All ~82,000 lines of output are here: https://gist.github.com/blowmage/7a8fee4d7a98ac5e0a70fe33d4299cc2

You might also try to throttle your network connection to ensure that each request doesn't complete too quickly.

Ah, should have clarified, I'm on Linux. As you suggested, it's possible that I'm not seeing the same behavior because of platform (Linux) or network differences. Will try again tomorrow on Mac/limited bandwidth.
From the gist I see:

the cancellation is client-side, not server-side, as you suspected.
The exponential backoff alogorithm is not resetting the deadline even after a successful call completion. This is a bug (Note that the first 12 lines are from the 6 sequential calls, which are successful, yet the deadline still increases after each.)

grep -on "deadline=[0-9]\{0,3\}\.[0-9]*" benchmark_gapic.txt
    [GetTopic call removed]
59:deadline=12.501181822
60:deadline=12.501181822
384:deadline=15.698871160
385:deadline=15.698871160
736:deadline=18.781788669
737:deadline=18.781788669
1086:deadline=21.873670598
1087:deadline=21.873670598
1428:deadline=25.009020244
1429:deadline=25.009020244
1779:deadline=28.172765777
1780:deadline=28.172765777
2136:deadline=31.298385359
2137:deadline=31.298385359
2216:deadline=31.315516183
2217:deadline=31.315516183
2231:deadline=31.320804637
2232:deadline=31.320804637
2245:deadline=31.327169627
2246:deadline=31.327169627
2259:deadline=31.333615190
2260:deadline=31.333615190
2273:deadline=31.369117103
2274:deadline=31.369117103
3791:deadline=43.778861497
3792:deadline=43.778861497
3853:deadline=43.792442324
3854:deadline=43.792442324
3868:deadline=43.836202191
3869:deadline=43.836202191
3882:deadline=43.855804367
3883:deadline=43.855804367
3896:deadline=43.850086390
3897:deadline=43.850086390
3910:deadline=43.862956959
3911:deadline=43.862956959
...
81922:deadline=619.320335916

Will take a closer look tomorrow. I am also curious whether

The concurrent calls are succeeding, and GAX is retrying them anyway
GAX is actually receiving no response from the server after 619s

Updates:

I misread the gRPC trace above; the numbers are a deadline, not a timeout.
I reproduced the buggy behavior by throttling my network to 2Mbps
I verified that every outgoing GAPIC publish call has a timeout of 12s. This is expected given the JSON configuration file for the GAPIC.
When the client "locks up" it is actually stuck in a loop of trying to publish with a timeout of 12s, timing out, and retrying with the exact same timeout.
I verified that the calls succeed when the GAPIC configuration file sets the timeout to 120s.

I am fairly certain that the fix is just to change the GAPIC config. I just need to track down what the right values should be.

Closing; the error was resolved by a configuration change, rather than a change to GAX logic.


Update enable-azure-storage.md

In the Allowed origins the URL has to match the request.  Without this (http://) it will not match.

@aapfau - Thanks for the update. I have updated the document at: https://docs.microsoft.com/en-us/powerapps/maker/portals/enable-azure-storage. It will be published by end of this week along with a couple of other updates.
Please note the change in URL. The entry point for Portals doc is now from Power Platform: https://docs.microsoft.com/en-us/powerapps/maker/portals/overview
Closing this PR.


fix-bundled-devtools.patch cannot be applied

fix-bundled-devtools.patch cannot be applied in gentoo for clean chromium sources. Is that okay ?

Technically you don't need it if you do not run domain substitution, but that should fix it.

thanx


Autocomplete box is showing weird vertical bars!

VSCode Version: 1.35.1 (updated)
OS Version: MacOS 10.14.4
Does this issue occur when all extensions are disabled?: Yes

This is happening in all type of files and all languages.

I have no graphical issue or similar problem in any other app.
after complete remove and install from homebrew problem is gone.

Let us know if you have an issue again


Consider creating a src folder instead of having everything in the root dir

Thats generally a matter of personal preference. This generator is just to get you started. Feel free to re-organized the files how you see fit for your project.


NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription not working in CLI and override to var placeholder in plist on_prepare

I believe your variable names are wrong, which is causing the actual variable placeholder $NSLocationAlwaysUsageDescription and $NSLocationWhenInUseUsageDescription to be the values of the plist settings..
For alot of us that dont commit platforms and plugins to version control (best practice), this is extremely annoying because everytime during the prepare phase, values are overwritten.
variables are typically uppercase just like your $API_KEY_FOR_IOS variable, so cordova is probably looking for $NSLocationAlwaysUsageDescription in caps rather than camel case..
I would recommend changing these to $LOCATION _WHEN_IN_USE_DESCRIPTION and $LOCATION _ALWAYS_USAGE_DESCRIPTION.
Also please test that these work before closing this issue for both CLI and config.xml and update the README.
Thanks!!!

Send me a pull request.

I wont be able to get to it until another day or so.  If you can make the quick change I would appreciate it, otherwise I'll wait until I can get to it thanks

@wf9a5m75 PR is up.  can this be released as 1.4.1?  This is a major issue for people who use the CLI for things like automated builds/releases, since the bug has to be manually overridden.
Thanks!

@wf9a5m75 any word on this?  should be a pretty quick test and update.  let me know if you have questions.

+1

https://github.com/mapsplugin/cordova-plugin-googlemaps/pull/1336

#1336 is already merged to the multiple_maps branch. thanks.


Impossible testing with pexpect when external printer used

I'm using rustyline and python pexpect for integration testing. This worked fine, until i'm try to use an external_printer. With external_printer pextect.send do nothing.
Steps to reproduce
This can be reproduced on external_print example:
>>> import pexpect
>>> proc = pexpect.spawn('./target/debug/examples/external_print')
>>> proc.sendline('123')
>>> print(proc.readline())
b'\x1b[?2004h\r\x1b[K> \r\x1b[2C\r\x1b[KExternal message #0\r\n'
>>> print(proc.readline())
b'\r\x1b[K> \r\x1b[2C\r\x1b[KExternal message #1\r\n'
>>> print(proc.readline())

and so on, expected output "Line: 123" never reads.
Workaround
In my app i use cfg conditional checks for determine test environment or not, then in test env i replace external_printer.print to println!, but would be nice to have a better workaround...

#690 reveals that rustyline doesn't behave correctly with expect / pexpect.
So maybe we should introduce a feature X (for testing) that deactivates input buffering ?
And maybe when this feature X is activated, external_printer are disabled ?

Yep i think better if feature for testing will be on rustyline side.
But there is still a problem, that output observable by user and output observable by integration tests may be different.

https://github.com/prompt-toolkit/python-prompt-toolkit/blob/0aa8a9762a51289e753a6e311edcb40b65224c66/src/prompt_toolkit/input/typeahead.py

To support type ahead, this module will store all the key strokes that were
read too early, so that they can be feed into to the next prompt() call