Proposal to reserve "virtuals" member at top level of resource objects

The spec knows "attributes" but not "virtual attributes" (or "derived attributes"). This type of attribute is usually calculated from the values of other attributes of the same resource (or of related resources).
The problem with these attributes is, that they cannot be updated directly (only by updating the attributes they are derived from), so they are read-only and MUST NOT be used in CREATE/UPDATE requests.
Examples for this type of attribute:

age (calculated from the date of birth and the current time)
item total price (calculated from the number of items and the single price)
order total price (calculated from the total prices of related order items)

The only way to handle this in the current version of the spec is to reply with a "409 Conflict" error, but this error is also used for other conflicts, e.g. with client generated ids.
This conflict could be easily prevented by excluding the derived attributes from the request - but to be able to do that, the client needs to know which attributes are "virtual".
Suggestion:
Reserve a new member "virtuals" at the top level of resource objects, based on the suggested change #573. They MUST share the same namespace with the other resource attributes.
{
  "id": "1",
  "type": "person",
  "attributes": {
    "firstname": "Justin",
    "lastname": "Timberlake",
    "signature": "http://commons.wikimedia.org/wiki/File:Justin_Timberlake_signature.svg",
    "date-of-birth": "1981-01-31"
  },
  "virtuals": {
    "age": 34
  }
}

It would be great if it were possible for the spec to allows clients to rely more on API responses rather than API docs in order to determine what can be modified and what cannot be. However, what about complex attributes? If a complex attribute contains both changeable and calculated members, it would break the abstraction suggested here. I think that introducing a list of calculated members, possibly placing them into meta, would allow to achieve the same goal, while keeping the format more versatile.

I agree with @hhware.  This sort of implementation-specific behavior is precisely what meta is for.

I understand your point, but the spec doesn't define meta information as read-only or that they are not allowed in request or must not be processed by the server.
So yes, it would be possible to use meta, but the problem with the read-only data remains.
Would it be possible to allow the meta member in responses only? I think the definition as additional information that are no real attributes (and therefore not updateable) allows such a limitation.

There's a difference between virtual and read only values. That is, there are many cases in which you can update the virtual value directly and the changes you make to it will be reflected in the value(s) it was derived from. Here's a dumb example just to make the point:
{
   "birth-month": 1,
   "birth-date": 15,
   "birth-year": 1939,
   "dob-en-US": " 1/15/1939"
}

The localized dob-en-US is derived from the other fields, and yet it could be set directly too to update the other values.
Given that virtual doesn't imply read-only, the behavioral treatment you're suggesting (i.e. not allowing these fields in updates etc.) would really be appropriate for any read-only field, many of which aren't virtual.
While I've seen read-only fields come up in almost every complex api, I'm not sure they warrant their own property bag. This would mean, for example, that a client that does simply want to read all the values out of a resource object must loop over both the attributes bag and the virtual bag.
I think the right balance here would be to add a recommendation for how to specify in meta which attributes are read-only.

I agree with @ethanresnick that virtual but not read-only attributes do not require special treatment.
@ziege, sorry for not being clear enough, I did not mean to place read-only members to meta, I meant to place the list of read-only members to meta.
An alternative: introduce a dedicated member in the response object for this purpose. IMHO, the need to support read-only fields (not only attributes, but also relationships) is common enough to warrant this step towards HATEOAS.
An example:
{
  "data": {
    "id": "12",
    "type": "users",
    "username": "jsmith",
    "email"<EMAIL_ADDRESS>    "updated_at": "2015-01-01",
    "name": {
      "first": "jane",
      "last": "smith"
    },
    "links": {
      "father": { "linkage": { "id": "34", "type": "users" }},
      "mother": { "linkage": { "id": "56", "type": "users" }},
      "spouse": { "linkage": { "id": "78", "type": "users" }}
    }
    "immutable": [ "id", "username", "name.first", "father", "mother", "updated_at" ]
  },
  "immutable": {
    "users": [ "id", "username", "name.first", "father", "mother", "updated_at" ],
  }
}

This mechanism could be also used to notify the client that the id of a resource is changeable, if the server wishes to allow that.

Corrected the error in the example above.

@ethanresnick: I agree that virtual and read-only attributes are not always the same, and that there's also a need to include update permissions.
@hhware: I like your suggestion. All attributes are saved in one object, and it solves the problem with attributes that are read-only in general or because of general (client specific) permissions, without changing the structure of the resource object itself.
I only see one limitation:
The "immutable" attributes for "users" are defined for all users resource objects. This is good to avoid unnecessary repetition and enough for most cases, but resource specific permissions wouldn't be possible this way.
A complementary "immutable" member at the resource level would solve this...
{
  "data": [
    {
      "id": "12",
      "type": "users",
      "username": "jsmith",
      "email"<EMAIL_ADDRESS>      "updated_at": "2015-01-01",
      "name": {
        "first": "jane",
        "last": "smith"
      },
      "links": {
        "father": { "linkage": { "id": "34", "type": "users" }},
        "mother": { "linkage": { "id": "56", "type": "users" }},
        "spouse": { "linkage": { "id": "78", "type": "users" }}
      },
      "immutable": {
        "email"
      }
    },
    {
      "id": "13",
      "type": "users",
      "username": "mmuster",
      "email"<EMAIL_ADDRESS>      "updated_at": "2013-12-04",
      "name": {
        "first": "max",
        "last": "muster"
      },
      "links": {
        "father": { "linkage": { "id": "64", "type": "users" }},
        "mother": { "linkage": { "id": "84", "type": "users" }},
      }
    }]
  },
  "immutable": {
    "users": [ "id", "username", "name.first", "father", "mother", "updated_at" ],
  }
}

but I think that introducing cascading would make the format unnecessarily complex, so I'd move "immutable" to the resource object instead:
{
 "data": [
   {
     "id": "12",
     "type": "users",
     "username": "jsmith",
     "email"<EMAIL_ADDRESS>     "updated_at": "2015-01-01",
     "name": {
       "first": "jane",
       "last": "smith"
     },
     "links": {
       "father": { "linkage": { "id": "34", "type": "users" }},
       "mother": { "linkage": { "id": "56", "type": "users" }},
       "spouse": { "linkage": { "id": "78", "type": "users" }}
     },
     "immutable": {
       "id", "username", "name.first", "father", "mother", "updated_at", "email"
     }
   },
   {
     "id": "13",
     "type": "users",
     "username": "mmuster",
     "email"<EMAIL_ADDRESS>     "updated_at": "2013-12-04",
     "name": {
       "first": "max",
       "last": "muster"
     },
     "links": {
       "father": { "linkage": { "id": "64", "type": "users" }},
       "mother": { "linkage": { "id": "84", "type": "users" }},
     },
     "immutable": {
       "id", "username", "name.first", "father", "mother", "updated_at"
     }
   }]
 }
}

This would enable resource specific immutable attributes. Although this means repetition in some cases, it would be much clearer - also because "immutable" doesn't have to contain the additional resource type level anymore.

@ziege, IMHO, immutable at resource level is a very special case. The vast majority of use cases should be served by immutable at the top level, so this option should be available because it is much less verbose. The tradeoff could be to allow immutable either at the top or resourse level witin each particular response document, not at both levels at the same time.

@hhware:
I think that if something like immutable is introduced, it should also support resource dependent permissions, because it would be hard to add that later. This is a common case when working with APIs that allow not only read-access but also the modification of resources (e.g. see GitHub OAuth scopes, which differ between read and write access for some user information).
I don't agree that it would be generally "much less verbose" at the top level. At the top level you need an additional level for the resource type, not so at the resource level, so in can be more compact at resource level.
Only when multiple resources of the same resource type are returned, there can be some repetition, but IMHO...

In most cases an API will return only one resource in primary data. So if immutable is used, it doesn't make a big difference if it's placed at the top or the resource level. At the resource level it would be more compact in this case.
When resources are included, they are of different resource types in most cases, so there wouldn't be repetition. (And it's not said, that the included resource even use immutable.)
If used, the number of immutable attributes will be small in most cases (1-3 attributes I guess), so a possible repetition would be small.
I expect that the response is gzipped, so there shouldn't be a mentionable difference in size, also if there is repetition.
Many APIs won't use immutable at all, but allow clients with general access to do everything.

Finally I don't think that placing immutable at the top OR the resource level is a good idea, because this would complicate the processing on client-side.

Only when multiple resources of the same resource type are returned

@ziege, yes, that was what I meant.

In most cases an API will return only one resource in primary data

I disagree, I think it depends.

When resources are included, they are of different resource types in most cases, so there wouldn't be repetition

The client may wish to cache all resources from primary data and included, and then allow the user to edit them without re-fetching specifically for editing. In this case, the client may want to have immutable defined for all resources being fetched in a request.

Many APIs won't use immutable at all, but allow clients with general access to do everything.

Yes, if immutable is accepted, it should definitely be added via MAY.
Again, as a compromise, I suggest to allow it either at resource level or at the top level within each particular response.

Again, as a compromise, I suggest to allow it either at resource level or at the top level within each particular response.

