[FEATURE]: More explicit handling in QuickSort partition algorithm

Motivation
I've been reviewing the Quicksort partition implementation in this repository. Specifically, I'm focusing on the following segment of the code:
while (i < j) {
 while (array[++i] < pivot);
 while (array[--j] > pivot);

 if (i < j) {
    [array[i], array[j]] = [array[j], array[i]];
 }
}

In the scenario where the rightmost element is chosen as the pivot, and all other elements are greater than the pivot (e.g., [6, 5, 4, 3, 2, 1]), the code handles the out-of-bounds behavior as follows: array[-1] is undefined. When undefined is compared against a number, it is coerced into NaN, resulting in false for the comparison.
While this approach works and is quite clever, I believe it could be beneficial to make the handling of these cases more explicit. This would enhance the readability and maintainability of the code, making it easier for newcomers to understand and for the code to be adapted or modified in the future.
I suggest taking a more conventional approach, such as:
while (array[--j] > pivot) {
 if (j === left) break;
}

This change would make the algorithm's logic more straightforward and easier to follow, without relying on special JavaScript behavior.
Thank you for considering this request. I'm open to feedback and suggestions on how to further improve the code.
Examples
No response
Possible workarounds
No response

I agree that relying on the type coercion done by > here is hacky; it should be made explicit.
Why not do something like while (array[--j] > pivot && j !== left); though?


When the ajax functions was added, the tasks no longer appeared on the active studentpage! Bring it back!

A single include line had disappeared as the lecture-page was re-structured to fit the top-bar. Sentence re-introduced, task system should now work again.


[ionic2 bugs] Alert or ActionSheet will not fire every time in many tags in ios9. ( exclude )

https://www.youtube.com/watch?v=KPLgMzro7Y8&feature=youtu.be
When i bind an click event about alert or actionSheet on a . It will have some strange things happen:
First time i click, good result. the click event will be fired and alert/actionSheet will happen. but after fired it first time,it will have a big interval time to fire the click event again.(about 1.5-2 second).
But if you bind an click event about alert on . Every thing works fine and no problem. Every time the click is work and alert/acti
onSheet will work.
It seems that if you call an alert or actionSheet on a 's click event. It will block the click event on the same object about some times.
Let's see what happen:
https://www.youtube.com/watch?v=KPLgMzro7Y8&feature=youtu.be
Android 4.4.4 no this problem and everything works fine. But i try it on my iphone6 (IOS9) it will happen this issue.
I have try many tags have this problem(  include bind it in svg element );
Demo case:
<ion-navbar *navbar>
  <ion-title>Tab 1</ion-title>
</ion-navbar>

<ion-content padding class="page1">

<button secondary (click)="doClickButton()" >button click</button>
  <ion-card (click)="doClickCard()" >
    <ion-card-header class="LineTitle" >
      Card click
    </ion-card-header>
  </ion-card>

</ion-content>

    doClickButton() {
	let alert = Alert.create({
		title: 'Clicked On button',
		buttons: ['OK']
	});
	this.nav.present(alert);
}

doClickCard() {
	console.log("a");
	let alert = Alert.create({
		title: 'Clicked On card',
		buttons: ['OK']
	});
	this.nav.present(alert);
}

ion-card is not a button, so to remove the 350ms delay on iOS. However, for this reason we created a tappable attribute, so your html would look like:
<ion-card (click)="doClickCard()" tappable>

The good news is this should no longer be an issue with iOS 9.3, so as older versions phase out this will be a thing of the past. Please give that a shot and let me know if you're still having issues. Thanks

@adamdbradley
Thank you and sorry for the late reply.
I have try add  tappable tag but it seem not related to the 300ms delays.
When i use add bind click to console.log() something, it works and immediate console the string.
But  when you bind Actionsheet or alert in the click.
It will have not fire the event often!!!
And you can just have a real devices test in IOS9
Thanks

@adamdbradley
Sorry for the late reply and thanks you !  The problems fixed.


VPN working, but nothing using it.

Hello,
I have followed the guide and the linked opnsense guide from step 7, but none of my devices seem to be using the tunnel. I have even gone as far as to restore to a previous image and try again with the same result. Do you have any thoughts or guidance?

Does the PIA Gateway show as up and the monitoring is showing a rrt time?
Example

Show me a screenshot of your LAN rules, and highlight the one you believe should be working and isn't 😊

I'm not really sure which one is working. I'm wondering if my alias is wrong. When I hover over the RFC1918_Networks, it shows the subnets that the linked guide had input, <IP_ADDRESS>/16 is one of them. The subnet for my lan is <IP_ADDRESS>/24.

So when traffic hits the interface, it evaluates the rules top to bottom, so it's matching `Default Allow LAN to any rule", and using that to allow the traffic out of the default gateway.
That bottom PIA rule needs to become before that rule. and the top most PIA rule isn't required and can be deleted.

I have moved that rule to the top and applied the change and rebooted, but when I lookup the public ip of the machines on my network they still resolve to my non-vpn ip.

I assume those two ALIAS are correct?
WG_VPN_Hosts should contain for example;

