proposal: spec: permit values to have type "comparable"

As part of adding generics, Go 1.18 introduces a new predeclared interface type comparable.  That interface type is implemented by any non-interface type that is comparable, and by any interface type that is or embeds comparable.  Comparable non-interface types are numeric, string, boolean, pointer, and channel types, structs all of whose field types are comparable, and arrays whose element types are comparable.  Slice, map, and function types are not comparable.
In Go, interface types are comparable in the sense that they can be compared with the == and != operators.  However, interface types do not in general implement the predeclared interface type comparable.  An interface type only implements comparable if it is or embeds comparable.
Developing this distinction between the predeclared type comparable and the general language notion of comparable has been confusing; see #50646.  The distinction makes it hard to write certain kinds of generic code; see #51257.
For a specific example, you can today write a generic Set type of some specific (comparable) element type and write functions that work on sets of any element type:
type Set[E comparable] map[E]bool
func Union[E comparable](s1, s2 Set[E]) Set[E] { ... }

But there is no way today to instantiate this Set type to create a general set that works for any (comparable) value.  That is, you can't write Set[any], because any does not satisfy the constraint comparable.  You can get a very similar effect by writing map[any]bool, but then all the functions like Union have to be written anew for this new version.
We can reduce this kind of problem by permitting comparable to be an ordinary type.  It then becomes possible to write Set[comparable].
As an ordinary type, comparable would be an interface type that is implemented by any comparable type.

Any comparable non-interface type could be assigned to a variable of type comparable.
A value of an interface type that is or embeds comparable could be assigned to a variable of type comparable.
A type assertion to comparable, as in x.(comparable), would succeed if the dynamic type of x is a comparable type.
Similarly for a type switch case comparable.

To be clear, this proposal is for Go 1.19 or later.
CC @griesemer

Amusingly, I wrote my first real generic code today and then immediately ran into this situation, in almost exactly the way described in the writeup.
My generic set type:
type Set[T comparable] map[T]T

I initially tested it with some simple cases involving T being a struct type containing only comparable fields, and I was just getting ready to call it done when I decided to write the following declarations as static assertions to verify it could support all of the types I wanted:
var _ Set[exampleInterface]
var _ Set[exampleComparableStruct]
var _ Set[*exampleUncomparableStruct] // pointers are comparable regardless of target type

type exampleInterface interface {
	comparable
	Boop()
}

type exampleComparableStruct struct {
	v [2]int
}

type exampleUncomparableStruct struct {
	f func(int)
}

This fails at compile time with the following error:
set_test.go:3:11: interface is (or embeds) comparable

I understand that this is one of the cases you already listed as what this proposal would allow:

A value of an interface type that is or embeds comparable could be assigned to a variable of type comparable.

However, I ended up here mostly by luck, because this error message happened to exactly match the text you used to describe the situation that would become valid. This error message was confusing to me because it just states something I know to be true: I intentionally embedded comparable in that interface type to try to make it possible to declare a set of that interface type. It doesn't say anything about why that statement is relevant, since it does seem to be valid to declare an interface which embeds comparable, just that it's not valid to then declare a value of that type.
I totally understand that making this work is not on the table until Go 1.19 at the earliest, but I wonder if it would be possible in the meantime to improve this error message to at least make a more direct statement about what I did wrong here:
set_test.go:3:11: cannot declare variable of interface type that is (or embeds) comparable

Perhaps I'm misunderstanding, but I believe from this writeup (and from my own further experimentation) that it's the declaration of the variable that is invalid, not the interface declaration itself.

In case it's helpful in evaluating the proposal, my underlying goal here is to make a set of values that are all comparable and all implement a specific interface, but that have different dynamic types.
This is actually part of an implementation of a directed acyclic graph where the nodes represent different actions, so in real usage there would be a type Action interface representing the idea of an action, and concrete implementations of that interface representing specific action types. The program will then walk the graph in a topological sort order and call a method of Action on each node, which is of course then a virtual call to perform the specific action represented by that value.
Action will actually be implemented only by pointers to the action types in practice, which will therefore all be comparable by pointer identity.
I'm not planning to pursue this any further for the moment, since it seems unlikely I will be able to achieve this goal with Go 1.18. I hope these details are helpful in evaluating the proposal.

Is it possible to disallow comparisons with incomparable interfaces, to avoid runtime panics during comparisons? (looks hard).

I would think that disallowing comparisons with interfaces that aren't statically incomparable would be a breaking change at this point, since it's always been possible so far to carefully compare interface values and just make sure that you don't write any implementations that aren't themselves comparable. :thinking: I have several examples in the codebases I maintain in my dayjob which would immediately fail compile even though in practice they never panic at runtime.
It does seem like a shame, since this seems like a clear win if this were a green field problem, but I think I'd rather have the ability to declare that all values of a particular interface are guaranteed never to panic on comparison, even if it remains possible to accept the risk and try comparing interface values of a non-statically-guaranteed-comparable interface type.

@go101 We can't change the existing language, so it will continue to be possible to compare values of interface type which can possibly panic.  That said, if we adopt this proposal, then programs that care can convert their interface types to be comparable, or embed comparable, and thus ensure that their interface comparisons can't panic.  It would also, after a while, be possible to have vet or some other analyzer warn about comparisons of interface types that are not comparable.