We had this debate over and over about "top-level, resource-level or both" back when the spec still had link templates. At that point, there was likewise concern that putting the templates at the top-level only would be insufficient (as there are occasional needs for a resource-level override) but that putting them at the the resource-level only would be redundant. Ultimately, we decided resource-level only (which is why there aren't link templates at all any more) for the the reason that @ziege pointed out:

I expect that the response is gzipped, so there shouldn't be a mentionable difference in size, also if there is repetition.

Gzipping means the size difference is negligible, and the implementation benefits of not having to support two cases outweigh any costs. I assume that logic would apply to "immutable" too.

@ethanresnick, I think the case of links is different.
In case of links, only template could be possibly stored at the top level, and that template was not the actual information needed by the client. The client would need to build the actual link using the template from the top level and ID from the resource level. It is easier to include the complete link to make things more readable and simpler on the client side, as gzipping makes the difference in payload size negligible.
In case of immutable, the actual information needed by the client may reside, depending on a particular API, either (1) on top level, when all resources of a give type have the same set of immutable attributes or (2) on resource level.
IMHO, case (1) is very common, as it is typical to authorize access to API at resource level, not at resource attribute level. In this case, there is absolutely no advantage in having immutable on resource level: they are all the same, but the client is forced to look them up in each resource because the server returned them that way. The client will have to do more data crunching and allocate more memory, just for the sake of preferences of the transmission format.
In principle, in this case, the API could even provide a special endpoint to list all immutable attributes for all possible types, so that the client could fetch them once and use afterwards, for example,
GET /immutables

{
  "data": {},
  "immutable": {
    "users": [ "id", "username", , "created_at" ],
    "comments": [ "id", "created_at" ]
  }
}

At the same time, the server may allow top-level immutable in actual responses, if the client requests so: the format is the same in both cases, so it is not an implementation burden.
Case (2) seems very special to me, I believe it will be used much less often than (1). So I think that, contrary to links, it makes sense to allow immutable at top & resource levels.

@hhware: I understand what you are trying to achieve, but I don't think that this solves the problem.
You say that immutable settings at the top level are the common case for you. On the other hand I work on a project that requires immutable settings for each resource. So I agree that it depends on the type of API you use - but this also means that both cases must be supported.
You suggested to provide a special endpoint to provide a list of immutable settings for all resource types - which can (and must be allowed to) be overwritten in each response.
I see that you try to avoid the immutable member in the following responses, but they still can (and must be allowed to) be a part of it. So IMHO this makes the problem even more complicated, because you would now have 3 different sources for the immutable information - the global immutable settings, the (now more or less optional) immutablesetting at the top level (which can be set and need to be checked), and the optional immutable settings at resource level (which also need to be checked).
It would be a really bad, if you require the client to make a special request first so that it can understand the following (as long as the immutable information is not always provided there). Of course you could implement something to give the client the control over the included immutable information, but this would mean additional complexity in general and IMHO be counterproductive.
You wrote, that "The client will have to do more data crunching and allocate more memory, just for the sake of preferences of the transmission format.", but I cannot fully agree to that.
Yes, in some cases the response itself is larger than necessary because the settings are repeated, and of course this requires somewhat more memory, but if immutable is set on resource level only, there wouldn't be "more data crunching" - the contrary was the case. You only have to check one source, the settings of the resource object, not the aforementioned three.
The processing on the client side depends on the implementation, but I'd say, that - as it's always possible to save immutable settings at resource level - these settings are mapped to the resources by the client when parsing the response. So no matter if you provide all settings with one request, at the top level or at resource level, in the end they are always saved at the resource level and require the same memory there.
In total even less memory would be required than in your suggestion, because the global default immutable settings (requested separately) would have to be saved too - and depending on the number of resource types, this can me a lot of information (although you perhaps just want to make one request for one resource type).
So I'm convinced that providing immutable information at the resource level only is the best way to implement this feature, as it would make the processing much easier and efficient for the client - if the data are provided at all (which IMHO isn't the case for most APIs).
To find an agreement for the implementation I though about some rules for the spec and additional ways to optimize the responses for different API types:

If a client tries to update an immutable attribute (not updateable in general or for this specific client), the server MUST response with a 403 Forbidden status code and SHOULD provide an error to inform the client about the immutable attribute(s) used in the request.
immutable is an additional information for the client to avoid conflicts with updates. Servers SHOULD support it, if they allow clients to update resources.
immutable settings are set per resource and placed at resource level. Normally it's value is an array, containing the immutable resource attribute names.
If the client has all rights to update all attributes of a resource, immutable SHOULD NOT be included for this resource. Alternatively its value MUST be set to an empty array.
If the client has limited rights to update attributes, the immutable array MUST be set to an array of the immutable resource attribute names.
If the client has no right to update the attributes of a resource, immutable MUST either be set to an array of all the resource attributes, or it can be set to just "*" (to keep the response small).

This should solve most of the conflicts we discussed and offer a solution for different use cases:

It's up to the API if it supports immutable. So if an API is read-only, it doesn't have to support it, because the client doesn't need this information. No change compared to now.
If an API allows updating of resources without any limitation for the clients, it SHOULD support it, but in this case it's never required to add immutable to a resource. No change compared to now.
If an API allows updating but limits the attributes that can be updated in general or for specific clients, it SHOULD support immutable to help clients to avoid errors, but it doesn't have to - it would also be possible to fall back to the defined error handling, as this MUST be supported in any case.
In the case, that specific clients have read-only access to resources, the use of  "*" reduces the size of the response and makes it easier to process immutable for the client. (One could also wrap in in an array for consistency.) This suggestion is based on #567, so "*" can be used for this.

The processing on the client side depends on the implementation, but I'd say, that - as it's always possible to save immutable settings at resource level - these settings are mapped to the resources by the client when parsing the response. So no matter if you provide all settings with one request, at the top level or at resource level, in the end they are always saved at the resource level and require the same memory there.

I do not understand why it is necessary to always save them at the resource level. We are discussing the format here, what it allows and what it does not allow. I think that implementation, e.g., a client library, can be smarter. For instance,

The library may decide to provide two ways to handle immutable via API-wide configuration settings of the library, such as immutable_level=(global|resource), to indicate whether immutable is internally saved at resource level or they are static and defined API-wide,
If immutable_level=global, then the library may provide GET /immutables and a query parameter for all GETs, immutables=true|false, so that the API client may decide where he wants to see immutables in the particular response. In both cases (dedicated endpoint and specific response) they will include exactly the same response-level immutables, either for all types of the API or for types returned in that response,
if immutable_level=resource, then the library may decide to provide neither GET /immutables nor response-level immutables query parameter, only resource-level immutables would be supported.

Yes, this complicates the library, but these are implementation choices, I do not think they should be mandated by the spec. Each particular implementation may decide to support only one use case or both, or a mix of them, since they are all defined via MAY. It may decide to support them via one internal mechanism or via two different mechanisms. It may always allow them to be specified on all 3 levels and then merge (override) them for every resource. It is similar to the pagination definition in the spec: the framework and reserved words are defined, the rest is out of scope of the spec.

So I'm convinced that providing immutable information at the resource level only is the best way to implement this feature, as it would make the processing much easier and efficient for the client - if the data are provided at all (which IMHO isn't the case for most APIs).

IMHO, libraries may need to be more complicated to simplify implementation of the actual APIs which use them. The end user of the spec is the API, the library is a service provider.
Again, why I think it is important to support both use cases is that they are totally different, many APIs will only ever use one of them. I understand that APIs with attribute-level access control exist and it is important to have that option available. But I dare to suggest that the more common case for the API is to provide resource-level access control, not attribute-level, and in this case resource-level immutable is just a meaningless noise in every response because this data is completely static for the whole API.
Consider the following analogy. To ship a package abroad, one usually has to provide a customs declaration. Suppose it is required by law to supply customs declaration for every package, domestic or international. One has to attach an extra piece of paper to every package, and if it is domestic, one has to check a checkbox at the top and can otherwise leave it blank. If one wants to ship a very small item domestically, and there is no room for the customs declaration on a small box selected for that package -- no problem, just use a larger box! Now, suppose a business which ships thousands of packages per year domestically and never ships internationally, is trying to repeal that law, and the carrier is lobbying for it because it does not want to maintain package processing machinery which accounts for different processing algorithms for different packages types. @ziege, which side are you on? (Law = the spec, postal carrier = library, business = API.)
I have submitted a PR for this issue. This way the discussion can be brought to a more practical level and specific rewording / inclusion / exclusion suggestions can be made.

I not only work on an API for my own project, but want to provide a server and client library that can be used by everyone, no matter how the accessed API is configured. So I think not only about the format itself, but also about the later implementation.
Additional complexity on server side is okay, but the client side should be as easy as possible. As an API provider, you want that clients can use it out of the box, without special configuration. Do you agree?

I do not understand why it is necessary to always save them at the resource level. We are discussing the format here, what it allows and what it does not allow.

What I tried to say is that a client uses the immutable information to update a resource (or multiple ones) and to do that, the client needs to know, which attributes for the specific resource(s) can be updated or not. So in the end, everything ends at the resource level.

The library may decide to provide two ways to handle immutable via API-wide configuration settings of the library, such as immutable_level=(global|resource), to indicate whether immutable is internally saved at resource level or they are static and defined API-wide,

Yes, I understand this, but this would require additional configuration on the client side. The client needs to know that global settings are used and that an additional request has to be made.

If immutable_level=global, then the library may provide GET /immutables

First I don't think it's a good idea to indroduce reserved endpoints, but I guess this is also a decision of the server where to place it exactly, right? In this case, this is also an additional information that needs to be configured on the client side.

a query parameter for all GETs, immutables=true|false, so that the API client may decide where he wants to see immutables in the particular response

This is what I meant with "additional complexity" on client side and should be avoided IMHO. It relies on the previously mentioned server configuration, If this needs to be set b the client.

Yes, this complicates the library, but these are implementation choices, I do not think they should be mandated by the spec.

Yes, and I suggested the same, but without any dependency between server and client configuration.

I dare to suggest that the more common case for the API is to provide resource-level access control, not attribute-level, and in this case resource-level immutable is just a meaningless noise in every response because this data is completely static for the whole API.

