proposal: spec: allow basic interface types to instantiate comparable type parameters

TL;DR
This is a restatement of proposal #52509 by @zephyrtronium. That issue has collected a lot of comments; starting anew will make it easier for readers to follow along again. The primary additional contributions in this issue are the formulation of the exact spec changes, a corresponding new API for go/types, and a discussion of these changes in the context of a future Go without the current implementation restrictions on interfaces. As a result, this issue is long, but the actually proposed change is small.
Background
The Go 1.18 release introduced the predeclared identifier comparable which denotes the set of all non-interface types that are comparable. More precisely, it is the set of (non-interface) types for which == and != are defined and for which these operations are guaranteed to not panic.
The types in the comparable type set do not correspond to the types of comparable operands: for instance, struct{ f any } is comparable but applying == on the field f may panic.
For clarity, in the following we use the term strictly comparable for the types in comparable, and spec-comparable for types of comparable operands. Strictly comparable types are spec-comparable, but not the other way around. Types that are not spec-comparable are simply not comparable.
Because in Go 1.18 and Go 1.19 constraint satisfaction means interface implementation, not all spec-comparable types satisfy the comparable constraint. The generic map type
type mymap[K comparable, V any] map[K]V

cannot be instantiated with struct{ f any } for K, but the built-in map type permits that. This is a major handicap for the design of generic data structures. See #51257 for another example.
Over the course of this year, many ideas have been proposed to address this problem, while trying to preserve the rule that constraint satisfaction and interface implementation remain the same. Here's a (possibly incomplete) list of proposals for reference: #51338, #52474, #52531, #52614, #52624, #53734.
If we want any to satisfy comparable, then constraint satisfaction can't be the same as interface implementation.  A non-comparable type T (say []int) implements any, but T does not implement comparable (T is not in comparable's type set). Therefore any cannot possibly implement comparable (the implements relation is transitive - we cannot change that). So if we want any to satisfy the comparable constraint, then constraint satisfaction can't be the same as interface implementation.
A pre-Go1.18 implementation of the compiler did not treat interface implementation and constraint satisfaction the same, which led to initial confusion because of the resulting inconsistency (see #50646). Eventually the inconsistency was considered an implementation bug (in hindsight this was done without enough consideration of all the implications). With more experience it appears that this inconsistency made it easier to use generic Go with commonly used Go types.
@zephyrtronium's #52509 and this issue propose that we go back to this pre-Go1.18 implementation of constraint satisfaction.
Proposal
We change the spec to use a different rule for constraint satisfaction than for interface implementation: we want spec-comparable types to satisfy comparable; i.e., we want to be able to use any type for which == is defined even if it may not be strictly comparable.
Specifically, in the language spec section on Instantiations, we propose to change the 2nd rule from (old):

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

to (new):

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

We also add a new paragraph defining what "satisfy" means:

A type T satisfies a constraint interface C if

T implements C; or
C can be written in the form interface{ comparable; E }, where E is a basic interface and T is comparable and implements E.

With this change, constraint satisfaction matches interface implementation but also contains an exception for spec-comparable types. This exception permits the use of interfaces as type arguments which require strict comparability.
This is the entire proposal.
Observations

The proposed change expands the set of types that satisfy a constraint, therefore no existing programs are invalidated and the proposal is fully backward-compatible. See the section on Implementation below for when the feature becomes available.

The spec has various implementation restrictions: interfaces that are not basic may only be used as type constraints, or as elements of other interfaces used as constraints. They cannot be the types of values or variables, or components of other, non-interface types. Because of these restrictions, if the type argument T is a (non-type parameter) interface, it must be a basic interface. Thus, we can ignore the case of type-constrained interfaces (such as interface{ ~[]int }) which can only hold non-comparable types. For the same reason, if T is a non-interface type with an interface field (such as struct{ f F } where F is an interface), F must be a basic interface. In other words, we don't need to complicate the rules to explicitly disallow such types for T: any interface that is or appears in a (non-type parameter) type argument must be a basic interface and therefore is spec-comparable.

The spec has additional implementation restrictions in place: comparable and interfaces containing methods may not appear as terms in a union (with more than one term). Because of these restrictions, if comparable appears in an interface (or an embedded element), it can be "factored out to the top"; the same is true for methods. More precisely, constraint interfaces can always be written in one of two forms: interface{ comparable; E } or interface{ U; E }, where E stands for all the interface's methods (if any), and U denotes a union of non-interface types (if any). (An interface of the form interface{ comparable; U; E } can always be reduced to the form interface{ U'; E } by eliminating all non-strictly-comparable terms from U).

For interface{ U; E } constraints, constraint satisfaction is the same as interface implementation: nothing changes. For a type T to satisfy the constraint, it must be in the union and satisfy all the methods, if any.

For interface{ comparable; E } constraints, constraint satisfaction is looser: we still expect a type argument T to implement all the methods E, but we allow any T which is spec-comparable, even if it is not strictly comparable. This is not statically type-safe and must be remedied with a run-time check for ==.

Because the new rule invalidates static type safety, the definition of strictly comparable is not quite correct anymore: == on an operand of a strictly comparable type parameter type may in fact panic at run-time. To be able to separate the various kinds of comparability, strictly comparable now more precisely denotes the set of types for which == and != are defined and for which these operations won't panic if type safety was never broken through the instantiation of a (strictly) comparable type parameter with a spec-comparable type argument.

If a type parameter P is spec-comparable, it is always strictly comparable (but see the previous observation). Therefore, if a type parameter is used as a type argument for a constraint of the form interface{ comparable; E }, the rule that P must "only" be spec-comparable doesn't weaken any static type guarantees because P will be strictly comparable.

The pre-Go 1.18 implementation, before the inconsistency documented in #50646 was reported, matched the proposed rules.

Eventually we may want to remove the existing implementation restrictions. This will also require a generalization of the rule for constraint satisfaction. To ensure backward compatibility, the proposed rule here should match a future, more general rule adjusted for the current implementation restrictions. But at the very least, the proposed rule should not permit more programs now than might be permitted with a more general rule for constraint satisfaction. See the appendix for an attempt at such a generalization.
Examples
Currently, any does not implement the comparable constraint. With the proposed change any will be permitted as type argument for comparable: comparable can be written as interface{ comparable; E } and thus the new rule applies, and any is spec-comparable and implements E (where E is the empty interface in this case).
Currently, the type parameter P in the type parameter list
[P interface{ comparable; fmt.Stringer }]

cannot be instantiated with the type S
type S struct {
	data any
}

func (S) String() string

because S is not strictly comparable. With the proposed change, S must only be spec-comparable (which it is) and implement fmt.Stringer (which it does).
More examples
type mymap[K comparable, V any] map[K]V

func _[P any, Q comparable]() {
	var (
		_ map[func()]string        // invalid with current and new rules: func() is not comparable
		_ map[struct{ f P }]string // invalid with current and new rules: P is not comparable
		_ map[struct{ f Q }]string // valid: key type is strictly comparable

		_ mymap[any, string]                // currently invalid, valid with new rules: any supports ==
		_ mymap[struct{ f any }, string]    // currently invalid, valid with new rules: type of f supports ==
		_ mymap[struct{ f func() }, string] // invalid with current and new rules: f is not comparable
		_ mymap[struct{ f int }, string]    // valid: key type is strictly comparable
		_ mymap[struct{ f P }, string]      // invalid with current and new rules: P is not comparable
		_ mymap[struct{ f Q }, string]      // valid: key type is strictly comparable
	)
}

Implementation
The proposal requires minor changes to the typechecker:

We have already implemented this alternative semantics at tip so that we can experiment. The new compiler flag -altcomparable enables the new behavior (disabled by default):

go tool compile -altcomparable <file.go>      // applied to a single file
go build -gcflags=-altcomparable <pkg path>   // applied to a package
etc.

If the proposal is accepted for Go version 1.nn, we will replace this flag with a version check that enables the new behavior starting with Go 1.nn.

Clients of go/types need to be able to check for constraint satisfaction, which is now slightly different from interface implementation. We cannot add a flag to the existing types.Implements function without breaking backward-compatibility. Instead, we propose to add the following exported function:

// Satisfies reports whether type V satisfies the constraint interface T.
//
// The behavior of Satisfies is unspecified if V is Typ[Invalid] or an uninstantiated
// generic type.
func Satisfies(V Type, T *Interface) bool

We may also want to provide a variant of types.Comparable that implements the notion of strict comparability. We can wait with this until a clear need arises.

All these changes are trivial (the internal implementations exist, they just need to be exported).
If this proposal is accepted in time, it could become effective with the Go 1.20 release.
Related spec issues

The current definition of the type set of the predeclared type comparable is incorrect in the spec. The definition is as follows:

The predeclared interface type comparable denotes the set of all non-interface types that are comparable. Specifically, a type T implements comparable if:

T is not an interface type and T supports the operations == and !=; or
T is an interface type and each type in T's type set implements comparable.

The first rule (T supports the operations == and !=) also includes types (such as structs) which may not be strictly comparable (see the structs used in the examples above). The rule needs to be amended to exclude types for which == may panic.

The definition of comparable operands in the spec is missing a dedicated rule for operands of type parameter type. Without it, type parameters (whose underlying types are their constraint interfaces) fall into the category of spec-comparable interface values. This is incorrect. A type parameter-specific rule needs to be added to this section.

Both these spec corrections should be made irrespective of whether this proposal is accepted or not.
Appendix
In a hypothetical future version of Go ("FutureGo") where generalized interfaces may be used as ordinary types, the constraint satisfaction rules must be suitably extended and expressed in terms of type sets. @ianlancetaylor proposes the following FutureGo rules:

Given a (constraint) interface C, we define two type sets S1 and S2 as follows:

S1 is the type set of C computed in the usual way, except that wherever comparable appears in C
it is treated as the set of all (spec-)comparable types (not just the strictly comparable types); and
S2 is the type set of C computed in the usual way, except that wherever comparable appears in C
it is treated as the set of all types, any.

