Makefile, pkg-config: Add INCLUDE_PREFIX variable, use include/openh2…

Makefile, pkg-config:
Add INCLUDE_PREFIX variable,
use $(PREFIX)/include/openh264 as default,
include correct default in the pkg-config file
People who use the pkg-config mechanism will benefit from this immediately and may not have to make any local changes to their own code.
People who hardcoded the paths may need to start using pkg-config or tweak their paths as they prefer.

There are a couple of reasons why this is important:
If people are using cisco/openh264 as a Git submodule, the API files are accessed in a subdirectory without the wels/ prefix, those files currently live here, notice that wels/ is not part of the path.
The current version of the openh264.pc file simply lacks the wels/ element and some projects include that as part of #include while other projects are hacking it into their CFLAGS.  Having a recommended value in the .pc file encourages conformity

This makes sense to me as well.

This change broke ffmpeg's detection and use of openh264. Was that intentional?

@jrmuizel thanks for the feedback
I'm guessing the problem you have is one of two things:

before this commit, the includedir in the OpenH264 pkgconfig file didn't have any path element such as wels/ or openh264/ on the end
you have the wels/ path element hardcoded in configure and/or something else

https://people.freedesktop.org/~dbn/pkg-config-guide.html
gives examples with the project name at the end of includedir in the package config file, e.g. Cflags: -I${includedir}/foo and that pattern has been followed in this commit.
Projects using a library like that can simply remove wels/ prefixes from the configure logic and also from those C files that #include this code.  This is useful if you sometimes want to build with a copy of OpenH264 as a Git submodule, see the comment at the top.
Alternatively, that part of the commit, the change to openh264.pc.in could be revised

Yes, ffmpeg has wels hardcoded: https://github.com/FFmpeg/FFmpeg/blob/129f5ed87e716788191a073791a2446a6099b72f/configure#L6565
https://github.com/FFmpeg/FFmpeg/blob/129f5ed87e716788191a073791a2446a6099b72f/libavcodec/libopenh264.c#L23
How should software like ffmpeg support building against versions of openh264 before and after this commit?

When OpenSSL changed their API it was much more substantial as it required code changes and people developed various hacks with macros to support both new and old.  That was more painful because OpenSSL libraries exist in many Linux distributions.
OpenH264 is very different: because of the patent issue, it is not pre-installed in packages on most systems.  Therefore, it may not justify a lot of effort to support older versions.

OpenH264 is very different: because of the patent issue, it is not pre-installed in packages on most systems. Therefore, it may not justify a lot of effort to support older versions.

Fair enough.
FWIW, I think it would be better to drop the change to openh264.pc.in. The header names (e.g codec_api.h) are very generic so I think it makes more sense for applications to use #include <openh264/codec_api.h> vs #include <codec_api.h>

FWIW, I think it would be better to drop the change to openh264.pc.in. The header names (e.g codec_api.h) are very generic so I think it makes more sense for applications to use #include <openh264/codec_api.h> vs #include <codec_api.h>

This is quite interesting and it does challenge the examples from pkgconfig
My own view on that:

for a library that is being included in every part of ffmpeg (or anything else), e.g. a logging library, that would be a big issue
but for openh264, most applications only include it into some module in a dedicated subdirectory with a dedicated Makefile where the include path can be configured.  No other module would have the openh264 headers in the include path because the other modules all have different Makefiles

There is another way forward though: maybe we could have a top level openh264.h file that simply includes all the other public headers

Generic names like codec_api.h also risks collision with some other libs headers. openh264 is not a general/useful to many apps that it motivates placing in /usr/include. An extra openh264 dir feels appropriate.

There is no suggestion that codec_api.h should be placed in /usr/include
This commit has not placed codec_api.h in /usr/include
The only question here is which permutation of the path should be in the pkgconfig file: should pkgconfig tell build systems to add -I/usr/include/openh264 to their compiler command line?
I posted a patch for ffmpeg here along with more comments:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293591.html

Oh, my mistake. Sorry about that.

There are a couple of reasons why this is important:
If people are using cisco/openh264 as a Git submodule, the API files are accessed in a subdirectory without the wels/ prefix, those files currently live here, notice that wels/ is not part of the path.
The current version of the openh264.pc file simply lacks the wels/ element and some projects include that as part of #include while other projects are hacking it into their CFLAGS. Having a recommended value in the .pc file encourages conformity

Wouldn't it have been more straightforward, without breaking multiple existing users, by just restructuring the header hierarchy in the repo, to have the headers in a wels subdirectory, so that users can consistently use <wels/codec_api.h> both when using the code as-is as a submodule and when installed? (And one could have kept the old location with a symlink to avoid breaking existing submodule users too!)
This change has just recently been merged and isn't part of any release (as far as I know?), so we still have time to get this right.

If taking a step back - a change like this should be accompanied by a clear declaration - what's the official way of including the library's headers?
Before this change, it was to install the library into a directory, use the pkg-config file and include <wels/codec_api.h>. This behaviour has now been broken.
Outside of that, users of the library may have been including <codec_api.h> in nonstandard setups by pointing their build tools directory at a non-installed repo checkout of openh264.
This patch broke the existing official usecase and instead made a different, nonstandard usecase the only supported one.
As there are concerns about codec_api.h being a very common header name (it's quite plausible that another project also has got a header named that, and thus, including <codec_api.h> is brittle and could accidentally load another header from another project, that's a great argument for keeping the directory prefix, i.e. <somedirectory/codec_api.h> would be the official recommended way of including it.
Now if we're back at that point, changing the directory from wels to openh264 might make it more understandable, but it's also an entirely avoidable and pointless break.
So if we want a common consistent way of including the library headers from the repo, mimicing the installed layout (with a wels subdirectory) would be a straightforward way of achieving that.

In #3488 I made a PR to revert this decision.

If anybody wants to search for code using the old header path
find . -type f -exec grep -H 'wels/' {} \;

and to replace
find . -type f -exec sed -i -e 's!wels/!openh264/!g' {} \;

Really, nobody is arguing that it is hard to change. The point is that there’s no need to change things in the first place. It’s just extra churn for countless of projects using the library, for no benefit.

The point is that there’s no need to change things in the first place. It’s just extra churn for countless of projects using the library, for no benefit.

Most people would be using this through ffmpeg or GStreamer and patches are available for both of those.  It would be interesting to identify other users.
Things like this do change in libraries from time to time and people just deal with it as part of their release process.
Notice that the pull request combines different changes, each one has different benefits
The rename from wels/ to openh264/ makes code more readable, easier for new developers coming into these projects.  There is now progress on making packages of the headers for Debian and that may mean the headers end up on a lot more systems.  If the headers are installed on a lot of systems then it is better to have them under a directory with an obvious name like /usr/include/openh264

The thing is, with how the patch is right now, you're expected to change from #include <wels/codec_api.h>  to just #include <codec_api.h>, since include path given in the new pkg-config file already includes the openh264 part.
Those header names are awfully generic to include without any kind of prefixing directory.
At the very least, that needs fixed. But really, I also don't see the point in renaming this for no gain. You can do stuff like that on a major bump that breaks ABI, but not randomly.

The thing is, with how the patch is right now, you're expected to change from #include <wels/codec_api.h> to just #include <codec_api.h>, since include path given in the new pkg-config file already includes the openh264 part.

That is not actually true: in most cases, the build system has probably added the higher level directory (e.g. /usr/include) to the include path too so code can use #include <openh264/codec_api.h> and it will work
Another enhancement may involve renaming codec_api.h to openh264_api.h

The point is that there’s no need to change things in the first place. It’s just extra churn for countless of projects using the library, for no benefit.

Most people would be using this through ffmpeg or GStreamer and patches are available for both of those. It would be interesting to identify other users.

So you basically assume that there’s only 2 projects out there using the API?

Things like this do change in libraries from time to time and people just deal with it as part of their release process.

Yes, projects have breaking API changes occasionally when it’s justified and needed. Here I still don’t see any justification.

The rename from wels/ to openh264/ makes code more readable, easier for new developers coming into these projects. There is now progress on making packages of the headers for Debian and that may mean the headers end up on a lot more systems. If the headers are installed on a lot of systems then it is better to have them under a directory with an obvious name like /usr/include/openh264

Is it a blocker for Debian to use the pre-existing include path that has worked fine for nearly a decade? Or is it just that you don’t like the name?

That is not actually true: in most cases, the build system has probably added the higher level directory (e.g. /usr/include) to the include path too so code can use #include <openh264/codec_api.h> and it will work

Not everyone is on Linux or uses system-installed headers in default locations. That argumentation is rather weak.

The thing is, with how the patch is right now, you're expected to change from #include <wels/codec_api.h> to just #include <codec_api.h>, since include path given in the new pkg-config file already includes the openh264 part.

That is not actually true: in most cases, the build system has probably added the higher level directory (e.g. /usr/include) to the include path too so code can use #include <openh264/codec_api.h> and it will work
Another enhancement may involve renaming codec_api.h to openh264_api.h

But why change at all? <wels/codec_api.h> does not conflict with anything, and has been in use for nearly a decade. Any API change like this is disruptive. The interface is settled since ages ago and there’s no practical issue, other than that your dislike the name and assume breaking all users is fine.

The point is that there’s no need to change things in the first place. It’s just extra churn for countless of projects using the library, for no benefit.

Most people would be using this through ffmpeg or GStreamer and patches are available for both of those. It would be interesting to identify other users.

So you basically assume that there’s only 2 projects out there using the API?

No, but those are some of the more well known

Things like this do change in libraries from time to time and people just deal with it as part of their release process.

Yes, projects have breaking API changes occasionally when it’s justified and needed. Here I still don’t see any justification.

The rename from wels/ to openh264/ makes code more readable, easier for new developers coming into these projects. There is now progress on making packages of the headers for Debian and that may mean the headers end up on a lot more systems. If the headers are installed on a lot of systems then it is better to have them under a directory with an obvious name like /usr/include/openh264

Is it a blocker for Debian to use the pre-existing include path that has worked fine for nearly a decade? Or is it just that you don’t like the name?

Different system administrators and package maintainers would have different attitudes to that.
The way I think about it personally: if every project had an obscure name for their header directory then it would be unreasonably tedious for people to identify things in /usr/include or in the #include statements.

@GuangweiWang I think this PR needs to be reverted immediately, it breaks everyone for no benefit. Note that it is also inconsistent with the Meson port that still install header files in the old location and generate a pkg-config file as before.

The other solution is to drop all Makefile and rely on Meson only, because it already copy all headers into wels/ subdir so they can be used uninstalled. :D

The other solution is to drop all Makefile and rely on Meson only, because it already copy all headers into wels/ subdir so they can be used uninstalled. :D

The existence of constructive solutions like this demonstrates that the "reverted immediately" reaction was never optimal, it is far better to allow a little bit of time for the issue to percolate and then move forward

it is far better to allow a little bit of time for the issue to percolate and then move forward

Leaving time for more people to wonder why their build fail? What do we gain from that?

it is far better to allow a little bit of time for the issue to percolate and then move forward

Leaving time for more people to wonder why their build fail? What do we gain from that?

Many people may have already updated their build by now and would have to make extra effort if it is reverted.  The effort of changing the name is so trivial that some people may have already done it without feeling it was worth the effort to post a comment here.  Sadly those people don't have a voice in discussions like this.
Libraries do make changes like this from time to time, this is a relatively trivial case.
Which part of it concerns you more personally, the directory name openh264 or the (non)inclusion of the suffix in the pkgconfig file?  I'm more sympathetic to people who argue for a partial revert that only impacts pkgconfig.

I highly doubt that.
This isn't even released yet, so majority of people haven't even noticed.
It's just pointless breakage for no advantage, forcing downstream projects to either add hacky ifdef hell, or require super bleeding edge versions.
Please just revert it. Or remove the entire buildsystem if you prefer... having two build systems that produce incompatible results is ridiculous anyway.

Most people would be using this through ffmpeg or GStreamer and patches are available for both of those. It would be interesting to identify other users.

Do you have link to the proposed patches? Did they merge it yet?

Most people would be using this through ffmpeg or GStreamer and patches are available for both of those. It would be interesting to identify other users.

Do you have link to the proposed patches? Did they merge it yet?

Not merged in ffmpeg at least, because we saw that this had only been merged for a couple of days and the change was entirely pointless, so I requested a revert https://github.com/cisco/openh264/pull/3488 immediately afterwards.

The proposed patch to ffmpeg was also breaking backwards compatibility, for a version without a release, and was wrong due to the wrong patch in the pkg-config file.

Many people may have already updated their build by now and would have to make extra effort if it is reverted.

This is a logically inconsistent statement on several levels.

you formerly justified this PR with the statement:

Most people would be using this through ffmpeg or GStreamer and patches are available for both of those. It would be interesting to identify other users.

i.e. you believe that very few people "actually" use openh264, and that no one needs to update their builds other than two projects, one of which responded to this PR by flatly rejecting your patch, refusing to fix their build, and demanding this PR be reverted

anyone who has updated their build but (unlike you, Mr. Pocock) cares about API stability and backwards compatibility, has to have two codepaths, one for before this change, one for after this change. So, if they support both then they are also compatible with having this change reverted.

The effort of changing the name is so trivial that some people may have already done it without feeling it was worth the effort to post a comment here.

Everyone who did post a comment here insists that the change is so non-trivial that they refuse to do it because the change is too hard and breaks everything, so "please instead revert the change here".

Sadly those people don't have a voice in discussions like this.

??? What does that mean, they don't have a voice?
Of course they have a voice. They may decline to exercise the voice, but they certainly have it. If they feel that reverting this change is bad, they are empowered to comment here.
Let's turn the argument around. You made a change that a bunch of people feel was bad. Why did you submit this PR? What about the people who felt the issue was so obvious that it must clearly be rejected, because it breaks API compatibility?
Sadly, the ffmpeg developers don't have a voice in discussions like this, because they thought it was obviously wrong so they didn't feel it was worth posting a comment.

Libraries do make changes like this from time to time, this is a relatively trivial case.

Libraries do NOT make changes like this, and this is NOT a relatively trivial case.
Or so say a bunch of people who find that this change was NOT trivial, and causes them a lot of problems. :)