That's why I considered different use cases in my suggestion. APIs that are read-only or allow all attributes to be updated wouldn't contain any additional information. Same situation as now.
And if your "data is completely static", you can just document it instead and don't have to use immutable at all in your API. So IMHO immutable is only required in more complex APIs, where these settings depend on the client or resource.

Consider the following analogy [...]

Please check my suggestions once again. I never suggested to add immutable to all responses, only for specific cases and I also defined it as optional, so that it can be defined per API.
So I'm on the side of the law, but it would simply say:
"A customs declaration can be helpful and it makes sense some cases, but it isn't required. Do what you prefer, but do not annoy your customers by asking them for unnecessary information when they want to place their order, that's not good for business."

I have submitted a PR for this issue.

I read it and I saw that you though a lot about this feature, but I still think, that your suggestion is unnecessarily complicated and includes to many dependencies...
Nevertheless you should include my suggestions regarding invalid update requests. I suggested to answer them with HTTP status 403 Forbidden, which seems to match the situation best (the client is authorized and the server understood the request, but refused it because of the disallowed update, see https://tools.ietf.org/html/rfc7231#page-59). The response should also contain error details.

I not only work on an API for my own project, but want to provide a server and client library that can be used by everyone

@ziege, so do I :) I haven't personally seen a need for attribute-level access control...

Additional complexity on server side is okay, but the client side should be as easy as possible.

I think there should be a balance. Depending on the situation, the client may need to include a bit of complexity too (and the use case of immutable only applies to complex systems).

So in the end, everything ends at the resource level.

As I tried to illustrate, it depends on the design of the client library. For instance, if it supported that global|resource configuration, it would not have to store it inside the object, it could just reference a static map located somewhere in the application config.

Yes, I understand this, but this would require additional configuration on the client side. The client needs to know that global settings are used and that an additional request has to be made.

Yes, and what is wrong with making that additional call, for instance, at the start of a SPA, if it is justified by the app logic?

First I don't think it's a good idea to indroduce reserved endpoints,

That is why I submitted a PR -- to make the discussion more concrete. This endpoint is only in the example, it is not reserved by the spec.

Yes, and I suggested the same, but without any dependency between server and client configuration.

IMHO, it is quite common to pass some configuration information from server to client at runtime, so I would imagine that in a complex API (and the use case of immutable only applies to complex systems) this transmission of configuration may have beed already implemented for other reasons.

And if your "data is completely static", you can just document it instead and don't have to use immutable at all in your API.

It is a good argument! OK, imagine that a service provider is building a multi-tenant application, one tenant per customer. One server installation hosts a number of isolated databases (or database schemas) with identical structure, one per tenant. In addition to the API, the same service provider provides a web UI for it in the form of SPA. Depending on the business objective of the application, it is conceivable that different customers of that service provider may want to allow different fields of the same resource to be immutable.
Another use case for immutables at response level is when the right to modify specific attributes of a specific resource type depends on the system-wide permissions of the user calling the API and not on specific permissions of the resource. So for the purposes of a user session in a SPA, these immutables are again can be considered static, although they are not static from the point of view of the server.
Here you are, we have two use cases for a client application which needs to fetch a list of immutables configured for the given user at start time. In the first example, the service provider could  hardcode immutables into the client and build a separate client app for each customer, but I doubt that would be a preferred option. In the second case, I doubt anyone would even consider building a separate app for each user.
The PR actually provides 3 options:

dynamic immutables at resource level,
static-per-user-session immutables at the API level (via a separate endpoint),
static-per-response immutables at response level.

I agree with you that the 3rd option is useless, but in order to keep the 2nd without the 3rd, the spec would need to introduce the concept of dedicated endpoints, and I think this is outside of the scope of the spec.

Nevertheless you should include my suggestions regarding invalid update requests.

Sorry, forgot about it

In my opinion, json-api is a great spec which says how data can be fetched. But saying what fields are virtual or read-only or whatever is kind of another responsibility, it's not for json-api.
Clients must know what model "A" is, what fields are there, what are read-only and so on, and that's what Swagger is for.
So use json-api for formatting and linking data and Swagger (or something similar) for describing data. Please, don't make json-api too complicated.

I believe that this is more of a schema concern which is currently beyond the scope of json-api. Furthermore, the general concepts of "read-only" and "virtual" can be applied to links as well as attributes, and therefore may not work well in a single virtual container.
However, please feel free to explore this concept as an additive extension. With the addition of the attributes container, the base spec does not need to reserve anything to allow for such extensions, since containers such as virtual can coexist as siblings to attributes.

Clients must know what model "A" is, what fields are there, what are read-only and so on, and that's what Swagger is for.

@ksimka, AFAIK, Swagger is more a documentation tool. This issue is addressing situations when read-only fields are not static per API. A couple of possible use cases are described, e.g., here. @ziege could probably provide more interesting examples, since he has practical need of this feature.

Furthermore, the general concepts of "read-only" and "virtual" can be applied to links as well as attributes, and therefore may not work well in a single virtual container.

@dgeb, this was reflected in the PR #589.

However, please feel free to explore this concept as an additive extension.

@dgeb, if you have a chance to review #589, I would greatly appreciate your opinion on it. I can certainly rewrite it as extension, but it would only change form, the gist would remain the same.

Clients must know what model "A" is, what fields are there, what are read-only and so on, and that's what Swagger is for.

That is generally true if you use it for "virtual attributes" only. This can be documented, but it would be good for clients to be able to automatically adjust update requests, e.g. if the API changes and new virtual attributes are introduced. With readonly this is possible.
Also a documentation cannot solve individual client specific or resource specific restrictions. The handling of permissions and permission related errors was completly missing in the spec.

However, please feel free to explore this concept as an additive extension.

It's defined as optional, so it's similar to an extension, and you don't have to use it. The only important differece is, that every server/client needs to support this optional feature, which is good, because we need a defined way to handle permissions.

@ksimka, AFAIK, Swagger is more a documentation tool. This issue is addressing situations when read-only fields are not static per API.

Also a documentation cannot solve individual client specific or resource specific restrictions.

@hhware, Swagger (and similar tools) can describe each api, each resource. And it's not a simple documentation, is't a machine-readable documentation. In other words, you can use it as an extension to your json-api.

This can be documented, but it would be good for clients to be able to automatically adjust update requests, e.g. if the API changes and new virtual attributes are introduced.

API changes, so documentation changes too, doesn't it? And since we're talking about swagger-like automatic documentation (which is an API too), we're good.
Can you provide an example where API changes without a BC break and documentation cannot help?
I'm sorry, but due to my poor english I can't express my thoughts as clear as I want to. The only thing I wanna say here is "please follow SRP". Two simple tools is better than one complicated.

@ksimka, I understand what you mean, but IMHO, functionality provided by readonly is not limited to documenting the API, it would allow to express differences between settings of tenants in a multi-tenant environment, permissions, state of resource.

API changes, so documentation changes too, doesn't it? And since we're talking about swagger-like automatic documentation (which is an API too), we're good.

Can you provide an example where API changes without a BC break and documentation cannot help?

@ksimka It's not about documentation or not, it's about a reduction of conflicts between clients and servers. With readonly a client can "understand" and work with the API, also if the API has changed (downwardly compatible) - without the need to adjust anything or to check the documentation for every little change. This is especially important if an API has thousands of clients.
Example:
The API adds two new attributes "server-update-time" and "resource-version". The first is read-only (as set by the server), the second is always required for updates (to check is the update is based on the same resource state).

Option 1 without readonly: The client doesn't send attributes, which it doesn't know. -> Would result in a conflict, because "resource-version" is required now.
Option 2 without readonly: The clients only works with the attributes it knows, and all other ones are send unchanged. -> Also "server-update-time" would be send and result in in error.
Option 3 with readonly: The client only works with the attributes it knows, and all other ones, that are not read-only, are send unchanged. -> No conflict.

Of course API versioning can also be handled otherwise, but being able to extend an API with less conflicts/adjustments on client side is IMHO a real benefit.
But the most important advantage is the ability to use per client and/or resource permissions (as already mentioned by @hhware an me before), and these cannot be documented.

The API adds two new attributes "server-update-time" and "resource-version". The first is read-only (as set by the server), the second is always required for updates (to check is the update is based on the same resource state).

It's a BC break as you described it. It shouldn't be roll out in the same version. All the new writable fields for the same version must be optional.
I can't imagine kind of client that automatically starts using any new fields of a response. Looks like magic or AI.
Another option — client works as a "form builder" (as we name it; when response has all the information about all fields: type of field, type of data, length, label and so on). But then you need another data layer, and still json-api will be just a transport.
I.e.
{
    "data": [
        {
            "id": 100100,
            "type": "text-field",
            "attributes": {
                "name": "resource-version",
                "label": "Resource version",
                "data-type": "string",
                "readonly": false,
                "value": ""
            }
        },
        {
             "id": 100102,
            "type": "datetime-field",
            "attributes": {
                "name": "server-update-time",
                "label": null,
                "data-type": "timestamp",
                "readonly": true,
                "value":<PHONE_NUMBER>
            }
        }
        // ...
    ]
}

That way you can change whatever you want without a BC breaks. Otherwise you have to read documentation and make some changes to your client.