Given these special type sets S1 and S2, we can define general constraint satisfaction as follows:

A type T satisfies a constraint interface C if

T is not an interface type, and T is an element of type set S1; or
T is a (non-type parameter)  interface type, the type set of T is a subset of the type set S2,
and the intersection of the type set of T with the type set S1 is not empty; or
T is a type parameter and T implements C.

(The case for type parameters can be folded into the case of non-interface types, but for the following discussion it is clearer to handle it separately.)
If T is not an interface (or type parameter) type, it is not hard to see why the respective sub-rule makes sense: instead of only accepting strictly comparable types for comparable, the use of the type set S1 permits any spec-comparable type.
If T is an interface type, we also want to accept it as a type argument for comparable: more precisely, any interface type, irrespective of its type set, supports == and thus is spec-comparable (we could say that non-basic interfaces don't support == by default, but that's an separate discussion). Effectively this means that comparable is the same as any in this case, hence the type set S2. However, we (probably) want to exclude interface types with type sets for which we can prove that == can't possibly succeed. For instance, interface{ ~[]int } is spec-comparable (all interfaces support ==, but see the comment on that above), but its type set only contains non-comparable types: comparing operands of type interface{ ~[]int } will always panic. The intersection of the type set of such interfaces with the type set S1 will be empty (if it were not empty, the interface would contain at least one spec-comparable type and so == might always happen to succeed in a concrete application). This explains the second part of the rule for interfaces.
Finally, if T is a type parameter, nothing changes and we can simply ignore this case below.
To make sure we remain forward-compatible with FutureGo, i.e., that these generalized constraint satisfaction rules do not restrict our current, limited proposal, we need to show that our current proposal doesn't permit more types for a constraint than the FutureGo rules.
We can do this by applying the current implementation restrictions to the FutureGo constraint satisfaction rules. With those restrictions in place, from the Observations section we know that constraint interfaces can appear in only two (canonical) forms:
a) interface{ comparable; E }; or
b) interface{ U; E }
where E stands for all the methods in the constraint (if any), and U denotes a union of non-interface types (if any). Therefore, the respective type set S1 is either
S1a which is the type set of interface{ comparable; E } with comparable denoting all spec-comparable types; or
S1b which is the type set of interface{ U; E } (unchanged).
Similarly, the type set S2 is either
S2a which is the type set of interface{ E }; or
S2b which is the type set of interface{ U; E } (unchanged).
Now we can look at the type argument T and how the generalized rules apply:
If T is not an interface type, per the generalized rules, T must be an element of S1. Therefore, T must either be an element of S1a, or S1b. If the former is true, T must be spec-comparable and implement the methods E - this corresponds to the our proposed exception for interface satisfaction. If the latter is true, T is simply an element of the type set of the constraint, which means T implements the constraint. This corresponds to the non-exceptional part of the proposed rule for constraint satisfaction.
If T is a (non-type parameter) interface type, with the implementation restrictions in place, T must be a basic interface. Per the generalized rules, the type set of T must be a subset of S2a and the intersection of T's type set and S1a must not be empty, or the type set of T must be a subset of S2b and the intersection of T's type set and S1b must not be empty. If the former is true, T implements the methods E, and because T is a basic interface it is also spec-comparable. This corresponds to the proposed exception for constraint satisfaction. If the latter is true, T simply implements the constraint, which again corresponds to the non-exceptional part of the proposed rule for constraint satisfaction.
In summary, if we apply the current implementation restrictions to FutureGo, the FutureFo constraint satisfaction rules reduce to the rules proposed in this issue. This provides some insurance that the proposed rules won't cause problems in FutureGo.

A type T satisfies a constraint interface C if

T implements C; or
C can be written in the form interface{ comparable; E }, where E is a basic interface and T is comparable and implements E.

With this change, constraint satisfaction matches interface implementation but also contains an exception for spec-comparable types. This exception permits the use of interfaces as type arguments which require strict comparability.

This seems like a small and clever rule with intentionally broad consequences. I'm not sure why this approach is preferable to, in particular, https://github.com/golang/go/issues/52509#issuecomment-1118972932 by @Merovius. Adding the "satisfies" relation seems to be helpful for the go/types API, but we can do that and also have a list of small explicit rules rather than a very big implicit one. Perhaps that's just my reading.

The approach suggested by @Merovius changes the meaning of type sets to include interfaces, which seems like a pretty big change. The end result may still be the same, but I haven't tried to prove that in any way.
If we want an interface, say any to satisfy comparable - which the comparable issues are all about - constraint satisfaction simply cannot be the same as interface implementation. Thus, the simplest change I can think of is to separate the two and introduce an exception for exactly the cases which we want to cover. Unless I'm overlooking something (which is entirely possible), it seems that the proposed rule does exactly what developers want: to be able to use a spec-comparable type where we request a comparable type argument, similar to what we always could do with map keys.

Since after implementing this comparable is equivalent to any since any will satisfy the comparable constraint, I don't understand why comparable is needed. What can we model with a comparable that will include any that we can't model with any alone?
There may be advantages when stenciling out the actual usages, but type safety is not improved over just using any.
Also when following this proposal one again cannot model comparable types without special support for equality that comparable enables right now. I don't see a plan for regaining this capability in in the proposal.

comparable is not the same as any with this proposal nor do we state that anywhere. It's not possible to use a non-comparable type (such as []int) as type argument for a type parameter constrained by comparable - yet if the constraint were any, it would be possible. What this proposal does is carving out just the right (I think) exception to permit types that in Go are considered comparable as type arguments constrained by comparable. We retain all the static safety elsewhere. Static type safety is definitely stronger than with any.
I do not understand what you mean by your second paragraph. Can you provide an example of the capability you're missing?
Finally, you may want to try and play with the actual implementation of this feature which is available to you at tip (see the Implementation section of the proposal). Perhaps that helps clarifying the impact this would have on your code.

Thanks for sharing this proposal. It broadly makes sense to me and I believe it will allow me to write the programs I described wanting to write in some of the previous proposal discussions (which I will not repeat here).
I do have a clarifying question, though:
The proposed text constrains E in interface{ comparable; E } to be a Basic interface. The spec currently defines that as an interface whose body consists only of methods.
The following section of the specification defines "Embedded interfaces" without describing the interaction between "Basic interface" and "Embedded interface". Is it true to say that an interface which embeds a basic interface is itself a basic interface as long as it otherwise meets the definition of a basic interface?
Concretely, is B in the following example a "basic interface" for the sake of satisfying the proposed new rule?
type A interface {
    Foo()
}

type B interface {
    A
    Bar()
}

Yes, B in your example would be basic interface. Per the spec:

Interfaces whose type sets can be defined entirely by a list of methods are called basic interfaces.

Thank you for the detailed proposal.
Sorry in advance for the long-winded comment. I think this proposal is a step toward a solution although there are a few things that I think differ from the conclusions of #52509 and #53734 and these differences may be important.
(also, note that #53734 and its predecessor suggests to differentiate between interface implementation and constraint satisfaction)
To be honest, I've found some of the explanations a bit hard to follow personally (which might be from my own limitations).
I think that the issue is that:

we have two definitions for comparability : spec comparable and strictly comparable (I have myself changed my mind on this and think it could be an unnecessary distinction)
constraint satisfaction seems to depend partially on interface implementation (a bit confusing to me, I believe that should be the opposite if anything)
comparable still seems to be treated as a special-case (which seems to be confusing others apparently)
FutureGo would require two kinds of type sets? (maybe I misunderstood)
maps in regular code and in generic code do not behave the same wrt acceptable map key types

(5) is about struct types whose fields may be interfaces. https://go.dev/play/p/JkAcqvXlirF
In current Go, these types are accepted as map keys even though they might  trigger a runtime panic. So they can be used in Set datastructures that are built upon maps. I think this was one use-case that was mentioned by people.
They are indeed satisfying the comparable constraint if we define such constraint as the proposition: has the comparison operators == and !=.
That however does not mean that these types would implement a potential future comparable interface. Admittedly, that part has been underdiscussed but seems that any composite type would implement comparable if and only if every part of that type implements comparable.
For a struct, that would be every field. For an array, the type argument to the array constructor should implement comparable.
Following this, we would not require a distinction between spec and strictly comparable. That takes care of issue 1 and issue 5 as the distinction would merely be between implementing and satisfying.
But now, what about 2,3,4 ? What is even implementing an interface and satisfying a constraint, why does it differ? How to build a simple mental model?
That's where I think there has been attempts to establish the (long) list of requirements for each in the spec but I think it shows that the mental model may need to be clarified so that it is made simpler and more obvious.
If we take a step back and think about it (I will probably be paraphrasing #53734):

A. An interface type defines the set of constraints that allow to group types together. It defines thus a set called a type set.
B. Any type is also an interface (conceptually) and defines a type set that is a singleton.
C. comparable is just an interface defined by the set of constraints { has == and != operators}
D. A type U satisfies a constraint  interface V iff U belongs to the type set of V by definition
E. An interface I implements an interface J iff we can show that all types that satisfy I satisfy J. (i.e. the type set defined by I is a subset of the type set defined by J i.e. the set of constraints defining J is a subset of the set of constraints defining I)

So as can be seen (in A,D,E), the definition of constraint satisfaction is the basis for a definition of interface implementation instead of the reverse.
We have only one kind of type sets and one kind of comparability. That's simpler.
Also because assignment to an interface value must be true for all satisfying typed values, it is by definition using interface implementation as a requirement. In the case of comparable, it would correspond to what is defined as strict comparability in the current proposal.
Constraint statisfaction is what is used by type parameters, so
struct{
  int
  ast.Node
}

should still be able to instantiate generic map key, just like in normal Go code since it has the comparison operators.
Now on the question of whether interface types belong to type sets or not?
... it depends.
We just need ot apply the rules since an interface is just a set of rules that determine a set of types.
Obviously that means that interface types may belong to type sets. Sometimes they would not. e.g. interface{ int | string}
Another question is whether all interface types should satisfy comparable ?
As mentioned in this proposal, it might seem less clear for interface{ ~[]int} .
I would still tend to say yes but it is perhaps not mandatory. Having these operators doesn't seem to rely on type sets as seen with any. Quite the opposite, the availability of these operators determine the type set instead.
In any case, it should be evident that it does not implement comparable, however. There is a difference between a type and the set it denotes.

I believe the mental model needed here remains very simple: Constraint satisfaction is the same as interface implementation (nothing changes), but we introduce an exception so that Go's (spec-) comparable types can also be used where (strictly) comparable type arguments are required.
That is all, and that is exactly what users are asking for. The reason we need this is that historically, Go was not statically type-safe with respect to ==: the operation can panic in some cases. But when writing generic code, we want to preserve type-safety as much as possible (which is why comparable is not the same as spec-comparable), this is simply something users don't want to give up. These two goals are conflicting, and the only way to bridge the gap is through an exception. Which is what we propose.
Now, to answer your questions:

We have always had (spec-)comparable and we cannot change that or it would break backward-compatibility. With Go 1.18 we introduced comparable which stands for strictly comparable types. We could make comparable the same as spec-comparable (a sort of late fix for a "bug" in the generics design), one could even get rid of comparable (make it mean any), see e.g. #52614. But this and similar ideas were vehemently rejected repeatedly. People want comparable to provide some guarantees, which is what we have now. Therefore comparable must be different from spec-comparable.

Constraint satisfaction depends mostly (not partially!) on interface implementation because we want to keep it that way. We just added an exception for spec-comparable types. That is the whole point of this proposal.

comparable is a special interface: it is predeclared because we don't have another mechanism in the language to denote strictly comparable types (and we don't want to invent one either, a predeclared identifier works fine). Again, if we accept 1), comparable must be different from spec-comparable.