one of which responded to this PR by flatly rejecting your patch, refusing to fix their build, and demanding this PR be reverted

and the other one uses the Meson port that has not been changed here, so they cannot accept such a patch anyway. I also failed to see a MR in GStreamer, did you really submitted one? Do you have a link?

Is it a blocker for Debian to use the pre-existing include path that has worked fine for nearly a decade? Or is it just that you don’t like the name?

I took a look at this.
It turns out that this PR was merged on February 23, and on March 1 @dpocock mentioned "There is now progress on making packages of the headers for Debian".
However, Debian actually uploaded the package of the headers a month before that, on January 18 the headers package was uploaded to Debian unstable.
The Debian package uses the wels/ directory. The Debian package would be broken by this PR.
@dpocock was not involved in the Debian bug at all, although due to https://www.debian.org/News/2021/20211117 he may have tried but lacked the opportunity. Either way, before proposing that this PR is a Debian requirement, we should probably ask Debian whether they want this patch.
With that in mind, @bgermann seems to be the Debian maintainer of libopenh264-dev, perhaps we can get some enlightenment here on what Debian's preferences are?

Sadly, the ffmpeg developers don't have a voice in discussions like this, because they thought it was obviously wrong so they didn't feel it was worth posting a comment.

Actually, 3 of us commenting here are ffmpeg developers - we just didn’t spell out our affiliation.
I made the revert PR #3488 as soon as I had understood full picture here.

Ah, to clarify: "Let's turn the argument around."
That was my attempt at humorously inverting the scenario, and theorizing that in between Aug 30, 2021 and February 23, 2022, your failure to comment on an unmerged PR constitutes "not having a voice".
According to the logic above, if people "don't have a voice" we should be defensive of their voice by not doing anything. This logic is currently being used to say that the PR should not be reverted, because these theoretical voiceless people can't say anything in defense of the PR.
So my line of thinking is that a couple months ago, the same logic should have been used to reject merging this PR to begin with.
(Alternatively, people who want to have a voice, will exercise that voice. ffmpeg has done so after the merge, but before a stable release. Anyone who actually likes this PR is welcome to volunteer their perspective at any time, but hopefully also before a stable release.)

Back to practical actions we can take:
I personally feel the idea from @xclaesse dropping the old build script completely and focusing on the Meson build script is the best.  @BtbN appears to be saying the same thing too.  Coincidentally, that would also drop the changes introduced by this PR and it makes #3488 redundant
@xclaesse do you want to create a pull request for your proposal?  If that is accepted by the project owner then we can restart this discussion after that.
The Gstreamer patch is on this branch:
https://gitlab.freedesktop.org/pocock/gst-plugins-bad/-/tree/pocock/openh264-include-wels

Libraries do NOT make changes like this, and this is NOT a relatively trivial case.

The OpenSSL 1.0 to 1.1 change involved code changes too, this only involves a path change, so it is trivial relative to that.
Ultimately, it is for the project owner to decide and everybody else will have to live with it.  I'm happy to update my patches for both ffmpeg and GStreamer to go with the final decision of the project owner and the Meson build if that is what comes about.

I personally feel the idea from @xclaesse dropping the old build script completely and focusing on the Meson build script is the best. @BtbN appears to be saying the same thing too. Coincidentally, that would also drop the changes introduced by this PR and it makes #3488 redundant

So if we agree that we should restart this discussion from a clean slate, let's revert this commit (which is a much smaller decision to make than to remove the build system that, as far as I know, Cisco themselves actually use) and restart it from there. As far as I undestood @xclaesse 's suggestion, it was a tongue-in-cheek comment implying that removing one build system would have the same effect as reverting the patch.
I don't see why that would need to be linked with removing one out of two build systems (which is an entirely orthogonal issue).

Ultimately, it is for the project owner to decide and everybody else will have to live with it. I'm happy to update my patches for both ffmpeg and GStreamer to go with the final decision of the project owner and the Meson build if that is what comes about.

If the final decision for openh264 is to change its include paths, then one requirement is patches for ffmpeg that transparently work for users both with the existing releases and upcoming ones - without requiring users to jump through any hoops.

I don't see why that would need to be linked with removing one out of two build systems (which is an entirely orthogonal issue).

If one of the build systems is not removed then I should get to work creating an equivalent patch for the Meson build
But I think it is better to just have one system or the other.  Otherwise we end up with changes like this where somebody forgets to update Meson.

If the final decision for openh264 is to change its include paths, then one requirement is patches for ffmpeg that transparently work for users both with the existing releases and upcoming ones - without requiring users to jump through any hoops.

