Putting it together

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@f312324). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             master       #10   +/-   ##
==========================================
  Coverage          ?   100.00%
==========================================
  Files             ?         1
  Lines             ?        17
  Branches          ?         0
==========================================
  Hits              ?        17
  Misses            ?         0
  Partials          ?         0

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Enable promotion for HCP Operators into Canary env

SDCICD-992
This commits adds support to promote Hypershift Operators using the $REGION-$SECTOR approach into the Production Canary environment.
Tested Locally:
I had to use the current integration environment to make sure the logic would replace the correct env. The output matches the int environment going from "main" to the current head of AVO.
./osdctl promote saas --serviceName saas-aws-vpce-operator --hcp
The current version () is different than the latest released version (v0.16.0).It is recommended that you update to the latest released version to ensure that no known bugs or issues are hit.
Continue? (y/N): Usage: For SaaS services/operators, please provide --serviceName and --gitHash
--serviceName is the name of the service, i.e. saas-managed-cluster-config
--gitHash is the target git commit in the service, if not specified defaults to HEAD of master
Running in checkout of app-interface.
Checking 'master' branch is up to date
'master' branch is up to date
Checking if service saas-aws-vpce-operator exists
Service saas-aws-vpce-operator found
SAAS Directory: $PATH/app-interface/data/services/osd-operators/cicd/saas/saas-aws-vpce-operator/hypershift-deploy.yaml
Current Git Hash: main
Git Repo: https://github.com/openshift/aws-vpce-operator
No git hash provided. Using HEAD.
Service: saas-aws-vpce-operator will be promoted to<PHONE_NUMBER>2781baf08e88eb97eea04d76edb2e8
The branch promote-saas-aws-vpce-operator-30257036032781baf08e88eb97eea04d76edb2e8 is ready to be pushed
service: saas-aws-vpce-operator
from: main
to:<PHONE_NUMBER>2781baf08e88eb97eea04d76edb2e8
READY TO PUSH, saas-aws-vpce-operator promotion commit is ready locally

@MrSantamaria what is the state of this PR?  It's been here for five months now.  Are we going to proceed with it?


[BUG] guy this is ratware pleas don download!!! 1

Dont download pasted ratware by pazer!!Hadto reinstall windows xp becausof this malware!!! Rijin.solutions is beter bot detecterand make you invincible against bots!!!!

Shut.
Ruined the chain lol

i love how the 5yo bot maker that bought a server with mommys credit card is out here trying to tell people, that an open source project, has a rat
Real funny kid


Rewrk as a library

In quickwit we need some benchmarking tools, rather than copying everything from scratch the plan is to export rewrk's core handling into a library with some updates in order to make it more maintainable, a little faster and more useful for more applications.

Basic implementation in #38


Update DG for ListRecord and modify Birthdate field

Add new UML Sequence Diagram for ListRecord using PlantUML.
Modify Birthdate#isValidBirthdate() to check for dates later than the current date.

Codecov Report

Merging #102 (5c2468e) into master (393d04c) will decrease coverage by 0.03%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##             master     #102      +/-   ##
============================================
- Coverage     74.75%   74.71%   -0.04%
  Complexity      641      641
============================================
  Files           100      100
  Lines          1953     1954       +1
  Branches        224      225       +1
============================================
  Hits           1460     1460
  Misses          416      416
- Partials         77       78       +1

Impacted Files
Coverage Δ

