Core: Ban Yoda conditions, loose comparisons and assignments in conditions

Is your feature request related to a problem?
Yoda conditions are the practice to reverse how comparisons in conditions are written, having the value being compared to on the left hand of the condition and the variable on the right hand, to prevent accidentally assigning something to a variable in a condition.
// This condition:
if ( $variable === 'value' ) {}

// ...would be written like this in Yoda style:
if ( 'value' === $variable ) {}

// ... to prevent this:
if ( $variable = 'value' ) {}

The problem with this is that code readability is decreased significantly to prevent a beginner's mistake which shouldn't be made in the first place and the chances of which are small when using strict comparisons anyhow.
Now, the WordPress coding standards contains a few sniffs related to this:

Core: WordPress.PHP.YodaConditions (error) - demands the use of Yoda conditions as per the handbook.
However, this sniff only looks at comparison operators, i.e. ==, ===, != and !==, not at assignment operators, like =, so in effect, it doesn't actually prevent assignments in conditions in the first place.
Extra: WordPress.CodeAnalysis.AssignmentInCondition (warning) - warns against assignments found in conditions of control structures as well as, in as far possible, assignments in the condition part of ternaries.
Extra: WordPress.PHP.StrictComparisons (warning) - warns against using loose comparisons.
Extra: WordPress.PHP.StrictInArray (warning) - warns against using loose comparisons in array comparison functions.

Note: none of these sniffs currently contain (auto-)fixers.
Describe the solution you'd like
At this moment, I'd like to propose the following:

Drop the handbook rule to demand Yoda conditions.
Remove the WordPress.PHP.YodaConditions sniff - both from the Core ruleset and from the repo (initially deprecated and emptied out, to be removed in the next major release).
Move the WordPress.CodeAnalysis.AssignmentInCondition sniff to the Core ruleset and change it from a warning to an error.
Move the WordPress.PHP.StrictComparisons and WordPress.PHP.StrictInArray sniffs to the Core ruleset, but leave these as a warning.

Impact

At this point, WPCS would have no opinion on whether or not to use Yoda conditions.
I expect that the WordPress.CodeAnalysis.AssignmentInCondition sniff would introduce a limited set of newly detected issues for the WP Core code.
I expect that the introduction of the WordPress.PHP.StrictComparisons and WordPress.PHP.StrictInArray sniffs would introduce a large number of new warnings for the WP Core code base.

Once these changes have been made to WPCS and Core has upgraded, contributors can be encouraged to start looking at the newly detected issues and to fix up the existing (non-strict) comparisons.
This should be done carefully as changing the type of comparison is a behavioural change.
It is recommended to make sure that all changes are covered by unit tests before making this type of change.
Next phase
As a next step, I'd like to propose the handbook to be adjusted to forbid Yoda conditions.
A new sniff will need to be written to detect the use of Yoda Conditions, throw an error and where possible, auto-fix this.
Alternatively it could be considered to add the Slevomat Coding Standard as a dependency to WPCS and use the existing sniff in that standard.
The downsides of that would be:

A new external dependency making installation of WPCS with anything but Composer more fiddly.
No control over the sniff, making getting bugfixes and such accepted slightly more fiddly.

Additional context (optional)
Some discussion about this has been had in other channels. I'm quoting some relevant parts of that discussion here.

@jrfnl Regarding Yoda conditions - we've talked about this before. IMO this rule should be dropped in favour of the "No assignment in condition" rule and the associated sniff WordPress/Generic.CodeAnalysis.AssignmentInCondition which is currently in Extra should be moved to Core.
At the time you asked me to investigate whether there is a sniff available out there which could revert existing Yoda conditions. The answer to that is "Yes". The external Slevomat Coding Standard contains a sniff which can auto-fix Yoda to non-Yoda. Tests could (should) be run to see how well it works, but this sniff could be used in a one-time action to move away from Yoda. Note: if the sniff would not be good enough/would turn out to be buggy, I'm happy to contribute fixes to the Slevomat standard just to make moving away from Yoda possible.
Having said that, as the tooling is available which would allow us to move away from Yoda and still prevent assignments in conditions, I would strongly suggest now is a good time to take a decision on this.

Source: https://core.trac.wordpress.org/ticket/45934#comment:14

@pento Yah, I agree that WordPress/Generic.CodeAnalysis.AssignmentInCondition should be moved into Core, violations should be fixed, and then Yoda conditions should be removed. There's some discussion on #42885 about Yoda conditions, too.
Notably, the JS team are planning on removing guidance on Yoda conditions, I'm inclined to disallow Yoda conditions, rather than simply allow either style, though.

Source: https://core.trac.wordpress.org/ticket/45934#comment:15
Opinions ?

A new sniff will need to be written to detect the use of Yoda Conditions, throw an error and where possible, auto-fix this.
Alternatively it could be considered to add the Slevomat Coding Standard as a dependency to WPCS and use the existing sniff in that standard.

Would it be an option to add detection sniff in WPCS, and use a composer suggest with message that SlevomatCodingStandard.ControlStructures.DisallowYodaComparison can be used as a fixer.
Looking at the Slevomat Coding standard it appears the fixer is far more complex than the sniff part of the implementation.
I think most projects would likely only be using it once during onboarding/initial scan. After that it's enough to be warned about the instance, an it would be natural to not type yoda conditions in the first place.

Anecdotally, I believe Yoda conditions improve code quality & readability.
They are a decades old practice with a proven track record at avoiding accidental assignment errors.
Removing them is removing the steel toes from our workboots because they aren’t comfortable.
Evidently my feelings here aren’t the currently popular ones, but I’m a big -1 on switching away from them.

Removing them is removing the steel toes from our workboots because they aren’t comfortable.

The presence of the assignment in condition check, means we've already removed the chance of anything heavy landing on our feet, so the steel toe caps would be redundant 😄

I'm with @JJJ on this. I don't see any need or improvement to switching away from Yoda conditions.

The problem with this is that code readability is decreased significantly

How is readability decreased, especially "significantly"? Are there references somewhere that aren't included here that can be linked to?
Even if the preference against Yoda conditions continues, I think there's no reason to completely reverse stance and start saying that Yoda conditions are bad practice.

Having thought about this some more, as well as discussing it with a range of different people, I'm not sure that banning Yoda conditions entirely is the most reasonable next step.
@JJJ was kind enough to go into the detail of how he finds Yoda conditions easier than non-Yoda to understand. @nacin mentioned the special case of checking false === strpos( ... ), and the like.
So, I'd like to explore this further before making a change. @davidakennedy recently published an interesting post about designing for accessibility, which I think also applies to this conversation. Let's work out what our constraints are, then make a change that works as well as possible for everyone.
I'm writing a post for make/core about WordPress coding standards changes with relation to the PHP version bump, so I'll include a call for feedback on the topic of Yoda conditions there.

@pento What about the initial step ?

Removing the yoda conditions rule, without replacing it with a ban (i.e. opinion, both yoda and non-yoda allowed);
Banning assignments in conditions;
Recommending strict comparisons.

Should any or all of these be actioned yet ?
Note: each of these three points can be actioned independently of the others.

Removing the yoda conditions rule, without replacing it with a ban (i.e. opinion, both yoda and non-yoda allowed);

To state what might be obvious - the decision to follow Yoda conditions in Core could be set in Core's ruleset or WordPress-Core, even if WordPress-Extra removes this requirement.

@jrfnl: Still working on the post about these. 🙂 Let's not action any of them yet, I suspect that 2 and 3 can happen quickly, but 1 will need some more information on the best way forward.

@pento OK, thanks for the heads-up. I will remove this from the WPCS 2.1.0 milestone for now.

@pento

I'm writing a post for make/core about WordPress coding standards changes with relation to the PHP version bump, so I'll include a call for feedback on the topic of Yoda conditions there.

Can you provide link to the post you mentioned? Just trying to trace the progress of this issue. Thanks!

@CurtisBelt: The post I was referring to was published here, with a followup posted a little later.
You'll note that Yoda conditions weren't mentioned in either post. On further reflection while writing the posts, that topic had the potential to be too much of a distraction from the more immediate changes that could happen. Unfortunately, I never got back to writing a post just for the Yoda conditions discussion.
I'm currently taking a break from working on WordPress Core, so I don't expect to have time to look at this in the near future. Given that the next step is to explore the topic further in a wider discussion, this is something that anyone interested could drive, it certainly doesn't require my input to move it along. I would suggest bringing it up at the next core dev chat as a way to gauge interest in a wider discussion.

I really just think the Yoda conditions need to be removed.
I am all for keeping loose comparisons and assignments in conditions warnings.
I agree with @GaryJones that by having loose comparisons and assignments in conditions is enough to also prevent accidental typos with "=" and "==".

Yoda conditions can be automatically converted to regular conditions with PHP CS Fixer:
'yoda_style' => [
    'equal' => false,
    'identical' => false,
    'less_and_greater' => false,
],

Have we considered the fact to only enforce it when using 2 equal operators and ignore it when using a strict comparison with 3 equal operators instead?
// Enforce it if
if ( $value == false ) {
}

// Ignore if
if ( $value === false ) {
}

Primarily because based on:

In the above example, if you omit an equals sign (admit it, it happens even to the most seasoned of us), you’ll get a parse error, because you can’t assign to a constant like true. If the statement were the other way around ( $the_force = true ), the assignment would be perfectly valid, returning 1, causing the if statement to evaluate to true, and you could be chasing that bug for a while.

Source
When using strict operator the premise from the docs is no longer valid as you are ensuring that won't happen :)

Have we considered the fact to only enforce it when using 2 equal operators and ignore it when using a strict comparison with 3 equal operators instead?

