FanEntityFeature.TURN_OFF / TURN_ON implementation missing

Good morning, while scrolling through my ha logs I noticed the following warning:
Entity None (<class 'custom_components.dyson_local.fan.DysonPureCoolLinkEntity'>) does not set FanEntityFeature.TURN_OFF but implements the turn_off method. Please create a bug report at https://github.com/shenxn/ha-dyson/issues
Entity None (<class 'custom_components.dyson_local.fan.DysonPureCoolLinkEntity'>) does not set FanEntityFeature.TURN_ON but implements the turn_on method. Please create a bug report at https://github.com/shenxn/ha-dyson/issues
Not sure how serious this is since it does not seem to affect the functionality of how I use your integration, but since it tells me to create a bug report I thought I might as well. Thanks!

I'd like to point you in this direction: https://github.com/libdyson-wg/ha-dyson
More information is in #185 if you'd like to know the history.


Save files to MongoDB from file transfer

Create endpoint that handles saving and retrieval of files to MongoDB.

@maksnowak @Depermitto @Duszke333 @msadlej
Model of data saved to MongoDB should look something like that?
type File struct {
--
ID primitive.ObjectID `bson:"_id"`
Name string
OwnerId string `bson:"user_id"`
Tags []string
Data []byte
}

Where Data are bytes encrypted by encryption service

@maksnowak @Depermitto @Duszke333 @msadlej
Model of data saved to MongoDB should look something like that?

type File struct {

--

ID primitive.ObjectID `bson:"_id"`

Name string

OwnerId string `bson:"user_id"`

Tags []string

Data []byte

}

Where Data are bytes encrypted by encryption service

I think so, maybe add an additional field for people who have access to the file (besides the owner)
@Duszke333 @Depermitto @msadlej thoughts?

@maksnowak @Depermitto @Duszke333 @msadlej Model of data saved to MongoDB should look something like that?
type File struct {
--
ID primitive.ObjectID `bson:"_id"`
Name string
OwnerId string `bson:"user_id"`
Tags []string
Data []byte
}

Where Data are bytes encrypted by encryption service

Looks good to me, maybe we could improve consistency with the naming of ID/Id?

Updated file struct:
type File struct {
--
FileID primitive.ObjectID `json:"id" "bson:"_id"`
FileName string `json:"file_name" "bson:"fileName"`
UserID string `json:"user_id" bson:"userID"`
Tags []string `json:"tags" bson:"tags"`
Data []byte `json:"data" bson:"data"`
HasAccess []string `json:"has_access" "bson:"hasAccess"` // List of user IDs
}

In the encryption service i will add support for basic CRUD operations on these fields via REST endpoints.

LGTM


Update: Dashboard widgets - fetch by layout order and limit concurrency

Description
Use ember-concurrency tasks to enqueue widgets requests by order in layout and add an option to limit concurrency.
Cancel running or enqueued tasks when leaving the route.
License
I confirm that this contribution is made under an MIT license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Do we have a test that shows it succeeds in fetching and advancing to the next request?

yeah line 119

Do we have a test that shows it succeeds in fetching and advancing to the next request?

yeah line 119

👍 I read it before widgetsRequestsMaxConcurrency: 2 was in config and was still making that assumption, thanks for pointing it out

If we aren't able to add that test today. let's go ahead and merge this.


Mock up search results for ontology term search

The point of the ontology driven search is to find cell type cards, not to find ontology terms.
Proposed behaviour of lexical search results:
If the hit is an ontology term corresponding to a cell type card, then that card is returned
If the hit is an ontology term for a class that groups cell type cards, then a results page of all subsumed cell type cards should be returned - with ontology term details in the side bar (as for cell type card pages).  results return should be identical to faceted search.
The aim of this ticket is to mock up a search results page for an ontology term.
Query to use for mockup
MATCH (c:Class)<-[:SUBCLASSOF]-(bds_class:Class)-[:has_exemplar]->(i:Individual)
WHERE label = '<some label in here>'
RETURN bds_class.label, i.cell_set_preferred_alias,
 i.cell_set_additional_aliases, labels(bds_class)