I think this is a good change, but mostly because I see it as a step on the path to making any constraint useable as a normal interface value, which in turn opens the door to tagged union types. I know that using constraints as interface values has some wrinkles to work out (given type number interface{ int | uint }, var n number would be initially nil, rather than 0 [but what else could it be, since it's not specified as an int nor a uint yet?]), but it seems like the logical implication of the systems introduced in Go 1.18, so I'm not sure how long it can be excluded.

I fell at (nearly) the first hurdle at trying to make a generic sync.Map (details in #51384 ). More precisely my GenericMap[K,V] works fine except for things like GenericMap[interface{},bool] because interface{}/any do not implement comparable. So I support this proposal.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

However, interface types do not in general implement the predeclared interface type comparable. An interface type only implements comparable if it is or embeds comparable.
[…]
But there is no way today to instantiate this Set type to create a general set that works for any (comparable) value. That is, you can't write Set[any], because any does not satisfy the constraint comparable.

TIL. This surprised me, I missed that discussion.
IMO that was a mistake and the answer to this problem is "interface types are comparable, so they should satisfy comparable".
Personally, I'm against this proposal for the reasons I mentioned when I last saw this idea being floated. Namely that embedding comparable becomes viral. For any interface-type:

Embedding comparable is bad. It disallows implementations with non-comparable values (e.g. http.HandlerFunc). In general, the author of an interface-types should have no opinion over what underlying type is used to implement it.
Not embedding comparable is bad. It disallows instantiating Set with it, even if the user of the interface knows all their actual values are comparable.

So you'll need both versions, in practice, for every interface. That's a color.
Moreover, the rules as stated don't actually seem to give meaningful additional guarantees about safety. For example, struct{ F any } would still implement comparable, AIUI. But its comparison is obviously not, in any way, safer than comparison of any. So, the claim that

That said, if we adopt this proposal, then programs that care can convert their interface types to be comparable, or embed comparable, and thus ensure that their interface comparisons can't panic.

doesn't seem to be actually true. Of course, we could extend the virality of comparable to struct-fields and array-elements. But that would also make the virality-problem above much worse. While it's not that unreasonable, to have to declare type ComparableType interface { reflect.Type; comparable } to instantiate Set[Type], if I want to use a struct with a reflect.Type field, I'd have to

Declare my own version of that struct, with the same fields, except all interfaces replaced with their comparable colors, potentially recursively.
Hope that definition stays in sync.
Presumably, manually write conversions between my comparable struct-flavor and the one I actually want (unless we do something like we did for struct-tags and allow conversions to ignore comparable coloring).
Convert back and forth, every time I want to put the struct I'm interested in into a Set or take it out from it.

That seems an unreasonable amount of effort, to me.

I understand why the decision was made, to have interface-types not satisfy comparable. It is confusing to be able to instantiate Set[any], even if the constraint is comparable. But confusion can be solved by education. We are living with the nil-pointers-in-interfaces-are-not-nil confusion, because it might be confusing, but the language is better for the semantics of it. The mess we are getting ourselves into with distinguishing comparable interface types from non-comparable ones, however, can't be solved by education. We are making it more cumbersome to use the language, to avoid having to explain to people that interface-types are in fact comparable. That seems a bad tradeoff.
Deciding that interface-types don't satisfy comparable was the conservative decision. We can't become more restrictive, but we can always become less restrictive. So starting out more restrictive until we learn made sense. IMO, the arguments in favor of this issue really are arguments that we should exercise the option to become less restrictive and have interface-types satisfy comparable.

Is this proposal significantly different from the idea I floated here? https://github.com/golang/go/issues/49587#issuecomment-984461847
In that comment, I was under the impression that interface types would satisfy the comparable constraint. I guess I never actually tried it out!
Although I have a soft spot for this idea, I don't think it fits well with the language as is. reflect.Type is a good example - it's commonly used as a comparable value, but we can't currently use it as a comparable type parameter, which seems wrong. If this had all been done at the start, we'd probably have added comparable to the reflect.Type interface definition, but I don't believe that can be done now without breaking backward compatibility.
As a general rule, I think that if one is allowed to use == on a type outside generic code, one should be allowed to use it inside generic code.
That said, I would support a change to the language that's compatible with the goal expressed in the subject of this proposal: I think that values should be permitted to have type "comparable". I propose a much simpler rule: when used in a non-constraint context, comparable is a synonym for any.
Given:
type Set[E comparable] map[E]bool

it would be possible to write Set[comparable] but that would be exactly the same as Set[any].
The main benefit of doing this is that it would be possible to use a comparable constraint interface
as the parameter type too. For example given these definitions:
type MC interface {
    comparable
    M()
}

type MSet[T MC] map[T] bool

MSet[MC] would be a valid instantiation of MSet, but MSet[struct{_ [0]func(); MC] would not.
@Merovius

Embedding comparable is bad. It disallows implementations with non-comparable values (e.g. http.HandlerFunc). In general, the author of an interface-types should have no opinion over what underlying type is used to implement it.

For the record, I disagree with this. It's an important part of some interfaces that their implementations are comparable - that's part of the contract. reflect.Type is one example. Another is context.WithValue: if comparable as proposed here had been available at the time, we'd almost certainly have used it for that first argument.

Is this proposal significantly different from the idea I floated here? https://github.com/golang/go/issues/49587#issuecomment-984461847
In that comment, I was under the impression that interface types would satisfy the comparable constraint. I guess I never actually tried it out!
Although I have a soft spot for this idea, I don't think it fits well with the language as is. reflect.Type is a good example - it's commonly used as a comparable value, but we can't currently use it as a comparable type parameter, which seems wrong. If this had all been done at the start, we'd probably have added comparable to the reflect.Type interface definition, but I don't believe that can be done now without breaking backward compatibility.
As a general rule, I think that if one is allowed to use == on a type outside generic code, one should be allowed to use it inside generic code.
That said, I would support a change to the language that's compatible with the goal expressed in the subject of this proposal: I think that values should be permitted to have type "comparable". I propose a much simpler rule: when used in a non-constraint context, comparable is a synonym for any.
Given:
type Set[E comparable] map[E]bool

it would be possible to write Set[comparable] but that would be exactly the same as Set[any].
The main benefit of doing this is that it would be possible to use a comparable constraint interface
as the parameter type too. For example given these definitions:
type MC interface {
    comparable
    M()
}

type MSet[T MC] map[T] bool

MSet[MC] would be a valid instantiation of MSet, but MSet[struct{_ [0]func(); MC] would not.
@Merovius

Embedding comparable is bad. It disallows implementations with non-comparable values (e.g. http.HandlerFunc). In general, the author of an interface-types should have no opinion over what underlying type is used to implement it.

For the record, I disagree with this. It's an important part of some interfaces that their implementations are comparable - that's part of the contract. reflect.Type is one example. Another is context.WithValue: if comparable as proposed here had been available at the time, we'd almost certainly have used it for that first argument.

@rogpeppe I agree that for some interfaces it's important. But for most it's counterproductive. By making interface types not satisfy comparable, unless they embed it, we make most interface types impossible to use with generic types like Set, even if that usage would be totally safe. And just because the author didn't want to require comparable, doesn't mean the user of an interface doesn't know all their values are.
That's kind of my point. comparable bisects the set of interface types into two universes, one with "types where it is considered essential that the interface is comparable" and one with "types where the author just wants to do some operations and doesn't care about the concrete type" - and a gray area in-between. In usage, they become incompatible. But there is overlap between them, which means duplication. The proposal text makes the argument:

But there is no way today to instantiate this Set type to create a general set that works for any (comparable) value. That is, you can't write Set[any], because any does not satisfy the constraint comparable. You can get a very similar effect by writing map[any]bool, but then all the functions like Union have to be written anew for this new version.

But I'd argue, we still need this duplication under the proposal, if we want to be able to use e.g. reflect.Type (or any other gray-area usage of an interface) in a Set. With the second being
// SetAny is a Set[T], which doesn't statically guarantee its values are comparable, for cases where
// you want to use an interface type which doesn't categorically require comparable, but where you know
// the values revelant for your case are. It panics at runtime, if you try adding non-comparable values to it.
type SetAny[T any] map[comparable]bool
func (s SetAny[T]) Contains(v T) bool { return s[v.(comparable)] }
func (s SetAny[T]) Add(v T) { s[v.(comparable)]
// etc

I also think that we need to keep current usage in mind. reflect.Type does not embed comparable and context.WithValue doesn't accept comparable and we can't really change that under compatibility rules. But that also means we can't have a Set[T comparable] which can take a reflect.Type. "If we had comparable from the beginning, we would've done that" is all well and good, but we didn't and we should consider how we go from here.

@rogpeppe Let me clarify: In my comment above, when I said "X is bad", i didn't mean "it is categorically bad, for all types", but "it has downsides". Both embedding and not embedding comparable has downsides, so no is strictly better, so we'll sometimes/often/usually/… need both.

I proposed that:

when used in a non-constraint context, comparable is a synonym for any.

For the record, that would imply that the following would be OK:
var x *comparable
var y *any = x

An alternative might be to consider comparable as a separate named type, as if it we defined as follows:
type comparable any

Is there really a problem appart from reflect.Type ?
How often do people use any potentially non-comparable interface values in Set and why would they not type assert to comparable  before insertion?
Embedding comparable does not seem like an absolute necessity every time. The proposal as it stands would enable us to test the dynamic type.

@atdiar

How often do people use any potentially non-comparable interface values in Set

The majority of interface values should be non-comparable. There are only two reasons I can think of, to embed comparable: 1. You accept it and need to put it in a map (or otherwise compare it) yourself and 2. it's effectively a closed sum (like reflect.Type or ast.Node) and you want to guarantee that all implementations are comparable.
Those are relatively rare. Most interface usages are to abstract over behavior, which shouldn't care about the dynamic type of its value.

why would they not type assert to comparable before insertion?

Of course, they can do that. That's what I said here, under "we still need this duplication". Of course the author of the Set type might chose not to do that duplication, putting the onus instead on the user of the type to do it. But avoiding that was one of the benefits given for this proposal and I just don't see that.
And, of course, the even larger problem of using struct-types with interface-fields still persists after that. That's not something that can even be solved with a type-assertion.

I am still mulling over the implications, but it seems to me that the migration for interfaces to comparable is analogous to the migration to const values in C.
Like const, comparable sets up a situation in which new APIs are more restrictive than old ones, and in which values must be cast or converted from the less-restrictive to the more-restrictive type in order to use them.
With const, if you have a const value, and you know that a function does not modify it, you can cast away the const and pass the value as a non-const type. With comparable, if you have an interface value, and you know that the caller always passes a value that is actually comparable, you can (in many cases) explicitly convert it to a comparable type.
However, I'm not sure that the comparable conversion is even always an option for, say, struct types with fields of interface types. You may know that the contents of a given field are always comparable, but you can't convert the struct type to an equivalent comparable type because struct types are not interfaces. (The comparable interface conversion would lose the struct fields.)

It seems to me that the virality problems could be at least partially addressed by defining “comparable” as a parameterized type rather than an interface type. Its behavior would be roughly analogous to the convertible.To and assignable.To interface types I described in my assignability writeup.
Here I'll describe that type as Comparable[T any].
Comparable[T] as a built-in type
Comparable[T] is a type with the same representation as T that holds the subset of values of type T for which the == operation is guaranteed not to panic.

A variable of type T is convertible to Comparable[T]. If the value held by the variable is not comparable, the conversion panics. (This essentially front-loads the panic that could later result from the == operation.)
A variable of type Comparable[T] is convertible to T.
The zero-value of Comparable[T] is the zero-value of T (which is itself always comparable).
If T is an interface type, Comparable[T] implements T. However, T only implements Comparable[T] if T is or embeds a Comparable interface type, or if the underlying types of all types in type-set of T are comparable.
The method set of Comparable[T] is the method set of T.
(optional) If T not an interface type and is itself comparable, T is assignable to Comparable[T]. (That is: because the conversion to Comparable[T] cannot fail, it may be implicit.)
(optional) Because every Comparable[T] is a T, a variable of type Comparable[T] is assignable to T.
(optional) If T is a comparable composite type, then T is assignable to Comparable[T]

I have not yet assessed whether this definition of Comparable[T] is coherent as an interface type. (The zero-value in particular is odd, since it is not nil like the usual zero-value for an interface type.)
This definition of Comparable is more useful for integrating generic types, because it allows, say, struct types with a field of an interface type to be used as a type with a comparable bound. However, I'm not sure whether Comparable[T] replaces or merely augments the non-parameterized comparable bound.

At the very least, Comparable[T] could be used to adapt existing interface types to generic APIs with comparable constraints:
type MapOf[K comparable, V any] map[K]V

func assign(m MapOf[Comparable[any], any], k, v interface{}) {
	kc := Comparable[any](v)
	m[kc] = v
}

The ergonomics still aren't great, but at least the conversion becomes possible to write at all.

What if we just don't apply comparable in a retroactive fashion. Anywhere any was used such as maps, we indeed wouldn't retroactively constrain with comparable.
On the other hand, it would be possible to offer a wrapping interface to maps that uses the comparable constraint if such an additional constraint was needed.
Meaning that in Go, in general, map keys would remain unconstrained (using any) leaving the usage of comparable for future APIs.

I guess, to summarize my comments above: defining comparable as an interface type as proposed seems coherent, but as far as I can tell does almost nothing to address the problems described in #51257.
Consider the implementation of the Union function for a Set type that allows arbitrary key-types checked at runtime:
type Set[E any] map[comparable]bool

func Union[E any](s1, s2 Set[E]) Set[E] {
	result := make(Set[E])
	for k, ok := range s1 {
		if ok {
			result[k.(comparable)] = true
		}
	}
	for k, ok := range s2 {
		if ok {
			result[k.(comparable)] = true
		}
	}
}

Now consider what happens if we instantiate above with the type:
type S struct {
	I any
}

As currently proposed in https://github.com/golang/go/issues/51338#issue-1148707830, the above implementation of Union would always panic for the type Set[S].
The problem is that the type-assertion rule is too weak (emphasis mine):

A type assertion to comparable, as in x.(comparable), would succeed if the dynamic type of x is a comparable type.

In order for the Union implementation to be viable, that rule would need to be revised to:

A type assertion to comparable, as in x.(comparable), would succeed if an interface comparison on the dynamic value of x would not panic.

But now we have a bit of a paradox: comparable is no longer a coherent interface type, because a variable of type comparable could contain a value of a type that does not implement the comparable interface!

What if a struct required all its fields to implement comparable?
That was how I was envisioning comparable.
Isn't that the only way to be sure at compile-time that a composite type implements comparable?

@bcmills

At the very least, Comparable[T] could be used to adapt existing interface types to generic APIs with comparable constraints:

ISTM this isn't substantially different than the proposal, except that the proposal spells the conversion as a type-assertion. i.e. it spells x.(comparable), instead of Comparable[T](x).

@Merovius, the difference is in whether “implementing comparable” is based on types or values. I am arguing that in order to be useful it must be based on values rather than types.
My Comparable[T] explicitly does not require T itself to be comparable: the type Comparable[T] can be read as “the comparable subset of T”.

For what it's worth, after reviewing the discussion here and better understanding the concern about the more typical use of interfaces where the implementations are intentionally outside the control of the author of the definition, I agree that it seems like a change of this sort would cause tensions when a particular interface type is to be used in several unrelated ways that have different needs.
In my case I've more often used interfaces in the two alternative ways described in https://github.com/golang/go/issues/51338#issuecomment-1058032361 -- map/set types and closed sum types -- but I believe that's because I spend most time maintaining an application rather than a library, and so we more often behave as a "closed system" rather than designing in open-ended extension points.
I can understand that this would not be true for an average Go library, and indeed some libraries I am responsible for include such open-to-implementation interfaces where I could imagine someone wanting me to make them comparable for use in a map or set, but where I would not be able to do so due to the possibility of existing noncomparable implementations.
With all of that said then: for my purposes, I would've been satisfied with a generic equivalent of the existing rule that interface comparisons are allowed statically but may fail dynamically. Although for my use-case (a closed sum type covering a finite set of possible actions) the static checking would be okay and desirable, I would be able to implement the same program by following the strategy we've typically used before generics: ensuring by manual review that all of the implementations in the closed set are comparable, and so a runtime panic is impossible in practice.

@bcmills
Oh, I meant that looking forward, for a struct type to be deemed comparable, all its fields would have to be, at compile-time.
Not sure there is a need for migration as much as using the right constraint for the behavior we need.
Set might mistakenly build upon map[comparable] bool. Perhaps that we need a more lax maybe-comparable constraint for the map keys that take into account interface values and interface fields/components.
The friction resides in the redefinition of comparability I feel.

Perhaps that we need a more lax maybe-comparable constraint

FWIW, that's exactly what comparable meant in the Type Parameters proposal as it was originally approved in #43651.
https://go.dev/design/43651-type-parameters#comparable-types-in-constraints:

The type set of the comparable constraint is the set of all comparable types.

https://go.dev/ref/spec#Comparison_operators:

Interface values are comparable.

https://go.dev/design/43651-type-parameters#permitting-constraints-as-ordinary-interface-types:

Any type that is an element of the type set could be assigned to such an interface type.

For a version of the comparable interface meaning “the subset of values that can be compared without panicking”, perhaps that would look like:

Any type that is an element of the type set could be assigned to such an interface type,
provided that either the interface type does not embed comparable or the value being
assigned is of a comparable non-interface type or an interface type that itself embeds comparable.

To assign from a non-comparable value, one would presumably need to first type-assert it to a comparable type.
The type set of the comparable interface type would thus include all comparable types (including all existing interface types), but the run-time values would include only the comparable subset of values.
That would be awkward for generic functions, though: a generic function instantiated with a legacy interface type might not panic immediately if passed a non-comparable value, while the equivalent function with a comparable argument would.

I suppose that one alternative to Comparable[T] would be to allow type-sets on run-time interface types. Then, to express an S that is also comparable for a struct type S with interface fields, you could write something like:
	kc, ok := k.(interface {
		S
		comparable
	})

Hmmh... Would it solve the below?
One of the issue with the initial proposal is assignability. The old rule was: any implements comparable (since it is an interface type and they are all comparable) without looking at the dynamic type. Don't we arrive at a contradiction with:

var test func()
fmt.Print(interface{} (test). (comparable))

?

reflect.Type is not an issue here.  The reflect.Type interface already includes unexported methods, and as such can only be implemented by types defined in the reflect package.  Therefore, we can change reflect.Type to embed comparable with no concerns about backward compatibility.

I'm not sure I fully grasp @Merovius 's color argument here.  Given any non-comparable interface Doer, I can write
type ComparableDoer interface {
    Doer
    comparable
}

That gives me a version of Doer that only permits comparable types, and that I can use with Set.  I don't know how often this will come up, but if it does come up it seems that there is a straightforward workaround, one that requires a bit of boilerplate but doesn't require replicating the entire interface definition or anything like that.

@Merovius Sorry, still catching up a bit.  I see now that you (unsurprisingly) already considered my comments.
I think it would be very helpful if people have specific examples of problems that can arise with the current decision that any does not implement comparable.  Much of the discussion in this issue, other than about reflect.Type, has been understandably somewhat theoretical.  Since I don't think reflect.Type is actually an issue, it would help to have a specific other example.  That is, an existing type, that is not an interface type, that supports the == operator but does not implement comparable, and that people would naturally want to use as a map key in some cases.
I understand the argument that comparable will spread through a program.  But I find that I don't believe it.  There aren't actually all that many cases where it matters that a type is comparable, other than using it as a map key.  And I think that types that are used as map keys tend to be specifically designed for that purpose, and I think that that is doubly true for interface types that are used as map keys.  I could be wrong about this, but am I?  Prove me wrong.
(It's worth noting that I fully expect people to write generic map packages, and those generic map packages will not depend on the language definition of ==, because that is too limiting.  They will use a comparison function.  For those kinds of maps none of these issues arise at all.)
(I should add that I don't feel too strongly about any of this.  My main concern today is that we are making the conservative choice for 1.18, a choice that we can change later without invalidating code that works with 1.18.  As far as I can see, we are.)

@ianlancetaylor

I think it would be very helpful if people have specific examples of problems that can arise with the current decision that any does not implement comparable. Much of the discussion in this issue, other than about reflect.Type, has been understandably somewhat theoretical.

I can't think of a fully concrete example of where this would have bitten me. But for illustrative purposes, maybe this hypothetical can at least convey a point. In that example, a struct type Work, with multiple fields is filled in multiple steps. During the first steps, its interface-typed field is nil, so the values are comparable and can be used as a map-key. In later steps, the interface-typed field is being filled with potentially non-comparable interface values.
Of course, this example could work around this issue by using a separate struct type for the comparable and non-comparable fields. But that's a bit of theater and I'm fairly sure I've written code like this, where a slice of structs is filled step by step in different processing steps. I admittedly don't know if it would've involved interfaces.

Thanks for the example.  Personally I would always write code like that using a map from the key (I guess URL + ContentType) to a *Work.  It would never occur to me that the io.Reader as part of the map key, because that just seems weird.  But maybe that's just me.
And there is always this approach https://go.dev/play/p/HzhWw23rpja?v=gotip ?  Maybe?
I dunno, it's suggestive, but is it convincing?  And it's not an existing type.

The hypothetical @Merovius shared could easily have applied to what I was describing in my original opening comment if what I were implementing were across multiple libraries intended for reuse, rather than a closed system.
I have a graph of actions, but the graph is built in terms of sets, which are themselves implemented as Go maps. If this were not a closed system where the graph representation and the actions mechanism were implemented together and tightly coupled, there would be no particular reason why the Action interface itself would deserve to be comparable in isolation. It's only once I want to put them in a set that the additional property of being comparable becomes important, but I wouldn't be able to do that if the definition of Action were not under my control, or if there are unrelated implementations of Action that don't need to be in the graph.
With that said, there are a lot of hypotheticals in that scenario. It's also true that I already solved it in a way that I think would also be satisfying in the less-tightly-coupled scenario: rather than trying to make Action also be a graph node, I made another type that is comparable and has an action. As far as I can tell this works even if the following three parts are controlled by different maintainers:

In a graph library: the generic graph/set implementation itself digraph.Graph[T comparable] and digraph.Set[T comparable].
In some sort of workflow modelling library: The workflow.Action interface, which is not comparable and has no justification to be within the realm of what this library provides.
In a graph-based workflow executor which uses both of the above: type GraphNode struct { Action workflow.Action }, with digraph.Graph[*GraphNode] as the graph type.

As long as you're willing to accept pointer identity as the comparison, it's always possible to wrap something in a pointer to make it comparable. If you need some other definition of identity then I think that invokes Ian's situation where the digraph.Set instance must have its own custom key-generating function (or similar), which takes a T and returns something stable and comparable that represents it.

(I should add that I don't feel too strongly about any of this. My main concern today is that we are making the conservative choice for 1.18, a choice that we can change later without invalidating code that works with 1.18. As far as I can see, we are.)

Yup. It looks like https://go-review.googlesource.com/c/go/+/381254 has changed that choice since I suggested doing so, which gives us some breathing room to consider this proposal, for which I'm grateful, thanks!
To speak in favour of this proposal for a moment, I believe that having a way of statically declaring that an interface type is comparable would be a significant benefit to Go, providing useful assurance that the code won't panic and also acting as user-visible documentation where that might not be clear otherwise. I think it's unlikely that this constraint would be significantly viral.
That said, I believe this statement is technically false:

reflect.Type is not an issue here.  The reflect.Type interface already includes unexported methods, and as such can only be implemented by types defined in the reflect package.  Therefore, we can change reflect.Type to embed comparable with no concerns about backward compatibility.

Here's an example where embedding comparable inside reflect.Type would result in a compilation failure:
https://go.dev/play/p/Bvd1uht3Gei?v=gotip
That is, the fact that unexported methods are included in it doesn't preclude other types implementing reflect.Type, and some such implementations might not themselves be comparable.
All that said, it is well known that reflect.Type should be comparable and any such implementation probably deserves that compilation failure.
Like Ian, I'd still like to see concrete examples where this proposal would actually cause problems.

@Merovius Thanks for the example. I think the current behaviour is correct there, since Work contains a io.Reader and is definitely not comparable in non generic Go. I would argue that comparable is the wrong type for the elements of a genetic set.
In java, for example there is the Hashable generic type and that is used as the basis for many other generic types. In go, i would expect a Set to likewise use a generic  Hashable interface.
Thinking about what this issue is trying to fix, perhaps it is better to wait and see if we can develop some best practices with a generics library with tye language as it is now, and after a year or two we can probably see more clearly what are the real problems to fix.

I think the probability of a specific person having encountered a specific problem in real code is relatively low - much less, that they remember it, potentially years after the fact. For example, I don't know if I ever encountered the nil vs. nil problem and while I definitely have encountered the loop variable closure problem, I couldn't actually name the occasion it happened in. So, the best I can do is try and come up with code I would plausibly write, which I tried to do above.
I thought about all of this some more. Another example (aside from reflect.Type) of an interface-type which tends to end up in maps is ast.Node. There's code in the stdlib doing it. ast.Node does not (AFAICT) contain unexported methods. But, to be fair, it falls into the same class of "it should really be a union type, but we don't have those", so it can at least be argued that it should have been given a comparable embedding.
But that made me think of another kind of ast.Node. In this case, it seems less clear. goldmark is a markdown parser and it is extensible. So an ast.Node here is not a closed union, but it is intended to be implementable by users of the library (at least AIUI). From what I can tell, the goldmark library itself does not store it in a map (I only grepped map[Node] and map[ast.Node] though, so I might've missed it), so there is no a priori reason for the library to declare the interface as comparable. But it's conceivable for an extension or user of the library to use these ast.Nodes in a map, for example to store annotations (similar to how go/types does it for go/ast.Node). That would, of course, require ast.Node to be comparable, strictly speaking.
So, in this case, the tradeoff I mentioned above comes up for the goldmark authors - should they limit the implementers of the ast.Node interface, by embedding comparable, or should they limit its users, by not doing it? Keeping in mind that the decision can't be reversed later, for backwards compatibility reasons.
These are the best, most plausible examples I could come up with so far. I will continue to idly think about this for a while, maybe I can come up with more. Maybe I can't. I honestly don't know how big of a problem this is going to be. Maybe it's fine.
Personally, I just find it strange, that interface-types are comparable, as defined by the spec, but don't implement comparable. ISTM that by choosing to not have them implement comparable, the generics design introduced an incongruency and special case, instead of trying to fit itself into the language. But maybe that's just me.

Personally, I just find it strange, that interface-types are comparable, as defined by the spec, but don't implement comparable. ISTM that by choosing to not have them implement comparable, the generics design introduced an incongruency and special case, instead of trying to fit itself into the language. But maybe that's just me.

I think it can be explained.
The change is ptobably motivated by the difference in dealing with interface value comparison vs. non-interface value comparison.
These are two different notions of comparability.
One is allowed to proceed and possibly fail at runtime.
The other one has its failures caught at compile-time.
It would be problematic to not distinguish the two:
var c comparable
var f func()

i:= interface{} (f)

c=i // ??

Unless I am wildly mistaken, if interfaces were comparable we should be able to assign i to c.
Meaning f would implement comparable?!
So I guess, now we would need to make sure that f implements comparable too for the assignment c=i to be valid.
Meaning that depending on the type that is boxed, an interface value would or would not be assignable to a comparable variable.
So I guess, perhaps that interface types are not comparable in general but only maybe-comparable.
Which would correspond to their behavior of being comparable until a runtime failure.

@atdiar I understand the logic. I just find the outcome strange.

It would be problematic to not distinguish the two: […] Unless I am wildly mistaken, if interfaces were comparable we should be able to assign i to c.

You are assuming the change of this proposal already happened and comparable is a type  - otherwise you couldn't write var c comparable. I'm arguing against doing that. Obviously, if comparable is a type, then i should not be assignable to c in that code.
What I find strange, is that it is valid to write func eq(a, b any) bool { return a == b }, but it is invalid to make that function generic. i.e. func eq[T comparable](a, b T) bool { return a == b} can't be instantiated with any, even though the manual expansion of that function is valid.
This proposal is to fix the problem that Set[T comparable] can't be instantiated with interface-types, because interface types don't implement comparable. My counter-proposal is to fix that problem by making comparable use the definition of "comparable" from the spec (which is to say, go back to how the design used to work).

Here's an example where embedding comparable inside reflect.Type would result in a compilation failure:

That's clever.  I'd rather not worry about that, but, hmmm.

@Merovius
The problem is that if we allow operations on interfaces that are not available to every member of the respective typesets they define, we lose the equivalence relation between interface implementation and constraint satisfaction.
Then, as you accurately note,  we won't be able to use some constraint interfaces as regular interfaces.
That's unfortunate asconstraint == typeset inclusion appears to be a simpler rule.
This clash is because of interfaces such as any  which are being compared in spite of their typeset.
If generic-go allows to write a sound subset of Go code that is sufficient in most cases, it might be preferable.
In any case, I think that implementing the current proposal might fix the definition of comparable somewhat irreversibly.

Sorry for being understanding this proposal too slowly. I have two questions about this proposal:

What are the differences between saying "permit values to have type 'comparable'" and "permit 'any' to implement type 'comparable'"?
If we have code in Go 1.18 that relies on func New[T comparable]() T can never return an empty interface, does this proposal mean a break of backward compatibility?

What are the differences between saying "permit values to have type 'comparable'" and "permit 'any' to implement type 'comparable'"?

The former means you can write var x comparable without getting a compilation error. This is not currently possible.
The latter would mean that you can instantiate func F[T any]() with any (or any other interface type, would be the goal), getting the same semantics of comparison as the rest of the language.
Those are basically the only two choice for making it possible to instantiate func F[T comparable]() with interface types - either you a) allow all interface types, or b) you introduce a special kind of interface type which restricts to comparable values.

If we have code in Go 1.18 that relies on func New[T comparable]() T can never return an empty interface, does this proposal mean a break of backward compatibility?

Not as stated. Because comparable would not be an empty interface. But if you can write code which relies on this being the empty interface, that code might also break if that function returns comparable. I can't really imagine how code would rely on that fact though. Do you have example code, which would demonstrate such an assumption?

@Merovius in the proposal where comparable is a specially defined interface, would it be possible to write a constrain such as:
`type ComparableIntf interface {
comparable
}
func Example[T ComparableIntf](T t) {…}`

@hherman1 Yes, but why? That's the same as just writing func Example[T comparable](T t) {…}.

@Merovius sorry, my example was incomplete. I meant something like this:
`type ComparableIntf interface {
comparable
OtherMethod()
}
func Example[T ComparableIntf](T t) {…}`

@hherman1 Yes, that's possible. It has been mentioned above a couple of times, see for example ComparableType in this comment.

Maybe the language spec should just change to define comparability for slices, maps, and functions?

Slices are equal if they have the same slice header.
Maps are equal if they are literally the same map, from the same call to make.
Funcs are never equal to other funcs, or even themselves.

Then all types in Go are "comparable". Consequently any and comparable are the same thing, so the latter is essentially deprecated.
I haven't thought through any negative implications this might have, but it sidesteps the issues mentioned throughout this thread about the two flavors of "comparable".

@rittneje Non-comparable types where made non-comparable for a reason. I don't think generics change the equation n that significantly.

Thanks for all the discussion.  We've tried to address the most pressing issue on #52474.  If that proposal is accepted, I will most likely close this one and recreate it in simpler form.

See #52614 for another take on this problem.

FWIW at this point, after all the discussion, I think I've fully come around to this proposal. I think my concerns are largely valid, but a) they happen relatively rarely, b) we might find ways to somewhat alleviate them and c) overall, after some transition pains, I think this leads to the most consistent language in the long term.
So, at least my personal opinion on this has changed.

It happens I've got here because I stumble on this issue while trying to refactor a simple code with generics, I cannot instantiate with a comparable type
type DupCount[T comparable] map[T]int

func (d DupCount[T]) Add(key T) {
	d[key]++
}

x := make(DupCount[comparable])

throw me an error
interface is (or embeds) comparable

This is the original code, been trying to replace the type check that prevents panic with a comparable constraint type and let the check happen on the compiler itself
type DupCount map[interface{}]int

func (d DupCount) Add(key interface{}) {
	if d.isAllowed(key) {
		d[key]++
	}
}

func (d DupCount) isAllowed(key interface{}) (ok bool) {
	allowedType := []reflect.Kind{
		reflect.Int,
		reflect.Int8,
		reflect.Int16,
		reflect.Int32,
		reflect.Int64,
		reflect.Uint,
		reflect.Uint8,
		reflect.Uint16,
		reflect.Uint32,
		reflect.Uint64,
		reflect.Float32,
		reflect.Float64,
		reflect.String,
	}

	for _, v := range allowedType {
		if v == reflect.ValueOf(key).Kind() {
			ok = true
			break
		}
	}
	return
}

x := make(DupCount)
x.Add(23452345)
x.Add("asdfasfd")

Is it possible for a Go team member to share the team's current thinking on this situ?
I'm wondering if you have an impression of a sensible path forward, or what would kind of consensus/changes would be needed in order to move forward?
I realise it's probably too late to get this resolved in 1.19, but it'd be great if we can get the info required to make sure we can get it figured out in time for 1.20.

It's fair to say that we're still deliberating this issue. One option might be to go back to the situation pre-Go 1.18 where ordinary interfaces did satisfy comparable, while non-comparable constraints did not. There's probably different ways we can get there. One way might be what @Merovius lined out in this comment a while back. Another approach might be to more closely match the definition to what the compiler actually implements with the existing restrictions, which is to treat method and type sets somewhat independently, and carve out a special case for non-type parameter interfaces. This may be a bit of a departure from what the spec says right now (interfaces are "just" type sets), but it wouldn't affect existing code.
Not much may happen in the next month or so as Gophers may be on vacation. But we do think it's important to solve this rather sooner than later, ideally for 1.20.

Retracting in favor of #56548.

It looks https://github.com/golang/go/issues/56548 and this issue are for two different purposes.
https://github.com/golang/go/issues/56548 is to use any interface type as type arguments of comparable constraints,
whereas this one is to let comparable be used as value types.

The two issues are two different approaches to solving the same problem.
Of course, we could also permit values to have type comparable for different reasons, but this issue was about doing it to address the #56548 problem.  If we want to do it for other reasons we can open a new proposal.


now showing s2025 tab in calendar

References

Linear: https://linear.app/hoagie/issue/DEV-82/spring-2025-missing-from-calendar-navbar

Proposed Changes

version checking w/ zustand s.t. if user's localStorage doesn't match our info (i.e. missing s2025) it will update

updated to use our static terms.ts definition instead of caching to localStorage


fix deprecated imports

/home/python/ai/langfl/.venv/lib/python3.11/site-packages/langchain/chains/retrieval_qa/base.py:183: UserWarning: VectorDBQA is deprecated - please use from langchain.chains import RetrievalQA
warnings.warn(
/home/python/ai/langfl/.venv/lib/python3.11/site-packages/langchain/chains/qa_with_sources/vector_db.py:60: UserWarning: VectorDBQAWithSourcesChain is deprecated - please use from langchain.chains import RetrievalQAWithSourcesChain
warnings.warn(

We get these straight from the __all__ in the __init__ file so these warnings happen just because we imported them, not because we are using them. I'm not sure how we should approach this in this case.


 This is an approach different than what we've done in the past, in that it puts an override directly on ScalarObservable, rather than doing type-checking in the functions themselves.
Here is a list of results (Before and After):
Before

                                         |                     RxJS 4.0.1 |             RxJS 5.0.0-alpha.3 |          factor |      % improved
---------------------------------------------------------------------------------------------------------------------------------------------------
         filter-scalar-false - immediate |               717,228 (±1.17%) |             1,516,863 (±0.45%) |           2.11x |          111.5%
          filter-scalar-true - immediate |               524,921 (±0.62%) |               966,993 (±0.65%) |           1.84x |           84.2%
                  map-scalar - immediate |               641,470 (±0.87%) |             1,372,438 (±0.62%) |           2.14x |          114.0%
        reduce-scalar-noseed - immediate |               687,545 (±1.95%) |             2,429,996 (±0.81%) |           3.53x |          253.4%
               reduce-scalar - immediate |               483,549 (±0.72%) |             1,119,916 (±1.03%) |           2.32x |          131.6%
          scan-scalar-noseed - immediate |               220,031 (±0.60%) |             2,422,950 (±0.67%) |          11.01x |        1,001.2%
                 scan-scalar - immediate |               189,861 (±1.00%) |             1,161,650 (±0.51%) |           6.12x |          511.8%
                count-scalar - immediate |               745,924 (±0.67%) |             2,462,605 (±0.58%) |           3.30x |          230.1%
               skip-scalar-0 - immediate |               703,792 (±0.76%) |             2,545,683 (±0.52%) |           3.62x |          261.7%
     skip-scalar-outofbounds - immediate |               635,857 (±0.61%) |             1,825,839 (±0.78%) |           2.87x |          187.1%
                 take-scalar - immediate |               707,963 (±0.50%) |             2,576,310 (±0.68%) |           3.64x |          263.9%

After

                                         |                     RxJS 4.0.1 |             RxJS 5.0.0-alpha.3 |          factor |      % improved
---------------------------------------------------------------------------------------------------------------------------------------------------
         filter-scalar-false - immediate |               704,688 (±3.42%) |             6,231,688 (±0.79%) |           8.84x |          784.3%
          filter-scalar-true - immediate |               520,997 (±0.97%) |             1,970,056 (±0.53%) |           3.78x |          278.1%
                  map-scalar - immediate |               626,140 (±1.73%) |             4,051,141 (±0.76%) |           6.47x |          547.0%
        reduce-scalar-noseed - immediate |               674,846 (±1.43%) |             4,074,599 (±0.88%) |           6.04x |          503.8%
               reduce-scalar - immediate |               468,252 (±0.53%) |             2,007,994 (±0.71%) |           4.29x |          328.8%
          scan-scalar-noseed - immediate |               217,599 (±2.10%) |             4,043,362 (±0.80%) |          18.58x |        1,758.2%
                 scan-scalar - immediate |               192,236 (±0.52%) |             1,970,688 (±0.94%) |          10.25x |          925.1%
                count-scalar - immediate |               691,734 (±2.01%) |             4,107,881 (±0.73%) |           5.94x |          493.9%
               skip-scalar-0 - immediate |               704,049 (±1.31%) |             4,115,490 (±0.65%) |           5.85x |          484.5%
     skip-scalar-outofbounds - immediate |               647,033 (±0.55%) |             2,456,657 (±0.85%) |           3.80x |          279.7%
                 take-scalar - immediate |               688,545 (±1.71%) |             4,030,593 (±0.54%) |           5.85x |          485.4%

Some of these are silly... like "why would someone ever reduce or skip(2) a scalar observable? But it's an inexpensive optimization, and the answer is "maybe they didn't know they had a scalar because they received it dynamically".

Nice job! Impressive results. ;)
:+1:

@blesh 👌🏽👍🏽💪🏽

Some of these are silly... like "why would someone ever reduce or skip(2) a scalar observable? But it's an inexpensive optimization, and the answer is "maybe they didn't know they had a scalar because they received it dynamically".

True, I know it can be quite common not to assume anything about the given Observable and still apply some operators on it. So they might look silly but are important, because it would be nice if Rx broke or threw errors for those cases.


feat: ability to add alt text to images

Checklist:

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)

Closes #392

So currently there are a view problems:

There is no good way of transporting variables to the new custom image extension. This is because CustomImage is extended from Image (TipTap) which holds a schema for all possible attributes that may be present on the Node.

Updating caption/alt text in the DOM is not the same as updating the image in the local Strapi instance. Meaning when updating the image alt text, it should be updated in the DOM and database. After that, the content of the editor needs to be saved. Otherwise the image alt or caption does not align with the one in the database.

CC: @sidemt and @ojeytonwilliams

One more thing that need to be solved :
At the moment it is possible to click the "Save" button multiple time when adding a new image. This adds the image multiple times into the editor. This is because the image is still being uploaded before the "Upload image modal" is closed.
There is one other issue in the editor but I will have to do more research before I can comment on that.
CC: @sidemt

Hey @sidemt,

Is it possible to disable the save button until the upload completes? If it's complicated, we can leave it to another PR.
This should be resolved now.

I will wait on #427 to go in.


Search - No "exported to CSV" system message and invalid data in downloaded CSV file

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v9.0.22-7
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp https://expensify.testrail.io/index.php?/tests/view/4874296
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:

Go to staging.new.expensify.com
Create a new workspace,
Go to workspace chat.
Submit two expenses.
Pay elsewhere the report.
Go to Search.
Go to Paid status.
Select the "Select all" checkbox for the paid expense report in Step 5.
Click on the dropdown > Download.
Go back to expense report in Step 5.
Refresh the page.
Open the CSV file.

Expected Result:
In Step 11, there will be "exported to CSV" system message in the expense report.
In Step 12, the CSV file will show the correct expense details.
Actual Result:
In Step 11, there is not "exported to CSV" system message in the expense report.
In Step 12, the CSV file shows invalid data.
Workaround:
Unknown
Platforms:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/f9d08d55-7220-4447-8bee-98dad343742b

View all open jobs on GitHub

We think that this bug might be related to #wave-collect - Release 1

We reverted the offending PR. Closing.


Update readme on how to use the OneWire interface

Spin off from -https://github.com/RobTillaart/AM232X/issues/26
For the AM2320 / 21 /22 something like

One Wire Protocol
The AM2320, AM2321 and AM2322 can also be read by using a "OneWire" protocol.
This protocol is identical to the DHT22 and will only provide a temperature,
a humidity and a CRC. See issue #26.
If one wants to use this protocol, one can use https://github.com/RobTillaart/DHTNew
and optionally force the type to 22.

Solved with 0.4.5


Shell unit-test harness must support Metal on Darwin.

Currently, support for only the software and OpenGL (via SwiftShader) client rendering APIs has been wired up in the unit-test harnesses.

I believe this should have been closed by https://github.com/flutter/engine/pull/14023


Jamming of objects in layering

How to avoid objects getting stuck in a stack of objects with the same collisionFilter.group? For example, in a jsfiddle, you can move a ball to a region with layering of rectangles so that the ball gets stuck there.
Example:
https://jsfiddle.net/mad4bzuf/

Generally you should merge bodies like these together and avoid gaps as much as possible, I've marked this as improve but it's a tricky problem.


How to "Reset to default code definition" or restore button

🚀 Feature Proposal
official website feature:

Motivation

Sometimes it is necessary to re-enter the code, this function can provide a quick reset
When I deleted the code template by mistake, I found that I couldn't get the Submit and Test buttons

Contribution

Feature request +1, This function is helpful for revising problems.
@GitHubQAQ Did you find any related info about this feature request?

I saw this button on the official website of leetcode and when I use F12, the element can be positioned correctly. But unfortunately, I can't understand how this button works due to my lack of js level, hope this can help you.
My simple idea is that the official website provides such a function, so can vscode-leetcode provide such a button?
Link to the official website: https://leetcode.com/problems/two-sum/
In order to help faster positioning, you can search for the following related codes in the element, it is recommended to use Reset to default code definition
>
Reset to default code definition


designspace axis map must not contain same keys mapping to different values

it's called "map" because it works like a mapping of keys (user locations) to values (design space locations). Just like in python dicts, one key cannot map to multiple values.
this is how varLib is translating from the "input" and "output" attributes of map elements to a python dictionary:
https://github.com/fonttools/fonttools/blob/a523a697164a4cdc721a06dec80791d4b1496f12/Lib/fontTools/varLib/__init__.py#L626
So if more than one "input" with same value is present, the last one wins and overwrites the previous ones.
Now, because of the way we map Thin, ExtraLight and UltraLight all to 250 weight class (see classes.py WEIGHT_CODES), we end up writing things like this (this is GlyphsUnitTestSans.glyphs, exported to designspace):
<?xml version='1.0' encoding='utf-8'?>
<designspace format="3">
    <axes>
        <axis default="400" maximum="900" minimum="250" name="Weight" tag="wght">
            <labelname xml:lang="en">Weight</labelname>
            <map input="250" output="17" />
            <map input="250" output="30" />
            <map input="300" output="55" />
            <map input="400" output="75" />
            <map input="400" output="90" />

In this font, there are two Thin and Extra Light instances that are assigned a 250 weight class. And there is even a "Web" instance that has default 400 weight class but has a different design location (75) than the Regular instance. In the latter case, one would expect the user to add a weightClass custom parameter (e.g. 350, in between Light and Regular) to make this unique and avoid the clash.
Note that this test font does not use the new Axes and Axis Location custom parameters, therefore is using the user location of the instances to make the axis map elements.
Even if the Axis Location was used we should raise an error if two masters have the same Axis Location but different design space locations, to prevent such invalid map elements.

there may be good legacy reasons (e.g. support some old MS Word) to have OS/2 weight class set to 250 for thin and extra light styles, but for the designspace axis maps -- which are primarily meant to be used to build a non-linear normalization mapping in the avar table -- we don't want that to happen.
The user location of a Thin named instance in a variable font is 100, not 250.
I just compared opening GlyphsUnitTestSans.glyphs in latest stable Glyphs.app (2.4.4 1075) and in latest beta (2.5b 1126) and it appears that in the latest beta, the default weight class for Thin and Extra Light is respectively 100 and 200, instead of the legacy 250 value.
So in addition of asserting that same input map to same output values (in axes.to_designspace_axes), we should also modify the default WEIGHT_CODE in classes.py to match the latest Glyphs.app beta.

and if one really wants to have a Thin or Extra Light instance's weight class be 250, one can always use the weightClass custom parameter.
Although again if more than one instance have the same weight class, we face again the same issue when constructing the axis mappings from the instances user locations...

fixed by #343


Automatically enable Helm v3 mode

Currently HELMFILE_HELM3 must be set to a non-empty value to enable the v3 mode. It works but not intuitive. Can't we do better?
My quick idea is that Helmfile could run helm version -c(-c is the shorthand for --client which skips contacting Tiller for the version number. It's v2 only) to detect the major version of the helm binary being used?
That is, if helm version -c returns 0 it should be v2 and if 1 and the error message was Error: unknown shorthand flag: 'c' in -c it should be v3.
$ helm version -c
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
$ echo $?
0
$ helm3b5 version -c
Error: unknown shorthand flag: 'c' in -c
$ echo $?

Cross-posting: https://github.com/helm/helm/issues/6322

@mumoshu Helm 3.0 released today and supports helm version -c without complaint (via https://github.com/helm/helm/pull/6868), so this should be unblocked for a non-hacky solution:
$ helm version -c --short
v3.0.0+ge29ce2a

Let me know if you'd like me to submit a PR, I'd be happy to throw one together.

@drakedevel That's super helpful! Thanks for sharing.
I'd definitely appreciate your PR!
Implementation-wise, a gotcha is that we have multiple places to pass the mode detected by calling helm version -c. Code search for isHelm3() for more on that.


Added functionality to get Field Exists by Id with Search In Site Hierarchy

Many Extension methods have a 'search in site hierarchy' argument.
I added it for the FieldExistsById check. Comes in handy now and then.

By the way, I made a typo in the branch name and the first commit. It should of course be FieldExistsById, not FieldById. I amended the commit name.

Hi martinlingstuyl, thanks for your contribution, looks good, but we'll double check. For giving you proper credits on this in our monthly call, would suggest to update your name in the GitHub profile... unless you want to stay anonymous.

Thanks, did just update my profile.

Hey Martin,
I've manually implemented your proposed change but used a slightly different approach. I'll close this PR now but you'll get credits for this change in our monthly communications.

Hi Bert,
Never mind, I'm interested to know how you pulled it off.
Martin
On 03 Jun 2016, at 17:00, Bert Jansen <notifications<EMAIL_ADDRESS>wrote:
Hey Martin,
I've manually implemented your proposed change but used a slightly different approach. I'll close this PR now but you'll get credits for this change in our monthly communications.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OfficeDev/PnP-Sites-Core/pull/546#issuecomment-223603167, or mute the threadhttps://github.com/notifications/unsubscribe/AFBgH5lay1IjN2J9mz6OXMw7GJyJueQKks5qIEGhgaJpZM4Ib7fN.

Ah, I see.. You broadened the scope to include GetFieldById...
Awesome!
On 03 Jun 2016, at 17:00, Bert Jansen <notifications<EMAIL_ADDRESS>wrote:
Hey Martin,
I've manually implemented your proposed change but used a slightly different approach. I'll close this PR now but you'll get credits for this change in our monthly communications.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OfficeDev/PnP-Sites-Core/pull/546#issuecomment-223603167, or mute the threadhttps://github.com/notifications/unsubscribe/AFBgH5lay1IjN2J9mz6OXMw7GJyJueQKks5qIEGhgaJpZM4Ib7fN.


feat(STONEINTG-677): upgrade controller-runtime, go and release-service versions

Upgrade controller-runtime to v0.16.3 along with related library upgrades
Disable http2 in webhook server when setting up manager
Adjust the metrics manager options to align with the updated API
Switch to using go version 1.20 as it's required by the above upgrade
Use the latest release-service version which is compatible with controller-runtime v0.16.3 and go v1.20
Add the admissions.warnings to validation functions
Update unit tests with the changes

Maintainers will complete the following section

[ ] Commit messages are descriptive enough (hints)
[ ] Code coverage from testing does not decrease and new code is covered (check the PR coverage on codecov)
[ ] Controllers diagrams are updated when PR changes controllers code  (if applicable)

I've tested this PR manually and made sure that the following works:

The Integration service responds to build pipelineRuns correctly and creates Snapshots with correct labels and status annotations
The Integration service responds to newly created Snapshots by triggering both static and ephemeral environment-backed integration tests (as defined by IntegrationTestScenarios)
The Integration service responds to finished integration test pipelineRuns by correctly checking for required IntegrationTestScenarios and marking the Snapshot as either passed or failed testing
The Integration service deploys the passed Snapshot to root environments, creates Releases marked for auto-release and updates the Global Candidate List
Both the admission and conversion webhooks work correctly for both v1alpha1 and v1beta1 versions of IntegrationTestScenarios


A general pattern for customization

We could approach this in many different ways.

A plugin approach.  Include whatever plugins you want to use, and the plugins do the customization.  This might get tedious, as the number of plugins that are imported might start to get REALLY long as we decompose things into smaller and smaller pieces
A customization file.  Imagine that teams write roughly the same Jenkinsfile, and then import a single Customize groovy class.  All the customizations are delegated to that Customize class.  1 and 2 could actually be combined - Cutomize could be used to load in the long list of customized plugins.

What if, at the time of Jenkinsfile.init(), we check for environment variables corresponding to each of the plugins.  If the variable is "enabled", then the plugin is automatically pulled in.  That would be a SUPER simple (also super "magical" - not necessarily a good thing) way to enable/disable functionality.

Eg: TERRAFORM_PIPELINE_PARAMETER_STORE_EXEC_ENABLED=true <-- set this as a global property in Jenkins, and automagically, every pipeline gets parameter-store-exec added.


Support Rewinding while Recording in Sourcereel

Rewrote recorder library
Added logics to support rewinding feature
Fix #1149

Pull Request Test Coverage Report for Build 4975

8 of 55 (14.55%)  changed or added relevant lines in 10 files are covered.
7 unchanged lines in 5 files lost coverage.
Overall coverage increased (+0.3%) to 37.632%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/actions/sourcecast.ts
1
2
50.0%

src/actions/sourcereel.ts
2
3
66.67%

src/components/sourcecast/Sourcereel.tsx
1
2
50.0%

src/containers/sourcecast/SourcecastContainer.ts
0
1
0.0%

src/reducers/sourcecast.ts
0
1
0.0%

src/reducers/sourcereel.ts
0
1
0.0%

src/components/sourcecast/SourcecastControlbar.tsx
0
3
0.0%

src/containers/sourcecast/SourcereelContainer.ts
0
8
0.0%

src/components/sourcecast/SourcereelControlbar.tsx
2
32
6.25%

Files with Coverage Reduction
New Missed Lines
%

src/components/sourcecast/SourcereelControlbar.tsx
1
6.14%

src/components/sourcecast/Sourcereel.tsx
1
35.09%

src/containers/sourcecast/SourcecastContainer.ts
1
23.08%

src/containers/sourcecast/SourcereelContainer.ts
1
16.67%

src/components/sourcecast/SourcecastControlbar.tsx
3
6.12%

Totals

Change from base Build 4962:
0.3%

Covered Lines:
3179

Relevant Lines:
7454

💛  - Coveralls

There is huge change on package-lock.json.

Please check the large change to package-lock.json. Is it intended or have you not evened it with sa_2021?

I added my own recorder library so I ran npm install, therefore the changes. I have checked the changes, they aren't breaking.


Add File Coverage to coverage data

It is now possible to see the coverage based on the file and then format
the data so a report generator is not needed. You can map the files from
one location to another, so if you have a copy of the repo, but in a different
location, you can still format the output in a way so it may be studied
Also, help is available for Format-FileCoverage!

the test failures seem to be flaky tests

I've triggered AppVeyor to run again

@adityapatwardhan updated and pushed

restarted appveyor due to a myget failure

@TravisEz13 would you be having a look at this?


Could you upload the files to Onedrive or Google drive.

Hello author. Thanks for the wonderful work.
I want to download the data link, however I can't sign up for the baidu since I'm living abroad.(The sign up for the abroad user was closed)
So could you give us the new link for the reproduction?

https://zjueducn-my.sharepoint.com/:f:/g/personal/hal_42_zju_edu_cn/Eu8_pllZ_vFAqAal6HWrxdMBQeTRsYt9yUt76JbInHbVQA?e=Khlwwq

Hello, this link is invalid. Would you please share with a new one? Thanks.


Request size limiting plugin error

After adding the requestsizelimiting plugin to an API all subsequent calls return a 500 error.
From errors.log:
2015/06/06 00:00:49 [error] 477#0: *26126 [lua] responses.lua:52: send_HTTP_INTERNAL_SERVER_ERROR(): An unexpected error occurred, client: <IP_ADDRESS>, server: _, request: "GET / HTTP/1.0", host: "<IP_ADDRESS>:8001"
2015/06/06 00:00:49 [error] 477#0: *26134 lua entry thread aborted: runtime error: ...hare/lua/5.1/kong/plugins/requestsizelimiting/access.lua:15: attempt to compare number with nil
stack traceback:
coroutine 0:
	...hare/lua/5.1/kong/plugins/requestsizelimiting/access.lua: in function 'execute'
	...are/lua/5.1/kong/plugins/requestsizelimiting/handler.lua:14: in function 'access'
	/usr/local/share/lua/5.1/kong.lua:206: in function 'exec_plugins_access'
	access_by_lua(nginx.conf:87):1: in function <access_by_lua(nginx.conf:87):1>, client: <IP_ADDRESS>, server: _, request: "GET / HTTP/1.0", host: "<IP_ADDRESS>:8001"
2015/06/06 00:00:49 [error] 477#0: *26134 [lua] responses.lua:52: send_HTTP_INTERNAL_SERVER_ERROR(): An unexpected error occurred, client: <IP_ADDRESS>, server: _, request: "GET / HTTP/1.0", host: "<IP_ADDRESS>:8001"

How to reproduce:
$ curl -X POST \
	--url http://localhost:8001/apis/ \
	--data 'name=benchmark' \
	--data 'target_url=http://<IP_ADDRESS>:8001/robots.txt' \
	--data 'public_dns=benchmark.api'

{"public_dns":"benchmark.api","target_url":"http:\/\/<IP_ADDRESS>:8001\/robots.txt","id":"50989ecf-6329-48ee-c843-a8d14b594112","created_at":1433549350000,"name":"benchmark"}

$ curl -i -X POST http://localhost:8001/apis/50989ecf-6329-48ee-c843-a8d14b594112/plugins \
	--data "name=requestsizelimiting"

HTTP/1.1 201 Created
Date: Sat, 06 Jun 2015 00:09:20 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: kong/0.3.0

{"api_id":"50989ecf-6329-48ee-c843-a8d14b594112","id":"3f9faf9a-3320-4dea-cde4-09e65013b3fa","value":{"allowed_payload_size":128},"enabled":true,"created_at":1433549360000,"name":"requestsizelimiting"}

$ curl -i localhost:8000 -H "host:benchmark.api"

HTTP/1.1 500 Internal Server Error
Date: Sat, 06 Jun 2015 00:09:44 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: close
Server: kong/0.3.0

{"message":"An unexpected error occurred"}

yes, it failing for request not having content-length header. pushed the fix

@shashiranjan84 closed?

Yes
On Jun 5, 2015 6:25 PM, "Marco Palladino"<EMAIL_ADDRESS>wrote:

@shashiranjan84 https://github.com/shashiranjan84 closed?
—
Reply to this email directly or view it on GitHub
https://github.com/Mashape/kong/issues/306#issuecomment-109494849.


Support minSDK 21

Hi, the current minSDK is 23 is there any possibility that you can support 21

Sorry, I just found this post. I modified it to minSdk 21.


Separate env files for production and development

It's a good practice to have separate env files for development and production. The project's backend is to have tests for routes which cannot be done in the production database.
Proposal:

having two env files instead of one, named env.production and env.development.
using cross-env, we can set an environment variable with each script (npm start, npm test etc) to denote whether the script is to be used in production or in development.

Changes to be done

installing and configuring the cross-env package for every script
updating all dotenv.config calls to include either the production or the development env file based on the environment variable passed
updating all documentations that mention of the .env file

Hello @singhayushh , as part of GSSOC21, I would love to work on this issue, if still unresolved please consider assigning to me.
Thanks


fix: assessment objectives formatting in markdown is not correct

Types of changes

[ ] Hot fix (emergency fix and release)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation (change which affects the documentation site)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Release (develop -> main)

Quality assurance (all should be covered).

[x] My code follows the code style of this project.
[x] Documentation for my change is up to date?
[x] My PR meets testing requirements.
[x] All new and existing tests passed.
[x] All commits are signed-off.

Summary
Closes #1376
Key links:

Sonar coverage

Before you merge

Ensure it is a 'squash commit' if not a release.
Ensure CI is currently passing
Check sonar. If you are working for a fork a maintainer will reach out, if required.

Closing due to problem with PR not updating


High-Level Comments

[x] #37
[x] You have a nice statement of need on your https://ephemeris.loopy.codes/lib/SPICEKernels/dev/ page, but not on the overview landing page. Adding one on the overview page would be helpful.
[x] I did not see any community guidelines (which is one of our review checklist items). Please add something that addresses that requirement to help people know how willing you are to interact with them in terms of contributions, issues, and support.
[x] A single, common, real-world example might be a good addition to the docs. If you showed how to solve it with both the SPICE and Horizons sub packages, that would be amazing. I am trying to understand the best real-world example to use here. I see you have https://github.com/cadojo/GeneralAstrodynamics.jl, so maybe you have an example motivated by that work? Personally, I would care about querying an ephemeris most in the context of knowing how far away an object would be from where my telescope is pointing... but that does not seem to be an easy application/goal of these packages, which are more focused on cartesian coordinates and state vectors. Maybe a "real-world" application is to calculate the closest approach of two objects? What is the minimum distance between Gaia and JWST over the last year? (that is a question I would find at least intriguing)
[x] You never show an example that uses the velocity information... seems like cooking up and example that uses velocities might be nice.

Velocity example posted here: https://juliaastro.org/EphemerisSources.jl/docs/dev/examples/velocity-study/

Can you point me to where you added guidelines to address?

[ ] I did not see any community guidelines (which is one of our review checklist items). Please add something that addresses that requirement to help people know how willing you are to interact with them in terms of contributions, issues, and support.

@andrew-saydjari I had thought the code of conduct was the standard "community guidelines" for projects on GitHub. I'm sure that file is not an issue, but to satisfy this item, should I add something else?

The exact wording I have is " Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support" My view is that this is different from a code of conduct. Here you are telling the people reading your README.md how you feel about contributions. Some packages have such high use rates that developers cannot respond to every issue or will only respond to PRs passing tests/some formatting restrictions. Some packages are happy to take issues, PRs, bug reports, feature requests, etc. People generally put a sentence at the bottom of the readme to explain their stance on that. See some examples

https://github.com/SciML/DifferentialEquations.jl, which directs some questions to Gitter, some to issues, and developers to a special part of the documentation.
https://github.com/andrew-saydjari/CloudCovErr.jl for a minimal example from me... just telling people we know things are still preliminary and are committed to fixing it if they make an issue.

You can be anywhere on this spectrum of complexity of statement (and also be less open to contributions), but I think the goal of this item on the checklist is to make sure you have said something about your position on contributions/issues/etc.

Done! See the README.md.


feat(SebmGoogleMap): support mapTypeControl MapOptions. #591

@SebastianM Good work, as always.  I rebased this branch with latest(RC6) master.

@TSHiYK thanks! merged


False positive ng-mocks not in JIT.

Hello,
After upgrading to the latest release of angular (13.0.2 to 13.0.3) a lot of our tests started failing with:
Error: NavigationComponent declaration has been passed into ng-mocks without Angular decorators. Therefore, it cannot be properly handled. Highly likely, jest.mock() has been used on its file, or ng-mocks is not in JIT mode.
It seems these are false positives, but I don't know why. We're on the last version of jest, jest preset angular and ng-mocks.

Hi @icorne
Thanks for the info. The next week I'm back from vacation and take a look at the issue.

This is a duplicate of #1427.

v13.0.0 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


How did you set up log directory name when you conducts different experiments?

It seems that the default log directory name is "outputs/". I want to change this name because I need to conduct multiple different experiments. How did you make it?

The output path is hard-coded on line 9 of src/misc/LocalLogger.py:
LOG_PATH = Path("outputs/local")

This should probably be configurable via Hydra, but unfortunately isn't (although it should be fairly easy to modify). We used the local logger for quick debugging because it's faster to start up than Weights and Biases, which we used to log full training runs. If you use wandb.mode=offline or wandb.mode=online, you can set wandb.name to give each run a unique name and path.

Thanks


Wrong coordinate system and alignement for the python lsm9ds1 driver

After implementing the madgwick algorithm on it, I noticed that the accelerometer, the gyros and the magnetometer were not lining up. The resulting coordinate system wasn't even direct.
The following code corrects the results of the accelerometer and gyro :
            acc,gyr,mag=(self.imu2.getMotion9())
            acc[0],acc[1]=-acc[1],-acc[0]
            gyr[2]=-gyr[2]
            gyr[0], gyr[1] = gyr[1], gyr[0]

Now, for the acc. and the gyro. : the z axis points toward the ground, x follows the arrow on the PCB and y is such that the coordinate system is orthogonal direct.
I don't know how to check if the magnetometer is aligned, but after calibrating it (and correcting the acc and gyro), the madgwick algorithm gave me the right pitch, roll and yaw, with very good performances

Hi @hubble14567
Thank you!
We'll take a look at this soon. Is this all changes you propose to add? May I suggest using a PR for this?

Hi,
Is this all changes you propose to add? Yes
May I suggest using a PR for this? If you want, yes you can do so.
I never (realy) used github before, this comment was a while ago and I don't have my Navio anymore (so I cannot troubleshoot and create a good PR myself). I simply posted this to quickly help other people with a problem I solved. Do whatever your think is best with my original post.

Got it, thanks.

@AlexanderDranitsa @hubble14567 the LSM9DS1 driver outputs is data to match the MPU9250 axis orientation. Could be that the source of the issue? This behavior kind of confusing and it is not well documented (that is why the axis change may seem quite arbitrary), but I think it is made this way so the AHRS algorithms supplied by Emlid work with any of the two IMU.

@gmsanchez I don't remember using the MPU9250 (had some issues, and LSM9DS1 was working fine), so I cannot tell you if the axis of both match. Also did not use the AHRS from Navio. Your theory is possible.
Nonetheless the coordinate system is highly confusing, and I would also change it on the MPU9250 if it is the same. The norm for coordinate systems should be x forward (that's the arrow one the Navio), z down and (most importantly) y in a way that creates an orthogonal direct coordinate system. LSM9DS1 coordinates system for the acc and gyro were a mess in that regard and were not even the same.

Something similar happened to me a while ago, when I needed the axis to conform to ENU. I suggest you download both the LSM9DS1 and the MPU9250 datasheet and see how their axis are oriented on the Navio2. Then try to apply the LSM9DS1 axis the same operations as the ones that are made in the driver. After that, they should match the MPU9250 or at least you can make sure where each axis is pointing.


Added New-NSResponderPolicy function

New function to create a new Responder Policy.
Related Issue
#51
How Has This Been Tested?
Tested in my local environment
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Thanks @rokett


VS Code can't find Homebrew-installed Conda

Applies To

[X] Notebooks (.ipynb files)
[ ] Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?

On macOS 14.3.1, install Conda with brew install miniconda
Open VS Code and open any ipynb file.
Press Shift-Cmd-P and click on "Notebook: Select Notebook Kernel"
Click "Select Another Kernel..."
Click "Python Environments..."
Click "+ Create Python Environment"
Click "Conda"

Expected result: A menu with a choice of the version of Python to install in the environment.
Actual result: An error box in the bottom right corner, saying Install `conda` to create conda environments.
Probable root cause: the hardcoded glob patterns for searching Conda in src/test/interpreters/condaService.node.ts, which don't match /opt/homebrew/bin/conda.
Quick workaround: cd /opt && sudo ln -s homebrew conda (since /opt/conda/bin/conda is matched by the patterns).
A quick solution would be to add a pattern for Homebrew, and a better one would be to look for Conda in a way that is independent of the way it is installed.
VS Code Version
Version: 1.87.2 Commit: 863d2581ecda6849923a2118d93a088b0745d9d6 Date: 2024-03-08T15:20:57.520Z (3 wks ago) Electron: 27.3.2 ElectronBuildId: 26836302 Chromium: 118.0.5993.159 Node.js: 18.17.1 V8: <IP_ADDRESS>-electron.0 OS: Darwin arm64 23.3.0
Jupyter Extension Version
v2024.2.0
Jupyter logs
No response
Coding Language and Runtime Version
No response
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
No response
Running Jupyter locally or remotely?
Local

I tested it with v2024.5.11021008 (pre-release), and it still doesn't work.

@kxmh42 You can see here that we specifically look at /opt/homebrew/bin
https://github.com/microsoft/vscode-python/blob/77e44cf2dacc7b6de24fe45318ecac2fd0f439f7/src/client/pythonEnvironments/common/environmentManagers/conda.ts#L345
The latest version of the extension is: 2024.5.11172159 and you will need latest VS Code insiders to install the latest python extension insiders.

I updated to v2024.7.11241010 and can see the above prefixes.push call is present in the compiled code in .vscode/extensions/ms-python.python-2024.7.11241010/out/client/extension.js. However, the bug can still be reproduced with the exactly same steps as above – it cannot find Conda.

Can you provide logs (Output > Python)again with the latest extension? Make sure you have VS Code version 1.89, and the python extension version 2024.6.0 or greater.

VS Code v. 1.89.0, Python extension v2024.7.11241010
2024-05-06 15:44:14.928 [info] Telemetry level is off
2024-05-06 15:44:14.928 [info] Experiments are disabled, only manually opted experiments are active.
2024-05-06 15:44:15.010 [info] Default formatter is set to null for workspace /Users/kaxia/proj/new
2024-05-06 15:44:15.027 [info] > conda info --json
2024-05-06 15:44:15.029 [info] > hatch env show --json
2024-05-06 15:44:15.030 [info] cwd: .
2024-05-06 15:44:15.039 [info] Python interpreter path: /usr/bin/python3
2024-05-06 15:44:15.270 [info] > pyenv which python
2024-05-06 15:44:15.271 [info] cwd: .
2024-05-06 15:44:15.281 [info] > /opt/homebrew/bin/conda/bin/conda info --json
2024-05-06 15:44:15.281 [info] > /opt/homebrew/bin/conda2solv/bin/conda info --json
2024-05-06 15:44:15.290 [info] > ~/.conda/bin/conda info --json
2024-05-06 15:44:15.291 [info] Found: /usr/bin/python3 --> /usr/bin/python3
2024-05-06 15:44:15.319 [info] > /usr/bin/python3 -I ~/.vscode/extensions/ms-python.python-2024.7.11241010/python_files/get_output_via_markers.py ~/.vscode/extensions/ms-python.python-2024.7.11241010/python_files/interpreterInfo.py
2024-05-06 15:44:16.202 [info] Starting Pylance language server.

See the comment in getCandidatesFromKnownPaths:
// Check common locations. We want to look up "<prefix>/*conda*/<suffix>", where prefix and suffix
// depend on the platform, to account for both Anaconda and Miniconda, and all possible variations.

And the definition of suffix:
const suffix = getOSType() === OSType.Windows ? 'Scripts\\conda.exe' : 'bin/conda';

Adding /opt/homebrew/bin to prefixes is incorrect, because now it is looking for the Conda binary in /opt/homebrew/bin/*conda*/bin/conda, and the correct binary path is /opt/homebrew/bin/conda.
In addition to /opt/homebrew/bin/conda, please also consider looking for Conda binary in ~/.local/bin/conda (that is, path.join(home, '.local', 'bin', 'conda')), as this is where the executable might be if it is installed locally on the user's account. I see the same error as above when I run VS Code remotely on a Linux server with Conda installed just on my account.

@kxmh42 Thanks for looking into this. I got this wrong when I tried it, I will do a fix soon.

This should not be fixed with the native locator.


Docker: Combine RUN statements for smaller images

This will not affect image size. This only makes sure we use the latest pkg lists and not the apt-get cache, which is good.
The title should've been different.


Iox 36 untyped api

Pre-Review Checklist for the PR Author

[x] Code follows the Rust coding style and is formatted with rustfmt
[x] Branch follows the naming format (iox-123-this-is-a-branch)
[x] Commits messages are according to this guideline

[x] Commit messages have the issue ID (iox-#42 commit text)
[x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)

[x] Update the PR title

Follow the same conventions as for commit messages
Link to the relevant issue

[x] Relevant issues are linked
[x] Add sensible notes for the reviewer
[x] All checks have passed (except task-list-completed)
[x] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code according to our coding style and naming conventions
[ ] PR title describes the changes

Post-review Checklist for the PR Author

[ ] All open points are addressed and tracked via issues

References

Closes #36

@neilisaac I'm currently implementing the reactor pattern for the WaitSet/Listener. If you are interested, I can ping you once I have a draft PR.


Fix code for internal branches

Sorry, I used the wrong parameter name #25

... I'll merge this, but I reckon the issue is that even with 100% unit coverage, we need real end to end tests. Maybe at some point we'll need automated tests, but one way or another, it would be nice if we could manually test this before merging in the meantime.
That being said, I trust you that this will actually solve the issue :)

Yes, sorry again. I really didn't mean to break the code. But somewhere between testing locally with the API and changing the code, I must have copied the wrong name.
I just tested again in my own project where I had noticed the error too and everything is running correctly again now. So the error should be fixed.
Real end-to-end testing would certainly be very helpful, but I also understand that it's difficult to set up. I will test more extensively locally in the future.

Don't beat yourself up, it's not your fault. If the process (the automated CI, my review, etc) left enough room for a bug to arise, then it's the process that's faulty. That was an honest mistake :)

I'm not sure that it would be that hard to setup something automated, especially using the gh cli. That said, it might be easier if it runs post-merge, at least for a start.


[DMA 4/8]: Apply Peripheral pattern

Don't let me get away with the I8080 change, it's incomplete - asyncness is implied by usage right now, which is bad.