That's a reasonable idea, but in that case why not enforce it only if using one equals operator (which really is the bug this rule is trying to prevent)?
// Enforce it if
if ( $value = false ) {
}

// Ignore it if
if ( $value == false ) {
}

// Ignore if
if ( $value === false ) {
}

The standard is there to make sure that a typo isn't made on a comparison, but automated linting can do that instead, and generally better than humans.

That's a reasonable idea, but in that case, why not enforce it only if using one equals operator (which really is the bug this rule is trying to prevent)?

Mostly for backward compatibility and to make sure when updating to a new rule system existing rules are no longer valid or considered instead. But I do agree if this can be automated I don't see a practical reason why not to replicate it in 2 comparison operators as well.

The standard is there to make sure that a typo isn't made on a comparison, but automated linting can do that instead, and generally better than humans.

:100: on board with this idea.

May I suggest reading the original proposal ? As that's kind of what was originally suggested.

There must be some axiom that says that if a discussion thread gets long enough it will loop back over itself. 😁

May I suggest reading the original proposal ? As that's kind of what was originally suggested.

Well partially, from the main proposal is actually requesting a ban which was updated here: https://github.com/WordPress/WordPress-Coding-Standards/issues/1624#issuecomment-470821000
Maybe should the main ticket description should be updated for a more simple approach instead as you described here: https://github.com/WordPress/WordPress-Coding-Standards/issues/1624#issuecomment-470821000

+1 non-yoda conditions. I find yoda counter-intuitive, as imagine you could.
Perhaps we could open a poll to settle this?

WordPress standardized on Yoda conditions 15 years ago.
Every plugin & theme has inherited that standard, resulting in verifiably millions of lines of PHP code that are written this way.
A timeline of future events after this change happens:

WordPress changes everything internally
Several plugins & themes immediately adopt
Some plugins & themes slowly adopt
Most plugins & themes never adopt

If this changes, the larger WordPress landscape is left littered with the simplest code imaginable (variable comparisons) looking different everywhere, in every project, all over the web. A few people will be happy and feel accomplished, and everyone will suffer.
Changing this results in code-slurry across the web that is marginally easier for a vocal minority to ingest, but will be highly disorienting for everyone else – I.E. people like my brilliant wife who is, as I write this, learning PHP for her very first time and is constantly tripping over (and frustrated by) uselessly differing code structure.
It will be a mistake to the entire ecosystem to intentionally invert such a prolific WordPress'ism.

If this changes, the larger WordPress landscape is left littered with the simplest code imaginable (variable comparisons) looking different everywhere, in every project, all over the web.

On the other hand, the larger PHP ecosystem seems to generally be non-Yoda. From this perspective WordPress seems like the outlier.
Then again, the larger PHP ecosystem has also standardized on PSR-4 for naming files containing classes; camelCase for method and variable names; and short array syntax. I've not seen any other project that requires aligning the => in arrays or = in assignments. And few projects seem to have clung to PHP 5.6 for so long.

@JJJ just because something was added 15 years ago, doesn't mean it should stay this way forever.
I don't think that the argument that various plugins/themes/projects out there having different coding standards (the reality is that the majority doesn't have any) should prevent changes in the WordPress core coding standards.
If anything it would be better if we are doing what the rest of the PHP community is doing and see if we can somehow align with their standard.
That way WordPress wouldn't be the odd one out IMO.
Plus, the point of using automated tools such as PHPCS is to prevent issues that Yoda conditions solved back when we didn't have such tools (or didn't use them)
.

A few people will be happy and feel accomplished, and everyone will suffer.

easier for a vocal minority to ingest, but will be highly disorienting for everyone else

