The variable a is incremented thanks to the atomic memory primitives function addInt that is concurrent-safe. However, we assign the result to the same variable, which is a not a concurrent-safe write operation. This a careless mistake detected by the atomic analyzer.

it quickly becomes a mess of non related functions that anyone but the owner feels brave enough to import

A little copy paste is better than a little dependency.

Avoid indentation levels, If you find yourself with more than 3, you should create a function.

Code explains what and how Documentation explains why.

So make sure to write your documentation, but do not explain your spells.

This is so clear that you don’t even need comments to explain it.

Another type of comments are the ones trying to explain a spell.

Do not explain your spells, rewrite them.

Do you really need those lines? Isn’t it clear enough? Well, I still find comments like this in a lot of cases and it gets funnier when the comment is obsolete and the code is doing other things. Following the example, let’s imagine that another developer adds support for PUT method. I think that this is what would happen.

This code is much easier to understand as it do not add levels of indentation and follows the principle where the 0 indentation level is the principal path of the application where other paths are exceptions or rare cases.

people usually forgets about one of the greatest advantages of Open Source. YOU can fix the issue. You can download the source code and dig deep into the code allow you to keep moving. Also, you can merge this changes back to the original repository so others doesn’t have to fix it again. win-win relationship.

The rule of thumbs is, never use code that you do not understand.

The rules recorded in natural language are readable not only by humans but also by the computer and therefore no longer need to be programmed by a software developer. This task is now taken over by openVALIDATION.

openVALIDATION enables programming of complex validation rules using natural language, such as German or English.

"detail": [ { "loc": [ "body", "name" ], "message": "Field required" }, { "loc": [ "body", "email" ], "message": "'not-email' is not an 'email'" } ]

For example, let’s consider the type property. For most of the projects I am working on, it isn’t practical to have a webpage dedicated to each type of possible error.

For the instance property, the most practical way I’ve found of implementing this is to define a URN that encapsulates additional information regarding the error. Here is an example URN for reference. urn:companyname:api:error:protocol:badRequest:f29f57d7-e1f8-4643-b226-fa18f15e9b71

We decided to follow their rules to stay in their affiliate program, because that's how we are able to actually run the site (without any ads).And if you look on the issue from the usability point of view, not having their price history isn't that big of a deal, unless the game is sold only on Amazon - and most games aren't - so you always have other stores to compare the price to.

Hi L0ki,as we depend on retailers with affiliate programs to run the site without ads, and Amazon being one of them, yes, we are following their rules so we can use API and their affiliate program.As Tomas said, we are also trying to get the history back, though we noticed we aren't the only site being affected by this.As for ignoring their API and doing it the hard way - that could be possible I guess but really not preferable.And we also understand anybody not wanting to buy from Amazon anymore (as some already told us), but to be fair, if the game is available anywhere else (and I have yet to randomly find a game which is available only at Amazon), you can always check the game info on ITAD to compare the price to other retailers.

If it's not, it should be illegal for them to forbid you from showing price history. This is restricting access to information, and it's probably supposed to benefit them from shady sales (increasing the base price just before a sale, so that the "X % off" is higher).

"We are not allowed to show you Amazon history"? What prompted this? Fill me in if I missed something :).EDIT: Camelcamelcamel can still show Amazon price history, so a bit befuddled here.

I would be interested to know what the legality of this is either way. I mean, do they really have any legal right to compel you not to list their price history? However, just knowing that Amazon doesn't want you to do this will make me less likely to purchase from them in the future. Anti-consumer behavior pisses me off. Edit: If this is related to API access couldn't you just manually scrape prices off the site instead and hammer their server? Or is this more related to not wanting to bite the hand that feeds you so to speak related to the funding you can get through referral links?

"type": "https://example.com/problems/request-parameters-missing"

