proposal: Go 2: add alias for interface {} as any

I would lilke to be able to declare any type with keyword any instead of empty interface, like rune means alias int32.
Such feature make language more readable , without polluting declarations with many empty interfaces. Imho any keyword is perfect for such alias.

I often use a type alias for this which isn't much extra work:
type any = interface{}

I agree with the sentiment that interface{} is terrible for readability, but I'm really hoping Go 2 has good enough generics to make nearly all uses of interface{} an avoidable anti-pattern. If that happens, an any type probably wouldn't be warranted at all. But if for some reason generics just completely fall through, sure, I'd support a builtin any alias. I do agree that it would increase readability.

I support this proposal, though not strongly.
In the early days of using Go, I often encountered the map[string]interface{} type, which is really confusing for a new gopher. I used it for about a year without knowing what it exactly means.

I support this proposal too.
Its simple to implements and the readability becomes better

I don't support this proposal. The power of Go is that for many things there's a single way of doing things. A language gets bloated easily once we start adding additional syntaxes only because some people prefer one way over the other.
People new to the language may initially learn the 'any' keyword, but then read existing code, and still have to look up the interface{} keyword. Effectively, the burden of learning the language increases, rather than decreases.

Yes and on w/ what @Freeaqingme  has said, we also must take care when creating different ways of doing the same thing because:

It makes tooling more difficult: now go tools have to support a new path to the same thing, and likely the users of said tools will expect output to match their chosen flavor of alias.

It reduces the token space for future golang iterations. Consider alternate uses for the any token in future iterations of the language. We lose the option of clear expressiveness if we choose to alias any to something that is already provided.  Some random ideas of how any could be something else:  it could refer to any length of array  ([any]string) , it could refer to non ZeroValue elements in a slice ( any mySlice) like lodash's compact function  .

The examples are unimportant, but the point should be clear. If we choose to make this our any then we're stuck with it for quite some time, likely for good.

Besides readability reason, less verbose and weird (esp. for new gophers) is another good point of this proposal.
@Freeaqingme
I began using Go by using Go templates to serve some web pages, I didn't need understand what interface{} is. I just needed to know I can assign any vale to it. any is far better for this purpose.
When a gopher later sudden realizes that any is just interface{}, it is a viva moment, which in fact helps gophers understand Go better.
@MaerF0x0

It makes tooling more difficult:

any is just an alias of interface{}, there are many aliases in Go. If a tool can't handle such cases, it is a not qualified tool.

and likely the users of said tools will expect output to match their chosen flavor of alias.

This is not what a qualified tool should do.

It reduces the token space for future golang iterations.

Builtin identifiers are not keywords, users can shadow them as needed.

@dotaheor

I just needed to know I can assign any vale to it. any is far better for this purpose.

If you really believe interface{} is so bad, I'd suggest you extend this proposal to deprecate interface{} and eventually remove it. I'm not a fan of that either, but my primary argument was against having two keywords for essentially the same thing. That argument would be moot if interface{} keyword is removed.
@MaerF0x0

We lose the option of clear expressiveness if we choose to alias any to something that is already provided.

We still have 'whatever' and 'anythingReally' as alternatives  :yum:

Is there anyone cloud explain the historical reason of why interface{} is designed as interface{} rather than anything else?

@Freeaqingme
any will not be a keyword, it will be just a builtin identifier, just like, rune and byte, etc.
interface{} means an interface type specifying no methods, which happens to make it act as the any type. interface{} is not a bad thing generally, but using it as the any type is bad for new gophers. It confuses many new gophers.

@Freeaqingme

If you really believe interface{} is so bad, I'd suggest you extend this proposal to deprecate interface{} and eventually remove it. I'm not a fan of that either, but my primary argument was against having two keywords for essentially the same thing. That argument would be moot if interface{} keyword is removed.

@changkun

Is there anyone cloud explain the historical reason of why interface{} is designed as interface{} rather than anything else?

It's not a special design, but a logical consequence of Go's type declaration syntax.
You can use anonymous interfaces with more than zero methods:
func f(a interface{Foo(); Bar()}) {     a.Foo()     a.Bar() }
Analogous to how you can use anonymous structs anywhere a type is expected:
func f(a struct{Foo int; Bar string}) {     fmt.Println(a.Foo)     fmt.Println(a.Bar) }
An empty interface just happens to match all types because all types have at least zero methods. Removing interface{} would mean removing all interface functionality from the language if you want to stay consistent / don't want to introduce a special case.

@fzipp good point. I realized that after posting my earlier comment as well. Then it makes zero sense to remove that.
I'm sticking with my original reply; we can simply explain why interface{} is interface{} and how it works. There's then no need to add an additional keyword that basically is/does the same thing.

Nothing will be removed, and the any won't be a keyword, it's just a friendly alias for interface{}, I have a lot of friends new in Golang that struggled a lot to understand the interface{} as a "generic" type

@Freeaqingme

If you really believe interface{} is so bad, I'd suggest you extend this proposal to deprecate interface{} and eventually remove it. I'm not a fan of that either, but my primary argument was against having two keywords for essentially the same thing. That argument would be moot if interface{} keyword is removed.

There was a type alias
type byte = uint8

from the very early days.
It is not me being a proposal supporter or the other way, just a well known fact.

In Haskell when we write guards:
abs n
  | n < 0     = -n
  | otherwise =  n

where
otherwise = True

Just imagine how much less readable it is if one uses True in place of otherwise.
It's only good if there's a single GOOD way of doing things.

The any value acts like the top type in a type system and it may be usefull sometimes even with generics.
Say we have a higher order function that composes just for logs. You do not need a contract of anything like that for that type if you want to log the argument and then perform the action. Something like (take it as a pseudocode):
func add(a interface{}, b interface{}, action fn_type<args>){
  return fn(a, b) -> {
    fmt.Printf("%v %v", a, b)
    action(a, b)
  }
}

The top type would be good in this case instead of writing interface{} either way, so I think this proposal still have some value.

Relevant: https://groups.google.com/forum/#!topic/golang-nuts/pxDVtPjatXo

In the latest generics design, we find the following:

However, it‘s tedious to have to write interface{} every time you write a generic function that doesn’t impose constraints on its type parameters. So in this design we suggest a type constraint any that is equivalent to interface{}. This will be a predeclared name, implicitly declared in the universe block. It will not be valid to use any as anything other than a type constraint.

