Links, relationships, discoverable actions, mapping to RFC5988

This proposal is a successor to #590. I would like to request to consider this for 1.0 because it won't make much sense afterwards.
@ethanresnick has submitted #618 while I was thinking about this. Even though the content of #618 is a part of what is proposed here, the scope of this issue is different from #618, so I am not hijacking #618...
Motivation

Five HTTP verbs are not enough to describe all possible actions available for a resource in a complex API. The solution is to add custom endpoints. There should be a way to associate those custom endpoints with the primary endpoint of the resource.
It would be great if JSON API allowed to build HATEOAS-compatible APIs. This requires ability to dynamically determine which actions can be taken on a given resource and its relationships, as well as what are the starting points to explore the API without much prior knowledge about it. It is often important for the clients to save trips to the server, so such information should be returned as part of a response, not on a separate endpoint.
Bring consistency to top-level and resource-level links and to relationships. A lot has been said on this. One thing I am trying to solve here is that each relationship provides multiple links, whereas members of top-level links and resource-level self are singular links, so they are not similar at all, one is a actually a component of another. Another aspect of it is making all links have the same structure, which can also be considered as a step towards the concept of "links can appear anywhere" (https://github.com/json-api/json-api/pull/588#issuecomment-98261811).
It would be useful to allow implementations to provide various links relevant to the given resource or response object, whether "verbs" or "nouns", whether representing actions on the endpoints of resource/its relationships/custom endpoints, or different aspects/views/versions/etc of the given resource, or anything else related to the given resource. Currently, only a very limited set of links is allowed (relationships, pagination, self), and meta is the only option for those who need more. It is workable, but it will drive fragmentation in the emerging JSON API ecosystem.
Provide an implementation of linking in JSON: allow association of RFC5988 Link Relations to all links. This must be optional in order not to affect adoption of the spec.
Make links extendable: they are currently defined as strings, which does not allow to add any customization/context to them, either in basic spec in the future or via extensions today.
While achieving all this, the subset of the spec which defines minimally required data structures should not become much more complicated than it currently is, so that adoption is not affected.

Proposed changes

Move relationships under resource-level key relationships, keeping self under resource-level key links. Relationships consist of relationship objects (formerly link objects) keyed with relationship name (#618). [This is implemented in #618, #625]
Relationship objects consist of 3 members: links, linkage, meta (at least one is required). [This is implemented in #618, #625]
Member links has identical definition whether it occurs on top, resource, or relationship level. [This is implemented in #618, #625]
Two forms of member links are possible: full (always available) or simplified (only available in special cases).
Full form of member links: an array, each element of it is a link object.
Define link object in the spec as an object having the following members:
name: required, self-explanatory,
href: required, self-explanatory,
class: required, classification of link type. It is a CSV-string with elements from the following set: general,pagination,action,version,hierarchy,custom (this set is obviously meant to be extendable in the future). Each link may have multiple classes. Elements of the set mean the following:
1. general (could not find a good name for it): for generally applicable links (possible values: self,related,type,copyright,help),
1. pagination: includes pagination members in top-level and relationship-level links (possible values: prev,next,first,last),
1. action: actions on the given resource or relationships, available to the given user at the given moment of time, either at the resource's own endpoint or at some custom endpoint (possible values: create,update,delete,explore; general self substitutes the action of reading the current resource/relationship -- we might want to try to eliminate this inconsistency),
1. version: links pointing at other versions of the given resource or providing versioning information about it (possible values: version-history,working-copy,successor-version,predecessor-version,latest-version,latest-published-version, see RFC5988),
1. hierarchy: links for handling hierarchical content (possible values: up, see RFC5988),
1. custom: all other (yet unclassified) links.
method: optional, contains HTTP verb,
rfc5988: optional, allows to add RFC5988 Link Relations. If defined, it should contain an object consisting of members keyed by names of link-params from RFC5988 or its extensions. URI-Reference is considered to be set in href.
Attributes share namespace with relationships but not with links.
In each given member links, each link object is identified by a pair name and class (canonicalized, e.g. with elements sorted alphabetically), so such pairs must be unique. (Alternatively, class can be defined as array, e.g., "class":["pagination","custom"]: alphabetic reordering and serialization are needed for use as key.)
The spec should be able to reserve names of links of standard classes in order to have freedom for future extensions, but at the same time it would be useful if the spec allowed implementations to extend standard classes or define completely arbitrary links. To achieve that, the spec reserves possible ranges of values of name for link objects classified with one of general,pagination,action,version,hierarchy. Link with class having any other value or any combination of values including any other value can have unrestricted name. E.g., if a link has "class":"pagination", it could only have name as one of prev,next,first,last, but if it has "class":"pagination,custom" or just "class":"custom", its name can be anything. All reserved values of name defined by spec must be unique, regardless of class. Proposed values per class to be defined by the spec are listed above in parentheses.
If member links only has link objects classified with single class, none of which is custom, and none of link objects has optional members, then such links can be returned by the server in simplified form: an object where values of href are keyed by values of name (class can be derived from name because name is unique for non-custom link classes). As of #625, the simplified form is just a tiny bit more complex than the current version of the spec. Perhaps the full form can be described in a separate section of the base spec, not in the primary text flow of the spec. On another hand, support for full form could be an official extension, but IMHO it should be a part of the base spec.
In principle, link objects defined this way can be used anywhere in the response. E.g., the implementation can consider returning all attributes which contain URLs as link objects in full form.
Top-level link with "class":"action" and name explore could be used to communicate starting point for browsing a HATEOAS-compliant API.

Example
Illustrates all formats, both simple cases (article with ID=3) and complex cases (article with ID=2), dynamic permissions through actions (published article with ID=1 vs unpublished article with ID=2), RFC5988 mapping, custom actions (report for article with ID=1).
I am not suggesting to allow mix of different link forms in one response, it is here only to shorten the example.
GET /articles?page=1&page_size=3&related_page_size=2

{
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON-LD paints my bikeshed!",
      "published": "true"
    },
    "relationships": {
      "authors": {
        "links": {
          "self": "http://example.com/articles/1/links/authors",
          "related": "http://example.com/articles/1/authors",
        },
        "linkage": [
          { "type": "authors", "id": "3" },
          { "type": "authors", "id": "4" }
        ]
      }
    },
    "links": [{
      "name": "self",
      "class": "general",
      "href": "http://example.com/articles/1"
    },{
      "name": "citation-report",
      "class": "custom",
      "method": "get",
      "href": "http://example.com/reports?type=citations&article_id=1",
      "rfc5988": {
        "rel": "http://example.com/notions/citation-reports",
        "type": "application/pdf",
        "title": "A report on citations of the given article over the last 5 years.
Data is derived from ISI Web of Science database in Computer Science."
      }
    }]
  },{
    "type": "articles",
    "id": "2",
    "attributes": {
      "title": "JSON API paints my bikeshed!",
      "published": "false"
    },
    "relationships": {
      "authors": {
        "links": [{
          "name": "self",
          "class": "general",
          "href": "http://example.com/articles/2/links/authors",
          "rfc5988": {
            "rel": "self"
          }
        },{
          "name": "related",
          "class": "general",
          "href": "http://example.com/articles/2/authors",
          "method": "get",
          "rfc5988": {
            "rel": "related author"
          }
        },{
          "name": "update",
          "class": "action",
          "href": "http://example.com/articles/2/links/authors",
          "method": "patch"
        },{
          "name": "next",
          "class": "pagination",
          "href": "http://example.com/articles/2/authors?page=1&related_page_size=2",
          "method": "get",
          "rfc5988": {
            "rel": "related author next"
          }
        },{
          "name": "last",
          "class": "pagination",
          "href": "http://example.com/articles/2/authors?page=last&related_page_size=2",
          "method": "get",
          "rfc5988": {
            "rel": "related author last"
          }
        }],
        "linkage": [
          { "type": "authors", "id": "5" },
          { "type": "authors", "id": "12" }
        ],
        "meta": {
          "pagination": {
            "related_page_size": "2",
            "related_page_count": "3",
            "related_item_count": "5"
          }
        }
      }
    },
    "links": [{
      "name": "self",
      "class": "general",
      "href": "http://example.com/articles/2"
    },{
      "name": "update",
      "class": "action",
      "method": "patch",
      "href": "http://example.com/articles/2"
    },{
      "name": "delete",
      "class": "action",
      "method": "delete",
      "href": "http://example.com/articles/2"
    },{
      "name": "publish",
      "class": "action,custom",
      "method": "post",
      "href": "http://example.com/articles/2/publish"
    },{
      "name": "version-history",
      "class": "version",
      "method": "get",
      "href": "http://example.com/articles/2/version-history",
      "rfc5988": {
        "rel": "version-history"
      }
    },{
      "name": "version-drop-wip",
      "class": "version,action,custom",
      "method": "post",
      "href": "http://example.com/articles/2/version-drop-wip",
      "rfc5988": {
        "rel": "http://example.com/notions/version-drop-wip"
      }
    },{
      "name": "type",
      "class": "general",
      "href": "http://example.com/notions/articles",
      "rfc5988": {
        "rel": "type"
      }
    }]
  },{
    "type": "articles",
    "id": "3",
    "attributes": {
      "title": "On Silver Bullets",
      "published": "true"
    },
    "relationships": {
      "authors": {
        "links": {
          "self": "http://example.com/articles/3/links/authors",
          "related": "http://example.com/articles/3/authors"
        },
        "linkage": { "type": "authors", "id": "33" }
      }
    },
    "links": {
      "self": "http://example.com/articles/3"
    }
  }],
  "links": [{
    "name": "self",
    "class": "general",
    "href": "http://example.com/articles?page=1&page_size=3&related_page_size=2"
  },{
    "name": "explore",
    "class": "action",
    "href": "http://example.com/start-api-exploration"
  },{
    "name": "copyright",
    "class": "general",
    "href": "http://example.com/copyright",
    "rfc5988": {
      "rel": "copyright",
      "type": "text/html"
    }
  },{
    "name": "next",
    "class": "pagination",
    "href": "http://example.com/articles?page=2&page_size=3&related_page_size=2",
    "rfc5988": {
      "rel": "next"
    }
  },{
    "name": "last",
    "class": "pagination",
    "href": "http://example.com/articles?page=last&page_size=3&related_page_size=2",
    "rfc5988": {
      "rel": "last"
    }
  }],
  "meta": {
    "pagination": {
      "page_size": "3",
      "page_count": "15",
      "item_count": "43"
  }
}

@hhware just wanted to say that I saw this and have been thinking about it. my big takeaway is that the core aim of your proposal—extending the links object to make it more powerful—is really important and spot on, but that your solution might be overly complex. i'll elaborate more on this when i can, but i want to write up my thoughts on #614 first, as that could effect this

I really want JSON-API to point in the direction of HATEOAS too, but I think this proposal is too complex for 1.0, and honestly, for the relative near future of JSON-API.
That said, we're committed to merging #618 today or tomorrow, which gets us quite a bit closer.
Would you be willing to close this in favor of a PR based on the structure of #618 @hhware? I think the focus should be ensuring this approach is possible in an additive fashion.

@ethanresnick, @tkellen, thanks for your interest! At the time it was written, it was important to consider at least the items up to relationship-level links for 1.0, but since that is now handled as part of #625, this proposal becomes fully additive and naturally gets lower priority compared to other things. I have just "rebased" this onto #625 by simply removing the first items from the Proposed Changes and updating wording in one place. The example remains unchanged.
As for complexity -- I agree, but it covers multiple use cases and (hopefully) provides extensibility of links in the future. Also, I would like to emphasize that, since one of the main motifs of JSON API was to stay simple, one of the design goals for this proposal was to formulate changes in a way that two options are available. Those APIs which do not need advanced functionality can use the simplified option, which is the base spec as of #625.
As for the PR, of course I will be happy to provide it, but it would be great to hear at least some constructive feedback on the proposed approach first. For instance, is the idea of classes acceptable at all? Could this go to the base spec or an extension is my ceiling?
I have changed bulleted list to enumerated list to simplify referencing.

honestly, for the relative near future of JSON-API.

@tkellen, that is what scares me. "Full HATEOAS" may be a relatively exotic need, but discoverable actions (the main driving force behind this) is not a need of the future, it is a need of today: people want to build agile user interfaces which take into account current resource state and user permissions without requiring additional trips to the server. JSON API is a modern spec, coming of age this week, so IMHO, it should be addressing such challenges. Not that I am saying that my proposal is good, but I sincerely hope that some solution to the problem at hand can come out of it or at least with some help from it in the very near future.

As for the PR, of course I will be happy to provide it, but it would be great to hear at least some constructive feedback on the proposed approach first. For instance, is the idea of classes acceptable at all? Could this go to the base spec or an extension is my ceiling?

Ok, here goes some rough and only half-backed (hopefully) constructive criticism for possible simplifications:

My inclination is that having classes of links add more complexity than it's worth. Categorizing link relations is, as your proposal mentions with self, difficult to do, and I'm not sure knowing a link's class is that helpful to a client that doesn't understand the specific link type. Also, letting one link be of multiple classes (which does seem like it would be necessary) then adds further conceptual overhead. Right now, the primary value of class seems to be that it carves out a space for user-defined link types (with the "custom" key), but I wonder if there are easier ways to do that.

It seems weird to me to special case RFC5988 in it's own container. What I'd much rather do is merge "name" and the RFC5988 stuff into one value, which simply would be an (extended) relation.

Here's a very, very raw sketch that shows sort of the direction I'm thinking. (This example would be in a resource-level links, but the structure would apply to links anywhere.)
"links": {
  "self": "http://example.com/",
  "collection": ["http://example.com/type", "http://example.com/sub-type"],
  "http://example.com/rels/publish": "http://example.com/articles/2/publish"
}

This is a really simple, but complete, RFC 5988 implementation. The context for the link is whatever object the "links" is contained in; the relation is the key name (a string for registered relations and a url for extended ones); and the target document is the value. The nice thing about this is that all the keys used in the base spec already are appropriate, registered link relations, so we wouldn't have to change a thing (except indicate that, when they appear in a json-api document, the more-specific json-api meanings of each key also apply). And because the values can be arrays, we can support multiple links with the same relation type.
Moreover, the above could easily be extended to support curie-like aliasing to make things shorter, like:
"rel-prefixes": {
  "ex": "http://example.com/rels/"
},
"links": {
  "self": "http://example.com/",
  "collection": ["http://example.com/type", "http://example.com/sub-type"],
  "ex:publish": "http://example.com/articles/2/publish"
}

(I've calld this a "prefix" above only because I think curies is another one of those words that scares people.)
Finally, if we decide that it's really necessary to hint at the supported methods, returned content types, etc. for each relation (and I'm not sure that it is—at least not in each response, though maybe we could in a JSON-HOME like entry point), we could replace the target URIs in the example above with objects, like so:
"links": {
  "self": "http://example.com/",
  "http://example.com/rels/publish": {"href": "http://example.com/articles/2/publish", "method": "post"}
}

What do you think? Could a more solid proposal be built on top of this? Are there any major cases it's overlooking? Etc.

This is very interesting work @hhware. I think a PR to the base spec is premature at this point and would strongly prefer to see these HATEOAS concepts explored extensively as an extension. Of course, it would also be preferable if it could be an additive extension (or extensions) to the base spec. I think we should focus our work in the next few days on ensuring that this level of extensibility is possible.

I think I was unclear in my previous comment--I meant a PR to ensure this kind of functionality it possible via additive changes later (basically what @dgeb just said).

@dgeb, thanks for encouraging note!
@ethanresnick, thanks for review!

having classes of links add more complexity than it's worth

I think extensibility is worth a lot. The primary use case: the client wants to know which actions are available on a resource, whether standard or custom -- just filter by class including action. The client wants to know which pagination links are available on a resource/relationship/response, whether standard or custom -- just filter by class including pagination. A few years from now, the client wants to know which links satisfy criterium A -- just filter by class A.
Link objects cannot be referenced directly, they are just part of the response, so I do not see why it is a problem to allow multiple classes per link, contrary to type, where multiple types per resource would generate quite a stir (even though they could probably help in cases like #571).

I'm not sure knowing a link's class is that helpful to a client that doesn't understand the specific link type

In my view, ability for the client to filter links by criteria is the main reason why classes are introduced. If the client does not need to filter, then it can of course just find the desired link by name.

Right now, the primary value of class seems to be that it carves out a space for user-defined link types (with the "custom" key),

I added a link to the example above to illustrate another case: version-drop-wip. Suppose some API allows to maintain a WIP version of a resource along with a published version, and hence needs actions to publish it (i.e., replace published version with WIP) and cancel editing (i.e., drop WIP). The spec does not make provisions for this scenario, so it has to be custom. Is it action? Yes, so it has to have action. Is it related to versioning? Yes, it has to have version.

but I wonder if there are easier ways to do that.

If it were only for custom, then obviously it would be easier to add a boolean flag to indicate it. Having separate flags for actions, pagination, etc, does not seem very practical. Again, I see it as an extensible mechanism for classifying links, which could be used by the server and client for various purposes.

It seems weird to me to special case RFC5988 in it's own container.

I do not mind putting them directly into the link object, but I thought that it would be easier to store them in their own container because they are defined by different specs, so there is a potential for parameter name conflict.

What I'd much rather do is merge "name" and the RFC5988 stuff into one value

I do not think it is practical. This proposal provides the ability for the API to define links with arbitrary names. RFC5988 defines a limited set of readable names, and the rest have to be URLs. I doubt many people would actually want to use URLs for names because they are not very readable and might hinder communication. I think that my example with action publish is much more readable than your example with "http://example.com/rels/publish": "http://example.com/articles/2/publish".

This is a really simple, but complete, RFC 5988 implementation

I do not think it is complete, because it does not allow, for example, to pass media or type of RFC5988.

Finally, if we decide that it's really necessary to hint at the supported methods, returned content types, etc. for each relation

In my view, that would be closer to support of RFC5988.

we could replace the target URIs in the example above with objects, like so:

This is what I am proposing, but not that much for RFC5988 compliance, mainly for (1) ability to add class, (2) extensibility.
The main difference between our proposals at this point is how links are identified. You suggest to key them by name, but what if a particular API defines a custom link name, and JSON API decides to reserve it a few years later? Adding class for custom links allows to avoid such conflicts, while allowing people to assign convenient meaningful names to links (not ugly constructs like http://example.com/rels/publish).

I doubt many people would actually want to use URLs for names because they are not very readable and might hinder communication

I agree that URIs as keys are ugly, but prefixes do ameliorate this to a large extent. And we can get even more clever than my example earlier. For example, we could define the api prefix as automatically mapping to the {current host}/rels/. So an api at http://example.com/v2 could return a resource-level links that looks like this:
"links": {
  "api:publish": "http://example.com/v2/articles/2/publish"
}

And api:publish would be mapped to the url "http://example.com/rels/publish" without the user having to define http://example.com/rels/ as the value of a prefix anywhere. (And this works even if the user doesn't ultimately bother to put anything at the http://example.com/rels/publish URI.)
The above still isn't as clean as a simple "publish" key, it's true. But, if we have a name, we still have to put the registered relation name or (something that maps to) a relation URI somewhere for us to have RFC 5988 compliance. And, to me, whatever ugliness is left in the api:publish key is preferable to having both a name and a relation mapping, which seems redundant. I don't like the idea of links with keys like "name": "first", "rel": "first", "name": "self", "rel": "self", etc.

You suggest to key them by name, but what if a particular API defines a custom link name, and JSON API decides to reserve it a few years later?

Future JSON-API keys might be extended relations, in which case they'd live at http://jsonapi.org/rels/whatever and couldn't conflict with user-defined keys (which live on other domains). The only possibility for conflict, therefore, would be if JSON API later defines a more-specific meaning for an existing registered link relation, and the user was already using that relation in their API with the generic meaning (but not the json-api–specific specialized meaning). But that possibility could be prevented by the right reasoning in #614.

The main difference between our proposals at this point is how links are identified...

Yup! And you're right that your structure is closer to included. But it's also less similar to the current/"simplified" form of a links object that's in the base spec. I'd rather not sometimes have links as an object and sometimes have it be an array. Instead, under my proposal it's always an object; the relation is always the key; and the value is made up of a set of "building blocks", namely:

A "link target" object, which must contain an "href" key and can contain other keys, like method, content-type, etc. A class key could go here too; I'm still not 100% sold on it (namely, because I worry we'd get the taxonomy wrong), but it would fit into the structure perfectly.
A "link target" object can be expressed more compactly as just a string, which equates to an object with just an href member.
And the value of the link is a single "link target" object/string, or an array of such objects.

is preferable to having both a name and a relation mapping, which seems redundant.

It is redundant only if they always coincide. What if an API had a naming convention for actions and did not want to follow suggestions of IANA for whatever reason? What if an API did not want to use URLs for custom link names? Even if it were not the case and the valuess were the same, some redundancy can be tolerated because RFC5988 is external to JSON API.

Future JSON-API keys might be extended relations, in which case they'd live at http://jsonapi.org/rels/whatever and couldn't conflict with user-defined keys (which live on other domains)

I personally really dislike the idea of an URL as a link name. Also, if two different domains are used, your argument "without the user having to define http://example.com/rels/ as the value of a prefix anywhere" does not seem to apply.

And the value of the link is a single "link target" object/string, or an array of such objects.

I did not think of an array of links as a value. Why would the client need multiple locations for one link name, are there example use cases? To me, it seems like duplication of functionality of to-many relationships at link object level. IMHO, the semantics of the link object is a location where something (defined by the link name) can be found or done, and if there are multiple locations, they should have distinct link names.

I agree that URIs as keys are ugly, but prefixes do ameliorate this to a large extent.

OK, so there is a choice between (a) included-like array and (b) current-spec-like object with namespace for custom links. I personally still prefer the option (a) because it allows implementations to select arbitrary names for links. The spec so far was able to avoid going in the way of implementations by not imposing naming conventions, I feel that link is an important concept which deserves the same treatment. However, I understand the appeal of the option (b), and if reasonable namespacing convention is defined ("http://example.com/rels/ as the value of a prefix" does not seem reasonable to me), it could be acceptable too. The convention of dasherized custom link names will not work because IANA registry already contains dasherized names, so it seems it has to be a prefix.
If the option (b) is adopted, there is no need to append custom to the value of class if the link is meant to supplement an existing class. (If option (a) is adopted, appending of custom to existing class can be avoided by adding a separate boolean flag member to link objects to indicate whether it is a custom link or not.)

HATEOAS concepts explored extensively as an extension. Of course, it would also be preferable if it could be an additive extension

@dgeb, the only thing which concerns me with formulating this particular proposal as extension is that it would be substituting the definition of links as an object in the base spec with an array in the extension (or, in the framework of @ethanresnick's suggestion, the definition of value as string in the base spec is substituted with an object in the extension). I do not think this problem exists the other way around: as proposed here, the base spec defines 2 forms, full and simplified, so the implementation should be handling both. But if the base spec defines a member as something and an extension redefines it as something else, it cannot actually be classified as additive (it will fall under (1) in @ethanresnick's classification). Rich links are not possible as additive extension simply because the entity to be extended is a string, and strings cannot be extended. The only additive way which occurs to me is something ugly like
"links": {
  "self": "http://example.org/arcicles/1",
  "next": "http://example.org/arcicles/1/next",
  "supplementary": {
    "self": {
      "key1": "v11",
      "key2": "v12"
    },
    "next": {
      "key1": "v21",
      "key2": "v22"
    }
  }
}

IMHO, this stuff belongs to the base spec, possibly to a separate section or something, but not to an extension.

@tkellen, that is what scares me. "Full HATEOAS" may be a relatively exotic need, but discoverable actions (the main driving force behind this) is not a need of the future, it is a need of today: people want to build agile user interfaces which take into account current resource state and user permissions without requiring additional trips to the server. JSON API is a modern spec, coming of age this week, so IMHO, it should be addressing such challenges. Not that I am saying that my proposal is good, but I sincerely hope that some solution to the problem at hand can come out of it or at least with some help from it in the very near future.

I agree that this is extremely important stuff. That being said, I also think we need to give the developer community time to absorb and implement the new concepts we're introducing before we layer on yet more.
What we are proposing with JSON-API is already a far cry from the "expose your database tables over the wire" mentality that pervades API design today. I strongly believe that we need to be tactical in our approach if we are to succeed in garnering wide adoption for these ideas.
As long as we leave the door open for this sort of functionality to be introduced additively, I feel we're in great shape to create a new baseline for API design on the web.
I think I speak for all of my co-authors when I say that we're committed HATOES, just not at the expense of alienating the wider developer community.

In short, please bear with us. We're headed in the same direction, just at different speeds. I think the best thing you can do right now is focus your efforts on making sure we don't introduce roadblocks that will prevent our progression in the future.

Well said, @tkellen - I agree completely.

I think I speak for all of my co-authors when I say that we're committed HATOES, just not at the expense of alienating the wider developer community.

Yes, absolutely.

Rich links are not possible as additive extension simply because the
entity to be extended is a string, and strings cannot be extended.

I think this could be resolved with a focused PR that adds support for an
expanded form of links as an object (which would typically not be used
initially, but would normatively prepare implementations to handle this).
On May 19, 2015 7:12 PM, "Steve Klabnik"<EMAIL_ADDRESS>wrote:

I think I speak for all of my co-authors when I say that we're committed
HATOES, just not at the expense of alienating the wider developer community.
Yes, absolutely.
—
Reply to this email directly or view it on GitHub
https://github.com/json-api/json-api/issues/622#issuecomment-103694415.

you can do right now is focus your efforts on making sure we don't introduce roadblocks that will prevent our progression in the future

Sure, this is the primary reason why this PR has been submitted before 1.0...

I think this could be resolved with a focused PR that adds support for an
expanded form of links as an object (which would typically not be used
initially, but would normatively prepare implementations to handle this).

Agree, but that means that the (a) vs (b) from https://github.com/json-api/json-api/issues/622#issuecomment-103685484 has to be decided before 1.0. Opinions?

I would say B. I think we should start by specifying the bare minimum "expanded" link form to support current functionality. The base spec should normatively make these two forms interchangeable, and perhaps nothing more needs to be said right now.
"links": {
  "self": "http://example.com/posts",
}

{
  "links": {
    "self": {
      "href":  "http://example.com/posts"
   }
}

It's late and I'm probably missing something, but that's the sort of thing I'm imagining.

We could perhaps reserve the entire namespace inside the object to start, save for meta, for people who want to explore this sort of thing.

I think allowing objects for links, reserving the whole namespace, and only recognizing meta and href is the way to go. Big :+1:

@tkellen Yup, I agree completely! Like I said earlier, I proposed (b) over (a) only because it seemed to grow more naturally out of what we have now. That isn't meant as a knock on @hhware's proposal—I think it's asking all the right questions and the primary difference we're talking about is stylistic anyway—I just think approach (b) feels like a more minimal change.
I'd only add that, to preserve the option of later mapping the keys to RFC 5988 relations, we should account in the base spec for the fact that it's quite common for multiple links to have the same relation name (e.g. the profile and collection relations, both of which are directly applicable to JSON API).
I think we could account for that either by allowing or mandating that the value at each key can be an array. Do either you, @hhware, or @dgeb have a preference one way or the other? Mandating an array means one less format for clients to parse, but it's a bit uglier if the array only has one item.

I feel that allowing the array form is premature at this point and that the object form could encompass such a structure if needed.

Agreed.

@dgeb @tkellen Ok, that's fair. (Though #614 might change the needs here.) Out of curiosity, though, how would the object form accommodate multiple links? The solutions I can think of quickly are pretty ugly.

Out of curiosity, though, how would the object form accommodate multiple links?

I really think it's premature to answer this now but: a member of the object (not sure of the key) could contain the array - or perhaps another object - that represents multiple links.

@dgeb Ok, yeah, that's more or less what I was thinking, and that's fine (again, pending #614).
Could you, @tkellen, and @steveklabnik actually jump back into #614 when you have a sec? I've been publicly brainstorming some stuff there, and am working it into a proposal, but it'd be helpful to know if you guys think I'm on the right track or think there's anything missing from my conceptual structure before I try to work up something more specific.

@hhware Would you be willing to put together a PR to cover this bare minimum use-case? Do you feel like this is enough to pave the way forward for real support of this sort of thing eventually?

Do either you, @hhware, or @dgeb have a preference one way or the other?

Sorry, @ethanresnick, I really do not understand the point of multiple links under the same name, so my preference is not to support arrays :) IMHO, the notion of classes allows to achieve the same result in a more versatile way. In your example, the API returns 2 profiles. Why not have a link class profiles, assign it to both links and name them with distinct meaningful names? Both of them could have RFC5988 relation name profile, but if JSON API link name is different from RFC5988 relation name, the client can still distinguish each link by its JSON API link name. How can each profile be referred to in your example?
Also, suppose 5 profiles in total are supported by the server, and the given API response returns 2 of them. How can the client know which of 2 URLs matches which profile if the URLs do not have names? Is the client supposed to parse the profile URL and figure out which URL corresponds to which profile? I feel like the only use for arrays is "load balancing", but this should be a responsibility of a layer lower in the stack...

@hhware Would you be willing to put together a PR to cover this bare minimum use-case?

Sure, I will prepare a PR tomorrow.

Do you feel like this is enough to pave the way forward for real support of this sort of thing eventually?

Yes, I think so. As I mentioned above, the only limitation I see now is the imminent requirement for a namespace for custom links, which is not in line with the approach taken by JSON API in other areas. Nevertheless, I believe it is perfectly workable.

@hhware I think we're talking past each other a bit. The key difference seems to be that your proposal has a required name property for each link with an optional RFC 5988 relation, whereas my proposal has a required RFC 5988 relation without (necessarily) giving each link a name.
Now, let me say right off the bat that I do think there are some use cases for giving a link a name, separate from its href or relation. For example, the collection relation lets a resource link to the collection(s) that it belongs to. If links to these containing collection(s) are going to be shown directly to users, it might make sense to give them human-readable names. In my proposal, that could happen by adding name as an extra, optional property in the link's object, like this:
"links": {
  "collection": {"href": "http://example.com/people", "name": "People Resources"}
}

But I think the example of profiles (below) shows clearly why it makes sense to make the relation the required part and the name the optional part, rather than vice-versa.

In your example, the API returns 2 profiles. Why not have a link class profiles, assign it to both links and name them with distinct meaningful names?... How can the client know which of 2 URLs matches which profile if the URLs do not have names? Is the client supposed to parse the profile URL and figure out which URL corresponds to which profile?

In the profile specification, a profile's URI is its name. The whole idea is that, by using a URI as a name, it can be globally identifiable/unique. So, yes, the client is supposed to match on the URI—that's how a generic client knows whether it actually understands the specified profile—and, again, having another name would just be redundant.
Imagine a client that comes across an API and gets back this JSON:
"links": [{
    "name": "semi-standard-immutables-documentation",
    "class": "profiles",
    "href": "http://popular-jsonapi-extension.org/immutables",
    "rfc5988": {
      "rel": "profile"
    }
  }, {
    "name": "semi-standard-write-template",
    "class": "profiles",
    "href": "http://popular-jsonapi-extension.org/write-template",
    "rfc5988": {
      "rel": "profile"
    }
  },
  // more links here...
]

There are two profiles here. They're semi-standard in that they're published publicly on some domain, such that a generic client might actually know how to interpret the additional semantics they convey. But they're not part of the base spec (in which case a profile isn't necessary) or specific to the example.com API. (Any semantics specific to a given API could be linked as profiles, but don't usually need to be, since a generic client won't know how to process the extra semantics anyway, and a client written specifically for the given API likely knows that the profile is in effect without it being declared.)
So, let's say a generic client comes across the JSON above. The client knows that it can understand the http://popular-jsonapi-extension.org/write-template profile, which it identifies internally by that URI but not by name (because the APIs it's interacting with could name it anything). So, it gets this blob of JSON and it identifies the profiles using the profiles class, which just ends up duplicating the rel, and then it throws away the name entirely and only looks at the href anyway. So this whole structure ends up communicating no more to a generic client than simply:
"links": {
    "profile": ["http://popular-jsonapi-extension.org/immutables","http://popular-jsonapi-extension.org/write-template"]
  }

And, again, a client written just for this API (as opposed to a generic client) probably already knows which profiles are in effect, so it doesn't even need to look at links. And, in the rare cases it does need to look at links, it would be better off identifying the profiles there by URI anyway. And, finally, if for some reason that's still inadequate, an optional name could always be added:
"links": {
    "profile": [{"href": "http://popular-jsonapi-extension.org/immutables", "name": "whatever", {"href": "http://popular-jsonapi-extension.org/write-template", "name": "profile 2"}]
}

But hopefully the above shows the key point: the problem with name is that it's not globally unique—that is, different APIs can use the same name for different things—whereas a link relation's name=>meaning mapping is unique. This is what allows generic clients to extract meaning from the link relations. So identifying the URIs by relation is key. And, once you do that, it's quite clear why arrays are needed, namely: because you can't just change the key to make each one distinct; you have to use the standard off-the-shelf relation name, and multiple links can share the same relation.

So this whole structure ends up communicating no more to a generic client than simply

@ethanresnick, got it. Indeed, it seems to be a very reasonable shortcut when relation name is used for link object key.
Well, perhaps we should indeed allow arrays as values of href? Unless we do it now, it would be awkward, e.g., to have href for a single URL and hrefs for multiple URLs, and the only way to have both under href is to define the whole thing in extension, not in the base spec. Since the whole purpose of this is to leave the door wide open for the future, it should not be a problem to partly close it later if the array use case ends up not being supported. This is accounted for in my PR #644, so @dgeb and @tkellen, please let me know if it needs to be removed.

Closing in favor of #644.  Thanks @hhware!


Passing alias this with function returning chain to tempCString hangs up the program

d.bugs reported this on 2019-10-21T10:55:33Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=20309
CC List

bugzilla (@WalterBright)

Description
The following minimal test case will result in a binary which hangs up:

import std.range : chain;
import std.internal.cstring : tempCString;

struct Test {
    auto filename() const { return chain("a", "b"); }
    alias filename this;
}

void main() {
    auto name = Test();
    auto namez = name.tempCString!char();
    // should return fine or crash if doesn't exist, but not hang
}

See https://run.dlang.io/is/8AlJO5

This is a bug because with `name.filename.tempCString!char()` it works fine, so it has an issue with the alias this on that range.

This causes calls to the std.file functions like isFile or getAttributes to hang up if called with a struct like this.

This only happens when it is indirected via an alias this on the argument which is passed.

Another test to test it with public APIs: `std.file.getAttributes(Test())`

bugzilla (@WalterBright) commented on 2019-12-08T09:50:30Z
Reduced example:

```
import std.stdio;
import std.range : chain;

struct Test
{
    auto filename() const { return chain("a", "b"); }
    alias filename this;
}

void main()
{
    auto name = Test();
    writeln(name.front);
    name.popFront();
    writeln(name.front);
}
```

name.front and name.popFront always call filename(), which returns a new range object... This is IMHO not a phobos bug.

d.bugs commented on 2019-12-08T12:46:26Z
you are right, it makes sense that it creates a new object for each instantiation. However this would mean that maybe the isInputRange check or whatever tempCString and others are using, should not allow such a construct which always returns a new instance

bugzilla (@WalterBright) commented on 2019-12-08T13:11:36Z
IMHO this is a problem burried deep into alias this. My solution would be, to remove alias this completely. Creates a lot of problems...


Fixed assumptions misspelling

Fixed assumptions misspelling in the link mentioned below:-
https://python.langchain.com/en/latest/modules/chains/examples/llm_summarization_checker.html

Fix for Issue:- #4959
@hwchase17

maintain to merge when tests pass


SideNav and Modals Transition is not smooth in mobile device

I make some test to create an app based on Materialize with Cordova, I use android platform with minimum requirement KitKat, however the animation/transition of SideNav and modals are stutter.
I though it was because Cordova, but I tested with built-in browser and Google Chrome, it's still lags so much.
I hope Materialize would faster and reliable on mobile device in future version!

Yes, we do plan on optimizing many of our components. Many were written quickly in the early stages of the project, but it takes time to go back over all of them and improve them. I know at least for side-nav that we transition the left or right property which is not good performance wise. Eventually we will switch to using transform translate.
If anyone wants to take a crack at making the switch to animating with transform: translate it would be highly appreciated.

I modified it, so it works with translateX instead of left and with some custom css, but i didn't modify it for edge: right yet. Transition is smooth on mobile now.

Yes I agree, trying to build an app for Cordova is quite laggy at this time.
Chrome works fine enough, I hope you guys optimize it asap cause this is quite a helper :)

I made it for both sides and fixed css as well, just have to make a pull request.

Looking forward to it @ElpySites

@ElpySites Can't wait for this PR :)))

still waiting...

Still waiting for a pull ...

Maybe this project can use Animate.css, seems fast...
https://daneden.github.io/animate.css/

Not sure it's really necessary. Most of the animations in material are fairly simple, it's just that a lot of them are done in js, and not necessarily optimized. The side nav needs JS because we need to be able to drag it.

Hope the PR could be accepted soon... this issue prevents me to use Materialize my production project, since the prototyping was pretty laggy on mobile browser, specially on Android devices...

Same here, that's why I use a custom fork of Materialize now. Materialize needs more admins =/

There were some problems with the PR due to some complexity around drag events, I created and pushed a fix here: df0c80fbd6c7f42e5d597464ce6962fbb8e3dfea
Sorry for the delay everyone.

still incredbly slow on a very modern anddroid on chrome like 1FPS/second both for navbar and modal (transition to open it and dragging)

The sidenav is also slow on my cordova project.

Me too I'm using materializecss .Navigation drawer is not perfect in my cordova app.

Is it possible to use JS only for dragging the sidenav and use CSS animations when clicking the sidenav open button?

Too slow and laggy


Implement internal_bit

We have to only implement ceil_pow2, which should equal to |n| 32 - n.leading_zeros().

Let me try.


nhost init --remote error

I created a brand new project and was following the cli getting started guide.
❯ nhost init --remote
✔ Selected: myapp  myuseraccount
> Failed to pull migrations from remote

With the --debug option I get a different error:
❯ nhost init --remote --debug
> Fetching user data
> Fetching saved auth credentials
✔ Selected: myapp  myuseraccount
> Created /Users/scott/.nhost
> Created .nhost
> Created nhost
> Created nhost/migrations
> Created nhost/metadata
> Created nhost/seeds
> Created nhost/emails
> Created nhost/config.yaml
> Created .env.development
> Created .gitignore
> Created .nhost/nhost.yaml
> Generating app configuration
> Saving app configuration
> Cloning github.com/nhost/hasura-auth/email-templates to nhost/emails
> Writing .gitignore
> [path] Removing .nhost/nhost.yaml
> Saving app information in .nhost/nhost.yaml
> Initializing Hasura client
> [hasura] [v2.13.0] Fetching binary
> Downloading hasura cli from 'https://github.com/hasura/graphql-engine/releases/download/v2.13.0/cli-hasura-darwin-arm64'
> [darwin-arm64] Writing hasura binary
> Creating migration 'init'
> Fetching metadata
> Fetching schema list
> Clearing remote migration for source: default
> Clearing migration
> Applying migrations
> Export metadata
> {"level":"info","msg":"Exporting metadata...","time":"2022-11-07T23:13:02-06:00"}
time="2022-11-07T23:13:04-06:00" level=fatal msg="failed to export metadata: cannot export actions from metadata: error parsing metadata \nobject: actions\nfile: actions.yaml\nerror: error in converting metadata to sdl: exit status 4: "

> exit status 1

#389 #350

Bump. Updated to v0.8.15 and confirmed the issue still exists.
I following along with the CLI Getting Started page says to init next.
nhost version
> Nhost CLI v0.8.15 for darwin-arm64
> You have the latest version. Hurray!

Prerequisits mention Git and Docker (which must be running while using the CLI), so I confirmed git, and that docker was started and no containers were currently active:
git -v
git version 2.39.0

docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
7050e35b49f5: Pull complete
Digest: sha256:c77be1d3a47d0caf71a82dd893ee61ce01f32fc758031a6ec4cf1389248bb833
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (arm64v8)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

docker ps -a
CONTAINER ID   IMAGE         COMMAND    CREATED          STATUS                      PORTS     NAMES
a66c9d86d8e4   hello-world   "/hello"   35 seconds ago   Exited (0) 35 seconds ago             charming_lamarr

After logging in to the cli, I checked to see that my account has no databases:
nhost list

App   Workspace
----  ---------

On the nhost web interface, I created a new project and after a couple minutes for provisioning, I ran nhost list again and see my new project.
nhost list

App             Workspace
----            ---------
myfirstproject  **********

nhost init --remote
✔ Selected: myfirstproject  **********
> Failed to pull migrations from remote

And again with --debug
nhost init --remote --debug
> Fetching user data
> Fetching saved auth credentials
✔ Selected: myfirstproject  *********
> Created /Users/scott/.nhost
> Created .nhost
> Created nhost
> Created nhost/migrations
> Created nhost/metadata
> Created nhost/seeds
> Created nhost/emails
> Found existing nhost/config.yaml
> Found existing .env.development
> Found existing .gitignore
> Found existing .nhost/nhost.yaml
> Generating app configuration
> Saving app configuration
> Cloning github.com/nhost/hasura-auth/email-templates to nhost/emails
> Writing .gitignore
> [path] Removing .nhost/nhost.yaml
> Saving app information in .nhost/nhost.yaml
> Initializing Hasura client
> Creating migration 'init'
> Fetching metadata
> Fetching schema list
> Clearing remote migration for source: default
> Clearing migration
> Applying migrations
> Export metadata
> {"level":"info","msg":"Exporting metadata...","time":"2022-12-22T00:53:10-06:00"}
time="2022-12-22T00:53:11-06:00" level=fatal msg="failed to export metadata: cannot export actions from metadata: error parsing metadata \nobject: actions\nfile: actions.yaml\nerror: error in converting metadata to sdl: exit status 4: "

> exit status 1

That's strange. Do you have any complex metadata in your project or something?
Can you try on a complete new project also?

I mid-editing my comment, but based on an old comment on the discord, I narrowed it down to be the fish shell. Running in zsh was successful:
nhost init --remote --debug
> Fetching user data
> Fetching saved auth credentials
✔ Selected: myfirstproject  purpleladybug619
> Created /Users/scott/.nhost
> Created .nhost
> Created nhost
> Created nhost/migrations
> Created nhost/metadata
> Created nhost/seeds
> Created nhost/emails
> Found existing nhost/config.yaml
> Found existing .env.development
> Found existing .gitignore
> Found existing .nhost/nhost.yaml
> Generating app configuration
> Saving app configuration
> Cloning github.com/nhost/hasura-auth/email-templates to nhost/emails
> Writing .gitignore
> [path] Removing .nhost/nhost.yaml
> Saving app information in .nhost/nhost.yaml
> Initializing Hasura client
> Creating migration 'init'
> Fetching metadata
> Fetching schema list
> Clearing remote migration for source: default
> Clearing migration
> Applying migrations
> Export metadata
> Saving environment variables


CNI ADD: weave bridge and the first connected container get the same IP addr

When doing CNI ADD, we allocate and assign an IP addr not only to a container, but also to the weave bridge, if it does not have any IP addr (https://github.com/weaveworks/weave/blob/1.9/plugin/net/cni.go#L77).
A function which calls IPAM allocate might not use ContainerID from args passed to the function (https://github.com/weaveworks/weave/blob/1.9/plugin/net/cni.go#L51), and instead it will use the one from CNI_CONTAINERID env var which contains the container id.
As a result, we will end up calling IPAM allocate with the same container id twice (instead of the container id and weave:expose),  which will allocate the same IP addr to the weave bridge.
This might explain the weave-kube bug reports from the past, where the weave bridge and some container ended up having the same IP addr. However, to make this happen, the first CNI allocation should have happened before executing https://github.com/weaveworks/weave/blob/1.9/prog/weave-kube/launch.sh#L115 .

Note this does not happen if you use the default CNI config generated by the weave script; only if you edit it to name an IPAM provider.  So I do not think it is responsible for many bug reports.

Trying to fix this I ran across another bug: https://github.com/containernetworking/cni/issues/410

Fixed by #2856.


Getting a : /install_generator.rb:41:in `create_migration': wrong number of arguments (3 for 0) (ArgumentError)

Getting this error for the  rails generate redactor:install --devise
Anyone with the same problem?

on redactor-rails (0.5.0) and redactor-rails-paperclip (0.4.3) this error appears again :(


Organize Chapters 7-9 of the topic "Property, Plant and Equipment"

Organize Chapters 7-9 of the topic "Property, Plant and Equipment"

一併整理在#272

took 8 hrs
done


Improve error output: "(node:12608) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead."

When I use current master locally (via npm link) I get this output:
λ cordova-paramedic --platform android --plugin ./ --target 02e7f7e9215da7f8
cordova-paramedic: Will use the following cli: cordova
(node:12608) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.

Can we improve this error output somehow so it is clearer where this is used? It doesn'T seem to be in paramedic itself, but I have no idea how to dig deeper.

I'm confused. The code sample only references paramedic. Is this actually a coho issue or did this just end up in the wrong repository? :thinking:

A search in both this repo and cordova-paramedic resulted in no matches. Maybe this issue is obsolete?

I think I remember that warning being caused by some temp dir dependency like tmp.

I'm confused. The code sample only references paramedic. Is this actually a coho issue or did this just end up in the wrong repository? 🤔

Possible and reasonable. Feel free to close or transfer.


Allow the mavlink sysid of GCS to be the same as MAV_SYS_ID

PX4 is ignoring heartbeats from groundstation if mavlink sysid of groundstation is the same as MAV_SYS_ID. That leads to failsafe on datalink loss to kick in.
This PR removes the offending condition in MavlinkReceiver::handle_message_heartbeat

The system ID of drone and ground control station need to be different (system == vehicle). So I believe this change is not correct. Please feel free to re-open if I didn't understand the intent correctly.


Failing silently on start

I was debugging why the jobs are not executed when scheduled, even though logs suggest everything went fine:
{"severity":"INFO","message":"Booting Sidekiq 5.0.5 with redis options {:id=>\"Sidekiq-server-PID-12\", :url=>\"[redacted]\"}","@timestamp":"2018-09-04T13:03:31.544Z","@version":"1"}
{"severity":"INFO","message":"Loading Schedule","@timestamp":"2018-09-04T13:03:31.550Z","@version":"1"}
{"severity":"INFO","message":"Scheduling hello_world {\"cron\"=>\"0 * * * * *\", \"class\"=>\"Workers::HelloWorld\", \"queue\"=>\"tokens\"}","@timestamp":"2018-09-04T13:03:31.550Z","@version":"1"}
{"severity":"INFO","message":"Starting processing, hit Ctrl-C to stop","@timestamp":"2018-09-04T13:03:31.552Z","@version":"1"}

I noticed two things here after a while:

Only test job HelloWorld was added, even though schedule file included more jobs
There was no Schedules Loaded message before Starting processing.

After replaying manually what the gem does in the console I managed to get to the root of the problem, which was this error (which was easy to fix after you know it):
TZInfo::DataSourceNotFound: No source of timezone data could be found.
Please refer to http://tzinfo.github.io/datasourcenotfound for help resolving this error.

However, I was a bit surprised that Sidekiq Schedule gave me no hint of this and just died silently. It would be nice if such errors were mentioned in the logs somehow (or even if they caused whole Sidekiq process to fail).

Hi @katafrakt
Where do you found the TZInfo::DataSourceNotFound exception was raised?
I verified that when TZInfo throws that exception, the exception is back propagated, and the process ends.
2018-09-26T20:24:12.168Z 30948 TID-owqv2ktaw INFO: Booting Sidekiq 5.2.2 with redis options {:id=>"Sidekiq-server-PID-30948", :url=>nil}
2018-09-26T20:24:12.170Z 30948 TID-owqv2ktaw INFO: Loading Schedule
2018-09-26T20:24:12.170Z 30948 TID-owqv2ktaw INFO: Scheduling hello_world {"cron"=>"*/10 * * * * * UTC", "class"=>"HelloWorld"}
2018-09-26T20:24:12.171Z 30948 TID-owqv2ktaw WARN: {"context":"Exception during Sidekiq lifecycle event.","event":"startup"}
2018-09-26T20:24:12.171Z 30948 TID-owqv2ktaw WARN: TZInfo::DataSourceNotFound: No source of timezone data could be found.
Please refer to http://tzinfo.github.io/datasourcenotfound for help resolving this error.

Could you post the versions of the following gems?

rufus-scheduler
et-orbi
tzinfo

Thanks

just as a comment, since it was closed anyway. I'm currently unable to reproduce the problem. When there is no tzinfo gem installed I see the error message. The problem must have been specific to our particular and closing is ok.


Add cupy.positive()

Close #5702.
This PR adds cupy.positive() as well as ndarray.__pos__(), which return elementwise numerical positive.
As for boolean dtype, Array API standard says the input array should have a numeric data type, which does not include boolean. Also, numpy raises the following exceptions, which I don't think is worth exactly mimicking in CuPy so our counterparts just raise TypeError.
https://data-apis.org/array-api/latest/API_specification/elementwise_functions.html#positive-x
>>> import numpy as np
>>> np.positive(np.array(True, dtype=np.bool_))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
numpy.core._exceptions.UFuncTypeError: ufunc 'positive' did not contain a loop with signature matching types dtype('bool') -> dtype('bool')
>>> +np.array(True, dtype=np.bool_)
<stdin>:1: DeprecationWarning: Applying '+' to a non-numerical array is ill-defined. Returning a copy, but in the future this will error.
True

Regarding __pos__, CuPy currently returns the ndarray instance itself, however, both Array API and NumPy say the results must equal the results returned by positive(), so I fixed it to align the way. This is a no-compat change.
https://data-apis.org/array-api/latest/API_specification/array_object.html#pos-self
>>> import numpy as np
>>> a = np.array([1])
>>> a is +a
False

Sure! I'll do it here.

PTAL!


Extra debugging to track connections

Just using CI to create custom builds while investigating an issue.

Don't need this any longer.


Missing the terminal expand button in the visual studio code

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.74.2
OS Version: Windows

Steps to Reproduce:

Open the terminal

The highlighted button from the above image is missing in the vscode but it is there in insider's build

Please see https://github.com/microsoft/vscode/issues/164107#issuecomment-1285073752


Parallel mmult

In this PR, I've removed what was left of the float instantiation,  move code around to add a function that creates a dealii::TrilinosWrappers::SparseMatrix from a SparseMatrixDevice, and then use deal.II to do mmult. I have also moved around the destructor of SparseMatrixDevice because it was at the wrong place in the file but I haven't changed the code at all.

Codecov Report

Merging #71 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #71   +/-   ##
======================================
  Coverage    88.4%   88.4%
======================================
  Files          24      24
  Lines        1302    1302
======================================
  Hits         1151    1151
  Misses        151     151

Continue to review full report at Codecov.

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

(@Rombur next time, could you just push the commits addressing the comments on top of the branch without rebasing? That would make it easier to see how comments were addressed).

Sure


Add 1D interpolation features

In Issue #15, @marcel-goldschen-ohm mentioned the fact that a spline fit feature would be a nice addition to DataLab.
The purpose of this Issue is to add spline interpolation and other interpolation techniques to a new "Processing>Interpolation" feature.

Thanks for sharing this code, I was about to use scipy.interpolate.splev as well, so it sure helps to see how you use it in order to wrap it accordingly into DataLab.
Some thoughts:

xspline will be optional, otherwise it could be entered as xmin, xmax , numpoints for example
xknots: same as xspline
n_segments will also be an optional parameter (and mutually exclusive with xknots)

I think there may be some confusion with my terrible choice of name xspline. Perhaps I should have called it xeval or xoutput instead? The idea is that the spline is optimized for all (xdata, ydata), but can optionally be evaluated for a different set of x-values (xspline). Usually this is not needed and xspline defaults to xdata, but a use case would be if you wanted a spline to go through all points but not be influenced by some artifact.
I agree with you that n_segments is not needed as xknots=np.linspace(xmax, xmin, n_segments+1) takes care of that.

@marcel-goldschen-ohm, thanks again for 1. motivating the introduction of this feature, 2. providing some insights on how to implement the spline method.
A resampling feature has also been added (see Issue #21).
In the near future, if you want to contribute more directly to the project, we have two options:

You may write new features in DataLab's base code, or fix things and suggest it using a pull request
Also, you may contribute by writing a plugin: once the feature is stable, it will be easy to transpose it inside DataLab's base code. I could guide you through all the steps: how to write a new plugin, how to implement your processing feature inside a plugin, or how to populate the "Plugins" menu of the application, and so on. As for the integration to the code base, once again, I could guide you through it if you want to.

Anyway, thanks and hoping to see you soon.

Happy to help out. And kudos on DataLab, it seems like a tour de force at first glance. I've also got some stuff in the works right now that might be worth chatting with you about at some point in the near future.
Cheers

Hello @marcel-goldschen-ohm,
Thank you so much for your kind words about DataLab! It's always great to hear positive feedback, and I'm glad you see it as a tour de force.
I'm definitely interested in hearing more about the projects you're working on and would love to chat about them soon. Collaborative discussions often lead to exciting ideas and developments, so I'm looking forward to our conversation.
Also, if you're enthusiastic about DataLab, please feel free to share it with your colleagues and friends. Spreading the word helps us grow and evolve, and we appreciate your support in this.
Looking forward to our future discussions!
Cheers


ReadonlyArray and For component

For and Index components have each property with mutable type: each: T[];. That makes impossible to use it with ReadonlyArray data. May I suggest a small PR to fix this?

Sure I'm always looking to improve types.


A child process seems to survive .kill

I am trying to create a child process and let it run for no longer than 2 seconds using the code below
proc = Process.new("crystal", args: ["eval", "while true; end"])
d = delay(2.seconds) do
  proc.kill(Signal::KILL)
  puts "Killing the process!"
end
case proc.wait
when .normal_exit? then d.cancel
when .signal_exit? then puts("Timeout exceeded")
end

The output I'm getting is as expected:
Killing the process!
Timeout exceeded

While the code is running, top shows these 4 processes:

crystal
crystal (yes, another one)
crystal-run-mwe.tmp (the filename is mwe.cr)
crystal-run-eval.tmp

When the program finishes execution, all of them except for crystal-run-eval.tmp are gone. Since the only remaining process is the one containing an infinite loop, it's a bit of an issue.
Exactly the same behaviour is observed when instead of using crystal eval, I spawn a child process using crystal run <filename>, where filename is a crystal file with an infinite loop in it.
Is it possible that .kill in the code actually kills the second crystal process instead of the -eval.tmp one?
Crystal version: Crystal 0.27.0
OS: macOS 10.14 (18A391)
P.S. I understand there's a race condition in here, when the process terminates and .wait call returns but then it tries to kill the process anyway because the delay isn't cancelled yet.

My first guess: With a SIGKILL the crystal eval has no chance of forwarding that signal to its child, so it dies and the child gets reparented to its parent, which never waits on it or kills it either, so as it exits it gets reparented to its parent.
If you see the same behavior with a SIGTERM we likely miss to actually forward the signal to child, which might very well be, I didn't check.

I used SIGKILL when I couldn't get the process to terminate from .kill(), which uses SIGTERM by default

So maybe crystal eval doesn't handle it at all, which might be.

crystal eval and crystal run just run the compiled binary as a child process and normal process semantics apply. When you SIGTERM or SIGKILL a process, it's children are not killed automatically. (when you press ctrl-C your shell sends a signal to the entire process group, so all processes stop)
The best solution here is to use process groups but I don't think crystal has support for them yet (unless you fork+exec manually). I'd suggest using crystal build -o /tmp/myfile myfile.cr then running /tmp/myfile. This will be exactly equivalent to crystal run.
This issue isn't a bug, but it would be nice to have a process group abstraction in the standard library.


Linking local React Native Library requires an entry in dependencies in package.json

Linking local React Native Library requires an entry in dependencies in package.json.
Steps To Reproduce
Let's imagine we have the following code structure:
- components
- native_app
- node_modules

where:

node_modules contains a React Native Library hoisted from components
native_app contains a React Native App

then you can link the library with the app running:
cd native_app && react-native link react-native-webview
But, this requires the following entry in native_app/package.json:
...
"dependencies": {
   "react-native-webview": "file:./../node_modules/react-native-webview"
}
...

And this is a problem, because for monorepo projects both yarn install and lerna bootstrap are failing with an error of not existing file.
React Native version:
System:
    OS: macOS Mojave 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Memory: 151.45 MB / 8.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.16.3 - ~/.nvm/versions/node/v10.16.3/bin/node
    Yarn: 1.21.1 - ~/.yarn/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v10.16.3/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 12.4, macOS 10.14, tvOS 12.4, watchOS 5.3
    Android SDK:
      API Levels: 23, 27, 28, 29
      Build Tools: 27.0.3, 28.0.3, 29.0.2
      System Images: android-27 | Google Play Intel x86 Atom
  IDEs:
    Android Studio: 3.4 AI-183.6<IP_ADDRESS>92245
    Xcode: 10.3/10G8 - /usr/bin/xcodebuild
  npmPackages:
    react-native: 0.61.5 => 0.61.5
  npmGlobalPackages:
    react-native-cli: 2.0.1

The issue is mentioned also here: https://github.com/yarnpkg/yarn/issues/7678#issuecomment-573331670

thanks @graphan for opening the issue and please let me clearify a couple of doubts that I have related to your post:

The structure of your project is:

- components
- ios
- android
- node_modules

from the root of your project you run react-native link <your library>

Since<EMAIL_ADDRESS>you don't run anymore react-native link command
The native files managing dependencies changed syntax between rn-0.59-rn0.60. You can see the full git-diff of the ios/android files at react-native upgrade helper

in particular rn-0.59 android file MainApplication.java was using the following syntax
public class MainApplication extends Application implements ReactApplication {
    @Override
    protected List<ReactPackage> getPackages() {
      return Arrays.<ReactPackage>asList(
          new MainReactPackage()
      );

rn-0.60.5 is using
public class MainApplication extends Application implements ReactApplication {
    @Override
    protected List<ReactPackage> getPackages() {
      @SuppressWarnings("UnnecessaryLocalVariable")
      List<ReactPackage> packages = new PackageList(this).getPackages();
      // Packages that cannot be autolinked yet can be added manually here, for example:
      // packages.add(new MyReactNativePackage());
      return packages;
    }

you can manually add packages using package.add(new YouNativeModule());

react-native-webview is compatible with react-native 0.60 so no need to do the linking
I have rn-webview installed without linking in my mobile app

My package.json
My podfile and MainApplication.java

If you are having issues with automatic linking I suggest you to read about manual linking for both ios and android


Description section is rendered incorrectly

Given the following snippet:
// Lorem Ipsum
//
// Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis vitae arcu non
// mauris efficitur pharetra sed a purus. Cras id sapien tortor. Nulla eget leo
// sed ligula molestie lobortis.
//
// Morbi ornare bibendum purus, non porta nibh hendrerit non. Praesent sed metus
// tincidunt, efficitur neque at, semper magna. Fusce vitae placerat ex. Cras
// rhoncus vehicula sodales. Aenean ac pulvinar augue, ut vulputate ex.
//
// Suspendisse gravida luctus accumsan. Curabitur dictum dolor ex, at suscipit
// ex rhoncus in.
//
// Styleguide 3.0

I would expect SC5 to render the description section as 3 paragraphs, but instead it combines them into a single paragraph.
Also, a lot of the markdown features are removed. For example, I can't use backticks to denote code or stars to denote emphasis.

Yeah I find this frustrating as well. I experienced the same issue.

+1

+1

+1

This issue is fixed in the latest release, also markdown (as well as plain HTML) is now supported in the description blocks. Please notify me and open new issue if the issue still exists.


sub-path support with baseName

I would like to to include a remix app alongside an existing legacy application by adding it to a sub-path. In this instance it would take over a section of our administration tool set. https://our-web-app.com/admin/preferred-gift <-- remix / path
I attempted a direct proxy-pass with nginx however as the expected relative paths were to https://our-web-app.com/build instead of https://our-web-app.com/admin/preferred-gift/build I ran into some issues.
If remix could accept a baseName such as /admin/preferred-gift and use that for routing and relative path resolution it would help.
There might also be a super simple solution that I am not seeing

This is also a  feature that I am looking for.

@williamtstanley did you ever find a solution for this?

Actually it looks like this might be on the radar, with https://github.com/remix-run/remix/issues/759

Closing in favor of #759


Interesting project

Marco,
This is an interesting project, that might be useful to many people.
A great improvement would be adding some documentation on hot to use pgDoctor.
Actual usage is not clear without extensive studying of source codes, which would be a brier for adoption.
Igor

Agreed @ipolishchuk , I am personally loved this project, but it will be more clear on how to use by reading it careful.
https://stackshare.io/thumbtack/scaling-postgresql-at-thumbtack-load-balancing-and-health-checks.

I agree, this project is supposed to be really good. I like using different apps, programs, etc. that help me to take care of my health. I find a possibility to do this on te move to be really great. Thus I order all necessary pills online. Also I read the descriptions of them there (here canadapharmacy.com helps me a lot). And now I've found out about your project. Thanks for sharing! Great job!


Indicate that parameterObject has dynamic enum ?

I try to have a parameter, which enum values has to be requested from different endpoint. So I haven't found any way how I could do it in specification. I though about 2 ways or I indicate that enum is dynamic with additionalProperties or I use $ref as value for enum attribute but not sure if this will be with accordance to specification ?
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#parameterObject
{
  "in": "query",
  "name": "name",
  "$ref" : "#/paths/enums/name",
  "schema": {
    "type": "object",
    "additionalProperties": {
       "dynamicEnum": "bool"
    },
    "enum": {"$ref" : "#/paths/enums/name"}
  }
}

Any thoughts ?

This is how Microsoft do it for PowerApps and Flow.
"x-ms-dynamic-values": {
    "operationId": "PopulateDropdown",
    "value-path": "name",
    "value-title": "properties/displayName",
    "value-collection": "value",
    "parameters": {
        "staticParameter": "<value>",
        "dynamicParameter": {
            "parameter": "<name of the parameter to be referenced>"
        }
    }
}

Hi @darrelmiller,
Thanks for advice. I was thinking about something similar, I mean I wanted to refer to resources existing already within schema. Have You raised any issue to take Microsoft solution into consideration and based on that create standard for specification ? For me the case is not rare so it should be included in specification ?


array_slice panics with stride=1

Describe the bug
See reproduction for specific example that triggers the panic.
Some combination of a column with varying size arrays, a negative start index, a positive end index, and stride explicitly set to one triggers the panic.
To Reproduce
CREATE TEMPORARY VIEW data3 AS VALUES ([1.0, 2.0, 3.0, 3.0]), ([4.0, 5.0, 3.0]), ([6.0]);
❯ select * from data3;
+----------------------+
| column1              |
+----------------------+
| [1.0, 2.0, 3.0, 3.0] |
| [4.0, 5.0, 3.0]      |
| [6.0]                |
+----------------------+
❯ select array_slice(column1, -1, 2, 1) from data3;

thread 'main' panicked at /Users/andy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/arrow-data-51.0.0/src/transform/primitive.rs:31:43:
range end index 9 out of range for slice of length 8

Expected behavior
Doesn't panic. Works just like the stride=1 default.
+-----------------------------------------------+
| array_slice(data3.column1,Int64(-1),Int64(2)) |
+-----------------------------------------------+
| []                                            |
| []                                            |
| [6.0]                                         |

Additional context
This was found upgrading datafusion-python: https://github.com/apache/datafusion-python/pull/669

take

I plan to work on this after #10424 is resolved.


Validate annotations before patching them and only patch if annotations are valid

What does this PR do?

Currently, the language detection patcher doesn't check if the language detection annotations are valid before trying to patch the deployments. However, kubernetes enforce some constraints on resource annotations. This PR avoids patching if the annotations are not valid.
Motivation

Avoid patching if annotations don't meet the kubernetes constraints for resource annotations.
This will avoid that the patcher retries patching invalid annotations several times.
Additional Notes

If a deployment has one container causing the annotation to be invalid (e.g. container with very long name), and other valid annotations to be patched, we should not patch anything at all, in order to let APM SSI inject all supported libraries and not miss traces instead of injecting a partial patch which might potentially cause losing traces.

Possible Drawbacks / Trade-offs

For validation, we are using the kubernetes publicly exposed method for validating annotations. However, some of the asserted constraints rely on the full annotation set of the resource (such as total size of the annotations). In our case, we are only running the validation on the annotations to be patched, and not on the full annotations set of the resource (which probably includes annotations not related to language detection). Therefore, there are some edge-cases where the patch is considered valid, but applying the patch fails because the result of the patch is not valid (e.g. adding an annotation to a resource that has already attained the max size of all annotations). However, this should be okay to ignore and leave it for the api server to fail the operation. Ignoring this is justified for 2 reasons:
These edge cases will rarely occur
Fetching the full annotation set of the deployment resource adds more load on the apiserver as it doubles the number of requests sent to the apiserver (for each deployment, the request will have to send a read request, followed by a patch request).

Describe how to test/QA your changes

Deploy the agent with APM SSI and language detection enabled:
datadog:
  apiKeyExistingSecret: datadog-secret
  appKeyExistingSecret: datadog-secret
  kubelet:
    tlsVerify: false

  # datadog.apm.instrumentation.enabled
  apm:
    instrumentation:
      enabled: true

clusterAgent:
  enabled: true
  admissionController:
    enabled: true
    mutateUnlabelled: true
  env:
    - name: DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INJECT_AUTO_DETECTED_LIBRARIES
      value: true

Create a separate namespace for your application
kubectl create namespace application

Create a deployment with two containers, one having a regular name, and one having a super long name.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: python-and-ruby-deployment
  namespace: application
  labels:
    app: user-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: user-app
  template:
    metadata:
      labels:
        app: user-app
    spec:
      containers:
        - name: dummy-ruby-container
          image: ruby:2.7-slim # You can replace this with the desired Ruby base image
          command: ["ruby", "-e", "loop { sleep 1000 }"] # Ruby script to sleep forever
        - name: dummy-python-container-long-long-long-long-long-long-long-long-long-long-long-long-long
          image: python:3.7 # Replace with your Python image
          command: ["python3", "-u", "your-python-script.py"]
          volumeMounts:
            - name: python-script-volume
              mountPath: /your-python-script.py
              subPath: your-python-script.py
      volumes:
        - name: python-script-volume
          configMap:
            name: python-script-configmap
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: python-script-configmap
  namespace: application
data:
  your-python-script.py: |
    while True:
      pass

What you should expect is not to have any language annotations patched on the deployment, and have an error log in the cluster agent indicating that the event handling failed due to the very long annotation key.
Here is an example of the error:
2024-04-11 16:58:08 UTC | CLUSTER | ERROR | (pkg/clusteragent/languagedetection/patcher.go:231 in handleDeploymentEvent) | failed to handle deployment event: annotations: Invalid value: "internal.dd.datadoghq.com/dummy-python-container-long-long-long-long-long-x.detected_langs": name part must be no more than 63 characters

/merge


clear data of select2

I had this line of code
$("#select").select2("val", null);
on version 4.0.2 it was working
i have updated to 4.0.3 and now it doesnt !

Can you expand upon the issue you are facing by adding a few more pieces of information to your bug report?

What steps can be used to reproduce the issue?
What is the bug and what is the expected outcome?
What browser(s) and Operating System have you tested with?
Does the bug happen consistently across all tested browsers?
Can you reproduce this issue on the examples page?
What version of jQuery are you using? And what version of Select2?
Are you using Select2 with other plugins?

The contributing guide contains a useful section with a few questions which can help us track down the bug and speed up the process of finding a fix for it.  The creation of an isolated test case would also be useful.

Hi. thanks 4 answer me.
I need to blank a select2. Empty it.
I had used this line on version 4.0.2 and it works
Now I found another way to do this.
$(".js-example-basic-single").html('').select2();

Now I found another way to do this.

Awesome.

Insert this code into your js file :
$('.sgl').val('1');
$('.sgl').trigger('change');


Dartpad sample app URLs Need corrected

Hello! Thank you for this awesome resource.
There has been an update to the URL structure for dartpad, and so the links are broken.
Currently, links are provided in the format:
https://dartpad.dev/d0cc86ebee39474f97d3c079c7437752
Whereas they should be:
https://dartpad.dev/?id=d0cc86ebee39474f97d3c079c7437752

Thank you for raising this issue @TJGhinder. I'll get it resolved soon.


Clarified systemd friendly path

Suggested-by: Rendezvous
I also took the liberty of combining some commands.

[x] read the CONTRIBUTING guidelines
[ ] raised a GitHub issue or discussed it on the projects chat beforehand
[ ] added unit tests
[ ] added integration tests
[x] updated documentation if needed
[ ] updated CHANGELOG.md

This is based on my suggestions, looks good. The systemd friendly path did not make sense to me, this should help future users.


Issue with aqtinstall Command: Unresponsive Download Link

Describe the bug
I am encountering an issue while using the aqtinstall command as mentioned below. Specifically, the download link seems to be unresponsive or malfunctioning.
python -m aqt install-qt --outputdir C:\\test windows desktop 5.15.2 win32_msvc2019 -m qtquicktimeline

To Reproduce
Steps to reproduce the behavior:

install aqt using this command

python -m pip install aqtinstall

run aqt with this command

python -m aqt install-qt --outputdir C:\\test windows desktop 5.15.2 win32_msvc2019 -m qtquicktimeline

See error

C:\Users\leeja\Desktop\MonitorControlPortalMaster\AzurePipeline\template>python -m aqt install-qt --outputdir C:\\test windows desktop 5.15.2 win32_msvc2019 -m qtquicktimeline
INFO    : aqtinstall(aqt) v3.1.6 on Python 3.10.4 [CPython MSC v.1929 64 bit (AMD64)]
INFO    : Downloading qtconnectivity...
INFO    : Downloading qtgraphicaleffects...
INFO    : Downloading qtquicktimeline...
INFO    : Downloading qtmultimedia...
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Downloading qtquicktimeline: attempt #2...
INFO    : Downloading qtgraphicaleffects: attempt #2...
INFO    : Downloading qtmultimedia: attempt #2...
INFO    : Downloading qtconnectivity: attempt #2...
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Downloading qtquicktimeline: attempt #3...
INFO    : Downloading qtgraphicaleffects: attempt #3...
INFO    : Downloading qtmultimedia: attempt #3...
INFO    : Downloading qtconnectivity: attempt #3...
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Downloading qtgraphicaleffects: attempt #4...
INFO    : Downloading qtmultimedia: attempt #4...
INFO    : Downloading qtquicktimeline: attempt #4...
INFO    : Downloading qtconnectivity: attempt #4...
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Downloading qtquicktimeline: attempt #5...
INFO    : Downloading qtmultimedia: attempt #5...
INFO    : Downloading qtgraphicaleffects: attempt #5...
INFO    : Downloading qtconnectivity: attempt #5...
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Downloading qtdeclarative...
INFO    : Downloading qtimageformats...
INFO    : Downloading qtxmlpatterns...
INFO    : Downloading qtwebsockets...
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Redirected: mirrors.sjtug.sjtu.edu.cn
INFO    : Downloading qtdeclarative: attempt #2...
INFO    : Downloading qtimageformats: attempt #2...

Expected behavior
A clear and concise description of what you expected to happen.
aqt output
Add program output to help explain your problem.
Collecting charset-normalizer<4,>=2 (from requests>2.20.0->aqtinstall==3.1.6)
  Downloading charset_normalizer-3.1.0-cp311-cp311-win_amd64.whl (96 kB)
     ---------------------------------------- 96.7/96.7 kB 5.4 MB/s eta 0:00:00
Collecting idna<4,>=2.5 (from requests>2.20.0->aqtinstall==3.1.6)
  Downloading idna-3.4-py3-none-any.whl (61 kB)
     ---------------------------------------- 61.5/61.5 kB 3.2 MB/s eta 0:00:00
Collecting urllib3<3,>=1.21.1 (from requests>2.20.0->aqtinstall==3.1.6)
  Downloading urllib3-2.0.2-py3-none-any.whl (123 kB)
     -------------------------------------- 123.2/123.2 kB 7.1 MB/s eta 0:00:00
Collecting certifi>=2017.4.17 (from requests>2.20.0->aqtinstall==3.1.6)
  Downloading certifi-2023.5.7-py3-none-any.whl (156 kB)
     -------------------------------------- 157.0/157.0 kB 9.2 MB/s eta 0:00:00
Collecting beautifulsoup4 (from bs4->aqtinstall==3.1.6)
  Downloading beautifulsoup4-4.12.2-py3-none-any.whl (142 kB)
     -------------------------------------- 143.0/143.0 kB 8.8 MB/s eta 0:00:00
Collecting soupsieve>1.2 (from beautifulsoup4->bs4->aqtinstall==3.1.6)
  Downloading soupsieve-2.4.1-py3-none-any.whl (36 kB)
Building wheels for collected packages: patch, bs4
  Building wheel for patch (pyproject.toml): started
  Building wheel for patch (pyproject.toml): finished with status 'done'
  Created wheel for patch: filename=patch-1.16-py3-none-any.whl size=12393 sha256=4f77f3d2d8bbbf679cfc57e0ddae87e3bd778177e8d89bd8cc66d64c39a1cc29
  Stored in directory: c:\users\vssadministrator\appdata\local\pip\cache\wheels\cb\ee\c0\8b7da5d06750d049187f4672e1fd70fade43ec0d2ee5b5fcda
  Building wheel for bs4 (pyproject.toml): started
  Building wheel for bs4 (pyproject.toml): finished with status 'done'
  Created wheel for bs4: filename=bs4-0.0.1-py3-none-any.whl size=1266 sha256=3aaf9e3d5f4d998149228ecb881e6328736397e433d8e840b4799a37b858d5af
  Stored in directory: c:\users\vssadministrator\appdata\local\pip\cache\wheels\d4\c8\5b\b5be9c20e5e4503d04a6eac8a3cd5c2393505c29f02bea0960
Successfully built patch bs4
Installing collected packages: texttable, patch, brotli, urllib3, soupsieve, semantic-version, pyzstd, pyppmd, pycryptodomex, pybcj, psutil, multivolumefile, inflate64, idna, humanize, defusedxml, charset-normalizer, certifi, requests, py7zr, beautifulsoup4, bs4, aqtinstall
Successfully installed aqtinstall-3.1.6 beautifulsoup4-4.12.2 brotli-1.0.9 bs4-0.0.1 certifi-2023.5.7 charset-normalizer-3.1.0 defusedxml-0.7.1 humanize-4.6.0 idna-3.4 inflate64-0.3.1 multivolumefile-0.2.3 patch-1.16 psutil-5.9.5 py7zr-0.20.5 pybcj-1.0.1 pycryptodomex-3.17 pyppmd-1.0.0 pyzstd-0.15.7 requests-2.30.0 semantic-version-2.10.0 soupsieve-2.4.1 texttable-1.6.7 urllib3-2.0.2

Desktop (please complete the following information):

OS: windows
aqt version [aqtinstall(aqt) v3.1.6 on Python 3.10.4 [CPython MSC v.1929 64 bit (AMD64)]]

Additional context
It appears that Qt is currently not providing the necessary download files on their website. Attempting to download the file resulted in an "access denied" message: https://s3.jcloud.sjtu.edu.cn/899a892efef34b1b944a19981040f55b-oss01/rsync/qt/143ed6ead1e80f323217f7a30cde97f1b955e766
However, I did find a successful download link:
https://download.qt.io/online/qtsdkrepository/windows_x86/desktop/qt5_5152/qt.qt5.5152.win32_msvc2019/5.15.2-0-202011130602qtmultimedia-Windows-Windows_10-MSVC2019-Windows-Windows_10-X86.7z.mirrorlist
This leads me to suspect that there may be an issue with the mirror file. It's possible that Qt is not aware of this issue yet.

I would like to report this issue and seek assistance in resolving it.


Content of "training.txt"

Change your training.txt by this path/To/Img;numberOfTheSet 👍
Or don't but you left your personnel informations ❌
I don't know how to do a pull request 🤔

The content of the file is an example. It's not my real environnement.


Upload packfiles directly to Sia

This should improve performance by uploading packfiles directly to Sia Skynet rather than parsing them into individual objects and uploading those. We'll have to keep track of what's in each packfile in the chaintree (see the filesystem storage in go-git for reference). Presumably we'll want to cache them after downloading so that any other object read requests for things in the same packfile will already have what they need. That should improve cloning / pulling performance quite a bit.

https://filebase.com/ runs a cache service for sia. It really fast. DGIT could run a cache  server cloud or locally.


Switch project structure to ReactionNext

Checked failures:

Codacy wants use to add Dockerfile maintainer but we shouldn't. Should disable that codacy rule
Lint: eslint passes but prettier fails. However, when I let prettier fix, it actually makes changes that go against our eslint rules. So it seems like prettier config needs some tweaking.
Snyk: The issues are with react-scripts deps. I don't want to eject from create-react-app if we can avoid it, so hopefully those will be fixed upstream soon.
Test: They pass locally but Jest seems to be misconfigured on CI. Will need to investigate eventually

FYI @ticean
Merging this since there are no more actual issues to fix.


Deprecate project directories outside of project root

@bot-gradle quickFeedbackLinux

Sorry I don't understand what you said.
Currently I support the following commands:

@bot-gradle test {BuildStage} to trigger a build

e.g. @bot-gradle test SanityCheck plz
SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/ReadyForMerge/ReadyForNightly/ReadyForRelease are supported
test this means test ReadyForMerge
SanityCheck can be abbreviated as SC, ReadyForMerge as RFM, etc.
Specific builds:

AST: AllSmokeTestsReadyForMerge
AFT: AllFunctionalTestsReadyForMerge
ASB: AllSpecificBuildsReadyForMerge
ACT: AllCrossVersionTestsReadyForNightly
APTN: AllPerformanceTestsReadyForNightly
AFTN: AllFunctionalTestsReadyForNightly
ACTR: AllCrossVersionTestsReadyForRelease
AFTR: AllFunctionalTestsReadyForRelease

@bot-gradle help to display this message
@bot-gradle clean to clear the conversation history

@bot-gradle test QuickFeedbackLinux

OK, I've already triggered QuickFeedbackLinux build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@rieske The PR (finally) passed on CI. Please give it a review.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.


CON-1193 Fixed the bootRun task

What was the issue? I tested your branch before I approved and it worked.
If these changes are required then the docs will need to be updated as well.

The command './gradlew host:bootRun' was not working.

The example provided in the docs, the hello-world sample does not use Gradle but instead java -jar host/build/libs/host-mock.jar


[CP] [vm/ffi] Fix variadic arguments on MacOS Arm64

Commit(s) to merge

c0b938c2286d99be3ff65f62bb3e627dd0fb2361

Target
stable
Prepared changelist for beta/stable
https://dart-review.googlesource.com/c/sdk/+/369822
Issue Description
Variadic arguments on Mac Arm64 weren't working correctly due to misalingment.
What is the fix
Distinguishing stack alignment of FFI call arguments between varargs and non-varargs.
Why cherry-pick
To prevent JNIgen having to target the 3.5 master branch for Flutter/Dart.

https://github.com/dart-lang/http/issues/1213#issuecomment-2147125270

Risk
Small: It's a couple of lines of code CL (with many lines of code tests).
Issue link(s)
https://github.com/dart-lang/sdk/issues/55471
Extra Info
No response

sgtm

Released in 3.4.4.


lib.attrsets.matchAttrTag: init

Description of changes
As suggested in https://github.com/NixOS/nixpkgs/pull/284551#pullrequestreview-1961816244, this is a useful utility function for working with values from lib.types.attrTag:
lib.matchAttrTag "my.option" value.my.option {
  tag1 = tagValue: "Tag1: ${tagValue}";
  tag2 = tagValue: "Tag2: ${tagValue}";
}

This was written in Nix Hour 68
Ping @roberth
Things done

[x] Add documentation
[x] Add tests
[ ] Update lib.types.attrTag docs to mention this function

Add a :+1: reaction to pull requests you find important.

Oh this looks really nice. I make extensive use of attrTag and this would make the processing logic much easier (at least, it would be much simpler than whatever this is :sweat_smile:)