<IP_ADDRESS>`

RFC918_Networks should contain the following;

<IP_ADDRESS>/8
<IP_ADDRESS>/12
<IP_ADDRESS>/16

If those are correct, what does your Outbound NAT look like?

That is probably where my mistake is. I have them both set to networks with a content of my subnet (<IP_ADDRESS>/24)

My outbound nat is:

Yes, .21, I think.

Actually, I think that fixing the RFC1918 alias fixed it. It is resolving to my pia now. THANK YOU!

Problem is now fixed.


fix npm start bug

When I run npm start in smart-home-provider/ folder, the
localhost:3000 will be 404, I modified the static files path to
path.join(__dirname, '<static files relative path>')

Based on the readme instructions you are supposed to run the file: node smart-home-provider-cloud.js isLocal

@Fleker Yes, you are right. But I think the script in package.json should work too.

If the script is not correct, then it should probably be updated instead of changing the existing instructions.


Allow nightly release custom versions for ZURG_VERSION

Don't prepend 'v' for zurg custom version nightly releases

@I-am-PUID-0


Weird visual artifact (triangle/caret) rendered in terminal after yarn install

Issue Type: Bug
Steps to Reproduce

Set the terminal.integrated.gpuAcceleration setting to auto, on, or canvas. The bug does not occur with GPU acceleration off.
Clone my repo, or create your own with:

yarn set version berry
yarn set version latest
yarn init
yarn add --dev rimraf

The choice of rimraf as a dependency is completely arbitrary. The important thing is that you have at least one dependency.

If this isn't your first time testing this, reset everything by killing and restarting the integrated terminal and then running yarn cache clean.
Run yarn to install packages.
Switch from the Light+ theme to the Dark+ theme (or vice versa). This step isn't truly necessary, but it makes the triangle artifact more obvious.

Actual behavior:
A visual artifact in the shape of a triangle/caret is displayed in the integrated terminal. It stays in the same position for the entire terminal session, regardless of what commands are run after yarn install. The color of the triangle will be white if you started in the Light+ theme, or black if you started in the Dark+ theme.
Look at the first "PS" after the yarn install completed:

Expected behavior:
There is no triangle artifact.
Additional Context

The bug does occur with all extensions disabled. (code --disable-extensions)
Resizing the integrated terminal causes the triangle to disappear.
Changing terminal.integrated.gpuAcceleration causes the triangle to disappear.
I am using PowerShell 7.1.4.
The issue does not occur when running in a standalone PowerShell window.
This is a super low priority issue, I just think it's kind of amusing and had some free time. 😆

VS Code version: Code 1.60.2 (7f6ab5485bbc008386c4386d08766667e155244e, 2021-09-22T12:00:31.514Z). Also tested with 1.61.0-insider (4fbe0344a0cedaf2a04edef728c9a3f27777cc6c).
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (8 x 3600)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.68GB (5.06GB free)

Process Argv
-n --crash-reporter-id 24f0b409-7147-40a8-84cc-a20f14042031

Screen Reader
no

VM
0%

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
vsccppwt:30364497
pythonvssor306:30344512
bridge0708:30335490
pygetstartedt2:30371810
dockerwalkthrucf:30370837
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30364666
pythonvspyt187:30373474
pydsgsc2:30361791
vsqsis300:30374797

If you see this again, could you run the new show texture atlas command and paste in the resulting image?

Let's close this out and reopen if it looks like a bug with more info


Define formal media type (MIME type) for Swagger Object

A media type of application/swagger+json has been suggested on the mailing list before. I would recommend formally declaring this as part of the spec.
RAML defines its media type as application/raml+yaml
API Blueprint defines its base media type as application/vnd.apiblueprint.ast plus similar ones for other serializations

For what it's worth, the White House open data policy is currently documenting application/swagger+json for metadata provided by federal agencies: https://project-open-data.cio.gov/v1.1/api/
If this should be changed, please flag it is an issue on https://github.com/project-open-data/project-open-data.github.io/issues

:+1:

I'm all for it and would like to go so far and suggest different mime-types for different encodings and Swagger versions
application/swagger-v20+json
application/swagger-v20+yaml
application/swagger-v12+json
application/swagger-v12+xml
(not really sure we need to add xml for 1.2 but it was in the spec as far as I can remember)
since Swagger 1.2 has separate files for resource listings and api declarations I suggest we make the api declaration implicit and have a separate mime-type for the resource listing
application/swagger-v12-resource-listing+json
application/swagger-v12-resource-listing+xml
or alternatively we make both the api declaration and resource listing explicit;
application/swagger-v12-resource-listing+json
application/swagger-v12-api-declaration+json
application/swagger-v12-resource-listing+xml
application/swagger-v12-api-declaration+xml
If we're aligned I can submit this to IANA... let me know your thoughts
/Ole

@olensmar Not really sure we need to separate resource listing and api declaration. Its implicit by definition that if its application/swagger-v12+json we're going to get a document that conforms to the swagger12 spec. likewise for swagger2 also. In the case of swagger 1.2 the protocol to access the resource listing to get to the api declarations is a shared understanding described by the spec.
As an aside, related to #708 would you be able to assist/ hand-hold so I could also register
application/swagger-v20+hal+json
I'm starting to experiment with a few ideas with swagger and hypermedia support. The thinking is that if we could combine HAL with swagger it would give a rich interactive experience. An on-demand swagger-ui if you will, similar to hal browser. I have very rough ideas that I hope to formalize soon. Initially trying to prototype it in spring using springfox.

@dilipkrish thanks! I'd love to talk about hypermedia support in swagger, it's getting asked for in every talk I've done on swagger over the last weeks. I personally think that using the extension mechanism is a good starting point; if we can agree on a set of extensions that add hypermedia-related constructs to a Swagger definition those can be used by related tools without having to change the spec itself - and if they gain a lot of traction we could discuss putting it in the next major revision of the spec.
Regarding the mime-type - I still think there are use-cases where it might be good to be able to differ between resource listings and api declarations - but those might be very application-specific so we can leave them out for now. In that case I suggest we just go with:
application/swagger-v20+json
application/swagger-v20+yaml
application/swagger-v12+json
application/swagger-v12+xml
what about also having
application/swagger+json
application/swagger+yaml
as aliases for the latest version of the spec? (2.0) Or is that some kind of anti-pattern that I'm not aware of?
/Ole

Is there any formal progress on a "application/swagger+json" media type. I'm working on generic client tooling right now, and the lack of a media type for swagger is a minor point of awkwardness there (eg can interact with other schema and hypermedia types without having to explicitly specify what type of media they should be interpreted as, but not so with swagger)

I think this is a very good idea to add in the next spec version

+1

+1

Is this worth the OpenAPI.Next Proposal tag, to ensure it gets consideration?

Done.

The lack of a registered Media Type for Open API resources is a hindrance so it would be great to get this resolved.
What ever Media Type name is chosen, it should be registered in the  IANA Media Types Registry.
Versioning information should not appear in the Media Type, the version information is present in the resource representation. The vast majority of Media Types in the IANA registry do not transport any version information. You don't want to have to go through the Media Type Registration process each time a new version is minted.
Note that the IANA Media Types registry is partitioned into namespaces, it won't be possible to register application/swagger+json, or application/~anything~+json, as they fall in the Standards Tree namespace, which requires a corresponding IETF (or other recognized standards body) specification.
Registration in the Vendor Tree should be fine, so I would recommend:
application/vnd.open-api+json for the JSON representation, and
application/vnd.open-api+yaml for the YAML representation.
Note that RFC 6839 Section 3.1 formalizes the +json suffix convention. There is no registered Media Type for YAML, and therefore no formalization of the +yaml suffix convention, both these issues may be an obstacle to registration of a Media Type for the YAML representation.

@darrelmiller I see RFC, IANA and vnd a lot here...chances are you have thoughts.

@jasonh-n-austin Just pinged someone to find out the right place to get some of the uncertainties ironed out.  In theory I don't think we have to be on the vnd tree and I believe recent specs have formalized the suffix issue, but I want to confirm before making a submission.

@darrelmiller :+1: Good stuff.

Asked the questions to the people who hold the keys to the registry  https://mailarchive.ietf.org/arch/msg/media-types/_ijxSwBDdS6MF-sECqhxN1jkXzs

Thanks @darrelmiller.  Did you manage to find "the form"?

I know where the submission form is :-).  I was hoping I could get a registration in the standards tree without having to submit a spec document to IETF.  However, I don't believe the Linux Foundation is considered a "Standards Development Organization" so, our choices are either live with the "vnd" or submit an IETF compliant version of the spec to them when we release new versions.  I did at least get confirmation that it could be "Informational" and therefore not require any IETF WG input/consensus.

@darrelmiller Happy to help with drafting the informational RFC if needed, have done some draft RFCs before. The other message I took from that email thread was the case for approving the RFCs for  application/openapi+json & application/openapi+yaml would be made stronger by going ahead and using those media types, did I interpret that correctly? Is there agreement within OpenAPI that those are the exact media types that should be registered?

+1 for registering these as the "latest version" media types.
+1 for also registering version-specific media types as proposed by @olensmar application/openapi-v20+json or applicatoin/openapi-3.0+json (have to check the naming rules for use of dot)

+1 for submitting OpenAPI as an IETF RFC as we want to base the JSON dialect of OData's Metadata Format on OpenAPI, so the OpenAPI specification would be a normative reference.

@cdivilly Thanks for the offer to help.  Regarding the deploy first register later, the challenge is if we do something informally, the worst thing that could happen is people start using different approaches.  e.g. with/without version number.  I'm currently just trying to gather information and get the opinions out in the open, so that when we do make a registration, all the opinions have been heard.
@ralfhandl Can you make your case for including the version?  I would prefer not to include the version and just encourage people who are writing OpenAPI parsers to handle the differences internally.
Yes, having OpenAPI as an RFC would definitely make it easier to reference from other RFCs.  It would be interesting to investigate what it would take to automate the creation of a mirror spec.  The spec is already in markdown, so perhaps it could just be inserted into a kramdown-rfc2629 template.

@darrelmiller Assuming that OpenAPI 3.0 isn't the end of the road we'll need a mechanism for version negotiation. This could be a separate set of headers, or it could be rolled into the media type, i.e. be part of the content negotiation:
Accept: application/openapi-v3_1+json, application/openapi-v3_0+json;q=0.2

or with separate headers
Accept: application/openapi+json
OpenAPI-MinVersion: 3.0
OpenAPI-MaxVersion: 3.1

Making it part of the media type is two request headers less, and in addition I can give a weight to the acceptable versions.

@ralfhandl That is not best practice. HTML for example uses text/html since ages without a version number.

@akuckartz I'd prefer if we don't try and resolve this by appealing to "best practices".  The best solution to a particular problem is usually fairly context sensitive and there are too many varying opinions about what are the best practices.
However, the text/html media type is a good example of a media type that has gone through numerous versions and has kept the same media type identifier.  I would prefer if OpenAPI tried to follow this model.
@ralfhandl Having version specific media types isn't the only way that we can deal with future versions of the OpenAPI spec.  The previous specification had the foresight to include version identifiers within the document so a parser can fairly easily identify which specification version is applicable.
It is true that without a version specific media type intermediaries will need to parse the body, but I am struggling to think of scenarios where they would want to differentiate.  Perhaps you are aware of some?  I would think it is more likely that intermediaries would prefer not to have to be updated when a new OpenApi version is released and they can identify all versions of the spec as an "OpenAPI" document.
The one scenario that is more challenging with just a single media type for all versions, is when a client wishes a server would return it a down-revision instance of the specification.  The question that comes to mind, is it really better to conneg for that, or should the OpenApi3 and OpenApi4 document simply be exposed as two different URLs?  Considering spec documents are fairly static documents, being able to cache them is handy and the support for using vary to cache multiple variants based on media type is quite poor, I think having separate URLs might be wise.
Are there other scenarios I am not considering where version specific media types are useful?

As an example, the TWINTIP API crawler currently expects just one API definition file referred from well-known URI (with its format specified in a type attribute). Though there is a feature request for allowing multiple ones, and then it might also be possible to mention different formats of the same specification there, so this is not really an argument for or against having different formats at the same or at different URIs.

@ralfhandl Embedding version information in the media type would require a new media-type registration
on each spec revision. In theory the version information could be transported as a media type parameter (like the charset parameter for text media types), but I'm not sure how well that would be supported, it's not something I've seen in the wild (I know I've written code that would fail to handle a parameterized media type in an Accept header correctly). So I wouldn't encourage this approach.
Instead of the client trying to negotiate a representation, how about if the server tells the client about alternative representations. I think this is something that is probably needed anyways, for example to point to the Open API YAML representation from the JSON representation and vice versa. Something like the links element from JSON Hyper Schema, e.g.:
swagger: '4.0'
links:
  - {rel: alternate, spec-version: 3.0 href: "/open-api/3.0/myapi.yaml, mediaType: "application/openapi+yaml"}
  - {rel: alternate, spec-version: 4.0 href: "/open-api/4.0/myapi.json, mediaType: "application/openapi+json"}

info:
  title: My API

A way to discriminate between Open API representation versions is needed for the hyperlinks, I'm not sure of the best way to represent this (again it could be a media type parameter), as a strawman I've minted a new attribute: spec-version to represent this value.

With this approach it is always apparent what older spec versions a server supports, versus the negotiation approach, which requires the client constructing a more complicated request to find out if the server supports the representation it requires.

@darrelmiller My goal is using OpenAPI as an alternative standard format for OData Metadata Documents, hence my desire for an IETF RFC for the OpenAPI Specification.
The metadata document of an OData service defines and describes the data structures and resource paths of that service, which OpenAPI also does, so this seems to be a good fit.
The metadata document is part of the service and resides at <service-root>/$metadata. It may be a static resource, but typically it is dynamically derived from the underlying API, and it is supposed to support content negotiation and language negotiation via the Accept and Accept-Language headers.
OData defines protocol-version negotiation, so a client can specify a range of acceptable OData versions, and we could tie the OpenAPI version to the OData version. But given that OData and OpenAPI are independent standards and will probably evolve at different speeds this feels undesirable.
@cdivilly I very much like the idea of having a links section pointing to alternate representations of the OpenAPI document. This would also be the natural place for a rel: latest-version that would allow an API advertising its successor.

@ralfhandl That's quite a challenging goal you have set for yourself there.  I would have thought it easier to just link to an OpenAPI document from the OData metadata rather than trying to replace the entire thing.  But that's another matter and I don't want to derail this thread.
I am reluctant to support versioning the Open API media types just because OData chose to try and standardize a resource identifier ($metadata) despite the guidance against doing that. This is the same situation that @ePaul mentions about the use of a .well-known identifier to point to OpenAPI descriptions.
However, it is important to realize that well-known URIs were formalized to resolve only a small subset of situations where all other options were not possible.

well-known URIs are not intended
for general information retrieval or establishment of large URI
namespaces on the Web.  Rather, they are designed to facilitate
discovery of information on a site when it isn't practical to use
other mechanisms; for example, when discovering policy that needs to
be evaluated before a resource is accessed, or when using multiple
round-trips is judged detrimental to performance
From https://tools.ietf.org/html/rfc5785

There are much better ways for API consumers to discover description documents.  For example using http://apisjson.org/
The parameterization of the version in the media type @cdivilly is certainly a way to avoid the re-registration problem, but like him I haven't seen very much use of this in the wild.  We should consider it and perhaps it is something that someone on the IETF mailing list might weigh in on.  Maybe if we made version parameter optional to allow those who want to explicitly set it do so and those who don't can just ignore it.

@cdivilly Please use type, not mediaType, as per RFC 4287 <IP_ADDRESS> The "type" Attribute.

Off topic: @darrelmiller nice to meet someone who knows OData even longer than I do :-) We could definitely link to an OpenAPI document from XML $metadata, but we also want JSON $metadata. JSON $metadata would need something very close to definitions and paths, so why reinvent the wheel?
On topic: both a format parameter or a links section for related documents - including but not limited to alternative OpenAPI documents for different versions of the specification - are viable solutions, so I'd be fine with application/openapi+json without version information. The links section approach would be an example of Reactive Negotiation, whereas the format parameter would be Proactive Negotiation.

@DavidBiesack yeah that's a peculiarity of JSON Hyper Schema, not something I'm inventing, that tripped me up first time I saw that too. The mediaType field is specified by JSON Hyper Schema (which I was using as a strawman above). I guess they use mediaType instead of type, because the type keyword already has significance for JSON Schema.

What is the status of this ticket? What media type should we use for 2.0 which will be around for a while? I know the type may change for OpenAPI 3.0, but I'd like some resolution for 2.0.

@DavidBiesack The status is "I'm a lazy ass" and I need to get on this.  My preference at this point is to register application/openapi+json and define an optional parameter called version.  So if you choose you can use application/openapi+json;version=2.0 to be explicit about the version.
If that registration works out, then we can attempt to register a +yaml version.  This will be a bit more tricky because we need to do some yaml related hoop jumping before that can go ahead.

One issue I have with application/openapi+json is that the 2.0 spec predates Open API -- it was not published as a product of the Open API Initiative and OAI/TDC process. I think application/openapi+json is fine for 3.0, but a perhaps misnomer for 2.0. Is there a reason to rule out application/swagger+json or application/swagger-v20+json (BTW, I do see the irony in me saying Open API should not call Swagger 2.0 "openapi" while in the same paragraph asking Open API to define a media type for Swagger 2.0.)

@DavidBiesack since swagger 2.0 is the OpenAPI spec as of now, it will always be legal to refer to it as the OpenAPI spec version 2.0.  So application/openapi+json;version=2.0 should cover the current 2.0 version, and be accurate.

To summarize, the proposal is to use application/openapi+json;version=3.0 where the version is an optional parameter.

@webron will put this in a PR into the spec definition, and @darrelmiller will submit the IANA form.

@darrelmiller What is the status of the IANA registration? When will we know it is safe to use the media type without worrying about changes?

Hey @dilipkrish I'm not @darrelmiller but I believe he can't register it until we release the spec.  So it'll happen when released.

Technically, we could register it based on the V2 spec.  This is simply procrastination on my part.

No hurry... prompted by requests to support rendering the spec in yaml and I'd rather use the media type as a negotiating instrument than something in the url or a file extension like we usually do.

/me pokes 👉 👉 👉 @darrelmiller
Stop procrastinating, friend. I need this, k?! 😁
❤,
🎩

@webron @darrelmiller @fehguy just checking in on this, with the 3.0 spec now released, is there any update on the IANA registration and the formal definition of the type?
My understanding from this comment was that application/openapi+json;version=#.# would be the proposed type to use, is that still the case?

Yes, that's still the case.  I still haven't done the registration.  I still need to do it.

bump @darrelmiller

So, in light of recent developments, I am bringing this issue back to life.  There are ongoing discussions in the OpenAPI Initiative about possibly increasing the scope of the OAI and it may arise that other specifications will fall under the OAI umbrella.
I would like to propose an alternate media type identifier that would remove some of the road blocks that were previously preventing this registration from happening and also accommodate the possibility of identifying other related specifications in a consistent manner.
I suggest that we register:
application/vnd.oai.openapi

with an optional version parameter.  By moving our registration to the vendor subtree, the process becomes as simple as filling a web form with some fields.  To be in the standards tree we would need to go through IETF expert review and have a stable copy of the the specification registered with a recognized standards organization.
This identifier makes the naming process easier for future specs managed by the OAI.
Finally, I am proposing that we drop the +json suffix.  We will not be able to have a properly registered +yaml suffix because yaml is not an IANA registered media type.  I would prefer to have the simpler identifier than only support just one.

application/vnd.oai.openapi+json (JSON only variant)
application/vnd.oai.openapi (YAML/JSON variant)
Optional version parameter:
 application/vnd.oai.openapi;version=2.0

Hmm, I'm not understanding how application/vnd.oai.openapi makes it easier to have other specs under the OAI umbrella. It seems, if anything, it would make it harder, as it would attach "OpenAPI" to one specific spec.

@usarid Well assuming it was decided to adopt asyncapi as is, then we could registerapplication/vnd.oai.asyncapi
If we decided to adopt a variant of apis.json as a discovery document then it could become application/vnd.oai.apisjson
My perspective is that OpenAPI already is associated to one spec.  OAI is the organization that could manage other specs.

I don’t think people will understand the subtlety that “OpenAPI” is just one of the specs managed by the OAI (OpenAPI Initiative). But maybe we should first progress the scope discussion and then get back to this.

Heya. Good work on progressing this.
Just to clarify on "Finally, I am proposing that we drop the +json suffix." is that a typo that meant to say "Finally, I am proposing that we drop the +yaml suffix." (Which the later comment suggests?)

@tomchristie My initial plan was to drop both, with the argument that if I can't support one, then let's not confuse the issue by only supporting +JSON.  But on the TSC call @MikeRalphson suggested letting the one without the suffix be YAML by default.  Which is extra convenient because JSON is actually valid YAML also.  Which leaves us in the awesome position of tools that support YAML or JSON get the clean  suffixless version and JSON only tools need the +json.  It's like having your cake and eating it too.

Great thanks @darrelmiller - that makes sense. 😄

@darrelmiller is this the final with an optional variant of version?  Sorry, the above thread does not clearly tell me what is the final.
application/vnd.oai.openapi (YAML variant)
application/vnd.oai.openapi+json (JSON only variant)

@pratikpparikh No final decision has been made.  The two options you mention were my latest suggestion.  https://www.asyncapi.com is another specification that is very similar to OAS but for message based protocols.  There is conversations going on about possibly bringing that specification under the OAI organization.

@usarid I think that regardless of how we end up incorporating AsyncAPI features into the OAI, whether it is with a distinct spec or just extensions to the existing specification, I still think there is value in calling out the fact that OpenAPI is part of the OAI.  It fits nicely into the vendor extension model and leaves the possibility of extensions in the future even if we don't use it.
Personally, I think I have dragged this issue out long enough and would really like to see some closure here.  If eventually we decide to propose OpenAPI as a full on IETF standard we can always register a new standards track media type at a later date.

@OAI/tsc APPROVED 🎉

Please publish the final approved media types on https://github.com/OAI/OpenAPI-Specification (no need to update the published specification documents, but in the future I would like to see it in the spec itself).
Also, please clarify if we should use ;version=3.0 for 3.0.*, as implied by https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#versions

@darrelmiller When should we expect these media types to appear in the registry at https://www.iana.org/assignments/media-types/media-types.xhtml?

Please consider resolving/closing #110 for OAS 3.0.2,  with clarification on exactly what the TSC approved, and what ;version= values/mapping are allowed

Hi folks, what's the current state of this issue? I see that the TSC approved the usage of application/vnd.oai.openapi for YAML based OpenAPI specs, but there's no mention of this in approved specifications.

I'm willing to file an I-D for registering those media-types.
Just let me know.
@darrelmiller @MikeRalphson

Considering these:
  application/openapi
  application/openapi+json

Optional version parameters:
  application/openapi;version=3

Please provide thumbs up on this suggestion?

@darrelmiller just a clarification:
is that correct?

application/openapi -> yaml

@ioggstream I believe that's the intention (that application/openapi is the YAML format), but as YAML is (to all practical purposes) a superset of JSON, you will be able to use application/openapi for JSON formatted OAS documents if you wish. Use application/openapi+json to indicate strict JSON only (which might affect performance in some cases).

Use application/openapi+json to indicate strict JSON only (which might affect performance in some cases).

Clear, upvoted. Let's register that! If you need me to write an I-D please let me know.

I'm probably entering this discussion far too late, but I think the idea of registering specific media types for openapi documents is the wrong way to go. Media types are about syntax (i. e. yaml oder json), the internal structur of the data refers more to what a current initiative in W3C calls "profiles". (Disclaimer: I'm one of the editors of that draft).
The idea is that in order to avoid combinatorial explosion of media types (one for each document syntax), we separate the document syntax from the document structure, so that content adhering to the same document structure (i. e. the how the information in the document is organised) can be expressed using several media types (i. e. information about document syntax).
The gist of the proposal is that description(s) of document structure get a URI and when issuing the http request, an agent can use an Accept-Profile header to negotiate for documents conforming to a specific profile. The server can then return a conforming document using any of the media types listed in the Accept header (or if it cannot serve any of those media types, return the content using another media type and include a list of alternate resources using a Link header).
In the case of OpenAPI, this would mean that the media type for API descriptions would be the usual application/json or application/yaml (if that's the correct one; I couldn't find it in the IANA media type registry). In addition to that, the server would use a Link header with rel=profile (as in @dret 's RFC 6906) to point to a URI defining the document structure, from where an agent can access additional information such as a JSON schema that can be used for validation.
As said, this might be too late and the train has probably already left the station.
Best,
Lars

@larsgsvensson thanks for chiming in.
The IANA registry contains several examples of application/this+json and application/this+xml or application/that+json and application/that+xml representing the data type + format. Sounds like you saying OpenAPI should not follow this - that this is a deprecated practice.
https://w3c.github.io/dx-connegp/connegp/#related-http describes using a ;profile= media type parameter, and
https://tools.ietf.org/html/draft-wilde-profile-link-04 also says

For newly defined
media types that may be used with profiles, it is therefore
recommended that they SHOULD define a media type parameter called
"profile", and specify that this media type parameter follows the
semantics of a profile as laid out in this document.

So would using application/json;profile=<some-openapi-2.0-profile-uri> and application/json;profile=<some-openapi-3.0-profile-url>, (and corresponding application/yaml;profile=... for YAML) for an Accept header satisfy this SHOULD recommendation, and be less complicated compared to using both an Accept header and an Accept-Profile header in requests? It looks like both of these citations still use the profile link in the response headers, vs. a ;profile= parameter in the response Content-Type.
Unfortunately as you note, there is no media type (yet) for YAML (see https://stackoverflow.com/questions/332129/yaml-mime-type/38000954#38000954 - yuch!). Personally, I'd prefer to see application/yaml over text/vnd.yaml.

@larsgsvensson defining a media type allows for other important features like defining media type parameters (forbidden to application/json, fragment syntax (JSON Pointer fragments are explicitly forbidden from use with application/json, and base URI + URI-reference resolution rules (absent from application/json as it has no URI-specific syntax or behavior).
While many of these restrictions on application/json are ignored in the wild, it is proper to ensure that strictly legal options are available for applications wanting to ensure strict conformance with specifications.  A profile does not accomplish this.

@DavidBiesack wrote:

The IANA registry contains several examples of application/this+json and application/this+xml or application/that+json and application/that+xml representing the data type + format. Sounds like you saying OpenAPI should not follow this - that this is a deprecated practice.

No, it's not formally deprecated. Some consider it a good practice, some a bad one. The point is that it conflates syntax and semantics and that there will be a proliferation of media types since you need a separate media type for every combination of data type and format. If you create a profile describing the semantics of your data type you can re-use existing media types.

So would using application/json;profile=<some-openapi-2.0-profile-uri> and application/json;profile=<some-openapi-3.0-profile-url>, (and corresponding application/yaml;profile=... for YAML) for an Accept header satisfy this SHOULD recommendation, and be less complicated compared to using both an Accept header and an Accept-Profile header in requests? It looks like both of these citations still use the profile link in the response headers, vs. a ;profile= parameter in the response Content-Type.

At a joint meeting with the JSON-LD WG, we discussed the use of ;profile= in Accept and Content-Type headers. The resolution was to suggest that the ;profile= in those headers is restricted to media type-specific profiles, such as http://www.w3.org/ns/json-ld#expanded to signal or request the use of the expanded document form in JSON-LD. In order to negotiate for profiled resource representations the Accept-Profile and Link headers should be used.

Unfortunately as you note, there is no media type (yet) for YAML (see https://stackoverflow.com/questions/332129/yaml-mime-type/38000954#38000954 - yuch!). Personally, I'd prefer to see application/yaml over text/vnd.yaml.

Funny, I would have thought that YAML would be widely supported enough... That of course makes it harder to decide what media type to use for OpenAPI documents in YAML syntax. You could either register application/openapi which doesn't reveal to clients that it is YAML, or you could wait for a YAML registration, register the +yaml suffix and then register application/openapi+yaml which would be more consistent with application/openapi+json. Or you could go for profiles and decide to publish documents at e. g. https://openapis.org/profiles/oas/3.0.3 that would contain links to human- and machine-readable documentation, includin e. g. a JSON schema that can be used for validation. There is a suggestion for how to link those things together to create a profile.

@handrews wrote:

defining a media type allows for other important features like defining media type parameters (forbidden to application/json, fragment syntax (JSON Pointer fragments are explicitly forbidden from use with application/json, and base URI + URI-reference resolution rules (absent from application/json as it has no URI-specific syntax or behavior).

Fair enough. Just so that I can follow your line of thought: How would you use those features when serving openapi documents?

While many of these restrictions on application/json are ignored in the wild, it is proper to ensure that strictly legal options are available for applications wanting to ensure strict conformance with specifications. A profile does not accomplish this.

If the profile URI would point to a set of documents where it would be easy to find things like JSON schemas or other validation aids, would that solve the problem for applications wanting to ensure strict conformance with specifications?

@DavidBiesack OK so your version of "profile" is separate from the media type parameter profile?
JSON Schema adds the application/schema-instance media type specifically so we could use a profile= or schema= media type parameter legally (and use JSON Pointers for fragments legally).  Several drafts ago we were using profile= but @dret objected so we switched to schema=, although @dret seems to have since given up trying to enforce that.
At this point idk what JSON Schema will do in the next draft (the one that will align with OAS 3.1 final) but I'm hoping that the people who keep disagreeing with each other will work it out because it's frustrating to be criticized for every possible decision by different people who are each trying to advocate for or discourage the use of their own projects.  I tried to get around it by coming up with our own thing, but people don't like that either, so I've more or less given up on the topic.

Funny, I would have thought that YAML would be widely supported enough.

No, it's been effectively a running joke for years that it will never get a proper media type, and it's annoying AF.  This is part of why OpenAPI declared their own media type, with an optional +json variant if you want to restrict the underlying syntax to JSON.

If the profile URI would point to a set of documents where it would be easy to find things like JSON schemas or other validation aids, would that solve the problem for applications wanting to ensure strict conformance with specifications?

@Relequestual @awwright @philsturgeon here's something to consider for the next JSON Schema draft I guess.

hello all.
On 2020-08-28 18:11, Henry Andrews wrote:

JSON Schema adds the |application/schema-instance| media type
specifically so we could use a |profile=| or |schema=| media type
parameter legally (and use JSON Pointers for fragments legally). Several
drafts ago we were using |profile=| but @dret objected
https://github.com/json-schema-org/json-schema-spec/issues/222#issuecomment-272750411
so we switched to |schema=|, although @dret https://github.com/dret
seems to have since given up trying to enforce that
https://github.com/json-schema-org/json-schema-spec/issues/833#issuecomment-590588506.

i cannot "enforce" everything. i simply have tried to explain to people
that a profile is not what they think it is when they are referring to
the RFC and actually talk about applying schemas to data models.
but yes, i have given up on this one. and i don't "own" the concept of a
profile, i simply had something specific in mind when i wrote the RFC
and that was different from what some people apparently want it to be.
such is life. time to move on. keep up the good fight, henry!
--
erik wilde |<EMAIL_ADDRESS>|
| http://dret.net/netdret    |
| http://twitter.com/dret    |

@dret I'm sorry that this keeps coming up, I think it's more that we're looking for consensus from the broader community, and I saw you disagree that a schema can be a profile, but I don't understand why. I would like to understand why, though.
I'm not sure about OpenAPI, but at least as far as JSON Schema defines it, a schema seems like a kind of profile:

a profile can be described as additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics.

✅ JSON Schema adds constraints to documents, and allows additional information to be read out of a JSON document; but it does not alter the JSON semantics.

A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation.

✅ e.g. an intermediate HTTP node (that does not understand profiles or JSON Schema) could add or remove whitespace without affecting a JSON Schema aware processor.

Profiles can be combined, meaning that a single resource representation can conform to zero or any number of profiles.

✅  Multiple JSON Schema documents may be applied, forming a logical intersection

Profiles are identified by URI.

✅  JSON Schemas are identified by URI

However ... the URI in this case only serves as an identifier

✅  JSON Schemas are not (necessarily) available over the network, and most applications expected to work without ever dereferencing a profile URI (unlike a DTD).

Thus, clients SHOULD treat profile URIs as identifiers and not as links, but profiles MAY be defined in a way that the URIs do identify retrievable profile description and thus can be accessed by clients by dereferencing the profile URI.

✅  JSON Schema does permit this, but downloadable representations are retrieved by following the "describedBy" link relation.

For profiles intended for use in environments where clients may encounter unknown profile URIs, profile maintainers SHOULD consider to make the profile URI dereferencable and provide useful documentation at that URI.

✅  We suggest doing this for the benefit of human debugging
If any of this doesn't seem correct, I'm very curious to hear your take, @dret.
@larsgsvensson wrote:

If the profile URI would point to a set of documents

I think this is the only issue here, if you mean something that can be downloaded, then another link relation would be appropriate.

On 2020-08-30 02:11, Austin Wright wrote:

I'm not sure about OpenAPI, but at least as far as JSON Schema defines
it, a schema seems like a kind of profile:

a bit of history: RFC 6906 is based on "profile" as used in the HTML
spec (it's deprecated by now, so linking to good old HTML4):
https://www.w3.org/TR/html40/struct/global.html#profiles
you can simply use this concept to understand what RFC 6906 is defining.
HTML is not a profile of SGML/XML. but you can use profiles to indicate
that your HTML is based on a certain way of using HTML. you can still
understand HTML as HTML even when you're not knowing the profile.
or to give a more real-life example:

a letter is something written on paper. a letter is a way of using
paper and it's defining a new layer of meaning. a letter isn't paper,
it's a way of using paper.

a "profile of paper" would be something like square paper: it's still
just paper, but with an additional constraint.

a "profile of a letter" would be an invitation letter: it's still just
a letter, but one with additional constraints.

that's really all i can say. if you think that a letter is paper, then
in my mind you're mixing categories, but you're of course free to do it.
--
erik wilde |<EMAIL_ADDRESS>|
| http://dret.net/netdret    |
| http://twitter.com/dret    |

@dret I don't understand how @awwright would be arguing that *a letter is paper*.  He provided a very clear breakdown of how he thinks JSON Schema meets each condition in the specification.
Could you please let us know which of his points is incorrect?  From my perspective, square paper is a subset of paper.  Given a schema language for paper dimensions it could be expressed as something like "xyRatio": "1:1".  There are endless possible sizes and ratios of paper, but this constrains the set to those where the X and Y dimensions are the same.
A JSON Schema similarly defines the subset of JSON documents that are acceptable.  The schema identifier may in practice be overloaded to indicate further semantics (e.g. this is a "letter"), but that is not part of the JSON Schema specification, and other link relation types are more appropriate for that.
In an API, I would not use a schema to indicate that a document is a letter (or a car, or a planet, or anything else).  Because the schema describes the representation syntax, not the semantic usage.  The semantic usage should be stable across the lifetime of the API.  Some uses may or may not be implemented at different times, but they are still semantically valid.  However, the syntax is expected to fluctuate across time.  Ideally it wouldn't but we all know that's not how it works.
So I read your explanation and @awwright's detailed examination of the requirements and cannot see a contradiction.  Could you please point it out in plain terms, using @awwright's example?

On 2020-08-31 20:37, Henry Andrews wrote:

Could you please let us know which of his points is incorrect? From my
perspective, square paper is a subset of paper. Given a schema language
for paper dimensions it could be expressed as something like |"xyRatio":
"1:1"|. There are endless possible sizes and ratios of paper, but this
constrains the set to those where the X and Y dimensions are the same.

yes, you can implement a profile using a schema language. but we're not
arguing over implementations here but over what the two terms mean (the
concept of a profile and the concept of a schema).
all i can say is that in my experience in a variety of fields, people
use these terms for different concepts. a schema establishes a new
interpretation; a profile augments an interpretation. think along the
lines of HTML (a schema) and the good old STRICT and LOOSE profiles of
it (two ways to constrain the HTML schema).
clearly you want to use these terms in a different way, and that's your
right. i happen to think that this is not very helpful, but that's just
me having a different opinion.
but we're getting into a wittgenstein loop here. if you want to use the
term "profile" the way you want to use it, then this is what it means
for you. i cannot point you to a definition that categorically disallows
your use. all i can do is say that this is not how i use it, how i see
it being used, and that this is not what was intended in the RFC.
--
erik wilde |<EMAIL_ADDRESS>|
| http://dret.net/netdret    |
| http://twitter.com/dret    |

HTML is not a profile of SGML/XML

Besides the fact HTML is a separate media type, is there any reason this should be the case? An XML processor can read an application/xhtml+xml document without any knowledge of what HTML is.
It seems the issue is XML semantics are so generic, there's not much else you can do with it.
But suppose I know the XML document is HTML, then there's more I can do with it.
And suppose I know the HTML document is hCard, or RDFa. Then there's even more I can do with it. Being able to express this seems to be the primary benefit of profiles.

think along the lines of HTML (a schema) and the good old STRICT and LOOSE profiles of it (two ways to constrain the HTML schema).

So you consider a DTD to be a kind of profile? Isn't a DTD a kind of schema?

clearly you want to use these terms in a different way, and that's your
right. i happen to think that this is not very helpful, but that's just
me having a different opinion.

@dret, i'm pretty distressed by this accusation.  Several years ago, we stopped using profile specifically because you asked us not to, on the grounds that it was not appropriate.  We have not started using it again.  It's demonstrably clear and documented in GitHub that we have, in fact, gone out of our way to respect your views of what this means.
In the intervening years, other things have happened with "profile", and you yourself have indicated some sort of shift in views (as noted and linked to above).  @awwright raised the idea that maybe given how things have changed, we should check in and align with the overall community meaning of "profile", whatever that happens to be now.
All we want is to be aligned with the common accepted usage.  We don't want to be a weird outlier to an established pattern.  We don't want to be that one project abusing an otherwise well-defined term, and we don't want to be that one project that re-invented the wheel (e.g. by replacing "profile" with "schema" for both media type parameters and link relation types, if it turns out that "profile" is the industry-wide consensus.  Which we are not assuming).
I am bothered that you are ascribing ill will to us here.

yes, you can implement a profile using a schema language. but we're not
arguing over implementations here but over what the two terms mean (the
concept of a profile and the concept of a schema).

That's not what we asked, and we're not trying to argue with you.  We're trying to understand, but instead of giving a clear answer in terms of the concrete example, you criticize us and give oblique arguments that don't clearly relate to what we need to understand.
@awwright and I are both trying our best to figure this out and we cannot.  There is a simple question on the table.  You should be able to tell us which of those seven points is wrong.  Or if it's not outright wrong (is that what you mean by "yes you can implement a schema..."?), then clearly something is at least bothering you about at least one of those seven point.
Which point is it, and what is the problem?
Don't point to other media types or create new examples.  There's a seven-point attempt to meet your own definition.  Where did we go wrong?

On 2020-09-01 22:14, Austin Wright wrote:

think along the lines of HTML (a schema) and the good old STRICT and
LOOSE profiles of it (two ways to constrain the HTML schema).

So you consider a DTD to be a kind of profile? Isn't a DTD a kind of schema?

we're definitely going in circles by now.
a DTD is tech. schemas and profiles are concepts. most people probably
would put DTD in the schema bucket, but as i said, you can implement
profiles in many ways, including a DTD.
if that helps you: HTML is a model that can be (and in fact has been,
look at HTML and XHTML) based on different foundations. for somebody
just interested in HTML semantics, that actually doesn't matter, it's
HTML semantics in both cases. because all you do is operate at the
semantic level of HTML.
profiles do not establish this new level. they constrain the existing
level. i still need to understand HTML in order to understand a profile
of HTML. i do not need to understand SGML in order to understand HTML.
really, i have no idea how to explain this any better. and it doesn't
seem to me like we're making any progress here.
--
erik wilde |<EMAIL_ADDRESS>|
| http://dret.net/netdret    |
| http://twitter.com/dret    |

On 2020-09-01 23:35, Henry Andrews wrote:

All we /want/ is to be aligned with the common accepted usage. We
don't want to be a weird outlier to an established pattern. We don't
want to be that one project abusing an otherwise well-defined term,
/and/ we don't want to be that one project that re-invented the wheel
(e.g. by replacing "profile" with "schema" for both media type
parameters and link relation types, if it turns out that "profile" is
the industry-wide consensus. Which we are not assuming).

i am not the arbiter of what common accepted usage is, and it probably
very much differs depending on the community. if you talk to people with
a more XMLish background you will find rather different ideas than you
would find in a sample with a more RDFish slant.
all i can do is tell you what my view of the matter is, and i think
that really hasn't changed much over the years. but to say it one last
time: i have no control over how people use terminology or specs, and i
have no special say in this either. concepts are fuzzy, people have
opinions and preferences, and you may have to simply accept that.

Why can't you just answer the question?

@dret this is maddening.  Just tell use 1, 2, 3, 4, 5, 6, 7 which point(s) are wrong?

Ok, I gather that it's entirely possible to use a JSON Schema to define profiles of an application/json document. It might be the case a JSON Schema isn't necessarily a profile, but it can certainly be the case.
Before we get too far off topic, I think the question becomes, can we use profiles to distinguish version? If a profile is required to correctly interpret an OpenAPI media type, we don't gain anything over just using application/json with a profile.

@dret

concepts are fuzzy, people have opinions and preferences, and you may have to simply accept that.

Why do you think we don't?  I'm not asking you for a certificate of compliance to wave at other people.  I'm just asking, in your own personal opinion, which of the seven points is incorrect?  You have indicated that you do not agree with our interpretation, therefore one of those steps must be a problem in your own opinion, which we promise not to use to bludgeon anyone else or whatever it is you think we're doing.  I am begging you to tell us which one.

Is this effectively resolved by https://datatracker.ietf.org/doc/html/draft-polli-rest-api-mediatypes?

See https://datatracker.ietf.org/doc/draft-ietf-httpapi-rest-api-mediatypes/

Is this dead?

On 2023-09-20 09:06, Michal Landsman wrote:

Is this dead?

hopefully not!

Dear all, the work on this is ongoing. Yet, laying down something meaningful is not easy as it seems.
People interested in contributing to this issue can spend some time reading and providing feedback here https://github.com/ietf-wg-httpapi/mediatypes/labels/rest-api
Have a nice day,
R:

As @ioggstream noted above, this work is going on at https://github.com/ietf-wg-httpapi/mediatypes and should be tracked there.  I'm going to close this out to reduce clutter here.


Setting to warn if using assign (=) instead of expression (:=)

Hey, I love to see a new ahk extension on vs code. I've tried all of them, but nobody has a feature that I'm really looking for. I want something that highlights a line that uses equals to assign a variable instead of colon equals, since I've had many issues where I had bugs related to forgetting the colon and expecting it to use expression syntax. The "warning" could be anything as long as it is noticeable. I'm not sure what options are available to extensions. To be clear, this is what I'm looking for:
Warned Line:
Message = "Errors and warnings"

Allowed Line:
Message := "Errors and warnings"

It'd probably be good to have this be a feature that defaults to off since I'm pretty sure most people don't care/like to use equals.
Thanks,
B0sh

Can the different coloration of the assignment and equality operator help you instead of the warning message?

👨🔧 Resolved in new version


dcterms:creator or created_by?

@matentzn
This is related to HP question, but I am seeing the results in MAXO.
I automatically loaded up with the OBO annotators plugin. I think I had it on my last machine, too, BUT all the created by are http://www.geneontology.org/formats/oboInOwl#created_by vs.  this  version set up, which is http://purl.org/dc/terms/creator.
should I change all to dcterms:creator? (I assume, yes, in a text editor, but I wanted to confirm).
https://github.com/obophenotype/human-phenotype-ontology/issues/9721

We should be using dcterms:creator or dcterms:contributor all the way, no more http://www.geneontology.org/formats/oboInOwl#created_by!

@matentzn
What should I do about DOSDP files? Currently, 'created_by: oio:created_by'
Is there an equivalent one for dcterms:creator? Also, where would I look?

I would try to simply replace created_by: oio:created_by https://github.com/monarch-initiative/MAxO/blob/master/src/patterns/dosdp-patterns/avoidance_of_food_intake.yaml#L20 with created_by: dcterms:creator?

Well, sure, but everytime I run 'definitions' wouldn't it add the wrong creator annotation? Or at very least, new terms would?
(I can't test anything as I don't have the computer set up to test what happens)

I dont think it should! If created_by: dcterms:creator is in the DOSPD, it will use the dcterms:creator! Only that. Which is what you want, right?

oh, misunderstood. I will change. thx.

Last question, is there an easier way to do this?
Tried variations of -type f -exec  sed -i "s/'created_by: oio:created_by'/'created_by: dcterms:creator'/g" {} \;
but this gives an error sed: 1: "./protein_measurement_u ...": invalid command code . sed: 1: "./mri_by_location.yaml": invalid command code . sed: 1: "./therapeuticprocedure_ ...": invalid command code . sed: 1: "./swab_by_location.yaml": invalid command code . sed: 1: "./screening_for_phenoty ...": invalid command code . sed: 1: "./protein_measurement_s ...": invalid command code ....

:D hahah.. ask ChatGPT, that is too advanced for me. or maybe on slack in the random channel

Ha. After a small argument with ChatGPT, I got it to work. FTR:
find . -type f -exec sed -i '' 's/created_by: oio:created_by/created_by: dcterms:creator/g' {} \;

🤣
Great!


Spelling fix

Category

[x] Content fix

Contents of the Pull Request
Correcting spelling of SharePoint

Docs Build status updates of commit b2f5013:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Community/glossary.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


oadp-1.0: OADP-812 Reduce update calls. Implement loglevel override.

Cherry-pick #841 into oadp-1.0

/retest

controller-manager logs from ci are here https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_oadp[…]controller-manager-64574b97d4-5c66f_manager.log
1.0.4 w/o the patch controller-manager logs are here:  openshift-adp_openshift-adp-controller-manager-c7fc8bcc9-q4vmn_manager.log20285Wed, 28 Sep 2022 20:39:37 UTC
w/ patch:
size of logs: 5128
[whayutin@thinkdoe tmp]$ cat openshift-adp_openshift-adp-controller-manager-64574b97d4-5c66f_manager.log | grep "has been labelled" | wc -l
1
w/o patch:
size of logs: 20285
[whayutin@thinkdoe tmp]$ cat openshift-adp_openshift-adp-controller-manager-c7fc8bcc9-q4vmn_manager.log | grep "has been labelled" | wc -l
286

/LGTM


Code for AEMCARL

Dear owners,
As far as I can tell it doesnt seem like the code for your proposed AEMCARL solution is included in this repo. Would it be possible to add this?
Many thanks,
Sahil

The location of AEMCARL code at  the line 90 of "AEMCARL/crowd_nav/common/qnetwork_factory.py "

Ah I see thanks, it would be great if the readme get started section was for training and testing the AEMCARL network or included a location to the AEMCARL code as it seemed it should naturally be in the policy folder. Great stuff though, enjoyed the paper and I look forward to playing around with AEMCARL now.

Another question, what test case/sim setup did you use to produce the video on the read me of the repo with many agents in crowd_sim? Also how did you get the extra graphic that shows how many GRU units are in use etc. Thanks!

The command "python test.py --policy actenvcarl --test_policy_flag 5 --multi_process self_attention --agent_timestep 0.4 --human_timestep 0.5 --reward_increment 2.0 --position_variance 2.0  --direction_variance 2.0 --model_dir data/output --phase test --visualize --test_case 0",  is used to configure the test case. The visualization of the GRU code at the line 777 of "https://github.com/SJWang2015/AEMCARL/blob/main/crowd_sim/envs/crowd_sim_video.py"

Thanks, this test command only produces 5 agents, the sim has 17 i think and the motion patterns are different to test case 0. I tried the same command with --human_num 17 added but the motion pattern is different to the one shown in the video.

You can change the term "human_num"  at the https://github.com/SJWang2015/AEMCARL/blob/202f3f1ce67f24a7b29276496ee0ed4f91683f96/crowd_nav/configs/env.config


Sync conflict when deleting file in shared album

When I share an album to my wife with option 'together' my wife can upload files perfectly. But she can't delete files which I have uploaded to this album. Then a sync error appears. This problem can be solved when I delete the file, too.
To Reproduce
Steps to reproduce the behavior:

create an album (person A is owner)
share to person B
person A (owner) uploads an image
person B deletes image
now person B gets sync error
quickfix is: person A deletes this image a well

Expected behavior
I would expect that person B can also delete images from an shared album.
Smartphone (please complete the following information):

Device: Fairphone 4 and Fairphone 5
OS: Android 14

Les Pas does not provide delete function in Friend's publication (Nextcloud share), could you elaborate on this step

person B deletes image

Did she delete the image using browser?

She deleted the file in the Les Pas app.

How come? There is NO way to delete photo in Friends Publication screen.


[ko] Translate Node-pressure Eviction into Korean

This is a Feature Request

What would you like to be added

The Korean translated version of Node-pressure Eviction
[English version URLs]

https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
https://github.com/kubernetes/website/blob/main/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md

Why is this needed
Because there is no Korean translated version of Node-pressure Eviction.
Comments

/language ko

/assign

/triage accepted


add(consensus): Adds disable_pow and genesis_hash fields, converts equihash::Solution to an enum

Motivation
We want to support Regtest in Zebra by committing the Regtest genesis block.
Closes #8412.
Closes #8366.
Closes #8362.
Closes #7846.
Depends-On: #8413.
PR Author Checklist
Check before marking the PR as ready for review:

[x] Will the PR name make sense to users?
[x] Does the PR have a priority label?
[x] Have you added or updated tests?
[x] Is the documentation up to date?

For significant changes:

[x] Is there a summary in the CHANGELOG?
[x] Can these changes be split into multiple PRs?

If a checkbox isn't relevant to the PR, mark it as done.
Solution

Adds genesis_hash and disable_pow fields
Adds a copy of the Regtest genesis block from zcashd
Converts equihash::Solution to an enum to represent the smaller solutions for Regtest
Updates Network::checkpoint_list() method to return the genesis checkpoint for Regtest

Related Cleanups:

Moves the check for the genesis hash in CheckpointList::from_list() to Network::checkpoint_list() and check that its the first item in the checkpoints that's the genesis hash rather than the first item in the BTreeMap.

Testing

Adds a test to check that the Regtest genesis block from zcashd can be validated and committed.
Updates a test to check that getting the Regtest checkpoint list won't panic

Review
Anyone can review.
Reviewer Checklist
Check before approving the PR:

[ ] Does the PR scope match the ticket?
[ ] Are there enough tests to make sure it works? Do the tests cover the PR motivation?
[ ] Are all the PR blockers dealt with?
PR blockers can be dealt with in new tickets or PRs.

And check the PR Author checklist is complete.
Follow Up Work

Add a target_difficulty_limit field to testnet::Parameters and set it as U256::from_big_endian(&[0x0f].repeat(8)) for Regtest

Looks like a test failed due to a port conflict: https://github.com/ZcashFoundation/zebra/actions/runs/8820097707/job/24212898628?pr=8421#step:12:2817
I'll re-run it once the rest of the workflow is done.


Enhance the fixer of interface-over-type-literal

PR checklist

[x] Addresses an existing issue: fixes  #4795
[x] New feature, bugfix, or enhancement

[x] Includes tests

[x] Documentation update

Overview of change:
Added a step in the fixer so that it goes into the members to check if they carry a trailing comma. If they do, replace it with semicolon. The fixed interface now looks like
interface User {
  someData: {
    firstName: string,
    lastName: string,
    registered: boolean,
  };
  location: string;
  quantity: number;
}

instead of
interface User {
  someData: {
    firstName: string,
    lastName: string,
    registered: boolean,
  },
  location: string,
  quantity: number,
}

Is there anything you'd like reviewers to focus on?
CHANGELOG.md entry:
[enhancement] interface-over-type-literal The fixer now makes sure that the interface uses semicolon to separate individual member declarations.

Thanks for your interest in palantir/tslint, @ychen10! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

Test failing as per #4784

Declined per #4795 😢.
In general, until an issue is marked as Status: Accepting PRs, it's better to hold off on writing a PR. You never know when an issue will be declined by some annoying maintainer.

FWIW, you can always fork this rule (copy & paste the .js output into a new file) and use it in your own project instead of the core rule.


Golint

Fixes the following issues:

Running gofmt...
Running ineffassign...
Running golint...
golint errors in:
src/poule/configuration/constants.go:5:2: const JenkinsBaseUrl should be JenkinsBaseURL
src/poule/operations/settings/filtering.go:328:1: exported function FilterIncludesIssues should have comment or be unexported
src/poule/operations/settings/filtering.go:337:1: exported function FilterIncludesPullRequests should have comment or be unexported
src/poule/runner/runner.go:18:6: exported type OperationRunner should have comment or be unexported
src/poule/runner/runner.go:68:1: comment on exported method OperationRunner.HandleStock should be of the form "HandleStock ..."
src/poule/test/github.go:12:6: type name will be used as test.TestClient by other packages, and that stutters; consider calling this Client

Also brings in a checks.sh script which should keep you passing goreportcard at all costs.
HTH!

NOTE: I commented out deadcode in my own tooling, which is where this script comes from. I can uncomment it or remove it; but it is pretty useful to have in the pipeline.

deadcode doesn't work with build tags.

Thanks! LGTM :)


Add option to output query data in long table format

Can have a sub-option to append dimension record columns (e.g., fuel_id and unit)

@elainethale I need some clarification regarding the sub-option.

Is this only for fuel_id and unit in the case of an unpivoted result table? Or do you want to generically support any dimension record column for pivoted and unpivoted? We don't really have use cases for columns other than fuel_id and unit. We could support any dimension record columns in pivoted results as long as the dimension isn't the pivoted one.
Do we need to support adding fuel_id and unit to pivoted column names?


Add gnuplot to GCG

Hallo @AntoinePrv,
I am a member of the GCG dev team and we thank you for adding GCG to conda-forge.
GCG uses gnuplot to visualize decompositions. Can you please take a look at this PR if it satisfies all requirements?
Kind regards,
Jurgen Lentz
Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-admin, please rerender

Thank you @jurgen-lentz for pointing this out!
Are there any other CMake flags (in build.sh) that need to be activated for this to work?

We only use the CLI of gnuplot to create visualizations, so no :)

Ok, makes sense. Is this something you use in an executable/script packaged in GCG, or as a post-processing step (in which case maybe we should leave it out)?

GCG runs in its C/C++ code the command
gnuplot {filename}.gp

to run the executable of gnuplot.

Sounds good to me. We happen to have another branch for the SCIP8 release that required quite a refactor.
If you don't see any objection, I'll add it there and release it along with SCIP8.

Sure. Thank you!


fix: new neighborhood type and cleanup

Checklist

[ ] I have read the coding guide.
[ ] My change requires a documentation update, and I have done it.
[ ] I have added tests to cover my changes.
[ ] I have filled out the description and linked the related issues.

Description

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

Even with increasing the reserve capacity in TestNeighborhoodStats/mem it seems that for macos it almost always fails .
Except this LGTM


Roll Engine from 23a8e027dbbe to 97cacfbfec89 (14 revisions)

https://github.com/flutter/engine/compare/23a8e027dbbe...97cacfbfec89
2020-11-20<EMAIL_ADDRESS>Add more runtime intrinsic symbols to the export checker script (flutter/engine#22641)
2020-11-20<EMAIL_ADDRESS>[web] Implement tilemode for gradient shaders. (flutter/engine#22597)
2020-11-20<EMAIL_ADDRESS>Roll Dart SDK from 861ebcb175b6 to 1adf3d5fa9d0 (1 revision) (flutter/engine#22636)
2020-11-20<EMAIL_ADDRESS>Roll Skia from 9dce4d081f8a to 8c5889937172 (1 revision) (flutter/engine#22635)
2020-11-20<EMAIL_ADDRESS>Roll Dart SDK from b8fea79a2549 to 861ebcb175b6 (1 revision) (flutter/engine#22634)
2020-11-20<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from DQpWjEN59... to wGZWtwuY4... (flutter/engine#22633)
2020-11-20<EMAIL_ADDRESS>Roll Skia from ed289e777cfa to 9dce4d081f8a (3 revisions) (flutter/engine#22632)
2020-11-20<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from aAb3NJv_h... to X1ue-JZsc... (flutter/engine#22631)
2020-11-20<EMAIL_ADDRESS>Roll Dart SDK from a06d469024fd to b8fea79a2549 (1 revision) (flutter/engine#22630)
2020-11-20<EMAIL_ADDRESS>[fuchsia] shader warmup fixes (flutter/engine#22439)
2020-11-20<EMAIL_ADDRESS>Remove opt outs for dart:ui (flutter/engine#22603)
2020-11-20<EMAIL_ADDRESS>Roll Dart SDK from 12fded61a2bc to a06d469024fd (1 revision) (flutter/engine#22623)
2020-11-20<EMAIL_ADDRESS>Implement Scene.toImage() in CanvasKit mode. (flutter/engine#22085)
2020-11-20<EMAIL_ADDRESS>Split AOT Android Embedder and shell (flutter/engine#22179)
Also rolling transitive DEPS:
fuchsia/sdk/core/linux-amd64 from aAb3NJv_h2CI to X1ue-JZscha_
fuchsia/sdk/core/mac-amd64 from DQpWjEN59czS to wGZWtwuY4ude
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Gold has detected about 1 untriaged digest(s) on patchset 14.
View them at https://flutter-gold.skia.org/cl/github/70958


Bug of restarting training?

Thanks for this great work!
I just launched the training under the csgo branch and it seems the learning_rate is reset after the first epoch, the loss also.
Could you let me know if this is on purpose and why, or it is a small bug? Thanks!

Sorry, my bad. It was a wandb logging debug problem I forgot to roll back... Cheers!


[Question] Add Users / Device to HAP association

Hi,
On my side, HAP works really good, great job !
However, I would like to add my iPad (with the same apple Id) and my wife's iPhone to the HAP instance.
As I understand, only one device can be paired with a HomeKit bridge.
For my wife, I tried to invite her through the HomeKit menu in settings - she never received the invitation, event if I tried to reset HomeKit  / reboot on device
On my iPad, even if I'm using the same Apple Id, I can't use SIRI and HomeKit does not appears in the settings.
Any workaround to fix those problems ?

Ok after few tests, it seems that changing the username in my device fix the issue.
But I found another issue : I have to re-pair my device with HAP on each raspberry's reboot.
I'm using forever to start hap as service - when I stop and restart the service, no problem I can still using siri and the iPhone is still paired with hap. When rebooting the raspberry, I have to redo the pairing operation...

That's strange, can you post logs from HAP-NodeJS after reboot?

Raspberry is connected through Ethernet.
Here is logs when HAP is working :
hap-out.log
HAP-NodeJS starting...
Parsing accessory: ambiancedodo_accessory.js
Parsing accessory: ambiancesalon_accessory.js
Parsing accessory: ambiancesleep_accessory.js
Parsing accessory: ambiancetv_accessory.js
Parsing accessory: aquarium_accessory.js
Parsing accessory: cafe_accessory.js
Parsing accessory: camera2_accessory.js
Parsing accessory: cameraExt_accessory.js
Parsing accessory: camera_accessory.js
Parsing accessory: jardin_accessory.js
Parsing accessory: lampeCouloir_accessory.js
Parsing accessory: lit_accessory.js
Parsing accessory: petiteLampeSalon_accessory.js
Parsing accessory: salon_accessory.js
Parsing accessory: tele_accessory.js
Setting light brightness to 0
Turning the light off!
Setting light brightness to 0

hap-err.log
*** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node>
*** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister>
Wed, 25 Nov 2015 11:13:59 GMT EventedHTTPServer Server listening on port 51826
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] New connection from client
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP server listening on port 54826
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify
Wed, 25 Nov 2015 11:14:31 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: POST /pair-verify
Wed, 25 Nov 2015 11:14:31 GMT HAPServer [3D:C6:76:A7:73:E3] Pair verify step 1/2
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify
Wed, 25 Nov 2015 11:14:31 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: POST /pair-verify
Wed, 25 Nov 2015 11:14:31 GMT HAPServer [3D:C6:76:A7:73:E3] Pair verify step 2/2
Wed, 25 Nov 2015 11:14:31 GMT HAPServer [3D:C6:76:A7:73:E3] Client 9C3F5AAC-9D97-4449-A8A7-290040B492CE verification complete
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /accessories
Wed, 25 Nov 2015 11:14:31 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: GET /accessories
Wed, 25 Nov 2015 11:14:31 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:14:32 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /characteristics
Wed, 25 Nov 2015 11:14:32 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: PUT /characteristics
Wed, 25 Nov 2015 11:14:32 GMT Accessory [Hautomation] Processing characteristic set: [{"remote":true,"value":0,"aid":8,"iid":10}]
Wed, 25 Nov 2015 11:14:32 GMT Accessory [Hautomation] Setting Characteristic "Brightness" to value 0
Wed, 25 Nov 2015 11:14:32 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:15:37 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /characteristics
Wed, 25 Nov 2015 11:15:37 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: PUT /characteristics
Wed, 25 Nov 2015 11:15:37 GMT Accessory [Hautomation] Processing characteristic set: [{"remote":true,"value":0,"aid":8,"iid":9}]
Wed, 25 Nov 2015 11:15:37 GMT Accessory [Hautomation] Setting Characteristic "On" to value 0
Wed, 25 Nov 2015 11:15:37 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:15:41 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /characteristics
Wed, 25 Nov 2015 11:15:41 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: PUT /characteristics
Wed, 25 Nov 2015 11:15:41 GMT Accessory [Hautomation] Processing characteristic set: [{"remote":true,"value":0,"aid":8,"iid":10}]
Wed, 25 Nov 2015 11:15:41 GMT Accessory [Hautomation] Setting Characteristic "Brightness" to value 0
Wed, 25 Nov 2015 11:15:41 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished

In this case I tried to turn off a light successfully. I'm using remote access through my Apple TV (<IP_ADDRESS>), and this also answer my first question concerning remote access - I believed that iOS 9 doesn't need an Apple TV to enable remote access to HomeKit, but it's not the case for me.
After stopping / starting hap, it can take some time for Apple TV to connect to hap (in this case 30 seconds but it's not a good example) - sometimes I have to disconnect / reconnect  Apple TV's WiFI.
Here is logs after rebooting raspberry pi :
hap-out.log
HAP-NodeJS starting...
Parsing accessory: ambiancedodo_accessory.js
Parsing accessory: ambiancesalon_accessory.js
Parsing accessory: ambiancesleep_accessory.js
Parsing accessory: ambiancetv_accessory.js
Parsing accessory: aquarium_accessory.js
Parsing accessory: cafe_accessory.js
Parsing accessory: camera2_accessory.js
Parsing accessory: cameraExt_accessory.js
Parsing accessory: camera_accessory.js
Parsing accessory: jardin_accessory.js
Parsing accessory: lampeCouloir_accessory.js
Parsing accessory: lit_accessory.js
Parsing accessory: petiteLampeSalon_accessory.js
Parsing accessory: salon_accessory.js
Parsing accessory: tele_accessory.js
Turning the light on!
Setting light brightness to 100
Turning the light off!
Setting light brightness to 0

hap-err.log
*** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node>
*** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister>
Wed, 25 Nov 2015 11:18:04 GMT EventedHTTPServer Server listening on port 51826
Wed, 25 Nov 2015 11:21:11 GMT EventedHTTPServer [<IP_ADDRESS>] New connection from client
Wed, 25 Nov 2015 11:21:11 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP server listening on port 54826
Wed, 25 Nov 2015 11:21:11 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify
Wed, 25 Nov 2015 11:21:11 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: POST /pair-verify
Wed, 25 Nov 2015 11:21:11 GMT HAPServer [3D:C6:76:A7:73:E3] Pair verify step 1/2
Wed, 25 Nov 2015 11:21:11 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:21:11 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify
Wed, 25 Nov 2015 11:21:11 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: POST /pair-verify
Wed, 25 Nov 2015 11:21:11 GMT HAPServer [3D:C6:76:A7:73:E3] Pair verify step 2/2
Wed, 25 Nov 2015 11:21:12 GMT HAPServer [3D:C6:76:A7:73:E3] Client CC5F6863-F45D-45DB-B69E-518A4353D081 verification complete
Wed, 25 Nov 2015 11:21:12 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:21:12 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /accessories
Wed, 25 Nov 2015 11:21:12 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: GET /accessories
Wed, 25 Nov 2015 11:21:12 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] New connection from client
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP server listening on port 54827
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify
Wed, 25 Nov 2015 11:22:45 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: POST /pair-verify
Wed, 25 Nov 2015 11:22:45 GMT HAPServer [3D:C6:76:A7:73:E3] Pair verify step 1/2
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify
Wed, 25 Nov 2015 11:22:45 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: POST /pair-verify
Wed, 25 Nov 2015 11:22:45 GMT HAPServer [3D:C6:76:A7:73:E3] Pair verify step 2/2
Wed, 25 Nov 2015 11:22:45 GMT HAPServer [3D:C6:76:A7:73:E3] Client 9C3F5AAC-9D97-4449-A8A7-290040B492CE verification complete
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /accessories
Wed, 25 Nov 2015 11:22:45 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: GET /accessories
Wed, 25 Nov 2015 11:22:45 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:23:17 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /characteristics
Wed, 25 Nov 2015 11:23:17 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: PUT /characteristics
Wed, 25 Nov 2015 11:23:17 GMT Accessory [Hautomation] Processing characteristic set: [{"remote":true,"value":1,"aid":8,"iid":9}]
Wed, 25 Nov 2015 11:23:17 GMT Accessory [Hautomation] Setting Characteristic "On" to value 1
Wed, 25 Nov 2015 11:23:17 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:23:21 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /characteristics
Wed, 25 Nov 2015 11:23:21 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: PUT /characteristics
Wed, 25 Nov 2015 11:23:21 GMT Accessory [Hautomation] Processing characteristic set: [{"remote":true,"value":100,"aid":8,"iid":10}]
Wed, 25 Nov 2015 11:23:21 GMT Accessory [Hautomation] Setting Characteristic "Brightness" to value 100
Wed, 25 Nov 2015 11:23:21 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:23:48 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /characteristics
Wed, 25 Nov 2015 11:23:48 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: PUT /characteristics
Wed, 25 Nov 2015 11:23:48 GMT Accessory [Hautomation] Processing characteristic set: [{"remote":true,"value":0,"aid":8,"iid":9}]
Wed, 25 Nov 2015 11:23:48 GMT Accessory [Hautomation] Setting Characteristic "On" to value 0
Wed, 25 Nov 2015 11:23:48 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 11:23:52 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /characteristics
Wed, 25 Nov 2015 11:23:52 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: PUT /characteristics
Wed, 25 Nov 2015 11:23:52 GMT Accessory [Hautomation] Processing characteristic set: [{"remote":true,"value":0,"aid":8,"iid":10}]
Wed, 25 Nov 2015 11:23:52 GMT Accessory [Hautomation] Setting Characteristic "Brightness" to value 0
Wed, 25 Nov 2015 11:23:52 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished

Ok so, even after a reboot hap is receiving well the instructions through HomeKit.
I was wrong ; if I try to call HomeKit request just after a reboot, it doesn't work because the device is not yet connected to network. In the log above, <IP_ADDRESS> is my iPad connected to WiFI. As you can see it can takes around 4 minutes to establish connection between some devices and Apple TV.
Conclusion is I finally don't think this is an issue - I have to be more patient :)
I will do some additional tests - if the problem persists I will continue this thread.

Ok I made additional test and the problem is there after reboot.
Here is the logs :
Wed, 25 Nov 2015 16:34:08 GMT EventedHTTPServer Server listening on port 51826
Wed, 25 Nov 2015 16:34:10 GMT EventedHTTPServer [<IP_ADDRESS>] New connection from client
Wed, 25 Nov 2015 16:34:10 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP server listening on port 54826
Wed, 25 Nov 2015 16:34:10 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP request: /pair-verify
Wed, 25 Nov 2015 16:34:10 GMT HAPServer [3D:C6:76:A7:73:E3] HAP Request: POST /pair-verify
Wed, 25 Nov 2015 16:34:10 GMT HAPServer [3D:C6:76:A7:73:E3] Pair verify step 1/2
Wed, 25 Nov 2015 16:34:10 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP Repsonse is finished
Wed, 25 Nov 2015 16:34:10 GMT EventedHTTPServer [<IP_ADDRESS>] Client connection closed
Wed, 25 Nov 2015 16:34:10 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP connection was closed
Wed, 25 Nov 2015 16:34:10 GMT EventedHTTPServer [<IP_ADDRESS>] HTTP server was closed

In fact the Apple TV stucks in the pairing step 1. Since the logs 5 minutes has passed and no additional logs.
I also checked the process part to be sure that hap is till running :
root      3952  0.8  2.4  82308 23396 ?        Ssl  17:34   0:02 /usr/local/bin/node /usr/local/lib/node_modules/forever/bin/monitor ./BridgedCore.js
root      3990  0.8  2.6  92824 24900 ?        Sl   17:34   0:02 /usr/local/bin/node /home/pi/hautomation/services/siri/HAP-NodeJS/BridgedCore.js
pi        4252  0.0  0.1   4100

Any idea ?


[Bug] User unable to see the "dbt docs" menu item in Astro

Astronomer Cosmos Version
Other Astronomer Cosmos version (please specify below)
If "Other Astronomer Cosmos version" selected, which one?
1.5.1
dbt-core version
1.7.2
Versions of dbt adapters
dbt-snowflake==1.7.3
apache-airflow-providers-snowflake==5.1.1
apache-airflow-providers-microsoft-azure==8.2.0
apache-airflow-providers-sendgrid==3.5.0
requests-futures==1.0.1
requests-toolbelt==1.0.0
polars[xlsx2csv]==0.18.15
azure-storage-blob==12.17.0
simple-salesforce==1.12.5
beautifulsoup4==4.12.2
LoadMode
AUTOMATIC
ExecutionMode
LOCAL
InvocationMode
None
airflow version
apache-airflow==2.9.1 (astro-runtime:11.3.00
Operating System
Any
If a you think it's an UI issue, what browsers are you seeing the problem on?
Chrome
Deployment
Astronomer
Deployment details
No response
What happened?
The user has successfully created the dbt docs and stored it in Azure Blob storage by using DbtDocsAzureStorageOperator.
They successfully configured the Cosmos plugin to render the docs, by using:
AIRFLOW__COSMOS__DBT_DOCS_DIR=wasb://user-bucket/dbt-docs
AIRFLOW__COSMOS__DBT_DOCS_CONN_ID=azure_conn

They are not able to see the menu item in the Airflow UI:

However, if they access the URL directly, they can see the dbt docs rendered in Airflow:
http://airflow-host/cosmos/dbt_docs

Relevant log output
Apparently, there are no errors in the webserver logs. The only issue is that the menu item is not showing up.

How to reproduce
We have yet to reproduce this problem.
We're currently suspecting this is a permission issue.
Anything else :)?
Internal slack thread where the problem was discussed: https://astronomer.slack.com/archives/C04EXKRQFD3/p1721637533315019
We'll likely have to add set additional level of permission in  https://github.com/astronomer/astronomer-cosmos/blob/main/cosmos/plugin/init.py
The specific user seems to have workspace operator permissions in Astro, which should have "Use custom plugins from the Airflow UI menu":
https://www.astronomer.io/docs/astro/user-permissions
The source of truth of perms is this file https://github.com/astronomer/astro/blob/fb0acfe9a0524aaceab61169fd7486862ddbe6e6/apps/authz/src/types/rolePermissions.ts#L134
We probably care about “deployment.airflow.customMenu.get” perm
Other references:

https://www.astronomer.io/docs/learn/using-airflow-plugins#appbuilder-menu-items
https://astronomer.slack.com/archives/C04JG8563HR/p1712242691378909 (a 216 thread about a similar issue in the past, with another provider)

Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Contact Details
No response

Something we could look into is how we define the custom menu item, to follow what is recommended in the docs:
https://www.astronomer.io/docs/learn/using-airflow-plugins#appbuilder-menu-items
from airflow.plugins_manager import AirflowPlugin

# creating a new top-level menu item
appbuilder_mitem_toplevel = {
    "name": "Apache",
    "href": "https://www.apache.org/",
}

# creating a new sub-item in the Docs menu item
appbuilder_mitem_subitem = {
    "name": "Astro SDK Docs",
    "href": "https://astro-sdk-python.readthedocs.io/en/stable/index.html",
    "category": "Docs",
}

# defining the plugin class
class MyMenuItemsPlugin(AirflowPlugin):
    name = "Menu items plugin"

    # adding the menu items to the plugin
    appbuilder_menu_items = [appbuilder_mitem_toplevel, appbuilder_mitem_subitem]

I just spoke to Vishnu U, and he was able to reproduce the problem in Astro 🎉

when he is an Organization Owner, he can see the dbt docs menu
when he is an Organization Member and Workspace Operator, he doesn't see the menu item

We identified that the issue is indeed user permissions and we'll try to fix this in 1.7

Suggestion from Alex Liotta, who experienced a similar problem in the past: https://astronomer.slack.com/archives/C04EXKRQFD3/p1722435658739929?thread_ts=1721637533.315019&cid=C04EXKRQFD3

Org owner gets the permission ‘deployment.airflow.admin’, via its inheritance of “workspaceOwnerActions”. This perm bypasses all auth checks on the airflow side hence why the  user can see the menu. For Operator to work you will need to set the dag file up to respect the attached image from this docs https://www.astronomer.io/docs/learn/using-airflow-plugins#flask-blueprints-and-appbuilder-views

@tatiana Do we have an ETA for this fix?

@jessicaschueler I've attempted to fix the issue (#1280) following Astro's docs, but it still needs validation in Astro Cloud.
If you want to help with this, please try out this alpha release:
https://pypi.org/project/astronomer-cosmos/1.7.1a2/
I strongly suggest we validate this before sharing it with customers.

I validated it in Astro Cloud, and the issue seems to be solved. However, I would appreciate a second pair of eyes to confirm.

I confirmed in a fresh deployment _tati_cosmos_test in a workspace ("OSS Team Integration Test Workspace") that I have Workspace Operator permissions (astronomer-stage environment):

This is with Cosmos 1.7:

This is with Cosmos 1.7.1a3:


[docs] Improving Troubleshooting section

This PR is intended to improve Troubleshooting section in azk documentation:

[x] Rewrite the whole troubleshooting section (fix typos and make it clearer);
[x] Add new section: [sync] fail Error: watch ENOSPC;
[ ] Add new section: Bind host to <IP_ADDRESS> IP when running a server from inside a container;

very good :smiley:


B14.0 Delivery to I&T Prep

💡 Description

https://github.com/NASA-PDS/software-issues-repo/issues/49
https://github.com/NASA-PDS/pds-github-util/issues/65
https://github.com/NASA-PDS/software-issues-repo/issues/84

📆 August status: Running behind by 1 week on this. To be worked in first week of September to include in delivery to I&T.

Skipping this for this build. No impact on I&T.

Closing very late. https://github.com/NASA-PDS/pds-github-util/issues/65 moved to B14.1