...ain/java/seedu/address/model/person/Birthdate.java
78.94% <66.66%> (-4.39%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Make blockpc exploitation optional

Please add sclang support.

Done.

Google » souper #450 SUCCESS
This pull request looks good
(what's this?)

Google » souper #451 SUCCESS
This pull request looks good
(what's this?)

Google » souper #452 SUCCESS
This pull request looks good
(what's this?)

Google » souper #453 SUCCESS
This pull request looks good
(what's this?)

Is it good to squash?

LGTM. Thanks.

Google » souper #454 SUCCESS
This pull request looks good
(what's this?)


fix: NVSHAS-9442 create lease object for ArgoCD

ArgoCD doesn't support creating lease object per
https://github.com/argoproj/argo-cd/issues/12722
This change will enable k8slock to try to create lease object when the lease object is absent.

I just tried v2.8.3, which seems to be on https://github.com/neuvector/neuvector/releases/tag/v5.4.1 which includes this fix. Yet, the controller's init container is still crashing with the same error as before:
time="2024-11-19T10:19:53Z" level=info msg="Getting running namespace"
time="2024-11-19T10:19:53Z" level=info msg="init container starts" kubeconfig= namespace=cattle-neuvector-system secretName=neuvector-internal-certs
time="2024-11-19T10:19:53Z" level=info msg="Checking k8s permissions"
time="2024-11-19T10:19:53Z" level=info msg="Getting helm values check sum"
time="2024-11-19T10:19:53Z" level=info msg="Retrieved values sha256 sum successfully" checksum=cb3be9b450c3df35194bf5ab8f89dfbc2b67ff20714c7c54616f67c3af582f10
time="2024-11-19T10:19:53Z" level=info msg="Creating cert upgrade job"
time="2024-11-19T10:19:53Z" level=fatal msg="Failed to run the command" error="failed to create post sync job: failed to acquire cluster-wide lock: failed to find lease object: leases.coordination.k8s.io \"neuvector-controller\" not found"

And still have the warnings in Argo CD…

I just tried v2.8.3, which seems to be on https://github.com/neuvector/neuvector/releases/tag/v5.4.1 which includes this fix. Yet, the controller's init container is still crashing with the same error as before:
time="2024-11-19T10:19:53Z" level=info msg="Getting running namespace"
time="2024-11-19T10:19:53Z" level=info msg="init container starts" kubeconfig= namespace=cattle-neuvector-system secretName=neuvector-internal-certs
time="2024-11-19T10:19:53Z" level=info msg="Checking k8s permissions"
time="2024-11-19T10:19:53Z" level=info msg="Getting helm values check sum"
time="2024-11-19T10:19:53Z" level=info msg="Retrieved values sha256 sum successfully" checksum=cb3be9b450c3df35194bf5ab8f89dfbc2b67ff20714c7c54616f67c3af582f10
time="2024-11-19T10:19:53Z" level=info msg="Creating cert upgrade job"
time="2024-11-19T10:19:53Z" level=fatal msg="Failed to run the command" error="failed to create post sync job: failed to acquire cluster-wide lock: failed to find lease object: leases.coordination.k8s.io \"neuvector-controller\" not found"

And still have the warnings in Argo CD…

We have the same problem. If we look in the NeuVector namespace, there're no leases created. if we create the leases ourselves we see that NeuVector continues with the upgrade and eventually succeeds with the upgrade. But this should happen automatically. @holyspectral do you have any updates about this known issue?

@idogancay Can you provide some details about your environment?. Deploying NV using ArgoCD works in our environments.

Please create lease objects manually until we fix this issue,
XXX$ cat upgrader-lease.yaml
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  name: neuvector-cert-upgrader
spec:
  leaseTransitions: 0

XXX$ cat controller-lease.yaml
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  name: neuvector-controller
spec:
  leaseTransitions: 0

We are temporarily using hooks within ArgoCD and this works well, however the warnings still exist.
---
#this is a workaround for: NVSHAS-9443: Upgrade/Install through ArgoCD fails as it cannot create leases.coordination.k8s.io object.
apiVersion: batch/v1
kind: Job
metadata:
  name: create-neuvector-leases
  namespace: neuvector
  annotations:
    argocd.argoproj.io/hook: Sync
spec:
  activeDeadlineSeconds: 60
  backoffLimit: 1
  template:
    spec:
      containers:
        - name: create-leases
          image: <image>
          command:
            - /bin/sh
            - -c
            - |
              oc apply -f - <<EOF
              apiVersion: coordination.k8s.io/v1
              kind: Lease
              metadata:
                name: neuvector-cert-upgrader
                namespace: neuvector
              spec:
                leaseTransitions: 0
              ---
              apiVersion: coordination.k8s.io/v1
              kind: Lease
              metadata:
                name: neuvector-controller
                namespace: neuvector
              spec:
                leaseTransitions: 0
              EOF
      restartPolicy: Never
      serviceAccount: neuvector
      serviceAccountName: neuvector

Please create lease objects manually until we fix this issue,

Thanks for the suggested work-around, @venkateshjayagopal. Do you know of an open Issue we can subscribe to to track this? It feels strange to follow this broken PR for updates…


Rust lint and coverage on Travis

Format to fustfmt defaults and force lint check in Travis. Also move to codecov.io for test coverage and get it working again,

See https://codecov.io/gh/TheBiggerGuy/yup-oauth2/branch/rustfmt for example report. Also when https://codecov.io is enabled for this repo the README badge should change.

It seems like the travis build did succeed despite github's UI claiming it to be pending.

Thanks for doing this!


Mixer E2E MCP tests are failing

Apparently they had not passed for a long time.
https://testgrid.k8s.io/istio-postsubmits#circleci-e2e-mixer-noauth-v1alpha3-v2-mcp
https://testgrid.k8s.io/istio-presubmits#e2e-mixer-no_auth-mcp
Please fix or remove to reduce noise.

There is a pending fix: https://github.com/istio/istio/pull/9862

Fixed in master by https://github.com/istio/istio/pull/9873. General e2e-mixer auth flakiness tracked by https://github.com/istio/istio/issues/9858


Can't build main.pdf

$ make main.pdf
make -C img
make[1]: Entering directory '/home/aqw/git/paper-remodnav/img'
Rendering remodnav_algorithm.pdf
echo ./remodnav_algorithm.pdf
./remodnav_algorithm.pdf
make[1]: *** No rule to make target 'mainseq_lab_300dpi.png', needed by 'all'.  Stop.
make[1]: Leaving directory '/home/aqw/git/paper-remodnav/img'
make: *** [Makefile:10: figures] Error 2

I think this is good to close.


proposal: spec: make comparable the set of comparable types

Out of caution over backward compatibility of features introduced with generics, with little discussion with the community when changing a major proposal that had already been accepted, Go 1.18 defined the predeclared constraint comparable to be "the set of all non-interface types that are comparable." The majority of the conversation motivating the "non-interface" portion of that definition seems to have occurred in #49587, despite its rejection. That interface types are comparable but not comparable is a significant pain point for a number of otherwise fine uses of generics: e.g., one cannot use x/exp/maps algorithms on map types which have reflect.Type as keys.
#52474 has been proposed to alleviate this problem, noting that the precise definition of comparable should include types like [1]reflect.Type, which is an array type supporting == rather than an interface type. A significant portion of the comments on that proposal have noted that the entire motivation for the proposal is the inconsistency between "comparable" and comparable. I'm filing this proposal as atonement for being the primary source of those arguably off-topic arguments.
The proposal is simply to remove the term "non-interface" from the definition of comparable, so that "comparable" and comparable mean the same thing.
This allows interface types to satisfy the comparable constraint. A consequence is that it becomes possible to write generic code using comparable which panics on comparison with non-comparable concrete types. That is an aspect of the type system which has existed since long before Go 1.0. What we gain is the ability to write code generic over all comparable types, rather than most of them with no solution for the remainder.

I agree with this proposal as it is simpler than the others. For code that would like to have a call comparable that cannot panick, we can add a strict_comparable (or the same with a better name) predefined interface.

I was prototyping a spec change, and it seems compatible with the goal of this proposal, although the implementation goes more into the detail of differentiating type sets and interfaces.
To advocate stopping those incomprehension discussions, we should clarify what exactly is the problem, and I think the problem is we are limiting ourselves to a mindset that type set and interfaces are the same things, which it turns out: they are different.
Again: Interface is just an approach to define a type set, and it can embed another type set, which may be an interface, comparable, or any other future possible predeclared type set.
Therefore, in CL 401874, I attempt to clarify this and remove comparable from a predeclared type to a predeclared type set.
As a side effect, comparable is now aligned with the original type parameter proposal, that: The predeclared identifier comparable is a type set that denotes the set of all types that are comparable (this "comparable" refers to the Go 1's definition of types that are comparable). For the differences between any and comparable, simply just: depending on how they are used:
func f[T any](x T) {}         // any as type set
func g[T comparable](x T) {}
func h(x any){}               // any as function parameter

var (
    x func() = func() {}
    _ = f(x) // OK, T is infered as func(), and f is instantiated as f(x func())
    _ = g(x) // Invalid, type func() is not comparable.
    _ = h(x) // OK, h accepts anything
)

Also, this behavior remains the same as expected:
var (
	anyType        = types.Universe.Lookup("any").Type()
	comparableType = types.Universe.Lookup("comparable").Type()
)
fmt.Println(types.AssignableTo(comparableType, anyType)) // true
fmt.Println(types.AssignableTo(anyType, comparableType)) // false

@changkun FWIW I disagree that the core issue is one of how to word things. I believe the core issue is what behavior we want, i.e. a) do we want comparable to be usable as a type (#51338), b) do we want interface types to implement the comparable constraint (this proposal) and c) do we maybe want to do other changes to solve other problems associated with either (e.g. #52474, which tries to address a problem with #51338). Once we decided on the behavior we want, finding the right words to put into the spec should be easy. But we should really focus on the actual technical language changes we want, first.

@Merovius I think the wording address what we might want explicitly:

a) we disallow comparable to be used as a type (as they are not today)
b) interfaces are comparable and satisfy comparable type set (as they are in Go 1)
c) the problems are not valid if type set is just a type set. (as the generics design doesn't permit using interface to be Turing complete for defining all kinds of type sets)

@changkun What you are not doing is talking about what kind of code we want to be able to write and what that code should or should not do. #51338 and this proposal both try to address a specific problem: There is no way to instantiate e.g. type Set[K comparable] … using interface-types. They do that using concrete technical changes, which have their own, technical drawbacks, namely "comparable becomes viral" in the case of #51338 and "comparisons in generic functions might panic" in the case of this proposal. If we want to enable people to use code like Set[reflect.Type], we have to address and/or weigh these drawbacks.
None of these technical questions changes based on whether we call comparable a "constraint", a "type set" or a "type" (though TBF, we use "comparable is a type" as a short-cut for #51338). It doesn't help to demonstrate that a particular answer can be worded in the spec. We need arguments as to why a particular answer is better than the others.
IMOH the reason these discussions have become so long and convoluted is because people try to interpret what "comparable" means and/or trying to come up with new definitions of that term, instead of talking about the concrete technical questions which are on the table. Namely, what code do we want to be able to write and what should that code do.

So would interface types be included in comparable's typeset?
What would it entail?

@atdiar

So would interface types be included in comparable's typeset?

Yes.

What would it entail?

I don't understand the question.

So now how would you define interface implementation in terms of typeset?

@atdiar I don't think we should worry about how to word the change, before we have decided what the change is we want to make. It doesn't seem particularly hard to word this, to me.

It's not just about wording. It affects how we understand, compute and use typesets.
So I will rephrase because it is important.
Currently the spec says defines an interface T implementing another interface I as:

T is an interface and the type set of T is a subset of the type set of I.

How would you change it?

If you have questions about how a specific piece of code would behave under this proposal, or how a specific piece of code could be written, I feel more confident that I could answer. Personally, as I said, I think it detracts from the discussion to talk about wording (but, if someone else thinks differently, they might well try to take a stab at it, of course).

you are not doing is talking about what kind of code we want to be able to write and what that code should or should not do. #51338 and this proposal both try to address a specific problem: There is no way to instantiate e.g. type Set[K comparable] … using interface-types.

I am not because people are mixing the objectives and concepts here.
Of course I understand there is no way to instantiate a vague conceptual "comparable" type set type Set[K comparable] …. But it has no association with the existing comparable identifier, the issue is: how such a type set looks like, and what should be the name of such a type set.
The language had a definition of "comparable" types, and comparable is the set of types that are comparable.

They do that using concrete technical changes, which have their own, technical drawbacks, namely "comparable becomes viral" in the case of #51338 and "comparisons in generic functions might panic" in the case of this proposal. If we want to enable people to use code like Set[reflect.Type], we have to address and/or weigh these drawbacks.

Is it a problem with "what we want to write", or "what people would actually do"?
If we use type set comparable:
func eq(x, y comparable) bool { return x == y }

and people erase the type information using any:
var _ = eq(any(func(){}), any(func(){})) // eq(any, any)

Is the panic a language issue or a usage issue?

None of these technical questions changes based on whether we call comparable a "constraint", a "type set" or a "type" (though TBF, we use "comparable is a type" as a short-cut for #51338). It doesn't help to demonstrate that a particular answer can be worded in the spec. We need arguments as to why a particular answer is better than the others.

No. I think all of these questions arise because people start to talk about a solution without defining the scope or understanding what it exactly means. Again, the problem would be framed completely differently if the concepts are clarified. The problem would be: proposal: spec: add new predeclared type set X, Y, Z

IMHO one reason these discussions have become so long and convoluted is because people try to interpret what "comparable" means and/or trying to come up with new definitions of that term instead of talking about the concrete technical questions which are on the table.

Exactly! But how do all these questions is strong associating with the identifier comparable then?

@changkun

I think all of these questions arise because people start to talk about a solution without defining the scope or understanding what it exactly means.

"We want to be able to instantiate type Set[K comparable] … using reflect.Type" is a precise and unambiguous problem-statement. It stands in for a wider range of problems, e.g. "we want to be able to write a maps.Keys function usable with a map[reflect.Type]T". It is not a solution, it is a problem. Specifically, a problem about particular pieces of code, which are currently impossible to write.
That particular problem is addressed by #51338 (after embedding comparable in reflect.Type) and it's addressed by this proposal, by allowing type parameters to implement comparable. There might be other solutions as well, feel free to bring one up.
But the problem statement is very clear: We want to write specific generic functions, which are currently impossible to write.

"We want to be able to instantiate type Set[K comparable] … using reflect.Type" is a precise and unambiguous problem-statement. It stands in for a wider range of problems, e.g. "we want to be able to write a maps.Keys function usable with a map[reflect.Type]T". It is not a solution, it is a problem. Specifically, a problem about particular pieces of code, which are currently impossible to write.
That particular problem is addressed by #51338 (after embedding comparable in reflect.Type) and it's addressed by this proposal, by allowing ~type parameters~ interface types to implement comparable. There might be other solutions as well, feel free to bring one up.

Still, I have the feeling that you maintained in the mindset that type set and interfaces are the same. As the CL attempt to clarify: interface can be used to define a type set. But there are type set that cannot be written or implemented using interface, such as comparable.
If we want to solve a particular problem to instantiate type Set[K comparable] … using reflect.Type, it is better to clarify that the problem is:
proposal: spec: add a predeclared type set magicset
so that we can  type Set[K magicset] ... and reflect.Type is an element of the type set magicset.

But the problem statement is very clear: We want to write specific generic functions, which are currently impossible to write.

Of course there are so many generic function we want to write and currently impossible to write. But why mix up with the comparable?

If you have questions about how a specific piece of code would behave under this proposal, or how a specific piece of code could be written, I feel more confident that I could answer. Personally, as I said, I think it detracts from the discussion to talk about wording (but, if someone else thinks differently, they might well try to take a stab at it, of course).

I'm still asking because without proper definitions, we don't know what we are talking about.
So under the proposed, updated, comparable,
type M struct{
   Name string
   Map map[string] interface{}
}
type Set[T comparable]...

How is it decided that M cannot be a value for the type argument?
Do we still use typeset inclusion?

This is a joke: maybe we should revisit the previous abundant contract design. Now we know that there is a clear difference between what is a contract and what is an interface. Because interface can implement a contract, but a contract is a contract.

If we want to solve a particular problem to instantiate type Set[K comparable] …  using reflect.Type, it is better to clarify that the problem is:
proposal: spec: add a predeclared type set magicset

That might be a solution to the problem. Feel free to file such a proposal. I disagree that it is better to say that is the problem. The problem is "we can't instantiate type Set[K comparable] … using reflect.Type" as an example of a broader problem of using interface types in generic code which needs to do comparisons.

@atdiar

How is it decided that M cannot be a value for the type argument?

The spec defines which types are comparable. Map types are categorically not comparible, so neither are struct types with map fields. This proposal only suggests changing whether or not interface types do or do not implement comparable, it does not talk about map types. So your example seems irrelevant to this discussion.

I disagree that it is better to say that is the problem. The problem is "we can't instantiate type Set[K comparable] … using reflect.Type" as an example of a broader problem of using interface types in generic code which needs to do comparisons.

Maybe. But that's not a strong enough argument to complicate the definition comparable type set. For such a problem we might simply mark it as "Hold".

@atdiar

How is it decided that M cannot be a value for the type argument?

The spec defines which types are comparable. Map types are categorically not comparible, so neither are struct types with map fields. This proposal only suggests changing whether or not interface types do or do not implement comparable, it does not talk about map types. So your example seems irrelevant to this discussion.

Just follow me for now. By the spec definition, M also implements comparable since it implements any and any is implementing comparableso what gives?
Should we use typeset inclusion to constrain type parameters or is there now something else we use?

@atdiar FWIW the proposal is to strike the "non-interface" and "is not an interface type" from the section about comparable. I disagree that with  that change, M would implement comparable, as it is not an interface type and does not support == and !=.
But again, that doesn't matter right now. We need to decide if we want to do this. We can always figure out how to word it, after we decided that. We can always fix ambiguities and conflicts, once we actually know how we want the language to behave. We can find words to describe whatever semantics we want. We are doing that all the time. It's just not a problem.

@changkun I think the spec changes you propose contain some unneeded changes as well. We came from contracts to interfaces to interfaces as type sets, I don't think we can go back now easily. The only change we need is this one:
The predeclared identifier comparable is a type set that denotes the set of all types that are comparable (this "comparable" refers to the Go 1's definition of types that are comparable).

@Merovius , @atdiar what are you going on about? You can agree with this proposal or oppose it but it seems besides the point. This proposal is to make the generic comparable and the pre generic comparable identical, for simplicity. It will have the benefit of making generics much easier to reason about.

@atdiar FWIW the proposal is to strike the "non-interface" and "is not an interface type" from the section about comparable. I disagree that with that change, M would implement comparable, as it is not an interface type and does not support == and !=.
But again, that doesn't matter right now. We need to decide if we want to do this. We can always figure out how to word it, after we decided that. We can always fix ambiguities and conflicts, once we actually know how we want the language to behave. We can find words to describe whatever semantics we want. We are doing that all the time. It's just not a problem.

I disagree. We can't sweep everything under a rug. There are moving pieces and changing one of them may impact everything else.
The spec clearly says that:

Implementing an interface
A type T implements an interface I if

T is not an interface and is an element of the type set of I; or
T is an interface and the type set of T is a subset of the type set of I.
A value of type T implements an interface if T implements the interface.

With the proposed change, M would therefore be a member of comparable typeset.
So typesets would not be constraining anymore. That would be a failure of typeset as way toward bounded quantification.
I am merely asking, how do you propose to resolve this incongruency?
I have an idea that I have already mentioned in other issues. But that seems to have flown over people's head too.
In short, the proposed change can't work if comparable is an interface. We would need to extend the concept of constraint to be a superset of constraint interfaces.
So we either keep comparable as it is and we add something else, or we change comparable but it requires more than just what is in this proposal.
@beoran there is an issue with this proposal and I am trying to explain why I think so. The end goal may still be legible.

@beoran I understand that. FWIW it was my first suggestion when the problem came up as well.

We can always figure out how to word it, after we decided that. We can always fix ambiguities and conflicts, once we actually know how we want the language to behave. We can find words to describe whatever semantics we want. We are doing that all the time. It's just not a problem.

I'm afraid I have to disagree with the view that wording doesn't matter. Appropriate terminology shapes our understanding and resolves miscommunication. All these discussions are happening because people have different understanding regarding comparability, and comparable is now identified might be a "bad" wording.
It is also now we want to write, it is what we want to help the Go team to address the pressing issue at the moment. As long as Go 1.19 goes out, more developers will start to confuse about comparable.
For the Go team, I think the real problem is what is the most consistently wording to align with the existing language, stick to the original proposal regarding comparable seems to be the simplest way because that is where people will look in order to understand the new generics feature, unlikely the formal spec. This also permits the Go team and us to figure out what might be the next name for another comparable and what it means exactly.

@atdiar
Could you please explain why there is a problem with this proposal because I don't see it.
@Merovius I first didn't like the idea that the == operator could panic, but all other approaches end up with two different concepts of comparability, which is unacceptably confusing. I am mentoring beginning Go programmers at my day job, but I postponed even using generics because now they would be too hard to explain.
@changkun correct wording is essential for technical documents like the spec. On point is that we should not give the same name for two different or slightly different concepts. The comparable constraint, and the concept of Go compatibility are as it is now confusingly similar. So we propose here to make them actually the same.

@beoran
It makes the definition of interface implementation invalid.
For the recall,

A type T implements an interface I if
T is not an interface and is an element of the type set of I; or
T is an interface and the type set of T is a subset of the type set of I.
A value of type T implements an interface if T implements the interface.

It would mean that any's typeset is a subset of comparable typeset.
But functions, maps, slices, and some composite types that are in any typeset are not in comparable's typeset.
So there is a problem.
It's related to the fact that

supports the operations == and !=;

is what we would like to use to define comparable. This would be a predicate, but I'm arguing that while it is constraining, it should not define an interface/typeset.
I can expound on the ramifications but that's in a nutshell.

@atdiar Thanks for the explanation, but i would think that it is opposite, namely that the type set of any is a superset of
the type set of comparable, since all comparable also match any, but not all any are comparable in the classic Ho sense of the word.
When they were introduced, I was against type sets because they seemed to be a concept that complicate generics. It is hard to go back on this decision but maybe we can explain the current behavior of the Go language in different ways?

@beoran that's the issue. Our intuition is telling us that but once things become formalized, there are issues :
Why would that rule break when it works perfectly for other interfaces?
For instance, with basic interfaces;
type ReaderWriter interface{
   Read()
   Write()
}

type Reader interface{
   Read()
}

type RC struct{}
func(r rc) Read(){}
func(r rc) Close(){}

ReaderWriter implements Reader. All the types that implement ReaderWriter  implement  Reader. So the typeset of ReaderWriter is a subset of the typeset of  Reader.
But we can't say that every type that implements Reader implements ReaderWriter ( proof: the existence of RC)
Now, by substitution, if any implement comparable, the typeset of any is a subset of the typeset of comparable. (unless I've made a msitake somewhere which happens)
I don't think that typesetsare the problem. They are needed. Typesets are actually quite a nice way to provide "bounds".
The issue is that with this proposal comparable builds a set of types that is not a typeset because it uses a different Domain.
So again, comparable should not be an interface with the proposed change.
I'm happy to stand corrected if someone thinks otherwise.

@changkun

To advocate stopping those incomprehension discussions, we should clarify what exactly is the problem, and I think the problem is we are limiting ourselves to a mindset that type set and interfaces are the same things, which it turns out: they are different.

I tried to point this out in https://github.com/golang/go/issues/43651#issuecomment-774607611 and opened #44235 to try to emphasize that difference. There was little support, especially from @ianlancetaylor and @griesemer. I think now I agree with their points overall, because I have not had to do the kind of teaching I was concerned about. In my experience, people aren't getting confused about the differences between interfaces as types and interfaces as constraints. They're getting confused about why interface types don't satisfy comparable.

@atdiar

It makes the definition of interface implementation inconsistent. For the recall,

A type T implements an interface I if
T is not an interface and is an element of the type set of I; or
T is an interface and the type set of T is a subset of the type set of I.
A value of type T implements an interface if T implements the interface.

It would mean that any's typeset is a subset of comparable typeset. But functions, maps, slices, and some composite types that are in any typeset are not in comparable's typeset. So there is a problem.

Logically, this is a good point. I am saying that any should implement comparable, therefore – by the existing language of the spec – the type set of any must be a subset of the type set of comparable, but there are types in any not in comparable, a contradiction.
This does not change the goal of this proposal, which is to allow using interface types as type parameters constrained by comparable. It does illustrate that there is more to change in the spec than I claimed, which would be to simply strike "non-interface" from the definition of comparable. I have ideas about how to solve that problem, but I would prefer to reach a consensus about exactly which problem should be solved before I suggest them. I'll update the proposal to mention that the spec changes would be more pervasive.

@atdiar

It makes the definition of interface implementation inconsistent. For the recall,

A type T implements an interface I if
T is not an interface and is an element of the type set of I; or
T is an interface and the type set of T is a subset of the type set of I.
A value of type T implements an interface if T implements the interface.

It would mean that any's typeset is a subset of comparable typeset. But functions, maps, slices, and some composite types that are in any typeset are not in comparable's typeset. So there is a problem.

Logically, this is a good point. I am saying that any should implement comparable, therefore – by the existing language of the spec – the type set of any must be a subset of the type set of comparable, but there are types in any not in comparable, a contradiction.
This does not change the goal of this proposal, which is to allow using interface types as type parameters constrained by comparable. It does illustrate that there is more to change in the spec than I claimed, which would be to simply strike "non-interface" from the definition of comparable. I have ideas about how to solve that problem, but I would prefer to reach a consensus about exactly which problem should be solved before I suggest them. I'll update the proposal to mention that the spec changes would be more pervasive.

🙂
That's what I have been explaining in a couple issues now 🥵.
If I read the comment by @griesemer in your issue #44235 there would be space left for constraints that are not interfaces if that's the direction that is picked.

The one case where I can see it mattering in practice, that any would implement comparable, while its type-set is not a subset of comparable, is if we also adopted #51338. Because in that case, you have any implement an interface type, but not be assignable to it. If we don't, I don't believe there is any confusion in practice. That is, it's not possible to write a program which does not behave according to expectation.

@atdiar
Thanks for your explanation. However, if I substitute any and comparable as in the example below then the type set of  comparable should be a subset of the type set of any.
Perhaps this conflicts with the spec, but it doesn't make sense in any other way. Practically, the type set of any in a Go program are ALL types that exist in that program. Comparable should necessarily be a subset of that, and ad this proposal states it should be the set of all types that exist in a program which are compatible in the classic Go sense.
https://go.dev/play/p/ARD_6ksE9qU
package main

import "fmt"

type Comparable interface {
	Equals(c Comparable) bool
}

type Any interface {
}

type IsComp struct{ i int }

func (ic IsComp) Equals(c Comparable) bool { return ic.i == c.(IsComp).i }

type NoCmp struct{ i int }

func main() {
	var cmp Comparable = IsComp{7}
	var cmp2 Comparable = IsComp{7}
	var anyCmp Any = IsComp{9}
	var anyNo Any = NoCmp{5}
	fmt.Println(cmp, anyCmp, anyNo, cmp.Equals(cmp2))
}

@beoran
I'm well aware of that. It just means that the typesets are equal. Which is still problematic.
@Merovius
It matters depending on how constraints are being checked by the compiler in practice. If it's mere typeset inclusion, there is an issue.
Also if we want to use constraint interfaces as types more generally as you mention. (which could spill over into discussions over union interface elements as sum/union types etc.)
There is some path dependence in the decisions that are taken.

@atdiar The compiler can always special case comparable, if need be. That seems like an overeager worry at this point.

@atdiar The compiler can always special case comparable, if need be. That seems like an overeager worry at this point.

I wouldn't be so sure. I might be mistaken but I imagine it could interact with interface elements in the determination of typesets when embedded. (provided comparable remains an interface)
Instead of overeager, I would say cautious. 🙂

I'm confident that this is not a problem. In particular, the plan is not to change anything about this:

A union (with more than one term) cannot contain the predeclared identifier comparable or interfaces that specify methods, or embed comparable or interfaces that specify methods.

Which is the only source of such problems I could imagine. Ultimately, it guarantees that comparable only ever appears as an extra conjunction term (if at all) in the constraint, which is easy to handle.

I'm confident that this is not a problem. In particular, the plan is not to change anything about this:

A union (with more than one term) cannot contain the predeclared identifier comparable or interfaces that specify methods, or embed comparable or interfaces that specify methods.

Which is the only source of such problems I could imagine. Ultimately, it guarantees that comparable only ever appears as an extra conjunction term (if at all) in the constraint, which is easy to handle. So I'll stay with overeager worry.

If that suits you.
That's typically has a conjunction term in constraints that I see an issue.
If we wanted to ever use that constraint as a type...
But anyway, I don't seem to appear to convince you that the path dependence of all those decisions warrants caution.

But anyway, I don't seem to appear to convince you that the path dependence of all those decisions warrants caution.

FTR, I've been pretty vocal that I don't think we should both accept this proposal and #51338, exactly because I believe they have bad interactions. I just don't think the problem is a) how we write this proposal into the spec or b) how we would implement this proposal. This proposal, itself, is fine.

My point is that we still "might" want both. For instance, if we think that it could be amenable to an implementation of sum/union types as typesets.
But for this to occur, the current proposal would have to change ever so slightly so that typesets remain computable.
So I do think that advertising caution would be wiser here.

I think there are many good reasons not to have both. For example

As has been brought up above, it is confusing for any to implement comparable, but not be assignable to it. And
If we want #51388, we also probably want struct{ any } not to be assignable to comparable. Because comparing that type could still panic and the actual point of having that type would be to statically prevent comparisons from panicing. But with this proposal, struct{ any } would/should definitely be assignable to comparable.

I think these are very good, technical reasons not to have both #51338 and this proposal. Personally, I will vehemently oppose doing both, for these reasons (and others).
But If we wanted to have both, we can figure out how to word that in the spec. And there is no reason to believe we would have difficulty implementing whatever we come up with.

Well we perhaps could have both in a sense if this new comparable you are advocating for is not an interface albeit still a constraint. This is the whole point. That it can't intervene is the computation of typesets. If this is doable.

But If we wanted to have both, we can figure out how to word that in the spec. And there is no reason to believe we would have difficulty implementing whatever we come up with.

Not everything is so trivial or we wouldn't go back and forth on these issues.

Well we perhaps could have both in a sense if this new comparable you are advocating for is not an interface albeit still a constraint.

Given that the point of #51338 is to have comparable be an interface type, are you saying we should have two flavors of comparable, one which is only usable as a constraint and one which is only usable as a type? In that case, I don't think that's a good idea either. It seems more confusing than any other of the options considered. And I don't think spelling comparable differently in one context from another solves the fundamental issues with it.
That is, even if they are different things, that still wouldn't change the fact that comparable in a constraint means "any type which can be compared" and comparable as a type would mean "may contain any value which has panic-free comparisons" and they would still be perceived as the same thing, so the issues would be the same.
This really seems to take the worst of both worlds and the good of neither.

Given that the point of #51338 is to have comparable be an interface type, are you saying we should have two flavors of comparable, one which is only usable as a constraint and one which is only usable as a type? In that case, I don't think that's a good idea either. It seems more confusing than any other of the options considered. And I don't think spelling comparable differently in one context from another solves the fundamental issues with it.

Almost but not exactly.
One would be a constraint.
The other would be a constraint interface with the semantics of the current comparable. Since it would be an interface, we could potentially make it a regular type as well. It would probably not be used as a constraint that often but maybe I'm wrong to think that way. *See issue linked below. It wouldn't interact with typesets in degenrative ways.
I'm not necessarily saying that we "need" to have both. But we might want to carve out space so we "can" have both.
The priority to solve the current issue would be the one that is only a constraint and not an interface.
(*) I'm not so sure it would be that confusing. People have already asked for something similar. (see #49587) btw.

Now, by substitution, if any implements comparable, the typeset of any is a subset of the typeset of comparable. (unless I've made a mistake somewhere which happens)

This is reversed: Under the current rules, if the typeset of any is a subset of the typeset of comparable, then any implements comparable.
The typeset of any is not a subset of the typeset of comparable, therefore under the current rules, any does not implement comparable.
This proposal is to add a rule stating that interfaces implement comparable. This doesn't require adding interface types to the typeset of comparable. And I don't think interface types should be in the typeset of comparable, since that'd break the existing property that an interface type's typeset never contains an interface type; it suffices for all interface types to implement comparable.

Nice find! I did make a mistake after all, ha!
Yes, I don't think that interface types should ever be included in typesets either.
However, I did have the false assumption that typeset inclusion and interface implementation was an equivalence.
It assuredly won't be if we adopt this rule as it definitely won't be symmetric.
The non-symmetry does describe that there are operations available to interface types that are not available to the members of their respective typesets.
The only potential issue I can see is that there would be no way to assert that a comparison is panic-free.
Even more flagrant if we think that one day, we should be able to use something such as interface{ int | []byte } in regular Go code.

This proposal was where we started in #50646.  As discussed there, it seems to lead to strange situations like
func Eq[T comparable](a, b T) bool { return a == b }
func F() {
    Eq(0, 0) // ok
    Eq([]int{}, []int{}) // compilation error
    Eq(any([]int{}), any([]int{})) // compiles OK, panics at run time
    Eq[any]([]int{}, []int{}) // compiles OK, panics at run time
    Eq[any]([]int{}, 0) // compiles OK, runs OK, returns false
}

And it gets even odder.  We need to consider the case where we instantiate using a type parameter.
func G[T any](a, b T) {
    Eq(a, b) // T is constrained by any so T could be []int, so, not OK?
    Eq[any](a, b) // OK, may or may not panic at run time
}

These considerations are what pushed us to the current spec, in which you can't instantiate a type parameter constrained by comparable with an interface type.  That leads to some difficulties with certain kinds of code, as we know, but it doesn't seem to lead to confusion.

it seems to lead to strange situations

If Eq is explicitly instantiated using any:
Eq(any([]int{}), any([]int{}))
Eq[any](a, b)

Why is it strange, and how could it expecting not to panic at run time as Eq(any, any)?

It's strange because the most important point of generics is better static type checking.  We can construct an argument explaining why the behavior is correct, but it feels strange.

It's strange because the most important point of generics is better static type checking. We can construct an argument explaining why the behavior is correct, but it feels strange.

I understand the goal for static type checking, but isn't here just a consequence of instantiating through a dynamic type any? Shouldn't the user be aware of the consequence?

@changkun
Eq(any(string("")), any(string("") )) // no panic
Eq[any](a, b)

Not exactly a direct consequence because it would panic with some uses and not some others, I think.
This is a good point. I think @bcmills had made the same.

@ianlancetaylor All these problems seem to be coming from instantiating a type parameter constrained by comparable with any. Why not just disallow that and only that. It doesn't even seem to make sense to use any here since that isn't comparable.

@ianlancetaylor

We can construct an argument explaining why the behavior is correct, but it feels strange.

I think the argument "the function behaves the same as if you manually wrote it out substituting the type arguments" is a pretty simple argument to explain the behavior - and it's how type parameters should work in general. And to me, it also feels strange if I can't reverse this to get to a generic function.
I agree that from first principles, we'd probably design the language to be stronger here. But from the language as it exists today, I don't think the behavior you point out is particularly strange.
That being said, I'm at the point where I can live with both #51338 and this proposal (as long as we don't do both).

I really like the idea of making comparable the keyword consistent with "comparable" the concept (so really like this proposal as written).
It would (I think) solve an oddity I noticed when first playing with generics (that @Merovius and I discussed here: https://github.com/golang/go/issues/43651#issuecomment-759991834):
// works
func Equal(a, b interface{}) bool {
  return a == b
}

// does not compile
func Equal[T interface{}](a, b T) bool {
  return a == b
}

That said, I would go much further. The addition of comparable to the language adds a lot of complexity, and the number of invalid programs that it would catch is comparatively small. It seems like a much more "go" approach would be to treat any generic type as comparable, and fail at runtime. (though the ship may have sailed there)

@beoran The same problems occur with reflect.Type, ast.Node or io.Reader, so I disagree that they are specific to any. I also don't think we should make any more special than other interface types.

strange situations

I don't see anything strange about these situations. A type parameter instantiated with any behaves exactly like a non-parameterized any parameter.
func EqA[T comparable](a, b T) bool { return a == b }
func EqB(a, b any) bool             { return a == b }

func F() {
    EqA(0, 0) // ok
    EqB(0, 0) // ok

    EqA([]int{}, []int{}) // compilation error
    EqB([]int{}, []int{}) // panics at run time

    EqA(any([]int{}), any([]int{})) // compiles OK, panics at run time
    EqB(any([]int{}), any([]int{})) // compiles OK, panics at run time

    EqA[any]([]int{}, []int{}) // compiles OK, panics at run time
    EqB([]int{}, []int{}) // compiles OK, panics at run time

    EqA[any]([]int{}, 0) // compiles OK, runs OK, returns false
    EqB([]int{}, 0) // compiles OK, runs OK, returns false
}

Perhaps it's strange that == can panic, but that decision was made long ago. But in the above example, EqA[any] is identical to EqB: It panics in the same cases EqB panics, and for the same reason.

I think it could work although I am still a bit uneasy.
How would type assertions to comparable work?
It is still strange in my opinion to create a function that may panic for the same variables passed as argument depending on the call site.
EqB would probably handle this differently, like reflect. DeepEqual.
It might also still interfere with the available space for other potential language features but that's just me trying to be future-proofing perhaps.

How would type assertions to comparable work (if even possible) ?

They would not. Under this proposal, comparable is not a type, so there would be no type-assertions to it.

It is still strange in my opinion to create a function that may panic for the same variables passed as argument depending on the call site.

That's just how Go works.

But where it could be truly confusing is that in a generic function constrained by any, one may use maps constrained by comparable for instance.

I don't understand what you mean here.

It is still strange in my opinion to create a function that may panic for the same variables passed as argument depending on the call site.

It occurs to me that you meant "it panics depending on whether you explicitly instantiate it". That's still possible in current Go, though I admit that it's a bit "stranger".

Also, FWIW

How would type assertions to comparable work (if even possible) ?

If we would make comparable a full type, the type-assertion would presumably succeed, if the dynamic type of the interface value is comparable. The dynamic type is never an interface-type, therefore this proposal has no influence over how that would work.

So there would be no way to check whether a comparison will panic by testing the dynamic type? 😕
What I meant corresponds to the last part of @ianlancetaylor 's comment https://github.com/golang/go/issues/52509#issuecomment-1109277211
People could easily create generic functions that  use  internal maps but whose type argument is constrained by any?
That would only fail depending on what type is passed at instantiation?

It is still strange in my opinion to create a function that may panic for the same variables passed as argument depending on the call site.

It occurs to me that you meant "it panics depending on whether you explicitly instantiate it". That's still possible in current Go, though I admit that it's a bit "stranger".

I think my reasoning was a bit more basic as I was thinking about variable reassignment.
This is definitely something that can occur in normal go code using map[any]any as an example.
Re. your example, that's actually much more interesting a behavior.

So there would be no way to check whether a comparison will panic by testing the dynamic type?

There is no way to do that today either.
FTR, as I said a couple of times now, for exactly reasons like that, I am against adopting both this proposal and #51338.

People could easily create generic functions that use internal maps but whose type argument is constrained by any?

If I understand correctly, your concern is that a generic function with unconstrained type-parameter (i.e. func F[T any](…)) could still create a map[T]X (for whatever X)? In that case, no. Writing map[T]X would still require T to be constrained to comparable. But you could write map[any]X instead and then store a T in there, without having to further constrain it. As you can today.

I understand although, today, the implementation of comparable ensures there is no panic so it is not needed.
And yes, about maps, I was actually being confused because  the concepts of interface implementation and constraint satisfaction are now different. Implementing an interface doesn't mean satisfying the constraint.
Not sure I like it.

I retitled and updated the proposal to more precisely ask for what I'm asking for. I agree now that just saying "make interfaces comparable" is not sufficient.
When I have some time, I will also draft the exact changes to the spec I would propose to implement the goal of this issue. As a measure to reduce noise for the proposal review team, I intend to write my concrete spec change as a comment on this issue and link to it in the proposal.

See #52614 for another take on this problem.

Note that testing the dynamic type of a value is in general not sufficient to determine whether a comparison would panic.

I've filed #52624 as a counterproposal that does provide a type-assertion sufficient to prevent run-time panics.

Here is a specification change I believe would implement this proposal. We introduce a new relation 'satisfies' between types. The section Implementing an interface becomes (italic indicates changes):

Implementing and satisfying an interface
A type T implements an interface I if:

T is not an interface and is an element of the type set of I; or
T is an interface and the type set of T is a subset of the type set of I.

Additionally, T satisfies I if:

T implements I; or
T is an interface with at least one comparable type in its type set, every element of the type set of I is comparable, and the comparable subset of the type set of T is a subset of the type set of I.

Then, the section Instantiations changes:

After substitution, each type argument must satisfy the constraint (instantiated, if necessary) of the corresponding type parameter. Otherwise instantiation fails.

In writing this, I tried to achieve three goals:

Interfaces may instantiate comparable type parameters.
Interfaces are not in the type set of comparable, to avoid the contradictions already known.
comparable remains an interface.

In general, I believe any implementation of this proposal which avoids contradictions will require either a new relation between types and interfaces or a new thing which is a type set but not an interface. The latter is related to #52531, and @atdiar has suggested it more directly in comments elsewhere. I prefer the former, because I think it leaves more room for a consistent realization of #51338 and any other future proposal to allow values of interface types which currently cannot have values.
If we do not add the 'satisfies' relation but add its extra rule to 'implements', then I believe we get something quite like #52614.

I would define implements in term of satisfies:
A type T satisfies an interface I if T is a member of the type set of I.
A type T implements an interface I if:

T is not an interface and T satisfies I; or
T is an interface and the type set of T is a subset of the type set of I

I would keep your s/implements/satisfies/ edit to instantiations.
I would and define (somewhere) that the type set of comparable is the subset of types that match the definition of comparable in https://go.dev/ref/spec#Comparison_operators
Interfaces are still in the type set of comparable but they're also in the type set of any. That's okay because the division between satisfies and implements makes it clear that interface types impose additional restrictions on the type set.
This would mean that comparable can result in runtime panics but since comparable is already defined in the spec and stdlib (reflect, go/types) this is nothing more or less than what we already deal with now with non-generic code.
It may be possible to define a stricter type set that's the "safe" subset of comparable but, if so, I think that should be given a separate name as it is a new concept that's not already in wide use.

@griesemer from #52614:

We currently don't have a mechanism to describe type sets that include interfaces.

Would the change I sketched in the post above provide a sufficient mechanism?

@jimmyfrasche

Would the change I sketched in the post above provide a sufficient mechanism?

I don't know (I'd have to read the entire proposal again and apply all comments to deduce the latest rules.) But from a 10,000 ft perspective it seems to me that using two different relations ("satisfies" vs "implements") depending on context is going to lead to trouble. We have concrete types (T), interfaces (I) and type parameters (P) and we have to give rules for all combinations: T rel I, T rel P, I rel I, I rel P, P rel I, P rel P, where rel is one of "implements" or "satisfies" . It would be helpful if somebody who believes they understand this proposal wrote not only explains what "implements" and "satisfies" means but how they apply in all these cases (and ideally show that they cannot lead to inconsistencies).
For comparison, right now we have only one case: "implements" and "satisfies" mean exactly the same, and the meaning is always the same no matter if we have concrete types, interface types, or type parameters: x implements y if the type set of x is a subset of y. (The type set of a concrete type is just that type.)

I think the way I would implement this is

Allow type sets to include interface types. Define typeSet(I) for an interface type I based on the definition ("all types with methods X,Y,Z, having types one of L,~M,~N…").
Say (using the naming conventions @griesemer sets out)

var A T is assignable to I, if T∈typeSet(I)
var A I1 is assignable  I2, if typeSet(I1)⊂typeSet(I2). The assignment assigns the dynamic value of I1 (or nil) to the I2 (this guarantees that the dynamic type of an interface is never an interface type).
var A P (with [P C]) is assignable to I, if typeSet(C)⊂typeSet(I). The assignment behaves as if the type argument was substituted (i.e. it assigns the dynamic value, if the type argument is an interface)
var A T can instantiate F[B C], if A∈typeSet(C)
var A I can instantiate F[B C], if I∈typeSet(C)
P (with [P C1]) can instantiate F[_ C2] if typeSet(C1)⊂typeSet(C2). The instantiation behaves as if the type argument (for P) was substituted

(note for clarity: A "type parameter" is, to me, what is in the type parameter list in the function declaration. A "type argument" is what was passed to the instantiation of the function. I think that terminology is established, but just to be sure)
This doesn't use "implements" and "satisfies", but the meaning is kind of the same. It would require writing down the cases in the appropriate sections (i.e. in the assignability section), instead of making up a term for one of these relationships and then using that term to say when an assignment is allowed.
It might be possible to still do that. Perhaps we can use "implements" or "satisfies" for ∈typeSet(A) or ⊂typeSet(A) and then use that. If that can be done consistently. But I don't think it's vital to do that, a lot of the spec already does this kind of detailed listing.
It would be possible to add typeSet(T) = {T} for non-interface types. This would make T∈typeSet(I) equivalent to typeSet(T)⊂typeSet(I) and allow us to unify the assignability-rules into one (though it would be a bit awkward to talk about the assignment of dynamic values). That gets traded off with the instatiation rules though, where we specifically don't want to use ⊂ for the interface case. The way it is written right now is more verbose, but IMO simpler.
Above is, I think, the behavior I would expect from this proposal. But I'm open to be convinced that it's still somewhat handwavy in parts, or that it does not match my expectations when taken at face value. It feels reasonably simple and straightforward to me, though.
One crucial deficiency of this is that it requires that typeSet(A) is efficiently computable. I think the spec already makes that assumption, somewhat to my chagrin. I also think the assumption is probably correct, with the interfaces we can express today (but it might prevent some interfaces we want to express in the future, like type Stringish interface { fmt.Stringer | ~string }. But until we purge the notion of "type sets" from the spec, I'm not sure this is a problem specific to this proposal.

Haven't had a chance to scribble anything down yet but that looks basically like what I planned to do. Did you mean ⊆instead of ⊂though?
I believe (but have not thought about enough to strongly believe) that it should be possible to check if X⊆Y easily as it naturally breaks down into cases that are easy to check.

@jimmyfrasche

Did you mean ⊆instead of ⊂though?

Sure, why not :) Conventions are not entirely consistent, some mathematicians use ⊂ and ⊆, some use ⊊ and ⊂, some use different symbols entirely. ⊂ is mapped on my keyboard and convenient to type, and I've kind of gotten used to ⊊/⊂ anyways.

I believe (but have not thought about enough to strongly believe) that it should be possible to check if X⊆Y easily as it naturally breaks down into cases that are easy to check.

FWIW, there are potential pitfalls because of implicit negative constraints. For example, having a method M() means you don't have a method M() int, or having a field M means you can't have a method M() and so on. I think we managed to get rid of them with the restrictions we put into place, but it's surprisingly subtle.

@Merovius In the rules you wrote down, is an interface I always a element of typeset(I)?  That's not obvious from your definition.
To put it another way, is this valid?
type I interface { ~int | ~string }
func F1[T I](v T) {}
func F2[T I](v T) { F1(v) }

@ianlancetaylor the call to F1 succeeds by rule vi regardless. I don't think I should be in typeset(I) as it is defined as {T | underlying(T) = int} ⋃ {T | underlying(T) = string}

@ianlancetaylor What @jimmyfrasche said.
I don't tend to think of interfaces with type elements as "types", which is why I didn't think of spelling that out. But yes, "basic interfaces" would always be in their own type set, whereas interfaces with type elements generally would not. I guess we'd have to argue about whether type X interface { ~X } or type X interface { X } or type X interface { X | int } should be allowed, to make it possible for such an interface's typeset to contain itself. Probably not, though.

And FWIW, the fact that basic interfaces are always in their own typeset follows from the same rules that imply today, that an interface type always implement itself. A basic interface is defined by its method set and a basic interface's method set contains all method it requires.

Oh and, as another note: Interfaces with type elements only ever appear in the rules in the form of a typeSet(C)⊂typeSet(I) check, never in the form of a C∈typeSet(I) check. Which sort of reflects my bias of not thinking of them as "types" and implying that it does not matter whether or not they are in their own (or any other) typeset.

Ignoring unions containing interfaces for the moment, comparable and A | ~B make sense as types to me under rules like these.
comparable is any with the restriction that its dynamic type is comparable
A | ~B is an interface whose dynamic type is restricted to A or a type T where T = underlying(B).
If, aside from the restriction on assignable types, they are otherwise ordinary interface values, then it seems like they're covered by rules i and ii.

If comparable ever becomes a full type (i.e. we adopt #51338):
Observe that

any ∈ typeSet(comparable). Interface types are comparable.
typeSet(comparable) ⊂ typeSet(any) (obviously)
typeSet(any) ⊄ typeSet(comparable). e.g. []byte is in typeSet(any), but not typeSet(comparable).
comparable ∈ typeSet(comparable). comparable itself is an interface type, so it's comparable.
And comparable ∈ typeSet(any) (obviously).

The rules would then imply that

comparable is assignable to any (rule ii, observation 2)
any is not assignable to comparable (rule ii, observation 3)
any (as a type argument) can instantiate comparable (rule v, observation 1)
comparable (as a type argument) can instantiate any (rule v, observation 5)
comparable (as a type argument) can instantiate comparable (rule v, observation 4)
A type parameter constrained on comparable can instantiate a generic function constrained on any (rule vi, observation 2)
A type parameter constrained on any can not instantiate a generic function constrained on comparable (rule vi, observation 3)

I think these are exactly the intuitive results we would want in that situation.

@jimmyfrasche

or a type T where T = underlying(B).

Typo, wrong way around, I assume (underlying(T) = B)?

any (as a type argument) can instantiate comparable (rule v, observation 1)
Can you provide a code sample to describe this? I'm not sure I understand it correctly.

@Merovius Right now we say that an operation (say +) on a type parameter is permitted if all types in the type parameter's type set support the operation. But if a type set of a type parameter contains an interface, the type parameter cannot have any operations because ordinary interfaces don't have operations. I assume this is why you say "basic interfaces would always be in their own type set, whereas interfaces with type elements generally would not"?
Do I understand that correctly?

Doesn't that fall out of X not being in typeset(X) given something like type X interface { A | B }?

I am looking for an exact definition of type set; at least I don't see it in https://github.com/golang/go/issues/52509#issuecomment-1118972932.
I'm trying to understand how the proposed rules differ from what we have now and at the moment I see

v. var A I can instantiate F[B C], if I∈typeSet(C)

where today we have "if typeset(I) ⊂ typeSet(C)".
I'm sure I am missing something.

Here's an attempt at a summary, slightly more compact, written down for my own understanding:

Terminology
a) uppercase T, I, P stand for a concrete, interface, or type parameter type respectively
b) lowercase t, i, p stand for variables of type T, I, P respectively

Typesets
a) typeset(T) = {T}
b) typeset(I): defined like in the Go spec but if I is a basic interface (no type elements), then typeset(I) also contains I
c) typeset(P) = typeset(I) with P declared as [P I]
d) typeset(x) = typeset(type(x)) with x one of t, i, p

Assignment
a) t is assignable to i if typeset(t) ⊆ typeset(i)
b) i1 is assignable to i2 if typeset(i1) ⊆ typeset(i2)
c) p is assignable to i if typeset(p) ⊆ typeset(i)

Instantiation
a) T instantiates P if T ∈ typeset(P)
b) I instantiates P if I ∈ typeset(P)
c) P1 instantiates P2 if typeset(P1) ⊆ typeset(P2)

