profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/syrusakbary/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Syrus Akbary syrusakbary @wasmerio San Francisco, CA http://syrusakbary.com Entrepreneur. Mathematician. @wasmerio CEO (YC S19). @GraphQL-Python creator. Author of Graphene, pyjade, promises (py) and other cool stuff... 😄

gatsbyjs/gatsby 49148

Build blazing fast, modern apps and websites with React

graphql-python/graphene 6367

GraphQL framework for Python

graphql-python/gql 663

A GraphQL client in Python

graphql-js/graphene 206

GraphQL Framework for Javascript

syrusakbary/aiodataloader 159

Asyncio DataLoader for Python3

graphql-python/graphql-relay-py 128

A library to help construct a graphql-py server supporting react-relay

GraphQL-python-archive/graphql-django-view 23

[DEPRECATED | Use graphene-django package] A django view that will execute a GraphQLSchema using a given Executor.

syrusakbary/Djinja 20

(Deprecated) A package that makes possible the integration of Jinja2 in Django, in a clean way.

graphql-python/graphene-python.org 6

Graphene-Python.org official website

Pull request review commentgraphql/graphql-spec

RFC: operation expressions

+# RFC: Operation Expressions++(WORKING TITLE!)++**Proposed by:** [Benjie Gillam](https://twitter.com/benjie) - Graphile++In the [Schema Coordinates RFC](./SchemaCoordinates.md) Mark introduced the+concept of "schema coordinates" which give a standard human- and+machine-readable way to unambiguously refer to entities within a GraphQL schema:+types, fields, field arguments, enum values, directives and directive arguments.+The scope of that RFC is deliberately very tight, and it serves that goal well,+providing a one-to-one mapping between the schema coordinates and the schema+entities.++This RFC is to gather feedback on expansions of the Schema Coordinate syntax+that could be used for different purposes whilst maintaining familiarity.++## Aim++The aim of this RFC is to give the GraphQL community a standard syntax that+people, tools and documentation can use to concisely and consistently reference+GraphQL operation concepts such as paths that is more fluid, expressive, and+contains more context than the Schema Coordinates RFC that this RFC builds on+top of.++This is not intended to be a replacement of the Schema Coordinates RFC, but an+extension to it for a number of additional use-cases.++## Use cases++#### Referencing a position within a GraphQL Operation Document

Yes it can, via the name:

OperationName:mutation>createFoo>foo>id
benjie

comment created time in a few seconds

push eventbytecodealliance/lucet

Pat Hickey

commit sha 2677e082bbf736ea3933f42372ff09e736ebd659

syntax

view details

push time in 6 minutes

push eventbytecodealliance/lucet

Pat Hickey

commit sha e296db8152ac81e1b6dc46c41590c46f79bb5190

add dependency installation to github workflow

view details

push time in 8 minutes

push eventbytecodealliance/lucet

Pat Hickey

commit sha 72a137972e901d326ed6c852476afee29dc5f5f7

get rid of docker wrapper on github actions

view details

push time in 17 minutes

push eventbytecodealliance/lucet

Pat Hickey

commit sha b38e249aa5da93c0f67fd5c9a7c6479369cf6eeb

fix witx syntax in test

view details

push time in 27 minutes

create barnchbytecodealliance/lucet

branch : pch/test_uffd_on_github

created branch time in 44 minutes

PR opened bytecodealliance/lucet

use witx 0.9

bumps the wasmtime submodule, which in turn pulls in witx 0.9. Fixes in lucet-wiggle and lucetc's witx validator to use the new AST.

+44 -44

0 comment

7 changed files

pr created time in an hour

create barnchbytecodealliance/lucet

branch : pch/witx_0.9

created branch time in an hour

issue commentflutter-rs/flutter-rs

armv7-unknown-linux-gnueabihf support

Just added: https://github.com/jwinarske/meta-flutter/tree/dunfell/recipes-graphics/flutter-rs

flukejones

comment created time in an hour

issue commenttessi/wasmex

Arguments and returns as a string

Again I thank you for your attention and I will keep you informed. Unfortunately I was very busy with other things today and I haven't been able to test it yet, but I believe it will work accordingly and again I will keep you informed

sleipnir

comment created time in 2 hours

Pull request review commentgraphql/graphql-spec

RFC: operation expressions