This could be streamlined somewhat by only partially reverting the commit, so the path name will definitely be openh264/* but the pkgconfig file will be the same as before without any suffix.

@eli-schwartz if you are going to share what is obviously a defamation then please also share the Red Hat case
January, Matthew Miller declares a web site doesn't obey his Code of Conduct (CoC)
March, an independent legal panel looked at evidence presented by both sides and decided not only that Miller was wrong, but went as far as declaring that Miller's attempt to enforce a CoC is harassing a volunteer and abuse of an administrative process:
https://www.adrforum.com/DomainDecisions/1980642.htm
News sites were so quick to ridicule the case that they didn't even spell the trademark correctly in one case
https://www.theregister.com/2022/03/16/red_hat_fedotra/
We can thank Miller for submitting his claim to an independent review.  The rogue elements of Debian have never submitted their gossip to any independent review because they know they are always right, just as Scientologists know they are right

I do not have a strong opinion on this. Please release a version when you have decided on this. It would be great to make that happen this year because the freeze for Debian's first stable release including the openh264 pkg will be next January.
I just want to let you know that I apply a related patch.

@dpocock

@eli-schwartz if you are going to share what is obviously a defamation then please also share the Red Hat case

I am not "sharing a defamation" -- who is right and who is wrong isn't topical here.
I'm positing that the result of it is, you are not currently coordinated with Debian in order to authoritatively rule on what Debian considers a libopenh264-dev packaging blocker.
@bgermann

I just want to let you know that I apply a related patch.

This patch is entirely unrelated. The .pc currently hardcodes:

includedir
libdir

and your patch fixes the latter, this PR fixes neither one but swaps the former out for a different hardcoded location.
This PR also makes a second change, to remove the wels/ directory (the includedir specifies the location of the wels/ directory) entirely.

That is not actually true: in most cases, the build system has probably added the higher level directory (e.g. /usr/include) to the include path too so code can use #include <openh264/codec_api.h> and it will work

That is not guaranteed at all and requiring that shows that this solution is all the more broken.

The Gstreamer patch is on this branch:
https://gitlab.freedesktop.org/pocock/gst-plugins-bad/-/tree/pocock/openh264-include-wels

A patch on an unmerged branch is not anywhere close to actually being merged in the upstream project.  Speaking with my GStreamer maintainer hat on, this branch would not be merged as-is because it doesn't support both the old openh264 include layout and the new openh264 include layout introduced by this PR.  This requirement would be the same as ffmpeg.
I would very much vote in favour of reverting this PR entirely as it doesn't actually seem to provide any real benefit.

After thoroughly thinking and discussion, we decide to revert this PR to keep the code backward-compatibility. (PR #3488 would be merged then.)
@dpocock actually we first thought it was really good to make code easier-to-understand, we forgot that this would bring much more effort to do for people who adopt it. We wish we had a better name at the very beginning!
Again, thank all of you for your precious voice! We hope that we can hear from you again in the future!


More investigation is needed.

seems that all these has been fixed except one case, where we are reporting an error that is too strong. I'm closing this bug and created #25225 to track that.


suggestion

i have a suggestion

Feel free to update this issue or reach out to me at<EMAIL_ADDRESS>


Rename groups mapping keys to new names

For example,
datasets_and_dictionaries --> _DATASETS_AND_DICTIONARIES_
This will help the documentation.

Done!


Added function to get funding_address from Luno API

Added a missing function to get funding address

Coverage decreased (-1.1%) to 75.08% when pulling 17ef89f146e5be282824ca34ed0fb210e132fc9f on waleoyediran:master into d5cdd72a3418400e1c92ab12b43a8a632556c084 on grantstephens:master.

Hi @waleoyediran. Thanks for the PR, but the funding address is already in the receive section- called get_receive_address

Thats correct @grantstephens.
Thanks for pointing it out, i did not notice it.
Great work on this, I'd try to find other ways to contribute
The PR should be declined then :)

Thanks. I haven't tested it on other (Non ZAR) currency pairs, so please tread carefully as there may be dragons.


Bugfix: changing line length did not invalidate cache

The cache was based only on the html string, not the line length. Therefore, when changing the line length, the result of the function did not change until the page was reloaded.
This should fix #3107.

Please add CHANGELOG entry. Then merge.

CHANGELOG entry added and rebased.


Question about the implementation of stops_at

Could you please provide a comprehensive explanation of the underlying theory that governs the concept of 'stop_at'? In cases where 'stop_at' is employed to ascertain the absence of specific characters at the conclusion of a sequence, what are the potential consequences and implications of such an evaluation? Furthermore, should 'stop_at' identify the presence of said characters, does it subsequently prompt a modification in its querying approach, leading to a repetition of the inquiry process? If indeed such a repetition occurs, I am curious to know the precise nature of the revised prompt that would be presented.

stops_at merely serves as stopping criterion and simply forces an end to text generation once the stopping phrase is encountered. It does not remove the phrase nor does it prevent the phrase from being generated. We also do not re-query the model to enforce constraints, but rather pro-actively mask its token distribution.
I hope this answers your question. If not, please let me know, I am happy to discuss further.


feat: add useRouter property to sidenav

Closes carbon-design-system/carbon-components-angular#2811
This MR adds a useRouter option to the SideNav component (which is false by default).
When the input is true, routerLink will be used instead.
Changelog
New

adds useRouter input to SideNav

recheck

recheck

recheck

Thanks for the review @Akshat55!  Took care of your remarks.
Quick question, did you do manual linting here? If so, is there a possibility to automate some things? Like adding eslint or prettier to the repo maybe?

Quick question, did you do manual linting here? If so, is there a possibility to automate some things? Like adding eslint or prettier to the repo maybe?

We do some manual linting here and there while reviewing the code. We do have a linter (tslint) and we run it prior to pushing the commit (using husky).
We haven't updated to eslint in v5 because we noticed it was taking way too long. From what I've seen, the duration has decreased and we plan to replace our existing linter with eslint in v6!

Quick question, did you do manual linting here? If so, is there a possibility to automate some things? Like adding eslint or prettier to the repo maybe?

We do some manual linting here and there while reviewing the code. We do have a linter (tslint) and we run it prior to pushing the commit (using husky).
We haven't updated to eslint in v5 because we noticed it was taking way too long. From what I've seen, the duration has decreased and we plan to replace our existing linter with eslint in v6!

Ah right, noticed a warning in my console when pushing/committing. Prolly I should look into resolving that.

This PR enabled the routing by default, but didn't take in consideration the routeExtras passed to the component (which is breaking anyone using the relativeTo option)


[BUG] keyword timeout not respected in teardown, because of "retry_interval".

When using Wait Untless Keyword Succeeds in test teardown, it is possible to have much longer execution time than allowed by the "user keyword timeout".
In practice, in teardown, Wait Untless Keyword Succeeds does skip the keyword re-execution when timeout has been reached, but not the retry_interval.
Out of teardown it works as expected, no re-execution occurs, therefore no retry_interval is included.
Example code:
*** Test Cases ***
Test 1: Works as expected when used in test body
    [Documentation]    Does not last much longer than keyword timeout.
    My Keyword

Test 2: Keyword timeout not respected in teardown
    [Documentation]    Lasts much longer than keyword timeout.
    No Operation
    [Teardown]    My Keyword

*** Keywords ***
My Keyword
    [Documentation]    This keyword should stop when reaching timeout
    [Timeout]    2s
    Wait Until Keyword Succeeds    4x    10s
    ...    Fail Slowly    60s

Fail Slowly
    [Documentation]    Sleeps and fails.
    [Arguments]    ${sleep_duration}
    Sleep    ${sleep_duration}
    Fail    failed on purpose

Example output:

This feels like a bug when checked against documentation.

Wait Until Keyword Succeeds states:

All normal failures are caught by this keyword. Errors caused by invalid syntax, test or keyword timeouts, or fatal exceptions [...] are not caught.

User guide on User keyword timeout:

User keyword timeouts are applicable also during a test case teardown, whereas test timeouts are not.

I believe the expected behavior would be that retry interval are also skipped when timeout has been reached.

I can reproduce the bug and it seems to be a pretty old regression caused by #3398. I'll debug this further and see how easy fixing it is. It will certainly be fixed in RF 7.2, but if the fix isn't too complicated, we can backport it also to RF 7.1.1 that will be released soon.

Fixed in d4c002fbc0d4f5786809871edd9c876c8426ea47 and 96bc2384c508d95a6782f94880c8bd4b0b1de5b2. Cherry-picked to the v7.1-maintenance branch in de07bffffe62387bbd3a246dbf746922b5e533cd and 3c5f7c63bb00bc4b23a24ca73271aeceedd9c5a5.


Not recognizing reason language

What is it I am missing here?
I think it is parsing in OCaml instead.

I'm not sure what is causing that without more information about how your project is set up. Do you have merlin installed local to the project?

I have following settings set up in user settings
   "reason.path.ocamlmerlin": "/home/absolutezero/.opam/4.03.0/bin/ocamlmerlin",
    "reason.path.refmt": "/home/absolutezero/.opam/4.03.0/bin/refmt",
    "reason.path.rtop": "/home/absolutezero/.opam/4.03.0/bin/rtop",
    "reason.formatOnSave": true

How do I install merlin locally to the project?

I cloned this project: https://github.com/reasonml/ReasonNativeProject
It already has .merlin.

I cloned this project: https://github.com/reasonml/ReasonNativeProject
It already has .merlin.

Can you try unsetting the user settings you mentioned above? As long as your PATH is set up correctly you shouldn't need to use them unless you have some custom versions or something. If you don't override them, the reason mode should use the ocamlmerlin binary that is installed when you set up the dependencies with npm or whatever.

I get the following error when I unset those settings

/home/absolutezero/.vscode/extensions/freebroccolo.reasonml-0.0.99/node_modules/ocaml-language-server/out/src/server/processes/merlin.js:25
                throw error;
                ^

Error: spawn ocamlmerlin ENOENT
    at exports._errnoException (util.js:1026:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
[Error - 6:58:42 AM] Connection to server got closed. Server will not be restarted.

But ocamlmerlin should be in PATH as
$ which ocamlmerlin
/home/absolutezero/.opam/4.03.0/bin/ocamlmerlin

How do you have your shell environment setup? How did you install opam? For whatever reason, when node tries to spawn ocamlmerlin, the binary is not in the path.

I installed opam with what opam's website instructs to do.
wget https://raw.github.com/ocaml/opam/master/shell/opam_installer.sh -O - | sh -s /usr/local/bin

And for reason, I installed it with opam install reason.

Maybe opam is not being initialized properly (and thus not setting the path) for new shells in some cases. Do you get the same output from the following commands?
sh -c opam
sh -cl opam

Yes

Oops, those commands should have run ocamlmerlin instead of opam. Can you try that? It probably won't make a difference but still…
I think the opam installer script should have either modified one of your shell init scripts or asked you to modify it manually. Do you see that somewhere in like ~/.profile or ~/.bash_profile or maybe one of the zsh files if you use that?
The only thing I can really think of is that there's some sort of misconfiguration with how the shell is initializing the opam stuff but it's hard to pinpoint from a distance.

sh -c ocamlmerlin runs off. But the other one:
$ sh -cl ocamlmerlin
sh: ocamlmerlin: command not found

Also in my .zshrc, the following line has been added.
. /home/absolutezero/.opam/opam-init/init.zsh > /dev/null 2> /dev/null || true

. /home/absolutezero/.opam/opam-init/init.zsh > /dev/null 2> /dev/null || true

It's a long shot but you could try moving this to ~/.zshenv instead and seeing if that helps. I think with ~/.zshrc, opam may only be initializing the path for login shells which could explain why it's failing for node but not when you try it manually.

Not working :slightly_frowning_face:

The problem turned out to be the environment (I opened vscode with dmenu) vscode was running on did not have them on PATH. Everything works fine when I opened vscode from the terminal. Thanks for taking your time.


Revert "refactor: improve build- and typescript configuration"

Reverts Zhengqbbb/cz-git#116

Reverts Zhengqbbb/cz-git#116

What was wrong?

What was wrong?

Don't worry, I'm backing up for testing. Just too busy today and yesterday, did not deal with in time lol 🤗

What was wrong?

Don't worry, I'm backing up for testing. Just too busy today and yesterday, did not deal with in time lol 🤗

Ah Okay, nice :grin:


Lost Kingdoms

I made one profile for Lost Kingdoms

Good work, have you tested the pack?
It looks good so far, you just have to set the generated_folder_name in the UniversalDIT_Flat_Pressed.json.

Just did the change you suggested and yeah I have tested the pack, works fine on my end


BL-579 Ensure book now button redirects to add courses and renders ap…

…propriate component
Description
Adding functionality to ensure that the Book Now button redirects to the appropriate route and as a consequence rendering the correct component relevant to the route
Fixes # (issue)
Book Now button did not redirect the user to any route
Loom Video
Please paste a link here of a quick loom video walking through what you did in your PR .

Type of change
Please delete options that are not relevant.

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

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have removed unnecessary comments/console logs from my code
[x] I have made corresponding changes to the documentation if necessary (optional)
[x] My changes generate no new warnings
[x] I have checked my code and corrected any misspellings
[x] No duplicate code left within changed files
[x] Size of pull request kept to a minimum
[x] Pull request description clearly describes changes made & motivations for said changes

Great job fixing this. Even small issues can cause major problems so this waa a great simple fix!


libjwt: 1.17.0 -> 1.17.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/benmcollins/libjwt/releases.
meta.description for libjwt is: JWT C Library
meta.homepage for libjwt is: https://github.com/benmcollins/libjwt
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.17.1 with grep in /nix/store/jni6j4xyrv40w5d5dakldwmv885288xw-libjwt-1.17.1
found 1.17.1 in filename of file in /nix/store/jni6j4xyrv40w5d5dakldwmv885288xw-libjwt-1.17.1

Rebuild report (if merged into master) (click to expand)

11 total rebuild path(s)

11 package rebuild(s)

First fifty rebuilds by attrpath

libjwt
python311Packages.pyslurm
python311Packages.seaserv
python312Packages.pyslurm
python312Packages.seaserv
seafile-server
seahub
slurm
slurm-spank-stunnel
slurm-spank-x11

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/jni6j4xyrv40w5d5dakldwmv885288xw-libjwt-1.17.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libjwt https://github.com/r-ryantm/nixpkgs/archive/9db99554eed2b6bda2a68070351a049e1ff878e6.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/9db99554eed2b6bda2a68070351a049e1ff878e6#libjwt

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/jni6j4xyrv40w5d5dakldwmv885288xw-libjwt-1.17.1
ls -la /nix/store/jni6j4xyrv40w5d5dakldwmv885288xw-libjwt-1.17.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

12 packages built:

libjwt
python311Packages.pyslurm
python311Packages.pyslurm.dist
seafile-server (python311Packages.seaserv)
python312Packages.pyslurm
python312Packages.pyslurm.dist
python312Packages.seaserv
seahub
slurm
slurm-spank-stunnel
slurm-spank-x11
slurm.dev

Maintainer pings
cc @pnotequalnp for testing.

Result of nixpkgs-review pr 312207 run on x86_64-linux 1

12 packages built:

libjwt
python311Packages.pyslurm
python311Packages.pyslurm.dist
seafile-server (python311Packages.seaserv)
python312Packages.pyslurm
python312Packages.pyslurm.dist
python312Packages.seaserv
seahub
slurm
slurm-spank-stunnel
slurm-spank-x11
slurm.dev


NNBD version of ListCopy.spread.int.{2, 100} benchmarks is slower than Dart 2 version

Repro in AOT mode:
pkg/vm/tool/precompiler2 benchmarks/ListCopy/dart2/ListCopy.dart foo_old.snapshot
pkg/vm/tool/precompiler2 --enable-experiment=non-nullable --null-safety benchmarks/ListCopy/dart/ListCopy.dart foo_new.snapshot
pkg/vm/tool/dart_precompiled_runtime2 foo_old.snapshot
pkg/vm/tool/dart_precompiled_runtime2 foo_new.snapshot

Dart 2 results:
ListCopy.spread.num.2(RunTime): 31596.703125 us.
ListCopy.spread.int.2(RunTime): 33473.78333333333 us.
ListCopy.spread.num.100(RunTime): 17082.118644067796 us.
ListCopy.spread.int.100(RunTime): 17308.370689655174 us.

NNBD results:
ListCopy.spread.num.2(RunTime): 31666.171875 us.
ListCopy.spread.int.2(RunTime): 50043.9 us.
ListCopy.spread.num.100(RunTime): 16653.528925619834 us.
ListCopy.spread.int.100(RunTime): 23112.298850574713 us.

During migration an expensive input.cast<int>() was inserted into the migrated version of the benchmark, which caused this regression.


Make dbt CLI cold start load up to 8% faster with lazy loading of task modules and agate

The dbt CLI takes a while to load, especially before .pyc files are compiled. This PR makes things go much faster by making sure a handful of resources only get loaded when they are needed.
In isolation, this PR speeds things up by about 5%. The additional 3% requires a change to dbt-adapters.
Lazy loading task modules
The first change was already discussed, but issue #4627 was closed without ever being fully resolved:

Since the defaults are only used if a subcommand is being called, was thinking we could improve performance by only importing the relevant dbt.task. For example:

If the user uses the command dbt build we will only import dbt.task.build as build_task
If the user uses the command dbt clean we will only import dbt.task.clean as clean_task
If the user uses the command dbt without a subcommand we will not import any classes from dbt.task

Implementing this speeds up the CLI by about 5% on a cold start.
Use TYPE_CHECKING to import agate
When I run PYTHONPROFILEIMPORTTIME=1 dbt —help to see where some additional free speed-ups may be, agate sticks out as taking a while to load; specifically it takes up about 3.5% of the total load time for the command dbt —help.
agate appears to only be used in three contexts across dbt (correct me if I am wrong): dbt unit tests, dbt docs generate, and dbt seeds.
Most agate imports are actually just for type annotations, meaning runtimes such as dbt run —select foo that do not require agate at all will end up loading it.
Important note: Gating import agate behind if TYPE_CHECKING: also requires making this change to the dbt-adapters library as well. Once both dbt-core and dbt-adapters use if TYPE_CHECKING to import agate in those contexts, then this change should shave another 3.5% off load times, and this speed improvement will impact not just dbt —help but all dbt command invocations that don’t require agate.
Before and after
I use the following script to test speeds before and after the changes. Note that this is only testing the lazy loading of modules, not if TYPE_CHECKING: import agate for reasons stated above.
In my testing, the before and after difference is about 5%.
#!/bin/bash
# OS X - requires `brew install coreutils` for gdate

for ((i=1; i<=60; i++))
do
  find "./venv" -type f -name "*.pyc" -delete
  find "./.venv" -type f -name "*.pyc" -delete
  find "./core" -type f -name "*.pyc" -delete

  start=$(gdate +%s%3N)
  dbt --help >/dev/null
  end=$(gdate +%s%3N)

  # Ignore first 5 runs
  if [ $i -gt 5 ]; then
    echo $((end - start))
  fi
done

If we compare the before and after outputs of the PYTHONPROFILEIMPORTTIME=1 diagnostics, we can see what modules that are no longer avoided which account for the 5% speed-up:
import csv
from pprint import pprint

before = []
after = []
with open(‘imports-before.txt’) as f:
    reader = csv.reader(f, delimiter='|')
    for row in reader:
        before.append(row[-1].strip())
with open(‘imports-after.txt') as f:
    reader = csv.reader(f, delimiter='|')
    for row in reader:
        after.append(row[-1].strip())

pprint([i for i in before if i not in after])

Output:
['dbt.task',
 'dbt.parser.sql',
 'sqlparse.tokens',
 'sqlparse.utils',
 'sqlparse.sql',
 'sqlparse.exceptions',
 'sqlparse.cli',
 'sqlparse.engine.grouping',
 'sqlparse.keywords',
 'sqlparse.lexer',
 'sqlparse.engine.statement_splitter',
 'sqlparse.engine.filter_stack',
 'sqlparse.engine',
 'sqlparse.filters.others',
 'sqlparse.filters.output',
 'sqlparse.filters.tokens',
 'sqlparse.filters.reindent',
 'sqlparse.filters.right_margin',
 'sqlparse.filters.aligned_indent',
 'sqlparse.filters',
 'sqlparse.formatter',
 'sqlparse',
 'dbt.compilation',
 'dbt.task.printer',
 'dbt.task.base',
 'multiprocessing.dummy.connection',
 'multiprocessing.dummy',
 'dbt.task.runnable',
 'dbt.task.compile',
 'dbt.task.run',
 'dbt.task.snapshot',
 'dbt.task.seed',
 'daff',
 'dbt.task.test',
 'dbt.task.build',
 'dbt.task.clean',
 'dbt.task.clone',
 'dbt.links',
 'dbt.task.debug',
 'dbt.deps',
 'dbt.deps.base',
 'dbt.deps.local',
 'dbt.deps.tarball',
 'packaging',
 'packaging._structures',
 'packaging.version',
 'dbt.clients.git',
 'dbt.deps.git',
 'dbt.clients.registry',
 'dbt.deps.registry',
 'dbt.deps.resolver',
 'dbt.task.deps',
 'dbt.task.docs',
 'dbt.task.docs.generate',
 'socketserver',
 'shlex',
 'webbrowser',
 'http.server',
 'dbt.task.docs.serve',
 'dbt.contracts.results',
 'dbt.task.freshness',
 'dbt.task.init',
 'dbt.task.list',
 'dbt.task.run_operation',
 'dbt.task.retry',
 'dbt.task.show']

It looks like this PR needs a artifact_minor_upgrade label because I add if TYPE_CHECKING: to a file in core/dbt/artifacts.

@dwreeves Thank you for making dbt better! We hope to have even more improvements to start-up time coming your way soon.

Thanks @MichelleArk and @peterallenwebb!
The associated dbt-adapters PR is essential for realizing the speed boost across the dbt runtimes which don't use agate. Not sure who is in charge of that.


Symphony Orchestra, Period 8 is actually on Thursdays (most of the time), Not Fridays, leo babe please fix for that specific class.

I think this is more so a caveat of symphony labeling itself as an 8th period class in Schoology; I suppose there could be a new timeslot made specifically for symphony, although I don't think that's going to work very well in the case that symphony is canceled, etc. Do you know if there's any publicly available schedule for symphony that could be parsed?


Update the URL

Can one of the admins verify this patch?

mesosphere-ci ok to test

@elopio Thanks a lot for fixing the repository url! Good catch 💯 👍

Thanks to you for reviewing :)


cleaning

This pull request introduces 1 alert when merging 2166f3eed2b476daf8ec48b4513528532a6f9ba2 into 25cfc7446b814bcfb3d3cf29bc83b4b69d774af8 - view on LGTM.com
new alerts:

1 for Inconsistent equals and hashCode

Comment posted by LGTM.com


Perf/a11y

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 66.91%. Comparing base (c968bbc) to head (5a2bfad).
Report is 116 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1052      +/-   ##
==========================================
- Coverage   69.29%   66.91%   -2.38%
==========================================
  Files          42       43       +1
  Lines         508      529      +21
  Branches       73       78       +5
==========================================
+ Hits          352      354       +2
- Misses        151      168      +17
- Partials        5        7       +2

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


Release Request

Hello!
While working to get SwiftGRPC compatible with CocoaPods, it looks like this is the only Pod that hasn't been published that is required. Would it be possible to get a release that includes the updated changes to the imports that allows for Cocoapods to build? 👍
Thanks!

@Jake-Prickett yes, we're working on a release anyway. Basically once #185 is in, we can release

I'll work on finishing that today

@weissi nice, thank you! 👍 No rush!

@Jake-Prickett done :)

https://github.com/apple/swift-nio-ssl/releases/2.7.0

Thank you @weissi!


SchTask Support for ConvergenceStrategy::InstallMsi.converge

It's a dependency for getting machine_image supported for run_lists that include wsus updates and other tasks required to be run on \LocalMachine.
chef/mixlib-install#9 should get us to a point where MixLib install support SchTask
by creating a install_command but I think we'll need make changes to  ConvergenceStrategy::InstallMsi.converge to support creation / usage of a chef-client-schtask

Related if we want a pure SchTask based install and run:
chef/mixlib-install/#9
Background:
chef/chef-provisioning#409
chef/chef-provisioning#410

We need updates applied, and they can only be applied successfully via schtask.
This is a spike that works, but I'd definitely feeling the pain of our lack of schtask provisioning to do this properly. (It sorta works, I get a 401 authentication fails after the wsus-updates apply, but that a different issue) @adamedx @tyler-ball @mwrock  ?
require 'chef/provisioning/aws_driver'
require 'pry-byebug'
current_dir = File.dirname(__FILE__) # to get relative files... encrypted databag

with_chef_server "https://api.chef.io/organizations/#{ENV['CHEF_ORG']}",
                 :client_name => Chef::Config[:node_name],
                 :signing_key_filename => Chef::Config[:client_key]

with_machine_options bootstrap_options: {
                       instance_type: 'c3.2xlarge',
                       subnet_id: 'subnet-6021b417',
                       security_group_ids: [
                         'sg-689c5a0c',
                         'sg-6f9c5a0b',
                         'sg-0a9a5c6e'
                       ]
                     },
                     aws_tags: {
                       :created_by => 'chris',
                       :please_destroy => 'true'
                     },
                     transport_address_location: :private_ip,
                     image_id: 'ami-7bc3e04b' # aws-marketplace/CIS Microsoft Windows Server 2012 R2 Benchmark v1.1.0-26bb465c-ce26-4da9-afb8-040b2f8c9a7f-ami-7a88f312.2

machine_name = 'base-2012-hardened-xv'

m = machine "#{machine_name}" do
  action :allocate
end

# converge a machine with chef-client::task
machine "#{machine_name}" do
  #action :nothing
  action :converge
  attribute %w{ client_client task frequency}, 'once'
  recipe 'chef-client::task'
  # these attributes will be use in the wsus convergence via schtask
  attribute %w{ wsus_client no_reboot_with_logged_users }, false
  attribute %w{ wsus_client automatic_update_behavior }, :install
  attribute %w{ wsus_client reboot_warning }, 1
  attribute %w{ wsus_client reboot_prompt_timeout }, 1
end

ruby_block "Run wsus-update via schtask on #{machine_name}" do
  #action :nothing
  block do
    mr=resources(machine: machine_name).provider_for_action(:ready)
    mr.load_current_resource
    machine=mr.action_ready
    driver = node.run_state[:chef_provisioning].drivers.values.first
    i=driver.ec2.instances[machine.machine_spec.reference['instance_id']]
    #not sure how to add recipes in a ruby_block...
    # it also seems that any machine 'thismachine' { recipe 'foo' }
    # resources that come later in __FILE__ update the run_list before
    # they execute, probably something to do with execution contexts
    ah = Chef::Provisioning::ChefProviderActionHandler.new(mr)
    if machine.execute_always(
         "knife node show #{machine_name} -a run_list -c c:\\chef\\client.rb"
       ).stdout.lines.grep(/wsus-client/).empty?
      machine.execute(ah,
        "knife node run_list add #{machine_name} wsus-client -c c:\\chef\\client.rb"
      )
    end
    machine.execute(ah, 'schtasks /run /tn chef-client')
    finished_running = false
    timer = 0
    until finished_running
      task_query = machine.execute_always('schtasks /query /tn chef-client').stdout.lines.grep(/chef-client/)
      finished_running = task_query.grep(/Running/).empty?
      Chef::Log.warn "chef-client wsus-client schtask running for #{timer} seconds"
      sleep 10
      timer += 10
    end
  end
end

@hh rather than loading the machine from the resource_collection, I think you could just do m = machine "#{machine_name}" do so that m would be in scope during the ruby_block.
The bottom of your example (where the scheduled task is ran then queried) LGTM for getting into the convergence strategy.  But I would hope this is ultimately something handled by Mixlib::Install

A couple thoughts here.

I have found that running updates during a machine provisioning is generally best avoided if possible. Even on 2012R2 this can possibly take hours, cause a converge to time out, require reboots and have all the winrm/scheduled task issues you refer to. I found it best to do this in creating the base image like in a packer template. Here is a blog I wrote on this process. However I realize sometimes business constraints require this to be done during provisioning.

If you are gonna do the updates during a chef run, I'd be inclined to create a cookbook/recipe dedicated to this and use the scheduled task resource to wrap the updates. Here is an example of a recipe I wrote to use a scheduled task to install a service that required some certificate manipulationi not possible in a remote session:

#create the batch file from a template which does the stuff you want done in the task
batch_path = "#{node['platform_octopus']['home_path']}/octopus.bat"
template batch_path do
  source 'octopus.bat.erb'
  action :create
end

#create the task. Note this will create and run the task immediately and delete itself when done
windows_task 'octopus' do
  user 'administrator'
  password provisioner_bootstrap_password
  cwd 'C:\\Program Files\\Octopus Deploy\\Tentacle'
  command batch_path
  frequency :monthly
  frequency_modifier 12
  run_level :highest
  action [:create, :run]
  notifies :delete, 'windows_task[octopus]', :delayed
  guard_interpreter :powershell_script
  not_if "(Get-Service | ? {$_.name -Contains 'OctopusDeploy Tentacle'}).count -gt 0"
end

ruby_block "Discover Octopus Machine (#{node['platform_octopus']['server_uri']})" do # ignore ~FC014
  block do
   # your code that checks if the task has finished
  end
end

I find this to be alot cleaner and can separate the wsus stuff from the provisioning script. This does not address possible issues with timeouts or reboots but like your code above, it will run the updates driven by a winrm based run.
Not sure if this helps at all in your scenario. Windows updates are a major pain (I say as I test a packer template against windows 7 with about 250 updates).

We should create a new convergence strategy called install_msi_schedule.rb and either set that as the default or let users specify that they want to use that.  We should also add a toggle for whether to run system updates since those can take forevvvvvvver.  This will also probably depend on https://github.com/chef/chef-provisioning/issues/362

Looks like we should be using https://github.com/WinRb/winrm-elevated

@tyler-ball @sneal is https://github.com/WinRb/winrm-elevated/ working well enough for me to try to create a stake in the ground for this?

@hh I haven't tested it

Looks like the dependency may have been moved from winrm-elevated into WinRb/winrm-fs#22  supplanting test-kitchen/winrm-transport#16 and directly using winrm-elevated. @mwrock is this correct?

I'm guessing I should wait for WinRb/winrm-fs#22 to support schtask before tackling this. Willing to help on that, but didn't want to overlap.

winrm-elevated would be the gem to leverage for elevated winrm commands that use a scheduled task under the hood. I know @sneal extracted that out of the current vagrant code. If that is what vagrant master is using, then I'd say it is pretty solid.


Escape test ID`s in Testing API

I have Python project with pytest's tests and I catch this error
Error: Test IDs may not include the "<path-to-test>/tests/unit/interactions/mastercard/test_mastercard.py::TestMasterCardDeleteCard::test_generic_404_exception_is_not_affected[\u0000]" symbol
	at new D (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:87)
	at Object.createTestItem (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:95)
	at vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9
	at vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9
	at Array.forEach (<anonymous>)
	at g (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at m (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9
	at Object.forEach (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:87)
	at g (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at m (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9
	at Object.forEach (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:87)
	at g (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at m (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9
	at Object.forEach (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:87)
	at g (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at m (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9
	at Object.forEach (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:87)
	at g (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at m (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9
	at Object.forEach (vscode-file://vscode-app/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:87)
	at g (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at Object.m [as updateTestItemFromRawData] (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:9)
	at _.resolveChildren (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:59)
	at _.refreshTestData (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:59)
	at processTicksAndRejections (internal/process/task_queues.js:93)
	at async v.refreshTestDataInternal (vscode-file://vscode-app/Users/perseus/.vscode/extensions/ms-python.python-2021.10.1336267007/out/client/extension.js:59)

Pytest allow to parametrize and test looks like this
    @pytest.mark.asyncio
    @pytest.mark.parametrize('body', ['', 'test', '{}', '{"test": true}', b'', b'\x00'])
    async def test_generic_404_exception_is_not_affected(

-> test_generic_404_exception_is_not_affected[\u0000] is valid test name

Version: 1.61.2

NUL bytes are not allowed in test ID names, since we use it for delimiters internally


pullapprove: Require documentation team approval

For all documentation files.
Signed-off-by: Samuel Ortiz<EMAIL_ADDRESS>

Coverage increased (+0.3%) to 75.206% when pulling bb1f2597d53e51a923c1137de1f8ed8816ab0a76 on sameo/topic/ci into d6109f0b84f38cd40b012154c4c88eabb1f98842 on master.

lgtm

LGTM

I'm not too sure we need to gate every change to md files with the ack from the documentation team, that adds both delay and burden on already stretched individuals. Oh well.
lgtm

@dlespiau I agree about the latency this will introduce. I think the easiest way to go away with that is to submit a PR for code changes only, and then you can submit a PR to update the readme. That way, you don't care if it takes some time to get the documentation's PR merged.

@sboeuf I'm not sold on the split PR idea - that could mean the code and the docs get out of sync, and that is bad. If we do find there is a problem with getting the docs processed then I think it would be better we find another way of fixing that.

I agree with @grahamwhaley. Honestly, how many PRs have we absolutely had to land "immediately" or the world will end?
If a developer is impatient to use some pending PR code, they can merge it into their branch and keep working.
Absolute worst case, we temporarily disable pullapprove.

This is just a pullapprove change away. If this proves to be ineffective, we can disable that at will. I trust the documentation team latency will be low enough.

@jodh-intel it is not about the world ending but more about the eternal rebase of a PR that is ready, but not ready for the doc.


RUN ERROR

Traceback (most recent call last):
File "./labelImg.py", line 28, in
import resources
File "/home/zhangxuan/software/labelImg/resources.py", line 6315, in
qInitResources()
File "/home/zhangxuan/software/labelImg/resources.py", line 6310, in qInitResources
QtCore.qRegisterResourceData(0x01, qt_resource_struct, qt_resource_name, qt_resource_data)
TypeError: qRegisterResourceData(int, str, str, str): argument 2 has unexpected type 'str'

using pyrcc4 -py3 -o resources.py resources.qrc


Feature request: implement Rayleigh random sampling op

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 16.04
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 1.6.0
Python version: 3.5
Bazel version (if compiling from source): -
GCC/Compiler version (if compiling from source): -
CUDA/cuDNN version: 9.0
GPU model and memory: 1080
Exact command to reproduce: -

You can collect some of this information using our environment capture script:
https://github.com/tensorflow/tensorflow/tree/master/tools/tf_env_collect.sh
You can obtain the TensorFlow version with
python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
Describe the problem
Describe the problem clearly here. Be sure to convey here why it's a bug in TensorFlow or a feature request.
TensorFlow does not currently offer tf.random_rayleigh, similar to np.random.rayleigh. What would be the simplest way to add this op?
The distribution is:

You can sample from a Rayleigh distribution using the uniform sampler.  Use tf.random_uniform and then pass it through
x = sigma * tf.sqrt(-2*/np.log(2) * tf.log(u))