The differences between this and what we have now are:

the typeset of basic interfaces also contain themselves
instantiation with a non-type parameter uses type inclusion, not typeset inclusion

Do I have this correctly?

@jimmyfrasche

Doesn't that fall out of X not being in typeset(X) given something like type X interface { A | B }?

I suppose so, but I didn't see this written down. Is it written down somewhere?

@griesemer

Here's an attempt at a summary, slightly more compact, written down for my own understanding: […] Do I have this correctly?

Yes, I think so.

I suppose so, but I didn't see this written down. Is it written down somewhere (besides in the summary I just wrote)?

As part of the discussion, e.g. this comment. I wasn't explicit about it, but it's a consequence of the typeSet definition, which would AFAICT be the same we already use (with the exception of the "non-interface" parts).

@griesemer

b) typeset(I): defined like in the Go spec but if I is a basic interface (no type elements), then typeset(I) also contains I

I think typeset(I) needs to include all of the interface types that implement I, not just I itself.
(That is: if a type parameter P is bounded by error, then it should be possible to instantiate P with the interface type net.Error, and thus net.Error should be in the typeset of error.)
Otherwise the instantiation rule doesn't work out.

Good point. This is BTW an issue with the spec right now:

The type set of a method specification is the set of types whose method sets include that method.

This would include interfaces in type sets, which we tried to leave out by construction. So, currently there should be a "non-interface" added here. i.e. making that work seems to be a pretty natural consequence of defining type sets based on their elements - it has to be actively excluded, not to be the case.