FutureGo is a thought experiment. We want to make sure that this proposal holds up even if we were to remove the current implementation restrictions. Or, looking the other way, we want to make sure that we can remove the current implementation restrictions and not run into problems because of this proposal. To that effect, @ianlancetaylor has proposed a set of (plausible) rules for constraint satisfaction that we believe would work with such a future Go, and then we show that this proposal doesn't conflict with those hypothetical future rules. It is possible that these future rules can be expressed more clearly and concisely. All this is relevant here only insofar that it gives us some confidence that this proposal is reasonable.

The built-in go map type behaves the exactly the same in all cases: the key type must be spec-comparable. If you define your own generic map type with a key type parameter that is comparable, it also accepts spec-comparable types. With this proposal, your example type

struct{
  int
  ast.Node
}

can be used to instantiate a generic map key. Again, that is the goal of this proposal.
I very much agree with you that it would all be much simpler if there was only one type of comparability - and we have tried that before (again see #52614 and perhaps others). But users want stronger guarantees.
To summarize:

users want to express in generic code that comparable really means strictly comparable (but see the next point)
users still want to use any for a strictly comparable type parameter
this is an inherent conflict and requires an exception in the constraint satisfaction rules
this proposal provides exactly that exception without changing anything else

(Regarding your last two questions: a) should interfaces be parts of type sets, and b) should all interfaces satisfy comparable. For a): probably not - but we don't need to answer this question for this proposal. For b) see point 1) above and the paragraph I wrote before the summary. I think you are going in circles.)
I recommend you play with the implementation available at tip. Setting the compiler flag -altcomparable will give you the proposed behavior. Thanks.

@griesemer thanks for the reply. I realize that I misread the examples and made a mistake. As you correctly state, the struct example works. SO that's one less issue.
Regarding comparable however, if we distinguish between interface implementation and constraint satisfaction, do we really still need to have two notions of comparability?
We should be able to keep compile-time safety (strict comparability) since it uses interface implementation and interface types would still satisfy the comparable constraint. Just not implement.
Basically instantiation requires constraint satisfaction. Assignability requires interface implemenation (which forces strict comparibility) ?
Interface implementation being constraint satisfaction of the memebers of the type set of a type instead of constraint satisfaction of the type itself.

We still need to be able to talk about the different kinds of comparability. What you are suggesting is that comparable types be the new "comparable" types. And then we have some other types (such as interfaces) for which == is defined.
I suppose we could talk about "types that support ==" instead of types that are comparable in the spec. That change would not be difficult. But it would require that we teach that "comparable types" now means types in the type set of comparable. Not to mention all the related documentation, books, API entry point names, etc. that would be affected but often cannot be changed.
It seems to me that might be even more confusing. In the spec and documentation it might be clearer to talk about "strictly comparable" types instead and leave established terminology alone.
We made a similar terminology change in the past: we used to refer to types declared in a type declaration as "named types". When we introduced alias declarations, the notion of a "named type" didn't make 100% sense anymore, because an alias declaration (e.g. type S = struct{}) introduces a name (such as S) for a type yet the type denoted by that name (struct{}) may not be a "named type". So "defined types" became the term for types formerly called "named types". We're still not fully recovered from that terminology change. With Go 1.18, we re-introduced the notion of a "named type" which is getting us mostly back to where we were. The lesson learned here is that we should not make changes to established terminology if there's other ways around it.

Almost but not quite the change I had in mind. Perhaps I'm thinking wrongly though.
I would define comparable as comparable i.e. the constraint would determine the set of types that have the comparison operators.
Quoting the current spec on Comparison operators, The equality operators == and != apply to operands that are comparable.
So nothing would change here?
Interface types could be said to be comparable since they can be compared.(just means that interface types satisfy the comparable interface.)
The difference would simply be that not every comparable type would implement comparable.
Which has to be understood in terms of interface.
Interface implementation is basically: can every type that fits into one interface also fit into another interface?
It's a comparison of constraining power and as such, it becomes obvious that any does not implement comparable for instance.
With non-basic interfaces we have the opposite, interface{string | int} implements itself as it denotes the same constraining power but the interface type does not satisfy the constraint it denotes.
I think these are nuances that we might want to make clearer. constraint satisfaction is really different from interface implementation.
That might even allow to future proof a potential FutureGo if all constraint interfaces are to be used as types.

I think the proposal establishes that interface implementation and constraint satisfaction should be different. We can consider this part of the discussion as settled.
You are saying we should turn things 180 degrees around: let comparable be the set of all spec-comparable types, and then make sure that not every comparable type implements comparable.
I don't know how that can work. You state yourself, that "Interface implementation is basically: can every type that fits into one interface also fit into another interface?". That is set inclusion: An interface A implements an interface B if every type in A is also in B. Thus every type in comparable implements comparable.
Similarly, you say that any does not implement comparable - it would only satisfy comparable. Yet any is clearly comparable (== is defined) and therefore any is in the set of all comparable types. So it must implement comparable.
The only potential way I see how this could work is by changing the definition of interface implementation - it could not be based on set inclusion anymore, or the notion of type sets for interfaces would need to be adjusted. If it's possible I'd love to see that. Without a precise definition of the "nuance" you're alluding to it's difficult to assess your idea. There's not enough here to make progress.

I think the proposal establishes that interface implementation and constraint satisfaction should be different. We can consider this part of the discussion as settled.
Yes!

You are saying we should turn things 180 degrees around: let comparable be the set of all spec-comparable types, and then make sure that not every comparable type implements comparable.

Yes, I think that many interfaces are comparable themselves as a type but the types that implement these interfaces are not necessarily comparable themselves. In terms of type set inclusion i.e. interface implementation, we can just take the example of any.

I don't know how that can work. You state yourself, that "Interface implementation is basically: can every type that fits into one interface also fit into another interface?". That is set inclusion: An interface A implements an interface B if every type in A is also in B. Thus every type in comparable implements comparable.

Set inclusion  would be set membership of every type in A. That is constraint satisfaction.
Every type in comparable satisfies comparable rather.

Similarly, you say that any does not implement comparable - it would only satisfy comparable. Yet any is clearly comparable (== is defined) and therefore any is in the set of all comparable types.

Type set membership of a type would be constraint satisfaction.

Let me spell this out: A type T satisfies a constraint C if the type T is a member of the type set of C.

Set inclusion of the type set of a given type would be interface implementation.

An interface T implements an interface C if the type set of T is a subset (set inclusion) of the type set of C.
Is that what you are saying? If so, that would require that interfaces (e.g. any) be part of type sets (so that any can satisfy the constraint comparable). https://github.com/golang/go/issues/52509#issuecomment-1118972932 comes to mind but this sounds a bit different.
Is comparable (the type) in the type set of comparable? I think it would have to be because a comparable type should satisfy comparable:
func f[P comparable]() {
   f[P] // this should be legal
}

I need to think about this some more, but I am going to disengage from this specific conversation for now because it doesn't directly discuss the pros and cons of the proposal at hand (which suggests a very small localized change). It sounds like you are proposing a different idea altogether, which changes how type sets are computed, and that should be discussed elsewhere. Feel free to open a new proposal explaining in detail how your idea would work. Thanks.