+# RFC: Operation Expressions++(WORKING TITLE!)++**Proposed by:** [Benjie Gillam](https://twitter.com/benjie) - Graphile++In the [Schema Coordinates RFC](./SchemaCoordinates.md) Mark introduced the+concept of "schema coordinates" which give a standard human- and+machine-readable way to unambiguously refer to entities within a GraphQL schema:+types, fields, field arguments, enum values, directives and directive arguments.+The scope of that RFC is deliberately very tight, and it serves that goal well,+providing a one-to-one mapping between the schema coordinates and the schema+entities.++This RFC is to gather feedback on expansions of the Schema Coordinate syntax+that could be used for different purposes whilst maintaining familiarity.++## Aim++The aim of this RFC is to give the GraphQL community a standard syntax that+people, tools and documentation can use to concisely and consistently reference+GraphQL operation concepts such as paths that is more fluid, expressive, and+contains more context than the Schema Coordinates RFC that this RFC builds on+top of.++This is not intended to be a replacement of the Schema Coordinates RFC, but an+extension to it for a number of additional use-cases.++## Use cases++#### Referencing a position within a GraphQL Operation Document++Imagine you have the following GraphQL query:++```graphql+{+  businesses: searchBusinesses(name: "Automotive") {+    id+    name+    owner: personByOwnerId {+      id+      name+      email # <<< HERE+    }+  }+}+```++You might reference the marked (`<<< HERE`) field with an expression such as:++- `Person.email` - this is the "schema coordinate" which uniquely identifies the+  field, but lacks context on how we retrieved it+- `>businesses>owner>email` - given the GraphQL query document, this is+  sufficient to uniquely identify this specific reference (caveat: duplicate+  fields would all be referenced with the same expression)+- `>businesses:searchBusinesses>owner:personByOwnerId>email` - this contains+  more context than the above, indicating not just the aliases but the actual+  field names too; with this access to the operation document is not required to+  determine what was requested+- `>businesses:searchBusinesses(name:)>owner:personByOwnerId>email` - this+  contains even more context (the argument names that were used)++These are all valid operation expressions, but they each convey different levels+of context.++### Generating a GraphQL Operation Document quickly (Emmet-style)++> Emmet is a plugin for many popular text editors which greatly improves HTML &+> CSS workflow:++Emmet is a popular syntax for quickly generating HTML/CSS. It's easy to imagine+how a operation expression syntax could be combined with a GraphQL schema+definition to quickly generate GraphQL queries, mutations and subscriptions with+a concise syntax. For example the expression:++`>businesses:searchBusinesses(name:)>owner:personByOwnerId>email`++might expand to:++```graphql+query($name: String!) {+  businesses: searchBusinesses(name: $name) {+    owner: personByOwnerId {+      email+    }+  }+}+```++`MyFragment:User.businesses>owner>email`++might expand to:++```graphql+fragment MyFragment on User {+  businesses {+    owner {+      email+    }+  }+}+```++### Documentation Permalinks++When navigating the GraphiQL documentation, GraphiQL maintains a stack of the+path you arrived to the current documentation page through. It could be valuable+to store this into the query string such that you could share a "documentation+stack" with someone else (or bookmark it). For example if you browsed through+the documentation via:++- `User` type+- `User.friends` field (returns a `User`)+- `User.latestMedia` field (returns a `Media` union)+- `Post` type in Media union+- `title` field++you might use a query string such as:++```+?docs=User.friends>latestMedia>Post.title+```++### Linking from a field description to an operation path++If, for example, you were to deprecate a root-level field in your schema, you+might want to indicate where the user can retrieve the equivalent data now. You+could do this by including an operation expression as part of the deprecation+reason:++> The `Query.branchesFromFork` field is being removed; please use the following+> path instead: `Query>repositories>forks>branches`++### Indicating how to access a particular field++When reading the documentation of a type in GraphiQL it currently does not+indicate how to reach a particular field. Though there are often infinitely many+paths to reach a field, often the shortest are the most valuable, so GraphiQL+could indicate a few of the shorter paths using operation expression syntax:++> `User.firstName` can be accessed through paths such as:+>+> - `>me>firstName`+> - `>articles>author>firstName`+> - `>searchMedia>Book.author>firstName`+> - `mutation>createUser>user>firstName`++### Analytics++When analysing how a GraphQL schema is used, it may be useful to track+statistics for each type, field, argument using Schema Coordinates; but it may+also be interesting to track through what paths users are finding said fields.+You could use operation expression syntax to track this:++```+counters['Query.cities>libraries>findBook(isbn:)']+++```++## Syntax++Syntax is in flux; but here's some thoughts:++#### Pathing++Following a path from one field to the next could use the `>` character; this is+already used in Apollo's GraphQL documentation browser and is intuitive for+navigation. This leaves `.` available and non-ambiguous for referring to fields+on a type, which is useful when disambiguating references on a union type, for+instance:++```+>me>media>Film.duration+```++might model:++```graphql+{+  me {+    media {+      ... on Film {+        duration+      }+    }+  }+}+```++#### Operations++The expression `>me>name` would expand to `{ me { name } }`.++If you want to create a mutation or subscription operation, you can prefix the+path with the operation type (you can do this for queries too, but just like in+operation documents, the query keyword is optional):++- `mutation>createUser>user>name` expands to+  `mutation ($input: CreateUserInput!) { createUser(input: $input) { user { name } } }`+- `subscription>currentUserUpdated>name` expands to+  `subscription { currentUserUpdated { name } }`+- `query>me>name` expands to `query { me { name } }`++You may name operations by prefixing with an operation name followed by a colon;+for example:++- `MyQuery:>me>name` and `MyQuery:query>me>name` expand to+  `query MyQuery { me { name } }`.+- `MyMutation:mutation>createUser>name` expands to+  `mutation MyMutation { createUser { name } }`.+- `MySubscription:subscription>userCreated>name` expands to+  `subscription MySubscription { userCreated { name } }`.++#### Fragments++Fragments start with a type name followed by a period: `User.friends>name`+expands to `... on User { friends { name } }`.++You can name fragments by prefixing with a fragment name and a colon:+`FriendNames:User.friends>name` expands to+`fragment FriendNames on User { friends { name } }`.++Other examples:++- `MyFragment:Node.User.fullName:name` expands to+  `fragment MyFragment on Node { ... on User { fullName: name } }`++- `MyQuery:>allEntities>edges>node>MyNodeFragment:Node.MyUserFragment:User.fullName:name`+  expands to++  ```graphql+  query MyQuery {+    allEntities {+      edges {+        node {+          ...MyNodeFragment+        }+      }+    }+  }++  fragment MyNodeFragment on Node {+    ...MyUserFragment+  }++  fragment MyUserFragment on User {+    fullName: name+  }+  ```++#### Arguments++Arguments use the same syntax as Schema Coordinates; namely parenthesis and a+colon: `>searchBusinesses(name:)>city`.++We also allow you to reference input objects used in arguments, for example:++`>searchBusinesses(where.size.greaterThan:)>city`++expands to something like:++```graphql+query($whereSizeGreaterThan: Int) {+  searchBusinesses(where: { size: { greaterThan: $whereSizeGreaterThan } }) {+    city+  }+}+```++Further we allow for multiple arguments to be specified, joined with commas:++`>searchBusinesses(where.size.greaterThan:,where.size.lessThan:,where.city.equalTo:)>name`