This was fixed several weeks ago. You're not looking at the spec at tip:

The type set of a method specification is the set of all non-interface types whose method sets include that method.

@griesemer
I've been thinking about the rules in https://github.com/golang/go/issues/52509#issuecomment-1119263078 through the lens of #52624.
If we treat comparable as a run-time interface type, then we also need to define its semantics for type-assertions.
For this proposal, I believe the rule is (roughly):

Assertability
a) x asserts to i if type(x) ⊆ typeset(i)

I think the rule is "x.(I) succeeds if T∈typeSet(I), where T is the dynamic type of x". Maybe you meant type(x) to be the dynamic type of x and meant typeSet(type(x)) ⊆ typeSet(x) in which case that means the same. But just to be explicit.

@DmitriyMV

any (as a type argument) can instantiate comparable (rule v, observation 1)

Can you provide a code sample to describe this? I'm not sure I understand it correctly.

It means this compiles and works (which is good, as that's the reason for this proposal):
type Set[K comparable] map[K]struct{}

func main() {
    s := make(Set[any]) // instantiate `Set` using `any`. any ∈ typeSet(comparable), so this is allowed by rule v.
}

The 2 CLs above essentially get us back to before  #50646 was addressed (by strictly implementing the typeset rules), and re-introduce the "inconsistency" that existed at that time. Specifically, an ordinary interface satisfies the comparable constraint.

I just posted #56548 which in essence is this proposal, but also includes the precise spec change and a discussion. @zephyrtronium, please comment as you see fit (and/or perhaps close this proposal, if you're so inclined). Thanks.

I'll close this in favor of #56548. If that proposal doesn't work out, this one can be reopened.

@zephyrtronium I disagree with that logic. If a type can not exist because it has contradicting methods, it's not in the type set of any interface. In other words, all type sets must be subsets of the universe of valid Go types.

the rule for assignability of values x of concrete type T to variables of parameter type P

I don't think I wrote down a rule for that. It also seems a rule of dubious utility. I think that's what you essentially showed. We might be able to write a rule allowing this, but it would require P to mention a list of concrete types, which makes the rest of your argument collapse.
There is a rule for a concrete type instantiating a type parameter, but that rule uses ∈ and again doesn't seem to fit your argument.
What am I missing? What specific rule are you referring to (they are numbered)?

That's true. I was so focused on resolving the contradiction that I didn't think about whether it's correct to do so, and indeed, we would be able to write func Foo[P any]() { _ P = struct{}{} } if so. Funny that I noticed that for interface assignments, but not for concrete types. 🙂


Improve formatting of doc links on panels

Feature Request
While creating a z/OS endpoint, I notice that the doc links to the right of the panel are not well aligned. This makes the panel look very messy. Also, the links are not actual links. And finally, the links point to generic doc sections rather than sections specific to the current panel.
For example, we have:
ZosEndpoint is the Schema for the zosendpoints API. View documentation: ibm.biz/ibm-zoscb-doc. License ibm.biz/ibm-zoscb-license.
Describe the solution you'd like.
It would be better to align this text with the words:
z/OS Endpoint
provided by IBM
(Though should the p be a capital P or should it read 'z/OS Endpoint provided by IBM'.)
on the same panel.
The text would look better if formatted as follows:
ZosEndpoint is the Schema for the zosendpoints API.
View documentation: ibm.biz/ibm-zoscb-doc.
License ibm.biz/ibm-zoscb-license.
Ideally, all links should be proper links to documents that users can just click on. I had to cut and paste the provided link into a browser.
Also, it would be better to direct users to https://www.ibm.com/docs/en/cloud-paks/z-modernization-stack/2023.1?topic=interface-importing-operator-collection , as this documentation specifically discusses defining z/OS Endpoints.
Btw, the same issue occurs on other panels too (e.g. Create Operator Collection) so it would be good to fix this on all new panels added for z/OS Cloud Broker.

Closing this here as I had raised it against the wrong category. Now raised as https://github.ibm.com/IBM-Z-and-Cloud-Modernization-Stack/zoscb/issues/2289 .


Re-open #6: Docking to the right (option)

It'd be really great to for wide-screen users.
Example: this atom-runner docks to the right.

Thanks for the feedback. I'm re-opening #6 so we can track the conversation.


Unable to reproduce results

@auspicious3000 We tried reproducing results using your codebase and the dataset found here https://datashare.ed.ac.uk/handle/10283/3443 (that you use) but unfortunately, we were unable to. The outputs that we have so far are extremely noisy (even if source and target speakers are the same). Could you please share a working code with us that might help us reproduce the results? I would greatly appreciate your inputs!

We got many feedbacks from users that they are able to reproduce the results using this code. It might be possible there are inconsistencies when using the code. It might be helpful to read the code and paper in greater detail.


Gradient Implementation

Great Work! Just some questions. For the gradient part, I did not see the actual implementation for gradient operation, but only register using official implementation. If I missed it, please correct me. In this case, are you using approximation only in forwarding stage? Thanks.

Related to the topic: Can you train the models with approximate layers (FakeApproxConv2D)?

Only support inference


Low diff shares  bug has been not fixed for Stratum version 2.

https://github.com/oliverw/miningcore/issues/1062
This bug has been fixed for Stratum version 1.
However, for stratum version 2, the error persists.
It does not occur immediately.
Here is a screenshot after 79 shares with t-rex 0.24.8
Stratum V2

Stratum V1

Originally posted by @kr1z1s in https://github.com/oliverw/miningcore/issues/1062#issuecomment-1025414726

Status?

I'll check it out

t-rex miner whith 79 shares

stratun v2

It's stratum v1 t-rex miner 79 shares

Looks good to me?

I think the same

Is that with the updated t-rex?

Yes, it a 0.26.4 version

Ok, closing this for now then. Thanks for the update. 👍

Ok


Docs: Broken link

This will fix one broken link and remove another link that doesn't exist anymore in README.md.

Thanks for the pull request, @CodeWithEmad! Please note that it may take us up to several weeks or months to complete a review and merge your PR.
Feel free to add as much of the following information to the ticket as you can:

supporting documentation
Open edX discussion forum threads
timeline information ("this must be merged by XX date", and why that is)
partner information ("this is a course on edx.org")
any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.
Please let us know once your PR is ready for our review and all tests are green.

I've run the tests and added @CodeWithEmad  to the triage team so tests will run automatically in the future.

@CodeWithEmad looks like there are some test failures, can you have a look?

Updating the README broke the tests due to snapshot issues. Not my strong suit (and probably needs macOS) but wanted to help. Can close if no one has time to fix.

Hi @CodeWithEmad! Just checking in to see if you plan to pursue this pull request?

Can't take it any further than this. I'll close it.
@mphilbrick211

Can't take it any further than this. I'll close it.
@mphilbrick211

@CodeWithEmad Even though your pull request wasn’t merged, please take a moment  to answer a two question survey so we can improve your experience in the future.


Here's one asset for a search bar along with a mockup.

Mockup:

The color for the search bar outline/text (and the provided svg) is #E29886

This is a mockup of the search bar in mobile

I actually dig this idea; might be cool when I get around to adding more data to buildings and whatnot - will see about implementing something like this

The first thing we'll search with can be a set of coordinates

No search bar and no "Find a place" and can't search in GTA 6 maps.
Screen recording 2023-12-26 8.21.08 PM.webm


Build : display/set the HLS release used

When doing a build (simulation or image), the compilation of the HLS can use a different release level than the Vivado release used for chip. The Vivado HLS release will grow much more quicker than the Vivado tool to take advantage of the bug corrections, and has no incidence on the build of the chip.
As this time the only way to do it is to pre-compile separately the HLS files before the build with the appropriate release, or by default they will take the Vivado release

Can we use a different variable to separate these ? (actually in ibm_settings_for_snap file)
Can we display the HLS release used during the build ?
Thx

@bmesnet
The current flow prints out the following message during the SNAP configuration phase:
[CREATE_ENVIRONMENT..] start Thu Sep  7 10:53:29 CEST 2017
using Vivado v2016.4 (64-bit)
Is this sufficient?

@ThomasFuchs
No the Vivado release level needs to be independent from the Vivado HLS release level since HLS release needs to be at the latest to get all bugs solved. Changing HLS release is immediate while changing Vivado release has a lot of dependencies and must be tested deeply

By default the latest Vivado should be ok for HLS as well. For the short times when a newer HLS is required, there is a workaround to compile the HLS files manually before starting the snap framework build process.
=> rejecting this change request


Error dsiplay while connecting from client to server in zimbra api

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ServerException' with message 'Server error response [url] https://<IP_ADDRESS>:7071/service/admin/soap [status code] 500 [reason phrase] Server Error' in /home/vikatan/www/intrasite/intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:89 Stack trace: #0 /home/vikatan/www/intrasite/intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Subscriber/HttpError.php(33): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Message\Response)) #1 /home/vikatan/www/intrasite/intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Event/Emitter.php(108): GuzzleHttp\Subscriber\HttpError->onComplete(Object(GuzzleHttp\Event\CompleteEvent), 'complete') #2 /home/vikatan/www/intrasite/intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/RequestFsm.php(91): GuzzleHttp\Event\Emitter->emit('complete', Object(GuzzleHttp\Event\CompleteEvent)) #3 /home/vikatan/www/intrasite/intra.vikatan.com/zimbra/vendor/guzzlehttp/ in /home/vikatan/www/intrasite/intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 89
Please help me all.

can you add more information about this? can you add a full stack trace and
some more detail about the problem?
On Tue, Jun 21, 2016 at 10:02 AM, aiyappann<EMAIL_ADDRESS>wrote:

Fatal error: Uncaught exception 'GuzzleHttp\Exception\ServerException'
with message 'Server error response [url]
https://<IP_ADDRESS>:7071/service/admin/soap [status code] 500 [reason
phrase] Server Error' in /home/vikatan/www/intrasite/
intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:89
Stack trace: #0 /home/vikatan/www/intrasite/
intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Subscriber/HttpError.php(33):
GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Message\Request),
Object(GuzzleHttp\Message\Response)) #1
https://github.com/GetStream/stream-php/issues/1
/home/vikatan/www/intrasite/
intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Event/Emitter.php(108):
GuzzleHttp\Subscriber\HttpError->onComplete(Object(GuzzleHttp\Event\CompleteEvent),
'complete') #2 https://github.com/GetStream/stream-php/issues/2
/home/vikatan/www/intrasite/
intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/RequestFsm.php(91):
GuzzleHttp\Event\Emitter->emit('complete',
Object(GuzzleHttp\Event\CompleteEvent)) #3
https://github.com/GetStream/stream-php/issues/3
/home/vikatan/www/intrasite/intra.vikatan.com/zimbra/vendor/guzzlehttp/
in /home/vikatan/www/intrasite/
intra.vikatan.com/zimbra/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php
on line 89
Please help me all.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GetStream/stream-php/issues/32, or mute the thread
https://github.com/notifications/unsubscribe/AAFan0tqJ7XsGFRHpFzAi_UYQiSmHc5uks5qN5qFgaJpZM4I6dR_
.