Yes, you got it right, interface types could/would now belong to type sets (as mentioned in #52509)
The advantage would be only one notion of comparability, comparable would be somewhat less magic an interface, and for a potential FutureGo, only one kind of type sets would need to be considered.
Would probably explain why constraint interfaces can in theory be used as regular interfaces as well.
No problem I will amend #53734 to try and specify things more accurately.
Thanks.

Just one last comment: I'm not sure things would be less magic. Right now, an interface is never in a type set. Type sets exactly represent the very real concrete types that can be stored in an interface variable, the types in a type set correspond to the possible dynamic types at run-time. If interfaces become parts of type sets, type sets become an essentially mathematical construct with no direct correspondence to run-time types. Just something to keep in mind. Thanks.

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

I have updated #53734 for a different take on this issue.

Thank you for the detailed proposal. It seems very reasonable to have separate meanings for "implement" and "satisfy" a type constraint, given that we want any to satisfy the comparable constraint.
I have a question: it is not very clear to me when type-parameter type satisfies a constraint.
https://go.dev/play/p/RJQcw75YVnf
type mymap[T comparable] map[T]struct{}

func f[T comparable]() {
	_ = mymap[T]{}
}

For example, the above program successfully compiles in Go1.19, so this should successfully compile in this proposal.
How this should be explained in the new spec? Why does the type parameter type T satisfies comparable in the above code?
According to the description of the proposal,

A type T satisfies a constraint interface C if

T implements C; or
C can be written in the form interface{ comparable; E }, where E is a basic interface and T is comparable and implements E.

In Go1.18, we could assume that (after instantiation) the argument T implements C.
But I think that we can no longer assume that in this proposal.
So I'm wondering "When a type-parameter type T satisfies type constraint C?"
My guess is something like follows. Excuse me if this question is too detailed to discuss now.

type parameter T satisfies constraint C if and only if all types that satisfy T's constraint also satisfy C.

@nobishino The second bullet point:

C can be written in the form interface{ comparable; E }, where E is a basic interface and T is comparable and implements E.

In your example, C can be written as interface{ comparable; E } and T is comparable and implements any.

@Merovius
(My sample program reposted below for convenience)
type mymap[T comparable] map[T]struct{}

func f[T comparable]() {
	_ = mymap[T]{}
}

In your example, C can be written as interface{ comparable; any } and T is comparable and implements any.

Thank you for the explanation, but still, I don't understand why T is comparable.

and T is comparable

I think this "comparable" means spec-comparable because we are trying to define the condition under which the type parameter T satisfies the comparable constraint.
But I couldn't find a definition of spec-comparability for type parameter type in the current spec or this proposal.

Can someone please confirm that the current rules would let this code compile in FutureGo?

package main

type numstr interface {
	string| int
}

func Add[T numstr](a,b T) T{
	return a + b
}

func main() {
	var operA numstr = 42
	var operB numstr = "some string"

	Add(operA,operB)
}

I think it shouldn't compile. I strongly believe that except for basic interfaces (by construction), constraint implementation is not  constraint satsifaction.
Am I misunderstanding something?

@atdiar No, I don't think that this proposal changes anything about that example. It will continue to not compile, as today.

@atdiar FutureGo does not exist. I agree that your example should not compile, so if we ever do allow numstr to be used as a variable, we should take that into account. Note that, the most intuitive way to do that would be to say that numstr is neither int, nor string, thus it is not in the type set of itself and thus it does not satisfy the constraint in your example.

@Merovius thank you and agreed. I was merely trying to explain that the current rules would have to be changed again if we ever consider lifting the current restrictions on constraint interfaces. So they are not completely future-proof wrt FutureGo.

@nobishino See also the section on "Related spec issues" in the initial proposal post: the spec is missing a direct explanation of spec-comparability for type parameters (and perhaps of strict comparability as well, or at least a clearer explanation).
With respect to your question: We need the difference between "implements" and "satisfies" for technical reasons - to make the precise rules work out. But for all practical purposes, you can essentially just keep using the "implements" relationship as always.

@griesemer

@nobishino See also the section on "Related spec issues" in the initial proposal post: the spec is missing a direct explanation of spec-comparability for type parameters (and perhaps of strict comparability as well, or at least a clearer explanation).

Sorry, I overlooked the section  "Related spec issues". And I think that section answers to my question. Thank you.

With respect to your question: We need the difference between "implements" and "satisfies" for technical reasons - to make the precise rules work out. But for all practical purposes, you can essentially just keep using the "implements" relationship as always.

👍

@Merovius

T is not an interface type and T supports the operations == and !=; or
T is an interface type and each type in T's type set implements comparable.

This does imply that, in your example, T's type is (spec) comparable.

I want to clarify your point: do you think type parameter type T, which implements(because we are talking about the current spec), falls into the first case?

T is not an interface type and T supports the operations == and !=;

By the way, I think griesemer's answer basically resolves my original concern.

The main effect of this will be that if I have a custom Map[K comparable, V any], I will be able to use Map[any, V] now, while I couldn't before. This seems reasonable, and the discussion above is in favor.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

Sorry if this is covered in the thread already.
We have the following code is Kubernetes to make sure that tlsCacheKey can be used as a map key and comparisons will never result in a runtime panic.  Do this proposal change that?

@enj AIUI, yes, that would change. If tlsCacheKey would get an interface field, that interface field could have a non-comparable dynamic value, but would still implement comparable. I'd say that in the future, an assertion like that would have to be done using explicit tooling in CI.

@enj AIUI, yes, that would change. If tlsCacheKey would get an interface field, that interface field could have a non-comparable dynamic value, but would still implement comparable. I'd say that in the future, an assertion like that would have to be done using explicit tooling in CI.

😞 being able to make such an assertion at compile time is a valuable aspect of comparable.  We have had folks try to make changes to that struct to include interfaces without realizing that such a change may fail at runtime...

FWIW I think that's understood, pretty much. We're between a rock and a hard place - disallowing using interface with comparable disallows a bunch of important use cases, but allowing it means comparable no longer statically guarantees that comparisons don't panic.
I do think it shouldn't be too hard to write an analyzer for this.

You can still do this compile-time check by using a type parameter constrained by the type T that you expect to be comparable. For instance:
// we want to ensure that T is strictly comparable
type T struct {
	x int
}

// define a helper function with a type parameter P constrained by T
// and use that type parameter with isComparable
func TisComparable[P T]() {
	_ = isComparable[P]
}

func isComparable[_ comparable]() {}

@griesemer Clever.

@griesemer Nice. The error message it produces when T isn't comparable isn't ideal though.
./prog.go:13:19: P does not implement comparable

It only mentions the parameter name P, not the actual type T. That's probably sufficient in most cases, but for the purpose of this sort of check it would be really nice if it mentioned T somewhere.

I think we can work on the error message (there's a lot of generic-related error messages that could be better). In this case we could say something like

P does not implement comparable (element T is not comparable)

or similar.
The point is that we don't lose the ability to implement the desired compile-time check.

@griesemer with respect to this remark in "Related spec issues" in your original post:

The definition of comparable operands in the spec is missing a dedicated rule for operands of type parameter type.

Do you already have a specific wording in mind?

It's probably going to be something like:

Type parameters are comparable if each type in the type parameter's type set implements comparable.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Is there an open issue which propose to use comparable as value types?

@go101 see #51338

@go101 I don't know of one.  Personally I think that permitting variables of type comparable is similar to permitting variables of all non-basic interface types.  I don't see a reason to do just comparable.

I don't see a reason to do just comparable.

Can we just say comparable is actually a basic interface type? I thought this is what #51338 proposes.

This is now implemented and documented. Closing.


Restore JSF changelog

What does this PR do?
Restores the JSF changelog for #2254
Checklist

[x] This is something else

[x] I have updated CHANGELOG.asciidoc

Fixed in d1274e726b271c8bdadde0c6130e83e9cde09f01


Mobile bugs

Couple of CSS bugs for mobile.

[ ] Home page board date action button
[ ] Event modal: date inputs
[ ] Event modal: phone number input keyboard input
[ ] Account settings page: spread out sections
[ ] Labels page: drop-down menu off screen
[ ] Center all modals

Home page board action buttons. Date input looks shitty.

Event modal.
Date inputs look bad.
Phone number input keyboard should be only digits.

Account settings page needs to spread out sections more.

Labels page drop down is off screen.

Center the modals on the page


toolbox modification for issue #871

1.adjusted the css of the toolbox such that it fits the canvas perfectly.
2. toolbox sized perfectly not to look too clumsy rather a classic ones that we normally find in other sites.

toolbox modified to fit the canvas length

General Feedback:

Please refer to the respective issue like closes #issue_number in the PR description.
Always try to attach a snapshot/clip of your change


FIPS support for Ubuntu Linux VMs

Some activities working from a FIPS-based architecture. Crypto libraries or commands, some security hardware, require access only from a FIPS-enabled host. Useful for regulatory compliance where needed.
Would like to enable FIPS support for Ubuntu Pro subscriptions: https://ubuntu.com/security/certifications/docs/fips-enablement
Or create an option to install a FIPS enabled/preconfigured images (The same would be useful for containers, but my personal focus does not involve containers at this time).
The only alternatives are to use leading industry software, Parallels, etc. Even UTM and QEMU don't quite fit the bill at this time.
(at least not for x86 running in arm/Apple Silicon)

What's stopping you from using the Ubuntu solution for userspace components? Also, for the kernel, do you need certification or is any FIPS compliance enough?

When I'd posted this originally, I wasn't able to install the FIPS packages or attach the ubuntu pro subscription. I've since attempted to attach differently and now I can enable the FIPS userland packages.
A FIPS compliant kernel is sufficient, FIPS Certification is not necessary since the system itself will not be used within the environment in question, just during development lifecycles.


Data Exploration

Explore the data, perform basic EDA, search for the target features.

Willing to work on this issue

Issue assigned to @Github3733.


Update and rename ThirdPartyNotices to ThirdPartyNotices.md

This file is in Markdown format.

Nice to see more automatic workflows in this repo!


User auth

Integrate auth0 user auth in eotdl
❌ api
❌ cli
❌ ui

Auth0 integrated in main ui, API and CLI.
Needs some testing, but it's already working.


Use stdout and local time for logging

Structlog defaults to writing logs to stdout and writing timestamps in local time. IMHO initialise_logging() should not change these defaults.
It is very confusing when apps like orchestrator switch logging formats midway during initialisation.
import structlog
from nwastdlib.logging import initialise_logging

logger = structlog.get_logger(__name__)
logger.info("Goes to stdout with timestamp in local time")
initialise_logging()
logger.info("Goes to stderr with timestamp in UTC")

Ill create a new release next week


🐞 vw vh min-vw min-vh max-vw max-vh aren't highlighted

What happened?

Version
2.0.0-beta.102
Relevant log output
No response
What browsers are you seeing the problem on?
No response

fixed


Address bar lacks contrast with built-in themes

Firefox's built-in light theme

Firefox's built-in dark theme

Firefox's built-in default theme - looks better, but I'm not sure if it is fully accurate.

Hover and selected states look fine in all except dark theme. Probably related to #9.
Tested on commit b0aa0cd, Firefox 63.0b11, macOS 10.14 (Mojave, light theme).

I'm unable to reproduce the behaviour you see with the default theme. This is meant to replace the light theme; was the only way to do it and retain lightweight theme support. You should be seeing a light grey tab bar, not a black one.
The problem with the built-in light and dark themes is their colours just don't suit it very well when the address bar doesn't have a border. Because lightweight themes are essentially interchangeable between Firefox and Chrome now, I tried to stay with Chrome's behaviour.

This is what it should look like, tested on a new profile with freshly cloned repo (macOS Mojave Light theme, b0aa0cda58a8553f854c06c564ad576871d10871 with Firefox's default theme). Would you mind testing on a new profile? Can do it through about:profiles.

Firefox Beta (63.0b11) looks exactly the same for me.

Ok I can verify that this occurs when you have "Show scroll bars: Always" set in Preferences. I use -moz-overlay-scrollbars to check for macOS as per this article. It seems it isn't as robust as they think. I'll look for an alternative.

I had it set on automatic FWIW, but changing it to "when scrolling" did not fix the issue for me.

I'm guessing you don't have a touchpad? Try the latest commit. Haven't tested to make sure Windows isn't affected yet.

I do, but I'm not using it.
I forgot to say that it did not fix the issue for me on light and dark themes (since light theme is suggested on readme), the default theme works as intended when I change the scrollbar preference.
Same goes for 98f9acd - only works as intended on default theme, when hiding scrollbars by default.

Sorry, it's on mac-selector branch, forgot to mention!

Damn, that selector also works for Windows... I'll keep looking.

Instructions have been updated to reflect that built in light and dark themes may clash with address bar. You can use MaterialFox Helper to force Chrome's dark or light theme. Not mentioned in readme because it is still experimental.

I'll need to set up a VM to test this but ideally, it sounds like Linux should act more like Windows. If I can find a CSS selector which targets Linux I might be able to fix the behaviour.

Today I had a chance to try this theme on Windows 7, and I saw that the toolbar was always black, even when trying some configurations with Helper (which successfully changed the titlebar though). Might've been related to the fact that the browser was in permanent no-history mode, but it seemed like Helper should've given an option nevertheless (as it detected private mode, but had an option for light theme).

On another note, I can confirm that the mac-selector works on Mojave with or without scrollbars enabled.

Set up a Ubuntu VM to test and fixed a few issues I noticed.
Still need to set up a Windows 7 VM to test, but one of my Ubuntu fixes may have resolved the tab bar issue in Windows 7 (I'm being a bit optimistic).

Tested on Manjaro (GNOME DE, like Ubuntu) and it looks very close, only big difference I see is that the tab titles are larger on Chromium, but I don't think that's worth changing :grin:

Thanks for testing. Yeah, I noticed that too but couldn't be bothered fixing. I might revisit it later.

Fixed the issues on Windows 7 and added the tab and toolbarbutton colours from Chrome on Windows 7 so it should look almost identical to Chrome now.
If you're able to test on Windows 7 and confirm that it looks right, I'll close the issue.

In Windows 7, Light theme, inactive tabs and the text are both black.

Resolved searchbar issues in 50723ab6d5632941dd5b605d31dc808de7102954.
I'm looking into the Windows 7 issue.


Local LogFlare docs?

Improve documentation
Link
Add a link to the page which needs improvement (if relevant)

Describe the problem
LogFlare tab was added to the local development environment (awesome!) but there is no documentation. Currently the tab doesn't work, it just fails to show any logs with LOGFLARE_API_KEY env variables are not set
Describe the improvement
Local LogFlare usage should be documented
Additional context

We have added logflare setup docs to our local development guide: https://supabase.com/docs/guides/getting-started/local-development#enabling-local-logging


dos2unix: Update to 7.3.3

dos2unix: Update to 7.3.3

You should add yourself as maintainer for this next time.

Thanks!

OK, I will. You're welcome.


Include a Calendly link in the Profile Section

I wish to include a  Calendly link present in the Profile Section to book meetings directly via the portfolio.

Hey @RashikaKarki , can you please assign this to @Ritesh055 and me? Thanks.


Updated links that were pointing to 404 page

Updated links that were pointing to 404 page

@ajayullal thanks for your PR. However, these links are intended to be this way as they will be published to the wiki on release.
I've create a PR that adds a warning to all files in /docs/documentation #4163


Fix typos

I just read the docs to learn more about LSP. Spot a few typos.
Thanks for well written documents.

@microsoft-github-policy-service agree


any plans to merge upstream

Curious why you haven't sent a pull request to @alebedev. I really like the changes you've made but it irks me to have 2 repositories for the same application.

I think mainly because we're quite far behind his master branch now.. also, we keep finding bugs :)

I just spent WAY too much time working on a full merge:
Merge of albedev and vitei branches.
It seems to work on SCP transport. In testing I also discovered several other things in the vitei fork that didn't seem to work: git merge clear for instance.
As I said, I've spent way too much time on it already and need to get back to "real" work. If someone wants to pick up where I left off, please do. The other transports should be tested; I suspect the change to enable subdirectories in the local cache was never tested on the SCP transport, for instance. It doesn't look like it should have ever worked. So it probably won't work on the WebDAV transport that I pulled from the @alebedev branch.
At the moment, given the state of all of the major big-media plug-ins for git, I'm going to give up and leave my big files in git. At least in the case of the SCP transport, git-media is pathetically slow at doing a git media sync for any nontrivial number of files. Heck, it's pathetically slow for one file; it needs some form of caching so that it can know what versions have been pushed without pinging the server for every file on every sync. And it looks like the other transports use the same approach. :(
I'm sure there are other transports that work better than SCP, but even the existence of one that worked so poorly gives me a bad taste for git-media -- and it seems like none could be fast if you have, say, 200 media files in a repo. Too much overhead for every query.
By the way, what IS a "hashstash"? I can't find a server anywhere that is called hashstash; when I Google it I mostly get "marijuana storage solutions". :(

Wow, thanks for this!  I've been meaning to do a similar job for a while, but as you've just discovered it can get pretty hairy!  I'll answer some of your questions here:
Firstly, yeah, there's a lot of stuff that probably "doesn't quite work" in the vitei branch.  A lot of our commits are "quick fixes" for specific issues we were having, and geared toward the hash stash which is what we use, so may have caused issues for other transports -- the subdirectory thing is a perfect example.
Re. the hash stash -- that's actually one of the reasons I hadn't got around to cleaning up our git-media fork ready for merging yet.  We also noticed the SCP transport was slow -- especially on Windows -- so we knocked together our own little server which allows you to store and retrieve files based on their hash.  The first version we knocked together is mentioned on our blog, but that's not the version we're currently using and isn't exactly easy for other people to get up and running with!  One of the things I've had on a backlog for ages is to clean that up and make a gem for it, so that we could submit it as a first-class citizen to git-media, but I just haven't got around to that yet.

Heck, it's pathetically slow for one file; it needs some form of caching so that it can know what versions have been pushed without pinging the server for every file on every sync.

I suspect this is an issue we don't suffer from as much as we almost never run git media sync.  I can't remember the details, but I think we check as part of our clean filter (when adding files etc) whether the file exists in our local cache.  If it does we do nothing; otherwise we copy the file to the local cache and push it up to the hash stash at the same time, so it's very rare to find that the file already existed on the hash stash.  Obviously this makes working offline basically impossible.
Anyway, thanks for putting the effort into this merge.  It's a great first step -- if we can polish up the hash stash and tidy up some of our fixes so that they make sense on all available transports we might have something worth submitting upstream.


Added czech translation

Q
A

Is bugfix?
no

New feature?
yes

Breaks BC?
no

Fixed issues

Thanks!


HTTPS is forced

Hi
It's mentioned in docs that using non-HTTP protocols(And abnormal TLS implementations?) is possible, But port 80 just redirects (301) to 443.
It's really appreciated if you would disable the forced HTTPS.
Thank you very much.

@nimagp TLS is required between the client and srv.us, and cannot be used between srv.us and the server.
There are no plans to support non-TLS between the client and srv.us as we use SNI for routing. What would be the use case where TLS is not desirable?

Thanks.
Mainly TLS implementations like uTLS and xTLS which are harder to detect and block in systems like GFW
But a test showed that there is little difference in performance


Swift 3: Cannot convert return expression of type 'Int32?' to return type 'Int?'

We are upgrading to SwiftyJSON Swift 3 with CocoaPods config pod 'SwiftyJSON', '3.1.0'.
We are getting this error:

/Users/xxx/Documents/iOS/xxx/Pods/SwiftyJSON/Source/SwiftyJSON.swift:866:33:
Cannot convert return expression of type 'Int32?' to return type
'Int?'

Error is on the return statement in SwiftyJSON.swift:
public var int: Int? {
    get {
        return self.number?.int32Value
    }
    set {
        if let newValue = newValue {
            self.object = NSNumber(value: newValue)
        } else {
            self.object = NSNull()
        }
    }
}

Anyone know what the issue is?  Is this an issue with our CocoaPods config or with SwiftyJSON?

Are you on Xcode8?

I am.  Realized that the supported version is 3.0.0 not 3.1.0.   Used that version and I was good.
https://github.com/SwiftyJSON/SwiftyJSON/issues/647

3.1.0 should also work, I'll look into it.

same thing for me but with both version on 3.0.0 and 3.1.0 in both i get "Cannot convert return expression of type 'Int32?' to return type 'Int?'"
xcode 8A218a

I'm having the same problem with SwiftyJSON 3.1.0 and Xcode 8A218a.

I am having same issue

I changed the int32Value to intValue. And the build succeeded

I am having same issue

I'm having the same issue with SwiftyJSON 3.0.0. Any solution to this?

I have same issue.
Xcode8.1, Swift3.0.1, SwiftyJSON3.1.1

same issue.. changed to intValue


Release 2.2.0

Version 2.2.0 🎉
Additions ➕

Payment Intents are now supported through the payment_intents manager located on the Fintoc class 🎉

Codecov Report

Merging #41 (c6db2e9) into stable (9bb1408) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            stable       #41   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           39        41    +2
  Lines          399       409   +10
=========================================
+ Hits           399       409   +10

Impacted Files
Coverage Δ

fintoc/core.py
100.00% <100.00%> (ø)

fintoc/managers/__init__.py
100.00% <100.00%> (ø)

fintoc/managers/payment_intents_manager.py
100.00% <100.00%> (ø)

fintoc/resources/__init__.py
100.00% <100.00%> (ø)

fintoc/resources/payment_intent.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Enable AWS Lambda for chunk reads

For data selection cases where 100's of chunks need to be quieted, it will likely be more efficient to invoke a lamda function for each chunk rather than dispatching to the DN nodes.  AWS supports up to 1000-way parallelism for Lambda, which will provide better scaling than most server configurations.

Implemented here: https://github.com/HDFGroup/hsds/commit/3a901f2501dc40f32e5fbc0335a8e6d1e61ddd83


Descriptive log error message should be shown upon React Native null module error

Currently, the log message looks like this:
2017-02-07 17:33:58.109 [error][tid:com.facebook.react.JavaScript] Native module cannot be null.
It needs to say which native module is null. Right now, I have 10+ native modules in my project, and so my only recourse for debugging is linear search through them all O(n) human cost, which could be O(1) for me if the log message specified which module is null.

We're cutting down on the number of outstanding issues, in order to allow us to focus. I'm closing this issue because it has been open for over 60 days with no activity. If you think it should still be opened let us know why. PRs are always welcome.


panicked when some etcd server node shutdown

panicked logs
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Status { code: Unknown, message: "transport error: error trying to connect: tcp connect error: Connection refused (os error 111)" }', .../etcd-rs-0.5.0/src/lease/mod.rs:109:70

code in crate
res = client.lease_keep_alive(request).fuse() => res.unwrap().into_inner()

refer #50

fixed.


openxr-loader: init at 1.0.1

Motivation for this change
Infrastructure to allow OpenXR applications to find a runtime like Monado or a future version of SteamVR, and headers to allow C/C++ OpenXR applications to be built.
I'm not sure if a custom output for the layers is idiomatic. These are mainly useful when testing OpenXR applications during development, and are not of interest to typical users or builds.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build openxr-loader

@GrahamcOfBorg build openxr-loader

Thanks!


[GALL-3017] - view Works on Statement page should include works count

This is the counter part of the ticket. We still need to refactor to use the first 4 artworks and put them into greed.
But the counter was listed as higher priority for tomorrow's Community pages.
Generates this button:

Updated here @dblandin to use the connection to get totalCount and use it to display for View works button.


Continue with some permissions when some permission allowed.

How to handle response when some permission is allowed we need to continue with that permission.

There new version 1.4
compile 'com.master.android:permissionhelper:1.3'

Added onIndividualPermissionGranted() when some permissions are granted.


Filter genuine email

Is your feature request related to a problem? Please describe.
In your application anyone can enter using temporary or disposable email.
I will add a feature so that no one could create an account using temporary or disposable email.
It will allow only genuine users in your database.
It will help to avoid any bot.
Describe the solution you'd like
I'll implement some script that will help to detect such emails.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Assign me this work under GSSoC24, I will implement it.

Thanks for letting know issue #517  is also the same
Raise PR as soon as possible !


change constexpr-or-const to just const in tools

fixes compiler warnings

What compiler warnings does this fix?

In something I merged yesterday, this fixes a C++11 warning about deprecated behavior of assigning a literal string to a "char *" as opposed to a "const char *".

Make them constexpr const ;-)

Is there a macro for this?  I know of BOOST_CONSTEXPR_OR_CONST for C++03 compatibility.

How about BOOST_CONSTEXPR const ?


[firebase_messaging] Init firebase at runtime / without google-services.json

Description
Currently the plugin needs the google-services.json file to be initialized, or at least no other approach is documented. This is a problem if the file cannot be present when the app is build, i.e. all the information is (optionally) added when the app is already running. Additionally this means that the app can only receive messages from one firebase project. A possible workaround right now might be to create the file at runtime, but that approach  is tedious.
Describe the solution you'd like
In android it is possible to initialize firebase at runtime by using FirebaseOptions.Builder with something like this:
FirebaseOptions.Builder builder = new FirebaseOptions.Builder()
                    .setApplicationId(...)
                    .setApiKey(...)
                    .setDatabaseUrl(...)
                    .setStorageBucket(...)
                    .setProjectId(...)
                    .setGcmSenderId(...);
            FirebaseApp.initializeApp(this, builder.build());

Additional context
This might be related to this.

An alternative might be to support the passing a FirebaseApp to initialize FirebaseMessaging.  I tried a while back to remove the need for the google-services.json and it looked to be pretty deeply embedded into the tools chain and code.
What we're doing is including our Production defaults with the apps, but overriding them at runtime for the FirebaseDatabase for test environments.  Unfortunately... that doesn't work for FCM.


Refactor and update ubiquity inventory component

Oh, I just realized, remember that for the Token component we need to be able to specify the number of decimals, since USDC has 6 decimals instead of the usual 18! I just made a quick fix with that change, so don't worry!
@pavlovcik this is quite ready for merging! The inventory components got quite a cleaning!

@pavlovcik any reason not to merge this?

Haven't gotten around to reviewing yet


429 Too Many Requests Error

Requesting a certain amount of 'loadpagechunk' will result in '429 Too Many Requests Error'.
It didn't happen before, but this error has occurred since recently.

I found an API that can replace 'loadPageChunk'.
def getPageMap(blockId): #blockId => 12345678-1234-1234-1234-123456789012
    param = {
        "requests":[
            {
                "table":"block",
                "id":blockId,
                "version": -1
            }
        ]
    }
    res = client.post("syncRecordValues",param).json()

    return res["recordMap"]["block"][blockId]["value"] # == client.get_block().get()

'syncRecordValues' also has a 429 Error, but is less restrictive than 'loadPageChunk'.

I'm currently experiencing the exact same issue. Any idea how to fix this? :)

I'm also getting this error when trying to init a client using my email and password.
requests.exceptions.HTTPError: 429 Client Error: Too Many Requests for url: https://www.notion.so/api/v3/loginWithEmail

I'm getting this error when importing the records from md files to notion.

I am getting this err too
requests.exceptions.HTTPError: 429 Client Error: Too Many Requests for url: https://www.notion.so/api/v3/loadUserContent

I solved it by putting a time.sleep(5). It doesn't work perfectly, but
enough to make use of the algorithm.
Le mar. 10 janv. 2023 à 21:34, Eikosa @.***> a écrit :

I am getting this err too
requests.exceptions.HTTPError: 429 Client Error: Too Many Requests for
url: https://www.notion.so/api/v3/loadUserContent
—
Reply to this email directly, view it on GitHub
https://github.com/jamalex/notion-py/issues/296#issuecomment-1377813772,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKOQG63D2EWNCFF4HXFFKOTWRXBUBANCNFSM4YYX3PQA
.
You are receiving this because you commented.Message ID:
@.***>

Is there some place where api/v3 is described?
Actually, this one /api/v3/loginWithEmail
Because i'm getting 403


[Question]  module is only allowed to import functions

I encountered an error when trying to create a component with the following command.
 wasm-tools component new target/wasm32-wasi-preview1-threads/release/test.wasm -o component.wasm --adapt ./wasi_snapshot_preview1.wasm

I think it's because it includes memory as shown below, but why does this constraint exist? Will it be improved in the future?
  (import "env" "memory" (memory (;0;) 17 17 shared))

error

error: failed to encode a component from module

Caused by:
    0: module is only allowed to import functions
(base)

@alexcrichton Thank you for your quick response. I thought that by using rayon, building with wasm32-wasi-threads, and then implementing and importing thread_spawn on the host side, I could use components that internally use rayon. However, I understand now that such a use case is not considered for components.
Is there any plan to extend or discuss this aspect in the future?


Update resources.py

reclass is not considering the parameters passed in reclass-config.yml file
Fixes issue #
Proposed Changes

I have signed the CLA


fix: use MP money fields for My Bids floor selling price and online asking price (PURCHASE-2171)

The type of this PR is: Bugfix

This PR resolves PURCHASE-2171 and depends on https://github.com/artsy/metaphysics/pull/2805.
Description
Following https://github.com/artsy/metaphysics/pull/2805, this migrates floorSellingPrice and onlineAskingPrice to Metaphysics Money type (instead of the deprecated Causality money type).
Migration steps:

[x] (artsy/causality#848) Add the new raw cents fields (e.g. floorSellingPriceCents) and deprecate the Causality Money type fields (e.g. floorSellingPrice).
[x] (https://github.com/artsy/ohm/pull/707) Migrate Ohm to use the new cents fields.
[x] (https://github.com/artsy/causality/pull/852) Remove the Causality Money type fields (e.g. floorSellingPrice).
[x] (https://github.com/artsy/metaphysics/pull/2805) Update MP to stitch in MP Money type fields.
[x] (This PR) Update Eigen to use the new fields.

PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have added tests for my changes, or my changes don't require testing, or I have included a link to a separate Jira ticket covering the tests.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a CHANGELOG.yml entry or my changes do not require one.

Looks good!

Merging and giving it a try. Thanks for the review!


Stability settings

I am working on a project. Stability requirements are high, and latency is not important. In this case, can we make some settings?

Yes, you can modify this library as you want.


Renamed add_children to add_child since it adds only one child

Related to #6771

bot merge

bot merge

yeah...


Documentation for LXSSManager / LxBus / /dev/lxssclient?

Can we have some?
(My use case: I currently have a project that manages processes running in a WSL session by, essentially, running bash.exe as a subprocess and puppeteering it via stdin/stdout.
If I could instead have it run its own WSL-side process and communicate with it over LxBus, this would get a lot cleaner and easier to make reliable.)

@cerebrate If you watched the video, Benhillis said they're going to do that probably as the next blogpost.


Bump werkzeug upper bound dependency constraint to include version 1.0

This PR aim to upgrade the werkzeug upper bound dependency to fix the following issue https://github.com/fishtown-analytics/dbt/issues/3010.
Description
As suggested https://github.com/fishtown-analytics/dbt/issues/3010#issuecomment-759468509 I just change the upper bound of the constraint.
Checklist

[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[x] I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.

Here we go @jtcohen6, I think I did what you asked. I did not added a release date for the 0.19.0 because I did not find one.
I'm sorry for the commit without the identity in between I change my computer setup since last time.

Here we go @jtcohen6, I think I did what you asked. I did not added a release date for the 0.19.0 because I did not find one.
I'm sorry for the commit without the identity in between I change my computer setup since last time.


3.0.5 breaks vue-class-component

Version
3.0.5
Node and OS info
8.12.0, yarn 1.10.1 monorepo, OS X
Steps to reproduce
Update vue-cli and utils to 3.0.5, compile existing app using vue-class-component decorators, serve.
What is expected?
An existing app should continue to function on a minor version bump.
What is actually happening?
After updating vue-cli to 3.0.5, components using vue-class-component compile correctly, however are broken at runtime, presumably due to a change in babel. No decorated functions or variables are available.

Is it related to this issue: https://github.com/vuejs/vue-class-component/issues/283 ?

Closing due to inactivity for more than 1 week. Please open a new issue with a reference to this one if you can follow up with more information.


[Enhancement/Question] Auto pin citation keys

Again, thanks for the great work! I would love to see an option in the BBT preferences to automatically pin the generated citation keys on import (or export).
I saw that this was dropped in Zotero-5, probably for a good reason (https://github.com/retorquere/zotero-better-bibtex/issues/875). So please just close the request, if this is not possible...

On import is already possible: https://retorque.re/zotero-better-bibtex/installation/preferences/hidden-preferences/#autopin

thx - activated :)


[BUG] Documentation missing details on parameter Get-PnPWeb

Reporting an Issue or Missing Feature
Page https://pnp.github.io/powershell/cmdlets/Get-PnPWeb.html is missing details on the "Includes" parameter
Expected behavior
Each parameter is fully documented and examples provided.
Actual behavior
Missing Information
Steps to reproduce behavior
n/a
What is the version of the Cmdlet module you are running?
n/a
Which operating system/environment are you running PnP PowerShell on?

[X] Windows
[ ] Linux
[ ] MacOS
[ ] Azure Cloud Shell
[ ] Azure Functions
[ ] Other : please specify

Thanks for reporting @danmyhre , have updated docs


pull request for e2e test at 01/27/2017 02:45:11

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Refactor battlers to make it easier to edit and extend them

Makes use of scene inheritence like it used to, making it a bit easier to actually see how parts plug into the results.  Battlers and their stats resources are still duplicated so that it's easier to reset combat.
Combat Actions have been altered so they are self aware of if they can be used, which simplifies the API a bit.
Moved some calculations out of the Battlers and into the Combat Actions where suitable to help encapsulate the logic.
Fixed a bug with life bars where if your max hp is higher than 100, the bar wouldn't be properly filled all the way.
You can now unlock skills on level up
Levels are defined as an experience growth lookup table
Party Members now have a battler attached to them

The biggest drawback to using the node inheritance approach instead of abstracting with purely resources and a template container is that it's not immediately apparent which sections should be overridden without seeing another instance for example.
One of the most visible advantages is now you are able to properly visualize battlers when arranging formations.  Code has also been cleaned up/simplified a bit.

Yup it's looking good to me!

Great, even 😄


Fix ts gen error

Add a serializer for PingView to suppress the error message produced by create-axios-schema.sh.

Codecov Report

Merging #12 (77360bd) into main (a78f010) will increase coverage by 0.02%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##             main      #12      +/-   ##
==========================================
+ Coverage   88.96%   88.99%   +0.02%
==========================================
  Files          55       56       +1
  Lines        1477     1481       +4
  Branches       79       79
==========================================
+ Hits         1314     1318       +4
  Misses        163      163

Impacted Files
Coverage Δ

backend/recotem/recotem/api/views/__init__.py
87.03% <50.00%> (ø)

...ackend/recotem/recotem/api/serializers/__init__.py
97.29% <100.00%> (+0.07%)
:arrow_up:

backend/recotem/recotem/api/serializers/ping.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Review Issue 6: Revenue component

Please review the Revenue Component, linked here
Use these guidelines:

Architecture
Design
JS
React

DUE: 10/21

Design-01: Could use an array for the form input pieces
Design-04: Add a description
For later: totalRevenue could be calculated in the component

Looks good

Revenue component:
Design-01: There is some duplication with the form input, which could be refactored:
Design-08: it’s pretty DRY but we could extract repeated code into helper functions

Design: More comments needed to describe the code

Architecture OK
Design 05 - could have more comments around
JS and ESLint OK
React OK

DESIGN-05: Include more comments


Add basic support for generation of ufunc

Related to #2141

This is awesome! I can’t wait to try it out. Thanks @serge-sans-paille. On a related note, we’re more than halfway through translating all of the currently existing ufuncs in scipy.special into C++. The plan is to make this into a separate C++ library that SciPy and other array libraries can depend on. How much work would it be to make the scalar versions of functions in scipy.special available inside ufunc kernels written in Pythran, if the scalar kernels are already written in C++? Would you be interested in supporting more of scipy.special in Pythran and if so, is this something I could help with?
@mdhaber @tirthasheshpatel. Check out how cool this is.

Very cool - like exactly what we wrote about! That plan changed, but this is still great for things that won't be in special or for things that are built on top of special.


python 3.12 support

Now that rs can support python 3.12, we should too. This PR expands our test matrix to include 3.11 and 3.12. I added these versions as repo-variables in github, so that they can be shared between workflows.
Addresses #81.

Codecov Report
Attention: Patch coverage is 80.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 95.74%. Comparing base (f9c1762) to head (fa84dc3).

Files with missing lines
Patch %
Lines

meteor/rsmap.py
80.00%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #82      +/-   ##
==========================================
- Coverage   95.93%   95.74%   -0.20%
==========================================
  Files          15       15
  Lines         910      916       +6
==========================================
+ Hits          873      877       +4
- Misses         37       39       +2

Flag
Coverage Δ

unittests
95.74% <80.00%> (-0.20%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Buffer underflow when muxing

Hi, i encoded a file and when mux to MPEG-TS container it have many buffer underflows
examples       0 - Multiplexing access unit 500 message OK
M104:Video EB underflow at pack 4945 by 18234 bytes message ERROR buffer underflow
0 - Multiplexing access unit 500
0 - Multiplexing access unit 1000
M104:Video EB underflow at pack 4945 by 18234 bytes
M104:Video EB underflow at pack 5049 by 47364 bytes
0 - Multiplexing access unit 9000
M104:Video EB underflow at pack 5318 by 17199 bytes
M104:Video EB underflow at pack 5682 by 558 bytes
M104:Video EB underflow at pack 5706 by 2437 bytes
0 - Multiplexing access unit 9500
M104:Video EB underflow at pack 5919 by 1751 bytes
M104:Video EB underflow at pack 5949 by 11102 bytes
M104:Video EB underflow at pack 6013 by 13293 bytes
M104:Video EB underflow at pack 6089 by 11910 bytes
M104:Video EB underflow at pack 6157 by 1358 bytes
M104:Video EB underflow at pack 6166 by 622 bytes
M104:Video EB underflow at pack 6173 by 312 bytes
M104:Video EB underflow at pack 6176 by 1570 bytes
M104:Video EB underflow at pack 6186 by 352 bytes
M104:Video EB underflow at pack 6223 by 3568 bytes
M104:Video EB underflow at pack 6254 by 1554 bytes
0 - Multiplexing access unit 10000
The content is encode with TargetBitrate 2 pass VBR, when encoding with CQP or CQF no buffer underflows
1pass cmd
ffmpeg -hide_banner -v error -i 02125.m2ts -f yuv4mpegpipe - | vvencFFapp --y4m 1 --TargetBitrate 1M --CTUSize 64 --Threads 36 --Tiles 2x2 -i - -b C:\Users\thx4ever\Desktop\teste.266 --Verbosity verbose --Sdr sdr_709 --IntraPeriod 240 --Passes 2 --Pass 1 --RCStatsFile teste_1pass.json --MTProfile 0
2pass cmd
ffmpeg -hide_banner -v error -i 02125.m2ts -f yuv4mpegpipe - | vvencFFapp --y4m 1 --TargetBitrate 1M --CTUSize 64 --Threads 36 --Tiles 2x2 -i - -b C:\Users\thx4ever\Desktop\teste.266 --Verbosity info --Sdr sdr_709 --IntraPeriod 240 --Passes 2 --Pass 2 --RCStatsFile teste_1pass.json --MTProfile 0

Edit out a sample and upload it somewhere and send a link to it.
Donald Graft has a DGSplit tool for editing video files under Windows.
Scroll down to the section "Tools and Utilities" and you'll find DGSplit just below.
https://www.rationalqm.us/mine.html#tools
You only need to edit maybe the first 10 seconds at most.

Edit out a sample and upload it somewhere and send a link to it.
Donald Graft has a DGSplit tool for editing video files under Windows. Scroll down to the section "Tools and Utilities" and you'll find DGSplit just below. https://www.rationalqm.us/mine.html#tools You only need to edit maybe the first 10 seconds at most.
I've not read of any tools that support VVC in a TS container - maybe I'm wrong. This could be a similar problem to the other day where someone was using ffmpeg to create VVC inside a mkv container but it didn't work as mkv doesn't support VVC yet. The only muxing tool that supports VVC is currently mp4box and ffmpeg (creating mp4).

Made another sample with 11sec video and here its the output
0 - Multiplexing access unit 500
0 - Multiplexing access unit 1000
0 - Multiplexing access unit 1500
0 - Multiplexing access unit 2000
0 - Multiplexing access unit 2500
0 - Multiplexing access unit 3000
0 - Multiplexing access unit 3500
0 - Multiplexing access unit 4000
0 - Multiplexing access unit 4500
0 - Multiplexing access unit 5000
M104:Video EB underflow at pack 3771 by 37764 bytes
M104:Video EB underflow at pack 3984 by 20778 bytes
0 - Multiplexing access unit 5500
M104:Video EB underflow at pack 4103 by 12586 bytes
M104:Video EB underflow at pack 4175 by 6669 bytes
M104:Video EB underflow at pack 4213 by 3524 bytes
M104:Video EB underflow at pack 4236 by 1478 bytes
M104:Video EB underflow at pack 4246 by 1513 bytes
M104:Video EB underflow at pack 4256 by 3378 bytes
M104:Video EB underflow at pack 4276 by 1433 bytes
M104:Video EB underflow at pack 4285 by 1376 bytes
M104:Video EB underflow at pack 4294 by 5671 bytes
M104:Video EB underflow at pack 4328 by 2848 bytes
M104:Video EB underflow at pack 4345 by 1203 bytes
M104:Video EB underflow at pack 4353 by 1059 bytes
M104:Video EB underflow at pack 4360 by 2600 bytes
M104:Video EB underflow at pack 4380 by 976 bytes
M104:Video EB underflow at pack 4387 by 864 bytes
M104:Video EB underflow at pack 4393 by 9087 bytes
M104:Video EB underflow at pack 4444 by 4978 bytes
M104:Video EB underflow at pack 4475 by 2214 bytes
M104:Video EB underflow at pack 4489 by 744 bytes
M104:Video EB underflow at pack 4495 by 733 bytes
M104:Video EB underflow at pack 4500 by 2306 bytes
M104:Video EB underflow at pack 4514 by 707 bytes
M104:Video EB underflow at pack 4519 by 674 bytes
M104:Video EB underflow at pack 4530 by 2975 bytes
0 - Multiplexing access unit 6000
M104:Video EB underflow at pack 4743 by 43444 bytes
M104:Video EB underflow at pack 4987 by 13095 bytes
0 - Multiplexing access unit 6500
M104:Video EB underflow at pack 5062 by 10574 bytes
M104:Video EB underflow at pack 5123 by 6044 bytes
M104:Video EB underflow at pack 5157 by 1524 bytes
M104:Video EB underflow at pack 5167 by 409 bytes
M104:Video EB underflow at pack 5173 by 499 bytes
M104:Video EB underflow at pack 5177 by 1528 bytes
M104:Video EB underflow at pack 5187 by 445 bytes
M104:Video EB underflow at pack 5191 by 448 bytes
M104:Video EB underflow at pack 5195 by 4724 bytes
M104:Video EB underflow at pack 5222 by 1094 bytes
M104:Video EB underflow at pack 5229 by 345 bytes
M104:Video EB underflow at pack 5232 by 273 bytes
M104:Video EB underflow at pack 5235 by 812 bytes
M104:Video EB underflow at pack 5242 by 203 bytes
M104:Video EB underflow at pack 5246 by 240 bytes
M104:Video EB underflow at pack 5259 by 1952 bytes
0 - Multiplexing access unit 7000
0 - Multiplexing access unit 7500
I dont have used ffmpeg to mux i have retail tool to mux the bitstreams, it fully support the MPEG-TS container format, i can mux with mp4box but in MPEG-TS i get buffer underflow, it mux successfully but when play it stuttering
samples.zip

I think the issue is that VVenC does not support CBR, non of the RC modes does it. 1pRC probably gives the most stable rate, but still no hard on constraints on producing something resembling CBR are there.
The fact that it works with CQ and CQF is just a coincidence specific to your content, but would fail on other content.
TLDR: VVenC does not support CBR.

Your teste,266 sample plays ok once it's muxed into mp4
Obviously the teste.ts sample plays back staggered fashion.
It's best to ask the author of tsMuxer when or if he intends to support h266/VVC
https://www.videohelp.com/software/tsMuxeR

It's possible to create ts format using the gpac tool. The old mp42ts tools is now deprecated.
First mux the 266 file into mp4 using mp4box
mp4box -add teste.266 test2.mp4
Then use gpac to create ts using
gpac -i teste.mp4 -o res/live.m3u8:profile=live:muxtype=ts
A sub folder res is created containing teste_dash1.ts and live.m3u8
gpac displays this message:
[Dasher] First CTS 15015 in segment 1 drifting by 0.625625 (more than half a segment duration) from segment time, consider reencoding or using segment timeline
[Dasher] Changing HLS target duration from 1 to 10, either increase the segment duration or re-encode the content
The teste_dash1.ts plays ok with mpv (with Fraunhofer's VVdeC enabled) without stuttering.


Mobile browser and google map issue

When scrolling down on mobile browser you are stuck on google map and cannot scroll down. Adding max-height: 90vh: on map container gives user extra 10 percent of view height to hook up on page body and scroll down.

can you compile the assets please? (run gulp --production)

Closed until assets compiled.


Add support for redirecting input to buffer

Introduce a new redirection mode. Redirection mode can be used to transmit any number of raw bytes into the application. To enable redirection mode, a new function cmd_redirect is called with a pointer to a buffer and length as parameters. When redirection mode is enabled, all characters received are appended to the redirection buffer until length bytes have been received.

originally I was thinking more like callback function which just give application to decide how much/when to stop "redirecting" and what to do with that data. Then It could be more generic solution but probably this is good enough for us now.

Hmm, that could be good way of doing it as well, didn't think about that. Like pass a function pointer to eg. bool (*input_redirect_fnc)(uint8_t c) which could return true or false depending on if "passthrough/redirection" should stop or continue.

I think I will do that actually, it will be more versatile and it shouldn't be too much work.

Just need to specify that the callback needs to be quick and interrupt safe.

How does this affect to command line interface?

Suggestions for passthrough callback API? Here's what I'm thinking:
typedef void (*input_passthrough_cb_t)(uint8_t c);
void cmd_passthrough_func(input_passthrough_cb_t passthrough_func)
void cmd_passthrough_enable()
void cmd_passthrough_disable()
In cmd_char_input function first check if passthrough enabled and passthrough function defined, call that and return, otherwise continue to normal input handling.

Just need to specify that the callback needs to be quick and interrupt safe.
I don't think this is accurate, you can't call cmd_char_input from interrupt in the first place since it will execute the actual command, ie. every command would have to be quick and interrupt safe?

I don't think this is accurate, you can't call cmd_char_input from interrupt in the first place since it will execute the actual command, ie. every command would have to be quick and interrupt safe?

Eh.. You're right. Nevermind.
The only restriction is that it needs to be fast enough to ensure that the serial interface can't fill the RX buffer. Unless you want to add some sort of flow control messages to the mix.

How does this affect to command line interface?

Once the redirect is active all bytes get swallowed silently until it's disabled again.

Suggestions for passthrough callback API? Here's what I'm thinking:

That seems pretty clear.

typedef void (*input_passthrough_cb_t)(uint8_t c);
void cmd_passthrough_func(input_passthrough_cb_t passthrough_func)

Technically this would be enough. Set cb to NULL to disable. That might not be explicit enough though.

Any chance of this being part of a solution to the following issue?
https://github.com/ARMmbed/mbed-client/issues/398


remove quoting from dockerfile env. closes #1002

removes single quotes from the generated DOCKERFILE_ENV_FILE

these are not needed by dockerfile deployments but are by buildpack deployments

adds link to config/docker-args-run
makes dockerfile test the same as buildpack test

Why the link?

This allows the app env to be included in containers started with dokku run.

@michaelshobbs Thanks for both fixes. That with the link would have been my next issue. :+1:
Already tapped into that.

tests are failing. i'll need to dig into that

Is this why my Dockerfile ENV variables have quotes around them, but the buildpack ones don't?

Yes

What is holding up the merge of this? Looks like tests pass according to CircleCI

Was hoping for more comments I suppose. I'll merge now.


Kubernetes integration

Help wanted to figure out how the hell this is actually going to work

Still requires direct access to Docker daemon for build

Indirect access may be needed

Build daemon running on each Kube node

Test can (and should) be run in Kubernetes

Kube should handle deps

Possibly make this openshift integration


Installing highline-1.7.1.gem still results in hiera-eyaml requires highline (~> 1.6.19)

I installed the latest available versions of trollop (trollop-2.1.1.gem) and highline (highline-1.7.1).
After that I tried to install hiera-eyaml-2.0.7.gem, but I got the following error:
Unable to resolve dependencies: hiera-eyaml requires highline (~> 1.6.19)
I downgraded to highline-1.6.21.gem and then I could install hiera-eyaml-2.0.7.gem

This is expected.  hiera-eyaml does not use any of the features new to HighLine 1.7, which drops compatibility with Ruby 1.8, so the dependency is on the HighLine 1.6 version group.

Thank you. I'll keep using 1.6.x
Have a nice weekend

@ltutar If the problem is resolved, could you close the issue?  Thank you!

I'll close the issue. Thank you for the help.


Add member searching/filtering

Current coverage is 87.82% (diff: 73.68%)

Merging #582 into master will decrease coverage by 0.03%

@@             master       #582   diff @@
==========================================
  Files           209        209
  Lines          8466       8496    +30
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           7439       7462    +23
- Misses         1027       1034     +7
  Partials          0          0

Diff Coverage
File Path

••••       44%
open_humans/member_views.py

••••••••   82%
open_humans/templates/member/member-list.html

•••••••••• 100%
common/activities.py

Powered by Codecov. Last update 02c628d...ee4eac1


[ci skip] adding user @consideratio

Hi! This is the friendly automated conda-forge-webservice.
I've added user @consideratio as instructed in #1.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Please contact conda-forge/core to have this PR merged, if the maintainer is unresponsive.
Fixes #1

Thanks @consideRatio