Breaking change in tuples after VS 15.4 update

With VS Update 15.3.5 we get:

With VS Update 15.4 we see:

/cc @mexx @drvink

OK, so this is a regression.  We fixed an issue to translate Tuple<int,int> into F#'s view of tuple types int * int.  However the F# view of tuple types doesn't support .Item1 etc. properties.
I'm not sure what to do about this, we will need to think about it.

Tbh I think it should compile in any case since we only use system.tuple everywhere

I think whenever the type System.Tuple is specified explicitly the compiler would allow ItemX otherwise it probably shouldn't?
Besides that System.Tuple and * should behave exactly the same (and we should be able to change one to the other without semantic changes - with the exception of ItemX).
The easier solution would be to allow ItemX everywhere, but that might have other side-effects.

Workaround:

ok this fails in ci_part1 for unrelated reason. I guess master is broken

@forki Yes, there's something fishy with the latest commit "Merge branch 'vs2017-rtm' into master".

I think whenever the type System.Tuple is specified explicitly the compiler would allow ItemX otherwise it probably shouldn't? Besides that System.Tuple and * should behave exactly the same (and we should be able to change one to the other without semantic changes - with the exception of ItemX). The easier solution would be to allow ItemX everywhere, but that might have other side-effects.

See https://github.com/Microsoft/visualfsharp/issues/3016, https://github.com/Microsoft/visualfsharp/pull/3283

See #3016, #3283

Ok with that in mind another solution would in fact be to not allow users to use System.Tuple by either emitting a warning or even an error (because apparently it is hard to write code when you have that anywhere)

@matthid this code comes from C# interop in real life app. We broke that.
one could argue that's bad design to use tuples in public APIs, but this is still a breaking change

@forki Yes non-breaking is only my suggestion above. Problem is as far as I can understand the point of @dsyme is to strictly separate language-tuples from System.Tuple. That they are in fact the same is an implementation detail. This is a hard decision to make with what is already released.
Maybe the compiler needs to be less eager in converting to F# tuples as it is right now?

ok so the test is capturing the bug.

Found the same issue in our code base, C# calling an F# function that explicitly specifies System.Tuple with types. Repro:
[<CompiledName("F")>]
let f (p : System.Tuple<bool, int>) =
    printfn "%A %A" p.Item1 p.Item2

I'm finding it rather troublesome that one can specify a concrete type and the compiler supersedes the request.

@curtnichols Thank you for reporting this.  Firs,t I want to apologize that this change has come into F# 4 .1 midway instead of being done as a language addition/change in F# 4.2.   The rising use of System.Tuple meant that the #3016 was becoming a more serious issue that would have meant very inconsistent views of the use of the type when encountered via F# source and C# source.  However I hadn't appreciated fully the side effects that addressing the issue would have.  Certainly, an RFC should have been written with full analysis, and it is something I will endeavour to do next week - better late than never.
The change to fix #3016 has effectively made  (int * int) and Tuple<int*int> equivalent and regular.  The case you're seeing above is actually a long standing nit in the F# compiler - which we decided long ago not to change - that there is an element of type-directedness in determining the compiled form of a function that accepts tuples as arguments.   Basically a function like this:
let f1 (p : (bool * int))) = ()

or
let f2 ((a,b,c) as d) = ()

will in each case have a compiled form that accepts multiple arguments, rather than one tupled argument.  As you're encountering, it now doesn't matter whether you write (bool * int) or Tuple<bool,int> - in either case you now get two arguments.  It's at least now consistent in that the two ways of writing tuple types are equivalent
The original rational for this approach was that the following is quite a common coding pattern:
let f3 (a,b,c) = ...
let f4 args = f3 args