@aiyappann can you contact us at<EMAIL_ADDRESS>for assistance with this, or let us know that you've resolved this?

@hannesvdvreken suggest a quick check but looks like this can be closed.

Looks like a server-side problem with a service not related to this SDK.


select2-focus event doesn't behave as expected

Here's a simple JSFiddle to log select2-focus events to the console:
http://jsfiddle.net/timbonicus/L82GW/1/

Click the Select2; select2-focus is fired as expected
Click the input field to focus; select2-focus is fired on blur!
Click the Select2 again; no select2-focus event is fired

Closing this off due to a lack of activity.
If this is still an issue in the upcoming 4.0 release, feel free to reply back and we can determine if this needs to be reopened.


feat: add new assistant_thread_started support

Slack just released new AI agent view and it comes with a set of new requirements outlined here
Requirements

https://api.slack.com/docs/apps/ai

Hi @b0xtch! We'll be introducing support for these endpoints in our lower-level SDKs today (for BoltJS specifically, that'd be the Node SDK), followed by an instance-based implementation once we determine exactly what that experience should be.
Thrilled to see your eagerness for support! Keep an eye out for the releases that contain these updates. 🙂

Here's a link to the release notes for reference! https://github.com/slackapi/node-slack-sdk/releases/tag/%40slack%2Fweb-api%407.5.0