I notice we're using a dot separator for input types (where.size.greaterThan)

any reason we're opting for . instead of > here?

e.g. this:

>searchBusinesses(where>size>greaterThan:,where>size>lessThan:,where>city>equalTo:)>name

(even if the answer is "it looks nicer", then fair enough, just wondering)

benjie

comment created time in 3 hours

Pull request review commentgraphql/graphql-spec

RFC: operation expressions

+# RFC: Operation Expressions++(WORKING TITLE!)++**Proposed by:** [Benjie Gillam](https://twitter.com/benjie) - Graphile++In the [Schema Coordinates RFC](./SchemaCoordinates.md) Mark introduced the+concept of "schema coordinates" which give a standard human- and+machine-readable way to unambiguously refer to entities within a GraphQL schema:+types, fields, field arguments, enum values, directives and directive arguments.+The scope of that RFC is deliberately very tight, and it serves that goal well,+providing a one-to-one mapping between the schema coordinates and the schema+entities.++This RFC is to gather feedback on expansions of the Schema Coordinate syntax+that could be used for different purposes whilst maintaining familiarity.++## Aim++The aim of this RFC is to give the GraphQL community a standard syntax that+people, tools and documentation can use to concisely and consistently reference+GraphQL operation concepts such as paths that is more fluid, expressive, and+contains more context than the Schema Coordinates RFC that this RFC builds on+top of.++This is not intended to be a replacement of the Schema Coordinates RFC, but an+extension to it for a number of additional use-cases.++## Use cases++#### Referencing a position within a GraphQL Operation Document++Imagine you have the following GraphQL query:++```graphql+{+  businesses: searchBusinesses(name: "Automotive") {+    id+    name+    owner: personByOwnerId {+      id+      name+      email # <<< HERE+    }+  }+}+```++You might reference the marked (`<<< HERE`) field with an expression such as:++- `Person.email` - this is the "schema coordinate" which uniquely identifies the+  field, but lacks context on how we retrieved it+- `>businesses>owner>email` - given the GraphQL query document, this is+  sufficient to uniquely identify this specific reference (caveat: duplicate+  fields would all be referenced with the same expression)+- `>businesses:searchBusinesses>owner:personByOwnerId>email` - this contains+  more context than the above, indicating not just the aliases but the actual+  field names too; with this access to the operation document is not required to+  determine what was requested+- `>businesses:searchBusinesses(name:)>owner:personByOwnerId>email` - this+  contains even more context (the argument names that were used)++These are all valid operation expressions, but they each convey different levels+of context.++### Generating a GraphQL Operation Document quickly (Emmet-style)++> Emmet is a plugin for many popular text editors which greatly improves HTML &+> CSS workflow:++Emmet is a popular syntax for quickly generating HTML/CSS. It's easy to imagine+how a operation expression syntax could be combined with a GraphQL schema+definition to quickly generate GraphQL queries, mutations and subscriptions with+a concise syntax. For example the expression:++`>businesses:searchBusinesses(name:)>owner:personByOwnerId>email`++might expand to:++```graphql+query($name: String!) {+  businesses: searchBusinesses(name: $name) {+    owner: personByOwnerId {+      email+    }+  }+}+```++`MyFragment:User.businesses>owner>email`++might expand to:++```graphql+fragment MyFragment on User {+  businesses {+    owner {+      email+    }+  }+}+```++### Documentation Permalinks++When navigating the GraphiQL documentation, GraphiQL maintains a stack of the+path you arrived to the current documentation page through. It could be valuable+to store this into the query string such that you could share a "documentation+stack" with someone else (or bookmark it). For example if you browsed through+the documentation via:++- `User` type+- `User.friends` field (returns a `User`)+- `User.latestMedia` field (returns a `Media` union)+- `Post` type in Media union+- `title` field++you might use a query string such as:++```+?docs=User.friends>latestMedia>Post.title+```++### Linking from a field description to an operation path++If, for example, you were to deprecate a root-level field in your schema, you+might want to indicate where the user can retrieve the equivalent data now. You+could do this by including an operation expression as part of the deprecation+reason:++> The `Query.branchesFromFork` field is being removed; please use the following+> path instead: `Query>repositories>forks>branches`++### Indicating how to access a particular field++When reading the documentation of a type in GraphiQL it currently does not+indicate how to reach a particular field. Though there are often infinitely many+paths to reach a field, often the shortest are the most valuable, so GraphiQL+could indicate a few of the shorter paths using operation expression syntax:++> `User.firstName` can be accessed through paths such as:+>+> - `>me>firstName`+> - `>articles>author>firstName`+> - `>searchMedia>Book.author>firstName`+> - `mutation>createUser>user>firstName`++### Analytics++When analysing how a GraphQL schema is used, it may be useful to track+statistics for each type, field, argument using Schema Coordinates; but it may+also be interesting to track through what paths users are finding said fields.+You could use operation expression syntax to track this:++```+counters['Query.cities>libraries>findBook(isbn:)']+++```++## Syntax++Syntax is in flux; but here's some thoughts:++#### Pathing++Following a path from one field to the next could use the `>` character; this is+already used in Apollo's GraphQL documentation browser and is intuitive for+navigation. This leaves `.` available and non-ambiguous for referring to fields+on a type, which is useful when disambiguating references on a union type, for+instance:++```+>me>media>Film.duration+```++might model:++```graphql+{+  me {+    media {+      ... on Film {+        duration+      }+    }+  }+}+```++#### Operations++The expression `>me>name` would expand to `{ me { name } }`.++If you want to create a mutation or subscription operation, you can prefix the+path with the operation type (you can do this for queries too, but just like in+operation documents, the query keyword is optional):++- `mutation>createUser>user>name` expands to+  `mutation ($input: CreateUserInput!) { createUser(input: $input) { user { name } } }`+- `subscription>currentUserUpdated>name` expands to+  `subscription { currentUserUpdated { name } }`+- `query>me>name` expands to `query { me { name } }`++You may name operations by prefixing with an operation name followed by a colon;+for example:++- `MyQuery:>me>name` and `MyQuery:query>me>name` expand to+  `query MyQuery { me { name } }`.+- `MyMutation:mutation>createUser>name` expands to+  `mutation MyMutation { createUser { name } }`.+- `MySubscription:subscription>userCreated>name` expands to+  `subscription MySubscription { userCreated { name } }`.++#### Fragments++Fragments start with a type name followed by a period: `User.friends>name`+expands to `... on User { friends { name } }`.++You can name fragments by prefixing with a fragment name and a colon:+`FriendNames:User.friends>name` expands to+`fragment FriendNames on User { friends { name } }`.++Other examples:++- `MyFragment:Node.User.fullName:name` expands to+  `fragment MyFragment on Node { ... on User { fullName: name } }`++- `MyQuery:>allEntities>edges>node>MyNodeFragment:Node.MyUserFragment:User.fullName:name`+  expands to++  ```graphql+  query MyQuery {+    allEntities {+      edges {+        node {+          ...MyNodeFragment+        }+      }+    }+  }++  fragment MyNodeFragment on Node {+    ...MyUserFragment+  }++  fragment MyUserFragment on User {+    fullName: name+  }+  ```++#### Arguments++Arguments use the same syntax as Schema Coordinates; namely parenthesis and a+colon: `>searchBusinesses(name:)>city`.++We also allow you to reference input objects used in arguments, for example:++`>searchBusinesses(where.size.greaterThan:)>city`++expands to something like:++```graphql+query($whereSizeGreaterThan: Int) {+  searchBusinesses(where: { size: { greaterThan: $whereSizeGreaterThan } }) {+    city+  }+}+```++Further we allow for multiple arguments to be specified, joined with commas:++`>searchBusinesses(where.size.greaterThan:,where.size.lessThan:,where.city.equalTo:)>name`++expands to something like:++```graphql+query(+  $whereSizeGreaterThan: Int+  $whereSizeLessThan: Int+  $whereCityEqualTo: String+) {+  searchBusinesses(+    where: {+      size: { greaterThan: $whereSizeGreaterThan, lessThan: $whereSizeLessThan }+      city: { equalTo: $whereCityEqualTo }+    }+  ) {+    name+  }+}+```++> NOTE: the following number syntax probably needs more thought. Added only for+> completeness.++We also allow `[number]` syntax to refer to a numbered entry in a list, or `[]`+to refer to the next entry; e.g.:++`>findUsers(byIds[]:,byIds[],byIds[],byIds[5])>name`