@jvdillon we can add this as a distribution pretty easily.

Ive added this request to our internal feature request tracker. Thanks!

Nagging Assignee @jvdillon: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @jvdillon: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @jvdillon: It has been 16 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @jvdillon: It has been 79 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @jvdillon: It has been 94 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @jvdillon: It has been 109 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

I'll created and will soon submit tfp.math.random_rayleigh in
https://github.com/tensorflow/probability


New Airport: SAWH (Ushuaia Airport)

Ushuaia Airport, officially "Aeropuerto Internacional Malvinas Argentinas" (A very controversial name as it reflects Argentina's claims of sovereignty over the Falkland Islands) is a small airport at the southern tip of Argentina in Ushuaia, the southernmost city in the world. I made this airport mainly because I wanted to play around with terrain (I think it looks pretty good, although there are some errors north of the airport, where there's two overlapping areas with an elevation of 1000ft).
This PR also includes changes to LAN and TAM, since the 2 airlines have merged into one airline called LATAM.
When #561 is merged, d8d0de9 and c9df00e will become unnecessary.

@Fechulo, I am getting a parse error on sawh.json line 50.  Could you please fix so it passes JSON validation?
If possible also rebase/merge to resolve the merge conflicts

@tedrek I'm currently away and I'm not able to do anything with my phone. I'll be home this evening, so I'll do it then. (~2300z)

