inheres in at some time URI re-used with different meaning

From<EMAIL_ADDRESS>on April 24, 2013 15:15:10
We had been using BFO_0000052 for inheres_in (atemporal) and BFO_0000053 for bearer_of. These are declared inverses in RO.
BFO2 has re-used these URIs for relations with different semantics - inheres-in-at-ALL-times and bearer-of-at-SOME-time.
Complicating the picture, these are not declared as inverses, but they probably should be: https://code.google.com/p/bfo/issues/detail?id=144 If this axiom is added to BFO2, then at least the atemporal and temporalized forms sharing the same URI will be the same in terms of their basic OWL axioms.
However, they are not the same at the FOL level, and we must be very careful about overloading the IRIs. The differences will probably leak into the OWL.
E.g.
'human with parkinsons' EquivalentTo human and BFO_0000052 some 'PD'
This is obviously not correct with the BFO2 at-some-times reading (in fact it's not clear that this is allowed in BFO2 since the LHS is non-rigid). However, we make statements like this all the time with the atemporal relation, intending a RO2005-style reading (see critique for details).
I think it's very dangerous to re-use the same URIs. It would be safer if BFO2 were to use different URIs than the ones already in use.
Or perhaps this notion of URI sharing will not work. Maybe RO should just mint RO IDs for these relations if we can't have a guarantee that the same URI won't be reused with a different meaning.
See also: https://code.google.com/p/bfo/issues/detail?id=163
Original issue: http://code.google.com/p/bfo/issues/detail?id=165

From<EMAIL_ADDRESS>on April 24, 2013 13:15:01
Issue 81 has been merged into this issue.

From<EMAIL_ADDRESS>on April 24, 2013 14:35:07
There is a typo in the above. I said:

human with parkinsons' EquivalentTo human and BFO_0000052 some 'PD'

I meant

human with parkinsons' EquivalentTo human and BFO_0000053 some 'PD'

When using the labels from RO this says

human with parkinsons' EquivalentTo human and 'bearer of' some 'PD'

When using the labels from BFO2 this says

human with parkinsons' EquivalentTo human and 'bearer of at some times' some 'PD'

Clearly it's problematic to overload the URI with these two different senses.

From<EMAIL_ADDRESS>on April 24, 2013 14:40:23
Here is another example. We may wish to say
(bearer_of some open) DisjointWith (bearer_of some closed)
(e.g. open or closed heart valves)
This is the kind of axiom that is very useful to have for error checking. If we end up with an interpretation in the spirit of the original RO paper then this is perfectly justifiable.
However, if we overload the URIs then in BFO2 we end up saying:
(bearer-of-at-some-time some open) DisjointWith (bearer-of-at-some-time some closed)
Because the some-times form is weaker, the overall axiom is stronger when used with a disjointness axiom. In fact too strong - the above axiom is patently false for any object that can switch state like a heart valve.
In summary, it is plainly very wrong to try and re-use the same URI for the atemporal and temporalized forms here

From<EMAIL_ADDRESS>on April 24, 2013 14:43:40
I don't see how "Clearly it's problematic" . In the actual case of a disease, 'bearer of at some times" is a reasonable interpretation of 'bearer of' -- it's certainly not 'bearer of at all times.'  I could imagine a more specific relation for an incurable disease like PD (something like bearer of continuously from some time until death), but that would just be a subclass of 'bearer of at some time'.  What is the clear problem here?  Can you be more explicit about some incorrect inference or other consequence?

From<EMAIL_ADDRESS>on April 24, 2013 15:45:32
The disjoint example might show a difference, if you can show that your example is interpretable in ro2005ish semantics. However as stated you can't have a heart with open or closed valves - since you can only make atemporal statements either the valve is open or it isn't.  No change is available.
Remember, the ro semantics are all-time, and here generic versus specific won't help.
Regarding the desirability of such error checking constraints, I agree and will think about how to enable such.

From<EMAIL_ADDRESS>on April 24, 2013 17:20:41
Hi Larry
The curability issue is a bit of a sidetrack. Let's switch to
influenza.
The standard pre-BFO2-OWL approach is to say something like this:
[1] Human-with-flu EquivalentTo human and 'bearer of some 'infected-with-flu'
And assume a RO-2005 type interpretation (glossing over a lot here,
see Niels' and Stefan's paper for more) - the statement is true at any
given moment of time. If you're the bearer of a flu infection at t,
then you're an instance of human-with-flu at t. This is different than
at-all-times (which would be incorrect - most people can gain or lose
the infected status, as you point out), and -- crucially -- different
from at-some-times. This is because times have to be the same on
either side of the equivalence predicate for it to work, it's not just
at any time.
In fact if we are to switch out the relation to the BFO2-OWL
at-all-times we have:
[2] Human-with-flu EquivalentTo human and 'bearer of at some time'
some 'infected-with-flu'
According to the BFO2-OWL release notes this is expanded to:
instance_of(i,Human-with-flu) <->
instance_of(i,Human) &
exists t : [ instance_of(d,Infected-with-flu)
bearer_of(i,d,t) ]
Which only makes sense if we interpret
instance_of(i,Human-with-flu)
As being
exists t & instance_of(i,Human-with-flu,t)
But in fact BFO2-OWL doesn't support temporal instantiation /
non-rigid classes.
I can provide a more rigorous treatment in FOL with proofs, but it
might be better if you first look over my critique where a lot of this
ground is covered.
The TR approach and the AR have different ways of interpreting the
relations, which is why we get into trouble if we mix.
Let's take another example
[3]  (bearer_of sick) DisjointWith (bearer_of healthy)
This is biologically valid if we assume the statement to be true for
any given moment (I am never both sick and healthy at the same time -
and let's just assume a simple binary model of sickness here for
simplicity). I have a neeed to make statements like this.
What happens if we switch out the relations behind the schemes to be
the BFO2-OWL ones, which are supposedly equivalent?
[4]  (bearer_of-at-some-times sick) DisjointWith (bearer_of-at-some-times healthy)
This is contradicted by most people. There are plenty of examples of a
human h who is sick at t1 and healthy at t2.
The bottom line is that I don't want my statements of type [3] to be
read as [4], which is wy it's crucial to use a different ID/URI for
the at-some-times form and the atemporal form.

From<EMAIL_ADDRESS>on April 24, 2013 17:25:50
Alan: re "The disjoint example might show a difference, if you can show that your example is interpretable in ro2005ish semantics"
That's the plan. Need to not confuse the relations in the interim.

From<EMAIL_ADDRESS>on April 25, 2013 08:58:15
There is damage that is done by making relations different - it makes interoperation less likely. Therefore a balanced decision needs to be made when making such decisions. In the case of bearer of, there was general agreement on the interpretation of bearer-of, temporally. You wish to do something that has a deleterious effect on the basis of a maybe. I believe the example you have given is wrong. The assertion
(bearer-of some open) disjoint-from (bearer-of some closed)
is not a statement that would be correct by RO2005ish semantics. That's because an ROish semantics would not make quantify bearer-of as for all times, as this is by far the less common case, and because qualities, by nature are the sorts of things that are supposed to be gained or lost in change.
That it is "useful" or that you might find some different interpretation in which it is correct, brings insufficient benefit considering the downside - that users will then be forced to make a decision about which term to use, without having any factual basis for doing so.
Take the has-participant definition from RO2005. It uses some-time quantification
P has_participant C = [definition] for all p, if Pp then there is some c, t such that Cct and p has_participant c at t.
Bearer of, at the class level would have this pattern.
C bearer_of Q = [definition] for all c, if Cc then there is some c, t such that Qqt and C bearer_of q at t.
Under this interpretation, "ROish", the statement
(bearer_of some Open) disjointFrom (bearer_of some Closed)
is false.
Even in the case that the at-all-times class-level relation was defined, for example to record that a type has a rigid determinate, (e.g. all material entities have some mass at all times), the case would adequately be handled the by the relation bearer_of at all times.
In summary, the motivating example is semantically incorrect. The choice of temporal qualification of bearer_of as at-some-time is consistent with the RO-2005 style of definitions, and the use case motivating the example is adequately handled by the current temporal relations.

From<EMAIL_ADDRESS>on April 25, 2013 09:29:24
Is there any way in BFO2 to record that a heart valve may not be simultaneously open and closed or that a person may not simultaneously be an adult and a child.  If so, how?
This seems to me to be what Chris's disjointness axiom is attempting to express.

From<EMAIL_ADDRESS>on April 25, 2013 10:55:48
All this pain seems to me to result from our inability to make quantified statements over variables (a la FOL), and forcing some of the most critical quantifications into places where they can have unfortunate consequences.
The Disjoint-from bearer argument wants to express that there is no time when a heart valve is both open and closed.  No combination of bearer-at-some-time assertions can do that, because there is no way to say the "some" time is the same one in both statements.
Is there some reason that we can't make the existing atemporalized relations into ternary relations that make the time explicit, at least at the instance level?  Then it would at least be possible to express the open/closed disjointness.  Would that satisfy both sides?

From<EMAIL_ADDRESS>on April 25, 2013 11:41:07
To Answer David:
Agreed. I think it would be expressed as the none overlapping of parts of life of the heart during which each quality obtains. I have another relation I was going to introduce in the next iteration to express this sort of thing- roughly
Q quality-of-during CHP
Where q is a quality and CLP is a continuant history part.
We want to say, then, that there are no parts of a hearts history such that for one open quality-of-during and also closed quality-of-during
I'll be happier when there's a worked example, but hopefully the above shows that there is a plausible strategy.
To Answer Larry.
Attempts thus far seems to make us lose too much of the inference we find useful in OWL. But suggestions on how to do this are welcome. But see what you think of the above, which effectively relies on overlaps, something we can (almost) do in OWL.

From<EMAIL_ADDRESS>on April 25, 2013 16:13:08
Alan: "In the case of bearer of, there was general agreement on the interpretation of bearer-of, temporally"
I wasn't aware of this
Alan: "(bearer-of some open) disjoint-from (bearer-of some closed)
is not a statement that would be correct by RO2005ish semantics. That's because an ROish semantics would not make quantify bearer-of as for all times, as this is by far the less common case, and because qualities, by nature are the sorts of things that are supposed to be gained or lost in change.
"
Of course qualities can be gained or lost. It does not follow from this that the statement would be incorrect. The fact of the matter is that bearer-of is not in the RO2005 paper, so there's no basis for your claims. Had it been, it's not necessarily the case that it would have been at-some-times. Quantification of the statement at all times is the more useful (note: note the same as an at-all-times TR). E.g. all t : instance_of(i,Human-with-flu,t) -> exists d instance_of(d,has-flu,t) & bearer_of(i,d,t). Note that gain or loss is not an issue here, since we have a non-rigid class.
This documentation is missing from the existing atemporal object property (partly because these relations have been living in limbo for the last year), although all usage has been in this sense. I will add clearer docs, together with a default all-t statement-level quantification for all C-C statements. This will clearly differentiate the meaning from the BFO2 relation.
With regards to my original request - I now think it's best if BFO_0000052 is ceded to BFO2 and we mint a new RO ID for the atemporal relation, and transfer all current usages across.

From<EMAIL_ADDRESS>on April 26, 2013 06:11:55
Chris, you missed important points. First, either contemplated sense of the term you want here are available in the TR. Second, the example you gave was flawed under any interpretation. Third, the issue of non-rigid classes is orthogonal. The TR relations are agnostic to this distinction.  What is needed for that is not extra relations, but a plan for a working embedding in owl. There are two candidates and I'm confident we will arrive there. There is no plan for bfo1 owl to accommodate that at all.
My conclusion remains that, at least for a subset of relations including bearer of and participates in, minting new terms is not justified from a technical point of view, as the temporal relations satisfy will work unproblematically. A choice to use other relations for foundry ontologies would be damaging, would raise my objection and would need to be mediated by the coordinators and operations groups.
This is quite distinct from the situation with part of, where although there are still damages, there is more justification for taking an alternative route.

From<EMAIL_ADDRESS>on April 26, 2013 08:31:19
"First, either contemplated sense of the term you want here are available in the TR."
You haven't demonstrated this. And we keep straying from the point. The original point was that BFO_0000053 was re-used with a different meaning from how we have been using BFO_0000053. You may not like how we have been using it, you may think there are problems inherent in any alternative to TRs, but that doesn't alter the fact that it was reused with your interpretation.
In the course of this discussion I have come to accept this. The only option left if we are to keep using the bearer-of relation without committing to the TR strategy is to create a new relation.
"Second, the example you gave was flawed under any interpretation."
Demonstrate this.
"A choice to use other relations for foundry ontologies would be damaging, would raise my objection and would need to be mediated by the coordinators and operations groups."
I have been trying to avoid this for the last year. However, I see no other way. The choice is (1) TRs (2) some alternative to TRs. Given that you have blocked (2) from BFO2, the only option is to make the alternatives somewhere else.

From<EMAIL_ADDRESS>on April 26, 2013 09:22:11
> "First, either contemplated sense of the term you want here are available in the TR."
Chris: You haven't demonstrated this.
Alan: We have only touched on the all-times or some-times ro-ish interpretations? Each is straighforward because there is no issues of genericity. Please be specific about where you think I've failed.
Chris: And we keep straying from the point. The original point was that BFO_0000053 was re-used with a different meaning from how we have been using BFO_0000053.
Alan: I'm sorry, I just don't know what you are talking about. You can a supposed example of why we didn't have the same meaning. I've shown that the example is bad. All you've demonstrated is that you aren't even clear about what the possible meanings it could have, never mind the one you propose it does have.
Chris: You may not like how we have been using it, you may think there are problems inherent in any alternative to TRs, but that doesn't alter the fact that it was reused with your interpretation.
Alan: You don't have an alternative. All you have is criticism of the TR approach and loose appeals to the undefined relations you are suggesting sometimes leading to acceptable entailments.
Chris: In the course of this discussion I have come to accept this. The only option left if we are to keep using the bearer-of relation without committing to the TR strategy is to create a new relation.
Alan: You've come to your conclusion, which I believe is misplaced. I've come to the conclusion that I don't know what it takes to convince you and so this becomes a coordination issue.
"Second, the example you gave was flawed under any interpretation."
Chris: Demonstrate this.
Alan: I did in my comments above. You asked for detailed responses. I gave you that. The other readers seem to get it. I think it is your turn to show why I haven't.
"A choice to use other relations for foundry ontologies would be damaging, would raise my objection and would need to be mediated by the coordinators and operations groups."
Chris: I have been trying to avoid this for the last year. However, I see no other way. The choice is (1) TRs (2) some alternative to TRs. Given that you have blocked (2) from BFO2, the only option is to make the alternatives somewhere else.
You haven't tried hard enough. Your only offer is to accept the status quo of relations with no BFO interpretation. I haven't blocked (2) - there just hasn't been any alternative offered that comes with a proper BFO consistent FOL interpretation. You keep saying you can create logical definitions that are consistent with P1. Do so. Then we'll have an alternative, and if it works I will be very happy. But you can't keep blocking with an alternative whose only basis is your opinion that it works well enough and that you should be able to, sometime in the future, come up with a BFO consistent semantics.

From<EMAIL_ADDRESS>on June 26, 2013 12:44:50
the temporally qualified inheres_in and bearer_of would be inverses if we did not have specific dependence.
Action:

Is specific dependence between processes and continuants equivalent (logically) with has-participant.
What would go wrong if we only had inheres_in and not specifically depends between dependent continuants and independent continuants.

If answer to both is that nothings is gained by specifically depends on either
a) Rename inheres_in specifically depends on (but keep as alternative term)
or
b) Keep only inheres_in
Note: ro2005 interpretation of inheres_in would make inheres_in support migration of qualities, which is specifically disallowed, so that is not a correct interpretation.
Barry suggests that we keep specifically depends on to allow for Chris "broader use of" inheres in.
Alan considers that (some polite synonym for: 'nonsense')