Hi @b0xtch 👋🏼  Just wanted to circle back to let you know that we've introduced support for the assistant.* APIs with the latest release of Bolt (v3.22.0). Sorry for the delay! Since the most recent version of @slack/web-api (7.x) isn't yet referenced in the current Bolt dependencies, we've decided to backport this feature to 6.x, as well.


Stuck on Error: Gone

I'm deploying an Ember application to a GCS using the ember-cli-deploy-gcloud-storage and ember-cli-deploy-gcs-index addons.
Everything was working correctly when I used a GC service account with Project Owner permissions, but this seemed like overkill so I was experimenting trying different service accounts with lesser permissions. Somewhere along the line, deploying the ember app went from returning Error: Unauthorized to Error: Gone. Now no matter what I try, the bucket seems to be stuck in the state of trying to resume a failed upload. Below is the console output from running ember deploy.
I've tried:

Uploading directly through the GC Storage UI the files I thought were missing. The goal being to trick the bucket into thinking everything was uploaded.
Deleting everything from the bucket.

Neither of these worked, so I've resorted to destroying the bucket completely and starting fresh.
My question: Is there a way to clear the partially uploaded file cache on a bucket (or clear wherever it keeps track of uploads) without destroying the entire bucket?
- Error: Gone
- Error: Gone
    at Request._callback (/Users/uname/Code/union/portal/node_modules/ember-cli-deploy-gcloud-storage/node_modules/google-cloud/node_modules/@google-cloud/storage/node_modules/gcs-resumable-upload/index.js:274:25)
    at Request.self.callback (/Users/uname/Code/union/portal/node_modules/request/request.js:187:22)
    at emitTwo (events.js:100:13)
    at Request.emit (events.js:185:7)
    at Request.<anonymous> (/Users/uname/Code/union/portal/node_modules/request/request.js:1044:10)
    at emitOne (events.js:90:13)
    at Request.emit (events.js:182:7)
    at IncomingMessage.<anonymous> (/Users/uname/Code/union/portal/node_modules/request/request.js:965:12)
    at emitNone (events.js:85:20)
    at IncomingMessage.emit (events.js:179:7)