i'm a little confused here - are we implying that byIds5 is an array?

(it's writen as a single ID type in the query below)

benjie

comment created time in 3 hours

issue closedtessi/wasmex

Arguments and returns as a string

First of all I would like to thank you for this excellent library. I need to call a function that takes a string as an argument and that returns a string as a result. In the examples I only saw the use of one or the other, never passing and receiving strings. It may seem trivial to expand, but I'm a little confused about the WASM API and the use of Memory to achieve this goal. Could someone help me?

closed time in 3 hours

sleipnir

issue commenttessi/wasmex

Arguments and returns as a string

Very cool :) I wish you best of luck and success with Astreu! I'm very interested if things work out for you.

Anyways, considering this issue, I think we're done. Please re-open or create a new issue if you discover any bugs or weirdnesses.

sleipnir

comment created time in 3 hours

Pull request review commentgraphql/graphql-spec

RFC: operation expressions

+# RFC: Operation Expressions++(WORKING TITLE!)++**Proposed by:** [Benjie Gillam](https://twitter.com/benjie) - Graphile++In the [Schema Coordinates RFC](./SchemaCoordinates.md) Mark introduced the+concept of "schema coordinates" which give a standard human- and+machine-readable way to unambiguously refer to entities within a GraphQL schema:+types, fields, field arguments, enum values, directives and directive arguments.+The scope of that RFC is deliberately very tight, and it serves that goal well,+providing a one-to-one mapping between the schema coordinates and the schema+entities.++This RFC is to gather feedback on expansions of the Schema Coordinate syntax+that could be used for different purposes whilst maintaining familiarity.++## Aim++The aim of this RFC is to give the GraphQL community a standard syntax that+people, tools and documentation can use to concisely and consistently reference+GraphQL operation concepts such as paths that is more fluid, expressive, and+contains more context than the Schema Coordinates RFC that this RFC builds on+top of.++This is not intended to be a replacement of the Schema Coordinates RFC, but an+extension to it for a number of additional use-cases.++## Use cases++#### Referencing a position within a GraphQL Operation Document++Imagine you have the following GraphQL query:++```graphql+{+  businesses: searchBusinesses(name: "Automotive") {+    id+    name+    owner: personByOwnerId {+      id+      name+      email # <<< HERE+    }+  }+}+```++You might reference the marked (`<<< HERE`) field with an expression such as:++- `Person.email` - this is the "schema coordinate" which uniquely identifies the+  field, but lacks context on how we retrieved it+- `>businesses>owner>email` - given the GraphQL query document, this is+  sufficient to uniquely identify this specific reference (caveat: duplicate+  fields would all be referenced with the same expression)+- `>businesses:searchBusinesses>owner:personByOwnerId>email` - this contains+  more context than the above, indicating not just the aliases but the actual+  field names too; with this access to the operation document is not required to+  determine what was requested+- `>businesses:searchBusinesses(name:)>owner:personByOwnerId>email` - this+  contains even more context (the argument names that were used)++These are all valid operation expressions, but they each convey different levels+of context.++### Generating a GraphQL Operation Document quickly (Emmet-style)++> Emmet is a plugin for many popular text editors which greatly improves HTML &+> CSS workflow:++Emmet is a popular syntax for quickly generating HTML/CSS. It's easy to imagine+how a operation expression syntax could be combined with a GraphQL schema+definition to quickly generate GraphQL queries, mutations and subscriptions with+a concise syntax. For example the expression:

How lossy is this? If I converted a query to an operation expression and then back again to a query, is it always perfectly preserved? (Wondering how things like @if are preserved, or directives in general)

benjie

comment created time in 4 hours

Pull request review commentgraphql/graphql-spec

RFC: operation expressions

+# RFC: Operation Expressions++(WORKING TITLE!)++**Proposed by:** [Benjie Gillam](https://twitter.com/benjie) - Graphile++In the [Schema Coordinates RFC](./SchemaCoordinates.md) Mark introduced the+concept of "schema coordinates" which give a standard human- and+machine-readable way to unambiguously refer to entities within a GraphQL schema:+types, fields, field arguments, enum values, directives and directive arguments.+The scope of that RFC is deliberately very tight, and it serves that goal well,+providing a one-to-one mapping between the schema coordinates and the schema+entities.++This RFC is to gather feedback on expansions of the Schema Coordinate syntax+that could be used for different purposes whilst maintaining familiarity.++## Aim++The aim of this RFC is to give the GraphQL community a standard syntax that+people, tools and documentation can use to concisely and consistently reference+GraphQL operation concepts such as paths that is more fluid, expressive, and+contains more context than the Schema Coordinates RFC that this RFC builds on+top of.++This is not intended to be a replacement of the Schema Coordinates RFC, but an+extension to it for a number of additional use-cases.++## Use cases++#### Referencing a position within a GraphQL Operation Document++Imagine you have the following GraphQL query:++```graphql+{+  businesses: searchBusinesses(name: "Automotive") {+    id+    name+    owner: personByOwnerId {+      id+      name+      email # <<< HERE+    }+  }+}+```++You might reference the marked (`<<< HERE`) field with an expression such as:++- `Person.email` - this is the "schema coordinate" which uniquely identifies the+  field, but lacks context on how we retrieved it+- `>businesses>owner>email` - given the GraphQL query document, this is+  sufficient to uniquely identify this specific reference (caveat: duplicate+  fields would all be referenced with the same expression)+- `>businesses:searchBusinesses>owner:personByOwnerId>email` - this contains+  more context than the above, indicating not just the aliases but the actual+  field names too; with this access to the operation document is not required to+  determine what was requested+- `>businesses:searchBusinesses(name:)>owner:personByOwnerId>email` - this+  contains even more context (the argument names that were used)++These are all valid operation expressions, but they each convey different levels+of context.