HTML Validation Error: Unknown element

When using this module in NuxtjS2, I get the following HTML validation error when using the cld-image element:
Unknown element <cld-image>

I am using it like so:
              <cld-image
                :public-id="post.photoURL"
                class="rounded-circle me-1"
                type="fetch"
                width="40"
                height="40"
                crop="fill"
                gravity="auto"
                :alt="`${post.displayName}'s avatar image`"
              ></cld-image>

The app works, just that I get the above warning in my validator. Any advice on how to fix?

Hey, I am closing this issue as it is targeting the v1 version and it is really old (more than one year stale)


Typescript auto imports should be absolute in our repo

Not sure about other repositories, but we have the convention of always using absolute imports. Relative ones even cause lint issues:

I think the current strategy chooses whichever path is shortest. We're tracking allowing this to be explicitly configured with https://github.com/Microsoft/TypeScript/issues/21860 as part of https://github.com/Microsoft/TypeScript/issues/20619


What Are the Most Important Modules That Are Needed?

I know you guys worked on a basic users module, but how about a small list of modules that are essential to build the JAWS ecosystem? what's the highest priority functionality do you think is needed at this point?
Maybe create a markdown file with that list, and have the community PR their ideas of the lambdas modules they'd like to have?

Let's get it going in this Issue.  In the next few days, I'll move it to a wish list located here.
Below are themes.  People are going to want various expressions of these themes (this one uses SES, this one uses Mailchimp).  But, imagine a world where all of this stuff is already written in aws-modules ready for lambda deployment(!!!)

Users/Sessions CRUD - Bonus if you include sign on via popular 3rd party services (e.g., Github)
Analytics/Event Functions - Captures common user events
Image functions - Resize, filters, etc.
Twilio functions - Send SMS
Email - Transactional email functions (e.g., receipt, welcome, where you been?)
Email - Marketing - Blasting html emails to many addresses for dirt cheap via Lambda + SES
Stripe Webhook Handlers
• Slack Webhook handlers
Webhook handlers for all the things
3rd Party Authentication Handlers - Pre-built authentication with the most popular peeps.

Awesome! that should be enough to get the ball rolling! But I thought we already have Users/Sessions CRUD?!

I have to rewrite it slightly for aws-module format.  But it's one of those aws-modules that will implemented several ways.  Of interest, is doing it with AWS Cognito too.  We're making one change to the aws-module dir structure today, after that, we should be good to get going.

oh I see! it seems that AWSM is a completely separate entity from JAWS. So I'm guessing the whole jaws.json format will be replaced with awsm.json? Or in other words, I should follow the structure provided in the AWSM repo, is that correct?

@eahefnawy Yes, JAWS projects will have a jaws.json in their root folders, but all aws-moodules will have awsm.jsons in their modules.  The dir structure in the AWSM repo will change slightly today, but I don't think it will affect your development at all.
Also, adding another list item to my list above.

@eahefnawy Ok, we're done with the module structure:  https://github.com/awsm-org/awsm

woooo! Awesome! looking into it!

haha I like the hand gesture in the logo

@eahefnawy Thanks!  We're currently building an aws-module that provides essential JAWS utilities which will be the first example.  It's a bitt different since it doesn't actually have any lambda functions or endpoints, it consists only of code meant to be shared across other aws-modules in a JAWS project.

+1 Stripe webhooks

interesting, I was just about to ask how env vars should be handled in aws modules! Should I expect that the env vars that are needed for the module will be provided by the developer? I think the JAWS framework has a way to handle that, right?
Also, what about node modules? according to AWS Lambda docs, the node modules folder should be in the root directory of the lambda. However, since a lot of the AWS modules will have multiple lambdas that probably share the same node modules, maybe it should be in the lib directory instead?
I'm currently working on twilio awsm cause it seemed the easiest to start experimenting with, and I faced both of these questions. I'll get to Stripe next once I wrap my head around it.

@eahefnawy Put environment variables that your awsm expects in the "lambda" properties in awsm.json files.  You can see an example here.  It's up to the user to set those.  But that is where you specify which ENVs your awsm needs.
In the awsm README's Structure section you can see that the node_modules should be at the awsm's root.  When your lambda function is packaged, it recreates the aws_module structure, with your lambda in a subfolder (just like the module is).  We recommend putting your node_modules in the awsm root and not the lib folder.  Node/NPM knows to look up a few parent directories to fetch node_modules so this will work best.
Twilio is going to be so sweet!


Meet new UX specs

#major# due to api change from on-input to onInput

:+1:

:+1:

Approved - good stuff


Declare "method" outside of the loop in "uninstallPlugin"

This is @IaroslavMazur's suggestion:

it should be more efficient to declare method outside the for loop. Possibly, even with --via-ir.