Heh, and here I was going to be happy if you got to it within a couple of weeks :wink:

Haha, I was actually too tired to do it yesterday, so I'll do it today. I might close this PR and open a new one with the fixes.


 IF YOU DO NOT FOLLOW THE FORMAT OR MAKE A GENERIC TOKEN REQUEST YOUR ISSUE WILL BE DELETED WITHOUT COMMENT
YOUR JUSTLIST MUST FOLLOW THE JSON SPECIFICATION
https://github.com/justswaporg/justlists/blob/main/example.justlists.ts
Checklist

[x] I understand that this is not the place to request a token listing.
[x] I have tested that my JustList is compatible by pasting the URL into the add a list UI at justswap.org.
[x] I understand that filing an issue or adding liquidity does not guarantee addition to the justlists website.

Please provide the following information for your token.
JustList URL must be HTTPS.
JustList URL: https://tronscan.org/#/token/1004011
JustList Name: c23
Link to the official homepage of the JustList manager:

Sorry, your issue will be closed as you did not submit your information in the correct URL and homepage.Please resubmit.


[Bug]: Checkout page navbar not working and no proper routing and organising of files

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
When i got to top deals from navbar and then book a service so i will be on the payment or checkout page there is navbar but when i click on home or any other link it is not redirecting me anywhere so i want to fix the routing part and the routing is not properly done.
Expected behavior
So what i want to suggest is that we can create a express app to support it and a ejs template with it to organise all the files and put them in a single place so that developers can understand code properly as right now it is too messy and also the links are not clean like #Home, #Services and so these are not professional routes so i want to fix this. Assign me under gssoc 2024 ext and hacktoberfest and i will be on it. I will use express js for the routing.
Add ScreenShots