@ksimka:
This was just an example. What I wanted to show is, that even if you have an BC break in your API, the client can handle that automatically "without the need to adjust anything". Also if you do it correctly and create a new version for the change, clients can just use the new version! Furthermore I don't know why you concentrate just on this single point, as the most important use case are the client and/or resource dependent permissions.
What do you what to say with your example? You moved the readonly information to the attributes, where it could cause naming conflicts, and it seems that you think about interfaces/forms and how fields are styled there - but this hasn't to do with this suggestion.
readonly is to inform the client which fields cannot be updated on server side, because you don't have the right to do so or because it's generally not possible (for derived attributes). It's aim is to avoid server errors, as well as unnecessary requests, debugging, and manual adjustments on client side for information that can be easily detected automatically. Also it enables resource dependent permissions that can neither be solved by documentation nor by client configuration.

@ziege, my point was that readonly is not a responsibility of json-api layer, I tried to show how you can handle it on the other layer of abstraction.
And still, can you show me an example of a cient that can work without "manual adjustments on client side" when API gets a BC break with a new required writable field? Even with this readonly attribute, I still can't imagine.

@ksimka:
Of course you cannot handle all BC breaks. If a client needs to set own information for attributes, this doesn't work, but it works if a client just sends back the pre-set (default) information it got from the server.

For create request the new attributes don't have to be set, if there is a default value on server side or if the values are set by the server on creation (like the "resource-version" in my example).
For update requests the client knows the possible attributes and send all attributes that are not read-only. New writable attributes are just send back with their default value, and read-only attributes (that would cause an error on server side) are automatically ignored by the client - so the request succeeds without changing the client.

So if the new API version only adds new fields (IMHO mostly the case minor version updates) and provides default values for them, clients can still create and update resources, without having to adjust the code.
Of course they always fall-back to default values until the attributes are explicitly handled by the client, but in the first step the client doesn't break, and perhaps it will never want to support the new attributes (because not relevant for it). So in the ideal case all you have to do is to check the (old) client against the new API version (possibly also automatically), and update the supported API version in the client.

The more I think about attribute types whether protected or read-only I think that information is mostly descriptive not necessarily a ready to add additional structure in a response or within the representation of the attributes. The 'meta' section of the response should suffice for meta info e.g. a list of "read-only" or protected attributes. For example:
{
  "id": "1",
  "type": "person",
  "attributes": {
    "firstname": "Justin",
    "lastname": "Timberlake",
    "signature": "http://commons.wikimedia.org/wiki/File:Justin_Timberlake_signature.svg",
    "date-of-birth": "1981-01-31",
    "age": 34,
    "fullname": "Justin Timberlake"
  },
  "meta": {
    "attributes": {
      "read-only": ["age", "fullname"],
      "protected": ["date-of-birth"]
    }
  }
}

I think the same applies the (proposal) issue I created for "protected-attributes": https://github.com/json-api/json-api/issues/611

@pixelhandler You could do so, and it would result in nearly the same information moved below meta, but with an important difference: The members in meta are not standardized, and I think there should be a standard way to define permissions and enable clients to detect permissions automatically.

@ziege I'm not sure that the JSON API spec can cover every use case for how attributes should be handled. This issue proposes adding 'virtuals', I had an idea to propose 'protected-attributes' based on a use case I have. I'm pretty sure we'll miss a few use cases for how applications should handle attributes. I'm planning on expressing the rules for attribute handling in meta vs. optional/reserved structure for the spec.
Though the members in meta are not 'standard', example solutions for 'read-only' or 'protected' attributes can be included in the spec. Perhaps examples of using meta for these use cases will help to form a best practice.

@ziege

So if the new API version only adds new fields (IMHO mostly the case for minor version updates) and provides default values for them, clients can still create and update resources, without having to adjust the code.

Agree, it's a sane rule. If so, why do you need readonly section? We add new fields from time to time and all works just like you've described.

@ksimka You need it, because some of the attributes are derived attributes and cannot be set by the client (e.g. "age", "order-total", "order-vat",...).

You need it, because some of the attributes are derived attributes and cannot be set by the client (e.g. "age", "order-total", "order-vat",...).

Why server can't handle this? Server knows what fields are writable, so just skip any attempt to write them. Because even if API supports that "readonly" meta info, suppose client has a bug and it still sets those fields. What server will do?
I'm sorry for being annoying, but I really want to understand the needing, maybe we're doing something wrong and we can do better.

Why server can't handle this?

The server could do it, but this would break a basic rule of the spec:
"A request MUST completely succeed or fail (in a single "transaction"). No partial updates are allowed."
On the other hand the client should be informed if there is something wrong (no matter if because of derived attributes or insufficient permissions).

The server could do it, but this would break a basic rule of the spec:
"A request MUST completely succeed or fail (in a single "transaction"). No partial updates are allowed."

Sorry, can't agree. It will completely succeed or completely fail, it doesn't depend on readonly fields. Client sends those fields blindly, it doesn't actually want to update them, so for server is a kind of trash. It's like if I add some random param to request, it'll be just skipped (by most APIs, I suppose), because it makes no sense.

You're mixing things here...
You suggested to send all fields, although unnecessary, and to ignore readonly fields on server side, which would be against basic rules of the spec.
The server doesn't know what the client wants to update or not. So readonly does exactly what is needed. It gives the client the required information to send valid updates that can succeed. Without that the client would send data it isn't allowed to change... Individual permissions cannot be documented. The client either gets the required information before the request or an error after the request - and as it's optional you are free to add this info to avoid errors.
I explained it several times, but it seems that you focus on a special use case in your api and to ignore all other use cases, arguments and examples above... Do I don't think that a further discission with you will result in something constructive.

I feel like we're talking about two different but very similar cases :) So yes, further discussion is meaningless. I think I can explain my point of view verbally in a native language, but not here )
Anyway, thanks for your patience. And if you find (or create) some real example of API with that kind of behaviour (when only "readonly" info helps), please notify me, I'll try to show how it can be handled without any additional info :)

Per our contribution guide, I am closing this discussion here because it is not on our roadmap for 1.1.
I encourage you to continue this dialog @ http://discuss.jsonapi.org.
We appreciate the suggestions greatly, but the core team only has so much bandwidth to deal with new feature requests. Because of this, we are focusing our efforts on empowering the community to create extensions without our direct involvement (until a critical mass of adoption makes it clear that something like this belongs in the base specification).


v1.9 backports 2021-03-19

#14488 -- Bugtool: route tables dynamically dumped (@youssefazrak)
#14568 -- Bugtool: add taskset  (@youssefazrak)
#15228 -- endpoint: Fix the initialization of endpoints' datapath configs (@pchaigno)
#15328 -- contrib: fix remote overriding (@kaworu)
#15323 -- docs: adds a rancher kubernetes engine installation guide (@seanmwinn)
#15321 -- bpf: Skip policy enforcements for service loopback case (@aditighag)
#15365 -- Documentation: fix key rotation command in encryption guide (@mauriciovasquezbernal)
#15363 -- bugtool: dump iptables-legacy and iptables-nft (@h3llix)

Once this PR is merged, you can update the PR labels via:
$ for pr in 14488 14568 15228 15328 15323 15321 15365 15363; do contrib/backporting/set-labels.py $pr done 1.9; done

test-backport-1.9

test-1.19-4.9 hit a known flake #6728

retest-1.19-4.9