The reference is for the method variable declaration here:
https://github.com/PaulRBerg/prb-proxy/blob/27594d50f049330c5acfa6cf45448152a2932ecf/src/PRBProxyRegistry.sol#L264

I tested this now. What I did:

Deploy the basic plugin (which has two methods) to Goerli
Install the basic plugin on a proxy using the current version of the registry (the one with method defined within the loop)
Define an adjusted version of PRBProxyRegistry with the method defined outside the loop (as suggested by @IaroslavMazur)

Note: I enabled the optimized profile when deploying

Deploy the adjusted registry to Goerli
Install the basic plugin on a proxy using the adjusted version of the registry

Breakdown:

Tx
Gas Cost

Inside the Loop
122,310

Outside the Loop
122,358

Thus, contrary to our expectations, it turns out that declaring method outside the loop increases the cost. And the reason for this is via IR - I've started this Twitter discussion about how surprising via IR can be.

Thus, contrary to our expectations, declaring method outside the loop increases the cost. And the reason for this is via IRhere.

How very weird, indeed! 🤔
Thank you for diving into this!


logging gracefully closed uTP connection

This change is

r? @canndrew
(maidsafe_highfive has picked a reviewer for you, use r? to override)

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from the review on Reviewable.io


vimPlugins.vim-agda: init at 2022-03-01

Description of changes
Init the vim-agda package. With the whole  #232078 of it all, I just threw on vimPlugins: update to actually generate the plugin. We should probably wait for #232899 to get merged, and then rebase this onto master.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

merged #232899

merged #232899

Thanks for letting me know, I've rebased onto master now and rerun the update script

Looks like nvim-treesitter's tests are failing because we were on a commit when a language's queries were added but the bot didn't catch up and add it to the lock file yet. This shouldn't be an issue any more once we rerun the udpate script

@ofborg eval (That failure for x86_64-darwin was definitely spurious, it seemed to build the wrong commit. Maybe the force-push did it in? Wonder if I can even call ofborg)

Looks like nvim-treesitter's tests are failing because we were on a commit when a language's queries were added but the bot didn't catch up and add it to the lock file yet. This shouldn't be an issue any more once we rerun the udpate script

Alright, I'm pretty sure that's fixed now. Ofborg did fail on x86_64-darwin, but I'm pretty sure that's spurious, and it's building the wrong commit. If you look in the log, you can see it building c-grammar-0.0.0+rev=424d014, which is the version that c-grammar has on master, even though this PR has upgraded to c-grammar-0.0.0+rev=cac392a. The other ofborg builds, which pass, are building the correct version of c-grammar.
I tried rerunning ofborg, but it didn't work.


Text implicit macro fails when encountering interpolated strings

When implementing a script, this leads to a cryptic compilation error
val foo = "foo"
started.logger.info(s"$foo")

