Add -is $null and -isnot $null support to operators and Where-Object

PR Summary
Fix #10656.
PR Context
Mads Torgersen rightly pointed out at this point in a .NET Conf 2019 demonstration he delivered that testing for $null using -is is more accurate than testing for $null using -eq.
PowerShell would benefit from having the same support, such that users can check if an object is or is not null by invoking $x -is $null or $x -isnot $null, or Where-Object Property -is $null or Where-Object Property -isnot $null, for two reasons:

Code written this way is very discriptive, and matches the way we speak about what is actually happening when we test for $null.
More importantly, this allows for comparisons of any object to $null, including collections. Before this change, if you want to test whether or not a collection is $null, you have to place the $null on the left-hand side of the operator, which is not possible in Where-Object. With this change in place, you can simply keep $null on the right-hand side of the -is and -isnot operators, regardless of the type of object on the left-hand side that you are comparing to $null.

Here are the new patterns that will be supported once this PR is merged:
$x -is $null
$y -isnot $null
$collection | where Property -is $null
$collection | where Property -isnot $null

Note that -is $null will return $true if the left hand side is $null, [DBNull]::Value, [NullString]::Value, or [System.Management.Automation.Internal.AutomationNull]::Value.
Also note that this only works when you use a null literal on the right-hand side of -is and -isnot, regardless of whether you use the operators or Where-Object. The explicit check for a null literal is necessary to prevent the use of other variables or subexpressions on the right-hand side.
PR Checklist

[X] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[X] Summarized changes
[X] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[X] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[ ] Not Applicable
OR
[X] Documentation needed

[X] Issue filed: https://github.com/MicrosoftDocs/PowerShell-Docs/issues/4890

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[X] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[X] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[x] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

@KirkMunro should we provide support here also for the null-like values [dbnull]::Value and [NullString]::Value (or indeed possibly even [AutomationNull]::Value?)
Given the decisions in #9561, I would say that we probably should have this operation also treat the null-representatives as null via LanguagePrimitives.IsNullLike(value). If distinction is required, $value -is [dbnull] will still be functional to make the distinction, but in most cases we don't need that distinction, I would think?
/cc @daxian-dbw

@PoshChan Please restart macos

@KirkMunro, successfully started retry of PowerShell-CI-macOS

@vexx32 So you're proposing this update invoke LanguagePrimitives.IsNullLike instead of just checking if the lhs is null? That seems to make sense to me. Before I update that, it would be good to get @daxian-dbw's opinion to be sure that's the desired/expected behavior.
Aside: LanguagePrimitives.IsNullLike should probably check IsNull first, before checking DBNull.Value or NullString.Value, right, since the most common matches in PowerShell would be null or AutomationNull.Value. I'd also put NullString.Value before DBNull.Value. That way the comparisons are in order from most likely to least likely.

@KirkMunro yep, that's the conclusion we came to in #10422 which is currently stalled pending a question on how we determine equality and what matters to it when using -ge/-le instead of -eq; the same change you recommend is made there, but that PR is yet to be merged.

I'd expect consistency with -eq for NullDB and etc.

@iSazonov Are you're suggesting that we should support [NullString]::Value, [DBNull]::Value and [AutomationNull]::Value on the right-hand side of -is as well? Because there is a slight difference between $null and these values.
When using -eq, to test for equality with these other null values, you need to use the singleton returned from the Value static member. When using -is, however, it is more natural and accurate to use the object type on the right-hand side. For example:
$x = [AutomationNull]::Value
$x -is [AutomationNull] # returns true
$x -is [AutomationNull]::Value # returns an error because the right-hand side is not a type or null

I believe the above behavior is desirable and expected.

@KirkMunro i would that that if given the type itself to test, it would follow current behaviour, and if given a null singleton value, it should follow the IsNullLike pattern. Reason being is that $nullLike -eq $null will return true for all of them, and it would a point of confusion for this semantic to differ here, I think.

Using the -is operator is the most accurate and correct way to test for $null, because it avoids running user code (operator overloads), and simply checks if a value is null. That's why this PR was implemented. It also promotes better code because it keeps the operand on the right-hand side (collection unwrapping does not come into play with -is).
The other nulls already work using -is, with their types.
Your question @vexx32 highlights exactly why I think we shouldn't support [AutomationNull]::Value and the other non-$null nulls on the right-hand side of -is: because it opens a can of worms. If we're going to support one value on the right-hand side of -is, then why not support all values on the right-hand side of -is? i.e. After checking for $null or instances of Type, why not fall back to an equality comparison?
The answer to that question is simple: intent/ambiguity.
-is $null is not a test for equality. It's a check to see if something is null.
-is [string] is not a test for equality either. It's a test to see if something is a string.
But what about the following syntax:
is 'string' is a test to see if something is a string. The 'string' string gets converted into a type.
If you want to fall back to -eq when the right-hand side is not null and not a type, suddenly you have a consistency issue. When the right-hand side is a string, which is supported today, and when that string is also a type name are you checking if something is of type string or if something is a string that contains the value "string"?
By forcing tests for value for equality to be done using the -eq or -neq operators, the intent is clear and unambiguous.

@vexx32 To your point, I think it makes sense when checking for -is $null to also match on the other null types. e.g. [AutomationNull]::value -is $null should return true IMHO. That allows scripters to avoid thinking about which null they are dealing with. If they want to test for a specific null other than $null, they can always use the type (i.e. [AutomationNull], [DBNull], etc.).

Is the final proposal then that:

The RHS of -is must be either a type object or $null
Other RHS expressions, including DBNull, AutomationNull and NullString, are errors
When the RHS is a type, it checks the LHS expression for being that type (established behaviour)
When the RHS is $null, it checks the LHS for being null-like (null, DBNull, AutomationNull, NullString) (new behaviour)

@rjmholt That's almost 100% correct.

Other RHS expressions, including DBNull, AutomationNull and NullString, are errors

[DBNull]::Value, [NullString]::Value, and [S.M.A.Internal.AutomationNull]::Value on the right-hand side are errors, just like any non-null, non-type value. The [DBNull], [NullString], and [AutomationNull] types are supported on the right-hand side though, because they are types.
The other statements you listed were accurate, and the code was just updated to support that proposal.

If they want to test for a specific null other than $null, they can always use the type (i.e. [AutomationNull], [DBNull], etc.).

For consistency we could define [Null] type.
It is not clear why do we follow C# pattern.

@KirkMunro sorry, was using the type name as a shorthand for the singleton value.
Ok, that sounds good to me. I certainly agree that not allowing the alt-null values on the RHS is the way to go.

This is pretty much ready to go, there are two interesting questions worth thinking out loud:
Consider this:
$w = $null
$x = [System.Management.Automation.Internal.AutomationNull]::Value
$y = [DBNull]::Value
$z = [NullString]::Value

I would expect with those variables that the following would all be true:
$w -is $null and $x -is $null -and $y -is $null -and $z -is $null
$x -is [System.Management.Automation.Internal.AutomationNull]
$y -is [DBNull]
$z -is [NullString]

Are we agreed on that? All nulls are recognized as null using -is $null, but the "special" nulls can also be identified using their types.
At the moment, the test for -is [S.M.A.Internal.AutomationNull] fails because it needs to be special cased in order for it to work (I noticed this in my testing, and I have implemented that special case locally).
We do expect $x -is [System.Management.Automation.Internal.AutomationNull] to return true though, right? Because it would be very clearly incorrect if it returned false. I think this is the right thing to do, and I think it would be useful to be able to identify AutomationNull in PowerShell this way for the few cases where it does come up.
Also, by leveraging IsNullLike, we lose the ability to uniquely distinguish an actual null from the other null values, unless we do this:
$w -is $null -and
$w -isnot [System.Management.Automation.Internal.AutomationNull] -and
$w -isnot [DBNull] -and
$w -isnot [NullString]

Does that matter? Probably not, but I wanted to put the question out there.

@iSazonov Personally I strongly prefer not muddying the waters for the non-developer scripters out there by having a [Null] type in addition to $null. I think it adds little value, and it is much easier for folks to just use $null in all cases when they care about whether something is or is not some form of $null.

@KirkMunro actually, there already is Null type. It's hiding in LanguagePrimitives, if I recall correctly, and is used for some of its internal bits and pieces (it takes the place of a Type argument when the passed value is null, for example).
For the purposes of being able to distinguish true $null from the others, end users do have access to LanguagePrimitives.IsNull(). However, this by design does not distinguish between AutomationNull and true null. There isn't supposed to be a difference in PowerShell, and there's not usually a meaningful reason or need to distinguish null and AutomationNull.
If there is such a need, we could potentially expose the [Null] type from LanguagePrimitives with its own type accelerator (we could have typecast operations behave the same as with [void] for example) and have it be recognised by -is and -isnot.
But given we do already have access to IsNull() from within PowerShell there may not be a pressing need?

I've changed this PR to WIP, pending the merge of #10769 -- that PR is required so that internally within the IsNullLike method that this PR uses, we compare against null using is null instead of == null. Once that PR is merged I will change this back to ready for merge.

Also, regarding [S.M.A.Internal.AutomationNull] and the fact that you can't test for it by using -is [System.Management.Automation.Internal.AutomationNull], users can test for automation null once these changes are merged using something like the following:
$aNull = [System.Management.Automation.Internal.AutomationNull]::Value
# How to check if $aNull is AutomationNull:
$aNull -is $null -and $aNull -is [PSObject]