@capstan does this sound like the issue brought up recently about explicitly canceling/deleting a resumable upload, or is this something else?

410 Gone is related to poisoned or expired upload sessions. Upload sessions expire 7 days after creation, but may linger for a bit before being garbage collected. Session poisoning happens if we get corrupt data (i.e., your provided hash doesn't match the data you sent) or the service experienced a small class of unrecoverable errors and likely tried to return a 503. Unfortunately, if a session is Gone, it's gone and a new upload session must be erected.

Thanks for the info! I've put a PR together at #16. @patrickberkeley would you mind giving it a shot?

I erred in my comment; it does not include expired sessions, which will return 404 Not Found. This is purely for cases of bad data transmission or service-side error rendering the session unrecoverable. We call them "terminated" sessions.

@stephenplusplus thanks for following up on this and for the fix. Unfortunately I don't have a solid way to reproduce the error. The bucket initial got into the error'ed state when I was changing permissions, but the only thing I was doing from the command line was deploying. I think the Gone state was just a fluke.
Let me know there are steps I can take to reproduce and I'd be happy to give them a shot.

No problem, I'm not sure how to reproduce either. I think I'll just make a new release which should help if someone else winds up in situation you were in. If it doesn't, we'll just keep working through it :)

Published under 0.7.4. Thanks for reporting @patrickberkeley!