(Note: clearly we could make any generally available as an alias for interface{}, or as a new defined type defined as interface{}. However, we don't want this design draft, which is about generics, to lead to a possibly significant change to non-generic code. Adding any as a general purpose name for interface{} can and should be discussed separately).

I think the "It will not be valid to use any as anything other than a type constraint." is a bad idea. It is far more simple and consistent to allow the use of the any alias type any = interface{} everywhere, in the hope that as generics are introduced, we'll see it getting use less and less in non-generic code.

I feel very strongly that any should either be allowed in both type parameters and everywhere else, or allowed nowhere at all. And quite strongly that it should be allowed.
Having a confusing-to-beginners pattern of using interface{} is negative
Having any which means the same thing but is only sometimes allowed will add to this confusion and thus is significantly worse
The only thing we must not do is make it more confusing. Adding any would be a nice improvement, but not conditionally

I disagree too. Maybe in Dart, Typescript, Rust, etc. it can be good improvement, otherwise, put in package simple file like
extra.go
package something

type any = interface{}
type null = struct{} // for channels f.e.

// something that you want to syntax sugaring

could be amazing practice! I mean, any/null is good, it's more readable, than interface{}/struct{}, but it can be implemented just now, in specific cases that you want.

@ianlancetaylor

If we are able to add generics to the language, then I suspect there will be many fewer cases where people write interface{}, so the alias would have correspondingly less value. Putting on hold pending a decision on generics.

From design proposal:

So in this design we suggest a type constraint any that is equivalent to interface{}

If I understand it correctly, it would result in having the "alias" ONLY for type parameter constrains (and nowhere else). IMO it would make the language not consistent.

@ianlancetaylor

If we are able to add generics to the language, then I suspect there will be many fewer cases where people write interface{}, so the alias would have correspondingly less value. Putting on hold pending a decision on generics.

From design proposal:

So in this design we suggest a type constraint any that is equivalent to interface{}

If I understand it correctly, it would result in having the "alias" ONLY for type parameter constrains (and nowhere else). IMO it would make the language not consistent.

I believe it would be wiser to either rename any to interface{}, or simply deprecate interface{}, having two types that mean the same thing would put a lot confusion and ambiguity for new adopters of go in the future.

I believe it would be wise to either rename any to interface{}, or simply deprecate interface{}, having two types that mean the same thing would put a lot confusion and ambiguity for new adopters of go in the future.

@g13013 They are not two types. One is the name (an identifier), the other is the actual thing. It's like being confused about fmt.Stringer and interface{String() string} existing at the same time.

@fzipp I think that actually any means interface{}, am I wrong ?

@g13013 Yes, any is an identifier for interface{}, like fmt.Stringer is an identifier for interface{String() string}.

any is just an alias to interface{} it might be called an identifier, still it's the same thing, the point is, having two things that mean the same thing should be avoided.

@g13013
Why do you not complain about having two ways to write fmt.Stringer?
You can write func f(s fmt.Stringer) {} or you can write func f(s interface{String() string}) {}
Why do you not complain about having two ways to write io.Writer?
You can write func f(w io.Writer) {} or you can write func f(w interface{Write(p []byte) (n int, err error)}) {}
Why is it suddenly a problem with any and  interface{}?

@fzipp if so, how to use json.Unmarshal without interface{}/any?

@fzipp I would complain about func f(s interface{String() string}) {} and func f(interface{Write(p []byte) (n int, err error)} I would definitely ban them as it makes the code unnecessarily unreadable.
interface{} is an another story, its the de facto standard in go to accept any type, I think you got me wrong, if we chose to introduce any for generics, than the deprecation should happen in the documentation and guides not in the language itself, if we are willing to keep interface{} than I would definitely prefer to write generics with interface{} instead of any.

re: https://github.com/golang/go/issues/33232#issuecomment-525489884
Now that the proposal is accepted (https://github.com/golang/go/issues/33502#issuecomment-776951191), what's next?

I believe the proposal here is to add a new predeclared identifier any that is an alias for interface{}.
I'll take this proposal off hold.

I strongly support use of "any" as an alias for interface{}, and I also support deprecation of interface{}. I think there may be an argument for having "any" and "anyref". The argument could be that "any" in a generic context has a different meaning and performance consideration than "any" in a non-generic context.
For example:
func M[T any](p1 T, p2 any) {
  // ...
}

The "p1" parameter is fundamentally different than the "p2" parameter. I can imagine some user confusion here.
That being said, I would like to discourage adopting two separate type names. I strongly support using "any" as both the generic constraint, and the alias for reflection-based polymorphism. Semantically "any" in both places means the same thing: a type must satisfy the constraint to be legally passed. There are differences in how the type looks to the user at compile time, but they aren't significant enough to warrant bifurcation.

I don't think this is a good idea.
Semantically speaking, interface{} means "interface that holds value, whose type guaranteed to have empty method set". Important thing there is that interface{} does not define type of value. It just wraps value of concrete type to use it in runtime.
I see that recent rise in discussion is probably because of approval of type parameters and its any type parameter. It is wrong to extend its usage to language, because in scope of type parameters any means concrete type rather than value wrapped into interface{}.
This change can be misleading since one may assume that any is concrete type while it is not.

@gudvinr in terms of go generics: interface{} == any, but any != interface{}. you can't set any value as any type, but you can set, for example (interface{})(nil)

@gudvinr in terms of go generics: interface{} == any, but any != interface{}. you can't set any value as any type, but you can set, for example (interface{})(nil)

It makes perfect sense because in terms of generics interface{} and any both aren't types but type constraints which later will be deducted into concrete type. In second statement interface{} is a valid type for value that holds another value.

@gudvinr absolutely not. In the world of golang, the interface{} is a type, same as fmt.Stringer, or error. the interface{} type itself is a pointer to ANYTHING that corresponds to the specified interface (f.e. error allows to store pointer to literally any value, that has at least Error() string method, interface{} allows to store pointer to literally any value that has at least be correct for go runtime). any is not a type as you correctly said, but it's constraint for specific types.

I don't understand where the confusion or the desire to distinguish comes from.
These are interfaces:
any				// identifier
interface{}			// no identifier

fmt.Stringer			// identifier
interface{String() string}	// no identifier

error				// identifier
interface{Error() string}	// no identifier

You can use them as types:
var x any
var x interface{}

var x fmt.Stringer
var x interface{String() string}

var x error
var x interface{Error() string}

You can use them as constraints:
[T any]
[T interface{}]

[T fmt.Stringer]
[T interface{String() string}]

[T error]
[T interface{Error() string}]

An interface is not intrinsically a type or a constraint, it's just a method set. Whether an interface acts as a type or as a constraint depends on its usage position, not on its identifier or lack of identifier.

This is a great summary of why the feature should exist. It is syntactic
sugar and isn't more confusing than the existing situation. The current
situation is not easier for learners, it does not provide more information
or syntactic clues. And "any" is not more confusing for advanced users than
interface{} is.
Providing an identifier that means "interface{}" is strictly better in all
ways.
On Thu, Mar 11, 2021 at 3:45 PM fzipp @.***> wrote:

I don't understand where the confusion or the desire to distinguish comes
from.
These are interfaces:
any				// identifier
interface{}			// no identifier
fmt.Stringer			// identifier
interface{String() string}	// no identifier
error				// identifier
interface{Error() string}	// no identifier
You can use them as types:
var x any
var x interface{}
var x fmt.Stringer
var x interface{String() string}
var x error
var x interface{Error() string}
You can use them as constraints:
[T any]
[T interface{}]
[T fmt.Stringer]
[T interface{String() string}]
[T error]
[T interface{Error() string}]
An interface is not intrinsically a type or a constraint, it's just a
method set. Whether an interface acts as a type or as a constraint depends
on its usage position, not on its identifier or lack of identifier.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/33232#issuecomment-797037075, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPQTPAZILO32FHT4GND573TDETXLANCNFSM4IF5A7QQ
.

@nadiasvertex If you consider yourself "advanced user" you probably already know that usage of empty interfaces kinda discouraged.
In reality, most code written by inexperienced folks won't naturally contain interface{}. There are limited number of cases where you can't avoid them and it's basically either libraries for data serialization or some sort of containers and wrappers (like sync/atomic).
These kind of libraries usually require interface{} as input parameter(s). Even then it's being converted to reflect.Value right at the beginning most of the time.
In some cases type parameters reduce usage of interface{} even more.
And most importantly, this alias won't benefit existing libraries in any way because rewriting them using new alias is waste of time.
So why bother adding alias for sake of adding it? It has zero impact on existing code, it can't be widely used by "learners" and "advanced users" only use interface{} in write-once kind of libraries.
It isn't better in any meaningful way outside of discussions on how cool it would be.

@fzipp You should try to expand your example outside of definitions since they constructed in a way that only benefits your point but doesn't show difference in semantics while focusing on specific difference between having identifier or not.
In your last example, you only define constraints as type parameters. Code inside functions that use those parameters won't use these constraints explicitly.
While if you have interfaces as types you will probably use them a little more often than that. In that case, assigning something to variable of type any seems very wrong in statically typed language.

An interface is not intrinsically a type or a constraint, it's just a method set.

Interfaces are types that specify method sets. Not in some ephemeral sense, it is a struct that holds pointer and RTTI header.
And when you have some value with interface{} type you explicitly state that "value of that type will be wrapped in a struct".
It is well-known behaviour for advanced users and explained basically in every tutorial and article.
Alias for interface{} hides that subtle yet important meaning since any can easily be misinterpreted as "any type" which is not true. That means you must always keep this in mind this additional information.
For example, C++ users might assume that it works like auto and does some deduction at compile time.
If you have some previous experience with dynamically typed languages you might also wrongly assume that any has some properties that it doesn't have. Interfaces allow you to have type information in runtime but Go still statically typed language.
Constraints, on the other hand, are meta-types. You do not use constraint as a type inside parameterized function. In that case any literally means "any type" and after applying [T any] constraint, var value T will have value of type T, not type any.

@nadiasvertex If you consider yourself "advanced user" you probably already know that usage of empty interfaces kinda discouraged.

It doesn't matter if they are discouraged or not. They are the only mechanism that exists for accomplishing certain tasks. If you look through the go standard library you will see them used over and over. Whether or not a new user needs to (or should) "write" an interface{} taking function is immaterial since they certainly will need to use one.
For example, what is more immediately clear to a new user reading the following (real) prototype from the library:
 func SliceStable(x interface{}, less func(i, j int) bool)
or
 func SliceStable(x any, less func(i, j int) bool)

And when you have some value with interface{} type you explicitly state that "value of that type will be wrapped in a struct".

That's not true. You can turn integers into receivers with no more ceremony than a "type" statement. All function calls in go are statically bound at compile time. There is no implicit automatic runtime dispatch. While type assertions do invoke the reflection machinery, the asserted value is statically bound which (among other reasons) is why you have to check to make sure it worked before using it.

They are the only mechanism that exists for accomplishing certain tasks. If you look through the go standard library you will see them used over and over.

As you may notice, I said exact same thing after sentence you quoted. These usages limited by basically libraries for data serialization or some sort of containers and wrappers.

For example, what is more immediately clear to a new user reading the following (real) prototype from the library

Neither. You still need to explain what to pass in documentation. This case is also covered by "type parameters reduce usage of interface{}". So I don't get what's your point here.
And you still don't pass value of "any type", you pass wrapped value of concrete type so it's probably important to have this information right on hand.

And when you have some value with interface{} type you explicitly state that "value of that type will be wrapped in a struct".

That's not true.

What do you mean? This is struct that describes interfaces in Go runtime:
type iface struct {
	tab  *itab
	data unsafe.Pointer
}

type statement uses information from tab (which contains both interface type information and dynamic type information of stored type) to extract value from data. It is neither implicit nor automatic.

@fzipp You should try to expand your example outside of definitions since they constructed in a way that only benefits your point but doesn't show difference in semantics while focusing on specific difference between having identifier or not.
In your last example, you only define constraints as type parameters. Code inside functions that use those parameters won't use these constraints explicitly.

@gudvinr Ok, here's an example with implementation:
func Concat1(a []fmt.Stringer) string {
	r := ""
	for _, s := range a {
		r += s.String()
	}
	return r
}

func [T fmt.Stringer] Concat2(a []T) string {
	r := ""
	for _, s := range a {
		r += s.String()
	}
	return r
}

fmt.Stringer is an interface. In Concat1 it acts as a type constraint, in Concat2 it acts as a type. The difference in semantics between these two functions does not come from a difference in names (it's fmt.Stringer in both cases) but from a difference in usage position. So why should interface{} / any be an exception. Why artificially limit the scope of any as an identifier for interface{} to type parameter lists when this limitation does not exist for all the other interfaces. Implementation details like boxed in one case and not boxed in the other case (depends on how type parameters will be implemented) can't be the criterion as the fmt.Stringer example shows.

I think that all the debate stems from the overloading of interface with type constraints which I don't like.
Any is a constraint.
interface{} is a type that the proposal wants to be allowed as a use to denote the same constraint.
The issue is that an interface has in general adhoc constraints itself (adhoc because the constraints are different depending on the compiler implementation of interface types)
Using interfaces as types and as constraints too is confusing at best.
Better way would be to have a notation to explicitly derive a constraint object from a type.
In our present case,
const Any = type constraint{
    interface{}
}

And even that needs to be looked into because the equality of constraints is not assured if we want to implement a constraint checker at the compiler level and not only user code.
In that case, we would need some type of constraint deriving function that would massage the type's constraint sets a bit.
Anyway, semantically, any should be different from interface{}.

I think that all the debate stems from the overloading of interface with type constraints which I don't like.

The fact that interfaces can also act as constraints is the whole genius and beauty of the type parameters design.

I don't think it's genius after having thought hard about it. And the literature seems to warn against it.
I initially also thought that interfaces would be sufficient but the problem is that they are types.

Unfortunately, I don't think it's manageable after having thought hard about it. It's confusing and the literature seems to warn against it.
I initially also thought that interfaces would be sufficient but the problem is that they are types.

The Featherweight Go paper has shown that interfaces as constraints work out. I'd be interested in the literature that you're referring to. I'm more worried about type lists in interfaces if they make some interfaces unusable as types. But I hear that they are working on an update to the design that addresses this.

Semantic subtyping is a variant of structural subtyping that has been implemented in an O-Caml based language.
They use a set theoretic interpretation of types.
They use a SMT solver to type check one of their language C-Duce if I remember well.
It's basically constraint type checking which is similar to having types as a set of propositions.
They even have  the luxury of having variance bolted in the type system and make it still decidable if I still do remember well. Although I do not know how slow the type checking is because of it.
The warning is about a seemingly unrelated issue but that will apply here.
Can be found in "A gentle introduction to sematic subtyping" page 200.
This is about breaking the circularity problem in presence of arrow types (functions basically).
This is actually a similar issue to what I am hinting at.
Namely, the constraints on types are a superset of the constraints of types. Especially for interfaces.
And when solving, it needs to be taken into account for soundness.

They are the only mechanism that exists for accomplishing certain tasks. If you look through the go standard library you will see them used over and over.

As you may notice, I said exact same thing after sentence you quoted. These usages limited by basically libraries for data serialization or some sort of containers and wrappers.

Which means that new users especially need to understand them.

For example, what is more immediately clear to a new user reading the following (real) prototype from the library

Neither. You still need to explain what to pass in documentation. This case is also covered by "type parameters reduce usage of interface{}". So I don't get what's your point here.
And you still don't pass value of "any type", you pass wrapped value of concrete type so it's probably important to have this information right on hand.

The point is that inteface{} is a needlessly esoteric spelling of any type. We should just say "any".

And when you have some value with interface{} type you explicitly state that "value of that type will be wrapped in a struct".

That's not true.

What do you mean? This is struct that describes interfaces in Go runtime:
type iface struct {
	tab  *itab
	data unsafe.Pointer
}

I think I have trouble understanding your English. Certainly if you pass a type into a function that takes a value interface what you say is true. My point is that just because something acts as a receiver doesn't mean that the value has to be wrapped up into yet another object. Also, what you point to is an implementation detail, not a semantic requirement of the language. The machinery of the implementation can be changed without necessarily affecting the semantics of the language.

I thought it was worth mentioning that interface{} has a natural pairing with struct{}, and both function very similarly to Any and Unit in Kotlin. Any is the equivalent of Java's Object, the automatic top of the class hierarchy, allowing any type to be assigned to a variable of type Any by way of subtype polymorphism, thus acting fairly similarly to interface{} in Go.
Similarly, Unit does the opposite, allowing only the value Unit to be assigned to it and thus carrying no information whatsoever, very similarly to struct{} and other, less commonly used empty types in Go.
Something like unit would have a quirk in Go, of course, as unit could only be a type, not also the value for that type, if it was just an alias for struct{}. The value would instead have to be unit{}, which is kind of odd.

@DeedleFake, unit would be a separate proposal (and exceedingly unlikely to be accepted). This is only about increasing the visibility of the now-already-existing any.

@rsc I know. I'm not proposing it. Just mentioning prior art and something generally related.
Personally, I'm not in favor of any, and one of the reasons for that is that unit, the natural counterpart, would be weird. If any hadn't been accepted for use in type constraints, I would have been very against its inclusion as a general-use alias, but because it has been, and only because it has been, it seems to make some sense. That doesn't sit well with me.

@DeedleFake, unit{} is not the counterpart to any. There are infinitely many possible unit types (imagine an unexported type unit struct{} in each of infinitely many packages), whereas there is only one any type: even if you define a separate any type in each of infinitely many packages, they are all interchangeable and mutually-assignable.
The type-theoretic counterpart to any is the “bottom” type (⊥), which is the return type of an expression that cannot evaluate to a value (e.g. one that must loop forever, panic, or call runtime.Goexit). There is no well-defined bottom type in Go's type system today, and I would be shocked if one were ever added, so I think its omission here is perfectly natural.

I posted https://golang.org/cl/347296 to show what a blind replacement would do in the main Go repo. (For backwards compatibility, we're unlikely to do much better than that.) Overall, the code is shorter and I think a bit clearer, but definitely feels foreign. That foreign feeling would dissipate pretty quickly. (I remember the same feeling when we started capitalizing for export and when os.Error became error. You adapt quickly, and the old code starts to look foreign instead.)
I don't believe the way the code looks is dispositive one way or another: it looks fine before, and it looks fine after. Instead I think we should be considering the larger effects of the change.
As I understand it, the main reason to decline this proposal, or put it back on hold, and leave 'any' only useful for constraints in Go 1.18, is to be cautious and move slowly. In general I think that's often good advice, but it's not a hard rule.
Here are some reasons for accepting the proposal in Go 1.18, which I personally find persuasive in aggregate:

'any' being only for constraints is a detail that will be in every writeup of generics - books, blog posts, and so on.
If we think we are likely to allow it eventually, it makes sense to allow it from the start and avoid invalidating all that written material.

'any' being only for constraints is an unexpected cut-out that reduces generality and orthogonality of concepts.
It's easy to say "let's just wait and see", but prescribing uses tends to create much more jagged features than full generality. We saw this with type aliases as well (and resisted almost all the proposed cut-outs, thankfully).

If 'any' is allowed in generics but not non-generic code, then it might encourage people to overuse generics simply because 'any' is nicer to write than 'interface{}', when the decision about generics or not should really be made by considering other factors.

If we allow 'any' for ordinary non-generic usage too, then seeing interface{} in code could serve as a kind of signal that the code predates generics and has not yet been reconsidered in the post-generics world.
Some code using interface{} should use generics. Other code should continue to use interfaces.
Rewriting it one way or another to remove the text 'interface{}' would give people a clear way to see what they'd updated and hadn't. (Of course, some code that might be better with generics must still use interface{} for backwards-compatibility reasons, but it can still be updated to confirm that the decision was considered and made.)

2. 'any' being only for constraints is an unexpected cut-out that reduces generality and orthogonality of concepts.

This also adds to the overhead of those people learning Go for the first time. Differences that feel like they should be the same thing often confuse people learning and not aware of the history of the language.

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

There are infinitely many possible unit types (imagine an unexported type unit struct{} in each of infinitely many packages), whereas there is only one any type

@bcmills Is this because interfaces are a form of structural typing, while structs use nominative typing?

Just like byte is alias of uint8
And rune is alias of int32
Adding one more for readability is fine

Would gofmt rewrite interface{} to any automatically? I imagine this could be quite helpful in the pursuit of consistency and there being one way to do any given thing

Would gofmt rewrite interface{} to any automatically? I imagine this could be quite helpful in the pursuit of consistency and there being one way to do any given thing

I believe this would be a work better appropriate to  go fix

Would gofmt rewrite interface{} to any automatically? I imagine this could be quite helpful in the pursuit of consistency and there being one way to do any given thing

I don't think gofmt should be rewriting interface{} to any. A programmer may choose interface{} deliberately, for instance because the intent is to add methods eventually. It would be really annoying if gofmt were to change that code. More generally, gofmt is in the business of organizing "white space", not rewriting code. (The fact that gofmt does have some options for rewriting, such as the -s and -r flags, is largely historic; we wouldn't be doing this now.)

We are going to accept this change. Robert will update the compiler.
Please do not send CLs updating the main Go tree to use any in new places.
We will do it in a single CL ourselves. Thank you.

If I recall correctly there was a promise not to change the language in Go 1. And adding a new keyword is quite a big change.
There are a lot of packages, libraries, and apps that use any as a type, type alias, or variable name: https://github.com/search?l=Go&q="any"&type=Code
Just assume the situation when your project stops compiling because of some indirect dependency that uses any.

@makhov: This isn't adding a new keyword, but rather adding a new builtin alias.
Any local declarations of any will take precedence over the builtin declaration for any.

Generally, it's not a good idea to shadow an identifier (builtin or otherwise), but it's not incorrect either. I don't think grpc (or any codebase) needs to change any of their usages of any.

@makhov What @dsnet said. This is a 100% backward-compatible change. any is a predeclared alias for interface{}. Regarding your 2nd comment: You could always shoot yourself into the foot and write something like const true = false. The answer is simple: just don't do that.

Isn't the final comment period over?

The answer is simple: just don't do that.

@griesemer and I don't. But now looks like someone is shooting in my foot without me doing anything :)
My point here is that the change will introduce more issues than value, at least now.

That's true of any language or library change, though. For example:

That's not what I'm talking about, so I'd say your examples are irrelevant. I'm not arguing the transition from interface{} to any here (yet). Valid usage of var any is no longer valid after the change, that's the point.

That's certainly subjective. The 118 thumbs up and the 44 thumbs down seems to suggest that most people believe this has value.

I'm from Russia, don't tell me about democracy :)

Valid use of var any ... remains valid after this change; that is the point of this change being backward-compatible.
Let's stop this discussion. This issue has been up for > 2 years and there was plenty of time to comment and plenty of discussion on its merits and disadvantages. Thanks.

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

Reopening because this is not yet done.
@makhov This change is completely backward compatible.  If you want to discuss why that is, please do so on golang-nuts, not here.  Thanks.

Valid use of var any ... remains valid after this change; that is the point of this change being backward-compatible.

This change is completely backward compatible.

@ianlancetaylor @griesemer Only in the sense that it still will compile. But software engineering is much more than writing code that compiles, right?
Again, legit code will become ugly. Making the product of your customers worse is not a good way to go, IMHO.
Also, the issue has LanguageChange and Go2 labels. Will it be implemented only in Go2?

@makhov To repeat what @ianlancetaylor already said: If you want to discuss why that is, please do so on golang-nuts, not here. Thanks.

Actually, this is done, sorry.

For people who are landing on this issue now, note that the reasoning for acceptance is in https://github.com/golang/go/issues/33232#issuecomment-915333205, which is in the middle of the issue thread and therefore hidden by default.


Fn::Sub warning on Resources line

CloudFormation Lint Version
1.4.2
What operating system are you using?
Windows, Ububunu
Describe the bug
I'm getting this warning from cfn-lint (1.30 to 1.4.2). - 0.87 is fine by the way. The problem is that it's for the Resources: line section.
W1020 'Fn::Sub' isn't needed because there are no variables
src\project\project.yml:115:1

There are only two places where Fn::Sub is getting used in the whole file and I've checked them. I also checked !Sub references and from what I can see, they look fine too. Obviously having the actual line number that I should be looking at would make a big difference rather than the parent.
I won't include a template as it would be 4k lines. I'm sorry I can't be more specific about this issue as it's kind of vague in of itself.
Expected behavior
I would expect to be directed to the exact line that it's warning me about - not the parent.
Reproduction template
Resources:
  ...

Any chance you have the resource/property you are using the sub?
I'll look into why the path is getting messed up.
That rule will look for the ${}(with a negative look ahead for the escape characters) pattern in the Fn::Sub string section to validate if there are any parameters. Can you double check that there are variables there.  Its possible that the regex is getting tripped on something but I don't believe this regex was changed from v0.
Also are you using SAM in this template?

This is the regex by the way.  re.compile(r"\${([^!].*?)}")

It is a SAM template. There are two AWS::CloudWatch::Dashboard's that use Fn::Sub and even if I remove those logical resources from the template, it still brings up the warning (i.e there is no Fn::Sub found in the file at all). That is what is odd about it.

By the time we do validation all occurrences of !Sub are converted into Fn::Sub

I'm curious if you were able to figure this out.  You should be able to do cfn-lint --info -- template.yaml to see the template that is generated by SAM translator.  We use that template to do our linting.  My guess is there a sub that doesn't have a parameter in there.  We have a few options... we could disable this validation when a person is using SAM.  The reason resources is being highlighted is its a new resource that is created by SAM so we lose the ability to track it to the template you are working on.

Sorry for the delay - I was ill. I eventually go the output to a file with WSL and  cfn-lint --info --  ./src/ropp/ropp.yml 2> output. Unfortunately, the line at 115 it is complaining about is   }, and the Fn::Sub's at 109 and 120 have ${AWS::StackName}...
We might just have to disable this warning to get past the issue at this stage.

This error should no longer show in SAM transformed templates.


Expand set of characters command can contain?

Would it be possible to allow the command contain everything up to the end of the line? The presently accepted set of character is rather restrictive.
https://github.com/onatm/croon/blob/c88b4f59894d1539210c113abeb6d8a1b31ce432/src/parser.rs#L99
Sorry, I don't know much about nom parsers.

This sounds like a great improvement. I believe you already have an implementation for it. Would you like to send a PR?

Sure. Though, given my inexperience with nom parsers, feel free to propose changes and/or push additional commits.


Update to cross-fetch 3.x.x releases

cross-fetch and it's dependancies have been updated for some time.
This update would be great to be pushed as a dot update.
If needed we could update this to be 2.2.2||^3.0.0 if you think that is better.

cross-fetch is no longer bundled so this PR is obsolete. Thanks anyways @Bertg!


files about privacy policy are removed

@sot528 please check the points below.

deleted privacy policy link from footer
deleted files which is related to privacy policy
no style collapse( I worry if I deleted wrong file)

[nits]
Finally we removed all of markdown resources. 😂
So please remove related package from package.json via the command:

yarn remove jstransformer-markdown-it

And commit package.json and yarn.lock.

[nits]
Also, please remove src/includes/navbar_without_links.pug

@sot528 Done! Check it out!

@fiestared
LGTM!


It's difficult to find your position in the Leaderboard and it takes a lot of time

Currently I have to scroll for a long time to find my account
⇒ Suggestion: Stick the user's ranking so that the user can always see and know the ranking position

Currently, this issue is resolved


Fix SelfRegisterTestCase intermittent failure

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/11157992218

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/11157992218
Status: success


Remove dead code in settingspage class

Description

This PR removes some dead inside the SettingsPage class.
Motivation and Context

Closes #866
How Has This Been Tested?

Ran the app manually.
Screenshots (if appropriate):
Types of changes

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

@chingucoding I remove an additional function that wasn't used. Let me know what you think

I think that the function you removed was actually used, it seems that the settings page header is not working anymore.

Ok my bad. I didn't see any references to it but I'll put it back.

The OnNavigatedTo is one of the special functions that are being called by the XAML Framework itsself, that's why you won't find a reference to it in the XCG code base.

Awesome! Thank you @chingucoding!


Revert #313 include errors in abi. (caused storage layout bugs)

Storage layout was broken in #313.  This removes an interface inheritance that broke it before

Current dependencies on/for this PR:

main

PR #330   👈

This stack of pull requests is managed by Graphite.

is this a git rollback?

is this a git revert?

it was originally, but this just fixes that issue. if preferred, we can do a separate git rollback

is this a git revert?

it was originally, but this just fixes that issue. if preferred, we can do a separate git rollback

@iainnash #332 does a full revert.  If desired, we can go with that, then do this diff on top of that to fix the issue

Merge activity

Nov 8, 7:32 PM: @oveddan merged this pull request with Graphite.


[UISAUTHCOM-39] Enforce new "manage" permission set

Fulfills UISAUTHCOM-39.
Only show the "Assigned users" accordion in the role details pane if user has ui-authorization-roles.users.settings.view perm. See dependent perm changes here: https://github.com/folio-org/ui-authorization-roles/pull/90
Also, prevent Action menu from displaying if there are no actions to perform due to user not having sufficient perms.

Code changes LGTM, but there are no tests 😢

Thanks, added tests.


bug: inappbrowser options not working (toolbar missing)

Type: bug
Platform: mobile browser
I was trying to make toolbar appear in the inappbrowser so that i can "close" that view. although toolbar=yes should be the default behaviour but that is not the case in ionic (toolbar shown in onsenUI)
As mentioned in this link http://forum.ionicframework.com/t/inappbrowser-options-not-working/16896
apparent the options field does not seem to work.
tried with "window.open('http://pururu.moe/vy/chocolator', '_self ','toolbar=yes,location=no'); " but the result is still the same. therefore i am assuming is the ionic issue rather than ngCordova
using ngCordova 0.1.14-alpha

Greetings @Trexology!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!

Unfortunately, bugs with the inappbrowser are beyond our direct control. I would encourage you file a bug on Apache's Jira repo, and encourage those on the forum to chime in there.


remove/updated dependencies

Updated to lowest LTS (node 8+)
Changed the main function to a class

Got rid of inherit
Made all test file use new

Got rid of typedarray
Got rid of buffer-from (only needed for node < 6)?

This should make the bundle smaller
edit: Realised i did the same stuff as in #62 + a bit more
closes #62

ping

ping

ping again @maxogden

ping

@mafintosh Would you like some help with maintaining the library?


622 block headers

closes #622
TODO

[x] Use cargo fmt
[x] Add necessary tests
[x] Add changelog entry
[x] Update default config/theme in README (if applicable)
[x] Update man page at lsd/doc/lsd.md (if applicable)

This is how the header looks like

On second thought should we just use underlines instead of using -? It looks like we have a lot of wasted space.

On second thought should we just use underlines instead of using -? It looks like we have a lot of wasted space.

Yes, it does look like there's a lot of wasted space. Will update

Underlined text looks much better imo :)