I really like this - i could imagine being able to specify different levels of verbosity to tooling that generates these

benjie

comment created time in 4 hours

Pull request review commentgraphql/graphql-spec

RFC: operation expressions

+# RFC: Operation Expressions++(WORKING TITLE!)++**Proposed by:** [Benjie Gillam](https://twitter.com/benjie) - Graphile++In the [Schema Coordinates RFC](./SchemaCoordinates.md) Mark introduced the+concept of "schema coordinates" which give a standard human- and+machine-readable way to unambiguously refer to entities within a GraphQL schema:+types, fields, field arguments, enum values, directives and directive arguments.+The scope of that RFC is deliberately very tight, and it serves that goal well,+providing a one-to-one mapping between the schema coordinates and the schema+entities.++This RFC is to gather feedback on expansions of the Schema Coordinate syntax+that could be used for different purposes whilst maintaining familiarity.++## Aim++The aim of this RFC is to give the GraphQL community a standard syntax that+people, tools and documentation can use to concisely and consistently reference+GraphQL operation concepts such as paths that is more fluid, expressive, and+contains more context than the Schema Coordinates RFC that this RFC builds on+top of.++This is not intended to be a replacement of the Schema Coordinates RFC, but an+extension to it for a number of additional use-cases.++## Use cases++#### Referencing a position within a GraphQL Operation Document

