feat: Unable to run the project

Describe the feature you'd like to request
The documentation states:
npm i novel

and then:
import { Editor } from "novel";

export default function App() {
  return (
     <Editor />
  )
}

but doing that and following all the documentation leads you to not run the project at all as is likely is missing a bunch of imports and libraries needed for a headless solution.
Describe the solution you'd like to see
A more polish documentation and maybe a package or set of commands that allow to import all needed packages and dependecies.
Additional information
No response

I was struggling with this documentation too. I managed to solve it (with tailwindcss).
First, install this packages:
pnpm add novel
pnpm add @vercel/blob
pnpm add class-variance-authority
pnpm add lucide-react
If you don't have @tailwindcss/typography follow this link.
Then you need extensions to make novel work. Follow this link and create extensions.ts.
Finally, you can use novel as follows:
<EditorRoot><EditorContent extensions={defaultExtensions}></EditorContent></EditorRoot>

I'm struggling to import novel/extensions due to some TS error. My Next.js project has:
    "module": "esnext",
    "moduleResolution": "node",

Which is standard and hasn't caused any issue with other libraries. Specifically for novel/extensions, I get this:
Cannot find module 'novel/extensions' or its corresponding type declarations.
  There are types at '/Users/arielweinberger/Development/academia-helper/node_modules/novel/dist/extensions.d.ts', but this result could not be resolved under your current 'moduleResolution' setting. Consider updating to 'node16', 'nodenext', or 'bundler'.ts(2307)

I assume this is related to using exports in package.json?

I was struggling with this documentation too. I managed to solve it (with tailwindcss).

Hello ahmeterenodaci - can you share the code you used to solve it?
I followed your steps and installed @vercel/blob, class-variance-authority in addition to novel ( I already had tailwind and lucide-react installed). And created the extensions.ts and imported it into my editor.
Here's my editor:
'use client';

import { defaultExtensions } from '@/lib/extensions';
import { EditorContent, EditorRoot, JSONContent } from 'novel';
import { useState } from 'react';

const NovelEditor = () => {
  const [content, setContent] = useState<JSONContent | undefined>(undefined);
  const extensions = [...defaultExtensions];

  return (
    <EditorRoot>
      <EditorContent
        extensions={extensions}
        initialContent={content}
        onUpdate={({ editor }) => {
          const json = editor.getJSON();
          setContent(json);
        }}
      >
        {/* Add the required children prop */}

{/* Add any additional content or placeholder */}

      </EditorContent>
    </EditorRoot>
  );
};

export default NovelEditor;

Can you share the editor you're using? Thanks!

I was struggling with this documentation too. I managed to solve it (with tailwindcss).

Hello ahmeterenodaci - can you share the code you used to solve it?
I followed your steps and installed @vercel/blob, class-variance-authority in addition to novel ( I already had tailwind and lucide-react installed). And created the extensions.ts and imported it into my editor.
Here's my editor:
'use client';

import { defaultExtensions } from '@/lib/extensions';
import { EditorContent, EditorRoot, JSONContent } from 'novel';
import { useState } from 'react';

const NovelEditor = () => {
  const [content, setContent] = useState<JSONContent | undefined>(undefined);
  const extensions = [...defaultExtensions];

  return (
    <EditorRoot>
      <EditorContent
        extensions={extensions}
        initialContent={content}
        onUpdate={({ editor }) => {
          const json = editor.getJSON();
          setContent(json);
        }}
      >
        {/* Add the required children prop */}

{/* Add any additional content or placeholder */}

      </EditorContent>
    </EditorRoot>
  );
};

export default NovelEditor;

Can you share the editor you're using? Thanks!

Is this worked for you ?

Sorry for late reply. I tried your code and its worked for me. If you don't have any error it means it's working but you might want to add some css like this:
    .ProseMirror {
      @apply p-12 px-8 sm:px-12;
    }

    .ProseMirror .is-editor-empty:first-child::before {
      content: attr(data-placeholder);
      float: left;
      color: hsl(var(--muted-foreground));
      pointer-events: none;
      height: 0;
    }
    .ProseMirror .is-empty::before {
      content: attr(data-placeholder);
      float: left;
      color: hsl(var(--muted-foreground));
      pointer-events: none;
      height: 0;
    }

    /* Custom image styles */

    .ProseMirror img {
      transition: filter 0.1s ease-in-out;

      &:hover {
        cursor: pointer;
        filter: brightness(90%);
      }

      &.ProseMirror-selectednode {
        outline: 3px solid #5abbf7;
        filter: brightness(90%);
      }
    }

    .img-placeholder {
      position: relative;

      &:before {
        content: "";
        box-sizing: border-box;
        position: absolute;
        top: 50%;
        left: 50%;
        width: 36px;
        height: 36px;
        border-radius: 50%;
        border: 3px solid var(--novel-stone-200);
        border-top-color: var(--novel-stone-800);
        animation: spinning 0.6s linear infinite;
      }
    }

    @keyframes spinning {
      to {
        transform: rotate(360deg);
      }
    }

    /* Custom TODO list checkboxes – shoutout to this awesome tutorial: https://moderncss.dev/pure-css-custom-checkbox-style/ */

    ul[data-type="taskList"] li > label {
      margin-right: 0.2rem;
      user-select: none;
    }

    @media screen and (max-width: 768px) {
      ul[data-type="taskList"] li > label {
        margin-right: 0.5rem;
      }
    }

    ul[data-type="taskList"] li > label input[type="checkbox"] {
      -webkit-appearance: none;
      appearance: none;
      background-color: hsl(var(--background));
      margin: 0;
      cursor: pointer;
      width: 1.2em;
      height: 1.2em;
      position: relative;
      top: 5px;
      border: 2px solid hsl(var(--border));
      margin-right: 0.3rem;
      display: grid;
      place-content: center;

      &:hover {
        background-color: hsl(var(--accent));
      }

      &:active {
        background-color: hsl(var(--accent));
      }

      &::before {
        content: "";
        width: 0.65em;
        height: 0.65em;
        transform: scale(0);
        transition: 120ms transform ease-in-out;
        box-shadow: inset 1em 1em;
        transform-origin: center;
        clip-path: polygon(14% 44%, 0 65%, 50% 100%, 100% 16%, 80% 0%, 43% 62%);
      }

      &:checked::before {
        transform: scale(1);
      }
    }

    ul[data-type="taskList"] li[data-checked="true"] > div > p {
      color: var(--muted-foreground);
      text-decoration: line-through;
      text-decoration-thickness: 2px;
    }

    /* Overwrite tippy-box original max-width */

    .tippy-box {
      max-width: 400px !important;
    }

    .ProseMirror:not(.dragging) .ProseMirror-selectednode {
      outline: none !important;
      background-color: var(--novel-highlight-blue);
      transition: background-color 0.2s;
      box-shadow: none;
    }

    .drag-handle {
      position: fixed;
      opacity: 1;
      transition: opacity ease-in 0.2s;
      border-radius: 0.25rem;

      background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 10 10' style='fill: rgba(0, 0, 0, 0.5)'%3E%3Cpath d='M3,2 C2.44771525,2 2,1.55228475 2,1 C2,0.44771525 2.44771525,0 3,0 C3.55228475,0 4,0.44771525 4,1 C4,1.55228475 3.55228475,2 3,2 Z M3,6 C2.44771525,6 2,5.55228475 2,5 C2,4.44771525 2.44771525,4 3,4 C3.55228475,4 4,4.44771525 4,5 C4,5.55228475 3.55228475,6 3,6 Z M3,10 C2.44771525,10 2,9.55228475 2,9 C2,8.44771525 2.44771525,8 3,8 C3.55228475,8 4,8.44771525 4,9 C4,9.55228475 3.55228475,10 3,10 Z M7,2 C6.44771525,2 6,1.55228475 6,1 C6,0.44771525 6.44771525,0 7,0 C7.55228475,0 8,0.44771525 8,1 C8,1.55228475 7.55228475,2 7,2 Z M7,6 C6.44771525,6 6,5.55228475 6,5 C6,4.44771525 6.44771525,4 7,4 C7.55228475,4 8,4.44771525 8,5 C8,5.55228475 7.55228475,6 7,6 Z M7,10 C6.44771525,10 6,9.55228475 6,9 C6,8.44771525 6.44771525,8 7,8 C7.55228475,8 8,8.44771525 8,9 C8,9.55228475 7.55228475,10 7,10 Z'%3E%3C/path%3E%3C/svg%3E");
      background-size: calc(0.5em + 0.375rem) calc(0.5em + 0.375rem);
      background-repeat: no-repeat;
      background-position: center;
      width: 1.2rem;
      height: 1.5rem;
      z-index: 50;
      cursor: grab;

      &:hover {
        background-color: var(--novel-stone-100);
        transition: background-color 0.2s;
      }

      &:active {
        background-color: var(--novel-stone-200);
        transition: background-color 0.2s;
        cursor: grabbing;
      }

      &.hide {
        opacity: 0;
        pointer-events: none;
      }

      @media screen and (max-width: 600px) {
        display: none;
        pointer-events: none;
      }
    }

    .dark .drag-handle {
      background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 10 10' style='fill: rgba(255, 255, 255, 0.5)'%3E%3Cpath d='M3,2 C2.44771525,2 2,1.55228475 2,1 C2,0.44771525 2.44771525,0 3,0 C3.55228475,0 4,0.44771525 4,1 C4,1.55228475 3.55228475,2 3,2 Z M3,6 C2.44771525,6 2,5.55228475 2,5 C2,4.44771525 2.44771525,4 3,4 C3.55228475,4 4,4.44771525 4,5 C4,5.55228475 3.55228475,6 3,6 Z M3,10 C2.44771525,10 2,9.55228475 2,9 C2,8.44771525 2.44771525,8 3,8 C3.55228475,8 4,8.44771525 4,9 C4,9.55228475 3.55228475,10 3,10 Z M7,2 C6.44771525,2 6,1.55228475 6,1 C6,0.44771525 6.44771525,0 7,0 C7.55228475,0 8,0.44771525 8,1 C8,1.55228475 7.55228475,2 7,2 Z M7,6 C6.44771525,6 6,5.55228475 6,5 C6,4.44771525 6.44771525,4 7,4 C7.55228475,4 8,4.44771525 8,5 C8,5.55228475 7.55228475,6 7,6 Z M7,10 C6.44771525,10 6,9.55228475 6,9 C6,8.44771525 6.44771525,8 7,8 C7.55228475,8 8,8.44771525 8,9 C8,9.55228475 7.55228475,10 7,10 Z'%3E%3C/path%3E%3C/svg%3E");
    }