This specification reserves the use of one URI as a problem type: The "about:blank" URI [RFC6694], when used as a problem type, indicates that the problem has no additional semantics beyond that of the HTTP status code. When "about:blank" is used, the title SHOULD be the same as the recommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on), although it MAY be localized to suit client preferences (expressed with the Accept-Language request header). Please note that according to how the "type" member is defined (Section 3.1), the "about:blank" URI is the default value for that member. Consequently, any problem details object not carrying an explicit "type" member implicitly uses this URI.

Consumers can use the status member to determine what the original status code used by the generator was, in cases where it has been changed (e.g., by an intermediary or cache), and when message bodies persist without HTTP information. Generic HTTP software will still use the HTTP status code.

Likewise, truly generic problems -- i.e., conditions that could potentially apply to any resource on the Web -- are usually better expressed as plain status codes.

For example, a "write access disallowed" problem is probably unnecessary, since a 403 Forbidden status code in response to a PUT request is self-explanatory.

Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree.

The media type specification and registration procedure is now a separate document, to make it clear that it is independent of MIME.

they allow resources to be referred to without the need for a continuously available host, and can be generated by anyone who already has the file, without the need for a central authority to issue them. This makes them popular for use as "guaranteed" search terms within the file sharing community where anyone can distribute a magnet link to ensure that the resource retrieved by that link is the one intended, regardless of how it is retrieved.

However, while URLs allow you to locate a resource, a URI simply identifies a resource. This means that a URI is not necessarily intended as an address to get a resource. It is meant just as an identifier.

pointer: type: string description: A string containing a JSON pointer to the specific field within a received JSON body that caused the problem, e.g. '/data/attributes/title' to refer to the `title` property within the `attributes` object that is a child of the top level `data` object. example: /data/attributes/title

ErrorResponse: description: Container object for one or more errors returned by the API. type: object required: - errors properties: errors: type: array items: $ref: '#/definitions/Error'

TylerRick commented