If we prefer, I can make $aNull -is [System.Management.Automation.Internal.AutomationNull] return true as well (I've worked out the code locally for that and stashed it), but technically that's not true because [S.M.A.Internal.AutomationNull] is a static class and [S.M.A.Internal.AutomationNull]::Value is actually a singleton naked PSObject in PowerShell. Although when we get into a technical discussion, by making [DBNull]::Value -is $null return true, we're technically lying there as well because it is not null -- it's an instance of [DBNull]. The same holds true for [NullString]::value -is $null.
I can't help but wonder which of these approaches would be better:

To put a stake in the ground that -is doesn't lie, period, in which case this PR can simply add support for -is $null and make that only return true if the left-hand side is actually null.

To lie for the sake of much easier scripting, allowing any null-like instance to be identified as $null, which I added support for based on @vexx32's comments.

If we feel the latter is better, would it also be better for scripters if they could identify what PowerShell considers to be [S.M.A.Internal.AutomationNull] for those rare cases where they are troubleshooting something and need see if that's what they're really dealing with by allowing it to be identified using -is [System.Management.Automation.Internal.AutomationNull]?

This issue has changes that could potentially change syntax. Please consider adding this feature to EditorSyntax which is used for syntax highlighting in GitHub, Visual Studio Code, Atom, Sublime Text, and many more locations.
Consistent syntax highlighting is very important for the language and a feature isn't "complete" until syntax highlighting is what is expected.
If you can't contribute to EditorSyntax, at least open an issue to track the work - however, please note, that no one is actively working on the repo and so the work will likely not get done in a timely manner.
We hope that you consider contributing to EditorSyntax.
(note this is copy/pasted text for any change that looks like it could impact EditorSyntax - and will be a bot in the future)

@TylerLeonhardt Can you explain how this impacts EditorSyntax in a non-copy/paste way? This doesn't add new keywords. It just modifies what is supported on the right-hand side of the -is/-isnot operators, allowing $null in addition to a type name. Given that is the case, it doesn't seem to me that this impacts EditorSyntax at all. Please confirm.

Yep you're right. Missed that detail. Since you're not changing syntax, EditorSyntax is unaffected. Thanks!

All previous discussions and confusion around AutomationNull have been resolved at this point, and after determining that this PR is not dependent on #10769 (it just gives a slight performance boost to comparisons against $null), this PR is good to go.

When the RHS is $null, it checks the LHS for being null-like

Please reconsider this decision:
The -is operator is about unambiguous type testing, and treating all null-like values the same in this context takes away the ability to test for $null specifically, which you could previously do with $null -eq ..., but which will no longer work unambiguously after https://github.com/PowerShell/PowerShell/pull/10422 is merged.
I propose the following division of labor:

-is $null is only true for $null specifically.

null-like values can be tested for via their respective types (-is [DbNull], ...), which already works except for AutomationNull, unfortunately.

Use $null -eq ... for a catch-all test for all null-like values.

@mklement0 I suppose that really depends on whether making the distinction has significant value.
Are there cases where making the distinction is valuable, to the point that slightly more unusual tests are unwarranted? Even with this change, you can test for true null with $null -isnot [PSObject] and a few other expressions.
However, keep in mind that we already treat null equivalently to AutomationNull.Value in all conversion paths and binders and this would likely be no different. In light of that, I think it makes the most sense to be agnostic about the type of null we're handling. A null value is a null value, regardless of the implementation detail.

whether making the distinction has significant value.

Generally speaking:

If I explicitly test for a type, I neither want nor expect "fuzziness".

If I use -eq, I expect and typically welcome on-demand type coercions.

Therefore, -eq strikes me as the place to treat all null-like values the same, but not -is.
In particular, the distinction between $null and AutomationNull has behavioral implications (enumeration/non-enumeration in the pipeline - see https://github.com/PowerShell/PowerShell/issues/9997#issuecomment-505296556 and https://github.com/PowerShell/PowerShell/issues/9997#issuecomment-506582327), so it is important to be able to tell the difference.
And, to reiterate, that requires fixing the currently broken behavior:
# Currently broken
(& {}) -is  [System.Management.Automation.Internal.AutomationNull]  | Should -BeTrue

Arcane and/or cumbersome workarounds such as $null -isnot [PSObject] and $null -eq $v -and @($v).Count -eq 0 are unsatisfactory.

🤷♂ that seems fair enough, I suppose. Given the nature of PS's pipeline semantics though, I think it probably prudent for -is $null to at least include AutomationNull.Value; if it doesn't, I think we're only increasing confusion rather than helping, really.

I think it probably prudent for -is $null to at least include AutomationNull.Value;

Since they are not the same and - situationally - do not behave the same (which is something we cannot fix without breaking backward compatibility), they shouldn't be treated the same in the context of explicitly inspecting a value's type.
Using -is is an advanced use case - less experienced scripters may never even have to deal with types explicitly.
By contrast, people who do use -is (and -as - see #4343), coming from a world of strict typing, I think will expect precision there.
To answer the "is it null-like" question, the following tests, which do not require -is, are available:
# Strictest
if ($null -eq $obj) { ...

# Only works as expected with a scalar LHS
if ($obj -eq $null) { ...

# Loosest - also met by numerically 0 values and empty collection objects
if (-not $obj) { ...

All that said:
I can see the appeal in making ... -is $null the new idiom to test for all null-like values, because it is less awkward than $null -eq ....
I suppose as long as the explicit type tests work for the null-like types that aren't actually $null - such as ... -is [AutomationNull] - so you can discover the difference if needed, that would work.  However, you then wouldn't need get a direct "is-it-really-$null" test, but I guess the more common case would be to test for a null-like value that isn't $null.

@mklement0 I've gone back and forth on this. It's worth presenting both perspectives I've had and then letting others decide how we want to go.
For an inexperienced scripter that doesn't understand or care to understand that there are different types of null, the simplicity of having -is $null compare against $null and the other three null-like types all at once is beneficial because it hides that complexity for them.
For a more experienced scripter/developer, being able to identify a specific type of $null is also beneficial, but I believe that...:

...this is something they would typically do when troubleshooting a script, not something they would do in their script, with the possibility of some exceptions here and there where they really want to identify what type of $null they're looking at in an actual script (but I think that scenario would be very uncommon).

...more experienced scripters/developers can learn how to identify the specific types of nulls much more easily than a less experienced scripter can learn and truly understand that there are different types of nulls.

That is why I'm currently on the side of the fence that is $null should invoke LanguagePrimitives.IsNullLike internally -- it keeps things simple for the less experienced, while still allowing more experienced folks to identify a specific type of $null if and when they need to.
The following table shows how users can identify the various $null's depending on how the final PR gets implemented here:

Null type
Treat -is $null as is null
Treat -is $null as LanguagePrimitives.IsNullLike

Any
$value -is $null -or $value -is [DBNull] -or $value -is [NullString] -or ($null -eq $value -and $value -is [PSObject]) 1
$value -is $null

$null
$value -is $null
$value -is $null -and $value -isnot [DBNull] -and $value -isnot [NullString] -and $value -isnot [PSObject] 1,2

[DBNull]::Value
$value -is [DBNull]
$value -is [DBNull]

[NullString]::Value
$value -is [NullString]
$value -is [NullString]

[S.M.A.InternalAutomationNull]
$null -eq $value -and $value -is [PSObject] 1
$value -is $null -and $value -is [PSObject]` 1

1 I have a local sandbox with the necessary changes to support is [S.M.A.Internal.AutomationNull], but I held back on pushing that change into this PR because technically speaking, you cannot have an instance of AutomationNull. That said, from an end user's perspective, if you capture the results of a command that returns nothing, that thing you captured is AutomationNull, so personally I am OK with allowing that technical falsehood to be in the product. It could be considered hacky, but AutomationNull is already hacky, and we can only work with what we have.
2 In practice, scripters wouldn't need to include all of these tests, so this comparison may be much simpler than what is shown. For example, unless they're working with a database, they wouldn't need to include the test against DBNull here.

By contrast, people who do use -is (and -as - see #4343), coming from a world of strict typing, I think will expect precision there.

If that's the case, and if we think -is is really for more advanced scripters, then I could go the other way with this; however, when we talk (and likely think) about what we're doing, we naturally say to others or ourselves "if x is null", which makes me think -is $null is a great feature for less experienced scripters.

I can see the appeal in making ... -is $null the new idiom to test for all null-like values, because it is less awkward than $null -eq ....

That, plus as mentioned above, it allows Where-Object with its -is parameter to be used to compare properties that contain collections against $null, which is something that you can't do today without using the ScriptBlock parameter set.

Yeah, I think it's worth including all null-likes there. Worth mentioning that a test for "true null" should be as simple as $value -is $null -and $value -isnot [PSObject]. That will exclude all the null-like values, as they are all considered PSObjects if I recall correctly.
Thanks for the detailed breakout @KirkMunro! :blush:

they are all considered PSObjects if I recall correctly.

That is incorrect. [DBNull]::Value and [NullString]::Value are not of type PSObject, so the test for "true null" isn't as simple as you suggest. It's still not that complicated though, because DBNull and NullString may not even need to be considered, depending on what you're doing in your script.

Thanks for the detailed analysis, @KirkMunro - I now agree that making -is $null cover all null-like types is the better option.

My only - minor, in the grand scheme of things - remaining concern is with how easy it is to test for [AutomationNull]::Value:

you cannot have an instance of AutomationNull

If something like & {} returns the [AutomationNull]::Value then you do have an instance - even if it's the very same instance (singleton) every time.

so personally I am OK with allowing that technical falsehood to be in the product. It could be considered hacky, but AutomationNull is already hacky, and we can only work with what we have.

Yes, and it is the "hackiness" - the situationally different behavior - that makes me think that distinguishing $null from AutomationNull is important to facilitate.
The abstraction is out of the bag, if you will, so pretending it is $null in all cases only adds to the confusion.
While adding a LanguagePrimitives.IsAutomationNull() method is a good idea, I feel that -is [AutomationNull] should also work, to (a) make it script-friendly and (b) consistent with -is [DbNull] and -is [NullString].
As an aside: For [AutomationNull] to work in the type-name-only form, System.Management.Automation.Internal.AutomationNull would have to be added as a type accelerator.

A bit of a tangent re technical falsehoods:
Hiding certain abstractions - as long as they don't leak - can be beneficial.
For instance, what truly deserves hiding is psobject, which should only ever have been an invisible helper type that PowerShell scripters should be allowed to be blissfully unaware of - but presently cannot - see #5579
The conflation of type accelerators [psobject] and [pscustomobject] to both refer to System.Management.Automation.PSObject (see #4344) is another highly unfortunate legacy burden:
# Not only passes 1 through, which is unexpected,
# but also creates a typically-but-not-always-invisible PSObject wrapper.
1 -as [pscustomobject]

In the context of fixing #4343, that means that the following is meaningless:
[pscustomobject] @{foo=1} -as [pscustomobject] # !! meaningless - ANY type matches

That saddles us with having to use the full type name, which is the case that is currently broken ( the -is case works, however):
[pscustomobject] @{foo=1} -as [System.Management.Automation.PSCustomObject] # !! CURRENTLY BROKEN

Long story short: while [pscustomobject] @{foo=1} may technically be a PSObject, behind the scenes, the only meaningful interpretation from a scripter's perspective is to consider it a System.Management.Automation.PSCustomObject instance - that is a "lie" worth telling consistently (it is already being told with -is, but not with -as), because it is consistent with the world view that PowerShell presents.

@mklement0 while I agree the inconsistencies are unfortunate, I do not think that perpetuating the inconsistency here is valuable. We should strive to close the gap, as it were, rather than widen it, so users have a more consistent experience as development progresses.

I agree on closing the gap, but to me that (now) means:

make -is $null return $true for all null-like types.

add support for -is [AutomationNull] (and a LanguagePrimitives.IsAutomationNull method).

No inconsistency is being perpetuated there; instead, an unavoidably legacy inconsistency is made more tractable.

Agreed, that sounds like the most effective solution here. 🙂

Sorry for not reading the discussion, but I believe this is a breaking change.
Lest you think it's a harmless breaking change, consider:
try {
    "" -is $Typo
    Remove-Item -Recurse -Force stuff
} catch {}

The point in this sample - the typo returns $null. Today this code never hits the Remove-Item because of the exception.
With this change, the exception is never raised and the (possibly never run before code) is now reachable.
I think there is a non-zero chance of this affecting real world scripts and extra caution should be applied if taken (e.g. in release notes, script analyzer rules, etc.)

Does a nonexistent variable return $null or AutomationNull.Value?

@lzybkr Couldn't you make that same argument for literally any new command in PowerShell?
e.g. If I have a local module with a Get-Error command that I sometimes load, and in a script I have this:
try {
    Get-Error
    Remove-Item -Recurse -Force $dir
} catch {}

If my module is not loaded, and then I run that script on the latest build of PowerShell, where Get-Error was just added, then suddenly the Remove-Item line would execute "unexpectedly". Should we treat all new commands as potential breaking changes as well?
That's contrived, but I think your example is pretty contrived as well. Have you ever seen such code?

I think there is a non-zero chance of this affecting real world scripts and extra caution should be applied if taken (e.g. in release notes, script analyzer rules, etc.)

Also, what sort of script analyzer rules?

Does a nonexistent variable return $null or AutomationNull.Value?

$null

@KirkMunro @lzybkr I mean... is null in c# works only on that specific keyword, not on any identifier that happens to resolve to a null value.
Shouldn't we do the same thing here? Shouldn't we make it only work for specifically entering exactly  $value -is $null ? That would probably require a bit different of a change, but would make this impossible to be a breaking change. It would also reduce ambiguity significantly.

Shouldn't we do the same thing here? Shouldn't we make it only work for specifically entering exactly $value -is $null ?

Good idea. There's no point having an arbitrary value on the right-hand side, just $null or a type. I'll see what I can do.

@KirkMunro Re:

Couldn't you make that same argument for literally any new command in PowerShell?

Maybe you could make that same argument, but I think my example was less contrived. My example does combine things I've seen in the wild - typos in variable names are common, and hitting code that hasn't run before due to a previous handled error is not unheard of.
Regardless - if this only applies to the literal $null, my concerns are addressed. You can still call it a breaking change, but it is unlikely to break any real world scripts.

Figuring out how to make it work for literal $null with the -is operator was actually really easy.
What I haven't figured out yet is how to make it only work for literal $null with something like Where-Object Property -is $null.
In the former case, when the operator is compiled, it's easy to identify the literal $null. In the latter case, it's a cmdlet, which can accept any input, so it's definitely not as straightforward.

You could, I suppose, check the $MyInvocation information to determine how the cmdlet was called? Not 100% sure how that would go from a compiled cmdlet, but in PS you can examine $MyInvocation.Line to determine what was passed to each parameter and work from there.
It's hacky as hell, but it's probably one of pretty few options to make the behaviour sync up with what we'd need for the real -is operator.

If you add a property to CommandArgumentInternal, you could then pass a special internal only type if the command is Where-Object, then add a special case in Where-Object. I think it's minimal code and not too hacky.

If we actually need address real null check scenario we could introduce new operator -isnull without risk to break scripts.

@iSazonov: While that would solve the problem, it would break the one-to-one correspondence between Where-Object arguments and operators, and, conversely, I don't think we want to introduce new operators.

@mklement0 We could have the same in the cmdlet too.

@iSazonov: Sorry, I misunderstood your original comment: I thought you already were talking about the cmdlet, in the context of the difficulty of identifying a $null argument there.
I think at this point everyone is happy with supporting only a verbatim $null on the RHS of -is and -isnot and requiring any other variable reference to evaluate to an actual type - that way, no existing code should break.
Since it sounds like @lzybkr knows of a way of identify a verbatim $null  even in the Where-Object case, there should be no need to introduce additional -isnull and -isnotnull operators.

For specifics on my idea:

Add a bool property nullLiteral here
When generating code here - be sure to set this new property appropriately.
Then here you can replace the null argument with an internal type if the command is Where-Object (check the ImplementingType to make sure it's the internal command).
Then in Where-Object, add your custom logic if the type is this internal type.

@lzybkr Awesome! I had already worked my way into the first part, but this will make the rest easy. Thanks!

Then here you can replace the null argument with an internal type if the command is Where-Object (check the ImplementingType to make sure it's the internal command).

This was really helpful @lzybkr. I still have more details to work out though, to be able to support -is $null (already working), -is -value $null (not working yet), and -is -value:$null (not working yet). These seem to take different paths through the binder, so this will take a little longer while I work those paths out.

Well that was a fun exercise. :)
I've finished updating this to make both the -is/-isnot operator pair and the Where-Object -is/-isnot parameters only support $null on the right-hand side if you pass in literal null.
I also ended up going with an approach that isn't a hack at all.
As I worked through the Where-Object scenario (which was the hardest part in all of this), I realized that the only way to really make this work so that only the -Value parameter of Where-Object would accept a NullLiteral.Value instance was to add an attribute to that value. The other approach (simply checking if the command was Where-Object) caused some issues if a null literal was passed into another parameter.
By leveraging the attribute approach, I was able to mark the -Value parameter of Where-Object as a parameter that SupportsNullLiteral (that's the internal attribute name), meaning that if that parameter is passed in a null literal ($null, $global:null, $local:null, etc.), the binder will bind in a value of NullLiteral.Value (a singleton) instead so that the command can leverage its specific support for a null literal. Also, in the cmdlet implementaiton, if the parameter set is anything other than the parameter set with -is or -isnot, then any NullLiteral.Value that it receives is immediately converted back to null for normal processing.
@lzybkr Since you proposed the original set of changes, I'd really appreciate your review of the changes I landed on in the end.

By the way, before I forget, this code seems to be missing a check against !VariablePath.IsDriveQualified. I added a method below that one in this PR, and in my tests, I needed to ensure that the variable path was not drive qualified as part of the check for a null literal, so it surprised me to see this other test for a constant variable not doing the same. I haven't gone down the rabbit hole to see if/how that shows up in PowerShell though.

@daxian-dbw @SteveL-MSFT is there interest in having this available for PS7?
Personally I think it'd be a really nice addition to PS7 but I understand you guys are are very busy round about now. Just thought I'd give y'all a ping so it doesn't fall off the radar entirely. 😊 💖

This wasn't on my radar so didn't push for it before we started the preview.6 release process.  This is a great addition, but the substantial changes make my default answer to be in 7.1.

Aww. 🙁
'Twas worth a shot! 😁

This PR is still awaiting a decision or a merge.

I know this has already been discussed, but I want to register that I'm worried about a cmdlet having a different behaviour between the $null literal and another variable that is null. At runtime, my feeling is that the behaviour around a value should not depend on the syntax used to create it. I think that introduces complexity in both implementation and understanding and hurts our separations of concern between the parser and the PowerShell runtime.
This PR does great work, and I think the addition of -is $null makes sense both because of the .NET concepts at work and also to alleviate the pain of -eq $null. But I think we should design very carefully around:

-is $null vs -is $variableThatIsNull vs -is $uninstantiatedVariable -- in particular I'm not sure of anywhere else in PowerShell where accessing a variable (in $ form) is different in those three scenarios
-is $null vs Where-Object -is $null (vs Where-Object -IsNull)

I'm not sure I fully agree that the breaking change that the literal $null behaviour differentiation was intended to avoid is something we have considered to be breaking in the past (for example, a similar breakage could be claimed by defining most command names). I definitely understand the scenario there though, and I think it's a valuable point.
As I say, I think -is $null is a great addition. My concern is only that differentiating the $null literal from a null value puts a corner case into PowerShell that may not belong there.
I just want to make these points in writing so that maintainers or the @PowerShell/powershell-committee can review the design carefully.

@PowerShell/powershell-committee reviewed this, we prefer adding -isnull operator which can be used with -not instead of overloading -is which is expected to be used against types and would be a breaking change.

@SteveL-MSFT That would effectively make it the only postfix operator currently existing in PS, at least if we're still talking $object -isnull
I'd be concerned about whether that would complicate the parsing logic for operators.

We could make it a regular prefix unary operator with a -isnotnull variant, I suppose, which would also work with Where-Object (where the argument representing an operator can be placed in any position):
# Expressions
-isnull $var
-isnotnull $var

# Where-Object
... | Where-Object -isnull Foo
... | Where-Object -isnotnull Foo
... | Where-Object -isnotnull   # once #8357  gets implemented

🤔 having experimented with Where-Object's parameter sets before... I genuinely don't think that you can make that binding work without overhauling the entire parameter binder.
So that request is, at least for Where-Object, currently impossible @SteveL-MSFT @mklement0

It works with the unary -not operator, so wouldn't it work with other unary operators too?
PS> [pscustomobject] @{ foo = 0 } | Where-Object -Not foo

foo
---
  0

Note that, for the reasons mentioned, Where-Object foo -Not works too (though is obviously ill-advised).

My only objection to any of the arguments made above and to what the Committee decided on is that we should have -isnotnull instead of -not -isnull for the same reason that we have paired -eq/-ne, -is/-isnot, and so many other operators that have positive/negative comparisons associated with them.
I also feel strongly that these should be postfix operators, not prefix operators so that the expressions can be read and more easily understood, so I'm going to move forward with that approach. Part of the value with these changes is eliminating the need to put the $null value you are comparing against first, which is not intuitive for non-developers and which never reads well.
$array -isnull # Intuitive, reads exactly like what it checks

-isnull $array # Not as readable

I've never liked that PSScriptAnalyzer always complains and tells me to put my $null values first in comparisons such as $null -eq $value.

@SteveL-MSFT That would effectively make it the only postfix operator currently existing in PS, at least if we're still talking $object -isnull
I'd be concerned about whether that would overcomplicate the parsing logic for operators.

You're forgetting about the ++ and -- postfix operators. Adding additional postfix operators won't overcomplicate the parsing logic.

I can see the appeal of postfix -isnull / -isnotnull for symmetry with -is / -isnot.
However, I still think that -is $null / -isnot $null is by far preferable to having separate operators.
I definitely understand @rjmholt's concern about the special-casing of only supporting a verbatim $null as the RHS.
However, he also states:

I'm not sure I fully agree that the breaking change that the literal $null behaviour differentiation was intended to avoid is something we have considered to be breaking in the past

So my plea is:
Let us stick with -is $null / -isnot $null, irrespective of the syntactic form of the RHS, which eliminates the special casing and also simplifies the implementation.
I think there's a reasonable case to be made that the technically breaking change that this constitutes falls into Bucket 3: Unlikely Grey Area:

I've gone through about 30 pages of the top 3 matches among the 203,107 uses of the -is operator (https://github.com/search?p=20&q=language%3APowerShell+-is&type=Code) and didn't find a single instance of using a variable as the RHS, which is the scenario @lzybkr was concerned about (the vast majority of these literal RHSs were type literals (e.g, [string]), with only very few instances of strings (e.g., 'string').

Even the case of code that contains "" -is $Typo (see above) relying on a statement-terminating error strikes me as unlikely:

With $Typo accidentally evaluating to $null (as the naming suggests), the bug would likely have been discovered and fixed before deployment.
Without an explicit try / catch / $ErrorActionPreference = 'Stop', execution would continue even with the statement-terminating error (although with the proposed change an error would no longer be emitted).

Closing. See https://github.com/PowerShell/PowerShell/pull/10238#issuecomment-826091414.


Build option to add architecture suffix to tags when publishing multi-platform images

a PoC for the issue I reported here: #3518

@mpeddada1 If this looks good, I'll look through how to get this wired into the actual gradle config

You can run ./gradlew dev to do automatic formatting, Javadoc checks, and run unit tests locally.

You can run ./gradlew dev to do automatic formatting, Javadoc checks, and run unit tests locally.

Thanks!

I did some refactoring here and there.
I'll leave this to @mpeddada1 for final approval.

@mpeddada1 I'd like to open a new PR to expose this property to the gradle plugin. Any pointers to where that should land? I feel like it makes sense as  jib.to.enablePlatformTags

Hi @taer, I think exposing it as jib.to.enablePlatformTags makes sense. We also include the option to add additional tags under jib.to. TargetImageParameters could be a good place to start: https://github.com/GoogleContainerTools/jib/blob/71e3977d5b1e81b860b29c3c62c8ea807a1d2d28/jib-gradle-plugin/src/main/java/com/google/cloud/tools/jib/gradle/TargetImageParameters.java#L36


Search user by full name doesn't work

web 4.9.0
ocis(docker) 1.16.0
Steps:

Admin add file
go to share dialog
add to invite input  "Marie Curie"

Actual result: user not found

Search by mail or name - works

This seems to be a problem in glauth (or the accounts backend of glauth). Apparently filtering on "displayName" (the attribute that contains the full name does not work:
Doing the search manually gives no result as well,
 ldapsearch -x -H ldap://<IP_ADDRESS>:9125 -b dc=ocis,dc=test -D "cn=admin,dc=ocis,dc=test" -w admin '(&(objectclass=posixaccount)(displayname=mar*))'
# extended LDIF
#
# LDAPv3
# base <dc=ocis,dc=test> with scope subtree
# filter: (&(objectclass=posixaccount)(displayname=mar*))
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

I guess this issue will go away once we switch away from glauth

I re-tested it on  ownCloud Web UI 5.5.0-rc.5   Infinite Scale 0.0.0+5526d6179 Community
search user by full name Marie Skłodowska Curie works.


Query doesn't like "Asset" suffix

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
Queries with the Asset suffix throw an exception at runtime complaining about attribute order.
Steps to reproduce
Given the following queries:
 [UseDbContext(typeof(DBContext))]
 [UseProjection]
 [UseFiltering]
 [UseSorting]
 public IQueryable<DealAsset> GetDealAsset([ScopedService] DBContext context)
 {
     return context.DealAssets;
 }

 [UseDbContext(typeof(DBContext))]
 [UsePaging(IncludeTotalCount = true)]
 [UseProjection]
 [UseFiltering]
 [UseSorting]
 public IQueryable<DealAsset> GetDealAssetPaged([ScopedService] DBContext context)
 {
     return context.DealAssets;
 }

Renaming the methods to GetDealAssets and GetDealAssetsPage (Pluralize the word Asset) resolves the exception.
Relevant log output
{
  "message": "Response not successful: Received status code 500",
  "name": "ServerError",
  "statusCode": 500,
  "statusText": "",
  "bodyText": "{\"message\":\"For more details look at the \\u0060Errors\\u0060 property.\\r\\n\\r\\n1. The middleware pipeline order for the field \\u0060GQuery.dealAsset\\u0060 is invalid. Middleware order is important especially with data pipelines. The correct order of a data pipeline is as follows: UseDbContext -\\u003E UsePaging -\\u003E UseProjection -\\u003E UseFiltering -\\u003E UseSorting. You may omit any of these middleware or have other middleware in between but you need to abide by the overall order. Your order is: UseDbContext... -\\u003E UseDbContext... -\\u003E UseProjection -\\u003E UseFiltering -\\u003E UseSorting -\\u003E UseDbContext... -\\u003E UseDbContext... -\\u003E UseProjection -\\u003E UseFiltering -\\u003E UseSorting. (HotChocolate.Types.ObjectType\\u003CGraphQl.WebApi.GraphQL.GQuery\\u003E)\\r\\n\"}"
}

Additional Context?
No response
Product
Hot Chocolate
Version
12.15.2

Can you provide a repro?

Closing, for lack of a reproduction.


Resfinder download fails

Expected Behavior
The Resfinder database is downloaded and an mmseqs2 index is created.
Current Behavior
Fails at the download extraction step.
Steps to Reproduce (for bugs)
mmseqs databases Resfinder db/rf tmp
MMseqs Output (for bugs)
databases Resfinder db/rf tmp
MMseqs Version:              	13.45111
Force restart with latest tmp	false
Remove temporary files       	false
Compressed                   	0
Threads                      	48
Verbosity                    	3
--2021-10-08 14:50:24--  https://api.bitbucket.org/2.0/repositories/genomicepidemiology/resfinder_db/commit/master?fields=hash,date
Resolving api.bitbucket.org (api.bitbucket.org)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, ...
Connecting to api.bitbucket.org (api.bitbucket.org)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 89 [application/json]
Saving to: 'tmp/9391455786971071082/version'
tmp/9391455786971071082/version               100%[=================================================================================================>]      89  --.-KB/s    in 0s
2021-10-08 14:50:24 (13.7 MB/s) - 'tmp/9391455786971071082/version' saved [89/89]
--2021-10-08 14:50:24--  https://bitbucket.org/genomicepidemiology/resfinder_db/get/master.tar.gz
Resolving bitbucket.org (bitbucket.org)... <IP_ADDRESS>, 2406:da00:ff00::22c3:9b0a, 2406:da00:ff00::34cc:ea4a, ...
Connecting to bitbucket.org (bitbucket.org)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 457328 (447K) [application/x-tar-gz]
Saving to: 'tmp/9391455786971071082/master.tar.gz'
tmp/9391455786971071082/master.tar.gz         100%[=================================================================================================>] 446.61K  --.-KB/s    in 0.07s
2021-10-08 14:50:25 (5.88 MB/s) - 'tmp/9391455786971071082/master.tar.gz' saved [457328/457328]
tar: .fsa: not found in archive
createdb tmp/9391455786971071082/.fsa db/rf --compressed 0 -v 3
Input tmp/9391455786971071082/*.fsa does not exist
Error: createdb died
Context
Your Environment
Include as many relevant details about the environment you experienced the bug in.

Git commit used (The string after "MMseqs Version:" when you execute MMseqs without any parameters): h95f258a
Which MMseqs version was used (Statically-compiled, self-compiled, Homebrew, etc.): singularity container downloaded from Biocontainers
Server specifications (especially CPU support for AVX2/SSE and amount of system memory): Intel Xeon 8268, 192GB RAM
Operating system and version: RHEL 7.9

This is quite confusing. For whatever reason your system's tar doesn't use the default --wildcards option. It seems to be having --no-wildcards set as the default mode. I don't have access to RHEL, but in the centos 7.9 docker image this doesn't seem to happen.
You can probably get around this issue by doing:
TAR_OPTIONS="--wildcards" mmseqs databases Resfinder db/rf tmp

Is this a public container? I would like to know how exactly this failed to improve the script for the future.


[T2A3][T16-A1]Lai Zhiyuan

Ready for review

@zyjames
Avoid accumulating unrelated changes into a single PR.
Tip: If you are currently on branch1 and want to create a new branch2, you need to switch back to master branch before creating branch2. If not, changes in branch1 will appear in the PR created from branch2 later.
please close the PR after reviewing the comments


repairwheel 0.2.8 generating invalid ELF libraries on aarch64

Repairing an aarch64 linux wheel with an external .so dependency using repairwheel 0.2.8 is generating a bad ELF:
Python 3.12.2 (main, May 13 2024, 17:20:29) [GCC 12.2.1 20221121 (Red Hat 12.2.1-7)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from saxonche import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /.../lib/python3.12/site-packages/saxonche.cpython-312-aarch64-linux-gnu.so: ELF load command past end of file

If I set LD_LIBRARY_PATH and use the unrepaired wheel, there are no problems, so it's not a problem with the unrepaired .so, and repairing the wheel using a directly installedauditwheel 6.0.0 produces wheels that don't have this problem either.

Would you be able to share the input wheel by chance?

Brilliant, thanks. I was hoping to have a wheel I could share, but that got delayed... However, I am about to build new wheels, so I will test this out ASAP...


[bug] Metamask doesn't connect on Metamask browser on Android

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
v1.0.7
wagmi Version
v1.3.9
Current Behavior
Inside the Metamask browser on an Android phone, if the Metamask option is clicked, nothing happens. Other options, like Coinbase, Rainbow and WalletConnect work.
Metamask app version: v7.3.0.
Expected Behavior
A connection popup shows that allows me to connect and subsequently sign a message.
Steps To Reproduce

Open Metamask app on an Android phone.
Open the Metamask browser inside the Metamask app.
Go to app.playswoops.com/login
Tap on Sign in with your Wallet.
Tap on the Metamask icon.

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
The app is a Next.js app (v12). I can provide code if this works for you to checkout the configurations I have in place:
// Inside _app.tsx
const { chains, publicClient, webSocketPublicClient } = configureChains(
    [mainnet, polygon],
    [infuraProvider({ apiKey: process.env.NEXT_PUBLIC_INFURA_API_KEY }), publicProvider()]
);

const { wallets } = getDefaultWallets({
    appName: 'App',
    projectId: `${process.env.NEXT_PUBLIC_WALLET_CONNECT_PROJECT_ID}`,
    chains,
});

const connectors = connectorsForWallets([...wallets]);

const wagmiConfig = createConfig({
    connectors,
    publicClient,
    webSocketPublicClient,
    autoConnect: true,
});

const App = ({ Component, pageProps }: AppProps) => {
    return (
            <WagmiConfig config={wagmiConfig}>
                <RainbowKitProvider appInfo={{ appName: 'App, learnMoreUrl: 'https://blog.com' }}
                    modalSize="compact"
                    chains={chains}
                >
                    <Component {...pageProps} />
                </RainbowKitProvider>
            </WagmiConfig>
        );
    };
}

export default App;

Hi! How did you solve this problem?

@saguirre Are you still seeing this issue ? If not we can close this issue.
Feel free to open any issues if you find other bugs 👍


fix: resolve CI build failure

As we are already speaking about our CI pipelines, I've also noticed that some of our other pipelines are currently breaking - do we already have a plan to address this? Anything I can help with? ☺

I broke this one in particular @tobiasbueschel - but you're right, and we've been discussing this. We'll probably start rewriting soon, but need to get V4 out.

I broke this one in particular @tobiasbueschel - but you're right, and we've been discussing this. We'll probably start rewriting soon, but need to get V4 out.
And no, this is because of another failure. I was looking at that failure too, but need to spend more time on it.

@mrmckeb keen for v4 as well - happy to help with the re-write once it's the right time, thanks :)


Datenschutz anpassen.

Hallo Sebastian,
ich sehe in Deinem Profil das du aus Deutschland kommst. Würde daher in deutsch schreiben.
Erstmal danke für die tolle Software. Sehr gute Arbeit.
 Soweit so gut.
Die Extractor settings sind default in der config "Auskommentiert" (!), welches bedeutet sollte, das der Extractor deaktiviert sein sollte. Dem ist aber nicht so! Die Bilder werden an: https://api.home-gallery.org gesendet. Was dort damit passiert, ein Rätselraten ?!  -> Ein absolutes No-Go.
Es findet sich zwar ein Hinweis auf https://docs.home-gallery.org/api-server/index.html, allerdings wird nicht erwähnt, das das Übermitteln an Deinem Server default eingeschaltet ist, auch wenn der extractor explizit auskommentiert ist in der config.
Ich Bitte Dich dies zu beheben, und einen auskommentierten extractor  in der config entweder zu deaktivieren (wie erwartet), oder irgendwo einen "dicken" Hinweis zu hinterlassen, dass der extractor immer default eingeschaltet ist, und Bilder an Deiner URL leitet.
Viele Grüße Christian

Hi @ChR-iSz
thank you for finding this project and open your privacy concerns here. Since the privacy concerns is not limited to Germans I reply in English.
I understand your concerns about the public API service. The split between the "core" and the API service was born out of local requirements and comes with pro and cons. In the FAQ What data is requested from public services? describes also the functionality.
In the default configuration it is written how comments and default values are defined:
# HomeGallery configuration file
#
#
# Default configuration file is gallery.config.yml. JSON format is
# also supported (gallery.config.json)
#
# This is a comment, starting with hash tag and space ('# ')
# A default value starting with hash tag and variable ('#baseDir...')

So
#
# Extractor settings
#
#extractor:
  # Api Server is used for image similarity, object and face detection
  #apiServer:
  #  url: https://api.home-gallery.org

says by default it uses the public service.
Further for the docker compose setup it states that it uses an local API server.
Regarding the public API service https://api.home-gallery.org it is just the public docker image on my public machine. This service does not save any data. It would be the opposite of the whole idea and motivation of the project: To keep your data local and private...
Remains the question of trust: You can believe what is available as documentation and code - or you can be skeptic (which is totally fine with me). Since it is open source you can look on this Github repo, read the code, open an issue or even better create an PR at the documentation repo to improve and clarify your concerns ;-) Maybe your change in the documentation fits better than mine so far.

Erstmal danke für die tolle Software. Sehr gute Arbeit.

Thank you. I hope it can help to browse your pictures
Thanks again for your time and effort to improve this project

Hi @ChR-iSz
did my response help? Do you have further questions?

irgendwo einen "dicken" Hinweis zu hinterlassen

Where or when do you exactly expect a warning if the public API server is used? There could be several places:

On the homepage home.gallery.org
Somewhere else in the documentation
In the logs when extractor is starting

Do you have other your ideas or preferences?

Hi Sebastian,
Thank you for your answer.
A warning message in the logs would certainly be useful (info-log).
But I still suggest (of course your project, and your decision) to disable the extractor by default for your submission.
Would like to see an enable: true/false in the config file, which defaults to false. Then below that the URL where the requests are sent.
Should a user set the enabled value from false to true it should be obvious in the next line where the requests are going. Especially since the user has then consciously activated the function.
Only as a suggestion.

A warning message in the logs would certainly be useful (info-log).

This option can be done and will consider it in the near future to implement that.

But I still suggest (of course your project, and your decision) to disable the extractor by default for your submission.

For my usecases and also as project main feature the results of the API server are important. So to disable it by default would break these from the start.
IMHO due the basic project properties (open source, self hosted, project size and members) it is justifiable to read the doc in advance and get familiar with its feature set and detect the circumstances with the API server.
So the current state with public API server enabled by default for non docker version is fine with me.
It is technically possible to include the API server into the default app bundle and start and stop it when the extractor runs. Back than it was not due the lacking wasm support of tensorflowjs which is now supported.
I would prefer to go that way first than disable the API server by default. This feature needs some time to implement and PRs are welcome for it.

Only as a suggestion.

Thank you for your proposals. I hope I could highlight my desicions. Futher input, discussion and ideas are welcome

Hi @ChR-iSz
since the fresh release v1.7.0 the extractor logs a warning if the public API server is used:
You are using the public api server https://api.home-gallery.org for similar images. Please read its documentation at https://docs.home-gallery.org for privacy concerns
You are using the public api server https://api.home-gallery.org for object detection. Please read its documentation at https://docs.home-gallery.org for privacy concerns
You are using the public api server https://api.home-gallery.org for face detection. Please read its documentation at https://docs.home-gallery.org for privacy concerns

Hello. Although this topic is more then a year old .. i still have trouble with this.
I tried to disable the api with:
  apiServer:
    url:
    timeout: 30
    concurrent: 5
    disable:
      - similarDetection
      - objectDetection
      - faceDetection

.. still .. even after deleting the database .. all images get object-detection run all over the place.
I can only agree, that all features involving some online APIs should be disabled by default for privacy conserns.
Best regards Marc

Hi @cimba007

Hello. Although this topic is more then a year old .. i still have trouble with this.

Thank you for your voice and your input.

I tried to disable the api with:
  apiServer:
    url:
    timeout: 30
    concurrent: 5
    disable:
      - similarDetection
      - objectDetection
      - faceDetection

.. still .. even after deleting the database .. all images get object-detection run all over the place.

If you just delete your database the storage might still contain files from previous api server calls and will use them. The extractor should not call the api service on new files.
Your described setting is checked in an E2E Test and should work as expected and as designed.

I can only agree, that all features involving some online APIs should be disabled by default for privacy conserns.

I can understand that privacy is very important for us. Therefore there is information about the public usage of these requests in the documentation and a warning message in the logs.
For me I can ensure that the public service https://api.home-gallery.org is nothing more than the docker version from the docker hub. This fee service is there for convenience for low powered devices such Raspberry PI, for non-docker environments or quick evaluations of the gallery. Since there is no data storage for the images on the public service I leave the decision to the user to trust it or not. As you need to trust the code or not. It is your free choice.
To disable it by default is not an easy question to answer. For a docker-compose these feature detection should be enabled. Maybe for other setup not. However I see these features as convincing features to use  HomeGallery over other similar software so I would like to present these features by default. I am just loving the similarity feature which I want to present to others.
You are welcome to contribute your option as PR on the docs or the code. One valid possibility is to print a warning for a public api server usage at configuration initialization, too.
What do you think about this idea and what do you think you can contribute to it? Would you mind to improve the docs so that it meets your expectation? How about some code changes?

Thank you for your time to elaborate on this topic. I understand that this might be a feature that sets home-gallery apart from other software. I find documentation a little bit problematic as . "you could just simply ignore it". Might it be a possibility to integrate a popup on the first startup of a fresh instance and let the user decide on what feature to enable? This popup might be configured in such a way, that it is only shown incase the setting is not altered from the default setting? If the user "enables" or "disables" the feature in the config file the popup will not be shown. Its just an idea to make it more obvious. I understand that there is already a info added in the logfile but .. tbh. .. the logfile contains so many information that it might be overlooked.
For the seconds question .. "If you just delete your database the storage might still contain files from previous api server calls and will use them. The extractor should not call the api service on new files." Can you elaborate on where this information might be retained so I could test it by deleting whatever file/service might still containe this information?
Thank you for making this great tool available to the public!
Best regards

Thank you for your time to elaborate on this topic. I understand that this might be a feature that sets home-gallery apart from other software. I find documentation a little bit problematic as . "you could just simply ignore it". Might it be a possibility to integrate a popup on the first startup of a fresh instance and let the user decide on what feature to enable? This popup might be configured in such a way, that it is only shown incase the setting is not altered from the default setting? If the user "enables" or "disables" the feature in the config file the popup will not be shown. Its just an idea to make it more obvious.

Currently a popup is not easy to implement and the UI has no knowledge about the configuration. Further there is no acknowledge dialog to handle and store this state and users decision.
As suggested before I could image to add a warning while the configuration is initialized on the setup procedure (gallery run init --sources ...). There could be also an option to enable/disable the api server calls. IMHO it should be enabled by default but the docs can mention this option for privacy concerns.
As the software is open I suggest to provide this change by a PR from you or someone else. I am currently working on other features which consumes my time which is available for this spare time project. If required I can assist with guidance to implement that.

I understand that there is already a info added in the logfile but .. tbh. .. the logfile contains so many information that it might be overlooked.

Yes and no. Warnings are rare. This is a warning message and should be as clear as a log entry can be.
I think you can also check the docs and try to emphasis this privacy concerns as PR for documentation improvement.

For the seconds question .. "If you just delete your database the storage might still contain files from previous api server calls and will use them. The extractor should not call the api service on new files." Can you elaborate on where this information might be retained so I could test it by deleting whatever file/service might still containe this information?

Just add a new file and check if these files are present on the next import (also the logs should not mention anything about a call).
Or delete the file from the api server. The storage directory contains different raw output files also from the api server:
./25/d7/b73c43674fec76979c2fef7d09884c1864af-exif.json
./25/d7/b73c43674fec76979c2fef7d09884c1864af-objects.json
./25/d7/b73c43674fec76979c2fef7d09884c1864af-faces.json
./25/d7/b73c43674fec76979c2fef7d09884c1864af-image-preview-1280.jpg
./25/d7/b73c43674fec76979c2fef7d09884c1864af-image-preview-1920.jpg
./25/d7/b73c43674fec76979c2fef7d09884c1864af-image-preview-800.jpg
./25/d7/b73c43674fec76979c2fef7d09884c1864af-image-preview-320.jpg
./25/d7/b73c43674fec76979c2fef7d09884c1864af-vibrant.json
./25/d7/b73c43674fec76979c2fef7d09884c1864af-similarity-embeddings.json
./25/d7/b73c43674fec76979c2fef7d09884c1864af-image-preview-128.jpg

You can delete the *-objects.json, *-faces.json and *-similarity-embeddings.json files and rerun the (full) import. But I do not see a benefit to delete these files since the files were already transmitted to the api server and it wont change the misconfiguration from the past.

PS: Maybe something even more easy .. provide simpley two "sample" config files .. one maybe with _privacy that has some stuff preset by default. This might be an easy "quickwin" to solve this and make everbody aware that it can be configured.

As stated before: Please provide a PR. I guess the initialization of the configuration is a good part to implement this privacy requirement.

Thank you for making this great tool available to the public!

You are welcome.
Final question: Do you have the possibility to run the api server locally via docker? So you can benefit from this feature? Or why would you like to disable these feature?

Next problem .. it seems you can't disable the geoReverse feature?!
  geoReverse:
    url:
  #   Preffered address language of geo code reverse lookups
  #   addressLanguage: [de, en-US] # for multiple languages
  #  addressLanguage: [en, de]
  # excludes are using gitignore patterns
  excludes: ['*.*']

I still get ..
[2023-12-27 00:09:11.730]: extractor.geoReverse warn Invalid geo position values of 745c996:REDACTED.jpg: 0 0
[2023-12-27 00:09:12.732]: extractor.geoReverse warn Invalid geo position values of b127ff7:REDACTED.jpg: 0 0
shouldn't exclude .. like .. exclude all files?
Thank you for your patience in advance :-)

Next problem .. it seems you can't disable the geoReverse feature?!

This feature is not implemented yet. PRs are welcome. You can add an invalid URL like http://localhost:1025 for the geo reverse feature. I do not know by heart what happens on a invalid URL. I do not know if always a warning message is printed or if it is printed only some times at the beginning.
@cimba007 since you are comment on this thread it seems that you are concerned about any external calls. It would help me to understand you if you explain your requirements and your needs so we can discuss  them. We can further evaluate if your concerns fit the current design of HomeGallery in general. Currently I feel a bit lost to provide appropriate help.

@xemle Okay .. so let me elaborate my usecase for home-gallery. I currently have an collection of private photos .. something like 150gb. Its not feasable to make them available to my family for easy viewing. My idea was to self-host them on my private computer. I don't want any of the photos to be made available to any sort of cloud service. They are private and I don't want them somewhere on the internet as I don't trust any 3rd party withi this kind of private information.
I might make the gallery accessible via Internet and and user/password feature but it would also be a possibility to use a VPN on the phone to directly connect to my home-computer.
Currently the files are sorted in folders like "2010 NameOfEventOrTopic". There is a total of 350 such folders.
I like the idea of the timeline but would also appreciate just a listing of folders. Maybe this can be solved by using the "Tag" feature by tagging all files withan an folder with the "Foldername".
I don't need the gea-feature as non of my photos has GPS information attached.
Furthermore I understand, that the API-Feature would provide some benefit, as it might allow me to quickly filter for all "cat" photos, in case the classification is able to classify cats. For this I understand that I would have to setup an private instance of the API server (same as running in the docker-container on your end). For this I want ot better understand how to use docker but for now I stick with the Windows-Standalone version that I can run by console.
As I said before I have concerns with sending all my family photos (even if in a small/compressed form) to through some 3rd party application. I don't think that you have an evil intent but the most probable cause for a data breach might be some outdated security feature - nevertheless - I have limited trust.
I appreciate home-gallery so far as getting it running with Windows was easy enough. Now I can scan my library and check if it is the right tool for this.
Furthermore I don't need any advanced features as the user of the library would most probably family members that just want "to watch" some memorys. For this I like the basic interface.
For now I have commented out the function-calls
From this "known startpoint" I would like to make some progress in getting docker running and maybe even enable the detection features .. but as this is only an added "Bonus" I would do it exactly in this order. As you already meantinoned. If the photos are once processed (over the cloud) there is no benefit in disabeling it afterwards.
      // single ungrouped entries
      imagePreview(storage, extractor),
      //videoPoster(storage, extractor),
      vibrant(storage, extractor),
      //geoReverse(storage, config),
      logPublicApiPrivacyHint(config),
      //similarEmbeddings(storage, extractor, config),
      //objectDetection(storage, extractor, config),
      //faceDetection(storage, extractor, config),
      //video(storage, extractor, config),
      //.pipe(videoFrames(storageDir, videoFrameCount))

Thank you for taking your time to follow this thread.
In addition I have never programmed in javascript/phython beyond an "hello world". Most of the time I code and C# and the hurdle for me to make myself familiar and provide an PR is just too huge at the moment.
Thank you again, best regards

@cimba007 thank you for your detailed response and motivation to use HomeGallery

I like the idea of the timeline but would also appreciate just a listing of folders. Maybe this can be solved by using the "Tag" feature by tagging all files withan an folder with the "Foldername".

While this feature requests raises from time to time I have not implemented it since I do have unordered folders. The default search honors the folder name so maybe you will find your images quickly by type some search input terms.

I don't need the gea-feature as non of my photos has GPS information attached.

What a petty since they are also a nice search vector and this feature comes for free with photos taken from mobile phones. And since the best camera is the camera which you have at the moment of the shot the mobile phone wins quite often in recent years.

Furthermore I understand, that the API-Feature would provide some benefit, as it might allow me to quickly filter for all "cat" photos, in case the classification is able to classify cats. For this I understand that I would have to setup an private instance of the API server (same as running in the docker-container on your end). For this I want ot better understand how to use docker but for now I stick with the Windows-Standalone version that I can run by console.

You can run api-server via docker in WSL. It should work. It is also possible to clone/download the repo and run the api server from the command line via a node environment.
Up to now there was not a big deal with the api server. So there is also no generic bundle for the api server like the gallery. Currently that would be possible but I wish the api server serves more and updated ML/AI feature detection. Using docker the used technology (node, python, go, etc) can be hidden within the container. If I provide a binary for the api server it can be a deal breaker in the future.
Summary: The api server works somehow and it does not get a lot maintaining attention. It is basically the version from the beginning of 2021. So you are welcome to improve that.

For now I have commented out the function-calls

Awesome. That is a good approach at the moment. Congratulations that you found your way to your requirement.

In addition I have never programmed in javascript/phython beyond an "hello world". Most of the time I code and C# and the hurdle for me to make myself familiar and provide an PR is just too huge at the moment.

But at least you are familiar with coding and you can comment out stuff. That is great.


separate search bar from URL bar

Due to the fact that the current user.js has disabled search suggestions for privacy, I suggest disabling search from the address bar altogether, as already implemented in ungoogled chromium with the nosearch search provider.
To do this, you need to add user_pref such as:
user_pref("browser.urlbar.suggest.searches", false);
user_pref("keyword.enabled", false);
user_pref("browser.fixup.alternate.enabled", false);

I understand the logic, but this would break too many people's workflows (user expectation).
Yes, live search suggestions are disabled for privacy, but that doesn't mean most users want to enable a separate search bar to search for something (hello early 00's), or, for users who won't understand how to do that, think that they have to navigate to google.com etc. every time they want to search. Enthusiasts who want that usually know how to achieve it.
Users who want a separate search bar from the address bar + autocomplete search results in search bar can add to their overrides:
// PREF: perform search engine queries in a separate search bar
user_pref("browser.search.widget.inNavBar", true); // display search bar beside the URL bar
user_pref("browser.search.suggest.enabled", true); // DEFAULT; restore autocomplete search suggestions
user_pref("keyword.enabled", false); // disable URL bar from resolving search queries

Btw, browser.fixup.alternate.enabled false is already default.
Even though many people tout Ungoogled Chromium as a great browser, it removes too much, IMO.


Updated DigitalOcean resources

Added new digitalocean resources

Hi @mjuenema. I'm planing create a script to sync all resource and data objects with terraform documentation. Then, we will have all providers always updated. https://github.com/terraform-providers/.

That would be great. Good luck.


Plan for scala friendly editor formatting

Hello!
I use jupyter-scala almost every time in my workspace (thank you) but some of editor features annoying me.
Everytime I 'enter' after some brace's opened, it appears a lot of tabs on my cursor.
For example,
val someVal = Seq(1, 2, 3, 4).map { n =>
                                  |

instead of
val someVal = Seq(1, 2, 3, 4).map { n =>
  |

Do you have any plan for scala-friendly editor features? or did I miss some feature from others?

It works as in your second example, since some time already (jupyter >= 5.7.0 at least, probably for earlier versions too).


Failed login - clear Exception

Description

Include the same options into session login Exception

For now when login fails it shows full login and password.
It should not show what password the user is using.
Line where the password is shown in vmngclient/vmanage_auth.py
Made PR for it #77

PR #77 merged, password hidden.

Full message available only in html file.


System LimitException: Apex CPU time limit exceeded When Importing from Source System to Salesforce

Hi Everyone,
Has anyone else ran into the error message listed below when importing records into the Salesforce "Interaction" object using an ETL tool?
"OBJ: Interaction__c - INT_Interaction: System.LimitException: Apex CPU time limit exceeded"?
We needed to break our Dell Boomi process to include batch sizes of 12 to handle the PeopleSoft records, as anything more than 12 records included in the batch prompted the error message above
Looking for feedback on possible approaches to help alleviate this issue other than breaking it up in to these small batch sizes
Thanks in advance,
Jason
@karamcintyre  @jacebryan

Hi Jason,
A common cause for this:  The amount of related automations occurring as result of the interaction insert is too much for the SalesForce governor.   To verify, try a test load with related workflows/process builders/flows turned off for related objects, and see if that improves the CPU time limits (perhaps the batch can be larger).
If eliminating automations improves the data load, it might be wise to refactor those automations to occur within a scheduled batch (if business procedures allow it).
@jnorat


Use Node-RED CSS vars

Description

Replicating the changes made in https://github.com/node-red/node-red-dashboard/pull/763, this PR changes ui_base.html to use Node-RED's CSS vars with a fallback to their current values.
Related Issue(s)

Checklist

[x] I have read the contribution guidelines
[ ] Suitable unit/system level tests have been added and they pass
[ ] Documentation has been updated

[ ] Upgrade instructions
[ ] Configuration details
[ ] Concepts

[ ] Changes flowforge.yml?

[ ] Issue/PR raised on FlowFuse/helm to update ConfigMap Template
[ ] Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production

Labels

[ ] Backport needed? -> add the backport label
[ ] Includes a DB migration? -> add the area:migration label

Thanks @bonanitech.
All looks fine from my phone, but AFK until Tuesday, where I can double check everything to merge it in.


Fix for issue #9.

Configured the awaiters in GetResponseContentAsync to not capture context (to prevent a deadlock reachable from GetResponseXML)

Hi,
Does this resolve the issue?
I don't have write permissions for this project, so we need to wait for one of project owners here.

Yes, fixes it for me...But the more involved fix involving making GetResponseXML and its callers async would be better I think...perhaps the project owners could decide.

@selvasingh @julienjtpierre


Are we still appending a version number to Docker Compose files?

In .../releases/edinburgh/compose-files/ we have
docker-compose-edinburgh-1.0.1.yml
docker-compose-edinburgh-no-secty-1.0.1.yml
docker-compose-redis-edinburgh-no-secty-1.0.1.yml

In .../releases/fuji/compose-files/ we have
docker-compose-fuji-no-secty.yml
docker-compose-fuji.yml
docker-compose-redis-fuji-no-secty.yml

Are we still appending the version number?

Gentle bump @jpwhitemn

now handled via directory structure and release naming


CREATE TAB FOR NEW GOALS

[ ] A component should be created for rendering new goals
[ ] New goals should have all the necessary sections filled

Redundant


Adding diagrams to holistically visualize App delivery

Often my customers are asking for a visualization which contains all of the application delivery guidelines in one or two drawings. I created two diagrams showing the recommended and considered ingress and egress traffic patterns as described in the Plan for App Delivery segment of ALZ.

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

Maybe these diagrams also make sense to commit to: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/plan-for-inbound-and-outbound-internet-connectivity.

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

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

#label:"aq-pr-triaged"

Have I missed anything?

@BrianBlanchard @JanetCThomas could you take a look at the proposed update? Thanks.


HVAC stopped to work recently

HVAC stopped to work recently :/
Is this project still alive ?
2022-05-11 18:36:18 ERROR (MainThread) [homeassistant.setup] Error during setup of component smartthinq
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 235, in _async_setup_component
    result = await task
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/smartthinq/__init__.py", line 69, in setup
    client = wideq.Client.from_token(refresh_token, region, language)
  File "/usr/local/lib/python3.9/site-packages/wideq/client.py", line 210, in from_token
    client.refresh()
  File "/usr/local/lib/python3.9/site-packages/wideq/client.py", line 193, in refresh
    self._session, self._devices = self.auth.start_session()
  File "/usr/local/lib/python3.9/site-packages/wideq/core.py", line 361, in start_session
    session_info = login(self.gateway.api_root, self.access_token,
  File "/usr/local/lib/python3.9/site-packages/wideq/core.py", line 258, in login
    return lgedm_post(url, data)
  File "/usr/local/lib/python3.9/site-packages/wideq/core.py", line 213, in lgedm_post
    raise APIError(code, message)
wideq.core.APIError: ('0110', '약관동의 미동의 상태입니다.')

if anybody steps into same problem, the Korean message says it's due to missing the Term&Condition re-agreement.
You need now to go thru token issue process using WideQ program, the reconfigure hass with new refresh token.

Thanks!! I added a special error handler for this error code, so messages might be marginally more helpful for users who encounter this problem in the future.


on IE EDGE: Cursor pointer position is after placeholder text instead at start

https://jsfiddle.net/k2gbjfwm/1/
here is the fiddle. you can open in chrome and all will work as expected but on IE Edge the cursor pointer is after placeholder text on the input field

I have not IE edge, and I don't care about this shitty browser

@SaadAhmedSiddiqui you can remove the emojionearea placeholder and apply css to the contenteditable div like this fiddle: http://jsfiddle.net/RZZ6X/9/

@waleedramzan I dont see emojionearea in your fiddle. i mean i do need to use the emoticons as well from emojionearea on my input field plus the fix of the placeholder text on IE edge.

@SaadAhmedSiddiqui This fiddle is showing us how to set placeholder for contenteditable div using css and js. You can use this as a reference and apply it to emojione contenteditable with class name 'emojionearea-editor'.

@waleedramzan  thanks for the help. and here is the final fiddle if anyone has gone through the same issue.
https://jsfiddle.net/x21gL75h/8/

@waleedramzan thanks for the help. and here is the final fiddle if anyone has gone through the same issue. It is not an exact behavior for placeholder but considering IE case it still would work fine i think,
https://jsfiddle.net/x21gL75h/8/

@SaadAhmedSiddiqui  that's great! Glad that it worked :)


Validators/expose valid vals

For some secret plans that I have regarding instrument mocks (EDIT: no longer secret, #859) I would like to have a way to make a QCoDeS Parameter tell me a valid value it could have. I think it makes sense to get such a value from the Parameter's validator. I therefore propose to have all validators expose a list of at least one valid value through a property called valid_values. This has the nice side effect that all validators actually have something to do in their __init__, which makes it less silly to have the base class demanding them to implement __init__.
Changes proposed in this pull request:

Make all validators expose valid values
Add tests to check that the valid values are, well, valid

@jenshnielsen @sohailc

@WilliamHPNielsen I think this was merged during the simulated instruments pr and can close?

You are correct, this was included in #859.


[WIP] Use GitHub Actions instead of Travis

Just a general note - this is WIP and most of this code will effectively go to litex-conda-ci.

We're working on adding stages for dependent packages now.

This PR was replaced with "local" branch PR
https://github.com/litex-hub/litex-conda-misc/pull/15

This PR was replaced with "local" branch PR
https://github.com/litex-hub/litex-conda-misc/pull/15


towards Nupm workspaces

i was once again working on NGM and was thinking about a few things related to Nupm :smirk:

[ ] installing multiple modules in a single package:
in https://github.com/nushell/nupm/pull/33, we made it possible to install multiple distinct modules from a single package, e.g. nu-git-manager and nu-git-manager-sugar in NGM. However, after using this feature, it sounds a bit strange... it's a bit like having two separate src/ directories in a single Rust crate :thinking:
i think we should revert that feature and keep it simpler, i.e. a single module per module package, and move towards a "workspace" or "bundle" model
[ ] dependencies resolution:
in NGM, i always have to write things like use ../../foo/bar.nu in the modules themselves or use ../src/nu-git-manager/ in the tests, which is not that great :thinking:
i think it would be great to have a nupm run that would resolve the dependencies and do that for the user, e.g. use module/foo/bar.nu and use nu-git-manager respectively: this would only be a trick with NU_LIB_DIRS to expose modules and activate overlays
[ ] "workspace" or "bundle" support:
would be cool to have multiple module packages in a repo and a central top-level package.nuon that would define a "workspace" and allow maybe to install everything at once?, e.g. nupm install --workspace

another quick thought, we might want to change package.nuon to Nupm.nuon?

Sounds good.

nice, i'll start working on all this then :relieved:

I'm also fine renaming package.nuon to nupm.nuon (no need for the capital IMO).

yeah, nupm.nuon is great :ok_hand:
the inspiration was Cargo.toml but the capital is not required :wink:

I think I misunderstood your point 2, we don't have anything like Rust's crate in Nushell. Modules currently don't have an idea of being a part of a package, we'd have to build it into the language. I purposefully kept the modules as flexible as possible to avoid rigid module lock-in situations like in Python, but maybe something dumb like substituting the pkg in pkg/lib/lib.nu for the first parent directory containing nupm.nuon (or throwing an error) could work. It would most likely need to be implemented as a part of Nushell, though.

@kubouch
i've managed to fix my dumb issue => i needed to put the full absolute path in $env.NU_LIB_DIRS
i've created a draft PR to try things out :yum:

in NGM, i've defined a top-level nupm.nuon and i use it here to generate the documentation of the two modules in the workspace.


Dang/add port id into msg register interchain account response

Description
Add generated portID to message MsgRegisterInterchainAccountResponse

closes: #2724
Commit Message / Changelog Entry
type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #3204 (1579647) into main (761277a) will increase coverage by 0.00%.
The diff coverage is 72.22%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3204   +/-   ##
=======================================
  Coverage   78.60%   78.60%
=======================================
  Files         177      177
  Lines       12410    12421   +11
=======================================
+ Hits         9755     9764    +9
- Misses       2230     2231    +1
- Partials      425      426    +1

Impacted Files
Coverage Δ

modules/apps/transfer/ibc_module.go
64.81% <40.00%> (-0.16%)
:arrow_down:

modules/apps/transfer/keeper/relay.go
90.63% <60.00%> (ø)

...nterchain-accounts/controller/keeper/msg_server.go
92.10% <100.00%> (+0.21%)
:arrow_up:

...les/apps/27-interchain-accounts/host/ibc_module.go
91.11% <100.00%> (+1.11%)
:arrow_up:

...s/apps/27-interchain-accounts/host/keeper/relay.go
71.08% <100.00%> (ø)

Thank you, @GNaD13!
Can you also please update the MsgRegisterInterchainAccountResponse message in the docs here?

Hi sir @crodriguezvega , Thanks for your reviewed, I've updated it


PageView  with PlatformView embedded won't snap page

PageView with PlatformView embedded won't snap the page after randomly scrolling up or scrolling down, then the ViewPost Callback Function won't be called. Submit the issue here to get some clues and helps, thanks.
https://user-images.githubusercontent.com/8843894/132845328-48af6a92-0873-44c7-88a0-d8f4122f7351.MP4
##Example
https://github.com/voicewitness/demo_platform_pageview
##Flutter doctor
[✓] Flutter (Channel stable/v1.22.6.xianyu, 1.22.6-xianyu, on macOS 11.2.3 20D91
    darwin-x64, locale zh-Hans-CN)

[!] Android toolchain - develop for Android devices (Android SDK version 29.0.0)
    ! Some Android licenses not accepted.  To resolve this, run: flutter doctor
      --android-licenses
[✓] Xcode - develop for iOS and macOS (Xcode 12.5)
[✓] Chrome - develop for the web
[!] Android Studio (version 2020.3)
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    ✗ Unable to find bundled Java version.
[!] IntelliJ IDEA Community Edition (version 2019.2.3)
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
[!] VS Code (version 1.60.0)
    ✗ Flutter extension not installed; install from
      https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[✓] Connected device (3 available)

Hi @voicewitness, Thanks for filing the issue, I see that you are using a very old version of flutter, And unfortunately we do not provide support to older versions, I just verified on the latest stable version 2.5.0 and it seems to be working fine.
Closing this issue as invalid if you disagree feel free to write in the comments and I will reopen it.
https://user-images.githubusercontent.com/31410839/132858862-6a8d1596-499c-4cfe-ae04-fcd58c31fa5c.mov

flutter doctor -v
[✓] Flutter (Channel stable, 2.5.0, on macOS 11.5.2 20G95 darwin-arm, locale en-GB)
    • Flutter version 2.5.0 at /Users/mahesh/Documents/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 4cc385b4b8 (2 days ago), 2021-09-07 23:01:49 -0700
    • Engine revision f0826da7ef
    • Dart version 2.14.0

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/mahesh/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • ANDROID_HOME = /Users/mahesh/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] IntelliJ IDEA Community Edition (version 2021.2.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 60.1.4
    • Dart plugin version 212.5080.8

[✓] VS Code (version 1.59.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.26.0

[✓] Connected device (3 available)
    • iPhone 12 Pro (mobile) • B622CBB7-F906-4FA7-8F49-FACEAAC905AB • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • macOS (desktop)        • macos                                • darwin-arm64   • macOS 11.5.2 20G95 darwin-arm
    • Chrome (web)           • chrome                               • web-javascript • Google Chrome 93.0.4577.63

• No issues found!

Thank you.


Problem: omni_python.config does not have UNIQUE constraint on name column

This allows multiple entries for the same config, like:
omnigres=# select * from omni_python.config;
 id |      name      |     value
----+----------------+----------------
  1 | pip_find_links | /python-wheels
  2 | pip_find_links | /python-wheels
(2 rows)

@yrashk I'll take this up, as discussed on Discord.

@yrashk How can settings like pip_find_links be non-unique on the name? What value do we use if there are multiple values for the same setting?

This is based on my prior understanding that pip would take plural -f/--find-links as well as plural --extra-index-url. We should validate this finding to ensure I am not wrong.

@yrashk Oh. If that turns out to be the case, does it make sense to still have a unique constraint on name, and just allow comma separated values?

There are pros and cons to both. Comma-separated values allow us to order the values, which is actually fairly important, but plant us firmly outside of easily processable data (if we want to check for existence for individual value validity in the future, etc. we'd need to parse the values)
There are some ways we can think of here:

adding an ordering column. Makes it more complicated to manage but easier to add/remove values
making all values arrays of text and enforcing their size on a setting base.


Support setting title attribute on Link tag

I think the previous implementation was accidentally lost in a merge/commit (5219552)

Nice catch, thanks!