On which device are you experiencing this bug?
Windows
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[ ] I'm a VSOC'24 contributor
[X] I have starred the repository

@apu52 Assign this to me under gssoc 2024 ext and hacktoberfest, I would like to contribute to this.

@tarunkumar2005 u are assigned . really great issue .

@apu52 I would suggest one thing your project is good but i think you should organise the files a bit means like in folders or somewhere as they are spread in the main dir which is not good this is my suggestion.

@apu52 I would suggest one thing your project is good but i think you should organise the files a bit means like in folders or somewhere as they are spread in the main dir which is not good this is my suggestion. that is what i will be doing in this.

yeah . Thanks for the suggestion . & thanks for your issue also .


Error: Could not find file in 'getValidSourceFile' during 'quickinfo'

This issue comes from crash dumps in telemetry. We've tried to de-duplicate issues on a best-effort basis, comparing the sequence of methods called and the command requested while ignoring line numbers.
TypeScript Version Prefix: 2.7.1
VSCode Version 1.20.0-insider
command requested: quickinfo
hitting sessions: 517
proportion of all sessions: 0.001930019076204022
stack
Error: Could not find file
    at getValidSourceFile (tsserver.js:82737:23)
    at Object.getQuickInfoAtPosition (tsserver.js:82889:30)
    at IOSession.Session.getQuickInfoWorker (tsserver.js:89819:62)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (tsserver.js:88972:61)
    at unknown (tsserver.js:90393:88)
    at IOSession.Session.executeWithRequestId (tsserver.js:90384:28)
    at IOSession.Session.executeCommand (tsserver.js:90393:33)
    at IOSession.Session.onMessage (tsserver.js:90413:35)
    at Interface.<anonymous> (tsserver.js:91614:27)
    at emitOne (events.js:96:13)
    at Interface.emit (events.js:191:7)
    at Interface._onLine (readline.js:241:10)
    at Interface._normalWrite (readline.js:384:12)
    at Socket.ondata (readline.js:101:10)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)