I think your issue is a bug (it's different from this issue which is a feature request about the split command). I opened this issue you may want to follow: #560

with the caveat that the split->bundle will be lossy with respect to YAML comments/format. I've thought about it more and think, "so what?" If it enables teams to be more productive, great.

It means it is split to an opinionated split structure.

I saw the repo previously, but missed the split functionality, I thought it was more like a template repo.

FetchErrorResponse: type: object properties: meta: $ref: '#/definitions/FetchMetaResponse' errors: $ref: '#/definitions/Error' example: { "meta": { "req_id": "d07c8b12-c95e-4a06-8424-92aac94bb445" }, "errors": [{ "code": "Unauthorized", "detail": "A valid bearer token is required", "status":"401" } ] }

This has moved to part of the monorepo:

There are also some advantages to a multi-file YAML format OpenAPI definition: Reuse schema objects to keep things DRY (don't repeat yourself) Smaller diffs compared to JSON (especially for markdown descriptions) Easier to navigate Easier to edit with confidence

Filter gives me the impression of inclusion... so if I filter by fruits, I expect to see apples, oranges, and bananas. Instead, this is more like filter out fruits... remove all the fruits, and you're left with the rest. Filter in/out are both viable. One means to include everything that matches a condition, and the other is to exclude everything that does not match a condition. And I don't think we can have just one.

I got stuck with tests here #443 and I need to switch to other more prioritised work. Maybe somebody will take over when time allows.

let's not mix code changes with prettier. This is a bad practise which complicates code review and history review. Let's apply prettier in a separate PR/commit.

The server possibly can send back a 406 (Not Acceptable) error code when unable to serve content in a matching language. However, such a behavior is rarely implemented for a better user experience, and servers often ignore the Accept-Language header in such cases.

x-ov-rules: culture: en rule: | the location of the applicant MUST be Dortmund

Warning: The client should not repeat this request without modification.

It is often the case that a group or "tree" of documents has been constructed to serve a common purpose, wherein the vast majority of URI references in these documents point to resources within the tree rather than outside it. Similarly, documents located at a particular site are much more likely to refer to other resources at that site than to resources at remote sites. Relative referencing of URIs allows document trees to be partially independent of their location and access scheme.

Relative referencing of URIs allows document trees to be partially independent of their location and access scheme.

Would you accept a PR for the suggested change?

There are so many movies where the directors go out and say this is a family movie, just like the whole cast of Salaam Namaste when they shouted out that its a movie for families too..but the ones that have seen it they know how Vulguar the movie was at times. But this movie is a true family movie, and Iam sure your family will enjoy it, mine did for sure.

However, links between resources need not be format specific; it can be useful to have typed links that are independent of their serialisation, especially when a resource has representations in multiple formats.

To be fair, for a $30 asset I don't really expect that much support, but the problem here is that because of the lack of docs and hard to parse and modify codebase, folks are way more dependent on the developer than for other assets with proper docs, field tooltips, and maintainable code.

The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

You can tell the lint command to validate specific API definitions by using their names from the apis object, like in the following example: Copy Copied redocly lint core@v2

We do, You doThis tutorial is most effective when you follow along and complete the steps.

Rename the existing default branch to the new name (main). The argument -m transfers all commit history to the new branch: git branch -m master main

Unfortunately, Wiki depends a lot on HEAD ref for its functionality, such as versions management, file collision check, etc. That causes multiple quirky behaviors. The normal project repositories don't fall into such behaviors because GitLab (Gitaly actually) has a complicated heuristic to determine the current default branch, while Wiki repository does not.

The fix is to unify how Git repository accesses the data.

Further, all outbound communication from the FaxZero server is secured with either SSL or TLS.

Snail mail can be too slow, and email isn't secure. So that leaves us with the decades-old, but still reliable, fax.

A workaround you can use is to move additionalProperties to the extending schema and redeclare the properties from the extended schema.

Because additionalProperties only recognizes properties declared in the same subschema, it considers anything other than “street_address”, “city”, and “state” to be additional. Combining the schemas with allOf doesn’t change that.

It’s important to note that additionalProperties only recognizes properties declared in the same subschema as itself. So, additionalProperties can restrict you from “extending” a schema using Schema Composition keywords such as allOf. In the following example, we can see how the additionalProperties can cause attempts to extend the address schema example to fail.

In your scenario, which many, many people encounter, you expect that properties defined in schema1 will be known to schema2; but this is not the case and will never be.

When you do: "allOf": [ { "schema1": "here" }, { "schema2": "here" } ] schema1 and schema2 have no knowledge of one another; they are evaluated in their own context.

],

I'm not sure if there's a reason why additionalProperties only looks at the sibling-level when checking allowed properties but IMHO this should be changed.

This clearly violates DRY, which is the reason why OP asked this question in the first place

It appears redundant, and my goal of using $ref is to avoid repeating definitions.

It's unfortunate that additionalProperties only takes the immediate, sibling-level properties into account

additionalProperties applies to all properties that are not accounted-for by properties or patternProperties in the immediate schema.

additionalProperties here applies to all properties, because there is no sibling-level properties entry - the one inside allOf does not count.

Incidentally, I am also the author of the website you are referring to.

[author of the draft v4 validation spec here]

You have stumbled upon the most common problem in JSON Schema, that is, its fundamental inability to do inheritance as users expect; but at the same time it is one of its core features.

this is one of the best examples I've read that explains the full picture. Thanks @ted epstein

unevaluatedProperties is like additionalProperties, except that it can "see through" $ref and "see inside" allOf, anyOf, oneOf, if, then, else

Yes, I understand that it had probably been tried. My question was more, "Why didn't twiddling the knob work?”

I think the answer lies here: Cant see into oneOf or allOf etc. This, I think, is the distinguishing difference between additionalProperties and unevaluatedProperties.

that is the key difference

Everything else in this issue is just figuring out how to make that happen, which turns out to be rather involved.

understanding that was a big (and recent) moment for me too.

If anyone can completely refactor the JSON Schema description for OpenAPI v3.0 to accurately describe the schema in all its glory, without using this new keyword, then please do so, but I would kindly ask you to test the theory first.

Such schemas cannot easily be refactored without removing the benefits of sharing. Refactoring would require forking a local copy, which for schemas intended to be treated as an opaque validation interface with internal details that may change, eliminates the benefit of referencing a separately maintained schema in the first place.

PRs will introduce various mechanisms step by step. Some of these have issues already. A possible breakdown could be: Annotation collection using instance values (links also does this) Defining annotations to which multiple keywords contribute (this is new, see Need more details of annotation collection #530) Defining subschema and keyword processing results to include annotations Processing sequence for keywords that dynamically rely on the results of static keywords The actual definition of unevaluatedProperties An example of unevaluatedProperties

In particular, it allowed for organizing common traits (such as extensibility, or different ways of showing examples as schemas that can be mixed in to the main object definitions.

This means that when considering the "unevaluatedProperties": false in the root schema, "wheels" has not been evaluated, so unevaluatedProperties applies to it, and therefore validation fails because the false subschema fails by definition against any instance.

consider a situation where the branches of the oneOf are separate schemas owned by other entities (and therefore impossible to refactor without forking), which are intended to provide an opaque validation interface (and therefore may change internal details without warning, but without changing the desired validation outcome) and are included by $ref

However, unevaluatedProperties has dynamic behavior, meaning that the set of properties to which it applies cannot be determined from static analysis of the schema (either the immediate schema object or any subschemas of that object).

unevaluatedProperties is similar to additionalProperties in that it has a single subschema, and it applies that subschema to instance properties that are not a member of some set.

Please do not debate the annotation collection mechanism here in this issue. Please do debate it in #530.

We do not want to change or remove additionalProperties. Providing a clear solution for the above use case will dramatically reduce or eliminate the misunderstandings around additionalProperties.

This is a distillation of the results of 230+ comments on #515, not to mention the 300+ comments spread across several other older issues that fed into that one. I know it's long. Please don't complain unless you can offer a shorter write-up. :-)

This does work, but as can be seen in the PR, it raised serious concerns over the maintainability of the resulting schema due to all of the duplication.

This issue is for discussing the use case given in the next section, and the unevaluatedProperties proposal to solve it. If you want to discuss a different use case or a different proposal, you MUST file your own issue to do so. Any comments attempting to revive other lines of discussion from #515, introduce new problems or solutions, or otherwise derail this discussion will be deleted to keep the focus clear. Please file a new issue and link back to this one instead.

As a reminder, the JSON Schema is not the source of truth for the Specification. In cases of conflicts between the Specification itself and the JSON Schema, the Specification wins.

Also, some Specification constraints cannot be represented with the JSON Schema so it's highly recommended to employ other methods to ensure compliance.

Does this mean that the schema is available now since the bug is closed?

OK, I am really, truly, for real working on this next week. Stay tuned... and feel free to mock me if I don't get anything done

Changing OAS to placate JSON Schema validators is definitely a tail-wagging-the-dog scenario.

I found your unevaluatedProperties proposal while trying to understand what's the problem with JSON Schema for OAS 3.x. It looks like OAS 3.x would not have used x- properties if it had to produce a JSON Schema at release time. Now, you are trying to fix OAS 3.x idiosyncrasies by pushing a change to JSON Schema in a tail-wagging-the-dog move. This is fascinating ;-)

The difficulties of producing an OAS 3.0 spec without it helped validate that the keyword was needed, and not (as some claimed) a solution looking for a problem. The best feedback is always real-world usage.

It is very excited to see JSON Schema and OAS 3.0 Schema efforts collide in such a very constructive way. I look forward to seeing the results of your very appreciated effort!

Nobody expects the v3 schema to be more of a perfect guarantee than the v2 schema (as said above, consider operationId). Just release a schema and let the dice fall where they may.

trying to break a year-long (and counting) logjam.

I hate when one developer don't want to implement a wanted and useful feature because some other developer might "use it wrong" according to their own "dogma".

It is important to remain respectful even when through disagreement in the open source community.

my use of the schema would have nothing to do with validation but generating typescript definition and having more accurate code editor completion/suggestions.

One of the reasons I initially pushed back on the creation of a JSON Schema for V3 is because I feared that people would try to use it as a document validator. However, I was convinced by other TSC members that there were valid uses of a schema beyond validation.

the errors that you get from JSON schema can sometimes be very confusing. I wanted to be able to generate errors that could easily be understood to speed up debugging time.

Maybe one day, JSON Schema would be able to express all the constraints in the OpenAPI spec, but I suspect some are going to be really hard.

Release early, release often! One out of two won't be bad :-)

without a schema, you do not have a spec, you have an aspiration.

When we do release a final version of JSON Schema, please do not use JSON Schema to guarantee an OpenAPI document is valid. It cannot do that. There are numerous constraints in the written specification that cannot be expressed in JSON Schema.

To keep it regular, I'd like to avoid hand-edits to the schema as much as possible

I'd also love to see a JSON schema along with the specification. I don't really trust myself to be able to accurately read the spec in its entirely, so for 2.0 I fell back heavily on using the included schemas to verify that what I'm generating is actually intelligible (and it worked, they caught many problems).

I hope this doesn't seem too much like a content-free +1, but

it's syntactically correct, but it will check that none parameters are valid, just because additionalProperties work at siblings level, and no enter inside of allOf

What I want is to use "additionalProperties: false" to validate a union of schemas, but it seems it isn't possible. I already tried with sevaral different combination, but I didn't make it works.

additionalProperties: false works on it, but not along with allOf, because only validate one schema or another.

allOf takes an array of object definitions that are validated independently but together compose a single object.

The latest (draft 2020-12) version of JSON Schema supports the unevaluatedProperties vocabulary (see here). This is quite a useful feature, and facilitates stricter validation while composing properties from multiple sub-schemas (using e.g. allOf) than would otherwise possible.

OAS 3.1 uses all of JSON Schema draft 2020-12 including unevaluatedProperties. You won't find direct references to unevealuatedProperties in the OAS spec because it links to the JSON Schema spec instead of duplicating it's contents.

This object is a superset of the JSON Schema Specification Draft 2020-12.

JSONPath contains verbiage that allows for an empty array to be returned in the case that nothing was found, but the primary return in these cases is false.

I had not thought about whether dropping means "defined but empty" or "not present at all"

I have refactored the schema to use allOf, oneOf, and unevaluatedProperties, which not only dramatically shrank the file (1500 lines down to 845) but allowed a different approach consisting of a number of "mix-in" schemas grouping commonly used fields, which are then referenced throughout a set of object schemas.

Multiple different people have been discussing multiple different problems, and asking for examples of the other problems, talking past each other and generally this thread got to an unreadable point due to this confusion.

The discussion here can get very fast-paced. I am trying to periodically pause it to allow new folks, or people who don't have quite as much time, to catch up. Please feel free to comment requesting such a pause if you would like to contribute but are having trouble following it all.

As a reminder, the JSON Schema is not the source of truth for the Specification. In cases of conflicts between the Specification itself and the JSON Schema, the Specification wins. Also, some Specification constraints cannot be represented with the JSON Schema so it's highly recommended to employ other methods to ensure compliance.

This is confusing spec language. In particular the last sentence is too hard to follow - the definitions can't be the same and not be the same.

JSON Schema allows for additionalProperties both a boolean or an object value. true is interpreted as "additional properties follow no restrictions", false means "no additional restrictions", and an object is interpreted as a JSON schema applied to the property values (the empty object is thus equivalent to true).

Good code is its own best documentation. As you’re about to add a comment, ask yourself, "How can I improve the code so that this comment isn’t needed?". Improve the code and then document it to make it even clearer.

Also be aware of how Ruby handles aliases and inheritance: an alias references the method that was resolved at the time the alias was defined; it is not dispatched dynamically.

Prefer alias when aliasing methods in lexical class scope as the resolution of self in this context is also lexical, and it communicates clearly to the user that the indirection of your alias will not be altered at runtime or by any subclass unless made explicit.

Booleans and nil can be compared by identity and therefore the `be` matcher is preferable as it is a more strict test.

git -c log.follow= log: that will unset log.follow, just for that one git log instance.

If we ever moved a file to a different location or renamed it, all its previous history is lost in git log, unless we specifically use git log --follow. I think usually, the expected behavior is that we'd like to see the past history too, not "cut off" after the rename or move, so is there a reason why git log doesn't default to using the --follow flag?

Note: Git 2.6+ (Q3 2015) will propose that in command line: see "Why does git log not default to git log --follow?" Note: Git 2.6.0 has been released and includes this feature. Following path changes in the log command can be enabled by setting the log.follow config option to true as in: git config log.follow true

If you want to replace many blobs, trees or commits that are part of a string of commits, you may just want to create a replacement string of commits and then only replace the commit at the tip of the target string of commits with the commit at the tip of the replacement string of commits.

As of Git 1.6.5, the more flexible git replace has been added, which allows you to replace any object with any other object, and tracks the associations via refs which can be pushed and pulled between repos.

Graft points or grafts enable two otherwise different lines of development to be joined together. It works by letting users record fake ancestry information for commits. This way you can make git pretend the set of parents a commit has is different from what was recorded when the commit was created.

The next step is to graft the two branches together, skipping the two commits which renamed the folder. (Otherwise there will be a weird jump where everything is deleted and recreated.)

This repair fitting is designed to seal leaks at a glue joint for Sch.40 pipe.

Calling the same filter multiple times with different options will not work, since the last filter definition will overwrite the previous ones.

IMO passive vs. active voice has no impact on the ambiguousness of the sentence.

This hasn't yet been scheduled, but we're tracking it on our backlog as something we want to do this year. A few months ago, we arranged for additional capacity to address items like this that have waited for so long. Now that additional capacity is available, it's just a matter of scheduling based on relative priority. We're anxious to get this one done, and I hope to soon have a clearer date to post here.

Giving ~, YAML’s representation of nil, as a value cancels the setting of the corresponding key in the parent configuration.

the AST version of the code is vastly superior IMHO. The knowledge about what constitutes an access modifier is already encoded in the system so it makes more sense to just call the method to test the type of node. The regexp solution may be expedient, but it's not as resilient to change -- if new access modifiers are added in the future it's very likely this code won't be updated, which will be the source of a bug.

When you google the problem and realized your answer is how you fix it: #557 (comment)

asdf is not intended to be a system package manager. It is a tool version manager.

Just because you can create a plugin for any tool and manage its versions with asdf, does not mean that is the best course of action for that specific tool.

Shims are just tiny wrappers created by asdf that just forward execution to the real versioned executables installed by asdf. This way, asdf has a single shims directory added to your PATH and has no need of mangling the PATH for every installed version.

To criticise Rust for being a complex language misses the point: it's designed to be expressive, which means having a lot of features, and in many situations that's what you want from a programming language.

For example, whereas C programmers have argued for years about where to put their brackets, and whether code should be indented with tabs or spaces, both Rust and Go eliminate such issues completely by using a standard formatting tool (gofmt for Go, rustfmt for Rust) which rewrites your code automatically using the canonical style. It’s not that this particular style is so wonderful in itself: it’s the standardisation which Rust and Go programmers appreciate.

If you like the functional style of programming, though, you’ll find a lot more facilities for it in Rust, because Rust has a lot more facilities than Go in general.

Rust is integrated with Firefox. This integration is cleverly dubbed ‘oxidation’ and has a whole wiki page dedicated to the project. 

The single-line commit trailers ^Update-Info: *(.*) on version tagged commits are used to assemble a small changelog during update, which is presented to the user. The single line can contain important information/links to relevant fixes and changes.

Ruby's keyword args work a little differently than similar implementations (selectors in Objective C, for instance). The value on the right-hand side of the colon is the default, not the local name.

an equivalent of R's signif function in Ruby.

This rounds to the specific number of decimal places, but what's wanted is to round to a specific number of significant digits.

R is the implementation of the S programming language combined with lexical scoping semantics inspired by Scheme.

The S language is often the driver programming language for research in statistical methodology, and R gives an Open Source route to participation in that activity.