Implement trailing-comma rule

fixes #557

The common reason for this is diffs and blame in SCM tools and that is only valid for multiline which is why I created the rule to only care about that. Shout if you prefer an option.
Used enforce instead of always because that is what used in the readme to describe other rules. Can change that too of course.

Thanks for the PR @Pajn! I left a few high-level comments/change suggestions for you

This new rule breaks an invariant in tslint.json where no config can be contradictory. With this addition, a user can enable no-trailing-comma and trailing-comma at the same time, which isn't great. Before this PR is accepted we'll need to resolve the contradiction there -- we should probably consolidate into a single trailing-comma rule? Thoughts @gscshoyru / @ashwinr?

I could merge the rules but it would be a breaking change to remove the no-trailing-comma rule.
I'm thinking about how to handle the options if I did.
Personally I would like to specify "always for newline, never for oneline". Would this set of options be okay "always", "never", "always-newline", "always-newline-never-oneline" or do we need even more options? Could split into "always-newline", "always-oneline", "never-newline" and "never-oneline" where the used would set one newline option and one oneline option. Could also extend with just "always" and "never" for people that want a consequent behaviour.

I think the rules should be merged into a single trailing-comma rule, but as @Pajn mentioned, that's a breaking change so we'd have to delay it until the next major release.
As far as options, I like actually like the four-option proposal, "always-newline", "always-oneline", "never-newline" and "never-oneline".

Will take a look at array literals, they doesn't seem to be supported by the walker so I fixed the other comments first.
I used an object for options, just as typedefWhitespace as it felt cleaner and allows any combination. Is that ok?

Added support for array literals and destructing. Also took the freedom to add named imports as those are pretty much the same as object destructing.
Tell me if I should squash the commits

In PR #726 you mention bumping to 3.0 this week. If possible it would be nice to get this into that as well as this is breaking too. So if you have time to review the updated version I would be happy :)

@Pajn We'll be having breaking changes that relate to TSLint 3.0 for a little while, so this will definitely make it into 3.0

Nice :) Will try to be more speedy if there are other things to fix as well.

Also, can you add an example usage to docs/sample.tslint.json

looks pretty good overall; I like the rule configuration. just need some small fixes and a rebase on the latest master to get this in.

You can find the corresponding docs here: https://palantir.github.io/tslint/rules/trailing-comma/


Assist proposal: generate a as_variant() method for enum

Inspired by this assist https://github.com/rust-analyzer/rust-analyzer/pull/7562 I would like add an assist to generate method as_variant_name() a pattern I often use to quickly extract a variant from an enum.
Example:
enum Number {
    I64(i64),
    F64(f64),
}

output:
enum Number {
    I64(i64),
    F64(f64),
}

impl Number {
    pub fn as_i64(&self) -> Option<&i64> {
        // ....
    }
}

If you think it could be useful for developers let me know I would be happy to implement this.

Sounds like a good addition to me as it is closely related to the is_ version, and pretty useful to have in general in my opinion. Reminds me that I still wish there was a matches! like macro in std that does exactly this 😄 Could probably live in the same module as well?

Sounds like a good addition to me as it is closely related to the is_ version, and pretty useful to have in general in my opinion. Reminds me that I still wish there was a matches! like macro in std that does exactly this smile Could probably live in the same module as well?

This is discussed here: https://github.com/rust-lang/rfcs/issues/2960


inplace warning ahead of pandas 3.0

I'm seeing this (a lot) with my new caveclient install.
/Users/jefferis/Library/r-miniconda-arm64/envs/r-reticulate/lib/python3.10/site-packages/caveclient/materializationengine.py:1085: FutureWarning: A value is trying to be set on a copy of a DataFrame or Series through chained assignment using an inplace method.
The behavior will change in pandas 3.0. This inplace method will never work because the intermediate object on which we are setting values always behaves as a copy.

For example, when doing 'df[col].method(value, inplace=True)', try using 'df.method({col: value}, inplace=True)' or df[col] = df[col].method(value) instead, to perform the operation inplace on the original object.

https://github.com/CAVEconnectome/CAVEclient/blame/863eeb21879729c8ebc5e4c64ce742e6906733e4/caveclient/materializationengine.py#L1085
pandas is at version 2.2.2 and this is a summary of the rest of my Python env.
Python
----
python:         /Users/jefferis/Library/r-miniconda-arm64/envs/r-reticulate/bin/python
libpython:      /Users/jefferis/Library/r-miniconda-arm64/envs/r-reticulate/lib/libpython3.10.dylib
pythonhome:     /Users/jefferis/Library/r-miniconda-arm64/envs/r-reticulate:/Users/jefferis/Library/r-miniconda-arm64/envs/r-reticulate
version:        3.10.14 | packaged by conda-forge | (main, Mar 20 2024, 12:51:49) [Clang 16.0.6 ]
numpy:          /Users/jefferis/Library/r-miniconda-arm64/envs/r-reticulate/lib/python3.10/site-packages/numpy
numpy_version:  1.26.4

NOTE: Python version was forced by use_python() function

          package version         requirement channel installed  core
1    cloud-volume  8.33.0 cloud-volume=8.33.0    pypi      TRUE  TRUE
2      caveclient  5.21.0   caveclient=5.21.0    pypi      TRUE  TRUE
3    seatable-api   2.8.0  seatable-api=2.8.0    pypi      TRUE  TRUE
4         pyarrow  16.1.0      pyarrow=16.1.0    pypi      TRUE FALSE
5         fafbseg   3.0.8       fafbseg=3.0.8    pypi      TRUE FALSE
6         DracoPy    <NA>                <NA>    <NA>     FALSE FALSE
7       meshparty    <NA>                <NA>    <NA>     FALSE FALSE
8        skeletor   1.3.0      skeletor=1.3.0    pypi      TRUE FALSE
9        pykdtree    <NA>                <NA>    <NA>     FALSE FALSE
10       pyembree    <NA>                <NA>    <NA>     FALSE FALSE
11 pychunkedgraph    <NA>                <NA>    <NA>     FALSE FALSE
12        igneous    <NA>                <NA>    <NA>     FALSE FALSE
13      fastremap  1.14.1    fastremap=1.14.1    pypi      TRUE FALSE
14      ncollpyde  0.19.0    ncollpyde=0.19.0    pypi      TRUE FALSE

Python example:
>>> import caveclient
>>> import pandas as pd
>>> import datetime
>>> datastack_name = "flywire_fafb_public"
>>> client = caveclient.CAVEclient(datastack_name)
>>> postsyn_df = client.materialize.live_query("synapses_nt_v1", filter_in_dict={"post_pt_root_id": [720575940617343316]}, timestamp=datetime.datetime.now())
/Users/jefferis/Library/r-miniconda-arm64/envs/r-reticulate/lib/python3.10/site-packages/caveclient/materializationengine.py:1085: ChainedAssignmentError: A value is trying to be set on a copy of a DataFrame or Series through chained assignment using an inplace method.
When using the Copy-on-Write mode, such inplace method never works to update the original DataFrame or Series, because the intermediate object on which we are setting values always behaves as a copy.

For example, when doing 'df[col].method(value, inplace=True)', try using 'df.method({col: value}, inplace=True)' instead, to perform the operation inplace on the original object.

  df[root_id_col].replace(future_map, inplace=True)

R example
library(fafbseg)
flywire_partner_summary('720575940617343316', method = 'cave')

thanks for this greg.. on our radar now.  we should proactively pin pandas<3.0 for now till we get this warning taking care of.

Thanks @fcollman! I'm getting this with 2.2.2 so I think the pin would have to be a bit more aggressive than <3.0 and might cause trouble elsewhere. I guess the warnings are designed to be annoying enough to make people bite the bullet and fix!

this is just a warning though right at 2.2.2 ?

I've pinned it below 3.0 for now

It's just a warning at 2.2.2 but it's a very noisy one!

fixed in ed0b1aecf3a2083be1b8bc6a97bd9c97ab42b4ee (in addition to the pin)


fix readme file by replacing *.routes.ts with *-routing.module.ts and…

Dear all,
this PR related to https://github.com/mgechev/angular-seed/issues/2050
fixed readme file by replacing *.routes.ts with *-routing.module.ts and remove unexists index.ts

LGTM, thanks for the PR!


Config Question

Hi Tamion, thanks for creating DiscordConnector!
This step #2 isn't clear to me. I updated the bot token and guild ID in papermc/plugins/DiscordConnector-main/src/main/resources/plugin.yml.
Do I also need to edit papermc/permissions.yml?

Required Setup
Start the server and set bot token and guild ID by using commands for which you will need the permissions DiscordConnector.token and DiscordConnector.id or directly editing the config

Hey John.
No the permissions DiscordConnector.token and DiscordConnector.id are needed to use the commands /setbottoken and /setguildid. I just realized i am not acutally mentioning these commands in the documentation. Thanks for making me aware of this issue.
I hope i was able to clear up any confusion

I will update the documentation when i have the time to do so


Loading environment variables

Currently Create React App supports environment variables however it leaves some of it to the user's imagination:

Note: Defining environment variables in this manner is temporary for the life of the shell session. Setting permanent environment variables is outside the scope of these docs.

I went on to find my own solution using node-forman but still thought it was sub-optimal*. Is the CRA-team open to leverage dotenv and integrate this in react-scripts (for development)?
Happy to open a PR but wanted to discuss upfront if 👍 or 👎
--
* I didn't really like wrapping all scripts in a shell script that loads the env variables

A PR sounds good to me, a specific proposal would be easier to discuss.
Thanks!

Opened #695 with a working solution

Fixed in #695, available in 0.5.0.

0.5.0 has been released with this feature.


Correct permission of the OA4MP storage directory

When the OA4MP embedded issuer is enabled, it will use the following directory for its storage:
/opt/scitokens-server/var/storage

Verify that this (a) exists, (b) is writable and (b) owned by tomcat prior to launching OA4MP.  When creating an empty PVC in Kubernetes, this may start life owned as root -- we should correct this to avoid having to do complex init containers.

More precisely:

Before starting the OA4MP issuer daemon, check the permissions of /opt/scitokens-server/var/storage.
If it exists, make sure it's 0700 and owned by user tomcat / group tomcat.
If it doesn't exist, create the directory tree.  Default the mode of created directories to 0755.  Change the ownership of the top directory to tomcat / group tomcat.


Features/multi version

This is a work in progress.

This change is

Review status: 0 of 13 files reviewed at latest revision, 1 unresolved discussion.