@jrajahalme other than looking into the sysdump attached to the failure (See the "Artifacts" box above the output results box here: https://github.com/cilium/cilium/pull/15399/checks?check_run_id=2167272770), in the past I have looked up the specific action and just iterated through the instructions to run the same steps. I think it's typically just a matter of pointing kind towards the right config file under .github and running a few more commands.
I'd like if it were a bit easier, but I think the above is workable?

@jrajahalme other than looking into the sysdump attached to the failure (See the "Artifacts" box above the output results box here: https://github.com/cilium/cilium/pull/15399/checks?check_run_id=2167272770), in the past I have looked up the specific action and just iterated through the instructions to run the same steps. I think it's typically just a matter of pointing kind towards the right config file under .github and running a few more commands.
I'd like if it were a bit easier, but I think the above is workable?

Just did that, run kind locally using the same steps as in .github file, and it succeeded (cubedns became available long before the 5m timeout).

Could the fact that the smoke-test yaml is running 5 jobs in parallel be a factor? Are they all run in the same VM?
If so then relaxing the timeout from 5m to 10m might help?

test-backport-1.9

Closed and reopened to trigger the GitHub actions.

IPv4 version of smoke-test/conformance test keeps failing for the same reason, coredns container stuck on ContainerCreating:
            "status": {
                "conditions": [
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2021-03-24T08:51:06Z",
                        "status": "True",
                        "type": "Initialized"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2021-03-24T08:51:06Z",
                        "message": "containers with unready status: [coredns]",
                        "reason": "ContainersNotReady",
                        "status": "False",
                        "type": "Ready"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2021-03-24T08:51:06Z",
                        "message": "containers with unready status: [coredns]",
                        "reason": "ContainersNotReady",
                        "status": "False",
                        "type": "ContainersReady"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2021-03-24T08:51:01Z",
                        "status": "True",
                        "type": "PodScheduled"
                    }
                ],
                "containerStatuses": [
                    {
                        "image": "k8s.gcr.io/coredns:1.7.0",
                        "imageID": "",
                        "lastState": {},
                        "name": "coredns",
                        "ready": false,
                        "restartCount": 0,
                        "started": false,
                        "state": {
                            "waiting": {
                                "reason": "ContainerCreating"
                            }
                        }
                    }
                ],
                "hostIP": "<IP_ADDRESS>",
                "phase": "Pending",
                "qosClass": "Burstable",
                "startTime": "2021-03-24T08:51:06Z"
            }

@joestringer Do we have access to kubelet logs on failed GH actions? Anything else I could look into?

We also have the k8s events. The last messages for the CoreDNS pods are:
(combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox \"cf2fed496930a0d91f3f21f6c7825b89df08581607f9c66fcff36193978fa519\": Unable to create endpoint: Cilium API client timeout exceeded
(combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox \"ba5551d718be4b94ce880fd423e8254dd576ae825481a4b32e6361a67725c058\": Unable to create endpoint: Cilium API client timeout exceeded

Maybe worth trying to bisect since only two commits actually changed the Cilium code (mine and Aditi's)?

@pchaigno Bisecting on another pr: https://github.com/cilium/cilium/pull/15470, rolled back 4 commits. The failing test succeeded locally with all the commits in though.

 subsys=datapath-loader
2021-03-24T08:51:28.846166423Z level=warning msg="JIT disabled, but 1/5 tail call maps in the program have JITed owner!" subsys=datapath-loader
2021-03-24T08:51:28.846171524Z level=warning msg="Error fetching program/map!"  containerID= datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=3040 file-path=3040_next_fail identity=4 ipv4= ipv6= k8sPodName=/ subsys=endpoint
2021-03-24T08:51:28.858506788Z level=warning msg="Regeneration of endpoint failed" bpfCompilation=3.333051289s bpfLoadProg=32.039088613s bpfWaitForELF=3.333218091s bpfWriteELF="254.004µs" containerID= datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=3040 error="Failed to load tc filter: exit status 1" identity=4 ipv4= ipv6= k8sPodName=/ mapSync="38.401µs" policyCalculation="58.601µs" prepareBuild="301.604µs" proxyConfiguration="9µs" proxyPolicyCalculation="17.3µs" proxyWaitForAck=0s reason="updated security labels" subsys=endpoint total=35.374685036s waitingForCTClean="486.707µs" waitingForLock="9.6µs"
2021-03-24T08:51:28.858717591Z level=error msg="endpoint regeneration failed" containerID= datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=3040 error="Failed to load tc filter: exit status 1" identity=4 ipv4= ipv6= k8sPodName=/ subsys=endpoint

Looks like none-of the endpoints can be regenerated, coredns is just the first one being verified in the test script?

Endpoint list
ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                                                      IPv6   IPv4           STATUS
           ENFORCEMENT        ENFORCEMENT
918        Disabled           Disabled          22009      k8s:io.cilium.k8s.policy.cluster=default                                                <IP_ADDRESS>    regenerating
                                                           k8s:io.cilium.k8s.policy.serviceaccount=coredns
                                                           k8s:io.kubernetes.pod.namespace=kube-system
                                                           k8s:k8s-app=kube-dns
3613       Disabled           Disabled          1          reserved:host                                                                                ready
3828       Disabled           Disabled          4          reserved:health                                                                         <IP_ADDRESS>    waiting-to-regenerate
3837       Disabled           Disabled          8650       k8s:app=local-path-provisioner                                                          <IP_ADDRESS>   regenerating
                                                           k8s:io.cilium.k8s.policy.cluster=default
                                                           k8s:io.cilium.k8s.policy.serviceaccount=local-path-provisioner-service-account
                                                           k8s:io.kubernetes.pod.namespace=local-path-storage

Removed #15321 -- bpf: Skip policy enforcements for service loopback case (@aditighag) as it appears to have caused the smoke-test/conformance-test failure.

test-backport-1.9

Arf! That's a complexity issue again.

Arf! That's a complexity issue again.

It's curious that this only happened in that one test, everything else passed. Must be a unique kernel/cilium config combo?

Pulled the non-backport PR that doubled a test timeout.

test-backport-1.9

It's curious that this only happened in that one test, everything else passed. Must be a unique kernel/cilium config combo?

Most likely because it's the only test running on 5.4.

It's curious that this only happened in that one test, everything else passed. Must be a unique kernel/cilium config combo?

Most likely because it's the only test running on 5.4.

So all the other tests on older and newer kernels passed? 😕


希望引入 try-catch

预试
....
撞南墙
...
回头

Shipped in #399. Closing now. If you got any questions, feel free to reopen it.


[webview_flutter] Force webview to load mobile page

Hi,
When I load my HTML in the webview, the content is really small. Looks like it is rendered for a desktop. How can I make it so it looks good on mobile?
Check the screenshot:

flutter doctor -v
[✓] Flutter (Channel stable, v1.12.13+hotfix.9, on Mac OS X 10.15.4 19E287,
    locale en-GB)
    • Flutter version 1.12.13+hotfix.9 at /Users/tudor/dev/flutter
    • Framework revision f139b11009 (4 weeks ago), 2020-03-30 13:57:30 -0700
    • Engine revision af51afceb8
    • Dart version 2.7.2

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/tudor/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-29, build-tools 29.0.2
    • ANDROID_HOME = /Users/tudor/Library/Android/sdk
    • Java binary at: /Users/tudor/Library/Application
      Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/192.6241897/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4, Build version 11E146
    • CocoaPods version 1.9.1

[!] Android Studio (version 3.6)
    • Android Studio at /Users/tudor/Library/Application
      Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/192.6241897/Android
      Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)

[✓] Connected device (1 available)
    • Tudor’s iPhone 7 • 6c6f39c58d86256962f6a336f8ebef46f202225e • ios • iOS
      13.3.1

! Doctor found issues in 1 category.

I use webview_flutter: 0.3.21
This is how I use the widget:
 WebView(
                initialUrl: Uri.dataFromString(
                  _htmlContent,
                  mimeType: 'text/html',
                ).toString(),
              )

@tudor07
it seems you are missing
<meta name="viewport" content="width=device-width, initial-scale=1">

in the <head></head> of your html.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it

@VladyslavBondarenko works perfectly, thanks a lot


Signed Contingent Inputs

Motivation
Add support for Signed Contingent Inputs
In this PR

create SCI
prepare and submit tx for SCI
cancel SCI

Future Work

ability to reserve input used by SCI to allow other transactions to be completed without potentially invalidating SCI

finished my initial pass, and other than a few nits this looks solid !

whats left on this PR ?

whats left on this PR ?

Should be good to go


bug: settings method of the TikiSdk

reference https://github.com/tiki/examples/pull/6#issuecomment-1529627450

quoting the original comment

When we trigger the opt out button in the settings method of the offer the onAccept() functionality of the offer works as mentioned in the lib/home_screen.dart. Also Opt in button triggers the functionality of the onDecline() method. This should not happen I guess. (Probably a bug?)

Adding to Sprint 70 for investigation.

The variables were switched. Done in #264


[NFC][test] Remove unused test file

Remove complete_type_any.swift.tmp.types.txt. It was probably added by accident.
Also complete_type_any.swift doesn't need to use temporary file for FileCheck.

@swift-ci Please smoke test


Running the inline analyzer on a package where it would inline multiple functions leads to duplicate suggested fixes that some tools cannot deal with (including the analysistest package). As far as I can tell it tries to remove the import twice. In general it seems to be an issue that it always tries to remove the import even if it is still needed (see example below).
Here is a self contained reproducer test:
func TestRemovingImport(t *testing.T) {
	files := map[string]string{
		"some/package/pkg/foo.go": `package pkg

			// inlineme
			func ToInline () {}

			func Bar () {}
		`,
		"b/c/foo.go": `package c

			import (
				"some/package/pkg"
			)

			func foo() {
				pkg.ToInline() // want "inline call of pkg.ToInline"
			}

			func bar() {
				pkg.ToInline() // want "inline call of pkg.ToInline"
				pkg.Bar() // ok
			}
		`,
		"b/c/foo.go.golden": `package c
			func foo() {
			}

			func bar() {
			}`,
	}
	dir, cleanup, err := analysistest.WriteFiles(files)
	if err != nil {
		t.Fatal(err)
	}
	analysistest.RunWithSuggestedFixes(t, dir, analyzer.Analyzer, "b/c")
	cleanup()
}

What did you see happen?
The example fails with:
...analysistest.go:263: /tmp/analysistest3675113240/src/b/c/foo.go: error applying fixes: diff has overlapping edits (see possible explanations at RunWithSuggestedFixes)

What did you expect to see?
I expected the analyzer to not remove the import when it is still needed and if it is no longer needed to only remove the import once.

cc: @adonovan

I plan to improve the API for the inliner so that it includes (for example) options to control literalization, consideration of side effects, and suchlike. I think it might also be useful (and I seem to recall writing a TODO comment to this effect) to return not just one but diff, but a more structured result that separates the diff around the call site and the logical changes to the import declaration. This would also allows Bazel/Blaze to interpose their visibiliity checking.

We may also need to make the -fix conflict checker more tolerant to redundant but identical diff chunks.

So what you are saying is that it is not the Analyzer to deduplicate these findings but it is the user of that analyzer to determine this?
I think it is a general problem that you want fixes to be independent of each other so that you can apply them independently?
I don't think this works because following that, you can never generate an import removal unless it is the only usage of that import in the file. Because as soon as there are two or more usages, removing any of them (independently) would require keeping the import because of the other usage.
In other words, the inliner should only ever remove the import if it is removing the only usage of that import. If it is removing something and there is another usage, it should not generate an import removal (even if there are other suggested fixes removing all other usages).
Side note: especially in case where there are usages that are not removed by the inliner, it should not generate a suggested fix to remove the import as it does right now.

You raise a number of good questions. You're right that in general two fixes may be safe individually but not together, for example because they each remove the second-last reference to an import. Or that two fixes may spuriously conflict with each other because they each try to remove the same import; a simple conflict resolution strategy would work in this case.
We don't yet have a good calculus for composing fixes. Perhaps analyzers shouldn't even try to solve the goimports problem (since it isn't composable), and the driver's -fix flag should run goimports after any batch of fixes.

In other words, the inliner should only ever remove the import if it is removing the only usage of that import. If it is removing something and there is another usage, it should not generate an import removal (even if there are other suggested fixes removing all other usages).
Side note: especially in case where there are usages that are not removed by the inliner, it should not generate a suggested fix to remove the import as it does right now.

I totally agree, but it sounds like you are describing a plain and simple bug. If the tool prematurely removes an import while there is still an existing use, please file a bug report and I will fix it.

I totally agree, but it sounds like you are describing a plain and simple bug. If the tool prematurely removes an import while there is still an existing use, please file a bug report and I will fix it.

I thought saw a but while preparing this example and then was to lazy file a separate bug which is why I folded this into this one. You prompted me to look into this again and while I was trying to reproduce this, I noticed that my report here is incorrect.
The duplicate findings are not the import removal but the formatting changes.
To summarize:

The inliner does not generate any import removals for the given example. Even when you remove the call to pkg.Bar, it does not remove the import.
The inliner produces duplicate suggested fixes to remove the identation. Note that all of the files are not properly indented so that they fit better into the test structure. All lines are indented by three \t and the inline analyzer attempts to remove these \t on each suggested fix.

I'm not sure if this is considered a bug or if the inliner is only supposed to work on files that a formated with gofmt.
Feel free to close this issue if you think this is intended behavior and sorry for the noise.

I plan to improve the API for the inliner so that it includes (for example) options to control literalization, consideration of side effects, and suchlike. I think it might also be useful (and I seem to recall writing a TODO comment to this effect) to return not just one but diff, but a more structured result that separates the diff around the call site from the logical changes to the import declaration. This would also allow Bazel/Blaze to interpose their visibiliity checking.

@adonovan is this the TODO you're referring to -
https://cs.opensource.google/go/x/tools/+/master:internal/refactor/inline/inline.go;l=55-58?
I was looking to contribute to the inlining part of the codebase and came across this when I was trying to understand it.

In our meeting today we decided on an agreed interpretation of multiple fixes:
Each Diagnostic has a set of associated SuggestedFixes, each of which are logical alternatives; if there are more than one, the user must choose at most one. Once these choices have been made, we have a set of fixes to apply. Conceptually, all of these fixes are independent changes to the baseline file state, analogous to git commits with the same parent.
To combine them, we must merge them in some order, analogous to a git merge. Each merge may succeed, if the accumulated changes and the latest change do not overlap, or if the overlapping parts are changed in the same way; or it may fail, in which case the user must be informed of the conflict, and the latest change must be rejected. (It's up to the tool whether it proceeds as best it can with the next change, or aborts the whole operation, so long as it reports the error.)
Naturally, the quality of the merge algorithm will determine how robust it is. Our existing conflict logic can de-duplicate identical changes, such as redundant additions of the same import at the same place, but nothing more; by contrast git-mergetool can often successfully resolve more complicated conflicts.
I propose to document this approach at analysis.SuggestedFix, and (eventually) to implement it in checker -fix and in gopls. Though I expect some common logic to resolve a set of fixes will be usefully shared among the various tools, we needn't discuss it here since we don't plan to share it.
The original problem in this thread is that RunWithSuggestedFixes tries to apply all the suggested fixes at once. I hit exactly this problem this morning in the context of https://go.dev/cl/592155, and the solution in that case was to rewrite the test to use a txtar file as the .golden file, withinstead of the go.


Pyperclip not working on MacOS Sierra?

Hello, I'm going through Automate the boring stuff with Python and I couldn't make pyperclip work for me.
 I know the 'u' is for unicode, but why isn't it working with my clipboard?
I'm sorry if the question is a bit vague. I'm still pretty noob.

The relevant code is follows:
def init_osx_clipboard():
    def copy_osx(text):
        p = subprocess.Popen(['pbcopy', 'w'],
                             stdin=subprocess.PIPE, close_fds=True)
        p.communicate(input=text.encode('utf-8'))

    def paste_osx():
        p = subprocess.Popen(['pbpaste', 'r'],
                             stdout=subprocess.PIPE, close_fds=True)
        stdout, stderr = p.communicate()
        return stdout.decode('utf-8')

return copy_osx, paste_osx

and the code to use that clipboard type is:
def determine_clipboard():
# OMMITED
    if os.name == 'mac' or platform.system() == 'Darwin':
        return init_osx_clipboard()

This means that for OSX it's executing pbpaste/pbcopy when it detects the platform is OSX/Darwin, could you try maybe manually running those functions above and seeing if there is any errors in the interpreter?
You can manually init another clipboard too, so you can force the module to use init_osx_clipboard for the case where it's not being detected as being OSX properly.

os.name is posix on macOS Sierra:
Python 2.7.12 (default, Sep 28 2016, 18:41:32)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
.>>> import os
>>> os.name
'posix'
>>> import platform
>>> platform.system()
'Darwin'
>>>

And has been for some time. Anyway, here's a PR: https://github.com/asweigart/pyperclip/pull/78.
But os.name == 'mac' or platform.system() == 'Darwin'is still True.
Anyway, I get this in IDLE:
$ pip freeze | grep pyperclip
pyperclip==1.5.27

$ python
Python 2.7.12 (default, Sep 28 2016, 18:41:32)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyperclip
>>> pyperclip.copy('Hello World')
>>> pyperclip.paste()
u'pyperclip.paste()'

But it works in a script:
$ cat test.py
import pyperclip
pyperclip.copy('Hello World')
out = pyperclip.paste()

assert out == 'Hello World'
print "Done."

$ python test.py
Done.

Running this on Sierra 10.12.1 and it works fine both within a script and in IDLE

@GenericError With which Python version?

Python 2.7.10 with Pyperclip 1.5.27

This is now working for me too.
I was still get the same problem (with macOS Sierra 10.12.2 / Python 2.7.12 / Pyperclip 1.5.27). I then uninstalled, and tried again using this cloned repo (ran python in the repo, didn't run python setup.py anything) and got the same problem.
I added some debugging prints, ran pyperclip.copy('Hello World') and then in another terminal window ran pbpaste and got "Hello World", so the copy was working fine.
I then switched to another directory, pip installed pyperclip again, and it was working in a global install for IDLE too. So I didn't really do anything than run pbpaste in another window. Perhaps that initialised something?

The problem still happens for me in IDLE with pyperclip-1.5.30 (macOS High Sierra, both Python 2.7.14 and 3.6.3), but I don't personally need to use it in IDLE. Via script is fine.

Reopening this, although I can't reproduce this issue on my Mac (El Capitan with pyperclip 1.5.31 and Python 3.6.1 and Python 2.7.10 (both from IDLE).

it work for me!
def clipboard_read():
    p = subprocess.Popen(['pbpaste', 'r'],
                         stdout=subprocess.PIPE, close_fds=True)
    stdout, stderr = p.communicate()
    return stdout.decode('utf-8')

def clipboard_write(text: str):
    p = subprocess.Popen(['pbcopy', 'w'],
                         stdin=subprocess.PIPE, close_fds=True)
    p.communicate(input=text.encode('utf-8'))


Put executable somewhere friendly on build

When you zig build, currently the oxid executable lands in a hash-named subfolder of zig-cache. Figure out how to get it to output somewhere nice too

made it output to zig-cache.


added regexpMathScalar

Summary of the changes / Why this improves CrateDB
Added RegexpMatchScalar
Submitting this pull request as a solution to the following issue: https://github.com/crate/crate/issues/15117

Created a class, implementing it similar to the existing RegexpMatchOperator.
Instead inherited it from Scalar instead of Operator
Had it support the use of flags.
Updated ScalarFunctionModule.java to register it as a function

Checklist

[ ] Added an entry in the latest docs/appendices/release-notes/<x.y.0>.rst for user facing changes
[ ] Updated documentation & sql_features table for user facing changes
[ ] Touched code is covered by tests
[✓] CLA is signed
[✓] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in the latest docs/appendices/release-notes/<x.y.0>.rst
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

Can one of the admins verify this patch?

@Lyra126
Thank you for this contribution.
Probably I confused you by my comment https://github.com/crate/crate/issues/15117#issuecomment-1909597298 that the scalar is almost equal to the existing operator. But the scalar should return the matched values, so the return type should be a array of strings ->DataTypes.STRING_ARRAY.
See also the example in the original issue request, this example must work.

Thank you for your continuous review and help with this issue! This is my first time contributing, and I appreciate the help and clarification. Let me know if I'm missing anything else.

@Lyra126 Any updates on this, do you need additional help?

@Lyra126 Any updates on this, do you need additional help?

Yeah, I’ve realized that I’m a bit lost and may not have the necessary experience to resolve this. I’d like to step back so that someone more familiar with the project can take over. Thank you for checking in though.

@Lyra126 Ok thank you for trying, I'll close this then.

Hello @seut , can I work on this please?

@bhaskar16 Sure, go ahead, thanks!
Btw. we stopped assigning tickets as this assignment got stale a lot of times as people did not progress on the development while also not inform us. So just go ahead on working on an issue and create a (Draft) PR asap so we can see your progress.


Iframe height set to 150px from child page that renders PHP

I'm having an issue where the parent iframe was always configured to 150px height no matter the child's height, despite trying to poll or callback a pymChild.sendHeight() function. I did some testing and it appears to have something to do with PHP code I have in the child file to load data that populates the page.
Just wondering if there are known issues regarding height adjustment and PHP on the child. Thanks!

Had the same problem using Semantic-UI, which applies a 100% height on .


fix: revert "fix: revert error to previous protocol (#139)

This reverts commit e053b895503d5a29522404ce14e13239b6db7852.
We reverted the protocol changes for error messages like the friendly rate limit message in the Chat. Now that we're using the latest protocol with structured outputs, we need the new version again

:tada: This PR is included in version 1.10.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add /truefact command using Random Useless Facts API

Command Name
/truefact
Public API Resource
https://uselessfacts.jsph.pl
Description
The command should display a random true fact.
Remember to add the url parameter ?language=en to get the response as JSON.
Implementation Details

Add a new javascript file in the commands folder
Implement a API request with the help of axios to your public API
Format the data in a readable way and send it to the user
Use the discord.js docs to get started

Code of Conduct

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

Hey @thieleju,  please assign this to me.

Alright, happy contributing!

Can You Assign This to Me? I can do it in an hour

Hi @Madhvik007, this issue is already assigned to JatinSingh08.
But you can create your own issue and I'll assign you to it.

Hey, @JatinSingh08. There are about two more weeks to Hacktoberfest. Do you need any help setting up the project?
Feel free to ask me :)

Only a week left for Hacktoberfest, this issue is up for grabs again

@thieleju Please assign it to me!.
Thank you.

Hi @hkmekala. Since you volunteered for this issue, #53 and #17. Which would you like to work on? Unfortunately only one issue per person is allowed :)

Hi @thieleju,
I'll take #17, Thank you.

Hey, can i take it?

@KY-Y0 Sure, go ahead!

@KY-Y0 Great work!
I reviewed your pr #147 and labeled it with the hacktoberfest-accepted label.
Keep contributing ❤


CI for PBSPro using Docker

This issue is derived from #2. The goal is to add some CI configuration for testing PBSCluster on a toy dockerized cluster. See work done in #23 and #27 for SGE.
Some useful comments:
https://github.com/dask/dask-jobqueue/issues/2#issue-301592217
https://github.com/dask/dask-jobqueue/issues/2#issuecomment-370237199

I'm still up for this one, but I've not really worked on it so far. Hopefully in the next few weeks, but if someone has more bandwidth and is willing to try, that's fine with me.


Build database

Store each call in a database in order to begin tracking how many requests we are making.

[ ] Build table with email, image link or base64, [descriptions], createdOn, isRefineAttempt
[ ] Build table based off of the image itself in order to track common images
[ ] Implement table viewers into the admin and personal pages for users to either return to a query or for administrators to properly track data
[ ] Collect data from users at point of returning submission in order to collect all relevant data.

On hiatus to focus other portions of the project.

Looking for someone to continue working on this. There exists a branch which returns an error that begins to setup astro:db. There is an error with no relevent solutions online yet as astro:db is new. Should consider using a baked in Azure solution or as Alex Waltrip has setup, a json db using astro.


fix: clear WinToast on exit

this might fix a rare crash on shutdown on Windows
There's still room for other crashes (e.g. if TwitchChannel calls getApp()->getNotifications() during shutdown), but this patches a tiny hole at least.
Fixes #5601

I haven't tried this but I assume it doesn't explode your PC. Some windows user can test this when this lands in nightly


Code analysis c26495 as error

Summary of the Pull Request
Based on pull request #21085 this pull request turns on the code analysis rule "C26495 - A member variable isn't initialized" as error and fix all errors.

PR Checklist

[X] Continue towards: #940
[X] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[X] Tests: Added/updated and all pass - No test was update or added, and all tests still passing.
[X] Localization: All end user facing strings can be localized - No Changes to strings
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments
Based on pull request #21085 this pull request turns on the code analysis rule "C26495 - A member variable isn't initialized" as error and fix all errors.
The errors are fixed by using default member initialization.

Validation Steps Performed
The unit test were run and all passed.
The CI job passes.

FYI this has a conflict


MUU-42: Notifications to client

Purpose of this larger ticket set is to enable server side notifications to client , that will show user either dialog or banner to inform user on different matters, including ones blocking usage i.e. server outage. Multiple sub task tickets included within pr. Tickets will have link to this single pr.
Added to scope rework of the snackbar/banner ui logic.

Screenshots of common use case ui elements included to MUU-348

NOTE!
For notifications route to be able to properly function enviroment variable "NOTE_MONGO_URI" should be set.
If not set routes mongo operator will result to undefined and usage in "get" catches it and defaults to returning empty array.


fix(release): update semver alongside release

:tada: This PR is included in version 1.3.7 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


⚠ PrivateHD has degraded performance

In ac3b083, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 1362 ms

Resolved: PrivateHD performance has improved in 5a24365.


When srtcp is encrypted with gcm, it cannot pass the auth authentication when srtcp is decrypted?

Your environment.

Version: v2.0.1
Browser: chrome 87.0.4280.141
Other Information - stacktraces, related issues, suggestions how to fix, links for us to have context

What did you do?
I use pion/webrtc to establish a connection with webrtc on the browser, and then when the browser returns rtcp information (such as nack), pion/webrtc will return an unpacking error message. After following up, it was found that the error came from the decryption verification of srtcp (srtcp.go:18). The established srtcp uses gcm encryption. I found that the SRTP_AES128_CM_HMAC_SHA1_80 encryption method has a generateSrtcpAuthTag call (srtp_cipher_aes_cm_hmac_sha1.go:138), but SRTP_AEAD_AES_128_GCM does not. Is this the cause of the problem? After I switched the encryption method of srtcp to SRTP_AES128_CM_HMAC_SHA1_80, this problem disappeared.
--From google translation

Thank you so much for the bug report!
I am looking into this now. Will try to resolve quickly, sorry for the delay.

Fixed!
Mind trying new version of Pion WebRTC https://github.com/pion/webrtc/releases/tag/v3.0.14 ?
thanks for reporting this


Make MA.M more MVVM-friendly

There are some things in our library that can be made for or improved for MVVM scenarios. We should try to figure out how to make those non-friendly sections more friendly. (Feel free to discuss here or in gitter.)

Dialogs aren't exactly as MVVM friendly as they should be.
FlipView isn't designed for MVVM scenarios. - #998 - see PR #1040
Flyouts.... ugh.

Can a contrib project be launched, now that MahApps is in v1.0 stage, that folks can start dumping what they've done to solve common problems in the MVVM space (e.g. showing a dialog via an IDialogManager) in some sort of way that makese sense?

I've started with my own (opiniated) MVVM library based on MahApps.Metro, see TinyLittleMvvm

Meantime, I've discovered Caliburn.Metro which seems to be a good start in this direction (Caliburn.Micro + MA.M)

link @papuashu ?

@dealproc Caliburn.Metro

@remcoros I might be missing something in here. Where do you specify the UserControl that should appear inside the Flyout? In case of multiple Flyouts, how do you specify that? Thanks


Peek Address apperances with Trueblocks?

Range queries can be hard to do efficiently without hammering a node because asking for "Vitalik transactions from block 0 to now" may require checking every block. This is a problem if someone has to rely on remote public node with rate limits.
We don't strictly need every block to answer that query, but without knowing which blocks contain Vitalik transactions, what choice do we have?
Trueblocks is an indexer whose maintainers provide an IPFS-hosted unchained index which can be used to find all blocks containing an "apperance" of a given Ethereum address.
The Unchained index is updated regularly, but infrequently (I think last update was 30 days ago)
Still, if we pretend to have accurate index, we can try such strategy:

start with address we want to check -> vitalik.eth -> resolves to 0xabc...
download some chunks of unchained index via chifra to find all apperances of that address, we now have list of relevant blocks
query only relevant blocks via RPC-API, cryo or whatever tool EQL uses under the hood

The caveat is this would makes performance better for obscure addresses yet worse for popular ones:

The number of index chunks you download depends entirely on the addresses you query. Of course, if you query a lightly used address, very few chunks will be downloaded. However, if you query are heavily used address, such as UniSwap, nearly every chunk will be downloaded

This could be blind alley, but I think it is worth checking out so would happy to test how many "chunks" are needed by chifra and report the results.

I spent sometime digging into Trueblocks and here are some thoughts:
Pros:

The project is aligned with EQL's end-game when it comes centralization vectors in the space. It distributes the index via IPFS to make faster to sync data locally, this is really similar with what I described as a possible solution in the release post.
Once synced, queries are really fast.

Cons:

Leverage Trueblocks' index implies that every user/application will need have a local indexer running, since Trueblocks doesn't provide a crate to be compiled along with EQL.
Users would need to wait until their local indexer is synced before running queries, which is somewhat a bad UX.

In regards to heavily used addresses and I think we should be fine given users the option to wait for large queries or to provide a max amount of records being returned.

so would happy to test how many "chunks" are needed by chifra and report the results.
That would be amazing!

Tried chifra init which is supposed to be fast-now, slow-later. This indeed turns out to be true.

For crypto OG address like owocki.eth the lookup with chifra list takes 5 minutes or more.
For lite-address with 30 transactions lookup happens in seconds though.

I am not expecting magic to happen - someone has to trawl the blockchain and download the data, but as you hinted running an indexer that trawls IPFS is only "slightly less bad" UX-wise than running a full node.
Maybe Trueblocks folks can figure something for the skill issue I am having here - but for now it looks like we traded hammering JSON-RPC node for hammering IPFS gateway.
This seems a bit hardcore to implement, but hopefully that fancy BTree structure presented in the paper would prove to be more efficient.

For crypto OG address like owocki.eth the lookup with chifra list takes 5 minutes or more.
For lite-address with 30 transactions lookup happens in seconds though.
This doesn't sound bad, actually. Better than expected. Tysm for the report!

Maybe Trueblocks folks can figure something for the skill issue I am having here
I believe that's a limitation of Trueblocks design, not a skill issue.

This seems a bit hardcore to implement, but hopefully that fancy BTree structure presented in the paper would prove to be more efficient.
Yepp. But hopefully we'll find a way to safely distribute that tree using something like IPFS. Not trivial to implement though.

Leverage Trueblocks' index implies that every user/application will need have a local indexer running

In the end, it's our belief that if we actually want censorship resistant, distributed private access to our own data everyone will do this naturally. In fact, we think this should not only be in the node, but that the node should be in the operating system.

In the end, it's our belief that if we actually want censorship resistant
That's exactly what EQL wants to build. Something along the lines of a distributed version of Dune

you get 4GB of bloom filters which is how we know which larger parts of the index you need
How frequently the remote bloom filter is updated?

This touches a bit on what EQL wants to be.
Using the example on the original post: “I want block’s information about all the blocks in which Vitalik made transactions.” A data provider that indexes blocks and transactions can easily solve this. You can make a simple query like the one below:
WITH vitalik_tx AS (
	SELECT block_number
	FROM ethereum.transactions
	WHERE "from" = 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 --vitalik.eth
)
SELECT *
FROM ethereum.blocks b
LEFT JOIN vitalik_tx t ON  b.number = t.block_number

All indexers provide APIs to make the same logic as the SQL code above. The only reason you can’t do this with a simple RPC is that although nodes store all transaction data, they don’t index it by sender address, so you can’t filter the transactions by the sender—a trivial indexing functionality.
Now, if you don’t want to use a data provider that indexes those raw data for you, you would need to index the data yourself. That would be fine, but EQL is already targeting users who don’t want to run nodes themselves by using RPC providers. What is the point of requiring a user to index data?
Full decentralization means you need to do the job yourself.
Why don't Ethereum clients (or the protocol) already index transactions? It does this for logs using the logs bloom. I think this comes with a design decision by generic client's devs. They are building clients for everyone, and they reasoned that not everyone would want this functionality. Nothing prevents you from making your own client fork that index and distributing it for anyone to run.
Now, EQL could develop tools to make indexing easier and cheaper because if it’s easier and cheaper to index, more businesses can provide it, which will lead to more competition, cheaper access, and less trust and dependency in one player. If you’re doing this, you would probably want to catch up with the tip of the chain, which requires your own node. Indexing would be just a simple extension to better store the data a node already has.
Maybe I'm explaining something that is obvious to anyone in this conversation; if that's the case, sorry for that.

This was obvious to us seven years ago. That's why we've been arguing indexing should be part of the node software. But blind Web 2.0 like indexing will never work. It's monotonically increasingly large. It never gets smaller. That's why TrueBlocks "shards and shares naturally" as we discuss here: https://trueblocks.io/papers/2023/specification-for-the-unchained-index-v2.0.0-release.pdf.
Distrubuted data, in our opinion, cannot be in a monolithic database "provided" by providers. Every single participant must carry their own weight -- and share the portion of the data they carry. And, that carrying must be heavily redundant. And it has to be always on. And always pinned. That's why not only must users run nodes, but they must also run file sharing nodes such as IPFS.

Here's an article we wrote recently showing why indexing is so important: https://github.com/TrueBlocks/trueblocks-compare/blob/main/results/with-3-providers-2024-06-26.md. Pay attention, in particular, to The Results secion.


Making the codebase more general

Codecov Report
Patch coverage: 22.65% and project coverage change: -15.70% :warning:

Comparison is base (894e95c) 56.31% compared to head (c12c07e) 40.61%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main      #59       +/-   ##
===========================================
- Coverage   56.31%   40.61%   -15.70%
===========================================
  Files          16       18        +2
  Lines         950     1492      +542
===========================================
+ Hits          535      606       +71
- Misses        415      886      +471

Flag
Coverage Δ

unittests
40.61% <22.65%> (-15.70%)
:arrow_down:

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

Files Changed
Coverage Δ

ocean_model_skill_assessor/plot/map.py
15.32% <ø> (ø)

ocean_model_skill_assessor/main.py
19.48% <4.53%> (-19.41%)
:arrow_down:

ocean_model_skill_assessor/plot/surface.py
16.41% <16.41%> (ø)

ocean_model_skill_assessor/accessor.py
34.14% <23.33%> (-23.00%)
:arrow_down:

ocean_model_skill_assessor/plot/scatter.py
36.36% <36.36%> (ø)

ocean_model_skill_assessor/plot/line.py
39.13% <39.13%> (ø)

ocean_model_skill_assessor/paths.py
62.50% <40.00%> (-27.98%)
:arrow_down:

ocean_model_skill_assessor/stats.py
51.21% <42.40%> (-33.63%)
:arrow_down:

ocean_model_skill_assessor/utils.py
55.02% <45.12%> (+1.38%)
:arrow_up:

tests/test_plot.py
100.00% <100.00%> (ø)

... and 2 more

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


Fix k8s slack link in main navigation

Signed-off-by: Carlisia Pinto<EMAIL_ADDRESS>This fixes the slack link in the main navigation:

Currently it points to a non existing channel ark, but it needs to point to ark-dr.

LGTM!


Fix min/max position not being correct due to multithreading

The code was in place to handle this:
			// merge min/max of this batch into global min/max
			for (int i = 0; i < outputAttributesCopy.list.size(); i++)
			{
				Attribute &source = outputAttributesCopy.list[i];
				Attribute &target = outputAttributes.list[i];

				lock_guard<mutex> lock(mtx_attributes);
				target.min.x = std::min(target.min.x, source.min.x);
				target.min.y = std::min(target.min.y, source.min.y);
				target.min.z = std::min(target.min.z, source.min.z);

				target.max.x = std::max(target.max.x, source.max.x);
				target.max.y = std::max(target.max.y, source.max.y);
				target.max.z = std::max(target.max.z, source.max.z);
			}

However, outputAttributesCopy min/max was never being set; instead, outputAttributes min/max we being assigned to directly. As a result, the code above did not do anything, and outputAttributes got improperly assigned/overriden by multiple threads.

This is specifically for the position attribute, which doesn't get an attribute handler that populates the copy as it should, right?
Your PR seems to make sense. Thanks!


Fix release CI

With the bump to chart releaser 1.5.0 we lost the ability to do cr index with an ssh git remote, which is the type of remote that circleci uses.  As a result, the circleci job could not run the cr index step of the release.  An attempt to fix this issue was made with https://github.com/honeycombio/helm-charts/pull/250, but it was unsuccessful.  As a result, we have had to do the cr index step locally, which is annoying.
We need to update our release script or the CircleCI job so that it plays nicely with chart releaser.

Doing some testing, it seems CircleCI is replacing any instance of and https remote with the ssh remote when running the git remote command.
In CircleCI when I run
git remote add origin-https "https://github.com/$GIT_REPOSITORY_OWNER/$GIT_REPOSITORY_NAME.git"
git remote get-url --push origin-https
git remote -v

the output is
<EMAIL_ADDRESS>origin	git@github.com:honeycombio/helm-charts.git (fetch)
origin	git@github.com:honeycombio/helm-charts.git (push)
origin-https<EMAIL_ADDRESS>(fetch)
origin-https<EMAIL_ADDRESS>(push)

Issue was that circleci's global git config for the job had url.ssh://git@github.com.insteadof=https://github.com/.


Image upload

We will need image upload for setting user avatars. It would be preferred to use a third party service instead of saving the files locally on disk.
Maybe look into using supabase as it can be self hosted.

https://www.postgresql.org/docs/7.4/jdbc-binary-data.html


Access to react-bratus organization in npmjs

Hi team,
If you want to push updates to the npm package, you should have access to the react-bratus organization on npmjs.
If you provide me with the e-mails of those who need access, then I can add you :-)
Best,
Stephan

Great @stephanboersma.
<EMAIL_ADDRESS>

I have invited you, @Evgenios95


How to get the origin pixels values from pixmap?  Is that possible?

How to get the final image pixels from pixmap?
Is that possible? Would you please tell me?
Now I could get the PNG file with the pixmap in the resvg project,  but I couldn't read the pixel from pixmap now and I just want to convert svg to raster image. And the input svg may is the group of raster image and vector graphics, and I want to be able to perform image pixel manipulation on the converted raster image data.

See https://github.com/linebender/resvg/blob/main/crates/resvg/examples/minimal.rs
The pixmap variable would have your pixels.

Yes, but I would like to tunning pixels directly in the pixmap, but they are priviate, not allow me to modify them, how to do that?

Yes, I would like to get the red, green, and blue pixel values for all pixels from the pixmap.
Could you please tell me how to modify that?

I think you should be using pixels_mut here. You should be able to replace the pixels if you use the method to get exclusive access to them, but of course you can't mutate them from a shared reference.


Bulk Update for Members

I was wondering if there is a possibility to improve bulk update on members?
In my game there are events, that basically recalculate almost every score for a whole leaderboard. Maybe an implementation based on batch or multi. Especially since batch seems to improve bulk updates significantly (400% as stated on node-redis)

There is the rankMembersIn method, https://github.com/agoragames/leaderboard-coffeescript/blob/master/src/leaderboard.coffee#L189-L202. This uses multi.

Ahh somehow skipped over it. I am thinking if it would make sense to also offer a batch version, maybe with an additional parameter {safe: false}. But first I will check the performance with multi.


Make flake8 ignore tox folders

Coverage remained the same at 94.483% when pulling 5c61a4e52e2cbe0288e4c5c8a51b7b3eb3c4ecc8 on thomwiggers:faster_flake into 296ca8dbcf67d561be9781b60a9ae55b8861caf5 on dahlia:master.