looks related to https://github.com/Microsoft/TypeScript/issues/20785

This issue reproduced in the following context:
TypeScript Version Prefix: 2.7.2
VSCode Version 1.20.1
command requested: quickinfo
hitting sessions: 113
proportion of all sessions: 0.00231989981317621
stack
Error: Could not find file
    at getValidSourceFile (tsserver.js:82897:23)
    at Object.getQuickInfoAtPosition (tsserver.js:83049:30)
    at IOSession.Session.getQuickInfoWorker (tsserver.js:89979:62)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (tsserver.js:89132:61)
    at unknown (tsserver.js:90553:88)
    at IOSession.Session.executeWithRequestId (tsserver.js:90544:28)
    at IOSession.Session.executeCommand (tsserver.js:90553:33)
    at IOSession.Session.onMessage (tsserver.js:90573:35)
    at Interface.<anonymous> (tsserver.js:91774:27)
    at emitOne (events.js:96:13)
    at Interface.emit (events.js:191:7)
    at Interface._onLine (readline.js:241:10)
    at Interface._normalWrite (readline.js:384:12)
    at Socket.ondata (readline.js:101:10)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)

Duplicate of #20785
@aozgaa These (this and #20786 and #21795) are all the same error, with the only difference being that they started with a different services call (which all immediately call getValidSourceFile) -- could we disambiguate these automatically?


Is add-network-policy is there using cf-mgmt

Is cf "add-network-policy" there using cf-mgmt , if not in feature will it be implemented?

There isn't currently support for this but can add it to the backlog and investigate what it would take to implement this.

@spkrsna  Looking at the documentation this appears to be better suited to be part of an applications ci/cd pipeline as it requires information about the application source/target to be configured.  Similiar to how cf create-service is generally included in the app ci/cd pipelines.
https://cli.cloudfoundry.org/en-US/cf/add-network-policy.html
Currently cf-mgmt stops at the configuration of orgs/spaces/users/quotas to prepare a cloud foundry instance to be able to push an app, create a service and/or configure those c2c network policies.
That being said... Interested in how you envisioned this working in cf-mgmt with the dependency on apps as I may be missing some context.

Hi and thank you for opening the issue. Thank you to Caleb for your perspective on it.
I'd like to close the issue but feel free to re-open it if you have more ideas or thoughts you'd like to share or feel strongly cfmgmt is the best place to address your use case.


Architecture proposal

Hi,
I'm following and working on ETC blockchain. And I think that we could improve a lot this explorer.
My proposal starts changing MongoDB for LevelDB (Thanks @elaineo for the advise)
We've some options to implement LevelDB.
The first, keeping JS as backend language we should use https://github.com/Level/levelup.
The second option B4F (Backend for frontend) - Backend with LevelDB (has changes in the architecture.):

B4F with Nextjs to get server side render and the better features from React.
Backend with RPC to expose all data and connect with the B4F.

What do you think? I would like to hear your opinion and starting to work ASAFP.

I think LevelDB will be fairly easy to port. Let's go for it.
I'm not sure I understand the second option. Are you proposing to switch to React? Is there documentation for B4F?

@elaineo thanks for your answer. I propose to use NextJS (https://github.com/zeit/next.js/), it will be a backend just to server the frontend.
And keep isolated the front end and the backend of the explorer, both will communicate through RPC calls.

Okay. I think isolating the frontend and backend is a good idea. I have no problem with using NextJS to replace the current backend, but it sounds like it will be a fairly big project.

@elaineo may be, I could do my best work to keep it small. I'll start to work and keeping you updated about the progress.


Energy/Power API support

Created on behalf of @rwijbenga:
Implement Energy/Power API integration for HC3 => Home Assistant

Super!
Keep up the great work.

@rwijbenga
Just to keep you updated - I’ve implemented Energy API support at my local development environment
I’ll be doing extra testing testing next weekend, and then publish changes along with few other improvements at once

Exciting news!
I think this is going to be a very good plugin for many new users.... :)

Implemented both Energy and Power monitoring for Fibaro HC3 devices marked with interfaces "energy" (as kWh) and "power" (as W)

@rwijbenga new Energy/Power API works well for me. Feel free to check it out on your end, and let me know if all is good or any issues to be fixed

Great work again!
Did a small test, and it works.. Only small thing....
They changed a device class:
https://developers.home-assistant.io/blog/2021/08/16/state_class_total/
So I changed "measurement" to "total_increasing" in your script to resolve the error message.
https://community.home-assistant.io/t/how-can-i-add-total-increasing-to-my-template-sensor/334961/14
So a simple change for you to do in your build.... ;)
Now testing some devices over a longer period, to be sure.

Right... Home Assistant team keeps adjusting the specification. This is fine, because it is an evolutionary process that makes platform a better/cleaner place to work with.

it appears that "last_reset" property needs attention too, based on the docs from you + logs from my Home Assistant "2021-09-06 01:11:50 WARNING (MainThread) [homeassistant.components.sensor] Entity sensor.svet_gostinaia (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) with state_class measurement has set last_reset. Setting last_reset is deprecated and will be unsupported from Home Assistant Core 2021.11. Please update your configuration if state_class is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A"integration%3A+mqtt""

I'll apply the changes this weekend. And I also plan to check Home Assistant logs for warning messages more frequently :)

I’ve implemented the changes to total_increasing and last_reset properties. Doing local testing and then vomit changes during weekend


fix: 'Oh snap' error when creating VPC from Linode Create

Description 📝
When the Linode Create v2 feature flag is not checked, trying to create a VPC from Linode Create results in the page crashing

Changes  🔄

Update value field in VPC panel's autocomplete to ensure 'undefined' is never the value

Target release date 🗓
8/14 - trying to get it into this upcoming release, as the bug it fixes is still unreleased!
Preview 📷
How to test 🧪
Reproduction steps

Make sure Linode Create v2 flag is not checked
Try creating a VPC from the Linode Create page

Verification steps

Verify that creating a VPC from the Linode Create page does not crash the page when Linode Create v2 flag isn't checked
Double check that when Linode Create v2 flag is checked, everything still works as expected

As an Author I have considered 🤔
Check all that apply

[x] 👀 Doing a self review
[ ] ❔ Our contribution guidelines
[ ] 🤏 Splitting feature into small PRs
[ ] ➕ Adding a changeset
[ ] 🧪 Providing/Improving test coverage
[ ] 🔐 Removing all sensitive information from the code and PR description
[ ] 🚩 Using a feature flag to protect the release
[ ] 👣 Providing comprehensive reproduction steps
[ ] 📑 Providing or updating our documentation
[ ] 🕛 Scheduling a pair reviewing session
[ ] 📱 Providing mobile support
[ ] ♿  Providing accessibility support

Commit message and pull request title format standards

Note: Remove this section before opening the pull request
Make sure your PR title and commit message on squash and merge are as shown below

<commit type>: [JIRA-ticket-number] - <description>
Commit Types:

feat: New feature for the user (not a part of the code, or ci, ...).
fix: Bugfix for the user (not a fix to build something, ...).
change: Modifying an existing visual UI instance. Such as a component or a feature.
refactor: Restructuring existing code without changing its external behavior or visual UI. Typically to improve readability, maintainability, and performance.
test: New tests or changes to existing tests. Does not change the production code.
upcoming: A new feature that is in progress, not visible to users yet, and usually behind a feature flag.

Example: feat: [M3-1234] - Allow user to view their login history

I see a few regressions still that we'll want to address

We should probably add disableClearable
We should probably remove the clearIcon prop
We can probably remove isOptionEqualToValue