(@shawntanzk  - return might not be quite right for what you're doing for faceted search - likely needs synonyms. Please update.)

Stretch goal.

Is this what you mean @dosumis
MATCH (c:Class)<-[:SUBCLASSOF]-(bds_class:Class)-[:has_exemplar]->(i:Individual)
WHERE c.label = 'L5 ET primary motor cortex glutamatergic neuron (Mus musculus)'
RETURN bds_class.label, i.has_exact_synonym, i.cell_set_preferred_alias, i.cell_set_additional_aliases, labels(bds_class)

see mockup: https://www.figma.com/file/WhKGRN9tDEa8ScpLeZEHaB/Workshop-Mockups?node-id=0%3A1

Just realised that L5 ET is not a great example as it has a cell type card.  Sorry!
A MET type that cuts across the taxonomy would be better.   Any ideas?

Just look through, those that cut the taxonomy, like Large CCK basket cell, have not been added to CL/our ontology.
Noticed that L5 T Martinotti is problematic too - need to double check this, will make a ticket.
Happy to do any MET type, perhaps non-MY projecting keeping with the cell type cards? It doesnt cut across the taxonomy but has the same idea?

Added non-medulla ET (easy to mock up since everything was there anyway) - think we can show all 3 as examples (searching for leaf node, searching for parent class, searching for MET type)

oh wait take it back, if search for parent type that happens to be a cell type card, the cell type card would show up - maybe we dont show that one

It is in CL though - so kinda counts. But perhaps better to have an example that groups more.

can do a big grouping like PVALB?

Pvalb could be good.  Or perhaps just do Martinotti?

Looks nicely cross-cutting with some gaps

Easy to present along with dendrogram to tell a clear story

Although might look redundant with tags.

worry with L5 T martinotti: https://github.com/obophenotype/brain_data_standards_ontologies/issues/129


[INLONG-2144] InlongDataProxy recover TDMsg1 protocol of TDSDKSource and MetaSink

Title Name: [INLONG-2144][Inlong-DataProxy] InlongDataProxy recover TDMsg1 protocol of TDSDKSource and MetaSink
Fixes #2144
Motivation
Explain here the context, and why you're making that change. What is the problem you're trying to solve.
Modifications
Describe the modifications you've done.
Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

Codecov Report

Merging #2145 (9b8c0d4) into master (57df9a2) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 9b8c0d4 differs from pull request most recent head ed6a022. Consider uploading reports for the commit ed6a022 to get more accurate results

@@            Coverage Diff            @@
##             master    #2145   +/-   ##
=========================================
  Coverage     12.28%   12.28%
  Complexity     1157     1157
=========================================
  Files           413      413
  Lines         35215    35215
  Branches       5542     5542
=========================================
  Hits           4325     4325
  Misses        30119    30119
  Partials        771      771

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 57df9a2...ed6a022. Read the comment docs.


Update miner execution

update imports
add typing
fix miner execution
add setting of logging level
update logging
update uids sampling
fix BaseValidatorNeuron.set_weights function
update cybertensor's library version
update from github.com/opentensor/bittensor-subnet-template up to the last commit github.com/opentensor/bittensor-subnet-template/commit/332a4177b6ad85fcf421600758618d9bc4a8b207:

move subnet links from subnet_links.json to subnet_links.py
remove weights setting for miners
remove what_are_subnets.md

@Snedashkovsky need to rollback removing of weights set for miners


MD051: Add support for custom heading anchor IDs

Many MD parsers allow for custom anchor names on headings as follows:
## Some Section {#name}

With this markup, I can change the heading but keep the anchor name the same and avoid breaking links.
The problem is that MD051 will now flag this as an invalid link:
See [some section](#name)

It would be great if markdownlint could capture {#name} as the heading ID to avoid this false positive.
(Although some MD parsers also allow you to use this syntax to add IDs on other elements, I believe headings are the most common and would be a great starting point to add this support. Then if there's demand, perhaps add support for custom IDs on other elements such as images or other arbitrary elements.)

https://github.com/DavidAnson/markdownlint/blob/main/doc/ReleaseProcess.md


PF2e Perception module compatability

can you check the compatibility with this module?

Can you give me a link to the module you are talking about?


feat(cli): add frontend dynamic plugins base build config

Changes

add frontend dynamic plugins build configuration
upgrade @backstage/backend-common to LTS, required to fix issues with conflicting nested dependencies
add root tsconfig.json as a requirement of the latest cli

cc @tumido
Closes #726

The app-next and dynamic plugin will be removed before merging.


feat<EMAIL_ADDRESS>

This adds support for<EMAIL_ADDRESS>which is effectively just renamed https://github.com/WebAssembly/wasi-messaging/commit/4ee59bb881f7a8675fbb3ae7ca5d5d586ab88657
Tested with a newly-added<EMAIL_ADDRESS>example manually
Note, that wadm, wash or something in-between does not support incoming-handler interface names for links, but that does not really matter, because these interface names do not appear to ever really be used by providers
Note: binary providers are expected to use<EMAIL_ADDRESS>for the time being

To make sure we're on the same page: implementation is not tightly coupled to NATS.io, it's fully generic

Changed content-type errors to warn logs and filed an issue upstream https://github.com/WebAssembly/wasi-messaging/issues/30
Also filed this PR https://github.com/WebAssembly/wasi-messaging/pull/29 to avoid having to trap when content-type is not supported


proposal: go 2: a simpler approach to generics with "concrete" interfaces

A summary is available at the end for the less patient of you!
The problem with contracts
Much constructive criticism has already been expressed against contracts. Here is a brief list of good arguments I've read:

It does not provide a clean, systematic way of indicating which operations are allowed on a type. For example, two different contracts may describe the same idea in two very different ways (taken from this blog post):
contract comparable(t T) {
    t == t
}

contract mapkey(t T) {
    var _ map[t]bool
}

They can also describe very different things even though they look similar. Consider this example:
contract add(t T) {
    t = t + t
}

contract mult(t T) {
    t = t * t
}

It looks like both would refer to numeric types, right? Not quite: add is also compatible with string.

But there is more: mult implicitly allow operations that would most likely not produce a compilation error:
func Halve(type T mult) (a T) T {
    return a / 2
}

The whole point of contracts was that you state what you can do with a type outside of the function body. Will programmers be thorough enough in explicitly listing all the operations they need if some can be omitted? I don't think so.

On the contrary, it can and will end up as a game of one-lining constraints, akin to the (c = getchar()) != EOF && isalpha(c) ? toupper(c) : '\0' follies in C and C++:
contract pointer(t T) {
    t == nil
}

contract magic(t T) {
    (t + t) == string(t)
}

contract impossible(t T, s S) {
    t == ((s + t) == t)
}

Is it clear that pointer could be a slice or a map as well? How about magic, what could it even be? Will the compiler produce an error if a contract is impossible? The horrors of real-world code should not be underestimated.

A contract exposes the internals of types to the users: it can be both exported and require a given type to be implemented in some way only, which is for example a huge step back from the decision of leaving fields out of interfaces.

A substantial amount of the standard library and existing code from the outside world may end up being rewritten with contracts to only mimic what was done with interfaces until now, leading to projects with a random mixture of contracts and interfaces depending on each contributor's habit on the matter.

It is overall too clever, as formulated by Chris Siebenmann. He also adds:

Go contracts do not seem designed to be read by anything but the compiler. This is a mistake; computer languages are in large part about communicating with other people, including your future self, not with the computer.

Operators can only be used on the very small set of primitive types anyway: the amount of distinct, meaningful contracts that can be written with operators is thus very small. It means that in general, a contract will describe the methods and fields of a composite type, making it a lot like an extended, generic version of interfaces.

This is exactly what I am going to present next: an extended, generic version of interfaces.
A case study
Let's say we want to write a generic Min() function. It should probably look like this:
func Min(a T, b T) T {
    if a.Less(b) {
        return a
    }
    return b
}

It is ambiguous whether T refers to an existing type, or any type. We still want the compiler to report errors when mistakenly using non-existent types, so at least we need a way to indicate that T is a parameter as well. The syntax proposed in the current draft design is almost just fine:
func Min(T type) (a T, b T) T {
    ...
}

See how the position of type differs from the draft: by switching it at the end, it now looks like a function definition — which it is, since we use generic functions just like functions on types:
// More on that import later
import "types"

var minInt = Min(types.Int)

It eliminates the cognitive burden of using Min(types.Int) just like a function, but defining it a different way. In short, it just reads better.
But this is not all, it also enables two possible additions to the language in the future that would then fit naturally:

"Pseudo-"partial applications, by extending the idea of "chaining" parameter lists to build higher order functions:
func SumOfThree(a int) (b int) (c int) int {
    return a + b + c
}

f := SumOfThree(2)  // f is of type func(int)(int) int
g := f(3)           // g is of type func(int) int
fmt.Println(g(4))   // Prints 9

I say "pseudo-"partial because technically this wouldn't be allowed:
func SumOfThree(a, b, c int) int {
    return a + b + c
}

fmt.Println(SumOfThree(2)(3)(4)) // WRONG

That is, Go wouldn't have full currying. Which is good, as forgetting an argument would raise an error at compilation, instead of silently producing a partial application.

type reads a lot like the "type" of T. Why not add new "types" of types, then? They could be used to introduce new semantics on type parameters:
// A possible solution to our example, see further down
func Min(T ordered) (a T, b T) T {
    ...
}

In my opinion, it would look much better than the current draft design:
func Min(type T ordered) (a T, b T) T {
    ...
}

Note that in the current draft design ordered would be a contract, which means that we could very well still add contracts as "types" of types in the future if what I suggest next is implemented.

Now back to our example. We want to indicate that T should have a method called Less(), which takes an argument of type T and returns a boolean. If T was known, then what we would need is exactly an interface; it makes perfect sense to first attempt to extend the semantics of interface to something that works for any T. By reusing the same syntax, we could try:
type Ordered(T type) interface {
    Less(T) bool
}

func Min(T type) (a Ordered(T), b T) T {
    if a.Less(b) {
        // Wait a minute...
        return a
    }
    return b
}

This is actually wrong: we don't know that a is of type T! What I suggest is extremely simple... Embed T to indicate that Ordered(T) should behave like T:
type Ordered(T type) interface {
    T
    Less(T) bool
}

It only makes sense when you think of it with other interfaces:
type WithClose(T type) interface {
    T
    Close() error
}

type ReadCloser WithClose(io.Reader)

I call this a "concrete" interface (hence the title): it specifically refers to a given type in contrast with "normal" interfaces, referring to any type matching their description.
I feel that a number of points need to be addressed before continuing any further:

Writing it differently, such as:
type Ordered(T type) interface {
    T Less(T) bool
}

much like how it is suggested for contracts would not only look weird, but would also become unnecessarily repetitive, and would allow to write impossible declarations:
type Numbers(T, S type) interface {
    T One()
    T Two()
    T Three()
    S Four()    // IMPOSSIBLE
}

The last case is possible if, and only if T == S which has no reason to occur in real-life situations and most probably is a bug, so it should raise an error at compilation anyway. The proposed syntax avoids this error, and repetitions as well.

For the same reason, the following code:
type Union(T, S type) interface {
    T
    S
    ...
}

should produce an error at compilation since, in general, T != S. That means a concrete interface must be associated with exactly one type parameter. If there are zero associated types, then basically it is a normal generic interface. If there are more than one, then it is an error.

If we have, for example:
import "net/http"

type WithGet(T type) interface {
    T
    Get(string) (*http.Response, error)
}

var c WithGet(http.Client)

What is the type of c? Of course, it should be http.Client. That means a concrete interface acts like an assertion on type properties at compilation: it takes a type as an argument, and returns it if it corresponds to the specifications, otherwise the compilation fails. This is why I strongly advise naming concrete interfaces with the prefix With to indicate that a particular property is expected. Our initial example would be better rewritten as:
type WithOrder(T type) interface {
    T
    Less(T) bool
}

func Min(T type) (a, b WithOrder(T)) T {
    if a.Less(b) {
        return a
    }
    return b
}

Embedding other concrete interfaces should be possible, but recursion on the associated type forbidden:
type WithOrder(T type) interface {
    T
    Less(T) bool
}

type WithClose(T type) interface {
    T
    Close() error
}

type WithOrderAndClose(T type) interface {
    // As it embeds concrete interfaces associated with the same
    // type T, embedding T is not required
    WithOrder(T)
    WithClose(T)
}

type Recursion(T type) interface {
    T
    Recursion(T) // IMPOSSIBLE
}

Note that embedding concrete interfaces is equivalent to chaining their application:
var x WithOrderAndClose(SomeType)

// Equivalent
var x WithOrder(WithClose(SomeType))

A first major drawback is that you can't specify fields with an interface, which is a good design decision in my opinion. I assume that the initial philosophy was that when exporting an API, only how you can interact with an object matters, not its inner working. Contracts, on the other hand, allow exposing the internals to the users, and may restrict how a structure is implemented.
If yet, such a possibility is desired, we could naively think at first of some way using generic structures. Let's say, for a new example, that we want to write a generic ValueOf() function that takes a structure with a Value field, and return its value:
func ValueOf(T, S type) (x T) S {
    return x.Value
}

Following the same logic than with interfaces, we would think of something similar to this:
type WithValue(T, S type) struct {
    T
    Value S
}

type Integer struct {
    Value int
}

func ValueOf(T, S type) (x WithValue(T, S)) S {
    return x.Value
}

// Wait a minute...
fmt.Println(ValueOf(Integer, int)(Integer{12))

... This time, WithValue(Integer, int) is not the same type as Integer! Indeed, it has an extra Integer field representing the embedded structure.
At this point, there are two solutions:

Abandon the possibility to specify fields, in accordance to the principle that the internals should not be fiddled with by the outside world

Extend the semantics of concrete interfaces again to indicate which fields are required, with the exception that exporting such an interface, or a function using such an interface is an error at compilation:
// Not exportable
type withValue(T, S type) interface {
    T
    Value S
}

// Not exportable
func valueOf(T, S type) (x withValue(T, S)) S {
    return x.Value
}

I strongly support this second option. Since interfaces containing field requirements cannot be exported, there is good practice to write separate, unexported interfaces containing field requirements only. It would still be very useful inside of a package to indicate constraints, and would prevent exposing the internals of the package when used by someone else.
The second drawback is what probably motivated the idea of contracts in the first place: operators. In our example with Min() I took great care of writing a.Less(b) instead of a < b, and for a very good reason: for as long as Go refuses to implement operator methods (I don't hold an opinion on that), there will be no choice but to write two versions of every function working on both composite and primitive types:
contract ordered(t T) {
    t < t
}

contract withLess(T) {
    T Less(T) bool
}

func Min1(type T ordered) (a T, b T) {
    if a < b {
        return a
    }
    return b
}

func Min2(type T withLess) (a T, b T) {
    if a.Less(b) {
        return a
    }
    return b
}

Whether contracts are implemented or not in the end, code duplication will still occur with primitive types. Since composite types are more frequent than primitive types, a generic function will most likely end up using methods rather than operators; therefore using methods should be preferred. Given this perspective, we should try to find a suitable solution with interfaces one more time, using what the language already permits.
As stated before in the preliminary criticisms of contracts, some operators are implicitly allowed (t * t implies t / t), others don't make sense when used together (for example t && t and t + t), and overall the set of meaningful contracts using operators is very small. An excellent idea brought forward by Matt Sherman, and named by Axel Wagner are "pseudo-interfaces". Instead of adding a way to list which operations are possible, we add a small set of builtin identifiers grouping operators that only make sense together:

Pseudo-interface
Allowed operators

comparable
==, !=

ordered
<, <= > >=

boolean
||, &&, !

bitwise
^, %, &, |, &^, <<, >>

arith
+, -, *, /

concat
+

complex
real(z), imag(z)

nilable
v == nil

pointer
*v

...

As the name suggests, they can be used like interfaces:
type num interface {
    comparable
    ordered
    arith
}

func GreaterThanThree(a num) bool {
    return a > 3
}

A number of derived interfaces could be predeclared as well:

Pseudo-interface
Definition

num
interface { comparable; ordered; arith }

integral
interface { num; bitwise }

...

With a set of sane, predeclared pseudo-interfaces, developers would only need to refer to the standard Go documentation to find out what they mean, instead of tediously trying to guess what a contract implies:
contract num(t T) {
    t == (t - (t * t))  // Is it obvious?
}

A small issue arises when you think about how to write a generic Min() function again. We still need to know what type we're referring to, as ordered in our case is merely an interface. The code would then look like this:
type WithOrder(T type) {
    T
    ordered
}

func Min(T type) (a, b WithOrder(T)) T {
    if a < b {
        return a
    }
    return b
}

Of course, it works. But we'd rather write the function this way:
func Min(T ordered) (a, b T) T {
    if a < b {
        return a
    }
    return b
}

I suggest we might as well just do that: pseudo-interfaces (and them only) can also be used as "types" of types as it was referred to earlier:
func Select(T num, S type) (z T, a S, b S) S {
    if z == 0 {
        return a
    }
    return b
}

At last, we still have the problem that every generic function will have to be written twice: one for the primitive types, one for the composite types. As a convenience, and for performance reasons, I would encourage the introduction of a new "pseudo-"package named types, which provides a number of structures and interfaces wrapping the operations on the primitive types:
package types

type Int struct {
    ...
}

func (i Int) Add(j Int) Int {
    ...
}

func (i Int) Less(j Int) bool {
    ...
}

This way we can write a definitive, generic Min() function that also applies
to integers:
import "types"

fmt.Println(Min(types.Int{5}, types.Int{3}))    // Prints 3

Using dark magic with the compiler, we could natively translate types.Int into int at compilation, avoiding the extra overhead of wrapping everything into an actual structure with methods. The package don't really exist as source code, hence the prefix "pseudo". A number of generic structures could be provided by types as well:
import "types"

var m types.Map(string, int)
m.Set("foo", 5)

fmt.Println(m.Get("foo"))   // Get has signature func(string) (int, bool)
fmt.Println(m.Get("bar"))   // Prints 0 false

If methods from types are assigned (for example f := m.Get) or the types from types are embedded to create substructures, the compiler could fall back to an actual implementation of the structures in pure Go. Since these types would be standard and supposedly widely used, we still may find ways to optimize such situations in the future, to the benefit of everyone.
types could also include concrete interfaces, being the general counterpart of the aforementioned pseudo-interfaces:

Interface
Definition

comparable
==, !=

types.Comparable
interface(T type) { T; Equal(T) bool }

...

That is, if type x is compatible with pseudo-interface p, then type types.X (notice the capital letter) is compatible with concrete interface types.P. This would break the rule of naming concrete interfaces with the prefix With, but at least it is memorable and coherent with everything else. We can write at last:
import "types"

func Min(T type) (a, b types.Ordered(T)) T {
    if a.Less(b) {
        return a
    }
    return b
}

Summary

Invert the syntax to declare type parameters, and make it look like a function declaration. (type T) becomes (T type):
// Can also be written as (K, V type)
func Keys(K type, V type) (m map[K]V) []K {
    ...
}

Exactly one type argument can be embedded to a generic interface, turning it "concrete":
// Name should always start with "With..."
type WithClose(T type) interface {
    T                // Type embedding should go at the top
    Close() error
}

A concrete interface should be read in code as an assertion on a type, returning the type if the assertion succeeds:
type WithAny(T type) interface {
    T
}

var x WithAny(int)   // x has type int
var y WithClose(int) // ERROR! int does not have a Close() method

A normal interface embedding a concrete interface turns into a concrete interface, because of the rule stated above:
type WithReadAndClose(T type) interface {
    WithClose(T)                 // Same as embedding T
    Read([]byte) (int, error)
}

Fields can be specified by an interface, but then the interface cannot be exported:
// Name must start with lower case
type withValue(T, S type) interface {
    T
    Value S
}

A function using an interface specifying fields cannot be exported either:
// Name must start with lower case
func valueOf(T, S type) (x withValue(T, S)) S {
    return x.Value
}

A number of identifiers, called "pseudo-interfaces", are added to access operators: they can be used like interfaces, and group operators together in a meaningful and documented way:
type num interface {
    comparable   // They can be embedded, and start with lower case
    ordered      // ordered is compatible with any type using <, <=, >, >=
    arith
}

func GreaterThanThree(a num) bool {
    return a > 3
}

Pseudo-interfaces can also be used as "types" of types to concisely refer to type parameters on which operators can be used:
// Note how (T type) has changed into (T ordered)
func Min(T ordered) (a, b T) T {
    if a < b {
        return a
    }
    return b
}

A new package named types is added to provide a standard interface to primitive types and ease the writing of generic functions:
import "types"

x, y := types.Int{5}, types.Int{3}
fmt.Println(x.Less(y))               // Prints false

var m types.Map(string, int)
m.Set("foo", 3)
if v, ok := m.Get("foo"); ok {
    fmt.Println(v)                   // Prints 3
}

types exports the composite counterpart of primitve types and pseudo-interfaces by using a capital letter:
import "types"

// types.Ordered(T) requires T to have a method Less(T) bool
func Min(T type) (a, b types.Ordered(T)) T {
    if a.Less(b) {
        return a
    }
    return b
}

The current draft proposal on generic structures is just fine, with the extra care that structures using concrete interfaces specifying fields cannot be exported either:
type Tree(T type) struct {
    Node     T
    Children []*Tree(T)
}

// Not exportable
type valueTree(T, S type) struct {
    Node     withValue(T, S)
    Children []*valueTree(T, S)
}

EDIT. Just to be clear, type Name(T type) keyword { ... } is sort of (but not exactly) syntactic sugar for Name := keyword(T type) { ... }, pretty much how func Name(a Type) { ... } is sort of (but not exactly) syntactic sugar for Name := func(a Type) { ... }. I see no reason to forbid writing things like this:
var x struct(T type) { Value T }(int)

What do you all think?

Disclaimer: I read only summary section, keep that in mind.
Overall this looks really interesting except few things

Making whole interface concrete is a big restriction IMO. Maybe it would be easier to introduce Self pseudo-type to interface declaration and make any method which uses it "concrete". Then, "concrete" methods cannot be used in dynamic context.
I'm not sure about "interface fields" part.

@target-san I'm not exactly sure to understand what you mean, but "concrete" was just a word I came up with to describe the property of a generic interface to be associated to one of its type parameters. How it translates into an actual implementation is still to be worked on. In particular, it would be nice to be able to write type ReadCloser WithClose(io.Reader) and mean it : following a basic substitution rule should produce an interface identical to io.ReadCloser. My goal was to avoid coming up with new keywords, or notions that would cover part of what you can almost already do with interface, so I don't really know about "self pseudo-types".
On the "interface fields" part I anticipated it would be hard to accept. This is why I suggested forbidding to export interfaces using them in order to sort of keep the original spirit of interfaces (which is in my opinion, as I state in my presentation, a good design decision from the original authors). Or, we could still set this aside and maybe make a decision in a later version of Go 2; and be content with generic structures for now. Maybe this would require a deeper analysis of the existing real-world codebase to decide whether it should be added or not.

Your discussion about contracts appears to refer to the earlier draft.  Please take a look at the most recent draft (https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) as it has significant differences.
It would help if you could explain how to implement the Graph/Nodes/Edges idea with your suggested syntax.  Thanks.

@ianlancetaylor
I guess OP's main idea is "why have separate entity for compile-time interfaces?".
@kantbell
On the other hand, unification of interfaces and contracts looks a bit questionable. While they partially "overlap" semantically, they cover different sub-domains of language polymorphism. Such unification will require smth similar to Rust traits, which in turn are more powerful yet more complex than interfaces and traits combined. I doubt core team would pursue such goal.

Overall, I like the ideas in here. Very well thought-out.
T type instead of type T resonates with me.

some operators are implicitly allowed (t * t implies t / t)

This is false. A field only requires two binary operations, conventionally + and *. There are algebraic systems where the inverse operator / either does not exist, or is different enough from scalar division that you would not want to use the / syntax and just use a method, so conceptually, this is not great, even if the pseudo-interfaces part isn't used. I think methods can be implicitly allowed, but I do not like implicit operators.
I personally like the idea of pseudo-interfaces to access operators, but I am skeptical the goteam will ever implement it, as it effectively amounts to operator overloading =D.

I think too much () can be confusing
I propose that the definition of type use <>
Just like:
contract Sequence<type> {
    string
    []byte
}

func IndexByte<T Sequence> (s T, b byte) int {
    for i := 0; i < len(s); i++ {
        if s[i] == b {
            return i
        }
    }
    return -1
}

When call the function just like:
IndexByte<string>("Hello World", 'W')

or
IndexByte("Hello World", 'W')

I personally think it will be very simple to drive up
I have n’t used GO for long time, please forgive my stupid suggestions

@xkortex

T type instead of type T resonates with me.

I think that this is a matter of parsing. For example, consider func Example(type T)(arg T) T. Without type before everything else in that first set of parentheses, the parser can't tell if it's parsing the argument list yet or if there's a generic type list first. This is solvable, but for the most part Go tries to keep the parser simple.
@neroBB

I think too much () can be confusing
I propose that the definition of type use <>

This is talked about in the draft. <T> also introduces parsing problems, such as in f<int>(). Until the parser gets to the >, it can't tell if that's a comparison operator or not. Like the above, it's obviously solvable, as plenty of languages have done it without too many problems, but it also complicates the parser quite a bit.

I think this is headed in the right direction, more than the contracts draft proposal, primarily because interfaces are so clean and sensible, and when we talk about contracts we're really just talking about another dimension of interfaces. To reduce cognitive load it would be nice to just have interfaces with optional syntactic sugar to express the nature of parametric polymorphism.
For so many cases, interfaces can get us so far, in part because they can be self-referential:
package main

import (
	"fmt"
)

type Comp interface {
	Less(Comp) bool
}

type Int struct {
	val int
}

func (i Int) Less(b Int) bool {
	return i.val < b.val
}

type Float struct {
	val float32
}

func (f Float) Less(b Float) bool {
	return f.val < b.val
}

func main() {
	a := Int{5}
	b := Int{7}
	fmt.Println(a.Less(b))

	c := Float{4.3}
	d := Float{3.4}
	fmt.Println(c.Less(d))
}

This gets us so close. The problem is, as discussed, we don't have any hierarchy of primitives to draw on. There is a line in the sand between operators and functions, and it is a costly distinction.
The other half of the problem, obviously, is the generic nature of structures. Some mechanism to set a starting type and then consistently reference it. This proposal doesn't address that, I think, but the contracts proposal attempts to. Again, though, interfaces could be used rather than contracts if there was a way to interact with primitives.
It is likely the that types aspect of this proposal is the most useful and would solve the vast majority of problems around "generics".
It feels like we're so close, and there is a solution somewhere that is simple, and we just need to keep poking around for a bit.

Why doesn't this work? It would go along way towards supporting parametric polymorphism:
package main

import (
	"fmt"
)

type Comp interface {
	Less(Comp) bool
}

type Int struct {
	val int
}

func (i Int) Less(b Int) bool {
	return i.val < b.val
}

type Float struct {
	val float32
}

func (f Float) Less(b Float) bool {
	return f.val < b.val
}

func PrintComp(a, b Comp) {
	fmt.Println(a.Less(b))
}

func main() {
	a := Int{5}
	b := Int{7}
	PrintComp(a, b)

	c := Float{4.3}
	d := Float{3.4}
	PrintComp(c, d)
}

@john-wilkinson This issue is about a specific proposal for a change to Go.  It's not a good place to discuss the language in general.  Please ask your question on golang-nuts or in a forum.  See https://golang.org/wiki/Questions.  Thanks.

@ianlancetaylor Can this be closed now that Go 1.18 includes generics? (and uses some of these ideas)

Thanks, yes, this proposal is no longer applicable.


[ODS-3401] Cycles in claims taxonomy (security metadata for resource claims) causes requests to hang

@mjaksn Just wondering if you might be able to do this more directly by just switching to using a HashSet<T> in the GetResourceClaimLineageForResourceClaim method?
        private IEnumerable<ResourceClaim> GetResourceClaimLineageForResourceClaim(string resourceClaimUri)
        {
            // ==============================
            // Use a HashSet<T> here instead of List<T>?
            // ==============================
            var resourceClaimLineage = new List<ResourceClaim>();

            ResourceClaim resourceClaim;

            try
            {
                resourceClaim = _securityTableGateway.GetResourceClaims()
                    .SingleOrDefault(rc => rc.ClaimName.Equals(resourceClaimUri, StringComparison.OrdinalIgnoreCase));
            }
            catch (InvalidOperationException ex)
            {
                // Use InvalidOperationException wrapper with custom message over InvalidOperationException
                // thrown by Linq to communicate back to caller the problem with the configuration.
                throw new InvalidOperationException($"Multiple resource claims with a claim name of '{resourceClaimUri}' were found in the Ed-Fi API's security configuration. Authorization cannot be performed.", ex);
            }

            if (resourceClaim != null)
            {
                // ==============================
                // OLD: resourceClaimLineage.Add(resourceClaim);
                // NEW:
                if (!resourceClaimLineage.Add(resourceClaim))
                {
                    // Handle cycle problem here
                }
               // ==============================

                if (resourceClaim.ParentResourceClaim != null)
                {
                     resourceClaimLineage.AddRange(GetResourceClaimLineageForResourceClaim(resourceClaim.ParentResourceClaim.ClaimName));
                }
            }
            return resourceClaimLineage;
        }

Also, in looking at the code, I think it's an opportunity to be more efficient and declare the HashSet<T> in the calling method and pass it into the recursive private method, thereby avoiding the creation of multiple HashSets or Lists when this is called.

If I disable the Security cache, this validation fails to find the cycle because it hits the DB on each recursive call (so we get a new instance with a different hash code) so .Contains() always returns false.
Turning off the Security cache isn't a real-world scenario; should we care about this edge case?
"Security": {
    "AbsoluteExpirationMinutes": -1
}


Fix serverless mime import

Information

Type
Breaking change

Fix
No

Todos

[x] Tests
[ ] Coverage
[ ] Example
[ ] Documentation

:tada: This PR is included in version 7.73.3 :tada:
The release is available on:

v7.73.3
GitHub release

Your semantic-release bot :package::rocket:


Release 2.4.0

need to move<EMAIL_ADDRESS>to latest tag before publishing

Coverage increased (+0.1%) to 95.157% when pulling 44ca1588d3817f8142aba0bfd345871f8d563ded on release-2.4.0 into b79e08307f40b299811b333cdd5a8d9833e1a5e4 on release.

Coverage increased (+0.1%) to 95.157% when pulling 44ca1588d3817f8142aba0bfd345871f8d563ded on release-2.4.0 into b79e08307f40b299811b333cdd5a8d9833e1a5e4 on release.

@ljharb should I unpublish this as well? I deprecated but it's literally unusable since I unpublished the broken utils module.

yeah, unpublished in terror at the idea of Greenkeeper, etc., asking folks to upgrade to a dead version.


Custom SQL query for migration

Maybe i'm missing something, but is it possible to execute raw SQL queries during a migration with db: Kysely<any> object ?
I'm trying to run CREATE EXTENSION IF NOT EXISTS "uuid-ossp" for Postgres. Since db: Kysely instance does not have create() method, I can't make this work. Any solutions for this ?

Hey 👋
Try
import { sql } from 'kysely'

await sql`create extension if not exists "uuid-ossp"`.execute(db)


Document recommendations for plugin authors to design URLs

See thread: https://twitter.com/kanedr/status/1320653434895347713

The process and API for making a plugin is great btw. One question I had was the best format for URLs. I've created an url like ///reconcile as a json endpoint, but that could conflict with the row-level URLs. Is there a recommended pattern to use?

https://docs.datasette.io/en/latest/writing_plugins.html#designing-urls-for-your-plugin


POLIO-1625 Chronogram task page: add filters "Period" and "Status"

Chronogram task page: add filters "Period" and "Status".
Related JIRA tickets : POLIO-1625
Print screen

There's bug when selecting status N/A https://github.com/user-attachments/assets/309ede12-c3bf-4126-b2ed-ecaec36c76b6
I think you need to escape the / character or something in that vein

Ah, well spotted!
I think that's a deeper problem with how the router handle params.
Loading a URL with encoded params such as status/N%2FA…
http://localhost:8081/dashboard/polio/chronogram/details/accountId/1/page/1/chronogram_id/5/status/N%2FA

…still triggers a status=N backend query:
/api/polio/chronograms/tasks/?order=start_offset_in_days&page=1&chronogram_id=5&limit=20&status=N&fields=:all

The quick and dirty solution would be to change this param name to remove the / character…


Linux fix for Silk.NET Vulkan Triangle experiment.

Summary of the PR
The validation layers cause a crash on my computer, proposed implementation more similar to https://github.com/KhronosGroup/Vulkan-Samples/blob/96dc1b3d729a743b7bb1caf5b9a631a5e684538b/samples/api/hpp_hello_triangle/hpp_hello_triangle.cpp#L135
Related issues, Discord discussions, or proposals
https://github.com/dotnet/Silk.NET/pull/587
Further Comments

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: usertoroot sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@Perksey Great!
I'll use this opportunity to thank you and the team for making the library of my dreams supported by the .NET foundation.


add pod deletecollection permissions

Necessary for the operand change where UpdateSecret deletes pods to restart workloads now

@bitscuit the changes should be merged to release-3.6 branch

opening another PR for that, but the change should also go into master

yes, all the changes made to release-3.6 will also need to port back to master


Link to purchasing STX for the balances empty state

We'll address this as a part of https://github.com/blockstack/stacks-wallet-web/issues/1232.


Add support for multiple update_schedules / update_type combos for a single ecosystem / directory

Hey, I'd love to be able to trigger and receive PRs for security updates on a live schedule.
and my regular scheduled all updates weekly.
The following is a mock for my config.yml -- obviously fails the validator as a dupe atm :)
version: 1

update_configs:
  - package_manager: "ruby:bundler"
    directory: "/"
    update_schedule: "weekly"
    version_requirement_updates: auto
    allowed_updates:
      - match:
          update_type: "all"

  - package_manager: "javascript"
    directory: "/"
    update_schedule: "weekly"
    version_requirement_updates: auto
    allowed_updates:
      - match:
          update_type: "all"

  - package_manager: "ruby:bundler"
    directory: "/"
    update_schedule: "live"
    version_requirement_updates: auto
    allowed_updates:
      - match:
          update_type: "security"

  - package_manager: "javascript"
    directory: "/"
    update_schedule: "live"
    allowed_updates:
      - match:
          update_type: "security"

This is equally valid in a v2 config world, and is something we're considering for the future.

Would love to have this feature. Hoping to have minor update merging automagicaly if passes the tests and send PR to lead devs for major updates.
Example .yml
version: 2
updates:
  # Minor updates to npm production dependencies daily
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
      time: "06:45"
      timezone: "Europe/Helsinki"
    versioning-strategy: lockfile-only
    labels:
      - "npm minor dependencies"
    allow:
      - dependency-type: "production"

  # Major updates to npm dependencies weekly @tuesday
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "tuesday"
      time: "07:00"
      timezone: "Europe/Helsinki"
    versioning-strategy: increase-if-necessary
    labels:
      - "npm major dependencies"
    reviewers:
      - "foobar/js-lead"

Would love to have this feature. Hoping to have minor update merging automagicaly if passes the tests and send PR to lead devs for major updates.

This is exactly our use case. I would appreciate it very much.

The use case for my team is updating production dependencies weekly and dev dependencies monthly.

I'm also after this functionality.
I'd like to allow the default of 5 PR's for external dependencies, but unlimited PR's for dependencies from my organisation.

Are there any possible workarounds for this? I have the exact same use case as @jamime

I’d like to allow the default of 5 PR’s for external dependencies, but unlimited PR’s for dependencies from my organization.

I'd like to enable security updates for all packages, but version updates for only a handful.

A variant of this was requested in #6957:

Currently, Dependabot does not provide a native way to separate Pull Requests for major, minor, and patch version updates within the same configuration. As a result, users cannot easily distinguish between different update types and may unintentionally merge major version updates that require more extensive testing and refactoring.
I propose the addition of a feature that allows Dependabot to create separate Pull Requests for major, minor, and patch version updates. This would enable users to better manage updates by having dedicated Pull Requests for each update type, making it easier to prioritize and review changes based on their potential impact.
Example:
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      prefix: "Dependabot Minor/Patch"
    versioning-strategy: "increase"
    update-types: ["version-update:semver-minor", "version-update:semver-patch"]

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      prefix: "Dependabot Major"
    versioning-strategy: "increase"
    update-types: ["version-update:semver-major"]

Is this ... possible yet?
To configure more than one schedule for the same ecosystem.
Pinging active contributors:
@brrygrdn
@deivid-rodriguez
@mctofu
@Nishnha
@jakecoffman
This seems like quite a prevalent question, and the issue is still open. Apologies if I've overlooked an obvious answer, but even if the spec is accepted, it'd take me a week to validate if 2 schedules are running or not.
As far as I can tell the documentation on scheduling doesn't cover any advice to the natural scenario of wanting 2 separate schedules. Any feedback will be appreciated

Hey, I'm also interested in this feature so that we can bump our direct / indirect go.mod dependencies on different schedules

I've been looking for this type of differentiation as well. It seems like a very straightforward use case, wanting to receive security updates to all dependencies but version updates limited to scoped dependencies.
Would appreciate it a lot!

Hey I also stumbled upon the same problem, are there any potential workarounds available?
What we would like to achieve (for the same ecosystem = bundler):

patch/minor versions grouped, provide one MR per week
major versions seperately in individual merge requests, for example every day

Another use-case if it helps with prioritization:
A project at Adobe, Spectrum web components, consumes styles from a source project, Spectrum CSS. Though it has a weekly cadence for other dependencies, this base styles library is critical and so the Spectrum web components projects wishes to set up daily version checks to ensure alignment with the latest. This daily check also wants to assign different owners and use distinct labels. It is not ideal to group the styles dependency because those packages are independently versioned and all components might not be updated at the same time.
version: 2
updates:
    - package-ecosystem: 'npm'
      directory: '/'
      schedule:
          interval: 'weekly'
          day: 'tuesday'
          time: '12:00'
          timezone: 'America/Los_Angeles'
      open-pull-requests-limit: 5
      ignore:
          - dependency-name: '@spectrum-css/*'
      reviewers:
          - 'xxx'

    # This sets up a daily check for Spectrum CSS updates
    # focused on the @spectrum-css/* packages
    - package-ecosystem: 'npm'
      directory: '/'
      schedule:
          interval: 'daily'
      allow:
          - dependency-name: '@spectrum-css/*'
      labels: ['xxx']
      assignees:
          - 'xxx'

link

We just hacked our way around this by actively setting target-branch: main for one config, and leaving it unset for the other config (obviously only limited to 2 configs)

Hey, I'm also interested in this feature so that we can bump our direct / indirect go.mod dependencies on different schedules

Same but with Rust/Cargo! (Also, with different grouping, not just schedules.)

We just hacked our way around this by actively setting target-branch: main for one config, and leaving it unset for the other config (obviously only limited to 2 configs)

It appears to also be possible to use target-branch: MAIN (or other uppercase/lowercase combinations) to get more than two configs.

given that hacking the config to fool dependabot into thinking two schedules for the same package manager are unique works perfectly it should be relatively easy to enable first-class support for this, no?
Are there some edge cases here that need to be considered or is it really this easy?

if anyone's looking for further examples, i use the following config to make minor and major updates as soon as they're available, and group patch releases on a monthly basis (cargo)-
version: 2
updates:
  # bump major and minor updates as soon as available
  - package-ecosystem: cargo
    target-branch: main # see https://github.com/dependabot/dependabot-core/issues/1778#issuecomment-1988140219
    directory: /
    schedule:
      interval: daily
    commit-message:
      prefix: chore
      include: scope
    ignore:
      - dependency-name: "*"
        update-types:
          - "version-update:semver-patch"

  # bundle patch updates together on a monthly basis
  - package-ecosystem: cargo
    directory: /
    schedule:
      interval: monthly
    commit-message:
      prefix: chore
      include: scope
    groups:
      patch-updates:
        update-types:
          - patch
    ignore:
      - dependency-name: "*"
        update-types:
          - "version-update:semver-minor"
          - "version-update:semver-major"

  # update github actions as soon as available
  - package-ecosystem: github-actions
    directory: "/"
    schedule:
      interval: daily
    ignore:
      - dependency-name: dtolnay/rust-toolchain
    commit-message:
      prefix: "ci"
      include: "scope"


WHMCS Module update

This is not for requesting support for new games/applications
To do this you should go to https://github.com/CubeCoders/AMPTemplates and first attempt to build a configuration yourself - otherwise you can request a template from this repo.
Feature Request
WHMCS Module update to include new tags and provisioning flags
Feature Information:

Newer features such as tags, provisioning flags and such have become a thing since the WHMCS module was first created. This is a significant feature update from an enterprise perspective, and the WHMCS module, as it comes from CC, should include these new features. It is currently in a basic deployment configuration which whilst it works (with caveats that are to be fixed in the LTS release), it does not in its current state implement the tagging feature.
This should be able to affect the provisioning settings for docker: ie. RAM, CPU,
Affect datastore location - ie tagged datastores, like for SSD's etc,
Affect location for nodes that are tagged with a specific location,
Ability to specify via custom options/configurable options - so you can effectively have a "custom tag" or tags and have AMP look for that during deployment - for example I might have tag 1 2 or 3 as an option when ordering, and have that passed and parsed into AMP when searching for a compatible deployment target.
I confirm:

[x] that I have searched for an existing feature request matching the description.
[x] I've talked about this extensively and it's awesome

This was actually the main reason why my company did not go with AMP as our CP. This is in my opinion baseline functionality that should be implemented as a priority as though the current module works you have little to no control.

This should ideally go in the repo for the module: https://github.com/CubeCoders/WHMCSModule
If you don't have access, let us know.
@MiffedLyric559 The tags functionality for targets and datastores is brand new in 2.4 so the module hasn't had a chance to reflect that yet, but hosts do have access to the source of the module to make changes.

Closing the issue, we're talking with the WHMCS module dev to get this functionality added so the WHMCS module can catch up with the new 2.4 functionality.


regex rewrite

something like this would be good for handling path without showing extensions of the file, i don't know if it already implemented or not but it would be a nice to have feature
[rewrites]
# the leading slash is required, if it is not present, the server will NOT recognize the path
"/home" = { to = "/index.html" } # if a request is made to /home, the server will serve /index.html instead
"/page-2" = "another_page.html" # this is relative to the root directory, so if the root directory is `public`, the server will serve `public/another_page.html` instead
"$1" = "$1.html" # this is a regex rewrite, so if a request is made to /about, the server will serve /about.html instead

Regex rewrites and redirects are planned, not a priority at the moment.


GraphQL Subscription constantly connecting and disconnecting

Hello,
i want to access my GraphQL API with subscriptions. Queries and Mutations just work fine. But when i am trying to connect to my subscription it keeps connecting and disconnecting. My GraphQL server is build with nestjs and it has a console log when someone connects but it doesnt show anything in the logs. However when i do the same thing with Altair everything works just fine. This is my code
import 'package:flutter_dotenv/flutter_dotenv.dart';
import 'package:graphql/client.dart';

GraphQLClient getGraphQlClient({
  String? token,
  bool websocketEndpoint = false,
}) {
  final HttpLink httpLink = HttpLink(
    "https://${dotenv.get("API_BASE_URL")}/graphql",
    defaultHeaders: {
      "Apollo-Require-Preflight": "true",
      "authorization": "Bearer $token"
    },
  );

  final WebSocketLink webSocketLink = WebSocketLink(
    "wss://${dotenv.get("API_BASE_URL")}/graphql",
    subProtocol: GraphQLProtocol.graphqlWs,
    config: SocketClientConfig(
      inactivityTimeout: const Duration(hours: 1),
      autoReconnect: false,
      initialPayload: {
        'authorization': 'Bearer $token',
      },
    ),
  );

  return GraphQLClient(
    link: Link.split(
      (request) => request.isSubscription,
      webSocketLink,
      httpLink,
    ),
    cache: GraphQLCache(),
    defaultPolicies: DefaultPolicies(
      query: Policies(fetch: FetchPolicy.noCache),
      mutate: Policies(fetch: FetchPolicy.noCache),
      subscribe: Policies(fetch: FetchPolicy.noCache),
    ),
  );
}

I/flutter ( 5577): Initialising connection
I/flutter ( 5577): Disconnected from websocket.

 @override
  Stream<QueryResult<Object?>> subscription(
    String options, {
    Map<String, dynamic> variables = const {},
  }) {
    return client.subscribe(
      SubscriptionOptions(
        document: gql(options),
        variables: variables,
      ),
    );
  }

I have tried putting the toket in the headers but nothing changes. I have tried it now for 2 weeks and have tried many things but nothing works till now. Token and request is definitly fine. Thanks in advance

I just added autoreconnecting false so that i dont have constantly this error. Now just one time just as shown above


window is not defined

While using the Slideout package and building a SSR with Gatsby in production,
I get the following error;
WebpackError: ReferenceError: window is not defined
I guess, it is because the module require of window to be defined. In development works fine but while
using an Static Site Generator with Gatsby.js in production it will fails.

@EAdeveloper You should disable SSR for this plugin. here is how:
plugins: [
   //other plugins
    { src: '~/plugins/NonSSR-Plugins.js', ssr: false },
  ],


Fixes #15299 Adding API for container migration.

Fixes #15299
Signed-off-by: Shishir Mahajan<EMAIL_ADDRESS>

This is a personal preference, but I'd rather have #13602 than this api.

@calavera
IIUC, container checkpoint/restore API is completely orthogonal to this API. In checkpoint/restore we will save process state and restore it later. But restore expects that container file system is in same state as it was at the time of checkpoint. checkpoint/restore API does not seem to give any way to migrate the existing container environment. That API will only restore the container processes if underlying container file system is same.
IOW, I think both the APIs might actually be complementary. What if I want to checkpoint a container and restore it on a different host. First I should be able to recreate the container on different host before I can restore it. And to recreate the container I should now how container was created to begin with. (All the options which were used at create/run time)
So if we can come up with a way where container's rootfs can be migrated from one host to another, then checkpoint/restore should be able to use it too and restore the saved state on migrated container.
So to me it looks like that these two functionality are actually complimentary and one is not replacement for other. Am I missing something.

I completely agree that this is complementary to checkpoint/restore.

@shishir-a412ed I would like you to close this until we have a design agreement on #15299. Then you can reopen this. Feel free to link to branches of yours on the issue if you want to share code.

@tiborvass
Agreed. Closing this one, until a design decision is made on #15299 .

Thanks!


Added support for DRF json payload in request

Closes #495

Looks good, thanks for the contribution! Adding the flag to docs would be nice as well.


Unable to open output file

Checklist

[x] Check that you have the GNU C Compiler installed by typing gcc --version into a terminal.
[x] If you don't have the linter package installed, either update to the latest version of linter-gcc or install linter directly with apm install linter.
[x] Ensure that you are using a valid grammar - either C/C++/C++14

Issue (including debugging messages):
Hi.
I'm facing an error message as shown in the image I posted here.
What I'm doing whrong?

Looks like tempfile is giving a path that your user doesn't have access to somehow.
You can check where it is trying to save the temporary file by placing a breakpoint here from within Atom's Developer Tools.

@Arcanemagus you're right. But there is another problem - the -fmax-errors option. This means you are actually using clang because on OSX with XCode installed, the gcc command actually links to clang. To find out more about this, please read this issue here.

Problem solved.
It was the XCode.
Thanks @Arcanemagus !

@LeonardoLeite you mean @hebaishi for the root problem 😉.

I do all the work and get none of the credit heheh :joy:

@hebaishi So sorry for my insensibility, thank you very much! 😁

@Arcanemagus Sorry for I don't know how to do. I found the code and added a line code: console.log(filename);
but there is nothing output.
Could you show some detail ?
Thanks a lot!

@Arcanemagus Sorry for I don't know how to do. I found the code and added a line code: console.log(filename);
but there is nothing output.
Could you show some detail ?
Thanks a lot!

If you guys fail to link the gcc in Bash,
you could directly copy the directory to the origin folder.


Fix/survey summary

Description

Modified the survey summary page to match the rest of the app styles
Changes

-Deleted background questions summary view
-Changed the style of the indicator questions summary list to match the surveys list
-Deleted some unnecessary code
Screenshots

Tests

This code has been tested in the following ways:

Tasks:

[X] Logged in to the application
[X] Fill out a snapshot for a new family
[ ] Fill out a snapshot for an existing family
[ ] Fill out priorities for a snapshot
[ ] View a family and it's priorities

API Level:

[X] API Level 19
[ ] API Level 22
[X] API Level 25

Screen Size:

[ ] 7" screen size
[X] 8" screen size
[X] 10" screen size

Couldn't text on 7" because I don't have a 7" emulator with play services

Definitely looks a lot better than before, but the colors don't quite meet our style guide. (In fact, the survey selection page also doesn't match our style guide. I realize you just used that as a point of reference)
Take a look at the mock for the survey selection page.
I made this quickly to show you what i mean. We should also move away from the nonstandard next/previous buttons.

Also it's not using the correct indicator names (#154)

Can you file the cards with indicator.getTitle() (e.g. Entertainment And Recreation) instead of indicator.getName() (e.g. entertainmentAndRecreation)? I know that it was like that before, but it seems like only a one line change and would make it look better IMO

@krconv i think she updated that

@melokda Your changes are great, but unfortunately the code that you built upon is architected terribly. There's an adapter in a view component, for instance. And there's a ton of code that does absolutely nothing now.
For example, on resume has this whole function that creates a list of names for some unknown reason and then dumps it all to the view and gets the adapter from the view and then adds a callback to the adapter within the view.
Not sure why it was architected like that in the first place, but it's a big problem. Personally I can't approve it until that's updated, but if someone else (like @krconv) disagrees then it's fine by me.

I'm ok with approving as long as this works and new issues aren't introduced; I think re-architecture is out of the scope of this problem

@bhylak @krconv Can someone please look at my changes and review or give me comments?


add cilium helper functions to the list of monitored helpers.

Tracked here: https://github.com/sdsen/opened_transformation/issues/1

@sdsen This is done right..Can we close?


PR for many Old Rebase Required PR's

Issue Reference
This PR addresses the Issue : Fixes #7 #15 #196 #506 #548
Summarize
All the above PR's mentioned required a rebase and thus I have made all those into a single one. Please check the same and approve it as well as close the other PR's mentioned above.

For ease of those who are checking:
mainapp/models.py
One Typo corrected and added check for 10 digit mobile verification
mainapp/templates/mainapp/camp_details.html
One Typo corrected
mainapp/views.py
A new line is removed
static/css/style.css
Updated styles to hold columns in screen
templates/home.html
Add Google Maps Relief Resources Page Link: #500

#7
is a duplicate of #93. The issue is currently discussed at #93.
#15
All the changes have been merged as of now except in the verbose_name part. Check #15.

As @jilvin told, I have updated the PR to update only select Fixes only.
Please check.

Except for mobile number verification, all the rest are just typo's
Please check @vigneshhari @vrthra @biswaz @shameelsadaka @ashwinrajeev and merge

Tested.


randomly exec: "plugin-git": executable file not found in $PATH

Hi, I'm running a woodpecker server and agents on next version (master). I  barely saw this error when I only had one worker but since I increased it to 16 workers, It happens way more often.
I'm using the default clone step in all my pipelines and I 've already read this documentaion https://woodpecker-ci.org/docs/next/usage/pipeline-syntax#clone

Thanks

Using a custom clone config
clone:    git:      image: woodpeckerci/plugin-git
randomly gives this error

Backend?

Docker, both server and agents configured in the same docker-compose file

Which os and architecture is it?

Hetzner dedicated server, amd 16 cores (32 threads) 128 ram running ubuntu 22. Thanks in advance.

Which backend do you use?

Same message exec: "plugin-git": executable file not found in $PATH with the latest git woodpecker running on debian.
Strangely enough, everything worked fine before I rebooted the system. Now every job fails to clone.
Debian GNU/Linux 11 (bullseye) x86_64
Kernel: 5.10.0-21-amd64
go version go1.20.1 linux/amd64

I could fix the issue by removing all the docker images, then restarting the docker and woodpecker services. I am not sure what happened though.

hmm could be related to the default $PATH var used ... by docker

but it should find it in any case:
https://github.com/woodpecker-ci/plugin-git/blob/4447028fb10d4314930ed34c1dd1f178947b3a49/docker/Dockerfile.multiarch#L19

https://stackoverflow.com/a/37904830
we might should try if moving to the "shell form" does fix it?
cc  @anbraten
I can create a test image that has only this change ...
... @healdropper  would you try that one?

Yes @6543  I could test it our CI server for sure, let me know

@6543 any update about this? Thank you

I created an internal image with the proposed change, I let you know @6543

It definitely improved the ratio it happens,  but still occurs 1 out of 15 executions.


chore(main): release 0.9.0

:robot: I have created a release beep boop
0.9.0 (2023-03-04)
Features

enhance please-release action (6098d95)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/samuele-cozzi/obsidian-marp-slides/releases/tag/v0.9.0 :sunflower:


cannot find metadata

nd2 version: 0.4.6
Python version: 3.10.6
Operating System: Ubuntu 22.04

Description
I am searching for metadata but cannot find it.
I know the metadata exists because when using NIS elements software I can export as an excel file:
https://hhmionline-my.sharepoint.com/:x:/g/personal/busheyd_hhmi_org/EdGxdrwO_o9Ml1m3M6NS7WsBxXaAv2Ej9y7Ra-dwyFPR-g?e=aycWd2
I am specifically looking for data in sheet "Recorded Data" column 640 nm[%].
The nd2 file can be found here (large file 18.6 GB):
https://hhmionline-my.sharepoint.com/:u:/g/personal/busheyd_hhmi_org/ESt_jvLHeMVIhiXF3VAk4aYB0NZYxLe3HT4OVH6T8s_iZA?e=zwHEbt
What I Did
I've looked in (f= nd2.ND2File(target_file)):
f.frame_metadata(0) #looking at first frame. Assuming the 640 nm would be here per frame in time series image.
Also, I looked in other places but do  not indicate per frame state:
f.custom_data - can see 640 nm as tag 6
f.attributes
f.experiment
f.unstructured_metadata() #when running this it hangs
f.metadata
Assistance is greatly appreciated. Although I can export the data via elements it takes a long time.
Thanks for nd2

thanks for the detailed report and data.  being addressed in #107

after the next release (coming today) you'll be able to access this at f.recorded_data.  It will be a dict of numpy arrays or sequences, and is suitable for passing to pandas dataframe.
f = nd2.ND2File('some_file.nd2)
df = pd.DataFrame(f.recorded_data)

Thank you so much. With the upgrade to 0.5.0 it works great. Also, pulling the timestamp from recorded_data is much faster.


[Bug] pyarrow not found, install pyarrow>=3.0.0

Is this a new bug in dbt-bigquery?

[X] I believe this is a new bug in dbt-bigquery
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
CI failure: https://github.com/dbt-labs/dbt-bigquery/actions/runs/8459554085/job/23176082535
Expected Behavior
No CI failure
Steps To Reproduce
https://github.com/dbt-labs/dbt-bigquery/actions/runs/8459554085/job/23176082535
Relevant log output
try:
            import pyarrow
        except ImportError as exc:  # pragma: NO COVER
            if raise_if_error:
>               raise exceptions.LegacyPyarrowError(
                    "pyarrow package not found. Install pyarrow version >="
                    f" ***_MIN_PYARROW_VERSION***."
                ) from exc
E               google.cloud.bigquery.exceptions.LegacyPyarrowError: pyarrow package not found. Install pyarrow version >= 3.0.0.

Environment
- OS: all
- Python: all
- dbt-core: 1.8
- dbt-bigquery: 1.8

Additional Context
No response

issue in bigquery python: https://github.com/googleapis/python-bigquery/issues/1877

I have the same issue, someone from DBT team please let me know when this will be resolved

Hey 👋 Thanks for fixing this quickly!
Any idea when 1.7.7 will be available on PyPi? Looks like the workflow was cancelled? https://github.com/dbt-labs/dbt-bigquery/actions/runs/8461950493

google-cloud-bigquery has yanked the offending version (3.20.0) from PyPI. The root cause was an undeclared dependency on pyarrow>=3.0.0. Folks should be alright to resume their workflows after reinstalling.


fixed docs error

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[x] Docs
[ ] Underlying tools
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Other information:

Thank you for fixing this! 🎉

In Vue CLI >= v3.11.0, the scope prefix can be omitted for official plugins. So I'm closing this issue.


Busy looping guards for Stream-consuming futures

Work to fix #1957 and provide a new macro for responsible polling.

This is a simple all-dynamic solution that augments futures and streams which may be affected by saturation of their poll function with a counter-based relief valve.
A more elaborate, generic extension is also possible that will allow the users to opt out of the iteration counter statically, which will be backward compatible with these additions (except the poll_loop! macro that would need to make use of a protocol trait to be future proof). But that may be overkilling it. If I get around to do it, I will submit the generic solution in another PR.

I'm not sure about landing the iteration API and the poll_loop! macro in futures-core. These are implementation helpers, not essential definitions, and so they could be moved to futures-util or even to their own dedicated crate if deemed necessary.


Nimony: progress

Todo:

[x] basic overloading resolution
[x] obj.field expressions
[ ] generic instantations

Merging this now as it contains crucial bugfixes.


LAN-164 - Prepare automated release workflow

Prepare for release workflow

Will be done via https://github.com/shopware/SwagLanguagePack/pull/27


Unpin upper bound of libclang for qt6 + mysql 8.3 + pulseaudio 17

xref: https://github.com/conda-forge/qt-main-feedstock/issues/240
closes #243

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

2024-03-15T09:35:17.9070555Z    INFO (qt6-main,lib/qt6/bin/qdoc): Needed DSO lib/libclang.so.13 found in conda-forge/linux-64::libclang13==18.1.1=default_h5d6823c_0
2024-03-15T09:35:17.9132325Z WARNING (qt6-main,lib/qt6/bin/qdoc): Needed DSO lib/libclang-cpp.so.18.1 found in ['conda-forge/linux-64::libclang-cpp18.1==18.1.1=default_h127d8a8_0']
2024-03-15T09:35:17.9133307Z WARNING (qt6-main,lib/qt6/bin/qdoc): .. but ['conda-forge/linux-64::libclang-cpp18.1==18.1.1=default_h127d8a8_0'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
2024-03-15T09:35:17.9191978Z WARNING (qt6-main,lib/qt6/bin/qdoc): Needed DSO lib/libLLVM.so.18.1 found in ['conda-forge/linux-64::libllvm18==18.1.1=h2448989_0']
2024-03-15T09:35:17.9193030Z WARNING (qt6-main,lib/qt6/bin/qdoc): .. but ['conda-forge/linux-64::libllvm18==18.1.1=h2448989_0'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

@conda-forge-admin please rerender

For others to help debug, here are "cleaned logs" of osx 64 from the previous builds on this branch
osx_pass_vs_failure.zip

While there seems to be some cmake incompatibility, i'm planning ot merge this today and then start to troubleshoot the cmake +osx incompatibilities once this is in the main branch.


BREAKING: Do not copy .git directory from local rock

Fixes #19
Had to use a function to invert the regex.

Thanks!


GameStoppingServerEvent not firing

For some reason this doesn't fire:
@Listener void onServerStop(GameStoppingServerEvent e) {}

Tested on SpongeForge 979.

This is an implementation issue, not an API issue.

Where do I have to post it then?

Post the issue on the SpongeForge repository.

As you probably saw I already posted it there but then removed it for whatever reason.


Student that was not in waiting room when dq'ed results in them infinitely being put in the sender's elevated queue

This will be the new model for how dq'ing works


Unit-testing in Entitas

Unit-testing is not possible with the current try-catch block in the Contexts.cs because the reflection-based method call to InitializeContexObservers() throws an exception. I'll repost my comment in #362 here:

Placing the try-catch like that still produces an exception for me. Placing it like the following works:
public partial class Contexts {

   #if(!ENTITAS_DISABLE_VISUAL_DEBUGGING && UNITY_EDITOR)

   [Entitas.CodeGenerator.Api.PostConstructor]
   public void InitializeContexObservers() {
       try {
               CreateContextObserver(game);
               CreateContextObserver(gameState);
               CreateContextObserver(input);
       } catch (System.Exception) {  }
   }

   public void CreateContextObserver(Entitas.IContext context) {
       if (UnityEngine.Application.isPlaying) {
           var observer = new Entitas.Unity.VisualDebugging.ContextObserver(context);
           UnityEngine.Object.DontDestroyOnLoad(observer.gameObject);
       }
   }
   #endif
}

I can't really see what the difference is. Why does moving the try catch block help?
I'd say we should find out why there is an exception in the first place, since there shouldn't be one. Is it the security exception? Are the dlls unblocked?

Unblocking does nothing. The error message i get is:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Security.SecurityException: ECall methods must be packaged into a system module.
at Contexts.CreateContextObserver(IContext context)
at Contexts.InitializeContexObservers() in D:\GitHub\UnityProject\Assets\Generated\Contexts.cs:line 82 (this is the CreateContextObserver(input) method)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at Contexts..ctor() in D:\GitHub\UnityProject\Assets\Generated\Contexts.cs:line 50

I think Unity does something very weird when they throw exceptions. Because doing the following makes the try-catch block work fine as @sschmid pointed out.
public partial class Contexts {

#if(!ENTITAS_DISABLE_VISUAL_DEBUGGING && UNITY_EDITOR)

    [Entitas.CodeGeneration.Attributes.PostConstructor]
    public void InitializeContexObservers() {
        CreateContextObserver(game);
        CreateContextObserver(gamestate);
        CreateContextObserver(input);
    }

    public void CreateContextObserver(Entitas.IContext context) {
        try {
            if(IsPlaying()) {
                var observer = new Entitas.VisualDebugging.Unity.ContextObserver(context);
                DontDestroyOnLoad(observer);
            }
        } catch(System.Exception) {
        }
    }

    private bool IsPlaying()
    {
        return UnityEngine.Application.isPlaying;
    }

    private void DontDestroyOnLoad(Entitas.VisualDebugging.Unity.ContextObserver observer)
    {
        UnityEngine.Object.DontDestroyOnLoad(observer.gameObject);
    }

#endif
}

If someone can explain this mystery then I'm glad to hear it.

So basically doing the following works:
    public void CreateContextObserver(Entitas.IContext context) {
        try {
            UnityCode(context);
        } catch(System.Exception) {
        }
    }

    private void UnityCode(Entitas.IContext context)
    {
        if(UnityEngine.Application.isPlaying)
        {
            var observer = new Entitas.VisualDebugging.Unity.ContextObserver(context);
            UnityEngine.Object.DontDestroyOnLoad(observer.gameObject);
        }
    }

But this doesn't:
    public void CreateContextObserver(Entitas.IContext context) {
        try {
            if (UnityEngine.Application.isPlaying)
            {
                var observer = new Entitas.VisualDebugging.Unity.ContextObserver(context);
                UnityEngine.Object.DontDestroyOnLoad(observer.gameObject);
            }
        } catch(System.Exception) {
        }
    }

I'm very much new to .NET projects, but it looks like the Unity project always has the UNITY_EDITOR symbol set; so after assembly, the DLL would only contain the first block when Visual Debugging is enabled for the project (i.e. when ENTITAS_DISABLE_VISUAL_DEBUGGING is not defined), even before we access the DLL from the test project. (Because the assemblies seem to get compiled first, based on the individual project settings, before being linked to the test project.)
Looks like the intent of the #if #else #endif was to be able to compile the code block dependent on unity when run from within the Unity Editor, or the other block when compiled from outside the Unity Editor. However, the compilation always seems to use the symbols defined in the Unity-controlled .csproj file, which always has the UNITY_EDITOR symbol.
Do we need to make another .csproj file (manually??) for the same production code-base (so that we can control the defined symbols), to compile the #else code block instead, for our unit test use cases?

I'd be interested in a solution for windows. Works with mono on a mac, no security exception. Is this sth you can configure? Kind of trust a location / dll / sth ?
@wistler My setup:

Unity project Assembly-CSharp.csproj
A second Tests.sln which has a ref to Assembly-CSharp.csproj

This way I have the tests separate and not in a Editor folder which is great. UNITY_EDITOR shouldn't be an issue since

Is this second sln inside the Unity root project folder?

Added the suggested fix. Will be in the next release. Thanks!


Creating Voice with custom format could trigger panic

When creating a new Voice in alsa, there are a lot of lines that use the expect function.
In one of my projects, rather than enumerating all formats I tried to guess the best format available by constructing one myself. Since Voice::new returns an option, I would expect that, given an invalid Format, I would recieve Err(FormatNotSupported) rather than a panic from which I cannot recover.
Shouldn't some of these use try! rather than expect?

An error definitely should be returned in the format is wrong.
However some of the lines you linked use expect because if these function calls fail it always indicates that there's a bug either in cpal or in alsa.
A function call which can legitimately return an error should do so, but function calls that are never supposed to fail should just panic.

I have the following code. I wrote this to determine a high supported sample rate, and to check if F32 is supported.
let mut wanted_samplerate = None;
let mut wanted_sampleformat = None;
for f in endpoint.get_supported_formats_list().unwrap() {
    match wanted_samplerate {
        None => wanted_samplerate = Some(f.samples_rate),
        Some(cpal::SamplesRate(r)) if r < f.samples_rate.0 && r < 192000 => wanted_samplerate = Some(f.samples_rate),
        _ => {},
    }
    match wanted_sampleformat {
        None => wanted_sampleformat = Some(f.data_type),
        Some(cpal::SampleFormat::F32) => {},
        Some(_) if f.data_type == cpal::SampleFormat::F32 => wanted_sampleformat = Some(f.data_type),
        _ => {},
    }
}

if wanted_samplerate.is_none() || wanted_sampleformat.is_none() {
    return None;
}

let format = cpal::Format {
    channels: vec![cpal::ChannelPosition::FrontLeft, cpal::ChannelPosition::FrontRight],
    samples_rate: wanted_samplerate.unwrap(),
    data_type: wanted_sampleformat.unwrap(),
};

But this gives me the following when passing to Voice::new:
format: Format { channels: [FrontLeft, FrontRight], samples_rate: SamplesRate(192000), data_type: F32 }
thread '<main>' panicked at 'hardware params could not be set: "Invalid argument"', ../src/libcore/result.rs:746

But switching to
let format = endpoint.get_supported_formats_list().unwrap().next().unwrap();

gives me
format: Format { channels: [FrontLeft], samples_rate: SamplesRate(5512), data_type: I16 }

which does work.

I have had some time to once look at this situation. It seems that my earlier assessment was wrong.
I am trying to make a
Format { channels: [FrontLeft, FrontRight], samples_rate: SamplesRate(192000), data_type: F32 }

on Linux (alsa).
The error that appears is
thread '<main>' panicked at 'hardware params could not be set: "Invalid argument"', ../src/libcore/result.rs:746

However, it seems that this exact format is in the get_supported_formats_list(). So it may be that that returns results that are too permissive.

As of #286, an appropriate error should be returned that should allow the user to handle this case.
If anyone reading this is still running into a discrepancy between the supported_input/output_formats and what is accepted when building a stream on ALSA, feel free to open up a new issue specifically for this problem.


rgb(a) issues

Hi!
First of all, it's really useful - thanks for that.
Second, there's a bug. Check out screenshot to see what I'm talking about.

Please let me know if you need some additional information.

Hello,
Thank you for the feedback. I'll try to fix it ASAP and will inform you once it's done. Please stand by. Once again thank you
Regards,
Ali

Ok, thanks :+1:

Hello!

commented on Dec 17, 2015
I'll try to fix it ASAP and will inform you once it's done. Please stand by. Once again thank you

Any news on bugfix after 2 months? Unable to use ext with rgba bug
tnx

Any news? Work stopped?

@anephew If he hasn't fixed it soon, I'll fix it, since I am finding it pretty annoying.

@Jacob-Gray @anephew @Equals182 Sorry guys, I've been busy due to my day job. Unfortunately I haven't had a chance to look into it. Feel free to play around with the .js file, you can do it by messing with the css properties. Once again my apologies.

@Jacob-Gray @anephew @Equals182
Try original version extension. It must correct works in the Brackets 1.5+ (I hope)
https://github.com/Taraflex/Brackets-Color-Highlighter

so still nobody looked into this? =(

@El4a Hey I'm sorry. I've been brushing up my skills, I'm a fairly new developer so I might not be able to troubleshoot it myself. Feel free to poke at it, if I find a solution, I'll definitely update the repo. Sorry


Run benches with different codegen options

All benchmark tests should be run with opt-level = 0/1/2/3.

Added in 9694fb77881364330afaf299056e48d889d033e3.


Feature/update ci

Codecov Report

Merging #699 into 2.2-dev will decrease coverage by 3.18%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           2.2-dev     #699      +/-   ##
===========================================
- Coverage     96.1%   92.92%   -3.19%
===========================================
  Files           83       83
  Lines         2544     2544
===========================================
- Hits          2445     2364      -81
- Misses          99      180      +81

Impacted Files
Coverage Δ

matchzoo/datasets/wiki_qa/load_data.py
24.39% <0%> (-73.18%)
:arrow_down:

matchzoo/datasets/quora_qp/load_data.py
27.27% <0%> (-72.73%)
:arrow_down:

matchzoo/datasets/snli/load_data.py
25% <0%> (-72.23%)
:arrow_down:

matchzoo/engine/base_model.py
94% <0%> (-0.67%)
:arrow_down:

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 ce589d2...df698b1. Read the comment docs.


[BOT PR] to update dependencies of istio

This PR will be merged automatically once checks are successful.
none

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: istio-testing
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: wattli
Assign the PR to them by writing /assign @wattli in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@istio-testing: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
eacce3b2a0deaf5f03f1a2b72535132e0a2270f9
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@istio-testing: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
eacce3b2a0deaf5f03f1a2b72535132e0a2270f9
link
/test istio-unit-tests

prow/e2e-bookInfoTests-v1alpha3.sh
eacce3b2a0deaf5f03f1a2b72535132e0a2270f9
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Extend .Summary and .IsTruncated to be used front matter keys.

Hey!
Not all our posts have content in the "body" of th markdown that needs to be summarised. Some of the strings I'd like summarised are actually in the front matter of the file.

Currently, .Summary and .IsTruncated only works for content within the body of the markdown file.
I'd like to know if we could extend that feature to the front matter keys as well, because I'd like to maintain the same summary length and truncate logic for the front matter keys too.
Seeing a usage being something like "{{ .Params.founder_message | summary}}" (or .summarize) which ever seems ideal.

I've been seeing that the only alternative has been to split the string by full stops currently, but I'd like something that maintains summary length from the config.
Really sorry if this is already present as a feature or in the timeline. I tried my best to search through the docs and GitHub issues beforehand.
Thanks!

It seems like a partial would be sufficient. For example:
https://discourse.gohugo.io/t/36676/5


[TF-TRT] Adding additional TraceMe ranges

This PR adds a few additional TraceMe annotations to improve profiling for TF-TRT.

@bixia1 for review


Cache pana's ToolEnvironment for a limited amount of access.

Caches the dart and flutter runtime information and doesn't need to run e.g. dart --version before each analysis. (related to https://github.com/dart-lang/pub-dartlang-dart/issues/1347)

Caches the downloaded packages for up to 100 separate analysis/dartdoc runs. Previously all of these were started from a clean state, and this part of the change should improve the pub upgrade part because it won't download the common dependencies in subsequent runs. (related to https://github.com/dart-lang/pub-dartlang-dart/issues/1521)

Because we don't want to have an unbounded number of packages being downloaded locally, I've set the arbitrary limit of 100. We could also monitor the total size of the directory, but I think we have enough value out of the simpler approach.

PTAL:

I've fixed the issue of multiple instance creation.
I have prepared a test, but it requires Flutter in the CI environment, and getting that installed seems not to worth it (increases the test times a lot).

I would imagine that you could mock 'flutter' in a test so we don't actually need it installed.

It would be easy to mock the parts where the command just prints some text on the output (e.g. --version), but that more important use case is to call pub upgrade / flutter packages upgrade, where we'd need to mock not only the stdout, but also do the filesystem changes.
The Dart SDK part is already covered via pana's end2end tests, but we don't have Flutter-based test there. I'd rather try to increase the coverage of our end2end tests, both on pana and on the pub site, because many of our recent issues were coming from data-assumptions that become invalid, which would be hidden by mocks anyway.
I've created https://github.com/dart-lang/pub-dartlang-dart/issues/1595 to track these, as it will be outside of the scope of this PR.


Using forcethumbnail=true and Download=False using python

Im pretty sure this is not the right place to post but i couldnt find an oficial forum or group.
im trying to get the thumbnail url from a video using python, how do i do that?
this is my code wich shows the Url and Title:
def getdata(url)
ydl = youtube_dl.YoutubeDL({'outtmpl': '%(id)s%(ext)s'})
result = ydl.extract_info(url,download=False)
url = result['url']
title = result['title']
writecvs(url, title, tags)
Thanks and sorry for posting in the wrong place.

This is the right place to post - what made you think otherwise?
You can simply look into the thumbnail property. Bear in mind that unlike id or title, it may be None or unset. That happens if the service does not provide a thumbnail, doesn't support thumbnails at all, or youtube-dl doesn't correctly extract the thumbnail (in the latter case, feel free to create a new bug report, provided you are using the latest version).
The following code works fine for me:
import youtube_dl

def getdata(url):
    with youtube_dl.YoutubeDL({'outtmpl': '%(id)s%(ext)s'}) as ydl:
        result = ydl.extract_info(url, download=False)
    url = result['url']
    title = result['title']
    thumbnail = result.get('thumbnail')
    print('url: %r, title: %r, thumbnail: %r' % (url, title, thumbnail))
    # writecvs(url, title, tags)

getdata('http://www.youtube.com/watch?v=BaW_jenozKc')

I am closing this issue now, since the code works fine for me. If there is still a problem, please say so and we will reopen it. Thanks!


Buttons not giving feedback

On various occasions including
-when executing an order
-refreshing
-press any button
Nothing happens. There is no feedback to the user. It's confusing and often there are things happening in the background.

-Executing order gives the info messages as it triggers the steps. Trade status tab previously been disabled auto refresh. that now auto refresh after recent git commits.
-refresh buttons in app are updated to show info message on button push.


wrong setup.py

When I try to deploy using scrapyd-deploy I get an error which occurs because the uploaded egg file doesn't contain the directory with templates. I suspect that's because setup.py of my data project forgets to mention it. I tried deleting it and let scrapyd-deploy create the setup.py file on it's own, but that didn't help.

If you change your setup.py to this:
Automatically created by: slyd
from setuptools import setup, find_packages

setup(
    name         = 'new_project',
    version      = '1.0',
    packages     = find_packages(),
    package_data = {
        'spiders': ['*.json', '*/*.json']
    },
    data_files = [('', ['project.json', 'items.json', 'extractors.json'])],
    entry_points = {'scrapy': ['settings = spiders.settings']},
    zip_safe = True
)

It should work. If it does I'll fix the default setup.py template in Portia when I get a chance.

@vit-tucek Did this work for you?

Yes, it works. Thank you.


Class property definitions should not disappear

class Shopify.AutocompleteV2
  LIST_CLASS = '.js-autocomplete-suggestions'
  PIXELS_FROM_BOTTOM_TO_INFINITE_SCROLL = 500
  ERROR_DISPLAY_TIME = 5000

export default class AutocompleteV2 {
  constructor(node, renderer, options = {}) {

Quick run through with decaf suggests that it's the source of the problem.

An especially bad case of this is SingleSelectResourcePicker:

In CoffeeScript, a resourceSelected class property is defined.
In JavaScript, the class property is missing, and individual methods declare it as a const

Ugh, yeah, this is a terrible one because it has no direct parallel in ES6. Best pet is probably just making these static properties.

Possibly fixed by mainline decaf merge.  Please don't start work on this until we've finished evaluation.

Still a problem after the mainline merge :/  This is odd because it definitely fixed some class property issues.

Duped by #157.


Client-side Mixer integration story

We need to establish a workflow / guidelines / best practices for using Mixer on the outbound (client) side of requests. Currently, Mixer is called solely on inbound (server-side). This will help with egress integration, etc.

I think one of the blocking issues is that Envoy doesn't support plugging in client-side filters. We would have to change the current Envoy architecture to support plugging in Mixer filter on Envoy client-side stack, which is non-trivial work.
@lizan

@myidpt We don't need Envoy client-side filter for client-side Mixer integration. They are orthogonal. We can apply client-side mixer check at regular filters on client-side Envoy.


Error when annotating on function out of several

I have a simple set of linear algebra functions written in C. I added tuning annotations to the add_matrix (~line# 180) function, leaving the others in the file. When I used orcc it errored out with python looking messages; however, when I moved the function and annotations to a unique file it worked fine.
orio_issue.zip

I think your issue is similar to mine, have a look on #12 .

@mahdifani14
Thanks for the feedback! From my highly limited experience it seems that it is not necessary to have a main function to do the tuning, but it can be useful to initialize data. There are a bunch of good examples in the testsuite/SPAPT directory of the repo as well.

@mastino
Thanks for your info,
I would be appreciated to let me know if you could find any solution and I will do so.


provide explicit copying of DMGrads and DMModel

in order to do #95 we forbid applying a mutating function to several pointers that point to the same object, like
a = something
f!(a,a)

we could privode a way of explicitly making a copy of the object a points to, to enable stuff like this.

is there for DMGrads, is impossible and undesirable for DMModel.


Crc leading zero fix for streams

I noticed the crc32 streams had the same bug as with #1

Thanks
Landed in v0.2.2