pedantic question: should this be "Referencing a position within a GraphQL Query"?

asking cos what if the document contains two operations? does the operation expression encode which operation in the document it refers to? (can it / should it?)

benjie

comment created time in 4 hours

push eventbytecodealliance/lucet

Frank Denis

commit sha 4a948c70c7749912b9fe309ff7577cf6af70c779

Update cranelift to version 0.70.0 (#634)

view details

push time in 4 hours

delete branch bytecodealliance/lucet

delete branch : fdenis/cranelift-update

delete time in 4 hours

issue commentflutter-rs/flutter-rs

armv7-unknown-linux-gnueabihf support

Keep in mind you can build a Flutter Engine GLFW client directly in the flutter engine repository. So I would just add another recipe that depends on glfw, flutter-engine, inherits CMake, pointing S to the GLFW example cmake folder. If GLFW is really what you want.

That said, I would avoid GLFW for anything related to embedded Linux, as it very poorly implements Wayland support. If you get it to work on one combination, and then need to move it to different targets, it will be a horrendous time sink.

That said it's fairly trivial to build flutter-rs in Yocto. But GLFW...

flukejones

comment created time in 4 hours

fork dcramer/go-links

The open source go links app at the core of Trotto.

https://www.trot.to

fork in 5 hours

startedwereturtle/ghostwriter

started time in 5 hours

startedtrotto/browser-extension

started time in 5 hours

startedtrotto/go-links

started time in 5 hours

issue commentgraphql/graphql-spec

Proposal: Serial fields (nested mutations)

Any update on it? I personally do not think that putting mutations inside types is a good idea (if only from a security perspective it would be a nightmare). But I do like something similar to @harrysolovay so I also suggest using the mutation keyword to define those things like proposed by @stubailo. But we might still want access to a parent in those children fields, so we could also reuse the on syntax of fragments.

It could look like:

type Comment {
  id: ID
  content: string
}

mutation TimelineMutations on Timeline {
  addComment(content: string): Comment
}

mutation UserMutations on User {
  timeline: TimelineMutations
}

type Mutation {
  user(id: ID!): UserMutations
}

It would respect the following rules:

  • The names would be exclusive between mutations and types (unless we get proper namespacing, see https://github.com/graphql/graphql-spec/issues/163).
  • Everything defined in mutations is expected to resolve sequentially.
  • fields defined in mutations can return a mutation, a scalar or a type
  • types cannot return a mutation
  • if a mutation defines a on Type, the parent of all the fields will be an instance of Type
syrusakbary

comment created time in 7 hours

issue commentgraphql-python/graphene

Resolver for a function that returns an Object

I was looking for something like this all over the place. Thanks for contributing

camd

comment created time in 7 hours

startedsyrusakbary/validate_email

started time in 8 hours

startedalpinejs/alpine

started time in 9 hours