📕 BSP: build unclosed string literal [location => file:///private/var/folders/ss/1cdxdk1j36xb7sgmdqsthzy00000gq/T/%3Cconsole%3E:0:9 until 0:9]

Very strange! I can't really reproduce it with any of 2.12, 2.13 and 3.x.
That said, I'll push a fix to remove some needless complexity in that interface


SW-4647 Fix display versus comparsion values for accession remaining quantity in inventory create validation

was using the raw value for display and localized value for comparison, switched that around now

No problem, looks good!


recommend 0.5.1 in get started

The get started documentation should probably recommend the newest version,
which is 0.5.1 at the time of writing. We also add a link to the releases page which
allows to find out if the recommended version is up to date.

Coverage remained the same at 89.811% when pulling 43ce54dae792be8ebbbb80c9856c86c75730716a on mriehl:patch-1 into 8a236987fbe8fc8c5d65286f9415e5a17721f0a2 on iheartradio:master.

There is also a little typo, maybe you can add this correction to your PR ?
Also in build.sht add domain package names [...]

build.sht --> build.sbt

thanks! LGTM

@MrCitron let's address that in another PR.


react-scripts not found

During my work on #260 I've noticed an issue that can't be fixed in Guppy right now & Guppy doesn't display anything what's wrong.
Describe the bug
If node_modules folder is missing there will be an error message that react-scripts can't be found.
This will happen on projects cloned from Github or if you restore a previously deleted project from recycle bin and re-import it to Guppy.
To reinstall node_modules we're adding a feature see PR #318.
To Reproduce

Create a CRA project
Open the project folder in Finder/Explorer & delete node_modules folder
Reload Guppy (just to see that there are no dependency but this step is optional)
Any started task will fail with the erro message from the screenshot below

Expected behavior
On any task run with-out node_modules folder, display an error dialog that's giving details to the issue & bail early. The info will give details how to fix the problem.
We could also display a button in the dialog so node_modules can be reinstalled from that notification. But I think that's optional as there will be a button in the UI.
Screenshots

Environment:

OS: any
Version: master
Node version: latest

Todos

[ ] Add check if node_module folder exists to dependencies.service.
[ ] Add the check to taskRun & launchDevServer in task.saga.
[ ] Display an error dialog & bail early if node_modules missing.

I tried to reproduce but got a different error, probably because I have a global version of react-scripts installed. I guess this does not affect this issue since we are checking if node_module folder exists, but posting it just in case.

@menor Yeah I think because you have react-scripts installed globally, it probably moves on to the next module that it finds missing (I'm speculating but it would make sense).
For the original suggestions in the issue...

On any task run with-out node_modules folder, display an error dialog that's giving details to the issue & bail early.

We could also display a button in the dialog so node_modules can be reinstalled from that notification. But I think that's optional as there will be a button in the UI.

@AWolf81 I don't think these will be necessary anymore right? Because all Task panes will now be hidden completely when #318 lands. Or is there another case that would require this?

@melanieseltzer Yes, you're right. There is no other case. Once reinstall lands this is not needed as any button will be hidden and we're not running into this issue.
I think we can close this once reinstall is merged.

Closing as we're checking that all dependencies are installed. Reinstall feature merged.


BCM accumulation correction

resolves #373
before correction:

after correction:

This is magic. I don't quite understand how such a simple fix works, but thank you kindly!

Build seems to be failing now, can you check?

That's odd, i didn't account it would compile in PlatformIO, should change the max() it into std::max() ?

Yep.

Hold on. -- I'll include the new example hue-value-test for the bonus of this.


Add Machine.Specifications.Runner.Console to fix test script

TestMe.bat tries to execute the runner from Machine.Specifications.0.8.3, but the package isn't installed.
In 0.9 versions of mspec, the console runner has been removed from the main package and is now distributed separately in the Machine.Specifications.Runner.Console package.
I have added that package to the test project and updated the batch file to call the correct version of the runner.

Ta.


fix: Improve path kebab case message and error on snake_case

What/Why/How?
The issues were reported by a user. The message didn't make sense, so it is fixed. And it didn't catch snake_case but did catch camelCase`.
Reference
Testing
I added tests to the PR.
Screenshots (optional)
Check yourself

[ ] Code is linted (no, when I run prettier, it makes a lot of changes)
[ ] Tested with redoc/reference-docs/workflows (shouldn't impact those)
[x] All new/updated code is covered with tests

Fixes #297.


Improvements to MAGIC BSC recipes

Maintainers
All recipes need a maintainer, who can check that they still work after changes to esmvaltool. Maybe @jvegasbsc could do it? Or would you have time @nperezzanon?
Recipes options and their documentation
recipe_combined_indices_wp6.yml

Could you better describe the valid values for moninf and monsup? From the code it looks like moninf can be null or 1-12 and monsup can be 1-12, but this is not mentioned in the documentation. We tried running the diagnostic with moninf 12, but it crashed.
Could you better describe the relation between running_mean and moninf/monsup? From the recipe, it looks like not all combinations of settings are valid
Setting Multi_year_average to true results in a crash

recipe_extreme_index_wp7.yml

Setting metric to cdd results in a crash

recipe_modes_of_variability_wp4.yml

Setting frequency to MAM results in a crash
Setting ncenters to 5 leads to a crash, can you indicate what valid values are in the documentation
detrend_order: it would be good if you could indicate what value range is expected
About start_historical, end_historical, start_projection, end_projection: these settings look a bit duplicate, because the datasets already have time ranges. Changing these settings results in a crash for the cases we tried, but maybe we did it wrong. Can you write in the documentation how to change these settings? Are there additional conditions/relations that should hold?
cluster_method is specified in the recipe, but not in the documentation.

recipe_multimodel_products_wp5.yml

time_series_plot: the documentation does not look like it's correct, because it does not match the recipe.
moninf: what does 'left blank' mean? What value do I put here, 'null'?
climatology_start_year, climatology_end_year, anomaly_start_year, anomaly_end_year -> it looks like these are the same as for the datasets, so why specify them at all?

recipe_toymodel_wp4.yml

beta -> can you add the valid range in the documentation?

Naming of recipes
Could you please remove all the _wp4, _wp6, _wp7 endings from the recipes etc? Those do not convey much information to most users.
Code quality
If you could work on improving any of the points listed below, would be great, but I can understand it if you do not have time to fix all issues.

code is not well aligned, i.e. there are missing spaces, making it hard to follow the control flow
there are many variables defined that are never used, making it difficult to follow what the author of the code is trying to do, it would be nice if you could improve this
the messages that are printed either do not contain any informative text or it is in Spanish and still not informative, it would be nice if you could improve this
quite a few variables have Spanish names, making it difficult to understand the code for people who do not speak Spanish, it would be nice if you could improve this
the code is written as one long script instead of split up into functions with a clearly defined purpose, making it difficult to follow. It would be nice if you could improve this, but this may be too time consuming.

Hi,
I've created the branch https://github.com/ESMValGroup/ESMValTool/tree/doc_magic_bsc to include the corrections you suggested.
I've started with the Beta parameter from toy model recipe and I've realized that the plot isn't displayed in the document https://github.com/ESMValGroup/ESMValTool/blob/doc_magic_bsc/doc/sphinx/source/recipes/recipe_toymodel.rst
Is this the expected behaviour?
Could you also confirm that this is the correct procedure to add the corrections you are suggesting?
I keep working in this branch and when I finished I will do a merged requested, isn't it?
Thanks!

I've started with the Beta parameter from toy model recipe and I've realized that the plot isn't displayed in the document https://github.com/ESMValGroup/ESMValTool/blob/doc_magic_bsc/doc/sphinx/source/recipes/recipe_toymodel.rst
Is this the expected behaviour?

This looks like an issue that I fixed in the old pull request. Can you merge the version2_development branch into your new branch and check again?

Could you also confirm that this is the correct procedure to add the corrections you are suggesting?
I keep working in this branch and when I finished I will do a merged requested, isn't it?

Yes, that would be great.

Note that you can build and view the documentation locally as described here:
https://github.com/ESMValGroup/ESMValTool/blob/version2_development/CONTRIBUTING.md#how-to-build-the-documentation-locally

Hi @bouweandela,
I'll try to answer recipe by recipe:

Toy Model:
beta range -> DONE
data -> it should work with monthly and daily data.
see Jasmin folders /work/scratch-nompiio/nperez/
recipe_toymodel_wp4_20190212_113407
recipe_toymodel_wp4_20190213_114615

Multi-model product:
time_series_plot the documentation does not look like it's correct, because it does not match the recipe.
--> CORRECTED
moninf: what does 'left blank' mean? What value do I put here, 'null'?
--> CORRECTED I've updated the documentation.
climatology_start_year, climatology_end_year, anomaly_start_year, anomaly_end_year -> it looks like these are the same as for the datasets, so why specify them at all?
--> Yes, they are the same as for the datasets, but the R code cannot read the dates from the header of the recipe and they should be repeated to be an input of the R code matching with the data subset done by the preprocessor.

I keep doing the revision.
All the best, Núria

Hi again,
I’ve improved:

recipe_capacity_factor_wp7.yml
It would be nice if the plot contained the names of the wind turbine, so you can see what is what.
--- > names added!
You could check the output on Jasmin: /work/scratch-nompiio/nperez

Naming of recipes --> Removed "_wp#"

Combined Climate Extreme Index documentation page

Variables should be per recipe
tasmin and tasmax are mentioned, but they are not used in a recipe?

I don't understand this comment, sorry. This functions should work with at least the variables indicated.
The optimal configuration is Tmax when metric is set as t90p, Tmin when metric t10p, SFwind if metric is Wx, and precipitation if metric is cdd or rx5day, but eventually a user could be interested to compute with Tmax the metric t10p.
What do you suggest to do with this recipe?
Thanks,
Núria

Hi Nuria,
Thank you for the updates and explanations. Can you please make a pull request? That makes it a bit easier for me to see what is going on.
Toy model

data -> it should work with monthly and daily data.

It would be great if you could add that in the documentation
Multi-model product

climatology_start_year, climatology_end_year, anomaly_start_year, anomaly_end_year -> it looks like these are the same as for the datasets, so why specify them at all?

Yes, they are the same as for the datasets, but the R code cannot read the dates from the header of the recipe and they should be repeated to be an input of the R code matching with the data subset done by the preprocessor.

The R code can read the dates from the metadata provided to the diagnostic script by the preprocessor, similar to how to you get the filenames, have a look at the contents of the metadata.yml file in the preprocessor output directory. You can see an example of how to read that data here (you'll need to slightly adjust for your case of course, to get the dates for both the climatology and the anomaly):
https://github.com/ESMValGroup/ESMValTool/blob/11477a82b7ce9d9e5b31c3354053dbf85b2cb29d/esmvaltool/diag_scripts/quantilebias/quantilebias.R#L57-L91
Combined Climate Extreme Index

This functions should work with at least the variables indicated.
The optimal configuration is Tmax when metric is set as t90p, Tmin when metric t10p, SFwind if metric is Wx, and precipitation if metric is cdd or rx5day, but eventually a user could be interested to compute with Tmax the metric t10p.
What do you suggest to do with this recipe?

Ok, I think I understand now. How about adding all the valid combinations to the recipe, so it computes everything?
diagnostics:

  extreme_index_tasmax:
    description: Calculate insurance extreme indices t90p and t10p from maximum near-surface temperature.
    variables:
      tasmax:
        preprocessor: preproc
        mip: day
    scripts:
      t90p:
        script: magic_bsc/extreme_index.r
        metric: t90p
      t10p:
        script: magic_bsc/extreme_index.r
        metric: t10p

  extreme_index_tasmin:
    description: Calculate insurance extreme index t10p from minimum near-surface temperature.
    variables:
      tasmin:
        preprocessor: preproc
        mip: day
    scripts:
      t10p:
        script: magic_bsc/extreme_index.r
        metric: t10p

  extreme_index_sfcWind:
    description: Calculate insurance extreme index Wx from near-surface wind speed.
    variables:
      sfcWind:
        preprocessor: preproc
        mip: day
    scripts:
      wx:
        script: magic_bsc/extreme_index.r
        metric: Wx

  extreme_index_pr:
    description: Calculate insurance extreme indices rx5day and cdd from precipitation flux.
    variables:
      pr:
        preprocessor: preproc
        mip: day
    scripts:
       rx5day:
        script: magic_bsc/extreme_index.r
        metric: rx5day
       cdd:
        script: magic_bsc/extreme_index.r
        metric: cdd

Hi @bouweandela,
Thanks for your comments, I've created the pull request.
I need time to have a look to all the information.
Núria

Thank you! Note that field can be removed from all recipes, it is no longer needed with the latest version of esmvaltool.

Hi,
I've removed 'field' from the recipes. Other modifications are:
-recipe_extreme_index_wp7.yml
Setting metric to cdd results in a crash
--> It works with precipitation (See output on Jasmin)
The metric options are not correctly formatted on the documentation page
--> I have updated the documentation.
In fact, these comments are related to your last suggestion of include all combination in the recipe_extreme_indices. However, a user of the Magic portal should be able to select a metric which will operate on the corresponding variable. Do you know how this modification will affect the use of the portal?
Cheers, Núria

However, a user of the Magic portal should be able to select a metric which will operate on the corresponding variable. Do you know how this modification will affect the use of the portal?

Yes, it will affect the portal, but I think it's absolutely fine if all metrics are always computed. The user can then just view the results they are interested in (it does not matter if there are extra results, right?).

Oh, I see... And what about the time of computation and the memory used? I think this is very important to optimize the performance of the portal.

I think it will not make a big difference in run time, as esmvaltool computes diagnostics in parallel. There will probably be an increase in memory use, but there are other recipes that also use a lot of memory (e.g. I just ran the perfmetrics recipe and it needs about 50 GB of memory). By the way, there is a command line option, esmvaltool --diagnostics, to run only a selection of the diagnostics available in the recipe, so esmvaltool users can always do that if they do not want to compute the complete recipe.

Dear Bouwe,
To fix the problem with setting frequency to MAM in recipe_modes_of_variability_wp4.yml, I've fixed a bug in the ClimProjDiags R package. A new version is already published on CRAN (https://cran.r-project.org/web/packages/ClimProjDiags/index.html). I think I don't need to update anything else in ESMValTool to include this update.
After some considerations, I have created a new branch to update recipes extreme_indices and combined_indices: https://github.com/ESMValGroup/ESMValTool/tree/develop-extreme. I hope this will simplify the review of the modifications.
Kind regards,
Núria

After some considerations, I have created a new branch to update recipes extreme_indices and combined_indices: https://github.com/ESMValGroup/ESMValTool/tree/develop-extreme. I hope this will simplify the review of the modifications.

Thank you. Can you make a pull request?

I have just merged #995 and marked the issues that it solved in the issue description above. Could you please have a look at the remaining items?

Is there any chance to finalize this @nperezzanon ?
If not, please close.

Not for now, sorry.


PR for #50 - Update StructureFilters to use semantic roles in determing predicate

#50

@chess-equality, I've left some comments. I didn't bother repeating myself in all the places the comment applied but most of them apply to many places. Also, please make the field all the filters use just filter. No need to describe what type of filter in the filter class.

@chess-equality, please let me know when you're done here. I thought the push meant you were finished but it doesn't look like it. When you are ready make sure you mark all my comments as resolved and mention here that it's ready for review.

@BFergerson Ok got it thanks, yes I'm not yet done still working on the rest (part ii).

@BFergerson I'm done with the fixes and this is ready for review.

@chess-equality, this looks good. You can forget what I said about not making a method a static method. If you can make a method static go for it. I just thought it was odd but I'm getting IntelliJ hints to make them static too.

@BFergerson Ok thanks, no worries.


unionstore: add checkpoint API to support TiDB savepoint feature

Please sign the DCO.

/merge

/merge

/merge


Change in the description of Support Version

SQL Server 2019 is listed in the Supported source and target versions in the Detail of the download URL, but not in the docs.
https://www.microsoft.com/en-us/download/details.aspx?id=53595

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

Note that publishing in this repository is suspended until Tuesday, May 25. Merging will resume Tuesday. Authors can still review and sign off on PRs in the interim. Thanks.

The information has been updated.


Update "remove a term from the obsoletion list"

related to #6547

@nicolevasilevsky @monicacecilia
Please review. I will add this to the curation call for discussion.

we discussed this on the call - it's fine to merge this @sabrinatoro as long as you are willing to enforce this and communicate it to the community.

I am VERY uncomfortable with saying that an SOP is in place as long as one person is willing to enforce it.
We either decide that this proposal is the SOP to remove terms from the obsoletion list "because it is the right thing to do for mondo", or we decide that the SOP is to save terms from obsoletion every time someone asks (without any additional discussions).
Maybe we need to consider how much additional work this SOP will add? We need to discuss this again before we merge and communicate with users.
@nicolevasilevsky @monicacecilia @cmungall @matentzn
Note: I don't mind doing the work. I just don't want SOP relying on me (or anyone) not getting hit by a bus or winning the lottery and disappearing in nature (because life is just crazy and full of surprises)

I just want to say Thank You to everyone who supported me through the years. My name is Manuel Franco, New Berlin, Wisconsin. My story of how I won the Powerball lottery of $768.4M is a bit of a tale. I have been playing Powerball tickets for 6 years now since I turned 18. I bought my first ticket on my 18 birthday. I was feeling very lucky that day because I had contacted Dr. Odunga Michael to help me with the winning Powerball numbers. I really had that great great feeling that I looked at the camera wanting to wink at it. I only did a tiny part of it and trusted him. He gave me the numbers after I played a couple other tickets along with it for $10. I checked my ticket after the winnings came online and saw the numbers were correct including the Power play. I screamed for about 10 minutes because it felt like a dream. I had won $768.4M. You can check my winning testimony with the lottery officials just with my name search. Thank you Dr Odunga. Well, his email is<EMAIL_ADDRESS>and you can also call or Whats-app him at +2348167159012 so you guys can contact him

@nicolevasilevsky @twhetzel @monicacecilia

The document was updated based on the discussion in the comments and in meetings.
@twhetzel and/or @nicolevasilevsky please review and if approved, merge this PR. Thank you.
Additional discussions about SOP and practicalities will need to be discussed on a call.


Drop EOL RHEL, CentOS, Fedora, VirtuozzoLinux versions

VirtuozzoLinux 7
Fedora 38, 39
Centos 7, 8
RHEL 7

Please update the PR title to list all affected OSes.

Do we want to make a release before dropping EOL OSes?

Why drop Fedora support instead of updating the supported versions to ["40", "41"]?

Hi @silug! I saw somewhere before that dropping EOL OSes and adding new OSes should be different PRs.. though.. maybe it was about different commits instead 🤔

Converting to Draft. Will work on adding new OSes first (to keep Fedora files untouched e.g.).

Should be ready to merge now

Before we merge this, I would like to do a minor release to bring out all merged changes: https://github.com/voxpupuli/puppet-systemd/pull/501

ah derp, we already have https://github.com/voxpupuli/puppet-systemd/pull/480 as a breaking change


Possible bug in the GET_STATUS command

There is a possible bug in the GET_STATUS command, implemented in smtc_modem_core\radio_drivers\sx126x_driver\src\sx126x.c:sx126x_get_status().  The command should send two bytes and include a NOP byte after the command byte.  The macro SX126X_SIZE_GET_STATUS should be changed to “2”.

Hi @rdaubencd,
According to the datasheet v2.1 (see below an extract), the implementation is correct.

The current value is 1:
https://github.com/Lora-net/SWL2001/blob/master/smtc_modem_core/radio_drivers/sx126x_driver/src/sx126x.c, line 183.
But as you point out from the data sheet, two bytes should be sent out: 0xC0, 0x00.
Therefore, the size used in line 814 is SX126X_SIZE_GET_STATUS, which should be 2.
What else am I missing?  Has this already been fixed in another branch?

The way sx126x_hal_read is used is the following:

Send command_length bytes from command buffer
Receive data_length bytes in data buffer

In sx126x_get_status implementation, sx126x_hal_read is called with the following values:

command_length = 1
data_length = 1

In the end, there are effectively 2 bytes exchanged over SPI.

I believe the command_length needs to be 2 to write out the opcode and NOP.  The data_length is 1 to read back the status byte. That's 3 bytes of data exchanged.  I had to make the change to get my test app to read the correct status.
Compare this to the next function in the file sx126x_get_rx_buffer_status(), which correctly adds the NOP byte to the outgoing 2-byte buffer.
Anyway, thanks for your feedback.


[ENH] read-only memory views do not work with fused dtypes

Is your feature request related to a problem? Please describe.
In my code, I would like to use a read-only memoryview using fused dtypes:
# cython: language_level = 3

ctypedef fused dtype_t:
    float
    double

cpdef bint _foo(const dtype_t[:] value):
    return False

But this leads to the following "not-implemented" error:
❯ cythonize -a -i fused_readonly.pyx
Compiling /home/maxnoe/test_Cython/fused_readonly.pyx because it changed.
[1/1] Cythonizing /home/maxnoe/test_Cython/fused_readonly.pyx

Error compiling Cython file:
------------------------------------------------------------
...

ctypedef fused dtype_t:
    float
    double

cpdef bint _foo(const dtype_t[:] value):
                             ^
------------------------------------------------------------

fused_readonly.pyx:7:30: Compiler crash in AnalyseDeclarationsTransform

File 'ModuleNode.py', line 124, in analyse_declarations: ModuleNode(fused_readonly.pyx:1:0,
    full_module_name = 'fused_readonly')
File 'Nodes.py', line 431, in analyse_declarations: StatListNode(fused_readonly.pyx:3:0)
File 'Nodes.py', line 2359, in analyse_declarations: CFuncDefNode(fused_readonly.pyx:7:6,
    modifiers = [...]/0,
    overridable = 1,
    visibility = 'private')
File 'Nodes.py', line 681, in analyse: CFuncDeclaratorNode(fused_readonly.pyx:7:15,
    calling_convention = '',
    overridable = 1)
File 'Nodes.py', line 891, in analyse: CArgDeclNode(fused_readonly.pyx:7:16,
    is_generic = 1,
    outer_attrs = [...]/2)
File 'Nodes.py', line 1093, in analyse: MemoryViewSliceTypeNode(fused_readonly.pyx:7:30,
    is_arg = True,
    name = 'memoryview')

Compiler crash traceback from this point on:
  File "/usr/lib/python3.10/site-packages/Cython/Compiler/Nodes.py", line 1093, in analyse
    self.type = PyrexTypes.MemoryViewSliceType(base_type, axes_specs)
  File "/usr/lib/python3.10/site-packages/Cython/Compiler/PyrexTypes.py", line 625, in __init__
    self.dtype_name = Buffer.mangle_dtype_name(self.dtype)
  File "/usr/lib/python3.10/site-packages/Cython/Compiler/Buffer.py", line 631, in mangle_dtype_name
    return prefix + dtype.specialization_name()
  File "/usr/lib/python3.10/site-packages/Cython/Compiler/PyrexTypes.py", line 57, in specialization_name
    common_subs = (self.empty_declaration_code()
  File "/usr/lib/python3.10/site-packages/Cython/Compiler/PyrexTypes.py", line 51, in empty_declaration_code
    self._empty_declaration = self.declaration_code('')
  File "/usr/lib/python3.10/site-packages/Cython/Compiler/PyrexTypes.py", line 1582, in declaration_code
    return self.const_base_type.declaration_code("const %s" % entity_code, for_display, dll_linkage, pyrex)
  File "/usr/lib/python3.10/site-packages/Cython/Compiler/PyrexTypes.py", line 1649, in declaration_code
    raise Exception("This may never happen, please report a bug")
Exception: This may never happen, please report a bug
Traceback (most recent call last):
  File "/usr/bin/cythonize", line 33, in <module>
    sys.exit(load_entry_point('Cython==0.29.32', 'console_scripts', 'cythonize')())
  File "/usr/lib/python3.10/site-packages/Cython/Build/Cythonize.py", line 225, in main
    cython_compile(path, options)
  File "/usr/lib/python3.10/site-packages/Cython/Build/Cythonize.py", line 97, in cython_compile
    ext_modules = cythonize(
  File "/usr/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1127, in cythonize
    cythonize_one(*args)
  File "/usr/lib/python3.10/site-packages/Cython/Build/Dependencies.py", line 1250, in cythonize_one
    raise CompileError(None, pyx_file)
Cython.Compiler.Errors.CompileError: /home/maxnoe/test_Cython/fused_readonly.pyx

Describe the solution you'd like.
Support read-only memoryviews for fused dtypes
Describe alternatives you've considered.
No response
Additional context
No response

This is fixed in the 3.0 alpha releases (I think in https://github.com/cython/cython/pull/3853, but I haven't checked that for sure). It probably won't be backported to the stable branch.

Good to know! Thanks

FWIW there is a very hacky way to transform a read-only memoryview into a read-write memoryview. I'd much rather people just used the Cython 3 alpha though. However if you want to look it's at https://github.com/scikit-learn/scikit-learn/blob/2a391bea9a409745e5c297c70bcebe51274b9d39/sklearn/utils/_readonly_array_wrapper.pyx


fix: 🐛 correct the return type of getAllCustomClaimTypes

Description
updates the reutn type to include dids
Breaking Changes
JIRA Link
https://polymesh.atlassian.net/browse/DA-937
Checklist

[x] Updated the Readme.md (if required) ?

:tada: This PR is included in version 23.0.0-alpha.34 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 23.0.0-beta.2 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update pybrainyquote.py

Allowed for search containing combination of words. Also included the name of the quote's author.

@manueltonneau Thanks for the contribution.


[acr] add step in "check-health" command to ensure the identity used for CMK does exist

Description
Add CMK configuration check to deflect support case

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

CC @adewaleo @shizhMSFT @jikuma

acr


3600000 Beauty (gravure)

Source name
3600000 Beauty
Source link
https://3600000.xyz/
Source language
All
Other details
18+/NSFW = yes
Gravure photography site with Japanese and Chinese models.
Acknowledgements

[X] I have checked that the extension does not already exist by searching the extension listing and verified it does not appear there.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[X] I will fill out all of the requested information in this form.

Can you provide app icons? The site uses a generic wordpress icon, I used this in my code


Investigate TLS connectivity

Does this issue include certificates? Like in: https://www.cockroachlabs.com/docs/dev/build-a-java-app-with-cockroachdb.html

@rinokadijk I'd expect certificates to be managed by the standard Java SSL context APIs, at least in a first incarnation.

@Squiry any chance for you to continue the work ? Otherwise, I could try to continue what you started

@cambierr my branch was pretty working last time I checked. I only needed a little bit help with configuration (don't know how to do it right).

From that point of view, please create a pull request so we can continue the discussion over some actual code.

@mp911de #104 here it is.

It is unclear to me what the status is of this issue and the corresponding pull request #104 can @Squiry or @mp911de (or perhaps someone else who knows) shed some light on this?
We are looking for a solution to use r2dbc with tls connections to our postgres databases and are happy to see if we can help get TLS support for postgres in r2dbc.

Paging @nebhale who is the maintainer of this project.

My pull request is ready for review.

It's merged!
Thank you @Squiry for getting this implemented. And thanks to @mp911de for helping to pull it all together.


auro-checkbox: checkbox group contents not controlled if children added after connectedCallback

Describe the bug
If child checkboxes are added to the checkbox-group after connectedCallback has run, the checkbox-group will not control the disabled/error state of these children.
This is especially an issue in Svelte, which first appends the group (calling connectedCallback), and then appends the children. At the time connectedCallback has run, the children are not in the DOM, so this.items is empty.
Related: https://github.com/AlaskaAirlines/auro-accordion/issues/18
To Reproduce
Render the following markup in Svelte:
<auro-checkbox-group disabled={true}>
	Example group
	<auro-checkbox id="optionOne" name="exampleOptions" value="option one"
		>Option one</auro-checkbox
	>
	<auro-checkbox id="optionTwo" name="exampleOptions" value="option two"
		>Option two</auro-checkbox
	>
</auro-checkbox-group>

Inspect the child auro-checkbox. The disabled property is false.
Expected behavior
The component reacts to additional slotted checkboxes added after connectedCallback has run.

:tada: This issue has been resolved in version 1.1.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


AADSTS50078: Presented multi-factor authentication has expired due to policies configured by your administrator, you must refresh your multi-factor authentication to access

This is autogenerated. Please review and update as needed.
Describe the bug
For some reason my integration tests start failing as of yesterday. I run from my dev box. I am working with AzureB2C integration with MSAL 3.0 to test if bearer tokens are received. I use my complete startup file including managed identities for my key vaults.
I find it hard to find out was is generating this bug.
The error is thrown upon test server creation.
`
public class TestServerScenarioInitialize
{
static string GetKeyVaultEndpoint() => Environment.GetEnvironmentVariable("KEYVAULT_NAME");
    public static TestServer CreateServer()
    {
       ///code ommitted for explaining where error is thrown

        var testServer = new TestServer(hostBuilder);
       ///error thrown above

        return testServer;
    }
}`

Command Name
az account get-access-token
Errors:
Get Token request returned http error: 400 and server response: {"error":"interaction_required","error_description":"AADSTS50078: Presented multi-factor authentication has expired due to policies configured by your administrator, you must refresh your multi-factor authentication to access 'cxxx3'.\r\nTrace ID: fc001aee-6ebe-487c-a226-ad3e9d300b00\r\nCorrelation ID: 00fedcf6-2ceb-4c35-a196-0fb6dc958758\r\nTimestamp: 2021-02-20 10:16:51Z","error_codes":[50078],"timestamp":"2021-02-20 10:16:51Z","trace_id":"fc001aee-6ebe-487c-a226-ad3e9d300b00","correlation_id":"00fedcf6-2ceb-4c35-a196-0fb6dc958758","suberror":"basic_action"}
Traceback (most recent call last):
Temp\pip-unpacked-wheel-yccaebu4\knack\cli.py, ln 233, in invoke
...

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 account get-access-token --output {} --resource {}

Expected Behavior
Environment Summary
Windows-10-10.0.19041-SP0
Python 3.6.8
Installer: MSI

azure-cli 2.19.1

Additional Context

Account

I fixed this by first running F5 before integration tests on my VS2019. The issue is away for now. You can close if you want. With Azure Feedback I got this reporting option.


Add v2.5.0 release notes

Signed-off-by: Kunal Kotwani<EMAIL_ADDRESS>Description

Add release notes for v2.5.0

Issues Resolved

N/A

Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #5816 (1390b24) into main (eeca443) will decrease coverage by 0.00%.
The diff coverage is n/a.

:exclamation: Current head 1390b24 differs from pull request most recent head 95f7ce2. Consider uploading reports for the commit 95f7ce2 to get more accurate results

@@             Coverage Diff              @@
##               main    #5816      +/-   ##
============================================
- Coverage     70.90%   70.89%   -0.01%
+ Complexity    58754    58725      -29
============================================
  Files          4768     4768
  Lines        280537   280537
  Branches      40512    40512
============================================
- Hits         198905   198885      -20
- Misses        65302    65358      +56
+ Partials      16330    16294      -36

Impacted Files
Coverage Δ

...port/ResponseHandlerFailureTransportException.java
0.00% <0.00%> (-60.00%)
:arrow_down:

...ava/org/opensearch/action/NoSuchNodeException.java
0.00% <0.00%> (-50.00%)
:arrow_down:

...cluster/coordination/PendingClusterStateStats.java
20.00% <0.00%> (-48.00%)
:arrow_down:

...regations/metrics/AbstractHyperLogLogPlusPlus.java
51.72% <0.00%> (-44.83%)
:arrow_down:

...rch/client/transport/NoNodeAvailableException.java
28.57% <0.00%> (-42.86%)
:arrow_down:

...min/cluster/snapshots/get/GetSnapshotsRequest.java
52.63% <0.00%> (-31.58%)
:arrow_down:

...opensearch/snapshots/SnapshotMissingException.java
28.57% <0.00%> (-28.58%)
:arrow_down:

...opensearch/index/reindex/BulkByScrollResponse.java
48.38% <0.00%> (-28.23%)
:arrow_down:

.../opensearch/index/reindex/ScrollableHitSource.java
69.02% <0.00%> (-23.90%)
:arrow_down:

...pensearch/index/shard/SearchOperationListener.java
72.72% <0.00%> (-20.00%)
:arrow_down:

... and 473 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Suggestion: deployments save like hardhat-deploy

Would be nice to have something similar like deployments.save had with hardhat-deploy. In case some contract call creates a new contract, I was using it to label it and in some case attach an abi to it so it goes in the deployment file.
example:
https://github.com/Abracadabra-money/magic-internet-money/blob/23266d17969a95e69199670cba9d0060bff33340/archive/deploy/FTMDegenCauldron.ts#L55

you can : https://github.com/wighawag/forge-deploy/blob/f38bcd71d045f78827ad7b25810eb83b4496ef40/contracts/Deployer.sol#L197-L223
need to document and maybe you were thinking of a nicer api ?
technically you could put empty bytecode and args if you dot care about them
but maybe I should add a simpler methods like
function save( string memory name, address deployed, string memory artifact) external;
function save( string memory name, address deployed, string memory artifacts, bytes memory args) external;

I'm dumb, didn't think you had it yet. Insane work ser, will give it a try.

I updated the save function
it is a breaking change (I reordered the args), I try to avoid them if I can but prefer to do that now as we are still early :)
https://github.com/wighawag/forge-deploy/blob/main/docs/src/contracts/Deployer.sol/contract.Deployer.md#save

Thanks for the update. Trying it out but I'm facing two issues reproductible with the current forge-deploy-testing branch of my repo.
The issues can be reproduced using make init first and then SCRIPT=ConvexCauldrons make mainnet-deploy-simulation
This should deploy the content of ConvexCauldrons.s.sol
First issue is when using deployer.save using an interface artifact. I understand that an interface artifacts doesn't contain any bytecode but do you think there could be a neat way to create a deployment with wrapper created from             wrapper = IConvexWrapper(wrapperFactory.CreateWrapper(38));?

Second issue, if you comment out the deployer.save line, to bypass the first issue, is related to zero byte contract being deployed. It's a similar issue I've been facing with that issue I've reported to foundry back then when I was trying to get the contractName from run-latest.json, seems like it's having trouble when all the fields are immutable? Or I might be wrong?

For the first one, forge-deploy assume you are using the short save version as you just been using the artifact and so the bytecode will be fetched from the given artifact
if you do not you can use
deployer.save("TrycriptoAbraConvexWrapper", address(wrapper), "IConvexWrapper.sol:IConvexWrapper", "", "");

Thinking to maybe do a try catch for getCode but for now, I ll leave this as is. Need to think more of the implications
For the second one, not sure what it is. this is happening in the simulation, not in forge-deploy reading of run-latest
Do you know where in the code this trace is associated with ?

About the second issue. I'm not sure, the wrapper address is the right one, so .curveToken() should work. I get the impression it might be the issue again when a contract has only immutable fields versus using the artifacts.
Here you can see the same code, one using vanilla new and the other using deployer but the second is reverting on simulation.

I wonder why there is staticcall could be the issue

Does not feel like a forge-deploy issue
So I guess if you use new and save the deployment via deployer.save then it should workaround the issue ?

Does not feel like a forge-deploy issue
So I guess if you use new and save the deployment via deployer.save then it should workaround the issue ?

that could be a workaround but it's annoying to have to repeat the constructor args twice, unless I just skip specifying them with ""

Oh yes i agree
Would be cool to make an minimal repo, as i dont think it ks related to forge-deploy
Another way to fix is to modify the template to use new
With forge-deploy you can provide your own with --templates

Something like this : https://gist.github.com/wighawag/081e9d1fe14f2f17c477eaa8f1253c5a
(not tested)

Ha actually the weird thing is that it should actually fails, see the interface : https://github.com/Abracadabra-money/abracadabra-money-foundry/blob/3bd89b0b39e1b18450bc4de500f1cdd2b3a0fd76/src/interfaces/IConvexWrapper.sol#L36
it define curveToken as a view function so solidity compiler will use a static call
Could it be that when you use new, the failure get caught somehow.
This is weird, but I know see why there is a staticcall in the trace

https://etherscan.io/address/0xB0daC09364550ecdFc46D9C4e012F2FABE70BC56#readContract
Ha, this does not seem to have a curveToken function

https://etherscan.io/address/0xB0daC09364550ecdFc46D9C4e012F2FABE70BC56#readContract
Ha, this does not seem to have a curveToken function

thanks for the help, 0xB0da has been deployed 3h ago by convex, wrapped is created by a proxy they provided us, if I run the simulation again it might give a new address this time. I'll give it another try asap but it should create a wrapper proxy that have the curveToken function otherwise it would revert when I'm not using forge-deploy, right?

can confirm it's now a new address and it doesn't exist yet
https://etherscan.io/address/0xecF3e645e5A6805C503fDCa00a14a84E881d9df1

using the template as suggested to make use of new Contract(... syntax works
See PR: https://github.com/Abracadabra-money/abracadabra-money-foundry/pull/73
This really suggests that forge is doing something weird when using assembly call for some reason, or is there something else in the way I make the assembly create call that is not correct ?
A minimal repo could help to ellucidate the problem. I would consider using the new Contract(... syntax in the default template but the thing I do not like about it is that we still need to compute the arg string and get the bytecode to save. so if this fails with the bytecode, then maybe the bytecode we get from forge is wrong and as such we will be saving wrong data.

No problem, here is a minimal repository reproducing the issue.
https://github.com/0xCalibur/forge-deploy-issue-2

Thanks for that,
I figured the issue
It fails with forge-deploy because forge-deploy make sure to broadcast the tx
If you do
vm.broadcast();
return new Counter(wrapper);

It also fails
I guess this is because the account broadcasting has not right to deploy the wrapper

Thanks for that,
I figured the issue
It fails with forge-deploy because forge-deploy make sure to broadcast the tx
If you do
vm.broadcast();
return new Counter(wrapper);

It also fails
I guess this is because the account broadcasting has not right to call curveToken or something ?

.curveToken() is a view, so the reason is probably something else ig

I am closing this issue as the issue does not stem from forge-deploy which is intended to be used for broadcast

I am closing this issue as the issue does not stem from forge-deploy which is intended to be used for broadcast
Feel free to open an issue if you think there are use case where broadcast is undesirable or if there are other issues related to it.
Thanks!

Hi, do you mean adding --broadcast, I updated the repo, where I did and it still fails with the same error

No I am talking about the vm.broadcast call which make the next call a real tx
if you do not use it the tx will not happen on the network
and in you case, for some reason, if you use it it fails, whether you use forge-deploy or not

Oh and for the demo repo, the reason it fails on the real network is that there is no vm.broadcast called for this line : https://github.com/0xCalibur/forge-deploy-issue-2/blob/f033944d079a733cb68389472594fc2d93f75d4f/script/Deploy.s.sol#LL13C8-L13C51
you need to call vm.startBroadcast and vm.stopBroadcast whenever you wan that tx actually hitting the network, see : https://book.getfoundry.sh/cheatcodes/start-broadcast

make sense, yeah I'm used to start/stop broadcast, been using it a lot over the year. It's just that I forgot that you use vm.broadcast and was used to have everything in between just broadcast, as an habit. Thx for shedding a light on this!

OK, maybe it make sense to have an global option where broadcast is disabled in the deploy call
Tne templating system kind of solve this already but I ll think about it

Hey @0xCalibur I am revisiting the setup in regard to broadcasting and would like your feedback: https://github.com/wighawag/forge-deploy/issues/3#issuecomment-1544786576
This would allow you to disable auto-broadcast


newest cask-repair version won't let me submit

trying to update android-platform-tools and every time i submit, it prompts me with yes no and edit again.

You see the red bullet point that turns into two, the second time? It‘s an error message it isn’t being able to show. It’s likely an issue (I’ve seen something similar before) with the installation of the style command.
Try
gem uninstall --all --executables rubocop rubocop-cask
brew cask style

If that doesn’t work, try the gem command with sudo.

Also, when submitting a bug report please never call a version “latest” or “newest”. I may have released a new version in the meantime without you noticing, or there may have been some error in the update mechanism or something.
Always mention the actual version number.

Got it working, thanks. Hadn't learned ruby and had rbenv install multiple ruby versions which had conflicts between their packages (?). It worked when I uninstalled one of the ruby versions I installed recently.

Glad it’s working.

Can you try:
/usr/bin/gem uninstall --all --executables rubocop rubocop-cask

I did this but did not work 😢
I still cannot use the cask-repair command properly; it is infinitely repeating event if I press y to submit a PR for a cask 😢

Just for fun, kan you do a export PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin.

@MindTooth
Thanks for the reply.

Just for fun, kan you do a export PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin.

$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

$ echo -e ${PATH//:/\\n}
/usr/local/sbin
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

$ brew cask style
Error: The 'rubocop-cask' gem is installed but couldn't find 'rubocop' in the PATH:
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.3.0/bin:/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Homebrew/Library/Homebrew/shims/scm

It seems that the problem is still persistent.. 😢

Can you set rbenv back to system.  And do:
$ /usr/local/bin/gem uninstall --all --executables rubocop rubocop-cask
$ /usr/bin/gem uninstall --all --executables rubocop rubocop-cask

If that don't solve it, I don't know.  Seems that there is some leftover somewhere.
When running /usr/local/bin/ruby -v , what's the output.
Also, as a last resort:
find / -name "*rubocop*"

@MindTooth

Can you set rbenv back to system. And do:
$ /usr/local/bin/gem uninstall --all --executables rubocop rubocop-cask
$ /usr/bin/gem uninstall --all --executables rubocop rubocop-cask

If that don't solve it, I don't know. Seems that there is some leftover somewhere.
When running /usr/local/bin/ruby -v, what's the output.

I have 3 Ruby versions installed:

rbenv Ruby
Homebrew Ruby
macOS Ruby

# 3 Ruby versions are listed in the numerial order shown above
$ type --all ruby
ruby is /Users/sho/.rbenv/shims/ruby
ruby is /usr/local/bin/ruby
ruby is /usr/bin/ruby

# `rbenv` Ruby
$ /Users/sho/.rbenv/shims/ruby -v
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin16]

# Homebrew Ruby
$ /usr/local/bin/ruby -v
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin16]

# macOS Ruby
$ /usr/bin/ruby -v
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

And accordingly, I have 3 gem versions:
$ type --all gem
gem is /Users/sho/.rbenv/shims/gem
gem is /usr/local/bin/gem
gem is /usr/bin/gem

# `rbenv` gem
$ /Users/sho/.rbenv/shims/gem -v
2.7.4

# Homebrew gem
$ /usr/local/bin/gem -v
2.7.4

# macOS gem
$ /usr/bin/gem -v
YAML safe loading is not available. Please upgrade psych to a version that supports safe loading (>= 2.0).
2.7.4

And, attempting to uninstall the rubocop and rubocop-cask gems from these 3 Ruby versions:
# `rbenv` gem
$ /Users/sho/.rbenv/shims/gem uninstall --all --executables rubocop rubocop-cask
Gem 'rubocop' is not installed
Gem 'rubocop-cask' is not installed

# Homebrew gem
$ /usr/local/bin/gem uninstall --all --executables rubocop rubocop-cask
Gem 'rubocop' is not installed
Gem 'rubocop-cask' is not installed

# macOS gem
# I already performed this previously and uninstalled the gems successfully,
# though did not help
$ /usr/bin/gem uninstall --all --executables rubocop rubocop-cask
YAML safe loading is not available. Please upgrade psych to a version that supports safe loading (>= 2.0).
Gem 'rubocop' is not installed
Gem 'rubocop-cask' is not installed

However, doing these does not resolve the issue for me:
$ brew cask style
Error: The 'rubocop-cask' gem is installed but couldn't find 'rubocop' in the PATH:
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.3.0/bin:/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Homebrew/Library/Homebrew/shims/scm

NB: Just to see if it is really not working, I tried using the cask-repair command to update some cask but could not complete the PR submit for it 😢

Also, as a last resort:
find / -name "*rubocop*"

I prepended sudo in front of the above command in order to avoid the Permission denied output.

$ sudo find / -name "*rubocop*" (Click to expand)

Password:
001: /Applications/GitHub Desktop.app/Contents/Resources/app/static/choosealicense.com/.rubocop.yml
002: find: /dev/fd/sho: No such file or directory
003: find: /dev/fd/sho: No such file or directory
004: /opt/vagrant/embedded/gems/gems/net-ssh-4.2.0/.rubocop.yml
005: /opt/vagrant/embedded/gems/gems/net-ssh-4.2.0/.rubocop_todo.yml
006: /opt/vagrant/embedded/gems/gems/rest-client-2.0.2/.rubocop-disables.yml
007: /opt/vagrant/embedded/gems/gems/rest-client-2.0.2/.rubocop.yml
008: /opt/vagrant/embedded/gems/gems/ruby_dep-1.3.1/.rubocop.yml
009: /opt/vagrant/embedded/gems/gems/winrm-2.2.3/.rubocop.yml
010: /opt/vagrant/embedded/gems/gems/winrm-elevated-1.1.0/.rubocop.yml
011: /opt/vagrant/embedded/gems/gems/winrm-fs-1.2.0/.rubocop.yml
012: /opt/vagrant/embedded/gems/gems/winrm-fs-1.2.0/.rubocop_todo.yml
013: /Users/sho/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/info/rubocop
014: /Users/sho/.gem/ruby/2.0.0/gems/bundler-1.14.4/.rubocop.yml
015: /Users/sho/.gem/ruby/2.0.0/gems/bundler-1.14.4/.rubocop_todo.yml
016: /Users/sho/.gem/ruby/2.0.0/gems/bundler-1.14.4/bin/rubocop
017: /Users/sho/.gem/ruby/2.0.0/gems/public_suffix-2.0.3/.rubocop.yml
018: /Users/sho/.gem/ruby/2.0.0/gems/public_suffix-2.0.3/.rubocop_defaults.yml
019: /Users/sho/.gem/ruby/2.0.0/gems/rainbow-2.1.0/.rubocop.yml
020: /Users/sho/.gem/ruby/2.3.0/bin/rubocop
021: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-0.49.1.gem
022: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-0.50.0.gem
023: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-0.51.0.gem
024: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-0.52.1.gem
025: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-cask-0.13.1.gem
026: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-cask-0.14.2.gem
027: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-cask-0.14.4.gem
028: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-cask-0.15.1.gem
029: /Users/sho/.gem/ruby/2.3.0/cache/rubocop-cask-0.16.0.gem
030: /Users/sho/.gem/ruby/2.3.0/gems/public_suffix-2.0.5/.rubocop.yml
031: /Users/sho/.gem/ruby/2.3.0/gems/public_suffix-2.0.5/.rubocop_defaults.yml
032: /Users/sho/.gem/ruby/2.3.0/gems/public_suffix-3.0.0/.rubocop.yml
033: /Users/sho/.gem/ruby/2.3.0/gems/public_suffix-3.0.0/.rubocop_defaults.yml
034: /Users/sho/.gem/ruby/2.3.0/gems/rainbow-2.2.2/.rubocop.yml
035: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.49.1
036: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.49.1/bin/rubocop
037: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.49.1/lib/rubocop
038: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.49.1/lib/rubocop.rb
039: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.50.0
040: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.50.0/bin/rubocop
041: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.50.0/lib/rubocop
042: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.50.0/lib/rubocop.rb
043: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.51.0
044: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.51.0/bin/rubocop
045: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.51.0/lib/rubocop
046: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.51.0/lib/rubocop.rb
047: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.52.1
048: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.52.1/bin/rubocop
049: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.52.1/lib/rubocop
050: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-0.52.1/lib/rubocop.rb
051: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.13.1
052: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.13.1/lib/rubocop
053: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.13.1/lib/rubocop-cask.rb
054: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.13.1/spec/rubocop
055: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.2
056: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.2/lib/rubocop
057: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.2/lib/rubocop-cask.rb
058: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.2/spec/rubocop
059: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.4
060: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.4/lib/rubocop
061: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.4/lib/rubocop-cask.rb
062: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.14.4/spec/rubocop
063: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.15.1
064: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.15.1/lib/rubocop
065: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.15.1/lib/rubocop-cask.rb
066: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.15.1/spec/rubocop
067: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.16.0
068: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.16.0/lib/rubocop
069: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.16.0/lib/rubocop-cask.rb
070: /Users/sho/.gem/ruby/2.3.0/gems/rubocop-cask-0.16.0/spec/rubocop
071: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-0.49.1.gemspec
072: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-0.50.0.gemspec
073: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-0.51.0.gemspec
074: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-0.52.1.gemspec
075: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-cask-0.13.1.gemspec
076: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-cask-0.14.2.gemspec
077: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-cask-0.14.4.gemspec
078: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-cask-0.15.1.gemspec
079: /Users/sho/.gem/ruby/2.3.0/specifications/rubocop-cask-0.16.0.gemspec
080: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-0.49.1.gemspec
081: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-0.50.0.gemspec
082: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-0.51.0.gemspec
083: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-0.52.1.gemspec
084: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.13.1.gemspec
085: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.14.2.gemspec
086: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.14.4.gemspec
087: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.15.1.gemspec
088: /Users/sho/.gem/specs/api.rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.16.0.gemspec
089: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-0.40.0.gemspec
090: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-0.41.1.gemspec
091: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-0.41.2.gemspec
092: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-0.45.0.gemspec
093: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-0.47.1.gemspec
094: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-0.49.0.gemspec
095: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-0.49.1.gemspec
096: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.10.4.gemspec
097: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.10.5.gemspec
098: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.10.6.gemspec
099: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.11.0.gemspec
100: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.12.0.gemspec
101: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.13.0.gemspec
102: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.13.1.gemspec
103: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.6.0.gemspec
104: /Users/sho/.gem/specs/rubygems.org%443/quick/Marshal.4.8/rubocop-cask-0.8.3.gemspec
105: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/github-pages-175/.rubocop.yml
106: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/github-pages-health-check-1.3.5/.rubocop.yml
107: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-3.6.2/.rubocop.yml
108: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-3.7.2/.rubocop.yml
109: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-3.7.2/rubocop
110: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-avatar-0.5.0/.rubocop.yml
111: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-feed-0.9.2/.rubocop.yml
112: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-gist-1.5.0/.rubocop.yml
113: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-redirect-from-0.12.1/.rubocop.yml
114: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-redirect-from-0.13.0/.rubocop.yml
115: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-seo-tag-2.3.0/.rubocop.yml
116: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-seo-tag-2.4.0/.rubocop.yml
117: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-sitemap-1.1.1/.rubocop.yml
118: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/jekyll-sitemap-1.2.0/.rubocop.yml
119: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/public_suffix-2.0.5/.rubocop.yml
120: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/public_suffix-2.0.5/.rubocop_defaults.yml
121: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/public_suffix-3.0.1/.rubocop.yml
122: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/public_suffix-3.0.1/.rubocop_defaults.yml
123: /Users/sho/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/ruby_dep-1.5.0/.rubocop.yml
124: /Users/sho/Dropbox/code/dotfiles/atom/packages/atom-beautify/docs/code/file/src/beautifiers/rubocop.coffee.html
125: /Users/sho/Dropbox/code/dotfiles/atom/packages/atom-beautify/src/beautifiers/rubocop.coffee
126: /Users/sho/Dropbox/code/dotfiles/vim/plugged/syntastic/syntax_checkers/ruby/rubocop.vim
127: /Users/sho/Dropbox/code/example-code/example-dotfiles/dotfiles-repos/dotfiles-jpalardy-68/vim/bundle/syntastic/syntax_checkers/ruby/rubocop.vim
128: /Users/sho/Dropbox/code/example-code/example-dotfiles/dotfiles-repos/dotfiles-sjl/vim/bundle/syntastic/syntax_checkers/ruby/rubocop.vim
129: /Users/sho/Dropbox/code/example-code/example-dotfiles/vim/vimrc-amix/sources_non_forked/syntastic/syntax_checkers/ruby/rubocop.vim
130: /usr/local/Cellar/zsh-completions/0.27.0/share/zsh-completions/_rubocop
131: /usr/local/Homebrew/Library/.rubocop.yml
132: /usr/local/Homebrew/Library/.rubocop_audit.yml
133: /usr/local/Homebrew/Library/Homebrew/.rubocop.yml
134: /usr/local/Homebrew/Library/Homebrew/bin/rubocop
135: /usr/local/Homebrew/Library/Homebrew/rubocops
136: /usr/local/Homebrew/Library/Homebrew/rubocops.rb
137: /usr/local/Homebrew/Library/Homebrew/test/rubocops
138: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/gems/simplecov-0.13.0/.rubocop.yml
139: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/gems/simplecov-html-0.10.0/.rubocop.yml
140: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/bin/rubocop
141: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/build_info/rubocop-0.49.1.info
142: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/cache/rubocop-0.49.1.gem
143: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/rainbow-2.2.2/.rubocop.yml
144: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/rake-12.0.0/.rubocop.yml
145: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/rubocop-0.49.1
146: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/rubocop-0.49.1/bin/rubocop
147: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/rubocop-0.49.1/lib/rubocop
148: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/rubocop-0.49.1/lib/rubocop.rb
149: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/simplecov-0.14.1/.rubocop.yml
150: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/gems/simplecov-html-0.10.0/.rubocop.yml
151: /usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.0.0/specifications/rubocop-0.49.1.gemspec
152: /usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask/Casks/.rubocop.yml
153: /usr/local/share/zsh-completions/_rubocop

As you see, 153 lines have been searched with the keyword "*rubocop*". I prepended line numbers to the output lines for convenience. L14-L104 are related to the ~/.gem directory – I was wondering if this could be a culprit, and erasing this is safe or not. Another culprit could be inside the /usr/local/Homebrew/Library/ directory in L131-L152.
Having said this, these two directories don't seem relevant to the PATH suggested by the output of running brew cask style:
$ brew cask style
Error: The 'rubocop-cask' gem is installed but couldn't find 'rubocop' in the PATH:
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.3.0/bin:/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Homebrew/Library/Homebrew/shims/scm

I will try renaming ~/.gem and reinstalling Rubies to see what happens 👨💻  💎

What I can see from my own find, is that I don't have rubocop installed other than the binary shipped with Homebrew, but still can submits PRs.
I see that you have a lot of leftovers.  Maybe s gem cleanup can clean some.
Also the .gem folder have Ruby 2.3.0 which is not installed.
Did it change when you removed .gem folder?  Also, care to post your .gemrc file?

FYI I had the same issue, and I was not able to understand which change exactly caused the issue. However, the issue is that homebrew cask is not using the current Ruby nor the current Ruby gems, but the gems installed via the Ruby version bundled with homebrew.
In fact, in the following case (like on my system) the paths were completely different than what I would expect:
$ brew cask style
Error: The 'rubocop-cask' gem is installed but couldn't find 'rubocop' in the PATH:
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/2.3.0/bin:/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Homebrew/Library/Homebrew/shims/scm

I fixed the issue by installing the latest Rubocop version from the bundled Ruby:
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin/gem install rubocop

It worked. Again, this is strange as I had other rubocop versions there
➜  ~ /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin/gem list | grep rubocop
rubocop (0.52.1, 0.51.0)
rubocop-cask (0.16.0, 0.15.1)

Anyway, after installing the latest rubocop here I was able to submit a cask update again.

My problem was caused by a stray, old version of rubocop in my ~/.gem directory. Specifically ~/.gem/ruby/2.3.0/bin/rubocop. (I have no idea how it got there. I've never knowingly installed anything with the --user-install option.)
Since there was nothing vital in my ~/.gem directory, I renamed it to ~/.gem.old and the problem went away.

Just wanted to leave this here as a possible solution if thing goes sideways.
brew vendor-install ruby


Standalone TGIS grpc plugin support

Includes grpc proto files from https://github.com/opendatahub-io/text-generation-inference
Currently only supports grpc requests
Can be used against Raw or serverless Kserve deployment

This looks good as a first iteration, thanks!
In a followup PR we should add error handling and make sure it works for a few simple cases like:

Bad / misspelled hostname for server
If concurrency is higher than MAX_CONCURRENT_REQUESTS in TGIS, the plugin should catch and record the "model is overloaded" errors.

/lgtm
/approve


Home assistant does not run with old firmware of Yeelight bulb (color)

After updating to the latest version of Home Assistant 0.65, I got an issue that I can turn off but cannot turn on Yeelight bulb. The issue make me reinstall Home Assistant 3 times.
**Home Assistant release (hass --version): 0.65
**Python release (python3 --version):3.0
Component/platform:
https://www.yeelight.com/en_US/product/wifi-led-c
Description of problem:
I cannot turn on the light. After updating to the lamp's latest firmware 1.4.2_0061, everything is fine.
Expected:
Home assistant needs to know which firmware of light he is using with.
Problem-relevant configuration.yaml entries and steps to reproduce:
Does not add any entry because the light is auto detected.
Traceback (if applicable):

Additional info:

If non-latest firmware is not supported by the manufacturer why would HA support it?
Docs specifically state "  LAN mode may only be available with the latest firmware installed on your bulb ".
This is not a bug and is well documented, please close the issue.

Sorry for not clear, my use-case is that I have HA and Yeelight work correctly with each other. One day I updated to latest HA, 0.65 and after that I cannot turn on Yeelight. I use Google Home to say command  to turn on Yeelight and it is ok. HA can turn off Yeelight also. The issue cannot turn on Yeelight by HA is fixed after I updated Yeelight to the latest firmware.
I think if is not a bug, we can call it an enhancement if HA can add more property for Yeelight like: "Auto_upadate_firmware" = True
and vendor library can update firmware by themself.
I found vendor library for Yeelight here:
https://github.com/skorokithakis/python-yeelight
What do you think?

HA is not intended to update 3rd party components or devices. This is simply not  platforms' management software, its integration software.
You are more than welcome to log it as enhancement request via https://community.home-assistant.io/c/feature-requests, this then gets voted on and community drives the changes.
Github's issues are really intended as bug reports only, that is why I asked you to close the issue, should have given you the link for feature request, tho.

Thank you, I will follow your suggestion.