Thanks for contributing!


note about GIS licences

I'm really sorry about not seeing this for over 2 years! Github has been really bad at notifications. There is now a conflict due to later changes.

rejigged and resubmitted....sometimes I just don't get git!


#394 Add the subscribtion menu to the header

@veganstraightedge, it could be cool if you had some time to review the css and tell me if it's ok or if you sea a better way to do it. :)

Merged. I have additional removed /video from the nav for now to keep it to two rows of nav items.

But, Subscribe is to long for the design. When the width get >= 800px, than the menu get horizontal, but with the subscribe item, it's too long and the bulb logo goes under the Crimethinc. title. It takes like 810px for the bulb logo to take the right place.
Do you think we could change the $small-phone viewport width or just find a way to make the nav smaller ?

Really there should be a responsive menu with a hamburger icon. :/
Is that something you'd be up for doing if I sketch up some comps?

Yeah, if you have an idea on how you want it I could do it.

Great. I'll sketch it later today and create a new issue for you.


Godot does not repeat the texture correctly.

Tested versions
v3.6.beta5.official [2a347ab86]
System information
w10 64
Issue description
If you use a small size image, godot does not repeat the texture well as you can see in this video.
Godot has no problem repeating the texture if, for example, you use the godot icon as a graphic.
Any solution to this?
Video example:
https://github.com/godotengine/godot/assets/19652075/5de2115e-f2cd-4720-b3f5-6915b2853e93
Steps to reproduce
Try repeating the texture in the example project.
Activate repeat.
Recare
Activate the region
Set region 0, 0, 64, 64 for example
Minimal reproduction project (MRP)
testRuedas.zip