Add missing identity matrix to the equation

This closes #446.

Docs Build status updates of commit 44add7d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/concepts/multiple-qubits.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Added: route logic, redux, api setup, login

route logic
login
api setup
redux setup

Added: pnotify


Added simple guide for adding non-timeseries metrics

The guide is currently very rudimentary and requires that a new vue be created for each type of endpoint

Thank you!


feat(entity): add basic support for id pattern when querying entities #381

I think that getEntities of Neo4jRepository needs a refactoring (i.e. Detekt ComplexMethod), should it be done in this PR ?

I think that getEntities of Neo4jRepository needs a refactoring (i.e. Detekt ComplexMethod), should it be done in this PR ?

no, add an issue.


Unable to use double quotes with gpfdist

From @sgulzar-pivotal on March 15, 2016 10:18
One of the prospects is trying to create a stream and passing the table name in double quotes (Their tables are case sensitive)
file --dir="/home/gpadmin/sppglabtests/" --pattern="testin.csv" --mode="lines" | gpfdist --columnDelimiter="," --dbHost="10.x.x.1" --dbName="spdb" --table="Apple" --mode="INSERT"

The stream are failing with the following error:
SNAP ERROR sqlTaskScheduler-1 gpfdist.GPFDistMessageHandler - Error in load
org.springframework.jdbc.BadSqlGrammarException: StatementCallback; bad SQL grammar [DROP EXTERNAL TABLE Apple_ext_8cab8bd5_1603_4f28_99e6_2db22583c9ff]; nested exception is org.postgresql.util.PSQLException: ERROR: table "apple_ext_8cab8bd5_1603_4f28_99e6_2db22583c9ff" does not exist

Copied from original issue: spring-cloud/spring-cloud-stream-modules#218

From @jvalkeal on March 29, 2016 9:1
Not really sure what's going on here as I can't reproduce these errors in gpfdist from dataflow(not sure if it'd be any different in XD).
With gpdb/hawq table names are not case sensitive.

We can close this issue Carlos Q and myself has added this feature in the SpringXD 1.3.2.

This issue was moved to spring-cloud-stream-app-starters/gpfdist#5


Update VMImage to macOS 15

Upgrade macOS version to macOS-10.15
Sunset  sunset 32-bit python jobs
Update version of xcode.
https://github.com/Azure/azure-sdk/issues/1014

/azp run azure-uamqp-python - openssl


Use smaller ints for bitmap_t if applicable

Hi, a small pr from me as was discussed earlier.
I was fighting with integer promotion for some time and the only solution I found so far is to use casts for non-const expressions. Otherwise we get popcount() overload ambiguity...
Please take a look and probably you could suggest a better solution for that :)

Codecov Report

Merging #69 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #69      +/-   ##
==========================================
+ Coverage   94.49%   94.49%   +<.01%
==========================================
  Files          84       84
  Lines        6902     6903       +1
==========================================
+ Hits         6522     6523       +1
  Misses        380      380

Impacted Files
Coverage Δ

immer/detail/hamts/champ.hpp
93.98% <100%> (ø)
:arrow_up:

immer/detail/hamts/node.hpp
97.27% <100%> (ø)
:arrow_up:

immer/detail/hamts/bits.hpp
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Hi, any updates here?

Nope, sorry!

Very sorry I neglected this for so long! I kind of got into other stuff and forgot about it... Sorry!
I'd be happy to merge this. @fedormatantsev, do you have time to resolve the conflicts or shall I do it myself?
Thanks a lot!!!

Wow, I have forgotten about this one as well :)
I'll take a look sometime this week
пн, 13 июл. 2020 г. в 12:18, Juanpe Bolívar<EMAIL_ADDRESS>
Very sorry I neglected this for so long! I kind of got into other stuff
and forgot about it... Sorry!
I'd be happy to merge this. @fedormatantsev
https://github.com/fedormatantsev, do you have time to resolve the
conflicts or shall I do it myself?
Thanks a lot!!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arximboldi/immer/pull/69#issuecomment-657434345, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AIW3D2Q7LQQY7PBFSHOARGLR3LGNPANCNFSM4GJISFXQ
.

Awesome! Thanks!
Fedor Matantsev<EMAIL_ADDRESS>writes:

Wow, I have forgotten about this one as well :)
I'll take a look sometime this week
пн, 13 июл. 2020 г. в 12:18, Juanpe Bolívar<EMAIL_ADDRESS>
Very sorry I neglected this for so long! I kind of got into other stuff
and forgot about it... Sorry!
I'd be happy to merge this. @fedormatantsev
https://github.com/fedormatantsev, do you have time to resolve the
conflicts or shall I do it myself?
Thanks a lot!!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arximboldi/immer/pull/69#issuecomment-657434345, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AIW3D2Q7LQQY7PBFSHOARGLR3LGNPANCNFSM4GJISFXQ
.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/arximboldi/immer/pull/69#issuecomment-657463237

--
∿∿∿  https://sinusoid.al
∿∿∿  https://sinusoid.es

Yeah, I definitely want to bring this PR to finished state finally :)
On Mon, Jul 27, 2020, 21:13 Juanpe Bolívar<EMAIL_ADDRESS>wrote:

@arximboldi commented on this pull request.
In immer/detail/hamts/champ.hpp
https://github.com/arximboldi/immer/pull/69#discussion_r461077387:

@@ -129,11 +129,11 @@ struct champ
for (auto i = count_t{}; i < max_depth; ++i) {
auto bit = bitmap_t{1u} << (hash & mask);
if (node->nodemap() & bit) {

           auto offset = popcount(node->nodemap() & (bit - 1));

           auto offset = popcount(static_cast<bitmap_t>(node->nodemap() & (bit - 1)));

I like this latter approach! Do you want to do it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arximboldi/immer/pull/69#discussion_r461077387, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AIW3D2QLDCPYDUNPWMQC3FTR5W7UJANCNFSM4GJISFXQ
.

Codecov Report

Merging #69 into master will decrease coverage by 0.12%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #69      +/-   ##
==========================================
- Coverage   94.62%   94.49%   -0.13%
==========================================
  Files         102       84      -18
  Lines        9947     6903    -3044
==========================================
- Hits         9412     6523    -2889
+ Misses        535      380     -155

Impacted Files
Coverage Δ

immer/detail/hamts/bits.hpp
100.00% <100.00%> (ø)

immer/detail/hamts/champ.hpp
93.98% <100.00%> (-0.61%)
:arrow_down:

immer/detail/hamts/node.hpp
97.27% <100.00%> (+0.50%)
:arrow_up:

immer/detail/rbts/visitor.hpp
66.66% <0.00%> (-33.34%)
:arrow_down:

immer/map.hpp
91.17% <0.00%> (-6.75%)
:arrow_down:

immer/detail/rbts/rrbtree.hpp
87.22% <0.00%> (-6.31%)
:arrow_down:

immer/detail/util.hpp
75.00% <0.00%> (-3.44%)
:arrow_down:

immer/detail/rbts/operations.hpp
94.88% <0.00%> (-0.79%)
:arrow_down:

immer/detail/arrays/no_capacity.hpp
89.28% <0.00%> (-0.57%)
:arrow_down:

... and 89 more

Continue to review full report at Codecov.

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

Hi, I've introduced node_t::*_count() set of methods that is similar to existing node_t::collision_count(), this way it feels to be in the proper place.

I really like it! Thanks @fedormatantsev! However Travis seems to not be happy about the changes :disappointed:  https://travis-ci.org/github/arximboldi/immer/builds/712629810

Yeah, I'm using corporate laptop currently and I have problems with setting up dev environment to run tests, I'm only doing examples build locally :)

Cool, it worked now, merging!


reduce ignition server scope

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/retest

my team will pickup prs if changes are necessary (as far as commit messages, etc)

Thanks!
/label tide/merge-method-squash
/approve
/lgtm

/cherry-pick release-4.12


Unequal height

Describe the bug
A card for one of the contributors has a greater height than others.
Screenshot

im on it

Assigned : @harry-hov

done

Solved: #41


Form Recognizer: Design Clients & Namespaces

Additional questions from Krzysztof to address as part of this:

Should scenario specific clients be in one namespace or many namespaces?

Should the custom client be in separate namespace from the scenario specific clients?

Multiple Clients for Custom/CustomModel/Layout/Receipt
Possible approaches, in order of FR team preference:
•	Single client with nested accessors (either properties or methods) for specialized areas
o	PRO: Clear separation of concerns
o	PRO: Reuse code and docstrings
o	CON: Deeply nested accessors
o	CON: sub-clients discouraged and/or not common in Azure SDKs
•	Multiple clients for each specialized area
o	PRO: Clear separation of concerns.
o	PRO: Reuse code and docstrings
o	CON: Duplicate XyzClientOptions for each XyzClient
o	CON: Multiple entry points for user
•	Single “flat” client with all methods available at once
o	PRO: Single entry point for user
o	PRO: Single client options class
o	CON: Verbose method names
o	CON: Duplicated method definitions and docstrings
o	CON: Duplicated method parameter for hierarchical resources (modelId)
Status: Switched from “Single client with nested accessors” to “Multiple clients for each specialized area”. Pending review.
Priority: high
Effort: high

Consider namespaces and whether to split into packages as part of this.

Status: proposed design; will discuss with service team and arch board.  @mayurid

New feedback from Krzysztof - Custom to go in a Custom namespace, all the prebuilt in the main namespace.  Model types to go in Models, except that Model means something specific in ML and we should consider this.

I left a comment in apiview but it’s worth considering that custom accounts for about 60% of our current traffic. Should we relegate our most used service to a sub namespace?

It's a good question.  Do we think that this will be the same pattern for customer who start using the service after GA?

Is it ok to not have a FormRecognizerClient in the root namespace.  We’ll UX test this and look at feedback on preview 1, but both Python and .NET will keep the client structure they currently have for preview 1.

Updating this issue to reflect current considerations:
o	Option 1: FormRecognizerClient and CustomTrainingClient as in current apiview.  Primary concern is that customer may not know which object to start from and CustomTrainingClient is less discoverable.
o	Option 2: All methods in a single FormRecognizerClient, similar to Sandeep’s suggestion, mirroring the current REST API.
o	Option 3: Since the first step for all use cases is to train/get a model, place the model creation/retrieval/management methods in FormRecognizerClient and have Recognize methods on the returned FormModel classes.  This is more object oriented, but deviates from current undocumented SDK conventions.

Addressed in new design - will reopen if architects suggest changes.


Table Rendered docs

Here is the code I changed up to make the table version of the docs.  Let me know if you want to discuss or don't like anything that I changed.

Nice job with this! As mentioned on discord, I think we can clean this up quite a bit. Let's add something like this:
_TABLE_CSS = """<style>
    table { border-collapse: collapse; border:thin solid #dddddd; margin: 25px 0px; ; }
    table tr:first-child { background-color: #FFF}
    table thead th { background-color: #eee; color: #000; text-align: center;}
    tr, th, td { border: 1px solid #ccc; border-width: 1px 0 0 1px; border-collapse: collapse;
    padding: 5px; }
    tr:nth-child(even) {background: #eee;}</style>"""

And then in doc():
    else:
        try: page.page({'text/html': output + _TABLE_CSS})
        except: display(Markdown(md))

This gives us a pretty close rendering to that of show_doc as a pop-out in Jupyter

added.  I did use display(HTML(output + _TABLE_CSS)) rather than Markdown for the except, but let me know if you don't like it and I'll swap back.

Let's keep it back to the Markdown :)

Should we do anything to the colab output?  Does it make sense to add your custom css there as well?

Yup, in_colab should have it too. Nice catch.

Ok, I believe all changes have been made now

One more little bit and we should be fine.
Currently we still show the table for returns even if there is no return documentation provided. We should not do so if there is no documentation (currently nbverbose has a conditional for that).

So we should keep the existing behavior in that way :)
Also show_doc needs the in_colab treatment as well


