profile
viewpoint
遗忘
Evan Huus eapache @Shopify Ottawa, Canada https://eapache.github.io/ Amateur musician and actor. Trying to end up with the right regrets.

terryma/vim-multiple-cursors 7460

True Sublime Text style multiple selections for Vim

eapache/go-resiliency 1034

Resiliency patterns for golang

eapache/channels 622

Golang channel helpers and special types

wvanbergen/kafka 365

Load-balancing, resuming Kafka consumer for go, backed by Zookeeper.

eapache/queue 362

Fast golang queue using ring-buffer

eapache/starscope 232

Smart code search for Ruby, Go, and JavaScript

eapache/rainbow_parentheses.vim 37

Rainbow Parentheses for Vim

eapache/wof_alloc 32

Fast C/C++ memory allocator with free-all operation

eapache/auto-pairs 5

Vim plugin, insert or delete brackets, parens, quotes in pair

eapache/go-xerial-snappy 5

Xerial-compatible Snappy framing support for golang

pull request commentgraphql/graphql-scalars

add implementation guide

For example 12133242323523523 is not a valid value for Int but it is valid syntax and therefore can be used as input for a custom Scalar BigInt for example

Ah that makes sense. But since Value Coercion can take anything, Literal Coercion is still basically just a subset of Value Coercion?

andimarek

comment created time in 9 days

Pull request review commentgraphql/graphql-scalars

add implementation guide