BuildTasks/PublishExtension/vsixeditor.ts, line 93 at r1 (raw file):

ew Promise((resolve, reject) => {

Quoted 4 lines of code…
>                     let tmpPath: string;
>                     temp.mkdir("vsixeditor", (ex, dirPath) => { tmpPath = dirPath; });
>                     resolve(tmpPath);
>                 })

This seems to not work as I thought it would be. Help wanted.

Comments from Reviewable

where are the tests?!?!

Review status: 0 of 13 files reviewed at latest revision, 6 unresolved discussions.

BuildTasks/Common/Common.ts, line 195 at r2 (raw file):

 * @param  {(tfx:ToolRunner)=>void} cmd
 */
export async function runTfx(cmd: (tfx: ToolRunner) => void) {

async without await?

BuildTasks/Common/Common.ts, line 405 at r2 (raw file):

}

async function getTasksManifestPaths(manifestFile?: string): Promise<string[]> {

very long

BuildTasks/Common/Common.ts, line 428 at r2 (raw file):

        tl.debug(`Found extension manifest: ${manifest}`);
        const tasks = await getTaskPathContributions(manifest);
        for (let t = 0; t < tasks.length; t++) {

tasks.forEach(_ => {})

BuildTasks/Common/Common.ts, line 433 at r2 (raw file):

            const taskRoot: string = path.join(rootFolder, task);
            const rootManifest: string = path.join(taskRoot, "task.json");
            if (fs.existsSync(rootManifest)) {

sync = smell, async/await

BuildTasks/Common/Common.ts, line 516 at r2 (raw file):

        // If extension version specified, let's search for build tasks
        if (extensionVersion) {
            // Extract version parts Major, Minor, Patch

Extract to method instead of comment

Comments from Reviewable

Yeah... Fun, eh :). And retroactively putting them in is a nightmare.

Review status: 0 of 13 files reviewed at latest revision, 6 unresolved discussions.

BuildTasks/Common/Common.ts, line 195 at r2 (raw file):
Previously, riezebosch (Manuel Riezebosch) wrote…
async without await?

I believe the PublishPackage.ts fails as long as that's out, as it's actually calling all kinds of async stuff through a delegate,

BuildTasks/Common/Common.ts, line 428 at r2 (raw file):
Previously, riezebosch (Manuel Riezebosch) wrote…
tasks.forEach(_ => {})

Tried that. Doesn't work because loaded Node packages cause arrays to return custom properties and iterating through the array using foreach and others return bogus items.

BuildTasks/Common/Common.ts, line 433 at r2 (raw file):
Previously, riezebosch (Manuel Riezebosch) wrote…
sync = smell, async/await

It's a bloody build task, everything runs sequentially anyway and the agent is never actually running multiple tasks in parallel

Comments from Reviewable

Review status: 0 of 13 files reviewed at latest revision, 6 unresolved discussions.

BuildTasks/Common/Common.ts, line 195 at r2 (raw file):
Previously, jessehouwing (Jesse Houwing) wrote…
I believe the PublishPackage.ts fails as long as that's out, as it's actually calling all kinds of async stuff through a delegate,

Shouldn't you be awaiting the cmd then? The PublishExtension is quite hard to read. Doing lots of stuff in a single method.

BuildTasks/Common/Common.ts, line 433 at r2 (raw file):
Previously, jessehouwing (Jesse Houwing) wrote…
It's a bloody build task, everything runs sequentially anyway and the agent is never actually running multiple tasks in parallel

Sure thing, but it is the TypeScript/NodeJS approach.

Comments from Reviewable


Add ability to pass arguments to command links

The {[notation]} in addition to supporting an alias, should also support passing arguments somehow. Open to ideas on syntax.

As I have a vision for a concrete usecase, and was about to open a new issue, I'm happy I found this.
I'd like to build a site-index, where I can quickly glance over pages and possibly delete them.
Therefore I would build an query und use a template that includes the Page: Delete command, but delegate that to the page from the query.
My suggestion was to go for: {[CMD]:[ARGS]} ... which would then be {[Page: Delete]:[{{name}}]}

Rather than inventing new syntax, why not lean on javascript syntax?
The native template literal syntax is perfect, IMO.
${cmd(arg1, arg2)}
Maybe this is only intuitive to a javascript programmer but I think this is cleaner than having a bunch of nested square and curly braces.
So ${page.delete(name)}

@20after4 currently the syntax for creating a command link is {[Name of the command]} or when aliased: {[Name of the command|my alias}] how would you suggest these look with a JS-style syntax? Command names are not JS identifiers right now (they're the same names you see in the command palette).

Implemented


Position gets wrongly re-calculated after scroll and onLayout (using SafeAreaView)

Current behaviour
Say we have two top-level screens, Screen A with SafeAreaView > TabView inside, and Screen B with whatever else. If you go to Screen A, then swipe to go to another tab, then go to Screen B, and then back to Screen A, position will be wrong. It will either be -1 or will be pointing to another element being selected.
Expected behaviour
position should always reflect currently selected index.
Code sample
import { createSwitchNavigator } from 'react-navigation'

const MainNavigator = createSwitchNavigator({
  screenA: { screen: ScreenA },
  screenB: { screen: ScreenB }
})

const ScreenA = () => (
  <SafeAreaView>
    <TabView {...whateverProps} />
  </SafeAreaView>
)

const ScreenB = () => <Text>Whatever</Text>

Screenshots (if applicable)

What have you tried
I have found the issue to be in the handleLayout function, in TabView. If values of offset/panX get updated via handleScroll, and handleLayout gets called afterwards, it messes up the rendering...
handleLayout is being called on focusing back to TabView because it is wrapped into SafeAreaView.
Your Environment

software
version

ios or android
ios

react-native
0.55.3

react-native-tab-view
^1.2.0

node
v8.10.0

npm or yarn
yarn

@satya164 hey, can you please check it out? I can assist if something's missing

Please provide a runnable example.

@satya164 updated the original description

Hey, I just released a new alpha 2.0.0-alpha.0 of the library. It's rewritten using react-native-gesture-handler and react-native-reanimated addresses a many platform specific bugs and performance problems. The documentation is updated as well.
Please try the new version and see if it addresses your issue. If not, please open a new issue following the issue template.


Function page: Missing empty messages on function charts when no activity occurred yet

Environment info

Version: 2.11.0-65f4306
Deployment: **AZURE **
Customer: NAME

Actual behavior

When a function has no connected triggers yet (no activity) the charts has a flat line

Expected behavior

Show empty message "No Data to Display"

Steps to reproduce

Go to an unused function > see charts

Screenshots or Logs or other output that would be helpful

As we are not investing in the UI console, closing


Display of boolean image attributes (no action needed)

When image attributes are boolean, they are displayed as strings:

This makes sense, since attributes have a generic scalar type.

I'm just documenting this behavior - we can re-visit later.

Working on this is probably not worth the possible edge cases or additional complexity. Closing, for the moment.


Mention winapi

I think it's absolutely lovely that people at Microsoft are stepping up and making these official bindings!
However, I do have a minor gripe: I find it sad that the winapi crate, which has served the Rust community faithfully for many years until this came along, isn't mentioned anywhere. I get that most projects should rather want to use this one, but winapi has at least one thing that this crate doesn't: An MSRV of 1.6.
Also, I'd be nice with an "upgrade guide" or similar, which mentions some major differences and pitfalls when migrating from winapi.

As I mentioned here, we have plans to provide more documentation in future. Help with migrating code is on the list for consideration.
Regarding MSRV, the windows crate is a much newer library that takes advantage of many of the advances to the Rust language since 1.6 was released in 2016! 😉 Basic things like C-style unions weren't even available back then.
Having said that, we can probably keep track of the min supported version with some basic validation in the CI build. I would expect it to be different between the windows and windows-sys crates as the latter has far fewer dependencies on newer features like const functions.

Yeah, I don't expect windows to work on such old Rust versions, but (depending on what windows/windows-sys's MSRV end up being) winapi may be more or less useful for people whose setup requires that.
Thanks for the kind answer!

The spirit of this issue wasn't about MSRV at all, but the historical note about the winapi crate, could this issue be reopened until that is addressed? (even if it might take a while, it's still good to track it)
On a more personal note, it's really disorientating to come across something that doesn't mention prior art, and with the amount of information we're exposed to, it's easy to start questioning remembered history that's not explicitly mentioned (before looking it up and reassuring oneself that no Mandela effect has occurred).
As a positive example I saw recently, the new(er) unicode-ident crate's README mentions not one but four existing implementations (in order to position itself as the more performant alternative).
It's immediately clear that it's meant to supersede the old popular choice in the ecosystem.


Fix CSP so that the policy can be enforced and not just report only

The CSP policy currently used is not correct.
https://github.com/IBM/taxinomitis/blob/3d32953f4f6b630d5aa81617ae9b9c4c5a593bb5/src/lib/restapi/config.ts#L43-L90
This was brought to light after a recent version update of the helmet module. To avoid breakages, the CSP was switched to report-only as a temporary workaround.
https://github.com/IBM/taxinomitis/blob/3d32953f4f6b630d5aa81617ae9b9c4c5a593bb5/src/lib/restapi/index.ts#L41-L45
The CSP needs to be fixed so that the enforcement can be re-enabled.

https://github.com/IBM/taxinomitis/blob/e665e30bb19615a6ac006b5333b35d6edb3ee840/src/lib/restapi/config.ts#L52-L54

https://github.com/IBM/taxinomitis/blob/e665e30bb19615a6ac006b5333b35d6edb3ee840/src/lib/restapi/config.ts#L59-L62

Some of the errors that these are hiding are from angular - see https://docs.angularjs.org/api/ng/directive/ngCsp for details


Don't leak backup password to ps

https://www.openssl.org/docs/man1.1.1/man1/openssl.html
pass:password
    The actual password is password. Since the password is visible to utilities (like 'ps' under
    Unix) this form should only be used where security is not important.

Another issue was that secure temporary files were created, but never used or deleted.
$file = tempnam(sys_get_temp_dir(), 'php-encrypt');

The files actually used were just created insecurely by writing to a known file after the creation of the previously mentioned $file.
file_put_contents("{$file}.dec", $data);

I really like that the current encrypted config.xml can be decrypted with just OpenSSL without OPNsense, but there's one relatively big caveat. It's not protected against accidental or malicious corruption. AES in GCM mode would prevent that. I made a tiny wrapper as an example what a new "aes-256-gcm" mode could look like. It wouldn't even need any openssl invocation outside of PHP since it uses the native openssl_encrypt.
So the question is, do you think that the integrity checking would be worth the trouble of updating the scheme?

@oittaa I still need to test this locally, but the code looks good.

I really like that the current encrypted config.xml can be decrypted with just OpenSSL without OPNsense, but there's one relatively big caveat. It's not protected against accidental or malicious corruption. AES in GCM mode would prevent that. I made a tiny wrapper as an example what a new "aes-256-gcm" mode could look like. It wouldn't even need any openssl invocation outside of PHP since it uses the native openssl_encrypt.
So the question is, do you think that the integrity checking would be worth the trouble of updating the scheme?

The problem might be backwards compatibility, which has the risk of adding more logic and the need to keep both approaches for a very long time. We can always discuss in PR, these are just my main concerns.

@oittaa I seems like I was a bit too optimistic  here and had to revert the commit as it seems to hang the backup on my end. Maybe we best keep the exec() and only go for your idea to flush the password in between execution? It's easier to test and less likely to regress on other peoples installs.

Have you tested https://github.com/opnsense/core/pull/5665?
That one doesn't need any openssl shell invocation or temporary files at all.

https://soatok.blog/2020/07/12/comparison-of-symmetric-encryption-methods/#aes-gcm-vs-aes-cbc
TLDR:

AES-GCM vs. AES-CBC
Just use AES-GCM. No contest.
If you must use AES-CBC, then you must also MAC your ciphertext (and the initialization vector–IV for short).

@AdSchellevis I don't have older MD5 based configuration file backups, but at least the "aes-256-cbc sha512" ones work perfectly fine with that newer pull request.

Have you tested https://github.com/opnsense/core/pull/5665?

I haven't, but at the moment I don't have enough time available to review it in full either. Let's keep the PR open for a while and see if other people chime in for some additional testing and feedback. I'll try to fix the password leak in the current code later today.


Apply-PnPProvisioningTemplate - Random (500) Internal Server Error while running the script

Category
[X] Bug
Environment
[X] SharePoint 2019
Expected or Desired Behavior
Template is applied without errors (or at least with detailed errors)
Observed Behavior
We are getting the 'The remote server returned an error: (500) Internal Server Error' intermittently while running the script  Apply-PnPProvisioningTemplate. The script works at times and other times it doesn't. See the trace log below:
PowerShell_ISE.exe Error: 0 : 2019-11-27 08:54:39.5022	[OfficeDevPnP.Core]	[0]	[Error]	ExecuteQuery threw following exception: System.Net.WebException: The remote server
returned an error: (500) Internal Server Error.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute()
   at Microsoft.SharePoint.Client.ClientRequest.ExecuteQueryToServer(ChunkStringBuilder sb)
   at Microsoft.SharePoint.Client.ClientContext.ExecuteQuery()
   at Microsoft.SharePoint.Client.ClientContextExtensions.ExecuteQueryImplementation(ClientRuntimeContext clientContext, Int32 retryCount, Int32 delay, String userAgent).
	0ms
PowerShell_ISE.exe Error: 0 : 2019-11-27 08:54:39.5282	[OfficeDevPnP.Core]	[0]	[Error]	ExecuteQuery threw following exception: System.Net.WebException: The remote server
returned an error: (500) Internal Server Error.
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute()
   at Microsoft.SharePoint.Client.ClientRequest.ExecuteQueryToServer(ChunkStringBuilder sb)
   at Microsoft.SharePoint.Client.ClientContext.ExecuteQuery()
   at Microsoft.SharePoint.Client.ClientContextExtensions.ExecuteQueryImplementation(ClientRuntimeContext clientContext, Int32 retryCount, Int32 delay, String userAgent).
	0ms
Apply-PnPProvisioningTemplate : The remote server returned an error: (500) Internal Server Error.
At line:9 char:1
Apply-PnPProvisioningTemplate -Path ' ...
    + CategoryInfo          : WriteError: (:) [Apply-PnPProvisioningTemplate], WebException
    + FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.Provisioning.Site.ApplyProvisioningTemplate

Steps to Reproduce
Run the following script:
Apply-PnPProvisioningTemplate -Path "C:\temp\template.xml" -Verbose

Duplicate for #4924, so closing this one. Issue is at the underlying oob API surface and it's being worked on.


SILGen/IRGen: Lower protocol witness thunks for ObjC lightweight generics as pseudogeneric.

Fixes rdar://problem/28873860, where we would miscompile when lightweight generic classes were extended to conform to Swift protocols because we tried to emit parameters for the class's generic parameters for the witness entry points. Prevent this by lowering the witness into a pseudogeneric function in SILGen, and teaching IRGen to do the right thing for a witness with pseudogeneric parameters.

@swift-ci Please smoke test and merge

@rjmccall Does this fix look reasonable for 3.0?

(Forgot REQUIRES: objc_interop for Linux. I'll fix that.)

@swift-ci Please smoke test and merge

@swift-ci Please smoke test and merge

Yeah, looks okay to me.


Extend support for AMA agent in the workbook.

Many customers are previewing defender for cloud using AMA in the private preview
Could you please extend the support for AMA as well for this workbook?
We have AMAs deployed side by side, but the workbook is identifying only the workspace where the MMA is sending heartbeat to.

Hi @mmkmur are you referring to Microsoft Defender for Servers monitoring dashboard ?

Thanks for getting back .
Yes, exactly.  Here, I see the workspace being reported is on the basis of where the MMA is pointing to.
In my case, we have both agents side by side and AMA is tasked to collect the SecurityEvents and is pointing to a 'X' workspace. But since the existing machines have MMA by default the workbook reports as if these machines are reporting to 'Y' workspace. I would like to know how I can modify the resource graph query to include the 'AMA'  workspace status.
Not sure if I was able to articulate the question well.  Thanks

From: ShaykeAmar @.>
Sent: Sunday, December 19, 2021 1:49 PM
To: Azure/Microsoft-Defender-for-Cloud @.>
Cc: MKrish @.>; Mention @.>
Subject: Re: [Azure/Microsoft-Defender-for-Cloud] Extend support for AMA agent in the workbook. (Issue #502)
Hi @mmkmurhttps://github.com/mmkmur are you referring to Microsoft Defender for Servers monitoring dashboardhttps://github.com/Azure/Microsoft-Defender-for-Cloud/tree/main/Workbooks/Defender for Servers Monitoring ?
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/Microsoft-Defender-for-Cloud/issues/502#issuecomment-997348775, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUBO5EPZPQ7YWN7QQYH23VTURWIR5ANCNFSM5KKYO3EQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>

Thanks for the clarification @mmkmur, adding @TomJanetscheck for awareness.

Thanks @ShaykeAmar for adding me.
Hi @mmkmur,
The workbook has been created to provide awareness of (mis)configuration within the scope of Defender for Cloud. Since Defender for Cloud leverages the Log Analytics agent only, not the AMA, AMA connection information is not part of the workbook.
For Defender for Servers and Defender for SQL on machines to work correctly, it's mandatory to enable these plans on both, the subscription and the Log Analytics workspace the LA agent on a machine is connected to.


Navigating fzf.vim broken since tnoremap update

The latest commit broke the ability to use ctrl-j and ctl-k to navigate up and down in a list in fzf.vim when using Neovim.  I know that a cross-plugin compatibility issue is not really your problem, but it would be great to have this feature restored.  For the time being, I had to pin my vim-plug dependency to the previous commit to keep things working the way I'm used to.
Since detecting when fzf.vim is open, it might be nice to just add a configuration option that can be turned off to prevent the terminal remaps from being set.

Yeah, sorry.
We should probably revert this altogether, and not add these mappings for terminal windows (which fzf uses).

I'm still seeing this issue on the latest commit. Is there some workaround to have it ignore J/K if you have the :Files pane open from FZF?

@adamyonk
Cannot reproduce: <c-j>/<c-k> is used by FZF for me (both Neovim and Vim).
I think you would have to open a new issue and provide more information.

I think fzf.vim also supports using <c-p>/<c-n> to navigate up/down, which is a same shortcut as navigating through shell history in a shell. The p(revious) and n(ext) is easier to remember than  k, j when navigating in a list (Still hjkl is definitely the best choice for left/up/down/right when moving the cursor in the editor). So I prefer <c-p>/<c-n> in this situation.
So if most people can accept using <c-p>/<c-n>, then we can add these mappings back for terminal windows.
Or how about this? Add a switch to let the user enable these mappings if they want to navigate when using terminal in nvim.


Some niconico videos not downloading in highest available quality

Checklist

[x] I'm reporting a broken site support
[x] I've verified that I'm running youtube-dl version 2019.05.20
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar issues including closed ones

Verbose log

youtube-dl -o "~/Desktop/%(id)s - %(title)s.%(ext)s" 'https://www.nicovideo.jp/watch/sm34678585' --retries 9001 --fragment-retries 9001 --verbose
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-o', '~/Desktop/%(id)s - %(title)s.%(ext)s', 'https://www.nicovideo.jp/watch/sm34678585', '--retries', '9001', '--fragment-retries', '9001', '--verbose']
[debug] Encodings: locale cp932, fs mbcs, out cp932, pref cp932
[debug] youtube-dl version 2019.05.20
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.17134
[debug] exe versions: ffmpeg 4.1.3, ffprobe 4.1.3
[debug] Proxy map: {}
[niconico] sm34678585: Downloading webpage
[niconico] sm34678585: Downloading JSON metadata for h264_720p-aac_192kbps
[niconico] sm34678585: Downloading JSON metadata for h264_480p-aac_192kbps
[niconico] sm34678585: Downloading JSON metadata for h264_360p-aac_192kbps
[niconico] sm34678585: Downloading JSON metadata for h264_360p_low-aac_192kbps
[niconico] sm34678585: Downloading JSON metadata for h264_720p-aac_64kbps
[niconico] sm34678585: Downloading JSON metadata for h264_480p-aac_64kbps
[niconico] sm34678585: Downloading JSON metadata for h264_360p-aac_64kbps
[niconico] sm34678585: Downloading JSON metadata for h264_360p_low-aac_64kbps
[debug] Default format spec: bestvideo+bestaudio/best
[debug] Invoking downloader on 'https://pc112b9c3bd.dmc.nico/vod/ht2_nicovideo/nicovideo-sm34678585_6882847d6ad743f3113079089fa18d4750099d0c146d953a999114794b6d504c?ht2_nicovideo=6-NXZdRnPIoU_1559783357163.ww6wdu_psnkjl_1ho39grxvxb8m'
[download] Destination: C:\Users\redacted\Desktop\sm34678585 - Secret Pure Love.mp4
[download] 100% of 7.15MiB in 01:24

Description

The video is available on the site in 720p, but is only downloading in 360p. Other examples of this issue include sm35166438 and sm35180267.

I've personally just got same result with my own channel on youtube, all videos came in 360p, although 720p is available


source code not inlined in sourcemap files

With the following directory structure:
Source:
./src
    └ main
         └ webapp
                └ src
                    ├ file1.ts
                    └ file2.ts

when I execute the following 'test' task:
gulp.task('test', function() {
  gulp.src('src/main/webapp/**/*.ts')
    .pipe(sourcemaps.init())
    .pipe(ts({sourceRoot: ''}))
    .pipe(sourcemaps.write('.'))
    .pipe(gulp.dest('build/webapp/main/'));
});

the directory structure is recreated correctly in the destination folder:
Destination:
./build
      └ webapp
             └ main
                  └ src
                      ├ file1.js
                      ├ file1.js.map
                      ├ file2.js
                      └ file2.js.map

however the .map files are incorrect. With:
.pipe(ts({sourceRoot: ''}))

I get no source code inlined in the map and an invalid 'sourceRoot':
{
  version: 3,
  sources: ["file1.ts"],
  names: [...],
  mappings: "...",
  file: "src/file1.js",
  sourceRoot: "/source/",
  sourcesContent: [null]
}

with:
.pipe(ts())

I get no source code inlined in the map and 'sourceRoot' set to my project root:
{
  version: 3,
  sources: ["file1.ts"],
  names: [...],
  mappings: "...",
  file: "src/file1.js",
  sourceRoot: "C:/Dev/prj/foo/",
  sourcesContent: [null]
}

with:
.pipe(ts({sourceRoot: 'src/'}))

sort of works. The source code is inlined and 'sourceRoot' is correct. However 'sources' relative path is still missing and, since 'sourceRoot' cannot be changed dynamically for every directory, it'll only work for the first '/src' directory level.
{
  version: 3,
  sources: ["file1.ts"],
  names: [...],
  mappings: "...",
  file: "src/file1.js",
  sourceRoot: "src/",
  sourcesContent: ['file1.ts' source code]
}

in my opinion the final sourcemap file should be as follow (with 'sourceRoot' not present since it's not needed because the source code is inlined):
{
  version: 3,
  sources: ["src/file1.ts"],
  names: [...],
  mappings: "...",
  file: "src/file1.js",
  sourcesContent: ['file1.ts' source code]
}

And finally when I execute the 'test' task with concat and uglify:
gulp.task('test', function() {
  gulp.src('src/main/webapp/**/*.ts')
    .pipe(sourcemaps.init())
    .pipe(ts({sourceRoot: 'src/'}))
    .pipe(concat('src/bundle.min.js'))
    .pipe(uglify())
    .pipe(sourcemaps.write('.'))
    .pipe(gulp.dest('build/webapp/main/'));
});

'src/bundle.min.js' is properly generated, its name is added to the sourcemap list of sources, but not its source code, resulting in a 'ghost' file in chrome javascript console:
{
  version: 3,
  sources: ["src/file1.ts", "src/file2.ts", "src/bundle.min.js"],
  names: [...],
  mappings: "...",
  file: "src/bundle.min.js",
  sourcesContent: ['file1.ts', 'file2.ts' but not 'bundle.min.js']
}

Looks to be related to #52, so this should be fixed now too.


Fix markdown + PHP fenced code blocks

previously PHP wasn't working at all because we don't appear to properly support grammar injections. This issue was addressed by pointing to a specific repository key (#languages)
ensure "fuzzy" syntax highlighting for PHP/HTML code so that script start tags are not required

forked from #16006, related to #14166
close #3746

Hi @mousetraps, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Sara Itani). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


fix circle style for rtl

Fix the circle style for rtl, this PR fixes #23

Thank you !

omg that was quick 😂


Update App & Array

This PR needs a last syntax check before merging

This PR needs a last syntax check before merging

All good


Some type extensions cannot set the buffer language

Check for existing issues

[X] Completed

Describe the bug / provide steps to reproduce it
Of course I know it does #207,but some type files cannot display the language type and thus cannot be set .

Environment
Zed: v0.77.3 (stable)
OS: macOS 13.2.1
Memory: 32 GiB
Architecture: aarch64
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.
If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.
No response

Oh, I found that there are relevant commands to implement the relevant function

I wonder can display unknown,Click to select
The choice of whether an buffer language type can be persisted in the Settings,
Set whether it can be project-dependent and let the Settings follow the project


Number Method issue

comma in input, works with 3 digits after comma.

The screenshot shows the number method working correctly. "123,456" is valid because the number method allows comma separators in addition to decimals. Can you please clarify how the expected behavior diverged from the actual behavior?

Look correctly, but

I was planning to enter a number 123.456, but enter 123,456. I am a regular inexperienced user, what is my mistake? :)

I think the expected behavior would be to show a warning message about the ambiguous meaning.


Transpose argument of draw_texture_rect or draw_texture_rect_region does not work anymore

Godot version:
Master branch
OS/device including version:
Linux, vulkan
Issue description:
Setting transpose to true as an argument of draw_texture_rect_region does not work, the texture is not rendered as transposed (the texture should be rendered as mirrored by its diagonal axis).
It is needed to render rotated textures (and thus, tiles). Related issue: https://github.com/godotengine/godot/issues/31149
Steps to reproduce:
Simply try to draw a texture with draw_texture_rect or draw_texture_rect_region.
Minimal reproduction project:
Ask if needed. :)

It looks to me like the issue is here:
https://github.com/godotengine/godot/blob/e44a2f16805b09a9a858ba5e8ebec7e598feb4d8/servers/rendering/renderer_rd/renderer_canvas_render_rd.cpp#L530-L532
While flipping the destination rect might have worked on GLES3, it doesn't seem to do anything at all for Vulkan. I have tried flipping the dest rect in all possible combinations and could see precisely zero difference to the on-screen output.
I am well out of my depth dealing with APIs this low-level though, so I don't know what the "correct" way to transpose the render for Vulkan is.

OK, think I have it figured it out, will put up a PR on my lunch break.


More advanced GridField state management

Description
The current GridField state management implementation is a bit lacking when dealing with multiple GridFields, especially with the new nested GridField component. It tries to handle GridField states by appending all GridField states as different request variables, and the code that does this is scattered in a few different places.
Our implementation of GridField state management is a GridFieldStateManager class that handles GridField states for all GridFields, not just the current one. The GridFieldStateManager implementation feels like a natural place to handle this, and it should preferably be the only place that handles it.
The way our GridFieldStateManager does this is to store modified GridField states in session, and to append a single request parameter, via the addStateToURL-method, which is already used by all GridFieldStateAware components. This single request parameter simply contains a key, by which the stored GridField states are found from session. In this way it can handle GridField states via session differently per browser tab/window.
With this implementation one could also in the future have different implementations of GridFieldStateManager which store the states somewhere else than session.
The implementation does require some changes to core except the GridFieldStateManager implementation, for example the addAllStateToUrl-method in GridField becomes much simpler.
Additional context or points of discussion
One point to consider here is if the GridFieldStateManager interface needs some new methods. It doesn't currently have any notion of when the GridFieldStateManager implementation should actually store a given GridField state. This means our implementation currently tries to figure this out when some GridFieldStateAware component calls the addStateToURL method, which isn't ideal. It then has to try to figure out if the state has actually changed from the default, and for performance reasons it only checks this once, even if the state might actually be changed later in the request.
Ideally we could add a storeState method to the interface, which could actually be called from the GridState class whenever some of the state data changes (after all GridField_StateProvider components initDefaultState methods have been called).
Validations

[X] You intend to implement the feature yourself
[X] You have read the contributing guide
[X] You strongly believe this feature should be in core, rather than being its own community module
[X] You have checked for existing issues or pull requests related to this feature (and didn't find any)

Just a couple questions to make sure I understand what is happening.

Since this is tied to the user session, I take it that those URL are ephemeral? In other words, if you logout those states are gone. This would preclude the ability to bookmark a GridField URL with a specific search term or to send that link to another user.
In your proposed solution, when a request alters the GridState, GridFieldStateManager will create a unique key to track that new state. However, multiple GridField component could try to update the GridState within one request. That's why you want a GridFieldStateManager::storeState() method so you can update the state multiple times within one request without creating new keys.
If someone manually recreates a state identical to a previous state in the user's session, I take the solution will still create a brand state key to add the URL?

None of those are deal breakers in my mind. We can maybe talk about those at our next catch up.

Other random questions. Have we considered storing the GridState elsewhere than the user session? e.g. Some sort of shared cache server side or in the DB.
I'm not suggesting we do this. Just pondering the "ifs".
Security wise, since the GridState is stored in a user's session, I take it there's no risk of one user gaining access to another user's GridState data? Even if there was, would we even care?

@maxime-rainville

Since this is tied to the user session, I take it that those URL are ephemeral? In other words, if you logout those states are gone. This would preclude the ability to bookmark a GridField URL with a specific search term or to send that link to another user.

You are correct, in our proposed solution those URLs are dependent on the user session. With that implementation you cannot send a link to a specific filtered GridField state to another user no.
If your session expires, then yes the state will also be gone. I see no real solution to this when using session-based storing of the states, but in practice we haven't found this a problem. If a user needs to log in again, they do not in our experience expect all the state to be preserved.

In your proposed solution, when a request alters the GridState, GridFieldStateManager will create a unique key to track that new state. However, multiple GridField component could try to update the GridState within one request. That's why you want a GridFieldStateManager::storeState() method so you can update the state multiple times within one request without creating new keys.

You got this correct, that is precicely why I propose the storeState method to be added to the interface.

If someone manually recreates a state identical to a previous state in the user's session, I take the solution will still create a brand state key to add the URL?

Yes, if the request doesn't yet contain any state key, then a new one will be created and it is always random and not tied to any given state. If the request already contains a state key, then that key will be used.

Have we considered storing the GridState elsewhere than the user session? e.g. Some sort of shared cache server side or in the DB.

We have considered this internally, and we have actually thought about using some in-memory cache for this, for example Redis. With the proposed solution, one could easily just implement another GridFieldStateManager class for this.

Security wise, since the GridState is stored in a user's session, I take it there's no risk of one user gaining access to another user's GridState data? Even if there was, would we even care?

Storing the state in session should security-wise be safe. Since the default authentication handling is session-based anyway, it is no less secure than that.

Is there a way we could do this without breaking change so people could start using this in CMS 5?

If we just add the storeState method to the GridFieldStateManagerInterface, then that is a breaking change if someone has done their own implementation of GridFieldStateManager. I don't know how common it actually is to do this, I haven't seen any public modules that do it. However, if we really want the change to be non-breaking, we could split that storeState functionality out into another interface, so that implementing it is optional for the GridFieldStateManager implementation. In that way I see no real breaking change other than states now not being preserved when the session expires.

Would it be possible to combine state from the URL and the local? So that the URL can contain an initial state that can be shared with the URL and then local stored state would override that, similar to how e.g. option objects can be merged.

Would it be possible to combine state from the URL and the local? So that the URL can contain an initial state that can be shared with the URL and then local stored state would override that, similar to how e.g. option objects can be merged.

One problem here is what states are included in the URL? Including all states for all GridFields in the URL is part of the original problem here. The states quickly get quite big as json-encoded text, and including for example all nested GridField states in the URL quickly becomes problematic. I have toyed with the idea to use just one request parameter for all GridField states, and encoding all the json-encoded states in some way to keep the total parameter size smaller. However, for example just base64 encoding them doesn't really help. you still end up with a very long parameter size.

How many gridfields do you have on a page or in a form? In the URL only the state for the viewed ones would be needed, so we wouldn't need to include a state for all of them. Alternatively there could be a separate request to the backend to fetch the state by the gridfield identifier if the backend wanted to provide one. There we could mix predefined state with local state as well. That wouldn't work if the local state id was randomised, but is it really needed to be randomised?

Its not really about how many GridFields are on a specific page or form, but how many are present in the whole path that took the user to the current edit form. The main problem to solve here is for the user to always end up with the same GridField state when going back one or more steps from the current view. Going back either via browser history, the back-button in the CMS or via breadcrumbs should all behave the same way, and the amount of GridFields that are affected might actually be quite many, especially with nested GridFields with GridFieldDetailForm components.

We've decided to retarget this to CMS 5 following a meteing with @forsdahl.
We'll have a follow up card to clean up a few rough edges in CMS 6: https://github.com/silverstripe/silverstripe-framework/issues/11267
We'll also create a follow up card implement behat test.


Updates to readme

Proposes:

additional text on module tag
adding example of using Promise.all for multiple module import (https://github.com/systemjs/systemjs/issues/498#issuecomment-110807515)
shuffling a few other bits about for a more logical sequence (IMHO)

Question: why is https://github.com/systemjs/systemjs/blob/master/docs/es6-modules-overview.md in systemjs? This surely belongs here.

Thanks, note that because this repo provides no production workflow, it is not suitable for end-users and is more appropriate for implementors at this point. So the documentation is moving to reflecting that as well somewhat, hence why the basic ES6 module info was removed.

if you're moving general usage docs to systemjs, it might be better to have the note on Promise.all in there (somewhere)

In general, it is advisable to have a single main entry point over multiple import promises, so it's not something I'd want to encourage too heavily.

Thanks again for the suggestions - it's great to have this documentation feedback.

I'm using it for optional loads: parse querystring into an array and load the requested components with Promise.all. I don't think it makes sense in a static situation.


ENH: Add some neuroscience links

Some links I think might be generally useful enough for other folks

Added a little GitHub workflow test, too

I pushed 1a39efd to my main and it seems to work:
https://github.com/larsoner/intersphinx_registry/actions/runs/8940381695/job/24558390655
============================= test session starts ==============================
platform linux -- Python 3.[12](https://github.com/larsoner/intersphinx_registry/actions/runs/8940381695/job/24558390655#step:5:13).3, pytest-8.2.0, pluggy-1.5.0
rootdir: /home/runner/work/intersphinx_registry/intersphinx_registry
configfile: pyproject.toml
plugins: xdist-3.6.1
created: 4/4 workers
4 workers [283 items]
........................................................................ [ 25%]
........................................................................ [ 50%]
........................................................................ [ 76%]
...................................................................      [100%]
============================= 283 passed in 11.51s =============================

... and improved the error message on a bad input because I got:
Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/home/circleci/python_env/lib/python3.10/site-packages/sphinx/config.py", line 509, in eval_config_file
    exec(code, namespace)  # NoQA: S102
  File "/home/circleci/project/doc/conf.py", line 177, in <module>
    get_intersphinx_mapping(
  File "/home/circleci/python_env/lib/python3.10/site-packages/intersphinx_registry/__init__.py", line 39, in get_intersphinx_mapping
    assert len(set(only) - set(mapping.keys())) == 0
AssertionError

which is less useful than having the missing keys printed.


Add solution to ex5

name = Le Huu Thong,
score = 3,
accuracy = 2mHa,
parameters = 16.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Sorry for the delay. Thank you very much for your submission!


about continuous display

Hi@hailanyi , thank you for your work.i got problem in viewing a sequence data and pressing "Enter" key did not work. How can i realize continuous display as the gif in Readme.md? looking forward to your reply!

While the code is running, please first click on the 3D window and then press the "Enter" key to view a sequence data.

@hailanyi,  I followed your step, it still didn't work. It seems only the 2d window could display continuous.

I have the same problem . when the first frame is closed,the terminal shows "Process finished with exit code -1073741819 (0xC0000005)"

I have the same problem . when the first frame is closed,the terminal shows "Process finished with exit code -1073741819 (0xC0000005)"

pip3 install vedo -U

@hailanyi @Typolo  Hi, do you know how to save as a gif file? Thanks.

@DuZzzs, you can use ScreenToGif to record the 3D or 2D window.

Thanks

Set the interactive=False to get a continuous display.
self.vi.show( ... interactive=False ... )

Also to interact with continuous display make the settings.allowInteraction True.
from vedo import *
settings.allowInteraction = True

Please use the vedo version in readme:
vedo==2021.0.6
If you can not continuous display after  press 'Enter'  please press 'Q' instead.


Deprecate [RCTConvert UIBarStyle:]

Summary:
The enums UIBarStyleBlackOpaque and UIBarStyleBlackTranslucent have been deprecated since iOS 13, already below React Native's minimum OS of iOS 13.4. Indeed, they are not available on visionOS and tvOS, making this a source of extra diffs.
Rather than deprecate and remove those options, I noticed that we don't actually use that RCTConvert method in the core repo, and haven't since 0.58-stable (presumably before the lean core effort). Let's just remove it, it's a conversion that should be easy enough to replicate elsewhere. However, removal is a breaking change, so let's deprecate it for one release (0.74) and remove it for the next one (0.75). For posterity, tracking deprecation with https://github.com/microsoft/react-native-macos/issues/2008 and removal with https://github.com/microsoft/react-native-macos/issues/2009 .
Changelog:
[IOS] [DEPRECATED] - Deprecate [RCTConvert UIBarStyle:]
Test Plan:
CI should pass

@okwasniewski FYI


Implement tap to scroll to item in CupertinoPicker

Finishes the work started by @Kavantix in #110733.
Fixes https://github.com/flutter/flutter/issues/24089.
Before:
https://github.com/user-attachments/assets/7ca0d346-7538-44a0-b0b2-41cf96eee6eb
After:
https://github.com/user-attachments/assets/8da91188-28a0-4738-a216-e03946f00284
Native picker:
https://github.com/user-attachments/assets/8662b3c0-0443-4f8d-818b-cabd97d37de8
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] I followed the breaking change policy and added Data Driven Fixes where supported.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

From looking at the golden files, it looks like it's ending at a different place. I'm concerned about the picker wheels feeling not as responsive. Have we considered using DragStartBehavior.down? Or does that provide some clunkiness with the gestures?

Sounds good. Can I attach this to this PR, or make a separate PR for that?


[FEATURE]435i internal Gyro Usage

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
The Realsense 435i has an internal IMU / accell + gyro. Although the phone's gyro AVR system may work ok, it would be nice to take full advantage of this functionality as sometimes your phone can be slightly skewed from the sensor mount throwing off data accuracy. Though I admit most of the 4xx cameras do not have this ability, so this is likely a low priority feature for such an early in development app.
Describe alternatives you've considered
Currently through AVR the phone does get position data.
Additional context
Add any other context or screenshots about the feature request here.

Hi @Calsa512 ,
You're right - we need such a feature. Unfortunately librealsense still not supporting internal IMU for Android (IntelRealSense/librealsense#4384)... So we need to wait when they will prepare it.
From our side - hopefully by the end of the week we will introduce the ARCore positioning in v0.5.0 (#14) and this will help with rough positioning of the camera to simplify the future PCL pointclouds registration (#13).

Looks like the guys from realsense added IMU support for version 2.26.0 (at least the logic I added to remove IMU init on adnroid was changed: https://github.com/IntelRealSense/librealsense/commit/f0141ceed#diff-76788c4833e724cad4a926d3a6e6de14L851 ).
Need to check on practice - but right now the main blocker for using version > 2.20.0 is IntelRealSense/librealsense#4215 - bulk transfer is not working well.


Custom test check (post test script)

Use cases:

Run user provided script on guest when test fails (other result, always) to gather logs/configuration (e.g. sosreport) necessary to investigate the failure. Output of the script and produced artifacts has to be pulled to the host for later investigation by user.
Run user provided script on guest as a 'test check' which might change the test result

Such script has to have access to the 'test result', the exit code is not enough (beakerlib tests exit always with 0; previous test check might mark the test as a failure already, ...).
To some extend this can be done already by login -t -c BINARY -w fail however this doesn't store BINARY output nor can change the test result.

Note for developers: a refactoring of code handling (check) results is necessary, plus one extra fetch of data from the guest. Today, the code runs before-test checks, test, and after-test checks, then pulls data from the guest. To allow framework extract results, we need before-test checks, run test, pull, collect results, run after-test checks, and pull once again to fetch their possible artifacts. I think I had something similar in my git stash, I'll try to find it and publish a draft PR. No shell check in my stash yet, though, although watchdog PR prototypes check keys - dmesg or avc did not require any, but shell will need at least script.

The reshuffling of the result gathering I mentioned above is in https://github.com/teemtee/tmt/pull/2608/.


Combine slash-command-dispatch and conda-lock-command workflows

Consolidate the slash-command-dispatch and conda-lock-command workflows into a single GitHub Action workflow, aided by the conda-lock-refresh GitHub Action at https://github.com/weiji14/conda-lock-refresh/releases/tag/v0.1.0
References:

https://github.com/weiji14/conda-lock-refresh/tree/v0.1.0#usage
https://github.com/weiji14/conda-lock-refresh-demo/blob/0f280e78657578326ba74d9f13861235661fb2d9/.github/workflows/conda-lock.yml
https://github.com/pangeo-data/pangeo-docker-images/issues/414

Closes #18, Supersedes #5

@yuvipanda or @scottyhq, appreciate it if either of you take a look at this PR and give it a review. The PR should be keeping the same functionality of the /condalock command as before, and is mostly just consolidating the slash-command-dispatch.yml and conda-lock-command.yml GitHub Action workflows into one workflow.
If not, I can also just merge this in first and sort out any problems later :slightly_smiling_face:

This is neat @weiji14 I like creating a new action step. I think being able to run against forks is desirable for public projects. As far as I know the way to this is either to use a personal token or trigger the action from a label (which only repo admins can do & therefore the workflow can run with access to full secrets permissions) see https://github.com/uwhackweek/jupyterbook-template/blob/main/.github/workflows/netlifypreview.yaml

This is neat @weiji14 I like creating a new action step. I think being able to run against forks is desirable for public projects. As far as I know the way to this is either to use a personal token or trigger the action from a label (which only repo admins can do & therefore the workflow can run with access to full secrets permissions) see https://github.com/uwhackweek/jupyterbook-template/blob/main/.github/workflows/netlifypreview.yaml

Agree that we want this to work for public forks too. I'm gonna see if there's a workaround for the permissions part, from https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#changing-the-permissions-in-a-forked-repository, it says:

You can use the permissions key to add and remove read permissions for forked repositories, but typically you can't grant write access. The exception to this behavior is where an admin user has selected the Send write tokens to workflows from pull requests option in the GitHub Actions settings. For more information, see "Managing GitHub Actions settings for a repository."

But that Send write tokens to workflows from pull requests option is only available for private repos :sweat_smile: There's another potential way which is to use the workflow_run event as mentioned at https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks, but that would require going back to two GitHub Actions YAML files (which might not be too bad if it doesn't require a PAT).
Let me have a think about what the best approach might be from all the options above. For this PR, I might end up sticking with tibdex/github-app-token to continue allowing forked repos to work with /condalock, and experiment with a non-PAT approach later in a follow-up PR.

Let me have a think about what the best approach might be from all the options above. For this PR, I might end up sticking with tibdex/github-app-token to continue allowing forked repos to work with /condalock, and experiment with a non-PAT approach later in a follow-up PR.

Ok, using the GitHub App generated token again after 304627706b4c7709ed49d6ba7b206e856864666e and 0c3a0ef5238ad593a8a60949b627c38e29238423.


[Essay] three-presentation-of-vue-render

https://liamrad.netlify.app/essays/detail

测试

apple
banana
watermelon


Add additional custom Range

Solves issue #98
This is small but it lets people set their max range to 40 yards.  Since 10.1 there have been some issues (I'm not sure if its from this addon or just from the game) with the out of range distance being set to the incorrect value.

Interesting, thanks for the PR. Is there a strong reason why you set the default custom range to 40 from 30? It doesn't 'really' matter, it was just interesting that that was part of your changes.

I couldn't tell if it would be on by default, and I was worried if that was then for most classes the range indicators would be shorter than normal.
I can revert that if you want, it probably didn't need to get changed.

Oh it's just the value that is set the first time someone toggles on that option. Unless the option is toggled on this value doesn't do anything. Which is why I said it doesn't 'really' matter if it's different, but in the grand scheme of things I do prefer 30 over 40 for the default, since the game default is already 40 (or supposed to be anyway).

I've updated it to return the default to 30.


Docs are not available (404)

Describe the bug
Pandas profiling documentation isn't available.
To Reproduce
Open https://pandas-profiling.github.io/pandas-profiling/docs/master/rtd/

It seems be changed to
https://ydataai.github.io/pandas-profiling/docs/master/rtd/


fix: trigger release

:tada: This PR is included in version 1.0.0-beta.12 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Support for etcd v3

It appears etcd v3 is not yet supported:
# confd -onetime -backend etcd -node=http://<IP_ADDRESS>:2379
2017-06-23T16:11:17Z be2621c9ebce confd[27]: INFO Backend set to etcd
2017-06-23T16:11:17Z be2621c9ebce confd[27]: INFO Starting confd
2017-06-23T16:11:17Z be2621c9ebce confd[27]: INFO Backend nodes set to http://<IP_ADDRESS>:2379
2017-06-23T16:11:20Z be2621c9ebce confd[27]: ERROR client: etcd cluster is unavailable or misconfigured
2017-06-23T16:11:20Z be2621c9ebce confd[27]: FATAL client: etcd cluster is unavailable or misconfigured

Any plan to add support for the new gRPC api?

This appears to have been addressed by pull request #468...  Just waiting on @kelseyhightower  to merge...  Gonna see if the @bacongobbler 0.12.1 branch works in the meantime...

Duplicate of #544

So, how to use etcd client v3

see https://github.com/kelseyhightower/confd/pull/468.


[virt-controller]: Refactor renderLaunchManifest function

What this PR does / why we need it:
This PR breaks apart some of the logic in renderLaunchManifest into smaller private helper functions. This function is almost 1300 line long and very non-cohesive. This PR reduces it into about 500 lines of code and introduces 5 helper functions to achieve it. Every helper function is cohesive - deals with one task (or renders a different manifest aspect).
This is an initial work that breaks apart some of the logic but not all. Follow-up PR(s) can continue this until we have a clear and clean function.
Release note:

NONE

/test pull-kubevirt-e2e-kind-1.19-sriov

@ashleyschuett Just to be clear - I didn't write the code you commented on but only moved it around into a helper function to break renderLaunchManifest apart. In any case I've addressed them :smile:
Thanks! :+1:

/retest

/cc @davidvossel
just so i remember to review this soon

since you're building helper functions for volumes, i'm curious why some of the volumes are still left in the top level function.

Thanks for catching that David!

Hey @fgimenez @dhiller,
As you can see the same functional tests is failing for all compute lanes (example):
 [sig-compute]Configurations
 tests/vmi_configuration_test.go:66
   VirtualMachineInstance definition
   tests/vmi_configuration_test.go:222
     [rfe_id:140][crit:medium][vendor:cnv-qe@redhat.com][level:component]with hugepages
     tests/vmi_configuration_test.go:1001
       should consume hugepages
       vendor/github.com/onsi/ginkgo/extensions/table/table.go:92
         [Serial][test_id:1672]hugepages-1Gi [It]
         vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:43

         Timed out after 360.001s.
         Timed out waiting for VMI testvmi-clncc to enter [Running] phase(s)
         Expected
             <v1.VirtualMachineInstancePhase>: Pending
         to be an element of
             <[]interface {} | len:1, cap:1>: [["Running"]]

         tests/utils.go:2919

The problem is that I cannot reproduce it locally as when I try to run this locally I get this message:
sig-compute]Configurations
tests/vmi_configuration_test.go:66
  VirtualMachineInstance definition
  tests/vmi_configuration_test.go:222
    [rfe_id:140][crit:medium][vendor:cnv-qe@redhat.com][level:component]with hugepages
    tests/vmi_configuration_test.go:1001
      should consume hugepages
      vendor/github.com/onsi/ginkgo/extensions/table/table.go:92
        [Serial][test_id:1672]hugepages-1Gi [It]
        vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:41

        No node with hugepages hugepages-1Gi capacity

        tests/vmi_configuration_test.go:1077

I've talked with @dhiller about this and we figured that there is no clear way (e.g. though environment variable etc') to set the usage of hugepages-1Gi in the cluster. I've tried to play with things around to enable it without luck.
Can you advise on how to continue?
Thanks!

/test pull-kubevirt-e2e-k8s-1.21-sig-storage

Hey @maiqueb! Thanks for your review.
While I agree with your points I think this PR had lost its original purpose which is to split renderLaunchManifest() into multiple helper functions. Instead, this PR had been reviewed multiple times by multiple people always finding better ways of styling the code which I didn't even write..
IMHO we can't turn this PR into "make this code perfect", especially where I didn't write the code and only tried to move it around in order to keep things cleaner so we can further refactor in the future. Future PRs can and should improve this even further, but IMHO this PR is drifting away from its original task of splitting a huge function into multiple helper ones.

Hey @maiqueb! Thanks for your review.
While I agree with your points I think this PR had lost its original purpose which is to split renderLaunchManifest() into multiple helper functions. Instead, this PR had been reviewed multiple times by multiple people always finding better ways of styling the code which I didn't even write..

I think that's part of the purpose of code review: find better ways of styling the code, enabling the reader to have an easier time understanding it. It could be argued that you should incorporate those suggestions into the code.

IMHO we can't turn this PR into "make this code perfect", especially where I didn't write the code and only tried to move it around in order to keep things cleaner so we can further refactor in the future. Future PRs can and should improve this even further, but IMHO this PR is drifting away from its original task of splitting a huge function into multiple helper ones.

I agree with small iterative improvements, I've even mentioned that in https://github.com/kubevirt/kubevirt/pull/6118#discussion_r737372323.
I don't agree with everything you say; for instance, you're introducing a function that returns 6 variables. That's making the code worse imo, since it is error prone - it's easy to put things in the wrong order. I've said so, and I think it should be changed. Same with adding a couple of consts that - when correctly named - will indicate to the reader what they are , and how they're supposed to be used.
You can still split this "huge" function into smaller ones and not have functions that return 6 variables.
I haven't blocked this PR though. I just voiced my concerns that the intermediate state you're proposing has parts that are confusing and error prone; if other reviewers agree with me, I hope you take these into account.

Hey @maiqueb! Thanks for your review.
While I agree with your points I think this PR had lost its original purpose which is to split renderLaunchManifest() into multiple helper functions. Instead, this PR had been reviewed multiple times by multiple people always finding better ways of styling the code which I didn't even write..

I think that's part of the purpose of code review: find better ways of styling the code, enabling the reader to have an easier time understanding it. It could be argued that you should incorporate those suggestions into the code.

I agree, except this PR is meant to complete a small refactoring task, not to beautify every part of the code that is moving around

IMHO we can't turn this PR into "make this code perfect", especially where I didn't write the code and only tried to move it around in order to keep things cleaner so we can further refactor in the future. Future PRs can and should improve this even further, but IMHO this PR is drifting away from its original task of splitting a huge function into multiple helper ones.

I agree with small iterative improvements, I've even mentioned that in #6118 (comment).

Great

I don't agree with everything you say; for instance, you're introducing a function that returns 6 variables. That's making the code worse imo, since it is error prone - it's easy to put things in the wrong order. I've said so, and I think it should be changed. Same with adding a couple of consts that - when correctly named - will indicate to the reader what they are , and how they're supposed to be used.
You can still split this "huge" function into smaller ones and not have functions that return 6 variables.

Let me disagree. I think that a function of almost 2K lines is probably the hardest code to read and understand, and therefore maintain. The first step IMO is to break the logic apart. This is the small incremental change this PR tries to achieve. In a future work we should take your advice and continue beautifying the rest, but I certainly do not agree that a messy 2K lines function is better than a small function which in one of its lines returns 6 values.

I haven't blocked this PR though. I just voiced my concerns that the intermediate state you're proposing has parts that are confusing and error prone; if other reviewers agree with me, I hope you take these into account.

And thank you for that! All of your points are important and should be addressed in future PRs.

Hey @maiqueb! Thanks for your review.
While I agree with your points I think this PR had lost its original purpose which is to split renderLaunchManifest() into multiple helper functions. Instead, this PR had been reviewed multiple times by multiple people always finding better ways of styling the code which I didn't even write..

I think that's part of the purpose of code review: find better ways of styling the code, enabling the reader to have an easier time understanding it. It could be argued that you should incorporate those suggestions into the code.

I agree, except this PR is meant to complete a small refactoring task, not to beautify every part of the code that is moving around

I don't think my suggestions count as "beautify". It's functional: it helps the reader understand it better. That's important, since code is read a lot more times than it is written.

IMHO we can't turn this PR into "make this code perfect", especially where I didn't write the code and only tried to move it around in order to keep things cleaner so we can further refactor in the future. Future PRs can and should improve this even further, but IMHO this PR is drifting away from its original task of splitting a huge function into multiple helper ones.

I agree with small iterative improvements, I've even mentioned that in #6118 (comment).

Great

I don't agree with everything you say; for instance, you're introducing a function that returns 6 variables. That's making the code worse imo, since it is error prone - it's easy to put things in the wrong order. I've said so, and I think it should be changed. Same with adding a couple of consts that - when correctly named - will indicate to the reader what they are , and how they're supposed to be used.
You can still split this "huge" function into smaller ones and not have functions that return 6 variables.

Let me disagree. I think that a function of almost 2K lines is probably the hardest code to read and understand, and therefore maintain. The first step IMO is to break the logic apart. This is the small incremental change this PR tries to achieve. In a future work we should take your advice and continue beautifying the rest, but I certainly do not agree that a messy 2K lines function is better than a small function which in one of its lines returns 6 values.

Let me clarify: I'm not saying a "messy 2K lines function is better than a small function which in one of its lines returns 6 values". I'm saying that one of the functions that you're proposing has a signature that is error prone, and hard to follow.
As such, I've asked to consider updating it. I also don't buy the argument that "a small function which in one of its lines returns 6 values" ... That single line you mention ends up being the one that specifies the contract between the implementation and the caller of the function.

I haven't blocked this PR though. I just voiced my concerns that the intermediate state you're proposing has parts that are confusing and error prone; if other reviewers agree with me, I hope you take these into account.

And thank you for that! All of your points are important and should be addressed in future PRs.

/test pull-kubevirt-e2e-k8s-1.22-sig-storage

Huge +1 on the last commit of the stack.
I'm just asking for a couple of commits here to be squashed into others, since they're fixes to errors introduced within this very same PR.
Once that's taken care of, you have my lgtm.
Thanks.

Thanks, addressed your feedback :+1:

/retest

/retest

Thanks for your patience.

And thank you very much for your review and great ideas!
I sincerely think your ideas are very important and should be addressed in the future

/retest

/retest

/test pull-kubevirt-e2e-k8s-1.21-sig-storage

/hold
refactors in that area are critical. I think @davidvossel wanted to have a look.

/cc @davidvossel

/hold
refactors in that area are critical. I think @davidvossel wanted to have a look.

/hold
refactors in that area are critical. I think @davidvossel wanted to have a look.

Of course.
@davidvossel In two words this PR splits the function to several helper functions that are more cohesive and focused on a logical rendering sub-task, i.e. no logical changes are expected from this PR, only pure refactoring.
Please let me know what you think of this.

/retest

/retest

While this does break up logic into smaller functions and reduce overall size of the renderLaunchManifest function, I don't think the new structure necessarily makes this function any easier to work in or understand.
Here is what I mean.
Let's take for example volumes. We still have volume information being generated and spread out all throughout this function and nested functions. Except now instead of having a single set of slices to follow at the top of the renderLaunchManifest function, we have multiple objects and object pointers being passed around through layers of nested functions.
The rendering of volumes isn't concise either. For example, we're applying fields from the volumeInfo object to container specs and then modifying the volumeInfo object more later on.

Thanks @davidvossel.
IMHO having a HUGE function that does a lot of unrelated things is the worst code to maintain. I understand that further refactoring is needed here and that the division to sub-function is not perfectly cohesive, but I do think that it makes the situation much better. At least renderLaunchManifest's code is readable and it's pretty much clear where everything is being done.
This is meant to be a first step towards refactoring this function. I think we should perform incremental changes and the first obvious step IMO is to split this function into more or less cohesive helper functions.
Another note: I honestly think it's problematic that as a project such PRs are so difficult to push forward. IMO small incremental PRs to refactor the code should happen on a regular basis. Instead, this PR is out there for months now for what I thought of as a tiny incremental change that will also encourage others to further refactor it.
How do you think we should continue?

I think your direction is a great start. What I'd like to see is that the top level render function only uses volume information rendered by helper functions. So move everything involved with rendering volumes out of the top level function.
It's really tough to untangle all this

Thanks @davidvossel.

I think my primary issue with the refactor is it doesn't completely refactor the rendering of the volumes, instead we're split between some volumes being rendered in the giant top level function and the majority being rendered in helper functions.

So, in other words - this refactoring work is not yet completed and not perfect, we have more work do to. I Agree.

I think your direction is a great start.

So why don't we merge it?

What I'd like to see is that the top level render function only uses volume information rendered by helper functions. So move everything involved with rendering volumes out of the top level function.
It's really tough to untangle all this

If it's really tough, why insist on doing all the work in the same PR?
Usually, small incremental changes are encouraged (rightfully), I honestly don't understand why we take the complete opposite approach when it comes to refactoring. You said this PR is a "great start" - so I assume you agree that it makes things better, not worse - so IMHO we should merge it and then think on how to further improve this.
And again, I think about it from the perspective of how do we want to behave as a community. Let's be honest - refactoring work is not very fun to do, and usually it's not an impressive task for your resume. It's a lot easier to see a 2K lines function and just add to it the stuff you need for that feature you're working on. How do we encourage people to stop what they're doing and say "I'm gonna spend some time on making things better, even it's outside of my task's scope"? If refactoring means to start a very heavy task which will takes months to complete and the expectation is that you do it perfectly or it won't get merged - IMHO it means that de-facto no one will do such work.As a proof we can see that one of our most important functions that are in the heart of are flow hadn't been refactored and just keeps growing and growing...
The main goal of this PR is not to perfectly refactor everything - but to be an initial work that will encourage others and myself to continue the refactoring effort, as PR description says.

/retest

I admit I missed completely this PR, so it was great that it was mentioned during the community meeting. But I'd like to give some good reasons why a refactoring of this function could be very beneficial. We have a couple of situations like WaitForFirstConsumer or the attachment pod for hotplug where we need to create a pod with the same scheduling constraints as the VM. I'm also working on a similar feature where I need this. If we can separate the part of the renderLaunchManifest that influences the scheduling of the VM, those functions could be reused for the creation of these helper pods.

The main goal of this PR is not to perfectly refactor everything - but to be an initial work that will encourage others and myself to continue the refactoring effort, as PR description says.

Taking into account what David said in https://github.com/kubevirt/kubevirt/pull/6118#issuecomment-970721810, I would suggest to take a small domain (like e.g. volume rendering) and try to factor it out. This will likely also involve slight restructuring of other parts of the function and will lead to the next step, by try to keep all other changes at a minimum.
This would still be a (focused) "initial work" which can still encourage others. If you want to do big refactoring at once (also fine in principal), a clear idea and vision with clear benefits of the restructuring is required. If a refactoring does for instance not clearly improve e.g. isolation, and instead introduce more paths to track, then it is probably not worth merging it. Especially when it is a big refactor.

I admit I missed completely this PR, so it was great that it was mentioned during the community meeting. But I'd like to give some good reasons why a refactoring of this function could be very beneficial. We have a couple of situations like WaitForFirstConsumer or the attachment pod for hotplug where we need to create a pod with the same scheduling constraints as the VM. I'm also working on a similar feature where I need this. If we can separate the part of the renderLaunchManifest that influences the scheduling of the VM, those functions could be reused for the creation of these helper pods.

That is right, and you can clearly see that WaitForFirstConsumer was added as a boolean (I did it) flag because there was no easy way to reuse/extend the function. So refactoring will help with tasks like that, and with testing new additions.

I admit I missed completely this PR, so it was great that it was mentioned during the community meeting. But I'd like to give some good reasons why a refactoring of this function could be very beneficial. We have a couple of situations like WaitForFirstConsumer or the attachment pod for hotplug where we need to create a pod with the same scheduling constraints as the VM. I'm also working on a similar feature where I need this. If we can separate the part of the renderLaunchManifest that influences the scheduling of the VM, those functions could be reused for the creation of these helper pods.

That is right, and you can clearly see that WaitForFirstConsumer was added as a boolean (I did it) flag because there was no easy way to reuse/extend the function. So refactoring will help with tasks like that, and with testing new additions.

At least, isolating the volumes (volumeMounts and deviceMounts), node selector and the resources assigned to the pod (like huge pages and host devices) can be very useful.


Add clear warnings for HS256 secret length

https://auth0.com/blog/brute-forcing-hs256-is-possible-the-importance-of-using-strong-keys-to-sign-jwts/

The second key, secret is 48-bit. This is simply too short to be a valid key. In fact, the JSON Web Algorithms RFC 7518 states that a key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with the HS256 algorithm.
I therefore recommend that anyone trying to generate a JSON Web token and signing them with HS256 to use a properly sized secret key. Auth0 secret keys are 512 bits in length and not susceptible to this type of brute force attack.

I see too many examples using secret as a key without any warnings, please consider adding an example how to generate such key.

Hi @lil5 very good point, will take care of it. Also feel free to PR if you want to 😉

If this is not a PR of this projects scope I guess a warning on the readme would be good.
Maybe something like:

:warning: Create a key for HS256 of at least 256 bits!
the RFC7518 standard states that "A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm."
tldr; Create your key for HS256 of 32 bytes long using crypto/random

Will take care to add it to the README this week (now leaving till Friday)

@cristaloleg reminder :wink:

Ouch...

Done and v4 finally released.


Time report is not accurate

Summary
PR https://github.com/pouriyajamshidi/tcping/pull/76 helped tidying up a lot of technical debt surrounding the way we were handling timing and helped standardizing the code.
However, as a by product, for downtimes that are around a second, we are reporting the time as 0 instead of 1. Although it is a cosmetic matter, based on the discussion in the aforementioned PR, we decided to pursue those fixes in a sperate issue.
In the image below, we can see:

No response received for 0 seconds showing 0 but should be 1
The from to to appear to be incorrect. They have overlapping values

longest consecutive uptime:   2 seconds from 2023-05-18 22:31:43 to 2023-05-18 22:31:45
longest consecutive downtime: 1 second from 2023-05-18 22:31:43 to 2023-05-18 22:31:44

How to reproduce
run the program:
go run . fb.com 443

Cause a downtime to the destination and recover after a second:
sudo iptables -A OUTPUT -d <IP_ADDRESS> -j DROP; sleep 1; sudo iptables -F

Quick investigation on

No response received for 0 seconds showing 0 but should be 1

As logs show, this functions still uses actual time to calculate downtime.

For a quick fix this will do (I feel like PR is a bit too much for it, since it's not an actual fix as well)
tcping.go, calcTime()
seconds := duration.Seconds()
if seconds > 0 && seconds < 2 {
	seconds = 1
}

Actual problem lies here (it should be using ongoingUnsuccessfulProbes * time.Second, or something similar)
https://github.com/pouriyajamshidi/tcping/blob/2839563055a3e76c821d2e7db73901339ff84519/statsprinter.go#L201-L205
Although this could be fixed now, I believe it's better to do when we'll fix hardcoded time.Seconds, imho.

For a quick fix this will do (I feel like PR is a bit too much for it, since it's not an actual fix as well)

That's a good quick win.

Although this could be fixed now, I believe it's better to do when we'll fix hardcoded time.Seconds, imho.

No objections. This issue aims to address that problem (the next release is blocked by this issue).

Looks like the longest consecutive downtime is also not displayed at times:

One more odd result:


init README.ru.md

???

lets do Russian description of service like into https://github.com/golang-standards/project-layout


revert changes from PR 5781 and add zxcvbn as ext script

Description
During previous review we had removed zxcvbn because API was not doing it and it took 822 kB of data (which was very big compared to the size of the bundle).
API will soon implement this check but cannot expose a validator endpoint because of DOS risk.
By using a script to bring zxcvbn (for this 1 only usage) we benefit from a caching in the browser that is independent from our codebase and will not force a user to redownload these 822kb too often
** This does affect the UI but we go back to previous UI from 2019**
Type of Change

Non breaking change ('update', 'change')

Note to Reviewers
This code should work today again existing API i reset the code from before we moved away from zxcvbn except without zxcvbn in the bundle.

Just popping in. Rather than loading the JS via the HTML script, would it be more appropriate to lazy-load zxcvbn with a React component? Consider using route-based lazy-loading with React.Suspense. That way, you can:

Get type safety on zxcvbn instead of having to declare var
Not load the library if the page hasn't requested it (only requests probably during signup/login)
Get loading state management using React.Suspense (showing loading indicators, should empty box, etc)

Just popping in. Rather than loading the JS via the HTML script, would it be more appropriate to lazy-load zxcvbn with a React component? Consider using route-based lazy-loading with React.Suspense. That way, you can:

Get type safety on zxcvbn instead of having to declare var
Not load the library if the page hasn't requested it (only requests probably during signup/login)
Get loading state management using React.Suspense (showing loading indicators, should empty box, etc)

Hello,
Thanks for your feedback @quinnturner

type safety, absolutely you are right, it would add type safety for the developer
About the react suspense load, yes this could avoid loading this script if the user never goes in a Linode>create process (the login page is independant). Although this script after it is loaded once is cached until we change this libraries version in the html without us having to add react dependant mechanism

Changed to use React lazy + Suspense, Fallback necessary per Jest unit tests -> SuspenseLoader


Edit Style of sidebar in questions page.

Describe the bug
Under GSSoC22
Sidebar labels and buttons need to have a little margin to look more beautiful.
Screenshots

@AhmedKhaled590 u can work


Exponential search

Would like to state this with example Let me know

Can I work on this?

Can I work on this?

hey bro @gopichandpuli9 you can make a different issue or if I am not able to get it done you can go ahead

@Sloth-Panda in which language you want to work on  : C / C++ / JS / Python?

@ankitapuri I can do it in java/js

@ankitapuri I could implement in python and C++

@ankitapuri I can do it in java/js

Go ahead with JS @Sloth-Panda

@ankitapuri I could implement in python and C++

Go ahead with C++ @gopichandpuli9

@ankitapuri I can do it in java/js

Go ahead with JS @Sloth-Panda

I have done it using java as i have done dsa using it I am most comfortable with it @ankitapuri , should I go on making a pr?

@ankitapuri I can do it in java/js

Go ahead with JS @Sloth-Panda

I have done it using java as i have done dsa using it I am most comfortable with it @ankitapuri , should I go on making a pr?
I am really sorry but I am not taking PRs for Java

@ankitapuri can I give a try in python/c then?

@ankitapuri can I give a try in python/c then?

ok do in C then

Can i give it a try in C++

Can i give it a try in C++

its done


Provide additional docs about pre-commit hooks usage

It's like guide for newcomers, that should cover "first week/month usage issues and questions"

links to common useful practices
tips about pre-commit
tips about git and git hooks

note about that pre-commit work only for files known by git

tips about automation workflows
tips about tools used inside hooks

how to disable check
on what cases check can be desabled and how document it

Etc.
Can be separated to subtasks

Looks like I'll not find time for that


Added new website

Hello Ali, I added a new website. Please merge it.

Thank you for the contribution.


503 Failed to execute query because not enough resources were available to cover 100% of the index

Hello,
I'm getting the error message in the title, on some of my requests (but not all of them) and haven't been able to find resources on what it means or how to solve it.
Would Appreciate any info.
Attached is aggregated error I had gotten, including some simple rate limiting ones

You are being throttled. Please review this documentation
https://learn.microsoft.com/en-us/azure/search/search-performance-analysis#throttling-behaviors


map_space and map_bs

Is your feature request related to a problem? Please describe.
map_cr already exists, map_space would do (|) -> ( | ) and map_bs would do ( | ) -> () or \n  |\n<\a> ->
Describe the solution you'd like
create a is_expandable and is_collapsable function that are publicly exposed and can be reused.
Solution for map_space is detailed in the wiki
https://github.com/windwp/nvim-autopairs/wiki/Custom-rules#add-spaces-between-parentheses

Something like Rule(' ', ' '):useKey('<Plug>autopairs_space') would be awesome.
I currently my custom space mapping is getting overwritten :disappointed:

This code seams to work for the muliline map_bs case.
vim.keymap.set('i', '<c-bs>', '<bs>')
vim.api.nvim_set_keymap('i', '<Plug>autopairs_bs', 'v:lua.MPairs.autopairs_bs()', {
  expr = true,
  noremap = true,
})
vim.keymap.set('i', '<bs>', function()
  if vim.fn.foldclosed('.') > -1 then
    return '<C-o>zo'
  end

  local line = vim.fn.getline('.')
  if line == '' then
    local prev_line = vim.fn.getline(vim.fn.line('.') - 1)
    local next_line = vim.fn.getline(vim.fn.line('.') + 1)
    local trimmed_next_line = next_line:gsub('^ *', '')
    local rules = npairs.get_buf_rules()
    for _, rule in pairs(rules) do
      if rule.start_pair then
        local prev_char, next_char = utils.text_cusor_line(
          prev_line .. trimmed_next_line,
          #prev_line,
          #rule.start_pair,
          #rule.end_pair,
          rule.is_regex
        )
        if utils.compare(rule.start_pair, prev_char, rule.is_regex)
          and utils.compare(rule.end_pair, next_char, rule.is_regex)
        then
          return string.rep('', #next_line - #trimmed_next_line + 1) .. '<bs>'
        end
      end
    end
  end

  return '<Plug>autopairs_bs'
end, { expr = true, silent = true, noremap = true })

Yes, space would be nice! Still important to me

Yes, space would be nice! Still important to me

https://github.com/jguddas/dotfiles/blob/02a3579256e53f4c64bccbc9d15d40ee4953f913/neovim/init.lua#L395-L397


Nginx install fail

I got an error about my nginx and i fixed it but it still didnt work so i uninstalled it but whenever i try to install it is says that its already installed but i cant see what path and the webserver isnt running either

Jitsi Desktop doesn't use a webserver like nginx. If you're referring to an issue with Jitsi Meet, please report the bug in the correct repository.
In any case you need to describe your issue much more detailed.


fix: invalid scene id in 2019.1

This post processor is finding objects that are not in the scene and failing the build in 2019.1
To reproduce,  merge #832 , open the tanks example and try to build

This might solve #824

was the meta file changed intentionally?
and we definitely need that error message, I'll just have to fix the root issue

fixed

Yes. Meta was intentional, because hlapi weaver has the same asset id. We need a new Id so it does not report conflict


Set thread count in predict server

Set the number of threads that tensorflow can use.  I tested that this works by using a job with 2 CPUs but setting the thread count to 1 and using the profiler (which is still in the hack-the-code stage), and saw that the threads being used by TF go down to 1.

The tests are failing.  I need to fix that.  (It is because I can't change the parallelism after TF is installed, but the tests install tensorflow earlier than the rest of the code.  This happens too with the random seed, and I'll fix it the same way.)

Standardized the arguments, and fixed the tests.  It should be good to go.