I'm thinking we can delete the defaultValue prop  in favor of this for the value:
            value={
              selectedVPCId && selectedVPCId !== -1
                ? vpcDropdownOptions.find(
                    (option) => option.value === selectedVPCId
                  )
                : vpcDropdownOptions[0]

Linode Create v2 handled the "empty" state better by using a placeholder instead of a "None" option, but I think these steps will get Linode Create v1 back to what is use to be

👀 oh sweet thanks Banks! There does seem to be a slight change in initial behavior with the panel inside the Edit Config dialogue with those changes - the first VPC option gets selected instead of a default no option selected. Maybe this is fine though, since a person editing their Linode's configs to include a VPC wouldn't leave the VPC as 'none' anyway?
local (also going to look into the styling change)

prod

Maybe this is fine though, since a person editing their Linode's configs to include a VPC wouldn't not select a VPC anyway?

Looks like we do need to keep the default value for the Linode config, otherwise we run into the strange case where it seems we've selected a VPC, but can't select subnets for that VPC

I probably missing a few things but here were my thoughts on what I just pushed up:

adding disableClearable prevented me from using null, which it seems we need for the Edit Config portion - using undefined led to controlled vs not controlled errors (?)
essentially moved the value of defaultValue to be inside the value prop - so that initial values inside Edit Config and Linode Create should both now match prod, hopefully
removed clearIcon and isOptionEqualToValue props
there's a weird flicker when creating a VPC in the autocomplete compared to prod - I'm not too sure how to get rid of it tbh
style regression still not fixed 😢

I think my takeaway from this is that Linode Create v2 sounds really great 😅

adding disableClearable prevented me from using null, which it seems we need for the Edit Config portion - using undefined led to controlled vs not controlled errors (?)

This field was a point of trouble in the original PR too. Linking for context in case you hadn't read.

oh man, thanks for pointing that out @mjac0bs! I'm gonna add back in the clearIcon prop then + recheck everything


[maven] fix warnings

Some warnings appear in IntelliJ for the parent project:
The following variables are unknown. We should probably set them as properties. Note that every sub plugin or any user can overload those properties when running maven:

${project.parent.build.directory} (if #45 is merged)
${java.permGenSpace}
${forbidden.signatures}
${forbidden.test.signatures}
${scmBranch}
${validate.skip}
${validate.patternsFound}
${skipTests}
${plugin_classpath}
${runtime_classpath}
${test_classpath}

Also, it sounds like this plugin can not be found:
                <dependency>
                    <!--  must be on the classpath  -->
                    <groupId>org.jacoco</groupId>
                    <artifactId>org.jacoco.agent</artifactId>
                    <classifier>runtime</classifier>
                    <scope>test</scope>
                </dependency>

Also, it sounds like this plugin can not be found:

There is nothing wrong with jacoco, its both declared in dependencyManagement, and works (if i do a jacoco profiling build of say kuromoji: mvn -Dtests.coverage=true test jacoco:report, then it produces target/site/jacoco with coverage report).

Yeah. Just that IntelliJ adds a warning on this part. Might be an issue in IntelliJ?


Fix README.md

npm can't run custom scripts without run command

This was a typo. Thank you very much

No problem. Thank you for good example.


Allow up to two newlines before trailing clause body comments

Summary
This is the peer to https://github.com/astral-sh/ruff/pull/7557, but for "leading" clause comments, like:
if True:
    pass

# comment
else:
    pass

In this case, we again want to allow up to two newlines at the top level.
Test Plan
cargo test
No changes.
Before:

project
similarity index
total files
changed files

cpython
0.76083
1789
1631

django
0.99983
2760
36

transformers
0.99963
2587
323

twine
1.00000
33
0

typeshed
0.99979
3496
22

warehouse
0.99967
648
15

zulip
0.99972
1437
21

After:

project
similarity index
total files
changed files

cpython
0.76083
1789
1631

django
0.99983
2760
36

transformers
0.99963
2587
323

twine
1.00000
33
0

typeshed
0.99979
3496
22

warehouse
0.99967
648
15

zulip
0.99972
1437
21

(Merging, this is minor.)


Array try convert

implements try_convert from #39
on a side note, it might be sensible to replace all the loose to_ary or to_int with the respective try_converts

Oh, cool! I didn't know about try_convert.

@TheGrizzlyDev hey, since I don't have another way of contacting you, I thought I'd mention we now have a Discord server in case you're into that sort of thing: https://discord.gg/hnHp2tdQyn
(Although, discussion on PRs and issues is totally ok and maybe preferable when it's a contained thing.) :hugs:

Oh sweet!


Fix table format

@derrix060 wow you're fast 🚀  after reading README.md I also wanted to create PR with same fixes 😄


Dapr bot docs issue automation does not seem to work

In what area(s)?

/area test-and-release
What version of Dapr?
edge
Expected Behavior
When docs-needed label is applied to PR/issue, a corresponding issue is created in dapr/docs repo.
Actual Behavior
dapr-bot workflow is not triggered on docs-needed label addition and on triggering with comment addition, does not seem to work as expected. Eg: https://github.com/dapr/dapr/actions/runs/4328719813
Steps to Reproduce the Problem

Release Note

RELEASE NOTE:

@shubham1172 Can you take a look at this?

Issue comment took precedence over labeling. Can you please try labeling it again?
From logs -

[handleIssueCommentCreate] command "The" not found, exiting.

Is it fixed now?


Add a column (comments_og) in the mergin/field_data/2023/pscis_2023 file to track changes, allow multiple programmatic updates, and facilitate reproducibility

closely related to https://github.com/NewGraphEnvironment/dff-2022/discussions/154 which has been actioned piece by piece through this project and others
About to add a column (assessment_comments_og) in the mergin/field_data/2023/pscis_2023 file so that everything is ready to go with live edits through QGIS.  To track changes and facilitate reproducibility - from now on we will always make a copy of the assessment_comments column from our fieldform, call it assessment_comments_og and do our programatic and hand edits to the comments in the comments column. that allows us to easily track the original comments without needed to sluth through diffs to find it.
This is most important for iterative programatic updates (ex. update the MoTi structure IDs more than once, concatenate comments from climate change columns, add the time in separate steps )

looks like the assessment_comments_og column is already there!  this is great.
I am going to implement a different workflow on this one to explore incorporating all the climate change comments into the data that goes to PSCIS - I will back the existing assessment_comments column to assessment_comments2 and rebuild  assessment_comments.  It will require a lot of trimming of the assessment_comments in QGIS but will be a good exercise in reviewing all available info and working towards leveraging/sharing as much of our work as possible to openly accessible datasets.

ok.  plan is as follows.  Will likely change in the future but here is a go for now:

reverted assessment_comments to version without any appended info.  keep changes made by Mateo in Q that were not tracked though.
add columns for additional moti structure IDs - some times there are 2 or 3.  There are clues to if they are the right ones in the sizes and lengths in the 2 (thats right 2) MoTi Culverts layer and MoTi major structures layer.  Be aware that MoTi datasets are reaaalllly bad and very often quite inaccurate....
Add citation and priority ranging columns
rearrange the columns so we have all the comments, notes and moti stuff, priority, etc at the start.
Burn back to gpkg and track changes with data/backup/* version controlled files in repo

This was done with 01b_pscis_tidy.R
Going forward we:

In QGIS update all assessment_comments and *_notes to be as succinct as possible and remove redundancy in text when possible.  First place to remove the redundancy is the assessment_comments b/c the *_notes columns will stand on their own in the reporting.  Major major issues (culvert is collapsing in the middle, inlet completely blocked, mega erosion happening, etc) should make it into (or be left in the assessment_comments) because in our reporting we will have separate tables (as before) to present the assessment_comments info and each of the climate change *_notes columns (otherwise the table rows are half a page long.... :()

make columns for citation keys.  If a report or website is reaaaly juicy it is ok to put a link to it in the actual assessment_comments too.  Watch out for special characters though (&^^^%$%^$#@#@! they bite)

we have a column for ranking priority for follow up (no fix, low, medium, high). *Once we have updated the assessment_comments (this process) - the justification for this ranking should be clear (ex. large system with good flow, known chinook rearing area, ongoing initiatives by nechako environment and water stewardship society, etc.)

Through this process we update https://github.com/NewGraphEnvironment/fish_passage_fraser_2023_reporting/issues/23 and for large systems that look decent we search Ecocat (search stream name, look at FISS stream sample sites links) to scope for relevant information.  We don't care too much about excel files with fish submissions since we have access to most of that info anyway (FISS layers in Q) but we want to find the reports that are meaningful as far as giving a sense of community related to the system, high value fisheries hints (sockeye spawning trib or known chinook rearing), potential collaborators, past/ongoing restoration/research initiatives, land owner partners and other collaborators that we can tie in with)


Example how to add XML documentation as part of codegen

Steps to reproduce:
to ApiControllerWithContext.cshtml
add
/// <summary>
/// Initializes a new instance of the <see cref="@(Model.ControllerName)"/> class.
/// </summary>
/// <param name="context">Database context to use.</param>
public<EMAIL_ADDRESS>context)
{
    _context = context;
}

so the created constructor would be documented.
Expected behavior:
a) Something more meaningful
b) maybe some example in the codebase how desired behavior could be obtained.
Actual behavior:

Additional information about the project being scaffolded, such as:
Target framework(s):
Package version of Microsoft.AspNetCore.App or Microsoft.AspNetCore.All (if applicable):
2.1.5
Package version of Microsoft.VisualStudio.Web.CodeGeneration.Design - this may be added to your project by scaffolding:
2.1.1

This issue was moved to aspnet/Razor#2664


Synchronize with https://github.com/leereilly/games

At least import from them and they also export. However, I'm not sure why they are restricting themselves to projects on Github. The limitation seems artificial.

I'm on it. There are ~400 entries in this list (with minor discrepancies of the format) and about 250 of them I cannot find in the OSGL. Will chip away at the difference.


CC and BCC button

Hi,
is there a Button in v5.114 to show the CC and the BCC fields when writing an email? If no, please reimplement it as in the 5.0xx series.

Press the 'down' arrow next to the "To" field.
Next time please use the mailing list for support requests.

Hey,
yesterday I found the 'down' arrow...
When you have the dark theme an black arrow on black ground is a little bit hard to see...

This is already fixed, the arrow has isn't adjusted to the dark theme in the current release. Will be released soon :)


Update references to rcbops-extras

Update references from https://github.com/rcbops/rcbops-extras to https://github.com/rcbops/rpc-openstack.
Fixes-Bug: #473

:+1: LGTM and thanks

:+1:


CIDVT-1053: added sign out link + unit tests

the view change is not tested - we should look into adding a test for the layout


[feat]: Switches with icons

Feature description
Add support for icons on switches.
Affected component/components
Switch
Additional Context
Example: https://nextui.org/docs/components/switch#with-icons
https://github.com/shadcn-ui/ui/assets/89687635/09df410c-b9c0-4bed-9401-c276eea81d9c
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues and PRs

@alvinsjoy that's really a good idea!
May I try this?

@alvinsjoy that's really a good idea! May I try this?

Sure. Maybe ask the team before creating a PR

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.


Explanation of the cast() function provided by the implement macro

When implementing an interface with the implement macro, it provides a cast() function that has following documentation:
    #[doc = r" Try casting as the provided interface"]
    #[doc = r""]
    #[doc = r" # Safety"]
    #[doc = r""]
    #[doc = r" This function can only be safely called if `self` has been heap allocated and pinned using"]
    #[doc = r" the mechanisms provided by `implement` macro."]
    unsafe fn cast<I: ::windows::core::ComInterface>(&self) -> ::windows::core::Result<I> {
        // ...
    }

I want to know how can I safely use this function, and what pinning mechanisms are being provided by the implement macro? If just Box<ClassImplementation> would suffice?
Thanks!

So the cast() method is unusable on a ClassImplementation instance? But isn't so limiting? Doesn't this imply whenever I need to give a reference I would need to create a new instance and into(self) it to an interface?
As an afterthought, if I create an instance only once and into() it to an interface like(IClassFactory) and store it, when I need to give a reference, I call the cast(&self) method of the stored interface and give it, would that increment the internal reference count and would suffice?