In this case, looking only at let f4 args = f3 args, it is reasonable for the programmer to expect that f3 and f4 will have the same compiled form.  (It's intrinsic in the fact there is even a choice about the compiled form that you have to "pay the cost" at some point in the language design - in this case we choice "implicit type-directed de-tupling happens" over "innocuous rebindings change your compiled form".  The F# design has a number of such choices.
The only way I know of to stop the compiler making this choice is now to add a signature file to a module (previously you could use an explicit System.Tuple as in your code, but that route has now been blocked off).  If you do that, and use
val f1 : p:(int * bool)  -> unit
val f2 : p:(int * int * int)  -> unit

then you will get one argument in the compiled form.  If you use
val f1 : a:int * b:bool  -> unit
val f2 : a:int * b:int * c:int  -> unit

then you get multiple arguments.  AFAIK there is no way to get this behavior any more without a signature file.  I'm still thinking about what we should do here, and I will try to document the choices in an RFC next week.  We may add such a way, or we could in theory roll back the change that fixed #3016 (though that seems unlikely)
In short the workaround at the moment appears to be to add a signature file.  I understand that's not a great workaround though if your implementation file is large.

@forki How serious is the Item1, Item2... thing for you (or others)?

For me personally it's no issue at all. I only reported it for @mexx. So he should comment on that.

I mean since destructuring with (i1, i2) is working it's only an annoying step to go over all the item1 thingies and change the code.

But then we need to make sure we don't break it ever again.

In my case the code base which was broken is not big, I was able to change the code to function again.
For me it's not critical, but I can imagine someone could have more code to change.

Tbf 8 think it's now pretty usable when you consider that you can basically
destructure all kinds of tuples now with same syntax. Only trouble is that
it is breaking...
Am 15.10.2017 14:52 schrieb "Max Malook"<EMAIL_ADDRESS>In my case the code base which was broken is not big, I was able to change
the code to function again.
For me it's not critical, but I can imagine someone could have more code to
change.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/pull/3729#issuecomment-336709609,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNNFKOwSHGs12MW7TlOXHuoMmIW4qks5ssgAVgaJpZM4P1Qzn
.

Here is a more sinister (but real) repro, simplified. I've attempted the signature file, but as you can see the Sytem.Tuple is not part of a function signature, so my optimism wanes.
The F# side essentially looks like this:
module Update =

    open System
    open System.IO

    type FileMapper = Func<string, Tuple<bool, Stream>>

    type UpdateArguments = {
        MapFilePath : FileMapper
    }

    [<CompiledName("F")>]
    let f (args : UpdateArguments) =

        let success, file =     let result = args.MapFilePath.Invoke("name")
                                result.Item1, result.Item2
        printfn "%A %A" success file.CanRead

@dsyme

The case you're seeing above is actually a long standing nit in the F# compiler....

I think I grok most of what you're saying, but this is obviously an interop issue--which I think you mention as the reason for prioritizing this change. So this was meant to be a breaking change sooner or later? As in, our understanding of how this interop works needs to change?
I write primarily F#, C#, and C++, with interop between the various factions. Few things push my buttons more than compilers not doing what I ask of them.

@dsyme
I made a small modification to @curtnichols' example, to make the surprise of this behavior more clear.
    [<CompiledName("F")>]
    let f (args : UpdateArguments) =
        let success, file =     let result:Tuple<bool, Stream> = args.MapFilePath.Invoke("name")
                                result.Item1, result.Item2
        printfn "%A %A" success file.CanRead

And it yielded a compile error.
>------ Rebuild All started: Project: Library1, Configuration: Debug Any CPU ------
1>C:\Users\kevinr\source\repos\ConsoleApp1\Library1\Library1.fs(17,40): error FS0039: The field, constructor or member 'Item1' is not defined.
1>C:\Users\kevinr\source\repos\ConsoleApp1\Library1\Library1.fs(17,54): error FS0039: The field, constructor or member 'Item2' is not defined.
1>C:\Users\kevinr\source\repos\ConsoleApp1\Library1\Library1.fs(18,33): error FS0072: Lookup on object of indeterminate type based on information prior to this program point. A type annotation may be needed prior to this program point to constrain the type of the object. This may allow the lookup to be resolved.
1>Done building project "Library1.fsproj" -- FAILED.

I think this error message would surprise most F# developers. and be pretty hard to explain.

I could easily be missing something, but wouldn't it be a whole lot simpler and avoid tons of garbage if we could just use the new struct tuples everywhere and get rid of the old class-based tuples?

@varon

I could easily be missing something, but wouldn't it be a whole lot simpler and avoid tons of garbage if we could just use the new struct tuples everywhere and get rid of the old class-based tuples?

It's irrelevant to this discussion, and wouldn't solve the issues here

I think this error message would surprise most F# developers. and be pretty hard to explain.

F# developers don't use Tuple or Item1 explicitly - they use (int * int) and pattern matching.
We could allow the use of ItemN properties. However these properties are defined in the compiled form of the types, which is relevant for large tuples.  So, for large tuples, would (int * ...... * int) 10-tuple have a Item10 property?  Or only up to Item7 or Item8?
The correct thing to do in F# is to adjust the code above to this:
let f (args : UpdateArguments) =
    let success, file = args.MapFilePath.Invoke("name")
    printfn "%A %A" success file.CanRead

As you can see, the code was just a kludge to workaround the fact that F# wasn't understanding that Tuple<X,Y> is the same as (X * Y)

@dsyme I think in an ideal fix for this a variable/symbol declared as (X * Y) would not have ItemN properties.
But if the developer explicitly declares a variable/symbol as Tuple<...> I feel like the ItemN properties should become available (while otherwise still behave exactly the same).

This would solve this bug as we would gain backwards compatibility
It removes the surprise of people going to the docs and expecting the ItemN properties.

Besides that I feel like X*Y should behave like Tuple<X,Y>. Is there a problem with this suggestion? Is it too hard to implement? Basically the compiler has to "remember" if the type was declared as F# tuple or System.Tuple and unify them later (if at all).
I think what I'm missing in the above solution is how we can differentiate F# tuples from System.Tuple<...> in external references. Is it even feasible to detect if a function type was declared as F# or System.Tuple after compilation? Probably not. But then I'd favor @dsyme's argument of not enabling ItemN everywhere.

Is there a problem with this suggestion? Is it too hard to implement? Basically the compiler has to "remember" if the type was declared as F# tuple or System.Tuple and unify them later (if at all).

@matthid Realistically we could only do that if they were considered distinct nominal types (F# makes an effort to remember abbreviations but these are not necessarily preserved by type inference).
Note F# has always translated Tuple<X,Y> encountered in .NET libraries to (X * Y).   The thing we were not doing previously was translating Tuple<X,Y> declared in F# code to (X * Y).

Here's my latest:
The return of this Func is is what broke:
type FileMapper = Func<string, System.Tuple<bool, Stream>> // Broken in VS 15.4 where .ItemN is used.

This version using F# idioms would be very bad interop:
type FileMapper = string -> (bool * Stream) // Bad interop: FSharpFunc<string, Tuple<bool, Stream>> MapFilePath

And this works on both 15.3.5 and 15.4. Both versions of VS generate a System.Tuple as the return value.
type FileMapper = Func<string, (bool * Stream)> //  Func<string, Tuple<bool, Stream>> MapFilePath

Note that spelling the tuple in the F# dialect left me with the System.Tuple, which is what I want for intrerop. At the moment I'm just not sure why. :)

Note that spelling the tuple in the F# dialect left me with the System.Tuple, which is what I want for intrerop. At the moment I'm just not sure why it did what I want. :)

In F# A * B and Tuple<A,B> are now two syntaxes for exactly the same thing.  They are identical.
It's just that F# doesn't let you use the ItemN properties on this thing anymore, for reasons mentioned above.
And yes, we should not have made that breaking change except via an RFC, in which case I suppose we would surely have supported Item1, ... at least for small tuples.

@dsyme what do you propose for next steps on this PR?
Thanks
Kevin

@KevinRansom I believe we are at the point where we will just have to accept that this breaking change happened.

Part of the problem here is we have no data on how often people snag ItemX from a System.Tuple defined in F# code.  I suspect that few people do this in a way that is difficult to correct, but the mere fact that there is a breaking change here will keep people and orgs from adopting VS 2017, even if they're not broken by this at all.  I'm inclined to say this should be fixed, even though it requires a change to the language to allow Item1-Item7 access on F# tuples.  We'll just have to not document that so that it doesn't catch on.

@cartermp OK, I'll think over the cost and approach to factor that in

We'll just have to not document that so that it doesn't catch on.

It's not that I think ItemN properties are bad - they actually fill a need since utility functions such as now let p13 (a,b,c) = c aren't really needed, especially if _.Item1 becomes allowed as a first class function value (see RFC on that).   It would be wrong to steop them appearing in intellisense for example, if they are legitimate properties
It's just it's best discussed

Agreed

@KevinRansom what is UpdateArgs?  In this case result can be converted directly into success, file:
[<CompiledName("F")>]
let f (boolStream : Tuple<bool, System.IO.Stream>) =
    let success, file = boolStream
    printfn "%A %A" success file.CanRead

Why does ItemX property access have to work aside from strictly from a "not breaking existing code" reason?

@cartermp
The developer specified that result is a Tuple<bool, Stream>.  In every other .Net language it would have an Item1 and Item2 property.  It should in F# too.  That F# has a nicer deconstruction syntax, is irrelevant.
Kevin

In every other .Net language it would have an Item1 and Item2 property. It should in F# too. That F# has a nicer deconstruction syntax, is irrelevant.

If life were only made up of small tuples I'm fine with this approach.
However, for large tuples size > 7), other .NET languages see the compiled representation of tuples. Normal F# code suppresses the compiled representation from view. From F#, the compiled representation can be observed in multiple ways (reflection, typeof etc) but in normal F# coding the user is not aware of that encoding.
For example, what would Item8 show for an 9-tuple of integers?  A pair of integers??  (That's the encoding used for large tuples in the compiled representation, and I presume that's what C# shows). Or what intellisense list do you get when you press . for for a 100-tuple?  Item1 to Item8`, where Item8`` has a massive whacky type?
It's a reasonable choice to make the Item properties available for small tuples - especially for backwards compat reasons - but I'm loathe to do it for large tuples. But equally, if we don't make them available for large tuples, then programmers can get to a situation where adding an extra element to a tuple suddenly means all those Item properties are no longer available.
A separate consideration is that using Item properties for tuple elements arguably makes code less readable - when you are forced to use tuple decomposition with a pattern you are forced to give names to the elements of the tuple, which is valuable metadata, c.f.
(fun p -> p,Item1 / p.Item2)

v.
(fun (distance, time) -> distance / time)

or even
(fun (d,t) -> d/t)

Both the second and third carry more useful metadta - the first is horrible for readability and maintainability. People are lazy and love hitting .. But I don't think it will remotely increase the quality of F# code being written.
(As an aside, note that, after the change that caused this regression, the F# type system can't effectively distinguish between int * int and Tuple<int,int> - a choice you make about one form of declaring tuple types applies to the other.)

@dsyme I think we make our life harder than it actually is:
We probably should not even try to change regular F# code for this bugfix. The Compiler should introduce/allow ItemX properties only when the type is annotated explicitly as .NET Tuple type. This is what a programmer expects. That Tuple<X,Y> and X*Y is the same is an implementation detail (from a language point of view they can be converted implicitly from one to another)

Note F# has always translated Tuple<X,Y> encountered in .NET libraries to (X * Y). The thing we were not doing previously was translating Tuple<X,Y> declared in F# code to (X * Y).

So all we need to do to fix this bug is allow ItemX in that particular case. We don't introduce any problems regarding bigger tuples as it is hard to explicitly annotate them anyway (they don't actually exist as explicit Tuple types).
Maybe we shouldn't try to add a general language feature for tuples around here and somehow concentrate on the one special case we broke?
So in short: Can't we have a solution without ItemX in the general case (we might be able to add that later) and still recover this edge case? It probably is a bit of work...
Above I was thinking that it is hard to do, because of external libraries. But as we never supported that case anyway we don't have support that case here in the bugfix?
Leaving this bug aside. It really feels strange to explicitly annotate something with a regular .NET type and then not having access to its members (as @KevinRansom has already said). Do we have something similar somewhere else in the language?

IMHO there are two ways of approaching the problem.
On one side, if we see F# tuple and System.Tuple as synonyms, the API provided by either of the types should contain all of the possible properties and methods defined on any of them. The types should be made really interchangeable. I think this was as well the rationale behind the changes whose leaded to the current state.
On the other side, we can treat F# tuple and System.Tuple as implementation equal but different types on the type system with an implicit conversion between them as they are equal on implementation. When the type is explicitly provided it shouldn't change in the type system, but the value should be automagically able to be used as the other "implementation equal" type. This approach would make the types as well interchangeable.
For me the second approach would fix the problem for the interop scenario (as @matthid described) and as well would allow to proceed with the first approach once this identified to be needed for example for the _.ItemX syntax mentioned by @dsyme.

Re synonyms v. distinct.  We have long regarded  F# tuple and System.Tuple as synonyms when

System.Tuple appears in the metadata of a non-F#  .NET assembly, and
The particular use of System.Tuple conforms to a valid compiled representation of an F# tuple type.

Prior to the breaking change we regarded them as distinct when they appeared explicitly in F# source code.  However that approach led to unresolvable logical inconsistencies in corner cases.
Clearly we need to continue to regard them as synonyms in the cases where we already do that, we have no choice.

Compiler should introduce/allow ItemX properties only when the type is annotated explicitly as .NET Tuple type. This is what a programmer expects.

While I sympathize with this, especially since it was the behaviour prior to the change, I don't necessarily want to follow "what the programmer expects" here.

In the F# design and implementation it is extremely difficult to attempt to allow two types that are "synonyms" to be non-equivalent, e.g. for the purposes of name resolution of properties.   And I mean really, really difficult, among other things it results in incoherent, under-specified or fragile behaviour in type inference.

I'm not particularly happy to have the Item properties appearing in intellisense lists just because some C# programmer rocks up and complains "where are my Item properties".  Tuples are very fundamental to F# - we shouldn't muck with their usability/engineering/resulting-code-quality properties just because of that.   As I said above, if we do add the Item properties to intellisense lists (for F# tuple values) they will get used all the time.  I know the proposal is to only add them for TUple<_,_> annotated types, but that's very hard, see point 2 above

Obviously for large tuples it is fundamentally "wrong" for Item8 to reveal the nested encoding (which we would be at risk of given that we basically can't have one view of the properties for ( ... * ... * ...)-declared or inferred large tuple types, and one for Tuple<...> declared tuple types)

Note also that large tuple types are common enough in F#, because they are automatically inferred for large tuple expressions.
Given all this, a design that would satisfy me is:

Allow `Item*`` properties to be name-resolved on all small tuple types (size <= 7), and
Hide all Item* properties from intellisense lists, and
Give a warning that their use should be replaced by let (x,y) = p tuple decomposition in F#.

That's basically where we want code to end up, and would deal with the breaking change.
As an aside, there are precedents for hiding things from intellisense lists in F# where we don't want them to infest F# code and thinking, e.g. we don't show Equals and GetHashCode for F# types that don't satisfy the equality constraint, see https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/NameResolution.fs#L4141.

@dsyme I like your solution, Don. It un-breaks broken code and discourages the .ItemX usage. The new warning would be treated as an error in our build, but I presume it would come with a descriptive warning message. We dealt with the one line of .ItemX in our F# code base and moved on.
As a C/C++/C#/F# (primarily ;)), I have long found the .ItemX usage in C# to be inelegant. As far as C#-flavored developers being concerned about lack of .ItemX in F#:

the new warning would help them write more idiomatic F# code, and
C# now has better tuple support, meaning they don't need to use the .ItemX syntax in C#, either. That's a welcome improvement in my view.

Just a small comment:

For example, what would Item8 show for an 9-tuple of integers? A pair of integers?? (That's the encoding used for large tuples in the compiled representation, and I presume that's what C# shows). Or what intellisense list do you get when you press . for for a 100-tuple? Item1 to Item8, where Item8 has a massive whacky type? That's just wrong.

It's very ugly in C# - you need to understand the representation (which is crazy), and do var item9 = theTuple.Rest.Item1.Item2;.  This is because "Rest" returns the Tuple<Rest> (1 item tuple) containing the tuple of the 8th and 9th values internally.
As Item8 does not exist, I'm not sure this is necessary:

Allow `Item*`` properties to be name-resolved on all small tuple types (size <= 7), and

Allowing the Rest property to be name resolved (but hidden from intellisense) doesn't seem inappropriate if you're allowing the first 7 items and including a warning already. This would prevent the above ugliness from being a breaking change, but the warning/hidden intellisense would still be enough to discourage people from using that monstrosity.

I agree to add for completeness reasons the property Rest no matter what crazy encoding it reveals. I don't think even in C# people goes into property Rest frequently, it is there for completeness and should be added here as well for the same reasons.
To me it will look even crazier to provide access the internals of a 7-uple but not for the 8-uple.

@dsyme
I think the proposal is:
•	For Tuples and ValueTuples allow Items 1-7 + Rest.
•	Warn on use with improved F# syntax …. (Off by default since it’s a breaking change?)
•	Hide Tuple members from intellisense?
What should intellisense do with this:
let x = struct(1, 2)
printfn “%d” x.

For Tuples and ValueTuples allow Items 1-7 + Rest.
Warn on use with improved F# syntax …. (Off by default since it’s a breaking change?)
Hide Tuple members from intellisense?

Yes, though

I don't care about Rest, I don't believe anyone has used it
historically haven't considered adding "sensible" warnings as true breaking changes

That said, the above is a fair chunk of work and the issue doesn't appear to be of screeching urgency.

I don't care about Rest, I don't believe anyone has used it

I have used Rest. It's not a common pattern but I think we should definitely have it available, again for completeness. I like the way F# handle tuples, in the sense that it's not theoretically limited to a certain number of elements, as it is in other languages, so let's keep it like that.

I have used Rest.  It's not a common pattern but I think we should definitely have it available, again for completeness.

You've used Rest from F# code?  Why?
We are treating this as a tactical fix to undo a breaking change - but not to encourage or extend how F# programmers program with tuples. Given that the cost of this fix is fairly high and we've little evidence of any widespread use of Item* properties on explicit F# uses of System.Tuple<...> I'm tempted just to not do this at all.  We've no evidence at all of the use of Rest....

You've used Rest from F# code? Why?

I don't remember exactly the reasons, but I think it was to generalize at some point in the code over arbitrary size tuples and avoid a lot of boilerplate while at the same time have strong type checking.
That part of the code was something like a little dataframe lib, but strongly typed.
Since I have no longer access to the source code I can't give you more details, but I know they're using it in production.
If it's a big effort I'm happy to help on that part.

Hi,
I usually use FsPickler and when I change the code like this:
https://github.com/mbraceproject/FsPickler/pull/97#issue-275127733
And I could build it successfully on my Windows Server 2016 with clear VS 2017 update 15.4.
I did a git commit and try to pull request, but the CI tool just failed to compile it.
https://travis-ci.org/mbraceproject/FsPickler/builds/304174513?utm_source=github_status&utm_medium=notification
This is good for those who usually follow the latest version tool and quickly change their code (e.g. me?!) but not comfortable with the others who only NuGet something to use...

@ingted @dsyme +1, this regression makes it impossible to build FsPickler without resorting to reflection.

@ingted @dsyme +1, this regression makes it impossible to build FsPickler without resorting to reflection.

... and it worth clarifying that .Rest is also being used in FsPickler.

... and it worth clarifying that .Rest is also being used in FsPickler.

Yeah, I saw that.
@cartermp One approach to this breaking change would simply be to revert https://github.com/Microsoft/visualfsharp/pull/3283 and try again with that change in F# 4.2.

@dsyme I agree that reverting #3283 is a way to go, but such a change will not be until at least the VS 2017 15.6 release.  We're currently in Ask Mode for the first Preview (group engineering manager approval required for changes), but the final release is not likely to be for a few months.  There is a chunk of time allocated for addressing issues with the large forthcoming 15.5 release.  And we're far, far beyond the time where we could get a compiler change into 15.5.
We could also look into shipping a VSIX through the gallery, but this will not have the same reach as VSIX distributed in-box, plus it's another thing we'll need to account for until 15.6 RTW.  So I think we should look for a way to unblock FsPickler in the interim.
I'm a bit confused about the issue with FsPickler.  Looking at the code, it should work with the new compiler with small tweaks.  @dsyme says this:

In F# A * B and Tuple<A,B> are now two syntaxes for exactly the same thing. They are identical.

However, in a PR intended to unblock FsPicker, @eiriktsarpalis says this:

Thanks, but Tuple`8 types are not exactly the same as a tuple of 8 elements. In order to get this to work, the F# compiler issue must be fixed.

Does the FsPickler build contain the same compiler as #3283?  If not, can we try to update it and see what happens?

Yes, I understand it would be for 15. at the earliest.

I'm a bit confused about the issue with FsPickler. Looking at the code, it should work with the new compiler with small tweaks.

My understanding is that FsPickler programs over Tuple`8 (i.e. Tuple<t1,...,t8>) with explicit access to Rest in order to deal with arbitrarily sized tuples without using reflection.  That programming technique is not possible after #3283 (partly because accessing Rest is not possible, and particular because an F# 8-tuple (int * .... * int) corresponds only tuples of logical size 8, where :? Tuple`8 matches tuples of logical size 8 and greater).
So @eiriktsarpalis is correct that it's not possible after #3283.

So that means that this code basically won't work?  Suppose I could just pull it down and try it out.

So that means that this code basically won't work? Suppose I could just pull it down and try it out.

Correct - specifically it won't work on a 9+ tuple

Okay, in that case let's revert and try to get it into the 15.6 preview

FWIW here's a small snippet that illustrates how tuples of large arities are encoded:
open FSharp.Reflection

let mkTupleTy arity =
    Array.init arity (fun _ -> typeof<int>)
    |> FSharpType.MakeTupleType
    |> string

Array.init 20 ((+) 1 >> mkTupleTy)

8-tuples are cannot work either, because they also rely on nesting a 1-tuple in the Rest parameter. In general it is not possible to pattern match on a Rest argument using regular tuple expressions.

Okay, in that case let's revert and try to get it into the 15.6 preview

@cartermp See #4029, though as I note in the PR it makes me feel queasy.  The alternative is to implement the proposal above after all:
•	For Tuples and ValueTuples allow Items 1-7 + Rest.
•	Warn on explicit use of Item* and Rest
•	Hide Tuple members from intellisense

Warn on explicit use of Item* and Rest

Would that really be necessary in your opinion?
I find destructuring larger tuples to be annoying (even though large tuples are probably an anti-pattern).
Compare
let (_,__,x,_,_,_) = tpl
let x = tpl.Item3

In the first case it is really not obvious which member is accessed - I need to count the number of ignored items.
This issue is compounded by the fact that it is not possible to write universal accessor functions fst, snd, or itemN which work over all tuple sizes. So I would need to create fstOf4, fstOf5 and so on.

In the current state, it seems also impossible to explicitly call the constructor of System.Tuple:
let tpl3 = new System.Tuple<int,int,int>(8,9,10)

error FS0756: 'new' may only be used with named types

@0x53A Re Item
I understand the temptation to add these to the F# programming model for all tuple values.  However, see my comment above, particularly:

A separate consideration which is weighing on my mind is that using Item properties for tuple elements makes code less readable... When you are forced to use tuple decomposition with a pattern you are forced to give names to the elements of the tuple, which is valuable metadata,.....[using Item properties] is horrible for readability and maintainability. People are lazy and love hitting . ....making Item properties available in intellisense lists will not remotely increase the quality of F# code being written, and indeed will harm it.

In the current state, it seems also impossible to explicitly call the constructor of System.Tuple:

Yes, that is correct.  The proposal here would be not to change this.

[...] When you are forced to use tuple decomposition with a pattern you are forced to give names to the elements of the tuple, which is valuable metadata,..... [...]

This is a nice goal, but I don't think it actually holds in practice. In reality I will use
let (_,__,x,_,_,_) = tpl
where x doesn't really tell me anything, and I lose the information which member I access and so need to manually count.

IF you really hate ItemX, please consider https://github.com/fsharp/fslang-suggestions/issues/628. The SRTP method needs ItemX visible, but it could still warn on explicit use, and/or hide them from intellisense, as long as they are visible to the constraint solver.

In reality I will use let (_,__,x,_,_,_) = tpl where x doesn't really tell me anything, and I lose the information which member I access and so need to manually count.

I agree this kind of code is poor and in good, long-lived code there should be accurate transition paths away from it. Using a large tuple or a name x that is a programmer's problem.  However, there are progressive, accurate steps the programmer can take to rectify the mess, e.g. turn the tuple values into a record type or a single-case discriminated union.
In contrast offering tpl.Item3 in the intellisense list is worse

We actively incentivize the use of a crappy, meaningless name (even x is better than Item3)
There is no incentive to move away from a large tuple
Programming is less accurate under change. For example, consider when an extra item is added or removed from the front of the tuple - you have to manually hunt down and correct all Item accesses that aren't caught by the type checker.  With an explicit tuple, you at least manually go and adjust the tuple patterns that consume the tuple.

Do you think the same about external accessor functions (fst, snd, thrd, ...)?
The big advantage of them is that they aren't easily discoverable (you can't dot into them from the tuple itself), so you can only use them if you already know they are there ;-)

Do you think the same about external accessor functions (fst, snd, thrd, ...)?

I'm not fundamentally opposed to generic constructs over generic data shapes.  For tuple projections I think the incentives are set about right for those in F# today:

fst and snd are there but you aren't particularly incentivised to use them

You can define additional projections (e.g. p13, p14 as we do in the compiler code) but you probably know what you're doing in that case

The fix for this issue is at https://github.com/Microsoft/visualfsharp/pull/4034

The RFC issue for this whole tuple malarkey is at https://github.com/fsharp/fslang-design/blob/master/FSharp-4.1b/FS-1046-consistent-tuple-types.md


Directory structure and build chain modifications

Hello !
I think your simple library is quite cool ! I also have some system control library similar to yours, that is part of a bigger library.
I think it would be great for me to make this code more "external", and to complete yours.
What do you think of it ?
Anyway, I have made some structural modifications of the files, and replaced your compile.sh by a Makefile.

Please don't close. I'm quite busy ATM, I'll read through the changes early next week.

Sorry, since you did not answer and some of the algorithms were not compiling, I thought the project was dead. So I directly used my code as a base in this repository.


Deal with multi class problems

The ForestBinaryClassifier works with multi-class classification problems, but we cannot use #2 for multi-class problems. So, when there are K classes, the strategy is to build K trees instead of 1, which makes n_estimators * K trees total. We need to change labels to one-versus-all for each tree, and predict using normalized score. We can look that https://github.com/scikit-learn/scikit-learn/tree/main/sklearn/ensemble/_hist_gradient_boosting for inspiration

Fixed in #51


[azure-mgmt-sql] add support for SQL replica

I'm using azure-mgmt-sql 3.0.0 and i want to create a replica of an existing SQL DB but there is no such operation available.
there should be an API that supports SQL replica create/list/delete which is similar to CLI:
https://docs.microsoft.com/en-us/cli/azure/sql/db/replica?view=azure-cli-latest

Thanks for the feedback, we’ll investigate asap.


Alexa now gets confused and works erratically

This just started on 4/17 or 4/18. I believe Alexa updated itself. I have about 70 devices, most of which are z-wave. They are all duplicated. The duplicate says "Royal Philips Electronics smart device". This problem has existed for a while but the system worked properly until now.
Alexa get confused when "Turn On ...". Sometimes it says "I didn't find a device named This Device". Sometimes the action occurs but then Alexa says "The device is not responding".
All the devices with problems are set up as Vera devices though they are actually Homeseer devices. That has never been a problem.

I did also observe strange behavieour in the last 2 or 3 days. Alexa commands are changing the wrong devices. So I say Alexa turn on light A and light B is turned on.
I did also add a new device two days ago in habridge, but it is not discovered by Alexa.
The state with duplicate entries is also in my setup but as @CPM-luvr  said, this had not be a problem.

Can confirm. On 20 April 202 Alexa stopped working with my ha-bridge. Got only 'Device not responding' messages. New device is not discovered. I updated to 5.3.1.RC1 without success.

It is happening to me as well. I noticed it in the past 2-3 days that it won't dim any lights. I even tried updating it 5.3.1RC1. Deleted all devices from alexa, readded and issue still exists.

Today (24. April)  my devices were suddenly rediscovered in Alexa app but still not working; 'Device not responding'.

same here, devices can not be discovered.

I have the same problems like OP (@CPM-luvr ) since a few days. Any ideas how to solve it?

Any update on this?


(#134) Document actionpolicy implementation in README

As promised in #134 , a small doc update PR.
Update README:

Add headers, Godoc/goreport badges
Add mention of action policy

thank you :)


Broken link https://visualstudio/extend/ide/overview.md

Found in extend docs TOC

Thanks @xjlim ! This should be fixed within 5-10 minutes with the latest push and it should go here: https://docs.microsoft.com/en-us/vsts/integrate/ide/extensions/overview?view=vsts


Managing different "document type"

I need to manage different kind of documents (event, user, book).
How to manage different query based on document type ?
Do I need to add an "extra field" in all document type to specify the type of document ?

You should use multiple database files for now, since creating 'collections/tables' isn't possible (yet).

Any idea when will this be possible ? regards.

We are putting this on the roadmap for v2


Split gm out of the hermes repo

Summary

It would make sense for gm to be split out from the hermes repo and have it maintained by Cephalopod; this would be a more appropriate breakdown of responsibilities.
Acceptance Criteria

[ ] Split the gm directory out into its own repo

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[x] Contributor assigned/self-assigned

Do Cephalopod even use gm themselves? If not, then we should keep maintaining it, but I don't mind splitting it off in its own repo.

Yes they do and they are in the favour of splitting it off in it's own repo. I have started working on this.

Great!


type '(String, StringBuffer) => Null' is not a subtype of type 'Object' of 'value'

Using Dart on Flutter's master, dev, beta, or stable channels, running in the VM on Android, the following code incorrectly throws a TypeError:
  final l = <Object>[];
  l.add((String x, StringBuffer y) {
    print(x);
  });

I reproduced this on an Android Pixel emulator, using Flutter, inserting the above code in the main() entry-point.
The code does not throw an error running on iOS or on MacOS.
E/flutter ( 6922): [ERROR:flutter/lib/ui/ui_dart_state.cc(199)] Unhandled Exception: type '(String, StringBuffer) => Null' is not a subtype of type 'Object' of 'value'
E/flutter ( 6922): #0      List.add (dart:core-patch/growable_array.dart)
E/flutter ( 6922): #1      main
package:saml2/main.dart:58
E/flutter ( 6922): #2      _runMainZoned.<anonymous closure>.<anonymous closure> (dart:ui/hooks.dart:142:25)
E/flutter ( 6922): #3      _rootRun (dart:async/zone.dart:1354:13)
E/flutter ( 6922): #4      _CustomZone.run (dart:async/zone.dart:1258:19)
E/flutter ( 6922): #5      _runZoned (dart:async/zone.dart:1789:10)
E/flutter ( 6922): #6      runZonedGuarded (dart:async/zone.dart:1777:12)
E/flutter ( 6922): #7      _runMainZoned.<anonymous closure> (dart:ui/hooks.dart:138:5)
E/flutter ( 6922): #8      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:283:19)
E/flutter ( 6922): #9      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:184:12)

Reproduces on 2.13.1. Does not appear to affect dart2js, only VM.

Changing <Object>[] to <Object?>[] or <dynamic>[] avoids the error. Perhaps this helps narrow down the relevant code?

Also... I was confused by the error message is not a subtype of type 'Object' of 'value'
What does the of 'value' part mean?

The error likely comes from inside the add method, where it checks that the argument for the value parameter has the required type. Since Dart generics are covariant, methods like void add(E value) need to check their arguments at run-time, because the receiver object, of type List<Object> might have been used with a static type of List<Object?>. Passing null as argument to add in that case must be caught at run-time, because the static type system allows it.
That run-time check seems to fail here, for no good reason (a function is an Object).

Thanks for the report and the repro. I am surprised that this simple bug remained undetected until now.
CL under review: https://dart-review.googlesource.com/c/sdk/+/201863


Add symbol scope

@pchickey I did this a bit different from the scope/visibility support you added in faerie, because I think this fits Mach-O better. I didn't see where you used the faerie support in lucet, so I'm interested if this still meets the needs you had from faerie.

Coverage remained the same at 0.0% when pulling c9036fade342b80e0c054ded55242964b1e09244 on philipc:scope into 5af94a5d5d7e2d00ffde015e2363b776fafd7086 on gimli-rs:master.

This makes sense. When I designed scopes in Faerie I was really just trying to copy ELF's way of doing things, and I didn't know the first thing about Mach-O. Even for targeting ELF, I like this design better. I assume that Dynamic implies Linkage and Compilation scopes work as well on every target, and Linkage implies Compilation?

I assume that Dynamic implies Linkage and Compilation scopes work as well on every target, and Linkage implies Compilation?

Yes for ELF and Mach-O. I'm not as sure about COFF since it stores exports separately from the symbol table, but I don't it makes sense to export a local symbol.


Difference in accuracy between tensorflow DeepLabv3+ and this version

Do you know why there is a difference in accuracy between your network and the tensorflow implementation of DeepLabv3+.

I just list the possible factors in terms of the model.

What is the version of the backbone FCN?

ResNet v1, ResNet v2 (Pre-act), etc.
ResNet v1 has some variants. My v3+ implementation is based on DeepLab v2 built with Caffe. Its ResNet has 7x7 conv while the official one does not. The stride position is also different.

Pre-trained on ImageNet or/and COCO?
What is the output stride in training/testing?

Do you know why there is a difference in accuracy between your network and the tensorflow implementation of DeepLabv3+.

Hi, I'm implementing the coco pre-trained deeplabv3+. However, I got very strange results, about 7% mIoU. Would you like to provide some information for me if you could?  Thank you for your help.

Are the COCO-trained parameters successfully loaded into the backbone part (ResNet)? The strict=False option in loading weights hides name inconsistency.
DeepLab v3 and v3+ have new batch norm params inside ASPP, which are not pre-trained on COCO. Did you add them to the optimizer's param list as trainable weights?


Add some docs to gestures.dart

Also, add some missing docs to http.dart and widgets.dart.

@Hixie @krisgiesing

LGTM too, thanks!


Unknown attribute 'cpu_total_cores' for Azure provider

I'm getting this error when using najdorf-1.3. As a result I'm unable to use Azure Cloud Provider.
unknown attribute 'cpu_total_cores' for ManageIQ::Providers::Azure::CloudManager::Flavor.

Hey @kTipSSIoYv was this an upgrade?  The flavors.cpu_total_cores column was created here https://github.com/ManageIQ/manageiq-schema/pull/582/commits/f08bca479ed3d36e2ebacc0dbcd5829fe8c18c1a which is in najdorf-1.  Your database might not have been migrated after the upgrade.

@agrare No not an upgrade. I backed up Morphy database and built a new image of najdorf-1.3 and imported the database. Is that the issue?
Just to be sure I even deleted the azure provider and added it again and I got the same error.

Yes that is an upgrade (from the database's point of view).  When you move between releases (e.g. morphy -> najdorf) you have to migrate the database schema.  Within a release (e.g. najdorf-1 -> najdorf-1.3) we don't change the schema.
Take a look at https://www.manageiq.org/docs/reference/latest/upgrading_appliances/index.html
You can skip steps 1, 2, and 4 in that guide.

In Docker version I got stuck with Missing library: qpid-proton error during bundle install which was recommended.
Either way I decided to start from scratch on najdorf-1.3, added everything manually and its working.

In Docker version I got stuck with Missing library: qpid-proton error during bundle install which was recommended.

That's odd you should never have to run bundle install on a release, @Fryguy @bdunne not sure if there's something different about the Docker version but I doubt it

You shouldn't have to bundle install, everything is already in the image.
$ podman run -it --rm  docker.io/manageiq/manageiq-orchestrator:najdorf-1.3 bash
[root@0c51de504283 /]# cd /var/www/miq/vmdb/
[root@0c51de504283 vmdb]# . ./container_env
[root@0c51de504283 vmdb]# bundle info qpid_proton
  * qpid_proton (0.30.0)
	Summary: Ruby language bindings for the Qpid Proton messaging framework
	Homepage: http://qpid.apache.org/proton
	Path: /opt/manageiq/manageiq-gemset/gems/qpid_proton-0.30.0
[root@0c51de504283 vmdb]# irb
irb(main):001:0> require 'qpid_proton'
=> true

sh-4.4# cd /var/www/miq/vmdb/
sh-4.4# bundle exec rake db:migrate
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:233: warning: already initialized constant Psych::LIBYAML_VERSION
/usr/share/ruby/psych.rb:233: warning: previous definition of LIBYAML_VERSION was here
/usr/share/gems/gems/psych-3.1.0/lib/psych.rb:235: warning: already initialized constant Psych::NOT_GIVEN
/usr/share/ruby/psych.rb:235: warning: previous definition of NOT_GIVEN was here
https://github.com/ManageIQ/manageiq-ui-classic (at najdorf@c98fb3d) is not yet checked out. Run `bundle install` first.

Seems like if I run  . ./container_env then I don't get prompted for bundle install. But migration doesn't happen. Any idea why?
sh-4.4# . ./container_env
sh-4.4# bundle info qpid_proton

qpid_proton (0.30.0)
Summary: Ruby language bindings for the Qpid Proton messaging framework
Homepage: http://qpid.apache.org/proton
Path: /opt/manageiq/manageiq-gemset/gems/qpid_proton-0.30.0
sh-4.4# bundle exec rake db:migrate
rake aborted!
URI::InvalidURIError: the scheme postgresql does not accept registry part: :@: (or bad hostname?)
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/connection_specification.rb:40:in initialize' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations/url_config.rb:63:in new'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations/url_config.rb:63:in build_url_hash' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations/url_config.rb:68:in build_config'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations/url_config.rb:36:in initialize' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations.rb:191:in new'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations.rb:191:in environment_url_config' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations.rb:133:in build_configs'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/database_configurations.rb:18:in initialize' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/core.rb:51:in new'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/core.rb:51:in configurations=' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/core.rb:53:in block in module:Core'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/concern.rb:122:in class_eval' /opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/concern.rb:122:in append_features'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/base.rb:293:in include' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/base.rb:293:in class:Base'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/base.rb:277:in <module:ActiveRecord>' /opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/base.rb:27:in '
/opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require' /opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:324:in block in require' /opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:291:in load_dependency'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:324:in require' /opt/manageiq/manageiq-gemset/bundler/gems/manageiq-schema-81e87803fee9/lib/reserve.rb:1:in '
/opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require' /opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:324:in block in require' /opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:291:in load_dependency'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:324:in require' /opt/manageiq/manageiq-gemset/bundler/gems/manageiq-schema-81e87803fee9/lib/manageiq/schema.rb:11:in '
/opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require' /opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:324:in block in require' /opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:291:in load_dependency'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:324:in require' /opt/manageiq/manageiq-gemset/bundler/gems/manageiq-schema-81e87803fee9/lib/manageiq-schema.rb:1:in '
/opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require' /opt/manageiq/manageiq-gemset/gems/bootsnap-1.11.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in require'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/runtime.rb:60:in block (2 levels) in require' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/runtime.rb:55:in each'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/runtime.rb:55:in block in require' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/runtime.rb:44:in each'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/runtime.rb:44:in require' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler.rb:187:in require'
/var/www/miq/vmdb/config/application.rb:31:in <top (required)>' /var/www/miq/vmdb/Rakefile:5:in require'
/var/www/miq/vmdb/Rakefile:5:in <top (required)>' /opt/manageiq/manageiq-gemset/gems/rake-13.0.6/exe/rake:27:in <top (required)>'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/cli/exec.rb:58:in load' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/cli/exec.rb:58:in kernel_load'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/cli/exec.rb:23:in run' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/cli.rb:483:in exec'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/vendor/thor/lib/thor/command.rb:27:in run' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in invoke_command'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/vendor/thor/lib/thor.rb:392:in dispatch' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/cli.rb:31:in dispatch'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/vendor/thor/lib/thor/base.rb:485:in start' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/cli.rb:25:in start'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/exe/bundle:48:in block in <top (required)>' /opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/lib/bundler/friendly_errors.rb:120:in with_friendly_errors'
/opt/manageiq/manageiq-gemset/gems/bundler-2.3.18/exe/bundle:36:in <top (required)>' /opt/manageiq/manageiq-gemset/bin/bundle:23:in load'
/opt/manageiq/manageiq-gemset/bin/bundle:23:in `'
(See full trace by running task with --trace)

export DATABASE_URL='postgresql://localhost:5432/vmdb_production' Now it continues but aborts due to
ERROR:  relation "miq_set_memberships" already exists
{"@timestamp":"2022-08-03T09:09:47.366927 ","hostname":"aa0fcbdf7054","pid":874,"tid":"986c","service":"production","level":"info","message":"Migrating to AddMiqSetMemberships<PHONE_NUMBER>0613)"}
==<PHONE_NUMBER>0613 AddMiqSetMemberships: migrating =============================
-- create_table(:miq_set_memberships, {:id=>:bigserial})
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::DuplicateTable: ERROR:  relation "miq_set_memberships" already exists
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/postgresql/database_statements.rb:92:in `exec'
/opt/manageiq/manageiq-gemset/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/postgresql/database_statements.rb:92:in `block (2 levels) in execute'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies/interlock.rb:48:in `block in permit_concurrent_loads'
/opt/manageiq/manageiq-gemset/gems/activesupport-<IP_ADDRESS>/lib/active_support/concurrency/share_lock.rb:187:in `yield_shares'

Any idea how I can retain everything when I take backup and restore it (morphy to najdorf)?

The monolithic docker container does not have this feature because it is intended as a demo.  If you wanted to use it as a full-fledged system (which is not recommended), you would have to start the container with an external database (of which I don't think there is documentation at the moment).
Note that in the future the monolithic docker container may go away due to eventual changes in the provider worker architecture where we will have different containers for providers workers (cc @agrare)

@Fryguy I downloaded the github repo branch and used docker build command on the Dockerfile. If I use . ./container_env then bundle install isn't prompted.

@Fryguy If not monolithic can we upgrade? According to this post   upgrade isn't possible.

@agrare Our production is on monolithic docker and we want to be on najdorf when we move to Kubernetes. We can move up to morphy from lakser without issues. But from morphy to najdorf we have this issue during db migrate

@kTipSSIoYv I think your best bet is to backup your db from your monolithic container and restore it as an external db running on one of the production supported platforms (appliance or podified on k8s)

@kTipSSIoYv Can you open https://github.com/ManageIQ/manageiq/issues/22030#issuecomment-1203761012 as a separate bug ticket?  That feels like it might be a completely separate bug.

@agrare @Fryguy Any idea how I can stop the service in order to test DB migrate on Docker containers? I'm testing db migrate  on another container but I get the following error.
DETAIL:  There are 15 other sessions using the database.

@agrare @Fryguy I was able to successfully migrate from prod lasker to najdorf and dev mophy to najdorf following this documentation.
rake db:drop db:create was needed before using pg_restore. No errors were found.


query-log-enabled in config is ignored

Bug report
System info: 0.13.0, running in a docker container
Steps to reproduce:

add query-log-enabled = false to the config file
start the server

Expected behavior: No query logging
Actual behavior: All queries are output to stderr

I've verified that the config file is actually being read by running 'influxd config'.
In previous versions of influxdb, this setting eliminated query logging - in 0.13.0, every query is output no matter what the value of the setting is. This causes quite a bit of undesired log spam for us. Sadly, I can't just redirect stderr to /dev/null, since I would like to pick up any errors or other meaningful log messages and get alerts on them.

i have the same. very annoying bug

wow i've been pull my hair out on this...you'd think something this basic would work flawlessly by now


fix(ToggleSwitch): Remove buggy shadow effect

closes https://github.com/unoplatform/uno/issues/5636
PR Type
What kind of change does this PR introduce?

Bugfix

Description

PR Checklist
Please check if your PR fulfills the following requirements:

Commits must be following the Conventional Commits specification
[ ] Tested UWP
[ ] Tested iOS
[ ] Tested Android
[ ] Tested WASM
[ ] Tested MacOS
[ ] Contains No breaking changes

If the pull request contains breaking changes, commit message must contain a detailed description of the action to take for the consumer of this library. As explained by the Conventional Commits specification

/azp run


✅ 🧱 Adding API and Test for it.

Adding API call use to calculate the leaderboard of gym.
done by returning usernames and the

Adding API call use to calculate the leaderboard of gym.
done by returning usernames and the count of the badges they have earned a number of times


bake axis conversion transform on import

This simplifies exporting armatures for wimdo export and will work more seamlessly with Blender.

This will also require dealing with axes conversions for bones and and animations similar to Smash Ultimate. It should be possible to switch to octahedral display for bones.
Bone Import:
https://github.com/ssbucarlos/smash-ultimate-blender/blob/a003be92bd27e34d2a6377bb98d55d5a34e63e56/source/model/import_model.py#L371
Anim Import:
https://github.com/ssbucarlos/smash-ultimate-blender/blob/a003be92bd27e34d2a6377bb98d55d5a34e63e56/source/anim/import_anim.py#L350
Bone Export:
https://github.com/ssbucarlos/smash-ultimate-blender/blob/a003be92bd27e34d2a6377bb98d55d5a34e63e56/source/model/export_model.py#L1485


pow() of Fxp unsigned values does not work

Hi! First of all, thanks for this module, great work!
I've noticed, that Fxp does not support the power of unsigned values. The following example
a = Fxp(15, signed=False)
b = a ** 2

Generates traceback:
Traceback (most recent call last):
  File "dpd_model.py", line 16, in <module>
    b = a ** 2
  File "/home/arnfol/anaconda3/lib/python3.8/site-packages/fxpmath/objects.py", line 608, in __pow__
    y = Fxp(self.get_val() ** n, signed=self.signed or n.signed, n_word=n_word, n_frac=n_frac)
AttributeError: 'int' object has no attribute 'signed'

Which is, obviously, because integer n does not have a signed field :) I think that or n.signed is not needed here, because the sign of the number in pow does not affect the resulting sign.
I also suppose that the __pow__ method does not generate correct n_word bit size for signed values. Rigth now it multiplies  sign bit by n, which is not needed. I assume it should be like:
def __pow__(self, n):
    n_intg = self.n_word - self.n_frac - 1 if self.signed else self.n_word - self.n_frac
    n_frac = self.n_frac * n
    n_word = n_intg * n + n_frac + 1 if self.signed else n_intg * n + n_frac

    y = Fxp(self.get_val() ** n, signed=self.signed, n_word=n_word, n_frac=n_frac)
    return y

But I haven't tested it yet.

On the second thought, the resulting sign depends on n//2. So we can get rid of sign bit if n//2 == 0, but in this case return object could be signed or unsigned, depending on n. Could it be a problem?

Hi,
Thank you very much. I'm glad this module is useful for you and sorry about bug, but it is immature yet.
About the signed field in n, you are right, it's a bug considering that n is a Fxp object.
You can get the integer size of Fxp using n_int property, so, you don't need to take care about sign :) (just info)
But, you're right about in case of signed n_word = n*(n_int + n_frac) + 1 and not n_word = n*n_word
All of these makes me thing that this method is not supporting float or negative exponents (n).

About your second thought, it is not convenient return a signed or not signed object depending its val. The philosophy I choose for fxpmath is to maintain the signed type of Fxp regardless its value.
I imaging that all of these changes will be included in next release (soon)

Oh, I've noticed that my fix #18 also does not consider the cases there power n is negative. As I understand in those cases only the fractional part should be extended.

well, I update the repo and release.
This issue should be solved. I change a little bit the solution taking into account other cases.
Obs: please check in your solution if the following case works:
x = Fxp(-16)
y = x ** 2
assert y() == 256

I think one bit is missing in your solution.
Tell me please if v0.3.8 is working for you.
Thanks again!


Make requests with new metric names

Change names: earnings -> estimated_revenue, impressions -> add_impressions
Add deprecation message for old metric names

Closes #297

Aliasing wasn't enough for keeping deprecated metric names  (channel.earnings working but channel.reports only: [:earnings] not working) so close this pull request in favor of #297


SPIKE: Explore Okta <-> SendGrid workflow automation

Description
We're running into limitations with Okta's out of the box email solutions, particularly as ReportStream and SimpleReport share an Okta instance. It's not possible to customize the emails as much as we need to, especially given that the emails don't allow for any conditional logic.
Proposed solution
We reached out to Okta support for potential solutions, and they sent the following: https://help.okta.com/wf/en-us/Content/Topics/Workflows/use-case-custom-user-notifications-crm.htm
We need to do additional research on this, but the SendGrid - Okta integration seems promising. We already use SendGrid elsewhere in SimpleReport, and if it's possible to create custom workflows for different conditions (i.e., user added to RS group or SR group) this could be a good solution for us.
Additional context
https://skylight-hq.slack.com/archives/C01KGBU542K/p1634683831100500

Couple of us working on ReportStream chatted with Dale and Mike from Okta yesterday and this topic came up. They gave us a brief demo of Okta Workflows and it seems like this will solve this problem. When a new user is created, we can trigger different welcome emails based on what Okta Group they are in. Since all (afaik) SimpleReport Groups begin with "SR-" and all ReportStream groups begin with "DH" we can base the email sent off that

@sean-usds mentioned this to you in today's standup but just writing it down for posterity:

The sign up email flow stuff looks good! Also looks like it applies to any updates to their accounts as well.
Are there also similar options to differentiate what content shows up on any of the hhs-prime.okta.com/* pages, ex: login help, or password reset? Currently those pages show the SimpleReport logo.

Thank you both! I think sorting by groups within the workflow is likely our best option. @drew-usds, I'm not sure about the options available to differentiate content on the login or password reset pages, but I'll look into it.
I did just try to start enabling a workflow in our Preview account, and it looks like it's not an option that's enabled for us just yet. I got in touch with Michael & Dale, but I suspect this might be something additional we have to add to the contract 😞

Just heard back from Okta; they do indeed have to turn Workflows on but Dale doesn't have permission to do that in production. Sounds like they're working on their end to enable it.

@sean-usds and @drew-usds, Okta Workflows have been enabled in our Preview environment. I was poking around a little this morning and I think we should be able to customize it so that special activation emails are sent to RS users. Who is the best point of contact on the RS side to start working on that? I'm happy to pair with them. (Please also feel free to reach out over Slack if that's easier!)

Closing in favor of #4430


Corporate Proxy - does the usual .gitconfig work

I need to configure all network requests to use a proxy.  Is this possible with this version of git.

Yep, nogit supports proxy settings. Please see Proxy settings section in the updated readme :wink:


Section level leaf bundles use wrong page template

If I have a leaf bundle content/sec_leaf/index.md on "top-level"/"section-level", the template layouts/_default/single.html is used. The expectation would be layouts/sec_leaf/single.html (if existent).
With a branch bundle content/sec_branch/_index.md instead, everything works as expected,
and layouts/sec_branch/list.html gets used.
Reading the documentation I think that row 1 in that table applies to the leaf bundle case and the choice should be "2". However, the leaf bundle seems to fall through straight to "4". One level deeper it works as expected, choosing the template by the section which is implied by the file path. (The branch bundle case is handled by row 2 of this table where it stops at "6".)
I made a minimal example site.
BTW: Of course I can fix this with an explicit type front matter as demonstrated here.
The relevance of this issue arises from pages like "about", "contact" etc which logically are pure leaf bundles and might need different layouts.
This issue seems similar to report #5714.
What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.84.0-2C4689F7B linux/amd64 BuildDate=2021-06-18T17:14:27Z VendorInfo=gohugoio

If I have a leaf bundle content/sec_leaf/index.md on "top-level"/"section-level",

In your example the section is the root section, so to me it looks like it behaves exactly as designed.

Hmm. After consulting the .Section page variable I might agree.
If bundles are not just the files within a directory but together with the containing directory, then I need to reconsider.
The documentation can be read this way ("is a directory", "is any directory") for both bundle types.
The (top-level) branch bundles then each span a new section for themselves while the leaf bundles do not?
(Because they are "attached" directly to the root section.)
But this contradicts the documentation on sections, no? The first paragraphs there read:

A Section is a collection of pages that gets defined based on the organization structure under the content/ directory.
By default, all the first-level directories under content/ form their own sections (root sections).

A leaf bundle at this level is not included in the "default" setting then?
Does this "by default" implicitly mean: unless changed by the type front matter field?
(Uh, and another reference to "root". Then "content/" is the root and each section right beneath it is a root section, right?)
And then there is the .Section page variable carrying a note:

For nested sections, this is the first path element in the directory

which may add to this confusion as well.
If I am convinced that this "works as expected" then I need to agree with your final comment at #5714

I suspect this issue is mostly about the lookup rules being a little har do understand.

and one should clarify the documentation.
BTW: My use case arises from a single "top-level" page (like "about") where I wish to load additional content from markdown files for use within the specialized template. Now, either I make this page a leaf bundle and use *.md page resources (which I think would be the proper way) but then need to explicitly construct a section or assign a layout directly to use my template. If I make it a branch bundle instead and use GetPage (because only non-md page-resources here) I need to suppress the publication of all other md files as pages on their own in the _build options. Both ways are just 95% straight forward.

@raoulb
If you have specific suggestions to improve the documentation, pull requests are welcome at https://github.com/gohugoio/hugoDocs.
In the future, please use the forum (https://discourse.gohugo.io) for questions and troubleshooting. We prefer to use GitHub for verified bugs and vetted enhancements. Thanks.

@jmooring I gave it a try: https://github.com/gohugoio/hugoDocs/pull/1482


Update coding guidelines

Update coding guidelines to make it more concrete and useful in a review process.

Please feel free to question the content I put in the doc as well as suggest more content.

All comments are addressed. Please take another look, thanks!

@PaulHigin your comment has been addressed. Can you please take another look?

@daxian-dbw Is the PR ready to merge? (Squash and merge?)

@iSazonov Yes, I think it's ready to go.

@daxian-dbw Many thanks!


[Custom Connector] (SAML) Meta data file field is populated as a text field. This should be a place to upload the meta data file.

Describe the issue:
In the general SAML Idp connector, this is an upload file field. Making this an input field provides the following issues should impose proper validations which are missing now.

Input field is not validated in UI for empty content
When the meta data file is pasted in the field, the details cannot be saved.

How to reproduce:

Create a custom connector
Navigate to Settings and click on "Add Authenticator"
Click on the SAML authenticator
Verify the "SAML Meta Data File" field behaviour for inputs.

Expected behavior:
Either the input should be an upload file type field or proper validations should be in place
Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: [e.g., IS 5.10.0, IS 5.9.0]
OS: [e.g., Windows, Linux, Mac]
Database: [e.g., MySQL, H2]
Userstore: [e.g., LDAP, JDBC]

Optional Fields
Related issues:

Suggested labels:

This behavior is the same in the Identity Server 6.1 pack. Hence we need to implement the file picker for the meta data file from scratch.
https://github.com/wso2/product-is/assets/27746285/2d2bd3bb-9de9-4fc5-bf88-c3b7eb1651a3

Verified in the new pack


Adds first draft of agent page

Adds a first go at the PageAgent component.

Adds a AgentAttribute and AgentAttributeList component to handle the pieces of data being displayed.

A couple of things are not done yet, and I'll open separate issues for those:

Fetching data from Wiki* land. We don't have those identifiers in AS yet.
Displaying related_agents. Likewise, this data is not in AS yet.

This looks good! So exciting to get data in here. I bumped up the font size a little in the tiles to match the design treatment, and adjusted that tile type label color because the color contrast wasn't sufficient, if that's cool.
Is "Back to Search" actually a link that we're styling as a button? If I'm thinking about that right, I'm wondering if we should have a link component for that, or somehow refactor the skip link component to encompass that. Thoughts?

And should this be limiting to 6 related collections yet? I'm not seeing that in my build

OK, I added back some code which got reverted by mistake. If you pull down the most recent version the Argo development branch, you should now have collections limited to 6.
Regarding the "Back to Search" button - yes, that's a link. But so is the "Search More Related Collections", right?


Release v2.3.0 into master

will fix conflicts later!

Yup I'll check it out

The problem is the version number should match the release. This trivial issue can haunt us.
Also, we need to track the reason the version was changed from v2.3.0 to v2.3.1

Yeah agreed! So what do you recommend? Do you want me to create a new PR knowing that release/v2.3.0 was already merged into dev?
Let's live with it and make sure to never ever repeat it from now on.

The problem is the version number should match the release. This trivial issue can haunt us.
Also, we need to track the reason the version was changed from v2.3.0 to v2.3.1

Yeah agreed! So what do you recommend? Do you want me to create a new PR knowing that release/v2.3.0 was already merged into dev?
Let's live with it and make sure to never ever repeat it from now on.

Honestly, I think our job  is as good librarians and much as writers.  I have been trying to create a release story in iOS so we can feel confident that we can jog our memories on why we did what we did.
You guys should offer the reason for the dotted release because we already agreed that we want to follow semver. That is we are using the MAJOR, MINOR, PATCH for each octet.
So, even if the reason is a mistake or trivial, we need to document why the version went from v2.3.0 to v2.3.1

> > The problem is the version number should match the release. This trivial issue can haunt us.

Also, we need to track the reason the version was changed from v2.3.0 to v2.3.1

Yeah agreed! So what do you recommend? Do you want me to create a new PR knowing that release/v2.3.0 was already merged into dev?
Let's live with it and make sure to never ever repeat it from now on.

Honestly, I think our job is as good librarians and much as writers. I have been trying to create a release story in iOS so we can feel confident that we can jog our memories on why we did what we did.
You guys should offer the reason for the dotted release because we already agreed that we want to follow semver. That is we are using the MAJOR, MINOR, PATCH for each octet.
So, even if the reason is a mistake or trivial, we need to document why the version went from v2.3.0 to v2.3.1
It's going to be very difficult to convince me to leave as is. But, I'm open to listening for counter arguments.
cc: @RyanPetter @mosadialiou

@kcw-grunt According to what you shared for the release process and in a need to make this PR accepted by you (before the merge I want a full approval of all reviewers). I renamed the PR name from Release v2.3.0 into master to Release v2.3.1 into master
Does it make sense to you now?


Mention output scaling and normalization in docs

It seems that phastft and rustfft use the same "normalization factor" for outputs: $\frac{1}{\sqrt{n}}$, where $n$ is the sequence length. The rustfft docs mention normalizing outputs, and it would be nice if this were covered in the readme/docs for phastft too.

Hi @astral4,
Thank you for bringing this up. Can you please provide a code snippet that I can run to make sure I understand what you are referring to exactly? Going off of the link you provided, it says "RustFFT does not normalize outputs.". I know that as of right now, the inverse FFT in our implementation does not scale all the outputs by $\frac{1}{N}$.
Thank you!
Best,
Saveliy

Here's a demonstration:
use phastft::planner::Direction;
use rustfft::num_complex::Complex;
use std::iter::zip;

fn main() {
    // example data
    let mut real_data = [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8];
    let mut imag_data = [-0.1, -0.2, -0.3, -0.4, -0.5, -0.6, -0.7, -0.8];

   // same data, but in the format that rustfft wants
    let mut complex_data = [
        Complex::new(0.1, -0.1),
        Complex::new(0.2, -0.2),
        Complex::new(0.3, -0.3),
        Complex::new(0.4, -0.4),
        Complex::new(0.5, -0.5),
        Complex::new(0.6, -0.6),
        Complex::new(0.7, -0.7),
        Complex::new(0.8, -0.8),
    ];

    // use phastft to calculate the Fourier transform
    phastft::fft(&mut real_data, &mut imag_data, Direction::Forward);

    // convert result to facilitate side-by-side comparison with rustfft
    let phastft_results: Vec<_> = zip(real_data, imag_data)
        .map(|(real, imag)| Complex::new(real, imag))
        .collect();

    // use rustfft to calculate the Fourier transform
    rustfft::FftPlanner::new()
        .plan_fft_forward(8)
        .process(&mut complex_data);

    // log results
    println!("{phastft_results:#?}");
    println!("{complex_data:#?}");
}

phastft and rustfft reach the same answer, so I assume that both of them have the same scaling factor. The rustfft docs that I linked states that this scaling factor is $\frac{1}{\sqrt{n}}$.
Also, I don't think either phastft or rustfft scales the output by $\frac{1}{n}$ when computing the inverse Fourier transform—the rustfft docs imply that the scaling factor applies twice when you compute the Fourier transform, then the inverse, so the final scaling factor is $\frac{1}{\sqrt{n}}\cdot\frac{1}{\sqrt{n}}=\boxed{\frac{1}{n}}$. I hope this clears up any confusion!

RustFFT does not normalize outputs. Callers must manually normalize the results by scaling each element by 1/len().sqrt(). Multiple normalization steps can be merged into one via pairwise multiplication, so when doing a forward FFT followed by an inverse callers can normalize once by scaling each element by 1/len()

Hi @astral4,
The rustfft docs seem to imply there is no scaling at all. Everything must be done manually. I assume you got the same results using phastft and rustfft because phastft does not do any scaling -- all scaling is left up to the user.
Let me know if this sounds right to you. Thanks!
Best,
Saveliy

That makes sense. Thank you for the docs update!


Modify ProcessDynamicCodePolicy Value

anti-analysis/anti-av/block-operations-on-executable-memory-pages-using-arbitrary-code-guard.yml
The rule currently uses 8 for ProcessDynamicCodePolicy, but the correct value should be 2 according to documentation and observations.
I kindly request an update to the rule.
Thank you!
typedef enum _PROCESS_MITIGATION_POLICY {
    ProcessDEPPolicy,
    ProcessASLRPolicy,
    ProcessDynamicCodePolicy, // 2
    ProcessStrictHandleCheckPolicy,
    ProcessSystemCallDisablePolicy,
    ProcessMitigationOptionsMask,
    ProcessExtensionPointDisablePolicy,
    ProcessControlFlowGuardPolicy,
    ProcessSignaturePolicy,
    ProcessFontDisablePolicy,
    ProcessImageLoadPolicy,
    ProcessSystemCallFilterPolicy,
    ProcessPayloadRestrictionPolicy,
    ProcessChildProcessPolicy,
    ProcessSideChannelIsolationPolicy,
    ProcessUserShadowStackPolicy,
    ProcessRedirectionTrustPolicy,
    ProcessUserPointerAuthPolicy,
    ProcessSEHOPPolicy,
    MaxProcessMitigationPolicy
} PROCESS_MITIGATION_POLICY, *PPROCESS_MITIGATION_POLICY;

@jtothej can you confirm the proposed update?


⚠ ClamAV has degraded performance

In 470585a, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 424 ms

Resolved: ClamAV performance has improved in c08739d.


fat32 reads/writes incorrect 8.3 lowercase flags, should be case insensitive on fs.OpenFile

There are two distinct but related issues:

Lowercase filenames created with mtools are read as "lower.UPP" by go-diskfs, ie "syslinux.cfg" is read as "syslinux.CFG".  This is kind of a cosmetic issue, except for issue 2.
Because os.OpenFile doesn't ignore case when opening a file, the filename returned from above cannot be found (ie, attempt to open 'syslinux.CFG' as that was returned by fs.ReadDir, but get file not found instead)

Related to 2, I also added a test for mixed case on long file names in fs.OpenFile (verified on Linux vfat with "touch some-long-file && cat SOME-LONG-FILE").
I have a PR to raise for these issues, with unit tests.

Hi @jsando and thanks for raising this. And you opened a PR, too; we don't usually get that lucky with issues! 😄
This is interesting. So you are saying the issue is not with diskfs creating the file, as much as it is with filenames created by mtools, which then are read incorrectly by diskfs?
The whole case issue with fat32 has been painful )not just here, in general) for a long time. You kind of wish they could abandon all of that 8.3 and shortnames once and for all. Of course, then it would not be fat32, would it?
If I recall correctly, the fat32 rule is that filenames can have any case (longname), as long as the 8.3 version of it (upper-case only, limited characters, etc.) do not conflict. So JASON.TXT and jason.txt cannot both exist. In other words, those are functionally the same. It has some odd ways of dealing with files that are longer than fit in 8.3, if they conflict at <= 8 chars, but that is not the subject here.
If I understood you correctly, a simple recreation would be:

Create a fat32 filesystem
Use mtools to insert a file like syslinux.cfg - this file would then have the long filename of syslinux.cfg and the shortname.extension (8.3) of SYSLINUX.CFG
Open the filesystem with diskfs and open the file as syslinux.cfg - this fails as file not found

Is that it?

You are correct on the steps to manually recreate the issue.
However step 2 is not working as you expect:  For filenames that fit within 8.3, mtools does not create a long filename, and will set the shortname.extension (8.3) to SYSLINUX.CFG, while also setting bit 3 and bit 4 of the 12th byte in the directory entry to note that both the short name and extension are lowercase.  Go-diskfs was expecting bits 2 and 3 to be set (while also hiding a bug substituting extension for name).
Here is hexdump -C output for a directory entry written by mtools:
                                       Note byte 0x0c = 18
                                               👇🏻
00504040  53 59 53 4c 49 4e 55 58  43 46 47 20 18 00 84 bb  |SYSLINUXCFG ....|
00504050  17 59 17 59 00 00 84 bb  17 59 05 00 4a 00 00 00  |.Y.Y.....Y..J...|

Since go-diskfs is checking bit 2 for the extension instead of bit 4, it thinks the extension is uppercase and return the name 'syslinux.CFG' instead of syslinux.cfg.

Aha. That does explain it, thank you.


Format #[doc(foobar)] annotations in its original syntax, not as ///foobar?

Preamble
Rust uses #[doc(foobar)] annotations to control how code docs are rendered and it uses another syntax as an alternative to the triple slash ///: #[doc = " This is a doc comment."].
Issue
In Sway, currently, I believe, it's not possible to write useful comments using the #[doc(foobar)] annotations, because the parser expects foobar to be an identifier, and the user cannot put a string there.
Moreover, #[doc(foo,bar,baz)] gets printed as ///baz by the Sway formatter.
Possible solution
My proposal would be to

stop printing #[doc(foobar)] as ///foobar and print it in its original syntax,
add a new attribute kind (let's say doc-comment) and parse /// foo bar baz into this new attribute kind, hence decoupling doc comments from doc controlling annotations.

Any comments on this proposal are more than welcome.

Another alternative might be to desugar /// foobar into a nested comment attribute like #[doc(comment(foobar))]? This might make it a little easier to keep all doc related attributes together when they get forwarded to forc-doc, as forc-doc would only need to check for AttributeKind::Doc (and not an extra AttributeKind::DocComment)?
Either way, this sounds fine to me :+1:

@mitchmindtree It turned out to be way simpler to introduce a new attribute kind so I went with that option (we don't the support for nested attributes at the moment).
@tritao @mitchmindtree Thank you for the discussion!


project build not work from nebeans ide

Build time issue

cd E:\dev-jddict\New folder\jeddictPractice1; "JAVA_HOME=C:\Program Files\Java\jdk1.8.0_152" cmd /c """E:\dev-jddict\setup\NetBeans_IDE_9.0\java\maven\bin\mvn.cmd" -Dmaven.ext.class.path=E:\dev-jddict\setup\NetBeans_IDE_9.0\java\maven-nblib\netbeans-eventspy.jar -Dfile.encoding=UTF-8 install""
Scanning for projects...

Building jeddictPractice1 1.0-snapshot
--- maven-dependency-plugin:2.6:copy (default) @ jeddictpractice1 ---
--- jacoco-maven-plugin:0.8.2:prepare-agent (jacoco-initialize) @ jeddictpractice1 ---
argLine set to "-javaagent:C:\Users\masum\.m2\repository\org\jacoco\org.jacoco.agent\0.8.2\org.jacoco.agent-0.8.2-runtime.jar=destfile=E:\dev-jddict\New folder\jeddictPractice1\target\coverage-reports\jacoco-unit.exec"
--- maven-resources-plugin:3.1.0:resources (default-resources) @ jeddictpractice1 ---
Using 'UTF-8' encoding to copy filtered resources.
Copying 8 resources
--- maven-resources-plugin:3.1.0:copy-resources (filter-resource) @ jeddictpractice1 ---
Using 'UTF-8' encoding to copy filtered resources.
Copying 3 resources
--- maven-compiler-plugin:3.7.0:compile (default-compile) @ jeddictpractice1 ---
Nothing to compile - all classes are up to date
--- maven-resources-plugin:3.1.0:testResources (default-testResources) @ jeddictpractice1 ---
Using 'UTF-8' encoding to copy filtered resources.
Copying 4 resources
--- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ jeddictpractice1 ---
Nothing to compile - all classes are up to date
--- maven-surefire-plugin:2.20.1:test (default-test) @ jeddictpractice1 ---
file.encoding cannot be set as system property, use -Dfile.encoding=... instead

T E S T S
Running com.erp.app.controller.AccountControllerTest
Feb 06, 2019 11:14:16 PM fish.payara.arquillian.container.payara.CommonPayaraManager start
SEVERE: Could not connect to DAS on: http://localhost:4848 | Connection refused: connect
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 16.881 s <<< FAILURE! - in com.erp.app.controller.AccountControllerTest
com.erp.app.controller.AccountControllerTest  Time elapsed: 16.877 s  <<< ERROR!
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not connect to DAS on: http://localhost:4848 | Connection refused: connect
Running com.erp.app.controller.CustomerControllerTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.001 s <<< FAILURE! - in com.erp.app.controller.CustomerControllerTest
com.erp.app.controller.CustomerControllerTest  Time elapsed: 0.001 s  <<< ERROR!
java.lang.RuntimeException: Arquillian has previously been attempted initialized, but failed. See cause for previous exception
Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not connect to DAS on: http://localhost:4848 | Connection refused: connect
Running com.erp.app.controller.UserControllerTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 s <<< FAILURE! - in com.erp.app.controller.UserControllerTest
com.erp.app.controller.UserControllerTest  Time elapsed: 0 s  <<< ERROR!
java.lang.RuntimeException: Arquillian has previously been attempted initialized, but failed. See cause for previous exception
Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not connect to DAS on: http://localhost:4848 | Connection refused: connect
Results:
Errors:
AccountControllerTest.com.erp.app.controller.AccountControllerTest » Lifecycle
CustomerControllerTest.com.erp.app.controller.CustomerControllerTest » Runtime
UserControllerTest.com.erp.app.controller.UserControllerTest » Runtime Arquill...
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0

BUILD FAILURE
Total time: 01:05 min
Finished at: 2019-02-06T23:14:18+06:00
Final Memory: 17M/42M
Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on project jeddictpractice1: There are test failures.
Please refer to E:\dev-jddict\New folder\jeddictPractice1\target\surefire-reports for the individual test results.
Please refer to dump files (if any exist) [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
-> [Help 1]
To see the full stack trace of the errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.
For more information about the errors and possible solutions, please read the following articles:
[Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

Please find my config file : pom.xml and nb-configuration.xml
config.zip

Attached pom.xml contains 2 test profiles : payara-ci-managed and payara-remote, where payara-remote is default profile.
payara-ci-managed :
This profile installs a Payara server and start up the server per sample.
payara-remote :
This profile doesn't manage the lifecycle of a container but binds to an already running container means it depends on an already running application server's instance.
As per error log message, it looks like Payara server is not running so requires you to start up a Payara server outside of the build.

Could not connect to DAS on: http://localhost:4848 | Connection refused: connect


[BUG] App crashes on image save

java.lang.NullPointerException
java.lang.NullPointerException
at s6.c.a(SourceFile:168)
at ru.tech.imageresizershrinker.main_screen.t.Z(SourceFile:19)
at q6.b$a.j(SourceFile:135)
at o4.a.s(Unknown Source:8)
at f5.i0.run(Unknown Source:100)
at kotlinx.coroutines.internal.e.run(Unknown Source:11)
at kotlinx.coroutines.scheduling.j.run(Unknown Source:2)
at kotlinx.coroutines.scheduling.a$a.run(SourceFile:79)
Suppressed: f5.g0: [l1{Cancelling}@832c9f8, Dispatchers.Main.immediate]<

This issue happens permanently, every time I'm trying to save a size-reduced image.

Additional info? Android, steps to reproduce

Google Pixel 7
Android 13, root
Steps to reproduce:

Open App
Open image
Select desired quality
Press save button

I managed to "fix" the issue by manually resetting the app (clear cache and storage).

Nope. Not yet.

What happened before you spotted this issue? Selected new saving path and then?

Nope. Not yet.
Yes I did. Since the issue does not occur again since my app reset, I won't be able to reproduce the issue any longer - for now.
The issue seems to be related to deleting the exif data of any image prior to any further steps.
I just did it and the error / crash is happening again.
Even if I closed the app completely (via app manager > force stop) and then edit any image again, the crash persists.

Hmm, interesting, will check soon

Weird, on Emulator with android 13 everything works as expected...

Does this apply to all images or just one?

Does this apply to all images or just one?

Every image. Like I said, I can 100% confirm the crash always happens after performing the exif data deletion, on any random image. The process itself seems to trigger it.

Interesting, will check it again

Can you check it on this unminified apk and send log, so i will be able to find where issue occures

Hello, had you found the issue?

I'm very sorry, but I haven't been able to reproduce it lately - that's weird, as it happened in 9/10 attempts before.

Interesting, will wait for updates 👀

You may as well close this ticket for now. I can reopen it once this bug happens again.

Ok, thanks!


[release/8.2] Update NuGet and Docker dependencies (#5575)

Manual backport of #5575 to release/8.2
cc: @eerhardt
Customer Impact
Updating transitive dependency versions
Testing
Automated testing to catch regressions with new versions
Risk
Low.
Regression?
No.
Microsoft Reviewers: Open in CodeFlow

Chatted with @radical and seems like the failing tests here are flaky and have been disabled in main. Will merge to get the build ready and will cherry pick the PRs into release/8.2 that disabled those tests.


[RFE] spawn job from cronjob via button

Current situation
Currently i can look at a cronjob, but not force start it.
Impact
For the few people that prefer an UI, but need to restart a cronjob after an update or similar, they can't with this UI.
Ideal future situation
add a button to create a job from a cronjob. basically the pendant to
k create job --from=cronjob/some-cron some-cron-manual-001
Implementation options
see above
Additional information

This makes sense. We'll look into it.

Fixed. #938