Determine implications of OGC API - Common - Part 2

The SWG today (2020-05-27) discussed whether the development of OGC API - Common - Part 2: Collections might have implications for OGC API - Coverages. The SWG agreed to revise the document, if possible, to be consistent with OGC API - Common - Part 2: Collections.

The SWG on 2020-05-27 agreed that @jerstlouis would review the specifications and estimate the changes needed and how long they might take to apply to the document.
@jerstlouis will report back to the SWG on 2020-06-03.

Cc: @cmheazel @Schpidi

An important on-going discussion has been happening in Common ( https://github.com/opengeospatial/oapi_common/issues/140 ), and it seems like we are finally converging towards solutions to settle the big Collections issue.

Relation type
So far, one important change is that the "items" relation type would not be appropriate for coverage. The exact meaning of an "items" relation type is still being discussed (e.g. whether it implies that the link follows the /items semantics of the Features API), but it seems now that the relation type would be the primary mechanism by which a client recognizes the access method provided by a link. This enables supporting more than one access method for a single collection (e.g. the same data available through SensorThings, Features and Coverage), while identifying which link provides which access method. Therefore I suggest to change this relation type from "items" to "coverage".

Extensible /collections/{collectionId} resource
It has also been clarified that by default, a JSON schema is extensible unless "additionalProperties" is explicitly set to false. So it would already be perfectly okay to add additional information directly at /collections/{collectionId}, and part of my suggestion was that some coverage resources which are not going to be overly lengthy could be provided as properties of the /collections/{collectionID} resource. I believe this could generally include the DomainSet, RangeType and Metadata. As the Metadata seems to be currently described as application-specific, perhaps this could be a general Common concept rather than coverage-specific. For the DomainSet, it might be that non-gridded coverages require a more verbose description. In this case, perhaps it could be specified that as an alternative to fully describe the whole DomainSet, a link to a DomainSet resource could be provided instead. What is currently being returned from /coverage would nicely merge into that {collectionID} resource. The envelope could be an extra property with more complex coverage-semantics which the {collectionID}'s spatial and geospatial extent do not support describing adequately.

/coverage, /coverage/description, /coverage/all and /coverage/rangeset
Currently, /all is indicated as returning "everything", i.e. both the coverage description and the coverage data itself (the RangeSet). One of my concerns with this is that some formats (media types) may either:

not support specifying the data alone without the description (netCDF? GeoTIFF?)
while other RangeSet formats may not support specifying the description at all
To keep things simple, I would suggest that:
/collections/{collectionId} embeds the description as properties, except when the DomainSet is too bulky in which case the domainSet property could be omitted, and a link with "rel" : "domainSet" could be included instead linking to /coverage/DomainSet.
/collections/{collectionId}/coverage returns the data (RangeSet), and if the selected media type defines a mechanism for it, the description components as well.
/coverage/rangeSet could still optionally be supported to return only the data without the description for formats that support this.

Like Features and Tiles, no specific media types is mandated by Coverage. This is good, but Features and Tiles make some recommendations on specific formats that are commonly implemented. I could not find any such recommendation in the current draft specs. I would suggest including at least mentions of CoverageJSON, GeoTIFF and netCDF.

None of the examples responses at https://github.com/opengeospatial/ogc_api_coverages/tree/master/standard/examples/JSON seem to have any proper content. I think the lack of proper examples is quite hindering for developers attempting implementing clients & services. Some of the examples likely require selecting a specific media type, and text-based formats are probably better suited for example responses (e.g. CoverageJSON).

Thanks @jerstlouis for summarizing this important issue.  I have chimed in a bit on https://github.com/opengeospatial/oapi_common/issues/140 as much as I can as time permits, so thanks very much for working on this one and reporting back.  Thoughts related to OACov:

relation type could be ogc-coverage (see related https://github.com/opengeospatial/ogcapi-features/issues/383)
+1 to recommend CoverageJSON, GeoTIFF, NetCDF as media types
we need some effort to start adjusted the various schemas we have and come up with examples.  I'm happy to sprint on this with others.  Would also suggest a once over on the spec and the various JSON/OpenAPI/yaml (even renaming this repo to ogcapi-coverages for consistency with the other standards here on GitHub)

@tomkralidis Thanks!

Would also suggest a once over on the spec and the various JSON/OpenAPI/yaml (even renaming this repo to ogcapi-coverages for consistency with the other standards here on GitHub)

This has also been bugging me a lot. Currently there are all sorts of naming for the repos and it makes them hard to find, especially when switching between them:

ogcapi-features
oapi_common
ogc_api_coverages
wps-rest-binding
OGC-API-Tiles
OGC-API-Maps

It would be nice to standardize this @ghobona .

Note we changed ogcapi-records at some point for the consistency.

@jerstlouis don't forget ogcapi-records! ;)

@pvretano well at least that is consistent with Features ;)

And EDR API has not yet got a new branding (OGC API - Environmental Data Retrieval?)

To summarize point 2 & 3 of the proposal:

Merge current "coverage offering" ({collectionID}/coverage) directly into {collectionID}, e.g. envelope property, and links and/or properties for the coverage description
Get rid of {collectionID}/coverage/description (integrated in {collectionID})
Get rid of {collectionID}/coverage/all (now returned by /coverage)
Get rid of {collectionID}/coverage/rangetype (always a property in {collectionID})
Make {collectionID}/coverage/domainset optional (Can either be a property in {collectionID}, or a link in the case of complex domainset, which may also support subsetting)
Make {collectionID}/coverage/rangeset optional (only present when format supports providing the rangeset without the description)
Make {collectionID}/coverage/metadata optional, linked from {collectionID}

The advantages I see from this is that while it preserves full compatibility with the CIS model, it greatly reduces the entry barrier for non-coverage experts, and facilitates a simple implementation for clients & services, including serving simple coverage data by a static server.
e.g. only two resources are required for a simple one-file gridded coverage GeoTIFF or netCDF:
{collectionID} (which will feature rangetype and domainset properties, as well as optional link to metadata)
{collectionID}/coverage (which will contain the rangeset along with the description supported by the format)

This ( https://github.com/opengeospatial/oapi_common/issues/140#issuecomment-637620660 ) is the comment which is stirring us towards using more specific relation types, and why I was suggesting "coverage" rather than "items" for the {collectionID}/coverage resource.

hm, I see the long and involved description, and the different handling in different branches - now I fail to see how I just can get a coverage. How would I do the equivalent of a vanilla GetCoverage, even without subsetting?

@pebau  {collectionID}/coverage

@pebau Would you have a link to CIS JSON encoding?
Googling for "cis json encoding", first hit is for CoverageJSON :/ ( https://www.w3.org/TR/covjson-overview/ ).
I don't see any issue with adding any formats which existing/initial implementations will support.

@jerstlouis:

Googling for "cis json encoding", first hit is for CoverageJSON :/ ( https://www.w3.org/TR/covjson-overview/ ).

duckduckgoin for "feature" I get a high-ranked
Sneakers, high-end apparel and accessories - Feature
[Search domain feature.com] https://feature.com
Feature was created as a venue where fashion, music and art could co-exist. Since then, it has been our mission to provide the highest quality in footwear, apparel and accessories that street wear and high end fashion culture have to offer.

I don't see any issue with adding any formats which existing/initial implementations will support.

If compatible, yes. And, again, IMHO there are further interesting candidates, such as RDF.
BTW, as I often have expressed I am not against having a compatible CoverageJSON encoding as a CIS encoding. It just is not there yet, whereas OGC coverage JSON is standard, compatible, and therefore makes sense as primary choice.

...just for the sake of avoiding misinterpretations: please read previous search results as tongue-in-cheek!

@pebau Well I always complain about the term feature, especially when used meaning vector data and unqualified as such ;) Still, it would be nice to do some SEO to improve search results on CIS JSON :)
I added CIS JSON and CIS RDF at the head of the list of formats to recommend.
Even if a coverage representation is deemed "incompatible" with CIS, I think we still need to acknowledge the possibility that implementations may be supporting those formats (e.g. @tomkralidis 's implementation was one of the first for OGC API - Coverage, at the coverage & analytics code sprint, and CoverageJSON is the one encoding that he decided to implement. Generally speaking CoverageJSON seems to be quite popular.).
If it is possible to convert between CoverageJSON and a CIS-compliant encoding, is "not compatible" really accurate?

From CoverageJSON (https://www.w3.org/TR/covjson-overview/#cis):
The main points of difference are:

CIS uses a different set of rules for gridded and non-gridded data, whereas CoverageJSON uses a single consistent set.
CIS allows each Coverage to have exactly one CRS, whereas CoverageJSON allows different CRSs to be applied to different sets of coordinates in the domain (e.g. one CRS for x and y, and another CRS for z).
Version 1.1 of CIS defines a JSON encoding that uses a near-literal translation of GML structures into JSON. CoverageJSON does not use GML as its starting point.

I think it will be necessary to accommodate people in both camps :)

@pebau Well I always complain about the term feature, especially when used meaning vector data and unqualified as such ;) Still, it would be nice to do some SEO to improve search results on CIS JSON :)

right, calls for OGC's marketing office ;-)

I added CIS JSON and CIS RDF at the head of the list of formats to recommend.

thanks, appreciated!

Even if a coverage representation is deemed "incompatible" with CIS, I think we still need to acknowledge the possibility that implementations may be supporting those formats (e.g. @tomkralidis 's implementation was one of the first for OGC API - Coverage, at the coverage & analytics code sprint, and CoverageJSON is the one encoding that he decided to implement (unless I'm mistaken and made some wrong assumptions?). Generally speaking CoverageJSON seems to be quite popular.).

well...I could bore you with a list of agencies, businesses, research centers, data providers using CIS JSON, with 2-digit Petabytes of offerings. But me engineer would rather go for the technical merits :-)

If it is possible to convert between CoverageJSON and a CIS-compliant encoding, is "not compatible" really accurate?

definitely that would change it: if both can be converted into each other in both directions without loss of information and with all the coverage types, we have a win.
FWIW, earlier we have worked with encoding writers wanting to bring in their formats into coverage world, such as NetCDF and GRIB2 and JPEG2000, helping to get this correspondence established.

@pebau
Thanks for sharing your thoughts on that comparison. I will definitely need to dig into these further at some point.

so we talk politics now ;-)