+import { Link } from 'gatsby'+import Layout from '../components/layout'+import SEO from '../components/seo'++<SEO title="Guide to GraphQL Scalars" />++<h1>Reference guide to implement custom GraphQL Scalars</h1>++This is a reference which aims to be as complete as possible and which will be updated over time.<br/>+For an introduction see: [GraphQL Scalars in-depth](https://www.graphql.de/blog/scalars-in-depth/)++```toc+# This code block gets replaced with the TOC+```++# Preamble: Naming is hard++The [GraphQL specification](https://spec.graphql.org/) currently only refers to "Result Coercion" and +"Input Coercion". ++In order to be more clear and precise this guide refers "Literal Coercion" and "Value Coercion" +which are both two different "Input Coercion" in the spec terminology.++"Input" here means always the input of the Coercion functions (the argument of the functions) and not a +specific Coercion function. The specific functions are always named "Result Coercion", "Literal Coercion" +or "Value Coercion"++# Coercion functions++The fundamental job of a Scalar is to give type safety about the values which are returned or which can be used as input.++This type safety is implemented through three functions per Scalar. Each function is invoked at a specific time by the GraphQL engine. +They all validate and convert a provided value. This conversion is called "Coercion" in GraphQL. ++Overview of the coercion functions:++![coercion functions](../images/coercion-functions.png)+++Every function has an input and produces an output:+++| Function      | Input | Output+| ------------- |-------------|------+| Result Coercion  | The result of a resolver.  | A leaf of the overall execution result.+| Literal Coercion | An abstract syntax tree (Ast)  Literal | Is provided to an resolver as argument. +| Value Coercion | A value which is provided as a variable value. | Is provided to an resolver as argument.+++## Result Coercion ++Result Coercion takes the result of a resolver and converts it into an appropriate value for the result.++This result value is NOT the serialized value. Serialization is an extra step.++## Literal Coercion ++Literal Coercion takes an abstract syntax tree (Ast) element from a schema definition or query and converts it into an appropriate +argument value for a resolver.++Literal values can be arbitrary Ast elements: Strings, Ints, Enum names or Input Objects. ++There are no restrictions beside syntax. For example am Ast element can be `1234568901234567890` which +is actually not a valid  Integer (it is to big) but it is a valid Ast element. ++Ast elements can even be complex input objects like `{foo: "String", bar: 1234}`.++## Value Coercion ++Value Coercion takes a runtime values (which come from variables) and convert it into an appropriate value for a resolver.++Variables are provided along with the actual query to the engine for execution. These values are often deserialized from JSON before+provided to the engine.++# Serialization ++Serialization is the process of taking some in-memory values and converting them into an appropriate format for +sending over a network or storing somewhere. Deserialization is the opposite: taking some format which comes from a network request+and constructing an in-memory value from it.++A typical GraphQL request against a GraphQL service accepts JSON as serialization format and produces JSON:++![request steps](../images/request-steps.png)++A GraphQL request in JSON consists of:++```JSON+{ +    "query": "..." +    "operationName": "..."+    "variables": {...}+}+```+This JSON is then deserialized into an in-memory representation. The details how this in-memory structure +looks depend very much on the language you using.  ++This values are then used to passed into the GraphQL engine to execute the request.++The result of the overall execution is an in-memory execution result which is then serialized to JSON:++```JSON+{ +    "data": {...} +    "errors": [...]+}+```++## Result Coercion: Serialize or not

Should this go under implementation guidelines? It is an implementation thing.

andimarek

comment created time in 10 days

pull request commentgraphql/graphql-scalars

add implementation guide

I understand the distinction between Literal and Value coercion you're trying to make, but ultimately I think they're the same thing. It's just that a literal can only be one of the graphql AST types (string, int, etc) whereas a variable value can be of any type supported by the transport.

In other words, I don't think it should be possible to specify a scalar which treats string literals differently from string variables.

andimarek

comment created time in 10 days

issue openedgraphql/graphql-scalars

Blessing scalars for GraphQL-JS

To discuss: how do we want to bless certain custom scalars for inclusion in graphql-js? Is it just an ad-hoc vote of the working group? Or should we not bless any such scalars, and leave the community to figure it out? There's definitely a case to be made for standard reference implementations of some key ones like DateTime...

created time in 10 days

issue openedgraphql/graphql-scalars

Edit Rights

Something that occurred to me, to discuss: who should we accept edits from (or e.g. new versions of an existing scalar), besides the original author? Other members of a shared org seem obvious, but there's no obvious path for sharing ownership over a single author's scalar.

Not sure if this actually matters, or if we should be encouraging more of a fork-and-evolve model?

created time in 10 days

issue openedgraphql/graphql-scalars

Requirements Discussion

Ticket for any discussion of what requirements we want to enforce before we accept a scalar definition to the repo. Off the top of my head:

  • Conforms with whatever we decided on for URL/namespacing/versioning: https://github.com/graphql/graphql-scalars/issues/1
  • Conforms with whatever rough format we decide on in https://github.com/graphql/graphql-scalars/pull/2
  • Some kind of licensing agreement or contributor's agreement or something something legal?

Anything else?

created time in 10 days

PR opened graphql/graphql-wg

Add Evan to July meeting
+1 -0

0 comment

1 changed file

pr created time in 14 days

push eventeapache/graphql-wg

Evan Huus

commit sha 350af7223a5230866e15bdb728b4a148e27ed834

Add Evan to July meeting

view details

push time in 14 days

issue commentgraphql/graphql-scalars

URL Proposal

I agree with Andi's point about versioning, and might even take it a step further - if the spec change is clearly not backwards compatible, is it even the same spec at that point? Should the new spec and the old spec really be sharing usage stats? I think that for most of the metadata/stats we might want for a spec, we'd really want them per major version, not shared across multiple major versions, in which case it might be simpler to follow the golang style and just say that a new major version should just be a new spec. This would still leave a single integer version for use for editorial changes.

The obvious con here is that we might end up with https://scalars.graphql.org/andimarek/datetime-v2/1. It's a bit gross, but not actually sure if it's a huge problem?

leebyron

comment created time in 16 days

pull request commentShopify/quilt

Accept query params in gid

we accept/expect GID not using an URI format.

What? Why? Is core returning GIDs in these formats (it shouldn't) or has the method been hijacked for things that aren't actually GIDs?

jsaubry

comment created time in 21 days

issue commentShopify/sarama

Sarama roadmap

👋 I unfortunately haven't been following the evolution of this project at all in the last year or so, and I'm quite busy for the next few weeks with another project, but I'm still interested in chatting and providing my fully un-informed opinions :)

I want to mention https://github.com/Shopify/sarama/wiki/Ideas-that-will-break-backwards-compatibility as a nice long collection of things we should fix or think about if we decide to do a breaking v2. Back when I was maintaining Sarama I dumped a lot of random ideas there. Off the top of my head all of the points in that list are still valid/important.

Historically Sarama has tied it's protocol usage to the Version field in Config. However, it should really be sending ApiVersionRequest to a broker on connect and using the version ranges found in the response to gate what protocols are used.

That seems like a nice thing to bake in everywhere if that protocol is now available in all of Sarama's supported Kafka versions. It had only just been introduced last time I was paying any attention, so we still needed to support older brokers at that point.

Do we think it would be feasible to provide a useful Producer and Consumer API without doing any lifecycle management internally?

Isn't this just creating and manually sending request objects to brokers, which you can already do?

I think I'd support splitting out the basics into a separate package from the producer/consumer/etc, but in my mind the complex parallelism/lifecycle management is where most of the actual value in Sarama lies. I think Bryan's principle is meant to apply to more low-level packages, not to high-level client libraries that have to do state management anyway.

Metrics

Yeah, sorry, I merged a PR to add go-metrics support without thinking about it too hard and without any use case for it myself. If we have a better alternative, let's do that.

d1egoaz

comment created time in 22 days

pull request commentShopify/quilt

Accept query params in gid

I think that even if we were to use/return an URI object, we would still need to craft a regex to extract the numeric id from it.

I don't think so? Instead of a regex it would just be uri.path.last.to_i.

jsaubry

comment created time in 24 days

CommitCommentEvent
CommitCommentEvent

issue openedgraphql/graphql-spec

Working draft release notes

https://spec.graphql.org/ has release notes for everything except the working draft. This makes it difficult to know what changes are going to be included when the next release is cut - right now that information only exists in git.

@IvanGoncharov mentioned that this could be done by adapting a script he wrote for graphql-js: https://github.com/graphql/graphql-js/blob/master/resources/gen-changelog.js

created time in a month

issue commentrmosolgo/graphql-ruby

[Rework] Input argument validation

That's a great summary, thanks Robert. We're chatting internally but we're coming around to the idea that the logging we want should ultimately be decoupled from visible? - that's going to be a bigger project for us though.

Related to that: there's a weaker/inverse expectation we're using that visible? is called for at least all the schema elements which are present in the query. This seems more obviously true (I hope) and probably easier to enforce. It would be good to explicitly support (or drop) that expectation as well, separate from the one you mention.

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if !input.key?(argument_name) && argument.type.non_null? && warden.get_argument(self, argument_name)+              m[argument_name] = nil             end++            m           end -          # Items in the input that are expected, but have invalid values-          visible_arguments_map.map do |name, argument|-            argument_result = argument.type.validate_input(input[name], ctx)-            if !argument_result.valid?-              result.merge_result!(name, argument_result)+          input.to_h.merge(required_inputs).each do |argument_name, value|+            argument = warden.get_argument(self, argument_name)+            # Items in the input that are unexpected+            unless argument+              result.add_problem("Field is not defined on #{self.graphql_name}", [argument_name])+              next             end+            # Items in the input that are expected, but have invalid values+            argument_result = argument.type.validate_input(value, ctx)

My original comment here was an architecture/style question, not a behavioural one. It sounds like there's more we need to dig into here, but if we're confident that the current code works correctly could we get that out and then follow up on the other points?

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if !input.key?(argument_name) && argument.type.non_null? && warden.get_argument(self, argument_name)+              m[argument_name] = nil             end++            m           end -          # Items in the input that are expected, but have invalid values-          visible_arguments_map.map do |name, argument|-            argument_result = argument.type.validate_input(input[name], ctx)-            if !argument_result.valid?-              result.merge_result!(name, argument_result)+          input.to_h.merge(required_inputs).each do |argument_name, value|+            argument = warden.get_argument(self, argument_name)+            # Items in the input that are unexpected+            unless argument+              result.add_problem("Field is not defined on #{self.graphql_name}", [argument_name])+              next             end+            # Items in the input that are expected, but have invalid values+            argument_result = argument.type.validate_input(value, ctx)

As I understand it the old code was kind of implicit - it checks every visible argument, and if the argument was required but had no value provided, then argument.type.validate_input would produce an error.

Now we're being a bit more explicit about generating a list of missing_required_inputs. Rather than merging those explicit nils into the input just so we can call validate_input on nil to generate the error... I think we could just generate the error instead of building missing_required_inputs at all?

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          missing_required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|

this hash has entirely nil values... I don't know if there's actually a nicer way to build it, or if we could get away with just an array of keys instead or something? but don't let it hold this up in the short term

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)           # We're not actually _using_ the coerced result, we're just           # using these methods to make sure that the object will           # behave like a hash below, when we call `each` on it.-          begin+          input = begin

The comment on this block is now wrong

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def get_field(parent_type, field_name)         @visible_parent_fields[parent_type][field_name]       end +      # @return [GraphQL::Argument, nil] The argument named `argument_name` on `parent_type`, if it exists and is visible+      def get_argument(parent_type, argument_name)

I'll defer to @rmosolgo's judgement here. I did note that we are now calling get_argument twice on the same argument in some scenarios.

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if !input.key?(argument_name) && argument.type.non_null? && warden.get_argument(self, argument_name)+              m[argument_name] = nil             end++            m           end -          # Items in the input that are expected, but have invalid values-          visible_arguments_map.map do |name, argument|-            argument_result = argument.type.validate_input(input[name], ctx)-            if !argument_result.valid?-              result.merge_result!(name, argument_result)+          input.to_h.merge(required_inputs).each do |argument_name, value|+            argument = warden.get_argument(self, argument_name)+            # Items in the input that are unexpected+            unless argument+              result.add_problem("Field is not defined on #{self.graphql_name}", [argument_name])+              next             end+            # Items in the input that are expected, but have invalid values+            argument_result = argument.type.validate_input(value, ctx)

@rmosolgo it's weird to me that we handle missing required inputs by adding them as nil, and then letting the validation fail that nil isn't an accepted value? Could we not just add_problem directly when we notice they're missing?

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|

I might call this missing_required_inputs

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def get_field(parent_type, field_name)         @visible_parent_fields[parent_type][field_name]       end +      # @return [GraphQL::Argument, nil] The argument named `argument_name` on `parent_type`, if it exists and is visible+      def get_argument(parent_type, argument_name)

I believe the intent of this method was to be cached which it is not right now?

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if !input.key?(argument_name) && argument.type.non_null? && warden.get_argument(self, argument_name)

The only case we will trigger a visibility check and over-report our logging is when there is a required argument that is not supplied by the user and it is visible on the field.

These requests are broken anyway, correct, meaning they'll fail with an error for a missing argument?

I think this is probably a solid upstream improvement and good short-term fix for our issue (since IIRC none of the args we care about short-term are required), but the corner case worries me a bit. Let's ship this, but continue to think about a long-term solution.

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if !input.key?(argument_name) && argument.type.non_null? && warden.get_argument(self, argument_name)

Will get_argument still trigger our logging? 'cause we're still calling it here on keys that are explicitly not in the input.

grcooper

comment created time in a month

pull request commentrmosolgo/graphql-ruby

Only check used input arguments visibility

Where are we using .key? ? merge only returns a merged hash, it doesn't mutated input so as long as I am not using it in that particular block then we are good?

KCCO I made some bad assumptions based on how you worded the PR description.

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if input[argument_name].nil? && argument.type.non_null? && warden.get_argument(self, argument_name)+              m[argument_name] = nil             end++            m           end -          # Items in the input that are expected, but have invalid values-          visible_arguments_map.map do |name, argument|-            argument_result = argument.type.validate_input(input[name], ctx)-            if !argument_result.valid?-              result.merge_result!(name, argument_result)+          input.merge(required_inputs).each do |argument_name, value|

if we merged this the other way around we could build required_inputs much more simply?

grcooper

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if input[argument_name].nil? && argument.type.non_null? && warden.get_argument(self, argument_name)

input[argument_name].nil? or !input.key?(argument_name)

grcooper

comment created time in a month

pull request commentrmosolgo/graphql-ruby

Only check used input arguments visibility

Inject all required arguments as nil that were missing from input.

Is this going to break .key? on the input for those arguments?

grcooper

comment created time in a month

Pull request review commentShopify/graphql-metrics

Safely handle interrupted runtime metrics

 def after_query(query)         return if query.context[GraphQL::Metrics::SKIP_GRAPHQL_METRICS_ANALYSIS]          ns = query.context.namespace(CONTEXT_NAMESPACE)+        analyzer = ns[GraphQL::Metrics::ANALYZER_INSTANCE_KEY] -        # NOTE: The start time stored at `ns[GraphQL::Metrics::QUERY_START_TIME_MONOTONIC]` is captured during query-        # parsing, which occurs before `Instrumentation#before_query`.-        query_duration = GraphQL::Metrics.current_time_monotonic - ns[GraphQL::Metrics::QUERY_START_TIME_MONOTONIC]+        if runtime_metrics_interrupted?(ns)+          # If runtime metrics were interrupted, then it's most likely that the application raised an exception and that+          # query parsing (which is instrumenetd by GraphQL::Metrics::Tracer) was abruptly stopped.

typo

chrisbutcher

comment created time in a month

issue commentShopify/graphql-design-tutorial

Defaulting to semantic nullability

Would it make sense, then, to update the tutorial?

Our thoughts on this are evolving quite a bit, and we prefer not to change the tutorial too drastically on a regular basis. We'll definitely update it if we come to a confident conclusion.

I would love to hear your non-confident thoughts on the matter. Can you share what specific problems in practice you've run into?

Given a field which our internal data model declares must always be present, you’d think it would be a safe bet to make the relevant GraphQL field non-null. We’ve collected a significant number of exceptions to this rule:

  • When the user using the app does not have permission to access the object. Apps are expected to know their own access scopes and not request fields they don’t have access to, but they cannot easily track the permissions of the active user.
  • When a race condition between resolving a query and mutating the data results in an inconsistent view of the world within the execution of a single query.
  • When the database has invalid data. We sometimes have model-level validations without database-level validations, so there are some fields which ought to have no null values but in practice have a bunch.
  • When the backing data is moved from our core system into a transparent micro-service which can fail or time out independently.

In a mostly-nullable schema, any of these problems would be isolated to the single failing field which would return null, permitting the rest of the query to succeed. This is a pretty important property for overall system resiliency.

flux627

comment created time in a month

issue commenteapache/starscope

add sample .starscope.json for reference

That would make sense to me.

twnaing

comment created time in a month

issue commentShopify/graphql-design-tutorial

Defaulting to semantic nullability

I have lots of thoughts on this, but none of them are confident - while I still agree with you in theory, we've run into so many problems with non-nulls in practice that I don't feel comfortable recommending their use. The official recommendations have a bunch of trade-offs, but they're likely the right choice for the majority of use cases.

flux627

comment created time in a month

issue commenteapache/starscope

add sample .starscope.json for reference

ctags read command-line options from .ctags file (like starscope use .starscope.json) man ctags's FILES section tells more. Previously I used ctags and migrated to starscop. I had to migrate my .ctags to .starscope.json. If starscope could understand the .ctags file, the transition would be seamless.

Ah, I understand now. I don't have time to add that feature myself right now, but I'd be happy to take a pull request.

I just wanted to confirm that because (this part of) USER GUIDE does not mention the need to run starscope before export. And I thought export command run the starscope (db generation code) before exporting.

Yes, if you just run e.g. starscope -e cscope that will generate the database and do the export - you don't need to generate the database separately first.

twnaing

comment created time in a month

pull request commentgraphql/graphql-wg

Add myself and agenda item

👍 the 11th also works for me.

eapache

comment created time in a month

pull request commentgraphql/graphql-spec

Small fixes and clarifications to contributing

I'm not certain of the rules of that vs which.

https://www.quickanddirtytips.com/education/grammar/which-versus-that-0

AFAICT all of the s/which/that changes made in this PR are correct. Maybe a bit pedantic at this point, but technically correct.

mike-marcacci

comment created time in a month

Pull request review commentgraphql/graphql-spec

Small fixes and clarifications to contributing

 move forward. See editor Lee Byron talk about  * **Performance is a feature** -  GraphQL typically avoids syntax or behaviors which could place burden on-  runtime efficiency or make demands of a GraphQL service it cannot-  efficiently fulfill.+  GraphQL typically avoids syntax or behaviors that could jepordize runtime

typo: jeopardize

mike-marcacci

comment created time in a month

issue commenteapache/starscope

add sample .starscope.json for reference

Good question, I'll try and write up something better at some point. In the meantime:

is it possible to source .ctags file it is present in the directory? (the reason is ctags supports ruby and there are quite some tools available for ctags e.g. gem-ctags, but cscope support for ruby is poor)

Are you asking if starscope can extract information from existing tag files? It cannot, but it can generate all the same information itself. Or have I misunderstood?

what are the patterns we can use to exclude files and folders?

Anything supported by Ruby's File.fnmatch? method: https://ruby-doc.org/core-2.5.0/File.html#method-c-fnmatch

command line --exclude is the same as json file "excludes"?

Yes.

how can I view the currently excluded file/folders?

starscope --no-update --dump _excludes will show the current list of patterns excluded from the local db. This list gets combined with the patterns in .starscope.json.

If you're looking for the actual files/folders, I don't think there's a way to get that list? It's calculated from the exclude patterns and isn't stored or output anywhere.

do I need to run starscope before I export the cscope format?

Yes? Again I'm not sure what you're asking. You can't export to cscope without running the program, since the program is what does the export...

twnaing

comment created time in a month

PR opened graphql/graphql-wg

Add myself and agenda item
+2 -0

0 comment

1 changed file

pr created time in a month

push eventeapache/graphql-wg

Evan Huus

commit sha 6e4b5ba4c1d16edc07e45e4fc860473f8046da03

Add myself and agenda item

view details

push time in a month

push eventShopify/graphql-design-tutorial

Alexander Popov

commit sha b12aa7eaa3b00e4b8d25c4e7977475c19240a7bc

Add table of contents

view details

Evan Huus

commit sha 56c3b8ea2e6f54d9768318558ce411ba066faae2

Merge pull request #15 from AlexVPopov/add-table-of-contents Add table of contents

view details

push time in 2 months

pull request commentShopify/shopify_api

Add bulk operation utility

cc @grcooper @swalkinshaw

nickmealey

comment created time in 2 months

PR opened graphql/graphql-wg

Add Evan to 2020-05
+1 -0

0 comment

1 changed file

pr created time in 2 months

push eventeapache/graphql-wg

Evan Huus

commit sha aa131da5186e6cf449d62b2ea033f946ed6f7e18

Add Evan to 2020-05

view details

push time in 2 months

issue commentgraphql/graphql-spec

The term "query" is overloaded and can be ambiguous

Yes please! I strongly support this disambiguation. Shopify has felt this pain at several points internally, both in explaining GraphQL to devs and in our actual code - you don't want to know how many distinct class Querys we have 😬 .

benjie

comment created time in 3 months

pull request commentrmosolgo/graphql-ruby

Reduce stack depths of deeply nested blocks

What's the value in reducing stack depths? IIRC capturing blocks in ruby is fairly slow, so it's not obvious to me up front if these changes would actually perform any better.

jhawthorn

comment created time in 3 months

pull request commentrmosolgo/graphql-ruby

Limit to 100 input validation errors

Did anything ever come of this Robert?

eapache

comment created time in 3 months

more