Error when scheduling a delayed job with a difference of less than 1 second

The issue is a part of #284 which appears when we try to enqueue jobs with a difference of less than 1 second at a very high-rate. The exact issue happens since the enqueue methods convert the millisecond timestamp into seconds, thereby rounding off a large portion of the timestamp, which then means that conflicts appear if a similar job is scheduled before the first one is picked up by a worker.

https://github.com/taskrabbit/node-resque/issues/284 is marked as will not fix
I thought we could use this issue to suggest alternative resque patterns.
Perhaps a single job at each per-second timestamp could be enqueued to then process a bach of jobs it enqueues at that moment?


Recording crash with TightVNC server on Windows 10: unknown message-type: 6

I'm using https://github.com/saily/vnc-recorder, but randomly I've got :
INFO[0411] ========got server message, msgType=6
panic: unknown message-type: 6
In your code I can see :
// Server-to-Client message types
const (
FramebufferUpdateMsgType ServerMessageType = iota
SetColorMapEntriesMsgType
BellMsgType
ServerCutTextMsgType
)
So there's no type 6 and I don't know what is a type 6 message, RFB protocol tells "Possibly used by UltraVNC".
Have you any idea how to fix this ?
Thanks

First tell me, which server are you using? is it UltraVNC?
In any case, since RFB is a binary protocol which has no message size, untreated messages can break the system: reading the wrong size (or not reading something), means that you are now off by some bits, so you don't know where the next message begins.
to fix this you should first see that you are really getting this message type and not just failing on a previous message and wrongly reading the next message and it's type. (check for any previous silent failures by opening up debug level / adding some logs)
if it is a correct message type, then you should implement this message type (just by reading & skipping it):

try just ignoring the message after reading the type
try reading several bytes (most simple messages are less than 8 bytes)

You should also try to understand when the server is sending the problematic message, it can furtehr your understanding about what the problem really is (it might be when you are in fullscreen, or when you open some spacial image remotely, when pressing ctrl+c / ctrl+v, or maybe when the mouse hover over something and changes the cursor, etc.)
Ultra vnc source is available for download here: (it's actually GPL opensource)
https://www.uvnc.com/downloads/ultravnc/100-download-ultravnc-10962.html
look at rfb/rfbproto.h and other files in that area.
Their code doesn't indicate using server message type = 6 as far as I can see.

@amitbet I use TightVNC for Windows (Version 2.8.27) on Windows 10 64 bits.
I will try to investigate on server side, thanks for your help.


Beautify and enhance README

Make the README.md (very) pretty.

Add a nice HackerRank logo at the top.
Add cool badges.
Add a Table of contents section similar to the screenshot (with pointers to contents in this README)

Add an Open-Source Events section at the bottom, with KWOC logo.

Hey, I wish to take this up.

Hey please check this Link and let me know the changes if any

@Aarushi11H Great work on the issue! Just a few caveats:

The commit activity badge shows invalid
Add a Contributions Welcome  badge and three language badges.

You can absolutely make a PR after that.


AWS_DEFAULT_REGION environment variable not being read.

Describe the bug
When calling the EnvironmentVariableAWSRegion, the code is only looking at AWS_REGION it should also look at AWS_DEFAULT_REGION as well.
Expected Behavior
The code should look at both environment variables AWS_DEFAULT_REGION and AWS_REGION
Current Behavior
The code only looks at AWS_REGION environment variable
Reproduction Steps
Remove AWS_REGION environment variable and add AWS_DEFAULT_REGION environment variable.  Then try to instantiate an AmazonServiceClient.
Possible Solution
If the AWS_REGION environment variable is not set check the AWS_DEFAULT_REGION environment variable before throwing exception.
Additional Information/Context
No response
AWS .NET SDK and/or Package version used
AWSSDK.Core -Version <IP_ADDRESS>
Targeted .NET Platform
.NET 6, .NET 7
Operating System and version
ALL

Per Environment variables to configure the AWS CLI, AWS_DEFAULT_REGION identifies the AWS Region whose servers you want to send your requests to by default.
The constant ENVIRONMENT_VARIABLE_DEFAULT_REGION was added in commit https://github.com/aws/aws-sdk-net/commit/3d41f4bdec4d3fab0b2ad804fedb945b5e051364 as part of adding support for Default Configuration Modes. This needs review with the team since the utility class EnvironmentVariableAWSRegion hasn't changed in years and the new constant was introduced when adding support for default configuration mode. Needs review with the team.

Hi @aaronolds, I'm going to resolve this as not planned.
AWS_DEFAULT_REGION is a variable the previous version of the CLI (V1) used, but all other SDKs have standardized on using AWS_REGION instead: https://docs.aws.amazon.com/sdkref/latest/guide/feature-region.html (including the CLI V2: AWS CLI v2 uses any value in AWS_REGION before any value in AWS_DEFAULT_REGION).


fix attention.forward

Hi @AryaNguyen,
By default, the forward() method is always called. So, I don't see a need for explicitly adding it.


chore: error logging and response to arweave endpoint

Description

error logging and response to arweave endpoint

Review Error for lauchness @ 2023-08-15 00:50:45 UTC
User failed mfa authentication, public email is not set on your github profile. see go/mfa-help

Review Error for wilsoncusack @ 2023-08-15 01:44:08 UTC
User failed mfa authentication, see go/mfa-help

@wilsoncusack please let me when it is deployed, so I can run tests on my end to further troubleshoot the issue with this endpoint 🙏


Remove allure-junit5 dependency and bump gradle to 8.1.1

Testing of the snapshot version showed that the allure-junit5 dependency is redundant. I have also bumped the gradle version

@Kantis hi. Could you check it please?

@Kantis @sksamuel ping guys. We are really need this fix to finish our integration with allure

@Kantis @sksamuel Hi! When will this changes be released?

@Kantis @sksamuel Hi! When will this changes be released?

+1

@Kantis @sksamuel Hello! I appreciate the efforts you put into this project. Do you think there are prospects for implementing these changes? Thank you

Sorry for the delay. Has anyone tried out the snapshot? I can publish a new version tonight


RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation: [torch.FloatTensor [128, 3, 4, 4]] is at version 2; expected vers

In skipgnomaly, there is a  self.err_d_lat in backward_d, if I delete self.err_g_lat, the programmer can run normaly;there is a issue in programmer if I don't change it.Please hele me!

I think that self.err_g_lat is appear only in generator，pls help me to correct my idea
def backward_g(self):
""" Backpropagate netg
"""
self.err_g_adv = self.opt.w_adv * self.l_adv(self.pred_fake, self.real_label)
self.err_g_con = self.opt.w_con * self.l_con(self.fake, self.input)
#self.err_g_lat = self.opt.w_lat * self.l_lat(self.feat_fake, self.feat_real)
    self.err_g = self.err_g_adv + self.err_g_con #+ self.err_g_lat
    self.err_g.backward(retain_graph=True)

def backward_d(self):
    # Fake
    pred_fake, _ = self.netd(self.fake.detach())
    self.err_d_fake = self.l_adv(pred_fake, self.fake_label)

    # Real
    # pred_real, feat_real = self.netd(self.input)
    self.err_d_real = self.l_adv(self.pred_real, self.real_label)

    # Combine losses.
    self.err_g_lat = self.opt.w_lat * self.l_lat(self.feat_fake, self.feat_real)
    self.err_d = self.err_d_real + self.err_d_fake + self.err_g_lat
    self.err_d.backward(retain_graph=True)

In skipgnomaly, there is a self.err_d_lat in backward_d, if I delete self.err_g_lat, the programmer can run normaly;there is a issue in programmer if I don't change it.Please hele me!

It seems that the version of torch or torchvision is wrong.

In skipgnomaly, there is a self.err_d_lat in backward_d, if I delete self.err_g_lat, the programmer can run normaly;there is a issue in programmer if I don't change it.Please hele me!

It seems that the version of torch or torchvision is wrong.

In skipgnomaly, there is a self.err_d_lat in backward_d, if I delete self.err_g_lat, the programmer can run normaly;there is a issue in programmer if I don't change it.Please hele me!

It seems that the version of torch or torchvision is wrong.
I add "detach()" to "self.err_g_lat", and it run normaly.

In skipgnomaly, there is a self.err_d_lat in backward_d, if I delete self.err_g_lat, the programmer can run normaly;there is a issue in programmer if I don't change it.Please hele me!

It seems that the version of torch or torchvision is wrong.

I add "detach()" to "self.err_g_lat", and it run normaly.

it works：
with torch.no_grad():
            self.pred_fake, self.feat_fake = self.netd(self.fake)


Suggested changes for pull #47

It removes the duplicated code in onSessionError and makes necessary changes to pass the test.

LGTM!