No, we explicitly try to stay away from politics :)
(I myself don't belong to either camps, and would be inclined to implement both in our software).
This is partly why I think the OGC API specifications do not mandate a specific media type, recognizing the different needs and preferences of different communities.
And the recommendation is just to provide a sample of commonly used coverage formats, so I think it would be a fair compromise to include both CIS JSON and CoverageJSON in there.

@jerstlouis There is a CoverageJSON standardisation effort, hosted in the WCS SWG, to be started soon. The one technical change that may help compatibility with CIS is the evolution of JSON-LD from 1.0 to 1.1, so there is some work to do besides just editorially producing an OGC standard.
The WCS SWG agreed to host the work last year, rather than have a separate, format only, SWG established. It was put back on the WCS agenda a month of so ago. As you say, there are plenty of implementations, and the user community is supportive of an OGC standardisation effort. I just need to get some money and contractual stuff sorted.
There is even a moribund GitHub repo in waiting: https://github.com/opengeospatial/CoverageJSON

All,

OGC API - Coverages - Part 1: Core is due to be completed by the end of 2020.
CIS is well established within OGC and it has a JSON encoding.
Reading the current version of the OGC API - Coverages spec, the SWG had already selected CIS to work with.

Those are multiple reasons to proceed with CIS as mandatory. CoverageJSON can be optional.
We need to aim to complete OGC API - Coverages - Part 1: Core soon, so that it can be sent to the OAB and the Public for Comment.

@ghobona In Features, no encoding is mandatory.
Was there a decision to have a mandatory encoding in OGC API - Coverage?

... and there is clause_8_media_types.adoc which says "This API-Coverages standard is built around the OGC Coverage Implementation Schema (CIS). CIS content often includes multi-dimensional coordinates and coordinate reference systems in sensor and analytic space. "

@ghobona The way I read the specs right now:

Support for JSON is recommended.
This [CIS JSON] format should be used for all JSON encodings from the {root}/collections/{coverageid}/coverage/* paths.

This would mean (or might be interpreted in this way) that support for CIS JSON is not mandatory, but recommended.
The fact that it mentions all JSON encodings seems in direct conflict with the ability to support additional JSON-based formats.
So I would like to suggest that:

As per this proposal to update the resources, it is clarified that in properties and linked resource for domainset, CIS JSON is what must be used.
For the coverage itself (this proposal suggests to move this to /coverage, with optional /coverage/rangeset for rangeset only), it is strongly recommended that the API supports at least CIS JSON
If the media type "application/json" is used for those resources, this implies CIS JSON.
Alternative JSON encoding such as CoverageJSON can be used, but must be identified by a more specific media type (e.g. something like application/json+covjson).
The references to GeoJSON are very confusing, as GeoJSON is not really used anywhere, and should be moved to a more informal status.

@jerstlouis That's a reasonable proposal, in my opinion.
What do others think of the proposal?

No objections here. Having no mandatory (but recommended) encoding also leaves things open to seeing which formats move forward and are most used (without having to use them).

It also supports the static hosting server use case, where you can simply provide extra static resources (e.g. the {collectionID} etc. in addition to your netCDF or CIS RDF files.

good discussion! If din this suggestion also very reasonable. Brief comparison of format value, for the archive:

JSON: can do n-D although inefficient and not common for higher dimensions; common for 1-D
XML: can do n-D although inefficient and not common for higher dimensions; not commonly used for rangeset of a coverage, but still common for all other components
NetCDF: can do n-D, common for 3D+, not common for 1-D
TIFF: can do 2-D (and 3-D, limited), limited in non-rangeset information; common for 2-D, not others

So while NetCDF on principle could be an overall candidate, ASCII formats like XML and JSON are preferred (i) for low dimensions due to their easier Web integration (really? XML?? - well, there are libraries available these days).
Another point: ISO SQL/MDA [1], the SQL datacube extension, has JSON as default encoding.
Bottom line:I like the "should support JSON".
[1] https://www.iso.org/standard/67382.html
PS: let us just factor out the /rangeset path discussion, please, it is a separate issue.

All, thanks for the feedback. I suggest we formalise the decision regarding Item 4 of https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-637893877 with a Motion during next week's telecon.
Regarding Item 1, is there any objection to the proposal in https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-638167987 to use a relation type of ogc-coverage?
@jerstlouis Regarding, https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-638193236, I am drafting an OGC-NA policy regarding repo naming.

+1 to ogc-coverage.  I'm just wondering whether it could/should be ogc-coverage or ogc:coverage (RE: https://github.com/opengeospatial/ogcapi-features/issues/383 && cc @cportele).

@tomkralidis - I added a comment in the linked issue.

@ghobona I support a motion for Item 4.
To clarify, I am still suggesting that no specific media type is mandated, so an OGC API - Coverage can still be conformant without supporting CIS JSON, but a strong recommendation (should) so that CIS JSON be the first format that a service/client considers supporting (just like in Features this is GeoJSON). Also part of the recommendation is that in the context of the coverage resources, it is clearly indicated that "application/json" refers to CIS JSON (with a link to https://docs.opengeospatial.org/is/09-146r6/09-146r6.html#46), and that any other JSON encoding (e.g. CoverageJSON) must use a more specific media type (it would be good to suggest a media type for CoverageJSON).
Also I think it would be good to get back to issues 2 & 3, and if possible also move on that so that we can adjust the specs accordingly before the OAB review and public comments. At this week's meeting there was no objection raised, but @Schpidi wanted to take a closer look. I summarized the proposed changes in https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-638277791

@ghobona: All fine with me, except for item 3: semantics of /coverage, /coverage/description, /coverage/all and /coverage/rangeset where I heavily disagree.
It is counter-intuitive at best to get a coverage by addressing one of its components, rangeset, although you expect to also get domainset, rangetype, metadata, enevlope, and what not.
What about having features/attributes for accessing the complete features, in comparison?

@pebau maybe I did not communicate this properly...
Assuming we are talking about a CIS JSON media type distribution, which supports both including or excluding the description.
You would get the full coverage including everything at {collectionID}/coverage.
You would get only the rangeset at {collectionID}/coverage/rangeset.
You could get only the domainset at {collectionID}/coverage/domainset, if the server decides to do this because the domainset is complex (otherwise it can be embdded directly as properties in {collectionID}).
The rangetype would also be integrated in the {collectionID} resource.
The main change is that the coverage offering is moved from {collectionID}/coverage to {collectionID}, and so {collectionID}/coverage can return what {collectionID}/coverage/all was returning.
And some resources are made optional to allow for media types that do not allow to describe some of these things by themselves, while it ensures that CIS JSON description of the coverage is always available from {collectionID}.

@jerstlouis, thanks for clarifying. I was not reading carefully enough. So what you describe sounds natural to me: {collectionID}/coverage gives me the coverage, {collectionID}/coverage/{facet} gives me the corresponding coverage facet. Then of course /all is not needed any longer.
Just to be sure: coverages/rangeset gives you only a naked set (in the math sense) of pixels, no georeference, no rangetype, no linearization scheme (aka sequence rule), no metadata, right? Actually, a multi-set like { 10, 10, 40, 49, ..., 250 } .

@pebau correct, but I am suggesting that /rangeset be made optional, because some mediatypes (NetCDF? GeoTIFF?)  would not support such naked set.
I am also dropping /rangetype, because that is always short & sweet and would be included in a property of {collectionID}, to avoid having to perform an additional HTTP round-trip to the server.
For /domainset, the server has the option to either embed it as a property, or link to /coverage/domainset (which is optional, if the property is present). This addresses both the cases where the domainset is simple and when it is more complex and a separate resource (which you could also subset) is justified.
Metadata would be linked from {coverageID} as a separate resource at /coverage/metadata.
Could metadata be made optional?

@pebau correct, but I am suggesting that /rangeset be made optional, because some mediatypes (NetCDF? GeoTIFF?) would not support such naked set.

Unless I'm missing something, I don't think GeoTIFF is such an example.  If a client wants a GeoTIFF of a coverage, how would it make that request if not through the .../coverage/rangeset endpoint?  I was under the impression that:
.../collections/myCollection/coverage/rangeset?f=geotiff

would be more or less equivalent to the following WCS request:
...?service=WCS&version=2.0.1&request=GetCoverage&coverageId=myCollection&format=image%2fgeo%2btiff

On a related note, would it be wrong to have the output of:
.../collections/myCollection/coverage/rangeset?f=json

be:
{
  "type": "RangeSetRefType",
  "fileReference": [
    ".../collections/myCollection/coverage/rangeset?f=geotiff"
  ]
}

@pomakis

If a client wants a GeoTIFF of a coverage, how would it make that request

.../collections/myCollection/coverage?f=geotiff

On a related note, would it be wrong to have the output of: .../collections/myCollection/coverage/rangeset?f=json
be  { ... }

I would expect this to always be a naked rangeset following CIS JSON, not a reference to another format, as per the recommendations earlier clarifying that simply "JSON" encoding for those coverage objects is always CIS JSON.
I am not very familiar with CIS JSON, but I am assuming that your response is not CIS JSON? Otherwise having it be a reference can make it complicated for the client to get to the actual data if it can be a reference.

If a client wants a GeoTIFF of a coverage, how would it make that request

.../collections/myCollection/coverage?f=geotiff

The coverage endpoint is supposed to return the domainset, rangetype and rangeset of the coverage.  Does a GeoTIFF represent all three?  Section 8.3 of the draft "OGC API - Coverages - Part 1: Core" document mentions using multipart/mime or zip, etc., to bundle things together when a binary format such as GeoTIFF is in the mix.  How does this factor into things?  This seems to imply that a GeoTIFF is considered only the rangeset of a coverage, and that if the domainset and/or rangetype also need to be communicated, it should all be delivered bundled as a multipart/mime or zip.
In this light, if the client wants just a GeoTIFF, would it do so via:
.../collections/myCollection/coverage?f=geotiff
or:
.../collections/myCollection/coverage/rangeset?f=geotiff

@pomakis: ahem, no - the GetCoverage request returns the complete coverage, as far as it can be encoded in GeoTIFF (described in the OGC CIS GeoTIFF extension). Somileage varies with the format used, but normally cannot be broken down simply to one or the other coverage constituent. Typically it is a wild ride through the components. For Example, GeoTIFF can hold the domainset coordinates, parts of rangetype (after all, the TIFF file knows the band components by name). Re CRS it knows EPSG, but not temporal CRS. And so on....
The /rangeset component was introduced to extract a particular coverage component. I opposed to this right from the beginning (so about a year now) as it just does not make sense - think of a feature collection where you extract either coordinates or attributes, but not both.
So the most straightforward thing for a client would be your suggestion #51
.../collections/myCollection/coverage?f=geotiff
...why should a naive user need to know what a "rangeset" is?

@pomakis
My opinion is that GeoTIFF is much more than the naked set of values, so it is not just a plain rangeset, and I would argue that although it may not fully describe things per the CIS model, GeoTIFF would be a common community use case.
And we need to consider that as per my suggestion, the {collectionID} (potentially together with a linked /coverage/domainset, in the case of a complex domainset) would already provide a full CIS-complicant description of the coverage.

Section 8.3 of the draft "OGC API - Coverages - Part 1: Core" document mentions using multipart/mime or zip, etc., to bundle things together when a binary format such as GeoTIFF is in the mix.

This is way too complicated and impractical and in my opinion a major barrier of entry for simple implementations.

...coverage encodings are available for different situations in life (all of which have been brought to our doors over the years :) ):

ASCII formats like XML, JSON, RDF: informationally complete, but inefficient (except for 1D)
binary formats: often more or less incomplete, but efficitn. Usually you know what you are requesting and can live with a potential loss.
multipart (container) formats (canonical header in ASCII + factored out parts, stored binary): informationally complete and efficient

...so users are free to pick their favourite.

@pomakis:

This is way too complicated and impractical and in my opinion a major barrier of entry for simple implementations.

A simple implementation would not support it, it is in the "cage" of a separate conformance class. Some implementations iwll only want to support NetCDF, or only GeoTIFF, or...

@pebau but my point is that a we want it to be simple for a server to support GeoTIFF, without having to do this multipart stuff.
It's easy with my proposal, and can even be done with a static webserver:
{collectionID} has the CIS JSON description
{collectionID}/coverage.geotiff is the GeoTIFF coverage ("rel" : "ogc-coverage")

My opinion is that GeoTIFF is much more than the naked set of values, so it is not just a plain rangeset,

exactly, and that is why /rangeset does not solve the encoding question.

and I would argue that although it may not fully describe things per the CIS model, GeoTIFF would be a common community use case.

yes, definitely - and therefore GeoTIFF is a perfectly valid output format. Just if you want to import that again into some CIS service it does not fulfil the requirement of completeness. But normally you export TIFF because you want to feed a GIS.

it does not fulfil the requirement of completeness.

This is why I suggest to always have the CIS JSON mandatory in {collectionID} (with potentially the domainset part linked rather than embedded).

@pomakis That is part of the simplification that my proposal implies.
It was also making me dizzy, and I think things should be as simple as they can to facilitate adoption, while ensuring that we don't lose capabilities to address the use cases originally intended.

glad to sense that the story is converging gradually!
One thought: why specifically the domain set at  {collectionId} ? I know I am on thin ice now after my discussion of rangeset, but several components might make sense to be extractable:

envelope ("where roughly is this coverage in space and time, in my dear WGS84?")
domainset ("where exactly, in its native CRS?") -- note that, although normally it will be comparatively small, this can become quite large, in the extreme case larger than the range set for very complex coverages
metadata ("what coverages do we have from IGN-F?"...thinking of INSPIRE here)
rangetype ("what timeseries do you have?")

Note that I am not (!) opting for getting all the fuss back, it is more about not making domainset stand out.

@pebau
My suggestion was to always mandate that all of the following be included at {collectionID}:

envelope
rangetype (encoded per CIS JSON specs)
domainset (encoded per CIS JSON specs) either as a property, or as a link to {collectionID}/coverage/domainset (For those use cases when it can be large)
coverage metadata as an optional link
link to {collectionID}/coverage ("rel" : "ogc-coverage")
link to {collectionID}/coverage/rangeset, if a naked value set is supported by the media type (e.g. for CIS JSON)

@jerstlouis
OK, so who would decide whether a link or the real thing gets delivered? Are you maybe thinking of allowing a ?fmt=... for domainset?

@pebau the server has both options -- "domainSet" property,  or ("rel" : "ogc-domainSet"?) link.
The recommendation would be that a separate resource and a link should be used if the DomainSet  is more complex than simple dimension(s) bound.
At minimum, a CIS JSON DomainSet must be provided (either as a property, or as a link).
Links to DomainSet resources in additional formats can always be provided (e.g. even if a CIS JSON property is used) with a different media type -- it doesn't matter whether if the linked URL is using ?fmt= or ?f= or .something.

Regarding "envelope", I have not brought this up yet because it may be contentious, but

"where roughly is this coverage in space and time, in my dear WGS84?"

Is exactly the purpose of the Common "extent" property (already included in {collectionID}, and I would suggest that if it is lacking in any way, it be addressed in the context of that Common property.
Although I would not call it a deal-breaker for this proposal if we need to keep a redundant "envelope" :)

Scanning through this issue -- very happy to see the progress.
Just want folks to be aware of this issue: https://github.com/opengeospatial/oapi_common/issues/76 and that it is going to the NA to determine how we are going to handle link-relations not to be registered with IANA.

@jerstlouis: ok, if the envelope can be expressed via an extent (can it be n-D?) then why not declare that in OAPI the coverage envelope is given by an extent item.

@jerstlouis:

the server has both options -- "domainSet" property, or ("rel" : "ogc-domainSet"?) link.

Can you show an example of what the corresponding client code is looking like that gets a domainset?

@pebau Currently, it can be 4-D (CRS84h which is CRS84 + height) + temporal.
I don't believe it currently supports more than that, but I assume that additional dimensions could be added (the extent has a "spatial" and "temporal" member, so we could probably add something like an "extra" member?)
Also, I may be mistaken, but aren't the bounds of those extra dimensions defined in the DomainSet anywyas? If so, having those 4D might be good enough for the quick check of "extent", and the details are in the CIS JSON encoding of the DomainSet.
Re: client code for retrieving domainset, I don't have such client code yet, but it would:

Look for a "domainSet" property as part of the ../{collectionID} resource. If it's there, the value follows the CIS JSON encoding
If it's not there, it must be part of the links (same links where the "ogc-coverage" link to {collectionID}/coverage is found), and it can find such a link with "rel" : "ogc-domainset" and "type" : "application/json", which will be the CIS JSON encoded DomainSet. This may also mean that this linked domainset resource supports queries (specified in /conformance as a conformance class indicating DomainSet subsetting is supported by the service?)

@jerstlouis re extent: hm, why trying to tweak (there will be issues indeed) and not simply add an n-D bbox to Common? Would be a nice package together with n-D subsetting that was decided to go into Common as well.

@jerstlouis I seem to remember that OAPI should be simple, but now it adds substantial complexity burden on the client programmer's side. Instead of a single GET request now some 20 lines of non-trivial code just to get a domainset?

@pebau re: extent -- it is already the 4D BBOX of Common. I suggest tweaking it (e.g. adding way to specify extra dimensions) to turn it into an n-D extent? This way the part that clients understand will be compatible (they'll at least understand the 4D part).
If we add a separate 'envelope' property, we would still need to include the extent. So that would be somewhat redundant. (plus the DomainSet may also duplicate some of that information?)
Re: OGC API being simple, the property and link patterns, and "follow the link", are something clients must implement anyway for every resource, so it is trivial.
Advantages of not always making the DomainSet a resource when it is simple are that:

Clients avoid having to request an additional resource and make an extra round-trip to the server
Servers have one less resources to provide, which is particularly convenient e.g. for the simple case of serving a gridded coverage like a GeoTIFF.

...sorry, all that makes me prefer the so much simpler DescribeCoverage and GetCoverage.

@pebau well, WCS is not going away ;)
Would you prefer if the DomainSet was always a separate resource & link?
This would mean always a minimum of 3 resources rather than 2, and always forcing an extra round-trip to the server, even if the domainset is very simple.
.../{collectionID}, .../{collectionID}/coverage, .../{collectionID}/coverage/domainset
RangeType would still always be in {collectionID}.
This would not be my preference, but if folks prefer this we could go with that...

@jerstlouis no, I am not in love with GetCoverage (and for sure not with DescribeCoverage), it is just a practical vehicle. And as it represents the state of the art it is my reference for all new ways: does an alternative provide more simplicity or add more complexity?
Currently the complexity gap discussed here is at 200% - 300% if I understand right.

...and why actually do we keep shifting functionality up and down paths? For the machine, it's just strings that are longer or shorter, so a nobrainer. For humans, though, it decides about usability, coding speed and error probability.
My KISS favourite still is:
.../coverage/ -- full coverage
.../coverage/X -- component, where domainset, rangeset, rangetype, metadata make sense (and if need be, rangeset)
and then if we wish we can lateron add convenience branches like
.../coverage/comainset/crs
.../coverage/rangetype/red
if a client fears the result of say domainset can be too large use
.../coverage/comainset?f=url
to obtain a reference.

Given the following clarification from @jerstlouis at https://github.com/opengeospatial/oapi_common/issues/140#issuecomment-642299075, the WCS SWG needs to decide whether OGC API - Coverages- Part 1: Core has a dependency on OGC API - Common - Part 2: Collections or not.
"As for freedom to specify collections as they see fit, as clarified previously no standard would be required to be based on OGC API Common - Part 2, even though I believe it should be a recommendation of Common for APIs whose purpose is to distribute geospatial data."
If there is no dependency, then I will ask the SWG to pass a Motion at its next meeting to close this issue. If there is a dependency, then the potential implication is that OGC API - Coverages- Part 1: Core would have to wait for OGC API - Common - Part 2: Collections to be completed.

IMHO the Collections concept of OAPI is not adequate to reflect the structure of a coverage. It is relevant, though, to model collections of coverages (which has been stated earlier by several stakeholders). Therefore, there should not be a normative dependency. Rather, coverages should be modelled after the emerging ISO 19123-1 which will also become OGC Abstract Topic 6.

@ghobona Based on the current draft specifications of coverage (including updates agreed upon based on this issue at the last SWG meeting) and the consensus forming in Common, I am of the opinion that there is a dependency on Part 2: Geospatial data.
However this should be a reason to prioritize & accelerate OGC API Common - Part 2, rather than delay OGC API - Coverage.
Regarding @pebau 's concern on collections of coverages, I believe this can be addressed as part of https://github.com/opengeospatial/oapi_common/issues/11 , and this could be an extension to Common - Part 2, and not an immediate requirement to make progress. Any coverage end-points defined for a single coverage will also work tacked onto a coverage part of a collection of coverages.
OGC API - Coverage can depend on OGC API - Common Part 2 while also being modeled after ISO 19123-1. All that Common Part 2 states is that OGC API - Coverage distributes a "collection of geospatial data" as a coverage.

July 15, 2020 SWG:

Both rangeType and domainSet could be either embedded or referenced at /collections/{collectionID} using a Common-defined mechanism ("$ref" ?  "rangeType": {"$ref": "https://....."} -- https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03 )
rangeSet can be an optional resource at {collectionID}/coverage/rangeSet , only provided for representations supporting a naked rangeSet -- a link relation type must be defined
"envelope" will always be included in /collections/{collectonID} resource
CIS (coverage) metadata for the coverage can optionally be available via a link relation type to be defined, e.g. at /{collectionID}/coverage/metadata

Associated issue as discussed in OGC API - Common https://github.com/opengeospatial/oapi_common/issues/155

Sorry I missed this 2020-07-15 teleconference; I didn't notice its date and time until it was too late.
I've got a question about the "envelope" decision.  Is this "envelope" in addition to the "extent" property that already exists at that endpoint?  If so, that seems awfully redundant.
I also want to mention that CubeWerx has a test implementation of 'OGC API - Coverages" up at "https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa".  This OGC API service provides a coverage called "Daraa_mosaic_2019" (in addition to a number of vector feature sets).  If anybody toys with this and sees any implementation detail that doesn't seem right to them, please let me know.

@pomakis great!  Are there associated JSON reprensentations that we can review?

The only representation we currently support for the coverages themselves is GeoTIFF.  However, the domain set and range type can be requested separately via collections/{collectionId}/coverage/domainset and collections/{collectionId}/coverage/rangetype respectively.  Each of the endpoints has a few optional query parameters, which are listed in the OpenAPI description at "https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/api".

@pomakis Regarding envelope, I have made the same remark since the beginning of the issue, and we discussed this again today in the call. One reason that envelope persists is because Coverages may define additional dimensions not yet defined in the bounding box. I suggest that bounding box should be extended instead. @Schpidi brought up another concern is CRS other than WGS84, but again isn't the envelope in fact always WGS84 when it concerns the spatial dimensions? ( https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-638991260 )
I would say that part if the envelope story is not yet entirely settled, and we can open up a further issue to discuss merging it within the extent properly (I would be strongly in favor of that). But at lesat today the decision is that envelope will not be its own resource and will for now be a Coverage extension added to collections/{collectionID}.
Thanks for sharing your implementation. With a quick look, based on the decisions today:
{"href":"https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/coverage?f=json","rel":"coverage","type":"application/json","title":"the coverage of this collection"}
This is linked and currently returns an error. If this were to return something proper, based on previous decisions this should be CIS JSON (CoverageJSON would need to use a more specific media type).
{"href":"https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/coverage/domainset?f=json","rel":"coverage","type":"application/json","title":"the domain set of the coverage of this collection"},
{"href":"https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/coverage/rangetype?f=json","rel":"coverage","type":"application/json","title":"the range type of the coverage of this collection"}
Today we agreed that either embedded or embedded for both rangeType and domainSet should be supported.
The discussion though leaned towards using the "$href" mechanism, so I am guessing this would mean always using a property rather than using an element of links OR a property. There are on-going discussion about this about guidance from Common though (See https://github.com/opengeospatial/oapi_common/issues/155). I would actually prefer using either a links element or a property, but when using links a proper relation type would have to be defined. You are using "coverage" for everything (coverage, rangeSet, domainSet) in your API and I think that is problematic as one cannot distinguish only by "type" (e.g. application/json is defined as the media type for CIS JSON which can represent all of these).
As a side note I would suggest to also add the Daraa DTED in there as well as an example of an elevation coverage  ;)
(http://maps.ecere.com/geoapi/collections/vtp/Daraa2/Daraa_DTED -- I am planning to update our service as well before the next Coverage code sprint in August).

brought up another concern is CRS other than WGS84, but again isn't the envelope in fact always WGS84 when it concerns the spatial dimensions.

Bounding box in a capabilities response has traditionally been a hint of the east west north south area covered by the data set.  There has never been a requirement that the data set actually be available in WGS 84 long lat.

because Coverages may define additional dimensions not yet defined in the bounding box.

A coverage may express all of it's dimensions in outside of the WGS 84 dimensions, not just additional ones.  I mean the actual data rather than the hint of the location.
I assume a coverage could have all it's dimensions  as different from the bounding box

@nmtoken And that would all be perfectly fine with the .../collections/{collectionID} extent property.
If for some reason a coverage really does not map any "spatial" dimension at all, then "spatial" could be omitted from the extent.
(Though really, if it is real-world data, it normally would be associated with at least one point in space where the measurement occurred?)

@jerstlouis Two examples:

How about sampling the genome of a specific human to construct their full DNA sequence (3.2GB) viewed as a coverage. Even time, within a few thousand years, might not be relevant? ;-)
Use wavelength/frequency as a dimension, for averaged radiative properties of the whole earth. Other dimension could be time.
In API EDR we assume extents always 4D. If not fully specified, defaults could apply, including error condition, like 'latest', 'top', 'nearest', etc.

Does anybody else think that we are doing a Procrustes exercise here, just to force the more powerful concept of multi-dimensional coverages into feature flatland? ;-)

Don't want to add confusion, but we've had some interesting discussions on modelling coverages with the spatial aspect being provided via references to administrative units, in this case one coverage axis refers to these external polygons
On the one had this is an edge case, on the other shows how even spatial may be there but in a non-spatial axis

@chris-little , all...
Well OK.
But we can still include all these non-traditional use cases in a {collectionId} "extent" and omit the "spatial" property.
So as @pomakis suggested again, I strongly support merging envelope with extent, because it really is the exact same thing.

@jerstlouis wrote:

Thanks for sharing your implementation. With a quick look, based on the
decisions today:
{"href":"https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/coverage?f=json","rel":"coverage","type":"application/json","title":"the
https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_mosaic_2019/coverage?f=json","rel":"coverage","type":"application/json","title":"the
coverage of this collection"}
This is linked and currently returns an error. If this were to return
something proper, based on previous decisions this should be CIS JSON
(CoverageJSON would need to use a more specific media type).

Ooops, that link should be ".geotiff" with a media type of "image/geo+tiff".  I'll put up a fix for this within the next couple of days.  Of course, without subset, scaleFactor and/or responseHandler parameters, the requested resource would be too large, as it would request the entire coverage at full resolution.
@jerstlouis wrote:

Today we agreed that either embedded or embedded for both rangeType and
domainSet should be supported.
The discussion though leaned towards using the "$href" mechanism, so I
am guessing this would mean always using a property rather than using an
element of |links| OR a property. There are on-going discussion about
this about guidance from Common though (See
opengeospatial/oapi_common#155
https://github.com/opengeospatial/oapi_common/issues/155). I would
actually prefer using either a |links| element or a property, but when
using links a proper relation type would have to be defined. You are
using "coverage" for everything (coverage, rangeSet, domainSet) in your
API and I think that is problematic as one cannot distinguish only by
"type" (e.g. application/json is defined as the media type for CIS JSON
which can represent all of these).

I'm okay with going either way on this.  I agree that using links with rel="coverage" for everything is problematic; I implemented it that way for now just to get something going.
@jerstlouis wrote:

As a side note I would suggest to also add the Daraa DTED in there as
well as an example of an elevation coverage ;)
(http://maps.ecere.com/geoapi/collections/vtp/Daraa2/Daraa_DTED -- I am
planning to update our service as well before the next Coverage code
sprint in August).

Sure.  Where can I get the source data for this coverage?

@pomakis I believe that DTED is at
https://portal.ogc.org/index.php?m=projects&a=view&project_id=621&tab=2&artifact_id=92004
for VTP2.
And
https://portal.ogc.org/index.php?m=projects&a=view&project_id=550&tab=2&artifact_id=83535
for Testbed 15.
@jeffharisson Could you please confirm it's okay for that DTED data to be shared from demo implementations?

All, the extent object in common/features is meant to be extensible so other keys can be added that represent the extent that you wish to convey.  The extent schema in common/features even says ..."Extensions may add additional members to represent other extents, for example, thermal or pressure ranges."
So let say you have an N-dimensional extent that you wish to communicate ... simply add a new key (e.g. "my_nd_extent"), defined as required and plop it into the extent object.  If the your extent object also includes enough information to populate the bbox and temporal keys then copy the relevant information into those keys as well to play nice with clients that happen to know how to handle bbox and temporal but may not recognize your domain/community-specific extent key.
{
"bbox": { ... },
"temporal": { ... },
"my_nd_extent": {...},
.
.
.
}
I see very little reason to define a new extent object when the existing one is extensible!  Sorry to jump in like this; I have not been following too closely so if what I say is foolish, please ignore! ;)

Okay, I've added the Daraa_DTED coverage to the test implementation at "https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa".  I've also corrected the rel="coverage" links.

@pomakis Nice! Thanks! :)

BTW, is anybody aware of a media type for DTED (even an ad-hoc one)?  I'd like to allow clients to be able to POST new DTED sources to the https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa/collections/Daraa_DTED endpoint, but would need it to recognize a DTED-specific Content-Type for this to work.  As it stands now, a client would either have to convert the DTED to a single-band integer GeoTIFF first, or package the DTED in a ZIP file.

@pomakis I kicked the bear (NGA) because they are the owner/maintainer of the DTED standard, and so far, they don't know of any.

hm, we have a baseline that CIS 1.1 is to be used. Hence, the envelope has to be there, no way around.
If you want to add extent or something else, that's ok (coverage metadata can hold that) with a description how it is derived from domainset or envelope, but the coverage structure must remain...well, the coverage structure. Otherwise it's not a coverage any longer. That's what all the implementations out there that rely on the CIS standard will tell.

@pebau The envelope is there, but would be encoded in the "extent" property.
It follows the CIS logical model.

@jerstlouis ok, so we are defining a new coverage encoding? No problem with that, we just maybe should state it clearly and define the concrete mapping, as the CIS format encodings do - they give nice, easy to follow precedence.

@pebau in a sense, yes, but specifically to describe for the envelope as the "extent" property of the .../collections/{collectionId} resource.
The full CIS JSON encoding of the coverage, including the envelope, can still be made available at .../collections/{collectionId}/coverage .

@jerstlouis so the suggestion is to define two independent data structures, one for a complete coverage response and one for the components? My naive idea was that the component requests simply return coverage components, as their name says. For me that variety is harder to understand and remember.

@pebau What we agreed at the meeting last Wednesday was:
.../{collectionId}/coverage -- returns the whole coverage with all its components supported by the selected representation (e.g. CIS JSON, NetCDF, GeoTIFF... )
.../{collectionId}/coverage/rangeSet -- An optional resource to return only the naked range set, when that is supported for a given representation (linked from .../{collectionId} with a specific relation type).
.../{collectionId} -- includes the envelope, rangeType and domainSet. For the envelope I believe we are now coming to an agreement that it should simply be encoded in the "extent" property. The rangeType and domainSet may either be embedded or linked. The "$ref" approach was suggested as one mechanism to achieve this. An alternative would be to use the links together with a specific a relation type for each of the rangeType and domainSet. Suggested paths where those would be found would be .../{collectionId}/coverage/rangeType and .../{collectionId}/coverage/domainSet.

@jerstlouis

.../{collectionId} -- includes the envelope, rangeType and domainSet. For the envelope I believe we are now coming to an agreement that it should simply be encoded in the "extent" property.

I disagree strongly. First, a long history of discussion ( in OAPI-Coverages and outside) has shown that it will not be able to reflect the information properly. Second, I see no specification of that. In order to even conduct a meaningful discussion we would need a concrete mapping proposal: how is each envelope item mapped to a corresponding extent item?
Currently we are at the level of hand waving, without a clear discussion basis.
So, how would the supporters suggest to map, concretely?

...generally speaking, for all stated as agreed, can you please point us all to the specification, examples, etc? thanks!

Well OK.
But we can still include all these non-traditional use cases in a {collectionId} "extent" and omit the "spatial" property. We can either regroup these in some Coverage-specific property for everything that is not temporal and not spatial, or define more specific ones.

how?

So as @pomakis suggested again, I strongly support merging envelope with extent, because it really is the exact same thing.

merge = enhance extent with envelope information and make it the new OAPI-Common extent?

@pebau OGC API - Common extent defines "spatial" for WGS84, and "temporal" (both instant and intervals).
It is also extensible.
So we could for example define a property called "coverage-axes", which maps to all other dimensions which could not be described, and this can follow the traditional "envelope" approach for those.
Would you have an envelope example of a very complex coverage with space, time and additional dimensions, that I could use as a basis for an example to illustrate on how to encode it?
As for specifications, I have been working on them all day yesterday and all night and still now to try present something at our meeting today :)

@jerstlouis re example, here is the canonical example collection: http://schemas.opengis.net/cis/1.1/gml/examples-1.1/
Maybe most interesting are the "non-standard" cases, ie 1D time, Index CRS, 4D, etc. as opposed to 2D Lat/Long.

I submitted Pull Request https://github.com/opengeospatial/ogc_api_coverages/pull/76 to try to update the standard to reflect these changes, and address other issues in the draft as well (removed unnecesary concept of a default encoding, reorganized conformance classes, addressed some media type issues). To some extent it is still work in progress. I included an itemized summary of the changes in the PR comment.

20200902: Coverages SWG call: Embedding vs. referencing of DomainSet and RangeType. It was decided to recommend to Common to explicitly allow relative links in the same document in the href element like "href": "#domainSet". This way we would make the link mandatory which could be a relative link in the same document.

PR https://github.com/opengeospatial/ogc_api_coverages/pull/87 should address the last remaining aspects of this issues.

20200909: Coverages SWG call: PR #87 was merged and it was agreed to close this issue.


Add test for testing memory usage for celery task

I want to merge this change because this test will check memory usage of that task

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations

Docs

[ ] Link to documentation:

Pull Request Checklist

[ ] Privileged queries and mutations are either absent or guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migrations are either absent or optimized for zero downtime
[ ] The changes are covered by test cases

Should we also register slow mark in PyTest confing in saleor/setup.cfg?

Not needed in this case as there is a fixture defining its existence:
https://github.com/saleor/saleor/blob/e0ff00724d601bb975edfc1cb83797f57bc30f98/conftest.py#L37-L38
e.g. we have this fixture in Saleor tests but not defined explicitly in our setup.cfg https://github.com/NyanKiyoshi/pytest-django-queries/blob/2aab6237ad6fee2ef836a7c34927a5876bd58513/pytest_django_queries/plugin.py#L107-L111
Whenever pytest starts, it will load the configuration fixtures to allow them to alter the behavior of pytest.


Sass 3.2

Do you still need to support Sass 3.2?

Not sure. How unpopular is it nowadays?

Not sure we have stats about this, but I think it is safe to say it's getting old.

Want to PR this as well after you rebase the other PR?

Will merge


Small change to introductionary paragraph

Nothing really wrong with this - but tidied up intro paragraph and spotted a missing 's' on need.  Was unsure if 'losslessly compressed with adapted lossless format' was longform for 'RAWcooked encoded'.  It may need re-adding into the sentence somewhere!

I slightly modified one modification (it is not RAWCooked data + sidecar data, RAWcooked data is the sidecar data ;-) ).

I'm glad you do, I can't know things this half so well as you :)


[SPARK-44357] [PYTHON] Add pyspark_testing module for GHA tests

What changes were proposed in this pull request?
This PR adds a new module and modifies GHA for pyspark.testing.utils doctests.
Why are the changes needed?
This change ensures that doctests are run by GHA, since pyspark.testing.utils now contains user-facing APIs with docstrings
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing unit tests

Merged to master.


the example totally not works for me

I tried the example but totally not work. The example code structure looks outdated.

First of all, you didn't fill out the Issue Template. Your issue is lacking important informations like version numbers and reproductible examples.
The example app, as well as the Readme and the Docs are up-to-date.
You can download examples/Playground and run it locally thanks to Expo. This is the same App with which I test and experiment locally, so it's up-to-date.
Also, v1.0.0 was just released 2 weeks ago, so nothing should be outdated. ☺ That being said, please make sure you're actually using v1.0.0.
If you have further questions, please specify what exactly doesn't work (e.g. are there any errors?) and share code examples.
I'm going to close this issue since it's very vague, but you can still comment.


Switching pipelines does not always show corresponding files

Describe the bug
I'm observing that, when switching pipelines inside the pipeline editor, the corresponding files are not always shown, and a refresh is needed.
Expected behavior
Every time I switch pipelines, the corresponding files are shown.
To Reproduce
Steps to reproduce the behavior:

Import "quickstart" project and open the pipeline editor
Create a new pipeline
Switch to it and observe that no files are shown ✔
Switch back to the original pipeline and observe that still no files are shown :x:
Refresh (or click the "pipelines" menu button again) and see the original files back ✔
Switch to the empty pipeline and observe that the other files are still there :x:
Refresh (or click the "pipelines" menu button again) and see no files ✔

Screenshots
https://user-images.githubusercontent.com/316517/167577112-43fbb399-2621-4691-97e2-d71e29c77cc5.mp4
Environment

OS (e.g. macOS): Linux Mint
Browser (e.g. Chrome): Firefox
Orchest's version (in the settings page): v2022.05.2

I think this issue has been fixed in #949 and will be included in the next release (v2022.05.4). Feel free to reopen if the issue still persists.


ENG-8436-window load composable events

Adding compose support to sdk with window load and unload events. Target and Compile sdk cahnged to 33 to support composable libs.

looks good:
The call:
NeuroID.getInstance()?.compose?.trackPage("personalInfo")
The output:
2024-08-06 09:44:20.895 13558-13558 NeuroID Debug Event     com...uroid_android_compose_sandbox  D  EVENT: WINDOW_LOAD - null - meta=null, attrs=[{jetpackCompose=true}], ec=personalInfo
2024-08-06 09:44:39.463 13558-13558 NeuroID Debug Event     com...uroid_android_compose_sandbox  D  EVENT: WINDOW_UNLOAD - null - meta=null, attrs=[{jetpackCompose=true}], ec=personalInfo


AccessViolationException while running MassTransit tests

Is this a bug report?
Yes
Can you also reproduce the problem with the latest version?
Yes
Environment
Dotnet version: netcore 3.1
Operating system: Windows 10
IDE: Visual Studio 2019
Broker: dockerized Confluent Kafka lensesio/box
MassTransit version: 7.1.5
Steps to Reproduce
Have Confluent Kafka running locally in Docker container.
Create .Net Core Nunit test project.
Paste the content of tests from MassTransit repository: https://github.com/MassTransit/MassTransit/blob/develop/tests/MassTransit.KafkaIntegration.Tests/Producer_Specs.cs#L109
Install required nugets with MassTransit 7.1.5.
Run the tests.
Expected Behavior
Tests should pass.
Actual Behavior
AccessViolationException is thrown. I've made some MassTransit version regression, and when I've set the version to 7.0.7, the error ceased to occur, therefore it seems like it was introduced in version 7.1.0. But having version 7.0.7, I had to comment out the line .Produce(x => x.Init<KafkaMessage>(new { Text = "text" })) in the state machine, because it is not supported, thus the second test couldn't be ran.
Also, there could be some problem with the aformentioned Produce (or Init) method because when I try to run tests for the production solution, they are stuck on the first line with these methods.

Reproducible Demo
NUnitTestProject1.zip

All the unit tests pass on my machine, without any access violations, both in Rider and from the console:
Test run for /Users/chris/Code/MassTransit/tests/MassTransit.KafkaIntegration.Tests/bin/Debug/netcoreapp3.1/MassTransit.KafkaIntegration.Tests.dll (.NETCoreApp,Version=v3.1)
Microsoft (R) Test Execution Command Line Tool Version 16.8.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.

Passed!  - Failed:     0, Passed:    13, Skipped:     0, Total:    13, Duration: 12 s - /Users/chris/Code/MassTransit/tests/MassTransit.KafkaIntegration.Tests/bin/Debug/netcoreapp3.1/MassTransit.KafkaIntegration.Tests.dll (netcoreapp3.1)

Because Confluent.Kafka uses librdkafka under the hood, I'd suggest you bringing this to Confluent's attention, and note any different between the package used in 7.0.7 and the current packages.

Moving a single test into a separate assembly isn't going to change that behavior. When I asked for a standalone repro case, I meant a standalone console application that reproduces the issues (with Program.cs) not just moving the unit test into a separate project.

Even the project you supplied executes fine, no exceptions:
Test run for /Users/chris/Downloads/NUnitTestProject1/bin/Debug/netcoreapp3.1/NUnitTestProject1.dll (.NETCoreApp,Version=v3.1)
Microsoft (R) Test Execution Command Line Tool Version 16.8.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.

Passed!  - Failed:     0, Passed:     2, Skipped:     0, Total:     2, Duration: 2 s - /Users/chris/Downloads/NUnitTestProject1/bin/Debug/netcoreapp3.1/NUnitTestProject1.dll (netcoreapp3.1)

The exception occurred also on the machines of my two co-workers.

Like I said, you might want to raise an issue with Confluent, it's their library and that's where the Access Violation is occurring. I can't research an issue I can't reproduce.

you need really to chase Confluent, they probably already have this issue in GH (at least I've seen it 2 or more years ago). It is the issue with Confluent and docker integration. But today they have their own docker image for kafka, so if you are not using it - you need at least to try it out.

My testing was using Kafka in Docker, with the docker-compose.yml file located in the unit tests project.

yeah, and it is exactly from confluent

I am going to close this unless it turns out to be an issue related to MassTransit.


Unable to run in production on Openshift

Hi,
I use the Programmatic API (v2.beta.20 & v2.beta.24) and I added the following from your example:
const dev = process.env.NODE_ENV !== 'production';
const dir = process.cwd();
const app = next({ dev, dir });

The server is running, but on any request it gives me the following error:
Client side it's an 500 error: Internal Server error
In the logs, I have:
glob error { Error: EACCES: permission denied, scandir '/var' errno: -13, code: 'EACCES', syscall: 'scandir', path: '/var' }

/var is the root folder on Openshift which I don't have access to.
I don't see why Next is looking for that folder because I have set up the next.dir accordingly.

@kadiks could you check process.cwd()? We don't look for /var anywhere in the next.js code

I even did it on the app instance and the value is fine:
console.log('server.js app.dir', app.dir); // server.js app.dir /var/lib/openshift/xxxx/app-root/runtime/repo

Is there a place where Next look into the root folder?

It is related to permissions.
The glob module fails because it cannot even ls on the /var folder (unlike Heroku where it's possible)
I didn't fix it, but it has nothing to do with Next.JS

Same problem in termux(android) and ubuntu when changing filesystem root permissions (EACCES: permission denied, scandir '/').
I think it could be fixed calling glob-promise with nocase: false when on linux (platform === 'linux' || platform === 'android'). Or maybe catching the EACCES error and trying with nocase: false.
https://github.com/zeit/next.js/blob/443b1d1260bda7a91fb797ca04b94c55ddb91a98/server/resolve.js#L82

Thanks @Wesitos  for your solution . it's works for dev mode
But for const app = next({dev: false, dir: process.cwd()}) I received the following error :
{ Error: Cannot find module 'next\dist\lib\error.js'
    at Function.Module._resolveFilename (module.js:538:15)
    at Function.Module._load (module.js:468:25)
    at Module.require (module.js:587:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/melkima/public_html/.next/dist/pages/_error.js:3:18)
    at Module._compile (module.js:643:30)
    at Object.Module._extensions..js (module.js:654:10)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
    at Function.Module._load (module.js:491:3) code: 'MODULE_NOT_FOUND' }

what's the problem?
my server.js config:
const next = require('next');
const routes = require('./routes');
const app = next({dev: false, dir: process.cwd()});

const handler = routes.getRequestHandler(app);

var compression = require('compression');
var express = require('express');
app.prepare().then(() => {
    express().use(compression()).use(handler).listen(3000);
});


❓ np.nan value from bed.compute()

Hi,
I try to follow 1000G_example.ipynb with read_plink function and when I compute the genotype code from bed file, I get some nan values, does this value represents binary genotype code 3 which is Homozygous for second allele?
Thank you

Hi @SamuelCahyawijaya ,
I've just update it (now it is named Example.ipynb). Please, have another look at it.
NaN means missing value. Please, have a look at https://pandas-plink.readthedocs.io/en/latest/api/pandas_plink.read_plink.html I have just added an example there.
Thank you for the interest =)

Hi @horta ,
Thanks for your help and quick response 👍
I have checked the documentation and the updated Example.ipynb, it is clear now.
Thank you :)


what is the meaning of this?

Why would anyone need to install this module when it comes bundled with npm?

Presumably to use it in a browser....
This is a package I've inherited, and it's not actively maintained.  I'm really not sure why so many Node-specific packages rely on it.  Perhaps it should be deprecated.

@jinder in the browser? I can't imagine this code would work in browser. process is undefined in the browser, so https://github.com/jinder/path/blob/master/path.js#L25 would throw an error.
For example browserify has it's own path shim which has nor process references:
https://github.com/substack/path-browserify/blob/master/index.js
I think people are installing this, because they don't know this is built in. A lot of people first come to node via something like express tutorial and in it, they have to install everything.
I think this should really be removed from NPM. No need to vaste megabytes of bandwith downloading this.

Although it's not packaged (browserify-style), it does depend on the process and util NPM packages.  So there's certainly going to be dependencies that are using it and packaging it themselves.
I agree with what you're saying though.  But I won't remove it from NPM (hundreds of dependent packages and half a million downloads a month).  Perhaps a deprecate and notice would be sufficient?

@jinder you can't really use this module unless you specify a require by absolute or relative path. So if there is a project, which has this as dependency and requires a path by doing: require('path') it get's the bundled native module not this one. And I seriously doubt anyone would be requiring path module like this:
require('./node_modules/path')
And if someone does, well, then he had this coming.

I'm a bit apprehensive about pulling this from the registry without knowing for sure it won't break anything.
I'll deprecate it this weekend and monitor it for a while to see what to do next.
A bit of background about how I've inherited this from @coolaj86:  I needed to use a package that depended on this, however it was published to the NPM registry without any licensing information.  Which meant the only way I could use it, was by re-publishing it (copy + paste from node core) and updating the package.json with relevant licensing details.

it should be easy to try out-just find some packages which have CI setup this in package.json and remove it and make a PR.

You certainly can use it without having a absolute/relative path.  RequireJS lets you specify the paths in its config for named modules.
You're welcome to contact any of the dependent libraries to investigate more.  For the moment, I think it's only safe to deprecate it.

You could of course add a little love to it like this:
if (process.versions && process.versions.node) {
    console.warn("[path installed via npm]: YOU'RE DOING IT WRONG! See https://github.com/jinder/path/issues/6");
}

Actually... you could do what I do with unibabel's package.json
I set "main": "node.js" and "browser": "unibabel.js".
You can then set the node.js to output "you're using this module incorrectly".
Also, a person can't really accidentally use this from npm. require('path') with always return the internal node module. require('path/'), however, would search node_modules.

I think in those instances, you'd only see the message if they're specifically forcing the use of the package under Node.  Really, what we want is to somehow notify users who have it listed as a dependency in their package.json, but are actually using the native node module.  i.e. it's an unnecessary dependency.

attach a message using npm deprecate?
npm deprecate path@"< 99" "This is for the BROWSER. Do NOT use it for NODE. See https://github.com/jinder/path/issues/6"

You could use the module in a browser environment together with browserify. I have tested this and it works and I am going to use this module for these purposes.
My app runs in node.js and browser environments so this is the perfect module for me.

Okay, so, latest plan of action:  Update the readme to clearly indicate it's not necessary to have a dependency on this module if you're only running on Node. Any objections? :)

+1 for this

Just noticed on NPM 3 at least, the following appears when running install:
npm WARN package.json<EMAIL_ADDRESS>path is also the name of a node core module.


Enable Var.CI

Automate some contribution guidelines checking:

Submissions include link in PR description (not just README)
Submissions should include a description (no empty bodies)
Links must be valid

Merging this now. Thanks @ziadoz for authorizing the bot!


feat(queryCache): pass query to subscribers

Any cache update triggered by a query will pass the query as the second argument to subscribers.
This enables executing side-effects for specific query updates.
BREAKING CHANGE: none

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Battery percentage icon for taskbar

Description of the new feature / enhancement
Be able to view battery percentage near battery icon

Scenario when this would be used?
More convenient than hovering over the battery icon
Supporting information
No response

/dup #15212


feat(fault-tolerance): enhanced fault tolerance cooperate with AIMaster role.

Ⅰ. Describe what this PR does

enhanced fault tolerance cooperate with AIMaster role.

II. Does this pull request fix one issue?

III. Special notes for reviewers if any.

Codecov Report

Merging #268 (9727419) into master (171c0d7) will increase coverage by 0.49%.
The diff coverage is 40.67%.

@@            Coverage Diff             @@
##           master     #268      +/-   ##
==========================================
+ Coverage   28.93%   29.43%   +0.49%
==========================================
  Files          88       89       +1
  Lines        5985     6193     +208
==========================================
+ Hits         1732     1823      +91
- Misses       4000     4108     +108
- Partials      253      262       +9

Flag
Coverage Δ

unittests
29.43% <40.67%> (+0.49%)
:arrow_up:

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

Impacted Files
Coverage Δ

apis/training/v1alpha1/pytorchjob_defaults.go
18.51% <0.00%> (-0.72%)
:arrow_down:

controllers/pytorch/pytorchjob_controller.go
0.59% <0.00%> (-0.01%)
:arrow_down:

controllers/pytorch/status.go
0.00% <0.00%> (ø)

pkg/gang_schedule/coscheduler/scheduler.go
74.13% <0.00%> (-5.50%)
:arrow_down:

pkg/job_controller/job.go
25.15% <0.00%> (+0.46%)
:arrow_up:

pkg/job_controller/service.go
0.00% <0.00%> (ø)

pkg/util/errors.go
0.00% <0.00%> (ø)

pkg/util/status.go
62.22% <0.00%> (ø)

pkg/gang_schedule/volcano_scheduler/scheduler.go
75.38% <9.09%> (-6.29%)
:arrow_down:

pkg/job_controller/util.go
23.80% <33.33%> (+1.58%)
:arrow_up:

... and 4 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[react-native][js] unhandled rejections

Describe the bug
I upgraded to the new React Native SDK and now I'm getting unhandled rejections in my bugsnag Inbox. The problem is that it's hard to tell what's going on as in the "Promise Rejection Tracking" tab there's only non-error parameter false. I'm uploading source maps but maybe there's something wrong with that?
Environment

Bugsnag version: @bugsnag/react-native 7.3.3
Device (e.g. iphonex): Android release build, Hermes enabled.

Error messages:
node_modules/promise/setimmediate/rejection-tracking.js:71
promise rejection tracking received a non-error. See "promise rejection tracking" tab for more detail.

@radko93 as far as I can tell this is not an issue with the notifier so I'm going to close this issue from here.  However, please send an email to<EMAIL_ADDRESS>and we'll be very happy to assist with the issue.


Include sbin for ifconfig command

This fixes the issue of a 'command not found' error on OS X while executing the systeminformation package in electron.

@OhKai added this to the code base. Version 4.16.1 just released.


Enable JMX and Prometheus metrics RSRVR-119

@adamdickmeiss I won't be adding tests for this.

If we like this we should make it part of folio-vertx-lib. Then the option is recognized for all folio-vertx-lib based applications.


Update README.md

Fixed type-O

Since I didn't realize this was your first PR, can you also add yourself to CONTRIBUTORS.md in another PR.


Lights not detected after Home Assistant 2023.9.x update

Describe the bug
Casambi lights no longer detected after updating HA to 2023.9.x
To Reproduce
Downgrading to 2023.8.4 helps solving the issue.
Expected behavior
Detect and control lights.
Debug logs
Provide debug logs for integration and aiocasambi in plain text, remove credentials. Enable them through configuration.yaml e.g:
logger:
  default: info
  logs:
    homeassistant.components.casambi: debug
    custom_components.casambi: debug
    aiocasambi: debug

Logger: homeassistant.components.binary_sensor
Source: helpers/entity_platform.py:621
Integration: Binary Sensor ([documentation](https://www.home-assistant.io/integrations/binary_sensor), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+binary_sensor%22))
First occurred: 25 September 2023 at 23:58:51 (6 occurrences)
Last logged: 25 September 2023 at 23:58:51

casambi: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'Casambi', 'default_model': 'Casambi', 'identifiers': {('casambi', '3CVlNqOjl1assafafsROpPEOtBWWGW-3785adb4bb69')}, 'manufacturer': 'Tridonic GmbH & Co KG', 'model': 'bDW Driver (Dim/pushBUTTON)', 'name': 'Svetaine 2', 'sw_version': '39.48'} for 'casambi' config entry: device info needs to either describe a device, link to existing device or provide extra information.
casambi: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'Casambi', 'default_model': 'Casambi', 'identifiers': {('casambi', '3CVlNqOjlsdfsdfsdfsdfPEOtBWWGW-0asdfsdfsdf8030')}, 'manufacturer': 'Tridonic GmbH & Co KG', 'model': 'bDW Driver (Dim/pushBUTTON)', 'name': 'Corridor', 'sw_version': '39.48'} for 'casambi' config entry: device info needs to either describe a device, link to existing device or provide extra information.
casambi: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'Casambi', 'default_model': 'Casambi', 'identifiers': {('casambi', '3CVlNqOjl1IsdsfsdfsdfpPEOtBWWGW-425sdfsdfsdfdb4c')}, 'manufacturer': 'Tridonic GmbH & Co KG', 'model': 'bDW Driver (Dim/pushBUTTON)', 'name': 'Miegamasis 1', 'sw_version': '39.48'} for 'casambi' config entry: device info needs to either describe a device, link to existing device or provide extra information.
casambi: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'Casambi', 'default_model': 'Casambi', 'identifiers': {('casambi', '3CVlNqOjlsdfsdfsdfsdfpPEOtBWWGW-d4asdfsdfsdf3584')}, 'manufacturer': 'Tridonic GmbH & Co KG', 'model': 'bDW Driver (Dim/pushBUTTON)', 'name': 'Miegamasis 2', 'sw_version': '39.48'} for 'casambi' config entry: device info needs to either describe a device, link to existing device or provide extra information.
casambi: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'Casambi', 'default_model': 'Casambi', 'identifiers': {('casambi', '3CVlNqsfdsdfsfdsdfsdfsPEOtBWWGW-3csdsfdsf001')}, 'manufacturer': 'Casambi', 'model': 'Xpress', 'name': 'Xpress', 'sw_version': '35.0'} for 'casambi' config entry: device info needs to either describe a device, link to existing device or provide extra information.

2023-09-25 23:59:49.626 ERROR (MainThread) [aiocasambi.websocket] websocket: Unexpected Exception: < 'NoneType' object has no attribute 'async_create_task' type="<class 'AttributeError'>">
2023-09-25 23:59:49.629 ERROR (MainThread) [aiocasambi.websocket] An unknown exception was thrown!

Additional context
If log above is not sufficient I will provide full.

I had a similar issue, failed on the first device info pull. Restart got the devices back again.
Probably some kind of timing issue with the new home assistant. Try a restart and see if it helps.
I am currently starved on time, so I don't have more time at the moment to look into the issue more deeply.

Thanks! Indeed it works after some time - have working it this morning. What I saw for multiple integrations is that developers adding more retries/longer wait times till it timeouts. Not sure how it's done exactly, but maybe it points to the right direction.


feat: dynamic color palettes(WIP)

I've created followings to treat color palettes dinamically, but it's still buggy.

useDojoColorPalettesStore
update SimpleColorPicker
GetColorPalettes

The error is:
no rows returned by a query that expected to return at least one row", details: [], metadata: MetadataMap { headers: {"content-length": "0", "content-type": "application/grpc-web+proto"} }
Before merge it, we have to fix it.

For now, I've commented out all buggy codes, but you can try it out by including them.


Build info extractor have repository hardcoded as ArtifactoryDummyRepo

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Versions

Extractor version:
Operating system:
Artifactory Version:

Additional context
Add any other context about the problem here.

In the below link artifact repository is hardcoded which leads to the build failures.
https://github.com/jfrog/build-info/blob/71938a9726346645db85754df97fe2cb350044f8/build-info-extractor-maven3/src/main/java/org/jfrog/build/extractor/maven/ArtifactoryProjectBuilder.java#L39
Gives the exception as
Caused by: java.net.UnknownHostException: ArtifactoryDummyRepo.


Add mention that Rust isn't a requirement anymore for installing the gem

I think it is worth calling this out, otherwise, people will think it is still a requirement and may end up not using the gem due to it introducing Rust as a dependency

Thank you @marcelolx !


[tool_crash] StateError: Bad state: No context with the running Dart application.

Command
flutter run

Steps to Reproduce

...
...
...

Logs
StateError: Bad state: No context with the running Dart application.
#0      RemoteDebuggerExecutionContext.id (package:dwds/src/debugging/execution_context.dart:55:7)
<asynchronous suspension>
#1      AppInspector._getExtensionRpcs (package:dwds/src/debugging/inspector.dart:538:20)
<asynchronous suspension>
#2      AppInspector._initialize (package:dwds/src/debugging/inspector.dart:97:34)
<asynchronous suspension>
#3      AppInspector.initialize (package:dwds/src/debugging/inspector.dart:160:5)
<asynchronous suspension>
#4      ChromeProxyService.createIsolate (package:dwds/src/services/chrome_proxy_service.dart:216:18)
<asynchronous suspension>

[✓] Flutter (Channel stable, 3.0.4, on Microsoft Windows [Version 10.0.19044.1889], locale en-US)
    • Flutter version 3.0.4 at C:\Users\HP\Documents\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 85684f9300 (10 weeks ago), 2022-06-30 13:22:47 -0700
    • Engine revision 6ba2af10bb
    • Dart version 2.17.5
    • DevTools version 2.12.2

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at C:\Users\HP\AppData\Local\Android\sdk
    • Platform android-33, build-tools 33.0.0
    • Java binary at: C:\Program Files\Android\Android Studio1\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at C:\Users\HP\AppData\Local\Google\Chrome\Application\chrome.exe

[✓] Visual Studio - develop for Windows (Visual Studio Community 2019 16.11.18)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.11.32802.440
    • Windows 10 SDK version 10.0.19041.0

[✓] Android Studio (version 2020.3)
    • Android Studio at C:\Program Files\Android\Android Studio1
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] Android Studio (version 4.1)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[✓] VS Code (version 1.71.0)
    • VS Code at C:\Users\HP\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.48.0

[✓] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19044.1889]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 104.0.5112.102
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 105.0.1343.27

[☠] HTTP Host Availability (the doctor check crashed)
    ✗ Due to an error, the doctor check did not complete. If the error message below is not helpful, please let us know about
      this issue at https://github.com/flutter/flutter/issues.
    ✗ HandshakeException: Connection terminated during handshake
    •

! Doctor found issues in 1 category.

Flutter Application Metadata
Type: malformed
Version: 1.0.1+2
Material: true
Android X: false
Module: false
Plugin: false
Android package: null
iOS bundle identifier: null
Creation channel: null
Creation framework version: null
Plugins
awesome_notifications-0.7.0-beta.2
device_info_plus-3.2.3
device_info_plus_linux-2.1.1
device_info_plus_macos-2.2.3
device_info_plus_web-2.1.0
device_info_plus_windows-2.1.1
external_path-1.0.1
file_picker-4.5.1
firebase_core-1.17.0
firebase_core_web-1.6.4
firebase_messaging-11.4.0
firebase_messaging_web-2.4.0
flutter_inappwebview-5.4.3+7
flutter_plugin_android_lifecycle-2.0.6
open_file-3.2.1
package_info_plus-1.4.2
package_info_plus_linux-1.0.5
package_info_plus_macos-1.3.0
package_info_plus_web-1.0.5
package_info_plus_windows-1.0.5
path_provider-2.0.9
path_provider_android-2.0.12
path_provider_ios-2.0.8
path_provider_linux-2.1.5
path_provider_macos-2.0.5
path_provider_windows-2.0.5
permission_handler-9.2.0
permission_handler_android-9.0.2+1
permission_handler_apple-9.0.4
permission_handler_windows-0.1.0
sqflite-2.0.2+1
url_launcher-6.1.0
url_launcher_android-6.0.16
url_launcher_ios-6.0.15
url_launcher_linux-3.0.0
url_launcher_macos-3.0.0
url_launcher_web-2.0.9
url_launcher_windows-3.0.0
video_player-2.4.0
video_player_android-2.3.2
video_player_avfoundation-2.3.3
video_player_web-2.0.8

Hi @aienary, this issue was previously reported and was tracked in https://github.com/flutter/flutter/issues/95916.
It has since been fixed and the fix is available on the master channel.
I'll be closing this issue since it has already been fixed on the master channel.
If you still experience this issue on the master channel or later versions of flutter, kindly file a new issue.
Thank you!


versionIRI no longer contains date

Hello,
I noticed recently that the versionIRI was changed and no longer contains a specific release date, which makes it much harder for me to keep track of the version of the ontology in the owl file that I am using. In the meantime I suppose I could use the oboInOwl:date line instead, but would it be possible to move back to a versionIRI with a release date in the future?
Sarah

Hi Sarah,
Thank you for putting in the issue request. I apologize that this was taken out. Our pipeline had not been updating the date since 2015, so I thought including the date in the version line would not be important. This has been added back into the files.
Thanks,
Dave


Can't determine third party packages when it's installed globally

Here's a workaround(s): https://medium.com/@zwinny/different-isort-results-from-the-same-version-15c277600957
My static analysis checks fail on dockerized isort because it's not in virtualenv and so it can't determine which packages are first or third party. On virtualenv installation it correctly puts all nonlocal in third party. On global installation (docker image, "python:3.5") it doesn't recognize third party packages and just puts them all into first party section.

I have mine working with global installations in docker. Are you running the isort inside of the docker container or somewhere else? If it can't pick up which party the modules are in it's usually a sign that it doesn't have access to the correct pathing, I was running my isort locally one time and not inside the docker which caused the isort to put them in the wrong order.

There has been a considerable amount of work done since this issue was raised to improve isort's discovery of import locations. I am hopeful that this issue is now fixed, if this proves incorrect please feel free to open a new issue or write a comment here.
Thank you!
~Timothy


Purge all data for already deleted project

Idea is to add support for hard deleting APIs so that we can clean up outdated projects on a regular basis and save db space.

Is this issue fixed by the commits listed here?


[4.2] IRGen: Use swift_getObjectType to get the type(of:) mixed classes.

A Swift subclass of an ObjC class can be dynamically subclassed, but type(of:) shouldn't return the artificial subclass, since that's not what -class does for ObjC classes, and people expect Bundle(for: type(of: c)) to work like [NSBundle bundleForClass: [c class]] would in ObjC. Fixes rdar://problem/37319860.

@swift-ci Please test

@swift-ci Please test source compatibility

Build failed
Swift Test OS X Platform
Git Sha - 20bc010e5f9925c8ed2c8e237d9b6c5cb61b0dbc

@swift-ci Please test

@swift-ci Please test source compatibility

@swift-ci Please test source compatibility

Build failed
Swift Test OS X Platform
Git Sha - 20bc010e5f9925c8ed2c8e237d9b6c5cb61b0dbc

Build failed
Swift Test Linux Platform
Git Sha - 20bc010e5f9925c8ed2c8e237d9b6c5cb61b0dbc


Preserve names of arrays and iteration variables across generated boundary

Fixes #74

Codecov Report

Merging #75 into master will decrease coverage by 0.23%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##           master      #75      +/-   ##
==========================================
- Coverage   93.23%   92.99%   -0.24%
==========================================
  Files          27       27
  Lines        2808     2713      -95
==========================================
- Hits         2618     2523      -95
  Misses        190      190

Impacted Files
Coverage Δ

src/condense_loopset.jl
93.22% <100%> (+1.89%)
:arrow_up:

src/reconstruct_loopset.jl
92.41% <73.33%> (ø)
:arrow_up:

src/filter.jl
4.16% <0%> (-95.84%)
:arrow_down:

src/vectorizationbase_extensions.jl
42.85% <0%> (-14.29%)
:arrow_down:

src/lower_constant.jl
87.3% <0%> (-4.89%)
:arrow_down:

src/broadcast.jl
87.28% <0%> (-2.06%)
:arrow_down:

src/costs.jl
83.01% <0%> (-1.89%)
:arrow_down:

src/lower_compute.jl
98.52% <0%> (-1.48%)
:arrow_down:

src/graphs.jl
86.15% <0%> (-0.44%)
:arrow_down:

src/lower_load.jl
100% <0%> (ø)
:arrow_up:

... and 13 more

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 07e71a1...7b43d46. Read the comment docs.

This is fantastic!
As a quick comment, I avoided making any of the structs parametric because I wanted to move towards everything being concretely typed as quickly as possible, although I haven't really dived into how well I'm actually achieving that. Regardless, gensym is actually much slower than a dynamic dispatch, so this should speed up compilation if anything...

If we add enough @nospecialize statements everywhere, concrete typing probably shouldn't matter. (You don't have any reason other than compile performance to want that, right?)

Yes, compile performance is the only reason. Any general advice on using @nospecialize?

I'll submit a PR. Best approach is to analyze the number of specializations per method; that tells you how many times they've been compiled. Whole goal is to avoid recompilation.

Not as straightforward as I hoped, it may be a Julia bug. https://github.com/JuliaLang/julia/issues/35131


Broken VS IntelliSense for WinUI 2.x styles & controls

Describe the bug
Visual Studio's IntelliSense doesn't detect WinUI 2.x styles and thinks it doesn't exist. It also doesn't show them in the dropdown for selecting a style. It also doesn't recognize certain WinUI 2.x types and can't show them in the designer.
Steps to reproduce the bug

Open a UWP app project with WinUI 2.x installed.
Apply a style only present in WinUI 2.x (eg: DisplayTextBlockStyle) to a XAML control and notice the IntelliSense saying it couldn't resolve it.

Expected behavior
Visual Studio should be able to resolve WinUI 2.x styles and controls at design time for a better experience.
Screenshots

NuGet package version
Microsoft.UI.Xaml 2.7.0
Windows app type

[X] UWP
[ ] Win32

Device form factor
Desktop
Windows version
Windows 11

@jevansaks @evelynwu-msft and @MikeHillberg How can we fix this from WInui2?


when will babel-preset-babili be updated to npm?

current 0.0.9 can not support options.

We are working on mangler fixes and will be published mostly after #284

0.0.10 is out


readme updates

@microsoft-github-policy-service agree [company="Kwantum Edu"]

@microsoft-github-policy-service agree company="Kwantum Edu"


Best approach for upgrading a template?

Let's say someone upgrades to a newer version of a CLI of Sao, e.g. lad (see https://github.com/ladjs/lad) via npm install -g lad@latest.  They then want to upgrade their template.  What would be the best approach?  Just a git clone and then apply the diff between template directory and the user's project dir?

For an already generated it's hard to upgrade automatically since you may have changed many files 🤔

@egoist Maybe we do something like this https://react-native-community.github.io/upgrade-helper/?from=0.59.8&to=0.60.3? and https://facebook.github.io/react-native/docs/upgrading
Also https://github.com/react-native-community/cli/blob/48626dd239e01d9d060f0d47661013610a0dcd0a/packages/cli/src/commands/upgrade/upgrade.ts and https://github.com/react-native-community/cli/blob/48626dd239e01d9d060f0d47661013610a0dcd0a/packages/cli/src/commands/upgrade/tests/upgrade.test.ts

It would be incredible for sao to have a package (possibly one even built-in) that lets you do this by plugging the package into your CLI.

This would be the BEST feature for Sao by far compared to ANY other template/scaffolding too.

Also would gladly donate to you to help build something like this 😄

I found your Patreon, now a supporter.

Thanks, I'll take a look at the react-native solution, this is definitely a missing feature for every scaffolding tool.

Let me know!

Codemods would work well. JSCodeShift is a solid tool. Good example usage with jest.

Would be awesome to have this 🙌

I am awarding a $200 bug bounty for this issue.

I will create a website like https://react-native-community.github.io/upgrade-helper to show the diffs between two versions of a generator

@egoist Hey!  I also shared this with @shaunwarman - but I think having a CLI tool like this would be great:
https://github.com/willmendesneto/update-yeoman-generator/blob/9946691c89a70a5916b929c7c2f38b26a9536445/lib/run.js

Yes, a separate CLI tool like that is also planned.

Any update here @egoist ?

Checking in again @egoist , I should have bandwidth to dive in and help, but unsure if you have some ideas / todos for this new CLI tool


[auto_animated] Export LiveOptions in library

Describe the bug
LiveOptions has to be imported from `package:auto_animated/src/helpers/options.dart.
Expected behavior
Importing package:auto_animated/auto_animated.dart should make LiveOptions available.

Thanks, fix published in auto_animated v2.0.1


$ionicHistory.goBack() Does not work

Short description of the problem:
$ionicHistory.goBack() does not work
What behavior are you expecting?
$ionicHistory.goBack(); to go to previous page.
Other information: (e.g. stacktraces, related issues, suggestions how to fix, stackoverflow links, forum links, etc)
$ionicHistory.goBack() does work on a clean 1.3.0 project. And it also works in version 1.2.4. Just not when I update my previous project to 1.3.0 using ionic lib update.
link to other people having the same issue:
https://forum.ionicframework.com/t/ionichistory-goback-does-not-work-in-1-3-0/50247
Which Ionic Version? 1.x or 2.x
1.3.0
Run ionic info from terminal/cmd prompt: (paste output below)
Your system information:
Cordova CLI: 6.1.1
Gulp version: CLI version 3.9.0
Gulp local:
Ionic Version: 1.2.4
Ionic CLI Version: 1.7.14
Ionic App Lib Version: 0.7.0
OS: Distributor ID:	Ubuntu Description:	Ubuntu 14.04.4 LTS
Node Version: v5.0.0

Hi @babinc,
Can you figure out a way to recreate this?  This worksforme currently.  I have tried with both hardware back buttons, and just using $ionicHistory.goBack().  In both cases, it works as expected.
What is the context of your app, and when is it happening?  It is a standard navigation app, or does it use tabs?  I need more info so I can resolve.
Thanks,
Dan

This should be resolved now.  Please test this fix via the nightly build tomorrow and comment back if the issue continues.  The easiest way to test is to download the zip file and replace the contents of www/lib/ionic with the contents of the zip file.
Thanks for letting us know of this issue!
See the commit here.
Thanks,
Dan


Windows aren't reopened in the correct desktop (macOS)

VS Code Version: 1.90.2 (Universal)
OS Version: macOS 14.2.1 (23C71)

After restarting VS Code or macOS, VS Code reopens all its windows. Unfortunately their original desktops aren't preserved, so they are all reopened on a single desktop.
This should be possible to fix by implementing NSWindowRestoration

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.91.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!

What is this a duplicate of? I only found this issue for Windows, but that's not the same: https://github.com/microsoft/vscode/issues/146915