I have downloaded almost all the 93 965 plugins in the WordPress Plugin Repository (Due to network gaps, I was able to download 82 450 plugins directly from wordpress.org servers (93GB)) and ran PHPCS to find the usage of Yoda vs Non Yoda conditions. This provides us with data that brings a pragmatic insight that can be beneficial to the discussion.
I will try to be as transparent, pragmatic, and scientific as possible, to describe every inch of my methodology so that it can be peer-reviewed to make sure it does not contain any bias.
This is the phpcs.xml that I have used:
<?xml version="1.0"?>
<ruleset name="Yoda Analyzer">
    <config name="installed_paths" value="/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/phpcs/vendor/slevomat/coding-standard"/>

    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/0-delay-late-caching-for-feeds</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/0-errors</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/001-prime-strategy-translate-accelerator</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/002-ps-custom-post-type</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/011-ps-custom-taxonomy</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/012-ps-multi-languages</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/028-ps-combine-taxonomy-children</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/030-ps-display-upload-path-for-wp35</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/03talk-community-conference</file>
    <file>/home/lucas/local/data/www/plugin-directory/WordPress-Plugin-Directory-Slurper/plugins/0gravatar</file>
    <!-- ... etc, until all plugins are scanned (in batches) -->

    <exclude-pattern>*/vendor/*</exclude-pattern>
    <exclude-pattern>*/node_modules/*</exclude-pattern>
    <exclude-pattern>*/freemius/*</exclude-pattern>
    <exclude-pattern>*/vendor_prefixed/*</exclude-pattern>
    <exclude-pattern>*/composer/*</exclude-pattern>

    <arg name="extensions" value="php"/>

    <arg name="parallel" value="12"/>

    <rule ref="SlevomatCodingStandard.ControlStructures.DisallowYodaComparison"/>
    <rule ref="SlevomatCodingStandard.ControlStructures.RequireYodaComparison"/>
</ruleset>

I have tried to do my best to exclude any vendor code, such as packages that might be installed using composer, and focus only on the WordPress PHP code of the plugin.

This is what the sniff SlevomatCodingStandard.ControlStructures.DisallowYodaComparison considers Yoda code.
This is what the sniff SlevomatCodingStandard.ControlStructures.RequireYodaComparison considers non-Yoda code.

I've used PHPCS's --report=source option, which gives me a result such as this (this example is for the first 10k scans):
PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     426417
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  100539
[ ] Internal                      No code found                                        1851
[ ] Internal                      Line endings                                         1475
[ ] Internal                      Exception                                            6
--------------------------------------------------------------------------------------------
A TOTAL OF 530288 SNIFF VIOLATIONS WERE FOUND IN 5 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (526479 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 7 mins, 3.01 secs; Memory: 56.24MB

Require yoda comparison required yoda comparison is the rule where we require Yoda conditions, and the count is the number of non-yoda conditions if found. Disallow yoda comparison disallowed yoda comparison is the rule where we disallow Yoda conditions, and the count is the yoda conditions it found.
I had to split the PHPCS run into batches, as it was too much for my PC to process in one go. To do that, I wrote a small script that generates a phpcs.xml with plugins within a range.

Results per batch
Plugins 0 to 10k:
➜  phpcs git:(master) ✗ cat 0_10000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     426417
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  100539
[ ] Internal                      No code found                                        1851
[ ] Internal                      Line endings                                         1475
[ ] Internal                      Exception                                            6
--------------------------------------------------------------------------------------------
A TOTAL OF 530288 SNIFF VIOLATIONS WERE FOUND IN 5 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (526479 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 7 mins, 3.01 secs; Memory: 56.24MB

Plugins 10k to 20k:
➜  phpcs git:(master) ✗ cat 10000_20000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     418345
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  91076
[ ] Internal                      No code found                                        2743
[ ] Internal                      Line endings                                         1233
--------------------------------------------------------------------------------------------
A TOTAL OF 513397 SNIFF VIOLATIONS WERE FOUND IN 4 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (509083 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 7 mins, 0.65 secs; Memory: 54.12MB

Plugins 20k to 30k:
➜  phpcs git:(master) ✗ cat 20000_30000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     445222
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  92608
[ ] Internal                      Line endings                                         2012
[ ] Internal                      No code found                                        1590
[ ] Internal                      Exception                                            2
--------------------------------------------------------------------------------------------
A TOTAL OF 541434 SNIFF VIOLATIONS WERE FOUND IN 5 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (537569 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 7 mins, 37.34 secs; Memory: 54.27MB

Plugins 30k to 40k:
➜  phpcs git:(master) ✗ cat 30000_40000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     458963
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  101565
[ ] Internal                      Line endings                                         3784
[ ] Internal                      No code found                                        2689
[ ] Internal                      Exception                                            7
--------------------------------------------------------------------------------------------
A TOTAL OF 567008 SNIFF VIOLATIONS WERE FOUND IN 5 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (560188 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 6 mins, 50.86 secs; Memory: 58.91MB

Plugins 40k to 50k:
➜  phpcs git:(master) ✗ cat 40000_50000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     479307
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  96621
[ ] Internal                      Line endings                                         3196
[ ] Internal                      No code found                                        1631
[ ] Internal                      Exception                                            1
--------------------------------------------------------------------------------------------
A TOTAL OF 580756 SNIFF VIOLATIONS WERE FOUND IN 5 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (575509 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 7 mins, 33.55 secs; Memory: 62.96MB

Plugins 50k to 60k:
➜  phpcs git:(master) ✗ cat 50000_60000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     364109
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  82842
[ ] Internal                      No code found                                        1617
[ ] Internal                      Line endings                                         1123
--------------------------------------------------------------------------------------------
A TOTAL OF 449691 SNIFF VIOLATIONS WERE FOUND IN 4 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (446646 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 6 mins, 25.88 secs; Memory: 47.55MB

Plugins 60k to 70k:
➜  phpcs git:(master) ✗ cat 60000_70000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     472825
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  106476
[ ] Internal                      Line endings                                         1831
[ ] Internal                      No code found                                        1762
[ ] Internal                      Exception                                            4
[ ] Internal                      Tokenizer                                            1
--------------------------------------------------------------------------------------------
A TOTAL OF 582899 SNIFF VIOLATIONS WERE FOUND IN 6 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (578880 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 8 mins, 5.99 secs; Memory: 58.7MB

Plugins 70k to 80k:
➜  phpcs git:(master) ✗ cat 70000_80000.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
-----------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                 COUNT
-----------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yod  549068
[x] Slevomat  Control structures  Disallow yoda comparison disallowed   120069
[ ] Internal                      No code found                         1731
[ ] Internal                      Line endings                          1428
[ ] Internal                      Exception                             6
-----------------------------------------------------------------------------
A TOTAL OF 672302 SNIFF VIOLATIONS WERE FOUND IN 5 SOURCES
-----------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (668881 VIOLATIONS IN TOTAL)
-----------------------------------------------------------------------------

Time: 9 mins, 26.69 secs; Memory: 63.78MB

Plugins 80k to 82450:
➜  phpcs git:(master) ✗ cat 80000_82450.txt

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     166025
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  38594
[ ] Internal                      No code found                                        536
[ ] Internal                      Line endings                                         251
[ ] Internal                      Exception                                            1
--------------------------------------------------------------------------------------------
A TOTAL OF 205407 SNIFF VIOLATIONS WERE FOUND IN 5 SOURCES
--------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SOURCES AUTOMATICALLY (204464 VIOLATIONS IN TOTAL)
--------------------------------------------------------------------------------------------

Time: 3 mins, 38.64 secs; Memory: 24.75MB

This is the final result:

Total Conditions: 4 610 671 (100%)
Normal Conditions: 3 780 281 (81.98%)
Yoda Conditions: 830 390 (18.02%)

My thoughts:
Looking at the data, I don't see a cascading effect on the entire world wide web that could bring doom and calamity to the internet if we stop using Yoda in Core. The Codex itself has a funny statement on the "Yoda" section: A little bizarre, it is, to read. Get used to it, you will., which seems to go against what it says just a couple lines below, on the "Clever Code" section: In general, readability is more important than cleverness or brevity..
To be quite frank, I think I'm dumber than most people. I really do. I don't have a very high cognitive capacity. That's why for me it's very important that the code is easy to read, follow, and understand. My personal opinion is that it compromises readability, and this is pretty much the consensus of Yoda conditions on the internet for the majority. People will not agree on everything, but we can pretty much confidently say that the majority prefers regular conditions, so I think this is a pretty pertinent discussion to have.

After commenting before in favor of keeping Yoda conditions, I feel like my stance has changed slightly. I think the best way forward is to:

Allow both styles of conditionals, Yoda and "regular".
As initially described, an assignment within a conditional should be an error.
Loose (==) operators should be a warning, as they are likely to be the source of sneaky bugs.

For item 1, I think that while the discussion around readability is completely relevant, the fact remains that we're talking about comparing two values. Is it really a readability issue to distinguish between 'a' === $b and $b === 'a'? Comparisons like this should be equally easy (or difficult) for a developer to parse regardless of which item is first.
To Yoda or not to Yoda feels like it is getting far more controversial than it really deserves, and perhaps the best solution is to switch from enforcing it to taking no stance at all on it. Instead, let's just focus on truly solving the problem that Yoda conditions originally intended to solve: assignments within conditionals.

Thanks @Luc45 💜 I wasn't intentionally fear-mongering, but certainly unintentionally, and the data is extremely helpful to see. Relatedly, I hadn't deeply considered what the greater PHP community had decided, so that's also compelling.
Consider me persuaded. Please accept my embarrassed apologies for disrupting progress here, and you have my gratitude for being patient with my resistance.

@JJJ it is with good intentions and divergent opinions that we get to the best solutions, always. If we all agreed, we would be missing the opportunity to seeing things from another angle, which could be dangerous. So thank you for disagreeing before, and for being open to the discussion.

Wanted to voice support for @JPry's comment above

Allow both styles of conditionals, Yoda and "regular".
As initially described, an assignment within a conditional should be an error.
Loose (==) operators should be a warning, as they are likely to be the source of sneaky bugs.

I don't care if WPCS does end up banning yoda conditionals or not, but I think the initial step of not trying to force code to use yoda is a good step forward.

In the context of WordPress Core, allowing both is a disaster IMO. Either use one or the other. Allowing both to be in the core just adds additional confusion for new developers to the project. Should it be Yoda or not? When? Why?
We should be consistent across the codebase.
I think people confuse WPCS standards as set in stone when it comes to building their own themes or plugins. And that's not the case. You can use whatever you want in your project. You can use parts of the WPCS ruleset, remove some, leave the one you want.
Personally, I only use some functional aspects of WPCS in my projects, while removing almost all of the styling CS, because I prefer PSR-12 and PSR-4 for autoloading.
I think this issue could be talked about in a meeting and discussed in official make posts for more visibility. Maybe throw in a poll to get the wider audience reach.

Otherwise, $a === 'b' is just as easy to understand as 'b' === $a.

As a person with dyslexia, I strongly disagree with this, the second form takes me about three times as much time to process as the first.
I do agree that the original goal of why Yoda was initially enforced has been superseded and that that should be addressed first.
As for consistency in the WP Core code base after the Yoda restriction has been removed, let's leave that for a future iteration.
For plugin/theme repos, they can choose their own rules, so even when WPCS would remove the rule, there are sniff available (in PHPCS itself/other external standards) to either enforce no Yoda or to still enforce Yoda, which a plugin/theme can elect to add to their custom ruleset.

I'd like to add another reason to remove the Yoda rule: it makes the sniffs noisier for no useful reason.
The sniffs only help users who install them, so anyone who doesn't and isn't contributing to Core is out of scope. If someone has installed the sniffs, they can get instant feedback on errors. The most useful feedback is warnings about assignment-in-condition and loose comparisons: those are the specific things that cause problems, and that info is helpful to novice and experienced  devs alike.
Enforcing Yoda doesn't add anything to this — it just generates more warnings, more noise for the developer to process, and hence more overwhelm and a longer learning curve for new devs.

I think you're confusing code style checks with static code analysis, such as PHPStan.

How so? This is all checkable through PHPCS. I can get alerts from it as I code with something like the PHP Sniffer & Beautifier extension in VS Code. No static analysis necessary, afaik.

Just a FYI: PHPCS === static analysis, just based on a different entry point to the code compared to PHPStan.

True that. My reasoning when I said that was because of the intent... PHPCS uses static analysis to check code style, while PHPStan uses static analysis to check logic errors, so if by "useful error" he means "flagging logic errors in my code", PHPCS is not the tool for that, as PHPCS only enforces code style conventions that shouldn't affect the logic of the code, no matter how the code style looks like.
<offtopic/>

As for next steps, what about?

Instead of enforcing Yoda, ban Yoda.
Increase the code style version to ^2.4.0, so projects that are already written in Yoda can lock to ^2.3.0 to avoid having to refactor to comply with the code style checks and keep CI happy.
Add documentation on how to convert a codebase from Yoda to non-yoda, which is simply: Run PHPCBF with PHP-CS-Fixer yoda_style rules configured to enforce non-yoda [Link]

Just a FYI: PHPCS === static analysis, just based on a different entry point to the code compared to PHPStan.

True that. My reasoning when I said that was because of the intent... PHPCS uses static analysis to check code style, while PHPStan uses static analysis to check logic errors, so if by "useful error" he means "flagging logic errors in my code", PHPCS is not the tool for that, as PHPCS generally speaking is meant to enforce code style conventions that shouldn't affect the logic of the code, no matter how the code style looks like.
<offtopic/>

While maybe off topic, it does a disservice to PHPCS, which can do a lot more than just check for code style convention. Think: the PHPCompatibility standard and sniffs in the CodeAnalysis category.
Of course, there are limitations, but don't underestimate PHPCS.
As for next steps, see my previous post about this and the original topic.
Most likely, we'll need a Make post before we can put this into effect anyhow.
Other than that:

The next version of WPCS will be 3.0.0, there is not going to be a 2.4.0.
Regarding fixing - you are confusing two different tools - CS-Fixer is completely unrelated to PHPCS/PHPCBF and these tools don't work with the rulesets from each other/cannot be used interchangably.

@jrfnl good points about the PHPCompatibility capabilities of PHPCS. A while back I needed to convert a project from Yoda to non-yoda, and PHP-CS-Fixer was the only tool that I found that could do it (Link). Indeed, I remember now that it was a separate tool from PHPCBF.

@Luc45 As described in the original topic, there is a PHPCS sniff in the Slevomat standard which can do this perfectly fine as well.

You're right, thanks. I'm replying here while working on other stuff and am a little bit distracted. I remember now that I have used that Slevomat standard when counting Yoda vs Non-Yoda in the WordPress Plugin ecosystem, actually... I agree that bumping to ^3.0.0 makes sense. Do you agree about banning assignments in conditions?

A good example of where Yoda can get really confusing: Inverted comparison operators:

Friends, what should we do next to bring this proposal to the table? Does anyone oppose getting rid of Yoda?

A good example of where Yoda can get really confusing: Inverted comparison operators:

These were never included in the Yoda condition rules.

These were never included in the Yoda condition rules.

Ah, you're right, thanks for the clarification. I have verified this in multiple ways and that statement does hold true.

Yoda and Numeric Comparison verification
As expected, Yoda rules does not enforce any kind of inverted order for numeric comparisons, in multiple scenarios as tested below. None of these scenarios are flagged by Yoda rules:
/vendor/bin/phpcs foo.php --standard=WordPress --sniffs=WordPress.PHP.YodaConditions
<?php

$count = 21;
$target = 20;
$getCount = static function () {
	return 21;
};
$getTarget = static function () {
	return 20;
};

// Numeric comparison with int - Inverted
if ( 20 <= $count ) {
	// no-op
}
// Numeric comparison with int
if ( $count > 20 ) {
	// no-op
}

// Numeric comparison with variable - Inverted
if ( $target <= $count ) {
	// no-op
}
// Numeric comparison with variable
if ( $count > $target ) {
	// no-op
}

// Numeric comparison with callable - Inverted
if ( $getTarget <= $count ) {
	// no-op
}
// Numeric comparison with callable
if ( $count > $getTarget ) {
	// no-op
}

// Numeric comparison with callable (variation) - Inverted
if ( $target <= $getCount ) {
	// no-op
}
// Numeric comparison with callable (variation)
if ( $getCount > $target ) {
	// no-op
}

// Numeric comparison with callable (variation 2) - Inverted
if ( $getTarget <= $getCount ) {
	// no-op
}
// Numeric comparison with callable (variation 2)
if ( $getCount > $getTarget ) {
	// no-op
}

Even though the enforcement is not there at a technical level, this popped up on a code review for me on a codebase that has Yoda enforced, I have asked the developer if he had struggled to write that line as much as I did to read it and he vented with me that he had struggled a lot. I will inform him that he does not need to invert numeric comparisons.
Now, the most important: Does anyone oppose @jrfnl proposal? I would like to pledge that we refrain all further replies to this lengthy thread to the resolution of this issue, so that we can get to a conclusion.

As this has been a long-standing issue with widely opposing views and lots of people with firm opinions involved, I believe a post on Make to announce our intention to change this is needed to move this forward.
Volunteers to write the post very welcome. I'm happy to review it before publication.
In my opinion, these are the action steps needed to get this sorted (in order):

[ ] Publish announcement of the intention to change this rule on Make Core, including what the "new" rules will be.
[ ] If the majority of responses to the Make post is positive, send in a PR to the Core CS handbook repo to update the official standards.
[ ] After the handbook has been changed, send in a PR to this repo to make the changes as originally proposed.

@Luc45 I don't oppose with the initial idea of @jrfnl to not enforce the Yoda condition any more (although I personally prefer it). I would just ask us not to "ban", disallow it, as some other people recommended in the comments. Basically what @jrfnl mentioned in this comment: https://github.com/WordPress/WordPress-Coding-Standards/issues/1624#issuecomment-470821000

@Luc45 I don't oppose with the initial idea of @jrfnl to not enforce the Yoda condition any more (although I personally prefer it). I would just ask us not to "ban", disallow it, as some other people recommended in the comments. Basically what @jrfnl mentioned in this comment: https://github.com/WordPress/WordPress-Coding-Standards/issues/1624#issuecomment-470821000

I understand, and this is indeed a very delicate topic. As banning Yoda might seem as unfair to some as enforcing  is to others.
Considering, and feeling, and trying to be fair with this, I am considering an equation like this:
$ecosystem = $developer_happiness + $codebase_consistency;

By enforcing Yoda, we can, with the data we have, (count of yoda vs regular and count of reactions in this proposal) infer that it decreases $developer_happiness.
// Considering:
// Yoda: 20% of conditionals found in large-scale sample
// Regular: 80% of conditionals found in large-scale sample

$ecosystem = 0.2 + 1; // 1.2 Enforcing Yoda
$ecosystem = 0.8 + 1; // 1.8 Banning Yoda
$ecosystem = 1 + ?; // ? Allowing Both

The critical point is that if we don't ban Yoda, we will never have enough incentive to get rid of it, thus decreasing $codebase_consistency dramatically over time, leading to a lower score of $ecosystem.
If you are passionate about Yoda, you can always disable the PHPCS sniff or even enforce Yoda in your project.
With that said, I think we can save our most brilliant discussions to the Make post, which I think is the most efficient path moving forward.

Volunteers to write the post very welcome.

Your proposal in this thread is already a very nice starting point to a post. I am sorry for not being able to help on that, as I'm going through one of those "crunch times" that happens every time you have a deadline and lots of technical work to do, which is a feeling I think most software developers know very well.
Someone...? :disguised_face:

@Luc45 I don't oppose with the initial idea of @jrfnl to not enforce the Yoda condition any more (although I personally prefer it). I would just ask us not to "ban", disallow it, as some other people recommended in the comments. Basically what @jrfnl mentioned in this comment: https://github.com/WordPress/WordPress-Coding-Standards/issues/1624#issuecomment-470821000

I think it's fine for us to have different opinions. As a collective we are always making choices, and divergence is a natural part of this process. Our sum of choices over time defines the success or failure of the collective enterprise, so it's a big responsibility to have opinions and defend them, which is only worthy as long as we still believe in what we are saying.
With that in mind, and aware that this divergence exist, I find myself in a crossroad: We can either write the Make post and bring further discussions there, as a definitive, formal place. Or only write the Make post once we have reached a consensus on whether to ban yoda or be indifferent about it.
I think the concept of a "Consensus" in a collective can actually be harmful to strive for. As to achieve consensus on every decision, we might often need to make suboptimal concessions for immediate happiness that are not healthy to the collective as a whole, like politics.
With that said, and taking upon the responsibility of keeping this thread on track so that we can keep a level of efficiency towards the best outcome for the issue at hand, I ask:
@2ndkauboy (and others), why should we allow Yoda in WordPress Coding Standards ^3? Don't you think it would decrease the codebase consistency, which is one of the main goals of a code style convention?

Why we should allow it? That's easy to answer: because we have enforced it in the past. Now banning it would make the vote more inconsistent, because we would need to change it on all occurrence, this would be a huge change. And we also have to get it out of the muscle memory of every WordPress developer, which might be just as hard 😁

For the sake of efficiency, let's focus on making this the final discussion before the Make post.
A) To ban Yoda.
B) To be indifferent about Yoda.
I prefer A, but I understand your argument in regards to "time to adapt".
With that said, I still think A is the best path moving forward, given a few criteria are met:
1: Codebases that need more time can always stick to WPCS ^2 for a while.
2: Simple instructions on how to automatically swap Yoda for regular conditions on existing codebases are documented.
Swapping Yoda for Regular on a codebase should ideally be a one-liner, something like:
./vendor/bin/phpcbf src --standard=WordPress --sniffs=WordPress.PHP.YodaConditions
(Considering Slevomat Coding Standard is added as a dependency of WPCS ^3 as proposed in the original thread)
In a large codebase with many open PRs branched off before the coding standard has been updated, this is one approach to avoid merge conflicts with open PRs:

Create a branch with only the version bump:

git checkout trunk
git branch -b wpcs-3
composer require wp-coding-standards/wpcs ^3 --dev
git add . && git commit -m "WPCS ^3" && git push

Create another branch for trunk fixed by PHPCBF:

git checkout trunk
git branch -b wpcs-phpcbf-3
git merge wpcs-3
./vendor/bin/phpcbf src --standard=WordPress --sniffs=WordPress.PHP.YodaConditions
git add . && git commit -m "PHPCBF WPCS ^3 && git push

Foreach PR:

git checkout my-pr
git merge wpcs-3
./vendor/bin/phpcbf src --standard=WordPress --sniffs=WordPress.PHP.YodaConditions
git add . && git commit -m "PHPCBF WPCS ^3" && git push

Now trunk and all open PRs have updated their codebases to regular conditions without any merge conflicts or manual labor.
With that said, this is what I personally defend to keep the codebase consistent between new and existing code. These are my arguments, and if we agree to disagree, that's fine. I am proud that we are able to have a rational discussion about Coding Standads at all, instead of going against each other with pitchforks and torches. This is the sign of a strong community, where everyone is comfortable coming forward and defend their opinion without being torn apart for it.
I'm looking forward for the conclusion and a hero that will write that Make post, be it as it may.

@2ndkauboy

It would also break many pending patches to core with a Yoda condition in place.

Not it wouldn't break anything if it was removed. No sniff is checking the absence of Yoda, only its enforcement. So code written with Yoda style or without it, if you don't include Yoda won't report: Missing Yoda condition this statement is 😂
Also, the argument that a lot of plugins/themes use Yoda or not, is not a concern for WordPress Core. A lot of plugins follow PSR-12 (or 2), but that doesn't mean we'd need to enforce curly braces on the separate line in the WordPress Core.

@dingo-d I'm talking about any patch on Trac/GitHub waiting to be merged with changes including a Yoda condition.
As far as we care about the WordPress Core: it uses only Yoda conditions. Plugins can and will use whatever syntax they want to use.

@jrfnl thanks for pointing me to that comment. I haven't recognized it really.
I did a quick check on a fresh copy of WordPress 5.9.3 if I exclude all external dependencies/libraries, I get the following numbers:
PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------------
    STANDARD  CATEGORY            SNIFF                                                COUNT
--------------------------------------------------------------------------------------------
[x] Slevomat  Control structures  Disallow yoda comparison disallowed yoda comparison  4621
[x] Slevomat  Control structures  Require yoda comparison required yoda comparison     302
[ ] WordPres  PHP                 Yoda conditions not yoda                             9
--------------------------------------------------------------------------------------------

Those 9 WordPress.PHP.YodaConditions.NotYoda violations come from the three "(ms-)deprecated.php" files. But what I also realized is that the SlevomatCodingStandard.ControlStructures.RequireYodaComparison would also flag a comparsion of a function to a string (like strpos( $permalink_structure, '%year%' ) !== false) but WordPress.PHP.YodaConditions.NotYoda does not flag that as a violation.
The summary also shows the number of violations, not the number of plugins, so we can't really tell from that summary how many plugins do use Yoda conditions and how many don't.
If we care about WordPress Core only, the Core is exclusively using Yoda conditions (except for those 9 violations in deprecated functions). If the number of violations of SlevomatCodingStandard.ControlStructures.DisallowYodaComparison is correct though, this would mean that Core would need a huge commit of up to 4621 changed lines.
So I would strongly suggest to go with your initial approach of just removing the sniff and going with B) To be indifferent about Yoda as @Luc45 mentioned.
The bigger issues are WordPress.CodeAnalysis.AssignmentInCondition, WordPress.PHP.StrictComparisons and WordPress.PHP.StrictInArray, but not whether we want to ban the Yoda condition from WordPress Core.

Again, I wouldn't include Slevomats Yoda check at all in core. So no patches would fail. No notices in the core would be thrown.

So I would strongly suggest to go with your initial approach of just removing the sniff and going with B) To be indifferent about Yoda as @Luc45 mentioned, or even keeping the sniff and move the other ones to the Core ruleset.

This is my stance as well. Remove the sniff, don't enforce it, but don't check if Yoda code exists or not in the codebase. If it exists, ok, if the new patches are not using it, also ok.

I've written a proposal on the core blog, it's still in draft mode.
@jrfnl @GaryJones I'd love to get your feedback on it when you'll find the time.

The article is live: https://make.wordpress.org/core/2022/06/14/upcoming-disallow-assignments-in-conditions-and-remove-the-yoda-condition-requirement-for-php/

Please participate in this unscientific poll on Yoda conditions: https://twitter.com/jrf_nl/status/1537015003546542080

The loose comparisons and assignments in conditions checks are in the core ruleset, but despite the overwhelming argument for removing Yoda conditions by the community, it was decided to leave those in the core ruleset.
If in the future we choose to revisit the Yoda conditions, we'll open a new issue.


Carthage Support

This PR brings carthage support

Thanks @cybertk and sorry for taking so long to respond.
Does this break anything with the previous way of using the project? For testing/developing purposes and for users of CocoaPods?

No, it will keep all existing functions.


Ability to go on margin

Add the ability to go on margin.
We'd have to figure out some rules on what the interest rate should be, max margin-to-equity ratio, maintenance requirement, and how margin calls will work.

This issue has been moved to the new repo, OttoBroker.


Go helloworld

Please a directory structure that includes the fact this is a tracing example (hello-world-tracing).  The instructions should also have links to where traces can be viewed, just like the java example.


Add ConstrainedQuadraticModel.str() method

For #1188.

Codecov Report

Merging #1207 (c3e24cb) into main (6ee9013) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1207      +/-   ##
==========================================
+ Coverage   94.83%   94.85%   +0.01%
==========================================
  Files          83       83
  Lines        8118     8136      +18
==========================================
+ Hits         7699     7717      +18
  Misses        419      419

Impacted Files
Coverage Δ

dimod/constrained.py
94.29% <100.00%> (+0.18%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6ee9013...c3e24cb. Read the comment docs.

For (1), we use the same rules as to_polystring(), see discussion(s) in https://github.com/dwavesystems/dimod/pull/1054. IMO it is important to show them somewhere, since they are present in the object. We could adjust the rules to only show the multiplications by 0 if they are not in any quadratic interactions and not in any constraints`.

For (1) I think I like the single line.
For (2) I think the 80char limit would be ideal. But agree it would take a lot of fiddling to always break between the variables. I am fine with it being out of scope for now. Really the change should be upstream in to_polystring() anyway.
For (3) I take your point about explicitness. I don't mind the empty constraint section

Summary of the state of this PR from my perspective:
I'm on the whole satisified with this as it stands, as it adds a nice capability and I'm not aware of any blocking issues.  And I'm happy to improve it if there is consensus on what is needed.
To summarize the possible future work we've discussed here:

Add ability to only show the multiplications by 0 if they are not in any quadratic interactions and not in any constraints.
Add ability to limit line length to given number of characters, by omitting sequence of terms and substituting ellipses in their place.
Add ability to control numerical precision of string representation of biases.
Add ability for user to control all of the above via some combination of global functions (e.g. surfaced in a new display_options module), environment variables, or config file variables.


Folder "group by" not saved.

Description
Hi,
Folder "group by" not saved.
https://user-images.githubusercontent.com/23485114/148827566-46bab524-006a-4419-b096-d23c8f15cc96.mp4
Steps To Reproduce
No response
Expected behavior
Folder "group by" saved.
Files Version
Version: <IP_ADDRESS> OS Version: 10.0.19044.1415
Windows Version
Windows 10 20H2 19044.1415
Relevant Assets/Logs
debug_fulltrust.log

This is intentional and matches the behavior of File Explorer where each directory has their own settings. You can change this by turning off the option to use individual preferences in different directories.

Now I turning on the option to use individual preferences in different directories.

I expected "group by" saved for each folder.


[Feature request] Sublime Text plugin source

1. Summary
It would be nice, if you add source of Sublime Text Kite plugin to any hosting as GitLab, BitBucket or GitHub.
2. Argumentation

For example, I want to create a pull request. But at the time I can't find repository for pull request.
It would be nice, if issues for each plugin will in separate repositories. I think it will be more convenient to Kite staff.

Thanks.

Hi @Kristinita, thank you for the feedback.  While we don't have plans to open source the Sublime Text 3 plugin currently, we will keep this in mind.  In the mean time please feel free to post any issues you run into here and note them as related to ST3.
Thanks again!


Why not Meteor?

Just curious, cool to see express and webpack, just curious.

This is not an app. Works with Meteor too.


Videos shared from other people in chat are still image only

A friend shared an uploaded video with me. In YakYak it previews a still image with a play button. Upon clicking the image, it opens the still image with the superimposed play button in a browser. When clicking the same thing in Hangouts, it opens, then redirects the link to the actual video.

which version are you using ? how did the guy send the video ? can someone send a video to me the same way so i can reproduce the issue ? :D

@davibe videos can be sent via the android app and I think via the webinterface by choosing a video (I believe I did the latter one once, but not 100% sure)
I'll send you a video in a short while

i found where the actual video url is. The problem is that this url requires the user to be logged.
When using google services on the main browser one cam be logged with many accounts at once. When navigating to different google services the urls have an index to know which account you're using. For example gmail.com/u/0/... and gmail.com/u/1/.... The ids are actually indexes and depend on the order of logins you performed in your browser
Yakyak only logs-in as one single user. The video url we receive may not match the url of the logged user in the main browser. Sicne we open the urls in the main browser it may or may not work.
I think it works only if you are logged one single user and it's the same you use in yakyak.
One solution (painful) could be to open contents directly in yakyak. I have tried creating a new window (window.open) but the new windows does not share the same session/cookie as the main one.
Hmm..

The video url we get from google requires authentication but it redirects to an un-aunthenticated one. We could modify hangupsjs to add a method to perform the first authenticated http request for us and retrieve the final url it redirects to. Then the final url could be open in the external browser.
I had a look at hangupsjs apparently this needs to be implemented in the ChatReq and exposed at Client level
Here is an example. Yakyak receives this

https://plus.google.com/u/3/photos/albums/pgf13jocroaeltkdarjm1co380vcbfli8?pid=6374318644773096706&oid=105346544122646337367

which redirects to this

https://r6---sn-hpa7zn7y.googlevideo.com/videoplayback?id=1e7397d2a6f34ccb&itag=22&source=picasa&begin=0&requiressl=yes&mm=30&mn=sn-hpa7zn7y&ms=nxu&mv=m&nh=IgpwcjAxLm1pbDAyKgw3Mi4xNC4yMTEuNjg&pl=21&sc=yes&mime=video/mp4&lmt=1484136737888760&mt=1484146143&ip=<IP_ADDRESS>&ipbits=8&expire=1484175055&sparams=ip,ipbits,expire,id,itag,source,requiressl,mm,mn,ms,mv,nh,pl,sc,mime,lmt&signature=701A059490D3FF042DB5DAD9A73A16F01DBF0D45.51E7CDA55C39EA1A44B3EFF9A413D3EBE88CD78C&key=ck2

I managed to workaround this on the client (renderer) side but i still think it the url-resolving logic should be implemented in hangupsjs at some point.


Enum as Event parameter crashes client

Apparently the client crashes, when you use an enum as parameter for an Event.
Any suggestions for a workaround?

Could you give an example of AL code to reproduce the problem?

enum 50100 TestEnum
{
value(1; FirstEnumValue)
{
Caption = 'First Enum Value';
}
value(2; SecondEnumValue)
{
Caption = 'Second Enum Value';
}
}
codeunit 50100 TestEnum
{
trigger OnRun()
var
FooEnum: Enum TestEnum;
begin
TestPublisher(FooEnum::FirstEnumValue);
end;
[IntegrationEvent(false, false)]
local procedure TestPublisher(TestEnum: Enum TestEnum)
begin
end;

[EventSubscriber(ObjectType::Codeunit, Codeunit::TestEnum, 'TestPublisher', '', true, true)]
local procedure TestSubscriber(TestEnum: Enum TestEnum)
begin
    If Confirm(format(TestEnum)) then;
end;

}

Used format before publish and evaluate after subscribe as a workaround for now so not critical.

Is there any timeframe for when enums will be added as a valid type throughout the system. (It isn't recognized for use with flowfields for instance, and I've experienced other places where I get a similar error.)
And do you know if enums will be part of the October BC release?


Create npm-grunt.yml

Do you have a bit more explanation what this is supposed to do? I haven't used grunt, isn't that supposed to be installed as well?
To be fair, everything is currently done before publishing, so don't really need a ton of CI/CD stuff atm. But will certainly need something a bit more solid down the road.


Remove two Dentons proxies

Description:
Per Dentons these are seeing very little traffic and they would like to delete them to remove costs. These must be removed from docs and address books first to avoid disruption to the network.
Related issue(s):
https://github.com/hashgraph/hedera-docs/pull/496
https://github.com/hashgraph/hedera-sdk-swift/pull/316
Notes for reviewer:
N/A
Checklist

[X] Documented (Code comments, README, etc.)
[X] Tested (unit, integration, etc.)

Hi @RickyLB  - I am not a rust developer and it will take me time to get this in place. I'm in DevOps management so I don't exactly have a lot of time, either. The linting step is unrelated to my failures. If you see this as blocking can you please add any formatting you'd like to see?


[SMALLFIX] Use the @Nullable annotation for all methods which may ret…

…urn null in UfsStatus.java

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/16902/
Test PASSed.


Delay workspace recommendations as remote extensions installations are ongoing

In remote windows such as codespaces it's possible to see the extension recommendation dialog while the extensions from the container are still installed.

I reproduced this in a codespace with devcontainer.json and a extensions.json containing
"extensions": [
	"rebornix.ruby",
	"castwide.solargraph",
]

That said, I only reproduced it once.

I pushed a change set that adds a delay of 5 seconds to the workspace recommendations.
Ideally there's a way to wait until ongoing installations are completed. Leaving that to @sandy081 for later.

Closing as fixed.

verified with code review


New Matcher: .toBeWithin(start, end)

Feature Request
Description:
.toBeWithin(start, end)
Use .toBeWithin when checking if a number is in between the given bounds of: start (inclusive) and end (exclusive).
test('passes when number is within given bounds', () => {
  expect(1).toBeWithin(1, 3);
  expect(2).toBeWithin(1, 3);
  expect(3).not.toBeWithin(1, 3);
});

hi, I'd like to try this

all yours @martiuslim remember to star and share :smile:


kubectl debug never connects

From the client:
Agent Pod info: [Name:debug-agent-pod-c632639e-200e-11ea-bb14-024283a9b9b2, Namespace:default, Image:aylei/debug-agent:latest, HostPort:10027, ContainerPort:10027]
Waiting for pod debug-agent-pod-c632639e-200e-11ea-bb14-024283a9b9b2 to run...
pod hellopy-5db6788688-kd5xz PodIP <IP_ADDRESS>, agentPodIP <IP_ADDRESS>
wait for forward port to debug agent ready...
Forwarding from <IP_ADDRESS>:10027 -> 10027
Forwarding from [::1]:10027 -> 10027
Handling connection for 10027

From the debug agent:
2019/12/16 14:17:26 Listening on <IP_ADDRESS>:10027
2019/12/16 14:17:28 receive debug request
2019/12/16 14:17:28 http: superfluous response.WriteHeader call from k8s.io/apimachinery/pkg/util/httpstream/spdy.responseUpgrader.UpgradeResponse (upgrade.go:91)

Just started trying to use kubectl-debug myself and ran into this.    Does anyone know of a work around?

Couple of things

Believe dmayle left out this message
E0403 22:33:34.210311    4348 httpstream.go:188] timed out waiting for client to create streams

Been trying to println debug this.   I see the client calls Negotiate in spdy.go and that executes as far as the call to upgrader.NewConnection.    However that never returns.

I think what is happening is

In the plugin, there is an attempt to get a container id from the specified pod.
( cmd.go Run, between lines 429 and 475 )   This is coming up with a value like
containerd://68620696047ddb08fa2ea8042aadc75d36764ef35bb551252176f02596c00537]
In the agent, in server.go around line 76 in the function ServeDebug there is a check to see if the container id begins with docker://.   Because it does not, the agent calls http.Error.    This causes headers to be sent.
However ServeDebug doesn't abort.    It keeps executing
Back in the plugin, it is going to hang because it will try to upgrade the connection but the connection is in a bad state.
In the agent it will also try to proceed to the point where it upgrades the connection.   This cases a second call to send headers.   The functoin WriterHeader in server.go detects this and reports the 'superflous call' and aborts.   Later the code waiting for the streams to be established times out.

Not sure if the check for docker:// can just be removed and/or how to work around this.

I tried removing the check for docker://.   Things progressed further but still did not work in the end.

Handling connection for 10027
2020/04/04 06:14:06 spdy Negotiate Making NewConnection
2020/04/04 06:14:06 remotecommand Stream negotiationed &{conn:0xc0007d80b0 streams:[] streamLock:{state:0 sema:0} newStreamHandler:0x716c50} v4.channel.k8s.io
set container procfs correct false ..
pulling image nicolaka/netshoot:latest...
end port-forward...
error execute remote, Internal error occurred: error attaching to container: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
error: Internal error occurred: error attaching to container: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Is there a prerequisite that docker be on the system and running?

From the client:
Agent Pod info: [Name:debug-agent-pod-c632639e-200e-11ea-bb14-024283a9b9b2, Namespace:default, Image:aylei/debug-agent:latest, HostPort:10027, ContainerPort:10027]
Waiting for pod debug-agent-pod-c632639e-200e-11ea-bb14-024283a9b9b2 to run...
pod hellopy-5db6788688-kd5xz PodIP <IP_ADDRESS>, agentPodIP <IP_ADDRESS>
wait for forward port to debug agent ready...
Forwarding from <IP_ADDRESS>:10027 -> 10027
Forwarding from [::1]:10027 -> 10027
Handling connection for 10027

From the debug agent:
2019/12/16 14:17:26 Listening on <IP_ADDRESS>:10027
2019/12/16 14:17:28 receive debug request
2019/12/16 14:17:28 http: superfluous response.WriteHeader call from k8s.io/apimachinery/pkg/util/httpstream/spdy.responseUpgrader.UpgradeResponse (upgrade.go:91)

I think the problem might be caused by the remote kube-apiserver couldn't  response kubeletremote.ServeAttach() request correctly? could you please check your kubelet status of your target container host?

Thanks for the input.   The kubelet seems fine.    After digging into this more I think I see what is going on.   The container runtime used in my environment is 'remote' as opposed to 'docker'.  ( See this in the command line args passed to kubelet. )
However at least at the moment kubectl-debug seems to only work with kubelets where the docker runtime is in use.   I can say this because I see that the code

assumes the containers in the target pod will have ids of the form docker://
( In my case they actually have the form containerd:// )
assumes that it can create the debug container using a docker client the end point unix:///var/run/docker.sock.  ( In my case nothing is listening on that socket )

@dee0 Yes, docker is the only supported runtime right now.😔

assumes the containers in the target pod will have ids of the form docker:// ( In my case they actually have the form containerd:// )

The agent does not assume the container id is started with docker://, but it does check the container id, and report an error if the id is not started with docker://, because other runtimes have not been supported.

assumes that it can create the debug container using a docker client the end point unix:///var/run/docker.sock. ( In my case nothing is listening on that socket )

Actually, the docker endpoint is configurable:
https://github.com/aylei/kubectl-debug/blob/1fd0bac15750d42c82b70376204d04142ca3583f/pkg/agent/config.go#L21

Thanks for confirming that docker is required.    I don't own the kubernetes deployment so I cannot change it to use a different runtime.  ( Oh, and docker isn't even installed in these environments )
From what I have seen in the code so far, it looks like adding support for the containerd runtime wouldn't be too hard.   Do you agree?

Fwiw I have containerd support pretty much working.   I expect I'll open a pull request within a couple of days.


Add a way to generate PostMan json from request

It can be very useful to be able to export all the requests and be able to import it on a new collection in Postman.
How do you see this feature in details ?

On each request you will have an extension method "AsPostManCollection(string filePath)".
:)


onepass libraries missing?

Thank you for a wonderful project. I'm building a Django integration for it.
The README currently points to the onepass libraries as a faster option, but they don't exist as advertised in the onepass library, e.g. https://pypi.org/project/minify-html-onepass/ is a 404.
Are they still pending release?
Thanks!

Yep, the library is not included by PyO3 when compiling.

I've implemented the onepass variant for Python as of version 0.9.2. Let me know how it goes if you try it out.

Thanks, I have made an issue to add support to my Django package: https://github.com/adamchainz/django-minify-html/issues/51


Add Bolly Life Provider to support more translation/versions

update readme
add a sub module for bible book name to number
[fact] move main.ts to make root folder cleaner
[fact] make provider abstract
[fact] clean up
[fact] update picture location
[feat] add bolly life provider
[feat] add bolly life provider through new bff of bible api

related issues:

https://github.com/tim-hub/obsidian-bible-reference/issues/12
https://github.com/tim-hub/obsidian-bible-reference/issues/18

related discussion

https://github.com/tim-hub/obsidian-bible-reference/discussions/21


Support tags color in TagsInput

Description
This PR introduces two new feature for TagsInput component, the ->color() method (HasColor Trait) to change the color of the tags/badges and the method ->inlineInput() to make the input inline, after the badges/tags.

[X] Visual changes (if any) are shown using screenshots/recordings of before and after.

Before:

After:

Code style

[X] composer cs command has been run.

Testing

[X] Changes have been tested.

Documentation

[X] Documentation is up-to-date.

I'm leaning towards saying no to the inline method, but I'll let Zep have the final call

The tags are stored in Alpine on the frontend so we should not support per-tag colors ATM.

Thanks for this PR, @WilgnerFSDev!
Could you revert the "inline" changes? I think there's more edge cases to it that need to be handled, so let's hold off on that part.
@danharrin, regarding the color API. Wouldn't it be better to support per-tag colors as we do on text columns and entries?

Sure, is done.
So for now, I will create a custom field to meet the client's requirement because the TagsInput (default) in the repeater takes up too much space.
hank you for your time @danharrin and @zepfietje


Drop support for Python 2.6

Python 2.6 is now EOL and is no longer supported by the Python core team.
Related to #99 , coverall doesn't support Python 2.6.
For these reasons I want to drop support for Python 2.6.

Changes Unknown when pulling 24c6e8344a24adc3fa47164df4d0c5e55e49cf67 on obsolete-py26 into ** on develop**.

Changes Unknown when pulling 24c6e8344a24adc3fa47164df4d0c5e55e49cf67 on obsolete-py26 into ** on develop**.

LGTM 👍


Tests and cleanups

Codecov Report

Merging #5 (166f095) into master (728cca2) will increase coverage by 0.19%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##           master       #5      +/-   ##
==========================================
+ Coverage   68.50%   68.70%   +0.19%
==========================================
  Files           1        1
  Lines         127      131       +4
==========================================
+ Hits           87       90       +3
- Misses         40       41       +1

Impacted Files
Coverage Δ

src/PhaseSlopeIndex.jl
68.70% <80.00%> (+0.19%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 728cca2...166f095. Read the comment docs.


Add telemetry for alizer binary downloads

Which area/kind this issue is related to?

/area alizer
/area releng
Issue Description

Once we have binary downloads available, metrics should be added to track the downloads.

Re-opening as it is still a requirement for alizer


[BUG] 'send-message-file' command is slow.

Describe the bug
I run the following command on the loopback endpoint A and monitored the loopback endpoint B.
midi endpoint send-message-file Test_ChMsg.txt --pause 0
I have attached the file used for this test(Test_ChMsg.txt).
It contains about 15,000 MIDI 2.0 channel voice messages.
Since the '--pause 0' option was used, all messages are expected to be sent instantly.
However, it took about one hour to complete sending all messages.
To Reproduce
Run the following command on the loopback endpoint with the attached "Test_ChMsg.txt".
midi endpoint send-message-file Test_ChMsg.txt --pause 0
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
At first, the message interval is not bad, but it takes 2-3 msec even with '--pause 0' option.

Then the interval is getting longer and longer and at the end, it will be about 500 msec.
As a result, it takes an hour to complete sending all messages.

If I send 15,000 messages with the 'send-messge' command like below, it takes only 100 msec.

Installer Name or Version

DP4 Daily3 (Windows.MIDI.Services.Developer.Preview.4.x<IP_ADDRESS>18.1850.exe)

Desktop (please complete the following information):

OS: Windows 11 23H2 build 26020.1000

Device information, if this is with an external MIDI device:

Diagnostics Loopback endpoint.

Application Information

midi.exe console app.

Thank you for this detailed test and results @m-komo!

Thanks. I see what is happening here. This is using the older table display code. I hadn't yet updated it to use what I created for endpoint monitoring. I will add this to my backlog to bring it up to performance with regular send-message code.

Fixed in the official DP4


PLAT-77085: Remove data-spotlight-* props from Scrollable

Checklist

[x] I have read and understand the contribution guide

[ ] A CHANGELOG entry is included

[ ] At least one test case is included for this feature or bug fix

[x] Documentation was added or is not needed

[ ] This is an API breaking change

Issue Resolved / Feature Added
Turning on data-spotlight-container-disabled in qa-sampler still allows touch devices to focus elements. The problem is two-fold. 1) Touch hold will focus the element on touch devices and 2) SpotlightContainerDecorator handles the focus event and prevents by checking spotlightDisabled prop, not data-spotlight-container-disabled attribute.
Resolution

Switch data-spotlight-container-disabled to spotlightDisabled in the sampler

Technically this would be enough to resolve the immediate issue, but also cleaned up the structure so that it respects SpotlightContainerDecorator props properly.

Removed data-spotlight-* props from Scrollable

Additional Considerations

When digging into as to why it was structured this way, I could only find this comment.
This change requires related tests to be updated.
As a fallback option, the simpler way to fix this issue may be to prevent focus event to propagate by checking the attribute instead of the prop. See  https://github.com/enactjs/enact/compare/develop...feature/PLAT-77085-stephen-1

Enact-DCO-1.0-Signed-off-by: Stephen Choi<EMAIL_ADDRESS>

Good catch! Both lines were supposed to be updated.
Regarding making public, I don't have any problem since moonstone/Scrollable is a private module it really doesn't matter to the public anyways. Hence no CHANGELOG.
However, moonstone/VirtualList which is public and composes moonstone/Scrollable has spotlightId as a private prop and no mention of spotlightDisabled. (https://github.com/enactjs/enact/blob/346d3344375938d6c090675ce29a67b4f8cf8673/packages/moonstone/VirtualList/VirtualListBase.js#L176)
It probably makes sense to have both props documented in VirtualList, but I'm not 100% sure. It seems a bit weird to update data-* attribute directly like we do in https://github.com/enactjs/enact/blob/346d3344375938d6c090675ce29a67b4f8cf8673/packages/moonstone/VirtualList/VirtualListBase.js#L283 and should use props instead. But it could have been done this way to bypass setState which is costly. But for the scope of this PR, I'd suggest creating a follow-up ticket.


Support for tentant-id column for multitenancy

Allow the operation to specify tenant id column in request param.
For insert set this to the incoming value
For update use in where clause
For query use in where clause
For delete use in where clause
Tenant id parameter will be checked in header - no check done on any request parameter. The name is fixed X-TENANT-ID

After careful consideration decided that this is not a required feature.

Conditions can be specified in the filter
Tenant id can be inserted as part of the payload.


[zh] Translate kubelet-tls-bootstrapping

This page, to my surprise, was not localized.

it feels like reading a new post when review your PR, because no gap here~

Yes. This page was NOT translated before.

it feels like reading a new post when review your PR, because no gap here~

Yes. This page was NOT translated before.

/lgtm


support more architectures, move to separate folder structure

and another one. this one might be a bit tricky, as it introduces filesystem changes, like described under Assumptions in the readme.
i'm leaving versioned binaries under /opt/ and link the version defined in the playbook into /usr/local/bin which i believe is the canonical location for binaries installed like this.
in a way, it's a breaking change, cause the role now does not care about preexisting installations of either restic or autorestic under /usr/bin. but to be honest i am not sure where the line is on how much a role should care about previous state on a box.
other details:

i've introduced autorestic_architecture as an override. i got a use case in which one of my machines returns mips for uname -m but is actually a mipsle, so i had to somehow circumvent that and make it obvious.
i've listed the precompiled binary locations under dependencies, because that is what they are
i removed the mode setting of the downloaded files to 0755 because i don't think this is necessary
i dabbled with unarchive but that module can't rename extracted files, and does not play nicely with bzip2 so i reverted that to your approach. the versioned files however give us at least a chance to have idempotency with the creates directive.

hope this is clear enough

anything else amiss?

Hey @whysthatso - I made a couple of changes. I made it so autorestic_install_directory and autorestic_restic_install_directory attributes such as owner, group and mode are configurable but keeps the defaults as before.
Let me know what you think 🙂 - Also one other thing, is overriding the ansible_architecture safe? What happens if a user runs this role and then runs a different role after which relies on ansible_architecture, but we've modified it, couldn't this cause issues?
Thanks 👍🏻

@whysthatso - To address concern above, I've added an additional task which gathers facts again to reset ansible_architecture when autorestic_architecture is defined.

@whysthatso Thank you for your contribution! 👍🏻 😃

@dbrennand thank you so much for finishing this up, and sorry for having abandoned it. life got in the way once again...
i think you found good solutions. regarding leaving around old binaries, and then linking against the version du jour, that's just an attitude :D i think if it is considered that a user wants to downgrade and can easily get older versions from a remote source, it's not a problem at all to overwrite them.


Duplicate paragraph

Under prerequisites the first paragraph is duplicated.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 94205933-3124-b7ee-c1f1-cd9cc44e439d
Version Independent ID: c7c22007-3d50-f273-53a1-0cafd6da0737
Content: Manage guest access with Azure AD access reviews
Content Source: articles/active-directory/active-directory-azure-ad-controls-manage-guest-access-with-access-reviews.md
Service: active-directory
Product: unspecified
GitHub Login: @markwahl-msft
Microsoft Alias: billmath

@erikkross Thanks for your feedback! We will investigate and update as appropriate.

@erikkross The PR for the fix has been created and it will be merged soon. Thanks again for pointing this out, I am closing the issue based on this update, please let us know if there is something else that we can help you with.


Update Chromium versions for javascript.builtins.Intl.supportedValuesOf

17319

 Quality gate: NA
Details

 Quality gate: NA
Details

 Quality gate: NA
Details

 Quality gate: NA
Details


Close connection in JobStoreCMT

Hello, guys.
I have looked through code, and found one strange algorithm in JobStoreCMT.
In the method executeInLock You get connection, execute callback and and finally cleanup connection. In the method cleanupConnection You restore connection attributes and close connection. But, If I understand correct, JobStoreCMT can share the same connection with client code. Should connection be closed, If some one are going to use it? Is it bug or no?

The connection is expected to come from a DataSource, and in such cases, calling close() on the connection simply returns it to the DataSource, it does not actually close the socket connection to the db.

I've ran into this issue when using JobStoreCMT which takes connection from hibernate+c3p0+H2 SessionFactory.
Although there is a PoolBackedDataSource that gives connection away - commit() cannot be called on it after close() was called. So this seems to be implementation dependent.


Implemented operator 'LIKE' for collections

What does this PR do?
A brief description of the change being made with this pull request.
Implemented LIKE operator for collection properties
Motivation
What inspired you to submit this pull request?
Related issues
A list of issues either fixed, containing architectural discussions, otherwise relevant
for this Pull Request.
Additional Notes
Anything else we should know when reviewing?
Checklist
[] I have run the build using mvn clean package command
[] My unit tests cover both failure and success scenarios

Hi, @leostryuk. Could you sign your commit (for the sake of security) and throw an exception in case the operator is unable to process the passed-in data type?

I was reverting unsigned commits


import error

Using numpy 1.15.0 and last dragnet version I can't import dragnet from python3:
Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dragnet
/usr/lib/python3.5/importlib/_bootstrap.py:222: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  return f(*args, **kwds)
/usr/lib/python3.5/importlib/_bootstrap.py:222: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  return f(*args, **kwds)
/usr/lib/python3.5/importlib/_bootstrap.py:222: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  return f(*args, **kwds)
/usr/lib/python3.5/importlib/_bootstrap.py:222: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
  return f(*args, **kwds)
/usr/local/lib/python3.5/dist-packages/sklearn/ensemble/weight_boosting.py:29: DeprecationWarning: numpy.core.umath_tests is an internal NumPy module and should not be imported. It will be removed in a future NumPy release.
  from numpy.core.umath_tests import inner1d

neither from python2:
Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dragnet import features
 File "/usr/local/lib/python2.7/dist-packages/dragnet/features/__init__.py", line 4, in <module>
   from dragnet.features.readability import ReadabilityFeatures
 File "/usr/local/lib/python2.7/dist-packages/dragnet/features/readability.py", line 3, in <module>
   from ._readability import make_readability_features
 File "dragnet/features/_readability.pyx", line 3, in init dragnet.features._readability
 File "__init__.pxd", line 1000, in numpy.import_array
ImportError: numpy.core.multiarray failed to import

with fresh environments I'm not able to reproduce these errors :/
I do get the sklearn DeprecationWarning, but that's it.
Are you still running into this, @fedecaccia ?
FWIW, here are my pip list outputs:
For Python 3.6:
Package          Version
---------------- ---------
appnope          0.1.0
backcall         0.1.0
certifi          2018.8.24
Cython           0.28.5
decorator        4.3.0
dragnet          2.0.3
ftfy             4.4.3
html5lib         1.0.1
ipython          7.0.1
ipython-genutils 0.2.0
jedi             0.13.1
lxml             4.2.5
numpy            1.15.2
parso            0.3.1
pexpect          4.6.0
pickleshare      0.7.5
pip              18.1
prompt-toolkit   2.0.5
ptyprocess       0.6.0
Pygments         2.2.0
scikit-learn     0.19.2
scipy            1.1.0
setuptools       40.4.3
simplegeneric    0.8.1
six              1.11.0
traitlets        4.3.2
wcwidth          0.1.7
webencodings     0.5.1
wheel            0.32.1

For Python 2.7:
Package                            Version
---------------------------------- ---------
appnope                            0.1.0
backports.shutil-get-terminal-size 1.0.0
certifi                            2018.8.24
Cython                             0.28.5
decorator                          4.3.0
dragnet                            2.0.3
enum34                             1.1.6
ftfy                               4.4.3
html5lib                           1.0.1
ipython                            5.8.0
ipython-genutils                   0.2.0
lxml                               4.2.5
numpy                              1.15.2
pathlib2                           2.3.2
pexpect                            4.6.0
pickleshare                        0.7.5
pip                                18.1
prompt-toolkit                     1.0.15
ptyprocess                         0.6.0
Pygments                           2.2.0
scandir                            1.1
scikit-learn                       0.19.2
scipy                              1.1.0
setuptools                         40.4.3
simplegeneric                      0.8.1
six                                1.11.0
traitlets                          4.3.2
wcwidth                            0.1.7
webencodings                       0.5.1
wheel                              0.32.1

Hello! FWIW I also get this error in a Python 2 environment:
Python 2.7.10 (default, Aug 17 2018, 17:41:52)
Type "copyright", "credits" or "license" for more information.

IPython 4.0.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from dragnet import features
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-3705de598490> in <module>()
----> 1 from dragnet import features

/Users/burtondewilde/.pants.d/python-setup/chroots/6a8bbfd8688faa57326b41c0ae9cdf9cbd977473/.deps/dragnet-2.0.3-cp27-cp27m-macosx_10_13_x86_64.whl/dragnet/__init__.py in <module>()
      1 from dragnet.blocks import Blockifier, PartialBlock, BlockifyError
----> 2 from dragnet import features
      3 from dragnet.extractor import Extractor
      4 from dragnet.util import load_pickled_model
      5

/Users/burtondewilde/.pants.d/python-setup/chroots/6a8bbfd8688faa57326b41c0ae9cdf9cbd977473/.deps/dragnet-2.0.3-cp27-cp27m-macosx_10_13_x86_64.whl/dragnet/features/__init__.py in <module>()
      2 from dragnet.features.css import CSSFeatures
      3 from dragnet.features.kohlschuetter import KohlschuetterFeatures
----> 4 from dragnet.features.readability import ReadabilityFeatures
      5 from dragnet.features.weninger import WeningerFeatures, ClusteredWeningerFeatures
      6

/Users/burtondewilde/.pants.d/python-setup/chroots/6a8bbfd8688faa57326b41c0ae9cdf9cbd977473/.deps/dragnet-2.0.3-cp27-cp27m-macosx_10_13_x86_64.whl/dragnet/features/readability.py in <module>()
      1 from sklearn.base import BaseEstimator, TransformerMixin
      2
----> 3 from ._readability import make_readability_features
      4
      5

dragnet/features/_readability.pyx in init dragnet.features._readability()

__init__.pxd in numpy.import_array()

ImportError: numpy.core.multiarray failed to import

In [2]: import numpy as np

In [3]: np.__version__
Out[3]: '1.13.3'

Unfortunately, this is a production environment over which I have little control. Locally, I can create a fresh environment for dragnet, which imports with a warning but no error:
Python 2.7.15 (default, Jun 28 2018, 10:19:24)
Type "copyright", "credits" or "license" for more information.

IPython 5.8.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from dragnet import features
/Users/burtondewilde/.pyenv/versions/2.7.15/envs/dragnet-test/lib/python2.7/site-packages/sklearn/ensemble/weight_boosting.py:29: DeprecationWarning: numpy.core.umath_tests is an internal NumPy module and should not be imported. It will be removed in a future NumPy release.
  from numpy.core.umath_tests import inner1d

In [2]: import numpy as np

In [3]: np.__version__
Out[3]: '1.15.4'

If I manually downgrade the version of numpy to that used in the production environment (1.13.3), I provoke that same error locally. Does dragnet need to set a lower bound on numpy version in requirements.txt?

I can import dragnet and tests pass for me on numpy 0.13.3 as well :/
Here's what I get in ipython:
Python 2.7.15 | packaged by conda-forge | (default, Jul 27 2018, 10:23:44)
Type "copyright", "credits" or "license" for more information.

IPython 5.8.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from dragnet import features

In [2]: import numpy as np

In [3]: np.__version__
Out[3]: '1.13.3'

@bdewilde would you mind sharing a pip list here so I can make sure I'm using the same packages as you? Also, what OS are you running this on?

Hi @pakelley , I just went through the process once more in a fresh environment and reproduced the result — you had me doubting myself! 😅
I'm using Python 2.7.15 on macOS. Here are the packages in this virtualenv:
(dragnet-test) ~$ pip list
Package      Version
------------ -------
Cython       0.29
dragnet      2.0.3
ftfy         4.4.3
html5lib     1.0.1
lxml         4.2.5
numpy        1.13.3
pip          18.1
scikit-learn 0.19.2
scipy        1.1.0
setuptools   40.5.0
six          1.11.0
wcwidth      0.1.7
webencodings 0.5.1
wheel        0.32.2


"Error: 304" after pressing "Attach/Detach" button

OS: Windows 10 - 64bit
Reproduction steps:

Start Shadowverse
Start ShadowWatcher.exe
Click on "Attach/Detach" button => error shows up (check screenshot)

Any ideas how to fix this? Probably something related to injector?
No anti-virus on PC, Windows Defender turned off.
Tried running ShadowWatcher and Shadowverse as admin and normal way - both cases shows same error.

Cheers!

I also heard the same error from other people. But I cannot reproduce the error, so I have no idea to solve this. I want to know whether the older version works well.
Here is the source code of SVInjector. I tried to update the dependencies to solve this yesterday, but I don't know if it works.
https://bitbucket.org/Gizeta_sf/svinjector/src/9cd1f83db0695a0edee97209d673c64744d1c67d/SVInjector/main.cpp?at=master&fileviewer=file-view-default#main.cpp-70
Error 304 means that the mono runtime fails to load Observer.dll.
I guess the dependencies of Observer.dll may be broken or not compatible with mono .net runtime.
But, I don't meet this error on my PC.
I would appreciate that if someone could fix it or tell me more details.

It doesn't work on both versions of injector (old and new one) if it helps somehow. Maybe some libraries are missing on PC (for example too old version of .NET framework or something like that). Just guessing. Can't help much in this case.


QQWry db stopped updating publicly

It looks like CZ88 has been commercialized, and no longer provide publicly available offline database.

To get the latest qqwrt.dat, you need to follow their WeChat Official Accounts, then download a zip file whose name has a random prefix, then install a windows version software, the database file was stored in the installation directory.

https://m.aliyun.com/market/detail?productCode=cmapi00046276


Split the cicd workflow into stage and prod workflows

Split up the cicd workflow so that a PR does not show a bunch of
irrelevant skipped steps on it. The new stage workflow is triggered on
a pull request and can be called from another workflow. The prod
workflow is triggered on a push to main, calls the stage workflow
and does the deployment to prod.
Docs: https://docs.github.com/en/actions/using-workflows/reusing-workflows

I did a test of temporarily modifying prod.yaml to be run on this branch as well as main and disabled the actual prod deployment jobs just to test that the workflow calling was working ok and the secrets were accessible to the jobs. All looks good, so undrafting now.