Does repeat textures work when the texture is a standard square size like 32x32, 64x64, 128x128, 256x256...? Don't think GLES2 can repeat non-uniform sizes.

Yes, then it's probably because of that.

If you click the texture huella.png, go to the import tab, set the repeat from disabled to enabled, then click Reimport, it works for me.
In Godot 3 you need to set the repeat when importing the texture, afaik. (In Godot 4 this is handled differently afaik.)

Hi, sorry for the delay.
The gpu is:

It isn't that old, but it still sounds like it is a GPU / driver limitation with NPOT.
It's up to you but it's a good idea (for compability in general) to use power of two textures with wrapping, not least because it will save a resize on some mobile which might result in some filtering anomalies.
It is kind of strange because:
https://opengl.gpuinfo.org/displayreport.php?id=13279
Suggests that GL_ARB_texture_non_power_of_two is quoted (in that report anyway) which should support npot texture wrapping. :shrug:

Also, just to remind, in the video, you didn't click "reimport".
Changing the texture wrap setting does nothing afaik unless you click "reimport".

I clicked on reimport, but the video doesn't show it. It works in v3.6.rc1.official [cfc4a0eff] anyway.

It works in v3.6.rc1.official [https://github.com/godotengine/godot/commit/cfc4a0eff029c3bda6df061465f9a6b6c66b9f01] anyway.

Very strange, I don't think we changed anything in 2D rendering since beta 5.
Possibly something corrupt or out of date in the import folder, not sure without being able to bisect / test locally.
Anyway if it is working again now, that is good, but frustrating not to know what caused it.


Match import wildcards

Continues #1149 and fixes #402.
I'm not necessarily happy with this code. I was trying to find the smallest change that fixed the issue. I think I did that, but the performance of this approach is probably bad. To check against a module name it does a map lookup as before, then it tries matching every pattern against the module name until it finds a match. This works but it could no doubt be faster.
That being said, I haven't tested the real world performance of this. Perhaps it's acceptable? At any rate I'd be happy to work on a faster approach.

Thanks, this looks pretty plausible.  People don't use restrictive matching that much, and if they start to, we can find/fix it then. Given we're quite a way since the GHC 9.0 release, and it's only just got to the point where our dependencies work with GHC 9.0, my inclination is to sit on this patch for a few days, make a GHC 9.0 release, and then do a proper review.

Sounds good to me! Absolutely no rush at all.

Thanks for the feedback! This should be ready for a re-review.

Thanks, looks great!


Quark - Changing statistics class.

This is more of a question, about a possible solution to an issue.
After going through the quick start guide (I like all the subtle hints) and getting everything running. Installed quarkcoin hash etc, etc, The last thing left was this "Pool_Target" and "Difficulty"
thats enough preamble i'll get to the question;
After setting the pool_target to 0.003  and the MPOS difficulty to 7.6191 the estimated shares was off...
So i was thinking to myself.. While looking at the statistics class formula, well why don't i just change
getEstimatedShares($dDiff) {     return round((POW(2, (32 - $this->config['target_bits'])) * $dDiff) / pow(2, ($this->config['difficulty'] - 16)));
to
getEstimatedShares($dDiff) {     return round((POW(2, (32 - $this->config['target_bits'])) * $dDiff) / pow(2, ($this->config['difficulty'] - 16)) / 333.43);
1/0.003 = 333.33 + 0.1

333.33 represents the amount of times our desired "pool_target" multiplies into the minimum difficulty in stratum with an inclusion of 0.1 (Out of preference, because i hate recurring numbers)

Is this an adequate correction ?
My hash rates seem correct, its submitting shares, and now the estimated shares "appear" correct i don't have enough hash power to crack a block but the estimates are similar to every other pool i'm looking at (I'm not running on test-net)
There is a high chance i've just mis-undertood something (I haven't read the whole source yet)
withstanding the known fact that hash-rate shouldn't calculate properly under difficulty 16 what else is wrong with this solution ?

i am need support to quark algorithm. i create dimecoin pool but maybe custom mpos to support it.


Update Docker maven plugin version for quickstarts

Refer to this link for build results (access rights to CI server needed):
https://fabric8-ci.fusesource.com/job/fabric8-quickstarts-master-pullreq/220/
Test PASSed.


Adding changes for consistent streaming of records

Sorry - ignore the previous comment. Wrong diff.

What is the plan to merge this PR? A couple of action items are to ensure github actions and jenkins runs are successful

@vrajat I have modified the GH Actions accordingly in order to get them run successfully, but the only issue will be that the consistency tests will fail in the runs against the stable YB build as that runs against 2.16 and doesn't have the required changes. I will update that to not run the test for consistency so that even they are successful.
Are there any other items you're talking about?

Will jenkins run the consistency tests?


feat(redux-store)!: update to afj 0.2.0

Updates redux store package to AFJ 0.2.0, removes most of the thunks (except get all to initialize the state) and updates the event listeners to the generic record events.
Supersedes #119.
MAKE SURE TO ADD THE FOLLOWING BREAKING CHANGES TO THE END OF THE SQUASHED COMMIT MESSAGE:
BREAKING CHANGE: the state changed events listeners have been updated to the new generic record saved/updated/deleted events. Instead of using a listener for each of the record types, you only have to use the startRecordsListeners method now.
BREAKING CHANGE: The thunks that exposed all module methods from AFJ are now removed. Instead of using the thunks, you should use the agent directly.

Codecov Report

Merging #133 (352e17d) into main (fd219ba) will decrease coverage by 3.47%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #133      +/-   ##
==========================================
- Coverage   89.09%   85.62%   -3.48%
==========================================
  Files          43       43
  Lines         633      633
  Branches       84       84
==========================================
- Hits          564      542      -22
- Misses         59       80      +21
- Partials       10       11       +1

Impacted Files
Coverage Δ

packages/rest/src/events/BasicMessageEvents.ts
50.00% <0.00%> (-50.00%)
:arrow_down:

packages/rest/src/events/ProofEvents.ts
57.14% <0.00%> (-42.86%)
:arrow_down:

packages/rest/src/events/ConnectionEvents.ts
57.14% <0.00%> (-42.86%)
:arrow_down:

packages/rest/src/events/CredentialEvents.ts
57.14% <0.00%> (-42.86%)
:arrow_down:

...ntrollers/basic-messages/BasicMessageController.ts
52.94% <0.00%> (-41.18%)
:arrow_down:

packages/rest/src/events/WebhookEvent.ts
40.00% <0.00%> (-40.00%)
:arrow_down:

...rc/controllers/connections/ConnectionController.ts
80.00% <0.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 fd219ba...352e17d. Read the comment docs.

LGTM, only question I have is why you left the createFooRecord() methods in? convenience?

So we can manage the whole record lifecycle (retrieving and the saving/updating/deleting using listeners)


Change the name of the balancer proto service from Msg -> BalancerMsg

This previously was causing problems for typescript proto generation,
because we have Balancer's proto Msg service and gamm's proto Msg service
existing at the same proto import path.
They existed at the same import path, because due to interface serialization
depending on the amino route (which depended on the proto import path),
changing the import path requires a state migration thats a bit cumbersome to
do.

Closes: #1185

For contributor use:

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer

Going to close this as stale for now. Lets update with the fix matt pointed out


Prepare for 7.x release: Update version to 7.1.0, add ChangeLog

Which issue does this PR close?
minor release for 7.1.0
Rationale for this change

What changes are included in this PR?
dev/release/update_change_log-all.sh is updated to respect release branch, else it always compare difference from latest master
However, it still includes issues that are closed between the tags, so I have to manually fix it at 6d84c51034be3f13c62eb5e3a0f61211c1b0ec2d
Are there any user-facing changes?

@alamb do we think we still want to fix clippy for maint-* branch?

@alamb do we think we still want to fix clippy for maint-* branch?
I think it would be helpful. I can get a PR up for it

Here is a PR to fix clippy in 7.x branch: https://github.com/apache/arrow-datafusion/pull/2191

Thanks @jychen7  -- shall I start the process to create 7.1.0 ?

@alamb yes, I think it is good to go with 7.1.0. Thanks

Cool -- thanks -- I will prepare a release for a vote - likely tomorrow


TOC creates invalid links when headers have inline images.

Example README: https://github.com/Cockatrice/Cockatrice/blob/dfd5c5e050e2abee5c3e2f7b6b0ae0387ced46e8/README.md

So the root cause of both this issue as well as #69 is that we're not treating headers as Markdown; rather we're treating them as plain text and doing some simple regex transformation on that text.
What we should be doing is parsing headers into something like a syntax tree for Markdown, determining what text is actually displayed vs. hidden per Markdown's rules, and rendering an anchor tag in the ToC accordingly.
/cc @thlorenz


Add support for truncate and normalize to InferenceClient.feature_extraction()

Is your feature request related to a problem? Please describe.
Text-embeddings-inference supports using the truncate and normalize parameters when computing the embeddings.
These parameters cannot be passed to the Inference Endpoint as the feature_extraction method of the InferenceClient does not support passing the truncate and normalize parameters.
Describe the solution you'd like
Add the truncate and normalize parameters to the feature_extraction method of the InferenceClient.

Hi @awinml thank you for your interest and thanks a lot for opening a PR to add this new feature. Unfortunately, this is a duplicate of https://github.com/huggingface/huggingface_hub/pull/1885 from @datavistics. As explained in https://github.com/huggingface/huggingface_hub/pull/1885#issuecomment-1845142394, inference parameters might get updated in the near future to be harmonized between our different APIs (and especially between the existing InferenceAPI and the "new" text-embeddings-inference). In the meantime, I prefer not to add new parameters to InferenceClient as it might costs us more in the future to remove/tweak them. I've shared a snippet of code on how you can still use them with the current implementation of InferenceClient. It's less straightforward but still perfectly valid.


[ENH] Added permutation param to pipelines

Reference Issues/PRs
closes #3439

@aiwalter, I think the idea of a permutation transformer is great!
I do not agree design-wise to attach it to the heterogeneous meta-estimator, or to the pipelines themselves - I think it "has no business there" in the sense of separation of concerns, and would be opposed to overloading functionality in the pipeline classes.
I would suggest a wrapper design, se #3439.

I'd really go about it the following way:

inherit from _DelegatedForecaster
init args are estimator, permute_param_name and permutation
the entire logic sits in __init__, it passes on the parameter permuted, and copies over tags
there is no other method, i.e., only __init__

can I put it into TransformerPipeline? I dont want to create another pipeline just for this 🤔

I'd rather not, since I think (a) that's too much responsibility - keep estimators modular, and (b) we would have to duplicate this for both pipelines. Why not the delegator idea which can be applied to any heteoregenous estimator?

superseded by #3689


Migrate to new Treesitter query API

vim.treesitter.set_query is deprecated. Using vim.treesitter.query.set instead.

As nvim_0.9.1 released today. New 0.8 branch created. Master will only support version 0.9


Upgrade to new vocabulary-styles and vocabulary-fonts

Problem
The vocabulary project has recently been seperated from a monorepo to 3 distinct projects. With this, downstream projects have to be updated to use the new release versions for vocabulary-fonts and vocabulary-styles, both of which are used in this project.
Alternatives
Continue using the original vocabulary package.

Closing this.
Both vocabulary-styles and vocabulary-fonts will be used via CDN in the downstream projects where cc-global-components is used hence this issue has no purpose...my bad.


Require optional fields for specific situations

Is your feature request related to a problem? Please describe.
We make field optional to accommodate flexible use cases, but for some cases we need some things to be required and if users won't comply if they don't know
Describe the solution you'd like
Validator that can make optional fields required for certain situations....
Describe alternatives you've considered
making too many unique classes.

It's a more general problem. E.g. we made a lot of field optional in instrument to accommodate commercial systems, but for the SPIMs we need to make sure they are there. I want to build validators that can require fields for specific situations.


[Feature Request]: Create a launchpad home page

Feature details
It will be great to create a launch pad home page and use that rather than having the default Next.js initial page.
Suggested Solution
It can have the information that we have in the readme.. like:

Purpose
Tech involved
How to get started.
A footer talk about Open SOurce from CreoWis

It should be a very lightweight page without spending too much time on it.
Affected areas
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

I'm interested go give it a try!


feat: as an attestation consumer, I want to be able to check if an address has an attestation using the ERC-1155 owner method

What does this PR do?
Related ticket
Fixes #109
Type of change

[ ] Chore
[ ] Bug fix
[x] New feature
[ ] Documentation update

Check list

[x] Unit tests for any smart contract change
[ ] Contracts and functions are documented

Codecov Report

Merging #227 (9d45e21) into dev (8e0efd6) will decrease coverage by 2.87%.
Report is 3 commits behind head on dev.
The diff coverage is 69.23%.

@@            Coverage Diff             @@
##              dev     #227      +/-   ##
==========================================
- Coverage   96.27%   93.40%   -2.87%
==========================================
  Files          10       11       +1
  Lines         161      182      +21
  Branches       38       41       +3
==========================================
+ Hits          155      170      +15
- Misses          4        8       +4
- Partials        2        4       +2

Files
Coverage Δ

src/AttestationRegistry.sol
91.37% <69.23%> (-6.40%)
:arrow_down:

... and 10 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fix a NullPointerException bug when 'rsdev' property is null.

During static initialization when used, e.g., in Processing, the rsdev property
is not set, and therefore, is null, so a NullPointerException is thrown and hard
to debug. This minimal onliner fixes the issue. Traced back to this via
https://github.com/cansik/realsense-processing/issues/3.

Looks great! Thanks for the PR!


add libcdd-dev key

I'd like to use libcdd-dev but it does not yet exist in rosdep.
I added libcdd-dev key.
https://www.archlinux.jp/packages/community/x86_64/cddlib/
https://packages.debian.org/buster/libcdd-dev
https://src.fedoraproject.org/rpms/cddlib
https://packages.gentoo.org/packages/sci-libs/cddlib
https://packages.ubuntu.com/xenial/libcdd-dev
https://packages.ubuntu.com/bionic/libcdd-dev

CC @k-okada

Thank you !


墨大社区显示语音功能只能跑tensorflow1.15环境，而KAN-TTS用的是pytorch

这是为何？有什么办法用KANTTS load 墨大社区的权重进行本地预测吗？
然后进行ONNX导出？

Hi @jinfagang, did you mean 魔搭社区？ Thanks for your interest in the models we released, actually some of them are in the beta version which is a mixture of TF and pytorch, we will update pure-pytorch models recently. For now, you can have a try on these two models  https://modelscope.cn/models/speech_tts/speech_sambert-hifigan_tts_zh-cn_multisp_pretrain_16k/summary , https://modelscope.cn/models/speech_tts/speech_sambert-hifigan_tts_zh-cn_multisp_pretrain_24k/summary,  they are both supported by KAN-TTS :)

@GinChow thank u for your reply. I wanna using the raw pth weights and load using KANTTS rather than using modelscope, Are there any instructions to do so?

Just clone the pre-trained models via git
# 16k model
git clone -b pretrain http://www.modelscope.cn/speech_tts/speech_sambert-hifigan_tts_zh-cn_multisp_pretrain_16k.git
# 24k model
git clone -b pretrain http://www.modelscope.cn/speech_tts/speech_sambert-hifigan_tts_zh-cn_multisp_pretrain_24k.git

then follow this tutorial https://github.com/alibaba-damo-academy/KAN-TTS/wiki/text_to_wav_manual

Hi @jinfagang , all of the TTS models on ModelScope are now in PyTorch format. You can simply clone the repository and load the models using KAN-TTS.


how wearable devices positioning？

Hello, if you want to achieve not only mobile phone positioning, but also wearable devices (such as bracelets, implanted chips on the helmet) to achieve real-time positioning of personnel (such as 1-5S interval) and motion track query. Can find3 be implemented? What should I do? What do I need to buy? . I saw https://github.com/DatanoiseTV/esp-find3-client, but I am not sure if this is used to solve the problems I described.

Program your wearble devices to something like esp-find3-client.
Disable the learning mode in esp-find3-client and you will get what you want.


Validation Rule - Address is not Unique on the road object

Every time I create a new address populating only base address and road name, the resolution feed link and the change feed link advise that the address is not unique on the road object. This is when the address is unique.
http://<IP_ADDRESS>:8080/aims/api/address/resolutionfeed/4881218
http://<IP_ADDRESS>:8080/aims/api/address/changefeed/4881218
The warning does not appear on the Review queue in the UI.
I am not able to accept the Add. A warning pops up saying Address is not unique on the road object.
The warning is not created if there is an alpha.
If I create a duplicate that really is a duplicate with an alpha two warnings are generated; Address is not unique on the road object and Address is not unique within the suburb. - This is correct functionality.
If I create a duplicate that really is a duplicate with no alpha two warnings are generated; Address is not unique on the road object and Address is not unique within the suburb. - This is correct functionality.

@shane-turk-espatial could you please take a look at this bug from Deb.

There is an update to this. It is not happening everywhere.
Addresses where it has occurred include;
3, 10, 13 Pamela Place, Otumoetai, Tauranga
15, 17, 24 Hillcrest Road, Otumoetai, Tauranga
10 Stratford Place, Otumoetai, Tauranga
It did not occur for;
123 Grange Road, Otumoetai Tauranga
5 Lees Way, Otumoetai, Tauranga
10 Apollo Street, Otumoetai, Tauranga
These three addresses are between the addresses where it is happening. So it's not unique to the locality or meshblock.
I haven't seen it outside of the examples above either, but it does occur every time I create an address on those roads.

I am also getting this error on The Esplanade, Petone, Lower Hutt. 7, 19 and 31.

I have produced the validation warning for each of the examples that you have raised.  I am now investigating.  If there is an updated database function required how do you want this supplied?

@Deb-Jones @SPlanzer

The fnProcessAddress has been altered to include a check for suburb.  Once introduced 13 Pamela Place is not returned as a duplicate.  The tests were performed for Hillcrest Road, and Stratford Place without any issues. In the screenshot (attached), number 3 and 10 already look as though they are proper address and should return duplicates. An update validation function has also been attached.  I understand that this is not as per the current process but it should allow quicker retesting.

Wasn't sure who to assign this to, but I need Shane's bug fix implemented to enable me to test it again.

ready for retest once script has been deployed.

Retested. Error no longer occurring.


Updates to security-azure-log-integration-get-started.md

Minor formatting updates and correcting "Set your Azure Environment" to state the command is run using PowerShell instead of the command prompt.

Hi @wahidsaleemi, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

@wahidsaleemi : Thanks for your contribution to the Azure documentation! The author, @TomShinder, has been notified to review your proposed change.

#Sign-off


Stop unnecessary every-1-hour restart

Fixes #143

I don't think current solution is a good thing, as now we never get new token (which is needed when runner is recreated).
I think IsRegisterable is OK, but it just needs to be called only before creating the new pod where token is actually needed.

I have thought this a bit, so if needed I can make PR about this refresh.

I think #159 solves this better.way

Closing in favor of #159. Thanks for your support @Hi-Fi ☺


config: allow volumes to be in /var/vcap/sys/run

This path is the de-facto location of job sockets. This helps
socket-using releases migrate to BPM without needing to conditionally
move their sockets to /var/vcap/data which can be a pain for consumers.
[finishes #160845685] (fixes #104)

[ ] needs docs
[ ] needs changelog

Should we give jobs a default director in /var/vcap/sys/run (i.e. /var/vcap/sys/run/<job-name>/<process-name>)?
Otherwise nothing immediately wrong with the PR.

We don't tend to give processes individual sub-directories (e.g. in the
ephemeral and persistent disks) but we could add a new config property
called sockets: true. This would do what aram is suggesting and mount the
directory into the process the same as ephemeral_disk and
persistent_disk. Volumes (this change currently) would still be used by
other jobs to gain access to that socket.
On Mon, Oct 1, 2018 at 12:10 PM James Myers<EMAIL_ADDRESS>wrote:

Should we give jobs a default director in /var/vcap/sys/run (i.e.
/var/vcap/sys/run//)?
Otherwise nothing immediately wrong with the PR.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cloudfoundry-incubator/bpm-release/pull/105#issuecomment-426027093,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACXnpo4SgOvbuFo6RcHfrko74O1UpM0ks5ugmipgaJpZM4XAOoe
.

Yeah that makes sense to me. I'm not in love with sockets:. I'll keep noodling on a good name. We don't necessarily need to do that functionality as part of this PR. So LGTM.


Sounds playing when iPhone is in silent mode and setCategory('Ambient')

:beetle: Description
I am trying to play ambient sounds, where they should be muted if the device is in silent mode.
:beetle: What have you tried?
react-native-sounds config is set to below code
:beetle: Please post your code:
import Sound from 'react-native-sound'

const start_final = new Sound('start_final.mp3', Sound.MAIN_BUNDLE)

Sound.setActive(true)
Sound.setCategory('Ambient')
Sound.setMode("Default")

const playStart = () => {
  start_final.play()
}

:bulb: Possible solution
Unknown
Is your issue with...

[x] iOS
[ ] Android
[ ] Windows

Are you using...

[x] React Native CLI (e.g. react-native run-android)
[ ] Expo
[ ] Other: (please specify)

Which versions are you using?

React Native Sound: ^0.11.2
React Native: 0.64.3
iOS: 15.6.1
Android: N/A
Windows: N/A

Does the problem occur on...

[x] Simulator
[x] Device

If your problem is happening on a device, which device?

Device:
iPhone 12

You can handle this by lowering volume :
soundFile.setVolume(0)
like above statement rest thing u can handle by fetching details of device if its mute or not handle this accordingly....

I'm wondering if it is still possible to play sounds when you are on silent mode on iOS? Seems like some features have been deprecated? 🤔
The signature '(value: AVAudioSessionCategory): void' of 'MySound.setCategory' is deprecated.

This will help https://www.youtube.com/watch?v=vVI7ZAZq5e0


fix: allow reference sub-factories in SelfAttribute

BREAKING CHANGE:
AsyncSQLAlchemyFactory.build() now has has to be awaited

It doesn't look related to my changes:
      def finalizer() -> None:
          """
          Cleans up the DB after testing. Must be called as part of the test environment teardown.
          """
          _restore_default()
          loop = _LOOP
          loop._selector = _SELECTOR  # type: ignore
  >       loop.run_until_complete(Tortoise._drop_databases())

@ADR-007 Thanks for PR. Same issue with build_batch() method. Can you please fix this too?

@ADR-007 Thanks for PR. Same issue with the build_batch() method. Can you please fix this too?

Sure, but I'm quite busy now :(

@ADR-007 Thanks for PR. Same issue with build_batch() method. Can you please fix this too?

It should be good now :)


Parse error: """ structHydrators map { _K } """.parse[Term] ... ; expected but [ found

Stack trace attached:
bug2.txt

Fixed in https://github.com/scalameta/scalameta/pull/928.


Feature/improve error handling

Added TimeoutException as a BakerException and convert all akka and cats.effect timeouts to BakerException.TimeoutExceptions.
Added UnexpectedException for if something unexpected happens in bakery. Generates an identifier which can be used to find the error in the bakery logs
Added UnknownBakerException for if an error is provided by bakery which is unknown by the baker client (probably means a newer version of bakery is used than the baker client).

Codecov Report

Merging #1290 (1a194c4) into master (7a674ec) will decrease coverage by 0.04%.
The diff coverage is 81.57%.

@@            Coverage Diff             @@
##           master    #1290      +/-   ##
==========================================
- Coverage   80.53%   80.48%   -0.05%
==========================================
  Files         123      123
  Lines        3986     4007      +21
  Branches      138      134       -4
==========================================
+ Hits         3210     3225      +15
- Misses        776      782       +6

Impacted Files
Coverage Δ

...cala/com/ing/bakery/baker/BakeryExecutorJava.scala
0.00% <0.00%> (ø)

...ain/scala/com/ing/baker/runtime/model/BakerF.scala
37.16% <73.68%> (+4.33%)
:arrow_up:

...n/scala/com/ing/baker/runtime/akka/AkkaBaker.scala
79.59% <100.00%> (+0.42%)
:arrow_up:

...ing/baker/runtime/serialization/JsonDecoders.scala
89.09% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Wrapped token balance

UI testing is required yet.

It should go after PR #542.

UI testing is required yet.

Done!

Supersed by https://github.com/interlay/interbtc-ui/pull/579


Query to tabulate tallies for verification tokens

Query for (from September 1, 2018 to April 30, 2019):

Total number of log-ins for all mentors
Total number of log-ins for all mentees
Average number of log-ins per mentor
Average number of log-ins per mentee
Top 5 number of log-ins for mentors (i.e. Mentor A logged in 16 times, Mentor B logged in 10 times, Mentor C logged in 8 times, etc.)
Top 5 number of log-ins for mentees (i.e. Mentee A logged in 20 times, etc.)

Desired deadline for query results: June 28, 2019

SELECT count(token.date_created),
       email.email,
       bool_and(email.is_mentor) as "is mentor"
FROM public.verification_token token
JOIN public.verification_email email
  ON token.email_id = email.id
  group by email.email
  order by count desc

Here's the query for average visits (change WHERE clause at the end to toggle mentor / not mentor), not counting ourselves
with stats AS
  (SELECT count(token.date_created) AS c,
          email.email,
          bool_and(email.is_mentor) AS "is mentor"
   FROM public.verification_token token
   JOIN public.verification_email email
     ON token.email_id = email.id
   WHERE email.email not in<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>   GROUP BY email.email
   ORDER BY c DESC)
SELECT sum(c)/count(c) AS avg_mentee_logins
FROM stats
WHERE stats."is mentor" = false

Data has been sent
Report is at https://modeanalytics.com/editor/rerere/reports/e97054f87269


I get incorrect results opening zip archives

[X] I have searched the FAQ and the documentation for solutions.
[X] I have searched the issue tracker for similar issues (the closed issues too).
[X] I have searched the Discourse for any errors and solutions.
[X] I can reproduce my issue on the latest commit of Doom Emacs.
[X] I have read How to Debug Issues and found no solution.

What did you expect to happen?
When I open a zip file (or docx, which is also a zip archive), I expect its contents to be displayed.  This works perfectly with emacs -q (no config), and it worked until recently with Doom.
What actually happened?
Now when I open a docx, I see
M Filemode      Length  Date         Time      File
- ----------  --------  -----------  --------  --------
- ----------  --------  -----------  --------  --------
                     0                         0 files

(Same thing happens if I rename it with a zip extension.)
In this case unzip -l r.docx shows
Archive:  r.docx
  Length      Date    Time    Name
---------  ---------- -----   ----
     1830  05-15-2021 18:18   [Content_Types].xml
      724  05-15-2021 18:18   _rels/.rels
      724  05-15-2021 18:18   docProps/app.xml
      595  05-15-2021 18:18   docProps/core.xml
      242  05-15-2021 18:18   docProps/custom.xml
     8125  05-15-2021 18:18   word/document.xml
     2494  05-15-2021 18:18   word/fontTable.xml
     1135  05-15-2021 18:18   word/footnotes.xml
      626  05-15-2021 18:18   word/comments.xml
     2157  05-15-2021 18:18   word/numbering.xml
     1785  05-15-2021 18:18   word/settings.xml
      199  05-15-2021 18:18   word/webSettings.xml
    14555  05-15-2021 18:18   word/styles.xml
     1367  05-15-2021 18:18   word/_rels/document.xml.rels
      301  05-15-2021 18:18   word/_rels/footnotes.xml.rels
     7674  05-15-2021 18:18   word/theme/theme1.xml
---------                     -------
    44533                     16 files

Describe your attempts to resolve the issue
I've tried reinstalling both Doom and emacs (27.2).  I've also tried with an empty config.el.  Same problem.   And I've tried reverting my config to the way it was in November, when I know this worked. Same problem. That all points to some recentish change in Doom, perhaps.
Yet with emacs -q it works fine, so this does seem related somehow to my config.  Messages buffer doesn't reveal anything.
I'm on macOS Catalina, by the way.  But, no major updates in my OS or userspace since the time when this worked.
Steps to reproduce
$ touch a.txt
$ touch b.txt
$ zip -r my.zip a.txt b.txt
$ emacs my.zip

This shows me an empty archive. But:
$ unzip -qq -l my.zip
       12  05-15-2021 13:21   a.txt
        7  05-15-2021 13:21   b.txt

System Information
https://pastebin.com/ajgWQH5t

I cannot reproduce this in vanilla Doom on Emacs 27.1, 27.2 or 28.0.50 on NixOS, Arch Linux or MacOS, out of the box, following your exact steps.
Docx files open as expected:

As do zip files:

Okay, thanks for checking, and feel free to close this.  I will try to track it down.  If you have any ideas for where the problem might lie, let me know.

By bisecting my init.el, I found the culprit: enabling "editorconfig" breaks this, and disabling fixes it again.

It's completely bizarre; I have no idea why editorconfig should affect this.  But I don't need editorconfig, so this is an adequate solution for me.

Odd. Enabling the editorconfig module did not change the behavior for me. What does your root ~/.editorconfig look like? Are there any errors/warnings in *Messages* after you open a docx/zip file? (C-h e to open the *Messages* buffer)

The .editorconfig in the directory containing the docx I'm trying to open is
root = true

[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true

[*.{markdown,md}]
trim_trailing_whitespace = false

[test/*]
insert_final_newline = false
trim_trailing_whitespace = false

Messages just says
Parsing archive file...done.
Parsing archive file...done.
Starting a new list of tags tables

Note that when I copy to the docx to ~/tmp, which does not have an .editorconfig, it works fine.
Aha!  Deleting the line charset = utf-8 fixes the issue.
I don't actually know much about editorconfig, but apparently it's a mistake to use this line if you plan to open binary files in your editor!

Adding this to my .editorconfig seemed to fix things:
[*.{zip,docx}]
charset =
end_of_line =
indent_style =
indent_size =
insert_final_newline =
trim_trailing_whitespace =

Does this fix the issue?
(after! editorconfig
  (add-to-list 'editorconfig-exclude-modes 'archive-mode))

No, that doesn't seem to help.

How about:
(add-to-list 'editorconfig-exclude-regexps "\\.\\(zip\\|docx\\)\\'")

Sorry for the trouble, even with charset = utf-8 I can't reproduce this.

That works!

Alright, I've added these zip/docx/pptx/xlsx extensions to editorconfig-exclude-regexps in 5bed0a6, so I'll consider this resolved. Thanks for bringing it to my attention!

Thanks very much for the fix!  I'm already using it and it works well.


subscription link in mochaJS thankyou email broken

there is an error in the link to subscriptions in the thank you email in MochaJS (might be in all thank you emails tho)
The link received in the email is the wrong token
The email were it happened is in transaction ID542

user tried to log in through the link and it's still not working, it's not a problem in the mail. the token is not working

fix here: https://github.com/OpenCollective/website/pull/221. Will be merged and pushed shortly.


Cannot resize function view when viewing function with long name

When viewing a function with a long name, I cannot resize the function list larger than screenshot below.

Navigating away to a function with shorter name allows me to resize:

This is essentially a dup of #7


cloud-run-manager service account should be for Cloud Build

Problem
In terraform, we are defining a service account "cloud-run-manager". This service account is described as something intended to facilitate Cloud Run deployment & traffic management. However, the only usage of this account is as a Cloud Run service identity for both Website and Content API.
Expectation
We should have one or more customized Cloud Build accounts to ensure each pipeline has minimum permissions.

Use cloud-run-manager for the Cloud Run management pipelines, move it to the Ops project
Pursue #197 and #198 to update the service account identity in our deployed services

This may be out of date; @rogerthatdev to investigate.

This issue requires:

Ensuring the service account names are corrected & clarified
The service account description/comments in Terraform are clear
Clarifying service account usage for Cloud Run services, Cloud Build triggers, and API testing
Updating Cloud Build triggers as needed to use the new service account
Updating Cloud Run service deployment to use the correct service accounts


grpc:x64-uwp build failure

Host Environment

OS: Windows 1909 (OS Build 18363.628)
Compiler: VS2019 Version 16.4.5

To Reproduce
Steps to reproduce the behavior:
.\vcpkg install grpc:x64-uwp --recurse
Failure logs
CMake Error at scripts/cmake/vcpkg_fail_port_install.cmake:93 (message):
Target 'UWP' not supported by abseil!
Call Stack (most recent call first):
ports/abseil/portfile.cmake:1 (vcpkg_fail_port_install)
scripts/ports.cmake:90 (include)
Error: Building package abseil:x64-uwp failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: abseil:x64-uwp
Vcpkg version: 2020.02.04-nohash-external
Additional context
Still broken for UWP builds.  Previoiusly reported for gRPC v1.26.

Just noticed this, building .\vcpkg install opencv[contrib]:x64-uwp --recurse , succeeds to build abseil !

Any word on progress?

Progress?

Hi, @Noemata, thanks for posting this issue. The port abseil doesn't support target UWP. And opencv[contrib] doesn't depends on abseil.
.\vcpkg.exe install opencv[contrib]:x64-uwp
Computing installation plan...
Warning: qualifier has changed meaning recently:
   windows
The following packages will be built and installed:
  * libjpeg-turbo[core]:x64-uwp
  * liblzma[core]:x64-uwp
  * libpng[core]:x64-uwp
  * libwebp[core,nearlossless,simd,unicode]:x64-uwp
    opencv[contrib,core,dnn,jpeg,opengl,png,tiff,webp]:x64-uwp
  * opencv4[contrib,core,dnn,jpeg,opengl,png,tiff,webp]:x64-uwp
  * opengl[core]:x64-uwp
  * protobuf[core]:x64-uwp
  * tiff[core]:x64-uwp
  * zlib[core]:x64-uwp
Additional packages (*) will be modified to complete this operation.
Starting package 1/10: liblzma:x64-uwp
Building package liblzma[core]:x64-uwp...

So I guess the question then is why the uwp build of gRPC regressed to non-existent?  Previously even an ARM build of gRPC was supported for UWP.  What happened?  gRPC has become an essential library given Microsoft is recommending it for many use cases in place of Microsoft equivalent technology that is being deprecated.  Please get this to build!  It's critically important.

Due to grpc update to version 1.27.1, it adds new dependency adseil, adseil doesn't suport target UWP. The related PR: #9963. If you want build grpc on UWP, you can modify grpc to verison 1.26.0 and rebuild it.

There is a v1.27.1 gRPC nuget package for UWP.  It builds for both Debug and Release, except the Release build crashes.  The debug build is working.  So it must be possible to create a UWP version of gRPC.  Also, there is no obvious reason abseil couldn't be compiled for UWP since it is mostly a set of algorithms with no system specific code in the library ....  I just spent 10 minutes getting abseil to compile under UWP.  It was trivial to get it to compile.  I would sort this out, but I don't know vcpkg well enough to do this quickly.  Please address the abseil compile issue so gRPC can target UWP.  Shouldn't take more than 10 minutes if all that's wrong is incorporating abseil.

Here is a screenshot of my vcpkg packages folder:

As you can see abseil was built for uwp.  So there is no reason this can't be done for gRPC.

If I can do this for one library without much expertise, surely the team working on vcpkg can sort this out!  All it takes is more than a trivial effort.  Yes, I too was able to easily spot the !uwp exclusion in the gRPC build setup.  That was not the problem!!!

@Noemata, PR https://github.com/microsoft/vcpkg/pull/10301 has add abseil to support uwp, so this issue should be solved. Please get vcpkg latest and try again.


Migrate sorting algorithms

I've moved over the rest of the sorting algorithms. The only anomaly (intentional anomaly, anyway) is that radix sort only sorts on positive integers, so I've left off the unit tests for now. I can add an issue to update the algorithm (using something like this).

@alxmjo I had added some review comments yesterday but had forgotten to submit the review, and when I saw the open tab in my browser right now and finally submitted, only then did I see that the changes have already been merged.
I'll create a new issue to fix these changes later on.

OK. I'm almost done migrating the remaining data structures. I can make these changes when I'm done with that.

These fixes are implemented in #253.


offset duplicated

Hi everybody:
I have tried the following text in the DBpedia SpotLight demo.
"Artaxerxes III was succeeded by Artaxerxes IV Arses”
I get the following strange result.
"Artaxerxes III was succeeded by Artaxerxes IV ArsesArtaxerxes IV ArsesArtaxerxes IV Arses, who before he could act was also poisoned"
If I make an API call, I get two different entities identified in the same offset 32:
@URI-> http://dbpedia.org/resource/Arses_of_Persia
@surfaceForm-> Artaxerxes IV Arses
@offset-> 32
and
@URI-> http://dbpedia.org/resource/Artaxerxes_III
@surfaceForm-> Artaxerxes
@offset-> 32
May be this is a bug? or is there an explanation I don't get?

Same here, I using the input
host, BBC Wildlife Specials
and then I have the result
host, BBC Wildlife SpecialsBBC Wildlife SpecialsBBC Wildlife Specials
This includes the following entities:

http://dbpedia.org/resource/BBC_Wildlife_Specials
http://dbpedia.org/resource/BBC

However, I would like to obtain the longest match only, which should be BBC Wildlife Specials. If this possible?
This happens in the demo page  as well as in the API used through the docker container.


Added multiline_wait configuration key

As was described at https://github.com/josegonzalez/beaver/issues/209 , I added multiline_wait configuration key with default value of 1 second (since this is what it currently is in the beaver).
I am not sure if it's completely correct but it works for me. Let me know if this change is sane.
Thank you!

Has this been merged to master yet?  Can't seem to see the changes in master.

Obviously not, given that the PR is still open.

Needs to be added to tail.py as well.

Closing due to inactivity. Feel free to reopen!


Settings refactor, step one #755

LGTM, but we need to check it staging before merge, so i'm waiting for that with final approval.


shim fs.access() and fs.accessSync()

added by io.js

https://github.com/sindresorhus/fs-access

@dead-horse might as well add it here :) https://github.com/normalize/mz/pull/15

it is not completed yet? only check F_OK now

Yes, it is not complete, but @sindresorhus seems to be making a few "ponyfills", so may be useful to contribute to that module and then mz can use it :)

Can this be closed since mz doesn't test Node versions below v4?


On the deployed sites robots.txt and sitemap.xml are served under the /storage path

Prerequisites

[x] I've searched for existing issues

Describe the bug
It is expected that the robots.txt and sitemap.xml are served from the root of the site like https://accessibilityexchange.ca/robots.txt; however they are accessibly only through the storage path like https://accessibilityexchange.ca/storage/robots.txt.
To Reproduce
Steps to reproduce the behavior:

Go to https://accessibilityexchange.ca/robots.txt
Notice the 404 error
Go to https://accessibilityexchange.ca/storage/robots.txt
See the contents of the robots.txt file

Expected behavior
The robots and sitemap files should be served from the root of the site.

It looks like the issue on the deployed site is because the public disk actually stores to the \storage directory and is configured to expose this at env('APP_URL').'/storage'. I'm not sure why locally it also exposes it off the root, but maybe there is something in Herd or other local environment configuration that is handling this.

@jobara I'm wondering if this solution is necessary. It looks like you can create links?
https://laravel.com/docs/10.x/filesystem#the-public-disk

is php artisan storage:link being run on production and local environments?


Replace QR Code PNG with SVG

Trello: https://trello.com/c/tnjBnZ7j/77-2sv-qr-code-is-not-responsive-and-generates-a-content-security-policy-report
This replaces the PNG QR code on the 2SV setup page with an SVG. This has the following benefits:

It removes the use of a data: URL which was throwing a console warning due to the content security policy provided by the govuk_app_config gem[1]
It allows the QR code to be displayed in the development environment (the PNG image data URL was previously blocked due to 1.)
It makes the QR code responsive to the screen width

I've enabled the use_path option in the call to as_svg to reduce the size of the generated SVG code. The viewbox option makes the SVG responsive to its container width.
[1] https://github.com/alphagov/govuk_app_config/blob/main/lib/govuk_app_config/govuk_content_security_policy.rb#L46
Before

After

It looks as if almost all modern browsers have basic support for SVGs, but it might be worth cross-referencing the "Can I use" matrix with any list we have of browsers we're supposed to support, e.g. note 3 on that page mentions a problem with SVG scaling in IE9-11 & Edge that might be worth investigating further.

The developer docs suggest that browser support for publishing apps should be based on analysis of the browsers used by users as per Google Analytics.
Checking GA for Signon I see Edge (41.17%), Chrome (39.47%), Android Browser (10.70%), Safari (5.17%), Firefox (1.57%), and Internet Explorer 11 (1.03%) account for over 99% of browers used.
The caniuse matrix suggests that there may be issues scaling SVGs on Edge and IE11 so I checked those using a Windows 10 environment on Browserstack. Edge scales the SVG correctly, while IE11 doesn't scale the SVG

However, I think the SVG is still usable and not really any worse than the PNG presented currently and as it accounts for only 1% of users, I think it should be ok as-is.

I wonder if it might be better to have a bit more whitespace between the QR code and the details element immediately below it - it looks a bit "tight" at the moment. One possibly related thing I wondered was should other bits of the page be wrapped in divs with the "govuk-grid-row" CSS class or is it legit to use it as a one-off here?

Similarly I wonder if it might be better to have a bit more whitespace to the left and right of the QR code - it currently looks a bit "tight" on narrow screened devices.

I've added 5px of offset/padding to the generated SVG in 97591799e5 to address this.

I think the CSP issue actually appears as an "error" (as opposed to a "warning") in the console in production. However, the reason the error doesn't actually cause a problem for users is that the CSP production environments is set to "report-only" mode, i.e. the error is sent to a reporting endpoint, it doesn't actually break the image. I think it might be worth clarifying that in the PR description. It might be worth linking to the GOV.UK CSP History which explains how we're currently using "report-only" mode, but we are trying to move to "enforcement" mode. The change in this PR will be a small step in that direction.

I'll improve the commit message to clarify when I squash, rebase and merge. Thanks!

I'm going to squash the commits I introduced to address @floehopper's feedback, rebase on main and merge.


Fix compile error when using test_ukvm.sh

Moved extern "C" to correct location. Otherwise, when executing ./test_ukvm.sh the following compile error is generated:
includeos/src/service_name.cpp:24:8: error: expected unqualified-id before string constant
 extern "C"
        ^

Can one of the admins verify this patch with one of the following commands:

"jenkins test please" for a one time test run
"ok to test" to accept latest and future commits on this pull request for testing
"add to whitelist" to add the author to the whitelist

ok to test

Can someone tell me if this is a sporadic?

Hi @mhk, our Jenkins guru par excellence, @mnordsletten, is investigating.

We do indeed have a pretty sporadic failure rate at the moment. Improvements are in the works.
I got this PR to pass in the end 👍