NSError conformance to Debuggable breaks type casting

The latest 3.6.0 release breaks type casting, xcode mentions that a forced cast from Error to Debuggable always succeeds. I use this quite a bit in my unit tests, but i also noticed that the Logger also notices this, saying that the case is already handled, but i don't think it actually is:
public func report(error e: Error,...
switch e {
    ...
    default:
        let reason: String
        switch e {
            case let localized as LocalizedError: reason = localized.localizedDescription
            // Case is already handled by previous patterns; consider removing it
            case let convertible as CustomStringConvertible: reason = convertible.description
            default: reason = "\(e)"
        }

Looks like conforming NSError to Debuggable causes incorrect type casting. A quick test;
enum DebuggableTest: Debuggable {
    case foo

    var identifier: String {
        switch self {
        case .foo: return "foo"
        }
    }

    var reason: String {
        switch self {
        case .foo: return "FooBar"
        }
    }

    static func test() throws {
        throw DebuggableTest.foo
    }
}

func testDebuggableTest() throws {
    // Works fine, no type casting happening
    XCTAssertEqual(DebuggableTest.foo.identifier, "foo")

    XCTAssertThrowsError(try DebuggableTest.test(), "test") { err in
        // err is Error
        // Notices that a force downcast from `Error` to `Debuggable` always succeeds, so Error probably conforms to NSError?
        // Test fails, because the identifier is "0", should be "foo"
        XCTAssertEqual(DebuggableTest.foo.identifier, (err as! Debuggable).identifier)
    }
}

Is there somewhere where Error actually conforms to NSError? Since Xcode/Swift notices that the downcast always succeeds.
It doesn't actually creates a DebuggableTest but just uses the identifier getter from the NSError extension.
Is there another way to cast i should use?

NSError actually does conform to Error according to the swift docs. But that doesn't mean that every Error is a NSError, basically that's what the compiler is complaining about. But yeah the type cast should work then, right?
Since identifier and reason are in the protocol, not a protocol extension, it should use the implemented methods by the custom errors, not those of NSError, right?

That's very strange. It seems almost like let downcast: Error = DebuggableTest.foo is converting the error to an NSError. I wonder if this happens on Linux.
Maybe instead of conforming NSError to debuggable, we need to add special NSError cases anywhere we print out errors (ErrorMiddleware, Log error, etc). @MrLotU any ideas?
Also, which Swift version are you on @terwanerik? I wonder if this happens with latest Swift 5.

Yeah really strange indeed.. Also happening on Linux/Docker, found the problem because the CI stopped working on Docker (clean install every time).
Running on Swift 4.2.1!

@tanner0101 For now, I think we should revert the NSError conformance to Debuggable, since it's breaking and get a "better" solution in place for Vapor 4, and than we can really think about how we want to do that (adding extra cases or smth)


Fix writing to an IO with no external_encoding

A file-IO has no external_encoding by default, so that rb_to_encoding() fails with a TypeError.
This regression was introduces in commit 2e260f53e6b84b8f9c1b115b0ded85eebc8155d7.
Fixes #2752

Thank you!


feat: introduce new schema referencing standard

Abstract
The current reference object is no longer sufficient as we need to support non-JSON references, i.e. we can no longer solely rely on JSON Reference. The main problem becomes that AsyncAPI is defined with JSON/YAML and you are referencing something that does not conform to this format. Hence making it though to support. This new standard aims to solve this problem.

Description
This proposal is part of a larger issue, that have been highlighted in multiple GitHub issues, and this PR extends the work from @magicmatatjahu in https://github.com/asyncapi/spec/pull/797, which this PR is a followup for (to allow referencing non-JSON data structures such as Protobuf, XSD, Avro, FlatBuffer schemas, EDI, COBOL copybook, and the inevitable "cool new format").
This issue is a two parter, cause without tooling, this new standard is use-less.
Requirements for the standard:

Should always produce a valid JSON document
Should define the behavior for referencing non-JSON data in a JSON.
Should define the behavior for referencing JSON data
Should define the behavior for referencing JSON data that also have reference behavior, and how they interconnect / or not
Should define the behavior of nested schemas within the same file

Remaining issues/tasks to resolve

[ ] Figure out if we "solve" or define how cross references accurate should/not work together
[ ] Figure out if we want to allow JSON pointer compatibility in some format, see https://github.com/asyncapi/spec/issues/216#issuecomment-510147873
[ ] Figure out how linking should work for local references
[ ] Figure out how linking should work for relative references
[ ] Should we distinct keywords for references and links instead of just $ref?
[ ] Figure out how to handle resolving non-JSON data into JSON. Is resolving it to content enough?

FAQ
Some quick questions and answers about the current state of the standard.

How can I use fragments in non-JSON data? (https://github.com/asyncapi/spec/issues/216)

You cannot.

If it's non-JSON, then fragment MUST be ignored.

How can parsers use this?

Parsers can, based on the schema format determine whether it has the capability to parse and interpret the reference.

Related issue(s):

https://github.com/asyncapi/spec/issues/622

Moves schema format into a "schema object" instead of message containing schema and schemaFormat. Introducing defaultSchemaFormat in root AsyncAPI object. schemaFormat in message object is deprecated/removed. Does look for supporting nested references, i.e. in avro  through schemaRef that is instead of using URI fragments.
Lift the idea of schemaParse, which does not make sense as we can look at the schemaFormat and it's up to the implementation if it supports it.
Lift the idea of $remoteRef or x-remote-ref, but that does not make sense either in this setup.

https://github.com/asyncapi/spec/issues/163

Nothing specific, want to reference Flatbuffers.

https://github.com/asyncapi/spec/issues/624

Proposes remoteReference to be unparsable by the parsers and left for generators.  Lift the idea of parse and remote. Highlights some requirements:

I want to have entire .xsd imported into AsyncAPI, as a string
I want to point from AsyncAPI to a schema registry/file, not bringing in the whole thing
Provide a pointer to a particular element
Pointer to a particular element if importing the schema

https://github.com/asyncapi/spec/issues/216

Require clearification how you can utilize JSON Reference and point to non-JSON data.
Require clearification on the following:

Clarify how $ref can be applied to YAML data structures
Refer to an existing mechanism used to translate YAML to JSON
Clarify referencing mechanism for any non-JSON and non-YAML schema languages

A list of possible URI fragments that can be supported for non-JSON data.

https://github.com/asyncapi/spec/issues/694

Introduce data format bindings, that aim to solve an issue where specific arguments is needed for the schema format. schemaOptions being proposed along side https://github.com/asyncapi/spec/issues/622

https://github.com/asyncapi/spec/issues/656

Problem with no clear definition how AsyncAPI parsers can and should handle different formatSchema.

While the "JSON" in "JSON Reference" implies that it would only work for JSON-stored data, that's not actually true as it could very easily be used to reference data in any structured format.  #/people/whitlockjc/email itself is no more bound to JSON as it is to anything else, just a hierarchical combination of keys and indices. 🤷♂
Do you have any examples where using a JSON Reference is not sufficient for another structured data format, like Protobuf?  I'm not saying that JSON References are the end-all-be-all, but unless you see a limitation I'm not aware, they're pretty powerful and not as language specific as its name may imply.

I guess I could see where writing a library that was content-aware to swap between resolving in structured language X to structured language Y could be difficult.  But I could also seeing that being application/domain specific at which point you could just do this yourself.

While the "JSON" in "JSON Reference" implies that it would only work for JSON-stored data, that's not actually true as it could very easily be used to reference data in any structured format. #/people/whitlockjc/email itself is no more bound to JSON as it is to anything else, just a hierarchical combination of keys and indices. 🤷♂
Do you have any examples where using a JSON Reference is not sufficient for another structured data format, like Protobuf? I'm not saying that JSON References are the end-all-be-all, but unless you see a limitation I'm not aware, they're pretty powerful and not as language specific as its name may imply.

I would love nothing more if we could stay with JSON Reference 😄 Also why I made this draft to trigger those very discussions whether it's even needed, cause just because I see it does not mean that's how it is 😄
So here are my issues with the current standard, and these go back to the requirement for the change:

It does not define the resolution behavior of non-JSON data

As JSON pointer, does not define any logic for how to handle the referenced resource that is not JSON. The question becomes how you handle it within a JSON document. Do you load the resource and place it into a content property that is a string? Do you transform it to JSON using a standard? Or a custom behavior?

It does not define a way for implementations to know which type of reference it is

I don't read anywhere within JSON Reference that it defines how the implementation can know the type of the referenced resource. How can implementations be content-aware about how to handle the referenced resources?

It does not allow referencing non-JSON data

As the standard is solely targeted JSON data, there is a lot of implies within using the standard for non-JSON data. Even though you probably could force it to comply in some way. As you say "just a hierarchical combination of keys and indices".

It does not define the resolution behavior in multi-spec environments

For example, while you can use $ref in AsyncAPI, you can also do this in OpenAPI and JSON Schema, which have very different resolution behavior. So when you nest a JSON Schema document within AsyncAPI, how should those references be handled?
Related issues: https://github.com/asyncapi/spec/issues/655, https://github.com/asyncapi/spec/issues/656

It does not define how to handle relative references in non-JSON data (through URI fragments)

As you highlight, technically, yes you can utilize fragments, but how exactly? See https://github.com/asyncapi/spec/issues/216
Those are just the issues I can remember at the moment. One of the core reasons behind authoring it as a standard is that regardless of whether we do it, we need to build tooling to handle references within a multi-spec document. So having this as a standard just makes sense to me 🤷
@whitlockjc what would your suggestion be instead, in terms of how we should move forward to support this requirement of referencing non-JSON data? 🤔

It does not define the resolution behavior of non-JSON data

I'm not sure JSON Reference cares about the data being resolved, and in my opinion it shouldn't care.  Resolution only cares with resolving something, it doesn't care what that something is.  And in the case of JSON References, so long as the data is structured, it seems resolvable to me.  (I do wonder how one might handle XML though, where you might need to resolve properties vs. nested elements.  But I'm sure a simple convention would suffice instead of creating yet another standard or approach.)

It does not define a way for implementations to know which type of reference it is

Much like the first, the standard doesn't mention this because it doesn't care, and I question whether it should.  If you know enough about where the data is, you should be able to reason about what kind of data is there.  To me, this is highly specific to the application using the data and I'm not sure if adding complexity so that tooling can "guess" is worth it.

It does not allow referencing non-JSON data

I'm not sure I agree with this because a JSON Pointer is nothing more than a URI, a hierarchical series of steps to find something in a structured document.  The same JSON Pointer that could locate something in JSON could be used to find data in a non-JSON data format so long as it's structured.  For example, #/people/Jeremy/email/0 could work for HTML, XML, any language equivalent of a structure object, a DAG or anything else that is structured.

It does not define the resolution behavior in multi-spec environments

I'm not sure I have an opinion on this, primarily because each format owns how references are supported/treated.  For example, OpenAPI started out with bastardized support for JSON References, then started using native JSON References and now uses JSON Schema's resolution of JSON References which is custom/unique to JSON Schema.  But where I'm slightly confused is what you mean by a "multi-spec environment", what is that?
If a "multi-spec environment" just refers to storing non-AsyncAPI documents/fragments within the AsyncAPI document, I don't think there is a problem.  Reason being is that there is no reason why a JSON Reference outside of the nested spec would need to resolve into the nested spec, nor a JSON Reference in the nested spec needing to resolve outside of itself.
The content of the nested spec is immaterial to AsyncAPI, and likely just used by some external tooling which itself would need to be aware of its content.  For example, in https://github.com/asyncapi/bindings/pull/141 I propose a way to document a Cloud Pub/Sub topology using AsyncAPI.  If I were to store Protobuf into the Message Binding in hopes of having some tooling to do client/server validation based on the Protobuf, AsyncAPI shouldn't care about it and for the client/server tooling to use it, it need to be fully aware of its content so any resolution it does would play by its own rules.

It does not define how to handle relative references in non-JSON data (through URI fragments)

Whether the data is JSON or not, if it's structured the rules are the same.  Fragments will address hierarchically from the root of the enclosing document.  I really don't think JSON vs. non-JSON changes much because a structured document is hierarchical and plays by the same rules.  (Like I mentioned earlier, I could see a case for XML and similar languages to need some sort of convention to differentiate between element properties and nested child elements.)
Summary
To me, so long as the data is structured, JSON References allows a very simple way to define where something is in relationship to a document/structure so that you can resolve it.  Sure, mixed data formats adds some complexity and there could even be some sort of edge cases for structured data that has data within a container (XML properties) but since JSON References are really just dict/map/object/... with a singular $ref key/property that is itself a URI whose resolution rules are pretty clear, I don't see the need for something more complex or necessarily a short coming in JSON References.
I will look more into the examples you linked to where we might need something that I'm just not seeing.

TL;DR:

AsyncAPI can define the usage of a reference in terms of the result of applying the reference target (regardless of what kind of schema it is) rather than in terms of replacing a JSON object with the expected-to-be-JSON target.  This is a delegation, not a replacement or a merge (merge may sound tempting, but it gets horrifically messy very fast)
The fragment syntax used in the reference is determined by the media type of the representation identified by the non-fragment portion of the URI, not by the usage of the URI.
However, AsyncAPI can require that such representations be mapped into a media type that supports JSON Pointer fragments (notably, application/json technically does not support JSON Pointer fragments — you can use non-fragment JSON Pointers with it, but technically not JSON Pointer URI fragments; for that, you need some sort of application/<something>+json media type).

Apologies if I missed something in this lengthy issue, but I wanted to raise a point that has been sporadically important (and often overlooked) within many JSON Schema / JSON Pointer-related discussion about URIs and fragments:

Some quick questions and answers about the current state of the standard.

How can I use fragments in non-JSON data? (https://github.com/asyncapi/spec/issues/216)

You cannot.

If it's non-JSON, then fragment MUST be ignored.

Technically, even with application/json you MUST ignore JSON Pointer fragments, per RFC 6901 §6:

Note that a given media type needs to specify JSON Pointer as its
fragment identifier syntax explicitly (usually, in its registration [RFC6838]).
That is, just because a document is JSON does not imply
that JSON Pointer can be used as its fragment identifier syntax.  In
particular, the fragment identifier syntax for application/json is
not JSON Pointer.

(emphasis added)
Fragment resolution is controlled by the representation's media type.
This is why we (the JSON Schema project) added application/schema-instance+json, which is just application/json with JSON Pointer fragments and a "schema" media type parameter added.  application/schema+json also supports both JSON Pointer and plain-name fragments.  We are working on getting these media types properly registered so that they can be used more broadly.  I haven't looked at OpenAPI's media type details, but I assume they say something about JSON Pointer fragments and/or deferring to the JSON Schema spec for Schema Objects.
So, whether you start with application/json or some vastly different media type, technically you first need to map that representation into a media type that supports JSON Schema fragments in order to use URIs with those types of fragments.  For application/json to application/schema-instance+json, this is trivial.  For YAML, as long as it is the JSON-compatible subset it is trivial, but otherwise more challenging (that same media type project is also working on getting application/yaml finally registered).

For example, while you can use $ref in AsyncAPI, you can also do this in OpenAPI and JSON Schema, which have very different resolution behavior. So when you nest a JSON Schema document within AsyncAPI, how should those references be handled?

It does not define how to handle relative references in non-JSON data (through URI fragments)
As you highlight, technically, yes you can utilize fragments, but how exactly? See https://github.com/asyncapi/spec/issues/216

There are several parts of resolving a reference which are governed by different mechanisms, some of which can't be changed by downstream standards.

Determining the full URI of the reference, governed by RFC 3986 §5 URI-reference resolution against a base URI, which first involves establishing a base URI through the following steps in order (§-numbers from RFC 3986):

§5.1.1 Base URI embedded in content (governed by the media type in question, which may, as OpenAPI's media type does, defer to an embedded media type's rules)
§5.1.2 Base URI from encapsulating entity (governed by the encapsulating entity's rules, so in the case of OpenAPI, an embedded schema that does not declare a full (with URI scheme) base URI with $id falls back to the base URI for the OpenAPI document
§5.1.3 Base URI from the retrieval URI (if the encapsulating entity, if any, does not establish a base URI, the URI from which it is retrieved becomes the base URI)
§5.1.4 Default base URI (application-dependent)

Resolve the URI to a representation

Look up the resource by the URI's non-fragment part either in a local cache or through a network operation
Apply the fragment to the representation based on media type rules

If the representation's media type is known, then its rules govern fragment interpretation
If the media type is unknown, or if it does not support JSON Pointer fragments, then it (technically) first needs to be mapped into a representation that does

Make use of the data found through the URI, for which I know of three alternatives:

JSON Reference (inlcuding JSON Schema draft-04): replace the entire containing JSON object with the reference result
JSON Schema draft-06 & draft-07: replace the entire containing JSON Schema object with the reference result
JSON Schema draft 2019-09 & 2020-12: Use the reference result as a schema to be applied to the same instance as the containing schema

The modern (2019-09+) JSON Schema behavior can be generalized to "use the result in the same way as the containing object is used", which is essentially delegation.  That allows the context to determine the behavior of any adjacent fields in the JSON object.  For modern JSON Schema, a reference behaves like any other keyword that produces schema results.
***This means that if AsyncAPI takes a similar approach to modern JSON Schema, then you can reference other schemas as the behavior is defined in terms of the schema result, not the schema syntax. ***
As far as the base URI, in practice, an embedded JSON Schema resolves references based on the nearest same-object or parent-object $id, and if none exist, against the base URI of the encapsulating entity (e.g. the AsyncAPI or OpenAPI document's base URI).  This means that for OpenAPI 3.1, if you have a $id in your schema, you can reference #/$defs/whatever within that schema object ($defs as a sibling to $id), but you can't reference #/components/schemas/whatever in the containing OAS file without instead doing something like https://example.com/oasfile#/components/schemas/whatever
$ref outside of a schema object in OAS 3.1 always uses the OAS file's base URI.  I believe they opted to retain the "replace the containing object" behavior for those references, but you could consider "apply the target in addition to whatever else is in the containing object" approach- what that would mean would be context-specific, obviously.

I don't read anywhere within JSON Reference that it defines how the implementation can know the type of the referenced resource. How can implementations be content-aware about how to handle the referenced resources?

They are not, it is the responsibility of whoever fetched the resource to know the media type and how to interpret fragments based on that.  This means that the application that fetched the resource can also map/reinterpret the resource into a media type that supports the desired fragment behavior.  This is the step where AsyncAPI can define behavior, such as how to map XML into a JSON Pointer-friendly media type/data model.

As mentioned on the v3 spec call, I'd be interested in the tooling implications of this.  If developers are trying to parse an AsyncAPI with a standard json parsing lib, what is the behavior?

If developers are trying to parse an AsyncAPI with a standard json parsing lib, what is the behavior?

That is a totally good point. Most JSON parsers don't support JSON Reference by default. However, tools like json-schema-ref-parser does. It won't support this new referencing standard for non-JSON files, but maybe we could build a parser (also called plugins) for asyncapi files.
Otherwise, we would need to build tooling around this.
cc @jonaslagoni

I've actually thought of enabling support for this in json-refs via an option, like an experimental feature.

JSON References are really just a specialized structure (an object containing a sole property, $ref) whose value is a URI. URIs are pretty dang good at pointing to where something is, regardless of what type it is, and only the fragment is where we have an issue. Regarding the fragment, JSON References says the following: "If the representation of the referrant document is JSON, then the fragment identifier SHOULD be interpreted as a [JSON-Pointer]." So to me, we have two issues:

How do we handle the URI fragment for non-JSON "referrant documents"
How do we serialize the resolved value for non-JSON "referrant documents"

For issue 1, my opinion is that JSON Pointers work for nearly all structured data without issue or modification. Where JSON Pointers fall apart are for languages where each "node" in the data structure has information within it, like HTML/XML attributes/properties, and for non-structured data (like protobuf). I feel like our only options here are to create a JSON Pointer replacement that is language agnostic, or we use some convention to fill in the gaps.  (For example, we could easily use a @ prefix for cases where the node is not part of the data structure hierarchy but is a value within a node of the structure, like with HTML/XML. Example: #/XMLRoot/XMLChild/@attr)
For issue 2, this is where I have less of an opinion but I could definitely see a JSON representation generated from almost anything, including Protobuf. The good news is that for many of the types we know we want to work with, the problem could already be solved with off the shelve tooling:

protobuf.js
xml2js

All this being said, I would like to know exactly what is wrong with what we have now, and what we're trying to solve. Reason being is because I don't think JSON References as they exist now are far off the mark of what we need, other than the lack of JSON Pointers working for everything we want.

I realize the "JSON" in "JSON Pointer" and "JSON Reference" implies that the containing document is JSON and the referrant document is JSON. But the structure and syntax of these items are by no means tied to just JSON and there is no reason we can't use what's there as-is regardless of the syntax of the containing/referrant documents. That's the point I'm making.

The more I think about it, the less I care about it.  "JSON *" implies JSON-only and if we are looking to get away from that, to me it looks like rewriting the related JSON-specific drafts/specs and figuring out a way to replace them with a language-agnostic equivalent is the best solution. But I do think we could start that in a much simpler way by using the JSON-specific drafts/specs as a base and using a convention to flesh out what we might eventually bubble up to a draft/spec.

But the structure and syntax of these items are by no means tied to just JSON and there is no reason we can't use what's there as-is regardless of the syntax of the containing/referrant documents

Reading the specification with no in-depth knowledge, I simply fail to see how this can be interpreted from the standard, do you mind clarifying how you see this? :sweat_smile: There are numerous places within the standard that explicitly state it has to be JSON, RFC4627, not an arbitrary structure that is not tied to JSON. Abstract defines JSON value to reference another value in a JSON document, section 3: `which identifies the location of the JSON value being referenced, etc. Nowhere within that does it state anything about non-JSON referenced resources.
With a bit of creative freedom, I might agree with you and especially since you have such an in-depth knowledge of it, that you can rather easily simply replace JSON with any structure and it will work in most cases. But from the standards perspective and for someone who cannot read it from the standard I would argue that the current one is not sufficient.

But I do think we could start that in a much simpler way by using the JSON-specific drafts/specs as a base and using a convention to flesh out what we might eventually bubble up to a draft/spec.

In my eyes we are, but I might be misunderstanding the term. This standard is nothing more than JSON Reference turned agnostic, which takes care of the first issue with JSON reference not (in my words) allowing referring to non-JSON resources. It does not specifically define how to handle complex fragments and resolvent but leaves this up to the standard that incorporates it.
I.e. fragments are something the AsyncAPI spec (or any other) needs to specifically define, see https://github.com/asyncapi/spec/pull/825#discussion_r970658915.
For resolvement/conversion of non-JSON structures to JSON I simply defined it as having to be placed into a string. Still not sure about this approach and why it's part of the remaining issues to figure out.
I fail to see where we can simplify this any further 🧐 Do you have any suggestions?

In JSON terms, a JSON Reference is an Object that has a singular $ref key. Every programming language has the ability to represent this. That's the reason why I say that while JSON Reference is JSON-specific, its concepts are not. I could easily represent a JSON Reference in any programming language, either using their Object equivalent (Java Maps, Python dicts, Golang maps, ...) or by using their type system (Java classes, Python classes, Golang structs, ...). There is a reason why most languages have built-in support for serialization to/from JSON to native language structures, because at the end of the day JSON is nothing more than a structured document with a simple type system that is represented in all programming languages.
So if the overall structure of a JSON Reference isn't necessarily unique or specific to JSON, I stand by what I said.
In JSON terms, a JSON Pointer is a String containing "containing a sequence of zero or more reference tokens, each prefixed by a '/' (%x2F) character." Again, there is nothing about this that is JSON-specific in its syntax nor in how resolution works because what makes a JSON Pointer resolvable is the fact that the JSON document is itself a structured document. You could easily parse a JSON Pointer and resolve an XML value, a value in a hierarchical data structure like a in a specific language, etc.
So if a JSON Pointer is really just a collection of "reference tokens" in a language agnostic format, and the requirement of resolution is a hierarchical data structure, neither of these requirements are unique or specific to JSON and I stand by what I said.
At the end of the day, JSON References provide a language agnostic way of defining a reference, despite it having "JSON" in its name.  And JSON Pointers provide a language agnostic way of defining the hierarchical collection of reference tokens needed to resolve data in a hierarchical data structure, despite it having "JSON" in its name.

I've tried to read all the comments and understand them 🤯, but I have some problems with the purpose of the PR itself, because we should specify exactly that this is about the ability to reference the schemas themselves (mainly for message payloads, but we should also allow this for other places where we can use SchemaObject in the AsyncAPI document - include extensions and bindings) not to enable referencing for example Info Object defined in XML (or something like that).
Additionally, it has been mentioned a lot here that the JSON Pointer itself is JSON agnostic and could be used for data that does not have a typical JSON structure (but it is possible to transform it to JSON) and then the JSON Pointer could actually be used to pull nested data, well here is the problem because every other structure format (and even JSON-based formats like AVRO) can have (and usually have) a different way of referencing against each other than defined like a JSON Pointer.
Another thing, even if we think of a fancy way of referencing other formats and even give it an RFC number, the problem remains: how is this supposed to be supported by the tools themselves? For now, there are no tools that can reference formats other than JSON/Yaml (by JSON Pointer) - XML (whole document from given file) to JSON referencing alone is currently supported in most JSON dereferencing tools and is treated as a plain string, but the problem is nested elements in XML (no mention of attributes, namespaces), so @jessemenning gave a good comment here, because what do we get from spec for referencing as there will be no tools to support it - I don't want to come off as ignorant but is there any implementation (in any language, at least one) that supports 100% all referencing cases (in dereferencing phase) in the new OpenAPI 3.1? If not, why do I need such a possibilities of referencing? Of course, I am also developer and I know that it can be difficult, but at least one tool implementation should be written alongside with given spec or draft for spec to show that's possible.
So if we want to somehow incorporate referencing other formats "inside" JSON Pointer, it would have to be strictly defined and explained without relying on any existing tools like XML -> JSON because they don't have to be based on the specification at all but on the author's idea - that is, each tool == a different way of transforming XML to JSON.
Simple example with Avro:
{
     "type": "record",
     "namespace": "com.example",
     "name": "FullName",
     "fields": [
       { "name": "first", "type": "string" },
       { "name": "last", "type": "string" }
     ]
}

and then (inside another Avro schema) I can reference FullName type as com.example.FullName. I could write by JSON Pointer: ./avro.avsc#/com.example.FullName but probably I need to know (and then tool) how to handle that and com.example.FullName is not a property of object (root object) but reference to the given (usually nested) element in some structure.
If it were up to me, instead of combining JSON Pointer with other formats, I would prefer a solution like this:

If $ref's values is a string, it's JSON Pointer
if $ref's value is a JSON Object, then link field inside that object (or another name, it's only a suggestion) points to some structure of another format (with JSON Pointer syntax/format) and rest of fields (depends on format) define complex referencing.

Example:
$ref:
  link: './avro.avsc'
  format: ...avro
  type: com.example.FullName

As I wrote at the beginning of the post, I tried to understand all the previous comments, but I missed a little bit of such a clue why we are discussing here because we are focusing too much on unimportant things so far, and probably not enough on how it would work in the end and what problems would face the developers of the tools.
BTW. Fran mentioned during the discussion of my one proposal about the possibility of defining custom schema formats anywhere in the spec, that probably this possibility is not so important, because anyone can parse XML to JSON and then use a regular JSON Pointer, but it requires a lot of user knowledge and work and we should simplify life.

@magicmatatjahu

is there any implementation (in any language, at least one) that supports 100% all referencing cases (in dereferencing phase) in the new OpenAPI 3.1?

Yes, I believe @karenetheridge's OpenAPI::Modern handles all of the cases, using her JSON::Schema::Modern implementation.  I think @gregsdennis JSON Everything project either supports it or will soon (he and I talked about base URIs in OAS 3.1 files recently, at least).  @jdesrosiers's Hyperjump OAS validator seems to work with the schema objects in isolation, but I'm pretty sure you could use Hyperjump JSON Schema Core to handle references across an OAS 3.1 file as it understands all of the necessary base URI and reference resolution concepts.
These are just projects by people I know, and come more out of the JSON Schema side expanding to OAS-specific validation.  You may be able to find more for other OAS use cases at openapi.tools.

Since variations have been brought up by many people in many threads, I'm going to make this plea at the top level:
Please, please, please do not make up new $ref behavior or syntax!
Just use a different keyword name.
Making your own $ref will create an absolute nightmare for us over at the JSON Schema Org as people who learn your $ref show up and demand that we support whatever you did.

JSON Reference was one of the JSON Schema Org's draft standards and we intentionally dropped it, while understanding that some would continue to use the old approach as it was.  That's fine.  The OpenAPI/AsyncAPI Reference Objects have a well-known (even if long-expired) specification source, and aside from the "ignore adjacent properties" (which has always been the cause of tremendous confusion anyway), the behaviors are  compatible.
But as soon as you go beyond that, you are fracturing the specification landscape.  For $ref in AsyncAPI files outside of JSON Schema objects, you'll be creating a divergent expectation and we'll get demands to comply, or to reconcile the approaches, or something.
If you make changes to $ref in the context of JSON Schema objects, then you're just flat-out incompatible with JSON Schema.  I've lost track of whether this is part of the current proposal, but just think of all of the problems and frustrations caused by OAS 2 and OAS 3.0's JSON Schema incompatibilities.  It was enough of a problem that JSON Schema compatibility became the primary focus of OAS 3.1 (along with Webhooks).
So please, do not fracture the $ref landscape.  Old-style JSON References are fine.  Once you go beyond that in a way that is not compatible with JSON Schema's $ref, we are all going to end up hurting.
There are many names out there.  If you want it to work in JSON Schema, we'd request that you not use a $ prefix as we use that to signify the small set of JSON Schema core keywords (although using $ is not outright forbidden, and I can't imagine anyone would do anything about it if you do use it).  If it is being used outside of JSON Schema, we of course don't care what you use in other contexts.

@jonaslagoni regarding:

***This means that if AsyncAPI takes a similar approach to modern JSON Schema, then you can reference other schemas as the behavior is defined in terms of the schema result, not the schema syntax. ***

Do you mind clearifying this, I dont quite understand what you mean here by the schema result, not the schema syntax 🤔?

JSON Reference (and JSON Schema $ref in draft-03, -06, and -07) works by replacing the containing object with the target, which is why adjacent (same-object) keywords are ignored.
In JSON Schema, keywords have two effects: they produce a boolean assertion result, and they can produce annotations, e.g. associating a keyword like title with a specific instance location.  A schema object ANDs its assertion results, and if that ANDed result is true it keeps the annotations from all of the keywords.  If it's false, it deletes the annotations.  Don't worry too much about the annotation stuff, I'm just pointing out that there's more going on than a boolean.
With the old "replace the context object" approach, you could implement it as a literal replace-and-re-evaluate, or you could implement it as "evaluate $ref's target schema, and use its results for the whole schema object containing the $ref, ignoring all other keywords instead of evaluating them, ANDing their results, etc."  The effect is the same either way.
In modern JSON Schema (2019-09 and later), we started from the 2nd approach and changed it to the following (italicized parts are different): "evaluate $ref's target schema, and use its results as the result of $ref as a JSON Schema keyword."  From there, the standard way of combining keyword results in JSON Schema is used, which means that adjacent keywords work just fine.  So consider:
{
  "$defs" :{
    "foo": {
      "type": "object",
      "additionalProperties": {"type": "string"}
    }
  },
  "type": "array",
  "items": {
    "$ref": "#/$defs/foo",
    "minProperties": 1
  }
}

In the old JSON Reference replace-the-context-object approach, this behaves like:
{
  "type": "array",
  "items": {
    "type": "object",
    "additionalProperties": {"type": "string"}
  }
}

In the 2019-09 and later approach, it behaves more-or-less like:
{
  "type": "array",
  "items": {
    "allOf": [{
      "type": "object",
      "additionalProperties": {"type": "string"}
    }],
    "minProperties": 1
  }
}

There's not really an allOf inserted, but a one-element allOf also just evaluates that element and uses its result as the result of the allOf keyword.  A $ref now does the same thing: evaluates the referenced schema and uses tis result as the result of $ref as a keyword.
So, for other uses of $ref, the quesetion is, "What is the effect of the thing that is being referenced, and how would it be used at the point of reference.  In JSON Schema, the thing is a schema and it is used for its assertion and annotation results.  JSON Schema has a well-defined process for combining the assertion and annotation results of multiple keywords, so that works just fine.
How well a similar approach would work in other contexts depends on what you're referencing and how it's used.

Please, please, please do not make up new $ref behavior or syntax!

Agreed, but didn't JSON Schema do the same? While JSON Schema's syntax is the same as JSON Reference, its resolution behavior is definitely very different than the $ref we all know and love. So when people see a $ref in AsyncAPI, who's to know what the expectation for resolution might be. I know if I were writing OpenAPI tooling again, something I've not been excited to do since the unnecessary complexity of 3.x, the only choice is to defer to an approved JSON Schema parser for handling $ref because it seems to be specific to JSON Schema now.
And that's why I go back to what exactly are we trying to solve here? If you have structured data and a JSON Reference, resolution is possible. While "JSON" is implied by their names, JSON Pointers/References provide a simple syntax and expectation for defining resolution locations and resolution rules...even if you're not using JSON. (JSON References seem to work just fine in YAML for example.)
Not looking to rock the boat, but as a long time OpenAPI consumer and tooling author, I'd just hate to see us go down the path of making things harder than they need to be. I'm completely open to changing my mind, I'm just not sure there's been a case made that can't be solved with the existing JSON Reference syntax and resolution rules. Maybe I just missed it above, so I'll go back and re-read again.

Agreed, but didn't JSON Schema do the same?

They're all JSON Schema Org specs (including JSON Reference which, like all of the early JSON Schema specs, was edited/authored or co-edited/authored by Kris Zyp), and all clearly marked as drafts.  And we talked it over extensively with OpenAPI as you probably recall since you were on a lot of those TSC calls.  And there were and are a ton of use cases where keywords alongside $ref would be advantageous.  And someone (either Phil Sturgeon or someone from the OpenAPI TSC or some combination) went and did an extensive survey of $ref usage to see if making that change was likely to cause problems in OpenAPI.  It's not like we just did it for the lulz without talking to anyone about it.
It's different when one org redefines another org's specs.  We don't redefine JSON Pointer, for example (although we do define Relative JSON Pointer, which is careful not to overlap or contradict JSON Pointer: they are distinct specifications).

its resolution behavior is definitely very different than the $ref we all know and love.

The constant stream of people confused about adjacent keywords being ignored and wanting them not ignored indicated that "love" was definitely a stretch.  We changed the behavior in response to use cases and confusion within the community.

... It's not like we just did it for the lulz without talking to anyone about it.

First off, there was no disrespect in my message and I never suggested that the decisions made were taken lightly. I do remember being on those OpenAPI TSC calls, but I also remember being one of the people suggesting against the change. My reasons were to avoid confusion for people that know $ref, which should include years of people using JSON Schema/OpenAPI/Swagger, and to avoid complexity as it relates to reasoning about the reference by a human and when authoring tooling. What's done is done and there is no going back, but my concern that seeing a $ref and not knowing if it's the draft spec to follow or the JSON Schema specific version seems like a valid concern.
To move on from my original disagreement with the changes to $ref, because they don't matter now, my new opinion is that OpenAPI and AsyncAPI have similar needs and since OpenAPI adopted the JSON Schema $ref approach, I would be all for AsyncAPI doing the same. It would make for consistency across authoring these documents, and the tooling for supporting them.
But even if AsyncAPI does this, it does not change my opinion on how $ref is capable of resolving values in any structured data so I don't see the need to extend/modify what JSON Schema already does for $ref as it relates to supporting resolution of values in non-JSON referrant documents.

Thanks, @whitlockjc .

a $ref and not knowing if it's the draft spec to follow or the JSON Schema specific version seems like a valid concern.

Not to re-litigate but just to explain for those with less context, yes that's a valid concern.  But for Reference Objects (which are in OAS 3.1 clearly distinct from Schema Objects- they are never both syntactically valid in the same place) both OpenAPI and AsyncAPI say explicitly in their own documentation that adjacent fields SHALL be ignored.  With that restriction, you end up with essentially the same behavior in both places (a $ref in modern JSON Schema that doesn't have siblings has the same observable behavior as it did in draft-07).

OpenAPI and AsyncAPI have similar needs and since OpenAPI adopted the JSON Schema $ref approach, I would be all for AsyncAPI doing the same. It would make for consistency across authoring these documents, and the tooling for supporting them.

I'm in agreement with you there.

But even if AsyncAPI does this, it does not change my opinion on how $ref is capable of resolving values in any structured data so I don't see the need to extend/modify what JSON Schema already does for $ref as it relates to supporting resolution of values in non-JSON referrant documents.

The problem isn't the JSON Pointer part, it's the URI fragment part.  All of this boils down to whether one wants to respect the principle that media types determine fragment syntax, and if so how one goes about reconciling that with a varied landscape of data formats, some of which don't define media types, and some of which that do don't define suitable fragment approaches.
For anyone wondering where I'm getting this, it's from RFC 3986 §3.5:

The semantics of a fragment identifier are defined by the set of
representations that might result from a retrieval action on the
primary resource.  The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced.  If no such representation exists, then the
semantics of the fragment are considered unknown and are effectively
unconstrained.  Fragment identifier semantics are independent of the
URI scheme and thus cannot be redefined by scheme specifications.
Individual media types may define their own restrictions on or
structures within the fragment identifier syntax for specifying
different types of subsets, views, or external references that are
identifiable as secondary resources by that media type.  If the
primary resource has multiple representations, as is often the case
for resources whose representation is selected based on attributes of
the retrieval request (a.k.a., content negotiation), then whatever is
identified by the fragment should be consistent across all of those
representations.  Each representation should either define the
fragment so that it corresponds to the same secondary resource,
regardless of how it is represented, or should leave the fragment
undefined (i.e., not found).

That's only a $ref question because $ref uses a single URI, and is therefore governed by these rules.  A reference that doesn't use URIs, or (more realistically) uses URIs plus additional information not governed by RFC 3986, has more flexibility.
For JSON Schema, $ref makes sense because we know the target media type (application/schema+json), so URI fragments have clear predictable behavior.

A quick update:  I have continued to think on the issues brought up here in @jonaslagoni 's proposal, plus the conversation with @whitlockjc and others, including the long-standing use of standalone ref-parsing tools outside of JSON Schema.  We are discussing this among the JSON Schema team.
It will be a little while before I can share more details due to a team member being OOTO until later this week, but I wanted to let y'all know that my "please don't redefine $ref because JSON Schema owns it" was not intended to be a "don't do this, that's the end of it" ultimatum.  We recognize that if we're going to claim some sort of ownership over $ref, then we have a responsibility to the communities using it.  Whether that usage fits perfectly with ours or not.
These sorts of issues have come up periodically, and we're assessing the various proposals that have been considered in the past.  I post an update here when I am able, whether that's a new proposal or an acknowledgement that we should work with an existing proposal such as this one (I'm not aware of any other recent proposals, although if anyone knows of any please comment and I'll throw them into the mix).
I apologize for being cryptic, it's simply a matter of timing with respect to our team members' schedules.

A few questions for clarifying requirements.  By secondary resource, I more-or-less mean "thing you'd use a fragment to reference if fragment behavior were defined for the media type."

Do you ever need to reference a schema without knowing its format in advance?
Is there any other need for a single syntax (JSON Pointer) for accessing secondary resources across all schema formats?
Do all known schema formats define some sort of secondary resource access syntax (whether as fragment syntax or otherwise)?
For any schema formats that do not define their own secondary resource access syntax, is there a need to access secondary resources in that format?
When referencing a format that does not itself use JSON Reference, are there other sorts of references that need to be resolved?  If so, do they use URIs?  In particular, do they allow relative URI references?
Are cyclic references possible outside of JSON Schema?
Are all of AsyncAPI's $ref uses outside of JSON Schema intended to be "resolved" in the sense of replacing them in order to create a single file that does not use $ref outside of JSON Schema?

Sorry for taking so long folks, had to figure out what we should do with all this information and how to further progress the discussion.  Because there are so many things to consider, and use-cases that almost becomes impossible to follow in a PR Therefore I created a dedicated on ONLY focusing on a tooling perspective and how the specifications are sufficient/insufficient in defining expected behavior in order to create a feedback loop to create better standards and tooling. Please see https://github.com/asyncapi/community/discussions/485

So if we want to somehow incorporate referencing other formats "inside" JSON Pointer, it would have to be strictly defined and explained without relying on any existing tools like XML -> JSON because they don't have to be based on the specification at all but on the author's idea - that is, each tool == a different way of transforming XML to JSON.

@magicmatatjahu defined in U8 👍

If it were up to me, instead of combining JSON Pointer with other formats, I would prefer a solution like this:

@magicmatatjahu I am neither against nor for changing the keywords and structure for linking or referencing for that matter, lets see how we can progress that!

But even if AsyncAPI does this, it does not change my opinion on how $ref is capable of resolving values in any structured data so I don't see the need to extend/modify what JSON Schema already does for $ref as it relates to supporting resolution of values in non-JSON referrant documents.

@whitlockjc please jump into the discussion in U8 in the discussion, especially as you have the reasons why you see linking to non-JSON resources should be easy to achieve. But remember to point out where exactly in the specifications this is clarified or interpreted!
https://github.com/asyncapi/community/discussions/485#discussioncomment-3788951

The problem isn't the JSON Pointer part, it's the URI fragment part. All of this boils down to whether one wants to respect the principle that media types determine fragment syntax, and if so how one goes about reconciling that with a varied landscape of data formats, some of which don't define media types, and some of which that do don't define suitable fragment approaches.

@handrews U9 and U10 might be just for you! This tries to clarify the problem with media types and remote references and media types.

A quick update: I have continued to think on the issues brought up here in @jonaslagoni 's proposal, plus the conversation with @whitlockjc and others, including the long-standing use of standalone ref-parsing tools outside of JSON Schema. We are discussing this among the JSON Schema team.

@handrews I hope that the discussion and use cases can help us narrow down exactly where tooling doesn't know what to do because the standards are insufficient and the problems they face. Hope this helps your proposal to narrow it down.

A few questions for clarifying requirements. By secondary resource, I more-or-less mean "thing you'd use a fragment to reference if fragment behavior were defined for the media type."

Damn, what a set of questions 😅 Let me see if I can add my perspective to some of them!

Do you ever need to reference a schema without knowing its format in advance?

I think it could be, see U5, U9, and U10.

Is there any other need for a single syntax (JSON Pointer) for accessing secondary resources across all schema formats?

I would say that would be preferred, otherwise, implementations can come to the wrong conclusion of what that second resource is, or not even be able to find it.

Do all known schema formats define some sort of secondary resource access syntax (whether as fragment syntax or otherwise)?

I would say no here. But I dont have a complete experience with all the standards so I cant possibly say tbh. Maybe https://github.com/asyncapi/spec/issues/622 can give you some insight.

For any schema formats that do not define their own secondary resource access syntax, is there a need to access secondary resources in that format?

I would say yes because of https://github.com/asyncapi/spec/issues/622.

When referencing a format that does not itself use JSON Reference, are there other sorts of references that need to be resolved? If so, do they use URIs? In particular, do they allow relative URI references?

If you take a look at JTD, it uses its own referencing format i.e. simple mapping between reference and definitions. See https://www.rfc-editor.org/rfc/rfc8927#name-ref

Are cyclic references possible outside of JSON Schema?

Yes, but of course not for all formats.

Are all of AsyncAPI's $ref uses outside of JSON Schema intended to be "resolved" in the sense of replacing them in order to create a single file that does not use $ref outside of JSON Schema?

It is only from a tooling perspective. Because, as far as we can determine, the use-case is not to know it's a reference but what that referenced resource is, so you can iterate/interact with the resolved resourced. Especially when it comes to parsers.


SVG  missing text (maybe the clippath problem)

Attach (recommended) or Link to PDF file here:
Configuration:

Web browser and its version: chrome  91.0.4472.124 or Microsoft Edge(91.0.864.67 )
Operating system and its version: window 10
PDF.js version:  pdfjs-2.9.359-legacy-dist
Is a browser extension:

Steps to reproduce the problem:

download the input.pdf file
2.using pdf2svg.js to generate svgs
3.the first page  svg of the pdf file

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
PDF file:
input.pdf

@samchild same problem, did you fix this?


Remove PostBuildSign

PostBuildSigning requires an additional release and signing step after build.  We aren't doing that for maintenance-packages, so just sign during the build.

PR won't do it, we need the official build.  Since it has to complete to test it, we might as well just merge.


Provide Elixir code samples

It would be great if all the code samples could be translated to Elixir,
as well to make it easier for Elixir newbies to start using it (as many of us are unfamiliar with the original Erlang syntax and sometimes stumble trying to convert it).
Thank you, much appreciated

Thanks for this suggestion! I think I'll even go further and do a Elixir-specific library as an exercise to learn Elixir better :) Stay tuned

That would be awesome!  I'm also an Elixir user that would like to use Cassandra.  I think as people discover Elixir, there will more and more demand for drivers etc. which will hopefully help projects like this.

If nobody's doing this, I would love to write some examples :+1:

@krakatoa Please do! I'll be more than happy to merge that!

Here's an example from my app:
require Record
Record.defrecord :cql_query, statement: nil, values: [], reusable: :undefined, named: false, page_size: 100, page_state: :undefined, consistency: 1, serial_consistency: :undefined, value_encode_handler: :undefined

query = cql_query(
  statement: """
    SELECT *
    FROM users
    WHERE user_uuid = :user_uuid
  """,
  values: [
    user_uuid: UUID.string_to_binary!(user_uuid)
  ]
)

It took some effort to get that right it would be great to have examples in the wiki/repo.  Also, would we be receptive to adding a package.exs to get this project up on hex.pm?

@hayesgm I prefer extract record from cqerl.hrl:
defmodule Cqerl.Utils do
  require Record
  Record.defrecord :cql_query, Record.extract(:cql_query, from: "deps/cqerl/include/cqerl.hrl")
  Record.defrecord :cql_query_batch, Record.extract(:cql_query_batch, from: "deps/cqerl/include/cqerl.hrl")
end

Config for {:ok, client} = :cqerl.new_client():
config :cqerl,
  cassandra_nodes: [{'<IP_ADDRESS>', 9042}],
  keyspace: "development"

Usage:
  import Cqerl.Utils

  # Batch insert example:
  def add_populars(client, pairs) do
    query = cql_query(statement: "INSERT INTO user.populars (uid, ts, data) VALUES (?, ?, ?);")
    queries = for {uid, ts, data_map} <- pairs, do: cql_query(query, values: [uid: uid, ts: ts, data: Poison.encode!(data_map)])
    batch_query = cql_query_batch(mode: 0, consistency: 1, queries: queries)
    :cqerl.run_query(client, batch_query)
  end

Just created this project: https://github.com/matehat/cqex

That project wraps cqerl behind a Elixir-style interface, with Enumerable support, chaining and some custom structs. If you just wanted access to cqerl records though, it would be as simple as:
iex(1)> import CQEx
iex(2)> cql_query(statement: "SELECT * FROM users;")
{:cql_query, "SELECT * FROM users;", [], :undefined, false, 100, :undefined, 1, :undefined,
 :undefined}


mindreader auto-merge broken using release/v0.10.x

I started from a geth backup from a few weeks back.  mindreader won't merge anything.
All the files pile up in mindreader/work/mergeable.
Stopping, removing all the files in mindreader/work/mergeable and restarting results in the same thing.
Full debug logs available upon request.

2022-04-30T15:09:36.742Z DEBG (bstream) found root or hole. did not reach requested block {"requested_block_num": 6530600, "missing_id": "9321a4f8"}

Closing, every thing is found under https://github.com/streamingfast/firehose-core now anyway. Going to make this repo read-only.


image label

May I ask what's the label of each image? Thanks a lot:)

Hi, it's up to you to label images, by default you can assume, that most of them is NSFW, after you can split images in sexy, porn and other categories, but you should do it on your side, this repository doesn't provide such labels. Thanks for your question

@EBazarov Thanka a lot:)


Use informative exceptions instead of Maybe for fromJSRef

Currently, the type of improved-base fromJSRef is fromJSRef :: FromJSRef a => JSRef -> Maybe a.  Having a Maybe type for marshaling failures isn't very informative, and in practice, I find that I always want the Nothing case to be a failure.  By using the Monad instance for Maybe, we lose info about why and where marshaling failed.  Each time I use fromJSRef, I need to write my own error message saying that overall marshaling failed.
How can we resolve this?  My proposal is to instead throw an exception.  Here's why:

It's more efficient than plumbing Maybe everywhere.
fromJSRef already lives in IO.
I almost always want marshaling failure to be an exception.
In the cases where I want to do something upon marshaling exception, I can catch the exception.

I think the following is a reasonable type for exceptions during marshaling:
newtype FromJSRefException a = FromJSRefException a
  deriving (Typeable, Show)

instance (Show a, Typeable a) => Exception (FromJSRefException a)

Ideally, there would be a convention of always throwing exceptions wrapped in this, to provide a uniform way of catching marshaling issues.  It may also be worth considering passing through a path like [(TypeRep, String)], so that it's clear where in the structure the error is occurring.  It might be good to make this optional, though, as there could be quite a bit of overhead.

I discussed this some with Luite at ICFP, and it sounds like the most efficient way to get info about where the marshalling error occurred is actually to wrap things in a catch at all the spots we want to extend the error with more info.

One complication here is that it would be consistent for the pure version to also throw marshaling exceptions.  However, they may not get forced during marshaling, and so wouldn't get the path information indicating the path to the issue.
Maybe this is a good reason to explicitly build the path rather than doing it with exception catching?


Google Play Games Services - Social authentication

Hi, good day!
Do you have a date to include the documentation of Google Play Games Services (Social Auth) implementation in https://firebase.flutter.dev/docs/auth/overview/ website? I'm looking forward to implement GPGS functionalities in my Flutter app but I think it's difficult and it isn't into the docs.

Hi @jdaibello
GPGS isn't a part of native Firebase functionality, it is just a credential provider you could use for Firebase auth.
There is native documentation on how to do what you want to do https://firebase.google.com/docs/auth/android/play-games#integrate_play_games_sign-in_into_your_game but this still requires you to integrate GPGS in native, which won't work for Flutter.
As for how to use GPGS in Flutter currently - there are plugins like https://pub.dev/packages/play_games and https://pub.dev/packages/games_services but there is no official implementation yet https://github.com/FirebaseExtended/flutterfire/issues/982
As it hasn't been implemented yet and there is nothing to document I'm going to close this as a duplicate of https://github.com/FirebaseExtended/flutterfire/issues/982
Thank you


team page 403 when logged out but team is public

https://cables.gl/team/standalone

https://cables.gl/team/66b5c9ad0fe26f0d5e7ffeac

https://search.google.com/search-console/index/drilldown?resource_id=https%3A%2F%2Fcables.gl%2F&item_key=CAESHWh0dHBzOi8vY2FibGVzLmdsL3NpdGVtYXAueG1sGDMgAg&hl=de


Song time bar not updating on 'previous song' when paused

After clicking 'previous song' when a song is midway to play it from the beginning, if the song is paused, the progress bar does not update.
(Spotify)
How to reproduce:

Play a song
Skip to about a half of the song's length
Press 'Previous song'
The progress (song time) bar does not update.

The progress bar is not resetting to 0 (start of song) is what I was trying to say, so even if Spotify doesn't give the information, the fix shouldn't be difficult.

Currently I can't detect any changes in the progress within the same song. I only get the latest information when the song changes or it goes from play to pause and vice versa. But I do have an idea for a workaround now since you reminded me.


documents protect with specified expireTime is not working

It seems that documents protect with specified expireTime doesn't work
    db.documents.protect({
      uri: 'someTemporalDoc.json',
      temporalCollection: 'temporalCollection',
      level: 'noUpdate',
      expireTime: '2016-11-03T19:56:17.681154-07:00'
    })

This will throw an error:
{ [Error: protect document: response with invalid 400 status (on temporalDoc.json)]
  message: 'protect document: response with invalid 400 status (on temporalDoc.json)',
  statusCode: 400,
  body:
   { errorResponse:
      { statusCode: 400,
        status: 'Bad Request',
        messageCode: 'TEMPORAL-INVALIDEXPTIME',
        message: 'TEMPORAL-INVALIDEXPTIME: temporal:document-protect("temporalCollection", "temporalDoc.json", <options xmlns="temporal:document-protect"><level>noUpdate</level>...</options>) -- The specified expire time option 2016-11-03T19:56:17.681154-07:00 is invalid' } } }

Hi aries, this bug is in bugtrack already: 42632.  Jane is looking into it.

Thanks @grechaw

I will keep my eye on it and verify it after it gets fixed

Working fine, added test on nodejs-temporal-protect-update.js


TypeScript rules

Pull request checklist
Make sure you:

[X] Signed the Contributor License Agreement
[X] Followed the commit message guidelines

For non-trivial changes, please make sure you also:

[X] Added/Updated related documentation.
[X] Added/Updated related tests.

Short description of the change(s)
This PR adds a couple new rules for TypeScript. Couple things that I'd like to do first this PR is merged:

Find a better name for the target rule
Complete the target support matrix, browserslist returns a lot of browsers in some of the queries and this should be more complete
Maybe add what browser(s) are affecting the target?

In any case, this is ready to start looking in case there's any major change required.

This PR also fixes some stuff that could be merged before (first 3 commits)

This PR also fixes some stuff that could be merged before (first 3 commits)

Done.

@sarvaje @alrra, I've updated the browser support matrix and added a few more links. Let me know if you have any other feedback or otherwise I'll merge it as soon as I can.


Update column formatting schema

This update contains the following 2 changes -

Added  viewBox and preserveAspectRatio attributes
Added columnFormatterReference

@octogonz Can you please help by merging this?

@octogonz Can you please help by merging this?

The live branch has been deployed.

The live branch has been deployed.


feat(its/it): add contract constructor Constructorv22/its

closes https://axelarnetwork.atlassian.net/browse/AXE-6583
Summary
similar to #69
only thing of note was that the interchain-token ContractError type only had two variants, both of which were removed. So I just commented it out (could just be deleted instead?)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.34%. Comparing base (90d4368) to head (ca87f62).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #74      +/-   ##
==========================================
- Coverage   99.36%   99.34%   -0.02%
==========================================
  Files          33       32       -1
  Lines        2054     1999      -55
==========================================
- Hits         2041     1986      -55
  Misses         13       13

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


Convert unittests to pytest

Changed file names such that pytest is able to discover tests; fixed multiple files that had various issues; deleted faulty test case that would've taken too much effort to fix.

Can we add this to our CI workflow with Junit XML report generation?

I think we're going to de-prioritize further CI work for dev work which Gary is handling. I'll just merge this as-is for now so we have some test coverage.


Permify playground link should be added into navbar

"Permify Playground" tab need added to top navigation bar and it should redirect to the playground. Specifically, it should be placed as below image pointed.

Hello, can I get assigned for this issue?

Hi @alielbashir good to see you here 👋 I'm assigning you to the issue, happy hacking 🚀


GEditor->MoveSelectedActorsToLevel warning

When building the plugin with 4.17.2 I get this warning about a soon to be deprecated function.  I can't seem to find a migration path away from this method - so not sure how you want to support / ifdef the support for this method out?

Should be fixed in latest code :)


Use histogram type to send timing data.

Based on Datadog's docs dogstatsd doesn't support the timing metric, so using histogram instead.

Thanks for the PR @davedash!
h and ms type are indeed equivalent: https://github.com/DataDog/dd-agent/blob/52e7eb6032edca337bbb102c6e555c44443b688d/aggregator.py#L747-L748, I'm not sure why we need to change though, could you add some details ? (maybe just the docs ref if it's enough)

@degemer you are right.  I was working with someone at Datadog support and they (and I) read this bit incorrectly:
http://docs.datadoghq.com/guides/dogstatsd/#timers
assuming it's no longer supported, but you are right, it's interchangeable.  I'm going to close this. :)


Download GUI keeps disappearing

Bug description
The download GUI at the bottom of every image in the viewer disappears frequently. Only reappears after adjusting options.
Steps to reproduce

Open image in image viewer

Expected behavior
Download gui below image
Screenshots

System information

OS:. Windows 10 22H2
Grabber version: 7.12.2 (x64)
main.log
settings.ini

Additional context
Using a ultrawide monitor. 3440 x 1440

I can confirm the same thing happening on Windows 11 23H2.
I also need to open settings and press OK to get the buttons to reappear


Use server-side apply

Instead of reverse-engineering the client-side three-way diff algorithm that kubectl uses, use the new server-side apply feature.
Docs: https://kubernetes.io/docs/reference/using-api/api-concepts/#server-side-apply
Client support: https://github.com/tintoy/dotnet-kube-client/issues/63

:tada: This issue has been resolved in version 0.12.0 :tada:
The release is available on:

PowerShell Gallery
GitHub release

Your semantic-release bot :package::rocket:


Set --system in JavaExtractor

/gcbrun

Note: this fixes some extraction errors when running with a newer JDK.

It looks like kythe's copy of the extra action proto needs to be updated
kythe/java/com/google/devtools/kythe/extractors/java/bazel/JavaExtractor.java:143: error: cannot find symbol
--
  | String sysd = jInfo.getSystem();
  | ^

updating our local copies now

PR #5485

/gcbrun


publish a new version?

I see a PR (https://github.com/kpdecker/node-resemble/pull/12) has gone in which has not yet been published.
I understand the PR is no longer maintained, but a new version would be gratefully received!
I see there was an offer to help with maintenance, did that go anywhere?  Would it be helpful to have multiple maintainers? I'd be happy to put my name into the hat also.

Honestly can't remember. @snollygolly has contributor access to the repository now, but that's all that I remember.


Added swahili translation

Adding swahili translation

@tanyona thank you for contributing to grahamar/cron-parser! At cron-utils we would be glad to add support for swahili. Would you be able to contribute it there also?